自动化项目为何失败

设想一位企业主：他研究了好几个月，上线了一套自动化，并向团队做了说明。几周之后，大家又回到了原来的做法。系统在运行，却没有人使用。这样的情形并不少见。

讲述自动化有多大用处的文章比比皆是，我们自己的网站上也按行业写了不少。但有一个话题几乎无人谈及：自动化项目为什么留不下来？

本文谈的正是这个。讲自己所售之物的边界，或许显得奇怪，但反其道而行代价更高。装错位置的自动化，比完全没有自动化更耗时间。

问题通常不在技术

自动化一旦受阻，最先被责怪的往往是工具。可如今的工具已经相当成熟。受阻的源头多半在技术之前的环节，也就是流程本身。

自动化是加速器。它可以让运转顺畅的流程更快。但它同样会加快混乱的流程，也就是把混乱放大。如果一半记录在表格里、一半在笔记本上，自动化并不会替你把它理顺。

在不少企业里，同一件事两个人有两种做法。由人来做的时候这不成问题，各自清楚自己的路数。但自动化只接受一种做法。流程若事先没有写下来，实施过程中就会冒出"其实我们不是这么做的"，工作只好从头再来。

办法很简单，却常被跳过：把要自动化的流程在实施前逐步写清楚。谁在什么时候做什么，哪条信息流向哪里。这份清单一旦成形，流程中多余的步骤往往也会一并显现。

人自然想从最痛的地方开始。可最痛的地方通常也最复杂：牵涉人多、例外多、连接的系统多。作为第一次实施，那是个吃力的位置。

从范围小而清楚的环节入手，往往是更稳的路径。预约提醒、把收到的消息转给对应负责人、生成定期报表。当一个小环节顺利运转，团队会开始信任系统，再推进复杂环节可能就容易一些。

自动化常常在管理层拍板，然后以成品交给团队。团队可能有两种理解：一种是"能让我省事的工具"，另一种是"盯着我的系统"。他们信哪一种，直接影响结果。

录入数据的是团队，使用结果的是团队，最先发现问题的也是团队。在开头征询他们，比在结尾说服他们省力得多。

自动化上线，工作并没有结束。真实使用总与实施时的设想不同：来了没预料到的消息格式，客户表单只填了一半，供应商用另一种结构发来数据。这些不是故障，而是日常运转。

上线后的头一段时间，如果没有人观察系统、修补卡顿之处，团队可能在第一次不顺时就退回旧办法。一旦退回，再走回来就难了。

"到底有没有用"若凭感觉回答，争论不会有尽头。实施之前就该定好衡量什么：有多少消息没能回复，有多少预约被遗忘，一份报价要经过哪些步骤。

这种衡量不必复杂。要紧的是把实施前的状况记在某处。否则即便有所改善，也可能无人察觉。

并非每个流程都适合。以下情况下，等一等可能更妥当：

从销售角度看，说这些或许显得反常。可装在不合适位置上的系统对谁都没有好处：企业损失了钱，实施方损失了口碑。

在谈自动化之前，如果下面这些问题已有答案，推进会更快，走错方向的风险也会降低：

其中有些答不上来也不要紧。答不上来本身也是信息，它可能指出哪一块该先理顺。

Kılman Bilişim 倾向于在实施之前与客户一起把流程梳理出来。对于我们认为不合适的环节，我们不会提议上线，而是说明需要先做哪些准备。上线之后，我们会观察系统在真实使用中的表现，并修正卡顿的地方。

这种做法看上去更慢。但一次做对的系统，因为赢得了团队的信任，往往能留得住。

多数项目在准备阶段就已受阻，甚至还未开始安装工具。如果流程没有落到纸面，谁做什么也不清楚，实施过程中就会不断冒出新的例外情况。技术很少是真正的根源。

从范围较窄且重复的环节入手，往往是更稳妥的路径。预约提醒、把收到的消息转给对应负责人、生成定期报表，都可能适合作为起点。当一个小环节顺利运转，团队的信任感会建立起来，再推进复杂流程可能会更容易。

抵触通常源于不清楚系统究竟做了什么。如果团队把它当作监督工具，就可能回避使用。在流程之初征询团队意见、说明为何要自动化这项工作，并在最初出现问题时陪在他们身边，都可能减轻这种抵触。

并非如此。形态经常变化、很少重复，或者每个案例确实各不相同的工作，自动化能带来的帮助可能有限。在没有任何记录的领域，也缺少可以依托的基础，需要先把记录习惯建立起来。

在提议实施之前，我们先一起把流程梳理清楚。若判断不合适，我们会明确说明。