有个现象挺耐人寻味：制造业数字化项目的失败率，这么多年来一直没有明显下降。软件越来越成熟，实施方法论越来越完善，可项目做砸的比例还是那么高。
问题往往不在技术，而在路径。
一、八种失败模式，几乎覆盖了所有翻车现场
课件列了八条，每一条都能在项目复盘会上听到。
第一，目标写成"上线 MES/WMS"，没有经营指标。 项目章程里写的是"完成 MES 系统上线"，而不是"把准时交付率从 78% 提到 90%"。结果验收的时候，系统确实上线了，业务指标一个没动。项目成功了吗？按章程是成功了，按经营是失败了。
第二，软件先行，流程与主数据长期悬而未决。 系统都开始配置了，物料编码规则还没定下来，工艺路线版本怎么管还在争论。这类项目最后往往变成"把混乱固化进系统"，上线后反而更难改。
第三，MES、WMS、ERP 各建一套库存或工艺账。 三套账，三个数字，谁也说不清哪个是真的。盘点时对不上，就只能靠调整单抹平，账面准确率成了自欺欺人。
第四，过度定制，把旧流程原样固化进新系统。 花了大价钱做二次开发，实现的却是二十年前的老做法。定制越多，升级越难，最后被自己的系统锁死。
第五，设备采集追求"大而全"，没有场景和数据质量策略。 把所有点位都采上来，数据量暴涨，存储成本飙升，真正用到的数据却不到百分之一。更要命的是，很多点位的数据质量极差，传感器漂移、通讯丢包，采上来的都是噪声。
第六，只测试正常流程，异常、断网、返工、退料无法闭环。 演示的时候一路顺畅，上线第一天遇到返工，系统卡住了；第二天网络抖动，数据丢了。生产现场百分之三十的时间在处理异常，而系统只覆盖了那百分之七十的顺畅部分。
第七，试点选最容易的区域，推广时才暴露复杂性。 试点特意挑了一条产品单一、设备最新、人员配合度最高的产线。跑得很成功，老板很满意，然后推广到其他车间，全崩了。
第八，上线即撤项目组，没有产品运营和持续改善机制。 上线三个月后项目组解散，没人维护规则、没人迭代优化、没人跟进指标。系统慢慢变成电子化的台账，两年后被悄悄替换掉。
这八条里，前三条是立项阶段的问题，中间三条是实施阶段的问题，后两条是推广和运营阶段的问题。对照一下，基本能定位自己的项目卡在哪。
二、从场景到项目的七步法
对应的解法，课件给了一条七步路径。
第一步，战略对齐。 明确交付、质量、成本、库存或合规目标。这一步要产出的是可量化的经营指标，不是系统功能清单。
第二步，现状诊断。 梳理流程、系统、数据、设备和组织能力。诊断报告应该包含业务流程现状图与主要断点、系统应用地图和接口现状、主数据对象与编码规则及质量问题清单、设备联网与自动化及网络安全现状、关键场景痛点与影响范围及量化基线、业务 IT OT 与供应商的责任矩阵、约束条件（停线窗口、预算、合规、老旧设备、人员能力）。
课件有句话很硬气：不接受只有"功能需求列表"而没有问题基线、业务流程和数据责任的诊断报告。这句话值得写进采购合同。
第三步，场景规划。 形成场景清单、价值假设和优先级。这一步的产出物是一张打分表，按业务价值 40%、紧迫性 20%、数据可得性 15%、技术可行性 15%、推广性 10% 排序。
第四步，蓝图设计。 明确系统边界、流程、数据和集成架构。课件要求画出五张图：业务流程图（从订单、计划、执行到交付的闭环）、应用架构图（ERP、PLM、MES、WMS、QMS、EAM 的边界）、数据架构图（主数据、业务数据、时序数据、指标与知识）、集成架构图（API、消息、文件、数据库、设备协议和平台）、部署与安全图（云/边/本地、网络分区、身份、备份和容灾）。
每张图都要回答五个问题：谁是源头、谁能修改、何时同步、失败怎么办、如何审计。
第五步，试点实施。 选择有代表性的产线、车间或仓库验证闭环。注意"有代表性"三个字——不是最容易的，也不是最难的，是能代表推广时典型复杂度的。
第六步，复制推广。 模板化配置，控制个性化和技术债务。这一阶段最容易失控的是定制需求，每个车间都说自己情况特殊，最后模板失效。
第七步，运营优化。 指标复盘、规则迭代、数据治理和版本管理。这一步没有终点，它决定了系统能不能持续产生价值。
三、几个容易被跳过的治理动作
主数据治理要单独立项。 组织资源（工厂、车间、产线、工位、班组、人员、技能）、产品工艺（物料、BOM、工艺路线、工序、程序、参数、版本）、生产资源（设备、工装、模具、容器、计量器具、产能日历）、物流资源（仓库、库区、库位、载具、包装、批次/效期规则）、质量资源（检验项目、方法、规格、缺陷、处置、抽样方案）。
五类主数据，每一类都要有唯一编码、权威来源、发布审批、生效失效、变更影响分析、历史版本保留。这件事不做完，后面的系统都是在沙子上盖楼。
集成架构要分层设计。 实时事件用消息或事件总线发布开工、完工、缺料、异常、库存移动等状态变化；业务服务用 API 查询主数据、订单、库存、工艺和任务；批量交换只用于低频、非关键、可补偿的数据同步；设备接入通过 OPC UA、MQTT、工业网关或设备平台统一接入；数据分析由业务库、时序库、数据湖仓分工承担，避免直接压垮交易系统。
课件还特别提醒：接口验收必须包含重复消息、乱序、超时、断网、字段缺失、回滚、补偿和人工重处理测试。这八种异常场景，是系统健壮性的真正试金石。
项目组织要有人真负责。 业务负责人对业务目标、流程决策和推广效果负责；项目经理管范围、进度、风险、资源和跨部门协调；产品/流程负责人管需求优先级、蓝图、验收和规则管理；数据负责人管编码、质量、迁移、口径和权限；IT/架构团队管技术架构、集成、环境、运维和安全；OT/设备团队管设备接口、控制边界、现场改造与停线窗口；供应商负责产品配置、开发、测试、文档和知识转移。
关于一把手支持，课件给了一句很实在的判断标准：能够推动跨部门流程变更、数据责任落地和关键资源投入。开会时表个态不算支持，能在部门利益冲突时拍板才算。
四、选型时最该看重什么
课件给的权重分配值得参考：行业适配 25%、产品能力 20%、实施能力 20%、架构集成 15%、运维扩展 10%、总拥有成本 10%。
行业适配权重最高，这个排序很说明问题。同样是 MES，做汽车零部件和做机加工，业务逻辑差别巨大。一个在本行业有成熟模型和参考案例的团队，能帮你避开大量坑。
而至于演示，课件建议得很直接：用企业真实订单、BOM、工艺、异常和库存数据跑通端到端脚本，不只看标准演示。一个具体的脚本可以这样设计：创建一个含替代料、返工路线和关键 SN 的工单；模拟缺料与设备停机，展示重排和影响分析；完成备料、配送、过站、防错、检测、返修和入库；最后从缺陷产品反查物料批次，再正查受影响产品与库存。
能把这四步跑顺的系统，能力不会差。跑不顺的，PPT 做得再漂亮也没用。
五、写在最后
数字化项目失败，很少是因为某个技术难题没攻克，多半是因为该做的事被跳过了。
七步法没有一步是多余的，八种失败模式也没有一条是罕见的。把它们打印出来贴在项目经理的工位旁，可能比任何先进的方法论都管用。
