019_皖南某地市级工伤认定管理系统信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

2024 年 4 月至 2025 年 4 月，我担任项目经理完成了皖南某地市级工伤认定管理系统的建设。项目由当地人力资源和社会保障主管部门发起，合同额 226.08 万元，工期 12 个月，团队 18 人，服务全市 3.2 万家参保单位、年均 4600 件工伤认定申请。这个项目真正的压力来自三处：可用于新旧系统切换的窗口极为有限、办理高峰时段的并发压力大、基层终端型号繁杂导致适配工作量被严重低估。本文以这三个难点为纲，逐一说明我如何借助沟通管理的三个过程与标杆对照、控制图、因果图三种手段加以化解，并单列一节交代干系人管理过程和本项目的干系人管理计划。项目结项时平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，用户满意度测评由 78 分提升至 94 分。

一、项目概况与我承担的工作

皖南某地市共有参保单位 3.2 万家，参保职工约 86 万人，年工伤认定申请 4600 件左右，劳动能力鉴定 3100 人次。项目启动前，工伤认定、劳动能力鉴定、待遇支付三段业务由三套彼此独立的系统承担，且都未与省级系统打通。用人单位申报一次工伤，材料要在三处分别提交，职工家属往往要跑三趟窗口；认定环节需要的参保记录、医疗票据、事故调查材料靠人工核对；系统内一份材料平均被录入 2.8 次。

2024 年 3 月立项，4 月启动建设，合同额 226.08 万元，工期 12 个月，2025 年 4 月通过验收。系统交付内容包括：网上申报与材料预审、工伤认定办理、劳动能力鉴定预约与结论管理、待遇核定与支付对接、统计分析，以及与省级人社系统、医保结算系统、法院与仲裁机构数据的接口。

技术上，申报表单与认定流程通过低代码平台配置，以适应政策条款调整；后端为 Java 与 Spring Boot 微服务，经微服务网关统一鉴权、限流与灰度；数据层选用 OceanBase 承载认定与鉴定主库；与省级系统、医保系统之间的数据交换通过 RocketMQ 异步完成；申报端为网页与微信小程序双入口，经办端适配窗口一体机与办公电脑。

团队 18 人：我任项目经理；业务组 3 人，其中 2 人从认定科抽调；开发 9 人；测试 2 人；实施与培训 4 人。

项目沟通管理是确保项目信息及时、正确地产生、收集、分发、存储和最终处置的过程。这句话在本项目中的分量，要从下面三道难关说起。

二、难点一：割接窗口极短，六方却各有各的时间表

工伤认定业务的特殊性在于，法律对认定时限有明确规定，业务一天都不能停；而系统割接需要新旧数据一致性校验、省级接口切换、窗口终端配置更新三项同时完成。经过测算，唯一可用的窗口是周六凌晨 0 点至次日 6 点，共 6 小时。参与方却有六个：我方项目组、省级系统运维单位、医保系统运维单位、机房托管方、窗口经办科室、短信网关服务商。第一次演练时问题就暴露了——各方各自按自己的节奏准备，省级接口在凌晨 1 点才有人到岗，而数据校验早在 0 点 40 分就完成了，白白等掉 40 分钟。

这本质上是规划沟通管理没有做到位。我采取的第一个动作是标杆对照。省内已有两个地市完成过同类切换，我带实施组分别去待了一天，重点问的不是技术方案而是 " 你们那晚是怎么调度的 "。其中一个市的做法给了我直接的启发：他们把割接夜分成若干个 15 分钟的时间格，每格标明谁在做什么、谁在等待、谁可以休息，所有人手里拿的是同一张表，到点对表。

据此我们编制了《割接夜对表调度表》，把 6 小时切成 24 格，逐格明确六方各自的动作、前置条件、完成标志和责任人电话，并约定每格结束时由我在语音通道里点名确认。同时明确了三个关键判定时点：凌晨 2 点若数据校验未通过则启动回退；凌晨 4 点若省级接口未联通则降级为离线受理；凌晨 5 点 30 分为最终决策点。这三个时点写在调度表最显眼的位置，六方都清楚在什么情况下会发生什么。

正式割接当晚，实际用时 4 小时 52 分完成全部切换，比计划提前 1 小时 08 分。周一开门时窗口业务正常受理，未出现一起因系统原因办不了的情况。

三、难点二：办理高峰的性能压力，各方对 " 快 " 的理解并不一致

第二道难关出现在联调后期。业务科室反复强调 " 高峰期不能卡 "，开发组则认为性能已经达标，两边都很坚持，但谁也说不出一个数。追问下去才发现，业务科室说的 " 卡 "，指的是每月月初集中申报时窗口一体机上点击提交后转圈超过 5 秒；而开发组测的是服务端接口响应时间，平均只有 0.3 秒——两者测的根本不是一回事。

这是典型的管理沟通问题：信息在传递过程中因为缺少共同的度量单位而失真。我做的第一件事是把模糊的要求转成可测的指标，与业务科室逐条确认后写进沟通口径：高峰并发 2000 用户在线，申报提交端到端 P95 响应时间不超过 1.5 秒，认定查询 P95 不超过 1.0 秒，失败率低于 0.1%。这里的关键是 " 端到端 " 三个字——从用户点击到页面反馈，包含网络与前端渲染，而不只是服务端接口。

第二件事是让指标的变化持续可见。测试组从 2024 年 11 月起每日执行一轮回归压测，把申报提交的 P95 响应时间打成控制图，中心线取 1.0 秒，上控制限按 1.5 秒设定，图表每日早上随晨报发送给业务科室、开发组和分管领导。这张图起到了两个作用：一是让所有人对性能状况有同一个认知，不再靠感觉争论；二是异常能被及时捕捉。2025 年 1 月中旬，控制图上连续 5 个点呈上升趋势并接近上限，虽然尚未越界，但趋势明显异常。排查发现是新上线的材料预审功能在提交时同步调用了外部票据核验接口，把外部依赖串进了主链路。开发组随即改为异步核验加结果回填，曲线两天内回落到 0.7 秒附近并持续受控。若等到用户投诉再查，这个问题很可能会在 3 月申报高峰时集中爆发。

四、难点三：终端型号繁杂，返工信息在窗口与开发之间被磨平

第三道难关贯穿整个实施期。全市窗口与基层服务网点在用的终端来自六个采购批次，操作系统与浏览器内核跨度极大，还有部分一体机带手写板与身份证读卡器等外设。适配缺陷持续不断，但窗口反馈到项目组时，往往只剩 " 读卡器不好使 " 这一句，开发组反复到现场也复现不出来。到 2024 年 9 月，兼容性适配的累计工时已经是估算值的 2.4 倍，进度开始吃紧。

我组织窗口经办员代表、实施组和开发组开了一次专题分析会，用因果图围绕 " 终端适配返工居高不下 " 这一结果展开：人员方面，经办员反馈时不带型号与错误信息，且不同网点的表述习惯差别很大；设备方面，六个批次的读卡器驱动版本不统一，部分驱动已停止维护；材料方面，需求文档只写了 " 支持主流终端 "，没有列出型号清单；方法方面，缺陷提报没有模板，全靠口头或电话；环境方面，部分网点为保证稳定禁用了系统自动更新，浏览器停留在很老的版本。

逐条验证后确认三条主因：没有型号清单、缺陷提报无模板、驱动版本失控。措施相应有三：一是用两周时间完成全市终端普查，形成含批次、型号、系统版本、外设清单的台账，共登记终端 417 台，并据此明确适配范围，超出清单的终端由使用单位自行更换；二是在系统里嵌入一键提报功能，自动带出终端型号、系统版本、驱动版本与错误堆栈，经办员只需补一句现象；三是统一发布经过验证的驱动安装包，由实施组集中远程部署。措施落地后的两个月内，适配类缺陷由月均 63 件降至 9 件，剩余适配工作在 2025 年 1 月按期收口。

五、干系人管理过程与本项目的干系人管理计划

干系人管理包含识别干系人、规划干系人参与、管理干系人参与与监督干系人参与四个过程。本项目共识别干系人群体 8 类、具名联系人 52 人。

管理干系人参与阶段最需要下功夫的是市劳动能力鉴定委员会办公室。该单位初期为不支持状态，担心鉴定预约上线后专家排班被系统固化，遇到专家临时有事无法灵活调整，反而增加纠纷。我请其主任参加了两次需求评审，并在系统中增设了 " 人工干预排班 " 入口与改期短信自动通知功能，同时把改期原因纳入留痕。第二次评审后其态度转为支持，并主动提出把鉴定结论送达也纳入系统，这项后来成了群众满意度提升最明显的一环。

干系人	分类	当前/期望参与度	主要诉求	参与与沟通策略
市人社局分管领导	重点管理	支持/领导	按期上线、零事故	月度汇报，割接等重大节点当面报告
工伤保险科、认定科	重点管理	中立/支持	法定时限、办件质量	需求评审签字，性能指标共同确认
市劳动能力鉴定委办	令其满意	不支持/支持	排班灵活、责任清晰	参与评审，保留人工干预入口
市医保局	令其满意	中立/中立	接口安全、数据边界	接口方案联合评审，书面确认单
窗口与基层网点经办员	随时告知	中立/支持	终端好用、少折腾	一键提报，驱动统一部署，分批培训
用人单位与工伤职工	随时告知	不知晓/中立	少跑腿、进度可查	申报节点短信告知，办事指南前置
省级系统运维单位	令其满意	中立/中立	割接不影响省级	对表调度表，割接夜专人值守
短信网关等服务商	监督	中立/中立	排期与结算	周例会，书面确认单

六、结项成效与体会

2025 年 4 月项目通过验收。三段业务打通为一条链，材料一次提交全程复用，人工重复录入工作量下降 68%；平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日；用户满意度测评由 78 分提升至 94 分；系统上线后连续运行未发生因性能原因导致的业务中断。

三点体会。第一，沟通计划要细到 " 什么时候谁做什么 " 这一层才管用。割接夜的 24 格对表调度表本身没有任何技术含量，但它把六方的动作放进了同一条时间线，这是任何一次动员会都换不来的。第二，模糊的表述是沟通的最大敌人。" 不能卡 " 和 "P95 不超过 1.5 秒 " 表达的是同一个诉求，但只有后者能被验证、被监控、被追责。把要求量化，本身就是最重要的一项沟通工作。第三，沟通管理与质量管理、进度管理是连在一起的。控制图和因果图原本属于质量管理的工具箱，但在本项目里，它们真正的作用是给争执不下的各方提供了一个共同的事实基础；而适配返工若不追到根因，吃掉的必然是工期。这些做法我已经沉淀成模板，用在了本单位后续的社保经办系统改造中。