Skip to main content
BlogERP

Post Go-Live ERP: Apa yang Terjadi dalam 90 Hari Pertama

90 hari pertama setelah go-live ERP adalah saat implementasi menstabilkan atau gagal — apa yang perlu dipantau, cara mendukung pengguna, dan metrik yang menandakan keberhasilan atau tekanan.

Matthews Wong

Software Engineer

Juni 202510 menit baca
ERP

Ringkasan Utama

Sembilan puluh hari pertama setelah go-live ERP menentukan apakah investasinya stabil atau jatuh ke dalam kekacauan. Pekerjaan di jendela waktu itu tidak menarik: menghabiskan antrean defect, memperbaiki data yang terlanjur salah dimasukkan di bawah tekanan, dan melatih ulang orang yang diam-diam kembali ke proses lama.

90 hari pertama setelah go-live ERP dapat membuat atau menghancurkan seluruh investasi Anda. Studi menunjukkan ini adalah periode ketika implementasi menstabilkan dan skala — atau tergelincir ke dalam kekacauan. Saya telah melihat kedua hasil dalam pekerjaan konsultasi ERP freelance saya. Acara go-live mendapat perhatian, tetapi 90 hari setelahnya menentukan apakah implementasi benar-benar berhasil.

Tiga Fase Post Go-Live

Periode 90 hari pasca go-live terbagi menjadi tiga fase berbeda. Hari 1–30 (Stabilisasi): risiko tertinggi, dukungan maksimum, pemantauan intensif. Hari 31–60 (Normalisasi): intensitas dukungan berkurang, metrik adopsi meningkat (atau tidak), masalah sekunder muncul. Hari 61–90 (Optimalisasi): mulai menangani backlog permintaan peningkatan, menjalankan tinjauan proses bisnis pertama pasca-implementasi.

Hari 1–30: Mode Stabilisasi

Dalam 30 hari pertama, jalankan stand-up harian dengan champion departemen. Tinjau tiga metrik setiap pagi: uptime sistem, tingkat kesalahan dari log aplikasi, dan tiket dukungan terbuka berdasarkan tingkat keparahan. Selesaikan masalah P1 dalam 2 jam — ini tidak dapat dinegosiasikan. Selesaikan masalah P2 dalam 24 jam.

Memantau yang Penting

KPI yang menandakan kesehatan ERP dalam 90 hari pertama: Pengguna Aktif Harian sebagai persentase dari total pengguna (target 80%+ pada hari ke-30), tingkat kesalahan transaksi (target di bawah 3% pada hari ke-14), volume tiket dukungan (harus memuncak di minggu 1, turun 50% pada minggu ke-4), penggunaan solusi sementara bayangan (nol pada hari ke-60), dan tingkat penyelesaian proses.

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

Dari pengalaman saya mengimplementasikan ERP sebagai konsultan ERP freelance: lakukan rapat tinjauan formal 30 hari dengan semua kepala departemen. Bukan sesi keluhan — tinjauan terstruktur dengan data. Tunjukkan metrik adopsi, tingkat kesalahan, masalah terbuka, dan masalah yang diselesaikan. Minta setiap kepala departemen menilai kesiapan tim mereka pada skala 1–5.

Menangani Masalah yang Tidak Dapat Dihindari

Tidak ada go-live ERP yang bebas masalah. Pertanyaannya bukan apakah masalah akan muncul tetapi apakah Anda memiliki sistem untuk menanganinya. Buat register masalah: setiap masalah yang dilaporkan mendapat tiket dengan tingkat keparahan, status, pemilik, dan tanggal penyelesaian.

-- 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;

Investigasi Solusi Sementara Bayangan

Pada hari ke-45, lakukan audit solusi sementara bayangan yang sistematis. Wawancarai setiap champion departemen dan minta mereka menunjukkan cara tim mereka menyelesaikan setiap alur kerja inti. Jika ada bagian dari alur kerja yang melibatkan Excel, WhatsApp, email, atau alat non-ERP apa pun yang seharusnya digantikan ERP, itu adalah solusi sementara bayangan.

Sinyal pasca-go-live paling berbahaya bukanlah banjir tiket dukungan — melainkan keheningan radio setelah ledakan awal. Ketika tiket dukungan tiba-tiba turun ke nol pada minggu ke-2, biasanya berarti salah satu dari dua hal: sistem bekerja dengan sempurna (tidak mungkin) atau pengguna telah menyerah melaporkan masalah dan menemukan solusi sementara (sangat mungkin).

Merencanakan Fase 2 dari Pembelajaran Post-Go-Live

Periode pasca-go-live adalah sumber terkaya dari persyaratan Fase 2. Pengguna yang sekarang bekerja dengan sistem nyata setiap hari akan mengangkat kebutuhan yang tidak dapat diprediksi oleh workshop persyaratan mana pun. Kumpulkan persyaratan ini secara sistematis: setiap permintaan peningkatan dari tiket dukungan, champion departemen, dan umpan balik informal harus masuk ke backlog Fase 2.

Kapan Menyatakan Keberhasilan

Keberhasilan ERP tidak dinyatakan saat go-live. Ini dinyatakan ketika: tingkat pengguna aktif harian melebihi 90% selama 30 hari berturut-turut, tingkat kesalahan di bawah 1% transaksi, solusi sementara bayangan nol, penutupan periode keuangan pertama berhasil diselesaikan menggunakan data ERP, dan bisnis telah menghasilkan laporan ERP pertama yang digunakan untuk keputusan bisnis nyata.

FAQ

Pertanyaan Umum

Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.

Apa saja tiga fase periode pasca go-live dan apa fokus masing-masing fase?

Periode 90 hari terbagi menjadi Stabilisasi (hari 1–30), Normalisasi (hari 31–60), dan Optimalisasi (hari 61–90). Fase Stabilisasi memiliki risiko tertinggi dan berfokus pada memastikan proses inti berjalan serta menyelesaikan masalah kritis dengan cepat. Fase Normalisasi memantau apakah metrik adopsi benar-benar meningkat, sementara Optimalisasi menangani backlog permintaan peningkatan dan merencanakan pengembangan Fase 2.

Bagaimana cara memprioritaskan masalah P1, P2, dan P3 selama 30 hari pertama?

Masalah P1 — sistem mati atau proses inti benar-benar tidak berjalan — harus diselesaikan dalam 2 jam dan ini tidak dapat dinegosiasikan. Masalah P2, di mana proses gagal untuk sebagian pengguna, harus diselesaikan dalam 24 jam. Masalah P3 yang bersifat ketidaknyamanan minor dan memiliki solusi sementara ditangani dalam sprint mingguan.

Mengapa penurunan tiket dukungan secara tiba-tiba justru menjadi tanda bahaya, bukan kabar baik?

Ketika tiket turun ke nol di minggu kedua, biasanya artinya pengguna sudah menyerah melaporkan masalah dan diam-diam menggunakan solusi sementara — bukan berarti sistem bekerja sempurna. Penulis menyebut ini sebagai 'kegagalan diam' dan menyarankan untuk secara proaktif menanyakan kepada champion departemen setiap minggu apakah tim mereka masih mengerjakan sesuatu di luar ERP, misalnya melalui Excel atau WhatsApp.

Apa itu audit solusi sementara bayangan dan kapan sebaiknya dilakukan?

Audit solusi sementara bayangan adalah tinjauan sistematis — disarankan pada hari ke-45 — di mana setiap champion departemen diwawancarai dan diminta menunjukkan cara timnya menyelesaikan setiap alur kerja inti. Setiap langkah yang melibatkan Excel, WhatsApp, email, atau alat non-ERP yang seharusnya digantikan ERP dicatat sebagai solusi sementara bayangan. Akar penyebabnya bisa berupa kesenjangan sistem, kesenjangan pelatihan, atau masalah UX, dan masing-masing memerlukan penanganan yang berbeda.

Kriteria apa yang menandai keberhasilan implementasi ERP di akhir periode 90 hari?

Keberhasilan dinyatakan ketika pengguna aktif harian melebihi 90% selama 30 hari berturut-turut, tingkat kesalahan transaksi di bawah 1%, solusi sementara bayangan sudah nol, penutupan periode keuangan pertama berhasil menggunakan data ERP, dan bisnis telah menghasilkan laporan ERP yang digunakan untuk keputusan bisnis nyata. Menurut artikel ini, implementasi yang dikelola dengan baik biasanya mencapai pencapaian ini di hari ke-60–90, sementara yang kurang terkelola bisa memakan waktu hingga hari ke-180–360.