目录
ERP 实施团队需要一位有权威的发起人，一位懂 ERP 的项目经理，来自每个受影响职能的业务流程负责人，功能顾问和技术顾问，以及负责集成、数据迁移、测试、变革和切换的专属负责人。云上的 SAP 项目还要增加一位 Clean Core 架构师和一位指定的 SAP 联系人。按复杂度而不是公司人数来确定团队规模，并为每位顾问配一位内部人员，由这位内部人员在上线后负责该领域。
本文写给为 ERP 项目配备人员的发起人、CIO 和项目总监。内容涵盖各个角色、每个角色成败的关键、团队规模、云 ERP 和 AI 带来的变化，以及如何与实施合作伙伴分工。
我合作过的一家公司，同时在跑两个 ERP 实施项目：一个用 SAP，一个用 Oracle。Oracle 项目有 4500 人在做。SAP 项目有 38 人。一个顺利上线。另一个则是没完没了的灾难。差别就在团队。
做了 25 年 SAP 实施，这个规律始终成立。团队选错了，或者人对了、结构错了，项目就会拖沓，成本攀升，等到上线时，用户已经认定自己讨厌这个系统。
- 项目发起人清除障碍、争取预算、在各部门之间做决定SAP 服务联系人在 RISE 项目中，负责平台问题升级和服务评审
- 项目经理时间线、范围、风险以及合作伙伴协调
- 业务流程负责人验证设计，测试真实工作流
- 功能顾问和技术顾问配置、扩展并提出异议
- 数据迁移负责人清洗、加载和切换数据
- 集成负责人中间件设计和数据流
- 变革和培训负责人沟通、倡导者、采纳
- Clean Core 架构师在云版本中，每个扩展放在哪里
| 角色 | 他们实际做什么 | 何时参与 |
|---|---|---|
| 项目发起人 | 清除障碍、争取预算、做出跨部门决定 | 所有阶段 |
| 项目经理 | 掌管时间线、范围、风险和合作伙伴协调 | 所有阶段 |
| 业务流程负责人 | 验证设计、测试场景、代表真实的工作流 | Explore 到 Deploy |
| 功能顾问 | 收集需求、配置模块、支持测试 | Explore 到 Deploy |
| 技术顾问 | 扩展、接口、系统设置 | Realize 到 Deploy |
| 集成负责人 | 中间件设计和跨系统的数据流 | Explore 到 Deploy |
| 数据迁移负责人 | 数据策略、清洗、加载、切换数据 | Prepare 到 Deploy |
| 变革和培训负责人 | 培训、沟通、采纳度衡量 | Explore 到 Run |
| 测试负责人 | 测试脚本、SIT、UAT、缺陷跟踪 | Realize 到 Deploy |
| 切换经理 | 生产切换、停机、回退计划 | Deploy |
| Clean Core 架构师（云版本） | 决定每个扩展放在哪里、处于哪个 Clean Core 等级 | Explore 到 Run |
| SAP 服务联系人（RISE） | 平台问题升级、服务评审、与 SAP 路线图对齐 | Prepare 到 Run |
我的 SAP 实施团队角色一文对每个角色有更详细的说明。
项目发起人
发起人的工作不是签完章程就消失。当项目经理之上没有人有权在各部门意见不一时做决定，项目就会停滞数月。发起人必须随时能找到、愿意做艰难的决定，并且在稳定期一直在场，而不只是在启动会上。
常见的问题：把一切都交给 IT 的发起人。ERP 改变的是业务的运行方式。如果领导层不推动，它就会失败。指导委员会指南讲了如何搭建发起人的议事平台。
项目经理
ERP 项目经理需要懂 SAP 或 Oracle 项目实际是怎么运作的，而不只是通用的 IT 项目管理。风险、依赖项，以及切换时的压力，都是不同的。
常见的问题：在范围上对顾问言听计从的项目经理，或者无法让业务方遵守测试截止日期的项目经理。
业务流程负责人
IT 不经营您的业务。运营、财务、采购和 HR 才经营。流程负责人确保系统对真实的流程管用，而不只是在纸面上。把他们排除在外，您得到的就是一套在研讨会上说得通、第一周就失效的配置。
从一开始就让他们参与，而不是在 UAT 时才让他们去批准自己从未参与过的决定。
ERP 顾问
好的顾问会提出异议。如果您的顾问对一切都表示同意、从不质疑任何需求，他们就是在计工时，而不是在贡献专业能力。最优秀的顾问，会在错误造成数月损失之前就把它们拦住。
弱顾问的一个迹象：他们过度定制，因为这比解释业务为什么应该改变某个流程更容易。每一个自定义程序都要维护、在升级时测试，并向下一个团队解释清楚。有了 SAP 的 Clean Core 等级，这种债务现在是可见的：用老办法构建的扩展会落在 C 级或 D 级，并在第一次重大升级时暴露出来。
数据迁移负责人
旧系统中的坏数据，会变成新系统中的坏数据。如果在迁移之前没有人负责数据质量这场对话，财务报表在第一天就会与现实不符。
数据迁移是一个需要业务方负责的业务流程。IT 可以移动数据。业务方必须确认数据是对的。
变革管理和培训负责人
变革管理不是培训。它是沟通、早期参与，以及在上线前在业务内部找到倡导者。当业务以为培训就够了，不信任新系统的用户就会回到他们的电子表格，而上线后再来修复代价高昂。
这位负责人应该在构建内容、开展试点和衡量就绪度，而不是在上线前两周发一份 PDF 了事。在 SAP 项目中，他们现在还要负责数字化采用工具：SAP 正把 SAP Enable Now 并入它在 2024 年收购的 WalkMe，所以新内容应该在 WalkMe 中规划。
Clean Core 架构师（云版本）
SAP 现在按四个 Clean Core 等级，从 A 到 D，给每个扩展评级。必须有人针对每个差距做出决定：它是在标准配置中解决，是作为 SAP BTP 上或通过 ABAP Cloud 在系统内的 A 级扩展来解决，还是根本不做。在大型项目上，这是一个专职角色。在中型市场项目上，通常由解决方案架构师兼任。
没有 SAP BTP 和 ABAP Cloud 经验的合作伙伴无法胜任这个角色。问问他们按这些规则交付过多少个扩展，并要求看看这些扩展。
SAP 服务联系人（RISE 项目）
在 RISE with SAP 下，SAP 运营着您系统的基础设施和运维，所以 SAP 是交付的一部分。CIO 需要一位指定的 SAP 联系人，处理平台问题升级、服务评审和路线图对齐。从 Prepare 阶段起，就把这个人放进团队名册，而不只是放进指导委员会的邀请名单。
我合作过的一家公司，同时在跑两个 ERP 实施项目。Oracle 项目有 4500 人，SAP 项目只有 38 人。一个系统顺利上线。另一个则是没完没了的灾难。差别就在团队。
团队规模应该与复杂度匹配，而不是与人数匹配。
| 公司类型 | 典型团队规模 | 复杂度来自哪里 |
|---|---|---|
| 小型（单一主体，500 名员工以下） | 10-25 | 主要是标准功能，集成很少 |
| 中型市场（多站点，500-5000 名员工） | 30-75 | 更多集成、区域流程变体、大规模变革 |
| 大型企业（全球，5000 名以上员工） | 100-500+ | 多个主体和集成，跨司法辖区的合规 |
一家运行复杂按订单生产制造的 50 人工厂，可能需要比一家运行标准零售流程的 500 人公司更大、更专业的团队。按需要完成的事情来定规模。我的 SAP 项目资源分配规划指南展示了如何制定这份计划。
Joule 现在已进入 SAP 的实施工具（SAP Cloud ALM 和 SAP Activate Roadmap Viewer）。SAP Build Code 使用 Joule 帮助开发人员在 SAP BTP 上构建扩展。Microsoft Copilot 起草状态报告、指导委员会简报和变革沟通材料。
持续使用的话，这些工具能加快重工作流的角色。它们让项目比几年前同样范围所需的规模略精简一些，但不会大幅缩小。
把这些工具写进角色定义里。功能顾问用 AI 起草需求和 Fit-Gap 文档的初稿。项目经理用它做状态汇报。开发人员在有帮助的地方使用它。AI 不会改变的是问责：它起草得更快，而草稿写了什么，仍由人负责。
大多数企业会把了解业务的内部核心团队，与带来技术和方法深度的合作伙伴结合起来。
内部团队必须真正参与，而不是出席状态会议。否则项目交付的，就是一套合作伙伴懂、而公司内部没人能运营的系统。
对合作伙伴的期望：结构、更快的决策，以及对您这类错误的经验。不要下放的：范围决策、流程设计签批和用户就绪度。这些需要内部负责人。
始终有效的模式是影子配对（shadow pairing）。每位顾问都有一位内部对口人，由这位对口人在上线后负责该领域。顾问负责交付，内部人员学习，顾问离开之后，知识留了下来。
筛选合作伙伴时，要求提供与您规模和行业相当的公司作为参考，而不是厂商的样板客户。询问 Clean Core 方面带示例的经验，以及他们如何在 RISE 项目中与 SAP 合作。含糊的回答会告诉您，谁是与时俱进的，谁在卖他们三年前所了解的那个版本的 SAP。
ERP 实施团队有多少人？
复杂度比公司规模更重要。流程简单的小企业通常需要 10-25 人，有多个站点的中型市场公司需要 30-75 人，全球性大型企业需要 100-500 人或更多。一家按订单设计生产流程复杂的制造商，所需的人手比一家运行标准零售职能的更大的公司更多。
云上的 SAP 项目需要哪些新的团队角色？
两个。一位 Clean Core 架构师或扩展负责人，决定每个扩展放在哪里、处于哪个 Clean Core 等级；在较小的项目上由解决方案架构师兼任。以及在 RISE with SAP 上，一位指定的 SAP 服务联系人，处理问题升级和服务评审，因为 SAP 运营着您系统的基础设施和运维。
项目发起人在 ERP 实施中的角色是什么？
发起人争取预算、清除障碍，并在各部门意见不一时做决定。他们在那里是为了让项目可管理，而不是去管理它。发起人做的最重要的事，是在稳定期保持参与。在切换后失去高管关注的项目，会形成持续多年的权宜做法。
为什么 ERP 实施需要业务流程负责人？
因为财务、运营、HR 和采购的人最清楚工作实际是怎么完成的。没有他们，团队设计出的系统在纸面上说得通，在实践中失效。从一开始就让他们参与研讨会和设计决策；到了 UAT，要改正错误的成本已经太高。
我该如何评价一位 ERP 顾问？
看他是否愿意提出异议。对一切都表示同意的顾问，是在让自己的日子好过，而不是让您的日子好过。好的顾问会质疑糟糕的需求、指出范围蔓延，并解释为什么标准通常比定制更适合您。然后再看他们带示例的 Clean Core 经验、您可以打电话核实的类似规模的客户参考，以及他们是在解决您的问题，还是在推销自己早已习惯交付的那种项目。
ERP 实施中如何处理数据迁移？
给它配一位专属负责人，负责策略、清洗规则、加载和上线验证。数据质量由业务方负责：IT 可以移动一条供应商记录，但只有业务方才知道它对不对。
ERP 项目中的变革管理是什么，为什么重要？
在上线之前、期间和之后，让人们为工作方式的重大变化做好准备。它涵盖沟通（尽早说明什么在变、为什么变）、参与（让关键用户参与设计和测试）和支持（帮助同事适应的倡导者）。把它当作培训日程表的项目，每次得到的结果都一样：权宜做法、电子表格，以及一个没人信任的系统。
作者
Noel D'Costa
SAP实施团队的关键角色与职责
多数SAP项目失败源于团队问题，而不是技术。本文列出每个项目都需要的八个角色，RISE和AI如何改变这些角色，不同规模企业的团队配置，以及如何在上线前建好卓越中心。
避免代价高昂失误的最佳 SAP 实施策略
SAP 实施很少是因为技术而失败。它们失败，是因为策略不适合业务，或者团队无法守住策略背后的纪律。
SAP 实施模板：分阶段指南
每个阶段真正重要的 SAP Activate 模板，从范围界定和 Fit-Gap 到切换和 Hypercare，附可直接套用的版式。跳过 Prepare 模板的团队，要在 Realize 阶段付出代价。
需求收集模板：我在项目中使用的 7 个实用技巧
需求收集模板只有在迫使大家尽早进行艰难对话时才有用。下面是我用的大纲、我从不跳过的五个部分，以及七个让干系人保持坦诚的技巧。
下一步
您现在正在推进ERP项目吗？
如果这篇文章谈到的正是您当前正在推进的项目，那么一次30分钟的交流，往往比再花一周做内部分析走得更远。