- 实施从原型开始，在原型中已经实施了业务流程链，客户可以将其视为目标。同时，在项目期间可能必须消除差异。
- 为了进行该项目，创建了一个由顾问，业务和IT服务的客户代表组成的团队。客户代表在项目期间接受培训，并与顾问一起测试系统原型，制定系统要求并接受其实施。IT服务是一个积极的部分，它实现了一些需求，并在项目结束时获得了系统的支持。
- 在项目过程中，还将建立更多原型，每次迭代都将更加接近客户的需求。在项目过程中，对需求进行了指定和更改多次。
实际上，在一个大型ERP实施项目中，应用了敏捷性原则-人员和交互比流程更重要，工作产品比文档更重要，与客户的合作比合同更重要，并且与变更相关的准备比遵循初始计划更重要。
但是，在具有固定价格的已签订合同的条件下，在使用大型统一系统的情况下，需要遵循这些原则。没有附加条件和限制，该项目极有可能无法完成，而且肯定会超出预算。
首先，这不是像敏捷项目中经常出现的那样，可以分批开始的系统开发，因为每次迭代都必须以开发完整的功能块为结束以准备使用时结束。 ERP系统只能全部运行，而不能部分运行。
其次，如果您不限制需求，那么对它们的澄清和更改将是无穷无尽的，项目将耗时，并且需要额外的资金。
因此，第一个问题是ERP系统由紧密相连的零件组成，并渗透到端到端的流程中。因此，我们需要在每次迭代的所有范围内建立一个整体系统。该系统不是从头开始创建的，而是最终产品，这简化了该任务。通常，您可以使用具有标准流程的行业解决方案或预配置系统，将其用作第一个工作原型。
准备下一个原型需要时间。该系统庞大，复杂，有许多项目参与者，因此至少需要两个月的时间来准备原型，对其进行测试并形成评论。在我们的案例中，迭代不是像典型的敏捷那样的两周，而是2-5个月。
在每次迭代中，我们都会形成一个完整的系统，但是它们之间存在差异。在第一次迭代中，这是具有标准或特定于行业的流程的典型系统。标准流程可能与客户最终看到的结果相去甚远。顶层的过程是相同的，但细节会大不相同。当我说“客户”时，我的意思是将使用该系统的人-不管他与承包商之间是什么关系，都是合同的，或者是公司的内部项目，承包商可以是IT部门。
在根据第一个原型的测试结果收集需求之后，我们建立了第二个原型，在其中实现了所有可以通过设置实现的需求，加载了客户的测试数据，并解决了在第一个原型的测试过程中浮出水面的所有问题。客户遍历系统中的业务流程，检查当前实施适合的程度，系统的效率以及是否满足其要求。
在第二次迭代中，系统的未来用户不会第一次看到它，感觉更舒适，提出了已经更有意义和更详细的新要求。理想情况下，所有关键问题都应在此期间解决，因为随着发布时间的缩短，更改变得更加昂贵。
在第三次迭代中，我们已经有能力开始开发扩展，或者用术语来称呼系统的“定制”。这些可以是标准系统中不存在的报告，过程，表格，但它们是非常必要的，因为并非总是可以将业务流程调整为系统的标准。在考虑所有其他可能性之后，才决定进行扩展，因为他们的发展和支持是一种相当昂贵的享受，这是额外的钱。
我们正在准备第三个月的原型，以便使其成为接近目标的完整系统。通常，系统已完全配置，已加载大量数据，并安装了所有关键扩展。它的测试非常彻底，涉及到许多用户。该测试通常持续约一个月。
在测试了第三个原型之后，仍然存在评论和问题，我们在其上制定了开发计划。并且所有批评性言论都应通过发布消除。
到此时，项目的进度变得非常激烈，时间像战斗中一样被压缩。有必要准备说明，培训用户，转换数据，进行组织更改。以前尚未解决的问题浮出水面，有人记得他忘了宣布一些重要情况。在发布之前，还要进行验收测试，然后再启动新系统。
当然，这是对ERP系统实施的迭代方法的非常肤浅的描述。该方法详细描述了所有过程，包括文档，培训项目团队和用户，数据转换，组织变更等，这些过程实际上与任何其他项目管理方法没有区别。
出现一个合理的问题：如何以不进行第四次迭代，然后再进行第五次或第六次迭代的方式组织流程？您如何避免不受控制的变更和需求澄清的风险，这些风险会随着您对细节的深入研究（有时是由于业务变更）而自然发展？
当然，存在这种风险，并且它非常重要。在项目的入口处，需求是固定在合同中的，但是通常它们是用一般的方式制定的，而魔鬼在细节中。
在项目开始时采用“瀑布式”方法，要求是固定的，技术转让也已签署，这成为以后拒绝更改要求或要求额外资金进行更改的正式基础。在迭代方法中，此技巧不适用。
我们知道需求可能会发生变化，并且会不断变化。我们在时间和金钱上进行投资。问题是这些变化的程度。我们可能会犯一个大错误，并最终引起一波新评论，尤其是如果客户首先提到参与项目“溜溜”，选择了错误的人员参加，没有明确提出要求，希望“一切都会好起来”。依靠顾问-最后，我们遇到了严重的问题。
因此，减少项目结束时需求扩展风险的最重要的组成部分就是客户的参与。敏捷开发原则的完全相同的实施，根据该原则，团队从项目一开始就紧密联系，包括客户和开发人员。这有几个重要的后果。首先，及早发现实际需求和不符合系统的这些需求。其次，在准备系统的过程中，客户不是其所有者，而是在整个项目过程中逐渐以最终形式转让时成为所有者。这成为他工作的结果，到项目结束时，就不可能做出像“您的系统不起作用”这样的声明，因为这是他的系统。
将最有能力做出决定的最有才能的人100％地分配给项目是一个好习惯。在我们的实践中，这些人是业务流程的所有者，其代理人或享有服务经理完全信任的员工。是的，这很困难，是的-没有多余的人，是的-很难做到最好。但这是快速进行项目并获得高质量系统的唯一方法。项目参与者在理解企业的运作方式，获得新知识，学习以新方式工作方面取得了巨大飞跃，通常，这为他们创造了新的职业机会。您可以将ERP实施项目视为一项非常强大的人员发展活动，就像为经理创建新的人员储备一样。
要注意的第二件事是项目的时间紧迫。项目进度表应具有积极性，启动日期不应更改。如果项目范围很广，那么更改业务需求的可能性就会增加。如果项目日期改变了，就会出现新的需求，情况又会重演：系统还没有准备好，让我们推迟启动。即使使用非常长的项目期限，也无法实现系统的完美，并且在启动之前永远无法完全确定所有要求。只有真正的运作才能显示出所有瓶颈以及真正重要的内容。因此，启动后至少有三个月的稳定期，在此期间，项目团队将帮助和教育用户，更正错误，接受新要求并进行必要的改进。
为了抵制推迟截止日期和扩大需求的诱惑，每个人都必须有强烈的动机去满足这些截止日期。对于承包商来说，这些当然是合同义务和预算。客户的动力通常来自公司的管理层或股东的上方。例如，CEO做出启动准备就绪的决定可能会受到对股东的义务的束缚。项目经理和项目团队可以在截止日期的最后获得奖金，以激励他们。部门负责人将面临按企业命令启动的需求。
由于对它所提供的新机会的期望很高，因此迫切希望尽快启动该系统时，这种情况很少发生。新系统首先面临压力，并且需要从熟悉的界面过渡到最初不方便的界面，需要更多的控制权，再到需要输入更多信息的需求。最终用户几乎从不欢迎新系统。他们需要时间来达成协议并在其中找到优势。而且，如果最初并未将按时启动的内部动机纳入项目中，则启动将被推迟，因为系统永远不会100％准备就绪。
由于发布日期很紧，因此无法无休止地扩展和完善需求。面对不可避免的截止日期，包括客户代表在内的项目团队停止提名他们，并开始考虑优先事项，推迟某些事情的可能性。项目经理的任务是从项目一开始就形成一种缺乏时间的早期启动感觉。该项目上半场的气氛过于平静，这意味着由于不可避免的比赛，下半场将承受极大的压力。为此，必须设定中间目标，并以及时压缩项目的第一阶段的方式来制定项目进度表，因此，在启动前为最后阶段形成储备。长跑有不同的策略，但是这里的策略应该是相同的-您需要从一开始就快速运行，可能没有足够的力量来加速。
以上所有内容的摘要：
- 就系统与既定的和隐含的客户要求的接近程度而言，迭代方法可提供更好的结果。
- 为了实施这种方法，让客户完全参与项目是绝对必要的。
- 为了避免需求的激增和不断完善，必须严格限制项目时间表，并且必须激励项目参与者满足这些要求。
当然，这些只是基本原则，仍然有许多细微之处取决于具体条件，公司特征和参与者的个性。在每种情况下，一切都是单独决定的。