一句话：我们的人到你的车间和仓库去，把「数据从哪来、账怎么算、单怎么排、货在哪、问题找谁」这几件事做通， 让老板第二天早上能看到真实的数。
FDE 动作：跟着班组跟一整班，看真实报工动作，把扫码/看板做到工人愿意用。
结果：报工线上化率 ≥90%，生产进度 ≥90% 可视。
FDE 动作：把 BOM、工时、领退料三条数据链对齐，定清成本口径。
结果：按工单 / 批次可算出成本，月结有固定节奏。
FDE 动作：现场走一遍收发货路径，装扫码、定盘点规则。
结果：出入库扫码登记率 ≥95%、账实一致 ≥95%，呆滞与缺料预警 100% 覆盖。
FDE 动作：把订单、库存、工序、工时打通，做自动排程与齐套检查。
结果：排程自动编制率 ≥80%，开工齐套检查 100%。
FDE 动作：定批次标识规则，把来料 / 过程 / 出货检验搬上线。
结果：检验记录线上化率 100%、质量追溯率 100%。
FDE 动作：统一单据口径与凭证规则，把对账差异列成清单逐条销。
结果：业务单据与财务凭证同源，对账有差异清单。
FDE 动作：现场盘点设备与接口，能采集的先采集，不能采的定人工口径。
结果：关键设备运行状态可见，停机有记录、有原因。
FDE 动作：先问老板每天早上要看哪三个数，再倒推数据来源。
结果：经营看板每天自动更新，管理层早会用同一套数。
这八件事不是八套系统，是一条链上的八个环节。FDE 的做法是先挑一个「一个月内能看见变化」的环节做通， 再往上下游延伸——而不是一次性把所有模块都上线。
驻到业务现场的工程师——先把业务摸清，再动手把系统做出来、把数据接通、把流程跑顺
FDE（Forward Deployed Engineer，前沿部署工程师）= 驻到客户业务现场的工程师。
他的活儿不是「照着需求文档做开发」，而是：先到现场搞清楚业务到底怎么跑、数据到底在哪、 卡点到底卡在谁手上，然后自己动手把系统做出来、把数据接通、把流程跑顺， 一直到客户的人真的用起来为止。
中文也译作「前线部署工程师」。这个词最早来自 Palantir——2003 年他们给美国情报部门做项目， 工程师接触不到数据、需求写在密级文件里，只能把人直接「部署」到客户办公室，和情报分析师并排坐着干活， 2011 年成了正式岗位。
一句话总结：您买到的是「工具」，而我们要交付的是「工具在你的车间里真的转起来」。两者不是对立——好的软件是前提，但把软件用起来，是一门独立的功夫。
软件是必要条件，但不是充分条件。客户买到软件，不等于软件能投入使用—— 这是行业里的普遍情况，不是哪一家产品的问题。
| 维度 | 卖软件 | FDE 服务 |
|---|---|---|
| 起点 | 从产品功能出发：有实时库存、有预警、有看板 | 从你的现场问题出发：先问「现在为什么不准、上次盘点差多少、差在哪几个料上」 |
| 主要在干什么 | 把软件装上、参数配好、数据导进去 | 跟着仓管走一遍收发货，把「先发货后补单」「代用不记录」这些真实动作逐个解决 |
| 交付物 | 许可与操作手册 | 能用起来的数据与流程 + 交付物（口径说明书、扫码与盘点规则、分岗位手册、看板） |
| 谁负责「跑起来」 | 客户自己：功能可用、培训做完，后面怎么用是客户的事 | 我们驻场负责到跑通：工程师自己在现场判断、自己改配置、自己跑数据验证 |
| 结束标志 | 验收签字、项目结束 | 你车间里真的在按新方式干活：扫码登记率 ≥95%、账实一致 ≥95%，连续 30 天 |
| 出了问题 | 提工单排队，按响应时限处理 | 现场的人就在：上线后 30 天陪跑，业务真在用、数据真在流才结项 |
| 经验去哪了 | 留在实施人员的个人经验里，下一个项目重新摸索 | 只属于这一家的做法留下，别的厂也会遇到的就沉淀成我们下一家的现成做法 |
注：表里这三个比率（扫码登记率 ≥95%、账实一致 ≥95%、连续 30 天）是系统行为指标， 看系统记录就能判达标，可以写进合同；它们不是经营结果承诺，口径见文末「数字口径与公开来源」。
不是。外包是「你说做什么、我做什么」，人只对交办的动作负责。FDE 是对结果负责：先跟你一起确认目标（比如「账实相符 ≥95%」，看系统记录判定），再倒推需要哪些数据、哪些动作、哪些功能。做到没做到，翻系统记录。
不会。系统只能承载规则，不能替企业定规则。批次怎么标识、成本按什么口径算、报废谁签字——这些是管理决策，系统只是把它固化下来。所以双向责任里写明：客户侧要配合定规则、要把相关执行纳入考核；规则定不下来，再好的系统也只会在上面长出一堆假数据。
正相反，我们的做法是一次只做一个环节：先做一个月内能看见变化的那一块，一条线、一个仓库先做通，跑起来之后再往上下游延伸，而不是一上来把所有模块都上一半。我们把范围写进合同，双方按同一份范围推进，避免「做了一半、谁也不认」。具体做法以合同约定为准。
正确的顺序不是「先买软件，软件自己会跑起来」：先把系统买对、配好，再有人把现场的动作和规则理顺， 系统里的数才会是真的。反过来，现场的动作不变、单据照旧、考核照旧，系统里只会多出一套看起来完整的假数据—— 这种情况我们会在诊断阶段直接讲出来。
卖软件交付的是「工具」，FDE 交付的是「工具在你的车间里真的转起来」。
不是制造业「更落后」，而是制造业的数字化有四个别的行业没有的特点，远程做不了
工人可能为了赶产量先开工后补单，仓管可能因为扫码枪没电就先记纸上，班组长可能把两个工单的料合在一起领。这些动作决定了账能不能对上，但只有站在现场看才看得见——访谈里问不出来，因为当事人不觉得那是问题。
数据通常同时散在：ERP、Excel 台账、纸质派工单、微信群、设备本地屏、老师傅的脑子里。进场后往往要先做数据治理和知识梳理这些「脏活累活」，这些活儿在办公室干不了，必须一边看现场一边梳理。
同一台设备、同一个产品，不同老师傅的参数不一样；什么样的活该排在哪条线，老师傅心里有数但说不清。这些隐性规则不被问出来、写下来、变成系统里的规则，排产和质检就永远「看人」而不是「看系统」。
工厂不缺报告，要的是：成本到底多少、这批货几号能交、仓库里压了多少钱、这个月为什么没赚钱。看板做得再漂亮，底下的报工是假的、库存是估的，看一眼就不会再看第二眼——真正的门槛是「数据从哪来」，不是「报告怎么画」。
行业里也已经看清了：直接照搬海外「重装部署」的更深层问题是不可持续——项目做完、人一走， 能力也随之带走，下一家工厂依然要从零开始。所以本土化的方向，是让 FDE 从一种「岗位」变成一种可沉淀、可延续的能力。这正是尚贤做 FDE 服务的前提：不能只靠驻场人力，必须有可复用的做法、 有交接、有陪跑。我们 18 年在制造、食品、商贸、工程、农牧这些行业做实施，攒下来的就是这套可复用的东西。
九块内容，按制造业真实痛点划分。每块都写清三件事：FDE 在现场做什么动作 · 交付什么物 · 客户得到什么结果。 「结果」栏里的比率，是可以写进合同的系统行为指标——看系统里跑出来的记录判达标，不承诺经营结果（省了多少钱、合格率一定提升多少）。
老板的原话通常是：「昨天的产量，今天中午才能问出来。」纸质派工单、微信群报数、下班前一次性补录，结果是进度永远滞后一天，异常永远事后才知道。
月底结账靠倒推，料工费归集不到工单，报价只能凭感觉加几个点。成本不准，报价就是赌。
系统里的数和仓库里的货对不上，呆滞和缺料都是盘点时才发现。账实不符，后面所有的分析都是假的。
排程靠 Excel、跟单靠人盯，1～1.5 个人的时间绑在排程上；最怕的是开工了才发现缺料，设备、工人、订单一起等。
客户投诉要查批次，只能翻纸质检验记录，一查半天。追溯做不了，出了事只能全批认损。
业务和财务各自一套数，对账靠 Excel 拉来拉去；差异找不到原因，只能挂账。
设备开着没开着、跑了多少、为什么停，全靠人记。没有设备数据，OEE 和产能都是猜的。
客户问价，业务凭经验报一个数；报完能不能做、什么时候交，要再问一圈人。报价慢、报错价，丢单或者亏单。
看板做了一堆，没人看。问题从来不是「图不够漂亮」，而是「底下的数不是真的」。
这九块怎么选？通常不建议一次全做。我们的建议是：先做「库存账实相符 + 报工线上化」这两块—— 因为几乎所有其他分析都建立在这两个数据源上；跑通之后，再按你最疼的地方往成本、排产、质量追溯延伸。
每个阶段都有明确的现场动作和可验收产出。做不完上一阶段的产出，不进入下一阶段——这是我们对「不烂尾」的理解。
人到现场，按岗位跟：跟一个班组走一整班、跟仓管收发一次货、跟计划员排一天产、跟财务结一次账。同时看真实单据（纸质派工单、微信群记录、Excel 台账），不只看系统里的。这一阶段不急着提方案——先把事实收集齐，因为很多「问题」看到现场之后会换一个说法。
产出：现场调研记录、业务流程现状图、关键岗位访谈纪要、现有单据与数据清单。
把现场看到的事实，和「账实相符、成本算得清、交期可承诺」这些目标对比，列出差距清单。每条差距写清：现状是什么、目标是什么、差在数据还是差在流程还是差在人不执行。同时和老板对齐一件事：哪一条差距最疼、最先解决——这一步定不下来，后面一定反复。
产出：现状与差距报告、优先级排序（含原因）、第一期范围建议书、双方责任人清单。
只做第一期范围，做到「能跑起来、能看见数」。宁可先只做一条线、一个车间、一个产品，也不要为了好看把所有模块都上一半。这一阶段的关键动作是「把人教会」：不是发一份手册，而是站在工位旁边看着操作几遍，直到不用提醒也会做。
产出：系统配置完成、数据初始化完成、操作手册、上岗培训与考核记录、第一个闭环的验收记录。
看系统里跑出来的记录和现场对不对得上：报工流水是不是真实的、扫码率有没有掉、预警有没有人处理。对不上就改——可能是规则定错了，也可能是动作设计得太麻烦。每轮迭代都回现场确认一次：不看「功能上线了没有」，看「数据对不对、人用不用」。
产出：迭代记录、问题清单与处理结果、指标达成情况表、范围扩展建议。
把系统交给客户自己的人：谁负责日常维护、谁负责数据质量、出问题找谁、怎么做月结和盘点。交付源码、文档与操作手册，不留「只有我们能改」的黑箱。上线后还有 30 天陪跑期——这 30 天里业务真的在用、数据真的在流，才算交付完成。
产出：验收确认单、操作手册与运维手册、培训记录、数据责任矩阵、30 天陪跑记录与结项报告。
我们按7 个阶段、约 50 件交付物的方法论推进项目。下面是各阶段的代表项，不是全部； 具体项目按合同额分档确定必选项。
「源码可交付」也是我们的做法之一：二次开发部分交付源码， 不让客户变成「离了原厂就动不了」。具体交付范围在合同里写清楚。
把边界说清楚，比把话说满更有用。下面「先不要做」的几种情况，我们会在诊断阶段直接讲出来， 而不是先签了合同再说。
不需要先做决定。先做一次免费诊断，我们会去现场看一圈，告诉你哪些能做、哪些先别做。
我们不做的事：不承诺「保证降本多少个百分点」；不承接检验数据造假； 不做「只有我们能维护」的系统。诊断阶段的结论如果是不建议做，我们会直接讲。
指标能写进合同，是因为它看系统记录就能判；经营结果不在此列