Migracja danych do ERP

Migracja danych do wyższej wersji ERP przenosi informacje firmy do nowszego wydania używanego systemu. Przed podjęciem decyzji warto porównać aktualizację z wymianą produktu, bo nowy system może okazać się tańszy¹.
W artykule opisujemy czyszczenie i mapowanie danych, import próbny oraz kontrolę wyniku. W modelowym studium Oracle aktualizacja JD Edwards kosztowała 599 tys. USD, a wymiana na SAP 18,205 mln USD; koszty amortyzowano przez pięć lat².

Czym jest migracja do wyższej wersji ERP i jakie wiążą się z nią ryzyka?

Migracja do wyższej wersji ERP zmienia wydanie używanego systemu, ale ma zachować ciągłość danych i procesów. Nie kończy się na instalacji aktualizacji. Trzeba jeszcze sprawdzić dane, rozszerzenia i integracje. W opublikowanym przykładzie SAP Readiness Check wykrył przed konwersją 8 niezgodnych dodatków, które można było odinstalować³.

Ryzyko migracji ERP dotyczy zarówno poprawności danych, jak i codziennej pracy użytkowników. Nowa wersja może inaczej odczytywać pola lub obsługiwać zmienione procesy. Błędy wykryte dopiero po przełączeniu utrudniają obsługę zamówień, magazynu i księgowości⁴.

Plan migracji powinien rozdzielać testy systemu od przygotowania pracowników. Poprawny wynik testu technicznego nie oznacza, że użytkownik poradzi sobie ze zmienionym interfejsem.
Według badania Prosci cele osiągnęło 88% projektów z doskonałym zarządzaniem zmianą, wobec 13% projektów, w których oceniono je jako słabe⁵.

Jak przetestować nową wersję ERP przed przełączeniem użytkowników?

Nową wersję ERP należy sprawdzić na kopii danych, wykonując rzeczywiste zadania firmy. Testy powinny zakończyć się przed rozpoczęciem bieżącej pracy w nowym środowisku. Subskrypcje Business Central Essentials i Premium obejmują po trzy środowiska sandbox bez dodatkowej opłaty⁶.

• Scenariusze procesów biznesowych prowadzą od utworzenia dokumentu przez zatwierdzenie do zaksięgowania. Właściciele procesów zapisują wynik i każde odstępstwo od oczekiwanego przebiegu.
• Testy integracji sprawdzają przepływ dokumentów między ERP a połączonymi systemami. Zespół kontroluje zarówno wysłanie danych, jak i ich poprawny odczyt po drugiej stronie⁷.
• Testy uprawnień pokazują, czy użytkownicy widzą właściwe dane i mogą wykonać przypisane czynności. Obejmują też działania, które mają pozostać zablokowane.
• Szkolenia pracowników opierają się na zadaniach z ich codziennej pracy. Trudności zgłoszone podczas ćwiczeń trafiają przed przełączeniem na listę poprawek lub do instrukcji⁸.

Przełączenie użytkowników powinno nastąpić po usunięciu błędów blokujących i akceptacji testów przez właścicieli procesów. W opublikowanych kryteriach stanu Michigan wymagano przed uruchomieniem systemu zera otwartych błędów najwyższych poziomów ważności⁹.

Po czym poznać, że obecny system ERP wymaga zmiany?

Obecny system ERP warto poddać ocenie, gdy przestaje stabilnie obsługiwać pracę firmy. Sygnałami są brak wsparcia producenta, kłopoty z aktualizacjami, spadek wydajności i trudne integracje¹. Sam niewygodny interfejs nie uzasadnia jeszcze wymiany: przyczyną może być konfiguracja, rozszerzenie albo ograniczenie produktu.
Standardowe wsparcie podstawowych aplikacji SAP Business Suite 7 kończy się 31 grudnia 2027 r.; opcjonalne wsparcie rozszerzone potrwa do końca 2030 r.¹⁰.

Jakie problemy mogą wystąpić podczas zmiany systemu ERP?

Zmiana systemu ERP może odsłonić błędne przypisania pól, braki w danych i różnice w obsłudze procesów. Niewłaściwa jednostka miary zmienia znaczenie przeniesionej pozycji. Brak powiązania dokumentów utrudnia z kolei odtworzenie historii transakcji. Przerwany przepływ danych do systemów zewnętrznych może zatrzymać pracę również poza ERP.
W przykładzie z dokumentacji SAP jedno opakowanie odpowiada 10 sztukom, więc pomylenie jednostek zmienia przeniesioną ilość dziesięciokrotnie¹¹.

Ryzyko operacyjne rośnie, gdy firma przełącza użytkowników bez wskazania osób odpowiedzialnych za błędy. Potrzebuje też sposobu powrotu do poprzedniego środowiska. Migrację można bezpiecznie zakończyć, kiedy dane, integracje i codzienne zadania spełniają przyjęte kryteria. AWS zaleca, by po zatrzymaniu połączeń ze źródłem potwierdzić opóźnienie replikacji CDC wynoszące 0 sekund¹².

Przygotowanie danych do ERP: czyszczenie, mapowanie i bezpieczny import

Przygotowanie danych do ERP zmniejsza ryzyko przeniesienia błędów do nowej wersji. Obejmuje analizę zbiorów, czyszczenie rekordów, mapowanie pól i kontrolę importu. Przed migracją trzeba usunąć duplikaty, uzupełnić braki i poprawić wartości wpływające na raporty lub operacje finansowe^13,14.

Mapowanie danych łączy pola źródłowe z docelowymi i określa reguły przekształcania wartości. W projekcie Tokai COBEX Polska dotyczącym SAP S/4HANA uporządkowanie danych zmniejszyło listę materiałów o 40%¹⁵. To wynik tego projektu, a nie rezultat, którego można oczekiwać po każdej migracji¹⁶.

Kontrola importu musi sprawdzać coś więcej niż liczbę przeniesionych rekordów. Istotne są powiązania kontrahentów, dokumentów i pozycji magazynowych oraz ich przydatność w codziennej pracy. Błędnego powiązania może nie ujawnić samo zestawienie liczby rekordów¹⁷.

Jak ograniczyć ryzyko przestoju, utraty danych i niezgodności rozszerzeń?

Harmonogram migracji ERP pomaga ograniczyć przestój, jeśli wskazuje okno przełączenia i osoby podejmujące decyzję. Powinien też określać warunki powrotu oraz uwzględniać budżet i rezerwy na nieprzewidziane problemy¹³.
All for One Poland deklaruje przy migracji do SAP S/4HANA metodą Bluefield niedostępność przez 1 weekend. To deklaracja dotycząca tej metody, nie termin obowiązujący w każdym projekcie¹⁸.

• Kopia danych źródłowych zabezpiecza stan systemu sprzed migracji. Zespół zapisuje też sposób odtworzenia danych, gdyby trzeba było przerwać import.
• Test rozszerzeń sprawdza każde używane dostosowanie i jego zależności od nowej wersji. Właściciel procesu zapisuje wynik przed przełączeniem.
• Plan powrotu wskazuje, kto wstrzymuje migrację i jak firma wznowi pracę w dotychczasowym systemie. Zasady tej decyzji trzeba ustalić przed rozpoczęciem pracy na danych docelowych.

Przestój migracyjny łatwiej kontrolować, gdy zespół zna kolejność działań i warunki cofnięcia przełączenia. W procedurze AWS DMS po wstrzymaniu połączeń ze źródłem należy zaczekać, aż opóźnienie CDC wyniesie 0 sekund¹².

Jak bezpiecznie przenieść ERP do chmury?

Przeniesienie ERP do chmury wymaga ochrony danych podczas transferu i kontroli dostępu po uruchomieniu środowiska. Zalecenia obejmują szyfrowanie, ograniczanie uprawnień i monitorowanie aktywności, a po migracji – audyt bezpieczeństwa¹³.
Gwarantowana dostępność SAP S/4HANA Private Cloud dla Tokai COBEX Polska wynosi 99,8%. Ten parametr dotyczy wskazanego projektu^15,16.

• Szyfrowanie danych chroni przesyłane zbiory przed odczytem przez osoby nieuprawnione. Ochrona powinna objąć także pliki pośrednie używane przy imporcie.
• Kontrola dostępu przyznaje dostęp do danych migracyjnych tylko osobom wykonującym przypisane zadania. Po przeniesieniu administrator usuwa uprawnienia tymczasowe¹⁹.
• Audyt bezpieczeństwa sprawdza uprawnienia i ślady aktywności w środowisku docelowym. Może ujawnić dostęp pozostawiony po zakończeniu prac migracyjnych.

Bezpieczna migracja do chmury nie kończy się na ochronie transferu. Wymaga też kontroli środowiska po uruchomieniu. Art. 32 RODO nakazuje dobrać zabezpieczenia do ryzyka przetwarzania danych osobowych, uwzględniając między innymi szyfrowanie i bezpieczeństwo przesyłanych danych²⁰.

Jak wyczyścić, zmapować i zweryfikować dane po imporcie próbnym?

Import próbny danych do ERP sprawdza reguły przenoszenia przed importem całego zbioru. Test na małej próbce pozwala ocenić przebieg migracji, zanim obejmie ona wszystkie dane¹³. Warto uwzględnić rekordy wyjątkowe, na przykład z niepełnym adresem lub nietypową jednostką miary. Według ISTQB pełne pokrycie wymaga przynajmniej jednego testu każdej wyodrębnionej klasy danych, także każdej klasy wartości nieprawidłowych²¹.

• Czyszczenie rekordów usuwa duplikaty i poprawia wartości niezgodne z przyjętymi regułami. Właściciel danych rozstrzyga, który wpis pozostanie źródłem informacji²².
• Mapa pól podaje pole docelowe, format i regułę przekształcenia każdej przenoszonej wartości. Osobno opisuje pola, których znaczenie zmienia się między systemami.
• Kontrola po imporcie próbnym porównuje dane źródłowe z docelowymi i bada powiązania rekordów. Rozbieżności wymagają poprawienia mapowania przed właściwym importem²³.

Import właściwy powinien korzystać z reguł poprawionych po próbie²⁴.

Jak ocenić gotowość obecnego ERP, danych i rozszerzeń do przeniesienia?

Ocena gotowości ERP ustala zakres przenoszenia, zależności między procesami i osoby akceptujące wynik. Inwentaryzacja obejmuje dane, rozszerzenia, integracje oraz zadania wykonywane poza standardowym systemem.

• Wykaz danych wskazuje właściciela każdego zbioru i jego zastosowanie w systemie docelowym. Pomaga oddzielić dane operacyjne od archiwalnych.
• Wykaz rozszerzeń łączy dostosowania z procesami, które z nich korzystają. Dzięki temu wiadomo, jakie funkcje wymagają testu po migracji.
• Decyzja o gotowości wymaga zaakceptowanych danych, działających zależności i usuniętych błędów blokujących. Właściciele procesów zatwierdzają wynik przed przełączeniem.

Gotowość do migracji oznacza, że firma potwierdziła poprawność danych i działanie zależnych od nich procesów. Podstawą oceny mogą być opisane wcześniej kryteria testów akceptacyjnych oraz wyniki importu próbnego.

Migracja do wyższej wersji ERP czy zmiana systemu: wybór strategii

Migracja do wyższej wersji ERP ma sens, jeśli nowsze wydanie obecnego produktu obsłuży wymagane procesy. Zmiana systemu ERP jest uzasadniona, gdy aktualizacja nie usuwa ograniczeń ważnych dla firmy. Tabela porównuje strategie pod względem procesów, danych i nakładu pracy.

Kalkulacja kosztów ERP on-premise i SaaS powinna objąć 3–5 lat, w tym wdrożenie i migrację danych²⁵. Koszt licencji lub subskrypcji trzeba oddzielić od wdrożenia, integracji i utrzymania. Porównanie samych opłat za oprogramowanie pomija prace niezbędne do uruchomienia systemu²⁶.

• Aktualizacja dotychczasowego ERP zachowuje produkt, lecz wymaga oceny zmian w procesach, danych i rozszerzeniach. Nie wystarczy firmie, której kluczowych potrzeb nie obsługuje także nowsze wydanie.
• Wymiana ERP pozwala dobrać produkt do zmienionych procesów, ale wymaga ponownego zaprojektowania przeniesienia danych i integracji. Nie ma uzasadnienia, jeśli aktualizacja obecnego produktu spełnia potrzeby firmy.
• Model utrzymania ERP określa sposób ponoszenia opłat oraz odpowiedzialność za środowisko. Warianty on-premise i SaaS należy porównać dla tego samego zakresu procesów i okresu użytkowania.

Aktualizacja czy zmiana ERP: jak porównać obie możliwości?

Aktualizację i zmianę ERP trzeba ocenić według tych samych wymagań biznesowych. Przy aktualizacji liczą się możliwości nowszej wersji, wsparcie dostawcy, potrzeby pracowników i opłaty za dodatkowe funkcje¹. Te same wymagania powinny obowiązywać przy ocenie zamiennika; funkcje produktu należy oddzielić od usług partnera wdrożeniowego.
W amerykańskim cenniku Business Central plan Essentials kosztuje 80 USD, a plan Premium z dodatkowymi funkcjami produkcji i serwisu 110 USD miesięcznie za użytkownika przy płatności rocznej²⁷.

Porównanie kosztów powinno osobno pokazywać opłaty za oprogramowanie, wdrożenie, integracje i późniejsze utrzymanie. Wynik ma wskazywać nie tylko tańszy wariant. Musi też pokazać procesy wymagające dodatkowych prac.
Przy płatności rocznej Microsoft podaje miesięczne stawki za użytkownika: plan Essentials 80 USD, plan Premium 110 USD i plan Team Members 8 USD²⁷.

Kiedy warto zastąpić obecny system ERP innym?

Obecny system ERP warto zastąpić, jeśli jego aktualizacja nie spełni wymagań wynikających z procesów firmy. Decyzję powinna poprzedzić lista czynności, których użytkownicy nie mogą wykonać w wymagany sposób. Trzeba też ocenić, czy wystarczy zmiana konfiguracji. Wymiana wymaga uzasadnienia, zwłaszcza gdy oznacza ponowne projektowanie integracji i migrację historii danych.

Jak dobrać nowy system ERP do branży, skali i procesów firmy?

Nowy system ERP należy dobierać do przebiegu pracy, wolumenu danych i odpowiedzialności użytkowników. Sama lista modułów nie pokaże, czy produkt pasuje do firmy. Tabela wskazuje procesy, które warto opisać przed oceną produktów.

Każdy rozważany produkt należy ocenić na tych samych scenariuszach. Ocena powinna uwzględniać skalę danych i liczbę osób biorących udział w procesie.

Partner wdrożeniowy odpowiada za oferowane usługi, nie za funkcje produktu producenta. Przy jego ocenie liczą się sposób prowadzenia migracji, podział odpowiedzialności i obsługa integracji używanych przez firmę.

Na jakie ryzyka zwrócić uwagę podczas wdrożenia ERP?

Wdrożenie ERP staje się ryzykowne, gdy firma nie określi procesów ani właścicieli danych. Integracje pominięte w planie również mogą utrudnić uruchomienie. Niejasny podział obowiązków między firmą a partnerem komplikuje rozstrzyganie błędów. Umowa powinna osobno opisywać prace wdrożeniowe, migracyjne, integracyjne i utrzymaniowe.

Wybór strategii ERP powinien wynikać z porównania wymaganych procesów i pełnego zakresu prac w obu wariantach.

Przejście na SAP S/4HANA: jak przygotować dane do przeniesienia?

Migracja z SAP ERP do SAP S/4HANA wymaga wyboru ścieżki i ustalenia, co stanie się z historią danych. Przed uruchomieniem produkcyjnym trzeba też przetestować procesy. SAP ECC jest dotychczasowym systemem ERP, a SAP S/4HANA – systemem docelowym. Tokai COBEX Polska wybrała migrację z SAP ECC zamiast dalszego korzystania z dotychczasowej wersji¹⁵.

Wybór ścieżki migracji zależy od zakresu konfiguracji i historii, które firma chce zachować. Tabela zestawia Greenfield, Brownfield i Bluefield według przygotowania systemu, postępowania z danymi oraz ograniczeń.

Dane w tabeli: 18

Plan prac musi uwzględniać różnice między ścieżkami. Czasów podanych dla innych projektów nie należy traktować jako gwarancji. All for One Poland podaje dla Greenfield 1–3 lata, a dla migracji z SAP ECC metodą Bluefield deklaruje 4–6 miesięcy¹⁸. Organizacjom z wieloma oddziałami źródło zaleca osobne uruchomienia zamiast wspólnego startu¹⁸.

Zakres danych historycznych warto podzielić na dane potrzebne w bieżącej pracy oraz historię do analiz i rozliczeń. Tokai COBEX Polska połączyła konwersję do SAP S/4HANA z ponownym wdrożeniem wybranych procesów¹⁵. Dostęp do historii pozostawionej poza nowym systemem zapewniło połączenie archiwalnego SAP ERP z produkcyjnym SAP S/4HANA i hurtownią SAP BW/4HANA¹⁵. Przy takim podziale trzeba ustalić, skąd użytkownik odczyta dokument historyczny po przełączeniu.

Inwentaryzacja systemów źródłowych pokazuje, czy projekt obejmuje konwersję jednego środowiska, czy również konsolidację. W projekcie opisanym przez All for One Poland połączono 2 systemy SAP ECC w 1 system SAP S/4HANA¹⁸. Każde środowisko źródłowe potrzebuje właściciela danych i reguł rozstrzygania duplikatów.

Harmonogram decyzji firmy nie powinien wynikać wprost z terminów innych projektów. Tokai COBEX Polska uwzględniła planowane zakończenie wsparcia SAP ECC 6.0 w 2027 roku; zbudowanie nowej architektury ERP zaplanowano na 30.03.2020¹⁵. Opis podaje też, że zespół Conversion Factory NTT DATA Business Solutions zrealizował ponad 50 konwersji technicznych. Ta liczba opisuje doświadczenie zespołu, a nie wynik migracji Tokai COBEX Polska^15,16.

Przygotowanie do SAP S/4HANA powinno zakończyć się wyborem ścieżki, zakresu historii i sposobu dostępu do danych po przełączeniu.

Najczęściej zadawane pytania

Czy lista materiałów w projekcie Tokai COBEX Polska zmniejszyła się o 40%?

Tak, taki wynik odnotowano w tym projekcie. Artykuł zaznacza, że nie jest to rezultat gwarantowany przy każdej migracji.

Czy każda migracja SAP S/4HANA metodą Bluefield oznacza tylko jeden weekend niedostępności?

Nie. Jeden weekend to deklaracja All for One Poland dotycząca tej metody, a nie uniwersalny czas przestoju.

Czy dostępność 99,8% jest standardem dla każdego wdrożenia SAP S/4HANA Private Cloud?

Nie. W artykule ten parametr dotyczy projektu Tokai COBEX Polska.

Czy dodatki wykryte przed konwersją zawsze trzeba odinstalować?

Nie wynika to z artykułu. W opisanym przykładzie SAP Readiness Check wykrył niezgodne dodatki, które można było odinstalować; każdy przypadek wymaga oceny.

Czy dobre zarządzanie zmianą gwarantuje osiągnięcie celów projektu ERP?

Nie daje gwarancji. Badanie Prosci przytoczone w artykule pokazuje różnicę w wynikach projektów zależnie od oceny zarządzania zmianą.

Ceny i warunki sprawdzone u źródeł: październik 2026.