Di banyak organisasi, eskalasi sering terjadi bukan karena orangnya “salah”, melainkan karena keputusan tersendat, konteks hilang, atau batas kewenangan tidak jelas. Ketika persetujuan melibatkan terlalu banyak pihak atau justru melewatkan pemilik risiko, dampaknya bisa berupa keterlambatan proyek, konflik antar tim, dan temuan audit. Dengan workflow yang dirancang baik, Anda bisa menurunkan kemungkinan eskalasi secara signifikan sambil tetap menjaga kecepatan eksekusi.
Pembahasan ini memetakan cara kerja workflow persetujuan yang efektif, titik rawan yang sering memicu eskalasi, dan langkah desain praktis yang bisa diterapkan pada proses operasional serta proyek TI. Contoh yang dipakai dekat dengan realitas kerja di Indonesia, seperti pengadaan sederhana, perubahan scope, dan approval akses sistem.
Kenali pemicu eskalasi yang paling sering muncul
Eskalasi biasanya diawali oleh ketidakpastian: siapa yang berwenang memutuskan, informasi apa yang wajib tersedia, dan kapan keputusan harus keluar. Saat ketiga hal ini tidak tegas, orang cenderung melempar keputusan ke atas untuk menghindari risiko pribadi. Akibatnya, atasan menerima isu yang sebenarnya bisa diselesaikan di level operasional.
Beberapa pemicu umum sering muncul bersamaan sehingga eskalasi terasa mendadak padahal akumulasinya sudah lama. Mengidentifikasi pola ini membantu membuat perbaikan workflow yang menargetkan akar masalah, bukan sekadar menambah lapisan persetujuan.
- Matriks kewenangan kabur: nilai transaksi, dampak risiko, atau perubahan scope tidak punya batas yang disepakati.
- Kualitas input lemah: permintaan approval datang tanpa data minimum (biaya, risiko, alternatif, atau dampak operasional).
- Approval overload: terlalu banyak approver “sekadar diketahui”, membuat waktu tunggu panjang dan tanggung jawab menjadi samar.
- Tidak ada SLA keputusan: permintaan menggantung, lalu meledak saat tenggat sudah dekat.
- Jejak keputusan tidak rapi: sulit membuktikan alasan keputusan, memicu debat ulang dan gesekan lintas fungsi.
- Jalur eskalasi tidak tertulis: ketika macet, tim tidak tahu harus naik ke siapa dan dengan format apa.
Contoh sederhana: project manager mengajukan perubahan scope kecil tetapi tidak ada definisi jelas tentang “kecil” dan “besar”. Approver menunda karena khawatir dampaknya tidak terlihat, lalu saat jadwal terancam barulah isu naik ke steering committee.
Rancang workflow yang jelas: dari otoritas sampai data minimum
Workflow persetujuan internal yang menurunkan eskalasi biasanya dimulai dari dua fondasi: siapa yang memutuskan dan informasi apa yang membuat keputusan aman. Jika fondasi ini kuat, keputusan menjadi lebih cepat, mudah dipertanggungjawabkan, dan jarang diperdebatkan ulang. Fokusnya bukan memperbanyak kontrol, melainkan membuat kontrol yang tepat sasaran.
Pertama, tetapkan approval matrix yang mengikat dan mudah dipakai. Praktiknya bisa berupa tabel ringkas: tipe keputusan (mis. pengeluaran, perubahan scope, akses data), level risiko, dan batas nominal atau dampak yang menentukan approver utama serta pihak yang wajib dikonsultasikan.
Untuk proyek TI, gunakan kombinasi dampak layanan dan risiko keamanan. Misalnya, perubahan konfigurasi yang memengaruhi sistem produksi dan menyentuh data sensitif memerlukan persetujuan pemilik aplikasi dan keamanan informasi, sedangkan perubahan minor pada laporan internal cukup ditangani pemilik proses.
Kedua, terapkan quality gate berupa data minimum sebelum permintaan masuk antrean approval. Alih-alih dokumen panjang, gunakan daftar isian singkat yang memaksa pemohon menyertakan informasi krusial.
- Tujuan permintaan dan opsi alternatif (minimal satu alternatif bila relevan).
- Estimasi biaya dan waktu serta dampak pada SLA operasional.
- Risiko utama dan mitigasi ringkas (mis. rencana rollback untuk perubahan TI).
- Pihak terdampak dan rencana komunikasi.
Ketiga, bedakan approver dan reviewer. Reviewer memastikan kelengkapan atau kepatuhan, sedangkan approver memiliki mandat risiko dan anggaran untuk mengambil keputusan akhir.
Keempat, gunakan konsep RACI atau setidaknya definisi tanggung jawab yang jelas. Jika peran Responsible dan Accountable tertukar, diskusi mudah memanas karena semua merasa harus mengendalikan keputusan.
Jika Anda sedang membenahi struktur ini dari nol, rujukan praktis tentang elemen-elemen sistem persetujuan dapat membantu menyusun standar yang konsisten, misalnya melalui pembahasan pada sistem persetujuan internal untuk mengurangi risiko keputusan. Pastikan hasil akhirnya disesuaikan dengan konteks unit kerja, jenis risiko, dan budaya pengambilan keputusan di organisasi Anda.
Bangun mekanisme pencegahan macet: SLA, eskalasi terarah, dan audit trail
Workflow yang jelas tetap bisa macet jika tidak ada mekanisme pencegahan. Karena itu, pencegahan macet harus menjadi bagian inti. Kombinasinya paling efektif berupa SLA keputusan, jalur eskalasi spesifik, dan pencatatan yang rapi.
Mulailah dengan SLA approval yang realistis, misalnya satu hari kerja untuk keputusan berisiko rendah dan tiga hari kerja untuk yang berdampak sedang. SLA ini sebaiknya dilengkapi aturan: jika approver tidak merespons dalam periode tertentu, permintaan otomatis naik ke delegasi yang ditunjuk atau masuk agenda rapat keputusan terjadwal.
Buat jalur eskalasi terarah, bukan eskalasi kepada siapa saja yang paling senior. Jalur yang baik menetapkan kondisi pemicu (mis. melewati SLA, konflik antar fungsi, atau peningkatan risiko), tujuan eskalasi (pemilik anggaran, risk owner, atau komite), dan paket informasi yang wajib dibawa agar tidak mengulang diskusi dari awal.
Audit trail sering diremehkan, padahal ini kunci menurunkan eskalasi berbasis persepsi. Ketika alasan keputusan, pertimbangan risiko, dan pihak yang menyetujui tercatat konsisten, potensi konflik “katanya” jauh berkurang, terutama saat ada pergantian personel atau evaluasi pasca insiden.
Dalam praktik operasional, audit trail tidak harus rumit. Cukup pastikan setiap keputusan memiliki tanggal, versi permintaan, ringkasan pertimbangan, dan catatan perubahan jika ada revisi.
Praktik operasional: contoh penerapan pada proyek dan proses harian
Ujilah workflow pada dua sampai tiga proses yang paling sering menimbulkan ketegangan lintas tim. Pilih proses yang frekuensinya tinggi dan berdampak nyata, seperti pengadaan mendadak, perubahan scope proyek, atau permintaan akses sistem. Dari situ, Anda bisa menyempurnakan aturan sebelum memperluas ke proses lain.
Contoh 1: perubahan scope proyek. Definisikan ambang “perubahan minor” berdasarkan kombinasi biaya tambahan dan dampak jadwal; misalnya hingga Rp25 juta dan mundur maksimal tiga hari kerja masih bisa diputuskan di level manajer unit. Di atas itu, harus melibatkan sponsor proyek dan pemilik anggaran, dengan ringkasan risiko dan opsi trade-off yang jelas.
Contoh 2: pengadaan kecil yang sering urgent. Banyak eskalasi muncul karena permintaan datang mendadak tanpa justifikasi. Terapkan data minimum (kebutuhan, vendor alternatif, dan konsekuensi jika ditunda), lalu sediakan jalur fast-track hanya untuk kategori tertentu yang sudah disepakati, misalnya kebutuhan keamanan atau kelangsungan layanan.
Contoh 3: approval akses TI. Audit akses sering sensitif karena menyangkut pemisahan tugas dan risiko penyalahgunaan. Workflow yang baik meminta pemohon menyebutkan peran yang dibutuhkan, durasi akses, serta persetujuan pemilik aplikasi; tim keamanan informasi cukup menjadi reviewer untuk akses standar tetapi menjadi approver untuk akses istimewa.
Terakhir, lakukan kalibrasi berkala dengan data sederhana: waktu rata-rata approval, persentase permintaan yang kembali karena data kurang, dan titik paling sering macet. Dengan metrik ringan ini, diskusi perbaikan jadi objektif dan eskalasi emosional cenderung turun.
Dengan matriks kewenangan yang tegas, input yang terstandar, dan mekanisme anti-macet, eskalasi berubah dari kebiasaan menjadi pengecualian yang terkelola.
Jika Anda ingin, buat satu proses pilot minggu ini dan evaluasi hasilnya setelah dua siklus persetujuan.
Telusuri contoh alur persetujuan di https://epruvo.com