WRNOTE: Proyek AI Tertahan: Tambah Training atau Perbaiki Proses?

Ketika penggunaan rendah, jangan buru-buru menilai orangnya belum siap. Temukan hambatan yang benar-benar menahan pekerjaan.

Gejala yang sama bisa punya penyebab berbeda

Sebuah perusahaan distributor fiktif menyediakan asisten untuk mencari prosedur retur. Pelatihan pengenalan sudah dilakukan, tetapi petugas jarang menggunakannya. Sponsor ingin mengulang training agar investasi tidak terlihat sia-sia.

Ada beberapa penjelasan yang perlu diuji. Petugas mungkin belum bisa memeriksa jawaban. Bisa juga prosedur yang dicari tidak mutakhir, akses sering gagal, atau proses baru justru menambah pekerjaan. Angka penggunaan tidak bisa membedakan semua kemungkinan itu.

Kasus ini latihan diagnosis orisinal. Kita tidak sedang memberi skor kematangan seluruh perusahaan atau mengerjakan soal resmi. Pertanyaannya lebih sempit: perubahan apa yang paling masuk akal untuk mengatasi hambatan pada pekerjaan ini?

Lihat satu pekerjaan dari awal sampai selesai

Minta beberapa pengguna menunjukkan bagaimana mereka menangani satu retur, dengan data contoh yang aman dan izin yang sesuai. Catat kapan mereka mencari informasi, memeriksa jawaban, meminta persetujuan, serta menyalin hasil ke sistem lain. Jangan mengubah pengamatan menjadi pemantauan individu tanpa tujuan dan batas yang jelas.

Pisahkan waktu mencari, waktu memeriksa, waktu menunggu keputusan, dan pekerjaan ulang. Bila hambatan utamanya menunggu persetujuan, jawaban AI yang lebih cepat belum tentu mempercepat layanan. Bila sumbernya saling bertentangan, pengguna yang berhati-hati justru akan lebih banyak memeriksa.

Gabungkan pengamatan dengan percakapan dan bukti proses. Keluhan adalah petunjuk, bukan bukti sebab dengan sendirinya. Pengguna yang diam juga belum tentu setuju. Tanyakan kasus yang membuat mereka kembali ke cara lama dan apa yang terjadi sesudahnya.

Bedakan kemampuan, kesempatan, dan aturan kerja

Untuk dugaan gap kemampuan, minta pengguna menjalankan tugas: mencari sumber, mengenali versi usang, memeriksa jawaban, dan meminta bantuan. Jika kesulitan terletak di sana, latihan berbasis tugas dan pendampingan mungkin lebih tepat daripada presentasi umum.

Untuk dugaan hambatan proses, periksa hak akses, pemilik dokumen, alur persetujuan, integrasi, serta dukungan. Jangan mengirim orang mengikuti training untuk menutupi kegagalan akses yang hanya bisa diperbaiki pemilik sistem.

Periksa pula target dan pembagian kerja. Jika petugas diwajibkan meninjau setiap draf tetapi hanya dinilai dari kecepatan, mereka menerima dua tuntutan yang bertentangan. Perbaikannya perlu melibatkan pemilik proses dan manajer, bukan dibebankan kepada pengguna.

Pilih perubahan kecil yang bisa membantah dugaan

Misalnya, pengamatan menunjukkan petugas sering meninggalkan aplikasi karena versi prosedur tidak jelas. Dugaan kerja: keterlacakan sumber menghambat pemakaian yang aman. Uji perbaikan pada satu jenis retur, bukan langsung membeli model baru.

Tetapkan sebelum uji: sumber yang sah, siapa menjaga versinya, siapa boleh mengakses, dan bukti apa yang akan diperiksa. Bandingkan waktu total, mutu keputusan, pekerjaan ulang, serta beban pemeriksaan dengan kondisi awal. Banyaknya login hanya salah satu sinyal, bukan tujuan akhir.

Jangan menyatakan sebab sudah terbukti hanya karena hasil satu kelompok membaik. Perhatikan perbedaan pengalaman pengguna, variasi kasus, dan bantuan tambahan selama uji. Catat penjelasan alternatif agar tim tahu apa yang masih perlu diperiksa.

Beri pemilik pada perbaikan, bukan pada keluhan

Buat catatan singkat: hambatan, bukti, dugaan penyebab, perubahan yang diuji, pemilik, serta waktu review. Bedakan masalah yang harus selesai sebelum penggunaan dilanjutkan dari perbaikan yang boleh berjalan dalam lingkup terbatas dengan kontrol yang disetujui.

Sponsor membantu membuka hambatan lintas fungsi. Pemilik proses memperbaiki aturan kerja. Pemilik data menjaga sumber. Tim teknis menangani akses dan keandalan. Pengguna menilai apakah perubahan membantu pekerjaan nyata. Pembagian ini contoh untuk kasus tersebut, bukan struktur wajib semua organisasi.

Kembalikan hasil kepada orang yang memberi masukan. Jelaskan apa yang berubah, apa yang belum, serta alasannya. Meminta feedback berulang kali tanpa tindak lanjut bisa membuat saluran masukan kehilangan kepercayaan.

Training tetap penting ketika masalahnya tepat

Panduan kesiapan organisasi AWS membahas kepemimpinan, budaya, training, dan komunikasi. Artinya, kemampuan adalah satu bagian dari kesiapan, bukan penjelasan tunggal untuk setiap proyek yang tertahan. Panduan tersebut menjadi rujukan prinsip, bukan bukti bahwa perusahaan fiktif ini punya masalah tertentu.

Setelah perbaikan proses, latihan mungkin tetap diperlukan. Buat sesuai peran dan pekerjaan yang berubah. Uji kemampuan menjalankan kontrol, bukan hanya kehadiran atau rasa percaya diri sesudah kelas.

Keputusan berikutnya bisa berupa lanjut terbatas, ubah pendekatan, atau hentikan penggunaan yang belum layak. Diagnosis yang berguna tidak membela proyek dengan segala cara. Ia membantu memilih perubahan berdasarkan bukti, termasuk ketika jawabannya bukan menambah AI.