A distributor went bankrupt during an ERP rollout

The company that had to automate

FoxMeyer Drug was, by the early 1990s, a genuinely large business — roughly the fourth-largest pharmaceutical distributor in the United States, moving billions of dollars of prescription drugs annually through a network of warehouses to hospitals and pharmacies. The margins in drug distribution are thin and the volumes are enormous, which means the competitive advantage is almost entirely operational: whoever can fill orders fastest and cheapest wins. By 1993, FoxMeyer's management had concluded that its existing systems could not scale to meet that competition, and it committed to a paired technology programme — SAP R/3 for enterprise resource planning, and a warehouse automation system built by a company called Pinnacle, to be integrated on top of it.

The ambition was reasonable on its face. SAP R/3 had been released in 1992 and was already attracting large manufacturers and distributors across Europe and the United States. The relational database and integrated module architecture that made R/3 compelling — connecting procurement, finance, inventory and fulfilment into a single system — was exactly what FoxMeyer needed if its logic held. The warehouse automation was supposed to accelerate the physical throughput that the software would orchestrate. Together, the investment was reported at around $65 million.

What the logic underestimated was complexity at FoxMeyer's specific scale. The company was processing roughly 500,000 order lines per day — a transaction volume that pushed against what R/3, in its early-1990s configuration, handled comfortably. R/3's design assumed a manufacturing model: discrete jobs, bills of material, production orders. Drug distribution is a different pattern — millions of small picks, continuous replenishment, real-time fulfilment windows measured in hours. The system required extensive customisation to approach FoxMeyer's operational profile, and every customisation made the next upgrade harder and the testing surface wider.

What went wrong and when

The implementation was led by Andersen Consulting, the firm that would later become Accenture. Project timelines slipped. The warehouse automation system, which was being built in a new facility in Washington Court House, Ohio, did not perform at the transaction rates the business required. Testing found significant gaps between the promised throughput and the actual throughput, but the go-live proceeded on schedule rather than being delayed to close them.

The consequences were operational from the first days of live running. Orders were lost or duplicated. Inventory positions in the system diverged from physical stock. Fulfilment errors reached hospital customers — the kind of customer whose supply chain tolerance is essentially zero. Meanwhile, FoxMeyer had done something strategically dangerous: it had signed a large new supply contract with a major university-affiliated hospital network, priced on the assumption that the new automated warehouse would deliver the efficiency gains that justified the pricing. When the warehouse did not perform, the contract became a source of losses rather than revenue.

Throughout 1995 and into 1996, FoxMeyer's management tried to stabilise the operation. Some accounts suggest that the parallel running of old and new systems — the period in which both operate and discrepancies are reconciled — was shortened under schedule pressure, leaving the organisation without the safety net that transition usually provides. Employee resistance in the warehouses was also documented; warehouse workers reportedly feared that the automation would eliminate jobs, and some were accused of deliberate sabotage of the new equipment, though the legal record on this is not conclusive.

By 1996, the financial position was terminal. FoxMeyer's parent company put it into bankruptcy in August of that year, and it was subsequently sold to McKesson, one of its larger competitors, which acquired the customer relationships and wrote off the technology investment. The new automated warehouse, the centrepiece of the programme, was sold for a fraction of its construction cost.

The lawsuit and what it established

The bankruptcy trustee filed suit against both SAP and Andersen Consulting, seeking damages in the hundreds of millions of dollars on the theory that the implementation partners had oversold the system's capabilities, mismanaged the rollout and delivered something that could not perform at FoxMeyer's required volumes. SAP's position, broadly, was that the system could have worked but was misconfigured and that the scope had expanded without adequate controls. Andersen Consulting contended that FoxMeyer's own management decisions — the accelerated timeline, the new supply contract signed before the system was stable — were the primary cause of failure. The suits were eventually settled, without a public ruling on the merits, so the legal record does not establish a clear finding of fault against either party.

What the case did establish, durably, was a set of questions that every large ERP programme since has had to answer before go-live. Could the system handle the actual transaction volume of this specific business, demonstrated in testing rather than estimated? Had the contract assumptions — pricing, margins, customer commitments — been stress-tested against a delayed or degraded implementation? Was the parallel running period long enough? Who carried the risk if the system did not perform at the promised specification?

The case also established something subtler about the relationship between ERP vendors, implementation partners and customers. The vendor sells a platform. The implementation partner shapes it to the customer's environment. The customer operates it. When the chain fails, responsibility is genuinely distributed, which is exactly why the FoxMeyer litigation produced a settlement rather than a judgment: the fault surface was wide enough that no party wanted a court to apportion it.

The residue in practice

FoxMeyer is now cited in almost every serious literature on ERP risk management, alongside Hershey's 1999 go-live failure and, two decades later, Lidl's abandoned SAP programme. The citation tends to carry a specific warning: companies that are operationally complex, running at high transaction volumes, and simultaneously undergoing structural change — new warehouses, new contracts, new customer relationships — are not good candidates for a simultaneous ERP go-live. The technology risk and the business risk compound each other. When both materialise at once, the organisation may not have enough slack to absorb either.

The pharmaceutical distribution market that FoxMeyer was competing in has since consolidated around a small number of very large operators — McKesson, AmerisourceBergen, Cardinal Health — all of whom have run their own large-scale technology programmes in the decades since. SAP R/3, updated and eventually succeeded by SAP S/4HANA, remains in production at distributors and manufacturers across the world. The failures embedded in those later programmes echo the same questions FoxMeyer surfaced in 1996: what the system was actually tested to do, what the contract promised, and who was accountable when the two did not match.