Di banyak perusahaan, penggantian biaya terasa lambat bukan karena jumlahnya, melainkan karena alurnya bolak-balik antar-pihak, akibatnya tim finance kesulitan memprediksi arus kas, karyawan terus menanyakan status, dan manajer operasional kehilangan visibilitas. Dengan mengukur waktu siklus secara konsisten, Anda bisa menemukan titik macet, menetapkan SLA realistis, dan mempercepat proses tanpa mengurangi kontrol.
Samakan definisi waktu siklus dan titik mulai-akhir
Pengukuran akan bias jika setiap pihak memakai definisi berbeda, misalnya ada yang menghitung sejak kuitansi dibuat dan ada yang sejak diajukan, sepakati satu definisi yang mudah direplikasi lintas unit dan periode lalu dokumentasikan agar audit trail tetap rapi.
Praktik umum di Indonesia adalah menghitung dari “submit” (pengajuan terekam sistem) sampai “paid” (tanggal pembayaran tercatat), karena kedua titik ini paling berdampak pada pengalaman karyawan dan kas. Jika perusahaan Anda memisahkan verifikasi dan pembayaran, Anda tetap bisa menambah metrik per tahap tanpa mengubah definisi utama.
Pastikan setiap status punya makna operasional jelas, misalnya “dikembalikan” berarti perlu perbaikan data, bukan sekadar menunggu, tanpa disiplin status waktu siklus bisa tampak pendek padahal banyak kasus terparkir di status yang tidak mencerminkan pekerjaan nyata.
Lima cara mengukur waktu siklus agar bottleneck terlihat
Berikut lima pendekatan yang saling melengkapi, bukan pilihan tunggal, mulai dari yang paling mudah diambil datanya lalu kembangkan metrik saat alur persetujuan sudah lebih rapi.
-
End-to-end cycle time (submit ke paid). Ini metrik utama untuk layanan reimbursement, gunakan median (bukan rata-rata) agar tidak terpengaruh kasus ekstrem, dan laporkan juga persentil 90 untuk menunjukkan kasus paling lambat yang mengganggu persepsi.
-
Stage cycle time per tahap (submit ke approve, approve ke verify, verify ke paid). Pecah waktu siklus per tahap agar jelas apakah kemacetan ada di persetujuan, verifikasi bukti, atau eksekusi pembayaran, contoh: jika “approve ke verify” stabil 1 hari tetapi “verify ke paid” melonjak saat akhir bulan, kemungkinan masalah ada pada jadwal pembayaran atau kapasitas tim treasury.
-
Queue time vs touch time (waktu menunggu vs waktu dikerjakan). Banyak proses lambat bukan karena pekerjaan sulit, melainkan karena dokumen menunggu di antrean, ukur “touch time” sebagai durasi saat tiket sedang diproses lalu bandingkan dengan total waktu menunggu; perbandingan ini cepat menunjukkan apakah masalahnya kapasitas, prioritas, atau aturan persetujuan yang panjang.
-
Rework rate dan time-to-resubmit (kasus dikembalikan). Hitung persentase pengajuan yang dikembalikan untuk perbaikan, lalu ukur lama sampai diajukan ulang, jika rework tinggi mempercepat approver saja tidak cukup; perlu perbaikan kualitas input, format bukti, atau aturan kebijakan yang lebih jelas dari awal.
-
Compliance-to-SLA (kepatuhan terhadap target waktu). Tentukan SLA per tahap, misalnya persetujuan manajer 1 hari kerja dan verifikasi finance 2 hari kerja, lalu ukur proporsi yang memenuhi, pendekatan ini mudah dikomunikasikan ke manajer operasional karena fokus pada pemenuhan komitmen, bukan sekadar angka rata-rata.
Jika Anda sedang merapikan tata kelola persetujuan agar metrik di atas konsisten, rujukan tentang workflow persetujuan internal yang tertib dan mudah diaudit membantu memastikan setiap tahap meninggalkan jejak data yang bisa diukur.
Bangun data yang bisa dipercaya: timestamp, status, dan kalender kerja
Metrik kuat bisa runtuh jika timestamp tidak konsisten, pastikan sistem mencatat waktu otomatis untuk setiap transisi status (submit, approve, verify, reject/return, paid) bukan mengandalkan input manual yang rentan terlambat atau “dibulatkan”.
Gunakan kalender kerja agar perhitungan lebih adil, terutama untuk perusahaan dengan operasi Senin–Jumat, mengukur “hari kalender” dapat membuat proses terlihat lambat saat ada libur nasional sementara “hari kerja” lebih relevan untuk mengelola kapasitas tim.
Tambahkan atribut yang memudahkan segmentasi, misalnya unit, lokasi, jenis biaya (perjalanan dinas, entertain, operasional), serta jalur persetujuan (satu tingkat vs dua tingkat), dengan ini Anda bisa membedakan masalah kebijakan dari masalah eksekusi.
Terakhir, tetapkan aturan penanganan outlier sejak awal, misalnya pengajuan yang menunggu klarifikasi pajak atau koreksi akun bisa masuk kategori “exception” agar tidak merusak evaluasi proses standar tetapi tetap dipantau sebagai backlog khusus.
Interpretasi hasil dan tindakan perbaikan yang berdampak
Setelah dashboard berjalan, ubah angka menjadi keputusan, mulailah dengan satu atau dua hipotesis yang bisa diuji misalnya “bottleneck terbesar ada di persetujuan tingkat kedua” atau “keterlambatan dominan muncul di akhir periode”.
Jika stage cycle time menunjukkan macet di persetujuan, periksa desain alur: apakah approver pengganti tersedia saat cuti, apakah batas nominal memaksa eskalasi terlalu sering, dan apakah notifikasi benar-benar sampai, perbaikan sederhana seperti aturan delegasi dan reminder terjadwal sering menurunkan queue time tanpa mengurangi kontrol.
Jika rework rate tinggi, fokus pada pencegahan di hulu, buat daftar persyaratan bukti yang spesifik per jenis biaya, gunakan validasi wajib (misalnya tanggal transaksi, vendor, nominal, dan alasan), lalu sediakan contoh pengisian yang benar; satu contoh konkret sering mengurangi salah input lebih efektif daripada dokumen kebijakan panjang.
Jika keterlambatan muncul saat verify ke paid, masalah sering berkaitan dengan batch pembayaran atau prioritas kas, Anda bisa menguji apakah menambah frekuensi pembayaran (misalnya dua kali seminggu) menurunkan persentil 90 secara signifikan, atau apakah perlu jalur “fast track” untuk nominal kecil dengan risiko rendah.
Simpan perubahan sebagai eksperimen: tetapkan target (misalnya median turun 20% dalam 4 minggu), pilih satu perubahan proses, lalu pantau sebelum dan sesudah, disiplin eksperimen menghindarkan tim dari perubahan besar yang tidak berdampak dan memudahkan pertanggungjawaban saat audit internal meminta alasan perubahan kontrol.
Jika Anda ingin, rangkum metrik yang ada hari ini lalu pilih satu bottleneck untuk diuji dalam dua minggu.
Pelajari lebih lanjut: https://epruvo.com