Pięcioletni serwer ERP zwykle nie przestaje działać nagle. Najpierw wydłuża raporty, potem blokuje użytkowników, później utrudnia zamknięcie miesiąca. Księgowość czeka na zestawienia, sprzedaż denerwuje się przy wystawianiu dokumentów, magazyn widzi opóźnienia przy operacjach, a zarząd słyszy: jeszcze działa, ale lepiej go nie ruszać. To zdanie powinno zapalić czerwoną lampkę. W systemach Comarch, enova365 lub InsERT z bazą SQL stary serwer rzadko jest tylko problemem technicznym. To ryzyko dla finansów, operacji i ciągłości pracy firmy.
Ten tekst jest dla dyrektorów finansowych, operacyjnych i IT, właścicieli firm oraz integratorów IT obsługujących środowiska ERP w organizacjach SMB i mid-market. W takich firmach system ERP nie jest jedną z wielu aplikacji. To miejsce, w którym spotykają się faktury, magazyn, zamówienia, sprzedaż, rozrachunki, raporty i decyzje zarządcze. Jeśli działa wolno, cała organizacja zaczyna pracować wolniej.
Największy błąd polega na traktowaniu migracji jak prostego przeniesienia serwera. Stary sprzęt nie powinien być kopiowany jeden do jednego do nowego środowiska bez diagnozy. Jeśli baza SQL ma źle ustawione zadania, raporty uruchamiają się w godzinach szczytu, integracje odpytują system bez kontroli, a użytkownicy pracują przez niestabilne połączenia, sama zmiana miejsca nie rozwiąże problemu. Może jedynie przenieść bałagan w bardziej nowoczesne opakowanie.
Diagnoza powinna zacząć się od obserwacji pracy firmy, nie od tabelki z zasobami. Kiedy ERP zwalnia najbardziej? Podczas zamknięcia miesiąca, wystawiania faktur, pracy magazynu, importu zamówień, synchronizacji z e-commerce, generowania raportów dla zarządu? Ilu użytkowników pracuje jednocześnie i z jakich lokalizacji? Które integracje są krytyczne, a które tylko wygodne? Takie pytania pozwalają oddzielić rzeczywiste wąskie gardło od objawów widocznych na ekranach użytkowników.
Dopiero potem przychodzi czas na inwentaryzację techniczną. Trzeba opisać wersję systemu ERP, bazę SQL, wielkość baz, zadania cykliczne, integracje z bankowością, sklepem internetowym, systemem magazynowym, drukarkami, terminalami i narzędziami raportowymi. Warto sprawdzić także sposób pracy użytkowników: lokalnie, przez pulpit zdalny, przez VPN, z oddziałów lub z domu. Dla dyrektora finansowego to może brzmieć jak techniczny detal, ale właśnie tu rozstrzyga się, czy migracja będzie kontrolowana, czy pełna niespodzianek.
Prywatna chmura daje sens wtedy, gdy jest zaprojektowana pod procesy firmy. Środowisko dla ERP i bazy SQL powinno uwzględniać stabilność pracy użytkowników, kopie zapasowe, odtwarzanie, bezpieczeństwo dostępu, komunikację z oddziałami i przewidywalny koszt miesięczny. W modelu takim jak prywatna chmura NSIX można zaplanować serwery wirtualne, hosting aplikacji, firewall, VPN, RDS, backup oraz migrację ze starego serwera bez opierania projektu na zgadywaniu parametrów. Kluczowe jest nie to, aby środowisko było największe, lecz aby odpowiadało realnemu obciążeniu i wymaganiom biznesowym.
Plan migracji powinien mieć część testową. Najpierw powstaje kopia środowiska, na której integrator IT i zespół klienta sprawdzają działanie ERP, połączenia z bazą SQL, raporty, wydruki, uprawnienia, zadania automatyczne i integracje. Test nie polega na tym, że aplikacja się uruchamia. To za mało. Trzeba przejść przez typowy dzień pracy: wystawienie dokumentów, przyjęcie magazynowe, raport sprzedaży, import danych, rozrachunki, pracę kilku użytkowników jednocześnie i scenariusz zamknięcia okresu.
Okno migracyjne powinno być decyzją biznesową, a nie tylko techniczną. Dla jednej firmy najlepszy będzie piątek wieczorem, dla innej sobota, a dla kolejnej termin po zamknięciu miesiąca. Przed oknem produkcyjnym trzeba zamrozić określone zmiany, wykonać aktualną kopię, potwierdzić odpowiedzialności, przygotować komunikat do użytkowników i uzgodnić moment, w którym zespół podejmuje decyzję: kontynuujemy albo wracamy do poprzedniego środowiska. Brak takiej granicy często powoduje najdroższe przestoje, bo wszyscy próbują ratować migrację bez jasnego planu.
Scenariusz powrotu nie jest oznaką braku zaufania do projektu. To element profesjonalnej migracji. Jeśli po przełączeniu pojawi się krytyczny problem, firma musi wiedzieć, jak wrócić do pracy i ile danych może utracić. Tu pojawiają się RTO i RPO. RTO określa, jak długo firma może czekać na odtworzenie działania. RPO mówi, jak duża utrata danych jest akceptowalna. Dla księgowości, magazynu i sprzedaży te wartości mogą oznaczać coś zupełnie innego, dlatego nie powinny być ustalane wyłącznie przez IT.
Kopie zapasowe wymagają tej samej precyzji. W ERP nie wystarczy stwierdzić, że kopia istnieje. Trzeba wiedzieć, co obejmuje, jak często powstaje, gdzie jest przechowywana, kto ma do niej dostęp i kiedy ostatnio testowano odtworzenie. W praktyce dopiero test pokazuje, czy firma jest w stanie wrócić do działania po awarii. Bez tego backup bywa bardziej uspokojeniem niż realnym mechanizmem ciągłości.
SLA również powinno wynikać z pracy firmy. Jeśli sprzedaż pracuje od rana do wieczora, magazyn realizuje wysyłki w określonych oknach, a księgowość ma krytyczne terminy, wymagania dla środowiska ERP muszą uwzględniać te rytmy. Nie każda funkcja systemu ma taką samą wagę. Inaczej ocenia się chwilowy brak raportu zarządczego, inaczej brak możliwości wystawiania faktur, a jeszcze inaczej zatrzymanie pracy magazynu.
Koszt starego serwera często jest zaniżany w rozmowach zarządczych. Widać fakturę za serwis, części lub energię, ale nie widać godzin straconych przez użytkowników, ryzyka awarii, presji na integratora, nieplanowanych wizyt, nerwowego odtwarzania i odkładanych aktualizacji. Prywatna chmura nie powinna być sprzedawana jako magiczne lekarstwo. Jej przewaga polega na tym, że pozwala przejść z niepewnego utrzymania starego sprzętu do bardziej przewidywalnego modelu pracy, kosztów i odpowiedzialności.
Dobra migracja ERP nie zaczyna się od pytania, gdzie przenieść system. Zaczyna się od pytania, które procesy nie mogą stanąć i jak szybko firma musi wrócić do pracy po awarii. Jeśli pięcioletni serwer coraz częściej spowalnia Comarch, enova365 lub InsERT z bazą SQL, nie czekaj na moment, w którym przestanie być wybór. Zaplanuj bezpieczną migrację ERP, sprawdź ryzyka, ustal RTO i RPO oraz przygotuj przejście do prywatnej chmury z kontrolowanym przestojem i przewidywalnym kosztem.