ERP Implementation KPIs: What to Measure Before and After Go-Live

An ERP implementation gets judged twice. The first time is go-live: did the system arrive on time, on budget and working? The second comes months later, when finance closes the books, the warehouse counts stock and someone asks whether the business runs any better than before.

If you sponsor the project, you need measures for both. This guide sets out the KPIs that answer three questions in turn: is the project on track, is the system ready to go live, and is the business getting what it paid for. It explains how to define success before the work starts, how to make a status report honest, and the implementation practices that move the numbers. It includes a template for status definitions and a go/no-go checklist you can copy.

DisclosureJake Jorgovan co-founded Alpha Apex Group, which is mentioned in this article.

Three questions your ERP KPIs need to answer

Common ERP KPIs, from schedule adherence to inventory turnover, belong to different stages of the project and have different owners. Sorting them by the question they answer makes a dashboard easier to read and harder to game.

The first two rows tell you whether the project is being delivered. Only the third tells you whether it was worth doing, so define its measures before implementation and record their baselines while the old processes are still running.

Define success in the business's terms before you start

The US Government Accountability Office has documented what a large ERP program looks like without this step. In an October 2010 report on the Department of Defense's ERP programs (opens in a new tab), GAO reported, from the department's own data on status as of December 31, 2009, that six of the nine programs had schedule delays of 2 to 12 years and five had increases of $530 million to $2.4 billion in their reported life-cycle cost estimates. Separately, it found that the department lacked a comprehensive set of performance measures to tell whether the systems were delivering what they were bought for.

GAO's point was that management "needs to define what constitutes a successful implementation" in terms that show whether the system is being used as expected and providing the intended benefits. The department's own guidance, as GAO summarized it, already said how: measures should be written as desired outcomes, be quantifiable, show how far the outcome has been achieved, and not be "focused on system-performance criteria". The examples depended on the system. A logistics system might be judged on lower inventory levels and a higher inventory turnover rate; a financial system on fewer prompt payment penalties and financial statements generated by the system.

One example from the report shows the trap. At two Army depots, the measures used to assess a new logistics system looked at it "from a system-software perspective". They did not show whether the depots could carry out their repair work with it. A system can pass every technical test and still fail the people who run the business on it.

For your own project, that means:

1. Write down three to five business outcomes the ERP system is meant to deliver, in measures the business already uses: days to close the books, inventory accuracy, order cycle time, late-payment penalties, manual journal entries.
2. Record today's figure for each before the project starts. After go-live, a comparable baseline is harder to reconstruct.
3. Give each measure a target, a target date and an owner in the business who will still be accountable for it after the project team leaves. Record how it is calculated, where the data comes from and how often it is reported.
4. Link each measure to the processes and modules in scope. If no module affects a measure, it is not a measure of this project.

Project management KPIs: is the project on track?

These are the familiar project-office measures. Their value depends on the baseline they are measured against, and on someone with the time to run the plan: if the project needs a dedicated lead, the guide to project manager recruiters covers that hire.

Schedule adherence

Compare actual milestone dates with a baselined plan, and track the forecast date for go-live as well as the dates already missed. The plan needs to be one integrated schedule that links the system integrator's work, the vendor's work and your own team's tasks. GAO found that none of the four DOD programs it analyzed had a fully integrated master schedule, and concluded that without a reliable schedule the department could not predict "with any degree of confidence" whether completion dates were realistic.

Cost against budget

Report actual spend, committed spend and the forecast cost at completion, with approved change requests shown separately so they do not disappear into the baseline. Schedule and cost belong on the same page: in GAO's assessment, none of the four programs' cost estimates could be considered credible because they did not assess the cost effects of schedule slippage. A late project also keeps the old systems running longer.

Scope changes

Count change requests raised, approved and rejected each month, and their effect on cost and dates. A steady flow of approved changes late in the build can be an early sign that requirements were not settled.

Decisions and resources

Track decisions the business owes the project that are past their due date, and whether the business staff assigned to the project are actually available for the hours planned. Both are leading indicators: a decision that slips this month can show up as a missed milestone later.

Risks and issues

Report the count of open high-severity risks and issues, how long each has been open and whether each has an owner and a mitigation date.

Make the status report honest: define red before you need it

If your steering report uses a red, amber and green status, write down what each color means. Without definitions, the person writing the report chooses the color, and nobody wants to be the one who reports red.

In 2023 I wrote about the management system we built as my business grew. We tracked the health of every client account with green, yellow and red statuses, and each status had a quantified definition. Red meant something specific had happened, for example a client complaint, a mistake on the account or a failure to deliver the agreed scope. We walked through the accounts in a weekly management meeting. The reason was simple: "if you just ask people 'How's it going?' They will always say great. You need quantitative data and ways to measure the key performance aspects of your business."

An ERP steering committee needs the same discipline. Agree the definitions at kickoff, in numbers, for each measure on the dashboard. Then the color follows from the facts, and a red status starts a conversation about the cause.

Image

Zoom

The approach described in this article, shown as a visual guide.

The limits and thresholds depend on the size and risk of your project, so set them with your implementation partner and record them in the project charter. What matters is that they are written down before anyone has a reason to argue about them.

Go-live readiness KPIs: is the system ready?

Go-live should be a decision made against written criteria. Microsoft's implementation guide for Dynamics 365 (opens in a new tab) describes the readiness review as "a quality gate for deployment" and says the team should assess readiness "early and often", so that stakeholders and the steering committee can make "a well-informed go/no-go decision". Its readiness plan covers testing, deployment packages, data migration, the cutover plan, training and security roles, licenses and production support, and it asks for an owner for every action that mitigates a risk.

The guide is written for one vendor's products, but the gate applies to any ERP system. It also warns about timing: starting the review only a few days before the go-live date risks a delay, and starting too early can mean the project is not mature enough, or there is not enough information, for a reliable answer. In Microsoft's description of the later phases (opens in a new tab), the cutover plan includes go/no-go criteria and the team schedules mock go-lives before the real one.

Turn those criteria into measures you can read on one page in the final weeks:

Delay go-live if an agreed readiness criterion is unmet or a risk to critical business operations, such as invoicing customers or paying suppliers, has no accepted mitigation.

After go-live: is the business getting what it paid for?

Microsoft calls the period after go-live the Operate phase and names stabilization as its goal. This is where the business measures you baselined at the start become the main report.

Reliability: can people complete critical work?

Performance testing before go-live does not end the need to watch performance. Keep monitoring availability, failed transactions and response times for the processes that depend on the system, agree acceptable service levels with the business, and review any breaches alongside support tickets, especially at month-end and other peak periods.

Adoption: are people using the system for the work it replaced?

Adoption is an early sign of whether the outcome measures will move. Measure it by role and process, beyond logins: the share of purchase orders, invoices or journal entries processed in the new system, and the spreadsheets and side systems that are still in use for work the ERP was meant to absorb. Track support tickets by week and by process, and investigate a rising queue where it appears: the cause may be a training gap, a design problem, an outage or simply more transactions.

Ask the people using the system too. Use short, regular surveys of the employees affected by the change alongside the transaction counts to understand what is holding adoption back.

Business outcomes by process

The measures below are examples. Choose the few that match the outcomes you wrote down at the start, and compare each with your own baseline before you look for an outside benchmark: benchmarks vary widely by industry and company size.

Review these measures alongside changes in demand, staffing and business policy before you credit or blame the ERP system for a change. The last row matters more than it looks. GAO noted that the delays forced the department to fund the legacy systems the ERP programs were meant to replace for longer than it had planned. Retiring the old systems on time is part of the return.

ERP implementation best practices that move the numbers

KPIs show where a project stands; they do not deliver it. Five implementation practices bear most directly on the measures above.

1. 1

   Set business goals and requirements before configuration

   Map the processes in scope, decide what each must do better and turn those goals into the outcome measures above. If you are still choosing a system, the guide to ERP selection covers that decision first.

2. 2

   Put the leaders whose teams will change on the project from the start

   Department heads who will run the new processes should help decide them, with clear roles for who decides, who advises and who is informed. Nestlé USA's experience, described below, shows what happens when they are left out.

3. 3

   Clean the data and test the migration in stages

   Audit the data you plan to move, agree how old fields map to new ones and what is archived, then migrate a small set first and scale up. Reconcile every trial run against the old system.

4. 4

   Test end to end and rehearse the cutover

   Test whole processes across modules and integrations. For critical processes, consider a parallel run in which old and new systems process the same transactions so the outputs can be compared before the switch.

5. 5

   Train by role and plan support beyond go-live

   Train each group on the work it will do in the system, provide guides people can look things up in, and staff a support model with named contacts for the weeks after go-live.

A case in point: Nestlé USA's SAP project

Nestlé USA's SAP project is an old story, but it shows why these measures matter. The details come from CIO magazine's account of the project, published in May 2002 (opens in a new tab).

In 1997 a team reviewing Nestlé USA's systems found that its brands were paying 29 different prices for vanilla to the same vendor. Each factory named the ingredient differently, so nobody could compare. A smaller team spent 18 months examining item data across the divisions to give every item a common structure. Even before four of the modules went live in late 1999, employees were resisting the change. None of the groups whose work would change had been represented on the key stakeholders team, which the company's CIO, Jeri Dunn, later called her "near fatal mistake". By the beginning of 2000, help desk calls had reached 300 a day. In the rush to meet the Y2K deadline, the team had also overlooked the integration points between modules: purchasing ran on common systems but was not connected to finance, planning or sales.

The team reset the project. It started again from the business requirements and set the end date from them, instead of fitting the work to a date fixed in advance. A director of process change joined as liaison with the divisions, and the team began regular surveys of the employees affected by the new systems. When CIO wrote in May 2002, the final rollouts were still planned for early 2003. It put the project's cost at $210 million and reported Dunn's claim that it had already saved the company $325 million, with supply chain improvements, including more reliable demand forecasts, accounting for a major part.

Those figures belong to Nestlé USA's own project. The Swiss parent's separate global agreement with SAP, a $200 million contract plus $80 million for consulting and maintenance, is a different program. Read in measurement terms, the case shows each of the signals in this guide: duplicate item prices as a data measure, help desk volume and employee surveys as adoption measures, unconnected modules as what end-to-end testing is for, and an end date set from requirements as a schedule decision.

Common questions about ERP project KPIs

How many KPIs should an ERP project track?

Fewer than you might expect. A sponsor needs a handful of delivery measures, a go-live checklist and three to five business outcome measures. Detailed measures can sit underneath for the teams that act on them.

When is an ERP implementation complete?

Go-live is one milestone along the way. Agree the project's closure criteria before implementation: business acceptance, a stabilization period, handover to support and a plan to retire the replaced systems. Business owners keep tracking the outcome measures against their targets after the implementation team leaves.

Why do ERP implementations fail?

The reasons that recur in the cases above are a schedule nobody can rely on, success defined only in system terms, the people whose work changes left out of the decisions, poor data, and too little training and support after go-live.

What should an ERP KPI dashboard show the executive team?

One page: the forecast go-live date and cost at completion against the baseline, with their status colors; the open risks that could stop the business operating; and, after go-live, adoption and the business outcome measures against their baselines.