Kenapa software perusahaan tidak dipakai karyawan: 6 penyebab dan cara mencegahnya

Polanya mirip di banyak perusahaan. Software baru dibeli, tim dilatih, lalu dua bulan kemudian rekap harian kembali lewat spreadsheet dan foto di WhatsApp. Sistemnya tetap menyala, tapi datanya bolong. Uangnya tidak hilang dalam satu hari. Ia menguap pelan-pelan, setiap kali ada orang yang memilih cara lama.

Kalau software perusahaan tidak dipakai karyawan, penyebabnya hampir tidak pernah teknis. Di bawah ini enam penyebab yang paling sering kami temui, apa tandanya, dan apa yang bisa dicegah sejak tahap desain.

Tanda-tanda sistem mulai ditinggal

Sebelum membahas penyebab, pastikan dulu masalahnya memang ini. Beberapa tanda yang mudah dicek tanpa alat khusus:

• Ada spreadsheet "pendamping" yang dipakai di samping sistem, dan semua orang tahu letaknya.
• Laporan di sistem baru masuk menjelang tutup bulan, bukan setiap hari.
• Pertanyaan "angka yang benar yang mana?" muncul di rapat.
• Satu atau dua orang ditugasi memindahkan data dari kertas atau chat ke sistem.

Kalau dua atau lebih tanda di atas terjadi, sistem Anda sedang ditinggal. Kabar baiknya, sebagian besar penyebabnya bisa diperbaiki.

Dirancang dari ruang rapat, bukan dari lantai kerja

Kebutuhan biasanya dikumpulkan lewat rapat dengan manajer. Masalahnya, manajer jarang mengisi data. Yang mengisi adalah admin gudang, operator shift, atau sales di lapangan, dan kondisi kerja mereka tidak terlihat dari ruang rapat.

Cara mencegahnya sederhana tapi jarang dilakukan: amati satu hari kerja penuh sebelum menggambar layar pertama. Catat setiap kali orang menulis di kertas, mengetik ulang, atau mengirim foto. Setiap catatan itu adalah langkah yang seharusnya hilang di sistem baru.

Menambah langkah, bukan mengurangi

Sistem baru sering meminta data yang dulu tidak pernah diminta: kode barang, kategori, alasan, persetujuan. Bagi manajemen itu data yang berguna. Bagi orang yang mengisi, itu pekerjaan tambahan yang tidak ada imbalannya.

Ujinya sederhana. Hitung jumlah ketukan atau isian untuk satu tugas harian, di cara lama dan di sistem baru. Kalau cara baru lebih panjang, orang akan kembali ke cara lama, sebagus apa pun pelatihannya.

Kalau sistem baru lebih lambat dari kertas untuk orang yang mengisinya, kertas yang menang.

Layar dibuat untuk manajer, diisi oleh operator

Dashboard untuk direksi dan formulir untuk operator adalah dua produk yang berbeda. Ketika keduanya dipaksa berbagi layar, hasilnya formulir yang penuh kolom dan dashboard yang datanya tidak lengkap.

• Operator butuh satu tugas per layar, tombol besar, dan tanda yang jelas bahwa data sudah tersimpan.
• Supervisor butuh daftar hal yang perlu diurus sekarang, bukan grafik.
• Pemilik butuh angka yang bisa dipercaya. Itu hanya terjadi kalau dua kelompok pertama benar-benar mengisi.

Tidak jalan di kondisi nyata

Aplikasi yang lancar di laptop kantor bisa gagal total di gudang. Sinyal hilang di area rak, layar tidak terbaca di bawah matahari, tombol terlalu kecil untuk tangan bersarung, atau ponsel karyawan jauh lebih lambat dari ponsel tim IT.

Minta tim desain menguji prototipe di lokasi dan perangkat yang sebenarnya. Untuk masalah sinyal, pastikan data tersimpan dulu di perangkat dan baru dikirim saat jaringan kembali.

Data lama tidak ikut pindah

Ketika riwayat pelanggan, stok awal, atau daftar harga tidak dipindahkan dengan rapi, orang tetap membuka file lama untuk mencari jawaban. Sekali mereka membuka file lama, mereka cenderung tetap bekerja di sana.

Migrasi data adalah bagian dari desain, bukan pekerjaan sisa di minggu terakhir. Tentukan sejak awal data apa yang harus sudah ada di hari pertama sistem dipakai.

Tidak ada yang menjaga setelah rilis

Minggu pertama setelah go-live selalu memunculkan masalah yang tidak terlihat saat uji coba. Kalau tidak ada yang cepat memperbaikinya, karyawan belajar satu hal: sistem ini tidak bisa diandalkan. Kepercayaan itu lebih sulit dibangun ulang daripada kodenya.

Sebelum menandatangani kontrak, tanyakan siapa yang menjawab laporan masalah di bulan pertama, berapa lama waktu jawabnya, dan apakah itu tertulis. Kalau Anda masih menimbang antara membeli aplikasi jadi atau membangun sendiri, panduan custom software vs SaaS membahas pertanyaan yang sama dari sisi biaya.

Kalau sistemnya sudah terlanjur ditinggal

Membangun ulang dari nol jarang jadi langkah pertama yang tepat. Mulai dari mengamati di mana orang keluar dari sistem. Biasanya ada satu alur yang paling sering dipakai dan paling sering dihindari, misalnya laporan harian atau permintaan barang. Perbaiki alur itu dulu, ukur apakah datanya kembali masuk, lalu lanjut ke alur berikutnya.

Pola yang sama terjadi pada alat AI di kantor. Kalau aturannya merepotkan, karyawan mencari jalan pintas sendiri. Kami membahasnya di panduan kebijakan AI perusahaan.

Cara mengecek sebelum membangun

• Sudah ada yang mengamati satu hari kerja penuh di lokasi, bukan hanya rapat kebutuhan.
• Jumlah langkah untuk tugas harian utama sudah dihitung, dan cara baru lebih pendek.
• Prototipe sudah dicoba oleh 5 calon pengguna di perangkat mereka sendiri.
• Data yang harus ada di hari pertama sudah disepakati.
• Ada satu angka adopsi yang akan diukur setelah rilis, misalnya persentase laporan yang masuk di hari yang sama.
• Ada nama dan waktu jawab untuk laporan masalah di bulan pertama.

Lima pengguna untuk uji prototipe bukan angka ajaib. Dalam praktik, jumlah itu biasanya sudah cukup untuk menemukan sebagian besar masalah besar sebelum ongkos perbaikannya mahal.

Pertanyaan yang sering muncul

Berapa lama sampai kita tahu sistem benar-benar dipakai?

Dua sampai empat minggu setelah rilis biasanya cukup untuk melihat polanya. Ukur satu angka yang mudah dihitung, misalnya persentase laporan yang masuk di hari yang sama. Kalau angkanya turun setelah minggu pertama, ada langkah yang terlalu berat bagi pengisinya.

Apakah pelatihan yang lebih lama bisa menyelesaikan masalahnya?

Jarang. Pelatihan membantu orang tahu caranya, tapi tidak membuat mereka mau memakai sistem yang lebih lambat dari cara lama. Kalau tugas harian butuh pelatihan panjang, biasanya yang perlu diperbaiki desainnya.

Bisakah sistem yang sudah telanjur ditinggal diperbaiki tanpa membangun ulang?

Sering bisa. Mulai dari mengamati di mana orang keluar dari sistem, lalu perbaiki satu alur yang paling sering dipakai. Membangun ulang dari nol hanya masuk akal kalau fondasi datanya memang tidak bisa dipakai.