Approval Workflow Bukan Sekadar Tombol Approve
Mengapa approval system yang terlihat sederhana sebenarnya menyimpan persoalan authority, traceability, exception, dan accountability.
Kalau dilihat dari layar, approval system terlihat sederhana.
Ada request. Ada tombol Approve. Ada Reject.
Tetapi ketika dipakai di organisasi, persoalannya jauh lebih besar daripada tiga status itu.
Yang sebenarnya sedang kita modelkan adalah authority
Siapa berhak menyetujui? Apakah berdasarkan jabatan, nominal, unit kerja, jenis transaksi, atau kombinasi semuanya?
Apa yang terjadi ketika approver cuti? Bolehkah didelegasikan? Kalau struktur organisasi berubah, apakah workflow ikut berubah? Bagaimana jika request sudah berjalan saat rule diganti?
Pertanyaan seperti ini bukan masalah UI. Ini masalah operasional dan governance.
Audit trail bukan fitur tambahan
Dalam proses yang melibatkan uang, procurement, reimbursement, atau keputusan organisasi, kita harus bisa menjawab: siapa melakukan apa, kapan, berdasarkan data apa, dan apakah ada perubahan setelah approval diberikan.
Karena itu saya melihat approval sebagai bagian dari kontrol internal, bukan sekadar fitur aplikasi.
Exception selalu datang
Happy path mudah dibuat. Yang sulit adalah kondisi ketika request dikembalikan untuk revisi, sebagian disetujui, approver berganti, dokumen kurang, atau data upstream berubah.
Sistem yang tidak memikirkan exception biasanya terlihat bagus saat demo dan mulai menyulitkan ketika benar-benar dipakai.
Mulai dari policy, baru workflow
Sebelum membuat diagram approval, saya lebih suka menanyakan policy-nya terlebih dahulu.
Apa yang sebenarnya ingin dikontrol? Risiko apa yang sedang dikurangi? Di titik mana organisasi membutuhkan bukti keputusan?
Kalau itu jelas, workflow menjadi konsekuensi dari proses bisnis.
Bukan sebaliknya.
Dan di situlah perbedaan antara membuat tombol Approve dan membangun sistem approval yang benar-benar membantu organisasi.