ERP Post Go-Live: What Happens in the First 90 Days

The first 90 days after ERP go-live can make or break your entire investment. Studies show this is the period when implementations either stabilize and scale — or slip into chaos. I've seen both outcomes at Commsult Indonesia. The go-live event gets the attention, but the 90 days after it determine whether the implementation is actually successful. This post is a practitioner's guide to managing the post-go-live period with discipline rather than hoping things work out.

The Three Phases of Post Go-Live

The 90-day post-go-live period breaks into three distinct phases. Days 1–30 (Stabilization): highest risk, maximum support, intensive monitoring. The primary goal is ensuring core processes work, users can complete their daily tasks, and no critical issues go unresolved overnight. Days 31–60 (Normalization): support intensity reduces, adoption metrics improve (or don't), secondary issues surface as users push beyond basic workflows. Days 61–90 (Optimization): begin addressing the backlog of enhancement requests, run the first post-implementation business process review, and plan Phase 2 development.

Days 1–30: Stabilization Mode

In the first 30 days, run daily stand-ups with department champions. Review three metrics every morning: system uptime, error rate from application logs, and open support tickets by severity. Resolve P1 issues (system down, core process completely broken) within 2 hours — this is non-negotiable. Resolve P2 issues (a process fails for some users, not all) within 24 hours. P3 issues (minor inconvenience, workaround available) get addressed in the weekly sprint. The support channel — a dedicated WhatsApp or Slack group — should be staffed during business hours with a response time commitment of under 1 hour.

Monitoring What Matters

The KPIs that signal ERP health in the first 90 days: Daily Active Users as a percentage of total users (target 80%+ by day 30, 90%+ by day 60), transaction error rate (target under 3% by day 14, under 1% by day 30), support ticket volume (should peak in week 1, drop 50% by week 4), shadow workaround usage (zero by day 60 — if your finance team is still maintaining a parallel Excel sheet, investigate why), and process completion rate (percentage of started workflows that complete without manual intervention).

ERP Post-Go-Live Health Dashboard (Days 1–90)

  PHASE 1: STABILIZATION (Days 1–30)
  ┌─────────────────────────────────────────────────────────────┐
  │ Daily Active Users       │ Target: 80%+ by Day 30          │
  │ Transaction Error Rate   │ Target: <3% by Day 14, <1% D30  │
  │ P1 Issues Open           │ Target: 0 at end of each day    │
  │ P2 Issues Open           │ Target: <5, all with owner+ETA  │
  │ Support Tickets/Day      │ Should peak Week 1, fall by 50% │
  │ Shadow Workarounds       │ Target: 0 by Day 60             │
  └─────────────────────────────────────────────────────────────┘

  PHASE 2: NORMALIZATION (Days 31–60)
  ┌─────────────────────────────────────────────────────────────┐
  │ Daily Active Users       │ Target: 90%+ by Day 60          │
  │ Error Rate               │ Target: <0.5%                   │
  │ Process Completion Rate  │ % workflows completing w/o help │
  │ Training Gaps Identified │ Topics with 5+ repeated tickets │
  │ Phase 2 Backlog Items    │ Enhancement requests collected  │
  └─────────────────────────────────────────────────────────────┘

  PHASE 3: OPTIMIZATION (Days 61–90)
  ┌─────────────────────────────────────────────────────────────┐
  │ First Month-End Close    │ Completed using ERP data only?  │
  │ First ERP Report Used    │ For a real business decision?   │
  │ Shadow Workarounds       │ Confirmed zero across all depts │
  │ Phase 2 Scope Signed     │ Next development cycle planned  │
  └─────────────────────────────────────────────────────────────┘

  SUCCESS DECLARATION criteria (all must be true):
  ✓ DAU > 90% for 30 consecutive days
  ✓ Error rate < 1% for 30 consecutive days
  ✓ Shadow workarounds = 0 (verified by dept audit)
  ✓ First financial period close completed in ERP
  ✓ Board received first ERP-generated management report

Handling the Inevitable Issues

No ERP go-live is issue-free. The question is not whether issues will arise but whether you have a system for handling them. Create an issue register: every reported problem gets a ticket with severity (P1/P2/P3), status (Open/In Progress/Resolved), owner, and resolution date. Review the issue register daily for P1/P2 items. Communicate resolution status to affected users — 'we know about this and are fixing it' reduces frustration more than any technical fix. When the same issue is reported by multiple users, investigate for a systemic root cause before applying individual workarounds.

-- ERP Post-Go-Live Issue Tracker (PostgreSQL)

CREATE TABLE erp_issues (
  id          SERIAL PRIMARY KEY,
  reported_at TIMESTAMPTZ DEFAULT NOW(),
  severity    VARCHAR(2) CHECK (severity IN ('P1','P2','P3')),
  title       TEXT NOT NULL,
  description TEXT,
  reporter    VARCHAR(100),
  department  VARCHAR(50),
  owner       VARCHAR(100),
  status      VARCHAR(20) DEFAULT 'open'
              CHECK (status IN ('open','in_progress','resolved','wont_fix')),
  resolved_at TIMESTAMPTZ,
  resolution  TEXT
);

-- Daily SLA compliance check
SELECT
  severity,
  COUNT(*) FILTER (WHERE status = 'open') AS open_count,
  COUNT(*) FILTER (
    WHERE status = 'open'
    AND severity = 'P1'
    AND reported_at < NOW() - INTERVAL '2 hours'
  ) AS p1_sla_breach,
  COUNT(*) FILTER (
    WHERE status = 'open'
    AND severity = 'P2'
    AND reported_at < NOW() - INTERVAL '24 hours'
  ) AS p2_sla_breach
FROM erp_issues
WHERE reported_at > NOW() - INTERVAL '30 days'
GROUP BY severity;

-- Adoption by department
SELECT
  department,
  COUNT(*) AS issues_reported,
  COUNT(*) FILTER (WHERE severity = 'P1') AS critical_issues,
  MAX(reported_at) AS last_issue_date
FROM erp_issues
GROUP BY department
ORDER BY issues_reported DESC;

The Shadow Workaround Investigation

By day 45, do a systematic shadow workaround audit. Interview each department champion and ask them to show you how their team is completing each core workflow. If any part of a workflow involves Excel, WhatsApp, email, or any non-ERP tool that the ERP was supposed to replace, that's a shadow workaround. Shadow workarounds happen for three reasons: the ERP doesn't support the workflow correctly (a system issue), the user doesn't know how to use the ERP for this workflow (a training issue), or the ERP workflow is significantly slower than the workaround (a UX issue). Each reason requires a different fix.

Planning Phase 2 from the Post-Go-Live Learnings

The post-go-live period is the richest source of Phase 2 requirements. Users who are now working with the real system every day will surface needs that no requirements workshop could have predicted. Collect these requirements systematically: every enhancement request from support tickets, department champions, and informal feedback should go into a Phase 2 backlog. Review and prioritize this backlog at day 60. High-value, quick-win items can often be delivered as hot fixes; larger requirements become Phase 2 development items.

When to Declare Success

ERP success is not declared at go-live. It's declared when: daily active user rate exceeds 90% for 30 consecutive days, error rate is below 1% of transactions, shadow workarounds are at zero, the first financial period close has been completed successfully using ERP data, and the business has produced its first formal ERP-generated report that was used for an actual business decision. In my experience, this typically happens at day 60–90 for well-managed implementations, and day 180–360 for poorly managed ones. The investment in the first 90 days of intensive support determines which outcome you get.