Kegagalan Implementasi & Sumber Resmi
Mengapa implementasi ERP gagal di UMKM: 10 pola kegagalan, tanda awalnya, dan cara mencegahnya
Pola umum kegagalan proyek ERP di usaha kecil dan menengah, dari data kotor, cakupan membengkak, kustomisasi, sampai kontrak tanpa jalan keluar, lengkap dengan tanda bahaya dan langkah pencegahan.
Implementasi ERP di UMKM jarang gagal karena software tidak mampu menghitung. Kegagalan biasanya berasal dari keputusan dan kebiasaan di sekitar software: data awal yang tidak bersih, proses yang tidak disepakati, pemilik usaha yang tidak punya waktu, cakupan yang terus bertambah, kustomisasi yang menyulitkan pembaruan, atau kontrak yang tidak mengatur apa yang terjadi bila hasilnya tidak sesuai. Kabar baiknya, hampir semua pola ini bisa dikenali sejak awal dan dicegah dengan biaya yang jauh lebih kecil daripada memperbaikinya setelah go-live.
Panduan ini adalah pintu masuk kategori Kegagalan Implementasi & Sumber Resmi. Pola di bawah disusun dari pengalaman umum proyek software bisnis, bukan dari studi kasus perusahaan tertentu.
Sepuluh pola kegagalan
| Pola | Bagaimana terjadi | Tanda awal | Pencegahan |
|---|---|---|---|
| 1. Data kotor | Kode barang ganda, saldo tidak cocok, pelanggan tanpa identitas pajak | Migrasi uji diulang berkali-kali | Bersihkan data sebelum proyek, tetapkan pemilik data |
| 2. Proses tidak disepakati | Setiap bagian ingin cara lamanya dipertahankan | Rapat desain berakhir tanpa keputusan | Pemilik usaha memutuskan, catat di dokumen desain |
| 3. Tidak ada pemilik proyek | Proyek diserahkan ke vendor atau staf junior | Vendor menunggu jawaban berminggu-minggu | Tunjuk pemilik proyek dengan wewenang dan waktu |
| 4. Cakupan membengkak | Fitur "sekalian" terus ditambahkan | Daftar permintaan perubahan panjang | Bekukan cakupan tahap 1, tampung sisanya untuk tahap 2 |
| 5. Kustomisasi berlebihan | Sistem diubah agar sama dengan cara lama | Banyak laporan dan alur khusus | Ikuti fitur standar sejauh mungkin |
| 6. Pelatihan kurang | Hanya satu sesi sebelum go-live | Pengguna kembali ke spreadsheet | Pelatihan pengguna kunci, panduan tertulis, pelatihan ulang |
| 7. Paralel tanpa akhir | Sistem lama tidak pernah dimatikan | Input ganda berbulan-bulan | Tanggal henti sistem lama yang tegas |
| 8. Anggaran hanya untuk langganan | Implementasi dan biaya internal tidak dianggarkan | Proyek berhenti di tengah | TCO lengkap sebelum tanda tangan |
| 9. Kepatuhan diuji terlambat | Faktur pajak atau payroll baru dicek setelah go-live | Koreksi faktur di bulan pertama | Uji skenario pajak dan payroll di demo dan UAT |
| 10. Kontrak tanpa jalan keluar | Tidak ada hak ekspor data, perpanjangan otomatis | Sulit berhenti meski tidak puas | Pasal ekspor data, pemutusan, batas kenaikan |
Pola 1–3: dasar yang paling menentukan
Data kotor adalah penyebab penundaan yang paling umum. ERP yang menerima data berantakan menghasilkan laporan berantakan, dan pengguna berhenti memercayai sistem. Mulailah pembersihan sebelum kontrak ditandatangani; biaya dan caranya dibahas di biaya implementasi, migrasi data, dan pelatihan.
Proses yang tidak disepakati muncul saat bagian penjualan, gudang, dan keuangan punya kebiasaan berbeda untuk hal yang sama, misalnya kapan barang dianggap terkirim. ERP memaksa satu definisi. Keputusan seperti ini harus diambil pemilik usaha, bukan vendor.
Pemilik proyek yang tidak punya waktu atau wewenang membuat semua pola lain lebih buruk. Di UMKM, pemilik usaha sendiri sering perlu terlibat di setiap rapat keputusan.
Pola 4–7: selama proyek
Cakupan yang membengkak dan kustomisasi berlebihan saling terkait: setiap permintaan "kecil" menambah hari kerja dan risiko. Pembahasannya ada di kustomisasi dan integrasi berlebihan. Pelatihan yang kurang dan paralel tanpa akhir membuat penghematan tidak pernah terjadi; jadwal dan strategi go-live dibahas di durasi dan jadwal implementasi.
Pola 8–10: uang, aturan, dan kontrak
Anggaran yang hanya memuat langganan adalah penyebab proyek terhenti di tengah jalan. Daftar biaya yang sering terlupa ada di biaya tersembunyi ERP.
Kepatuhan yang diuji terlambat berbahaya karena dampaknya ke pihak lain: faktur pajak yang tidak disetujui DJP bukan faktur pajak, dan PPN-nya tidak dapat dikreditkan pembeli Anda. Uji integrasi Coretax dan payroll sebelum go-live.
Kontrak tanpa jalan keluar membuat Anda terikat pada sistem yang tidak berfungsi. Pasal yang perlu dibaca ada di kontrak SaaS ERP: SLA, pemutusan, dan perpanjangan dan ekspor data dan keluar dari vendor. Sebelum mematikan sistem lama, pastikan kewajiban arsip dan retensi 10 tahun sudah terpenuhi.
Contoh ilustratif: biaya keterlambatan
Proyek dengan biaya langganan Rp6.000.000 per bulan yang sudah ditagih sejak kontrak, konsultan Rp2.500.000 per hari, dan penghematan yang direncanakan Rp5.000.000 per bulan setelah go-live. Angka ilustratif.
Bila go-live mundur 3 bulan karena data kotor:
- Langganan tanpa manfaat: 3 × Rp6.000.000 = Rp18.000.000
- Tambahan 10 hari konsultan: 10 × Rp2.500.000 = Rp25.000.000
- Penghematan yang tertunda: 3 × Rp5.000.000 = Rp15.000.000
- Dampak total sekitar Rp58.000.000
Bandingkan dengan biaya staf sementara untuk membersihkan data selama satu bulan sebelum proyek. Pencegahan hampir selalu lebih murah.
Bila proyek sudah bermasalah
- Hentikan penambahan cakupan dan buat daftar masalah yang menghalangi go-live.
- Kelompokkan masalah: data, konfigurasi, pelatihan, atau fitur yang memang tidak ada.
- Rapat dengan vendor berdasarkan kontrak: tonggak mana yang belum dipenuhi dan oleh pihak mana.
- Putuskan: perbaiki dengan cakupan diperkecil, ganti mitra implementasi, atau keluar. Hitung biaya ketiga pilihan.
- Dokumentasikan semua komunikasi tertulis. Untuk sengketa bernilai besar, mintalah pendapat advokat.
Pertanyaan yang sering diajukan
Apakah kegagalan selalu kesalahan vendor?
Tidak. Banyak penyebab ada di sisi pembeli: data, keputusan, dan waktu staf. Kontrak yang baik membagi tanggung jawab dengan jelas.
Kapan sebaiknya mengganti mitra implementasi?
Bila masalah berulang di sisi konfigurasi atau pengetahuan konsultan, bukan data atau keputusan Anda, dan pembicaraan perbaikan tidak berhasil.
Bisakah kembali ke sistem lama?
Bisa, bila sistem lama dan datanya masih utuh. Itulah alasan untuk tidak menghapus sistem lama sebelum sistem baru stabil dan arsip selesai.
Apakah ada lembaga pengaduan untuk sengketa software B2B?
Sengketa antar pelaku usaha umumnya diselesaikan sesuai kontrak: musyawarah, mediasi, arbitrase, atau pengadilan. Lihat program pemerintah dan sumber resmi.
Sumber resmi
- Direktorat Jenderal Pajak — ketentuan faktur pajak yang harus diuji sebelum go-live
- Kementerian UMKM — pendampingan dan informasi untuk usaha kecil
- Kementerian Komunikasi dan Digital — penyelenggara sistem elektronik dan pelindungan data
