e-works数字化企业网  »  文章频道  »  管理信息化  »  流程管理(BPM)

BPM是与非?

2017/4/26    来源:和讯科技    作者:谭云杰      
关键字:BPM  
文章从BPM的基本概念出发,给出一些辨别和选择BPM产品的建议?希望能为BPM市场的进一步发展带来一点帮助?

    BPM(Business Process Management)方兴未艾,然而市场上BPM产品你方唱罢我上场,各色产品?各种概念粉墨登场?虽然百花齐放,但真正有志于实施BPM的客户却被这乱花迷了眼,实在搞不清楚BPM该怎么去做,最终失去对BPM的信心?这于BPM的发展并无益处?笔者于是撰写此文,从BPM的基本概念出发,给出一些辨别和选择BPM产品的建议?希望能为BPM市场的进一步发展带来一点帮助?

    现在一种普遍的理解,即把BPM理解为一个IT术语或一类IT产品,这是不全面的?在BPM中,业务应当占据主导地位,软件或者说技术占辅助地位?从业务角度说,完整的BPM应该覆盖企业战略管理?战略流程定义?业务构建?业务流程定义?业务服务定义和编排?业务执行和监控?业务流程优化改进以及战略调整等几乎企业管理的方方面面?从IT角度说,BPM所集成的一系列软件和专业技术要能够支持上述的业务生命周期落地?最重要的是,这些软件和专业技术必须是面向业务人员的,即要由业务来驱动BPM的建设,由业务人员来主导整个业务流程管理体系的建立,而不是由IT来驱动?

BPM市场和产品的混乱

    与其他革命性的IT变革一样,我们需要从方法?架构和实现技术三个方面去理解和掌握BPM产品?

    方法对应产品的设计目标企业的管理理论和相应的实施方法论,架构意味着对软件产品的设计如何匹配设计目标,实现技术则意味着采用何种IT技术去实现相应的设计目标?三者缺一不可,然而长久以来,人们习惯于用实现技术去分辨和解释BPM,以至于到现在为止,人们仍然无法正确理解BPM?由此也造成了BPM市场和产品的混乱?

    其实这个问题并不是BPM独有的?举例来说,笔者在培训面向对象的分析和设计方法时发现,相当大比例的程序员,即使他已经工作了很多年,即使他拥有丰富的项目经验,同时也精通一门或多门面向对象的语言,但实际上他们却没有真正地掌握面向对象的方法?掌握面向对象方法的关键不在于是否采用了面向对象的语言和工具(如UML),也不在于是否掌握了面向对象的编程技巧(如设计模式),而是从需求到分析设计,再到编码实现,你是否真的在用面向对象的思维去思考?

    SOA也面临同样的问题?是否掌握了SOA,其关键不在于是否采用了支持SOA的应用架构(如WebSphere Application Server),也不在于是否把某些代码逻辑封装成了符合SOA规范的服务(如Webservice),而是,你是否真的采用面向服务的方法去分析需求?设计架构?抽取服务,把业务服务化?从项目开始到结束的整个过程都应该是面向服务的,而不仅仅是针对产出物的?

    回到BPM产品上来,如果仅从实现技术去理解,人们就会陷入这样的混乱: BPM与工作流有什么差别?都有流程引擎,都可以自动化运行,都有流程编排器,也都能对流程进行监控?凭什么工作流就不是BPM?如果辩解说BPM比工作流能做更多的事,比如服务编排和集成,那么也可以辩解说只要是开放的通信标准,不论是WebService还是JMS,工作流同样可以集成第三方服务,BPM可以做的,工作流同样可以做到,无非只是技术实现的方式不一样而已,并没有本质的差别?你还可以争辩说BPM是面向业务的,而工作流不是,但你如何解释什么是业务?难道BPM里一个审批申请的活动是业务,工作流里一个审批申请活动就不是业务?什么道理?

    看,一旦陷入这样的技术细节比较,就是比上个三天三夜,吵个天翻地覆也不会有结果?

从方法和架构入手

    要辨别一个产品是否是BPM产品,我们还是得回到方法和架构上来?我们得承认这样一个事实:业务驱动架构,架构驱动技术,而不是相反?判断一个产品是不是真正的BPM,应该从源头往下看,看它的设计目的是不是为了解决业务流程管理,看它的架构是不是从业务流程管理方法论当中推导出来的,是不是符合业务流程管理方法规范,其针对的用户是不是业务用户?而不是看它是否包含了BPM的某些技术特征,也不是看它是不是能做到一些BPM声称应该做到的事情?

    一方面,技术的堆砌无法形成架构(技术架构必须指向特定的业务领域,解决特定的业务问题),拼凑出来的所谓架构也无法完整的解决业务问题?能够做到某些事情并不表示它就是解决这类问题的恰当的工具,比如,扳手和锤子都可以用来砸钉子,但扳手本身不是锤子,二者被设计服务于不同的业务领域?另一方面,同样的方法和架构允许不同的实现技术?例如,如果你的架构就是要解决砸钉子的业务问题,由于某种原因无法使用锤子,必要时,你可以把扳手集成进来,作为一种可能的实现技术?

    这有两层含义?其一,某种技术手段的加入不能决定或改变其所针对的业务领域,更不能改变其本质?上述例子中,扳手是为砸钉子设计的,其设计目标并不会因为产品具备了扳手的某些特征就变成了修水管的工具?因为扳手在这里明确地指向砸钉子的业务问题,产品会忽略掉其他与砸钉子无关的扳手的其他特征?其二,不能因为某项技术最终解决了某个业务问题,就认为该项技术就是针对该业务问题的正确工具?上述例子中,在解决砸钉子业务问题的工具里,扳手是一种可能的实现办法,但它仍然是扳手,不能够说因为扳手也可以砸钉子了,所以它就是锤子?

    我为何要如此纠结于一个产品到底是不是真正的BPM呢?只要能解决实际问题不就行了吗?我要如此较真的原因在于,业务驱动架构,架构驱动技术,这是一套符合科学方法的体系:首先提出问题,然后分析问题,最后解决问题?从方法到架构到实现,它是一套自洽的?能自我发展完善的体系?随着问题的深入和变化,整个体系也会随之修改或者进化,但始终是一套完整的处于相应理论指导下的体系,直到该问题不再有价值时被抛弃或者被另一套更好的体系或理论所替代?在整个产品生命周期中,其目标始终清晰?体系始终完整?进化始终有序?所以,如果它是真正的BPM,意味着该产品会随着整个BPM理论和体系进化,获得稳定的?可靠的升级和改进;如果它只是披着BPM的马甲,通过勉强的改造或挪用某些技术手段去解决BPM的问题,则意味着该产品无法针对业务流程解决方案提供有效和持久的改进?因为对一个软件来说,如果一个软件设计的最初目标与应用目标不符,而硬逼迫它往应用目标变更和定制,该软件必然变成打满补丁的袍子,总有一天它不但再也无法解决这些业务问题,恐怕连它的本职工作都无法再胜任了?

    是,还是不是BPM,真的是问题的关键!

责任编辑:程玥
本文来源于互联网,e-works本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供,并已尽力标明作者与出处,如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐