控制迭代过程 防止业务流程管理失败

CIOAge
在二十世纪初期,迭代过程被采纳为业务流程管理(BPM)的一个中心原则,BPM本身是从业务再造中发展而来。大概在同一时间,IT重新设计了原型模型,而这一次,将其作为设计和解决方案的“迭代”嵌入到敏捷软件开发方法中。

在20世纪90年代后期,IT发现了原型概念,并将其应用于应用开发。原型模型是迭代过程的前身——小规模设计和构建,在组件中快速完成,然后测试和调整组件。和现今的迭代方法一样,这个前身是一个好主意,但实际上并不奏效。调整通常需要比预期更长的时间,业务用户经常失去耐心,这一概念从未被广泛接受。

[[199829]]

在二十世纪初期,迭代过程被采纳为业务流程管理(BPM)的一个中心原则,BPM本身是从业务再造中发展而来。大概在同一时间,IT重新设计了原型模型,而这一次,将其作为设计和解决方案的“迭代”嵌入到敏捷软件开发方法中。

所以,再一次的,我们使迭代成为一个主流过程,并再次获得各种结果。

在我们进一步讨论之前,我想清楚地说明我是迭代方法的支持者——我只是希望它能正常工作,真正有帮助。

但实际上,根据历史,迭代过程有好有坏。

让我们先来讨论一下缺点,最后以优点结束。

迭代过程中的问题

有一个谬见,认为迭代可以使项目更早完成。我,以及很多专业人士都没听说过迭代确实节省时间的项目。(当然,肯定有人可以证明迭代可以节省时间,但我并不认识。)我知道有评价团体赞扬了敏捷方法,然而,迭代,却被报告有难以置信的70%的项目失败率,BPM相关项目则更高。值得注意的是,很多这些项目最终都取得了成功,一旦它们完成了永无止境的设计、构建、评估和重新设计的迭代工作。

那么在迭代过程中,我们需要怎样做,才能缩小谬见与现实之间的差距呢?我们首先来讨论我亲身经历过的几个迭代现实。

无休止:迭代可以不断进行,不断扩展解决方案的设计和构建,远远超出预期。在迭代中,并不是为了第一次就让新的设计起作用——目标是快速,并且“灵活”,然后通过多次迭代进行改进。对于更倾向于分析的管理者,解决方案总是可以更好,永远没有尽头。在这种情况下,管理者认为下一次迭代会比这一次更好。

风险增加:每当团队创建新的迭代模型时,必须对其进行全面重新检查——如果没有,交付有问题的产品的风险,随着每个模型而增加。这再次延长了构建解决方案所需的时间。这是一种反复试验的方法,最终会带来一个很好的解决方案,但它可能不是最有效的方法。

中断:在某一截点,宣布成功,并安装解决方案。但迭代过程还在继续,因为已经安装的可能并不完整。这会导致业务中断,因为部分解决方案或者不同版本不断实施,再次发生改变。

混乱:经过几次解决方案的迭代,没有一个员工知道他们应该做什么或应该怎么做。最后的结果就是业务人员和经理的沮丧。

用模拟控制迭代次数

迭代是一个很好的概念,当被正确使用和控制时,可以很好地起作用。

对于一些CIO和应用开发领导者来说,这种“正确的方式”需要将业务和IT BPM相关的概念,方法和技术相结合,来最好地解决每个问题。 然而,在将BPM方法(通常是瀑布型方法)和IT BPM方法(通常是基于敏捷的方法)相结合时,关键是设置机制来控制迭代次数,以及每次迭代的预期。

在这部分讨论中,我假设应用解决方案开发团队能够创建满足业务和技术需求的应用。这个假设意味着应用将提供所需的服务。这并不意味着应用解决方案的运行完全顺利,或者如预期般有效。这也不意味着应用解决方案是灵活的或完整的。也不意味着应用解决方案消除了复杂性。

但这些需要迭代的问题可以有效地处理。在IT BPM和业务BPM方面,我建议团队考虑使用模拟建模来评估每个迭代设计。模拟工具将指出瓶颈,解决方案在不同工作负载下如何工作,以及设计中的许多其他问题。

使用模拟结果,重点关注设计改进,团队不断优化设计。这样,改进评估是基于严格的模拟效率评估,而不是“让我们试试,来看看结果。”最终,迭代次数受到控制,需要的次数更少。同时,这种方法也产生了更好的业务设计。

让迭代过程更顺利

当交付目标产品或服务的概率很高时,当模拟和财务评估表明业务的工作流程和其他方面最优时,说明新的业务流程模型,是起作用的。将现有的状态模拟结果与新的解决方案的运营模拟相比较时,团队还能够预测项目效益——使用新运营(工作流程)时,通过新设计,消除业务问题可以节省的成本,通过消除或减少错误可以节省的成本。

一旦业务流程模型在使用模拟工具时,可以证明有效和高效,那么这些应用可以由BPM套件(BPMS)工具生成。假设使用BPMS工具,可以生成“straw man”版本的应用。

此外,使用传统测试技术,“stub”来测试应用,模拟将数据传递给另一个应用,和“驱动程序”来模拟解决方案系统从其他应用接收数据的情况,可以进一步优化模型和解决方案设计,以确保支持计算机应用的工作流程和运营,可以完成目标结果。

在BPM项目中应该考虑stub和驱动类型的迭代——特别是那些由BPMS工具支持的项目。至于业务设计迭代过程,stub和驱动类型迭代必须计划和仔细的控制。此外,业务设计迭代,当正确管理时,该项目测试和修改周期可以带来更好的结果。

总而言之,控制迭代的这两个方法,消除了业务流程开发中的许多固有问题,让团队可以更快地创建更好的结果。

责任编辑:赵宁宁 来源: TechTarget中国
相关推荐

2011-05-18 11:34:54

云端业务流程管理

2022-06-23 14:12:06

业务流程管理应用软件工具

2020-06-19 12:23:05

CIO数据分析技术

2017-05-16 10:46:06

博阳咨询流程管理

2021-05-06 17:22:22

区块链加密货币技术

2010-06-29 15:45:57

UML业务流程

2013-11-06 14:15:11

流程

2020-01-19 20:07:32

物联网大数据IOT

2010-02-04 13:57:19

ibmdwWebsphere

2023-01-04 13:41:23

RPA自动化机器人

2014-07-16 11:24:56

甲骨文业务流程管理BPM

2023-11-30 15:17:21

人工智能业务流程

2012-12-03 13:50:40

IBMdW

2023-10-17 13:35:00

数字化转型供应商

2013-11-06 14:16:23

流程

2020-05-06 10:07:15

价值流图VSM可视化图形

2010-05-20 11:20:36

TIBCO事件驱动

2014-09-09 09:54:57

炎黄盈动BPM

2010-08-11 00:59:17

BPMOracleSOA

51CTO技术栈公众号