meghatározás: a Kockázatazonosítás olyan kockázatok meghatározásának folyamata, amelyek potenciálisan megakadályozhatják a programot, a vállalkozást vagy a befektetést a célok elérésében. Ez magában foglalja az aggodalom dokumentálását és közlését.
kulcsszavak: kockázat, kockázatazonosítás, kockázatkezelés
MITRE SE szerepek & elvárások: a kormányzati programokon dolgozó MITRE rendszermérnökök (SEs) várhatóan azonosítják azokat a kockázatokat, amelyek befolyásolhatják a projektet és a programot. Elvárják, hogy világos, egyértelmű és bizonyítékokkal alátámasztott kockázati nyilatkozatokat írjanak és értékeljenek .
háttér
a kockázat azonosítása az 1.ábrán bemutatott kockázatkezelési folyamat kritikus első lépése.
a kockázatazonosítás célja azoknak az eseményeknek a korai és folyamatos azonosítása, amelyek bekövetkezése negatív hatással lesz a projekt teljesítmény-vagy képességkimutatási céljainak elérésére. Ezek származhatnak a projekten belül vagy külső forrásokból.
többféle kockázatértékelés létezik, beleértve a programkockázat-értékeléseket, a befektetési döntést támogató kockázatértékeléseket, az alternatívák elemzését, valamint a működési vagy költségbizonytalanság értékelését. A kockázatazonosításnak meg kell egyeznie a kockázatalapú döntéshozatal támogatásához szükséges értékelés típusával. Az akvizíciós program esetében az első lépés a program céljainak és célkitűzéseinek azonosítása, ezáltal elősegítve a csapat közös megértését arról, hogy mi szükséges a program sikeréhez. Ez kontextust és korlátot ad a kockázatok azonosításának és értékelésének hatóköréhez.
kockázatok azonosítása a rendszermérnöki programban
több kockázati forrás létezik. A kockázat azonosításához a projektcsoportnak felül kell vizsgálnia a program hatókörét, a költségbecsléseket, az ütemtervet (beleértve a kritikus út értékelését), a technikai érettséget, a legfontosabb teljesítményparamétereket, a teljesítmény kihívásait, az érdekelt felek elvárásait a jelenlegi tervvel szemben, a külső és belső függőségeket, a megvalósítási kihívásokat, az integrációt, az interoperabilitást, a támogathatóságot, az ellátási lánc sebezhetőségét, a fenyegetések kezelésének képességét, a költségeltéréseket, a tesztesemények elvárásait, a biztonságot, a biztonságot stb. Ezenkívül a hasonló projektekből származó korábbi adatok, az érdekelt felekkel folytatott interjúk és a kockázati listák értékes betekintést nyújtanak a kockázat megfontolandó területeibe.
a kockázat azonosítása iteratív folyamat. A program előrehaladtával több információ nyerhető a programról (pl. egyedi tervezés), a Kockázati nyilatkozatot pedig úgy módosítják, hogy tükrözze a jelenlegi megértést. A projekt életciklusának előrehaladtával új kockázatokat azonosítanak.
bevált gyakorlatok és tanulságok
működési kockázat. Ismerje meg az Ön által támogatott képességek működési jellegét, valamint a végfelhasználókra, a küldetésükre és a képességek működésére jelentett kockázatot. Az operatív szükséglet/küldetés megértése (lásd a Systems Engineering Guide Koncepciófejlesztési témáját) segít megérteni a kockázatok súlyosságát és a végfelhasználókra gyakorolt hatását. Ez a kockázatelemzés kritikus részeannak a valós hatásnak a felismerése, amely akkor fordulhat elő, ha kockázat merül fel az operatív használat során. Általában az operatív felhasználók hajlandóak elfogadni bizonyos szintű kockázatot, ha képesek teljesíteni küldetésüket (pl. a küldetés biztosítása), de segítenie kell a felhasználókat az általuk elfogadott kockázatok megértésében, valamint a rendelkezésre álló lehetőségek, egyenlegek és alternatívák felmérésében.
technikai érettség. Munka és tőkeáttétel az ipar és a tudományos élet, hogy megértsék a technológiák fontolgatják erőfeszítés és a valószínű átmenet a technológia idővel. Az egyik megközelítés az, hogy együttműködnek a szállítókkal egy titoktartási megállapodás alapján, hogy megértsék a képességeket és hová mennek, hogy a kockázat értékelhető legyen.
nem Fejlesztési tételek (NDI). NDI magában foglalja a kereskedelmi-off-the-shelf és a kormány-off-the-shelf tételek. A kockázat kezelése érdekében vegye figyelembe az NDI szolgáltató életképességét. Van-e piaci részesedése a Szolgáltatónak? A Szolgáltató megfelelő élettartammal rendelkezik-e versenytársaihoz képest? Hogyan kezeli a szolgáltató a képességproblémákat, a kiadási javításokat stb.? Mi az adott NDI felhasználói bázisa? Be tudja-e mutatni a szolgáltató az NDI-t, lehetőleg az ügyféléhez hasonló környezetben? Használhatja-e a kormány az NDI-t prototípus létrehozására? Mindezek a tényezők segítenek felmérni az NDI és a Szolgáltató életképességének kockázatát. Keressen választ ezekre a kérdésekre más MITRE munkatársaktól, akik dolgoztak a területen, vagy felhasználták az értékelendő NDI-t.
beszerzési illesztőprogramok. Hangsúlyozza a kritikus képességeket lehetővé tevő tényezőket, különösen azokat, amelyek korlátozott alternatívákkal rendelkeznek. Értékelje és határozza meg az akvizíció elsődleges mozgatórugóit, és hangsúlyozza a kapcsolódó kockázatot a kockázatcsökkentési ajánlások megfogalmazásában. Ha egy képesség egy bizonyos aspektusa nem kritikus a siker szempontjából, akkor értékelni kell annak kockázatát, de nem kell, hogy ez legyen a kockázatkezelés elsődleges célja. Például, ha fennáll a javasolt felhasználói felület kockázata, de a piacnak számos alternatívája van, a javasolt megközelítés sikere valószínűleg kevésbé kritikus a képesség általános sikere szempontjából. Másrészt az információbiztonsági funkció valószínűleg kritikus. Ha csak egy alternatív megközelítés elégíti ki a szükségletet, hangsúlyt kell fektetni rá. Határozza meg az elsődleges siker mozgatórugóit az igények és tervek értékelésével, valamint a létező alternatívák meghatározásával. Egyedülálló megoldás a sikerhez vezető kritikus úton? Győződjön meg arról, hogy a kritikus út elemzése magában foglalja a teljes rendszermérnöki ciklust, és nem csak a fejlesztést (azaz a rendszerfejlesztés önmagában “szelet torta” lehet, de az aktív működési helyzetben történő fielding jelentős kockázatot jelenthet).
használja a képességfejlődést a kockázat kezelésére. Ha különleges követelmények vezérlik az egyedi fejlesztés miatt magas kockázatú képességek megvalósítását, a boríték szélén lévő teljesítményigények stb., a követelményeket meg kell vitatni a felhasználókkal kritikusságuk miatt. Előfordulhat, hogy a szükségletet el lehet halasztani, és a fejlesztési közösségnek fel kell mérnie, hogy a jövőben mikor lehet kielégíteni. Segítsen a felhasználóknak és a fejlesztőknek felmérni, hogy egy adott képességnek mekkora kockázatot (ütemezést és költséghatást) kell vállalnia a kevésbé kockázatos képességek gyorsabb megszerzéséhez szükséges követelményekkel szemben. Az ajánlások kidolgozása során vegye figyelembe a technikai megvalósíthatóságot és a kapcsolódó megvalósítási sikerek és kudarcok ismeretét, hogy felmérje a jövő helyett a most megvalósítás kockázatát. A képességek elhalasztásakor ügyeljen arra, hogy ne essen abba a csapdába, hogy elhalasztja a végső kudarcot a rövid távú könnyű sikerek kereskedelmével a több magas kockázatú követelmény jövője érdekében, amelyek elengedhetetlenek lehetnek az Általános sikerhez.
Fő Teljesítményparaméterek (KPPs). Szorosan működjön együtt a felhasználókkal a KPP-k létrehozása érdekében. A program törlésének általános kockázata a KPP-k teljesítésének elmulasztására összpontosulhat. Működjön együtt a felhasználókkal annak biztosítása érdekében, hogy a paraméterek megfeleljenek a küldetés igényeinek és műszakilag megvalósíthatók legyenek. A paramétereknek nem szabad olyan engedékenynek lenniük, hogy könnyen teljesíthetők legyenek, de nem elégíthetik ki a küldetés szükségletét; sem olyan szigorúaknak, hogy nem teljesíthetők kiterjedt erőfeszítés vagy toló technológia nélkülamelyek bármelyike veszélybe sodorhat egy programot. Keresse meg a múltbeli műveletek, kísérletek, teljesítményértékelések és ipari megvalósítások eredményeit a teljesítmény megvalósíthatóságának meghatározásához.
külső és belső függőségek. A vállalati perspektíva segíthet a felvásárlóknak, a programkezelőknek, a fejlesztőknek, az integrátoroknak és a felhasználóknak értékelni a fejlesztési erőfeszítések függőségéből eredő kockázatokat. A szolgáltatásorientált megközelítések megjelenésével a program egyre inkább függ a mások által nyújtott szolgáltatások elérhetőségétől és működésétől, amelyeket programjuk fejlesztési erőfeszítései során használni kívánnak. Együttműködés a szolgáltatások fejlesztőivel a minőségi szolgáltatások létrehozásának biztosítása érdekében, és a szolgáltatások karbantartása és fejlesztése is felmerült. Dolgozzon együtt a fejlesztési program munkatársaival, hogy értékelje a rendelkezésre álló szolgáltatásokat, azok minőségét és annak kockázatát, hogy egy program használja és támaszkodik a Szolgáltatásra. Hasonlóképpen, fennáll annak a kockázata, hogy a szolgáltatást létrehozzák, és nem használják a szolgáltatásokat egy másik vállalati erőfeszítésből. Segítsen meghatározni a fejlesztésen belüli szolgáltatás létrehozásának kockázatait és lehetséges előnyeit, esetleg a vállalati szolgáltatásra való áttéréssel egy későbbi időpontban.
integráció és interoperabilitás (I& I). I& szinte mindig jelentős kockázati tényező leszek. Ezek a függőségek olyan formái, amelyekben az integrálás vagy az interoperabilitás értékét úgy ítélték meg, hogy felülírja a benne rejlő kockázatokat. Az olyan technikák, mint az enterprise federation architektúrája, igény szerint összeállítható képességek és tervezési minták segíthetnek a kormánynak megtervezni és végrehajtani egy útvonalat az I&I kockázatokhoz való navigáláshoz. Az I&I kapcsolódó kockázatok kezelésére szolgáló technikákról szóló cikkeket a rendszermérnöki útmutató vállalati mérnöki részében találja.
információbiztonság. Az információbiztonság szinte minden fejlesztés során kockázatot jelent. Ennek egy része a kormányzati igények és követelmények egyediségének köszönhető ezen a területen. Ennek egy része a számítógépes támadások elleni küzdelemben rejlő nehézségeknek köszönhető. A támadások spektrumát lefedő védelmi képességek létrehozása kihívást jelent és kockázatos. Segítsen a kormánynak rugalmassági megközelítések kidolgozásában (pl. készenléti tervek, biztonsági mentés/helyreállítás stb.). A nemzetközi partnerekkel való koalíciós műveletek során a rendszerek közötti információmegosztás lehetővé tétele technikai kihívásokat és politikai kérdéseket vet fel, amelyek fejlesztési kockázatot jelentenek. Az ellátási lánc menedzsmenttel kapcsolatos információbiztonsági kérdések olyan tág és összetett, hogy még a fenyegetések kezdetleges tudatosságának fenntartása is óriási kihívás.
képzettségi szint. A fejlesztők, az integrátorok, a kormányzat és más érdekelt felek képzettségi vagy tapasztalati szintje kockázatokhoz vezethet. Vigyázzon az elégtelen készségekre, és érje el a vállalatot, hogy kitöltse a hiányosságokat. Ennek során segítsen oktatni a kormányzati csapat tagjait, ugyanakkor vállalati készségeket és tapasztalatokat hoz magával.
Költségkockázatok. A programok általában létrehoznak egy kormányzati költségbecslést, amely figyelembe veszi a kockázatot. A program technikai és egyéb kockázatainak fejlesztése és finomítása során a kapcsolódó költségbecsléseknek is fejlődniük kell. A költségbecslés nem egyszeri tevékenység.
korábbi információk, mint a kockázat azonosításának útmutatója. A hasonló kormányzati programokból származó történelmi információk értékes betekintést nyújthatnak a jövőbeli kockázatokba. Keressen információkat az operatív kihívásokról és kockázatokról a különböző műveleti tanulságokban, cselekvési jelentések, gyakorlati összefoglalók és kísérleti eredmények után. Az ügyfelek gyakran rendelkeznek ezek tárolóival a hozzáféréshez. A kormányzati vezetők általában kommunikálják stratégiai szükségleteiket és kihívásaikat. Értse meg és vegye figyelembe ezeket az ügyfelek által igényelt legfontosabb képességek értékelésében és a kockázatértékelések alapjaként.
a kockázatértékelést segítő korábbi adatok gyakran rendelkezésre állnak a múltbeli teljesítményértékelésekből, valamint a beszerzési programok és vállalkozók tanulságaiból. Sok esetben a MITRE munkatársai segítik a kormányt egy adott akvizíció teljesítményinformációinak elkészítésében. Az AF rendelkezik egy múltbeli teljesítményértékelési útmutatóval (PPEG), amely azonosítja a rögzítendő információk típusát, amelyek felhasználhatók a jövőbeni kormányzati források kiválasztásához . Ez az adattár segíthet háttérinformációt szolgáltatni a korábbi kihívásokról és arról, hogy hol merülhetnek fel újramind az adott fejlesztési tevékenység típusa, mind az egyes vállalkozók esetében.
számos műszaki értékelés áll rendelkezésre a forgalmazói termékekre vonatkozóan, amelyek segítségével meghatározható a különböző termékek kockázata és életképessége. Az eszközök értékelésének egyik MITRE-tárháza az elemzési eszköztár, amely útmutatást és tapasztalatot tartalmaz az analitikai eszközökről. Az ilyen erőforrások használata és mások keresése, akik prototípusokban és kísérletekben kipróbálták a termékeket és technikákat, segíthetnek felmérni egy adott erőfeszítés kockázatait.
Hogyan írjunk kockázatot-a legjobb gyakorlat . A Kockázati nyilatkozat megírásának legjobb gyakorlati protokollja a feltétel-ha-akkor konstrukció. Ez a protokoll szinte bármilyen környezetre tervezett kockázatkezelési folyamatokra vonatkozik. Felismerés, hogy egy kockázat természeténél fogva valószínűségi jellegű, és ha bekövetkezik, nem kívánt következményekkel jár.
mi a feltétel-ha-akkor konstrukció? A feltétel tükrözi a ma ismerteket. Ez az azonosított kockázati esemény kiváltó oka. Így a feltétel olyan esemény, amely bekövetkezett, jelenleg bekövetkezik, vagy biztosan bekövetkezik. A kockázati események olyan jövőbeli események, amelyek a jelen állapot miatt fordulhatnak elő. Az alábbiakban bemutatjuk ezt a protokollt.
a BA a jelen állapothoz kapcsolódó kockázati esemény. Fontos, hogy az If és a feltétel kettős legyen. Ha közösen vizsgáljuk, lehetnek olyan módszerek, amelyek közvetlenül beavatkozhatnak vagy orvosolhatják a kockázati esemény mögöttes gyökerét (állapotát), hogy ennek az eseménynek a következményei, ha bekövetkezik, már ne veszélyeztessék a projektet. Az If a Kockázati nyilatkozat valószínűségi része.
az akkor az a következmény vagy következmények összessége, amely hatással lesz a mérnöki rendszer projektjére, ha a kockázati esemény bekövetkezik. A feltétel-ha-akkor konstrukció példáját a 2. ábra szemlélteti.
ösztönzi a csapatokat a kockázatok azonosítására. Egyes kormányzati projektek és programok kultúrája elriasztja a kockázatok azonosítását. Ez azért merülhet fel, mert a kockázatok nyomon követésére, nyomon követésére és csökkentésére irányuló kockázatkezelési tevékenységeket terhesnek és haszontalannak tekintik. Ebben a helyzetben hasznos lehet beszélni a csapatokkal a kockázatok azonosításának előnyeiről és arról, hogy nem képesek mindezt fejben kezelni (pl., meghatározza a prioritást, kit kell bevonni, enyhítő intézkedéseket). Segítse a kormánycsapatokat egy olyan folyamat végrehajtásában, amely kiegyensúlyozza a menedzsment beruházásait a projekt eredményeinek értékével. Általában jó egyensúly érhető el, ha a projekt hatóköre, ütemezése és költségcéljai teljesülnek, vagy a cselekvési tervek sikeresen enyhítik, és a projektcsoport úgy véli, hogy a kockázatkezelési tevékenységek értéket nyújtanak a projekt számára. A csapatok közötti képviselet kötelező; a kockázatokat nem szabad egyénnek vagy szigorúan a rendszermérnöki csapatnak azonosítania (a fenti kockázati források áttekintése).
vegye figyelembe a szervezeti és környezeti tényezőket. A szervezeti, kulturális, politikai és egyéb környezeti tényezők, mint például az érdekeltek támogatása vagy a szervezeti prioritások, ugyanolyan vagy nagyobb kockázatot jelenthetnek egy projektre, mint a technikai tényezők önmagukban. Ezeket a kockázatokat azonosítani kell, és aktívan csökkenteni kell a projekt teljes élettartama alatt. Az enyhítési tevékenységek magukban foglalhatják a jogalkotási megbízások vagy vészhelyzeti változások nyomon követését, amelyek befolyásolhatják a program vagy a projekt küldetését, a szervezeti változásokat, amelyek befolyásolhatják a felhasználói igényeket vagy a képesség hasznosságát, vagy a politikai támogatás olyan változásait, amelyek befolyásolhatják a finanszírozást. Minden esetben mérlegelje a program kockázatát, és határozza meg az érdekelt felekkel folytatott megbeszélések cselekvési lehetőségeit. További információkért lásd a kockázatcsökkentési tervezés, végrehajtás és előrehaladás nyomon követése cikket.
az érdekelt felek bevonása a kockázat azonosításába. A projektek és programok általában több érdekelt féllel rendelkeznek, amelyek különböző kockázati dimenziókat hoznak az eredményekre. Ezek közé tartoznak az üzemeltetők, akiket eláraszthatnak az új rendszerek; a felhasználók, akik esetleg nem megfelelően képzettek vagy félnek a munkájuktól; a felügyelők, akik esetleg nem támogatják az új képességeket, mert úgy tűnik, hogy csökkentik tekintélyüket; és a politikai döntéshozók, akik a jogalkotási jóváhagyással és a költségekkel foglalkoznak. Ezenkívül fontos, hogy minden érdekelt fél, például a tanúsító és akkreditáló hatóságok, akik, ha véletlenül figyelmen kívül hagyják, jelentős kockázatokat jelenthetnek a program későbbi szakaszában. Az érdekelt felek nagyon tudatában lehetnek a különféle környezeti tényezőknek, például a függőben lévő jogszabályoknak vagy a politikai programtámogatásnak, amelyek kockázatot jelenthetnek egy projekt számára, amely ismeretlen a kormány vagy a MITRE projektcsoport számára. Az érdekelt feleket is be kell vonni a kockázatazonosítási folyamatba, hogy segítsenek ezeknek a kockázatoknak a felszínre kerülésében.
írjon egyértelmű kockázati nyilatkozatokat. A feltétel-ha-akkor formátum használata elősegíti a Kockázati nyilatkozat kommunikációját és értékelését, valamint az enyhítési stratégia kidolgozását. A kiváltó ok az a mögöttes feltétel, amely bevezette a kockázatot (pl. tervezési megközelítés lehet az oka), az If tükrözi a valószínűséget (pl. annak valószínűségének értékelése, hogy a Kockázati nyilatkozat If része bekövetkezik), és az ezután közli a hatást a programmal (pl. megnövekedett erőforrások a tesztelés támogatására, további ütemezés, valamint a teljesítmény elérésére való törekvés). Az enyhítési stratégia szinte mindig jobb, ha egyértelműen megfogalmazott kockázati nyilatkozaton alapul.
a kockázatértékelési és kockázatcsökkentési stratégia kidolgozása során várható a Kockázati nyilatkozat módosítása. Gyakori, hogy a kockázati nyilatkozatokat finomítják, amint a csapat értékeli a hatást. A potenciális kockázati hatás (költség, ütemterv, technikai vagy időkeret) értékelésekor és dokumentálásakor a kockázat megértése és kimutatása megváltozhat. Például a szoftveres ütemezés csúszásának kockázati hatásának értékelésekor a Kockázati nyilatkozat finomítható úgy, hogy tartalmazza az igény szerinti dátumot és/vagy a hatás további tisztázását (például ha az xyz szoftvert nem szállítják 2015 márciusáig, akkor nem lesz elegendő idő az interfész-cserék tesztelésére a korlátozott felhasználói teszt előtt).
ne vegye fel a kockázatcsökkentési nyilatkozatot a kockázati nyilatkozatba. Vigyázzon, ne essen abba a csapdába, hogy az enyhítő nyilatkozatot bevezették a kockázati nyilatkozatba. A kockázat egy potenciális negatív hatással járó bizonytalanság. Néhányan gyorsan a kockázat mérséklésének következtetéseire ugranak, és ahelyett, hogy azonosítanák az enyhítendő kockázatot (az enyhítési lehetőségek meghatározásával), a kockázatot az optimálistól elmaradó tervezési megközelítésként azonosítják. Például egy Kockázati nyilatkozat lehet: ha a Vállalkozó nem használja az XYZ-t a teszthez, akkor a teszt sikertelen lesz. Az aggodalom valóban teszt elegendő. Ha a Vállalkozó nem végzi el a tesztet mérhető eredményekkel elemzés céljából, akkor a program nem teljesítheti a korlátozott felhasználói tesztet. Az XYZ használata enyhítő lehetőség lehet a teszt elegendő kockázatának csökkentésére.
a kockázat valószínűségének és hatásának értékelése előtt ne ugorjon enyhítési stratégiára. A kockázat további elemzéssel finomítható vagy megváltoztatható, ami befolyásolhatja a leghatékonyabb/kívánt mérséklést. A mérnökök gyakran ugranak a megoldásra; a legjobb, ha a kockázati hatásvizsgálatban és a prioritási cikkben tárgyalt következő lépésre lépünk, hogy először lebontsuk és megértsük a problémát. Végső soron ez egy olyan stratégiához vezet, amely szorosan illeszkedik az aggodalomhoz.
hivatkozások & források
- a MITRE Intézet, szeptember 1, 2007, MITRE Systems Engineering (SE) kompetencia modell, Version 1, pp.10, 40-41.
- Garvey, P. R., 2008, analitikai módszerek a kockázatkezeléshez: rendszermérnöki perspektíva, Chapman-Hall/CRC-Press, Taylor & Francis Group (Egyesült Királyság), Boca Raton, London, New York, ISBN: 1584886374.Amerikai légierő, 2008. január, légierő múltbeli teljesítményértékelési útmutató(PPEG), IG5315.305 (A).
- amerikai légierő, 2008. január, légierő múltbeli teljesítményértékelési útmutató(PPEG), IG5315.305 (A).
további hivatkozások & források
MITRE E520 kockázatelemzés és menedzsment technikai csapat ellenőrző listák, Kockázatellenőrzések, kockázatelemzés és irányítási dokumentumok.
Projektmenedzsment Intézet, útmutató a projektmenedzsment Tudásanyagához (PMBOK útmutató), negyedik kiadás, ANSI/PMI 99-001-2008, 273-312.
SEPO, “Standard folyamat/a folyamat lépései, 2.lépés: kockázatok azonosítása & veszélyek,” MITRE SEPO kockázatkezelési eszköztár, hozzáférés május 5, 2010.
