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）产品及其解决方案。
来源：oschina
链接：https://my.oschina.net/u/179986/blog/38921