Mengapa ERP Mahal Anda Tidak Digunakan
Kebanyakan sistem ERP yang akhirnya tidak digunakan ditinggalkan karena alasan yang tidak ada hubungannya dengan perangkat lunak itu sendiri. Masalah muncul saat pelingkupan, desain, atau penerapan — dan saat sistem mulai beroperasi, kegagalan sudah terjadi.
Ini tidak abstrak. Sebelum mendirikan Result Marketing, Jared Loo menghabiskan tujuh digit dana untuk teknologi di Terasek, bisnis logistik kapal tanker air, dan operasi e-commerce. Sebagian dari pengeluaran tersebut masuk ke sistem yang tidak melekat. Perbedaan antara sistem yang memotong timnya sekitar 70% dan yang tidak bukanlah teknologinya — melainkan bagaimana masalahnya didefinisikan sebelum satu baris kode pun ditulis.
Enam Pola yang Memprediksi Pengabaian
1. Sistem Dibangun untuk Pemiliknya, Bukan Penggunanya
Pemilik menginginkan dasbor dan visibilitas. Seorang pekerja gudang menginginkan layar yang memberi tahu mereka apa yang harus dipilih tanpa memerlukan tiga klik menu. Ketika ERP dirancang untuk memuaskan orang yang membayarnya daripada orang yang menggunakannya, orang yang seharusnya memasukkan data mencari cara untuk tidak melakukannya.
2. Pelatihan Adalah Acara Satu Kali
Sesi pelatihan dua hari sebelum go-live tidaklah cukup. Staf lupa. Staf berbalik. Ketika sistem menjadi rumit dan pelatih tidak lagi tersedia, orang-orang kembali ke apa yang mereka ketahui — WhatsApp, Excel, dan kertas. Adopsi yang berkelanjutan memerlukan pelatihan yang tertanam dalam prosesnya, bukan disampaikan sebagai acara pra-peluncuran.
3. Sistem Menambahkan Langkah-Langkah Daripada Menghapusnya
Jika menggunakan ERP membutuhkan lebih banyak usaha daripada tidak menggunakannya, staf tidak akan menggunakannya. Ini terdengar jelas, tapi ini adalah kegagalan desain yang paling umum. Sistem yang mengharuskan pekerja gudang untuk login, menavigasi empat layar, dan memasukkan enam kolom untuk mencatat tanda terima barang — padahal sebelumnya mereka menulis tiga hal di clipboard — akan ditinggalkan. Sistem harus membuat pekerjaan lebih mudah. Jika itu membuat lebih sulit, maka akan diperjuangkan.
4. Data Tidak Pernah Dipercaya
Pada awal kehidupan sistem, jika data tidak akurat – angka stok salah, catatan pemasok hilang, pesanan tidak sesuai dengan apa yang sebenarnya dikirimkan – pengguna kehilangan kepercayaan. Ketika sebuah tim yakin bahwa sistem tersebut tidak dapat dipercaya, mereka berhenti menggunakannya sebagai sumber kebenaran dan menyimpan catatan paralel. Catatan paralel adalah kematian ERP.
5. Tidak Ada Seorangpun yang Bertanggung Jawab atas Adopsi
Proyek teknologi sering kali diserahkan saat go-live dan dianggap selesai. Namun go-live adalah saat pekerjaan sesungguhnya dimulai. Tanpa pemilik internal yang mempunyai tugas untuk mendorong adopsi, memantau penggunaan, dan menyelesaikan masalah dalam 90 hari pertama, sistem akan mengalami kegagalan.
6. Ruang Lingkup Ditentukan oleh Apa yang Dapat Dibangun TI, Bukan Operasi Apa yang Sebenarnya Dibutuhkan
Pengembang membangun apa yang diperintahkan kepada mereka. Jika arahan datang dari seorang manajer yang tidak menghabiskan waktu bersama pengguna sebenarnya, sistem akan memiliki fitur yang tidak dibutuhkan siapa pun dan kehilangan satu hal yang membuatnya dapat digunakan.
Seperti Apa Penyelamatan Itu
Tidak semua ERP yang tidak terpakai perlu diganti. Beberapa memerlukan desain ulang komponen yang menghadap pengguna. Beberapa memerlukan pembersihan data. Beberapa memerlukan pengisian celah khusus — aplikasi seluler untuk gudang, antarmuka yang lebih sederhana untuk satu peran, atau integrasi yang menghilangkan langkah manual yang membuat prosesnya sulit.
Layanan penyelamatan dan audit sistem ERP dimulai dengan menentukan apa yang salah sebelum merekomendasikan apa yang harus diubah. Sumber daya tentang mengapa proyek ERP gagal dan halaman masalah untuk sistem ERP yang tidak digunakan membahas pola diagnostik secara lebih detail.
Seperti Apa Keputusannya
| Situasi | Kemungkinan Jalan |
|---|---|
| Sistem sebagian besar benar; staf menghindari satu atau dua langkah yang menyakitkan | Perbaiki langkah-langkah tersebut; jangan membangun kembali |
| Data sangat rusak sehingga tidak dapat dipercaya | Pembersihan dan migrasi ulang sebelum melakukan hal lain |
| Logika alur kerja inti salah dalam cara bisnis sebenarnya beroperasi | Pembangunan kembali sebagian atau seluruh modul tersebut |
| Sistem dibangun untuk proses yang sudah tidak ada lagi | Keputusan strategis: beradaptasi atau mengganti |
Pertanyaan Umum
Apakah layak menyelamatkan ERP atau haruskah kita mulai lagi?
Itu tergantung pada apa yang sebenarnya salah. Sistem dengan arsitektur yang baik tetapi UX yang buruk patut diselamatkan. Sistem yang dibangun berdasarkan asumsi alur kerja yang salah mungkin memerlukan biaya perbaikan yang lebih besar daripada penggantian secara selektif. Audit sistem memberi Anda jawaban jujur berdasarkan bukti, bukan berdasarkan apa yang vendor ingin jual kepada Anda.
Bagaimana kita membuat staf benar-benar menggunakan sistem saat ini?
Libatkan mereka dalam desain. Bukan dalam keputusan teknis, tapi dalam keputusan alur kerja. Tanyakan di mana letak gesekannya, lalu perbaiki. Tunjukkan pada mereka prototipe sebelum membangun, bukan setelahnya. Sistem yang digunakan adalah sistem yang dirancang dengan mempertimbangkan pekerjaan sehari-hari pengguna.
Berapa lama sebelum Anda dapat mengetahui apakah suatu sistem akan diadopsi?
30 hari pertama setelah go-live adalah sinyal paling kritis. Jika penggunaan tidak berkembang dalam jangka waktu tersebut, jarang sekali akan pulih tanpa intervensi. Atasi titik-titik gesekan pada bulan pertama, bukan pada tinjauan tiga bulan.
Jika tim Anda sedang mengerjakan sistem yang Anda bayar untuk membangunnya, WhatsApp kami untuk penilaian yang jujur — kami akan memberi tahu Anda apa yang dapat diperbaiki dan apa yang tidak sebelum merekomendasikan apa pun.