SAP Yetkilendirme Optimizasyonu: Maliyet, Güvenlik ve Sürdürülebilirlik Ekseninde Stratejik Bir Dönüşüm

Projenin son dakika krizi “Yetkilendirme”

SAP projelerinin dinamik ve stresli doğasında, proje ekipleri genellikle fonksiyonel süreçlerin kusursuz çalışmasına odaklanır. Malzeme akışları, muhasebe kayıtları veya üretim teyitleri üzerine harcanan aylar süren eforun gölgesinde, Yetkilendirme (Authorization) konusu genellikle projenin son virajına, yani Kullanıcı Kabul Testleri (UAT) veya Canlıya Geçiş (Go-Live) aşamasına bırakılır. Ancak bu yaklaşım, modern SAP mimarisinde artık sürdürülebilir değildir.

Yetkilendirme, IT departmanları için yönetimi karmaşık, son kullanıcılar için ise genellikle “iş yapmayı engelleyen bir bürokrasi” olarak algılanan hayati bir katmandır. Birden fazla modülün (MM, SD, FI, CO vb.) iç içe geçmiş süreçlerini yönetirken, sadece “kimin hangi ekrana gireceği” değil, “kimin hangi veriyi, hangi organizasyonel seviyede göreceği” sorunu, projenin en karmaşık denklemlerinden biridir.

Geleneksel yaklaşımda “teknik bir destek görevi” olarak görülen yetkilendirme yönetimi, aslında Kavramsal Tasarım (Conceptual Design) aşamasında masaya yatırılması gereken stratejik bir bileşendir. İş süreçleri tasarlanırken yetki matrislerinin oluşturulmaması ve gerekli workshop‘ların yapılmaması; canlı kullanımda güvenlik açıklarına, Segregation of Duties (SoD) ihlallerine ve en önemlisi öngörülemeyen lisans maliyetlerine yol açmaktadır.

Bugün yetkilendirme optimizasyonu, sadece güvenliği sağlamakla kalmayıp, SAP’nin yeni lisanslama modelleriyle doğrudan şirketin finansal tablolarına etki eden bir maliyet yönetimi aracı haline gelmiştir.

1. Oyunun Kuralları Değişti: “Named User”dan FUE (Full User Equivalent) Modeline Geçiş

SAP dünyasında yetkilendirme stratejilerini kökünden değiştiren en önemli gelişme, SAP S/4HANA Cloud ve “RISE with SAP” inisiyatifleri ile hayatımıza giren FUE (Full User Equivalent) lisanslama modelidir. Eskiden alışkın olduğumuz Professional, Limited Professional veya Employee gibi statik kullanıcı tipleri yerini, kullanıcıların sistemde var olan yetkilerine göre katsayı harcayan FUE sistemine bırakmıştır.

FUE Modeli Nedir?

FUE modeli, kullanıcılara atanan yetkilerin ağırlığına göre bir puan (FUE) değeri biçer. Güncel SAP Service Description ve RISE paketlerine göre standart katsayılar şöyledir:

· SAP Advanced Use (1.0 FUE): Sistemin tüm fonksiyonlarına erişebilen, finansal kayıt atan, konfigürasyon yapan kullanıcılar.

· SAP Core Use (0.20 FUE): Operasyonel süreçleri yürüten kullanıcılar. (1 Advanced = 5 Core).

· SAP Self-Service Use (~0.033 FUE): Onay veren veya görüntüleme yapan kullanıcılar. (1 Advanced = 30 Self-Service).

Lisans Optimizasyonu: Teknik Değil, Süreç Tasarımı İşidir

FUE dünyasında lisans maliyetini düşürmek, sadece teknik bir rol kısıtlamasıyla değil, iş süreçlerinin lisans maliyeti farkındalığıyla yeniden tasarlanmasıyla mümkündür.

Kritik Örnek Senaryo: Tedarikçi Fatura Süreci

Klasik bir SAP projesinde, Satın Alma Talebi (PR) açan departman çalışanlarının, gelen tedarikçi faturalarını da sisteme girmesi (MIRO) istenebilir.

· Mevcut Durum (Riskli): Talep açan kullanıcı, faturayı sisteme girip muhasebe kaydını oluşturduğu (Posting) anda, sistem bu kullanıcıyı finansal bir kayıt yarattığı için Advanced User (1.0 FUE) olarak etiketler. Kullanıcının günün %90’ında basit işlemler yapması sonucu değiştirmez; o artık en pahalı lisans grubundadır.

· Optimizasyon (Workshop Çözümü): Yetkilendirme odaklı süreç workshoplarında bu durum analiz edilmelidir. Süreç şu şekilde değiştirilir: Satın alma talebi açan kullanıcı, faturayı doğrudan kaydetmek yerine “Ön Kayıt” (Park Invoice) aşamasına getirir. Faturanın kontrolünü ve “Kesin Kayıt” (Post) işlemini ise halihazırda Advanced lisansa sahip olan Muhasebe departmanı yapar.

· Sonuç: Talep açan kullanıcı “Muhasebe Kaydı Atan” kişi olmaktan çıkar. Lisans kategorisi Advanced User (1.0 FUE) yerine, yaptığı diğer işlere göre Core veya Self-Service seviyesinde kalarak ciddi bir maliyet tasarrufu sağlanır.

Bu örnek, yetkilendirme yönetiminin kod yazmak veya kutucuk işaretlemek değil; şirketin iş yapış şeklini maliyet/fayda ekseninde kurgulamak olduğunu kanıtlar.

2. Sürdürülebilir Bir Mimari İçin: “Task-Based” (Görev Bazlı) Rol Tasarımı

SAP projelerinde teknik ekiplerin düştüğü en büyük tuzaklardan biri, organizasyon şemasını birebir SAP rollerine kopyalamaya çalışmaktır (Job-Based Approach). “Satınalma Uzmanı” adında tek ve devasa bir rol oluşturmak ilk etapta kolay görünse de, süreçler değiştiğinde veya organizasyonel yapılar farklılaştığında bu yaklaşım sürdürülemez hale gelir.

Modern SAP mimarisinde doğru yöntem; SAP Best Practices ışığında yürütülen Fit-to-Standard workshop’larında belirlenen iş süreçlerini analiz etmek ve rolleri “Unvanlara” göre değil, “İşlevlere” (Task) göre tasarlamaktır.

Süreç ve Yetki Eşleşmesi (Process Mapping)

Fit-to-Standard atölye çalışmalarında sadece sistemin nasıl çalışacağı değil, “kimin neyi yapacağı” da belirlenir. Uçtan uca bir süreçte (örneğin Procure-to-Pay), her bir işlem adımının (transaction), raporun veya onay mekanizmasının hangi birim tarafından sahiplenildiği netleştirilmelidir. Bu analiz sonucunda, pozisyonlara özel tek parça roller yerine; tekrar kullanılabilir (reusable), modüler ve yönetilebilir Task-Based roller oluşturulmalıdır.

Senaryo Üzerinden İnceleme

Task-Based yapının gerekliliğini somut bir örnek üzerinden inceleyelim: Bir işletmede Satınalma Departmanının; Teklif Toplama, Sipariş Yaratma ve Sözleşme Yönetimi süreçlerini yürüttüğünü varsayalım. Aynı işletmede, farklı bir birim ise sadece “Sözleşme Oluşturma” işini yapsın.

· Geleneksel (Hatalı) Yaklaşım: Tek bir “Satınalma Uzmanı” rolü yapılır ve içine her şey atılır. Diğer birim için bu rolden kopyalama yapılır ve içinden sipariş yetkileri ayıklanmaya çalışılır. Bu durum, sürekli türeyen ve bakımı zor rollere sebep olur.

· Task-Based (Modern) Yaklaşım: Süreç parçalara bölünür:

1. Rol A (Satınalma Operasyon): Teklif ve Sipariş işlemlerini içerir.

2. Rol B (Sözleşme Yönetimi): Sadece sözleşme yaratma işlemlerini içerir.

Bu modüler yapıda Satınalma Uzmanına (Rol A + Rol B) atanırken, diğer birime sadece (Rol B) atanır. Böylece tek bir rol değişikliği tüm sistemi otomatik günceller ve bakım maliyetleri düşer.

---

3. Yeni Arayüz, Yeni Kurallar: SAP Fiori ve Katalog Yönetimi

SAP S/4HANA ve Cloud ERP dünyasında, kullanıcıların sistemle etkileşimi artık gri ekranlar (SAP GUI) üzerinden değil, SAP Fiori Launchpad üzerinden gerçekleşmektedir. Bu değişim, yetkilendirme mimarisine “Frontend” (Önyüz) ve “Backend” (Arkayüz) ayrımı getirerek kurguyu daha sofistike bir hale getirmiştir.

“Z’leyip Geçme” Tuzağı ve Ekran Kirliliği

Projelerde sıkça yapılan en büyük hatalardan biri, SAP’nin standart iş kataloglarını (Örn: SAP_MM_BC_BUYER) kopyalayıp, temizlik yapmadan kullanıcıya atamaktır. Standart bir katalog yüzlerce uygulama barındırabilir. Kullanıcıya bu katalog verildiğinde, ihtiyacı olan 5 uygulama için ekranında 100 gereksiz uygulama belirir. Bu durum hem ciddi bir “Ekran Kirliliği” yaratır hem de Kullanıcı Deneyimi (UX) açısından sistemi karmaşık gösterir.

Performans Kriteri: “Launchpad” Yavaşlaması

Gereksiz uygulama ataması aynı zamanda teknik bir performans sorunudur. Fiori Launchpad açılırken, sistem kullanıcının yetkili olduğu tüm uygulamaların meta verilerini yüklemeye çalışır. Aşırı yüklenmiş kataloglar; açılış hızını yavaşlatır, tarayıcıyı kasar ve ağ trafiğini artırır. Çözüm, yine Task-Based yaklaşımla sadeleştirilmiş, amaca yönelik özel kataloglar oluşturmaktır.

Public Cloud vs. Private Cloud

Yetkilendirme stratejisi kullanılan sürüme göre de farklılaşır:

· Private Cloud / On-Premise: PFCG ve Kataloglarda tam özgürlük vardır, sıfırdan tasarım yapılabilir.

· Public Cloud: Standart süreçlere (Business Roles) uyum zorunludur. IAM (Identity Access Management) üzerinden kısıtlamalar yönetilir.

4. Denetim ve Güvenlik Kalkanı: Görevler Ayrılığı (SoD) ve GRC Yönetimi

Mükemmel kurgulanmış FUE modelleri ve sade Fiori ekranları; eğer sistemde “Görevler Ayrılığı” (SoD) prensiplerine uyulmuyorsa, denetim masasında başarısız olmaya mahkumdur. Modern bir SAP projesi sadece “çalışan” değil, “denetlenebilir” olmalıdır.

Risk Matrisi ve SoD Çatışmaları

SoD prensibi, kritik bir iş sürecinin tek bir kişinin inisiyatifine bırakılmamasıdır. Örneğin, bir kullanıcının hem “Satıcı Yaratma” hem de “Satıcıya Ödeme Yapma” yetkisine sahip olması, finansal suistimal (Fraud) riskini doğurur.

Bağımsız denetçiler ve iç denetim birimleri, bu “zehirli kombinasyonları” tespit etmek için SAP GRC (Access Control) veya SAP Cloud IAG gibi araçlar kullanır. Bu araçlar, “Risk Simülasyonu” ile rol henüz kullanıcıya atanmadan uyarı verir (“Get Clean”) ve riskin oluşmasını engeller (“Stay Clean”).

“Mitigation” (Azaltıcı Kontrol) Stratejisi

Küçük ekiplerde bazen görevler ayrılığını %100 sağlamak mümkün olmayabilir. Bu durumlarda SAP, “Mitigation Controls” mekanizmasını önerir. Riskli yetki mecburen verilir, ancak sistem dışı bir kontrolör (Örn: Yönetici) işlemleri düzenli olarak denetler ve onaylar. Böylece teknik risk, süreçsel kontrol ile bertaraf edilir.

Sonuç: Yetkilendirme Stratejik Bir Yolculuktur

SAP yetkilendirme yönetimi, projenin sonunda IT ekibine devredilecek teknik bir detay olmaktan çıkmış; projenin Kavramsal Tasarım aşamasında başlayan hayati bir stratejiye dönüşmüştür.

Kuruluşlar yaşayan ve gelişen organizmalardır; iş süreçleri değiştikçe yetki matrislerinin de bu değişime ayak uydurması ve sürekli kontrol edilebilir olması gerekir. Özellikle SAP FUE lisanslama modeli ve Cloud ERP yaklaşımları ile birlikte, hatalı kurgulanmış bir yetkilendirme yapısının maliyeti, geçmişe kıyasla çok daha ağırdır.

Bu nedenle firmalar için en sağlıklı yol haritası;

1.      Mevcut rollerini “kopyala-yapıştır” mantığıyla değil, iş süreçlerine göre optimize ederek (Task-Based) yeniden kurgulamaları,

2.      Lisans maliyetlerini ve güvenlik risklerini (SoD) sürekli izlemeleri,

3.      Ve bu karmaşık, çok katmanlı disiplini yönetmek için konuya hakim uzman firmalar ile çalışmalarıdır.

Unutulmamalıdır ki; doğru kurgulanmış bir yetkilendirme mimarisi sadece sistemi korumakla kalmaz, şirketin dijital dönüşüm bütçesini de korur.

Referanslar ve Kaynakça

Bu makalede yer alan teknik bilgiler ve lisanslama modelleri, aşağıdaki resmi dokümanlar ve standartlar esas alınarak derlenmiştir:

1. SAP Lisanslama ve FUE Modeli:

o SAP S/4HANA Cloud Service Description Guide (2024/2025 Edition)

o RISE with SAP – Licensing Model Overview

2. Teknik Rol Tasarımı:

o SAP Note 2465153 – Manual maintenance of SU24/SU25

o SAP Security Guide for S/4HANA

3. Denetim ve GRC Standartları:

o ISACA – Segregation of Duties (SoD) Control Standards

o SAP Access Control & IAG Documentation