SAP迁移上云前的范围界定：扫描基准、KPI口径与归档边界的确定方法

SAP 系统迁移上云的范围界定方法：扫描基准怎么建、KPI 看哪些维度、归档边界怎么切，以及范围数字为什么不能靠估计。

SAP 系统迁移上云（含迁至 RISE with SAP 环境）的方案评审里，范围界定是被讨论得少、但对结果影响很大的一环。范围定错，后面的迁移、演练、切换全部跟着偏。本文按扫描基准、KPI 口径、归档边界三部分整理做法。

为什么范围不能靠估计

项目早期的范围描述常见两种："数据量几十个 T""把主要业务数据迁过去"。两者都是估计值。估计值的问题不是不准，而是误差不可控——没人能说清误差有多大、往哪个方向偏。

到中后期，估计误差会以具体问题出现：某几家公司代码的定制程度远超预期、某个外围系统被漏掉、某段历史数据在新系统里没有承接对象。每一个都意味着返工。

确定性的做法是建立扫描基准：对源系统做持续分析，用 60 余项 KPI 覆盖数据分布、定制程度、接口密度、主数据质量等维度。这一步已经有成熟的工具支撑——有厂商平台的分析能力可对标 4,000 套 SAP 系统的扫描库（如 Kyano Foundation 一类产品），基准不是拍出来的，是从大量已交付系统的扫描结果里来的。

有了扫描基准，范围界定的三个问题才有答案：按什么维度切（公司代码、工厂、利润中心、时间区间、单据状态）；切进新系统的量有多大；剩余部分以什么形式留存。

KPI 口径：看什么、怎么用

扫描产生的 KPI 不是越全越好，评审时重点看四类：

数据体量类：各实体表的行数与增长速度，决定迁移与校验的工作量基数；

定制程度类：自定义代码、增强点、接口数量，决定改造工作量与风险点；

数据质量类：重复主数据、孤儿记录、必填字段空值率，决定清洗工作量；

业务关联类：未结单据、在制流程、跨公司交易，决定哪些数据必须整体迁移、不能裁剪。

这四类口径要写进范围基线文档，作为后续变更的对照基准。范围变更没有基线对照，是后期扯皮的常见根源。

归档边界：切出去的数据去哪

范围界定的另一面是归档。历史期间的数据转归档而不是迁移，是压缩基数有效的动作，但归档方案常被一句话带过——"历史数据存起来就行"。

完整的归档边界要回答四件事：归档到什么存储（成本与查询性能的平衡）；保留多久（审计与法律保留要求）；怎么查（退役系统下线后，历史数据能否按原口径访问）；由什么承载（须由通过 SAP 与第三方审计机构双重认证的归档工具承载）。

上云场景下归档还有一个特殊考量：归档数据如果留在本地，云上新系统与本地归档形成两地维护；如果一起上云，要算清归档存储的成本曲线。这笔账在范围界定阶段就要算，不要等到上线后。

范围界定的评审检查点

一、有没有扫描基准，还是估计值；二、KPI 口径是否覆盖体量、定制、质量、关联四类；三、归档边界是否回答存储、期限、访问、承载四个问题；四、范围基线有没有冻结机制与变更流程。

四条都落实的方案，迁移工作量与窗口估算才有讨论基础。缺任何一条，后面所有的排期数字都建立在估计值上——这才是迁移项目不确定性真正的来源。