Computer Weekly 十一月 3 日的一篇文章报导，美国军方计划在其ERP 系统实施中采用开放标准和敏捷实践，因为目前的供应商实施受阻。这篇文章提到：
“近10 年来，美国军方跟随千禧年以来在公共计算领域的趋势，通过集中采购开展了雄心勃勃的计划，用全新的、全方位的企业资源计划（ERP）软件替代数百个业务系统。
然后他们和ERP 趋势一样，超期数年并超出预算数十亿美元。
现在国防部宣布将采用敏捷方法，使用开放标准并拥抱语义网络。”
Elizabeth McGrath，国防部代理首席管理官，在她给美国众议院的证词中说到：
“在【企业业务架构】的下一次发布中，我们将会采用开放标准和协议，作为开发架构，同时采用语义网络技术，通用业务流程建模方法，和敏捷开发方法。”
ERP 实施的失败在信息科技领域內得到公认并被记载。CIO 杂志 2009 年发表了一篇文章《 10 大 ERP 系统实施失败案例》。英国Computer World UK 杂志也发表了ERP 实施失败案例的清单。这些都指向了实施ERP 系统的难度。但是美国军方使用敏捷实践作为此问题的解决方案是有先例可寻还只是痴心妄想？
Guerilla Project Management 博客上有一些关于在 ERP 实施中采用敏捷实践这一主题的讨论。根据案例分析，通过使用敏捷实践，在一次 SAP 系统实施中，实现提前交付。
根据上述案例学习中对 Genesis 咨询公司 CEO Jason Fair 的录音采访：
“……我们实际花在增加客户价值的活动上的时间很少。”
Jason 估计在传统的瀑布流程下实施 ERP，他们在增加客户价值的活动上花的时间不超过 5-10%。如果将这个比例提高到 20%，他们就能够显著的为客户提升价值。
Agile Scout 对 Bluefin 的 Mike Curl 进行专访，Bluefin 专注于 SAP 实现。他提供了一份在 ERP 实施中应用敏捷的实践列表。
选择一个合适的项目作为第一次尝试，和一个信任的业务客户合作，尝试解决真正的问题，并挑战时间压力。
-
不要只是把一群人凑在一起然后开始“做事”。你需要解决真正的问题和真正的业务需要，授权给 Product Owner 。
-
仔细考虑你需要多少个 SCRUM 团队，和每个团队资源组合。随着 SCRUM 团队数量的增长，合作、沟通的复杂性增加，并导致冲突的风险升高。
-
你无法期待项目团队一夜之间适应新方法。培训，教育和指导是必要的，因为需要一些重要的变更管理来证明（敏捷实践的）好处并克服那些伴随敏捷的冷嘲热讽。
-
敏捷世界适合于拥有数量少、但更熟练的资深成员，对 SAP 世界来说也是如此。敏捷团队成员需要能够思考、设计、开发、解决问题、测试和沟通，通常是同时进行！能力欠缺的成员很快就会显现出来并成为团队的瓶颈。
-
交付压力是常见的、也是无情的。保持团队专注和在长期的项目中的积极性是真正的挑战。
-
事情会出问题。你需要务实和适应。如果互相指责的文化开始蔓延，应该快速的平息，否则会伤害氛围并导致避免风险的行为。
-
使用某种形式的微博客，这样每个人在任何时候都知道你在做什么。这有助于防止误解，促进良好沟通，并能够节省时间。
-
回归测试的概念不容易与敏捷方法论配合，因为此时开发即将结束。当你在实施关键的 SAP 系统时，回归测试是唯一的方法来保证“可工作的软件”不会变为不能运行的软件。
-
当同时采用几个组件和技术时，团队倾向找到“最薄弱的环节”并把未能交付或延误交付归咎于此。这是一个辄代解决的组织文化问题——项目是整体成功或失败，而非单独的部分。
-
支持模式和组织的影响不能事后才想到。将一些功能投入到生产系统，然后立即专注于下一个迭代不太可能赢得项目，或者让敏捷方法广为接受。
然而，网上也存在关于在 ERP 实施中采用敏捷时间的争论。下面是 http://www.focus.com 上一些专家的讨论。
敏捷方法可以适用于大型和复杂的 ERP 系统实施。典型的 ERP 系统实施采用瀑布方法或供应商、实施者的专有方法论，这些方法都有如需求、蓝图、构建、测试、培训和部署几个阶段。
敏捷方法论专注于在称之为 sprints 的短时间间隔（通常是 2 至 4 周）內，通过与客户紧密合作，而交付特定可衡量的结果。
客户乐于使用敏捷方法论在项目期间获得更高的可视性。
现在，在 ERP 中采用敏捷实践需要为下面的事情制定初始计划：
- 将整个项目范围分解为（较小的）可交付物，以适用于 sprint
- 让客户来管理各个 sprint 的 backlog
- 有效的按需为每个 sprint 分配资源
最重要的是让有 ERP 背景的 PM 接受敏捷方法论的培训。
我愿意应对任何在 ERP 中使用敏捷方法中遇到挑战。
Bill Wood 持有不同的看法：
针对这里提出的几点，根据“敏捷宣言”定义的“敏捷”，对大型 ERP 项目来说是完全彻头彻尾的灾难。
就像已经提过的，大型的、互联的、集成的、互相依赖的软件项目如果没有采用仔细考虑的、结构化的方法是几乎不可能的。
然而，话说回来，现在任何事都被称为“敏捷”。包括与“敏捷宣言”要求背道而驰的传统项目管理方法。
因此，作为原始含义的“敏捷”对 ERP 项目来说是彻头彻尾的灾难。但被某些人称为“敏捷”的传统项目管理方法是可行的。
-------------------
作为敏捷方法对于 ERP 项目是个灾难的实际证明，我在 SAP ERP 领域工作。SAP 在上世纪 90 年代早期和中期出现过不断的失败、持续超出预算、并麻烦重重的项目。他们立即着手创建了一个专门的、有步骤的方法论来解决这个问题。这就是 ASAP 方法论，目前仍在使用。
此后，数以万计的项目，严格的说是这个方法论，被证实 是绝对必要的。
但是，ASAP 方法论与“敏捷宣言”描述的基本项目原则相冲突。
美国军方在 ERP 实施上的新方向是否成功尚未可知。但是，商业世界已经厌倦了 ERP 项目的失败，并不断探索新方法。那么你是如何看待的呢？敏捷方法能拯救那些面临 ERP 灾难的公司吗？
评论