流程、责任与协作边界

本章目标：把业务步骤、责任转移、审批和通知区分清楚，设计一条现实中能被人执行的目标流程。

1. 业务过程不等于审批流程

采购申请从提出到完成可能包括：

提出需要 → 填写申请 → 审批 → 行政采购 → 到货确认 → 完成

其中只有“审批”部分需要审批流程。填写、采购和到货确认同样属于业务过程，但不一定需要审批节点。

如果把所有步骤都画成审批：

• 本来只是执行工作的岗位被迫点击“同意”；
• 状态和待办数量变得混乱；
• 业务含义被“批不批准”掩盖；
• 流程难以调整。

判断某一步是否需要审批，可以问：

• 这个人是在作出授权或风险决定吗？
• 他是否可能拒绝或要求修改？
• 需要保留正式的决定和意见吗？

如果只是接收信息或执行工作，可能更适合任务、状态、通知或操作按钮。

2. 先画现状流程，再设计目标流程

现状流程

如实记录现在怎样做，包括手工、重复和绕行：

员工发消息 → 主管回复 → 行政复制到 Excel
→ 行政采购 → 员工询问进度 → 行政回复

目标流程

基于目标重新设计：

员工提交申请 → 主管审批 → 必要时负责人审批
→ 进入行政待采购清单 → 行政登记采购结果 → 申请人查看完成

不要因为现状有三次复制，就在新应用里设计三个“复制步骤”。先问每一步产生什么价值。

3. 用步骤卡描述每个环节

每个步骤都回答：

项目	示例
步骤名称	直属主管审批
开始条件	申请已提交且找到直属主管
负责人	申请人的直属主管
需要的信息	用途、明细、总金额、申请人
作出的决定	同意、退回或拒绝
完成结果	进入下一审批或待采购
时间期望	两个工作日内
异常处理	无主管时不允许静默跳过

步骤卡能发现“有节点但没人负责”“要决定但信息不够”等问题。

4. 区分四种参与方式

一项工作里，人可能以不同方式参与：

参与方式	说明	采购案例
执行	实际完成这一步工作	行政采购员购买物品
负责	对最终结果承担业务责任	行政负责人负责采购制度
提供意见	在决定前提供专业信息	财务确认预算口径
被告知	不参与决定，但需要知道结果	申请人收到审批和完成通知

每一步最好有一个明确的最终负责人。多人都“共同负责”往往等于没人真正负责。

5. 设计责任如何转移

记录在不同阶段可能由不同人负责：

阶段	当前责任人	责任内容
草稿	申请人	补全和确认申请内容
审批中	当前审批人	作出审批决定
待采购	行政采购员	执行购买和更新进度
已完成	无待处理责任	保留查询与管理

需要进一步问：

• 责任人如何确定；
• 多人可以处理时，是任意一人还是全部都要处理；
• 人员离岗时如何交接；
• 责任转移后，前一责任人还可以做什么；
• 管理者怎样发现无人负责或长期未处理的事项。

6. 设计交接点

交接点是最容易丢信息的地方。

从主管交给行政时，需要明确：

• 行政收到哪些申请信息；
• 审批意见是否可见；
• 是否需要附件；
• 什么时候进入行政的待处理清单；
• 申请内容是否仍可被修改；
• 如果行政发现信息错误，应该退回还是直接修改。

好的交接标准是：接手人不需要再通过聊天询问基本信息，就能开始工作。

7. 正确使用通知

通知用于“让应该知道的人知道”，不能代替责任和待办。

适合通知

• 申请已提交；
• 审批被退回；
• 申请已批准；
• 采购已完成；
• 待办即将超时。

不应只靠通知

• 必须由某人处理的审批；
• 必须登记结果的采购工作；
• 需要持续跟踪的异常；
• 需要证明已经完成的责任。

如果一件事必须做，就应有明确的待处理入口和状态，而不只是发一条消息。

8. 处理并行、分支和回退

并行

两项工作可以同时进行，并且都完成后才能继续。例如法务和财务同时审查合同。

条件分支

根据业务条件选择不同路线。例如采购总额是否大于 5000 元。

回退

退回到哪一步、由谁修改、修改后从哪里重新开始，都必须清楚。

终止

拒绝、撤回和作废是否都终止流程？是否允许重新发起？原记录如何保留？

避免画出没有出口的分支，或让一条记录在多个责任人之间无限循环。

9. 时间和超时

每个需要人处理的步骤应考虑：

• 正常期望多久完成；
• 何时提醒本人；
• 何时通知负责人；
• 超时后只是提醒，还是自动转交；
• 节假日是否计算；
• 紧急业务是否有不同规则。

超时策略必须符合真实管理制度，不能为了“自动化”擅自把审批交给别人。

10. 目标流程评审问题

逐步检查：

1. 每一步是否产生明确价值？
2. 是否有唯一可解释的开始和结束？
3. 每一步是否有负责人？
4. 负责人是否拥有作决定所需的信息？
5. 交接后是否仍需线下补充信息？
6. 正常、退回、撤回、拒绝、作废是否都有去向？
7. 如果某人不在，业务是否完全停住？
8. 管理者如何发现积压和异常？
9. 哪些步骤应自动完成，哪些必须由人判断？

11. 采购案例目标流程

顺序	步骤	负责人	结果
1	创建并提交申请	申请人	形成正式申请
2	直属主管审批	直属主管	同意、退回或拒绝
3	高金额审批	行政负责人	仅大于 5000 元进入
4	执行采购	行政采购员	登记采购日期和结果
5	确认完成	行政采购员	申请状态变为已完成
6	查看结果	申请人、管理者	查询进度与统计

需要补充的异常：

• 无直属主管；
• 申请人撤回；
• 审批退回；
• 批准后缺货；
• 申请作废；
• 行政采购员交接。

12. 常见错误

• 把业务全过程全部设计成审批节点；
• 只有流程图，没有每一步的输入、负责人和结果；
• 通知了很多人，却没有明确谁必须处理；
• 退回只画一条反向箭头，没有说明修改和重提规则；
• 多个角色“共同负责”，没有最终责任人；
• 自动转交改变了业务责任，却没有制度依据；
• 目标流程只是把现状原样电子化。

13. 本章完成标准

• [ ] 已分别画出现状流程和目标流程；
• [ ] 已区分业务步骤、审批、任务和通知；
• [ ] 每一步都有开始条件、负责人、输入和结果；
• [ ] 主要交接点的信息完整；
• [ ] 并行、分支、回退和终止都有清楚去向；
• [ ] 超时和人员不在的处理方式已明确；
• [ ] 流程中没有无价值的“为了审批而审批”。

下一步

业务不仅要能流转，还要能被查询和管理。下一章学习如何分析查询、统计与管理指标。