How do I prepare a practical ROI justification for an ERP system?

How do I prepare a practical ROI justification for an ERP system?


I have been approached with the question of how to prepare a practical and usable ROI justification for an ERP system. That can measure the results of changed operations to reflect what degree of financial improvement the ERP system has achieved. In my mind that is like trying to put a survey stake in the center of a sandbar in the midddle of a river whose current and strength shift the center of the sandbar almost on a daily basis. However you folks say you are the GOTO company on ERP questions so I thought I would ask.

~ Asked by Paul Ames

Answer From: Vince Benz, Jomax Consulting

The ROI is difficult to calculate based on the future success of the project. Most companies use the ROI or IRR for justification. Based on my experience there are 3 areas that can be used as hard savings in deploying an ERP system. People and the reduction of staff is one of the better returns based on the application footprint, the removal of maintenance costs of legacy applications, and the removal of support staff and 3rd party tools that support them, and finally, the annual care and feeding of new features and add-ons that might be included in the new software.

One example I can share is the ROI of adding automated testing to the ERP deployment process, I was able to find a 16% ROI by eliminating the onshore and offshore testing resources for the project. Most companies use the ROI for buying the software and justifying the project but lack the follow up and close out process to see what the actual costs and return were on the project. Your company may be different. Vince


Answer From: Gene Hammons

ROI studies range from informal walkthroughs of the affected departments to detailed business process mapping and transactional studies - that is, looking at each transaction the system will affect and measuring systemic improvement. (WMS guys are particularly good at this.)

We see far more hiring avoidance than actual cuts in headcount - that is, we're looking at a 20% growth rate and assuming since the staff is at or near capacity currently, we'll need an additional 20% staff hire - it's a rough measurement but across enough situations, it does prove fairly accurate. And one of the easiest ERP achievements is growing the business with the same support staff - no additional hiring, avoiding additional salaries, benefits, office space, extra donuts in the staff kitchen, etc. Other measurements are 'softer'. For example if we're putting our quoting and price matrix into ERP and a salesperson can produce a quote in 2 hours rather than 4, will he then shift that extra two hours into productive activities causing a 4% uptick in sales? Or will he take off early to work on his golf game? The key here is to get managerial buy in.

If the Sales Manager thinks he can motivate his crew to sell more with less systemic drag, he probably will. If he looks at you with crossed eyes and furrowed brow, probably not. It's also far easier to quantify operational improvements, manufacturing scheduling, fewer inventory stockouts, improved customer service, than some of the backoffice improvements - but they are there. As you work through the organization, you can create millions in projected savings. We like to do two things, One, factor in the learning curve - they won't come out of the box on day one with operational efficiencies - so build a 4-6 month learning curve into the front end. Two - assume the unknown - factor in a 70% miss rate - then, if you say you'll build 30 more widgets with new ERP (knowing you think you'll build 100 more) your numbers become more believable and more achievable.

Also - remember buy-in. If the department manager isn't ready to put his name on the 30 more widgets forecast, keep working on finding ways the new system will improve his efficiencies until he agrees. Sometimes you won't find it - but if you look deeper and let him vet the answers - you can deliver. There are dozens of studies that show companies who begin with these goals in mind are 80-90% more likely to achieve them. As part of the comprehensive process, we take this into the reference site visit area. For example, if we know we can save $10m with supply chain improvements - prior to purchase, we're asking the vendor 'who's your best reference site in regards to supply chain?' And that's who we're going to visit to learn how they've done it - who was their consultant - what problems did they encounter and how did they ultimately solve the supply chain conundrum.

ROI costing of transactional improvements drives selection. If you do 40k invoices a week you're looking for a different system than if you do a dozen a month. And even though Ed in supply chain is very vocal about his needs, if he's already running a tight ship and a new system will only result in 0.002% greater supply chain efficiency, we better be looking at ERP packages with automated invoicing to tackle those 40k invoices. But here's the real secret. Once you've set these goals, you're going to have to manage the implementation to deliver the expected functionalities. The software consultant has no idea you've promised 30 more widgets and he's hell-bent on setting up the system just like he set up the last 10 systems he worked on regardless of your goals - which may or may not work for your end user who's counting on a certain feature to produce those extra widgets. Yes, it all ties together. But if you don't do the ROI study - it always, always comes back to bite you. Did I say always? You may not realize it, but it does. Sometimes in subtle ways that just means you never reach goal. Sometimes killing the project all together. Had a client last year trying to take a $400m Pharma company from contract manufacturing to building a new plant and bringing production in house. Day one, everyone in the room agreed we'd save $14m in outside costs - so there was no need for a formal ROI study. So we spent $1.5m on software and services, were halfway through the project when there was upheaval in the Ops side, CEO cleans house, calls in his oldest, most trusted OPS guy out of retirement - unretired him, and we saw the entire project killed when the 70+ year old VP said basically, "Software? I don't need no stinking Software." It might have been a different decision if we had the backing to respond "you do need the software if you want $14m in savings'.

More ERP projects will die when project excitement wanes, and budget gets shifted to other priorities - we know that automated bread slicer will give us 60,000 more loaves an hour - which looks like real money, especially to someone who understands bread baking at a professional level - and that ERP project is...nice to have? (Easy decision for management, one that ERP rarely wins.) You want to spend how much on staff training? A three day class in Chicago? What for? If the answer is, "To achieve our goals of $17m in savings with the ERP package" - it's a different decision. It always, always comes back to bite you.

author image
Richard Barker

About the author…

author image
Richard Barker

Related articles