煤矿双重预防管理信息系统建设实践：从风险模型到隐患闭环

1. 为什么“双重预防”在煤矿现场总是流于形式1.1 风险辨识清单往往是“一次性”的在煤矿干过安全管理的人都有体会每年年初做风险辨识通常就是技术科牵头、组织几个老专家和科室负责人开半天会最后生成一份几十页的《年度风险辨识评估报告》。报告里风险点列得很全管控措施写得也很规范但这份报告盖完章以后基本上就存到档案室了。真正到了井下作业现场一线班组长和工人很少会去翻阅那本厚厚的报告他们更依赖自己的经验判断“这里有没有事”。问题就出在“静态”两个字上。煤矿生产条件是动态变化的采掘工作面在往前推进顶板条件在变瓦斯抽采效果在变大型设备检修状态在变。年初做的风险辨识清单到了年中可能已经和现场对不上了。比如采煤工作面回采到应力集中区原清单里依然是“一般风险”实际管控等级早该上调。但因为没有动态更新机制系统也好、台账也罢都只停留在一份固定清单的层面。我参与过的某次内部检查就发现某区队风险辨识表里的“主要风险点”还写着上一个工作面名称现场早就已经搬家倒面换到新区域了。这种情况不是个例。没有一套能把风险清单“用起来”的机制双重预防的第一重防线就是纸面文章。1.2 隐患排查整改闭环靠“人盯人”隐患排查治理是双重预防的第二重防线。很多矿井的日常做法是安全检查人员下井发现隐患记录在检查表上升井后把记录交给安全科安全科登记台账下发隐患整改通知单责任人签收后组织整改整改完毕找验收人签字最后月末汇总成一张闭环表。听起来流程没有缺失但实际执行中最大的痛点是“催办”。整改期限到了没有人主动提醒责任区队超期了安全科只能挨个打电话问。基层区队同时挂着好几个整改任务优先级靠自觉碰上生产任务紧张“整改超期”就成了家常便饭。到了月底统计为了报表好看就把隐患到期日往后顺延几天或者先“验收合格”再补录像资料。这种“纸面闭环”在实际矿井里相当普遍。1.3 数据上报到矿级时已经“变形”隐患数据从区队汇总到安全科再由安全科整理成周报、月报报给矿领导中间的统计口径经常不一致。同样是“皮带保护失效”在采煤队记录里算一般隐患到安全科汇总时可能被调整为较大隐患有的区队怕被考核会刻意把隐患等级往低报或者把隐患描述模糊化。结果矿领导看到的“隐患总数持续下降”很可能不是真实好转而是漏报和降级。这种信息损耗本质上是缺少一个统一的数据模型和强制流转规则。人工报表可以灵活调整灵活到一定程度就失真了。所以当时我们决定建设煤矿双重预防管理信息系统最核心的目标不是找一个软件来记录台账而是用数据模型把“风险—管控—隐患—整改”这条链串起来让每一个环节的变更都有迹可循、自动触发。2. 系统建设的第一步把风险清单变成能跑数据的模型2.1 风险点、危险源、管控措施怎么拆解系统要跑起来首先要解决“数据从哪来、怎么组织”的问题。我们最终确定的数据结构是把过去那份几十页报告拆成三层第一层是风险点对应一个具体的位置或对象比如“22101综采工作面”“主斜井皮带运输系统”“3503回风掘进巷道”。风险点必须有唯一编码后续隐患排查、整改统计都挂到这个编码下面。第二层是危险源指风险点上具体存在的可能引发事故的致因。比如“22101综采工作面”这个风险点上危险源可能是“顶板离层”“瓦斯超限”“设备转动部位防护缺失”“人员进入危险区域”。第三层是管控措施针对每个危险源列出应对手段。这一层要尽量具体到可操作不能写“加强管理”。比如对于“顶板离层”管控措施应该拆成“每班观察离层仪数值并记录”“当离层值超过阈值时停止作业并补打锚索”“每周检查支护质量一次”。同时每个管控措施要匹配管控层级班组级、区队级、矿级对应不同的检查频次。之所以这样拆是因为隐患排查的记录要能够“反查”到风险点。井下发现一条隐患比如“皮带急停拉线被复位”系统里应该能通过隐患类型关联回“主斜井皮带运输系统”这个风险点以及“皮带保护装置失效”这个危险源。如果风险清单只是一个平面的文本表格这一步反查根本做不了。2.2 管控责任如何落到具体岗位风险清单建好之后下一步是把管控措施和“人”绑定。很多系统在实施时都会遇到同一个问题管控措施写了“责任人班组长”但班组长是张三还是李四张三休班时谁来替他这个岗位今天管的是A工作面还是B工作面我的做法是先梳理组织架构和人员主数据把每个岗位对应到具体人员账号。然后建一张映射表风险点、管控层级、作业岗位三者关联。比如“22101综采工作面—顶板离层监测—生产班班长”系统就会把“每班查看离层仪并记录”这个任务自动推送给当天在岗的班长账号。这一步听起来简单实际工作量非常大。一个中型矿井风险点可能有几百个管控措施几千条逐条映射到岗位需要安全科和技术科反复校核。但它决定了系统能不能真正“用起来”有了人员绑定才有任务推送、超期预警和绩效统计。2.3 动态风险评估的实现思路风险分级不能一年只做一次。我们在系统里设计了一个动态评估规则管控措施的执行情况会反过来影响风险等级。比如某个风险点的“矿压监测”任务连续两次超期未完成系统自动把该风险点的风险等级从“较大风险”上调为“重大风险”并同步给安全科值班人员。动态升级不只是为了好看它直接影响排查频次重大风险点的排查由每周一次变为每天一次并自动生成新的排查任务。这样风险管控和隐患排查就真正联动起来了。具体实现上我用的是简单的规则引擎没有做复杂的机器学习模型。规则大体包括管控任务超期3次风险等级上调一级近一个月内同一危险源关联的隐患超过3条风险等级上调一级整改验收通过率达到100%持续两个月风险等级可以回调。关键是每个规则都要让现场人员理解规则太多太复杂反而没人信。3. 隐患排查治理模块从“签字确认”到“超期自动预警”3.1 排查任务怎么生成才不会被抵触双重预防系统最容易引起一线人员反感的地方就是“任务轰炸”。如果系统每天都给所有人都推十几条排查任务大家打开手机一看就烦最后只会变成乱点“已完成”。我们在设计任务生成规则时把握一个原则排查频次要和风险等级匹配人物要匹配到具体风险点。具体参数可以这样设置重大风险点每天排查一次较大风险点每三天一次一般风险点每周一次。系统根据每个风险点的“风险等级”和“管控措施”自动生成任务清单。比如采煤技术员收到的任务是“巡查22101工作面上下出口高度和支护状况”而不是“请完成今日排查”这种泛泛的提醒。另外要给区队留出“合并执行”的空间。一个班长同时负责三四个风险点如果系统机械地每个风险点各派一条任务他要来回切换。我们做了“任务合并”同区域、同时段、同一负责人可执行的排查任务合并成一条现场一次巡查就能覆盖。这样既保证了排查频次又不至于让任务清单变成负担。3.2 隐患等级与整改期限的联动逻辑隐患录入系统后首先是分级。我们在系统里统一了几个等级一般隐患、较大隐患、重大隐患。每一类对应的整改期限和审批流程不同隐患等级整改期限验收权限是否自动上报矿级一般隐患5个自然日区队安全员否较大隐患10个自然日安全科科长是重大隐患按专项方案矿总工程师是这一套参数在系统里可以直接配置。隐患到期前24小时系统推送消息给责任人和验收人超期未改的自动上报到上级主管账号同时在责任单位的月度风险指标里扣分。不需要安全科再去做“人肉催办”系统替代了这部分重复劳动。补一个实际经验整改期限不是拍脑袋写死的要考虑备件采购周期和作业条件。比如“井下中央变电所高压开关老化”需要更换备件备件采购需要15天给5天整改期限显然不合理。所以系统里要支持“申请延期”并设置审批流区队申请、安全科核实、同意后调整到期时间。但不能无限延期同一隐患最多两次延期否则自动升级为较大隐患。3.3 反查风险措施避免“改了又犯”隐患整改最怕什么最怕同一类问题反复出现。今天这个巷道的电缆挂钩掉了明天另一个巷道同样的问题又查出来。如果只盯着单个隐患整改永远在“亡羊补牢”。我们在系统里建立了“隐患类型—危险源—管控措施”的反查映射。某一条隐患录入时除了填写内容还要选择其对应的隐患类型和风险点。这样系统就能自动统计某个风险点下同一类隐患在30天内出现的次数。一旦超过设定的阈值系统会判定对应管控措施失效自动生成一条“管控措施修订”任务要求区队重新审视措施内容而不是继续同一套办法。举个例子某矿“井下防爆电气失爆”这类隐患反复出现系统反查到风险点“采区变电所”对应的危险源是“电气设备失爆”原本的管控措施是“每周检查一次”。因为反复触发系统提示管控措施修订为“每天开工前由电工班巡检并拍照留存”。这样一来隐患排查的成果就回流到了风险分级管控端真正实现“双重预防”的闭环。4. 实施中真正难的不是技术是现场习惯和网络环境4.1 一线人员不愿用APP的破解办法系统上线之前我认为最难的是数据库设计和权限配置上线之后才发现最难的是让四五十岁的老班长愿意拿出手机来点几下。他们不是学不会而是觉得“多此一举”过去填一张纸现在又要掏手机、打开App、找任务、拍照上传一套流程下来比原来慢。我们的解决办法不是强硬推行而是从简化操作和调整考核两方面下手。简化操作方面APP主界面只保留两个高频按钮“我的排查任务”和“隐患上报”。任务详情里风险点、隐患类型、整改建议都是下拉选择尽量减少打字。井下工人文化水平不一让手写描述不现实所以每个隐患类型都配上标准描述模板一键套用后稍作修改即可。调整考核方面上线第一个月不考核完成率只要求“用起来”第二个月开始考核“有效隐患上报数”而不是“任务完成数”。如果某个班连续一周零上报安全科会重点关注这个区域是否存在漏报而不是直接扣分。这样一来大家发现“多用系统隐患整改完确实不用再反复被电话催了”接受度慢慢就上来了。4.2 井下无网络环境的离线同步方案煤矿井下多数区域没有4G/5G信号这是系统实施时必须面对的现实条件。我们不可能要求工人在采煤工作面实时上传数据。如果系统设计成“必须在线才能用”下线率会极高。最后采用的方案是移动端本地缓存加断点同步。APP内置SQLite数据库所有任务数据在上一次有信号的时候提前下载到手机端工人在井下录入的排查记录、隐患照片先存在本地升井或者到达有信号的地方后点击“同步”按钮数据自动上传到服务器。同步最怕的是数据冲突。比如班长的任务在井下已完成但服务器上这个任务已被人修改状态。我们用了一个简单策略所有离线提交的数据都带“本地时间戳”和“任务版本号”提交时服务器校验版本号如果任务当前版本与本地不一致则该条记录标记为“待复核”由安全科人工确认不直接覆盖服务端状态。照片体积也要控制。井下拍的照片经常一张3到5MB上传慢我们统一做了压缩处理压缩到500KB以内画质满足隐患佐证即可。另外在防爆要求上使用的终端必须是本安型或隔爆型设备这部分成本不能省。4.3 历史纸质台账迁移的编码陷阱系统上线需要把以往几个月的纸质隐患排查台账导入作为历史数据。我们以为这是个简单的录入工作结果踩了坑。最大的坑是“同一个隐患多种叫法”。比如“电缆悬挂不标准”“电缆吊挂不规范”“电缆拖地未吊挂”这三条在纸质台账里可能被当作不同隐患实际属于同一个隐患类型“电缆吊挂不规范”。如果原样导入系统里的隐患类型会非常杂乱后续无法统计同类隐患反复出现的规律。我们的做法是先建一套“隐患编码字典”把常见隐患归纳成十大类、几十个子类每个子类规定标准描述模板和对应危险源。然后对历史台账逐条清洗先自动识别关键词归类再由安全科工作人员复核拿不准的到现场确认。整个清洗过程用了两周但这是值得的。如果不做这一步后面的隐患反查和风险联动全都会失效。另一个容易被忽略的问题是“历史隐患的整改状态”。纸质台账上写着“已整改”不一定真改完导入系统时如果直接把状态置为“已闭环”后续抽查时发现实际未改系统反而成了造假的帮凶。稳妥的办法是把历史数据全部标记为“历史遗留”导入后由安全科重新确认确认整改完毕再修改状态。5. 让管理层愿意打开系统的可视化报表设计5.1 矿领导关心的是“趋势”不是“数字”系统上线两个月后我发现一个尴尬现象在线率很高但矿领导几乎不主动打开系统。一问才知道领导觉得首页太“复杂”满屏的数字、列表、待办没有一个整体印象。于是我调整了首页设计思路。矿领导真正关心的是三件事今天整体安全态势怎么样、风险集中在哪个区域、有没有超期未改的重大隐患。不需要几百个明细数据。最终首页做成了“红黄绿”三色态势大屏左侧是风险分布热力图按采掘工作面、机电运输、通风瓦斯等系统分类颜色体现风险等级中间是近7日隐患趋势折线图附带隐患闭环率右侧是超期隐患TOP5列表每条只显示责任单位、隐患简述、超期天数。领导打开大屏十秒内能掌握全局这才是可视化该有的价值。5.2 风险指数模型怎么算才不唬人为了让领导有个更直观的“安全好不好”的判断我们设计了月度风险指数。这个指数不用复杂算法一定要让安全科的人能解释清楚否则会被当成“玄学”。我们用的线性模型是风险指数 风险点等级加权分 隐患整改及时分 − 超期扣分具体每个项的权重我在项目里跟安全科一起确定重大风险点数量占总风险点比例越高加权分越高隐患整改及时率达到95%以上得满分每低一个点扣分超期未整改的隐患按严重程度每条再附加扣分。指数范围映射到90、75、60、40几档对应“优秀、良好、一般、较差”。这样一个模型矿领导能看懂区队也能明白自己怎么做才能提升分数。它不是越复杂越先进能长期用起来才是有效的。5.3 红黑榜和考核如何避免失真每月系统自动生成各责任单位的安全绩效排名排名靠前的上红榜排名靠后的上黑榜。初衷是好但很快出现了反向操作某几个区队开始刻意少报隐患想着“只要查不到就不扣分”。应对办法是调整考核维度不再只看“整改及时率”单项而是引入“上报隐患数”和“隐患质量”双指标。如果一个单位上报隐患数量连续处于全矿末尾同时“零重大隐患”系统会自动标记为异常由安全科进行针对性现场核查。同时在月度红黑榜里增加一列“有效隐患上报数”让大家看到“上报不是扣分回避才是问题”。这个调整很重要。否则系统会奖励那些“看不见问题”的单位最后导致数据全面失真管理层也会逐渐失去对系统的信任。6. 运行一年之后的复盘哪些值得保留哪些该删减6.1 真正提升效率的三个功能系统运行一年后我们做过一次内部总结从一线使用反馈来看有三个功能评价最高。第一个是自动任务推送。风险管控任务和隐患排查任务到点自动到人基层不用每天去问“今天该查什么”。第二个是超期自动预警。以前催整改靠电话现在系统提前发消息、超期自动上报区队自己想拖都拖不住。第三个是台账自动汇总。安全科月底不再需要人工统计几十张Excel表系统里的各类记录一键导出极大减少了重复填报工作。这说明系统的核心价值不是“记录”而是“自动驱动”和“自动提醒”。凡是能把人工管理动作自动化替代的部分才是真正值得投资的部分。6.2 被滥用的“拍照打卡”和“填报负担”同时我们也发现了一些过度设计的反效果。早期为了让系统“留痕”我们要求每个排查任务必须拍照打卡一些区队为了图省事在井口照片墙前补拍各种角度的照片根本不下井。数据是齐了但过程是假的。后来我们把“必须拍照”改成了“按风险类型选择性拍照”只有涉及设备保护、瓦斯、顶板、密闭等高风险检查项才强制拍照一般性巡查只做勾选记录。上线后补拍现象大幅减少数据真实性反而提高了。另一个被反馈为“负担”的功能是每日安全播报。系统每天早上给所有人推送一条安全提醒出发点是好的但内容高度重复很快就变成“免打扰”对象。我们删掉了这类无关紧要的消息推送只保留与本人任务、风险变更、隐患超期相关的消息。6.3 我对后续迭代的三个建议复盘之后如果让我重新做这套煤矿双重预防管理信息系统我会在三个方向重点改进。一是把系统与矿井已有的监测监控数据打通。瓦斯传感器、顶板压力监测、水文监测这些实时数据目前和双重预防系统是割裂的。如果风险等级能自动结合实时监测值动态调整预防的“预”字才能落到实处。二是增加隐患排查的“正向激励”。现在的考核逻辑偏惩戒催生了不少防御性填报。可以尝试月度隐患上报质量积分积分可用于安全评优或兑换劳保用品让一线人员从“要我报”变成“我要报”。三是定期做数据质量审计。运行一年后系统里沉淀了不少从未关联过任务的僵尸风险点和长期无人认领的管控措施。每季度安排安全科集中核查一次清理无效数据保持模型和现场同步。我在实际使用中还有一个体会别在系统上线第一天就上全模块。二十几个模块同时铺开所有部门都在面对新流程问题会像雪球一样滚起来。比较稳妥的方式是先把风险库和隐患闭环跑顺一两个月的稳定运行后再上报表、考核、大屏这类强化功能。系统是越大越容易翻车越小越容易落地。如果能把“最小可用闭环”想清楚再一点一点往外扩展这套系统才能真正从“线上台账”变成矿上离不开的安全管理工具。后续遇到具体问题欢迎同行多交流我也还在摸索的路上。