Wyobraźmy sobie przegląd przed uruchomieniem systemu: zespół wdrożeniowy zgłasza zakończenie prac, ale właściciel procesu nie potrafi potwierdzić, że użytkownicy poradzą sobie z wyjątkami, a partner nie potwierdził, kto zapewni wsparcie po starcie. Sponsor nie powinien traktować zakończenia prac wdrożeniowych jako zgody na rozpoczęcie eksploatacji.
Zatwierdź uruchomienie ERP, gdy właściciele procesów biznesowych potrafią wykazać gotowość operacyjną, a zespół wsparcia może przejąć odpowiedzialność za nierozwiązane ryzyka. Odrocz start, jeśli krytyczny proces zależy od nieprzygotowanych użytkowników, niedostępnych specjalistów lub niesprawdzonej ścieżki eskalacji. Zgoda warunkowa ma sens pomiędzy tymi decyzjami tylko wtedy, gdy warunki są jednoznaczne i można je wyegzekwować.
Ta lista kontrolna gotowości do uruchomienia ERP dotyczy zgody na rozpoczęcie pracy produkcyjnej. Uzupełnia, ale nie zastępuje zatwierdzenia technicznego przełączenia na nowy system, uzgodnienia danych ani planowania odtworzenia działania. Następuje też po decyzji o usprawnieniu lub wymianie ERP: teraz należy ustalić, czy organizacja potrafi pracować w dostarczanej wersji systemu.
Oddziel akceptację właściciela procesu od zakończenia prac wdrożeniowych
Poproś właściciela każdego krytycznego procesu o oświadczenie o akceptacji obejmujące rzeczywisty zakres uruchamianej wersji. Powinno ono wskazywać zweryfikowane przebiegi pracy, zaangażowanych użytkowników, pozostałe ograniczenia oraz obejścia, które właściciel jest gotów stosować. Raport kierownika projektu o zakończeniu testów powinien być podstawą tej oceny, a nie ją zastępować.
Różnica dotyczy odpowiedzialności. Konsultant funkcjonalny może wyjaśnić, jak działa skonfigurowany proces; właściciel biznesowy powinien zdecydować, czy proponowana procedura operacyjna jest akceptowalna. Wymagaj obu perspektyw tam, gdzie działalność zależy od przekazywania pracy między zespołami.
Przykładowo, podczas hipotetycznego przeglądu obsługi zamówień poproś użytkowników o zademonstrowanie standardowego przebiegu pracy oraz wyjątku wymagającego interwencji. Następnie ustal, kto rozpoznaje wyjątek, kto zatwierdza reakcję i kto potwierdza możliwość wznowienia pracy. To ćwiczenie służy akceptacji operacyjnej, a nie pełnemu testowi integracji czy uzgodnienia danych.
Zapisuj zastrzeżenia zamiast oznaczać dany obszar jako gotowy. Jeśli właściciel procesu nie może zaakceptować sposobu pracy, ustal, czy przeszkodą jest brak przygotowania, nierozwiązany błąd czy nieakceptowalna procedura operacyjna. Kolejne działanie powinno odpowiadać właśnie na tę przeszkodę. Następna demonstracja zespołu wdrożeniowego nie rozwiąże problemu, jeśli brakuje dowodu umiejętności użytkowników.
Sprawdź przygotowanie użytkowników, nie tylko obecność na szkoleniu
Praktyk ERP Francesco Perrotta wskazuje, że niedocenianie szkoleń jest problemem, który wielokrotnie obserwował w swojej pracy. Wiąże go z nieefektywnym wykorzystaniem systemu i ograniczeniem korzyści z wdrożenia. Wniosek dla decyzji o starcie jest praktyczny: wymagaj dowodów, że użytkownicy potrafią wykonywać swoje zadania, a nie jedynie potwierdzenia przeprowadzenia szkoleń.
Poproś osobę odpowiedzialną za szkolenia o przypisanie ról objętych zmianą do zadań, które będą wykonywane od uruchomienia systemu. Oceniaj frekwencję razem z wynikami ćwiczeń praktycznych, nierozstrzygniętymi pytaniami, planem uzupełnienia szkoleń i dostępem do aktualnych instrukcji. Uwzględnij zastępców oraz użytkowników spoza głównej grupy projektowej. Przygotowanie użytkownika kluczowego nie powinno być traktowane jako dowód gotowości całego zespołu operacyjnego.
Najbardziej przekonującym dowodem jest demonstracja zadania przez osoby, które mają je wykonywać, z wykorzystaniem procedury i uprawnień przewidzianych do pracy produkcyjnej. Poproś je o wyjaśnienie, kiedy przerwałyby pracę, wystąpiły o zgodę lub zgłosiły problem do wsparcia. Prezentacja i lista obecności pozostają przydatną dokumentacją, ale nie odpowiadają na te pytania.
Ustal kryteria akceptacji na podstawie konsekwencji błędu w każdej roli. W przypadku zadania krytycznego wymagaj od właściciela procesu wskazania pozostałej luki w przygotowaniu oraz jej skutków operacyjnych. Jeśli użytkownicy potrzebują dodatkowych ćwiczeń pod nadzorem, wyznacz osobę odpowiedzialną i zweryfikuj rezultat przed zatwierdzeniem startu. Jeśli proponowane jest obejście, sprawdź, czy stosujące je osoby rozumieją jego ograniczenia, a jego właściciel akceptuje dodatkowe obciążenie pracą.
Potwierdź dostępność wsparcia i przećwicz eskalację
Perrotta ostrzega również, że niektórzy partnerzy mają problemy z przydzielaniem personelu z powodu zbyt wielu projektów. W rezultacie klient może nie mieć dostępu do potrzebnej osoby, gdy pojawi się konieczność uzyskania wsparcia. Nie jest to powód do odrzucenia partnera ze względu na jego wielkość. To powód, aby na etapie decyzji o uruchomieniu zweryfikować rzeczywistą dostępność zespołu.
Poproś o harmonogram obsady wsparcia z nazwiskami osób po stronie organizacji i partnera, zakresem odpowiedzialności, godzinami dostępności oraz zastępcami. Poproś przełożonych o potwierdzenie, że wewnętrzni specjaliści mają zarezerwowany czas na wsparcie obok zwykłych obowiązków. Od partnera wymagaj wskazania osób odpowiedzialnych za wsparcie funkcjonalne i techniczne tej wersji, zamiast przyjmować ogólne zapewnienie o istnieniu zespołu wsparcia.
Jeśli pierwotna oferta nie precyzuje tych obowiązków, wróć do weryfikacji zespołu i dostępności przy wyborze partnera. Przy uruchomieniu nie chodzi już o ogólne kompetencje dostawcy. Chodzi o to, czy potrzebne osoby mogą reagować na problemy w konkretnym zakresie operacyjnym.
Przećwicz eskalację na hipotetycznym przykładzie zakłócenia działalności. Użytkownik powinien zgłosić problem, service desk skierować go do odpowiednich osób, a odpowiedzialni specjaliści wyjaśnić dalsze kroki. Potwierdź, kto ocenia wpływ na działalność, kto zatwierdza obejście i kto informuje dotknięte problemem zespoły operacyjne. Nie utożsamiaj przypisania zgłoszenia z przejęciem odpowiedzialności za przywrócenie pracy biznesowej.
Przy przekazaniu do utrzymania poproś kierownika przejmującego wsparcie o akceptację procedur, dostępów, rejestru znanych problemów i kontaktów do eskalacji. Wiadomość potwierdzająca wysłanie dokumentacji jest słabszym dowodem niż potwierdzenie, że zespół przejmujący potrafi z niej korzystać. Jeśli odpowiedzialność pozostaje sporna, rozstrzygnij ją, zanim poprosisz sponsora o akceptację ryzyka.
Zarezerwuj zasoby na stabilizację i kolejne aktualizacje
Zdefiniuj stabilizację jako zestaw prac z przypisaną odpowiedzialnością, a nie po prostu okres w harmonogramie projektu. Wskaż, kto będzie klasyfikować i priorytetyzować problemy produkcyjne, pomagać użytkownikom, zatwierdzać zmiany oraz aktualizować instrukcje operacyjne. Oddziel pilne przywracanie działania od wniosków o usprawnienia, aby te same osoby nie były domyślnie zobowiązane do obu rodzajów pracy bez ustalenia priorytetów.
Stała odpowiedzialność wykracza również poza pierwsze uruchomienie. Podczas dyskusji społeczności Microsoft Dynamics Steve Goodwin opisał rozmowy potrzebne do wyjaśnienia kadrze zarządzającej procesu aktualizacji platformy, zarządzania funkcjami oraz możliwości dostępnych dla organizacji. To relacja klienta osadzona w konkretnym kontekście, a nie dowód typowego przebiegu wdrożenia ERP.
Praktyczny wniosek jest taki, że kierownictwo powinno rozumieć także obowiązki po starcie. Ustal, kto będzie analizować istotne aktualizacje, oceniać ich wpływ na działalność, koordynować testy i przygotowywać użytkowników do zaakceptowanych zmian. Zarezerwuj zasoby na te obowiązki, zamiast zakładać, że zakończenie wdrożenia oznacza koniec potrzeby udziału biznesu.
Uzgodnij, jakie dowody pozwolą przejść ze wzmożonego wsparcia stabilizacyjnego do normalnego utrzymania. Warto ustalić, czy dla krytycznych problemów zaakceptowano sposób dalszego postępowania, czy odpowiedzialność za wsparcie działa w praktyce i czy właściciele procesów radzą sobie z pozostałym obciążeniem. Dobierz kryteria do uruchamianej wersji; nie zastępuj decyzji o akceptacji arbitralnym upływem czasu.
Zapisz nazwiska odpowiedzialnych osób i nierozwiązane ryzyka w protokole decyzji
Wykorzystaj poniższy arkusz jako narzędzie wspierające decyzję sponsora. Zastąp nazwy ról nazwiskami, dodaj odnośniki do dowodów i określ pozostałe ryzyko. Nie przekształcaj wierszy w punktację, która pozwala ukryć poważną lukę operacyjną w średnim wyniku.
| Obszar decyzji | Osoba odpowiedzialna do wskazania | Dowody do oceny | Nierozwiązane ryzyko do zapisania |
|---|---|---|---|
| Akceptacja procesu | Właściciel procesu biznesowego | Zaakceptowany zakres przebiegu pracy, wyjątki i obejścia | Zadania, których biznes nie potrafi jeszcze bezpiecznie realizować |
| Przygotowanie użytkowników | Osoba odpowiedzialna za szkolenia i przełożony | Wyniki ćwiczeń według ról, działania uzupełniające i dostępne instrukcje | Zadania, których użytkownicy nie potrafią jeszcze wykonać lub eskalować |
| Dostępność personelu | Kierownik wsparcia wewnętrznego i osoba odpowiedzialna po stronie partnera | Imienna obsada, zakres dostępności i zastępcy | Obowiązki bez obsady lub kolidujące zobowiązania |
| Eskalacja i przekazanie do utrzymania | Kierownik zespołu przejmującego wsparcie | Przećwiczona ścieżka przekazywania zgłoszeń i zaakceptowane materiały wsparcia | Niejasne uprawnienia do przywrócenia działania lub brak dostępu |
| Stabilizacja i aktualizacje | Właściciel aplikacji | Zarezerwowane zasoby, priorytety i kryteria przejścia do normalnego utrzymania | Prace związane ze wsparciem lub aktualizacjami bez przypisanej osoby odpowiedzialnej |
Przydatny sposób dokumentowania decyzji zawiera szablon decyzji o gotowości do uruchomienia: przy zgodzie warunkowej zapisuje się warunek, osobę odpowiedzialną, termin, osobę weryfikującą i konsekwencję niespełnienia warunku. Wykorzystaj ten mechanizm, aby odróżnić rzeczywistą zgodę warunkową od nieformalnej obietnicy dokończenia prac później.
Zatwierdź start, gdy dowody potwierdzają gotowość do pracy produkcyjnej, a pozostałe ryzyka zostały zaakceptowane przez wskazane osoby odpowiedzialne. Stosuj warunki do jasno ograniczonych luk, których usunięcie można zweryfikować przed rozpoczęciem objętej nimi czynności. Odrocz uruchomienie, jeśli krytyczny obowiązek operacyjny nadal nie ma zapewnionego wsparcia. Zapisz powód, działanie naprawcze i dowody potrzebne do kolejnej decyzji, a nie tylko nową datę.
Przed spotkaniem zatwierdzającym poproś właścicieli wszystkich krytycznych procesów oraz kierownika przejmującego wsparcie o przedstawienie dowodów i nierozwiązanych ryzyk w jednym protokole decyzji. Jeśli do zamknięcia tych luk potrzebujesz dodatkowych zasobów funkcjonalnych lub technicznych, porozmawiaj ze specjalistami ERP Digiventi o zakresie uruchomienia i odpowiedzialności za wsparcie.
