Migracja SAP na platformę HANA

Forte oczekiwało przeprowadzenia całościowego procesu modernizacji platformy sprzętowo-programowej. Start projektu został poprzedzony starannymi analizami obejmującymi spodziewane korzyści biznesowe, jak i związane z nim koszty realizacji. Pod koniec sierpnia 2018 r. w Fabryce Mebli Forte rozpoczął się projekt upgrade’u i migracji systemów SAP ERP na platformę SAP HANA. Wynikiem projektu był skonwertowany do unicode system SAP ERP 6.0 z EHP7 na platformie SAP HANA 2.0.

Planowanie i przygotowanie

Przemyślenie sposobu realizacji i jej zorganizowanie we wszystkich wymiarach (działania, ludzie, zasoby, narzędzia, skutki itp.) jest kluczowym elementem wg metodyki projektowej SNP Poland (aktualnie All for One Poland) – Go Forward. Jej celem jest lepszy rezultat projektu, a sama metodyka stanowi ważny element warsztatu naszej organizacji. Podobnymi zasadami kieruje się firma Forte. Pozwoliło to w efektywny sposób stworzyć wspólną mapę drogową jako swoisty przewodnik projektu migracji, w którym zapisany był jasny podział odpowiedzialności stron za poszczególne zadania wraz z harmonogramem ich realizacji. Dla firmy produkcyjnej, jaką jest Forte, terminowość oraz solidność wykonania prac stanowi podstawę do efektywnego prowadzenia biznesu. Planowanie musiało uwzględnić specyficzne wymagania branży, czasy niedostępności systemu, a wreszcie szczegółowe testy potwierdzające skutek projektu, czyli działający system umożliwiający postęp w zarządzaniu przedsiębiorstwem. Stworzony wspólnie plan cechowała zrozumiałość, realistyczność, podatność na zmiany oraz możliwość pełnej kontroli postępu.

Do realizacji zostały powołane zespoły złożone z pracowników firmy Forte oraz konsultantów SNP – technologicznych i modułowych z obszarów biznesu wykorzystywanych w fabryce. Całym procesem zarządzał duet kierowników projektów po stronie klienta oraz SNP.

Na wczesnym etapie planowania ustalono, że wersja systemu ERP, jaką posiadało Forte, nie pozwalała na jego bezpośrednią migrację na platformę HANA. Konieczne było najpierw wykonanie upgrade’u SAP ERP do wersji minimum 6.0 EHP7 wraz z konwersją do unicode. Zaplanowano to do wykonania w jednym kroku z wykorzystaniem funkcjonalności Database Migration Option (DMO). Takie podejście pozwalało na skrócenie czasu projektu przez jednokrokowe przejście technologiczne z systemu źródłowego do docelowego, a tym samym dostosowania i testy funkcjonalne mogły być wykonane jednorazowo po każdej migracji systemu. Podczas określenia ścieżki upgrade’u zweryfikowano, czy wszystkie zainstalowane rozwiązania dodatkowe mogą zostać podniesione do wymaganych wersji i czy mogą współpracować z HANA. Zweryfikowano również potencjalny wpływ migracji na działanie raportów i rozszerzeń z przestrzeni nazw użytkowników.

W celu zagwarantowania i potwierdzenia odpowiedniej jakości procesu migracji, zaplanowano szczegółowe scenariusze testowe, obejmujące swoim zakresem wszystkie funkcjonalności biznesowe stosowane w Forte. Za proces przygotowania scenariuszy oraz późniejszej ich realizacji przede wszystkim odpowiadał klient przy doradczej roli SNP (aktualnie All for One Poland). Przy projektowaniu testów konieczna jest doskonała znajomość procesów biznesowych organizacji, umożliwia to znaczne ograniczenie czynników nieznanych i nieprzewidywalnych przed docelową migracją systemu produkcyjnego.

Wynikiem wszystkich aktywności projektowych był plan migracji, który nie był ani zbyt ogólnikowy, ani zbyt szczegółowy. Pozwalał na precyzyjne mierzenie postępu prac w celu zidentyfikowania odchyleń, ale jednocześnie umożliwiał podjęcie działań korekcyjnych przez przesunięcie działań czy zamianę ich kolejności.

Zmiany w infrastrukturze

Po ustaleniu wektora upgrade’u przystąpiono do wymiarowania (sizingu) sprzętu dla systemów SAP HANA. To bardzo istotny etap zastosowania rozwiązania in-memory. W przypadku niedoszacowania wymaganej przestrzeni RAM nie będzie możliwości załadowania wszystkich zmigrowanych danych, a tym samym nie będzie możliwe uruchomienie systemów po migracji. Podczas tej operacji pomocny był standardowy raport SAP uruchamiany w każdym systemie, którego zadaniem było określenie szacunkowego rozmiaru bazy danych na platformie HANA. Raport bierze pod uwagę nieskompresowany wolumen danych, w tym przypadku w bazie danych DB4 (IBM DB2 dla iSeries) i kalkuluje szacunkowy rozmiar skompresowanej bazy na nowej platformie.

Na podstawie kalkulacji zdecydowano o zakupie platformy technologicznej, umożliwiającej uruchomienie nowych systemów wg zdefiniowanych założeń: wysoka dostępność w ramach klastra geograficznego (dwie serwerownie) z pełną redundancją platformy oraz infrastruktury sieciowej. Wybrano certyfikowane serwery (Appliance) oraz serwery pod zwirtualizowane środowisko serwerów aplikacyjnych SAP wraz z towarzyszącą infrastrukturą, jak przełączniki SAN i NET. Dla nowego rozwiązania zaprojektowano również nowy wydajny system backupowy w oparciu o rozwiązania EMC DataDomain i oprogramowanie NetWorker. Dostawcą wymaganej infrastruktury była firma SNP Poland przy współpracy z naszym partnerem technologicznym firmą DELL. Przedstawiciele Forte byli czynnie zaangażowani na etapie planowania i uruchamiania nowej platformy.

Migracja środowiska

Po ustaleniu planu migracji, przystąpiono do jego realizacji. Pierwszym krokiem było zainstalowanie i skonfigurowanie infrastruktury technicznej IT stanowiącej platformę sprzętową pod zmigrowane środowisko. Zespół techniczny złożony z pracowników Forte oraz konsultantów SNP zintegrował całe środowisko, osadzając go w istniejącej już infrastrukturze. W ramach prac wykonano montaż techniczny serwerów i infrastruktury towarzyszącej. Utworzono redundantne środowisko sieciowe z zagregowanymi linkami, połączono obie lokalizacje serwerowe, zainstalowano systemy operacyjne oraz utworzono środowisko wirtualne będące bazą dla serwerów aplikacyjnych. Na zakończenie podłączono całą infrastrukturę do nowego środowiska kopii zapasowych.

Jako że źródłowa wersja systemu wymagała jego podniesienia, to następnym krokiem było zdefiniowanie dokładnego wektora, polegające na określeniu, w jaki sposób będzie przebiegał upgrade oraz jakie komponenty i do jakiej wersji zostaną podniesione. Krok ten zrealizowano przy pomocy narzędzia Maintenance Planner dostarczanego w chmurze przez producenta aplikacji SAP. Oprogramowanie to pozwala w sposób prosty i efektywny planować wszelkie zmiany w wersjach pejzażu systemów SAP, jak również przygotować koszyk nośników i poprawek do pobrania oraz zdefiniować plik XML zawierający informacje o wektorze upgrade.

Procedurę migracji wykonywano zgodnie z metodologią rekomendowaną przez SAP, wykorzystując narzędzie Software Update Manager (SUM) i rozpoczynając od systemów rozwojowych. Wybrano procedurę DMO pozwalającą w jednym kroku na kombinowany upgrade, konwersję do unicode oraz migrację na platformę SAP HANA. Metoda ta pozwala na przeniesienie systemu znajdującego się na tradycyjnej relacyjnej bazie danych na bazę in-memory dostarczaną przez SAP. Przy zastosowaniu tej metody niedostępność systemu źródłowego jest skrócona do czasu niezbędnego do przeniesienia danych aplikacyjnych po zakończonym procesie upgrade, realizowanym w tzw. instancji shadow. Dzięki takiemu podejściu system źródłowy w trakcie tego procesu dostępny jest w sposób nieprzerwany. Niedostępność rozpoczyna się w momencie rozpoczęcia transferu danych aplikacyjnych, a same dane do unicode konwertowane są w locie.

Konwersja do unicode wymaga dokładnego procesu przygotowania systemu źródłowego, jak również wykonania wymaganych kroków w systemie docelowym. Najważniejszym z kroków w systemie docelowym jest dostosowanie programów do działania w środowisku unicode. Wymaga to aktywowania flagi unicode w raporcie, który przeznaczony jest do konwersji. Większość programów dostarczanych w standardzie SAP mą tę flagę domyślnie aktywną. Zmiany najczęściej wymagane są dla programów z przestrzeni nazw użytkownika, dla których flaga unicode nie była aktywowana na etapie tworzenia. Taka aktywacja może wymuszać dostosowanie kodu programu do zgodnego ze składnią zarezerwowaną dla programów typu unicode. Dostosowanie programów do unicode wykonano w systemie rozwojowym po zakończenie jego przeniesienia.

Proces migracji każdego systemu kończony był dokładną procedurą weryfikacyjną, obejmującą testy techniczne i aplikacyjne.

Przed przystąpieniem do migracji systemu testowego ERP wykonano jego aktualizację przez wykonanie kopii z produkcji. To działanie pozwoliło dość dokładnie określić czas trwania poszczególnych faz upgrade’u, a tym samym oszacować przyszłą niedostępność systemu produkcyjnego. Szczególną uwagę przyłożono do wykonania dokładnych testów pomigracyjnych. Za dokładność i jednoznaczność testów odpowiadali przedstawiciele klienta. W przypadku wychwycenia błędów czy nieprawidłowości, były one na ich wniosek niezwłocznie korygowane, a testy tego elementu powtarzane. Zespół Forte był aktywnie zaangażowany w korygowanie i modyfikowanie własnych raportów SAP. Po zakończeniu wszystkich testów potwierdzono gotowość przeprowadzenia migracji produkcyjnej.

Na podstawie uzyskanych wyników przygotowano godzinowy plan podniesienia wersji i przeniesienia na nową bazę danych dla systemu produkcyjnego ERP. Ponadto upgrade każdego z systemów został dokładnie opisany w protokole z prac, łącznie z odnotowaniem czasów poszczególnych faz. W opisach zawarto informacje o problemach, które wystąpiły, oraz sposobach ich rozwiązania. Pozwoliło to na późniejsze bezproblemowe wykonanie procedury migracyjnej systemu produkcyjnego w zakładanym czasie.

Na etapie planowania zdecydowano, że zapewnienie wysokiej dostępności dla systemu produkcyjnego jest wymagane. W tym celu zostały utworzone dwa klastry niezawodnościowe; na poziomie bazy danych oraz na poziomie serwerów aplikacyjnych.

Główny klaster bazodanowy został uruchomiony w oparciu o rozszerzenie High Availability Extension (SuSE HAE) oraz o replikację podstawowego węzła produkcyjnej bazy danych HANA do węzła zapasowego. Serwer zapasowego węzła jest również platformą dla rozwojowej i testowej bazy danych. Przy konfiguracji środowiska, w której węzeł zapasowy pełni dodatkową funkcję, wymagane jest zamknięcie wszystkich dodatkowych baz danych podczas przełączenia w przypadku wystąpienia awarii. Konfigurację klastra wykonano zgodnie z tymi wymaganiami. Podczas awarii węzła podstawowego usługa klastrowa wpierw zatrzymuje bazy danych dla systemu rozwojowego i testowego, a następnie wykonuje przełączenie produkcyjnej bazy danych na węzeł zapasowy.

Podczas realizacji podobnie zadbano o wysoką dostępność serwerów aplikacyjnych. Konfigurację oparto o technologię Microsoftu Failover Clustering. W uruchomionej konfiguracji zdefiniowano dwa serwery aplikacyjne z pływającą usługą ASCS. W przypadku awarii jednego z wirtualnych serwerów klaster Microsoft przełącza ASCS na drugi z węzłów, zapewniając w ten sposób dostępność środowiska z jednym działającym serwerem aplikacyjnym. Ma to wpływ na ogólną degradację wydajności systemu, ale zapewnia ciągłość jego działania.

Przed wykonaniem migracji produkcyjnej wykonano pełne testy niezawodnościowe dla różnych scenariuszy awarii. Aby zapewnić wiarygodność i jednoznaczność testów, w ramach klastra uruchomiono pełnoskalowe środowisko SAP, powstałe z migracji testowej produkcji. Po potwierdzaniu poprawności działania i akceptacji klienta, przystąpiono do finalnej, produkcyjnej migracji systemu SAP ERP. Dokładne i zweryfikowane podczas poprzedzających migracji procedury pozwoliły wykonać migrację bez błędów i w zakładanym czasie. Dokładne scenariusze testów technicznych i aplikacyjnych zostały wykorzystane do weryfikacji systemu produkcyjnego po podniesieniu wersji. Poprawność upgrade’u została potwierdzona przez Forte, systemy zostały udostępnione użytkownikom końcowym.

Podczas ostatniego etapu realizacji projektu migracji do SAP HANA zostały przeprowadzone testy odtworzeniowe z wykorzystaniem nowej infrastruktury kopii bezpieczeństwa. W ramach testów wykonano odtworzenie zarówno bazy danych jaki i serwerów aplikacyjnych. Pozytywnie zakończone testy potwierdziły gotowość środowiska do wspierania wymagających funkcji biznesowych z jednoczesnym utrzymaniem jego wysokiej dostępności i bezpieczeństwa.

Tomasz Krawczuk, Dyrektor ds. Zarządzania Projektami i Łańcucha Dostaw, Fabryka Mebli Forte

Projekt i administracja w pakiecie

Zadania partnera wdrożeniowego nie zakończyły się u nas z chwilą startu produkcyjnego. Pozyskaliśmy nową platformę sprzętowo-programową, ale okres budowania nowych kompetencji zespołów jest procesem długotrwałym i angażującym. Z tego względu zdecydowaliśmy się oddać nowe systemy w zdalną administrację doświadczonych administratorów SNP Poland (aktualnie All for One Poland, tym samym zapewniając sobie nie tylko opiekę nad systemami, ale także proaktywne działania optymalizujące, a także indywidualny konsulting.

Tomasz Krawczuk, Dyrektor ds. Zarządzania Projektami i Łańcucha Dostaw, Fabryka Mebli Forte

Cel osiągnięty

Możliwość sięgnięcia do potencjału sprawdzonego partnera i gwarancja, że powierzone mu prace zostaną wykonane zgodnie ze specyfikacją, w założonym czasie i budżecie, a ich jakość nie będzie budziła zastrzeżeń to istota współpracy między organizacjami. Celem naszych działań było osiągnięcie lepszego rezultatu, czyli udostępnienie perspektywicznego systemu gwarantującego lepszą wydajność, pozwalającego wykorzystać możliwości przetwarzania w czasie rzeczywistym i udostępniającego dostęp do nowych funkcjonalności, mogących uczynić proces zarządzania jeszcze efektywniejszym. Projekt Forte zakończył się sukcesem. Potwierdził, że dobra metodyka oraz planowanie mogą być gwarancją sukcesu. Przy czym należy pamiętać, że projekt realizowali pracownicy klienta i konsultanci SNP. To ich kompetencja i zaangażowanie zdecydowały o efekcie końcowym. Ten rodzaj współpracy powoduje, że korzyści zawsze uzyskują obie strony; klient, któremu przekazano metodologię działania zgodnie z najlepszymi praktykami oraz wymiernymi korzyściami wynikającymi z posiadania odpowiednich procedur oraz SNP (aktualnie All for One Poland), któremu przygotowanie wiedzy do przekazania pozwala na utrzymanie jej wysokiej jakości oraz utrzymania wysokiej pozycji na rynku.