Plan migracji typu cutover – dane statyczne a dynamiczne

(Część 4 z 6-częściowego cyklu „Podręcznik migracji”)
W części 3zbudowaliśmy silnik. Wyróżniliśmy Exchange Schemes jako preferowane narzędzie i zastosowaliśmy doktrynę DAL , aby zapewnić integralność danych.
Teraz stoimy w obliczu decydującego momentu całego projektu: weekendu uruchomienia.
To nie jest po prostu kolejny weekend roboczy. To wysoce zsynchronizowana sekwencja przełączeń trwająca od 48 do 72 godzin, w której każda minuta jest uwzględniona. Jeśli masz szczęście, dzieje się to w przerwie świątecznej, dając Ci strategiczne okno na uruchomienie systemu na początku stycznia.
Jeśli jednak masz mniej szczęścia (co zdarza się często), wystarczy standardowy weekendowy sprint: wyłączasz stary system w piątek o 18:00, a do poniedziałkowego poranka musisz uruchomić system ERP, sprawdzić jego poprawność i przygotować go do operacji biznesowych.
Jeśli spróbujesz improwizować w tym czasie, poniesiesz porażkę. Potrzebujesz scenariusza. Planu generalnego. Absolutnego punktu odniesienia , który dyktuje każdy ruch. Nazywamy ten dokument Planem Migracji Cutover.
Plan migracji Cutover: coś więcej niż tylko lista
Plan migracji Cutover to nie tylko lista zadań do wykonania. To harmonogram minutowy, który koordynuje działania konsultantów technicznych, użytkowników biznesowych, zespołu ds. infrastruktury i partnerów.
Możesz opracować ten plan, korzystając z narzędzia, które najlepiej pasuje do DNA Twojej organizacji. Niezależnie od tego, czy korzystasz z Microsoft Project dla precyzyjnego zarządzania kaskadowego, Notion dla elastyczności współpracy, czy po prostu ze wspólnego pliku Excel, zasada pozostaje ta sama.
Narzędzie jest kwestią drugorzędną, treść jest obowiązkowa.
Niezależnie od wybranego oprogramowania, solidny plan migracji typu Cutover musi zawierać co najmniej następujące kolumny dla każdego pojedynczego zadania:
- Identyfikator zadania i opis: (np. „Załaduj dane główne pozycji”, „Sprawdź wartość magazynową”).
- Właściciel: konkretna osoba odpowiedzialna. Musi to być osoba z imienia i nazwiska, nigdy ogólny dział.
- Godzina rozpoczęcia i czas trwania: szacunkowe (im mniej szacunkowe, tym lepiej).
- Zależności: „Zadanie B nie może się rozpocząć, dopóki zadanie A nie zostanie ukończone w 100%.”
- Kryteria walidacji: skąd wiemy, że zadziałało? (np. „Liczba wierszy jest zgodna ze starszą wersją”).
- Data przesłania: śledzi dokładny czas przesłania.
- Status: aktualny stan zadania (np. „Oczekujące”, „W toku”, „Zrobione”), który pozwala dokładnie określić, na jakim etapie jesteśmy.
- Notatki: ogólne pole umożliwiające dodawanie szczegółowych informacji, odchyleń lub szybkich spostrzeżeń w trakcie procesu.
Złota zasada: Jeśli zadanie nie znajduje się w Planie Migracji Cutover, nie zostanie zrealizowane. Żadnych „szybkich poprawek” ani „skoro tu jestem, to po prostu zaktualizuję ten parametr”. Dyscyplina to Twoja deska ratunku.
Strategia: statyczna kontra dynamiczna
Największym błędem jest próba załadowania wszystkiego w weekend startowy. Jest to fizycznie niemożliwe. Aby przetrwać, podzieliliśmy dane na dwie kategorie: statyczne i dynamiczne.
1. Dane statyczne
Dotyczy to danych podstawowych, które nie zmieniają się co minutę: pozycje, zestawienia materiałów, trasy, klienci, dostawcy, ceny.
Strategia jest taka: migrujemy te dane na N dni lub tygodnie przed uruchomieniem. Nie narzucamy sztywnego terminu. Termin ten ustala Klient na podstawie ilości danych do załadowania i złożoności kontroli walidacyjnych , które należy przeprowadzić.
- Wgrywamy cały zestaw do środowiska produkcyjnego.
- Sprawdzamy to spokojnie.
- Wprowadzamy okres „Podwójnej Konserwacji”. Jeśli użytkownik utworzy nowego Klienta w systemie Legacy w ciągu tych 2 tygodni, musi go również ręcznie utworzyć w systemie ERP.
- W weekend startu 80% danych jest już gotowe. Musimy się martwić tylko o dane transakcyjne.
2. Dane dynamiczne
To dane, które zmieniają się do ostatniej chwili: stany magazynowe, otwarte zamówienia i produkcja w toku (WIP). Można je tylko podczas przerwy w działaniu systemu.
Koszmar WIP: przeprowadzać się czy nie?
Migracja prac w toku (WIP) – zleceń produkcyjnych, które są w połowie ukończone na hali produkcyjnej – stanowi najbardziej złożone wyzwanie techniczne w każdym projekcie ERP.
Wyobraź sobie zamówienie na 100 sztuk. Operacja 1 (cięcie) jest wykonana. Operacja 2 (spawanie) jest wykonana w 50%. Operacja 3 (malowanie) pozostaje nienaruszona. Jak na przykład przenieść to do Infor LN ?
Opcja A: Strategia „Otwarcia linii produkcyjnej”: wstrzymanie realizacji nowych zamówień na 2 tygodnie przed uruchomieniem. Zmuszenie fabryki do zakończenia wszystkich otwartych linii produkcyjnych.
- Zalety: Zaczynasz od zera. Brak skomplikowanej logiki migracji.
- Wady: Nie zawsze jest to możliwe dla firm o długim terminie realizacji (np. produkujących maszyny, na które potrzeba 6 miesięcy).
Opcja B: Migracja „stanu operacji”: Jeśli konieczna jest migracja otwartego WIP, nie można po prostu wstawić rekordu z informacją „ukończono w 50%”. Należy zasymulować rzeczywistość w systemie ERP.
- Migracja zlecenia produkcyjnego w LN.
- Replikacja zużycia materiałów: nie można migrować transakcji. Należy ponownie wykonać wydanie w LN. W zależności od parametryzacji (wydawanie wsteczne lub ręczne), należy zgłosić ukończoną operację, aby uruchomić automatyczne wydanie, lub ręcznie wydać materiał, aby wyrównać saldo WIP.
- Migracja godzin: Wstrzyknij logikę, aby zarezerwować już wykorzystane godziny pracy.
- Wynik: Zamówienie w LN ma prawidłowy koszt i status, jest gotowe do następnej operacji.
Unikaj opcji B, jeśli możesz. Wymaga ona gruntownego testowania i często prowadzi do rozbieżności w kosztach. Jeśli możesz wybrać opcję A, zrób to.
Zakres zlecenia otwartego: Co oznacza „otwarty”?
W Części 1zdecydowaliśmy się na „ Czyste Cięcie”. Teraz musimy to ściśle egzekwować w Planie. Mówiąc „Otwarty Zakres”, mamy na myśli przyszłe zobowiązania, a nie historyczne zapisy. Migrujemy tylko to, co jest aktualne i wykonalne.
Ta logika ma zastosowanie uniwersalne do zamówień sprzedaży, zamówień zakupu, kontraktówi wszelkich innych otwartych zobowiązań. Nie migrujemy historii, lecz pozostałe saldo tego, co jeszcze nie zostało dostarczone lub odebrane.
Wreszcie, jeśli chodzi o zapasy, obowiązuje zasada finansowa: całkowita wartość importowanych zapasów powinna odpowiadać wartości w systemie klienta. W przypadku stwierdzenia rozbieżności należy przeanalizować deltę. Należy zawęzić różnicę, aby ustalić, czy wynika ona z problemów z zaokrąglaniem, czy z konkretnych rozbieżności kosztów. Dopasowanie kosztów i wycena zapasów to najbardziej delikatny etap procesu walidacji.
Punkt bez powrotu
W Planie migracji typu Cutover istnieje kamień milowy określony jako punkt bez odwrotu.
W tym momencie zbiera się Komitet Sterujący. Przeglądamy pulpit nawigacyjny:
- Dane statyczne: załadowane w 100%.
- Dane dynamiczne: załadowane w 100%.
- Uzgodnienie finansowe: Dopasowane.
- Problemy krytyczne: 0.
Jeśli odpowiedź brzmi „GO”, udostępniamy system użytkownikom. Nie ma odwrotu. System Legacy staje się tylko do odczytu. Jeśli odpowiedź brzmi „No-Go”, uruchamiamy Plan Wycofania. Odblokowujemy system Legacy, a firma kontynuuje pracę na starym systemie ERP w poniedziałek rano, jakby nic się nie stało.
Odwaga, by powiedzieć „Nie” to cecha, która odróżnia starszego partnera od młodszego dostawcy. Lepiej opóźnić się o tydzień niż zniszczyć firmę na rok.
Już prawie
Dane zostały załadowane. Salda się zgadzają. Punkt bez powrotu został przekroczony. W poniedziałek rano użytkownicy się zalogują. Zobaczą ekrany, które widzieli tylko na treningu. Będą zdenerwowani. Na pewno popełnią błędy.
Ale przede wszystkim system będzie zgłaszał błędy. W następnej części omówimy, jak je interpretować. Porozmawiamy o języku logów i najlepszych praktykach radzenia sobie z chaosem pierwszego tygodnia bez utraty rozumu.
Napisane przez Andreę Guaccio
2 kwietnia 2026 r