Podstawowe Pojęcia Wpływ Ryzyka

Transkrypt

1 Jak Skutecznie Zamawiać Systemy Informatyczne Podstawowe Pojęcia Wpływ Ryzyka 13 Listopad, 2012 Konferencja PIIT Jak Skutecznie Zamawiać Systemy Informatyczne Andrzej Więckiewicz Dyrektor ds. Rozwoju Sektora Publicznego

2 Doniesienia prasowe z sytuacji rynku budowlanego Zdaniem obu specjalistów firma powinna umieć przewidzieć ryzyko, np. związane ze wzrostem cen materiałów budowlanych. Równie ważna jest reakcja na pojawiające się zagrożenia. Eksperci: Firmy budowlane bankrutują, bo wchodzą w ryzykowne projekty Wyborcza biz Piętą achillesową polskich firm jest zarządzanie ryzykiem - wynika z badań, które na zlecenie firmy doradczej Deloitte przeprowadziła w marcu i kwietniu firma badawcza Millward Brown SMG/KRC Eksperci: Firmy budowlane bankrutują, bo wchodzą w ryzykowne projekty Wyborcza biz wynika, że najwyższa dojrzałością procesów zarzadzania projektami budowlanymi charakteryzują się spółki z kapitałem zagranicznym, notowane na GPW, o przychodach przewyższających 500mln PLN raport Deloitte.i okazuje się, że jedynym pomysłem na rekompensaty jest przeniesienie kosztów na podwykonawców, a to dla większości z nich jest ciężar nie do uniesienia....głównym powodem kłopotów jest specyfika realizowanych kontraktów, w których najważniejszym kryterium była cena, a realizacja kontraktów wymaga dużego zaangażowania kapitału obrotowego. Zaniżanie cen i brak doświadczenia. Firmy budowlane w zapaści, Wyborcza.biz, kwiecień 2012 Murator Plus Firmy budowlane masowo bankrutują, bo mają problemy z dokończeniem realizacji nierentownych kontraktów autostradowych. Polskie Drogi za Pół Ceny, Wprost, sierpień 2012

3 Wybrane Elementy Raportu Deloitte Polskie Firmy Budowlane 2012 Źródło: Polskie firmy budowlane 2012, Deloitte Badanie poziomu dojrzałości zarza dzania projektami budowlanymi

4 Wybrane Elementy Raportu Deloitte Polskie Firmy Budowlane 2012 Źródło: Polskie firmy budowlane 2012, Deloitte Badanie poziomu dojrzałości zarza dzania projektami budowlanymi

5 Bazowy model kalkulacji ryzyka projekty informatyczne R Y Z Y K O = (Prawdopodobieństwo x Skutek) - Odporność Prawdopodobieństwo wystąpienia czynników Skutek odzwierciedla rozmiar szkód, jakie poniesie organizacja w zakresie osiągnięcia jednego lub kilku celów Odporność odzwierciedla zdolość organizacji w reakcji na wystąpienie zagrożenia Przykład: 20% szansa, że wydarzy się Spowoduje straty 1 mln zł Które firma może lub nie może ponieść. Jako punkt startowy przyjmujemy, że organizacja posiada profil strategii ryzyka i zdefiniowała zakres i tolerancję do przyjęcia różnych ryzyk. Zakładamy, że organizacje zidentyfikowały najbardziej oczywiste źródła, które ich dotyczą Źródło: IBM Global Business Services

6 Przygotowanie budżetu ze świadomością wystąpienia ryzyka Przygotowanie budżetu ze świadomością wystąpienia ryzyk Risk Adjusted Budgeting 1. Budżet operacyjny wpierw przygotowany bez ryzyk (bez ryzyka) Wycena Poz. A Poz. B Poz. C $x $x $x 2. Gdy ryzyka są zidentyfikowane, prawdopodobieństwo, skutki oraz możliwości reagowania na ryzyka są analizowane Ryzyko 1 Ryzyko 2 Ryzyko 3 3. Te są wtedy usupełnione aby ozwierciedlać plany reagowania na ryzyka. Budżet po wliczeniu ryzyka Poz. A Poz. B Poz. C $x $x $x $x R Y Z Y K O = (Prawdopodobieństwo x Skutek) - Odporność Powyższe jest stale uaktualniane i usprawniane w miarę pozyskania lepszej wiedzy w czasie. Źródło: IBM Global Business Services

7 Obszary weryfikowane pod kątem wystąpienia ryzyka

8 Co to jest open scope Każdy projekt jest oceniany pod względem ryzyka (IBM kieruje się skalą BTT 1 5, oraz skalą ryzyka projektu 1 9) Otwarty zakres umowy powoduje (teoretycznie) nieograniczone ryzyko związane z dodatkowym nakładem pracy wykonawcy Przykłady: Wymóg dostosowania rozwiązania do zmian prawnych Wprowadzenie nieograniczonych ilości zmian Obsługa nieograniczonych ilości wolumenów (np. danych, zgłoszeń, itp.) Nieprecyzyjne warunki odbioru Integracja z systemem do którego niezbędna będzie współpraca autora

9 Kosztotwórcze Przykłady Ryzyk w Zamówieniach Nieograniczona odpowiedzialność. Rękojmia, niewyłączona lub nieograniczona umownie. Kary umowne bez limitu. Sztywna konstrukcja warunków umownych. Niewyłączone umownie wykonanie zastępcze. Przeniesienie praw majątkowych oprogramowania na materiały wytworzone w ramach projektu bez licencji zwrotnej. Brak regulacji zabezpieczającej przed roszczeniami osób trzecich. Nieprecyzyjne warunki odbioru.

10 Inne aspekty związane z ryzykiem Niedostosowanie specyfikacji technicznej do warunków prawnych Brak np. sposobu zarządzania zmianami Sztywne, nie dające możliwości zmiany określenie warunków kontraktu bardzo często nie pozwala wykonawcom na skuteczne zarządzanie ryzykiem Rola architekta rozwiązania przechodzi na zamawiającego Art. 36, PzP: Specyfikacja istotnych warunków zamówienia zawiera co najmniej: pkt 16: istotne dla stron postanowienia, które zostaną wprowadzone do treści zawieranej umowy w sprawie zamówienia publicznego, ogólne warunki umowy albo wzór umowy, jeżeli zamawiający wymaga od wykonawcy, aby zawarł z nim umowę w sprawie zmówienia publicznego na takich warunkach; Do dokumentacji przetargowej klienci załączają najczęściej wzory umów. O ile wzory umów sprawdzają się w prostych przetargach to z naszej perspektywy najczęściej nie sprawdzają się w kontraktowaniu skomplikowanych systemów IT. Negocjacje zawsze doprowadzają do lepszych rezultatów (w każdej dziedzinie)

11 Sposoby na zmniejszenie poziomu ryzyka w projektach Możliwość wdrożenia przez zamawiającego planu reakcji na zagrożenia (mitigation) Przetestowanie rozwiązania, (pilot) Stosowanie ogólnych warunków umowy zamiast wzoru umowy Wybór korzystnej oferty na podstawie oceny rozwiązania Znaczne lub nieograniczone ryzyko powoduje wzrost wyceny (budżetu) projektu

12 Stosowanie dobrych praktyk w ocenie ofert na przykładzie instytucji pomocy społecznej w Danii Funkcjonalność i Możliwości Rozwojowe Systemu Waga 40% 1. Osiągnięcie funkcjonalnych i nie-funkcjonalnych wymogów dla kadry kierowniczej zamawiającego 45% 2. Osiągnięcie funkcjonalnych I nie-funkcjonalnych wymogów dla kadry wsparcia zamawiającego 30% 3. Możliwości elastycznego rozwoju funkcjonalnego wraz z parametrami kontroli i modyfikacji nowych/istniejących procesów/podprocesów wprowadzonych w wyniku zmian prawnych oraz elastyczność w rozpowszechnieniu zmian 25% Architektura Waga 20% 1. Wykorzystane interface-y użytkownika, bezpieczeństwo systemu, stosowanie zasad otwartych standardów, interoperacyjności, oraz elastyczności w odszukiwaniu danych, w tym tworzenie raportów przez dostarczony interface 45% 2. Sposób integracji z zewnętrznymi źródłami danych 30%. 3. Wykorzystanie zasad otwartych standardów architektonicznych, standardów, interoperacyjności, luźnego powiązania (loose coupling), elastycznych i modularnych komponentów w rozwiązaniu w celu zapewnienia fizycznej skalowalności rozwiązania oraz możliwości utrzymania systemu na najwyższym poziomie 25%

13 Stosowanie dobrych praktyk w ocenie ofert na przykładzie instytucji pomocy społecznej w Danii Cena 1. Wycena kontraktu 60%: Całkowita suma: 60% Harmonogram płatności: 20% Waga 25% Opcje i opłata za rozwiązanie umowy: 10% Stawki godzinowe i upusty: 10% 2. Ceny oferowane w ramach kontraktu na utrzymanie systemu 40% Proponowana płatność Etap1, Etap 2, Etap 3, Etap 4 60% Wycena dodania następnego odbiorcy systemu 15% Koszty jednostkowe zwiększenia lub zmniejszenia wolumenu 15% Opcje I opłata za rozwiązanie umowy utrzymaniowej 10% Sposób Zabezpieczenia Poprawności Wdrożenia Waga 15% 1. Procent wykorzystania obecnego oprogramowania w proponowanym rozwiązaniu (stopień standaryzacji w proponowanym rozwiązaniu) 40% 1. Harmonogram projektu, wraz z harmonogramem dostaw częściowych 35% 1. Jakość zespołu projektowego oraz metodyka 25% Zakres kompetencji i kwalifikacji kluczowego personelu oferenta zarówno w fazie wdrożenia jak I utrzymania systemu 40% Sposób zaangażowania zespołu zamawiającego 20% Propozycja organizacji współpracy w fazie wdrożenia systemu 15% Propozycja organizacji współpracy w fazie utrzymania systemu 15% Opis metodyki prowadzenia projektu 10%

14 Wybór korzystnej oferty na podstawie oceny rozwiązania 1. Określenie głównych parametrów wymaganej funkcjonalności 2. Dokonanie wyboru oferty w oparciu o przejrzysty i z góry zdefiniowany mechanizm oceny 3. Sprecyzowanie ogólnych warunków umowy Umożliwia zamknięcie rozwiązania w całość Pozwala architektom rozwiązania dobranie optymalnych parametrów usługi Pozwala architektom na wykazanie wartości, jaką niesie współpraca z kompetentnym wykonawcą Ogranicza ryzyko a przez to cenę rozwiązania Zamawiający korzysta z wiedzy i doświadczenia wykonawcy

15