SAP实施可能感觉是迈出了一大步，也许确实如此。但它不必让人感到仓促。我见过不少企业，在还没弄清自己要解决什么问题之前，就一头扎进选平台、比较部署模式、追逐功能清单之中。
目标不是做到完美，而是做到清晰。您的企业实际需要什么？您准备好接受多大的变革？如果事情没有按计划进行，会发生什么？
本页逐一介绍各个阶段，附上我针对每个阶段写过的所有指南，最后回答客户最常问的问题。
大多数团队首先关注软件。这可以理解。但SAP实施与企业每天如何运转的关系，比与底层系统的关系更大。
难的不是安装SAP，而是围绕真正需要改变的东西，让人员、时机和决策保持一致。项目正是在这里放慢，甚至停滞。
您现在不需要掌握所有答案。但把SAP实施看作工作方式的转变，而不是又一个IT项目，会很有帮助。
一览
战略准备
先了解业务，再谈软件：要解决的问题、成功的样子，以及标准与定制之间的界线。
规划与治理
尽早确定项目范围、部署模式和决策机制。
方案设计
Fit-to-Standard：让业务对齐SAP的流程，只在能创造价值的地方做开发。
数据与集成
决定迁移哪些数据并加以清理，设计SAP如何与其他所有系统连接。
构建、测试与培训
受控的开发、带退出标准的真实测试周期，以及使用真实数据的培训。
上线与Hypercare
有纪律的切换、快速修复问题的Hypercare团队，以及衡量业务成效的KPI。
阶段0：战略准备
在谈论模块或比较平台之前，先停下来。SAP实施始于了解您的业务：它今天如何运转，在哪里遇到困难，需要改变什么。之后的每一个决策都依赖于您在这里确定的内容。
聚焦三个问题。您要解决什么问题？成功应该是什么样子？您要在标准与定制之间的哪里划线？
需求收集不是一份功能清单，而是梳理您的业务今天如何运作、是什么在拖后腿。业务案例确定预期成果、ROI预期，以及六个月后您将如何为这笔投资辩护。干净核心（Clean Core）策略划定哪些要定制、哪些保持标准，并影响上线后的每一次升级。
阶段1：规划与治理
一旦知道自己为什么要做这件事，就把它转化为决策。清晰的决策，尽早做出。
把范围定具体。哪些业务单元上线，哪些流程暂时保持手工，哪些遗留系统保留？这里任何不清晰的地方都会在后面造成干扰，而事后清理的成本比一开始就做对要高。
选择Greenfield、Brownfield还是选择性迁移，不只是一个技术选择。它反映了企业准备好接受多大的变革，几十个设计决策都由此而来。然后成立指导委员会，明确升级路径，决定由谁对艰难的决定负责。在推进过程中持续更新业务案例。
阶段2：方案设计（Fit-to-Standard）
方案设计不是从零开始设计一切，而是弄清SAP已经提供了什么、您的业务真正需要什么，以及什么时候该对定制开发说不。Fit-to-Standard研讨会会逐一走查SAP的默认流程，让您决定哪里调整、哪里接受。
从三个方面入手。模块对应您的主要业务职能，如财务、销售、采购和制造。集成之所以重要，是因为SAP很少单独运行，它必须与CRM、供应商网络、报表工具和遗留系统对接。还有架构，要在企业成长的过程中保持干净、可升级、可支持。
阶段3：数据与集成
这个阶段常被低估，但它决定上线的成败。您可以拥有最好的模块和最干净的设计，但只要数据有问题，用户从第一天起就会感受到。
想清楚三件事。哪些数据值得迁移，哪些可以留下？您当前的数据到底有多干净？SAP将如何与现有工具和第三方平台连接？
数据迁移听起来简单，其实不然。项目会因为映射不当、源数据脏乱和临时的范围变更而延误。
阶段4：构建、测试与培训
这是SAP实施开始变得真实的阶段，没有结构的话，很快就会乱套。开发提速，传输请求快速流转。如果技术变更管理不清晰，变更会相互覆盖，团队也会搞不清哪些已经获批。
测试必须反映真实的业务活动：UAT、切换演练以及各种边缘情况。退出标准和质量关口能让所有人保持一致。
培训比大多数人预想的更重要，把它推到最后只会适得其反。用真实数据开展培训，让大家动手尝试，甚至犯错。信心就是这样建立起来的。
阶段5：上线与Hypercare
上线感觉像是终点线，但它恰恰是现实开始的地方。用户不再练习，而是开始依赖系统。我见过有的团队一天之内从平静陷入混乱，不是因为工作做错了，而是因为交接太松散。
切换意味着在一个紧凑的时间窗口内迁移数据、启用接口、冻结变更，并协调数百项细小任务。我见过的最好的切换，都有清晰的时间表、备用方案和演练。大家还需要知道在哪里登录、找谁求助、哪些东西可以动。
上线后的Hypercare是一个专注响应的小组，而不是延长的支持。让工单公开可见并快速修复，因为一旦用户早期失去信任，往往就不会再回来。然后衡量业务，而不只是系统：采用率、周期时间、错误趋势，以及报表和库存现在是否与财务对得上。
我写过的所有SAP实施指南，按它们帮助您做出的决策分组。请从每一行的第一个链接开始。
没有放之四海而皆准的公式。声称有的人，多半没真正做过。但无论是10个用户的项目，还是覆盖5个国家的全球推广，我反复看到的都是同样的六点。
- 明确的业务目标。“上线”不是目标。把订单处理时间缩短40%才是目标，从IT到运营的每个人都应该知道这个系统为什么重要。
- 高管赞助。 如果管理层没有明显地支持项目，大家都看得出来，势头会减弱，棘手的决定会被往下推。
- 有力的变革管理。 抵触很少是喧闹的。它体现在被用到一半的功能和影子电子表格里，所以要尽早开始，宁可多沟通。
- 务实的数据策略。 明确数据的归属，在上线之前清理，而不是之后。
- 业务内部的主导权。 不要把自己的头脑完全外包出去。您需要一个受信任、又有点倔强的人，在事情不对劲时敢于顶回去。
- 上线后的支持计划。 人们会犯错，功能也不总是按预期工作。支持就是生命线。
做对了，收获是实实在在的：销售、库存和财务共用一套数据，更严格的流程纪律，更清晰的审计轨迹，现金和订单的实时数据，以及无需推倒重来就能成长的空间。
我见过一些项目开局很强，到第六个月却停滞了，原因是数据不干净，或者没人能就审批该怎么运作达成一致。这很正常，而且如果及早留意，是可以避免的。
- 业务与IT不一致。 IT在推动敏捷，而业务部门想要万无一失的流程，这种脱节会成为持续的拖累。
- 复制旧系统。 把上一套ERP的每个界面和字段都重建一遍，会导致定制膨胀和推广缓慢。
- 数据准备不足。 重复记录、过时的编码和缺失的关联会在项目中途暴露出来，拖慢一切。
- 变革疲劳。 团队本来就要兼顾日常工作，没有变革管理，抵触是安静的，但真实存在。
- 没人对艰难的决定负责。 顾问可以指引，但如果内部没有人做决定，决策就会停滞，成本就会上升。
- 项目中途总会出状况。 一次重组、一位新任CFO或一次收购。灵活性和切合实际的时间表会有帮助。
要从Oracle或Microsoft迁移过来？这两种迁移我都帮团队做过。
借这次迁移重新思考流程，而不是照搬流程。先修复数据，合理界定集成范围，并给大家留出时间。从业务上的清晰入手，而不是从产品比较矩阵入手。
我在SAP实施和数字化转型领域已经工作了25年。有些项目我从第一天起就负责领导。另一些项目，我是在进度延误或愿景偏离现实之后才加入的。
我的工作始终不变：不讲行话，把企业的需要与SAP能切实交付的东西连接起来。您可以先从这些免费工具开始。
- SAP实施成本计算器：估算您的SAP实施大致成本。
- ERP实施成本计算器：快速了解ERP的成本和时间表。
- 数据迁移工作量与成本估算器：您需要的数据对象，以及迁移它们的成本。
- S/4HANA迁移评估：根据系统年限、数据和自定义代码，判断Greenfield、Brownfield还是选择性迁移。
- SAP解决方案构建器：按您的行业和规模给出模块范围和分阶段路线图。
- SAP岗位说明生成器：为SAP项目招聘时使用的岗位说明。
什么是SAP实施？
就是把SAP软件配置起来，以支持企业的运转，把采购、生产、人力资源等真实流程映射到系统中。它不止于技术配置，还涉及人员、数据、时间表，以及上线时一切如何连接在一起。
SAP实施需要多长时间？
从几个月到一两年不等。小型企业可能需要6到9个月。大型全球推广往往需要18个月或更长时间。
SAP实施的5个阶段是什么？
经典的五个阶段是项目准备、业务蓝图、实现、最终准备，以及上线与支持。有些企业会增加步骤或回到前面的阶段，这很常见。
SAP实施的三大支柱是什么？
人员（发起人、用户和管理层）、流程（SAP所要支持的工作流程）和技术（系统、集成和数据）。
SAP容易实施吗？
很少。技术只占一半。让人员保持一致、清理数据、管理变革，往往比软件更难，但有了正确的规划，是可以掌控的。
SAP代表什么？
Systems, Applications and Products in Data Processing（数据处理系统、应用与产品）。该公司于1970年代起源于德国，如今为全球许多最大的组织提供支撑。