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

回到BPM产品上来，如果仅从实现技术去理解，人们就会陷入这样的混乱： BPM与工作流有什么差别？都有流程引擎，都可以自动化运行，都有流程编排器，也都能对流程进行监控。凭什么工作流就不是BPM？如果辩解说BPM能比工作流能做更多的事，比如服务编排和集成，工作流会说只要是开放的通讯标准，不论是WebService还是JMS，工作流同样可以集成第三方服务，BPM可以做的，工作流同样可以做到，无非只是技术