业务流程管理系统(BPMS)

BPMS

百科名片

业务流程管理系统(Business Process Management System,BPMS)一套集成的软件。虽然许多供应商的产品还不能实现我们定义的BPM的所有功能，但它们正朝着这个方向发展。作为一个正处在发展中的市场，现有的软件将实现哪些BPM功能是由企业最关键的需求、供应商的背景和可用资源决定的。事实上，一些重要的供应商并没有提供一个集成的系统，它们只是就BPM的一两个特定功能提供成熟的软件或服务。
编辑本段
简介

　　在这里，我们将审视一下市场中的供应商和它们的产品。然后讨论一下BPMS的主要功能应该有哪些，最后我们将回到BPMS技术和业务流程分析与建模（BPA/M）、商务智能（BI）、在线分析处理（OLAP）、企业绩效管理（EPM）、业务活动监控（BAM）、业务规则引擎（BREs）、企业事件管理（EEM）、门户、B2B流程、EAI、企业服务总线（ESBs）、Web Service、集成开发环境（IDE）的关系上来。
　　一、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及其相关技术是非常有前途的，这里面有许多潜在的业务利益。但它的实施只有经过仔细研究和量化控制才能取得成功。