Ostatnia aktualizacja: 2026-09-17
- Zidentyfikuj systemy, pliki i właścicieli danych.
- Rozdziel dane podstawowe, konfigurację, otwarte transakcje i historię.
- Zapisz reguły transformacji oraz wyjątki w tabeli mapowania.
- Przetestuj pełny przebieg migracji przed uruchomieniem produkcyjnym.
Zakres i techniczny sposób wykonania prac zależą od systemu źródłowego, platformy docelowej oraz modelu wdrożenia. Uniwersalna pozostaje logika przygotowania: najpierw trzeba ustalić, jakie dane istnieją i do czego będą służyć, a dopiero później budować mechanizm ich przenoszenia.
Od czego zacząć przygotowanie danych do migracji ERP
Przygotowanie danych zacznij od inwentaryzacji źródeł, oceny jakości i ustalenia zakresu. Następne etapy to czyszczenie, mapowanie, migracja próbna oraz walidacja. Każdy z nich opiera się na ustaleniach z wcześniejszych prac: nie da się wiarygodnie opisać transformacji, dopóki nie wiadomo, skąd pochodzą dane i które z nich mają trafić do nowego systemu.[1][4]
- Zinwentaryzuj źródła. Zapisz systemy, arkusze i inne miejsca przechowywania danych objętych projektem.
- Oceń stan danych. Rozpoznaj braki, duplikaty, nieaktualne rekordy oraz niespójne formaty.
- Ustal zakres. Oddziel dane podstawowe, konfigurację, otwarte transakcje, salda i historię.
- Oczyść dane. Zastosuj uzgodnione reguły poprawy oraz obsługi wyjątków.
- Przygotuj mapowanie. Powiąż strukturę źródłową z docelową i opisz wymagane przekształcenia.
- Wykonaj migrację próbną. Przetestuj przebieg importu przed przełączeniem produkcyjnym.
- Zweryfikuj rezultat. Skontroluj dane i ich działanie w procesach biznesowych.
Roboczy rejestr może obejmować nazwę źródła, obszar biznesowy, właściciela, typ danych, wolumen i decyzję o dalszym postępowaniu. Pozwala to odróżnić zasoby gotowe do mapowania od tych, które wymagają poprawy albo decyzji biznesowej.
Zidentyfikuj źródła i popraw jakość danych
Mapa źródeł powinna uwzględniać nie tylko stary ERP, lecz wszystkie wskazane w projekcie miejsca przechowywania danych. Dla każdego źródła trzeba określić jego właściciela, zakres i typ danych oraz ich wolumen. Dopiero na tej podstawie można przeprowadzić profilowanie, czyli ocenę stanu danych przed ich poprawą.[5]
Co uwzględnić w rejestrze źródeł danych
- Źródło i obszar biznesowy, którego dotyczą dane.
- Typ danych, na przykład kartoteki, transakcje, salda lub konfiguracja.
- Właściciel danych oraz osoba zatwierdzająca wyjątki.
- Wolumen i format danych przeznaczonych do oceny.
- Wymagane pola oraz reguły jakości dla danego obszaru.
- Decyzja, czy dane mają być migrowane, poprawione, zarchiwizowane czy wykluczone.
Właściciel danych nie musi być administratorem technicznym. Jego zadaniem w tym procesie jest akceptowanie reguł i rozstrzyganie przypadków, w których korekta zmienia biznesowe znaczenie rekordu. Nazwy ról mogą różnić się między organizacjami, ale odpowiedzialność za decyzje nie powinna pozostawać wyłącznie po stronie zespołu technicznego.[4][6]
Jak rozpoznać duplikaty, braki i niespójne formaty
Profilowanie opisuje stan zbioru, natomiast czyszczenie oznacza jego poprawę. Kontrola powinna wykryć między innymi zdublowane wpisy, nieaktualne rekordy, brakujące wartości i formaty niezgodne z przyjętym standardem. Każda korekta powinna wynikać z ustalonej reguły, a nie z doraźnego poprawiania pliku przed importem.[2][7]
Dla kartoteki można określić wymagane pola, sposób rozpoznawania duplikatów, docelowy format oraz osobę zatwierdzającą przypadki niejednoznaczne. Dzięki temu zespół otrzymuje listę konkretnych problemów i decyzji potrzebnych przed mapowaniem.
Ustal, które dane migrować, a które zostawić poza nowym ERP
Zakres trzeba ustalać osobno dla danych podstawowych, konfiguracji, otwartych transakcji, sald i historii. Dane podstawowe obejmują zwykle takie obiekty jak klienci, dostawcy i produkty, natomiast dokładny zakres zależy od procesów firmy, wymagań nowego ERP oraz decyzji projektowych.[4][6]
| Kategoria lub stan danych | Możliwa decyzja | Warunek decyzji | |||
|---|---|---|---|---|---|
| Dane potrzebne do bieżących procesów | Migrować | Muszą mieć ustalone mapowanie i kryteria akceptacji. | |||
| Dane potrzebne, ale niespełniające reguł jakości | Poprawić przed migracją | Sposób korekty powinien być uzgodniony z właścicielem danych. | |||
Dane podstawowe, otwarte transakcje i historia
Otwarte transakcje i salda trzeba ocenić w kontekście dnia uruchomienia nowego systemu. Dane historyczne nie zawsze muszą trafić do produkcyjnego ERP: część może pozostać w archiwum albo w systemie dostępnym tylko do odczytu. Takiej decyzji nie należy jednak podejmować bez sprawdzenia wymagań operacyjnych, audytowych, podatkowych i retencyjnych.[3][6]
Dane finansowe, w tym salda i rozrachunki, wymagają potwierdzenia przez osoby odpowiedzialne za księgowość. Artykuł nie wyznacza jednego zakresu dla wszystkich firm, ponieważ zależy on od organizacji, sposobu uruchomienia modułów i wymagań dotyczących zachowania dokumentacji.
Dlaczego konfigurację planuje się oddzielnie
Konfiguracja opisuje działanie nowego systemu, na przykład za pomocą walut, kodów podatkowych i parametrów. Nie jest tym samym co kartoteki lub dokumenty pobierane ze źródła, dlatego w planie projektu należy wydzielić ją od danych migrowanych. Zakres i nazewnictwo elementów konfiguracyjnych zależą od wybranej platformy.[4]
Przygotuj mapowanie pól i reguły transformacji
Mapowanie nie kończy się na przypisaniu nazwy starej kolumny do nowego pola. Powinno opisywać także sposób przekształcenia wartości, obsługę wyjątków, wartości domyślne i relacje między rekordami. Jeżeli reguła wpływa na biznesowe znaczenie danych, wymaga zatwierdzenia przez właściciela procesu.[2][7]
Minimalny zakres tabeli mapowania
| Pole źródłowe | Pole docelowe | Reguła transformacji | Obsługa wyjątku | Właściciel decyzji | Status testu |
|---|---|---|---|---|---|
| Nazwa pola w starym systemie | Odpowiednie pole w nowym ERP | Opis wymaganej zmiany formatu lub wartości | Sposób postępowania z rekordem niespełniającym reguły | Rola zatwierdzająca znaczenie reguły | Informacja o wyniku testu |
Co opisać poza nazwą pola
W dokumentacji mapowania należy zapisać konwersje formatów, przypisania słowników, wartości domyślne, zasady łączenia rekordów i sposób obsługi przypadków wyjątkowych. Przy każdej regule powinny być widoczne osoba odpowiedzialna oraz wynik testu.
ETL oznacza proces pobrania, przekształcenia i załadowania danych. Narzędzie realizujące ten proces wykonuje zapisane reguły, ale nie zastępuje decyzji o tym, które dane są prawidłowe i jakie znaczenie powinny mieć po migracji. Nazwy obiektów oraz dostępne mechanizmy importu zależą od platformy; jeśli systemem docelowym jest comarch erp, mapowanie trzeba odnieść do jego struktury i dokumentacji używanej w danym projekcie.
Uzgodniona tabela mapowania staje się wspólnym opisem dla zespołu biznesowego i technicznego. Na jej podstawie można budować import, rejestrować wyjątki oraz sprawdzać, czy konkretna reguła przeszła zaplanowane testy.
Wykonaj migrację próbną przed cutoverem
Migracja próbna powinna możliwie wiernie odtwarzać planowany przebieg importu. Jej zadaniem jest zweryfikowanie kolejności prac, zależności i czasu potrzebnego na działania wykonywane podczas cutoveru, czyli przełączenia produkcyjnego ze starego rozwiązania na nowe.[4][6]
Co mierzyć podczas próby
- Czas eksportu danych ze źródeł.
- Czas transformacji i załadowania zbiorów.
- Czas kontroli wyniku oraz działań wykonywanych ręcznie.
- Moment wystąpienia błędu i etap, którego dotyczy.
- Zależności między importowanymi obiektami i zadaniami zespołu.
Liczba prób i ich zakres zależą od ryzyka, używanych narzędzi, dostępnych środowisk oraz strategii uruchomienia. Test ograniczony do niewielkiej próbki może nie ujawnić problemów związanych z pełnym wolumenem lub wszystkimi zależnościami.
Jak prowadzić rejestr błędów i decyzji
Każdą rozbieżność należy powiązać z przyczyną, właścicielem, sposobem poprawy i decyzją o ponownym teście. Istotna zmiana reguły danych lub transformacji powinna zostać sprawdzona w następnym przebiegu. Dzięki temu plan uruchomienia opiera się na wynikach próby, a nie na niezweryfikowanym założeniu dotyczącym przebiegu importu.
Zweryfikuj dane i odbierz migrację w procesach biznesowych
Poprawny technicznie import nie wystarcza do odbioru migracji. Walidacja powinna obejmować kompletność rekordów, zgodność kluczowych pól, wartości i relacji, a także działanie danych w procesach biznesowych. Sama zgodność liczby rekordów nie potwierdza, że salda, powiązania lub przebieg pracy użytkownika są prawidłowe.[4][8]
Kontrola techniczna i kontrola biznesowa
Kontrola techniczna porównuje między innymi liczność zbiorów, wymagane pola, wartości kontrolne i relacje między rekordami. Kontrola biznesowa odpowiada na inne pytanie: czy zmigrowane informacje nadają się do wykonania działań przewidzianych po uruchomieniu systemu.
- Porównaj liczbę rekordów w uzgodnionym zakresie.
- Zweryfikuj kluczowe wartości, relacje i przypisania słowników.
- Sprawdź obsługę rekordów oznaczonych wcześniej jako wyjątki.
- Zapisz rozbieżności, decyzje i wynik ponownej kontroli.
Testy end-to-end oraz akceptacja użytkowników
Test end-to-end sprawdza pełny scenariusz biznesowy, a nie tylko pojedynczy etap importu. W zależności od procesów firmy może polegać na przejściu od użycia zmigrowanej kartoteki, przez utworzenie dokumentu i zmianę stanu, aż po rozliczenie lub raportowanie. Scenariusze oraz kryteria odbioru należy uzgodnić przed migracją.[6][8]
UAT, czyli test akceptacyjny użytkowników, powinien angażować osoby znające procesy i odpowiedzialne za zatwierdzenie rezultatu. Wymagania finansowe, audytowe i retencyjne trzeba potwierdzić dla konkretnej organizacji. Odbiór następuje więc po potwierdzeniu użyteczności danych w pracy, a nie wyłącznie po komunikacie o zakończeniu importu.
Najczęstsze pytania
Czy trzeba przenosić całą historię dokumentów do nowego ERP?
Nie zawsze. Zakres historii trzeba ocenić pod kątem bieżącej pracy, raportowania, audytu, podatków i zasad retencji. Część danych może pozostać w archiwum lub systemie dostępnym tylko do odczytu, jeżeli pozwalają na to wymagania dotyczące konkretnej organizacji.
Czy zespół IT może sam zdecydować, jak poprawić dane?
Nie w każdym przypadku. Decyzje wpływające na znaczenie danych, klasyfikację rekordów lub obsługę wyjątków powinien zatwierdzać właściciel danych albo procesu. Zespół techniczny może następnie przełożyć uzgodnioną regułę na mechanizm transformacji.
Źródła
- Jak przygotować dane do migracji przy wyborze ERP, zanim zaczniesz wdrożenie, Probiterp.
- Jak przygotować się do migracji danych przy wdrożeniu systemu ERP, QandA.
- Migracja systemu ERP — lista kontrolna: kluczowe strategie prowadzące do sukcesu, SAP.
- Manage configuration and migration data for Dynamics 365 projects, Microsoft Learn.
- Checklist for data management and governance, Microsoft Learn.
- Govern key project areas in your Dynamics 365 implementations, Microsoft Learn.
- An Oracle White Paper, Oracle.
- Guide for User Acceptance Test after Data Migration, Microsoft Learn.
+Artykuł Sponsorowany+
