Migracja systemu w firmie: kiedy i jak?

Migracja systemu, a nawet sama decyzja o niej, nigdy nie jest prosta. Wymaga analizy, zarówno od strony korzyści biznesowych, jak i działu IT w kontekście dalszych możliwości rozwoju oraz utrzymania nowego systemu. Taką decyzję podejmuje się zwykle, gdy nie ma już innego wyboru, bo starego systemu nie daje się już w żaden sposób uratować, innymi słowy nie daje się już go rozwijać, utrzymywać i dostosowywać do zmieniającego się otoczenia biznesowego. 

Migracja systemu to operacja polegająca na transferze danych ze starej struktury na infrastrukturę następcy.  Czasami to ostateczność, a czasami po prostu przemyślany krok ku rozwojowi organizacji. Poznaj najbardziej typowe sytuacje, gdy migracja jest już konieczna:

• Obecny system nie performuje i efektywność pracy z tym systemem nie pozwala rozwijać biznesu;
• Obecnego systemu nie można już rozwijać (brak specjalistów, ograniczenia technologiczne);
• Nie jest możliwe spełnienie odpowiednich wymogów bezpieczeństwa.

Jeśli chcesz poznać 3 najlepsze podejścia i sposoby migracji, czytaj dalej. Część z nich opiszemy szerzej, drugie pokrótce. Wskażemy jakie problemy napotkaliśmy i jak je rozwiązaliśmy. Podpowiemy jakie nastawienie powinna prezentować organizacja.

Migracja etapowa

Rozwiązaniem, które można zastosować, jest migracja etapowa. Jeśli stary system daje taką możliwość, to możemy przenosić go do nowego kawałek po kawałku. Wyobraźmy sobie, że system Legacy ma budowę modułową, którą utożsamiamy razem z procesami. Identyfikujemy moduły, ewentualnie niezależne funkcjonalności, następnie próbujemy je ustrukturyzować i ułożyć plan migracji. Po dobrze wykonanej analizie jesteśmy świadomi, jak powinien przebiegać cały proces i jak możemy go dokładnie zaplanować. W tym przypadku będziemy musieli zaangażować cały zespół jak i BIZNES w proces migracji etapowej. Nie zawsze jesteśmy w stanie zaabsorbować biznes w stu procentach, ponieważ często osoby po tej stronie mają swoje codzienne obowiązki do wykonania.

Ten rodzaj migracji niesie za sobą pewne zalety. Musimy zdawać sobie sprawę, że cały proces będzie trwał dłużej, ale zyskamy nad nim większą kontrolę. Będzie droższy niż migracja jednorazowa, ale mniej wpłynie na wszystkie procesy. W przypadku bardzo dużych monolitów trudno będzie wydzielić konkretne moduły. Jeśli to się nie uda, to możemy spróbować wydzielić poszczególne procesy, funkcjonalności lub podzielić system w inny sposób, patrząc na niego jak na czarną skrzynkę, która posiada wejście-wyjście. Dokładnie analizujemy jakie zestawy danych/parametrów mają być dostarczone na wejściu, aby uzyskać konkretne wyniki/dane na wyjściu. Podejść jest tutaj dużo.

Spójność, integralność

Wspomnijmy, że wymagane jest również ciągłe sprawdzanie spójności między systemami, ponieważ wiele procesów czy modułów będzie się ze sobą zazębiało i część zostanie w starym systemie, a inne fragmenty przejdą do nowego systemu. W pewnych punktach wspólnych, dobrze zidentyfikowanych, będzie można sprawdzać i kontrolować czy ta spójność zachodzi. Proces ten jest trudny do przeprowadzenia w przypadku systemów monolitycznych. Z im większym Legacy mamy do czynienia, tym przeprowadzenie tego typu sprawdzenia integralności będzie stwarzało większy problem.

Podsumowując: proces będzie na pewno kosztowny, czasowo jak i finansowo. Będzie wymagał pracy dwóch systemów: starego i nowego. W zasadzie do momentu, dopóki poprzedni system nie zostanie w pełni zmigrowany.

Migracja do zupełnie nowego systemu

Powiedzmy szczerze, najbardziej drastyczne, najkosztowniejsze i najczęściej najrozsądniejsze rozwiązanie… Wybieramy takie oprogramowanie, które pokrywa nasz obszar biznesowy i ma funkcjonalności, które realizował poprzednik. Tę migrację możemy zrealizować na wiele sposobów, choć stosujemy ją najczęściej, kiedy nie mamy innego wyjścia. Wiąże się to z przeniesieniem, zarówno danych wszystkich procesów biznesowych, ról jak i odpowiedzialności ze starego systemu. Ten wariat wybiera się w szczególności, gdy obecna architektura (często legacy) nie daje się już w rozsądny sposób rozwijać. Dochodzimy do ściany, kończą się już pomysły, nie jesteśmy w stanie dalej rozwijać naszego biznesu. W związku z tym wybieramy z rynku sprawdzony mechanizm do danego obszaru.

Wiemy, że system działa na rynku, został wdrożony u wielu Klientów, dostępni są też specjaliści do jego rozwoju, więc tworzymy projekt i wykonujemy migrację. Mimo że jest ona jednorazowa, nie oznacza, że będzie krótka. Ani tania. Często ten proces jest dość bolesny: przenosimy się na nowy system, wyznaczamy pewną datę odcięcia: obecny przestaje działać, zostaje nam już tylko jego następca. Poprzednik oczywiście może nam posłużyć jako system np. do odczytu, gdzie jeszcze możemy sprawdzić parę funkcji czy danych. Natomiast wszystkie nowe pliki, wyliczenia, procesy dzieją się już tylko i wyłącznie w nowym systemie. Jest to duże ryzyko, ponieważ wszystko, co zostało przeniesione, musi być bardzo dobrze zaprojektowane i przetestowane. Po to, aby od „momentu zero”, nowy system wystartował poprawnie, bez zablokowania procesów biznesowych.

To wymaga bardzo dużego zaangażowania osób z samego biznesu, co często jest bagatelizowane na etapie projektu. W tym wypadku nie można przyglądać się biernie, jak powstaje nowy system – należy brać czynny udział w jego tworzeniu.

„Umarł król, niech żyje król”

Dodajmy, że przynajmniej według nas jest to dość odważne podejście i czasami konieczne. Im większa konieczność upgrade’u, im większy dług technologiczny, tym wyższy jest koszt. Wyobraźmy sobie, że mamy do czynienia z bardzo starym systemem Legacy. Chcemy mieć produkty, które będą w pełni konfigurowalne przez administratora. Niestety system jest bardzo „zahardkodowany” i w zasadzie nie ma możliwości zrobienia tego w obecnej konfiguracji. To są przesłanki do tego, że system nadaje się już do wymiany. Niezależnie od obszaru biznesowego: czy to będą ubezpieczenia, bankowość, czy inna branża.

Migracja systemu do nowszej technologii

Kolejną możliwością, którą zawsze można rozważać, jest przepisanie systemu na nowszą technologię. Nie jest to rozwiązanie tanie i nazbyt powszechne. Zdarzało nam się pracować nad takimi projektami, gdzie następowało przepisanie starego systemu do nowszej technologii. Natomiast trzeba wziąć pod uwagę, że to zawsze dość duże przedsięwzięcie. Wymaga najczęściej zaangażowania dwóch zespołów: jednego, który zna stary system dość dobrze, i drugiego, który ma wiedzę o nowej technologii. Taka operacja jest długa, wymaga dokładnego zaplanowania i zaprojektowania wszystkich faz całego przedsięwzięcia. Może to być proces, który będzie wymieniał system od razu w całości lub też zastępował kolejno poszczególne funkcjonalności biznesowe. Na koniec i tak zawsze zostaje migracja danych, którą w mniejszym lub większym stopniu należy wykonać.

Migracja systemu: założenia i efekty

W przypadku migracji, problemy zawsze się gdzieś znajdą. Chociażby przez to, że przeniesione między systemami dane nigdy nie pasują do siebie w stu procentach. Części będzie brakowało, a inne fragmenty trzeba po prostu uzupełnić z zewnątrz lub wypełnić danymi domyślnymi. Napotkamy procesy, które powodują, że system nie będzie w pełni funkcjonalny, a nowy proces nie będzie odzwierciedlał w 100% starego. Oczywiście będzie on spełniał podstawowe wymagania biznesowe, bo musi – inaczej migracja nie miałaby sensu i należałoby się cofnąć do starego systemu. Natomiast, po wdrożeniu są zawsze jakieś problemy, które „wychodzą” w trakcie użytkowania i trzeba je szybko poprawić. Bo praktycznie zawsze da się to zrobić.

Bardzo częstym scenariuszem jest pozostawienie jeszcze przez jakiś czas działającego starego systemu, nawet po pełnej zakończonej sukcesem do nowego systemu. Oczywiście w zależności od oprogramowania, przejście musi nastąpić z dnia na dzień, aby nie było sytuacji, że dane trafiają zarówno do nowego jak i starego systemu w sposób niezamierzony. Przykładem mogą tu być systemy księgowe. Powodowałoby to ogromny bałagan w danych a czasem nawet konieczność powtórnej migracji danych.

Natomiast jeżeli mówimy o wewnętrznym rozwiązaniu: zazwyczaj aplikacje działają i są utrzymywane równolegle. Przy pewnych kluczowych procesach biznesowych rzeczywiście tak się dzieje. Dla bezpieczeństwa i sprawdzenia poprawności danych klient decyduje się na utrzymywanie obu systemów jeszcze przez jakiś czas. Chce sprawdzać, czy nowe wyliczenia i procesy w systemie rzeczywiście zachowują się tak samo i dają te same wyniki co wcześniej. Czasami stary system przełączany jest w tryb „read only” i służy tylko jako referencja, bo nikt już nie wprowadza tam nowych danych i w sumie nie powinien, jeśli migracja została zakończona

Nasze doświadczenia

Realizowaliśmy taki projekt, gdzie proces przenoszenia danych był bardzo specyficznie podzielony. Cała migracja, która była zaplanowana na uruchomienie nowego systemu, odbywała się w weekend, a od poniedziałku nowy system ruszał produkcyjnie. Natomiast nie dotyczyło to wszystkich danych. Duża część, która była zaklasyfikowana przez Klienta jako „stare” i niepotrzebne do bieżących prac biznesowych została rozłożona w czasie na kilkanaście dni, już po wdrożeniu nowego systemu. Pliki były sukcesywnie każdej nocy domigrowywane, tak jak to było zaplanowane. W przypadku systemów bankowych mieliśmy sytuacje, gdzie faktycznie dostępne były dwa systemy, a Klienci byli migrowani do nowego systemu etapami.

Podsumujmy sobie to, co już zostało wymienione wyżej. Migracja systemu to proces kosztowny i czasochłonny. Będzie wymagała zaangażowania wielu osób, nie tylko stałego zespołu projektowego, ale również, w szczególności, biznesu. Musimy mieć świadomość, że nie przerzucamy danych z systemu A do systemu B, a potem wszystko działa. Będą one musiały zostać poddane pewnym transformacjom. Nowe oprogramowanie czasami będzie wzbogacone lub wypełnione tylko danymi, których ten nowy system wymaga i nie muszą to być treści istotne dla procesów biznesowych. Systemy są różne i operacje w nich mogą przebiegać inaczej. Wszystkich danych nie da się odwzorować 1:1. Chyba że, mamy do czynienia z przepisaniem starego systemu na nowy, gdzie takie projekty również przeprowadziliśmy. Tak naprawdę rozwiązania różniły się tylko wizualnie, bo wszystkie funkcjonalności i dane musiały być zmigrowane „jeden do jednego”.

Odpowiednie nastawienie organizacji do migracji

Warto zwrócić uwagę, że bardzo często nowości są wrogiem użytkowników, ponieważ muszą oni nauczyć się nowego systemu. Będzie on przecież funkcjonował trochę inaczej od poprzedniego: nie wszystkie procesy będą działały tak samo, ścieżki przejścia w różnych etapach procesu będą inne. Zdarza się, że wzbudza to niechęć użytkowników, gdyż byli przyzwyczajeni do pewnych zachowań, które znali na pamięć. Natomiast nowy system nie będzie im tego zapewniał, dopóki się go nie nauczą.

Zawsze znajdzie się grupa użytkowników, dla których nowe rozwiązanie stanie się „wrogiem”. Narzekają i rozsiewają plotki, że wdrażany system do niczego się nie nadaje, ten stary był taki super i tak dalej… Trzeba z tym walczyć, ponieważ rozbija to motywację zespołów, które nad tym pracują. Wielce prawdopodobne jest, że nowy system po kilkunastu miesiącach, gdy zostanie dobrze rozpoznany przez Użytkowników, będzie w wielu aspektach dużo wygodniejszy niż poprzednik.

Jak możemy podejść do migracji do nowego systemu?

Najlepszym rozwiązaniem, jeśli nie mamy zbyt dużych doświadczeń w tego typu działalności i brakuje nam specjalistów, jest po prostu wybór firmy doradczej do migracji, a potem utrzymania systemu. Istotną sprawą jest precyzyjne zaplanowanie całego procesu i uznanie przedsięwzięcia za milowy projekt. Rozpiszmy plan „co do minuty”, ponieważ sam proces wykonania migracji danych z jednego systemu do drugiego, będzie odbywał się najczęściej podczas »kluczowego weekendu«, a w harmonogramie to tak naprawdę chwila. Nie możemy dopuścić do sytuacji, że zaczynamy migrację, dajmy na to, w sobotę rano, a ona do poniedziałku się nie skończy. Przygotowanie dokładnego roll out planu w tym wypadku to podstawa.

Ważną rzeczą jest szkolenie użytkowników kluczowych. Oczywiście najlepiej, gdyby udało się przyuczyć wszystkich użytkowników, którzy będą korzystali z tego systemu. Jednak bardzo często ze względu na inne obowiązki, które wykonują, nie będzie to możliwe. Najczęstszym rozwiązaniem jest edukacja użytkowników kluczowych, którzy później propagują tę wiedzę i przekazują ją pozostałym użytkownikom.

Podsumowanie: ważne jest zaangażowanie

Ważną, a może najważniejszą sprawą, jest tutaj zaangażowanie zarówno biznesu jak i kierownictwa. Chodzi o to, żeby wszelkiego rodzaju spory czy kwestie otwarte rozwiązywać jak najszybciej. Nie możemy czekać z pewnymi sprawami, aż projekt się skończy albo aż dotrzemy do konkretnego kamienia milowego. Wtedy to już jest „pożar”: coś wybucha i staje się to krytyczne dla całego projektu. Jak wspomnieliśmy: decydenci nie mogą tylko stać biernie z boku i się przyglądać, muszą być w tym procesie szczególnie aktywni. Wszyscy, a przede wszystkim zainteresowani, muszą być dobrze informowani na każdym etapie, aby uniknęli dezorganizacji wynikającej właśnie z dezinformacji. Aby sprawniej zarządzać, angażować ludzi oraz informować o stanie projektu dobrym sposobem jest utworzenie Komitetu Projektowego, który będzie odbywał częste cykliczne spotkania, na których będą podejmowane kluczowe decyzje przez osoby decyzyjne.

Proces migracji to ogromne wyzwanie dla każdej organizacji, jednakże świadomość wymaganego wysiłku i kosztów pozwali spojrzeć w przyszłość z nadzieją. Każde usprawnienie to praca przyjemniejsza, wygodniejsza, generująca mniej sytuacji stresowych. Przecież wynik zależy od wprowadzonych danych, nieprawdaż?

Krzysztof Skowerski
Paweł Szutowicz
Tomasz Turmowicz