下文为Datablau数语科技创始人&CEO王琤先生在2023DAMA中国管理峰会发表的《数据治理新实践与发展趋势》主题分享实录第二部分：

数据资产入湖管理这个话题，我们从数据模型管控的经典流程讲起。 这个图在《华为数据管理之道》或Datablau的模型管控解决方案都可以看到。但我们发现很多企业还是不知道怎么做，其中主要问题是模型设计怎么做。 

• TP侧-业务系统设计阶段，业务系统需求方与开发方会共同做模型设计，这个是传统系统开发的基本功，非常成熟。如果可以打通模型管理与DevOps(CI/CD)会将TP侧管控的更落地。所以，TP侧的模型管控主要是推动业务系统开发要做设计，形成这个习惯，就自然落下来。

• AP侧是主要有挑战的。首先模型设计谁干？如何建统一数据底座（标准数据模型层），进而数据资产入湖？模型与数据资产目录如何联动？面向业务的数据资产目录？有的企业是照搬数仓的模型设计到数据湖，问题是模型对应的数据资产目录是按数据域，对业务很不友好，对业务不可用。所以AP侧的数据模型是需要拉通业务一起建设的，数据模型与数据资产目录只设计一次，而不是各建各的。

所以，今天我来重点聊聊，拉通业务部门建设AP侧业务域模型，同时进行数据资产入湖管理的成功实践案例。

下图是这个案例的背景， 业务系统数据需要按业务域设计标准模型层，之后按入湖规范进行评审后入湖。统一数据底座支撑各种数字化转型的应用。

下图是数据资产入湖的流程图，这个案例精彩之处在于流程是由业务发起的。业务根据数据需求先梳理业务流程、业务对象、业务属性。之后将这些业务对象、业务属性交给对口IT做数据探源。

之后交给数据管理，按需发布数据标准，落标、核标率，数据质量检核及评分。

过程中会输出三个产出物： 1、入湖所需数据标准信息清单；2、入湖所需元数据信息清单；3、入湖所需数据质量评分信息清单。三部分汇总为评审数据入湖信息清单。

最后交给主题域数据owner进行审批。具体流程如下：

这种业务发起的方式大大提高了数据资产盘点的效率，整个流程捋顺了，既不是数据治理部自己闷头苦干最后被定义为自说自话，也不是数据治理部苦苦求着业务部门协助补充业务相关信息。

下图是通过一张大表拉通四个利益相关方的实例。最终这些都将作为数据架构或数据资产目录落地到数据资产管理平台。

数据模型与数据资产目录的转换可以通过如下方式。将主题域分组、主题域、业务对象、逻辑实体、属性，映射到L1-L5的数据资产目录。设计只需要做一次，数据模型与数据资产目录可以自动同步。

总结一下，这个案例给出如何拉通业务部门构建AP侧数据中台的数据架构、数据模型的实践。通过业务部门梳理业务流程业务对象、业务对口IT进行数据探源、数据治理发布数据标准、提交入湖信息清单，最后由数据owner审批入湖。这对于苦苦陷在拉通业务，甚至自己埋头苦干最后还不被业务认可的数据管理部门，是非常有参考价值的。