Hope everyone’s well. I was asked a question regarding our estimated time savings and was hoping to post the question out to others here for a wider point of view.
If a bot runs every 30 minutes throughout the day, every day, and takes 5 minutes to run, it runs (48x5x365=) 1460 hours a year. Does the bot save 1,460 hours a year?
Or if the person who ran the job used to run it twice a day, and it took them 10 minutes each time does it save (2x10x260=) 87 hours?
Basically, does it save the time it took the person to do it, or does it save the time it takes the bot to do it? Or is it a mix?
I ask this because we always used to give 87 as our answer, as that makes sense, but we now have automations running for processes which weren’t possible before but are hugely useful to be run. If they weren’t running before, or were running on a greatly different schedule, how do you measure the hours they save?
Saved means that the process was manually performed previously by the employee. Now the RPA process, by performing the automation, saves that time. In your example, it saves 87 hours.
Concerning
If they weren’t running before, or were running on a greatly different schedule
I believe that the Process Assessment Tool provided by UiPath within the RPA Business Analysis Fundamentals course ( Link here ) could help you
Thanks for your input - but again, it’s not “freeing man hours” as it wasn’t done before? It’s adding benefit for sure, but how do you assess an added benefit that wouldn’t be possible with a person? Such as chatbots - it’s not like we used to have a PA that sat there on teams and fielded everyone’s queries, but the bot still saves everyone some time. That’s the sort of angle I’m trying to look at here, if that makes sense?
If it saves time, then somebody is supposed to spend that time.
When the process is new, then in order to determine the amount of saved hours, you have to see how much time this new process would take to be manually completed by a person. This would be the saved time.
I have no doubts that you are aware that this is an estimated time and it can be quite subjective sometimes.
I’m afraid that something better that the Process Assessment Tool we don’t have at this moment…
The thing with some of these processes though is that it would take a person their entire working life to do them, and so our CFO is questioning the hours saved as realistically no one would ever be doing that. This is more of a philosophical question than a logic based question I suppose.
As you said, best current way could be to estimate the hours it would take a human, which if we go by my example in the OP would be (4810365=) 2,920 hours a year, and it’s that figure we’re getting push back on, even though rather than use the human figure of 10 minutes we went with the bot’s 5.
I was just wondering how other people had justified those savings, or if they accounted for them in a different way?
This is a good question and scenario that comes up a lot with our clients. Even if it is a new process you can still estimate manual effort if a human was hired to perform the task. However, is this process ongoing or temporary to clear up a backlog of items? If it’s the latter then you can extrapolate how many resources you will need to complete the backlog in one year to better justify your time savings.
Even if it will be an ongoing new process, it can also be related to a “Cost Avoidance” or “Capacity” scenario where no additional resources would need to be hired. Either scenario, I don’t see any CFO not liking the ROI if the communication is properly delivered.
These would be ongoing, and I did try to paint them as “cost avoidance or capacity”, I was just ask to double check with IT and clarify - he’s extremely prudent which is good, it’s useful to push back on hours saved so we don’t over-inflate our savings, I was just wondering if others had been having similar conversations and how they’d justified these.
One question was “well if the process wasn’t done before, why didn’t we automate something which was already being done to save associates’ time and revisit “nice to haves” later?” and that’s one thing I’m struggling with answering sometimes.
I have also run into this same problem. However, the only good answer is to build an appropriate backlog first.
Let the C-level team make a strategic or tactical decision based on a healthy pipeline of at least 5 items. You can only make recommendations but you need to be able to compare the “nice to have” against something in the pipeline. If you are utilizing the Hub, you don’t need to get as far as creating a PDD to get enough information for your detailed assessment to help make a decision.
Otherwise, if its your first process, start with an easy process that can provide immediate value.
Thanks again for replying, sorry I missed it by 3 weeks!
We’ve got 20 or so live automations and a fairly healthy pipeline - this thread was just based on feedback from c-suite about some of the numbers which were in the report we shared (generated from the Hub). We’re actually lucky in that we as the RPA team get nearly full autonomy in selecting our projects and priorities, we just need to explain/clarify why.
