Definition: risikoidentifikation er processen med at bestemme risici, der potentielt kan forhindre programmet, virksomheden eller investeringen i at nå sine mål. Det inkluderer dokumentation og kommunikation af bekymringen.
nøgleord: risiko, risikoidentifikation, risikostyring
MITRE se roller & forventninger: MITRE systems engineers (SEs), der arbejder på offentlige programmer, forventes at identificere risici, der kan påvirke projektet og programmet. De forventes at skrive og gennemgå risikoerklæringer, der er klare, entydige og understøttet af beviser .
baggrund
risikoidentifikation er det kritiske første trin i risikostyringsprocessen afbildet i Figur 1.
målet med risikoidentifikation er den tidlige og kontinuerlige identifikation af begivenheder, der, hvis de opstår, vil have negativ indvirkning på projektets evne til at opnå resultater eller kapacitetsresultater. De kan komme fra projektet eller fra eksterne kilder.
der er flere typer risikovurderinger, herunder programrisikovurderinger, risikovurderinger til støtte for en investeringsbeslutning, analyse af alternativer og vurderinger af drifts-eller omkostningsusikkerhed. Risikoidentifikation skal matche den type vurdering, der kræves for at understøtte risikoinformeret beslutningstagning. For et erhvervelsesprogram er det første skridt at identificere programmets mål og målsætninger og dermed fremme en fælles forståelse på tværs af teamet af, hvad der er nødvendigt for programmets succes. Dette giver sammenhæng og grænser det omfang, hvormed risici identificeres og vurderes.
identificering af risici i Systemteknik-programmet
der er flere kilder til risiko. Til risikoidentifikation skal projektteamet gennemgå programomfanget, omkostningsestimater, tidsplan (for at inkludere evaluering af den kritiske vej), teknisk modenhed, nøglepræstationsparametre, ydeevneudfordringer, interessentforventninger vs. nuværende plan, eksterne og interne afhængigheder, implementeringsudfordringer, integration, interoperabilitet, supportbarhed, forsyningskædesårbarheder, evne til at håndtere trusler, omkostningsafvigelser, testhændelsesforventninger, sikkerhed, sikkerhed og mere. Derudover giver Historiske data fra lignende projekter, interessentsamtaler og risikolister værdifuld indsigt i områder til overvejelse af risiko.
risikoidentifikation er en iterativ proces. Efterhånden som programmet skrider frem, vil der blive opnået mere information om programmet (f.eks. specifikt design), og risikoerklæringen justeres for at afspejle den aktuelle forståelse. Nye risici vil blive identificeret, efterhånden som projektet skrider frem gennem livscyklussen.
bedste praksis og erfaringer
operationel risiko. Forstå den operationelle karakter af de kapaciteter, du støtter, og risikoen for slutbrugerne, deres missioner og deres drift af kapaciteterne. Forståelse af det operationelle behov / mission (se Konceptudviklingsemnet i Systemteknik-Guiden) hjælper dig med at forstå alvorligheden af risici og den indvirkning, de kan have for slutbrugerne. Dette er en kritisk del af risikoanalysenat realisere den virkelige påvirkning, der kan opstå, hvis der opstår en risiko under operationel brug. Typisk er operationelle brugere villige til at acceptere et vist risikoniveau, hvis de er i stand til at udføre deres mission (f.eks. mission assurance), men du skal hjælpe brugerne med at forstå de risici, de accepterer, og vurdere de tilgængelige muligheder, saldi og alternativer.
teknisk modenhed. Arbejde med og udnytte industrien og den akademiske verden til at forstå de teknologier, der overvejes for en indsats og den sandsynlige overgang af teknologien over tid. En tilgang er at arbejde med leverandører under en Fortrolighedsaftale for at forstå kapaciteterne og hvor de skal hen, så risikoen kan vurderes.
ikke-udviklingsmæssige elementer (NDI). NDI omfatter kommercielle-off-the-shelf og regering-off-the-shelf elementer. For at styre risikoen skal du overveje ndi-udbyderens levedygtighed. Har udbyderen markedsandel? Har udbyderen en passende levetid sammenlignet med sine konkurrenter? Hvordan løser udbyderen kapacitetsproblemer og frigiver rettelser osv.? Hvad er brugerbasen for den pågældende NDI? Kan udbyderen demonstrere NDI, helst i en indstilling, der ligner din kundes? Kan regeringen bruge NDI til at oprette en prototype? Alle disse faktorer vil hjælpe med at vurdere risikoen for levedygtigheden af NDI og udbyderen. Søg svar på disse spørgsmål fra andre MITRE-medarbejdere, der har arbejdet i området eller har brugt den ndi, der vurderes.
erhvervelse drivere. Fremhæv kritiske kapaciteter, især dem, der har begrænsede alternativer. Evaluere og bestemme de primære drivkræfter til en erhvervelse og understrege deres tilknyttede risiko ved formulering af risikoreducerende anbefalinger. Hvis et bestemt aspekt af en kapacitet ikke er kritisk for dens succes, bør dens risiko vurderes, men det behøver ikke at være det primære fokus for risikostyring. For eksempel, hvis der er risiko for en foreslået brugergrænseflade, men markedet har adskillige alternativer, er succesen med den foreslåede tilgang sandsynligvis mindre kritisk for kapacitetens samlede succes. På den anden side er en informationssikkerhedsfunktion sandsynligvis kritisk. Hvis kun en alternativ tilgang opfylder behovet, bør der lægges vægt på det. Bestem de primære succesdrivere ved at evaluere behov og design og bestemme de alternativer, der findes. Er en unik løsning på den kritiske vej til succes? Sørg for, at kritiske stianalyser inkluderer hele systemteknik-cyklussen og ikke kun udvikling (dvs.systemudvikling i sig selv kan være et “stykke kage”, men feltning i en aktiv driftssituation kan være en stor risiko).
brug kapacitetsudvikling til at styre risiko. Hvis særlige krav driver implementering af kapaciteter, der er høj risiko på grund af unik udvikling, ydelsesbehov på kanten af konvolutten osv., skal kravene drøftes med brugerne for deres kritik. Det kan være, at behovet kan udskydes, og udviklingssamfundet bør vurdere, hvornår det kan være tilfreds i fremtiden. Hjælp brugere og udviklere med at måle, hvor meget risiko (og planlægge og omkostningspåvirkning) en bestemt kapacitet skal påtage sig i forhold til kravene om at modtage mindre risikable kapaciteter hurtigere. Når du udvikler dine anbefalinger, skal du overveje teknisk gennemførlighed og viden om relaterede implementeringssucceser og fiaskoer for at vurdere risikoen for implementering nu i stedet for fremtiden. Ved udsættelse af kapaciteter skal du passe på ikke at falde i fælden med at udsætte den ultimative fiasko ved at handle på kort sigt lette succeser for en fremtid med flere højrisikokrav, der kan være afgørende for den samlede succes.
Key Performance Parameters (KPPs). Arbejd tæt sammen med brugerne for at etablere KPP ‘ er. Den samlede risiko for programaflysning kan være centreret om manglende opfyldelse af KPP ‘ er. Arbejd med brugerne for at sikre, at parametrene er lydhøre over for missionens behov og teknisk gennemførlige. Parametrene skal ikke være så lempelige, at de let kan opfyldes, men ikke imødekomme missionsbehovet; de skal heller ikke være så strenge, at de ikke kan opfyldes uden en omfattende indsats eller skubbe teknologisom begge kan sætte et program i fare. Søg Resultater af tidligere operationer, eksperimenter, præstationsvurderinger og industriimplementeringer for at hjælpe med at bestemme gennemførligheden af ydeevnen.
eksterne og interne afhængigheder. At have et virksomhedsperspektiv kan hjælpe erhververe, programledere, udviklere, integratorer og brugere med at sætte pris på risiko fra afhængigheder af en udviklingsindsats. Med fremkomsten af serviceorienterede tilgange vil et program blive mere afhængigt af tilgængeligheden og driften af tjenester leveret af andre, som de har til hensigt at bruge i deres programs udviklingsindsats. Arbejd med udviklerne af tjenester for at sikre, at der skabes kvalitetstjenester, og der er tænkt på vedligeholdelse og udvikling af disse tjenester. Arbejde med udviklingsprogrammet personale til at vurdere de tjenester, der er tilgængelige, deres kvalitet, og risikoen for, at et program har i at bruge og stole på tjenesten. Ligeledes er der en risiko forbundet med at oprette tjenesten og ikke bruge tjenester fra en anden virksomhedsindsats. Hjælp med at bestemme risiciene og de potentielle fordele ved at oprette en service internt i udviklingen med muligvis en overgang til virksomhedstjenesten på et senere tidspunkt.
Integration og interoperabilitet (i&I). Jeg& jeg vil næsten altid være en stor risikofaktor. De er former for afhængigheder, hvor værdien af at integrere eller interoperere er blevet vurderet til at tilsidesætte deres iboende risici. Teknikker som enterprise federation architecting, composable capabilities on demand og designmønstre kan hjælpe regeringen med at planlægge og udføre en rute for at navigere i i&i risici. Se afsnittet Enterprise Engineering I System Engineering Guide For artikler om teknikker til håndtering af i&i relaterede risici.
informationssikkerhed. Informationssikkerhed er en risiko i næsten enhver udvikling. Noget af dette skyldes det unikke i regeringens behov og krav på dette område. Noget af dette skyldes de iboende vanskeligheder med at imødegå cyberangreb. At skabe defensive evner til at dække spektret af angreb er udfordrende og risikabelt. Hjælp regeringen udvikle resiliency tilgange (f.eks beredskabsplaner, backup/recovery, etc.). Aktivering af informationsdeling på tværs af systemer i koalitionsoperationer med internationale partnere giver tekniske udfordringer og politiske spørgsmål, der omsættes til udviklingsrisiko. Informationssikkerhedsproblemerne i forbindelse med supply chain management er så brede og komplekse, at selv opretholdelse af rudimentær bevidsthed om truslerne er en enorm udfordring.
færdighedsniveau. Udviklernes, integratorernes, regeringens og andre interessenters færdigheds-eller erfaringsniveau kan føre til risici. Vær på udkig efter utilstrækkelige færdigheder og nå på tværs af selskabet for at udfylde eventuelle huller. På den måde hjælper du med at uddanne regeringsteammedlemmer på samme tid, som du bringer virksomhedernes færdigheder og erfaring til at bære.
Omkostningsrisici. Programmer vil typisk skabe en regerings omkostningsestimat, der overvejer risiko. Når du udvikler og forfiner programmets tekniske og andre risici, bør de tilhørende omkostningsestimater også udvikle sig. Omkostningsestimering er ikke en engangsaktivitet.
historisk information som vejledning til risikoidentifikation. Historiske oplysninger fra lignende offentlige programmer kan give værdifuld indsigt i fremtidige risici. Søg information om operationelle udfordringer og risici i forskellige erfaringer med drift, efter handlingsrapporter, træningsoversigter og forsøgsresultater. Kunder har ofte opbevaringssteder for disse at få adgang til. Regeringsledere vil normalt kommunikere deres strategiske behov og udfordringer. Forstå og faktor disse i din vurdering af de vigtigste kapaciteter, som din kunde har brug for, og som grundlag for risikovurderinger.
Historiske data til at hjælpe med at vurdere risiko er ofte tilgængelige fra de tidligere præstationsvurderinger og erfaringer fra anskaffelsesprogrammer og entreprenører. I mange tilfælde vil MITRE-personale hjælpe regeringen med at forberede præstationsoplysninger til en bestemt erhvervelse. AF har en past Performance Evaluation Guide (PPEG), der identificerer den type information, der skal fanges, der kan bruges til fremtidige valg af regeringskilder . Dette arkiv af oplysninger kan hjælpe med at give baggrundsinformation om tidligere udfordringer, og hvor de måtte opstå igenbåde for den bestemte type udviklingsaktivitet såvel som med de særlige entreprenører.
der er adskillige tekniske vurderinger for leverandørprodukter, der kan fås adgang til for at bestemme risikoen og levedygtigheden af forskellige produkter. Et GERINGSARKIV af evalueringer af værktøjer er Analyseværktøjsskuret, der indeholder vejledning om og erfaring med analytiske værktøjer. Brug af ressourcer som disse og søgning efter andre, der har prøvet produkter og teknikker i prototyper og eksperimenter, kan hjælpe med at vurdere risikoen for en bestemt indsats.
hvordan man skriver en risiko-en bedste praksis . En bedste praksis protokol til at skrive en risikoerklæring er betingelsen-hvis-så konstruere. Denne protokol gælder for risikostyringsprocesser designet til næsten ethvert miljø. Det er en erkendelse af, at en risiko i sin natur er sandsynlig, og at hvis den opstår, har uønskede konsekvenser.
Hvad er betingelsen-hvis-så konstruere? Tilstanden afspejler det, der er kendt i dag. Det er årsagen til den identificerede risikohændelse. Tilstanden er således en begivenhed, der har fundet sted, forekommer i øjeblikket eller vil forekomme med sikkerhed. Risikohændelser er fremtidige begivenheder, der kan opstå på grund af den nuværende tilstand. Nedenfor er en illustration af denne protokol.
If er risikohændelsen forbundet med den tilstedeværende tilstand. Det er kritisk vigtigt at genkende If og tilstanden som en dobbelt. Når der undersøges i fællesskab, kan der være måder til direkte at gribe ind eller afhjælpe risikohændelsens underliggende rod (tilstand), således at konsekvenserne af denne begivenhed, hvis den opstår, ikke længere truer projektet. If er den sandsynlige del af risikoerklæringen.
derefter er konsekvensen eller sæt af konsekvenser, der vil påvirke ingeniørsystemprojektet, hvis risikohændelsen opstår. Et eksempel på en betingelse-If-Then konstruktion er illustreret i figur 2.
tilskynde hold til at identificere risici. Kulturen i nogle offentlige projekter og programmer afskrækker identifikation af risici. Dette kan opstå, fordi risikostyringsaktiviteterne til sporing, overvågning og afbødning af risiciene ses som byrdefulde og uhensigtsmæssige. I denne situation kan det være nyttigt at tale med holdene om fordelene ved at identificere risici og manglende evne til at styre det hele i dine hoveder (f. eks., bestemme prioritet, hvem der skal involveres, afbødende handlinger). Bistå regeringsteamene med at udføre en proces, der afbalancerer ledelsesinvesteringer med værdi for projektets resultater. Generelt opnås en god balance, når projektets omfang, tidsplan og omkostningsmål opfyldes eller med succes afbødes af handlingsplaner, og projektteamet mener, at risikostyringsaktiviteter giver værdi for projektet. Repræsentation på tværs af hold er et must; risici bør ikke identificeres af en person eller strengt af systemteknikteamet (gennemgå kilder til risiko ovenfor).
overvej organisatoriske og miljømæssige faktorer. Organisatoriske, kulturelle, politiske og andre miljømæssige faktorer, såsom interessentstøtte eller organisatoriske prioriteter, kan udgøre lige så meget eller mere risiko for et projekt end tekniske faktorer alene. Disse risici skal identificeres og afbødes aktivt i hele projektets levetid. Afbødningsaktiviteter kan omfatte overvågning af lovgivningsmæssige mandater eller nødændringer, der kan påvirke programmet eller projektmissionen, organisatoriske ændringer, der kan påvirke brugerkrav eller kapacitetsnyttighed, eller ændringer i politisk støtte, der kan påvirke finansieringen. I hvert tilfælde skal du overveje risikoen for programmet og identificere handlingsmuligheder til diskussion med interessenter. For yderligere oplysninger, se artiklen risikoreduktion planlægning, implementering og overvågning af fremskridt.
Inkluder interessenter i risikoidentifikation. Projekter og programmer har normalt flere interessenter, der bringer forskellige dimensioner af risiko for resultaterne. De omfatter operatører, der kan blive overvældet af nye systemer; brugere, der måske ikke er ordentligt uddannet eller har frygt for deres job; tilsynsførende, der måske ikke støtter en ny kapacitet, fordi det ser ud til at mindske deres autoritet; og beslutningstagere, der er bekymrede for lovgivningsmæssig godkendelse og omkostninger. Derudover er det vigtigt at inkludere alle interessenter, såsom certificerings-og akkrediteringsmyndigheder, der, hvis de utilsigtet overses, kan udgøre store risici senere i programmet. Interessenter kan være meget opmærksomme på forskellige miljøfaktorer, såsom verserende lovgivning eller politisk programstøtte, der kan udgøre risici for et projekt, der er ukendt for regeringen eller MITRE-projektteamet. Inkluder interessenter i risikoidentifikationsprocessen for at hjælpe med at overflade disse risici.
skriv klare risikoerklæringer. Brug af Condition-if-Then-formatet hjælper med at kommunikere og evaluere en risikoerklæring og udvikle en afbødningsstrategi. Grundårsagen er den underliggende tilstand, der har indført risikoen (f.eks. kan en designtilgang være årsagen), If afspejler sandsynligheden (f. eks. sandsynlighedsvurdering af, at if-delen af risikoerklæringen skulle forekomme), og derefter kommunikerer virkningen til programmet (f. eks. øgede ressourcer til understøttelse af test, yderligere tidsplan og bekymring for at imødekomme ydeevne). Afbødningsstrategien er næsten altid bedre, når den er baseret på en klart formuleret risikoerklæring.
forvent ændringer i risikoerklæring, når risikovurderings-og afbødningsstrategien udvikles. Det er almindeligt at have risikoerklæringer raffineret, når holdet vurderer virkningen. Ved vurdering og dokumentation af den potentielle risikopåvirkning (omkostninger, tidsplan, teknisk eller tidsramme) kan forståelsen og opgørelsen af risikoen ændre sig. For eksempel, når man vurderer en risikopåvirkning af programmelskema, kan risikoerklæringen forbedres til at omfatte behovsdato og/eller yderligere afklaring af virkningen (f.eks. hvis programmet ikke leveres inden marts 2015, vil der ikke være tilstrækkelig tid til at teste grænsefladeudvekslingerne før begrænset brugertest).
Inkluder ikke afbødningserklæringen i risikoerklæringen. Pas på ikke at falde i fælden med at få afbødningserklæringen indført i risikoerklæringen. En risiko er en usikkerhed med potentiel negativ indvirkning. Nogle springer hurtigt til afslutningen af risikobegrænsning, og i stedet for at identificere den risiko, der skal afbødes (med identificerede afbødningsmuligheder), identificerer de risikoen som en suboptimal designtilgang. For eksempel kan en risikoerklæring være: hvis entreprenøren ikke bruger HS til test, vil testen mislykkes. Bekymringen er virkelig testforsyning. Hvis entreprenøren ikke udfører testen med målbare resultater til analyse, kan programmet muligvis ikke bestå begrænset brugertest. Det kan være en afbødende mulighed for at reducere risikoen for testtilstrækkelighed.
gå ikke til en afbødningsstrategi, før du vurderer risikosandsynligheden og virkningen. En risiko kan forbedres eller ændres givet yderligere analyse, som kan påvirke, hvad den mest effektive/ønskede afbødning kan være. Ingeniører springer ofte til løsningen; det er bedst at gå til det næste trin, der diskuteres i artiklen om risikovurdering og prioritering for først at nedbryde og forstå problemet. I sidste ende vil dette føre til en strategi, der er tæt tilpasset bekymringen.
referencer& ressourcer
- MITRE Institute, 1.September 2007, Mitre Systems Engineering (SE) Kompetencemodel, Version 1, s. 10, 40-41.
- Garvey, P. R., 2008, analysemetoder til risikostyring: et Systemteknisk perspektiv, Chapman-Hall/CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, Ny York, ISBN: 1584886374.US Air Force, januar 2008, Air Force Past performance Evaluation Guide(PPEG), IG5315.305 (a).
- US Air Force, januar 2008, Air Force Past performance Evaluation Guide (PPEG), IG5315.305(a).
yderligere referencer & ressourcer
MITRE E520 risikoanalyse og ledelse teknisk team tjeklister, risikokontrol, risikoanalyse og ledelsesdokumenter.
Project Management Institute, en Guide til Projektledelsesorganet for viden, (PMBOK Guide), fjerde udgave, ANSI/PMI 99-001-2008, s.273-312, adgang til 2. marts 2010.
SEPO, ” standardproces / procestrin, Trin 2: Identificer risici & farer,” MITRE SEPO Risk Management Toolkit, adgang til 5.maj 2010.
