
2026-10-27 10:23:00 -
纸质点检亏在三笔账:记录晚半天、签名证明不了人到过现场、故障时找不到人和历史。搬到手机上按扫码到点、拍照留证、异常派单三步配置。本文给出任务状态流转、六类必须上线的点检数据、数值与照片的校验规则,以及两周试点要看的三个数。
纸质点检亏在三笔账:记录晚半天、签名证明不了人到过现场、故障时找不到人和历史。搬到手机上按扫码到点、拍照留证、异常派单三步配置。本文给出任务状态流转、六类必须上线的点检数据、数值与照片的校验规则,以及两周试点要看的三个数。
头一笔是时间。记录晚半天,异常也跟着晚半天。夜班发现的问题,等第二天录入系统,白天的人已经换过一轮。
第二笔是真实性。人到没到现场,一个签名说明不了。本子上的勾打满,不代表每一台设备都走过去看过。
第三笔是找人。设备出了故障,还得到处打电话,问这台归谁管、谁巡检过、上一次的记录在哪。
| 步骤 | 现场动作 | 系统里留下什么 | 顶掉了什么问题 |
|---|---|---|---|
| 扫码到点 | 每台设备贴一个码,扫了才能填 | 扫码时间、设备编号、巡检人 | 没到现场也能填 |
| 拍照留证 | 异常点随手拍一张 | 照片带时间和位置水印 | 事后说不清当时状态 |
| 异常派单 | 手机上提交异常 | 工单推给维修负责人,修完拍照销单 | 靠打电话找人 |
这三步在 Dolphin Code 低代码平台上配置,员工用手机就能跑。现有的点检项、判定标准、巡检路线照原样录进平台,纸面上的内容一条不丢,巡检员要学的只是扫码和拍照。
流程走向:
两条边界要看紧。S1 到 S2 之间必须有校验,扫的不是自己路线上的设备就不能填;S2 到 S4 之间必须靠数值判定触发,靠人在备注里写"有点漏油",异常照样传不出去。
| 内容 | 为什么要进系统 | 谁维护 |
|---|---|---|
| 设备编号与二维码 | 扫码定位到具体那一台 | 设备部 |
| 点检项与判定标准 | 手机上按标准填数值,超出范围当场提示 | 设备部或工艺 |
| 巡检路线与频次 | 按班次生成任务,漏检直接看得见 | 车间 |
| 异常类别 | 派单按类别路由到不同的人 | 设备部 |
| 拍照要求 | 哪些点必须留照片,写成规则 | 质量或安全岗 |
| 历史记录 | 故障分析和备件计划都要用 | 系统自动留存 |
这一步最容易省事的地方,是把纸质表格原样电子化:还是让人在手机上打勾,数值不填、照片不拍。那样只是把纸换了个地方存,异常照样传不出去。关键项至少要填数值,比如油位、温度、振动值,填了数值才有趋势可看。
| 校验点 | 规则 | 提示文案 |
|---|---|---|
| 扫码 | 设备码必须在该任务的巡检路线内 | 该设备不在你的巡检路线上 |
| 数值 | 按点检项的单位与上下限判定 | 温度 86℃ 超出上限 80℃,请填写异常类别 |
| 照片 | 异常记录至少 1 张,正常记录可不传 | 异常记录需要现场照片 |
| 时间 | 以服务器时间落库,客户端时间不可覆盖 | 时间以提交时服务器时间为准 |
| 水印 | 照片写入时间、位置、巡检人 | 拍照组件自动叠加 |
CREATE TABLE inspect_record (
record_id BIGINT PRIMARY KEY,
task_id BIGINT NOT NULL, -- 由巡检计划按班次生成
device_code VARCHAR(64) NOT NULL, -- 扫码得到,不由人填
item_code VARCHAR(64) NOT NULL, -- 点检项,如 OIL_LEVEL / TEMP
measured_value DECIMAL(12,3), -- 数值项必填
unit VARCHAR(16),
judge_result VARCHAR(16) NOT NULL, -- PASS / NG
exception_type VARCHAR(64), -- NG 时必填,决定派单路由
scanned_at DATETIME NOT NULL,
scanned_by VARCHAR(64) NOT NULL
);
CREATE TABLE inspect_photo (
photo_id BIGINT PRIMARY KEY,
record_id BIGINT NOT NULL,
object_key VARCHAR(256) NOT NULL,
taken_at DATETIME NOT NULL,
lng DECIMAL(10,6),
lat DECIMAL(10,6)
);
得帆官网的汽车行业方案里写着,车间无纸化应用的周期从 4 到 6 个月缩短到 1 个月。这句讲的是应用搭建周期,不是巡检本身省下的时间。巡检省下来的是另外两笔:纸面录入占用的人力,异常传递的延迟。这两笔在每个车间每个月都会重复发生,累积起来比搭建周期更容易看见。
挑一台关键设备所在的工位起步。这类工位的点检项最多,从纸面改成电子,收益一眼能量出来。它出故障影响大,派单到销单这条链路一跑就知道通不通。一线班组对这种设备本来就上心,配置有不顺手的地方,当天就会指出。
试点看三个数,两周就够:漏检率降了多少,异常从发现到派单过了多久,纸面录入还需要几个人。三个数都在往好的方向走,再往其他车间复制。
一般不补。三年的纸质点检记录逐张录进系统,人力成本高,录出来的东西还常常缺项、无法比对。历史数据的价值在趋势,从上线那天开始攒,三个月就有能看的东西。
两种情况例外。一台设备反复出现同一类故障,那几条纸质记录值得录进去,用来确认是不是老问题;另一类是有监管或审核要求的行业,记录必须连续,缺一段会被追问,这种就把范围限定在涉及的那几台设备上,别扩展到全车间。
移动:能不能不在办公室就完成填报和查询。取证:现场情况需不需要照片和时间来证明。时效:异常晚半天会不会造成实际损失。防作弊:光靠签名够不够证明人到了。
四条里占两条就适合搬上手机,全中的场景先做。做之前把现在这套点检表的版本号、修订日期和责任人定下来,否则线上只是把一摊乱数据换了个地方存。
得帆智能成立于 2014 年,目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程,配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统,应用上线后由平台统一承接权限、审计与版本管理。
说明:本文由得帆智能整理发布,文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理,仅作行业交流,不构成采购建议;文中表结构与代码均为示意,实际字段以各平台元数据规范为准。
猜你喜欢