Approval Matrix Procurement: Cara Menyusun Jenjang Persetujuan yang Tepat

Approval matrix adalah salah satu elemen procurement yang paling sering dianggap sudah "jelas dengan sendirinya" — semua orang tahu siapa yang biasanya menyetujui apa — sampai ada PO yang macet berhari-hari karena penyetuju sedang cuti dan tidak ada aturan pengganti. Ketiadaan struktur formal yang tertulis dan bisa dijalankan otomatis inilah yang membuat proses persetujuan menjadi titik lemah paling umum dalam procurement, jauh sebelum bicara soal sistem atau teknologi apa pun.

Apa Itu Approval Matrix dan Kenapa Perusahaan Distribusi Membutuhkannya

Approval matrix adalah aturan tertulis yang menetapkan siapa berwenang menyetujui pembelian sampai nilai berapa, dan jalur eskalasi apa yang berlaku kalau nilai tersebut terlampaui atau penyetuju yang ditunjuk tidak tersedia. Bagi distributor dengan banyak cabang, kategori barang, dan tingkat urgensi pembelian yang bervariasi, aturan ini menjadi penentu apakah proses pengadaan berjalan cepat dan terkendali, atau justru menjadi sumber kemacetan berulang.

Tanpa approval matrix yang jelas, dua masalah muncul bergantian: pembelian bernilai besar bisa lolos tanpa pengawasan yang memadai karena tidak ada batas wewenang yang tegas, atau sebaliknya, pembelian kecil pun harus menunggu persetujuan pejabat senior yang sebenarnya tidak perlu terlibat. Keduanya sama-sama merugikan — yang pertama soal risiko kontrol, yang kedua soal kecepatan operasional.

Prinsip Dasar Menyusun Jenjang Approval

Jenjang approval yang efektif dibangun dari beberapa prinsip dasar, bukan sekadar meniru struktur organisasi yang ada:

Wewenang mengikuti tanggung jawab, bukan jabatan semata. Seseorang diberi batas approval tertentu karena ia memikul akuntabilitas atas anggaran atau kategori pembelian itu, bukan karena posisinya di struktur organisasi.

Jumlah jenjang seminimal mungkin untuk tetap terkendali. Setiap jenjang tambahan berarti satu titik potensi keterlambatan lagi. Jenjang ditambahkan hanya kalau memang ada kebutuhan kontrol nyata di nilai tersebut, bukan karena "biasanya begitu di perusahaan lain".

Kategori pembelian bisa punya jalur berbeda. Pembelian barang operasional rutin dan pembelian aset atau kontrak jangka panjang wajar punya jenjang berbeda meski nilainya mirip, karena tingkat risikonya tidak sama.

Setiap jenjang harus punya pengganti (backup approver) yang ditetapkan di awal, bukan dicari secara ad hoc ketika penyetuju utama sedang tidak bisa dihubungi.

Menentukan Batas Nilai per Jenjang

Menentukan batas nilai (threshold) di tiap jenjang sebaiknya didasarkan pada data transaksi historis, bukan angka bulat yang terasa "pantas". Langkah praktisnya:

Kelompokkan histori pembelian berdasarkan rentang nilai, dan lihat di rentang mana volume transaksi paling padat — di situlah kecepatan proses paling krusial.

Tetapkan jenjang pertama (nilai terendah) untuk mencakup mayoritas transaksi rutin, dengan wewenang di level yang paling dekat dengan kebutuhan operasional — misalnya kepala gudang atau supervisor pembelian.

Jenjang berikutnya dinaikkan untuk transaksi yang mulai berdampak signifikan pada arus kas atau anggaran divisi, biasanya melibatkan manajer atau kepala divisi terkait.

Jenjang tertinggi dicadangkan untuk transaksi yang benar-benar material terhadap keuangan perusahaan secara keseluruhan, yang wajar melibatkan direksi.

Batas nilai ini bukan angka final selamanya — perlu ditinjau ulang secara berkala mengikuti pertumbuhan volume transaksi perusahaan, supaya jenjang yang dulu relevan tidak menjadi terlalu longgar atau terlalu ketat seiring waktu.

Kesalahan Umum yang Membuat Approval Matrix Gagal Jalan

Beberapa pola kesalahan berulang ditemukan di banyak perusahaan yang sudah punya approval matrix di atas kertas, tapi tetap mengalami hambatan di praktiknya:

Terlalu banyak jenjang. Semakin banyak orang yang harus dilibatkan sebelum PO bisa jalan, semakin besar peluang salah satu dari mereka menjadi titik hambatan — cuti, sedang rapat, atau sekadar telat membuka pesan. Setiap jenjang tambahan harus bisa dijustifikasi dengan alasan kontrol yang jelas, bukan kebiasaan.

Tidak ada eskalasi otomatis saat penyetuju tidak tersedia. Ini adalah kegagalan paling umum. Approval matrix yang hanya mendefinisikan "siapa menyetujui" tanpa mendefinisikan "apa yang terjadi kalau orang itu tidak merespons dalam waktu tertentu" pada akhirnya tetap bergantung pada proses manual mengejar tanda tangan — persis masalah yang seharusnya diselesaikan oleh approval matrix itu sendiri.

Batas nilai yang tidak pernah ditinjau ulang. Threshold yang ditetapkan bertahun-tahun lalu, saat volume transaksi perusahaan jauh lebih kecil, membuat jenjang atas kebanjiran approval yang sebetulnya sudah rutin dan tidak lagi berisiko tinggi.

Approval matrix tidak konsisten diikuti di semua cabang atau divisi. Kalau aturan hanya berlaku formal di kantor pusat tapi cabang punya kebiasaan sendiri, matrix itu kehilangan fungsinya sebagai kontrol yang seragam.

Approval Matrix yang Hidup: Eskalasi Otomatis dan Review Berkala

Approval matrix yang efektif bukan dokumen yang dibuat sekali lalu disimpan, melainkan aturan yang aktif dijalankan di setiap transaksi dan ditinjau secara berkala. Dua elemen yang membuatnya benar-benar berfungsi:

Eskalasi otomatis berbasis waktu — kalau penyetuju tidak merespons dalam jangka waktu tertentu, sistem secara otomatis meneruskan permintaan ke penyetuju pengganti atau ke jenjang berikutnya, tanpa perlu ada orang yang mengingatkan secara manual. Ini menghilangkan titik hambatan paling umum yang disebutkan di atas.

Review berkala terhadap struktur dan batas nilai, idealnya setiap enam hingga dua belas bulan, untuk memastikan jenjang yang ada masih relevan dengan skala dan kompleksitas transaksi perusahaan saat ini. Sebagian besar hambatan digitalisasi distribusi bersifat organisasi, bukan teknis — approval matrix yang tidak berjalan biasanya bukan karena sistemnya kurang canggih, tapi karena wewenang dan aturan eskalasinya tidak pernah didefinisikan dengan tegas sejak awal.

Vena memungkinkan approval matrix diterapkan langsung di alur PO — lengkap dengan eskalasi otomatis saat penyetuju tidak merespons dalam waktu yang ditentukan — sehingga aturan yang sudah disusun benar-benar berjalan di setiap transaksi, bukan hanya di dokumen kebijakan. Lihat bagaimana ini bekerja lewat demo gratis Vena (/lp/demo-vena).