Przejście na nowy system IT bez wstrzymywania pracy firmy: etapami czy jednorazowo?
Kiedy obecny system zaczyna hamować rozwój firmy, pojawia się potrzeba zastąpienia go nowym rozwiązaniem. Jednak gdy od starego systemu zależą sprzedaż, realizacja zamówień i obsługa klientów, zmiana wcale nie jest prosta. Co, jeśli przejście na nowy system zakłóci codzienną pracę i utrudni wywiązywanie się ze zobowiązań?
Zależnie od sytuacji zespół lub dostawca może zaproponować migrację etapową albo jednorazową. Każda z tych strategii wiąże się z innymi kosztami i ryzykiem. W tym artykule pokazujemy, jak ocenić taką rekomendację i jakich dowodów gotowości oczekiwać. Wyjaśniamy też, co powinien uwzględniać plan migracji, żeby ograniczyć zakłócenia pracy firmy i przygotować ją na ewentualne problemy.
W skrócie
|
Czym różnią się migracja etapowa i jednorazowa?
Migracja etapowa polega na stopniowym przenoszeniu obsługi kolejnych grup użytkowników lub procesów ze starego systemu do nowego. Przez pewien czas oba systemy działają równolegle. Przy migracji jednorazowej obsługa wszystkich użytkowników i procesów objętych migracją zostaje przeniesiona do nowego systemu w jednym zaplanowanym terminie.
Obie strategie wiążą się z ryzykiem zakłócenia pracy firmy. Wybór zależy między innymi od tego, czy można bezpiecznie rozdzielić obsługę procesów między systemy oraz ile będzie kosztować ich równoległe utrzymywanie.
Określ warunki biznesowe i wymagaj uzasadnienia rekomendacji
Określ, które działania firmy muszą być kontynuowane podczas migracji, a które można czasowo ograniczyć. Chodzi na przykład o przyjmowanie zamówień, realizację dostaw czy obsługę klientów. Ustal dopuszczalny czas takich ograniczeń i oceń ich wpływ na przychody oraz możliwość wywiązania się ze zobowiązań.
Zespół lub dostawca powinien przeanalizować, jak każda ze strategii wpłynie na pracę firmy. Do niego należy sprawdzenie zależności między systemami, przepływu danych i ryzyka błędów. Oczekuj jasnej informacji o skutkach biznesowych: co może przestać działać, kogo dotkną problemy i ile potrwa przywrócenie obsługi.
Wymagaj porównania obu strategii pod względem kosztów, wpływu na działalność firmy i ryzyka. Zespół powinien uzasadnić, dlaczego rekomendowane rozwiązanie najlepiej spełnia ustalone warunki biznesowe.
Kiedy migracja etapowa jest uzasadniona?
Migracja etapowa pozwala sprawdzić nowe rozwiązanie na mniejszej grupie użytkowników lub wybranym procesie, zanim obejmie kolejne części firmy. Dzięki temu może ograniczyć skutki błędów. Wymaga jednak ustalenia, za obsługę których użytkowników i procesów będzie odpowiadał każdy z systemów. Trzeba też określić, jak oba systemy będą współpracować, żeby firma mogła kontynuować codzienną pracę.
Jeśli zespół zarekomenduje migrację etapową, poproś o wyjaśnienie tych czterech kwestii:
- Zakres etapów. Którzy użytkownicy lub które procesy zostaną przeniesione najpierw? Jak zostanie zapewniona ciągłość procesów, których część będzie obsługiwana w nowym systemie, a część nadal w starym?
- Podział zadań między systemami. Który system będzie wykonywał poszczególne operacje i zapisywał ich wyniki? Podział musi zapobiegać pomijaniu lub podwójnemu wykonywaniu tych samych operacji.
- Synchronizacja danych. Jak zmiany zapisane w jednym systemie trafią do drugiego? Jak zespół zapobiegnie utracie danych, duplikatom i rozbieżnym statusom?
- Wycofanie etapu. Jak zespół przywróci obsługę w starym systemie, jeśli pojawią się problemy? Co stanie się z danymi i operacjami zapisanymi już w nowym?
Zespół powinien rozpocząć kolejny etap dopiero wtedy, gdy testy i obserwacja działania nowego systemu w dotychczasowym zakresie potwierdzą, że procesy przebiegają poprawnie, a użytkownicy mogą wykonywać codzienną pracę.
Takie podejście wymaga dodatkowej pracy przy integracjach i synchronizacji danych. Przez okres przejściowy trzeba też utrzymywać oba systemy. Przed zaakceptowaniem strategii zapytaj, jak długo potrwa ten okres i jakie dodatkowe koszty poniesie firma.
Kiedy migracja jednorazowa jest uzasadniona?
Jednorazowe przeniesienie obsługi procesów biznesowych do nowego systemu może być rozsądniejsze, gdy procesy i dane są ze sobą silnie powiązane. Rozdzielenie ich między dwa systemy na czas migracji wymagałoby wtedy kosztownych zmian lub zwiększałoby ryzyko błędów. Dotyczy to na przykład sytuacji, w której trudno zapewnić zgodność danych potrzebnych obu systemom do obsługi zamówień.
Przed zatwierdzeniem migracji jednorazowej upewnij się, że zespół uzasadnił jej wybór i przygotował plan ograniczenia skutków przerwy w pracy firmy. Sprawdź cztery kwestie:
- Uzasadnienie wyboru. Co konkretnie utrudnia migrację etapową? Jakie dodatkowe koszty i ryzyko wiązałyby się z równoległym działaniem obu systemów?
- Przerwa w dostępności systemu. Jakie działania firmy zostaną ograniczone i na jak długo? Jak firma będzie w tym czasie obsługiwać klientów i realizować zobowiązania?
- Warunki rozpoczęcia i wstrzymania migracji. Co zespół sprawdzi przed rozpoczęciem prac i udostępnieniem nowego systemu użytkownikom? Jakie problemy będą wymagały wstrzymania migracji i kto podejmie tę decyzję?
- Powrót do starego systemu. Jak długo potrwa przywrócenie jego działania i spójności danych? Kiedy najpóźniej trzeba będzie podjąć decyzję o powrocie, żeby zmieścić się w dopuszczalnym czasie przerwy?
Błąd może dotknąć wszystkich użytkowników i procesów objętych migracją. Dlatego plan musi uwzględniać również scenariusz niepowodzenia. W zaakceptowanym czasie przerwy musi zmieścić się zarówno nieudana próba migracji, jak i powrót do starego systemu wraz z przywróceniem spójności danych.
Przykład: dlaczego wybraliśmy migrację jednorazową
Pracowaliśmy nad systemem logistycznym obsługującym codziennie tysiące przesyłek. Korzystali z niego pracownicy magazynów, koordynatorzy i kurierzy.
Początkowo chcieliśmy przeprowadzić migrację kluczowych elementów systemu etapami. Były one jednak tak silnie powiązane, że przygotowanie architektury do równoległego działania obu systemów zajęłoby więcej czasu niż migracja jednorazowa. Oznaczałoby też dodatkowe koszty i większą złożoność prac.
Zdecydowaliśmy więc o jednorazowej migracji tych elementów. Przed właściwą migracją przeprowadziliśmy jej pełną próbę i przetestowaliśmy procedurę powrotu do starego systemu, aby w razie problemów móc przywrócić jego działanie i spójność danych.
Jakich dowodów gotowości wymagać przed migracją?
Przed zatwierdzeniem terminu migracji wymagaj wyników prób oraz informacji o wykrytych problemach i sposobie ich rozwiązania. Samo zapewnienie, że „testy przeszły”, nie wystarczy do podjęcia decyzji. Zespół powinien wykazać, że wyniki spełniają ustalone warunki rozpoczęcia migracji, oraz wskazać, jakie ryzyko nadal pozostaje.
Czy testy potwierdzają gotowość do codziennej pracy?
Wyniki testów powinny potwierdzać, że użytkownicy będą mogli wykonywać w nowym systemie swoje zadania od początku do końca. W przypadku obsługi zamówień oznacza to sprawdzenie całego procesu: od przyjęcia zamówienia, przez płatność i realizację, po aktualizację statusu oraz rozliczenie.
Wymagaj też potwierdzenia, że system poprawnie obsłuży sytuacje, w których coś pójdzie nie tak. Czy brak odpowiedzi operatora płatności nie spowoduje utraty zamówienia? Czy ponowienie płatności nie doprowadzi do podwójnego obciążenia klienta? Czy zwrot środków zostanie poprawnie zapisany w rozliczeniach?
Testy powinny uwzględniać typowe i szczytowe obciążenie systemu oraz sprawdzenie zgodności danych w połączonych systemach. Pozwoli to ocenić, czy przy rzeczywistej skali operacji nie będą ginąć zamówienia, powstawać duplikaty lub pojawiać się rozbieżne statusy.
W testach powinni uczestniczyć także użytkownicy wykonujący te zadania na co dzień. W naszym projekcie logistycznym część problemów wykryliśmy dopiero po udostępnieniu aplikacji kurierom do testów.
Czy próbna migracja potwierdza wykonalność planu?
Próbna migracja pozwala sprawdzić, czy zaplanowane działania da się wykonać w przewidzianym czasie i czy dane zostaną poprawnie przeniesione. Żeby jej wyniki były miarodajne, zespół powinien odtworzyć warunki właściwej migracji: infrastrukturę, konfigurację, integracje i skalę danych. Następnie powinien wykonać wszystkie zaplanowane kroki w tej samej kolejności, zmierzyć czas i zweryfikować przeniesione dane. Dane wykorzystane w próbie muszą być odpowiednio zabezpieczone, a ich użycie zgodne z wymaganiami dotyczącymi prywatności.
Zapytaj, ile trwała próba i czy po usunięciu wykrytych błędów zespół ponownie sprawdził poprawione kroki. Dzięki temu ocenisz, czy przewidywany czas ograniczonej dostępności systemu ma oparcie w wynikach, a nie tylko w szacunkach.
Czy zespół przećwiczył działania na wypadek awarii?
Poproś o wyniki testów procedur awaryjnych: czy zespół wykrył problem, czy wyznaczona osoba podjęła na czas decyzję o wstrzymaniu migracji i czy udało się przywrócić obsługę. Sama instrukcja postępowania nie potwierdza, że uda się ją wykonać pod presją czasu.
Testy powinny objąć również pracę osób odpowiedzialnych za obsługę klientów i realizację zamówień. Czy otrzymają na czas informację o awarii i instrukcje dalszego działania? Czy będą wiedzieć, co zrobić ze sprawami rozpoczętymi przed wystąpieniem problemu?
Wymagaj potwierdzenia, ile trwało przywrócenie działania systemu i spójności danych oraz jakie braki zostały ujawnione. Przed migracją zespół powinien usunąć wykryte braki i ponownie przetestować poprawione procedury.
Co powinien zawierać plan migracji, który zatwierdzasz?
Plan powinien określać, kto wykona poszczególne działania, w jakiej kolejności i na jakiej podstawie zespół podejmie kolejne decyzje. Musi też uwzględniać pracę osób odpowiedzialnych za realizację zamówień, obsługę klientów i komunikację.
Przed zatwierdzeniem planu sprawdź, czy zawiera te pięć elementów:
- Zakres migracji i zależności. Które procesy, dane i integracje obejmą zmiany? Jakie powiązania między systemami wpływają na kolejność prac?
- Kolejność działań i odpowiedzialność. Każdy krok powinien mieć przypisaną osobę odpowiedzialną, oczekiwany wynik i sposób potwierdzenia wykonania. Plan musi też wskazywać, kto koordynuje całość i podejmuje decyzje o rozpoczęciu lub wstrzymaniu prac.
- Termin i organizację pracy firmy. Harmonogram powinien uwzględniać aktywność użytkowników, terminy kluczowych operacji i dopuszczalne ograniczenia dostępności systemu. Plan musi określać, jak w tym czasie będą obsługiwani klienci oraz kto, kiedy i o czym poinformuje klientów, pracowników i partnerów.
- Warunki rozpoczęcia, wstrzymania i zakończenia migracji. Wymagaj zapisania konkretnych kryteriów rozpoczęcia, wstrzymania i zakończenia migracji. Powinny obejmować wymagane przygotowania, dopuszczalny poziom błędów oraz sposób potwierdzenia, że dane są poprawne, a procesy działają.
- Procedurę awaryjną. Plan powinien zawierać instrukcję przywrócenia działania systemu i spójności danych oraz wskazywać potrzebne wersje aplikacji i kopie zapasowe. Musi określać osobę uprawnioną do podjęcia decyzji o powrocie, najpóźniejszy moment tej decyzji i czas wykonania procedury.
W projekcie, który wcześniej przytaczaliśmy jako przykład, każdy krok miał przypisaną konkretną osobę. Nie rozpoczęliśmy migracji, dopóki osoby odpowiedzialne nie potwierdziły zakończenia wszystkich przygotowań, w tym wykonania kopii zapasowych i poinformowania klientów oraz administratorów. Termin przerwy wybraliśmy na podstawie analizy aktywności poszczególnych grup użytkowników.
Czy bezpieczna migracja oznacza opłacalną inwestycję?
Nawet dobrze przygotowany plan migracji nie przesądza o tym, że przepisanie systemu będzie uzasadnione biznesowo. Jeśli dopiero rozważasz taką inwestycję, porównaj jej koszt i spodziewane korzyści z dalszym rozwojem obecnego rozwiązania.
Kalkulator opłacalności przepisania systemu pomoże oszacować koszt i czas realizacji planowanych zmian w starym oraz nowym systemie. Uwzględnia on koszt odtworzenia potrzebnych funkcji, zakres przepisywania i zakładane tempo dalszego rozwoju.
Jeśli analiza uzasadnia inwestycję, sprawdź, jak w Pragmatic Coders podchodzimy do przepisywania systemów legacy, w tym przenoszenia danych, odtwarzania integracji i zapewnienia ciągłości obsługi procesów biznesowych.
Podsumowanie: zatwierdź strategię na podstawie dowodów
Wybierz strategię, której koszty, ryzyko i wpływ na działalność firmy mieszczą się w ustalonych granicach. Od zespołu wymagaj uzasadnienia rekomendacji, wyników testów oraz planu wykonania migracji i działania w razie problemów.
Zatwierdzenie strategii nie oznacza jeszcze zgody na rozpoczęcie migracji. Tę decyzję podejmij dopiero wtedy, gdy wyniki prób potwierdzą spełnienie ustalonych warunków gotowości.
