012_鲁南某区县级矿山安全监测系统信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

本文围绕我于 2022 年 1 月至 10 月主持建设的鲁南某区县级矿山安全监测系统，回答题目提出的三个问题。该项目由当地应急管理主管部门发起，合同额 920.12 万元，工期 10 个月，团队 15 人，接入辖区 23 座非煤矿山的 1160 个传感测点。项目的特殊之处在于外部厂商多、国产化适配要求刚性、监测数据一旦延误就可能酿成安全事故，因而沟通链条的可靠性直接决定项目成败。文中先交代项目概况与本人职责，再说明沟通管理的三个过程在本项目的落地情况，随后单独回答干系人管理的四个过程并给出本项目实际使用的干系人管理计划，最后总结成效与体会。项目结项后系统可用率稳定在 99.9% 以上，人工重复录入工作量下降 68%。

一、我管理的是一个什么项目，在其中承担了什么工作

鲁南某区县辖区内有非煤矿山 23 座，其中地下开采 9 座，从业人员约 2700 人。此前的安全监管依靠人工巡检加纸质台账，矿压、瓦斯、粉尘等数据由矿方每日电话或传真上报，区局再手工汇总，一份周报要三个人录两天，隐患信息从发现到抵达监管人员平均需要 6 小时以上。2021 年下半年的一次省级检查中，这套做法被明确指出无法满足实时监测要求。

2022 年 1 月，当地应急管理主管部门以安全生产专项资金立项，建设矿山安全监测系统，合同额 920.12 万元，工期 10 个月，2022 年 10 月完成验收并移交运行。项目内容包括：在 23 座矿山部署矿压、瓦斯、粉尘、人员定位四类传感器共 1160 个测点，通过 MQTT 网关接入；建设区局监测中心与市局灾备中心的多活容灾架构；开发实时监测、预警推送、隐患闭环、统计分析四个业务子系统和一块指挥大屏。

技术上，后端采用 Java 8 与 Spring Cloud 微服务，通过服务网格 Istio 实现服务治理与灰度发布；前端使用 Vue 2 配合 ECharts 构建监测大屏与业务界面；数据库为 GaussDB，配合分布式缓存承载高频遥测数据；操作系统与中间件按国产化替代要求分别选用麒麟操作系统与国产应用服务器，整套技术栈须整体适配，不能只换数据库。

团队 15 人：我任项目经理，负责总体计划、采购与外部协调；开发 6 人，测试 2 人，实施与现场安装 3 人，数据与算法 2 人，另有 1 名专职资料员。外部还涉及 3 家传感器厂商、1 家通信线路服务商和 1 家监理单位。

我在项目中承担项目经理职责，除进度、成本和质量之外，投入精力最多的就是沟通管理——因为本项目真正的风险不在代码，而在于矿方、厂商、区局、市局四方的信息能不能对上。

二、项目沟通管理包含哪些过程，本项目是怎么落地的

所谓项目沟通管理，指的是为确保项目信息及时、正确地产生、收集、分发、存储和最终处置所需的各个过程，包括规划沟通管理、管理沟通和监督沟通三个过程。本项目对这三个过程的落地如下。

规划沟通管理阶段，我组织需求组用问卷和访谈两种方式识别干系人，形成登记册。与一般政务项目不同的是，本项目的干系人里有一类特别关键——矿方的安全员。他们既是数据源头，又是隐患整改的执行人，但既不归区局管，也不受项目合同约束。我为此在沟通管理计划里单列了一层 " 矿方通道 "，约定由区局安监科出面、以监管例会的名义组织，而不是由项目组直接对接，这样才具备约束力。计划中同时明确了四类信息的时效要求：预警信息秒级推送，隐患整改 48 小时闭环，进度信息每周同步，重大变更书面确认。

管理沟通阶段，最费力的是与三家传感器厂商的协同。三家厂商的设备协议、数据精度和交付节奏都不一致，集成测试前三轮全部失败。我把每次失败的现象、根因和责任方都记入《集成问题台账》，到 8 月共累计 217 条沟通类问题记录。用帕累托图对这 217 条按原因分类后，结果很清楚：接口文档版本不一致占 43%，变更通知未闭环占 33%，两项合计 76%，其余 5 类原因合计仅 24%。据此我们只做了两件事：一是设立文档基线，所有接口文档统一编号入库，厂商现场调试前必须核对版本号，用旧版文档产生的返工由厂商自行承担；二是把变更通知改为 " 发出—确认—验证 " 三步闭环，未收到确认回执的变更视为未生效。两项措施实施后的一个月内，同类问题从月均 37 条降至 6 条。

管理沟通中我还借用了质量审计这一手段。8 月中旬，我会同监理单位对三家厂商开展了一次联合审计，审计范围不只是设备质量，同时核查沟通过程的合规性：周报是否按约定提交、变更是否走了书面流程、问题是否在台账中留痕。审计共开出不符合项 11 项，其中沟通过程类占 4 项，全部限期两周内整改完毕。把沟通合规纳入审计清单，比反复口头强调有效得多。

监督沟通阶段，我关心的是 " 信息是否真的被正确接收 "，而不是 " 信息是否发出 "。为此在试运行期采用统计抽样的办法做验证：从 1160 个测点中按 10% 比例抽取 118 个，核对现场读数与平台展示、与推送到矿方安全员手机上的告警内容三者是否一致，抽样共发现不一致 9 处，其中 7 处是单位换算错误，2 处是告警短信被运营商拦截。同时对 23 座矿山的安全员和区局 6 名监管人员做了满意度回访，识别出 " 预警短信内容过长、关键信息在末尾 " 这一共性反馈，随即把短信模板改为矿名、测点、超限值前置。

三、干系人管理包含哪些过程，本项目的干系人管理计划是怎样的

所谓项目干系人管理，指的是识别能影响项目或受项目影响的人员与组织，分析其期望与影响，并制定策略以促进其有效参与的一系列过程，包括识别干系人、规划干系人参与、管理干系人参与和监督干系人参与四个过程。

识别干系人时，我们通过组织结构分析、专家判断和一对一访谈，共识别出干系人群体 8 类、具名联系人 47 人，逐一记录其在项目中的角色、期望、影响力与态度。规划干系人参与时，用干系人参与度评估矩阵标出当前与期望参与度，并与前述沟通管理计划做了对应，确保每一类干系人都有明确的信息通道。管理干系人参与阶段处理了本项目最棘手的一件事：3 座民营矿山的负责人明确抵制安装人员定位设备，理由是 " 监控矿工位置侵犯隐私、影响出勤统计 "。我请区局安监科牵头，组织这 3 家矿主到已完成试点的国有矿山现场参观，重点看事故追溯演示，同时在系统中把人员定位数据的查询权限限定为 " 仅事故与应急状态下开放 "，并将该约定写入运行管理办法。三方沟通两轮后，3 座矿山均同意安装。监督干系人参与阶段，每月更新参与度矩阵和问题日志，全程更新 8 轮，态度发生变化的干系人共 5 人。

本项目实际使用的干系人管理计划主要内容如下（C 为当前参与度，D 为期望参与度）。

干系人	分类	C	D	主要诉求	参与与沟通策略
区应急管理局分管领导	重点管理	支持	领导	按期通过省级验收	月度专题汇报，重大问题当日直报
区局安监科	重点管理	中立	支持	隐患闭环可追溯	联合主持监管例会，需求评审签字确认
市局灾备与运维单位	令其满意	中立	中立	容灾切换可靠、后续可运维	阶段性联调通报，运维手册联合评审
国有矿山安全员	随时告知	支持	支持	告警准确、少误报	现场培训 + 告警回执，误报当日反馈
民营矿山负责人	随时告知	抵制	中立	隐私顾虑、成本负担	现场观摩，权限边界写入管理办法
3 家传感器厂商	监督	中立	支持	付款节点、验收口径	周联调例会，文档基线 + 变更三步闭环
通信线路服务商	监督	中立	中立	施工窗口	双周排期会，书面确认施工计划
监理单位	令其满意	支持	支持	过程资料完整	参与质量审计，资料同步归档

四、项目结果如何，我从中得到了什么体会

2022 年 10 月，项目通过验收并投入运行。1160 个测点全部接入，预警信息推送时延由原先的 6 小时以上缩短到秒级；周报、台账等重复录入工作量下降 68%；矿山现场的人工巡检投入下降 60%，巡检人员转为处理系统推送的重点隐患；运行首年系统可用率稳定在 99.9% 以上，未发生重大故障，一次省级抽查中被列为区县级示范案例。

第一点体会是，沟通管理不能停在 " 发出去了 "。本项目用统计抽样核对现场读数、平台展示与告警短信三者的一致性，才发现了单位换算错误和短信被拦截这两类问题——如果只看发送日志，这些问题会一直潜伏到出事那天。

第二点体会是，沟通问题要用数据来定位，而不是凭印象。217 条问题记录做成帕累托图之后，主要矛盾一目了然，两条措施就压掉了七成以上的返工。这也说明质量管理中的工具完全可以用在沟通管理上，知识领域之间本来就不该有墙。

第三点体会是，沟通管理与采购管理、质量管理、风险管理是咬合在一起的。本项目厂商多、交付质量参差，属于典型的采购风险；但它最终是通过文档基线、变更闭环和联合质量审计这几项沟通与质量手段消解的。反过来说，如果只在合同里写罚则而不在过程中把信息通道理顺，罚款拿到手，工期也误了。

第四点体会是，对抵制型干系人，硬压往往适得其反。3 位民营矿主的顾虑是真实的，让他们去现场看一次事故追溯，再把权限边界白纸黑字写进管理办法，比开十次会都管用。这条经验我在后续项目中一直沿用。