JHS 172 ICT-palvelujen kehittäminen: Esiselvitys

JHS 172 ICT-palvelujen kehittäminen: Esiselvitys Versio: 1.1 5.10.2012 Julkaistu: 11.9.2009 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 2 Soveltamisala... 3 3 Termit ja määritelmät... 4 4 Esiselvityksen käynnistämisen edellytykset... 5 5 Markkinakartoitus... 6 5.1 Puitejärjestelyt... 6 5.2 Käynnissä olevat hankkeet ja yhteishankinnat... 7 5.3 Avoimen lähdekoodin ratkaisut... 7 5.4 Vaiheen lopputulokset... 7 6 Integrointi muihin järjestelmiin... 8 7 Tietoturvallisuuden kartoitus... 9 7.1 Riskien tunnistaminen... 9 7.2 Tärkeysluokat... 12 7.3 Tietojen turvaluokitus ja suojaustasot... 12 7.3.1 Tietojen suojaustasot... 13 7.4 Esiselvitysvaiheen tietoturvallisuusvastuut... 13 8 Tavoiteratkaisun tarkentaminen... 14 8.1 Toiminnallisten hyötyjen kuvaaminen... 14 8.2 Keskeisten laatutavoitteiden määrittely... 15 8.3 Perusteet kilpailutukselle... 15 8.4 Tavoitetilan suunnittelun lopputulosten tarkastelu... 16 8.5 Jatkotoimenpide-ehdotuksen laatiminen... 16 9 Esiselvityksen päättäminen ja dokumentointi... 16 10 Päätöksenteko hankkeen jatkamisesta... 17 10.1 Hankittavan tietojärjestelmän omistajuus... 17 11 Opastavat tiedot... 17 12 Liitteet... 18 1/18

1 Johdanto Tässä suosituksessa kuvataan julkisen hallinnon esiselvitysmenetelmän toteutusprosessi vaiheittain ja vaiheisiin liittyvät toimintaohjeet. Tämä suositus on osa ICT-palvelujen kehittäminen suositussarjaa ja se täydentää suositusta JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen. Vaiheena suositus sijoittuu kehittämiskohteiden tunnistamisen jälkeen. Kuva 1 ICT-palvelujen kehittämisen vaiheet Tämän suosituksen taustalla on valtiovarainministeriön ValtIT:n laatima kokonaisarkkitehtuurimenetelmä, joka on alun perin tehty kuvaamaan valtionhallinnon kokonaisarkkitehtuurin kuvaamista ja mallintamista. Suosituksessa on huomioitu lisäksi kuntanäkökulma. Valtionhallinnon kokonaisarkkitehtuuri on toiminnan prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. Valtionhallinnon kokonaisarkkitehtuuri pitää sisällään arkkitehtuurilinjaukset ja -kuvaukset, arkkitehtuurin hallintamallin sekä arkkitehtuurimenetelmän. Tässä suosituksessa kuvataan oheisen prosessin (kuva 2) kohtaa Toimeenpanon suunnittelu. 2/18

Kuva 2 Kokonaisarkkitehtuurin suunnitteluprosessi, ValtIT:n Arkkitehtuurimenetelmä Esiselvityksen tehtävänä on tuottaa tietoa toimintamallien tai tietojärjestelmän kehittämisestä päättäville sekä määrittää lähtökohdat mahdolliselle tietojärjestelmän hankinnalle. Esiselvityksessä kootaan sidosryhmiltä mahdollisesti tullut palaute tai tietojärjestelmää koskevat toiveet sekä järjestelmälle asetettavat tavoitteet ja rajaukset. Organisaation korkean tason vaatimukset (kuten TTS, lainsäädäntö, kehittämisohjelma) toimivat pohjana esiselvityksen kohteena olevalle tietojärjestelmälle. Suuremman kehittämiskokonaisuuden esiselvitys kannattaa toteuttaa projektina. Pienemmissä kokonaisuuksissa esiselvitys voidaan toteuttaa myös kevyemmällä menettelyllä, jolloin järjestelmän omistaja vastaa esiselvityksen toteuttamisesta. Esiselvityksen aloituksen edellytyksenä on, että kehittämiskohteiden tunnistamisen eri vaiheet on suoritettu ja ko. vaiheessa toteutettavat dokumentit ovat käytettävissä (kts. JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen). valmisteluvaiheessa on kerätty ja analysoitu eri tahojen tarpeet ja ne on hyväksytty johtotasolla. esiselvityksen kokonaisuus on määritelty ja rajattu. tulevan järjestelmän omistajuus on selvitetty. strategisten ja muiden tavoitteiden mukaisuus on tarkistettu. Esiselvitysvaiheessa kootaan kaikki ne asiakirjat, ohjeistukset, standardit jne., jotka ohjaavat, rajaavat tai määrittelevät mahdollista järjestelmän hankintaa. Näitä ovat esimerkiksi JHS-suositukset ja VAHTI-ohjeet sekä organisaation oma ICT-strategia. 2 Soveltamisala Suositus on tarkoitettu käytettäväksi julkisen hallinnon tietojärjestelmähankkeiden esiselvitysvaiheessa, ennen itse hankintaa ja hankkeen aloittamista. 3/18

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. esiselvitys Esiselvityksellä tarkoitetaan ennen tietojärjestelmän vaatimusmäärittelyä ja tietojärjestelmähankintaa tehtävää selvitystä. Selvityksen osa-alueita ovat mm. toimintaympäristön kartoitus, tavoiteratkaisun tarkentaminen sekä tietoturvallisuuden kartoittaminen. integraatio Integraatiolla tarkoitetaan tässä sovellusten tai järjestelmien liittämistä toisiinsa. 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. konversio Konversiolla tarkoitetaan tiedon siirtämistä talletusmuodosta toiseen esim. verkkotietokannasta relaatiotietokantaan, vanhan tietokannan tietojen siirtoa uudempaan kantaan tai tietokantojen yhdistämistä. SaaS Software as a Service, vuokrattavaksi tehty ohjelmisto moniasiakasympäristöön. Ohjelmistoa käytetään selainkäyttöliittymällä verkon yli ja sitä ei räätälöidä asiakaskohtaisesti. 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, luokittelua ja 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. 4/18

toiminta-arkkitehtuuri Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation strategisiin vaatimuksiin liittyvää ydintoimintaa eli ydintoimintaprosesseja ja näitä 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 Esiselvityksen käynnistämisen edellytykset Ennen esiselvityksen aloittamista on selvitettävä, ovatko JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen -suosituksessa mainitut lopputulokset valmiita ja käytettävissä. Mikäli ennen esiselvitystä on jo suunnitelmia tietojärjestelmiin liittyvistä muutoksista tai -hankinnoista, suunnitelmia tulee verrata olemassa oleviin arkkitehtuurikuvauksiin. Ennen esiselvityksen aloittamista on myös selvitettävä onko organisaatiolla käytettävissään riittävät resurssit (rahaa, asiantuntemusta, henkilötyöaikaa) selvityksen toteuttamiseen. Itse esiselvitysvaiheen vaiheistaminen, rajaaminen sekä eri tehtävien priorisointi on myös tehtävä ennen vaiheen käynnistämistä. Lisäksi on tarkistettava, onko kaikki oleelliset sidosryhmät kartoitettu ja tarvittaville tahoille ilmoitettu alkavasta esiselvityksestä/kehityshankkeesta. Mahdolliset eri osapuolten edustajat on myös kartoitettava ja heidän mahdollisuutensa osallistua tai kommentoida vaiheen tuloksia on varmistettava. Projektipäällikön valinta on myös suositeltavaa tehdä jo ennen vaiheen aloittamista. Mahdollisuuksien mukaan kannattaa jo kerätä tietoa samankaltaisista hankkeista tai toimenpiteistä muista organisaatioista. Mikäli jonkin edellä mainitun osa-alueen kohdalla havaitaan ristiriitaisuuksia tai tiedot ovat puutteellisia, ei esiselvitystä kannata käynnistää, ennen kuin riittävät esitiedot on kerätty. Vähintään seuraavien dokumenttien tulisi olla käytettävissä ennen esiselvityksen käynnistämistä: organisaation strategia. palvelukuvaukset. palveluihin liittyvät (niitä tuottavat tai mahdollistavat) tietojärjestelmät. toimintamallit ja organisaatiot. prosessien kuvaukset (nykytila ja tavoitetila). prosessien analysointien tulokset. riskianalyysi. järjestelmä- ja arkkitehtuurikuvaukset. arkkitehtuurien mahdolliset kehittämistarpeet. selvitykset taloudellisista tunnusluvuista. analyysien tuloksena syntyneet ja/tai tiedossa olevat priorisoidut nykyjärjestelmän ja nykytoiminnan kehittämistarpeet. kehittämissuunnitelma. Esiselvityksessä tarkennetaan kehittämiskohteiden tunnistamisen yhteydessä tehtyjä kuvauksia, kuten esimerkiksi tavoiteratkaisun kuvauksia sekä kustannus- ja hyötyanalyysiä. 5/18

Kuva 3 Esiselvityksen vaiheet 5 Markkinakartoitus Esiselvitysvaiheen markkinakartoituksella tarkoitetaan sitä, että pyritään selvittämään muiden toimijoiden tapaa toimia vastaavanlaisessa tilanteessa sekä jo olemassa olevia mahdollisia tietoteknisiä ratkaisuja ja palvelutarjontaa ja miten niitä mahdollisesti voitaisiin hyödyntää. Mahdollisia tulevia tarjoajia tulee markkinakartoituksessa kohdella tasapuolisesti. Lisäksi kannattaa selvittää mahdollisuudet tietojen yhteiskäyttöön (perusrekisterien hyödyntäminen, yhteisten tietolähteiden kehittäminen) sekä yhteisten tukipalveluiden käyttöön. Perusrekistereitä ovat mm. VTJ-henkilötietorekisteri ja YTJ-yritystietorekisteri, yhteisiä tukipalveluita esim. tunnistus- ja aikaleimapalvelut. Markkinakartoitusvaiheessa tarjontaa voidaan selvittää myös ns. RFI-kyselyllä (Request For Information) teknologiatoimittajille. Kyselyllä voidaan tiedustella markkinoilta löytyviä tuotteita tai tarjontaa kehittämiskohteen ratkaisua. Tämä voi olla tarpeen niissä tapauksissa, joissa vastaavaa toiminnallisuutta ei ole tehty organisaation sisällä tai vastaavia referenssejä ei ole tiedossa. 5.1 Puitejärjestelyt Toimintaympäristön kartoituksen yksi tärkeä osa-alue on erilaisten puitejärjestelyjen selvittäminen. Puitejärjestelyiden avulla hankinta voi olla mahdollista toteuttaa kevyemmällä kilpailutuksella. Olemassa olevaa puitejärjestelyä hyödyntämällä voi olla mahdollista vähentää hankkeen käynnistämiseen kuluvaa aikaa. Puitejärjestelyistä saa tietoa esim. Hanselin www-sivuilta (www.hansel.fi). Kuntien puitejärjestelyjä hoitaa KL Kuntahankinnat Oy. 6/18

5.2 Käynnissä olevat hankkeet ja yhteishankinnat Muiden toimijoiden (virastojen, osastojen jne.) tarve vastaavanlaiselle tietojärjestelmälle tai toiminnallisuudelle on hyvä kartoittaa. Esiselvitysvaiheessa kannattaa selvittää lisäksi muiden toimijoiden käynnissä olevat tai alkamassa olevat hankkeet, joilla on sama tai osittain sama tavoite. Mahdollisuudet osallistua hankintaan tai hankkeeseen kannattaa arvioida ratkaisuvaihtoehtoja määriteltäessä. Julkisen hallinnon hankkeista saa tietoa ValtIT:n (www.valtit.fi) sekä KuntaIT:n (www.kuntait.fi) internetsivustoilta sekä Valtiovarainministeriön ylläpitämästä Hankerekisteristä (http://www.hare.vn.fi). Tietoa käynnissä olevista ja päättyneistä kilpailutuksista saa mm. seuraavista linkeistä: HILMA: http://www.hankintailmoitukset.fi/fi/ TED (kilpailutukset EU-tasolla): http://simap.europa.eu/supplier/opportunities-in-europe_fi.html 5.3 Avoimen lähdekoodin ratkaisut Mikäli markkinakartoituksessa todetaan, että täytettävä tarve voidaan ratkaista avoimen lähdekoodin ohjelmalla, tämä tulee huomioida hankinnan suunnittelussa. Jos tuote on maksutta ladattavissa, niin hankinnan kohde ei olekaan tietojärjestelmä sellaisenaan, vaan esimerkiksi konsultointi-, asennus-, koulutustai käyttöpalvelut. On myös syytä varmistaa, että kyseisen avoimen koodin ratkaisun yllä mainittuja palveluita on saatavilla järkevillä kustannuksilla. Lisäksi tulevan toimittajan sopimusvastuun varmistaminen avoimella lähdekoodilla toteutetusta sovelluksesta on suositeltavaa. Myös mahdolliset lisensointi- ja sopimustekijät tulee huomioida avoimen lähdekoodin ratkaisua kartoitettaessa. Avoimen lähdekoodin elinkaarikustannuksia tulee myös arvioida verrattuna suljetun koodin tuotteen elinkaareen. Jos vertailussa päädytään siihen, että suljetun koodin tuote olisi elinkaarikustannuksiltaan ja toiminnallisilta ominaisuuksiltaan soveltuvampi, niin hankinnan kohde määritellään ohjelmistolisenssiksi ja vaatimukset kohdistuvat sen mukaisesti. Vaihtoehdot ovat siis, että valitaan avoimen lähdekoodin tuote ja kilpailutetaan tarvittavat palvelut sen käyttöönottoon ja ylläpitoon. hankitaan järjestelmä niin, että tarjoaja valitsee välineet ja vastaa käyttämiensä avoimen koodin tuotteiden tuesta osana järjestelmän tukipalvelua. kilpailutetaan tietojärjestelmän toteutus niin, että eri vaihtoehtojen (avoimen lähdekoodin tuote, ohjelmistolisenssi, palveluna ostettava tietojärjestelmä) kokonaiskustannuksia (lisenssin hinta + elinkaarikustannukset) verrataan toisiinsa. Jälkimmäisessä vaihtoehdossa ongelmana on eri toteutusmallien saaminen vertailukelpoisiksi keskenään. JHS 169 Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa -suositus opastaa avoimen lähdekoodin hankinnoissa. 5.4 Vaiheen lopputulokset Markkinakartoitusvaiheen lopputuloksena on selvitetty, onko jo olemassa vastaavia tietoteknisiä ratkaisuja tai palvelutarjontaa ja voidaanko niitä hyödyntää. on tarkistettu, voidaanko mahdollisia puitejärjestelyjä hyödyntää hankintaa tehtäessä. on selvitetty, onko käynnissä vastaavia hankkeita tai yhteishankintoja, joita voitaisiin hyödyntää. 7/18

on tehty selvitys avoimen lähdekoodin käytöstä järjestelmän hankinnassa. on selvitetty mahdollisuus yhteispalvelujen ja rekisterien käyttöön. 6 Integrointi muihin järjestelmiin Järjestelmien integroinnilla tarkoitetaan sitä, että tietojärjestelmän komponentit ovat keskenään yhteentoimivia sekä eri tietojärjestelmien kytkemistä toisiinsa fyysisesti tai toiminnallisesti. Esiselvitysvaiheessa on tunnistettava ne prosessit, jotka liittyvät integroitavan järjestelmän tai sovelluksen (=tavoiteratkaisun) ympäristöön. Esiselvitysvaiheessa tulee lisäksi selvittää tavoiteratkaisun integraatiotarpeet, kuvata integroitavat järjestelmät ja niiden suhteet sekä suunnitella alustavasti itse integraatio. Järjestelmien integraatiota ja siihen liittyviä toimenpiteitä selvitettäessä hyödynnetään kehittämiskohteiden tunnistamisvaiheessa tehtyjä kuvauksia. Integraation suunnittelussa oleellisia kuvauksia ovat mm. kuvaukset toiminta-, tieto- ja tietojärjestelmäarkkitehtuureista tavoiteratkaisun kannalta sekä nykytilan ja tavoitetilan prosessikuvaukset. Toiminta ja integraatio Kuvataan nykytila prosessien ja integroitavan järjestelmän tai sovelluksen osalta. Lisäksi kuvataan tavoitetila prosessien ja integroitavan järjestelmän tai sovelluksen osalta Integraatiotarpeiden selvittäminen Selvitetään, millaisia integraatiotarpeita tavoiteratkaisun toteuttaminen vaatii. Selvitettäviä asioita ovat mm. mitä tietoja siirretään tai mitä tietoja tarjotaan toiselle palvelulle. siirrettävien/tarjottavien tietojen tärkeys (pakko siirtää, ei pakko siirtää). siirrettävän/tarjottavan tiedon määrä (kpl ja koko) tietojen omistajuus (MDM, Master Data Management). tarve siirtojen/tietojen tarjoamisen reaaliaikaisuuteen. Integroitavien järjestelmien kuvaus Tunnistetaan ja kuvataan integroitavat sovellukset ja järjestelmät huomioiden niiden erityispiirteet sekä elinkaari. Kuvattavia asioita ovat mm. ratkaisuun liittyvät osajärjestelmät. järjestelmien tallentama ja tarvitsema tieto. mahdolliset ja soveltuvat teknologiat. rajapinnat Integraation suunnittelu Laaditaan alustava toteutussuunnitelma integraation läpiviemiseksi. Yhtenä osana integraation suunnittelua on konversion suunnittelu, jota on kuvattu liitteessä 2 Konversio. Vaiheen lopputuloksina syntyvät: kuvaukset tavoiteratkaisun integroimisesta muihin sovelluksiin tai järjestelmiin. selvitys integraatiotarpeista. alustava toteutussuunnitelma integraation läpiviemiseksi. 8/18

7 Tietoturvallisuuden kartoitus Esiselvitysvaiheen tärkein tietoturvallisuustehtävä on kartoittaa tietoturvallisuuden pettämisestä toiminnalle aiheutuvat menetykset, tunnistaa ja arvioida riskit sekä valita järjestelmän turvallisuustaso. Esitutkimuksessa kartoitetaan kohteena olevan tavoiteratkaisun, siihen liittyvien tietoaineistojen ja työtehtävien tärkeys toiminnalle ja sen jatkuvuudelle. Esiselvityksen perusteella määritellään muun muassa kehitettävän järjestelmän tärkeysluokka. Tärkeysluokitus määrittelee valvonnalle (toiminnan ja tapahtumien seurannalle ja toimenpiteisiin ryhtymiselle) asetettavat vaatimukset. 7.1 Riskien tunnistaminen Tietoturvariskien tunnistamiseksi on tärkeää tuntea kehitettävän järjestelmän toiminnallisuus, sen avulla käsiteltävä tietoaineisto ja rajapinnat muihin järjestelmiin, jotka tulee dokumentoida osana esiselvitystä. Pohjana tietoturvaratkaisujen kuvaukselle toimii tavoiteratkaisun kuvaus, joka on tehty kehittämiskohteiden tunnistamisen yhteydessä. Esiselvitysvaiheessa tehtävä tietoturvariskien arviointi toimii vastaavasti lähtötietona vaatimusmäärittelyvaiheessa laadittaville tietoturvavaatimuksille. Tunnistettujen tietoturvariskien ja toiminnallisuuden perusteella voidaan hankittavalle järjestelmälle määritellä turvallisuustaso, joka kuvaa järjestelmän kriittisyyttä tietyllä asteikolla. Kehityshankkeen ja järjestelmän kriittisyyttä arvioidessa tulee kiinnittää huomiota lisäksi työtehtävien tärkeyteen ja toimintojen jatkuvuuden varmistamiseen. Tärkeysluokkia arvioidessa kannattaa myös huomioida eri luokkien kustannusvaikutukset; kriittisten järjestelmien palvelutasovaatimukset saattavat nostaa kuluja huomattavasti. Standardissa ISO/IEC 27001:fi määritellään tietoturvariskien arvioinnin tehtäviksi 1. Tunnistaa riskit Tunnistaa (tietoturvallisuuden hallintajärjestelmään kuuluvat) suojattavat kohteet ja niiden omistajat. Tunnistaa näihin suojattaviin kohteisiin kohdistuvat uhkat. Tunnistaa alustavasti haavoittuvuudet, joita uhat voivat toteutuessaan käyttää hyväkseen. Tunnistaa ne vaikutukset, joita luottamuksellisuuden, eheyden ja käytettävyyden menetyksillä voi olla suojattaviin kohteisiin. Tunnistaa ne vaikutukset, joita voi kohdistua palveluntuottajaverkostosta (kehitettävän järjestelmän käyttöpalvelut, tukipalvelut, järjestelmään liittyvät omat ja muiden toimijoiden järjestelmät) järjestelmän toimintaan. 2. Analysoida ja arvioida riskien vaikutukset Arvioida organisaation liiketoimintaan kohdistuvat vaikutukset (menetetty työaika, rahallinen menetys, maineen menetys ja luottamus palveluun), jotka voivat olla seurauksena turvallisuuden murtumisesta ottaen huomioon suojattavien kohteiden luottamuksellisuuden, eheyden ja käytettävyyden menettämisen seuraukset. Arvioida realistinen todennäköisyys, jolla suojattavien kohteiden turvallisuuden murtuminen voi tapahtua verrattuna vallitseviin uhkiin, haavoittuvuuksiin ja vaikutuksiin ottaen huomioon toteutetut turvamekanismit. Laatia arvio riskitasosta (laadullinen esim. maineen menetys, euromääräinen menetys, todennäköisyys x vaikutus = riskitaso). Päättää riskien hallintakeinoista, onko riski hyväksyttävä vai edellyttääkö sen torjuminen toimenpiteitä. 9/18

Riskin luokittelu Sietämätön riski Merkittävä riski Kohtalainen riski Vähäinen riski Alhainen riski Riskin hallinnan tavoite Riskin poistaminen on välttämätöntä välittömästi. Riskin pienentäminen on välttämätöntä nopealla aikataululla. Riskin pienentäminen sopivalla aikataululla ja kohtuullisin kustannuksin Riskiä seurataan ja pienennetään ilman lisäkustannuksia Riski hyväksytään Riskin hallinnan toimenpiteet Riskin poistaminen on välttämätöntä. Toimenpiteet tulee aloittaa välittömästi. Riskialtista toimintaa ei pidä aloittaa. Riskin välttäminen riskialttiista toiminnasta pidättäytymällä. Riskialtis toiminta pitää keskeyttää, kunnes riski on poistettu. Riskin pienentäminen on välttämätöntä. Toimenpiteet tulee aloittaa nopeasti (tekniset turvamekanismit, organisaation ja yksilöiden toimintaan liittyvät turvamekanismit, riskin siirtäminen esim. sopimuksin tai vakuuttamalla). Riskialtista toimintaa ei pidä aloittaa ennen kuin riskiä pienennetty. Riskialtista toimintaa voidaan jatkaa, mutta kaikkien on tunnettava riski ja toiminta pitää saada loppumaan nopeasti. On ryhdyttävä toimiin riskin pienentämiseksi (tekniset turvamekanismit, organisaation ja yksilöiden toimintaan liittyvät turvamekanismit, riskin siirtäminen esim. sopimuksin tai vakuuttamalla). Toimenpiteiden toteutukselle voidaan suunnitella sopiva aikajänne. Toimenpiteiden kustannuksia on mietittävä tarkasti. Jos riskiin liittyy erittäin haitallisia seurauksia (esimerkiksi vakava henkilövahinko tai tulipalo), on tarpeen selvittää tapahtuman todennäköisyys tarkemmin. Toimenpiteitä ei välttämättä tarvita. Hankitaan parempia ratkaisuja, jotka eivät aiheuta lisäkustannuksia. Tilannetta seurataan ja varmistetaan, että riski pysyy hallinnassa. Toimenpiteitä ei tarvita Ei riskiä Riski hyväksytään Toimenpiteitä ei tarvita Taulukko 1 Riskien hallinta (lähde: VAHTI 7/2003 Riskien arviointi tietoturvallisuuden edistämiseksi valtionhallinnossa ). 3. Tunnistaa ja arvioida riskien käsittelyn vaihtoehdot. Mahdollisia toimenpiteitä ovat: asianmukaisten turvamekanismien käyttö riskien hyväksyminen tietoisesti ja objektiivisesti edellyttäen, että ne selkeästi toteuttavat organisaation tietoturvapolitiikan ja määritellyt riskien hyväksymiskriteerit riskien välttäminen (esim. ei lähdetä johonkin uuteen (liike)toimintaan) liiketoimintariskien siirtäminen sidosryhmille, esim. vakuutusyhtiöille, tietojärjestelmätoimittajille sopimuksilla. luetteloida jäännösriskit. 4. Valita alustavat turvamekanismit riskien käsittelyyn 10/18

Turvamekanismit tulee valita ja toteuttaa siten, että ne täyttävät riskien arviointi- ja käsittelyprosessissa yksilöidyt riskit. Esitutkimusvaiheessa on suositeltavaa suorittaa alustava turvamekanismien luonnostelu, jota täsmennetään vaatimusten määrittelyssä ja edelleen teknisessä suunnittelussa. Tietoturvallisuusuhkien tarkastelussa on suositeltavaa noudattaa yleistä jako kahdeksaan tietoturvallisuuden osa-alueeseen, jotka ovat: Hallinnollinen turvallisuus Henkilöstöturvallisuus Fyysinen turvallisuus Tietoliikenneturvallisuus Laitteistoturvallisuus Ohjelmistoturvallisuus Tietoaineistoturvallisuus Käyttöturvallisuus Lisäksi on hyvä tarkastella tietoturvallisuutta ulkoistamisen sekä ICT-palvelujen jatkuvuuden ja varautumisen hallinnan kannalta. Uhkien tunnistamisen apuna voi käyttää tarkastelussa eri näkökulmia kuten kehitettävän järjestelmän sidosryhmiä, teknisiä komponentteja, liitännäisjärjestelmiä ja järjestelmän avulla toteutettavan prosessin eri vaiheita. Uhkien tunnistamisessa ajattelumallin tulisi pyrkiä löytämään pahimmat mahdolliset väärinkäytökset tai toimintahäiriöt. Tietoturvallisuutta toteuttavia ominaisuuksia ovat: Saatavuus, käytettävyys (ominaisuutta voidaan parantaa esim. tietoliikenneyhteydet tai järjestelmät kahdentamalla ja kuormanjaolla) Luottamuksellisuus (ominaisuutta voidaan parantaa esim. salaamalla luottamuksellinen tieto, lokittamalla tiedon käyttöä) Eheys (ominaisuutta voidaan parantaa esim. tiedon muuttumattomuuden varmistavalla teknisellä menetelmällä, kuten digitaalisella allekirjoituksella) Kiistämättömyys, todistettavuus, jäljitettävyys (ominaisuutta voidaan parantaa esim. kattavalla lokitoiminnallisuudella, digitaalisella allekirjoituksella, lokitietojen muuttumattomuuden varmistamisella oikeudettomia muutosyrityksiä vastaan) Luotettavuus (ominaisuutta voidaan parantaa esim. kattavalla testauksella ja suorituskyvyn varmistamiselle, sekä poikkeustilanteiden varajärjestelyillä) Pääsynvalvonta (ominaisuutta voidaan parantaa esim. vahvalla käyttäjän todentamisella, keskitetyllä käyttöoikeuksien hallinnalla, luotettavilla pääsynhallintaratkaisuilla) Tietosuoja (ominaisuutta voidaan parantaa esim. tiukalla työtehtävään ja tarpeeseen perustuvalla käyttöoikeuspolitiikalla ja pääsynvalvonnalla, kattavalla lokitiedon keräämisellä myös henkilötietojen katselutapahtumista, tietonäkymien eriyttämisellä käyttäjän tehtävän perusteella, seurannalla ja valvonnalla) 11/18

Tunnistettujen tietoturvariskien ja toiminnallisuuden perusteella voidaan hankittavalle järjestelmälle määritellä turvallisuustaso, joka kuvaa järjestelmän kriittisyyttä tietyllä asteikolla (kts. kohta 7.2). Kehityshankkeen ja järjestelmän kriittisyyttä arvioidessa tulee kiinnittää huomiota lisäksi työtehtävien tärkeyteen ja toimintojen jatkuvuuden varmistamiseen. Kehitettävälle järjestelmälle asetettava tietoturvallisuuden taso saattaa määräytyä kokonaan tai osittain lainsäädännön perusteella, mikäli kyseessä on esim. valtionhallinnon erityissuojattava tietojärjestelmä tai muutoin arkaluonteisien tietojen kuten henkilötietojen käsittelyyn tarkoitettu järjestelmä. Esitutkimusvaiheessa olisi hyvä olla mukana lainsäädännön ja toimintaympäristön asiantuntijoita. Tarvittaessa voidaan yksityisyyden suojaan liittyvissä kysymyksissä pyytää lausuntoa tietosuojavaltuutetun toimistolta. Tietoturvariskien arvioinnissa ja turvallisuustason määrittelyssä voidaan käyttää apuna Valtiovarainministeriön ohjeita, joka on laadittu Valtionhallinnon tietoturvallisuuden johtoryhmän (VAHTI) toimesta, kuten esimerkiksi Ohje riskien arvioinnista tietoturvallisuuden edistämiseksi valtionhallinnossa, 7/2003 (http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvall isuus/53828/name.jsp). Tietojärjestelmäkehityksen tietoturvallisuussuositus, 3/2000 (http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvall isuus/3389/3391_fi.pdf). Valtion tietotekniikkahankintojen tietoturvallisuuden tarkistuslista, 6/2001 (http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvall isuus/6193/name.jsp). 7.2 Tärkeysluokat Tärkeysluokkia ovat: 1. tärkeysluokkaan (kriittiset järjestelmät) kuuluvat tärkeät tietojärjestelmät, joiden tietoturvallisuuden ja/tai toipumisvalmiuden on oltava korkealla tasolla. Tietojärjestelmät pyritään pitämään toimintakunnossa kaikissa olosuhteissa siten, että tietojärjestelmällä tulee olla varajärjestelmä, korvaava manuaalinen järjestelmä sekä suunnitelmat toimenpiteistä vakavia häiriö- ja poikkeustilanteita varten. 2. tärkeysluokkaan (tärkeät järjestelmät) kuuluu sisäisille toimintaedellytyksille tärkeitä tietojärjestelmiä, joiden käytettävissäoloaika normaalioloissa tulee varmistaa. Tietojärjestelmän tukemaa toimintaa ja tietotekniikan käyttöä voidaan poikkeusoloissa supistaa. 3. tärkeysluokkaan (korvattavissa olevat järjestelmät) kuuluvat sellaiset tietojärjestelmät, joissa tilapäinen keskeytyminen ei aiheuta välittömiä vahinkoja. Tietojärjestelmä voidaan korvata tai lopettaa poikkeusoloissa. Tärkeysluokitus määrittelee valvonnalle (toiminnan ja tapahtumien seurannalle ja toimenpiteisiin ryhtymiselle) asetettavat vaatimukset. 7.3 Tietojen turvaluokitus ja suojaustasot Kun tärkeysluokitus koskee järjestelmiä, turvaluokittelu koskee asiakirjoja tai tietoja. Lisätietoa tietojen ja asiakirjojen turvaluokittelusta löytyy julkisuuslaista ja siihen liittyvästä asetuksesta ja VAHTI -ohjeistuksesta. 12/18

Salassa pidettävät asiakirjat tai niihin sisältyvät tiedot voidaan luokitella sen mukaan, minkälaisia tietoturvallisuutta koskevia vaatimuksia niiden käsittelyssä on tarpeen noudattaa. Luokittelu voidaan suorittaa myös siten, että tietoturvallisuutta koskevat vaatimukset kohdistetaan vain sellaisiin asiakirjan käsittelyvaiheisiin, joissa erityistoimenpiteet ovat suojattavan edun vuoksi tarpeen. Luokitusta ei saa ulottaa sellaisiin asiakirjan osiin, joissa käsittelyvaatimusten noudattaminen ei suojattavan edun vuoksi ole tarpeen. Alla olevasta taulukosta (taulukko 2) ilmenee eräiden kansainvälisten järjestöjen ja Suomen turvallisuusluokituksien vastaavuus. Kohde Turvallisuusluokka Turvallisuusluokka Turvallisuusluokka Turvallisuusluokka I II III IV Suomi ERITTÄIN SALAINEN LUOTTAMUK- KÄYTTÖ SALAINEN SELLINEN RAJOITETTU EU TRÉS SECRET UE/ SECRET UE CONFIDENTIEL UE RESTREINT UE EU TOP SECRET NATO COSMIC TOP NATO SECRET NATO NATO RESTRICTED SECRET CONFIDENTIAL Taulukko 2 Turvallisuusluokitus Turvallisuusluokittelua edellyttävä aineisto käsitellään vastaavan suojaustason mukaisesti. Esiselvitysvaiheessa on päätettävä myös järjestelmän projektityöskentelyn aikaisista tietoturvallisuusmenettelyistä. 7.3.1 Tietojen suojaustasot Turvaluokiteltavan tiedon käsittelyvaatimuksia osoittavat suojaustasot ovat: 1. Suojaustaso I, jos asiakirjaan sisältyvän salassa pidettävän tiedon oikeudeton paljastuminen tai oikeudeton käyttö voi aiheuttaa erityisen suurta vahinkoa salassapitosäännöksessä tarkoitetuille yleisille eduille; 2. Suojaustasotaso II, jos asiakirjaan sisältyvän salassa pidettävän tiedon oikeudeton paljastuminen tai oikeudeton käyttö voi aiheuttaa merkittävää vahinkoa salassapitosäännöksessä tarkoitetuille yleisille eduille; 3. Suojaustaso III, jos asiakirjaan sisältyvän salassa pidettävän tiedon oikeudeton paljastuminen tai oikeudeton käyttö voi aiheuttaa vahinkoa salassapitosäännöksessä tarkoitetuille yleisille tai yksityisille eduille; 4. Suojaustaso IV, jos asiakirjaan sisältyvän salassa pidettävän tiedon oikeudeton paljastuminen tai oikeudeton käyttö voi aiheuttaa haittaa salassapitosäännöksessä tarkoitetuille yleiselle tai yksityiselle edulle. 7.4 Esiselvitysvaiheen tietoturvallisuusvastuut Esiselvitysvaiheen tietoturvallisuuden kartoituksen lopputuloksena on tietoturvallisuusselvitys, joka sisältää tarvittavilta osin seuraavat asiat: tietojärjestelmän tärkeysluokka ja tietojen suojausluokka on määritetty. vaatimukset järjestelmän jatkuvuus ja valmiussuunnitelmalle vaatimukset järjestelmän tietoturvaratkaisuiksi on tehty. toiminta häiriö- ja poikkeustilanteissa on kuvattu ja vastuista on sovittu. on laadittu lainsäädännön ja tietoturvavaatimusten läpikäynnin tuloksena lista säädöksien vaatimuksien toteutumisesta. 13/18

käsiteltävien tietojen ja järjestelmäkehityksen tietoaineistojen turvaluokittelu sekä projektissa syntyvien dokumenttien säilyttäminen ja merkitseminen organisaation arkistonmuodostussuunnitelman mukaisesti on tehty. tietoturvaratkaisun kustannus-, hyöty- sekä kuormitusvaikutukset on selvitetty järjestelmän omistajalle eri turvatasoilla. työhön osallistuvien palvelun toimittajien salassapitosopimukset on laadittu ja käytettävissä oleva tietoturvaosaaminen varmistettu. järjestelmän alustava riskikartoitus ja järjestelmän merkitys organisaation toiminnalle on dokumentoitu ja riskien käsittely huomioidaan myöhemmissä kehittämisvaiheissa. Esiselvitysvaiheen lopputuloksena ovat kuvattuina ne tietoturvalliset vaihtoehtoiset ratkaisut, joilla järjestelmän tietoturvallisuus voidaan toteuttaa tai ne tukevat kehittämisalueen tavoitteiden toteuttamista. Lopputuloksena ovat myös ratkaisujen alustavat kustannusarviot. Sekä tietoteknisen ja tietoturvan tavoitetilan että tavoiteltavan arkkitehtuurin osalta tehdään tiiviisti iteratiivista tarkastelua seuraavan vaiheen, eli kehittämismahdollisuuksien ja rajoitusten kanssa, ja näiden molempien näkökulmien tuloksena päädytään lopputuloksiin. 8 Tavoiteratkaisun tarkentaminen Kehittämiskohteiden tunnistamisen yhteydessä määriteltyjen tietoteknisten vaihtoehtojen perusteella on valittu jokin tietotekninen tavoiteratkaisu, josta esiselvitystä ollaan tekemässä. Tässä esiselvityksen vaiheessa tavoiteratkaisu kuvataan tarkemmalle tasolle eri osa-alueittain ja laaditaan alustava hankesuunnitelma ja projektiehdotukset (tehdään alustava hankkeen projektointi). Kehittämiskohteiden tunnistamisen yhteydessä (kts. JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen) tehtyjä alustavia kuvauksia sekä myös tässä suosituksessa kuvattuja Markkinakartoitus ja Tietoturvallisuus -vaiheissa tehtyjä selvityksiä ja analyysejä hyödynnetään tavoiteratkaisun kuvaamisessa. Tavoiteratkaisun kuvaus toimii pohjana vaatimusmäärittelylle sekä hankinnalle, joten tässä vaiheessa tarkennetaan myös valittu toteutustapa (kuten avoimen lähdekoodin ratkaisu, valmisohjelmisto, ASP/SAASratkaisu). Esimerkkejä tietoteknisen tavoiteratkaisun eri osa-alueista ovat: vaatimukset järjestelmän toiminnalle (yleisellä tasolla, vaatimuksia tarkennetaan vielä vaatimusmäärittelyvaiheessa). järjestelmän/palvelun rajaukset. vaatimukset tietoturvallisuudelle. alustava järjestelmäkartta ja liittymät muihin järjestelmiin (järjestelmän kompleksisuuden kuvaamiseksi). 8.1 Toiminnallisten hyötyjen kuvaaminen Järjestelmähankinnan toiminnalliset hyödyt kuvataan konkreettiselle tasolle kategorisoituna neljään eri näkökulmaan, jotka ovat taloudellinen hyöty. asiakkaiden / sidosryhmien saamat hyödyt. toiminnan ja prosessien tehostumisen hyödyt. osaamisen ja henkilöstön näkökulmasta saavutettavat hyödyt. 14/18

Hyötyjä ja alustavia mittareita on jo kuvattu kehittämiskohteiden tunnistamisen ja tavoiteratkaisun kuvauksen yhteydessä, joten tässä vaiheessa hyötyjen kuvaaminen onkin lähinnä tiivistämistä, konkretisointia ja dokumentointia. 8.2 Keskeisten laatutavoitteiden määrittely Tavoiteratkaisulle asetetaan sen tulevaa käyttöä ja hyödyntämistä silmällä pitäen keskeiset laatutavoitteet. Tietoteknisissä ratkaisuissa laatukriteereitä voidaan määritellä esim. seuraavista näkökulmista: oikeellisuus ja palvelevuus (tietojärjestelmän kyky täyttää asiakastarpeet). yksiselitteisyys (ymmärrettävä ja ymmärretään yhteisellä tavalla). täydellisyys (kaikki oleellinen ja tarvittava on huomioitu). yhdenmukaisuus (ratkaisun ristiriidattomuus ja selkeys). laitettavissa järjestykseen (ratkaisun osat priorisoitavissa esim. kriittisyyden kannalta). muutettavuus (muutos helppo ja turvallinen). jäljitettävyys (osiin voidaan palata ja viitata). Laatutavoitteiden määrittelyn yhteydessä on syytä myös miettiä ja kuvata keskeiset kriteerit ja mittarit, joilla laatutavoitteiden toteutumista arvioidaan ja mitataan sekä toteutustyön kuluessa että lopputuloksen valmistuttua. On myös hyvä huomioida olemassa olevat alan laatustandardit. 8.3 Perusteet kilpailutukselle Esiselvityksen yhteydessä muodostuu se perustieto, jonka perusteella kilpailutusmenettely voidaan toteuttaa tulevan hankkeen tai projektin osana. Esiselvityksessä tuotettu perustieto täsmentyy vielä tietojärjestelmähankinnoissa vaatimusmäärittelyn kautta. Esiselvityksessä pitää esittää ehdotus hankittavasta tietojärjestelmästä eli hankitaanko tietojärjestelmä räätälöitynä, sovellusvuokrauksena, valmisohjelmistona tai palveluna. Päädytäänpä mihin ratkaisuun tahansa, on esiselvityksessä jo otettava kantaa siihen, miten vaatimusmäärittelyt pitää laatia. Näiden linjanvetojen tekeminen vasta hankinnan vertailuvaiheessa nostaa hankinnan riskitasoa ja voi tehdä tarjouksista vertailukelvottomia tai vertailuista helposti riitautettavia. Jos on kyse uusittavasta tietojärjestelmästä, on hyvä kerätä luetteloon järjestelmän ne piirteet, jotka edellytetään vaatimuksina toteutuvan uudessa järjestelmässä. Esiselvityksessä on otettava kantaa esim. seuraaviin asioihin: tietojärjestelmäratkaisun/muun hankinnan kilpailutuksen menettelytapa, kuten esimerkiksi avoin kilpailutus, rajoitettu menettely. kilpailutuksen alustava aikataulu, vaiheistus ja aikapuskurit (kuukausi- tai vuositasolla): ennakko- ja hankintailmoituksen tekeminen osallistumishakemusten viimeinen vastaanottoajankohta tarjouspyynnön lähettämisajankohta tarjousten vastaanoton ajankohta hankintapäätöksen tekoajankohta sopimusten allekirjoituksien valmistumisen ajankohta tarvittavat asiantuntijat (kilpailutuksen asiantuntija, sopimusjuristi, tekninen asiantuntija, kilpailutuksen aikana kysymyksiin vastaavat asiantuntijat yms.). hankinnat, joita ei kilpailuteta (esim. vuokrataan väliaikaisia resursseja, laitteita, testausvälineitä, tiloja jne., teetetään tavoiteratkaisuun komponentteja toisessa projektissa tai hankkeessa, hankitaan laitteita ja niiden varusohjelmistoja jne.). 15/18

Esiselvityksessä pyritään osaltaan luomaan perusteet onnistuneelle kilpailutukselle siten, että kilpailutuksessa tarvittavat tiedot ovat selkeät ja yksiselitteiset. Esiselvitys on osa hankintaprosessia (hankinnan valmisteluvaihe), mutta se ei ole osa hankintamenettelyprosessia, 8.4 Tavoitetilan suunnittelun lopputulosten tarkastelu Tavoitetilan suunnittelun lopputuloksia kokonaisuudessaan tarkastellaan seuraavien osa-alueiden pohjalta: tavoitetilan vastaavuus strategisiin ja muihin tavoitteisiin. tavoitetilan vastaavuus kokonaisuudessaan esiselvityksen ja kehittämiskohteen tavoitteisiin. tavoitetilan kattavuus suhteessa asetettuihin tavoitteisiin. tavoitetilan relevanssi, ts. tavoitetilassa on määritelty kaikki olennainen riittävälle tasolle. tavoitetilan realistisuus ja toteuttamiskelpoisuus. On tärkeää, että kun valitun ratkaisun määrittelyä ollaan jatkamalla vaatimusmäärittely-vaiheella, ratkaisun tulisi olla mahdollisimman selkeästi rajattu esiselvityksen tuloksena. Lisäksi tarvittaessa tavoitetilan kuvauksessa voidaan määritellä vaiheittainen eteneminen, mikäli tätä ei ole kuvattu aiemmin esim. kehittämiskohteiden tunnistamisvaiheessa. 8.5 Jatkotoimenpide-ehdotuksen laatiminen Laaditaan jatkotoimenpide-ehdotus, joka voi olla, että kehitysprojektista tai -hankkeesta tehdään suunnitelma kehitysprojekti tai -hanke keskeytetään (ainakin tässä vaiheessa), koska sille ei ole taloudellisia tai muita edellytyksiä. osia kehityshankkeesta tai -projektista toteutetaan ja osia ei (ainakaan tässä vaiheessa). Ns. pakollisissa hankkeissa (esim. lainsäädäntömuutos) vaihtoehtoa ei toteuteta ei ole olemassa, mutta sellaisissakin hankkeissa tai projekteissa voi olla osia, joita esiselvityksessä on tutkittu, mutta niitä ei nähdä tarpeelliseksi / mahdolliseksi toteuttaa. Esimerkiksi voi olla, että lakimuutosten vaikutukset toteutetaan pelkästään tietojärjestelmiin, samassa yhteydessä on tutkittu myös vaihtoehtoja kehittää prosesseja tai toimintamallia, ja päädytään ratkaisuun, jossa näitä ei kuitenkaan toteuteta. 9 Esiselvityksen päättäminen ja dokumentointi Esiselvitys päätetään kun sovittu dokumentaatio on tuotettu, käsitelty ja hyväksytty. esiselvitysraportti on laadittu, käsitelty ja hyväksytty. Esiselvityksestä laaditaan esiselvitysraportti (kts. liite 1), johon pyritään keräämään kaikista vaiheista kaikki olennainen tieto, kokemukset ja näkemykset. Kaikkien esiselvityksen vaiheiden tulokset, kuvaukset, analyysit, johtopäätökset ja päätökset dokumentoidaan huolellisesti ja selkeästi. Dokumentaatiota voi tuleva kehityshanke ja sen projektit hyödyntää myöhemmässä työssään. Esiselvitysraportti sisältää mm. seuraavat osa-alueet: markkinakartoituksen tulokset toimittajat ja tuotteet käynnissä olevat hankkeet puitesopimukset tavoiteratkaisun kuvaus järjestelmän toiminnallisuus 16/18

järjestelmävaatimukset tietoturvallisuus tarkennettu kustannus- ja hyötyanalyysi laatutavoitteet integrointi muihin järjestelmiin alustava konversiosuunnitelma kilpailutuksen perusteet jatkotoimenpide-ehdotukset ja niiden vaiheistus Mikäli esiselvitys on suoritettu projektina, projekti päätetään ja sen resurssit vapautetaan organisaation projektinhallintamenettelyssä kuvatun päättämismenettelyn mukaisesti, kun projektin työt on suoritettu. 10 Päätöksenteko hankkeen jatkamisesta Ohjausryhmä tai kehittämiskohteen prosessinomistaja arvioi organisaation hyväksymismenettelyjen mukaisesti, objektiivisesti ja kriittisestikin kuvatun tavoitetilan ja esiselvityksessä tehtyjen analyysien tulosten, johtopäätösten ja jatkotoimenpide-ehdotuksen perusteella onko esiselvityksen toteutus edennyt olennaisilta osiltaan oikeaan suuntaan. ovatko lopputulokset ja niistä tehdyt analyysit edelleen kehittämistavoitteita ja siten etenemistä tukevia. ovatko määritellyt tavoitehyödyt esiselvityksen asettamisvaiheen linjausten mukaisia ja edelleen relevantteja. onko hankintaa hyödyntävillä tahoilla yhteinen näkemys hankinnasta (huom. yhteisesti sovitut termit). onko organisaatiolla käytettävissään riittävät resurssit (rahaa, asiantuntemusta, henkilötyöaikaa) hankinnan toteuttamiseen. onko tietojärjestelmän omistaja selvitetty. Mikäli edellä mainittuihin kysymyksiin ei saada selkeitä vastauksia tai niihin joihinkin tulee kielteinen vastaus, on päätöksenteolle kaksi vaihtoehtoa eli esiselvitysprojektin uudelleensuunnittelu ja paluu taaksepäin vähintäänkin tavoitetilan kuvaukseen tai niihin osioihin jotka ovat vielä epäselviä. esiselvitysprojektin keskeyttäminen tarpeettomana. Mikäli taas vastaukset ovat linjassa tavoitteisiin nähden, tulokset ovat yksiselitteisiä ja selkeitä ja tavoitehyödyt johdettu ja tarkennettu objektiivisesti ja tehtyihin selvityksiin perustuen, ohjausryhmässä päätetään esiselvityksen jatkamisesta kehityshankkeen valmisteluun. 10.1 Hankittavan tietojärjestelmän omistajuus Ennen hankinnan valmisteluun etenemistä, on selvitettävä tulevan tietojärjestelmän omistajuus organisaatiossa eli mikä organisaatioyksikkö vastaa tietojärjestelmästä sen elinkaaren ajan ja mitkä ovat sen sidosryhmät. 11 Opastavat tiedot Tätä suositusta ylläpitää Julkisen hallinnon tietohallinnon neuvottelukunta JUHTA, puh. 0295 16001, sähköposti: jhs-sihteeri@jhs-suositukset.fi. JHS-järjestelmän verkkosivut: http://www.jhs-suositukset.fi/ 17/18

12 Liitteet Liite 1: Esiselvitysraportin sisällysluettelo Liite 2: Konversio 18/18