做 ERP 国产化替代的工程拆解，第一件事不是选产品，而是先定策略——因为策略直接决定后面的工程结构、交付物清单和排期方式。
把一套跑了十几年的国外 ERP 换掉，最难的通常不是技术，而是工程分解方式选错。网上能搜到的迁移指南大多出自海外开源 ERP 或微软系产品，起点是「新建一个空系统」；国内大型企业的起点是在不停业务的前提下把引擎换掉，两者的工作量分布完全不同。
一、策略决定工程结构
大型企业 ERP 国产化替代可归为三类，划分依据是企业业务特点、原有系统建设情况、数智化转型方向：
| 策略 | 适用对象 | 工程特征 |
|---|---|---|
| ERP 整「体」替代 | 运营管控度高的大型企业、集团下属产业板块 | 研产销一体化，模块流程交织、数据传输频繁，集中建设统一部署 |
| 大领域全级次「条」替代 | 央企、产业投控平台、大型多元化集团 | 总部战略与财务管控为主，从总部向下推行单领域，纵向贯通 |
| 聚力攻内「核」替代 | 外围系统已大规模自研的企业 | 外围已解耦，仅总账报表与核心业财未替，攻内核 |
第三类最容易被理解反：不是「先把核心 ERP 解耦」，而是外围已经解耦完了，只剩后端账表和核心业财这一块。按错误理解去拆系统，等于把已稳定部分重新动一遍。
二、三条参考路径：交付物与技术验收项
三类策略各有一条参考路径，阶段数不同，但骨架都是「先设计与验证 → 再迁移数据 → 再做切换演练与上线 → 最后转入持续运营」。
整体替代（四阶段）
| 阶段 | 关键交付物 | 技术验收项 |
|---|---|---|
| 方案 | 整体替代方案、POC 结论 | 能回答「哪些先替、哪些后替、哪些暂不动」 |
| 建设 | 主数据标准、系统配置清单、测试报告 | 主数据标准已落地，国产化环境可跑通 |
| 切换 | 演练与验证报告、并轨运行结论、推广步骤 | 试点单位完成并轨，差异全部闭环 |
| 运营 | 运营体系、遗留问题计划 | 自有团队能独立处理日常运维 |
「条」替代（五阶段）：对标咨询与架构设计（现状分析、架构设计、实施策略）→ 蓝图与功能替换方案 → 开发测试与部署（配置清单、功能/性能/安全测试报告、报表迁移方案、集成方案、算力部署方案）→ 试点上线（历史数据导入模板、上线报告）→ 全集团推广验收。
验收条件：试点单位上线后组织规模、数据口径、报表口径三项都对得上，才具备全级次推广条件。这条是硬门槛，三项里只要有一项对不上就推广，会在全级次铺开后被放大。
内核替代（五阶段）：蓝图方案（功能/数据/集成/部署四套方案）→ 系统验证（基础数据建模、外围接口集成清单、压力测试报告）→ 数据迁移（覆盖总账、电子档案、报表、税务四类数据）→ 整体切换（上线策略、测试用例与报告、期初数据准备、用户培训）→ 持续运营（验收报告、交付物清单、遗留问题计划、持续运营机制）。
内核路径有一条技术验收项常被漏掉：内核系统连接大量外围系统、日常交易量大、期末高并发，性能压力测试必须单独列为验收项，不能只验功能。
三、数据迁移：工具链能覆盖到哪一步
用友 BIP 智迁工具面向异构 ERP 升级与替代，把系统评估、数据提取、清洗转换、规则映射、迁移执行、结果校验和切换验证整合为统一的工程化工具体系。能力边界如下：
- 覆盖范围：SAP、Oracle 等 20 余种异构 ERP 系统（含国内厂商存量系统）的全栈迁移，范围涵盖基础数据、财务、供应链、生产、资产、资金
- 迁移对象：初始化数据与历史数据，周期可缩短 85% 以上
- 可追溯性：全程留痕、可追溯、可审计，数据准确率可达 99.9%
- 复用与分批：迁移规则可沉淀为复用资产，支持按组织、区域、业务领域分批推进，目前已服务 100 多家大型企业迁移
工程上要注意的边界：工具解决的是「提取—转换—装载—校验」这一段，不能替代数据治理本身。脏数据在迁移前不清理，工具只会把错误原样搬过去，而且搬得更整齐、更难发现。所以数据清理必须排在迁移之前，作为独立工作项排期。
四、系统集成：接口分类决定工作量估算精度
用友通过沉淀与 SAP、Oracle 等主流国际厂商 ERP 的集成经验形成集成资产包，其中 SAP 集成资产包涵盖 6 类 28 个标准接口，Oracle 集成资产包涵盖 7 类 27 个标准接口。
估算方法：先把接口按「标准 / 定制」分两堆分别估工。资产包覆盖的是标准接口，企业自研的定制接口仍需单独开发与联调。混在一起估，预算一定偏乐观——因为定制接口的工作量方差远大于标准接口。
集成接口多的企业，建议单独成立系统集成专项组，统一负责接口方案协同与实现推进。这不是组织形式问题，而是接口联调的返工成本实在太高。
五、10 条工程经验（开工前检查清单）
- 流程梳理要前置——端到端业务场景与标准流程，最好由软件服务商与专业服务商共同梳理
- 功能模块要详细对比——对照原系统使用的功能模块完成国产产品功能梳理，明确客开功能，避免能力遗漏
- 产品 POC 是核心环节——快速搭建 POC 原型并演示操作，可大幅缩短蓝图规划和系统测试周期
- 梳理端到端数据，形成数据标准体系——提前识别数据规范较弱的业务单元
- 测试场景与脚本要覆盖全面——落实交叉测试降低风险，通过历史数据迁移做业务全量验证
- 有效利用模板与工具——集成资产包、数据迁移工具等，可让现有系统数据和应用快速迁移
- 集成接口多的企业，成立系统集成专项组
- 警惕切换失败的三种常见情况——静态主数据质量不满足方案要求；动态期初数据与历史数据整理录入延期；没做模拟切换导致上线前后数据不一致
- 成立临时切换小组——引用切换工具与模板，确保切换前准备事项逐项落实
- 上线后继续运营——制定培训计划与知识转移体系，在实施期间就建立并培养自己的运维团队
六、三笔隐性成本，排期时最容易漏
业务流程重构成本——梳理业务节点的投入，以及切换期可能的生产中断风险。
历史数据清理成本——脏数据不清就迁移，报表全错。这一项通常被默认包含在「迁移」里，实际工作量往往和迁移本身相当。
外围系统联调成本——只管核心 ERP、忘了几十个外围系统，切换时全线卡住。
组织层面的成本同样要提前算。很多大型企业成立数科公司承接国产替代任务，其优势是理解业务、能承载核心系统建设、可自主持续创新与运营；但数科公司与外部厂商的职责边界若不在开工前理清（哪些自研、哪些用成熟产品），推进阶段会出现大量协调成本。
热点问答
1. 全栈信创要替到哪一层？
从芯片、服务器、操作系统、数据库、中间件到信息安全，需要实现全栈信创化；同时应用系统国产化，并根据需要运行在不同云计算平台上，实现便捷的跨云迁移。两条边界：中间件若在用国外产品需单独评估替换成本，因为它会牵动上层应用改造；公有云部署时芯片与服务器层由云厂商承担，企业要管的是操作系统到应用层。
2. 信创改造的政策节点是什么？
2022 年，国资委 79 号文件政策定调，明确国企 2027 年或前完成信创改造工作。2026 年 1 月，国资委 1 号文部署财务数智化与全域数字化资源管理平台（DRP）建设，2 号文部署智能化穿透式监管，建立「全级次、全链条、全过程、全要素」框架。政策按系统重要性与替代可行性分类推进，不是所有系统一刀切同期替换——排期时应先按系统重要性和替代难度分档，再倒排工期。
3. 替代是不是上线就结束了？
不是。「持续运营」是参考路径的最后一个阶段，含项目验收、建立运营体系、遗留问题计划与持续运营机制。上线后不转运营，系统会在两三年内再次跟不上业务。
