Definice: identifikace Rizik je proces určení rizika, které by mohly potenciálně zabránit programu, podnikání, nebo investice z dosahování jeho cílů. Zahrnuje dokumentaci a komunikaci koncernu.
Klíčová slova: riziko, identifikace rizik, řízení rizik
MITRE SE Role & Očekávání: MITRE systémy inženýrů (SEs) práce na vládních programů se očekává, že k identifikaci rizik, která by mohla ovlivnit projekt a program. Očekává se, že budou psát a přezkoumávat prohlášení o rizicích, která jsou jasná, jednoznačná a podložená důkazy .
pozadí
identifikace rizika je kritickým prvním krokem procesu řízení rizik znázorněného na obrázku 1.
cílem identifikace rizik je včasné a kontinuální identifikaci událostí, které pokud nastanou, budou mít negativní dopad na schopnost projektu dosáhnout výkonu nebo schopnosti výsledku cílů. Mohou pocházet z projektu nebo z externích zdrojů.
Existuje několik typů rizik, včetně programu hodnocení rizik, hodnocení rizik na podporu investičního rozhodování, analýzu alternativ a posouzení provozních nebo nákladů nejistoty. Identifikace rizik musí odpovídat typu hodnocení potřebnému k podpoře rozhodování informovaného o riziku. Pro akviziční program je prvním krokem identifikace cílů a cílů programu, čímž se podpoří společné pochopení toho, co je potřeba pro úspěch programu. To dává kontext a omezuje rozsah, podle kterého jsou rizika identifikována a hodnocena.
identifikace rizik v programu systémového inženýrství
existuje více zdrojů rizika. Pro identifikaci rizik, projektový tým by měl recenzi programu rozsah, odhady nákladů, plán (včetně hodnocení kritické cesty), technické vyspělosti, klíčové výkonnostní parametry, výkon výzvy, zúčastněných stran očekávání vs. současná plánu, vnější a vnitřní závislosti, provádění výzvy, integrace, interoperability, podpory, dodavatelského řetězce zranitelnosti, schopnost zvládat hrozby, nákladů, odchylky, test událost, očekávání, bezpečnost, zabezpečení, a další. Kromě toho Historická data z podobných projektů, rozhovory se zúčastněnými stranami a seznamy rizik poskytují cenný vhled do oblastí pro zvážení rizika.
identifikace rizika je iterativní proces. Jak program postupuje, budou získány další informace o programu (např konkrétní návrh), a prohlášení o riziku budou upraveny tak, aby odrážely současné chápání. Nová rizika budou identifikována v průběhu celého životního cyklu projektu.
osvědčené postupy a poučení
operační riziko. Pochopte provozní povahu schopností, které podporujete, a riziko pro koncové uživatele, jejich mise, a jejich provoz schopností. Pochopení operativní potřeby/mise (viz Koncepce Rozvoje tématu Systémy Inženýrství Průvodce), vám pomůže ocenit závažnost rizika a dopad by mohly mít pro koncové uživatele. Toto je kritická část analýzy rizikrealizace real-svět dopad, který může nastat, pokud riziko vzniká během provozu. Typicky provozní uživatelé jsou ochotni přijmout určité úrovni rizika, pokud jsou schopni splnit jejich poslání (např. mise jistotu), ale budete muset pomoci uživatelům pochopit rizika jsou přijmout a posoudit možnosti, zůstatky, a alternativy k dispozici.
technická vyspělost. Pracujte s průmyslem a akademickou obcí a využívejte je k pochopení technologií, které jsou zvažovány pro úsilí a pravděpodobný přechod technologie v průběhu času. Jedním z přístupů je spolupráce s dodavateli na základě dohody o mlčenlivosti, abychom pochopili možnosti a kam směřují, aby bylo možné riziko posoudit.
Non-vývojové položky (NDI). NDI zahrnuje komerční-off-the-shelf a vládní-off-the-shelf položky. Pro řízení rizika zvažte životaschopnost poskytovatele NDI. Má poskytovatel podíl na trhu? Má poskytovatel odpovídající životnost ve srovnání se svými konkurenty? Jak poskytovatel řeší problémy se schopností a opravy vydání, atd.? Jaká je uživatelská základna pro konkrétní NDI? Může poskytovatel prokázat NDI, nejlépe v prostředí podobném nastavení vašeho zákazníka? Může vláda použít NDI k vytvoření prototypu? Všechny tyto faktory pomohou posoudit riziko životaschopnosti NDI a poskytovatele. Hledejte odpovědi na tyto otázky od jiných zaměstnanců MITRE, kteří pracovali v oblasti nebo použili posuzovaný NDI.
akviziční ovladače. Zdůrazněte aktivátory kritických schopností, zejména ty, které mají omezené alternativy. Vyhodnoťte a určete primární hnací síly akvizice a zdůrazněte jejich související riziko při formulování doporučení ke zmírnění rizik. Pokud určitý aspekt schopnosti není rozhodující pro její úspěch, mělo by být posouzeno její riziko, ale nemusí být primárním cílem řízení rizik. Například, pokud existuje riziko pro navrhované uživatelské rozhraní, ale trh má řadu alternativ, úspěch navrhovaného přístupu je pravděpodobně méně kritický pro celkový úspěch schopnosti. Na druhou stranu je pravděpodobné, že funkce zabezpečení informací bude kritická. Pokud pouze jeden alternativní přístup uspokojí potřebu, je třeba na něj klást důraz. Určete primární ovladače úspěchu vyhodnocením potřeb a návrhů a určením alternativ, které existují. Je jedinečné řešení na kritické cestě k úspěchu? Ujistěte se, že kritická cesta analýzy zahrnují celou systémové inženýrství cyklus a ne jen vývoj (tj. vývoj systému, sama o sobě, může být „kus koláče“, ale fielding v aktivní provozní situace může být významné riziko).
použijte vývoj schopností k řízení rizika. Pokud jsou konkrétní požadavky hnací silou implementace schopností, které jsou vysoce rizikové kvůli jedinečnému vývoji, požadavky na výkon na okraji obálky atd., požadavky by měly být projednány s uživateli pro jejich kritičnost. Je možné, že by tato potřeba mohla být odložena a rozvojová komunita by měla posoudit, kdy by mohla být v budoucnu uspokojena. Pomoci uživatelům a vývojářům odhadnout, jak velké riziko (a plán nákladů a dopadu) zvláštní schopnost by měla předpokládat, že proti požadavků přijímat méně riskantní možnosti dříve. Při vývoji vašich doporučení zvažte technickou proveditelnost a znalosti souvisejících implementačních úspěchů a neúspěchů, abyste posoudili riziko implementace nyní místo budoucnosti. V odložením schopnosti, dávejte pozor, abyste spadnout do pasti odkládání konečné selhání tím, že obchodování v blízkosti horizontu snadné úspěchy na budoucnost více vysoce rizikových požadavků, které mohou být zásadní pro celkový úspěch.
Klíčové Parametry Výkonu (KPPs). Úzce spolupracujte s uživateli na vytvoření kpps. Celkové riziko zrušení programu může být soustředěno na nesplnění KPPs. Spolupracujte s uživateli, abyste zajistili, že parametry odpovídají potřebám mise a jsou technicky proveditelné. Parametry by neměly být tak shovívavý, že mohou snadno být splněny, ale ani splnění mise potřeba; ani by neměly být tak přísné, že nemohou být splněny bez rozsáhlé úsilí, nebo tlačí technologiebuď z které můžete dát program v ohrožení. Vyhledejte výsledky minulých operací, experimenty, hodnocení výkonu, a implementace průmyslu, které pomohou určit proveditelnost výkonu.
externí a interní závislosti. Podniková perspektiva může pomoci nabyvatelům, programovým manažerům, vývojářům, integrátorům a uživatelům ocenit rizika vyplývající ze závislostí vývojového úsilí. Se vznikem přístupů orientovaných na služby bude program více závislý na dostupnosti a provozu služeb poskytovaných ostatními, které hodlají využít v rozvojovém úsilí svého programu. Spolupracujte s vývojáři služeb, abyste zajistili vytváření kvalitních služeb, a myšlenka byla vložena do údržby a vývoje těchto služeb. Spolupracujte s pracovníky vývojového programu na posouzení dostupných služeb, jejich kvalita, a riziko, které má program při používání služby a spoléhání se na ni. Stejně tak existuje riziko spojené s vytvořením služby a nepoužíváním služeb z jiného podnikového úsilí. Pomozte určit rizika a potenciální přínosy vytvoření služby interní pro vývoj s případným přechodem na podnikovou službu v budoucnu.
integrace a interoperabilita (I&I). I&budu téměř vždy hlavním rizikovým faktorem. Jsou to formy závislostí, v níž hodnota integraci nebo spolupráci byl souzen pro potlačení rizika s nimi spojená. Techniky, jako je enterprise federation architecting, skládatelné schopnosti na vyžádání a designové vzory, mohou pomoci vládnímu plánu a provést trasu pro navigaci i&I rizika. Články o technikách řešení i&i související rizika naleznete v části podnikové inženýrství příručky systémového inženýrství.
bezpečnost informací. Informační bezpečnost je rizikem téměř v každém vývoji. Některé z nich jsou způsobeny jedinečností vládních potřeb a požadavků v této oblasti. Některé z nich jsou způsobeny inherentními obtížemi v boji proti kybernetickým útokům. Vytváření obranných schopností pro pokrytí spektra útoků je náročné a riskantní. Pomozte vládě rozvíjet přístupy odolnosti(např. pohotovostní plány, zálohování / zotavení atd.). Umožnění sdílení informací napříč systémy v koaličních operacích s mezinárodními partnery představuje technické výzvy a politické problémy, které se promítají do rizika rozvoje. Otázky informační bezpečnosti spojené s řízením dodavatelského řetězce jsou tak široké a složité, že i udržení základního povědomí o hrozbách je obrovskou výzvou.
úroveň dovedností. Úroveň dovedností nebo zkušeností vývojářů, integrátorů, vlády a dalších zúčastněných stran může vést k rizikům. Dávejte pozor na nedostatečné dovednosti a oslovte celou společnost, abyste vyplnili mezery. Přitom, pomozte vzdělávat členy vládního týmu a zároveň přinášíte firemní dovednosti a zkušenosti.
nákladová rizika. Programy obvykle vytvoří vládní odhad nákladů, který zohlední riziko. Při vývoji a zdokonalování technických a dalších rizik programu by se měly vyvíjet také související odhady nákladů. Odhad nákladů není jednorázová činnost.
historické informace jako vodítko k identifikaci rizik. Historické informace z podobných vládních programů mohou poskytnout cenný vhled do budoucích rizik. Vyhledejte informace o provozních výzvách a rizicích v různých provozních lekcích, po akčních zprávách, shrnutí cvičení, a výsledky experimentů. Zákazníci mají často k dispozici úložiště. Vládní představitelé obvykle sdělí své strategické potřeby a výzvy. Pochopit a faktor do hodnocení nejdůležitější schopnosti potřebné pro vašeho zákazníka, a jako základ pro hodnocení rizik.
historické údaje, které pomáhají posoudit riziko, jsou často k dispozici z minulých hodnocení výkonnosti a poučení z akvizičních programů a dodavatelů. V mnoha případech budou zaměstnanci MITRE pomáhat vládě při přípravě informací o výkonu pro konkrétní akvizici. AF má Past Performance Evaluation Guide (PPEG), který identifikuje typ informací k zachycení, které lze použít pro budoucí výběr vládních zdrojů . Toto úložiště informací může pomoci poskytnout základní informace z předchozí výzvy, a kde by mohly vzniknout znovujak pro konkrétní typ rozvoje činnosti, stejně jako s konkrétní dodavatele.
existuje řada technických hodnocení produktů dodavatele, ke kterým lze přistupovat, aby bylo možné určit riziko a životaschopnost různých produktů. Jedním z úložišť hodnocení nástrojů je analytický nástroj, který obsahuje pokyny a zkušenosti s analytickými nástroji. Použití zdrojů, jako jsou tyto, a hledání dalších, kteří vyzkoušeli produkty a techniky v prototypech a experimentech, může pomoci posoudit rizika pro konkrétní úsilí.
Jak napsat riziko-nejlepší praxe . Osvědčený protokol pro psaní prohlášení o riziku je stav-pokud-pak konstrukt. Tento protokol se vztahuje na procesy řízení rizik navržené pro téměř jakékoli prostředí. Je to uznání, že riziko je svou povahou pravděpodobnostní a riziko, pokud k němu dojde, má nežádoucí důsledky.
jaká je podmínka-pokud-pak konstruovat? Stav odráží to, co je dnes známo. Je hlavní příčinou zjištěné rizikové události. Podmínkou je tedy událost, která nastala, v současné době se vyskytuje nebo nastane s jistotou. Rizikové události jsou budoucí události, které mohou nastat kvůli přítomnému stavu. Níže je ilustrace tohoto protokolu.
If je riziková událost spojená s přítomným stavem. Je kriticky důležité rozpoznat If a podmínku jako duální. Když zkoumány společně, může být způsoby, jak přímo zasáhnout nebo lék riziková událost je základní kořen (Podmínka) takové, že důsledky z této akce, pokud k ní dojde, již ohrožují projekt. If je pravděpodobnostní část prohlášení o riziku.
pak je důsledek nebo soubor důsledků, které ovlivní projekt inženýrského systému, pokud dojde k rizikové události. Příklad konstrukce podmínky-Pokud-Pak je znázorněn na obrázku 2.
povzbudit týmy k identifikaci rizik. Kultura v některých vládních projektech a programech odrazuje od identifikace rizik. To může nastat, protože činnosti řízení rizik spojené se sledováním, monitorováním a zmírňováním rizik jsou považovány za zatěžující a neužitečné. V této situaci může být užitečné hovořit s týmy o výhodách identifikace rizik a neschopnosti vše zvládnout ve vašich hlavách (např., určit prioritu, kdo musí být zapojen, zmírňující akce). Pomozte vládním týmům při provádění procesu, který vyvažuje investice do řízení s hodnotou výsledků projektu. Obecně je dosaženo dobré rovnováhy, když jsou akční plány splněny nebo úspěšně zmírněny cíle projektu, harmonogram a náklady, a projektový tým věří, že činnosti řízení rizik poskytují projektu hodnotu. Cross-týmu reprezentace je nutností; rizika by neměla být identifikovány individuální, nebo přesně podle systémy technický tým (hodnocení zdrojů rizika výše).
zvažte organizační a environmentální faktory. Organizační, kulturní, politické a jiné faktory životního prostředí, jako podporu zúčastněných stran nebo organizační priority, může představovat stejně nebo více rizik projektu, než technické faktory sám. Tato rizika by měla být identifikována a aktivně zmírňována po celou dobu trvání projektu. Zmírňující činnosti by mohly zahrnovat sledování legislativních mandátů nebo mimořádných změn, které by mohly ovlivnit misi programu nebo projektu, organizační změny, které by mohly ovlivnit požadavky uživatelů nebo užitečnost schopností, nebo změny politické podpory, které by mohly ovlivnit financování. V každém případě zvažte riziko pro program a určete možnosti akce pro diskusi se zúčastněnými stranami. Další informace naleznete v článku plánování, provádění a sledování pokroku v oblasti zmírňování rizik.
zahrňte zúčastněné strany do identifikace rizik. Projekty a programy mají obvykle více zúčastněných stran, které přinášejí výsledky různým rozměrům rizika. Patří mezi ně operátory, kteří by mohli být zahlceni nových systémů; uživatelé, kteří nemusí být řádně vyškoleni a mají obavy o svá pracovní místa; nadřízení, kteří nemusí podporovat nové schopnosti, protože se zdá, snížit jejich orgánem a tvůrci politik, kteří se zabývají legislativní schválení a náklady. Kromě toho je důležité zahrnout všechny zúčastněné strany, jako jsou certifikační a akreditační orgány, které, pokud jsou neúmyslně přehlédnuty, mohou později v programu představovat velká rizika. Subjekty mohou být velmi dobře vědomi různých faktorů životního prostředí, jako do doby, než právní nebo politický program podporu, které mohou představovat riziko pro projekt, které jsou neznámé, aby vláda nebo MITRE projektového týmu. Zahrňte zúčastněné strany do procesu identifikace rizik, abyste pomohli těmto rizikům čelit.
napište jasná prohlášení o riziku. Použití formátu Condition-If-Then pomáhá komunikovat a vyhodnocovat prohlášení o riziku a rozvíjet strategii zmírňování. Příčinou je základní onemocnění, které zavedla riziko (např. koncepce, co by mohlo být příčinou), Pokud odráží pravděpodobnost (např. posouzení pravděpodobnosti, že Pokud část rizika, prohlášení mělo dojít), a Pak komunikuje vliv, aby program (např. zvýšení zdrojů na podporu testování, další plán, a obavy, aby splňovaly výkon). Strategie zmírňování je téměř vždy lepší, pokud je založena na jasně formulovaném prohlášení o riziku.
očekávejte změny výkazu rizika při vypracování strategie hodnocení a zmírňování rizik. Jakmile tým vyhodnotí dopad, je běžné upřesnit prohlášení o rizicích. Při posuzování a dokumentování možného dopadu rizika (náklady, harmonogram, technický nebo časový rámec) se může pochopení a prohlášení o riziku změnit. Například při posuzování rizika dopad software plánu proklouznout, riziko výpověď může být rafinované, aby zahrnovala třeba-podle data a/nebo další objasnění dopadu (například, pokud by xyz software není dodáno v Březnu 2015, pak tam nebude dostatek času na test rozhraní výměny před Omezený Uživatelský Test).
nezahrnujte prohlášení o zmírnění rizika do prohlášení o riziku. Dávejte pozor, abyste nespadli do pasti, že do prohlášení o riziku bylo zavedeno prohlášení o zmírnění. Riziko je nejistota s potenciálním negativním dopadem. Některé skočit rychle k závěru, zmírnění rizika, a místo určení riziko, že by měly být zmírněny (s možností zmírnění identifikovaných), identifikují rizika jako sub-optimální přístup k designu. Například, prohlášení o riziku může být: pokud dodavatel nepoužívá XYZ pro test, pak test selže. Problémem je opravdu dostatečnost testů. Pokud dodavatel neprovede test s měřitelnými výsledky pro analýzu, pak program nemusí projít omezeným uživatelským testem. Použití XYZ může být zmírňující možností ke snížení rizika dostatečnosti testu.
před posouzením pravděpodobnosti a dopadu rizika nepřecházejte na strategii zmírňování. Vzhledem k další analýze může být riziko upřesněno nebo změněno, což by mohlo ovlivnit to, jaké nejúčinnější / nejžádanější zmírnění může být. Inženýři často ukvapené řešení; to je nejlepší, aby se přesunout na další krok projednán v Riziku Posouzení Dopadů a stanovení Priorit článku rozložit a pochopit problém první. Nakonec to povede ke strategii, která je úzce spojena s obavami.
Odkazy & Zdroje
- MITRE Institut, září 1, 2007, MITRE Systems Engineering (SE) Kompetenční Model, Verze 1, s. 10, 40-41.
- Garvey, P. R., 2008, Analytické Metody pro Řízení Rizik: Systémy technického Hlediska, Chapman-Hall/CRC Press, Taylor & Francis Group (UK), Boca Raton, Londýn, New York, ISBN: 1584886374.US Air Force, leden 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
- US Air Force, leden 2008, Air Force Minulosti Performance Evaluation Guide (PPEG), IG5315.305(a).
Další Odkazy & Zdroje
MITRE E520 Analýzy Rizik a Řízení Technický Tým seznamy, Rizika, Kontroly, Analýza Rizik a Řízení Dokumentů.
Project Management Institute, Průvodce Project Management body of Knowledge, (PMBOK Guide), Čtvrté Vydání, ANSI/PMI 99-001-2008, s. 273-312, přístup Březen 2, 2010.
SEPO, „Standardní Postup/Kroky Procesu, Krok 2: Identifikovat Rizika & Nebezpečí,“ MITRE SEPO soubor Nástrojů pro Řízení Rizik, přístup 5. Května 2010.
