ERP yang berhasil login dan mencetak invoice belum tentu menghasilkan ROI. Tiga bulan setelah go-live, manajemen perlu menjawab pertanyaan yang lebih keras: proses mana yang benar-benar lebih cepat, biaya apa yang turun, kontrol apa yang membaik, risiko apa yang justru muncul, dan modul mana yang belum dipakai sebagaimana dirancang.
Post-implementation review bukan audit untuk mencari siapa yang salah. Review ini adalah mekanisme pengambilan keputusan: fitur apa yang dihentikan, masalah apa yang harus segera diperbaiki, dan proses mana yang layak diperluas.
Gunakan ritme 30-60-90 hari
| Checkpoint | Fokus | Pertanyaan keputusan |
|---|---|---|
| Hari ke-30 | Stabilitas, akses, defect, dukungan, dan adopsi awal. | Apakah operasi inti dapat berjalan tanpa workaround berisiko? |
| Hari ke-60 | Kualitas master data, disiplin proses, integrasi, dan waktu siklus. | Apakah sistem baru memperbaiki alur atau hanya memindahkan pekerjaan manual? |
| Hari ke-90 | Manfaat terverifikasi, biaya total, kontrol, backlog, dan keputusan skala. | Apakah manfaat cukup kuat untuk melanjutkan investasi berikutnya? |
Jangan menunggu hari ke-90 untuk mencatat data. Ambil snapshot mingguan sejak go-live. Bila baseline sebelum implementasi belum dibuat, rekonstruksi sekarang dari laporan sistem lama, spreadsheet, dokumen transaksi, log insiden, data keuangan, dan sampling waktu kerja. Tandai jelas data aktual, estimasi, dan data yang belum tersedia.
Scorecard yang harus dibawa ke rapat direksi
Batasi scorecard utama menjadi 8 sampai 12 metrik. Terlalu banyak indikator membuat tim sibuk mengisi dashboard tetapi tidak mengambil keputusan.
| Dimensi | Contoh metrik | Sumber bukti | Pemilik |
|---|---|---|---|
| Adopsi | Persentase transaksi yang diselesaikan di ERP tanpa spreadsheet bayangan. | Log ERP, sampling dokumen, dan wawancara pengguna. | Process owner |
| Kecepatan | Median waktu order-to-invoice atau procure-to-pay. | Timestamp transaksi sebelum dan sesudah go-live. | Operasional |
| Kualitas | Persentase transaksi yang dikoreksi, dibatalkan, atau dikerjakan ulang. | Audit log, credit note, retur, dan tiket. | Quality owner |
| Data | Duplikasi customer, SKU tanpa atribut wajib, dan saldo tidak cocok. | Data quality report dan rekonsiliasi. | Data owner |
| Keuangan | Hari tutup buku, DSO, nilai stok, dan biaya proses per transaksi. | General ledger dan laporan manajemen. | Finance |
| Kontrol | Konflik akses, transaksi tanpa approval, dan perubahan master tanpa bukti. | Role matrix, approval log, dan audit trail. | Risk/control owner |
| Stabilitas | Insiden kritis, downtime, waktu pemulihan, dan backlog defect. | Monitoring dan service desk. | IT owner |
| Pengguna | Task completion rate dan pola kebutuhan bantuan. | Observasi tugas, survei singkat, dan tiket. | Change lead |
Untuk setiap metrik, tampilkan baseline, target, angka saat ini, arah tren, sumber data, tingkat keyakinan, dan tindakan. “Lebih efisien” bukan metrik. “Median waktu membuat invoice turun dari 18 menit menjadi 9 menit berdasarkan 120 transaksi” adalah bukti yang dapat diperiksa.
Pisahkan aktivitas, output, dan hasil bisnis
Jumlah login, peserta training, atau transaksi yang dibuat adalah aktivitas. Invoice terbit lebih cepat dan stok lebih akurat adalah output proses. Penurunan biaya rework, membaiknya arus kas, atau turunnya modal kerja adalah hasil bisnis. Jangan mengklaim ROI hanya dari aktivitas.
- Aktivitas: 80 pengguna login minggu ini.
- Output: 92% purchase order dibuat melalui alur approval ERP.
- Hasil: waktu tunggu approval turun dan pembelian di luar kontrak berkurang.
Hubungan sebab-akibat juga perlu diuji. Penjualan dapat naik karena musim atau kampanye, bukan ERP. Nilai persediaan dapat turun karena permintaan melemah, bukan perencanaan yang membaik. Gunakan periode pembanding yang setara dan catat faktor lain yang memengaruhi hasil.
Rumus ROI yang dapat dipertanggungjawabkan
Gunakan rumus dasar berikut:
ROI = (manfaat finansial terverifikasi − total biaya ERP) ÷ total biaya ERP × 100%
Total biaya tidak hanya invoice vendor. Masukkan lisensi atau subscription, implementasi, infrastruktur, integrasi, migrasi dan pembersihan data, jam kerja internal, training, support, perangkat, keamanan, downtime, serta biaya mempertahankan sistem lama selama masa transisi.
Manfaat finansial juga harus konservatif. Kelompokkan ke dalam:
- jam kerja yang benar-benar dialihkan ke pekerjaan bernilai, bukan sekadar waktu yang terasa lebih singkat;
- rework, retur, penalti, dan koreksi yang berkurang;
- biaya aplikasi lama yang benar-benar dihentikan;
- modal kerja dari perbaikan persediaan atau penagihan;
- margin tambahan yang dapat dikaitkan dengan kapasitas atau keputusan yang dibantu ERP.
Contoh perhitungan hipotesis
Sebuah distributor mencatat total biaya ERP tahun pertama Rp480 juta. Setelah tiga bulan, tim memverifikasi penghematan berulang Rp18 juta per bulan dari pengurangan rework dan penghentian dua aplikasi lama. Ada pula manfaat satu kali Rp30 juta dari koreksi stok. Jika penghematan bulanan diproyeksikan selama 12 bulan, manfaat tahun pertama menjadi Rp246 juta.
ROI tahun pertama dalam simulasi ini adalah (Rp246 juta − Rp480 juta) ÷ Rp480 juta, atau negatif 48,75%. Ini tidak otomatis berarti proyek gagal. Investasi awal sering terbebani biaya implementasi satu kali, sedangkan manfaat berulang muncul bertahap. Direksi perlu melihat payback period dan skenario tahun kedua, sekaligus memeriksa apakah asumsi Rp18 juta per bulan benar-benar bertahan. Contoh ini sengaja menunjukkan bahwa review yang jujur tidak selalu menghasilkan angka positif.
Temukan spreadsheet bayangan dan double entry
Masalah adopsi sering tersembunyi. Pengguna melakukan transaksi di ERP untuk memenuhi prosedur, tetapi keputusan sebenarnya tetap memakai spreadsheet pribadi. Cari file rekap yang masih beredar, data yang diketik ulang, approval melalui chat tanpa jejak, dan laporan yang dibuat manual karena master data belum dipercaya.
Untuk setiap workaround, catat alasan: fitur kurang, konfigurasi salah, hak akses, performa, kualitas data, training, atau proses bisnis belum disepakati. Memaksa pengguna berhenti memakai spreadsheet sebelum akar penyebab selesai dapat memindahkan risiko ke pekerjaan yang tidak terlihat.
Audit kualitas data dan rekonsiliasi
Pilih objek data kritis seperti customer, vendor, SKU, chart of accounts, harga, satuan, pajak, lokasi stok, dan saldo awal. Ukur kelengkapan, validitas, keunikan, konsistensi, ketepatan waktu, dan kepemilikan data.
- Rekonsiliasi subledger dengan general ledger.
- Bandingkan stok sistem dengan cycle count fisik.
- Cari customer atau vendor duplikat dan transaksi pada master nonaktif.
- Uji transaksi lintas modul dari sumber hingga jurnal.
- Periksa siapa yang boleh membuat dan menyetujui perubahan master.
Jangan memperbaiki data hanya dengan proyek bersih-bersih satu kali. Tetapkan data owner, aturan validasi, daftar atribut wajib, proses koreksi, dan indikator kualitas bulanan.
Periksa kontrol, keamanan, dan kemampuan pulih
Review ERP harus mencakup risiko, bukan hanya produktivitas. Uji role dan permission berdasarkan pekerjaan aktual, bukan jabatan umum. Cari konflik seperti pengguna yang dapat membuat vendor sekaligus membayar, membuat purchase order sekaligus menyetujui, atau mengubah harga dan mengeksekusi penjualan tanpa kontrol tambahan.
Periksa akun bersama, akun mantan karyawan, MFA untuk akses sensitif, log perubahan, patch, integrasi, backup, dan prosedur restore. Bukti backup belum cukup; lakukan uji pemulihan terbatas dan catat waktu serta data yang berhasil dipulihkan. Untuk proses penting, tetapkan prosedur manual sementara ketika ERP atau koneksi tidak tersedia.
Bedakan defect, change request, dan masalah proses
| Kategori | Definisi kerja | Contoh keputusan |
|---|---|---|
| Defect | Sistem tidak bekerja sesuai desain atau acceptance criteria. | Perbaiki berdasarkan severity dan dampak operasional. |
| Change request | Kebutuhan baru atau desain yang sebelumnya tidak disepakati. | Nilai manfaat, biaya, dependensi, dan prioritas. |
| Data issue | Masalah pada migrasi, master, aturan, atau ownership data. | Perbaiki data sekaligus kontrol pencegahannya. |
| Process issue | Alur kerja atau tanggung jawab belum jelas. | Selesaikan keputusan proses sebelum menambah fitur. |
| Training issue | Pengguna belum mampu menjalankan tugas yang sudah didukung sistem. | Latihan berbasis tugas dan ukur completion rate. |
Backlog yang tidak diklasifikasi akan berubah menjadi daftar permintaan tanpa batas. Setiap item perlu memiliki dampak, bukti, akar penyebab, owner, estimasi, dependensi, dan indikator selesai.
Agenda rapat keputusan 90 hari
- Tinjau 8–12 metrik utama dan kualitas buktinya.
- Pilih lima masalah dengan dampak terbesar terhadap uang, pelanggan, operasi, atau risiko.
- Putuskan stop, fix, atau scale untuk setiap modul dan integrasi.
- Setujui owner, anggaran, tenggat, dan ukuran keberhasilan.
- Bekukan permintaan bernilai rendah sampai masalah fondasi selesai.
- Jadwalkan review berikutnya dan tetapkan data yang harus dikumpulkan.
Morabangun dapat memfasilitasi review lintas fungsi, membantu menyiapkan scorecard, memetakan proses, memeriksa backlog, dan menerjemahkan temuan menjadi sprint perbaikan. Keputusan ROI tetap harus memakai data keuangan serta bukti operasional milik perusahaan, bukan angka benchmark generik.
Langkah awal: siapkan business case awal, daftar biaya, baseline proses, akses laporan ERP, daftar insiden, role matrix, dan lima keluhan pengguna yang paling sering muncul. Dari data itu, tim dapat menentukan apakah masalah utama berada pada sistem, data, proses, atau adopsi.
