Pernah melihat satu permintaan persetujuan atau workflow persetujuan internal “nyangkut” berhari-hari karena penanggung jawabnya sedang cuti atau bingung siapa yang harus memutuskan? Eskalasi yang dirancang dengan baik menjaga alur persetujuan tetap bergerak tanpa mengorbankan kontrol. Dengan begitu tim operasional, project manager, dan tim TI bisa mempertahankan SLA, kualitas keputusan, serta jejak audit yang rapi.
Kenapa eskalasi perlu dirancang, bukan sekadar tombol “forward”
Di praktik di Indonesia, persetujuan internal sering terkait pengeluaran, perubahan ruang lingkup proyek, akses sistem, atau pengecualian kontrol. Bila eskalasi tidak jelas, dua risiko umum muncul: pekerjaan terhenti atau keputusan dibuat oleh pihak yang tidak punya mandat. Desain eskalasi yang baik mencegah kedua masalah itu.
Eskalasi yang sehat menjelaskan kapan sebuah permintaan harus “naik level”, siapa yang berhak memutuskan, dan apa yang perlu didokumentasikan. Hasilnya lebih cepat, konsisten, dan mudah ditelusuri saat audit internal atau evaluasi pascaproyek.
7 skenario eskalasi yang paling sering muncul
Berikut tujuh skenario umum, lengkap dengan pemicu (trigger) yang bisa Anda jadikan aturan otomatis atau pedoman operasional. Mulailah dari skenario yang paling sering terjadi di unit Anda, lalu tambah detail berdasarkan data keterlambatan dan titik bottleneck.
Skenario 1–4: eskalasi karena waktu, kapasitas, dan ketidakjelasan
- Skenario 1: Batas waktu terlewati (SLA breach). Pemicunya sederhana: belum ada keputusan sampai waktu yang ditetapkan. Eskalasi sebaiknya diarahkan ke atasan approver atau peran “duty approver” agar keputusan tetap memiliki otoritas.
- Skenario 2: Approver tidak tersedia. Contoh: cuti, perjalanan dinas, atau akun nonaktif. Terapkan aturan delegasi yang sudah disetujui sebelumnya dan catat siapa delegator, periode delegasi, serta cakupannya.
- Skenario 3: Beban antrean terlalu tinggi. Misalnya satu manajer menerima 40 permintaan akses per hari sehingga antrean menumpuk. Solusi bukan selalu menaikkan level, melainkan mendistribusikan ulang ke approver cadangan atau memakai rotasi berdasarkan tim atau area.
- Skenario 4: Permintaan tidak jelas atau tidak lengkap. Ini lebih ke eskalasi untuk koreksi dari pemohon. Pemicunya bisa dokumen pendukung kosong, rincian biaya tidak diisi, atau justifikasi risiko yang belum lengkap.
Skenario 5–7: eskalasi karena risiko, konflik, dan batas kewenangan
- Skenario 5: Melewati batas kewenangan (authority limit). Contoh: pengadaan di atas nominal tertentu atau perubahan kontrak yang memperpanjang durasi. Trigger harus berbasis parameter objektif seperti nilai, kategori, atau dampak, lalu diarahkan ke level yang punya mandat.
- Skenario 6: Konflik kepentingan atau independensi. Misalnya approver adalah pemilik vendor, anggota tim yang mendapat manfaat langsung, atau reviewer yang terlibat membuat permintaan. Trigger bisa berupa flag manual dari compliance atau otomatis berdasarkan relasi organisasi, lalu dialihkan ke pihak independen.
- Skenario 7: Ketidaksepakatan antar fungsi (deadlock). Contoh: Operasional menyetujui, Keuangan menolak karena anggaran, dan TI menahan karena risiko keamanan. Di sini diperlukan forum atau peran pemutus, misalnya steering committee atau risk owner, dengan kriteria keputusan yang jelas.
Jika Anda ingin memperkuat jejak keputusan dan memudahkan penelusuran saat pemeriksaan internal, rujukan tentang transparansi dan audit trail bisa membantu, misalnya pada pembahasan transparansi dan audit dalam proses persetujuan.
Peran yang perlu ada: pemilik keputusan, penjaga proses, dan pengelola risiko
Kegagalan eskalasi biasanya bukan karena sistem, melainkan karena definisi peran yang kabur. Untuk menjaga alur cepat dan akuntabel, setidaknya bedakan tiga kelompok peran dengan tegas.
1) Pemilik keputusan (decision owner). Pihak ini berwenang menyetujui atau menolak sesuai kebijakan dan batas kewenangan. Pastikan keputusan mereka terekam beserta alasan singkat, terutama untuk pengecualian.
2) Penjaga proses (process owner/administrator). Mereka tidak memutuskan isi, tetapi memastikan tiket tidak macet, aturan routing benar, dan delegasi berlaku. Tim TI sering bertanggung jawab pada konfigurasi, notifikasi, integrasi, dan kontrol akses.
3) Pengelola risiko dan kepatuhan (risk/compliance/security). Peran ini memberi review atau approval gate pada kondisi tertentu, misalnya akses ke data sensitif, perubahan konfigurasi produksi, atau vendor baru. Mereka juga menetapkan kapan konflik kepentingan atau deadlock harus dibawa ke forum yang lebih tinggi.
Agar jelas, susun matriks RACI yang ringkas untuk jenis permintaan utama. Misalnya pada permintaan akses sistem: requester (R), atasan langsung (A), pemilik aplikasi (C), keamanan informasi (C/A untuk akses tertentu), admin workflow (I).
Praktik implementasi agar eskalasi konsisten dan tidak menambah birokrasi
Mulailah dari data: jenis permintaan mana yang paling sering terlambat, di langkah mana, dan apa penyebabnya. Dari situ tetapkan aturan eskalasi yang sedikit namun kuat, lalu uji selama dua sampai empat minggu sebelum diperluas.
Gunakan trigger terukur seperti durasi tunggu, nilai rupiah, klasifikasi data, atau tingkat perubahan (minor/major). Hindari aturan yang bergantung pada interpretasi semata karena sulit diautomasi dan rawan diperdebatkan.
Pastikan setiap eskalasi menghasilkan salah satu dari tiga output: keputusan, permintaan perbaikan data, atau pemindahan ke peran yang tepat. Jika eskalasi hanya memindahkan antrean tanpa perubahan kewenangan atau informasi, alur akan tetap macet.
Siapkan standar catatan keputusan yang singkat: alasan, referensi dokumen, dan kondisi pengecualian jika ada. Ini membantu project manager saat evaluasi dampak dan tim TI saat menelusuri perubahan akses atau konfigurasi.
Dengan skenario eskalasi yang jelas dan peran yang tegas, persetujuan internal menjadi lebih cepat, konsisten, dan mudah diaudit.
Diskusikan skenario mana yang paling sering terjadi, lalu tetapkan satu aturan eskalasi untuk diuji minggu ini.
Telusuri contoh alur persetujuan di https://epruvo.com