Krótszy downtime w migracji do S/4

Na wyzwanie związane ze zbyt długim czasem niedostępności systemu podczas migracji dużego systemu do S/4 trafiliśmy w międzynarodowej firmie działającej w segmencie hydrauliki oraz systemów i techniki płynów. Firma posiada 50 spółek zależnych w różnych krajach, 14 linii produkcyjnych i zatrudnia prawie 10 tys. pracowników. Wszystkie spółki działają na pojedynczym systemie SAP ECC, którego baza danych MAXDB ma wielkość 9 TB.

Projekt migracji jest nie tylko konwersją do nowej wersji systemu bez wprowadzania zmian. Przy okazji, bez osobnego podprojektu, wdrażany jest Business Partner (CVI), łączone są dwa obszary rachunku kosztów w kontrolingu w jeden, a także wprowadzane inne zmiany wymuszane przez nową wersję systemu.

62 godziny downtime – zamiast 342

Jak zwykle nie dało się wskazać pojedynczej przyczyny długiego czasu przestoju systemu podczas pierwszych testów migracji. Na 342 godziny testowego downtime’u złożyły się przede wszystkim wielkość bazy danych, typ bazy danych (MAXDB nie jest demonem szybkości, szczególnie przy bardziej złożonych zapytaniach SQL), konieczność przeniesienia wszystkich danych ze źródłowego systemu (pełna historia, bez usuwania starych danych) i złożone kryteria połączenia dwóch obszarów rachunku kosztów w SAP (transformacja danych w locie). Ponieważ zmierzony podczas testowej migracji czas przestoju systemu nie mógł być zaakceptowany przez klienta, zaaplikowaliśmy liczne środki zaradcze, by go skrócić do wartości oczekiwanej – 62 godzin.

W All-for-One Poland wykorzystujemy wiele sposobów skracania czasu przestoju podczas startu produktywnego. Niektóre są proste, inne wymagają większego nakładu pracy, a są i takie, które potrafią wręcz zdublować pracochłonność, ale pozwalają na znaczną optymalizację downtime.

Sposoby skracania downtime
w migracji do S/4HANA

Zazwyczaj zaczynamy od weryfikacji architektury systemów, elementów wpływających na wydajność (np. wielkość pamięci, szybkość przesyłu plików do/z systemu SAP). W zdiagnozowaniu, które fragmenty należy zweryfikować, pomagają nam narzędzia monitorujące wydajność (najczęściej CrystalBridge Monitoring).

CrystalBridge Monitoring – narzędzie pozwalające na łatwiejszą identyfikację wąskich gardeł w projekcie migracji

Oprócz działań czysto technicznych weryfikujemy plan migracji danych w okienku niedostępności systemu, dobrze planując operacje, które mogą się odbywać równolegle. Dodatkowo dostosowujemy standardowy kontent w narzędziach transformacyjnych (CrystalBridge Transformation Cockpit) do konkretnej bazy danych i systemu klienta. To pozwala na dalsze oszczędności czasu – szczególnie w przypadku danych, których migracja trwa najdłużej. W przypadkach szczególnie trudnych, rozmawiamy z klientem na temat możliwości selekcji danych do migracji na S/4HANA (np. brak migracji danych starszych niż X lat) oraz rozważamy przesłanie części danych poza okienkiem niedostępności systemu.

U opisywanego klienta udało się skrócić czas z 342 godzin początkowo do 152 godzin po kolejnych testach, by docelowo w fazie GLS osiągnąć oczekiwany przez klienta czas 62 godzin niedostępności.

Narzędzia migracyjne

Do migracji systemów ECC do S/4HANA grupa All for One wykorzystuje specjalne narzędzia migracyjne (w tym zakresie jesteśmy partnerem Grupy SNP i korzystamy z portfolio jej produktów CrystalBridge). Pozwala to nie tylko wykonywać projekty migracji szybciej i bardziej przewidywalnie, ale także równolegle wdrożyć w systemie wymagane przez klienta zmiany. W naszych projektach transformacji SAP prawie standardem jest wykonywanie w systemie SAP wdrożenia funkcjonalności partnera biznesowego bez osobnego podprojektu, przechodzenie w finansach z raportowania według kont na raportowanie według ksiąg równoległych, dostosowanie planu kont, przekształcanie jednostek organizacyjnych SAP (łączenie lub dzielenie danych), dodawanie nowych walut i wiele innych drobnych transformacji.

Projekty migracji, szczególnie w przypadku większych systemów SAP (>2TB danych, obsługa wielu krajów z różnych części świata w jednym systemie SAP), są często wyzwaniem nie tylko organizacyjnym, ale i technicznym. Długość downtime w takich projektach to tylko jeden z czynników, który może zaważyć na losach projektu.

Dzięki zastosowaniu narzędzi transformacyjnych i specjalnego podejścia, w którym migracja pustego systemu do S/4HANA jest oddzielona od migracji i transformacji danych, mamy większe pole manewru. Możemy łatwiej wdrażać zmiany w systemie, łącznie z konwersją do S/4, oraz znaczne zmniejszyć czas niedostępności systemu podczas go-live. Dzięki naszym doświadczeniom zebranym z ponad 100 projektów migracji do S/4, możemy śmiało twierdzić, że czas przestoju systemu podczas fazy go-live nie będzie przeszkodą w naszym projekcie migracji.

Krzysztof Siwiec, Dyrektor Digital Transformation Center, All for One Poland