如今，敏捷软件开发已成为流行语。许多人将这种形式的软件开发和部署视为大型，缓慢，昂贵且有风险的ERP实施的 传闻，这些实施吓坏了许多高管。
就像行业中大肆宣传的流行语和所谓的“银子弹”一样，敏捷并不是每种数字转换策略的答案。尽管瀑布方法在某些情况下适用，但在其他情况下则不适用，但敏捷也是如此。
首先，了解瀑布和敏捷之间的区别很重要。瀑布式方法需要更传统的顺序开发方法，在需求，设计，开发，测试和上线之间具有明确的里程碑。下一个阶段仅在上一个阶段完成时才开始。
另一方面，敏捷方法论则涉及更多的迭代方法。设计，开发，测试和培训在定义每批需求时进行。例如，在定义不同需求之前，敏捷方法将等待开发，测试和推出，而不是等待整个解决方案设计完成才进行开发。
那么，哪个适合您的组织？就像许多有关数字转换和ERP系统的决定一样：这一切都取决于。它取决于需要事先定义的许多决策点。
以下是一些问题，可帮助您为项目定义最佳方法：
通常快速且敏捷的组织可能会从敏捷方法中受益。初创企业，快速成长的组织以及其他重视速度，规模和效率的公司更可能从敏捷中受益。在这些情况下，事情变化太快以至于无法支持瀑布式方法，而瀑布式方法更适合静态操作模型。
另一方面，达到规模，规模和可预测性的特定点的公司通常会从瀑布式方法中受益更多。在这些情况下，创造运营效率和扩展规模是重中之重，而不是速度。在这里，更重要的是预先明确定义整个解决方案，而不是逐步地逐步推出更改。
一些组织从根本上破坏了业务流程和系统，或者他们有机会更好地整合其端到端价值链。在这些情况下，进行业务流程再造和业务流程管理 活动以明确定义“将要”的业务流程是很重要的。这些需求指向了一种更传统的瀑布方法。
但是，如果您是一个具有明确定义的流程和系统的组织，那么敏捷方法可能对您更有意义。这些情况提供了一定的灵活性，可以在解决方案推出时定义流程改进，这比瀑布式情况更是如此。
那些已经或者正在试图成为集中化的公司倾向于采用瀑布式开发模型。在大多数情况下，这些组织都试图在各个位置和业务部门中创建标准化的运营模型。瀑布方法的前期业务流程和系统设计可实现这种集中化。
另一方面，分散的或很大程度上独立运营的组织通常会发现敏捷方法更适合其需求。在这里，更有条理和有序的开发方法是无益的，但更多的迭代和快节奏的更改是有好处的。
概括地说，如果没有瀑布式方法，则很难进行企业范围的数字转换。这些转换的价值在于跨功能集成的水平，这需要大量的前期设计和规划。在这些情况下，设计这些解决方案所需的时间可能比某些人希望的要长，但是如果正确完成，项目的这些早期阶段可以在以后节省大量时间和金钱。
如果您的计划更孤立于组织的较小部分，那么敏捷可能更适合。例如，如果您要推出CRM软件 并将其使用范围限制在销售团队中，则可能需要以更具迭代性的方式进行更改，而不是先设计整个解决方案。在此示例中，实现快速获胜可能比完美更重要。
任何数字化转型都会带来变化疲劳。员工倾向于抵制任何形式的变更，但是您对敏捷还是瀑布的决定将极大地影响变更的幅度以及员工如何接收这些变更。瀑布式实施往往涉及较少的频率，但是规模变化较大，而敏捷的实施通常需要更频繁，更增量的变化。
无论哪种情况，您都只是在将一种风险换成另一种风险。因此，查看您的文化和您的员工来确定哪个会更好会很有帮助。员工会更愿意接受一波大的变革吗？还是您认为通过不断进行不断的渐进式变革，他们会做得更好？无论哪种情况，有效的组织变更管理策略 对于您的成功都是至关重要的。
上述问题没有正确或错误的答案-当然也没有万能的灵丹妙药。重要的是确定对您的组织最有意义的因素，然后制定实施策略并制定相应的计划。
客服毛燕