Ketika persetujuan masih mengandalkan spreadsheet dan rangkaian email, masalah biasanya muncul bukan karena orangnya tidak disiplin, tetapi karena sistemnya memang mudah bocor. Versi file bercabang, bukti persetujuan tercecer, dan status terakhir sulit dipastikan, padahal keputusan operasional harus cepat dan bisa diaudit. Pembahasan ini menjelaskan bagaimana alur persetujuan digital menggantikan kebiasaan manual itu dengan jejak proses yang rapi, kontrol yang jelas, dan waktu siklus yang lebih singkat.
Mengapa spreadsheet dan email cepat rusak saat proses makin kompleks
Spreadsheet cocok untuk pencatatan, tetapi kurang tepat untuk mengelola keputusan yang melibatkan banyak pihak. Begitu ada lebih dari satu approver, revisi berulang, dan tenggat berbeda, spreadsheet berubah jadi papan status yang tidak benar-benar real-time.
Email justru memperparah karena diskusi, lampiran, dan persetujuan tersebar di banyak thread. Satu orang membalas ke sebagian penerima, yang lain meneruskan versi lama, lalu tim harus menebak mana yang valid.
Dari sisi kontrol internal, kombinasi ini mempersulit pemisahan tugas dan akuntabilitas. Saat auditor menanyakan siapa yang menyetujui apa dan berdasarkan versi dokumen mana, tim sering menghabiskan jam untuk mengumpulkan bukti dari folder, inbox, dan chat.
- Status persetujuan tidak jelas karena bergantung pada update manual.
- Risiko salah versi tinggi: angka berubah, lampiran tertukar, komentar hilang.
- SLA sulit dipenuhi karena tidak ada pengingat terstruktur dan eskalasi otomatis.
- Jejak audit lemah: persetujuan bisa berupa teks singkat tanpa konteks dokumen.
- Kontrol akses terbatas: siapa pun yang punya file bisa menyalin atau mengubah.
Perubahan saat alur persetujuan dipindahkan ke sistem
Dalam sistem persetujuan modern, unit kerja mengajukan permintaan lewat form terstruktur dan melampirkan dokumen. Sistem kemudian mengirimkan permintaan ke approver sesuai aturan yang ditetapkan (approval workflow software). Intinya: satu permintaan, satu status, satu riwayat sebagai single source of truth.
Yang dulu terjadi lewat email sekarang berlangsung di satu tempat. Komentar, revisi, dan keputusan tercatat berdampingan dengan dokumen yang disetujui, sehingga konteks tidak hilang.
Persetujuan juga bisa nonlinier. Anda dapat mengatur approval paralel, misalnya Finance dan Legal menilai bersamaan, lalu Head of Operations memberi persetujuan akhir.
Di praktik perusahaan Indonesia, perbaikan paling terasa pada tiga area: kecepatan siklus, kepastian kontrol, dan kesiapan audit. Jika tim Anda pernah mengalami pembayaran tertahan karena approval terselip atau PO dibuat berdasarkan nilai belum final, alur terpusat seperti ini mengurangi ruang interpretasi.
Fitur inti yang benar-benar menggantikan spreadsheet dan email
Bukan banyaknya fitur, melainkan beberapa kemampuan dasar yang menutup celah kerja manual. Saat fitur ini berfungsi konsisten, kebiasaan “kirim file terbaru ya” atau “tolong approval via email” bisa dihentikan.
- Form dan field wajib: misalnya nomor proyek, vendor, nilai Rp, termin, dan akun biaya agar data tidak bolong.
- Aturan approval berbasis threshold: contoh, < Rp50 juta cukup Manager, Rp50–200 juta perlu Divisi, di atas itu tambah Direksi.
- Role-based access: pemohon mengisi, approver menyetujui, reviewer menilai, tanpa saling mengubah data inti.
- Audit trail otomatis: siapa melakukan apa, jam berapa, termasuk perubahan lampiran dan komentar.
- Notifikasi, pengingat, dan eskalasi: permintaan yang tertahan memicu reminder atau naik ke atasan.
- Versi dokumen terkunci: dokumen yang disetujui tidak berubah saat ada revisi di luar.
Jika fokus Anda juga mengurangi celah penyimpangan pada proses pembayaran, penjelasan tentang kaitan kontrol persetujuan dan pencegahan kecurangan bisa dilihat pada pembahasan penguatan kontrol persetujuan untuk menekan risiko fraud pembayaran. Ini relevan terutama saat perusahaan punya volume transaksi tinggi dan banyak pihak yang terlibat.
Contoh peralihan proses: dari email berantai ke alur yang bisa dipantau
Bayangkan proses persetujuan pembayaran vendor bulanan. Sebelumnya, staf AP mengirim email ke Manager, menunggu balasan, lalu meneruskan ke Finance Head sambil melampirkan invoice, PO, dan BAST yang kadang belum lengkap.
Dengan alur terstruktur, staf AP membuat permintaan dari template dan mengisi data minimum. Sistem menolak submit jika dokumen wajib belum ada. Approver melihat ringkasan: nilai, vendor, termin, dan daftar dokumen, bukan hanya lampiran tanpa konteks.
Contoh lain adalah approval diskon penjualan atau kredit limit. Spreadsheet sering dipakai untuk mencatat keputusan, tetapi alasan dan bukti analisis tercecer. Keputusan kredit memerlukan justifikasi yang rapi untuk mengelola risiko.
Di sistem, Anda bisa menambahkan kolom alasan diskon, margin setelah diskon, dan persyaratan pembayaran. Sertakan juga hasil pengecekan seperti umur piutang atau riwayat pembayaran. Approver dapat meminta revisi tanpa membuka thread baru, dan pemohon memperbaiki pada permintaan yang sama sehingga tidak ada duplikasi.
Transisi terasa mulus karena status per item dapat dipantau. Alih-alih bertanya lewat chat “sudah di siapa?”, tim cukup membuka dashboard untuk melihat bottleneck. Misalnya ada 12 permintaan menunggu satu approver yang sedang dinas, lalu delegasi atau eskalasi bisa diaktifkan.
Langkah implementasi yang realistis agar adopsi tidak macet
Masalah implementasi biasanya bukan teknis, melainkan definisi proses dan disiplin perubahan. Cara paling aman adalah memulai dari satu jenis approval yang paling sering memicu keterlambatan atau risiko, lalu memperluas setelah pola kerjanya stabil.
Mulailah dengan memetakan alur aktual, bukan SOP ideal. Tanyakan siapa yang benar-benar memeriksa kelengkapan, siapa yang memberi persetujuan nilai, siapa yang hanya perlu diberi tahu, dan keputusan apa yang sering diulang.
Setelah itu, tetapkan tiga hal yang tidak boleh ambigu: kriteria wajib lanjut ke tahap berikutnya, batas nilai (threshold) untuk level persetujuan, dan definisi dokumen final. Di Indonesia, perusahaan sering memakai kombinasi PO, kontrak, BAST/BA, dan invoice sebagai bukti, jadi pastikan daftar ini sesuai praktik internal Anda.
Agar pengguna tidak merasa pekerjaan bertambah, siapkan template permintaan yang paling dekat dengan format yang sudah mereka pakai. Terapkan aturan sederhana seperti: semua komentar revisi dicatat di sistem, sementara diskusi panjang boleh terjadi di rapat. Namun keputusan final tetap dicatat di permintaan.
Terakhir, ukur sebelum dan sesudah dengan metrik yang dipahami manajemen. Contohnya waktu siklus rata-rata (submit sampai final), jumlah permintaan yang dikembalikan karena dokumen kurang, dan proporsi permintaan yang melewati SLA internal.
Jika Anda konsisten menjaga satu sumber data, mengunci versi dokumen, dan menegakkan aturan approval berbasis peran, spreadsheet dan email akan kembali ke fungsi yang tepat: komunikasi pendukung dan analisis, bukan mesin persetujuan. Hasilnya proses lebih cepat, lebih mudah diaudit, dan lebih sulit disalahgunakan.
Pilih satu alur yang paling sering menimbulkan friksi, lalu rapikan dari definisi data hingga aturan persetujuannya.
Pelajari Epruvo lebih lanjut: https://epruvo.com