案例 08 · 工业物料与采购
Datawhale原书章节 · 印刷页码 76—85 · 当前仅加载一页

原书第 80 页 · 点击页面可放大查看
查看与复制本页文字
文字由原PDF提取,阅读顺序和表格请以原页为准。
在这个过程中,我们才逐渐把“ERP不好用”拆解成一个个具体问题,并进一步找到数据 质量和搜索这两个值得优先处理的问题。 第二步,把问题放回完整业务链条里。 这是我认为FDE和单纯做AI功能非常不一样的地方。我们没有停在“搜索不好,所以做一 个更好的搜索”这一步,继续往下追,搜索不好到底为什么会产生业务损失。最后才得 到这条链路,搜索困难 → 重复录入 → 数据污染 → 错误/重复采购 → 库存积压 → 最终 报废 → 产生真实财务损失。只有这条链路成立,我们才知道这个AI应用到底值多少钱。 第三步,和所有利益相关方一起确定优先级。 这个案例涉及十几个部门,不可能FDE自己拍脑袋决定先做什么。我们把诊断出来的功 能点整理成列表,再把不同业务部门的负责人和代表召集起来,一项项确认每个功能到 底解决什么问题、是不是业务真正需要的、应该先做哪个后做哪个,还会让业务部门参 与投票。 与此同时,FDE内部也会从七八个维度去评估每个用例,比如数据能不能拿到、数据处 理后能不能重新写回业务系统、AI到底能不能解决、技术难度怎么样,以及最终业务人 员是否愿意采用。 因为一个功能技术上做出来,不代表它真的能落地。有时候数据根本不存在;有时候老 系统不允许你把处理结果写回去;有时候技术能实现,但业务部门不愿意自己的系统被 碰;还有时候业务人员根本不相信AI输出的结果。这些问题,都要在真正开始构建之前 尽可能摸清楚。 第四步,把技术分工定清楚,让AI只做该做的部分。 我们没有把所有事情都塞给大模型。语义检索负责理解业务人员那句“我要找的东西” 背后的语义,把同一个物料的不同叫法对上号;数据清洗和标准化则负责在检索之前先 把历史数据里的重复和不一致处理掉,让语义检索有干净的底子。最终是不是采购、采 购多少,仍然由业务人员拍板。 80/243