SAP FUE by Design: jak aktywnie zarządzać klasyfikacją licencyjną w projekcie SAP S/4HANA

Wdrożenie SAP S/4HANA generuje dziesiątki, a często setki decyzji projektowych: nowe aplikacje Fiori, rozszerzenia procesów, zmiany ról, nowe obiekty autoryzacyjne, dodatkowe aktywności czy dostęp do kolejnych jednostek organizacyjnych. Każda z tych zmian może potencjalnie wpływać na klasyfikację użytkowników w modelu FUE.

Naturalnym odruchem jest więc próba opiniowania każdego Change Requestu pod kątem licencyjnym. Takie podejście jest możliwe, ale przy większej skali projektu szybko staje się kosztowne, niespójne i trudne do utrzymania. Z drugiej strony pomiar FUE dopiero po uruchomieniu systemu oznacza, że nie zarządzamy ryzykiem - jedynie mierzymy jego skutek.

Dlatego właściwym celem nie powinno być "policzyć FUE jak najwcześniej", ale zarządzać FUE iteracyjnie, wraz z dojrzewaniem rozwiązania.

1. Problem: FUE pojawia się w projekcie dużo wcześniej niż na etapie audytu

W typowym projekcie pytanie o wpływ na FUE pojawia się przy kolejnych CR-ach. Przykładowo zespół chce wdrożyć nową aplikację do masowego tworzenia zamówień albo rozszerzyć rolę Purchasera o funkcje związane z RFQ, ofertami dostawców czy kontraktami. Na poziomie biznesowym zmiana może wyglądać niewinnie, ale technicznie może oznaczać nowy katalog Fiori, nowe obiekty autoryzacyjne i dodatkowe aktywności.

Problem polega na tym, że na etapie koncepcji często nie istnieją jeszcze finalne role ani kompletne uprawnienia. Nie da się więc wykonać pełnej, technicznej klasyfikacji użytkowników. To jednak nie oznacza, że temat FUE należy odłożyć do końca projektu.

1a. Dlaczego to wyzwanie jest strukturalne, nie personalne

Warto zatrzymać się na chwilę i zrozumieć, dlaczego to wyzwanie tak trudno rozwiązać w klasycznym modelu pracy. To nie jest kwestia dobrej woli - to strukturalny problem informacyjny, w którym obie strony operują z ograniczoną wiedzą.

Perspektywa klienta

Polityka licencyjna SAP dla środowisk RISE with SAP i S/4HANA jest skomplikowana i ewolucyjna. Model FUE zastąpił klasyczne Named User Licenses - zamiast liczyć użytkowników po nominalnych typach licencji, mierzy się efektywny zakres uprawnień. Ten sam użytkownik może być klasyfikowany jako Core Use lub Advanced Use w zależności od pojedynczej aktywności w jednym obiekcie autoryzacyjnym.

Klient w trakcie projektu dopiero poznaje funkcjonalność - uczy się, co robi konkretna aplikacja Fiori, jak działa nowy proces, jaka jest wariantowość rozszerzeń i jakie uprawnienia będą wymagane. Jednocześnie ma świadomość, że każda decyzja o rozszerzeniu ma konsekwencje licencyjne. Odpowiedzialne zachowanie to zapytać o wpływ zanim się zdecyduje. Ale żeby zapytać sensownie, trzeba mieć narzędzie - a klient go jeszcze nie ma.

Perspektywa konsultanta

Cel konsultanta funkcjonalnego to konfiguracja systemu i wdrożenie rozwiązania biznesowego. Wiedza o mierniku FUE, 7 klasach licencji, kombinatoryce Auth Object + Field + Value to specyficzna kompetencja techniczno-licencyjna, którą ma stosunkowo wąska grupa specjalistów. Nie każdy konsultant funkcjonalny ma ją w naturalnym pakiecie kompetencji - i słusznie, bo jego głównym zadaniem jest dostarczyć działający proces biznesowy, nie kalkulator licencji.

Bez narzędzia pokazującego natychmiast wpływ zmiany na klasyfikację użytkowników, konsultant musiałby: nauczyć się rulesetu FUE (v1.69, 3 100+ reguł), zrobić analizę populacji użytkowników, wykonać kalkulację kombinatoryczną - a to wszystko dla każdego pojedynczego CR. To dodatkowa specjalizacja i dodatkowa praca, która nie mieści się w klasycznym scope wdrożenia.

Paradoks informacyjny

Klient wie, że powinien znać wpływ FUE zanim zdecyduje - ale nie ma jeszcze narzędzia, które by to pokazało. Konsultant wie jak wdrożyć funkcjonalność, ale nie ma naturalnej wiedzy jak przełoży się to na klasyfikację licencyjną. Efekt: obie strony się starają, ale rachunek pojawia się dopiero na końcu projektu.

W kontekście SAP FUE to oznacza narzędzie, które:

• Ma aktualne dane o rolach i uprawnieniach we wszystkich instancjach SAP klienta,
• Ma wgrany aktualny ruleset FUE (obecnie v1.69) i mechanizm aktualizacji do kolejnych wersji,
• Wie co jest w rolach dziś i czego użytkownicy faktycznie używają,
• Potrafi symulować jak to się zmieni gdy dodamy nową funkcjonalność - z konkretnym efektem na populację użytkowników,
• Prezentuje wynik w formacie, który klient i konsultant potrafią razem przedyskutować przed decyzją Komitetu Projektu.

Dopiero z takim narzędziem klient może odpowiedzialnie decydować, a konsultant może dostarczać kompletną informację bez konieczności ręcznej analizy per CR. Wyzwanie z rynku, opisane na początku, staje się wykonalne - nie przez heroizm zespołu, tylko przez dostarczenie zespołowi właściwego narzędzia.

2. Trzy poziomy dojrzałości analizy FUE

FUE by Design - etap koncepcji

Na początku analizujemy nie role, lecz planowane funkcje biznesowe. Celem nie jest jeszcze ostateczna klasyfikacja użytkownika, ale identyfikacja scenariuszy, które mogą być driverami wyższego FUE.

• Scenariusz A: użytkownik tylko tworzy zgłoszenie zapotrzebowania.
• Scenariusz B: użytkownik prowadzi RFQ i porównuje oferty.
• Scenariusz C: użytkownik dodatkowo wybiera ofertę i tworzy kontrakt lub zamówienie.

Na tym etapie sens mają analizy scenariuszowe i pytania typu "what if": co stanie się z klasyfikacją, jeżeli rozszerzymy zakres procesu o dodatkową funkcję biznesową?

FUE by Authorization - etap budowy

Gdy role, katalogi, aplikacje i obiekty autoryzacyjne zaczynają być konfigurowane, analizę można uszczegółowić. Zamiast oceniać ogólny opis procesu, można wskazać konkretne elementy, które wpływają na klasyfikację.

Przykładowo sam obiekt M_BEST_EKO określa zakres organizacji zakupowej, ale liczba wartości przypisana użytkownikowi nie musi sama w sobie zmieniać FUE. Znaczenie ma kombinacja obiektu, aktywności, funkcji biznesowej i całego efektywnego zakresu uprawnień.

Na tym etapie analiza what-if może odpowiedzieć na dużo bardziej praktyczne pytanie: "co stanie się z klasyfikacją użytkowników, jeśli do roli dodamy tę aplikację, katalog, obiekt lub aktywność?"

FUE by Usage - po uruchomieniu

Po go-live pojawia się kolejna warstwa danych: rzeczywiste wykorzystanie systemu. Można wtedy porównać to, co użytkownik ma przypisane, z tym, z czego faktycznie korzysta. To daje możliwość optymalizacji ról i identyfikacji pojedynczych uprawnień, które niepotrzebnie podnoszą klasyfikację.

Pomiar FUE po go-live jest więc potrzebny, ale sam w sobie nie jest zarządzaniem. Zarządzanie zaczyna się wtedy, gdy skutki decyzji można oceniać jeszcze przed ich wdrożeniem.

3. Dlaczego ręczna analiza każdego CR nie skaluje się

Teoretycznie zespół GRC może opiniować każdy CR osobno: przeanalizować funkcję, role, obiekty, aktywności i potencjalny wpływ na FUE. W praktyce taki model działa tylko przy niewielkiej liczbie zmian.

• CR-y pojawiają się szybciej niż można je ręcznie analizować.
• Role zmieniają się po pierwotnej opinii i wniosek szybko się dezaktualizuje.
• Na etapie koncepcji często brakuje danych technicznych.
• Ta sama funkcja może być realizowana przez różne aplikacje i role.
• Ręczna ocena zależy od wiedzy kilku osób i trudno ją powtarzalnie odtworzyć.
• Excel, spotkania i punktowe analizy tworzą proces kontrolny, ale nie mechanizm ciągłego zarządzania.

3a. Na czym polega analiza wpływu na FUE - wytyczne SAP

Aby zrozumieć skalę problemu, warto zobaczyć jak wygląda oficjalne mapowanie uprawnień na klasyfikację licencyjną. SAP dostarcza ruleset FUE dla RISE with SAP Private Cloud Edition (aktualna wersja: 1.69), który mapuje kombinacje obiektów autoryzacyjnych na 7 głównych klas licencji.

Każda reguła to kombinacja: Auth Object + Auth Field + Auth Value. Przykład - reguła kwalifikująca użytkownika do klasy Advanced Use (GB):

Rule Description: GB Advanced Use
Auth Object:      F_ACES_PER
Auth Field:       ACTVT
Auth Value:       02, 30, 39, F1, UL

Jeśli użytkownik ma w swoich rolach obiekt autoryzacyjny F_ACES_PER z aktywnością 30, jest klasyfikowany jako Advanced Use.

Klasyczny przykład kryjący pułapkę - transakcja BP (Business Partner):

• ACTVT=03 (Display) → użytkownik klasyfikowany jako Self-Service Use (najniższy koszt)
• ACTVT=01/02 (Create/Change) → automatycznie Core lub Advanced Use (kilkadziesiąt razy droższy)

Sama pozorna „mała różnica" między Display a Change w jednej transakcji może przenieść setki użytkowników z Self-Service (0,033 FUE) do Advanced Use (5-10× więcej FUE). Przy stawce średnio ~2 000 EUR za 1 FUE rocznie, taka zmiana w niewinnym CR to konkretne dziesiątki, a nawet setki tysięcy euro dodatkowego kosztu licencji.

SAP udostępnia raport SLIM_USER_CLF_HELP (Nota 3113382), który wykonuje wstępną klasyfikację FUE - ale sama SAP w dokumentacji wskazuje, że wynik wymaga walidacji eksperta (usługa STAR Review) i nie uwzględnia customowych obiektów autoryzacyjnych ani rzeczywistego użycia systemu.

Dlaczego to trudne w praktyce

• Wolumen reguł - 3 100+ pozycji do przeanalizowania. Konsultant funkcjonalny nie zna tego rulesetu na pamięć i nie zna nawet wszystkich obiektów autoryzacyjnych.
• Kombinatoryka - użytkownik ma MAX z uprawnień, nie SUM. Jeśli user X ma już Advanced Use z modułu FI, dodanie Core Use z MM nic nie zmieni. Ale jeśli user Y jest w Self-Service Use, ten sam Core Use go „awansuje". Bez analizy populacji nie da się tego przewidzieć per CR.
• Ruleset ewoluuje - wersja 1.69 to kolejna aktualizacja SAP. Konsultant analizujący CR na v1.65 może pomylić klasyfikację w v1.69.
• Custom Z-authorizations - SAP nie pokrywa ich w oficjalnym rulesetcie. Klient musi je zmapować samodzielnie i utrzymywać mapowanie.
• Industry-specific rulesets - Retail (73 reguły), IS-H Healthcare (74), Real Estate (83), GTS (31), HR (35), Utilities (48) - każda branża ma dodatkowe reguły które mogą się nakładać.
• Dynamiczne zmiany - CR-y aktualizują role kilka razy w tygodniu, dołączają nowi użytkownicy, powstają nowe funkcje. Snapshot analiza z zeszłego miesiąca jest już nieaktualna.
• Skala środowiska - typowe wdrożenie enterprise to kilka instancji SAP (ECC + S/4HANA + BW + landscape dev/test/prod) i wiele tysięcy użytkowników. Każdy dodany CR trzeba przeanalizować w kontekście całej populacji na wszystkich systemach jednocześnie. Ręcznie w Excelu przy takiej skali to setki godzin analityka na każdy Komitet Projektu.

Wracając do wyzwania opisanego na początku artykułu - obie perspektywy mają sens. Klasyczna ręczna analiza per CR faktycznie się nie skaluje przy takiej złożoności, ale też pozostawienie tego na koniec fazy Explore to za późno na zarządzanie. Odpowiedź nie leży w wyborze między „ręcznie per CR" a „zbiorczo na końcu", tylko w zbudowaniu automatycznej warstwy analitycznej zasilanej aktualnymi danymi z SAP i oficjalnym rulesetem.

4. Gdzie smartGRC może wnieść wartość

W takim modelu smartGRC nie powinno być traktowane wyłącznie jako kalkulator FUE. Największa wartość pojawia się wtedy, gdy narzędzie staje się warstwą analityczną pomiędzy projektem ról a modelem licencyjnym.

Dzięki temu pytanie nie brzmi już "czy ta rola jest Core czy Advanced?", lecz: "które konkretne uprawnienie lub funkcja powoduje zmianę klasyfikacji i ilu użytkowników to dotyczy?"

4a. Cztery procesy FUE-aware w cyklu życia dostępu

Aktywne zarządzanie FUE to nie tylko analiza what-if per CR na etapie koncepcji. To wpięcie świadomości licencyjnej w cztery kluczowe procesy operacyjne, które i tak istnieją w organizacji z SAP GRC:

1. Projektowanie ról z ograniczeniem FUE (design time)

Klasyczne projektowanie roli patrzy głównie na dwie osi: funkcjonalność (czy rola pozwala wykonać potrzebne zadania) i SoD (czy nie tworzy konfliktu podziału obowiązków). Trzecia oś, która powinna być równie widoczna: klasyfikacja FUE.

Konkretny scenariusz: rola „Display Only" dla działu finansów powinna dawać Self-Service Use. Ale przez pozorną wygodę dodano do niej obiekt M_RECH_BUK z aktywnością Create - i rola nagle klasyfikuje wszystkich swoich użytkowników jako Advanced Use. Bez świadomości FUE przy projektowaniu, takie sytuacje są normalne - i drogie. Projektant roli powinien widzieć klasyfikację licencyjną w momencie budowy, nie kilka miesięcy później podczas audytu.

2. Tagowanie „drogich" ról w BRM / smartArchitect

Role które mają wysoką klasyfikację FUE (Advanced, Developer) powinny być etykietowane w narzędziu zarządzania rolami - w SAP GRC Access Control BRM, w smartArchitect, albo w każdym innym systemie który obsługuje metadane ról. Etykieta w stylu „License: Advanced (+3,5 FUE / user)" widoczna przy każdej takiej roli zmienia dynamikę procesów downstream.

Przełożony wnioskujący o dostęp dla nowego pracownika widzi od razu, że rola A jest kilkanaście razy droższa niż rola B - i pyta funkcjonalnie: „Czy naprawdę potrzebuje wszystkiego z A, czy wystarczy uboższa B?". To rozmowa która wcześniej się nie odbywała, bo nikt nie widział ceny.

3. Provisioning aware of FUE (workflow)

Kolejny krok: wpięcie widoczności kosztu FUE bezpośrednio w workflow wniosku o dostęp. Kiedy manager zatwierdza dostęp podwładnego, widzi nie tylko czy dostęp niesie ryzyko SoD, ale też:

• jaka klasyfikacja FUE zostanie przypisana użytkownikowi,
• czy zmienia się z aktualnej (np. Core → Advanced),
• ile to kosztuje rocznie w podziale na budżet działu.

Efekt: manager przestaje być tylko „aprobatą SoD", a staje się „aprobatą kosztowo-ryzykową". Odpowiedzialność za koszt licencji rozkłada się na tych, którzy podejmują decyzje o dostępie - a nie tylko na dział finansów, który zobaczy rachunek z SAP na koniec roku.

4. Okresowe przeglądy uprawnień z perspektywy FUE

Tradycyjne User Access Review (UAR) sprawdza „czy ten użytkownik nadal powinien mieć ten dostęp z punktu widzenia funkcji". Warto rozszerzyć to o pytanie kosztowe: „czy ten użytkownik używa dostępu na tyle intensywnie, że uzasadnia klasyfikację Advanced / Developer?".

Praktyczny wynik z realnych projektów: przeglądy oparte o rzeczywiste użycie (usage data z ostatnich 6-12 miesięcy) potrafią zidentyfikować 15-30% użytkowników, którzy mają przypisaną wyższą klasę FUE niż wynikałoby to z ich faktycznej pracy w systemie. Downgrade tych użytkowników do niższej klasy licencyjnej daje natychmiastową oszczędność bez utraty funkcjonalności biznesowej.

5. Warunek krytyczny: aktualne dane

Sama funkcja what-if nie rozwiązuje problemu, jeśli dane do analizy są aktualizowane ręcznie. Eksport z SAP, przygotowanie pliku, import do narzędzia i ponowienie całego procesu przy każdym większym CR nie skaluje się przy intensywnym projekcie.

Dlatego aktywne zarządzanie FUE wymaga nie tylko modelu analitycznego, ale również sprawnego i możliwie automatycznego zasilania narzędzia aktualnymi danymi z projektu i środowiska SAP.

Dopiero wtedy można zbudować praktyczny cykl:

zmiana projektowa → aktualizacja roli → analiza what-if → ocena wpływu na użytkowników → decyzja → ponowna weryfikacja po wdrożeniu.

6. Model docelowy: FUE jako constraint projektowy

Najbardziej dojrzałe podejście polega na traktowaniu FUE podobnie jak SoD czy architektury bezpieczeństwa: nie jako kontroli wykonywanej po zakończeniu projektu, ale jako jednego z ograniczeń uwzględnianych podczas projektowania.

Nie oznacza to, że na pierwszym etapie musimy znać finalną licencję każdego użytkownika. Dokładność analizy rośnie wraz z dojrzałością projektu:

• koncepcja → ocena scenariuszy i potencjalnych driverów FUE,
• budowa → analiza finalnych ról i uprawnień,
• testy/go-live → symulacja wpływu na populację użytkowników,
• run → porównanie uprawnień z rzeczywistym użyciem i optymalizacja.

7. Wniosek

Nie chodzi o to, żeby dokładnie policzyć FUE jak najwcześniej. Chodzi o to, żeby wraz z dojrzewaniem projektu coraz dokładniej rozumieć konsekwencje decyzji projektowych.

Ręczna analiza pojedynczych CR-ów może być dobrym mechanizmem kontrolnym, ale nie skaluje się jako model zarządzania. Pomiar wykonany dopiero na końcu pokazuje skutek, ale nie pozwala już efektywnie wpływać na projekt.

Narzędzie takie jak smartGRC może wypełnić tę lukę, jeżeli jest używane nie tylko do końcowego pomiaru FUE, ale do analiz scenariuszowych i what-if w trakcie projektu oraz późniejszego zestawienia uprawnień z rzeczywistym użyciem. Warunkiem jest jednak regularny dostęp do aktualnych danych - bez tego nawet dobra analityka szybko zamienia się w kolejny ręczny proces.

Najważniejsze pytanie nie brzmi: "jaką licencję ma ta rola?", ale "która decyzja projektowa zmienia klasyfikację użytkownika i czy jest rzeczywiście potrzebna?"