Yang mengajukan tidak boleh menyetujui sendiri

Awalnya cuma keluhan yang sudah lama saya rasakan: proses yang butuh persetujuan berjenjang di SATU itu membingungkan. Ada yang posisinya hilang, ada yang cabangnya tidak punya kepala toko, ada yang alurnya beda-beda tiap modul. Jadi saya minta satu hal: petakan semuanya dulu, sebelum ada yang diubah.

Lima penelusur, satu peta

Pemetaan itu dikerjakan lima penelusur kode yang jalan bersamaan, masing-masing kebagian satu kelompok proses — Dana dan Biztrip, Refund dan keuangan, Pembelian dan Gudang, HR dan Absen, lalu Product, Marcom, dan Service. Semuanya baca saja, tidak ada yang diubah. Hasilnya satu ringkasan: tiap proses, siapa yang boleh bertindak di tiap tahap, dari mana hak itu ditentukan, dan apa yang terjadi kalau posisinya kosong.

Dua temuan besar. Pertama, hak seseorang ditentukan dari tiga sumber berbeda — jabatan di HR, peran per modul, dan akses cabang — dan tiap modul memilih sumbernya sendiri. Kedua, dan ini yang bikin saya terdiam: aturan “yang mengajukan tidak boleh menyetujui sendiri” hampir tidak dijaga. Dari semua proses, hanya Events yang punya pagarnya.

Satu aturan, dipasang di semua tempat

Aturannya sederhana, dan justru karena itu seharusnya ada dari awal. Sekarang aturan itu dipasang di Dana, Refund, penarikan dan top-up KAS, dan pinjaman karyawan. Kalau pengajuan dibuat oleh orang yang sama dengan yang mau menyetujui, sistem menolak dengan pesan yang jelas.

Satu keputusan yang saya ambil sendiri: super admin ikut dijaga. Tidak ada pengecualian “karena saya yang punya sistemnya”. Kalau pengecualian itu ada, aturannya tidak berarti apa-apa.

Bagaimana kalau pengaju memang atasannya

Aturan seperti ini langsung menabrak kenyataan. Bagaimana kalau yang mengajukan Dana adalah Korwil itu sendiri? Gerbang Korwil di alurnya jadi tidak mungkin dilalui — tidak ada orang lain yang boleh menyetujui.

Jawabannya bukan membiarkan dia menyetujui diri sendiri. Gerbangnya dilompati, dan lompatan itu dicatat secara jujur: di data tertulis bahwa gerbang itu dilewati, bukan seolah-olah ada yang menyetujui.

Hal yang sama sebenarnya sudah lama terjadi diam-diam di Refund. Di cabang yang tidak punya Kepala Toko lain selain pengaju, nama pengaju tercatat sebagai penyetuju tahap itu. Di tampilan audit, itu terbaca “disetujui Kepala Toko” padahal sebenarnya tidak ada yang menyetujui. Sembilan refund lama yang begitu sudah dirapikan: penyetujunya dikosongkan dan ditandai sebagai gerbang yang dilompati. Satu lagi sengaja tidak saya sentuh, karena tidak jelas apakah itu lompatan atau persetujuan sendiri — lebih baik dibiarkan ambigu daripada ditulis ulang dengan tebakan.

Tiga hal kecil yang ikut dibereskan

• Peran manual tidak lagi ditimpa. Sinkronisasi peran dari jabatan HR dulu bisa mencabut peran yang saya atur tangan. Dalam uji kering, kodenya akan menghapus peran enam kasir yang sedang dipakai untuk mengajukan Dana. Sekarang yang berbeda dilewati dan dilaporkan, tidak ditimpa.
• Peran yang salah ketik ditolak. Kelola Pengguna sekarang memeriksa bahwa peran yang diberikan memang dikenal modulnya.
• Peringatan kalau Absen tidak terjangkau. Kalau antrean cuti dan lembur dari Portal Absen gagal dimuat, Tugas Saya sekarang menampilkan kotak kuning — bukan daftar kosong yang terlihat seperti “tidak ada tugas”.

Yang saya bawa dari sini

Saya mencari fitur yang hilang, dan yang ketemu adalah pagar yang tidak pernah dipasang. Pagar seperti ini tidak kelihatan sampai ada yang menabraknya, dan sistem yang berjalan lancar justru membuatnya makin mudah terlewat. Masih ada pekerjaan yang lebih besar di peta itu: satu sumber hak yang seragam, pengganti saat atasan berhalangan, dan eskalasi saat antrean macet. Tapi aturan yang paling mendasar, akhirnya sudah dijaga.