Supply Chain Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the "replace everything" scope failure happen so often?

The pain that starts these projects is almost never the ERP itself. It is the reconciliation layer: a planner exporting inventory on Tuesday, pasting it into a forecast sheet, cross checking open purchase orders from a supplier email thread, and being wrong by Thursday. But the proposal that comes back describes a platform that also handles receiving, costing, purchase order approval and financial posting, because once you list everything the spreadsheet touches, it touches everything.

That expansion is what turns an orchestration layer into a suite rebuild with a parallel running period nobody budgeted, and it creates two systems that both claim to own on hand inventory.

The fix is a one page document written before the first sprint naming the single system of record for each entity. Items, costs and the general ledger stay in the ERP. On hand, receipts and cycle counts stay in the WMS. Loads and proofs of delivery stay in the TMS. Forecast, safety stock, allocation and the exception queue live in the new platform, because no packaged product holds your version of them. Everything else is read only until someone makes an explicit case to change it. A vendor who cannot produce that document in week one is scoping a replacement, not a layer.

What goes wrong with item master and inventory data migration?

Every build in this category hits the same wall around week three: the same physical product carries three identifiers. The ERP calls it a material number, the WMS calls it a location suffixed code, and the supplier's advance ship notice uses their own part number. Units of measure disagree too, because purchasing buys in cases, the warehouse picks in eaches, and forecasts are built in pallets, with a conversion factor entered once and never audited.

Teams underestimate this because migration sounds like a data task and is actually a decision task. Somebody has to decide which of two conflicting on hand quantities is true, whether a lot code present in the WMS but absent from the ERP gets created or written off, and what happens to the items that have not moved in two years and still carry value. Those are operational calls that need your inventory controller, not your developer.

What works: before any feature is built, stand up a read only mirror that pulls from both systems and publishes a daily reconciliation report listing every item where the numbers disagree and by how much. Run it for three or four weeks. It is cheap, it is useful on its own, and it tells you whether the data is ready. If that list is still hundreds of lines long after a month, that is your project.

Why do the ERP, WMS and EDI integrations break after launch?

Integrations rarely fail at go live, because everyone is watching. They fail in month four, quietly. A supplier changes their advance ship notice layout. The ERP takes a service pack and an endpoint starts returning a different date format. A nightly job fails at 2am, nobody is subscribed to the alert, and the planning screen shows Tuesday's inventory on Thursday without saying so.

The specific hazards are worth naming. Legacy ERP connections often run through IDoc or BAPI style interfaces rather than clean REST, which means batch semantics and no natural retry. Electronic data interchange traffic across 850, 856, 810, 204 and 214 documents moves through a value added network with its own acknowledgement rules, and a rejected functional acknowledgement nobody reads looks exactly like silence. Two way syncs create duplicates the first time a message is delivered twice.

Three decisions prevent most of it. Make every inbound message idempotent so replay is safe, and store the raw payload so you can replay it. Alert on absence rather than only on error, because the expensive failure is a feed that stopped, not one that threw. And put a staleness indicator on every screen showing the age of the data displayed, so a planner sees that the WMS feed last ran eleven hours ago instead of trusting the number in front of them.

What happens when exception handling and allocation rules are not covered?

A platform that shows correct numbers without telling anyone what to do gets used for about a month. The planner keeps the spreadsheet, because the spreadsheet is where their judgement lives: who gets short shipped, which purchase order gets expedited, which forecast override survives.

Allocation is the sharpest version. When you are short, someone decides who waits, and that decision involves contract commitments, channel priority, margin and the customer whose buyer will escalate. Packaged suites give you a priority field. If your build also gives you a priority field, the decision goes back into a meeting and the software merely records it.

Two things belong in scope from the start. An exception queue with a named owner and a clock on each item, so the dozen things that need action today have accountability and an audit trail. And allocation and reorder logic expressed as rules your planning lead can read and edit, with a dry run mode that shows what would change before anything changes. Lot and serial traceability belongs here too if you handle food, pharmaceutical or otherwise regulated goods, because a recall query that takes two days of spreadsheet work is the gap you discover on the worst possible day, and retrofitting traceability into a data model that never carried it is close to a rebuild.

Should you build custom or configure what you already own?

Configure, and spend the money elsewhere, if your process is genuinely standard. NetSuite, SAP and Microsoft Dynamics all ship demand planning and replenishment modules that many companies have never properly switched on, and a competent functional consultant configuring what you already licensed will beat a custom build on both cost and time to value. The same logic applies to visibility. If the real problem is that nobody knows where the containers are, buy that data rather than building scrapers, because carrier and terminal integrations break constantly and owning them buys you nothing.

Build when the logic is yours: unusual echelon structures, contract manufacturers with their own formats, allocation rules no product models, or a service level you compete on. The strongest version of custom here is not a suite. It is a thin orchestration and intelligence layer that keeps accounting in the ERP and picking in the WMS and holds only what nobody sells you.

A practical test before committing. Ask your ERP partner for a written statement of what their planning module can and cannot do for your three hardest cases. If they cover two of the three, configure. If they cover none, you have your answer and a much narrower build, because you now know exactly which gap you are filling.

How do hidden costs get into the quote?

The line that hides the most money is "ERP integration", singular. That phrase can mean a nightly item export or a two way real time sync of items, purchase orders, receipts, costs and ledger postings, and the distance between them is roughly a factor of ten. Ask for integrations priced per object and per direction and the estimates become comparable across vendors.

The others, in rough order of how late they surface. Data cleanup, presented as your responsibility and then quietly billable when nobody internally has the hours. Non production environments, since ERP sandboxes sometimes carry their own licence cost and refresh schedule. Value added network fees and trading partner onboarding for electronic data interchange, which is per partner and slow. User acceptance testing, because your planners have day jobs and the hours they spend testing are real cost even when nobody invoices them. Training for a tool that replaces a decade of habit.

Then the permanent line. Budget roughly 15 to 20 percent of build cost per year for hosting, monitoring, integration upkeep as connected systems change, and model tuning, since forecast and safety stock logic needs adjusting against real outcomes after go live. A quote without that number is not cheaper, it is incomplete.

What separates a build that works from one that fails here?

The builds that work put trustworthy data live before they put features live. Getting one unified, reconciled inventory picture into production in month three delivers value on its own, and it forces the data problems into the open while budget still exists to fix them. The builds that fail spend those months on screens, then discover during user acceptance testing that the numbers behind the screens are not defensible.

The other reliable markers are unglamorous. A phased plan where each phase ends with something your team uses daily rather than one launch date nine months out. A named senior engineer who stays on the project rather than a sales lead who disappears after signature. Questions in the first call about which ERP, which WMS and how allocation actually works, because a quote produced without those answers is a guess. Ownership of the repository, the cloud accounts and the data from the first commit, in writing, before kickoff.

One internal marker matters more than any vendor one: a named owner on your side who can decide about data. Not a steering committee. Someone who can say this on hand number is the true one and this obsolete item gets written off, this week, without escalating. Projects in this category stall on decisions far more often than they stall on code.