后台与运营
那些没有归属、人人都在做一点的工作
每家公司都有一层任务：没人被雇来做这些，但最后人人都得做——要挪动的文件、要核对的数字、要催的审批、要在会计到来之前完成的导出。
有四套系统的分销商
一家小型分销商。订单进一个系统，库存在另一个系统，会计用第三个系统，仓库则运行着 2006 年的一款软件，它唯一的接口就是丢到 SFTP 服务器上的一个 CSV 文件。单看每一套都没问题，问题全出在缝隙里。
每天早上有人导出、导入、检查、修正。顺利时花五十分钟，供应商数据里多出一列时就要两个小时。做这件事的人是仅有的两个足够了解业务、能发现数字不对的人之一——这恰恰说明他们不该每天在这上面花两个小时。
- ⚡触发器文件出现在供应商的 SFTP 上。
- 2已解析分号分隔、字节顺序标记、波兰语表头。共 4 118 行。
- 3已核对对照参考数据核对货币和国家代码。两行无效。
- 4已推送以每批 200 条写入库存系统。遵守了速率限制。
- 5已回写仅为差额创建了会计分录。
- !例外两行已归档，附行号和原因。其余 4 116 行顺利通过。
- ✉摘要07:00 发送一条消息，此前由静默时段保留。
付费步骤：0本次运行的成本：零
异常才是产品
这样一个工作流的价值不在于它搬动了四千行数据。任何脚本都能搬四千行。价值在于它静默地搬完其中 4 116 行，并把另外两行连同行号、出错的值和出错原因一起摆到人的面前。
这把一个五十分钟的活儿变成两分钟的活儿，而且——更有用的是——把一个看不见的活儿变成看得见的。以前，没人知道数据每周有两行坏数据。它们被做导入的人悄悄修掉了，供应商从未被告知。
不会卡住的审批
审批就是一次等待。运行停在这一步，带着它掌握的全部信息，而等待期间不产生任何费用。如果在设定的期限内没人回应，它会升级、走默认路径，或者停下来自行归档——由你选择，而且这个选择体现在工作流里，而不是在某个人的脑子里。
常见的做法是：两天后催一次，四天后升级给第二个人，绝不因为唯一能批准的人去休假了，就让一件事搁置三个星期。
以前总有人为这个加班。
常见的六种
人们在这里搭建什么
夜间任务
导出、转换、导入、校验、报告。从头到尾都是确定性的，这意味着运行不花钱，而且每晚产出相同的结果。
文档流转
发票以 PDF 附件的形式到达。系统提取字段，与采购订单核对，并归档到三个系统中。对不上的那一份会转给人工处理。
入职与离职
新同事需要在六个地方开通账号，而离职的那位则要在正确的日子从这六个地方全部移除。后者往往是被遗忘的那一个。
升级处理
任何超过时限、还压在任何人手里的事项，先催办一次，然后升级上报。这个流程本身很枯燥；但正是因为没有它，事情才会一压就是三个星期。
合规日期
一项有提前期的周期性义务——续约、申报、检查——提前浮现出来，而不是当天才发现；如果没有任何动作，还会再次提醒。
健康检查
轮询那些必须在线的东西，出问题时只发一条警报，而不是在凌晨 02:41 网络抖动一下就冒出四百条警报。
为什么这些工作长期停留在手工状态
因为它从来不是任何人的正式项目。它太小，不值得请开发人员；太特殊，买不到现成的产品；又太无聊，做它的人懒得为此大惊小怪。于是它留了下来，越积越多，最终公司里会有三个人，他们的实际工作就是在几个各自号称功能完备的系统之间搬运数据。
因此，一个工作流要达到的门槛其实很低：只要搭建它比亲手做上几个月的活儿更快就行。用一句话描述它，再花二十分钟整理一下，对这一页上几乎所有的场景来说，都能轻松跨过这道门槛。
不要自动化一个糟糕的流程。如果两个人用不同的方式做同一件事，而且都确信自己是对的，那么工作流只会让其中一个人更快、更稳定地出错。先把流程理顺；自动化只需要一个下午，而争论要花上两个星期。