制造业数字化转型是顺序问题，不是技术问题

顺序才是难的那部分，也是供应商资料里跳过的那部分，因为诚实的版本意味着要告诉客户今年少买一点。这个页面讲的就是这个顺序。

制造业数字化转型项目为什么会卡住

大部分卡住的项目，原因就四个。这四个都是项目管理层面的失败，而不是产品的失败——这正是重点：它们是工厂自己能控制的。软件当然也会在它自己的层面上出问题，那份清单属于采购环节：事务设计、规模化之后的性能、以及一家上线即结束的供应商。

第一个是有发起人，下面却没有负责人。发起人批预算、参加月度会议；负责人要待在车间、有权改流程，并且一年后工厂运转方式是否真的变了，与他个人的考核挂钩。第二个是商业论证假设了并不存在的数据，于是“分析停机”的计划撞上了交接班表上的一列自由文本。第三个是试点从一开始就没打算推广。第四个是问题还没想清楚就先买平台，结果工厂拥有了一套能力很强、却没有第一个用途的系统。

第一个数字化项目怎么选

第一个项目应该来自工厂的瓶颈，而不是来自模块清单。多数工厂的损失都不体面：换型超过标准工时、料找不到、没人上报的两分钟短停机。

三个问题能很快筛掉候选项。这项损失是否已经出现在工厂自己的账上——报废、加班、加急运费或延迟交付罚款？如果有人拿到答案，他会在同一个班次内做出不同的动作吗？你能在一个生产周期内判断出它是否有效吗？是周期，不是季度：三个月在多品种重复性生产里是个公平的检验，在航空或制药里则毫无意义，那里的单位是一轮生产或一张订单。

有时候软件就是错误的答案：如果瓶颈是物理上的，再多数据也不会让机器变快。测量真正做的事，是显示产能去了哪里，而这通常会改变而不是佐证那份资本支出申请。把短停机算进去之后，那台候选设备自己的运行时间比谁想的都难看；但它损失的大部分小时数并不是它自己造成的：上游断料、下游堵塞、在换型，或者在等一个同时看两个工位的操作员。这台设备从来就不是瓶颈，钱应该花在别处。

开始之前要测什么，才能在事后证明变化

陷阱在定义上。上线前，时间稼动率取自交接班表，而短停机根本没人记；上线后，停机被自动采集，于是测出来的OEE反而下降，因为一直存在的损失终于被算进去了。如果没人记录下旧的定义和旧的数字，第三个月看上去就像倒退，项目会把自己的信誉花在自证清白上。

所以要把当前的数字和它的完整定义写下来：百分比用的是哪个时间基准，理论节拍从哪里来，停机怎么分类，计划保养是否扣除，返工怎么处理。前两项决定了大部分结果：日历时间、计划时间和出勤时间会让同一个工厂用同一份数据得出三个不同的数；而理论节拍可能是铭牌值、历史最好值，或者工艺路线里设定一次之后再没人碰过的一个数。

然后把那些更难被重新定义、并且能和财务对上的事实记下来：出货数量、支付工时与实际运行工时、延迟交付的订单行、红字发票和加班。更难不等于不可能，所以要和OEE定义一起，把每一项的定义和来源系统冻结下来。准时交付需要单独写一条决定，因为日期口径是任何一家工厂里被反复争论最多的定义：是原始承诺日期还是最后一次变更后的日期，是按订单还是按行，是按发货还是按客户收货。

什么在先：网络连接、主数据，然后才是分析

网络连接和主数据在最底下，分析在最上面，上面那层值多少钱取决于下面两层值多少钱；而主数据是一直被低估的那个依赖项。执行系统无法下达一道工艺路线里根本没有的工序，排程也无法在没有近十年有人实测过的标准工时的情况下排序。所以在承诺日期之前，先数一数：多少零件没有工艺路线，多少标准工时是整数凑出来的，多少库位现实中存在却不在任何系统里，多少物料清单是重复的。

另一条应该在开始而不是结尾去界定的接缝，是ERP集成，它的难点在于达成一致，而不在代码：一次报工在双方各自意味着什么，是车间报还是倒冲，部分数量和订单拆分如何落地，物料已经移动之后冲销会发生什么，报废按标准成本记到哪里。每一个答案都是一次跨部门的决定，而这些部门此前从未被要求达成一致。

有两项长周期依赖很少出现在技术路线图上。一套把产出、停机和报废归到具体某个操作员名下的执行记录，在德国和欧洲大部分地区属于有能力监控个人绩效的系统，因此上线前需要与职工委员会谈成一份企业协议。审批要几个月，所以要在第一年就与主数据并行启动。内容其实不长：是否存储操作员身份、谁能看到、保留多久、报表是否在设计上就做了汇总。

第二项适用于受监管的生产。在制药、医疗器械和相当一部分食品行业，凡是记录或强制执行质量放行结论的系统都属于验证范围：验证计划、确认、审计追踪、电子签名义务，以及之后更慢的变更控制。报表、停机采集和排程在这条线之外；批次锁定、放行结论，以及视觉检测系统所用的模型版本，则在这条线之内。要在买模块之前就界定清楚，因为验证往往是整个项目里单项周期最长的一块。

为什么MES在APS之前，质量数据在AI质量预测之前

如果高级排程拿到的，是昨天关于活儿在哪里的假设，那么排出来的顺序会在开班前被人工重排一遍，计划员几周之内就回到Excel里，最后的结论是排程软件不行。它不是不行，它是看不见。

实时输入让排程变得可行，但不等于能执行，大多数对APS的失望就落在这个差距里。即便数据完美，如果优化目标搞错了——工厂按交期考核，排程却在最小化换型——这个排程照样没人理；如果次要约束缺失也一样，因为真实的加工顺序是由工装、技能矩阵和共用人力决定的；如果什么都不冻结也一样，因为一个持续重解的优化器，会在主管每次去看的时候都给他一版新计划。定好一个冻结期，让优化在冻结期之外去折腾。

质量预测是同一个形状：一个预测报废的模型，需要报废在它实际发生的那道工序上被记录下来，带上原因和过程上下文——从设备、刀具到物料批次。

维护这边有一个常被销售话术盖过去的区别。基于振动或电流特征的异常检测不需要故障历史，但这不等于不需要数据：它需要覆盖完整工况范围的数周健康状态数据，否则它会对每一次换型报警，而不是对损伤报警；它还需要按你关心的失效模式来安装和采样的传感器。即便如此，它也只能说“这里不正常”；要知道哪些异常真的有意义，还需要带失效模式的维修工单历史。

一台在屏幕上显示OK或NG的相机同样没有改变工厂：这个判定必须挂到执行与质量记录中的一张工单、一个批次和一个模型版本上，这让视觉检测成为一项靠后的能力，而不是一个入口。有限产能排程、一份APS排程必须满足什么，以及CMMS到哪里为止、预测性维护从哪里开始，另有专门的文章。

谁来主导这个项目，以及操作员为什么抗拒在车间录入数据

IT是伙伴，不是主人：当IT主导项目时，它会围绕集成和安全去优化，这两件它做得很好，然后卡在推行上，因为那条线上没有人对操作员到底用不用这个界面负责。负责人下面坐着关键用户，每个区域一名，指名到人，并分配工时：由他们决定一个界面问什么、按什么顺序问，而车间听他们的。

被说出口的推行障碍几乎总是人；真正的障碍通常是那笔事务本身的设计。去看一次换型时的报工：手上戴着手套，下一张订单在等。如果录入停机原因之后什么可见的事都没发生，这个录入就是压在班次上的一项税，会被拖到最后一刻才交，而且通常是下班前编出来的一批数。如果它能通知维修、更新看板或者重排下一张订单，它就变成工作的一部分了。

好的录入设计是很具体的：终端就装在机台旁，能戴着手套单手操作，默认值从订单里带出来，每种机型配一张简短的原因清单，而不是一套只有少数几个代码真被用到的分类体系。当事务贴合作业本身时，培训短到可以在班中就在机台边完成。当它不贴合时，再多课堂时间也补不回来；而“要求增加培训”往往是把设计问题误诊成了人的问题。

多数培训计划漏掉两件事。第一是更正：教人确认一个合格数量很容易，而冲销一个错误数量、或者拆掉一笔报到错误订单上的报工，才是未经培训的用户真正造成破坏的地方。第二是培训不是一场活动，因为主管需要的比操作员更多，而新员工、劳务派遣人员和多语言的车间是持续不断进来的。

把试点推广到全厂：什么样的试点是可复制的

试点推不开，原因是设计进去的：挑了最好的产线，避开了老设备，供应商天天驻场，主数据是人工整理出来的。为推广而设计的试点跑在一条有代表性的产线上，包含至少一台难搞的设备，并记录每条线投入的工时，因为那个单位成本是推广计划唯一诚实的输入。

退出标准和推广决策日期要在试点开始之前就定好，而收尾那一段要在供应商不在场的情况下跑完。这一段重要的是它覆盖了什么，而不是它有多长，因为试点很少在正常生产时失败。它们失败在第一次期末结账——数字必须和ERP对上，然后有人发现报废被记了两遍；也失败在停机后的第一次重启——网关都回来了，缓存的计数却没有。所以要明确覆盖范围：一次含对账的期末结账、这条线跑的全部产品组合，以及一次计划停机和重启。在多数工厂里那是一个月或一个完整周期，而不是两周。

数字化转型预算包含什么，以及之后的运行成本

许可费是被压价压得最狠的一行，而真正决定结果的几行在别处：与ERP和设备的集成；硬件，从网关、面板到加装的传感器；主数据清洗；培训以及它占用的生产时间；还有内部投入。内部投入是最常被漏掉的一行：关键用户、负责人、IT、装网关的技术员、切换时损失的产量。如果没人给这些工时算过账，那么不管许可费谈得多漂亮，预算都是错的。

物理施工分成两类，排期方式完全不同。布线、交换机端口，以及控制网与办公网之间的隔离，属于交期长的常规工程，可以与生产并行推进。机柜里面的任何工作都不行：那是隔离作业，需要上锁挂牌和一次计划停机，而多数工厂对带电开柜有长期禁令。所以连接工作真正的约束，是今年还剩几个停机窗口，以及其中多少已经被维护占掉了。连接是按维护日历排的，不是按软件计划排的。

然后是运行成本，没有哪份项目预算包含它，而财务总监会第一个问：第四年要花多少钱。订阅费或年度服务费会继续；工业面板和网关比办公硬件坏得快。最重要的是，供应商撤走之后得有内部的人来运行这套系统：主数据维护、原因代码和工艺路线的变更、用户管理、每个版本的升级。还要为上线后十二个月内的变更单独留预算，因为真正值得花钱的需求，只有在车间开始相信系统给出的数字之后才会提出来。

三年智能工厂路线图怎么排

日历能补上依赖顺序补不了的东西：每一个边界上由谁来拍板，以及钱和工时怎么分段。第一年解决那些改起来很贵的决定，而且是由负责人会同财务、IT和职工委员会去定，而不是项目组：KPI定义、主数据结构、ERP接缝、操作员身份，以及在受监管工厂里的验证范围。相对于许可支出，内部投入在这一年达到峰值，所以一份长得像常规IT项目的预算，一开始就是错的。有一项工厂常常推后、但属于第一年：给最大的几个用电负荷装表以建立基线，这是仪表化而不是建模，而且在能源管理标准或审核要求下往往不是可选项。

进入第二年的边界是一个判断，不是一个日期：当车间开始跟系统给的数字争论、而不是无视它的时候，就跨过去了。闭环意味着主管或质量经理把一个决定交给一条规则，所以这个范围要和那些权限会被移走的人去谈，而支出的重心也从内部工时转向许可和集成。第三年才配得上基于模型的那一层，因为它建立在两年的记录之上，而它的边界条件是归属：每一项能力都需要一个指名到人的责任人，负责阈值和再训练的节奏。按零件分摊的能耗属于这一年，因为分摊需要前两年搭起来的执行记录。

有两个停止条件要写进审批里。如果车间不信第一年的数据，第二年就不开始。以及，因为董事会要一个AI项目就把第三年提前，产出的正是本文开头描述的那种卡住的项目。

怎么判断要不要继续：每个阶段的关卡标准

每个阶段都需要一个关卡，而且证据要经得起一个怀疑者看。连接完成后，一个完整班次内自动采集的产量与人工点数是否对得上，误差在测试之前就商定的容差之内。第一个数字报出来之后，旧的那张Excel是否还在同时维护；当它悄悄不再更新时，说明这个数字被接受了。

有一个关卡属于第一次执行系统上线，而且几乎总被跳过：系统不在的时候，这条线怎么办。一旦操作员在机台上报工、质量按规则锁定批次，一个坏掉的交换机或接口就会让生产停下来：工厂用一块写字夹板换来了一个单点故障。所以要先定义并测试降级模式：终端在本地缓存什么、缓存多久，纸质的兜底方案是什么，谁有权批准在没有系统的情况下继续生产，以及补录时怎么做到不重复计数。测试方法是在生产班次中把连接拔掉，因为未经测试的故障切换，正是上线变成生产事故最常见的原因。

执行记录跑起来之后，你能不能在不问任何人的前提下，按商定的标识颗粒度还原出一张订单的全过程，包括停机、报废和是谁做的。在做排程之前，班次开始时的在制品是否准确。有一个趋势比任何单个关卡都重要：如果每上一条新线的成本都和上一条一样，那么这个项目建的是一套套定制安装，而不是一种方法。

Meta Smart Factory 处在什么位置

Meta Smart Factory把上面这些层做成了彼此独立的模块，从MES、MRP、APS到质量、维护、仓储、视觉，以及ERP集成。模块化让这种排序变得可以分步采购，但第一笔采购不只是一个模块。它是一个模块，对着一个区域里一个指名的瓶颈，外加它下面的地基：连接、主数据清洗、ERP接缝和商定的定义。这块地基占了第一年大部分的投入，却不出现在任何价目表上，所以它应该作为独立的一行写进审批，而不是被默认包含在许可费里。

难的部分不会因为选哪个平台而消失。把数字的含义定下来、把主数据清干净、把操作员不用被追着也愿意完成的事务设计出来，以及决定停掉哪些事情，这些都是共同的工作。如果你正处在这个位置，那么围绕你的瓶颈聊一次顺序，比看一场产品演示更有用。