Migracja danych do nowego systemu – jak ją dobrze zaplanować?

Zmiana systemu niemal zawsze prowadzi do pytania: co zrobić z danymi, które już mamy? Klientami, zleceniami, dokumentami, historią realizacji, kartotekami produktów, cennikami, stanami magazynowymi, kontaktami, notatkami czy załącznikami.

Pierwsza odpowiedź często brzmi: przenieśmy wszystko. To zrozumiałe – dane powstawały przez lata i nikt nie chce ich stracić. Problem w tym, że migracja wszystkiego nie zawsze jest najlepszym rozwiązaniem. Stary system zwykle zawiera nie tylko wartościowe informacje, ale też duplikaty, nieaktualne rekordy, dawne sposoby klasyfikacji, błędne dane i historię, która nie jest już potrzebna do codziennej pracy.

Dlatego dobrze zaplanowana migracja nie zaczyna się od eksportu. Zaczyna się od decyzji: które dane rzeczywiście powinny znaleźć się w nowym systemie i w jakiej postaci?

Migracja to nie kopiowanie bazy danych

Technicznie często da się wyeksportować dużą część informacji ze starego rozwiązania. Nie oznacza to jednak, że wystarczy skopiować je jeden do jednego. Nowy system może mieć inną strukturę. To, co wcześniej było zapisane w jednym polu tekstowym, w nowym rozwiązaniu może być podzielone na kilka konkretnych informacji. Dawny status „w realizacji” może odpowiadać kilku różnym etapom nowego procesu. Klient może występować w starej bazie kilka razy pod różnymi nazwami. Dokument zapisany kiedyś jako załącznik do klienta może teraz powinien być przypisany do konkretnego zlecenia.

Dlatego migracja danych jest w dużej mierze tłumaczeniem starego sposobu pracy na nowy model informacji. I właśnie tutaj najczęściej pojawiają się trudności.

Najpierw ustal, jakie dane są potrzebne po starcie

Nie zaczynaj od pytania „co mamy w starym systemie?”. Lepiej zacząć od pytania: jakich informacji będziemy potrzebowali w nowym systemie pierwszego dnia pracy?

Dla jednej firmy będą to aktywni klienci, otwarte zlecenia, bieżące oferty, produkty i cenniki, niezamknięte reklamacje oraz dokumentacja aktualnych projektów. Dla innej potrzebna będzie również kilkuletnia historia realizacji. Jeszcze inna firma może potrzebować jedynie aktywnych danych operacyjnych, a całą historię zostawić w bezpiecznym archiwum. To zależy od sposobu pracy, wymogów prawnych, potrzeb raportowych i tego, jak często firma faktycznie korzysta ze starszych informacji.

Nie każda historia musi znaleźć się w nowym systemie

To ważne rozróżnienie: dane, które trzeba zachować, nie zawsze trzeba migrować. Można mieć obowiązek przechowywania starych dokumentów albo potrzebować dostępu do historii klientów, ale nie oznacza to automatycznie, że wszystkie te informacje muszą trafić do nowego systemu operacyjnego.

Część danych może pozostać w archiwum. Jeśli firma potrzebuje starej faktury raz na kilka miesięcy, czasem rozsądniej zapewnić bezpieczny dostęp do archiwalnego systemu lub eksportu niż przenosić tysiące historycznych rekordów do rozwiązania używanego na co dzień. Nowy system powinien przede wszystkim pomagać w bieżącej pracy – nie powinien od pierwszego dnia stawać się magazynem całej historii firmy tylko dlatego, że technicznie można ją tam umieścić.

Migracja jest dobrą okazją do porządków

Zmiana systemu bywa jednym z niewielu momentów, kiedy firma naprawdę przygląda się jakości swoich danych. Nagle okazuje się, że ten sam klient występuje pod trzema nazwami. Jedna osoba ma kilka kartotek. Część produktów nie była używana od pięciu lat. W polu „telefon” znajduje się czasem numer telefonu, czasem komentarz, a czasem nic. Niektóre zlecenia formalnie nadal są otwarte, chociaż zostały zakończone kilka lat wcześniej.

Przeniesienie takich danych bez weryfikacji oznaczałoby rozpoczęcie pracy w nowym systemie z dokładnie tym samym problemem. Dlatego przed migracją warto wykonać przynajmniej podstawowe porządki. Nie trzeba ręcznie poprawiać każdej informacji w wieloletniej bazie – trzeba jednak zadbać o dane, które będą dalej aktywnie używane.

Najważniejsze jest ustalenie źródła prawdy

W wielu firmach dane nie znajdują się w jednym miejscu. Lista klientów jest w programie handlowym, dane kontaktowe w arkuszu, aktualne ceny w innym pliku, dokumentacja na dysku sieciowym, status realizacji w systemie produkcyjnym, a dodatkowe informacje w skrzynkach mailowych pracowników.

Wtedy przed migracją trzeba ustalić, które źródło jest właściwe dla konkretnego rodzaju informacji. Jeśli ten sam klient ma inny adres w dwóch systemach, który z nich jest aktualny? Jeśli cena produktu różni się między programem a arkuszem, która obowiązuje? Jeśli kilka plików zawiera różne wersje tego samego zestawienia, który powinien zostać użyty?

Bez takiej decyzji migracja może technicznie zakończyć się sukcesem, ale nowy system zacznie pracę z niepewnymi danymi.

Podziel dane na grupy

W praktyce bardzo pomaga prosty podział.

Dane podstawowe – informacje, bez których trudno rozpocząć pracę: klienci, dostawcy, pracownicy, produkty, usługi, cenniki, słowniki, lokalizacje, typy zleceń.

Dane bieżące – to, co aktualnie znajduje się w realizacji: otwarte oferty, aktywne zlecenia, projekty, zamówienia, zgłoszenia, reklamacje, zadania.

Historia – zakończone procesy: zamknięte zlecenia, stare oferty, dawne projekty, zakończone reklamacje, historyczne ceny i statusy.

Dokumenty i załączniki – osobna kategoria, bo często wymaga innego sposobu migracji niż dane tabelaryczne.

Taki podział bardzo szybko pokazuje, że nie wszystko musi być potraktowane w ten sam sposób.

Szczególnej uwagi wymagają otwarte sprawy

Najtrudniejsze zwykle nie są stare dane ani nowi klienci. Najtrudniejsze są procesy, które znajdują się w połowie realizacji w momencie zmiany systemu. Wyobraźmy sobie zlecenie, które zostało przyjęte w starym rozwiązaniu, jest częściowo wykonane, ma kilka dokumentów i ma zostać zakończone już po uruchomieniu nowego systemu. Co z nim zrobić?

Są dwa podstawowe podejścia: można zakończyć rozpoczęte sprawy w starym systemie i nowe rozpoczynać już w nowym, albo przenieść aktywne sprawy wraz z ich bieżącym stanem. Nie ma jednej odpowiedzi dobrej dla każdej firmy. Ważne jest natomiast, żeby zasada została ustalona przed dniem przełączenia. To dokładnie ten rodzaj decyzji, który warto przygotować podczas analizy przedwdrożeniowej systemu.

Jak zdecydować, co przenosić?

Pomocne są cztery pytania:

• Czy ta informacja będzie używana w bieżącej pracy? Jeśli tak, prawdopodobnie warto ją przenieść.
• Czy będzie potrzebna do podejmowania decyzji lub raportowania? Jeśli firma analizuje historię zakupów klienta albo sezonowość produkcji, część danych historycznych może być bardzo cenna.
• Czy istnieje obowiązek jej przechowywania? Wtedy trzeba zapewnić dostęp, ale nadal nie zawsze oznacza to konieczność importu do głównego systemu.
• Ile będzie kosztowało przygotowanie tej informacji do poprawnej migracji? Czasem przeniesienie bardzo starego i niespójnego zakresu danych wymaga nieproporcjonalnie dużo pracy w stosunku do jego późniejszej wartości.

Migracja powinna mieć uzasadnienie biznesowe, a nie wynikać wyłącznie z zasady „skoro mamy dane, to trzeba je przenieść”.

Najpierw mapowanie, później import

Przed właściwą migracją trzeba ustalić, gdzie każda informacja ma trafić. Przykład: w starym systemie istnieje pole „opiekun”. W nowym systemie może istnieć osobno handlowiec odpowiedzialny za klienta, osoba prowadząca projekt i osoba odpowiedzialna za realizację. Nie można wtedy po prostu skopiować pola do pola – trzeba określić znaczenie starej informacji i przypisać ją do właściwego miejsca w nowym modelu.

To właśnie mapowanie danych. Im bardziej przez lata zmieniał się sposób pracy firmy, tym ważniejszy staje się ten etap.

Uważaj na dane wpisywane ręcznie

Najwięcej niespodzianek pojawia się często tam, gdzie użytkownik mógł wpisać praktycznie wszystko. Przykład: pole „województwo” powinno zawierać jedną z 16 wartości. W praktyce baza może zawierać „opolskie”, „Opolskie”, „OPOLSKIE”, „op.”, „opol.” albo pustą wartość. Człowiek rozumie, że część z tych zapisów oznacza to samo – system niekoniecznie.

Dlatego dane przeznaczone do migracji często wymagają normalizacji. Podobny problem dotyczy numerów telefonów, kodów pocztowych, NIP-ów, nazw produktów, kategorii i wielu innych informacji.

Duplikaty są ważniejsze, niż się wydaje

Jeśli ten sam klient znajduje się w starej bazie trzy razy, można oczywiście przenieść wszystkie trzy rekordy – tylko wtedy nowy system już pierwszego dnia będzie miał trzy wersje tego samego klienta. To wpływa później na raportowanie, historię kontaktów, dokumenty i wyszukiwanie.

Dlatego przed migracją warto określić sposób wykrywania duplikatów. Czasem wystarczy NIP, w innym przypadku potrzebny będzie e-mail, numer klienta albo kombinacja kilku danych. Nie każdą sytuację da się rozwiązać automatycznie, ale nawet częściowe uporządkowanie aktywnej bazy daje dużą wartość.

Zrób migrację próbną

Pierwszy import nie powinien być importem produkcyjnym. Najlepiej wykonać wcześniej migrację testową. Dzięki temu można sprawdzić nie tylko, czy dane zostały technicznie zaimportowane, ale przede wszystkim, czy można na nich normalnie pracować: czy klient ma właściwe dane, czy dokument jest przypięty do odpowiedniego zlecenia, czy status został dobrze przetłumaczony, czy historia jest kompletna, czy raporty zwracają oczekiwane wartości i czy użytkownik może znaleźć informacje, z których korzystał wcześniej.

Próbna migracja często ujawnia problemy, których nie widać podczas samej analizy pliku eksportowego.

Sprawdzaj próbki, ale również liczby

Nie trzeba ręcznie otwierać każdego z kilkudziesięciu tysięcy rekordów. Trzeba jednak mieć sposób na sprawdzenie, czy migracja jest kompletna. Jeśli eksport zawierał 3 416 aktywnych klientów, warto wiedzieć, dlaczego w nowym systemie znajduje się 3 409. Być może siedem rekordów było duplikatami i zostało świadomie połączonych – to w porządku. Problem pojawia się wtedy, gdy nikt nie wie, skąd wynika różnica.

Warto więc porównywać liczbę rekordów, sumy kontrolne, liczbę dokumentów, liczbę aktywnych zleceń, wartości finansowe, stany magazynowe i inne istotne dla procesu wielkości. Dzięki temu test migracji nie opiera się wyłącznie na stwierdzeniu „kilku klientów otworzyliśmy i wygląda dobrze”.

Migracja dokumentów to osobny temat

Pliki często zajmują znacznie więcej miejsca niż same dane i mogą występować w różnych lokalizacjach: w bazie programu, na dysku sieciowym, w folderach poszczególnych pracowników, w chmurze albo jako załączniki wiadomości.

Przed migracją dokumentów warto ustalić przede wszystkim ich docelową strukturę. Nie ma większego sensu przenosić tysięcy plików do jednego miejsca, jeśli po migracji nikt nie będzie potrafił ich znaleźć. Dokument powinien być powiązany z tym, czego dotyczy – klientem, zleceniem, projektem, produktem albo innym właściwym obiektem.

Kto powinien weryfikować dane?

Nie tylko informatyk. Osoba techniczna może sprawdzić, czy pole zostało poprawnie zaimportowane, ale nie zawsze wie, czy jego wartość jest prawidłowa biznesowo. Dlatego do weryfikacji trzeba zaangażować osoby, które rzeczywiście pracują na danych.

Handlowiec najlepiej oceni informacje o klientach i ofertach. Osoba odpowiedzialna za realizację wychwyci problemy ze zleceniami. Magazyn sprawdzi kartoteki i stany. Księgowość albo administracja zauważy błędy, których zespół techniczny może w ogóle nie rozpoznać. Migracja jest elementem wdrożenia, a nie wyłącznie operacją informatyczną.

Ustal moment zamrożenia danych

Przed finalnym importem trzeba zdecydować, co stanie się z danymi zmienionymi między wykonaniem eksportu a uruchomieniem nowego rozwiązania. Jeśli w piątek pobierzemy bazę, a firma do poniedziałku nadal będzie intensywnie pracowała w starym systemie, w międzyczasie powstaną nowe informacje – trzeba je później uwzględnić.

Rozwiązaniem może być krótkie okno bez zmian, kolejny eksport przyrostowy, ręczne przeniesienie niewielkiej liczby zmian albo synchronizacja między systemami. Wybór zależy od wielkości firmy i charakteru procesu. Najważniejsze, żeby nie odkrywać tego problemu dopiero po uruchomieniu.

Zawsze trzeba mieć możliwość powrotu

Przed finalną migracją należy zabezpieczyć źródło – stary system, baza lub pliki powinny mieć kopię umożliwiającą odtworzenie danych. Nie chodzi wyłącznie o sytuację poważnej awarii. Czasem po kilku tygodniach okazuje się, że potrzebna jest informacja, której pierwotnie nie planowano przenosić.

Jeśli źródło zostało zachowane, można do niego wrócić. Jeśli zostało usunięte albo nadpisane, zaczyna się problem. Dlatego archiwizacja starego środowiska jest często równie ważna jak sam import do nowego.

Kiedy migracja jest zakończona?

Nie wtedy, gdy import zakończył się komunikatem „sukces”. Migracja jest zakończona wtedy, gdy firma potwierdziła, że potrzebne dane znajdują się w nowym systemie, mają właściwe znaczenie i można na nich normalnie pracować.

To duża różnica. Techniczne przeniesienie miliona rekordów może potrwać kilkanaście minut. Pewność, że te rekordy zostały poprawnie zinterpretowane, może wymagać znacznie więcej pracy.

Najczęstszy błąd: migracja bez właściciela

Jeśli wszyscy zakładają, że „informatycy przeniosą dane”, łatwo przeoczyć ważne decyzje. Kto ustala, które rekordy są aktywne? Kto decyduje, które duplikaty można połączyć? Kto zatwierdza odwzorowanie statusów? Kto potwierdza poprawność aktywnych zleceń?

Każda ważna grupa danych powinna mieć osobę, która potrafi powiedzieć: „tak, te dane są poprawne i możemy na nich rozpocząć pracę”.

Migracja nie powinna blokować całego wdrożenia

Czasem firmy odkładają zmianę systemu przez lata, bo zakładają, że przed rozpoczęciem trzeba idealnie oczyścić całą historię danych. Nie zawsze jest to konieczne. Można zacząć od aktywnych klientów, otwartych zleceń i podstawowych kartotek, a starsze dane przenieść później albo zostawić je w archiwum.

Tak samo jak całe wdrożenie systemu można przeprowadzić etapami bez zatrzymywania pracy firmy, tak też migracja nie zawsze musi być jednym wielkim przełączeniem.

Jak podchodzimy do migracji w NSF?

Najpierw chcemy zrozumieć, do czego dane będą potrzebne po wdrożeniu. Dopiero później ustalamy, co należy przenieść. Nie wychodzimy z założenia, że największa możliwa migracja jest najlepsza – jeśli firma ma dwadzieścia lat historii, ale do codziennej pracy potrzebuje dwóch ostatnich, warto sprawdzić, czy import całej reszty rzeczywiście ma sens.

Jeśli dane są niespójne, najpierw ustalamy zasady ich uporządkowania. Jeśli część informacji trzeba zostawić tylko ze względów archiwalnych, niekoniecznie umieszczamy je w aktywnym systemie. Celem migracji nie jest przeniesienie jak największej liczby rekordów – celem jest przygotowanie nowego systemu do pracy na właściwych danych.

Najczęstsze pytania