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提供流程管理中标准的补偿操作和异常处理操作，即流程开发人员需要自定义补偿操作。也可以通过其微流程特性，在底层应用支持事务处理的基础上，保证一个子流程级别的自动回退。

　　4.2人工密集型流程

　　(1)流程特性:流程参与者以人为主，关键的流转方式由人的处理结果决定。流程的处理过程，往往围绕着1个或多个业务表单进行，参与流程的人员对业务表单进行操作，并由流程引擎按照操作结果判断下步由谁处理。在所谓的adhoc工作流中，参与流程的人员希望能够直接指定下一步的具体处理人员，这在中国是很普遍的需求。在大型企业中，层次化的管理机制往往要求层层上报、层层下发方式的管理流程，这样的模式需要更好的流程可视化支持。

　　(2)业务示例:生产部门的消缺流程。一个典型的消缺流程，需要经过多个岗位的人工操作和判断，用语言加以说明多少有些困难，这里直接用一个示范流程图(见图2)来表述:

　　可以看到，流程中绝大部分操作是由不同的角色来执行的，但是也有部分操作是自动执行的，比如缺陷归档和自动发起缺陷跟踪。

　　(3)平台支持:Cordys平台的一个显著特性是其彻底的S O A特性。即使是基于表单的人工操作，在平台中也被封装成为Web服务。可以这样考虑，表单设计中必然会有用户的输人和输出，而输入和输出中关键的部分，成为Web服务的输人和输出，可以在流程中被作为参数引用，影响流程的走向。比如，在表单中指定的下一步操作人选，成为Web服务的输出参数进人流程，然后按照流程的动态用户、角色绑定功能，决定了流程的走向。另外，国内的业务流程应用经常有所谓的直通车需求，即在达到某种条件后(通常是由人工判断得出的)，可以省略很多流程环节。这类需求，通过表单与流程的服务级互动，再结合流程引擎动态条件执行的功能，可以方便而直观地实现。

　　此外，基于Ajax技术的所见即所得Web表单开发能力，也是Cordys的一个重要优势。这种技术与Cordys相应的lava应用逻辑开发框架相结合，可以在B/S上很大程度地实现C/S功能，可以实现丰富、易用的界面，并且在开发周期中，能尽早向用户展示最终界面，有利于确保系统贴近需求。

　　另外Cordys BPMS产品能够提供灵活多样的监控功能，以图形化视图、列表视图或树状视图等不同方式展现流程当前的运行情况，例如对于一般的流程，产品能够提供与设计时完全或基本一致的监控视图;对干跨层级的管理流程，产品能够通过树状视图，为管理者提供一目了然的流程实时状况.

　　4.3文档密集型流程

　　(1)流程特性:流程围绕一个业务文档的制作、审批、发布、归档进行，可能还包括某些与业务紧密相关的特别操作。一般来说，详细的业务信息驻留在文档中，而流程控制信息和最关键的业务信息、(比如文档状态和存储路径)由流程来管理。过程中牵涉到对文档的处理，包括自动和人工两类，这要求流程可以提供对文档管理系统的接，并可以在用户界面层与文档处理程序相结合

　　(2)业务实例:这里举一个配电线路单线图审核的卞流程为例:1)电缆工区制图;2)电缆工区专工校验，3)电缆工区生产主任审核，4)供电部专工审核;5)供电部牛产经理审核;6)存档。

　　(3)平台支持:文档密集型流程本质上是人工流程，但与文档处理功能结合紧密。Cordys、对Office,PDF, SVG等通用文档格式都有相应的支持，也有相关的成熟案例。对于各类私有的文档格式和文档制作工具，则需要视情况决定集成方式。

　　4.4决策密集型流程

　　(1)流程特性:在流程中牵涉到大量的执行路径和分支判断，而这些分支判断的标准经常需要变化。比如，原先针对1万元以下、10万元以下、50万元以下、100万元以下和100万元以上的采购金额，有不同的审批方式，现在把50万的分界线移到 30万，再增加对500万以上的专门规定。如果用一般的流程实现，则流程图会较为复杂，对于业务人员也不直观，而且改动时的工作量相对比较大。使用专门的规则引擎，与流程结合在一起解决这类问题，是比较理想的模式

　　(2)业务实例:停电审批流程，目前在很多单位还是一个人工密集型流程，在其审批过程中往往注重停电范围和修复时间等因素。随着今后供电企业数字化管理进程的深人，很可能要引人经济影响、社会影响(比如某区域内短期多次停电)等因素，那时，很可能需要制订相应的业务规则，按照不同因素的组合来确定具体的审批路径，并在审批获准后执行相应的处理预案。可以想象，新业务规则的确定需要有一个过程，在此过程之内，通过配置业务规则，灵活改变流程的能力就会显得尤其重要。

　　(3)平台支待:Cardys平台内置规则引擎，从而充分利用规则引擎所具有的规则建模、动态配置和执行能力，实现更人的业务灵活性。它具备以下功能特性:1)与流程引擎紧密集成;2)易于被流程设计模型调用。3)支持规则建模与高性能执行引擎;4)业务对象行为可配置;5)支持动态行为变更

　　5结语

　　逐一揭示了BPMS与工作流以及R A工产品之间的区别，并剖析R P M S的应用场景。在实际应用中，端到端的业务流程更为复杂多变，但往往是上述4种流程的组合。比如，在消缺流程中，判断缺陷类型后，如果会造成一个变电工区以上的区域停电，则可以异步地触发跨系统应急处理流程，这就把系统密集型和人工密集型流程结合在一起。总之，真正的BPMS流程管理平台要做到灵活、稳健、高性能地支持各种各样的应用集成方式。只有这样，才能为企业带来跨部门、跨系统的解决方案，让企业的业务彻底摆脱旧有模式中信息孤岛带来的制约，变得更加灵活敏捷，自如应对市场环境的各种变化。