JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen

JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Versio: 1.2 5.10.2012 Julkaistu: 11.9.2009 Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto... 3 2 Soveltamisala... 4 3 Termit ja määritelmät... 4 4 Kehittämiskohteiden tunnistamisen aloittaminen... 5 4.1 Arkkitehtuurimenetelmän hyödyntäminen kehittämiskohteiden tunnistamisessa... 6 4.2 Nykytilan analyysi... 6 4.3 Tavoitetilan suunnittelu... 6 4.4 Toimeenpanon suunnittelu... 7 5 Nykytilan analyysi... 7 5.1 Analysoi nykytilan toiminta... 8 5.2 Listaa ja analysoi kehitystarpeet... 8 5.3 Selvitä taloudelliset tunnusluvut... 9 5.4 Nykytilan analysointivaiheen lopputulokset... 9 6 Tavoitetilan suunnittelu... 9 6.1 Tavoitetilan hahmotus, rajaaminen ja nykytila... 11 6.1.1 Määritä ja rajaa kehittämiskohteen laajuus... 11 6.1.2 Tunnista ja kokoa ohjaava tieto... 12 6.1.3 Määritä ylätason toimintalähtöinen visio... 12 6.1.4 Perusta projekti... 12 6.1.5 Vaiheen lopputulokset... 12 6.2 Tavoitetilan suunnittelu... 12 6.2.1 Analysoi kehittämisalueen ja kuvausten kohderyhmät... 13 6.2.2 Tee puuteanalyysi... 13 6.2.3 Kuvaa tavoitetilan palvelut ja palveluratkaisut... 13 6.2.4 Kuvaa tavoitetilan toimintamallit ja prosessit... 14 6.2.5 Kehitä toiminnan tavoitetilaa tarvittaessa... 16 6.2.6 Vaiheen lopputulokset... 16 6.3 Tavoitehyötyjen määrittely ja mittarien laadinta... 16 6.3.1 Määrittele tavoitehyödyt... 16 6.3.2 Laadi mittarit... 17 6.4 Tietoteknisten mahdollisuuksien ja rajoitusten määrittely... 18 6.4.1 Määrittele tietotekniikkaratkaisut... 18 1/29

6.5 Toiminnan kehittämismahdollisuuksien ja rajoitusten määrittely... 19 6.5.1 Määrittele toiminta- ja palveluratkaisut... 19 6.6 Tavoitetilan analyysit... 19 6.6.1 Tee riskianalyysi... 19 6.6.2 Tee tuottavuusvaikutusanalyysi... 21 6.6.3 Vaiheen lopputulokset... 22 6.7 Kehittämisvaihtoehtojen vertailu ja valinta... 22 6.7.1 Vertaile tavoitehyötyjä... 22 6.7.2 Vertaile toiminnallisia vaihtoehtoja... 23 6.7.3 Vertaile tietoteknisiä vaihtoehtoja... 23 6.7.4 Valitse toteutusvaihtoehto... 24 6.7.5 Vaiheen lopputulokset... 25 7 Tavoiteratkaisun kuvaaminen... 25 8 Toimeenpanon suunnittelu... 25 8.1 Tunnista kehitystarpeet ja projektit... 26 8.2 Tee kustannus- ja hyötyanalyysit... 26 8.3 Aseta laatutavoitteet... 27 8.4 Analysoi riskit... 27 8.5 Priorisoi kehitystarpeet... 27 8.6 Suunnittele kehittämispolku... 27 8.7 Tee alustava toimeenpanosuunnitelma... 27 8.8 Järjestä suunnitelmien katselmointi... 28 8.9 Esitä toimeenpanosuunnitelmat projektin sidosryhmille... 28 8.10 Toimeenpanosuunnitelman linkittäminen TTS-prosessiin... 28 8.11 Vaiheen lopputulokset... 28 9 Päätöksenteko ja dokumentointi... 28 9.1 Valmistuvat dokumentit... 29 10 Opastavat tiedot... 29 10.1 Liitteet... 29 2/29

1 Johdanto Tässä suosituksessa kuvataan menetelmä kehittämiskohteiden tunnistamiseksi ICT-palveluita kehitettäessä. Tämä suositus on osa ICT-palvelujen kehittäminen -suositussarjaa. Suosituksessa ohjataan valmistautumista toiminnan kehittämisprojektin tai tietojärjestelmähankinnan esiselvitysprojektiin. JHS 172 ICT-palvelujen kehittäminen: Esiselvitys -suositus täydentää tätä suositusta. Vaiheena suositus sijoittuu kokonaisarkkitehtuurin kuvauksen jälkeen, jossa on kuvattu organisaation koko toiminta, toiminnassa käytettävät tiedot ja järjestelmät sekä teknologiat ja kehittäminen kokonaisuutena. Organisaation kokonaisarkkitehtuurin kehittäminen on kuvattu JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen -suosituksessa. Tämä suositus käsittelee organisaation tietyn osan tai osien kehittämiskohteiden tunnistamista. Kuva 1 ICT-palvelujen kehittämisen vaiheet Kokonaisarkkitehtuuri on toiminnan prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. Kokonaisarkkitehtuuri pitää sisällään arkkitehtuurilinjaukset ja -kuvaukset, arkkitehtuurin hallintamallin sekä arkkitehtuurimenetelmän. Tässä suosituksessa kuvataan tarkemmin yksittäistä tai yksittäisiä kehittämiskohteita, jotka on todettu kokonaisarkkitehtuurin suunnittelun yhteydessä tai jollain sen suunnittelun iteraatiokierroksista. ICT-kehittämisprojekteissa ja -hankkeissa tulee huomioida lainsäädännön ja asetusten luomat vaatimukset kehittämiselle. Lisäksi kehittämisprojekteissa ja -hankkeissa tulee huomioida organisaation asettamat vaatimukset ja linjaukset arkkitehtuurin suhteen. Huomioitavaa on, että valittujen kehittämiskohteiden on oltava myös linjassa kokonaisarkkitehtuurin suhteen. ICT-kehittämisprojekti koostuu eri vaiheista, joita yleensä ovat esiselvitys, vaatimusmäärittely, hankinta, tekninen suunnittelu, toteutus, testaus sekä käyttöönotto. Tämän suosituksen kuvaamat tehtävät ja selvitykset suoritetaan ennen esiselvitys-vaihetta ja ne toimivat valmistavina toimenpiteinä ennen itse 3/29

kehittämishankkeen tai -projektin aloittamista. Huomioi, että kehittämistyö on iteratiivista ja paluu edellisiin vaiheisiin tarkentamaan määrittelyitä on suositeltavaa. Suuremman kehittämiskokonaisuuden suunnitteluvaihe kannattaa toteuttaa projektina. Pienemmissä kokonaisuuksissa kehittämisprojektin suunnittelu voidaan toteuttaa myös kevyemmällä menettelyllä. 2 Soveltamisala Suositus on tarkoitettu käytettäväksi julkisen hallinnon ICT-palvelujen kehittämisessä kehittämiskohteiden tunnistamisvaiheessa, ennen tietojärjestelmähankinnan esiselvityksen tekemistä. Suosituksessa ohjeistetut eri toimintavaiheet on kuvattu prosessinomaisena siirtymänä vaiheesta toiseen. 3 Termit ja määritelmät Tässä kappaleessa on kuvattu tälle suositukselle oleellisia termejä ja niiden määritelmiä. ASP Sovellusvuokrauspalvelun tarjoaja, Application Service Provider, tarjoaa asiakkaille tietojärjestelmän käyttöön palveluna verkon kautta. GAP-analyysi GAP-analyysi eli puuteanalyysi on menetelmä, jolla voidaan mm. verrata ja kuvata nykytilan ja tavoitetilan välistä eroa. järjestelmäkartta Järjestelmäkartta kuvaa yleensä organisaation järjestelmäkokonaisuutta halutusta näkökulmasta. Järjestelmäkartta voidaan kuvata myös esim. poikkihallinnollisten prosessien osalta tai muusta vastaavasta kokonaisuudesta. Järjestelmäkartassa järjestelmät sijoitetaan visuaaliseen kuvaan (karttaan) käyttäen apuna erilaisia karttapohjia, joilla esitetään haluttua näkökulmaa. Näkökulma voi olla esim. viraston järjestelmät toiminnallisen luokittelun mukaan tai osastojen mukaan tai järjestelmäalustan mukaan. Poikkihallinnollisissa kuvauksissa voidaan kuvata virastoittain tai toiminnallisen luokittelun mukaan. kokonaisarkkitehtuuri Kokonaisarkkitehtuuri on toiminnan, prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. Kokonaisvaltainen arkkitehtuurillinen lähestymistapa ICT:n (informaatio- ja kommunikaatioteknologia) haltuunottamiseksi ja hallinnoimiseksi. Malli, jossa tietotekninen varustus kuvataan ja huomioidaan osana (liike)toimintaa. palvelu Palvelulla tarkoitetaan toiselle osapuolelle tarjottua toiminnallista tai teknistä palvelua. Palvelu voidaan tarjota joko organisaation sisälle tai sen ulkopuolelle. palvelukuvaus Kuvaus, jossa palvelun toiminnallisuudet ja käyttötarkoitukset, yhteydet muihin palveluihin sekä palvelun elinkaari on kuvattu. palvelukartta Palvelukartta kuvaa visuaalisesti organisaation palvelut ja niiden yhteydet sekä vastuulliset tahot. SaaS Software as a Service, on vuokrattavaksi tehty ohjelmisto moniasiakasympäristöön. Ohjelmistoa käytetään 4/29

selainkäyttöliittymällä verkon yli ja sitä ei räätälöidä asiakaskohtaisesti. SWOT -analyysi SWOT-analyysi on nelikenttämenetelmä, jota käytetään strategian laatimisessa, sekä oppimisen tai ongelmien tunnistamisessa, arvioinnissa ja kehittämisessä. teknologia-arkkitehtuuri Kokonaisarkkitehtuurin näkökulma, jonka keskeinen tavoite on linjata ja rajata käytettävät tekniset vaihtoehdot, standardit ja rakenteet siten, että kokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita. tietoarkkitehtuuri Kokonaisarkkitehtuurin näkökulma, joka kuvaa informaation rakenteistamista, organisointia ja luokittelua, välitystä. Arkkitehtuurissa tarkastellaan organisaation informaatiotarpeita, tietopääomaa, tietojen välisiä suhteita, informaatioarvoketjuja, tietojen rakenteita sekä informaation organisointia ja hallintaa. Tarkoituksena on luoda organisaatiotasoinen yhteinen näkemys keskeisestä tietopääomasta ja helpottaa informaation löytämistä, välittämistä ja hallintaa. tietojärjestelmäarkkitehtuuri Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation keskeiset järjestelmät sekä niiden arvioidun elinkaaren, kriittisyyden, niiden käyttämät/tuottamat tiedot ja suhteet muihin järjestelmiin. Organisaation järjestelmäpääoma. toiminta-arkkitehtuuri Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation strategisiin vaatimuksiin liittyvää ydintoimintaa ja sitä tukevia tukiprosesseja, resursseja sekä palvelutarjontaa. Myös tunnetaan termillä liiketoiminta-arkkitehtuuri (business architecture). toimintaympäristö Toimintaympäristöllä tarkoitetaan sitä ympäristöä, joka koostuu organisaation toimialan, asiakkaiden ja sidosryhmien toimijoista ja tarjotuista palveluista ja toiminnallisuuksista. 4 Kehittämiskohteiden tunnistamisen aloittaminen ICT-palvelujen kehittäminen ja kehittäminen yleensäkin edellyttää tietoja nykytilasta, jotta tiedetään lähtötilanne ja toisaalta käsitystä tavoitetilasta, eli päämäärästä, johon ollaan menossa. Oleellista on myös tietää, minkälaisessa ympäristössä toimitaan. Ennen kuin kehittämiskohteiden tunnistaminen voidaan aloittaa, tulee olla siis käytettävissä vähintään seuraavat dokumentit: organisaation strategia. organisaatiokaavio. organisaation talous- ja toimintasuunnitelma tai vastaava suunnitelma. organisaation nykytilan ja tavoitetilan kokonaisarkkitehtuurikuvaukset (kts. JHS 179 -suositus). Olennaista kehityskohteiden tunnistamisen jälkeen tapahtuville mahdollisille kehittämishankkeille ja -projekteille on, että kohdealueen prosessi(e)n omistaja(t) ohjaavat kehittämistyötä ja osallistuvat määrittelyihin. 5/29

4.1 Arkkitehtuurimenetelmän hyödyntäminen kehittämiskohteiden tunnistamisessa Johdannossa kuvattua kokonaisarkkitehtuurimenetelmää (kts. JHS 179 -suositus) käytetään tässä suosituksessa kehittämiskohteiden tunnistamisen työkaluna ja apuvälineenä. Arkkitehtuurimenetelmän malleja käyttämällä pyritään mahdollisimman kokonaisvaltaiseen ja eri osa-alueet huomioivaan tarkasteluun sekä kehittämiskohteiden ja projektien yhdenmukaiseen dokumentaatioon. ICT-palvelujen kehittämisen näkökulmasta kehittämisellä on kolme päävaihetta: 1. nykytilan analyysi 2. tavoitetilan suunnittelu 3. toimeenpanon suunnittelu. Kaikkia näitä vaiheita ei välttämättä toteuteta yhdessä projektissa tai kehittämishankkeessa. Esimerkiksi pelkästä nykytilan analysoinnista voidaan muodostaa itsenäinen kehittämisprojekti. Jo tällöin voidaan tunnistaa joitakin kehittämiskohteita erityisesti tarkastelemalla harmonisointimahdollisuuksia. Toiminnan uudistumisen kannalta merkittävämmät kehityskohteet tunnistetaan verrattaessa tavoitetilaa nykytilaan. Seuraavassa on kuvattu lyhyesti eri päävaiheiden tarkoitus sekä tässä suosituksessa käytettävät menetelmät vaiheen toteuttamiseksi. 4.2 Nykytilan analyysi Nykytilan analyysi keskittyy usein yhteen kokonaisarkkitehtuurin näkökulmaan, useimmiten toiminnan kehittämiseen eli toiminta-arkkitehtuurinäkökulmaan. Muita näkökulmia ovat tieto-, tietojärjestelmä- sekä teknologia-arkkitehtuurit. Nykytilan analyysissa huomioidaan kaikki ko. näkökulmaan keskeisesti liittyvät toiset näkökulmat. Esimerkiksi tietoarkkitehtuurin nykytilaa analysoitaessa tulee huomioida niin prosessit kuin järjestelmätkin, joissa informaatiota hyödynnetään. Nykytilan analyysi perustuu olemassa olevaan toimintaan ja siinä kartoitetaan esimerkiksi olemassa olevat tietojärjestelmät, teknologiat tai informaatio. Mukaan voidaan ottaa valmiiksi määriteltyjä, lähitulevaisuudessa toteutettavia kokonaisuuksia, mikäli oleelliset asiat on niissä jo päätetty ja lyöty lukkoon. Lähestymistapa nykytilan kuvaamisessa on siten alhaalta ylös, eli fyysisestä näkökulmasta käsitteelliseen. Vaikka nykytilan lähtökohta onkin olemassa oleva todellisuus, voidaan sitä kuvata monella eri tarkastelutasolla. Kokonaisarkkitehtuurin edellyttämä kokonaisuuden hallinta edellyttää yleensä yksityiskohtaista tasoa abstraktimmalla tasolla olevia kuvauksia. Nykytilan analyysin pohjatietona käytetään mm. nykytilan prosessien sekä palveluiden ja palvelurakenteen kuvaamista, organisaatio- ja sidosryhmäkarttaa sekä tarvekartoitusta, joiden tekeminen on kuvattu JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen -suosituksessa. Esimerkki tarveluettelosta löytyy myös liitteestä 1 Tarveluettelo. 4.3 Tavoitetilan suunnittelu Tavoitetilan suunnittelussa määritellään tavoitetila sekä toiminnalle että järjestelmille, joita käytetään toiminnan tukena, kuten myös palveluille ja palveluratkaisuille. Tavoitetilan suunnittelussa edetään lähtökohtaisesti suuremmista kokonaisuuksista pienempiin kokonaisuuksiin. Käsitteelliseltä tasolta edetään kohti käytännön toteutusmallia. Tavoitetilaa ei kuitenkaan voida suunnitella täysin irrallaan olemassa olevista ratkaisuista, vaan nykytila on huomioitava lähtökohtana 6/29

ja mahdollisena rajoittavana tekijänä, joka on huomioitava vähintään kehittämissuunnitelman aikataulutuksissa. Tavoitetilan suunnittelussa hyödynnetään nykytilan kuvausten lisäksi tässä suosituksessa kuvattuja tavoitetilan prosessien ja palveluiden/palveluratkaisujen kuvauksia, tavoitehyötyjen arviointia, tietoteknisten mahdollisuuksien arviointia sekä kehittämisvaihtoehtojen vertailua (luku 6 Tavoitetilan suunnittelu sekä JHS 179 -suositus). 4.4 Toimeenpanon suunnittelu Toimeenpanon suunnitteluvaiheessa suunnitellaan (kokonaisarkkitehtuurin) tavoitetilan vaatimat kehitysprojektit, arvioidaan niiden hyödyt ja riskit sekä välitetään tulokset kehitysprojektin sidosryhmille (kts. luku 8 Toimeenpanon suunnittelu). Tässä vaiheessa hyödynnetään valitun kehittämisvaihtoehdon tavoitetilaa koskevia määrityksiä sekä tarkennetaan jo tehtyjä kustannus-, hyöty- ja riskianalyysejä, priorisoidaan kehitystarpeet sekä suunnitellaan kehityspolku kohteena olevalle osa-alueelle. Edellä mainittujen toimintojen suorittaminen on kuvattu tässä suosituksessa (kts. luvut 5-7). 5 Nykytilan analyysi Nykytilan analyysivaiheessa analysoidaan nykytilan toimintaa, selvitetään nykytilan kehittämistarpeita sekä selvitetään taloudellisia tunnuslukuja käsittelyssä olevan kehittämisalueen tai alueiden kohdalla. Kuva 2 Nykytilan analysoinnin vaiheet 7/29

5.1 Analysoi nykytilan toiminta Tässä vaihessa hyödynnetään JHS 179 Kokonaisarkkitehtuurin kehittäminen -suosituksen mukaan laadittuja nykytilan kuvauksia. Analysoi niiden pohjalta nykytilan toimintaa ja kerää kehitystarpeita käyttäen hyväksi pääasiassa tehtyjä prosessi-, sidosryhmä- ja palvelukuvauksia. Analysoi nykytila myös muista arkkitehtuurinäkökulmista (tieto-, tietojärjestelmä- ja teknologia-arkkitehtuurit). Tarpeen/ongelman analysoimiseksi on edellä mainittujen kuvausten lisäksi hyvä käyttää tarvittaessa erilaisia ongelmanratkaisu- ja määrittelymenetelmiä. Näitä menetelmiä ovat esim. SWOT-analyysista erityisesti osat Strengths ja Weaknesses nykytilan vahvuuksien ja heikkouksien arviointiin. toiminnan ja prosessien simulaatiot ja ns. pöytätestaus eli prosessien läpikulku ja kehittämiskohteiden ja muutosmahdollisuuksien alustava hakeminen kuvausten kautta. Mind Map, ns. kalanruototekniikka tai seinätaulutekniikka, joilla pyritään varmistamaan että kaikki kehittämiskohteen osa-alueet tulevat huomioiduksi. riskianalyysi. kustannus-/hyötyanalyysi organisaation omasta ja yhteiskunnallisesta tarkastelukulmasta. tietoturvallisuuden kartoitus eri näkökulmista (mm. järjestelmät, tilat, henkilöstö). tilastojen läpikäynti, kuten organisaation toiminnan tulostilastot ja toimintakertomukset. 5.2 Listaa ja analysoi kehitystarpeet Kerää kehitystarpeet kehittämiskohteena olevan osa-alueen eri osapuolilta. Pyri keräämään lopputulosten käyttäjien ja hyödyntäjien tarpeet. Käyttäjillä ei tarkoiteta pelkästään mahdollisen tulevan tietojärjestelmän käyttäjiä, vaan hankkeen / projektien tulosten hyödyntäjiä koko laajuudessaan, mukaan lukien tarvittaessa myös organisaation ulkoiset sidosryhmät. Listaa käyttäjiltä sekä nykytilan analysoinnin lopputuloksena saadut kehitystarpeet taulukkoon. Kullekin tarpeelle kirjataan tunnus ja nimi. kuvaus. ketä tarve koskee. miten ja mihin vaikuttaa. tarpeen ratkaisemisen hyödyt. Eri käyttäjätahojen osallistuminen selvitystyöhön on välttämätöntä myös lopputuloksen hyväksyttävyyden kannalta. Keskeinen onnistumiskriteeri tarpeiden keräämisessä on riittävä kattavuus. Tämän vuoksi eri käyttäjä- /hyödyntäjäryhmienkin edustus on myös oltava kattavaa. Huomioi tarpeiden keräämisen yhteydessä myös mahdolliset kehittämisalueella meneillään olevat muut hankkeet / projektit. Analysoi listatut tarpeet. Keskity analysoinnissa mm. tarpeiden relevanttiuteen, ts. liittyvätkö tarpeet selkeästi selvityksen alla olevaan kehittämisalueeseen vai onko ne mahdollista / järkevää toteuttaa jossakin muussa hankkeessa. tarpeen taustojen selvittämiseen, jolla pyritään varmistamaan mm. se, että tarve on todellinen ja kaikilta osiltaan perusteltu. tarpeellisuuteen / välttämättömyyteen, ts. tehdään tarpeiden priorisointia jo tässä vaiheessa ei vielä rajauksia. 8/29

tarpeiden päällekkäisyyteen ja yhdenmukaisuuteen. Mahdolliset ristiriitaiset tarpeet pyritään selvittämään, selkiinnyttämään ja tarvittaessa karsimaan jo tässä vaiheessa. Käytä apuna tarvelistausta (= alustava vaatimusluettelo), johon merkitset analyysin tulokset, esim. onko tarve relevantti ja onko se tarpeen ratkaista mahdollisimman pian vai vasta myöhemmin. 5.3 Selvitä taloudelliset tunnusluvut Kokoa käytettävissä olevat nykytilan taloudelliset tunnusluvut. Tunnuslukuja ovat esimerkiksi nykytilan toiminnan hinnat ja volyymit sekä arvio hintojen ja volyymien kehittymisestä tulevaisuudessa. työn tunnusluvut, kuten manuaalisen työn kustannukset ja mahdolliset henkilötyövuosien säästötarpeet. henkilöstön motivaation, työn laadun ja työn tehokkuuden kasvu toiminnan kehittämisen kautta. Taloudellisia tunnuslukuja käytetään pohjatietona tavoitetilan hyötyjen määrittelyvaiheessa. 5.4 Nykytilan analysointivaiheen lopputulokset Nykytilan analysointivaiheen lopuksi nykytilan kuvaukset on tuotettu ja dokumentoitu riittävän tarkalla ja kattavalla tasolla ja tulosten perusteella on tehty arvio suunnittelun jatkamisen edellytyksistä. Dokumentoituja osa-alueita ovat palvelukuvaukset. palveluihin liittyvät (niitä tuottavat tai mahdollistavat) tietojärjestelmät. toimintamallit ja organisaatiot ja sidosryhmät. nykyprosessien kuvaukset. prosessien analysointien tulokset. arkkitehtuurien kuvaukset. järjestelmäkuvaukset nykytilan mahdolliset kehittämistarpeet huomioiden eri arkkitehtuuri-näkökulmat. selvitykset taloudellisista tunnusluvuista analyysien tuloksena syntyneet ja/tai tiedossa olevat priorisoidut nykyjärjestelmän ja nykytoiminnan kehittämistarpeet. 6 Tavoitetilan suunnittelu Tavoitetilan suunnittelussa pyritään mahdollisimman kokonaisvaltaiseen ja kattavaan näkemykseen siitä, mikä on se tavoitetila ja tavoiteltavat hyödyt, mitkä kohdealueen kehittämisellä saavutetaan tai on mahdollista saavuttaa. 9/29

Kuva 3 Tavoitetilan suunnittelun vaiheet Tavoitetilan suunnittelu toteutetaan iteratiivisesti, toisin sanoen edetään systemaattisesti vaiheesta toiseen mutta informaation ja näkemyksen karttuessa palataan tarvittaessa mihin tahansa edeltävään vaiheeseen. Paluu edeltävään vaiheeseen tulee olla kuitenkin perusteltua eli kullekin paluumenettelylle täytyy löytyä selkeä tarve ja päätös. Esimerkiksi riskianalyysin tai muun analyysin tulosten perusteella on tarpeen palata tarkentamaan joitakin osaalueita. kehittämisvaihtoehtojen vertailussa joku ratkaisumalli näyttää osoittautuvan selkeästi paremmaksi, jos sen osalta voidaan tehdä tarkennuksia palveluratkaisuihin, prosesseihin, tietojärjestelmiin tms. 10/29

Kuva 4 Tavoitetilan määrittely iteratiivisena toteutustapana 6.1 Tavoitetilan hahmotus, rajaaminen ja nykytila Syötteinä tavoitetilan hahmottamisessa, sen rajaamisessa ja nykytilaan vertaamisessa ovat mm. toiminnan kehittämisen tavoitteet ja strategiat. organisaation ja organisaatiota ylemmän tason (kokonais)arkkitehtuurin nykytila ja tavoitetilakuvaukset. nykytilan kuvausten ja analyysien sekä tarpeiden tarkennuksien ja analyysien tulokset. taloudellisten tunnuslukujen selvitysten tulokset. Vaiheen tarkoituksena on tunnistaa ja hahmottaa toiminnan tulevaisuuden tavoitetila. varmistaa toiminnan ja ICT-johdon tuki. rajata ja suunnitella kehittämisprojekti rinnakkaiset kehitysprojektit huomioiden. tunnistaa kehittämiseen vaikuttava olemassa oleva kokonaisarkkitehtuurin sisältö. tunnistaa kehittämisen sidosryhmät ja heidän tavoitteensa. tunnistaa alustavasti sekä toiminnan että toiminnassa käytettävien järjestelmien liittymät. hahmottaa siirtymäaikaan liittyvät tekijät ja toimintamallit, analysoida toiminnan kehittämistarpeet ja vaikutukset eri osapuolten näkökulmasta sekä analysoida kehittämisen perustelut toiminnan näkökulmasta. perustella suunnitteluvisio. 6.1.1 Määritä ja rajaa kehittämiskohteen laajuus Määritä kehittämisalueet ja tee tarvittavat rajaukset. Arvioi, aiheuttaako kehittämisen kohteena oleva alue muuttamis- tai kehittämistarpeita myös siihen liittyvissä osa-alueissa. Huomioi tässä vaiheessa myös siirtymäaikaan liittyvät tekijät, kuten toimintamallit, kustannukset ja mahdolliset haitat. 11/29

6.1.2 Tunnista ja kokoa ohjaava tieto Tunnista, mitä periaatteita, ohjeistuksia, vaatimuksia ja kuvauksia on huomioitava ohjaavana tietona. Huomioi olemassa olevat nykytila- ja tavoitetilakuvaukset. Varmista, että ko. dokumentaatio on käytettävissä tulevissa vaiheissa. Arvioi, ovatko nykytilatiedot riittäviä ja ajantasaisia. Mikäli tiedot ovat puutteellisia, varaa suunnitteluvaiheeseen aikaa nykytilatietojen täsmentämiseen. Arvioi riskit, mikäli nykytilatietojen täsmentäminen ei ole ajallisesti tai resurssien näkökulmasta mahdollista. 6.1.3 Määritä ylätason toimintalähtöinen visio Kuvaa tarvittaessa ylätason toimintalähtöinen visio organisaation asettamien reunaehtojen puitteissa. Vision kuvaaminen on tarpeen, mikäli kehittämiskohde on iso ja kehittämisen seurauksena tehtävää muutosta ei ole kuvattu kokonaisuutena tai kehittämisen perusteluja ei ole mietitty toiminnan näkökulmasta. Toiminnan visio kuvaa kehittämisen johdon näkökulmasta. 6.1.4 Perusta projekti Mikäli kehittämiskohteiden tunnistamisen vaiheet suoritetaan projektina, suunnittele projekti tämän suosituksen vaiheet huomioiden tai tarkenna olemassa olevaa projektisuunnitelmaa. Analysoi projektin riskit ja ilmoita aikatauluun tai lopputulokseen liittyvistä riskeistä kehittämisen johtamisesta vastaavalle tasolle. Tunnista kehittämiseen liittyvät sidosryhmät ja heidän tarpeensa. Huomioi myös liittymät ja rajapinnat toimintaprosessien ja mahdollisten toiminnan tukena käytettävien järjestelmien kannalta. Varmista sidosryhmien hyväksyntä ja tuki. Mikäli projektin perustaminen on kehittämisalueen kannalta tarpeetonta, tämä vaihe voidaan jättää väliin. Tavoitetilan määrittelyn lopputulosten kirjaamiseen on tällöin kiinnitettävä erityistä huomiota. Tässä JHS-suosituksessa kuvattujen kehittämiskohteiden tunnistamisen vaiheiden perusteella aloitettavat kehittämisprojektit suunnitellaan luvussa 8 Toimeenpanon suunnittelu kuvatun prosessin mukaisesti. 6.1.5 Vaiheen lopputulokset Tavoitetilan hahmotus ja rajausvaiheen lopputulokset ovat: lista suunnittelussa tarvittavista olemassa olevista kuvauksista. alustava kehittämis- tai projektisuunnitelma. ylätason toimintalähtöisen vision skenaariokuvaus. päivitetyt tarpeet. alustava suunnitelma perustettavasta kehitysprojektista tai -hankkeesta. 6.2 Tavoitetilan suunnittelu Tavoitetilan suunnitteluvaiheessa määritellään tarkemmin tavoitetilan palvelut ja palveluratkaisut sekä toimintamallit ja prosessit käsittelyssä olevan kehittämisalueen tai -alueiden kohdalta huomioiden myös muut arkkitehtuurinäkökulmat (tieto-, tietojärjestelmä- ja teknologia-arkkitehtuurit) sekä kehittämisen kohteena olevan alueen sidos- ja kohderyhmät. Tässä vaiheessa varmistetaan myös puuteanalyysin avulla, että suunnittelussa on huomioitu kaikki tarvittavat osa-alueet. 12/29

6.2.1 Analysoi kehittämisalueen ja kuvausten kohderyhmät Analysoi, miten projektin sidosryhmät osallistuvat kehittämiseen tai hyödyntävät suunnittelun tuloksia. Tuotettavien kuvausten sisällön tulee olla sellainen, että kaikki sidosryhmät tulee huomioitua. Kunkin sidosryhmän tulee ymmärtää sidosryhmälle tarkoitettujen kuvausten sisällöt (esim. ylin johto toiminnan käsittein tai tekninen asiantuntija teknisin käsittein). Huomioi analyysin tulokset kehittämiskohteiden tunnistamisen tulosten dokumentoinnissa. 6.2.2 Tee puuteanalyysi Puuteanalyysissä kerätään ja analysoidaan kehittämistarpeita. Arvioi, onko jotain asioita tai näkökulmia jäänyt huomioimatta suunnittelussa. Hyödynnä analyysissä JHS 179 -suosituksen liitteen 4 Puuteanalyysipohjaa. 6.2.3 Kuvaa tavoitetilan palvelut ja palveluratkaisut Kuvaa kehittämiskohteena olevan alueen tavoitetilan palvelut ja palveluratkaisut. Selvitä myös mihin olemassa oleviin palveluihin ja palveluratkaisuihin muutokset vaikuttavat. Hyödynnä palveluiden ja palveluratkaisujen kuvauksessa liitteen 4 Palvelukuvaus-pohjaa sekä kuvan 5 Palvelukartta-mallia. Huomioi myös tässä vaiheessa, että hallintolain 7 mukaan viranomaisasiointi tulee järjestää siten, että hallinnon asiakas voi käyttää ja hyödyntää asianmukaisesti järjestettyjä hallinnon palveluita. Kyseisen palveluperiaatteen tarkoituksena on korostaa asioinnin tehokkuutta ja tarkoituksenmukaisuutta sekä turvata viranomaispalvelujen saatavuus sekä varmistaa, että asiointia järjestettäessä kiinnitetään huomiota hallinnon asiakkaiden tarpeisiin. Palveluperiaatteeseen kuuluu myös palautteen kerääminen palvelujen käyttäjiltä ja sen hyödyntäminen palveluiden kehittämisessä. Kuvassa 5 on kuvattu esimerkki palvelukartasta. 13/29

Kuva 5 Palvelukartta (lähde: ValtIT, Arkkitehtuurimenetelmä) Lopputuloksena syntyvät vähintään seuraavat kuvaukset: tulevat palveluratkaisut ja keskeiset muutokset nykyisiin palveluratkaisuihin. tulevat palvelukuvaukset, eli asiakkaille ja sidosryhmälle kehittämisalueen tuloksena syntyneet uudet tai muuttuneet palvelut. tulevien palveluratkaisujen ja strategisten sekä muiden toiminnan tavoitteiden yhteys. 6.2.4 Kuvaa tavoitetilan toimintamallit ja prosessit Tavoitetilan prosessien ja toimintamallin hahmottelun lähtötietoina ovat mm. nykyprosessin kuvaukset (mikäli olemassa olevaa toimintaa). nykytoiminnan muut kuvaukset, mm. palvelurakenteen kuvaukset (mikäli on). tulevan palvelurakenteen kuvaukset. kehittämisprojektin suunnitteluvaiheen tavoitteet. Tee tavoiteprosessista kuvaus, jota tullaan tarkentamaan vielä vaatimusmäärittelyn ja varsinaisen toteutusprojektin yhteydessä. 14/29

Prosessien kuvaustapa on esitelty ja ohjeistettu Julkisen hallinnon suosituksessa JHS 152 Prosessien kuvaaminen (http://www.jhs-suositukset.fi/suomi/jhs152). Prosessien kuvaus tasolla 2 riittää yleensä, tärkeintä on, että erojen havaitseminen nyky- ja tavoiteprosessista on mahdollista. 6.2.4.1 Tunnista tavoite- ja nykyprosessien erot Tavoiteprosessin kuvauksen jälkeen suorita vertailu nykytilan ja tavoitetilan prosessien välillä ja selvitä, jääkö prosessien välille kuiluja. Listaa vertailussa myös prosessien erot siirtymäkauden toimintamallien suunnittelua ajatellen. Tarkastele eroja nyky- ja tavoiteprosessien välillä esimerkiksi puuteanalyysien (GAPanalyysi) avulla. Puuteanalyysien kautta erot konkretisoidaan ja määritellään tarkemmin kehittämistoimenpiteiksi. Nämä kehittämistoimenpiteet konkretisoidaan prosessien kehittämisprojektiksi/- projekteiksi ratkaisujen valintavaiheessa. Kuva 6 GAP-analyysin avulla voidaan määritellä portaat, joilla organisaatio pääsee aikataulutetusti kehittämään toimintaansa nykytilasta tavoitteiden suuntaan. Tarkastele nyky- ja tavoiteprosessia myös toteuttamismahdollisuuksien ja -rajoitusten näkökulmasta. Tarkastellessa selvitä mm. onko kuilu niin suuri, ettei prosessimuutosta ole mahdollista tai järkevää toteuttaa. onko prosessimuutos realistinen esim. osaamisen tai tukevien tietojärjestelmien näkökulmasta. saadaanko prosessien muutoksella tavoiteltavat hyödyt suhteessa panostukseen. entä jos prosessien muutos jää esim. em. syistä tavoiteltua vähäisemmäksi, mitkä ovat tavoitetilan toteuttamisen vaihtoehdot. ovatko mittavan prosessien muutoksen hyödyt ja muutoksen aiheuttamat riskitekijät oikeassa suhteessa ja riskit hallittavissa. miten laadun varmistaminen muutoksen aikana (siirtymäaika) ja sen jälkeen on mahdollista. ovatko toimintamallien muutosten vaikutukset organisaatioon (hallinnollinen rasite) hallittavissa ja ovatko ne kokonaisuuden kannalta järkeviä. Jos tietotekninen ratkaisu toteutettaisiin valmisohjelmistoratkaisuna tai ASP-ratkaisuna, prosessin tarkennuksiin on oltava valmiudet. Tämä johtuu mm. siitä syystä, että on huomattavasti järkevämpää ja 15/29

kustannustehokkaampaa räätälöidä omaa prosessia valmisohjelmistoon sopivaksi kuin räätälöidä valmisohjelmistoa prosessin mukaiseksi. 6.2.5 Kehitä toiminnan tavoitetilaa tarvittaessa Arvioi, vaikuttaako kehittämisen tulos toiminnan tavoitetilaan ja korjaa sitä tarvittaessa. Päivitä vaatimukset ja ilmoita muutoksista vastuullisille tahoille. 6.2.6 Vaiheen lopputulokset Tavoitetilan suunnitteluvaiheen lopputulokset ovat: tavoiteprosessin kuvaukset. realistinen arvio prosessimuutosten toteutusmahdollisuuksista. puuteanalyysi. toiminnan tavoitetilan kehitysehdotukset. päivitetyt vaatimukset. 6.3 Tavoitehyötyjen määrittely ja mittarien laadinta 6.3.1 Määrittele tavoitehyödyt Määrittele ja täsmennä palvelurakenteen ja palvelukuvausten, tavoiteprosessin ja myös tietoteknisen tavoitetilan perusteella tarkemmalle tasolle kaikki ne tavoiteltavat hyödyt, joita kehittämisellä tavoitellaan. Hyötyjen kuvauksissa tulee pyrkiä kattavuuteen ja laajaan näkökulmaan, ei pelkästään taloudellisten hyötyjen kuvaamiseen. Tavoitehyödyt voidaan jakaa esimerkiksi neljään kategoriaan: Taloudelliset hyödyt palvelun tuottajalle Kuvaa mm. toiminnan kehityksen taloudelliset tavoitteet mm. kustannustehokkuuden, tuottavuusvaikutusten ja mahdollisten säästöjen näkökulmasta. Hyödyt asiakkaille ja sidosryhmille Kuvaa kehittämisen hyödyt asiakas- / sidosryhmävaikuttavuuden ja asiakas- / sidosryhmätyytyväisyyden kannalta. Kuvaukset voivat sisältää esim. sidosryhmien kustannuksiin, palvelun laatuun, laajuuteen, saatavuuteen ja joustavuuteen liittyviä hyötyjä. Toiminnan tehostuminen ja sitä kautta tapahtuva tuottavuuden nousu Kuvaa hyödyt, joita tavoitellaan esim. parempana prosessien ja toiminnan tehokkuutena, toimintavarmuutena, parempina läpimenoaikoina, oikeellisempina tuloksina sekä parempana ja tehokkaampana tietotekniikan hyödyntämisenä. Osaaminen ja henkilöstö Kuvaa hyödyt osaamisen kehittämisen / kehittymisen kannalta, parempana työtyytyväisyytenä, osaamisen ja osaamisvaatimusten kohdistamisen kannalta sekä organisoinnin kannalta. 16/29

Tarkastele hyötyjen syntymistä myös organisaation sisällä eri näkökulmista, sekä yhteisissä toiminnoissa että substanssissa. Yhteisiin toimintoihin vaikuttavat hyödyt voivat olla esimerkiksi tietojärjestelmien hallintaan tai muihin organisaation yhteisiin palveluihin tai yleishallintoon ja johtamiseen liittyviä hyötyjä. Substanssissa voi syntyä hyötyjä prosessien ja toiminnan tehostumisen ja tuottavuuden kautta. Lain muutoksien kohdalla voidaan keskittyä tutkimaan kustannusten järkevää optimointia, sillä hyötyjen arviointi on suoritettu jo lainvalmisteluvaiheessa. Kiteytä ja konkretisoi hankkeen ja projektien hyötynäkökulmat esimerkiksi alla olevan kuvan (kuva 7) mukaisen hyötykartan avulla. Kartta, kuten yllä oleva hyötyjen jaottelukin perustuu Balanced Scorecard -mallin mukaiseen nelijakoon: Taloudelliset hyödyt, hyödyt asiakkaalle / asiakkaan näkökulmasta, toiminnalliset hyödyt ja hyödyt henkilöstölle ja organisaatiolle. Eri projekteissa tavoitehyötyjen painopisteet voivat vaihdella merkittävästikin. Kuva 7 Hyötykartta 6.3.2 Laadi mittarit Laadi mittarit tavoitehyötyjä ja niiden toteutumisen mittaamista varten. Mittareiden laadinnassa tulee huomioida: että niillä voidaan mitata toiminnan ja ohjauksen suorituskykyä. että suorituskykymittari on muutoksissa säilyvä, jotta mittaamistulokset olisivat verrannollisia. Kuvan 8 hyötykartasta ja määritellyistä tavoitehyödyistä, sekä tavoitetilan tunnistetuista kriittisistä menestystekijöistä voidaan johtaa myös alustavat mittarit kuhunkin hyötykategoriaan. Huomaa, että mittareiden määrä ei ole tärkein asia, vaan se, mitataanko lopputuloksen kannalta olennaisia asioita. Liitteen 2 Mittarit- ja hyödyt -taulukkoa voidaan käyttää apuna mittarien laadinnassa. Mittareiden avulla hyötyjen toteutumista voidaan seurata sekä kehittämishankkeen kuluessa, että myös hankkeen ja sen projektien päätyttyä lopputuloksen ollessa hyötykäytössä. Mittareista ensimmäinen näkemys voidaan muodostaa jo tässä vaiheessa, mutta sekä mittarit että niiden tavoitearvot täsmentyvät kehityshankkeen asettamisen ja suunnittelun yhteydessä. Suorituskykymittari voi liittyä organisaatioon, prosessiin, palveluun, syötteisiin, henkilöön, jne. 17/29

Prosessien suorituskyvyn ja tehokkuuden mittaamista varten liitetään prosessiin mittari. Mittaamisessa ja mittarin valinnassa tulee kiinnittää huomio seuraaviin kysymyksiin: Mikä on prosessin tarkoitus ja tavoitteet? Mitä pitää mitata, jotta saadaan tavoitteiden kannalta oikea tulos? Minkälainen mittari valitaan mihinkin tilanteeseen, laadullinen (tyytyväisyys-kyselyt) vai määrämuotoinen (lukuarvoinen eli määrällinen)? Miten mittarin toimivuus voidaan testata ennen käyttöönottoa? Miten mittaamisen tuottama tulos saadaan analysoitua ja hyödynnettyä päätöksentekoa varten? Prosessijohtaminen ja prosesseista täyden hyödyn saaminen vaatii avukseen työvälineen. Apuvälineen avulla prosesseja voidaan kuvata käyttäen standardeja prosessien kuvauskieliä, jotka ovat jatkojalostettavissa suoraan mitattaviksi, suoritettaviksi prosesseiksi (automatisointi, kuvausstandardi OMG Business Process Modeling Notation Specification). 6.4 Tietoteknisten mahdollisuuksien ja rajoitusten määrittely Tietoteknisen tavoitetilan määrittelyn lähtökohtana ovat toiminnalliset tavoitteet, palveluratkaisut sekä tavoiteprosessit. Määrittelyllä haetaan vastauksia mm. seuraaviin kysymyksiin millaiset tietotekniset ratkaisut tukevat parhaiten asetettuja (toiminnallisia) tavoitteita. millaisilla tietoteknisillä ratkaisuilla pyritään parantamaan prosessia. 6.4.1 Määrittele tietotekniikkaratkaisut Määrittele tietotekniset ratkaisuvaihtoehdot huomioiden kehittämisalueen toiminnalliset tavoitteet ja odotukset, jottei tietoteknisiä ratkaisuja viedä tasolle, jota ei toiminnan kannalta tarvita. Huomioi myös, että merkittävä teknologian muutos voi olla myös merkittävä kustannustekijä tulevaa ratkaisua toteutettaessa. Ota kantaa jo tässä vaiheessa tietotekniikkaratkaisun toteutustapaan, esim. tulisiko tuleva ratkaisu olemaan valmisohjelmisto, räätälöity ratkaisu vai kenties olemassa olevan järjestelmän uudistaminen. Selvitä myös mahdollisuudet yhteishankintaan. Tarkemmin ratkaisuvaihtoehtoihin paneudutaan kuitenkin vasta esiselvityksen vaiheessa Tavoiteratkaisun tarkentaminen. Ota tarkasteluun mukaan eri näkökulmia, kuten esim. kolme päänäkökulmaa: Nykyisin käytetyn teknologian tuomien mahdollisuuksien ja rajoitusten kartoitus Tutkitaan huolellisesti nykyinen kohdealueella käytössä oleva teknologia, mitä mahdollisuuksia se tarjoaa tulevan ratkaisun toteuttamiselle, ja mitä se rajoittaa. Käytettävissä olevan teknologian tuomien mahdollisuuksien ja rajoitusten kartoitus Tutkitaan jo olemassa olevan, ei välttämättä tällä kohdealueella, mutta esim. toisella toimialalla käytössä olevan teknologian mahdollisuudet ja rajoitukset. Tällä tavalla, organisaatiossa jo olemassa olevan teknologian käyttöalueen laajentamisella, voidaan saada merkittävää kustannushyötyä. Kokonaan uuden teknologian käyttäminen, mahdollisuudet ja rajoitukset Tutkitaan mahdollisuuksia siirtyä uuteen teknologiaan luonnollisesti koko ajan muistaen, että uusi teknologia ei ole itse tarkoitus, vaan sillä tulee toteuttaa kehittämisalueen tarpeet ja odotukset mahdollisimman kustannustehokkaalla tavalla. 18/29

Selvitä lisäksi markkinoilla toimivia toimittajia ja tarjontaa. Tarvittaessa lähetä markkinatilanteen kartoittamiseksi alustava kysely tai tietopyynnön kaikille tuntemillesi markkinoilla toimijoille. Tietopyynnön tarkoituksena on kartoittaa markkinoilla toimivia yrityksiä, heidän toimintamallejaan ja ratkaisuvaihtoehtojaan sekä yleistä hintatasoa ja mahdollista halukkuutta osallistua hankkeen toteuttamiseen, jotta varsinaisella tarjouspyyntökierroksella saadaan mahdollisimman selkeät ja vertailukelpoiset tarjoukset. Tietopyynnön lähettäminen ei edellytä myöhemmin hankintailmoituksen laatimista. Lähetä tietopyyntö mahdollisimman monelle potentiaaliselle tarjoajalle, jotta varmistetaan tulevien tarjoajien tasapuolinen kohtelu. Tietopyyntö ei saa olla tarjouspyynnön kaltainen tai kohdennettu vain muutamalle yritykselle. Tietopyynnöstä tulee käydä ilmi, että ei ole kyse hankintailmoituksesta. Hyvä tapa kartoittaa mahdollisia ratkaisuja, on myös selvittää mitä järjestelmiä muissa vastaavissa organisaatioissa käytetään ja minkälaisia kokemuksia niistä on. Määrittelyn lopputuloksena ovat tietoteknisten ratkaisuvaihtoehtojen kuvaukset alustavine kustannustekijöineen, mahdolliset laajennustarpeet huomioiden. 6.5 Toiminnan kehittämismahdollisuuksien ja rajoitusten määrittely 6.5.1 Määrittele toiminta- ja palveluratkaisut Määrittele toiminta- ja palveluratkaisut kehittämiskohteena olevalle alueelle. Avainkysymyksiä kehittämismahdollisuuksien ja myös rajoituksen mietinnässä ovat mm. mihin nykyiset toiminta- ja palveluratkaisut taipuvat, millaisia ratkaisuja ne tukevat ja mitä rajoittavat tai estävät. kuinka paljon tulevilla toiminta- ja palveluratkaisuilla on mahdollista ja järkevää muuttaa toimintatapaa ja prosessia. toiminta- ja palveluratkaisujen muutostarpeiden /-mahdollisuuksien realistisuus ja toteuttamiskelpoisuus. miten tavoitetilan mukaiset toiminta- ja palveluratkaisut istuvat palvelukulttuuriin. vastaavatko tavoitetilan mukaiset ratkaisut asiakaslupauksia ja sidosryhmien tarpeita ja odotuksia. Määrittelyn lopputuloksena ovat kuvaukset eri toiminnallisista vaihtoehdoista ja palvelurakenteen ja palveluratkaisujen vaihtoehdoista. 6.6 Tavoitetilan analyysit 6.6.1 Tee riskianalyysi Tee riskianalyysi kehittämiskohteena olevasta alueesta huolellisesti, sillä mitä aikaisemmassa vaiheessa riskit kehittämistyössä tunnistetaan ja mitä yksiselitteisemmin niiden vaikutukset kyetään arvioimaan, sitä helpompi niihin on myös vaikuttaa. Järjestelmäkehityksessä riskien arviointi on tärkeätä kaikissa vaiheissa. Käytä riskianalyysin apuna olemassa olevia kuvauksia tai tässä annettuja esimerkkejä. Huomioi, että tässä kuvatun riskianalyysin perustana on järjestelmään kohdistuvien uhkien tunnistaminen ja niiden merkityksen arvioiminen. Mallia voi myös käyttää toimintamallien riskien analysoinnissa soveltuvin osin. Järjestelmään kohdistuvia riskejä ovat mm. 19/29

järjestelmän ulkoisia liittymiä koskevat riskit. järjestelmän päätoimintojen riskit. tietojen säilyttäminen ja käyttö. käytettävät sovellukset (riski joka liittyy käytettyihin tuotteisiin ja niiden tukeen). käyttöympäristöriskit (palvelimet, työasemat, tietoliikenne) fyysisen ympäristön riskit (laitetilat). henkilöstöriskit (palvelun toimittajan sekä oma). ulkoisten palveluiden käyttöön liittyvät riskit. hankintojen riskit. Huomioi riskien analysoinnissa yksittäisten tietoturvallisuuskriittisten kohteiden tarkempi riskianalyysi. tietoturvallisuuskriittisten kohtien jäännösriskit. yleiset jäännösriskit eli kaikkien varautumistoimenpiteiden jälkeen jäljelle jäävät hyväksytyt riskit. Kuva 8 Riskien arvioinnin ja hallinnan vaiheet (Murtonen 2003) 1. 1 Murtonen Mervi, Riskin arviointi, STM:n työsuojeluoppaita ja -ohjeita 14 20/29