SAP Business One'da Yetkilendirme ve Onay Süreçleri

SAP Business One'da kontrol iki tamamlayıcı mekanizmayla kurulur: yetkilendirme (kim hangi ekranı ve veriyi görebilir, hangi işlemi yapabilir) ve onay prosedürleri (hangi belge, hangi koşulda, kimin onayından geçmeden ilerleyemez). Yetki matrisi erişimin sınırını, onay akışı ise istisnanın yönetimini tanımlar; ikisi birlikte kurulduğunda sistem hem güvenli hem akışkan olur. İkisinden biri ihmal edildiğinde ise sonuç ya herkesin her şeyi yapabildiği bir serbestlik ya da işin yürümediği bir bürokrasidir.

Sahada devraldığımız kurulumlarda en sık gördüğümüz iki uç var: ya proje telaşında herkese geniş yetki verilmiş ve yıllardır öyle kalmış, ya da kâğıt üstündeki her kural onaya çevrilmiş ve satış ekibi "sistem bizi yavaşlatıyor" diye Excel'e geri kaçmış. Bu yazıda dengeyi kuran yaklaşımı anlatıyoruz: yetki matrisi nasıl tasarlanır, onay prosedürleri nerede kullanılır, nerede kullanılmaz.

Yetkilendirmenin katmanları

SAP Business One'da erişim kontrolü tek bir ekrandan ibaret değildir; birkaç katman birlikte çalışır:

• Genel yetkiler (General Authorizations): Modül, ekran ve işlem bazında tam yetki / salt okunur / yetkisiz ayrımı. Matrisin gövdesi budur.
• Veri sahipliği (Data Ownership): Belgeyi kimin görebileceğini belge sahibi üzerinden sınırlar — satış temsilcisinin yalnızca kendi müşterilerinin belgelerini görmesi bu katmanda kurulur.
• Form ve alan seviyesi kısıtlar: Ekranın tamamı değil, tek bir alanın (örneğin fiyat veya iskonto alanı) düzenlenebilirliği kontrol edilir.
• Süper kullanıcı ayrımı: Süper kullanıcı tüm yetki kontrollerini baypas eder. İlkemiz net: süper kullanıcı sayısı bir elin parmaklarını geçmemeli ve günlük operasyon hesabı olarak asla kullanılmamalıdır.

Bu katmanlara ek olarak lisans türü de doğal bir sınırdır: rol bazlı Limited lisanslar (Financials, Logistics, CRM) kullanıcıyı zaten kendi alanına kısıtlar. Yetki matrisi tasarlanırken lisans planıyla birlikte düşünülmelidir — lisans türlerinin fiyat ve kapsam boyutunu ayrıca yazmıştık.

Yetki matrisi: rolden başlayın, kişiden değil

En yaygın tasarım hatası, yetkileri kişi kişi vermek. "Ayşe Hanım'a şu ekranı açalım" ile başlayan düzen, iki yıl sonra kimsenin haritasını çıkaramadığı bir yamalı bohçaya dönüşür. Önerdiğimiz düzen rol bazlıdır:

1. Rolleri tanımlayın: Satış temsilcisi, satış müdürü, depo sorumlusu, muhasebe uzmanı, finans yöneticisi, satın almacı... Tipik bir KOBİ'de 8-12 rol yeterlidir.
2. Rol başına yetki setini yazın: Her rol için ekran/işlem listesi — tam, salt okunur, kapalı. Bu doküman sistemin dışında, yaşayan bir belge olarak durur.
3. Kullanıcıyı role eşleyin: Yeni personel geldiğinde soru "hangi ekranları açalım" değil "hangi rol" olur; işten ayrılmada kapatma da aynı hızla yapılır.
4. İstisnaları yazılı gerekçeye bağlayın: Rol dışı her yetki talebi, kim istedi ve neden sorusunun cevabıyla kayda geçer.

Matris tasarımında yol gösteren ilke görevler ayrılığıdır (segregation of duties): kritik zincirlerde aynı kişi hem belgeyi yaratıp hem onaylayamamalı. KOBİ ölçeğinde kadro darlığı bunu her zaman saf haliyle mümkün kılmaz — o durumda telafi edici kontrol kurulur: işlemi engellemek yerine görünür kılmak, örneğin kendi açtığı satın almayı kapatan kullanıcının işlemlerini haftalık istisna raporuna düşürmek.

Onay prosedürleri: istisnanın motoru

Onay prosedürleri (Approval Procedures), belge kaydını koşula bağlar: koşul sağlanırsa belge taslak olarak bekler, tanımlı onaycı(lar) karar verene kadar ilerlemez. Kurgunun üç bileşeni vardır — hangi belgeler (sipariş, satın alma, ödeme...), hangi koşul (tutar eşiği, iskonto oranı, kredi limiti aşımı veya sorgu tabanlı özel koşul) ve kim onaylar (tek onaycı, birden çok aşama, "n kişiden biri" yapıları).

Sorgu tabanlı koşullar, mekanizmanın asıl gücüdür: "iskontosu şu oranı aşan satış siparişi", "vadesi geçmiş bakiyesi olan müşteriye yeni sevkiyat", "bütçe hesabını aşan masraf kaydı" gibi şirkete özgü kurallar, standart araçla kurulur. Bu esnekliğin dengesi de şudur — her kural bir bekleme noktasıdır. Tasarım ilkelerimiz:

İlke	Gerekçe
Rutini onaya bağlamayın, istisnayı bağlayın	Her belge onaydan geçiyorsa onay anlamını yitirir, refleks "hepsini onayla"ya döner
Eşikleri gerçek veriden türetin	Tutar eşiği masa başında değil, geçmiş belge dağılımına bakılarak konur
Onaycıya vekil tanımlayın	Onaycının izni, sürecin tatili olmamalı
Onay süresini izleyin	Bekleyen belge yaşlandırması haftalık rapora bağlanır; bekleyen onay, geciken sevkiyattır
Reddin gerekçesi zorunlu olsun	"Reddedildi" tek başına öğretmez; gerekçe, talebi düzeltmenin yoludur

Bir saha gözlemi: onay prosedürünün amacı kontrol kadar hızdır. Doğru kurulmuş onay akışı, e-postayla ve koridorda yürüyen görünmez onayları sistemin içine alır — "kim onaylamıştı?" sorusunun cevabı artık belgeye işlenmiş durumdadır. Denetim (iç denetim, bağımsız denetim, kurumsal müşteri tedarikçi denetimleri) tarafında bu izlenebilirlik, KOBİ'lerin tahmin ettiğinden erken kapılarını çalar.

Kurulum sırası ve yaşatma düzeni

Yetki ve onay yapısını devreye alırken izlediğimiz sıra: önce rol matrisi (analiz fazında, süreçlerle birlikte), sonra genel yetkiler ve veri sahipliği, en son onay prosedürleri — ve onaylar canlıya geçişten itibaren değil, ilk haftaların tozu dindiğinde sıkılaştırılarak. İlk günden maksimum sıkılıkta açılan kurulum, kullanıcı daha ekranı öğrenirken bekleme kuyrukları üretir ve sisteme karşı ittifak kurdurur.

Yaşatma tarafında üç rutin öneriyoruz: çeyreklik yetki gözden geçirmesi (ayrılan/rol değiştiren kullanıcılar, biriken istisnalar), onay kurallarının yıllık revizyonu (eşikler enflasyon ve iş hacmiyle eskir) ve süper kullanıcı envanterinin düzenli kontrolü. Bu rutinlerin sahipsiz kalmaması için teknik destek sözleşmelerimizde periyodik sağlık kontrolünün parçası olarak yürütüyoruz.

Son bir not: yetki yapısı ne kadar iyi kurulursa kurulsun, kullanıcı neyi neden yapamadığını bilmiyorsa sonuç yine sürtünmedir. Rol bazlı kullanıcı eğitiminde her rolün kendi yetki sınırlarını ve onay akışlarını görmesi, "sistem izin vermiyor" çağrılarının en etkili panzehiridir. Yetkilendirme, SAP Business One kurulumunun teknik değil kurumsal katmanıdır — iyi kurulduğunda sistemin değil, şirketin disiplinini yansıtır.

Örnek rol seti: tipik bir KOBİ'de matrisin iskeleti

Her şirketin matrisi kendine özgüdür; yine de başlangıç iskeleti olarak şu rol seti çoğu KOBİ'de karşılık bulur:

Rol	Ana yetki alanı	Tipik kısıt
Satış temsilcisi	Teklif ve sipariş oluşturma, kendi carileri	Fiyat/iskonto alanı sınırlı; başkasının belgesi kapalı
Satış müdürü	Tüm satış belgeleri, iskonto onayı	Muhasebe ekranları salt okunur
Depo sorumlusu	İrsaliye, mal kabul, transfer, sayım	Fiyat alanları görünmez; fatura kapalı
Satın almacı	Talep ve sipariş oluşturma	Eşik üstü sipariş onaya düşer
Muhasebe uzmanı	Fatura, ödeme, dekont kayıtları	Ödeme talimatı onayı ayrı rolde
Finans yöneticisi	Ödeme onayı, banka ekranları, raporlar	Kayıt oluşturmaz, onaylar
Genel müdür	Tüm raporlar, üst eşik onayları	Günlük belge girişi yok

Tablo bir şablon değil, konuşma başlatıcıdır: her satır, kurulum çalıştayında şirketin gerçeğiyle test edilir. Deneyimimizde en verimli soru şudur — "bu rolde işe yeni giren biri, ilk gün hangi ekranları görmeli?" Cevap, matristen fazlasını da söyler: işin kendisinin ne kadar tanımlı olduğunu gösterir.

Devreye alma ve denetim kontrol listesi

• Rol matrisi yazılı ve yönetim onaylı mı; sistemdeki yetkilerle birebir mi?
• Süper kullanıcı listesi asgaride mi; günlük işte süper kullanıcı hesabı kullanılmıyor mu?
• Kritik zincirlerde (satın alma-ödeme, satış-iskonto) görevler ayrılığı ya da telafi edici kontrol var mı?
• Onay prosedürleri yalnızca istisnayı mı yakalıyor; eşikler geçmiş belge dağılımından mı türetildi?
• Her onaycının vekili tanımlı mı; bekleyen onaylar yaşlandırma raporuyla izleniyor mu?
• İşten ayrılma ve rol değişikliği için kullanıcı kapatma/güncelleme prosedürü işliyor mu?
• Çeyreklik yetki gözden geçirmesi takvime bağlı mı, sahibi belli mi?
• İstisna yetkiler gerekçeli ve kayıtlı mı?
• Test/eğitim ortamındaki kullanıcı hesapları canlı ortamdan ayrık mı?
• Rol matrisi dokümanı ile sistemdeki fiili yetkiler en son ne zaman karşılaştırıldı?

Bu listeyi iç denetim hazırlığı olarak da kullanabilirsiniz: dış denetçinin veya kurumsal müşterinin tedarikçi denetiminin soracağı soruların büyük kısmı, bu maddelerin türevidir.

Sık sorulan sorular

SAP Business One'da kullanıcı bazında ekran ve alan kısıtlaması yapılabilir mi?

Evet; genel yetkilerle ekran/işlem seviyesinde, form ayarları ve alan kısıtlarıyla tek alan seviyesinde, veri sahipliğiyle belge görünürlüğü seviyesinde kontrol kurulur. Pratikte bu kontrolleri kişi kişi değil, rol bazlı bir matris üzerinden yönetmenizi öneriyoruz.

Onay prosedürü hangi belgelerde kullanılabilir?

Satış ve satın alma belgeleri, ödemeler, stok işlemleri dahil geniş bir belge yelpazesinde; koşullar tutar, oran gibi hazır kriterlerle veya sorgu tabanlı özel kurallarla tanımlanır. Tasarım ilkesi bellidir: rutin akış onaysız ilerler, istisna onaya düşer.

Onaycı izindeyken belgeler bekler mi?

Vekil tanımlanmadıysa evet — ve bu, kurulumda en sık atlanan ayrıntıdır. Onay şablonlarında birden çok onaycı veya vekil yapısı kurmak, iznin ve yoğunluğun süreci kilitlemesini engeller; bekleyen onayların yaşlandırma raporuyla izlenmesi de güvenlik ağıdır.

Onay prosedürleri belge akışını yavaşlatmaz mı?

Yanlış kurulursa yavaşlatır; doğru kurulumda tam tersi olur, çünkü e-postada ve koridorda yürüyen görünmez onaylar sistemin içine taşınır ve beklemeler görünür hale gelir. Ölçüt basittir: rutin belge onaysız akmalı, yalnızca istisna onaya düşmeli ve bekleyen onaylar yaşlandırma raporuyla izlenmelidir.

Yetki değişikliklerinin kaydı tutulur mu?

Kim, neye, ne zaman erişti ve yetkilerde ne değişti sorularının izi, sistem günlükleri ve değişiklik kayıtlarıyla desteklenir; kritik ekranlarda alan bazlı değişiklik geçmişi de açılabilir. Denetim tarafında asıl istenen, bu kayıtların varlığından çok, yetki değişikliklerinin yazılı gerekçeye bağlanmış olmasıdır.

Mevcut kurulumumuzda yetkiler yıllardır elden düzenlendi; toparlamak için sıfırdan mı kurmak gerekir?

Çoğu durumda hayır; önce mevcut durumun envanteri çıkarılır (kim, neye, hangi yolla erişiyor), sonra hedef rol matrisi tasarlanır ve kademeli geçiş yapılır. Bu toparlama, çalışan sistemde kesintisiz yürütülebilen bir iştir — kapsamını netleştirmek için keşif görüşmesi yeterlidir.