Analiza ryzyka dla opornych cz. 1.

29 sierpień 2015 Written by 
Published in Artykuły

Analiza ryzyka dla opornych

W artykule o bezpiecznym wdrożeniu systemu ERP odniosłem się do ryzyka projektu, obiecując opublikowania schematu analizy ryzyka.  Pomijanie tego zagadnienia ułatwia rozpoczęcie projektu, ale bardzo utrudnia jego zakończenie.

W relacjach dostawcy z klientem „ryzyko” jest często słowem zakazanym. We wczesnych etapach projektu usługodawca boi się informować klienta o potencjalnych zagrożeniach, a klient obawia się, że używając zakazanego słowa obudzi kolejnego upiora o brzydkiej nazwie „rezerwa budżetowa”.  Nic więc dziwnego, że w projektach realizowanych z udziałem zewnętrznych wykonawców ryzyko jest tematem tabu.

Bez względu na to, czy jesteś dostawcą, czy odbiorcą usług wdrożeniowych,  domyślam się, że raczej nie zaproponujesz drugiej stronie wspólnej zabawy w analizę zagrożeń. Jeśli  nie jeszcze własnych doświadczeń w zarządzaniu ryzykiem proponuję, byś udał się sam w jakieś  dyskretne miejsce, zamknął na klucz i przeczytał ten artykuł.

Przedstawione niżej zestawienie zawiera listę rodzajów ryzyka typową dla wdrożeń systemów ERP w małych i średnich firmach. Liczby opisujące ryzyko w analizie jakościowej mają charakter szacunkowy. W przeciwieństwie do analizy ilościowej, którą zajmiemy się oddzielnie, analiza jakościowa jest łatwa do przeprowadzenia.

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.

 Mapa temperatury ryzyka

POZIOM RYZYKA

PRAWDOPODOBIEŃSTWO

 

Niskie
1

Umiarkowane
2

Wysokie
3

 
 

SKUTKI

  Łagodne

1

1

2

3

 

  Umiarkowane

3

3

6

9

 

  Dotkliwe

6

6

12

18

 

(opracowano zgodnie z zaleceniami PMBOK®)

Projekty, w których występuje ryzyko z poziomem 18 nie powinny być realizowane, dopóki nie zostanie przygotowany satysfakcjonujący plan zarządzania tym ryzykiem zawierający skuteczne sposoby zapobiegania i reagowania. Wśród metod reagowania na wysokie ryzyko powinna się znaleźć rezerwa budżetowa po stronie klienta lub dostawcy. Stąd też powstaje konieczność przeprowadzenia wstępnej analizy ryzyka na etapie negocjacji kontraktu.

Poniższe zestawienie może być traktowane jako gotowa checklista, służąca do jakościowej analizy ryzyka na wszystkich etapach projektu wdrożeniowego ERP

ŹRÓDŁO RYZYKA

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

 

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; 

X

X

X

2

6

12

Zapewnienie zastępstwa;

zmiana wymagań w stosunku do planu wdrożenia

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ń;

X

   

2

3

6

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

nieefektywne wykorzystanie systemu;

Nieznajomość technologii informatycznej

wydłużenie etapu szkoleń;

 

X

X

1

3

3

szkolenia podstawowe z obsługi komputera

- ogólna obsługa komputera

nieefektywne wykorzystanie systemu;

 

duża liczba błędów obsługowych

Niedostateczne kwalifikacje zespołu projektowego (po stronie Wykonawcy)

błędne rozpoznanie wymagań klienta;

X

X

 

1

6

6

Szkolenia; 

błędy na etapie realizacji;

Zmiana składu zespołu projektowego;

niezgodność systemu z wymaganiami

Aktywny udział użytkowników kluczowych w akceptacji Analizy Wdrożeniowej

Kontraktowe i metodyczne

               

Niedostosowanie metodyki zarządzania projektem do typu kontraktu.
Metodyki "zwinne" trudno pogodzić z umową typu stała cena i zakres.

Brak dokumentacji projektu na potrzeby jego rozliczenia. Przekrocznie budżetu i terminów.

x

x

 

2

3

6

Zastosowanie metodyki hybrydowej, wykorzystującej podejście klasyczne do ogólnego planowania i rozliczenia projektu i "zwinne" do planowania szczegółowego i realizacji;
Określenie metodyki w umowie lub dokumencie Planu Wdrożenia

Niedostosowanie typu umowy do charakteru projektu i potrzeb klienta.
Projekt o niepewnym zakresie jest realizowany w ramach stałej ceny i zakresu

Obniżenie wartości produktu, przez ignorowanie zmian priorytetów realizacyjnych;
Mimo formalnego wypełnienia warunków kontraktu, produkt nie zaspakaja potrzeb użytkowników

x

   

3

3

9

Utworzenie rezerwy budżetowej na realizację nieprzewidzianych wymagań; Określenie w umowie warunków zmian zakresu

Niedostosowanie metodyki zarządzania projektem do skali projektu

Konflikt interpretacji zakresu dokumentacji i procedur; Nadmierne obciążenie stron dokumentacją i procedurami kosztem wartości produktu
Częsta konieczność zmiany umowy

X

X

X

2

3

6

Dostosowanie otwartego standardu zarządzania projektami do wielkości projektu zamiast stosowania ściśle określonej metodyki; Uzgodnienie kluczowych elementów metodyki w umowie lub Planie Projektu
Uzgodnienie

Brak rozbudowanej sieci partnerskiej producenta

Uzależnienie od dostawcy – osłabienie pozycji negocjacyjnej; zwiększenie kosztu i czasu, obniżenie jakości produktu;
Zwiększenie kosztu utrzymania systemu

x

x

x

1

6

6

Wybór produktu oferowanego i serwisowanego przez rozbudowaną sieć partnerską.;
Zakup praw do kodu dedykowanych komponentów systemu

Niedoprezyzowany zakres projektu i podziału obowiązków;

Konflikt interpretacji zakresu;
Częsta konieczność zmiany umowy

X

X

X

3

6

18

Dokładne opisanie zakesu projektu;
Skorzystanie z szablonu umowy;
Zastrzeżenie możliwości zmiany zakresu, kosztu i harmonogramu projektu na podstawie Planu Projektu i Analizy Wdrożeniowej za porozumieniem stron
Zastrzeżenie możliwości odstąpienia od umowy po etapie Planowania Wdrożenia

Przeniesienie na wykonawcę obowiązku opisu procesów biznesowych

Nieadekwatność implementowanych w systemie procesów w stosunku do rzeczywistych procesów biznesowych i potrzeb użytkowników; Opisanie procesów w sposób wygodny dla wykonawcy

X

   

1

6

6

Podział ról przy identyfikacji i opisie procesów: klient opisuje docelowe procesy biznesowe, wykonawca modeluje procesy na potrzeby systemu informatycznego. Docelowy model procesów weryfikowany jest i akceptowany przez obydwie strony.

Zaangażowanie firmy audytorskiej konkurencyjnej wobec wykonawcy

Nieobiektywność audytu;
Konflikt klienta z wykonawcą;
Zagrożenie poufności informacji

X

X

X

2

3

6

Zaangażowanie niekonkurencyjnej firmy audytorskiej

TECHNICZNIE

               

Unikalność technologii i oprogramowania

Uzależnienie od dostawcy – osłabienie pozycji negocjacyjnej; zwiększenie kosztu i czasu, obniżenie jakości produktu;

X

X

X

1

3

3

Przeprowadzenie ekspertyzy technologicznej na etapie wyboru produktu;

Zwiększenie kosztu utrzymania systemu

Uzgodnienie warunków  serwisowania na etapie umowy wdrożeniowej;

 

Zbadanie dostępności usług u konkurencyjnych dostawców

Dezaktualizacja komponentów systemu; zaprzestanie rozwoju i wsparcia dla komponentu przez producenta

Utrudnienie naprawy błędów;

X

X

X

1

9

9

Wybór rozwiązań o małej liczbie komponentów zewnętrznych, pochodzących od dużych i stabilnych finansowo dostawców;

Zablokowania rozwoju systemu;

Sprawdzenie wizji rozwoju komponentów

Uniemożliwienie aktualizacji

 

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

duże prawdopodobieństwo błędów w początkowej fazie eksploatacji sytemu;

X

X

X

3

3

9

Dokładne przetestowanie rozszerzeń funkcjonalnych przez uruchomieniem operacyjnym;

wymienione w zestawieniu modyfikacji.

podwyższone koszty supportowania i upgrade'ów;

Utworzenie rezerw zasobów na etapie Asysty;

 

Zwiększony koszt wdrożenia

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;

X

X

X

2

3

6

Upgrade

niedostosowanie infrastruktury sprzętowej do wersji oprogramowania

Niedostosowanie infrastruktury sprzętowej do wymagań systemu

obniżenie wydajności systemu

X

   

3

3

9

Rozbudowa sprzętu

Zmiana wymagań użytkowników

wzrost kosztów - tym wyższy im później w okresie realizacji projektu postulowane są zmiany;

X

X

X

3

3

9

Koncentracja wysiłków na etapie Analizy Wdrożeniowej;

 

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

Przeplanowanie projektu począwszy od Analizy Wdrożeniowej;

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

 

Realizacja zmian w systemie;

     

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

   
     

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

   

ZEWNĘTRZNE

               

Prawne - zmiany prawa handlowego, cywilnego 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;

 

X

X

1

3

3

Dublowanie łączy

problemy eksploatacyjne w trybie pracy on-line

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

opóźnienie realizacji wdrożenia

 

X

 

3

3

9

Wybór dostawców alternatywnych; Przeplanowanie harmonogramu;

- np. dostawca sprzętu, łącza internetowego, systemu EDI

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.

Świadomość ryzyka sama w sobie stanowi pewną wartość, ale bez umiejętności reagowania na zagrożenia powoduje głównie bezradność i frustrację.  Istnieją różne sposoby radzenia sobie z ryzykiem: unikanie, ograniczanie, akceptacja i transferowanie.

  • Unikanie, polegające na całkowitym wyeliminowaniu przyczyny  jest podejściem idealnym, lecz kosztownym i nie zawsze osiągalnym.  Jedynym sposobem uniknięcia jakiegokolwiek ryzyka jest rezygnacja z projektu.
  • Ograniczenie ryzyka  to zmniejszenie jego prawdopodobieństwa lub skutków. Typową metodą ograniczenia ryzyka harmonogramowego jest
  • Akceptacja ryzyka jest metodą najłatwiejszą, polegającą na nierobieniu niczego. Wbrew pozorom , to podejście może mieć sens – szczególnie wobec  ryzyka o małych skutkach i niskim prawdopodobieństwie.  Jest uzasadnione w przypadku, gdy reagowanie nie jest możliwe lub koszt reagowania przekracza koszt potencjalnych skutków.
  • Transferowanie ryzyka, to przeniesienie go na drugą stronę umowy lub na ubezpieczyciela.

Najprostszym przykładem transferu jest ustalenie kar umownych za niedotrzymanie terminu.

Tworząc własną listę kontrolną ryzyka powinniśmy posortować ją wg malejącego poziomu ryzyka i dla pozycji o najwyższych wartościach przygotować plan reagowania.

Chociaż w intuicyjnym rozumieniu, ryzyko jest zawsze zjawiskiem niepożądanym, w ujęciu formalnym jest traktowane neutralnie. W szerszej definicji ryzyka mieści się również ryzyko pozytywne, oznaczające nieplanowane zdarzenia, mogące mieć pożądany wpływ na efekty projektu. W kontekście wdrożeń ERP może to być pojawienie się w ramach darmowej aktualizacji nowej funkcjonalności systemu, która pozwoli na rezygnację z planowanych rozszerzeń funkcjonalnych i wykorzystanie zwolnionego budżetu na inne cele.

Do tej mówiliśmy głównie o jakościowej analizie ryzyka.  Analizą ilościową, odnoszącą się do harmonogramu,  kosztu i zakresu projektu zajmiemy się w kolejnym artykule.

© Wojciech Szyprowski, PMP

Read 4378 times Last modified on sobota, 29 sierpień 2015 16:48
Rate this item
(0 votes)

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

O nas

Jesteśmy grupą niezależnych konsultantów i twórców rozwiązań informatycznych w obszarze ERP, BI, CRM, BPMS i B2B.

Dane kontaktowe

Adres:
02-078 Warszawa,
Tel:
ul. Krzywickiego 2/1
Tel:
+(48) 22 666 97 71
Kom.:
+(48) 502 728 001
Kom.:
+(48) 604 586 470
E-Mail:
Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.
Website:
www.quereo.pl

Galeria

JoomShaper