BPMS业务流程管理套件部析

1企业、系统与流程

    业务流程是由一组相互协调、有序关联的步骤构成的活动链条，用以达到某种业务目标。流程一与简单活动之间的区别在于:流程中的各个步骤需要不同的人员和系统来完成，还需要各个步骤之间流转的控制与数据。企业就是由各种各样的流程组成的、张流程网络。企业具有众多业务职能，包括产品规划、市场营销、订单处理、客户服务等，各种流程贯穿其间，构成它们的基础。管理越规范，固定资产密度越大的企业，流程的重要性就越明显。然而，企业并非按照流程来组织，而是依照不同的业务职能来划分部门，如市场、营销、生产、财务、以及客户服务等，集团性企业的分支机构也基本上是按照这种方式组织的。企业内的每个部门都有自己的工作方式和应用系统，支撑着部门内的业务流程。企业应用一般都针对专门的业务职能或部门需求而设计，但是关键业务流程和信息往往会跨越不同的职能和部门。
    面向业务部门和职能的应用系统一般已经达到相当高的成熟度。长久以来，企业在ERP和CRM等企业应用上的投资为各个部门和系统内部的任务自动化、数据集成、以及控制管理带来了不小的进步。但是，为此付出的代价却是在企业内部又形成新的信息孤岛，大大限制了企业的灵活度，也不利于跨越部门和系统管理业务流程和业务信息。显而易见，这些跨越部门的业务流程才是企业最为重耍的要素，关乎企业生存的方方面面，包括企业的整体运营效率、客户的满意度、企业的合规性、以及对需求不断变化的响应能力。20年前，出于对业务管理的思考，诞生厂业务流程管理(Business  Process Management，简称BPM)的理念它从关键性的跨部门流程人手，研究如何规划业务、理解业务、并对其进行考核，而不是局限在某个部门和系统之内考虑问题。
    有些人士认为，BPM就是一门管理学问再加上分析业务的全新方式。然而，这种认识是很不准确的。使用业务流程管理套件(Business  Process  Management Suite，简称BPMS)进行业务流程建模与分析的真正好处在于能够对企业的跨部门业务加以自动化执行、并对其进行测量与优化。BPMS消除了企业内各个部门之间的隔阂，为跨部门的业务流程带来了出色的效率、灵活度、合规性、以及可监控性。
    目前市场上也有很多解决流程问题的软件产品，如针对人员交互的工作流产品，以及针对自动化任务的企业应用整合EAI。然而，它们只能解决各自领域内的流程问题.始终无法逾越人员交互与自动化任务之间的鸿沟，将两者结合起来，提供完整的跨部门和跨系统的解决方案。这里就向您揭示BPMS与工作流以及E A I产品之间的区别，并剖析BPMS的应用场景，从而让您对BPMS产品有更加清晰的认识。

2工作流解决方案

    在过去十几年间发展起来的工作流解决方案主要包括工作流引擎、工作流描述语言和基本的图形化建模工具。建模工具会生成代码，这些代码通常都是l商专有的流程语言，按特定的流程模式来描述工作流。一般来说，引擎用来解释生成的代码，执行工作流。同时，它还追踪任务执行过程中所涉及和消耗的资源。用工作流引擎解决人工工作处理非常理想。但这一模式也存在2个问题。
    首先，它们本身使用新的描述语言，而且往往需要开发人员了解Java, Perl及SQL等其他语言，但并非每个人都了解和掌握这些东西;其次，工作流软件一般不涵盖用户界面、系统接日和对象模型等东西，而这些东西其实又是工作流运行所必须涉及的。换言之，工作流引擎无法在运行时真正控制业务流程。所以，需要更先进的方式来解决问题，答案就是业务流程管理套件。

3企业应用整合EAI

    几年前，企业应用整合EAI的概念盛行一时，它能够通过高性能的消息总线，在应用系统之间实时地转换和传递数据信息，形成完整的自动处理流程。它在异构系统之间能提供统一的集成方式，也提供了高性能可仲缩的底层技术架构，对消除信息孤岛有很大的作用，也为实现业务流程提供了新的工具和方法。但由于强调对复杂信息系统的整合，EAI产品多少忽视了业务需求这个最根本的问题，主要体现在2个方面:
    (1)人工操作支持不足:自动化不能包打天下，很多业务流程是要牵涉人工操作的.而EAI产品在这力面的功能明显不足。
    (2)业务建模和流程建模脱节:EAI起初实现的是自动化流程，但在市场推广环节也宣称自己支持端到端的面向业务的流程。既然要支持，必须有相应的工具，所以往往在事后开发专用的业务建模工具或者并购专门的业务建模工具，但和原先的自动化流程开发工具，毕竟是两套不同的界面。这样做、提高了产品推向市场的速度.但导致业务人员和技术人员无法在同一个环境内协同工作，流程实现完毕后，业务人员难以判断这是否是自己想要的东西
    传统EAI产品面临的另外1个问题是对SOA的支持。之前，大多数厂商都使用自己的私有格式在网络上传输数据，而不是SOA要求的Web服务方式。然而SOA已经成为了市场上底层集成技术的主流，很多套装应用都直接提供了Web服务接口，并且作为产品的一部分进行技术支持和维护，比如SAP的XI技术。所以老牌的EAI产品一般都已经支持SOA，甚至把自己重新定位成SOA的整合平台。从目前来看，大多数厂商支持Web服务的工作，进展得都比较顺利，因为本质上是修改或者新增一种数据交换方式，不牵涉到底层的架构。然而，下文提到的2个问题，事关基本的设计思想，至今日，多数厂商还没有很好解决。BPMS产品与EAI产品之问的区别可以用表1来概括。
    因此，在当今谈应用整合，必须是面向业务，能够通过标准的Web服务技术整合底层应用，能够实现人工操作与自动化任务无缝集成，井提供丰富业务可视化功能的业务流程管理(BPM).

4 BPMS应用场景

    根据美国著名的高科技市场研究机构Forrester Research的分类模式，业务流程管理可以分为4种基本类型(见表2)，而更为复杂的流程可能综合了其中的多种类型:
    这种分类方式能够较好地说明基干B P M S的应用集成特性。因此，这里就按照上述的基本类型进行逐一介绍。

4.1系统密集型流程

    (1)流程特性:在应用系统之间，通过实时消b的方式实现松祸合的数据或逻辑集成。或者定期执行一系列逻辑复杂，又需要一定灵活性，需要访问多个应用系统或数据源的操作。在过程中一般不需要人的参与，但在发生异常时，应该有灵活的机制通知责任人进行相关的业务处理。
      (2)业务示例:重大故障造成停电或计划停电影响到一个变电工区或更大范围时，从生产管理系统触发跨系统应急处理流程:1)自动在95598客服系统内生成事件记录，以便客服应对客户的投诉，并提示管理者是否要在自动语音系统中加人对该事件的通报，包括停电范围和预期恢复时间;2)如果影响到大客户，则在大客户营销模块中，提示相关人员尽早与对方沟通;3)按照停电范围、同欺营收状况、和预期恢复时间，在财务系统中生成损失报告。
    (3)平台支持:Cordys通过Web服务集成各种底层应用系统，也可以把流程发布成Web服务。平台本身可以通过各类技术适配器或应用适配器把应用系统的逻辑、数据封装成Web服务，也可以利用应用本身提供的VsTeb服务(如SAP XI)或第三方ESB提供的Web服务(Aqualogic Service Bus)。在这个基础上，使用流程的方式把Web服务组织、串联起来。Cordys支持同步和异步的子流程与流程环节(Activity)，并可以在同一个流程中把两者结合在一起，兼顾系统间的松藕合和业务逻辑的紧密整合。Cordys提供流程管理中标准的补偿操作和异常处理操作，即流程开发人员需要自定义补偿操作。也可以通过其微流程特性，在底层应用支持事务处理的基础上，保证一个子流程级别的自动回退。