Dlaczego projekty ERP kończą się niepowodzeniem, mimo że sam system wydaje się właściwy?
Projekty ERP często kończą się niepowodzeniem, ponieważ organizacja nie potrafi prawidłowo oszacować, ile czasu, odpowiedzialności i zaangażowania w podejmowanie decyzji będzie potrzebne po jej stronie, aby system rzeczywiście działał tak, jak powinien. Według szacunków Gartnera od 55% do 75% wszystkich projektów ERP kończy się niepowodzeniem. Partner wdrożeniowy może skonfigurować Dynamics 365, Business Central lub inną platformę ERP, ale tylko firma może potwierdzić, jak powinny przebiegać procesy, którym danym można zaufać i które decyzje są kluczowe.
Tutaj tkwi ukryty problem zasobów w projektach ERP.
Znaczna część liderów wie, że wdrożenie ERP będzie wymagało udziału project managerów, konsultantów i specjalistów systemowych. Ale już rzadziej odpowiednio planuje się zaangażowanie osób wewnątrz organizacji, które posiadają praktyczną wiedzę o jej działaniu: liderów finansów, managerów operacyjnych, kierowników magazynów, planistów łańcucha dostaw, zespołów produkcyjnych, liderów obsługi klienta czy właścicieli danych. Osoby te zazwyczaj muszą wykonywać dwie prace jednocześnie.
Nadal muszą zamykać miesiąc, realizować zamówienia, zarządzać zapasami, rozwiązywać problemy klientów, wspierać zespoły i realizować cele biznesowe. Jednocześnie oczekuje się od nich udziału w warsztatach projektowych, oceny przyszłych procesów, walidacji zmigrowanych danych, testowania rzeczywistych scenariuszy, kwestionowania błędnych założeń i zatwierdzania decyzji, które mogą wpływać na sposób działania firmy przez wiele lat.
Na początku projektu ta presja nie wydaje się poważnym ryzykiem. Pojawia się stopniowo i często niemal niezauważalnie. Właściciel procesu nie uczestniczy w warsztacie, więc decyzja zostaje podjęta bez jego wiedzy i odpowiedniej weryfikacji. Lider finansów tylko pobieżnie przegląda pakiet danych do walidacji, ponieważ trwa zamknięcie miesiąca. Kierownik magazynu zatwierdza proces, który dobrze wygląda na papierze, ale nie sprawdza się przy rzeczywistym obciążeniu podczas kompletacji. Kluczowy użytkownik zatwierdza testy dlatego, że zbliża się termin, a nie dlatego, że dany scenariusz został rzeczywiście sprawdzony. Każda z tych sytuacji z osobna pozornie wydaje się drobna. Ale razem powodują stopniowe zbaczanie z kursu w projekcie.
Presja na zasoby to nie problem z kalendarzem
Ograniczenia dotyczące wewnętrznych zasobów w projekcie ERP często traktuje się jak problem organizacji kalendarza: kto może uczestniczyć w którym spotkaniu, kto ma wolne moce przerobowe w tym tygodniu, kto zdąży sprawdzić dokument do piątku. Ale to zbyt wąskie spojrzenie.
Presja na wewnętrzne zasoby wpływa na jakość projektu rozwiązania ERP. Wpływa na szybkość podejmowania decyzji. Decyduje o tym, czy organizacja będzie w stanie zakwestionować standardowe założenia, odpowiednio wcześnie zauważyć luki i sprawdzić system w rzeczywistych warunkach operacyjnych. Wpływa również na poziom zaufania do projektu. Gdy zespoły są przeciążone, przestają szczegółowo analizować rozwiązania i zaczynają liczyć na to, że projekt jakoś się utrzyma.
Dla sponsorów projektu powinien to być sygnał ostrzegawczy. Przeciążeni eksperci mogą sprawić, że dobrze zaplanowany projekt ERP zamieni się w powolny i wyczerpujący program, w którym decyzje są opóźnione, rośnie liczba poprawek, a gotowość użytkowników do korzystania z nowego systemu słabnie jeszcze przed go-live.
Problem nie polega na tym, że ludzie nie chcą się angażować. ERP wymaga od nich głębokiej znajomości biznesu i dojrzałych decyzji dokładnie w momencie, gdy kluczowe osoby są już obciążone codziennymi obowiązkami operacyjnymi.
Lepszy plan wdrożenia ERP zaczyna się od uczciwego uznania tego problemu na wczesnym etapie. Firma powinna wiedzieć, czyjego udziału potrzebuje, kiedy ten udział będzie konieczny, za jakie decyzje odpowiada dana osoba oraz w jaki sposób jej codzienne obowiązki zostaną zabezpieczone w okresie, gdy projekt będzie wymagał jej zaangażowania.
Bez takiej przejrzystości harmonogram wdrożenia może wyglądać na w pełni kontrolowany, podczas gdy największe ograniczenie znajduje się wewnątrz samej organizacji.
Zastępstwa w projekcie ERP ograniczają ryzyko opóźnień i błędnych decyzji
Zapewnienie zastępstw dla kluczowych osób zaangażowanych w projekt, czyli tzw. backfill, często traktowane jest jako koszt, który należy ograniczać. W praktyce jest to jeden z niewielu konkretnych mechanizmów, dzięki którym liderzy mogą ograniczać ryzyko opóźnień projektu ERP.
Projekt Dynamics 365 Finance & Supply Chain Management lub Business Central nie potrzebuje wyłącznie obecności przedstawicieli biznesu na spotkaniach, ale również właściwych osób dostępnych dokładnie w tych momentach, w których konieczna jest ich wiedza i ocena: podczas projektowania procesów, czyszczenia danych, planowania testów, testów akceptacyjnych użytkowników, planowania uruchomienia systemu oraz oceny jego gotowości do startu.
Bez odpowiedniego zastępstwa osoby te są zmuszone wybierać pomiędzy projektem a codzienną pracą. Najpierw cierpi na tym jakość projektu, a następnie jego harmonogram.
Backfill może przyjmować różne formy. Może oznaczać tymczasowe zastępstwo w bieżących operacjach, przekazanie mniej istotnych zadań innym osobom, dodatkowe wsparcie dla finansów lub operacji, wykorzystanie zewnętrznych zasobów wspierających zespół projektowy albo zapewnienie budżetu na czasowe zastępstwa w najbardziej wymagających fazach wdrożenia.
Nie chodzi o całkowite odsunięcie wewnętrznych ekspertów od bieżącej działalności firmy, ale o zapewnienie im wystarczającej ilości chronionego czasu, aby mogli podejmować dobre decyzje.
Słaby wkład wewnętrzny a ryzyko biznesowe
Kwestię zastępstw należy omówić jeszcze zanim projekt nabierze tempa, a nie dopiero wtedy, gdy zespół jest już przeciążony.
Rozsądny plan zasobów wewnętrznych powinien z wyprzedzeniem identyfikować okresy największego obciążenia. Zamknięcie miesiąca, audyty, sezonowość sprzedaży, inwentaryzacje, ważne zobowiązania wobec klientów czy nieobecności kluczowych liderów mają bezpośredni wpływ na dostępność zespołu projektowego ERP. Zignorowanie ich nie sprawia, że plan staje się bardziej efektywny, ale że jest mniej realistyczny.
Uzasadnienie biznesowe jest proste. Niewielka oszczędność na zastępstwach może później przełożyć się na znacznie większe koszty poprawek, opóźnień, dodatkowych zmian, przedłużonego wsparcia partnera oraz zakłóceń w działalności firmy. Może również osłabić adopcję systemu, ponieważ wyczerpani użytkownicy rzadko stają się jego pewnymi siebie ambasadorami.
Zamiast zastanawiać się, czy firmę stać na zapewnienie zastępstw, warto zadać sobie pytanie: „Które decyzje są zbyt ważne, aby pozostawić je osobom, które nie mają czasu, żeby dobrze je przemyśleć?”.
Co powinien zawierać wewnętrzny plan zasobów projektu ERP?
Wewnętrzny plan zasobów dla projektu ERP powinien pokazywać, kto odpowiada za każdą kluczową decyzję, ile czasu potrzebuje, kiedy ten czas będzie chroniony oraz kto przejmie jego bieżące obowiązki operacyjne. Jeszcze przed rozpoczęciem realizacji projektu powinien obejmować sponsorów, liderów obszarów, właścicieli procesów, właścicieli danych, testerów, super userów, osoby odpowiedzialne za szkolenia oraz zarządzanie zmianą.
Plan projektu bez takiego spojrzenia jest tylko połową planu.
Partner wdrożeniowy może doskonale znać Microsoft Dynamics 365, Business Central, integracje, migrację danych i konfigurację systemu. To jednak firma musi zdecydować, jak powinny wyglądać prawidłowo działające finanse, zakupy, gospodarka zapasami, produkcja, magazyn, raportowanie czy obsługa klienta. Do tego potrzebni są jasno wskazani właściciele.
Test zasobów PACE
Warto przeprowadzić ten test przed przejściem z fazy diagnostyki do projektowania rozwiązania, a następnie powtórzyć go przed budową rozwiązania, testami i go-live.
Jest to tzw. dyscyplina projektowa, a realistyczny model zasobów ERP powinien obejmować cztery poziomy.
Pierwszym jest sponsoring projektu. Sponsor musi mieć wystarczające uprawnienia, aby rozwiązywać konflikty pomiędzy działami, chronić projekt przed ciągłym spychaniem na dalszy plan oraz pilnować, aby uzasadnienie biznesowe pozostawało powiązane z rzeczywistymi rezultatami, takimi jak kontrola kosztów, dokładność zapasów, szybsze zamknięcie miesiąca, lepsza widoczność danych czy większa odporność operacyjna.
Drugim poziomem jest odpowiedzialność za poszczególne obszary projektu. Finanse, łańcuch dostaw, operacje, magazyn, produkcja, obsługa zamówień sprzedaży i raportowanie potrzebują jasno wyznaczonych liderów. Osoby te powinny rozumieć obecne problemy, przyszłe wymagania oraz kompromisy pomiędzy wykorzystaniem standardowego procesu, konfiguracją, integracją i tworzeniem rozwiązań niestandardowych.
Trzecim poziomem jest udział w realizacji projektu. Migracji danych, testów, szkoleń i zarządzania zmianą nie można zostawić na końcowe etapy. Właściciele danych potrzebują czasu na ich oczyszczenie i walidację. Testerzy potrzebują realistycznych scenariuszy. Super użytkownicy muszą zdobyć wystarczającą wiedzę, aby po go-live móc wspierać swoich współpracowników.
Czwartym poziomem jest odpowiedzialność za decyzje. Pomocna może być praktyczna matryca w stylu RACI. Kto rekomenduje rozwiązanie? Kto je zatwierdza? Kto waliduje? Z kim należy je skonsultować? Kogo wystarczy poinformować? Projekty ERP zwalniają, gdy odpowiedzi na te pytania są niejasne.
Dla liderów wartością takiego podejścia jest przede wszystkim większa kontrola. Jasny podział odpowiedzialności po stronie firmy przyspiesza podejmowanie decyzji, ogranicza liczbę poprawek, pozwala lepiej oceniać gotowość organizacji i daje komitetowi sterującemu bardziej rzeczywisty obraz ryzyka. Zmienia również sposób, w jaki zespół postrzega cały projekt. ERP przestaje być czymś, co jest „wdrażane im”, a zaczyna być traktowane jako decyzja dotycząca sposobu działania firmy, za którą sami odpowiadają.
Jak zarządzanie projektem chroni tempo, jakość i energię zespołu
Dobrze zaprojektowany model zarządzania projektem daje przeciążonym zespołom bezpieczny rytm pracy. Zapewnia widoczność decyzji, chroni czas ekspertów, pozwala wcześnie eskalować blokady i sprawdzać gotowość organizacji, zanim nadejdzie moment go-live. Bez takiego rytmu opóźnienia stają się normą, zmęczenie narasta, a projekt może stopniowo tracić kierunek, mimo że raporty statusowe nadal wyglądają na kontrolowane.
Najlepsze mechanizmy zarządzania projektem są proste. Ustal stały rytm spotkań komitetu sterującego. Prowadź aktualny rejestr decyzji. Śledź problemy wraz z właścicielem, terminem i wpływem na biznes. Oceniaj postęp testów według procesów, a nie tylko liczby wykonanych zadań. Sprawdzaj, czy eksperci rzeczywiście otrzymują czas, który został im obiecany. Eskaluj nierozstrzygnięte decyzje, zanim zaczną zagrażać harmonogramowi.
To ważne, ponieważ zmęczenie projektem ERP rzadko jest wynikiem jednego poważnego niepowodzenia. Narasta przez serię drobnych frustracji: warsztaty bez właściwych właścicieli procesów, ponowne otwieranie wcześniej podjętych decyzji, nierozwiązane błędy z testów, odkładanie problemów z danymi, zbyt późne szkolenia użytkowników czy zbyt optymistyczną ocenę gotowości do go-live.
Praktyczna ocena gotowości powinna odpowiadać na następujące pytania:
- Czy krytyczne procesy zostały przetestowane od początku do końca?
- Czy właściciele danych zatwierdzili zmigrowane dane?
- Czy super użytkownicy wiedzą, jak wspierać pozostałych pracowników?
- Czy otwarte problemy są priorytetyzowane według poziomu ryzyka biznesowego?
- Czy komitet sterujący rozumie, które elementy nadal nie są gotowe?
Te pytania nie tylko chronią harmonogram projektu, ale także zaufanie. Wdrożenie ERP jest wymagające, ponieważ dotyka finansów, operacji, łańcucha dostaw, zapasów, produkcji, raportowania i obsługi klientów. Liderzy powinni spodziewać się presji. Celem nie jest jej całkowite wyeliminowanie. Chodzi o to, aby presja nie zamieniła się w chaos.
Najczęściej zadawane pytania (FAQ)
Dlaczego projekty ERP kończą się niepowodzeniem?
Projekty ERP często kończą się niepowodzeniem, gdy słabe zaprojektowanie procesów, niewystarczające przygotowanie organizacji do zmiany, niejasny podział odpowiedzialności oraz zbyt małe zaangażowanie wewnętrznych zasobów zderzają się ze sztywnym harmonogramem wdrożenia.
Ile czasu po stronie firmy wymaga projekt ERP?
Osoby pełniące najbardziej wymagające role mogą potrzebować każdego tygodnia zagwarantowanego czasu na projekt, a ich zaangażowanie będzie jeszcze większe podczas projektowania procesów, walidacji danych, testów, szkoleń i przygotowań do go-live.
Czy zapewnienie zastępstw jest naprawdę konieczne?
Tak, jeśli od tych samych ekspertów oczekuje się jednocześnie prowadzenia bieżącej działalności i podejmowania kluczowych decyzji dotyczących ERP. Bez odpowiedniego zastępstwa zwykle cierpi zarówno jakość, jak i tempo projektu.
Kto powinien odpowiadać za decyzje dotyczące procesów ERP?
Gotowość to coś więcej niż prawidłowa konfiguracja systemu. Firma potrzebuje przetestowanych procesów, wiarygodnych danych, przeszkolonych użytkowników, jasno określonych ścieżek wsparcia, rozwiązanych problemów wysokiego ryzyka oraz liderów, którzy rozumieją kompromisy i kwestie pozostające nadal otwarte. Wartość ERP wynika ze spójnie działających operacji, jasno określonej odpowiedzialności i procesów, z których ludzie rzeczywiście mogą korzystać. System to umożliwia, nie zastąpi jednak zaangażowania organizacji.
Dla firm, które planują wdrożenie Microsoft ERP lub próbują ustabilizować projekt znajdujący się już w trudnej sytuacji, praktycznym kolejnym krokiem może być ocena gotowości zasobów albo przegląd zakresu projektu. Przeprowadzona odpowiednio wcześnie pozwala sprawdzić, czy zespół, model governance i plan realizacji są wystarczająco silne, aby utrzymać tempo, jakość i zaufanie do projektu, zanim presja zacznie rosnąć.
