How to measure whether enterprise platform implementation services is working
How do you measure whether an enterprise platform implementation is working?
Measure an enterprise platform implementation on three things: whether people use it instead of the workarounds, whether the process it supports got faster or more accurate, and whether it runs without unplanned intervention. Go-live date, modules delivered and training attendance measure the project, not the platform.
Measure an enterprise platform implementation on three things: whether people use it instead of their workarounds, whether the underlying process got faster or more accurate, and whether it runs without unplanned intervention. Go-live date, modules delivered and training attendance measure the project. They say nothing about whether the platform is working.
Steering committees track the second list because it is easy to collect and comfortable to report. This article gives you the first list instead: which metrics to baseline before cutover, what to read at thirty, ninety and one hundred and eighty days, which numbers actively mislead, and how to instrument all of it without starting a reporting project of its own.
The three questions any metric has to serve
A platform implementation is a bet that a process will be better afterwards. Every useful metric answers one of three questions about that bet, and a metric that answers none of them is decoration.
The first question is adoption: are the people who are supposed to use this actually using it, for the work it was bought for, rather than keeping a parallel spreadsheet. The second is process outcome: did the cycle time, error rate, cost per transaction or reconciliation gap move in the direction that justified the business case. The third is operability: does the platform run at the service level you promised the business, without an engineer intervening every week.
Adoption without process outcome means you have moved work into a new system and gained nothing. Process outcome without operability means the gain is fragile and will erode when the implementation team leaves. Both without adoption usually means you are measuring a pilot group rather than the organisation. A definition of what counts as usage sits in our note on adoption metrics.
What to measure, and when to read it
Different metrics become trustworthy at different points. Reading an adoption number in week two tells you about training logistics, not about the platform. This table sets out the sequence we use on enterprise platform implementation programmes.
| Phase | Question it answers | Metric to read | Reads false when |
|---|---|---|---|
| Before cutover | What are we comparing against? | Baseline cycle time, error rate and manual touches per transaction | Baselined from a good month rather than a normal one |
| Cutover week | Did the data arrive intact? | Reconciliation variance between source and target, by control total | Only the headline total is reconciled and sub-ledgers are not |
| Day 30 | Are people in the system at all? | Share of in-scope transactions created in the platform, not imported later | Measured on the pilot team or on a light-volume period |
| Day 30 | Is it stable enough to leave alone? | Unplanned interventions per week and P1 incident count | Hypercare engineers are fixing things before tickets are raised |
| Day 90 | Did the process improve? | Cycle time and error rate against the pre-cutover baseline | Volume is still below normal because the backlog was cleared early |
| Day 90 | Are the workarounds gone? | Count of active shadow spreadsheets and offline approvals | Nobody asked the team directly; system logs cannot see a spreadsheet |
| Day 180 | Is the business case holding? | Cost per transaction and headcount actually redeployed | Savings are claimed on roles that were never backfilled anyway |
| Continuous | Is support sustainable? | Ticket volume trend and share resolved without engineering | Tickets are being closed as user error rather than routed to a fix |
The metrics that mislead
Four numbers are reported in almost every steering pack and are close to meaningless on their own.
Licence utilisation counts people who logged in, which includes everyone who logged in once, hated it and went back to email. Replace it with the share of in-scope transactions that originated in the platform. Training completion counts attendance, not competence; replace it with error rate by team in the first month. Modules delivered counts scope, not value; a module nobody uses is negative value because it still needs patching. And user satisfaction surveys taken during hypercare measure the implementation team's attentiveness, not the platform, which is why the score usually falls when they leave.
There is a fifth trap worth naming: reading an average when the distribution is what matters. If mean approval time halves while the slowest decile triples, the platform has improved the easy cases and broken the hard ones, and the hard ones are where your risk lives. Report the ninetieth percentile alongside the mean or you will not see it.
How to instrument this without a reporting project
Define the indicator before the target
Agree precisely what is being counted before anyone argues about the number it should hit. Is an order cycle measured from customer submission or from the moment it clears credit check? Google's site reliability engineering practice of defining service level indicators before setting objectives applies exactly here: an indicator nobody can dispute is worth more than an ambitious target nobody trusts.
Take the baseline before anything changes
The single commonest measurement failure is having no credible before. Baseline during a normal month, not a quiet one, and capture manual touches per transaction by observation rather than by asking. Once the platform is live the old numbers are unrecoverable, and every claimed improvement becomes an argument.
Instrument the process, not the screens
Event logs from the platform tell you what the platform did. They cannot see the spreadsheet that still runs the month-end close. Pair the system metrics with a short monthly conversation with two or three people who do the work, and ask one question: what did you do outside the system this month, and why. That question finds more than any dashboard.
Put the numbers where decisions happen
A weekly operations review with four numbers beats a fifty-page monthly pack. Each number needs an owner who can change it, and a stated action if it moves the wrong way. Measurement that produces no decision is overhead wearing a lanyard.
What good looks like at each checkpoint
Use these as sanity checks rather than contractual targets, because they vary by sector and by how messy the incumbent process was.
- Cutover week: control totals reconcile to zero variance, not to an acceptable tolerance, and every exception has a named owner
- Day 30: most in-scope transactions originate in the platform, and unplanned interventions are trending down week on week
- Day 30: the P1 list is empty and the P2 list is shrinking, with fixes rather than manual workarounds behind the closures
- Day 90: cycle time has moved measurably against baseline and the error rate is at or below the old process
- Day 90: shadow spreadsheets for in-scope work have been retired, or you know exactly why each survivor exists
- Day 180: the business case numbers are being reported from the platform itself rather than reassembled by hand
- Day 180: support has moved from the implementation team to a Care Plan or your own team without a spike in tickets
One more checkpoint deserves a place in the plan and rarely gets one: the first full statutory cycle. For finance platforms that is the first quarter-end and the first GST return prepared entirely from the new system; for people platforms it is the first full payroll run with no parallel; for supply chain it is the first stock count. Nothing shorter than a complete cycle proves the platform can carry the work, because the exceptions that break implementations cluster at period boundaries rather than in daily volume.
When measurement is the wrong focus
Two situations where more measurement makes things worse. If adoption is poor because the process design was wrong, no dashboard fixes it; you need to go back to the people who do the work and change the design, which is the failure pattern described in why enterprise software implementations fail on adoption. Counting logins harder will not help.
The second is a phased rollout still in flight. Comparing module three against a baseline taken before module one confuses the effect of the platform with the effect of everything else that changed, and it tempts teams to declare victory on partial data. During a phased go-live, measure each module against its own baseline and hold the programme-level verdict until the last one has run a full cycle.
What this looked like on a real programme
On a university ERP programme we replaced finance and admissions module by module around the academic calendar. Adoption was never in doubt for finance, because the old screens were switched off; the number that mattered was reconciliation variance during each cutover and the count of manual journal corrections in the following month. Admissions was the opposite: the old process lived partly in spreadsheets, so we counted applications that completed entirely inside the platform. The full engagement is described in modernising a university ERP without a rewrite.
Who owns the numbers after the implementers leave
Measurement dies about six weeks after the delivery team goes home unless someone is accountable for it. Name that person before cutover and give them the weekly review slot. Where the ongoing operation sits with us, it is part of a maintenance and support engagement, with Care Plans from $1,000 or ₹68,000 a month on Essential, $2,500 or ₹1,60,000 on Standard and $5,250 or ₹3,40,000 on Enterprise with a one-hour response and a named engineer. Tiers and response times are published on the pricing page.
Related reading
Data migration for platform implementations covers the reconciliation work behind the cutover metric, zero-downtime cutovers explains how the cutover week is planned, and the ROI of enterprise platform implementation services turns these measurements into a business case that survives review.
Measure the process you were trying to improve, baseline it before you touch anything, and treat any metric nobody would act on as a number you can stop collecting.
Frequently asked questions
What is the best single metric for an enterprise platform implementation?
▾
The share of in-scope transactions that originate in the platform rather than being imported or reconciled later. It captures adoption and process change in one number, and it is hard to game. Pair it with cycle time against a pre-cutover baseline so that usage without improvement is visible.
When should we start measuring after go-live?
▾
Baseline before cutover, reconcile control totals during cutover week, then read adoption and stability at day thirty, process outcome at day ninety and business case at day one hundred and eighty. Earlier readings mostly reflect training logistics and hypercare attention rather than the platform itself.
Why do satisfaction scores fall after the implementation team leaves?
▾
Because the score was partly measuring the team's responsiveness during hypercare, not the platform. When day-to-day support moves to a Care Plan or an internal team, expect a dip, and judge the platform on transaction share, cycle time and unplanned interventions instead of sentiment.