用以改良商业流程管理系统的方法及设备的制作方法
【专利摘要】一种商业流程管理系统，其包括核心流程模型和高度可配置的扩展组件。所述扩展组件包括扩展流程元件和功能性，它们经配置以连同核心流程元件的一个子集一并操作以便在所述子集上执行特定的商业流程管理功能。所述扩展流程元件和功能性完全与含有所述核心流程元件子集的流程流分离，并且不是所述流程流的一部分，因此，所述商业流程管理功能并不会影响（affect/influence）到所述核心流程流。可经配置用于这些目的的商业流程管理功能的实例包括服务水平协议、商业流程监控及KPI收集、政策遵从性和趋势预测。
【专利说明】用以改良商业流程管理系统的方法及设备
【技术领域】
[0001]本发明大体涉及商业管理流程系统，更确切地说，涉及针对可配置的扩展而提供计算机化的方法及设备，所述可配置的扩展存在并且操作于核心商业流程外部。这些扩展具有高度灵活性，因为它们对商业管理流程系统所提供的元数据进行操作并且可用于实施多种商业流程中的任意一者。
【背景技术】
[0002]本章节陈述仅提供关于本发明的【背景技术】，而且可能不构成现有技术。
[0003]商业流程管理(BPM)是基于IT的商业管理中庞大且不断成长的领域，其中基于IT的商业管理对于成熟商业的成功运作来说是非常重要的。今天的全球市场所需求的效率正是BPM可实现的。另外，当今日常商业任务的庞大规模及复杂性通常要求使用技术来建模并充分理解那些任务。BPM是桥接组织与技术范式的整体管理方法，并且其重点在于联合商业组织的所有方面以更好地提供商业客户的需要和需求。尽管BPM的主要目标是为了促进商业流程的有效性和效率，但是BPM实施的一个同等重要的方面是自身持续流程改进的过程。当商业流程通过使用基于计算机的工具后实现自动化时，它能以一种相对廉价的方式被严格精确地监控和管理，同时其需要的致力于流程管理任务的人力资源最少。这使得商业继续地革新并扩大它们的核心商业，而其财政上或资源上没有过重负担，并且同时监控内部商业流程以实现该商业的运作。
[0004]BPM系统的实施可能非常昂贵，通常需要约数十万美元的投资资本。因此可估计，平均而言，组织的操作中仅有5%是由BPM套件驱动的。为实施BPM功能性，通常需要大量成熟的信息技术(IT)资源来对待捕获和管理的多种商业流程进行定义和建模。一旦被完全地定义和建模，从初始操作的角度来说，可对BPM系统的精确性和稳健性进行广泛的测试。通常情况下，创建BPM的整个初始流程昂贵、耗时并且是IT密集型的，尤其是其需要专家级别的支持。然而，在BPM系统启动运行后,商业与BPM系统的相互作用从对操作流程的定义和实施中的一者变为对那些流程的评估和管理。这正是其商业价值所在。
[0005]然而，出于若干原因，将诸如监控、管理、遵从性等额外流程或功能性直接引入至操作BPM流程流是不理想的。第一，随着BPM管理及监控流程步骤的增多，在每个附加的管理及监控流程中，总BPM流程流开始呈指数型地膨胀。这使得原始BPM系统变得笨拙、低效、无法辨识和不能改变。第二，与初始BPM定义、建模和测试所需的专业IT支持不同，在现存BPM系统上实施的管理、监控及元数据收集流程通常由商业人员或商业分析师定义和创建。因此，当操作型商业流程中含有高阶管理或性能扩展功能性时，必须留住高价位的IT资源。此外，IT人员必须对商业具有一定的熟悉程度以对那些高阶流程进行合适地设计和建模。这是不断进行的对IT资源的昂贵且低效的使用。
[0006]2011年3月8日颁发给阿当多夫(Adendorff)等人的第7，904，302号美国专利，提供了 BPM的完整系统及方法的背景，该专利的全部内容以整体的方式并入本文中。然而，尽管BPM系统处理漫长，但是阿当多夫等人并没有提供高度可配置的灵活机制，其中通过此机制，BPM系统内的操作型商业流程可在最小化核心流程干扰及再定义并且不需要昂贵的IT再编程资源的情况下飞速地改变。因此，有必要在BPM系统设计空间中容纳用于定义和实施非核心BPM流程的灵活高阶BPM编程平台。
【发明内容】
[0007]根据本发明的一个方面，可提供基于计算机的流程管理系统，该流程管理系统具有用于管理流程模型内流程流的流程引擎，该流程流含有多个流程元件，所述流程管理系统包括:安置于流程模型外部并且耦合到该流程模型的扩展组件，其用于与流程流内的流程元件的子集相互作用，所述扩展组件由流程引擎管理并且经配置以执行特定扩展功能。本发明可任选地包括:实施服务水平协议，所述服务水平协议可确保流程元件子集在指定时间段内被遍历；通过收集关键绩效指标而对流程元件子集的性能监控；流程元件子集的政策遵从性的验证；流程元件子集内商业状况的评估和基于此评估采取行动；由扩展组件直接评估的商业状况和包括对流程元件子集的动态流程修改的行动；由扩展组件通过使用为流程模型一部分的规则引擎来评估的商业状况和包括对流程元件子集的动态流程修改的行动。本发明还可任选地包括:特定扩展功能，该特定扩展功能包括基于有关流程模型的统计历史数据对流程元件子集内流程趋势的预测；特定扩展功能，该特定扩展功能包括流程元件子集内的警报监控；特定扩展功能，该特定扩展功能包括对流程元件子集内商业状况的评估以及基于此评估采取行动；多个扩展组件，所述扩展组件用于执行多个特定扩展功能；或商业流程管理系统，其中流程模型是商业流程模型，流程引擎是商业流程引擎，流程流是商业流程模型内的商业流程流，多个流程元件是多个商业流程元件，以及由扩展组件执行的特定扩展功能是特定商业扩展功能。
[0008]在本发明的另一方面中，可提供基于计算机的扩展组件用于流程管理系统中，所述流程管理系统对流程建模并且具有用于管理所述流程模型内的流程流的流程引擎，所述流程流含有多个流程元件，所述扩展组件包括:用于耦合至流程管理系统并与之通信的扩展基础；具有设计时间组件和运行时间组件的扩展框架，其中设计时间组件包括有包括用户界面的环境系统，运行时间组件包括用于执行扩展组件流程的流程引擎，其中扩展流程与流程引擎结合操作，但从所述流程元件去耦掉所述流程元件的一个子集并且由用户配置以执行特定的扩展功能。
[0009]在本发明的又另一方面中，可提供用于对基于计算机的流程管理系统进行操作的方法，所述流程管理系统具有用于管理流程模型内的流程流的流程引擎，所述流程流含有多个流程元件，所述流程元件的子集包括开始事件和结束事件，所述方法包括:捕获与流程流内的流程元件的子集相关联的开始事件；在捕获到开始事件时激活含有扩展模型流程元件的扩展组件，所述扩展组件流程元件与流程流内的流程元件子集是分离的并且与之并行操作；执行扩展组件流程元件，直到发生以下任一情况:在流程流内达到结束事件或通过扩展组件确定不能达到结束事件；以及终止扩展组件流程元件的执行。进一步包括以下方法，其中激活步骤包括激活扩展模型流程元件以执行服务水平协议，所述扩展模型流程元件包括服务水平协议，所述执行步骤进一步包括以下步骤:激活与流程元件子集相关联的子流程定时器；监控子流程定时器以确定流程元件子集的子流程执行时间；以及在子流程时间超过最大子流程执行时间时触发警报。还考虑到以下方法，其中捕获步骤包括对流程数据变化的检测并且激活步骤包括激活扩展模型流程元件以执行性能监控功能，所述扩展模型流程元件包括性能监控功能，所述执行步骤进一步包括以下步骤:收集与所述流程元件子集相关联的关键绩效指标；以及向扩展组件报告关键绩效指标以对所述流程元件子集的性能进行评估；或者其中激活步骤包括激活扩展模型流程元件以执行政策遵从性功能，信息扩展模型流程元件包括政策遵从性功能，信息执行步骤进一步包括以下步骤:评估所述流程元件子集对一个标准的遵从性；评估所述流程元件子集遵从上述标准；以及在所述流程元件子集不遵从上述标准时触发警报。还任选地包括以下方法，其中所述激活步骤包括激活扩展模型流程元件以执行警报功能，所述扩展模型流程元件包括警报功能，所述执行步骤进一步包括以下步骤:针对所述流程元件子集在正常流程范围外的状况进行监控；当流程元件子集在正常流程范围外时触发警报；或者以下方法，其中所述激活步骤包括激活扩展模型流程元件以执行趋势预测功能，所述扩展模型流程元件包括趋势预测功能，所述执行步骤进一步包括以下步骤:评估与所述流程元件子集相关联的历史操作；以及基于评估而对至少一个所述流程元件子集进行调整。
[0010]最后，本发明的其他方面还包括计算机可读媒体，其具有可执行指令以用于引发处理器来执行上述方法。
【专利附图】
【附图说明】
[0011]附图并入本说明书中并构成本说明书的一部分，展示了本发明的各个实施例，并与【具体实施方式】一起解释本发明的原理。图中相同的标号代表相同的元件，图示出这样的元件是为了简单清晰起见并且元件无需按比例绘制。这里所示的实施例均是目前优选的，然而，应理解，本发明并不限于所示的精确布置和工具，其中:
[0012]图1为示例性商业流程管理(BPM)的架构图；
[0013]图2为根据本发明一个实施例的示例性BPM扩展架构图；
[0014]图3A、3B和3C所示为示例性BPM流程模型，其中图3A和图3B中流程流中嵌入有高阶扩展流程元件，而图3C中，此类元件从流程流中清除；
[0015]图4为根据本发明的扩展流程的操作流程图；
[0016]图5为对应于服务水平协议功能的流程事件图；
[0017]图6为对应于实时商业监控功能和关键绩效指标功能的流程事件图；
[0018]图7为对应于政策遵从性功能的流程事件图；
[0019]图8为对应于趋势预测功能的流程事件图；以及
[0020]图9为多个扩展组件及扩展流程应用于流程流的图示。
【具体实施方式】
[0021]这里提供对本发明某些方面进行描述的说明性实例以帮助读者对本发明有个清晰的了解。然而，应了解，这些图解并不意图限制本发明范围，而是经本文提供以用于图示与本发明相关的某些概念。
[0022]还应理解，可通过如软件、硬件、固件、专用处理器的各种形式或上述形式的组合来实施本发明。本发明优选地作为包含在程序存储装置上的可触摸程序在软件中实施。该程序可上传至包括任一合适架构的机器中，并且可由该机器执行。一方面，该机器可由具备诸如一个或多个中央处理单元(CPU)、随机存取存储器(RAM)和输入/输出(I/O)接口等硬件的计算机系统来实施。该计算机系统还包括操作系统和微指令代码。本文所述的各种流程和功能可为通过用于管理机器的操作系统而执行的微指令代码的一部分或程序(或二者组合)的一部分。此外，可连接多个其他的外围设备至计算机系统，诸如额外的数据存储设备和打印设备。也可连接该计算机系统至网络，本文所述的程序、数据、规则、功能和其他任何组件可在该网络中存储和/或可供计算机系统使用，或者通过此网络用户可查看和/或可向计算机系统提供控制机制。
[0023]应理解，由于附图所示的一些构成系统组件和方法步骤优选地在软件中实施，所以系统组件(或流程步骤)之间的实际关联会依据本发明编程方式而发生变化。如图1至图9所示，本发明优选地通过使用通用计算机系统实施。然而，可通过使用一个或多个经编程的通用计算机、经编程的微处理器或微控制器及外围集成电路元件、ASIC或其他集成电路、数字信号处理器、硬线电子或逻辑电路(诸如分立元件电路)、可编程逻辑装置(诸如PLD、PLA、FPGA或PAL等)的任一组合来实施本发明的系统和方法。通常情况下，能够实施有限态机器的任一装置可用于实施此系统，其中有限态机器转而能够实施本文所述的任意流程图或流程流。
[0024]应注意，某些术语在整篇说明书中互换地使用。这种做法并不会对术语的具体定义造成混淆，相反地可简单地区分核心商业流程与非核心商业流程。至于核心商业流程，替代性术语包括操作流程、流程中(in-process)、飞行中(in-flight)和基础流程。至于非核心商业流程，替代性术语包括管理商业流程、高阶(商业)流程和扩展流程。
[0025]图1提供根据本发明的BPM的示例性服务器架构I。提供流程数据库10 (例如，微软SQL服务器、Oracle)用于存储涉及持续流程模型、流程状态和流程管理的数据。所示的BPM服务器20包括各种具有流程执行引擎的元件，并且执行以下功能:流程执行引擎、流程模型管理、流程状态管理、负载平衡管理、角色权限管理、流程交换管理、流程异常处理程序、流程归档和恢复服务、流程模型部署服务、通知服务和流程时间服务。提供基于服务的应用程序开发接口(API) 30用于访问BPM服务器功能，例如，部署流程模型、初始流程实例和/或管理/更改运行时间流程实例。该接口支持标准的web服务功能和windows通信功能。还提供流程设计器(建模工具)40用于使流程分析师和开发人员在BPM系统内对流程进行建模处理。所示的开发加载项组件50提供了项目类型和基础功能以开发用户自定义扩展组件。所示基于web的仪表板60用于管理流程模型、流程、任务、用户、角色运行时间流程和运行时间模型。可提供用户自定义应用程序70，并且如果提供用户自定义应用程序70，则该应用程序通过基于服务的API 50与BPM服务器形成一个整体。数据库80用于存储持续的用户自定义应用程序数据。抽象框架90能够在设计时间利用其自身用户界面通过访问流程模型和流程元数据来使用户自定义扩展组件和流程设计器(模型)相互作用。它也使扩展组件变得可配置、可再使用并且可见，同时不需要理解模型和元数据内所有基础细节。在运行时间，用户自定义扩展组件接收由框架中继的被同意的流程事件，并且通过服务器端API改变流程行为。用户自定义组件95构建在抽象框架的顶部105 (见图2)，在BPM引擎运行时间背景下运行，并且通过服务器端API事件处理程序而与引擎发生相互作用以动态地改变流程模型的默认行为。该框架支持四种类型扩展模型:人类活动(例如流程步骤)、系统活动(例如访问数据库)、扩展组件、系统连接器(例如扩展服务器功能性)。[0026]图2提供根据本发明的扩展组件的示例性扩展组件的架构100。商业流程管理基础101提供基本功能性以访问BPM服务器10。此类功能性实例有流程定义、运行时间流程实例和任务。在设计时间处，一个或多个用户自定义扩展组件可与流程建模工具中的流程模型102 “相关联”(不是作为流程模型元件插入)从而使流程模型在运行时间时一经要求即可选择触发或启动扩展组件功能性。该用户自定义扩展组件103能够在设计时间通过抽象框架来访问流程模型和流程元数据(XML格式)。该组件作为流程设计器(建模工具)上的加载组件而运行并且为配置提供用户界面，该用户界面通过抽象框架而持续作为流程模型的一部分。引擎在其驱动运行流程时(例如结束/开始流程或分配/取消任务)启动事件104。该引擎在外部应用程序递交请求时(例如，当发起流程时，当暂停流程时，当分配任务给用户时，当更新流程状态时，或当再分配任务给替代用户时)也可启动事件104。抽象框架将把事件中继到用户自定义的组件，前提是该组件同意该事件，随后该组件提供反馈给引擎。例如，当流程状态正在进行更新时，如果它与公司政策不一致，那么该引擎将取消该更新的交易。该用户自定义组件还可基于其设计和配置而通过服务器端API来动态地改变流程行为105。例如，当分配任务时，资源优化组件可检查所分配任务的数量并且平衡工作负荷，并且对可能的资源分配程序发送警报。服务器端API 106用于在执行引擎并且安全的背景下直接访问引擎功能。
[0027]参看图3A、图3B和图3C，提供了简化商业流程的两个版本来说明本发明的益处。首先参看图3C，图中提供有示例性商业销售流程，其中关键绩效指标(KPI)将在商业管理流程中收集。根据该简化流程，无KPI收集时，流程开始于步骤202，向流程元件210进展，此处可获得客户详细信息或本地详细信息。随后在流程元件212处创建呼叫记录条目以记录关于客户接触的详细信息。是否发生销售由流程元件214确定，并且如果发生销售，那么流程元件216会执行延迟功能直到产品已交付。在产品交付后，执行售后跟进决策流程元件218并且如果该跟进符合要求，那么在执行流程元件220时记录售后跟进的详细信息，此后，流程在流程元件290处结束。返回至决策流程步骤214，如果没有发生销售，那么随后在决策流程元件240处会作出决策以再分配任务(例如，给其他人员)或升级任务到另一个流程或决策层次，并且如果决策是积极的，流程元件242处发生再分配或升级。流程随后在流程元件290处结束。如果决策流程元件240处的决策是消极的，那么在决策流程元件244处会作出关于是否需要跟进的判断。如果需要跟进，则执行跟进延迟流程元件246，在流程元件248处的跟进记录中创建数据条目，以及在决策流程元件214处再执行关于销售发生的再评估。如果在流程元件244处不需要跟进，随后流程在流程元件290处结束。
[0028]现在参看图3A和图3B，提供了扩展型商业流程，在此流程中调查潜在客户的简单管理流程直接插入到上述的操作型商业流程中。阴影流程元件260至288指代这些附加流程。紧随着决策流程元件214-“销售是否发生”(图3C中一样)，图3A提供了可查询客户是否为现有客户的流程元件260，，而非延迟流程元件216。如果客户是现有客户，商业流程前进至客户销售增量流程元件262并且随后前进至流程元件264处的确定功能，在流程元件264中，可基于自商业流程所要求的上一次调查以来交易的特定数量，来确定通信调查候选人。确定功能流程元件264也可直接达到，前提是现有客户决策流程元件260返回“否”。
[0029]继续参看图3B，管理调查流程从决策流程元件266处继续，在此处可决定出销售是否为调查候选者。如果销售是调查候选者，在流程元件268处执行“设置已调查标记”;在流程元件270处执行“发送通信调查请求”功能；在流程元件272处执行“通信调查”功能。随后，如之前所述流程，流程流进展至流程元件216处的延迟功能。
[0030]图3B中在流程元件216处延迟功能后的并行流程路径处还引入了管理调查流程的另一部分。与决策流程元件218处售后跟进并行的调查决策步骤“已调查？ ”在流程元件280处执行。如果结果是肯定的，则流程在290处结束。如果结果否定，则随后在流程元件282处执行确定功能，在该流程元件282中，可基于自商业流程所要求的上一次调查以来交易的特定数量，来确定通信调查候选人。此后，在流程元件284处执行决策流程元件“有调查候选者？ ”。如果结果否定，则流程在290处结束。如果结果肯定，则随后在流程元件286处执行流程功能“发送产品调查请求”，在流程元件288处执行产品调查功能，并且流程在290处结束。
[0031]应了解，图3中提供的原始操作销售流程的整体复杂度由于引入相对简单的管理(调查)流程而大大地增加。与图3C相比，图3A和图3B中流程元件数量几乎是加倍的，并且由附加流程元件导致的感知混乱可轻易致使相对简单的操作销售流程变得让人费解。对应于BPM环境内传统架构方法，企业将不得不描述他们需要添加至流程中的“调查”功能，这可通过添加“阴影”的额外步骤至流程中而实现，之后IT专家可编出程序代码以永久且稳固地添加此性能。
[0032]此外，从IT角度出发，必须创建数据存储区并将其配置在BPM系统中以容纳由额外的流程元件创建的额外的数据和元数据。这个需要初始BPM流程定义和建模中数据库管理员或数据架构者的额外服务。需要创建输入/输出(I/O)服务(例如，web服务)以提供不断更新的功能，从而增加了相关研发时间和成本。可能最大挑战是，对核心操作型商业流程进行设计和建模的IT员工必须在商业分析师的帮助下扩大其作用，其中包括对操作型商业管理流程内的大量不协调管理流程进行设计和建模。这些问题的每个问题均随着每个附加流程而呈指数型的增长。其中不理想的结果有:不断膨胀的相关设计和建模的IT预算、鉴于原始计划流程提供其所产生的商业流程时带来的混乱，以及连同操作型商业流程一起的BPM系统所执行的慢速计算处理。
[0033]十分有利的是，提供这些额外流程(图3C中的294)以及基础商业流程顶部相同的覆盖层，这是本发明的关键部分。根据本发明的一方面，这是用覆盖架构式元件292来提供的，即，图2中BPM服务扩展框架100。此元件与BPM套件的流程引擎32协调管理，因此，高阶流程元件定位在核心流程模型的外部而不是直接插入核心流程流中。这些高阶流程元件是包括扩展流程的扩展组件的一部分。对通过服务扩展框架内的扩展组件来定义、建模和执行的每个扩展流程而言，可识别核心商业流程内相关的流程元件的一个子集。核心商业元件的该子集构成流程元件的一个范围或范畴以供扩展流程在此范围或范畴内进行操作。该核心流程元件子集包括开始事件流程元件和结束事件流程元件。仅在到达开始事件和元件时激活扩展流程并且在到达结束事件和元件时终止扩展流程，否则可确定无法回到结束元件。一旦扩展流程终止，并且核心流程元件不在范围内，扩展流程就不再对其相关联的核心流程变量、外部数据、商业规则、政策或其它数据/元数据中的任意一项中的变化作出响应。
[0034]应了解，尽管上述关于图3A至图3C的说明描述了添加的非核心流程，但是更广泛的理解是，扩展组件能够添加任一自定义功能或任一流程，所添加的自定义功能或流程可帮助非技术型商业用户利用和控制所述自定义功能，这可通过利用用户界面对话框与其交互以提供不同输入值或选择的组来实现。一旦开发人员创建出扩展组件，商业用户就能够通过向用户界面(UI)提供不同输入值或选择来控制扩展组件的执行，UI随后将引导核心流程以产生动态添加的功能或行为，尽管在设计核心流程时起初并未考虑到这些功能。另外，同样的扩展组件并不需独一地应用于仅仅一个特定核心流程。一般地，可通过动态地添加扩展组件至任何流程(即，针对不同目的所设计的不同核心流程)的任一运行流程实例来实现扩展组件的预期功能。这样的话，扩展组件的重要成就是高生产率，即，BPM扩展组件解决方案需要具有高生产率以便能够提供非核心流程的流程优点。
[0035]作为扩展模块以这种方式执行的另一个实例，可假设，公司最近雇佣一些新销售人员并且他们参与图3C所示的销售流程。由于新销售人员数量增加，销售经理可能担心他们在初始培训后是否真的能达到可接受表现水平。为验证此问题，销售经理决定了在元件214处衡量销售(或未销售)来作为确认表现水平的一种方法。如果销售失败，可采取跟进路径；如果流程执行对元件248与元件214之间路径的遍历超过指定次数(例如，2、3、5或任一合适数量)，那么经理可要求收到警报。在这种情况下，可创建扩展组件来提供一般性功能，用于对流程中任意两个元件之间的流程执行进行监控，以确定该执行发生次数是否超过给定的次数值。在这种情况下，注意以下内容是非常重要的:
[0036]扩展组件的预期功能可能不会在流程(或核心流程)中产生额外的可视元件。相反地，扩展组件可能简单地执行由程序代码实现的监控和警报功能。然而，并非是在流程元件248和214附近永久地添加这样的代码，“监控和警报”功能可以是“一般性的”和“浮动的”，并且可以动态地添加到任何流程(或针对不同目的设计的核心流程)中的任何两个元件。在这种情况下，此扩展模块的用户界面对话框UI可含有最少3个输入字段，例如: [0037].流程元件识别#1
[0038].流程元件识别#2
[0039]?用于判断两个流程元件的流程路径之间的执行重复发生多少次后导致警报发生的一个数字。
[0040]此扩展组件UI对话框可选则性地包括的输入字段有:
[0041 ] ?开始日期(此监控和警报何时将开始)
[0042]?结束日期(此监控和警报何时将结束)
[0043]这将使经理能够确定图3C所示的流程中的元件248与214之间的此监控和警报将在多久后可用。
[0044]因此，扩展组件所例示的动态插拔功能可能并不总是“表示”添加额外流程元件至流程(或核心流程)。或者，扩展组件可表示一种可动态插拔的一般性功能/功能性，它可提供如动态地添加以下各项至一个或多个流程(核心流程)一样的效果:
[0045].流程(核心流程)的一个或多个流程片段，如在核心流程初始设计时已将其考虑到的情况一样
[0046].不可见或不明显的功能，例如上述实例中监控和警报功能(传统地可能需要通过添加基础代码而实现并且这种基础代码实现的功能或功能性现可动态地添加至任何流程(核心流程))。
[0047]虽然具体参考了扩展流程的扩展功能和管理的应用而提供如下说明，但是应注意，这些概念可更广泛地作为上述的扩展组件功能性使用。
[0048]现参看图4，提供正式高层次的流程流301，用于在BPM套件与BPM服务扩展间协调的组件。如图4所示，由BPM捕获开始事件——310，随后激活扩展组件——320。流程引擎随后执行扩展组件内的操作以执行作为扩展组件设计目的的功能——330。这些功能的实例在下面描述的说明中提供。如340处所示，这些功能继续由扩展组件通过执行相关扩展流程元件或功能来执行，直到发生以下两种情况中一种:核心流程内的终止事件和元件被组件检测到(沿着“是”的路径)，或者可确定终止事件和元件不可能被达到(沿着“否”的路径)。在任一情况下，任意终止后扩展组件操作、行动和/或报告功能可在流程全部终止前由扩展组件370执行。
[0049]在扩展框架的帮助下可实施任一数目的扩展流程。下面描述若干这类高度有用的流程。应注意，用于下面各实例的实际扩展流程元件在除了以高层次图形显示和附文的形式外没有具体显示。本领域的技术人员应清楚了解，这些扩展流程可配置在多种不同布置中的任意一者中，可配置在多个不同平台上的任意一者上，且能够处理由基础流程产生的元数据，因此可执行下述功能。比具体流程元件更重要的是流程元件与相关联基础流程的面对面的相互作用，这是这些扩展流程描述的重点。
[0050]参看图5，提供了扩展流程401，用于实施服务水平协议。服务水平协议的目标是确保基础流程遍历若干步骤或位于指定时间框410内的步骤块420，否则将发送警报至流程的所有者或者触发另一个流程来处理滞后流程。时间线405由扩展流程监控。服务水平协议扩展流程当它在时刻ts在基础流程内捕获到开始事件和元件A2的执行时激活。在基础流程执行流程元件A2至AS时，服务水平定时器407由扩展流程启动来开始监控时间通道。一旦在te时刻达到终止事件和元件AS，扩展流程捕获该事件并停止服务水平定时器。服务水平扩展流程随后可结合任何其他终止后功能，实时地或作为其他报告的一部分，而将执行时间报告给其他扩展流程或基础流程，即图4中的370。然而，如果在基础流程执行过程中，不能在预设的最大流程持续时间td内达到基础流程AS，那么扩展流程可开始执行异常处理程序，由此，可向BPM系统用户(流程所有者)提供警报或通知。或者，或除了人类感知的警报和通知外，服务水平协议扩展流程可能引起其他扩展流程或基础流程来处理过期的基础流程。预设的最大基础流程持续时间可编码为扩展流程编程的一部分或者它可以BPM系统内产生的实时元数据的形式提供。
[0051]参看图6，提供了在扩展流程中编码的实时商业监控功能，其中扩展流程通过关键绩效指标(KPI)而使用操作型商业智能(BI)。操作型BI KPI可由BPM系统所管理的自动商业流程非常容易地收集。然而，使用传统基础流程元件来执行该收集是艰难的、难以修改的，并且趋向于使流程模型变得非常庞大而复杂。扩展组件是用于在不改变核心商业流程模型的情况下收集操作型BI KPI的理想选择。由于KPI提供的对周全的工作职责或工作单元的业绩的洞察是很必要的，因此扩展组件的可配置范畴还理想地适用于操作型BI。例如，如果KPI追踪销售部门的业绩，那么导致无销售完成的售后纠纷(例如，由于运输部门出现问题)将不会反映在仅与销售相关的KPI中，这是很必要的。与流程元件的另一个周全的范围相关联的分离的KPI，可理想地经配置以识别和直接链接与运输部门相关的性能问题。
[0052]再次参看图6，提供了扩展流程501来实施商业数据监控功能以及相关操作型BIKPI的收集。如上所述，商业数据监控功能的目标很多，包括监控指定关键商业数据的生命周期和衡量商业流程的性能(如KPI)。此外，BI可通过与BPM系统中BI组件相整合的数据，实时且快速地响应市场变化。监控开始于扩展流程对操作的投票和追踪，以确定核心流程内是否有步骤块520 (子集)。此流程块中各元件均由已编程的扩展流程监控，所述扩展流程用于监控具体商业功能及其性能，例如，上述的销售功能。触发事件和元件A2，例如，一个单元的销售，可由扩展流程捕获，此后该扩展流程被激活。由于核心流程520的子集执行流程元件A2-A8，所以扩展流程510继续监控和收集商业数据和KPI。此数据可能之后被商业智能(BI)组件共享在仪表板514上呈现给BPM系统用户。根据图4中的高层次流程，此商业流程监控将继续进行直到达到结束事件和元件AS，例如，客户付款单据。扩展流程捕获该事件并且终止已售出的特定单元的商业监控(扩展)流程。也就是说，根据商业单元的预编程商业规则，此单元完全“售出”。此时，其他商业监控流程可开始或者相反地继续在特定的售出单元上操作以验证销售循环中其他时刻的流程完整性。商业监控扩展流程可实时地或作为其他报告一部分，或与其他任意终止后功能结合，向其他扩展流程或基础流程报告某些数据，即图4中的370。在商业流程监控中的任意时刻，扩展流程可开始执行异常处理程序，由此向BPM系统用户(流程所有者)提供警报或通知，例如，当由于某种原因过多初始销售被撤消时。或者，或除了人类感知的警报和通知外，商业监控扩展流程可能弓I起其他扩展流程或基础流程来处理异常流程。异常流程的阈值可为预设的最大值或量(例如，撤消的销售的固定数目)，可编码为扩展流程编程的一部分，或者可以BPM系统内产生的实时元数据的形式对其进行确定。
[0053]图7所示为根据本发明的可在BPM扩展组件上操作的扩展流程的又另一个实例。在此政策遵从性实例中，必须验证商业流程遵从于公司的商业政策，或者规则。如上文参考图3A至图3C所示，如果要求开发人员创建或插入有关遵从性的流程元件，那么核心流程模型可变得非常复杂，这转而将冻结流程模型，且令流程改变更加困难。本发明的扩展组件能够将政策监控功能和流程模型去耦。这样有效地将BPM系统角色与政策所有者和流程设计者分离开来，由此给予政策所有者更多的自由来改变政策的实施，且无需担心对流程模型的任何影响。这样使商业流程更节省成本且更易管理。
[0054]图7提供了政策遵从性扩展流程601，用于监控商业流程的遵从性的各个方面。任意给定的监控和遵从性验证功能中可牵涉到若干核心子流程。例如，核心流程元件子集可负责确定对政策遵从性620的需求，并且核心流程元件的其他子集可能需要一般政策遵从性的监控和验证，例如，子集622是针对财政政策遵从性，或子集624是针对工业遵从性。在根据图4的流程操作的其他扩展流程中，遵从性功能，无论其是需求识别或遵从性监控/验证，随着事件和元件(A2-A8)被扩展流程捕获，其后政策遵从性扩展流程启动，它都会由事件和元件触发。当执行核心流程元件子集时，扩展组件610、612和614内的扩展流程持续监控流程元件子集的操作。根据图4的高层次流程，这项政策遵从性监控持续执行，直到达到结束事件和元件或可确定政策遵从性扩展流程不为所需或不能被验证。扩展流程捕获该事件，并且结束用于政策遵从性功能的政策遵从性扩展流程。商业监控扩展流程可实时地或作为其他报告一部分，或与其他任意终止后功能结合，向其他扩展流程或基础流程报告某些数据，即图4中的370。在政策遵从性监控中的任意时刻，扩展流程可开始执行异常处理步骤，由此向BPM系统用户(流程所有者)提供警报或通知，例如，当确定违反政策时。或者，或除了人类感知的警报和通知外，政策遵从性扩展流程可能引起其他扩展流程或基础流程来处理异常流程。异常流程的阈值可为预设的最大阈值，其可编码为扩展流程编程的一部分，或者可以BPM系统内产生的实时元数据的形式对其进行确定。
[0055]图8所示为趋势预测流程，其可作为根据本发明的可在BPM扩展组件上操作的扩展流程的最后一个实例。当BPM系统累积到历史流程数据的某个量时，扩展组件能基于同一流程模型的流程状态和统计历史数据而提供关于指定流程步骤处的流程的有用的趋势预测。通过对流程里程标的评估，趋势预测流程能帮助企业确定流程势头的波动且相应地调整资源。
[0056]再次参看图8，提供趋势预测扩展流程701以用于监控商业流程的历史操作并且随后提供响应于其的趋势识别功能。趋势预测开始于扩展流程对操作的投票和追踪，以确定核心流程内是否有步骤块520 (子集)。。此流程块中各元件均由已编程的扩展流程监控，所述扩展流程用于监控关于流程性能的历史趋势。先于监控功能，假定扩展组件710已收集流程历史数据712并对其做出评估。在核心子集流程执行过程中，指定里程标事件和元件A5可由扩展流程所捕获，其后，激活趋势预测扩展流程。随着核心流程元件子集720的执行，趋势预测扩展流程710持续检测里程标流程元件A5的执行。根据图4中高层次流程，该里程标监控持续执行直到达到终止事件/元件。应意识到，趋势预测扩展流程可继续不减退地执行一段时间以用于历史分析和相关的趋势预测。因此，中断事件，例如在里程标元件A5处与历史流程趋势的巨大偏差，可有效地终止扩展流程以报告或提供涉及与历史趋势相关的里程标功能的警报。在任一情况下，扩展流程都将捕获该事件并且在一段时间内可能或可能不中止扩展流程的趋势预测运作。此时，其他商业流程可开始或者继续连同趋势预测扩展流程一起操作，并且这些流程可与其他任意终止后功能结合，实时地或作为其他报告716的一部分，，向其他扩展流程或基础流程报告某些趋势数据，即图4中的370。在趋势预测流程中的任意时刻，扩展流程可开始执行异常处理程序，由此向BPM系统用户提供关于趋势元数据的警报或通知。或者，或除了人类感知的警报和通知外，商业监控扩展流程还可能引起其他扩展流程或基础流程来处理异常流程。异常流程的阈值可为预设的最大趋势偏差值，其可编码为扩展流程编程的永久的一部分，或者可以BPM系统内产生的实时元数据的形式对其进行确定。
[0057]在一个更成熟的布置中，本发明的扩展组件能够执行具有高级用法以及极微妙操作的流程。尤其在多个扩展组件及其关联流程嵌套起来或并行使用(图9所示)时，更是如此。如图9所示，多个扩展组件能全部并行地在扩展框架上运行，以便执行它们各自功能且不会对核心流程造成破坏。分离的扩展组件可分成810、812和816三层，它们通常可由具有周全工作职能的不同个体来分别维持。在图9的示例性图中，图示有在基础商业流程上并行地操作的三个扩展组件:商业监控功能810、商业准则评估功能812和监控和警报功能816。只需要少量扩展组件，各流程即可进行调适，否则在使用传统“流程中”元件的情况下，可能需要数百个或数千个的流程元件。作为一个实例，操作型BI KPI阈值可由BRE的条件所驱动，并且在通过可接受阈值(在BI的I/O仪表板中的“黄色”至“红色”的转换中显示)时，扩展组件可触发特殊的响应或升级计划。对传统商业流程中这个层次的功能性建模非常复杂，但是可利用以本发明方式操作的少数的嵌套扩展组件来实现此建模。
[0058]其他商业流程功能也能通过扩展组件的使用来实现。一个十分有用的实例是扩展组件在基于云计算环境的大规模定制方面的应用。可以想象，当可利用BPM的应用需要多租户支持时，该组件是必需的。由于各客户可能需要定制他们自己的流程模型，因而流程模型定制可能需要巨大的潜在的重复工作。那些流程模型中的每个模型在高层次处可能都是相似的，但是可以想象到，由于已存在的动态改变的可能性，每个模型的低层次细节是不同的。本文所述的扩展框架提供一种非常独特并且强大的用于流程模型中的大规模定制的解决方案。例如，扩展组件可应用至流程模型，从而可通过扩展用户界面或API在设计时间配置或在运行时刻连接，且无需改变流程模型。它提供比传统定制方法更具适应性和动态性的流程模型。
[0059]商业规则和复杂事件流程:如果要在评估流程元件范围内评估具体商业条件，则需要大量的工作或在所希望的流程范围内配置各元件，或添加空隙流程元件以执行此评估。与包括流程元件全部范围的子集相关联的扩展组件可提供中心场所来对评估状况并且可任选的基于此评估所采取的行动进行定义。此条件可直接在扩展组件中定义，或由BRE提供。如果需要采取任何行动，可执行对分离流程、子流程或动态流程的修改。这些类型的动态的流程状态触发的行动通常在复杂事件流程(CEP)的标题下分组。
[0060]监控、警报和统一通信功能:当商业流程出错时，通常有一个共享响应及升级计划可用于分支部门、部门或工作小组。扩展组件可使此计划在一处定义并且在流程元件整个范围内共享。直接将监控及警报机制、升级流程流和统一通信特征添加入流程模型会添加大量的流程元件并且使流程模型相当复杂。这些“雨天(rainy day)”流程的附加物，尽管非常重要但几乎不执行。通过扩展组件添加这些功能和特征可使核心流程模型保持简单，并且使得修改响应及升级计划变得更容易。
[0061]虽然已参考具体实施例对本发明做了详细展示和说明，但所属领域的技术人员应了解，在不违背所附权利要求书所定义的本发明的精神和范围的情况下，可对形式和细节做出各种改变。
【权利要求】
1.一种基于计算机的流程管理系统，所述流程管理系统具有用于管理流程模型内流程流的流程引擎，所述流程流含有多个流程元件，所述流程管理系统包括: 安置于所述流程模型外部并且耦合到所述流程模型的扩展组件，所述扩展组件用于与所述流程流中的所述流程元件的一个子集相互作用，所述扩展组件由所述流程引擎管理并且经配置以执行特定扩展功能。
2.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括实施服务水平协议，所述服务水平协议确保所述流程元件子集在指定时间段内被遍历。
3.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括通过收集关键性能指标而对所述流程元件子集进行的性能监控。
4.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括对所述流程元件子集的政策遵从性的验证。
5.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括对所述流程元件子集内商业状况的评估以及基于所述评估而采取行动。
6.根据权利要求5所述的基于计算机的流程管理系统，其中所述商业状况由所述扩展组件直接评估，并且所述行动包括对所述流程元件子集进行动态流程修改。
7.根据权利要求5所述的基于计算机的流程管理系统，其中所述商业状况由所述扩展组件通过使用规则引擎来评估，所述规则引擎是所述流程模型一部分，并且所述行动包括对所述流程元件子集的动态流程修改。
8.根据权利要求1所述的基于计算`机的流程管理系统，其中所述特定扩展功能包括对所述流程元件子集内的流程趋势进行预测，这是基于有关所述流程模型的统计历史数据。
9.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括在所述流程元件子集内进行警报监控。
10.根据权利要求1所述的基于计算机的流程管理系统，其中所述特定扩展功能包括对所述流程元件子集内商业状况的评估以及基于所述评估而采取行动。
11.根据权利要求1所述的基于计算机的流程管理系统，其中所述基于计算机的流程管理系统包括多个所述扩展组件以执行多个特定扩展功能。
12.根据权利要求1所述的基于计算机的流程管理系统，其中所述基于计算机的流程管理系统是商业流程管理系统，所述流程模型是商业流程模型，所述流程引擎是商业流程引擎，所述流程流是所述商业流程模型内的商业流程流，所述多个流程元件是多个商业流程元件，以及由所述扩展组件执行的所述特定扩展功能是特定商业扩展功能。
13.一种用于流程管理系统中的基于计算机的扩展组件，所述流程管理系统对流程建模并且具有用于管理所述流程模型内的流程流的流程引擎，所述流程流含有多个流程元件，所述扩展组件包括: 用于耦合至所述流程管理系统并与之通信的扩展基础； 具有设计时间组件和运行时间组件的扩展框架，所述设计时间组件包括具有用户界面的环境系统，所述运行时间组件包括用于执行扩展组件流程的流程引擎，所述扩展流程连同所述流程引擎一并操作，但从所述流程元件去耦掉所述流程元件的一个子集并且由用户配置以执行特定的扩展功能。
14.一种用于对基于计算机的流程管理系统进行操作的方法，所述流程管理系统具有用于管理流程模型内的流程流的流程引擎，所述流程流含有多个流程元件，所述流程元件的一个子集包括开始事件和结束事件，所述方法包括: 捕获与所述流程流内所述流程元件的一个子集相关联的所述开始事件； 在捕获到所述开始事件时激活含有扩展模型流程元件的扩展组件，所述扩展组件流程元件与所述流程流内的所述流程元件子集是分离的并且与之并行操作； 执行所述扩展组件流程元件，直到发生以下任一情况:在所述流程流内达到所述结束事件或通过所述扩展组件确定不能达到所述结束事件；以及终止所述扩展组件流程元件的执行。
15.根据权利要求14所述的方法，其中所述激活步骤包括激活所述扩展模型流程元件以执行服务水平协议，所述扩展模型流程元件包含所述服务水平协议，所述执行步骤进一步包括以下步骤: 激活与所述流程元件子集相关联的子流程定时器； 监控所述子流程计时器以确定所述流程元件子集的子流程执行时间；以及 在所述子流程时间超过最大子流程执行时间时触发警报。
16.根据权利要求14所述的方法，其中所述捕获步骤包括对流程数据变化的检测并且所述激活步骤包括激活所述扩展模型流程元件以执行性能监控功能，所述扩展模型流程元件包含所述性能监控功能，所述执行步骤进一步包括以下步骤: 收集与所述流程元件子集相关联的关键绩效指标；以及 向所述扩展组件报告所述关键绩效指标以对所述流程元件子集的性能进行评估。
17.根据权利要求14所述的方法，其中所述激活步骤包括激活所述扩展模型流程元件以执行政策遵从性功能，所述扩展模型流程元件包含所述政策遵从性功能，所述执行步骤进一步包括以下步骤: 评估所述流程元件子集对一个标准的遵从性； 评估所述流程元件子集遵从所述标准；以及 在所述流程元件子集不遵从所述标准时触发警报。
18.根据权利要求14所述的方法，其中所述激活步骤包括激活所述扩展模型流程元件以执行警报功能，所述扩展模型流程元件包含所述警报功能，所述执行步骤进一步包括以下步骤: 针对所述流程元件子集在正常流程范围外的状况进行监控； 当所述流程元件子集在所述正常流程范围外时触发警报。
19.根据权利要求14所述的方法，其中所述激活步骤包括激活所述扩展模型流程元件以执行趋势预测功能，所述扩展模型流程元件包含所述趋势预测功能，所述执行步骤进一步包括以下步骤: 评估与所述流程元件子集相关联的历史操作；以及 基于所述评估的結果而对所述流程元件子集中的至少一个进行调整。
20.一种计算机可读媒体，具有可执行指令以用于引发处理器来执行用于操作基于计算机的流程管理系统的方法，所述流程管理系统具有用于管理流程模型内流程流的流程引擎，所述流程流含有多个流程元件，所述流程元件的一个子集包括开始事件和结束事件，所述方法包括:捕获与所述流程流内所述流程元件的一个子集相关联的所述开始事件； 在捕获到所述开始事件时激活含有扩展模型流程元件的扩展组件，所述扩展组件流程元件与所述流程流内的所述流程元件子集是分离的并且与之并行操作； 执行所述扩展组件流程元件，直到发生以下任一情况:在所述流程流内达到所述结束事件或通过所述扩展组件确定不能达到所述结束事件；以及终止所述扩展组件流程 元件的执行。
【文档编号】G06Q10/00GK103460228SQ201180027913
【公开日】2013年12月18日 申请日期:2011年4月8日 优先权日:2010年4月8日
【发明者】张舒安, 杰西·夏 申请人:敏捷尖端公司