Otomatisasi persetujuan internal: alur jelas dan tenggat waktu

Otomatisasi persetujuan internal berarti setiap permintaan, dari cuti hingga pengeluaran dan diskon, mengikuti alur yang diketahui: siapa yang menyetujuinya sesuai jenis dan nilainya, siapa yang menggantikan saat orang itu tidak ada, berapa jam permintaan menunggu sebelum dieskalasi, dan catatan yang menunjukkan siapa menyetujui apa dan kapan. Di bagian 2 seri ini Anda telah memetakan proses sebagaimana benar-benar berjalan, dan kemungkinan besar penantian di tahap persetujuan muncul sebagai langkah terpanjangnya. Bagian ketiga dari 7 ini memberi Anda 4 elemen untuk membangun alur persetujuan, serta latihan untuk melacak 10 permintaan terakhir Anda dan berapa lama masing-masing menunggu.

Mengapa otomatisasi sering dimulai dari persetujuan

Persetujuan adalah langkah kecil dalam bentuk tetapi besar dalam dampak. Permintaannya sendiri mungkin selesai dalam hitungan menit, tetapi tertahan berhari-hari karena manajer sedang bepergian, pesannya tenggelam di obrolan WhatsApp yang ramai, atau pengaju bahkan tidak tahu siapa yang memutuskan. Tidak ada yang salah: persetujuan lewat pesan berjalan baik selama tim masih kecil, lalu mulai kewalahan setiap kali ada karyawan dan cabang baru.

Persetujuan adalah alur kerja pertama yang paling jelas karena aturannya biasanya sudah ada di kepala manajemen: jenis permintaan, nilai, dan penanggung jawab. Alur kerja di sini sekadar berarti permintaan berpindah dari satu langkah ke langkah berikutnya secara otomatis menurut aturan tertulis, bukan dibawa tangan oleh seorang karyawan. Gagasan ini berlaku untuk banyak jenis permintaan: cuti, pengeluaran dan kas kecil, permintaan pembelian, diskon pada penawaran harga, dan perubahan kontrak.

Matriks persetujuan: siapa menyetujui apa sampai batas berapa

Elemen pertama adalah matriks persetujuan, satu tabel yang menjawab satu pertanyaan: untuk jenis permintaan ini dengan nilai ini, siapa yang menyetujui? Tulis berdasarkan jabatan, bukan nama, agar tidak berubah setiap kali ada yang keluar:

• Jenis permintaan: cuti, pengeluaran, pembelian, diskon, perubahan kontrak. Setiap jenis punya barisnya sendiri.
• Batas: nilai, durasi, atau tingkat diskon tempat pengambil keputusan berganti. Gunakan batas yang benar-benar dipakai perusahaan Anda, bukan angka yang dipinjam dari perusahaan lain.
• Pemberi persetujuan: jabatan yang menyetujui di dalam setiap batas, dan kapan persetujuan memerlukan dua tingkat secara berurutan.
• Syarat: apa yang harus dilampirkan sebelum permintaan sampai ke pemberi persetujuan, misalnya penawaran harga atau saldo cuti, agar permintaan tidak kembali dalam keadaan tidak lengkap.

Jangan membuat ulang apa yang sudah Anda bangun di tempat lain. Kami telah membahas permintaan pembelian secara rinci dalam Purchase Requests and Approval Limits: Who Signs What?, dan cuti serta ketentuan Undang-Undang Ketenagakerjaan dalam Leave Under Saudi Labor Law: An Approval Path, Not WhatsApp. Yang penting di sini adalah menyatukan semua jenis dalam satu logika yang dapat diikuti sistem.

Pengganti saat pemberi persetujuan tidak ada

Elemen kedua adalah pengganti. Yang paling sering menghentikan permintaan bukanlah penolakan, melainkan ketidakhadiran pemberi persetujuan: cuti, perjalanan, atau rapat panjang. Karena itu setiap jabatan dalam matriks membutuhkan pengganti yang ditunjuk sebelumnya, dengan 3 aturan sederhana:

• Delegasi berjangka: dimulai dan berakhir pada dua tanggal, dan tidak tetap terbuka setelah pemberi persetujuan kembali.
• Delegasi berbatas: pengganti hanya boleh menangani permintaan kecil, sedangkan permintaan besar menunggu pemegang wewenang atau dieskalasi.
• Delegasi tampak dalam catatan: tercatat bahwa seseorang menyetujui atas nama orang lain, bukan hanya dengan namanya sendiri.

Pemberi persetujuan tidak perlu lagi membuka ponsel saat liburan, dan karyawan tidak perlu menebak harus bertanya kepada siapa.

Tenggat waktu dan eskalasi

Elemen ketiga adalah tenggat waktu. Setiap langkah persetujuan membutuhkan waktu maksimum yang ditetapkan pemilik usaha, dan setelahnya terjadi sesuatu yang pasti, bukan permintaan yang menggantung. Eskalasi berarti permintaan otomatis berpindah ke tingkat yang lebih tinggi atau ke pengganti ketika tenggat lewat. Aturan yang Anda tulis sederhana: jika pemberi persetujuan belum menjawab dalam tenggat, sistem mengirim pengingat; jika tenggat kedua lewat, permintaan naik ke atasan atau ke pengganti.

Tenggat bukan tekanan bagi manajer. Artinya perusahaan sudah memutuskan sejak awal seberapa lama penantian yang dapat ditanggung tiap jenis permintaan. Permintaan perbaikan mendesak tidak sama dengan perubahan kontrak tahunan. Mulailah dengan tenggat realistis dari latihan di bagian ini, lalu sesuaikan setelah sebulan berjalan.

Catatan persetujuan: siapa menyetujui apa dan kapan

Elemen keempat adalah catatan, yang juga disebut jejak audit: daftar yang tidak dapat diubah dan menyimpan, untuk setiap permintaan, siapa yang mengajukan, siapa yang menyetujui atau menolak, kapan, dengan wewenang apa, dan dengan komentar apa. Catatan ini menjawab pertanyaan peninjau internal, auditor, dan manajemen tanpa menggali obrolan lama. Jika sebuah keputusan memerlukan tanda tangan pada dokumen seperti kontrak atau adendum, lihat Electronic Signatures in Saudi Arabia untuk mengetahui kapan persetujuan di dalam sistem sudah cukup dan kapan Anda memerlukan tanda tangan elektronik.

Permintaan seperti cuti memuat data pribadi karyawan. Undang-Undang Pelindungan Data Pribadi (PDPL) yang diterbitkan di situs SDAIA menyatakan dalam Pasal 19 bahwa pengendali harus mengambil langkah dan sarana organisasi, administratif, dan teknis yang diperlukan untuk melindungi data pribadi, dan dalam Pasal 31 bahwa pengendali menyimpan catatan kegiatan pemrosesan data pribadi selama jangka waktu yang ditetapkan oleh peraturan. Alur persetujuan dengan wewenang yang jelas dan catatan yang rapi membantu dalam kedua hal itu, tetapi jangka waktu dan isinya ditetapkan oleh Peraturan Pelaksana. Ini bukan nasihat hukum; konfirmasikan dengan SDAIA atau pengacara.

Pandangan Origami

Kami adalah perusahaan teknologi Arab Saudi yang membangun sistem, aplikasi, integrasi, dan solusi kecerdasan buatan. Saat membangun alur persetujuan, kami memulai dengan matriks yang ditulis di atas kertas bersama manajemen sebelum layar apa pun, karena sistem tidak dapat menerapkan aturan yang belum disepakati siapa pun, dan kami menghubungkan alur itu dengan sistem tempat permintaan benar-benar berada agar tidak ada yang mengetik ulang data.

Kami juga memastikan pengecualian tetap mungkin dan tercatat: permintaan mendesak tetap menemukan jalannya, tetapi dengan jejak di catatan, bukan lewat pesan sampingan. Keseimbangan antara disiplin dan fleksibilitas inilah dasar dari apa yang kami bangun, dan Anda dapat menemukan detailnya di halaman layanan kami.

Latihan: lacak 10 permintaan persetujuan terakhir Anda

Selama 5 hari kerja, kumpulkan 10 permintaan persetujuan terakhir Anda dari satu jenis, dan untuk masing-masing catat:

• Kapan diajukan, kapan persetujuan akhir datang, dan selisihnya dalam jam.
• Melewati berapa pemberi persetujuan, apakah ada yang tidak hadir dan siapa yang menggantikan.
• Berapa kali kembali dalam keadaan tidak lengkap, dan informasi apa yang kurang.
• Di mana persetujuan disimpan: sistem, email, WhatsApp, atau kertas.
• Apakah hari ini Anda bisa membuktikan siapa yang menyetujui dan kapan, tanpa bertanya kepada siapa pun.

Rata-rata waktu tunggu yang Anda hitung di sini menjadi dasar tenggat pertama Anda, dan itu lebih jujur daripada angka umum mana pun.

Di bagian berikutnya

Setelah permintaan mengikuti alur yang jelas, masih ada pekerjaan lain yang menyita waktu: mengetik ulang dokumen ke dalam sistem. Bagian 4 dari seri ini, Entri data manual: saat sistem membaca dokumen, menjelaskan bagaimana sistem mengambil data dari dokumen pemasok, surat jalan, dan formulir, lalu mengirim yang belum pasti kepada seseorang untuk ditinjau.

Sumber

• Undang-Undang Pelindungan Data Pribadi (PDPL) — Otoritas Data dan Kecerdasan Buatan Arab Saudi (SDAIA) — Pasal 19 tentang langkah organisasi, administratif, dan teknis untuk melindungi data pribadi, dan Pasal 31 tentang catatan kegiatan pemrosesan.
• Peraturan Pelaksana Undang-Undang Pelindungan Data Pribadi — SDAIA