【IT168 信息化】业务流程管理（Business Process Management，BPM）从流程的角度出发，最终目的是期望协助建立一路直通的业务环境，并建立持续改善流程的能力，提供企业因应市场变化，弹性调整的敏捷能力。 

    面向服务架构（Service-Oriented Architecture，SOA）则是从整体IT架构出发，企图建立以合约为基础，整合信息与服务能力的发布平台，目的同样也是提升信息系统的敏捷度，以应付市场竞争及持续的成长。

    SOA与BPM两者最终的目标都是提高企业的敏捷度，差别在于着眼的角度不同，操作的方法及方向也因此不同。

不能让三个人生气的，都不能称之为流程

    业务流程管理并不是一个新兴的课题，早在1990年代在哈佛商业评论中一篇标题为《The Principles of Scientific Management》的文章中，就提出了业务流程再造（Business Process Reengineering，BPR）的概念。它的重心在于建立企业内部的管理纪律，透过不断调整的业务流程，推动企业管理的效率。

    经营管理大师Michael Hammer在1996年发表的《Beyond Reengineering》中曾经对“Process”这个字眼提出很精辟的见解：“凡是不能让三个人生气的，都不能称之为Process。”

    之所以会让人“生气”，是因为彼此的立场。在一个人的情境下，没有立场的问题；两个人的情境，没有少数或多数的问题，只能选择合作或互不往来，也很难生气；但是当第三个人出现时，就会有门户之见和争取多数支持的情况，这个时候就必须制定游戏规则，流程也就跟着来了。游戏规则很难尽如人意，因此不满意流程的人，便会为此感到“生气”。

    严格来说，流程的建立终究是为了达成业务/商业目的，透过流程的制定，决定了要达成这个目的所需实践的一连串工作，而进行这些工作势必牵涉相关的参与者。这些参与者可能是人员，也可能是一些推动业务经营的系统。
 

整合技术扮演重要关键 

    工作流程引擎是驱动业务流程管理的重要因素，而其它相关的驱动技术还包括了像电子邮件和简讯此类讯息传递及发布的平台、文件管理平台、业务规则建立、储存及管理的环境、可视化的流程建置工具等。

    而这当中，SOA也会是一个驱动的技术，因为透过松散架构及单元独立概念为基础的服务，可以配合业务流程自由调整，并充分反应市场的变动。

    而整合能力的强弱，是评选BPM平台的重要指标。这是过去纯以工作流程（Workflow）为主的产品最大的弱点，唯有涵盖了整合能力的工作流程产品，才有资格晋升到BPM领域。

    谈到企业整合，绝对不能不谈到XML，它在整合技术的演进过程中扮演着催化剂的角色。XML提供一个描述整合数据的标准基础，也让后续产生的Web Services相关标准，能以很低的门坎提供不同平台互通的可能性。

    进而从信息的观点产生出所谓企业服务总线（Enterprise Service Bus，ESB）的概念，整合信心交换作业。再延伸到企业事件驱动架构（Event Driven Architecture，EDA），以事件的方式更主动地推动整合服务。

    当整合的动作从数据进展到业务流程的范畴，BPM平台就担负起重要的角色，因此BPM产品几乎都强调与某些主流系统的衔接能力。这些BPM平台不论是采取松散结合或是紧密整合的策略，多半都不会少掉XML和Web Services这两方面的处理能力。

    整合能力的完备是评判企业建立服务导向架构能否成功的重要关键，在缺乏整合能力的情况下，很可能让推动服务导向架构的工作到最后只是Web Services化，难以提供企业经营上需要的敏捷能力。

    而良好的服务导向架构，又能协助企业推动更好的信息整合环境。因此这两者间可以说互为因果，一旦能正确地起头，就有机会朝正向循环的方向前进，持续改善企业信息服务架构。
 

BPM和SOA之间的配合 

    在定义业务流程的过程中，一般会期望能以标准的描述方式来定义。虽然可以透过BPM平台提供的可视化建模工具，轻松建立起业务流程的架构，但很多时候这些业务流程可能会有跨平台的需要，例如我们期望类似的流程能在上下游合作伙伴的环境中实践。因此能否顺利地交换这个模型，有时会是很重要的需求。

    由于服务导向架构是以合约及标准为基础，因此描述业务流程也可以采用相同的精神。业界由Microsoft、IBM等主流厂商所合作制定的BPEL4WS，就是以Web Services的描述语言为基础所描述业务流程的标准，让业务流程能够易于以服务的方式表现。

    进到执行的阶段，服务导向架构所强调的合约精神及在整合业务上提升的效度，可以让执行的工作更为顺畅，进而影响到业务监控实施的难易度。合约的协助使我们可以更容易地建立监控机制，以标准的作业方式检视商务程序中数据的内容及动向。

    而从服务导向架构在建立服务的过程中，我们也可以看到业务流程及逻辑的明确与否，也关键性地影响到每一个服务本身是否易于被重复使用、是否符合商业意义。

    换句话说，SOA会因为BPM的效益而有更佳的表现，相对的，SOA技术也让BPM更容易实践。两者间在操作的手法上有许多相似之处，而它们在呈现的效果上也常会是一体两面，一个着重在业务层面上，一个则着重在信息技术的运用上。
 

SOA的实践以BPM的执行成果为指标 

    完整的BPM平台除了要面对流程模型建立、仿真、人力工作流程等需求外，也必须具备有足够基础的企业应用整合能力，并充分管理业务流程的生命周期。

    而在作业流程同时会牵涉到合作伙伴的情况下，相关的伙伴管理功能也可能是一个重要的项目，进而推展到B2B 的作业情境。

    当然，业务规则的处理、检视作业进展和绩效的入口网站技术也会是很重要的成员。而这些功能都可以因为SOA而有更好的表现，同时它们也可以做为检视SOA成果很重要的指标或工具。

    讨论BPM这个主题时，很难不讨论服务导向架构。而服务导向架构的实践，也几乎都会以BPM的执行成果做为评断成功与否的重要指标。 透过良好的BPM平台的协助，一方面可以支持整合及流程改善，另一方面也能帮助SOA，建立组合式的应用程序──也就是前述由应用程序及数据服务包装成商业服务的成果。