Jak wdrożyć system ERP

 Wśród użytkowników systemów klasy ERP powszechny staje się pogląd, że zakup systemu generuje koszty a jego wdrożenie korzyści. Niestety przekonanie to jest udziałem tylko tych firm, które wdrożenie mają już za sobą. Potencjalni użytkownicy muszą się przygotować na czekające ich niespodzianki. Aby ich uniknąć, nie wystarczy znać własne wymagania funkcjonalne w stosunku do wdrażanego produktu i ogólne zasady zarządzania projektami. Dzisiaj taką wiedzę posiadają już prawie wszyscy, a mimo to aktualną pozostaje opinia, że 80 % wdrożeń kończy się mniejszym lub większym niepowodzeniem. Udane wdrożenia różnią się od nieudanych przede wszystkim umiejętnością przewidywania i unikania licznych pułapek.

 Oto kilka podstawowych rad, które w tym pomogą: 

  • Starannie wybierz firmę wdrożeniową
  • Zweryfikuj metodykę wdrożeniową
  • Zbuduj zespół wdrożeniowy
  • Przeanalizuj ryzyko na początku wdrożenia
  • Regularnie kontroluj ryzyko 

Zawartych niżej uwag nie należy traktować jako kompendium wiedzy o sposobach skutecznego wdrażania. Skupiają się one raczej na tych elementach, które pozwalają ograniczyć ryzyko porażki.

Starannie wybierz firmę wdrożeniową 

Najprostszym sposobem przeprowadzenia syntetycznej oceny kompetencji dostawcy usług wdrożeniowych jest sprawdzenie referencji. Najprostszym nie oznacza najlepszym. Na dynamicznym rynku pracy trudno jest zachować w pełnym składzie zespół, który kryje się za sukcesem odniesionym w poprzednich projektach. Tutaj z pomocą przychodzą odpowiednie klauzule umowy gwarantujące skład zespołu wdrożeniowego. W zapisach tych należy wskazać osobę kierownika projektu i ograniczyć swobodę jego zmiany. 

Kompetencje członków zespołu dobrze weryfikują posiadane przez nich dyplomy i certyfikaty. Certyfikaty produktowe są na tyle powszechne, że ich brak rodzi wątpliwości co do kwalifikacji oferenta usług. Ważniejszym od indywidualnych certyfikatów świadectwem kompetencji są certyfikaty przyznawane nie osobom lecz firmom. Producent systemu poprzez przyznanie statusu oficjalnego partnera oraz specjalistycznego certyfikatu całej organizacji potwierdza trwałość uzyskanych przez nią umiejętności. 

Oprócz powszechnie znanych certyfikatów produktowych równie ważne, o ile nie ważniejsze jest posiadanie merytorycznych kompetencji we wdrażanym obszarze i doświadczenia w zarządzaniu projektami. W Polsce najbardziej uznawanymi świadectwami kwalifikacji kadry zarządzającej projektami są certyfikaty PMP, PRINCE2® oraz IPMA. Uzyskanie niektórych z nich wymaga nie tylko zdania trudnych egzaminów, ale również udokumentowania wieloletniego doświadczenia w dziedzinie zarządzania projektami. Proces certyfikacji IPMA wymaga od kandydatów nie tylko rozwiązania testów, ale sprawdza również ich predyspozycje psychologiczne. Certyfikat PMP jest nadawany przez Project Management Institute tylko na okres trzech lat, a jego odnowienie wymaga aktywnego stosowania ustalonego standardu w praktyce oraz stałego poszerzania wiedzy.

Ostateczną weryfikacją wdrażanego rozwiązania są wizyty referencyjne u dotychczasowych klientów. Organizuje się je w ostatnim etapie selekcji, po zawężeniu grona potencjalnych dostawców do „shortlisty”. Są doskonałą okazją do jednoczesnego sprawdzenia zarówno oferowanego produktu jak i zdolności usługodawcy do skutecznego wdrożenia. Jeśli nie są nadmiernie aranżowane pozwalają również na ujawnienie i uniknięcie popełnionych wcześniej błędów . Nauka na cudzych błędach jest najmniej kosztowna. 

Przed wyborem firmy wdrażającej należy sprawdzić:

  • referencje
  • udokumentowane certyfikatami kompetencje produktowe
  • udokumentowane certyfikatami kompetencje w zarządzaniu projektami
  • udokumentowane kwalifikacje we wdrażanej dziedzinie biznesu
  • po zawężeniu grona oferentów do shortlisty zażądać wizyty referencyjnej 

Powyższe informacje dostarczane są przez oferenta w formie listów referencyjnych oraz skróconych życiorysów zawodowych kluczowych członków zespołu wdrożeniowego.

W umowie wdrożeniowej należy odwołać się do deklarowanych przez usługodawcę kwalifikacji i ograniczyć swobodę zmiany składu zespołu wdrożeniowego. 

 

Zweryfikuj metodykę wdrożeniową 

Przy wyborze systemu ERP skupiamy się na produkcie i dostawcy usług zapominając o samym procesie wdrożenia. Z uwagi na popularność systemów zarządzania, wiedza na ich temat staje się dość powszechna wśród menadżerów. Unikalna natomiast pozostaje umiejętność ich wdrażania. Wydaje się, że to właśnie dojrzałość organizacyjna i konsekwencja w stosowaniu metodyki odróżnia dobre od złych zespołów projektowych. Paradoksalnie, przestrzeganie standardów zarządzania projektami jest często ważniejsze podczas realizacji małych niż dużych wdrożeń. Nie należy się spodziewać, że skomplikowany z natury system informatyczny uda nam się wdrożyć przy niewielkim budżecie bez stosowania pewnego rodzaju szablonów.Zespoły zaangażowane w duże projekty mają czas na implementację uniwersalnych standardów, wypracowanie indywidualnej metodyki i naukę na własnych błędach na koszt klienta. Przy realizacji projektów niskobudżetowych kluczową rolę odgrywają gotowe schematy postępowania i oparta na szablonach metodyka.

Metodyki zarządzania dużym projektami informatycznymi oparte są na zaadaptowanych standardach PMBOK®, IPMA, PRINCE2®i CMMISM. Tymczasem w polskich realiach przy niskobudżetowych wdrożeniach najpowszechniej stosowana jest metodyka „szarży ułańskiej”. Łatwo ją rozpoznać po następujących cechach: 

  • brak dokumentu planu projektu
  • brak specyfikacji wymagań lub studium wykonalności
  • brak dokumentu analizy wdrożeniowej lub stosowanie niezmodyfikowanego „gotowca”
  • brak kamieni milowych weryfikujących postęp wdrożenia
  • brak ustalonych sposobów monitorowania wdrożenia
  • brak zasad dokonywania zmian w projekcie
  • brak etapu testów przed uruchomieniem
  • brak analizy ryzyka
  • bliżej nie określony zespół wybitnie uzdolnionych konsultantów i programistów 

Powszechnym zaniedbaniem jest pomijanie jednego z dokumentów analizy wdrożeniowej lub planu projektu. Analiza wdrożeniowa zawiera specyfikację potrzeb klienta oraz opisuje sposób ich realizacji w ramach wdrażanego systemu. Plan projektu powinien opisywać sposób w jaki wdrożenie będzie realizowane. Niektóre firmy wdrożeniowe kopiują szablon dokumentu, edytują w nim nazwę i dane adresowe klienta lekceważąc specyfikę wspieranych przez system procesów. 

Najważniejszymi elementami planu projektu z punktu widzenia skuteczności wdrożenia są: 

  • Zakres projektu
  • Harmonogram uwzględniający testy
  • Plan zarządzania ryzykiem 

Brak jasno sprecyzowanego zakresu projektu prawie zawsze skutkuje mniejszym lub większym konfliktem, przekroczeniem kosztów, terminów lub brakami funkcjonalnymi. Jeśli wymagania funkcjonalne nie są precyzyjnie opisane, wykonawca może perfekcyjnie wywiązać się ze swoich formalnych zobowiązań, a mimo to system nie spełni oczekiwań klienta. 

W praktyce testy są często pomijane lub traktowane jako uciążliwy formalizm. W takiej sytuacji rzeczywiste testowanie ma miejsce po operacyjnym uruchomieniu systemu. Skutkiem jest bardzo bolesne wprowadzanie poprawek w trakcie pracy systemu, rezygnacja z części funkcjonalności, a w skrajnym przypadku ponowne uruchomienie. Modyfikacje wprowadzane na tak zaawansowanym etapie zazwyczaj są o wiele bardziej kosztowne niż rzetelne planowanie i testowanie rozwiązania.Testy należy zaplanować z wyprzedzeniem wystarczającym na wprowadzeniem poprawek. 

Karygodnym, choć zrozumiałym z marketingowego punktu widzenia błędem jest pomijanie analizy ryzyka. Ten element chyba najlepiej odróżnia amatorów od profesjonalistów. Dostawca usług albo nie rozumie potrzeby przeprowadzenia takiej analizy albo uznaje za „niepolityczne” informuje klienta o zagrożeniach. Mała skala niektórych projektów ERP nie jest żadnym usprawiedliwieniem. Realizując krótkie i powielarne projekty łatwiej jest skatalogować typowe zagrożenia i ocenić w jakim stopniu dotyczą każdego z kolejnych wdrożeń. 

Przygotowując agendę prezentacji należy zadbać o :

  • Prezentację metodyki
  • Przykładowy plan projektu lub harmonogram
  • Przykładową analizę wdrożeniową 

W trakcie realizacji wdrożenia połóż duży nacisk na:

  • Zgodność zakresu projektu z potrzebami użytkowników
  • Etap testów
  • Regularne monitorowanie ryzyka

 

Zbuduj zespół wdrożeniowy 

Po podjęciu strategicznych decyzji dotyczących wdrożenia przez sponsora projektu, najważniejszą postacią w zespole wdrożeniowym staje się jego kierownik. Wymaganiem krytycznym w stosunku do osoby pełniącej tą funkcję jest zdolność motywowania członków zespołu i przyszłych użytkowników wdrażanego systemu – bezpośrednio lub przez wsparcie sponsora. Wdrożenie ERP jest małym wstrząsem dla całej firmy - ingeruje we wszystkie sfery działalności, często narusza przyzwyczajenia i zastane interesy poszczególnych grup. Dlatego prawie w każdym przypadku wymaga pokonania mniejszego lub większego oporu pracowników. Należy zadbać o to, by osoby koordynujące prace wdrożeniowe miały narzędzia do pokonywania tego oporu – najlepiej w postaci systemu motywacyjnego.

We wdrożeniach ERP obowiązuje zasada znana z innych projektów: im później wprowadzamy zmiany, tym są one bardziej kosztowne. Warto mieć to na uwadze planując zaangażowanie zespołu w poszczególnych etapach. Dobrą praktyką jest zaangażowanie osób kluczowych w proces wyboru systemu i etap planowania wdrożenia. Złą, ale powszechną praktyką jest uaktywnienie kierowników działów funkcjonalnych dopiero na etapie szkoleń lub testowania. W takich przypadkach wdrożenie zamiast się kończyć rozpoczyna się od początku. Ponieważ większość planowanych kosztów została już poniesiona budżet projektu jest przekraczany w sposób radykalny. Jeśli budżet projektu na to pozwala, dobrym rozwiązaniem jest przeprowadzenie wstępnych szkoleń dla użytkowników kluczowych już na etapie planowania. Dzięki temu członkowie zespołu klienta stają się pełnoprawnymi partnerami dla firmy wdrażającej. Pozwala to na precyzyjne sformułowanie wymagań i zweryfikowanie zgodności zakresu projektu z oczekiwaniami. 

Tworząc zespół wdrożeniowy należy pamiętać o:

  • Wyznaczeniu lidera mającego duży autorytet techniczny i organizacyjny
  • Zaangażowanie kierowników działów w etap wyboru i planowania systemu
  • Aktywizację osób kluczowych już w pierwszej fazie wdrożenia

Najczęstsze problemy związane z „czynnikiem ludzkim” i zaangażowaniem pracowników w proces wdrożenia opisano w części dotyczącej analizy ryzyka.

 

Przeanalizuj ryzyko przed rozpoczęciem wdrożenia 

Firmy wdrażające systemy ERP unikają jawnej analizy ryzyka z dwóch powodów: braku wiedzy dotyczącej ryzyka oraz z przyczyn marketingowych. Wśród optymistycznie nastawionych managerów ryzyko jest „passe”, budzi panikę wśród oferujących system handlowców, a kierownicy projektów nie chcą być posłańcami złych wieści. Obowiązuje ogólna reguła, że ryzyko w pierwszych etapach projektu jest słowem zakazanym. W kolejnych etapach staje się słowem niepotrzebnym – na jego analizę jest już za późno. Pozostaje tylko łagodzenie skutków i ponoszenie rosnących kosztów. 

Plan zarządzania ryzykiem to specyfikacja wszystkich pułapek jakie mogą zepsuć wdrożenie wraz ze sposobami ich unikania i reagowania na trudne sytuacje. Systematyczna ocena i kontrola ryzyka to wyższa szkoła jazdy i wielu firmom brakuje w tej dziedzinie dobrych praktyk. Jest mało prawdopodobne, że dostawca usług wdrożeniowych aktywnie poinformuje klienta o zagrożeniach na etapie przedsprzedażnym. Wiele umów wdrożeniowych dopuszcza rezygnację z wdrożenia i zakupu systemu po etapie analizy. W tym przypadku ujawnianie zagrożeń przez dostawcę może być obarczone konfliktem interesów. Na otwartość mogą sobie pozwolić tylko firmy przestrzegające wysokich standardów zarządzania projektami.

Dopóki takie podejście nie jest powszechne, klienci zdani są na własną analizę ryzyka. Tutaj po raz kolejny możemy się odwołać do schematów. Przedstawione niżej zestawienie zawiera listę rodzajów ryzyka typową dla wdrożeń systemów ERP w małych i średnich firmach. Ogólny poziom ryzyka zależy od dwóch czynników: prawdopodobieństwa wystąpienia zdarzenia oraz jego skutków. Podane w zestawieniu wartości mają charakter orientacyjny – w rzeczywistości zawsze zależą od rodzaju projektu i środowiska, w którym jest realizowany. Poziom ryzyka oceniono wg skali 1-18. Założono większy wpływ skutków niż prawdopodobieństwa na poziom ryzyka, co zostało odzwierciedlone w progresywnej skali dla skutków. Poziom 1 oznacza ryzyko o łagodnych skutkach i niskim prawdopodobieństwie. Poziom 18 to ryzyko o dotkliwych skutkach i wysokim prawdopodobieństwie. Kierownik i sponsor projektu powinni szczególnie skoncentrować się na ryzykach o poziomie powyżej 6 - zaznaczonych na czerwono w tabeli.

W tabeli określono obszary dotknięte skutkami ryzyka. Pominięto powiązanie rodzajów ryzyka z etapami i zakresem wdrożenia. W zestawieniu zaproponowano również przykładowe sposoby reagowania na ryzyko.

 Skala poziomów ryzyka 

     

PRAWDOPODOBIEŃSTWO

 

POZIOM RYZYKA

Niskie

Umiarkowane

Wysokie

     

1

2

3

SKUTKI

Łagodne

1

1

2

3

Umiarkowane

3

3

6

9

Dotkliwe

6

6

12

18

(opracowano zgodnie z zaleceniami PMBOK®)

 

Tabela ryzyka 

RYZYKO

OPIS SKUTKÓW

OBSZARY

POZIOM

ŚRODKI ZARADCZE I METODY REAGOWANIA

Zakres

Harmonogram

Koszt

Prawdopodobieństwo

Skutki

Poziom

                 

ORGANIZACYJNE

               

Struktura organizacyjna klienta niedostosowana do realizacji projektu

konflikty kompetencyjne wynikające z koordynowania prac wielu działów przez kierownika wdrożenia nie posiadającego wystarczających umocowań

X

X

 

2

6

12

Klarowny przydział uprawnień i odpowiedzialności przez sponsora projektu

Zmiana Kierownika Projektu (po stronie Wykonawcy)

Czasowe obniżenie poziomu kwalifikacji projektowych

 

X

 

2

3

6

Zapewnienie zastępstwa;
Stałe zaangażowanie innych członków zespołu projektowego w zagadnienia organizacyjne; dokładna dokumentacja wdrożenia

Zmiana Kierownika Wdrożenia (po stronie Klienta)

zmiana wymagań w stos. do systemu;
zmiana wymagań w stosunku do planu wdrożenia

X

X

X

2

6

12

Zapewnienie zastępstwa;
Zaangażowanie innych osób kluczowych

Zmiana użytkownika kluczowego

zmiana wymagań w stos. do systemu

X

X

X

2

6

12

Zapewnienie zastępstwa;
Zaangażowanie innych osób kluczowych;
Dodatkowe szkolenia

Zmiana członka zespołu projektowego

Czasowe obniżenie poziomu kwalifikacji projektowych

 

X

 

2

3

6

Zapewnienie zastępstwa;
Wymiana informacji w obrębie zespołu;
Dodatkowe szkolenia

Zmiana administratora infrastruktury informatycznej

utrata dostępu do danych i kopii bezpieczeństwa

 

X

X

1

3

3

dostęp do systemu dla zarządu;
przekazanie uprawnień na czas nieobecności
odzyskanie z kopii

Niedostateczne umocowanie i autorytet kierownika wdrożenia po zmianie

brak zdolności motywowania członków zespołu wdrożeniowego

X

X

 

1

6

6

Wsparcie sponsora projektu

Niedostępność użytkowników kluczowych na etapie planowania

system skonfigurowany niezgodnie z wymaganiami osób odpowiedzialnych za realizację wybranych procesów

X

X

X

2

3

6

Zmiana harmonogramu wdrożenia; wyznaczenie zastępstwa

Słaba koordynacja zasobów ludzkich

niespójne lub sprzeczne wymagania użytkowników

X

X

X

1

3

3

Jasne zdefiniowanie ról i zasad komunikacji w projekcie

Rozproszona lokalizacja zespołu wdrożeniowego Klienta

trudności w komunikacji

 

X

 

1

3

3

Elektroniczne formy komunikacjia, telekonferencje

                 

Personalne

               

Opór przed zmianami

brak zaangażowania i świadome działania na szkodę wdrożenia

X

X

X

3

3

9

Nadzór sponsora projektu; działania dyscyplinarne; system motywacyjny;

Brak motywacji

niepełne i nieprecyzyjne określenie wymagań i zakresu projektu

X

   

1

6

6

System motywacyjny; jasne wyznaczenie celów i odpowiedzialności;

Brak zaangażowania użytkowników na etapie planowania i szkoleń

późne zaangażowanie użytkowników w proces wdrożenia drastycznie zwiększa koszty termin i zgodność systemu z oczekiwaniami

X

X

X

2

6

12

Nadzór sponsora nad początkowymi etapami wdrożenia;
System motywacyjny

Konflikty personalne

Obniżona jakość pracy zespołowej

X

X

 

2

3

6

Nadzór sponsora projektu i kierowników projektu;

Niedostateczne kwalifikacje zespołu wdrożeniowego (po stronie Klienta)

błędne określenia wymagań;
nieefektywne wykorzystanie systemu;

X

   

2

3

6

Szkolenia; właściwy dobór członków zespołu wdrożeniowego

Nieznajomość technologii informatycznej
- ogólna obsługa komputera

wydłużenie etapu szkoleń;
nieefektywne wykorzystanie systemu;
duża liczba błędów obsługowych

 

X

X

1

3

3

szkolenia podstawowe z obsługi komputera

Niedostateczne kwalifikacje zespołu projektowego (po stronie Wykonawcy)

błędne rozpoznanie wymagań klienta;
błędy na etapie realizacji;
niezgodność systemu z wymaganiami

X

X

 

1

6

6

Szkolenia;
Zmiana składu zespołu projektowego;
Aktywny udział użytkowników kluczowych w akceptacji Analizy Wdrożeniowej

                 

TECHNICZNIE

               

Braki funkcjonalne standardu systemu

niski poziom satysfakcji użytkowników mimo zgodności systemu z deklarowaną funkcjonalnością

X

   

2

3

6

Precyzyjne sformułowanie wymagań w trakcie Analizy Wdrożeniowej;
Zapoznanie się ze specyfikacja funkcjonalną systemu na etapie Analizy;

Niezgodność standardu systemu z deklarowaną specyfikacją funkcjonalną, błędy systemowe

utrudniona, nieergonomiczna obsługa systemu;
błędy danych

X

X

 

1

6

6

Rzetelne testy systemu przed uruchomieniem; Wykupienie gwarancji producenta oprogramowania;
Naprawy błędów w trybie serwisowym;

Duży udział modyfikacji funkcjonalnych w stosunku do standardu systemu (niestandardowe raporty, aplikacje, interfejsy),

wymienione w zestawieniu modyfikacji.

duże prawdopodobieństwo błędów w początkowej fazie eksploatacji sytemu;
podwyższone koszty supportowania i upgrade'ów;
Zwiększony koszt wdrożenia

X

X

X

3

3

9

Dokładne przetestowanie rozszerzeń funkcjonalnych przez uruchomieniem operacyjnym;
Utworzenie rezerw zasobów na etapie Asysty;
Rozważenie rozwiązań alternatywnych, opartych na standardzie systemu

Zmiana wersji oprogramowania w trakcie wdrożenia

rozbieżność między dokumentem Analizy a funkcjonalnością systemu;
niedostosowanie infrastruktury sprzętowej do wersji oprogramowania

X

X

X

2

3

6

Upgrade

Niedostosowanie infrastruktury sprzętowej do wymagań systemu

obniżenie wydajności systemu

X

   

3

3

9

Rozbudowa sprzętu

Zmiana wymagań użytkowników

- wymuszona zmianami procesów biznesowych i zmianami organizacyjnymi (połączenie spółek i zmiana osobowości prawej)

-wymuszona rosnącą świadomością potrzeb;

-wynikająca z niezrozumienia przez użytkowników znaczenia etapu planowania

wzrost kosztów - tym wyższy im później w okresie realizacji projektu postulowane są zmiany;
niski poziom satysfakcji użytkowników mimo zgodności systemu z deklarowaną funkcjonalnością

X

X

X

3

3

9

Koncentracja wysiłków na etapie Analizy Wdrożeniowej;
Przeplanowanie projektu począwszy od Analizy Wdrożeniowej;
Realizacja zmian w systemie;

             

0

 

ZEWNĘTRZNE

               

Prawne - zmiany prawa handlowego podatkowego i finansowego

niedostosowanie funkcjonalności systemu do wymagań ustawowych

X

X

X

2

3

6

Wykupienie gwarancji producenta oprogramowania;
Rezerwa budżetowa na upgrade;
Wykonanie upgrade'u;

Techniczne - niespełniające wymagań łącza internetowe

utrudnienie prac zdalnych;
problemy eksploatacyjne w trybie pracy on-line

 

X

X

1

3

3

Dublowanie łączy

Zmiany otoczenia rynkowego Klienta w trakcie wdrożenia

obniżone zdolności finansowania projektu

X

X

 

2

3

6

Ograniczenie zakresu wdrożenia

Zmiany otoczenia rynkowego Wykonawcy

obniżone możliwości zapewnienia wykwalifikowanych konsultantów

X

X

 

1

3

3

Przeplanowanie harmonogramu;
Zaangażowanie podwykonawcy

Opóźnienia realizacji prac przez dostawców zewnętrznych
- np. dostawca sprzętu, łącza internetowego, systemu EDI

opóźnienie realizacji wdrożenia

 

X

 

3

3

9

Wybór dostawców alternatywnych; Przeplanowanie harmonogramu;

                 

 

 Podobne zestawienie można opracować dla struktury podziału pracy, oceniając ryzyko dla każdego elementu wdrożenia. Szczególną uwagę należy poświęcić wszystkim niestandardowym rozwiązaniom: dodatkowym modułom, aplikacjom i interfejsom. Jeśli plan wdrożenia dopuszcza wariantowość rozwiązań, ocena ryzyka pomoże dokonać wyboru jednego z wariantów. 

Nieodłącznym elementem analizy ryzyka są rezerwy budżetowe przypisane do całego projektu lub poszczególnych jego etapów. Ponieważ budżet tworzony jest na etapie negocjacji handlowych często w oparciu o wycenę typu „fixed price”, dostawca usług umieszcza w nim rezerwy w sposób niejawny. Rezerwy uwzględniane są w stawce za roboczodzień lub cenie poszczególnych etapów projektu. Takie podejście zazwyczaj jest wymuszone na firmach wdrożeniowych przez klienta. Tymczasem z natury projektów wynika, że rzeczywisty zakres prac i związany z nim budżet zawsze wykazują odchylenia od wartości planowanych. Projekty bez odchyleń po prostu nie istnieją. Jawność rezerw chroni inwestora przed niebezpieczeństwem przekroczenia budżetu i zwiększa szansę osiągnięcia celów związanych z zakresem funkcjonalnym i jakością wdrażanego systemu. Jest ona w interesie klienta chociażby dlatego, że pozwala mu kontrolować koszty przez ustalenie zasad wykorzystywania środków rezerwowych.

Z drugiej strony, jeśli w trakcie negocjacji cenowych wykonawca zostanie przyparty do muru i obetnie swoje niejawne rezerwy, z całą pewnością odbije się to negatywnie na zakresie lub jakości wykonywanych prac. Bez względu na zapisy umowy, strona ponosząca straty nie będzie realizowała projektu w sposób satysfakcjonujący kontrahenta. Istnieje wiele metod szacowania rezerw czasowych i finansowych. Jedną z nich jest analiza PERT, która w sposób łatwy i stosunkowo wierny pozwala przewidzieć realny czas oraz rzeczywisty koszt na poziomie całego projektu. 

Rozpoczynając wdrożenie pamiętaj o następujących zasadach: 

  • zadbaj o jawność oceny ryzyka i ustal rezerwy
  • analizę ryzyka umieść planie wdrożenia
  • oszacuj poziomy ryzyka na podstawie prawdopodobieństwa i skutków
  • ustal sposoby reagowania na ryzyko i zasady wykorzystania rezerw
  • skoncentruj się na niestandardowych rozwiązaniach 

Zadaniem odbiorcy usług wdrożeniowych jest nakłonienie dostawcy do przestrzegania powyższych reguł. 

 

Regularnie kontroluj ryzyko 

Uczulenie zespołu wdrożeniowego na ryzyko na początku projektu nie wystarczy aby uchronić się przed nieoczekiwanymi wydarzeniami. Idealnym rozwiązaniem jest uwzględnienie w harmonogramie projektu spotkań oceniających stan wdrożenia, na których jednym z poruszanych zagadnień będzie ocena ryzyka. Kierownicy po obu stronach wdrożenia mogą wspólnie przejrzeć przygotowaną na etapie planowania zestawienie ryzyka i zweryfikować aktualny poziom zagrożenia. Jeśli lista zostanie uporządkowana wg malejącego poziomu ryzyka staje się gotowym narzędziem do śledzenia zagrożeń o najwyższym priorytecie. Oczywiście w miarę postępu wdrożenia wiedza o ryzyku rośnie i lista może być uzupełniana, jednak w trwających kilkanaście tygodni projektach rzadko jest to praktykowane. 

Obowiązującą zasadą jest wzajemne informowanie się stron o zdarzeniach, które są związane z ryzykiem. Kierownik wdrożenia ze strony klienta powinien np. poinformować kierownika projektu o zmianie na stanowisku głównej księgowej, a kierownik projektu zrewanżować mu się informacją o zmianie konsultanta wdrożeniowego. Dzięki temu będzie można z wyprzedzeniem uruchomić działania zaradcze zmieniając harmonogram prac lub planując dodatkowe szkolenia.

Monitorowanie ryzyka na podstawie hierarchicznej listy jest doskonałym narzędziem dla organizacji, które zaadaptowały metodę zarządzanie przez wyjątki. Ustalone w liście priorytety pozwalają unikać mikrozarządzania i koncentrować się na kluczowych czynnikach sukcesu. 

Aby kontrolować ryzyko przez cały cykl życia projektu: 

  • ustal zasady komunikacji i reguły bieżącego informowania o zagrożeniach
  • zaplanuj regularne spotkania organizacyjne uwzględniające ocenę ryzyka
  • koncentruj się na priorytetach wskazanych na liście ryzyka 

 

Podsumowanie 

Wiedza techniczna jest niezbędna ale niewystarczająca do skutecznego wdrożenia systemu informatycznego. Statystyki wskazują, że wdrożenia systemów zarządzania przedsiębiorstwem są obarczone wysokim ryzykiem. O powodzeniu decydują kwalifikacje zespołu oraz metodyka zarządzania projektem wdrożeniowym. W przypadku systemów ERP obejmujących swoją funkcjonalnością wszystkie sfery działalności przedsiębiorstwa, ilość kontrolowanych podczas wdrożenia zagadnień oraz liczba źródeł ryzyka jest bardzo duża. Zarządzający projektami chcąc uniknąć mikrozarządzania muszą skoncentrować się na problemach kluczowych dla powodzenia wdrożenia. Identyfikację zagrożeń ułatwia lista typowych źródeł ryzyka, która na etapie planowania musi być zweryfikowana pod względem prawdopodobieństwa i potencjalnych skutków. Działania zabezpieczające przed skutkami zagrożeń powinny rozpocząć się na etapie wyboru partnera wdrożeniowego, znaleźć odzwierciedlenie w umowie wdrożeniowej i być kontynuowane w trybie stałego monitoringu podczas realizacji projektu.

  

© Wojciech Szyprowski, PMP