Workflow Persetujuan Pembelian: Cara Merancang Aturan yang Dipatuhi Tim
Oleh Apex Horizon Digital
Workflow persetujuan pembelian gagal ketika semua permintaan diperlakukan sama atau jalur yang benar lebih sulit daripada jalan pintas. Kontrol yang baik harus sebanding dengan risiko. Sistem mengarahkan keputusan ke orang yang tepat, memberi konteks yang cukup, menangani cuti dan urgensi, mencatat hasil, serta membiarkan pekerjaan rutin berisiko rendah terus berjalan. Tugas desain bukan menambah sebanyak mungkin approval. Tugasnya adalah menentukan di mana judgment dibutuhkan dan membuat keputusan tersebut cepat, terlihat, serta dapat dipertanggungjawabkan.
Ringkasan utama
- Dasarkan aturan approval pada risiko, nilai, kategori, dan kondisi pengecualian, bukan hanya jabatan.
- Rancang delegasi, eskalasi, penolakan, perubahan, dan jalur darurat sebelum launch.
- Buat jalur yang disetujui mudah dipakai dan simpan riwayat keputusan lengkap.
1. Terjemahkan kebijakan purchasing menjadi aturan keputusan
Mulailah dari risiko yang ingin dikendalikan: pengeluaran tanpa izin, budget terlewati, pemasok tidak sesuai, perbandingan hilang, kategori sensitif, syarat tidak biasa, atau konflik kepentingan. Lalu tentukan kondisi mana yang membutuhkan review. Pembelian rutin bernilai rendah dari pemasok yang sudah disetujui dapat memakai jalur lebih sederhana daripada pemasok baru, pembelian aset, atau komitmen kontrak. Hindari menyalin bagan organisasi langsung ke workflow. Approver yang benar adalah orang yang bertanggung jawab atas budget atau risiko terkait, bukan selalu orang paling senior.
2. Bangun matriks approval yang jelas
Matriks perlu menggabungkan tipe transaksi, departemen, rentang nilai, kategori, status budget, kondisi pemasok, dan flag risiko khusus. Untuk setiap kombinasi, tentukan urutan approver serta apakah keputusan berjalan paralel atau berurutan. Jaga jumlah rentang agar dapat dipahami dan jelaskan kebijakan dengan bahasa sederhana. Jika dua aturan bertabrakan, tentukan prioritas. Jelaskan pula apa yang terjadi saat permintaan berubah setelah approval. Perubahan material pada kuantitas, harga, pemasok, atau syarat dapat memerlukan approval ulang, sedangkan koreksi catatan kecil tidak perlu mengulang seluruh rantai.
3. Rancang pengecualian, delegasi, dan eskalasi
Operasi nyata mencakup cuti, kerusakan mendesak, penolakan, approval sebagian, dan informasi hilang. Delegate perlu memiliki periode dan authority yang jelas, bukan memakai login orang lain. Eskalasi harus memberi notifikasi atau mengalihkan setelah waktu respons yang disepakati tanpa melakukan approval diam-diam. Pembelian darurat memerlukan alasan terkendali, authority terbatas, bukti wajib, dan review setelah kejadian. Penolakan harus mencatat alasan serta mengembalikan permintaan ke owner yang jelas. Jalur ini perlu diuji karena user meninggalkan sistem saat pengecualian pertama membuat mereka terjebak.
4. Beri approver konteks dan tindakan cepat
Layar approval perlu menampilkan apa yang diminta, alasan, kuantitas, harga, pemasok, dampak budget, perbandingan sebelumnya, attachment, requester, tanggal dibutuhkan, dan flag kebijakan. Approver tidak seharusnya mencari chat atau membuka beberapa spreadsheet untuk memahami keputusan. Interface perlu mendukung approve, reject, request changes, dan comment dengan hasil yang tegas. Notifikasi harus menuju langsung ke keputusan dan menghindari noise berulang. Akses mobile dapat membantu, tetapi identity dan authorization tetap harus jelas.
5. Simpan audit trail dan uji adopsi
Catat permintaan awal, setiap revisi penting, approver, delegasi, notifikasi, keputusan, alasan, timestamp, dan aktor. Laporan perlu menunjukkan umur pending, bottleneck, pemakaian jalur darurat, alasan penolakan, serta permintaan yang dipenuhi tanpa approval wajib. Sebelum launch, uji matriks dengan skenario representatif dan minta user menjelaskan tindakan mereka. Setelah launch, review bypass dan keterlambatan. Jika orang tetap menyetujui lewat chat, cari apakah konteks, akses, waktu respons, atau pengecualian yang belum tertangani mendorong mereka menjauh dari jalur resmi.
- Aturan threshold: nilai, mata uang, departemen, dan budget owner.
- Aturan pengecualian: pemasok baru, kategori sensitif, syarat khusus, atau budget hilang.
- Aturan eskalasi: waktu respons, notifikasi, pengalihan, dan owner.
- Bukti audit: versi permintaan, keputusan, alasan, aktor, timestamp, dan status lanjutan.