määritelmä: riskien tunnistaminen on prosessi, jossa määritetään riskejä, jotka voivat mahdollisesti estää ohjelmaa, yritystä tai sijoitusta saavuttamasta tavoitteitaan. Siihen kuuluu huolen dokumentointi ja siitä tiedottaminen.
avainsanat: riski, riskien tunnistaminen, riskienhallinta
MITRE SE roolit & odotukset: hallitusohjelmissa työskentelevien MITRE systems Engineersin (ses) odotetaan tunnistavan riskejä, jotka voivat vaikuttaa projektiin ja ohjelmaan. Niiden odotetaan kirjoittavan ja tarkastelevan riskilausuntoja, jotka ovat selkeitä, yksiselitteisiä ja joiden tueksi on esitetty näyttöä .
Tausta
riskien tunnistaminen on kuvassa 1 kuvattu riskienhallintaprosessin kriittinen ensimmäinen vaihe.
riskien tunnistamisen tavoitteena on sellaisten tapahtumien varhainen ja jatkuva tunnistaminen, jotka toteutuessaan vaikuttavat kielteisesti hankkeen kykyyn saavuttaa suoritus-tai valmiustavoitteet. Ne voivat tulla hankkeen sisältä tai ulkoisista lähteistä.
on olemassa monentyyppisiä riskinarviointeja, mukaan lukien ohjelman riskinarvioinnit, sijoituspäätöksen tueksi tehtävät riskinarvioinnit, vaihtoehtojen analysointi sekä toiminnan tai kustannusten epävarmuuden arviointi. Riskien tunnistamisen on vastattava arviointityyppiä, jota tarvitaan riskitietoisen päätöksenteon tueksi. Hankinta-ohjelman ensimmäinen askel on tunnistaa ohjelman tavoitteet ja tavoitteet, mikä edistää yhteistä ymmärrystä koko tiimin kanssa siitä, mitä tarvitaan ohjelman onnistumiseen. Tämä antaa asiayhteyden ja rajat riskien tunnistamiselle ja arvioinnille.
riskien tunnistaminen Systems Engineering Program
Riskilähteitä on useita. Riskien tunnistamiseksi hankeryhmän tulisi tarkastella ohjelman laajuutta, kustannusarvioita, aikataulua (sisältäen kriittisen polun arvioinnin), teknistä kypsyyttä, keskeisiä suorituskykyparametreja, suorituskykyhaasteita, sidosryhmien odotuksia vs. nykyinen suunnitelma, ulkoisia ja sisäisiä riippuvuuksia, täytäntöönpanohaasteita, integraatiota, yhteentoimivuutta, tuettavuutta, toimitusketjun haavoittuvuuksia, kykyä käsitellä uhkia, kustannuspoikkeamia, testitapahtumien odotuksia, turvallisuutta ja paljon muuta. Lisäksi vastaavista hankkeista saadut Historiatiedot, sidosryhmien haastattelut ja riskilistat antavat arvokasta tietoa riskien huomioon ottamisesta.
riskin tunnistaminen on iteratiivinen prosessi. Ohjelman edetessä saadaan lisää tietoa ohjelmasta (esim.erityinen suunnittelu), ja riskilausuntoa muutetaan vastaamaan nykyistä ymmärrystä. Uusia riskejä tunnistetaan hankkeen edetessä elinkaaren aikana.
Parhaat Käytännöt ja saadut kokemukset
operatiivinen riski. Ymmärrä tukemiesi valmiuksien operatiivinen luonne ja loppukäyttäjille aiheutuva riski, heidän tehtävänsä ja valmiuksien toiminta. Operatiivisen tarpeen/tehtävän ymmärtäminen (KS.Systems Engineering Guiden Konseptikehitysaihe) auttaa sinua ymmärtämään riskien vakavuuden ja niiden mahdollisen vaikutuksen loppukäyttäjiin. Tämä on kriittinen osa riskianalyysiä-ymmärtää reaalimaailman vaikutukset, joita voi tapahtua, jos riski syntyy operatiivisen käytön aikana. Tyypillisesti operatiiviset käyttäjät ovat valmiita hyväksymään jonkintasoisen riskin, jos he pystyvät suorittamaan tehtävänsä (esim.tehtävän varmennus), mutta sinun on autettava käyttäjiä ymmärtämään riskit, jotka he hyväksyvät, ja arvioimaan vaihtoehtoja, saldoja ja vaihtoehtoja.
tekninen erääntymisaika. Työskennellä ja hyödyntää teollisuuden ja korkeakoulujen ymmärtää teknologioita harkitaan vaivaa ja todennäköinen siirtyminen teknologian ajan. Yksi lähestymistapa on työskennellä salassapitosopimuksen alaisten myyjien kanssa, jotta he ymmärtäisivät valmiudet ja minne he ovat menossa, jotta riski voidaan arvioida.
Kehityshäiriöiset erät (NDI). NDI sisältää kaupallisia ja viranomaisluonteisia tuotteita. Riskien hallitsemiseksi on tarkasteltava NDI-tarjoajan elinkelpoisuutta. Onko palveluntarjoajalla markkinaosuutta? Onko palveluntarjoajalla riittävä pitkäikäisyys kilpailijoihinsa verrattuna? Miten palveluntarjoaja käsittelee valmiusongelmia ja julkaisukorjauksia jne.? Mikä on tietyn NDI: n käyttäjäkunta? Voiko palveluntarjoaja osoittaa NDI: n, mieluiten samanlaisessa ympäristössä kuin asiakkaasi? Voiko hallitus käyttää KRP: tä prototyypin luomiseen? Kaikki nämä tekijät auttavat arvioimaan riskiä NDI: n ja palveluntarjoajan elinkelpoisuudesta. Etsi vastauksia näihin kysymyksiin muilta MITREN työntekijöiltä, jotka ovat työskennelleet alueella tai käyttäneet arvioitavana olevaa NDI: tä.
Hankintakuljettajat. Korostakaa kriittisen toimintakyvyn mahdollistajia, erityisesti niitä, joilla on rajalliset vaihtoehdot. Arvioida ja määrittää ensisijaiset ajurit hankintaan ja korostaa niihin liittyvää riskiä laatiessaan riskinhallintasuosituksia. Jos jokin kyvykkyyden osa-alue ei ole kriittinen sen onnistumisen kannalta, sen riskejä olisi arvioitava, mutta sen ei tarvitse olla riskienhallinnan ensisijainen painopiste. Jos esimerkiksi ehdotettu käyttöliittymä on vaarassa, mutta markkinoilla on lukuisia vaihtoehtoja, ehdotetun lähestymistavan onnistuminen on todennäköisesti vähemmän kriittinen valmiuden kokonaismenestyksen kannalta. Toisaalta tietoturvaominaisuus on todennäköisesti kriittinen. Jos vain yksi vaihtoehto tyydyttää tarpeen, sitä on painotettava. Määritä ensisijainen menestys ajurit arvioimalla tarpeet ja mallit, ja määrittää vaihtoehtoja, jotka ovat olemassa. Onko ainutlaatuinen ratkaisu menestyksen kriittisellä tiellä? Varmista, että kriittiset polku-analyysit sisältävät koko järjestelmän suunnittelun syklin eikä vain kehitystä (eli järjestelmän kehittäminen sinänsä voi olla ”pala kakkua”, mutta fielding aktiivisessa operatiivisessa tilanteessa voi olla suuri riski).
käytä valmiuksien kehitystä riskien hallintaan. Jos erityisvaatimuksina ovat sellaisten valmiuksien toteuttaminen, jotka ovat korkean riskin omalaatuisen kehityksen, reunasuoritustarpeiden jne.vuoksi., vaatimukset olisi keskusteltava käyttäjien kanssa niiden kriittisyys. Voi olla, että tarvetta voidaan lykätä, ja kehitysyhteisön pitäisi arvioida, milloin se voidaan tulevaisuudessa tyydyttää. Auttaa käyttäjiä ja kehittäjiä arvioimaan, kuinka paljon riskejä (sekä aikataulu-ja kustannusvaikutuksia) tietyn valmiuden pitäisi ottaa vastaan vaatimuksia saada vähemmän riskejä valmiuksia aikaisemmin. Kun kehität suosituksiasi, ota huomioon tekninen toteutettavuus ja tieto toteutukseen liittyvistä onnistumisista ja epäonnistumisista arvioidaksesi toteutuksen riskiä nyt eikä tulevaisuudessa. Lykkääviä valmiuksia, varo lankeamasta ansaan lykätä lopullista epäonnistumista kauppaamalla lähiaikoina helppo onnistumisia tulevaisuudessa useita korkean riskin vaatimuksia, jotka voivat olla välttämättömiä yleistä menestystä.
Keskeiset Suorituskykyparametrit. Tehdä tiivistä yhteistyötä käyttäjien kanssa KPPs: n perustamiseksi. Yleinen riski Ohjelman peruuttamisesta voi olla keskittynyt kpps: n täyttämättä jättämiseen. Työskentele käyttäjien kanssa varmistaaksesi, että parametrit vastaavat tehtävän tarpeita ja ovat teknisesti toteutettavissa. Parametrit eivät saa olla niin lieviä, että ne voidaan helposti täyttää, mutta ne eivät saa täyttää tehtävän tarpeita; ne eivät myöskään saa olla niin tiukkoja, että niitä ei voida täyttää ilman laajaa ponnistelua tai teknologian tyrkyttämistäjoista kumpikaan voi vaarantaa ohjelman. Etsiä tuloksia aiemman toiminnan, kokeiluja, suorituskyvyn arviointeja, ja teollisuuden toteutukset auttaa määrittämään suorituskyvyn toteutettavuus.
ulkoiset ja sisäiset riippuvuudet. Ottaa yritys näkökulma voi auttaa hankkijoita, ohjelmien johtajat, kehittäjät, integraattorit,ja käyttäjät arvostavat riskejä riippuvuudet kehitystyön. Palvelukeskeisten lähestymistapojen myötä ohjelma tulee riippuvaisemmaksi muiden tarjoamien palvelujen saatavuudesta ja toiminnasta, joita he aikovat käyttää ohjelmansa kehitystyössä. Tee yhteistyötä palveluiden kehittäjien kanssa, jotta laadukkaat palvelut saadaan luotua, ja näiden palveluiden ylläpitoon ja kehittämiseen on panostettu. Työskentele kehitysohjelman henkilöstön kanssa arvioidaksesi saatavilla olevat palvelut, niiden laadun ja riskin, joka ohjelmalla on palvelun käytössä ja siihen luottamisessa. Samoin on olemassa riski, joka liittyy palvelun luomiseen ja toisen yrityksen palvelujen käyttämättä jättämiseen. Auttaa määrittämään riskit ja mahdolliset hyödyt luoda palvelun sisäisen kehityksen mahdollisesti siirtyminen yrityspalveluun joskus tulevaisuudessa.
integraatio ja yhteentoimivuus (i&I). I&tulen lähes aina olemaan merkittävä riskitekijä. Ne ovat riippuvuuksien muotoja, joissa integroinnin tai yhteistoiminnan arvon on katsottu ohittavan niihin liittyvät riskit. Tekniikat, kuten enterprise federation architecting, kompositable capabilities on demand, ja suunnittelumallit voivat auttaa hallitusta suunnittelemaan ja toteuttamaan reitin navigoimaan i&I riskit. KS.Systems Engineering Guide for articles on techniques for admitting I&I associated risks-julkaisun Enterprise Engineering-osio.
tietoturva. Tietoturva on riski lähes jokaisessa kehityksessä. Osa tästä johtuu valtion tarpeiden ja vaatimusten ainutlaatuisuudesta tällä alalla. Osa tästä johtuu kyberhyökkäysten torjunnan luontaisista vaikeuksista. Puolustuskyvyn luominen hyökkäysten kirjon kattamiseksi on haastavaa ja riskialtista. Auttaa hallitusta kehittämään häiriönsietokykyä koskevia lähestymistapoja (esim.valmiussuunnitelmat, varmuuskopiointi/elvytys jne.).). Järjestelmien välisen tiedon jakamisen mahdollistaminen koalitio-operaatioissa kansainvälisten kumppaneiden kanssa aiheuttaa teknisiä haasteita ja poliittisia kysymyksiä, jotka johtavat kehitysriskiin. Toimitusketjun hallintaan liittyvät tietoturvakysymykset ovat niin laajoja ja monimutkaisia, että alkeellisenkin uhkatietoisuuden ylläpitäminen on valtava haaste.
taitotaso. Kehittäjien, integraattoreiden, viranomaisten ja muiden sidosryhmien taito-tai kokemustaso voi johtaa riskeihin. Ole hakevat riittämättömät taidot ja tavoittaa koko yritys täyttää aukkoja. Näin, auttaa kouluttaa hallituksen tiimin jäseniä samalla tuot yritysten taitoja ja kokemusta kantaa.
Kustannusriskit. Ohjelmat luovat tyypillisesti hallituksen kustannusarvion, jossa otetaan huomioon riski. Kun kehität ja tarkennat ohjelman teknisiä ja muita riskejä, myös siihen liittyvien kustannusarvioiden pitäisi kehittyä. Kustannusarvio ei ole kertatoimi.
Historiatiedot oppaana riskien tunnistamiseen. Historiatiedot vastaavista hallitusohjelmista voivat antaa arvokasta tietoa tulevaisuuden riskeistä. Hae tietoa operatiivisista haasteista ja riskeistä erilaisista operatiivisista kokemuksista, toimintakertomusten, harjoitusyhteenvetojen ja kokeilutulosten jälkeen. Asiakkailla on usein näiden arkistot käytettävissään. Valtiojohtajat viestivät yleensä strategisista tarpeistaan ja haasteistaan. Ymmärrä ja ota nämä huomioon arvioidessasi asiakkaasi tarvitsemia tärkeimpiä valmiuksia ja riskinarviointien pohjana.
riskinarviointia helpottavia historiatietoja on usein saatavilla aiemmista suoritusarvioinneista ja hankintaohjelmista ja urakoitsijoista saaduista kokemuksista. Monissa tapauksissa MITREN henkilökunta auttaa hallitusta valmistelemaan suoritustietoja tiettyä hankintaa varten. AF: llä on PPEG-opas (Past Performance Evaluation Guide), jossa yksilöidään kerättävät tiedot, joita voidaan käyttää tulevissa hallituslähteiden valinnoissa . Tämä tietovarasto voi auttaa antamaan taustatietoa aiemmista haasteista ja niistä, joita niitä saattaa ilmaantua uudelleensekä tietyntyyppisen kehitystoiminnan että yksittäisten toimeksisaajien osalta.
myyjätuotteista on olemassa lukuisia teknisiä arviointeja, joiden avulla voidaan määrittää eri tuotteiden riski ja kannattavuus. Yksi Mitre-tietovarasto työkalujen arvioinneista on Analyysityökaluvaja, joka sisältää ohjeita ja kokemuksia analyyttisistä työkaluista. Tällaisten resurssien käyttäminen ja muiden, jotka ovat kokeilleet tuotteita ja tekniikoita prototyypeissä ja kokeissa, voivat auttaa arvioimaan tietyn työn riskejä.
miten riski kirjoitetaan — paras käytäntö . Parhaan käytännön protokolla riskilausunnon kirjoittamiseksi on ehto-Jos-sitten-konstruktio. Tätä protokollaa sovelletaan riskienhallintaprosesseihin, jotka on suunniteltu lähes mihin tahansa ympäristöön. Se on tunnustus siitä, että riski on luonteeltaan todennäköinen ja että sen toteutumisella on ei-toivottuja seurauksia.
mikä on ehto-Jos-niin konstruoida? Tila kuvastaa sitä, mitä nykyään tiedetään. Se on tunnistetun riskitapahtuman perimmäinen syy. Tila on siis tapahtuma, joka on tapahtunut, tapahtuu parhaillaan tai tapahtuu varmasti. Riskitapahtumat ovat tulevia tapahtumia, jotka voivat johtua vallitsevasta tilasta. Alla on esimerkki tästä pöytäkirjasta.
If on vallitsevaan tilaan liittyvä riskitapahtuma. On ratkaisevan tärkeää tunnistaa If ja ehto kahtena. Yhteisesti tarkasteltuna voi olla olemassa keinoja puuttua suoraan riskitapahtuman taustalla olevaan juureen (tilaan) tai korjata se siten, että tämän tapahtuman seuraukset, jos se tapahtuu, eivät enää uhkaa hanketta. Sijoitusrahasto on riskilaskelman todennäköinen osuus.
silloin on se seuraus tai seurausten joukko, joka vaikuttaa suunnittelujärjestelmäprojektiin, jos riskitapahtuma toteutuu. Esimerkki ehto-Jos-sitten konstruoida on kuviossa 2.
kannustaa tiimejä tunnistamaan riskit. Joissakin hallituksen hankkeissa ja ohjelmissa vallitseva kulttuuri estää riskien tunnistamisen. Tämä voi johtua siitä, että riskien seurantaan, seurantaan ja lieventämiseen liittyvät riskienhallintatoimet koetaan raskaiksi ja hyödyttömiksi. Tässä tilanteessa voi olla hyödyllistä puhua joukkueiden kanssa riskien tunnistamisen hyödyistä ja kyvyttömyydestä hallita kaikkea omassa päässä (esim., määrittää prioriteetti, kuka on oltava mukana, hillintätoimet). Avustaa hallituksen työryhmiä prosessin toteuttamisessa, joka tasapainottaa johdon investointeja ja hankkeen tuloksia. Yleisesti ottaen hyvä tasapaino saavutetaan, kun hankkeen laajuus, aikataulu ja kustannustavoitteet saavutetaan tai niitä lievennetään onnistuneesti toimintasuunnitelmilla, ja projektiryhmä uskoo riskienhallintatoimien tuovan hankkeelle lisäarvoa. Ryhmärajat ylittävä edustus on välttämätöntä; riskejä ei saa yksilöidä, eikä niitä saa tarkasti määrittää järjestelmätekniikkatiimi (katso yllä olevat riskilähteet).
tarkastellaan organisatorisia ja ympäristötekijöitä. Organisatoriset, kulttuuriset, poliittiset ja muut ympäristötekijät, kuten sidosryhmien tuki tai organisaation prioriteetit, voivat aiheuttaa hankkeelle yhtä suuren tai suuremman riskin kuin pelkät tekniset tekijät. Nämä riskit olisi tunnistettava ja niitä olisi aktiivisesti vähennettävä koko hankkeen keston ajan. Hillintätoimiin voisi kuulua lainsäädäntövaltuuksien tai hätätilanteiden muutosten seuranta, jotka saattavat vaikuttaa ohjelmaan tai hankkeen tehtävään, organisaatiomuutokset, jotka voivat vaikuttaa käyttäjien vaatimuksiin tai valmiuksien hyödyllisyyteen, tai muutokset poliittisessa Tuessa, jotka voivat vaikuttaa rahoitukseen. Ota kussakin tapauksessa huomioon ohjelmaan kohdistuva riski ja tunnista toimintavaihtoehdot sidosryhmien kanssa käytävää keskustelua varten. Lisätietoja on artikkelissa riskinhallinnan suunnittelu, toteutus ja edistymisen seuranta.
sisällytä sidosryhmät riskien tunnistamiseen. Projekteissa ja ohjelmissa on yleensä useita sidosryhmiä, jotka tuovat tuloksiin eri riskien ulottuvuuksia. Niihin kuuluvat operaattorit, jotka saattavat hukkua uusiin järjestelmiin; käyttäjät, joita ei ehkä ole koulutettu asianmukaisesti tai jotka pelkäävät työpaikkansa puolesta; valvojat, jotka eivät ehkä tue uusia valmiuksia, koska ne näyttävät vähentävän heidän arvovaltaansa; ja poliittiset päättäjät, jotka ovat huolissaan lainsäädännön hyväksymisestä ja kustannuksista. Lisäksi on tärkeää ottaa mukaan kaikki sidosryhmät, kuten sertifiointi-ja akkreditointiviranomaiset, jotka tahattomasti sivuutettuina voivat aiheuttaa merkittäviä riskejä myöhemmin ohjelmassa. Sidosryhmät voivat olla hyvin tietoisia erilaisista ympäristötekijöistä, kuten vireillä olevasta lainsäädännöstä tai poliittisesta ohjelmatuesta, jotka voivat aiheuttaa riskejä hankkeelle, jota hallitus tai MITRE-projektiryhmä ei tunne. Ota sidosryhmät mukaan riskien tunnistamisprosessiin, jotta nämä riskit saadaan selvitettyä.
Kirjoita selkeät riskilaskelmat. Condition-If-Then-formaatin käyttäminen auttaa viestimään ja arvioimaan riskilausuntoa sekä kehittämään lieventämisstrategian. Perussyy on taustalla oleva ehto, joka on ottanut käyttöön riskin (esim.suunnittelun lähestymistapa voi olla syy), If heijastaa todennäköisyys (esim., todennäköisyysarvio, että If-osa riskilausunnon tapahtuisi), ja sitten viestii vaikutus ohjelmaan (esim., lisääntynyt resursseja tukemaan testausta, lisäaikataulu, ja huoli suorituskyvyn täyttämiseksi). Lieventämisstrategia on lähes aina parempi, kun se perustuu selkeästi ilmaistuun riskilausumaan.
Riskilaskelmaan on odotettavissa muutoksia riskinarviointi-ja lieventämisstrategiaa kehitettäessä. On tavallista, että riskilausuntoja hiotaan, kun tiimi arvioi vaikutuksia. Arvioitaessa ja dokumentoitaessa mahdollista riskivaikutusta (kustannuksia, aikataulua, teknistä vaikutusta tai aikataulua) riskin ymmärrys ja selvitys voivat muuttua. Esimerkiksi arvioitaessa ohjelmiston aikataulusiirtymän riskivaikutusta riskilauseketta voidaan tarkentaa niin, että se sisältää päiväyksen tarpeen ja/tai lisäselvennyksen vaikutuksesta (esim.jos xyz-ohjelmistoa ei toimiteta maaliskuuhun 2015 mennessä, ei ole riittävästi aikaa testata rajapintavaihtoja ennen rajoitettua Käyttäjätestiä).
riskilaskelmaan ei sisällytetä lieventämislaskelmaa. Ole varovainen, ettet lankea siihen ansaan, että riskien vähentämistä koskeva lausuma sisällytetään riskilausuntoon. Riski on epävarmuus, jolla voi olla kielteisiä vaikutuksia. Jotkut tekevät nopeasti johtopäätöksen riskin lieventämisestä, ja sen sijaan, että he tunnistaisivat riskin, jota olisi vähennettävä (ja tunnistaisivat lieventämisvaihtoehdot), he toteavat riskin olevan huono Suunnittelumalli. Riskilauseke voisi olla esimerkiksi: jos urakoitsija ei käytä XYZ: ää testiin, testi epäonnistuu. Huolena on todella testin riittävyys. Jos urakoitsija ei suorita testiä mitattavilla tuloksilla analysoitavaksi, ohjelma ei välttämättä läpäise rajoitettua käyttäjätestiä. XYZ: n käyttö voi olla lieventävä vaihtoehto testin riittävyysriskin vähentämiseksi.
älä hyppää lieventämisstrategiaan ennen kuin arvioit riskin todennäköisyyden ja vaikutuksen. Riski voi tarkentua tai muuttua lisäanalyysin perusteella, mikä saattaa vaikuttaa siihen, mikä on tehokkain/halutuin riski. Insinöörit usein hypätä ratkaisu; se on parasta siirtyä seuraavaan vaiheeseen käsitellään Riskivaikutusten arviointi ja priorisointi artikkeli hajottaa ja ymmärtää ongelma ensin. Viime kädessä tämä johtaa strategiaan, joka on tiiviisti linjassa huolen kanssa.
References & Resources
- the MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Version 1, s.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.Yhdysvaltain ilmavoimat, tammikuu 2008, Air Force Past Performance Evaluation Guide(PPEG), IG5315.305 (a).
- U. S. Air Force, tammikuu 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
Lisäviitteet & resurssit
MITRE E520 riskianalyysi ja johtaminen teknisen ryhmän tarkistuslistat, Riskitarkastukset, riskianalyysit ja Johtamisasiakirjat.
Project Management Institute, a Guide to the Project Management Body of Knowledge, (PMBOK Guide), Fourth Edition, ANSI/PMI 99-001-2008, s.273-312, accessed March 2, 2010.
SEPO, ” Standard Process/Steps of Process, Step 2: Identify Risks & Hazards,” MITRE SEPO Risk Management Toolkit, accessed May 5, 2010.
