为适应业务发展的需要 [ＢＰＭ：适应业务变化的利器]

　　业务流程管理(BusinessProcess Management，简称BPM)，是指根据业务环境的变化，推进人与人之间、人与系统之间以及系统与系统之间的整合及调整的技术手段。业务流程管理应该包括“建模－执行－监控－优化”的过程。支持上述所有功能的工具，方可称为业务流程管理平台(BusinessProcess Management Suite，简称BPMS)。
　　BPM的兴起与SOA架构的逐渐成熟是密不可分的。可以说，BPM是SOA架构体系中非常重要的层面，它充分利用SOA在集成和复用方面的优势，为企业应用提供灵活适应业务变化的能力。
　　对于业务来说，BPM是最为直观、系统的建模、执行和管理工具。它所关心的是业务活动的流转和相互之间的协调关系，简而言之，就是在什么步骤、谁(或什么系统)要完成什么事情、和其他活动之间有什么样的联系。而对于每个活动的具体实施细节，即利用什么手段和方法来完成这个活动，BPM是不会过问的。
　　SOA架构提供的服务恰恰契合了BPM的上述本质：SOA通过整合，将各个系统中的功能开放成服务，调用这些服务的使用方根本就不会关心这个服务是从什么系统、什么地点获取的，以及它是怎么实现的。因此，SOA让BPM真正得以实现，而BPM让SOA更加贴近真实业务。许多SOA架构参考模型都将BPM囊括其中，如IBM提出的SOA参考架构。此外，BPM还是帮助SOA在企业内尽快实现落地的工具。
　　近几年，BPM是企业软件中发展最快的细分市场之一。著名的IT分析机构Forrester对BPM市场的发展状况做过统计，从2005年至2007年，BPM市场的规模从1亿2千万美元增长到1亿7千万美元，涨幅达到近40％。Forrester对这个市场非常看好，预计在2008年到2009年的两年时间里，该市场都会保持稳定高速的成长，以每年接近24％的速度递增。到2009年，BPM市场将会达到2亿6千万的规模，比2005年整整增长了114％。
　　
　　业务需求变化的原因
　　
　　BPM为什么能灵活适应业务需求的变化呢?让我们先来分析一下业务需求变化的原因。业务需求的变动对于IT人员来说是最为头疼的一件事，因为这通常意味着庞大烦杂的重新设计和编码工作。总体来说，目前导致业务需求变动的原因主要有：
　　第一是与业务人员沟通不畅。技术人员与业务人员的思想方法和项目经验都有很大的不同，所使用的工具和沟通方式也彼此迥异，因此对于业务需求的描述和理解自然会发生分歧，这也是造成软件项目中许多与实际业务不匹配的主要原因。
　　第二是来自业务的需求不清晰、不完整。在进行需求调研时，技术人员经常会遇到业务人员不知道该如何提需求的情况，这样就很容易造成需求的不清晰和不完整。当然，技术人员不能责怪业务人员不懂提需求，因为业务人员所受的训练以及所关心的问题是如何能完成业务上的任务，而不是设计软件系统的功能。除此之外，业务人员投入的时间不足，以及调研时遗漏业务人员都会造成业务需求上的不清晰和不完整。
　　第三是技术方案不够灵活，技术方案中的各个组件采用僵硬的紧耦合方式衔接，不能很好的归纳业务类型，因此当实际情况稍有改变，就意味着来自业务部门的新的需求调整。
　　第四是业务本身在发生变化，图2展示了目前普遍存在的业务与IT各自的变化周期。我们从图中可以看到：企业策略层每1～2年就会做一次策略上的调整；执行层由于需要根据市场的实际情况进行研判，因此对企业实际业务的调整就更为频繁，一般是3～6个月就需要进行一次，规模可大可小，这要视具体情况而定，而在企业的IT层面，由于受IT设备的购买预算和软件开发周期的限制，其调整周期通常会是3～5年，甚至更多，相对于业务上的调整，可以说是非常缓慢，因此很难跟上业务和市场变化的步伐。
　　
　　
　　帮助IT灵活适应变化
　　
　　我们可以看出，业务需求的变化更多是来自业务与IT之间的隔阂。而BPM恰恰在这两者之间起到了很好的桥梁作用，并通过快速搭建和执行流程的功能为企业业务提供具有理想灵活性和动态性的IT实现手段，其作用主要包括帮助梳理业务，实现业务，监控和管理业务。
　　
　　帮助梳理业务
　　
　　BPM具有一体化的图形建模工具，该工具可以将图形化的流程模型直接转换成可以在IT系统内执行的流程代码。
　　因此，BPM可以让技术人员和业务人员在同一个设计环境内一道工作，共同梳理业务，从而避免由于彼此使用不同的设计工具而造成的理解和设计上的分歧。
　　技术人员还可以利用BPM内提供的丰富构件来完善这些流程模型。例如，技术人员可以为流程模型添加异常处理和相应的补偿动作，所有这些也都是通过图形化建模的方式在同一个设计时环境内完成。然后再与业务人员进行沟通、确认。
　　这样一来，BPM就可以很好地帮助技术人员和业务人员同步彼此对业务的理解和认识，解决他们之间沟通不畅的问题。
　　
　　帮助实现业务
　　
　　BPM可以帮助技术人员快速实现具有相当灵活性的技术方案，不但能很快创建供业务人员验看的原型应用，帮助并引导业务人员提供完整、清晰的业务需求，而且还能快速应对业务层面发生的变化，将软件应用的调整周期也从3～5年缩短到几个月，完全跟上业务变化的步伐。
　　那么，BPM的灵活性和敏捷性是如何获得的呢?关键的两点就是：其一，流程的流转逻辑不是写死在程序代码中的，而是剥离出来形成了新的流程层；其二，BPM充分利用了SOA松耦合的集成和复用功能。
　　利用BPM开发流程应用的基本过程是：图形化的流程模型一旦搭建完毕，流程的流转逻辑就可以自动生成了。BPM支持混合型流程，因此模型中的单个活动可以是系统自动化任务，也可以是人工任务。
　　借助SOA架构强大的集成和复用功能，企业内各个系统中的功能和数据都被开放出来，成为可以互相调用的服务。这些服务就可以与BPM流程模型中的系统自动化任务对应起来。然后，再借助BPM中的UI界面快速搭建工具，生成可以和人员交互的应用界面，并将其与BPM流程模型中的人工任务对应起来。最后再构建好任务与任务之间传递的消息以及必要的数据映射。这样，一个相对完整的流程应用就创建好了。
　　当实际业务发生变化之后，我们可以对流程模型进行修改，重新编排流程中的任务，或增加、删改相应的任务，当模型调整好之后，相应的流程流转逻辑也就自动生成了。而之前通过SOA开放出来的服 务、以及通过UI搭建工具创建的人工交互界面还可以继续加以利用，要么和原先的任务继续绑定，要么和新的任务进行耦合，或根据新的需求开发新的功能和界面，然后再与相应的任务进行绑定。通过这种松散耦合的方式，就可以大大加快软件的开发速度，让其跟上业务的变化步伐。
　　
　　帮助监控和管理业务
　　
　　BPM提供通用的流程监控和管理功能，使技术人员可以根据需要迅速定制管理层需要看到的监控信息。
　　在流程正式运行之后，BPM可以从业务和技术两个不同的层面对其运行状况进行监控。首先是业务层面，在此过程中，通过把数据聚合加工成各种业务信息，使业务分析人员可以按照自己需要的钻取路径，逐层深入地对业务运转情况进行监控与分析，包括业务指标、业务资源等各个方面。在技术层面，不但要实时掌控整个平台以及关联系统的运行情况，还要对单个流程的执行逻辑以及传递的数据进行分析。
　　
　　通过对流程状态和运行数据的历史情况进行记录和维护，业务分析人员和流程开发人员就可以获得准确详实的依据，有针对性地对流程进行优化，从而获得更好的运行效果。此时，企业就又开始新的一轮对业务的建模、执行、监控、与优化。
　　
　　综上所述，我们可以看出BPM能很好地应对造成业务需求变化的问题，帮助我们灵活、快速地适应业务需求的变化。另外，BPM从业务出发，采用自顶向下的“建模一执行一监控一优化”开发模式，并通过提供方便的一体化建模环境、快速UI界面搭建工具、丰富的流程监控和管理工具等手段大大加快了企业应用的开发周期，并节省了开发资源。同时，其强大的流程监控能力也为企业管理层展现了更加详实的企业运营数据，帮助其做出更为准确和迅速的决策。
　　
　　链接
　　
　　
　　这是一个BPM产品的层次结构图，最上面是最终的应用，依次是业务流程的知识框架、BPM产品包、BPM工具，BPM服务器／引擎，特定的语言或者平台。
　　其中每一层的产品都建立在它下面那一层的基础上，通过整合下一层的技术，从而扩展相应的功能。其中业务流程的知识框架决定了最终的应用适合于哪一种行业，例如面向保险行业的会集成保险业的相应规则和模型。
　　需要注意到是一个BPM公司可以使用自己开发的BPM引擎、工具来完成最终的软件包或者应用，也可以集成其他厂商的。
　　例如，一个厂商利用Java自主开发流程模型工具，用户界面和BPM引擎，然后基于IBM的WebSphereBusiness Integration Server来整合，同时集成BPEL的工具。