Can RPA increase shadow IT?

I feel like RPA is a new buzzword. This stuff's been out there for a long time, it's just got a new name now for automating processes. Just think of a mac, it's automated and it's been here forever. It does the same thing. 

So RPA is not new, it's just that you need controls and some sort of governance around it. You need to go through and define what it is—not necessarily who can do it, but what the tool is capable of doing if multiple people are running different RPA processes at the same time. It's complicated. We're using RPA from a call center standpoint, whether it's an on-prem call center or contact center as a service (CCaaS). There are other players out there that are doing it as well.

I have mixed feelings about RPA. I did a half-successful RPA project. It worked great if IT was running it, creating the bots, and using it for processes within IT. Onboarding and offboarding are great examples. At the company I was with then, we were onboarding hundreds of people a month. With all the applications we had in Okta and software we had to deploy, it was impossible to onboard that many people.

So we made an RPA process where the HR person would say, "This guy's starting. He's an engineer, so I'm going to checkbox the engineer applications, and then hit go." It comes to IT, and IT says, "Yup, looks good. Approve. Continue." Then, in the background, the RPA bots are provisioning all the apps behind Okta. At the end of it, they send Okta in a link via email to the end user saying, "Here you go. Welcome to our company. Here's all your apps." Done. Then we'd do the same thing in reverse when somebody got offboarded. 

When we got SAP, the finance people wanted to write all these bots. We were okay with that but they also wanted to control the bots. We said, "Fine. If you have a problem, come talk to us." Soon enough, everybody was running all these bots that were overriding what other people were doing, and it caused a huge mess. After that, we realized that we needed a governance model to approve all these bots that we're writing.

People solve problems in a context they understand. That's what we're always battling with. You don't know there is a problem that needs to be solved because people have already solved it, at least in their view. My joke is that every ask that came into IT when I first started at one company was, "Build me a bicycle, make it out of Legos, and have it by Friday." The deadline's built in, I want you to use Legos because Legos are something that I understand, and a bicycle's what I think I need. When what they really needed was a moped, and it's actually a pretty simple buy. We can just go get one.

What I find fascinating about that is that the biggest Lego brick in every company I work for is Excel. You've got people using Excel for project management and event planning, and finance is using it for 80K-row spreadsheets. It's magical how much that box of Legos can do. I'll never forget a scenario I ran into where a financial planning and analysis (FP&A) guy was using a myriad of very complex vlookups across multiple sheets to build this model that he had to report on. His mean time to update the model was about a week—the guy was so busy that he couldn't even ask for help.

When he quit, the CFO called me because he was freaking out. When we got in and analyzed what the FP&A guy had been doing, I said, "Fortunately for you, this can all be recreated in an industrial strength way." But I feel for the guy who spent days or weeks of his life doing this thing. It was probably solving the problem in the most painful way possible—like getting your mail every evening by walking on your hands for no reason. Why would you do that? Just walk out and get your mail.