《质量返工反复发生，别只问谁粗心：先查这三段交接》

一个很常见的场景：质量返工又来了，生产说按图做了，质检说首检提醒过，班组长夹在中间只能先补救。

生产主管说是设备问题，机修说自己接到通知太晚，仓库说物料早就备好了，班组长说首检一直没过。每个人听起来都有理由，但订单就是晚了，成本就是多了，工厂老板最后还是不知道哪一环在漏。

很多工厂推进数字化，真正卡住的不是软件功能，而是一个更基础的问题：工厂对自己现场发生过什么，没有解释权。

想少走弯路，第一步不是先把功能清单拉满，而是先把这种解释权补回来。

一、什么是现场解释权

现场解释权，不是多装几个看板，也不是月底多导几张报表，而是老板能回答五个问题：什么时间发生了什么，谁先知道，谁处理，处理多久，最后有没有结果。

如果这五个问题回答不上来，系统上线以后，旧问题不会自动消失，只会换一种更贵的形式继续存在。

比如一台设备停了，过去的解释可能是“设备有点问题”。有解释权以后，问题要被拆开：几点停，停了多久，停机前后在做哪张订单，谁确认异常，谁接手处理，是否影响后续工序。

很多现场问题最终都会落到同一个底层矛盾：状态、动作、异常和产能变化如果串不成事实链，管理层就只能事后猜原因。

这句话放到老板视角里，其实就是一句大白话：你不是不知道结果差，你是不知道结果为什么差。

二、先看五种解释权有没有

第一，是设备解释权。

设备不是只分“开”和“停”。老板真正要知道的是：它为什么停，停在什么工序，停机前有没有预警，机修有没有响应，恢复以后有没有影响良品和交期。

第二，是物料解释权。

很多订单延误，表面看是生产慢，实际可能是待料、错料、少料、批次不清。物料解释权的核心，是让每一次等待都能说清楚原因，而不是车间和仓库互相甩锅。

第三，是订单解释权。

订单不是排进计划就结束。它在车间走到哪一步，卡在哪个工序，是否存在插单、返工、等待首检，老板必须能追到过程。

第四，是质量解释权。

质量问题不能只在终检时暴露。返工发生在哪一步，谁发现，谁确认，影响了多少工序，这些如果说不清，质量损失就会被摊进“综合成本”里，最后谁都不用负责。

第五，是异常责任解释权。

异常不是被发现就算解决。谁接单，多久响应，谁升级，谁关闭，这条责任线如果断了，系统里再多按钮也只是摆设。

数字化不能停留在系统概念上，必须回到现场动作、责任边界和真实数据。

这就是很多项目做重的根源：上面想要经营数据，下面连现场动作都还没沉淀成事实。

三、现场不清楚时直接上系统，为什么会越做越重

很多老板以为，上系统就是把流程规范起来。

但如果上线前没有解释权，系统会遇到三个麻烦。

第一，需求会膨胀。因为现场说不清，大家就会把所有问题都塞给系统：排产要改、报工要改、仓库要改、质检要改、绩效也要改。最后项目从一个生产执行工具，变成一个试图重写全厂管理的巨型工程。

第二，数据会失真。如果停机、待料、返工、首检这些动作本来就靠人补，系统上线后也可能继续靠人补。数字化不能停留在系统概念上，必须回到现场动作、责任边界和真实数据。

第三，责任会继续模糊。系统记录了异常，不代表异常会被处理。没有接单规则、转交规则、升级规则和关闭规则，异常只是从口头扯皮变成线上待办。

所以，系统不是现场解释权的替代品。它更像放大器：现场清楚，它放大效率；现场糊涂，它放大混乱。

四、一个常见场景：为什么不能把它包装成真实案例

这里必须说清楚：如果素材里没有完整客户案例，就不能把故事写成“真实客户故事”。只能讲常见场景。

一家多品种小批量工厂准备做数字化。老板最痛的是交期不准，于是第一反应是要排产模块。可往下追，问题并不只在排产：设备换型时间没人记录，首检等待没人统计，物料齐套只靠班组长催，异常处理靠电话和微信群。

这时候如果直接做大而全的系统，项目很容易变重。更合理的顺序，是先选一条瓶颈产线，把三类动作跑清楚：设备状态、物料等待、异常责任。等这三类动作能被稳定记录和复盘，再去谈排产、绩效和经营驾驶舱。

这个场景不能扩大成所有工厂的结论。反过来，如果一座工厂产品稳定、自动化程度高、异常很少，先补这套现场解释权的收益不一定最大；但对订单驱动、多品种小批量、设备和物料经常打断计划的这类工厂，它通常是更靠前的一步。

这个场景的经验是：不要先问系统能做多少功能，先问现场能不能提供真实动作。尤其要看班组长有没有权限调动机修、仓库和质量；如果没有授权，却把责任都压给班组长，现实里很容易变成多做多错、少做少错。

五、老板启动前，先做三步检查

第一步，列出最痛的三类现场问题。

不要写“效率低”“管理乱”这种大词，要写具体动作：换模等待、首检等待、待料、返工、停机、插单、报工不准。

第二步，给每类问题补一条事实链。

每条事实链至少包括：发生时间、责任岗位、处理动作、持续时长、最终结果。没有这条链，后面所有报表都容易变成装饰。

第三步，先做一个小闭环。

不要一上来全厂铺开。先选一条线、一个班组、一个瓶颈工序，用两到四周验证：数据能不能真实采集，异常能不能被接住，责任能不能闭环，主管能不能每天据此调整动作。

如果这三步都过不了，系统越大，风险越大。厂长、车间主任、班组长、质量、仓库和机修最好都能看到同一条事实链：谁接单、谁处理、谁升级、谁关闭，哪些责任在岗位内，哪些需要授权，哪些动作会影响收益和风险。

很多工厂缺的不是更多系统，而是对现场发生过什么拥有解释权。

系统真正值得上的时机，不是老板被方案打动的时候，而是工厂已经准备好把现场动作变成事实、把事实变成责任、把责任变成改进的时候。

这篇更适合粗放管理、成长型规范化、现场异常多的小型和中型离散制造工厂。大型或成熟工厂当然也可以参考，但不能简单照搬；有些工厂的问题可能先在工艺、设备能力或供应链承诺，而不在现场记录本身。

这也是它适合被老板转发给厂长、车间主任和班组长讨论的原因：大家不是争谁更辛苦，而是把权限、责任、收益、风险和升级机制摊开讲清楚。

没有解释权，系统只是更贵的记录本；有了解释权，系统才可能变成管理的放大器。