数据都在 ERP 里，但老板还是看不清经营 看看 Ai 加持后这件事可以怎么解决

FDE-Watson
FDE-Watson

AI 数智化实验室

2026年10月22日 20:00
山东

去阅读

一家汽车供应链企业的老板，每天要问下面的人：订单到哪了、货发了没、这笔钱为什么要付。数据都在 ERP 里，但经营还是一团雾。

我们长期给传统企业做 AI 应用落地，帮企业把 AI 接进真实业务流程，而不是停在演示。这个案例来自公开的 FDE 案例集 ：一家汽车供应链企业，向下游销售汽车维修零部件，从上游采购、做简单加工和组合，再交付客户。

它要回答一个问题：ERP 用得好好的，为什么老板还是看不清经营？以及在数据齐全的情况下，AI 到底该补哪一段。

一、4980 个扳手，卡在哪里

举一个案例里的真实场景。

供应商应该发 5000 个扳手，实际只到了 4980 个，少 20 个。

按 ERP 的标准逻辑，数量没达到 5000，这笔订单就不能正常入库。但现实业务不会因为少了 20 个，就把 4980 个扳手退回去——仓库里实实在在多了 4980 个。

于是就出现了这种状态：货已经发生了，系统没有完整结束，账上看不见。

员工的处理办法是额外记录、解释、沟通；老板想知道真实库存，只能再去问人。

这不是某个系统的 bug，而是标准化产品必然的边界。

图 1｜同一个事实，两种呈现：账面卡住，还是标记差异

ERP 解决的是“标准化的信息管理”，老板要的是“贴近经营的判断视角”。SaaS 为了商业回报不会给每家企业做深度定制，所以数据都有，唯独看不清。

二、老板真正在问的四个问题

这个项目一开始，没有先问“你想上什么 AI 功能”，而是先跟老板聊：你每天最担心什么？

最后收敛成四个问题：

• ◆客户下了订单，企业内部到底怎么往下走？
• ◆生产任务有没有正常推进？
• ◆采购有没有多订，库存到底多少？
• ◆什么时候能发货，要付给供应商的钱对应哪些客户订单？

这四句话对应六个环节：订单、生产任务、采购、库存、发货、回款。老板要的是这条线能自己跑，出现异常再来告诉他，而不是每天靠人汇报。

注意，这里没有“AI 助手”这个词。诉求提得越具体，后面越不容易做成演示。

这也是方法上的一个关键选择：直接问“你想要什么 AI 功能”，拿回来的往往是一堆功能清单；换一种问法——“你每天最担心企业发生什么”“哪些事必须亲自盯”“什么异常希望第一时间知道”——得到的就是经营问题。同一家企业，两种问法会通向两个完全不同的项目。

三、四步：AI 只做它该做的那一段

第一步，保留 ERP，只把数据重新组织。 没有重写系统，原有 ERP 继续承担业务功能，在它的数据基础上做二次加工。要解决的不是“系统没有数据”，是“数据没按经营逻辑串起来”。

第二步，让 AI 做匹配和核对。 财务要付供应商 10 万，过去要回答“为什么付这 10 万”，得人工去对供应商订单、客户订单、库存签收。这类工作本质是数据之间的关系判断——案例里把 AI 理解成“数据关系处理器”：判断不同业务环节是否对得上，而不是让它写方案、做决策。

第三步，把异常从“人发现”变成“系统提醒”。 给关键节点设判断标准：价格是否合理、库存是否异常、应付款能不能和业务数据对上。一旦异常，通过飞书卡片推给对应的人。

第四步，正常情况自动跑。

形成闭环：自动运行 → 持续匹配核对 → 发现异常 → 主动提醒 → 人处理异常。

这四步里，AI 的位置很窄。窄，但准。

为什么不重写一套系统？ 因为重写的代价远大于收益。企业原有的 ERP 还在承担日常业务，采购、入库、发货都靠它跑；推翻重做意味着业务停摆、人员重新培训、历史数据迁移。而真正缺的只是“把数据按经营逻辑重新串一遍”这一层。在原有数据上做二次加工，既不动业务重心，又能把老板要的视角补上。这是成本最低的路径，也是大多数传统企业真正能承受的路径。

判断标准也很朴素：如果现有系统能跑业务，就不要动它；如果它只是“能跑但不能看”，那就在上面加一层。

图 2｜订单从下单到回款，异常才需要人介入

四、效果：能证明什么，不能证明什么

案例方自己说得很克制：上线时间还短，目前不能证明利润、成本等经营指标有明确量化提升。

已经能直接感知的变化有两个：

1. ◆ 01系统更接近真实业务。

还是 4980 个扳手，现在能告诉老板实际库存增加了 4980 个，而不是卡在“不足 5000”。
2. ◆ 02应付款可追溯。

过去只看到一个应付金额，现在能追到它对应哪些客户订单、哪些上游采购、为什么形成。

另外，“企业能自动运行”和“异常能通知到人”这两件基础功能已经实现；减少重复订货这类更进一步的经营效果，还需要跑一段时间才能验证。

这段值得单独强调：把刚上线的项目包装成已经产生巨大收益，是做 AI 落地最容易犯的错。 能明确解决什么、还不能证明什么，都讲清楚，客户才敢继续往下投。

五、四个挑战，三个不在技术里

老板的认知。 做技术出身的人和制造业老板看问题的方式不一样。第一步得先理解他的经营逻辑，同时让他知道 AI 能做到什么、不能做什么。这一步不对齐，后面方案一定跑偏。

行业 Know-how。 不同行业的业务规律差别很大。FDE 不必是行业里最资深的专家，但至少要知道这个行业基本怎么运转，否则连客户真正的问题都判断不了。行业理解是进现场的门票。

数据。 这是这套方案没法直接标准化复制的主要原因。同一个行业、规模差不多的企业，数据基础、口径、流程都可能差很多。案例方在这个项目上花了大量时间做数据清理、治理和口径统一。方法论可以复用，底层数据和业务逻辑未必能复制。

ROI。 这一条最容易被忽略。FDE 的核心成本是人的时间。如果一个需求要做大量数据治理、长期维护和定制开发，即使客户满意，对团队也未必是好生意。所以要问的不只是“能不能做”，还有“值不值得做、长期维护成本多少”。

六、一个反例：IT 完成了转型，业务回去找设计师

案例方提到自己早年在金融机构见过的一幕。

业务部门觉得找设计师做营销图太慢，提出用 AI 提效。需求合理。但金融机构有数据合规要求，不能直接用外部模型，只能本地部署。最后花钱搭了一套生图系统，生成出来的图实际不能用。

结果是：IT 部门完成了“AI 转型”，合规部门完成了数据安全要求，领导可以说企业完成了转型，业务部门还是回去找设计师做图。

从经营角度看，什么都没变。

这就是“为 AI 而做 AI”的典型样本：每个部门都完成了自己的 KPI，唯独业务问题没被解决。

七、三种能力，缺一个都做不成

案例方把这个角色拆成三种能力：懂业务、懂 AI、能落地。

只懂技术，很容易变成技术外包——需求方说什么就做什么，做完发现没人用。只懂咨询，容易停在方案层，PPT 很漂亮，系统一行没动。只懂业务，知道问题在哪，但没法把它变成能跑的东西。

真正难的是把三件事串起来：从经营问题拆到业务流程，从流程拆到数据和系统，最后才落到具体的 AI 能力。这条链路断在任何一环，项目都做不成。

还有一条经验值得记住：不要一开始就执着于做一个完美的标准化产品。 真实企业的业务太复杂，同一个问题在不同企业里，数据基础和处理方式可能完全不同。合理顺序是先进真实场景把一个真问题解决掉，再从多个项目里找共通方法，最后才判断哪部分值得标准化。反过来做，做出来的是功能，不是落地。

八、如果你也在考虑这件事

三条判断，可以直接对照：

1. ◆ 01这个问题是“信息管理”还是“经营判断”？

前者上系统，后者才需要把数据按经营逻辑重新串，AI 只做中间那段关系判断。
2. ◆ 02异常现在是谁发现的？

如果靠人盯、靠人问，那就有价值；如果本来就有报表自动报警，优先级往后放。
3. ◆ 03维护成本算过吗？

数据治理和口径统一是长期活，算不清这笔账的项目，上线即巅峰。

下周能做的一件事：挑一条业务线，把从订单到回款的关键节点画出来，标出“数据存在但看不清”的位置。那张图，就是你第一个 AI 场景的边界。

案例来源：Datawhale《FDE 案例 100》·《从看不清订单到看清经营：FDE用AI让制造企业的经营流程更透明》。我是 watson，一个专业的企业 ai 应用落地专家。如果这篇对你有用，欢迎点赞、在看、转发。