Cerita yang paling sering kami dengar dari calon klien saat konsultasi awal adalah tentang sistem lama yang "sudah dibangun tapi tidak dipakai". Uangnya sudah keluar, sistemnya secara teknis berfungsi, tapi begitu serah terima selesai, aplikasinya pelan-pelan ditinggalkan dan staf kembali ke Excel atau catatan manual.
Yang menarik, hampir tidak pernah alasannya karena sistemnya rusak. Biasanya sistemnya jalan. Hanya saja tidak ada yang mau memakainya, dan itu masalah yang berbeda sama sekali.
Akar pertama: dirancang dari asumsi, bukan dari cara kerja nyata
Ini terjadi ketika fase analisis kebutuhan dipercepat atau dilewati. Developer membangun berdasarkan spesifikasi umum dan wawancara dengan pimpinan, bukan berdasarkan bagaimana staf benar-benar bekerja setiap hari, lengkap dengan kebiasaan dan pengecualian kecil yang terlihat sepele.
Justru pengecualian kecil itu yang mematikan. Contoh nyata dari salah satu proyek yang kami ambil alih: sistem pengajuan yang lama mewajibkan nomor surat diisi sebelum berkas bisa disimpan. Masuk akal di atas kertas. Masalahnya, di instansi itu nomor surat baru keluar sore hari dari bagian tata usaha, sedangkan berkasnya masuk pagi. Akibatnya staf tidak bisa mencatat apa pun sampai sore, jadi mereka mencatat sementara di buku, lalu memindahkan ke sistem kalau sempat. Dua bulan kemudian, "kalau sempat" itu berhenti terjadi.
Perbaikannya sederhana: nomor surat dibuat opsional saat draf, wajib saat berkas difinalisasi. Satu perubahan aturan validasi, dan sistem yang mangkrak setahun mulai dipakai lagi. Yang mahal bukan memperbaikinya, tapi mengetahuinya terlambat.
Akar kedua: UAT dianggap formalitas
User Acceptance Test kerap diperlakukan sebagai tahap tanda tangan menjelang serah terima. Padahal ini kesempatan terakhir bagi pengguna sebenarnya untuk mencoba sistem dalam skenario kerja nyata sebelum dipakai harian.
Bedanya jelas kalau dilihat dari siapa yang duduk di depan layar. UAT formalitas dihadiri kepala bagian yang mengklik lima menu lalu menandatangani berita acara. UAT yang berguna dihadiri staf yang setiap hari menginput, dengan data kasus yang benar-benar pernah terjadi, termasuk kasus yang aneh: pemohon yang datanya ganda, transaksi yang harus dibatalkan setelah disetujui, berkas yang kurang satu lampiran.
Kalau kasus-kasus itu tidak diuji sebelum go-live, mereka tetap akan muncul. Bedanya, muncul saat anggaran dan semangat memperbaiki sudah habis.
Akar ketiga: tidak ada pendampingan setelah rilis
Sistem sebagus apa pun tetap butuh masa adaptasi. Staf yang bertahun-tahun terbiasa cara manual perlu waktu untuk berubah kebiasaan, dan pelatihan sekali di hari peluncuran hampir tidak pernah cukup.
Pola yang kami lihat berulang: minggu pertama semua bersemangat, minggu kedua mulai muncul pertanyaan kecil yang tidak terjawab, minggu ketiga satu dua orang kembali ke cara lama karena lebih cepat, dan bulan kedua sistemnya sepi. Titik kritisnya biasanya ada di minggu kedua dan ketiga, saat masalah kecil masih mudah diperbaiki tapi belum ada yang melaporkannya.
Karena itu kami menyarankan jadwal pendampingan yang eksplisit di kontrak, bukan sekadar janji "kami siap dihubungi". Misalnya kunjungan atau sesi daring rutin di minggu kedua, keempat, dan kedelapan setelah go-live, dengan agenda mengumpulkan keluhan kecil, bukan menunggu keluhan datang.
Tanda-tanda awal yang bisa Anda pantau sendiri
Anda tidak perlu menunggu enam bulan untuk tahu sistem Anda sedang ditinggalkan. Beberapa indikator ini biasanya muncul jauh lebih awal:
- Jumlah transaksi yang diinput per minggu menurun, padahal volume pekerjaan tetap.
- Ada satu orang yang menginput untuk seluruh tim. Ini tanda yang lain sudah menyerah.
- Data diinput menumpuk di akhir bulan, bukan harian. Artinya sistem tidak dipakai untuk bekerja, hanya untuk melapor.
- Muncul lagi file Excel bayangan yang dipakai sebagai catatan sebenarnya.
Kalau vendor Anda tidak bisa menunjukkan angka-angka ini, mintalah. Semua sistem yang layak pasti bisa menghitungnya.
Urutan yang kami pakai, dan kenapa terasa lambat di awal
Proyek kami berjalan dengan alur yang tetap: analisis kebutuhan turun langsung ke meja staf, scope disepakati tertulis, pengembangan bertahap dengan checkpoint, testing dan staging yang dicoba tim internal klien, UAT yang melibatkan pengguna harian, baru deployment, lalu pendampingan berkala.
Urutan ini memang terasa memperlambat di awal. Fase analisis sering menghabiskan dua sampai tiga minggu yang kelihatannya "belum ada hasilnya" karena belum ada layar yang bisa dilihat. Tapi biaya memperbaiki salah paham di fase analisis adalah mengubah satu paragraf di dokumen. Biaya memperbaikinya setelah go-live adalah mengubah struktur data, migrasi ulang, dan melatih ulang orang.
Sistem yang benar-benar dipakai bukan hasil dari kode yang lebih bagus. Biasanya cuma hasil dari lebih banyak pertanyaan yang ditanyakan sebelum menulis kode.