definitie: risico-identificatie is het proces van het bepalen van risico ‘ s die mogelijk kunnen verhinderen dat het programma, de onderneming of de investering zijn doelstellingen bereikt. Het omvat het documenteren en communiceren van het probleem.
trefwoorden: risico, risico-identificatie, Risicobeheer
MITRE se rollen & verwachtingen: MITRE systems engineers (SEs) die aan overheidsprogramma ’s werken, zullen naar verwachting risico’ s identificeren die van invloed kunnen zijn op het project en programma. Van hen wordt verwacht dat zij duidelijke, ondubbelzinnige en met bewijsmateriaal gestaafde risicoverklaringen opstellen en beoordelen .
Achtergrond
risico-identificatie is de kritieke eerste stap van het risicobeheerproces zoals afgebeeld in Figuur 1.
het doel van risico-identificatie is het vroegtijdig en continu identificeren van gebeurtenissen die, indien zij zich voordoen, negatieve gevolgen zullen hebben voor het vermogen van het project om prestatie-of vermogensuitkomstdoelstellingen te bereiken. Zij kunnen afkomstig zijn uit het project of uit externe bronnen.
er zijn verschillende soorten risicobeoordelingen, waaronder programmarisicobeoordelingen, risicobeoordelingen ter ondersteuning van een investeringsbeslissing, analyse van alternatieven en beoordelingen van operationele of kostenonzekerheid. De identificatie van de risico ’s moet overeenkomen met het soort beoordeling dat vereist is ter ondersteuning van besluitvorming met kennis van risico’ s. Voor een acquisitie programma, de eerste stap is het identificeren van de doelstellingen van het programma en de doelstellingen, waardoor het bevorderen van een gemeenschappelijk begrip in het team van wat nodig is voor het succes van het programma. Dit geeft context en begrenst de reikwijdte waarmee risico ‘ s worden geïdentificeerd en beoordeeld.
risico ‘ s identificeren in het Systeemengineerprogramma
zijn er meerdere bronnen van risico. Voor risico-identificatie moet het projectteam de reikwijdte van het programma, kostenramingen, schema (om evaluatie van het kritieke pad te omvatten), technische maturiteit, belangrijkste prestatieparameters, prestatieuitdagingen, verwachtingen van stakeholders Versus huidig plan, externe en interne afhankelijkheden, implementatieuitdagingen, integratie, interoperabiliteit, supportability, kwetsbaarheden in de toeleveringsketen, vermogen om bedreigingen aan te pakken, kostenafwijkingen, verwachtingen van testgebeurtenissen, veiligheid, beveiliging en meer beoordelen. Daarnaast bieden Historische gegevens uit soortgelijke projecten, interviews met belanghebbenden en risicolijsten waardevol inzicht in gebieden waar risico ‘ s in aanmerking kunnen worden genomen.
risico-identificatie is een iteratief proces. Naarmate het programma vordert, zal meer informatie worden verkregen over het programma (bijvoorbeeld specifiek ontwerp), en de Risicoverklaring zal worden aangepast aan de huidige inzichten. Nieuwe risico ‘ s zullen worden geïdentificeerd naarmate het project vordert tijdens de levenscyclus.
beste praktijken en geleerde lessen
operationeel risico. Begrijp de operationele aard van de mogelijkheden die u ondersteunt en het risico voor de eindgebruikers, hun missies en hun activiteiten van de mogelijkheden. Inzicht in de operationele behoefte/missie (zie het Concept ontwikkeling onderwerp van de Systems Engineering Guide) zal u helpen de ernst van de risico ‘ s en de impact die ze kunnen hebben op de eindgebruikers te begrijpen. Dit is een cruciaal onderdeel van risicoanalysehet realiseren van de reële impact die kan optreden als er een risico ontstaat tijdens operationeel gebruik. Doorgaans zijn operationele gebruikers bereid om een bepaald risiconiveau te accepteren als ze in staat zijn om hun missie te volbrengen (bijvoorbeeld mission assurance), maar u moet gebruikers helpen om de risico ‘ s te begrijpen die ze accepteren en om de beschikbare opties, balansen en alternatieven te beoordelen.
technische looptijd. Werk met en hefboomwerking Industrie en de academische wereld om de technologieën die worden overwogen voor een inspanning en de waarschijnlijke overgang van de technologie in de tijd te begrijpen. Een aanpak is om met leveranciers te werken in het kader van een non-disclosure agreement om de mogelijkheden en waar ze naartoe gaan te begrijpen, zodat het risico kan worden beoordeeld.
niet-Ontwikkelingscomponenten (NDI). NDI omvat commerciële-off-the-shelf en overheid-off-the-shelf items. Om de risico ‘ s te beheren, moet de levensvatbaarheid van de ndi-aanbieder in overweging worden genomen. Heeft de aanbieder marktaandeel? Heeft de aanbieder een passende levensduur in vergelijking met zijn concurrenten? Hoe werkt de provider aan te pakken vermogensproblemen en release fixes, enz.? Wat is de gebruikersbasis voor de betreffende NDI? Kan de aanbieder de NDI demonstreren, bij voorkeur in een omgeving die vergelijkbaar is met die van uw klant? Kan de overheid de NDI gebruiken om een prototype te maken? Al deze factoren zullen helpen het risico van de levensvatbaarheid van de NDI en de aanbieder te beoordelen. Zoek antwoorden op deze vragen van andere VERSTEKMEDEWERKERS die het gebied hebben bewerkt of gebruik hebben gemaakt van de ndi die wordt beoordeeld.
acquisitie drivers. Benadruk kritische capability enablers, in het bijzonder degenen die beperkte alternatieven hebben. Evalueer en bepaal de primaire drijfveren voor een acquisitie en benadruk de bijbehorende risico ‘ s bij het formuleren van risicobeperkende aanbevelingen. Als een bepaald aspect van een vermogen niet van cruciaal belang is voor het succes ervan, moet het risico ervan worden beoordeeld, maar het hoeft niet de primaire focus van risicobeheer te zijn. Als er bijvoorbeeld risico ‘ s zijn voor een voorgestelde gebruikersinterface, maar de markt heeft tal van alternatieven, is het succes van de voorgestelde aanpak waarschijnlijk minder cruciaal voor het algehele succes van de mogelijkheid. Aan de andere kant, een informatiebeveiliging functie is waarschijnlijk van cruciaal belang. Als slechts één alternatieve aanpak aan de behoefte voldoet, moet de nadruk daarop worden gelegd. Bepaal de primaire succes drivers door het evalueren van behoeften en ontwerpen, en het bepalen van de alternatieven die bestaan. Is een unieke oplossing op de kritieke weg naar succes? Zorg ervoor dat kritische padanalyses omvatten de gehele systeem engineering cyclus en niet alleen de ontwikkeling (dat wil zeggen, systeemontwikkeling, per se, kan een “fluitje van een cent,” maar fielding in een actieve operationele situatie kan een groot risico).
gebruik capability evolution om risico ‘ s te beheren. Als specifieke vereisten de implementatie van mogelijkheden die een hoog risico als gevolg van unieke ontwikkeling, edge-of-the-envelope prestatiebehoeften, enz., de eisen moeten worden besproken met de gebruikers voor hun kriticiteit. Het kan zijn dat de behoefte kan worden uitgesteld, en de ontwikkelingsgemeenschap moet beoordelen wanneer in de toekomst aan deze behoefte kan worden voldaan. Help gebruikers en ontwikkelaars meten hoeveel risico (en planning en kosten impact) een bepaalde capaciteit moet aannemen ten opzichte van de eisen om minder risicovolle mogelijkheden sneller te ontvangen. Bij het ontwikkelen van uw aanbevelingen, rekening houden met de technische haalbaarheid en kennis van de gerelateerde implementatie successen en mislukkingen om het risico van de implementatie nu in plaats van de toekomst te beoordelen. Bij het uitstellen van mogelijkheden, zorg ervoor dat u niet in de val van het uitstellen van de uiteindelijke mislukking door de handel op korte termijn gemakkelijke successen voor een toekomst van meerdere hoog-risico eisen die essentieel kunnen zijn voor het algemene succes.
Key Performance Parameters (KPPs). Werk nauw samen met de gebruikers om KPPs op te richten. Algemeen risico van programma annulering kan worden gecentreerd op het niet voldoen aan KPPs. Werk samen met de gebruikers om ervoor te zorgen dat de parameters inspelen op de behoeften van de missie en technisch haalbaar zijn. De parameters moeten niet zo mild zijn dat ze gemakkelijk kunnen worden gehaald, maar niet voldoen aan de missiebehoefte; noch moeten ze zo streng zijn dat ze niet kunnen worden gehaald zonder een uitgebreide inspanning of pushing technologiedie beide een programma in gevaar kunnen brengen. Zoek resultaten van eerdere operaties, experimenten, prestatiebeoordelingen en implementaties in de industrie om de haalbaarheid van de prestaties te bepalen.
externe en interne afhankelijkheden. Het hebben van een enterprise perspectief kan helpen acquirers, programma managers, ontwikkelaars, integrators, en gebruikers waarderen risico van afhankelijkheden van een ontwikkeling inspanning. Met de opkomst van service-georiënteerde benaderingen, EEN programma zal meer afhankelijk worden van de beschikbaarheid en de werking van diensten die door anderen die zij van plan zijn te gebruiken in hun programma ‘ s ontwikkelingsinspanningen. Werk samen met de ontwikkelaars van diensten om ervoor te zorgen dat kwaliteitsdiensten worden gecreëerd, en er is nagedacht over het onderhoud en de ontwikkeling van deze diensten. Werk samen met de medewerkers van het Ontwikkelingsprogramma om de beschikbare diensten te beoordelen, hun kwaliteit en het risico dat een programma heeft bij het gebruik van en het vertrouwen op de dienst. Ook is er een risico verbonden aan het creëren van de dienst en het niet gebruiken van diensten van een andere onderneming inspanning. Helpen bepalen van de risico ‘ s en potentiële voordelen van het creëren van een dienst intern aan de ontwikkeling met eventueel een overgang naar de enterprise service op een toekomstig moment.
integratie en interoperabiliteit (i &I). I&I zal bijna altijd een belangrijke risicofactor zijn. Het zijn vormen van afhankelijkheid waarbij de waarde van integratie of interoperabiliteit is beoordeeld om de inherente risico ‘ s ervan te overstijgen. Technieken zoals Enterprise federation architecting, composable capabilities on demand en design patterns kunnen de overheid helpen bij het plannen en uitvoeren van een route om I&I risico ‘ s te navigeren. Zie de sectie Enterprise Engineering van de Systems Engineering Guide voor artikelen over technieken voor het aanpakken van I&I geassocieerde risico ‘ s.
informatiebeveiliging. Informatiebeveiliging is een risico in bijna elke ontwikkeling. Een deel hiervan is te wijten aan het unieke karakter van de behoeften en eisen van de overheid op dit gebied. Een deel van dit is vanwege de inherente problemen bij het tegengaan van cyberaanvallen. Het creëren van defensieve mogelijkheden om het spectrum van aanvallen te dekken is uitdagend en riskant. Help de overheid bij het ontwikkelen van veerkrachtbenaderingen (bijv. noodplannen, back-up / herstel, enz.). Het mogelijk maken van informatie-uitwisseling tussen systemen in coalitieoperaties met internationale partners brengt technische uitdagingen en beleidskwesties met zich mee die zich vertalen in ontwikkelingsrisico ‘ s. De informatiebeveiligingsproblemen in verband met supply chain management zijn zo breed en complex dat zelfs het handhaven van een rudimentair bewustzijn van de bedreigingen een enorme uitdaging is.
vaardigheidsniveau. De vaardigheid of ervaring niveau van de ontwikkelaars, integrators, de overheid, en andere belanghebbenden kan leiden tot risico ‘ s. Wees op zoek naar onvoldoende vaardigheden en bereik het hele bedrijf om eventuele hiaten op te vullen. Door dit te doen, helpen bij het opleiden van de overheid teamleden op hetzelfde moment dat u het brengen van corporate vaardigheden en ervaring te dragen.
kostenrisico ‘ s. Programma ‘ s maken meestal een schatting van de kosten van de overheid die rekening houdt met risico. Naarmate u de technische en andere risico ‘ s van het programma ontwikkelt en verfijnt, moeten de bijbehorende kostenramingen ook evolueren. Kostenraming is geen eenmalige activiteit.
historische informatie als leidraad voor risico-identificatie. Historische informatie uit soortgelijke overheidsprogramma ’s kan waardevol inzicht bieden in toekomstige risico’ s. Zoek informatie over operationele uitdagingen en risico ‘ s in verschillende operationele lessen geleerd, na actie rapporten, oefening samenvattingen, en experimenten resultaten. Klanten hebben vaak repositories van deze om toegang te krijgen. Regeringsleiders zullen normaal gesproken hun strategische behoeften en uitdagingen communiceren. Begrijp en neem deze mee in uw beoordeling van de belangrijkste capaciteiten die uw klant nodig heeft en als basis voor risicobeoordelingen.
Historische gegevens om risico ’s te helpen beoordelen zijn vaak beschikbaar uit eerdere prestatiebeoordelingen en lessen die zijn geleerd van acquisitieprogramma’ s en contractanten. In veel gevallen, MITRE personeel zal de overheid te helpen bij het voorbereiden van prestatie-informatie voor een bepaalde overname. De AF heeft een Past Performance Evaluation Guide (Ppeg) waarin wordt aangegeven welk type informatie moet worden vastgelegd die kan worden gebruikt voor toekomstige bronselecties van de overheid . Dit gegevensbestand kan helpen achtergrondinformatie te verschaffen over eerdere uitdagingen en waar deze zich opnieuw zouden kunnen voordoenzowel voor het specifieke type ontwikkelingsactiviteit als voor de specifieke contractanten.
er zijn talrijke technische beoordelingen voor leveranciersproducten die toegankelijk zijn om het risico en de levensvatbaarheid van verschillende producten te bepalen. Een MITRE repository van evaluaties van tools is de analyse Toolshed die begeleiding en ervaring met analytische tools bevat. Met behulp van middelen als deze en het zoeken naar anderen die producten en technieken hebben geprobeerd in prototypes en experimenten kan helpen bij het beoordelen van de risico ‘ s voor een bepaalde inspanning.
hoe een risico te schrijven — een beste praktijk . Een best-practice protocol voor het schrijven van een Risicoverklaring is de Condition-If-Then construct. Dit protocol is van toepassing op risicobeheerprocessen die zijn ontworpen voor vrijwel elke omgeving. Het is een erkenning dat een risico van nature probabilistisch is en een risico dat, als het zich voordoet, ongewenste gevolgen heeft.
Wat is de Condition-If-Then construct? De toestand weerspiegelt wat vandaag de dag bekend is. Het is de hoofdoorzaak van de geïdentificeerde risicogebeurtenis. De toestand is dus een gebeurtenis die heeft plaatsgevonden, momenteel plaatsvindt of met zekerheid zal plaatsvinden. Risicogebeurtenissen zijn toekomstige gebeurtenissen die wegens de aanwezige voorwaarde kunnen voorkomen. Hieronder is een illustratie van dit protocol.
het bf is het risicogebeurtenis geassocieerd met de aanwezige aandoening. Het is van cruciaal belang om als en de voorwaarde als dubbel te erkennen. Bij gezamenlijk onderzoek kunnen er manieren zijn om direct in te grijpen of de onderliggende oorzaak (conditie) van de risicogebeurtenis te verhelpen, zodat de gevolgen van deze gebeurtenis, als deze zich voordoet, het project niet langer bedreigen. Het bf is het probabilistische gedeelte van de Risicoverklaring.
Dit is het gevolg, of een reeks gevolgen, dat van invloed zal zijn op het engineering system project als de risicogebeurtenis zich voordoet. Een voorbeeld van een Condition-If-Then construct wordt geïllustreerd in Figuur 2.
moedigt teams aan risico ‘ s te identificeren. De cultuur in sommige overheidsprojecten en-programma ’s ontmoedigt de identificatie van risico’ s. Dit kan zich voordoen omdat de risicobeheeractiviteiten van het volgen, monitoren en beperken van de risico ‘ s als belastend en onbehulpzaam worden beschouwd. In deze situatie kan het nuttig zijn om met de teams te praten over de voordelen van het identificeren van risico ‘ s en het onvermogen om het allemaal in je hoofd te beheren (bijv., prioriteit bepalen, wie moet worden betrokken, mitigatiemaatregelen). Assisteer de overheidsteams bij het uitvoeren van een proces dat managementinvesteringen balanceert met waarde voor de resultaten van het project. In het algemeen wordt een goed evenwicht bereikt wanneer de projectomvang, planning en kostendoelstellingen worden gehaald of met succes worden beperkt door actieplannen, en het projectteam is van mening dat risicobeheeractiviteiten waarde bieden aan het project. Teamoverschrijdende vertegenwoordiging is een must; risico ‘ s mogen niet worden geïdentificeerd door een individu, of strikt door het systeem engineering team (overzicht bronnen van risico hierboven).
Houd rekening met organisatorische en omgevingsfactoren. Organisatorische, culturele, politieke en andere omgevingsfactoren, zoals stakeholderondersteuning of organisatorische prioriteiten, kunnen net zoveel of meer risico voor een project opleveren dan technische factoren alleen. Deze risico ‘ s moeten gedurende de gehele looptijd van het project worden geïdentificeerd en actief worden beperkt. Mitigatieactiviteiten kunnen bestaan uit het monitoren van wettelijke mandaten of noodwijzigingen die van invloed kunnen zijn op de missie van het programma of het project, organisatorische veranderingen die van invloed kunnen zijn op de behoeften van de gebruiker of het nut van de capaciteit, of veranderingen in politieke steun die van invloed kunnen zijn op de financiering. Overweeg in elk geval het risico voor het programma en identificeer actieopties voor discussie met belanghebbenden. Zie het artikel risicobeperkende Planning, implementatie en voortgangsbewaking voor meer informatie.
belanghebbenden betrekken bij risico-identificatie. Projecten en programma ‘ s hebben meestal meerdere stakeholders die verschillende dimensies van risico aan de resultaten te brengen. Het gaat onder meer om exploitanten, die overspoeld kunnen worden door nieuwe systemen; gebruikers, die misschien niet goed zijn opgeleid of bang zijn voor hun baan; toezichthouders, die misschien geen steun geven aan een nieuwe capaciteit omdat het hun gezag lijkt te verminderen; en beleidsmakers, die zich zorgen maken over wettelijke goedkeuring en kosten. Daarnaast is het belangrijk om alle stakeholders erbij te betrekken, zoals certificerings-en accreditatieautoriteiten die, als ze per ongeluk over het hoofd worden gezien, later in het programma grote risico ‘ s kunnen opleveren. Stakeholders kunnen scherp op de hoogte zijn van verschillende omgevingsfactoren, zoals hangende wetgeving of politieke programmaondersteuning die risico ‘ s kunnen opleveren voor een project dat onbekend is voor de overheid of het MITRE projectteam. Stakeholders betrekken bij het risico-identificatieproces om deze risico ‘ s aan de oppervlakte te helpen brengen.
schrijf duidelijke risicoverklaringen. Het gebruik van het Condition-If-Then-formaat helpt bij het communiceren en evalueren van een Risicoverklaring en het ontwikkelen van een mitigatiestrategie. De hoofdoorzaak is de onderliggende voorwaarde die het risico heeft geïntroduceerd (bijvoorbeeld, een ontwerp benadering kan de oorzaak zijn), de If weerspiegelt de waarschijnlijkheid (bijvoorbeeld, waarschijnlijkheidsbeoordeling dat het If-gedeelte van de Risicoverklaring zou optreden), en de communiceert vervolgens de impact op het programma (bijvoorbeeld, verhoogde middelen om testen te ondersteunen, extra schema, en zorg om de prestaties te voldoen). De mitigatiestrategie is bijna altijd beter als ze gebaseerd is op een duidelijk geformuleerde Risicoverklaring.
verwacht wijzigingen in de Risicoverklaring naarmate de risicobeoordelings-en mitigatiestrategie wordt ontwikkeld. Het is gebruikelijk dat risicoverklaringen worden verfijnd zodra het team de impact evalueert. Bij het beoordelen en documenteren van de potentiële risico-impact (kosten, schema, technisch of tijdschema) kan het inzicht in en de verklaring van het risico veranderen. Bijvoorbeeld, bij het beoordelen van een risico-impact van software schedule slip, de Risicoverklaring kan worden verfijnd om de need-by datum, en/of verdere verduidelijking van de impact (bijvoorbeeld, als de XYZ software niet wordt geleverd door Maart 2015, dan zal er niet voldoende tijd om de interface uitwisselingen te testen voorafgaand aan beperkte gebruiker Test).
neem de mitigatieverklaring niet op in de Risicoverklaring. Zorg ervoor dat u niet in de valkuil van het hebben van de mitigatieverklaring in de Risicoverklaring vallen. Een risico is een onzekerheid met mogelijk negatieve gevolgen. Sommigen komen snel tot de conclusie dat het risico moet worden beperkt en in plaats van het risico te identificeren dat moet worden beperkt (met opties voor mitigatie), identificeren zij het risico als een suboptimale ontwerpbenadering. Bijvoorbeeld, een Risicoverklaring zou kunnen zijn: als de aannemer XYZ niet gebruikt voor de test, dan zal de test mislukken. De zorg is eigenlijk testvoldoendheid. Als de opdrachtnemer de test niet met meetbare resultaten voor analyse uitvoert, kan het programma niet door de beperkte gebruikerstest slagen. Het gebruik van XYZ kan een mitigatieoptie zijn om het risico op toereikendheid van de test te verminderen.
stap niet naar een mitigatiestrategie voordat de risicowaarschijnlijkheid en-impact worden beoordeeld. Een risico kan worden verfijnd of gewijzigd na verdere analyse, die van invloed kan zijn op wat de meest efficiënte/gewenste mitigatie kan zijn. Ingenieurs springen vaak naar de oplossing; het is het beste om naar de volgende stap te gaan die in het artikel risicobeoordeling en prioritering wordt besproken om het probleem eerst te ontbinden en te begrijpen. Uiteindelijk zal dit leiden tot een strategie die nauw aansluit bij de zorg.
referenties & middelen
- The MITRE Institute, 1 September 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.U. S. Air Force, januari 2008, Air Force Past Performance Evaluation Guide (Ppeg), IG5315.305(a).U. S. Air Force, January 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
aanvullende referenties & middelen
MITRE E520 checklists van technische teams voor risicoanalyse en-beheer, risicocontroles, risicoanalyse en Beheersdocumenten.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK Guide), Fourth Edition, ANSI/PMI 99-001-2008, PP.273-312, geraadpleegd op 2 maart 2010.
SEPO, “Standard Process/Steps of Process, Step 2: Identify Risks & Hazards,” MITRE SEPO Risk Management Toolkit, geraadpleegd op 5 mei 2010.
