政务督办的分合模式：主办协办的并发审批

政务督办的分合模式：主办+协办，办结前必须主办点头

文章目录

政务督办的分合模式：主办+协办，办结前必须主办点头

不是简单的"A派给B"。是主办能把任务拆成多个协办，协办做完主办再审批。

一、场景

领导批示："请社保局牵头，税务局、民政局配合，一个月内解决困难群众参保问题。"

这就不是一张工单能搞定的了。

社保局是主办，税务局和民政局是协办。主办负责整体推进，协办各自完成自己的任务。协办做完，主办审批通过才算完成。主办说"不行，再补充"，协办就得再干。

二、完整链路

复制代码

录入督办表单
    │
    ▼
领导审批 → 不通过 → 退回修改
    │
    ▼ 通过
发起主办事项 ←──┐
    │            │
    ▼            │
督办分发       │（主办审批不通过，打回）
    │            │
    ├──→ 完成督办任务（主办自己的活）
    │
    └──→ 发起协办事项
            │
            ▼
         协办分发（分给税务局、民政局等）
            │
            ▼
         完成协办任务
            │
            ▼
         主办审批 ──→ 通过 → 领导复核 → 办结
            │
            └──→ 不通过 → 退回协办 → 循环

三、主办和协办的权限边界

	主办	协办
能看到什么	全部督办事项 + 全部协办任务	只看自己名下的协办任务
能做什么	分发、审批、退回	完成任务、查看任务
能决定什么	协办结果是否通过	自己的任务是否完成
依赖性	所有协办完了才能申请办结	被主办审批，被主办退回

主办是一个责任节点，不是行政级别。不管主办单位是不是比协办级别高，在系统里主办对协办的结果有否决权。这个设计避免了"协办做了、主办不知道、最后出事了谁都不认"的扯皮。

伪代码实现：

复制代码

// 创建督办任务
function 创建督办(表单信息, 主办单位, 协办单位列表):
    task = INSERT INTO 督办事项(标题, 内容, 状态='待审批')
    
    // 领导审批
    审批人 = 获取审批人(主办单位)
    通知(审批人, "新的督办事项待审批: " + task.标题)

// 领导审批通过后，主办开始拆任务
function 发起主办事项(督办ID):
    task = SELECT * FROM 督办事项 WHERE ID=督办ID
    if task.状态 != '已审批': return error("未审批")
    
    task.状态 = '主办执行中'
    INSERT INTO 主办任务(督办ID, 主办单位=task.主办单位, 状态='处理中')

// 主办向多个协办单位分发
function 协办分发(督办ID, 协办单位):
    INSERT INTO 协办任务(督办ID, 协办单位, 状态='处理中')
    通知(协办单位, "收到协办任务: " + 督办.标题)

// 协办完成自己的任务
function 完成协办任务(协办任务ID, 结果):
    task = SELECT * FROM 协办任务 WHERE ID=协办任务ID
    if task.状态 != '处理中': return error("状态不正确")
    
    UPDATE 协办任务 SET 状态='待审批', 完成时间=NOW(), 结果=结果 WHERE ID=协办任务ID
    通知(督办事项.主办单位, "协办" + task.协办单位 + "已完成任务，待审批")

// 主办审批协办结果
function 主办审批协办(协办任务ID, 是否通过, 意见):
    task = SELECT * FROM 协办任务 WHERE ID=协办任务ID
    if task.状态 != '待审批': return error("状态不正确")
    
    if 是否通过:
        UPDATE 协办任务 SET 状态='已通过', 审批时间=NOW() WHERE ID=协办任务ID
    else:
        UPDATE 协办任务 SET 状态='处理中' WHERE ID=协办任务ID  // 退回重做
        通知(task.协办单位, "主办退回协办任务: " + 意见)

// 主办完成自己的任务
function 完成主办任务(主办任务ID):
    UPDATE 主办任务 SET 状态='已完成' WHERE ID=主办任务ID

// 检查是否可以办结：主办完成 + 全部协办通过
function 检查是否可办结(督办ID):
    主办 = SELECT * FROM 主办任务 WHERE 督办ID=督办ID
    if 主办.状态 != '已完成': return false
    
    协办列表 = SELECT * FROM 协办任务 WHERE 督办ID=督办ID
    for each 协办 in 协办列表:
        if 协办.状态 != '已通过': return false
    
    return true  // 全部完成，可以办结

// 领导复核 → 办结
function 领导复核(督办ID, 是否通过):
    if not 检查是否可办结(督办ID): return error("尚有任务未完成")
    
    if 是否通过:
        UPDATE 督办事项 SET 状态='已办结', 办结时间=NOW() WHERE ID=督办ID
    else:
        通知(督办事项.主办单位, "领导退回督办事项，请重新处理")

四、跟普通工单的区别

	普通工单系统	督办系统
参与者	单线：审批人→处理人	分合：主办+多个协办
完成条件	处理人做完 → 审批人确认	主办做完 + 全部协办做完 + 主办审批通过 + 领导复核
退回	退回一个人	主办可以退回任何一个协办
闭环	审批人确认	领导复核才是最终办结

普通工单是单线流转 ，督办是分合流转 。难度不在技术上，在状态的并发管理上------多个协办同时干活，任一个退回都不影响其他人，但主办不能审批通过直到全部协办通过。

五、跟已有工作流文章的关系

你之前写的 Activiti 外挂会签------"不用 multiInstance，独立子流程+自建关联表实现会签"------那篇里的 hq 关联表，本质上就是这个主办-协办模式的数据库实现：

主办任务和协办任务各自独立
协办结果通过关联表汇总到主办
主办审批后触发流程继续

督办系统是这套模式的最高复杂度场景：不是一次性会签（几个部门同时审批），而是协办先干完活、主办再审批、审批不过再退回------有时间顺序、有状态依赖。

六、亮点总结

✅ 分合模式------主办拆任务、协办各自干、主办审批、领导终审，四层闭环

✅ 状态机驱动------每个节点有明确的状态流转（待审批→处理中→待审批→已通过/退回）

✅ 并发协办------多个协办同时干，互不阻塞，任一退回不影响其他人

✅ 伪代码完整------从创建到办结全链路可落地

✅ 责任归属清晰------每个节点的审批权、退回权、否决权有明确定义

七、适用场景

跨部门联合督办（如"社保局牵头，税务局、民政局配合"）
主办+协办的工作分解和审批模式
需要多部门协同、最终有终审节点的政务审批流程

八、扩展方向

协办超时自动催办------协办超过期限未完成，自动发通知并抄送主办
协办退回重做次数限制------超过N次退回自动升级到领导复核
多级主办------主办也可以把自己的主办任务分解为下一级的主办+协办
协办进度可视化------主办实时看到所有协办的完成进度百分比

九、总结

政务督办系统的核心设计就两个点：

分合模式：主办是根，协办是枝。主办拆任务、协办干、主办审。
终审上移：协办做完不算完，主办审过才算阶段性完成，领导复核才最终办结。

这不是技术难度的问题。是责任归属的问题------每个节点的审批人是谁、退回权限在谁手里、最终谁对督办事项负责。这些规则写成代码，就是一串状态判断。但想清楚这些规则，靠的是跟政务部门坐在一起，一个场景一个场景推出来的。