TOGAF 和 EBPM 对 “业务事件” 的理解

无论在流程管理还是在企业架构建模中，“业务事件 Business Event”（简称为“事件 Event”）是一个不可或缺的要素。但在实践中，关于这个要素的梳理和应用却不太被重视。事实上，在流程管理的数字化转型过程中，“业务事件” 的管理机制是流程迈向自动化和智能化的一个重要抓手。本文，我们先探讨一下什么是 “业务事件” 及其主要特征。

01

TOGAF 对 “业务事件” 的理解

在上图所示 TOGAF 10 的《内容元模型关系图》中，“业务事件”作为一个元模型要素与“执行者 Actor”、“流程 Process” 和 “业务服务Business Service” 三者产生关联关系。

在上图所示 TOGAF 10 的《企业元模型关系表》中，TOGAF 认为：

•  “事件Event”与 “执行者 Actor”、“流程 Process”之间的关系是：“事件”由“流程”和“执行者”产生（Is generated by），并由“流程”和“执行者”解决 ( Is resolved by)。

•  “事件Event”与“业务服务Business Service”之间的关系是：“事件”由“业务服务”解决。

  
  

那么，什么是 “业务事件” 呢？TOGAF 10 中给出的定义如下：

触发处理事件的组织状态变更；其可能源自组织内部或外部，也可能在组织内部或外部得到解决。An organizational state change that triggers processing events; may originate from inside or outside the organization and may be resolved inside or outside the organization.

另外，在 TOGAF 10 中有一类“架构输出物 Architectural Artifacts” 叫 “业务事件图Businee Event Diagram”。TOGAF 关于 “业务事件图 Businee Event Diagram” 的说明如下：

业务事件图的目的是描绘事件与流程之间的关系。某些事件 —— 例如特定信息的到达（如客户销售订单已提交）或特定时间点（如财季已结束）—— 会引发工作，并且企业内部需要采取特定行动。这些事件通常被称为 “业务事件” 或简称为 “事件”，并被视为流程的触发因素。需要注意的是，事件必须触发一个流程并产生业务响应或结果。The purpose of the Business Event diagramis to depict the relationship between events and process. Certain events — such as arrival of certain information (e.g., customer submits sales order) or a certain point in time (e.g., end of fiscal quarter) — cause work and certain actions need to be under taken within the business. These are often referred to as "business events" or simply "events" and are considered as triggers for a process. It is important to note that the event has to trigger a process and generate a business response or result.

综合上述 TOGAF 对于 “业务事件” 的理解，我们可以提炼出如下要点：

• 事件是状态的变更（state change），所谓状态的变更，包括特定信息的到达（如客户已提交销售订单）或特定时间点（如财季已结束）。
  

• 事件会触发流程 (triggers processing events) 或者引发工作和组织内部的特定行动（cause work and certain actions need to be under taken within the business）。
  

• 事件可能来自组织内部，也可能来自外部 (may originate from inside or outside the organization )。
  

• 事件可能被组织内部解决，也可能被组织外部解决。 (may be resolved inside or outside the organization)。

02

EBPM 方法论对 “业务事件” 的理解

在上图所示的《EBPM企业架构元模型关系图》中，“事件” 主要与 “活动” 建立关联，而 “活动” 是构成 “流程” 的基本要素。所以，最终 “事件” 也是与 “流程” 建立了关联关系。这一点，本质上与 TOGAF 没有区别。

如上图所示，在绘制流程图时，不管是采用 EPC 规范还是 BPMN 规范，“事件” 和 “活动” 都是不可或缺的两个要素。从图中可以看出“事件” 与 “活动” 之间的如下关系：

1）“事件”触发“活动”，如果触发的是流程中的第一个“活动”就等同于触发“流程”。这就是TOGAF 所说的“事件”会触发流程 (triggers processing)。我们把这类“事件”称为“开始事件”。

2）“事件”触发“活动”，如果触发的是流程中间的“活动”，我们把这类“事件”称为“中间事件”。也就是 TOGAF 所说的引发工作和组织内部的特定行动（cause work and certain actions need to be under taken within the business）。

3）“事件”触发“活动”，“活动”引发“事件”，“事件”与“活动”在流程图中交替出现。所谓“事件”触发“活动”，说明 “事件”是开展“活动”的原因；所谓“活动”引发“事件”，说明“事件”同时也是“活动”导致的结果。

如上图红框内所示，“报销申请单已提交”这个事件，触发了活动<审核差旅费用报销申请单>；而活动<审核差旅费用报销申请单>完成后，引发了“报销申请单已审核”这个事件。

所以，“报销申请单已提交”这个事件是<审核差旅费用报销申请单>这个活动的“因”；而“报销申请单已审核”这个事件是<审核差旅费用报销申请单>这个活动的“果”。

“流程”是由“活动”构成的，因此TOGAF 说“事件”由“流程”产生（Is generated by）并由“流程”解决 ( Is resolved by) 说的是同一个意思。以上图为例，用 TOGAF 的语言可以这么说：

“报销单申请单已提交”这个事件由<审核差旅费用报销申请单>这个活动来“解决resolve”；而<审核差旅费用报销申请单>这个活动 “产生generate”了“报销申请单已审核”这个事件。

早在上世纪 80 年代末 90 年代初，德国Scheer 教授就提了 EPC （Event-driven Process Chain 事件驱动的流程链）的概念，认为流程是由 “事件” 和 “活动” 构成的连续触发的链路，在这个链路中 “事件” 和 “活动” 是交替出现的。只不过，在实际绘图过程中，为了减少绘图的工作量，通常仅在开始、结束和有分叉路径时才标识事件，其他情况下就不标识事件了。不标识事件，不等于事件不存在，这仅是一个绘图工作量的简化。

03

"业务事件” 是状态，不是过程

TOGAF 认为 “事件” 是状态的变更（state change），EBPM 方法论认同这一点，更确切地说，“业务事件” 是组织中 “业务对象” 状态的变更。

什么是状态的变更，TOGAF 给出例子是：特定信息的到达（如客户已提交销售订单）或特定时间点（如财季已结束）。用 EBPM 的语言可以这么说：“销售订单”这个业务对象的状态变更为“客户已提交”；“财季已结束”这个事件通常应触发“财务报表编制流程”，即“财务报表”这个业务对象的状态变更为“需编制”。

这里需要特别强调的是：“状态变更”是指变更的结果，不是指变更的过程，即“事件”描述的是“状态变更”的结果，而不是过程。讲得更直白一点，“事件”是一种“状态”，不是“过程”。“状态”是业务对象在某一时刻的特征或性质。“状态”本身不存在时长、成本、过程、执行人、工具、输出物等特性，“活动”才有时长、成本、过程、执行人、工具、输出物等特性。

为什么要特意强调这一点？因为在实际绘制流程图过程中，这一点是常犯的错误。

如上图的示，很多人在绘制流程图时常常将<判断XXXX>作为一个“事件”进行标识，这肯定是错误的。<判断XXX> 是一个活动，因为其有时长（花多少时间）、执行人 (谁来判断)、成本（有时长和人员，自然就有成本，不管多少），甚至还有工具、输出物等特性。所以<判断XXX> 一定是一个“活动”，判断的结果，比如“合规”或者“不合规”才是“事件”。

再举个例子。如上图所示，“事件” 触发 “事件” 一定是错误的，这是在描述一个判断的过程，先判断是否可以维修，再判断有没有合同。有过程，就有时长，就有谁在执行这个判断过程等这些特性；而时长、执行人、过程都是“活动”才有的特性，“状态”是业务对象某一瞬间的特性或特征，不能有过程、时长、成本、执行人等特性。

正确的流程模型应如上图所示，“可维修，有合同支撑”、“可维修，无合同支撑”、“不可维修”是三个并列的“事件”，都是由<审核设备维修申请>这个活动产生的，而判断的过程、执行人、时长等特性是由<审核设备维修申请>这个活动来体现的。

结合上述两个案例，可以得出如下结论：流程图中“事件”连“事件”一定是错误的，即“事件”不可能触发“事件”，“事件”只能触发“活动”。

上述规则，在流程接口中更容易犯错。所以，EBPM 方法论给出如下流程图建模规范：后置流程接口前应直接连“事件”，前置流程接口后不能直接连“事件”。只要遵从这一规则，就不会犯错了。

如上图所示，<设备维修申请流程>结束事件 “可维修，无合同支撑“ 触发了后置流程<采购合同签署流程>；那么对于<采购合同签署流程>来说，<设备维修申请流程> 就是其前置流程。在上图下方的<采购合同签署流程>中，在<设备维修申请流程>这个前置流程接口的下方又标识了一个事件“需签署合同”，此时相当于是将<设备维修申请流程>结束事件 “可维修，无合同支撑” 直接与<合同签署流程>中的第一个事件 “需签署合同” 相连了，是 “事件” 连 “事件”，也就是第一个 “事件” 导致了第二个 “事件”，这是一个过程，是绝对错误的。

那正确的建模规则是什么呢？记住：后置流程接口前应连 “事件”，前置流程接口后不连 “事件”。

上图所示是遵循“后置流程接口前应连事件，前置流程接口后不连事件”这一规范后，正确的流程模型。事实上，更为规范的操作是将<设备维修申请流程>结束事件 “可维修，无合同支撑” 完整描述为 “可维修，无合同支撑，需签署合同”，然后再触发后置<采购合同签署流程>。

这个案例中的<采购合同签署流程> 明显是一个会被反复调用的流程，其前置流程通常不会只有一个。

上图所示的<采购合同签署流程>是更为常见的一种情况。图中有多个前置流程，表示本流程被多次调用。另外，还有一个独立的开始事件“需签署合同”，这代表<采购合同签署流程>可以被独立触发，即没有前置流程，直接发起本流程。

如上图所示，如果没有独立的开始事件“需签署合同”，则意味着<采购合同签署流程>只可能被前置的4个流程触发，不可能被独立触发。

可能有的读者会问，有必要搞得这么严谨吗？这就要看你构建流程模型的根本目的了。如果只是画一个示意图，为了让执行者大致看明白做事情的过程，此时关于 “事件” 这个要素，可能确实没有必要这么严谨。如果我们的目的是迈向 “数据+模型” 驱动的数字化流程管理，那么就必须如此严谨。后续将专门撰文探讨如此严谨的 “事件” 建模，在流程的数字化管理中究竟有何作用和价值。