一个成功的SAP项目带来的幸福感是一样的，但是一个失败的SAP项目却各有各的不幸。吸取教训，避免重蹈覆辙是我们每个SAP人需要警醒的。我们来分析下造成SAP项目失败的要因：

• 企业不愿意改变现有业务流程

  畏难情绪是人之常情，对于诸多已经习惯现有流程几年甚至几十年的用户来说，改变是下意识的逃避。通常，总有人借口要保持事情简单使得实施可以又快又好。还有些情况下，是由于没有获得强有力的执行管理层的命令来作出决定，而同时项目中的人员又没有权利做决定。实际上，不想使用关于业务流程的SAP最佳实践只是导致SAP开发项目失败的一个最共通的原因，而希望顾问团队保留现有流程，造成过多的客制化开发。

• 对一般的变化缺少管理

    SAP实施将会改变很多人的工作任务。员工可能害怕他们目前的工作将变得多余，或者可能只是因为控制问题和其他原因而抵触变化。对组织内变化缺乏管理，可能创造一个消极的环境而导致项目屈服于政治。

• 不从错误中学习

  实施SAP是一个迭代的过程，因为即使在有限的现有流程内，实施各种系统架构，在各种开发和测试集团(client）上工作也都有改进的机会。实施SAP阶段性的方法（阶段指先开发，然后测试，最后培训等）使你可以从错误中学习以便每个新的实施阶段开始后不会重蹈覆辙。

• 忽视健全的技术变更控制实践

  采用科学的变更管理流程是常识，但是我们经常看到在上线前后都不采用科学的变更控制实践的后果。更多的SAP上线日期延期看起来都由这个“非最佳”实践引起。实际上，通常是某些对象在系统内变更之后马上传到生产系统。没有首先充分地在其他环境测试。变更控制需要成为一种习惯：没有这种习惯，它只能被当做一大堆恼人的流程和文书工作，直至非计划宕机事故的发生，变更管理的作用才会凸显。

• 缺少健全的项目管理

    尽管这可能被公认为是不应该的，但实际上这个问题很常见，为了实现健全的项目管理，首先，确保理解和记录理想状态的解决方案愿景，其次，遵循实践证明的SAP部署方法学，再次，保证实施的目标清晰并积极地设法完成，最后，聘请具有领导力、管理能力和出色的人员管理能力的项目经理。

• 过分依赖第三方顾问

  这是另外一个无需动脑的问题，但也是一个十分共通的进退两难的问题。项目拥有很多顾问不是问题（实际上这是规范），但是将所有机会都提供给顾问或者以牺牲企业员工（他们将在顾问离开后继续供职）的代价实施SAP都没有意义的，我们也看到了在很多项目里，第三方顾问公司员工占据了过多的关键角色或位置，这些人从SAP部署里学到的知识需要与客户团队分享，而不是隐藏起来带走，一方面要雇用优秀的人员从事项目，但是内部培训和知识转移同样重要，如果在企业内有空缺，尽量用你自己的人员去填补，避免造成项目结束人员离职，知识无法沉淀在企业内部。

• 培训不充分

   业务人员和工部门人员都应在工作中得到充分的培训，并作为最终阶段的一部分。所有的终端用户应该接受与他们新的角色有关的培训，并赋予适当的权限。

• 文档缺失

  如重新发明轮子一样，一遍又一遍地学习如何正确地做事是昂贵且可笑的，关于SAP实施中的所有描述流程，技术等配置、操作的相关文档对改进生产力大有帮助。然而缺少可靠的文档将置整个项目于危险之中。

• 缺少支持

  支持意味着不仅要获得管理层的认可，而且也要获得最终使用系统的最终用户的认可。

• 未能充分测试

    这个问题比大多数人认为的要常见。不要误解，组织的错误在于相信他们已经做了大量的测试，用户经常用以“测试“的名义所花费的时间来说事儿。但是这些数字未能反映出的事实是，这些失败的或延期的项目没有进行广泛的集成测试或者端到端的压力测试。

• 渐变的范围和“附加的”疯狂

    增加额外的华而不实的附属功能和其他的要求将项目拖延到远离最初设定的上线日期。对项目追加的东西不仅延长了配置和测试的时间，而且影响日常操作和将来的支持/维护。

• 上线后支持不充分

  管理和维护方面的系统问题注定会随着时间流逝导致系统性能低下，遭受过多宕机时间。

•  沟通不充分

    可能对任何企业级业务的IT项目，不仅仅是SAP项目，最重要的注意事项就是沟通。不能太频繁，但要保证项目相关方都达成共识，或者说基本面的共识。