编译者按：本文基于日文技术博客编译，旨在为中文读者系统介绍SAP项目实施中两种主流的团队组织模式——“模块切割”与“业务部门切割”，并深入分析其各自的优缺点、适用场景及潜在风险点，对于规划或参与SAP项目的管理人员与顾问具有重要参考价值。
SAP项目2024.02.05
深入解析SAP项目组织架构模式！
SAP项目中，每个项目的团队划分方式各不相同。
不同的团队划分方式各有其优缺点，最佳实践也随之变化。
本文将分享我迄今为止所经历过的几种组织架构模式。
目录
- 1 SAP项目组织架构——两种模式
- 2 模块切割
- 3 业务部门切割
- 4 （最后）无论何种架构，都要主动发现潜在问题点！
SAP项目组织架构——两种模式
SAP项目的组织架构主要分为两种模式。
- 模块切割
- 业务部门切割
模块切割是指按照SAP的模块来划分团队。但这其中也有几种不同的模式，稍后会详细说明。
业务部门切割是指根据引入SAP公司的部门设置，来划分实施方的团队。
模块切割
SAP的主要模块如下。
| 模块名称 | 简称 | 英文名 |
| 财务会计 | FI | FInancial Accounting |
| 管理会计 | CO | COntroling |
| 销售与分销 | SD | Sales and Distribution |
| 物料管理 | MM | Material Management |
| 生产计划 | PP | Production Planning and Control |
| 质量管理 | QM | Quality Management |
在大型项目中，有时会按模块划分团队，但为了防止出现“潜在问题点”，也常将多个模块合并为一个团队。
团队合并模式①
第一种模式是将FI/CO、SD/MM、PP/QM分别划分为一个团队。
对应的负责部门是：FI/CO对应财务部门，SD/MM对应负责订单处理的销售/采购部门，PP/QM对应制造部门。
在这种架构下，容易出现潜在问题点的地方如下：
- FI与SD/MM之间的债权/债务
- SD与PP之间的发货
- MM与PP之间的外包、盘点
- CO与PP之间的生产成本
团队合并模式②
第二种模式是为了不让“生产成本”这一SAP引入的最大优势兼最大难点成为潜在问题点，而将CO/PP设为一个团队的架构。
在这种情况下，FI将与总部财务对接，CO将与工厂财务对接。
在这种情况下，可能会出现CO侧需要对总部财务侧掌握的预算进行需求定义的情况。
- FI与CO之间的预算管理
应用负责人、会计/物流负责人的存在
在模块切割的情况下，有些项目会设置应用整体负责人或会计/物流负责人。
通过设置负责人，可以推动跨模块问题的解决和一致性协调，我认为这是SAP特有的、具有开创性的组织方式。
担任会计/物流负责人的人，通常需要拥有10年以上的SAP经验，并掌握多个模块的知识。
业务部门切割
近年来出现的是按照业务部门切割来组建项目团队的模式。
随着S/4 HANA的普及，在全球范围内引入SAP的案例也在增加，据说这种业务部门切割模式起源于欧美。
代表性的团队如下：
| 简称 | 正式名称 | 业务部门 | SAP模块 |
| RTR（R2R） | Record To Report | 财务 | FI/CO |
| OTC（O2C） | Order To Cash | 销售 | SD（仅限订单、开票） |
| PTP（P2P） | Procure To Pay | 采购 | MM（仅限采购、发票校验） |
| PTD（P2D） | Plan To Produce | 生产 | PP/QM |
| WTD（W2D） | Warehouse To Delivery | 物流 | SD（发货）、MM（库存） |
对于实施方来说，对接的部门基本固定，工作推进起来更加方便。
此外，对于全球性项目而言，跨多个部门的协调往往困难重重，因此这种架构也可以说是高效集中资源的一种方式。
但在采用这种架构时，有两点需要注意：
- 由于SD/MM被细分化，要避免产生潜在问题点。
- 虽然号称“Fit to Standard”，但因为是按业务部门切割而非按模块（系统）切割，要注意避免让系统去迁就业务。
注意事项① 避免产生潜在问题点
因为是按业务部门切割，所以每天面对的是相同的对接人。
如果是模块切割，会意识到“需要和其他部门的人开会讨论！”，引入方能够主动地去探讨部门间的业务衔接，而业务部门切割则使这一点变得困难。
特别是SD/MM被拆分到OTC/WTD/PTP中，因此任何项目中都可能存在“虽然是SD模块但不懂发货的OTC成员”或“虽然是MM模块但不懂库存管理的PTP成员”。
一旦出现潜在问题点，就可能导致正式上线延期或生产系统故障，因此主动发现并解决团队间的问题变得尤为重要。
注意事项② 避免让系统迁就业务
由于团队切割是基于业务部门设置的，对于旨在实现“Fit to Standard”的SAP引入项目而言，更加需要有意识地让业务去适配系统。
特别是在大企业，部门间的壁垒和摩擦或多或少都存在，因此“不懂的地方就在本部门内通过增强开发解决”的情况也屡见不鲜。
团队间的协作是必须的，通过团队间的沟通，可以更高效地探讨：
- 是否有SAP标准的跨模块联动功能可以应对？
- 增强开发是否可以共通化？
这被认为是更好的推进方式。
来源： Tokulog | 翻译： AI 自动编译 (历史归档)
(本文图片引用自原站，版权归原作者所有)