Clean Core: po co wynosić rozszerzenia poza rdzeń SAP
Opublikowano: 1 września 2026
W większości firm, które używają SAP od dziesięciu lat lub dłużej, istnieje kilkaset obiektów Z. Część z nich powstała, bo standard czegoś nie obsługiwał. Część, bo w 2013 roku szybciej było napisać własny raport niż wynegocjować zmianę procesu. Przy przejściu na S/4HANA ta różnica przestaje mieć znaczenie, bo koszt utrzymania ponosisz jednakowo za jedno i drugie.
Na czym polega clean core
Clean core to zasada, zgodnie z którą rdzeń systemu ERP zostaje w standardzie, a wszystko, co specyficzne dla firmy, budowane jest obok, na oficjalnie udostępnionych interfejsach. SAP opisuje to jako sposób na utrzymanie systemu stabilnego i gotowego na aktualizacje przy zachowaniu możliwości różnicowania się tam, gdzie to realnie ma wartość.
Cel jest prozaiczny. Modyfikacja standardu oznacza, że każdy upgrade wymaga przeglądu, testów i często poprawek. Rozszerzenie zbudowane na udostępnionym API przechodzi upgrade bez ingerencji, bo producent utrzymuje stabilność tego interfejsu.
W praktyce SAP porządkuje rozszerzenia w dwa modele:
- On-stack, czyli rozwój wewnątrz S/4HANA przy użyciu ABAP Cloud, ograniczony do publicznie udostępnionych API. Nadaje się do logiki ściśle związanej z procesem w ERP.
- Side-by-side, czyli aplikacje uruchamiane na SAP BTP, komunikujące się z rdzeniem przez API i zdarzenia. Tu trafiają rozwiązania luźno powiązane z ERP, integracje, aplikacje dla użytkowników spoza SAP.
Do tego dochodzi warstwa konfiguracji dla kluczowych użytkowników, która w wielu przypadkach załatwia sprawę bez pisania kodu i bywa pomijana, bo brzmi zbyt prosto.
Poziomy czystości, czyli jak SAP ocenia istniejący kod
Sama deklaracja nie wystarczy, więc SAP wprowadził skalę. W przewodniku po rozszerzalności ABAP poziom A oznacza rozszerzenia zbudowane w ABAP Cloud lub na BTP wyłącznie na udostępnionych interfejsach. Poziomy B i C obejmują klasyczny ABAP, przy czym C wymaga sprawdzenia przed każdym upgrade'em i jest uznawany za czysty tylko warunkowo. Poziom D to modyfikacje i użycie obiektów wewnętrznych SAP, czyli dokładnie to, co przy aktualizacji potrafi zatrzymać projekt.
Ta skala jest przydatna nie dlatego, że narzuca cel, tylko dlatego, że pozwala policzyć, ile faktycznie masz do zrobienia. Wynik inwentaryzacji zwykle zaskakuje w obie strony: część kodu okazuje się nieużywana od lat i można ją po prostu skasować, a część rzeczy uznawanych za drobne modyfikacje siedzi głęboko w poziomie D.
Gdzie to boli
Największym kosztem clean core nie jest przepisanie kodu, tylko rozmowa o procesie. Wynoszenie rozszerzeń na BTP wymaga odpowiedzi na pytanie, czy dana funkcja jest naprawdę przewagą konkurencyjną, czy tylko przyzwyczajeniem, które przeżyło trzech dyrektorów operacyjnych. Odpowiedź „zawsze tak robiliśmy” nie pomaga przy szacowaniu budżetu, ale pojawia się regularnie.
Drugi problem jest kompetencyjny. Zespół, który przez lata pisał klasyczny ABAP, nie przesiada się na CAP, RAP i narzędzia chmurowe w kwartał. Można ten koszt zignorować w planie i zapłacić go później w opóźnieniach.
Trzeci to koszt platformy. Side-by-side oznacza subskrypcję BTP i utrzymanie środowiska, którego wcześniej nie było. W rachunku całkowitym zwykle wychodzi to korzystnie w porównaniu z utrzymywaniem własnych integracji, o czym pisaliśmy w zestawieniu iPaaS z rozwiązaniami budowanymi na zamówienie, ale to jest nowa pozycja w budżecie i lepiej pokazać ją zarządowi od razu.
Jak wygląda porządkowanie rdzenia SAP w realnym projekcie?
Na konferencji rozmawiamy z zespołami, które przeszły przez migrację i przez decyzje o tym, co przepisać, a co skasować. To rozmowa o kolejności prac i o tym, gdzie projekty zwykle się zatrzymują.
Zarejestruj się za darmo ↗Clean core a integracja
Osobna, często pomijana część zasady dotyczy integracji. Czysty rdzeń to także rdzeń, do którego nikt nie wchodzi bocznymi drzwiami: bez bezpośrednich zapytań do tabel, bez punktowych połączeń pisanych przy okazji jednego projektu. Jeśli utrzymujesz kilkadziesiąt takich połączeń, sprzątanie kodu bez uporządkowania interfejsów da połowiczny efekt.
Dla firm, które i tak stoją przed migracją z SAP PI/PO do Integration Suite, jest to argument za połączeniem obu wątków w jeden program. Inwentaryzacja interfejsów i inwentaryzacja kodu Z korzystają z tej samej wiedzy o systemie, a rozłożone na dwa osobne projekty wymagają jej dwa razy.
Warto też uczciwie powiedzieć, że nie każda organizacja musi dojść do poziomu A wszędzie. Ilu interfejsów i ilu obiektów Z faktycznie się używa, tego zwykle nikt nie wie na starcie, a bez tej liczby każdy plan jest zgadywaniem. To samo pytanie o realny koszt utrzymania tego, co zostało, stawiamy w tekście o systemach legacy.
FAQ
Czy clean core wymaga przepisania całego kodu Z?
Nie. Część obiektów okazuje się nieużywana i podlega usunięciu, część spełnia już wymogi po drobnych zmianach, a tylko wybrane wymagają przebudowy. Kolejność ustala się po inwentaryzacji narzędziami SAP do analizy własnego kodu, nie przed nią.
Czy clean core dotyczy tylko S/4HANA Cloud?
Nie, zasada odnosi się także do wdrożeń on-premise i private cloud, choć tam SAP dopuszcza szerszy zakres klasycznych rozszerzeń. Różnica polega na tym, że w wersji publicznej ograniczenia są wymuszone technicznie, a w pozostałych są kwestią dyscypliny projektowej.
Co się stanie, jeśli firma zignoruje clean core?
System będzie działał, ale każda aktualizacja stanie się osobnym projektem z testami regresji i poprawkami. Koszt nie pojawia się jednorazowo, tylko narasta przy kolejnych upgrade'ach, a przy okazji ogranicza tempo wdrażania nowych funkcji, w tym rozwiązań AI opartych na standardowych obiektach.