The Real Go-Live of ERP Happens About Three Months In

A few months after go-live of an enterprise resource planning application, something predictable happens inside most manufacturing operations: The spreadsheets come back.

Inventory stops matching what the system says. Planning starts padding buffers because nobody fully trusts the numbers anymore. Production is expediting jobs again. Buyers are keeping notes on the side. Supervisors are skipping transactions because they’re trying to keep the floor moving. And leadership watches all of it and starts wondering if the implementation failed.

The pattern repeats inside plants ranging from $50 million to multi-billion-dollar operations — different ERP platforms, different leadership teams, same story. And most of the time, the software isn’t the problem.

When the Shortages Hit

I encountered the rare exception to that rule while working at the world’s largest portable spa manufacturer, when we migrated from one mid-market ERP to a tier-one platform. About three months after go-live, parts started drying up. A flood of shortages was hitting all at once.

The floor went into full scramble mode. Buyers were padding quantities on top of whatever material requirements planning was suggesting. Expediting became the default. Everyone was running harder just to keep production from falling apart, and nobody could explain why a system we’d just implemented was making things worse instead of better.

Upon running scenarios in the test database, and methodically eliminating variables, I discovered the problem. When a purchase order was partially received, the system was silently discounting the remaining open balance as a source of supply. Planning couldn’t explain why the numbers kept drifting. It took months of elimination before I could prove it was the software and not us. The vendor eventually patched the code. That’s the only time in my career the software was actually the culprit.

The Problem Isn’t the System

Most of the time, what looks like an ERP problem is a people problem. They gravitate back to what worked for them. It doesn’t matter how good the system is, or how clean the data is. If they weren’t part of the decision, they’ll find a way around it.

It’s human nature to say, “I love change, except when it happens to me.” And if you ignore that tendency, your implementation is already in trouble before anyone flips the switch.

It’s crucial to pull in everyone who will actually touch the system — floor supervisors, buyers, planners, receiving clerks — before anything is decided. You want their input, their frustrations, and their workarounds. Even when the decision is already made, you need to make sure they had a voice in how you got there.

That changes everything. People embrace change when they feel like they were part of it. The system can be configured perfectly and the data spotless, but if the user didn’t have a seat at the table, they’ll be back on their spreadsheet within 90 days.

What the Floor Already Knows

When things are going sideways after implementation, the first thing to do is walk the floor. You need to know what the operators are actually experiencing. Are they using workarounds? If so, why? The answer to that question tells you almost everything you need to know.

Leadership usually thinks the problem is the implementation, and you can understand why. The most recent change gets the blame. But nine times out of 10, you’ll find that the business didn’t properly address its processes up front. The system went live on top of broken or undocumented workflows, and nobody caught it in time.

There’s a constant pressure to go live against current processes: Get it up and running, and sort it out later. If the company didn’t have proper controls in place going in, that’s technically on the company — but in the end, the software gets the blame.

That’s why you need to go straight to the operators. They have the answers. They know exactly where the system doesn’t match reality, and they’ve already built the workaround to prove it.

A Different Kind of Help

Before calling in a team with a methodology deck and go-live timeline, it's important to consider one thing: The answer is usually already in the building. It’s in the workarounds the operators built because the process wasn’t right from the start. It’s in the transactions getting skipped because nobody asked the floor what they actually needed. It’s in the spreadsheets that came back three months after go-live because the system never had a chance.

What actually moves the needle isn’t better software or faster implementation. It’s someone who has stood where the operators are standing — who came up through the floor, understands why people reject change that gets handed to them, and works on behalf of the business rather than a methodology.

That perspective is rarer than it should be, but it’s the one worth looking for.

Lee Stout is the founder of Staudt Solutions.