挑要自动化的活儿之前，先划掉不该自动化的

自动化之后反而更忙

每周花两小时的对账整理交给了脚本。脚本跑得挺好。可每到周一早上，还是要打开日志看结果对不对；数字不对劲，就得翻回原始文件找是哪儿错位了。

活儿没有消失，只是换了个形状。原来动手的两小时，变成了检查的二十分钟，加上偶尔炸掉的半天。平均值确实降了，感受却没降。以前做完就是做完，现在得确认过才算做完。

自动化的评估大多在这里就偏了。做出来要几天，人人都会问；做出来之后每个月要贴进去几小时，很少有人问。报价来回的时候，只有前一个数字是看得见的。

频次和例外，两个数就够判断

省下来的时间，用单次耗时乘以每月次数就能算出来，这一步谁都会做。漏掉的是减法那一边。要减掉例外发生时人去看的时间、对方系统变了之后修的时间、以及核对结果对不对的时间，剩下的才是真正落到手里的量。这个减法里最重的一项是例外。十次里有两次要把人叫回来，负责人就还得把这件事挂在脑子里，节省下来的就从小时缩成了点几下鼠标。例外多的活儿不是自动化的对象，是先该把规则理顺的对象。

频次更直白。一个季度才回来一次的活儿，哪怕一次要坐三个小时，也多半是手工做更划算。为一年跑四次写的脚本，跑到第三次通常已经坏了，而那时候修它花的时间比手工做还长。

坏掉的地方多半在别人的系统上

自动化悄悄停摆，原因很少是代码老了，而是对面变了。供应商发来的表格多了一列，后台管理页面改版，登录处忽然加上了双因素验证。越是靠在自己动不了的一侧，维护成本就越是无声地堆上来。

所以挑候选的时候，先问”半年后还是这个样子吗”，再问”现在跑得通吗”。走官方接口的活儿能撑很久；靠读页面抓值的活儿，对方改个版式就停。公司内部系统介于两者之间，至少变更的时间点我们自己知道。同一件事从哪扇门进去，寿命就不一样，而这个寿命最后正是回本计算里的分母。

先一起看该划掉哪几条

想自动化的事情如果有好几件，把清单原样发过来就行。Weple 的业务自动化是从这份清单里挑出该拿掉的开始的。按频次、按例外插进来的多少、按对外部系统的依赖程度把候选收窄，再从留下来的开始做。要是算下来手工反而更划算，我们也会照实说。