从看不清订单到看清经营：FDE用AI让制造企业的经营流程更透明

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

中小制造企业的订单、生产、采购、库存、发货和回款数据虽然已进入 ERP，却仍分散在不同环节，老板需要不断询问才能了解订单状态。项目重新组织和匹配 ERP 数据，让 AI 参与跨环节核对并主动提示异常，使经营问题变得可见、可追溯。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

这个案例，最开始先跟老板聊他到底想解决什么问题。

这是一家汽车供应链企业，主要向下游销售汽车维修零部件。

它的生产形态偏轻，主要从上游采购零部件，再做一些简单加工、组合和组装，最后形成产品交付给客户，跟传统意义上那种重生产线的制造企业很不一样。

表面上看，这家企业其实已经有ERP系统，订单、生产任务、采购、库存、发货等数据都有。

问题是，这些数据虽然存在，但并没有真正形成老板需要的“经营视角”。

老板真正关心的是：客户下了一个订单之后，企业内部到底怎么往下走？

生产任务有没有正常推进？

采购有没有多订？

库存到底有多少？

什么时候能发货？

财务现在要付给供应商的钱，到底对应哪些客户订单？

老板每天有大量事情要处理，不可能自己逐条核对，所以很多时候只能问下面的人。

这也是FDE与普通软件外包最重要的区别：FDE先站在老板经营的角度，找到真正影响经营的问题，再据此开始开发。

比如这个企业老板，他真正想要的，是企业能够尽量自动化地运行。

他希望自己不用每天盯着工厂，也能知道现在有多少订单进来了、多少正在生产、多少已经收货、多少已经发货、多少已经回款；如果中间出现异常，再主动告诉他。

所以最后项目团队把问题收敛成了几个很具体的事情：让订单流转变得透明，让不同业务数据能够对应起来，让异常能够被发现，让老板不用再依赖人工询问。

二、原有流程与核心问题

过去他们其实有自己的解决办法。

企业使用的是管家婆这样的标准化ERP，里面已经能够看到客户订单、生产任务单、供应商采购订单、库存以及发货等信息。

对于标准化的企业管理来说，这套系统本身是能够工作的。

所以FDE不会说原来的方式“不好”。

问题在于，ERP解决的是一个标准化的信息管理问题，而老板需要的是一个更加贴近企业经营的判断视角。

SaaS产品为了保持标准化和商业ROI，本身不会针对每一家企业的经营方式做大量深度定制。

于是就出现了一个很典型的情况：数据都有，但老板还是看不清。

举个很简单的例子。

供应商给企业发来5000个扳手，但实际只发了4980个，少了20个。

按照原来的ERP逻辑，因为数量没有完全达到5000个，这笔订单可能就无法正常入库。

但现实业务不会因为少了20个，就把4980个扳手退回去。

仓库里实际上已经多了4980个，只是系统的标准逻辑没有办法很好地表达这种“实际发生了，但标准流程没有完整结束”的情况。

这类问题如果靠人工处理，就意味着员工需要额外记录、解释和沟通；如果老板想知道真实情况，又得再去问人。

三、AI 解决方案与交付路径

当时，FDE做的第一件事，是先把老板的经营诉求拆出来，没有急着写代码。

因为如果直接问老板“业务人员想要什么AI功能”，最后很容易得到一堆功能需求。

但如果问的是“业务人员每天最担心企业发生什么”“哪些事情业务人员必须亲自盯”“哪些异常一旦发生业务人员希望第一时间知道”，得到的东西就完全不一样。

这个项目最后形成了一个比较清晰的思路：

第一步，先明确老板要看什么。

老板真正要看的，是企业现在经营到什么状态。

所以项目团队围绕订单、生产、采购、库存、发货、回款这些关键环节，把老板真正关心的信息梳理出来。

第二步，保留原来的ERP，把必要的数据拿出来重新组织。

FDE没有去重新开发一套ERP。

原有系统继续承担原来的业务功能，项目团队在它的数据基础上做二次加工。

因为真正的问题在于，“系统里的数据没有按照老板的经营逻辑串起来”。

第三步，让AI去做过去大量依靠人工完成的数据匹配和核对。

比如财务要支付供应商10万元，过去要回答“为什么要付这10万元”，可能需要人工去对应供应商订单、客户订单、库存签收等信息。

这时候AI发挥作用的地方，在于做数据之间的匹配、核对和关联。

也就是说，可以把这里的AI理解成一个“数据关系处理器”：它帮助系统判断不同业务环节之间到底是什么关系，有没有对得上。

第四步，把异常从“人去发现”变成“系统主动提醒”。

企业正常运行的时候，FDE希望它自己往下走；只有出现问题的时候，才需要人介入。

所以项目团队给一些关键业务节点设置判断标准，例如价格是否合理、库存数据是否异常、应付款能不能和相关业务数据对应起来。

一旦出现异常，就通过飞书卡片提醒相关人员。

这实际上形成了一个很简单的闭环：正常情况自动运行 → 数据持续匹配核对 → 发现异常 → 主动提醒 → 人处理异常。

从项目实践看，这比单纯做一个“AI助手”更有价值，因为它真正嵌进了原来的业务流程。

四、项目结果与业务价值

这个项目目前上线时间还比较短，所以FDE可以比较谨慎地说：现在还不能证明企业的利润、成本或者其他经营指标已经发生了明确的量化提升。

但有一些变化是已经能够直接感知到的。

以前ERP里存在一些“有数据但看不清”的情况，现在已经可以把它重新呈现出来。

还是刚才那个4980个扳手的例子。

原来的ERP可能因为没有达到5000个的标准数量，所以没有办法很好地反映真实库存；现在项目团队可以告诉老板，实际库存里已经增加了4980个。

这看起来只是一个很小的变化，但对于老板来说，区别在于：系统开始更接近真实业务了。

另外一个比较明显的变化，是财务应付款的可追溯性。

还是前面财务应付款那个例子。

以前老板看到“今天要付给某个供应商多少钱”，可能只能看到一个结果；现在可以进一步追溯，这笔钱对应了哪些客户订单、哪些上游采购，以及为什么形成这笔应付款。

所以目前这个项目更像是完成了从“有没有这个功能”到“经营信息能不能被看清楚”的第一步。

老板最初想要的三件事情里，“企业能够尽量自动运行”和“出现异常能够通知他”，目前基础功能已经实现；至于减少重复订货等更进一步的经营效果，还需要继续运行一段时间才能验证。

项目实践表明这一点也很重要。

做FDE不能为了证明AI有效，就把刚上线的项目包装成已经产生巨大经营收益。

业务价值需要时间验证，能明确解决什么、还不能证明什么，都应该讲清楚。

项目图示

原案例图示（PDF 第 201 页）

原案例图示（PDF 第 204 页）

原案例图示（PDF 第 206 页）

五、关键落地难点

这个项目让FDE比较深地意识到，FDE真正难的地方，很多时候在AI技术之外。

FDE团队总结下来，至少有四个挑战。

第一个挑战，是老板的认知。

FDE原来是互联网大厂产品经理出身，和制造业老板看问题的方式并不一样。

所以第一步，FDE先理解他的经营逻辑，同时让他知道AI到底能做到什么、不能做到什么。

如果这一步没有对齐，后面的方案很容易跑偏。

第二个挑战，是行业Know-how。

FDE团队服务的客户不只有制造业，还有医疗、贸易、物业、集采等，不同行业的业务规律差别很大。

FDE不一定要成为这个行业最资深的专家，但至少要知道这个行业基本是怎么运转的。

否则项目团队连客户真正的问题是什么都判断不了，更不用说设计方案。

所以项目实践表明，行业理解，是FDE进入业务现场的门票。

第三个挑战，是数据。

这也是这个制造业案例目前没有办法直接标准化复制的主要原因。

项目初期曾考虑，既然这套方案做出来了，是不是可以直接复制给其他制造业企业。

但真正做下去之后发现，即便是同一个行业、规模差不多的企业，底层的数据基础、数据口径、业务流程都可能差很多。

项目团队在这个项目上花了大量时间做数据清理、数据治理和口径整理。

所以最后项目没有急于把它包装成一个标准化产品。

方法论可以复用，但底层的数据和业务逻辑，未必能直接复制。

第四个挑战，是ROI。

这是FDE团队需要持续关注的问题。

以前做大厂产品，项目团队会习惯把事情做到80分、90分。

但到了真实企业场景里，项目团队还得问一句：做到80分到底划不划算？

因为FDE的核心成本就是人的时间。

如果一个项目需要投入大量人力做数据治理、长期维护和定制开发，那么即使客户觉得项目很好，对FDE团队来说也不一定是一门好生意。

因此，FDE不能只看“这个需求能不能做”，还会看“这个需求值不值得做”“长期维护的成本是什么”“这个项目的ROI是不是合理”。

这也推动项目转向寻找更加标准化场景的原因。

六、FDE 交付方法与企业启示

项目实践表明，企业做AI，最容易犯的错误就是为了AI而做AI。

另一个金融机构项目就发生过类似的事情。

当时业务部门觉得找设计师做营销图片很慢，希望用AI提高效率。

从业务逻辑上看，这个需求完全合理。

但因为金融机构有数据合规要求，不能直接使用外部模型，最后只能做本地部署。

结果就是花了不少钱搭了一套AI图片生成系统，但生成出来的图片实际不能用。

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

从企业经营的角度看，什么都没有改变。

这类FDE项目的经验可以归纳为以下几点。

首先，AI转型最好从老板真正关心的经营问题出发。

老板要解决的是降本增效、安全、效率、经营透明度等问题。

先把这些问题找出来，再判断AI能不能介入。

其次，业务部门必须有动力、有资源。

IT当然要参与，但不能变成“IT部门为了完成AI转型而推动AI转型”。

真正每天承受业务问题的人，才最清楚什么地方值得改。

所以最好由老板主导，或者由真正承担业务指标的负责人推动，并且给业务团队足够的资源和权限。

第三，FDE要同时具备三种能力：懂业务、懂AI、能落地。

只懂技术，很容易变成技术外包；只懂咨询，又可能停留在方案层面；只懂业务，也很难真正把AI落到系统里。

FDE真正有价值的地方，就是把“经营问题”一路往下拆成“业务流程”，再拆成“数据和系统”，最后才落到具体的AI能力。

最后，项目经验强调：不要一开始就执着于做一个完美的标准化产品。

真实企业的业务往往很复杂，同样一个问题，在不同企业里可能有完全不同的数据基础和处理方式。

先进入真实场景，把一个问题真正解决掉，再从多个项目里找到共通的方法，最后再判断哪些部分值得标准化。

这一案例中的FDE角色，本质上就是这么一个过程：从老板的经营问题出发，进入真实业务现场，找到AI真正能够创造价值的节点，再把技术变成业务流程的一部分。

AI降低了过去很多项目的开发和交付成本，让一些以前因为成本太高而被搁置的问题重新变得可行。

但企业真正的诉求并没有因为AI出现而改变。

改变的是，AI让企业有机会用更低的成本、更高的效率，把过去那些长期存在的问题真正解决掉。

从项目实践看，FDE最核心的价值：帮企业找到“什么问题值得用AI解决”，并且一直跟着这个问题走到真正落地。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 图像类型清单、标注样本集、识别错误集和人工复核规则
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：谢尧（无锡继达智成科技有限公司创始人）；PDF 第 200-209 页，书内页码 199-208。本文为访谈资料的第三人称整理，不是本站新采访。