The Dangers of Automation
by jed simms on February 25, 2008
Since the inception of computing, computers, IT and many other names have been synonymous with “automation”.
Automating payrolls, production schedules, stock records and others business areas were the mainstay of computing for many years.
Now the focus is on ‘automating processes’ (often called BPM) as a major area where IT can contribute to the business.
But, beware. This is an area fraught with danger.
Some time ago, a keen software sales director flew to Australia to try to convince me to use his ‘process mapping’ software for our Business (Process) Simplification process.
His software was good and flexible, easy to use and learn. But, for our purposes, useless.
Why? It automated the process map capture and revision process. Good? Well, no.
In our rush to automate processes we often overlook the consequences.
When you’re re-engineering or simplifying processes you need to draw them manually. Not once, but again and again until you’ve got them right and complete.
Now, I can just see many eager beavers saying, “But, if you use process mapping software the workload involved in redoing the process maps will be greatly reduced.” That may be true.
But we’re not trying to streamline the process mapping process because we want to use the manual mapping process to drum an understanding of the processes into the brain of the person mapping them. Every time they manually update, change or redraw their maps, their knowledge of the process increases and gets further buried in their non-conscious (their deep smarts).
However, if they’re “automated” and are just moving boxes around on a screen, they are no longer drumming the process map into their brains. They are far more focused on the operational characteristics of the software than the nature and sequence of the process.
This is just one example of where automation actually destroys value. It converts “knowledge” into “information”. However, the brain can do so much more when it has “knowledge”.
Another example of moving from “knowledge” to just “information” can be seen with ‘to do’ lists. Some years ago I thought it would be great to have an automated, rolling to do list. Each week I’d add new activities, delete completed activities and reprint the to do list.
It didn’t work. What I lost was an understanding in my brain of what had to be done.
I was no longer processing what had to be done into my non-conscious, which we otherwise do automatically when we rewrite or update our manual to do lists. This background brain activity processing helps us organise the material and better manage our workload, non-consciously.
However, once you automate your to do list, it exists on your system (and possibly on paper as well) but not in your head.
Automation is fine where knowledge is not required. Where a series of steps can be driven by information or data to achieve an end; that’s fine.
But where the series of steps is dependent on generating knowledge, then automation will prevent or destroy this.
Therefore, when we look at our business processes, we need to assess which need knowledge to operate effectively and which need just information. Only the latter type should be automated.
2 comments
“Automation is fine where knowledge is not required. Where a series of steps can be driven by information or data to achieve an end; that’s fine” —- I whole heartedly appreciate this statement. Blind computerisation without proper documentation will convert all the well thought processes (more specifically engineering design processes) into black-boxes over a period of time. At one point, no one will know the real process for any required modification. Periodical manual validations(audits) are essential to preserve the Knowledge(process) properly so that no damage is caused to an organisation in long run. Then Organisations need not worry much about the exit of veterans/experts.
by Sandanadurai on April 26, 2008 at 10:55 pm. #
Sandanadural’s comments are quite accurate. A good example of buried knowledge is in many banking systems where ‘how they work’ is no longer known.
When involved in the revision of a major bank’s retail banking system we kept finding that many of the business rules and calculation bases embedded in the systems were wrong!
This is where true process management can play a role — tracking and managing the process and information flows, including the business rules — to ensure continuing integrity and relevance.
by Jed Simms on April 28, 2008 at 9:22 am. #