You have identified this awesome opportunity to improve a business process within the business and now you sit down with the business manager, the procurement person or simply the purse strings owner and try to work out the cost justification of what you want to do. If you are lucky you have a lot of statistical data and metrics to backup your justification or argument but how you present that information could make or break the decision to make the investment. In the perfect world we are all rational, all reasonable and completely in agreement that reducing costs or at least containing them is the right thing to do. Of course as we also know this idyllic controlled economic situation dictated by numbers in business is hardly ever bound up by rational, reasonable thinking with across the board consensus. For every initiative that you trigger for process improvement which carries a cost burden, potentially starves some other initiative of funding. This week I spent a bit of time trying to play with an ROI calculator for automation. This could have become very sophisticated if I was a Microsoft Excel guru or an awesome statistician or actuary, but it will have to do in its current form for me and for illustrative purposes I share some of the thoughts around this with you here.
My experience is that accountants love ROI calculations, purchasers often can understand them (or pretend that they can’t), IT people generally hate them and business people simply accept that they have to provide them. ROI is important not just for new initiatives that need funding but sometimes even for existing ones to ensure that they continue to be financially supported. Dealing with ROI for automation with software whether it is for testing and quality assurance or operational transaction processing is hardly any different to any other kind of ROI that you might undertake to demonstrate value of implementation or adoption. The main reason an ROI is justified is because your initiative requires an initial investment; often an initial investment that cannot be funded with your operational budget or spending. ROI is an estimate of how much you need to spend and how quickly you can recoup that initial spend in savings, cost reductions or cost avoidance. The classic calculation then is benefit over cost.
With an automation tool the cost variables are likely to be the initial cost of the software licenses, any hardware specifically required for the software, training and time to produce the scripts. The benefits are calculated based on the time interval contractions by use of the automation tool over manual entry or manipulation. This time is then factored against the per cap cost of an additional person to do that work.
Where do you start?
- Begin by gathering your data
- Aggregate all the factors that are ascribed to costs. Don’t forget to include indirect costs.
- Add up any monetary and non monetary gains or anticipated gains.
Questions you need to ask :
- Are the metrics you collect meaningful for ROI
- What is missing, who can help you get that information?
- How will you work the data to your purpose?
- What is the business objective and how this contributes, is it aligned with the overall objective?
- What should you isolate/ignore and what is the overall effect?
- Consider “intangibles” that will contribute to success of the initiative
Using the simple model you could calculate that at $30 per hour a person that takes 60 minutes suing a tool to achieve a task that previously took 120 minutes is saving 60 minutes for every hour of use of the automation tool i.e. is avoiding another hour of person-time engaged in that task.
If the cost of the automation tool (loaded with all costs) is $1500 then all I need is 50 hours of use to save the equivalent cost of the initial investment
Manual Cost = 100 hours x $30
Automation Cost = 50 hours x $30 + $1,500 (cost of tool)
ROI = Benefit/Cost
ROI = (cost of manual – cost of automation)/cost of automation
ROI = ((3000 – 3,000)/3,000) x 100
ROI = 100% over the course of 50 hours
I could have got this wrong, but it seems right; or at least the numbers seem to make sense. The flaw with this approach is that it assumes that I can do the same ‘quality’ of job manually, that there are no ancillary benefits or negatives associated with my automation. Additionally it assumes that I have factored all the variables into my ROI calculation, such as training and capability to simply increase my time and myself infinitely.
Consider that this value calculation is based on 100 hours that is more than two man weeks of labour. Even if I could afford that time, the challenge will come if I need to invest 200 hours in the given process and have to achieve it by a given date. Very quickly my model becomes useless because I now have to impose constraints that I cannot easily incorporate. Quite simply I may not have the luxury of simply extending my hours. Replication may sound straightforward but as you will also know, certain resources are scarce and can’t simply be replicated. Try drumming up a VC modeler for your environment on short notice….
Quantify what you cannot monetize
The important thing to look at in your calculation is the real value of automation, when using a transaction automation tool, this may be something as beneficial as faster financial closing demonstrated by use of a tool like closingexpressfor the SAP Closing Cockpit; that in turn may lead to confidence in the management of the company by the stock markets by virtue of its ability to report its financial status in a timely fashion. The implementation of a given automation may avoid the hiring of a temporary staff member or a full-time one for that matter to cope with added workload; it may avoid some penalties or fees associated with non compliance or failure to meet a deadline required to report on or update data or it might simply reduce stress within a given business area or for a given person (yourself?).
Ascribing a value to these variables could be a useful financial measurement to appease the finance gods but it is also important in establishing your understanding of the benefits that you hope automation will yield, traditional ROI looks at past use and measures and often does not consider future yields. Even when these anticipated yields cannot be articulated in monetary terms they should be described as part of the non-monetary ROI. ROI does not have to be measured purely in monetary terms and even though finance would have you believe that monetary ROI is the best measure of ROI, there are sufficient real life examples (like charitable efforts) that prove that ROI is more than just numbers.
Credits to Michael Kelly at http://www.michaeldkelly.com/ for giving me some additional ideas on this topic.
The original posting is on SAP SCN here
