ERP'de yetkilendirme ve görevler ayrılığı: iç kontrol açığını kapatan erişim tasarımı

Bir muhasebe çalışanı hem yeni bir tedarikçi kartı açabiliyor hem de o tedarikçiye yapılacak ödemeyi onaylayabiliyorsa, sistemin kendisi hiçbir hata vermeden bir dolandırıcılığa zemin hazırlamış olur. Bu senaryo abartı değil; küçük ve orta ölçekli işletmelerde ERP yetkilendirmesi genelde "kim hangi ekranı görsün" sorusuyla sınırlı kurulur, "kim hangi işlemi tek başına tamamlayabilsin" sorusu ise arka planda kalır. Oysa ikinci soru, iç denetimin ve bağımsız denetçinin asıl baktığı yerdir.

ERP projelerinde yetkilendirme genelde kurulumun son haftasına sıkışan, "kimin hangi menüyü göreceği" düzeyinde ele alınan bir iş kalemi olarak kalır. Bu yazı, yetkilendirmeyi bir erişim listesi değil bir iç kontrol tasarımı olarak ele almanın çerçevesini veriyor: görevler ayrılığı ilkesi, rol bazlı erişim, onay eşikleri ve denetim izi.

Görevler ayrılığı ilkesi ve ERP'deki klasik çatışma noktaları

Görevler ayrılığı (segregation of duties), bir işlemin baştan sona tek bir kişinin elinde tamamlanmasını engelleyen iç kontrol ilkesidir. Amaç güvensizlik değil, hata ve suistimal riskini yapısal olarak azaltmaktır — bir kişi ne kadar güvenilir olursa olsun, tek başına hem kaydı açıp hem onaylayabildiği bir sistemde hata fark edilmeden ilerler.

ERP'de en sık görülen çatışma noktaları şunlardır:

• Satın alma ile ödeme onayı: Aynı kullanıcı hem satınalma siparişi açıp hem de o siparişe bağlı faturanın ödemesini onaylıyorsa, gerçekte var olmayan bir mal/hizmet için ödeme çıkması mümkün hale gelir.
• Tedarikçi/cari kartı açma ile ödeme onayı: Yeni tedarikçi kartı açabilen kişi aynı zamanda o tedarikçiye ödeme onaylayabiliyorsa, hayali bir tedarikçi üzerinden fon çekilmesi riski doğar.
• Stok girişi ile sayım onayı: Depoya giren malı sisteme kaydeden kişi aynı zamanda dönemsel sayım farkını da onaylıyorsa, fiziksel kayıp fark edilmeyebilir.
• Bordro hazırlama ile bordro onaylama: Bordroyu hazırlayan ile onaylayan aynı kişiyse, maaş/prim rakamındaki bir hata ya da kasıtlı değişiklik ikinci bir gözden geçirmeden geçer.
• Banka mutabakatı ile ödeme çıkışı: Banka hesabından ödeme çıkışını yapan kişi aynı zamanda banka mutabakatını da yapıyorsa, tutarsızlık kendi kendini denetleyen bir döngüye girer.

Bu beş nokta, bağımsız denetçilerin ERP incelemesinde ilk baktığı kalemlerdir; hiçbiri sektöre özel değildir, hemen her işletmede aynı şekilde ortaya çıkar.

Rol bazlı erişim (RBAC) nasıl tasarlanır

Rol bazlı erişim kontrolü (RBAC), yetkiyi kişiye değil role tanımlar: "Ahmet'e şu ekranları aç" yerine "Satınalma Uzmanı rolü şu işlemleri yapabilir" mantığıyla çalışır. Bu ayrım küçük görünse de sonucu büyüktür — personel değiştiğinde yeniden yetki tanımlamak yerine kişi role atanır, rol tanımı sabit kalır.

Tasarımda üç katman ayrı ayrı ele alınmalı:

1. Modül/ekran erişimi — kimin hangi modülü görebildiği (stok, finans, İK gibi).
2. İşlem yetkisi — modül içinde hangi işlemi yapabildiği (görüntüleme, oluşturma, düzenleme, silme, onaylama ayrı ayrı tanımlanmalı; "düzenleme yetkisi olan otomatik onaylayabilir de" varsayımı görevler ayrılığını baştan bozar).
3. Onay eşiği — belirli bir tutarın üzerindeki işlemin ikinci bir kişinin onayına düşmesi. Örneğin 50.000 TL altı satınalma tek onayla geçerken üzerindeki tutar ikinci bir yöneticinin onayına düşebilir; eşik seviyesi işletmenin nakit akışı ve risk iştahına göre belirlenir.

Çok seviyeli onay zinciri her işlemde gerekli değildir — küçük bir işletmede her satınalma için üç imza istemek operasyonu yavaşlatır ve pratikte kimse uymaz. Eşik ve seviye sayısı, işlemin riskiyle orantılı tutulmalı.

Sık görülen tasarım hataları

Yetkilendirme kurulumunda tekrar eden birkaç hata var:

"Süper kullanıcı" yaygınlığı. Kurulum sırasında danışmanların işini kolaylaştırmak için birçok kullanıcıya geniş yetki tanımlanır, canlıya geçtikten sonra bu yetkiler daraltılmaz. Bir yıl sonra bakıldığında muhasebe ekibinin yarısının hâlâ "yönetici" rolünde olduğu görülür.

Paylaşılan hesap kullanımı. Birden fazla kişinin aynı kullanıcı adı ve şifreyle sisteme girmesi, denetim izini anlamsız hale getirir — bir işlemi kimin yaptığı artık tespit edilemez.

İşten ayrılan personelin yetkisinin açık kalması. Bir çalışan işten ayrıldığında ERP hesabının o gün kapatılması gerekir; bu adım genelde İK sürecinden bağımsız yürütüldüğü için gecikir ya da unutulur.

Tek seviyeli onay. Tutar veya risk fark etmeksizin her işlemin tek onayla geçmesi, görevler ayrılığını fiilen ortadan kaldırır — sistem teknik olarak "onay" adımı gösterse de bu adım gerçek bir kontrol işlevi görmez.

Yetkilendirmenin bir kerelik proje işi sanılması. Roller kurulum sırasında tanımlanır, sonra yıllarca gözden geçirilmez. Oysa organizasyon değiştikçe (yeni departman, yeni sorumluluk dağılımı) rol tanımlarının da güncellenmesi gerekir.

Denetim izi: kim, ne zaman, hangi kaydı değiştirdi

Denetim izi (audit trail), sistemdeki her kritik değişikliğin kim tarafından, ne zaman ve hangi eski değerden hangi yeni değere yapıldığının kalıcı olarak kaydedilmesidir. Bu kayıt, hem bağımsız denetimde hem de bir uyuşmazlık durumunda geriye dönük tek güvenilir referanstır.

Denetim izinin kapsaması gereken asgari alanlar: fatura/fiş tutarı değişiklikleri, cari kart bilgisi (özellikle banka hesap numarası) değişiklikleri, kullanıcı yetki değişiklikleri, silinen kayıtlar ve fiyat/iskonto listesi değişiklikleri. Denetim izi kaydının kendisinin de değiştirilemez (sadece eklenebilir, üzerine yazılamaz) olması gerekir — aksi halde denetim izi güvenilirliğini kaybeder.

Değerlendirme sırasında sorulacak somut soru şu: bir cari kartın banka hesap numarası altı ay önce değiştirilmiş olsa, bunu kim, ne zaman değiştirdi diye bugün sorgulayabiliyor musunuz? Cevap "hayır" ya da "IT'ye sorup log dosyasını taratmamız lazım" ise, denetim izi fiilen kullanılabilir durumda değil demektir.

KVKK bağlantısı: erişim sınırlaması veri koruma yükümlülüğünün bir parçası

Yetkilendirme tasarımı yalnızca mali kontrol meselesi değil; KVKK'nın veri güvenliğine ilişkin yükümlülükleriyle de doğrudan kesişir. VERBİS ve KVKK uyum rehberimizde ele aldığımız gibi, veri sorumlusu işlediği kişisel veriye yalnızca gerekli personelin erişebilmesini sağlamakla yükümlüdür. ERP'de İK modülüne, müşteri/tedarikçi kişisel verilerine ya da sağlık verisi içeren kayıtlara erişimin rol bazlı sınırlandırılması, bu yükümlülüğün pratikteki karşılığıdır. Bir muhasebe uzmanının İK modülündeki bordro detaylarını, ya da satış temsilcisinin tüm müşteri tabanının kişisel iletişim bilgilerini görebilmesi, hem iç kontrol hem KVKK açısından aynı zayıflığın iki görünümüdür.

Ölçeğe göre karar çerçevesi

Bu tablo genel bir eğilimi gösterir; kesin yapı işletmenin risk iştahına ve sektörüne göre değişir. Denetim yükü doğası gereği yüksek olan finans sektörü, holding yapıları ve mali müşavirlik firmaları için yetkilendirme tasarımı, ERP seçiminde fiyat ya da modül zenginliğinden önce gelen bir kriterdir.

Karar öncesi kısa kontrol listesi

1. Satınalma açan kişi ile ödeme onaylayan kişi farklı mı?
2. Tedarikçi/cari kartı açabilen kişi, o karta ödeme onaylayabiliyor mu? (Onaylamamalı.)
3. Belirli bir tutarın üzerindeki işlemler ikinci bir onaya düşüyor mu, eşik tutar net tanımlı mı?
4. Denetim izi kaydı değiştirilemez mi, yoksa üzerine yazılabiliyor mu?
5. Paylaşılan kullanıcı hesabı var mı?
6. İşten ayrılan personelin yetkisi hangi sürede kapatılıyor?
7. Rol tanımları ne zaman gözden geçirildi — bir yılı geçti mi?
8. Kişisel veri içeren modüllere (İK, müşteri, sağlık) erişim rol bazlı mı sınırlı?

Yetkilendirme tasarımı, ERP kurulumunun görünmeyen ama en çok iş gören parçalarından biridir; iyi kurulduğunda kimse fark etmez, kötü kurulduğunda ise fark edildiğinde genelde iş işten geçmiş olur. Kendi organizasyon yapınıza uygun bir erişim ve onay tasarımını değerlendirmek için bir keşif görüşmesi talep edebilir, ölçeğinize uygun ürünleri kıyaslamak için uygun ERP bul aracını kullanabilirsiniz.