Ini adalah studi kasus otomasi dokumen tentang sebuah broker asuransi di Tangerang yang diam-diam tersendat oleh kesuksesannya sendiri. Makin banyak klien berarti makin banyak polis, makin banyak polis berarti makin banyak dokumen, dan makin banyak dokumen berarti makin banyak hal yang lolos dari perhatian. Timnya sibuk, pemiliknya stres, dan tidak ada yang bisa memastikan di mana persisnya sebuah polis berada pada satu waktu tertentu.
Saya ingin membahas kasus ini secara detail karena bagian yang menarik bukan teknologinya. Bagian yang menarik adalah proses diagnosisnya. Ketika saya mulai, semua orang mengira jawabannya adalah "beli software." Jawaban sebenarnya ternyata sekitar 30 persen software dan 70 persen mendesain ulang cara kerja mengalir di kantor tersebut. Kalau Anda melompati tahap diagnosis dan langsung ke sebuah tool, Anda hanya mengotomasi proses yang rusak dan membuatnya lebih cepat rusak.
Titik awal: email dan Excel sebagai sebuah sistem
Broker ini menangani polis personal dan komersial untuk beberapa ratus klien aktif. "Sistem" yang mereka pakai adalah email ditambah satu file Excel bersama. Permintaan klien datang lewat email atau WhatsApp. Seseorang mencetak atau meneruskannya. Detailnya diketik ke Excel. Dokumen pendukung tersebar di inbox, di shared drive, dan kadang di ponsel seseorang.
Gejalanya klasik:
- Polis tertahan berhari-hari karena tidak ada yang tahu giliran siapa untuk bertindak
- Detail klien yang sama diketik tiga sampai empat kali di tempat berbeda
- Pemiliknya tidak bisa menjawab "berapa polis yang pending renewal minggu ini" tanpa menghitung manual selama satu jam
- Ketika seorang staf cuti, pekerjaan yang sedang berjalan miliknya langsung terhenti, karena semuanya tersimpan di inbox pribadinya
Timnya bukan malas. Mereka bekerja keras di dalam sebuah proses yang justru menjamin adanya friksi.
Diagnosis: memetakan di mana dokumen tertahan, bukan di mana dokumen bergerak
Sebelum menyentuh tool apa pun, saya menghabiskan dua hari melakukan sesuatu yang tidak glamor: menelusuri dokumen. Bukan jalur yang lancar, tapi titik-titik tersendatnya. Untuk sampel polis-polis terbaru yang representatif, saya menelusuri persis di mana setiap polis berada, berapa lama, dan kenapa berhenti bergerak.
Polanya jelas. Bottleneck-nya bukan kecepatan mengetik atau jumlah orang. Masalahnya adalah serah terima tanpa pemilik yang jelas. Sebuah dokumen bisa datang lengkap tapi tertahan dua hari karena tidak jelas siapa yang seharusnya mengambil alih berikutnya. Renewal adalah yang terburuk, karena tidak ada yang memegang kalendernya; renewal diingat, bukan dilacak.
Ini adalah langkah yang paling sering dilewati orang, dan melewatinya adalah alasan kenapa begitu banyak proyek otomasi mengecewakan. Kalau Anda hanya memetakan di mana pekerjaan bergerak, semuanya akan terlihat baik-baik saja. Anda harus memetakan di mana pekerjaan berhenti. Dalam studi kasus otomasi dokumen ini, sekitar 70 persen dari total waktu yang terpakai pada sebuah polis adalah waktu menunggu, bukan waktu bekerja.
Desain ulang: satu intake, satu pipeline, pemilik yang jelas
Setelah titik-titik tersendat terpetakan, solusinya hampir mendesain dirinya sendiri. Software mendukung desain ini; software tidak memimpinnya.
Satu intake yang terstruktur. Alih-alih polis datang sebagai email bebas format, kami menaruh sebuah web form sederhana di depan. Klien dan staf memasukkan permintaan ke dalam field-field yang sesuai dengan apa yang benar-benar dibutuhkan proses tersebut. Tidak ada lagi acara mencari-cari di thread email untuk merekonstruksi apa yang sebenarnya diinginkan seseorang.
OCR untuk dokumen. Dokumen identitas, PDF polis lama, dan dokumen kendaraan diproses lewat OCR sehingga field-field kunci terekstrak otomatis alih-alih diketik ulang. Ini adalah satu-satunya bagian yang benar-benar bernuansa AI, dan ini penting karena mengetik ulang itu lambat sekaligus jadi sumber kesalahan. Peninjauan manusia tetap ada, karena OCR cukup sering salah dengan percaya diri sehingga Anda tidak pernah bisa sepenuhnya mempercayainya tanpa pengawasan.
Papan pipeline bersama. Setiap polis menjadi sebuah kartu yang bergerak melalui tahapan yang jelas: intake, verifikasi, quoting, konfirmasi klien, penerbitan, diarsipkan. Setiap tahap punya satu pemilik yang disebutkan namanya. Siapa pun bisa membuka papan itu dan melihat, dalam lima detik, di mana posisi semuanya.
Tampilan renewal. Karena tanggal-tanggal sekarang tersimpan dalam data terstruktur alih-alih ingatan, renewal muncul otomatis berminggu-minggu sebelumnya. Ini saja sudah memulihkan pendapatan yang selama ini bocor lewat polis-polis yang lewat masa berlaku tanpa dikejar tepat waktu.
Apa yang berubah, dalam angka
Saya waspada terhadap studi kasus yang menyebutkan angka perbaikan yang mencurigakan kebulatannya, jadi berikut angka-angka yang masuk akal dan jujur dari tiga bulan pertama setelah peluncuran.
| Ukuran | Sebelum | Sesudah |
|---|---|---|
| Rata-rata turnaround polis | 6 sampai 8 hari | 2 sampai 3 hari |
| Berapa kali detail klien diketik | 3 sampai 4 | 1 |
| Waktu pemilik untuk mendapatkan status pipeline | ~1 jam | hitungan detik |
| Renewal yang terlewat per bulan | beberapa | mendekati nol |
Perbaikan turnaround ini tidak datang dari siapa pun yang bekerja lebih cepat. Perbaikan ini datang dari menghilangkan waktu menunggu. Begitu serah terima punya pemilik dan semuanya terlihat di satu papan, pekerjaan berhenti mengendap tanpa gerak.
Kenapa yang 70 persen lebih penting dari yang 30 persen
Kalau broker ini sekadar membeli CRM asuransi yang mengkilap tanpa diagnosis, saya yakin itu akan gagal. Timnya akan tetap dengan kebiasaan email mereka, memasukkan data dua kali, dan menyalahkan tool-nya. Tool itu akan mengotomasi intake tapi membiarkan serah terima tanpa pemilik tetap tak tersentuh, padahal itulah masalah sebenarnya.
Desain ulang alur kerja inilah yang membuat software-nya benar-benar terpakai. Kami menentukan siapa yang memegang setiap tahap, menghilangkan duplikasi input data, dan membuat status terlihat sebelum kami mengotomasi apa pun. Software kemudian membuat proses yang sudah baik itu jadi mudah diikuti. Ini adalah pelajaran yang sama dengan yang ada di Manajemen Perubahan: Mengapa Staf Menolak Software Baru Anda: tool berhasil ketika proses di baliknya solid dan tim ikut membentuknya.
Ini juga pengingat bahwa kendala nyata sebuah perusahaan jarang sekali berupa fitur yang hilang. Biasanya itu adalah akumulasi utang proses, saudara operasional dari masalah kode yang saya jelaskan di Utang Teknis Dijelaskan untuk Pemilik Non-Teknis.
Pelajaran praktisnya
Kalau back office Anda tenggelam dalam dokumen, tahan dulu keinginan untuk membeli software di hari pertama. Habiskan dua atau tiga hari lebih dulu menelusuri dokumen-dokumen Anda melalui titik-titik tersendatnya. Tanyakan, untuk kasus-kasus nyata, di mana pekerjaan berhenti dan kenapa. Anda hampir selalu akan menemukan bahwa bottleneck-nya adalah serah terima tanpa pemilik, duplikasi input data, dan hal-hal yang dilacak lewat ingatan alih-alih lewat sistem.
Perbaiki dulu prosesnya, baru biarkan software membuat proses yang sudah diperbaiki itu jadi tanpa hambatan. Dalam studi kasus otomasi dokumen ini, urutan itulah yang mengubah operasi yang stres dan tidak transparan menjadi operasi yang bisa dilihat dan dipercaya pemiliknya, dan itu memangkas turnaround lebih dari separuh tanpa merekrut satu orang tambahan pun. Kalau Anda ingin bantuan menjalankan diagnosis semacam itu pada operasi Anda sendiri sebelum mengeluarkan biaya untuk tool, itulah jenis kerja yang saya lakukan sebagai technical partner.