I have shared this story on stage a few times, but not in writing. It is the tale of one way not to do Robotic Process Automation. It is worth noting that my story is from 2013-14 when things were different. When I discovered RPA in 2012, it was a new thing and not many knew much about it. Having run global IT for a couple of major F500 companies in my last couple of jobs, I immediately understood the potential of this shiny new RPA tool. In my role at the time, I didn’t run IT, and the IT department had bigger fish to fry at the time. Not surprisingly, I took matters into my own hands…
To make a long story short, I made the decision to just go do what I needed to do. I wanted to do automation and didn’t want to take the year it would take me to explain and convince people of what task automation could do. The alternative: I could get pretty powerful laptop workstations without much notice. We had a lot of people and no one worried if we ordered equipment to have it ready for new hires.
And as long as my purchases of software were not that big, they didn’t attract a lot of attention. So a few laptops a week and a five-pack of licenses at a time it was. We were quite excited with our new capability. We were building and deploying automation quickly. There were some very attractive processes to automate in a shared service center that served up HR, finance and supply chain.
Automate we did! And in just a few quarters, we had 60 extra powerful laptops humming away on Costco shelves. We had to make a few air-conditioning changes to that one room that no one really ever went in and quietly worked our automation backlog queue.
It was about a year in that we were found out. Someone in IT realized we had some machines on our network really working hard. Oh, and there might have been a couple of network switches that didn’t match the standard. They came to investigate. My stash of CPUs was discovered and there was quite the scene.
People threatened to turn everything off, and others warned of the dangers in doing so to critical supply chain and HR processes if that happened. I look back and laugh, but it was a tense moment. Our IT group knew nothing about RPA, and darn it! These were computers! Computing! With software! Surely, IT had to have control.
You can imagine the discussions. What is it? How does it work? Is it secure? How do you control it? Who’s allowed to access it? What about the data? Where is it? How is it stored? And on and on. To say again, my story is one how not to do it. It worked out well in the end, but it illuminated what I now know to be possibly the single greatest and potentially fatal Stall Point: not establishing the right relationship with IT. Lessons were learned. Scars remain to remind.
So what is the right relationship with IT? It has seven hallmarks:
1) Automation is led by the business, enabled by IT
2) Provisioning, license control, and systems access have IT oversight
These things rightly belong to IT. They are accountable for the cost of licensing, and the secure provisioning of access to systems. They get the call when audit finds something wrong. So these thing rightly belong in IT. They need to have oversight, but do not control consumption. That is a business decision.
3) Infrastructure is an IT responsibility, particularly if using Highly Available (HA) configurations when automating mission critical processes
If an enterprise is going to use automation on important processes, particularly anything to do with compliance or involving money, then the system enabling the automation needs to be robust. Manufacturers go to a great deal of trouble to make HA configurations. IT is the only party who can make them a reality.
4) Security (InfoSec and Cyber) remain in the IT domain. Period
Not much more to say here. If you are putting software in your environment, IT needs to kick the tires. They are accountable for the thankless job of protecting the company’s digital assets. This is IT’s domain.
5) IT is represented on the automation CoE, but is not the decision maker
IT must be a part of your CoE, but only in the rarest of circumstances (such as when automation is being used within IT) should IT be in the decision chair.
6) Automation represents one of the best ways for IT to provide a way of “self-help” to parts of the business that will never be a priority for IT: the back and mid office
I come from a tech background and I remind IT leaders frequently that this is a miracle; to be celebrated. It’s a tool, that with minimal oversight and cost can give neglected parts of the business a way to self-serve technology solutions that solve a myriad of ever-changing challenges the operations face.
7) Automation lives somewhere between IT and the business. Most IT folks don’t make good automation leads. It requires deep process subject matter expertise
Some even call it ultra-light IT. The profile of people that are good at automation are usually tech-savvy SMEs from a part of the operation. In some places, the build and release process of automation is governed by the IT Change and Release Management processes. But again, it is critical to understand this is digital labor; an extension of the operation.
In a study done of about one hundred stalled program a couple of years ago, in almost half of them, the root cause was traced back to a fundamental disconnect in the roles, responsibilities, and accountabilities of the “business” and IT.
Every situation is unique. I’ve seen programs succeed with IT in the lead. I will disclaim that in these cases, IT is typically has a broader role than just the tech, but I have seen it work. Far more often, a failure to establish the right relationship with IT will bring an automation program to its knees. Next time, I will talk a bit about a related Stall Point: Procuring with a Limited View.