Bir web yazılımında kullanıcı yetkileri, yalnızca kimin sisteme giriş yapabileceğini belirlemez. Hangi verinin görülebileceği, hangi işlemin yapılabileceği, kimlerin onay vereceği ve hatalı bir değişikliğin nasıl izleneceği de yetki planının parçasıdır.
Bu konu proje sonuna bırakıldığında yönetim paneli karmaşıklaşır, kullanıcılar ihtiyaç duymadıkları ekranlara erişir ve küçük bir görev değişikliği bile yazılım geliştirme talebine dönüşebilir. Sağlıklı yaklaşım, roller ve işlem sınırlarını daha tasarım aşamasında gerçek iş akışları üzerinden tanımlamaktır.
Rol ile yetki arasındaki fark nedir?
Rol, benzer sorumluluklara sahip kullanıcıları bir araya getiren tanımdır. Yetki ise belirli bir ekranı görme, kaydı ekleme, düzenleme, silme, onaylama veya dışa aktarma gibi tekil bir erişim hakkıdır.
Örneğin “Satış Temsilcisi” bir rol olabilir. Bu rol müşteri kayıtlarını görüntüleme, yeni teklif oluşturma ve kendisine ait teklifleri düzenleme yetkilerine sahip olabilir. “Satış Yöneticisi” ise bunlara ek olarak ekip kayıtlarını görme, indirim onaylama veya rapor alma yetkisi taşıyabilir.
Rolleri doğrudan departman adlarıyla sınırlamak her zaman yeterli değildir. Aynı departmandaki iki kişinin sorumlulukları farklı olabilir. Bu nedenle önce yapılacak işlemler belirlenmeli, ardından benzer yetki kümeleri rollere dönüştürülmelidir.
Yetki planlamasına nereden başlanmalı?
İlk adım, yazılımın yöneteceği süreçleri ve kullanıcı türlerini listelemektir. Sisteme kimler girecek, hangi işi yapacak, hangi veriye ihtiyaç duyacak ve hangi işlemler için başka bir kişinin onayı gerekecek soruları yanıtlanmalıdır.
Bu bilgiler proje kapsamıyla birlikte ele alınmalıdır. Kullanıcı rolleri belirsiz bırakılırsa ekran listesi ve iş akışları da eksik kalır. Bu nedenle rol ve yetki tablosu, web yazılımı ihtiyaç dokümanının temel parçalarından biri olarak hazırlanabilir.
Planlama toplantısında yalnızca yönetimin görüşünü almak yeterli olmayabilir. Günlük işlemleri yapan çalışanlar, gerçek görev dağılımını ve istisnaları daha iyi bilir. Departman sorumluları, operasyon kullanıcıları ve gerekirse dış kullanıcılar ayrı ayrı dinlenmelidir.
Yetki matrisi nasıl hazırlanır?
Yetki matrisi, rolleri ve işlemleri aynı tabloda karşılaştırmayı kolaylaştırır. Satırlarda ekranlar veya işlemler, sütunlarda roller yer alabilir. Her kesişimde görüntüleme, ekleme, düzenleme, silme, onaylama ve dışa aktarma gibi izinler işaretlenir.
Yalnızca ekran bazında “erişebilir” veya “erişemez” ayrımı yapmak çoğu projede yetersiz kalır. Kullanıcı bir müşteri sayfasını görebilir fakat iletişim bilgilerini değiştiremeyebilir. Siparişleri inceleyebilir fakat iptal işlemi yapamayabilir. Bu farklar matris içinde açıkça belirtilmelidir.
Tablo hazırlanırken her yetkinin iş gerekçesi de not edilebilir. Böylece ileride “Bu rol neden tüm müşterileri görebiliyor?” sorusu ortaya çıktığında kararın dayanağı bulunabilir. Gerekçesi olmayan geniş erişimler yeniden değerlendirilmelidir.
Veri kapsamı yetkisi neden önemlidir?
Bir ekranı görmek ile o ekrandaki bütün kayıtları görmek aynı şey değildir. Satış temsilcisi yalnızca kendi müşterilerini, bölge yöneticisi kendi bölgesindeki kayıtları, genel müdür ise tüm şirket verisini görebilir. Bu ayrım veri kapsamı yetkisiyle tanımlanır.
Kapsam seçenekleri iş modeline göre değişebilir: kullanıcının kendi kayıtları, bağlı olduğu ekip, şube, bölge, şirket veya tüm sistem gibi seviyeler kullanılabilir. Yapı oluşturulurken organizasyon değişiklikleri de düşünülmelidir. Bir çalışan başka şubeye geçtiğinde eski ve yeni kayıtlarla ilişkisi nasıl yönetilecek sorusu baştan yanıtlanmalıdır.
Müşteri portalı veya bayi ekranı gibi dış kullanıcı alanlarında kapsam daha da önemlidir. Her müşteri yalnızca kendi hesabını, her bayi yalnızca kendisine bağlı siparişleri görmelidir. Rol doğru olsa bile kayıt kapsamı yanlış kurulursa kullanıcı başkasına ait bilgiye ulaşabilir.
Görüntüleme, düzenleme ve silme ayrı ele alınmalı
Bir kullanıcının veriyi görmesi, değiştirebilmesi gerektiği anlamına gelmez. Özellikle finansal bilgiler, fiyatlar, ödeme durumları, kullanıcı hesapları ve sistem ayarları için görüntüleme ile düzenleme yetkileri ayrılmalıdır.
Silme işlemi ise çoğu zaman daha sıkı kontrol gerektirir. Bir kayıt gerçekten sistemden kaldırılacak mı, yoksa pasif duruma mı getirilecek? Yanlışlıkla silinen kayıt geri alınabilecek mi? Silme işlemini kim yaptı ve ne zaman yaptı bilgisi tutulacak mı? Bu sorular iş kuralı olarak tanımlanmalıdır.
Bazı durumlarda kullanıcının kaydı oluşturması fakat yayımlayamaması gerekebilir. İçerik hazırlayan kişi taslak oluştururken, yönetici yayına alma yetkisine sahip olabilir. Böyle bir ayrım, tek bir geniş “düzenleme” yetkisinden daha güvenli ve anlaşılırdır.
Onay akışları nasıl tasarlanmalı?
Her işlem için onay mekanizması kurmak işleri gereksiz yere yavaşlatabilir. Buna karşılık fiyat değişikliği, yüksek tutarlı indirim, ödeme iadesi veya önemli bir durum güncellemesi gibi işlemler ikinci bir kontrol gerektirebilir.
Onay gerektiren işlemler açıkça listelenmeli; talebi kimin oluşturduğu, kimin onaylayabileceği ve talep reddedildiğinde ne olacağı belirlenmelidir. Aynı kişinin hem talep oluşturan hem de onaylayan olması istenmiyorsa bu kural yazılım tarafından uygulanmalıdır.
Onaylayacak kişi izinli olduğunda veya görev değiştirdiğinde sürecin nasıl devam edeceği de düşünülmelidir. Vekâlet, alternatif onaylayıcı veya üst role aktarım gibi senaryolar proje sırasında kararlaştırılabilir.
Geçici ve istisnai yetkiler nasıl yönetilmeli?
Kullanıcılara zaman zaman geçici erişim gerekebilir. Bir çalışanın başka bir ekibe destek vermesi, yöneticinin izin döneminde vekâlet edilmesi veya dış uzmanın sınırlı süre sisteme girmesi buna örnektir.
Geçici yetkinin başlangıç ve bitiş tarihi olmalıdır. Süre dolduğunda erişimin otomatik kaldırılması, unutulmuş yetkilerin kalıcı hâle gelmesini önler. İstisnai erişimin kim tarafından verildiği ve hangi gerekçeyle tanımlandığı da kaydedilmelidir.
Her istisna için yeni bir kalıcı rol açmak yönetimi zorlaştırır. Bunun yerine temel roller korunabilir; gerçekten gerekli durumlarda süreli ve izlenebilir ek izinler tanımlanabilir.
Yönetim panelinde yetkiler nasıl görünmeli?
Yetki sistemi yalnızca teknik altyapıda bulunmamalı, yetkili yöneticilerin anlayabileceği biçimde yönetilebilmelidir. Rol adları, açıklamaları ve hangi izinleri içerdiği açıkça görülmelidir.
Yüzlerce teknik izin tek bir uzun listede gösterilirse yanlış seçim yapılabilir. İzinler müşteri yönetimi, siparişler, raporlar, içerikler ve sistem ayarları gibi iş alanlarına göre gruplanabilir. Kritik izinler ayrıca işaretlenebilir.
Kullanıcı yönetimi, genel panel planıyla birlikte tasarlanmalıdır. Menü yapısı, arama, filtreleme, kullanıcı durumu ve rol atama ekranları için yönetim paneli planlama adımları dikkate alınabilir.
Bir kullanıcıya birden fazla rol verilmeli mi?
Birden fazla rol desteği esneklik sağlar; ancak çakışan yetkilerin nasıl çözüleceği belirlenmelidir. Bir rol işlemi izinli, diğeri yasak olarak tanımlıyorsa hangi kural geçerli olacaktır? Sistem bu konuda tutarlı davranmalıdır.
Küçük projelerde her kullanıcı için tek ana rol ve sınırlı ek izinler daha kolay yönetilebilir. Büyük yapılarda birden fazla rol gerekli olabilir. Karar verirken kullanıcı sayısı, görev çeşitliliği ve yönetim ekibinin teknik yetkinliği değerlendirilmelidir.
Kullanıcıya doğrudan çok sayıda tekil izin vermek kısa vadede pratik görünebilir. Fakat zamanla kimin neden farklı erişime sahip olduğunu anlamak zorlaşır. Mümkün olduğunda yetkiler roller üzerinden yönetilmeli, kişiye özel izinler istisna olarak tutulmalıdır.
İşlem kayıtları hangi soruları yanıtlamalı?
Yetkili bir kullanıcının yaptığı önemli değişikliklerin izlenebilmesi işletme açısından değerlidir. İşlem kayıtları; kimin, ne zaman, hangi kaydı, hangi işlemle değiştirdiğini gösterebilir.
Her küçük ekran hareketini kaydetmek yerine iş açısından önemli işlemler belirlenmelidir. Kullanıcı rolü değişikliği, fiyat güncellemesi, ödeme durumu, kayıt silme, dışa aktarma ve onay kararı gibi olaylar öncelikli olabilir.
Kayıtların kimler tarafından görüntülenebileceği de ayrı bir yetkidir. İşlem geçmişi hassas bilgiler içerebilir. Ayrıca saklama süresi, arama alanları ve dışa aktarma ihtiyacı projenin kapsamına göre tanımlanmalıdır.
Yetki sistemi nasıl test edilmeli?
Test yalnızca yönetici hesabıyla yapılmamalıdır. Her rol için örnek kullanıcı oluşturulmalı ve gerçek görev senaryoları denenmelidir. Kullanıcı erişmesi gereken ekrana ulaşabiliyor mu, yapmaması gereken işlemi gerçekleştirebiliyor mu ve doğru kayıt kapsamını görüyor mu kontrol edilmelidir.
Sadece izin verilen işlemleri değil, engellenmesi gereken durumları da test etmek gerekir. Kullanıcının adres çubuğuna farklı bir sayfa yazarak, başka kaydın numarasını değiştirerek veya doğrudan işlem bağlantısına giderek yetkiyi aşamaması gerekir.
Rol değişikliği, kullanıcı pasife alma, geçici yetki süresinin dolması ve onaylayıcının bulunmadığı durumlar da test senaryolarına eklenmelidir. Kabul testinde işletmenin gerçek kullanıcılarından geri bildirim alınması, kağıt üzerindeki rol tanımlarının pratikte çalışıp çalışmadığını gösterir.
Sık yapılan planlama hataları
- Tüm çalışanlara yönetici yetkisi vermek,
- Rol ile veri kapsamını aynı şey olarak düşünmek,
- Görüntüleme, düzenleme, silme ve onaylama izinlerini ayırmamak,
- Geçici görevler için kalıcı ve geniş erişim tanımlamak,
- Kişiye özel izinleri çoğaltarak rol yapısını işlevsiz bırakmak,
- Departman değişikliği ve işten ayrılma senaryolarını planlamamak,
- Yetki değişikliklerini kayıt altına almamak,
- Testleri yalnızca tam yetkili hesapla yapmak.
Yayımlamadan önce kontrol listesi
- Tüm kullanıcı türleri ve gerçek görevleri listelendi mi?
- Rollerin içerdiği işlem yetkileri açıkça tanımlandı mı?
- Kendi kaydı, ekip, şube ve tüm şirket gibi veri kapsamları ayrıldı mı?
- Kritik işlemler için onay gereksinimi belirlendi mi?
- Silme ve pasife alma kuralları net mi?
- Geçici erişimler için süre ve onay kaydı bulunuyor mu?
- Yetki değişiklikleri ve önemli işlemler izlenebiliyor mu?
- Her rol olumlu ve olumsuz senaryolarla test edildi mi?
- Yetki yönetimini yapacak sorumlu kişiler belirlendi mi?
Sonuç
Kullanıcı yetkileri, web yazılımının sonradan eklenen teknik bir ayarı değil, iş süreçlerinin dijital karşılığıdır. Doğru planlama; kullanıcıların görevlerini gereksiz engeller olmadan yapmasını, hassas işlemlerin ise yalnızca yetkili kişilerce yürütülmesini sağlar.
Roller, işlem izinleri, veri kapsamı, onay akışları ve kayıt tutma birlikte ele alınmalıdır. Gerçek kullanıcılarla test edilen ve görev değişikliklerine uyum sağlayan bir yetki yapısı, yazılımın uzun vadede daha anlaşılır ve yönetilebilir kalmasına yardımcı olur.