当前位置：首页> BPM-流程管理> 学习培训> 正文

鉴别BPM真品与赝品

来源：和讯网

2012/1/22 16:41:02

大中小

BPM(BusinessProcessManagement)方兴未艾，然而市场上BPM产品你方唱罢我上场，各色产品、各种概念粉墨登场。虽然百花齐放，但真正有志于实施BPM的客户却被这乱花迷了眼，实在搞不清楚BPM该怎么去做，最终失去对BPM的信心。这于BPM的发展并无益处。

分享到：新浪微博腾讯微博

本文关键字：

BPM(BusinessProcessManagement)方兴未艾，然而市场上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的应用架构(如WebSphereApplicationServer)，也不在于是否把某些代码逻辑封装成了符合SOA规范的服务(如Webservice)，而是，你是否真的采用面向服务的方法去分析需求、设计架构、抽取服务，把业务服务化。从项目开始到结束的整个过程都应该是面向服务的，而不仅仅是针对产出物的。

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

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

从方法和架构入手

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

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

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

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

是，还是不是BPM，真的是问题的关键！

BPM产品甄别标准

BPM的设计目标决定，BPM是一个IT工具，必须要和企业运营紧密结合在一起，是企业管理运营的直接映射。企业需要的是可以直接将业务变成可执行流程的技术，需要由业务人员直接建立、管理、优化流程，希望流程管理系统建设后可以直接在执行过程中监控企业绩效，更希望企业的战略意图可以直接与具体的执行层联系起来。

要满足这样的需求，BPM工具必须彻头彻尾地面向业务人员而不是IT人员，用业务语言去建模而不是IT语言，由业务人员驱动BPM的建设而不是IT驱动。换句话说，如果有一个所谓的BPM产品，它被设计为面向IT人员，靠IT人员定制开发而不是业务人员建模，它的设计无法对接企业战略和执行层面(是否对接战略和执行的简单判断标准是，是否能够说明和测量流程中的某一个活动针对哪个战略目标，某个实例贡献值如何)，它的设计是针对业务执行问题(需求从基层来)而不是业务管理本身问题(需求必须自顶向下)的，即可怀疑为伪BPM或说是不完整的BPM。最容易混淆的便是工作流与BPM、OA与BPM、 ERP与BPM。

非针对BPM的设计带来两个明显的局限，其一，系统的建立尽管使得工作效率有所提高，但对于衡量企业的整体绩效来说，这些系统内容是一个黑盒子，无法在执行过程中监控并得到企业整体绩效乃至战略的反馈；其二，由于架构和设计的方向不同，业务人员被排除在流程的建立、管理、监控、调整之外，必须通过IT人员来进行。这使得业务敏捷成了一句空话。

责编：罗信