Bir muhasebe departmanında aynı kişi hem tedarikçi kartı açabiliyor hem fatura giriyor hem de ödeme onaylıyorsa, sistem teknik olarak çalışır, ama iç kontrol tarafında büyük bir açık vardır. Bu açığın adı görev ayrılığıdır (segregation of duties) ve ERP projelerinde genellikle modül seçimi, entegrasyon, veri taşıma gibi başlıkların gölgesinde kalır. Oysa yetki tasarımı yanlış kurulmuşsa, en gelişmiş ERP bile hatayı veya kötüye kullanımı yakalamakta gecikir.
Görev Ayrılığı İlkesi Nedir
İlke basit: bir işlemin başlatılması, onaylanması, kaydedilmesi ve fiziksel varlığın kontrolü mümkün olduğunca farklı kişilerin elinde olmalı. Tek kişi bu adımların birden fazlasını üstlenirse, hatayı düzeltecek ikinci bir göz kalmaz. Kasıt olmasa bile yanlış tutar girme, mükerrer kayıt, unutulan iptal gibi hatalar fark edilmeden ilerler.
Kurumlar büyüdükçe bu ayrım kendiliğinden oluşmaz; tam tersine, ekip küçükken “herkes her işi yapar” alışkanlığı ERP’ye taşınır ve orada donar. Sistem üzerinden herkese geniş yetki tanımlamak, kurulumu hızlandırır ama sonradan geri almak zorlaşır; kimse “artık bu yetkiye ihtiyacın yok” demek istemez.
En Sık Görülen Çakışan Yetki Kombinasyonları
İç denetim literatüründe ve ERP uygulamalarında tekrar eden çakışma örnekleri şunlardır:
| Süreç | Çakışan yetki çifti | Risk |
|---|---|---|
| Satın alma | Tedarikçi kartı açma + fatura onaylama | Hayali tedarikçiye ödeme |
| Satış | Cari kart açma + tahsilat kaydı girme | Tahsilatın örtülü kalması |
| Stok | Depo girişi yapma + sayım farkı onaylama | Fiili eksiğin kapatılması |
| Finans | Banka kaydı girme + banka mutabakatı yapma | Hatalı kaydın fark edilmemesi |
| İK | Bordro parametresi değiştirme + bordro onaylama | Yetkisiz ücret değişikliği |
Tablodaki her satır aslında aynı soruyu soruyor: bu işlemi biri başlatıyorsa, bir başkası mı kontrol ediyor? Cevap “hayır” ise, sorun ERP’nin yeteneğinde değil, yetki kurgusundadır.
Tek Kişide Toplanan Yetkinin Somut Sonucu
Küçük ve orta ölçekli işletmelerde bu riskler genelde kötü niyetten değil, ekip darlığından doğar. Muhasebeci hem fatura kesiyor hem tahsilat giriyorsa, ay sonunda cari hesap mutabakatını da kendisi yapıyor demektir; kendi işini kendisi denetlemiş olur. Depo sorumlusu hem mal kabul ediyor hem sayım farkını kapatıyorsa, fiili kayıp sistem üzerinde hiç görünmez.
Bu durumun pratik karşılığı şudur: yıl sonu denetiminde ya da bağımsız denetçi taramasında “bu işlemi kim onayladı” sorusuna net cevap verilemez. Kredi başvurusunda banka, yatırımcı görüşmesinde durum tespiti (due diligence) ekibi, ya da vergi incelemesinde müfettiş aynı soruyu sorar. Cevap “herkes her şeyi yapabiliyordu” olursa, güven kaybı ERP’nin kendisinden değil, kurumun süreç olgunluğundan kaynaklanır.
Rol Matrisiyle Çakışmaları Tespit Etmek
Pratikte işe yarayan yöntem, kişi bazlı değil rol bazlı ilerlemektir. Önce kurumdaki tüm kritik işlemler (fatura kesme, ödeme onaylama, stok düzeltme, bordro değiştirme, cari kart açma…) bir listeye çıkarılır. Sonra hangi rolün hangi işlemi yapabileceği bir matrise işlenir. Matris tamamlandığında, aynı satırda “başlatma” ve “onaylama” sütunlarının aynı role düştüğü yerler işaretlenir; çakışma tam olarak orada görünür.
Bu matris bir kere kurulduktan sonra statik kalmaz. Yeni bir eleman işe başladığında ya da biri departman değiştirdiğinde, matrise bakarak “bu role hangi yetkiler geliyor” sorusu saniyeler içinde cevaplanır; kimseye özel yetki tanımlamaya gerek kalmaz.
Onay Limitleri ve Çok Kademeli Onay Zinciri
Görev ayrılığının ikinci ayağı tutar bazlı onay zinciridir. Belirli bir tutarın üzerindeki her ödeme veya sipariş, tek onaydan değil zincirden geçmeli. Örneğin saha ekibi harcamayı talep eder, departman yöneticisi ilk onayı verir, belirli bir eşiğin üzerinde finans ekibi ikinci onayı ekler. Zincirin her halkası ayrı bir kişi olduğu sürece, tek bir onayla büyük tutarlı bir işlemin geçmesi mümkün olmaz.
Limitlerin statik değil, kurumun büyüklüğüne göre ayarlanabilir olması önemlidir. On kişilik bir işletmede iki kademeli onay yeterli olabilirken, yüz kişiyi geçen bir organizasyonda üçüncü bir kademe (örneğin genel müdür onayı) büyük tutarlı işlemler için eklenir.
Erişim Kaydı ve Denetim İzi
Görev ayrılığı kurgusu ne kadar iyi tasarlanırsa tasarlansın, kim neyi ne zaman değiştirdiğinin kaydı tutulmuyorsa denetlenebilirlik eksik kalır. Kişisel Verileri Koruma Kurumu’nun veri güvenliği rehberi de erişim kontrolünü ve erişim kayıtlarının düzenli denetimini temel teknik tedbirler arasında sayar. Bu ilke kişisel verinin yanında finansal ve operasyonel kayıtlar için de geçerlidir. Her kayıt değişikliğinin kim tarafından, ne zaman yapıldığının iz bırakması, hem iç denetimde hem dış denetimde ilk sorulan sorunun cevabını hazır tutar.
Log kaydı olmadan kurulan bir yetki matrisi, kağıt üzerinde iyi görünür ama bir anlaşmazlık çıktığında ispat gücü taşımaz. İkisi birlikte çalıştığında (kim yapabilir, kim yaptı) iç kontrol tamamlanmış olur.
Excel ve Paylaşılan Hesabın Sınırı
Küçük ekiplerde yetki yönetimi genelde “herkes aynı şifreyle giriyor” ya da “Excel’de kim ne yapabilir listesi var” şeklinde ilerler. İkisi de kayıt bırakmaz. Paylaşılan hesapla girilen bir işlemde hangi kişinin yaptığı sistem üzerinden asla ayrıştırılamaz; Excel listesi ise güncellenmediği anda fiili durumla uyumunu kaybeder. Yetki kurgusunun ERP içinde, kullanıcı bazlı ve rol bazlı olarak tutulması, bu iki yöntemin bırakmadığı izi otomatik olarak üretir.
Qera’da Görev Ayrılığını Kurmak
Qera ERP, satın alma, satış, stok, finans ve İK süreçlerini tek platformda çalıştırdığı için yetki tanımı da modüller arasında dağınık kalmaz; tek bir rol yapısı üzerinden yönetilir. Tutar bazlı çok kademeli onay zincirleri kurulabilir, her kritik işlem kullanıcı ve zaman damgasıyla kayıt altına alınır, roller departman ve pozisyon bazında şablonlanabilir. Altyapı Microsoft Azure üzerinde çalıştığı için erişim güvenliği platform seviyesinde de desteklenir.
Kurulum anahtar teslim ilerler; yetki matrisi kurumun mevcut organizasyon yapısına göre proje ekibiyle birlikte tasarlanır, sonradan ek maliyet çıkmaz. 100 kullanıcıya kadar ek kullanıcı maliyeti olmaması, büyüyen ekiplerde rol bazlı yetkilendirmeyi genişletmeyi de maliyet kaygısından bağımsız hale getirir.
Kurumsal Değerlendirme İçin Kontrol Listesi
- Kritik işlemler (fatura, ödeme, stok düzeltme, bordro, cari açma) listelendi mi?
- Her işlem için “başlatan” ve “onaylayan” farklı roller mi?
- Tutar bazlı onay eşikleri tanımlı mı, kaç kademeli?
- Her kayıt değişikliği kullanıcı ve zaman damgasıyla loglanıyor mu?
- Paylaşılan hesap veya ortak şifreyle işlem yapan kullanıcı var mı?
- Rol matrisi son personel değişikliğinden sonra güncellendi mi?
Sıkça Sorulan Sorular
Görev ayrılığı yalnızca büyük şirketler için mi gerekli?
Hayır. On kişilik bir işletmede de aynı kişi hem fatura kesip hem tahsilat kaydedebiliyorsa risk vardır. Ölçek küçüldükçe kademe sayısı azalır ama ilke değişmez.
Küçük ekipte herkesin birden fazla iş yapması kaçınılmaz, bu durumda ne yapılır?
Tam ayrım mümkün olmadığında ikinci bir kontrol eklenir: örneğin aynı kişi hem fatura kesip hem tahsilat girebiliyorsa, ay sonu mutabakatını üçüncü bir kişi (dış muhasebeci dahil) gözden geçirir.
Rol bazlı erişim ile kullanıcı bazlı erişim arasındaki fark nedir?
Kullanıcı bazlı erişimde her kişiye ayrı ayrı yetki tanımlanır ve personel değişiminde yeniden kurulması gerekir. Rol bazlı erişimde yetki role bağlanır, kişi role atanır; personel değiştiğinde sadece atama değişir.
Denetim izi (log) hangi işlemler için tutulmalı?
Finansal etkisi olan her işlem için: fatura, ödeme, stok düzeltme, fiyat değişikliği, bordro parametresi, cari bakiye düzeltmesi. Salt görüntüleme işlemleri genelde bu kapsamın dışında tutulur.
Yetki matrisi kaç ayda bir gözden geçirilmeli?
Sabit bir kural yok; personel değişikliği, departman yeniden yapılanması veya yeni bir sürecin devreye girmesi matrisin gözden geçirilme tetikleyicisidir. Yıllık bir rutin kontrol de asgari pratik olarak önerilir.
Qera’ya geçişte mevcut yetki yapısı nasıl taşınır?
Kurulum sürecinde mevcut organizasyon şeması ve iş akışları esas alınarak yeni bir rol matrisi tasarlanır; eski sistemdeki dağınık yetkiler birebir kopyalanmaz, süreç yeniden değerlendirilir.
Başlamak için
Görev ayrılığını ERP kurulumundan sonra değil, kurulum sırasında tasarlamak, sonradan yetki toplama alışkanlığını değiştirmekten çok daha kolaydır. Kurumun kritik işlem listesini çıkarıp mevcut yetki dağılımıyla karşılaştırmak, ilk adım için yeterlidir.
Qera ERP’nin rol bazlı yetkilendirme ve onay zinciri yapısını yakından görmek için Qera ERP ürün sayfasını inceleyebilir, kurumunuzun süreçlerine özel bir gösterim için ücretsiz demo talep edebilirsiniz. Finansal onay güvenliğiyle ilgili farklı bir risk açısı için ERP onay süreçlerinde yapay zekâ destekli sahtecilik riskini, veri güvenliği tedbirleriyle ilgili yükümlülükler için KVKK ceza güncellemesi ve VERBİS eşikleri yazısını inceleyebilirsiniz.
Kaynak: Kişisel Verileri Koruma Kurumu, Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler).
