Bagaimana Internal Approval Workflow Mengurangi Bottleneck Dalam Proses?

Bagaimana Internal Approval Workflow Mengurangi Bottleneck Dalam Proses?

Di banyak perusahaan, pekerjaan paling mahal sering bukan yang rumit, melainkan yang menunggu: menunggu tanda tangan, klarifikasi, atau revisi yang berputar di email. Penundaan kecil seperti itu menumpuk jadi bottleneck yang mengganggu target proyek, arus kas, dan kualitas keputusan. Tulisan ini menjelaskan cara membangun alur persetujuan internal yang terstruktur agar keputusan lebih cepat, transparan, dan terkontrol.

Mengapa bottleneck persetujuan terjadi (dan sulit terlihat)

Bottleneck kerap muncul ketika jalur persetujuan bergantung pada kebiasaan personal, bukan atas aturan proses. Akibatnya, tim tidak punya patokan sama tentang siapa yang berwenang memutuskan, kapan harus eskalasi, dan bukti apa yang wajib dilampirkan.

Gejalanya sering kali tampak seperti “orang A lambat”, padahal akar masalahnya ada pada desain proses. Misalnya, pengadaan menahan PO karena dokumen penawaran kurang lengkap, lalu bolak-balik tanpa checklist yang jelas.

Di perusahaan menengah hingga besar, kompleksitas bertambah karena banyak lapisan kontrol. Risiko meningkat: persetujuan longgar bisa memicu pembelian di luar kebijakan, sedangkan persetujuan terlalu ketat memperlambat operasi dan mendorong praktik pintas.

Merancang alur persetujuan yang memangkas waktu tunggu tapi tetap menjaga kontrol

Kunci utama adalah memisahkan “siapa memutuskan” dari “siapa menyiapkan”, lalu menetapkan aturan konsisten. Dengan begitu, keputusan tidak lagi terhambat oleh rantai pesan yang berulang dan setiap persetujuan punya jejak audit yang jelas.

Mulailah dengan memetakan keputusan yang paling sering menimbulkan antrean. Contoh umum: permintaan pembelian, kontrak vendor, diskon penjualan, perekrutan, perjalanan dinas, dan perubahan ruang lingkup proyek.

Selanjutnya, definisikan komponen dasar alur persetujuan:

  • Owner proses yang bertanggung jawab atas aturan dan pembaruan.
  • Jenis keputusan (misalnya CAPEX vs OPEX, kontrak baru vs perpanjangan).
  • Threshold berdasarkan nilai, risiko, atau kategori (contoh: di atas Rp250 juta perlu lapis tambahan).
  • Dokumen wajib seperti justifikasi bisnis, perbandingan vendor, atau ringkasan risiko.
  • SLA persetujuan, termasuk kapan sistem melakukan eskalasi.
  • Aturan substitusi saat approver cuti agar proses tidak berhenti total.

Seringkali yang terlupakan adalah menyederhanakan jalur normal dan menambah lapisan hanya untuk kondisi khusus. Misalnya, kontrak standar dengan vendor terdaftar bisa melewati review legal penuh, sedangkan kontrak non-standar harus melalui legal dan risk.

Pastikan juga ada mekanisme pre-check sebelum request sampai ke approver. Pre-check bisa dijalankan oleh admin proses atau sistem, misalnya menolak otomatis jika dokumen wajib belum lengkap, sehingga waktu pimpinan tidak terbuang untuk permintaan yang belum siap.

Implementasi: kontrol akses, eskalasi, dan metrik untuk pengambil keputusan

Setelah desain disepakati, tantangan berikutnya adalah menjalankan proses konsisten lintas departemen. Di tahap ini, kebijakan, kontrol akses, dan pengukuran kinerja menentukan keberhasilan.

1) Kontrol akses berbasis peran (role-based) membantu memastikan hanya pihak berwenang yang dapat menyetujui atau mengubah parameter penting. Jika organisasi Anda menata ulang hak akses dan delegasi, rujukan seperti panduan penguatan kontrol akses pada sistem persetujuan internal (internal approval workflow) dapat membantu menyelaraskan praktik IT dan kebijakan operasional.

2) Eskalasi yang jelas mencegah request menggantung tanpa pengejaran manual. Misalnya, jika tidak ada respons dalam 24 jam kerja, notifikasi kedua dikirim; jika 48 jam, permintaan otomatis dialihkan ke atasan langsung atau pengganti yang ditunjuk.

3) Audit trail dan alasan keputusan membuat persetujuan lebih dapat dipertanggungjawabkan, terutama untuk pengeluaran besar atau keputusan berisiko. Simpan ringkasan alasan setuju/tolak, catatan revisi, dan versi dokumen yang disetujui agar tidak ada kebingungan soal versi final.

4) Standarisasi data input mengurangi pertanyaan berulang. Form yang baik memaksa informasi penting muncul sejak awal, misalnya kode biaya, periode kontrak, vendor, dan dampak finansial, sehingga approver tidak perlu bolak-balik meminta detail tambahan.

Untuk memantau apakah bottleneck turun, gunakan metrik yang mudah dibaca dan relevan bagi pimpinan:

  • Cycle time per jenis keputusan (median sering lebih informatif daripada rata-rata).
  • Jumlah rework (berapa kali request dikembalikan untuk perbaikan).
  • Backlog persetujuan per approver atau departemen.
  • Exception rate (berapa banyak permintaan yang melewati jalur khusus atau eskalasi).
  • Compliance rate terhadap dokumen wajib dan threshold.

Jika metrik menunjukkan kemacetan pada satu titik, jangan langsung menambah approver. Sering kali solusi lebih efektif adalah memperjelas kriteria keputusan, menambah pre-check, atau membagi kategori agar beban tidak menumpuk pada satu meja.

Contoh skenario sederhana: tim sales meminta diskon tambahan untuk deal besar. Dengan aturan threshold dan template justifikasi baku, permintaan di bawah batas tertentu dapat disetujui kepala sales, sementara diskon di atas batas memerlukan persetujuan finance dan direktur, lengkap dengan proyeksi margin, sehingga tidak ada tarik-ulur data di menit terakhir.

Pada akhirnya, alur persetujuan yang efektif bukan soal menambah langkah, melainkan menempatkan langkah yang tepat pada keputusan yang tepat. Saat hak akses, eskalasi, dan data input distandarkan, waktu tunggu berkurang, keputusan lebih konsisten, dan risiko operasional lebih terkendali.

Luangkan waktu 30 menit untuk memetakan tiga keputusan yang paling sering macet dan penyebabnya.

Pelajari lebih lanjut tentang solusi kami di Epruvo