JHS XXX ICT-palvelujen kehittäminen: Esiselvitys

JHS XXX ICT-palvelujen kehittäminen: Esiselvitys Versio: Julkaistu: Voimassaoloaika: Sisällys 1 Johdanto... 2 2 Soveltamisala... 3 3 Termit ja määritelmät... 3 4 Esiselvityksen käynnistämisen edellytykset... 4 5 Toimintaympäristön kartoitus... 6 5.1 Markkinakartoitus... 6 6 Konversio... 8 6.1 Konversion suunnittelu ja tavoitteet... 8 7 Tietoturvallisuuden kartoitus... 9 8 Tavoiteratkaisun tarkentaminen... 11 8.1 Toiminnallisten hyötyjen kuvaaminen... 11 8.2 Keskeisten laatutavoitteiden määrittely... 11 8.3 Perusteet kilpailutukselle... 12 8.4 Tavoitetilan suunnittelun lopputulosten tarkastelu... 12 8.5 Jatkotoimenpide-ehdotuksen laatiminen... 12 9 Esiselvityksen päättäminen ja dokumentointi... 13 10 Päätöksenteko hankkeen jatkamisesta... 13 10.1 Hankittavan tietojärjestelmän omistajuus... 14 11 Opastavat tiedot... 14 12 Liitteet... 14 1/14

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. Tätä suositusta täydentää JHS XXX ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen suositus: 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. Suosituksessa on huomioitu lisäksi kuntanäkökulma. Tässä suosituksessa kuvataan oheisen prosessin (kuva 2) kohtaa Toimeenpanon suunnittelu 2/14

Kuva 2 Kokonaisarkkitehtuurin suunnitteluprosessi, ValtIT 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. 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 XXX 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 Termit ja määritelmät Tässä kappaleessa on kuvattu tälle suositukselle oleellisia termejä ja niiden määritelmiä. 3/14

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. järjestelmäarkkitehtuuri Kokonaisarkkitehtuurin osa-alue 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. 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 Kokonaisvaltainen arkkitehtuurillinen lähestymistapa ICT:n (informaatio-ja kommunikaatioteknologia) haltuunottamiseksi ja hallinnoimiseksi. Malli, jossa tietotekninen varustus kuvataan ja huomioidaan osana organisaation toimintaa. 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 osa-alue-näkökulma, joka kuvaa organisaation toiminnan ja toimintaympäristön keskeiset viitekehykset sekä peruslinjauksia suositeltavista standardeista ja teknologioista. tietoarkkitehtuuri Kokonaisarkkitehtuurin osa-alue- näkökulma, joka tutkii informaation rakenteistamista, organisointia ja luokittelua, välitystä. Arkkitehtuurissa tarkastellaan organisaation informaatiotarpeita, informaatio- /tietopääomaa ja niiden välisiä suhteita, informaatio-arvoketjuja. toiminta-arkkitehtuuri Kokonaisarkkitehtuurin osa-alue näkökulma, joka kuvaa organisaation strategisiin vaatimuksiin liittyvää ydintoimintaa eli ydintoimintaprosesseja ja näitä tukevia tukiprosesseja, resursseja sekä palvelutarjontaa. 4 Esiselvityksen käynnistämisen edellytykset Ennen esiselvityksen aloittamista on selvitettävä, ovatko JHS XXX ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen suosituksessa mainitut lopputulokset valmiita ja käytettävissä. 4/14

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 ja 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. arkkitehtuurin 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/14

Kuva 3 Esiselvityksen vaiheet 5 Toimintaympäristön kartoitus 5.1 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ää. Kartoitus tulee suorittaa tasapuolisesti ottaen huomioon olemassa olevat markkinat. Lisäksi kannattaa selvittää mahdollisuudet tietojen yhteiskäyttöön (perusrekisterien hyödyntäminen, yhteisten tietolähteiden kehittäminen) sekä muihin yhteisiin tukipalveluihin. Perusrekistereitä ovat mm. VTJhenkilötietorekisteri ja YTJ-yritystietorekisteri, yhteisiä tukipalveluita esim. tunnistus- ja aikaleimapalvelut. 5.1.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). 5.1.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 alkavat hankkeet, joissa on sama tai osittain sama tavoite. 6/14

Mahdollisuudet osallistua hankintaan tai hankkeeseen kannattaa arvioida ratkaisuvaihtoehtoja määriteltäessä. Kunta-alan- ja julkisen hallinnon hankkeista saa tietoa esimerkiksi KuntaIT:n Hanke- ja palvelukartasta (http://hapa.netum.fi/hapa/) ja ValtIT:n sekä KuntaIT:n internet-sivustoilta. Julkisen hallinnon hankkeista saa tietoa mm. Valtiovarainministeriön ylläpitämästä Hankerekisteristä (http://www.hare.vn.fi/maloitussivu.asp?h_iid=&tvno=1&styp=hankerekisteri). 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.1.3 Avoimen lähdekoodin ratkaisut Mikäli esiselvityksessä 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-, koulutus- tai käyttöpalvelut. On myös syytä varmistaa, että kyseisen avoimen koodin ratkaisun yllä mainittuja palveluita on saatavilla järkevillä kustannuksilla. Esiselvityksessä tulee myös arvioida elinkaarikustannuksia 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 XXX Avoimen lähdekoodin hankintaopas suositus opastaa avoimen lähdekoodin hankinnoissa (julkaistaan alkuvuodesta 2009). 5.1.4 Vaiheen lopputulokset Markkinakartoitusvaiheen lopputuloksen 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ä vastaavien hankkeita tai yhteishankintoja, joita voitaisiin hyödyntää. selvitys avoimen lähdekoodin käytöstä järjestelmän hankinnassa on tehty, mahdollisuus yhteispalvelujen ja rekisterien käyttöön on selvitetty. 7/14

6 Konversio Konversiolla tarkoitetaan tiedon siirtämistä talletusmuodosta toiseen esim. verkkotietokannasta relaatiotietokantaan, vanhan tietokannan tietojen siirtoa uudempaan kantaan tai tietokantojen yhdistämistä. 6.1 Konversion suunnittelu ja tavoitteet Konversiota varten on oltava kuvattuna nykyinen tietoturva-arkkitehtuuri, tietoarkkitehtuuri ja kuvaukset tietokannoista. Mikäli lähdekannan/kantojen kuvaukset ovat vanhoja tai ne ovat kadonneet, on varauduttava tekemään minimitason täyttävä kuvaus esim. reverse -tekniikalla jotain apuohjelmaa käyttäen. Esiselvitysvaiheessa pitää tehdä yleiskuvaus tai ainakin jonkinlaiset määritykset tai mallinnukset tulevasta tietokannasta. Lisäksi tulee tehdä lähdetiedon ja lähtöjärjestelmän kuntoarvio sekä selvittää alustavasti vastaanottavan järjestelmän asettamat vaatimukset siirrettäville tiedoille. Lähtötietojen kuntoarviolla haetaan vastausta siihen, onko alkuperäinen tieto tarpeeksi laadukasta siirrettäväksi seuraavaan elinkaaren vaiheeseen ja miten se sellaiseksi tunnistetaan ja tehdään. Kuntoarviossa kiinnitetään huomiota mm. seuraaviin tekijöihin: tietojen oikeellisuus ja eheys tietojen kattavuus lähtötiedon kannan tyyppi Tietojen eheyttä, kattavuutta ja oikeellisuutta on tutkittava mieluiten ohjelmallisesti. Huonokuntoisen tiedon kunnostamiseen alkuperäisessä lähteessä, tietojen korjaamiseen ja tietojen hylkäämiseen on otettava kantaa mahdollisimman aikaisessa vaiheessa, koska hylkäämistä lukuun ottamatta kaikki muut vaihtoehdot ovat varsin työläitä. Konversion suorittamiselle tulee asettaa tavoitteet mm. aikataulun ja laadun suhteen. Myös tulevalle tietokannalle asetetaan tavoitteet, mutta esiselvitysvaiheessa vain yleisellä tasolla. Konversion keskeisten laatutavoitteiden määrittelyssä huomioidaan seuraavat tekijät: tiedon muuttumattomuus lähteen ja kohteen välillä. tiedon jäljitettävyys konversioissa, joissa esim. käsitellään rahaa tai kun tietoa siirretään useista lähteistä. kohteen asettamat vaatimukset. suurien tietomassojen konversion tehokkuus eli mm. läpimenoaikojen arviointi. läpimenoaikojen rajat tuotantokatkon takia. Mikäli konversio on tarkoitus kilpailuttaa, kuvausten laatu ja ajantasaisuus sekä realistinen arvio tietosisällön laadusta ovat tarpeen toimittajakandidaateille mahdollisimman oikean työmääräarvion laatimisessa. 8/14

7 Tietoturvallisuuden kartoitus Esiselvitysvaiheen tärkein tietoturvallisuustehtävä on kartoittaa suunnitteilla olevaan uuteen järjestelmään liittyvät tietoturvariskit ja tietoturvallisuuden pettämisestä toiminnalle aiheutuvat menetykset. Vastaavasti on selvitettävä toimintamallien muutokseen liittyvät tietoturvatekijät, kuten esimerkiksi tietosuojaan liittyvät tekijät. Tekijöitä ovat mm. autorisointi ja pääsynhallinta käyttöoikeudet turvaluokiteltujen materiaalien säilytys ja tuhoaminen. Tarvittaessa voidaan myös pyytää lausuntoa tietosuojavaltuutetulta merkittävissä henkilötietoja koskevissa hankkeissa. 7.1.1 Tekniset tietoturvaratkaisut 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ä. Tunnistettujen tietoturvariskien ja toiminnallisuuden perusteella voidaan hankittavalle järjestelmälle määritellä turvallisuustaso, joka kuvaa järjestelmän kriittisyyttä tietyllä asteikolla (kts. kohta 7.1.1.1). 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. 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_tietoturvallisuu s/53828/name.jsp). Tietojärjestelmäkehityksen tietoturvallisuussuositus, 3/2000 (http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvallisuu s/3389/3391_fi.pdf). 7.1.1.1 Tärkeysluokat 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ävyys 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. 9/14

Tärkeysluokitus määrittelee valvonnalle (toiminnan ja tapahtumien seurannalle ja toimenpiteisiin ryhtymiselle) asetettavat vaatimukset. Turvaluokittelu koskee asiakirjoja tai tietoja ja tärkeysluokitus järjestelmiä. Lisätietoa tietojen ja asiakirjojen turvaluokittelusta löytyy mm. Julkisen hallinnon suosituksesta JHS 147 Salassa pidettävien tietojen ja asiakirjojen turvaluokittelu (http://www.jhs-suositukset.fi/suomi/jhs147) ja tärkeysluokituksesta VAHTI ohjeistuksesta. Tässä yhteydessä on päätettävä myös järjestelmän projektityöskentelyn aikaisista tietoturvallisuusmenettelyistä. 7.1.1.2 Esiselvitysvaiheen tietoturvallisuusvastuut Esiselvitysvaiheen tietoturvallisuus-selvityksen lopputuloksena järjestelmän omistaja/ohjausryhmä hyväksyy lopputulokset. tietoturvallisuusvastaava tarkastaa ja varmistaa, että ehdotetut ratkaisut ovat organisaation tietoturvallisuuspolitiikan ja ohjeistuksen mukaisia. tärkeysluokkaan yksi kuuluvan järjestelmän osalta järjestelmän omistaja hankkii turvaratkaisulle ylimmän johdon hyväksynnän. esiselvityksen tietojen perusteella ylin johto päättää järjestelmän tärkeysluokan ja päättää tietoturvallisuuteen liittyvistä jatkotoimista kun on kyse organisaation toiminnalle erittäin kriittisestä hankkeesta. Arkkitehtuurien osalta pääsääntönä on tietty stabiilius, arkkitehtuurilinjauksien tulee olla pitkäikäisiä ja niihin tehtävät muutokset on oltava tarkkaan harkittuja. Kuitenkin jossakin tapauksessa arkkitehtuureja voi olla tarpeen ja perustellusti tarkistaa tai muuttaa. Arkkitehtuuritarkastelun tekeminen perustuu tietotekniseen tavoitetilaan (joka on siis johdettu toiminnallisista tavoitteista), ja tavoitearkkitehtuuri kuvataan näistä lähtökohdista. 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. 7.1.2 Vaiheen lopputulokset Vaiheen lopputuloksena ovat kuvattuina tietoturvalliset vaihtoehtoiset tietotekniikkaratkaisut, joilla kehittämisalueen tavoitteet voidaan toteuttaa tai ne tukevat kehittämisalueen tavoitteiden toteuttamista. Lopputuloksena ovat myös ratkaisujen alustavat kustannusarviot. Lisäksi tietoturvakuvaukset on tehty. tietojärjestelmän tärkeysluokka ja tietojen suojausluokka on määritetty. vaatimukset järjestelmän tietoturvasuunnitelmaan on tehty. on laadittu lainsäädännön ja tietoturvavaatimusten läpikäynnin tuloksena lista säädöksien vaatimuksien toteutumisesta. 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. 10/14

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 xxx 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 (mahdolliselle) vaatimusmäärittelylle sekä hankinnalle, joten tässä vaiheessa tarkennetaan myös valittu toteutustapa (kuten avoimen lähdekoodin ratkaisu, valmisohjelmisto, ASP/SAAS-ratkaisu, OSS). 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 (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. 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). 11/14

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. 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 se hyvät /parhaat 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 yms.). hankinnat, joita ei kilpailuteta (esim. vuokrataan väliaikaisia resursseja, laitteita, testausvälineitä, tiloja jne., teetetään komponentteja projektin ulkopuolella, hankitaan laitteita ja niiden varusohjelmistoja jne.). Esiselvityksessä pyritään osaltaan luomaan perusteet onnistuneelle kilpailutukselle siten, että kilpailutuksessa tarvittavat tiedot ovat selkeät ja yksiselitteiset. Hankinta on erillinen prosessi ja esiselvityksen tehtävät on tuoda sille hankinnan kohdetta ja tavoitteita koskeva aineisto. 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. 8.5 Jatkotoimenpide-ehdotuksen laatiminen Laaditaan jatkotoimenpide-ehdotus, joka voi olla, että kehityshanke projektoidaan. 12/14

kehityshanketta keskeytetään (ainakin tässä vaiheessa), koska sille ei ole taloudellisia tai muita edellytyksiä. kehityshankkeesta osia 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 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 suunnitellut tehtävät on suoritettu. sovittu dokumentaatio on tuotettu, käsitelty ja hyväksytty. esiselvitysraportti on laadittu, käsitelty ja hyväksytty. Esiselvityksestä laaditaan esiselvitysraportti, 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: tavoiteratkaisun kuvaus toimintaympäristön kuvaus tarkennettu kustannus- ja hyötyanalyysi kilpailutuksen perusteet konversion alustava suunnitelma yleiskuvaus tietokannasta tietoturvallisuusselvitykset 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. 13/14

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 (09) 16001, sähköposti: jhs-sihteeri@jhs-suositukset.fi. JHS-järjestelmän verkkosivut: http://www.jhs-suositukset.fi/ 12 Liitteet Liite 1: Esiselvitysraportin sisällysluettelo 14/14