WRNOTE: Mulai dari Masalah Bisnis, Bukan dari Model AI

Strategi yang berguna menjelaskan hasil yang dicari, batas eksperimen, dan alasan untuk berhenti.

Demo menarik belum tentu menjawab masalah

Sebuah distributor fiktif ingin memakai AI karena tim lain sudah membuat chatbot. Namun keluhan pelanggannya bukan kekurangan tempat bertanya. Pelanggan berkali-kali mendapat perkiraan pengiriman yang berbeda karena data gudang dan penjualan tidak sama.

Memasang chatbot di depan data yang tidak konsisten bisa membuat jawaban keliru terdengar lebih meyakinkan. Masalah bisnisnya perlu ditulis lebih dulu: pelanggan belum mendapat informasi pengiriman yang dapat diandalkan. Teknologinya baru dipilih setelah penyebab dan kebutuhan pekerjaannya dipahami.

Diagram orisinal. Skenario fiktif untuk pembelajaran.

Tuliskan outcome sebelum daftar fitur

Business outcome adalah perubahan yang ingin dirasakan bisnis atau pelanggan. Dalam kasus distributor tadi, hasil yang dicari bisa berupa berkurangnya pelanggan yang harus menghubungi tim berulang kali untuk satu pengiriman. Itu berbeda dari target memasang chatbot atau menghasilkan banyak jawaban.

KPI membantu memeriksa apakah perubahan terjadi. Tim dapat melihat pengulangan kontak untuk masalah yang sama, ketepatan informasi pengiriman, dan waktu penyelesaian. Metrik teknis seperti kecepatan respons tetap penting, tetapi tidak menggantikan hasil layanan.

Sebelum uji coba, catat baseline: keadaan awal dengan cara ukur yang jelas. Tentukan jenis permintaan yang dihitung, periode pengamatan, dan sumber datanya. Tanpa definisi yang sama, hasil sebelum dan sesudah mudah terlihat membaik hanya karena cara menghitung berubah.

Buat satu halaman opportunity brief

Opportunity brief tidak harus rumit. Isinya menjelaskan siapa yang mengalami masalah, pada langkah mana hambatan muncul, dan apa akibatnya. Lalu tuliskan hasil yang ingin diperbaiki, data yang diperlukan, serta siapa pemilik prosesnya.

Untuk distributor, brief dapat membatasi uji coba pada draf jawaban status pengiriman untuk petugas layanan. Sistem tidak menjanjikan tanggal baru kepada pelanggan dan tidak mengubah pesanan. Data stok dan pengiriman berasal dari sumber yang disepakati, bukan tebakan model.

Tuliskan juga hal yang belum diketahui. Misalnya, apakah pembaruan data cukup cepat dan apakah petugas benar-benar memakai draf itu. Daftar asumsi memberi arah eksperimen. Ia lebih berguna daripada berpura-pura seluruh business case sudah terbukti.

Build, buy, atau partner bukan lomba gengsi

Buy berarti memakai produk yang sudah tersedia. Pilihan ini dapat cocok ketika kebutuhan relatif umum, tetapi kesesuaian alur kerja, akses data, biaya lisensi, integrasi, dan cara keluar tetap perlu dinilai. Produk siap pakai bukan berarti langsung siap untuk setiap organisasi.

Build berarti membangun bagian solusi sendiri. Ini dapat memberi kendali atas pengalaman dan integrasi yang khas, tetapi organisasi juga menanggung pengujian, pemeliharaan, keamanan, dan dukungannya. Build tidak selalu berarti melatih model dari nol; aplikasi sendiri dapat memakai model atau layanan yang sudah ada.

Partner berarti bekerja bersama pihak yang membawa kemampuan atau kapasitas tambahan. Tetap jelaskan siapa pemilik keputusan, data, hasil kerja, dan dukungan setelah proyek selesai. Ketiga jalur dapat digabung. Pilih berdasarkan kebutuhan dan kemampuan, bukan anggapan bahwa membeli selalu cepat atau membangun selalu lebih istimewa.

Prioritaskan manfaat, kelayakan, dan risiko bersama

Ide dengan potensi manfaat terbesar belum tentu paling tepat dikerjakan pertama. Periksa apakah data tersedia secara sah, prosesnya cukup jelas, pengguna siap mencoba, dan dampak salahnya dapat dikendalikan. Ide sederhana yang bisa diuji dengan baik dapat memberi pembelajaran yang lebih berguna.

Distributor dapat membandingkan tiga kandidat: merapikan sumber status pengiriman, membantu petugas membuat draf, atau membiarkan sistem mengirim jawaban langsung. Ketiganya tidak punya beban risiko yang sama. Perbaikan data mungkin harus mendahului penggunaan AI, bukan dimasukkan sebagai pekerjaan nanti.

Tidak semua kriteria perlu dipaksa menjadi satu skor. Catat alasan pilihan dan hambatan yang belum selesai. Jika hak akses data belum jelas, skor manfaat tinggi tidak menghapus masalah itu.

Tentukan lanjut, perbaiki, atau berhenti sejak awal

Eksperimen yang baik menguji dugaan, bukan mencari pembenaran. Sebelum mulai, sepakati ukuran mutu, biaya, waktu respons, dan batas risiko. Sertakan pengguna layanan dan pemilik proses agar keputusan akhir tidak hanya bergantung pada kesan tim pembuat.

Jika draf membantu tanpa menurunkan ketepatan informasi, proyek dapat dilanjutkan ke pengujian yang lebih nyata. Jika data belum siap, perbaiki dasar datanya. Jika kebutuhan lebih mudah diselesaikan dengan perubahan proses biasa, menghentikan jalur AI bisa menjadi keputusan yang tepat.

Lulus proof of concept juga belum sama dengan siap diperluas. Integrasi, dukungan operasional, akses data, dan pemantauan masih perlu diuji. Strategi AI yang sehat menghubungkan setiap keputusan teknologi dengan masalah yang memang layak diselesaikan.