Penyebab Implementasi ERP Gagal dan Cara Mengujinya Sebelum Kontrak

1. Kenapa Implementasi ERP Gagal Bukan Sekadar Soal Software

Ketika sebuah proyek ERP gagal, tuduhan pertama biasanya jatuh pada software: “sistemnya kurang cocok”, “fiturnya tidak lengkap”, atau “aplikasinya sulit dipakai”. Padahal bila dilihat lebih jujur, sebagian besar kegagalan tidak lahir dari lisensi yang dibeli, melainkan dari hal-hal di sekelilingnya: data yang belum rapi, proses yang belum disepakati, orang yang tidak siap berubah, dan lingkup pekerjaan yang meluas tanpa kendali.

ERP bukan sekadar pemasangan perangkat lunak. Ia adalah proyek perubahan cara kerja: sistem menuntut setiap transaksi dicatat dengan aturan yang sama oleh semua bagian. Software hanyalah alat; yang sesungguhnya berubah adalah kebiasaan orang di dalamnya. Karena itu pertanyaan “ERP mana yang terbaik” sering salah tempat. Pertanyaan yang lebih menentukan adalah “apakah perusahaan kami siap menjalankannya”.

Memahami pola kegagalan lebih dulu jauh lebih berguna daripada menghafal daftar fitur. Bagian berikut membahas penyebab yang paling sering muncul, lalu cara mengujinya sebelum kontrak ditandatangani — saat memperbaiki kesalahan masih murah.

2. Tanda-Tanda Awal Proyek Sedang Menuju Kegagalan

Kegagalan jarang datang tiba-tiba. Ia hampir selalu memberi tanda lebih dulu, dan tanda itu sering diabaikan karena dianggap bagian normal dari perjalanan proyek.

• Jadwal mundur terus-menerus tanpa sebab yang bisa dijelaskan dan tanpa perubahan lingkup yang disepakati.
• Uji coba ditunda berulang dengan alasan data belum siap — padahal data tidak akan pernah siap sempurna.
• Semua keputusan menunggu satu orang. Bila satu manajer atau direktur menjadi satu-satunya yang boleh memutuskan, proyek berhenti setiap kali ia sibuk.
• Permintaan kustomisasi bertambah tanpa ada yang mencatat dampaknya pada jadwal dan biaya.
• Tim internal dialokasikan sambil lalu: staf kunci tetap menangani pekerjaan harian penuh sambil ditambah tugas proyek.
• Pengguna akhir tidak dilibatkan sampai menjelang go-live.

Semakin banyak tanda yang muncul bersamaan, semakin besar kemungkinan masalahnya bukan pada software, melainkan pada cara proyek dijalankan.

3. Penyebab Pertama: Data Induk Tidak Disiapkan

Data induk (master data) adalah fondasi yang paling sering diremehkan. Kode produk, satuan, daftar pemasok, pelanggan, bagan akun, sampai struktur bill of materials harus diseragamkan sebelum masuk ke sistem baru.

Kesalahannya sederhana tetapi mahal: sistem baru diisi dengan data lama yang masih berantakan, sehingga ia langsung mewarisi seluruh kekacauannya. Dua kode untuk barang yang sama, satuan yang bercampur, atau daftar pelanggan yang duplikat akan membuat laporan otomatis apa pun menjadi salah sejak hari pertama. Prinsip lama dunia sistem informasi tetap yang paling relevan di sini: kualitas keluaran tidak pernah melebihi kualitas masukan.

Merapikan data hampir selalu memakan waktu lebih lama daripada perkiraan, dan pekerjaan ini tidak bisa diserahkan seluruhnya ke vendor — hanya tim internal yang benar-benar tahu barang mana yang sama. Untuk memahami mengapa konsistensi data menjadi inti nilai ERP, mulai dari penjelasan apa itu ERP.

4. Penyebab Kedua: Proses Bisnis Belum Disepakati

ERP memaksa satu cara kerja untuk seluruh perusahaan. Masalahnya, sebelum implementasi, tiap divisi sering punya caranya sendiri — dan masing-masing merasa caranya yang paling benar. Bagian penjualan menghitung potongan harga dengan asumsi berbeda dari bagian keuangan; gudang punya aturan sendiri soal barang rusak; pembelian menilai pemasok dengan ukuran yang tidak sama antar staf.

Selama perbedaan itu belum diputuskan, konfigurasi sistem tidak bisa diselesaikan. Vendor hanya dapat mengatur sistem mengikuti aturan yang jelas; ia tidak bisa menyelesaikan perbedaan pendapat antar departemen. Karena itu pekerjaan pertama sebelum menyentuh konfigurasi adalah menyepakati proses: siapa berwenang menyetujui apa, pada nilai berapa, dan dengan bukti apa. Keputusan seperti ini pekerjaan manajemen, bukan pekerjaan tim IT.

5. Penyebab Ketiga: Lingkup Melebar dan Kustomisasi Berlebihan

Hampir setiap proyek ERP menghadapi permintaan yang sama: “bisakah sistem ini sedikit diubah supaya persis seperti cara kami sekarang?” Permintaan itu wajar, tetapi bila diterima seluruhnya, hasilnya adalah sistem yang dijahit khusus untuk kebiasaan lama — dan justru kehilangan manfaat utamanya.

Dua akibat biasanya menyusul. Pertama, jadwal dan biaya membengkak: setiap kustomisasi menambah pekerjaan pengembangan, pengujian, dan pelatihan. Kedua, sistem menjadi sulit diperbarui, karena setiap pembaruan versi harus disatukan kembali dengan perubahan khusus tadi.

Pegangan yang lebih aman adalah mengikuti cara kerja standar sistem terlebih dahulu, lalu menyimpan kustomisasi hanya untuk hal yang benar-benar menjadi pembeda bisnis. Perbedaan kecil dalam kebiasaan administrasi hampir selalu lebih murah disesuaikan oleh manusia daripada diubah di dalam sistem.

6. Penyebab Keempat: Tim Internal dan Sponsor Tidak Siap

Proyek ERP yang tidak punya pemilik dari sisi bisnis hampir selalu tersendat. Bila hanya tim IT yang mengurusnya, keputusan proses yang seharusnya diambil manajemen tidak akan diambil, dan proyek berjalan tanpa arah yang jelas.

Tiga peran yang perlu benar-benar ada:

• Sponsor eksekutif yang berwenang memutuskan dan menyelesaikan perbedaan antar divisi.
• Pemilik proses di tiap bagian, yang bertanggung jawab atas kebenaran alur kerja masing-masing.
• Pengguna kunci (key user) yang akan menjadi tempat bertanya rekan-rekannya setelah sistem berjalan.

Selain itu, waktu staf kunci harus dialokasikan secara nyata. Proyek yang dijalankan sambil lalu oleh orang-orang tersibuk perusahaan biasanya berakhir dengan sistem yang terpasang tetapi tidak dipakai. Pelatihan juga bukan acara sekali jalan; pengguna baru akan terus muncul dan bertanya setelah go-live.

7. Penyebab Kelima: Menilai Vendor dari Presentasi, Bukan Bukti

Demonstrasi penjualan selalu terlihat rapi: data contoh bersih, alur mulus, dan hampir semua pertanyaan dijawab bisa. Masalahnya, demo tidak menunjukkan bagaimana sistem berperilaku dengan data perusahaan Anda yang sesungguhnya berantakan.

Beberapa hal yang lebih layak dinilai daripada kualitas presentasi:

• Siapa yang benar-benar mengerjakan. Tim yang tampil saat penawaran belum tentu tim yang akan mendampingi implementasi. Tanyakan langsung siapa personelnya.
• Rekam jejak di sektor yang sama. Masalah perusahaan manufaktur berbeda dari perusahaan tambang; pengalaman di industri sejenis lebih berharga daripada jumlah proyek secara umum.
• Dukungan setelah go-live. Yang paling menentukan kepuasan jangka panjang biasanya bukan pemasangan, melainkan respons ketika ada masalah setelah sistem berjalan.
• Referensi yang bisa dihubungi. Minta izin berbicara langsung dengan pelanggan yang sudah melewati implementasi.

Untuk gambaran bagaimana kebutuhan berbeda menurut industri, bandingkan pendekatan umum dengan contoh pada sektor tambang di artikel ERP untuk perusahaan tambang.

8. Cara Menguji Sebelum Kontrak Ditandatangani

Semua penyebab di atas bisa dideteksi lebih awal melalui pengujian dengan data nyata — bukan dengan melihat demo. Urutan uji berikut memakan waktu beberapa hari, tetapi jauh lebih murah daripada menemukan masalah setelah kontrak berjalan.

1. Jalankan satu proses tersulit dari awal sampai akhir. Pilih proses paling rumit di perusahaan Anda, lalu minta sistem kandidat menyelesaikannya memakai data perusahaan sendiri.
2. Minta sistem menghitung angka terpenting Anda secara otomatis. Misalnya harga pokok per unit, tanpa bantuan spreadsheet. Bila perhitungan itu masih manual, inti masalahnya belum tersentuh.
3. Uji laporan manajemen dan audit yang benar-benar Anda pakai. Bukan laporan contoh, melainkan laporan bulanan Anda. Periksa apakah bisa ditarik langsung dari sistem.
4. Libatkan pengguna harian, bukan hanya manajer. Minta staf yang akan memakai sistem setiap hari mencobanya sendiri, dengan skenario pekerjaan tercepat yang biasa mereka lakukan.
5. Minta rencana implementasi dengan tonggak dan kriteria penerimaan. Setiap tahap harus punya ukuran keberhasilan yang jelas, bukan sekadar tanggal selesai.
6. Tanyakan siapa yang mendampingi setelah serah terima. Ketahui sejak awal siapa yang dapat dihubungi ketika ada masalah, dan dengan jaminan waktu respons seperti apa.
7. Pastikan data tetap milik Anda. Periksa apakah data bisa diekspor keluar dari sistem kapan saja, tanpa terkunci pada satu vendor.

Uji dengan data satu minggu operasional nyata jauh lebih informatif daripada sepuluh presentasi.

9. Yang Harus Jelas di Kontrak dan Rencana Implementasi

Banyak perselisihan muncul bukan karena niat buruk, melainkan karena hal penting tidak pernah dituliskan. Sebelum menandatangani, pastikan beberapa hal ini terumuskan dengan jelas:

• Lingkup dan batasnya. Apa yang termasuk dan apa yang tidak termasuk, supaya tidak ada harapan yang berbeda di kedua pihak.
• Kriteria penerimaan per tahap. Kapan sebuah tahap dianggap selesai, dan diukur dengan apa.
• Tanggung jawab migrasi dan pembersihan data. Siapa mengerjakan apa, sebab bagian ini paling sering menimbulkan keterlambatan.
• Jadwal pelatihan dan siapa yang dilatih. Termasuk pelatihan untuk pengguna baru di kemudian hari.
• Dukungan pasca go-live. Cakupan, durasi, dan cara pelaporannya.
• Hak atas data dan cara keluar. Kemampuan mengekspor data dan melanjutkan operasi tanpa bergantung pada satu pihak.

Dokumen yang rapi menyelesaikan perbedaan sejak awal; kontrak yang kabur memindahkannya ke tengah proyek, ketika memperbaikinya jauh lebih mahal bagi semua pihak.

10. Kesimpulan

Implementasi ERP gagal bukan terutama karena software-nya salah pilih, melainkan karena hal di sekitarnya tidak disiapkan: data induk yang belum rapi, proses yang belum disepakati, lingkup yang meluas, orang yang tidak dilibatkan, dan vendor yang dinilai dari presentasi alih-alih bukti. Semua itu bisa dideteksi lebih awal melalui pengujian dengan data nyata dan pertanyaan yang tepat sebelum kontrak ditandatangani.

ERP tetap alat yang kuat: ia menyatukan keuangan, persediaan, penjualan, dan operasional dalam satu basis data, sehingga satu angka dipakai bersama oleh semua bagian. Namun ia hanya bekerja bila fondasinya siap. Ujian yang paling jujur tetap sama: ambil satu proses paling rumit, jalankan di sistem dengan data asli, lalu minta orang yang akan memakainya setiap hari memberi penilaian.

ImpactLabs mendampingi perusahaan sejak menilai kesiapan, memetakan proses, merapikan data, sampai serah terima sistem melalui layanan implementasi ERP.