在这里，我们将审视一下市场中的供应商和它们的产品。然后讨论一下BPMS的主要功能应该有哪些，最后我们将回到BPMS技术和业务流程分析与建模（BPA/M）、商务智慧型（BI）、线上分析处理（OLAP）、企业绩效管理（EPM）、业务活动监控（BAM）、业务规则引擎（BREs）、企业事件管理（EEM）、门户、B2B流程、EAI、企业服务汇流排（ESBs）、Web Service、集成开发环境（IDE）的关係上来。

只要不是单个人独立完成全部工作的个人作坊性质，企业从它的诞生起，就存在着流程，并且随着企业的不断成长，其流程越来越多，越来越複杂。几乎每个企业都针对各类业务流程和事务流程有一套规章制度，随着管理的细化和规範化，企业的规章制度是越来越厚，而执行这些规章制度的人却越来越坠入谜团中。

有些企业已经认识到了这点，甚至花巨资请专业的谘询公司来重新肃清流程、规划流程，但很多企业中由于人的原因，如碍于情面、越级审批、不照章办事等，而造成套用的失败。企业业务流程管理系统就能在套用的初期阶段达到这样的首要套用目标，通过系统固化流程，把企业的关键流程导入系统，由系统定义流程的流转规则，并且可以由系统记录及控制工作时间，满足企业的管理需求及服务质量的要求，真正达到规範化管理的实质操作阶段。

除了节省时间和成本的优点外，已经实施BPM的企业也发现了其它几项关键优点。首先，可以大幅降低甚至消除造成企业损失的错误，如丢失表格和档案或错误存档、遗漏重要信息或必要审查。其次，显着改善流程的可视化程度，所有参与流程者不仅被授权了解自己在流程中的角色，而且确切地了解流程在任何时候的状态。第三，有了可视化，也就明确了职责，所有人都完全清楚地知道什幺时候应当完成哪些工作。不再有藉口造成延误、误会或疏忽。最后，可提高一致性，公司内部和外部各方对工作都有明确的期望。结果使得员工、客户和合作伙伴都有了更高的满意度和向心力。

BPM是提供业务流程建模、自动化、管理与最佳化的準则与方法。一个成功的BPM方案包括正确商业领导和技术的组合，可以大幅缩短流程周期（有时高达90%）和降低成本。这种效果在跨部门、跨系统和用户的流程中尤为突出。从技术的角度看，一个独立的BPM系统能够轻易地与现有的套用软体如CRM、ERP和 ECM相集成，而无需重新设计整个系统。

有人做过一个行为分析，发现一个流程的处理时间中90%是停滞时间，真正有效的处理时间很短。并且在流程处理过程中需要人员去用“腿”、用“电话”等其他手段去推进，不仅耗时耗力，而且效果差，时时有跟单失蹤或石沉大海的情况发生。通过业务流程管理系统，利用现有的成熟技术、计算机的良好特性，很好地完成企业对这方面的需求，信息只有唯一录入口，系统按照企业需要定义流转规则，流程自动流转，成为企业业务流程处理的一个“不知疲倦”的帮手。

流程在制定出来以后，没有人能保证这样的流程就是合理科学有效的，即使是当时合理科学有效的系统，由于我们身处的市场环境的变化、组织结构的随之变化、行销服务策略的随之变化，很难说能继续保持这种优势。一套好的业务流程管理系统不仅仅可以具备以上的诸多好处，而且随着流程的执行流转，系统能够以数据、直观的图形报表报告哪些流程制定得好，哪些流程需要改善，以便提供给决策者科学合理决策的依据，而不是单靠经验，从而达到不断最佳化的目的，呈螺旋式上升的趋势。

企业老闆经常环顾员工下班后空蕩蕩的办公室，问自己我的企业还剩下什幺，还值多少钱。而业务流程管理系统通过固化流程，让那些随着流程流动的知识固化在企业里，并且可以随着流程的不断执行和最佳化，形成企业自己的知识库，且这样的知识库越来越全面和深入，让企业向“有生命会呼吸”的知识型和学习型企业转变。如一个新进入公司的员工，他能够通过企业业务流程管理系统很快地熟悉企业及企业的业务处理，并且可以通过流程固化形成的知识库不断充实自己及提高处理流程的难度和水平。

传统的职能式企业组织架构，自有它的套用範围和优势，但我们发现企业的很多流程不仅仅靠一个部门来完成，更多的是企业部门间的协同合作，特别是有些企业还存在着跨地域的合作，如採购流程，它涉及到生产部门、採购部门、库管部门、财务部门、商务部门、契约签署中的法律部门以及企业的高层管理部门。如果我们还以传统的职能部门的思维考虑流程，就可能患“近视眼”、注重部门利益忽视企业利益、重视部门上司的感觉忽视实效，并且还容易导致部门之间权责不清的灰色地带。而作为企业的业务流程存在着各业务部门的天然联繫，其流畅的业务处理是需要各部门以企业的利益为最高利益，协同工作。

业务流程管理系统以流程处理为面向，自动地串起各部门，即利用现在先进的网际网路技术串起各地域，达到业务流程良好完成的目的，并且企业的很多高管人员的意识已远远超出一套业务流程管理系统，更多的希望凭藉这样的系统，形成企业协同工作的团队意识，配合完成自己的企业文化。

1. 业务主管希望企业的流程能够与不断变化的业务环境保持同步，而IT主管希望对不断变化的业务需求迅速做出回响

2. 经营管理者希望对企业流程的执行进行通盘的监控和绩效分析，更好的协调业务，做出更迅速、有效的决策

3. 业务系统越来越多也越来越複杂，完成一笔业务需要人工访问多个系统

1. 基于B/S架构，通过本地电脑、区域网路、网际网路皆可使用，使得企业的管理与业务不受地域限制

2. 客户端无需安装专用软体，使用浏览器即可实现异地、实时业务办理

3. 软体完全独立安装在用户自己的电脑或是伺服器上，提供数据备份工具，数据资料彻底安全

4. 员工许可权分配灵活严谨，可以设定操作人员不同级别的操作许可权，避免越权操作，数据相互保密

5. 初始化简单， Excel导入基础数据功能、数据导出为Excel功能

6. 统计功能强大，多种图形分析

7. 用户数不限，可以任意添加、修改、删除用户帐号

8. 使用期限不限，一次购买，终身使用

9. 安装简单，使用简捷方便，通过三种方法（视频教程、书面教程、电话支持） 使您更快熟悉软体功能

10. 支持列印自定义功能

规则引擎及建模特点

Linkey BPM是新一代基于规则引擎的业务流程管理系统，Linkey BPM中规则引擎是全面基于事件驱动和自动监控的业务规则引擎。Linkey BPM的规则引擎实现了将流程中的业务决策从业务流程的逻辑中分离出来，并使用预定义的语义模组编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

◇ 与EPC相比，主要是改进了EPC模式中的规则概念。在EPC中规则只作为路由规则使用，在LinkeyBPM中规则被提高到一种模型，并引入了规则引擎的概念。在活动的状态变化中均可以由规则来驱动并且可以由节点来触发业务规则。

◇ 与Petri相比，LinkeyBPM主要是增加了事件驱动及规则定义，增加了互动性系统的主动性，去掉了Petri中的繁锁环节(如分支节点必须要有聚合节点配对)

自我学习能力

Linkey BPM是一个会学习和自我成长的基础开发及运行平台。因为Linkey BPM本身是一个开放的框架，企业的IT人员通过Linkey BPM的规则管理功能可以为企业的业务系统规写特定的业务规则程式。 这些程式可以在多个单位和Linkey BPM中进行共享和复用，同时联科软体在项目实施过程中产生的规则程式也会及时的提供给企业的BPM系统。

◇ 通过规则模型库工作流引擎能够自我扩张其功能。

◇ Linkey的实施人员在实施过程中只需维护和编写规则就能完成整个项目的实施。

◇ 这些规则能够传回公司经过最佳化后做为BPM的标準功能然后在网上发布给更多的客户,Linkey的用户只需要上我们的网站就能下载最新发布的规则库下载后就能增强工作流引擎的功能。

◇ 让BPM引擎具有Web2.0的思想,让所有的客户和实施人员来共同完善这个平台。

一、BPMS的供应商分类

我们可以将BPMS供应商分成几类。虽然分类不一定很準确，但它能够帮助我们理解不同的供应商对BPM的理解，它们的产品解决哪些BPMS需求。几乎所有的BPMS供应商都是从技术角度看BPM，因此它们的产品只是间接地满足BPM提出的业务管理原理。这种状态是非常不幸的，因为只有採取一个清晰定义的面向流程的业务管理战略才能成功地实施一个BPMS。不过有迹象显示这种状态正在改变。

目前主要有8类最重要的BPMS供应商：

· 纯粹的BPMS供应商：纯粹的BPMS供应商从一开始就设计了一个BPMS产品，并将它作为自己的旗舰产品。

· EAI供应商：EAI供应商很自然地从它们的软体产品扩展到流程集成和流程自动化上面来。从讯息流到工作流管理服务、活动监控dashboards、绩效管理，这在概念上并无多大飞跃。但是许多EAI供应商还在进一步向业务流程方向发展。

· 工作流供应商：与EAI供应商类似，工作流管理系统供应商能够很容易地进入BPMS市场。一个工作流可以看作是一个结构特别好的业务流程。

· BPA和BPR供应商：现有的业务流程分析供应商靠BPR获得了市场。这些供应商通常都有丰富的流程分析、定义、模拟经验，有些供应商提供的产品具有流程执行、流程监控功能。

· EAS和IDE供应商：这些供应商发现BPM市场商机诱人。它们採取的第一步往往是向IDE添加图形规则驱动或流程驱动的功能和集成功能（尤其是与Web Services和JavaBeans集成），以便快速开发基于流程的套用。要超越这种技术流程观点，就要加入业务流程分析与设计和流程定义驱动的流程引擎。

· 企业套用供应商：企业套用套件（如ERP）内含有植入式的工作流管理和一些EAI功能，这些功能帮助客户进行定製和集成。在目前的市场压力下，它们开始增强这方面的功能，以便更好地适应BPMS需求。

· BRE、BAM、EEM供应商：这些供应商的产品在BPMS中扮演着重要角色。一些供应商正在扩展它们的产品，以提供更加完整的BPMS功能。一些供应商使用规则引擎在流程执行中实施规则驱动的方法。

· BI和OLAP供应商：这些供应商在业务、企业、EPM、dashboards方面的发展使得它们正成为BPMS供应商。它们开始意识到，BPM或工作流管理是满足绩效管理需求必需的功能。它们可能会在分析流之外提供对流程的支持。

二、BPMS的功能

要描述所有供应商实现BPMS的方法是不可能的。因此，我们将描述一个理想的BPMS应该具有的组件。从概念上讲，这些组件可以分成6大类：

· 用户界面

· BPA/M功能

· 运行时组件

· BAM和EPM

· 基础设施

· 系统管理

用户界面和系统管理的功能是十分清楚的，下面就不再做介绍了。

1、BPA/M功能

一个BPMS含有一组BPA/M工具。BPMS的使用者通过这些工具与系统进行互动。这些工具应该无缝集成，以供业务使用者方便地使用。这些工具产生的定义存储在一个知识库内，运行时系统可以直接或间接地访问这些定义。

· 业务流程建模器：业务流程建模工具是BPMS主要的流程设计与流程变更界面。除了传统的流程分析功能——捕捉、设计和修改业务流程及其属性，还需要解决业务功能的操作性属性和界面属性。这些包括资源需求。虽然必定要採用一些流程设计方法论，但建模器在捕捉流程的过程中不应该受到限制，不管是在複杂性方面还是结构方面。它应该允许使用者定义和推行流程标準，为流程设计之间的转换提供帮助。应该根据许可权、功能责任、所需的细节层次提供流程的各种视图。如果要支持流程独立与流程抽取的话，最后一个要求是很重要的。

· IT编制建模器/映射器：IT编制建模器用于定义和维护技术流，如讯息流与数据流、数据转换、IT资源的事务性管理等。在一个理想的BPMS中，它支持业务流程定义与技术编制之间的映射。此外，业务功能也与服务类进行了映射。这种映射过程可以是显式的也可以是隐式的。

· 业务事务建模器：对于业务来说，将业务事务与业务流程事件联繫起来、定义事务性属性的功能是重要的。业务事务建模组件能够满足审计、一致性、错误恢复的业务需求。

· 技术事务建模器/映射器：一个业务事务最终必须转换为一个实施模型，这个实施模型将它映射为一组协调的流、事件、具有ACID（Atomicity、Consistency、Isolation、Durability）属性的技术事务。这个工具用于创建、维护定义和映射。

· 业务标準建模器：只有当业务流程和业务功能与业务标準或关键绩效指标（KPIs）联繫起来时，它们对业务经理来说才是有用的。因此，BPMS的一个关键功能就是要捕捉业务标準，将它们与粗指标（比如由流程引擎或特定的业务功能产生）联繫起来。业务标準与粗指标之间的差异是关键的。比如业务人员对一个业务事务的完成时间感兴趣，而平均排队时间、平均活动服务时间、完成的最可能路径等粗指标则过于技术、过于细节了。业务标準定义影响粗指标的制定。

· 技术指标建模器/映射器：一个业务标準或KPI最终要转换成一组物理或技术指标，以及用于获得这些指标的操作。这个工具用于制定所需的技术指标和由技术指标生成业务标準的方法。

· 业务流程模拟：离散的业务流程模拟对于业务流程的设计、最佳化、故障检查是十分有价值的。它应该提示可选路径的分布、调整基于活动的成本分析中的成本、调整控制流程路径分支的数据值的分布。它还应该对潜在的瓶颈或不一致提供可视化的强调，应该根据使用者的标準识别出最佳的流程设计。它应该能够用使用者提供的数据或历史性数据进行模拟。使用者对可视化的模拟过程和模拟结果的要求也很高。

· 模拟引擎：模拟的有效性取决于对流程引擎的操作性特性的精确表示。模拟引擎与目标流程引擎的匹配度越高，模拟结果就越精确。

· Dashboards：这个工具用于监控流程实例和它们产生的标準数据。Dashboards大致可分为3类：BAM Dashboard、EPM Dashboard和流程监控器Dashboard。

· Dashboards设计器：可能要根据不同的使用者设计Dashboard。这个工具可以利用个性化技术和内容管理技术。

· 业务流程管理者：应该授权一些使用者启动、停止、暂停、重定义或改变一个流程或业务功能实例。他们可能需要修改一条讯息或需要手工分配资源。这个功能显示了BPMS的柔性。

· 业务分析器和报表生成器：业务人员的许多问题都要通过大量计算和分析才能解决。有时候，分析涉及到複杂的统计模型，用户不需要理解这些模型，只要知道任何使用就可以了。用户需要通过报表来浏览分析结果，最好是通过网路传递这些报表。这些工具在一个OLAP系统中是很普遍的，虽然BPMS的业务分析组件还要根据特定业务流程环境进行定製。如果能够提供一个帮助理解特定业务流程的分析帮助库也是非常好的。这种工具通常是BAM和EPM产品的组件。

2、运行时组件

运行时组件是BPMS的心脏。如果没有运行时组件，BPMS就无法执行流程定义、无法管理流程的运行。运行时组件的技术架构、特性和功能在很大程度上决定了操作可用性、绩效、效率和灵活性。

· 流程引擎：BPM流程引擎显然是BPMS的中心组件。它的目标是实现业务流程、管理实时调用和终止业务功能。理想情况下，它不应该规定流程的形式或业务功能的性质。我们认为传统的工作流引擎是BPM流程引擎的一个子集，因此流程引擎也应该能够处理结构化的工作流。

· 分散式的BPM协调器：B2B、B2C、全球化、跨地区或跨部门的业务流程需要一个分散式的流程引擎。这意味着流程引擎要具有远程流程调用、通信和协调功能。在某些情况下，流程引擎之间的对话是通过全局流程来协调的。对话中的每个参与者可能有各不相同的流程视图、安全策略，它们可能将流程的外部部分视为一个子流程。协调器同时也是一种监督器和防火墙。

· 资源管理器：在一个理想的BPMS中，需要一个工具来实现业务功能定义与业务功能实现之间的独立性。这种资源独立性能够让业务使用者优先关注业务目标，改进业务流程定义的鲁棒性，对可用资源进行有效的运行时管理。业务功能可能通过机制、电子手段、软体或手工方法来实现。资源管理器必须为业务功能的执行分配合适的资源，这些资源应该能满足业务功能的定义时需求和运行时需求。当业务功能被调用或激活时，所需的资源必须是可用的。业务功能完成后，这些资源又被送回资源库。通常一个任务可以并行执行，在一组资源中进行负载平衡。如果所需的资源不可用，那幺资源管理器应该自动分配一项替代资源。比如一项本该通过自动化方法执行的任务，可以改用手工方法来完成。

· 调度器：在BPMS中，业务功能的调度是一项重要的任务。如果资源的使用没有限制，如果时间先后顺序没有限制，如果没有外部约束，那幺业务功能就能在前序任务完成之后立即执行。但事实上，这些条件很少能够满足。我们必须考虑授权、负载、能力问题，而且有些功能是由代理执行的，而我们对这些代理不拥有控制权。另外，业务流程和事务通常受到外部施加的时间约束，或者是由外部事件触发的。这些因素使业务功能的调度变成一个複杂的技术问题。如果BPMS没有这个组件，那幺它就无法高效地运行，流程也无法及时执行。

· 规则引擎：一个规则引擎可以增强流程引擎和资源管理器的作用。规则能够表示一个流程容许的转换，从而也能够表示活动之间的控制流决策。规则还能够表示活动的初始条件和完成条件。业务功能的资源需求与资源能力的匹配可以通过带有规则引擎的管理器完成。规则引擎可以帮助资源管理器最佳化资源分配。规则引擎在EAM、EPM中也十分重要，尤其是涉及到事件、标準、回响时。

· 硬体接口管理器：这个组件使得BPMS能够支持活动通过计算机数控、机器人接口、流程控制接口等对机器进行控制。这能够实现对起重机、运河水闸、製造设备、阀门等的操作。

· 界面管理器：如果流程引擎不能与业务功能通信，那幺BPMS就没有什幺价值。它必须用一种协调的方式实现控制流与数据流之间的通信。如果BPMS是与一套集成组件整合在一起的，那幺界面管理器就应该负责整合的操作方面。界面管理器应该处理与适配器、技术编制引擎的通信。

· 工作单管理器：与人力资源的互动需要一些任务交付方法。通常，面向人的工作流管理需要用户登录系统，然后从表单中选择任务。这些表单通常是有优先次序的。现在，任务选择可能会调用一个自动生成的小程式或表单，或者是企业套用中的一个互动功能。工作单管理器应该支持涉及到外部资源的手工活动。

· 知识库：BPMS需要一个成熟的DBMS或知识库来存储数据和元数据。知识库要存储的数据对象有很多，包括业务流程定义、完整性规则、实例日誌、讯息和数据流、业务标準定义和数据、业务分析和报告定义、保留数据、事务定义和数据、安全和政策定义、访问日誌、模拟数据、错误事件和解决方法等。

如果没有正确地集成这些技术性的运行时组件，那幺使用起来将十分不便。但如果能够用一个通用的架构和编程接口将它们整合起来的话，那幺它们就能够形成一个连贯的、协调的单元，增强企业的完整性。

3、业务活动监控与企业绩效管理

对于流程管理，监控事件、分析测评数据、探测趋势、计算KPIs的能力是很关键的。如果没有这些能力，就不能智慧型化地最佳化业务流程或是回响战略性事件创建有效的新业务流程。语义层、分析引擎、规则引擎是BAM（侧重于对实时事件的检测和回响）和EPM（侧重于业务绩效相关趋势的探测、回响、预测）共有的。

· 语义层：这一层处理业务使用者要求的视图与技术性描述之间的映射。这是一个概念层，它允许业务使用者从业务标準、业务对象、平衡记分卡等角度出发监控业务流程。

· BI/分析引擎：在根据底层或技术性标準计算业务标準和KPIs时，通常必须进行複杂的、规则驱动的分析。

· 门户管理和个性化：每个业务使用者都可能要求个性化地展示业务测评数据。如果将dashboards配置为门户，就可以通过门户管理来实现这一点。

· 事件管理：BAM要求监测业务事件和技术事件，要求与规则引擎和分析引擎进行互动以对事件进行分类，确定合适回响，最终执行回响。回响的执行可能涉及到流程的初始化、事件的发起、警告的触发等。

· 企业信息集成：EPM和BAM要求访问各种各样的数据。从概念上讲，这个功能属于一个企业信息集成产品，但大部分BPMS产品都会提供对数据源的集成的访问。

· 内容管理：大部分业务数据是植入文档中的。BAM的内容管理功能使得它能够监测到更度的数据事件。

4、基础设施

下面的技术接口可以是简单的也可以是複杂的，但BPMS中必须具有这些组件。

· 系统管理器：BPMS需要IT支持组件来负责安装、配置、系统管理。系统管理器应该具有企业级软体系统管理器拥有的一般功能。一个系统管理员的工作是非常複杂的，因此系统管理器的可用性和可靠性是十分重要的。它的目标是要消除手工的管理任务。

· 审计管理器：大多数企业要求对业务流程进行审计。审计管理器负责跟蹤流程做了什幺、做出什幺决策、什幺时候、由谁、用了哪些资源。审计条件一旦定义好以后，就应该严格执行。审计点应该与事务边界紧密地结合在一起。审计管理器必须支持跟蹤查询和报表生成。

· 错误管理器：虽然许多错误是可以预测的，可以建立业务流程来对它们做出回响，但总是有一些错误是无法预见的。因此必须通过一种一致的、可审计的方法来管理错误，即使是要用手工的方法来处理错误。错误管理器应该定义错误类别和相关的回响。

· 安全和政策管理器：正如前面提到的，并不是所有代理都能够获得授权执行任何一项任务或活动、在任何时候使用任何资源。BPMS不能违反业务政策，它必须保证安全性。它可能必须支持加密、数字签名、公钥基础设施（PKI）、单点登录等。BPMS必须具备一个涉及到访问、使用、管理的安全模式，因为业务流程可能是最宝贵的智慧财产权。

· 集成基础设施：从一种最底层的角度看，集成基础设施由一组直接连线的适配器组成，提供BPMS与实施业务功能的方法之间的点到点的集成。最低限度上，BPMS需要为手工流程提供一种与人通信的方法。从最高层的角度看，集成基础设施可能是一个完整的业务集成组件。显然，BPMS在一个完全集成的层面上才能够运行好。这个基础设施可能是一个架构在ESB上的传统的EAI、Web Services。

· IDE：随着BPMS的成熟，使用者肯定会想开发出能够充分利用BPMS功能的软体。要做到这一点，就需要一套开发工具。最简单的一个IDE应该能够开发新的适配器和Web Services。使用者很需要能够提供流程驱动的设计与开发的IDE，以建立事件驱动的、基于规则的套用或套用组件。在使用这些IDE工具之前，使用者需要学习集成的流程对象方法论。有时候套用伺服器和套用平台产品会提供流程驱动的IDE。

三. 发展趋势与预测

早期的BPMS产品只具有简单的类似于工作流的功能，几年前发展成为对BPA/M和BAM有最低限度支持的产品，现在它能够支持更加複杂的含有手工和自动化活动的流程。它对BPA/M的支持已经大大改进了，对BAM和EPM的支持也在改进中。

在接下来的4～5中，BPMS还是有很多发展可以期待的。下面的一些发展预测尤其重要：

· 业务流程的範围更加广泛，而且无需将它们转换成高度结构化的等价物

· 设计和监控中业务视图和技术视图的分离

· 意外处理的集成解决方法

· 改进联合与分布能力，更好的支持企业级套用和B2B套用

· 协同的业务流程

· 相互连线的业务流程

· 有力的业务事务支持

· 智慧型的资源管理器，资源独立性更好

· 经验证的标準化的设计与开发方法论

· 具体的实施方法论

· 集成的BAM/EPM，经过闭环最佳化

· 更高水平的绩效、可靠性和可用性

· 标準的但更易于定製的业务流程定义（模板）库

BPM及其相关技术是非常有前途的，这里面有许多潜在的业务利益。但它的实施只有经过仔细研究和量化控制才能取得成功。