Sidosryhmä

Sidosryhmä ( englanninkielinen  stakeholder ), myös kiinnostunut osapuoli , osallinen , työhön osallistuja , rooli hankkeessa  - henkilö tai organisaatio, jolla on järjestelmää tai sen ominaisuuksia koskevia oikeuksia, osuuksia, vaatimuksia tai etuja, jotka vastaavat heidän tarpeitaan ja odotuksiaan ( ISO / IEC / IEEE 15288:2015 [1] , ISO/IEC 29148:2011 [2] :6 ).

Muut määritelmät:

Sidosryhmät tarjoavat järjestelmälle mahdollisuuksia ja ovat järjestelmän vaatimusten lähde. [4] :14

Sidosryhmiä on aina yksi enemmän kuin tiedät, ja tuntemillasi on vähintään yksi tarve enemmän kuin nyt tiedät.

Tom Gilb ( englanniksi ) [7] .

Järjestelmäsuunnittelussa sidosryhmiä tarkastellaan päätöksentekoprosessin yhteydessä ihmisinä tai organisaatioina, jotka ovat riippuvaisia ​​tehtyjen päätösten tuloksista. Ymmärrys siitä, kuka on sidosryhmä tehtävissä päätöksissä, tulee selvittää etukäteen. Hyvin usein näin ei tapahdu – sidosryhmiä ei määritellä ennen päätösten tekemistä. Kuitenkin heti, kun päätös on julkistettu tai pantu täytäntöön, jokainen, johon päätös jollakin tavalla on vaikuttanut, ilmaisee mielipiteensä. [8] :258

A. I. Levenchukin mukaan sidosryhmien on tarkoituksenmukaista käyttää termiä "roolit hankkeessa" [9] .

Sidosryhmien suhde suunnitteluprojektin muihin kokonaisuuksiin

Kuvassa näkyy projektissa havaittujen pääkokonaisuuksien ja -objektien vuorovaikutus. Kohteet ryhmitellään yhteen kiinnostaviin alueisiin. Sidosryhmä kuuluu siis asiakkaan kiinnostusalueeseen , sillä  tämä alue sisältää kaiken järjestelmän käyttöön ja toimintaan liittyvän. [4] :13-14

Sidosryhmien tyypit (ryhmät)

Sidosryhmien tyypeistä (ryhmistä) ei ole tyhjentävää luetteloa, koska ne voivat vaihdella merkittävästi eri kohdejärjestelmissä. Voit antaa esimerkkejä yleisimmistä sidosryhmien tyypeistä (ryhmistä), jotka mainitaan standardeissa (GOST R ISO/IEC 15288:2005, ISO/IEC 29148:2011, GOST R ISO/IEC 12207:2010, OMG Essence), System Engineering Code of Knowledge ( SEBoK ) ja järjestelmätekniikan oppikirjat [8] :

Sidosryhmien tunnistaminen elinkaarivaiheittain

Jokaisella järjestelmällä on omat elinkaarivaiheensa , kuten konseptisuunnittelu , kehitys, tuotanto, toteutus, käyttö ja hävittäminen. Jokaista vaihetta varten määritetään luettelo kaikista tulevaan järjestelmään kiinnostuneista (suhde) sidosryhmistä. Tämän toiminnan tarkoituksena on ottaa huomioon kunkin sidosryhmän näkökulma järjestelmän elinkaaren kaikissa vaiheissa, jotta voidaan muodostaa täydellinen joukko sidosryhmien tarpeita, jotka voidaan priorisoida ja muuntaa sidosryhmien vaatimuksiksi. Esimerkkejä sidosryhmien suhteesta elinkaaren vaiheisiin on esitetty taulukossa 1.

Taulukko 1. Sidosryhmien määrittely järjestelmän elinkaaren vaiheiden mukaan [10] :262
Elinkaarivaiheet Esimerkkejä sidosryhmistä
Suunnittelu (suunnittelu, analyysi) Hankintayksikkö , potentiaaliset käyttäjät, markkinointiosasto , kehitysosasto , standardointielin , toimittajat , testausosasto ( varmennus ja validointi ), tuotantojärjestelmä jne.
Kehitys Ostaja, toimittajat, suunnittelijat, integraatiotiimi jne.
Siirto tuotantoon tai käyttöön Laadunvalvontaosasto, tuotantojärjestelmä, operaattorit jne.
Logistiikka ja tuki Tukipalvelut, ohjaajat, toimitusketjun osallistujat jne.
hyväksikäyttö Tavalliset käyttäjät, satunnaiset käyttäjät jne.
selvitystilaan Operaattorit, vahvistava elin jne.

Kirjanpidon aste ja sidosryhmien osallistuminen

OMG :n ehdotusten mukaan erotetaan kuusi tilaa, joissa projekti voi olla kirjanpidon, osallistumisen ja sidosryhmien tyytyväisyyden kannalta [4] :20-21 :

Projektin nykytilan arvioimiseksi kirjanpidon, osallistumisen ja sidosryhmien tyytyväisyyden kannalta ehdotetaan seuraavia tarkistuslistoja :

Taulukko 2. Sidosryhmien tarkistuslistat [4] :22-23
Osavaltio Ohjausluettelo
Määritelty

□ Kaikki sidosryhmät, joihin järjestelmän kehitys ja toiminta vaikuttaa tällä hetkellä tai tulevaisuudessa, on tunnistettu.
□ On sovittu, mitkä sidosryhmät ovat edustettuina. Huomioon otetaan ainakin ne sidosryhmät, jotka rahoittavat, käyttävät, tukevat ja ylläpitävät järjestelmää.
□ Sidosryhmien edustajien vastuut on määritelty.

Edustettuna

□ Sidosryhmien edustajat ovat sitoutuneet hoitamaan tehtävänsä.
□ Sidosryhmien edustajilla on valtuudet suorittaa tehtävänsä.
□ Sovittu lähestymistapa sidosryhmien edustajien yhteistyön varmistamiseksi.
□ Sidosryhmien edustajat tukevat ja kunnioittavat tiimin teknologiaa.

mukana

□ Sidosryhmien edustajat avustavat tiimiä tehtäviensä mukaisesti.
□ Sidosryhmien edustajat antavat palautetta ja osallistuvat päätöksentekoon oikea-aikaisesti.
□ Sidosryhmien edustajat viestivät nopeasti sidosryhmilleen tärkeistä muutoksista.

Yhteisymmärryksessä

□ Sidosryhmien edustajat sopivat vähimmäisodotuksista uuden järjestelmän tulevalle käyttöönotolle.
□ Sidosryhmien edustajat ovat tyytyväisiä osallistumiseensa työhön.
□ Sidosryhmien edustajat ovat yhtä mieltä siitä, että tiimi arvostaa ja kunnioittaa heidän panostaan ​​työhön.
□ Tiimin jäsenet ovat yhtä mieltä siitä, että sidosryhmien edustajat arvostavat ja kunnioittavat heidän panostaan ​​työhön.
□ Sidosryhmien edustajat sopivat, kuinka heidän prioriteettinsa ja näkemyksensä tasapainotetaan antaakseen tiimille selkeän suunnan.

Tyytyväinen käyttöönottoon (toteutus)

□ Sidosryhmien edustajat antavat palautetta sidosryhmiensä näkökulmasta.
□ Sidosryhmien edustajat vahvistavat, että järjestelmä on valmis käyttöönotettavaksi.

Tyytyväinen käyttöön

□ Sidosryhmät käyttävät uutta järjestelmää ja antavat palautetta kokemuksistaan.
□ Sidosryhmät vahvistavat, että uusi järjestelmä vastaa heidän odotuksiaan.

Sidosryhmien rooli hankkeiden organisatorisissa tukiprosesseissa

Organisaation projektituki koostuu organisaatioiden kyvystä toimittaa ja hankkia tuotteita ja palveluita tuen, provisioinnin ja projektinhallinnan avulla. Tämä määräys tarjoaa tarvittavat resurssit ja infrastruktuurin hankkeiden helpottamiseksi ja varmistaa, että organisaation tavoitteet ja olemassa olevat sopimukset täyttyvät. Se ei väitä olevan joukko liiketoimintaprosesseja, jotka muodostavat organisaation liiketoiminnan hallinnan. [yksitoista]

Sidosryhmien rooli projektisalkun hallinnassa

GOST R ISO/IEC 12207:2010 (ISO/IEC 12207:2008) -standardissa todetaan, että sopimusmuutosten hallintamekanismin tulee heijastaa johdon rooleja ja vastuita, ehdotettujen muutospyyntöjen virallistamistasoa ja lisäneuvotteluja sopimuksesta, sekä suhteet sidosryhmiin . [yksitoista]

Onnistuneen projektisalkun hallinnan tuloksena:

Sidosryhmien rooli laadunhallinnassa

Organisaation on tarkistettava säännöllisesti projektin laadunvarmistussuunnitelmia. Jokaiselle hankkeelle asetetaan erilaiset laatutavoitteet, jotka puolestaan ​​perustuvat sidosryhmien vaatimuksiin. [yksitoista]

Auditoinnin tarkoituksena on ylläpitää sidosryhmien kanssa yhteistä kehitysymmärrystä sopimuksen tavoitteista ja siitä, mitä tarkalleen on tehtävä, jotta tuote kehittyy sidosryhmiä tyydyttävällä tavalla. Revisioita sovelletaan sekä projektinhallintaprosessissa että teknisellä tasolla ja niitä tehdään koko projektin elinkaaren ajan. [yksitoista]

Sidosryhmien rooli riskienhallinnassa

Kaikki riskienhallintaprosessin osat tulee virallistaa ja dokumentoida. Riskienhallintaprosessin formalisointi ja dokumentointi sisältää kuvauksen riskiluokista, sidosryhmien näkökulmista sekä kuvauksen (mahdollisesti referenssinä) teknisistä ja hallinnollisista tavoitteista, oletuksista ja rajoituksista. On tarpeen luoda ja ylläpitää riskiprofiili, jonka jokaisen merkinnän tulee sisältää riskin merkitys. Tärkeys määräytyy sidosryhmien antamien riskikriteerien mukaan.

Asianomaisen riskiprofiilin luonteesta olisi tiedotettava säännöllisesti sidosryhmille heidän tarpeidensa perusteella, koska riskiprofiili voi muuttua, jos tietty riskitila päivitetään.

Sidosryhmien tulee tarjota suositeltuja riskinhoitovaihtoehtoja riskitoimia koskevissa vaatimuksissa. Jos sidosryhmät päättävät, että toimenpiteisiin on ryhdyttävä riskin tekemiseksi optimaaliseksi, tulee ottaa käyttöön vaihtoehtoinen riskikäsittely. Jos sidosryhmät hyväksyvät enimmäisarvon ylittävän riskin, tämä riski on pidettävä ensisijaisena prioriteettina ja sitä on seurattava jatkuvasti, jotta voidaan määrittää tarvittavat toimenpiteet sen ratkaisemiseksi. [yksitoista]

Sidosryhmien rooli teknisissä prosesseissa

Teknisten prosessien avulla muotoillaan vaatimuksia järjestelmälle, muokataan vaatimuksia tehokkaaksi tuotteeksi, joka mahdollistaa tarvittaessa tämän tuotteen kestävän uudelleentuotannon, käytetään sitä tarvittavien palvelujen tuottamiseen, ylläpidetään näiden palvelujen tarjontaa ja hävitetään. kun se poistetaan liikkeestä. [1] :19 Tekniset prosessit määrittelevät työn sisällön, joka mahdollistaa yrityksen ja hankkeen tavoitteiden puitteissa voittojen lisäämisen ja teknisten päätösten ja asianmukaisten toimenpiteiden toteuttamisen yhteydessä syntyvien riskien minimoimisen.

Sidosryhmien rooli vaatimusten määrittelyprosessissa

Ohjelmistojärjestelmän elinkaariprosessit -standardissa sidosryhmävaatimusten määrittelytehtävä on muotoiltu seuraavasti: määritellä järjestelmävaatimukset, joiden täyttämisellä voidaan varmistaa käyttäjien ja muiden sidosryhmien tarvitsemien palveluiden tuottaminen tietyssä sovellusympäristössä. Tämän prosessin avulla voit määrittää sidosryhmät tai sidosryhmäluokat, jotka liittyvät järjestelmään koko sen elinkaaren ajan. Lisäksi heidän tarpeitaan ja toiveitaan korostetaan. Prosessissa tarpeet ja toiveet analysoidaan ja muokataan yleisiksi sidosryhmien vaatimuksiksi, jotka kuvaavat järjestelmän toivottua käyttäytymistä vuorovaikutuksessa sovellusympäristön kanssa. Tätä sarjaa vasten jokainen tarjottu palvelu validoidaan sen varmistamiseksi, että järjestelmä täyttää täysin ilmoitetut vaatimukset. [yksitoista]

Sidosryhmävaatimusten määrittelyprosessin onnistuneen toteutuksen tulokset ovat:

Sidosryhmien tunnistamisprosessi voidaan muotoilla seuraavasti: Sellaisten sidosryhmien tai sidosryhmien tunnistaminen, jotka ovat kiinnostuneita järjestelmästä sen elinkaaren aikana. Jos suora kommunikointi ei ole mahdollista, valitaan sidosryhmien edustajat. [yksitoista]

Vaatimusten tunnistamisprosessi koostuu seuraavien tehtävien ratkaisemisesta:

  1. On tarpeen määrittää hankkeen sidosryhmien vaatimukset. Sidosryhmien vaatimukset voivat ilmetä tarpeiden, toiveiden, vaatimusten, odotusten tai rajoitusten muodossa. Ohjelmistotuotteiden laatustandardit kuvaavat tuotteen laatumallia ja laatuvaatimuksia, joilla on tärkeä rooli sidosryhmien vaatimusten määrittelyssä. [12] [13] Ostaja sekä käyttäjien mahdollisuudet voivat asettaa järjestelmään rajoituksia, jotka tulee ottaa huomioon sidosryhmien tarpeissa tarpeiden ja toiveiden ohella. Keskeisten sidosryhmien vaatimusten mittaamiseksi ja arvioimiseksi on suositeltavaa laatia suoritusindikaattoreita.
  2. Olemassa olevien organisatoristen ja teknisten ratkaisujen vuoksi järjestelmässä on rajoituksia. Suunnittelussa on määriteltävä järjestelmän rajoitukset.
  3. Toimintojen järjestys, liiketoimintaprosessit määritellään työskenaarioiden ja tukiskenaarioiden muodostamiseksi järjestelmäsovelluksen kannalta. Tämä on tarpeen tunnistamattomien vaatimusten tunnistamiseksi, toisin sanoen vaatimukset, joita sidosryhmät eivät ole muodollisesti määrittäneet. Toimintaskenaarioiden ja tukiskenaarioiden avulla analysoidaan järjestelmän käyttöehdot, jotka ovat välttämättömiä myöhempää suunnittelua varten.
  4. Toteutusvaiheessa on tarpeen ottaa huomioon järjestelmän käyttäjien kyvyt ja kyvyt ja sitä kautta asetetut rajoitukset.
  5. Suunnittelussa tulee ottaa huomioon järjestelmän käytön mahdolliset haitalliset vaikutukset ihmisten terveyteen ja turvallisuuteen. Tätä varten asetetaan tietyt vaatimukset terveydelle, turvallisuudelle, ympäristöolosuhteille, turvallisuudelle ja muille ominaisuuksille. [yksitoista]
Perustaso

Määritelmä tai tuote (järjestelmäversio), joka on virallisesti tarkistettu ja hyväksytty myöhemmin jatkokehityksen perustaksi ja jota voidaan muuttaa vain muodollisilla ja kontrolloiduilla muutosmenettelyillä. [3] :2 Käytetään usein "perusversiona", "hyväksyttynä versiona", "arkistoituna versiona".

Hankkeessa on tarpeen selvittää yhdessä sidosryhmien kanssa heidän vaatimustensa ilmaisun oikeellisuus. Tätä varten on välttämätöntä antaa kehittäjiltä palautetta sidosryhmille, jotta varmistetaan, että asetettavat vaatimukset ymmärretään oikein. On myös tarpeen keskustella ja päästä sopimukseen ristiriitaisista ja toteuttamattomista sidosryhmien vaatimuksista. Hankkeessa tulee kirjata sidosryhmien vaatimukset vaatimusten hallintaan soveltuvassa muodossa koko elinkaaren ajan ja sen jälkeen. Nämä tietueet muodostavat perustan sidosryhmien vaatimuksille ja tallentavat tietoa tarpeiden muutoksista ja niiden alkuperästä järjestelmän elinkaaren aikana.

Hankkeessa tulee jäljittää tarpeiden syntymisen lähde sidosryhmien vaatimuksista. Sidosryhmien vaatimukset käydään läpi elinkaaren keskeisissä päätöskohdissa sen varmistamiseksi, että tarpeiden muutokset huomioidaan. [11] Järjestelmän rajoitukset voivat johtua seuraavista syistä:

Muistiinpanot

  1. ↑ 1 2 3 4 5 6 7 ISO/IEC/IEEE 15288, 2015 .
  2. ↑ 1 2 3 4 ISO/IEC 29148, 2011 .
  3. ↑ 12 ISO/IEC 42010, 2011 .
  4. ↑ 1 2 3 4 5 6 7 OMG Essence, 2018 .
  5. ↑ PMBoK, 2013 .
  6. ↑ GOST R ISO 9000, 2015 .
  7. ↑ Tom Gilb . Kymmenen tehokkainta järjestelmätekniikan heuristiikkaa arkistoitu 7. maaliskuuta 2016 Wayback Machinessa
  8. ↑ 1 2 3 4 Järjestelmäsuunnittelun periaatteet ja käytännöt, 2011 .
  9. ↑ Levenchuk A. I. Systeemiajattelu: Oppikirja. - Boston-Uldingen-Kiova, 2019. - S. 152. - 534 s. — ISBN ISBN 978-1-62540-081-9 .
  10. ↑ 1 2 3 SEBOK, 2012 .
  11. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 GOST R ISO/IEC 12207, 2010 .
  12. ↑ ISO/IEC 9126-1, 2001 .
  13. ↑ ISO/IEC 25030, 2007 .

Kirjallisuus

Katso myös

Linkit