Project Management

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.
 

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 jest 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
 

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 od pokonywani 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.
 

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 dostawce 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®)

 

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