Ketika alur persetujuan dipindahkan dari email dan spreadsheet ke sistem, masalahnya jarang pada fitur. Yang sering menghambat implementasi justru ketidakjelasan siapa berwenang menyetujui, siapa meninjau, dan siapa yang harus diberi tahu. Dengan memetakan pemangku kepentingan dan perannya sejak awal, Anda bisa mempercepat adopsi, mengurangi bolak-balik revisi, dan menjaga kepatuhan proses tanpa membebani tim.
Petakan pemangku kepentingan berdasarkan keputusan yang mereka pegang
Langkah pertama yang efektif adalah mulai dari keputusan yang terjadi dalam proses, bukan dari struktur organisasi. Tanyakan untuk setiap jenis permintaan: keputusan apa yang harus diambil, risikonya apa, dan siapa yang berwenang mengambil keputusan dalam praktik sehari-hari di Indonesia.
Biasanya pemangku kepentingan approval workflow system terbagi menjadi beberapa kelompok. Anda tidak perlu melibatkan semua orang sejak hari pertama, tetapi harus jelas siapa pemilik keputusan dan siapa yang terdampak.
- Requester/pemohon: karyawan atau tim yang mengajukan permintaan (contoh: PR, perjalanan dinas, akses sistem).
- Approver bisnis: pemegang otoritas anggaran atau kebijakan (contoh: Head of Department, budget owner).
- Reviewer kontrol: pihak yang memastikan kelengkapan dan kepatuhan (contoh: Finance untuk dokumen, Procurement untuk vendor, HR untuk kebijakan).
- Risk & compliance: Legal, Internal Audit, atau Risk untuk kasus berisiko lebih tinggi (contoh: kontrak, pengadaan tertentu, konflik kepentingan).
- IT & security: pemilik akses, integrasi, dan pengendalian keamanan (contoh: akses aplikasi, SSO, audit trail).
- PMO/Process owner: pihak yang menjaga standar proses lintas proyek dan mengelola perubahan.
Untuk membuatnya konkret, ambil satu skenario yang sering terjadi, misalnya pengajuan reimburse. Di situ terlihat siapa budget owner, siapa yang memverifikasi bukti, dan kapan eskalasi diperlukan bila melebihi batas tertentu.
Definisikan peran dengan RACI yang bisa diuji di lapangan
Setelah stakeholder terpetakan, terjemahkan menjadi peran operasional menggunakan RACI (Responsible, Accountable, Consulted, Informed). Kuncinya bukan sekadar dokumen rapi, tetapi memastikan setiap langkah punya satu Accountable yang benar-benar bisa mengambil keputusan final.
Kesalahan umum adalah menempatkan terlalu banyak approver wajib sehingga alur melambat. Tambah lapisan persetujuan hanya jika itu memang menurunkan risiko nyata, misalnya nilai transaksi tinggi, vendor baru, atau tipe pengeluaran sensitif.
Berikut contoh RACI ringkas untuk permintaan pembelian (PR) yang bisa Anda adaptasi. Angka, batas nilai, dan jabatan perlu disesuaikan dengan kebijakan internal tiap perusahaan di Indonesia.
- Requester: Responsible mengisi kebutuhan, spesifikasi, dan lampiran.
- Atasan langsung: Accountable memastikan kebutuhan valid dan sesuai prioritas.
- Procurement: Responsible untuk review vendor/penawaran, Consulted untuk strategi pengadaan.
- Finance: Consulted untuk cek ketersediaan anggaran, Informed untuk dampak cashflow.
- Legal: Consulted bila ada kontrak/ketentuan khusus.
Uji RACI dengan dua pertanyaan sederhana: siapa yang menggantikan jika approver tidak merespons, dan siapa pemutus akhir saat ada sengketa keputusan. Jika jawabannya tidak jelas, workflow akan menghasilkan antrean dan eskalasi manual.
Selanjutnya, definisikan aturan delegasi dan backup approver agar proses tetap berjalan saat cuti atau perjalanan dinas. Di banyak organisasi, ini pembeda utama antara workflow yang dipakai sehari-hari dan yang kembali ke email.
Terjemahkan peran ke desain workflow, kontrol, dan metrik operasional
Peran yang sudah jelas perlu diterjemahkan ke konfigurasi sistem: tahapan, kondisi (rules), notifikasi, dan hak akses. Tahap ini idealnya dikerjakan bersama process owner, IT, dan perwakilan fungsi kontrol agar desain seimbang antara kecepatan dan kepatuhan.
Mulailah dengan memisahkan tiga hal yang sering tercampur: approval (keputusan), review (verifikasi/kelengkapan), dan acknowledgement (sekadar mengetahui). Jika semuanya diperlakukan sebagai approval, SLA akan membengkak dan orang cenderung asal klik setuju.
Prinsip desain yang biasanya membantu di lapangan:
- Conditional routing: alur berbeda berdasarkan nilai, kategori, cost center, atau vendor baru/lama.
- Parallel review: verifikasi dokumen dan pengecekan anggaran bisa berjalan bersamaan bila independen.
- Exception handling: definisikan jalur cepat untuk koreksi minor tanpa mengulang dari awal.
- Audit trail: simpan alasan persetujuan/penolakan dan versi lampiran untuk pemeriksaan.
Untuk pembayaran dan reimburse, praktik yang sering mempercepat adalah menempatkan verifikasi kelengkapan sebagai gate sebelum approval final. Contoh penerapannya dijelaskan pada pembahasan tentang mempercepat pembayaran dan reimburse dengan alur persetujuan internal.
Perhatikan akses dan keamanan: siapa boleh membuat jenis permintaan tertentu, siapa boleh melihat nominal, dan siapa dapat mengubah master data. IT perlu memastikan prinsip least privilege, integrasi identitas (misalnya SSO), serta kebijakan retensi data yang sesuai kebutuhan audit.
Terakhir, tetapkan metrik yang mencerminkan peran. Contoh metrik berguna: median waktu per tahap, rasio penolakan per kategori, jumlah permintaan ulang karena lampiran kurang, dan frekuensi penggunaan delegasi.
Kelola perubahan: komunikasikan tanggung jawab, bukan sekadar fitur
Bahkan workflow terbaik bisa gagal jika orang tidak paham tanggung jawabnya. Susun komunikasi berbasis skenario: apa yang harus dilakukan requester agar tidak ditolak, kapan approver perlu memberi alasan, dan kapan reviewer cukup mengembalikan untuk perbaikan.
Rencanakan uji coba terbatas dengan 1-2 proses yang paling sering terjadi, lalu perluas setelah stabil. Pada fase ini, PMO atau process owner sebaiknya memimpin triage masalah: apakah kendalanya kebijakan, desain alur, data master, atau perilaku pengguna.
Penutupan yang rapi juga penting: dokumentasikan definisi peran, kebijakan delegasi, dan aturan routing sebagai referensi satu halaman. Saat ada perubahan organisasi atau batas nilai, pembaruan akan lebih cepat dan tidak merusak alur yang sudah berjalan.
Dengan pemetaan pemangku kepentingan yang tepat, peran yang tegas, dan desain alur yang terukur, implementasi menjadi lebih stabil dan mudah diaudit.
Jika Anda ingin, tinjau kembali satu proses paling sering dipakai dan cek apakah RACI serta jalur pengecualiannya sudah jelas.
Pelajari Epruvo lebih lanjut: https://epruvo.com