Every ERP program has a go-live date. Far fewer have a date on which someone checks whether the business is better off. A value-realization plan closes that gap, and it only works if it exists before the system goes live.
- Business caseOutcomes are written down
- DesignMeasures, baselines and owners agreed
- Go-liveThe plan is already in place
- First reviewResults checked against the baseline
The usual sequence, and where it breaks
In many programs the business case is written to win approval and then set aside. The project team plans design, build, testing and cutover. Benefits come up again after go-live, when the team has moved on, the old baseline has been lost and nobody is sure who was meant to deliver what.
The result is a system that works and a business that cannot say what changed.
What a value-realization plan contains
It does not need to be long. For every outcome the program promised, it answers six questions.
- Outcome. What will be different for the business, in plain terms.
- Measure. How that difference will be observed.
- Baseline. Where the measure stands today, recorded before anything changes.
- Owner. The named business leader who is accountable, not the project manager.
- Enabler. The design, data or process decision that makes the outcome possible.
- Review point. When and how the result will be checked after go-live.
Why it has to come before go-live
Design decisions still depend on it. Once configuration is frozen, an outcome that needs a particular report, approval step or data field becomes a change request. Before design is complete, it is simply a requirement.
Baselines cannot be recovered later. The old process can only be measured while it is still running. After cutover, how long something used to take becomes a matter of memory.
Owners are available now. During the program, business leaders sit in workshops and approvals. After go-live they return to daily operations, and ownership that was never agreed is easily lost.
It sharpens testing and cutover. If the plan names what must work for an outcome to be achieved, those scenarios belong in user acceptance testing and on the go-live checklist.
A simple format to start with
A single table is enough to begin. The rows below are an illustration only. Replace them with your own program's outcomes and measures.
| Outcome | Measure | Baseline | Owner | Enabler | Review point |
|---|---|---|---|---|---|
| Faster month-end close | Working days from period end to close | Record before go-live | Head of Finance | Standard posting rules, clean opening balances | First two closes after go-live |
| Fewer stock mismatches | Variance between system and physical stock | Record before go-live | Head of Operations | Location structure, counting process | Monthly for the first quarter |
| Clearer receivables position | Share of invoices past due, by customer group | Record before go-live | Finance lead | Customer master data, dunning rules | Monthly review |
Questions for the steering committee
Before approving go-live, ask:
- Can we state each promised outcome and the measure that will show it?
- Is the baseline for each measure recorded and agreed?
- Does every outcome have a named business owner who has accepted it?
- Are the scenarios that enable each outcome covered in testing and cutover readiness?
- When is the first review after go-live, and who will present it?
After go-live
Keep the review light and regular. Report each measure against its baseline, record what has not moved and decide what to do about it. A measure that has not improved is useful when someone owns the next step. Without a plan it simply goes unnoticed.
If your program is approaching design freeze or cutover, a plan can still be added. Earlier is easier, and the first step is writing down the outcomes.
Draft for review. Prepared by HindustanIQ Consultants LLP and not yet published.
Related: ERP Advisory & Transformation · More insights