Z tego artykułu dowiesz się:

·       dlaczego SAP odchodzi od modelu FUE i wprowadza PUPM,

·       jakie są nowe typy użytkowników i czym się od siebie różnią,

·       jak działa zasada „najwyższy typ wygrywa” i dlaczego potrafi mocno podnieść koszty,

·       jakie ryzyka wiążą się z przypisywaniem ról i katalogów biznesowych,

·       dlaczego macierze mappingu są trudne w praktyce i jak je czytać,

·       co oznacza okres przejściowy i kiedy faktycznie będzie można migrować,

·       jakie narzędzia i działania pomagają kontrolować koszty licencji w nowym modelu.

 

Nowy model licencjonowania – potrzeba

Przez ostatnie lata w SAP Cloud ERP obowiązywał model FUE (Full Use Equivalent). Klienci musieli przeliczać użytkowników na ‘ekwiwalenty kont’ i dopiero w ten sposób kalkulować koszty.

Problemem nie była jednak tylko matematyka, ale przede wszystkim określenie, do jakiej kategorii przypisać każdego użytkownika. Firma, która dopiero wdrażała SAP i nie znała jeszcze dobrze modelu licencjonowania, często wychodziła od prostego założenia: „mamy 100 osób, które chcą pracować w systemie”. Zamiast nadać im uprawnienia i obserwować faktyczne wykorzystanie, musiała od razu na etapie planowania zdecydować, co każda z tych osób będzie robić i jaki typ użytkownika jej przypisać. To było trudne i obarczone dużym ryzykiem błędu.

Ta firma w efekcie kalkulacji określała, że będzie posiadała 50 użytkowników samoobsługowych, 20 użytkowników operacyjnych, 10 użytkowników finansowych oraz 5 użytkowników deweloperskich. W modelu FUE każdy typ użytkownika miał przypisany przelicznik – ‘Self-Service’ liczono jako 0,1 FUE, ‘Operational’ jako 0,5 FUE, ‘Finance’ jako 1 FUE, a ‘Developer’ jako 1,5 FUE. Aby policzyć całkowity koszt, należało wykonać obliczenia matematyczne: 50 x 0,1 plus 20 x 0,5 plus, etc… co w efekcie dawało 45 FUE. Dopiero ta suma stanowiła podstawę do dalszego przeliczenia kosztów licencji.

Przykładowo pracownik działu zakupów, który głównie wystawiał zamówienia, mógł być uznany za użytkownika operacyjnego, ale jeśli dodatkowo zatwierdzał faktury, należało go klasyfikować jako finansowego. Podobnie kierownik sprzedaży – na pierwszy rzut oka operacyjny, ale jeśli miał dostęp do raportów controllingowych, podbijał koszty do wyższej kategorii.

W rezultacie firmy, które nie miały doświadczenia z FUE, często przeszacowywały liczbę droższych typów użytkowników. Model, zamiast ułatwiać start, powodował konieczność prowadzenia szczegółowych warsztatów, tworzenia map ról i angażowania konsultantów, aby uniknąć przepłacania.

 

FUE zostało zastąpione PUPM – nowe podejście

W modelu PUPM (Per User Per Month) SAP zlikwidował przeliczniki, które były najbardziej uciążliwe w FUE. Na pierwszy rzut oka wydaje się więc, że problem został rozwiązany – klient kupuje jasno nazwane licencje, takie jak Self-Service, Operational czy Finance Base, i płaci miesięczną stawkę za użytkownika.

W praktyce jednak wyzwanie nie zniknęło całkowicie, a jedynie zmieniło formę. Teraz to nie przeliczniki, ale przypisane katalogi biznesowe (Business Catalogs) decydują o tym, jaki typ użytkownika otrzyma dana osoba. Każdy katalog ma przypisaną kategorię licencji, a użytkownik dziedziczy najwyższy typ spośród katalogów, które otrzymał w ramach swojej roli.

Na przykład jeśli pracownik ma dostęp zarówno do katalogu Self-Service, jak i do katalogu Operational, to zostanie zaklasyfikowany jako użytkownik operacyjny. Jeśli dodatkowo dostanie dostęp do katalogu Finance Base, jego typ wzrośnie do Finance Base, nawet jeśli z tych funkcji korzysta sporadycznie lub wcale.

Dla wielu firm oznacza to powrót znajomego problemu: „mamy 100 osób, które chcą pracować w systemie”, ale zanim nadadzą im role, muszą zrozumieć, które katalogi podniosą typ użytkownika i koszt licencji. Choć kalkulacja jest dziś prostsza niż w FUE, sama klasyfikacja ról nadal bywa skomplikowana i obarczona ryzykiem błędów. Jeden dodatkowy katalog może podnieść koszty dla całej grupy pracowników, a nieświadome przypisanie zbyt szerokich ról kończy się przepłacaniem.

Dlatego w modelu PUPM, podobnie jak w FUE, kluczowe staje się prowadzenie warsztatów i regularne analizy uprawnień. Firmy, które ograniczą się do „prostego przypisania ról”, mogą szybko odkryć, że płacą za Premium, podczas gdy użytkownicy w praktyce korzystają wyłącznie z funkcji Self-Service czy Operational.

Nowe typy użytkowników (SKU)

W modelu PUPM SAP wprowadził jasno zdefiniowane kategorie użytkowników. Dzięki temu klient nie przelicza już abstrakcyjnych FUE, ale wybiera spośród konkretnych pakietów. Każdy pakiet odpowiada innemu zakresowi funkcjonalności, a ceny różnią się w zależności od poziomu.

Finance Base i Finance Premium

• Finance Base to podstawowy pakiet dla osób pracujących w finansach – księgowych, specjalistów ds. zobowiązań i należności, osób odpowiedzialnych za raportowanie. Zawiera m.in. GL, AP, AR, podstawowe procesy controllingowe.
• Finance Premium to rozszerzona wersja, obejmująca dodatkowe aplikacje i integracje, np. Ariba, Concur, Project Management, Sustainability, a także wsparcie zaawansowanych scenariuszy controllingowych. Premium zawiera także wszystkie funkcje Finance Base (nested model).

SCM Base i SCM Premium

• SCM Base to pakiet dla planistów i operatorów logistyki – obsługa łańcucha dostaw, planowanie produkcji, gospodarka magazynowa, zakupy operacyjne.
• SCM Premium to pełny pakiet dla bardziej zaawansowanych ról, np. inżynierów produkcji, planistów strategicznych, managerów jakości. Zawiera wszystkie funkcje SCM Base oraz dodatkowe moduły wspierające bardziej złożone procesy.

Combo Base (Finance + SCM)

• Combo Base łączy w jednym pakiecie elementy Finance Base i SCM Base. Jest to rozwiązanie dla organizacji, które mają użytkowników korzystających zarówno z procesów finansowych, jak i logistycznych, a nie chcą kupować dwóch oddzielnych licencji.

Operational

• Operational User to licencja dla użytkowników zajmujących się podstawową obsługą transakcji, np. pracowników działów zakupów, sprzedaży czy obsługi klienta. Taki użytkownik wystawia zamówienia, oferty sprzedaży, potwierdzenia dostaw, ale nie ma pełnego dostępu do obszaru finansów czy planowania.

Self-Service

• Self-Service User to najprostszy i najtańszy pakiet. Przeznaczony dla pracowników, którzy korzystają tylko z funkcji samoobsługowych – np. zgłaszanie urlopów, wprowadzanie timesheetów, przeglądanie własnych danych kadrowych czy podstawowych raportów.

Developer

• Developer User to specjalny typ licencji dla programistów pracujących w środowisku SAP. Może obejmować dostęp do ABAP Workbench, a także do narzędzi z rodziny SAP Build (np. Build Apps, Build Process Automation).

Typy użytkowników – przykład zastosowania

Wyobraźmy sobie firmę produkcyjną zatrudniającą 100 osób. Sześćdziesięciu pracowników to operatorzy, którym wystarczy Self-Service, bo potrzebują jedynie zgłaszać urlopy i wprowadzać czas pracy. Dwadzieścia pięć osób zajmuje się obsługą sprzedaży i zakupów – dla nich odpowiedni wydaje się pakiet Operational. Dziesięciu pracowników w księgowości wymaga licencji Finance Base, a trzy osoby, które zajmują się zaawansowanym controllingiem oraz integracją z Ariba i Concur, muszą mieć Finance Premium. Do tego dochodzi dwóch programistów korzystających z ABAP i SAP Build – oni potrzebują licencji Developer.

Na pierwszy rzut oka wszystko wygląda klarownie – każdy dostaje to, czego potrzebuje. Ale teraz załóżmy, że pięćdziesięciu pracowników musi mieć dostęp do Concur, aby rozliczać koszty podróży służbowych. W teorii Concur jest częścią pakietu Finance Premium, więc można zadać pytanie: czy oznacza to, że dla tych pięćdziesięciu osób trzeba kupić droższe licencje Premium, mimo że poza wprowadzeniem delegacji korzystają jedynie z prostych funkcji Self-Service?

To pokazuje, że nowy model wcale nie jest tak prosty, jak mogłoby się wydawać na prezentacjach. W praktyce pojawiają się wątpliwości:

• czy każdy, kto rozlicza delegacje w Concur, automatycznie musi mieć Premium,
• czy SAP przewiduje wyjątki i specjalne scenariusze dla takich przypadków,
• czy można stosować „mix” – część pracowników na Self-Service, część na Premium, nawet jeśli wykonują podobne czynności,
• jak zmapować role, aby nie przepłacać za użytkowników, którzy tylko incydentalnie korzystają z droższych aplikacji.

W efekcie, choć PUPM upraszcza cennik i eliminuje skomplikowane przeliczniki FUE, to w codziennym życiu firmy nadal muszą bardzo ostrożnie analizować przypisania ról i dostępów. Jeden dodatkowy katalog, taki jak Concur, może zamienić taniego użytkownika Self-Service w drogiego użytkownika Premium i radykalnie zmienić strukturę kosztów.

Przykład liczbowy

Jeśli tych 50 użytkowników zostanie zakwalifikowanych jako Self-Service, koszt (hipotetyczny przykład przy uproszczonej stawce):50 × 5 EUR miesięcznie = 250 EUR miesięcznie. Ale jeśli zostaną uznani za użytkowników Finance Premium, koszt nagle rośnie do: 50 × 60 EUR miesięcznie = 3 000 EUR miesięcznie.

Różnica wynosi 2 750 EUR miesięcznie, czyli ponad 33 000 EUR rocznie, tylko dlatego, że dostęp do jednej aplikacji (Concur) podniósł kategorię licencji.

Co to pokazuje?

Ten przykład pokazuje, że choć PUPM wydaje się prostszy niż FUE, w praktyce nadal jest pełen obszarów wątpliwych. Klient musi rozstrzygnąć, czy rozliczanie delegacji kwalifikuje użytkownika do Premium, czy SAP dopuści wyjątki, czy też konieczne będzie drogie licencjonowanie dla wszystkich, którzy dotkną aplikacji Concur. To właśnie te szare strefy sprawiają, że model PUPM, mimo uproszczonej komunikacji, nadal wymaga szczegółowej analizy ról, katalogów i scenariuszy użytkowników, aby uniknąć przepłacania.

Minimalna liczba użytkowników

SAP wprowadza też wymóg minimalnej ilości użytkowników: to jest 25 użytkowników Finance Base lub Premium, min. 1 Finance Base przy zakupie innego Base SKU, Premium znosi ograniczenia Base.

Przykład: Firma chce wystartować tylko z modułem zakupowym. Musi kupić przynajmniej 1 Finance Base i 25 Base/Premium, nawet jeśli realnie korzysta mniej osób, co generuje dodatkowe (z gwiazdką postanowienie)  koszty licencji.

Wbudowane uprawnienia komercyjne

Dużą nowością jest to, że w PUPM część rozwiązań, które wcześniej trzeba było dokupować, jest już w cenie:

• w Base: Multi-Bank Connectivity, Market Rates, Digital Access, Build Base,
• w Premium: Ariba, Concur, Sales Cloud, Project Management, Sustainability.

To uproszczenie, ale też ryzyko – klient musi uważać, żeby nie przepłacać za funkcje, których faktycznie nie używa.

Jak SAP przypisuje typ użytkownika?

System działa w oparciu o Business Catalogs.

Każdy katalog ma przypisany typ użytkownika. Rola = zestaw katalogów. System przypisuje najwyższy typ spośród katalogów. Pomiar odbywa się automatycznie w SAP IAM.

Przykład

·      Warehouse Operator → Self-Service,

·      Production Operator → SCM Base,

·      Accounts Payable Accountant → Finance Base,

·      Compliance Officer → SCM Premium

 

Efekt: mimo że wielu użytkowników korzysta z prostych funkcji, obecność kilku ról „premium” podbija całkowity koszt.

Dlaczego to nadal skomplikowane?

Na poziomie slajdów wygląda to bardzo przejrzyście – kilka typów użytkowników, prosta zasada „najwyższy typ wygrywa” i automatyczny pomiar w SAP IAM. Jednak w praktyce klienci otrzymują obszerne macierze mappingu, które wyglądają jak wielkie arkusze Excela, pełne dziesiątek lub setek wierszy i kolumn. W każdej kolumnie znajdują się role biznesowe, w każdym wierszu konkretne zadania lub obiekty systemowe, a na przecięciu widać małe oznaczenia – najczęściej „x” – wskazujące, że dana rola wymaga dostępu do danego katalogu.

Z punktu widzenia licencji kluczowa jest zasada „najwyższy typ wygrywa”. Może się zdarzyć, że 90% uprawnień użytkownika mieści się w ramach niższego typu, na przykład Operational albo Finance Base, a tylko jedna aplikacja wymusza podniesienie typu do Premium. Użytkownik często nie zdaje sobie sprawy, że ten dodatkowy katalog powoduje kilkukrotnie wyższy koszt jego licencji. Gdyby wiedział, że to właśnie on podnosi kategorię, mógłby z niego świadomie zrezygnować.

Dlatego interesem klienta jest to, aby definiował dostęp świadomie – upewniając się, że rzeczywiście istnieje biznesowa potrzeba na wyższy typ licencji. Jeszcze ważniejsze jest jednak monitorowanie faktycznego użycia. W praktyce często wygląda to tak, że na etapie startu projektu użytkownicy biznesowi walczą o jak najszersze uprawnienia („bo mogą się przydać”), a argumenty bywają podszyte kwestiami ego i pozycji w organizacji. W efekcie pracownik otrzymuje dostęp klasy Premium, korzysta z niego przez tydzień albo wcale, a firma przez kolejne miesiące ponosi koszty tej decyzji.

Dlatego dobrze, jeśli w organizacji istnieje narzędzie i osoba odpowiedzialna za monitorowanie użycia. Takie połączenie pozwala nie tyle ograniczać licencje, co optymalizować je pod realne potrzeby. Chodzi nie o to, aby „nie płacić” za SAP, tylko aby płacić dokładnie za to, co jest rzeczywiście używane, a nie za coś, co zostało wywalczone przy starcie systemu i potem okazało się zbędne.

Przykład:
Accounts Payable Accountant pracuje głównie w ramach Finance Base, ale dostaje dodatkowo jeden katalog związany z Concur, żeby móc w wyjątkowych sytuacjach rozliczyć delegację. System klasyfikuje go od razu jako Finance Premium, co dla firmy oznacza kilkukrotnie wyższy koszt miesięczny. Użytkownik mógłby obejść się bez tej funkcji, ale nie wie, że to właśnie ona wpływa na jego kategorię licencji.

Dlatego jeden niewielki „x” w tabeli może podnieść koszt licencji nie tylko dla jednej osoby, ale też dla całej grupy, jeśli dana rola została zdefiniowana szeroko i przypisana większej liczbie pracowników. To pokazuje, że choć PUPM uprościł cennik, to w zarządzaniu uprawnieniami nadal wymaga szczegółowych analiz i świadomego projektowania ról – inaczej łatwo przepłacić.

Ważne ograniczenie – elastyczność licencji tylko w jedną stronę

Warto dodać, że poprawne zdefiniowanie modelu PUPM to nie tylko kwestia licencji użytkowników, ale również całego ofertowania środowiska. W zależności od wyboru wersji Base czy Premium klient może otrzymać dodatkowe produkty i funkcjonalności. Jednak kluczowym ograniczeniem jest to, że PUPM nie daje elastyczności w obie strony.

Dodawanie licencji w trakcie kontraktu jest możliwe – klient w każdej chwili może zwiększyć liczbę użytkowników. Natomiast zmniejszenie liczby licencji nie jest możliwe na bieżąco. Taką korektę można przeprowadzić dopiero przy odnowieniu kontraktu, w zależności od tego, na jaki okres został on podpisany (najczęściej 3–5 lat). W trakcie trwania umowy SAP nie autoryzuje zmniejszenia wolumenu.

Oznacza to, że firma, która przeszacuje swoje potrzeby i kupi zbyt wiele licencji Premium „na wszelki wypadek”, będzie musiała ponosić ten koszt aż do końca obowiązywania kontraktu. Dlatego świadomość klientów i partnerów sprzedających SAP Cloud ERP jest absolutnie kluczowa – od tego zależy, czy organizacja będzie korzystać z zasobów efektywnie, czy też przez kilka lat będzie przepalać znaczne budżety na nieużywane dostępy. Skuteczną metodą ograniczenia tego ryzyka jest monitorowanie faktycznego użycia systemu i przypisanych licencji.

Zamiast od razu kupować nowe licencje, warto zastanowić się, czy aktualne wykorzystanie jest na tyle intensywne, że uzasadnia ich dodanie. Bardzo często analiza pokazuje, że część użytkowników nie korzysta w pełni ze swoich dostępów. W takiej sytuacji zamiast zwiększać liczbę licencji, można przesunąć je w ramach istniejącej puli – odebrać niewykorzystywane dostępy i przydzielić je nowym pracownikom.

Takie podejście wymaga systematycznego monitoringu, ale pozwala firmie uniknąć przepłacania i zachować większą elastyczność w granicach już posiadanych licencji.

Podsumowanie

W nowym modelu PUPM kluczowym ryzykiem jest to, że opłaty naliczane są na podstawie przypisanych uprawnień, a nie rzeczywistego użycia. Oznacza to, że firma może płacić za dostęp, z którego użytkownik w praktyce nie korzysta. Bez regularnej optymalizacji ról i analizowania faktycznego wykorzystania aplikacji łatwo dochodzi do sytuacji, w której koszty licencyjne rosną ponad potrzebę. Dlatego wciąż niezbędne są narzędzia takie jak SAP GRC, SAP IAG, czy SmartGRC, które pozwalają sprawdzić, kto posiada jakie uprawnienia, kto faktycznie korzysta z systemu i gdzie istnieje potencjał do obniżenia kosztów.

Na razie model FUE i PUPM będą funkcjonować równolegle do pierwszej połowy 2026 roku, a klienci nie są zmuszeni do natychmiastowej migracji. Co więcej, techniczne możliwości przejścia na PUPM pojawią się dopiero po tym terminie.

Podsumowując, zmiana w kierunku PUPM to rewolucja w komunikacji, ponieważ cennik jest czytelniejszy i łatwiejszy do zrozumienia, ale w praktyce to wciąż ewolucja, wymagająca od klientów świadomego podejścia do macierzy ról i stałej optymalizacji. Najlepszym rozwiązaniem jest potraktowanie okresu przejściowego do 2026 roku jako czasu na testy, warsztaty i przygotowanie organizacji do nowego modelu, tak aby po migracji płacić za to, co rzeczywiście jest używane