Yetki Karmaşasına Son: Depo, Üretim ve Finans Ekranları Nasıl Ayrılır?

Her istisna için yeni rol açıldığında rol sayısı çalışan sayısına yaklaşır ve model yönetilemez hale gelir; buna rol patlaması denir. Önlemek için roller görev tanımlarına göre az sayıda tutulur (departman başına iki-üç kademe), kişiye özel ihtiyaçlar yeni rolle değil süreli istisna yetkisiyle karşılanır ve matris periyodik gözden geçirmelerde sadeleştirilir. Elli kişilik bir şirkette 8-12 rol genellikle yeterlidir.

Yaygın pratik üç ayda bir hızlı kontrol, yılda bir kapsamlı denetimdir. Hızlı kontrolde ayrılan ve görev değiştiren personelin erişimleri ile hiç kullanılmayan hesaplar taranır; kapsamlı denetimde izin matrisi organizasyon şemasıyla karşılaştırılır. Terfi, departman değişikliği, toplu işten çıkış veya bir güvenlik olayı ayrıca gözden geçirme başlatmalıdır. Gözden geçirmenin kendisi de loglanırsa denetimlerde kanıt olarak kullanılır.

Aynı kişinin bir işlemi hem başlatıp hem onaylayabilmesi, suistimalin ve fark edilmeyen hatanın en kısa yoludur. Görev ayrılığı bunu engeller: ödemeyi hazırlayan ile onaylayan, satın alma talebini açan ile siparişi veren farklı yetkilerde tutulur. Yazılım tarafında tutar eşikli onay akışlarıyla uygulanır. Bağımsız denetimlerde ilk kontrol edilen maddelerdendir; küçük şirketlerde bile en azından finans işlemlerinde çift imza ilkesi önerilir.

Kullanıcıya birden fazla rol atanır; yetkiler birleşir ve kişi hem depo hem üretim ekranlarını görür, finans gibi atanmadığı alanlar kapalı kalır. Dikkat edilmesi gereken nokta görev ayrılığıdır: birleşen roller, aynı işlemi başlatma ve onaylama yetkisini tek kişide toplamamalıdır. İyi tasarlanmış sistemler böyle çakışmaları rol atama sırasında uyarı olarak gösterir.

Ekran bazlı erişimin altında işlem bazlı yetkiler tanımlanır: görüntüleme, ekleme, düzenleme, silme ve dışa aktarma ayrı ayrı verilir. Alan seviyesine inmek de mümkündür: satış ekranını gören bir kullanıcıdan maliyet sütunu gizlenebilir. İlke "ne kadar gerekiyorsa o kadar yetki"dir; ancak aşırı ince taneli kurgu bakım yükünü artırır. Alan bazlı gizlemeyi maliyet, kâr marjı ve kişisel veri gibi gerçekten hassas alanlara saklayın.

Kullanıcı hesabı pasifleştirilir; tüm oturumları düşer ve erişim anında kapanır. Kritik nokta zamanlamadır: çıkış işlemi İK sürecinin parçası olmalı, son iş gününde tamamlanmalıdır. Hesap silinmez, pasifleştirilir — geçmiş kayıtlarda "bu işlemi kim yaptı" sorusunun cevabı korunmalıdır. Ortak kullanılan paneller varsa parolalar da değiştirilir; en sağlıklısı ortak hesap hiç bulundurmamaktır.

Evet. Denetim izi her girişi, görüntülemeyi ve değişikliği kullanıcı, tarih ve eski-yeni değer bilgisiyle saklar. Stok eksiği, fiyat değişikliği veya silinen kayıt tartışması loglardan dakikalar içinde çözülür. Yetkisiz ekran deneme girişimleri de kayda geçer; tekrarlayan denemeler yöneticiye bildirim olarak iletilebilir. Log saklama süresini KVKK ve iç denetim politikanıza göre belirlemeniz gerekir.

Evet. Kullanıcı yalnızca kendi şubesinin verisini görecek şekilde kapsam kısıtı tanımlanır; merkez tüm şubeleri konsolide izler. Holding yapısında birden fazla şirket aynı sistemde ayrı veri alanlarıyla tutulur: her şirket kendi cari ve stok verisini görür, yönetim konsolide rapora erişir. Rol (ne yapabilir) ile kapsam (hangi veri üzerinde) ayrı tanımlandığında aynı rol tanımı tüm şubelerde yeniden kullanılabilir.

Evet. Belirli eşiği aşan iskonto, stok düzeltme, fire kaydı veya ödeme talimatı gibi işlemler üst yetkilinin onayına bağlanır; işlem onaylanana kadar askıda kalır. Onay akışı kademeli de kurulabilir: tutar büyüdükçe ikinci imza devreye girer. Onaylayan kişiye anlık bildirim gitmesi süreci hızlandırır; kritik aksiyon tek kişinin inisiyatifine bırakılmaz.

Kısmen. Hazır ERP ve ön muhasebe programlarının çoğu "yönetici/kullanıcı" gibi birkaç kalıp rol sunar; reçetenin kademeli açılması, tutar eşikli onay veya vardiya saati kısıtı gibi kurgular ya hiç yoktur ya da ek modül gerektirir. Departman yapınız standartsa hazır çözüm yeterli olabilir; ekran ayrımını organizasyon şemanıza birebir oturtmak istiyorsanız yetki katmanının özel geliştirilen yazılımda baştan tasarlanması gerekir.

Evet, doğrudan. KVKK kişisel veriye yalnızca görevi gereği ihtiyaç duyan kişilerin erişmesini bekler; ekran bazlı ayrım ve erişim logları bunu hem uygular hem belgeler. Olası bir denetimde "müşteri verisine kimler erişebiliyor" sorusu izin matrisiyle, "kim erişti" sorusu loglarla yanıtlanır. Üretim tesislerinde bu gereksinimleri siber güvenlik standartlarıyla birlikte ele almak gerekir; ayrıntıları endüstriyel yazılımlarda siber güvenlik ve KVKK rehberinde işledik.

Evet. Finans gibi hassas roller için SMS, e-posta veya doğrulayıcı uygulama tabanlı 2FA zorunlu tutulabilir; parola ele geçse bile yetkisiz giriş engellenir. Bunun üzerine kural bazlı bildirimler eklenir: mesai dışı giriş, yetkisiz ekran denemesi veya yüksek tutarlı işlem yöneticinin telefonuna anında düşer. Mobil tarafta bu uyarılar anlık bildirim (push notification) altyapısıyla iletilir; e-posta kutusunda kaybolmaz.

Çoğu durumda evet. Önce erişim analizi yapılır: kim bugün neyi görebiliyor, kimin gerçekten neye ihtiyacı var. Ardından yetki kontrolü hem arayüzde hem sunucu tarafında devreye alınır — yalnızca menüyü gizlemek güvenlik sağlamaz. Mevcut sistem dışarıya servis veriyorsa aynı kontrolün API katmanında da uygulanması gerekir; arayüzü kısıtlayıp uç noktaları açık bırakmak sık rastlanan bir eksiktir. Edge Bilişim bu tip sonradan eklemelerde yeni kural setini önce gölge modda çalıştırıyor: kurallar iki hafta boyunca kimseyi engellemeden yalnızca log üretiyor, "şu kural açılsaydı şu kullanıcı şu ekranda durdurulacaktı" listesi departmanlarla tek tek gözden geçiriliyor, itiraz kalmadığında kurallar zorlayıcı hale getiriliyor. Böylece geçiş günü kimse ekransız kalmıyor. Kapsam mevcut mimarinin düzenine göre değişir; bazen birkaç haftalık iştir, bazen kademeli (milestone) bir geçiş planı gerektirir.

Belirleyici kalemler: rol ve ekran sayısı, onay akışlarının derinliği, 2FA ve bildirim katmanları, şube/çok şirket kapsamı ve mevcut sisteme entegrasyon ihtiyacı. Yeni bir projede yetki katmanı ayrı bir kalem değil, toplam geliştirme bütçesinin makul bir parçasıdır; asıl farkı sonradan ekleme senaryosu yaratır — dağınık bir mimariye yetki katmanı eklemek, baştan tasarlamaktan belirgin biçimde pahalıdır. Kapsam netleşmeden verilen kesin rakam güvenilir değildir.

Günlük işler — yeni personele rol atama, ayrılanın hesabını kapatma, mevcut role ekran ekleme — yönetim panelinden teknik bilgi gerekmeden yapılır. Yeni rol tipi veya onay akışı gibi yapısal değişiklikler ise geliştirici desteği gerektirebilir; bu yüzden sözleşmede teslim sonrası destek koşullarını netleştirin. Edge Bilişim teslim paketine onaylanmış rol-ekran matrisinin son sürümünü ve yetki yönetimi ekranının kısa kullanım kaydını ekliyor; ayrıca sistemi devralacak kişiyle bir tur canlı prova yapıyoruz — yeni bir depo personelini kendisi tanımlıyor, ayrılan bir hesabı kendisi kapatıyor. Yetki yönetimini tek bir kişinin bilgisine bırakmamak, teslim sonrası en çok işe yarayan alışkanlıklardan biri. Teslim sonrası garanti süresinin neleri kapsadığı, yetki altyapısı gibi güvenlik açısından kritik bileşenlerde özellikle önemlidir.