Intelligent automation is transformational. It is not a fad or just a project. Enough people know enough now to say that can bring real enterprise value. Even if we take its most modest benefits, efficiency or “hours returned to the business” – we can clearly quantify material financial benefits. Task automation targeted at this most fundamental benefit is where most people start and for good reason. There is a lot to learn about how to do automation well. It is a relatively safe space to build the muscle you will need if you want to have hundreds or thousands of bots in production.
As organizations find and automate burdensome and repetitive tasks, tens or hundreds of thousands of hours can be returned to the business to spend on more value-add activities. Now, more than ever, as we are faced with resource constraints as well as working from home, task automation should be a priority for every automation program. I always recommend a balance of about 50:50 in task automation to intelligent automation. Use the capacity freed up by task automation to go after the transformational benefits of intelligent automation (more on Intelligent Document Processing and cognitive automation later).
So why do so many automation programs Stall in what I call the “single digit hole”? Meaning, the program gets five or eight automations in production and then grinds to a halt. By far, the most common reason is not having a Design Authority. Well, what is that you might ask? The Design Authority provides for about ten critical things:
- Business process documentation standards
- Automation logic configuration standards
- Reusability standards
- Maintaining the library of re-usable objects already created
- Teaching and propagating the re-use of those objects in configuration
- Testing and acceptance protocols
- Build documentation standards
- Production support process documentation
- Release Management protocols
- Change Management protocols
- To implement the automated process
- To re-implement the remaining/adjacent human processes
- Design Reviews
- Configured code review
- Documentation review
- Monitoring of Release
- Final sign-off and “Ready to Release” review
This all sounds like it might be a lot of overhead administration. It doesn’t have to be. Start small but with the end in mind. Thought must be given to all of the design authority factors and elements. Every part of Design Authority is intended to minimize the “brittleness” of automation, ensure high standards for config and documentation all so that once the automation goes live, it stays live, can be supported, and all goes well during Release to Production.
When we autopsy stalled programs, we inevitably find a lack of Design Authority in the root causes. You can “wing it” for a few automations, but very quickly the automation will start to fail, sufficient documentation doesn’t exist on what exactly was configured into it, and the person that built it doesn’t even work there anymore. So it doesn’t get fixed, and the business will have no choice but to go back to the old way of processing. When that happens two, or three or four times; the business gets automation fatigue, the program slows, and it might not ever get moving again. We find about half of stalled programs fit this mold.
This stuff is not rocket science. It’s simply good hygiene when you are setting about transforming processes. The truth is intelligent automation is not a thing we do. It’s a way we do things. It’s a decision to do things differently, bringing together design thinking, task automation, and some sound management discipline to transform processes and business operations.
While it’s not rocket science, your program won’t make it to a stable orbit without it. We’ve done it a few times. Give us a call if this sounds like this might be part of the problem in your program or you need a diagnostic to help improve your program.