政务问题工单系统：一张工单的生命周期
政务问题工单系统：提出→审批→分配→处理→确认，一条不能断的状态链
文章目录
- 政务问题工单系统：提出→审批→分配→处理→确认，一条不能断的状态链
- 一、问题
- 二、全流程：五段状态链
- 提出申请
- 申请审批
- 需求分配
- 需求处理
- 需求确认
- 三、接入海政通
- 四、决策支持：工单不是做完就完了
- 五、跟已有工作流文章的关系
- 六、总结
政务问题的处理不能靠微信群。需要一个系统，让每一张工单都有来处、有去处、有回头。
一、问题
一个省社保局每天收到几百个问题——窗口上报的、基层反映的、群众投诉的、上级交办的。没有系统的时候，靠 Excel + 微信群。催办靠吼，升级靠领导拍桌子，年底算账时谁也说不清楚哪个问题从哪来、谁在处理、处理了多久。
需要一个工单系统。不是抄 JIRA 那种 IT 工单。是政务场景的问题全生命周期管理。
二、全流程：五段状态链
提出申请 → 申请审批 → 需求分配 → 需求处理 → 需求确认 │ │ └──────── 任意节点可退回上一环节 ────────────────────────┘提出申请
谁都能提——窗口人员、基层社保所、12345 热线转办。提的时候填：问题来源、问题类型、问题描述、紧急程度、期望解决时间。
关键设计：问题来源和问题类型在申请时必填。这是后续统计分类的基础。不填不能提交。
申请审批
提交后，上级审批人能选择：
- 通过→ 推进到分配环节
- 退回→ 退回给申请人修改或补充
- 拒绝→ 关闭（但保留记录）
退回时审批人必须写退回原因。否则申请人不知道改什么。
需求分配
审批通过后，分配人把工单派给具体科室或具体人。支持：
- 指派到科室（科室负责人再往下分）
- 指派到具体人
- 指派到多人（协办）
被派到的人收到通知（系统消息 + 短信）。
需求处理
处理人开始处理后，工单状态变为"处理中"。处理完成后填写：
- 处理结果
- 处理耗时
- 是否需要反馈给申请人
如果处理后发现问题不在自己职责范围，可以退回重新分配——不是甩锅，是政务问题经常牵扯多个部门，第一次分配不准很正常。
需求确认
处理完成后，回到最初审批人做闭环确认：
- 确认问题已解决 → 工单关闭
- 不确认 → 退回处理人补充
不是处理人自己说"解决了"就完了。当初谁审批的，谁来确认解决。审批和确认是同一个人，形成闭环。
三、接入海政通
工单系统接入了省级政务协同平台（海政通）。领导在手机上就能审批、分配、督办。不用坐在电脑前。
接入后带来的变化：
- 审批人手机收到待办通知 → 点进去审批 → 工单状态自动更新
- 处理人手机收到派单 → 开始处理 → 系统自动计时
- 督办人手机看报表 → 哪个科室在拖，一眼看到
四、决策支持：工单不是做完就完了
工单积累了数据，数据要拿出来用：
| 分析维度 | 看什么 |
|---|---|
| 问题汇总分析 | 哪个类型的问题最多？哪个地区的投诉最多？ |
| 问题处理时长分析 | 哪个科室处理最慢？哪类问题超期最多？ |
| 满意度分析 | 群众对处理结果满不满意？ |
| 督办情况分析 | 催了多少次才解决？ |
| 分类问题统计排名 | 科室排名、市县排名、类型排名 |
这些报表不是年底总结用的。是每月看一次，看哪个环节堵了。处理时长突然拉长了 → 可能是人员变动。某类问题突然爆发了 → 可能是新政策上线引发的。
五、跟已有工作流文章的关系
你看这条流程：
提出 → 审批 → 分配 → 处理 → 确认就是你工作流系列里的 Activiti 审批流程。但这里用的是自研业务表 + 状态字段，没有走 BPMN。原因：
- 工单的流程是固定的——就是这五步，中间只是"退回"这一种异常分支。不需要 BPMN 那样灵活的跳转。
- 纯状态字段 + 更新人 + 更新时间——查询比 Activiti 的运行时表快两个数量级。
- 统计报表直接 SQL 查业务表，不需要 JOIN Activiti 的历史表。
你前面写的"数据库配拦截器，不用改 BPMN"那篇，本质也是这个思路：不是所有流程都值得上 BPMN。固定流程用状态字段，简单、快、好查。
六、总结
一个政务工单系统，功能不复杂。真正花时间的是想清楚每个状态下允许哪些操作、禁止哪些操作。
比如：
- 申请审批时不能直接跳到处理——必须经过分配
- 处理完成不能自己确认——必须回到审批人
- 退回必须写原因——不能一句话不说就退
这些规则写在代码里就是几行if。但想清楚要花几天——跟业务科长坐在一起一个一个场景推。
工单系统本质上就是一个问责系统。每一张工单记录了：谁提的、谁批的、谁做的、做了多久、结果怎样。这些数据不是为了绩效考核。是为了哪天出了事，能翻出来看"这件事是怎么处理的"。