Whose job is Process Standardisation?

Every once in a while, I encounter with processes that are fragmented way beyond imagination. For example, I've seen a payments process that had 250 permutations, meaning that they processed every means of payment for every legal entities in a different way, at a different time for more than 15 years, while bringing the process to a Central European Shared Service Centre, and after a while migrating it to an Asian Shared Service Centre.

The company had multiple Continuous Improvement and Lean Six Sigma teams and experts in all its locations. I am not quite sure, whether they've managed to take a look at this process earlier either at a high level or at a keystroke level, but needless to say, when Robotic Process Automation (RPA) came to the picture, they stood there amazed that they thought this was just an easy peasy process that would require a maximum 10 hours sessions spent on process discovery (as they didn't have any documentations of course).

Surely, they wanted to have it all automated, but they had to face the harsh reality: within 10 hours, we were just able to discover the process for 1 legal entity with 4 means of payment. It only takes a quick math to realise, they'd have needed 500-625 hours just to discover the nuances between all the legal entities, not to mention the time and negotiations they'd have needed to standardise it across the countries and roll out with a better process.

Who should have done that?

Companies expect their own Shared Service Centres to optimise and standardise the processes they take over from several other locations, as they will have all the variations handled in one place. But were they really doing that? Did they have the authority to do this? Were they able to retain the expertise that would have been able to standardise? Did they have the courage to disrupt processes or they only felt like pleasing all the process owners they had? Whatever the answer is... it won't change the fact... they mostly failed in this.

The business model was to migrate the processes to Central European SSCs, where they stabilise, optimise and standardise the processes, and then Asian SSCs would take over to operate them. Now that the standardisation didn't happen after the first migration, they didn't even have the authority anymore to change anything.

But even if the processes stood at the CE SSCs, the employee turnover rate made it impossible to see through all the processes and reconcile them, as they only managed to maintain an average level of low expertise while performing them. You were lucky, if you had a Process Note telling you which button to push...

Who should do this now?

Well, you basically have three choices, when you have a chance to tackle a process like this for automation. First, you don't care about standardisation anymore, just building robots to do the exact same suboptimal tasks.

Second, you push the problem to a team that should have done the standardisation and wait for a miracle to happen for them to standardise it in the foreseeable future.

Third, you roll up your sleeves, bring in the people, who has the authority, the business acumen, the courage and the synthesising skills to transform the process, and then start to automate it, when it is finally optimal.

But choose your KPIs wisely

Robotic Process Automation Initiatives have plenty of ridiculous Key Performance Indicators (KPIs). One of them is the number of robots built. Even if we would have a clear definition of what we call "a robot" (hint: we don't have), counting them doesn't make any sense upon we want to measure the business benefits.

There was our company, with 250 ways of doing the same process... and you guessed it right, its RPA project had a KPI tied to only to the number of robots developed. So, instead of freaking out and ditching it from the scope of the project, or starting to standardise the process, they cheered that they'll reach their KPI faster. Now this is what I call a Robotic Armageddon...

When will we learn our lesson?

Doing things the right way actually benefits more than doing it faster and cheaper.

Simplification doesn't mean that now it is easier to click through a task because we prepared a Process Note to follow, so a high-school student with negligible IT skills can perform it. Simplification means that under normal circumstances you don't need 5-10 years spent analysing to see through and understand what's really going on in that process end-to-end. The least thing an unnecessary complexity can cause is a mistake... the other end is that it can lead to fraud.

#RPA #Budapest #Hungary #RoboticProcessAutomation