READING TIME: 6 MINUTES
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…
Would you like to implement robotic solutions that add real value to your business? We are happy to share our experience in selecting winning use cases as soon as you write us!
Original article: https://www.linkedin.com/pulse/processes-value-rpa-pipeline-creation-fallacy-balint-laszlo-papp/
