ZARZ DZANIE I POMIAR RYZYKA W PROJEKCIE INFORMATYCZNYM

Transkrypt

1 ZARZ DZANIE I POMIAR RYZYKA W PROJEKCIE INFORMATYCZNYM MAGDALENA KIERUZEL Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Streszczenie Celem artykułu jest wskazanie metody warto ci nara onej na ryzyko VaR (Value at Risk) jako podej cia daj cego mo liwo wyra enia w sposób finansowy ryzyka projektu. Wykorzystanie VaR stanowi wsparcie dla oceny ryzyka w projekcie. W artykule przedstawiono równie tradycyjny sposób prezentacji ryzyka w oparciu o metodyk zarz dzania projektami Prince2. Słowa kluczowe: zarz dzanie ryzykiem, pomiar ryzyka, warto nara ona na ryzyko VaR (Value at Risk), metodyka zarz dzania projektami Prince2 1. Wprowadzenie Projekty informatyczne charakteryzuj si wysok zło ono ci i dlatego s uznawane za jedne z najbardziej ryzykownych przedsi wzi. Ryzyko to jeden z głównych czynników, który musi by wzi ty pod uwag przy zarz dzaniu dowolnym projektem. Zadaniem zarz dzaj cych ryzykiem jest jego kontrolowanie i ograniczanie po to by projekt zako czył si powodzeniem. Najcz ciej ryzyko jest definiowane jako niepewno, e dany wynik zostanie osi gni ty. Według Instytutu Zarz dzania Projektami (PMI Project Management Institute) ryzyko jest niepewno ci co do wyst pienia zdarzenia lub warunku, które je li wyst pi, b d miały istotnie negatywny lub pozytywny wpływ na przebieg projektu. Głównym zadaniem przy zarz dzaniu ryzykiem w projekcie jest radzenie sobie z sytuacj nara enia projektu na niepomy lne (negatywne) zdarzenie, celem jest panowanie nad stopniem tego nara enia poprzez realizacj działa, które utrzymaj ryzyko na akceptowalnym poziomie w sposób efektywny kosztowo. Ka da czynno w projekcie informatycznym (wdro eniowym czy konstrukcyjnym) jest zwi zana z okre lonym ryzykiem. Wa ne, aby oceni stosuj c rachunek ekonomiczny ryzyko dla wszystkich czynno ci po to, aby uzyska warto ciowy obraz ryzyka dla całego projektu. 2. Cykl zarz dzania ryzykiem na przykładzie metodyki PRINCE2 Ka dy projekt poddawany jest nieustannym zmianom, zarówno tym wyst puj cym bezpo- rednio w otoczeniu biznesowym jak i w dalszym rodowisku. Zmiany dotycz równie zagro e, na które nara ony jest projekt. W trakcie post pów prac pojawiaj si nowe ryzyka, istotno innych zmienia si, a jeszcze inne trac na znaczeniu. Dlatego te cykl zarz dzania ryzykiem w projekcie powinien by i jest kilkakrotnie powtarzany. W metodyce Prince2 cykl zarz dzania ryzykiem realizowany jest w kilku głównych krokach (rys. 1).

2 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, A N A L I Z A R Y Z Y K A OCENA ZAGRO E OKRE LENIE MO - LIWYCH REAKCJI NA ZAGRO ENIE WYBÓR REAKCJI MONITOROWANIE I RAPORTOWANIE PLANOWANIE DZIAŁA I PRZY- DZIAŁ ZASOBÓW ZARZ DZANIE RYZYKIEM Rysunek 1. Cykl zarz dzania ryzykiem według metodyki PRINCE2 ródło: Opracowanie własne na podstawie: Managing Successful Projects with Prince2. The Stationery Office Ltd., CCTA, Norwich Pierwszym jest identyfikowanie zagro e. Metodyka wyró nia kilka podstawowych kategorii ryzyka, które mog stanowi punkt startowy dla identyfikacji. Główne obszary ryzyka organizacji w odniesieniu do projektów to [5]: Ryzyka strategiczne, handlowe (np. bankructwo wykonawców, zmienno rynku, niespełnienie przez dostawców zobowi za wynikaj cych z umowy w aspekcie jako ci, ilo ci, terminów). Ryzyka ekonomiczne, finansowe, rynkowe (np. inflacja, zmienno kursów walut, niestabilno stóp procentowych). Ryzyka prawne (np. nowe zmienione prawo, które uniewa nia zało enia b d ce podstaw dla działa w projekcie, wymagania licencyjne, zmiany w strukturze podatków). Ryzyka organizacyjne, zarz dcze (np. słabe przywództwo, zła polityka firmy, niekompetentne zarz dzanie, niekompletne informacje). Ryzyka rodowiskowe (np. katastrofy naturalne, problemy transportowe). Ryzyka techniczne, eksploatacyjne, infrastrukturalne (np. bł d ludzki, niedbalstwo zawodowe, bł dy wykonawcze). Wa ne, aby przy identyfikacji ryzyka nie dokonywa jego oceny. Mogłoby to doprowadzi do nieuzasadnionych decyzji o wykluczeniu danego ryzyka z listy potencjalnych zagro e. Wszystkie

3 118 Magdalena Kieruzel Zarz dzanie i pomiar ryzyka w projekcie informatycznym ryzyka zostaj wpisane do tzw. Rejestru Ryzyka prowadzonego i uzupełnianego w trakcie realizacji projektu. Kolejnym krokiem w cyklu zarz dzania ryzykiem jest ocena zagro e. W metodyce Prince2 przyjmuje si, e ryzyko projektu okre laj dwie miary tj. prawdopodobie stwo wyst pienia ryzyka oraz jego wpływ na projekt. Dokonuj c oceny ryzyka zajmujemy si z jednej strony oszacowaniem faktycznego prawdopodobie stwa wyst pienia danego zdarzenia, a z drugiej strony okre lamy jaki jest jego stopie oddziaływania (wpływu) na projekt. Wpływ danego zdarzenia powinien by rozpatrywany pod k tem takich elementów jak: czas, koszty, jako, zakres, korzy- ci, ludzie. Pomocne w wizualizacji ryzyk wyst puj cych w projekcie jest ich przedstawienie za pomoc tzw. sumarycznego profilu ryzyka. Jest to graficzna prezentacja informacji, które znajduj si w Rejestrze Ryzyka. Profil ryzyka prezentuje zagro enia wykorzystuj c identyfikatory zagro e w kategoriach prawdopodobie stwa wyst pienia oraz stopnia oddziaływania. Tablica profilu ryzyka jest na bie co uzupełniana wraz z aktualizowanym Rejestrem Ryzyka. Te zagro enia, które zostały zakwalifikowane powy ej tzw. linii tolerancji ryzyka uwa ne s za najistotniejsze, maj ce najwi kszy wpływ na powodzenie projektu, a decyzje odno nie działa, jakie nale y podj w ich zakresie powinny by podejmowane na najwy szym szczeblu struktury zarz dzania projektem. Prawdopodobie stwo wysokie Ryzyko nr1, nr2 Ryzyko nr 6 rednie Ryzyko nr4 Ryzyko nr5 małe słabe umiarkowane du e Rysunek 2. Sumaryczny profil ryzyka Linia tolerancji ryzyka Ryzyko nr3 Oddziaływanie ródło: Opracowanie własne na podstawie: Managing Successful Projects with Prince2. The Stationery Office Ltd., CCTA, Norwich Po etapie oceny przyst pujemy do okre lenia mo liwych reakcji na zagro enie. Wykorzystuje si tutaj pi kategorii reakcji pozwalaj cych wybra odpowiednie działanie: Zapobieganie (prewencja) polegaj ce na usuni ciu zagro enia; wprowadza si rodki zaradcze, które albo wyeliminuj wyst pienie zagro enia, albo wyeliminuj jego wpływ na projekt. Redukowanie zwi zane z działaniami, które pozwol w jaki sposób sterowa zagro eniem tak, aby zmniejszy prawdopodobie stwo jego wyst pienia albo ograniczy jego oddziaływanie na projekt. Przeniesienie działanie polegaj ce na przekazaniu zarz dzania ryzykiem stronie trzeciej np. za po rednictwem polisy ubezpieczeniowej czy klauzuli kary. W wyniku tego działania skutki zagro enia nie stanowi dalej problemu dla powodzenia projektu.

4 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, Akceptacja polegaj ca na pogodzeniu si ze zidentyfikowanym zagro eniem. Dzieje si tak najcz ciej wtedy, gdy przeciwdziałania staj si nieefektywne kosztowo lub wtedy, gdy prawdopodobie stwo wyst pienia oraz skutki ryzyka s na akceptowalnym poziomie. Tworzenie rezerw polegaj ce na organizowaniu i planowaniu działa po to, aby uruchomi je wtedy gdy zagro enie si urzeczywistni. Odpowiednie reakcje na ryzyko mog wynika z jednej lub kilku przedstawionych powy ej kategorii. Istniej sytuacje, w których nie ma opłacalnych działa eliminuj cych dane zagro enie. Wtedy nale y zastanowi si czy mo na zaakceptowa dane ryzyko, czy te projekt jest zbyt ryzykowny i nale y zaprzesta jego kontynuowania. Etap wyboru reakcji w cyklu zarz dzania ryzykiem wi e si z identyfikacj i ocen kilku wariantów post powania. Istotne jest, aby wybrane działania były proporcjonalne do zagro enia. Ka de przeciwdziałanie generuje okre lone koszty, a wi c musi przynie korzy odpowiedni do poniesionych nakładów. W zwi zku z tym, e cz sto istnieje kilka mo liwych reakcji (a ka da daje inne efekty) mo- emy wybra jedno działanie albo kombinacj kilku. Po dokonaniu wyboru reakcji przygotowujemy i wdra amy plany zarz dzania ryzykiem. Dokonany wybór reakcji na zagro enie wi e si z konieczno ci planowania i przydzielania zasobów. W metodyce Prince2 ten etap zarz dzania ryzykiem obejmuje okre lenie ilo ci i rodzaju zasobów potrzebnych do realizacji wybranych przeciwdziała. Wymagana jest tak e konieczno potwierdzenia celowo ci podj cia działa, okre lonych podczas oceny zagro enia, w wietle wszystkich informacji dodatkowych. Dla zarz dzania ryzykiem konieczne jest przeznaczenie odpowiednich rodków bud etu, czasu, zasobów. Wa ne, aby odpowiednie nakłady były przekazane nie tylko na działania dotycz ce reakcji na zaistniałe zagro enie, ale aby istniały rodki na prowadzenie działa wst pnych w procesie zarz dzania ryzykiem, takich jak ocena ryzyka, która wymaga zró nicowanej wiedzy narz dzi czy technik. Do wiadczenie pokazuje, e przeznaczenie odpowiedniego bud etu we wczesnych fazach cyklu ycia projektu skutkuje wi kszym powodzeniem w zarz dzaniu ryzykiem. Ostatnim etapem w cyklu zarz dzania ryzykiem jest monitorowanie i raportowanie. W zwi zku z przyj tymi reakcjami na ryzyko konieczne staje si stworzenie mechanizmów dotycz cych monitorowania i raportowania ich realizacji. Działania z tego zakresu mog polega jedynie na monitorowaniu zidentyfikowanego zagro enia lub te obejmowa mog obserwowanie wczesnych sygnałów zwi zanych z rozwojem zagro enia, czy te sprawdzanie efektywno ci ogólnego zarz dzania ryzykiem. W przypadku zagro e finansowych ryzyko mo e by przedstawiane w postaci danych liczbowych natomiast inne niemierzalne zagro enia mog by subiektywnie szacowane przez osoby b d ce wła cicielami 1 danych ryzyk w projekcie. Szacowanie mo e polega na przypisaniu okre- lonych wag dla prawdopodobie stwa i wpływu. Pomimo wprowadzonych w metodyce sposobów oceny ryzyka przez pryzmat prawdopodobie stwa wyst pienia oraz wpływu na projekt nie otrzymujemy miary ryzyka w wymiarze finansowym. Prezentacja ryzyka w Prince2 skutkuje jedynie zakwalifikowaniem danego zagro e- 1 Wła cicielem ryzyka jest ta osoba, która jest odpowiedzialna za dane ryzyko ( została do niego przypisana ) tzn. ma obowi zek je monitorowa i raportowa wszelkie zmiany, które zachodz w jego obszarze.

5 120 Magdalena Kieruzel Zarz dzanie i pomiar ryzyka w projekcie informatycznym nia do klasy ryzyka niskiego, redniego, b d wysokiego. Taki sposób prezentacji nie jest wiarygodny szczególnie wtedy gdy chcemy porówna te same zagro enia z ró nych projektów. 3. Pomiar ryzyka w projektach informatycznych (metoda Value at Risk) Zanim przyst pimy do okre lania ryzyka musimy dokona identyfikacji wszystkich poszczególnych działa w projekcie. Przebieg procesów w projekcie mo na przedstawi w postaci drzewa czynno ci informatycznych. Rysunek 3. Drzewo czynno ci w projekcie informatycznym ródło: Opracowanie własne na podstawie: Lasi ski M.: Zarz dzanie projektami informatycznymi. Wydawnictwo Naukowe PWN. Warszawa 2006.

6 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, Przykładowo dla procesu migracja danych wyznaczono czynno ci składowe konieczne w jego realizacji. Podobna dekompozycja mo e by przedstawiona dla dowolnego procesu. Aby okre li całkowite ryzyko, z jakim wi e si realizacja projektu konieczne jest okre lenie poszczególnych ryzyk dla ka dego procesu. Zastosowa mo na tutaj metod Var (Value at Risk warto ryzykowana, warto nara ona na ryzyko), która jest miar statystyczn, pokazuj c maksymaln strat jaka mo emy uzyska dla danego procesu przy zało onym poziomie ufno ci. VaR dla projektu informatycznego liczona jest jako iloczyn prawdopodobie stwa ryzyka niepowodzenia procesu i warto ci nara onej na ryzyko. Przez warto nara on na ryzyko b dziemy rozumieli warto realizacji procesu w projekcie. Całkowita warto ryzyka w projekcie b dzie wyra ona wzorem [6]: VaR = n R Va (1) i i i gdzie R i prawdopodobie stwo wyst pienia ryzyka w obszarze i-tego procesu, Va i warto nara ona na ryzyko, warto i-tego procesu. Dla okre lenia warto ci prawdopodobie stwa mo na przyj dwa podej cia. Pierwsze to wykorzystanie wiedzy poszczególnych członków zespołu projektowego do szacowania prawdopodobie stw ryzyk w obszarze danej czynno ci (procesu). Druga mo liwo to wykorzystanie du ej ilo ci danych historycznych (ze zrealizowanych ju projektów) do estymacji ryzyka. Takie podej cie jest proponowane przez Instytut In ynierii Oprogramowania Uniwersytetu Carnegie Mellon w Pittsburgu, który w raporcie Software Risk Management [8] publikuje szacunkowe prawdopodobie stwa wyst pienia ryzyka w ró nych obszarach projektu. Zgodnie z przyj tymi poni ej warto ciami mo emy wyliczy warto ryzyka dla procesu migracja danych zgodnie ze wzorem (1) przyjmuj c przedział ufno ci na poziomie 99% (warto rekomendowana przez Komitet Bazylejski): Czynno składowa procesu Porz dkowanie danych w systemach dotychczas u ywanych Opracowanie narz dzi i skryptów do migracji i weryfikacji danych Migracja danych do nowego systemu Weryfikacja poprawno ci danych Tabela 1. Ocena warto ci ryzyka z zastosowaniem metody VaR Warto Prawdopodobie stwo ryzyka Warto ryzykowana realizacji w obszarze czynno ci (VaR) zł 16,6% 4 249,6 zł zł 13,2% zł 720 zł 2,8% 20,16 zł zł 13,7% 1 380,96 zł Warto ryzykowana (VaR) dla procesu migracja danych 6 978,72 zł ródło: Opracowanie własne na podstawie: Higuera R.P.,Haimes Y.Y.:Software Risk Management. Software Engineering Institute, Carnegie Mellon University, 1996.

7 122 Magdalena Kieruzel Zarz dzanie i pomiar ryzyka w projekcie informatycznym Z powy szych wylicze wynika, e warto nara ona na ryzyko w obszarze procesu migracja danych w projekcie wynosi 6 978,72 zł. Podanie całkowitej warto ci ryzyka w wymiarze finansowym dla projektu informatycznego jest mo liwe dzi ki zastosowaniu metody VaR. Szacowanie warto ci ryzyka proponowanego w metodyce Prince2 nie skutkuje podobn kwantyfikacj, st d warto uzupełni ocen ryzyka w projekcie o proponowan metod tak, aby w sposób jednoznaczny móc okre li poziom ryzyka w momencie podpisywania kontraktu na wykonanie projektu informatycznego. 4. Zako czenie Zgodnie z ide zarz dzania ryzykiem d ymy do utrzymania ryzyka na takim poziomie, który b dzie akceptowalny, czyli zapewni takie warunki, w których nie poniesiemy (w wyniku wyst pienia zdarzenia) strat wi kszych ni zało ono. Pomocne w realizacji tego postulatu jest okre lenie warto ci nara onej na ryzyko. Miara VaR jest najcz ciej wykorzystywana w obszarze zarz dzania ryzykiem portfela kredytowego banku, ale mo na j skutecznie zastosowa przy ocenie ryzyka w projekcie informatycznym. Zastosowanie metody VaR daje mo liwo kwantyfikacji ryzyka na czynnik finansowy, to z kolei umo liwia porównywanie ryzyk wyst puj cych w ró nych projektach. Dla Zarz du firmy wydaj cego zgod na realizacj projektu informatycznego istotna b dzie informacja na temat ogólnego ryzyka, na jakie nara ony jest projekt. Metoda VaR mo e wspiera okre lenie całkowitego ryzyka dla projektu składaj cego si z szeregu ró nych procesów, które trudno porównywa stosuj c prosty rachunek. [1] Best P. Warto nara ona na Ryzyko. Oficyna Ekonomiczna, Kraków [2] Fr czkowski K. Zarz dzanie projektem informatycznym. Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław [3] Higuera R.P.,Haimes Y.Y.:Software Risk Management. Software Engineering Institute, Carnegie Mellon University, [4] Kalinowski M. Zarz dzanie ryzykiem walutowym w przedsi biorstwie. CeDeWu, Warszawa [5] M.Flasi ski: Zarz dzanie projektami informatycznymi. Wydawnictwo Naukowe PWN, Warszawa [6] Majerowska E. Warto nara ona na ryzyko a ryzyko inwestowania w akcyjne fundusze inwestycyjne. Zeszyty Naukowe Uniwersytetu Szczeci skiego, Nr 415, Prace Ekonometrii i Statystyki nr 16, [7] Managing Successful Projects with Prince2. The Stationery Office Ltd., CCTA, Norwich [8] Riehl H. Zarz dzanie ryzykiem. WIB, Warszawa [9] Wróblewski P. Zarz dzanie projektami informatycznymi dla praktyków. Wydawnictwo Helion, 2005.

8 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 28, MANAGEMENT AND MEASURING THE RISK IN AN IT PROJECT Summary In the article there are defined the steps in the management cycle of the project according to the methodology of Prince 2. It is shown the traditional way of quantification of the risk in the project and it is proposed to use the value held up to the risk VaR (Value at Risk) as the way which gives us the possibility of expressing in the financial way the total risk of the project. Keywords: risk management, risk measurement, Value at Risk (VaR), Prince2 project management methodology Magdalena Kieruzel Katedra Organizacji i Zarz dzania Wydział Informatyki Zachodniopomorski Uniwersytet Technologiczny w Szczecinie ul. ołnierska 49, Szczecin mkieruzel@wi.zut.edu.pl