巡检系统上线后没人用，先查这三件事

系统上线三个月，数据越来越少。 第一个月还像模像样，第三个月开始出现「全部正常」的记录，半年后变成应付检查的摆设。这不是个例，是巡检系统最常见的死法。

多数人把它归因于「一线抵触」「年纪大不会用」。但真实原因通常更具体，而且都在系统设计侧。

一、判据不清，他只能填「正常」

如果系统里只写「温度」「压力」「有无异响」这样的字段，没有正常范围，巡检员面对一个模糊的框，最安全的选择就是填「正常」。

不是他偷懒，是系统没给他判断依据。 换成「温度 60～75℃，超出填实测值」这种写法，他才有得填。判据这件事必须在系统上线前做完，否则系统只是把模糊电子化了。

二、报了异常没下文，第二次他就不报了

巡检员发现异响，上报，然后没有然后。一周后设备坏了，追责时翻记录，发现他早就报过——但没人处理。

这种情况下他学到的不是「上报有用」，而是「上报会惹麻烦」。 下一次他会选择不报，或者在备注里写一句谁都不会注意的话。

三、考核方向错了，得到的是假数据

如果考核只看「巡检完成率」，那结果一定是 100%——因为点一下就算完成。如果考核只看「异常数量」，那大家会尽量少报。

更糟的是上线就开始考核。 系统还没跑顺、判据还在调整，这时候用考核施压，只会让所有人学会最快填完的办法，而不是认真巡检。

推行的顺序

• 先试点一条产线，跑两周，只收集问题不考核
• 让班组长参与定判据，他们有经验，也更清楚哪里不现实
• 第一个月只拿出一件事给管理层看：发现了几处以前会被漏掉的隐患
• 跑顺之后再纳入考核，且缺勤和异常要一起考，只考一边一定失真

什么情况下该承认推不动

如果试点两周后，一线提出的问题集中在「点位太多」「频次太高」，而不是「判据不清」，那说明设计本身超出了实际需要。这时候该做的是删点位、降频次，而不是加强考核。

最后

系统推不动，先别怪一线。 回头查三件事：判据写清楚了吗、异常有人接吗、考核是在逼数量还是在逼质量。这三件不解决，换一套系统也一样。