Dari Role Generik Menuju Spesifik: Kisah Transformasi Akses Kampus Y

Kampus Y awalnya menerapkan struktur role yang sederhana: hanya ada dua role untuk seluruh sistem akademik—”Admin Pusat” dan “User Biasa.” Konsekuensinya, mahasiswa bisa akses data dosen lain. Dosen bisa lihat data keuangan pribadi kolega. Dalam 2 tahun, tidak ada insiden besar, tapi rasa tidak aman terus menghantui Rektor dan Wakil Rektor.

Ketika audit compliance pertama dilakukan, auditor bertanya: “Siapa yang authorized untuk edit kurikulum? Siapa yang boleh lihat data keuangan?” Kampus tidak punya jawaban yang jelas. Dokumentasi tidak ada. Semua tergantung “kepercayaan” dan “konvensi.”

Momentum perubahan datang ketika Rektor baru masuk. Beliau tegas: “Kita tidak bisa lanjut begini. Struktur role harus jelas, terukur, dan auditable.” Tim IT diminta audit seluruh implementasi akses, lalu redesign dari nol.

Fase 1: Identifikasi dan Mapping (Bulan 1-2)

Tim IT bersama Kabiro dan kepala biro lainnya melakukan audit menyeluruh. Pertanyaan yang diajukan sederhana tapi fundamental: “Apa tugas pokok Anda? Data apa yang Anda butuhkan untuk menjalankan tugas itu?”

Dari situ, muncul gambaran baru tentang flow data di kampus. Role-Based Access Control (RBAC) efektif membatasi hak akses sesuai peran pengguna, dengan pengguna yang terlibat diantaranya Pendaftar, Staf Administrasi, Staf, Penerjemah, dan Kepala Lembaga, sehingga keamanan data terjaga.

Hasilnya: 12 role utama diidentifikasi—Rektor, WR, Dekan, Kaprodi, Operator Akademik, Staf Keuangan, Dosen, Mahasiswa, Kabiro, Koordinator PMB, Admin Sistem, dan Auditor Internal.

Fase 2: Penetapan Permission (Bulan 3-4)

Untuk setiap role, tim IT membuat matrix: data entities × permission level (none, read, write, delete). Setiap peran membawa bundel izin yang memungkinkan tindakan spesifik pada sumber daya, dan administrator dapat dengan mudah mengubah akses pengguna dengan mengubah penugasan peran, bukan mengubah puluhan kontrol akses individual.

Proses ini melibatkan back-and-forth dengan stakeholder. Dekan ingin kaprodi bisa edit kurikulum tapi tidak lihat data keuangan. Kabiro ingin bisa audit akses tapi tidak bisa ubah permission sendiri (untuk check and balance). Setiap pertanyaan dipelajari, dan permission disesuaikan.

Fase 3: Testing dan Feedback (Bulan 5)

Sistem baru diuji dengan user pilot dari beberapa fakultas. Feedback nyata datang: “Saya tidak bisa akses data yang saya butuhkan.” “Ini terlalu banyak klik.” Tim IT adjust, implementasi iteratif.

Hasil fase testing jadi valuable: permission yang awalnya terlalu ketat dilonggarkan; workflow yang berbelit disederhanakan. Model tidak sempurna, tapi sudah jauh lebih baik.

Fase 4: Full Rollout dan Training (Bulan 6)

Sebelum go live, semua pengguna dilatih: “Inilah role Anda. Inilah yang bisa dan tidak bisa Anda lakukan. Jika Anda butuh akses lebih, ajukan ke kepala unit Anda.”

Transparansi adalah kunci. Pengguna perlu tahu MENGAPA mereka punya atau tidak punya akses tertentu. Jika diframing sebagai “pembatasan keamanan,” orang menerima. Jika diframing sebagai “kurangnya kepercayaan,” orang merasa tersinggung.

Hasil Pasca-Implementasi (6 Bulan Kemudian)

Audit compliance kedua berjalan mulus. Auditor bisa trace dengan jelas: siapa akses apa, kapan, untuk apa. Dokumentasi lengkap. Kampus lulus dengan catatan positif.

Di level operasional, dampaknya juga nyata. Mahasiswa tidak lagi bisa lihat nilai teman. Dosen tidak lagi takut data pribadi mereka terlihat. Tim IT bisa onboard pengguna baru dalam 1 hari (assign role saja), bukan 1 minggu. Culture change pun terasa: orang mulai menghargai akses sebagai privilege, bukan entitlement.

Fitur pengaturan role kerja yang robust, seperti di SEVIMA Platform, memungkinkan kampus melakukan perubahan permission tanpa code deployment. Ketika organisasi berubah, role bisa adjust dengan cepat. Transparansi tetap terjaga.

Diposting Oleh:

ilhamfe45465277