ERP Rollout After a Failed Pilot
A utility is migrating 14 core processes to a cloud ERP across three regions in 18 months because the legacy ERP loses vendor support in 20 months. The program covers 6,000 employees, including 2,000 field staff. A pilot in the smallest region went live but missed its goals: data migration reconciliation errors reached 12%, supervisors bypassed the new work-order app and kept using spreadsheets, and overtime rose 9% during cutover. The steering committee wants to start the next two regions on the original schedule to meet the support deadline. The budget is fixed; there is no room for a second pilot. Unions have raised concerns about role changes and monitoring of field crews. You are the lead analyst asked to advise on whether to proceed, and if so, under what conditions.
1. The steering committee wants to start the next two regions on the original schedule. What is your recommendation, and what evidence would you require before proceeding?
Read the worked answer
Recommend a conditional pause, not an unconditional go. The pilot did not fail only because users resisted change; 12% data reconciliation errors and 9% overtime indicate unresolved data ownership, process fit, and cutover capacity. Starting two larger regions on the same pattern would multiply the defect. However, the legacy support deadline is real, so a full stop is also risky. Propose a short 4–6 week remediation gate with exit criteria: reconciliation errors below an agreed threshold, supervisors using the work-order app in daily routines, overtime back within a stated tolerance, and union consultation completed for affected roles. In parallel, start data cleansing and readiness assessments for the next regions, not full deployment. Present the committee with a decision tree: if gates pass, start one region, not two, with a hypercare window; if not, re-sequence. This protects the deadline while avoiding a second failed wave.
2. Design a transformation governance and change plan for the remaining regions. Include decision rights, readiness gates, and union considerations.
Read the worked answer
Governance: three tiers-steering committee owns scope, budget, and go/no-go; a process council of regional process owners resolves standardization and data definitions; region leads run readiness and adoption. Decision rights should be explicit: global process owners decide core design, regions decide only approved local extensions, and the program management office controls sequencing. Readiness gates before each wave: data reconciliation below threshold, end-user training completion, manager readiness, cutover rehearsal, and support capacity. Change plan: identify supervisor champions in each region, involve them in design and testing, and give them data to see crew-level impact. Union: consult early on role changes, monitoring, and reskilling; document agreements; avoid announcing changes before consultation. Use a minimum viable process plus local extensions, and plan hypercare with floor support. This addresses the pilot's real failure modes: data, supervision, and change capacity, not just training.
3. How should the program measure transformation success beyond go-live date?
Read the worked answer
Go-live is a milestone, not an outcome. Measure four layers. Adoption: percent of work orders created in the new app, active supervisor use, and spreadsheet workarounds. Process performance: cycle time for core processes, first-time-right, rework, and overtime. Data quality: reconciliation error rate, master-data completeness, and duplicate records. Benefits: cost per transaction, inventory or asset accuracy, compliance exceptions, and service levels. Add sustainment measures at 30/60/90 days and one quarter after hypercare: defect backlog, support ticket volume, and process conformance audits. Compare against pilot baseline and pre-program baseline. Also track union or workforce indicators such as reskilling completion and voluntary turnover in affected roles. This prevents declaring success at cutover while workarounds and overtime persist.