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，真的是问题的关键！自底向上的堆砌技术，随波逐流的往架构上随意嫁接技术，见风使舵的把产品改头换面去制造与业务需求的匹配，终究不是长远之计。
以下文章点击率最高
Loading…