工作流中的委托审批：请假模式与替代审批人

为什么有人不在时审批会卡住

审批停滞通常有一个简单原因：流程在等待某个特定的人，而系统不知道当此人离线时该怎么办。请求到达他们的收件箱，但没有其他人有权限处理，一切就停了下来。

当审批绑定到个人姓名而不是角色时，这种情况会更糟。团队变动、人员请假、经理出差都很常见。如果工作流不能自动切换到替代人，就会出现“紧急催办”、手动变通和延迟决策。

把几类容易混淆的操作区分开也很有帮助：

• Delegation（委托）：原始审批人仍对决定负责，但在特定期间或特定情况下，替代人可以代表其执行操作。
• Forwarding（转发）：任务被共享或发给别人，但系统可能仍然期待原始人员的回应。
• Reassignment（重新分配）：审批任务的所有权转移给另一个人，通常是永久性的或仅针对单个请求。

真正的目标不仅仅是速度，而是可预测性和清晰记录。

“透明”对经理和审计人员来说有两层含义：你要能看出工作流为什么路由到替代人，并且能证明谁在何时、依据何种规则进行了审批。如果 Alex 在休假而 Priya 批准了一项采购，历史记录应显示 Priya 是作为 Alex 的代理执行的。记录不应显示为 Alex 批准，也不应隐藏在私人聊天中。

目标很简单：没有被阻塞的请求，并且即使有人不在，仍然有一条可审阅的清晰责任链。

关键术语：审批人、替代人与委托

用词清楚可以避免后续规则混乱。如果团队对谁有权审批没有共识，工作流要么停住，要么带来审计问题。

大多数审批工作流包含一些常见角色：

• 请求人 发起流程（费用、采购、访问请求等）。
• 审批人 做出决定。
• 管理员 配置工作流、权限和规则。
• 替代人（有时称为代理）被允许代表另一人进行审批。

主审批人 是该步骤默认期望审批的人。备份审批人 是在主审批人无法处理时的后备人选。

人们常把“备份审批人”和“第二审批人”混为一谈，但它们不同。第二审批人是增加一个额外审查层；备份是同一审批层的替代路径。

委托是允许替代人代为处理的规则。常见的两种形式是：

• 始终生效的委托：替代人在任何时候都可以审批，即使主审批人在岗。
• 仅在缺席时生效的委托：只有在主审批人标记为离开（请假模式）或达到超时阈值时，替代人才可审批。

审批层级是请求必须经过的有序步骤（例如先经理、再财务、再法务、再 IT，取决于请求和金额）。将“层级”与“替代人”分开考虑：层级定义必须经过哪些审批；替代人定义当常规审批人不可用时谁可以代为审批。

为你的流程选择合适的委托模型

并非每个团队都需要相同的备份方式。正确的模型取决于人员缺席的频率、决策的风险程度，以及审批步骤的可预测性。

先选择一种主模型，把其他情况当作例外。刚开始就混合所有选项会让用户困惑，并增加审计难度。

常见的委托模型（及适用场景）

大多数团队最终会结合使用以下几种：

• 请假模式（基于日期）：审批人设置起止日期，在该时间段内请求路由到指定替代人。
• 一次性手动委托：管理员或经理在紧急时为单个请求指定替代人。
• 基于规则的委托：替代人由规则选出，例如按团队、请求类别或金额。
• 升级处理：若无人在期限内响应，请求转给下一位（通常是审批人的经理或值班队列）。
• 职责分离：敏感审批要求由不同的人或第二审批人处理，防止请求人或替代人自行审批自己的事项。

请假模式通常是日常操作中最简单的。基于规则的委托适合较大团队，因为它减少了关于覆盖人员的人工决策。升级处理不是委托的替代，而是超时后的安全网。

快速决定模型的问题

几个问题可以快速缩小选择范围：

• 该审批是高风险（资金、访问、合规）还是低风险（例行管理）？
• 是每人一个替代人，还是需要一个池（例如“财务值班”）？
• 是否向请求人显示替代人，还是只对管理员可见？
• 在触发升级前，请求可以等待多久？
• 是否需要硬性规则来阻止自我审批？

请假模式与替代人的设计规则

请假模式只有在可预测的情况下才有效。目标很简单：审批继续流转，且每个人都能看到谁负责。

要求明确的时间窗口。 每次委托都应有开始和结束日期（若跨区域工作，带上时区）。避免使用“直到另行通知”。如果有人忘记关闭，审批可能错误地路由给某人数周。

决定谁可以选择替代人。 小团队中自选替代人可行，但若人员选择了不受过培训的人，风险较高。经理指派适用于大多数组织架构。管理员指派最为严格，但会增加设置时间。

设置系统可强制执行的资格规则。 保持规则简单，不要允许只存在于某人脑中的“特殊情况”。典型规则包括属于相同部门或成本中心、具有相应审批层级、完成所需培训。始终阻止明显冲突：替代人不应是请求人，应防止循环审批。

定义在途审批的处理方式。 许多团队将新请求路由到替代人，但对已挂起的事项保留给主审批人，除非逾期。一旦逾期，工作流可以自动重新分配或升级。

让状态可见。 请求人应能看到当前审批人、是否有委托以及下一步是什么。类似“等待审批（已委托给 Alex，至 1 月 30 日）”的状态能减少追问并提高信任。

实施替代审批的分步指南

先写下一个常见请求（采购、访问、政策例外）的精确审批路径。保持范围小，2 到 4 个步骤足以设计模式。

一个实用的实现模式

1. 将每个步骤映射到一个角色并保留一名记录中的主负责人。 即使替代人可以代为处理，也要为每个步骤保留一个主审批人，以便责任清晰。

2. 选择一个主要触发委托的机制。 大多数团队使用缺席标记、日期窗口或经理控制的开关。先选一种，这样人们不会被静默重路由而感到惊讶。

3. 添加路由规则以选择实际处理人。 可预测的顺序最易说明：用户选择的替代人，然后经理，然后共享备份队列。决定替代人是否可以立即审批，或仅在超时后才可审批。

4. 通过通知设定期望。 请求人应看到当前负责的人。主审批人应被告知委托已生效以及如何关闭。替代人应收到上下文并明确知道如何拒绝不应处理的请求。

5. 运行一次端到端测试并检查历史记录。 你应能看到谁被分配、为何发生委托、谁批准以及何时批准。

测试与确认

使用真实场景：主审批人“请假”，替代人进行审批。然后重复测试替代人也不可用的情况以确认回退规则。最后确认审计轨迹显示主审批人与实际操作人，以及委托原因，让审计人员无需询问任何人就能理解交接过程。

为清晰审批历史应记录的信息（审计轨迹）

审计轨迹应能毫无疑问地回答三件事：发生了什么、谁做的、为什么被允许。委托审批时这点尤为重要，因为“责任审批人”和“实际点击的人”可能不同。

把委托规则作为一等记录记录，而不是会静默变化的设置。捕获谁将权力委托给谁、开始和结束时间、范围（哪些请求、金额、团队或文档类型）、以及在流程需要签字确认时谁批准或确认了该变更。

审批决策应是不可变的事件。不要覆盖“待处理”为“已批准”。记录诸如“已批准”、“已拒绝”或“要求修改”的事件并保留，即便工作流重启也不应删除这些记录。

一个实用的审计轨迹通常包括：

• 事件 ID、工作流项 ID 和步骤名称
• 时间戳（含时区）、执行者身份及其当时角色
• 代为处理的详情（原始审批人、委托规则 ID）
• 结果及评论、原因代码和任何附件
• 对委托规则的任何编辑（谁何时修改了什么）

将评论和附件与决策事件绑定在一起。如果它们存在于单独的聊天或通用“备注”字段，就很难证明哪条评论支持了哪项决定。

最后，让历史记录可读。一条按时间顺序显示委托变更、发送的通知、所作决定和升级处理的时间线能防止后续争议。

透明度：审批进行时用户应看到什么

当人们能看到发生了什么时，他们会接受延迟。看不到时，他们会追着错的人、重复发送请求或认为系统坏了。

请求人和审阅者应始终看到当前审批人和被选择的理由。如果任务从主审批人转给替代人，应直接显示：“分配给：Priya（替代 Alex）。” 这一行能防止混淆并保障问责。

还应显示委托的时间窗口和设置者。“委托生效：1 月 10 日至 1 月 20 日，由 Alex 设置”能让团队相信交接是有意为之。

隐藏的重新分配会让审计变糟。如果有人能在不留可见痕迹的情况下交换审批人，用户会丧失信任，经理也无法判断是谁做出的调整。让适当人员可以看到重新分配，并始终记录触发者。

一个简单的“查看历史”面板通常足够。要点包括：当前状态、当前审批人及原因、委托期间、任何手动重新分配和决策评论。

隐私也很重要。定义每个角色可以看到的内容。请求人可能需要看到姓名和状态，而人力、财务或法务等流程可能需要屏蔽内部备注。

常见会导致延迟或审计问题的错误

委托失败往往是由简单原因造成：规则过于宽松、记录含糊或缺乏后备计划。结果可预见：请求搁置，之后没人能证明是谁批准的。

一个常见陷阱是将委托给不能审批该类请求的人。例如，采购负责人将采购审批委托给一个没有支付权限的同事。替代人点击批准后，财务发现问题，而你必须解释系统为何允许这种操作并撤销交易。

常见错误包括：

• 将委托给自己，或不合格的人（角色错误、额度不足、存在利益冲突）
• 委托没有结束日期
• 在记录上覆盖原始审批人（丢失责任链）
• 当主审批人和替代人都不可用时没有升级路径
• 通知过多，导致人们将其静音并错过关键通知

通知过载很微妙。如果每一步都触发邮件、聊天、推送和提醒，用户会学会忽略所有信息。

可防止大多数问题的设计选择包括：

• 要求委托有开始和结束日期，并自动到期
• 在激活前用明确规则验证替代人的资格
• 保留两个身份：“被分配的审批人”和“实际操作人”，且绝不抹去原始审批人
• 添加升级处理：若 X 小时内无人操作，则路由给经理或值班队列

在推广前的快速检查清单

当“枯燥的细节”一致时，委托才会有效。在为全公司启用请假模式前，检查每个审批步骤并问：如果今天分配的审批人不可用，接下来会发生什么？

• 每个步骤都有命名的备份（或明确的值班队列），且该备份拥有正确的权限。
• 委托规则有时间限制，管理员可以看到哪些委托处于激活状态。
• 审批历史同时显示主审批人和实际操作人。
• 对任何记录，你都能在不猜测的情况下回答“谁在什么时候、依据何种规则批准了它”。
• 对超时有升级处理（例如，48 小时后重新分配给经理或队列）。

然后至少完整测试一次“人员休假”的场景：请求在休假开始前提交、在休假期间被批准，并在该人返回后复查。

示例：一次真实的请假期间审批交接

销售团队提交了一笔购买请求：12 个耳机，金额 1,200 美元。请求通常发给销售经理 Maya。但 Maya 请假两周，审批不能等。

离开前，Maya 启用请假模式，并指定 Jordan（销售运营主管）作为她在 5,000 美元额度内的采购替代人。高于此额度的审批仍需财务处理。

干净、可审计的交接过程如下：

• 周一 9:10：一名员工提交“入职用耳机”，并填写供应商和成本中心。
• 周一 9:10：工作流首先将步骤分配给 Maya，但由于请假模式生效，立即重路由到 Jordan。
• 周一 9:18：Jordan 审核并批准。记录显示“Jordan（代 Maya 批准）”，并包含 Jordan 的备注：“为 Q1 入职批准，预算已确认。”
• 周一 9:18：工作流继续流转到财务进行预算检查，随后将请求标记为已批准。

有两点让整个流程显得可信：请求人能看到为何审批人变更（“路由到替代人：Maya 离开中”），Maya 返回时也清楚自己缺席期间发生了什么。

Maya 回来后，打开“缺席期间的审批”视图，查看 Jordan 代她批准的事项。她可以按日期范围、金额或请求人筛选。她不会再次批准，但如果发现问题可以标记某条请求以便后续跟进。

后来审计员问“谁批准了这笔采购，为什么不是 Maya？”时间线会给出一致的说明：原始审批人、委托原因（请假模式）、替代人身份、代为标注、时间戳和备注。

下一步：安全推广并保持易于维护

把委托当作一次小型产品变更，而不是一个打勾的设置。目标不变：当人们不在时审批继续流转，并且每个决定都能被解释清楚。

从一个在停滞时会带来实际痛点的工作流开始（费用、采购审批或访问请求）。范围要紧凑：一个团队、一条审批路径和一个明确的成功指标，比如“因某人不在导致的待批超过 24 小时的情况为零”。

写一份短小的委托政策，让人们愿意遵守：谁可以委托、哪些事项可被委托（例如仅低于某个成本或风险阈值）、委托如何开始与结束、以及紧急覆盖如何记录和执行。

为角色和规则指定一个负责人，并设定定期复查（每月或每季度）以清理过期的替代人。大多数长期问题源于从未关闭的陈旧委托。

如果你想在不写大量代码的情况下构建审批应用，AppMaster（appmaster.io）可以在数据库中建模用户、角色和委托窗口，然后在可视化业务流程编辑器中实现路由和超时，同时保持面向审计的一致审批历史。

分阶段推出，倾听用户反馈，并在第一个工作流运行稳定几周后再扩展到下一个流程。