SAP 项目的资源分配规划

SAP 项目的资源分配规划，是指确定需要哪些角色、在 SAP Activate 的哪个阶段、每周投入多少小时，然后每周检查现实是否仍与计划相符。按角色配置人员，而不是笼统地按人头。让计划契合各阶段的曲线：Explore 阶段是功能顾问，Realize 阶段是技术人员，Deploy 阶段是数据、Basis 和变革管理。与直属经理以书面形式确认人员可用性。本指南写给正在制定或挽救 S/4HANA 资源计划的项目总监、PMO 和 CIO。下文的 FTE 表和日费率区间，可作为起步参考。

我见过几十个实施项目为同样的资源问题所困。计划假定了一种稳定状态，而一旦进入执行阶段，这种稳定就消失了。

我曾见过一个团队白白损失了整整一周，因为没人意识到安全负责人的休假和培训接连排在了一起。这件事没有被标出，也没有被跟踪，结果让一项关键的系统访问权限审查延误了九天。

大多数 SAP 计划依赖整齐的估算、全职投入的人员和可预测的工作流。这样的世界，很少能撑过 Realize 阶段的第一个月。

我围绕三件事做规划：工作实际需要什么，现有的人实际能交付什么，以及现实与计划不符时会发生什么变化。一份经得起检验的计划，涵盖六个维度：

1. 按 Activate 阶段、按角色划分的人数。 不是平均分摊。Explore 阶段和 Realize 阶段完全不同。
2. 由直属经理确认的每周工时。 要有书面确认，不能想当然。
3. 每个人同时承担的任务。 一个被列为 100% 投入、同时还要负责生产支持的人，交付的会少得多。
4. 关键路径上每个角色的后备人选。 在 18 个月的项目里，交叉培训不是可选项。
5. 跨工作组的依赖关系。 每一项都有明确的责任人、到期日和升级路径，一旦延误，当天就看得见。
6. 更新节奏。 积极阶段每周更新。启动会时的计划只是第一版。

计划出错，往往是因为规划者使用了笼统的 IT 角色。SAP 需要具体的功能和技术专长。S/4HANA 项目的标准配置如下：

项目领导层。 项目群经理、PMO 负责人和解决方案架构师。架构师对各模块之间的设计一致性负责。

功能顾问。 范围内每个模块一位负责人：财务会计（FI）、管理会计（CO）、物料管理（MM）、销售与分销（SD）、生产计划（PP）、扩展仓库管理（EWM），以及在范围内时的人力资本管理（HCM）、工厂维护（PM）和项目系统（PS）。如果您仍在运行经典的仓库管理（WM），请规划迁移：它在 S/4HANA 本地部署上的兼容包使用权已于 2025 年底结束。

技术顾问。 ABAP 开发人员负责报表、接口、转换、增强、表单和工作流（RICEFW），以及基于已发布 API 或 SAP BTP 的 Clean Core 扩展。集成专家负责 SAP Integration Suite（Cloud Integration，原 CPI）、仍在运行的 SAP Process Orchestration，以及任何第三方中间件。

平台。 Basis 顾问负责 HANA、内核补丁、传输、系统复制和性能调优。安全顾问负责角色设计、职责分离分析，以及在范围内时的 SAP GRC Access Control。

数据。 迁移专家使用 SAP S/4HANA Migration Cockpit 中的“Migrate Your Data”应用（旧的 LTMC 事务码已弃用），用 Migration Object Modeler 处理自定义对象，用 SAP Data Services 处理复杂的转换。我的指南SAP 数据迁移为何失败，以及如何补救解释了为什么这个团队需要比大多数计划所允许的更早启动。

变革。 变革负责人、培训负责人和业务就绪负责人。通常人手不足，因为这项需求要到 Deploy 阶段才显现出来。

客户方。 业务分析师（每个主要模块一位）、流程负责人（每个流程领域一位），以及从运营部门抽调、参加 UAT 的测试人员。

把这些角色当成可以互换的空位，是最常见的规划错误。资深 FI 顾问没法主持 SD 设计会议。初级 ABAP 开发人员没法设计集成架构。关于各角色的具体职责，请参阅我整理的SAP 实施团队的核心角色。

资源需求并不平稳。Activate 的各个阶段会形成可预测的曲线，平均分摊的做法会错过它。

Prepare（通常为第 1 至 4 周）。轻。项目群经理、架构师，以及每个模块一位负责人，用于界定范围。业务用户确认范围。Basis 和安全开始搭建环境。

Explore（通常为第 2 至 5 个月）。以功能顾问和业务用户为主，设计工作坊决定进度。在设计决策落定之前，ABAP 和集成的工作量不大。Basis 准备沙盒系统和质量系统。

Realize（通常为第 5 至 12 个月）。以技术人员为主：配置、开发、单元测试和集成测试。ABAP 工作量达到峰值。业务用户加入测试周期。数据团队构建迁移对象并进行预演。

Deploy（通常为第 12 至 14 个月）。以数据迁移、Basis、安全、变革和培训为主。UAT 占用业务方的精力。切换演练需要团队集中办公。上线后支持的规划启动。

Run（从第 14 个月起；上线后支持通常为 30 至 90 天）。核心团队精简，支持覆盖面重。Basis 和应用管理加大投入，顾问逐步撤出。

如果把这几个阶段当成同等的需求窗口，您就会在 Prepare 阶段人手过剩，在 Realize 阶段人手不足，到 Deploy 阶段数据迁移又会捉襟见肘。阶段曲线是计划中最重要的形状。

1. Prepare约 11 FTE第 1 至 4 周。负责人界定范围，Basis 搭建环境
2. Explore约 36 FTE第 2 至 5 个月。功能顾问和业务用户
3. Realize约 56 FTE，峰值第 5 至 12 个月。开发建设，ABAP 工作量达到峰值
4. Deploy约 42 FTE第 12 至 14 个月。数据、Basis、安全、变革
5. Run约 12 FTE第 14 个月起。上线后支持通常为 30 至 90 天

接连不断的紧急情况。 团队总在救火，说明计划已经不能预测现实。一个人缺席，不该就能让一个工作组出轨。

需要业务用户时，他们消失了。 设计会议和 UAT 因业务用户没空而停滞。这是导致延误最常见的原因之一。成因几乎总是一样的：这些时间只是被默认存在，并没有被正式承诺。只要承诺没有被正式确定，业务压力每一次都会占上风。

技术人员被摊得太薄。 Gerald Weinberg 关于软件管理的研究估算，一个人如果同时分身于三个项目，只能交付其总产能的约 60%，其余都消耗在切换上。美国心理学会对任务切换研究的总结报告了同一数量级的损失：在任务之间切换造成的短暂思维中断，可能吞掉多达 40% 的有效工作时间。计划看起来很高效。产出却并非如此。

关键路径每周都在变。 不断重新洗牌、工作组启动太晚、每周变换优先级，往往可以追溯到范围不清晰或依赖关系排序不当。先把范围定下来，再去调整资源计划。

1. 虚假的可用性。 某人被列为 100% 投入，却同时还要负责月结和生产支持。要问：每周多少小时，还在做哪些其他工作，直属经理是否已书面确认。
2. 共用角色没有边界。 一个人同时做方案设计、测试和变革管理。按任务而不是按头衔划分职责，并且永远不要让一个人同时在两个地方成为关键人物。
3. 缺少业务用户的时间。 工作坊延后，UAT 签字多拖几周。让时间承诺落到书面上，并由部门负责人签字，跟踪出勤情况，对反复出现的情况尽早升级。
4. 没有缓冲。 一个人缺席就让一个工作组停摆。缓冲要设在任务层面，而不只是阶段层面，并且为每个核心角色至少交叉培训一个人。
5. 计划从不更新。 启动时做好，之后从不修订。积极交付期间每周评审，与阶段关口挂钩，现实发生变化时就更新。

从已确认的可用性开始。 项目开始前就去找直属经理。确认每周工时和其他承诺，并形成文档。项目中途可用性发生变化时，这份基线就是您升级问题的依据。

按阶段塑造计划。 ABAP 开发人员在 Explore 阶段的负荷，与 Realize 阶段不同。业务用户的峰值出现在 Explore 阶段的设计，以及 Deploy 阶段的 UAT。平均分摊在纸面上看起来均衡，到了现场就行不通。

明确梳理依赖关系。 数据迁移支撑集成测试，集成测试支撑 UAT，UAT 决定切换。给每项依赖关系指定责任人、日期和标记，这样一旦延误，当天就看得见。

在指导委员会层面保护业务用户的时间。 他们的日常工作仍在继续。如果没有他们管理层就每周工时给出的明确签字，业务压力一来，他们就会放下这个项目。向部门负责人要这笔时间的，应当是项目发起人，而不是项目经理。

每周更新计划。 两周没动的计划大概率已经不对了。对比实际与计划的利用率。某人连续两周处于 120%，说明要么他超负荷了，要么计划错了。

以下是人数和费率的参考区间，可作为起步基准。行业、范围、地区和合作伙伴都会让它们发生变化。请把这些表格当作合理性检验，而不是报价。

中型企业棕地项目（500 万至 1,500 万美元，约 12 个月）

典型范围：单一法人实体或小型集团，三到四个模块（通常是 FI、CO、MM、SD），标准流程，定制开发有限。

工作组	Prepare	Explore	Realize	Deploy	Run
项目群经理	1	1	1	1	0.5
解决方案架构师	1	1	1	0.5	0
功能顾问（FI/CO、MM、SD 加一人）	1	4	4	2	1
ABAP 与技术	0	1	3	1	0.5
集成	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
安全与授权	0	0.5	1	1.5	0.5
数据迁移	0	1	2	3	0
测试负责人	0	0.5	1	1	0
变革与培训	0.5	1	1	2	0.5
客户方业务分析师	1	4	3	2	1
峰值 FTE 合计	5	14	20	17	5

企业级棕地项目（3,000 万至 8,000 万美元，15 至 18 个月）

典型范围：多个实体，六到九个模块，复杂的集成，相当规模的定制开发，以及多个国家的推广。

工作组	Prepare	Explore	Realize	Deploy	Run
项目群经理与 PMO	2	2	3	3	1
解决方案架构师（总架构师加模块架构师）	2	3	3	1.5	0.5
功能顾问（范围内所有模块）	2	10	12	5	2
ABAP 与技术	0	3	8	3	1
集成与中间件	0.5	2	5	2	1
Fiori 与 UI5	0	1	3	1	0.5
Basis	1	1	2	4	2
安全与 GRC	0.5	1.5	2	3	1
数据迁移	0	2	5	6	0.5
测试	0.5	1	3	4	0
变革与培训	1	2	3	5	1
客户方业务分析师	2	8	7	5	2
峰值 FTE 合计	11	36	56	42	12

各角色、各地区的日费率（2024 至 2025 年）

这些是合作伙伴对每位专家的计费费率，而不是薪资。项目的综合费率通常比在岸资深费率低 30% 至 50%，因为大多数项目会把在岸架构师与离岸交付混合使用。

角色	在岸（美国/英国/德国）	海湾国家（阿联酋/沙特）	近岸（拉美/东欧）	离岸（印度）
解决方案架构师（资深）	$2,000 至 $3,500	$1,500 至 $2,500	$900 至 $1,500	$500 至 $1,000
功能顾问（资深）	$1,500 至 $2,800	$1,200 至 $2,000	$700 至 $1,400	$300 至 $700
功能顾问（中级）	$1,000 至 $1,800	$800 至 $1,400	$500 至 $900	$200 至 $500
ABAP 与技术（资深）	$1,400 至 $2,500	$1,000 至 $1,800	$600 至 $1,200	$300 至 $700
集成专家	$1,500 至 $2,800	$1,100 至 $1,900	$700 至 $1,300	$350 至 $800
Basis	$1,400 至 $2,200	$1,000 至 $1,800	$600 至 $1,100	$300 至 $700
安全与 GRC	$1,500 至 $2,500	$1,100 至 $1,900	$700 至 $1,300	$350 至 $800
数据迁移	$1,300 至 $2,200	$1,000 至 $1,700	$600 至 $1,100	$300 至 $700
变革与培训负责人	$1,200 至 $2,000	$900 至 $1,500	$500 至 $1,000	$250 至 $600
初级顾问（任何角色）	$800 至 $1,400	$500 至 $900	$400 至 $700	$150 至 $350

在岸、近岸与离岸的配比

大多数 SAP 项目都会混合不同地区。这是成本与速度之间的取舍，而不是非此即彼。

美国私营部门的项目，按 FTE 计，通常在岸占 30% 至 60%。在岸力量集中在架构、变革、业务分析和资深功能岗位，这些岗位需要贴近业务。离岸力量集中在 ABAP、集成开发和数据迁移执行，这类工作更容易把需求说明清楚。美国联邦项目往往完全在岸，并有只能由美国籍人员参与的限制，具体取决于工作内容。

海湾国家的项目，在岸通常占 60% 至 70%，因为当地的雇佣规定和阿拉伯语要求把这个比例推高。离岸工作偏向南亚的中心，因为时区有重叠。欧洲的项目各不相同：制造业通常在岸占 50% 左右，而公共部门和受监管行业出于数据驻留的原因，比例更高。

一个常见的错误，是只按成本来优化配比。一个 80% 离岸、20% 在岸架构师的团队，在电子表格上看起来很便宜。隐藏的成本是每天的交接周期，以及缺少业务背景的设计工作坊推进更慢。最便宜的团队很少能交付出最便宜的项目。比较合作伙伴时，我的指南按层级划分的 SAP 实施合作伙伴讲了他们在费率和团队构成上有何不同。

一份做过一次就再不检验的计划，不算计划。把计划中的每一条假设都当作需要检验的假说，在执行的第一周检验，之后每周都检验。

SAP 项目中的资源分配规划是什么，为什么重要？

就是确定项目需要哪些人、什么时候需要、每人投入多少时间，然后跟踪这是否与现实相符。

SAP 项目依赖具体的某些人：了解您科目表的 FI/CO 负责人，熟悉您遗留数据的迁移专家，在业务部门里有人脉的变革负责人。当他们在关键时刻不在，工作就会停下来，或者被做错。许多看起来是技术问题的延误，其实是资源问题。

资源分配不当如何造成 SAP 项目延误？

通过依赖关系。Realize 阶段，一位配置负责人被调去做另一个项目。他的工作停滞，这会延误集成测试，再延误 UAT，再延误切换就绪。第 8 周出现的两周缺席，到上线时可能变成六周的延误。

早期的小缺口，到后期就成了大延误。等影响显现出来时，补救的代价是早期修正的数倍。

业务用户本职工作繁忙，如何让他们投入 SAP 项目？

项目开始前，就让他们的直属经理给出书面承诺：每周多少小时，哪些阶段最需要他们，以及可用性发生变化时需要什么样的批准。

像对待其他资源一样跟踪他们的出勤情况。出勤下降时，在指导委员会层面升级。部门负责人能够落实这项承诺；项目团队不能。

项目中途关键人员离职，该怎么处理？

首先要避免单点故障：每个关键工作组，至少要有另一个人理解到足以让它继续推进的程度。

有人离开时，立刻把他知道的东西记录下来：未成文的决策和配置背后的理由。这往往比找到替代者更难。补位方面，一份交接文档、录制好的会议和一周的重叠期，是最低要求。

资源问题应该什么时候升级？

比您觉得舒服的时候更早。当某位有名有姓的依赖关系负责人一周以上无法联系，某位业务用户总是缺席会议，某位技术资源连续两周利用率高于 120%，或者某个工作组因资源决策被搁置而受阻时，就该升级。

过早升级的代价是一次尴尬的谈话。过晚升级的代价是几周的延误。

跨多个项目共用的资源应该怎么处理？

假定共用的人在压力来临时会优先处理别的事情。与他们的主要经理约定具体的每周工时，在依赖他们的工作中留出缓冲，除非您有后备方案，否则不要让他们出现在您的关键路径上。

对于共用的业务用户，请求必须由项目发起人来提。项目经理向部门负责人要时间，每一次都会输给运营上的优先事项。