The Four Ages of Automation - Part 2
The first wave of processes is in production; exceptions are low, and confidence builds as successes are enjoyed. However, there is a realisation that automation is not plain sailing. Unexpected demands for operational support distract from progress as the need to maintain an ever-growing portfolio of processes becomes a burden. The bot platform is reaching capacity from the original investment, and there is pressure from an excited organisation to solve longer-term business issues.
The first wave of automation is usually 'as is' processes, rapidly delivered without process redesign or streamlining.
This description may not match your experience; however, these are common themes for organisations in this age.
Welcome to the Age of Enlightenment

In the Age of Enlightenment, organisations reflected on rapid growth and identified opportunities to bring stability and structure to their automation programme.
We need to buy more bots!
The fact that bots are cheaper than humans doesn't mean we should waste resources and grow our bots on a foundation of inefficiency. There are many areas to explore before expanding your platform.
Code efficiency - can our bots run faster?
It is fair to say that robots can run faster than humans. You notice I use the word 'can'. The result depends on how well bot code is developed. I've seen plenty of bot examples riddled with static waits or sleeps between actions. So, in this case, the process will consume the same time between actions rather than monitor the host application dynamically and speed up and slow down based on system performance.
Better use of data
Careful planning around data set manipulation will speed up processing time and lowers bot consumption. Using built-in automation platform features such as environment variables, queues and collections will help, and for large data sets accessing external data sources such as SQL databases or APIs will help tremendously and bring processing time way down.
Linear processing vs multi-bots
Linear automation is an end-to-end process that executes everything on a single bot. The best approach is to design your processes to run across all available bots simultaneously. This will eliminate a single point of failure and speed up the overall processing time.
The multi-bot approach will require bot code to be dynamically programmed with no hard-coded aspects and for each bot environment to be configured to the same system standards.
Scheduling vs Orchestration
In the early days, it is common for processes to be scheduled to run at a fixed time (almost like planning a recurring meeting in your outlook calendar). The challenge with this is two-fold. First, it leads to wasted bot idling time between scheduled processes as they will end at different times. Second, business needs and priorities are not considered as the ecosystem changes.
We spend too much time supporting our automation!
This is the Frankenstein monster I frequently speak about. Building your first processes using a defined set of standards is essential. This will improve performance but also lower the operational burden later on. It is a myth and a general misunderstanding that automation manages itself.
System application upgrades and changes in process flows will require process reworking. This is time-consuming if many objects are scattered across the environment that does the same thing. Object design and change control are critical to avoid this.
Exception handling, when done well, will allow bots to manage themselves. Business exceptions (transactions that need to be completed by a human due to defined business rules or data quality issues) should be clearly identified and passed directly to the business users benefitting from the automation. A clear explanation of why there is a business issue will save human time in investigating and will remove the operator from the support loop.
System exceptions (technical issues preventing the bot from continuing) can be managed and recovered by decent coding techniques.
The operator should be more about managing the automation platform than fixing process issues.
In extreme cases, I have seen a process that may save the equivalent of two people's time but requires three people to manage the exceptions. This is NOT automation!
We have demonstrated the power of the bots; now, we want them to do more!
As confidence in automation grows and engagement amongst staff is more widespread, there will be a surge of requests for automated solutions. If a governance structure is not in place now, it must be. To deliver more advanced business solutions, additional digital tools may be needed.