Definisjon: risikoidentifikasjon er prosessen med å bestemme risikoer som potensielt kan hindre at programmet, bedriften eller investeringen når sine mål. Det inkluderer å dokumentere og kommunisere bekymringen.
Nøkkelord: risiko, risikoidentifikasjon, risikostyring
MITRE Se Roller & Forventninger: MITRE systems engineers (SEs) som arbeider med offentlige programmer, forventes å identifisere risikoer som kan påvirke prosjektet og programmet. De forventes å skrive og gjennomgå risikosetninger som er klare, entydige og støttet av bevis .
Bakgrunn
risikoidentifikasjon er det kritiske første trinnet i risikostyringsprosessen som er avbildet i Figur 1.
målet med risikoidentifikasjon er tidlig og kontinuerlig identifisering av hendelser som, hvis de oppstår, vil ha negativ innvirkning på prosjektets evne til å oppnå ytelses – eller kapasitetsutfallsmål. De kan komme fra prosjektet eller fra eksterne kilder.
det finnes flere typer risikovurderinger, inkludert programrisikovurderinger, risikovurderinger for å støtte en investeringsbeslutning, analyse av alternativer og vurderinger av drifts-eller kostnadsusikkerhet. Risikoidentifikasjon må samsvare med typen vurdering som kreves for å støtte risikoinformert beslutningstaking. For et oppkjøpsprogram er det første trinnet å identifisere programmets mål og mål, og dermed fremme en felles forståelse på tvers av teamet om hva som trengs for programsuksess. Dette gir kontekst og grenser omfanget av hvilke risikoer som identifiseres og vurderes.
Identifisering Av Risiko I Systems Engineering Program
det er flere kilder til risiko. For risikoidentifikasjon bør prosjektgruppen gjennomgå programomfanget, kostnadsestimatene ,tidsplanen( for å inkludere evaluering av den kritiske linjen), teknisk modenhet, nøkkelprestasjonsparametere, ytelsesutfordringer, interessentforventninger vs. gjeldende plan, eksterne og interne avhengigheter, implementeringsutfordringer, integrasjon, interoperabilitet, støttbarhet, sårbarheter i forsyningskjeden, evne til å håndtere trusler, kostnadsavvik, testhendelsesforventninger, sikkerhet, sikkerhet og mer. I tillegg gir historiske data fra lignende prosjekter, interessentintervjuer og risikolister verdifull innsikt i områder for vurdering av risiko.
risikoidentifikasjon er en iterativ prosess. Etter hvert som programmet utvikler seg, vil det bli oppnådd mer informasjon om programmet (f.eks. Nye risikoer vil bli identifisert som prosjektet utvikler seg gjennom livssyklusen.
Beste Praksis Og Erfaringer
Operasjonell Risiko. Forstå den operasjonelle naturen til evnene du støtter og risikoen for sluttbrukerne, deres oppdrag og deres drift av evnene. Forståelse av det operative behovet /oppdraget (se Konseptutviklingsemnet I Systemteknikkveiledningen) vil hjelpe deg med å sette pris på alvoret av risiko og virkningen de kan ha for sluttbrukerne. Dette er en kritisk del av risikoanalysen-å realisere den virkelige effekten som kan oppstå hvis en risiko oppstår under operativ bruk. Vanligvis operative brukere er villige til å akseptere en viss grad av risiko hvis de er i stand til å utføre sitt oppdrag (f. eks mission assurance), men du må hjelpe brukerne til å forstå risikoen de aksepterer og å vurdere alternativene, saldoer og alternativer som er tilgjengelige.
Teknisk modenhet. Arbeid med og utnytte industri og akademia for å forstå teknologiene som vurderes for en innsats og den sannsynlige overgangen til teknologien over tid. En tilnærming er å jobbe med leverandører under en ikke-avsløringsavtale for å forstå mulighetene og hvor de skal, slik at risikoen kan vurderes.
Ikke-Utviklingsmessige Elementer (NDI). NDI inkluderer kommersielle-off-the-sokkel og regjeringen-off-the-sokkel elementer. For å håndtere risiko, vurder levedyktigheten TIL ndi-leverandøren. Har leverandøren markedsandeler? Har leverandøren riktig levetid i forhold til sine konkurrenter? Hvordan adresserer leverandøren kapasitetsproblemer og utgivelsesrettinger, etc.? Hva er brukerbasen for den aktuelle NDI? Kan leverandøren demonstrere NDI, helst i en innstilling som ligner på kunden din? Kan REGJERINGEN bruke NDI til å lage en prototype? Alle disse faktorene vil bidra til å vurdere risikoen FOR levedyktigheten TIL NDI og leverandøren. Søke svar på disse spørsmålene fra andre MITRE ansatte som har jobbet området eller har brukt NDI blir vurdert.
Oppkjøp drivere. Legg vekt på kritiske kapasitetsmuligheter, spesielt de som har begrensede alternativer. Vurdere og bestemme de primære driverne til et oppkjøp og understreke tilhørende risiko ved å formulere risikoreduserende anbefalinger. Hvis et bestemt aspekt av en evne ikke er kritisk for suksess, bør risikoen vurderes, men det trenger ikke være hovedfokus for risikostyring. For eksempel, hvis det er risiko for et foreslått brukergrensesnitt, men markedet har mange alternativer, er suksessen til den foreslåtte tilnærmingen sannsynligvis mindre kritisk for den samlede suksessen til evnen. På den annen side er en informasjonssikkerhetsfunksjon sannsynligvis kritisk. Hvis bare en alternativ tilnærming tilfredsstiller behovet, bør det legges vekt på det. Bestem de primære suksessdriverne ved å evaluere behov og design, og bestemme alternativene som eksisterer. Er en unik løsning på den kritiske veien til suksess? Sørg for at kritiske baneanalyser inkluderer hele systemkonstruksjonssyklusen og ikke bare utvikling (dvs. systemutvikling i seg selv kan være et «stykke kake», men felt i en aktiv driftssituasjon kan være en stor risiko).
Bruk kapasitetsutvikling for å håndtere risiko. Hvis spesielle krav kjører implementering av evner som er høy risiko på grunn av unik utvikling, edge-of-the-konvolutt ytelsesbehov, etc., bør kravene diskuteres med brukerne for deres kritikk. Det kan være at behovet kan bli utsatt, og utviklingsmiljøet bør vurdere når det kan være fornøyd i fremtiden. Hjelp brukere og utviklere å måle hvor mye risiko (og planlegge og kostnadspåvirkning) en bestemt evne bør påta seg mot kravene for å motta mindre risikable evner før. I å utvikle dine anbefalinger, vurdere teknisk gjennomførbarhet og kunnskap om relaterte implementering suksesser og fiaskoer å vurdere risikoen for å implementere nå i stedet for fremtiden. Ved å utsette evner, pass på å ikke falle i fellen med å utsette ultimate fiasko ved å handle på kort sikt, enkle suksesser for en fremtid med flere høyrisikokrav som kan være avgjørende for total suksess.
Viktige Ytelsesparametere (Kpp). Samarbeide tett med brukerne for å etablere KPPs. Samlet risiko for programavbrudd kan være sentrert på manglende evne til å møte KPPs. Arbeid med brukerne for å sikre at parametrene er lydhør overfor oppdragsbehov og teknisk gjennomførbart. Parametrene bør ikke være så lette at de lett kan oppfylles, men ikke oppfylle oppdragsbehovet; de bør heller ikke være så strenge at de ikke kan oppfylles uten en omfattende innsats eller skyve teknologi-som begge kan sette et program i fare. Søk resultater fra tidligere operasjoner, eksperimenter, ytelsesvurderinger og industriimplementeringer for å avgjøre gjennomførbarheten av ytelsen.
Eksterne og interne avhengigheter. Å ha et bedriftsperspektiv kan hjelpe innløsere, programledere, utviklere, integratorer og brukere til å sette pris på risiko fra avhengigheter i en utviklingsinnsats. Med fremveksten av serviceorienterte tilnærminger vil et program bli mer avhengig av tilgjengeligheten og driften av tjenester som tilbys av andre som de har tenkt å bruke i programmets utviklingsarbeid. Arbeid med utviklerne av tjenester for å sikre kvalitetstjenester blir opprettet, og tanke har blitt satt inn i vedlikehold og utvikling av disse tjenestene. Arbeid med utviklingsprogrammets ansatte for å vurdere tjenestene som er tilgjengelige, deres kvalitet og risikoen for at et program har i å bruke og stole på tjenesten. På samme måte er det en risiko forbundet med å skape tjenesten og ikke bruke tjenester fra en annen bedriftsinnsats. Bidra til å bestemme risiko og potensielle fordeler ved å skape en tjeneste internt til utvikling med muligens en overgang til enterprise-tjenesten på et senere tidspunkt.
Integrasjon og Interoperabilitet (i& I). I & vil jeg nesten alltid være en stor risikofaktor. De er former for avhengigheter der verdien av å integrere eller interoperere har blitt vurdert til å overstyre deres iboende risiko. Teknikker som enterprise federation architecting, composable evner på forespørsel, og design mønstre kan hjelpe regjeringen planlegge og utføre en rute for å navigere i&jeg risiko. Se Enterprise Engineering delen Av Systems Engineering Guide for artikler om teknikker for adressering I&i tilknyttede risikoer.
Informasjonssikkerhet. Informasjonssikkerhet er en risiko i nesten enhver utvikling. Noe av dette skyldes det unike ved regjeringens behov og krav på dette området. Noe av dette er på grunn av de iboende vanskeligheter med å motvirke cyberangrep. Å skape defensive evner for å dekke spekteret av angrep er utfordrende og risikabelt. Hjelp regjeringen utvikle resiliency tilnærminger (f.eks beredskapsplaner, backup/recovery, etc.). Å muliggjøre informasjonsdeling på tvers av systemer i koalisjonsoperasjoner med internasjonale partnere gir tekniske utfordringer og politiske problemer som oversetter til utviklingsrisiko. Informasjonssikkerhetsproblemene knyttet til supply chain management er så brede og komplekse at selv å opprettholde rudimentær bevissthet om truslene er en enorm utfordring.
Ferdighetsnivå. Ferdigheten eller erfaringsnivået til utviklere, integratorer, myndigheter og andre interessenter kan føre til risiko. Vær på utkikk etter utilstrekkelige ferdigheter og nå over hele selskapet for å fylle eventuelle hull. Ved å gjøre det, bidra til å utdanne regjeringsteammedlemmer samtidig som du bringer bedriftens ferdigheter og erfaring til å bære.
Kostnadsrisiko. Programmer vil typisk skape en regjeringens kostnadsoverslag som vurderer risiko. Når du utvikler og forfiner programmets tekniske og andre risikoer, bør de tilknyttede kostnadsestimatene også utvikle seg. Kostnadsestimering er ikke en engangsaktivitet.
Historisk informasjon som veiledning for risikoidentifikasjon. Historisk informasjon fra lignende offentlige programmer kan gi verdifull innsikt i fremtidige risikoer. Oppsøk informasjon om operasjonelle utfordringer og risikoer i ulike operasjonelle erfaringer, etter handlingsrapporter, øvelsessammendrag og eksperimenteringsresultater. Kunder har ofte repositories av disse for å få tilgang. Offentlige ledere vil normalt kommunisere sine strategiske behov og utfordringer. Forstå og faktorere disse i din vurdering av de viktigste evnene som kunden trenger og som grunnlag for risikovurderinger.
Historiske data for å vurdere risiko er ofte tilgjengelig fra tidligere resultatvurderinger og erfaringer fra oppkjøpsprogrammer og entreprenører. I mange tilfeller VIL MITRE-ansatte bistå regjeringen med å forberede ytelsesinformasjon for et bestemt oppkjøp. AF har En Past Performance Evaluation Guide (PPEG) som identifiserer hvilken type informasjon som skal fanges opp, og som kan brukes til fremtidige valg av offentlige kilder . Denne informasjonen kan bidra til å gi bakgrunnsinformasjon om tidligere utfordringer og hvor de kan oppstå igjen-både for den bestemte typen utviklingsaktivitet og med de bestemte entreprenørene.
det er mange tekniske vurderinger for leverandørprodukter som kan nås for å bestemme risikoen og levedyktigheten til ulike produkter. ET GJÆRINGSREGISTER med evalueringer av verktøy er Analyseverktøyutgaven som inneholder veiledning om og erfaring med analyseverktøy. Å bruke ressurser som disse og søke andre som har prøvd produkter og teknikker i prototyper og eksperimenter, kan bidra til å vurdere risikoen for en bestemt innsats.
hvordan skrive en risiko-en beste praksis . En best-practice protokoll for å skrive en risiko uttalelse er Betingelsen-Hvis-da konstruere. Denne protokollen gjelder for risikostyringsprosesser designet for nesten alle miljøer. Det er en anerkjennelse av at en risiko, av sin natur, er probabilistisk og en som, hvis den oppstår, har uønskede konsekvenser.
Hva er Betingelsen-Hvis-da konstruere? Tilstanden gjenspeiler det som er kjent i dag. Det er årsaken til den identifiserte risikohendelsen. Dermed Er Tilstanden en hendelse som har skjedd, er for tiden forekommende, eller vil skje med sikkerhet. Risikohendelser er fremtidige hendelser som kan oppstå på grunn av tilstanden til stede. Nedenfor er en illustrasjon av denne protokollen.
Hvis er risikohendelsen knyttet til Tilstanden som er tilstede. Det er kritisk viktig å gjenkjenne Hvis Og Tilstanden som en dobbel. Når det undersøkes i fellesskap, kan det være måter å direkte gripe inn eller rette opp risikohendelsens underliggende rot (Tilstand) slik at konsekvensene av denne hendelsen, hvis den oppstår, ikke lenger truer prosjektet. If Er den probabilistiske delen av risikoutskriften.
den Da er konsekvensen, eller sett av konsekvenser, som vil påvirke engineering system prosjektet hvis risikohendelsen oppstår. Et Eksempel På En Tilstand-Hvis-da-konstruksjon er illustrert I Figur 2.
Oppmuntre team til å identifisere risikoer. Kulturen i noen offentlige prosjekter og programmer fraråder identifisering av risiko. Dette kan oppstå fordi risikostyringsaktivitetene for sporing, overvåking og reduksjon av risikoen blir sett på som byrdefulle og unhelpful. I denne situasjonen kan det være nyttig å snakke med teamene om fordelene ved å identifisere risikoer og manglende evne til å håndtere alt i hodet ditt (f. eks., bestemme prioritet, hvem som må være involvert, avbøtende tiltak). Bistå regjeringen lagene i å gjennomføre en prosess som balanserer ledelse investering med verdi til resultatene av prosjektet. Generelt oppnås en god balanse når prosjektets omfang, tidsplan og kostnadsmål blir oppfylt eller vellykket redusert av handlingsplaner, og prosjektgruppen mener at risikostyringsaktiviteter gir verdi til prosjektet. Kryss-team representasjon er et must; risiko bør ikke identifiseres av en person, eller strengt av systems engineering team(gjennomgang kilder til risiko ovenfor).
Vurder organisatoriske og miljømessige faktorer. Organisatoriske, kulturelle, politiske og andre miljøfaktorer, som interessentstøtte eller organisatoriske prioriteringer, kan utgjøre så mye eller mer risiko for et prosjekt enn tekniske faktorer alene. Disse risikoene bør identifiseres og aktivt reduseres gjennom hele prosjektets levetid. Avbøtende aktiviteter kan omfatte overvåking av lovgivningsmandater eller nødendringer som kan påvirke programmet eller prosjektoppdraget, organisasjonsendringer som kan påvirke brukerkrav eller kapasitetsnytte, eller endringer i politisk støtte som kan påvirke finansieringen. I hvert tilfelle bør du vurdere risikoen for programmet og identifisere handlingsalternativer for diskusjon med interessenter. Hvis du vil ha mer informasjon, kan du se Artikkelen Risikoreduserende Planlegging, Implementering og Fremdriftsovervåking.
Inkluder interessenter i risikoidentifikasjon. Prosjekter og programmer har vanligvis flere interessenter som bringer ulike dimensjoner av risiko til resultatene. De inkluderer operatører, som kan bli overveldet med nye systemer; brukere, som kanskje ikke er riktig trent eller har frykt for jobbene sine; veiledere som kanskje ikke støtter en ny evne fordi det ser ut til å redusere sin autoritet; og beslutningstakere, som er opptatt av lovgivningsmessig godkjenning og kostnad. I tillegg er det viktig å inkludere alle interessenter, for eksempel sertifiserings-og akkrediteringsmyndigheter som, hvis de utilsiktet overses, kan utgjøre store risikoer senere i programmet. Interessenter kan være svært oppmerksomme på ulike miljøfaktorer, for eksempel ventende lovgivning eller politisk programstøtte som kan utgjøre risiko for et prosjekt som er ukjent for regjeringen eller MITRE prosjektteamet. Inkluder interessenter i risikoidentifikasjonsprosessen for å hjelpe overflaten disse risikoene.
Skriv klare risikosetninger. Ved hjelp Av Condition-If-Then-formatet kan du kommunisere og evaluere en risikoerklæring og utvikle en begrensningsstrategi. Grunnårsaken er den underliggende Tilstanden som har innført risikoen (f.eks. en designtilnærming kan være årsaken), If reflekterer sannsynligheten (f. eks. sannsynlighetsvurdering at If-delen av risikoutskriften skulle oppstå), og kommuniserer deretter effekten til programmet (f. eks. økte ressurser for å støtte testing, tilleggsplan og bekymring for å møte ytelse). Begrensningsstrategien er nesten alltid bedre når den er basert på en tydelig artikulert risikoerklæring.
Forvent endringer i risikovurderings-og begrensningsstrategien. Det er vanlig å ha risiko uttalelser raffinert når teamet evaluerer virkningen. Når man vurderer og dokumenterer den potensielle risikopåvirkningen (kostnad, tidsplan, teknisk eller tidsramme), kan forståelsen og uttalelsen av risikoen endres. For eksempel, når man vurderer en risikovirkning av programvareplanslipp, kan risikoutskriften bli raffinert for å inkludere behovsdato og/eller ytterligere avklaring av innvirkning (for Eksempel hvis xyz-programvaren ikke leveres Innen Mars 2015, vil det ikke være tilstrekkelig tid til å teste grensesnittutvekslingene før Begrenset Brukertest).
ikke ta med skadereduksjon-setningen i risiko-setningen. Vær forsiktig så du ikke faller i fellen av å ha klimatiltak uttalelse innført i risiko uttalelse. En risiko er en usikkerhet med potensiell negativ innvirkning. Noen hopper raskt til konklusjonen om å redusere risikoen, og i stedet for å identifisere risikoen som bør reduseres (med begrensningsalternativer identifisert), identifiserer de risikoen som en suboptimal designtilnærming. For eksempel kan en risikoerklæring være: hvis entreprenøren ikke bruker XYZ for test, vil testen mislykkes. Bekymringen er virkelig test tilstrekkelig. Hvis entreprenøren ikke utfører testen med målbare resultater for analyse, kan programmet ikke passere begrenset brukertest. BRUK AV XYZ kan være et begrensningsalternativ for å redusere risikoen for testtilstrekkelighet.
ikke hopp til en begrensningsstrategi før du vurderer risiko sannsynlighet og innvirkning. En risiko kan forbedres eller endres gitt videre analyse, noe som kan påvirke hva den mest effektive/ønskede begrensningen kan være. Ingeniører hopper ofte til løsningen; det er best å flytte til neste trinn som er omtalt I Artikkelen Risikokonsekvensvurdering og Prioritering for å dekomponere og forstå problemet først. Til slutt vil dette føre til en strategi som er nært knyttet til bekymringen.
Referanser& Ressurser
- MITRE Institute, 1. September 2007, MITRE Systems Engineering (SE) Kompetansemodell, Versjon 1, s.10, 40-41.
- Garvey, Pr, 2008, Analysemetoder For Risikostyring: Et Systemteknisk Perspektiv, Chapman-Hall/CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New 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).
Tilleggsreferanser & Ressurser
MITRE E520 risikoanalyse Og Ledelse teknisk team sjekklister, Risikokontroll, Risikoanalyse og Ledelsesdokumenter.
Project Management Institute, En Guide Til Project Management Body Of Knowledge, (Pmbok Guide), Fjerde Utgave, ANSI / PMI 99-001-2008, s. 273-312, tilgjengelig 2.Mars 2010.
SEPO, «Standard Prosess / Trinn I Prosess, Trinn 2: Identifiser Risikoer & Farer,» MITRE SEPO Risk Management Toolkit, åpnet 5.Mai 2010.
