从物料难找到精准定位：FDE用AI减少工业企业采购浪费

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

原案例封面

为什么这个案例值得看？

一家海外工业客户用同一套 ERP 管理从手套、螺丝钉到卡车、机械臂的库存和资产，15 个相关团队都受到物料难找和数据质量问题影响。项目先对“系统不好用”做根因分析，再从数据清洗、标准化和小规模实验切入，把 AI 价值落到减少重复采购和库存浪费。

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

一、企业与业务场景

这个案例的客户来自海外。

坦白说，项目团队第一次去客户现场之前，并不知道最后要做什么。

虽然前面已经有过几轮沟通，但当时没有一个预设答案，客户到底需要大模型、Agent，还是其他AI能力，谁都不确定。

所以项目团队没有带着现成产品进去，而是先做了一件看起来很“慢”的事情，访谈。

前期对整个客户的业务摸排持续了很长时间，项目团队跟不同部门沟通，理解组织架构、业务流程，也观察不同业务人员对AI的态度。

真正进入这个具体案例之后，项目团队又围绕ERP及其上下游团队进行了持续数月的深入访谈。

这家企业属于工业场景，需要管理大量机械设备、物料和资产。

小到一副手套、一颗螺丝钉、一副耳塞，大到一辆卡车、一个机械臂，都需要进入ERP数据库。

跟这套数据库发生交互的团队大概有15个，有人负责录入，有人负责采购，有人负责合同，有人负责仓储。

项目团队把这些团队一个个访谈下来，发现一个非常有意思的现象，几乎所有部门都在抱怨同一件事情，ERP不好用。

但“ERP不好用”还不能算一个可以直接交给工程师解决的问题。

于是项目团队继续追问，到底哪里不好用，平时是怎么操作的，问题发生在哪一步。

有时候FDE可以直接坐在业务人员旁边，看他实际怎么工作。

因为很多问题，如果只在会议室里问，是问不出来的。

访谈结束之后，项目团队还会继续研究和拆解，去做根因诊断。

这个过程做下来，项目团队最后梳理出大约15个可以进一步处理的功能点，其中两个问题非常典型。

第一个是数据不干净。

第二个是搜索能力非常弱。

客户使用的是一套比较老的工业软件。

今天大家已经习惯了淘宝、京东、亚马逊这种搜索体验，输入自己想找的东西，很自然就能得到结果。

但在这套工业ERP里，搜索没有这么顺畅。

业务人员经常遇到一种情况：“业务人员明明知道这个部件数据库里有，业务人员上次还用过，但现在就是找不到。”这句话后来成为项目团队理解整个问题非常关键的入口。

因为“找不到”本身还不是最终的业务损失，真正的问题发生在后面。

当一个员工找不到某个物料时，他可能会认为数据库里没有，于是重新录入一条数据，可这个物料本来就存在。

于是形成一个循环：找不到物料 → 重新录入 → 出现重复数据 → 数据越来越脏→ 更难找到正确物料 → 买错、买重或者搞错单位。

到工业采购环节，这就牵扯到真金白银了。

消费者买错东西，可以退款。

工业采购却常常做不到这一点，东西买错了，往往不会退回去，只能再买一个正确的。

错误采购的东西就留在仓库里，一放可能就是几年。

仓库不可能无限存储。

几年之后清理库存时，发现这些东西长期没人使用，最后只能按照规则处理掉。

企业真正损失的钱，就藏在这里。

所以项目团队后来把真正要解决的问题，定义为能不能通过改善数据质量和物料查找能力，减少那些原本不应该发生的错误采购和重复采购。

这个问题一旦定义清楚，AI的价值也从“让系统更智能”，落到了一个真正能够影响企业经营结果的问题上。

二、原有流程与核心问题

客户的这套ERP已经承载了企业长期的库存管理流程，各个团队围绕它形成了自己的工作方式。

录入、采购、合同、仓储，各个环节都有明确的职责，企业也一直靠这套流程运转。

问题在于，随着数据不断积累，原有系统本身的限制越来越明显。

尤其是工业物料的数据非常复杂。

同一个东西可能存在不同名称、不同描述方式、不同单位或者不同录入习惯。

如果系统的搜索又主要依赖传统字段和关键词，业务人员就很难快速确认，数据库里到底有没有自己想要的物料。

以前碰到这种情况，业务人员依靠的是经验。

知道编码，可以按编码找；知道准确名称，可以按名称找；实在找不到，就按照原来的流程重新录入。

在数据规模还没有那么大、业务链路还没有那么复杂的时候，这套方式能够工作。

但随着历史数据越积越多，靠经验兜底越来越吃力，同样的流程开始失效。

所以这笔账，不能算在一线员工头上，先顶不住的是那套搜索系统。

企业其实早就把流程装进了ERP，数字化这一步早就迈出去了。

真正卡住的是，这套系统的关键词检索和字段匹配，处理不了工业物料那么多名称、描述和单位，于是数字化的工具本身成了新的瓶颈。

这时候如果只是继续要求员工录入得更规范一点、搜索得更仔细一点，很难从根本上解决问题。

于是项目团队判断，AI应该在这里介入。

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

如果只看最后做出来的功能，这个案例其实一点都不“性感”。

无非就是两件事，把已有数据清洗、标准化，再增加语义检索能力。

甚至有人会说，这不就是RAG或者智能搜索吗。

项目实践表明这么说技术上没有问题，但如果只看到这里，就把这个案例最重要的部分漏掉了。

因为真正困难的事情，从来都在“为什么要做语义检索，以及做完以后究竟改变了什么业务结果”上。

项目团队整个过程大概经历了几个阶段。

第一步，进入现场，先做问题发现。

项目团队花了数月时间和业务部门沟通，重点看他们真实的工作过程，也听他们说自己希望AI帮什么。

因为业务人员会说明很多需求，但FDE不能直接把需求列表变成功能列表。

项目团队需要继续判断，这个问题是否真的存在，根因在哪里，AI能不能解决，解决之后能产生多少业务价值。

在这个过程中，项目团队才逐渐把“ERP不好用”拆解成一个个具体问题，并进一步找到数据质量和搜索这两个值得优先处理的问题。

第二步，把问题放回完整业务链条里。

这是项目经验表明FDE和单纯做AI功能非常不一样的地方。

项目团队没有停在“搜索不好，所以做一个更好的搜索”这一步，继续往下追，搜索不好到底为什么会产生业务损失。

最后才得到这条链路，搜索困难 → 重复录入 → 数据污染 → 错误/重复采购 → 库存积压 → 最终报废 → 产生真实财务损失。

只有这条链路成立，项目团队才知道这个AI应用到底值多少钱。

第三步，和所有利益相关方一起确定优先级。

这个案例涉及十几个部门，不可能FDE团队拍脑袋决定先做什么。

项目团队把诊断出来的功能点整理成列表，再把不同业务部门的负责人和代表召集起来，一项项确认每个功能到底解决什么问题、是不是业务真正需要的、应该先做哪个后做哪个，还会让业务部门参与投票。

与此同时，FDE内部也会从七八个维度去评估每个用例，比如数据能不能拿到、数据处理后能不能重新写回业务系统、AI到底能不能解决、技术难度怎么样，以及最终业务人员是否愿意采用。

因为一个功能技术上做出来，不代表它真的能落地。

有时候数据根本不存在；有时候老系统不允许项目团队把处理结果写回去；有时候技术能实现，但业务部门不愿意自己的系统被碰；还有时候业务人员根本不相信AI输出的结果。

这些问题，都要在真正开始构建之前尽可能摸清楚。

第四步，把技术分工定清楚，让AI只做该做的部分。

项目团队没有把所有事情都塞给大模型。

语义检索负责理解业务人员那句“业务人员要找的东西”背后的语义，把同一个物料的不同叫法对上号；数据清洗和标准化则负责在检索之前先把历史数据里的重复和不一致处理掉，让语义检索有干净的底子。

最终是不是采购、采购多少，仍然由业务人员拍板。

第五步，从能快速证明价值的场景开始，允许中途反复。

FDE不建议一上来就挑最难、最酷的东西做。

因为如果一个项目做了几个月还没有结果，客户的耐心和信心都会快速下降。

项目团队更愿意先找容易见效的场景，最好几个星期，甚至两周左右，就能够让业务部门看到一个初步结果。

一旦业务人员看到“这个东西真的有效”，信心就建立起来了，后面才会更愿意主动参加后续的行动。

而且这条路不会一直笔直。

过程中经常会反复。

有时候做到一半发现问题定义不对，项目团队会重新回到问题发现这一步；有时候发现范围铺得太大，就重新缩回来。

FDE真正做的，是持续验证“问题、方案、业务价值”三者之间的关系，让每一步都建立在前一步的验证结果上。

最终，项目团队让业务人员更容易找到已经存在的物料。

这样做的目的，是从源头减少重复录入，进一步减少错误采购和重复采购，搜索只是手段。

四、项目结果与业务价值

项目团队衡量效果的方法其实非常明确。

最终看的是客户是不是少买错东西了，是不是少重复购买了。

模型准确率、员工觉得搜索速度快了多少，都只是过程指标，真正的业务结果是采购行为有没有改变。

在做这个项目之前，客户其实知道错误采购和库存浪费存在，但这个问题在客户那里并不显性。

没有人真正把历史数据库里的记录找出来，仔细分析这些错误到底每年造成多少损失。

所以项目团队工作的一部分，是把过去不可见的问题变成可以计算的问题。

项目团队会从历史数据中建立基线，再通过小规模实验逐步扩大范围。

每个阶段都去验证几个问题，AI有没有减少重复数据，数据库的清洁程度有没有提高，原来因为数据问题造成的错误采购有没有下降，最终对应的采购浪费有没有被避免。

更重要的是，这个价值不能由项目团队宣布。

项目团队最后需要通过严格的计算方式得出结果，而且计算出来的业务价值还需要客户自己的业务人员确认。

只有客户说出那句“对，这笔钱确实是因为这个应用被节省下来了”，项目团队才认为价值真正成立。

所以相比过去，这个案例最大的变化，是把原来“大家都知道有问题，但没人知道问题值多少钱”的状态，变成了一个可以被发现、被干预、被持续衡量的经营问题。

这正是这一案例体现的AI落地和AI演示之间最大的区别。

五、关键落地难点

这个项目真正困难的地方，其实大部分都不在模型本身。

第一个挑战，找到真正的问题需要很长时间。

项目团队花数月去理解一个看起来和AI没有太大关系的ERP业务流程。

对很多工程师来说，这可能是最难接受的部分，大家更习惯客户给需求、自己写代码。

但FDE不一样，很多时候客户自己都不知道真正值得AI解决的问题在哪里。

FDE必须坐下来理解采购怎么做、仓储怎么做、数据怎么录、不同部门之间怎么协作，不做这些“脏活累活”，后面的AI很可能只是在错误的问题上做得更漂亮。

诊断要深，客户对价值的期待又来得快。

如果前面已经花了很长时间做业务梳理，进入实施以后再连续几个月看不到结果，组织很容易失去耐心。

所以项目团队会刻意从容易证明价值的场景开始，先让业务部门看到有效，再逐步扩大。

第二个挑战，跨部门协调难。

这个案例涉及十几个团队，每个团队职责不同，诉求也不同。

有些AI应用甚至会改变部门之间原来的工作流程，因此天然可能产生冲突，而且很多冲突不会在会议上直接说出来。

所以项目团队会做多轮讨论，不仅开大会，还会提前和不同利益相关方单独沟通，把这些没说出口的顾虑提前化解。

第三个挑战，技术能做，落地却难。

比如数据能不能拿出来，老ERP能不能让项目团队把处理后的数据写回去，业务部门是否允许项目团队触碰现有系统，最终用户愿不愿意相信AI结果。

这些问题任何一个解决不了，用例都有可能失败。

所以项目团队在正式构建之前，就会从多个维度给不同场景打分，AI能不能实现只是其中一项。

上线之后，事情同样没有结束。

项目最终要移交给业务部门，由他们决定是否真正采纳。

上线以后还要继续看，运行一段时间之后效果还在不在，和项目启动时定义的目标相比有没有变化，如果效果下降，原因是什么，是不是还需要继续优化。

FDE不能是“东西做完、钱到账、人撤走”。

如果业务部门最终不用，或者三个月之后效果消失了，那这个应用就不能算真正落地。

整个交付因此会反复回到问题诊断、范围选择和验证环节，很难一条直线走到底。

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

这个案例进一步验证了：FDE最重要的能力，在于找到真正值得解决的问题，快速做一个AI应用反而排在后面。

可归纳为几个原则。

第一，不要拿着AI去找问题，要先进入业务现场找问题。

很多人做AI应用的方式，是手里有一个Agent、有一个RAG、有一个工作流产品，然后去问客户，项目团队这里有没有什么场景能用。

这很容易变成拿着锤子找钉子。

项目团队更希望反过来。

先长期跟客户接触，理解业务，做问题发现，再判断这个问题应该用生成式AI、传统机器学习，还是根本不应该用AI。

AI技术只是手段。

第二，不要停留在用户提出的表面需求，要一直追到根因。

业务人员说“ERP不好用”，这不是一个问题定义。

他说“搜索不好用”，也还不是。

继续追下去，进一步追踪后可以看到，“搜索不好用”一路追到底，最后落到了真实的财务损失上。

FDE需要一直追问，为什么，然后呢，这件事最终影响了什么，直到找到能够和业务结果连接起来的根因。

第三，优先选择能证明价值的用例。

一个AI场景值不值得做，FDE可以同时考虑数据获取难度、系统集成难度、AI可行性、业务复杂度、用户接受程度和潜在价值，最酷的往往先放一放。

一开始尤其应该选择能够快速产生结果的场景，因为早期的结果不仅是技术验证，也是建立组织信心的过程。

第四，把ROI定义放在项目开始。

很多AI项目上线之后才开始问，这个东西到底创造了多少价值，这时候往往已经晚了。

项目团队会在一开始就问清楚，如果这个问题解决了，企业一年能减少多少损失，这个数字怎么算，数据从哪里来，最后谁来确认。

这样到项目结束的时候，项目团队拿客户认可的业务结果证明自己，模型指标只是过程参考。

第五，先标准化的应该是方法，产品可以先放一放。

FDE并不反对标准化产品，但现阶段AI技术变化太快。

如果一开始就想着把某个功能沉淀成一个标准产品，再拿着它去找下一批客户，很容易又回到老路上。

相比之下，项目更强调可以复用的方法论。

怎么做问题发现，怎么做根因分析，怎么判断用例，怎么定义ROI，怎么做小规模实验，怎么和业务部门一起验证，怎么持续衡量。

这些东西，比某一个具体的AI功能更值得沉淀。

因为下一个客户的ERP可能完全不同，业务流程也可能完全不同，但解决问题的思维方式是可以复用的。

所以这个案例可以概括为：可以概括为：FDE真正的工作，是先深入业务，把一个模糊的抱怨还原成一个可以解决、可以验证、可以计算价值的问题，再决定AI应该出现在哪里。

这个案例最后落地的是数据清洗和语义检索，但真正创造价值的，在于项目团队花了足够长的时间，把“一个物料为什么找不到”一直追到了“企业为什么会因此浪费采购预算”。

当这条链路被找到之后，AI才真正从一个技术能力，变成了业务价值。

七、可复用的交付资产

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

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：马诺（某AI创业公司FDE）；PDF 第 78-87 页，书内页码 77-86。本文为访谈资料的第三人称整理，不是本站新采访。