为什么有了 ERP、MES、IoT，数据还是进不了决策现场
以前我开始做建筑的数字化，听到最多的一个说法就是，建筑业是所有行业数字化水平最低的，仅高于畜牧业，还不及农业。最近去跟一位做工业AI项目的朋友交流，我问他，你们数字化水平高应该AI应用得很好吧。他苦笑说：数据确实不太缺，但不妨碍大模型不懂具体的业务。我更好奇了。他就跟我介绍起来：
生产线上跳出一条数据：温度 72℃。
AI 当然认识 72℃。它知道这是摄氏温度。
但它不知道这是哪台设备的哪个加热区，正在跑什么料，工艺允许的区间是多少，车间今天是不是比昨天热，以及上一次出现这个温度的时候，后面出了什么事。
在数据库里，72℃ 是一个字段。在业务现场，它是一个正在逼近边界的状态。
企业其实一点都不缺数据。ERP 里有订单和财务，MES 里有工序和产能，IoT 里有设备的实时数据流，质量系统里有检测记录。还有十几年的标准、工艺文件、项目资料，和一批老师傅脑子里的东西。
奇怪的是 AI 到了企业里，还是经常不懂业务。
不是不会聊天。你把一个真实业务问题丢给它，它进不了现场，也答不上那几个真正要命的问题：现在发生了什么，为什么会发生，接下来会怎样，如果现在改一个参数会带来什么。
问题也不在模型不够大。
在数据和业务之间，缺了一层东西。
一、一个数据点，到底意味着什么
把 72℃ 放回业务现场，它至少牵出这么一串问题：哪台设备，什么状态，正在生产什么产品，用的什么原材料，当前在哪个工艺阶段，这个阶段允许的温度区间是多少，环境温度多少，历史上类似情况有没有出过质量问题，这个温度持续多久了，后续哪个检测指标会受影响。
十个问题，没有一个写在 temperature 这个字段里。
它们散在设备台账、工单系统、工艺卡、检验记录、采购系统里，还有一部分只在某个老师傅的记忆里。
所以真正该问的不是企业有多少数据，而是这些数据进了什么模型。
我越来越认同这句话：数据只有在模型里才有生命力。
「温度 72℃」，AI 认识。
「3 号挤出机二段加热区，用 A 供应商第三批改性料跑 B 产品，超出工艺上限 2℃，已持续 14 分钟，车间温度比昨天高 4℃」，这一句才是业务。
中间隔着一个业务模型。
二、为什么数据进不了模型：异构业务流
企业数字化做了这么多年，数据一直是按系统的边界产生的，不是按业务的边界。
ERP 里的对象是订单、物料、成本、结算。MES 里是工单、工序、设备、产能。IoT 关心点位、采样频率和时序。质量系统关心指标、缺陷、检验批。
财务看金额，生产看节拍，质量看合格率。同一批物料在这四个系统里有四个 ID，更新频率还不一样。
专家那部分更麻烦。
这个供应商最近这批料，指标是合格的，但按过去几年的经验，最好不要直接进这个工艺。
这句话可能值几十万。它不在任何字段里，也没有时间戳，没法按批次检索。
所以企业真正面对的是一堆异构业务流：不同系统、不同专业、不同时间尺度搅在一起。数据很多，互相不知道对方在说什么。
这时候换一个更大的模型，或者接一个更强的 RAG，只是把这堆各自为政的数据，用更会说话的方式检索一遍。
三、业务模型长什么样
我认为拆解路径是这样的：
企业业务 → 分支领域 → 业务对象 → 关键要素 → 状态 → 关系 → 规则 → 决策
拿原材料采购举例。最上面是采购业务，往下拆成供应商、原材料、产品、工艺、设备、仓储、质量、成本。
原材料不是一个字段。它展开是品类、材料规格、化学成分、物理参数、来源、批次、供应商、检验结果、历史使用记录。
再往下是关系：哪种材料适合哪种产品，哪种材料适合哪种工艺，哪两种材料不能组合，哪个质量指标变了会影响后面哪道工序。
到这一层，数据才开始互相咬合。
还有个经常被忽略的东西：小数据。
企业 AI 从来不只是大数据问题。真正决定成败的信息常常只有一句话------某个老师傅的经验，某个供应商三年前出过的一次特殊情况，某种原材料在某个工艺组合下的一次异常，某个项目负责人知道的一条特殊政策。
数据量极小，可能直接决定一批产品的死活。
难题于是变成两个：小数据怎么进入大数据，大数据怎么反过来验证小数据。
没有业务模型，小数据只是孤立经验，大数据只是统计结果。放进同一个语义体系，两者才可能咬合。老师傅那句「这批料别直接进这个工艺」，才有机会被几千条历史批次数据验证是真是假。
很多企业说自己缺知识库，其实缺的是把知识组织起来的结构。业务模型决定的是：什么和什么有关，什么状态算正常，什么变化会影响什么，什么情况下该做什么。
四、有了模型，才谈得上语义和推演
过去做数据，关注点在数据有没有、准不准、存在哪、怎么查。现在多了一个问题：这个数据到底是什么意思。
一份国标、行标、地标、企业制度，甚至一份已经被采用的团标，LLM 能很快拆出对象、条件、参数、限制、例外、适用范围、判断规则。这活儿人工做起来极慢。
但拆出来不等于业务上成立。还得继续回答：来源是什么，当前是不是有效版本，企业到底采用哪一个，有没有地方性例外，当前这个业务状态是否满足条件，违反了影响什么。
这已经从「理解文字」走到了「理解业务语义」。再往前一步，是让语义进入决策。
然后是因果。
过去的大数据分析找的是相关：某设备温度升高后，不良率上升。这有价值。
但企业真正想问的是：如果我现在把温度调低，会发生什么？
这是另一回事。企业里的因果是动态的。设备一动，工艺就跟着变；工艺一变，材料跟着变；变了材料，质量、成本、交付、客户全都要重算。
所以数字孪生的价值不在那块 3D 大屏。大屏只是把已知状态画出来。真正难的是把业务状态实时映射出来，在上面做推演：把 72℃ 调到 68℃，良率会怎么变，能耗会怎么变，这批料的交期会不会受影响。
不能参与判断和推演的孪生，只是一件更贵的可视化。
五、怎么开始，以及为什么大部分本体项目会失败
谈到这里，绕不开一个词：本体。
以前谈企业本体，很容易变成技术选型：要不要做知识图谱，要不要定义实体和关系，用哪个 ontology 框架。
从业务出发，这件事反而简单。本体不是技术产品，它只做一件事：把企业真实的业务世界，还原成机器能理解、能计算、能推演的结构。
谁是什么，处于什么状态，和谁有什么关系，什么变化会影响什么。
但现实是，很多全企业本体项目失败了。花了几百万，图画得很漂亮，最后没人用。
原因通常不是技术不行，是顺序反了。
这些项目从「把企业知识整理清楚」开始，而不是从「解决一个决策点」开始。前者没有终点，也验证不了对错。后者有明确的输入、输出和验收人。
更现实的路径是倒过来：
1.选一个具体的业务问题
2.解决一个决策点
3.建立一套语义
4.接入一组真实数据
5.验证一个结果
6.跑通一个反馈闭环
7.再扩展到下一个场景
这套做法慢，但每一步都能被业务方检验。
本体不是画出来的。它是在业务实践里长出来的。
六、把这条链接起来
ERP 管资源和流程，大数据管汇聚和分析，IoT 把设备拉进数字世界，知识图谱管关系的表达，自动化管执行。LLM 带来了语义理解和自然交互，Agent 开始往任务执行里走。
这些都很重要。缺的是一条统一的业务主线。
于是 ERP 有 ERP 的数据，IoT 有 IoT 的数据，知识库有知识，AI 有 AI。堆起来是一堆很强的系统，不是一个理解企业的系统。
把它们串起来的那条链，大概是这样：
业务 → 数据 → 模型 → 语义 → 决策 → 执行 → 反馈
业务产生数据，数据进入模型，模型赋予数据业务意义。语义帮系统理解当前状态，决策模型做判断，然后调用 ERP、MES、设备去执行。执行结果又产生新数据，回来修正模型。
这条链转起来，企业才算有了数据智能。
回到开头那条数据。
到那时候，temperature = 72 不再是一个等待被查询的字段。它会被自动展开成：3 号机二段加热区，A 料第三批，超出工艺上限 2℃，已持续 14 分钟，历史上这个组合下出现过 3 次类似偏移，其中 2 次在探伤环节返工。
系统不会只告诉你温度异常。它会说：建议调整到 68℃，预计良率下降 0.3 个百分点，但能避免约 X 件返工。或者说，这批料建议改走备用工艺。
而这个判断，会被下一批真实数据验证，然后写回模型。
所以问题也许不是哪个模型更强。是这家企业有没有本事，把 72℃ 翻译成一句 AI 听得懂、业务也认账的话。
把企业本身重新变成一个 AI 可以理解、判断、执行和持续学习的系统。
这件事情的核心，不是某一种技术。
而是业务模型、数据、语义、经验、自动化和 AI 的重新组合。
我觉得这可能才是企业智能化真正值得长期研究的方向。
今天就先说到这里，后面我们会继续沿着几个小问题慢慢聊。
最后
我们也在这条路上做一些开源实践。如果你对知识工程、知识资源、知识库感兴趣，欢迎关注我们的产品Molio。