How to Think About Intelligent Process Automation

Filling the IT Transformation Gap
Shaun Dawson, CEO at Robiquity, Inc

In the early days of robotic process automation (RPA), when I was part of a process go-live, we were contacted by the IT department, who insisted on meeting up to understand what we were up to. The meeting majored on the desired IT controls around the project, one of the big ones was the change control process, which consisted of 4 different work streams and about 97 steps. Amazingly, the typical time to go through this process for a ‘rush’ fix was two weeks.

Now, I‘ve been responsible for highly available web-based services for over 20 years, so I understand the need for production release processes., but I also know that in a RPA context, if we’d abided by this lengthy process, we’d be dead in the water. So, rather than argue, I brought the question back around to the business requirement. I said, “OK, this is fine, and we’re happy to do this. We just need to make sure that this process can be executed within our SLA of four hours.”

This short timeframe is impossible to deliver with the restrictive IT release process, and it really laid bare the reason that RPA exists at all, which is that many processes are simply not economical to automate the IT way. Instead, we give the business a sandbox in the form of RPA tools, and let them run an independent automation program. Thankfully, the IT person was smart, and saw that we not only needed a better way to proceed but this was a golden opportunity to enable the business to solve some of their own problems – rather than always knocking on the IT department’s door. We got the issue resolved, received permission to run our own change control process, and successfully went live on schedule.

I don’t think that there is much confusion these days about what RPA is or does, RPA is software that mimics human actions and allows IT departments within organizations to offset bandwidth constraints by giving the business its own sandbox to automate certain processes. As a result, IT can direct their attention to more mission-critical initiatives. IPA, in turn, is an extension of those concepts to include emerging technologies like NLP, ML, and AI.

Despite the definitions for RPA and IPA being relatively clear to experienced practitioners, ask them where RPA and IPA fit into the overall business transformation landscape, and you’ll get something that hovers around the truth, but with quite a bit less clarity. The resulting confusion, in my experience, can really impact the development of an IPA practice, especially early on. What follows is the analogy that I use, and I have found that it serves us well to help understand how to deal with the myriad of issues that pop up as we get things going.

Rocks vs. Sand

Imagine an empty box which represents everything a particular business must do to create value for the world.

Within that box is a smaller box which is the subset of those activities that could theoretically be automated using today’s technology.

It is the job of the IT department to fill that inner box, but what they can fill it with are large, weirdly shaped rocks – systems / technology. They must find rocks, carefully inspect them, and then place them into the box so they fit perfectly and align with all the other rocks.

The IT organization packs that inner box as tightly as they can with rocks, but because they are weirdly shaped, they do not fit together perfectly. There are spaces between those rocks. These spaces represent activities that humans still have to do that machines would be better at, and those activities are thrown over the wall to the business, which throws people at the problem, and gives them generic tools such as SharePoint, Excel, Outlook, and so on. This is where RPA/IPA comes in as the set of tools, techniques and best practices used to fill these spaces – not by using more rocks – but with sand instead.

If you think about the difference between pouring sand and placing rocks, you can get a good feel for the major differences between managing IT transformation projects and working with a good IPA practice, and it can help you avoid some of the pitfalls.The first of these is that while IT transformation can be thought of as a series of carefully planned projects, an IPA program is a practice, involving opportunity identification, development, and operations. Within IPA, you cannot afford to deeply inspect each grain of sand. The best we can do is confirm that we believe that there will be ROI if we continue with any particular opportunity, and if we get farther down the line and discover that there is not going to be ROI, discard the opportunity and move on to something better.

Second, placing rocks is very painstaking. You will inspect, in detail, every single rock, place it just so, and hold it in place until its neighbor rocks are in position. You would never take that same approach with sand. You just pour it in. If some of the sand isn’t perfect, or spills over the side, so be it! This translates to the IT vs. IPA question by recognizing that IT projects, by their very nature, require a great deal of scrutiny and control to make sure that the business is enhanced, not harmed, by the incoming technology. For IPA, the controls are already in place, since we’re interacting with the user interfaces of the applications involved. Get to production fast and early and iterate. If something does not work anymore, throw it out!

Third, don’t take on huge projects in your IPA practice. I have said for a long time that if you can’t get something to production within 6 weeks, you’re not talking about an IPA project. This is my “Six Weeks to Glory” mantra that you may have heard me drone on about. Especially in the beginning, focus on the quick wins. Consider big projects later, as these are more likely to get picked up by the IT organization anyway.

The final parallel I’ll talk about is measurement. Measuring how many rocks you put in the box is simple. You just count them. It is easy to forget to keep track of the business value that your IPA practice is generating, but I can promise you that if you fail to do so, you will end up having difficult conversations when times get a little rougher. I recommend keeping track of the expected benefits and cost of every opportunity throughout the lifecycle of the automation. Bottom line: if you don’t have a graph that shows, in no uncertain terms, the value of your IPA program, you need one.

Growth – putting the Intelligence in IPA

IPA is good for filling the gaps between the IT system rocks, but there’s another place it shines as well. To illustrate this, we need to expand the analogy a little bit. The inner box we’ve been talking about actually gets bigger over time, and it takes the IT organization some time to rearrange the rocks and add new ones. IPA is perfect for addressing these emerging gaps.

The growth of the inner box happens for two reasons:

1) The business typically grows, or at least what it must do to keep delivering value for the world changes. So the larger outside box gets bigger or it changes. Since the inner box is a proportion of the outer box, that inner box changes as well, in shape or size. The IT department needs time to get new rocks to fill in those additional gaps or replace rocks with bigger rocks. IPA creates value by helping the business to swiftly fill those new gaps in the inner box – rather than waiting for IT to try and solve it.

2) The pace of emerging technologies means that the types of things that can theoretically be automated using today’s technology increases over time. Again, as the inner box grows, IT takes time and energy to figure out which emerging technologies are applicable to the business, and to get them integrated. IPA is profoundly useful for trying out these emerging technologies and getting value out of them quickly.

Long term prospects

There is one more place where the rocks and sand analogy can help us, which is in thinking about what an IPA practice looks like long term. If we think about the sand as a way of filling the gaps between rocks, and to fill in the spaces as the inner box changes size, then it is natural to think of the IPA practice as a structured way to try out solutions that can later be matured into IT solutions. In a well-run, fully mature IPA practice, this is often what we see. The IT organization seeks to eliminate bots as part of its release planning. This means that quarterly or annually, when IT sits down and plans out what they’re going to build next, they can look at the things that business built bots for and determine if there is any ROI to be had by adding that functionality into their core systems.

Key learnings

One key takeaway of this is that organizations really need to understand their costs and benefits per automation – what are the hardware costs, license costs, and costs for implementation and maintenance, and what are the benefits on a per-automation basis? Obviously, this is particularly important if your practice is used to influence an IT transformation roadmap – i.e. if a particular automation costs $10K a year to keep running, what’s it going to cost to build into SAP? If there isn’t ROI, then it really doesn’t make sense to build it – just leave it alone. By the way, this answer will change based on where you are in an upgrade cycle.

Robots do not need the same controls that IT projects do. Since bots use the UI of an organization’s target applications, we are are already protected from a lot of things. Most bugs result in the bot not working at all, as opposed to working in some way that harms the organization. And most of the other ways a robot can “misbehave” aren’t much different than a human making a mistake. Realistically, systems prevent the user from doing something too reckless, and the fact that there’s a complete audit trail of everything the robot does and that its behavior ties back to a specific developer means that nefarious behavior is less likely.

That doesn’t mean that robots don’t need controls at all, though. They just don’t need the same controls as IT projects do. In a human process, there are certain “built-in” controls that we might take for granted. For example, humans can’t operate at the scale that automations can, which means that robot mistakes can add up fast. And no human operator would ever put in a number in the billions in the “amount” field for a check, but a robot would do that happily, all day long. All of this means that we need to think about the controls we’re putting into place. Don’t saddle me with a two-week long change control process, but perhaps do insist that I put a range check on every value that gets typed into any system.

Final thoughts

Ultimately, there are important but subtle differences between the way that you would build and run an IPA practice, and the way you conduct IT transformation projects. It’s necessarily different in ways that aren’t obvious, which is why it pays to leverage an experienced partner, and only one that’s 100% committed to this type of work, is best positioned to help.