Membangun HRMS Klinik Belanda dari Makassar
Jarak tujuh jam dan bahasa Belanda tidak sebesar perbedaan cara klinik mengelola orang. Tulisan ini merangkum apa yang harus benar di HRMS kesehatan sebelum fitur terlihat lengkap.
Kerja jarak jauh yang tidak boleh “kira-kira”
Untuk Healthsoft B.V. saya membangun antarmuka web HRMS bagi klinik dan organisasi zorg di Belanda. Saya bekerja dari Makassar. Klien dan pengguna ada di zona waktu Eropa. Itu bukan halangan terbesar. Halangan terbesar adalah asumsi: saya tidak boleh mengisi kekosongan proses dengan tebakan hanya karena demo harus siap sebelum standup pagi mereka.
HRMS kesehatan bukan daftar karyawan plus cuti. Di klinik, jadwal berkaitan dengan pasien, pengganti shift, dan aturan ketenagakerjaan yang tidak bisa “kita atur nanti”. Satu field yang ambigu di formulir bisa menjadi kesalahan penggajian atau kekosongan tenaga di hari sibuk.
Yang saya kerjakan lebih dulu
Saya memulai dari alur yang orang pakai setiap minggu: melihat siapa yang bekerja, mengubah data yang memang boleh diubah, dan menelusuri status tanpa membuka tiga sistem lain. React dan Tailwind membuat iterasi UI cepat. Kecepatan itu berbahaya jika dipakai untuk menambah layar sebelum aturan bisnis jelas.
Karena itu setiap form saya uji dengan pertanyaan yang terdengar sederhana. Siapa yang boleh melihat gaji? Apa yang terjadi jika seseorang dipindah klinik? Apakah status “aktif” berarti masih digaji, masih boleh login, atau masih dijadwalkan? Tiga arti itu sering tercampur di produk HR yang tumbuh organik.
Komunikasi lintas negara
Saya menulis pertanyaan dalam bahasa yang bisa diterjemahkan tanpa kehilangan makna. Hindari slang. Hindari “nanti kita lihat”. Kirim tangkapan layar beranotasi, bukan paragraf panjang tanpa konteks. Jika ada istilah Belanda yang tidak saya pahami, saya minta contoh nyata: satu karyawan, satu minggu, satu pengecualian.
Contoh mengalahkan spesifikasi. Spesifikasi mengatakan “dukung cuti”. Contoh mengatakan “bidan ini cuti dua hari, penggantinya hanya bisa pagi, dan klinik cabang B tidak boleh melihat catatan cabang A”.
Privasi sebagai batasan desain
Data tenaga kesehatan dan data yang menyinggung pasien, bahkan secara tidak langsung, tidak boleh menjadi “detail backend”. Saya merancang layar seolah setiap tabel bisa dibuka di ruang yang tidak sepi. Nama, jadwal, dan catatan internal perlu pemisahan yang terlihat oleh pengguna, bukan hanya di aturan API.
- Jangan menaruh data sensitif di URL atau di log yang mudah disalin.
- Jangan menampilkan kolom “karena sudah ada di response”.
- Jangan mengandalkan “pengguna tidak akan menekan tombol itu”.
Kesimpulan
Membangun HRMS dari negara lain mengajarkan saya untuk memperlambat rasa ingin menyelesaikan layar. Yang dinilai klien bukan seberapa cepat komponen React jadi. Yang dinilai adalah apakah klinik bisa mengandalkan sistem itu pada Senin pagi tanpa menelepon saya di malam Minggu Makassar.