SAP实施与推广：差异，以及何时选哪种

SAP实施，是在没有系统的地方把系统建起来。推广，则是把集团内某处已经在运行的SAP系统扩展到新的国家、实体或业务单元。很多人以为推广只是缩小版的实施。在这类项目里，这个想法造成的返工比任何技术决策都多。

我曾经让一位CFO相信，区域性的SAP推广是即插即用的。我解释了风险，但没有坚持。我们用的是全球模板，他认为每个地点都会顺利跟上，不需要太多力气。事情并非如此。一个区域需要额外的税务处理。另一个区域因为当地法律，要求必填的员工数据字段。看起来是复制粘贴的活儿，实际上需要真正的定制。

所以，这个选择会改变您配置资源、编制预算和推进工作的方式。选错了，系统也许照样能上线，只是不会按您原先的计划上线。

实施从零开始。您要界定范围、梳理流程、配置系统、迁移数据、搭建集成。它适用于尚未使用SAP的组织，或者要彻底替换旧系统的组织。

推广复用一套已经行之有效的设计：流程、配置、主数据标准。要做的工作，是模板与新地点实际需要之间的差距。税务、法定报告、币种、语言、本地集成，以及将要使用系统的人。

1. 05本地用户按本地流程调整的培训，使用本地语言
2. 04本地集成新国家的银行、税务申报和物流系统
3. 03本地数据客户、供应商和物料数据，映射到全球标准
4. 02本地要求税务、法定报告和必填字段。只算要求，不算偏好
5. 01全球模板已经行之有效的流程、配置和主数据标准

两者在实践中的对比如下：

方面	SAP实施	SAP推广
起点	没有SAP，或者要替换的旧系统	SAP已在总部或其他实体运行
设计	全新设计，Fit-to-Standard	全球模板，本地偏离受控
典型周期	12至24个月，大型集团更长	每个地点6至12个月
主要风险	每个工作流都有未知数	本地化和本地准备度
数据	从旧系统全量加载	本地数据映射到全球主数据标准
测试	完整周期：单元测试、集成测试、UAT、性能测试	本地化、本地接口、UAT
变革管理	从零开始的完整项目	已有材料按本地团队调整

下面这些情况适合做实施：

1. 组织从未使用过SAP。
2. 现有系统已经难以为继，需要整体替换。
3. 并购或新的运营模式，使旧设计不再适用。
4. 首次引入行业解决方案，例如SAP for Utilities或SAP for Public Sector。
5. 没有任何现有模板能覆盖您需要的范围。

实施耗时更长，前期成本更高。您得到的是一套与业务相匹配的设计，以及一个理解每项选择背后原因的团队。赶着走完需求阶段的公司，事后纠错要多花30%至50%。这样的事我见过一次又一次。

推广适用的前提是：SAP已在集团内某处运行良好，核心流程稳定，模板足够灵活，能容纳本地要求而不至于散架。这三条里只要有一条不牢靠，就先修好模板，再往任何地方推广。

技术部分通常能按时完成。延误来自人，也来自在新国家不成立的假设。

模板被强加给本地团队

在北美行得通的做法，到了亚洲或中东可能就不够用。税务结构、审批流程和数据录入规则各不相同。我曾和一家公司合作，他们以为自己的欧洲模板在中东也能用。结果是延误、重写和不少摩擦。两地的业务流程差别实在太大。

解决办法是给新地点指定一位有决策权的业务负责人。总部团队为自己并不了解的地方决定流程，做出来的设计一接触本地用户就会失败。

本地化问题到测试才发现

税务处理、法定报告和必填数据字段，必须在设计开始之前确认。我曾支持过一位客户，一个很简单的税务配置差异，就让他们的上线推迟了一个多月。问题不在技术，而是没有人及早验证本地需求。

对不上的主数据

产品编码、客户编号和供应商分类必须与全球标准一致。上线后才发现的不一致，修起来代价高昂，还会破坏合并报表。要在设计阶段就把本地数据映射到全球模型，而不是等到UAT。

培训讲的是全球系统，不是本地系统

推广往往直接沿用最初实施时的培训。那些材料讲的是系统在总部如何运作，没有讲本地做了哪些调整。用户不明白自己用的版本为什么不同，就会自己想办法绕过去。

上面的框架依然成立。变的是模板的部署模式，它会改变部分成本结构和扩展规则。

在RISE with SAP（私有版）上，每增加一个国家，就是在按完整用户当量（FUE）计价的订阅里增加用户。成本可预测，基础设施工作也更少。但上线之后，这笔费用还会持续发生，所以要比较多年的总成本，而不只是第一年。

在GROW with SAP（公有版）上，首先要查清SAP是否为该国提供本地版本。截至2024年2月，SAP列出了59个国家和地区的本地版本。对于其他国家，SAP的“本地化自助服务”计划允许合作伙伴使用Configuration Localization Tool构建客户自己的本地版本，目前通过早期采用者通道提供（SAP Learning）。两者都不适用的话，您面对的是范围界定问题，而不是推广问题。

Clean Core适用于每一项本地偏离。 公有版只接受通过已发布接口进行的扩展。在私有版上，这是一项治理选择，但您允许的每一处本地修改，都意味着每次升级时多一个要重新测试的对象，再乘以国家的数量。我坚持的原则很简单：税法、法定报告和监管要求，足以成为偏离的理由。本地偏好不行。

在敲定下一个国家的上线日期之前，下面每一项都要拿到肯定的答复。每一项都有负责人。

1. 当地业务负责人（新国家）：已任命，有权批准本地设计。
2. 税务和法律顾问：税务、法定报告和必填数据字段，在设计开始前已整理成文。
3. 模板负责人（总部）：列出拟议的偏离项，每项都标明是要求还是偏好。
4. 数据负责人：本地的客户、供应商和物料数据，已映射到全球标准。
5. 集成负责人：必须对接的本地系统，例如银行、税务申报或物流系统，已识别并界定范围。
6. 变革负责人：培训已按本地流程调整，使用本地语言，配有本地案例。
7. 项目总监：一次只推进一个地点，并把上一次上线的经验用到下一次。

我的范围模板指南能帮您处理第3项，项目章程指南则讲了如何把决策权限写下来。

埃及的全新实施：一家总部设在埃及的区域制造企业，被陈旧、互不相通的系统和大量手工操作拖住。供应链、生产跟踪和财务报告彼此不通。他们从零开始实施SAP S/4HANA，把财务、采购和生产连接在同一个系统里。他们建立了自动化的供应链计划，并在上线前培训了四个国家的5,000多名员工。他们没有赶进度。运营成本降低了25%，预测误差减少了35%。

向15个市场推广：一家零售公司的总部已经运行SAP S/4HANA，现在需要把它推到15个新市场。每个市场的税务规则、币种和商业习惯都不同。他们从全球模板出发，按地点调整，分阶段用两年时间推广而不是一次铺开，并为每个区域设计了培训。结果是财务合并更快，各门店的库存实现实时跟踪，集团层面的报告准确度提高了20%。

一个是在建一套原本不存在的东西。另一个是在扩展一套已经行之有效的东西。两者都不是即插即用。如果您正处在第一种情形的起点，我写的如何正确启动SAP实施指南就是最好的开始。

SAP实施和SAP推广有什么区别？

实施是从零建设SAP：需求、流程设计、配置、数据迁移、集成、测试和上线。推广是把已有的SAP系统及其全球模板扩展到新的国家、实体或业务单元。推广的工作，就是模板与本地需求之间的差距：税务、法定报告、语言、本地集成和培训。

公司什么时候应该选实施而不是推广？

没有可供扩展的SAP，或者要整体替换旧系统时，选实施。业务模式变化大到现有设计不再适用，或者没有模板能覆盖所需范围时，实施也是更好的路径。硬把不合适的模板推出去，造成的返工比重新做一套干净的设计更多。

SAP推广比实施要花多长时间？

实施通常需要12至24个月，大型集团更长。推广通常每个地点需要6至12个月，取决于本地化、集成和数据。最大的变数，是在设计开始之前，本地要求验证得有多充分。

多国SAP推广最大的挑战是什么？

有四个问题反复出现。模板没有征求本地团队意见就强加给他们。本地化要求到测试阶段才发现。主数据与全球标准对不上。培训讲的是全球系统，而不是本地系统。大多数是人和计划上的问题，而不是技术问题。

SAP推广一定比完整实施便宜吗？

通常是，因为设计已经存在，而且经过验证。如果某个国家的税务或薪资规则复杂、需要多个本地集成，或者数据质量差，节省的幅度就会缩小。在RISE with SAP下，每个新国家的订阅费在上线后会持续发生，所以要比较多年的成本。

全球模板在SAP推广中是怎么运作的？

全球模板是集团标准流程的、有文档记录并已配置好的SAP设计。每一次推广都从它出发，只增加真正必需的本地变更。每一项偏离都会在每次升级时带来维护负担，所以要加以管控：税法这样的要求足以成为偏离的理由，偏好则不行。