Przedstawiamy, jak bezpieczne migrować dane do S/4, jaki scenariusz wybrać i jakich narzędzi do tego użyć, by w efekcie ograniczyć ich liczbę.

Przyjrzyjmy się różnym scenariuszom migracji pod kątem migracji danych.

Greenfield. W tym podejściu – wdrożeniu systemu od zera, zaczynamy korzystać z nowych funkcji i technologii S/4 bez dostępu do danych historycznych. Skupiamy się na dostosowaniu systemu do procesów biznesowych. Jest konieczny dodatkowy projekt migracji danych, by móc korzystać z analiz wstecznych.

Brownfield. To podejście przeciwne. Nie zmieniamy procesów biznesowych. Do nowego systemu zabieramy całą historię i wszystkie dane. Migracja to w istocie upgrade techniczny systemu do nowej wersji i szybszej bazy danych.

Bluefield. To podejście łączy to, co najlepsze w obu powyższych. Przenosimy się do nowej wersji systemu, przy okazji elastycznie ulepszamy procesy i możemy selektywnie zmigrować dane historyczne. Migrację możemy wykonać szybko – po odpowiednim wcześniejszym przygotowaniu powinno się to zamknąć w ciągu weekendu (w piątek wieczorem zaczynamy, w sobotę wieczorem już kończymy i przekazujemy gotowy system do klienta, by mógł go w niedzielę testować i w poniedziałek oddać użytkownikom). Ten czas można jeszcze skrócić (near zero downtime). Warto podkreślić, że nie jesteśmy uzależnieni od roku obrotowego, możemy wykonać migrację w dowolnym momencie.

Odchudzić system – po co i jak

Powody selekcji danych historycznych mogą być różne. Można je podzielić na dwie zasadnicze kategorie. W pewnych okolicznościach jest to konieczne. Na przykład w wypadku zbycia jednostki gospodarczej, gdy wydziela się system dla sprzedanego podmiotu, jednak bez danych podstawowych (szczególnie konieczna jest ochrona danych wrażliwych, jak dane finansowe, adresy, numery kont itp.). Innym powód to wielkość systemu. Zbyt duży rodzi konieczność zaplanowana długiego czasu niedostępności na migrację. Nie każda firma może sobie na to pozwolić i wtedy pojawiają się postulaty, by pozbyć się zbędnego balastu.

Drugą kategorią powodów jest chęć optymalizacji. Ograniczenie ilości danych wpływa na podniesienie efektywności pracy systemu, a tym samym jego przyspieszenie. Dane historyczne to często zbędny balast, którego można się pozbyć bez szkody dla prowadzonego biznesu. I wreszcie – mniejszy wolumen danych ułatwia wykonanie innych scenariuszy transformacji w tym samym projekcie co migrację do S/4 (np. harmonizacja i konsolidacja planu kont lub partnera biznesowego).

W autorskim podejścu Bluefield wykorzystujemy platformę CrystalBridge oferującą szerokie portfolio narzędzi automatyzujących czynności migracyjne, w tym także migrację danych.

Migracja danych w typowym projekcie konwersji do S/4

Cechą wyróżniającą podejście Bluefield w migracji do S/4 jest utworzenie pustej kopii systemu (bez danych), a następnie jej konwersja do S/4. W ten sposób powstaje złota kopia systemu, gotowa na przyjęcie danych. Kolejnym krokiem jest migracja testowa, a następnie wykonujemy weryfikację, testy użytkowników, poprawki i udoskonalanie specyfikacji. Wykonujemy kilka iteracji migracji, testów i poprawek (ciągły proces), co pozwala wyłapać wszystkie błędy – do skutku (zwykle jest to 2-5 cykli, w zależności od złożoności projektu). Po ostatnim cyklu – próbie generalnej (służącej poprawie wydajności i rozpisaniu szczegółowego harmonogramu) następuje start produktywny.

W fazie analizy – jeszcze przed uzyskaniem dostępu do systemu klienta, wykorzystujemy narzędzie System Scan, które prezentuje w atrakcyjnej formie wizualnej, co zawiera system, jak są wykorzystywane poszczególne dane i procesy.

Narzędzie CrystalBridge Transformation Cockpit pozwala na wykonanie selekcji danych na podstawie struktury organizacyjną lub czasu.

Selekcja na podstawie struktury organizacyjnej (FI – jednostka gospodarcza, SD – dział sprzedaży, MM – np. zakład, CO – obszar rachunku kosztów) występuje w każdym typie projektu transformacji SAP. Druga opcja – selekcja w oparciu o czas (zwykle rok obrotowy) – jest możliwa dla każdego obszaru SAP, w podejściu tabelarycznym lub w podejściu zagregowanym (BAPI).

Co z danymi historycznymi?

A co się dzieje ze starymi danymi? Możliwych jest kilka podejść. W zależności od rodzaju danych i decyzji klienta dane historyczne można zarchiwizować 1:1 (współpracujemy z firmą podwykonawczą, która specjalizuje się w transformacjach archiwizacji), możemy je przechowywać w hurtowni danych (w BW możemy transformować dane narzędziami dostępnymi w standardzie BW lub skorzystać z rozwiązań dostarczanych przez naszą firmę). Stare dane można też po prostu usunąć.

Migracja danych w projekcie konwersji do S/4 w podejściu Bluefield

Testy zautomatyzowane

Testy zautomatyzowane to jedno z narzędzi, które po selektywnej migracji danych pozwala sprawdzić, czy do systemu docelowego spakowaliśmy rzeczywiście te dane, które są potrzebne do prawidłowego działania procesów biznesowych. Za ich pomocą możemy też sprawdzić konfigurację. Najważniejsze zalety testów zautomatyzowanych to:

  • Są niezależne od interfejsu użytkownika;
  • Zawierają predefiniowane scenariusze testowe;
  • Pozwalają na elastyczny wybór zakresu testowanych danych;
  • Umożliwiają śledzenie logu testów;
  • Opracowanie obiektów testowych specyficznych dla klienta nie wymaga dużego nakładu pracy;
  • Nie wymagają dodatkowego sprzętu.

Kolejne narzędzie to Data Consistency Verification. Służy do sprawdzania połączeń między poszczególnymi tabelami i polami oraz weryfikacji integralności danych. Rozwiązanie zapewnia:

  • Techniczne sprawdzenie spójności danych całego systemu;
  • W pełni automatyczną kontrolę;
  • Tylko ocena stwierdzonych niezgodności i ich uwzględnienie w implementacji musi być wykonane ręcznie przez użytkownika;
  • Trzy rodzaje weryfikacji: klucze obce, wartości domeny oraz stałe wartości domeny.

I na koniec dobra rada. Po przeprowadzce do nowego miejsca warto utrzymywać porządek w danych podstawowych. Firma SAP oferuje dedykowane narzędzie do zachowania spójności danych – Master Data Governance. Także All for One oferuje swoim klientom wsparcie w tym zakresie. 

Case study #1: Branża automotive

Selektywna migracja danych

Klient już na systemie źródłowym miał klarowny podział systemu wg jednostek organizacyjnych. Dla finansów był to podział wg jednostki gospodarczej, dla sprzedaży był to dział sprzedaży, dla kontrolingu – obszar rachunku kosztów, a dla zakupów – zakład. Problematyczny był jedynie dział zaopatrzenia. Tu poradziliśmy sobie w ten sposób, że po uzgodnieniu z klientem nie usuwaliśmy danych.
Projekt był o tyle nietypowy, że klient postanowił zduplikować swój system (clode and delete), czyli zrobić kopię mandanta i następnie usunąć zbędne dane (podział biznesu na jednostkę produkującą auta osobowe i drugą – produkującą ciężarówki). Zaleta takiego podejścia była taka, że klient mógł cały czas pracować na obu systemach równolegle, a usuwanie danych mogło zostać wykonane w dowolny weekend.

 

Case study #2: Sektor ubezpieczeń

Poprawa wydajności

W projekcie migracji do S/4 łączyliśmy dwa systemy źródłowe klienta (oddzielne dla usług związanych z ubezpieczeniami mienia i ubezpieczeniami na życie). Wyzwaniem była wielkość systemu i jego wydajność. W systemie występuje kilkaset tabel liczących po kilka terabajtów danych i ponad miliard rekordów. Oczekiwaniem klienta było przeniesienie wszystkich historycznych danych ubezpieczeniowych. Dane z obszaru FI nie są krytyczne, dlatego zdecydowano się wykonać selekcję danych FI w oparciu o czas (tylko ostatnie 2 lata) – co skróciło czas konwersji w tym obszarze do pół godziny. Pozostały czas z 48-godzinnego okna czasowego został przeznaczony na migrację danych z pozostałych obszarów funkcjonalnych systemu (klient zapewniał odpowiedni hardware).

 

Case study 3#: Edukacja

Harmonizacja danych

Projekt dla uniwersytetu w Arabii Saudyjskiej. W systemie źródłowym S/4 klient korzystał z funkcji Business Partnerów, nie przeprowadzono jednak czyszczenia danych i znaczna część z ponad 100 tys. rekordów była zduplikowana. Zadanie All for One polegało na czyszczeniu i harmonizacji danych z wykorzystaniem oprogramowania do automatycznej analizy danych, wyszukiwania duplikatów i identyfikacji tzw. złotego rekordu na podstawie zadanych warunków. Efekt – system z poprawnymi danymi podstawowymi jako źródłem do raportowania.