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

我做的这个案例，最开始先跟老板聊他到底想解决什么问题。 这是一家汽车供应链企业，主要向下游销售汽车维修零部件。它的生产形态偏轻，主要 从上游采购零部件，再做一些简单加工、组合和组装，最后形成产品交付给客户，跟传 统意义上那种重生产线的制造企业很不一样。 表面上看，这家企业其实已经有ERP系统，订单、生产任务、采购、库存、发货等数据 都有。问题是，这些数据虽然存在，但并没有真正形成老板需要的“经营视角”。 老板真正关心的是：客户下了一个订单之后，企业内部到底怎么往下走？生产任务有没 有正常推进？采购有没有多订？库存到底有多少？什么时候能发货？财务现在要付给供 应商的钱，到底对应哪些客户订单？ 老板每天有大量事情要处理，不可能自己逐条核对，所以很多时候只能问下面的人。 图1：订单全链路异常提前呈现 我先站在老板经营的角度，找到真正 这也是我理解FDE和普通软件外包最重要的区别： 影响经营的问题，再据此开始开发。 比如这个企业老板，他真正想要的，是企业能够尽量自动化地运行。他希望自己不用每 天盯着工厂，也能知道现在有多少订单进来了、多少正在生产、多少已经收货、多少已 经发货、多少已经回款；如果中间出现异常，再主动告诉他。 让订单流转变得透明，让不同业务数 所以最后我们把问题收敛成了几个很具体的事情： 据能够对应起来，让异常能够被发现，让老板不用再依赖人工询问。

过去他们其实有自己的解决办法。 企业使用的是管家婆这样的标准化ERP，里面已经能够看到客户订单、生产任务单、供 应商采购订单、库存以及发货等信息。对于标准化的企业管理来说，这套系统本身是能 够工作的。 所以我不会说原来的方式“不好”。 问题在于，ERP解决的是一个标准化的信息管理问题，而老板需要的是一个更加贴近企 业经营的判断视角。SaaS产品为了保持标准化和商业ROI，本身不会针对每一家企业的 经营方式做大量深度定制。 数据都有，但老板还是看不清。 于是就出现了一个很典型的情况： 举个很简单的例子。 供应商给企业发来5000个扳手，但实际只发了4980个，少了20个。按照原来的ERP逻 辑，因为数量没有完全达到5000个，这笔订单可能就无法正常入库。 但现实业务不会因为少了20个，就把4980个扳手退回去。仓库里实际上已经多了4980 个，只是系统的标准逻辑没有办法很好地表达这种“实际发生了，但标准流程没有完整 结束”的情况。 这类问题如果靠人工处理，就意味着员工需要额外记录、解释和沟通；如果老板想知道 真实情况，又得再去问人。

我当时做的第一件事，是先把老板的经营诉求拆出来，没有急着写代码。 因为如果直接问老板“你想要什么AI功能”，最后很容易得到一堆功能需求。但如果问的 是“你每天最担心企业发生什么”“哪些事情你必须亲自盯”“哪些异常一旦发生你希望 第一时间知道”，得到的东西就完全不一样。 这个项目最后形成了一个比较清晰的思路： 第一步，先明确老板要看什么。 老板真正要看的，是企业现在经营到什么状态。所以我们围绕订单、生产、采购、库 存、发货、回款这些关键环节，把老板真正关心的信息梳理出来。 第二步，保留原来的ERP，把必要的数据拿出来重新组织。 我没有去重新开发一套ERP。原有系统继续承担原来的业务功能，我们在它的数据基础 上做二次加工。因为真正的问题在于，“系统里的数据没有按照老板的经营逻辑串起 来”。 第三步，让AI去做过去大量依靠人工完成的数据匹配和核对。 比如财务要支付供应商10万元，过去要回答“为什么要付这10万元”，可能需要人工去 对应供应商订单、客户订单、库存签收等信息。 这时候AI发挥作用的地方，在于做数据之间的匹配、核对和关联。 也就是说，我更愿意把这里的AI理解成一个“数据关系处理器”：它帮助系统判断不同业 务环节之间到底是什么关系，有没有对得上。 第四步，把异常从“人去发现”变成“系统主动提醒”。 企业正常运行的时候，我希望它自己往下走；只有出现问题的时候，才需要人介入。 所以我们给一些关键业务节点设置判断标准，例如价格是否合理、库存数据是否异常、 应付款能不能和相关业务数据对应起来。一旦出现异常，就通过飞书卡片提醒相关人 员。 正常情况自动运行 → 数据持续匹配核对 → 发现异 这实际上形成了一个很简单的闭环： 常 → 主动提醒 → 人处理异常。 对我来说，这比单纯做一个“AI助手”更有价值，因为它真正嵌进了原来的业务流程。 图2：只读同步、异常识别与老板看板

现在还不能证明企业的利 这个项目目前上线时间还比较短，所以我会比较谨慎地说： 润、成本或者其他经营指标已经发生了明确的量化提升。 但有一些变化是已经能够直接感知到的。 以前ERP里存在一些“有数据但看不清”的情况，现在已经可以把它重新呈现出来。 还是刚才那个4980个扳手的例子。原来的ERP可能因为没有达到5000个的标准数量，所 以没有办法很好地反映真实库存；现在我们可以告诉老板，实际库存里已经增加了4980 个。 系统开始更接近真实业务 这看起来只是一个很小的变化，但对于老板来说，区别在于： 了。 另外一个比较明显的变化，是财务应付款的可追溯性。 还是前面财务应付款那个例子。以前老板看到“今天要付给某个供应商多少钱”，可能 只能看到一个结果；现在可以进一步追溯，这笔钱对应了哪些客户订单、哪些上游采 购，以及为什么形成这笔应付款。 所以目前这个项目更像是完成了从“有没有这个功能”到“经营信息能不能被看清楚”的 第一步。 老板最初想要的三件事情里，“企业能够尽量自动运行”和“出现异常能够通知他”，目 前基础功能已经实现；至于减少重复订货等更进一步的经营效果，还需要继续运行一段 时间才能验证。 我觉得这一点也很重要。做FDE不能为了证明AI有效，就把刚上线的项目包装成已经产 业务价值需要时间验证，能明确解决什么、还不能证明什么，都应该 生巨大经营收益。 讲清楚。 图3：订单从任务单到回款的追踪链路

这个项目让我比较深地意识到，FDE真正难的地方，很多时候在AI技术之外。我自己总 结下来，至少有四个挑战。 第一个挑战，是老板的认知。 我原来是互联网大厂产品经理出身，和制造业老板看问题的方式并不一样。 所以第一步，我先理解他的经营逻辑，同时让他知道AI到底能做到什么、不能做到什 么。 如果这一步没有对齐，后面的方案很容易跑偏。 第二个挑战，是行业Know-how。 我现在接触的客户不只有制造业，还有医疗、贸易、物业、集采等，不同行业的业务规 律差别很大。 FDE不一定要成为这个行业最资深的专家，但至少要知道这个行业基本是怎么运转的。 否则你连客户真正的问题是什么都判断不了，更不用说设计方案。 行业理解，是FDE进入业务现场的门票。 所以我现在越来越觉得， 第三个挑战，是数据。 这也是这个制造业案例目前没有办法直接标准化复制的主要原因。 最开始我也想过，既然这套方案做出来了，是不是可以直接复制给其他制造业企业。 但真正做下去之后发现，即便是同一个行业、规模差不多的企业，底层的数据基础、数 据口径、业务流程都可能差很多。我们在这个项目上花了大量时间做数据清理、数据治 理和口径整理。 所以最后我反而没有急着把它包装成一个标准化产品。 方法论可以复用，但底层的数据和业务逻辑，未必能直接复制。 第四个挑战，是ROI。 这是我自己做FDE之后越来越在意的一件事情。 以前做大厂产品，我们会习惯把事情做到80分、90分。但到了真实企业场景里，你还得 问一句：做到80分到底划不划算？ 因为FDE的核心成本就是人的时间。如果一个项目需要投入大量人力做数据治理、长期 维护和定制开发，那么即使客户觉得项目很好，对FDE团队来说也不一定是一门好生 意。 所以我现在不会只看“这个需求能不能做”，还会看“这个需求值不值得做”“长期维护 的成本是什么”“这个项目的ROI是不是合理”。 这也是我后来开始主动寻找更加标准化场景的原因。

为了AI而做AI 我现在越来越觉得，企业做AI，最容易犯的错误就是 。 我以前所在的金融机构就发生过类似的事情。 当时业务部门觉得找设计师做营销图片很慢，希望用AI提高效率。从业务逻辑上看，这 个需求完全合理。但因为金融机构有数据合规要求，不能直接使用外部模型，最后只能 做本地部署。 结果就是花了不少钱搭了一套AI图片生成系统，但生成出来的图片实际不能用。最后IT 部门完成了“AI转型”，合规部门完成了数据安全要求，领导也可以说企业完成了AI转 型，但业务部门还是回去找设计师做图。 从企业经营的角度看，什么都没有改变。 所以如果让我总结现在做FDE的一些经验，我会特别强调几个事情。 AI转型最好从老板真正关心的经营问题出发。 首先， 老板要解决的是降本增效、安全、效率、经营透明度等问题。先把这些问题找出来，再 判断AI能不能介入。 业务部门必须有动力、有资源。 其次， IT当然要参与，但不能变成“IT部门为了完成AI转型而推动AI转型”。真正每天承受业务 问题的人，才最清楚什么地方值得改。 所以最好由老板主导，或者由真正承担业务指标的负责人推动，并且给业务团队足够的 资源和权限。 FDE要同时具备三种能力：懂业务、懂AI、能落地。 第三， 只懂技术，很容易变成技术外包；只懂咨询，又可能停留在方案层面；只懂业务，也很 难真正把AI落到系统里。 FDE真正有价值的地方，就是把“经营问题”一路往下拆成“业务流程”，再拆成“数据 和系统”，最后才落到具体的AI能力。 不要一开始就执着于做一个完美的标准化 最后还有一点，是我自己现在特别有感触的： 产品。 真实企业的业务往往很复杂，同样一个问题，在不同企业里可能有完全不同的数据基础 和处理方式。先进入真实场景，把一个问题真正解决掉，再从多个项目里找到共通的方 法，最后再判断哪些部分值得标准化。 从老板的经营问题出发，进入真实业务现 我理解的FDE，本质上就是这么一个过程： 场，找到AI真正能够创造价值的节点，再把技术变成业务流程的一部分。 AI降低了过去很多项目的开发和交付成本，让一些以前因为成本太高而被搁置的问题重 新变得可行。但企业真正的诉求并没有因为AI出现而改变。改变的是，我们现在有机会 用更低的成本、更高的效率，把过去那些长期存在的问题真正解决掉。 对我来说，这可能就是FDE最核心的价值：帮企业找到“什么问题值得用AI解决”，并且 一直跟着这个问题走到真正落地。