Panduan RDM • Dokumentasi Versi 3.1
RDM Versi 3.1: Membaca Dashboard, Menu Utama, Alur Kerja, dan Log Aktivitas
Dokumentasi praktis untuk memahami antarmuka Rapor Digital Madrasah (RDM) versi 3.1 pada Semester Ganjil 2025/2026, sekaligus membedakan informasi versi aplikasi, kebijakan kurikulum, dan praktik operasional yang masih relevan untuk operator serta guru.
Artikel ini mendokumentasikan antarmuka dan alur operasional RDM 3.1 yang digunakan pada konteks Semester Ganjil 2025/2026. Fokusnya bukan lagi menjelaskan “apa itu RDM” secara umum, melainkan membantu pembaca memahami hubungan antara dashboard, data master, kelas, rapor, akun, backup/restore, dan log aktivitas.
KMA Nomor 1503 Tahun 2025 merupakan perubahan atas KMA Nomor 450 Tahun 2024 tentang Pedoman Implementasi Kurikulum pada RA, MI, MTs, MA, dan MAK. Regulasi kurikulum dan versi aplikasi perlu dibedakan: sebuah versi RDM dapat menyesuaikan kebijakan tertentu, tetapi nomor versi aplikasi bukan pengganti regulasi atau panduan pembelajaran dan asesmen.
1. Posisi Artikel Ini dalam Panduan RDM
Hosch.id memiliki beberapa artikel RDM dengan tujuan berbeda. Agar tidak mengulang artikel pengenalan, halaman ini difokuskan sebagai dokumentasi antarmuka dan alur kerja RDM 3.1. Jika pembaca baru ingin memahami definisi, pengguna, fungsi, dan arsitektur RDM secara umum, gunakan artikel pengenalan utama. Jika membutuhkan langkah rinci untuk admin/operator atau guru, gunakan panduan per peran.
| Kebutuhan Pembaca | Panduan yang Tepat |
|---|---|
| Memahami RDM dari awal | Apa Itu RDM? Pengertian, fungsi, pengguna, dan cara kerja |
| Mengelola data dan konfigurasi | Panduan Admin/Operator RDM |
| Menginput nilai | Panduan Guru RDM: input nilai dan template Excel |
| Memahami antarmuka RDM 3.1 | Artikel yang sedang dibaca |
2. Konteks RDM 3.1 dan KMA 1503 Tahun 2025
Dokumentasi sumber artikel mencatat penggunaan RDM 3.1 pada Semester Ganjil
2025/2026, termasuk revisi aplikasi yang tercatat sebagai 20251218104054. Informasi
tersebut sebaiknya dibaca sebagai snapshot versi, bukan pernyataan bahwa revisi itu
masih merupakan build terbaru pada September 2026.
Pada sisi kebijakan, KMA Nomor 1503 Tahun 2025 mengubah KMA Nomor 450 Tahun 2024 tentang Pedoman Implementasi Kurikulum pada Raudhatul Athfal dan madrasah. Kebijakan ini mencakup konteks pembelajaran dan asesmen yang perlu diperhatikan madrasah. Dalam praktik akhir 2025, unit Kementerian Agama juga mendokumentasikan penggunaan RDM 3.1 dalam persiapan pengisian rapor dan penyesuaian terhadap kebijakan kurikulum tersebut.
- regulasi menetapkan kerangka kebijakan;
- panduan pembelajaran/asesmen menjelaskan implementasi pendidikan;
- RDM adalah perangkat aplikasi untuk mendukung proses pengelolaan dan pelaporan hasil belajar.
3. Cara Membaca Dashboard RDM
Dashboard berfungsi sebagai ringkasan kondisi data pada instalasi yang sedang digunakan. Dalam dokumentasi sumber, dashboard menampilkan informasi seperti peran pengguna, jumlah guru, siswa, kelas, dan ekstrakurikuler. Angka pada dashboard berguna sebagai indikator awal, tetapi tidak cukup untuk membuktikan bahwa seluruh data sudah benar.
| Ringkasan Dashboard | Pertanyaan Verifikasi |
|---|---|
| Jumlah guru | Apakah guru aktif sudah lengkap dan penugasannya benar? |
| Jumlah siswa | Apakah ada siswa ganda, siswa nonaktif, atau siswa yang belum masuk? |
| Jumlah kelas/rombel | Apakah pembagian siswa dan wali kelas sesuai kondisi semester? |
| Ekstrakurikuler | Apakah kegiatan yang digunakan pada periode tersebut sudah disiapkan dengan benar? |
Contoh lama pada dokumentasi menampilkan 2 guru, 20 siswa, 2 kelas, dan 5 ekstrakurikuler. Angka tersebut adalah contoh satu instalasi, bukan standar jumlah data RDM. Prinsip yang lebih berguna adalah mencocokkan angka ringkasan dengan sumber data madrasah.
4. Peta Menu dan Ketergantungan Data
Pada dokumentasi RDM 3.1, area kerja mencakup menu seperti Dashboard, Profil Madrasah, Pengaturan/Lembaga, Kelas, Data Guru, Siswa, Rapor, Administrasi, Backup/Restore, Akun, dan Logout. Nama atau pengelompokan menu dapat berubah pada versi lain.
Yang lebih penting daripada menghafal letak menu adalah memahami ketergantungan datanya. Rapor berada di bagian hilir. Jika data lembaga, guru, siswa, kelas, penugasan, atau komponen penilaian belum tepat, hasil pada tahap rapor dapat ikut bermasalah.
Profil/periode → data guru & siswa → kelas/rombel → penugasan & komponen → input nilai → verifikasi → finalisasi/cetak → backup.
Data master bukan satu-satunya sumber masalah
Versi artikel sebelumnya menyebut masalah rapor “paling sering” berasal dari data master atau mapping. Tanpa dataset insiden yang terukur, klaim frekuensi seperti itu terlalu kuat. Dalam praktik, gejala yang sama dapat berasal dari data master, penugasan, komponen penilaian, status periode, hak akses, konfigurasi aplikasi, atau masalah teknis lain. Karena itu, diagnosis sebaiknya dilakukan berurutan.
5. Alur Kerja Semester yang Lebih Terkendali
- Catat periode dan versi. Dokumentasikan semester, nomor versi/build, dan tanggal pengecekan.
- Verifikasi identitas lembaga. Periksa data yang akan digunakan pada keluaran rapor.
- Validasi guru dan siswa. Cocokkan identitas, status aktif, dan data yang relevan dengan sumber madrasah.
- Periksa kelas/rombel. Pastikan siswa, wali kelas, dan penugasan sesuai periode berjalan.
- Siapkan komponen penilaian. Ikuti kebijakan kurikulum dan konfigurasi yang berlaku pada instalasi.
- Lakukan input secara bertahap. Hindari menunggu seluruh pekerjaan sampai menjelang pembagian rapor.
- Verifikasi hasil. Bandingkan input dengan sumber nilai dan lakukan sampling keluaran.
- Koreksi pada sumber masalah. Jangan hanya mengubah hasil cetak bila akar masalah berada pada data/configuration.
- Finalisasi sesuai kewenangan. Pastikan pihak yang bertanggung jawab sudah melakukan pemeriksaan.
- Buat dan amankan backup. Simpan salinan yang dapat diidentifikasi sebelum perubahan penting dan setelah kondisi final sesuai SOP.
6. Memahami Log “Aktivitas”
Dokumentasi versi yang menjadi sumber artikel menunjukkan adanya area Aktivitas yang dapat digunakan untuk melihat jejak tertentu, termasuk informasi login/gagal login pada konteks yang didokumentasikan. Namun, keberadaan log tidak berarti aplikasi mencatat setiap tindakan pengguna secara lengkap.
| Temuan | Interpretasi yang Aman |
|---|---|
| Gagal login berulang | Periksa apakah terjadi salah password, akun bermasalah, atau pola akses yang perlu ditinjau. |
| IP yang tidak dikenali | Gunakan sebagai petunjuk investigasi, bukan bukti tunggal pelaku atau lokasi pengguna. |
| Perubahan data yang tidak diketahui | Periksa akun, log yang tersedia, waktu kejadian, dan konfirmasi kepada pengguna terkait. |
Alamat IP tidak selalu mengidentifikasi satu orang. NAT, jaringan bersama, VPN, perubahan IP dinamis, atau proxy dapat memengaruhi informasi yang terlihat. Karena itu, log harus diperlakukan sebagai salah satu sumber bukti teknis, bukan kesimpulan tunggal.
Kontrol akun yang lebih penting
- gunakan akun individual sesuai peran bila sistem mendukung;
- hindari membagikan kredensial admin melalui grup;
- gunakan password yang unik dan kuat;
- nonaktifkan atau ubah akses ketika petugas berganti;
- gunakan HTTPS jika RDM diakses melalui jaringan yang tidak sepenuhnya tepercaya;
- jangan mempublikasikan screenshot yang memperlihatkan password, token, data siswa, atau informasi sensitif.
7. Backup dan Restore: Jangan Dipahami sebagai Tombol “Undo”
Fitur backup/restore bernilai ketika prosedurnya jelas. Backup yang berhasil dibuat tetapi tidak dapat ditemukan, tidak memiliki identitas versi, atau tidak pernah diuji pemulihannya dapat memberikan rasa aman yang keliru.
- Buat backup pada titik risiko. Misalnya sebelum update, perubahan besar, perpindahan semester, atau proses lain yang berpotensi mengubah banyak data.
- Beri identitas. Catat tanggal, periode, versi aplikasi, dan kondisi data saat backup dibuat.
- Simpan salinan terpisah. Jangan mengandalkan satu file pada server/perangkat yang sama sebagai satu-satunya salinan.
- Periksa hasil. Pastikan file benar-benar terbentuk dan dapat diakses oleh petugas yang berwenang.
- Pahami prosedur restore. Restore dapat menimpa atau mengubah kondisi data; jangan menjalankannya hanya untuk “mencoba”.
Tidak ada satu jadwal seperti “mingguan” atau “harian” yang otomatis tepat untuk semua madrasah. Frekuensi backup sebaiknya mengikuti tingkat perubahan data, dampak kehilangan data, kapasitas penyimpanan, dan prosedur pemulihan yang tersedia.
8. Quality Control sebelum Finalisasi Rapor
| Tahap | Apa yang Diperiksa | Bukti Internal |
|---|---|---|
| Data master | Identitas lembaga, guru, siswa, kelas, dan status aktif. | Checklist/verifikasi dengan sumber data madrasah. |
| Penugasan | Guru, mata pelajaran, kelas, wali kelas, dan hak akses yang relevan. | Daftar penugasan semester. |
| Nilai | Kelengkapan dan kesesuaian input dengan sumber penilaian. | Sampling beberapa siswa/mapel. |
| Output | Identitas, nilai, catatan, halaman, dan elemen lain yang digunakan madrasah. | Pratinjau/cetak uji. |
| Backup | File terbentuk, diberi identitas, dan disimpan pada lokasi yang sesuai. | Catatan backup. |
Kementerian Agama pada akhir 2025 juga menekankan pentingnya kevalidan dan keamanan data dalam implementasi RDM. Prinsip tersebut lebih penting daripada sekadar mengejar status “semua kolom terisi”: data harus dapat dipertanggungjawabkan terhadap sumbernya.
9. Troubleshooting RDM Berbasis Gejala
| Gejala | Periksa Berurutan | Hindari Kesimpulan Instan |
|---|---|---|
| Nilai tidak muncul pada rapor | Nilai sumber → komponen → siswa/rombel → penugasan → status/finalisasi → versi/configuration. | Jangan langsung menghapus atau menginput ulang data massal. |
| Siswa berada di kelas yang salah | Identitas siswa → status → rombel → riwayat perpindahan/kenaikan → hasil keluaran. | Jangan menghapus siswa sebelum memahami efek terhadap riwayat data. |
| Pengguna tidak dapat login | Username → status akun → password → peran/hak akses → log yang tersedia → konektivitas. | Jangan menganggap setiap gagal login sebagai serangan. |
| RDM lambat | Jaringan → resource server → database → jumlah akses bersamaan → proses aplikasi → error log. | Jangan langsung menyalahkan jumlah pengguna atau hosting tanpa pengukuran. |
| Restore gagal | Kesesuaian backup → versi → prosedur restore → ruang penyimpanan → permission → log/error. | Jangan mencoba banyak file backup pada data produksi tanpa rencana pemulihan. |
| Output rapor berbeda dari harapan | Versi → konfigurasi → data → komponen → template/output → kebijakan yang digunakan. | Jangan mengubah banyak pengaturan sekaligus menjelang finalisasi. |
10. FAQ RDM 3.1 dan Alur Operasional
Apakah RDM 3.1 masih merupakan versi terbaru pada September 2026?
Artikel ini tidak menyatakan demikian. RDM 3.1 di sini adalah versi yang terdokumentasi pada Semester Ganjil 2025/2026. Untuk pekerjaan produksi, periksa informasi versi pada instalasi dan kanal/panduan teknis yang digunakan madrasah.
Apakah KMA 1503/2025 sama dengan panduan penggunaan RDM?
Tidak. KMA 1503/2025 merupakan regulasi tentang perubahan Pedoman Implementasi Kurikulum Madrasah. RDM adalah aplikasi operasional. Konfigurasi RDM perlu selaras dengan kebijakan yang berlaku, tetapi regulasi kurikulum bukan manual tombol/menu aplikasi.
Apakah angka pada dashboard berarti data sudah valid?
Tidak. Dashboard membantu melihat jumlah/ringkasan, sedangkan validitas tetap perlu diperiksa terhadap sumber data dan kondisi semester.
Apakah menu Aktivitas merupakan audit log lengkap?
Jangan mengasumsikannya tanpa memeriksa versi dan jenis event yang benar-benar dicatat. Dokumentasi sumber menunjukkan fungsi pemantauan aktivitas tertentu, tetapi cakupan log dapat berbeda menurut versi.
Seberapa sering RDM harus dibackup?
Gunakan pendekatan berbasis risiko. Semakin banyak perubahan data dan semakin besar dampak kehilangan data, semakin pendek interval backup yang masuk akal. Tambahkan backup sebelum perubahan besar dan pastikan prosedur restore dipahami.
Jika nilai tidak muncul, apakah pasti masalah data master?
Tidak. Data master adalah salah satu kemungkinan. Periksa juga komponen penilaian, penugasan, rombel, status proses, hak akses, konfigurasi, dan versi aplikasi sebelum mengambil tindakan.
11. Metodologi dan Batas Informasi
Artikel ini direvisi dari dokumentasi Hosch.id yang mencatat RDM 3.1 pada Semester Ganjil 2025/2026. Fakta tentang nomor versi/build, nama menu, contoh dashboard, dan keberadaan menu Aktivitas berasal dari materi sumber tersebut. Bagian checklist, quality control, strategi backup, keamanan akun, dan troubleshooting merupakan sintesis operasional Hosch.id untuk membantu pembaca menerapkan pemeriksaan secara sistematis.
Untuk konteks kebijakan, artikel mengacu pada KMA Nomor 1503 Tahun 2025 sebagai perubahan atas KMA Nomor 450 Tahun 2024. Karena antarmuka aplikasi dan petunjuk teknis dapat berubah, artikel ini tidak dimaksudkan sebagai pengganti dokumentasi teknis RDM yang berlaku pada instalasi pembaca.
Gunakan RDM sebagai Proses, Bukan Sekadar Tahap Cetak
Kualitas rapor bergantung pada kualitas data sumber, pembagian peran, pemeriksaan, dan kemampuan memulihkan data ketika terjadi masalah. Dokumentasikan versi yang digunakan, lakukan perubahan secara terukur, dan finalisasikan data setelah verifikasi.