Analiza wymagań jako klucz do redukcji ryzyka

IT - analiza ryzyka biznesowego
Podziel się!

W rozmowach z naszymi klientami lub partnerami często poruszamy problem ryzyka w projektach informatycznych. Omawiamy też zagadnienia, związane z budowaniem przewidywalności przedsięwzięć opartych o zmiany w zasobach IT. Najbardziej w tych dyskusjach zaskakujące jest podejście do analizy wymagań w kontekście zarządzania ryzykiem przedsięwzięcia.

Aby dobrze zdefiniować zagadnienie, spróbujmy rozważyć klasyczny problem szacowania kosztu, czasu oraz zakresu prac jeszcze na poziomie planowania inwestycji. Każda organizacja chce naturalnie znać te parametry przed podjęciem biznesowej decyzji o uruchomieniu danego działania.

Decyzje inwestycyjne w IT podejmowane są często na podstawie informacji o bardzo wysokiej niepewności, tymczasem powinny być analizowane z wykorzystaniem min. współczesnych metod minimalizacji ryzyka i definicji istotnych cech przedsięwzięcia.

Przetargi i wyceny rozwiązań IT

Jednym z klasycznych przykładów takiego działania jest budowanie postępowań przetargowych w modelu stałej ceny (tzw. fixed-price).  W oparciu o założenie, że analizę wymagań przeprowadza dostawca, który wygrał postępowanie, tworzy się wstępną listę wymagań biznesowych. Problemy może generować konfliktu interesów pomiędzy celami analityka (spełnienie celów biznesowych), a celem dostawcy (wdrożenie rozwiązania w estymowanym budżecie).

W praktyce najczęściej można mieć pewność, iż projekt końcowego rozwiązania będzie zgodny z pierwotnymi założeniami, estymowanymi na etapie postępowania zakupowego. Nie zawsze spełniane są cele zamawiającego.

Oczywistym powodem takiego postępowania jest fakt, że na etapie koncepcji biznesowej czy też definiowania potrzeb wobec proponowanego rozwiązania, bardzo trudno jest przyjąć poprawne założenia co do zakresu, czasu trwania oraz ceny projektu. Nie zrobimy tego bez usystematyzowanego opisu rozwiązania i jego specyfikacji. Konsekwencją tego i zarazem częstym problemem obserwowanym przez nas w wielu organizacjach jest duża rozpiętość cenowa ofert dostawców, której nie da się jednoznacznie uzasadnić obiektywnymi przesłankami (np. koszty licencji).

Stożek niepewności – „The cone of uncertainity”

Aby lepiej zobrazować ten problem, przyjrzyjmy się zagadnieniu stożka niepewności. Jako pierwszy koncept stożka zdefiniował Barry Boehm w opisie estymacji projektów metodą COCOMO II*. 

Następnie walidował swoje założenia empirycznie na podstawie badań licznych projektów dla US AirForce oraz NASA . Nazwy The cone of uncertainity dla zdefiniowania koncepcji Boehma jako pierwszy użył Steve McConnell**.

Software Estimation Demystifying the Black Art
Źródło: „Software Estimation: Demystifying the Black Art.”, S. McConnell, Microsoft Press, 2006

Stożek na ilustracji powyżej przedstawia wykres niepewności estymacji projektu. Niepewność jest mierzona na kolejnych etapach projektu jako poziom niedoszacowania lub przeszacowania. Kształt stożka jest raczej intuicyjny, co istotne i godne dyskusji to zbadane wartości wskaźników niepewności. Na etapie koncepcji rozwiązania, współczynnik niepewności wynosił dla naszego przykładu 4 x. Oznacza to, że dostawca jest w stanie nawet kilkukrotnie zawyżyć lub zaniżyć rozmiar projektu!

Wysokie ryzyko umów do projektów IT

Wiele organizacji rozpoczyna negocjacje projektów fixed price z dostawcami właśnie na tym etapie przedsięwzięcia. Doskonale tłumaczy to efekt znaczącej rozbieżności wycen na poziomie ofert, a co gorsza pokazuje wysoki poziom ryzyka z jakim musi liczyć się zamawiający w momencie zawierania umowy.

Takie podejście skutkuje szeregiem problemów, które są konsekwencją braku wspólnie opracowanego zakresu prac pomiędzy stronami. Najważniejsze to:

  • Zmniejszenie zakresu dostarczonego rozwiązania,
  • Re-negocjacje ceny w trakcie wdrożenia,
  • Wydłużenie czasu projektu wskutek zmienności wymagań,
  • Brak spełnienia kluczowych wymagań,
  • Brak spełnienia zakładanych celów biznesowych.

Analizując dalej przebieg stożka niepewności, na uwagę zasługują dwa fakty. Zakończenie etapu analizy wymagań redukuje wskaźnik niepewności do poziomu 1.5, a zdefiniowanie interfejsu użytkownika zmniejsza go do poziomu 1.25.  Stanowi to akceptowalny poziom ryzyka, zwiększając szanse przedsięwzięcia na sukces.

Analizy biznesowe i redukcja ryzyka 

Obserwacje na temat roli projektu interfejsu użytkownika na etapie analizy wymagań i definicji rozwiązania zdają się być potwierdzane przez wielu analityków, którzy chętnie włączają to narzędzie do swojego warsztatu pracy. Nasze doświadczenia w Inteca również potwierdzają istotę tego elementu, dlatego zalecamy stosowanie projektu interfejsów użytkownika na etapie walidacji wymagań, np. podczas Structured Walthrough lub Business Process Walkthrough.

Naszym zdaniem, istotę sukcesu stanowi odpowiednie ujęcie problemu, skupiające uwagę interesariuszy biznesowych na pytaniach kategorii „CO?” zamiast „JAK?”. 

Analiza biznesowa czy też analiza wymagań są istotnymi elementem wpływającym na redukcję ryzyka realizowanego przedsięwzięcia. Istotne jest zatem, aby decyzje o uruchomieniu projektu lub wyborze dostawcy podejmować po wykonaniu tych aktywności.

Wiele organizacji wciąż funkcjonuje w modelu wyceny i decyzji o uruchomieniu projektów na podstawie ogólnych założeń, zarówno w przypadku projektów wewnętrznych, jak i tych realizowanych przez zewnętrznych dostawców. Często używamy w tym przypadku analogii do budownictwa, w którym żaden wykonawca nie wyobraża sobie wiarygodnej wyceny całości inwestycji bez wglądu w dokumentację architektoniczną czy konstrukcyjną, wykonaną zgodnie z normami i standardami budowlanymi.

Standardy analizy biznesowej

Opisane postępowanie wydaje się mało intuicyjne, ale wielu naszych rozmówców przytacza problem braku odpowiednich zasobów czy kompetencji w organizacji. Dochodzą do tego kwestie takie jak abstrakcyjny charakter projektów IT czy braki dojrzałości w metodykach i standardach pracy w IT (chociażby w porównaniu do sektora budownictwa).

Problem zasobów i kompetencji jest tutaj zasadny (jest to jednak temat na osobny artykuł), ale sprawa abstrakcji materii czy też standardów i metod pracy wydaje się być pojmowana błędnie.

Istnieją sprawdzone metodyki i standardy dla praktyki analizy biznesowej (wiodącym w ostatnim czasie jest BABOK, wydany przez International Institute of Business Analysis), które pozwalają na systematyzację tej dziedziny w organizacjach.

W Inteca pomagamy naszym klientom w standaryzacji procesów analizy biznesowej, wykorzystując najlepsze praktyki z BABOK i wdrażając gotowe rozwiązania Inteca Business Analysis Enterprise Standard, którego celem jest budowa skutecznej, powtarzalnej i dopasowanej do charakteru organizacji praktyki analizy biznesowej. Wykorzystywanie takiego narzędzia przyczynia się do istotnej redukcji ryzyka inwestycji, bazujących na technologiach informatycznych.


Podziel się!