Pernah mengalami dokumen sudah siap jalan, tetapi proyek tetap tertahan karena menunggu satu orang menyetujui? Masalahnya sering bukan pada orangnya, melainkan pada rancangan alur persetujuan yang terlalu kaku, tidak transparan, dan sulit beradaptasi saat kondisi berubah. Tulisan ini membantu Anda memetakan sumber bottleneck dan merancang alur persetujuan yang lebih cepat tanpa mengorbankan kontrol, akuntabilitas, dan kebutuhan audit internal.
Kenali sumber bottleneck: bukan sekadar siapa yang lambat
Bottleneck persetujuan biasanya muncul dari kombinasi proses yang panjang, struktur organisasi, dan kualitas informasi yang diterima oleh approver. Jika hanya mengejar individu yang terlambat, masalah akan berulang karena akar penyebabnya tidak tertangani.
Satu pola yang sering muncul adalah terlalu banyak titik persetujuan untuk risiko yang rendah. Misalnya, pembelian rutin di bawah Rp5 juta masih harus melewati tiga level walau kebijakan sudah memberi batas kewenangan yang jelas.
Pola lain adalah ketergantungan pada satu orang yang sering rapat atau dinas. Tanpa delegasi resmi, sistem memaksa semua orang menunggu hingga pekerjaan menumpuk di akhir pekan atau akhir bulan.
Ada pula bottleneck yang tampak seperti kelambatan, padahal sebenarnya berputar karena form tidak lengkap, lampiran kurang, atau alasan permintaan tidak jelas. Approver lalu meminta revisi berkali-kali sehingga siklus waktu meluas.
Kurangnya visibilitas status juga menyulitkan tim operasional dan manajer proyek untuk mengeskalasi dengan tepat. Tanpa jejak yang rapi, tim TI kesulitan membedakan apakah hambatan disebabkan konfigurasi, integrasi, atau perilaku pengguna.
Rancang alur fleksibel: berbasis risiko, ambang batas, dan peran
Alur fleksibel (workflow persetujuan internal) bukan berarti lepas kontrol, alur harus menyesuaikan rute persetujuan berdasarkan tingkat risiko dan konteks pekerjaan. Prinsipnya sederhana: semakin standar dan rendah risikonya, semakin singkat jalurnya.
Mulailah dengan mengelompokkan jenis permintaan yang paling sering menimbulkan antrean, misalnya pengadaan, perjalanan dinas, perubahan scope proyek, atau permintaan akses sistem. Untuk setiap kelompok, tentukan atribut penentu rute seperti nilai, jenis biaya (CAPEX/OPEX), vendor baru versus vendor terdaftar, serta dampak pada data atau keamanan.
Terapkan ambang batas kewenangan yang jelas agar alur tidak selalu naik ke level tertinggi. Contohnya, pembelian operasional di bawah batas tertentu cukup disetujui pemilik cost center, sementara vendor baru atau kontrak multi-tahun memerlukan persetujuan legal dan finance.
Pakai persetujuan berbasis peran agar rotasi jabatan tidak merusak alur. Dengan pendekatan ini, alur mengarah ke peran seperti Kepala Departemen Operasional atau Information Security Officer, bukan ke nama orang tertentu.
Siapkan mekanisme delegasi dan backup approver yang terdokumentasi. Delegasi sebaiknya punya batas waktu, ruang lingkup, dan jejak audit jelas sehingga keputusan tetap bisa dipertanggungjawabkan.
Untuk beberapa kasus, pertimbangkan jalur paralel daripada berurutan. Misalnya, review legal dan finance untuk kontrak bisa dilakukan bersamaan sebelum persetujuan akhir pemilik anggaran sehingga lead time berkurang tanpa mengorbankan kualitas.
Jika Anda ingin mengukur dampak perubahan alur, indikator kinerja yang tepat membantu. Sebagai rujukan, lihat artikel KPI yang menunjukkan nilai sistem persetujuan internal, sehingga diskusi perbaikan berlandas data, bukan opini semata.
Standarkan input agar approver bisa cepat memutuskan
Approver bekerja paling cepat ketika konteks lengkap dan konsisten. Memperbaiki kualitas permintaan sering memberi dampak setara dengan memangkas level persetujuan.
Gunakan form yang mengharuskan informasi penting seperti tujuan bisnis, urgensi, dampak jika ditunda, dan rincian biaya. Untuk pengadaan, sertakan perbandingan penawaran atau alasan single-source bila hanya ada satu vendor.
Tentukan aturan lampiran yang sederhana tetapi tegas. Misalnya, kontrak wajib menyertakan draft, scope, dan termin pembayaran; permintaan akses sistem wajib menyertakan pemilik aplikasi, periode akses, dan justifikasi peran.
Sediakan ringkasan satu layar untuk approver, khususnya pimpinan yang menerima banyak permintaan. Ringkasan ini bisa mencakup total biaya, ketersediaan anggaran, risiko utama, serta rekomendasi pemilik proses sehingga keputusan tidak terhambat membuka banyak dokumen.
Gunakan komentar terstruktur untuk mengurangi percakapan yang tersebar di chat. Jika alasan penolakan atau revisi dikategorikan (misalnya “kurang lampiran,” “melewati anggaran,” “perlu review keamanan”), tim bisa melihat pola dan memperbaiki proses dari hulu.
Operasionalisasi: SLA, eskalasi, dan audit trail yang rapi
Alur yang baik tetap bisa macet tanpa aturan eksekusi yang jelas. Di banyak organisasi, hambatan terbesar muncul karena tidak ada kesepakatan soal batas waktu respon dan jalur eskalasi.
Tetapkan SLA per jenis permintaan, bukan satu angka untuk semua. Misalnya, persetujuan biaya rutin bisa ditargetkan selesai dalam 1 hari kerja, sementara kontrak vendor baru membutuhkan 5–10 hari kerja karena review lebih mendalam.
Aktifkan pengingat otomatis dan eskalasi bertahap yang proporsional. Eskalasi pertama sebaiknya mengarah ke backup approver atau atasan langsung setelah batas waktu, bukan langsung mengirim notifikasi ke banyak orang.
Pastikan audit trail mencatat siapa menyetujui, kapan, versi dokumen yang disetujui, dan alasan perubahan. Catatan ini penting untuk investigasi, pembelajaran proses, dan mengurangi perdebatan saat miskomunikasi terjadi.
Di sisi TI, lakukan change management untuk semua konfigurasi alur. Setiap perubahan aturan perlu catatan tujuan, tanggal berlaku, dan pihak yang menyetujui, sehingga troubleshooting tidak bergantung pada ingatan individu.
Lakukan review berkala berbasis data, misalnya bulanan untuk proses ber-volume tinggi dan kuartalan untuk proses kompleks. Fokus review pada waktu siklus, jumlah revisi, anomali eskalasi, dan beban persetujuan per peran, lalu sesuaikan aturan agar tetap relevan.
Dengan memetakan sumber hambatan, merancang rute berbasis risiko, menstandarkan input, dan menegakkan SLA, persetujuan bisa lebih cepat sekaligus lebih tertib. Hasil akhirnya biasanya terlihat pada proyek yang lebih lancar, keputusan yang lebih konsisten, dan jejak audit yang lebih mudah ditelusuri.
Luangkan 30 menit minggu ini untuk memetakan satu alur yang paling sering macet dan perbaiki satu aturan saja.
Telusuri contoh alur persetujuan di https://epruvo.com