SAP RISE FUE to nie tylko nowa metryka – to zupełnie nowe podejście do licencjonowania SAP

Czym jest model SAP FUE? Czy ta zmiana ma znaczenie dla klientów?

Model FUE (Full Use Equivalent) to znacząca zmiana w sposobie licencjonowania i mierzenia korzystania z systemów SAP. W przeciwieństwie do tradycyjnych modeli opartych na użytkownikach nazwanych (named users), model FUE wprowadza bardziej elastyczne i oparte na rolach podejście do licencjonowania. Ma to szczególne znaczenie w kontekście rozwiązań chmurowych, takich jak RISE with SAP, gdzie użytkownicy korzystają z różnych systemów i wykonują wiele zadań biznesowych.

W modelu FUE licencje przypisuje się na podstawie zdefiniowanych wcześniej person żytkowników, z których każda odzwierciedla określony zakres obowiązków. Przykłady to: Business User, Developer, Professional User czy Self-Service User.

Każdej personie przypisany jest określony współczynnik FUE, który wpływa na całkowite zużycie licencyjne. Na przykład:

• Developer = 5,0 FUE
• Self-Service User = 0,033 FUE

Całkowita liczba FUE bezpośrednio przekłada się na koszt licencji.

OK, ale ile to kosztuje?

Załóżmy uproszczony scenariusz: środowisko wymaga 1 000 FUE, a średni koszt to 2 000 EUR za 1 FUE rocznie.

To oznacza, że dla organizacji z 1 000 użytkownikami, łączny roczny koszt licencji może wynosić od 66 000 EUR do 2 000 000 EUR, w zależności od przypisanych ról i uprawnień. Warto jednak podkreślić, że rzeczywiste koszty mogą się znacząco różnić w zależności od:

• liczby zakupionych FUE,
• kraju i waluty,
• poziomu rabatów negocjowanych z SAP,
• rodzaju kontraktu i modelu wdrożenia (on-premise, cloud, RISE).

Jedno pozostaje pewne: klasyfikacja FUE ma ogromny wpływ na rachunek za SAP, i traktowanie jej jako „szczegółu technicznego” może oznaczać setki tysięcy euro strat.

Dlaczego SAP wprowadził model FUE?

Model FUE powstał jako element strategii SAP polegającej na przejściu na model subskrypcyjny i rozwiązania chmurowe, takie jak RISE with SAP. Dotychczasowe podejście – licencjonowanie użytkowników nazwanych z dostępem do określonych transakcji – przestało być efektywne w złożonych, hybrydowych środowiskach IT.

Klienci korzystają obecnie z wielu aplikacji SAP, zarówno w chmurze, jak i on-premise. Zarządzanie licencjami w sposób przejrzysty i skalowalny stało się wyzwaniem.

SAP wprowadził model FUE, aby:

• powiązać licencjonowanie z procesami biznesowymi, a nie dostępem technicznym,
• uprościć model subskrypcji w całym ekosystemie SAP,
• i – przynajmniej w teorii – zwiększyć przejrzystość i przewidywalność kosztów licencyjnych.

Ale w praktyce?
Wielu klientów ma ogromne trudności z ustaleniem właściwej liczby FUE. Dlaczego? Ponieważ SAP udostępnia ponad 2 000 reguł licencyjnych oraz ponad 700 obiektów autoryzacyjnych, które określają, jaka licencja ma zastosowanie w danym przypadku.

SAP udostępnia te kryteria (np. poprzez notę 3113382, pliki XLS, dokumentację), co zwiększa przejrzystość, ale odpowiedzialność za interpretację pozostaje po stronie klienta.

Bez odpowiednich narzędzi i procesów, zapewnienie zgodności z modelem FUE może być zadaniem ręcznym, podatnym na błędy.

FUE to tylko nowy model? Naprawdę?

Na pierwszy rzut oka model FUE może wyglądać jak nowy sposób liczenia użytkowników. To błąd.

To największa zmiana w licencjonowaniu SAP od dekad. W tradycyjnym modelu wystarczył login i przypisana rola. Teraz liczy się:

• co użytkownik może zrobić (np. tworzyć, zatwierdzać, drukować),
• jakie ma przypisane obiekty autoryzacyjne,
• oraz która persona FUE najlepiej pasuje do jego zachowania w systemie.

Przykład: dostęp do transakcji BP

Użytkownik z dostępem do transakcji BP (Business Partner):

• tylko do podglądu (Activity 03) → Self-Service User
• możliwość tworzenia (Activity 01) lub zmiany (Activity 02) → Core lub Advanced User

Nawet jeśli użytkownik nie wykonuje tych czynności na co dzień, sama możliwość ich wykonania może wielokrotnie zwiększyć koszt licencji.

Co mówi SAP Nota 3113382?

SAP udostępnia raport SLIM_USER_CLF_HELP, który:

• analizuje użytkowników, role i profile w ECC,
• szacuje ich przejście do odpowiednich licencji FUE w S/4HANA,
• wykorzystuje reguły licencyjne SAP S/4HANA Core (ponad 2 000 warunków i 700+ obiektów).

Ograniczenia:

• raport nie rozróżnia użycia core vs engine,
• wymaga walidacji eksperta (np. usługi STAR Review od SAP).

Dobra wiadomość?

Rozwiązania takie jak SAP GRC Access Control oraz SmartGRC umożliwiają:

• analizę przypisań pod kątem FUE,
• symulację wpływu zmian ról na licencjonowanie,
• identyfikację przerostu uprawnień,
• raportowanie danych na potrzeby audytu.

Jaką rolę pełni GRC w kontekście FUE?

W nowym modelu FUE GRC staje się kluczowym elementem nie tylko zgodności, ale i kontroli kosztów. To właśnie od GRC zależy, czy organizacja:

• poprawnie przypisze role do person FUE,
• zasymuluje wpływ zmian,
• ograniczy nadmierne uprawnienia,
• zoptymalizuje role z zachowaniem SoD,
• i będzie miała twarde dane na potrzeby audytu.

Jak SmartGRC wspiera klientów?

GRC Advisory stworzyło alternatywę dla SAP GRC Access Control (SmartGRC), które pozwala:

• analizować przypisania pod kątem FUE,
• przypisywać typy licencji do ról i użytkowników,
• symulować wpływ zmian uprawnień na koszty,
• raportować typy licencji przypisanych do użytkowników i ról,
• uwzględniać koszty licencji przy tworzeniu ról i wniosków o dostęp.

Etapy wdrożenia:

1. Budowa rulesetu FUE w GRC,
2. Udostępnienie danych licencyjnych dla biznesu (BRM, ARM, UAR),
3. Raportowanie przekrojowe (rola, użytkownik, system, jednostka).

Podsumowanie

Model SAP FUE to nie tylko nowy sposób liczenia użytkowników — to całkowita zmiana podejścia do kontroli dostępu, kosztów i zgodności.

Ryzykują firmy, które:

• traktują FUE jako formalność,
• przypisują za dużo niepotrzebnych ról,
• nie kontrolują, jak uprawnienia przekładają się na licencje.

Zyskują te, które:

• wdrażają narzędzia do analizy i symulacji,
• planują licencjonowanie jako część strategii GRC,
• optymalizują dostęp z uwzględnieniem kosztów.