Migracja na system SAP S/4HANA to krok, który coraz więcej firm się podejmuje, aby dostosować organizację do wymagań nowoczesnego świata biznesu. Jednakże, zanim przystąpisz do tego procesu, istnieje kluczowy krok, który może przynieść znaczne oszczędności - zoptymalizowanie swoich licencji SAP.
Migracja do systemu SAP S/4HANA to proces, który wymaga starannego planowania i przygotowania. Przejście na nowoczesny system ERP może przynieść wiele korzyści, ale również stanowić wyzwanie dla organizacji. Przed rozpoczęciem migracji warto zwrócić uwagę na kilka istotnych kwestii, które mogą mieć kluczowe znaczenie dla sukcesu całego przedsięwzięcia a co najważniejsze przynieść wymierne oszczędności (w porównaniu do wartości licencji S/4 w przypadku nieefektywnego przygotowania się).
Klasycznym przykładem migracji jest ten, w którym rozpoczyna się mapowanie obecnych licencji użytkowników nazwanych w systemie ECC na te, które są obecne w S/4HANA.
Uważaj na te pułapki:
Każde z powyższych stanowi osobne poziom wyzwań. Odpowiednie zaadresowanie tych tematów może pozwolić na obniżkę (z naszego doświadczenia - znaczną) ilości licencji koniecznych do zakupu dla środowiska S/4. Zatem kolejno:
1/ Nowe typy licencji - Oszczędności rzędu 10-30%
Pierwszą rzeczą, która powinna zwrócić naszą uwagę jest to, że istnieją nowe typy użytkowników. Nie korespondują one bezpośrednio z tymi, które znamy ze środowisk SAP ECC. Dla uproszczenia skoncentrujemy się tylko na licencjach dla dialogowych użytkownikach nazwanych (pomijam Engine Use, Technical Use oraz Engine Use).
Nowymi typami licencji użytkowników nazwanych (dialogowi, użytkownicy biznesowi) są:
Zwracamy od razu uwagę na brak Limited Profesional, co już samo w sobie może stanowić wyzwanie braku możliwości bezpośredniego przeniesienia korespondującej licencji na nowe środowisko dla tych użytkowników, którzy SP posiadają dziś.
Dodatkowym przykładem jest to, że w SAP ECC wszyscy użytkownicy zajmujący się sprzedażą mieli konieczność przypisania drogiej licencji Professional User. W nowym środowisku, jeśli użytkownik zajmuje się częścią z aktywności sprzedażowych nie ma konieczności przypisywania mu najwyższego poziomu licencyjnego, ponieważ Functional Use już posiada te aktywności.
Oto fragment standardowej umowy z SAP:
S/HANA Enterprise Management for Functional Use
- Sales (Sales Quotation Management, Sales Contract Management, Sales Order Management, Incentive and Commisions Management, Sales lead Management, Activity Management, account and Contact Management, Sales Master Data Management, Sales Billing, Solution Billing, Sales Rebates Management, Claims, Returns and Refounds Management, Sales Monitoring and Analytics)
Następny przykład – licencja Worker User. Tu również nie ma możliwości bezpośredniego przełożenia licencji ze starego typu na nowy. W zależności od aktywności danego użytkownika Worker - może on być przypisany w S/4 do Productivity bądź Functional Use.
Oto fragment standardowej umowy z SAP:
S/HANA Enterprise Management for Functional Use
- Suply Chain (Goods Movement, Inventory Analytics, Returnable Packing Logistics, Warehouse Management, Delivery Management, Transportation Management, Available to Promise Physical Inventory, Handle Unit Management, Serial Number Management)
- Manufactoring (Material Requirements Planning, External Processing, Production Execution, Subcontracting, Just-in-time Processing, Kanban, Production Control, Repetitive Manufacturing, Quality Planning, Quality Improvement, Quality Inspection, Production BOM Management, Recipe/Routing Management, Manufacturing Analytics)
- Asset Management (Maintenence Planning and Scheduling, Maintenence Execution)
S/HANA Enterprise Management for Productivity Use
- Supply Chain (Goods Movement, Warehouse Management, Delivery Management, Available to Promisse, Transportation Management, Physical Inventory, Handling Unit Management, Batch Management, Serial Number Management)
- Asset Management (Maintenence Execution)
- Manufacturing (Material Requrement Planning, Production Execution, Production Control)
Rozwiązanie:
Zweryfikuj, jak zachowują się Twoi użytkownicy. Dla środowiska ECC konieczna jest walidacja tego jakie transakcje w rzeczywistości wykorzystują użytkownicy. Jeśli znasz odpowiedź na to pytanie (a ono znajduje się na przykład w ST03) możesz przystąpić do kroku drugiego – kontekstowe potwierdzenie konkretnego typu licencji.
Rule-set transakcji dla użytkownika Professional
Można zautomatyzować ten proces weryfikacji. Dzieje się to z wykorzystaniem dostarczanych rule-setów, zawierające mapowane transakcje (standardowe) dla konkretnych grup licencyjnych. Oczywiście potrzebujemy również warstwy transakcji customowych (Z*), i ich analiza jest konieczna, żeby uzupełnić rule-set o ten kontekst również. Po uzupełnieniu - mamy gotową odpowiedź na to kto i jaką licencję potrzebuje w ECC. Stąd krok bliżej do mapowania potrzebnych licencji S/4.
2/ Czy użytkownik rzeczywiście potrzebuje dostępu do SAP? - Oszczędności rzędu 3-10%
Czy jesteś pewien, że wszyscy Twoi użytkownicy potrzebują dostępu do SAP? Czy dobrze zarządziłeś odpowiednią blokadą użytkowników, którzy już nie wykonują żadnych aktywności (bo na przykład nie pracują już w firmie)?
Przykładowe błędy, dla których niepracujący użytkownik nadal będzie liczony jako aktywny:
Podczas inicjalnych faz projektu optymalizacji licencji przypatrujemy się właśnie takim przypadkom. Analizowana jest na przykład data utworzenia usera oraz data ostatniego zalogowania do systemu (uprzedzam, że jest to przykład, dla każdego z wymienionych poniżej elementów wymagana jest dodatkowa analiza, potwierdzająca na przykład fakt, że użytkownik nie robi innego ruchu na CPU, z wykorzystaniem na przykład jobów w tle).
Poniżej znajduje się wycinek z przykładowego audytu wstępnego. Data analizy to luty 2024. Zwróć uwagę na obie kolumny. W niektórych przypadkach mamy do czynienia nawet z tym, że użytkownik nie zalogował się przez 4 lata do systemu. A nadal posiada ważnego usera z przypisaną (oczywiście błędnie, bo niepotrzebnie) licencją.
User | Creation_Date | Last_Logon |
---|---|---|
abc | 2022-01-14 | 2022-08-02 |
def | 2020-02-06 | 2020-02-06 |
ghi | 2020-04-10 | 2022-12-18 |
jkl | 2021-04-26 | 2021-05-11 |
mno | 2023-02-16 | 2023-03-17 |
prs | 2020-03-12 | 2022-02-28 |
tuw | 2022-06-24 | 2023-05-29 |
xyz | 2022-07-06 | 2022-07-07 |
Dodatkowo powinno się przyjrzeć tym, którzy nie logowali się do SAP przez kilka miesięcy. Czy oni potrzebują użytkownika? Może już nie pracują? Albo to zewnętrzni konsultanci, których już nie ma na projektach?
Rozwiązanie:
Regularna analiza użytkowników nieaktywnych. Pozwoli to na update, który może skutkować zwolnieniem nieużywanej licencji przez usera. Albo w przypadku przejścia z ECC do S/4 - ocenę kontekstową tego w jaki sposób i którzy użytkownicy rzeczywiście potrzebują licencji na nowym środowisku.
3/ Czy użytkownik ma dziś odpowiednią licencję?
Oszczędności rzędu 5-15%
Z naszych doświadczeń wynika, że w każdym systemie, który nie jest wspierany zautomatyzowaną identyfikacją poprawności przypisanej licencji – znajduje się pula użytkowników, która w sposób znaczący ma przypisane licencje odbiegające od optymalnych.
Jeśli na ECC użytkownik ma drogą i zbyteczną (dla niego) licencję Profesional, to korespondująca licencja w środowisku S/4 (Profesional Use) również będzie z dużym prawdopodobieństwem nieodpowiednia (czyli za droga, i niepotrzebna).
Odpowiednie przypisanie licencji dziś zatem może nie tyle zaoszczędzić pieniądze dla obecnego środowiska, ale znacząco wpłynąć na niższą wartość docelowych licencji dla S/4. Tym bardziej, że w przypadku modelu FUE - opłaty ponoszone są comiesięcznie.
Warto zwrócić uwagę na rozłożenie wag FUE:
1 FUE = 0.5 SAP S/4HANA Cloud developer access
1 FUE = 1 SAP S/4HANA Cloud for advanced use
1 FUE = 5 SAP S/4HANA Cloud for core use
1 FUE = 30 SAP S/4HANA Cloud for self-service use
Rozwiązanie:
Na systemie ECC koniecznie wykonaj analizę, która pozwoli odpowiedzieć na pytanie, czy dany typ licencji nie może zostać zastąpiony (dla konkretnego użytkownika) inną, bardziej optymalną, licencją. Pozwoli to na weryfikację czy oszczędność możesz rozpocząć zanim przejdziesz na nowe środowisko.
4/ Konsolidacja użytkowników - czy użytkownicy są liczeni podwójnie?
Oszczędności rzędu 5% (dla 2+ systemów produkcyjnych)
W przypadku środowisk zawierających więcej niż jedno środowisko produkcyjne konieczna jest realizacja konsolidacji. Jeśli Twoi pracownicy posiadają użytkowników na większej ilości systemów, wówczas (zgodnie z zapisami umownymi) licencja powinna być naliczana tylko raz. Bierze się pod uwagę wtedy tylko tą o najwyższej wartości.
Przykład w poniższej tabeli obrazuje to w jaki sposób jest liczona licencja dla każdego z userów w wielosystemowym środowisku.
User | System 1 | System 2 | Poprawne zliczanie po konsolidacji |
---|---|---|---|
ABC | Professional User | Worker User | 1x Professional User |
XYZ | Professional User | Professional User | 1x Professional User |
QWE | Limited Professional User | Professional User | 1x Professional USer |
Błędy, które wynikają z niepoprawnej konsolidacji (albo mówiąc wprost - wynikają z jej braku), to dla powyższego przykładu następujący scenariusz:
User | System 1 | System 2 | Niepoprawne zliczanie BEZ konsolidacji |
---|---|---|---|
ABC | Professional User | Worker User | 1x Professional User + 1x Worker User |
XYZ | Professional User | Professional User | 2x Professional User |
QWE | Limited Professional User | Professional User | 1x Professional User + 1x Limited Professional User |
Rozwiązanie:
Konieczność mapowania pracowników względem posiadanych użytkowników na wielu systemach. Tylko wtedy jesteś w stanie zagwarantować, że nie płacisz za licencje tam, gdzie nie jest to potrzebne.
W przypadku migracji do S/4 oprócz oczywistych tematów wynikających z przygotowania funkcjonalnej roadmapy dla nowego środowiska - potrzebne jest rzetelna analiza licencji użytkowników nazwanych, by nie generować niepotrzebnych kosztów.
Realizacja wyceny bez analizy kontekstowej przypisanych typów licencji może drastycznie wpłynąć na ostateczną ilość kupionych FUE.
Poniżej przykładowa wycena dla środowiska dla 1000 użytkowników przed i po optymalizacji licencji.
Licencja | Liczba licencji bez optymalizacji | bez optymalizacji Liczba licencji po optymalizacji | Waga | FUE bez optymalizacji | FUE po optymalizacji |
Developer Access | 10 | 10 | 0,5 | 20 | 20 |
Advanced Use | 355 | 154 | 1 | 355 | 154 |
Core Use | 545 | 345 | 5 | 109 | 69 |
Self Service | 90 | 491 | 30 | 3 | 17 |
Suma | 1000 | 1000 | 487 | 260 |
Z powyższego widać, że po optymalizacji jesteśmy w stanie zaoszczędzić 227 FUE, zachowując liczbę użytkowników, a licencje bezpośrednio będą zgodne z umową subskrypcyjną.
Licencje SAP stanowią znaczący element kosztów związanych z korzystaniem z systemu ERP tej firmy. Przed przeprowadzeniem migracji na S/4HANA warto dokładnie przeanalizować swoje obecne licencje, aby upewnić się, że są one zoptymalizowane pod kątem rzeczywistego wykorzystania systemu.
Już 20 marca o godzinie 12:30 nasz ekspert Tomasz Jurgielewicz opowie więcj o tym jak podejść do analizy i optymalizacji licencji SAP przed migracja na S4/HANA. Zarejestruj się już teraz!