Processes with No Value - an RPA Pipeline Creation Fallacy

Processes with No Value - an RPA Pipeline Creation Fallacy

It's not a secret that before I started to deal with Robotic Process Automation (RPA), I worked at several large companies mainly in the mid-, and back office functions doing the exact same things I'm advising to automate nowadays.

Based on this hands-on experience with processes that are more suitable to be conducted by robots than humans on a daily basis, I advise RPA teams to look into more about why a process is conducted in the first place, and if it is a part of a much bigger picture, start cleaning them up by consolidation and standardisation before turning to automation. If we don't do these steps together with a digital transformation initiative, we might end up with an unsustainable RPA even though it's not the fault of the technology at all.

The steps we take before turning to automation are just as critical as defining, designing and building an algorithm (robot) for conducting our processes. But with all these, are we thorough enough to focus on the real value of processes, or are we automating just for the sake of automation? Let me tell you a couple of stories from my pre-RPA "career":

Yes, I like to correct the same mistake... every single month!

I can hardly remember the specific details of this process, but the nature of the problem was that a withholding tax was booked incorrectly to one account instead of a different one... So my job would have been to check that general ledger account monthly for that erroneous entry and make a post so the amount is reflected on the proper account afterwards...

And I was like: how ignorant do we need to be not to find the source of the mistake and correct it there instead of patching the problem by conducting extra work? So I needed to send like 3 e-mails to find out that the person, who did this mistake didn't even know that he was doing anything wrong, because that account was set to be the default for him when he was making that transaction. They changed the process on their side, and poof, I had one less task to do.

Calculate the value!

This one is a classic... I was given a task to calculate the value of around 150 trades one-by-one for a monthly valuation task. It took around 1.5-3 minutes to calculate one depending on the server's calculation capacity and the complexity of the deal, so you can guess that this wasn't my favourite process at the time, but people were conducting this for years before me. I couldn't accept the reality that this was the best way to get the unadjusted value of such trades. So I raised an IT ticket in hope that they know a better way to get these out somehow.

Guess what, they knew a better way! As it turned out, the system has already calculated the amount on every closing cycle, so it took around 3 minutes altogether to get the results. Just imagine that a 1.5 hours long chat with an IT guy can save 60 hours a year, and I didn't really need to use any automation, only a VLOOKUP in Excel. So, 300+ hours well wasted in the previous 5 years...

Hello! Are you there?

I needed to send a couple of information to fellow teams, as we thought these are essential information for their jobs to do. Well, I was always a bit sceptical about the reports I needed to send automatically to people I didn't know anything about. So one day, I decided to put the following request to the top of the e-mails: "If you still need this info in the future, please reply to me!".

Well, 3 out of 4 hasn't replied so I knew they don't need this information anymore. The 4th one came back to me saying: "Geez, are you still sending this? I don't even remember why we needed this back then!". Fair enough, 30 minutes less work for me, mate.

Faulty metrics

I could go on with these kind of stories, but I guess now you get my point: the fact that a process exists doesn't mean that it has a purpose or it is necessarily creating a value that justifies the cost. That's why I encourage everyone, who think that the single source of truth for measuring the benefits of RPA is the number of FTEs saved, to reevaluate their metrics.

What value would you put next to your processes? What are the possible consequences if you'd stop doing them? Are there any alternatives that are available for conducting them?

The value of a process equals to the value of the benefits it supports to achieve and the value of the unfavourable consequences it helps us to avoid.

These processes above had an FTE cost, surely. If you consider that a month-end-closing needed to be done in 5 working days and there was a plan to shorten that to 4, half a day per month worth like 0.125 FTEs! But would you rather spend money on building and operating robots for processes that has no intrinsic value, or make some calls and write some e-mails to eliminate them altogether?

That's why we need to revise, reevaluate and restructure our end-to-end processes, instead of just throwing robots to tasks in the middle. The former is the most valuable... the latter is just too easy...

#RPA #Budapest #Hungary #RoboticProcessAutomation

Priya Patki CSPO?

Principal Domain Specialist | Strategic Product Consultant | Agile & Digital Transformation Expert | Automation Evangelist

4 年

Don't fix what is not broken! Simple.

回复
Kerry de Vore, MBA, PMP

Program/Project Management | Process Improvement | PMP | Global Business Services | Strategy & Operations

4 年

Balint, great article and examples. When I worked with automation, we didn't want to automate a bad process. Sometimes that meant improving the process prior to automation sometimes the recommendation was to stop doing the process.

Shail Khiyara

Top AI Voice | Founder, CEO | Author | Board Member | Gartner Peer Ambassador | Speaker | Bridge Builder

4 年

Well said Balint. Would be interesting to know the over capacity, ie Un-utilized bots within the roughly 12k customer base, in the overall market.

回复
Thomas Le-Rademacher

There’s a difference between being busy and being productive

4 年

Thanks for reiterating this, very well put. In most cases automation should be a last step. I know there are many different methodologies, but lately I’ve been thinking about Capgemini ESOAR process to avoid exactly these issues. Thanks for the post. https://www.capgemini.com/us-en/service/business-services/enabling-technologies/esoar/#

Francis Carden

Analysis.Tech | Analyst | CEO, Founder, Automation Den | Keynote Speaker | Thought Leader | LOWCODE | NOCODE | GenAi | Godfather of RPA | Inventor of Neuronomous| UX Guru | Investor | Podcaster

4 年

People just want shot of the process and because RPA is apparently so easy, why even bother with all the words you used in your post. However, your post nailed it. If people took the time to learn how you think and what other technologies and solutions existed, probably half or more of the failed or low value RPA bots wouldnt have seen the light of day. Better technology exists today than standalone RPA and even then, starting with collaboration and common sense, will prevail. Screen scraping RPA has its place but last resort and end of bot strategy even then should be part of it. Good post.

要查看或添加评论,请登录

Balint Laszlo Papp的更多文章

社区洞察

其他会员也浏览了