Panduan Teknis RDM & Operasional Digital Madrasah
Pusat panduan praktis untuk operator, guru, dan pengelola layanan: mulai dari master data, siklus penilaian, finalisasi rapor, keamanan akun, troubleshooting, backup, hingga jalur eskalasi teknis.
Gunakan halaman ini sebagai peta kerja, bukan sebagai satu-satunya sumber kebenaran.
Kebijakan akademik, versi aplikasi, jadwal, dan fitur resmi tetap perlu dikonfirmasi pada sumber resmi/otoritas yang relevan. Hosch.id memusatkan praktik operasional agar tim madrasah lebih mudah menentukan langkah berikutnya.
Peran, master data, rombel, akun, semester, dan kesiapan sistem.
Workflow guru, pemantauan progres, P5RA/kokurikuler, dan validasi bertahap.
Sampling, quality control, preview, finalisasi, dan arsip.
Keamanan, troubleshooting, backup/restore, provider boundary, dan eskalasi.
RDM diperlakukan sebagai alur data penilaian—bukan sekadar layar input nilai.
Keandalan hasil sangat dipengaruhi oleh kualitas master data, kewenangan akun, konsistensi input, validasi, dan proses finalisasi. Fitur audit trail, status, atau histori perubahan hanya disebut bila memang tersedia pada versi/konfigurasi yang digunakan.
Data master
Identitas lembaga, peserta didik, rombel, mapel, semester, dan penugasan menjadi fondasi sebelum input nilai.
Data penilaian
Input guru perlu konsisten dengan konteks kelas, mapel, semester, dan parameter penilaian yang berlaku.
Quality control
Preview dan sampling digunakan untuk menemukan pola anomali sebelum distribusi rapor secara luas.
Operasional teknis
Akun, browser, URL, jaringan, server, database, dan backup menjadi konteks saat masalah terjadi.
Pisahkan tanggung jawab agar kesalahan data tidak menjadi “masalah operator” semata.
| Peran | Fokus | Sebelum finalisasi |
|---|---|---|
| Admin / Operator | Master data, akun/role, konfigurasi dasar, dukungan teknis, backup operasional. | Pastikan struktur data dan akses siap digunakan. |
| Guru mapel / kelas | Input, verifikasi konteks, koreksi data penilaian pada kewenangannya. | Pastikan nilai/deskripsi yang menjadi tanggung jawabnya lengkap dan benar. |
| Koordinator P5RA / kokurikuler | Struktur proyek, target, eviden, dan narasi penilaian sesuai kebijakan madrasah. | Pastikan data proyek lengkap sebelum cetak/finalisasi. |
| Pimpinan / penanggung jawab | Kebijakan internal, tenggat, otorisasi, dan penyelesaian konflik data/prosedur. | Pastikan keputusan final mengikuti ketentuan institusi yang berlaku. |
Distribusikan pekerjaan sepanjang semester; jangan menunggu fase cetak.
Validasi profil, tahun/semester, mapel, rombel, peserta didik, dan akun.
Pantau kelengkapan input dan tangani anomali secara bertahap.
Tentukan tenggat internal dan lakukan sampling lebih awal.
Periksa identitas, mapel, nilai, deskripsi, layout, dan data proyek.
Preview, cetak/unduh, backup, dan dokumentasikan perubahan akhir.
Validasi sumber masalah sebelum guru mulai mengisi nilai dalam skala besar.
Profil lembaga
Periksa identitas yang ditampilkan pada rapor dan kesesuaiannya dengan data institusi yang sah.
Rombel & mapel
Pastikan struktur kelas, mapel, dan penugasan tidak tumpang tindih atau salah konteks.
Akun & role
Verifikasi siapa yang berhak melihat, mengubah, atau memfinalisasi data tertentu.
Peserta didik
Periksa nama, identitas, status aktif, dan pemetaan kelas sebelum finalisasi.
Input bertahap, cek konteks, dan jangan mengubah template tanpa memahami konsekuensinya.
Konfirmasi konteks
Sebelum menyimpan, pastikan kelas, mapel, semester, jenis penilaian, dan akun yang aktif sudah benar.
Input bertahap
Kurangi penumpukan pekerjaan di akhir semester agar koreksi masih memiliki waktu.
Template impor
Gunakan template sesuai versi aplikasi; struktur kolom, format, dan instruksi impor dapat berubah.
Verifikasi setelah impor
Sampling beberapa entri setelah upload untuk memastikan data masuk pada konteks yang benar.
Pisahkan desain proyek dari pekerjaan input ke aplikasi.
Tema, target, eviden, narasi, dan keputusan penilaian ditetapkan melalui proses akademik madrasah. Aplikasi digunakan untuk merekam data sesuai fitur yang tersedia—bukan untuk menggantikan kebijakan akademik.
Tema, tujuan, aktivitas, dan pihak yang bertanggung jawab.
Sesuaikan dimensi/elemen/indikator dengan kebijakan yang digunakan.
Catat bukti proses dan hasil yang relevan.
Buat catatan yang konsisten dan dapat dipertanggungjawabkan.
Rekam pada modul yang tersedia lalu periksa hasil sebelum final.
Sampling adalah alat deteksi—bukan bukti bahwa seluruh rapor pasti benar.
Sampling per rombel
Pilih beberapa rapor dengan kondisi berbeda. Jumlah sampel menyesuaikan risiko, waktu, dan ukuran kelas; tidak ada angka minimum universal pada panduan ini.
Cross-check identitas
Periksa nama, identitas, kelas, mapel, dan parameter yang muncul pada hasil.
Temukan pola
Jika kesalahan berulang, telusuri sumber master/configuration sebelum memperbaiki satu per satu.
Catat koreksi
Perubahan material sebaiknya dapat ditelusuri melalui catatan kerja, tiket, log, atau mekanisme yang tersedia.
Preview dulu, baru cetak atau distribusikan.
Parameter cetak
Periksa tahun, semester, tanggal, identitas, dan parameter lain yang tersedia pada versi aplikasi.
Preview PDF
Periksa halaman kosong, teks terpotong, identitas salah, data hilang, dan urutan halaman.
Browser permissions
Izinkan pop-up/download hanya untuk domain RDM yang telah diverifikasi bila fitur cetak memang memerlukannya.
Arsip sebelum perubahan besar
Lakukan backup sebelum update, impor massal, migrasi, atau tindakan lain yang berisiko mengubah banyak data.
Amankan kredensial, URL, role, perangkat, dan proses serah-terima.
Halaman ini hanya memberi prinsip ringkas. Kebijakan dan prosedur keamanan mendalam berada pada halaman khusus.
Satu URL rujukan
Gunakan satu alamat resmi yang dikomunikasikan institusi untuk mengurangi kebingungan akibat link lama atau palsu.
Least privilege
Berikan hak akses sesuai tugas. Jumlah admin utama tidak ditetapkan secara universal; sesuaikan kebutuhan dan risiko.
Password & MFA
Gunakan kata sandi kuat dan MFA bila tersedia. Jangan membagikan kredensial melalui kanal yang tidak sesuai kebijakan institusi.
Session hygiene
Logout setelah selesai, terutama pada perangkat bersama, dan jangan menyimpan kredensial pada perangkat yang tidak dikelola.
Mulai dari gejala dan boundary; hindari perubahan acak pada database.
| Gejala | Periksa lebih dulu | Tindakan aman |
|---|---|---|
| Latency / timeout | Apakah terjadi di semua perangkat/jaringan? Apakah status provider/server normal? | Uji jalur lain, catat waktu/URL, hindari refresh massal, lalu eskalasi bila berulang. |
| Login gagal | Kredensial, status akun, role, URL, waktu perangkat, dan sesi browser. | Verifikasi akun melalui admin yang berwenang; reset hanya bila memang diperlukan. |
| UI tidak responsif | Browser, extension, cache, error console bila relevan, dan status aplikasi. | Uji private window/browser lain sebelum mengubah konfigurasi server. |
| PDF kosong / tidak lengkap | Parameter cetak, data sumber, pop-up/download, versi browser, dan resource server. | Preview satu rapor, dokumentasikan gejala, lalu telusuri sumber sebelum cetak massal. |
| Data berubah / hilang | Siapa yang mengubah, kapan, fitur impor/update, log/tiket, dan backup terakhir. | Hentikan perubahan lanjutan, simpan bukti, lalu tentukan recovery plan sebelum restore. |
Pembaruan aplikasi dan kebijakan harus dibedakan dari arsip artikel internal.
Artikel Hosch.id dapat membantu menjelaskan konteks, tetapi tidak boleh dianggap sebagai ketetapan otoritas, changelog resmi vendor, atau sumber regulator kecuali halaman tersebut benar-benar merujuk sumber resmi yang dapat diverifikasi.
Pisahkan knowledge hub dari SOP, hosting, security, dan governance.
Halaman sumber sebelumnya mengulang banyak SOP dan security control. V5 mengarahkan topik mendalam ke dokumen khusus agar setiap halaman memiliki fungsi yang jelas.
Rutinitas operator, akun, backup operasional, perubahan kritis, insiden, dan handover.
Resource, database, migration, backup/restore, availability, provider boundary, dan sizing.
Kontrol keamanan, incident response, akses, vendor dependency, dan batas assurance.
Response vs resolution, availability bila berlaku, exclusions, maintenance, dan remedies.
Pertanyaan teknis yang paling sering membutuhkan keputusan operator.
Apakah panduan ini merupakan dokumentasi resmi RDM/Kementerian Agama?
Apakah menu dan langkah di artikel lama pasti sama dengan versi RDM sekarang?
Apakah backup mingguan atau 2–3 hari sekali adalah jadwal wajib?
Apakah HTTPS berarti RDM sudah aman?
Kapan harus eskalasi ke support?
Tujuan akhir: operator tahu apa yang diperiksa, siapa yang berwenang, dan kapan harus berhenti mengubah sistem.
Panduan yang baik mengurangi trial-and-error. Ketika masalah menyentuh data produksi, database, restore, DNS, server, atau akses administratif, dokumentasikan kondisi dan gunakan prosedur perubahan yang terkontrol.
Masih ada masalah setelah checklist dasar?
Kirim gejala, waktu kejadian, URL, browser/perangkat, role akun, perubahan terakhir, dan screenshot pesan error. Jangan mengirim kata sandi atau kredensial sensitif.