Faster does not necessarily mean better

Suppose automation reduces an approval process from two days to two hours. Is that an improvement? Probably. But not necessarily. What if errors increase? What if the approval was quick but the customer subsequently has to contact the organisation twice to correct the outcome? What if the activity immediately downstream now receives work faster than it can process it? This is the difference between making an activity more efficient and improving the performance of the work as a whole. Automation projects naturally produce measures such as time saved, tasks automated and transactions processed.

Those measures are useful. But they can also encourage us to optimise what is easy to measure. A process exists to produce an outcome. So what outcome matters? Lead time? Quality? Capacity? Customer experience? Risk? Revenue? Rework? If we cannot say what should become better, it becomes surprisingly difficult to establish whether automation has succeeded. This is particularly important with AI because the technology can now act on activities that previously resisted conventional automation. Classification, interpretation, drafting and recommendation can all be performed faster. But faster classification is not useful if it creates worse decisions.

Faster correspondence is not useful if customers receive plausible but inappropriate answers. Lower handling cost is not necessarily useful if demand simply returns elsewhere. The right question is therefore not: How much work have we automated? It is: What became better because we automated it? That requires us to understand the wider system before we change one activity within it. Efficiency matters. But efficiency is an attribute of an activity. Improvement is an attribute of the outcome. The two often coincide. Good management requires us to notice when they do not.