Hari peluncuran sering dirayakan seolah pekerjaan sudah selesai. Padahal, keberhasilan aplikasi baru baru terlihat beberapa bulan kemudian, saat rasa baru hilang dan pengguna kembali ke kebiasaan lama atau tidak. Kami pernah melihat sistem yang secara teknis sempurna tetapi hanya dibuka dua orang setelah bulan kedua, dan kami membahas penyebab umumnya di artikel tentang sistem yang tidak dipakai.
Artikel ini menawarkan cara sederhana mengukur adopsi tanpa alat analitik yang rumit. Cukup lembar kerja, beberapa pertanyaan, dan kebiasaan melihatnya pada waktu tertentu.
Mulai dari tujuan, bukan dari angka
Sebelum rilis, tuliskan satu sampai tiga hasil yang Anda harapkan, dalam bahasa pekerjaan, bukan bahasa teknologi. Contoh:
- "Rekap penjualan harian tersedia sebelum pukul 17.00 tanpa menyalin dari nota."
- "Permohonan layanan tidak lagi dicatat di buku, semuanya masuk aplikasi."
- "Waktu menyusun laporan bulanan turun dari lima hari menjadi satu hari."
Metrik hanya berguna bila terhubung dengan tujuan seperti ini. Tanpa itu, angka yang terkumpul tidak menjawab pertanyaan apa pun.
Empat metrik sederhana
- Pengguna aktif. Berapa persen pengguna yang seharusnya memakai aplikasi benar-benar masuk pada minggu terakhir? Hitung dari daftar orang yang seharusnya memakai, bukan dari jumlah akun yang dibuat.
- Cakupan pekerjaan. Dari seluruh transaksi atau berkas yang terjadi, berapa persen yang tercatat di aplikasi? Kalau 100 permohonan masuk tetapi hanya 60 tercatat, 40 sisanya masih lewat jalur lama.
- Waktu penyelesaian. Berapa lama satu pekerjaan utama selesai dibandingkan sebelum aplikasi? Ambil contoh sampel kecil, misalnya 10 kasus.
- Permintaan bantuan dan keluhan. Jumlah dan jenisnya. Banyak pertanyaan yang sama berarti ada bagian yang membingungkan atau pelatihan yang kurang.
Anda bisa menambah metrik khusus, misalnya jumlah kesalahan input atau jumlah koreksi data, tetapi empat di atas sudah cukup untuk memulai.
Hari ke-30: apakah dipakai?
Pada bulan pertama, pertanyaannya sederhana: orang mau membuka aplikasi atau tidak. Yang diperiksa:
- Persentase pengguna aktif mingguan.
- Apakah masih ada pekerjaan yang dicatat paralel di buku atau Excel, dan alasannya.
- Masalah yang paling banyak dilaporkan, apakah itu cacat teknis atau kebingungan alur.
Tindakan wajar pada tahap ini: perbaiki cacat yang menghambat, adakan sesi tanya jawab singkat, dan tunjuk satu orang di tiap unit sebagai rujukan pertama. Jangan menambah fitur dulu.
Hari ke-60: apakah menggantikan cara lama?
Pada bulan kedua, lihat apakah aplikasi sudah menjadi jalur utama.
- Cakupan pekerjaan di aplikasi mendekati seluruhnya.
- Catatan paralel di jalur lama dihentikan secara resmi.
- Waktu penyelesaian mulai membaik dibanding sebelum aplikasi.
- Data di dalam aplikasi cukup bersih untuk dijadikan laporan.
Kalau cakupan masih rendah, tanyakan langsung ke pengguna yang belum memakai. Jawabannya biasanya konkret: "formulirnya terlalu panjang", "tidak ada koneksi di lapangan", atau "atasan masih minta laporan dalam bentuk lama". Masing-masing punya solusi yang berbeda, dan hanya sebagian yang bersifat teknis.
Hari ke-90: apakah memberi hasil yang dijanjikan?
Pada bulan ketiga, kembali ke tujuan awal.
- Bandingkan hasil dengan tujuan yang Anda tulis sebelum rilis.
- Hitung perkiraan waktu yang dihemat atau kesalahan yang berkurang, sebisanya dengan data nyata, bukan perkiraan optimistis.
- Kumpulkan daftar permintaan perubahan dan urutkan berdasarkan dampaknya.
- Putuskan: lanjut seperti sekarang, perbaiki beberapa hal, atau ubah pendekatan.
Contoh pembacaan angka
Sebuah kantor memulai sistem pencatatan permohonan. Hari ke-30: 80 persen staf aktif, tetapi cakupan hanya 50 persen karena staf lapangan masih mencatat di buku. Hari ke-60: setelah formulir lapangan dipersingkat, cakupan naik menjadi 85 persen. Hari ke-90: laporan bulanan selesai dalam dua hari dari sebelumnya lima. Angka-angka ini rekaan untuk ilustrasi, tetapi pola pembacaannya nyata: persentase pengguna saja menipu, cakupan pekerjaan yang menunjukkan kebenaran.
Kesalahan umum
- Mengukur jumlah akun terdaftar, bukan pemakaian nyata.
- Tidak punya kondisi awal untuk dibandingkan, sehingga hasilnya hanya perasaan.
- Menganggap pengguna yang diam berarti puas.
- Menambah fitur saat masalahnya sebenarnya pelatihan atau kebiasaan.
- Tidak ada yang bertanggung jawab atas pengukuran, sehingga berhenti setelah bulan pertama.
- Menyalahkan pengguna padahal alurnya yang perlu disederhanakan.
Daftar periksa
- Tujuan tertulis sebelum rilis.
- Kondisi awal sudah dicatat: waktu, volume, kesalahan.
- Ada satu penanggung jawab pengukuran.
- Tiga jadwal tinjauan (30, 60, 90 hari) sudah masuk kalender.
- Tersedia saluran sederhana bagi pengguna untuk menyampaikan kendala.
- Keputusan lanjutan dicatat setelah tiap tinjauan.
Mengukur tidak perlu mahal. Yang dibutuhkan adalah kebiasaan melihat angka yang sama pada waktu yang sama, lalu mau bertindak berdasarkan hasilnya.