在《华为数字化转型之道》一书中，华为认为实现 “对象数字化、过程数字化、规则数字化” 是数字化转型的关键。本系列的前期文章已探讨了规则数字化和对象数字化，本文将阐述 EBPM 方法论对于业务过程数字化的理解。

如何实现过程数字化呢？在书中第122页华为指出：过程数字化首先实现的是作业过程的数化字记录，但随着对象数字化的深入，在虚拟世界中实现作业过程的仿真，可以反向作用到物理世界，大幅缩短业务的响应时延，从而降低作业成本，提升作业质量。

这段描述可以提炼出以下三个要点：

1）数字化记录业务过程

2）仿真分析业务过程

3）反向作用业务过程

这是标准的 “数字孪生” 管理闭环的逻辑。

如上图所示，EBPM 方法论完全认同华为的观点，所谓的业务过程数字化，就是要构建一个针对 “业务过程” 这个对象的 “数字孪生体”，并基于这个 “数字孪生体” 构建 PDCA 的管理闭环。

要构建业务过程的数字孪生体， “构建模型” 和 “数据映射” 是不可能绕开的两项基本工作。可以认为， “业务过程的数字化” 就是构建 “数据+模型” 驱动的企业流程管理体系。

下面我们分别从 “构建模型” 和 “数据映射” 两个方面来阐述一下 “业务过程的数字化”。

在前期文章《业务对象数字化和Palantir Ontology》中，我们介绍了上图所示的 Palantir Ontology 本体模型。本体模型的实质就是构建业务对象的 “数字孪生体”，在流程管理领域，这个 “业务对象” 就是 “业务流程”。而 EBPM 方法论认为，基于企业架构原理构建的【流程模型】其本质就是【Ontology 本体模型】。

下面，我们以【销售报价流程】为例，说明一下为什么【流程模型】就是【本体模型】。

01—【流程模型】中的「对象类型」和「关系类型」

我们先来解析一下【流程模型】中的「对象类型」、「关系类型」，也就是所谓的 “名词” 和 “动词”。

1）“流程、活动、管理记录” 是流程模型中三个最基本的「对象类型」

上图所示是在 EBPM 流程建模工具平台中绘制的【销售报价流程】，由以下四个业务活动构成：

提交报价申请【动词：申请】

审核报价单【动词：审核】

审批报价单【动词：审批】

发送报价单至客户【动词：发送】

注意，基于 EBPM 方法论，每一个活动都应提炼出关键动词，而这些动词决定了 Ontology 本体模型中的「关系类型」。

上图红色箭头所示就是在 EBPM 平台中绘制流程图时，系统自动识别和设定每一个活动关键动词的地方。在 Palantir Ontology 本体模型中明确用【对象类型】也就是 “名词” 来描述 “业务对象”；用【关系类型】也就是 “动词 ”来描述 “对象关系”。

在【销售报价流程】的四个流程活动中，我们已解析出了 “动词”，那么代表 “业务对象” 的 “名词” 是什么呢？如上图所示，是图中红色箭头所示的输出的「管理记录」即【报价单】。事实上，每一个流程活动也都是 “名词+动词” 的组合，在【销售报价流程】中，每一个流程活动都是对【报价单】这个“业务对象” 的一项操作，也就是所谓的「操作类型 Action Type」。

上图所示是【销售报价流程】的 【Ontology 本体模型】逻辑图。可以发现，完成「销售报价流程」模型的构建后，【销售报价流程】的 【Ontology 本体模型】其实也同步完成了，只不过没有按上图所示的样式进行呈现而已。图中红字部分就是流程「活动」这个业务对象与「报价单」这个业务对象之间的「关系类型 」。

总之，流程图中输出「报价单」的所有活动的关键动词有多少个，就有多少种「关系类型」。所以，不同流程的「活动」与其输出的「管理记录」间的「关系类型」的数量和类型是不同的。

另外，【流程模型】中还包含了三类固定的「关系类型」，所谓 “固定” 是说所有 “流程” 都存在这类关系，不同的 “流程” 这类关系是一样的。

「流程」与「活动」：有固定的「关系类型」，「流程」包含「活动」，这种「关系类型」不同的流程都是一样。

「活动」与「报价单」（管理记录）：有固定的「关系类型」，即 “作为输入” 和 “作为输出”，这种「关系类型」不同的流程都是一样。

「流程」与「报价单」（输出的管理记录）：有固定的「关系类型」，即 “生成”，这种「关系类型」不同的流程也都是一样。只不过，不同的流程 “生成” 也就是 “输出” 不同的管理记录而已。

综上，当完成一个【流程模型】时「流程」、「活动」、「管理记录」这三个「对象类型」和三者间的「关系类型」其实已经完成了构建，只不过一个是用【流程模型】的形式呈现，一个是用【本体模型】的样式呈现而已。

2）“角色”、 “员工” 也是「对象类型」

如上图所示的【销售报价流程】模型中，每一个流程活动还分配了“角色”，包括负责执行类“角色”和知会抄送类“角色”，而“角色”也是一种「对象类型」。在【销售报价流程】模型中有以下三个角色：

报价申请人（负责完成【提交报价申请】、【发送报价单至客户】）

报价审核人（负责完成【审核报价单】）

报价审批人（负责完成【审批报价单】）

如上图所示，由于 “角色” 中分配了人员，所以 “员工” 也是构成流程模型的一类「对象类型」。

于是，构成流程图模型的「对象类型」扩大到五类：即「流程」、「活动」、「管理记录」、「角色」、「员工」。上图所示是由这五个「对象类型」构成的【Ontology 本体模型】的逻辑图。

注意：「角色」与「员工」、「活动」、「管理记录」构成三组「关系类型」

「员工」与「角色」：「关系类型」是“担任”，这是一种“固定”的关系，即不同的流程中这种「关系类型」是固定的。

「角色」与「活动」：「关系类型」数量由流程活动关键动词的种类决定。

「角色」与「管理记录」：「关系类型」数量由流程活动关键动词的种类决定。

02—【流程模型】中的「属性」

下面我们分析一下上图所示【Ontology 本体模型】中的「属性」部分。完成【流程模型】的构建后，「流程」、「活动」、「角色」、「员工」这四类的「对象类型」的「属性」其实也构建完成了。

在上图所示的「流程」、「活动」、「管理记录」、「角色」、「员工」这五个「对象类型」中，除「管理记录」外，其他四类「对象类型」的属性对于不同的流程而言都是一样的，在建模时不需要反复定义，定义一次即可。也就是说，当【流程模型】构建完成后，每一条具体「流程」上这四类「对象类型」的「属性」都是一样的，在类似 EBPM 系统这样的流程建模工具平台中，只要完成一次定义即可，不需要反复定义。再说的直白一点，就是每画一个流程图，建模工具平台会自动生成上述「对象类型」和相关的「属性」。

通常，「流程」、「活动」、「角色」、「员工」这四类「业务对象」的应包含如下属性：

1）「流程」的属性：通常包括流程实例 ID、流程 ID、流程名称、流程发起人 ID、流程发起人、流程发起时间、流程结束时间、流程状态。

2）「活动」的属性：通常包括流程实例 ID、流程 ID、流程名称、流程活动实例 ID、流程活动、操作类型、开始时间、结束时间、活动状态、执行人员、抄送人员、输入、输出。

3）「角色」的属性：通常包括角色编号、角色名称、关联的岗位、关联的员工。

4）「员工」的属性：通常包括员工 ID、姓名、性别、职位、职级、入职日期。 

03—【数据架构】中的 「对象类型」、「关系类型」、「属性」

「流程」、「活动」、「管理记录」、「角色」、「员工(组织）」是上图所示【业务架构】的构成要素。其中「流程」、「活动」、「角色」、「员工」这四类要素可以直接解析出「属性」，不同【流程模型】中这四类对象的属性是一样的。

但是，不同「管理记录」的「属性」是不同的。如上图红色部分所示，「管理记录」的「属性」需要基于【数据架构】进行解析。在解析「管理记录」的「属性」时，甚至还会进一步解析出更多的的「对象类型」。

上图所示是【销售报价流程】完整的 【Ontology本体模型】，绿色部分是基于「报价单」这个「管理记录」对应的【数据架构】解析出来的「业务对象」。所谓 “解析”，可以认为就是构建【数据架构】模型。当数据架构师把相关的【数据架构】模型构建完成后，上图所示的【Ontology本体模型】也就同步完成了。

也就是说，基于企业架构的原理构建【流程模型】的过程，就是在构建【Ontology 本体模型】，两者在操作细节上可能有所不同，但实质上就是一回事。下一篇文章将从【管理记录】展开，继续论证这一点。

未完待续….