Satu Guru, Dua Sekolah: Kenapa Data Karyawan Tidak Boleh Digandakan per Unit

Seorang guru bisa mengajar di SMP pada pagi hari, lalu membantu kelas di SMA pada hari tertentu. Karyawan administrasi bisa menjadi staf yayasan, tetapi juga punya tanggung jawab di satu unit sekolah. Kepala cabang bisa memegang lebih dari satu lokasi.

Di organisasi pendidikan multi-lembaga, satu orang tidak selalu identik dengan satu sekolah.

Masalah muncul ketika sistem HR dibangun dengan asumsi sebaliknya: satu sekolah = satu database karyawan.

Orangnya satu. Yang bisa berbeda adalah penempatan, peran, jadwal, dan tanggung jawabnya.

Apa yang terjadi kalau orang yang sama dibuat sebagai karyawan baru di setiap sekolah?

Pada awalnya mungkin terasa paling mudah. Guru yang mengajar di dua unit tinggal dibuat dua akun atau dua data karyawan.

Tapi begitu proses HR mulai berkembang, duplikasi itu menimbulkan pertanyaan yang sulit dijawab.

• mana data identitas yang paling benar?
• kalau nomor telepon berubah, harus diedit di berapa tempat?
• masa kerja dihitung dari sekolah pertama atau dari yayasan?
• siapa yang menyetujui izin jika orang tersebut bekerja di dua unit?
• bagaimana melihat beban kerja keseluruhan tanpa menghitung orang yang sama dua kali?

Problemnya bukan karena data HR terlalu rumit. Problemnya karena struktur datanya tidak mengikuti kenyataan organisasi.

Pisahkan identitas orang dari penempatannya

Untuk organisasi multi-unit, model yang lebih masuk akal adalah menyimpan satu identitas karyawan di level organisasi, lalu menambahkan konteks penempatan di bawahnya.

Karyawan A
       │
       ├── Unit SMP
       │     ├─ Peran: Guru
       │     └─ Jadwal / tanggung jawab unit
       │
       └── Unit SMA
             ├─ Peran: Guru pendamping
             └─ Jadwal / tanggung jawab unit

Dengan model seperti ini, identitas dasarnya tidak digandakan. Yang berbeda adalah relasinya dengan unit.

Data mana yang seharusnya milik organisasi, dan mana yang milik unit?

Level organisasi	Level unit
identitas karyawan	penempatan
kontak utama	jabatan di unit
status hubungan kerja	atasan langsung di unit
riwayat organisasi	jadwal dan aktivitas lokal
akses dasar	hak akses sesuai tanggung jawab unit

Pembagian ini tidak harus persis sama untuk setiap yayasan. Tetapi prinsipnya penting: jangan menduplikasi identitas hanya karena konteks kerjanya berbeda.

Kenapa ini penting buat guru dan karyawan?

Dari sisi pengguna, struktur data terdengar seperti urusan admin. Padahal efeknya terasa langsung.

• tidak perlu punya akun berbeda hanya karena bekerja di unit berbeda;
• jadwal dan konteks kerja bisa dipisahkan tanpa memisahkan identitas;
• pengajuan atau informasi kerja lebih mudah diarahkan ke konteks yang benar;
• perubahan profil tidak perlu diulang berkali-kali;
• riwayat kerja tidak terpecah menjadi beberapa “orang” di sistem.

Sistem yang baik seharusnya mengikuti cara orang benar-benar bekerja, bukan memaksa orang mengikuti keterbatasan struktur software.

Ini juga mengubah cara tim HR yayasan melihat tenaga kerja

Kalau data karyawan disimpan per sekolah, tim HR mudah kehilangan konteks organisasi. Orang yang sama bisa terlihat sebagai dua karyawan berbeda. Perpindahan unit terasa seperti membuat data baru. Dan perubahan struktur memerlukan pekerjaan manual di banyak tempat.

Dengan satu identitas di level organisasi, HR bisa melihat seseorang sebagai bagian dari yayasan terlebih dahulu, baru kemudian melihat di mana saja ia ditempatkan.

Pendekatan OneEduSync: organisasi dulu, penempatan setelahnya

OneEduSync dirancang dengan konteks organisasi dan unit yang terpisah tetapi saling terhubung. Seorang karyawan bisa menjadi bagian dari organisasi yang sama, lalu mendapatkan penempatan dan tanggung jawab sesuai unit tempat ia bekerja.

Bagi karyawan, tujuannya sederhana: pengalaman kerja yang lebih masuk akal. Bagi yayasan, manfaat strukturalnya lebih besar: data orang tidak pecah hanya karena organisasinya punya banyak lembaga.

Kalau yayasan Anda sedang memikirkan HR lintas sekolah, masalah ini berkaitan erat dengan cara organisasi multi-lembaga dibangun. Konteks besarnya bisa dibaca di problem yayasan multi-lembaga.