Merancang Struktur Admin untuk Bimbel dengan Banyak Cabang dan Banyak Pemilik

Bimbel yang tumbuh dari satu cabang jadi beberapa cabang sering menghadapi situasi yang lebih rumit dari sekadar "tambah lokasi": kadang cabang baru dibuka dengan investor atau mitra bisnis berbeda, kepala cabang butuh akses penuh ke datanya sendiri tapi tidak seharusnya bisa mengubah data cabang lain, dan pemilik utama butuh gambaran menyeluruh tanpa harus login berkali-kali dengan akun berbeda. Kalau struktur akses ini tidak dirancang sejak awal, biasanya berakhir dengan solusi darurat yang berisiko: satu akun admin dipakai bersama banyak orang, atau semua orang diberi akses penuh karena lebih praktis daripada mengatur satu per satu.

Merancang struktur admin yang tepat bukan soal mencari sistem paling canggih, tapi soal memahami dengan jelas siapa yang perlu tahu apa, dan siapa yang perlu bisa mengubah apa.

Memetakan Peran Sebelum Memetakan Akses

Langkah pertama yang sering dilewati adalah memetakan peran secara eksplisit sebelum memikirkan detail teknis akses. Di institusi dengan banyak cabang dan banyak pemilik, peran yang umum biasanya mencakup: pemilik utama yang butuh visibilitas ke semua cabang, kepala cabang yang bertanggung jawab penuh atas satu cabang tapi tidak perlu — dan sebaiknya tidak bisa — mengubah data cabang lain, kepala akademik pusat yang mengelola bank soal dan standar mutu lintas cabang tapi bukan urusan operasional harian tiap cabang, dan guru yang hanya perlu akses ke kelas dan siswa yang diampu.

Peta peran ini biasanya lebih rumit dari yang dibayangkan di atas kertas, terutama kalau ada mitra bisnis yang menyertakan modal di cabang tertentu dan wajar ingin melihat laporan performa cabang itu tanpa perlu tahu detail cabang lain milik mitra berbeda.

Yang Sudah Bisa Dilakukan Sekarang

Lesan sudah punya fondasi untuk kebutuhan ini: setiap institusi bisa punya beberapa admin institusi, dan dashboard analytics bisa difilter per cabang, sehingga pemilik utama tetap bisa melihat gambaran menyeluruh sambil kepala cabang bekerja dengan data cabangnya masing-masing. Ada juga fitur custom role per institusi yang memungkinkan mendefinisikan peran di luar peran bawaan (admin institusi, guru, siswa) sesuai kebutuhan spesifik institusi.

Fondasi ini cukup untuk kebutuhan struktur admin dasar-menengah — memisahkan siapa yang bisa mengelola bank soal, siapa yang bisa melihat laporan keuangan/billing institusi, dan siapa yang hanya perlu akses operasional harian.

Yang Masih Perlu Diperlakukan dengan Hati-hati

Untuk institusi yang sangat besar dengan struktur kepemilikan kompleks — misalnya beberapa pemilik saham di cabang berbeda yang masing-masing hanya boleh melihat cabangnya sendiri secara sangat ketat, atau kebutuhan mengatur izin granular sampai level fitur tertentu per admin — antarmuka pengelolaan permission yang benar-benar rinci untuk skenario semacam ini masih dalam tahap pengembangan. Fondasinya (custom role) sudah ada sejak awal, tapi belum semua kombinasi scope akses yang sangat spesifik punya antarmuka pengaturan yang matang.

Kalau institusi Anda ada di titik ini, pendekatan paling realistis untuk saat ini adalah mengelompokkan cabang berdasarkan kepemilikan yang jelas terlebih dulu, lalu mengandalkan kombinasi role bawaan dan custom role yang sudah tersedia, sambil berkomunikasi langsung dengan tim Lesan soal kebutuhan spesifik yang belum terakomodasi antarmuka standarnya. Ini bukan celah yang perlu ditutupi — lebih baik institusi tahu batas ini di awal daripada menemukannya setelah terlanjur bergantung pada asumsi yang salah.

Prinsip Merancang Struktur yang Tahan Lama

Terlepas dari seberapa matang antarmuka sistemnya, ada prinsip yang tetap berlaku: beri akses seminim mungkin yang dibutuhkan untuk menjalankan peran, bukan akses semaksimal mungkin karena lebih praktis. Kepala cabang tidak perlu bisa mengubah bank soal pusat. Guru tidak perlu melihat data keuangan institusi. Setiap akses tambahan yang diberikan "untuk jaga-jaga" adalah potensi risiko — baik risiko kesalahan tidak sengaja (mengubah data yang seharusnya tidak disentuh) maupun risiko konflik kepentingan antar pemilik cabang yang berbeda.

Struktur admin yang baik juga perlu didokumentasikan, bukan hanya diatur di sistem. Institusi sebaiknya punya catatan internal — bukan hanya konfigurasi teknis — soal siapa punya wewenang apa dan kenapa, supaya saat terjadi pergantian orang di posisi kunci, wewenang itu bisa dipindahkan secara sadar, bukan sekadar diwariskan begitu saja lewat kredensial login yang dibagikan.

Merancang untuk Skala yang Akan Datang, Bukan Hanya Kondisi Sekarang

Institusi dengan dua cabang mungkin merasa struktur admin sederhana sudah cukup. Tapi kalau rencana ekspansi ke lima atau sepuluh cabang sudah ada di pikiran, ada baiknya struktur peran dirancang dengan asumsi skala itu sejak sekarang — supaya penambahan cabang baru berikutnya tinggal mengikuti pola yang sudah ada, bukan memicu perombakan struktur admin dari awal setiap kali institusi tumbuh.

Contoh Skenario Kepemilikan Campuran

Bayangkan sebuah institusi dengan tiga cabang: dua dimiliki penuh oleh pendiri, satu lagi dibuka bersama investor lokal yang menyertakan modal dan wajar ingin melihat laporan performa cabangnya sendiri secara berkala. Dengan beberapa admin institusi yang tersedia dan dashboard analytics yang bisa difilter per cabang, pendiri bisa memberi investor itu akses untuk melihat data cabang yang relevan dengannya, sementara admin utama tetap punya gambaran menyeluruh ke semua cabang.

Yang perlu disadari: skenario ini berjalan baik selama kebutuhan investor terbatas pada "melihat data cabangnya sendiri." Begitu kebutuhannya berkembang menjadi "investor ingin bisa mengubah pengaturan tertentu di cabangnya tanpa menyentuh cabang lain sama sekali, dengan kontrol yang sangat rinci per fitur," institusi perlu menyadari bahwa tingkat kerincian akses seperti itu ada di area yang masih dalam penyempurnaan — dan sebaiknya didiskusikan langsung dengan tim Lesan sebelum kepemilikan campuran itu terlanjur dijanjikan ke investor dengan ekspektasi yang belum tentu sepenuhnya terakomodasi antarmuka standar saat ini.