Çok şubeli kurumlarda veri ayrımı neden bir arayüz meselesi değildir

Sorun nasıl ortaya çıkıyor

Tek şubeyle başlayan kurumlar büyüdüklerinde aynı soruyla karşılaşır: ikinci şubenin öğretmeni birinci şubenin öğrencisini görüyor mu? Görmemesi gerektiği açıktır — hem mahremiyet hem işleyiş açısından.

Buna verilen ilk cevap genellikle arayüz düzeyinde bir filtredir: öğrenci listesi ekranı, kullanıcının şubesine göre süzülür. Bu bir süre çalışır. Sonra yeni bir rapor ekranı eklenir, bir dışa aktarım özelliği yazılır, bir arama kutusu konur — ve bunlardan birinde filtre unutulur.

Sızıntı genellikle küçük ve fark edilmesi zor bir yerden olur: bir arama sonucunda başka şubenin öğrenci adının çıkması, bir raporda toplam sayının fazla görünmesi, bir bildirimin yanlış kullanıcıya gitmesi. Sorunun kaynağı ihmal değil, yöntemdir: her ekranda tek tek hatırlanması gereken bir kural, er ya da geç unutulur.

Filtre nerede olmalı?

Doğru yer, verinin okunduğu en alt katmandır. Sistem her sorguya, isteyen kullanıcının kurumunu kendiliğinden ekler. Geliştirici yeni bir ekran yazarken bunu düşünmek zorunda kalmaz; filtre zaten oradadır.

Bunun pratikteki sonucu şudur: bir şubenin kullanıcısı, kendi şubesine ait olmayan bir kaydın kimliğini doğrudan adres satırına yazsa bile sonuç alamaz — kayıt onun için "yok" hükmündedir. Arayüzde filtre uygulayan sistemlerde bu yöntem çoğu zaman çalışır ve en sık rastlanan sızıntı biçimidir.

Aynı yaklaşım yazma işlemleri için de geçerli olmalıdır: bir kullanıcı yeni kayıt oluşturduğunda kurum bilgisi kullanıcıdan değil, oturumdan alınır. Formdan gelen kurum bilgisine güvenen sistemlerde, form değiştirilerek başka kuruma kayıt yazılabilir.

Ortak içerik ihtiyacı

Katı bir ayrım tek başına yeterli değildir, çünkü çok şubeli kurumların ikinci bir ihtiyacı vardır: merkezin hazırladığı içeriğin tüm şubelerde kullanılabilmesi.

Bu, ayrımın ikinci bir boyutla kurulmasını gerektirir: içerik ya bir kuruma aittir ya da platform içeriğidir. Platform içeriği tüm şubelere açıktır; kurum içeriği yalnız sahibinde kalır.

Pratikte şöyle işler:

• Merkezin hazırladığı ortak soru havuzu ve deneme sınavları platform içeriğidir; her şube kullanabilir.
• Bir şube öğretmeninin kendi yazdığı sorular yalnız o şubede görünür.
• Merkez isterse bir şubenin ürettiği içeriği platform seviyesine taşıyabilir — böylece iyi içerik yukarı akar.
• Öğrenci verisi hiçbir koşulda platform seviyesine çıkmaz; her zaman kuruma bağlıdır.

Son madde en önemlisidir: içerik paylaşılabilir, kişisel veri paylaşılamaz. Bu ayrımı yapamayan sistemlerde ya herkes her şeyi görür ya da hiç kimse hiçbir şey paylaşamaz.

Merkezî raporlama ve mahremiyet dengesi

Merkez, tüm şubelerin performansını birlikte görmek ister; bu meşru bir ihtiyaçtır. Ama "tüm veriye erişim" ile "tüm veriyi raporlayabilme" aynı şey değildir.

Sağlıklı kurgu, merkezin toplu göstergeleri görmesi, kişisel ayrıntıya ise yalnız gerektiğinde ve izlenebilir biçimde inmesidir:

• Merkez seviyesinde: şube bazında sınav ortalamaları, katılım oranları, konu bazında başarı dağılımı, öğrenci sayısı ve tahsilat göstergeleri.
• Şube seviyesinde: kendi öğrencilerinin ad ve kayıt düzeyindeki ayrıntısı.
• Her seviyede: rehberlik görüşme kayıtları yalnız yetkili rollere açık.

Bu kurgu hem merkezin yönetim ihtiyacını karşılar hem şube çalışanının "merkez her şeyimi okuyor" hissini önler. İkincisi göz ardı edilirse sistemin kurum içinde benimsenmesi zorlaşır.

Kurum kimliği: görünürde ayrım

Veri ayrımının bir de görünen tarafı vardır. Öğrenci ve veli, kendi kurumunun adını ve logosunu görmek ister; "merkez sistemi" hissi kurum aidiyetini zayıflatır.

Bu yüzden her şube kendi adı, logosu ve iletişim bilgileriyle görünebilmelidir. Aynı yazılım, her şubenin öğrencisine o şubenin kurumu gibi görünür. Bu yalnız estetik bir tercih değil, velinin kime ait bir sistemde olduğunu anlaması açısından da gereklidir.

Aynı mantık bildirimler ve e-postalar için de geçerlidir: gönderen adı, öğrencinin bağlı olduğu şube olmalıdır.

Öğrenci limiti, kayıt ve şube değişikliği

Çok şubeli yapının yönetim tarafında üç pratik ihtiyaç vardır.

Birincisi kapasitedir: her şubenin kaç aktif öğrenci kaydedebileceği tanımlanabilmeli ve limit dolduğunda kayıt engellenmelidir. Bu hem lisans yönetimi hem planlama açısından gereklidir.

İkincisi kayıt akışıdır: yeni şube açıldığında kurulumun merkezden birkaç dakikada yapılabilmesi, her açılışta teknik destek gerektirmemesi gerekir.

Üçüncüsü öğrencinin şube değiştirmesidir — taşınma, program değişikliği. Bu durumda öğrencinin geçmiş sınav ve devamsızlık verisinin ne olacağı önceden kararlaştırılmalıdır. Verinin kaybolması kabul edilemez; olduğu gibi yeni şubeye açılması da mahremiyet açısından her zaman doğru değildir. Uygulanabilir çözüm, geçmişin özet düzeyde taşınması ve ayrıntının merkezde kalmasıdır.

Roller ve yetkiler: ikinci katman

Kurum ayrımı ilk katmandır; ikinci katman, aynı kurum içinde kimin neyi görebildiğidir. İkisi birbirini tamamlar — kurum ayrımı doğru kurulmuş bir sistemde bile, rol yetkileri gevşekse veri yanlış kişiye açılır.

Pratikte ayrılması gereken başlıca yetkiler:

• Öğretmen — yalnız kendi derslerine girdiği sınıfların öğrencilerini görür, başka şubenin değil, kendi şubesindeki diğer sınıfların da değil.
• Rehber öğretmen — kendi kurumundaki tüm öğrencilerin akademik ve katılım verisini görür; görüşme kayıtlarını yazar ve okur.
• Yönetici — kurum içi her şeyi görür; rehberlik kayıtlarına erişimi kurum politikasına göre belirlenir.
• Muhasebe — ödeme ve fatura verisini görür, sınav sonuçlarını görmez.
• Veli — yalnız kendi çocuğunun verisini görür.

Muhasebe rolü sık atlanır ve yönetici yetkisiyle çalıştırılır; oysa tahsilat takibi yapan bir kişinin öğrencilerin rehberlik notlarına erişmesi için hiçbir neden yoktur. Yetkiyi ihtiyaç kadar vermek, güvenlik açısından en ucuz önlemdir.

Yedekleme, kayıt izi ve veri sahipliği

Çok şubeli yapıda üç soru er geç sorulur ve cevabı önceden belli olmalıdır.

Birincisi: veriyi kim yedekliyor ve ne sıklıkla? Yedeğin varlığı kadar geri dönüş süresi de önemlidir — bir sorun hâlinde kaç saat içinde çalışır duruma gelinebileceği yazılı olmalıdır.

İkincisi: kim ne zaman ne yaptı? Öğrenci notunun değiştirilmesi, bir kaydın silinmesi veya bir kullanıcıya yetki verilmesi gibi işlemlerin kayıt izi tutulmalıdır. Bu, suçlu aramak için değil, anlaşmazlıkları veriyle kapatmak içindir.

Üçüncüsü: veri kime ait? Şube kurumdan ayrılırsa kendi öğrenci verisini alabilecek mi, hangi formatta? Bu sorunun cevabı sözleşmede olmalıdır; sonradan konuşulduğunda taraflar arasında ciddi bir gerilim kaynağıdır.

Özet: üç soruyla kontrol

Bir sistemin çok şubeli yapıya gerçekten uygun olup olmadığını üç soruyla anlarsınız:

• Bir şube kullanıcısı, başka şubenin kaydının kimliğini doğrudan girerse ne olur?
• Merkezin hazırladığı bir soru, iki şubede aynı anda kullanılabiliyor mu — kopyalanarak değil, tek kayıt olarak?
• Merkez rapor alırken kişisel ayrıntıya inmeden şube karşılaştırması yapabiliyor mu?

Üçüne de net cevap alabiliyorsanız, ayrım doğru katmanda kurulmuş demektir. Bu konunun karar aşamasındaki karşılığı için online sınav sistemine geçerken sorulacak 7 soru yazımıza da bakabilirsiniz.

Kurumunuzda bu süreçleri nasıl kurabileceğinizi konuşmak isterseniz bize yazın ya da +90 532 397 85 22 numarasından arayın.