丙午马年首个工作日，与各位关注EBPM方法论的朋友，一同开启新一年的探索之路。

上一篇文章探讨了《业务规则的数字化》，本文探讨一下“对象数字化、规则数字化、过程数字化” 中的业务对象数字化。

先回顾一下 “业务对象” 的定义：企业不可缺少的重要的人、事、物，承载了业务运作和管理决策涉及的重要信息。

01—“对象数字化” 就是构建对象的数字孪生体

当下探讨 “业务对象数字化” 很难避开 Palantir 公司的本体模型 Ontology这个热得发烫的话题。那么，什么是本体模型 Ontology? 下面的论述来自 Palantir 的官网。

一个本体是对现实世界的分类体系，是组织的数字孪生体，是一层丰富的语义层，架设在数字资产（数据集与模型）之上。本体通过将数据集与模型映射到对象类型、属性、连接类型和操作类型，构建出组织业务全域的完整视图。An Ontology is a categorization of the world. The Ontology is the digital twin of an organization, a rich semantic layer that sits on top of the digital assets (datasets and models) .The Ontology creates a complete picture of an organization’s world by mapping datasets and models to object types, properties, link types, and action types.

我们再来看看华为对于 “对象数字化” 的论述。

对象数字化的目标是在数字世界中建立物理对象的数字映射。这种映射不是传统意义上基于流程要求的少量数据的映射，而是这个对象的全量、全要素的数据映射，使得对象在数字世界与物理世界中趋于一致。

可以看出，不管是 Palantir 关于本体的论述，还是华为关于业务对象数字化的论述，都可以提炼出两个关键词： “业务对象” 和 “数字孪生”。

综上，EBPM 方法论认为，“业务对象数字化” 就是基于业务对象构建企业管理的数字孪生体。

02—如何构建业务对象的数字孪生体

《华为数字化转型之道》一书中给出了构建业务对象数字孪生体的四个要点：

1）识别并定义业务对象，实现“活动即记录，记录即数据”。

2）从管理一类对象扩展到管理具体实例，实现业务对象实例的数字化。

3）覆盖全生命周期。记录业务对象从规划、设计到运行的全生命周期过程数据，实现全生命周期的数据闭环。

4）建立业务对象与业务对象之间的连接，构建更丰富的人与事、人与物、事与物之间的数据模型，为业务分析、业务事件处理提供更多的数据支撑。

Palantir 关于本体 Ontology 的论述中指出，构建本体模型就是将实例数据集映射到由以下四部分构成的元模型上：

*对象类型（object type）：组织中的实体或事件。

*属性 (property)：对象类型的特征。

*连接类型 (link type)：两种对象类型之间的关系。

*操作类型(action type)：对象类型可被修改的方式。

上图所示是 Palantir 官网上一个较为简单的本体模型 (ontology) 示例。此模型由机场、航班、航空公司、飞机、延误五个业务对象类型 (object type) 构成。

上图中，“对象(object)” 是 “对象类型(object type)” 的实例数据。比如，<机场> 是一个对象类型(object type)，而纽约肯尼迪 (JDF) 机场则是一个在物理世界中实际存在的机场，是<机场> 这个对象类型(object type) 的一个实例数据，一个具体的对象(object)。

上图中，<属性>仅罗列了属性类型，事实上每一类属性也应有映射的实例数据也就是属性值，只不过在上图所示的模型示意图中没有展示出来而已。

在 Palantir 的本体模型 ontology 中，【对象类型(object type) - 属性(property)】是元模型，可以认为是数据集的表头；将实例数据即【对象（object）- 属性值 (property value) 】采集上来并映射到对应的元模型中，就构成了一个<业务对象>的数字孪生体。将企业运行的全量实例数据采集上来映射到所有<业务对象>上，就构成了组织的数字孪生体。华为关于 “业务对象数字化” 论述中也有完全相同的观点。

下面用 Palantir 官网上的示例来描述一下构建 “业务对象数字孪生体” 的主要过程。

如上图所示：

第一步：先构建【机场】这个【对象类型 (object type)】，

第二步：针对【机场】这个对象类型构建【启用日期/运营容量/经纬度】这组【属性(property)】，从而形成【机场-启用日期/运营容量/经纬度】这个由【对象类型(object type）- 属性(property) 】构成的元模型。

第三步：采集【对象(object) - 属性值(property value) 】的实例数据，本示例中是【机场-启用日期/运营容量/经纬度】，并映射到元模型上从而形成这个业务对象的数字孪生体，让这个业务对象在虚拟的数字世界中 “动起来”。

上图所示，是由机场、航班、航空公司、飞机、延误这五个【对象类型（object type）-属性(property) 】元模型构成的 ontology 本体模型。

上图所示是由【对象类型(object type) - 属性(property)】+【对象(object）-属性值(property value) 】构成的数字孪生体。

如上图所示，如果将识别的五个【业务对象】都全量采集数据并映射到元模型上，就构建了由这五个【业务对象】构成数字孪生体。

上述模型是否看着有点眼熟？

是的，Palantir ontology 中的【对象类型(object type) - 属性(property)】元模型与上图所示的 《EBPM 企业架构元模型关系图》中的【数据架构：业务对象 (business object) – 数据实体 (data entity)】元模型本质上就是一回事。

不同的是，Palantir ontology 中强调了【对象（object）- 属性值 (property value) 】这组实例数据的采集和映射。而华为关于“对象数字化” 的论述中也同样强调要从管理一类对象扩展到管理具体实例，实现业务对象实例的数字化。

综上，Palantir 本体模型中的元模型及其架构（schema）就是EBPM企业架构模型中的一部分，这部分本质上没有什么区别；不同的是，Palantir 本体模型和华为业务对象数字化中都强调了实例数据的采集和映射，从而完成了 “数字孪生体” 的构建。另外，基于 “数字孪生体” 模型，Palantir Onlogy 还进一步构建了分析、决策和行动机制，这也是其最为惊艳的部分，关于这部分后续文章会深入探讨。

行文至此，如上图所示，Palantir ontology 的元模型似乎就是【EBPM 企业管理要素架构】和【EBPM 企业架构元模型】中的 “数据” 类要素的元模型。

那么，业务对象的数字孪生体真的只与EBPM26类要素中的 “数据” 类要素相关吗？当然不是！

未完待续...