SAP Readiness Check dla konwersji do SAP S/4HANA kończy się zwykle tak samo. Zespół Basis uruchamia kolektory, wynik ląduje na SAP for Me, ktoś eksportuje dokument i wysyła go dalej z jednym zdaniem: „mamy analizę gotowości”. Na komitecie sterującym pada wtedy pytanie o termin, budżet i o to, co w trakcie programu przestanie działać. Raport nie odpowiada na żadne z tych trzech pytań, bo nie po to powstał.
To nie jest zarzut wobec narzędzia. SAP Readiness Check robi dokładnie to, co obiecuje: opisuje stan techniczny systemu źródłowego i wskazuje pozycje, którymi trzeba się zająć. Problem zaczyna się w momencie, gdy raport techniczny zaczyna pełnić funkcję oceny gotowości organizacji do programu, a te dwie rzeczy dzieli kilka miesięcy pracy i kilka decyzji, których żadne narzędzie za Was nie podejmie.
W skrócie:
1/ SAP Readiness Check for SAP S/4HANA to szesnaście analiz, a podstawą najważniejszej z nich jest zawartość tabel i wykaz używanych transakcji - narzędzie widzi więc ślad po pracy systemu, nie sposób, w jaki korzysta z niego firma,
2/ trzy rodzaje znalezisk zatrzymują konwersję, zanim ją zaczniecie, a jedno z nich SAP każe zgłosić jako incydent, bo nie da się go rozwiązać po Waszej stronie,
3/ czterech odpowiedzi w raporcie nie ma w ogóle: o uprawnieniach, o koszcie licencyjnym modelu docelowego, o realnym przestoju w Waszym krajobrazie i o jakości danych poza finansami,
4/ sam SAP w kilku miejscach odsyła do człowieka, opisując część pozycji jako wymagające oceny eksperta - i to jest najuczciwszy fragment całego dokumentu.
Co SAP Readiness Check mierzy naprawdę
Scenariusz konwersyjny obejmuje szesnaście analiz. Dla porządku warto je pogrupować, bo w dokumencie leżą jedna obok drugiej i wszystkie wyglądają na równie ważne.
Zgodność, czyli co zablokuje start: elementy uproszczenia, analiza zakresu zgodności, aktywne funkcje biznesowe, zgodność dodatków. Wysiłek, czyli ile pracy przed Wami: działania powiązane z elementami uproszczenia, analiza kodu własnego, integracja, dostępność aplikacji i rekomendowane aplikacje SAP Fiori. Dane: jakość danych finansowych, integracja klientów i dostawców z rekordem Business Partner, szacowanie wielkości systemu docelowego. Reszta: kalkulator planowanego przestoju, odkrywanie procesów biznesowych, możliwości SAP Business AI oraz rozwiązania SAP Innovative Business Solutions.
Najważniejsza jest jedna linijka z dokumentacji SAP, którą łatwo przeoczyć. Dla elementów uproszczenia kontrola opiera się przede wszystkim na zawartości tabel i używanych transakcjach. To znaczy, że narzędzie rozpoznaje moduł, który zostawił dane, i transakcję, którą ktoś uruchomił. Nie rozpozna procesu, który u Was działa na obejściu w Excelu, ani modułu, który kupiliście i wdrożyliście w jednej spółce na piętnaście. Raport pokaże Wam odcisk systemu, a nie mapę firmy.
Druga rzecz, którą warto docenić: SAP nie udaje, że liczy wszystko. Ranking pracochłonności przy elemencie uproszczenia przyjmuje wartości od niskiej do wysokiej albo wprost oznacza, że pozycja wymaga oceny eksperta. Czynniki pracochłonności są z kolei porównaniem Waszego systemu do wartości referencyjnych zebranych z wcześniejszych projektów SAP S/4HANA. To użyteczna wskazówka i kiepska podstawa budżetu, bo referencją jest cudzy program, nie Wasz.
Zanim powstanie raport
Jeżeli raportu jeszcze nie macie, droga jest krótsza, niż się wydaje, i nie wymaga zamówienia usługi. SAP Readiness Check jest dostępny w dwóch miejscach: na SAP for Me dla wszystkich klientów z aktywną umową utrzymaniową, pod adresem me.sap.com/readinesscheck, oraz w SAP Cloud ALM dla tych, którzy mają tenant tej usługi. Procedura prowadzona krok po kroku przygotowuje system i uruchamia kolektory, a po zebraniu danych zakładacie nową analizę na stronie startowej narzędzia.
Dwie rzeczy warto ustawić od razu. Po pierwsze, analizę robi się na systemie produkcyjnym - to jego dane opisują rzeczywisty zakres programu, a nie zawartość systemu jakościowego, w którym połowa modułów nigdy nie pracowała na prawdziwych wolumenach. Po drugie, wyniki różnych scenariuszy uruchomionych na tym samym systemie da się połączyć w jedną analizę, co ma znaczenie wszędzie tam, gdzie obok konwersji stoi SAP BW/4HANA albo profilowanie użycia SAP ERP.
Raport starszy niż rok warto uruchomić jeszcze raz przed startem programu. Lista analiz rośnie z każdym wydaniem narzędzia, a w międzyczasie zmienia się także Wasz system - jeżeli w tym czasie ktoś aktywował funkcję biznesową albo dołożył dodatek, poprzedni wynik opisuje krajobraz, którego już nie ma.
Trzy znaleziska, które zatrzymują konwersję, zanim się zacznie
Pierwsze to niezgodny dodatek. Dokumentacja SAP mówi wprost, że niezgodne dodatki zablokują konwersję podczas pracy Software Update Manager. Narzędzie przypisuje dodatkom kategorie: zgodny, niezgodny, niezgodny bez możliwości odinstalowania oraz nieznany. Ta ostatnia kategoria jest najciekawsza, bo raport jej nie zamyka - trafiają do niej przede wszystkim rozwiązania partnerskie, a odpowiedź, czy dostawca wyda wersję pod docelowe wydanie SAP S/4HANA, musicie uzyskać sami. Im wcześniej, tym lepiej, bo wykreślenie dodatku z krajobrazu bywa osobnym projektem.
Drugie to aktywna funkcja biznesowa niezgodna z wydaniem docelowym. Tutaj SAP jest jeszcze bardziej stanowczy: taka funkcja zablokuje konwersję systemu, a zalecana ścieżka to zgłoszenie incydentu w komponencie tej funkcji i rozmowa z SAP. Nie ma tu miejsca na obejście po stronie zespołu projektowego, więc pozycja z tej listy powinna wyjść na komitet w pierwszym tygodniu, a nie w fazie przygotowania cutoveru.
Trzecie to elementy uproszczenia oznaczone jako wymagające oceny eksperta. To nie jest kategoria awaryjna, tylko sygnał, że narzędzie zrobiło, co mogło. Zwykle chodzi o obszary, w których zmiana modelu danych spotyka się z Waszą konfiguracją: rachunkowość, gospodarka materiałowa, sprzedaż z rozbudowanym własnym kodem. Każda taka pozycja to osobna rozmowa z osobą, która zna ten obszar w Waszej firmie.
Dobra wiadomość jest taka, że wszystkie trzy da się rozstrzygnąć przed startem programu, bez uruchamiania konwersji. Zła, że średnio nikt tego nie robi, bo raport wygląda na dokument do przeczytania, a nie do przepracowania.
Cztery odpowiedzi, których w tym raporcie nie ma
Uprawnienia, podział obowiązków i konta techniczne. Lista analiz jest zamknięta i publiczna, a nie ma na niej ani jednej pozycji o rolach, uprawnieniach, kontach serwisowych czy ekspozycji systemu. Konwersja przebudowuje model autoryzacji, dokłada aplikacje SAP Fiori z własnymi katalogami i grupami, a przy okazji na kilkanaście miesięcy otwiera w programie dostępy, których w normalnym trybie nikt by nie nadał. Raport o tym nie powie ani słowa. Opisaliśmy to osobno we wpisie Bezpieczna konwersja do SAP S/4HANA, bo to materiał na własny tekst, a nie na akapit.
Koszt licencyjny modelu docelowego. Analiza zakresu zgodności mówi o pakietach zgodności, czyli o ograniczonych prawach użytkowania klasycznych rozwiązań SAP ERP na SAP S/4HANA, i pokazuje, które z nich mają następcę. Nie mówi natomiast, ile zapłacicie po konwersji ani jak zmieni się Wasz rachunek licencyjny, gdy część użytkowników przejdzie na przelicznik Full Use Equivalent. To osobna analiza, którą robi się na danych o rzeczywistym użyciu, a nie na wyniku kolektora - patrz audyt licencji SAP.
Realny przestój w Waszym krajobrazie. Kalkulator planowanego przestoju jest w raporcie, ale nosi założenie napisane wprost: podane czasy dotyczą standardowej konwersji przez Software Update Manager w obrębie jednego centrum danych. Czasy faz pochodzą z doświadczeń innych klientów i pomiarów na podobnych systemach. Jeżeli macie replikację między ośrodkami, okno serwisowe wynegocjowane z biznesem albo integracje, które nie zniosą kilkunastu godzin ciszy, ten wynik jest punktem wyjścia do planu, a nie planem. Skrócić przestój da się dwiema drogami: wariantem downtime-optimized conversion oraz archiwizacją i porządkami zrobionymi przed programem, nie w jego trakcie.
Jakość danych poza finansami. Raport sprawdza księgę główną, środki trwałe i material ledger, przypisując niespójnościom kategorie od automatycznej korekty, przez korektę ręczną i kontakt z SAP, po korektę specyficzną dla systemu. Sprawdza też synchronizację klientów, dostawców i osób kontaktowych z rekordem Business Partner, bo bez niej konwersja nie przejdzie. I na tym kończy się temat danych. Duplikaty w danych podstawowych materiałów, niespójne indeksy, trzy wersje tego samego kontrahenta w trzech spółkach - tego nikt tu nie policzy, a to właśnie ten materiał wywraca testy akceptacyjne.
Jak przeczytać ten raport w tydzień
Kolejność ma znaczenie, bo dokument jest ułożony tematycznie, a program potrzebuje ułożenia decyzyjnego.
Dzień pierwszy: blokery. Dodatki niezgodne i nieznane, aktywne funkcje biznesowe, elementy z oceną eksperta. Z tego powstaje lista pytań na zewnątrz - do dostawców rozwiązań partnerskich i do SAP. Odpowiedzi przychodzą tygodniami, więc to musi wyjść pierwsze.
Dzień drugi i trzeci: kod własny. Wynik analizy kodu ma sens dopiero wtedy, gdy wiecie, co z tego kodu jest realnie używane. Informację o zakresie, czyli podział na kod w zakresie i poza zakresem, raport pokazuje tylko wtedy, gdy uruchomiliście aplikację SAP Fiori Custom Code Migration. Bez niej dostajecie listę znalezisk bez wagi, a różnica bywa taka, że połowa obiektów nie była ruszana od lat i idzie do usunięcia zamiast do przepisania. Przy okazji warto sprawdzić, ile znalezisk ma automatyczną poprawkę, bo to realnie zmienia wycenę. Tę część łączymy zwykle z analizą podatności w kodzie własnym przez SAP Code Vulnerability Analyzer, żeby nie robić dwóch przebiegów po tym samym kodzie.
Dzień czwarty: dane. Niespójności finansowe według kategorii, stan przejścia na Business Partner, potencjał archiwizacji z zakładki wielkości systemu. Tu zapada decyzja, czy porządki robicie przed konwersją, czy godzicie się przenieść bałagan na nową platformę i zapłacić za niego pamięcią.
Dzień piąty: integracje i przestój. Inwentarz interfejsów - IDoc, RFC i BAPI, usługi sieciowe, OData, ekstraktory SAP BW, pliki, konfiguracje SLT - zestawiony z listą systemów, których właściciele siedzą poza IT. Do tego kalkulator przestoju skonfrontowany z oknem, na które zgodzi się biznes.
Dopiero z tym materiałem warto iść na komitet, bo wtedy rozmowa przestaje być o raporcie, a zaczyna być o zakresie, terminie i pieniądzach. Kolejny etap, czyli jak ułożyć sam program konwersji, opisaliśmy we wpisie jak przygotować się do konwersji systemu SAP ERP do S/4HANA, a warstwę testową - we wpisie o testach SAP przy konwersji i przed go-live.
Termin, którego nikt nie przesunie
Utrzymanie standardowe dla SAP Business Suite 7 kończy się 31 grudnia 2027 roku, a utrzymanie rozszerzone trwa do końca 2030 roku i kosztuje dodatkowe dwa punkty procentowe do podstawy utrzymania. Firma, która dzisiaj ma raport SAP Readiness Check i nie ma rozstrzygniętych blokerów, ma przed sobą kilkanaście miesięcy na decyzje, które wymagają rozmów z dostawcami dodatków i z SAP. To wystarczy pod warunkiem, że raport zostanie przepracowany teraz, a nie wtedy, gdy program dostanie już budżet i datę go-live.
Co robimy w SNOK
Analizę gotowości prowadzimy jako pracę na Waszym raporcie, nie zamiast niego. Uruchamiamy kolektory tam, gdzie ich jeszcze nie uruchomiono, przechodzimy pozycję po pozycji przez blokery, kod własny i dane, dokładamy warstwę, której w raporcie nie ma - uprawnienia, ekspozycję i koszt modelu docelowego - i wychodzimy z listą decyzji na komitet zamiast z dokumentem do przeczytania. Zakres i sposób pracy opisuje strona konwersja do SAP S/4HANA.
Jeżeli macie już wynik SAP Readiness Check i nie wiecie, co z nim zrobić, napiszcie do nas. Przejdziemy go z Waszym zespołem Basis i z osobą odpowiedzialną za budżet programu, bo to są dwie różne rozmowy i obie trzeba odbyć.
Źródła
- SAP, SAP Readiness Check - Key Feature Overview, SAP Readiness Check Team, kwiecień 2026, dokument publiczny - help.sap.com (dostęp 22 września 2026)
- SAP Note 2913617, SAP Readiness Check for SAP S/4HANA - nota centralna scenariusza, dostęp po zalogowaniu w me.sap.com
- SAP Note 3344480, SAP Readiness Check Deployment Options - dostęp po zalogowaniu w me.sap.com
- SAP, Maintenance strategy - SAP S/4HANA and SAP Business Suite 7 - support.sap.com (dostęp 22 września 2026)
Opisujemy zakres narzędzia za dokumentacją SAP z kwietnia 2026 roku. SAP rozwija SAP Readiness Check wydaniami, więc przed oparciem decyzji na tym tekście sprawdźcie aktualną listę analiz w nocie 2913617.