生产马上要排产了，物料却还没齐套。

采购说，订单已经下了，是供应商延期。仓库说，货还没到，没法入库。工程说，替代料还在确认。每个部门都有自己的工作要做，也都能解释为什么事情没完成。

但生产还是开不了工。

这时候，如果我们去看系统，可能会发现采购需求有人负责、采购订单有人跟进、到货验收有人处理，相关任务都有经办人，流程也在正常运转。

每项工作都有人做，为什么最终的业务结果仍然没有保障？

这个问题在 Agent 出现之前就存在了。ERP、OA、CRM 等系统已经建设了很多年，为什么企业仍然需要依靠 Excel、群聊和人工协调来完成日常业务？

很多时候，问题不在于系统缺少某项功能，而在于系统从一开始就没有正确表达业务本身。

一、采购需求不是业务的起点

物料齐套的目标不是完成采购，而是保障生产能够在需要的时间，获得正确数量、规格和质量的物料。

采购只是实现这个目标的一部分。

为了保障物料齐套，企业可能需要计算需求、检查库存、核对在途、制定采购计划、跟进供应商交期、协调替代料、完成到货验收等。不同企业的具体分工可以不同，但这些工作共同服务于一个业务结果：生产所需物料齐套。

现在回头看开头的问题，就会发现，采购部门说「我已经下单了」，可能完全属实。它完成了采购执行中的一项工作，却不一定意味着物料齐套的业务目标已经实现。

同样，仓库完成收货入库，也不意味着生产所需的所有物料都已齐套。

局部工作的完成，不等于整体业务结果的实现。

企业需要明确谁对相关业务结果负有责任，再将实现结果所需的工作分配给相应部门和人员。采购、仓储、工程、计划等部门可以分别承担不同的职责，但不能因为工作被拆分了，就让最终结果失去明确的责任归属。

这里没有一个适用于所有企业的固定答案。某些企业由计划与物控部门统筹物料齐套，某些企业可能采用不同的组织安排。重要的不是预先指定某个部门，而是让企业根据实际业务目标和组织设计，明确谁负责保障什么结果。

如果连这个问题都没有回答，那么继续讨论「采购需求应该由谁负责」，就很容易停留在执行层面。

我们可能已经明确了谁负责提需求、谁负责下单，却仍然不知道谁负责确保需求最终得到满足。

二、业务问题没有解决，系统就开始替业务兜底

当组织没有明确整体业务结果的责任归属时，系统建设通常会遇到一个直接的问题：需求需要有人负责，流程需要有人推进，异常需要有人处理。

于是，系统开始增加各种字段。

采购需求负责人、采购执行人、协调人、最终负责人……每个字段似乎都能解决一部分问题。

但这些字段究竟分别意味着什么？

采购需求负责人，是对需求的准确性负责，还是对需求最终得到满足负责？采购执行人负责完成下单，还是还要负责供应商交付？协调人只是推动流程，还是需要对结果承担责任？最终负责人和前面几种角色之间又是什么关系？

如果业务没有先明确这些区别，系统就只能依靠字段名称、流程约定和人工解释来维持运行。

遇到新的业务场景时，还可能继续增加字段、允许更多关联，再增加一些特殊规则。表面上，系统的表达能力越来越强；实际上，原本没有明确的业务责任，只是被拆成了更多需要解释的信息。

系统能够记录一个人被指定为负责人，却不能仅凭这个字段，创造出真实、合理且可执行的责任安排。

这不是说系统不应该支持多种角色。业务确实需要经办人、审核人、协同人员等不同角色。问题在于，每增加一种角色，都应该有明确的业务含义和适用场景，而不是把它当成弥补责任不清的通用办法。

如果企业仍然没有决定谁对什么结果负责，那么增加再多字段，也只是让系统更详细地记录这种不确定性。

三、一个底层问题，会变成一串下游问题

假设企业最终决定：采购需求需要明确负责人，但允许多个部门同时承担同一项需求的最终责任。系统因此支持多人关联，并通过额外字段区分各自的责任。

看起来，问题解决了。

但接下来，系统需要判断谁有权推进采购、谁可以处理异常、谁应该收到逾期提醒、谁需要对未完成的任务负责，以及统计时应该把结果归到哪个部门。

如果多人负责的含义没有明确，这些问题就无法单纯依靠已有数据回答。

下游模块只能继续补充判断规则。某个流程认为第一个关联人是负责人，另一个模块认为指定的主责字段优先，还有一个报表需要人工判断应该归属哪个部门。

原本一个业务定义的问题，就这样扩散到了流程、权限、统计和自动化。

现实中，允许多人共同负责，往往也不是经过充分设计后的管理选择，而是组织无法就责任归属达成一致时，在系统里留下的妥协。两个部门都不愿意独自承担责任，于是把双方都填进负责人字段，先让流程跑起来。

但系统记录了这个妥协，并不意味着责任问题已经解决。出了问题，双方仍然可以证明自己完成了分内工作；而系统因为没有明确的最终责任归属，也无法据此判断下一步应该由谁统筹处理。

于是，系统可能继续增加协调人、升级人、最终负责人等角色，复杂度不断累积。

这类复杂度还会传递到更下游的模块。每个模块看起来只增加了一点判断逻辑，但随着模块增多，不同模块可能逐渐形成不同的解释，最终难以保持一致。

当 AI Agent 开始基于这些数据自主判断和执行任务时，问题还会进一步放大。

例如，采购 Agent 发现一笔订单已经延期，而生产排产时间即将到来。系统显示采购员已经下单，协调人正在跟进，工程部门还有一项替代料确认任务未完成。

Agent 接下来应该做什么？

它可以提醒采购员催交期，但如果供应商明确无法按时交货，单纯催促就未必有用。它可以建议启用替代料，但是否允许替代、由谁确认，又是另一组业务规则。它还可以通知生产计划调整排产，但如果没有明确谁对物料齐套结果负责，Agent 就无法仅凭这些字段确定谁应该统筹处理异常。

如果系统只记录了多个参与者，却没有清楚表达业务目标、责任边界和相应的决策规则，Agent 就只能猜测、反复询问，或者按照某个局部规则执行动作。即使它能够成功调用工具、更新状态，也不代表它做出了正确的业务决策。

如果业务语义需要在每个下游模块中重新解释，系统就失去了通过统一模型降低复杂度的价值。

四、问题发生在哪层，就在哪层解决

遇到业务场景无法顺利落入系统时，不能一遇到困难就增加字段或放宽关系。应该从上往下排查：

1. 业务结果与责任： 要实现什么结果？谁对结果负责？如果没有明确，先解决业务目标与责任安排。 2. 职责边界： 各方分别负责什么？如果存在推诿或重叠，先明确职责范围和交接关系。 3. 职责拆分： 现有职责是否过大或分工不合理？必要时重新拆分职责，调整组织安排。 4. 系统表达： 业务定义已经明确，现有模型仍无法承载时，再检查对象、关系、状态和规则设计。

例如，医疗设备维修的目标是恢复设备可用。如果维修、采购和仓储都完成了各自的任务，设备却仍然停用，就应该先检查整体结果的责任归属和各项职责的边界，而不是直接增加一个「设备恢复负责人」字段。

复杂度应该在其所属层级或上层消解，而不是通过改变下层概念的含义、放宽底层关系约束，或者不断增加例外，转嫁给下游系统。

五、从业务开始，不是照搬现状，而是先搞清楚业务

从业务开始，并不是要求系统忠实复刻企业现有的组织架构和工作方式。

现实业务本身也可能存在问题。部门之间可能职责重叠，某些工作可能长期无人承担，现有流程也可能无法保障业务目标。如果只是把这些现状原样搬进系统，系统建设反而会固化原有问题。

因此，业务分析需要先明确业务目标、责任安排和运行规则，再决定系统应该表达什么。

例如，企业提出「增加一个采购流程」，不能只从申请表单和审批节点开始设计。需要先弄清楚采购需求为什么产生、采购数量如何确定、库存和在途如何参与计算、谁对需求的准确性负责、谁有权批准采购，以及采购完成后要保障什么业务结果。

这些问题明确之后，才能判断需要哪些业务对象、关系、状态和规则，以及系统应当如何承载它们。

如果现有模型无法表达一种合理的业务安排，就应当认真检查模型本身；如果问题来自业务定义尚未明确，就应该先解决相应的业务问题。

业务定义决定系统需要表达什么，系统模型再将这些定义转化为稳定、可执行的结构。两者需要持续协作，但不能相互替代。

六、这就是为什么很多系统不好用

很多企业上了 ERP、采购系统和生产管理系统，却依然依赖 Excel 安排生产、核对库存、计算缺料。

例如，ERP 记录了库存，采购系统记录了订单，生产系统记录了排产计划，但系统没有把生产需求、物料清单、库存、在途和采购交期组织成能够直接支持齐套决策的业务模型。

于是，计划人员只能从不同系统导出数据，手动拼表、计算缺料、调整优先级，再把结果发给相关部门。

系统没有真正反映业务怎么运转，大家就只能在系统外重新组织业务。 系统建得越多，不代表管理能力越强；如果关键业务关系和责任没有被正确表达，最后仍然得靠 Excel 和人工协调来兜底。

结语

业务定义不清，系统就只能不断加字段；业务关系没有理顺，下游就只能反复补逻辑。最后，系统记录了大量数据和流程，却仍然无法真正支撑管理。

回到开头那个场景：生产马上要排产了，物料却还没齐套。一个真正好用的系统，应该让缺口提前可见，让影响范围和责任归属清楚可查，而不是等到排产受阻，再由人从几套系统和 Excel 里拼出答案。

系统建设不是给每一种业务模糊性都留一个字段，而是要识别问题的根源，在正确的层级解决它。这才是系统建设必须从业务开始的原因。