İş Yazılımında Rol ve Yetki Tasarımı: 7 Karar

Bir mobilya üreticisi düşünün. Satış ekibi teklif hazırlıyor, depo sevkiyatı çıkarıyor, muhasebe tahsilatı izliyor, bayiler kendi siparişlerini giriyor. Hepsi aynı web uygulamasını kullanıyor. Proje boyunca ekranlar, raporlar ve entegrasyonlar konuşuldu; "kim neyi görecek" sorusu ise teslimden bir hafta önce, bir satış temsilcisinin ürün maliyetlerini ve diğer temsilcilerin müşteri listesini görebildiği fark edilince gündeme geldi.

O noktada yapılan iş genellikle aynıdır: bazı menüler gizlenir, bazı butonlar kaldırılır, birkaç kullanıcıya "yönetici" denir. Sistem çalışır görünür. Birkaç ay sonra işten ayrılan bir çalışanın hesabının hâlâ açık olduğu, bir indirimin kim tarafından onaylandığının bilinmediği ya da gizlenen bir ekranın adres çubuğuna yazılınca açıldığı ortaya çıkar.

Yeni bir ürünün ilk sürümünde rol sayısını az tutmak çoğu zaman doğru karardır. Burada konu başka: birden fazla departmanın her gün kullandığı bir iş yazılımı. Böyle bir sistemde yetki, ekranların üstüne sonradan giydirilen bir katman değil, veri modelinin bir parçasıdır. Aşağıdaki yedi karar, ekran tasarımı başlamadan konuşulduğunda birkaç toplantı sürer; canlı sistemde sonradan eklendiğinde ise neredeyse her ekrana dokunmak gerekir.

1. Rolleri unvanlardan değil, yapılan işlerden çıkarın

"Satış müdürü", "bölge sorumlusu", "uzman" gibi unvanlar şirketten şirkete, hatta yıldan yıla değişir. Yazılımdaki rolleri bunlara göre kurarsanız, her organizasyon değişikliğinde yetki yapısını yeniden tartışırsınız.

Bunun yerine önce işleri listeleyin: teklif hazırlar, iskonto verir, iskontoyu onaylar, sevkiyat çıkarır, iade kabul eder, fiyat listesini değiştirir. Sonra her rolün bu işlerden hangilerini yapacağını bir tabloda işaretleyin. Unvan değiştiğinde tablo aynı kalır; yalnızca kişinin rolü değişir.

Bu tablo, yazılım ekibiyle iş tarafının aynı dili konuşmasını da sağlar. "Bölge sorumlusu bunu yapabilsin mi?" sorusu soyut kalır; "iskonto onaylayabilsin mi?" sorusuna herkes cevap verebilir.

2. Görmek, değiştirmek ve onaylamak ayrı yetkilerdir

Çoğu sistemde yetki tek bir soruya indirgenir: bu kişi bu ekrana girebilir mi? Oysa aynı kayıt üzerinde farklı kişiler farklı şeyler yapar. Muhasebe bir siparişi görmeli ama değiştirmemelidir. Satış temsilcisi teklifi değiştirebilmeli ama belli bir iskonto oranının üstünü kendisi onaylamamalıdır.

Her önemli kayıt türü için en az dört soruyu ayrı ayrı cevaplayın: kim görebilir, kim oluşturabilir, kim değiştirebilir, kim onaylar ya da siler. Onay gereken işlerde bir eşik belirleyin (ör. belli bir tutarın ya da oranın üstü) ve eşiğin kendisini de kimin değiştirebileceğini yazın.

3. Hangi kayıtları göreceğini de belirleyin

"Müşteriler ekranını görebilir" demek yetmez; hangi müşterileri? Bir satış temsilcisi yalnızca kendi müşterilerini, bölge sorumlusu kendi bölgesini, genel müdür hepsini görür. Bayi yalnızca kendi siparişlerini ve kendine tanımlı fiyatları görmelidir.

Bu kayıt düzeyindeki ayrım, veri modelinde her kaydın kime ya da hangi bölgeye ait olduğunu tutmayı gerektirir. Baştan planlanırsa her sorguya bir filtre eklemekten ibarettir. Sonradan eklenirse önce mevcut binlerce kaydın kime ait olduğu bulunmalı, sonra her rapor ve dışa aktarma tek tek elden geçirilmelidir. Raporları unutmayın: ekranda gizlenen veri, Excel'e aktarılan raporda görünüyorsa gizlenmemiş demektir.

4. Kontrolü ekranda değil, sunucuda yapın

Bir menüyü ya da butonu gizlemek kullanıcı deneyimi için iyidir, ama güvenlik değildir. Uygulama arka planda bir sunucuya istek gönderiyorsa, o isteği doğrudan gönderebilen biri gizli butona ihtiyaç duymaz. Adres çubuğuna bir kayıt numarası yazmak ya da tarayıcının geliştirici araçlarını açmak yeterli olabilir.

Bu yüzden her istekte sunucu iki şeyi kontrol etmelidir: bu kişinin bu işi yapma yetkisi var mı ve bu kayıt onun görebileceği kayıtlardan biri mi? Mobil uygulama ve bayi portalı gibi farklı arayüzler aynı sunucuyu kullanıyorsa, kural tek yerde durur ve her arayüz için ayrıca yazılmaz.

Teslim alırken basit bir deneme yapın: düşük yetkili bir kullanıcıyla girip, yetkili bir kullanıcının açtığı bir kaydın adresini yapıştırın. Kayıt açılmamalıdır.

5. Bazı alanlar, ekranın geri kalanından daha hassastır

Aynı ürün kartında ürün adı herkese açık olabilirken maliyet ve kâr marjı yalnızca birkaç kişiye açık olmalıdır. Aynı personel kaydında ad ve dahili telefon herkesi ilgilendirirken kimlik numarası, maaş ve sağlık bilgisi yalnızca ilgili birimi ilgilendirir.

Bu alanları baştan işaretleyin ve onları ayrı bir yetkiye bağlayın. Kişisel veriler söz konusu olduğunda bu yalnızca iyi bir uygulama değil, KVKK'nın da beklediği bir şeydir: kişisel veriye yalnızca işi gereği ihtiyacı olanlar erişmelidir. Hassas alanların dışa aktarmalarda ve bildirim e-postalarında da görünmediğini kontrol edin.

6. Kimin neyi, ne zaman değiştirdiğini kaydedin

Bir fiyat yanlış girildiğinde ya da bir sipariş iptal edildiğinde ilk soru "kim yaptı?" olur. Sistem bunu bilmiyorsa cevap tahmine ve karşılıklı suçlamaya kalır.

Önemli kayıtlarda değişiklik geçmişi tutun: kim, ne zaman, hangi alanı, neyden neye değiştirdi. Onaylarda kimin onayladığını ve hangi eşiğe göre onaylandığını saklayın. Bu kaydın kendisi de değiştirilemez olmalıdır; yöneticinin bile silemediği bir geçmiş, tartışmaları birkaç dakikada bitirir.

Hepsini kaydetmek gerekmez. Fiyat, iskonto, cari bilgisi, ödeme, stok düzeltmesi ve yetki değişiklikleri genellikle yeterli bir başlangıçtır.

7. İşe giriş, işten çıkış ve izin dönemlerini planlayın

Yetki yapısının en çok bozulduğu anlar sistemin değil, insanların değiştiği anlardır. Yeni gelen bir çalışana "şimdilik" yönetici yetkisi verilir ve geri alınmaz. İşten ayrılan birinin hesabı açık kalır. İzne çıkan müdürün onayları birikir ya da şifresi bir başkasına verilir.

Bunlar için baştan üç şey belirleyin. Hesap açma ve kapatma kimin işidir ve insan kaynakları sürecine nasıl bağlanır? İzin dönemlerinde onay yetkisi şifre paylaşılmadan, süreli olarak bir başkasına nasıl devredilir? Ve yılda bir ya da iki kez, her rolde kimlerin olduğunu kim gözden geçirir? Bu gözden geçirme çoğu zaman yarım saat sürer ve unutulmuş birkaç hesabı ortaya çıkarır.

Kısaca

• Rolleri unvanlardan değil, yapılan işlerden çıkarın ve bir tabloda gösterin.
• Görmek, oluşturmak, değiştirmek ve onaylamak için ayrı karar verin; onaylara eşik koyun.
• Kimin hangi kayıtları göreceğini belirleyin; raporları ve dışa aktarmaları da dahil edin.
• Yetkiyi her istekte sunucuda kontrol edin; buton gizlemek yetmez.
• Maliyet, marj ve kişisel veri gibi hassas alanları ayrı bir yetkiye bağlayın.
• Önemli değişikliklerin silinemeyen bir geçmişini tutun.
• Hesap açma, kapatma, vekâlet ve dönemsel gözden geçirmeyi baştan planlayın.

Özel yazılım ve iç araç projelerinde rol ve yetki yapısını ekran tasarımından önce, iş tarafıyla birlikte bir tablo olarak çıkarıyor ve kontrolleri sunucu tarafında kuruyoruz.