AI大模型和本体论模型赋能企业数据治理-解决业务和数据间断层和鸿沟

Hello大家好，我是人月聊IT。

今天下午要去参加一个关于数据治理的活动，主办方给了我一个命题：在AI时代，AI赋能下的数据治理究竟应该怎么做？

业务驱动的数据治理

实际上，我前面分享过相当多的关于企业架构里面的数据架构、数据治理整个体系，以及主数据平台、数据中台建设相关的文章和视频。我个人在这20多年的时间里，做过不少跟数据相关的项目。刚好在过年前，还到一个客户现场去沟通一个数据治理相关的咨询项目。现场沟通以后，客户提出来，他们想做数据治理咨询项目，去标准化数据模型，包括制定数据治理相关的标准规范。

我听了以后提了一个关键的问题：你为什么要做数据治理项目？做完这个项目希望达到的目的或目标究竟是什么？

实际做数据治理项目的推动力究竟在哪里？没有把这个问题想清楚，最后给的就是一堆标准、规范、模型，拿着以后也不知道怎么用，或者不清楚它究竟带来什么样的业务价值。沟通以后，我给了一个关键的建议：并不是说做数据治理项目不行，而是需要真正想清楚，找到关键的业务场景切入，基于这些业务场景来做数据治理。类似于预算管控的一体化，或者研发全生命周期的管理都可以。

因为在端到端流程贯通的过程中，很有可能出现业务断点，影响到实际预算编制和管控的一体化效率。以预算管理为例，往往就是由于预算科目、会计科目，包括产品BOM的颗粒度不一致，导致虽然有预算编制下达，但后面的管控做不到一体化。

如果再联系到产品研发、产品生命周期管理也一样。由于底层基础数据不一致、不畅通，或者颗粒度不一致，没办法做到产品研发项目的全成本核算。这些才是真正业务部门关心的问题，也是业务的老大难问题。而引起这些业务问题的，除了相关业务规范流程的原因以外，大部分都是由于数据原因导致的。

那么能不能从这些业务场景切入，基于场景展开数据治理工作？该优化标准、规范流程的，就去优化标准流程；该重新建立数据相关责权利的，就去做责权利的重新分配和建设；该构建数据架构、数据模型的，就去构建数据模型。最终这个事情解决以后，还会落地到IT系统的优化改造和系统集成。

优化完以后，你会看到一个巨大的效果：数据治理真正带来了业务价值。而且由于这是业务部门关心的事情，业务部门也会积极配合。讲了这么多，简单总结一句话：数据治理一定是业务驱动的。

为什么做数据治理？因为数据问题已经严重影响到了业务。单个数据问题、单个部门问题，往往在单个部门内部、单个系统就已经解决了。真正上升到公司级的数据问题，往往都是影响到跨系统、端到端业务流程的，这才是做数据治理的关键价值点。

传统数据模型缺少业务语义

第二个事情，我已经强调过很多次：在企业IT系统建设过程中，往往分为两大类IT系统。一类是OLTP类系统，类似于ERP系统、CRM系统、MES系统、SRM系统；还有一类是OLAP偏数据分析决策类的系统，早期可能是数据仓库、BI系统，当前可能是大数据分析平台或者数据中台。

但是经过这么多年的IT建设，始终有一个相当难解决的问题：OLTP类系统和OLAP类系统怎么样更好地集成和联动？

因为在分析决策类系统建设过程中，依托的是底层标准数据模型，同时基于数仓建模思路进行分层建设。但在分析决策类系统构建过程中，数据模型天然丢失了业务语义。也就是说，虽然拿到了数据模型，但它是偏静态的数据模型，只有数据对象、属性和对象之间的关系，不会告诉你数据本身形成的来龙去脉，也不会告诉你数据的关键属性状态变化需要触发什么样的业务行为，这些全部丢失掉了。

所以大家看到的一个关键情况是：虽然有BI系统、有仪表盘，当发现关键指标发生异常，类似于库存周转率出现严重异常以后，只能把这个信息通知到相关业务部门主管，然后业务部门主管再去排查计划系统、供应链系统、采购系统，找到原因最终解决。由于这个天然割裂的问题，也尝试了大量解决方法或措施。

类似于在企业架构里面，特别是对于数据架构，如果大家看过《华为数据之道》这本书，就知道华为数据架构里面专门谈到了最后一个点叫"数据分布"。在数据分布里面谈到，应该去构建数据和数据之间衔接的数据链，或者叫数据流，通过这种数据链的构建来更好地反向支撑或映射业务。这是在数据架构里面做的关键动作。

到了数据中台，其实也是一样的道理。数据中台把传统BI中间横向切开了一层，把识别的数据资源经过清洗整合形成数据资产以后，把数据资产开放成数据服务，直接给到OLTP业务系统使用，解决实时性问题。所以在数据中台里面一般叫"数据反哺业务"。

AI+本体模型实现数据到业务的闭环

最近大半年流行另外一个东西叫"本体论"。本体论里面出现了一个关键的词叫"回写"。什么叫回写？很多人搞不明白。回写很简单：在数据这边发现的问题、决策，能够动态地变更或回写到业务系统里面去，这个就叫回写。

当然，这个回写的实现需要本体论模型去支撑，需要AI大模型去支撑。

前面也举过一个简单的例子来说明这个场景。在整个供应链管理中，BI系统或数据中台这边有一个大的仪表盘或看板，能够看到关键数据指标的预警。比如发现一个关键数据指标出现预警，原因分析出来，很有可能是某一个关键供应商提供的关键原材料出现了1-2个月的延期。

在传统BI系统、传统系统建设里面，拿到这个预警延期以后，往往需要供应链主管自己去做优化和调整。但在本体论建模思路下，这么一个延期会触发一个事件，进入到本体模型的消息管道。

同时，本体模型下面本身就有一个供应链计划优化调度的模型，这个模型融合了我刚才说的供应商、物料、合同、订单、交期、约束规则等各种东西，天然地重合成一个大模型。这个大模型拿到关键物料交期延误的消息以后，会自动计算，给出一个最优决策。这个最优决策有可能是把某一个客户订单朝后面延，也有可能是引入新的关键合作伙伴供应商。然后它把这个决策调用供应链系统或CRM系统提供的回写API接口，把这些相关决策回写到业务系统里面去。

这个时候对于业务主管来说就很轻松了，只需要在业务系统里面最终审核一下本体模型或AI给出的最终决策建议：究竟是选择推迟客户交期，还是引入一个新的供应链合作伙伴？审核通过以后自动生效。通过这种模式，数据分析决策这一块跟业务运作系统实现了完整的双向协同和连接。这个双向协同连接的完成，需要底层有一个核心的本体模型来支撑。

这个本体模型简单来讲，不是单纯的传统数据模型，而是在数据模型基础上补充了原有数据模型缺失的业务语义、行为和规则。

所以说来说去，就更容易理解为什么一直在强调本体模型的核心就是"对象-关系-行为-规则"。对象里面包含了关系，行为里面包含了事件。对象、关系、行为、规则、事件，这些天然形成了一个完整的整体，形成了一个相互影响、相互约束的很大的语义网络，这才是本体模型带来的最大价值。

好了，今天的简单分享就到这里。再见。‘