BPM 是与非 -- 什么是BPM，如何辨别是否BPM产品，以及如何选择BPM产品

BPM方兴未艾，然而眼见市场上BPM产品一片混乱，你方唱罢我上场，各色产品、各类概念粉墨登场。虽然百花齐放，但真正有志于实施BPM的客户却被这乱花迷了眼，实在搞不清楚BPM该怎么去作，最终失去对BPM的信心和关注。这于BPM的发展并没有益处。由是撰写此文，从BPM的基本概念出发，讲解了一些如何辨别和选择BPM产品的建议。但愿能为BPM市场的进一步发展带来一点帮助。

什么是BPM

BPM（Business Process Management）其实并非近期出现的新概念，从本质上说，BPM并非一个IT术语，更不是因技术的发展而起源的，相反，BPM至始至终都是管理学术语和概念。BPM的核心是经过对企业运营的业务流程的梳理、改造、监控、优化来得到利益的最大化。要达到这一目的，必须把企业资源和管理方法从纵向的战略到 业务的执行打通，使得企业业务流程当中每个活动都可以明确的指向特定的战略目标而且能够测量和评估，从而得到改进的方向；同时必须把企业资源和管理方法 从横向的各部门、职能甚至第三方职能整合为一个有机的总体，使得企业业务流程能够以端到端的方式，即从业务目标的提出（业务流程创建）到业务执行结果（业 务活动的测量），来管理企业的运营以得到最大的利益。

而BPM软件产品则是针对这种管理方式的一种构造工具——一种使人异常兴奋的工具，可提供更快更好更便宜的解决方案。它致力于将IT 与业务之间的对话变成一种用于构建解决方案的交互式连续迭代方法。 BPM将IT会话转变成业务语言——解决IT长期存在的一个问题：业务-IT之间的沟通障碍，帮助企业改进效率、使流程可视化、使流程敏捷化并帮助企业进行业务变革。

    可见， BPM 不是由于 IT 技术而出现的，正相反，是由于有了 BPM 这样的管理理论，而企业又但愿经过 IT 工具来帮助他们实施 BPM 管理，才相应的出现了 BPM 软件。如今广泛的把 BPM 理解为一个 IT 术语，更多的理解为一类 IT 产品，这样的理解是不全面的。在 BPM 里，业务应当占据主导地位，软件或说技术是辅助地位。从业务上说，完整的 BPM 应该覆盖企业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和监控、业务流程优化改进以及战略调整等等几乎企业管理的方方面面。从 IT 角度说， BPM 所集成的一系列软件和专业技术要可以支持上述的业务生命周期使之落地。最重要的是，这些软件和专业技术必须是面向业务人员的。即， BPM 的实施将由业务来驱动 BPM 的建设，由业务人员来主导整个业务流程管理体系的创建而不是由 IT 来驱动。

当前BPM市场和产品的混乱

与其它革命性的IT变革同样，咱们须要从方法、架构和实现技术三个方面去理解和掌握BPM产品。方法对应产品的设计目标——企业的管理理论和相应的实施方法论；架构表示软件产品的设计如何匹配该设计目标；实现技术则表示采用何种IT技术去实现相应的架构设计。三者缺一不可，然而长久以来，人们习惯于用实现技术去分辨和解释BPM，以致于到如今为止，人们仍然没法正确的理解BPM。由此也形成了BPM市场和产品的混乱。

其实这个问题并非BPM独有的。举例来讲，做者在培训面向对象的分析和设计方法时发现，至关大比例的程序员，哪怕他已 经工做了不少年，哪怕他拥有丰富的项目经验，也精通一门或多门面向对象的语言，但他们并无真正的掌握面向对象的方法。掌握面向对象方法的关键不在因而否 采用了面向对象的语言和工具（如UML或java），也不在因而否掌握了面向对象的编程技巧（如设计模式），而是，你是否真的在用面向对象的思惟去思考，从需求，到分析设计，到编码实现。它体如今项目的整个过程而不是仅仅是结果的表象。

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

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

一样的混乱还有不少，例如ERP会争辩说ERP也有其内部的工做流，也能够把客户的业务流转起来，ERP也是BPM；办公协同类软件也会争辩说BPM不就是资源共享和工做协做么？从这个角度说，我也是BPM，有何不可？

而客户就更加混乱了。从经过流程来实现一项业务的实际需求出发，上述的任何一门技术彷佛均可以实现他们的需求，怎么选择？况且凡是带个流的，都说本身是BPM，彷佛谁谁也差不到哪里去。至于那些花了大价钱进行了流程梳理的企业，费了牛大的劲梳理出来的流程却停留在Visio里，写在word文档里，有什么用？以致于许多客户最终消极起来：我只知道我得审批信用卡，我得处理投诉，只要管用好用就行，只要能解决我如今的问题，是否是BPM又有何妨，who care？

看，一旦陷入这样的技术细节比较，就是比上个三天三夜，吵个天翻地覆也不会有结果，市场继续混乱，产品继续混乱，客户继续混乱 ……

甄别产品类型应从方法和架构入手

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

一方面，技术的堆砌没法造成架构（技术架构必须指向特定的业务领域，解决特定的业务问题），拼凑出来的所谓架构也没法完整的解决业务问题。 可以作到某些事情并不表示它就是解决这类问题的恰当的工具！好比，扳手和锤子均可以用来砸钉子，但扳手自己不是锤子，它们被设计为服务于不一样的业务领域。 另外一方面，一样的方法和架构容许不一样的实现技术。例如，若是你的架构就是要解决砸钉子的业务问题，因为某种缘由没法使用锤子，必要时，你能够把扳手集成进 来，做为一种可能的实现技术。

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

回到BPM上来，上述的例子想要表达的意思是：若是一个产品的设计理念和相应的架构不是针对BPM的（例如工做流、OA），即便其加入了符合BPM的某些技术实现特征（例如流程监控、流程生命周期管理），它仍然不是一个BPM产品，它只是可以额外作一些BPM所需的功能（上述例子中的扳手）而已；另外一方面，若是一个产品的设计理念和相应的架构是针对BPM的，即便其加入了其它一些技术使得它可以支持诸如工做流或OA的应用，它也不会所以就变成工做流或OA产品。它只是扩展了更多的支持而已。

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

是，仍是不是BPM，真的是问题的关键！自底向上的堆砌技术，随波逐流的往架构上随意嫁接技术，见风使舵的把产品改头换面去制造与业务需求的匹配，终究不是长远之计。

如何辨别一个产品是否BPM产品

由BPM的设计目标——业务流程管理决定，BPM不只仅是一个IT工具，它必然要和企业运营紧密结合在一块儿，是企业管理运营的直接映射，而不须要等待把业务需求翻译为IT需求再用技术定制实现的周期。企业须要的是能够直接将业务变成可执行流程的技术，须要由业务人员直接创建、管理、优化流程，但愿流程管理系统建设后能够直接在执行过程当中监控企业绩效，更但愿企业的战略意图能够直接与具体的执行层联系起来。

要知足这样的需求，BPM工具必须彻头彻尾的面向业务人员而不是IT人员，用业务语言去建模而不是IT语言，由业务人员驱动BPM的建设而不是IT驱动。换句话说，若是有一个所谓的BPM产品，但它被设计为面向IT人员，靠IT人员定制开发而不是业务人员建模、其设计没法对接战略层和执行层（最明显的判断是：是否可以说 明和测量流程中的某一个活动针对哪一个战略目标，某个实例贡献值如何）；或者它被设计为针对业务执行问题（需求从基层来）而不是业务管理自己问题（需求必须 自顶向下）的，便可怀疑为伪BPM或说是不完整的BPM。

最容易混淆的即是工做流与BPM，OA与BPM，ERP与BPM。首先，不管是OA仍是工做流，其设计目标并非管理业务而是经过IT手段协调和分配工做任务和资源，提高工做效率、优化资源利用率和工做规范化。其次，ERP是面向工做流的，它实现了信息的最小冗余和最大共享，将企业内部全部资源整合在一块儿，对采购、生产、成本、库存、分销、运输、财务、人力资源进行规划，从而达到最佳资源组合，取得最佳效益。换言之，不管是OA也好，工做流也好，ERP也罢，它们都关注在执行层面。

一方面，其活动或操做的粒度是针对业务人员执行的具体工做任务，并不追究该工做任务与企业总体业务之间的横向关联和企业战略目标之间的纵向 关联。其突出的特色是直接面对最为具体的业务操做，但没法说明和测量该业务操做指向哪个企业战略目标，更没法衡量该业务操做向特定的企业价值贡献了多少 指标。其项目特色是不须要端到端的流程梳理（自顶向下定义，纵、横向贯通）做为必要的需求输入，只须要某个局部的需求即可完成项目。

另外一方面，其技术基础针对的是IT人员，必须将流程的业务含义转化为IT含义，由IT人员进行建模和实施。其突出的特色是，在项目中，业务人员只可以承担需求提供者和软件使用者这两个角色，而没法承担流程建模者、流程监控者、流程改进者、流程管理者等角色。

    这些非针对 BPM 的 设计带来两个明显的局限，其一，系统的创建尽管使得工做效率有所提升，但对于衡量企业的总体绩效来讲，每一个这些系统内容是一个黑盒子，没法在执行过程当中监 控并获得企业总体绩效乃至战略的反馈；其二，因为架构和设计的方向不一样，业务人员被排除在流程的创建、管理、监控、调整以外，必须经过 IT 人员来进行。这使得业务敏捷成了一句空话。

总结下来，辨别一个产品是不是真正的BPM产品，能够从如下几个关键特征出发：

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

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

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

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

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

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

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

此特征这意味着业务人员将从单一被动的需求提供者和业务流程执行者的角色增长为更积极主动的业务流程构建者、业务流程监控者、业务优化者和业务流程管理者角色。业务人员和IT人员将密切配合起来。

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

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

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

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

如何选择BPM产品

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

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

1.  BPM与其余IT产品要么支持业务用户、要么支持IT建设的不一样之处在于，它必须横跨业务和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产品必须基于开放的标准和平台，要可以具有跨平台、跨应用的整合能力，能够扩展和被扩展，以知足企业各类各样的业务需求和应用环境。

以上4个核心问题，同时也是对一个BPM产品对企业业务流程管理支持度的评判，企业能够从以上四个方面来评估一个BPM产品是否符合自身的须要。

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

所以，在比较各BPM产品如何解决上述的核心问题以外，还须要看该BPM产品的复杂度和针对不一样背景和需求的客户的支持程度。其关键是两个方面：

其一，一个BPM产品是否可以支持并帮助企业按部就班的小步快走，步步为营，步步为赢，在短期内见成效。每创建一个业务流程都体现出应有的价值，帮助企业创建信心，找到适合本身的方法，锻炼业务流程管理能力，从而最终全面采用BPM。这要求一个BPM产品具有快速实施的能力，而且产品的复杂程度可以针对不一样客户量身定制。一个实施过程复杂、没法按需求规模定制复杂度的产品，将会给BPM的实施带来许多额外的困难。

其二，一个BPM产品是否可以支持企业长期的、不断深刻的、扩展的业务需求。随着企业使用BPM的成熟度提升，其需求也必将从简单走向复杂、从表面走入深层、从一个业务领域扩展到另外一个业务领域。这要求一个BPM产品具有完整的产品体系以及各产品模块的灵活配置、扩展甚至即插即用的能力，以保证不断扩展产品功能的同时维持BPM建设进程的稳定而且保护已有资产。不具有灵活的架构，只能经过定制开发来扩展功能的产品，将没法有效支持此需求。

BPM的实施团队的能力也很重要

    BPM的实施与传统管理信息化项目不一样，与ERP却是有几分类似：项目实施过程必然要依据对业务的深入理解并伴随着业务的改造、优化和调整等活动，而不只仅是简单的实现当前的业务。这要求实施团队不只仅要懂IT技术，更重要的是懂业务，要可以跟业务人员在业务层面上进入深刻的交流。最理想的BPM实施团队要有业务流程梳理的知识与技能，有实施企业业务管理的经验，可以帮助客户量身定制的寻找和定位业务价值、定义业务能力、端到端的建模业务流程而且可以找出流程中的瓶颈而且与客户一块儿寻找到适合该企业的优化的办法。

    再好的BPM产品交到只懂技术，持有技术至上观点或者只会用IT思惟去思考业务问题的团队去实施，其结果必然会失败。由于BPM是业务驱动而非IT驱动的，成功的BPM毫不仅仅是几个流程跑起来，解决了当前问题就完事。而是经过BPM的建设，从纵向打通企业自顶向下的价值实现过程（从战略目标或业务价值到业务执行），从横向创建价值实现能力（跨部门、跨业务的业务能力），从环向上创建业务绩效评估（业务活动针对某业务价值的指标监控）体系，最后经过BPM产品的业务流程治理来不断的优化上述的各个管理要点，从而不断的提高企业的价值创造能力。这些实施目标与技术相关不大或说技术只是支持，与BPM实施团队的业务理解能力、行业领域知识和行业管理咨询经验则是息息相关。

     所以对有志于实施 BPM 的企业来讲，除了关注 BPM 产品自己，还须要关注 BPM 实施团队的业务能力和业务经验，毕竟 BPM 毫不仅仅是一个 IT 级别的产品。从这一点来讲，大、中型企业的业务每每错综复杂，规模也要大得多。要想成功实施 BPM ，与具备丰富业务经验和行业管理咨询能力的 BPM 产商合做是更好的选择。一个实施团队实施了BPM，但又不可以在业务管理咨询方面向客户输出行业的成功经验、提供行业解决方案和量身定制的业务领域模型并因地置宜的提出优化建议 ，最终极可能成为只是实现了局部的、片段化的、仅仅实现了当前业务的所谓的 BPM 。这一结果距离真正的 BPM 成功尚有至关的差距！！可能只是披了流程外壳的传统信息化，或者新瓶装旧酒的又一个OA、工做流系统而已。

做者简介：

谭云杰， 《大象-Thinking in UML》一书做者，BPM及面向对象分析设计方面的专家。经验丰富的IT从业者，曾经担任过项目经理、产品经理、系统分析师、架构师等职，拥有10多个项目分析、设计、管理经验，对软件领域有着全面和深入的理解。精通UML及建模方法，在需求管理、分析方法、软件架构以及面向对象的分析和设计方面具备拥有10年的实践经历，有着深入的理解和独到的认识。精通软件工程和各类软件方法，如RUP、敏捷方法等。精通项目管理，PMP证书得到者。

现就任于IBM从事BPM相关产品的研发工做，精通IBM业务流程管理（BPM）产品及其解决方案。