利用业务流程管理（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等都属于这一类。
另一类是纯BPM软件供应商，如Fuego、FileNet、Pegasystems、Savvion等。它们的软件架构从上个世纪90年代的工作流系统进化而来，因此在需要将人力工作流集成进流程模型时，它们更好用。在纯BPM软件供应商提供的产品中，SOA、BPEL的作用很有限，主要用于应用的集成，而很少像第一类一样用来描述端到端的流程。
他们的区别很明确: 大型软件供应商提供的解决方案更强调BPEL，在应用较少涉及人力工作流，即组织中的流程无需多种角色的参与时，能很容易地通过集成Web服务实现应用。而纯BPM软件供应商提供的软件主要强调无需编码就可以是实现流程的定制，因此，这些软件更适合特定的行业。而它们的弱点则在于，与那些大型软件供应商的产品相比，纯BPM软件比较难于与已有的应用系统进行集成。
建模工具
无论是专门的BPM软件供应商还是大型软件供应商，建模工具都是其中的一个基本组成部分。这个工具使用一些基本元素，如活动、任务、完成每项任务所需的资源以及相关的业务规则来描述业务流程，最后用业务人员很容易理解的一些图形化的符号来表现他们。
建模工具在流程设计和定量的性能指标、以及通过仿真模拟进行性能优化时起到了十分关键的作用。建模工具在每一个流程活动上标注有相关的性能参数，如预计执行时间、资源成本、可用性以及后续有几个流程分支等。通过建模工具内置的仿真引擎能对各种场景进行分析。分析过程中，KPI将被用来作为分析流程性能好坏的依据，并决定各个参数值，最后根据这些参数对整个流程进行调整，完成一次闭环的业务流程实现。这就意味着建模工具不仅仅是对活动流程进行简单的描述，而是要根据整个组织的资源、流程数据和流程性能参数进行建模。
多年以来，只有Casewise、IDS Scheer、Popkin (现在叫Telelogic)和Proforma等提供的业务流程建模工具提供这种能力，而且通常作为企业架构工具中的一部分。然而，如今很多软件提供商，如Global 360、IBM、Savvion等提供的BPM软件本身已经可以实现这部分功能了。下一步，建模工具供应商要利用BPMN(Business Process Modeling Notation，业务流程建模符号)——这是对象管理集团(OMG)提出的一种标准化的图形符号，来改善BPM软件之间的交互性。
流程建模工具的输出是一组对业务的描述，用来指导IT人员实现所需的业务流程，建模工具将此提交给BPM的流程引擎，流程引擎将启动一个自动的过程来保证流程的自动执行。借助模型的标准符号(如BPMN)和模型交互格式（如CIF），模型可以输入到BPM的设计工具中，从而产生一个流程实现的基本框架。虽然这个框架还缺少真正执行时所需的很多细节，但是它完全可以作为定义业务流程的起点。
通用性问题
虽然采用像BPEL这样标准的BPM设计语言，但是每个供应商的流程设计工具也只能在它们自己的运行环境中使用。到今天为止，还无法保证一种流程设计结果可以在任意选择的流程引擎上运行，除非从一开始就在人力工作、业务规则、数据映射等方面充分考虑到这个业务流程设计将会在另一个流程引擎上执行。
今天，大多数BPM软件提供了一个统一的设计环境，同时还隐藏了人力工作流、应用集成、业务规则、交易管理等集中在一个可执行环境时所带来的复杂性，这样在企业的IT架构中，这些流程构件可以作为一个个独立的模块对待，其带来的好处就是，整个企业的流程可以采用统一的数据模型和统一的状态管理。
与建模一样，流程设计大多数也是图形化的。设计工具提供了一个配置板，从中设计人员可以选择、配置、安排流程步骤。除非需要对流程进行特殊的定制，一般流程设计几乎不用编程。在图形化的流程设计背后，是BPM软件专有的流程执行语言在运行。
在基于工作流架构的BPM软件中，各个供应商采用自己专门的流程执行语言，但都符合工作流管理协会制定的XPDL(XML流程定义语言)。流程活动一般是一些预定义并已实现了的类型，如Web服务、用户任务、集成活动，以及与这个流程活动相关的资源，如人工活动的角色或者集成适配器等。依据每个活动类型的不同，会出现不同的配置对话框。
与基于工作流架构的BPM软件不同，综合性的BPM软件采用了BPEL语言标准。BPEL只有惟一的一种活动类型，即调用，包括调用Web服务、调用人工任务、调用集成适配器等，所有这些必须用服务实现，并采用WSDL标准来描述接口。调用通过服务的URL地址进行，而不是基于角色。为了适应流程中的人工活动，BPEL调用的并不是人工活动本身，而是调用任务管理服务，再由任务管理服务来处理其中的细节。
两种BPM软件的另外一个不同是，基于工作流的BPM软件支持子流程的概念。子流程是一种可重用的流程片断，它与调用它的父流程具有同样的上下文数据和状态。而BPEL中没有类似的概念，在基于BPEL的BPM软件中，子流程就是另外一种BPEL流程，数据共享和状态同步也都必须在流程逻辑中明确定义。由于子流程在真实世界中客观存在，为克服这个局限，去年夏天，IBM、SAP对BPEL标准进行了扩展，这个扩展是可选的，但整个规范到目前为止还没有完成。不过，尽管架构和程序不同，但基于BPEL的BPM软件的核心功能都是一样的。
实现流程驱动的应用
流程设计完成后，将被部署到流程引擎上。一旦流程开始执行后，引擎会按照预先确定的活动顺序、集成需要的外部应用来执行，如果需要人的参与，引擎会将任务发送给相关的人，引擎还会管理整个流程的执行时间以及意外。在那些应用服务器供应商，如IBM、Microsoft、Oracle、SAP等，提供的BPM软件中，流程引擎只有在它们自己的应用服务器和相关的中间件上运行才能充分发挥流程引擎的性能，而那些纯BPM软件供应商的BPM软件可以运行在任何应用服务器平台上。
为了管理业务流程的性能，流程引擎还能产生流程运行的实时数据和状态报告，通常采用事件的形式。BPM中的性能管理组件将收集这些事件，根据这些事件提供的信息来更新KPI和其他的在建模阶段定义的性能指标。通常情况下，这些指标会被集中在OLAP Cube中，以图表显示或者用户通过管理驾驶舱里的查询获取。基于OLAP的性能管理提供了历史信息和近乎实时的信息报告以及钻取分析报告，因为最新的数据可以按照需要进行采集和更新。一些BPM软件，如Adobe、FileNet、IBM、Intalio、Savvion等公司的BPM产品，支持实时的BAM，可以对指定的KPI指标进行实时更新，并且能报警和自动进行调整。
从正在运行的流程中计算出来的参数可以用来对模型中参数进行优化，进而得到更佳的参数值，从而让流程的修改更有针对性。
BPM软件的选择
选择最合适的BPM软件无疑是一件具有挑战性的任务。尽管每个供应商都在它们的宣传册和网站上承诺提供差不多完全一样的功能，而事实上，每个供应商的产品都有其最佳的应用领域、流程类型和最适合的应用需求。
例如，对专注于金融交易的BPM软件而言，“Straight-Through”流程涉及非常复杂的应用集成，而几乎不涉及人工活动，所以不是需要多人协同、以人为中心而很少涉及集成的流程的最佳选择。而那些以文档为中心的流程、或者需要人工从高速的队列中进行选择的生产工作流流程也有自己的特殊需求，也并不是所有的BPM软件都能满足的。
然而，尽管BPM还是很复杂，比如，从架构上来说，它似乎像一团乱麻，但今天BPM软件正在给用户提供真正的投资回报。而且，新一代集成的BPM软件正在抛弃传统BPM的复杂性，为IT人员和业务人员提供一个崭新的协作平台。最重要的是，BPM正在给用户带来真正的投资回报。 （译自Infoworld）
BPM的四个阶段
从更高层次上说，BPM解决方案的开发过程与其他应用大体一样。不过，BPM的几个特色，如图形化的建模、自动生成应用程序、与老的应用系统集成，可以大大加快软件的开发速度，缩短软件上市时间。
