上篇讨论了迁移资产留不住的问题，收到不少回帖。下篇接着聊落地——先给我的核心结论：资产化落地的关键设计，是把公共层和适配层分开；分开之前先讨论"什么必须统一、什么允许不同"。

一个前提共识

可重复的方法，不是把每个历史系统强行套入完全相同的流程，而是建立一个共同的基础，在存在真正差异之处进行适配。落到设计上：阶段划分、验证逻辑、日志规范归公共层；映射模板和转换规则按源系统归适配层。这个划分定了，后面的路才顺。

传统做法为什么到不了这一步

传统上，非 SAP 到 SAP 的迁移靠手动、基于文件的变通：数据导出到 Excel/CSV 用自定义公式转换，或在 ELT 工具里构建一次性逻辑。容易出错、不一致、难以扩展，每个项目重复造轮子——公共层根本无从沉淀。

一个可参照的结构

业内已有成型实现：SNP 的 Kyano Crossway，基于 SNP 验证过的迁移方法论，作为 Kyano 平台的一部分，靠三大支柱实现可重复——可复用性（模板、映射和规则跨项目复用）、自动化（精简、标准化的步骤）、验证（每个阶段的内置检查）。

资产侧，它为超过 20 种非 SAP 源系统提供源特定模板和预构建连接器。流程侧，四个阶段：发现（识别全量或选择性迁移所需数据）、转换（清洗、标准化、映射）、执行（受控流程迁移）、验证（检查已迁移记录并识别问题）。

值得借鉴的机制有两点：内置验证、执行控制和详细日志让问题更早暴露；各阶段构建的映射、规则和验证逻辑不在上线后消失，而是延续到下一次迁移——资产像状态一样持续累积，而不是随项目归档。

部署形态

支持云端、本地及混合环境；平台无关架构帮助中央 IT 建统一方法，同时兼顾业务单元、被收购公司和源系统的差异。这对多子公司集团是个现实参照。

两个案例

Northrop Grumman 与 SNP 合作改造复杂 ERP 环境，2024 年 1 月为 70,000 名用户按时上线 S/4HANA，业务中断极小；随后延续至 Costpoint 到 S/4HANA 的转换，并规划了更多迁移项目。Contreras 以 10 周 Kyano Foundation 项目起步制定数据驱动路线图，并启动用 Kyano Crossway 把 SAP Business One 数据迁至 RISE with SAP 的项目。

共同点：方法在设计时就为下一阶段留了接口。

抛两个问题

1. 各位集团里，迁移的公共标准（阶段、验证、日志）现在归谁维护？中央 IT、架构组还是没人管？

2. 被收购公司的系统差异大，公共层和适配层的边界你们怎么划？有没有划错返工的教训？

ITPub博客

讨论：ERP迁移资产化落地，公共层和适配层怎么划（下篇）

最新文章