definicja: identyfikacja ryzyka to proces określania ryzyka, który może potencjalnie uniemożliwić programowi, przedsiębiorstwu lub inwestycji osiągnięcie jego celów. Obejmuje ona dokumentowanie i informowanie o problemie.
słowa kluczowe: ryzyko, identyfikacja ryzyka, zarządzanie ryzykiem
MITRE se role & oczekiwania: oczekuje się, że inżynierowie systemów MITRE (ses) pracujący nad programami rządowymi zidentyfikują ryzyka, które mogą mieć wpływ na projekt i program. Oczekuje się, że napiszą i przejrzą Oświadczenia o ryzyku, które są jasne, jednoznaczne i poparte dowodami .
kontekst
identyfikacja ryzyka jest krytycznym pierwszym etapem procesu zarządzania ryzykiem przedstawionym na rysunku 1.
celem identyfikacji ryzyka jest wczesna i ciągła identyfikacja zdarzeń, które, Jeśli wystąpią, będą miały negatywny wpływ na zdolność projektu do osiągnięcia celów wydajności lub wydajności. Mogą one pochodzić z projektu lub ze źródeł zewnętrznych.
istnieje wiele rodzajów ocen ryzyka, w tym oceny ryzyka programu, oceny ryzyka wspierające decyzję inwestycyjną, analiza alternatyw oraz oceny niepewności operacyjnej lub kosztowej. Identyfikacja ryzyka musi odpowiadać rodzajowi oceny wymaganej do wspierania podejmowania decyzji opartych na informacjach o ryzyku. W przypadku programu akwizycyjnego pierwszym krokiem jest określenie celów i celów programu, co sprzyja wspólnemu zrozumieniu przez cały zespół tego, co jest potrzebne do sukcesu programu. Daje to kontekst i ogranicza zakres identyfikacji i oceny ryzyka.
Identyfikacja ryzyk w programie Inżynierii Systemów
istnieje wiele źródeł ryzyka. W celu identyfikacji ryzyka zespół projektowy powinien przejrzeć zakres programu, szacunki kosztów, harmonogram (w tym ocenę ścieżki krytycznej), dojrzałość techniczną, kluczowe parametry wydajności, wyzwania wydajności, oczekiwania interesariuszy vs.aktualny plan, zewnętrzne i wewnętrzne zależności, wyzwania wdrożeniowe, integracja, interoperacyjność, wsparcie, podatności łańcucha dostaw, zdolność do radzenia sobie z zagrożeniami, odchylenia kosztów, oczekiwania dotyczące zdarzeń testowych, bezpieczeństwo, ochrona i inne. Ponadto Dane historyczne z podobnych projektów, wywiady z interesariuszami i listy ryzyka zapewniają cenny wgląd w obszary do rozważenia ryzyka.
identyfikacja ryzyka jest procesem iteracyjnym. W miarę postępu programu, więcej informacji będzie można uzyskać na temat programu (np konkretnego projektu), a Oświadczenie o ryzyku będzie dostosowane do odzwierciedlenia obecnego zrozumienia. Nowe zagrożenia będą identyfikowane w miarę postępów projektu w cyklu życia.
najlepsze praktyki i wyciągnięte wnioski
ryzyko operacyjne. Zapoznaj się z operacyjnym charakterem wspieranych przez Ciebie funkcji oraz z ryzykiem dla użytkowników końcowych, ich misji i operacji związanych z tymi funkcjami. Zrozumienie potrzeb operacyjnych/misji (zobacz temat rozwoju koncepcji w Przewodniku Inżynierii Systemów) pomoże Ci docenić wagę ryzyka i wpływ, jaki mogą one mieć na użytkowników końcowych. Jest to kluczowa część analizy ryzyka-uświadomienie sobie rzeczywistego wpływu, który może wystąpić w przypadku wystąpienia ryzyka podczas użytkowania operacyjnego. Zazwyczaj użytkownicy operacyjni są gotowi zaakceptować pewien poziom ryzyka, jeśli są w stanie wykonać swoją misję (np. zapewnienie misji), ale musisz pomóc użytkownikom zrozumieć ryzyko, które akceptują i ocenić dostępne opcje, salda i alternatywy.
dojrzałość techniczna. Współpracuj z przemysłem i środowiskiem akademickim, aby zrozumieć technologie, które są brane pod uwagę, i prawdopodobne Przejście technologii w czasie. Jednym z podejść jest współpraca z dostawcami w ramach umowy o Zachowaniu Poufności, aby zrozumieć możliwości i dokąd zmierzają, aby można było ocenić ryzyko.
NDI obejmuje artykuły komercyjne i rządowe. Aby zarządzać ryzykiem, należy wziąć pod uwagę rentowność dostawcy NDI. Czy dostawca ma udział w rynku? Czy dostawca ma odpowiednią długowieczność w porównaniu do swoich konkurentów? W jaki sposób dostawca rozwiązuje problemy z możliwościami i poprawkami wydań itp.? Jaka jest baza użytkowników dla konkretnego NDI? Czy dostawca może zademonstrować NDI, najlepiej w warunkach podobnych do ustawień klienta? Czy rząd może wykorzystać NDI do stworzenia prototypu? Wszystkie te czynniki pomogą ocenić ryzyko rentowności NDI i dostawcy. Poszukaj odpowiedzi na te pytania od innych pracowników MITRE, którzy pracowali w danym obszarze lub korzystali z ocenianej NDI.
Podkreśl krytyczne zdolności, szczególnie te, które mają ograniczone alternatywy. Ocena i określenie głównych czynników napędzających przejęcie oraz podkreślenie związanego z nimi ryzyka w formułowaniu zaleceń dotyczących ograniczania ryzyka. Jeżeli konkretny aspekt zdolności nie jest kluczowy dla jej sukcesu, należy ocenić jej ryzyko, ale nie musi ono być głównym celem zarządzania ryzykiem. Na przykład, jeśli istnieje ryzyko dla proponowanego interfejsu użytkownika, ale rynek ma wiele alternatyw, sukces proponowanego podejścia jest prawdopodobnie mniej krytyczny dla ogólnego sukcesu zdolności. Z drugiej strony funkcja bezpieczeństwa informacji może mieć kluczowe znaczenie. Jeśli tylko jedno alternatywne podejście zaspokaja tę potrzebę, należy położyć na nią nacisk. Określ podstawowe czynniki sukcesu, oceniając potrzeby i projekty oraz określając alternatywy, które istnieją. Czy unikalne rozwiązanie jest na krytycznej drodze do sukcesu? Upewnij się, że analizy ścieżki krytycznej obejmują cały cykl inżynierii systemowej, a nie tylko rozwój (tj. rozwój systemu jako taki może być „bułką z masłem”, ale znalezienie się w aktywnej sytuacji operacyjnej może być poważnym ryzykiem).
wykorzystaj ewolucję zdolności do zarządzania ryzykiem. Jeśli szczególne wymagania napędzają wdrażanie możliwości, które są wysokie ryzyko ze względu na unikalny rozwój, potrzeby wydajności edge-of-the-envelope, itp., wymagania powinny być omówione z użytkownikami dla ich krytyczności. Może być tak, że potrzeba może zostać odroczona, a społeczność rozwojowa powinna ocenić, kiedy może być zaspokojona w przyszłości. Pomóż użytkownikom i programistom ocenić, ile ryzyka (oraz wpływu na harmonogram i koszty) dana zdolność powinna przyjąć w stosunku do wymagań, aby wcześniej uzyskać mniej ryzykowne możliwości. Opracowując rekomendacje, weź pod uwagę techniczną wykonalność i wiedzę na temat związanych z nimi sukcesów i niepowodzeń wdrożeniowych, aby ocenić ryzyko wdrożenia teraz, a nie w przyszłości. Odkładając możliwości, uważaj, aby nie wpaść w pułapkę odkładania ostatecznej porażki przez handel łatwymi sukcesami na przyszłość z wieloma wymaganiami wysokiego ryzyka, które mogą być niezbędne do ogólnego sukcesu.
Kluczowe Parametry Wydajności (KPPs). Ściśle współpracuj z użytkownikami w celu utworzenia KPP. Ogólne ryzyko anulowania programu może być skoncentrowane na niezastosowaniu się do KPPs. Współpracuj z użytkownikami, aby upewnić się, że parametry są dostosowane do potrzeb misji i technicznie wykonalne. Parametry NIE POWINNY być tak pobłażliwe, że można je łatwo spełnić, ale nie powinny spełniać potrzeb misji; nie powinny być również tak rygorystyczne, że nie mogą być spełnione bez dużego wysiłku lub popychania technologiiktóre mogą narazić program na niebezpieczeństwo. Szukaj wyników przeszłych operacji, eksperymentów, ocen wydajności i wdrożeń branżowych, aby pomóc określić wykonalność wydajności.
zależności zewnętrzne i wewnętrzne. Perspektywa korporacyjna może pomóc nabywcom, menedżerom programów, programistom, integratorom i użytkownikom docenić ryzyko wynikające z zależności od wysiłku programistycznego. Wraz z pojawieniem się podejścia zorientowanego na usługi, program stanie się bardziej zależny od dostępności i działania usług świadczonych przez innych, które zamierzają wykorzystać w wysiłkach rozwojowych programu. Współpraca z twórcami usług w celu zapewnienia jakości usług są tworzone, i przemyślano utrzymanie i rozwój tych usług. Współpracuj z personelem programu rozwoju, aby ocenić dostępne usługi, ich jakość i ryzyko związane z korzystaniem z usługi i poleganiem na niej. Podobnie istnieje ryzyko związane z tworzeniem usługi i nie korzystaniem z usług z innego wysiłku przedsiębiorstwa. Pomóż określić ryzyko i potencjalne korzyści związane z tworzeniem usługi wewnętrznej dla rozwoju z ewentualnym przejściem do usługi korporacyjnej w przyszłości.
integracja i interoperacyjność (I & I). I&prawie zawsze będę głównym czynnikiem ryzyka. Są to formy zależności, w których wartość integracji lub interoperacyjności została oceniona jako nadrzędna wobec ich nieodłącznego ryzyka. Techniki takie jak architektura Federacji przedsiębiorstw, komponowalne możliwości na żądanie i wzorce projektowe mogą pomóc rządowi zaplanować i wykonać trasę do nawigacji I&I ryzyka. Zapoznaj się z sekcją Enterprise Engineering w Przewodniku Inżynierii Systemów, aby uzyskać artykuły na temat technik rozwiązywania I&i związanych z ryzykiem.
bezpieczeństwo informacji. Bezpieczeństwo informacji jest Zagrożeniem w prawie każdym rozwoju. Niektóre z nich wynikają z wyjątkowości potrzeb i wymagań rządu w tej dziedzinie. Niektóre z nich wynikają z nieodłącznych trudności w przeciwdziałaniu cyberatakom. Tworzenie zdolności obronnych w celu pokrycia spektrum ataków jest trudne i ryzykowne. Pomoc rządowi w opracowaniu podejścia do odporności (np. plany awaryjne, backup / recovery, itp.). Umożliwienie wymiany informacji między systemami w ramach operacji koalicyjnych z międzynarodowymi partnerami stwarza wyzwania techniczne i kwestie polityczne, które przekładają się na ryzyko rozwoju. Kwestie bezpieczeństwa informacji związane z zarządzaniem łańcuchem dostaw są tak szerokie i złożone, że nawet utrzymanie podstawowej świadomości zagrożeń jest ogromnym wyzwaniem.
Poziom umiejętności. Poziom umiejętności lub doświadczenia deweloperów, integratorów, rządu i innych interesariuszy może prowadzić do ryzyka. Uważaj na niewystarczające umiejętności i sięgnij po całą korporację, aby wypełnić wszelkie luki. W ten sposób, pomóc edukować członków zespołu rządowego w tym samym czasie są przynosząc umiejętności korporacyjnych i doświadczenie do niedźwiedzia.
Programy zazwyczaj tworzą kosztorys rządowy uwzględniający ryzyko. Wraz z rozwojem i udoskonalaniem ryzyka technicznego i innych zagrożeń programu, należy również ewoluować związane z nim szacunki kosztów. Kosztorysowanie nie jest czynnością jednorazową.
informacje historyczne jako przewodnik do identyfikacji ryzyka. Informacje historyczne z podobnych programów rządowych mogą zapewnić cenny wgląd w przyszłe zagrożenia. Szukaj informacji na temat wyzwań operacyjnych i zagrożeń w różnych wyciągniętych wnioskach operacyjnych, po raportach z działań, podsumowaniach ćwiczeń i wynikach eksperymentów. Klienci często mają do nich dostęp. Przywódcy rządowi Zwykle komunikują swoje strategiczne potrzeby i wyzwania. Zrozumieć i uwzględnić je w ocenie najważniejszych możliwości potrzebnych Klientowi oraz jako podstawę do oceny ryzyka.
Dane historyczne pomocne w ocenie ryzyka są często dostępne na podstawie przeszłych ocen wydajności i wniosków wyciągniętych z programów akwizycji i wykonawców. W wielu przypadkach pracownicy MITRE pomogą rządowi w przygotowaniu informacji o wydajności dla konkretnego nabycia. AF zawiera przewodnik oceny wyników z przeszłości (PPEG), który określa typ informacji do przechwycenia, które mogą być wykorzystane do przyszłych wyborów źródeł rządowych . To repozytorium informacji może pomóc w dostarczeniu podstawowych informacji o poprzednich wyzwaniach i miejscach, w których mogą się one pojawićzarówno dla konkretnego rodzaju działalności deweloperskiej, jak i dla poszczególnych wykonawców.
istnieje wiele ocen technicznych produktów Dostawców, które można uzyskać w celu określenia ryzyka i żywotności różnych produktów. Jednym z repozytoriów ocen narzędzi jest dział narzędzi analitycznych, który zawiera wskazówki i doświadczenia z narzędziami analitycznymi. Korzystanie z takich zasobów i poszukiwanie innych, którzy próbowali produktów i technik w prototypach i eksperymentach może pomóc w ocenie ryzyka dla określonego wysiłku.
Jak napisać ryzyko-najlepsza praktyka . Najlepszym protokołem do pisania Oświadczenia o ryzyku jest Condition-If-Then construct. Protokół ten dotyczy procesów zarządzania ryzykiem zaprojektowanych dla niemal każdego środowiska. Jest to uznanie, że ryzyko, ze swej natury, jest probabilistyczne i takie, które, jeśli wystąpi, ma niepożądane konsekwencje.
jaki jest warunek-if-then construct? Warunek ten odzwierciedla to, co jest znane dzisiaj. Jest to główna przyczyna zidentyfikowanego zdarzenia ryzyka. Tak więc warunek jest zdarzeniem, które miało miejsce, obecnie występuje lub nastąpi z pewnością. Zdarzenia ryzyka są przyszłymi zdarzeniami, które mogą wystąpić z powodu obecnego stanu. Poniżej znajduje się ilustracja tego protokołu.
If jest zdarzeniem ryzyka związanym z obecnym stanem. Niezwykle ważne jest, aby uznać, czy i warunek jako podwójny. W przypadku wspólnego badania mogą istnieć sposoby bezpośredniej interwencji lub naprawienia podstawowego korzenia (warunku) zdarzenia ryzyka, tak aby konsekwencje tego zdarzenia, jeśli wystąpi, nie zagrażały już projektowi. If jest probabilistyczną częścią Oświadczenia o ryzyku.
następnie jest konsekwencją lub zestawem konsekwencji, które będą miały wpływ na projekt systemu inżynieryjnego, jeśli wystąpi zdarzenie ryzyka. Przykład konstrukcji warunku-jeśli – to ilustruje rysunek 2.
zachęca Zespoły do identyfikacji ryzyka. Kultura w niektórych projektach i programach rządowych zniechęca do identyfikacji zagrożeń. Może to wynikać z faktu, że działania związane z zarządzaniem ryzykiem polegające na śledzeniu, monitorowaniu i ograniczaniu ryzyka są postrzegane jako uciążliwe i nieprzydatne. W tej sytuacji przydatne może być porozmawianie z zespołami o korzyściach płynących z identyfikacji zagrożeń i niemożności zarządzania tym wszystkim w głowach (np., określenie priorytetu, kto musi być zaangażowany, działania łagodzące). Pomagaj zespołom rządowym w realizacji procesu, który równoważy inwestycje menedżerskie z wartością w stosunku do wyników projektu. Ogólnie rzecz biorąc, dobra równowaga jest osiągana, gdy zakres projektu, harmonogram i cele kosztowe są osiągane lub skutecznie ograniczane przez plany działania, a zespół projektowy uważa, że działania związane z zarządzaniem ryzykiem zapewniają wartość projektu. Reprezentacja między zespołami jest koniecznością; ryzyko nie powinno być identyfikowane przez osobę fizyczną lub wyłącznie przez zespół inżynierów systemów (przegląd źródeł ryzyka powyżej).
weź pod uwagę czynniki organizacyjne i środowiskowe. Czynniki organizacyjne, kulturowe, polityczne i inne czynniki środowiskowe, takie jak wsparcie zainteresowanych stron lub priorytety organizacyjne, mogą stanowić takie samo lub większe ryzyko dla projektu niż same czynniki techniczne. Ryzyko to powinno być identyfikowane i aktywnie ograniczane przez cały okres trwania projektu. Działania łagodzące mogą obejmować monitorowanie mandatów legislacyjnych lub nadzwyczajnych zmian, które mogą mieć wpływ na misję programu lub projektu, zmiany organizacyjne, które mogą mieć wpływ na wymagania użytkowników lub przydatność funkcji, lub zmiany wsparcia politycznego, które mogą mieć wpływ na finansowanie. W każdym przypadku należy rozważyć ryzyko dla programu i określić opcje działań do dyskusji z zainteresowanymi stronami. Dodatkowe informacje można znaleźć w artykule planowanie, wdrażanie i monitorowanie postępów w ograniczaniu ryzyka.
Uwzględnij interesariuszy w identyfikacji ryzyka. Projekty i programy zwykle mają wielu interesariuszy, którzy przynoszą różne wymiary ryzyka do wyników. Należą do nich operatorzy, którzy mogą być przytłoczeni nowymi systemami; użytkownicy, którzy mogą nie być odpowiednio przeszkoleni lub obawiają się o swoją pracę; organy nadzoru, które mogą nie wspierać nowej zdolności, ponieważ wydaje się, że zmniejsza to ich autorytet; oraz decydenci, którzy są zaniepokojeni zatwierdzaniem przepisów i kosztami. Ponadto ważne jest, aby uwzględnić wszystkie zainteresowane strony, takie jak organy certyfikacji i akredytacji, które, jeśli nieumyślnie przeoczone, mogą stanowić poważne ryzyko w późniejszym okresie programu. Interesariusze mogą być świadomi różnych czynników środowiskowych, takich jak oczekujące na przyjęcie przepisów lub wsparcie programów politycznych, które mogą stanowić zagrożenie dla projektu, który jest nieznany rządowi lub zespołowi projektowemu MITRE. Włączenie zainteresowanych stron w proces identyfikacji ryzyka, aby pomóc w ujawnieniu tych zagrożeń.
napisz wyraźne oświadczenie o ryzyku. Korzystanie z formatu Condition-If-Then pomaga komunikować się i oceniać Oświadczenie o ryzyku oraz opracowywać strategię ograniczania ryzyka. Główną przyczyną jest podstawowy warunek, który wprowadził ryzyko (na przykład, podejście projektowe może być przyczyną), If odzwierciedla Prawdopodobieństwo (na przykład, ocena prawdopodobieństwa, że jeśli część Oświadczenia o ryzyku miały wystąpić), a następnie komunikuje wpływ na program (na przykład, zwiększone zasoby do wspierania testowania, dodatkowy harmonogram, i troska, aby spełnić wydajność). Strategia łagodzenia skutków jest prawie zawsze lepsza, gdy opiera się na jasno sformułowanym oświadczeniu o ryzyku.
spodziewaj się modyfikacji Oświadczenia o ryzyku w miarę opracowywania strategii oceny i ograniczania ryzyka. Często zdarza się, że Oświadczenia o ryzyku są dopracowane, gdy zespół ocenia wpływ. Podczas oceny i dokumentowania potencjalnego wpływu ryzyka (koszt, harmonogram, techniczne lub ramy czasowe) zrozumienie i Oświadczenie o ryzyku mogą ulec zmianie. Na przykład, podczas oceny wpływu na ryzyko poślizgu harmonogramu oprogramowania, Oświadczenie o ryzyku może zostać udoskonalone, aby uwzględnić datę potrzeb i / lub dalsze wyjaśnienie wpływu (np. jeśli oprogramowanie xyz nie zostanie dostarczone do marca 2015 r., nie będzie wystarczająco dużo czasu na przetestowanie wymiany interfejsów przed ograniczonym testem użytkownika).
Nie uwzględniaj Oświadczenia o ograniczeniu ryzyka w oświadczeniu o ryzyku. Należy uważać, aby nie wpaść w pułapkę o oświadczenie łagodzenia wprowadzone do Oświadczenia o ryzyku. Ryzyko to niepewność o potencjalnym negatywnym wpływie. Niektórzy szybko dochodzą do wniosku o ograniczenie ryzyka i zamiast identyfikować ryzyko, które należy ograniczyć (po zidentyfikowaniu opcji ograniczenia), identyfikują ryzyko jako nieoptymalne podejście projektowe. Na przykład Oświadczenie o ryzyku może brzmieć: jeśli wykonawca nie użyje XYZ do testu, test zakończy się niepowodzeniem. Problemem jest naprawdę wystarczająca próba. Jeśli wykonawca nie przeprowadzi testu z wymiernymi wynikami do analizy, program nie może przejść testu ograniczonego użytkownika. Stosowanie XYZ może być opcją łagodzącą w celu zmniejszenia ryzyka wystarczalności testu.
nie przeskakuj do strategii łagodzenia przed oceną prawdopodobieństwa ryzyka i wpływu. Ryzyko może zostać udoskonalone lub zmienione w wyniku dalszej analizy, co może mieć wpływ na to, jakie może być najbardziej skuteczne/pożądane ograniczenie. Inżynierowie często przeskakują do rozwiązania; najlepiej jest przejść do następnego kroku omówionego w artykule Ocena wpływu ryzyka i ustalanie priorytetów, aby najpierw rozłożyć i zrozumieć problem. Ostatecznie doprowadzi to do opracowania strategii, która będzie ściśle powiązana z tym problemem.
Referencje & zasoby
- MITRE Institute, 1 września 2007, MITRE Systems Engineering (SE) Competency Model, Version 1, PP.10, 40-41.
- Garvey, P. R., 2008, Analytical Methods for Risk Management: A Systems Engineering Perspective, Chapman-Hall / CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.US Air Force, January 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
- US Air Force, styczeń 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
dodatkowe referencje & zasoby
MITRE E520 Analiza ryzyka i zarządzanie zespół techniczny listy kontrolne, kontrole ryzyka, Analiza ryzyka i dokumenty zarządcze.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK Guide), Fourth Edition, ANSI/PMI 99-001-2008, S. 273-312, accessed March 2, 2010.
SEPO, „Standard Process / Steps of Process, Step 2: Identify Risks & Hazards,” MITRE SEPO Risk Management Toolkit, accessed May 5, 2010.
