利用业务流程管理（bpm）系统，我们可以把业务逻辑从应用系统中分离出来，从而让我们能比以前更快速地创建新的应用。

听起来，bpm(business process management，业务流程管理)软件的好处很多，简直有些难以置信。比如，支持者说bpm能降低应用软件的开发成本、缩短上市时间、加强法规遵从的贯彻力度、实现业务流程性能的最优化。

当然，bpm软件本身并不能改善任何东西，但是与关注业务流程的文档和流程分析结合以后，bpm就会成为企业改善业务效率的利器。在bpm提供的高级开发环境中，它采用流程驱动的模型和性能评估来实现it解决方案的开发。

从低层次上说，bpm提供了一种业务人员与it交流需求的平台。而从更高的层次来讲，bpm能帮助我们从现存的应用中提取出功能模块，从而把业务逻辑从它所在的软件系统中分离出来，这就给我们带来了前所未有的灵活性。

但是，有一个问题一直困扰着bpm的应用，就是bpm软件有太多的变种，似乎只有很少的几个咨询顾问才真正知道，到底哪个解决方案能解决自己的问题。

不过，现在由于bpm软件包中集成了各种工具和运行时所需要的组件，以及能进行业务流程仿真的软件，这个问题正在逐渐变得清晰起来。使用bpm软件包中的这些工具和组件，用户可以建立业务模型、部署和监控bpm系统，而不用零零碎碎地从多个的供应商把它们采购回来，再一一安装和部署它们。

如果使用恰当，bpm有助于解决应用系统内部基本的业务活动难以修改的问题，特别是在过去的那些业务软件系统中，这个问题尤为突出。与之相对的是，bpm软件可以让it部门通过修改与这些业务活动相关联的流程逻辑来优化业务效率。在bpm中，流程的设计就像画流程图，那些必要的执行方面的细节用注释来注明。整个过程几乎不用编码，而且流程逻辑非常容易修改，所以，bpm可以算得上一种灵活的应用开发工具。

流程的建模

bpm的使用从流程的建模开始。这个阶段要把当前的流程和未来的流程详细地列出来，并一一确定各个流程的性能指标（这些指标将来进行流程的仿真模拟时需要）。这是一个业务驱动的过程。

bpm软件包中的流程设计器是一个图形化的开发工具，它能够把流程模型和有关的人力活动流、应用和业务规则整合到一起，生成一个可执行的流程。上述流程模型经过这个流程设计器的优化后自动生成应用系统的一个框架，再经过修改和补充后，成为一个完成的流程方案。这个方案和其他一些bpm软件包运行时所需要的组件一起被加载给bpm的流程引擎。该流程引擎负责整个流程的路由、任务的追踪、业务规则的执行以及与外部系统的集成。

如果一个流程的实例完成了每个活动，流程引擎就会生成一个事件来标记这个实例。这些事件由bpm软件包中的性能管理组件负责收集。性能管理据此计算出一些参数来衡量业务效率。

性能管理的仪表盘把通过olap钻取分析出来的参考指标与上述的参数以图形化的方式展现出来。性能管理也可以生成实时的报警信息。一旦kpi（关键性能指标）偏离了设定值，系统还可以自动进行流程的调整，这是由bam(business activity monitoring，业务流程监控）功能模块来完成，通常bpm软件会集成这个模块。实际的性能数据会反馈给流程模型进行调整，从而开始一个新的性能优化过程。

流程之争

如果要对bpm的软件提供的功能进行一下清点，你可以找到一大堆用来完成各种功能的软件: 业务建模、仿真分析、人力工作流、应用集成、数据映射、业务规则、性能分析、业务活动监控（bam）、门户等。在整合的bpm软件包出现以前，这些工具相互独立，分别来自不同的供应商。

不过，今天它们都同属于bpm，被整合进入bpm软件包，或者通过并购，或者通过oem，或者通过合作伙伴的战略。然而，这种转变引发了bpm软件供应商和建模工具、bam及集成中间件供应商之间的一场冲突，因为每个人都想以自己的方式来解读bpm。

最大的冲突源于两种相互竞争的bpm技术架构。其中之一是最受媒体关注的、基于bpel（business process execution language，业务流程执行语言）标准的架构，它通过在sOA环境中集成web服务实现所需的功能，一些大型软件供应商，如ibm、microsoft、oracle、sap,sap,sap,sapsap等都属于这一类。

另一类是纯bpm软件供应商，如fuego、filenet、pegasystems、savvion等。它们的软件架构从上个世纪90年代的工作流系统进化而来，因此在需要将人力工作流集成进流程模型时，它们更好用。在纯bpm软件供应商提供的产品中，sOA、bpel的作用很有限，主要用于应用的集成，而很少像第一类一样用来描述端到端的流程。

他们的区别很明确: 大型软件供应商提供的解决方案更强调bpel，在应用较少涉及人力工作流，即组织中的流程无需多种角色的参与时，能很容易地通过集成web服务实现应用。而纯bpm软件供应商提供的软件主要强调无需编码就可以是实现流程的定制，因此，这些软件更适合特定的行业。而它们的弱点则在于，与那些大型软件供应商的产品相比，纯bpm软件比较难于与已有的应用系统进行集成。

建模工具

无论是专门的bpm软件供应商还是大型软件供应商，建模工具都是其中的一个基本组成部分。这个工具使用一些基本元素，如活动、任务、完成每项任务所需的资源以及相关的业务规则来描述业务流程，最后用业务人员很容易理解的一些图形化的符号来表现他们。

建模工具在流程设计和定量的性能指标、以及通过仿真模拟进行性能优化时起到了十分关键的作用。建模工具在每一个流程活动上标注有相关的性能参数，如预计执行时间、资源成本、可用性以及后续有几个流程分支等。通过建模工具内置的仿真引擎能对各种场景进行分析。分析过程中，kpi将被用来作为分析流程性能好坏的依据，并决定各个参数值，最后根据这些参数对整个流程进行调整，完成一次闭环的业务流程实现。这就意味着建模工具不仅仅是对活动流程进行简单的描述，而是要根据整个组织的资源、流程数据和流程性能参数进行建模。

多年以来，只有casewise、ids scheer、poKPIn (现在叫telelogic)和proforma等提供的业务流程建模工具提供这种能力，而且通常作为企业架构工具中的一部分。然而，如今很多软件提供商，如global 360、ibm、savvion等提供的bpm软件本身已经可以实现这部分功能了。下一步，建模工具供应商要利用bpmn(business process modeling notation，业务流程建模符号)——这是对象管理集团(omg)提出的一种标准化的图形符号，来改善bpm软件之间的交互性。

流程建模工具的输出是一组对业务的描述，用来指导it人员实现所需的业务流程，建模工具将此提交给bpm的流程引擎，流程引擎将启动一个自动的过程来保证流程的自动执行。借助模型的标准符号(如bpmn)和模型交互格式（如cif），模型可以输入到bpm的设计工具中，从而产生一个流程实现的基本框架。虽然这个框架还缺少真正执

行时所需的很多细节，但是它完全可以作为定义业务流程的起点。

通用性问题

1[]