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