Discussions about automation slide quickly into ten-year predictions. What can be observed, though, is what happens inside an organisation that actually automates something.
Tasks, not jobs
Few jobs consist of a single task. Automation affects individual tasks, and the effect on a role depends on what proportion of it consisted of those tasks and what is left afterwards.
A role that loses its repetitive part and keeps its judgement part becomes harder, not easier — and calls for different preparation.
Three observable effects
The task moves, it does not disappear. Someone has to check the output, handle the exceptions, correct the errors. Execution work becomes verification work — a different activity, often more tiring, because it demands sustained attention without the natural rhythm of doing.
Volume rises. When a task becomes cheap, it gets done more often. The organisation produces more reports, more variants, more analyses — not necessarily more value. The time saved is consumed by the extra volume.
Skill erodes. When a task is no longer practised, the ability to do it by hand declines. That becomes a problem when the system fails, or when someone has to judge whether its output is correct.
What works, what does not
It does not work to automate a bad process. The result is a bad process, executed faster and with less understanding of what is happening.
It does not work to introduce a system while changing nothing else. If the procedure, the metrics and the way of working stay the same, the system becomes one more step.
It does work to involve the people who do the task in designing the automation. They know where the exceptions are — exactly the part a top-down project discovers in production.
It does work to have an explicit plan for the time freed up. Without one, the time dissipates and nobody can say afterwards whether the project delivered anything.
The question worth asking
Before automating: what will the person who used to do this be doing tomorrow?
A clear answer turns the project into managed change. The absence of an answer turns it into a source of anxiety, passive resistance and, often, quiet sabotage — the real reason many technically sound implementations produce nothing.