工厂如何做FDE?从Excel台账到AI生产闭环
FDE不是一套买回去就能运行的软件,而是一种进入现场、围绕真实问题持续落地的工程方法。
最近,我们走访了河北正定、宁晋和湖北蕲春等地的多家制造企业。
这些企业分属不同产业,有电缆、机械设备、充气制品、童车和医药等,但谈到AI时,却出现了两个很相似的情况。
一是在对外营销上,不少工厂仍然主要靠业务员跑客户、参加展会或等待贸易公司下单,网站、搜索、社媒和客户数据没有形成持续运营。业务员一个人出去跑,像拿着一根鱼竿钓鱼;网络营销如果真正建立起来,则更像撒下一张网,可以同时连接不同地区、不同国家的潜在客户。
二是在工厂内部,订单、报价、采购、库存、排产、质检和交付仍然散落在Excel、微信群和各种文档里。每个部门都在忙,但同一份数据要反复录入,订单进展还要不断问人,老板看到的报表往往已经滞后。
这正是工厂做FDE最值得解决的问题:不是再增加一个“AI聊天窗口”,而是让FDE工程师进入现场,把一个真实流程从头到尾理顺,再让数据、规则、AI和员工协同起来。
![]()
FDE是什么?工厂为什么需要FDE工程师
FDE的英文是Forward Deployed Engineer,国内常译作“前线部署工程师”或“前沿部署工程师”。本文统一称为前线部署工程师。
严格来说,FDE首先是一类岗位和工作方式,不是一套可以买回去直接安装的软件,也不是“工厂数字员工”的另一种叫法。行业里常说的“工厂做FDE”,通常是让FDE工程师或FDE团队进入现场,对一个真实业务场景从需求梳理一直负责到上线使用。
FDE工程师既要理解业务,也要有技术落地能力。他需要跟着一张订单走完整个流程:客户需求从哪里来,谁负责报价,订单由谁确认,物料是否齐全,怎样排产,质量问题如何记录,什么时候入库,最终怎样交付。
OpenAI公开的FDE岗位职责包括需求发现、技术范围界定、系统设计、生产环境上线、用户采用和业务结果验证。也就是说,FDE不能做完一次演示就算结束,而要对“这套东西有没有进入实际工作”负责。
放到工厂里,FDE的价值就是把老板的目标、车间的流程、员工的经验、现有的软件和AI能力连接起来。
FDE也能用于营销、销售和客户服务等业务流程。本文重点讨论更难标准化、也更需要进入现场的生产管理环节,再用一个对外营销案例说明这种方法如何延伸。
Excel不是问题,断裂的数据链才是问题
很多人一谈工厂数字化,就先批评企业还在使用Excel。
这种判断并不准确。Excel简单、灵活,很多一线员工都会用,它完全可以继续作为部分数据的录入和分析工具。真正的问题,不是表格本身,而是数据链断了。
常见的情况是:销售有一张订单表,采购有一张原料表,仓库有一张库存表,生产有一张排产表,财务还有自己的应收应付表。产品名称、客户名称和订单编号的写法不统一,同一条信息要复制多次,不同版本之间也无法确认哪个才是最新的。
在这种基础上,即使接入再强的AI,也只能得到不完整或相互冲突的结果。
所以工厂做FDE,第一步不是买模型,也不是先做一个大平台,而是完成一个最基本的闭环:
收集真实数据,统一关键口径,连接业务流程,由AI分析并提出建议,关键动作由人审批,执行结果再回写系统。
只有结果能够回到下一次决策里,AI才不是一次性的问答工具,而是生产经营系统的一部分。
这里还要避免一个误区:工厂的所有问题并不都应该交给大语言模型。
订单、合同和质检记录等非结构化内容,可以用大模型提取和整理;固定的审批与数据搬运,更适合流程自动化;排产通常需要业务规则与优化算法;设备预测性维护则需要传感器、历史故障和时序数据。FDE工程师的职责不是把所有环节都套上同一种AI,而是判断每个问题应该使用什么技术,再把它们接进同一条业务流程。
工厂做FDE,可以按照七步落地
第一步:只选一个最痛的业务问题
不要一上来就说“我们要建设AI工厂”,也不要同时改造销售、采购、库存、排产、质检和财务。
先找一个老板真正关心、现场每天都在发生、结果能够计算的问题。例如:订单经常延期,原料到了但配件没到,库存很多却仍然缺料,小订单频繁插单,报价速度太慢,质量问题反复出现,或者设备停机以后才发现异常。
第一个项目越具体,越容易跑通。
第二步:跟着一张真实订单走现场
工厂的需求往往不是开会“问”出来的,而是沿着真实业务“理”出来的。
FDE需要跟着销售、跟单、采购、仓库、生产、质检和财务,把一张订单从询价到交付走一遍。现场要记录每一步由谁完成、使用什么表格或系统、需要哪些输入、输出给谁、在哪里等待、在哪里重复录入、出现异常后由谁判断。
老板说的是“交付太慢”,生产部门可能说是“插单太多”,采购说是“物料到货不稳定”,仓库说是“产品名称对不上”。只有把流程连起来,才能找到真正的堵点。
第三步:先统一数据,再讨论AI
确定订单号、客户、产品、规格、物料、设备、工序、交期、库存和质量记录等关键字段,明确每个数据由谁产生、在哪里保存、哪个版本是唯一可信来源。
如果工厂已经有ERP、MES或WMS,不必为了做AI全部推翻。FDE应该先连接现有系统和必要的Excel表,补齐缺失数据,再在上面增加轻量的分析和协同层。
这一阶段还要同步确定权限、操作日志、备份和商业秘密保护。客户价格、配方、供应商、成本和工艺参数,不能因为接入AI就失去边界。
第四步:把老师傅的经验变成规则
许多工厂真正有价值的知识并不在系统里,而在老板、生产经理和老师傅脑子里。
什么订单可以合并生产,什么情况下必须换线,哪种原料能够替代,哪类客户不能延期,哪种质量异常必须停机,这些都需要被整理成规则、标准作业流程和例外条件。
AI可以帮助整理文档、查找相关记录和汇总异常证据,但不能在不了解工艺边界的情况下替老师傅作最终决定。
第五步:先做出最小可用版本
第一个版本不求功能多,只求能处理一个真实场景。
它可以只是一个订单解析工具、一张缺料预警表、一个排产建议页面,或者一个把质检记录自动归类的助手。前期可以运行在原有系统旁边,不急着自动回写ERP,更不要让AI直接控制设备。
简单且数据较完整的场景,可以先用几周做出试用版本;数据越乱、系统越多、流程越复杂,梳理时间就越长。FDE项目不应该先承诺一个统一周期,而应先确认问题范围、数据条件和验收标准。
第六步:让AI建议,让负责人审批
在生产环境里,AI给出的建议必须能够说明依据。
例如它建议把两张订单合并生产,就应该同时展示产品规格、原料库存、设备产能、交期冲突和换线成本。生产经理确认后再执行;如果拒绝,也要记录原因。
这种“AI建议、人工审批、结果回写”的方式,比一开始追求全自动更适合多数工厂。它既保留责任边界,也能利用每次人工判断继续修正规则。
第七步:用结果验收,再复制到下一环节
FDE项目不能用“上线了几个智能体”“生成了多少份报告”验收。
不同场景要有不同指标,例如人工重复录入次数、订单处理时间、报价周期、缺料次数、延期交付率、库存周转、返工率、设备停机时长和预测偏差。
第一个场景跑通后,再把通用的数据标准、接口、权限和实施方法沉淀下来,复制到采购、仓库、质量、财务或销售环节。外部FDE团队还要培养企业内部的业务负责人,否则项目一结束,工厂仍然不会自己继续改进。
案例一:电缆工厂先解决排产和缺料
以我们在宁晋接触的电缆产业为例,这里只做典型场景说明,不对应某一家具体企业。
一张电缆订单可能涉及导体规格、绝缘和护套材料、长度、交期、设备能力、模具以及原料库存。传统流程中,销售确认订单后,生产人员再分别查看订单表、库存表和设备安排。临时插单或物料延期一发生,后面的排产就要人工重新调整。
FDE可以先把订单字段标准化,再连接库存、物料清单和设备产能。AI可以解析非结构化订单、识别缺失信息并解释建议;规则或优化程序负责约束交期、产能和换线条件;生产负责人决定最终方案。
这里不能只依赖大语言模型“凭感觉排产”。真正可用的系统通常要把业务规则、数学优化、实时数据和人工经验组合起来。
做完以后,最先观察的不是“AI聪不聪明”,而是订单确认到形成生产计划用了多久,缺料是否更早暴露,临时插单造成的调整是否减少,延期交付率有没有下降。
案例二:把业务员跑客户变成持续获客
我们在正定走访的一家工厂,营销仍以业务员外出拜访为主。线下拜访不是没有价值,但它受时间、距离和个人精力限制,企业也很难沉淀一套持续获得客户的方法。这也是不少县域企业把生产留在本地、把外贸营销放在大城市的重要原因之一。
对外营销同样可以用FDE的思路改造:先梳理产品、客户和成交过程,再建设网站、搜索、社媒和内容渠道,把不同渠道的访问、询盘、报价、跟进和成交记录进CRM,由AI辅助完成多语言内容、客户背景核验、询盘分类、回复建议和跟进提醒。
这样做不是简单地“建一个网站就有订单”,而是把过去分散在业务员个人手里的经验,逐步变成企业可以持续运营、可以衡量的获客流程。
工厂内部和外部最终还要连接起来。销售端拿到的新需求,应该反馈给研发、报价、库存和生产;生产端的交期、成本和质量数据,也应该帮助销售给客户更准确的承诺,形成从外贸获客到生产交付的完整链路。
做完FDE,工厂应该发生什么变化
第一,数据从重复填写,变成一次产生、多处使用。
第二,订单状态从到处问人,变成按权限实时查看。
第三,老师傅口口相传的经验,逐步变成可以复用的规则和知识。
第四,AI从回答问题,变成参与分析、预警、建议和复盘。
第五,企业不再只依赖外部服务商,而是逐步形成自己的内部负责人和持续改进能力。
这些变化不一定轰轰烈烈,甚至第一步看起来只是减少一张重复填写的表格。但只要真实数据开始流动,决策有依据,结果能回写,工厂就已经从“做一个AI演示”走向了“用AI改造经营”。
谁最适合在工厂里牵头FDE
外部FDE工程师不能单独把这件事做成。工厂内部必须有一名能协调销售、生产、采购、仓库、质量和财务的人共同负责。
这个人可以是厂二代、生产负责人、运营负责人、数字化负责人,也可以是老板充分授权的项目经理。关键不是职位名称,而是他能进入现场、拿到真实数据、理解业务取舍,并推动各部门配合。
一个比较实际的组合是:老板确定业务目标和资源边界,内部负责人推动流程和数据,外部FDE团队负责技术实现和实施方法,一线员工负责验证这套流程在现场到底能不能用。
FDE的“D”之所以重要,就在于人必须被部署到真实问题前面。只在会议室听需求,很容易做出一个逻辑正确、现场不用的系统。
工厂做FDE,先买的不是系统,而是一个结果
工厂真正需要的,不是再采购一套名字里带“AI”的软件,而是先解决一个能够计算的问题。
从一张订单开始,把数据、规则、责任人和结果连起来;从一个部门开始,让AI建议、让人审批、让结果回写;跑通以后,再复制到更多流程。
对内,从分散的Excel台账走向生产经营闭环;对外,从业务员单点跑客户走向持续的网络获客。两边的方法其实一致:进入现场,理解业务,连接数据,改造流程,并用真实结果验证。
这才是工厂做FDE最务实的路径。
资料说明:FDE职责和实施理念参考OpenAI公开的Forward Deployed Engineer岗位说明及OpenAI Frontier;制造业数据和业务对象连接方式参考Palantir公开的Foundry Architecture Center与Ontology说明。文中的正定、宁晋和蕲春情况来自走访观察;两个案例用于解释实施方法,不代表对具体企业的公开诊断或效果承诺。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.