Za kulisami wdrożeń Go-live

Jak wygląda pierwszy dzień po uruchomieniu systemu ERP

Poniedziałek, 6:58. Pierwsza zmiana ustawia się przy terminalu. Ktoś nie pamięta hasła. Ktoś inny widzi ekran, którego nie było na szkoleniu. Za plecami rośnie kolejka, a telefon kierownika już drga. Za trzydzieści sekund rusza pierwszy dzień na nowym ERP — i zaraz okaże się, czy poprzednie pół roku było warte swojej ceny.

JT
Architekt systemów MES / WMS • 11 lat w branży

Pierwszy dzień po uruchomieniu systemu — nazywany w branży go-live — to moment, w którym cała abstrakcja projektu zamienia się w konkret. Do tej pory były prezentacje, konfiguracje, testy w bezpiecznym środowisku. Teraz są prawdziwe zamówienia, prawdziwi klienci czekający na wysyłkę i prawdziwi ludzie, którzy muszą wykonać swoją pracę w narzędziu, którego uczyli się dwa tygodnie.

Ten jeden dzień potrafi zbudować albo zniszczyć całe wdrożenie. Nie dlatego, że decyduje o funkcjach systemu — te były gotowe wcześniej. Dlatego, że decyduje o tym, jak ludzie zapamiętają nowy system. Pierwsze wrażenie na hali i w biurze rzutuje na miesiące adopcji. A jak pisałem w tekście Dlaczego operator produkcji nie ufa nowemu systemowi, jeden głośny błąd na starcie potrafi zniszczyć zaufanie, którego potem nie odbudujesz przez kwartał.

Sedno problemu: Pierwszy dzień nie rozgrywa się pierwszego dnia. Rozgrywa się w tygodniach przygotowań, które go poprzedziły. Kiedy o 7:00 rano zaczyna się panika, jest już za późno, żeby cokolwiek naprawić — można tylko gasić skutki decyzji podjętych wcześniej.

Prześledźmy ten dzień godzina po godzinie — najpierw w wersji, która idzie źle, a potem zobaczmy, co odróżnia ją od startu, który idzie dobrze. Bo różnica nie leży w szczęściu.

Pierwszy dzień, który idzie źle — godzina po godzinie

To złożenie scen, które powtarzają się przy wdrożeniach ruszonych bez wystarczającego przygotowania. Żadna z nich nie jest katastrofą sama w sobie. Katastrofą jest ich suma.

7:00 — pierwsze logowanie: Część ludzi nie pamięta haseł, część ma konta bez odpowiednich uprawnień. Zamiast pracować, stoją. Przy jednym terminalu robi się kolejka. Nastrój z ciekawości zmienia się w irytację, zanim ktokolwiek wprowadził pierwsze zamówienie.
8:30 — pierwsze realne transakcje: Okazuje się, że dane początkowe są niepełne. Brakuje indeksów, kontrahenci mają błędne dane, stany magazynowe nie zgadzają się z półką. Każda transakcja wymaga „obejścia”. Ludzie zaczynają dzwonić do kierownika, kierownik do wdrożeniowca.
10:00 — telefon się urywa: Wdrożeniowiec odbiera dziesiąte to samo pytanie. Nie nadąża. Problemy proste mieszają się z poważnymi i nikt ich nie segreguje. Kolejka zgłoszeń rośnie szybciej, niż da się je zamykać. Zaczyna się poczucie, że „system nie działa”.
12:00 — obejścia i panika: Żeby wysłać pilne zamówienia, ludzie wracają do starych metod: kartka, telefon, Excel. Powstaje drugi obieg obok systemu, już pierwszego dnia. To, co miało być jednym źródłem prawdy, zaczyna się rozjeżdżać z rzeczywistością.
15:00 — narracja porażki: Po hali i biurze krąży zdanie „ten system jest do niczego”. Zarząd słyszy o chaosie. Rodzi się presja, żeby „wrócić do tego, co było”. Merytoryczne problemy schodzą na drugi plan — liczy się już tylko emocja.
17:00 — pierwszy bilans: Dzień zamknięty na obejściach. Dane w systemie są dziurawe, bo połowa pracy poszła bokiem. Jutro zacznie się od prostowania dzisiejszego bałaganu. Zaufanie do systemu spadło, zanim ktokolwiek dał mu szansę.
Zwróć uwagę: Ani razu nie padło słowo „awaria”. System działał. Zawiodło przygotowanie — dane, uprawnienia, przećwiczone scenariusze, dostępne wsparcie. Pierwszy dzień tylko obnażył braki, które istniały już wcześniej.

Ten sam dzień oczami pięciu osób

Go-live to jeden z niewielu momentów, w których cała firma przeżywa to samo wydarzenie równocześnie — i każda rola przeżywa je zupełnie inaczej.

Użytkownik końcowy (biuro / hala): „Mam robotę do zrobienia, a nie wiem gdzie kliknąć.” Nie interesuje go architektura systemu. Interesuje go, czy wyśle dziś zamówienie, które obiecał klientowi. Każda sekunda blokady to dla niego realny stres, bo termin jest jego, nie systemu.
Kierownik działu: „Odpowiadam za to, żeby dział dziś dowiózł.” Stoi między swoimi ludźmi a zarządem. Widzi kolejkę, słyszy narzekania i wie, że wieczorem będzie tłumaczył wyniki. Jego pokusą jest szybki powrót do starych metod, żeby „dowieźć dziś” — kosztem całego wdrożenia.
Wdrożeniowiec: „Gaszę pożary i próbuję odróżnić realny błąd od braku wiedzy.” Pierwszego dnia jest najbardziej obciążoną osobą w firmie. Jeśli nie ma przy sobie superużytkowników, którzy przejmą proste pytania, tonie w zgłoszeniach i przestaje ogarniać te naprawdę ważne.
Prezes / właściciel: „Zainwestowałem duże pieniądze — czy to była dobra decyzja?” Pierwszego dnia jest najbardziej niecierpliwym obserwatorem. Widzi chaos i odbiera go jako zagrożenie dla inwestycji. Jego reakcja — spokój albo panika — potrafi przesądzić o losie wdrożenia.
IT / dział techniczny: „Sprawdzam, czy to problem systemu, czy człowieka.” Odpowiada za infrastrukturę: logowania, sieć, terminale, uprawnienia. Pierwszego dnia większość zgłoszeń, które do niego trafiają, to nie awarie, lecz braki w przygotowaniu kont i danych — o które nikt nie zadbał na czas.

Najtrudniejszą rolę ma tu kierownik działu. To on jest pod największą presją, żeby „na dziś” porzucić system i wrócić do starego obiegu. A każda taka decyzja, choć ratuje jeden dzień, podkopuje całe wdrożenie. O tym, kto powinien go w tym momencie osłonić, piszę w tekście Kto naprawdę odpowiada za sukces wdrożenia.

Dlaczego drobiazgi urastają do katastrofy

Pojedyncze problemy pierwszego dnia są banalne. Zapomniane hasło. Inny układ ekranu. Brakujący indeks. Gdyby zdarzyły się raz, nikt by ich nie zapamiętał. Problem w tym, że pierwszego dnia zdarzają się jednocześnie, wszystkim, pod presją czasu.

Pierwszy dzień nie testuje systemu. Testuje przygotowanie. System, który przez pół roku działał w testach, nie psuje się w poniedziałek rano. Psuje się złudzenie, że ludzie i dane są gotowi.

Mechanizm eskalacji jest prosty. Każdy drobiazg mnoży się przez liczbę użytkowników. Trzydzieści osób, które potrzebują pół minuty pomocy, to piętnaście minut ciągłego przerywania pracy jednej osobie wsparcia. A ponieważ wszyscy potrzebują jej naraz, tworzy się kolejka, kolejka tworzy stres, stres rodzi błędy, a błędy — kolejne zgłoszenia. Pętla się nakręca.

Efekt kuli śnieżnej: Jeden nieprzygotowany obszar — na przykład brakujące uprawnienia — potrafi zablokować cały dział na godzinę. W tej godzinie narasta zaległość, która ciągnie się przez resztę dnia. Pierwszy dzień nie wybacza braków, bo nie ma w nim czasu na spokojne prostowanie.
30 os.
po 30 sekund pomocy to 15 minut ciągłego przerywania jednej osobie wsparcia
1 godz.
blokady jednego działu, która ciągnie zaległość przez cały dzień
miesiące
utraty zaufania po jednym głośnym błędzie pierwszego dnia
1 próbny poranek
tydzień przed startem — ujawnia kolejki, zanim zrobią to klienci

Dwa scenariusze startu obok siebie

Najlepiej widać różnicę, gdy zestawi się start, który idzie źle, ze startem, który idzie dobrze. Uderza to, jak niewiele dzieli jedno od drugiego — i jak bardzo to niewiele decyduje.

Element Start, który idzie źle Start, który idzie dobrze
Dane początkowe Niepełne, niesprawdzone, rozjazd z rzeczywistością Zweryfikowane i uzgodnione ze stanem faktycznym przed startem
Konta i uprawnienia Zakładane rano, w pośpiechu, z błędami Przygotowane i przetestowane z wyprzedzeniem
Szkolenie Na abstrakcyjnym demie, dawno temu Na własnych, realnych przypadkach, tuż przed startem
Wsparcie pierwszego dnia Jeden wdrożeniowiec na całą firmę, przez telefon Superużytkownicy w każdym dziale plus wsparcie na miejscu
Plan awaryjny Brak — panika i powrót do Excela Ustalona ścieżka na pilne przypadki, bez porzucania systemu
Zakres startu Cała firma naraz, całe ryzyko w jednym dniu Etapowo lub z okresem pracy równoległej na krytycznych procesach

Żaden z tych elementów nie jest kosztowny ani trudny. Wszystkie wymagają jedynie tego, żeby zająć się nimi wcześniej, a nie w dniu startu. To dlatego mówię, że dobry go-live jest nudny — cała dramaturgia została z niego usunięta na etapie przygotowań.

Co odróżnia dobry start od katastrofy

Sprowadza się to do kilku decyzji podjętych przed dniem startu. Nie do heroizmu pierwszego dnia, lecz do spokojnej pracy w tygodniach poprzedzających.

Dane, które zgadzają się z rzeczywistością

Zanim ktokolwiek się zaloguje, stany magazynowe, indeksy i kontrahenci muszą odpowiadać temu, co jest naprawdę. System, który pierwszego dnia pokazuje zły stan, traci wiarygodność natychmiast. O tym rozjeździe piszę w tekście Dane w ERP kontra rzeczywistość na hali.

Przećwiczone najczęstsze scenariusze

Każdy użytkownik powinien przed startem samodzielnie przejść swoje typowe czynności na realnych danych. Nie „obejrzeć, jak się to robi”, lecz zrobić to własnymi rękami. Wiedza z demonstracji ulatnia się pod presją; wiedza z własnego działania zostaje.

Superużytkownicy w każdym dziale

Kilka osób przeszkolonych głębiej niż reszta, które pierwszego dnia gaszą proste problemy na miejscu. Dzięki nim wdrożeniowiec zajmuje się tylko realnymi błędami, a nie dziesiątym pytaniem „gdzie to kliknąć”. To najskuteczniejszy bufor przeciw kolejce zgłoszeń.

Realistyczny plan na pilne przypadki

Musi istnieć ustalona ścieżka na sytuację „klient czeka, a coś nie działa” — taka, która nie oznacza porzucenia systemu i powrotu do Excela. Bez niej pierwsza pilna sprawa uruchamia panikę i drugi obieg, który potem trudno wygasić.

Spokój na górze

Reakcja zarządu pierwszego dnia jest zaraźliwa. Prezes, który widzi drobne potknięcia i mówi „to normalne, idziemy dalej”, stabilizuje firmę. Prezes, który panikuje, uruchamia lawinę. Przygotowanie decydentów na to, że pierwszy dzień nie będzie idealny, jest częścią planu startu.

Wyznacznik dobrego startu: Pod koniec pierwszego dnia dane w systemie są kompletne, bo prawie nikt nie musiał obchodzić systemu. Pytania były, ale dotyczyły obsługi, nie błędów. Nikt nie powiedział „wracamy do tego, co było”. To nie szczęście — to skutek przygotowania.

Big bang czy etapami — jak rozłożyć ryzyko

Jedna z najważniejszych decyzji dotyczy tego, ile ryzyka skumulować w pierwszym dniu. Start jednoczesny w całej firmie jest kuszący, bo szybki i „czysty”. Ale przenosi całe ryzyko na jeden poranek.

Start jednoczesny (big bang)

  • Całe ryzyko skupione w jednym dniu.
  • Wsparcie rozproszone na wszystkich naraz.
  • Jeden nieprzygotowany obszar blokuje resztę.
  • Trudno się uczyć — od razu gra się o wszystko.
  • Powrót do starego obiegu oznacza porażkę całości.

Start etapowy / praca równoległa

  • Ryzyko rozłożone na kolejne obszary.
  • Wsparcie skoncentrowane tam, gdzie akurat startuje.
  • Problemy jednego działu nie kładą całej firmy.
  • Wnioski z pierwszego etapu poprawiają kolejne.
  • Krytyczne procesy mają siatkę bezpieczeństwa.

Nie ma jednej dobrej odpowiedzi dla wszystkich. Mniejsza firma z prostym procesem może bezpiecznie ruszyć big bangiem. Firma produkcyjna z wieloma powiązanymi działami niemal zawsze zyskuje na wariancie etapowym albo na okresie pracy równoległej na najważniejszych procesach. Kluczowe jest, żeby tę decyzję podjąć świadomie, a nie domyślnie.

Lista kontrolna na dzień przed startem

Jeśli miałbym sprowadzić przygotowanie do jednej listy, którą warto przejść dzień przed go-live, wyglądałaby tak. Każde „nie” na tej liście to potencjalny pożar następnego ranka.

  • Wszystkie konta założone, uprawnienia nadane i przetestowane realnym logowaniem.
  • Stany magazynowe i indeksy zgodne z rzeczywistością — sprawdzone, nie zadeklarowane.
  • Każdy użytkownik samodzielnie przeszedł swoje najczęstsze czynności na danych realnych.
  • Superużytkownicy wyznaczeni i wiedzą, że pierwszego dnia gaszą proste pytania.
  • Ustalona ścieżka zgłaszania problemów — kto, do kogo, jak segregowane.
  • Plan na pilne przypadki, który nie oznacza powrotu do Excela.
  • Zarząd uprzedzony, że pierwszy dzień nie będzie idealny — i że to normalne.
  • Uwaga: jeśli dane nie są jeszcze zgodne z rzeczywistością — przesuń start, nie ruszaj.
  • Uwaga: jeśli nikt nie przećwiczył swoich realnych przypadków — szkolenie było teatrem, nie przygotowaniem.
  • Praktyczna wskazówka: Zrób „próbny poranek” na tydzień przed startem — kilkanaście osób loguje się o tej samej godzinie i wykonuje realne czynności równocześnie. To ujawni kolejki, brakujące uprawnienia i wąskie gardła, zanim zrobią to prawdziwi klienci czekający na wysyłkę.

    Podsumowanie

    Pierwszy dzień po uruchomieniu ERP wygląda dramatycznie tylko wtedy, gdy przygotowanie było niewystarczające. Kolejka przy terminalu, urywający się telefon do wdrożeniowca i narracja „system jest do niczego” nie są skutkiem awarii — są skutkiem braków w danych, uprawnieniach, szkoleniu i wsparciu, które ujawniają się dopiero pod presją realnej pracy.

    Dobry start jest nudny. Nie dlatego, że nic się nie dzieje, lecz dlatego, że wszystko, co mogło pójść źle, przewidziano wcześniej. Zweryfikowane dane, przećwiczone scenariusze, superużytkownicy gaszący drobiazgi, plan na pilne przypadki i spokój na górze — to nie luksus, to fundament.

    Pierwszy dzień nie rozgrywa się pierwszego dnia. Rozgrywa się w tygodniach, które go poprzedziły. Kto to rozumie, przechodzi go-live tak spokojnie, że pod wieczór zastanawia się, czego się tak bał. Kto tego nie rozumie, spędza pierwszy dzień na gaszeniu pożarów, których źródło zostało zaprószone dawno wcześniej.

    Najczęstsze pytania

    Dlaczego pierwszy dzień po uruchomieniu ERP bywa chaotyczny?
    Bo w jednym momencie dziesiątki ludzi po raz pierwszy robią realną pracę w nowym narzędziu, pod presją bieżących zamówień. Nawet drobne rzeczy — zapomniane hasło, inny układ ekranu, brakujące uprawnienie — mnożą się przez liczbę użytkowników i tworzą kolejki oraz panikę. Chaos pierwszego dnia rzadko wynika z awarii systemu; najczęściej z niedostatecznego przygotowania ludzi i danych.
    Co najbardziej decyduje o udanym starcie systemu?
    Przygotowanie na długo przed dniem startu: poprawne dane początkowe, przećwiczone najczęstsze scenariusze, dostępne wsparcie na miejscu i realistyczny plan awaryjny. Dobry go-live jest nudny, bo wszystko zostało przewidziane wcześniej. Katastrofa to zwykle skutek startu na niesprawdzonych danych i bez ludzi gotowych gasić drobne pożary w pierwszych godzinach.
    Czy warto uruchamiać ERP od razu w całej firmie?
    Zależy od skali i ryzyka. Start jednoczesny (big bang) jest szybszy, ale kumuluje całe ryzyko w jednym dniu. Start etapowy — dział po dziale lub proces po procesie — rozkłada ryzyko i pozwala uczyć się na mniejszej grupie. Dla większości firm produkcyjnych bezpieczniejszy jest wariant etapowy albo przynajmniej okres równoległej pracy starego i nowego obiegu na krytycznych procesach.
    Jak przygotować pracowników na pierwszy dzień z nowym systemem?
    Szkolenie na realnych, ich własnych przypadkach, a nie na abstrakcyjnym demie. Każdy powinien przed startem samodzielnie przejść swoje najczęstsze czynności. Warto wyznaczyć superużytkowników w każdym dziale, którzy pierwszego dnia gaszą proste problemy, zanim urośnie kolejka do wdrożeniowca. Kluczowe jest też jasne powiedzenie ludziom, gdzie i jak zgłaszać problemy.
    Czy telefon do wdrożeniowca pierwszego dnia oznacza, że wdrożenie się nie udało?
    Nie. Pytania pierwszego dnia są normalne — nikt nie nauczy się nowego narzędzia bez potknięć. Sygnałem ostrzegawczym jest dopiero to, gdy telefony dotyczą rzeczy, które powinny być rozwiązane przed startem: błędne dane, brakujące uprawnienia, procesy, których nikt nie przećwiczył. Wtedy problemem nie jest pierwszy dzień, lecz przygotowanie, którego zabrakło wcześniej.

    Przygotuj start systemu tak, żeby był nudny

    Pomagam firmom przejść przez go-live bez paniki — od weryfikacji danych, przez przećwiczenie scenariuszy, po plan wsparcia pierwszego dnia. Dobry start to nie szczęście, tylko przygotowanie. Umów bezpłatną rozmowę wstępną.

    Zaplanujmy bezpieczny go-live