流程跑起来之后，谁还在等
早上九点，一张申请单在系统里自动生成，字段校验通过，通知也发出去了。看起来事情已经往前走了一步。可到了下午，它又停在某个负责人那里，因为金额、供应商名称和合同附件之间有一点对不上。自动化工作流把能搬运的步骤搬走了，却没有把这类犹豫一并搬走。
这类场景并不少见。很多团队谈自动化工作流时，关注的是减少几次复制粘贴、省掉几个审批节点。真正上线后才发现，流程的速度并不只由系统决定，还取决于异常出现时，谁来判断、依据什么判断、判断结果如何回到流程里。
把重复动作交给系统，把判断留在合适的位置
自动化工作流的基本思路并不复杂：把触发条件、步骤顺序、数据传递和结果通知串起来，让重复动作按规则执行。表单提交后自动建任务，任务完成后自动更新状态，状态变化再通知相关人。这些环节适合交给系统，因为它们有明确输入，也有可预期输出。
麻烦往往出在规则之外。例如文本描述含糊、附件缺失、两个系统的字段口径不一致。流程如果只会走直线，就会把这些情况推回给人；如果强行用规则兜住，又可能把错误放大。一种可行的做法，是在流程里留出明确的“人工判断”位置，让人看到上下文，而不是只看到一个失败提示。
- 哪些步骤是固定动作，可以由系统直接执行；
- 哪些节点需要人补充信息，补充后如何回到原流程；
- 异常被处理后，是否需要留下可追溯的记录。
这些问题不解决，自动化工作流容易变成一条只处理顺利情况的通道。顺利时很快，不顺利时反而多绕几圈。
看不见的维护，常被放到搭建之后
搭建阶段通常容易获得关注：流程跑通、通知发出、页面可演示。之后才是日常：字段改了，接口变了，审批人换了，旧规则还在按原样执行。流程不会自己解释为什么停，它只会停在那里。维护者需要定期查看失败记录、清理过期规则、确认通知是否仍然有效。这些工作不显眼，却决定了流程能否长期可用。
因此，在设计自动化工作流时，日志和失败处理不该被放到最后。每一次自动执行留下可读的记录，失败时说明卡在哪一步，修改规则时能看出影响哪些分支。这样做并不追求复杂，只是让后来接手的人少猜一点。流程是给人用的，也需要被人维护。
回到开头那张申请单。它需要的也许不是再增加一个自动提醒，而是一个能看清差异、允许补充说明、并把结果送回流程的入口。流程的价值，不在于让所有步骤都消失，而在于让人和系统各自处理擅长的部分。想清楚这一点，流程跑起来之后，等待才会少一些。