Everything You Wanted to Know About ERP* (*But Were Afraid to Ask)

Messing with your company’s nervous system is not a small thing.

Think of considerations around an ERP implementation like journalism: focus on who, what, when, where, why, and how.

And “implementation” is a catch-all word. It might be a relatively minor in-place upgrade of the same ERP system. Or it could be a full-blown move to a completely different piece of software. And there’s a whole universe in between.

Why

We all know who Simon Sinek is and we all know Start With Why.

Why are you doing this?

• For fun? (No. Just… no.)
• Because you have 20 years of accumulated technical debt - the hamsters in the data center are screaming, and your users are battling a Y2K-era interface?
• You’ve had acquisition cycles and have 20 different ERPs running?
• You’ve reached a growth point that requires a more mature system?
• Do you have new regulatory requirements that your old system may not address?
• Business partners need to actually be able to integrate with your system?

Write a project mission statement. If you can’t state in a sentence or two why you’re doing this, well then… you probably need to think more about why you’re doing this.

“We want to build a place where great people want to work — and outdated systems make that harder. A modern ERP lets our teams spend less time firefighting and more time focusing on things that really matter.”

Write a project mission statement. If you can’t state in a sentence or two why you’re doing this, well then… you probably need to think more about why you’re doing this.

What

After you’ve got your why, move on to what.

What are you doing? Define your scope.

Is it a minor upgrade that is mostly technical lift with little or no process change?

Is it a 100-site consolidation with 23 different ERP systems, a culture change to “get everyone on the same page”, reengineering of processes to adopt universal best practices… and a partridge in a pear tree?

If you’re doing that second one, that’s pretty ambitious - you may want to get better wings, Icarus.

What is your goal, in measurable terms?

• Automation of core processes?
• Increased data discipline?
• Maturity of analytics or AI readiness?

What are your success criteria and metrics?

• Reduced production time?
• Minimizing inventory errors?
• “Month end close within 3 business days”?

Beyond that, “what” includes what system was selected, the scope of what’s being implemented (modules, geographies, peripheral systems), and boundaries of scope.

When

Anyone giving you an exact number before they understand your company is selling you something – and it’s a different acronym than ERP.

What is your timeline? How does all of that “what” fit into when you can feasibly do this in your business? Are you phasing this across different sites or going big bang? What is a realistic timeline? 12 months? 24 months?

So how long does it really take?

12 parsecs (if you know, you know).

Like everything else, it depends.

Factors that affect this:

• Company size and complexity
  • Number of physical locations
  • Number of employees
• Number of products made/sold/inventoried
• Overall use of the system (just sales, purchasing, and finance; full product design, engineering integration, sell/buy/build, quality, aftermarket service, transportation, finance, integrations with best-of-breed systems)
• Available people (internal and consulting)
• Level of process reengineering
• Customizations and integrations

I’ve seen projects take 3-4 months for smaller companies. I’ve seen projects in a multibillion/multinational still going on 15 years later as more of a continuous rollout, including acquisitions.

My dart throw estimate – 14.6 months.

Please don’t use that number. Anyone giving you an exact number before they understand your company is selling you something – and it’s a different acronym than ERP.

For real, most companies I’ve seen are in the 12-24 month range for a small-to-midsize manufacturing company.

Also – trying to shortcut the process does not turn out well. I’ve been involved in plenty of “pick up the pieces after the fact” projects that went live because they had a deadline to meet. Then, after go-live, they had to actually implement a working system.

In my experience, this typically costs significantly more than just doing the real work upfront. Measure twice, cut once is an adage for a reason.

Who

Putting bodies on a project because they’re available is not a good strategy.

A very important factor is who is doing this. That isn’t just your implementation partner (although that is critical, and we’ll talk more later) – but who drives and participates in this project from your business?

Who is your core team and who are your superusers? We talked about that some already in early articles - but what’s the balance between who can strategically and tactically best support the project and who needs to make sure your business still operates day to day?

One… choice… I’ve seen companies make is to put whoever is available on the ERP project. Please don’t do this, unless that person is also the best person to shape how the new system should work. Putting bodies on a project because they’re available is not a good strategy.

What is the steering committee structure? Do you have strong executive sponsorship (which, if you don’t, maybe don’t do this)?

A strong steering committee and executive sponsor are crucial in my experience. These aren’t just “OK, budget overage approved” roles. You need people who are willing to make tough calls, break deadlocks, and who believe in the mission.

You need people who are willing to make tough calls, break deadlocks, and who believe in the mission.

Where

OK, I may be pushing the analogy a bit far with “where” – but not much.

• Where are the facilities involved?
• Where does the project execute from – and does that rotate depending on phases?
• Is travel required?
• How does all of that fit into funding and budget?
• Do different geographies come with different compliance requirements?

How

Finally, let’s bring it all together – how does this actually happen?

• What’s your overall plan?
• How is the project organized and what kind of governance structures?
• What are the technical pieces and how do they get executed?
• How do you maintain enthusiasm and gain user participation and adoption (and, again, balanced with making sure your business is running well during all of this)?
• What is your training and testing strategy? I’ve historically used a “3 system integration tests (SIT) and 1 user acceptance test (UAT)” approach to testing. Is that what’s going to work for you, or do you integrate an Agile framework into your testing?
• How is risk managed?