Desain sistem permintaan cuti untuk kebijakan dan persetujuan yang jelas

Apa yang rusak di sebagian besar proses cuti

Orang mengharapkan permintaan cuti terasa seperti menjadwalkan rapat: pilih tanggal, lihat saldo, dapat jawaban jelas ya atau tidak, dan muncul di semua tempat yang perlu. Ketika tidak bekerja seperti itu, tim kembali ke “tinggal kirim pesan,” dan sistem jadi tugas pencatatan daripada alat yang dapat dipercaya.

Permintaan biasanya macet di handoff: thread email yang tidak sampai pada manajer yang tepat, spreadsheet yang tak pernah diperbarui, atau persetujuan lewat chat yang tak bisa diaudit nanti. Karyawan pikir mereka aman, manajer pikir HR yang mengurus, dan HR baru tahu saat penggajian bahwa saldonya salah.

Tujuan nyata desain sistem permintaan cuti itu membosankan tapi penting: saldo yang benar, persetujuan yang jelas, dan satu sumber kebenaran. Jika saldomu benar tapi persetujuan tidak jelas, manajer akan terus bertanya “Apakah saya sudah menyetujui ini?” Jika persetujuan sempurna tapi kalender salah, tim masih akan jadwal ganda.

Empat kelompok bergantung pada alur yang sama, tapi untuk alasan berbeda:

• Karyawan: permintaan cepat, status instan, dan kepercayaan bahwa tercatat
• Manajer: permintaan yang tepat dirutekan kepada mereka, dengan konteks cukup untuk memutuskan
• HR/penggajian: kebijakan diterapkan konsisten dan saldo sesuai aturan gaji
• Bisnis: visibilitas tim tanpa mengekspos detail pribadi

"Alur yang dapat dibaca" berarti Anda bisa melihat langkah-langkahnya dan menjelaskannya dengan bahasa biasa: apa yang memicu permintaan, siapa yang menyetujui, apa yang terjadi saat ditolak, dan apa yang ditulis kembali (saldo, status, kalender). Jika Anda tidak bisa menjelaskannya dengan cepat, orang akan melewatinya.

Alat seperti AppMaster bisa membantu dengan menjaga logika tetap visual dan terpusat, sehingga perubahan kebijakan tidak berubah jadi labirin email dan pengecualian.

Data dasar yang Anda perlukan (tanpa membangun berlebihan)

Alat cuti yang baik sebagian besar adalah sekumpulan catatan yang rapi dan beberapa relasi yang jelas. Jika Anda benar di dasar, sisa desain sistem permintaan cuti tetap bisa dibaca, bahkan ketika kebijakan dan persetujuan berkembang nanti.

Mulai dengan satu set objek inti kecil yang bisa Anda jelaskan dalam satu menit:

• Employee: siapa yang mengajukan cuti (dan siapa yang menyetujuinya).
• TimeOffRequest: permintaan itu sendiri (tanggal, jenis, status).
• Policy: aturan untuk jenis cuti (PTO, sakit, tanpa gaji).
• Balance: jumlah tersedia saat ini untuk karyawan dan kebijakan.
• Approval: keputusan dan komentar yang terikat pada permintaan.

Untuk permintaan, field yang mencegah sakit kepala dunia nyata tidaklah mewah. Mereka spesifik. Simpan tanggal/waktu mulai dan selesai, apakah itu parsial, dan zona waktu karyawan saat permintaan dibuat. Tambahkan alasan singkat, dan izinkan lampiran jika proses HR Anda membutuhkan bukti (misalnya surat dokter). Buat lampiran bersifat opsional agar tidak menghalangi PTO normal.

Status harus sedikit dan dapat diprediksi: draft (tersimpan tapi belum dikirim), submitted, approved, rejected, dan canceled. Hindari status ekstra seperti "pending HR" kecuali benar-benar diperlukan.

Jangan lewatkan jejak audit. Bahkan minimal "siapa mengubah apa dan kapan" akan menyelamatkan Anda saat perselisihan. Minimal, log submit, approve, reject, cancel, dan setiap edit tanggal.

Untuk tim, lokasi, dan departemen, perlakukan sebagai data referensi terpisah. Kaitkan karyawan ke grup ini, dan kaitkan kebijakan ke grup yang berlaku. Dengan begitu, saat seseorang pindah kantor, Anda cukup memperbarui satu record karyawan, bukan setiap kebijakan.

Jika Anda membangun ini di AppMaster, jaga setiap objek sederhana dulu, lalu tambahkan validasi dan langkah alur kerja setelah data stabil.

Aturan kebijakan: buat jelas dan dapat diuji

Kebijakan yang baik sengaja membosankan. Orang harus bisa memprediksi hasil sebelum menekan Submit. Dalam desain sistem permintaan cuti, cara tercepat kehilangan kepercayaan adalah ketika permintaan yang sama disetujui minggu ini dan ditolak minggu depan.

Mulai dengan menamai jenis cuti dan menulis satu kalimat sederhana untuk masing-masing. Liburan atau PTO adalah waktu yang direncanakan untuk tidak masuk kerja. Cuti sakit adalah waktu tak terencana terkait kesehatan. Cuti tanpa gaji adalah cuti tanpa bayaran. Cuti orang tua sering punya tanggal dan dokumen khusus. Comp time diperoleh dari jam ekstra dan dihabiskan seperti PTO.

Aturan kelayakan harus dibaca seperti checklist, bukan dokumen legal. Buat eksplisit: siapa yang bisa menggunakannya (full-time, part-time, kontraktor), kapan dimulai (setelah masa percobaan, setelah X hari), dan apakah tergantung masa kerja. Jika ada pengecualian, tulis pengecualian sebagai aturan tersendiri, bukan catatan kaki.

Aturan permintaan biasanya tempat kebingungan dimulai. Jelaskan periode pemberitahuan, tanggal blokir, dan unit waktu terkecil yang diizinkan. Misalnya: "Permintaan cuti harus diajukan 5 hari kerja sebelumnya, kecuali darurat yang disetujui HR" adalah bisa diuji. "Ajukan lebih awal" bukanlah aturan yang bisa diuji.

Aturan carryover dan kadaluarsa harus muat satu kalimat. Contoh: "Hingga 40 jam dibawa ke tahun berikutnya dan kedaluwarsa pada 31 Maret." Jika perlu kalimat kedua, itu pertanda kebijakan terlalu kompleks.

Cara sederhana menyinkronkan teks kebijakan dan logika aturan:

• Beri setiap aturan ID singkat (mis. PTO-NOTICE-5D)
• Simpan teks bahasa biasa di samping konfigurasi aturan
• Tambahkan 2–3 contoh kasus per aturan (disetujui atau ditolak) sebagai tes
• Ubah teks kebijakan hanya saat konfigurasi aturan berubah (dan sebaliknya)

Contoh: Seorang karyawan dalam masa percobaan meminta 2 jam PTO untuk besok. Sistem harus memblokirnya dengan dua alasan yang mudah dibaca: "PTO dimulai setelah 60 hari" dan "PTO membutuhkan pemberitahuan 5 hari kerja." Jika Anda membangun di AppMaster, tempatkan pesan-pesan itu dekat node aturan agar pembaruan tidak menyimpang.

Matematika akrual: pola yang menimbulkan kebingungan

Akrual adalah tempat desain sistem permintaan cuti sering berantakan, karena aturan kecil menumpuk. Tujuannya bukan matematika canggih. Tujuannya hasil yang dapat diprediksi yang sesuai ekspektasi HR dan karyawan saat mereka memeriksa saldo.

Satu kebingungan umum adalah mencampur gaya akrual. Beberapa perusahaan menambahkan jam setiap periode gaji, lainnya bulanan, ada yang akrual per jam kerja, dan ada yang memberikan jumlah tahunan penuh pada tanggal tetap. Masalah muncul saat Anda hanya menyimpan "saldo" dan lupa "bagaimana diperoleh." Simpan catatan peristiwa yang jelas: grant, accrue, adjustment, dan usage.

Prorata adalah jebakan lain. Karyawan baru yang mulai pertengahan bulan, atau yang berubah dari part-time ke full-time, seharusnya tidak perlu perbaikan spreadsheet manual. Tentukan satu aturan dan konsisten. Misalnya: prorata berdasarkan hari kalender dalam periode, atau berdasarkan jam terjadwal. Mana pun yang dipilih, tuliskan dengan jelas dan enkode di semua tempat.

Kaps dan saldo negatif menyebabkan tiket "terlihat salah". Jika mengizinkan carryover hingga batas, terapkan batas pada momen tertentu (akhir tahun, akhir periode akrual, atau setelah setiap akrual). Jika saldo negatif diizinkan, tentukan batas dan apa yang terjadi saat pemutusan kerja.

Aturan pembulatan membuat pergeseran diam-diam. Pilih satu level pembulatan (menit, kuartal jam, atau setengah hari) dan terapkan konsisten pada akrual dan penggunaan. Jika Anda mengakumulasi dalam menit tapi permintaan dalam setengah hari, karyawan akan selalu merasa sistem meleset.

Permintaan dan koreksi bertanggal mundur membutuhkan jejak audit. Jika seseorang mengajukan permintaan untuk minggu lalu, sistem harus menghitung ulang sejak tanggal efektif dan mencatat perubahan.

Checklist sederhana yang mencegah sebagian besar sengketa:

• Simpan perubahan saldo sebagai transaksi bertanggal, bukan hanya satu angka
• Hitung ulang dari tanggal efektif saat input kebijakan berubah
• Terapkan cap dan pembulatan dalam satu fungsi bersama
• Pisahkan penyesuaian manual dari logika akrual
• Selalu tunjukkan "sebagai pada tanggal" untuk saldo yang ditampilkan

Di AppMaster, ini biasa dipetakan ke tabel Transactions plus proses bisnis kecil yang menghitung ulang saldo saat permintaan disetujui atau dikoreksi.

Persetujuan manajer: routing sederhana yang tetap menutup kasus tepi

Alur persetujuan manajer harus menjawab satu pertanyaan: siapa yang bisa mengatakan “ya” dengan percaya diri? Jika Anda mencoba memodelkan setiap detail bagan organisasi, desain sistem permintaan cuti menjadi sulit dibaca dan bahkan lebih sulit diperbaiki.

Mulai dengan satu aturan default: manajer langsung karyawan menyetujui. Tambahkan hanya pengecualian yang mengubah risiko atau akuntabilitas. Jaga urutan aturan eksplisit, sehingga Anda bisa menjelaskan hasil tanpa menggali pengaturan.

Persetujuan satu langkah vs multi-langkah

Sebagian besar tim bisa memakai satu langkah persetujuan untuk PTO standar. Tambah langkah hanya ketika permintaan memengaruhi penggajian, kepatuhan, atau cakupan lintas tim.

Polanya yang umum dan mudah dibaca:

• Satu langkah: Manajer menyetujui untuk PTO standar dan cuti tanpa gaji.
• Dua langkah: Manajer lalu HR untuk jenis cuti yang membutuhkan dokumen atau pemeriksaan kebijakan.
• Penyetuju kedua: Tambahkan kepala departemen hanya saat ketidakhadiran memengaruhi cakupan bersama (mis. rotasi on-call).
• Auto-approve: Permintaan risiko rendah, seperti 1–2 jam untuk janji, atau waktu yang sudah disetujui sebelumnya di jadwal.
• Tanpa manajer: Persetujuan HR saja untuk kontraktor atau peran tanpa manajer yang jelas.

Delegasi, penolakan, dan pengiriman ulang

Persetujuan gagal ketika penyetuju sedang tidak hadir. Jadikan delegasi sebagai aturan kelas satu, bukan solusi manual. Jika manajer ditandai sedang out-of-office, rute ke delegasi; jika tidak ada delegasi, rute ke manajer si manajer (atau HR sebagai cadangan). Selalu catat aturan mana yang memilih penyetuju.

Penolakan dan edit adalah tempat sistem jadi berantakan. Jaga sederhana: penolakan menutup permintaan dengan alasan wajib. Jika karyawan mengubah tanggal atau jenis cuti, perlakukan sebagai pengajuan ulang dan jalankan lagi routing dari awal. Itu mencegah "setengah-disetujui" yang tidak lagi sesuai dengan apa yang disetujui.

Contoh praktis: Alex meminta 3 hari cuti sakit. Sistem merutekannya ke manajer, tapi karena ini tipe cuti yang dikontrol kebijakan, HR mendapat langkah kedua hanya setelah persetujuan manajer. Jika manajer sedang tidak ada, delegasi yang menyetujui, dan jejak audit menunjukkan alasan.

Jika Anda membangun ini di AppMaster, jaga logika routing dalam satu proses visual dengan set aturan kecil yang urutannya jelas, sehingga siapa pun bisa membaca dan memeliharanya nanti.

Aturan validasi sebelum permintaan diteruskan

Validasi yang baik menjaga desain sistem permintaan cuti tetap terbaca karena mencegah kasus khusus bocor ke persetujuan. Targetkan aturan yang mudah dijelaskan dan diuji.

Mulai dengan aturan pemesanan. Cek tumpang tindih harus menangkap konflik dengan cuti yang sudah disetujui dan permintaan yang sedang menunggu. Jelaskan parsial hari: simpan tanggal plus unit sederhana seperti AM, PM, atau jam agar setengah hari tidak dibulatkan menjadi hari penuh secara tidak sengaja. Juga putuskan apa yang dilakukan pada akhir pekan dan hari libur perusahaan: blokir atau izinkan tapi abaikan dalam perhitungan hari.

Pemeriksaan saldo lebih rumit dari yang terlihat. Banyak tim memvalidasi saldo saat submit (agar orang tidak spam permintaan) dan memeriksa kembali saat approve (karena akrual dan persetujuan lain bisa mengubah saldo). Jika melakukan keduanya, tunjukkan kepada pengguna titik mana yang gagal.

Berikut sekumpulan validasi yang bersih dan mencakup sebagian besar kasus:

• Tanggal valid (mulai sebelum selesai, zona waktu sama, tidak ada pilihan setengah hari yang hilang)
• Tidak tumpang tindih dengan cuti yang ada (termasuk setengah hari)
• Jumlah hari mengecualikan akhir pekan dan hari libur (berdasarkan kebijakan Anda)
• Lampiran wajib ada untuk jenis cuti tertentu (mis. surat sakit)
• Saldo cukup (cek saat submit, dan lagi saat approve)

Cek cakupan tim bisa membantu, tapi hindari pemblokiran keras kecuali perlu. Default yang lebih baik adalah peringatan yang membiarkan manajer memutuskan. Contoh: "Dua orang di tim Anda sudah cuti hari itu. Tetap kirim?"

Buat pesan kesalahan yang adil dan bisa diperbaiki. Beritahu pengguna apa yang gagal, di mana, dan bagaimana memperbaikinya. Contoh: "Permintaan Anda tumpang tindih dengan PTO yang disetujui pada 12 Mar (PM). Pilih waktu lain atau edit permintaan yang ada."

Jika Anda membangun ini di AppMaster, letakkan validasi dekat dengan formulir permintaan dan gunakan ulang pengecekan yang sama di langkah persetujuan, agar aturan tidak menyimpang.

Langkah demi langkah: alur yang dapat dibaca yang bisa Anda bangun dan pelihara

Desain sistem permintaan cuti yang baik terasa membosankan dengan cara terbaik: setiap permintaan mengikuti jalur yang sama, dan setiap keputusan punya satu alasan jelas. Cara termudah menjaga keterbacaan adalah memisahkan data kebijakan (apa aturannya) dari logika alur kerja (apa yang terjadi saat seseorang klik Submit).

Berikut urutan yang tetap sederhana meski Anda menambah jenis cuti nanti:

• Masukkan setiap jenis cuti dan aturan di satu tempat (nama, kelayakan, carryover, periode blokir). Jika aturan tidak tertulis di sini, maka aturan itu seharusnya tidak ada di tempat lain.
• Modelkan saldo sebagai garis waktu, bukan satu angka. Simpan opening balance, earned (accrual), used, dan adjustments sehingga Anda bisa menjelaskan saldo pada tanggal mana pun.
• Bangun formulir permintaan dengan pemeriksaan awal. Validasi tanggal, setengah hari, tumpang tindih, periode pemberitahuan, dan "cukup saldo pada tanggal mulai" sebelum persetujuan dimulai.
• Rute persetujuan menggunakan set peran kecil (karyawan, manajer langsung, HR). Tambahkan pengecualian sebagai data (mis. "butuh tinjauan HR jika >10 hari") daripada meng-hardcode kasus khusus.
• Buat acara kalender hanya setelah persetujuan, dan perlakukan sebagai catatan sinkron yang bisa diperbarui atau dibatalkan saat permintaan berubah.

Jaga alur tetap terbaca dengan mencatat setiap keputusan dalam bahasa biasa (mis. "Ditolak: tumpang tindih dengan cuti yang sudah disetujui"). Jika menggunakan alat visual seperti Business Process Editor AppMaster, beri label langkah seperti yang manusia akan bacakan.

Sebelum diluncurkan, uji dengan skenario nyata: permintaan bertanggal mundur, manajer cuti, perubahan kebijakan di tengah tahun, dan edit setelah persetujuan. Jika hasil mengejutkan HR, aturannya belum cukup jelas.

Integrasi kalender yang tetap akurat seiring waktu

Kalender harus menjawab satu pertanyaan dengan cepat: siapa yang tidak masuk, dan kapan. Jangan jadikan event kalender sebagai seluruh catatan permintaan. Taruh hanya apa yang membantu penjadwalan, dan simpan sisanya di sistem HR Anda.

Untuk isi event, buat konsisten. Default yang baik adalah judul singkat seperti "Out of office - Alex Kim" plus jenis cuti jika relevan ("PTO", "Sick"). Jaga detail seminimal mungkin demi privasi. Banyak tim memilih menampilkan event sebagai "Busy" dan menyimpan alasan, saldo, dan catatan hanya dalam permintaan.

Perlakukan event kalender sebagai cermin, bukan sumber

Setiap permintaan butuh ID internal yang stabil, dan setiap event kalender harus menyimpan ID itu (mis. di custom field atau deskripsi). Dengan begitu Anda bisa membuat, memperbarui, dan menghapus event yang tepat saat permintaan berubah.

Menangani status adalah tempat sistem sering menyimpang. Putuskan sejak awal apakah permintaan tentatif ditampilkan sama sekali. Jika menampilkannya, buat perbedaannya jelas (mis. prefix judul "Pending" dan pengaturan ketersediaan berbeda). Saat disetujui, perbarui event yang sama daripada membuat yang baru. Jika dibatalkan atau ditolak setelah terlihat, hapus event agar kalender tidak menipu.

Zona waktu dan hari "aneh"

Zona waktu paling sering bikin masalah dengan cuti sehari penuh dan setengah hari. Simpan mulai dan selesai sebagai timestamp tepat di zona waktu lokal karyawan, dan juga simpan zona waktu itu pada permintaan.

Gunakan event all-day hanya untuk cuti penuh. Untuk setengah hari, buat event ber-waktu (mis. 13:00–17:00) sehingga rekan di zona lain melihat tumpang tindih yang benar.

• Hari penuh: event all-day di zona waktu karyawan
• Parsial: event ber-waktu dengan timestamp mulai dan selesai
• Multi-hari: event all-day biasanya oke, tapi periksa aturan akhir tanggal (inklusif vs eksklusif)

Jika sinkronisasi kalender gagal, jangan sembunyikan. Antrikan pekerjaan, lakukan retry dengan backoff, dan tunjukkan status jelas "Kalender tidak diperbarui" dengan aksi manual "retry sync". Di alat seperti AppMaster, ini biasanya proses latar belakang plus layar admin yang mencantumkan percobaan sinkron gagal sehingga HR bisa memperbaiki tanpa mengedit permintaan.

Kesalahan umum dan cara menghindarinya

Sebagian besar kegagalan dalam desain sistem permintaan cuti terjadi saat aturan berkembang diam-diam. Sistem masih “berfungsi”, tapi tak ada yang percaya saldonya, dan setiap kasus aneh jadi tiket dukungan.

Kesalahan 1: Logika akrual tersembunyi di pengecualian

Jika akrual terpecah ke banyak kasus khusus (karyawan baru, carryover, cuti tanpa gaji, part-time), orang tidak bisa memprediksi saldo.

Jaga satu model akrual yang jelas per jenis cuti, lalu tambahkan pengecualian sebagai aturan bernama dan dapat diuji. Tuliskan beberapa contoh karyawan dan saldo yang diharapkan pada tanggal tertentu, dan cek ulang setiap kali kebijakan berubah.

Kesalahan 2: Alur persetujuan bercabang tanpa akhir

Alur approval yang bercabang terus-menerus jadi tidak bisa diuji, dan manajer tidak tahu kenapa permintaan pergi ke orang lain.

Pola yang lebih aman:

• Satu penyetuju default (biasanya manajer langsung)
• Satu penyetuju opsional kedua (HR atau kepala departemen) berdasarkan kondisi sederhana
• Satu fallback jelas saat penyetuju tidak ada (delegasi atau manajer berikutnya)
• Satu status akhir per permintaan (approved, rejected, canceled)

Kesalahan 3: Mencampur teks kebijakan dan matematika di satu field

Teks kebijakan untuk manusia (apa yang dihitung, siapa yang eligible). Aturan matematika untuk sistem (tarif, cap, pembulatan, carryover). Simpan terpisah agar Anda bisa memperbarui kata-kata tanpa mengubah perhitungan, dan menguji perhitungan tanpa menulis ulang handbook.

Kesalahan 4: Edit dan pembatalan tidak tercatat

Jika Anda menimpa permintaan, Anda kehilangan alasan di balik perubahan saldo.

Selalu simpan jejak audit: siapa mengubah apa, kapan, dan nilai sebelumnya. Di AppMaster, ini mudah dimodelkan sebagai tabel riwayat permintaan plus transisi status di Business Process.

Kesalahan 5: Zona waktu dan hari libur dipikirkan belakangan

Cuti membentang tanggal, tapi persetujuan dan entri kalender menggunakan timestamp. Normalisasi ke satu "zona waktu kebijakan" dan simpan juga zona waktu lokal karyawan. Juga putuskan lebih awal apakah hari libur umum mengurangi jumlah hari yang diminta, dan terapkan aturan itu konsisten.

Daftar periksa cepat sebelum diluncurkan

Sebelum mengumumkannya ke semua orang, jalankan serangkaian cek singkat dengan karyawan nyata, seorang manajer, dan seseorang dari HR. Anda ingin memastikan sistem terasa jelas, bukan sekadar berfungsi.

Gunakan daftar ini sebagai gerbang go/no-go untuk desain sistem permintaan cuti Anda:

• Visibilitas saldo: Karyawan bisa melihat saldo hari ini dan bagaimana cuti yang sudah disetujui mendatang mengubahnya (agar tidak "menemukan" saldo negatif kemudian).
• Kejelasan kebijakan: Setiap aturan ditulis dalam bahasa biasa (carryover, tanggal blokir, pemberitahuan minimal, setengah hari) dan logika cocok persis dengan kata-kata itu.
• Validasi membantu: Saat permintaan diblokir, pesan menjelaskan apa yang harus diubah (tanggal, jenis cuti, jam, lampiran hilang), bukan hanya "error" atau "tidak diizinkan."
• Persetujuan siap-manajer: Manajer bisa menyetujui dari satu layar dengan konteks cukup (sisa saldo, tumpang tindih ketidakhadiran tim, catatan serah terima) dan bisa meminta perubahan tanpa bolak-balik panjang.
• Kalender dan audit: Event kalender dibuat dan disinkronkan saat approve, ubah, dan cancel, dan setiap perubahan status dicatat siapa dan kapan.

Tes praktis cepat: buat satu permintaan, setujui, edit tanggalnya, lalu batalkan. Jika ada langkah yang meninggalkan saldo salah, event kalender kadaluarsa, atau status tak jelas, perbaiki sebelum peluncuran.

Jika Anda membangun di AppMaster, jaga keterbacaan alur dengan memberi nama setiap langkah sesuai tindakan pengguna (Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event) sehingga perilaku tetap jelas saat kebijakan berkembang.

Contoh skenario: dari permintaan ke undangan kalender

Karyawan baru, Maya, mulai pada 10 Maret. Desain sistem permintaan cuti Anda mendukung akrual bulanan, jadi Maya mendapat PTO setiap tanggal 1 setiap bulan. Pada 12 April, dia meminta setengah hari: 3 jam Jumat depan untuk janji medis.

Apa yang dilihat masing-masing orang berbeda:

• Karyawan (Maya): saldo saat ini, berapa jam yang akan digunakan permintaan ini, dan peringatan jelas jika akan negatif.
• Manajer: ringkasan singkat (tanggal, jam, catatan cakupan) plus opsi approve, deny, atau delegate.
• HR: kebijakan yang dipakai untuk perhitungan, jejak audit, dan cara menghitung ulang jika aturan berubah.

Maya mengirim permintaan. Manajernya sedang cuti, jadi sistem mengecek pengaturan delegasi dan merutekannya ke manajer pengganti. Manajer pengganti menyetujui.

Saat persetujuan, dua hal terjadi: permintaan dikunci ke versi kebijakan yang dipakai, dan event kalender dibuat berjudul "Maya - PTO (3h)" pada tanggal dan jendela waktu yang benar. Maya langsung melihat status "Approved" dan status kalender "Added."

Pada bulan Juni, HR memperbarui kebijakan di tengah tahun (mis. akrual naik setelah 90 hari). Saldo perlu dihitung ulang, tapi permintaan yang sudah disetujui sebelumnya tidak boleh diubah diam-diam. Sistem menghitung ulang saldo Maya dari tanggal efektif ke depan, sambil menyimpan jejak audit nilai sebelum/sesudah.

Seminggu kemudian, Maya mengubah tanggal permintaan (janji dipindah). Karena cuti sudah disetujui, perubahan menjadi "Change request" baru yang kembali ke penyetuju delegasi. Setelah disetujui lagi, event kalender yang sama diperbarui (ID event sama), bukan digandakan.

Ini mudah dimodelkan di alat seperti AppMaster dengan menjaga alur terbaca: satu jalur persetujuan, satu cek delegasi, satu langkah buat/perbarui kalender, dan aksi perhitungan ulang terpisah yang bisa dijalankan HR saat kebijakan berubah.

Langkah selanjutnya: kirim versi pertama dan iterasi dengan aman

Cara paling aman menyelesaikan desain sistem permintaan cuti adalah merilis versi kecil yang bisa dipercaya orang, lalu kembangkan. Mulai dengan satu kebijakan (mis. PTO) dan satu jalur persetujuan (karyawan -> manajer). Setelah terasa membosankan dan andal, tambahkan jenis cuti, wilayah, atau kasus tepi.

Sebelum membuat lebih banyak aturan, tentukan di mana sumber kebenaran berada. Jika sistem HR Anda adalah master, aplikasi Anda sebaiknya memvalidasi, merutekan persetujuan, dan menyinkronkan hasil kembali. Jika aplikasi Anda yang menjadi master, Anda butuh log audit yang lebih jelas dan rencana untuk apa yang terjadi saat data HR berubah (manajer baru, pemindahan departemen, tanggal pemutusan).

Rencana rilis praktis pertama:

• Implementasikan satu jenis cuti dengan saldo jelas dan satu aturan akrual.
• Tambahkan satu langkah persetujuan manajer dan satu jalur override HR.
• Buat sinkronisasi kalender sederhana hanya untuk cuti yang disetujui.
• Pertahankan layar admin tempat pengaturan kebijakan dapat dibaca oleh pemilik non-teknis.
• Tambahkan pelaporan dasar: siapa yang cuti, dan ketidakhadiran yang akan datang.

Tulis 5–10 kasus uji nyata dan jalankan ulang setelah setiap perubahan. Gunakan kasus dari tim Anda sendiri, bukan contoh yang dibuat-buat. Misalnya: seseorang mengajukan Jumat cuti pada Kamis, seseorang mengubah permintaan setelah disetujui, atau manajer menyetujui sementara karyawan di zona waktu berbeda.

Jika Anda membangun tanpa kode, keterlihatan sama pentingnya dengan fitur. Di AppMaster, Anda bisa menjaga model data (jenis cuti, saldo, persetujuan) dan alur persetujuan di editor visual, sehingga HR dan ops bisa meninjau apa yang sebenarnya dilakukan sistem. Anda juga bisa mengekspos API untuk sinkronisasi kalender dan menghasilkan kode sumber bersih saat kebijakan berkembang, tanpa menumpuk perbaikan berantakan.

Saat versi pertama stabil, kembangkan satu dimensi pada satu waktu: lebih banyak kebijakan, aturan routing lebih banyak, lalu integrasi lebih banyak.