Hi all - based on your experience, when calculating hours given back to the business, do you usually use the process names or queue names?
In the default ROI dashboard, it’s all based on Successful Process Transactions. Because the Jobs contains reporter and dispatcher, I only calculate the Successful Performer transactions. By default, I’ve been using jobs table for this calculation. I edited the ROI forumla so we’re only reporting on Hours Saved/Given back to the business based on successful transacitons as shown here:
SUM([ProcessId], DUPCOUNT([ProcessId]) * ALL([@Process Baselines.Manual Time(mins)])) /60
In your experience, what have you seen? Have you been using queues or jobs for time saving calculations?
That depends on how you’ve implemented the solution and what’s the standard you follow RPA implementation. Also, respect your views but suggest you to add more than just time saved to calculate the overall ROI.
If you have large number of transactions, then it’ll be recommended to have the Job’s information. We usually have a forecast report generator SQL script in DB that does the work of fetching the monthly job 's information as per our requirements of Column data.
Then those flat files serves input to a BI solution. They have total time of execution, errors with frequency, time saved using a formula dedicated to a process, trend for the types of errors, utilization per robot.
You can do it using queue too that is with less pain, just make sure all the information is passed to the queue and is consistent across processes, but most importantly make sure queues should be well archived timely, especially if they contain heavy data.
Both ways are fine, just see if you can have a common queue management protocol for all processes or you’ll be able to implement SQL batches.
More than happy to connect if you need more information on this.
Use whichever method gives you the best ROI to present to management
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.