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，真的是问题的关键!

　　BPM产品甄别标准

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

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

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

　　总结下来，辨别一个产品是否是真正的BPM产品，可以从以下几个关键特征出发：

　　1.该产品是否具有极强的导向性，面向价值增值(战略目标)而非仅仅实现当前业务。

　　此特征意味着每个业务流程和每个活动都可以明确地指出其针对的战略目标，并可以用指标衡量其价值贡献(相对于战略目标)。BPM的建设成功与否可以用企业最为熟悉的商业价值评估体系来评判并优化调整。

　　如果一个所谓BPM产品不能够直接实时地提供业务执行时对战略目标的贡献值，仅能够提供IT级别的运行测量结果，或者只能通过滞后的报表统计，再通过诸如BI工具等来估算业务效益。它将无法支持BPM的价值。

　　2.该产品是否以端到端的业务流程为中心而非仅仅用于实现局部业务。

　　此特征意味着流程梳理是BPM建设的前提条件。BPM实施的同时必然带有流程梳理、测量、优化或改造等活动，基于片断化的、局限于部门内部的所谓BPM建设难以获得BPM带来的价值。

　　如果一个所谓的BPM产品从建模到实施到管理，仅需要或仅支持局部的业务需求，在必要时，只能通过其他技术手段(如WebService、JMS、Rest)来与其他部门或系统做散列的点状集成，而不是像真正的BPM那样需要端到端的流程梳理结果作为必要条件，在建模过程中没有所谓的“与其他集成”的概念，所有活动都是端到端流程中一个自然的节点。那么，它将无法支持BPM中的战略落地。

　　3.该产品是否由业务人员驱动而非IT驱动。

　　此特征意味着业务人员的角色将不只是单一被动的需求提供者和业务流程执行者，还将是更积极主动的业务流程构建者、业务流程监控者、业务优化者和业务流程管理者角色。

　　如果一个所谓的BPM产品仅面向IT人员，业务人员不能深度参与业务流程建设，只能将业务需求翻译为IT语言再实现，那么很难做到IT资产与真实业务流程的高度同步。该产品将无法支持BPM的业务监控、改进、优化等管理需求。

　　4.该产品的流程实现是否支持粗粒度的服务编排而非从头定制开发

　　此特征意味着BPM产品必须支持通过编排粗粒度的服务集成并整合利用企业资产(包括IT和非IT)，以快速、敏捷的建设和变更业务流程，从而有效支持业务敏捷和业务改造。

　　如果一个所谓的BPM产品在项目中需要大量的定制开发，其架构不支持服务编排或者只能通过外挂的标准协议调用服务而不是架构的一个有机整体，那么它将无法支持业务敏捷和快速的业务改进。就目前IT界的技术来看，产品是否全面支持SOA甚至直接架构在SOA上，是判断是否符合此特征的重要依据。

　　解决哪些核心问题

　　真正的BPM需要提供面向业务人员的业务流程的建模语言、建模工具、管理工具和监控工具;需要屏蔽掉业务人员弄不懂的IT语言与实现;需要强大的集成能力可以贯通分散于各个业务部门各个平台上的异构系统以实现企业整体业务流程管理和绩效监控;还需要业务流程当中的活动可以与企业战略挂钩，使得业务流程的运行直接反馈战略执行状态。

　　因此，一个真正的BPM软件要解决的是以下一些核心问题：

　　1.BPM必须横跨业务和IT两个部分。它必须很好地支持业务用户采用业务语言来建设业务流程，同时又必须能够支持IT人员使用IT语言来整合IT资产以实现业务流程。这要求一个BPM产品必须同时具备业务设计能力与IT设计能力，并且能够将两种模型统一为一个完整的模型。

　　2.与以前纯IT产品不同，企业的运营流程与BPM产品里的资产应该是高度同步的，这些资产映射了真实的业务流程而不是需要翻译的IT资产。当企业的业务变更发生时，这些变更不需要等待从业务翻译为IT资产的周期，而是由业务人员直接将其转化成BPM资产，这些BPM资产则应快速响应业务变更。这要求一个BPM产品要能够管理一个业务流程(BPM资产)从创建到测试、模拟、部署、运行、监控、改进、变更、升级、归档的整个生命周期。

　　3.与单纯的某一类专业IT产品(如生产、财务、客户关系管理等)不同，BPM更注重于跨部门、跨IT系统、跨业务甚至跨组织的综合业务需求。尽管它在解决企业应用架构中较低层次的执行问题方面也是利器，但BPM更大的价值在于它能够在整个企业应用架构中更高的层次上整合业务，能够与企业战略相结合。这要求一个BPM产品要能够使用粗粒度的服务来快速构建应用程序而不是从头开发。

　　4.BPM必须具备更强的扩展能力，能够容纳、扩展、整合各种各样的企业应用，以BPM为核心形成应用生态圈而不是仅仅是孤立的业务问题和流程问题。这要求一个BPM产品必须基于开放的标准和平台，要能够具备跨平台、跨应用的整合能力，可以扩展和被扩展，以满足企业各种各样的业务需求和应用环境。

　　企业可以从以上四个方面来评估一个BPM产品是否符合自身的需要。

　　同时， BPM的实施是一个循序渐进的过程，它必须与企业当前的BPM成熟度、业务规模、人员素质等相匹配，同时也与BPM产品的复杂度息息相关。显然，一个刚刚接触并开始采用BPM的企业，不可能掌握从战略到执行的方法，不可能建立完善的从战略目标到活动的指标体系，也无法在短时间内在管理上疏通各个业务职能部门。直接实施一个庞大的BPM计划，引入一个复杂的BPM产品，将会使企业充满挫败感：每走一步都极为艰难，周期长，难见成效。许多邀请咨询公司做了业务流程梳理但却难以落地的企业对此应深有体会。

　　作者简介

　　谭云杰， 《大象-THINKING IN UML》一书作者，面向对象分析设计方面的专家。作为经验丰富的IT从业者，他曾经担任过项目经理、产品经理、系统分析师、架构师等职，拥有多个项目的分析、设计、管理经验，对软件领域有着全面和深刻的理解。他现就职于IBM ，从事BPM相关产品的研发工作。