The moment of truth is here. Go-live day is always exciting.
Rather than a big-bang switch on wherever possible, we try to release a single live transaction through the bot engine and monitor the logs, the transactions queue, and watch the virtual worker session. The frequency of transactions increases to the point we are running in real-time mode.
For bot processes that need to run in real-time 24×7, for example, the urgent treatment centre patient registration for the first few days, a human monitors the control room regularly. I am sure this approach is way too intense, but when our bots are dealing with patients, I need to be absolutely 100% sure that everything runs smooth.
As a lot of my readers know (although many people doubt), I freely offer my help and advice to any organisation, across all sectors. I am always amazed to see automated processes running with exception rates of 48%, some even 80%!
Is this really what we should be aiming for? Some of these processes developed by an external supplier should know better. I believe failure to go-live with a low initial exception rate is only down to one thing, a poorly executed development lifecycle. Adopting a philosophy of intelligent automation and being disciplined in your approach doesn't lead to a long development lifecycle. Myself and my team operate on a 3 to 8 week development cycle depending on complexity.
I hope this series of blogs sharing an overview of my development lifecycle is helpful. It is an approach and technique that has been developed and adopted over the last two years. All I can say is that it works very well for our team at ESNEFT.