What ERP really delivers after go-live, and when

Success depends on when you ask

Ask a company how its new ERP is going one month after go-live, and you may hear that it was a mistake. Ask the same company two years later, and you may hear that nobody can imagine working without it. Both answers can be honest.

In 2002, Andrew McAfee published a rare natural experiment. A US high-tech manufacturer moved its whole order-fulfillment operation onto an enterprise system on a single day, without other big process changes at the same time. Right after the switch, lead times got longer and on-time delivery got worse. McAfee called it a performance dip, like the one factories see when new machines arrive on the shop floor. Then the numbers improved along a learning curve, and after several months they were clearly better than before the switch.¹ Order volumes, headcount and new product launches did not explain the pattern.

Research that followed ERP adopters over time reached the same conclusion from another direction. Lynne Markus and her colleagues found that the success of an ERP system depends on when it is measured, and that success at one point in time may be only loosely related to success at another.²

So when people ask us what ERP really delivers, the honest answer starts with a shape. It usually costs a little first, then pays, and the payoff arrives in a fairly predictable order.

What the success numbers say

“Most ERP projects fail” is one of those lines that everyone repeats and few can source. The answer depends on what you count as success.

Count budget and schedule, and recent numbers look calmer than the folklore. Panorama Consulting’s 2026 ERP Report surveyed 170 organizations between January 2025 and January 2026. About half finished on budget and a fifth came in under. In all, 30% went over budget, and 7.1% went significantly over. On schedule, 22.3% finished late.⁶

Count the business case, and the picture is harsher. Speaking at Gartner’s Symposium in November 2025, Dixie John, Gartner’s senior director of ERP strategy, said that 70% of ERP initiatives fail to fully meet their original business case goals, and 25% fail catastrophically.⁷ Both views can hold at once. A project can land on budget and still not deliver the benefits that justified it.

Averages also hide the tail. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects, not only ERP. The average cost overrun was 27%, which sounds survivable. But one project in six was a “black swan,” with an average cost overrun of 200% and a schedule overrun of almost 70%.⁸ Most companies can absorb the average. Few can absorb the tail.

This is why we define success three times on a project, following the phases Markus and her colleagues used. The project succeeds if it goes live on time, on budget and with the agreed scope. The shakedown succeeds if the dip is shallow and short. The business succeeds if the numbers that justified the project have moved, one and two years later. A project can pass the first test and fail the third, and the reverse can happen too.²

The most useful question in Panorama’s survey is a different one. Among organizations with at least one phase live for a year or more, it asked which of their expected benefits they actually got.

Productivity and efficiency came through for 87.3% of the organizations that expected it. New operating models came through for 40.7%. Benefits that live inside one team’s daily work arrive. Benefits that need people across teams to decide differently are harder.

One caution about surveys like this. In the 2025 edition, removing silos was near the bottom of the same chart, at 55.2%. A year later it was second, at 77.4%.^9,6 The respondents change every year. Treat any single survey figure as a weather report, not a law.

Why performance dips after go-live

Researchers call the months after go-live the shakedown phase: the stretch from switching on the new system to normal operations.² This is where the dip lives, and the mechanism is ordinary.

On go-live day, every order meets the new rules at once. An item without a price stops a sales order. A unit of measure set up wrong stops a pick list. A credit limit that nobody knew about holds an invoice. People who could run the old process with their eyes closed now stop to ask what a field means. Each hold is small. Together they stretch the time from order to delivery.

The same mechanism explains the recovery. Most fixes are permanent. Once the price list is complete, it stays complete. Once someone has cleared the same exception three times, the fourth takes a minute. Exceptions fall week by week, and the new flow, which no longer needs anyone to re-key an order into a second system, starts to beat the old one.

Part of the dip is also in the measuring. During cutover, open orders and unpaid invoices move across in bulk. Customers who get their invoices late pay late, so receivable days rise for a while. And a report in the new system may not count things the way the old spreadsheet did. That is why the first month’s numbers deserve less trust than the third month’s, in both directions.

The large studies agree on the shape, if not the size. Lorin Hitt, D.J. Wu and Xiaoge Zhou looked at about 350 firms that licensed SAP R/3 between 1986 and 1998. Adopters did better than non-adopters on labor productivity, return on assets, inventory turnover and receivables turnover, and the stock market valued them about 13% higher. They also found a slowdown in performance and productivity shortly after implementation.³ Robin Poston and Severin Grabski found that cost of goods sold as a share of revenue improved only in the third year after implementation, while the number of employees per unit of revenue fell in each of the three years. Residual income, their measure of overall profit, did not improve at all.⁵

The dip is common, not compulsory. Mark Cotteleer and Elliot Bendoly studied a manufacturer whose order lead time improved right after go-live and kept improving.¹⁰ We still plan for a dip on every rollout, and spend the weeks before go-live making it short and shallow: clean item and customer masters, and people who have rehearsed real orders end to end.

Which benefits arrive, and when

A widely cited map of ERP benefits comes from Shari Shang and Peter Seddon. They analyzed 233 vendor success stories and interviewed managers at 34 organizations, then sorted everything they found into five dimensions: operational, managerial, strategic, IT infrastructure and organizational, with 21 sub-dimensions underneath.¹¹ The map is useful because each dimension tends to arrive at a different time.

Operational benefits come first because they sit closest to the transaction. IT infrastructure benefits can start on go-live day, when the old tools are switched off. Managerial benefits need history: you cannot plan stock from live data until that data has been right for a few cycles. Strategic and organizational benefits come last, because they depend on people changing how they decide.

Panorama’s 2026 numbers fit the same pattern. The benefit most often realized was productivity and efficiency, an operational gain. The least often realized was new operating models, which is organizational change by another name.⁶ Hitt’s data showed a similar early signal: receivables turnover improved both during and after implementation, while most other ratios gave back part of their gain once the project ended.³

The financial studies line up with that order. Andreas Nicolaou compared 247 ERP adopters with matched firms and found that adopters showed better financial performance only after two years of continued use.⁴ James Hunton and his colleagues found that adopters beat matched non-adopters over three years, but mainly because the non-adopters declined while the adopters held steady.¹² Sometimes the benefit of ERP is the decline you avoided. You can only see that with a comparison.

Measure before you migrate

Here is the uncomfortable part. Many companies can’t say what their ERP delivered, because they never measured the “before.”

The moment passes quickly. Once the old system is switched off, its data gets harder to query, the spreadsheets drift, and the people who knew how the old numbers were built move on. Six months after go-live, someone asks whether order lead time has improved, and nobody can say what it was.

So before go-live we pick a short list of numbers, write down exactly how each one is calculated, and compute it from the old system for the past year. The definition matters as much as the number. “Order cycle time” can mean order to dispatch or order to delivery, calendar days or working days, the average or the median. If the baseline and the new report use different definitions, the comparison is noise.

Two habits make a baseline trustworthy. First, freeze it. Finance and operations sign off the numbers before go-live, so nobody can quietly revise the “before” later to flatter the “after.” Second, record the context next to each number: order volume, headcount, product mix. McAfee could rule out volume and headcount as the cause of his results only because those figures existed.¹

Not every number is worth reading at the same time. Rework tells you something in the second week. Inventory turns need at least one full stock cycle. Margin and return on assets need years. Reading a slow number too early is how sound projects get called failures.

Reading the numbers after go-live

After go-live, collecting the numbers is the easy part. In ERPNext, for example, most of them come from standard reports such as Sales Order Analysis and Accounts Receivable, so they cost nothing to pull every month. Reading them well takes more judgment.

We hold ourselves to three rules. Compare like with like: the same definition, and the same months last year if the business is seasonal. And ask what else changed. A new sales head, a price rise or a lost customer can move these numbers more than any software. If one branch goes live later than the others, it makes a useful comparison for a few months.

Expect the dip, but give it a limit. Agree before go-live how deep and how long a dip is acceptable. A number that is still getting worse in month three is no longer shakedown. It is a problem that needs an owner.

And keep working on the system after go-live. Nicolaou and Somnath Bhattacharya tracked 182 changes that 83 ERP adopters made after their systems went live. Firms that made early enhancements, such as add-ons or upgrades, did better financially than other adopters. Late enhancements and abandonments went with worse results.¹³ Go-live is where improvement starts, not where the project stops.

So when someone asks what your ERP delivered, a real answer has three parts: the number before, the number now, and how long ago you went live. Without the first, the other two are just opinions.