Persetujuan yang Didelegasikan dalam Alur Kerja: Mode Cuti dan Pengganti

Mengapa persetujuan macet saat orang sedang tak hadir

Persetujuan terhenti karena alasan sederhana: alur kerja menunggu satu orang tertentu, dan sistem tidak tahu apa yang harus dilakukan saat orang itu sedang offline. Permintaan masuk ke inbox mereka, tidak ada orang lain yang punya wewenang untuk bertindak, dan semuanya terhenti.

Situasi ini menjadi lebih buruk ketika persetujuan dikaitkan pada nama, bukan peran. Tim berubah, orang cuti, manajer bepergian. Jika alur kerja tidak bisa otomatis beralih ke pengganti, Anda akan mendapat pesan “urgent”, solusi manual, dan keputusan yang tertunda.

Ada baiknya juga memisahkan beberapa tindakan serupa yang sering dicampur orang:

• Delegasi: approver asli tetap bertanggung jawab, tetapi pengganti dapat bertindak atas nama mereka untuk periode atau kasus tertentu.
• Penerusan: tugas dibagikan atau dikirim ke orang lain, tetapi sistem mungkin masih mengharapkan respon dari orang asli.
• Penugasan ulang: kepemilikan tugas persetujuan pindah ke orang lain, sering kali permanen atau untuk satu permintaan.

Tujuan sebenarnya bukan hanya kecepatan. Ini tentang keterdugaan dan catatan yang bersih.

“Transparan” berarti dua hal bagi manajer dan auditor: Anda bisa melihat mengapa alur kerja diarahkan ke pengganti, dan Anda bisa membuktikan siapa yang menyetujui, kapan, dan berdasarkan aturan apa. Jika Alex sedang cuti dan Priya menyetujui pembelian, riwayat harus menunjukkan bahwa Priya bertindak sebagai delegasi Alex. Tidak boleh terlihat bahwa Alex yang menyetujui, dan tidak boleh hilang ke obrolan pribadi.

Hasil yang dituju sederhana: tidak ada permintaan yang terblokir, dan jejak yang jelas serta dapat ditinjau tentang siapa melakukan apa, bahkan ketika seseorang tidak hadir.

Istilah utama: approver, pengganti, dan delegasi

Kata-kata yang jelas mencegah aturan berantakan nanti. Jika orang tidak sepakat siapa yang dapat menyetujui apa, alur kerja Anda akan macet atau menimbulkan masalah audit.

Kebanyakan alur persetujuan memiliki beberapa peran umum:

• pemohon memulai proses (biaya, permintaan pembelian, permintaan akses).
• approver membuat keputusan.
• admin mengonfigurasi alur kerja, izin, dan aturan.
• pengganti (kadang disebut delegate) diizinkan untuk menyetujui atas nama orang lain.

Seorang approver utama adalah orang default yang diharapkan menyetujui sebuah langkah. Seorang approver cadangan adalah pihak fallback yang bisa menyetujui saat approver utama tidak bisa.

Orang sering mencampuradukkan “approver cadangan” dengan “approver kedua”, padahal berbeda. Approver kedua menambah level ekstra. Cadangan adalah jalur alternatif untuk level yang sama.

Delegasi adalah aturan yang memungkinkan pengganti bertindak. Dua gaya umum adalah:

• Delegasi selalu aktif: pengganti bisa menyetujui kapan saja, bahkan jika approver utama tersedia.
• Delegasi hanya saat absen: pengganti boleh menyetujui hanya ketika approver utama ditandai tidak hadir (mode cuti) atau ketika batas waktu tercapai.

Tingkat persetujuan (levels) adalah langkah berurutan yang harus dilalui sebuah permintaan (manajer, lalu keuangan, lalu legal, lalu TI, tergantung jenis permintaan dan jumlahnya). Pisahkan “tingkat” dari “pengganti”: tingkat menentukan apa yang harus disetujui; pengganti menentukan siapa yang dapat menyetujui ketika orang biasa tidak bisa.

Pilih model delegasi yang sesuai proses Anda

Tidak semua tim membutuhkan pendekatan cadangan yang sama. Model yang tepat bergantung pada seberapa sering orang absen, seberapa berisiko keputusan tersebut, dan seberapa dapat diprediksi langkah persetujuan Anda.

Pilih satu model utama terlebih dahulu dan anggap yang lain sebagai pengecualian. Mencampur semuanya sejak awal membingungkan pengguna dan mempersulit audit.

Model delegasi umum (dan kapan cocok)

Kebanyakan tim menggunakan kombinasi dari ini:

• Mode cuti (berdasarkan tanggal): approver menetapkan tanggal mulai dan berakhir, dan permintaan diarahkan ke pengganti bernama selama jendela itu.
• Delegasi satu kali manual: admin atau manajer menetapkan pengganti untuk satu permintaan saat darurat.
• Delegasi berbasis aturan: pengganti dipilih oleh aturan seperti tim, kategori permintaan, atau jumlah.
• Eskalasi: jika tidak ada yang merespons tepat waktu, permintaan berpindah ke orang berikutnya (sering kali manajer approver atau antrean on-call).
• Pemisahan tugas: persetujuan sensitif memerlukan orang berbeda (atau approver kedua) sehingga pemohon atau pengganti tidak bisa menyetujui pekerjaannya sendiri.

Mode cuti biasanya paling mudah sehari-hari. Delegasi berbasis aturan cocok untuk tim besar karena mengurangi keputusan manual tentang siapa yang menutup. Eskalasi bukan pengganti delegasi; itu jaring pengaman untuk timeout.

Pertanyaan yang cepat menentukan model

Beberapa jawaban akan mempersempit opsi dengan cepat:

• Apakah persetujuan berisiko tinggi (uang, akses, kepatuhan) atau berisiko rendah (administrasi rutin)?
• Perlukah satu pengganti per orang, atau sebuah pool (mis. “Finance On-Call”)?
• Haruskah pengganti terlihat oleh pemohon, atau hanya oleh admin?\n- Berapa lama permintaan bisa menunggu sebelum eskalasi?
• Perlukah aturan ketat yang mencegah persetujuan diri?

Aturan desain untuk mode cuti dan pengganti

Mode cuti hanya berhasil jika dapat diprediksi. Tujuannya sederhana: persetujuan terus berjalan, dan semua orang bisa melihat siapa yang bertanggung jawab.

Wajibkan jendela waktu yang jelas. Setiap delegasi harus memiliki tanggal mulai dan berakhir (dan zona waktu jika bekerja lintas wilayah). Hindari “sampai diberitahu lebih lanjut.” Jika seseorang lupa mematikannya, persetujuan bisa mengalir ke orang yang salah selama berminggu-minggu.

Tentukan siapa yang boleh memilih pengganti. Delegasi yang dipilih sendiri bisa bekerja di tim kecil, tapi berisiko jika orang memilih seseorang yang tak terlatih. Penetapan oleh manajer cocok untuk kebanyakan struktur organisasi. Penetapan oleh admin terbaik saat Anda butuh kontrol ketat, tetapi bisa memperlambat pengaturan.

Tetapkan aturan kelayakan yang bisa ditegakkan sistem. Buat sederhana, dan jangan izinkan “kasus khusus” yang hanya ada di kepala seseorang. Aturan tipikal termasuk berada di departemen atau cost center yang sama, memiliki level persetujuan yang tepat, dan menyelesaikan pelatihan yang diperlukan. Selalu cegah konflik jelas: pengganti tidak boleh menjadi pemohon, dan hindari persetujuan melingkar.

Tentukan apa yang terjadi pada persetujuan yang sedang berjalan. Banyak tim mengarahkan permintaan baru ke pengganti tetapi mempertahankan item yang tertunda pada approver utama kecuali sudah melewati batas waktu. Setelah terlambat, alur kerja dapat auto-assign ulang atau eskalasi.

Buat status terlihat. Pemohon harus melihat approver saat ini, apakah delegasi aktif, dan apa langkah berikutnya. Status seperti “Menunggu persetujuan (didelegasikan ke Alex hingga 30 Jan)” mengurangi follow-up dan menjaga kepercayaan tinggi.

Langkah demi langkah: terapkan approver alternatif dalam alur kerja

Mulailah dengan menuliskan jalur persetujuan yang tepat untuk satu permintaan umum (pembelian, akses, pengecualian kebijakan). Buat sempit. Dua sampai empat langkah cukup untuk merancang pola.

Pola implementasi praktis

1. Peta setiap langkah ke peran dan satu pemilik tercatat. Bahkan jika pengganti bisa bertindak, pertahankan satu approver utama per langkah agar tanggung jawab jelas.

2. Pilih satu pemicu utama untuk delegasi. Kebanyakan tim menggunakan flag ketidakhadiran, jendela tanggal, atau sakelar yang dikontrol manajer. Pilih satu dulu supaya orang tidak kaget oleh reroute diam-diam.

3. Tambahkan aturan routing untuk memilih approver yang bertindak. Urutan yang dapat diprediksi paling mudah dijelaskan nanti: pengganti yang dipilih pengguna, lalu manajer, lalu antrean cadangan bersama. Putuskan apakah pengganti bisa menyetujui segera atau hanya setelah timeout.

4. Atur ekspektasi lewat notifikasi. Pemohon harus melihat siapa yang bertanggung jawab sekarang. Approver utama harus diberi tahu delegasi aktif dan cara mematikannya. Pengganti harus mendapatkan konteks dan cara jelas untuk menolak jika mereka tak seharusnya bertindak.

5. Jalankan satu uji end-to-end dan periksa riwayat. Anda harus bisa melihat siapa yang ditugaskan, mengapa delegasi terjadi, siapa menyetujui, dan kapan.

Uji dan konfirmasi

Gunakan skenario realistis: approver utama “sedang cuti” dan pengganti menyetujui. Ulangi dengan pengganti tak tersedia untuk memastikan aturan fallback berfungsi. Terakhir, pastikan jejak audit menunjukkan baik approver utama maupun approver yang bertindak, plus alasan delegasi, sehingga auditor dapat memahami alih tangan tanpa bertanya ke siapa pun.

Apa yang harus dicatat untuk riwayat persetujuan yang jelas (jejak audit)

Jejak audit harus menjawab tiga pertanyaan tanpa tebakan: apa yang terjadi, siapa yang melakukannya, dan mengapa itu diizinkan. Ini lebih penting lagi dengan persetujuan yang didelegasikan, karena “approver yang bertanggung jawab” dan “orang yang mengklik” bisa berbeda.

Catat aturan delegasi sebagai rekaman kelas satu, bukan pengaturan yang berubah diam-diam. Tangkap siapa mendelegasikan ke siapa, waktu mulai dan berakhir, cakupan (permintaan mana, jumlah, tim, atau jenis dokumen), dan siapa yang menyetujui atau mengonfirmasi perubahan jika proses Anda memerlukan tanda tangan.

Keputusan persetujuan harus menjadi peristiwa yang tidak dapat diubah. Jangan timpa status “pending” dengan “approved.” Rekam peristiwa seperti “Approved,” “Rejected,” atau “Requested changes” dan simpan, bahkan jika alur kerja dimulai ulang.

Jejak audit praktis biasanya mencakup:

• ID peristiwa, ID item alur kerja, dan nama langkah
• Timestamp (dengan zona waktu), identitas pelaku, dan perannya saat itu
• Rincian bertindak-atas-nama (approver asli, ID aturan delegasi)
• Hasil plus komentar, kode alasan, dan lampiran apa pun
• Setiap pengeditan pada aturan delegasi (siapa mengubah apa, dan kapan)

Simpan komentar dan lampiran yang terkait dengan peristiwa keputusan. Jika mereka berada di obrolan terpisah atau bidang “catatan” umum, akan sulit membuktikan komentar mana yang mendukung keputusan mana.

Terakhir, buat riwayatnya mudah dibaca. Timeline tunggal yang menunjukkan perubahan delegasi, notifikasi yang dikirim, keputusan yang dibuat, dan eskalasi secara berurutan mencegah perselisihan di kemudian hari.

Transparansi: apa yang harus dilihat pengguna selama proses persetujuan

Orang menerima penundaan saat mereka bisa melihat apa yang terjadi. Ketika mereka tidak bisa, mereka mengejar orang yang salah, mengirim ulang permintaan, atau mengira sistem rusak.

Pemohon dan peninjau harus selalu melihat approver saat ini dan alasan mereka dipilih. Jika tugas berpindah dari approver utama ke pengganti, tampilkan secara langsung: “Ditugaskan ke: Priya (pengganti untuk Alex).” Satu baris itu mencegah kebingungan dan melindungi akuntabilitas.

Tampilkan juga jendela delegasi dan siapa yang mengaturnya. “Delegasi aktif: 10 Jan sampai 20 Jan, diatur oleh Alex” membantu tim percaya penyerahan itu sengaja.

Penugasan ulang yang tersembunyi adalah sumber masalah audit. Jika seseorang bisa menukar approver tanpa jejak yang terlihat, pengguna kehilangan kepercayaan dan manajer tak bisa mengetahui siapa yang membuat keputusan. Buat penugasan ulang terlihat oleh orang yang tepat, dan selalu catat siapa yang memicunya.

Panel “Lihat riwayat” yang sederhana biasanya cukup. Fokuskan pada: status saat ini, approver saat ini dan alasannya, periode delegasi, penugasan ulang manual apa pun, dan komentar keputusan.

Privasi juga penting. Tentukan apa yang bisa dilihat tiap peran. Pemohon mungkin perlu nama dan status, sementara alur HR, keuangan, atau legal mungkin memerlukan penyamaran catatan internal.

Kesalahan umum yang menyebabkan penundaan atau masalah audit

Delegasi biasanya gagal karena alasan sederhana: aturan terlalu longgar, catatan terlalu samar, atau tidak ada rencana cadangan. Hasilnya bisa diprediksi: permintaan menunggu, dan nanti tak ada yang bisa membuktikan siapa yang menyetujui apa.

Perangkap umum adalah mendelegasikan ke seseorang yang tidak bisa menyetujui jenis permintaan itu. Misalnya, seorang pembeli mendelegasikan persetujuan pembelian ke rekan yang tidak punya batas pengeluaran. Pengganti mengklik setuju, keuangan menandai, dan sekarang Anda harus membongkar transaksi dan menjelaskan mengapa sistem mengizinkannya.

Kesalahan yang sering muncul:

• Delegasi ke diri sendiri, atau ke orang yang tidak memenuhi syarat (peran salah, batas salah, konflik kepentingan)
• Delegasi tanpa tanggal berakhir
• Menimpa approver asli di catatan (Anda kehilangan rantai tanggung jawab)
• Tidak ada jalur eskalasi saat baik primary maupun substitute tidak tersedia
• Terlalu banyak notifikasi, sehingga orang mematikan dan melewatkan notifikasi penting

Kelebihan notifikasi itu halus. Jika setiap langkah memicu email, chat, push, dan pengingat, pengguna belajar mengabaikan semuanya.

Pilihan desain yang mencegah sebagian besar masalah:

• Wajibkan tanggal mulai dan berakhir untuk delegasi, dengan kedaluwarsa otomatis
• Validasi pengganti terhadap aturan jelas sebelum aktivasi
• Pertahankan kedua identitas: “approver yang ditugaskan” dan “bertindak oleh,” dan jangan pernah menghapus approver asli
• Tambahkan eskalasi: jika tak ada aksi dalam X jam, arahkan ke manajer atau antrean on-call

Checklist cepat sebelum peluncuran

Delegasi berhasil ketika detail membosankan konsisten. Sebelum mengaktifkan mode cuti untuk seluruh perusahaan, periksa setiap langkah persetujuan dan tanyakan: jika approver yang ditugaskan tak tersedia hari ini, apa yang terjadi selanjutnya?

• Setiap langkah punya backup bernama (atau antrean on-call), dan backup itu punya izin yang tepat.
• Aturan delegasi berbatas waktu, dan admin bisa melihat delegasi mana yang aktif.
• Riwayat persetujuan menampilkan kedua orang: siapa yang bertanggung jawab dan siapa yang bertindak.
• Untuk setiap catatan, Anda bisa menjawab “siapa menyetujui, kapan, dan berdasarkan aturan apa” tanpa menebak.
• Ada eskalasi untuk timeout (mis. setelah 48 jam, assign ulang ke manajer atau antrean).

Lalu uji setidaknya satu skenario “orang sedang cuti” secara end-to-end: permintaan diajukan sebelum cuti dimulai, disetujui selama cuti, dan ditinjau setelah orang kembali.

Contoh: penyerahan persetujuan nyata selama cuti

Tim penjualan mengajukan permintaan pembelian 12 headset (USD 1.200). Permintaan biasanya ke Maya, Manajer Penjualan. Namun Maya cuti dua minggu, dan persetujuan tak bisa menunggu.

Sebelum berangkat, Maya mengaktifkan mode cuti dan menunjuk Jordan (Sales Ops Lead) sebagai pengganti untuk persetujuan pembelian sampai USD 5.000. Yang melebihi itu tetap ke Keuangan.

Inilah bagaimana penyerahan berjalan secara bersih dan ramah-audit:

• Senin 09:10: Seorang perwakilan mengajukan “Headsets untuk onboarding” dengan vendor dan cost center.
• Senin 09:10: Alur kerja menugaskan langkah ke Maya, lalu langsung mereroute ke Jordan karena mode cuti aktif.
• Senin 09:18: Jordan meninjau permintaan dan menyetujui. Catatan menunjukkan “Jordan (bertindak untuk Maya)” dan menyertakan catatan Jordan: “Disetujui untuk onboarding Q1. Anggaran terkonfirmasi.”
• Senin 09:18: Alur kerja berlanjut ke Keuangan untuk pemeriksaan anggaran, lalu menandai permintaan sebagai disetujui.

Dua detail membuat ini dapat dipercaya. Pemohon bisa melihat mengapa approver berubah (“Dialihkan ke pengganti: Maya out of office”), dan Maya tidak dibuat bertanya-tanya saat kembali.

Saat Maya kembali, ia membuka tampilan “Persetujuan saat absen” dan meninjau apa yang Jordan setujui atas namanya. Ia bisa memfilter berdasarkan rentang tanggal, jumlah, atau pemohon. Ia tidak menyetujui ulang apa pun, tetapi bisa menandai permintaan untuk tindak lanjut jika sesuatu terasa tak benar.

Kemudian auditor bertanya, “Siapa yang menyetujui pembelian ini, dan mengapa bukan Maya?” Timeline memberi satu cerita konsisten: approver asli, alasan delegasi (mode cuti), identitas pengganti, atribusi bertindak-atas-nama, keputusan ber-stempel waktu, dan catatan.

Langkah selanjutnya: terapkan dengan aman dan mudah dipelihara

Anggap delegasi sebagai perubahan produk kecil, bukan sekadar centang. Tujuan tetap sama: persetujuan terus berjalan saat orang absen, dan Anda bisa menjelaskan setiap keputusan nanti.

Mulailah dengan satu alur kerja yang bermasalah ketika macet (biaya, persetujuan pembelian, atau permintaan akses). Batasi ruang lingkup: satu tim, satu jalur persetujuan, dan satu ukuran keberhasilan yang jelas, seperti “tidak ada persetujuan menunggu lebih dari 24 jam karena seseorang absen.”

Tulis kebijakan delegasi singkat yang benar-benar akan diikuti orang: siapa yang bisa mendelegasikan, apa yang bisa didelegasikan (mis. hanya di bawah batas biaya atau risiko), bagaimana delegasi dimulai dan diakhiri, dan seperti apa override darurat serta bagaimana dicatat.

Tunjuk satu pemilik untuk peran dan aturan, dan jadwalkan tinjauan berkala (bulanan atau triwulanan) untuk membersihkan pengganti usang. Sebagian besar masalah jangka panjang muncul dari delegasi yang kedaluwarsa dan tidak pernah dimatikan.

Jika Anda ingin membangun aplikasi persetujuan tanpa banyak pemrograman, AppMaster (appmaster.io) dapat memodelkan pengguna, peran, dan jendela delegasi di database, lalu mengimplementasikan routing dan timeout di Visual Business Process Editor sambil mempertahankan riwayat persetujuan yang konsisten untuk audit.

Luncurkan bertahap, dengarkan kebingungan, dan perluas ke alur kerja berikutnya hanya setelah yang pertama berjalan lancar beberapa minggu.