So today we read in ERP Focus Five Signs your ERP Project Has Been A Success. And frankly, I’m shocked – at first – then gobsmacked – then amazed – but I finally calm down enough to realize, well, yes, most folks DO approach the ERP project this way.
And that’s exactly why most ERP projects fail.
I don’t mean to denigrate author Rick Carlton – he’s a great source of ERP information and he’s just reflecting the common state of most ERP projects. His 5 tips to measure success starts with 1) ERP should make more money for the company – and his measurement is ‘check the bottom line at the end of the year for pleasant SURPRISES.‘
I hate surprises.
I hate surprises that cost buku-bucks and cancel everyone’s weekends off for the next 6 months to implement.
I hate negative surprises even more – what if we check the bottom line and find we LOST money?!?
So here’s where our Consulting Practice comes in. When we’re engaged on a customer ERP evaluation, the first, very first and most first thing we do is gather requirements. What will they want the system to do for them?
We make a nice list of these requirements. We print it up and send it back to everyone to let them have a look and see if there’s anything we missed. Everyone participates and we all pat ourselves on the back when we come up with a hundred or so ‘must have’, ‘nice to have’, and even ‘pie in the sky’ requirements.
But that’s just the start.
Let’s say we talk to our Baked Goods Manufacturing client and the Plant Manager tells us he needs better scheduling. Well, what does he mean by ‘better scheduling’?
Turns out he gets a Work Order for 10m chocolate twinkies – which he spends all morning cranking out through his various production lines and so on. Then, after lunch here comes an order for normal yellowcake twinkies – well, that’s a problem. See, he’s got to break down 22 manufacturing lines, including 73 injection molders to get the chocolate out of the feed tubes.
And now it’s Q&A time
Q: How long does that cleanout take?
A: Oh it’s just over an hour with all hands on deck.
Q: How many hands would that be?
A: 36 line operators plus 6 guys from maintenance
Q: How often does this happen?
A: Sometimes 2 or 3 times a week
Q: and what if you did yellow cake in the AM, and chocolate twinkies in the PM?
A: Oh, that’s a quick flush, going from yellowcake to chocolate, you don’t have to get all that chocolate outta there.
So it doesn’t take a whole lot of MBA-superpower-math-skills to figure out (42 person hours x average hourly salary) + (average hourly revenue of 22 production lines) + (1.75 times a week [rounding down because he was not exact] x 52 weeks a year) – well, turns out this is costing the plant $22,000 dollars to do it the way we’re doing it today. If the new ERP software has a scheduling module that helps us run yellowcake first, and we eliminate only half the chocolate washouts – now we’re on our way to saving $11,000.
And that’s just one requirement.
Did we mention that at a client last summer, we were brought in and they proudly showed us they already had their requirements documented. 24 items! We asked how they came about so many items – turns out they worked with one of the software reps putting that together. It also turns out all 24 requirements came directly from the software vendor’s website, and happened to be features his actual software delivered! What a coincidence!
It also turns out that by 1:00pm that afternoon, speaking with different departments, we had a list of 78 requirements. Many of which were issues no one had thought to ask for, because they didn’t know modern ERP software had those type of features.
In any case – you probably can’t run a cost analysis of every requirement, but you should be able to put a number on quite a few.
In doing this, we deliver what’s called the Cost/Revenue Model. This takes every measurable requirement that ERP affects, adds the avoided costs, eliminated costs, cost savings as well as opportunities for revenue enhancements.
And NOW we begin to get an idea of which ERP package solves which of these issues. The evaluation is much more focused – if manufacturing scheduling will save $11,000 and inventory visibility saves $2,000 – guess which feature we’ll prioritize during the demos?
We’re also getting buy-in from the managers. We’re in the demo looking at manufacturing scheduling and we’re asking the Plant Manager – ‘could you cut half your chocolate washouts with this software’? He now has a goal once the software goes live. And we’re doing this with each requirement.
In the end, we have done a few things:
- We establish the software budget based on how much ERP will save
- We create project goals and the methodology to measure performance to goal
- We know exactly how we will measure project success
- We create a cash flow model and payback/breakeven analysis to determine exactly how long it will take to recover our expenditures with the new software
And if you know anything about goal setting, you know setting a SMART goal increases your odds of achieving that goal immensely.
We set up our average client on an 18 month payback/breakeven target. Our best client paid for their software in a single quarter, most come in within 2 months of projected breakeven.
Expectations of success, a roadmap to achieve goal and best of all, No Surprises.
Instead of “How do you tell if your ERP project is a success?” you get “Here’s how you make your ERP project a success.” Guess which one succeeds more often?
If you would like to avoid surprises in your ERP project, contact Gene Hammons – email@example.com