最近在LinkedIn上,有一个讨论组在探讨为什么大多数BPM项目失败了?来自各行各业的从业人员带来了自己的实战经验。BPM项目失败的原因有很多,也有很多是个案原因,无法抽取出共性的内容,但是ForresterVP兼研究总监ConnieMoore的看法却得到了多数人的认可。
在开始研究为什么BPM项目失败了之前,我们也要问一句“谁说这个项目失败了呢?”其实很多“谣言”是来自于一些老旧的业务流程重组(BPR),因为一次性集成的项目会由于自身过于庞大而导致整个项目分崩离析,注定要失败。换句话说,很多BPM项目并没有完全失败。BPM项目的展开更像是一种旅程,很多企业的BPM理解度都不够成熟。企业有时候要花费很长的时间才能到达成熟阶段,所以他们要实现单独的项目,但是有限的效率换回来的并不一定能命中业完全命中业务绩效的要害。
那么BPM项目失败的原因究竟是什么呢?其实有一些问题是清晰的。企业花费很多时间(大概两到三年的时间)来模型化其流程,这样的过程对于一个想要成功的项目来说已经很长了,这些确定后再来实现流程模型,咨询比较BPM套件厂商,做自定制的代码。自定制代码又要花上两年的时间,厂商在这个过程中会获得不小的财富。这也许有些危言耸听,但是经历过这些的企业的BPM项目难免会失败了。
企业最初应用BPM的初衷也比较简单,因为他们正在经历一些流程痛点,像不能交付期望的业务价值;花费了太长时间来完成这个项目;或者由于这个项目是个孤立的东西,提供的价值有限等。下面是对于ConnieMoore提出的BPM项目陷入僵局的原因的总结:
(1)不知道从何开始。很难知道流程开始的最佳范围,如果判断不准确,就会陷入僵局中。Connie建议在确定最终期限(业务转型)之前,要明确战略目标和流程技能是BPM成熟声明周期的一部分。
(2)建模过程时间过长。这个问题比较老,但是很多项目团队都全神贯注于建模,但Connie建议几周内实现就可以了。因为BPM是一个持续改进的过程。一旦流程正常运转,还可以经常按需增量式的进行改变,可以每三到六个月发布一次新的流程版本。在这个上花费太多时间就会忽视掉BPM的最大价值,那就是持续改进。
(3)IT来推动项目。很多企业中IT理解潜在的BPM内容,IT专业人士迫切地希望业务人员也能了解,在从业务端尝试购买失败后,一些IT领导者就会想在IT内部来驱动整件事情。而这条路简直太难了。
(4)没有一个强有力的流程改进方法。我们知道业务流程改进是一种规则,而不仅仅是技术。这个规则就是以持续流程改进为基础。目前很多成功的企业经常会报道说他们拥有自主开发的的精益+六西格玛的组合。
(5)变革管理。因为这个是任何BPM项目中摆在第一位的问题。大家都不想改变,而BPM需要企业不同层面都要做出一些改变。目前很多团队都纠结于此,因为他们不知道怎么办,也不知道该向谁求助。Connie给出的秘诀就是:企业的变革管理专家很可能就在HR中。让他们参与进来,对BPM项目将会有很大帮助。
事实上,还有很多问题会导致BPM项目陷入困境,但我们也看到一些最佳实践已经出现,比如方正飞鸿,是中国领先的BPM业务流程管理及解决方案提供商,推进整个行业的发展。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
在iBPM和BPM间做选择 不一定非此即彼
大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。
-
用BPM策略对遗留应用现代化
一些人提议把业务流程管理作为应用现代化的手段之一,但也有人对此提出质疑,但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。
-
RESTful API设计给开发人员带来怎样的未来?
在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。
-
如何用可行敏捷BPM工具增加灵活性
通常,企业架构师致力于业务流程管理,以理解为了改进业务流程并确保其遵从GRC授权的复杂工作流程。BPM套件(BPMS)保证能建立可实行的业务流程。