WRNOTE: Satu Halaman Business Case AI yang Bisa Dipakai Berdiskusi

Business case bukan janji manfaat dalam kemasan rapi. Isinya harus membantu tim memilih langkah, menguji asumsi, dan tahu kapan berhenti.

Satu halaman untuk satu keputusan

Bayangkan perusahaan jasa fiktif ingin membantu petugas mencari prosedur dan menyiapkan jawaban pelanggan. Proposal awalnya berbunyi: memakai AI agar layanan lebih cepat. Kalimat itu belum cukup untuk menentukan apakah investasi layak dilakukan.

Business case bisa dimulai dari satu halaman. Bukan karena proyeknya sederhana, tetapi supaya hubungan antara masalah, pilihan, biaya, risiko, dan keputusan terlihat. Rincian teknis serta perhitungan tetap perlu lampiran ketika keputusan makin besar.

Review ini menyatukan strategi, nilai bisnis, dan keunggulan bersaing yang telah dibahas sebelumnya. Latihannya bukan menghafal istilah Domain 2, melainkan memakai konsep itu untuk menilai satu usulan. Skenario, target, dan pilihan berikut bersifat ilustratif.

Diagram orisinal. Skenario fiktif untuk pembelajaran.

Kotak pertama: masalah dan kondisi awal

Tulis masalah dalam bahasa pekerjaan: petugas kesulitan menemukan prosedur yang berlaku sehingga pelanggan menunggu dan beberapa tiket harus dikerjakan ulang. Sebut siapa terdampak, alur yang dimaksud, dan apa yang belum diketahui.

Sebelum memasang target, ukur baseline dengan definisi yang konsisten. Waktu mencari sumber, waktu memeriksa jawaban, penyelesaian pada kontak pertama, dan keluhan adalah hal berbeda. Jangan menilai kecepatan saja jika pekerjaan ulang atau kesalahan justru meningkat.

Contoh target sementara: mengurangi waktu penyelesaian untuk kategori tiket tertentu tanpa menaikkan kesalahan kebijakan. Angka target baru ditetapkan setelah baseline dan batas risiko diperiksa. Target adalah hipotesis yang akan diuji, bukan hasil yang sudah dicapai.

Kotak kedua: pilihan yang benar-benar dibandingkan

Tulis setidaknya pilihan tetap seperti sekarang, memperbaiki proses atau pencarian biasa, dan memakai bantuan AI yang dibatasi. Tanpa pembanding, business case mudah menganggap setiap perbaikan berasal dari model padahal sumbernya mungkin penataan dokumen.

Untuk kandidat AI, bandingkan build, buy, dan partner berdasarkan kebutuhan yang sama. Solusi siap pakai tetap membutuhkan evaluasi, integrasi, izin data, dan dukungan operasional. Membangun sendiri juga tidak otomatis memberi kendali penuh jika tim bergantung pada komponen pihak lain.

Catat apa yang membedakan usulan ini dalam jangka panjang. Jawaban lebih cepat mungkin hanya efisiensi yang mudah ditiru. Nilai yang lebih tahan lama dapat bergantung pada proses, data yang layak, hubungan pelanggan, serta kemampuan tim memperbaiki layanan. Jangan menjanjikan keunggulan hanya dari akses ke alat.

Kotak ketiga: nilai, biaya, dan pemilik manfaat

Pisahkan kapasitas yang dibebaskan, pengeluaran yang benar-benar turun, dan hasil layanan yang membaik. Menit yang dihemat belum menjadi uang masuk. Perlu penjelasan siapa memakai waktu itu, untuk pekerjaan apa, dan bagaimana dampaknya akan diukur.

Masukkan biaya sejak persiapan sampai operasi: data, integrasi, lisensi atau pemakaian, pemeriksaan manusia, pelatihan, dukungan, dan penanganan kesalahan. Buat skenario pemakaian rendah, wajar, dan tinggi. Jangan menggabungkan angka manfaat optimistis dengan biaya terendah tanpa penjelasan.

Tunjuk pemilik manfaat dari proses bisnis, bukan hanya pemilik proyek teknis. Orang ini memeriksa apakah perubahan benar-benar terjadi. Catat juga asumsi yang paling memengaruhi keputusan, misalnya volume tiket yang layak dibantu dan banyaknya draf yang harus diperbaiki.

Kotak keempat: batas dan uji yang bisa menggugurkan usulan

Pilot fiktif dibatasi pada draf untuk petugas, dengan prosedur yang disetujui dan hak akses yang sesuai. Aplikasi tidak boleh mengirim janji ke pelanggan atau melakukan transaksi. Batas ini memperjelas apa yang sedang diuji dan apa yang belum mendapat persetujuan.

Tentukan bukti yang harus terkumpul: kualitas jawaban pada contoh representatif, perilaku ketika sumber tidak tersedia, biaya per tiket yang benar-benar selesai, serta dampak terhadap pekerjaan ulang. Tetapkan siapa menilai dan berapa lama pengamatan diperlukan sebelum mengambil keputusan.

Syarat berhenti perlu ditulis sebelum tim terlanjur menyukai demo. Contohnya akses data tidak bisa dibatasi sesuai kebutuhan, kesalahan penting berulang, atau manfaat bersih tidak terlihat dalam batas biaya. Ambang konkretnya harus disepakati untuk konteks organisasi, bukan disalin sebagai angka universal.

Kotak terakhir: keputusan berikutnya dan kapan dibuka lagi

Akhiri halaman dengan satu keputusan yang diminta: apakah menyetujui eksperimen terbatas, meminta bukti tambahan, memilih perbaikan non-AI, atau menghentikan usulan? Sebut pemilik keputusan, tanggal review, serta kondisi yang membuat penilaian perlu diulang.

Satu halaman tidak menggantikan kajian keamanan, hukum, pengadaan, atau arsitektur. Fungsinya menghubungkan kajian itu dengan alasan bisnis. Jika setiap orang membaca halaman yang sama tetapi membayangkan tujuan berbeda, business case masih perlu diperjelas.

Business case yang baik boleh berubah setelah diuji. Mengurangi scope atau berhenti bukan otomatis kegagalan. Bisa jadi itulah hasil paling berguna dari investasi belajar yang dibatasi sejak awal. Tulisan ini memakai cakupan publik dan rujukan teknis, bukan klaim meninjau seluruh aktivitas kursus.