软件的边界，不是业务的边界：为什么需要企业 OS

一家企业需要完成的，是从客户需求到交付回款的完整业务。建设数字系统时，面对的却是 ERP、CRM、OA、PLM、MES，以及飞书、钉钉等各有边界的产品。

客户修改交付要求后，销售需要确认承诺，技术要检查方案，采购与生产也可能需要调整。相关系统都已经上线，事情却仍然经常回到群聊和 Excel。

当然，企业面对的数字化起点差异很大。许多互联网公司的核心业务直接运行在软件中，业务对象和执行规则已经有较完整的系统表达，也有内部团队持续维护。即使没有显式使用“本体”这个名称，其中不少建模工作也已经相对完善，AI 更容易获得明确的数据与行动接口。

大量非数字化原生企业则没有这样的条件。业务先在线下运行，软件在不同阶段按部门和项目陆续引入。完整的业务逻辑仍有相当一部分留在表格和人的经验中，也未必有人持续统筹业务建模与系统建设。

本文主要讨论后一类企业：局部软件已经不少，但完整业务仍然依靠人来衔接。

一、软件不断扩张，边界问题仍然留给甲方

ERP、CRM 等系统从特定管理领域出发，逐渐向相邻业务扩展。飞书、钉钉等平台则从 IM 与协同入口出发，通过审批、表格、低代码和应用承载越来越多的局部业务。

产品之间因此既有空白，也有重叠。对甲方来说，最直接的问题就是：这件事到底应该放在哪里？

例如，销售在 CRM 里维护了一份合同，OA 里有它的审批记录，ERP 里又录入了对应订单。为了跟踪交付，计划人员另外维护一张表，销售每天看这张表向客户反馈。

客户修改交期后，销售先改 CRM，还是先发起审批？计划表能不能直接改？ERP 里的日期由谁更新？如果几处不一致，生产应该按哪个日期安排？

每个软件都可以提供“修改日期”的功能，但企业需要确定的是：客户提出要求、内部评估可行、双方正式确认，这几件事分别发生在哪里，如何接续。

软件厂商通常能够回答自己的产品可以做什么，甲方却必须负责判断这些产品组合起来以后，业务能不能完整运行。

软件的功能边界，不能直接拿来当作企业的业务边界。 两者之间没有被设计清楚的部分，最后会变成人的核对、搬运和协调工作。

二、集成原本就应该解决这些问题

这不是 AI 出现后才产生的新任务。系统集成原本就应该让局部软件协同工作，但接口接通之后，业务仍然可能接不起来。

继续看交期变更。如果 CRM 里的日期一改，ERP 和计划表就自动同步，看似消除了重复录入，却可能产生更严重的问题：销售刚记录了客户的要求，生产计划就被当成已经确认的安排修改了。

缺少的业务定义是：“客户要求交期”和“企业确认交期”分别意味着什么，由谁确认，什么条件下才能改变后续计划。

有效的集成必须以这些定义为依据。否则，接口只是更快地传递了一个含义不清的字段。

《传统企业数字化里的隐形断层：谁来定义业务如何进入数字世界？》讨论过这个问题：熟悉业务的人未必承担建模工作，软件团队又往往只负责实现已经提出的需求。跨系统的业务定义因此容易悬空。

如果这项工作始终没有人负责，每增加一个系统，就再补一轮映射；业务变化后，又逐个检查接口。集成成本会随着局部建设不断累积。

三、企业 OS：围绕完整业务重新组织系统

在《企业数字化的终局，是业务的数字孪生》中，我讨论了企业数字世界应当承载什么。在此基础上，把支撑企业持续运行的共同数字环境称为企业 OS。

它需要明确一件事在业务上如何成立，再安排软件分别承载哪些部分。

还是交期变更的例子：客户的新要求先形成一项待评估的变更，关联原订单。计划人员结合物料与产能判断能否满足；如果需要修改技术方案，再交由相应负责人确认。最终承诺经过确认，才更新正式交期及受影响的计划。

CRM 可以继续负责客户沟通记录，ERP 保存订单，生产系统安排执行。但这些软件承载的是同一件事的不同部分，彼此关系由业务定义决定。

这也让软件需求有了检验依据。“增加一个交期审批”究竟要解决什么问题？需要判断的是产能、技术可行性，还是商业承诺？哪些判断已经完成，哪些还缺少责任人？把这些问题拆开，才能决定需要什么页面和流程。

关于如何把责任落到对象上，可以接着看《讨论哪里能用 Agent 之前，先重新理解职能和组织分工》。

企业 OS 可以从一段有限业务开始建设。先让交期变更在现有系统之间正确流转，再逐步扩展。每解决一个局部问题，都将新增定义放回共同的业务模型，避免下一次需求又生长成一套孤立流程。

四、LLM 打通表达与业务，也需要重新设计交互模式

传统系统要求人先理解软件怎么组织，再把现实翻译成它接受的输入。客户说了一句话，销售要自己找到订单、拆出变更内容、填写表单，还要准备给其他部门的说明。

LLM 有机会承担其中的翻译工作，连接非结构化表达与结构化业务。但要利用这种能力，交互也需要重新设计。

假设客户发来一句话：

“这批柜子里，A 项目的十台能不能提前到下周五？其余的还是按原计划。”

业务助手需要结合当前沟通关联的客户和订单，找出可能对应的交付项。如果存在两张候选订单，就先请销售确认，而不是直接修改一个日期。

对象确定后，系统可以呈现一份变更草案：

销售确认系统理解无误后，这份草案进入交期评估。客户原话被保留下来，后续参与者也能看见它如何被解释。

这里发生的变化，是人可以先表达业务意图，系统再把需要确认的结构显露出来。信息不足时补问，涉及多项变化时展开表格，需要查看图纸时打开对应版本。交互形式随着当前工作改变。

反过来，系统也可以把业务结构转回适合人的表达。评估发现十台里有两台缺少元件，就具体指出这两台、缺少的物料以及预计到货时间，让销售知道客户要求卡在哪里。

因此，需要重新设计的是自然表达进入业务、业务结果返回人的整个过程。LLM 生成的内容必须落到明确对象上，才能成为下一步工作的依据。

五、与业务深度集成的 IM，将成为核心基础设施之一

交期评估很少由一个人独立完成。销售会找计划，计划会问采购，有时还需要技术人员确认替代方案。大量关键事实和决定就在这些交流中产生。

这使 IM 成为自然表达进入正式业务的重要入口。

继续看前面的十台柜子。采购在群里回复：“缺的元件供应商说周四能到。”如果系统只能保留这条消息，计划人员仍然要判断它说的是哪批物料，再手工更新表格。几天后有人问交付风险，还得重新翻聊天记录。

深度集成后，这条回复可以关联到对应采购项，并形成一项待确认的到货信息。它应保留“供应商承诺周四到货”的含义，不能被当成已经收货。

计划人员查看这项信息时，可以同时看到它影响的十台柜子，以及到货后还需要的生产时间。如果周四到货仍然来不及，就围绕同一项交期变更继续讨论替代方案。确认采用某个方案后，相应任务和计划随之更新。

后续元件实际到货，仓库更新的收货结果又能回到这段业务中。参与者不必逐个询问“现在进行到哪里了”，也不必从整段聊天里重新拼出结论。

这要求消息能够引用业务对象，讨论中的建议能够转成待确认事项，正式决定能够触发执行。IM 因此需要与 LLM、业务系统一起设计。

从 IM 向业务扩展有明确价值。但如果群聊里的承诺、多维表格里的计划和 ERP 里的订单各自更新，即使都在同一个平台入口里，衔接工作依然落在人身上。

六、有了本体，为什么仍然可能落不下来

关键在于业务是否已经被清楚建模，以及模型是否贯穿实际运行。本体提供了一种明确、可计算的组织方式；已有系统中形成的良好业务模型，同样是 AI 可以利用的基础。

Palantir 是这一方向的现实参照：围绕 Ontology 组织数据、逻辑与行动，将分散的系统能力连接到业务决策和执行之中。

但引入本体后，实施仍然可能在两个地方断开。

第一处是模型与系统实现脱节。模型中已经区分“客户要求交期”和“确认交期”，页面却仍然只有一个“交期”字段；接口也继续把它同步到所有系统。新定义只存在于模型里，实际操作仍沿用旧逻辑。

第二处是 AI 助手之间的业务没有接续。销售助手读懂了客户要求，生成一段“十台提前交付”的说明；销售复制给生产助手，得到“需要核实物料”的建议；再复制给采购助手，查到供应商的预计交期。最后，销售仍然要把几段答案整理成表格，找人确认，再到各个系统修改。

几个助手分别完成了自己的问答，却没有共同推进那项交期变更。底下即使存在本体，也没有真正组织起这段工作。

要避免这些断层，业务模型必须进入系统建设和运行过程。模型区分出的状态，要在页面和接口中得到保留；一次跨系统处理，要有能够持续引用的业务对象，记录已形成的结果和仍待完成的工作。

《从业务、产品到代码，三张可互算架构图》进一步讨论了这种对应关系：业务定义变化后，应该能够找到受影响的系统实现；功能完成后，也应该能够检查它是否正确承载了业务。

企业 OS 就是在这样的持续建设中形成的。当这些模型沉淀出行业共性，并沿着客户、供应商和上下游的真实协作关系延伸，就有了进一步发展为产业 OS 的基础。