Key Takeaways
- A securities class action alleges that DNOW’s merger proxy materials understated a known ERP system failure at MRC Global before shareholders voted to approve the $1.5 billion acquisition.
- Management described the system as state-of-the-art on the eve of closing, then disclosed roughly three months later that flawed design architecture was slowing core processes and impairing customer service.
- That disclosure erased more than $580 million in market value in a single trading session, which shows that an ERP system failure creates exposure well beyond the project budget.
- Acquirers reduce that exposure by treating the condition of a target’s enterprise software as a diligence question rather than an integration detail to be resolved after closing.
Due diligence teams review contracts, receivables, and pension obligations with considerable rigor. Enterprise software is frequently treated as a technical matter to be sorted out after closing. Yet the condition of a target’s ERP can determine whether the deal thesis survives its first two quarters.
The acquisition of MRC Global by DNOW has become a public example of what happens when that assumption goes untested.
Today, we’ll discuss the ERP integration failures alleged in the resulting lawsuit and what they suggest about diligence, disclosure, and project oversight.
Contemplating litigation?
We have multiple software expert witnesses available for provision of reports, depositions, and testimonies.
What the DNOW and MRC Global Complaint Alleges
DNOW completed its $1.5 billion all-stock acquisition of MRC Global roughly two months after shareholders approved the transaction at a special meeting. Both companies distribute pipe, valves, fittings, and related products to energy and industrial customers, and the combination targeted roughly $70 million in annual cost savings by year three.
One day before closing, management described MRC’s recently implemented ERP as a state-of-the-art system delivering improved inventory management, order processing efficiency, and supply chain optimization. Earlier software problems were characterized as an isolated, one-time event. The merger proxy materials filed with the SEC had gone out to shareholders of record several months earlier.
Roughly three months after closing, the company reported that MRC revenues had declined because of persistent ERP challenges. Management acknowledged that the system’s design architecture was producing inefficiencies in core processes, that the system was slow, impeded customer service, and increased safety stock, and that orders were difficult to process. Remediation required capital expenditure that had not been disclosed previously, and forward guidance was withheld. DNOW shares fell 19 percent that day, erasing more than $580 million in market value.
A securities class action followed, alleging that the proxy materials understated the condition of MRC’s ERP at the time investors were asked to approve the transaction. The claims remain unproven and the matter is ongoing. The same sequence appears in disputes that never reach the securities markets, as the lessons from our ERP failure expert witness practice describe.
Why Design Architecture Problems Surface After Go-Live
An ERP system failure of this kind rarely announces itself on go-live day. Design architecture refers to the structural decisions made early in a project: how the data model is organized, how transactions move between modules, and how far standard software has been altered to preserve existing habits. Those decisions are validated in test environments that use clean data and modest volumes.
Production behaves differently. Four patterns account for most of what surfaces afterward:
- Volume at production scale: Transaction loads expose performance limits that pilot testing never approached.
- Data that only looked clean: Records that passed validation in a test environment fail against live customer, pricing, and inventory data.
- Interfaces under concurrent load: Connections to warehouse and logistics systems process correctly in isolation but stall when they run together.
- Accumulated workarounds: Steps introduced to keep orders moving become a second, undocumented process the business quietly depends on.
For example, a distributor may find that order entry performs acceptably during user acceptance testing and then slows materially once branch teams enter live orders during the morning peak.
Organizations comparing manufacturing software systems weight functional fit heavily and give far less attention to behavior at their own volumes. That distinction matters, because functional fit is visible in a demonstration and performance under load is not.
When an ERP System Failure Becomes a Disclosure Risk
An operational problem becomes a legal problem at the point where it enters an investor communication. Late shipments reduce revenue. Safety stock added to compensate consumes working capital. Field staff hired to work around the system raises operating expense. Each effect lands in a financial statement, and each one requires executives to explain it.
The difficulty is that executives describing project status to investors depend on what project leadership reports upward. An ERP implementation failure treated internally as a temporary stabilization issue can become, on an earnings call, a statement that the system is performing as designed. When the condition does not improve, the distance between those accounts is what opposing counsel examines.
Expert Insight
Our software expert witness consultants have found that the documentary record in these cases is rarely ambiguous. Status reports, steering committee minutes, and defect logs generally show that project teams identified design problems months before leadership characterized the system publicly. The dispute is seldom about whether the problems were known. It is about who was told, when, and in what terms.
How to Reduce ERP Risk in an Acquisition
Acquirers cannot eliminate integration risk, but they can price it accurately and govern it deliberately. The following steps apply whether the target went live last quarter or last year.
1. Assess System Condition Before the Vote
Enterprise software diligence deserves the same weight as a quality-of-earnings review. An independent ERP consultant can evaluate the target’s design decisions, defect backlog, and stabilization trajectory while the transaction can still be repriced. After closing, the acquirer owns both the operational problem and the obligation to describe it accurately.
2. Separate Stabilization From Optimization in Reporting
A system can be stabilized and still be far from optimized. Those are different conditions with different cost profiles, and combining them into a single status produces optimistic guidance. Ask the ERP implementation consultant to report them separately, with defined exit criteria for each.
3. Verify Status Through Transaction Data Rather Than Status Decks
Order cycle time, on-time shipment rate, days sales outstanding, and inventory turns describe system health more reliably than a percentage-complete figure. Buyers researching the best ERP for manufacturing and distribution environments should request those measures at their own volumes rather than reference figures from a larger customer.
4. Establish an Independent Line of Sight to the Board
Project leadership has an understandable incentive to report progress. An external reviewer reporting directly to the audit committee gives directors an account that has not been filtered through the people accountable for the schedule. That structure is routine in large capital projects and belongs in enterprise software programs of comparable consequence.
Learn More About ERP System Failure
The DNOW and MRC Global matter is instructive less for its legal outcome, which remains undetermined, than for its sequence. A structural decision made early in an implementation produced operational problems that reached revenue, then guidance, then the courts. That path is open to any organization that treats enterprise software as a technical program rather than a governed business risk.
Panorama’s software expert witness team and our ERP implementation services help organizations assess system condition, document project decisions, and support counsel when a project becomes a dispute. Contact us below to learn more.
FAQs About ERP System Failure
What separates an ERP system failure from normal post-go-live disruption?
Normal disruption resolves on a predictable curve as users learn the system and defects close. An ERP system failure shows a flat or worsening trend in operational measures such as order cycle time and on-time shipment, and remediation requires design changes rather than additional training or configuration adjustments.
When should an acquirer bring in an independent advisor to review a target’s ERP?
Before the shareholder vote, while the transaction can still be repriced or conditioned. A review conducted during diligence can quantify remediation cost and stabilization timeline. Once the deal closes, the acquirer inherits both the operational problem and the responsibility to describe it accurately to investors.
What should executives ask a project team to confirm that an ERP implementation failure is not developing?
Ask for defect counts by severity over time, transaction performance at peak volume, the number of documented workarounds in active use, and the list of open design change requests. Trends across those four measures reveal system condition far more honestly than a percentage-complete figure.
Why does an ERP system failure create securities exposure rather than only operational cost?
Because the operational effects reach the financial statements and therefore the disclosures. Late shipments reduce revenue, safety stock consumes working capital, and remediation requires unplanned capital expenditure. Once executives describe those conditions to investors, the accuracy of that description becomes a legal question.
What does a software expert witness actually examine in ERP litigation?
Project artifacts, primarily: statements of work, design documents, testing results, defect logs, steering committee minutes, and change orders. The objective is to establish what each party knew about system condition at specific dates, and whether the decisions made at those points met reasonable professional standards.
