Pernah merasa proses persetujuan makin ramai di chat, tetapi keputusan tetap lambat dan sulit ditelusuri? Di banyak organisasi, persetujuan yang tidak tertata meningkatkan risiko salah bayar, ruang lingkup kerja yang meluas, atau perubahan teknis tanpa jejak audit, dan dengan rancangan yang tepat, workflow persetujuan bisa ketat untuk hal kritis namun luwes untuk pekerjaan harian. Artikel ini membantu Anda menyusun kerangkanya.
Mulai dari peta keputusan: apa yang perlu disetujui, siapa yang berwenang, dan kapan
Kontrol yang baik bukan soal menambah lapisan persetujuan, melainkan membuat definisi keputusan yang jelas. Langkah pertama adalah memetakan jenis keputusan yang benar-benar perlu otorisasi, lalu menetapkan pemilik keputusan berdasarkan risiko dan dampaknya.
Untuk memulai, kumpulkan 10–20 transaksi atau perubahan terakhir yang sering menimbulkan friksi, misalnya permintaan pembelian mendadak, perubahan timeline proyek, atau permintaan akses sistem. Dari situ, kategorikan keputusan menjadi beberapa kelas agar alurnya konsisten.
- Finansial: pembelian, reimburse, pembayaran vendor, penyesuaian anggaran.
- Operasional: perubahan jadwal, perubahan ruang lingkup kerja, penggunaan aset.
- TI dan keamanan: akses aplikasi, perubahan konfigurasi, deployment, integrasi data.
- SDM: lembur, penugasan, perjalanan dinas.
Setelah kelas keputusan terbentuk, tentukan tiga komponen inti: ambang (batas nilai atau dampak), penyetujui (pemilik otorisasi), dan SLA (batas waktu respons). Contoh sederhana: pembelian di bawah Rp5 juta disetujui manajer unit dalam 1 hari kerja, sedangkan di atas itu perlu persetujuan keuangan dengan SLA 2 hari kerja.
Terakhir, tempatkan momen persetujuan sedekat mungkin dengan titik keputusan, bukan setelah pekerjaan berlangsung. Cara ini mengurangi rework, terutama untuk perubahan teknis yang jika disetujui terlambat akan memicu rollback atau penyesuaian kontrak.
Menyelaraskan kontrol dengan fleksibilitas lewat aturan dan pengecualian yang terukur
Fleksibilitas bukan berarti semua serba cepat, melainkan ada jalur yang sesuai untuk setiap kondisi. Kuncinya membuat aturan baku untuk 80 persen kasus dan jalur pengecualian yang terdokumentasi untuk 20 persen sisanya.
Agar tidak kaku, gunakan pendekatan berbasis risiko. Semakin tinggi risiko finansial, kepatuhan, atau keamanan informasi, semakin ketat kontrol yang diperlukan, misalnya persetujuan berlapis atau persyaratan lampiran.
- Jalur cepat untuk permintaan berulang yang risikonya rendah dan sudah punya anggaran.
- Jalur normal untuk permintaan standar dengan kelengkapan dokumen minimum.
- Jalur pengecualian untuk kondisi darurat, dengan alasan tertulis dan review pasca kejadian.
- Delegasi terkontrol saat penyetujui cuti, dengan batas nilai dan periode yang jelas.
Misalnya di tim proyek, perubahan scope kecil yang tidak memengaruhi biaya dan timeline cukup disetujui project manager. Namun perubahan yang memengaruhi deliverable harus naik ke steering committee. Di sisi TI, permintaan akses sementara dapat dipercepat jika pemilik aplikasi menyetujui dan tanggal kedaluwarsa akses ditetapkan sejak awal.
Jalur pengecualian sering disalahgunakan karena tidak ada batas. Terapkan guardrail sederhana: setiap pengecualian wajib menyebutkan risiko yang diterima, siapa yang menyetujui, dan kapan akan dievaluasi. Dengan itu fleksibilitas tetap terlihat dan bisa diaudit.
Mendesain alur yang bisa diaudit tanpa memperlambat kerja harian
Auditability tidak selalu berarti banyak formulir. Yang penting adalah jejak keputusan yang konsisten: siapa meminta, apa yang diminta, alasan, bukti pendukung, siapa menyetujui, kapan, dan apa hasilnya.
Mulailah dari standar data minimum yang wajib ada di setiap permintaan. Praktiknya, tim operasional biasanya butuh deskripsi, nilai, vendor atau pihak terkait, pusat biaya, dan tanggal kebutuhan; tim TI sering menambahkan sistem terdampak, tingkat risiko, dan rencana rollback.
Untuk menjaga kecepatan, hindari meminta lampiran yang tidak relevan. Contoh: untuk pembelian kecil cukup lampirkan penawaran atau tautan katalog; untuk pembelian besar tambah analisis pembanding, justifikasi bisnis, dan persyaratan kontrak.
Bagian penting lainnya adalah mengurangi bolak-balik karena informasi kurang. Buat validasi di awal, seperti kolom wajib, format nilai, dan pilihan kategori, sehingga penyetujui menerima permintaan yang siap diputuskan.
Jika organisasi Anda mulai menata ini secara sistematis, rujukan seperti kerangka akuntabilitas dalam sistem persetujuan bisa membantu menyamakan istilah, peran, dan bukti yang perlu disimpan. Fokusnya bukan menambah birokrasi, melainkan memperjelas tanggung jawab agar keputusan bisa dipertanggungjawabkan.
Terakhir, tetapkan kebijakan retensi sederhana untuk catatan persetujuan, terutama yang terkait pembayaran, kontrak, dan akses sistem. Di Indonesia, kebutuhan retensi bisa mengikuti kebijakan internal dan ketentuan audit perusahaan, jadi pastikan sinkron dengan fungsi keuangan, legal, dan keamanan informasi.
Implementasi dan perbaikan berkelanjutan: metrik, bottleneck, dan perubahan perilaku
Workflow yang rapi di atas kertas bisa gagal bila tidak ada metrik. Pilih indikator yang mudah diukur dan langsung relevan dengan pekerjaan, sehingga tim bisa melihat dampaknya tanpa menunggu audit tahunan.
- Lead time persetujuan: rata-rata waktu dari request dibuat sampai keputusan keluar.
- Persentase kelengkapan awal: persentase permintaan yang tidak dikembalikan karena data kurang.
- Volume pengecualian: seberapa sering jalur darurat dipakai dan alasannya.
- Rework cost: biaya atau jam kerja akibat persetujuan terlambat.
- Kontrol akses: jumlah akses kedaluwarsa yang benar-benar dicabut tepat waktu.
Saat bottleneck muncul, cari akar masalah sebelum menambah penyetujui baru. Jika waktu persetujuan panjang karena penyetujui tidak punya konteks, solusi yang lebih efektif adalah memperbaiki template permintaan, menambahkan ringkasan risiko, atau menetapkan SLA yang realistis.
Perubahan perilaku juga penting. Buat aturan sederhana tentang komunikasi: diskusi boleh terjadi di chat, tetapi keputusan final harus tercatat di workflow, lengkap dengan alasan singkat agar tidak hilang saat anggota tim berganti.
Untuk tim TI, selaraskan workflow dengan proses perubahan seperti change request dan incident. Contoh praktis: incident kritis boleh lewat jalur darurat, tetapi wajib ada post-incident review yang menghasilkan tindakan perbaikan, termasuk penyesuaian kontrol agar kejadian tidak berulang.
Pada akhirnya, kontrol dan fleksibilitas bisa berjalan bersama jika keputusan diklasifikasikan dengan benar, jalur pengecualian dibatasi, dan jejak audit dibuat ringan namun konsisten. Dengan begitu, operasional lebih cepat, risiko lebih terkendali, dan kolaborasi lintas fungsi terasa lebih mulus.
Pilih satu proses yang paling sering macet, lalu rapikan alurnya minggu ini untuk mendapatkan dampak cepat.
Telusuri contoh alur persetujuan di https://epruvo.com