Case study: Jak firma z branży chemicznej osiągnęła dwucyfrową redukcję kosztów licencji SAP dzięki analizie FUE przed migracją

Pytania zespołu projektowego zgłoszone przed rozpoczęciem inicjatywy:

• Ile licencji FUE (Full Use Equivalent) będziemy realnie potrzebować w nowym środowisku S/4HANA?
• Jak nasze obecne role i uprawnienia wpływają na przyszłą klasyfikację FUE — i koszty?
• Czy migrację do S/4HANA możemy potraktować jako okazję do zmniejszenia ryzyk związanych z rozdziałem obowiązków (SoD)?
• Czy przeprojektowanie ról powinno być odrębną inicjatywą, czy też częścią migracji do S/4HANA?
• Którzy użytkownicy, role lub działy prawdopodobnie będą generować najwyższe koszty licencyjne?
• Jakie porządki lub korekty w dostępach możemy wprowadzić już teraz, zanim podpiszemy nową umowę?
• Jak możemy proaktywnie zarządzać modelem FUE w długim okresie — zwłaszcza że koszty licencji często rosną po 3. roku? (Większość organizacji planuje tylko w horyzoncie 3-letnim, ale umowy FUE zwykle stają się droższe po tym czasie).
• Czy możemy użyć standardowego raportu SLIM*USER i w jakim stopniu spełnia on nasze potrzeby?

Wprowadzenie: Dlaczego FUE ma znaczenie

Przejście na SAP S/4HANA to ważny krok, ale temat licencjonowania bywa często pomijany. Wraz z przejściem z modelu Named User na licencjonowanie Full Use Equivalent (FUE) – szczególnie w ramach kontraktów RISE with SAP – licencje nie są już przypisane do konkretnej osoby, lecz do przyznanych uprawnień. Oznacza to, że projektowanie dostępów bezpośrednio wpływa na przyszłe koszty. Licencjonowanie FUE, w którym cena zależy od nadanych uprawnień (a nie rzeczywistego użycia), może być o 50–150% droższe niż modele oparte na wykorzystaniu. Bez strategicznego przygotowania koszty mogą gwałtownie wzrosnąć.

Przeczytaj najpierw: :   SAP RISE FUE – Is it just a new metric, or a whole new pricing model?

Ten artykuł rozwija temat, opierając się na wynikach naszego studium przypadku.

Przedstawiamy rzeczywisty przykład dużej firmy chemicznej, która przed migracją do S/4HANA przeprowadziła uporządkowaną analizę FUE. Efekt? Dwucyfrowa redukcja prognozowanego zużycia FUE, co przełożyło się na mierzalne oszczędności i silniejszą pozycję negocjacyjną wobec SAP. Przed rozpoczęciem projektu intensywnie poszukiwaliśmy oficjalnych materiałów SAP porównujących modele licencyjne, jednak nie znaleźliśmy żadnego autoryzowanego przez SAP. Eksperci branżowi i konsultanci SAP wskazują, że podejście typu „lift-and-shift” – czyli przeniesienie istniejących ról użytkowników i uprawnień z SAP ECC do S/4HANA bez zmian – może prowadzić do znacznego wzrostu kosztów licencyjnych w modelu FUE, szczególnie po 3 latach. Wynika to z faktu, że model FUE przypisuje koszty licencji na podstawie działań, do których użytkownik ma uprawnienia, a nie jego stanowiska czy działu. Role, które były opłacalne w modelu Named User, mogą generować wyższe koszty, jeśli nie zostaną dostosowane do wymogów FUE.

Upiec dwie pieczenie na jednym ogniu

To wyzwanie to także szansa. Dzięki szczegółowej analizie ról użytkowników i dopasowaniu ich do rzeczywistych potrzeb biznesowych, organizacje mogą zidentyfikować obszary, w których można nie tylko poprawić bezpieczeństwo i uprościć dostępy, ale też uzyskać znaczne oszczędności na kosztach licencji. Wymaga to jednak nie tylko przemyślanego przejścia z modelu Named User (stary model licencji SAP) do FUE, ale też wykorzystania nowego modelu jako katalizatora redukcji uprawnień – ograniczenia dostępów tylko do faktycznie używanych transakcji. Takie proaktywne podejście pozwala zoptymalizować wydatki licencyjne i dostosować je do rzeczywistych potrzeb operacyjnych.

1. Sytuacja początkowa – gdzie zaczynamy.

The client Klientem była duża firma chemiczna działająca w kilku krajach europejskich. Ich system SAP ERP (ECC) funkcjonował od ponad dekady. W tym czasie role użytkowników były tworzone i modyfikowane w sposób „organiczny” – często przez kopiowanie, rozszerzanie lub przypisywanie uprawnień „na zapas”. Gdy firma zaczęła planować migrację do S/4HANA, ich środowisko zawierało:

• Ponad 2 500 aktywnych użytkowników SAP,
• dziesiątki tysięcy ról – wiele z nich się pokrywało lub było nieaktualnych,
• Rozbudowane uprawnienia z ryzykami SoD w wielu obszarach biznesowych,
• Licznych „power userów” z szerokimi dostępami (kopiowane role z adminów lub środowisk testowych),
• Model licencji oparty na Named Users: Professional, Limited Professional i Employee.

Organizacja wiedziała, że po przejściu na RISE with SAP będzie musiała przyjąć nowy model FUE. Nie wiedzieli jednak, ile FUE rzeczywiście potrzebują ani jak ich obecny projekt ról przełoży się na koszty w nowym modelu.

Pytania, które zadał zespół projektowy:

• Ile FUE będziemy realnie potrzebować w nowym środowisku S/4HANA?
• Jak nasze obecne role i uprawnienia wpływają na przyszłą klasyfikację FUE – i koszty?
• Czy migrację do S/4HANA możemy potraktować jako okazję do zmniejszenia ryzyk SoD?
• Czy przeprojektowanie ról powinno być odrębną inicjatywą, czy częścią migracji?
• Którzy użytkownicy, role lub działy generują najwyższe koszty licencyjne?
• Jakie porządki w dostępach można wprowadzić już teraz, przed podpisaniem nowej umowy?
• Jak proaktywnie zarządzać modelem FUE w dłuższej perspektywie, skoro koszty rosną po 3. roku?

Before the project the team only suspected that a simple one-to-one migration of current roles (the so-called „lift-and-shift”) might cause a sharp increase in license costs.

2. False-start: Dlaczego raport SLIM zawiódł

Początkowe podejście klienta polegało na wykorzystaniu standardowego raportu dostarczonego przez SAP w nocie SAP 3113382, stworzonego z myślą o wsparciu organizacji w szacowaniu zapotrzebowania licencyjnego w modelu Full Use Equivalent (FUE). Choć na pierwszy rzut oka wydawało się to rozsądnym punktem wyjścia, to narzędzie techniczne szybko ujawniło swoje ograniczenia i okazało się niewystarczające do opracowania strategii licencyjnej zoptymalizowanej pod kątem kosztów. Raport (SLIM_USER_CLF_HELP) oblicza zapotrzebowanie na licencje na podstawie obecnych uprawnień w systemie ECC – zarówno dla użytkowników, jak i ról. Na papierze obiecuje przejrzystość, w praktyce jednak często wprowadza zamieszanie i wymaga czasochłonnej, ręcznej interpretacji.

Dlaczego to podejście zawiodło:

❌ A. Brak elastyczności i podejścia strategicznego

Raport zakłada, że obecny stan przypisań ról jest poprawny, aktualny i odzwierciedla rzeczywiste potrzeby biznesowe. W rzeczywistości jednak, lata nadmiernego przydzielania uprawnień i tzw. dryfu ról sprawiają, że to założenie często jest nieprawdziwe — co prowadzi do zawyżonego zapotrzebowania na licencje.

❌B. Złożona i sztywna struktura danych

Używa ponad 700 obiektów autoryzacyjnych i 2000 warunków, np.:

• ACTVT=03 (wyświetlanie) → Self-Service
• ACTVT=01 (tworzenie) → Core lub Advanced

Jednak nawet pojedynczy, przypadkowo uwzględniony obiekt (np. M_RECH_BUK z prawami do tworzenia) może spowodować „awansowanie” użytkownika z licencji Core do Advanced — niezależnie od rzeczywistego użycia systemu. W przypadku tego Klienta analiza surowych wyników raportu stała się uciążliwa. Interfejs (widoczny w raporcie szczegółów roli) wymagał żmudnej, ręcznej analizy: „Najpierw widzę użytkownika i licencję, którą rzekomo powinien mieć. Potem sprawdzam, jakie ma role — i jaka licencja wynika z każdej z nich. Następnie muszę wejść w każdą rolę i sprawdzić, które dokładnie obiekty autoryzacyjne powodują przypisanie do danego typu licencji. To bardzo czasochłonne” — przekazał klient w ramach informacji zwrotnej.

Raport nie daje wglądu z perspektywy procesu biznesowego, typu użytkownika czy aplikacji, co utrudnia identyfikację potencjału optymalizacji. Prezentuje techniczne szczegóły bez kontekstu — przez co zespoły bezpieczeństwa i licencyjne muszą „odtwarzać” znaczenie ról krok po kroku. Brakuje też priorytetyzacji. W idealnym scenariuszu narzędzie pomagałoby znaleźć tzw. „low-hanging fruit” — użytkowników, którym wystarczyłoby zmniejszyć tylko 10–20% uprawnień, aby obniżyć poziom licencji. Tymczasem raport traktuje wszystkich użytkowników jednakowo, często zaczynając od tych, których profile wymagałyby ponad 80% przebudowy — co jest najmniej opłacalne na początek. Jeszcze ważniejsze jest to, że narzędzie nie uwzględnia rzeczywistego użycia. Gdyby można było połączyć obiekty wpływające na licencję z danymi o faktycznym wykorzystaniu (czy dana transakcja lub obiekt były naprawdę używane i przez kogo), raport mógłby stać się nie tylko narzędziem klasyfikacyjnym, ale praktycznym wsparciem strategicznych decyzji.

Szczególnie cennym efektem warsztatów była możliwość dokładnego wskazania, która rola powodowała przypisanie użytkownika do wyższego poziomu licencyjnego. W wielu przypadkach była to tylko jedna rola. Po sprawdzeniu, że użytkownik w ogóle nie korzystał z żadnej transakcji przypisanej do tej roli, zespół mógł bezpiecznie ją usunąć. Ten prosty krok pozwolił natychmiastowo zmniejszyć liczbę FUE bez wpływu na operacje biznesowe.

❌ C. Brak symulacji i scenariuszy typu „co jeśli”

Nie da się przetestować:

• „Co jeśli usunę ten obiekt?”
• „Co jeśli podzielę rolę na wersję do odczytu i edycji?”
• „Jak wpływa na to faktyczne użycie?”

Jest to szczególnie ograniczające w sytuacjach, gdy role są współdzielone przez wielu użytkowników. Możesz chcieć obniżyć poziom licencji jednemu z nich, ale narzędzie nie uwzględnia wpływu wspólnej roli na innych użytkowników ani nie podpowiada, jak bezpiecznie dostosować role w takim przypadku.

❌D. Manualna i oderwana realizacja

Uruchomienie narzędzia wymaga ręcznego wgrywania i zarządzania zestawami reguł poprzez import plików. Brakuje centralnego nadzoru oraz integracji z procesem projektowania ról, przepływami provisioningu i monitorowaniem aktywności użytkowników. Dodatkowo:

• w niektórych systemach narzędzie nie obsługuje uruchamiania w tle,
• brakuje integracji w czasie rzeczywistym z danymi o faktycznym użyciu systemu,
• narzędzie nie uwzględnia niestandardowych obiektów autoryzacyjnych, na których opiera się działalność wielu firm.

❌ E. Zalecenie SAP: skorzystaj z usługi STAR

Nawet SAP przyznaje, że raport ma ograniczenia. Dokumentacja wprost zaleca, aby uzupełniać go usługą SAP Trusted Authorization Review (STAR) — eksperckim wsparciem w interpretacji i weryfikacji wyników. To samo w sobie wskazuje, że narzędzie nie jest wystarczające do opracowania strategii licencyjnej bez znacznego nakładu pracy manualnej i wsparcia zewnętrznego.

3. Zmienione podejście: Optymalizacja z udziałem GRC i biznesu

Dostrzegając ograniczenia swojej początkowej metodyki, klient zdecydował się wykorzystać posiadane już rozwiązanie SAP GRC Access Control — w szczególności moduły Access Risk Analysis (ARA) oraz Business Role Management (BRM). Alternatywnie możliwe było również skorzystanie z narzędzi takich jak smartGRC, które oferują porównywalne, a w niektórych aspektach nawet bardziej rozbudowane możliwości.

Wdrożenie narzędzi GRC przyniosło wymierne korzyści dzięki funkcjom takim jak:

• Symulacja licencji – możliwość natychmiastowego testowania, jak zmiany w rolach lub obiektach wpłyną na klasyfikację FUE,
• Elastyczność reguł – szybka adaptacja logiki klasyfikacji licencji w odpowiedzi na zmiany kryteriów SAP,
• Integracja z danymi o użyciu – identyfikacja nieużywanych transakcji lub ról w okresie ostatnich 6 lub 12 miesięcy,
• Widoczność licencji – bezpośrednie powiązanie wymaganych typów licencji z rolami, użytkownikami i wnioskami o dostęp.

Jednak najważniejsza zmiana nie wynikała z samego narzędzia, lecz z zaangażowania właściwych osób. Prawdziwym przełomem okazały się warsztaty z interesariuszami biznesowymi. Kluczowa zmiana nastąpiła dzięki serii wspólnych warsztatów, które połączyły zespół złożony z różnych specjalistów:

• Konsultantów bezpieczeństwa SAP, znających techniczną konstrukcję ról i uprawnień,
• Konsultantów funkcjonalnych, rozumiejących, które transakcje wspierają konkretne procesy,
• Interesariuszy biznesowych – w tym kluczowych użytkowników, kierowników działów i właścicieli procesów – posiadających wiedzę o przebiegu procesów, wymogach zgodności i faktycznych potrzebach użytkowników.

Warsztaty te pozwoliły połączyć „suche” dane licencyjne z realiami operacyjnymi. Umożliwiły podejmowanie świadomych i konkretnych decyzji, odpowiadając m.in. na pytania:

• Czy ta rola naprawdę potrzebuje dostępu do edycji, czy wystarczy tylko podgląd?
• Czy rolę można podzielić na dwie „persony”, by obniżyć poziom licencji?
• Czy ta transakcja nadal jest potrzebna?
• Czy tę grupę użytkowników można przenieść do modelu samoobsługowego, jeśli uprościmy proces?

To podejście oparte na współpracy pozwoliło organizacji przeprojektować dostęp z uwzględnieniem zarówno bezpieczeństwa, jak i efektywności kosztowej — unikając polegania na nieaktualnych założeniach i przestarzałych strukturach ról.

Efekty warsztatów:

Dzięki połączeniu wiedzy technicznej z kontekstem biznesowym organizacja osiągnęła:

• Przejrzysty obraz rzeczywistego ryzyka licencyjnego,
• Pewność siebie w negocjacjach kontraktu FUE z SAP — opartą na danych i uzasadnieniu biznesowym,
• Dwucyfrową redukcję prognozowanego zapotrzebowania na FUE — jeszcze przed migracją choćby jednego użytkownika do S/4HANA.

4. Mierzalne efekty: Od złożoności do przejrzystości

Po przejściu od czysto technicznego podejścia do strategii licencyjnej opartej na kontekście biznesowym, organizacji udało się przekształcić złożoność w przejrzystość — a prognozowane koszty w realne oszczędności. Dzięki połączeniu narzędzi GRC z ustrukturyzowaną walidacją biznesową osiągnięto namacalne rezultaty w wielu obszarach:

✅ Dwucyfrowa redukcja liczby FUE

Dzięki symulacjom, czyszczeniu ról i ich przeprojektowaniu firma zredukowała prognozowane zużycie FUE o ponad 15% — bez kompromisów w zakresie potrzeb operacyjnych i doświadczenia użytkowników.

✅ Eliminacja nieużywanych lub zawyżonych dostępów

Do usunięcia zakwalifikowano role i transakcje przypisane użytkownikom, które nie były używane przez ponad 12 miesięcy, m.in.:

• Role techniczne i testowe,
• Przejęte uprawnienia administratorów,
• Sklonowane role bez uzasadnienia biznesowego,
• Dostępy nieaktualne z powodu zmian organizacyjnych.

✅ Uproszczenie i podział ról

Role generujące wysokie koszty zostały przeprojektowane na warianty, np. „tylko podgląd” vs „edycja”. Dzięki temu wielu użytkowników zostało przeklasyfikowanych z poziomu Advanced na Core lub Self-Service, znacząco obniżając koszt licencji na użytkownika.

✅ Inteligentniejsze przypisywanie licencji

Licencje przypisywano na podstawie rzeczywistego zachowania w systemie, a nie na podstawie stanowiska czy przestarzałych map przypisań. Nadmiarowo licencjonowani użytkownicy — typowy problem w poprzednim podejściu — zostali skorygowani na podstawie realnych wzorców użycia.

Dodatkowe wnioski z praktyki:

• Nawet niewielkie zmiany w wartościach aktywności (np. zamiana „edycji” na „podgląd”) mogą znacząco wpłynąć na klasyfikację FUE.
• Współdzielone role wykorzystywane przez różne persony zniekształcają rzeczywisty obraz licencyjny.
• Katalogi aplikacji Fiori często zawierają wiele transakcji back-endowych — co po cichu zawyża koszty licencyjne.
• Narzędzia GRC są najskuteczniejsze, gdy są połączone z danymi o rzeczywistym użyciu i kontekstem biznesowym.

Kluczowe wnioski i podsumowanie:

• Zacznij wcześnie — licencjonowanie zaczyna się od projektowania ról. Zostawienie kwestii licencji na koniec projektu to kosztowny błąd. Decyzje o dostępach podejmowane na początku bezpośrednio wpływają na liczbę FUE.
• Nie polegaj wyłącznie na surowych raportach. Raporty, takie jak SAP Note 3113382, mogą być punktem wyjścia — ale brakuje im symulacji, przejrzystości i kontekstu biznesowego. Wartość przynoszą dopiero rozwiązania GRC (SAP GRC AC lub alternatywy jak smartGRC) połączone z analizą użycia i redesignem ról.
• Zaangażuj biznes — kontekst zmienia wszystko. Największą dźwignią optymalizacji nie było oprogramowanie, lecz współpraca z biznesem. Warsztaty wnosiły zrozumienie rzeczywistości, którego żadne narzędzie samo nie zapewni.
• Połącz symulację i rzeczywiste użycie. Symulacja wpływu FUE i powiązanie jej z faktycznymi danymi o użyciu umożliwiły świadome, oparte na danych czyszczenie dostępów i optymalizację licencji.
• Włącz licencjonowanie w kulturę dostępową. Uwzględnianie FUE w codziennych procesach przydzielania dostępów stworzyło kulturę ciągłej kontroli kosztów — gdzie każdy wniosek o dostęp był okazją do weryfikacji kosztu względem potrzeby.

FUE to nie tylko metryka — to nowy model operacyjny.

Organizacje, które potraktują go jako formalność w kontrakcie, zablokują się na niepotrzebnie wysokie koszty. Te, które podejdą do niego jako do elementu projektowego i zarządczego, odblokują długofalową wartość.

To studium przypadku pokazuje, że przy odpowiednich narzędziach, danych i ludziach, licencjonowanie SAP może przejść z kategorii ryzyka finansowego do strategicznej przewagi — i pozostać zoptymalizowane także po uruchomieniu systemu.

—

Sources:

• E3 Magazine: The publication notes that „entitlement-based licensing is on average 50 to 150 percent more expensive than usage-based licensing,” emphasizing the financial impact of SAP’s authorization-based approach. E3-Magazin
• Redress Compliance: Their analysis indicates that „authorization-based licensing is typically 50–150% more expensive than usage-based licensing,” underscoring the potential for increased costs if licenses are not optimized. com
• SAP Licensing Experts: They mention that such models can be „50–150% more expensive than true usage-based models if they are not optimized,” suggesting that careful license management is crucial to control expenses.