Migracja danych krok po kroku - audyt, testy, plan działania

Migracja danych do nowego systemu IT

Wyobraź sobie pierwszy dzień pracy w nowym systemie IT. Handlowiec loguje się i nie widzi części klientów. Magazyn sprawdza stany i coś się nie zgadza. Raport sprzedaży pokazuje inne liczby niż jeszcze wczoraj. Jesteśmy w momencie, który bardzo często decyduje o tym, czy cały projekt rzeczywiście wystartuje zgodnie z harmonogramem i czy pierwszy dzień pracy w nowym systemie będzie spokojny czy nerwowy.

Mowa oczywiście o migracji danych, bo nawet najlepsza decyzja architektoniczna i najlepiej policzony budżet nie będą miały absolutnie żadnego, żadnego znaczenia, jeśli dane nie przejdą poprawnie. Od migracji zależy:

• czy handlowiec zobaczy swoich klientów,

• czy magazyn zobaczy swoje stany,

• czy księgowość zobaczy dokumenty,

• czy raporty pokażą prawdziwe liczby

• czy zespół od pierwszego dnia będzie mógł pracować normalnie.

Jeżeli jesteś na etapie, kiedy właśnie będziesz już dokonywać migracji albo jesteś świeżo po niej, to ten odcinek jest dla ciebie.

Migracja danych – ostatni test całego projektu wdrożenia systemu

Migracja danych to taki moment, w którym teoria de facto spotyka się z praktyką. To ostatni test całego projektu i całego wdrożenia. Na pierwszy rzut oka migracja wydaje się prosta. Eksport danych, import do nowego systemu i gotowe. Jak to wygląda w praktyce? Eksportujesz dane ze starego systemu. Próbujesz je włączyć do nowego.

I nagle okazuje się, że ten sam klient w starym systemie to występował trzy razy i teraz pytanie, czy go połączyć, czy przenieść te dane tak brzydko, jakby w starym systemie. Adresy są zapisane w różnych formatach. Produkty mają inne identyfikatory w różnych systemach.

Część rekordów jest niekompletna, część danych nie pasuje do nowej struktury w nowym systemie. I dopiero teraz zaczyna się prawdziwa praca, bo przez te 10, 15, 20 lat organizacja tworzy swój własny mikroświat danych. Ktoś kiedyś wpisał klienta jako firma XYZ spółka ZOO, ktoś inny wpisał go jako po prostu XYZ, a ktoś jeszcze inny wpisał po nazwisku osoby, z którą się tam komunikuje.

W starym systemie to jakoś działało. Ludzie wiedzieli, że to ten sam klient. Ale nowy system, on tego wiedział, nie będzie bardzo często.

Migracja danych w systemie gotowym – dopasowanie danych do narzuconej struktury

W systemie gotowym struktura danych jest z góry określona. Masz jakieś określone pola, masz obowiązkowe wartości, masz określone relacje między obiektami. Możesz dodawać własne pola i konfigurować system, ale punkt wyjścia jest zawsze narzucony, szczególnie w rozwiązaniach gotowych.

Twoje dane muszą pasować do struktury, którą zaprojektował producent danego systemu. Projekt danych zaczynasz od tego, co system już przewiduje, od dostępnych pól, od gotowych typów obiektów i też od tego, jak producent zdefiniował klienta, produkt, zamówienie, czy dokument, czy relacje między tymi wszystkimi obiektami. I to oznacza, że twoje dane muszą się w tę strukturę wpisać.

Jeśli dane nie spełniają wymagań, system ich zwyczajnie nie przyjmie i użytkownicy będą się denerwować, bo walidacja będzie pokazywała błędy. Jeśli masz niestandardowy sposób rozliczania klientów, musisz sprawdzić, czy nowy system to przewiduje. Albo jeśli masz specyficzne atrybuty produktów, to musisz je też zmieścić w dostępnych mechanizmach.

Jeśli masz nietypowe zależności między rekordami, sprawdzasz, czy model danych na to pozwala.

Migracja danych w systemie dedykowanym – projektowanie modelu danych pod procesy firmy

W systemie dedykowanym punkt wyjścia jest odwrotny. Najpierw projektujesz model danych pod swoje procesy, dopiero potem budujesz strukturę, która je obsłuży.

I to jest ta fundamentalna różnica przy migracji między systemami gotowymi, a dedykowanymi. W jednym przypadku dopasowujesz dane do systemu, w drugim projektujesz system pod dane i starasz się je też dobrze zunifikować. W obu przypadkach jest jedna rzecz wspólna.

Migracja bardzo często wymusza też porządki. Bo to jest dobry moment, żeby ujednolicić nazewnictwo, usunąć duplikaty, usunąć te brakujące pola, wyrównać formaty dat, różnego rodzaju jednostki, identyfikatory. No i to tutaj zaczyna się ta prawdziwa praca w zaplanowaniu migracji, a potem w jej wykonaniu.

Jak przygotować migrację danych do nowego systemu IT krok po kroku?

To, co polecam Ci zrobić, aby mieć pewność, że migracja systemu na inny system faktycznie przebiegnie pomyślnie, to po pierwsze zacznij od audytu danych. Ale nie rób tego powiedzmy w formie doktoratu.

Audyt danych przed migracją systemu

Chodzi o to, abyś wiedział co mamy, gdzie to jest, w ilu systemach, w jakiej jakości, orientacyjnie, czego brakuje, co jest duplikatem, co jest nieaktualne. Warto też zapytać ludzi w formie wywiadów indywidualnych, jak im się pracuje z danymi, gdzie wiedzą, że mogą na danych polegać, a gdzie niekoniecznie.

Definicja danych podstawowych przed migracją

Następnie przygotuj jedną wspólną definicję danych podstawowych. Zanim cokolwiek przeniesiemy, musimy ustalić, jak nazywamy klientów, jakie pola są obowiązkowe, jak będzie wyglądała struktura różnych danych, na przykład danych produktowych, czym będzie dokładnie ID klienta, jak identyfikujemy zamówienia, jak opisujemy stany magazynowe, czy jakich, nie wiem, jednostek stosujemy i gdzie.

I teraz najważniejsze. Kiedy te zasady są jasno ustalone, ogromną część pracy da się już tutaj zautomatyzować. Czyli zamiast ręcznie poprawiać tysiące rekordów, aby pasowały do tego nowego systemu, czy do nowej struktury danych, prawie automatycznie albo i automatycznie da się je przenieść pod nowy system. To ogromnie skraca czas i koszty owej migracji.

Priorytetyzacja danych - co przenosić przy migracji systemu?

I tu przechodzimy do podpunktu, który naprawdę lubię, czyli do ustalenia priorytetów. Bo w migracji danych najgorsze, co można zrobić, to próbować przenieść wszystko naraz.

Migracja nie polega na tym, żeby skopiować całą przeszłość firmy. Polega na tym, żeby przenieść to, co jest potrzebne, żeby nowy system mógł działać od pierwszego dnia. Resztę można dograć później, albo też nie wszystko przenieść.

I oczywiście to, co musi wejść na start, zależy od tego, jaki system wdrażasz i jakie dane mają dla ciebie tak naprawdę wartość. Mądre podejście do migracji to wybór nie hurtowe kopiowanie wszystkiego, co nazbierało się przez lata. I to właśnie ten wybór skraca migrację, obniża koszty i pozwala wystartować bez względnego chaosu.

Migracja próbna (testowa) – kluczowy etap bezpiecznego wdrożenia

I kiedy już wiemy, co naprawdę chcemy przenieść, a co może spokojnie poczekać, wtedy pojawia się kolejny kluczowy krok. Krok, który wciąż jest w wielu firmach pomijany, a jednocześnie jest jednym z najlepszych narzędzi, jakie masz do dyspozycji przy migracji. Mam na myśli migrację próbną.

Testujesz w bezpiecznych warunkach, żeby zobaczyć, co jeszcze trzeba poprawić na danych. Nie musisz od razu przenosić całych tysięcy produktów, czy wszystkich zamówień z ostatnich kilku lat, chociaż zalecam to zrobić przynajmniej testowo. Na start wystarczy przekrój danych, który odzwierciedla realne przypadki.

Kilka rekordów, kilka trudnych, trochę takich nieidealnych, które mają swoje braki lub niespójności i takie, które pojawiają się w wielu systemach jednocześnie. To pozwala zobaczyć, jak zachowuje się nowy system bez angażowania całej firmy jeszcze na tym etapie przed finalnym wdrożeniem, przełączeniem między systemami. I na tym etapie zostaje nam jeszcze jedna rzecz.

Rollback przy migracji danych – jak zabezpieczyć się przed błędami?

Bardzo prosta, ale niezwykle praktyczna, czyli zadbanie o możliwość szybkiego powrotu do poprzedniego stanu, gdyby pojawiła się taka potrzeba. To standardowa procedura, którą stosuje się w większości dobrze prowadzonych projektów IT. W większości przypadków to po prostu kopia danych ze starego systemu tuż przed migracją, zapis ustawień i konfiguracji oraz możliwość odtworzenia tego stanu w razie potrzeby, czyli zrobienia tzw. rollbacku.

Migracja danych a wybór systemu IT – o czym zapytać przed podpisaniem umowy?

To, co należy przede wszystkim podkreślić, to to, że migracja danych wcale nie jest ostatnim krokiem projektu. To, jak przebiegnie migracja, zależy w dużej mierze od decyzji, które podjęliśmy dużo wcześniej, na etapie wyboru systemu i projektowania struktury danych.

Jeśli wdrażasz system gotowy, musisz wiedzieć, czy twój sposób pracy da się w nim logicznie odwzorować. Pytania, które powinieneś zadać przed podpisaniem umowy, to np.

• czy system obsługuje nasze specyficzne atrybuty danych, pokazując projekt danych, jaki powinien powstać na bazie danych, które masz w obecnym systemie czy systemach.

• Czy możemy zaimportować dane w naszym obecnym formacie, czy musimy je przerobić?

• W jaki sposób musimy je przerobić?

• Jakie są wymagania co do jakości danych?

• Które pola będą obowiązkowe?

• Czy dostawca ma doświadczenie w migracjach z naszego obecnego systemu?

• Czy będzie w stanie się z nim zintegrować?

• Czy miał w tym doświadczenia?

• Kto odpowiada za migrację? My, jako klient, dostawca, czy może partner wdrożeniowy?

• Czy będzie właśnie owa migracja próbna?

Jeśli budujesz system dedykowany, już na etapie projektu musisz wiedzieć, jak te dane mają być odwzorowane w nowym systemie. To znaczy

• analiza obecnej struktury danych jest częścią no de facto discover.

• Model danych projektowany jest pod Twoje potrzeby, ale też z myślą o łatwej migracji.

• Plan migracji powstaje razem z projektem systemu, a nie na końcu przed samą migracją.

Jeśli dostawca mówi to proste, po prostu zaimportujemy dane, to może być czerwona flaga. Dobry dostawca wie, że migracja to raczej jest skomplikowany proces i będzie chciał najpierw zrobić audyt danych.

Jeśli jesteś przed migracją danych albo zastanawiasz się nad zmianą systemu, ale nie masz jeszcze pewności, jak się do tego dobrze przygotować, zacznij od wizji lokalnej. To bezpłatna i niezobowiązująca konsultacja, podczas której przeanalizujemy Twoją sytuację, możliwe scenariusze i realną skalę projektu i zwyczajnie zobaczymy, jak działasz w swojej organizacji na żywo.

Najpierw oddzwonimy, krótko omówimy Twoją sytuację i wspólnie ustalimy, czy i kiedy taka wizja lokalna ma sens w Twoim przypadku.