本博客讨论了实施SAP云项目的常见陷阱，特别是当大多数合作伙伴和客户团队都来自于使用瀑布模型在内部部署环境中实施SAP时。

对于许多在内部部署环境中开始SAP之旅的现有SAP顾问来说，这可能是一条陡峭的学习曲线。我想在这个博客里分享我在实施SAP云项目时所学到的经验和教训，大数据趋势，并希望听到来自世界各地的经验。

我还要感谢我的同事Davinder Sandhu和Manish Bhalla为这个博客所做的贡献。

1.项目方法和方法实施

问题：在大多数项目中，您可能会根据销售宣传和高水平的商业案例从不同的供应商处购买云产品。组织通常会触发采购团队，以确定和选择系统实施合作伙伴或咨询合作伙伴来实施解决方案。

SI合作伙伴中标后，客户可能会倾向于签署"大爆炸实施"方法，以转移内部部署或遗留问题SAP云跨多个市场的系统解决方案，在不检查售前宣传和实际情况是否匹配的情况下停用现有系统。

建议：我建议客户与其SI合作伙伴合作，规划分阶段实施的方法，使用如下所示的MVP模型或全球模板模型。

组织可以利用知识和经验，为单一市场进入云计算，并对云解决方案是否适合他们进行"深入研究"，而不必将自己锁定在昂贵的长期合同中。

这也将有助于组织通过评估第一个市场的SAAS产品的定制，并估计您需要为其他市场进行的定制，来决定移动到云计算是否是一个可靠的解决方案。如果需要进行高度定制，那么在投入大量投资之前，它可以帮助您重新评估SAAS产品是否适合您的组织。

在开始项目之前，运行以下SAP Activate加速器非常有用：

云思维评估.xlsx（SAP客户）云思维评估_外部.pptx（SAP客户）

了解组织的成熟度水平。在项目启动期间，它将有助于设定正确的期望，并教育企业"云项目如何工作"。

问题：如果客户使用"大爆炸"而不是MVP方法来处理SAP云项目，或者SI合作伙伴/客户构建高度定制的云解决方案（通常是复制内部部署或遗留问题）设计），方法论将成为瀑布和敏捷的混合袋，即脆弱的。

无一例外，试图利用"两者最佳"的方法，最终导致客户和合作伙伴在使用什么的问题上发生冲突，而这两种方法都不能正确应用。这对我来说是一个危险的红色信号，你没有正确地接近这个云实现！不管你遵循的是敏捷模型还是瀑布模型，你都需要正确理解项目的模型、里程碑和质量关卡。

建议：SAP提供了一个名为SAP Activate的框架。这包含了避免这种危险情况的最佳实践和加速器，因此，我建议你们都要学习S/4 HANA或C/4 HANA的开发方法、预定义的最佳实践和研讨会模板，或者基于项目或计划启动期间尝试实施的行业解决方案的成功因素阶段

要了解SAP如何为开始数字化转型的组织配置自己的最小可行产品（MVP），请查看SAP的模型公司服务产品。它们是为满足MVP时间框架而设计的预配置MVP。

问题：我参与过一些客户定制云解决方案以匹配其内部系统解决方案的项目，因为云转型项目只是被视为IT系统升级作为业务目标和质量关口没有在整个组织内明确定义和沟通。

由于定制的复杂性，项目采用了脆弱的方法，它既没有瀑布式方法中通常具有的里程碑和质量门，也没有阶段门/展示和讲述或记分卡或故事点估计或定义良好的用户您通常在敏捷项目中使用的验收标准。

在这类项目中实现投资回报率和衡量项目成功与否变得越来越困难，因为云解决方案的固有好处（自动升级、最小化升级的回归影响、降低运营成本、，资本支出与运营成本之比等）可以通过复杂的系统定制来抵消。

建议：这听起来可能有点官僚主义，但我始终建议，企业应用平台，在项目启动期间，我们应明确定义并向整个团队传达计划的业务愿景和目标，以确保他们了解IT计划应提供哪些内容来实现业务目标。

SAP Activate提供了一个良好的起点，有如QGateChecklist Concept SAP Activate（Public）和Business Definition Templates（Public）以及Phase Sign Off Template（SAP Customer）和Business Case Template（SAP Customer），以支持您完成该流程。

下表可作为指导方针，设置对项目治理的正确期望，并定义正确的成功衡量标准基于您选择的方法论。

问题：50%的SAP云项目将数据和集成团队视为"局外人"，不会将他们包括在Sprint中，因为Sprint通常不会在2周内完成。这背后的一般原因是，由于文档质量差，或者可能由于外包给了小众SI合作伙伴或第三方供应商，因此需要花费大量时间来理解现有接口和遗留数据模型。