Jak przygotować dane do migracji przy wyborze ERP, zanim zaczniesz wdrożenie

Dlaczego przygotowanie danych przed wyborem ERP decyduje o sukcesie wdrożenia

Nowy system ERP ma usprawnić procesy, dać lepszą kontrolę nad firmą i uwolnić od „życia w Excelu”. To się jednak nie wydarzy, jeśli do systemu trafią chaotyczne, niespójne i niepełne dane. ERP nie jest czarodziejską gumką do bałaganu – on ten bałagan tylko utrwali i pomnoży.

Przygotowanie danych do migracji przed wyborem ERP to tak naprawdę przygotowanie gruntu pod całe wdrożenie. Im wcześniej zaczną się prace porządkowe, tym krócej będzie trwać sam projekt i tym mniej nerwów stracą użytkownicy. Migracja danych ERP to jeden z najczęstszych powodów opóźnień, a jednocześnie obszar, który firmy najczęściej odkładają „na później”.

Na etapie wyboru systemu łatwo skupić się na funkcjach, demo i ofertach. Tymczasem to, czy system będzie działał sensownie w realnym środowisku, zależy wprost od jakości danych, które do niego trafią. Można idealnie dobrać rozwiązanie, a i tak „położyć” wdrożenie, jeśli do bazy nowych klientów, produktów czy stanów magazynowych przeniesione zostaną stare błędy, duplikaty i luki.

Różnica między „mamy dane” a „mamy dane gotowe do migracji” jest kolosalna. W pierwszym przypadku mowa o tym, że firma posiada jakieś informacje: w starym systemie, w Excelach, na dyskach sieciowych, czasem w głowach pracowników. W drugim: dane są zebrane, opisane, wyczyszczone, ujednolicone i można je bez większych niespodzianek załadować do nowego ERP. To właśnie ten drugi stan powinien być celem jeszcze przed podpisaniem umowy wdrożeniowej.

Jakość danych bezpośrednio wpływa na czas wdrożenia i koszty. Jeśli porządkowanie danych zacznie się dopiero w trakcie projektu, konsultanci wdrożeniowi będą czekać na pliki, użytkownicy będą poprawiać kartoteki po godzinach, a kierownictwo będzie pytać, dlaczego „to tak długo trwa”. Dobrze przygotowana migracja danych ERP skraca prace konfiguracyjne, ułatwia testy i pozwala szybciej przejść do realnego korzystania z systemu.

Punkt startu – jak realnie ocenić stan danych w firmie

Gdzie siedzą dane w typowej firmie

Ocena stanu danych zaczyna się od prostego pytania: gdzie w ogóle są nasze dane. W większości firm odpowiedź brzmi: wszędzie. Fragmenty leżą w obecnym systemie finansowo-księgowym, inne w systemie magazynowym, jeszcze inne w CRM, a reszta w dziesiątkach arkuszy Excel na dyskach współdzielonych i prywatnych laptopach.

Typowe miejsca przechowywania danych, które trzeba namierzyć:

• obecny system ERP/finansowo-księgowy (księgowość, kartoteki kontrahentów, część dokumentów sprzedaży i zakupów),
• osobny system magazynowy lub WMS (stany, lokalizacje, partie, numery seryjne),
• CRM (kontakty, szanse sprzedażowe, historia komunikacji z klientem),
• system produkcyjny/MES (marszruty, technologie, BOM-y, zlecenia produkcyjne),
• programy branżowe (np. kadrowo-płacowe, systemy serwisowe, narzędzia projektowe),
• pliki Excel i Access (cenniki, stany, rejestry klientów, rozliczenia, raporty),
• dyski współdzielone, SharePoint, Google Drive, itp.,
• „małe systemiki” działowe, często pisane na zamówienie lub „po godzinach” przez kogoś z IT.

Celem nie jest od razu pełna dokumentacja każdego pliku. Na start wystarczy zidentyfikować kluczowe źródła i zrozumieć, jakie typy danych są w nich przechowywane. Już samo uświadomienie sobie, że baza klientów występuje w pięciu różnych wersjach, jest ważnym odkryciem.

Jak zrobić szybką, ale sensowną diagnozę

Zamiast prowadzić wielomiesięczny audyt, lepiej zacząć od krótkiej, lecz przemyślanej diagnozy. Sprawdza się proste podejście warsztatowe: zaproszenie przedstawicieli głównych działów i przejście przez pytania związane z danymi biznesowymi.

Przykładowy zestaw pytań do szybkiej diagnozy:

• Jakich danych ten dział używa na co dzień (klienci, produkty, stany, projekty, itd.)?
• W jakich systemach, plikach lub narzędziach są te dane przechowywane?
• Kto jest „strażnikiem” tych danych – osoba, która realnie je utrzymuje?
• Co dziś najbardziej przeszkadza: duplikaty, brak aktualności, brak spójności, brak dostępu?
• Czy dział ma własne „tajne” pliki, których nikt inny nie widzi, ale wszyscy od nich zależą?

Już po takim ćwiczeniu można stworzyć prostą listę źródeł danych i głównych problemów. Chodzi o realny obraz sytuacji, nie idealny świat zapisany w instrukcjach, których nikt nie czyta. Jeśli handlowcy przyznają, że nie ufają kartotece klientów w systemie i wszystko prowadzą w Excelu – to właśnie ta informacja jest kluczowa dla planowania migracji danych ERP.

Przykład z praktyki: trzy równoległe bazy klientów

W wielu firmach handlowych funkcjonują jednocześnie:

• baza klientów w systemie FK/ERP – używana głównie do fakturowania,
• baza klientów w CRM – używana do sprzedaży i marketingu,
• oddzielne pliki działów regionalnych – bo „w systemie jest bałagan”.

Żadna z tych baz nie jest kompletna: jedna ma dobre dane adresowe, druga pełne osoby kontaktowe, trzecia realne warunki handlowe. Przy migracji do nowego ERP trzeba je ze sobą zmapować, ujednolicić i wyczyścić. Jeżeli ten etap zostanie pozostawiony na „kiedyś w trakcie wdrożenia”, projekt stanie się festiwalem pytań typu: „który to prawdziwy klient?”, „czy to ta sama firma, tylko inaczej wpisana?” i „kto ma decydujący głos w sprawie połączenia kartotek”.

Ustalenie priorytetów – które dane są krytyczne dla nowego ERP

Dane „must have” vs „nice to have” na start

Przygotowanie danych do ERP wymaga odróżnienia tego, co jest absolutnie niezbędne na dzień uruchomienia systemu, od tego, co można przenieść później lub zostawić w archiwum. Migracja danych ERP często rozpada się na zbyt szeroki zakres – próbuje się przenieść „wszystko, co mamy, na wszelki wypadek”. To prosta droga do chaosu.

W praktyce dobrze działa podział na dwie kategorie:

• Must have – dane, bez których podstawowe procesy firmowe nie ruszą (np. aktywni klienci, aktualne produkty, rzeczywiste stany magazynowe, otwarte faktury, bieżące zlecenia),
• Nice to have – dane, które są przydatne, ale można je przenieść w drugim kroku albo zostawić w systemach źródłowych (np. pełna historia sprzedaży sprzed wielu lat, nieaktywne kartoteki, stare projekty).

Przy definiowaniu priorytetów trzeba myśleć procesowo: które dane są konieczne, aby sprzedać towar, wystawić fakturę, przyjąć dostawę, wytworzyć produkt lub zamknąć miesiąc. Jeśli dane nie są potrzebne w tych kluczowych obszarach, jest duża szansa, że mogą poczekać.

Klasy danych: master data, transakcje, historia, konfiguracje

Ustalenie priorytetów jest prostsze, gdy dane zostaną podzielone na kilka klas. W kontekście ERP najczęściej mówi się o:

• Master data (dane podstawowe) – kartoteki klientów, dostawców, produktów, materiałów, kont księgowych, magazynów, pracowników (w zarysie),
• Dane transakcyjne – dokumenty sprzedaży, zakupów, przepływy magazynowe, zlecenia produkcyjne, rozliczenia,
• Dane historyczne – zamknięte dokumenty z poprzednich okresów, stare projekty, zakończone zlecenia, dawne kontrakty,
• Dane konfiguracyjne – słowniki, cenniki, rabaty, formy płatności, stawki VAT, schematy księgowań.

Dla każdej klasy można zadać kilka kluczowych pytań:

• Czy te dane są niezbędne, aby kontynuować pracę po starcie nowego ERP?
• Czy są wymagane przez przepisy (np. dla kontroli podatkowych, archiwizacji)?
• Czy dostęp do nich musi być w nowym ERP, czy może być w systemie archiwalnym (tylko do podglądu)?
• Czy migracja tych danych jest realna i opłacalna (czy struktury da się sensownie dopasować)?

Przykładowo: pełna historia sprzedaży z ostatnich kilkunastu lat często nie musi być migrowana dokument po dokumencie. Wystarczy przenieść dane zbiorcze, raporty lub zapewnić dostęp do starego systemu w trybie „tylko do odczytu”. Z kolei otwarte zamówienia, niezapłacone faktury i aktualne zlecenia – to już dane must have.

Ograniczanie zakresu migracji – jak nie przenosić „śmieci z 2003 roku”

Naturalny odruch wielu firm brzmi: „skoro już robimy nowe ERP, to wczytamy wszystko”. Problem w tym, że „wszystko” oznacza także błędy, duplikaty i dane dawno nieaktualne. Z perspektywy migracji danych ERP lepiej migrować mniej, ale za to porządnie wyczyszczone i przemyślane informacje.

Przy ustalaniu zakresu migracji warto użyć prostych kryteriów:

• Horyzont czasowy – np. przenosimy szczegółowe dane transakcyjne z ostatnich 2–3 lat, a starsze zostają w archiwum,
• Aktywność – migrujemy tylko klientów, z którymi było działanie w ostatnich X latach, albo którzy mają otwarte dokumenty,
• Wartość biznesowa – migrujemy kontrakty strategicznych klientów, nawet starsze, bo są kluczowe dla relacji,
• Obowiązki prawne – zapewniamy dostęp do danych potrzebnych dla kontroli, ale niekoniecznie w nowym ERP.

Ograniczenie zakresu migracji nie oznacza utraty danych. Często wystarczy utrzymać stary system w trybie archiwum lub wyeksportować dane do czytelnych raportów. Nowe ERP ma żyć teraźniejszością i przyszłością, nie być muzeum wszystkiego, co firma kiedykolwiek wpisała do komputera.

Projekt porządkowania danych – jak zorganizować prace przed wdrożeniem

Rola właścicieli danych (data owners)

Przygotowanie danych do migracji nie może być zadaniem „pana z IT” ani jednego księgowego. Dane są elementem procesów biznesowych, więc za poszczególne obszary muszą odpowiadać właściciele z biznesu – tzw. data owners.

Właściciel danych to osoba (zwykle kierownik lub ekspert danego działu), która:

• decyduje, jakie dane są potrzebne w danym obszarze (np. sprzedaż, zakupy, produkcja),
• ustala zasady ich jakości (co jest uznawane za kompletne, aktualne, spójne),
• zatwierdza decyzje o usuwaniu, łączeniu czy archiwizacji danych,
• uczestniczy w mapowaniu pól danych między starym a nowym systemem.

IT może pomóc w technicznej części (ekstrakcja, transformacja, ładowanie), ale to biznes decyduje, czy dwa rekordy klienta to faktycznie ta sama firma, czy tylko podobna nazwa. Bez jasno wskazanych „właścicieli danych” migracja danych ERP szybko zamienia się w festiwal niekończących się konsultacji i braku odpowiedzialności.

Zespół ds. przygotowania danych

Oprócz właścicieli danych potrzebny jest dedykowany zespół roboczy, który zajmie się realizacją zadań: zbieraniem, czyszczeniem, ujednolicaniem i dokumentowaniem danych. W skład takiego zespołu powinni wejść:

• przedstawiciele kluczowych działów (sprzedaż, zakupy, magazyn, produkcja, księgowość),
• osoba z IT / analityk danych – do technicznej strony migracji,
• kierownik projektu danych (lub ktoś pełniący tę rolę) – koordynujący działania i terminy.

Zadania zespołu ds. danych obejmują m.in.:

• inwentaryzację źródeł danych i ich opis,
• ustalenie standardów i struktur danych (w porozumieniu z biznesem),
• przygotowanie wytycznych do czyszczenia (co kasujemy, co łączymy, co archiwizujemy),
• tworzenie plików do migracji i weryfikację poprawności danych testowych.

Taki zespół powinien zacząć działać kilka miesięcy przed planowanym startem właściwego projektu ERP. Dzięki temu analiza i porządkowanie danych nie będą się dramatycznie ścigały z konfiguracją systemu.

Harmonogram prac przed startem projektu ERP

Prace nad danymi dobrze rozłożyć w czasie. Sensowny, uproszczony harmonogram może wyglądać tak:

1. Miesiące -6 do -4 – inwentaryzacja danych biznesowych: identyfikacja źródeł, opis typów danych, wstępna klasyfikacja (aktywne/archiwalne),
2. Miesiące -4 do -3 – ustalanie standardów kodów, nazw, jednostek, słowników; wstępne decyzje o zakresie migracji (co wchodzi, co zostaje w archiwum),

Realistyczne szacowanie nakładu pracy

Porządkowanie danych jest zwykle niedoszacowane. „Przecież to tylko wyczyszczenie plików Excela” zamienia się potem w setki godzin ręcznej weryfikacji kartotek. Zanim ruszy właściwy projekt ERP, dobrze jest policzyć choćby rząd wielkości pracy.

Pomaga proste podejście próbki:

• weź losową próbkę np. 200–500 rekordów z kluczowego obszaru (klienci, produkty, indeksy magazynowe),
• policz, ile z nich wymaga korekty, uzupełnienia, połączenia z innym rekordem,
• zmierz, ile średnio czasu zajmuje ręczne poprawienie jednego rekordu (wraz z decyzjami biznesowymi),
• przeskaluj na całą bazę, uwzględniając możliwą automatyzację części zadań.

Przykład: jeśli z próbki 300 klientów 40% wymaga interwencji, a średnio 3 minuty na klienta zajmuje znalezienie poprawnych danych i decyzja, co z nimi zrobić, to przy 10 000 klientów wychodzi kilkaset roboczogodzin. Przy takim rachunku szybko znika złudzenie, że „zrobimy to jednym sprintem”.

Lepsze jest uczciwe oszacowanie i zaplanowanie osobnego mini-projektu, niż później ratowanie wdrożenia nadgodzinami „na wczoraj”.

Kamienie milowe i punkty kontrolne jakości

Projekt porządkowania danych powinien mieć swoje własne kamienie milowe, a nie tylko ogólny termin „przed startem ERP”. W praktyce przydają się konkrety:

• gotowe słowniki i standardy nazw – zaakceptowane przez właścicieli danych przed wyborem systemu,
• wstępnie oczyszczone główne kartoteki (klienci, dostawcy, produkty) – w uzgodnionym formacie,
• pierwsza wersja plików migracyjnych do testów – pod nowy ERP lub przynajmniej pod model danych referencyjny,
• raport jakości danych – z pokazaniem, ile rekordów nadal wymaga pracy.

Tu przydają się proste wskaźniki: odsetek wypełnionych pól obowiązkowych, liczba duplikatów, liczba rekordów „w zawieszeniu” (np. do decyzji o archiwizacji). Dzięki temu decyzja „jesteśmy gotowi na start projektu ERP” nie jest oparta tylko na intuicji.

Inwentaryzacja i klasyfikacja danych – co tak naprawdę posiadamy

Mapa źródeł danych zamiast „wszyscy wiedzą, gdzie to jest”

Punktem wyjścia jest stworzenie prostej, ale kompletnej mapy źródeł danych. Chodzi o spis miejsc, w których żyją istotne informacje wykorzystywane w firmie. Zwykle jest ich więcej, niż ktokolwiek się spodziewa.

Taka mapa powinna obejmować m.in.:

• główne systemy transakcyjne (aktualny ERP, systemy finansowo-księgowe, systemy magazynowe, produkcyjne),
• systemy satelitarne (CRM, WMS, MES, systemy serwisowe, e-commerce),
• pliki dziedzinowe (arkusze Excela, Access, różne „pomocnicze bazy” działów),
• zewnętrzne źródła danych (bazy referencyjne, dane zewnętrznych operatorów logistycznych, platform B2B),
• papierowe lub półpapierowe „systemy” – zeszyty, kartoteki, wydruki podpisane przez lata, które realnie sterują pracą.

Dla każdego źródła warto krótko opisać: za co odpowiada, które procesy wspiera, jakie ma typy danych (kartoteki, transakcje, konfiguracje) i kto jest za nie biznesowo odpowiedzialny. Już na tym etapie zwykle wychodzą na jaw niespodzianki typu: „magazyn ma swój arkusz z alternatywnymi indeksami, o którym nikt nie wspominał na spotkaniach”.

Opis danych: minimalna „metryczka” dla każdego zbioru

Sam spis systemów to za mało. Potrzebna jest krótka „metryczka” dla każdego zbioru danych. Nie musi to być elaborat – wystarczy jedno, dobrze wypełnione ZEN (zestaw najważniejszych informacji):

• Nazwa zbioru – np. „Klienci – CRM”, „Indeksy magazynowe – arkusz Magazyn_ABC.xlsx”,
• Właściciel biznesowy – osoba / dział decydujący o zawartości,
• Lokalizacja / system – gdzie dane są przechowywane,
• Główne typy danych – klienci, produkty, zamówienia, cenniki itd.,
• Zakres czasowy – od kiedy zbiór jest prowadzony, czy zawiera archiwa,
• Jakość wstępna – subiektywna ocena (np. dobra / średnia / zła) plus krótkie uzasadnienie,
• Zależności – czy dane są kopiowane z innego systemu, ręcznie synchronizowane, eksportowane cyklicznie.

Taka metryczka wystarcza, aby podczas późniejszej analizy (i w rozmowach z dostawcami ERP) szybko się zorientować, jakie dane istnieją, skąd pochodzą i czy przypadkiem nie dublują się z innymi zbiorami.

Klasyfikacja: operacyjne, referencyjne, analityczne, „śmietnikowe”

Po inwentaryzacji przychodzi kolej na klasyfikację danych według ich funkcji. Pomaga prosty podział:

• Dane operacyjne – bezpośrednio używane w codziennych procesach (zamówienia, dokumenty magazynowe, faktury, zlecenia produkcyjne),
• Dane referencyjne – służą jako tło i uzupełnienie (słowniki, cenniki, listy kodów, tabele kursów, stawki VAT),
• Dane analityczne – agregacje, raporty, hurtownie danych, zestawienia KPI,
• Dane „śmietnikowe” – kopie robocze, pliki „do testów”, stare eksporty bez właściciela, które nikt już naprawdę nie potrzebuje.

Ta ostatnia kategoria bywa zaskakująco pojemna. Czasem 20–30% „systemu danych” firmy to różne pliki, które kiedyś do czegoś służyły, ale dziś pełnią głównie rolę cyfrowego strychu. Lepiej je zawczasu nazwać po imieniu niż migrować je z poczucia sentymentu.

Identyfikacja duplikatów i niespójności między systemami

Przy klasyfikacji danych dobrze jest od razu wychwytywać obszary podejrzane o duplikaty i niespójności. Typowe przykłady:

• ta sama baza dostawców w ERP i w arkuszu zakupów – z różnymi numerami kont bankowych,
• produkty rejestrowane w systemie produkcyjnym pod innymi kodami niż w sprzedaży,
• oddzielne listy magazynów w systemie WMS i w finansowo-księgowym,
• różne stawki VAT lub definicje jednostek miary w kilku bazach.

Na tym etapie nie trzeba jeszcze wszystkiego scalać, ale dobrze jest zaznaczyć takie „punkty konfliktowe” w dokumentacji. Podczas projektowania nowego ERP to właśnie one zdecydują o złożoności migracji.

Standardy i struktury – jak ujednolicić dane przed wyborem systemu

Spójne słowniki i kody biznesowe

Nowy ERP lubi porządek. Jeżeli każda jednostka organizacyjna używa własnych kodów, skrótów i opisów, system to tylko utrwali i powiększy bałagan. Sporo można uporządkować jeszcze przed wyborem rozwiązania, niezależnie od tego, jaki produkt ostatecznie wygra.

Kluczowe obszary, w których opłaca się zdefiniować wspólne standardy kodów i słowników:

• Jednostki organizacyjne – działy, oddziały, magazyny, linie produkcyjne,
• Struktura asortymentu – grupy towarów, kategorie produktowe, typy usług,
• Jednostki miary – ich skróty, przeliczniki i zasady stosowania,
• Formy płatności i warunki handlowe – ujednolicone nazwy i parametry,
• Typy dokumentów – spójne nazewnictwo dla faktur, zamówień, dokumentów magazynowych.

Jeżeli w jednym systemie magazyn nazywa się „001”, w innym „MAG1”, a w arkuszu Excel „Centralny”, to migracja skończy się serią ręcznych mapowań i wpadek. Wspólny słownik oznacza, że przed wdrożeniem można już zacząć stosować jednolite nazwy i kody w bieżącej pracy.

Minimalny model danych referencyjnych

Zanim pojawi się konkretny dostawca ERP, można zdefiniować prosty, systemowo niezależny model danych referencyjnych – coś w rodzaju „szkieletu”, do którego później dopasuje się struktury konkretnego systemu. Taki model może objąć np.:

• kartotekę klientów – obowiązkowe pola (nazwa, NIP, kraj, adres rozliczeniowy, typ klienta, status aktywności),
• kartotekę produktów – kod, nazwa krótka, nazwa pełna, podstawowa jednostka miary, grupa towarowa, status (aktywny/nieaktywny),
• magazyny – kod, nazwa, typ (surowce, produkcja, wyroby gotowe, serwis),
• podstawowe słowniki – kraj, waluta, forma płatności, stawka VAT.

Model ten nie musi od razu pokrywać wszystkich możliwych potrzeb. Chodzi o to, by ustalić minimum, bez którego prowadzenie spójnych danych nie ma sensu. Dzięki temu już na etapie porządkowania da się ocenić, które rekordy da się łatwo przenieść, a które są „niekompletne z definicji”.

Reguły nazewnictwa i formatów

Standardy nazewnictwa brzmią nudno, dopóki ktoś nie zacznie szukać produktu o nazwie „Usługa – instalacja” w bazie zawierającej także „usluga instalacyjna”, „instalacja – service” i „INSTALACJA”. Proste zasady ograniczają późniejsze rozczarowania.

Co warto uporządkować:

• Konwencje nazw produktów – np. wzór nazwy: [grupa] [model] [cecha kluczowa]; zakaz wprowadzania opisów w polu nazwy,
• Formaty numerów – NIP, numery kont bankowych, numery seryjne; czy zawierają spacje, myślniki, prefiksy kraju,
• Wielkość liter – czy nazwy wprowadzamy wielkimi literami, czy normalnie; brak przypadkowych miksów,
• Znaki specjalne – ograniczenie używania symboli, które potem utrudniają integracje lub eksporty.

Te zasady można stopniowo wdrażać już w istniejących systemach. Nie trzeba czekać na nowe ERP, żeby umówić się, że od dzisiaj wszystkie nowe indeksy są tworzone według spójnego schematu.

Polityka „aktywny / nieaktywny” zamiast kasowania

Jednym z elementów standaryzacji jest jasna polityka zarządzania życiem danych. Zamiast hurtowo kasować stare rekordy przed migracją, lepiej wprowadzić konsekwentny mechanizm statusów:

• aktywny – rekord używany w bieżących procesach,
• zablokowany – nie używamy w nowych transakcjach, ale może być jeszcze w rozliczeniach,
• archiwalny – pozostaje w systemach źródłowych lub wydzielonym archiwum, nie jest przenoszony do nowego ERP (chyba że wyjątkowo).

Dzięki temu nowy system nie startuje z tysiącami nieużywanych indeksów czy dawnych klientów. Jednocześnie firma nie traci historii – w razie potrzeby sięga do archiwum, w którym stare dane są oznaczone i nie udają „żywych”.

Czyszczenie i wzbogacanie danych – praktyczne kroki krok po kroku

Etap 1: Konsolidacja i zebranie danych w jednym miejscu roboczym

Zanim rozpocznie się „wielkie sprzątanie”, trzeba zebrać dane z różnych źródeł do jednego środowiska roboczego – choćby tymczasowej bazy lub serii dobrze opisanych arkuszy. Chodzi o to, by móc:

• zobaczyć pełny obraz – np. wszystkich klientów ze wszystkich systemów,
• porównać rekordy między sobą,
• stosować reguły czyszczenia na całej populacji, a nie w silosach.

Tu przydaje się wsparcie IT lub analityka danych – do zrzutu danych z systemów i ich wstępnego znormalizowania (np. nazwy kolumn, formaty dat). Nie jest konieczna od razu zaawansowana platforma ETL; przy średniej skali danych można działać etapowo w prostszych narzędziach, byle z głową.

Etap 2: Wstępne profilowanie jakości danych

Profilowanie to nic innego jak spojrzenie na dane „statystycznym okiem”. Zamiast zakładać, że „pewnie jest trochę braków”, można to precyzyjnie zmierzyć. Na tym etapie analizuje się m.in.:

• odsetek pustych pól w kluczowych kolumnach (np. brak NIP, brak jednostki miary, brak grupy produktowej),
• liczbę wartości unikalnych – np. ile różnych form płatności faktycznie funkcjonuje,
• zgodność z prostymi regułami – czy NIP ma właściwą długość, czy kody krajów są z listy ISO,
• rozrzut wartości – podejrzanie skrajne ilości, ceny, daty w przyszłości lub sprzed „urodzenia firmy”.

Etap 3: Definicja reguł biznesowych dla czyszczenia

Profilowanie ujawnia problem, ale nie mówi jeszcze, co z nim zrobić. Kolejny krok to spisanie konkretnych reguł, które zamienią „bałagan” w powtarzalny proces czyszczenia. W praktyce oznacza to decyzje typu:

• co jest obowiązkowe – które pola muszą być uzupełnione, aby rekord mógł wejść do nowego ERP,
• co można domyślać – np. brakujący kraj można ustalić z kodu pocztowego, a brak jednostki miary czasem z grupy towarowej,
• co trzeba odrzucić – rekordy z danymi sprzecznymi lub „nie do uratowania” (np. klient bez żadnego adresu i kontaktu),
• co wymaga akceptacji biznesu – reguły, które mogą wpłynąć na rozliczenia, ceny, historię sprzedaży.

Dobrze, gdy reguły mają właścicieli po stronie biznesu. To sprzedaż decyduje, co oznacza „kompletna kartoteka klienta”, a logistyka – jakie dane magazynowe są krytyczne. IT pomaga to później przełożyć na konkretne skrypty i procedury.

Etap 4: Usuwanie duplikatów i scalanie rekordów

Duplikaty to klasyka gatunku: ten sam klient pod trzema nazwami, produkt wpisany dwa razy z minimalną różnicą w opisie. Zanim wejdą do nowego ERP, trzeba je złapać i pogodzić.

Typowy przebieg prac:

• Identyfikacja potencjalnych duplikatów – np. po NIP, REGON, numerze telefonu, adresie e‑mail, podobieństwie nazw (fuzzy matching),
• Grupowanie kandydatów – rekordy podobne trafiają do jednej grupy „do rozstrzygnięcia”,
• Ustalenie zasad scalania – np. które pola „wygrywają” (nowsza data aktualizacji, dane z systemu nadrzędnego),
• Oznaczenie rekordów głównych i podrzędnych – jeden rekord zostaje, reszta jest do skasowania lub zarchiwizowania.

Przy dużej skali warto część decyzji zautomatyzować (proste reguły), a jedynie najtrudniejsze przypadki przekazać do weryfikacji użytkownikom biznesowym. Inaczej zespół utknie na tygodnie przy ręcznym „przeklikiwaniu” podobnych klientów.

Etap 5: Uzupełnianie i korekta kluczowych pól

Po redukcji duplikatów przychodzi kolej na czyszczenie „w głąb” rekordów, czyli uzupełnianie i poprawę brakujących lub błędnych informacji. W praktyce można połączyć kilka sposobów:

• Uzupełnianie automatyczne – np. przypisanie domyślnej stawki VAT do produktów z danej grupy, ujednolicenie formatów NIP czy numerów kont,
• Wzbogacanie z zewnętrznych źródeł – integracja z bazami referencyjnymi (np. rejestry przedsiębiorców, słowniki adresów),
• Akcje „kampanijne” – prośba do wybranych klientów o aktualizację danych kontaktowych, potwierdzenie preferowanych form komunikacji itp.,
• Ręczna korekta wybranych segmentów – np. 500 największych klientów czy kluczowe surowce przechodzą dokładny „przegląd ręczny”.

Na tym etapie przydaje się prosty system znakowania postępu – np. statusy „do uzupełnienia”, „do weryfikacji”, „gotowe do migracji”. Dzięki temu widać, gdzie zespół stoi, a gdzie dane wciąż blokują ruszenie z projektem ERP.

Etap 6: Walidacja z użytkownikami biznesowymi

Po automatycznym i półautomatycznym czyszczeniu trzeba jeszcze sprawdzić, czy dane „trzymają sens biznesowy”. Czasem algorytm ładnie się zepnie, ale księgowy lub kierownik magazynu od razu zobaczy, że coś nie gra.

Praktycznym podejściem jest przegląd próbki danych:

• wybór reprezentatywnego wycinka (np. po kilkadziesiąt rekordów z różnych segmentów),
• przekazanie ich właścicielom procesów (sprzedaż, zakupy, logistyka, księgowość),
• zebranie uwag i korekt do reguł czyszczenia – lepiej je poprawić teraz niż po migracji.

Taki przegląd można wykonać dwa–trzy razy przy rosnącej jakości danych. W pewnym momencie użytkownicy zaczną używać magicznego zwrotu „nareszcie to ma ręce i nogi” – to dobry znak, że można planować pierwsze testy migracji.

Etap 7: Przygotowanie „zestawu migracyjnego”

Na końcu procesu czyszczenia powstaje wyraźnie zdefiniowany zbiór danych, które mają trafić do nowego systemu. To nie tylko sam plik z rekordami, ale całe „opakowanie”:

• opis zakresu – które typy danych wchodzą do migracji, a które świadomie zostają w archiwum,
• specyfikacja struktur – jakie pola zawierają poszczególne kartoteki i jak je rozumieć,
• mapa powiązań – zależności między tabelami (np. produkt–jednostka miary–stawka VAT–kategoria),
• lista reguł filtrujących – np. „klienci aktywni w ciągu ostatnich 3 lat”, „produkty niearchiwalne z przypisaną grupą”.

Taki zestaw jest później podstawą do rozmów z dostawcami ERP. Zamiast ogólnego hasła „mamy dużo danych”, można pokazać konkretną strukturę i omówić, jak system poradzi sobie z migracją.

Stałe monitorowanie jakości danych przed migracją

Między rozpoczęciem porządków a startem projektu wdrożeniowego zwykle mija kilka–kilkanaście miesięcy. W tym czasie codzienna praca generuje nowe dane, które potrafią po cichu „zepsuć” starannie wysprzątaną bazę. Dlatego potrzebny jest prosty mechanizm czuwania nad jakością.

Można to zorganizować w kilku krokach:

• kontrola nowych rekordów – domyślne walidacje w obecnych systemach (np. brak zapisu klienta bez NIP lub kraju),
• okresowe raporty jakości – raz w miesiącu prosty raport pokazujący nowe braki, duplikaty, dziwne wartości,
• „bramki jakościowe” – np. założenie, że wskaźnik uzupełnienia kluczowych pól nie może spaść poniżej ustalonego poziomu.

To już nie jest jednorazowa akcja „sprzątaj i zapomnij”, lecz zaczątek stałego zarządzania jakością danych. Nowe ERP dzięki temu nie stanie się szybko powtórką starego krajobrazu.

Rola właścicieli danych i zespołu migracyjnego

Nawet najlepsze narzędzia nie załatwią kluczowej kwestii: kto podejmuje decyzje o tym, które dane są „dobre”. Stąd potrzeba jasnego przypisania odpowiedzialności.

Najczęściej sprawdza się konstrukcja:

• właściciele domen danych – np. dyrektor sprzedaży dla klientów, logistyka dla zapasów i magazynów, finansy dla kontrahentów księgowych,
• koordynator ds. migracji – osoba spinająca całość, prowadząca harmonogram, nadzorująca spójność reguł,
• wsparcie IT/analityczne – odpowiedzialne za ekstrakcję, transformację, walidację techniczną.

To właśnie właściciele danych zatwierdzają reguły: co archiwizujemy, co łączymy, a czego nie przenosimy. Jeżeli ich zabraknie, decyzje będą podejmowane „po cichu” przez tych, którzy akurat mają dostęp do baz – zwykle z mieszanym skutkiem.

Komunikacja i „zmiana nawyków danych”

Przygotowanie do migracji to dobry pretekst, by zmienić codzienne nawyki dotyczące wprowadzania i aktualizacji informacji. Bez tego czyszczenie jednorazowe zadziała jak mycie auta przed deszczem.

Przydatne praktyki to m.in.:

• krótkie szkolenia dla kluczowych użytkowników – nie o „magii migracji”, ale o konkretnych standardach: jak nazwać produkt, kiedy zakładać nową kartotekę klienta itd.,
• proste instrukcje i ściągi – np. jedna strona z zasadami kodowania, przykłady poprawnych nazw, lista obowiązkowych pól,
• pokazywanie skutków błędów – kilka realnych, biznesowych „wtop” spowodowanych złymi danymi przekonuje lepiej niż najgrubsza procedura,
• zachęty zamiast straszenia – np. skrócenie procesów akceptacji dla kompletnej kartoteki, szybsze wystawianie umów, mniejsza liczba zwrotów dokumentów.

Jeżeli użytkownicy zrozumieją, że nowe zasady nie są „fanaberią pod ERP”, tylko realnie ułatwią im pracę, poziom oporu spada zdecydowanie szybciej.

Testowe migracje „na sucho” jeszcze przed wyborem rozwiązania

Gdy dane są już wstępnie uporządkowane i opisane, można pokusić się o niewielkie testy „na sucho”. Chodzi o sprawdzenie, czy przygotowany model i standardy faktycznie się bronią, a nie o pełną migrację do konkretnego systemu.

Takie mini‑eksperymenty mogą wyglądać tak:

• próba załadowania danych do prostego, neutralnego modelu (np. roboczej bazy SQL lub narzędzia MDM),
• sprawdzenie, czy wszystkie reguły relacji i kluczy działają (np. każdy produkt ma grupę i jednostkę miary, każdy klient – komplet identyfikatorów),
• symulacja podstawowych raportów biznesowych (sprzedaż wg grup, zapas wg magazynu) na uporządkowanych danych.

Takie podejście pozwala w praktyce zweryfikować, czy przyjęty „szkielet” danych nie jest zbyt skomplikowany albo przeciwnie – zbyt ubogi. Przy wyborze docelowego ERP łatwiej wtedy ocenić, czy standardowy model systemu pasuje do przygotowanej struktury, czy wymaga rozbudowanej kastomizacji.

Świadome decyzje, których danych nie migrować

Jednym z najważniejszych efektów całej pracy powinna być lista danych świadomie pozostawionych poza migracją. Zamiast próbować wciągnąć do nowego ERP wszystko, co zgromadzono przez lata, lepiej podjąć twarde decyzje na podstawie kryteriów:

• używalność – brak wykorzystania w procesach od dłuższego czasu (np. klienci bez transakcji od dekady),
• kompletność – brak kluczowych pól, których nie da się wiarygodnie odtworzyć,
• waga biznesowa – dane, do których dostęp może zostać zapewniony przez proste archiwum, a nie musi być w nowym ERP,
• ryzyko prawne – informacje, które ze względu na RODO lub inne regulacje lepiej usunąć po spełnieniu wymogów retencji.

Tę listę dobrze mieć opisaną i zatwierdzoną przez kierownictwo. Dzięki temu, gdy w trakcie wdrożenia pojawi się pokusa „a weźmy jeszcze tę starą bazę, bo może się przyda”, można odwołać się do uzgodnionej polityki zamiast zaczynać dyskusję od zera.

Najczęściej zadawane pytania (FAQ)

Od czego zacząć przygotowanie danych do migracji do nowego systemu ERP?

Punkt startowy to zrobienie mapy: ustalenie, gdzie w firmie faktycznie są dane. Trzeba spisać wszystkie główne źródła – obecny system FK/ERP, system magazynowy/WMS, CRM, system produkcyjny, programy branżowe, arkusze Excel, dyski współdzielone i „małe systemiki” działowe.

Kolejny krok to szybka diagnoza z udziałem przedstawicieli kluczowych działów. Na warsztacie warto przejść przez pytania: z jakich danych dział korzysta, w jakich systemach je trzyma, kto jest za nie odpowiedzialny i gdzie są największe problemy (duplikaty, brak aktualności, rozjazdy między systemami). Dopiero na tej podstawie można sensownie planować dalsze porządki.

Jak sprawdzić, czy nasze dane są „gotowe do migracji”, a nie tylko „gdzieś istnieją”?

Dane „istniejące” to takie, które po prostu są – w różnych systemach, Excelach, czasem w głowach pracowników. Dane „gotowe do migracji” są zebrane w jednym miejscu, wyczyszczone z duplikatów, ujednolicone (formaty, nazwy, kody) i opisane tak, żeby dało się je jednoznacznie załadować do nowego ERP.

Praktyczny test jest prosty: czy potrafisz wygenerować plik z klientami/produktami/magazynami, który można przekazać konsultantowi wdrożeniowemu bez komentarza „tu jest trochę bałaganu, ale jakoś to ogarniemy”? Jeśli każda kolumna ma jasne znaczenie, dane nie dublują się i nie ma oczywistych braków (np. NIP, jednostki miary, stawki VAT), to jesteś bliżej „gotowości do migracji” niż większość firm.

Jakie dane trzeba koniecznie przenieść do nowego ERP na start, a co może poczekać?

Na start kluczowe są dane „must have”, bez których firma nie ruszy po przełączeniu systemu. Typowo są to: aktywni klienci i dostawcy, aktualne kartoteki produktów i materiałów, realne stany magazynowe, otwarte dokumenty (zamówienia, faktury, zlecenia), podstawowy plan kont i podstawowe słowniki (formy płatności, stawki VAT).

Dane „nice to have” – pełna historia sprzedaży sprzed wielu lat, nieaktywne kartoteki, stare projekty czy zamknięte zlecenia – można przenieść później lub zostawić w systemie archiwalnym do podglądu. W praktyce bezpieczniej jest wystartować z mniejszym, dobrze przygotowanym zakresem niż z „wszystkim, co mamy od 2005 roku”.

Jak zapanować nad wieloma bazami klientów, produktami i Excelami przed migracją ERP?

Najpierw trzeba te światy ujawnić. Podczas diagnozy poproś działy o pokazanie „tajnych” plików i lokalnych baz, na których faktycznie pracują (np. oddzielne Excela handlowców, osobne rejestry klientów w regionach). Gdy wszystkie źródła są na stole, można zobaczyć, które dane się powtarzają, a które się uzupełniają.

Kolejny etap to ujednolicenie i połączenie kartotek. Zwykle wymaga to decyzji biznesowych: co jest „bazą referencyjną”, jak łączymy duplikaty, kto ma ostatnie słowo przy konflikcie danych (księgowość, sprzedaż, logistyka?). Bez tych ustaleń migracja zamienia się w codzienny quiz „który klient jest prawdziwy”. Lepiej przejść ten bój przed wyborem systemu niż w środku wdrożenia.

Czy przygotowanie danych trzeba robić już przed wyborem systemu ERP, czy można poczekać do wdrożenia?

Porządki w danych warto zacząć jeszcze przed wyborem konkretnego systemu. Po pierwsze, skraca to samo wdrożenie – konsultanci nie czekają tygodniami na pliki, a użytkownicy nie poprawiają kartotek po godzinach. Po drugie, lepiej widać realne potrzeby i ograniczenia, więc łatwiej ocenić oferty dostawców ERP i zadać im konkretne pytania.

Jeśli przygotowanie danych przesunie się na etap wdrożenia, rośnie ryzyko opóźnień i nerwowych decyzji „na szybko”. System ERP nie naprawi bałaganu, tylko go przejmie i utrwali. Inaczej mówiąc: im bardziej ogarniesz dane przed podpisaniem umowy, tym mniej będziesz płacić za gaszenie pożarów po starcie.

Jak szybko ocenić jakość danych w firmie bez wielomiesięcznego audytu?

Sprawdza się krótki warsztat z udziałem przedstawicieli głównych działów. Dla każdego działu zadaj te same kilka pytań: jakich danych używacie, w jakich systemach/plikach je trzymacie, kto jest ich „strażnikiem” i co dziś najbardziej przeszkadza (brak aktualności, duplikaty, brak dostępu, niespójność między systemami).

Na podstawie takiego spotkania powstaje prosta lista: źródeł danych, typów danych (klienci, produkty, stany, projekty…), głównych problemów. To nie będzie naukowy audyt, ale da wystarczająco dobry obraz, by zaplanować migrację i określić, które obszary trzeba wyczyścić w pierwszej kolejności.

Jak podzielić dane na kategorie, żeby lepiej zaplanować migrację do ERP?

Praktyczny podział to cztery główne klasy: dane podstawowe (master data – klienci, dostawcy, produkty, materiały, konta, magazyny), dane transakcyjne (dokumenty sprzedaży i zakupów, ruchy magazynowe, zlecenia produkcyjne), dane historyczne (zamknięte okresy, zakończone projekty i kontrakty) oraz dane konfiguracyjne (cenniki, rabaty, formy płatności, stawki VAT, schematy księgowań).

Dla każdej klasy dobrze jest zadać kilka pytań: czy te dane są potrzebne od pierwszego dnia pracy w nowym ERP, czy wymagają ich przepisy, czy mogą zostać w systemie archiwalnym tylko do podglądu i czy ich migracja jest technicznie sensowna i opłacalna. Taki podział pomaga nie próbować przenosić „wszystkiego naraz”, tylko zbudować realny plan w kilku etapach.

Bibliografia i źródła

• ERP: The Implementation Cycle. CRC Press (2014) – Proces wdrożenia ERP, w tym przygotowanie i migracja danych
• Successful Packaged Software Implementation. Addison-Wesley (2001) – Praktyczne wskazówki dot. wdrożeń ERP i roli jakości danych
• Master Data Management and Data Governance. McGraw-Hill (2010) – Definicje master data, zarządzanie jakością danych w systemach ERP
• Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk. Cambridge University Press (2004) – Cykl życia ERP, ryzyka wdrożeń, znaczenie danych dla sukcesu projektu