作者北海 奇点智能FDE数据架构师一台成品在终检环节出现振动异常。质量工程师问了一个看起来很简单的问题这台异常产品实际使用了哪些物料批次做过数据平台或跨系统集成的人第一反应大概相同查QMS找到检验记录查MES找到工单再到 ERP 关联物料批次最后写一条跨系统SQL。但真正动手以后问题很快就变了。QMS 里的产品编码指的是被检验的序列化成品MES 里的产品编码可能指工单上的产品型号ERP 里的物料批次记录了领料却不一定等于生产现场的实际消耗。PLM 还有多个产品版本和工艺版本设备系统则用另一套设备编号记录当时的状态。每个系统都有数据每张表也都能查询。但这些数据还不能自动拼成一条身份一致、时间正确、证据可追溯的制造故事。SQL能连接字段却不能替我们判断字段背后究竟指向哪个现实对象。这正是本系列要讨论的问题。1 最危险的答案查到了但查错了假设我们根据产品编码、工单号和物料批次号完成了关联查询返回三条物料记录。结果结构完整字段齐全执行时间也很快它仍然可能是错的。至少有六件事需要先回答记录、零件和检测设备都摆在桌面上并不等于它们已经证明了同一个制造事实。如果这些问题没有答案SQL 只是把不确定性藏进了连接条件。过去做数据架构和数字化交付时我反复遇到一种错觉系统通了、表也汇了就默认业务已经打通。到了验收现场才发现真正耗时的不是把数据搬过来而是不同部门对客户、订单、产品、完成、有效这些词的理解并不一致。制造追溯把这个问题放大了。它不只关心一张当前快照还要回答谁在什么时候按照哪个版本用什么设备和物料实际做了什么并留下了什么证据。2 先把业务真正要问什么固定下来在本体工程中用来定义模型范围并检验模型是否可用的问题专业上叫能力问题Competency Question简称 CQ。为了让非技术读者更容易理解本系列优先叫它业务验收问题。M厂的第一个业务验收问题可以写成对于终检异常的成品实例M-FG-00017返回生产时实际消耗的物料批次、对应工序执行、发生时间和来源记录不得用计划用料替代实际消耗。这句话比“建设质量追溯本体”小得多却更接近一个能够交付和验收的项目。它明确了六件事本体先回答什么才算回答了业务问题再决定应该有哪些类。这个业务验收问题将贯穿本系列全部十三篇文章。每一篇都在回答同一件事为了让这个问题得到稳定、可信、可验收的答案我们还需要补上什么。3 一个问题要穿过完整的工程链要稳定回答上面的追溯问题至少要完成这样一条链业务问题 → 概念 → 本体论判断 → 模型 → 源数据 → 身份 → 约束与推理 → 查询 → 业务动作 → 验收与版本先识别产品实例、物料批次、工序执行、设备和检验事件等概念。再区分产品型号与产品实例、工艺步骤与一次真实工序执行、计划用料与实际消耗。然后定义使用了什么、由什么产生、什么设备参与、什么检验对应什么产品等关系把 ERP、MES、QMS、PLM 和设备系统的字段映射进来。数据进入以后还要解决跨系统身份两个相似编码究竟是同一对象、不同版本还是完全不同的对象接着检查数据是否满足最基本的可用条件。一次工序执行如果缺少产品、时间或参与设备就不应该悄悄进入追溯结果。最后查询返回的答案必须带着来源和证据路径进入追溯应用。模型、映射或规则发生变化后还要重跑原来的业务问题确认答案没有被破坏。这才是本体工程它包含本体建模但远不止本体建模。4本体不会替代SQL也不会替代数据治理这里需要提前划清一条边界。本体并不用来消灭数据库、接口、SQL、主数据或数据质量工作。SQL 仍然负责高效查询接口仍然负责数据交换主数据仍然负责关键编码治理数据质量规则仍然负责发现缺失、错误和异常。本体增加的是另一层能力把跨系统共享的概念、关系、身份、时间和约束显式表达出来让不同系统、不同角色以及后续的AI能够在同一种语义下使用数据。如果问题只是某个接口没通、某列数据缺失应该先修接口、补数据。如果问题只是流程无人负责应该先补治理责任。只有当同一业务对象在多个系统中长期存在稳定的语义分歧而且这种分歧需要被复用、解释、验证或供人机共同使用时本体才可能成为必要组成部分。所以本体工程手记系列的第一篇不会教你怎样“画”本体。它先回答一个更重要的问题你的项目究竟需不需要本体本体项目不是建一张概念图。它是让关键业务问题从定义到数据、查询和验收全程不失真。下期预告先别急着立项。下一篇我们回到 M 厂的追溯会判断问题究竟卡在数据、流程还是共享语义。案例声明本文中的M厂是用于教学的离散制造合成案例不对应任何真实客户人物、系统、编码、数据和事件均为模拟设定。