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

这个案例的客户来自海外。坦白说，我们第一次去客户现场之前，并不知道最后要做什 么。虽然前面已经有过几轮沟通，但当时没有一个预设答案，客户到底需要大模型、 Agent，还是其他AI能力，谁都不确定。 所以我们没有带着现成产品进去，而是先做了一件看起来很“慢”的事情，访谈。前期 对整个客户的业务摸排持续了很长时间，我们跟不同部门沟通，理解组织架构、业务流 程，也观察不同业务人员对AI的态度。真正进入这个具体案例之后，我们又围绕ERP及 其上下游团队进行了持续数月的深入访谈。 这家企业属于工业场景，需要管理大量机械设备、物料和资产。小到一副手套、一颗螺 丝钉、一副耳塞，大到一辆卡车、一个机械臂，都需要进入ERP数据库。跟这套数据库 发生交互的团队大概有15个，有人负责录入，有人负责采购，有人负责合同，有人负责 仓储。 我们把这些团队一个个访谈下来，发现一个非常有意思的现象，几乎所有部门都在抱怨 同一件事情，ERP不好用。但“ERP不好用”还不能算一个可以直接交给工程师解决的问 题。于是我们继续追问，到底哪里不好用，平时是怎么操作的，问题发生在哪一步。 有时候我会直接坐在业务人员旁边，看他实际怎么工作。因为很多问题，如果只在会议 室里问，是问不出来的。访谈结束之后，我们自己还会继续研究和拆解，去做根因诊 断。 这个过程做下来，我们最后梳理出大约15个可以进一步处理的功能点，其中两个问题非 常典型。第一个是数据不干净。第二个是搜索能力非常弱。 客户使用的是一套比较老的工业软件。今天大家已经习惯了淘宝、京东、亚马逊这种搜 索体验，输入自己想找的东西，很自然就能得到结果。但在这套工业ERP里，搜索没有 这么顺畅。 业务人员经常遇到一种情况：“我明明知道这个部件数据库里有，我上次还用过，但现 在就是找不到。”这句话后来成为我们理解整个问题非常关键的入口。 因为“找不到”本身还不是最终的业务损失，真正的问题发生在后面。当一个员工找不 到某个物料时，他可能会认为数据库里没有，于是重新录入一条数据，可这个物料本来 就存在。于是形成一个循环：找不到物料 → 重新录入 → 出现重复数据 → 数据越来越脏 → 更难找到正确物料 → 买错、买重或者搞错单位。 到工业采购环节，这就牵扯到真金白银了。消费者买错东西，可以退款。工业采购却常 常做不到这一点，东西买错了，往往不会退回去，只能再买一个正确的。错误采购的东 西就留在仓库里，一放可能就是几年。 仓库不可能无限存储。几年之后清理库存时，发现这些东西长期没人使用，最后只能按 照规则处理掉。企业真正损失的钱，就藏在这里。 所以我们后来把真正要解决的问题，定义为能不能通过改善数据质量和物料查找能力， 减少那些原本不应该发生的错误采购和重复采购。 这个问题一旦定义清楚，AI的价值也从“让系统更智能”，落到了一个真正能够影响企业 经营结果的问题上。

客户的这套ERP已经承载了企业长期的库存管理流程，各个团队围绕它形成了自己的工 作方式。录入、采购、合同、仓储，各个环节都有明确的职责，企业也一直靠这套流程 运转。 问题在于，随着数据不断积累，原有系统本身的限制越来越明显。尤其是工业物料的数 据非常复杂。同一个东西可能存在不同名称、不同描述方式、不同单位或者不同录入习 惯。如果系统的搜索又主要依赖传统字段和关键词，业务人员就很难快速确认，数据库 里到底有没有自己想要的物料。 以前碰到这种情况，业务人员依靠的是经验。知道编码，可以按编码找；知道准确名 称，可以按名称找；实在找不到，就按照原来的流程重新录入。 在数据规模还没有那么大、业务链路还没有那么复杂的时候，这套方式能够工作。但随 着历史数据越积越多，靠经验兜底越来越吃力，同样的流程开始失效。 所以这笔账，不能算在一线员工头上，先顶不住的是那套搜索系统。企业其实早就把流 程装进了ERP，数字化这一步早就迈出去了。真正卡住的是，这套系统的关键词检索和 字段匹配，处理不了工业物料那么多名称、描述和单位，于是数字化的工具本身成了新 的瓶颈。 这时候如果只是继续要求员工录入得更规范一点、搜索得更仔细一点，很难从根本上解 决问题。于是我们判断，AI应该在这里介入。

如果只看最后做出来的功能，这个案例其实一点都不“性感”。无非就是两件事，把已 有数据清洗、标准化，再增加语义检索能力。甚至有人会说，这不就是RAG或者智能搜 索吗。 我觉得这么说技术上没有问题，但如果只看到这里，就把这个案例最重要的部分漏掉 了。因为真正困难的事情，从来都在“为什么要做语义检索，以及做完以后究竟改变了 什么业务结果”上。我们整个过程大概经历了几个阶段。 第一步，进入现场，先做问题发现。 我们花了数月时间和业务部门沟通，重点看他们真实的工作过程，也听他们说自己希望 AI帮什么。因为业务人员会告诉你很多需求，但FDE不能直接把需求列表变成功能列 表。我们需要继续判断，这个问题是否真的存在，根因在哪里，AI能不能解决，解决之 后能产生多少业务价值。 在这个过程中，我们才逐渐把“ERP不好用”拆解成一个个具体问题，并进一步找到数据 质量和搜索这两个值得优先处理的问题。 第二步，把问题放回完整业务链条里。 这是我认为FDE和单纯做AI功能非常不一样的地方。我们没有停在“搜索不好，所以做一 个更好的搜索”这一步，继续往下追，搜索不好到底为什么会产生业务损失。最后才得 到这条链路，搜索困难 → 重复录入 → 数据污染 → 错误/重复采购 → 库存积压 → 最终 报废 → 产生真实财务损失。只有这条链路成立，我们才知道这个AI应用到底值多少钱。 第三步，和所有利益相关方一起确定优先级。 这个案例涉及十几个部门，不可能FDE自己拍脑袋决定先做什么。我们把诊断出来的功 能点整理成列表，再把不同业务部门的负责人和代表召集起来，一项项确认每个功能到 底解决什么问题、是不是业务真正需要的、应该先做哪个后做哪个，还会让业务部门参 与投票。 与此同时，FDE内部也会从七八个维度去评估每个用例，比如数据能不能拿到、数据处 理后能不能重新写回业务系统、AI到底能不能解决、技术难度怎么样，以及最终业务人 员是否愿意采用。 因为一个功能技术上做出来，不代表它真的能落地。有时候数据根本不存在；有时候老 系统不允许你把处理结果写回去；有时候技术能实现，但业务部门不愿意自己的系统被 碰；还有时候业务人员根本不相信AI输出的结果。这些问题，都要在真正开始构建之前 尽可能摸清楚。 第四步，把技术分工定清楚，让AI只做该做的部分。 我们没有把所有事情都塞给大模型。语义检索负责理解业务人员那句“我要找的东西” 背后的语义，把同一个物料的不同叫法对上号；数据清洗和标准化则负责在检索之前先 把历史数据里的重复和不一致处理掉，让语义检索有干净的底子。最终是不是采购、采 购多少，仍然由业务人员拍板。 第五步，从能快速证明价值的场景开始，允许中途反复。 我不建议一上来就挑最难、最酷的东西做。因为如果一个项目做了几个月还没有结果， 客户的耐心和信心都会快速下降。我们更愿意先找容易见效的场景，最好几个星期，甚 至两周左右，就能够让业务部门看到一个初步结果。 一旦业务人员看到“这个东西真的有效”，信心就建立起来了，后面才会更愿意主动参 加后续的行动。而且这条路不会一直笔直。 过程中经常会反复。有时候做到一半发现问题定义不对，我们会重新回到问题发现这一 步；有时候发现范围铺得太大，就重新缩回来。FDE真正做的，是持续验证“问题、方 案、业务价值”三者之间的关系，让每一步都建立在前一步的验证结果上。 最终，我们让业务人员更容易找到已经存在的物料。这样做的目的，是从源头减少重复 录入，进一步减少错误采购和重复采购，搜索只是手段。

我们衡量效果的方法其实非常明确。最终看的是客户是不是少买错东西了，是不是少重 复购买了。模型准确率、员工觉得搜索速度快了多少，都只是过程指标，真正的业务结 果是采购行为有没有改变。 在做这个项目之前，客户其实知道错误采购和库存浪费存在，但这个问题在客户那里并 不显性。没有人真正把历史数据库里的记录找出来，仔细分析这些错误到底每年造成多 少损失。所以我们工作的一部分，是把过去不可见的问题变成可以计算的问题。 我们会从历史数据中建立基线，再通过小规模实验逐步扩大范围。每个阶段都去验证几 个问题，AI有没有减少重复数据，数据库的清洁程度有没有提高，原来因为数据问题造 成的错误采购有没有下降，最终对应的采购浪费有没有被避免。 更重要的是，这个价值不能由我们自己宣布。我们最后需要通过严格的计算方式得出结 果，而且计算出来的业务价值还需要客户自己的业务人员确认。只有客户说出那句 “对，这笔钱确实是因为这个应用被节省下来了”，我们才认为价值真正成立。 所以相比过去，这个案例最大的变化，是把原来“大家都知道有问题，但没人知道问题 值多少钱”的状态，变成了一个可以被发现、被干预、被持续衡量的经营问题。这正是 我理解的AI落地和AI演示之间最大的区别。

这个项目真正困难的地方，其实大部分都不在模型本身。 第一个挑战，找到真正的问题需要很长时间。 我们花数月去理解一个看起来和AI没有太大关系的ERP业务流程。对很多工程师来说， 这可能是最难接受的部分，大家更习惯客户给需求、自己写代码。但FDE不一样，很多 时候客户自己都不知道真正值得AI解决的问题在哪里。你必须坐下来理解采购怎么做、 仓储怎么做、数据怎么录、不同部门之间怎么协作，不做这些“脏活累活”，后面的AI很 可能只是在错误的问题上做得更漂亮。 诊断要深，客户对价值的期待又来得快。如果前面已经花了很长时间做业务梳理，进入 实施以后再连续几个月看不到结果，组织很容易失去耐心。所以我们会刻意从容易证明 价值的场景开始，先让业务部门看到有效，再逐步扩大。 第二个挑战，跨部门协调难。 这个案例涉及十几个团队，每个团队职责不同，诉求也不同。有些AI应用甚至会改变部 门之间原来的工作流程，因此天然可能产生冲突，而且很多冲突不会在会议上直接说出 来。所以我们会做多轮讨论，不仅开大会，还会提前和不同利益相关方单独沟通，把这 些没说出口的顾虑提前化解。 第三个挑战，技术能做，落地却难。 比如数据能不能拿出来，老ERP能不能让我们把处理后的数据写回去，业务部门是否允 许我们触碰现有系统，最终用户愿不愿意相信AI结果。这些问题任何一个解决不了，用 例都有可能失败。所以我们在正式构建之前，就会从多个维度给不同场景打分，AI能不 能实现只是其中一项。 上线之后，事情同样没有结束。项目最终要移交给业务部门，由他们决定是否真正采 纳。上线以后还要继续看，运行一段时间之后效果还在不在，和项目启动时定义的目标 相比有没有变化，如果效果下降，原因是什么，是不是还需要继续优化。 FDE不能是“东西做完、钱到账、人撤走”。如果业务部门最终不用，或者三个月之后效 果消失了，那这个应用就不能算真正落地。整个交付因此会反复回到问题诊断、范围选 择和验证环节，很难一条直线走到底。

做完这个案例以后，我更加确信，FDE最重要的能力，在于找到真正值得解决的问题， 快速做一个AI应用反而排在后面。我会总结成几个原则。 第一，不要拿着AI去找问题，要先进入业务现场找问题。 很多人做AI应用的方式，是手里有一个Agent、有一个RAG、有一个工作流产品，然后 去问客户，你这里有没有什么场景能用。这很容易变成拿着锤子找钉子。我们更希望反 过来。 先长期跟客户接触，理解业务，做问题发现，再判断这个问题应该用生成式AI、传统机 器学习，还是根本不应该用AI。AI技术只是手段。 第二，不要停留在用户提出的表面需求，要一直追到根因。 业务人员说“ERP不好用”，这不是一个问题定义。他说“搜索不好用”，也还不是。继 续追下去，你才会发现，“搜索不好用”一路追到底，最后落到了真实的财务损失上。 FDE需要一直追问，为什么，然后呢，这件事最终影响了什么，直到找到能够和业务结 果连接起来的根因。 第三，优先选择能证明价值的用例。 一个AI场景值不值得做，我会同时考虑数据获取难度、系统集成难度、AI可行性、业务 复杂度、用户接受程度和潜在价值，最酷的往往先放一放。一开始尤其应该选择能够快 速产生结果的场景，因为早期的结果不仅是技术验证，也是建立组织信心的过程。 第四，把ROI定义放在项目开始。 很多AI项目上线之后才开始问，这个东西到底创造了多少价值，这时候往往已经晚了。 我们会在一开始就问清楚，如果这个问题解决了，企业一年能减少多少损失，这个数字 怎么算，数据从哪里来，最后谁来确认。这样到项目结束的时候，我们拿客户认可的业 务结果证明自己，模型指标只是过程参考。 第五，先标准化的应该是方法，产品可以先放一放。 我并不反对标准化产品，但现阶段AI技术变化太快。如果一开始就想着把某个功能沉淀 成一个标准产品，再拿着它去找下一批客户，很容易又回到老路上。 相比之下，我更看重可以复用的方法论。怎么做问题发现，怎么做根因分析，怎么判断 用例，怎么定义ROI，怎么做小规模实验，怎么和业务部门一起验证，怎么持续衡量。 这些东西，比某一个具体的AI功能更值得沉淀。因为下一个客户的ERP可能完全不同， 业务流程也可能完全不同，但解决问题的思维方式是可以复用的。 所以如果让我用一句话总结这个案例，我会说，FDE真正的工作，是先深入业务，把一 个模糊的抱怨还原成一个可以解决、可以验证、可以计算价值的问题，再决定AI应该出 现在哪里。 这个案例最后落地的是数据清洗和语义检索，但真正创造价值的，在于我们花了足够长 的时间，把“一个物料为什么找不到”一直追到了“企业为什么会因此浪费采购预算”。 当这条链路被找到之后，AI才真正从一个技术能力，变成了业务价值。