Mulai dari proses, bukan dari model

Masalahnya bukan di model

Sebagian besar proyek AI yang berhenti di tengah jalan punya pola yang sama: pemilihan use case dimulai dari apa yang bisa dilakukan teknologi, bukan dari proses mana yang paling mahal dijalankan manual.

Akibatnya proof of concept-nya jalan, demonya mengesankan, lalu tidak ada yang memakainya. Enam bulan kemudian sistemnya masih ada, tapi tim tetap mengerjakan pekerjaan yang sama seperti sebelumnya.

Ini bukan kegagalan teknis. Model yang dipakai mungkin benar-benar bagus. Yang keliru adalah urutan keputusannya.

Kenapa urutan yang salah terasa benar

Pemilihan use case dari sisi teknologi terasa masuk akal karena ia bisa didemokan. Ada yang bisa ditunjukkan ke manajemen, ada yang bisa diukur sebagai kemajuan, dan ada vendor yang siap membantu.

Sementara pemetaan proses tidak menghasilkan apa-apa yang bisa dipamerkan di minggu kedua. Ia hanya menghasilkan pemahaman — yang justru menentukan apakah sisa anggarannya terbuang atau tidak.

Perusahaan yang sudah pernah kecewa dengan satu proyek AI biasanya jadi jauh lebih sulit meluncurkan yang kedua, meski yang kedua sebenarnya use case yang tepat. Itu biaya yang jarang dihitung.

Tiga pertanyaan sebelum menulis kode

Setiap kandidat use case kami nilai dengan tiga pertanyaan yang sama. Bukan karena ketiganya lengkap, tapi karena ketiganya cukup untuk menyingkirkan sebagian besar kandidat yang terdengar menarik tapi tidak bernilai.

Proses ini dijalankan berapa kali sehari, oleh berapa orang? Frekuensi menentukan apakah penghematan per siklus pernah terakumulasi jadi angka yang berarti. Proses yang jalan tiga kali sebulan hampir tidak pernah layak diotomasi lebih dulu, sebagus apa pun demonya.

Berapa lama satu siklusnya, dan di mana antriannya menumpuk? Yang penting bukan total durasi, melainkan di titik mana pekerjaan menunggu. Otomasi yang mempercepat langkah yang bukan penyempitan tidak mengubah apa pun di ujung.

Kalau outputnya salah, siapa yang menanggung dan seberapa mahal? Ini menentukan berapa banyak pengaman yang harus dibangun, dan karenanya menentukan biaya sebenarnya. Use case yang murah dibangun tapi mahal kalau keliru bukan use case murah.

Kalau ketiganya tidak bisa dijawab dengan angka, use case-nya belum siap — dan yang dibutuhkan lebih dulu adalah pengukuran, bukan pengembangan.

Otomasi yang tidak mengubah antrian di lapangan hanya memindahkan pekerjaan, bukan menghilangkannya.

Yang kami lakukan lebih dulu

Sebelum membangun apa pun, kami memetakan proses yang berjalan hari ini — termasuk langkah yang tidak ada di SOP tapi tetap dikerjakan orang. Di situ biasanya letak bebannya.

Pemetaan ini hampir selalu dilakukan dengan orang yang menjalankan prosesnya sehari-hari, bukan hanya dengan manajemen. Bukan karena manajemen keliru, tapi karena alur yang sebenarnya mengandung jalan pintas, pengecualian, dan kebiasaan yang tidak pernah masuk dokumen mana pun.

Beberapa temuan yang paling sering muncul:

Ada satu orang yang jadi penyambung antar dua sistem, dan seluruh proses berhenti kalau ia cuti
Data yang sama diketik ulang di tiga tempat karena sistemnya tidak saling bicara
Langkah persetujuan yang secara formal wajib, tapi dalam praktiknya selalu disetujui tanpa dibaca
Laporan yang dirakit tangan setiap minggu dan dibaca oleh dua orang

Tidak semuanya perlu AI. Sebagian hanya perlu integrasi, dan sebagian lagi hanya perlu langkahnya dihapus.

Baru setelah itu, keputusan teknis

Setelah prosesnya jelas, pilihan teknologinya justru jadi jauh lebih sempit dan lebih mudah: apakah ini butuh LLM, cukup rule engine, atau sebenarnya hanya butuh integrasi API antara dua sistem yang selama ini disambung lewat salin-tempel.

Urutan ini juga mengubah cara proyeknya dibicarakan di internal. Ketika use case datang dari proses yang memang membebani tim, tim tidak perlu diyakinkan bahwa masalahnya nyata — mereka sudah menjalaninya setiap hari.

Itu yang membuat sistemnya dipakai setelah go-live, dan pada akhirnya itulah satu-satunya ukuran yang menentukan proyeknya berhasil atau tidak.