有个场景我见过好几次：一个人每天早上花十分钟，从系统里导出表格，改个名字，贴进另一份文件，发给几个人。后来这段被做成了自动化工作流，触发时间定在早上八点半。头两周大家都在夸，三个月后，那份文件的格式改了，没人记得流程里还有一步在按旧格式取数，于是它每天准时发出一份没人看的错误报表。
它把判断变成了规则
自动化工作流说白了是三件事的组合：什么情况下开始，满足什么条件走哪条路，然后做什么。听起来是技术问题，实际上是判断问题。人做这件事的时候，脑子会自动补上很多没写下来的前提——这一列今天可能是空的、这个客户上周改过名、数字对不上就先别发。这些前提从来没被记录过，因为它们不写在操作手册里，写在那个人的经验里。
所以流程能不能跑稳，往往不取决于工具强不强，而取决于动手之前有没有人愿意把这些隐含前提一条条问出来。问不出来，流程就只能覆盖最顺的那条路径。
失败比成功更值得设计
大部分流程在设计时，注意力都放在“跑通”上。真正消耗人的是跑不通的时候：任务卡在中间状态，没人知道它停在哪一步；重试了几次，数据被写了两遍；报错信息只有一行英文，收到通知的人不知道该找谁。
几个成本不高但常被忽略的做法：
- 保底处理：任何一步失败，都要有一个明确的人收到一条能看懂的通知，而不是一个后台日志链接。
- 可重复执行：同一个任务跑两遍，结果应该和跑一遍一样，否则重试本身就变成风险。
- 留下痕迹：每一步的输入输出留个快照，出问题时能倒回去看，而不是靠回忆。
这些都不新鲜，但它们决定了流程上线之后，是替人省事，还是给人添了一件需要照看的东西。
会长出隐性依赖
自动化工作流还有一个特点：一旦跑起来，就会有人开始依赖它的产出。依赖一旦形成，修改就变难。原来只是内部传阅的一份汇总，被另一个部门的报表引用，再往上又被当成某个看板的来源。链条拉长以后，最初写流程的人离职了，接手的人不敢动，因为“一动就出事”。
这时候流程还在跑，但它已经从工具变成了负债。它没坏，只是没人说得清它为什么是这样。
我会怎么判断值不值得做
判据不是“这件事花了多少时间”。耗时长的环节常常是要人参与判断的，硬塞进流程反而更别扭。更值得看的是三件事：这一步是不是每次都一样、出错了是不是很难被发现、错了以后返工的代价大不大。重复、易错、错了麻烦——三条占两条，基本就值得。
反过来，那些每次都要看情况决定、或者出错了立刻有人喊的地方，用手做着其实挺好，人比规则灵活。
最后一点是维护。做流程的时候顺手写下两样东西：它为什么存在，以及它依赖哪些别人家的东西。这两句话花不了几分钟，但半年后有人想改它的时候，能省掉一整天。
自动化工作流不是把人从工作里拿掉，而是把人从重复里挪到判断和维护上去。这个转移做得好不好，比流程本身跑得多快重要得多。