我们在流程P中通过选择起始点s和一套终结节点集E来定义区。在E中最多只有一个节点e可以是P中的一个非终结节点。区需要满足某个限制条件。特别地，s和E必须能标识P的一个子图SG，诸如：

1．s仅有一条输入弧，且这条弧来自于SG之外的一个节点；

2．E中唯一的节点e是P中的一个非终结节点，它仅有一条输出弧a，它将e和不属于SG的一个节点连接起来；

3．SG中其它的弧必须仅与SG中的节点相连接。

正如图3显示的，人们通过一个商业报告工具（诸如Crystal Reports和Oracle Discoverer）就能直接访问PDW中的数据。分析人员也可以通过BPI Cockpit（在文章后面会具体给它下定义）来访问PDW，Cockpit提供了具体的可视化技术来报告业务流程的执行情况。

3.2BPI流程挖掘工具

PDW拥有一套数据分析功能。然而，它是一个“含蓄”的组件：它让用户去“猜测”行为之间可能的因果关系。之后此PDW可以帮助用户核实这个猜测正确或者错误，诸如通过分析相关行为来核实。

BPI流程挖掘工具（PME）具有更为“机智”的分析能力，它能够（自动或半自动地）寻找到一个行为出现的原因。PME通过将行为分析问题与一个分类问题[Berry00]相对应来实现上面所说的功能，在分类问题中，流程是要被分类的对象，而类包括“有”类或“没有”类，各自代表了有或没有某个行为的流程。PME分析了PDW中的数据，而PDW则描述了哪一个流程有某个行为，也就是说，描述了对象属于的类别。通过分析这些数据，PME得到了一套分类规则。因此，根据流程各自的特征，分类规则指出了每一个种类的流程的特性。就每一项分类规则来说，分类器也提供了关于规则精确性的信息，也就是说，关于按规则进行分类的正确可能性。一旦第一类中的流程特性得到了识别，用户可以更好地理解流程具有某个行为的原因。

举例来说，分析人员可能想鉴别“支出批准”流程的特性，这个流程具有“持续时间超过15天”这个行为。PME可以处理仓库中的数据并反馈如下的分类规则：一些流程，如果它们有着超过18,000美元的订单，以及它们中的“确认”节点由John执行，那么这些流程所包含的行为有80%的精确性。

PME建立在一个商业数据挖掘工具2（识别了分类规则）上。我们正致力于设计和开发将行为分析问题与一个分类问题对应的组件。这里要提出的主要问题是数据的准备，因此分类器可以使用它来制定规则。特别地，我们需要识别流程具备哪些性质（特征，使用数据挖掘工具），分类器应该考虑这些性质后再决定规则的制定。事实上，这样的性质其数量从理论上来说是不受限制的。诸如，一个行为可能取决于两个节点持续时间长度二者的比例，或者取决于那些执行节点1，3，5等的资源之间的相互组合。根据以往做过的诸多实验，我们得到了下面这些性质，它们与用户通常分析的普通行为最为相关：

－流程活动和完成时间（按年，月，天等分解，如果它是一个工作日、假日或周末则给出标记）

－流程数据项：流程数据各项的初始值和终值，加上每一项的长（以字节的形式）。

－启动流程的资源

－流程持续时间

此外，对于每一个节点的执行情况，要考虑下面这些性质：

－活跃状态及完成时间（按照上述分解）

－数据项目：节点输出数据值，加上每一项的长（以字节的形式）

－执行节点的资源

－节点的最终状态（例如成功完成或失败）

－节点持续时间

－流程内节点的活动数目（定义每个节点时仅提到这个性质一次）

图6详尽地展现了PME的架构。一个流程数据准备应用程序从PDW中读取流程和行为信息，并挑出特征，将数据以一种适合于分类器（通常是一张相关的表格）的格式输出。这套数据通常被称为“训练数据集”，既然它被用来“训练”分类器，因此它了解分类的规则。然后分类器产生出规则并将它们存储进“分析和预测”数据库。之后分析人员可以得到这些规则，并利用其来推测行为出现的原因。在一些情况下，分析人员可能想先从该训练数据集所包含的流程中删除一些性质，然后再重新分类，并且还想强迫分类器关注他们感兴趣的特殊性质（诸如，资源）。

除了能进行行为分析，PME也能预测规则，即通过其它的BPI组件来推测在运行一个流程时可能会出现的行为，以及可能采取的措施。获取预测规则的过程与得到分类规则的过程是相似的，这里我们不提。

3.3BPI Cockpit

BPI Cockpit的主要目的是使商业用户能对业务流程进行业务层的质量分析，监控和管理。以商业用户为目标意味着要在不限制软件的功能及其灵活性的同时，使软件界面尽可能地保持简洁和即时。实现业务层上的分析和监控功能涉及到开发让用户定义、监控及评估业务质量标准的技术。BPC提供了如下三个主要功能：

－它可以向商业用户和IT用户提供多种报告。与通用报表工具所不同的是，BPC更加注重PDW数据的内在涵义，并且提供了概念可视化功能和专为显示业务流程执行数据而设计的技术。另外，可以通过BPC来配置PDW，如定义行为和分类规则等。通过BPC还可以采用一种直观的方式对报表和PDW进行配置且不需要编写任何代码。

－它监管流程，服务，资源以及其他流程相关的方面，并且将已有或是预测的质量下降情况通知给用户。BPC能够按照用户选择的方式向其发出通知。

－通过改进流程和系统的配置参数（例如流程的优先级别）以及将事件通报给流程，BPC可以管理正在运行中的流程。

BPC从不同的角度来设想流程执行的数据（包括相关的质量标准）。各个角度又有各自认为能作为分析重点的流程部分。举例来说，从服务角度来看，用户看到的将是与在业务流程执行中所调用的网络服务相关的统计数据和标准。通过和咨询人员及用户的讨论，我们发现了一些角度与业务层分析非常有关联，它们分别如下：

－流程：显示一个或一系列特定流程的相关信息。

－资源：显示了与个人资源或人工式或自动式资源群相关的信息，诸如资源配额或绩效。

－服务：显示在执行流程时所调用的电子服务相关的信息。

对每个角度来说，BPC都能够提供基本的统计信息（例如平均执行时间和绩效），价值相关信息（关于收入和成本）以及行为信息。

此外，当关注于某一特定角度时，BPC也依然能够借助其它角度来细化分析，这点有些类似于多维分析。诸如，当集中精力在一个特定的流程（流程角度）上时，也可能从总体上分析这个流程，或是考虑具体的时间值（例如，分析在某个时间窗口中的开始的实例），或考虑具体的资源值（例如，仅分析包含一项特殊资源的实例）。

图7作为一个例子，展示了流程如何根据持续时间分类。持续时间分类法分为四类：快（流程持续时间少于5天），正常（流程持续时间在5至10天），慢（流程持续时间在10至15天），以及非常慢（流程持续时间超过15天）。

除了向分析人员提供监控功能，BPC也能自动地管理运行中的流程实例。特别地，BPC能监控正在运行的流程所出现的重要行为，当这种行为被检测到时发出警报。诸如，一名流程设计人员指出，当一个服务级别的协定遭到违背时将事件SLA违例通知给流程（SLA违例可以用行为的方式说明，正如本文前面所描述的）。

综上所述，BPC的作用是：让用户定义自己关心的情况，对此情况进行检测并且将结果传送给相应的流程。而BPC望尘莫及的是：它不能让流程去处理检测到的情况，因为这个功能属于业务流程逻辑范畴。

再谈业务流程智能（一）（AMT研究院 王艳）

再谈业务流程智能（二）（AMT研究院 王艳）