Konwersja do S/4: uporządkuj pojęcia

W większości przedsiębiorstw rozwój systemów IT wygląda podobnie. Oto typowy cykl: kilka lat temu firma wdrożyła system SAP ERP wraz z dewelopmentem dedykowanych raportów, interfejsów, procesów workflow. Wśród kilkudziesięciu dodatkowych programów jest m.in. specyficzny raport sprzedaży. Po pewnym czasie powstała nowa wersja tego raportu, z innym układem kolumn. Później przygotowano zmodyfikowaną wersję dla zarządu, z podsumowaniem kwartalnym. Po roku zmieniła się struktura regionów w firmie i… raport ponownie wymagał dostosowania. W efekcie standardowych działań biznesowych po dwóch latach od uruchomienia pierwotnego raportu funkcjonuje już sześć jego wersji.

Zespół odpowiedzialny za utrzymanie SAP w organizacji powinien dokonywać przeglądu programów, transakcji i interfejsów. Powinien usuwać nieużywane obiekty, a następnie aktualizować dokumentację. System powinien być przejrzysty i łatwy w utrzymaniu. Tak się dzieje w… idealnym świecie. W praktyce sytuacja zwykle wygląda inaczej: złożoność systemów stale rośnie, a to z kolei utrudnia bieżące wsparcie użytkowników.

Problemy przedstawione powyżej na przykładzie pojedynczego systemu klienta, dotyczą też – w znacznie większej skali – rozwoju i utrzymania całego standardowego systemu ERP przez SAP. Na przestrzeni lat pojawiają się kolejne funkcje, transakcje, tabele w bazie danych, a nawet zupełnie nowe technologie (np. różne podejścia do tworzenia UI w przeglądarce www, SOAP/web services, a ostatnio – AI). Równocześnie producent systemu zachowywał bardzo dużą zgodność z wcześniejszymi wersami. Mogą to potwierdzić firmy, które używają systemu od lat 90., sukcesywnie go rozwijają i podnoszą wersje, a ich SAP nadal płynnie przetwarza wszystkie operacje.

Od początku swojego istnienia system SAP odnotował kilka ważnych kamieni milowych w rozwoju funkcjonalności, co wiązało się z wydawaniem kolejnych wersji i projektami upgrade u klientów. W 2005 r. zmieniło się podejście do nowych wydań systemu ECC 6.0 na rzecz bardziej ewolucyjnego modelu – publikowania tzw. enhancement packages (EhP). Ostatni z nich, wydany w 2016 r. EhP 8, gwarantuje wsparcie systemu do 2027 r. z opcją przedłużenia do 2030 za dodatkową opłatą. To niezwykle długi cykl życia systemu IT.

Równolegle, w 2015 r. SAP rozpoczął oferowanie nowej generacji swojego flagowego systemu – S/4HANA. Zachowuje on dużą zgodność z SAP ECC, ale wprowadza też nowości i pozbywa się balastu starszych technologii. Aktualna wersja S/4 pochodzi z 2023 r., a następne duże wydanie jest zapowiadane na 2025. Dodatkowo co pół roku są publikowane aktualizacje (feature packs) z mniejszymi rozszerzeniami funkcjonalnymi i zmianami prawnymi.

Aby podkreślić złożoność migracji z SAP ERP do wersji S/4HANA, producent nazywa ten proces konwersją (zamiast: upgrade). Z kolei dla instalacji nowych feature packów jest zarezerwowane określenie update.

Oprócz dodania nowych funkcji w S/4, producent dokonał też znacznych porządków, usuwając funkcje, które były zduplikowane lub bardzo rzadko używane przez klientów. Dla podkreślenia intencji „upraszczania systemu” SAP nazwał katalog różnic pomiędzy ECC i S/4: simplification items (SI). Każda pozycja SI jest szczegółowo opisana, w zależności od wersji systemu, wraz z odsyłaczami do not SAP i instrukcji postępowania dla każdego przypadku.

Możemy wyróżnić kilka głównych rodzajów simplification items:

• Zmiany w istniejących funkcjach. Na przykład wydłużenie identyfikatorów materiałów z 18 znaków w ECC do 40 w S/4 ze względu na potrzeby niektórych branż (np. automotive). Po konwersji standardowe programy i struktury danych w systemie zostaną dostosowane do nowej długości pól. Jednak własny dewelopment ABAP lub interfejsy mogą być przeszkodą w automatycznej konwersji. Odpowiedni simplification item dostarcza klientom i konsultantom dokładne wskazówki postępowania z tą zmianą.
• Konsolidacje funkcji w S/4. Tu przykładem może być uproszczenie modelu danych finansowych w Universal Journal. Dodanie centralnej tabeli ACDOCA z pozycjami wszystkich dokumentów finansowych sprawiło, że wiele innych tabel przechowujących nadmiarowe dane – jedynie w celu przyspieszenia działania starszych baz danych – nie jest już potrzebne. Także w tym wypadku standardowe programy i struktury danych SAP zostaną dostosowane w trakcie konwersji. W dewelopmencie, który odczytywał dane z tych tabel, mogą pojawić się jednak komplikacje – wymagające manualnych dostosowań.
• Usunięcie funkcji w nowej wersji. W SAP ECC możliwe było np. konfigurowanie parametrów sterujących MRP na trzech poziomach: zakładu, MRP area i składu. W S/4 to nadmiarowe rozwiązanie zostało uproszczone. Możemy skonfigurować MRP Area obejmujące tylko jeden skład, dlatego możliwość ustawiania parametrów MRP również na poziomie składu nie jest potrzebna. Jeśli wcześniej korzystaliśmy z tej opcji, dostosowania wymagają dane podstawowe i ewentualne custom development. Inna funkcjonalność nieobecna w S/4 to Sales Activities / Sales Support. Było to proste rozwiązanie „mini-CRM” wbudowane w ECC 6.0 do zarządzania relacjami z klientami. Firmy, które korzystały z tych funkcji, muszą obecnie znaleźć alternatywę, np. SAP Cloud for Customer.

Dla niektórych funkcji wychodzących z użycia producent pozostawił czas na ich migrację do nowych odpowiedników w wersji S/4HANA. Na przykład rekomendowaną alternatywą dla rozwiązania Logistics Execution Transportation (LE-TRA) jest Transportation Management. Dla tego typu migracji na nowsze funkcjonalności SAP dostarcza rozwiązania przejściowe – tzw. compatibility packs. Pozwalają one nadal używać starszych kluczowych funkcji systemu po konwersji, lecz tylko przez ograniczony czas. Większość z nich zostanie wyłączona pod koniec 2025 r. Wyjątkiem są trzy duże compatibility packs, które pozostaną dostępne w S/4 aż do 2030 r. Są to:

• LE-TRA,
• Customer Service,
• Production Planning for Process Industry (PP-PI).

Dzięki takiemu podejściu konwersję techniczną można, a nawet trzeba planować na najbliższą przyszłość, ale zmiany biznesowe dotyczące tych trzech obszarów możemy odłożyć na bardziej dogodny czas.

W klasycznym upgrade systemów SAP kolejno wykonywaliśmy migrację systemów rozwojowego, testowego i wreszcie produkcyjnego. Ze względu na wagę i złożoność konwersji do S/4 producent rekomenduje teraz nieco bardziej rozbudowaną sekwencję działań.

Poza standardowym pejzażem i ścieżką transportu powinniśmy powołać dodatkowy system testowy, tzw. Sandbox (1 na schemacie poniżej). Pozwoli on przećwiczyć konwersję bez wpływu na działanie bieżącego pejzażu systemów, trwające transporty i dewelopment. Następnym etapem projektu może być utworzenie kopii systemu deweloperskiego i jej konwersja (2 na schemacie). Dalej powołujemy drugi system testowy jako kopię systemu produkcyjnego i wykonujemy również jego konwersję (3 na schemacie).

Przy tym podejściu wymagane jest zaangażowanie większej liczby zasobów. Z pejzażu, który miał trzy systemy, powstało ich sześć, z czego trzy są kopiami systemu produkcyjnego. Zaletą tego nieco bardziej kosztownego podejścia jest jednak zachowanie nienaruszonej pierwotnej ścieżki transportów i całego pejzażu systemów deweloperskiego, testowego i produkcyjnego. Nasz system – i biznes – jest dzięki temu odporny na niespodzianki czy zmiany planów w trakcie projektu przejścia na nową wersję.

W kolejnym kroku wykonujemy konwersję systemu produkcyjnego (4 na schemacie), pozostawiamy także „nowe” systemy rozwojowy i testowy, powołane wcześniej jako kopie systemów (5). Pozostałe instancje można zarchiwizować (6).

Jest to rekomendowana sekwencja działań w pejzażu systemów. A jak to wygląda na poziomie pojedynczego systemu? Dla poszczególnych jego komponentów mamy do dyspozycji różne narzędzia wspierające konwersję:

• Maintenance planner – analizuje obecną wersję systemu (poziom EHP, add-ons, aktywne funkcje biznesowe) i określa dokładny zbiór docelowych komponentów do wykonania konwersji do wskazanej wersji S/4;
• Readiness Check – wykonuje analizę konfiguracji i danych w systemie produkcyjnym lub ewentualnie w jego kopii. Tworzy plik XML, który po pobraniu można wysłać do narzędzia Readiness Check w SAP Cloud (plik nie zawiera danych poufnych). Na tej podstawie narzędzie SAP może ocenić, które funkcje są używane i jakie simplification items będą istotne;
• Custom Code Analysis – ocenia programy ABAP pod kątem ich zgodności z wersją S/4HANA – zarówno ze zmianami składni języków ABAP i SQL, jak też sprawdza, czy np. zawierają odwołania do obiektów usuniętych w nowej wersji systemu.

Wykorzystanie tych trzech narzędzi warto potraktować jako miniprojekt analizy przed konwersją. Pozwoli on lepiej oszacować pracochłonność, czas trwania i wybrać podejście do faktycznego projektu.

Po analizie należy wykonać szereg działań związanych z simplification items. Jednym z ważniejszych dostosowań jest uruchomienie funkcjonalności Partnera Biznesowego, która scala rekordy dostawców i odbiorców. Tę zmianę należy wykonać jeszcze w wersji SAP ECC. Zalecamy też wstępne dostosowanie dewelopmentu, np. usunięcie nieużywanych programów.

Po uporządkowaniu systemu rozpoczynamy właściwą konwersję. Na poziomie technicznym używamy narzędzia Software Update Manager (SUM) do instalacji nowej wersji oprogramowania serwerowego, nowych programów ABAP oraz nowych struktury danych. Jeżeli wcześniej standardowe obiekty SAP były modyfikowane, konieczne jest wykonanie dostosowań z wykorzystaniem narzędzi SPDD/SPAU. SUM automatycznie przeniesie wszystkie dane transakcyjne, podstawowe oraz konfigurację do nowej bazy systemu S/4. Do wykonania pozostanie szereg zadań wynikających z simplification items.

Kolejne ważne zadanie, czyli custom code adaptation, to dostosowania, których nie dało się zrobić przed konwersją. Część zmian wykona się automatycznie (dzięki nowej funkcji quick fixes w narzędziach ABAP Development Tools), a część będzie wymagała interwencji programistów.

Efektem tych działań jest skonwertowany, gotowy do działania system S/4.

Z naszych doświadczeń wynika, że średnio projekt konwersji w podejściu brownfield – od rozpoczęcia analizy systemów aż po go-live i wsparcie po starcie – trwa około 9-12 miesięcy.

Greenfield, czyli reimplementacja, wdrożenie systemu od nowa – to metoda dla firm, które są zainteresowane wykonaniem przy tej okazji większych porządków w procesach biznesowych oraz w danych (archiwizacja znacznej części danych historycznych) dotychczasowych instalacji ECC 6.0.

Ten typ projektu zaczyna się od standardowej instalacji systemu S/4. Dostosowanie systemu do potrzeb organizacji może się odbyć poprzez wybranie i aktywowanie wzorcowych procesów SAP Best Practices – obejmujących konfigurację i aplikacje Fiori. Standardowe procesy przyspieszą wdrożenia, ale na pewno nie pokryją 100% potrzeb i specyfiki działania organizacji. Konieczne będzie zdefiniowane dodatkowych wymagań, kolejnych kroków w procesach czy zupełnie nowych procesów, dodanie specyficznej konfiguracji oraz dewelopmentu.

Połączenie standardowych procesów oraz dodatkowych wymagań złoży się na koncepcję wdrożenia systemu. Efektem dalszych prac konfiguracyjnych i programistycznych będzie system gotowy do zasilenia danymi. Migration cockpit – nowe standardowe narzędzie S/4, następca LSMW – pozwala na migrację kilkudziesięciu typowych obiektów danych podstawowych z systemu źródłowego. Dobrą praktyką jest graniczenie migrowanych danych transakcyjnych do niezbędnego minimum: stanu zapasów, bilansu otwarcia czy pozycji nierozliczonych, by nowy system mógł płynnie rozpocząć pracę produkcyjną.

Warto podkreślić, że w modelu Brownfield możliwe jest przejście na wersję on-premise lub S/4HANA Cloud Private edition. W modelu Geenfield dodatkowo możliwa jest reimplementacja na wersję S/4HANA Cloud Public edition.

Trzeci kolor migracji do S/4 – Bluefield – to autorskie podejście firmy SNP, partnera All for One. Projekty Bluefield (nazwane też Selective Data Transition) rozpoczynają się od wykonania kopii systemu produkcyjnego w wersji tzw. empty shell. Taka kopia obejmuje standardowe programy SAP, custom dewelopment i całą konfigurację klienta, ale bez danych podstawowych i transakcyjnych. Następnie ten „pusty” system jest konwertowany do wersji S/4 za pomocą narzędzi używanych w podejściu brownfield (SUM, Custom Code Adaptation), wykonywane są dostosowania wynikające z simplification items oraz zmian kodu.

Ta część projektu jest podobna do modelu brownfield, jednak dzięki temu, że jest wykonywana na kopii, nie zaburza bieżącej pracy systemu produkcyjnego. Wszystkie działania są wykonywane przy praktycznie pustej bazie danych, a zatem nie zajmują dużo czasu.

Przenoszenie danych podstawowych i transakcyjnych odbywa się za pomocą dedykowanych narzędzi (platformy transformacji danych CrystalBridge). Warto podkreślić, że podczas przenoszenia danych pomiędzy źródłem a systemem docelowym mamy do dyspozycji szereg dodatkowych możliwości filtrowania i modyfikacji danych. Na przykład dodanie reguły pominięcia dokumentów starszych niż wskazana data pozwoli uzyskać system, który ma historię danych transakcyjnych w rozsądnych granicach czasowych. Starsze dane będą pomijane, co pozwala radykalnie zmniejszyć wielkość bazy danych. Inny przykład filtrowania to pominięcie części danych według struktury organizacyjnej (jeśli np. system przechowuje dane z nieistniejących już spółek czy zakładów). Narzędzia te można też wykorzystać do czyszczenia i reorganizacji danych (np. usunięcie zduplikowanych kontrahentów, przenumerowanie cost centers czy planu kont).

Czas trwania projektu Bluefield jest porównywalny z brownfield (lub krótszy, jeśli przynosimy mniej danych). Wiąże się natomiast z koniecznością zakupu licencji na oprogramowanie CrystalBridge. Zaletą tego podejścia – podobnie jak w greenfield – jest możliwość reorganizacji danych, jednak możemy ją osiągnąć w znacznie krótszym czasie i przy relatywnie niższym budżecie niż pełnej reimplantacji.

Zamiast podsumowania, zbierzmy najważniejsze czynniki wpływające na plan projektu:

• Zakres funkcjonalny obecnie wykorzystywanego systemu ma bezpośrednie przełożenie na to, ile simplification items oraz compatibility packs będzie dotyczyć migracji;
• Custom development, a konkretnie liczba i zakres dostosowań kodu ABAP, które są konieczne do poprawnego funkcjonowania systemu;
• Infrastruktura: liczba systemów w pejzażu oraz decyzja: czy jednocześnie z przejściem na S/4HANA migrujemy do chmury;
• Wymagania biznesowe: oczekiwane (lub nie) zmiany funkcjonalności;
• Ograniczenia biznesowe, np. czas dostępności kluczowych użytkowników do wykonywania testów, ograniczenia co do terminu i czasu trwania niedostępności systemu produkcyjnego;
• Inne równolegle planowane projekty, np. przejście z SAP HCM na SuccessFactors, wdrożenie hurtowni danych w chmurze, przejście z Process Integration / Proces Orchestration na SAP Integration Suite;
• Inne uwarunkowania wynikające ze strategicznych planów firmy w zakresie rozwoju infrastruktury IT/SAP.