Setiap keputusan harus melewati approval — dari pengeluaran kecil hingga deal besar. Ketika level approval tidak proporsional dengan risiko keputusan, proses persetujuan menjadi bottleneck yang menghambat eksekusi dan membuang waktu organisasi.
Approval bottleneck adalah titik di mana proses persetujuan melambat karena level approval tidak proporsional dengan risiko keputusan - pengeluaran kecil harus lewat jalur yang sama dengan keputusan besar. Eksekusi pun terhambat dan waktu organisasi habis untuk menunggu tanda tangan. Tanda tangan tidak menambah kualitas keputusan, ia hanya menambah latency dan orang yang terlibat.
Pengeluaran kecil memerlukan approval direktur, meskipun sudah ada budget.
Deal sudah disepakati customer tetapi tertahan menunggu approval pricing dari atas.
Tim sudah siap eksekusi tetapi harus menunggu approval yang tidak kunjung datang.
Setiap kali ada permintaan khusus, semua harus eskalasi ke pimpinan.
Proses approval memiliki banyak tahap yang sama untuk keputusan besar dan kecil.
Marketing menunggu approval konten dari founder, meskipun konten sudah sesuai brand guideline.
Banyak email dan dokumen yang menunggu "approved" atau "disetujui".
Deal dan kontrak tertunda karena proses approval yang lambat.
Tim merasa frustrasi karena harus menunggu approval untuk hal yang sepele.
Pimpinan kewalahan karena semua keputusan harus melalui mereka.
Meeting diadakan hanya untuk membahas status approval.
Keputusan yang sama memerlukan approval dari beberapa orang yang berbeda.
Approval bottleneck terjadi ketika proses persetujuan menjadi tidak proporsional dengan risiko dan dampak keputusan. Bukan berarti approval itu buruk — beberapa keputusan memang memerlukan approval karena risiko, nilai, implikasi hukum, atau dampak strategis. Masalahnya adalah ketika keputusan kecil terjebak dalam approval level yang tinggi, atau ketika approval menjadi mekanisme kontrol yang menggantikan decision ownership yang jelas.
Organisasi menggunakan approval sebagai mekanisme kontrol utama. Daripada menentukan decision rights yang jelas, semua keputusan harus melalui approval untuk memastikan "tidak ada yang salah."
Tidak ada aturan yang jelas tentang kebutuhan approval berdasarkan risiko, nilai, atau jenis keputusan. Akibatnya, semua keputusan dianggap memerlukan approval yang sama.
Pimpinan takut keputusan yang salah akan berdampak besar. Daripada menetapkan batas, mereka memilih untuk approve semua keputusan.
Orang yang approve belum tentu yang bertanggung jawab atas hasil. Ini menciptakan ketidakseimbangan di mana approval menjadi formalitas, bukan mekanisme akuntabilitas.
Dulu, memang semua harus approval karena organisasi masih kecil. Kebiasaan ini terus berlanjut meskipun organisasi sudah bertumbuh.
Di mana approval diperlukan dalam alur keputusan? Berapa banyak tahap approval yang ada? Di mana keputusan menunggu approval? Di mana ia kembali untuk perbaikan?
Siapa yang harus approve? Apakah level approval proporsional dengan risiko keputusan? Apakah ada decision rights yang jelas sebelum approval diperlukan?
Kapan keputusan harus eskalasi untuk approval? Apakah eskalasi itu perlu atau sudah menjadi kebiasaan? Apakah ada batas eskalasi yang jelas?
Keputusan kecil memerlukan approval dari level yang terlalu tinggi. Pengeluaran Rp 500 ribu harus approval direktur, meskipun sudah ada budget.
Keputusan harus melewati beberapa tahap approval yang berurutan. Setiap tahap menambah waktu tanpa menambah value.
Tidak ada threshold yang jelas. Semua keputusan, tanpa memandang risiko atau nilai, harus melalui proses approval yang sama.
Approval menjadi stempel formal daripada mekanisme kontrol yang bermakna. Yang approve tidak bertanggung jawab atas hasil.
Seorang Decision Architect tidak langsung menyarankan untuk "mengurangi approval." Yang pertama dilakukan adalah memahami approval flow: kebutuhan approval mana yang proporsional dengan risiko, kebutuhan approval mana yang berlebihan, dan kebutuhan approval mana yang belum ada tetapi seharusnya ada. Prosesnya: memahami situasi → menelusuri alur approval → membedakan approval yang necessary vs excessive → merancang threshold yang proporsional.
Jika approval bottleneck terjadi secara konsisten, melibatkan banyak jenis keputusan, dan tidak bisa diselesaikan hanya dengan mengubah individu atau prosedur — ini adalah masalah desain sistem keputusan. Decision Architecture relevan ketika approval menjadi mekanisme kontrol utama tanpa decision rights yang jelas, dan ketika level approval tidak proporsional dengan risiko keputusan.
Diagnosis dapat membantu memahami approval flow, membedakan approval yang necessary vs excessive, dan menentukan threshold yang proporsional.
Schedule a Discovery Call