Dane, które zasilą nowy system, są zwykle spadkiem po zastępowanym rozwiązaniu informatycznym. Czy będziemy tu mówić o zestawie arkuszy kalkulacyjnych, czy też o bazach danych zastępowanych aplikacji – informacje o naszych klientach, dostawcach, materiałach, fakturach czy księgowaniach muszą znaleźć się w nowym systemie, aby było możliwe jego wykorzystanie do obsługi działalności gospodarczej.

Czynności składające się na skuteczne przeniesienie tych danych nazywamy ogólnie migracją (czasem konwersją) danych.

Aby sprawnie zorganizować proces dostarczenia danych do nowego systemu, w ramach głównego projektu wdrożeniowego uruchamia się podprojekty migracji danych, zwane również projektami konwersji. Wymagają one określenia zakresu informacji, które należy przenieść, oraz określenia systemów źródłowych i docelowych.

W trakcie projektu wykonuje się ekstrakcję danych z systemów źródłowych, oczyszcza się je, przetwarza na postać zrozumiałą dla systemu docelowego i ładuje do niego.

Dbałość o szczegóły

Jest rzeczą oczywistą, że od nowego systemu oczekujemy, że jego funkcjonalności będą wspierały pracowników w realizacji ich codziennych zadań. Na przykład możemy oczekiwać, że dokonane przez dział handlowy przypisanie klienta do odpowiedniej klasy ryzyka zablokuje dalszą sprzedaż dla tego klienta, jeśli zalega on chociażby dzień z regulacją należności.

Spodziewane działanie systemu informatycznego w tej i w innych sytuacjach jest sterowane konkretnymi atrybutami w danych podstawowych i historii transakcji. Innym przykładem mogą być wymiary produktu i ich wpływ na automatyczne planowanie transportu lub klasyfikacja klienta i jej wpływ na udzielane rabaty.

Oczekiwaniem użytkowników jest takie przygotowanie rozwiązania, aby system prawidłowo planował transport, sugerował rabaty czy blokował sprzedaż niesolidnym płatnikom.

Załóżmy, że funkcjonalność systemu została skonfigurowana poprawnie i zgodnie z oczekiwaniami. Jednak w pełni prawidłowe reguły działania systemu zadziałają jedynie na tyle dobrze, na ile pozwoli im na to jakość danych, na których system będzie operować.

Przykłady przedsięwzięć SAP, którym towarzyszą projekty migracyjne:

  • kompleksowe wdrożenie SAP ERP (migracja danych z poprzedniego systemu ERP bądź z innych źródeł, w tym z dotychczasowych „wycinkowych” aplikacji),
  • rozbudowa SAP o nowe obszary – zastąpienie „specjalizowanej” aplikacji przez funkcjonalność SAP, np. HR czy WM (migracja danych z innej aplikacji),
  • zmiana dotychczas wykorzystywanego lokalnego rozwiązania SAP na centralnie zarządzane rozwiązanie korporacyjne SAP, często połączona ze zmianą (rozszerzeniem) wykorzystywanego zakresu SAP (migracja danych z SAP do SAP),
  • fuzja firm bądź przejęcie innych jednostek i włączenie ich obsługi do użytkowanego systemu SAP (migracja danych z rozwiązań wykorzystywanych dotychczas w jednostkach będących przedmiotem przejęcia czy fuzji).

Prowadzenie projektu migracji danych bez należytej staranności o szczegóły jest prostą drogą do systemu, który nie spełni oczekiwań użytkowników. Na każdym etapie przygotowania danych, na których będzie operował nowy system, konieczne jest zapewnienie, że przygotowany zestaw danych jest wystarczający do zapewnienia poprawnego działania pożądanych funkcjonalności biznesowych.

Obiekty danych i mapowanie systemów

Środowisko informatyczne, które czeka zmiana związana z planowaniem realizacji operacji biznesowych w nowym systemie informatycznym, jest zwykle bardziej złożone niż pojedyncza instalacja produktywnego systemu ERP.

Pierwszym krokiem w projekcie migracji danych jest odpowiedź na pytanie – jak krajobraz systemów po zmianie odnosi się do aktualnie istniejącego? To pozwoli nam określić źródła danych oraz miejsce ich przeznaczenia. Jednym z ważnych źródeł może niespodziewanie okazać się zbiór arkuszy kalkulacyjnych rozproszony po komputerach pracowników przedsiębiorstwa.

Obiektem danych określa się zarówno dane podstawowe, jak i transakcyjne, które z powodzeniem mogą być transferowane za pomocą jednego programu ładującego. Przykładem są indeksy materiałowe, dane partnerów biznesowych (klientów, dostawców), zamówienia zakupu, zlecenia sprzedaży, otwarte pozycje, bilans, środki trwałe, BOM-y (specyfikacje materiałowe), dane kadrowe i płacowe itp.

Mapowanie obiektów danych, czyli analiza zależności pomiędzy obiektami docelowymi i źródłowymi, to najważniejszy element definiowania zakresu migracji danych. Pozwala ono dokładnie wyróżnić te obiekty, które będą podlegać konwersji ze względu na wymagania systemów docelowych, oraz wskazać możliwe źródła danych bądź zaznaczać ich brak.

Bardziej szczegółowym elementem analizy wyróżnionych obiektów danych jest określenie zależności między nimi samymi. Ma to kluczowe znaczenie dla planowania kolejności ładowania danych.

Wzbogacanie danych

Już na etapie mapowania obiektów danych można stwierdzić, czy i w jakim zakresie dane będą podlegać ręcznemu wzbogaceniu. Może być ono wymagane, jeśli dane wymagają uzupełnienia dla zapewnienia poprawności działania pożądanych funkcjonalności systemu.

Jeśli planuje się, że działania te będą miały intensywny charakter, zasadne może być wydzielenie tzw. bufora danych w postaci systemu pośredniego między systemami źródłowymi i docelowymi.

Rolą bufora, rozumianego jako system bazodanowy jest nie tylko ułatwienie łączenia danych pochodzących z wielu źródeł, ale również umożliwienie tymczasowego gromadzenia dodatkowych informacji (niezbędnych z punktu widzenia systemu docelowego).

Kroki w dobrą stronę

Masowy charakter niektórych obiektów danych (np. klienci czy materiały) podsuwa zastosowanie narzędzi wspierających automatyczną ekstrakcję, czyszczenie i import danych. Na myśl przychodzą raporty, programy ABAP czy narzędzie LSMW.

Jednak zbytnie poleganie na automatyce, szczególnie gdy w trakcie migracji dane należy uzupełnić, nie prowadzi do powodzenia projektu. Dodatkowo przy niewielkiej liczbie danych koszt budowy narzędzi ekstrakcji i ładowania mógłby przekroczyć koszt pracy przy ręcznym przenoszeniu informacji. W zależności od wolumenu i charakteru danych stosujemy więc różne scenariusze konwersji.

W ramach realizowanej migracji danego magazynu danych możemy wyróżnić następujące zadania:

  • ekstrakcja danych z systemów źródłowych;
  • oczyszczenie i uzupełnienie danych;
  • opracowanie mechanizmu konwersji danych do pożądanego formatu;
  • sprawdzenie danych;
  • załadowanie danych do systemów źródłowych (w ramach zadań ładowania danych rozróżnia się etap budowania programów do konwersji danych oraz właściwy etap ładowania danych do systemu docelowego);
  • testy, symulacje i walidacja pracy systemu docelowego.

W praktyce projektowej sprawdzanie, ładowanie i testy realizujemy wielokrotnie, gdyż dopiero pierwsze załadowanie danych ujawnia pełną skalę wyzwań etapu oczyszczenia i uzupełnienia danych – trwającego często przez cały czas projektu wdrożeniowego.

Harmonogram migracji

Celem projektu migracji danych jest nie tylko ich dostarczenie do środowiska produkcyjnego (PRD), ale również zapewnienie danych w systemie rozwojowym (DEV) i zapewniania jakości (QAS). Z tego powodu równie ważnym zadaniem zespołu konwersji danych jest umożliwienie sprawnego przeprowadzenia kolejnych faz testów.

Działania związane z konwersją danych ze względu na swój specyficzny charakter planowane są zwykle nieco w oderwaniu od głównych podziałów faz całego projektu wdrożeniowego. Niemniej muszą być one z nimi silnie zsynchronizowane.

Zadania etapów ekstrakcji, opracowania mechanizmu konwersji i przygotowania programów do ładowania danych realizowane są równolegle z fazą projektowania koncepcyjnego nowo wdrażanego systemu. W trakcie tej fazy rozpoczyna się również zaangażowanie w etapie oczyszczania i uzupełniania danych.

W miarę trwania fazy realizacji nowego systemu, w momencie osiągnięcia gotowości systemu testowego do przyjęcia danych, rozpoczynają się kolejne cykle etapów sprawdzenia, ładowania i testowania, z których ostatni uruchamia się przed startem produktywnym w celu finalnego załadowania danych do startującego systemu.

Ręczna robota

Czyszczenie i wzbogacanie danych to najbardziej krytyczny element powodzenia całego procesu konwersji. Jest to jednocześnie etap najbardziej czasochłonny, wymagający dużego zaangażowania ze strony użytkowników końcowych.

Najbardziej charakterystyczną czynnością etapu czyszczenia danych jest usuwanie duplikatów. Nagminnie występująca sytuacja, w której ten sam partner biznesowy znajduje się kilkakrotnie w bazie danych, utrudnia prawidłowe raportowanie – klient może łatwo wymknąć się mechanizmom kontroli kredytowej, trudniej też policzyć wartości sprzedaży dla segmentu czy grupy klientów.

Pierwszym krokiem w projekcie migracji danych jest odpowiedź na pytanie – jak krajobraz systemów po zmianie odnosi się do aktualnie istniejącego?

Proste działanie, jakim jest zwyczajne usunięcie nadmiarowych rekordów danych z zestawu, powoduje szereg konsekwencji w pozostałych migrowanych danych – takich jak bilanse otwarcia czy transakcje sprzedaży, które mogą mieć referencje na usunięte nadmiarowe rekordy i również wymagają poprawy.

Kolejnym zagadnieniem wymagającym wsparcia użytkowników jest wzbogacanie danych. Odwołując się do przykładu kontroli kredytowej – stary system mógł określać jedynie wysokość limitu kredytowego, a nowo wdrażany system SAP ma wykorzystywać również funkcjonalność klas ryzyka.

Oczywiście przypisanie klienta do klasy ryzyka nie występuje w danych ekstraktowanych z systemu spadkowego i dane te będą uzupełniane przez pracowników w oparciu o własne zestawienia lub analizę historii współpracy z tym klientem pod kątem terminowości regulacji należności.

Wzbogacenie danych o przypisanie do klasy ryzyka dla kilku tysięcy kontrahentów wymaga dużego i odpowiedzialnego zaangażowania człowieka w projekcie migracji.

Na podstawie naszych doświadczeń możemy stwierdzić, że proces czyszczenia i wzbogacania danych, nawet wsparty narzędziem informatycznym, to działanie w ponad 80% wykonywanie ręcznie.

Drużyna ds. migracji

Zespoły realizujące zadania migracji danych są zespołami interdyscyplinarnymi. Niezbędne jest zatem zaangażowanie w całość prac migracji danych oprócz pracowników zarówno konsultantów funkcjonalnych, jak i technicznych.

W skład takiego zespołu powinni wchodzić:

  • lider zespołu jako jednoosobowy punkt kontaktu oraz osoba koordynująca prace i zapewniająca terminowe ich wykonanie, w zgodzie z planem całego projektu;
  • użytkownicy kluczowi, bezpośrednio odpowiedzialni za czyszczenie danych oraz definiowanie reguł mapowania;
  • właściciele procesów biznesowych – dla celów finalnych walidacji oraz weryfikacji reguł mapowania;
  • konsultanci integracji, których czas w 100% poświęcony jest na rozwój programów ekstrakcji i ładowania;
  • konsultanci funkcjonalni (co najmniej jeden z każdego zespołu) jako zasadnicze wsparcie w definiowaniu wymagań co do docelowych zbiorów danych oraz jednoosobowy punkt kontaktu z zespołem funkcjonalnym. Jest to niezwykle istotne ze względy na konieczność ciągłego komunikowania konsultantom integracji wszystkich zmian w wymaganiach, jakie powstają jako konsekwencja ciągłego ulepszania konfigurowanych w systemie SAP procesów biznesowych.

Ze względu na wagę tematu i wpływ na powodzenie całego przedsięwzięcia wdrożeniowego, zespół migracji – jako grupa osób zorientowanych wokół wspólnych celów – powinien być zawsze traktowany jako odrębna całość, bez względu na to, że jego członkami mogą być użytkownicy i konsultanci pracujący równolegle w innych zespołach.

Po prostu działa

Efekty dobrej pracy zespołu migracji danych w ramach zorganizowanego projektu będącego częścią większego przedsięwzięcia wdrożenia systemu informatycznego najczęściej będą… kompletnie przezroczyste dla końcowych użytkowników systemu.

Pracując w wymagających warunkach współczesnego biznesu i przetwarzając w systemie kolejne kroki procesów gospodarczych, trudno bowiem zwrócić uwagę na fakt, że system po prostu działa.

Niczym nie zaskakuje kompletna baza klientów i materiałów, a poprawnie podpowiadające się terminy płatności, miejsca dostaw i warunki cenowe nie budzą entuzjazmu. Zupełnie zwykłą rzeczą jest to, że widzimy otwarte pozycje księgowe z faktur wystawionych w poprzednim systemie, że możemy przyjąć zwrot materiałów sprzedanych przy wsparciu poprzedniego systemu informatycznego.

Spokojną kontynuację operacji biznesowych zapewnia sobie na starcie projektu zarząd przedsiębiorstwa, decydując się na organizację dedykowanego projektu migracji danych, towarzyszącemu głównemu projektowi wdrożenia nowego systemu informatycznego.