能源行业的SAP升级项目，技术难点和制造业不在一个位置上。制造业项目的主战场是标准模块配置和接口改造；能源项目的主战场在数据层------资产与检修数据的连续性、多权益口径的核算、多法域的数据留存，以及被连续生产压到极窄的切换窗口。
一、数据模型层面的四类约束
1. 资产与检修数据的长期对应关系
能源企业资产密集，设备台账、检修历史、工单记录与财务资产账（AM/FI-AA）之间存在以十年计的对应关系。升级迁移时若按通用规则裁剪历史数据，破坏的往往不是数据本身，而是台账与资产账之间的引用完整性------后续折旧计算、维修成本归集（CO 归集到工单/功能位置）、资本化判断都会受影响。
工程上的验证点是：迁移前后，台账-资产账的对应记录数是否一致、抽样回溯十年期工单的成本归集路径是否完整。这两个校验做不了，说明映射设计有问题。
2. 多权益口径并存
合资公司、产品分成合同、联合运营，意味着同一套系统内多种权益口径与分摊规则并存（JV Accounting / PSC 场景）。若升级叠加组织结构调整（公司代码重组、科目表合并），配置矩阵会指数级膨胀------每种组织结构组合 × 每种权益口径都要有测试用例。
3. 多法域留存与报送
环境排放、安全生产、储量与生产报告、税费申报，决定了相当一部分数据必须长期保留并可随时调取。各法域的留存期限与本地化要求不一致，数据保留策略要按法域逐一配置，而不是一刀切的全局策略。这类边界必须在项目初期冻结，上线后补配的代价极高。
4. 窄停机窗口
电力、油气、化工装置连续运转，停产窗口提前很久排定，切换可用时长被严格限定，容错空间小。这意味着切换脚本必须全量演练过、回退路径必须验证过、时长测算必须有依据------"预计 X 小时"没有测算和演练支撑，等于没有承诺。
二、为什么通用经验会失灵
三个典型失误场景：
- 历史数据裁剪线沿用制造业惯例（如"近三年细迁"），未验证裁剪后台账-资产账对应关系的完整性；
- 升级与组织/总账调整叠加后，测试工作量按组合增长，仍按单项目排期，后期挤占验证时间；
- 多法域保留策略推迟到上线前配置，发现与本地化要求冲突，被迫返工。
共性：问题在启动前已存在，在测试后期或切换阶段才显现。这也是为什么"有没有处理过同类情况"是可以被验证的------问数据量、公司代码数量、停机时长、验证方式，四项都能给出过程细节的，经验大概率是真的。
三、评估服务商的四个工程维度
- 同类系统转换实证：资产密集型系统、多法人多权益结构、升级叠加组织调整，各做过什么，四项过程数据能否说清。
- 停机时长量化：能否写入方案，测算依据与演练次数。
- 多项目合并上线：升级、拆分、合并、上云能否合并为一次切换，直接影响中断次数。
- 历史数据归档：退役数据去向、保存期限、个人信息脱敏、访问与导出留痕，方案要落到字段与流程级别。
下一篇看具体实证项目，以及SNP在这类项目中的交付方式。