help desk software
+(800) 286-4232

One the most appealing parts of my RPA pitch is how RPA can be used to automate processes “as they currently exist”. Meaning, RPA can automate any process without requiring: modifications to the process itself, changes to the participating applications, or involvement of the applications’ vendors. Bottom line, RPA is an unintrusive collection of technologies that can automate virtually any existing process, warts and all.

However, this does not mean using organizations SHOULD automate a process, warts and all. Sure, there are some cases where, for whatever reason, a process cannot be changed. For example, at RatchetSoft, we have a large healthcare customer that could not change its existing messy process without getting regulatory approval from the federal government, which is incredibly expensive and time consuming. So, RPA’s unintrusive nature was just what the doctor ordered. But I consider this type of constraint an edge case and believe most customers can, and should, use an RPA project as an opportunity to wring-out process inefficiencies.

I was reminded of this important precept in a not so subtle, but quite effective way, during a recent project scoping session. At one point in the design process, I was asked to meet with “Jim The Intern”. Jim The Intern is the person who, at least for this semester, is manually performing most of the process we were automating. During my one-on-one with Jim, he leaned in as if to tell me a dirty little secret, and imparted this bit of wisdom.

“You know, I haven’t been here long, but I’ve been here long enough to know we’re not doing things right. I’m not saying the people here are not smart or good at their jobs, but I think our collective thinking is a bit stale. People have been doing things the same way for so long, they can’t imagine doing things any other way. They’ve instutionalized all kinds of bad habits and extraneous steps. It’s like they’ve been driving down the same road for so long, they’ve gown road weary and can’t see that new things that have sprung up along the roadside that may help. No offense (detecting I’m probably about his dad’s age), but when I talk to the older guys in the IT department, they kind of dismiss my ideas for improving the process because I don’t have a cool 1990’s war story about typing DEL *.* at a DOS prompt. You get my point? I think this RPA stuff is cool but we probably shouldn’t be burdening the bots with our mistakes.  Do we really want to automate the crap too?”

Message delivered loud and clear. Although I was a little concerned Jim the Intern sensed trace amounts of Clipper Summer ’87 still coursing through my veins, he was right. My zeal in playing up RPA’s unintrusive nature during the pitch played directly into the hands of a group of people hoping bots will paper over some long-standing process problems.

If the bots can perform these tasks more quickly and more accurately, does it matter if the processes are a bit inefficient? Maybe not, but we won’t know how costly those inefficiencies are until we know what they are, and why they are. In other words, to understand these trade-offs, it’s important to take time to understand the process within the business context. As a technology company, it’s easy for us to skimp on that part of the process and get to the fun part, creating the automations. Sure, projects come to fruition faster (i.e. close), and are generally easier to do when we put the blinders on and just do what the customer asks for instead of finding out what the customer really needs. But are we serving our customers best by giving them that out? Although we are first and foremost a technology provider and not a process improvement consultant, as such, we are exposed to many organizations do things across varying domains and serve our customers best by bringing that experience to the project in tandem with our technology. So, while I still plan to talk about RPA’s unintrusive nature in my pitch, I’ll also make sure to emphasize implementing RPA is also an opportunity to: re-examine the process within context, a time to question all assumptions, and minimize automating the crap.