A candy company could not ship its own product for Halloween. Hershey had gone live with a new integrated system right as orders poured in, and the order-fulfillment breakdown that followed cut quarterly sales by more than 12%. The software worked. The cutover did not.
That story is the whole guide in one sentence. Supply chain ERP programs fail on master data, on cutover, and on the handshakes to warehouses, carriers, and trading partners that nobody counted.
And here is what makes this go-live different from a finance or an HR one. When it breaks, you cannot ship. The revenue hit lands the same week, in full view of customers. Gartner still expects more than 70% of ERP initiatives to fall short of their goals by 2027. In a supply chain, that shortfall gets counted in missed shipments, not missed features. So this guide walks the stack module by module: what to get right, where it quietly breaks, and one concrete Oracle, SAP, or Workday detail per module. The cautionary tales are public. The field notes are mine, anonymized.
A supply chain go-live is a physical event, not just a software cutover. You often stop receiving and shipping, count inventory, and restart operations. Own the operational decisions, govern the master data, and treat the cutover and the first shipments as the real go-live.
1. What is really on the line
The history is a warning label. Nike lost more than $100 million in sales and watched its stock fall roughly 20% after a demand-planning system misfired. Lidl walked away from a 500 million euro program after 3 years. Revlon told the SEC an ERP go-live left it unable to fulfill about $64 million of shipments and produced a material weakness in its financial controls. None of those were really software failures.
And the ground keeps shifting under you. McKinsey found that supply chain shocks lasting a month or more now hit the average company every 3.7 years. Over a decade, disruptions cost close to 45% of a single year's profits, and one severe 100-day shock can wipe out 30 to 50% of a year's earnings. The system you put in has to help you run through that, not become one more thing that breaks.
Put the operations and planning leaders on the steering committee with named accountability from week one. The team that runs the warehouses and plants has to own the go-live plan, not review it.
The count you were given is not the real count. On one program, discovery listed 50 integrations. The real number was closer to 90 once we mapped every handshake to suppliers, carriers, 3PLs, and downstream systems. The plan was built on the wrong number from day one.
2. Pick the deployment shape, and respect the physical risk
A big-bang flips everything on one date: faster, cheaper, no fallback. A phased approach goes site by site, which contains the blast radius but means running two worlds in parallel for longer. For supply chain, the deciding factors are how many plants and DCs you run, how much you can afford to stop shipping, and how complex your trading-partner network is.
Nike is the instructive recovery. After its planning failure, it rolled SAP out by geography on successive quiet weekends, Canada first as a small slice, then the rest, and reported no disruption from the staged rollouts.
Sequence waves by network complexity, and take one genuinely hard site early so the expensive lessons are cheap to reuse. Do not let the program run so long it never lands. Every extra year on a large program adds about 15% to the overrun.
3. Master data is the foundation, and the usual cause of failure
Item, supplier, and BOM data feed planning, inventory, and orders. Bad master data does not fail loudly on day one. It quietly misroutes product and miscalculates replenishment at scale.
The definitive cautionary tale is Target Canada. An internal review found an astounding number of errors in the item data: dimensions entered in inches instead of centimeters or in the wrong order, wrong currency, missing tariff codes. Product would not fit the shipping containers or the shelves. The result was the paradox that defined the failure, full warehouses and empty shelves, because the replenishment logic was executing on corrupt data. Target lost billions and exited the country.
Stand up a data-governance body before configuration starts, with named owners for the item and supplier master. No item goes live until it passes the enrichment and approval workflow.
The dirt is worse than discovery admits. On a recent program, 10% of the active records were duplicates or carried data that contradicted the physical reality. That surfaced in profiling, not in the demo. Clean at the source before the first load, and keep cleaning through every cycle.
4. Ten modules, and almost every one ends at a seam
Each module has a handful of decisions that decide whether it works. Almost every one ends at a seam: order to warehouse, warehouse to carrier, or a feed to an outside trading partner. Here is the map. The detail follows.
Item and Product Master
The single definition of everything you buy, make, move, and sell. Get the organization and master-child hierarchy, item classification, units of measure and conversions, and the governance workflow right. Watch for loading legacy items with no de-dup, and confusing an item organization (no stock) with an inventory organization (holds stock). Oracle auto-assigns master-level items to child organizations under a master org; SAP drives field selection from the material type. A buy-in-cases, stock-in-eaches mismatch is a classic unit-of-measure failure.
Procurement and Sourcing
Requisition to PO to receipt to pay, plus sourcing and contracts. Get catalog coverage, approval routing that matches your delegation of authority, and the link from negotiated price to the PO right. Watch for thin catalogs that drive maverick spend, and punchout integrations that slip because each is a supplier-by-supplier build. Oracle uses content zones with punchout loaded via CIF or cXML; SAP carries source-of-supply in the info record, source list, and outline agreements.
Supplier Management
The supplier lifecycle: onboarding, qualification, risk, performance, and the portal. Get the relationship gate before a supplier can receive spend, the qualification design and re-qualification cadence, and the risk and diversity tagging right. Watch for qualify-once-and-forget, and duplicate records that fracture spend analytics. Oracle gates suppliers as prospective versus spend-authorized; SAP models the supplier as a Business Partner.
Inventory Management
What stock exists, where it sits, what it is worth, and how it moves. Get the storage structure, receipt routing, the valuation and costing method, lot and serial control, and the counting policy right. Watch for the wrong valuation method for the material class, and over-broad serialization that slows the floor. Oracle separates storage from receiving subinventories with Standard, Direct, or Inspection routing; SAP posts every movement with a movement type and values stock by price control.
Order Management
Capture the order, price it, promise it, and orchestrate fulfillment. Get the availability and promising rules, the pricing engine, the orchestration flow, and back-to-back and drop-ship setup right. Watch for treating available-to-promise as a switch instead of a policy, which makes every promise date optimistic. Oracle runs Global Order Promising; SAP uses Advanced Available-to-Promise with a Release for Delivery step for constrained stock.
Warehouse Management
The physical work inside the four walls: receive, put away, pick, pack, ship. Get the wave and task design, putaway and slotting, cycle counting, the RF flows, and the staging-to-ship-confirm handshake right. Watch for wave rules that create too much travel, and slotting copied from a template instead of built from real velocity. Oracle releases work as a pick wave; SAP EWM groups deliveries into waves and warehouse tasks. Design the RF flows around how pickers actually walk the floor, or adoption dies.
Transportation Management
Turn shipments into the cheapest compliant transportation plan, then execute and settle. Get the network and lanes, rate master data, carrier-selection logic, and freight settlement right. Watch for dirty rate data that makes optimization confidently wrong, and a settlement loop that never closes, so savings leak back at the invoice. Oracle Transportation Management plans shipments and rates carriers; SAP TM builds freight units into orders and selects the lowest-cost carrier per lane.
Manufacturing and Production
Turn a demand signal into a released work order, tell the floor what to build, and record consumption back to inventory and cost. Get BOM and routing accuracy, the discrete versus process decision, the material-consumption method, and the supply orchestration flow right. Watch for garbage BOM data, which produces confident wrong plans and costs, and over-backflushing, which makes the floor clean and the inventory records fiction. Oracle combines BOM and routing into a Work Definition; SAP keeps them separate and converges them in the production order.
Demand and Supply Planning
Produce the forecast, turn it into a feasible plan, and run the S&OP cadence that commits one number. Get clean demand history and hierarchies, the S&OP roles and cadence before the tool, the supply constraints, and the single source of the number right. Watch for buying a planning tool to compensate for dirty ERP data, and implementing the tool while skipping the decision cadence. Oracle Demand Management and Supply Planning cover this natively; SAP IBP and best-of-breed options like Kinaxis and o9 add scenario speed at the cost of an integration layer.
Cost Management
Value inventory and work-in-process, apply the costing method, capture landed cost, and hand accounting to the general ledger. Get the costing method per book, the standard cost and rollup, landed cost as a real workflow, and the subledger-to-GL reconciliation right. Watch for stale standards that turn every transaction into a variance, and landed cost expensed instead of capitalized, which understates inventory value. Oracle layers cost organization, cost book, and valuation structure; in SAP the Material Ledger is mandatory in S/4HANA even with actual costing off.
Insist the implementer configure each module to your policies, not the demo defaults. Your valuation methods, matching tolerances, and promising rules are where the value and the risk live.
No owner, so the loads kept failing. On one program, item and supplier loads kept failing during conversion. The software was fine. No single person owned the validation rules across the modules, so every team assumed another had it. We named one owner, put a date on each item, and the failures stopped. The fix cost nothing.
5. Convert the data, then count the warehouse
Supply chain conversion is harder than finance conversion. You reconcile to physical inventory, not just a trial balance. On-hand has to tie out by unit and by dollar, at every location. Load in dependency order: item master, BOMs and routings, supplier and customer data, then open POs, open sales orders, on-hand by location and lot and serial, and in-transit.
Reconcile with rigor. On-hand has to match the physical count by record, by unit quantity, and by financial value, per location. Run several mock conversions, and treat the cutover physical count as the bridge between the converted balance and live operations.
Set a numeric conversion gate: named owners per data domain, on-hand reconciled to the unit and the dollar, and a maximum exception count before go-live is approved. Make it a go or no-go criterion, not a status color.
6. You usually cannot ship during the cutover, so the freeze is the plan
The cutover is the riskiest part of a supply chain program, because you usually cannot ship during it. Most cutovers enforce a blackout. Receiving and shipping stop or are tightly controlled, open work is cleared, final data loads, the physical count validates it, and controlled execution resumes. Communicate the window to customers and suppliers early, because it directly threatens order fill and revenue.
Rehearse the cutover at least twice, once early for sequencing and once late for real timing. Before the production load runs, hold a real gate: confirm the count is done, the loads run clean, and configuration is loaded, then decide go or no-go. Then expect a ramp. History shows revenue can take a hit for months after an enterprise go-live, so plan the ramp-down and ramp-up of order volume rather than assuming full speed on day one.
Make "the physical count reconciles and the loads run clean" the gate for go-live, and staff a command center with named owners for inventory, warehouse, transportation, and the trading-partner interfaces.
7. The integration footprint is bigger than the story
A supply chain core never stands alone. It talks to WMS, TMS, MES, e-commerce, tax, banks, and every supplier, carrier, and 3PL by EDI. Three seams cause more slippage than any single module: order to warehouse, warehouse to transportation, and EDI to the outside world. The standard transactions ride these seams: the 850 purchase order, 856 advance ship notice, 940 and 945 to a 3PL, and the 204, 214, and 210 to carriers. Map every one to a system owner and a partner, and test with real partner data, not stubs.
The number that surprises leaders is the lead time. A simple EDI partner runs about 10 to 14 days to first live transaction. With ERP integration in the loop, it stretches to roughly 60 to 90 days per partner. Multiply that by your high-volume partners and the trading-partner enablement, not the ERP config, becomes the path to go-live.
50 on paper, 90 in reality. Discovery listed 50 integrations. The real number was closer to 90 once we mapped every handshake. Rate each one by criticality and cutover timing, and treat the close-critical ones as their own mini projects with owners on both sides.
8. What AI actually does in supply chain today
AI in supply chain is real for forecasting, exception triage, and optimization. Autonomous action on inventory and orders is mostly still gated behind a human, and for good reason. The ceiling is your master data. Most generally available capability today is advisor grade: it summarizes, recommends, and drafts, and a human executes. Oracle shipped SCM advisor agents in late 2025; SAP is building an autonomous supply chain across 2026; and the planning platforms, Kinaxis, Blue Yonder, and o9, have shipped agentic features with human-in-the-loop guardrails by design.
The adoption data says be selective. Gartner found about 72% of supply chain organizations using generative AI. Only 23% had a formal AI strategy, and 17% were pursuing a transformational redesign. Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, and an MIT study found 95% of enterprise AI pilots returned nothing measurable.
Where AI genuinely pays, McKinsey estimates AI-enabled operations can cut logistics cost 5 to 20%, inventory 20 to 30%, and procurement spend 5 to 15%. Tariffs made this urgent. As of late 2025 the US average effective tariff rate hit 16.8%, the highest since 1935, and it moved in days, not quarters. The real AI value here is scenario modeling: tariff-adjusted landed cost across a few weighted scenarios, and fast network and supplier redesign. The honest gap is that most organizations can size the exposure in days but still take weeks to align a response.
Scope "assistant" versus "agent" honestly in the contract. Turn on the embedded AI now, use the vendor's native capability over a custom build, and require a named human checkpoint for any action that moves inventory, orders, or money.
9. Planning native or best-of-breed is the strategic call in the program
The strategic call in this whole program is whether planning runs native in the ERP or on a best-of-breed platform. Native is simpler, cheaper, and tightly coupled to execution. Best-of-breed wins when network complexity, scenario speed, or a multi-ERP estate exceed what the ERP planner handles, and it costs you a heavier integration layer. The wrong reason to buy best-of-breed is dissatisfaction that is really a master-data or process problem.
Decide the planning architecture early and govern it. If you go best-of-breed, staff the ERP integration as a first-class workstream and name which system owns which number.
10. Adoption happens on a mobile gun, mid-shift, with targets still running
Supply chain adoption happens in plants and DCs, on mobile guns, mid-shift, with targets still running. It is the hardest adoption in the enterprise, and it is where the value is won or lost. Nike is the proof in both directions. The big-bang planning failure cost more than $100 million in sales and a 20% stock drop. The recovery ran on adoption mechanics: 140 to 180 hours of training per user, a lockout that kept people off the live system until they finished, and rollouts staged by geography on quiet weekends. Slower on the calendar. Faster to value.
Governance decides the rest. The cleanest recent turnaround put a business executive in charge, gave the program lead a direct line to the C-suite, and tied a third of the integrator's fee to milestone delivery. The transferable rule: the business owns the config decisions and the named data owners; the integrator executes and is held to milestone-gated payment. Measure it against the SCOR standard: perfect order fulfillment, on-time-in-full, cash-to-cash cycle time, inventory turns, and forecast accuracy.
Attach the case to named KPIs with a baseline and a cadence: perfect order, OTIF, inventory accuracy, forecast accuracy, and cash-to-cash. Review them monthly, and protect the frontline training budget when the timeline gets tight.
The red flags to run before every gate review
The vendors are capable and the implementers are skilled. What they cannot do is decide how your supply chain should run, or make the floor trust the system.
Keep the product moving
A supply chain ERP program is a sequence of decisions that belong to operations. Which modules, in what order, on what master data, converted to what standard, cut over how, and adopted how. Make those calls early, govern the data, and treat the cutover and the first shipments as the real go-live. The rest is configuration.
Related: implementing finance ERP modules, implementing HCM and HR ERP modules, implementing payroll, and data conversion and integrations.
