A 150-employee service center spent $800,000 on an ERP implementation. Eighteen months later, half the company was still using spreadsheets alongside the new system. The warehouse team had reverted to paper pick tickets. The sales reps entered orders in the ERP but kept their own Excel price sheets because they did not trust the system pricing. The company had spent $800,000 to add a third system to the two they were already using.
This is not unusual. Industry surveys put ERP implementation failure rates between 50% and 75%, depending on how you define failure. In steel distribution specifically, the failure rate may be higher because the industry has requirements that generic ERPs handle poorly.
Reason 1: The Software Does Not Understand Steel
General-purpose ERPs were built for discrete manufacturing or retail distribution. They think in SKUs, each counts, and standard costs. Steel distribution thinks in coils, pounds, linear feet, and market-based pricing that changes weekly. When your ERP cannot handle a coil that has a theoretical weight, an actual weight, and a shipped weight that are all different numbers, every transaction creates a reconciliation problem.
Heat number tracking, MTR management, gauge-based pricing, remnant handling, multi-unit-of-measure inventory (the same item priced per pound, sold per piece, and inventoried per bundle) are all requirements that generic ERPs bolt on as customizations. Those customizations create complexity that makes upgrades difficult and support expensive.
Reason 2: Inadequate Data Migration
The old system has 15 years of customer history, pricing agreements, inventory data, and vendor records. Moving that data to the new system is not a technical problem. It is a data quality problem. The old system is full of duplicate customer records, obsolete inventory items, pricing that nobody remembers setting, and contact information that has not been updated since 2018.
Most failed implementations skipped the data cleaning step. They migrated everything, garbage included, and then spent the first year in the new system dealing with bad data that made users distrust every report and every inventory count. Clean your data before migration. Delete inactive customers. Reconcile inventory. Validate pricing. This step takes months and it is the most important work in the entire project.
Reason 3: Insufficient Training
Two days of classroom training does not prepare a warehouse worker or sales rep to use a new system under real-world pressure. When the system goes live and a customer is on the phone wanting a quote, the user does not remember the seven steps they learned in training three weeks ago. They revert to what they know: the spreadsheet, the notebook, the old system.
Effective training requires role-specific instruction (warehouse users do not need to learn accounting functions), hands-on practice with realistic scenarios (not canned demo data), go-live support with trainers on the floor for the first two weeks, and refresher training at 30 and 90 days after go-live.
Reason 4: No Executive Champion
ERP implementations face resistance. People do not like changing how they work. When a senior sales rep with 20 years of experience says "I am not using that system, my spreadsheet works fine," someone with authority needs to say "yes, you are, and here is why." That someone cannot be the IT manager or the project consultant. It has to be the owner, the GM, or the VP of Sales.
Without executive sponsorship, the loudest resistors win and adoption stalls. The most successful ERP implementations we have seen had an owner or GM who used the system personally, asked questions that required data from the system (not from a spreadsheet), and made it clear that the new system was not optional.
If You Are Stuck Mid-Implementation
If your ERP is partially implemented and partially ignored, you have two options. Recommit: assign an internal champion, retrain the team on the specific workflows that are not being followed, clean up the data that has degraded since go-live, and set a hard deadline for retiring the workarounds. Or cut your losses: acknowledge that the system is not right for your business, document what you learned, and start evaluating alternatives with a much clearer understanding of your actual requirements. The worst choice is doing nothing, running two systems indefinitely, paying for both, and getting the benefits of neither.