Hasło „upgrade systemu” często wzbudza niechęć. Kojarzy się z procesem czasochłonnym, dezorganizującym dotychczasową pracę z systemem i wymagającym nakładów finansowych, a w gruncie rzeczy niewiele dającym. Czy tak jest? Czy każdą aktualizację wersji powinniśmy traktować jako „upgrade” i jakie są przesłanki do jego przeprowadzenia? Odpowiadamy!
Czy każdy update to upgrade?
Powyższe pojęcia bywają często mylone, co może powodować nieporozumienia i błędną interpretację. Updatem nazywamy drobną zmianę technologiczną, najczęściej w postaci wgranych patchy (poprawek) dostarczonych przez producenta oprogramowania lub dostawcę usługi utrzymania systemu. Ich zadaniem jest naprawienie występujących błędów albo dodanie nowych funkcji bez konieczności przeprowadzania pełnych testów. Od pewnej (nie zdefiniowanej sztywno) skali wgrywanych poprawek zaczynamy mówić o upgradzie. W związku z brakiem uniwersalnej definicji upgrade’u na potrzeby niniejszego artykułu będą to działania, które na tyle zmieniają działanie systemu, że wymagają pełnego testowania.
Czym się różni upgrade technologiczny od reimplementacji?
Rozróżniliśmy już upgrade od update’u, teraz opiszemy podział upgrade’ów ze względu na cel i sposób ich przeprowadzania.
Upgrade technologiczny (techniczny) można określić jako jednoczesne wgranie dużej liczby poprawek otrzymanych jako gotowa paczka patchy od producenta oprogramowania na posiadane środowisko. Skala zmian jest na tyle duża, że niezbędne jest wytestowanie systemu. Często również niezbędne będzie dostosowanie do nowej wersji modyfikacji lub interfejsów, zbudowanych dla poprzedniej wersji. Przy tym podejściu nie zakładamy jednak: redefinicji kluczowych procesów, zmiany struktury danych, migracji danych.
Reimplementacja oznacza wdrożenie nowej wersji w sposób zakładający zmianę kluczowych procesów, zmianę struktury danych, a co za tym konieczna będzie w projekcie zarówno faza analizy, jak i migracji danych. Czasami będziemy też musieli zaplanować szkolenia dla użytkowników, ma to miejsce, gdy procesy lub system zmienią się na tyle, że użytkownicy mogą sobie sami nie poradzić.
Dlaczego czasem robimy tylko upgrade technologiczny, a nie pełną reimplementację?
Przesłankami do przeprowadzenia reimplementacji mogą być: nowe funkcjonalności dostępne w standardzie nowej wersji, które mogą zastąpić wykorzystywane dotychczas kastomizacje, nowe potrzeby biznesowe (np. potrzeba zmiany planu kont, otwarcie nowego oddziału) lub też ilość lub jakość danych spowodowane długim okresem użytkowania systemu. W sytuacji, gdy przesłanki do zaktualizowania oprogramowania są czysto techniczne (np. brak wsparcia producenta w utrzymaniu danej wersji czy brak zgodności technologicznej pomiędzy wszystkimi komponentami infrastruktury) upgrade technologiczny jest wystarczającym rozwiązaniem.
Poniżej odpowiadamy na często pojawiające się pytania lub niejasności związane z aktualizacją systemów klasy ERP.
- Regularne wgrywanie drobnych aktualizacji, czy rzadsze przeprowadzanie kompleksowych upgrade’ów. Które rozwiązanie jest bardziej korzystne?
Bieżące upgrade’owanie systemu sprawia, że nie narasta dług technologiczny, a testy wprowadzonych zmian przeprowadzane są na bieżąco. Należy również pamiętać, że część wgrywanych patchy nie zmienia nic w codziennym działaniu systemu, ale odpowiada np. za bezpieczeństwo danych, które powinno być priorytetem na każdym etapie pracy z nim. Z punktu widzenia finansowego trudno jest oszacować, które rozwiązanie jest bardziej korzystne. Z całą pewnością można jednak powiedzieć, że duże upgrade’y to duże wyzwanie z punktu widzenia kompetencji i obsługi dużej ilości zmian jednocześnie, co przekłada się na utrudnienie we wsparciu technicznym użytkowników.
- Którą wersję systemu wybrać w momencie startu produkcyjnego?
Niejednokrotnie dyskutowaliśmy z naszymi klientami o tym, którą wersję oprogramowania powinni wybrać na moment go – live[3]. Zawsze podkreślamy, że najnowsza dostępna wersja co prawda zapewnia dłuży okres użytkowania bez konieczności wykonywania aktualizacji, ale jest również wersją najmniej przetestowaną i stabilną. Zachęcamy, aby wchodząc w fazę testów klienci korzystali z najnowszej, dostępnej wersji a następnie użyli jej podczas startu.
- Co dzieje się z danymi podczas reimplementacji?
Podczas reimplementacji mamy do wyboru dwie ścieżki. Pierwszą jest migracja danych, czyli przeniesienie ich ze starego do nowego systemu. Jednak zmiana systemu jest często dobrym pretekstem do uporządkowania nagromadzonych danych więc drugą ściężką, którą możemy wybrać na tym etapie jest ich migracja połączona z czyszczeniem. W tym celu tworzymy skrypty, wyłapujące błędy (np. zdublowany numer NIP lub kontrahent, błędny kod pocztowy), które następnie muszą być automatycznie lub manualne zweryfikowane i uzupełnione.
