手动审批工作流软件：先绘制流程

为什么邮件审批会变得混乱

当审批流程规模小且非正式时，邮件是可行的。一个人发起请求，另一人回复，工作继续推进。但一旦更多人参与，问题就会迅速显现。

第一个问题是可见性。审批请求和新闻邮件、日历邀请以及日常消息混在一起。有人打算稍后查看一个请求，但它很快下沉到收件箱底部并消失了。

下一个问题是版本混淆。有人在原讨论串回复，另一个人转发了修改后的附件，还有人批准了旧版本。经过几轮之后，没人能确定哪个文件、价格或措辞是最新的。

所有权也变得模糊。如果一个请求需要财务、法律和团队负责人三方的意见，当流程停滞时谁负责？在邮件里，这个答案往往不清楚。人们以为别人会处理，所以什么都没有发生。

当有人休假或审批路径会根据金额、风险或客户类型改变时，情况就更糟。那些例外通常只存在于个人脑中，而不是共享流程里。这会让审批路径难以预测，也难以追踪。

代价不仅仅是几次回复慢。延迟会拖慢采购、合同、产品上线、招聘决策和客户工作。团队最后花时间追逐更新，而不是做实际工作。

举个简单的例子说明问题。一位销售的折扣请求先通过邮件发给经理，然后被转给财务。财务要求修订后的数字，但销售代表只更新了其中一个讨论串。经理批准了早期版本，财务等待确认，客户两天都没有得到消息。

这就是为什么团队会开始寻找手动审批工作流软件。真正的问题不只是速度。邮件把状态、所有权、截止和例外隐藏起来，直到出现问题才显现。

在触碰设置前先绘制真实流程

在你在软件里建立任何东西之前，先把当前审批流程实际上是如何运作写下来。如果跳过这一步，你很可能会把邮件里的混乱复制到新工具里，而不是修复它。

从小处开始。不要一次迁移所有审批流。挑一个常发生、造成延迟或产生最多跟进的流程，比如采购申请、内容签核、折扣审批或权限申请。

然后看几个真实案例。三到五条最近的邮件线程通常足以显示模式。用真实案例，而不是记忆。人们会忘记小的交接、侧面回复和最后一刻的例外。

在审查这些例子时，用通俗的语言记录基本情况：

• 请求如何发起
• 谁先审核
• 接下来谁批准
• 哪里会停顿或回环
• 如何结束

还要记下每个步骤需要哪些信息。经理可能需要预算金额、供应商名称和截止日期才能做决定。如果这些信息经常缺失，延迟其实不是审批问题，而是请求质量问题。

截止时间也要写进流程。记录每个步骤应该花多长时间、如果无人响应会发生什么，以及紧急请求是否走不同路径。把例外规则一并列出。也许超过某个金额的审批需要财务复核；也许主要负责人不在时会有备用审批人接手。

把整个流程用一页纸写出来，使用人们已经在用的词汇。写“财务核对金额”或“经理要求补充信息”，而不是抽象的系统术语。目标是让人们认得出的流程，而不是看起来很精致的图表。

当实际做事的人说“是的，这就是实际发生的流程”时，你的流程图就可以用了。

选择人人能快速理解的状态

一个好的状态列表应该通过一个简单测试：如果两个人阅读同一条请求，他们对下一步会发生什么应得出相同结论。

这就是手动审批工作流软件在使用简短、清晰状态列表时更有效的原因。大多数团队不需要十个标签。他们需要几个能告诉每个人请求当前处于什么阶段的标签。

一个实用的起点可以是：

• Draft
• Waiting for approval
• Approved
• Rejected
• Needs changes

每个状态应该只表示一件确切的事。Waiting for approval（等待审批）表示请求已准备好，需要有人审核。Needs changes（需要修改）表示尚未批准，但可以在更新后再提交。Rejected（已拒绝）表示请求结束，除非有规则允许重新打开。

混淆始于团队创建近似重复的标签，比如 “Pending”、 “In review”、 “Under review” 和 “Awaiting sign-off”。对系统来说它们不同，但对人来说常常意义相同。这会导致报表混乱、交接不清和额外问题。

如果某个状态需要长篇解释，就重命名它。好的标签在列表、仪表盘或手机屏幕上一眼就能看懂。人们不应该必须打开记录才能明白它的意思。

把状态和所有权区分开通常也更明智。Waiting for approval 比 With finance 更直接。前者告诉你请求的状态，后者把状态和当前审核人混在一起。

先从最少的可行状态开始。如果后来确实出现需要解决的真实问题，再添加状态。

明确负责人和交接

当某个步骤属于“团队”而不是具体某个人时，工作流很快就会出现问题。每个阶段都需要明确的负责人。那个人可以向他人征求意见，但必须有一个名字或一个分配的角色，负责推动请求向前。

当你把邮件审批链迁移到软件时，这一点尤其重要。在邮件里，人们靠习惯行事：有人注意到讨论串、转发或催促下一个审批人。软件不能依赖这种猜测式的工作方式。

对每个步骤回答四个简单问题：

• 现在谁负责？
• 如果此人不在，谁来处理？
• 审批或拒绝后下一个接收者是谁？
• 谁可以重新打开或取消请求？

交接也应同样明确。如果经理批准后由财务复核，就在工作流里直接写清楚。不要只写“发给财务”，除非系统知道哪一个人或角色应该接收它。

举个简单的设备申请例子。它由员工的经理发起。如果费用超过某个限定，流程会转给财务。如果财务负责人不在，一天后由备用的审计员接手。如果申请人填错信息，只有申请人和第一审批人能重新打开它。如果不再需要该申请，只有申请人或部门经理能取消它。

这些规则看起来严格，但它们能防止常见混乱：请求停滞、重复审核以及每个人以为别人负责导致的长时间空档。

添加截止与例外规则

如果只有整个请求一个截止，工作流很容易卡住。每个阶段都需要自己的截止时间，这样团队才能看到时间究竟在哪儿被浪费。

例如，经理审核可能给一天，财务给两天，法律给三天。通常计时器应在请求进入某一状态时开始，而不是在第一封邮件发送时开始。这样更容易发现逾期工作。

在你自动化任何东西之前，先定义四个基本要素：

• 每个阶段的截止日期
• 逾期时清晰的后续动作
• 紧急情况的独立路径
• 缺少信息、返工和例外的规则

当错过截止时，事先决定下一步。通常一个简单规则就足够：先发一次提醒，然后在无变化时升级给备选负责人或团队负责人。不要让逾期工作停在同一状态而没有任何动作。

紧急请求需要自己的路径，但要尽量窄。如果人人都能标记为紧急，这个标签就失去意义。将其限定在少数明确情况，例如面向客户的问题或合规最后期限。

例外规则同样重要。如果请求缺少信息，就把它移到像 Waiting for requester（等待申请人）之类的状态并暂停计时器。如果被拒但可以修正，就送去返工而不是直接关闭。如果超出常规政策，把它发给指定的例外审批人，而不是让人们在邮件中即兴处理。

一个简单的采购请求能说明这一点。财务收到请求但没有供应商报价。没有规则时，财务的截止会到期，大家一头雾水。有规则时，请求会移动到 Missing information（缺少信息），申请人成为主动负责人，且在补上报价前暂停截止计时器。

实践中的简单流程

想象一个笔记本电脑的采购申请。员工在表单中填写物品、费用、理由和所需日期。工作流无需复杂。

一个基础版本可能使用这些状态：

• Submitted
• Needs more info
• Manager approved
• Finance approved
• Completed

请求以 Submitted（已提交）开始，先到经理处。如果员工只写了“给新员工的笔记本”却没有预算代码，经理不应直接批准并在侧面邮件解释问题。更清晰的做法是把状态改为 Needs more info（需要更多信息）并退回。员工再次成为负责人，补充缺失信息并重新提交。

一旦请求完整，经理审核并把状态改为 Manager approved（经理已批准）。所有权随后转给财务。财务检查预算、供应商规则和支出上限。如果一切正常，状态变为 Finance approved（财务已批准）。

现在加入一个现实中的例外：财务审批人病假三天。如果没有提前计划该规则，请求就会停在那儿。更好的设置是预先指定备用负责人。过了截止时间，或一旦确认缺席，请求就转给备用人员，而不是一直等待。

当财务批准后，请求变为 Completed（已完成）。如果团队之后想增加独立的采购步骤，可以再添加。第一个版本应保持简单。

迁入软件时的常见错误

最大的问题是把邮件里的流程原封不动地复制过去。看起来安全，但通常会把旧问题锁定在新系统里。

邮件会掩盖薄弱环节。人们在侧面讨论、手动催促更新并在没有清晰规则的情况下批准请求。如果把相同流程照搬到软件，混乱不会消失，只是更容易被看见。

另一个常见错误是过早添加过多细节。团队列出很长的状态清单，想把每个小步骤都显现出来，但这会让流程更难理解。如果一个请求可以被标为 pending review、under review、waiting for comments、sent back、resubmitted 和 ready for sign-off，大多数人不会知道该用哪个标签。

审批人过多也会有类似问题。如果为了以防万一加入了五个人，工作会放慢且没人感到完全负责。

一些警示信号会很快出现：

• 人们不断询问谁是负责人
• 两个状态看起来意义相同
• 仍需侧面邮件来解释审批情况
• 多人可以操作，但没人明确负责

团队也常在基本规则未确定前就匆忙启用提醒和升级。提醒只有在系统已经知道什么算作等待、谁迟到以及下一步该怎么做时才有用。规则模糊时，提醒只会制造更多噪音。

另一个错误是忽视例外直到上线后。真实的审批链总有例外：有人请假、请求紧急、表单不完整、被拒后带着修改再次提交。如果这些情况没在早期规划，人们第一次遇到异常时就会回到邮件处理。

第一天做到简单比做到完整更重要。先修复薄弱步骤，保持状态精简，每步指定一位负责人，并在添加自动化前决定例外如何处理。

在自动化前的快速检查

在启用路由规则、提醒或升级前，检查流程是否足够清晰以在不依赖邮件的情况下运作。

一个有用的测试很简单：一个标准请求大多数情况下能否沿一条清晰路径从开始走到结束？如果不能，先修正路径。

逐条问自己：

• 常规请求是否有一条标准路径？
• 状态是否用通俗语言书写？
• 每个步骤是否有一位主要负责人和一位备选？
• 截止是否在工作流中可见？
• 在自动化前，例外情况是否已写下来？

如果不能清晰回答这些问题，就暂停。清晰的标签、明确的所有权和写下来的例外规则比花哨的自动化更能节省时间。

这就是为什么许多团队会先在简单文档或白板上草拟流程，然后再在工具中构建它。如果你要创建内部审批应用，Koder.ai 可以是把通俗流程快速变成可用软件的实用方式，无需漫长开发周期。

在一个小而安全的试点中推广

不要把新流程一次性在全公司推广。先从一个团队和一种请求类型开始，例如采购审批或内容签核。小规模试点更容易在问题扩散前发现问题。

这正是手动审批工作流软件建立信任或引发阻力的关键。如果人们能用更少的混乱完成真实请求，采纳就更容易。

选择一个发生频率足够高以供测试，但出问题后风险不大的流程。明确告诉试点组目标不是完美，而是尽早找到尴尬环节以便在小范围内修正。

在试点期间，注意人们何时离开系统转而手动处理。那通常是最明显的信号，说明有缺失。

关注：

• 因为所有权不清而停滞的请求
• 人们对状态的不同解读
• 截止规则与实际工作不符
• 例外仍然溢出到邮件或聊天

在前几起真实案例后，先把基础打牢再添加更多功能。修复不清楚的交接，简化状态名称，并把截止时间调整得更符合实际。等核心流程运行顺畅后，再考虑报表、升级和额外自动化。

一个简单的复盘节奏有帮助。在前 5 到 10 个请求后检查一次，然后两周后再检查一次。问一个直接的问题：人们在哪些环节仍然需要变通？

如果你想快速测试内部审批工具，Koder.ai 对从对话原型生成工作流并把它变成可用应用非常有用。通常这足以在投入更大推广前验证流程。

一个安全的推广通常刻意保持枯燥。这是好现象。人们应该知道下一步会发生什么、谁负责以及当事情不符合常规时该怎么做。