Define ‘failure’

First up. What’s an ERP?

ERP = Enterprise Resource Planning. Three of the most boring words ever, assembled to create one even more boring string of words.

But what an ERP can do is not boring. It’s a system that does everything:

• Inventory planning

• Invoicing

• Payments

• Accounting

• People workflows

• Capital expenditure

EVERYTHING.

It takes the complicated things in a business and swallows them up into one beautiful big black box.

Sounds dreamy. Well kind of… unless you are one of the poor souls who has to implement that ERP system.

Worst case: it takes forever, is f*cking horrible, and costs 10x what you budgeted…

AND grinds your biz to a halt while you fix it.

Best case: it takes forever, it’s f*cking horrible. But you get there in the end and you have a more resilient, efficient, future-proof business.

There is a quote attributed to McKinsey that “70% of ERP rollouts fail.”

If I had a penny for every time I heard this.

I’ve heard it quoted in boardrooms, by other CFOs, CIOs, by ERP implementers. Not to mention McKinsey themselves in a pitch.

I don’t know if it’s right. But it sounds true. In fact, if you define a ‘failure’ as an ERP roll-out that does not deliver on ‘timeline, budget, and specification’, I’ll bet the failure rate is far higher than 70%.

The stat, phony or otherwise, has survived and multiplied because it resonates with people’s lived experiences.

When you meet another CFO you can tell by the look in their eyes whether they’ve lived through an ERP rollout or not.

It’s like seeing into Frodo’s eyes before the ring and after the ring. Forever leaving a scar on the psyche.

The first time you roll out an ERP system as CFO, you will underestimate the complexity and resource drain that comes with it. However hard you try not to, it will still be harder and more resource-intensive than you think. I promise.

My last ERP roll-out (for one business unit to move off of a legacy system) was delivered 6 weeks late and cost 20% more than promised. That probably sounds bad. But I’m delighted with this. I kept a contingency up my sleeve to fund the overspend, and I can live with the six weeks.

Far and away the most successful implementation I’ve been part of. I’ve seen some total horror shows.

Knowing how badly these projects can go is the first crucial step toward ensuring they go well. Or at least as smoothly as possible.

9 tips for avoiding an ERP rollout nightmare

In September’s special edition, we covered the top tips for selecting the right ERP system.

This week is part 2 of that piece. 

We dive into 9 practical tips to prevent your ERP rollout from becoming a f*cking nightmare.

I’d like to thank my friends over at Rillet for providing insight. I’ve only been on one side of an ERP implementation (in a finance role). They provided some tips from an ERP provider perspective that I found super valuable.

Now, onto the tips…

1) The system won’t fix the culture

All 9 of these tips are important. But if you only remember one, make it this one.

It is the culture of the business that will make a new system successful. NOT the other way around.

I have seen this fallacy so many times. And it applies to any system rollout, not just ERP systems.

If you have a business with a poor attitude to data quality and process compliance, it’s easy to blame ‘the system.’

And if it’s the system’s fault, then a new system will fix everything… right? Wrong. Very wrong.

The problem is far closer to home. If you have a low first-time match rate on purchase orders, or you don’t rotate inventory properly, you should not expect a new system to fix those problems.

A better tool might help, but only if it’s used properly. And if you aren’t using your existing systems properly, why will it be any different on a new system?

ERPs rely on a good culture of compliance with systems. Some businesses just aren’t mature enough for that. So wait until you are, before you start fiddling with systems.

2) Over-invest in master data quality

ERP systems are just a massive set of tables of data colliding with each other.

Right in the very center, sits a small number of the most vital tables: master data.

Product data. Supplier data. Customer data. Employee data. Etc.

Good master data management is tough. It cuts across a number of business functions. Bigger organizations will have dedicated master data teams, while small organizations will likely rely on the user to keep it up to date.

It’s common to see workarounds in systems and processes to fix what is a simple master data problem at the core.

Charlie Munger said: ‘If you mix turd and raisins, you’ve still got turds.’ In this case, the raisins are the system and the data is the turd.

Getting ‘squeaky clean’ master data before the ERP rollout starts will pay dividends. If you assume you can fix this problem during the roll-out itself you have no chance.

You should also think about what you will need in the near future. It’s not easy to change the master data structure once you are live. So if you want more product tagging or deeper data stored in your customer tables, now is the time to think about it.

Think of master data as the ‘project before the project.’ Give it a dedicated resource, and start early.

3) Put your best people on the project (and backfill)

A former CEO (and veteran of several ERP rollouts) once said to me: “people always underestimate how many people get sucked into an ERP rollout.”

You start with a dedicated project team. Those guys will think about nothing else for the next two years.

And before long, it’ll be the number one thing for the IT teams and accounting and finance teams. Eventually, it will feel like everyone in your business who touches a computer is working on it. Because they are.

There is a point in any ERP rollout where it really feels like it’s all anyone is working on. Who the hell is running the business while this is going on?

You need to balance engaging the business with distracting the business.

The best way to do this? Put your best people on the project team.

The best ERP rollouts I’ve seen take the top middle managers in the business out of their day jobs, backfill them, and move them onto the ERP project.

The senior FP&A manager who has lived and breathed the business for 15 years and knows how everything works. The IT business analyst who worked on the last rollout. The head of supply chain who knows how each warehouse works intimately. You probably know who those people in your business are, right off the top of your head.

ERP rollouts with teams built of people charged with spending 50% of their time on the project and 50% of their time on the day job are ALWAYS a disaster.

4) Use off-the-shelf software

Most businesses can make do with off-the-shelf ERP software, providing that:

• They select the right software

• They set it up properly and implement well

• They plug in the right apps

Everyone has a reason why their business is special or different.

99% of the time, that uniqueness is in the combination or sequencing of fairly standard processes. Just executed really well.

If you do end up having to develop something bespoke and move away from off-the-shelf products, make sure:

• It’s a last resort, having explored all alternatives

• To elevate risk management. Your project just got a whole lot riskier

• Have a plan for future-proofing it. One day the person who wrote that code just for you won’t be there to help you fix it when it needs fixing.

Earlier in my career I was working on the integration of an acquisition. The acquired business had an ERP system with some custom code built into it. Because of this custom code, we were unable to change the year-end of the business to match our own. We eventually had to outsource this problem at a cost of over $500k.

There is a time and a place for customizing ERP software, but unless you have a world-class in-house technology team on-hand, proceed with extreme caution.

5) Clarify the scope

One of the hardest bits of any ERP rollout is agreeing on what is in scope. What problems will the next system solve and what will it not?

Everyone will have their own map of what an ERP is or isn’t and what it solves. The more people involved the smaller the area of overlap. You must transform that into a common understanding.

Everyone must be clear on what is in the project and what is out of the project. Both inside your company and between the company and the implementation partner. Inevitably there will be something later that the company was expecting the implementor to do, that is not in the documented scope of work.

Invest time in that scope upfront. It will need several workshops to force clarity amongst the business and with its partners. Better to know you are on different pages now, than find out later.

6) Single point of ownership

The whole business must be engaged in an ERP rollout being a success. And for that to work the whole C-Suite has to be behind it. CEO, CFO, CIO, etc. Plus their teams.

But …

Only one person can be accountable.

There needs to be a single leader in the business responsible for its successful execution. A single point of ownership.

It should be the most senior person who is assigned to the project full-time. And they do need to be suitably senior. 

Last month I shared a story of an ERP disaster, where I had been assigned to write the autopsy report. One of my findings was that the project had been woefully under-resourced at a senior level. The project had been trusted with a capable middle manager.

But when things had started to go South she did not have the influence or direct access to the C-Suite needed to get it back on track. Not her fault, she’d been set up to fail.

That wasn’t good enough. It needed someone of VP level at least. In reality, no one of serious influence had spent more than a few hours per week on the project. Hence the horror story.

For an ERP rollout to succeed it needs someone very senior with a lot to lose worrying about whether it’s going to be a success or not. They need to be empowered to make all critical decisions for the project and be held accountable for them.

It’s the best way to inject a healthy level of paranoia into the project.

7) God-tier project management

Great project management is beautiful to watch in action. It’s a skill to be admired.

Great PMs can break actions, personalities, interdependencies, challenges, costs, resourcing requirements, etc. down into a clear plan for the project team and steering committee.

The Project Management Office (PMO) will be the forward momentum for a project when the going gets tough. Even if it’s only one person. Constantly identifying roadblocks, their root cause, and unblocking them.

Project management is a discipline in its own right. And not something for someone to manage off the side of their desk. Your PMO shouldn’t own any actions themselves beyond making sure everyone else is doing theirs (and reporting the results).

If you don’t have this skillset in-house you can buy it in with a contractor. 

If you don’t think you can afford a PMO for your rollout, try and work out what a bad ERP rollout will cost your business.

As a rule of thumb, if you can’t afford the PMO, you can’t afford the ERP.

8) Parallel run

There are two schools of thought on parallel running.

Some say it’s too risky to go ‘big bang’ and a parallel run with the old system and new system is the only way to manage the risk of an ERP rollout.

Others say you have to burn the boats. Hot swap the systems on a go-live date and force the business to figure out any issues in minutes, not weeks. 

I’ve never quite made my mind up on this. I can see both arguments, and it depends on the culture and the specific risk profile of the project.

If I can get it, I like to have the best of both worlds. A project plan that to the business looks like a ‘big bang’ rollout, but has an inflatable life raft if needed. An oven-ready disaster recovery plan that can be activated to continue using the old system in the event there is a critical failure upon go-live.

This can only be activated by someone senior to the project leader. Ideally the CEO, or someone who will ask suitably difficult questions about why the ‘plan b’ was needed.

9) Don’t forget the auditors

ERP implementations are just as risky for auditors as they are for companies.

There will be inevitable changes to methodologies, analysis and supporting schedules.

The last thing you want is a ‘limitation of scope’ in your audit because you have a gap in your record keeping. That would be baaaad.

So ensure that you are talking to your audit team about what they need to see, in what format, and when. Their spidey senses will be tingling from the first time they hear you mention ‘ERP rollout.’ 

They will smile and agree when you talk about what a great thing it will be for the business. Then they will immediately go back to their planning file and significant risk assessment and flag your ERP implementation as number 1 in the list.

If you have an internal audit function, I can’t think of a better way to use it than to put a full-court press on an ERP rollout. That means testing controls, cut-over readiness, and intensive balance sheet audits post-go-live.

Back to the story of the ERP rollout gone wrong. Had the internal audit team analyzed the balance sheet properly the business would have learned of the issue far sooner. And the restatement would have been mildly embarrassing internally rather than a catastrophe.

Those are the 9 tips for avoiding an ERP omni-shambles. That doesn’t mean it will go smoothly. But these tips might help you lose less sleep.

A well-implemented ERP is a selfless gift from strong leadership that could last a couple of decades. Not just for the system. But for the hard yards of process and culture change that comes before.

One day I will run a survey of readers to tell ERP war stories so we can validate whether the 70% stat is real or not…

Next week we begin a series on interpreting financial statements. Prepare to get nerdy.

Double G from Israel asked:

I'm a VP of finance in a high-tech company. A lot of the data comes from the BI system rather than the core accounting system. The CFO discourages the accounting and FP&A teams from working together. I’m curious to hear your view on this and whether it’s normal.

GG… I’m feeling uncomfortable with this.

It’s not uncommon to have different departments working from different systems. Often a product of legacy. That’s not ideal, but it’s okay if those systems are reconciled. The way I’m reading your question suggests you aren’t sure if they are.

The data in your BI system must reconcile to the ERP system… otherwise, it’s a house built on no foundation. As a VP of finance, the business (including the CFO) will assume you are guaranteeing that the information you provide is accurate and complete. I don’t see how you can do that without working with your accounting team. Especially if you are flying outside the ERP system.

That reconciliation either needs to come from you and your team or the controlling/accounting team. More likely the latter. Seriously G, this is not a gray area - it’s basic hygiene - you need to fix this. Start by speaking with your CFO.

Beyond that point, the FP&A team is both a customer of - and a partner of - the accounting function. They MUST work together. Your insights will be stronger for a better understanding of how the books are put together.

Frankly, I am surprised your CFO isn’t encouraging some level of collaboration between the two parts. I would have a chat with them to understand better why they have set it up the way they have.

If you would like to submit a question, please fill out this form.

Footnotes

• Sponsor CFO Secrets Newsletter

• Get your side hustle on. Are you a fractional CFO, or a finance professional interested in picking up part-time advisory work? We're launching a platform to help match you with SMBs looking for exceptional talent. Apply now

• Find amazing accounting talent in places like the Philippines and Latin America in partnership with OnlyExperts (20% off for CFO Secrets readers)

And Finally

Next week we’ll launch a new series on interpreting financial statements.

If you enjoyed today’s content, don’t forget to check out this week’s sponsor Rillet.

Stay crispy,

The Secret CFO

Disclaimer: I am not your accountant, investment advisor, tax advisor, lawyer, CFO, director, or friend. Well, maybe I’m your friend, but I am not any of those other things. Everything I publish represents my opinions only, not advice. And certainly is not investment advice. Running the finances for a company is serious business, and you should take the proper advice you need.