Większość wdrożeń ERP w MŚP nie zawodzi w dniu startu. Zawodzi w pierwsze cztery tygodnie po nim — kiedy dostawca już podpisał protokół odbioru, a Twoi ludzie dopiero zaczynają używać systemu na prawdziwych zamówieniach. Ten okres ma nazwę: hypercare. I prawie nikt go nie planuje.
Scenariusz, który widzimy nagminnie, wygląda tak: po pół roku projektu podpisujecie dokumenty odbiorowe w piątek, w poniedziałek system idzie na produkcję, konsultant dostawcy jest „pod telefonem", ale w praktyce już w kolejnym projekcie u innego klienta. Twoi ludzie w tym czasie uczą się nowego systemu na żywym organizmie — i co kilka godzin wpadają na coś, co w testach nie wyszło, bo nikt nie testował wariantu „faktura zaliczkowa dla kontrahenta spoza UE z kaucją za opakowania zwrotne".
Hypercare to nie jest luksus. To różnica między wdrożeniem, które po trzech miesiącach działa, a wdrożeniem, które po trzech miesiącach wraca do konsultanta ze słowami „coś to u nas nie wychodzi".
Co to w ogóle jest hypercare
Hypercare to zdefiniowany okres bezpośrednio po starcie produkcyjnym — zwykle 2 do 6 tygodni — w którym projekt jest formalnie „zakończony", ale faktycznie wciąż trwa w trybie wzmożonej obserwacji. Zespół wdrożeniowy nie znika, tylko przechodzi w inny tryb pracy. Zgłoszenia są obsługiwane w godzinach, nie w dniach. Jest jedna osoba po Twojej stronie, która zbiera wszystkie problemy. Są codzienne krótkie spotkania, nie tygodniowe statusy.
W kontrakcie z dostawcą hypercare powinien być osobną pozycją — z czasem reakcji, zakresem, dostępnością konsultanta i jasnym momentem, kiedy się kończy. Jeśli oferta kończy się na „24-miesięcznym serwisie SLA" bez wyodrębnionego hypercare, dostaniesz obsługę ticketową z czasem reakcji „do 2 dni roboczych" — a to nie wystarczy, kiedy magazyn stoi, bo nie da się zatwierdzić wydania.
- Hypercare to nie to samo co „gwarancja wdrożeniowa" — gwarancja chroni Cię przed błędami, hypercare przed codziennym tarciem.
- Hypercare to nie szkolenia — szkolenia powinny być zrobione przed startem.
- Hypercare to nie serwis SLA — SLA zacznie się później.
Przykład z życia — 25-osobowa hurtownia materiałów budowlanych
U jednego z naszych klientów — 25-osobowej hurtowni pokryć dachowych w Mazowieckiem — zrobiliśmy migrację z Subiekta do Comarch Optima z WMS-em. Projekt sam w sobie szedł cztery miesiące, test odbiorowy przeszedł czysto, start produkcyjny w poniedziałek rano.
W pierwszym tygodniu wyszło, że 40% faktur dla jednej grupy produktowej (akcesoria dekarskie) miało złą stawkę VAT — pole „stawka" migrowało się ze starej kartoteki, ale w nowej strukturze towarów zabrakło mapowania dla dwóch podgrup. Nikt tego nie wyłapał w testach, bo testy robiliśmy na top-50 produktach, a te akcesoria mają 180 kodów, każdy po 2-3 faktury miesięcznie. Łącznie 60 wystawionych faktur do korekty w pierwsze cztery dni.
W trzecim tygodniu wyszedł drugi problem — magazyn drukował dokumenty WZ, ale nie klikał „zatwierdź" w nowym systemie, bo w Subiekcie ten krok robił się automatycznie. Przez dwa tygodnie w bazie było 320 „otwartych" wydań, które z punktu widzenia księgowości jeszcze nie istniały.
Oba problemy zostały rozwiązane w ciągu doby, bo mieliśmy włączony hypercare: codzienne 15-minutowe spotkania o 9:00, jedna osoba (key user z działu sprzedaży) zbierała zgłoszenia, konsultant techniczny dostępny na Teamsie w godzinach 8-16. Po czterech tygodniach lista problemów skurczyła się z 23 pozycji dziennie do 2-3. Wtedy — i dopiero wtedy — przełączyliśmy się na zwykły tryb serwisowy.
Gdybyśmy odebrali projekt w piątek i powiedzieli „dzwońcie, jak coś", to te 60 faktur zostałoby wysłanych do klientów. A rozmowa po miesiącu nie byłaby już o korektach, tylko o kontroli skarbowej.
Co zaplanować, zanim ruszysz z produkcją
Hypercare planuje się przed startem, nie w jego trakcie. Jeśli zaczniesz myśleć o nim w drugim tygodniu po go-live, jest już za późno — Twoi ludzie są zmęczeni, konsultant już jest w innym projekcie, a Ty gasisz pożary.
Minimum, które warto wpisać do kontraktu i do kalendarza:
- Czas trwania. Dla prostego wdrożenia (sama wymiana ERP w firmie do 30 osób) wystarczą 3 tygodnie. Dla wdrożenia z integracjami (ERP + WMS + sklep internetowy + bank) planuj 6 tygodni.
- Dostępność konsultanta. Nie „pod telefonem", tylko konkretne godziny (np. 8-16 w dni robocze) i konkretny kanał (Teams, Slack, dedykowany adres mailowy — nie ticket w panelu).
- Czas reakcji. Dla błędów blokujących pracę — do 2 godzin. Dla pozostałych — do końca dnia roboczego. To osobne SLA niż serwis długoterminowy.
- Jedna osoba po Twojej stronie. Key user, który zbiera wszystkie zgłoszenia, filtruje duplikaty i decyduje, co jest pilne. Bez tego konsultant tonie w pytaniach od 15 osób naraz, które pytają o to samo.
- Codzienne 15-minutowe spotkania. Nie co tydzień, nie „jak będzie potrzeba". Codziennie, o stałej godzinie, przez cały okres hypercare. Jak nie ma tematów — kończy się po 5 minutach. Jak są — nie zbiera się bałaganu na trzy dni.
- Rejestr zgłoszeń. Prosty arkusz albo lista w zgłoszeniach — co, kto zgłosił, status, kto rozwiązuje, data zamknięcia. Bez tego po dwóch tygodniach nikt nie pamięta, co było naprawione, a co dalej wisi.
- Stare systemy w trybie read-only. Nie wyłączaj Subiekta/starego Dynamics-a w dniu startu. Zostaw go dostępnego do odczytu przez minimum 60 dni. To Twoja polisa — jak coś w nowym systemie nie zgrało się z historią, zawsze możesz podejrzeć.
Co mierzyć w czasie hypercare
Hypercare bez pomiaru to tylko intuicja. A intuicja mówi „coś mi się wydaje, że działa gorzej" — co jest fatalnym argumentem w rozmowie z dostawcą.
Trzy liczby, które warto zbierać codziennie:
- Liczba otwartych zgłoszeń. Powinna rosnąć w pierwszym tygodniu, stabilizować się w drugim, spadać od trzeciego. Jak nie spada — hypercare trzeba przedłużyć albo w systemie siedzi coś większego niż „ludzie się uczą".
- Czas do zamknięcia zgłoszenia. Mediana, nie średnia (jeden tydzień zawieszonego ticketu zepsuje średnią). Celuj w 1 dzień roboczy dla błędów, 3 dni dla usprawnień.
- Liczba faktur / dokumentów do korekty. To realny wskaźnik, że system działa poprawnie na produkcji. Zero nie będzie, ale tendencja powinna być spadkowa z tygodnia na tydzień.
Dodaj do tego tygodniowe spotkanie podsumowujące z zarządem, na którym pokazujesz te trzy liczby. To nie jest zbędna biurokracja — to jest sposób, żeby zarząd nie zaczął w panice szukać winnego, bo „pół firmy mówi, że nowy system jest beznadziejny". Dane rozbrajają emocje.
Kiedy formalnie zamknąć hypercare
Hypercare kończy się nie wtedy, kiedy mija zaplanowany termin, tylko kiedy spełnione są trzy warunki jednocześnie: liczba zgłoszeń dziennie spadła poniżej ustalonego progu (np. 3), żaden z otwartych tematów nie blokuje operacji, kluczowi użytkownicy potwierdzają, że „to się już daje używać". Dopiero wtedy przechodzisz na normalny tryb serwisowy — z czasem reakcji w dniach, nie godzinach.
To zamknięcie powinno być formalne: protokół, kto podpisuje (po stronie Twojej i dostawcy), lista otwartych tematów przeniesionych do backlogu i jasne powiedzenie, że od jutra kontakt idzie przez standardowe zgłoszenia. Bez takiego momentu hypercare dryfuje — konsultant „jeszcze dopina", a Ty myślisz, że to normalna sytuacja, kiedy po trzech miesiącach wciąż są codzienne telefony.
Wdrożenie nie kończy się w dniu podpisania odbioru. Kończy się wtedy, kiedy ludzie przestają mówić „a jak to się robi w nowym systemie", bo po prostu wiedzą.
Dzień startu to nie koniec projektu, tylko koniec jego pierwszego etapu. Prawdziwy test jest w czwartym tygodniu, kiedy wszyscy już myśleli, że jest spokój.