Czy istnieją wdrożenia bez zagrożeń?

Odpowiadając na postawione powyżej pytanie można stwierdzić: nie, takich wdrożeń nie ma, nie mniej prawidłowo zarządzając przedsięwzięciem wdrożeniowym możemy eliminować przyczyny zagrożeń lub minimalizować skutki, tak aby uruchomiony system był zgodny z wymaganiami, a wdrożenie zakończyło się sukcesem, zgodnie z zaplanowanym zakresem, budżetem oraz harmonogramem prac i ze spełnieniem wszystkich wymagań i oczekiwań biznesowych.

Każda osoba, która ma za sobą choć jeden projekt wdrożenia zintegrowanego systemu wie, że aby osiągnąć ten cel należy najpierw przejść drogę pełną pułapek, które mogą skazać na porażkę nawet najlepiej zapowiadający się projekt – jeżeli nie zostaną w porę zidentyfikowane i nie zostaną podjęte właściwe działania korygujące czy zapobiegawcze..

Przewidywanie potencjalnych i przeciwdziałanie rzeczywistym zagrożeniom, właściwe zarządzanie ryzykiem projektu to trudna sztuka w zarządzaniu przedsięwzięciami, świadcząca o klasie kierownika projektu i dostępna osobom o dużej wiedzy i doświadczeniu praktycznym.

Rodzaje źródeł zagrożeń

Wdrożenie systemu ERP to przedsięwzięcie wspólne (klienta i firmy wdrożeniowej) i wymaga zaangażowania obu stron. Dlatego też, analizując przyczyny problemów, które występują we wdrożeniach ERP w Polsce, można zauważyć, że ich źródła występują i po stronie firmy wdrożeniowej, i po stronie przedsiębiorstwa, w którym system jest wdrażany.

Ze względu na rozległość zagadnienia zdecydowałem się podzielić temat na dwie części. W pierwszej części artykułu chciałbym zasygnalizować potencjalne źródła problemów, które są niezależne od fazy, w której znajduje się przedsięwzięcie wdrożeniowe.

Z opisanymi niżej potencjalnymi źródłami błędów warto zapoznać się jeszcze przed rozpoczęciem wdrożenia, ponieważ mogą one zagrażać powodzeniu projektu w czasie od jego przygotowania (zatem jeszcze przed początkiem właściwych prac wdrożeniowych), aż po uruchomienie systemu.

W drugiej części artykułu skoncentruję się na przedstawieniu potencjalnych źródeł problemów, związanych z niewłaściwą realizacją czynności w poszczególnych fazach wdrożenia.

Wdrożenie systemu ERP jest przedsięwzięciem biznesowym, jego celem jest osiągnięcie korzyści biznesowych. Oznacza to, że cele wdrożenia muszą być ściśle powiązane z celami strategicznymi firmy.

Jednocześnie, osoby zaangażowane w przygotowanie i realizację wdrożenia, powinny opierać się na wizji docelowego modelu funkcjonowania przedsiębiorstwa.

Wśród źródeł potencjalnych trudności można zatem wymienić:

  • brak strategii rozwoju firmy, która określając kierunki rozwoju, byłaby drogowskazem przy budowie rozwiązania informatycznego wspierającego funkcjonowanie firmy
  • próba rozwiązania poprzez projekt informatyczny podstawowych problemów biznesowych firmy, np. posiadania przestarzałego i niekonkurencyjnego produktu, który się nie sprzedaje
  • brak określenia przez decydentów celów biznesowych wdrożenia systemu, zarówno na poziomie całej firmy, jak i na poziomie poszczególnych procesów czy obszarów funkcjonalnych firmy
  • niemożność dojścia przez decydentów do wspólnej wizji przygotowywanego rozwiązania – różnice zdań pomiędzy osobami zaangażowanymi w wypracowanie rozwiązania
  • niechęć decydentów do wprowadzania zmian w przedsiębiorstwie, w jego procesach lub strukturze organizacyjnej, obawa przed zmianami
  • zbyt niski priorytet projektu – inne projekty rozwojowe toczące się w firmie lub standardowe zadania biznesowe pracowników mają pierwszeństwo, „odciągając” wymagane zasoby ludzkie i materialne.

Organizacja wewnętrzna zespołu projektowego

Warunkiem sprawnego postępu prac wdrożeniowych jest odpowiednia struktura organizacyjna projektu (członkowie Komitetu Sterującego, Kierownicy projektu, Zespoły Robocze) obejmująca osoby o odpowiednich kompetencjach i motywacji.

Potencjalne źródła niepowodzeń mogą być związane z następującymi problemami:

  • brak wystarczających kompetencji osób zaangażowanych we wdrożenie (wiedza merytoryczna, wiedza nt. procesów biznesowych firmy)
  • brak wystarczających uprawnień decyzyjnych
  • niepodejmowanie wymaganych decyzji na czas, obawa przed podjęciem jakiejkolwiek decyzji, obawa przed odpowiedzialnością związaną ze skutkami podjętej decyzji
  • brak wystarczającego czasu na udział w pracach projektowych, spowodowany obciążeniem innymi zadaniami związanymi ze stanowiskiem i rolą pełnioną w firmie
  • konfliktowość osób biorących udział w pracach wdrożeniowych, trudności w komunikacji z innymi
  • ogólna niechęć do samego projektu, okazywanie braku zainteresowania pracami, informowanie o braku swojego poparcia dla projektu, czasami wręcz sabotowanie prac
  • wykorzystanie projektu do celów „politycznych” w firmie, dla wygrywania własnych interesów czy też interesów swojego działu.

Brak kompetencji firmy wdrożeniowej

Można tu zasygnalizować m.in. następujące zagadnienia:

  • niewystarczające doświadczenie wdrożeniowe, zbyt mała liczba zrealizowanych wdrożeń,  zaangażowanie do wdrożenia konsultantów bez wymaganej wiedzy i doświadczeń praktycznych,
  • brak znajomości wdrażanego systemu informatycznego
  • brak wiedzy branżowej lub niechęć konsultantów do poznania specyfiki biznesu firmy Klienta, proponowanie wciąż tych samych rozwiązań (które mogą się sprawdzać np. w przedsiębiorstwach produkcyjnych, ale niekoniecznie muszą pasować do firm handlowych czy usługowych)
  • konfliktowość konsultantów biorących udział w pracach wdrożeniowych, trudności w komunikacji z innymi.

Niedopracowana metodyka wdrożeniowa

Wykorzystanie dopracowanej i sprawdzonej w wielu przedsięwzięciach metodyki wdrożeniowej jest niezbędnym warunkiem odpowiedniej organizacji prac  wdrożeniowych.

Wśród potencjalnych zagrożeń, związanych z brakiem metodyki bądź stosowaniem niewłaściwej metodyki wdrożenia, można wymienić:

  • brak prawidłowego, nadzoru nad definicją projektu – celami biznesowymi, zakresem, budżetem i harmonogramem prac (wartości planowane a rzeczywiste)
  • brak wystarczającego nadzoru nad postępem i zaawansowaniem poszczególnych prac wdrożeniowych (wartości planowane a rzeczywiste) brak wystarczających i jasnych procedur projektowych, m.in. określających:
    • dokumentowanie prac
    • komunikację i dystrybucję informacji
    • raportowanie statusu projektu
  • brak zaplanowania i realizacji działań związanych z analizą i przeciwdziałaniem zagrożeniom w projekcie (zarówno potencjalnym, jak rzeczywistym)
  • brak skutecznych procedur kontroli jakości produktów, prac, w tym sprawdzenia ich zgodności z przyjętą specyfikacją wymagań oraz akceptacji przez odbiorców
  • brak efektywnych narzędzi do prowadzenia projektu (np. harmonogramowanie dni konsultacji, rezerwacja i wykorzystanie dostępnych zasobów, publikacja i dostęp  do dokumentacji czy informacji o statusie prac, baza wykorzystywanych formularzy wzorcowych).

Niewystarczająca dostępność zasobów technicznych i organizacyjnych

Wdrożenie systemu ERP, jak każde przedsięwzięcie biznesowe i informatyczne, wymaga dostępności zasobów technicznych, organizacyjnych. Źródłem potencjalnych problemów mogą być:

  • niezapewnienie dostępu do systemu (system szkoleniowy, testowo-rozwojowy, produkcyjny), brak licencji na system, brak platformy sprzętowej, brak infrastruktury sieciowej (LAN,WAN)
  • niezapewnienie wystarczającej liczby i jakości sal szkoleniowych, sal do spotkań Zespołów Roboczych i konsultantów, niezbędnego wyposażenia w postaci komputerów PC z oprogramowaniem  biurowym, rzutników, drukarek, tablic, ekranów,  artykułów biurowych i eksploatacyjnych, itp.

Zagrożenia związane z fazą wdrożenia

Poniżej w syntetycznym ujęciu zostały przedstawione źródła zagrożeń, zgodnie z metodyką wdrożeniową rozwiązań SAP, stosowaną przez BCC (aktualnie All for One Poland) – zatem kolejne fazy wdrożenia to:

  • analiza przedwdrożeniowa
  • przygotowanie projektu
  • projektowanie koncepcyjne
  • przygotowanie prototypu systemu
  • przygotowanie systemu do pracy
  • start produkcyjny

Faza 0 – analiza przedwdrożeniowa

W ramach tej fazy definiuje się projekt wdrożeniowy (cele biznesowe, strategia, zakres, harmonogram, budżet, struktura organizacyjna) jako podstawę do opracowania ofert przez firmy wdrożeniowe, wyboru oferty i podpisania na jej podstawie umowy wdrożenia systemu SAP.

Źródła zagrożeń pojawiające się na tym początkowym etapie prac, zostały częściowo scharakteryzowane już powyżej. Są to przede wszystkim:

  • brak jednoznacznego określenia celów projektu (racjonalnych i możliwych do zmierzenia, po zakończeniu przedsięwzięcia)
  • narzucenie nierealistycznych założeń co do zakresu i/lub harmonogramu projektu (wdrożenie większej liczby zmian organizacyjnych, niż jest to możliwe do „wchłonięcia” przez firmę, w tym czasie),
  • wybór nieodpowiedniego partnera wspierającego wdrożenie, np. firmy nie posiadającej sprawdzonej metodyki wdrożeniowej, odpowiednio licznego zespołu doświadczonych konsultantów, znajomości specyfiki polskich przepisów, itp.

Faza I – przygotowanie projektu

W ramach tej fazy definicja projektu – wynikająca z oferty i umowy wdrożeniowej – zostaje doprecyzowana i opisana w postaci tzw. Karty projektu.

Zostają określone również szczegółowo zasady pracy w projekcie (regulamin pracy, regulamin szkoleń, dokumentowanie, raportowanie statusu, ewidencjonowanie i rozliczanie prac, korzystanie z zasobów itp.) i następuje rezerwacja zasobów.

Potencjalne źródła zagrożeń to:

  • niewyznaczenie składów osobowych zespołów wdrożeniowych w strukturze organizacyjnej projektu
  • nieoddelegowanie uczestników projektu do prac w wystarczającym stopniu (co wymaga odciążenia od innych zadań)
  • brak sformalizowanego opisu definicji projektu, dostępnego dla członków organizacji projektowej (w metodyce BCC jest to „Karta projektu”)
  • brak sformalizowanego opisu metodyki projektu,  procedur i uregulowań postępowania w projekcie (w metodyce BCC jest to „Regulamin projektu”)
  • brak decyzji o wyborze dostawcy platformy sprzętowej i zatwierdzenia specyfikacji technicznej systemu testowo-rozwojowego i produkcyjnego
  • brak zatwierdzenia w terminie przez Komitet Sterujący standardów projektowych („Karta projektu” i „Regulamin projektu”)

Faza II – projektowanie koncepcyjne

W tej fazie prowadzone są szkolenia pracowników z zakresu SAP oraz opracowywana jest koncepcja wdrożenia – dokument, opisujący jak w systemie SAP zostaną odzwierciedlone procesy biznesowe firmy.

Potencjalne źródła zagrożeń to:

  • brak udostępnienia systemu szkoleniowego, sal i innych zasobów na potrzeby szkoleń Zespołów Roboczych
  • brak zakupu w terminie licencji na system SAP (dla potrzeb instalacji systemu testowo-rozwojowego)
  • brak dostarczenia w terminie platformy sprzętowej dla systemu testowo-rozwojowego – brak udziału w szkoleniach i konsultacjach osób z Zespołów Roboczych, oddelegowanych do prac koncepcyjnych
  • brak w modułowych Zespołach Roboczych osób znających poszczególne obszary funkcjonalne firmy (przebieg procesów i funkcji, obieg dokumentacji i informacji, miejsca podejmowania decyzji w procesie)
  • brak podejmowania przez uprawnione osoby wymaganych decyzji, związanych ze zmianą przebiegu procesów i funkcji, strukturą organizacyjną firmy i zakresem obowiązków na stanowiskach
  • brak spotkań międzymodułowych, na których są wyjaśniane i rozwiązywane zagadnienia integracyjne, dotyczące przebiegu procesów w systemie
  • niewystarczające dokumentowanie propozycji koncepcyjnych systemu (w „Koncepcji wdrożenia” oraz dokumentacji rozszerzeń systemu)
  • brak umiejętności przekazania przez członków Zespołów Roboczych założeń oraz rozwiązań koncepcyjnych pozostałym pracownikom firmy
  • brak zapoznania się przez osoby decyzyjne z dokumentami koncepcyjnymi na potrzeby zatwierdzenia przyjętych rozwiązań
  • brak zgłoszenia uwag, zastrzeżeń lub propozycji zmian do rozwiązań koncepcyjnych przez osoby weryfikujące i akceptujące te rozwiązania
  • brak przyłożenia wystarczającej wagi do działań, związanych z analizą źródeł oraz metodami przeniesienia danych podstawowych
  • brak podjęcia w terminie przez Komitet Sterujący decyzji o zatwierdzeniu „Koncepcji wdrożenia”

Faza III – przygotowanie prototypu

W tej fazie, na podstawie zatwierdzonej koncepcji wdrożenia, przygotowywany jest prototyp systemu SAP – poprzez parametryzację ustawień systemu. Prototyp poddawany jest testom w ramach poszczególnych funkcjonalności oraz testom integracyjnym całego systemu, sprawdzającym jego prawidłowe funkcjonowanie.

Potencjalne źródła zagrożeń to:

  • brak udostępnienia w terminie wymaganej infrastruktury sieciowej, umożliwiającej członkom Zespołów Roboczych na dostęp do systemu
  • brak udziału w konsultacjach osób z Zespołów Roboczych, oddelegowanych do prac konfiguracyjnych i prac nad rozszerzeniami systemu
  • traktowanie prac konfiguracyjnych i programistycznych jako zadania tylko dla konsultantów z firmy wdrożeniowej (brak transferu wiedzy w tym zakresie do pracowników firmy)
  • brak zainteresowania ze strony kierownictwa firmy transferem wiedzy w zakresie konfiguracji systemu od konsultantów do pracowników firmy
  • uzupełnianie wymagań do procesów lub wręcz zmiana wymagań w trakcie konfiguracji systemu lub w trakcie wykonywania testów (pomimo wcześniejszego zatwierdzenia Koncepcji wdrożenia)
  • uzupełnianie specyfikacji wymagań rozszerzeń w trakcie pisania programów lub w trakcie wykonywania testów (pomimo zatwierdzenia dokumentacji rozszerzenia)
  • brak udziału w testach osób z Zespołów Roboczych, oddelegowanych do testowania systemu
  • zbyt mała ilość testów, zbyt wąski zakres testowanych przypadków, zbyt mało czasu poświęconego na dokładne testy
  • brak wprowadzenia na potrzeby testów wymaganego zakresu danych podstawowych, odzwierciedlających rzeczywisty zakres danych w działalności biznesowej firmy
  • brak dostarczenia w terminie platformy sprzętowej dla systemu produkcyjnego
  • niewyznaczenie pracowników, odpowiedzialnych za przygotowanie danych podstawowych do przeniesienia (w tym brak eksportu danych ze starych systemów informatycznych i ręczne uzupełnienie brakujących informacji)
  • lekceważenie problemu dużej czasochłonności, związanej z prawidłowym przygotowaniem danych podstawowych
  • brak zatwierdzenia w terminie przez Komitet Sterujący prototypu systemu

Faza IV – przygotowanie do pracy

W tej fazie szkoleni są użytkownicy końcowi z funkcji wykonywanych w systemie. Nowy system jest też napełniany rzeczywistymi danymi, przeniesionymi z obecnych systemów przedsiębiorstwa.

Potencjalne źródła zagrożeń to:

  • brak wymaganej infrastruktury sieciowej umożliwiającej użytkownikom końcowym dostęp do systemu SAP
  • brak opracowania instrukcji użytkowników końcowych w terminie (ze względu na obszerność i dużą pracochłonność wykonania tej dokumentacji)
  • brak określenia pełnej listy pracowników, którzy będą użytkownikami końcowymi systemu
  • brak zakupu wystarczającej ilości licencji i sprzętu PC dla użytkowników końcowych
  • niewystarczająca ilość i zakres szkoleń dla użytkowników końcowych
  • nieumiejętność przeprowadzenia przez Zespoły Robocze szkoleń dla użytkowników, brak umiejętności skutecznego przekazywania wiedzy
  • brak zainteresowania ze strony kierownictwa firmy transferem wiedzy w zakresie obsługi systemu od członków Zespołów Roboczych do pracowników firmy
  • brak sprawdzenia poprawności przeniesienia danych konfiguracyjnych i rozszerzeń z systemu testowo-rozwojowego do systemu produkcyjnego
  • braki lub nieprawidłowe wpisy w danych podstawowych wprowadzonych do systemu produkcyjnego
  • brak wprowadzenia wymaganych zmian organizacyjnych, będących konsekwencją przyjętych do wdrożenia procesów i funkcji
  • brak prawidłowego przygotowania procesu zbierania i wprowadzania do systemu danych bilansu otwarcia (dane transakcyjne aktualne na dzień startu systemu produktywnego)
  • lekceważenie pracochłonności i wagi procesu zbierania danych na potrzeby bilansu otwarcia
  • wprowadzenie do systemu produkcyjnego danych bilansu otwarcia niezgodnych ze stanem rzeczywistym
  • brak zatwierdzenia w terminie przez Komitet Sterujący systemu produkcyjnego

Faza V – start produkcyjny

W tej fazie (po starcie produkcyjnym systemu) wspierani są użytkownicy końcowi w trakcie pierwszych dni swojej pracy systemu, następuje też optymalizacja ustawień technicznych systemu.

Potencjalne źródła zagrożeń to:

  • błędy w obsłudze systemu, będące skutkiem braków w wyszkoleniu użytkowników infrastruktury sieciowej, umożliwiającej członkom Zespołów Roboczych na dostęp do systemu
  • brak udziału w konsultacjach osób z Zespołów Roboczych, oddelegowanych do prac konfiguracyjnych i prac nad rozszerzeniami systemu
  • traktowanie prac konfiguracyjnych i programistycznych jako zadania tylko dla konsultantów z firmy wdrożeniowej (brak transferu wiedzy w tym zakresie do pracowników firmy)
  • brak zainteresowania ze strony kierownictwa firmy transferem wiedzy w zakresie konfiguracji systemu od konsultantów do pracowników firmy
  • uzupełnianie wymagań do procesów lub wręcz zmiana wymagań w trakcie konfiguracji systemu lub w trakcie wykonywania testów (pomimo wcześniejszego zatwierdzenia Koncepcji wdrożenia)
  • uzupełnianie specyfikacji wymagań rozszerzeń w trakcie pisania programów lub w trakcie wykonywania testów (pomimo zatwierdzenia dokumentacji rozszerzenia)
  • brak udziału w testach osób z Zespołów Roboczych, oddelegowanych do testowania systemu
  • zbyt mała ilość testów, zbyt wąski zakres testowanych przypadków, zbyt mało czasu poświęconego na dokładne testy
  • brak wprowadzenia na potrzeby testów wymaganego zakresu danych podstawowych, odzwierciedlających rzeczywisty zakres danych w działalności biznesowej firmy
  • brak dostarczenia w terminie platformy sprzętowej dla systemu produkcyjnego
  • niewyznaczenie pracowników, odpowiedzialnych za przygotowanie danych podstawowych do przeniesienia (w tym brak eksportu danych ze starych systemów informatycznych i ręczne uzupełnienie brakujących informacji)
  • lekceważenie problemu dużej czasochłonności, związanej z prawidłowym przygotowaniem danych podstawowych
  • brak zatwierdzenia w terminie przez Komitet Sterujący prototypu systemu

Faza IV – przygotowanie do pracy

W tej fazie szkoleni są użytkownicy końcowi z funkcji wykonywanych w systemie. Nowy system jest też wystąpić, a posiadanie wiedzy o możliwych pułapkach i trudnościach znacznie zwiększa szanse uniknięcia tych problemów!

Konieczne jest jednak, aby zawsze właściwie podejść do zarządzania zagrożeniami w trakcie trwania projektu, przy czym odpowiedzialność za realizację zadań w tym zakresie ponoszą bezpośrednio Kierownicy Projektu (ze strony przedsiębiorstwa – klienta i ze strony firmy wdrożeniowej).

Niezbędne działania zarządzania zagrożeniami powinny obejmować:

  • systematycznie odbywające się spotkania wybranych osób zaangażowanych we wdrożenie, które w oparciu o posiadane doświadczenie, pracę grupową (np. „burze mózgów”), z uwzględnieniem bieżącej sytuacji w projekcie i przy pomocy takich list kontrolnych jak przedstawiona powyżej, dokonują analizy prawdopodobieństwa wystąpienia potencjalnych zagrożeń. Następnie dla zagrożeń prawdopodobnych, o istotnym wpływie na przebieg projektu, podejmują działania zapobiegawcze, eliminujące potencjalne przyczyny ich wystąpienia oraz minimalizujące potencjalne skutki ich oddziaływania
  • systematyczne spotkania wybranych osób zaangażowanych we wdrożenie, które (z wykorzystaniem podobnych metod jak poprzednio) dokonują identyfikacji rzeczywistych zagrożeń projektowych, które w nim występują i dla tych rzeczywistych zagrożeń podejmują działania korygujące, usuwające przyczyny ich zaistnienia oraz działania naprawcze dla usunięcia skutków, jakie przyniosły one dla projektu (włącznie z koniecznością realizacji części prac/produktów cząstkowych projektu powtórnie). W przypadku akceptacji skutków wystąpienia danego zagrożenia (otrzymanie produktu cząstkowego projektu niezgodnego z wymaganiami) należy określić, jak skutki te mogą wpłynąć nie tylko na bieżąco wykonywane w projekcie czynności, ale też jak wpłyną na czynności zaplanowane do wykonania w projekcie w kolejnych jego fazach (włącznie z wpływem na ostateczny produkt projektu w postaci systemu produkcyjnego SAP).
  • niechęć użytkowników do nowego systemu, wynikająca z przyzwyczajenia i rutyny pracy z poprzednim systemem
  • obawa użytkowników końcowych przed samodzielną obsługą nowego systemu
  • krytyka i negatywna ocena projektu i systemu przez kierownictwo firmy na podstawie pierwszych trudności w jego eksploatacji i obsłudze
  • błędy w danych podstawowych, będące przyczyną błędów w działaniu systemu
  • błędy w danych bilansu otwarcia, dane w systemie niezgodne z rzeczywistością, np. stany materiałów na magazynie
  • błędy w konfiguracji i rozszerzeniach systemu, będące skutkiem niewystarczających testów modułowych i integracyjnych
  • brak aktualizacji przez Zespoły Robocze „Koncepcji wdrożenia” i instrukcji użytkowników końcowych (w przypadku wprowadzania zmian do konfiguracji systemu po starcie produkcyjnym)
  • brak wewnętrznej organizacji pomocy użytkownikom końcowym (Help Desk), składającej się z członków Zespołów Roboczych, eskalacja wszystkich, nawet drobnych problemów bezpośrednio do zewnętrznych konsultantów.

Sztuka zarządzania projektem wdrożeniowym to w dużej mierze wiedza o źródłach potencjalnych zagrożeń oraz o sposobach ich minimalizacji i eliminowania. Posiadanie i wykorzystanie tej wiedzy znacząco wpływa na zwiększenie prawdopodobieństwa sukcesu wdrożenia.

Przedstawiona powyżej lista potencjalnie występujących w projekcie zagrożeń jest bardzo obszerna i może wręcz zniechęcać do wdrożenia systemu.

Czy skoro jest tyle trudności, to wdrożenie ma w ogóle szanse powodzenia? Tak, bowiem są to zagrożenia potencjalne, które nie muszą wcale wystąpić, a posiadanie wiedzy o możliwych pułapkach i trudnościach znacznie zwiększa szanse uniknięcia tych problemów!

Konieczne jest jednak, aby zawsze właściwie podejść do zarządzania zagrożeniami w trakcie trwania projektu, przy czym odpowiedzialność za realizację zadań w tym zakresie ponoszą bezpośrednio Kierownicy Projektu (ze strony przedsiębiorstwa – klienta i ze strony firmy wdrożeniowej).

Niezbędne działania zarządzania zagrożeniami powinny obejmować:

  • systematycznie odbywające się spotkania wybranych osób zaangażowanych we wdrożenie, które w oparciu o posiadane doświadczenie, pracę grupową (np. „burze mózgów”), z uwzględnieniem bieżącej sytuacji w projekcie i przy pomocy takich list kontrolnych jak przedstawiona powyżej, dokonują analizy prawdopodobieństwa wystąpienia potencjalnych zagrożeń. Następnie dla zagrożeń prawdopodobnych, o istotnym wpływie na przebieg projektu, podejmują działania zapobiegawcze, eliminujące potencjalne przyczyny ich wystąpienia oraz minimalizujące potencjalne skutki ich oddziaływania
  • systematyczne spotkania wybranych osób zaangażowanych we wdrożenie, które (z wykorzystaniem podobnych metod jak poprzednio) dokonują identyfikacji rzeczywistych zagrożeń projektowych, które w nim występują i dla tych rzeczywistych zagrożeń podejmują działania korygujące, usuwające przyczyny ich zaistnienia oraz działania naprawcze dla usunięcia skutków, jakie przyniosły one dla projektu (włącznie z koniecznością realizacji części prac/produktów cząstkowych projektu powtórnie). W przypadku akceptacji skutków wystąpienia danego zagrożenia (otrzymanie produktu cząstkowego projektu niezgodnego z wymaganiami) należy określić, jak skutki te mogą wpłynąć nie tylko na bieżąco wykonywane w projekcie czynności, ale też jak wpłyną na czynności zaplanowane do wykonania w projekcie w kolejnych jego fazach (włącznie z wpływem na ostateczny produkt projektu w postaci systemu produkcyjnego SAP).

Sztuka zarządzania projektem wdrożeniowym to w dużej mierze wiedza o źródłach potencjalnych zagrożeń oraz o sposobach ich minimalizacji i eliminowania. Posiadanie i wykorzystanie tej wiedzy znacząco wpływa na zwiększenie prawdopodobieństwa sukcesu wdrożenia.