Sebuah perusahaan multifinance yang pernah saya bantu kehilangan banyak deal, bukan karena bunga atau tenor kreditnya jelek, tapi karena nasabah menandatangani aplikasi hari Senin dan baru dapat kepastian hari Kamis. Produknya sudah bagus. Yang tidak ada adalah otomasi alur approval, dan celah itu diam-diam menggerus pangsa pasar mereka ke kompetitor yang bisa bilang "ya" dalam hitungan sore.
Ini pola yang cukup umum saya temui di jasa keuangan Indonesia. Logika kredit inti, credit scoring, pengecekan jaminan, semuanya sudah solid. Yang rusak adalah "pipa" antar departemennya: folder fisik yang harus berpindah dari cabang ke credit analyst, ke komite risiko, lalu ke finance, dan setiap titik mengharuskan tanda tangan basah sebelum bisa lanjut ke titik berikutnya. Tidak ada yang sengaja mendesainnya jadi lambat. Kontrol itu menumpuk satu per satu sampai akhirnya kertas menjadi bottleneck, bukan lagi pengaman.
Berikut bentuk rantai approval perusahaan ini, kenapa sekadar mendigitalkan dokumennya saja tidak akan menyelesaikan masalah, dan apa yang benar-benar berhasil memangkas waktu proses dari hitungan hari jadi hitungan jam.
Kenapa Kertasnya, Bukan Kebijakannya, yang Jadi Masalah
Perusahaan ini punya empat level approval untuk aplikasi pembiayaan standar, dan bisa sampai enam level untuk pengajuan di atas plafon tertentu: admin cabang, credit analyst, kepala cabang, risk regional, dan untuk deal besar, komite risiko serta direktur finance. Setiap level mewajibkan tanda tangan fisik dan stempel, karena itulah yang selama ini dituntut oleh audit internal dan ekspektasi kepatuhan yang mengacu ke OJK.
Kriteria kreditnya sendiri sudah masuk akal. Masalahnya ada di tiga hal struktural yang menumpuk di atasnya:
- Tidak ada visibilitas. Tidak ada yang tahu, termasuk cabang yang mengajukan berkas itu sendiri, di posisi mana sebuah aplikasi berada dalam rantai approval tanpa menelepon kesana kemari.
- Perilaku batch. Approver memproses folder secara batch, satu atau dua kali sehari, jadi berkas yang terlewat dari batch pagi harus menunggu batch berikutnya.
- Biaya pengerjaan ulang. Kalau analis dua level di atas minta dokumen ditambahkan lagi atau ada angka yang perlu dikoreksi, seluruh berkas fisik harus dikirim balik ke bawah lalu naik lagi dari awal.
Tidak ada satu pun dari ini yang merupakan masalah pelatihan atau disiplin kerja. Ini adalah konsekuensi wajar dari kontrol yang dirancang untuk era volume rendah dan kompleksitas rendah, tapi kemudian di-scale up tanpa didesain ulang.
Kenapa Kami Mengotomasi Alur Kerjanya, Bukan Cuma Dokumennya
Insting pertama perusahaan ini, dan itu wajar, adalah "ayo scan semuanya dan simpan secara digital." Itu akan membantu pengarsipan dan pencarian, tapi tidak akan menyentuh waktu proses, karena bottleneck-nya memang bukan soal penyimpanan. Masalahnya ada di urutan proses, visibilitas, dan pengerjaan ulang.
Jadi scope proyek dibingkai ulang di sekitar alur kerja, bukan dokumen:
- Satu record aplikasi digital tunggal yang dibuka, diedit, dan ditandatangani oleh setiap level approver, menggantikan folder fisik sepenuhnya.
- Routing berbasis peran (role-based routing) yang otomatis mendorong berkas ke approver berikutnya begitu approver saat ini menyetujui, tanpa menunggu serah terima manual atau proses batch.
- Signoff digital dengan audit trail lengkap, bertanda waktu dan bisa diatribusikan ke user tertentu, yang justru memenuhi kebutuhan kepatuhan lebih baik daripada stempel, karena stempel hanya membuktikan sebuah dokumen pernah ada, bukan siapa yang benar-benar mereview atau kapan.
- Trigger eskalasi sehingga berkas yang tidak tersentuh melewati batas waktu SLA otomatis mengirim notifikasi ke approver dan atasannya, alih-alih diam menunggu di inbox fisik.
- Permintaan koreksi inline sehingga seorang analis bisa menandai satu field tertentu untuk direvisi tanpa harus mengembalikan seluruh berkas ke awal rantai approval.
Setiap poin ini menyasar titik gesekan spesifik yang sudah kami petakan selama tahap discovery, bukan ambisi generik "digitalisasi departemen."
Batasan Kepatuhan yang Membentuk Semuanya
Sistem approval di jasa keuangan hidup dan matinya bergantung pada audit trail, dan di sinilah banyak proyek otomasi alur kerja salah langkah dengan memperlakukan kepatuhan sebagai tambahan yang ditempel belakangan. Kami memperlakukannya sebagai requirement kelas satu sejak hari pertama.
Setiap aksi di sistem baru ini, lihat, edit, setujui, tolak, komentar, dicatat lengkap dengan user ID, timestamp, dan hash dari kondisi dokumen pada saat itu. Ini penting untuk dua pihak: tim risiko dan audit internal, yang perlu merekonstruksi persis apa yang terjadi pada sebuah berkas saat ada review, dan auditor eksternal perusahaan multifinance ini, yang perlu jaminan bahwa approval digital punya bobot pembuktian yang setara dengan tanda tangan basah.
Pelajaran yang berlaku umum di luar proyek ini: kalau Anda mengotomasi proses apa pun yang berat di approval dalam industri yang diregulasi, audit trail bukan fitur yang ditambahkan belakangan, itu adalah tulang punggung tempat seluruh sinyal sistem lainnya mengalir. Kalau ini salah, secepat apa pun sistemnya, tetap tidak akan lolos untuk dipakai produksi.
Apa yang Berubah Setelah Rollout
Hasil yang terukur, tiga bulan setelah go-live:
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Waktu proses aplikasi standar | 3-5 hari kerja | Hari yang sama hingga esok pagi |
| Waktu proses aplikasi plafon besar | 7-10 hari kerja | 1-2 hari kerja |
| Visibilitas status berkas | Telepon untuk melacak | Dashboard real-time per cabang |
| Waktu siklus pengerjaan ulang | Re-route penuh (1-2 hari) | Koreksi inline (menit hingga jam) |
Perubahan yang lebih besar justru bersifat kualitatif. Staf cabang berhenti menjadikan "di mana aplikasi saya" sebagai kecemasan harian dan mulai memperlakukan sistem sebagai sumber kebenaran. Anggota komite risiko bilang ke kami bahwa audit trail justru lebih mudah direview dibanding folder berstempel yang lama, karena mereka bisa memfilter dan mencari, bukan membolak-balik kertas.
Kalau bisnis Anda punya proses apa pun di mana beberapa orang harus memberi persetujuan sebelum sesuatu bisa lanjut, entah itu approval kredit, procurement, atau review kontrak, pola yang sama berlaku: petakan di mana berkas benar-benar berhenti bergerak, bukan di mana kebijakan bilang seharusnya bergerak, lalu otomasi titik sumbat spesifik itu. Untuk contoh lain bagaimana operasi manual yang berat kertas dimodernisasi tanpa rebuild total, lihat Bisnis Manufaktur Keluarga Ini Akhirnya Go Digital.
Intinya
Bottleneck approval jarang sekali merupakan masalah kebijakan. Itu masalah routing, visibilitas, dan pengerjaan ulang yang menyamar sebagai masalah kebijakan. Sebelum Anda memutuskan membangun ulang sistem secara menyeluruh, petakan dulu persis di mana sebuah berkas berhenti bergerak dan kenapa, karena di kebanyakan kasus solusinya adalah lapisan routing dan audit trail di atas aturan yang sudah ada, bukan seperangkat aturan baru. Bereskan audit trail sejak awal, karena menambahkannya belakangan jauh lebih mahal daripada mendesainnya sejak awal.