当前位置:cio技术探讨 → 正文

为erp实施规模化敏捷的六大难题 -凯发在线

责任编辑:cres 作者:john belden |来源:企业网d1net  2020-10-19 10:09:08 原创文章 企业网d1net

克服下述难题是将敏捷用于erp实施的关键。为此一切努力都是值得的。
 
根据it标准,敏捷方法已经存在了很长时间,事实证明,许多公司通过该方法取得了成效。随着公司在敏捷方法的开拓阶段不断发展和进步,这方面的付出也呈现了与日俱增的趋势。敏捷的应用甚至在支持erp的部署方面也取得了进展(众所周知,这些项目非常复杂,需要做大量集成工作)。但是,对敏捷方法小试牛刀所获得的收益并没有自然而然地转移到大刀阔虎的敏捷项目中。
 
经过研究发现,我们必须克服六个难题才能高效地为erp实施敏捷方法并解决这些难题。
 
1. 关键决策治理
 
实施成功的敏捷项目需要一个重要因素,那就是小而忠诚的团队,这个团队由技术娴熟的成员组成,他们可以在整个项目中做出关键决策。随着项目规模的扩大,跨团队的决策量会增加,“难以定义且杂乱无章(wicked messy)”的决策的数量也会随之增加。这些决定往往会涉及到成功的组织和失败的组织。当有更多团队参与且涉及到各种成果时,确保所有团队意见一致则更为困难,更为耗时。
 
利益相关者的范围也扩大了,这进一步延长了达成共识所需的时间。敏捷的心态不利于做出大型的,跨职能的决策,因此,随着项目规模的扩大,这变得更为困难。
 
为了解决这一问题,发布管理工程师(release train engineer)必须对关键决策,早期和频繁的社交活动承担充分的责任并制定决策策略,从而能及时作出关键决策。
 
2. 积压事项管理
 
在规模化的敏捷项目中管理积压事项比在小型开发项目中管理积压事项要困难得多,因为积压事项包括许多与软件开发并不直接相关的活动(即数据团队支持,培训支持,部署活动等)。
 
管理集成测试也可能十分困难,因为许多erp测试需要多个团队的参与。积压事项管理的复杂性还体现在另一方面,即其中的许多项目并不受某个人的影响(在erp中尤其如此),而且是其他团队直接提出的要求。这两个方面对产品负责人提出了更高的要求,他们必须了解整个程序的范围,从而高效地整理轻重缓急得到妥善安排并与其他团队同步进行的积压事项。
 
为了解决此问题,必须在程序开发初期开发端到端的测试策略。一旦制定此策略,产品所有者就可以更好地了解必须优先处理的积压事项的依赖关系和先例。
 
3. 与scrum团队保持同步和一致
 
敏捷项目在很大程度上取决于跨scrum团队的速度校准。当所有团队之间的沟通和绩效都不一致时,你最终将导致资源团队闲置。所有团队都必须以相同的完成度同时完成任务。
 
为了实现这一目标,所有成员必须完全接受敏捷思想并在团队之间明确定义“完成度”。以不同的完成度定义进行操作的团队可能会延长端到端测试所需的时间。
 
为了实现这种一致性,发布管理工程师必须执行两项关键职能:
 
1. 确认人们已经发现跨团队的依赖关系并将其记作单个团队的积压事项和冲刺计划的一部分工作内容。
 
2. 监控速度并根据需要调整冲刺团队的能力,从而使团队的交付与预期的交付日期保持一致。
 
4. 整合兼职和共享资源
 
尽管全职成员会全身性投入项目,但他们可能必须在多个团队中分享其时间。是否能高效分配时间将取决于他们是否能与项目中其他团队的进度保持一致。
 
scrum团队没有参与的兼职资源也必须得到管理。例如,负责评估的人可能只将10%的时间用于整个敏捷项目。项目经理必须帮忙协调时间,从而确保他们在需要做评估时可以灵活地参与敏捷项目。
 
资源预测是解决这一问题的优秀工具。发布管理工程师(release train engineer)必须在整个计划中维持完整的资源需求预测并定期更新所有供需领域。而产品负责人将受到外部资源提供商的青睐,其方法是管理积压订单,从而与需求预测保持一致。
 
5. 实施大型项目所需的作风
 
为了使项目不落后,高层通常会参与正式的阶段关卡评估(stage gate review),他们还要支持审查的内容。大型项目通常需要更多的输出和文档工作才能获得评估委员会成员的全面支持。实施敏捷方法将遇到一个困境,这就是在整个项目中加大对增量开发的关注并在总体上减少对文档工作的关注。这使团队难以在董事会级别上提供支出和风险管理方面的透明度。
 
为了解决这个问题,我们建议产品负责人制定初步的高管介绍,然后在每次冲刺结束时更新此材料,以此作为回顾的一部分内容。董事会和高管的演讲不应该只是一个活动,而应该是实现当前状态并预测未来状态。
 
6.供应商的责任和绩效
 
在敏捷项目中,定义公司与供应商之间的风险分担是更加困难的工作。大型计划的合同通常以瀑布式或可交付成果为基础,而赏罚措施会驱动成本和进度的绩效,这使公司可以要求供应商对全面交付承担责任。相反,当范围可变时,敏捷方法假定成本和时间是固定的。这种情况与标准的理念相悖,即erp的大部分范围都不灵活。这种情况将问题复杂化的其中一个方面是定义和解决保修支持的概念。这是项目中的所有人(无论他们在客户端还是在供应商端),每个冲刺都必须对“完成”持相同的定义。
 
近年来,新的合同组织形式纷纷出现,这种形式的重点是在实现特定定义时采用激励和惩罚的定义。正在考虑用规模化敏捷方法解决erp问题的团队必须寻找该领域的专家来了解这些新形式。
 
凯发在线的版权声明:本文为企业网d1net编译,转载需注明出处为:企业网d1net,如果不注明出处,企业网d1net将保留追究其法律责任的权利。

关键字:凯发在线凯发在线

原创文章 企业网d1net

x 为erp实施规模化敏捷的六大难题 扫一扫
分享本文到朋友圈
凯发在线
当前位置:cio技术探讨 → 正文

责任编辑:cres 作者:john belden |来源:企业网d1net  2020-10-19 10:09:08 原创文章 企业网d1net

克服下述难题是将敏捷用于erp实施的关键。为此一切努力都是值得的。
 
根据it标准,敏捷方法已经存在了很长时间,事实证明,许多公司通过该方法取得了成效。随着公司在敏捷方法的开拓阶段不断发展和进步,这方面的付出也呈现了与日俱增的趋势。敏捷的应用甚至在支持erp的部署方面也取得了进展(众所周知,这些项目非常复杂,需要做大量集成工作)。但是,对敏捷方法小试牛刀所获得的收益并没有自然而然地转移到大刀阔虎的敏捷项目中。
 
经过研究发现,我们必须克服六个难题才能高效地为erp实施敏捷方法并解决这些难题。
 
1. 关键决策治理
 
实施成功的敏捷项目需要一个重要因素,那就是小而忠诚的团队,这个团队由技术娴熟的成员组成,他们可以在整个项目中做出关键决策。随着项目规模的扩大,跨团队的决策量会增加,“难以定义且杂乱无章(wicked messy)”的决策的数量也会随之增加。这些决定往往会涉及到成功的组织和失败的组织。当有更多团队参与且涉及到各种成果时,确保所有团队意见一致则更为困难,更为耗时。
 
利益相关者的范围也扩大了,这进一步延长了达成共识所需的时间。敏捷的心态不利于做出大型的,跨职能的决策,因此,随着项目规模的扩大,这变得更为困难。
 
为了解决这一问题,发布管理工程师(release train engineer)必须对关键决策,早期和频繁的社交活动承担充分的责任并制定决策策略,从而能及时作出关键决策。
 
2. 积压事项管理
 
在规模化的敏捷项目中管理积压事项比在小型开发项目中管理积压事项要困难得多,因为积压事项包括许多与软件开发并不直接相关的活动(即数据团队支持,培训支持,部署活动等)。
 
管理集成测试也可能十分困难,因为许多erp测试需要多个团队的参与。积压事项管理的复杂性还体现在另一方面,即其中的许多项目并不受某个人的影响(在erp中尤其如此),而且是其他团队直接提出的要求。这两个方面对产品负责人提出了更高的要求,他们必须了解整个程序的范围,从而高效地整理轻重缓急得到妥善安排并与其他团队同步进行的积压事项。
 
为了解决此问题,必须在程序开发初期开发端到端的测试策略。一旦制定此策略,产品所有者就可以更好地了解必须优先处理的积压事项的依赖关系和先例。
 
3. 与scrum团队保持同步和一致
 
敏捷项目在很大程度上取决于跨scrum团队的速度校准。当所有团队之间的沟通和绩效都不一致时,你最终将导致资源团队闲置。所有团队都必须以相同的完成度同时完成任务。
 
为了实现这一目标,所有成员必须完全接受敏捷思想并在团队之间明确定义“完成度”。以不同的完成度定义进行操作的团队可能会延长端到端测试所需的时间。
 
为了实现这种一致性,发布管理工程师必须执行两项关键职能:
 
1. 确认人们已经发现跨团队的依赖关系并将其记作单个团队的积压事项和冲刺计划的一部分工作内容。
 
2. 监控速度并根据需要调整冲刺团队的能力,从而使团队的交付与预期的交付日期保持一致。
 
4. 整合兼职和共享资源
 
尽管全职成员会全身性投入项目,但他们可能必须在多个团队中分享其时间。是否能高效分配时间将取决于他们是否能与项目中其他团队的进度保持一致。
 
scrum团队没有参与的兼职资源也必须得到管理。例如,负责评估的人可能只将10%的时间用于整个敏捷项目。项目经理必须帮忙协调时间,从而确保他们在需要做评估时可以灵活地参与敏捷项目。
 
资源预测是解决这一问题的优秀工具。发布管理工程师(release train engineer)必须在整个计划中维持完整的资源需求预测并定期更新所有供需领域。而产品负责人将受到外部资源提供商的青睐,其方法是管理积压订单,从而与需求预测保持一致。
 
5. 实施大型项目所需的作风
 
为了使项目不落后,高层通常会参与正式的阶段关卡评估(stage gate review),他们还要支持审查的内容。大型项目通常需要更多的输出和文档工作才能获得评估委员会成员的全面支持。实施敏捷方法将遇到一个困境,这就是在整个项目中加大对增量开发的关注并在总体上减少对文档工作的关注。这使团队难以在董事会级别上提供支出和风险管理方面的透明度。
 
为了解决这个问题,我们建议产品负责人制定初步的高管介绍,然后在每次冲刺结束时更新此材料,以此作为回顾的一部分内容。董事会和高管的演讲不应该只是一个活动,而应该是实现当前状态并预测未来状态。
 
6.供应商的责任和绩效
 
在敏捷项目中,定义公司与供应商之间的风险分担是更加困难的工作。大型计划的合同通常以瀑布式或可交付成果为基础,而赏罚措施会驱动成本和进度的绩效,这使公司可以要求供应商对全面交付承担责任。相反,当范围可变时,敏捷方法假定成本和时间是固定的。这种情况与标准的理念相悖,即erp的大部分范围都不灵活。这种情况将问题复杂化的其中一个方面是定义和解决保修支持的概念。这是项目中的所有人(无论他们在客户端还是在供应商端),每个冲刺都必须对“完成”持相同的定义。
 
近年来,新的合同组织形式纷纷出现,这种形式的重点是在实现特定定义时采用激励和惩罚的定义。正在考虑用规模化敏捷方法解决erp问题的团队必须寻找该领域的专家来了解这些新形式。
 
凯发在线的版权声明:本文为企业网d1net编译,转载需注明出处为:企业网d1net,如果不注明出处,企业网d1net将保留追究其法律责任的权利。

关键字:凯发在线凯发在线

原创文章 企业网d1net

回到顶部
"));
"));

关于凯发在线联系凯发在线隐私条款广告服务凯发在线的友情链接投稿中心凯发在线的招贤纳士

企业网凯发在线的版权所有 ©2010-2024

^
网站地图