Blaski i cienie migracji danych

W większości przypadków migracja stanowi wynik korzystania z przestarzałych systemów, które często nie są już wspierane przez producenta. Wyzwaniami w takich wypadkach są m.in. znalezienie personelu mającego odpowiednie umiejętności do obsługi przestarzałego systemu, przestarzała funkcjonalność powodująca negatywne doświadczenia użytkowników i ograniczająca innowacyjność, niemożność nadążania za rosnącymi wymaganiami dotyczącymi przechowywania danych czy w końcu nieefektywności zwiększające ryzyko utraty danych i zagrożenia bezpieczeństwa.

Jak podejść do migracji danych?

Wydawałoby się, że o migracji danych napisano już wszystko, a mimo to nadal wiele projektów migracji danych przekracza terminy i budżet, co ostatecznie wpływa na transformacje biznesowe, frustrację, a w konsekwencji nawarstwiające się inne problemy wewnątrz organizacji. Zbyt często firmy ignorują pewne subtelne, ale ważne kwestie związane z danymi podczas planowania migracji danych. Brakuje również zrozumienia, czym właściwie jest migracja danych. Ostatecznie migracje danych nie zawsze są w pełni zrozumiałe i często są bardziej złożone, niż się wydaje. Dlatego ważne jest, aby zawsze zaczynać od pytania „dlaczego?”. Jakie są powody biznesowe, potrzeby i konsekwencje migracji wszystkich lub niektórych danych?

Rozważmy kilka kroków, przez które należy przejść, by uniknąć potencjalnych problemów:

1. Przegląd i analiza zakresu migracji

Jednym z powodów opóźnień projektów migracji danych jest rozszerzanie zakresu, które może wystąpić z powodu braku wystarczającej wiedzy o starszej wersji – zwłaszcza danych, interfejsów i systemów. Zespoły projektowe często odkrywają w trakcie procesu nowe elementy, które mogą mieć znaczący wpływ na migrację. Dlatego tak ważne jest, by na początku każdego projektu zrobić tzw. fazę poprzedzającą, która będzie składała się z audytu wcześniejszego środowiska oraz tego, jak będzie się ono zachowywało w nowej rzeczywistości. Przykład: dotychczasowe środowisko było napędzane danymi zewnętrznymi, które odbywało się w ramach serwerów zlokalizowanych w siedzibie organizacji. Przy migracji do chmury trzeba zweryfikować na wstępnej fazie, czy zasilanie zewnętrznymi danymi po migracji do chmury będzie możliwe ze względu na zabezpieczenia wewnętrzne naszej organizacji.

2. Zrozumienie różnic

Ponieważ migracja polega na przenoszeniu danych z jednego systemu do drugiego, ważne jest zrozumienie podobieństw i różnic między systemami dotychczasowymi i docelowymi. Szczególnie ważne jest to, w jaki sposób przechowują i zarządzają danymi oraz jaką natywną funkcjonalność oferują do przetwarzania danych. Pomoże to w mapowaniu źródła do celu, identyfikacji luk w danych i funkcjonalności oraz zdefiniowaniu podejść do usunięcia tych luk. W tym punkcie warto też wspomnieć o tym, jaki jest cel migracji. Przykład: jeżeli migrujemy dane ze starej FK do nowej i próbujemy robić kalkę 1 do 1, może to wywołać więcej problemów niż pożytku po migracji. Wtedy zamiast przerzucać się na nowy schemat działania tkwimy cały czas w poprzednim myśleniu księgowania i generujemy dodatkową pracę (efekt podwójnego myślenia) księgową, controllingową, a w rezultacie nie dostarczamy wiarygodnych danych biznesowych na czas. Efekt? Frustracja i odejścia z pracy pracowników często uznawanych za talenty.

3. Oddziel migrację danych od zmian biznesowych

Częstym błędem popełnianym przez firmy jest łączenie tych dwóch działań. Przykład: jednoczesna migracja danych oraz podział danych na jednostki biznesowe, by lepiej identyfikować nieefektywności biznesu.

Tego typu zmiany biznesowe wymagają komunikacji z użytkownikami, co przyprawia o ból głowy, ponieważ wszelkie problemy będą wymagały dodatkowej komunikacji. Może to mieć negatywny wpływ na organizację, która oprócz migracji danych, zapoznania się często z zupełnie nowym systemem musi jeszcze sprostać oczekiwaniom biznesowym przy nowej alokacji biznesowej. Dlatego wskazane jest oddzielenie zmian biznesowych od migracji danych. Dzięki temu, jeśli projekt się nie powiedzie lub będzie wymagał ponownego zaplanowania, nie musisz o tym informować użytkowników, ponieważ można to zaliczyć do konserwacji systemu. Albo po prostu poczekajmy 2–3 miesiące, gdy będziemy pewni, że migracja się udała, a zespół nabył niezbędną wiedzę w ramach kalki zadań, ale w nowym środowisku.