Wdrożenie systemu ERP - analiza przedwdrożeniowa i migracja danych

Wdrożenie systemu ERP zaczyna się od analizy przedwdrożeniowej

Analiza przedwdrożeniowa nie zmienia jeszcze niczego w systemie. Jej wynikiem są dokumenty: opis procesów w stanie obecnym i lista wymagań, a także wykaz integracji oraz rejestr ryzyk związanych z danymi. Na tej podstawie zespół wdrożeniowy opracowuje szczegółowy projekt, a klient wie, za co płaci i co dostanie w dniu uruchomienia.

Ten tekst dotyczy dwóch obszarów, które przesądzają o powodzeniu wdrożenia systemu ERP: analizy i przeniesienia danych. Sam podział na etapy projektu opisuje artykuł o metodyce wdrożenia systemu ERP, a przesłanki decyzji o zakupie zawiera materiał o tym, dlaczego warto wdrożyć ERP.

Inwentaryzacja procesów

Celem jest opisanie tego, jak praca faktycznie przebiega, a nie tego, co mówią procedury. Rozbieżność bywa znaczna i ujawnia się dopiero przy uruchomieniu, gdy system wymusza kolejność niezgodną z praktyką. Konsultant zbiera więc formularze wraz z arkuszami pomocniczymi i rozmawia z osobami wykonującymi pracę, a nie wyłącznie z kierownikami.

Szczególną uwagę poświęca się arkuszom kalkulacyjnym prowadzonym równolegle do systemu. To one zwykle przechowują informacje, których dotychczasowy program nie obsługuje, i to one trzeba przenieść albo zastąpić funkcją nowego ERP.

Dobrą praktyką jest rejestr obejść: lista sytuacji, w których użytkownik omija system, bo ten czegoś nie potrafi. Każdą pozycję rejestru rozstrzyga się przed konfiguracją, ponieważ obejście, które przetrwa wdrożenie, po starcie staje się niewidocznym procesem poza kontrolą ERP.

Luki w standardzie i decyzje o modyfikacjach

Każde wymaganie porównuje się z możliwościami standardu i klasyfikuje jako zgodne albo wymagające działania. Działaniem bywa parametr albo zmiana procesu, a gdy oba zawodzą, pozostaje modyfikacja. Ta ostatnia jest najdroższa, bo podnosi koszt każdej późniejszej aktualizacji. Pełniejsze omówienie zakresu takiej analizy zawiera tekst o analizie przedwdrożeniowej systemów IT.

Mapowanie pól i czyszczenie kartotek

Migracja danych oznacza przeniesienie kartotek z dotychczasowych systemów albo, gdy źródłem są papier lub arkusze, ich ręczne wprowadzenie. W obu przypadkach potrzebny jest formalny opis, które pole trafia dokąd i w jakiej postaci.

Mapa pól źródło-cel

W mapie pól każdej kolumnie źródła przypisuje się kolumnę docelową i regułę przekształcenia, a do nich uwagę o ograniczeniach. Największe ryzyko dotyczy słowników, takich jak jednostki miary czy stawki podatku. Ten sam kod w dwóch systemach potrafi znaczyć co innego, więc słowniki mapuje się jawną tabelą przekodowań, a nie domyślnie.

Kolejność ładowania i dokumenty otwarte

Dane ładuje się w kolejności wynikającej z kluczy obcych: najpierw słowniki, a po nich kontrahenci z indeksami. Następnie ładuje się stany otwarcia, a na końcu dokumenty otwarte. Odwrócenie tej kolejności kończy się odrzuconymi rekordami, bo zamówienie nie może wskazywać kontrahenta, którego jeszcze nie ma. Stary numer rekordu zapisuje się w osobnym polu, co pozwala później prześledzić pochodzenie każdej pozycji.

Dokumenty otwarte, czyli zamówienia w realizacji i niezapłacone faktury, przenosi się jako salda albo pozycje otwarcia, a nie jako pełną historię. Zamknięte dokumenty z minionych okresów zostają w archiwum systemu źródłowego, dostępnym w trybie odczytu.

Czyszczenie kartotek przed importem

Czyszczenie wykonuje się w systemie źródłowym albo w tabeli przejściowej, a nie w ERP po fakcie, bo po zaimportowaniu rekord zyskuje powiązania z dokumentami. Typowe zadania to scalenie duplikatów kontrahentów, usunięcie indeksów bez ruchu i uzupełnienie brakujących jednostek. O tym, co migrować, decyduje się z księgowością: zwykle przenosi się aktywne kartoteki i stany otwarcia, a nie pełną historię dokumentów.

Wykrycie duplikatów po znormalizowanym NIP-ie sprowadza się do jednego zapytania. Nazwy obiektów w przykładach są umowne.

SELECT REPLACE(REPLACE(Nip, '-', ''), ' ', '') AS NipZnormalizowany,
       COUNT(*)                                 AS Liczba
FROM dbo.PrzykladKontrahentZrodlo
WHERE Nip IS NOT NULL
GROUP BY REPLACE(REPLACE(Nip, '-', ''), ' ', '')
HAVING COUNT(*) > 1;

Podobne wyzwania - migracja kartotek i stanów początkowych z arkusza - opisuje tekst o przejściu z Excela na program magazynowy.

Import próbny i uzgodnienie danych

Import próbny wykonuje się na kopii środowiska, wielokrotnie, aż wynik przestanie się zmieniać. Każdy przebieg mierzy czas, bo od niego zależy długość okna przełączenia.

Tabele przejściowe i ładowanie

Dane źródłowe trafiają najpierw do tabel przejściowych o luźnych typach kolumn, gdzie sprawdza się je bez ryzyka dla docelowej bazy. Wczytanie pliku zapewnia polecenie BULK INSERT, opisane w dokumentacji Microsoft Learn o BULK INSERT. Dopiero zwalidowane rekordy przenosi się do tabel ERP w jednej transakcji, tak aby błąd w połowie ładowania nie zostawił częściowych danych.

CREATE TABLE dbo.StagingKontrahent (
    Kod   varchar(20)   NOT NULL,
    Nazwa nvarchar(200) NOT NULL,
    Nip   varchar(13)   NULL
);

BULK INSERT dbo.StagingKontrahent
FROM 'D:\migracja\kontrahenci.csv'
WITH (FIRSTROW = 2, FIELDTERMINATOR = ';', ROWTERMINATOR = '\n', CODEPAGE = '65001');

SET XACT_ABORT ON;
BEGIN TRANSACTION;
    INSERT INTO dbo.PrzykladKontrahent (Kod, Nazwa, Nip, Zrodlo)
    SELECT s.Kod, s.Nazwa, s.Nip, 'MIGRACJA'
    FROM dbo.StagingKontrahent AS s
    WHERE NOT EXISTS (SELECT 1 FROM dbo.PrzykladKontrahent AS k WHERE k.Nip = s.Nip);
COMMIT TRANSACTION;

Przy dużych kartotekach liczy się też sposób ładowania. Opcja TABLOCK pozwala w modelu odtwarzania SIMPLE albo BULK_LOGGED ograniczyć logowanie transakcji, a parametr BATCHSIZE dzieli plik na partie, dzięki czemu błąd w jednej partii nie cofa całego importu. Indeksy nieklastrowane tabeli docelowej odbudowuje się po załadowaniu, a nie w jego trakcie, bo aktualizacja każdego z nich przy każdym wierszu wydłuża import wielokrotnie.

Strona kodowa 65001 (UTF-8) jest dostępna w BULK INSERT od SQL Server 2016; dla starszych wersji plik konwertuje się do strony kodowej zgodnej z ustawieniami bazy.

Uzgodnienie sum kontrolnych

Po każdym imporcie porównuje się liczby rekordów i sumy wartości między źródłem a ERP, na przykład salda rozrachunków oraz wartość zapasu według magazynów. Zgodność samej liczby wierszy nie wystarcza, bo import może zaokrąglić kwoty albo pominąć rekordy o jednakowej liczbie.

Reguła: migracja jest zakończona dopiero wtedy, gdy każda suma kontrolna w ERP zgadza się z sumą w systemie źródłowym co do grosza.

SELECT 'zrodlo' AS Strona, COUNT(*) AS Liczba, SUM(Saldo) AS SumaSald
FROM dbo.StagingSaldo
UNION ALL
SELECT 'erp', COUNT(*), SUM(Saldo)
FROM dbo.PrzykladRozrachunek
WHERE Zrodlo = 'MIGRACJA';

Stany magazynowe wymagają osobnej uwagi, bo trzeba je zamrozić na dzień przekazania i zweryfikować po fizycznej inwentaryzacji; zasady liczenia stanu dostępnego opisuje artykuł o stanach magazynowych.

Testy akceptacyjne przed uruchomieniem

Testy akceptacyjne wykonują użytkownicy końcowi na danych zmigrowanych, a nie na przykładowych rekordach dostawcy. Dopiero wtedy wychodzą braki, których konsultant nie mógł przewidzieć: brakujący słownik, zbyt długi symbol albo dokument, którego nikt nie opisał w analizie.

Scenariusze na danych zmigrowanych

Scenariusz przechodzi cały proces od pierwszego dokumentu do ostatniego, na przykład od zamówienia klienta przez rezerwację i wydanie do faktury. Wynik porównuje się z oczekiwanym, zapisanym z góry, a odchylenie klasyfikuje jako błąd konfiguracji, błąd danych albo zmianę wymagań.

Błędy z testów trafiają do rejestru z priorytetem i osobą odpowiedzialną. Po poprawce test powtarza się od początku scenariusza, a nie od kroku, w którym wystąpił błąd, ponieważ zmiana konfiguracji potrafi zepsuć etap wcześniejszy.

Kryteria odbioru

Odbiór wiąże się z mierzalnymi warunkami, a nie z upływem terminu umownego. Zestaw zwykle obejmuje cztery pozycje.

• Zgodność sald - salda rozrachunków i bilans otwarcia zgadzają się ze źródłem po ostatnim imporcie próbnym.
• Zgodność stanów - stany magazynowe po miesiącu pracy zgadzają się z inwentaryzacją w granicach tolerancji przyjętej w projekcie.
• Scenariusze obowiązkowe - wszystkie scenariusze procesów podstawowych przechodzą bez obejść ręcznych.
• Błędy otwarte - lista błędów nie zawiera pozycji blokujących, a pozostałe mają termin naprawy.

Przygotowanie środowiska i użytkowników

Po testach danych pozostaje przygotowanie środowiska, w którym system będzie pracował z innymi aplikacjami i z konkretnymi ludźmi.

Integracje z istniejącymi narzędziami

Integrację z narzędziami używanymi już w firmie prowadzi się przez interfejs REST, usługi sieciowe (Web Services) albo wymianę plików XML lub EDI. Dzięki temu nowy ERP współpracuje z dotychczasową infrastrukturą i nie wymusza ręcznego przepisywania danych. Wzorce takiej wymiany na przykładzie systemu magazynowego opisuje tekst o integracji WMS z ERP przez REST i kolejki, a łączniki dopasowane do konkretnej wersji ERP klienta wytwarza dział oprogramowania na zamówienie SoftwareStudio.

Konfigurację połączeń z bazą SQL sprawdza się przed startem, w tym timeouty i poziomy izolacji. Pomaga w tym asystent wdrożeniowców, który wskazuje ustawienia mogące pogorszyć wydajność zapytań.

Role i uprawnienia

Uprawnienia przypisuje się do ról, a role do stanowisk, i testuje na koncie każdej roli. Reguła podstawowa zakłada, że dokumenty zatwierdza inna osoba niż ta, która je wystawiła. Wydruki dokumentów, na przykład faktur, weryfikuje się na danych próbnych, zanim staną się dokumentami urzędowymi; technikę budowy wydruków opisuje artykuł o SQL Report Builder i szablonach RDL.

Szkolenia na danych zmigrowanych

Szkolenia prowadzi się w formie warsztatów i ćwiczeń na rzeczywistych procesach firmy, w środowisku szkoleniowym z kopią zmigrowanych danych. Pracownik uczy się na własnych kontrahentach i indeksach, więc po starcie rozpoznaje ekrany oraz dokumenty. Szkolenie odbywa się przed uruchomieniem, a nie w tygodniu przełączenia.

Osobną grupą są administratorzy po stronie klienta. Znają procesy firmy i uczą się konfigurowania słowników i uprawnień, więc zmiany po starcie nie wymagają za każdym razem interwencji dostawcy.

Uruchomienie równoległe i przełączenie

Uruchomienie produkcyjne przenosi rolę systemu głównego na nowy ERP. Jego przygotowanie ogranicza ryzyko, że pierwszy dokument w nowym systemie okaże się jednocześnie pierwszym testem.

Uruchomienie równoległe

Uruchomienie równoległe polega na tym, że przez ustalony czas dokumenty powstają w obu systemach, a wyniki porównuje się codziennie. Drugi wariant to pilot obejmujący jeden oddział albo jeden moduł. Do porównania służy dzienny raport różnic, czyli zestawienie dokumentów, których suma w obu systemach się nie zgadza. Każda różnica ma przyczynę zapisaną w rejestrze: błąd danych, błąd konfiguracji albo zaokrąglenie. Praca w dwóch systemach podwaja wysiłek użytkowników, więc obejmuje się nią tylko procesy o największych konsekwencjach błędu i ogranicza do krótkiego okresu.

W okresie poprzedzającym przełączenie obowiązuje zamrożenie zmian w konfiguracji i w kartotekach systemu źródłowego. Każda zmiana wprowadzona po ostatnim imporcie próbnym musi zostać powtórzona w ERP ręcznie, co przy setkach rekordów jest źródłem pomyłek.

Przełączenie i opieka powdrożeniowa

Przełączenie odbywa się w oknie, w którym system źródłowy jest zamrożony. Ostatni import przenosi zmiany od czasu próbnego, po nim następuje uzgodnienie sum kontrolnych i decyzja o uruchomieniu (go/no-go). Plan powrotu do starego systemu obowiązuje tylko do chwili, gdy w nowym powstaną pierwsze dokumenty księgowe.

Po starcie następuje opieka powdrożeniowa: monitorowanie pracy, obsługa zgłoszeń użytkowników, okresowe kontrole wydajności i optymalizacja procesów. Warto zaplanować obecność konsultantów na miejscu w pierwszych tygodniach, bo część problemów wynika z organizacji pracy, a nie z konfiguracji. Przykład projektu podzielonego na cztery etapy pokazuje tekst o wdrożeniu systemu linkway.TMS, a przebieg projektu magazynowego opisuje artykuł o wdrożeniu systemu WMS.