RPA Process Analysis: It's more about the Whys than the Hows

In Robotic Process Automation, robots "are working the same way a human would do". At least that was a key selling point back in the days. And now, after many failed projects globally, we start to realise that the fact robots can work in a similar way humans would interact with applications doesn't mean these robots should copy what humans did in the first place.

The story of an average business process

There's a good chance that our business processes has been put together in a hurry back in the days, using technologically subpar solutions that has been executed by humans. So they hired someone, or a group of people to learn how to do it and then perform it accordingly.

From an operations point of view, this was way faster, cheaper and causing less friction within the organisation, than including technology-savvy process experts, wait for rounds and rounds of internal meeting and discussion, start a costly IT development, and in the end, getting lost in the corporate bureaucracy or running out of budget.

When these processes are handed over from human to human, even if the process executor do know or slightly remember, they seldom focus on why it has been executed like that, but in order to shorten the time needed for the transfer, they only tell the steps that are necessary to be conducted in order to get the expected output.

And as time passes by, a suboptimal solution that was born in a firefighting turns into:

We've always done it this way...

Lean, Six Sigma, BPR, etc. projects came and gone, but no one really looked at those processes at a keystroke level, so we ended up doing the exact same garbage only with less and less people involved. At a high level, it would look like that it is the most efficient industry-best practice, but at its core it's rotting with no clear decision making points, lacking 21st century digital solutions, and drowning in tons of paper stacks (at a company, it's 86 kg/employee p.a.).

And then, RPA came...

Consulting firms came with a shiny new tool saying that: "Hey, I've got a solution on how you can speed up these processes without a costly IT integration or process amendments!"

It's only natural that most firms said yes to this promising technology, why wouldn't they? So they started placing robots to these processes without a second thinking about whether the process is working properly in the first place. Consultants didn't dare to challenge the keystroke level details, they commanded their developers to develop them as it is.

Garbage in... Garbage out... It's as simple as that...

The success rate of RPA projects came down to forty something percent. It's no wonder that an inefficient process became dysfunctional at a high-speed when they started to conduct it with robots.

They immediately started to blame the technology. They desperately wanted process mining, intelligent document processing, machine learning, and artificial intelligence to be their saviour, while there were no documented processes, they were printing out Excel spreadsheets, and they seriously needed a digital transformation in the first place.

The state of technology at those processes are just one part of the problem. The other is that no one in these projects was able to propose process improvements at a keystroke-level.

The first RPA robots have been built by IT developers, who didn't even know how to use general office technologies (like Excel) properly, since it's not their field of expertise, hence they were forbidden to make any changes. Their task was to build the exact same processes to be conducted with RPA solutions, while arguing why the cell in C1435 was not coloured in purple, and the e-mail with "UGRENT" (no, not urgent) in it's subject wasn't marked with a red flag. There's no wonder why they failed.

The Business Analysts never had to deal with processes that deeply, so they lacked knowledge on how it could have been done better, as they didn't understand the core business intentions of those processes, and based on that, they couldn't determine whether the execution is optimal or there's a way to reengineer them. Their task was to simply write them down as it is in details. And they usually failed, since there was no processes in the first place.

By that time those, who conducted the processes didn't even had the knowledge why that process has been built like that, and as they didn't see the big picture, they didn't make any changes in a fear that somewhere down the line, it would cause troubles. They failed to transform and standardise, as they were not empowered to do so.

In my experience fragmented processes, no standardisation, lack of digital solutions, lack of process understanding and the inability to transform these processes to optimal robotic solutions led to the industry-wide disappointment.

And now we start to understand that:

The Why is more important than the How

If there's something weird and it don't look good, who you gonna call? No, this time, it's the MythBusters. Printed papers flying around are not a substitute of a good workflow tool. An Excel table is not a good way to store tens of thousands of records that is used by several departments simultaneously. You don't need to convert an Excel table to PDF before sending it out to someone. That Word template is really not that mandatory for standard internal communications. You don't really need that cell coloured in cyan. Yes, you can ask them to fill out that form, they don't need to send the details via e-mail.

There're just so much myths to weed out that would make our life easier, our robot developments faster and more successful, and our robots more stable.

We need to rediscover the way these processes should have been done so far.

It's not an easy task, you need to build a serious understanding on what the original business intention was when they created that process, whether that process is still necessary, and if it is, you need to assess whether there's a better way to fulfill the core business intention.

For that, you need to ask a lot of question. Mostly five whys to find the core intention. I can guarantee that many times, you'll bust a myth after the second or third why, because they won't have a clear and deep explanation for a nonsense they don't understand themselves.

And then, you need to investigate. Investigate whether eliminating a myth is feasible, what the technical alternatives are (digital transformation), and whether there's an impact on other places of the organisation.

And you need to negotiate. You will need to negotiate for a new, more optimal process, you might need to propose changes for internal regulations, changes in other departments' processes, because you are just about to throw a huge rock into the swamp that might have been stale for a decade now.

And after all these, when you have a digitally advanced, well-structured human process, then you can start to think about a robotic process solution. Anything less than that is just kicking the dust under the rug with the effectiveness of another Lean, Six Sigma or BPR project that has been conducted for decades now.

#RPA #Budapest #Hungary #RoboticProcessAutomation