Ruang rapat penuh sesak. Direktur berdiri di depan layar yang menampilkan antarmuka modul baru, bersih dan modern. Vendor menyalami semua orang. Fotografer mengabadikan momen. Ada kue tart bertuliskan “Go-Live Sukses!” di sudut meja.

Enam bulan kemudian, laporan bulanan di organisasi yang sama masih disusun di Excel. Sistem ERP memang aktif, tetapi dipakai terutama untuk laporan ke atasan. Kerja sehari-hari tetap berjalan di luar sistem.

Itulah monumen digital: sistem yang berdiri kokoh, berbiaya miliaran, tapi tidak mengubah satu pun kebiasaan kerja orang di dalamnya. Proyek Enterprise Resource Planning atau ERP (Sistem Perencanaan Sumber Daya Perusahaan) itu selesai di atas kertas. Tapi tidak berhasil di lapangan.

Selesai Bukan Berhasil

Kita sudah terlalu lama menggunakan kata “selesai” sebagai pengganti “berhasil.”

Selesai artinya: sistem terpasang, data dipindahkan, pelatihan tiga hari dilakukan, dokumen serah terima ditandatangani. Go-live dirayakan. Anggaran ditutup. Vendor pulang.

Berhasil artinya berbeda. Perilaku kerja berubah. Data yang masuk ke sistem akurat dan konsisten. Keputusan operasional benar-benar diambil berdasarkan informasi dari sistem. Dan kondisi itu bertahan enam bulan kemudian. Setahun kemudian.

Masalahnya: hampir semua proyek ERP di Indonesia diukur dengan definisi pertama, bukan definisi kedua.

Standish Group, lembaga riset manajemen proyek yang menganalisis puluhan ribu proyek IT sejak 1994, melaporkan bahwa hanya sekitar sepertiga proyek IT besar yang berhasil sesuai target waktu, anggaran, dan fungsionalitas. McKinsey dalam kajian digital transformation mereka mencatat sekitar 70% program tersebut tidak mencapai tujuan yang ditetapkan di awal.

Angka-angka itu mungkin terasa jauh dan abstrak. Coba tanya yang lebih dekat: berapa persen data yang masuk ke sistem ERP organisasi Anda benar-benar dipakai untuk mengambil keputusan, dan bukan sekadar untuk memenuhi kewajiban pelaporan?

Banyak yang tidak tahu jawabannya. Itu sendiri sudah informatif.

Tiga Mekanisme yang Membunuh Proyek ERP

Kegagalan ini bukan kebetulan dan bukan nasib buruk. Ada tiga mekanisme struktural yang bekerja hampir di setiap organisasi, dan ketiganya bisa diprediksi jauh sebelum go-live.

1. Go-Live Dirayakan sebagai Garis Akhir

Di hampir setiap proyek ERP, ada satu momen yang disebut go-live: hari ketika sistem resmi diaktifkan. Momen itu dirayakan karena memang ada sesuatu yang dicapai, integrasi teknis berhasil, data awal sudah ada, akun pengguna sudah dibuat.

Tapi go-live bukan garis akhir. Itu garis awal dari pekerjaan yang sebenarnya.

Begitu go-live dirayakan, tekanan mulai memudar. Sponsor proyek merasa tugasnya selesai. Tim implementasi vendor bergerak ke proyek berikutnya. Anggaran post-implementation jauh lebih kecil dari anggaran implementasi. Perhatian manajemen beralih ke prioritas lain.

Yang tersisa adalah pengguna yang dibiarkan menghadapi sistem baru sendirian, dengan kebiasaan lama yang masih jauh lebih cepat dan familiar.

Ada ironi yang menyakitkan di sini: justru saat sistem paling membutuhkan dukungan ekstra, saat pengguna masih bingung dan lambat, itulah saat dukungan paling tipis.

2. Gap Implementasi dan Adopsi

Ada perbedaan besar antara implementasi dan adopsi, dan kebanyakan proyek ERP hanya membayar untuk yang pertama.

Implementasi adalah urusan teknis: sistem terpasang, berjalan, terintegrasi. Ini bisa diukur dengan jelas, ada kriteria penerimaan yang tertulis di kontrak, dan vendor bertanggung jawab penuh.

Adopsi adalah urusan manusia: orang mengubah cara kerjanya, mempercayai data di sistem, berhenti melakukan workaround (jalan pintas di luar sistem), dan membangun kebiasaan baru. Ini jauh lebih sulit diukur, tidak ada di kontrak vendor, dan tidak ada yang merasa bertanggung jawab penuh.

Akibatnya, ada zona abu-abu yang tidak dimiliki oleh siapa pun. Vendor sudah selesai tugas teknisnya. Tim IT internal fokus pada stabilitas teknis. Pengguna dibiarkan beradaptasi sendiri. Di zona abu-abu itulah sebagian besar proyek ERP perlahan mati.

Tanda-tandanya mudah dikenali: ada dua sistem yang berjalan paralel, satu yang “resmi” dan satu yang “nyata.” Rekon manual antara laporan dari ERP dan catatan di luar sistem. Super user yang semakin jarang ditanya karena tidak ada yang percaya datanya akurat. Dan perlahan, sistem ERP berubah fungsi dari alat kerja menjadi alat pelaporan.

Itu bukan sukses. Itu keberlanjutan yang mahal.

3. Resistansi yang Tidak Dipahami

“Orang susah berubah” adalah penjelasan paling malas yang sering dipakai. Seolah resistansi adalah cacat karakter, bukan respons rasional terhadap situasi nyata.

Bayangkan posisi seorang staf pengadaan yang sudah bekerja delapan tahun. Cara kerjanya sekarang: buka WhatsApp, minta persetujuan, foto dokumen, kirim. Lima menit selesai. Cara kerja baru dengan sistem ERP: login, isi 12 kolom formulir, tunggu notifikasi persetujuan digital, upload dokumen sesuai format yang sudah ditentukan, tunggu lagi. Tiga puluh menit untuk hasil yang sama.

Di bulan pertama, cara baru itu lebih lambat. Jauh lebih lambat. Atasan masih menuntut kecepatan yang sama. Dan tidak ada yang menghargai kesabaran ekstra yang dikeluarkan staf itu setiap hari.

Resistansi itu bukan kemalasan. Itu kalkulasi efisiensi yang sangat rasional.

Phillippa Lally dan tim dari University College London melalui penelitian yang diterbitkan di European Journal of Social Psychology tahun 2010 menemukan bahwa rata-rata pembentukan kebiasaan baru membutuhkan 66 hari, bukan 21 hari seperti yang sering dikutip. Sementara program hypercare (pendampingan pasca go-live) yang umum di proyek ERP berlangsung 30 hari, lalu selesai.

Kebiasaan belum terbentuk. Pendampingan sudah pergi.

Sanggahan yang Sering Muncul

Vendor dan konsultan implementasi biasanya punya jawaban untuk semua ini: sudah ada change management, sudah ada pelatihan, ada super user di setiap divisi, ada hypercare satu bulan.

Niat baiknya tidak diragukan. Yang perlu dipertanyakan adalah definisi operasionalnya.

Change management yang dimaksud biasanya adalah: sosialisasi sistem baru, pelatihan cara klik tombol, dan pembuatan SOP baru yang belum tentu pernah dibaca siapa pun setelah dicetak. Itu bukan change management dalam pengertian yang digunakan Prosci dalam kerangka ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement): membangun kesadaran mengapa perubahan perlu, menciptakan keinginan untuk berubah, membangun kemampuan teknis, dan yang paling sering dilewati, memperkuat perubahan secara konsisten sampai menjadi norma baru.

Pelatihan yang mengajarkan cara klik tombol tidak mengganti model mental lama. Dan model mental lama akan selalu menang kalau tidak ada tekanan sistematis dan berkelanjutan untuk membangunnya kembali.

Ada satu pertanyaan sederhana yang bisa diajukan ke konsultan setelah go-live tiga bulan: berapa persen transaksi pengadaan yang diproses dalam sistem tanpa bypass? Jika jawabannya tidak diketahui, atau di bawah 80%, proyek itu belum berhasil. Apa pun yang tertulis di dokumen serah terima.

Wajah Monumen Digital di Indonesia

Cerita berikut adalah komposit anonim dari pola yang muncul di beberapa organisasi. Identitas disamarkan.

Sebuah PDAM kota sedang di Jawa mengimplementasikan sistem ERP senilai Rp 4,2 miliar pada 2022. Tujuannya jelas: integrasi data pelanggan, penagihan, dan pengadaan dalam satu platform. Proyek berjalan 14 bulan. Go-live dirayakan dengan seremoni sederhana. Direktur memotong tumpeng.

Dua tahun kemudian, laporan bulanan untuk Direksi masih dibuat manual di Excel. Alasannya klasik: format keluaran sistem tidak cocok dengan format yang diminta manajemen. Permintaan penyesuaian sudah diajukan berulang kali ke vendor, tapi selalu dijawab dengan kalimat yang sama: di luar lingkup kontrak.

Di divisi pengadaan, polanya berbeda tapi kesimpulannya sama. Data dimasukkan ke sistem ERP setelah transaksi selesai, bukan saat transaksi berlangsung. Sistem akurat secara historis, tapi tidak real-time. Untuk mengetahui stok gudang hari ini, cara tercepat masih telepon kepala gudang langsung.

Sistem itu tidak gagal secara teknis. Ia berjalan, stabil, dan diperbarui rutin oleh tim IT. Yang gagal adalah fungsinya sebagai alat pengambilan keputusan. Ia berhasil menjadi tempat perekaman data historis, bukan sistem yang mengubah cara orang bekerja.

Empat koma dua miliar rupiah. Tiga tahun kemudian masih pakai telepon untuk cek stok.

Ini bukan cerita tentang vendor yang buruk atau tim IT yang tidak kompeten. Ini cerita tentang proyek yang tidak pernah mendefinisikan apa artinya berhasil di luar go-live.

Yang Berbeda pada Organisasi yang Berhasil

Di beberapa organisasi yang ERP-nya benar-benar dipakai, ada satu perbedaan paling konsisten dibanding yang menjadi monumen digital: cara mereka mendefinisikan “berhasil” di hari pertama proyek dimulai.

Sebagai contoh komposit, sebuah BUMD layanan air minum di Jawa tidak menutup proyek saat go-live. Tim proyek tetap bertahan sampai 90% transaksi pengadaan diproses di sistem tanpa bypass selama tiga bulan berturut-turut, dan data pelanggan yang dipakai di rapat operasional konsisten sama dengan data di sistem. Baru setelah angka itu stabil, proyek dinyatakan selesai. Hasilnya bukan sekadar sistem hidup, tetapi kebiasaan kerja baru yang benar-benar dipakai.

Organisasi yang berhasil tidak merayakan go-live sebagai titik akhir. Mereka merayakan angka adopsi yang bertahan.

Bukan “sistem sudah hidup.” Tapi: 85% transaksi pembelian diproses dalam sistem tanpa bypass selama tiga bulan berturut-turut. Bukan “data sudah dipindahkan.” Tapi: akurasi data induk di atas 90%, diverifikasi oleh tim operasional, bukan oleh tim IT.

Dengan ukuran seperti itu, proyek tidak bisa ditutup saat go-live. Proyek baru selesai ketika angka itu tercapai dan bertahan. Vendor masih punya kewajiban kontraktual. Sponsor masih punya tanggung jawab yang belum tuntas.

Konsekuensinya jauh lebih dalam dari sekadar tolok ukur kinerja (KPI). Ketika “berhasil” didefinisikan sebagai perubahan perilaku, seluruh desain proyek berubah: training dirancang berbeda, jangka waktu pasca-go-live lebih panjang, ada mekanisme pemantauan adopsi yang nyata, dan ada eskalasi yang jelas ketika angka tidak bergerak.

flowchart TD
    A["Proyek ERP Dimulai"] --> B["Implementasi Teknis"]
    B --> C["Go-Live"]
    C --> D{"Definisi Berhasil?"}
    D -->|Lama: go-live = selesai| E["Proyek Ditutup\nVendor Pulang\nAnggaran Ditutup"]
    E --> F["Pengguna Ditinggal\nKebiasaan Lama Menang"]
    F --> G["Monumen Digital"]
    D -->|Baru: adopsi = berhasil| H["Fase Adopsi Dimulai\nTarget Perilaku Ditetapkan"]
    H --> I{"Angka Adopsi\nTercapai dan Bertahan?"}
    I -->|Belum| J["Pendampingan Dilanjutkan\nBarrier Diidentifikasi\nEskalasi ke Sponsor"]
    J --> I
    I -->|Ya, 3 bulan berturut-turut| K["Proyek Benar-benar Selesai"]

Gambar 1. Dua jalur proyek ERP: jalur kiri menghasilkan monumen digital karena go-live diperlakukan sebagai garis akhir, jalur kanan mengukur perubahan perilaku nyata sebagai kriteria keberhasilan.

Satu Langkah yang Bisa Dimulai Minggu Depan

Ini bukan soal menulis ulang seluruh kontrak dengan vendor atau mengubah metodologi proyek secara menyeluruh. Satu langkah yang konkret, bisa dilakukan sebelum proyek ERP berikutnya ditandatangani, dan tidak membutuhkan anggaran tambahan.

Sebelum menandatangani kontrak implementasi, organisasi menetapkan satu kalimat: “Definisi Berhasil” yang bukan go-live.

Contohnya: “Proyek ini dinyatakan berhasil jika 90% transaksi pengadaan diproses dalam sistem tanpa bypass selama tiga bulan berturut-turut, diverifikasi oleh Kepala Bagian Pengadaan, paling lambat 12 bulan sejak go-live.”

Kalimat itu masuk ke dokumen piagam proyek. Menjadi tolok ukur sponsor proyek. Dibacakan pada rapat awal proyek. Proyek tidak ditutup sebelum angka itu tercapai.

Sesederhana itu. Dan hampir tidak ada yang melakukannya.

Kenapa tidak dilakukan? Karena kalimat itu mengancam semua pihak: vendor tidak bisa kabur setelah go-live, sponsor tidak bisa pindah ke proyek berikutnya terlalu cepat, dan tim IT tidak bisa berargumen bahwa tugas mereka selesai saat sistem menyala.

Monumen digital tidak dibangun karena orang bodoh atau lalai. Dibangun karena tidak ada yang bertanya pertanyaan yang tepat di awal: berhasil itu seperti apa, terukur bagaimana, dan siapa yang bertanggung jawab memastikannya terjadi?

Tanyakan pertanyaan itu sebelum rapat pertama dengan vendor. Tuliskan jawabannya. Pastikan semua pihak menandatanganinya.

Itu satu-satunya cara memastikan foto go-live itu bukan foto peresmian monumen.

Artikel ini adalah bagian dari seri tentang transformasi digital dan manajemen organisasi. Dinamika yang sama, kesenjangan antara implementasi teknis dan adopsi perilaku, berlaku di banyak konteks lain: sistem manajemen aset, sistem manajemen pelanggan, bahkan sistem akuntansi yang paling sederhana sekalipun.

Referensi & Bacaan Lanjutan

  1. Standish Group Chaos Report: Ringkasan InfoQ Hastie, S. & Wojewoda, S. (2015). “Standish Group 2015 Chaos Report Q&A.” Pembahasan temuan laporan CHAOS 2015: hanya 29% proyek IT berjalan sesuai waktu, anggaran, dan fitur. Baca ringkasan di InfoQ

  2. Kegagalan Transformasi Digital McKinsey & Company (2018). “Unlocking success in digital transformations.” Kajian 1.521 eksekutif tentang mengapa 70% program transformasi digital gagal mencapai tujuannya. Baca di McKinsey.com

  3. Pembentukan Kebiasaan Baru Lally, P., van Jaarsveld, C. H. M., Potts, H. W. W., & Wardle, J. (2010). “How are habits formed: Modelling habit formation in the real world.” European Journal of Social Psychology, 40(6), 998-1009. Penelitian yang menemukan rata-rata pembentukan kebiasaan membutuhkan 66 hari, bukan 21 hari. Baca via DOI (tautan permanen)

  4. Kerangka ADKAR untuk Manajemen Perubahan Prosci Inc. “ADKAR: A Model for Change in Business, Government and our Community.” Kerangka manajemen perubahan berbasis individu: Awareness, Desire, Knowledge, Ability, Reinforcement. Pelajari kerangka ADKAR

  5. Tata Kelola Proyek TI Pemerintah Indonesia Badan Pengawasan Keuangan dan Pembangunan (BPKP). Pedoman dan hasil audit tata kelola proyek teknologi informasi instansi pemerintah Indonesia. Portal resmi BPKP

  6. Mengapa Adopsi ERP Sering Gagal Panorama Consulting Group. “ERP Report.” Survei tahunan tentang implementasi ERP: tingkat adopsi, waktu realisasi manfaat, dan faktor kegagalan. Laporan diperbarui setiap tahun; tautan mengarah ke edisi terkini (diakses Mei 2026). Baca laporan ERP terkini

Disclaimer: Tulisan ini adalah pandangan pribadi penulis sebagai praktisi profesional dan tidak mewakili sikap atau kebijakan resmi dari institusi/perusahaan tempat penulis bekerja. Studi kasus yang disebutkan adalah komposit anonim berdasarkan pola umum yang diamati dari berbagai sumber publik. Untuk keputusan strategis terkait investasi sistem, konsultasikan dengan tim internal dan penasihat yang memahami konteks spesifik organisasi Anda.