Two Customers, Same Bolt: A Mid-Market Manufacturer’s ERP Misconfiguration Story

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

Customer A calls the spare parts division and orders a bolt. It’s a specific bolt that fits a piece of equipment they bought from this company a few years back. The company takes the order which kicks off a full end-to-end workflow. Engineering review, procurement, receiving, shipping, and invoicing. Every step required, every transaction logged.

Two days later, Customer B calls. They need the same bolt. It’s the same part number, from the same supplier. No problem, right? Nope!

The system treats Customer B’s order as brand new, like Customer A’s order never existed. It kicks off a second full workflow from scratch. Procurement orders another bolt from the same supplier. Customer B waits for it to ship in.

Both customers wait an extra cycle they did not need to wait. The team running the spare parts business built an entire layer of spreadsheets to track what the system was not configured to see. Procurement and finance are fighting to get visibility into demand patterns, and inventory accuracy is a guessing game at best.

This is a real story from a mid-market manufacturer I worked with. They were wondering if they needed a new ERP. They did not. The ERP was doing exactly what it was configured to do. The configuration was wrong for the business model the division was actually running.

That is the story I want to tell, because it is one of the most common ERP misconfiguration manufacturing stories I see in mid-market, and almost nobody is writing about it from the inside.

The Setup

The parent company was an upper-mid-market custom manufacturer. Engineer-to-order. They designed and built complex pieces of equipment for industrial customers, one project at a time, with a long sales cycle and a deep configuration process for each unit. Their ERP had been implemented years earlier and was tuned to support exactly that kind of business. Project-based work. Custom item masters. Bespoke routings. Every transaction was its own thing.

That worked for the original business. Then they grew through expansion and acquisition.

One of the divisions they brought into the parent company had a different operating model. They were a spare parts and service operation supporting the equipment the parent company sold. End users needed parts when their machines went down. They needed inventory on the shelf or close to it. The business unit needed visibility into demand patterns across hundreds of customers ordering similar parts repeatedly. They needed a supply chain mindset, not a project mindset.

The parent rolled the spare parts division onto the same ERP platform. The implementation team did what implementation teams almost always do. They took the existing configuration, the one that had been working for the project-based parent, and applied it to the new division. Same item master logic. Same business rules. Same end-to-end workflow per transaction.

On the surface, both businesses were “custom manufacturers.” Underneath, they had completely different operational requirements. The configuration had been built around the wrong one.

What the Mismatch Looked Like

The bolt example is the cleanest illustration, but the pattern showed up across the division.

Every order, regardless of part type, kicked off the full project-style workflow. The system had no concept of inventory consolidation across orders, because the parent business never needed it. It had no concept of demand visibility across customers buying the same part, because every order in the parent business was unique by definition. It had no native way to handle reorder points or stocking levels for high-velocity items.

The team did what teams always do when the system does not fit. They built workarounds.

Order entry kept its own spreadsheet to track which customers had recently ordered which parts. Procurement ran a parallel ledger of what was on order from suppliers, because the system’s view was tied to specific customer orders rather than aggregated demand. Inventory ran cycle counts that the system could not properly reconcile against. Finance fought to get clean reporting because revenue and cost flows were running through transaction structures designed for one-off project work, not high-volume parts.

Every workaround took time. Every workaround introduced its own errors. Every workaround had to be maintained by someone who knew how the spreadsheet related to the system. Over the years, the workaround layer became part of how the division operated. New hires spent weeks learning the system’s quirks instead of the actual parts business.

By the time leadership started thinking seriously about replacement, the team had a long list of complaints about the ERP and very few people internally who could clearly articulate which complaints were ERP problems and which were configuration problems.

The Audit Conversation

When I came in, the question on the table was already framed as “do we need a new ERP.” I get that question a lot. It is almost always the wrong question to start with, because the answer depends entirely on whether you have actually understood what is broken.

The first move was to talk to individual contributors, not just leadership. I wanted to understand where the workarounds were and why. What was the team doing manually that the system should have been handling? What were the spreadsheets actually tracking? Where was data flowing in and out of the system in ways that introduced errors or delays?

That conversation surfaced the structural mismatch within the first couple of hours. The team did not say “the system was configured for the wrong business model.” They could not, because they had not been given that frame to think with. What they said was things like “we have to manually figure out which orders are for the same part,” and “we are constantly reordering things that we just ordered for somebody else,” and “we cannot see what we have on order until the customer order is already in the system.”

Each of those is a symptom. The diagnosis is one level up. The system was treating every order as a unique custom-engineered transaction because that is what the configuration told it to do, and the actual business needed it to recognize that many orders were for the same items and should be handled with inventory and supply chain logic instead.

Once the team had that frame, they could start telling me where else the same mismatch was showing up. The audit moved fast after that.

The Fix

The fix was not glamorous. There was no new software. No vendor pitch. No six-figure invoice for an implementation partner. The work was the work.

We reconfigured the item branch master to support inventory-managed parts as a distinct item type, separate from the project-based custom items the parent business needed. That alone unlocked a different set of business rules and routings.

We redefined the process flows for the spare parts division from end to end. Quote to cash, but adapted to a parts-and-service motion rather than a project motion. The high-volume order path got streamlined. The exception path for genuinely custom requests got separated out so it did not contaminate the standard flow.

We had to retrain the team on the new processes, which meant documenting them properly for the first time and walking through the change with the people who actually run the day-to-day work. The change management was as important as the configuration changes. Without it, the team would have kept their workarounds out of habit.

We also had to maintain visibility for finance and the broader corporate functions, because the spare parts division had to keep reporting up to the parent company in ways that fit the existing financial structure. That meant carefully threading the new configuration into the existing chart of accounts, transaction types, and reporting flows. It was not a clean greenfield rebuild. It was a reconfiguration that had to keep playing nicely with everything else the parent ran.

When the work was done, the same ERP that had been “broken” was suddenly working. Order fulfillment got faster. Customers stopped waiting for procurement loops that did not need to happen. Inventory accuracy improved because the system finally had the right structure to track it against. The team’s workarounds started disappearing, not because anyone forced the change but because the system stopped requiring them.

Why This Pattern Repeats in Mid-Market Manufacturing

What happened to this division is one of the most common patterns I see in mid-market manufacturing, and the reason is structural.

Most mid-market manufacturers grow through some combination of acquisition, product line expansion, and customer-base evolution. Each of those changes the operating model in subtle or not-so-subtle ways. The ERP that was configured five or ten years ago was tuned to whatever the business looked like then. As the business changed, the configuration generally did not. Nobody owns the job of going back to the configuration and asking whether it still matches.

The pattern shows up in three flavors:

The business you used to be. The configuration was right when it was set up, and the business has drifted away from it over time. Customers, mix, model, all evolved while the system stayed put.

The business you thought you would become. Somebody made assumptions about growth or new product lines or acquisitions during implementation, and the configuration was built to those plans. The plans changed. The configuration did not.

The business you never were. The implementation partner came in with a template, applied it across all divisions or business units, and never refined it for the specific operating model of each. The bolt story above is this version. The parent’s project-based template got applied to the parts division because it was easier than configuring properly.

Any of those three can produce the same downstream symptoms. Workarounds. Shadow spreadsheets. Frustration. Replacement conversations.

For the Broader Principle

This article is the deep manufacturing version of a more general principle. The same pattern shows up in CRMs configured for an outdated sales motion, WMS systems configured for a picking pattern that does not match how the floor actually picks, accounting platforms configured before a new revenue model came online. The story changes by tool category. The structural problem is the same.

If you are reading this and thinking “we have a similar misalignment with our CRM or our WMS,” the broader principle is the same audit move. I wrote about it from the tool-agnostic angle in [You Don’t Need New Software. You Need to Use What You Already Have.](#cross-link-c000632). Different surface, same diagnostic.

What This Means If You’re Reading Yourself in This Story

If your spare parts division, your aftermarket service business, your acquired subsidiary, or any unit of your business is running on the parent company’s ERP and you are seeing the workaround layer build up, the question to ask is not “do we need a new ERP.” The question is “is the configuration matching what this part of the business actually does.”

Pick one frustrated process flow this week. Walk it from end to end with the team that runs it. At every step where they are working around the system, ask why. When you get to “because that is how it was set up,” ask whether anyone has ever challenged that answer. Then look at the operating model for that part of the business and ask whether the configuration is actually supporting it or fighting it.

If the configuration was built for a different business than the one you are running today, you have found the start of the audit. The system is doing what it was told. What it was told no longer matches what the business is.

The fix is not always small. The bolt story took real work to unwind. Item master changes, process redesign, retraining, careful financial threading. But it cost a fraction of what replacing the ERP would have cost, and it kept the team’s institutional knowledge intact. The system the team had been complaining about for years became the system that quietly enabled the next phase of the division’s growth.

Final Thoughts

The instinct to replace your ERP is rooted in something real. The frustration is real. The workarounds are real. The cost of leaving this alone is real, and it compounds the longer you wait.

But the source of the problem is rarely where the conversation tries to send you. It is not the tool. It is the configuration relative to the business model you are actually running. And the work of fixing that is not glamorous. It is not a vendor pitch. It is sitting with the team that does the work, walking the flows, and being honest about which parts of the system were built around the wrong assumptions.

The companies that benefit most from this conversation are not the ones who replace the ERP. They are the ones who go back to the configuration with fresh eyes and find out the system was capable all along.

That’s it for today.

See you on the next episode.

Dave