JHS XXX ICT-palveluiden kehittäminen: Kehittämiskohteiden tunnistaminen

Samankaltaiset tiedostot
JHS 171 ICT-palveluiden kehittäminen: Kehittämiskohteiden tunnistaminen

ICT-palvelujen kehittäminen - suositussarja Suvi Pietikäinen Netum Oy

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

ICT-palvelujen kehittäminen suositussarja Suvi Pietikäinen Netum Oy

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Strategian kuvaaminen strategiakartan avulla

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/ /2011

Sähköisten viranomaisaineistojen arkistoinnin ja säilyttämisen palvelukokonaisuus

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 3. Arkkitehtuurin nykytilan ja tavoitetilan kuvaus

TAPAS - puheenvuoro - TAPAS-päätösseminaari Tommi Oikarinen, VM / JulkICT

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 1. Strategian kuvaaminen strategiakartan avulla

Valtion taloushallinnon kokonaisarkkitehtuurin tavoitetila

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Kokonaisarkkitehtuurin kehittäminen Satu Pajuniemi. Conversatum Oy

<Viitearkkitehtuurin nimi> toimeenpanosuunnitelma

Keskustelutilaisuus ICT-palvelujen kehittäminen -suositussarjasta

<<PALVELUN NIMI>> Palvelukuvaus versio x.x

ICT muutos kunta- ja palvelurakennemuutoksessa. Selvitysvaiheen tehtävät

Raportointi >> Perusraportti Palautepyyntö: ICT palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen

TIETOHALLINTOLAKI (LUONNOS) Korkeakoulujen IT-päivät Erityisasiantuntija Olli-Pekka Rissanen

Opistojohtaminen muutoksessa hanke. Kansanopiston kehittämissuunnitelma. Tiivistelmä kehittämissuunnitelman laatimisen tukiaineistoista

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

Toivakan kunnan teknologia-arkkitehtuuri

Toimintaja rjestelma (johtamisja rjestelma ) opas

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi

Terveydenhuollon alueellisen ja paikallisen kokonaisarkkitehtuurin hallintamallin suunnitteluprojekti 4/11 11/

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa

Valtionhallinnon arkkitehtuurin suunnittelu -hanke

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

JHS129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen. JHS-jaosto

Tietojärjestelmien hankinta ja ICT-projektit

Valtion taloushallinnon kokonaisarkkitehtuuri

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

Projektin suunnittelu A71A00300

Mitä kokonaisarkkitehtuurityöllä haetaan? Miika Nurminen Johtaja, Kokonaisarkkitehtuuriratkaisut QPR Software Oyj

Kieku ohjausmalli ja elinkaaren hallinta. Tomi Hytönen Valtiovarainministeriö Henkilöstö- ja hallintopolitiikkaosasto

Luotain-arviointi. Nykytila-arvio toiminnan osa-alueesta. Trust, Quality & Progress. Jatkuvuus Tietosuoja Tietohallinto Tietoturvallisuus

COBITilla tietohallinnon prosessien ja projektien tehokkuus kuntoon

PALVELUKUVAUS järjestelmän nimi versio x.x

Kuntasektorin kokonaisarkkitehtuuri

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

JHS XXX ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurimenetelmä

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy

Miten ideoidaan ja kehitetään uusia toimintatapoja? Juha Koivisto, THL

Jyväskylän seudun kuntien ICT muutostuen toteutusprojekti. Toteutussuunnitelma

YRKK18A Agrologi (ylempi AMK), Ruokaketjun kehittäminen, Ylempi AMK-tutkinto

Strategia prosessista käytäntöön!

QL Excellence -käsikirja

JHKA-jaosto. 1. Työsuunnitelma: 2015 toimikauden loppu - Esitys: JUHTA hyväksyisi työsuunnitelman 2. Taustamateriaali tilanteesta

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous

KuntaIT Mikä muuttuu kunnan tietotekniikassa? Terveydenhuollon Atk-päivät Mikkeli Heikki Lunnas

Kokemuksia kokonaisarkkitehtuurityöstä

Projektin suunnittelu A71A00300

Tietojohtamisen arviointimalli

TIETO- JÄRJESTELMÄN PROSESSIEN KEHITTÄMINEN

Turun kaupungin tietohallintostrategia Tiivistelmä

Paikkatiedon kokonaisarkkitehtuuri LUONNOSTELUA

Market Expander & QUUM analyysi

Valtionhallinnon arkkitehtuurin kehittäminen

Arviointi ja mittaaminen

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Sosiaali- ja terveydenhuollon ATK-päivät 2019

Ei näyttöä tai puheen tasolla

Parku-projekti Päivähoidon hallinnon ja asiakasrajapinnan hallinnan prosessien arviointi kuntaliitosnäkökulmasta KAmenetelmää

UMTK- SUUNNITTELUPROJEKTIN ESITTELY (UMTK = MML:N UUSI MAASTOTIETOJEN TUOTANTOJÄRJESTELMÄ)

SOTE KA hallintamallin uudistaminen

Tietojärjestelmän osat

Lausunto Palvelut ja tiedot käytössä - Julkisen hallinnon ICT:n hyödyntämisen strategia

Tietojärjestelmät muutoksessa: Alueiden ja kuntien sote - kokonaisarkkitehtuurityö

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija

JUHTA / VAHTI työpaja Valtiovarainministeriö, Kimmo Järvinen Valtiokonttori. Tietojohtaminen ja HR

Maakunnan tiedolla johtaminen ja tietoaltaan hyödyntäminen Jyrki Tirkkonen Liiketoimintapäällikkö, Tiedolla johtaminen ja informaation hallinta

Ohjelmajohtamisen kehittäminen

Sosiaali- ja terveysministeriön näkökulma sote-muutokseen ja tietohallintoyhteistyöhön

ONION-hanke. Tiivistelmä

Tietoturvapolitiikka

JHS- seminaari Uudet suositukset ICT- palvelujen kehittämiseen

Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria?

VAKAVA Valtakunnallinen kokonaisarkkitehtuurin suunnittelun ja kuvaamisen tukiprojekti

JHS 179 suosituksen uudistamishanke Suositusluonnoksen ja liitteiden esittely Keskustelutilaisuus Kansallismuseon auditorio

Kohti kokonaisvaltaista tietojohtamista Kokonaisarkkitehtuuri johtamisen tukena Leena Kononen

CERION 2.0 Lea Ryynänen-Karjalainen

Työpaja 3: ICT-tuen jatkovaihe tavoitetila ja kehittämiskohteet

Kuntasektorin kokonaisarkkitehtuuri

Miten suojautua nykyisiltä tieto- ja kyberuhilta? Petri Vilander, Kyberturvallisuuspäällikkö, Elisa Oyj

Kuntien ICT-muutostukiohjelma. Kunta- ja palvelurakennemuutostuen ICT-tukiohjelman uudelleen asettaminen

1 Teknisen ja ympäristötoimen mittareiden laatiminen

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista)

Kehittämisprosessin vaihemalli. Pirkko Mäkinen Asiantuntija, Työturvallisuuskeskus

Digipäivä, Hallintoryhmä Sipoo

Kokonaisarkkitehtuuri julkisessa hallinnossa 2016

Valtionhallinnon lausuntoprosessin kehittäminen ja digitaalinen tietojen hallinta Digitaaliseen tietojen hallintaan Sotu seminaari

ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ

Miten suunnittelu- ja kehitystyötä toteutetaan arkkitehtuurilähtöisesti

JHS-järjestelmä. Tommi Karttaavi

Asikkala Valtuustoseminaari

Yhteentoimivuutta kokonaisarkkitehtuurilla

Projektin tilanne. Tavaraliikenteen telematiikka-arkkitehtuuri Liikenne- ja viestintäministeriö

Transkriptio:

JHS XXX ICT-palveluiden kehittäminen: Kehittämiskohteiden tunnistaminen Versio: Julkaistu: Voimassaoloaika: Sisällys 1 Johdanto... 2 2 Soveltamisala... 3 3 Termit ja määritelmät... 3 4 Kehittämiskohteiden tunnistamisen aloittaminen... 4 4.1 Arkkitehtuurimenetelmän hyödyntäminen kehittämiskohteiden tunnistamisessa... 5 5 Nykytilan kartoitus... 6 5.1 Kuvaa nykyarkkitehtuurit... 6 5.2 Analysoi nykytilan toiminta... 8 5.3 Listaa ja analysoi kehitystarpeet... 8 5.4 Selvitä taloudelliset tunnusluvut... 9 5.5 Nykytilan kartoitus ja analysointivaiheen lopputulokset... 9 6 Tavoitetilan suunnittelu ja kuvaaminen... 10 6.1 Tavoitetilan hahmotus, rajaaminen ja nykytila... 10 6.2 Tavoitetilan suunnittelu... 12 6.3 Tavoitehyötyjen määrittely ja mittarien laadinta... 15 6.4 Tietoteknisten mahdollisuuksien ja rajoitusten määrittely... 17 6.5 Toiminnan kehittämismahdollisuuksien ja rajoitusten määrittely... 18 6.6 Tavoitetilan analyysit... 19 6.7 Kehittämisvaihtoehtojen vertailu ja valinta... 21 7 Tavoiteratkaisun kuvaaminen... 24 7.1 Toimeenpanon suunnittelu... 24 8 Päätöksenteko ja dokumentointi... 27 8.1 Valmistuvat dokumentit... 27 9 Opastavat tiedot... 28 9.1 Liitteet... 28 1/28

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 XXX ICT-palveluiden kehittäminen: Esiselvitys -suositus täydentää tätä suositusta. Vaiheena suositus sijoittuu kokonaisarkkitehtuurin kuvauksen 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. 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) kohtia Tavoitetilan hahmotus ja nykytila, Tavoitetilan suunnittelu sekä Toimeenpanon suunnittelu tunnistettujen ja valittujen kehittämiskohteiden kannalta. 2/28

Kuva 2 Kokonaisarkkitehtuurin suunnitteluprosessi, ValtIT Arkkitehtuurimenetelmä. 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 osa-vaiheista, joita yleensä ovat esiselvitys, vaatimusmäärittely, hankinta, tietojärjestelmän määrittely, 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 kehittämishankkeen tai -projektin aloittamista. 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ä. arkkitehtuuri Arkkitehtuuri määrittelee organisaation toiminnan, tietotarpeiden, tietojärjestelmien ja teknologiaratkaisujen mallintamisen, kuvaamisen sekä suunnittelemisen yhteisesti sovitun mallin mukaisesti. ASP Sovellusvuokrauspalvelun tarjoaja, Application Service Provider, tarjoaa asiakkaille tietojärjestelmän käyttöön palveluna verkon kautta. 3/28

GAP-analyysi GAP-analyysi on menetelmä, jolla voidaan mm. verrata ja kuvata nykytilan ja tavoitetilan välistä eroa. 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 (liike)toimintaa. palvelukuvaus Kuvaus, jossa palvelun toiminnallisuudet ja käyttötarkoitukset, yhteydet muihin palveluihin sekä palvelun elinkaari on kuvattu. palvelukartta Palvelukartta kuvaa visualisesti organisaation palvelut ja niiden yhteydet sekä vastuulliset tahot. 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. 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 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 informaatio tarpeita informaatio- /tietopääomaa ja niiden välisiä suhteita, informaatio-arvoketjuja. toiminta-arkkitehtuuri Kokonaisarkkitehtuurin osa-alue näkökulman, joka kuvaa organisaation strategisiin vaatimuksiin liittyvää ydintoimintaa eli ydintoimintaprosesseja ja näitä tukevia tukiprosesseja, resursseja sekä palvelutarjontaa. 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 4/28

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. Myös kuvaukset nykytoiminnasta olisi hyvä olla käytettävissä jo ennen kehittämishankkeen tai selvitystyön aloittamista. 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. 4.1 Arkkitehtuurimenetelmän hyödyntäminen kehittämiskohteiden tunnistamisessa Johdannossa kuvattua ValtIT:n kokoamaa arkkitehtuurimenetelmää 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. Arkkitehtuurien kehittämisen näkökulmasta kehittämisellä on kolme päävaihetta: 1. tavoitetilan hahmotus ja nykytila 2. tavoitetilan suunnittelu sekä 3. toimeenpanon suunnittelu. Kaikkia näitä vaiheita ei välttämättä toteuteta yhdessä projektissa tai kehittämishankkeessa. Esimerkiksi pelkästä nykytila-analyysista 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.1.1 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 tietoarkkitehtuuri, tietojärjestelmäarkkitehtuuri sekä teknologia-arkkitehtuuri. Nykytilan analyysissa huomioidaan silti samalla kaikki ko. näkökulmaan keskeisesti liittyvät toiset näkökulmat. Siten 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 tapauskohtaisesti ottaa myös valmiiksi määriteltyjä, lähitulevaisuudessa toteutettavia kokonaisuuksia, mikäli niissä oleelliset asiat on 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äkökulman edellyttämä kokonaisuuden hallinta edellyttää yleensä yksityiskohtaista tasoa abstraktimmalla tasolla olevia kuvauksia. 5/28

Nykytilan analyysin pohjatietona käytetään mm. nykytilan prosessien sekä palveluiden ja palvelurakenteen kuvaamista, organisaatio- ja sidosryhmäkarttaa, tarvekartoitusta, joiden tekeminen on kuvattu tässä suosituksessa (luku 5 Nykytilan kartoitus). 4.1.2 Tavoitetilan suunnittelu Tavoitetilan suunnittelussa määritellään tavoitetila niin toiminnalle ja järjestelmille, joita käytetään toiminnan tukena, kuin palveluille ja palveluratkaisuille. Tavoitetilan suunnittelun lähtökohta on ylhäältä alas. 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 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 ja kuvaaminen). 4.1.3 Toimeenpanon suunnittelu Toimeenpanon suunnitteluvaiheessa suunnitellaan (kokonaisarkkitehtuurin) tavoitetilan vaatimat kehitysprojektit, arvioidaan niiden hyödyt ja riskit sekä välitetään tulokset kehitysprojektin sidosryhmille. 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 (luku 7 Tavoiteratkaisun kuvaaminen). 5 Nykytilan kartoitus Nykytilan kartoituksen ja arvioinnin tavoitteena on saada käyttötarkoitukseen nähden riittävä näkemys nykytilasta. Kartoituksessa voidaan mm. muodostaa kuva nykyisestä toimintamallista ja palvelurakenteesta. käydä läpi nykyprosessi/prosessit. muodostaa kuvaa nykyprosessista sekä toimintamallia ja palvelurakennetta tukevista omista tietojärjestelmistä. kartoittaa sidosryhmät sekä toimintaympäristö. etsiä ja tarkentaa kehittämistarpeita analysoimalla myös nykyistä toimintaa ja tietojärjestelmiä. 5.1 Kuvaa nykyarkkitehtuurit Kokoa nykykuvaukset kaikista arkkitehtuurin osa-alueista kattavan kokonaiskuvan saamiseksi. Osa-alueita ovat toiminta-arkkitehtuuri, eli organisaation toimintamallit ja prosessit, toiminnan sidosryhmät, tarjottavat palvelut. tietoarkkitehtuuri. tietojärjestelmäarkkitehtuuri, kuten toiminnassa käytettävät järjestelmät ja ratkaisut). teknologia-arkkitehtuuri. 6/28

Mikäli selkeitä kuvauksia kohdealueen arkkitehtuureista ei ole, määrittele ne keskeisiltä osiltaan. Huomioi kuvauksessa ValtIT:n Arkkitehtuurimenetelmät dokumentissa annetut ohjeet kuvauksen ja mallintamisen suhteen (osa-alue taso). Kuvauksien tarkoituksena on kartoittaa mitä järjestelmiä ja arkkitehtuureja on käytössä ja miten ne tukevat ko. toimintaa. Analysoi nykytilan arkkitehtuurien tilanne arvioiden mahdolliset nykyjärjestelmien toiminnalliset riskit, mm. ikä, kunto, ylläpidettävyys. vastaavuus nykytoiminnan vaatimuksiin esim. suorituskyvyn ja palvelutason osalta. liittymien arviointi: Mahdolliset kehittämistarpeet liittymien toiminnallisuudessa. teknologian soveltuvuus. Analyysin tarkoituksena on selvittää nykyisten arkkitehtuurien ja järjestelmien / järjestelmäympäristön mahdolliset ongelmat ja kehittämistarpeet. 5.1.1 Kuvaa nykyprosessit Käytä hyödyksi kehittämisalueeseen liittyvien prosessien ja toimintoketjujen kuvauksia. Mikäli prosessikuvauksia ei ole tehty, kuvaa nykyprosessi(t) sille tasolle, jonka perusteella saadaan muodostettua riittävä kuva nykyprosessista ja sen tilasta / palvelevuudesta. Tässä vaiheessa tärkeintä on saada kuva toimintamalleista, selvittää syyt tämän hetkisiin toimintamalleihin ja tarkastella, miten niitä voitaisiin kehittää. Huomioi, että nykyprosessin kuvauksissa ei esiselvityksen yhteydessä pidä mennä liian tarkalle tasolle, koska riskinä saattaa olla, että se ohjaa ja lukitsee tulevaa ajattelua liian pitkälle, tai että siihen käytetään kohtuuttoman paljon aikaa. Yleensä kokonaisuuden hahmottamiseksi riittää prosessien ja toimintoketjujen kuvaus ydinprosessien sekä tukiprosessien osalta, itse työnkulkukaavioihin saakka ei kannata mennä. Selvitä kuvausten perusteella, mitkä järjestelmät osallistuvat prosesseihin. Tämän perusteella voidaan tunnistaa järjestelmävaikutukset esimerkiksi prosessimuutosta tehtäessä. Keskeistä on myös että tunnistetaan, mitkä järjestelmät osallistuvat erilaisten palveluiden ja prosessien toimintaan ja missä järjestelmissä tietoa luodaan, luetaan, päivitetään ja poistetaan. Tarkoituksena on mm. selvittää järjestelmien päällekkäisyydet ja ristiriidat informaation hallinnan kannalta. Työkaluina nykyprosessin kuvauksen ja/tai analysoinnin osalta toimivat prosessien kuvaamisen välineet ja menettelyt. prosessien suorituskyvyn arviointi ja analysointimenettelyt. prosessien ja toimintoketjujen kustannusten muodostumisen arviointi. prosessien roolitus ja resurssien käytön analysointi. Prosessien kuvaamisessa sovelletaan suositusta JHS 152 Prosessien kuvaukset. 5.1.2 Kuvaa nykytilan palvelut ja palvelurakenne Listaa nykytilan palvelut ja kerää olemassa ovat kuvaukset palveluista. Mikäli käytettävissä ei ole kuvauksia palveluista, koosta jokaisesta palvelusta vähintään seuraavat tiedot: palvelun käyttötarkoitus palvelun toiminnallisuudet palvelua käyttävät tahot (organisaatiot, järjestelmät). 7/28

Kuvaa palvelukuvausten perusteella nykytilan palvelurakenne rajattuna kehittämiskohteena olevalle alueelle. Palvelurakenteella tarkoitetaan niitä keskeisiä toimintoja, palveluita, tuotteita, tuottamismalleja ja organisaatioita, jotka kuuluvat tarkastelun alaisena olevaan kehittämisalueeseen. 5.1.3 Kuvaa organisaation roolit ja vastuut Selvitä ja listaa nykytoiminnan eri sidos- ja kohderyhmät sekä toiminnan eri osa-puolet vähintään kehittämiskohteena olevalta alueelta. Näitä ovat mm. prosessien sisäiset ja ulkoiset eri osapuolet tai järjestelmien eri käyttäjä- ja kohderyhmät. Laadi sidosryhmistä ja toimintaympäristöstä visuaalinen kuvaus, sidosryhmäkartta. Laaditut prosessikuvat toimivat pohjana sidosryhmäkartalle sekä sidosryhmien tunnistamisessa. Kuvaa organisaation toimijat ja roolit käyttäen hyväksi organisaatiokaavioita. Organisaation toimijoiden rooleista tulee kuvata osapuolen tai toimijan roolin nimi. roolin ja roolin tehtävien sanallinen kuvaus. roolin vastuut ja oikeudet. Apuna voit käyttää organisaation roolit, vastuut ja sidosryhmät kuvauspohjia (Liitteet 1-3). 5.2 Analysoi nykytilan toiminta Analysoi nykytilan toimintaa ja kerää kehitystarpeita käyttäen hyväksi tehtyjä prosessi-, sidosryhmä- ja palvelukuvauksia. 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. Tarpeen/ongelman analysoimiseksi on edellä mainittujen nykytilan kuvausten lisäksi hyvä käyttää tarvittaessa erilaisia ongelmanratkaisu- ja määrittelymenetelmiä. 5.3 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 todelliset 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 8/28

tunnus ja nimi. kuvaus. ketä tarve koskee. miten ja mihin vaikuttaa. tarpeen ratkaisemisen hyödyt. JUHTA - Julkisen hallinnon tietohallinnon neuvottelukunta 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 toteutettavan esiselvityksen alueeseen 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. 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.4 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.5 Nykytilan kartoitus ja analysointivaiheen lopputulokset Nykytilan kartoitusvaiheen 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. järjestelmä- ja arkkitehtuurikuvaukset. arkkitehtuurien mahdolliset kehittämistarpeet. selvitykset taloudellisista tunnusluvuista 9/28

analyysien tuloksena syntyneet ja/tai tiedossa olevat priorisoidut nykyjärjestelmän ja nykytoiminnan kehittämistarpeet. 6 Tavoitetilan suunnittelu ja kuvaaminen 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. 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 osa-alueita. kehittämisvaihtoehtojen vertailussa joku ratkaisumalli näyttää osoittautuvan selkeästi paremmaksi, jos sen osalta voidaan tehdä tarkennuksia palveluratkaisuihin, prosesseihin, tietojärjestelmiin tms. Kuva 3 Tavoitetilan määrittely iteratiivisena toteutustapana 6.1 Tavoitetilan hahmotus, rajaaminen ja nykytila Syötteinä tavoitetilan hahmottamisessa, sen rajaamisessa ja nykytilaan vertaamisessa ovat mm. kehittämispyyntö. kehittämispyyntöön liittyvät 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. 10/28

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 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ämispyynnön mukaiset kehittämisalueet ja tee tarvittavat rajaukset. Arvioi, aiheuttaako pyydetty kehityskohde kehitystarpeita myös siihen liittyvissä kohteissa. Huomioi tässä vaiheessa myös siirtymäaikaan liittyvät tekijät, kuten toimintamallit, kustannukset ja mahdolliset haitat. 6.1.2 Tunnista ja kokoa ohjaava tieto Tunnista, mitä ohjeistuksia, vaatimuksia ja kuvauksia on huomioitava ohjaavana tietona. Tässä vaiheessa huomioidaan niin kokonaisarkkitehtuuri kuin organisaation arkkitehtuuri kaikkine osa-alueineen. Huomioi olemassa olevat nykytila- ja tavoitetilakuvaukset. Varmista, että ko. dokumentaatio on käytettävissä suunnitteluvaiheessa. 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. 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 Suunnittele projekti menetelmän mukaisesti tai tarkenna olemassa olevaa projektisuunnitelmaa. Analysoi kehittämisprojektin 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. Dokumentointiin ja tavoitetilan määrittelyn lopputulosten kirjaamiseen on tällöin kiinnitettävä erityistä huomiota. 6.1.5 Vaiheen lopputulokset Tavoitetilan hahmotus ja rajausvaiheen lopputulokset ovat: 11/28

lista suunnittelussa tarvittavista olemassa olevista kuvauksista. hyväksytty kehittämissuunnitelma. ylätason toimintalähtöisen vision skenaariokuvaus. päivitetyt vaatimukset. 6.2 Tavoitetilan suunnittelu Tavoitetilan suunnittelu on vaihe, jossa varsinaiset suunnittelun tulokset tuotetaan. Tässä vaiheessa määritellään tavoitetila huomioiden arkkitehtuurit (toiminta-, tieto-, järjestelmä- ja teknologia-arkkitehtuurit) sekä kehittämisen kohteena olevan alueen sidos- ja kohderyhmät. Tässä vaiheessa kuvataan myös tavoitetilan prosessit, palvelut ja palvelurakenteet sekä varmistetaan, että suunnittelussa on huomioitu kaikki tarvittavat osa-alueet puuteanalyysin avulla. Tavoitetilan suunnittelu etenee seuraavien (luvut 6.2.1 6.2.7) päätehtävien mukaisesti kaikissa näkökulmissa. Tuloksen tuottamisessa voidaan käyttää suosituksen liitteenä olevia kuvauspohjia sekä Arkkitehtuurimenetelmä dokumentin liitteitä. 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 Valitse kuvaustavat Huomioi vaiheessa 6.2.1 Analysoi kehittämisalueen ja kuvausten kohderyhmät tehdyt määritykset ja valitse kuvaustapa. Kuvaustapoihin löytyy esimerkkejä mm. Arkkitehtuurimenetelmät dokumentista. 6.2.3 Kuvaa arkkitehtuuri huomioiden eri näkökulmat Analysoi Tavoitetilan suunnittelu vaiheessa tähän asti koottu materiaali kohde- ja sidosryhmistä ja kirjaa projektin arkkitehtuurin kehittämiseen vaikuttavat asiat. Arkkitehtuurin suunnittelun kannalta tässä vaiheessa voidaan suunnitella mitä tahansa osa-aluetta. Jos suunnittelun kohteena on useampia näkökulmia, on suunnittelujärjestys seuraava: 1. Toiminta-arkkitehtuurinäkökulma 2. Tietoarkkitehtuurinäkökulma 3. Järjestelmäarkkitehtuurinäkökulma 4. Teknologia-arkkitehtuurinäkökulma Teknologia-arkkitehtuurinäkökulma on kuitenkin huomioitava mahdollistavana lähtökohtana ensimmäisestä näkökulmasta lähtien. Hyödynnä projektiin liittyviä vaatimuksia. Hyödynnä tarjolla olevat kuvauspohjat ja ohjeet (ValtIT Arkkitehtuurimenetelmä dokumentin ja tämän suosituksen liitteet). Huomioi myös vaiheessa 6.2.1 tunnistetut suunnitteluun vaikuttavat tekijät. 6.2.3.1 Tee puuteanalyysi Arvioi, onko jotain asioita tai näkökulmia jäänyt huomioimatta suunnittelussa. Kuvaa matriisi, jossa riveinä ovat nykytilan arkkitehtuurin rakenneosat ja sarakkeina tavoitetilan arkkitehtuurin rakenneosat. 12/28

Kirjaa Säilytetään niihin soluihin, joissa tavoitetilan arkkitehtuuriin rakenneosa on sama kuin nykytilan arkkitehtuurin rakenneosa. Kirjaa Uusi niihin soluihin, joissa tavoitetilan arkkitehtuurin rakenneosaa vastaavaa rakenneosaa ei löydy nykytilan arkkitehtuurista. Kirjaa Poistetaan niihin soluihin, joissa nykytilan arkkitehtuurin rakenneosaa vastaavaa rakenneosaa ei löydy tavoitetilan arkkitehtuurista. Puuteanalyysissä huomioitavia kohtia ovat Uusi ja Poistetaan -kohdat. Uusi - tapauksessa on suunniteltava uuden rakenneosan toteuttaminen. Mikäli valitaan Poistetaan, on varmistettava, että poistaminen on tarkoituksellinen ja että vaikutukset muihin rakenne-osiin on huomioitu. 6.2.4 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. Huomioi myös tässä vaiheessa myös Hallintolain 7, jonka 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ä. Kuva 4 Palvelukartta (lähde: ValtIT, Arkkitehtuurimenetelmä) Lopputuloksena syntyvät vähintään seuraavat kuvaukset: tulevat palveluratkaisut ja keskeiset muutokset nykyisiin palveluratkaisuihin. 13/28

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.5 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ä. Prosessien kuvaustapa on esitelty ja ohjeistettu Julkisen hallinnon suosituksessa JHS 152 Prosessien kuvaukset (http://www.jhs-suositukset.fi/suomi/jhs152 ). Prosessien kuvaus tasolla 2 riittää yleensä, tärkeintä on, että erojen havaitseminen nyky- ja tavoiteprosessista (vrt.6.4.2) on mahdollista. 6.2.5.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 GAP-analyysien avulla. GAP analyysien kautta erot konkretisoidaan ja määritellään tarkemmin kehittämistoimenpiteiksi. Nämä kehittämistoimenpiteet konkretisoidaan prosessien kehittämisprojektiksi/-projekteiksi ratkaisujen valintavaiheessa. Kuva 5 GAP-analyysin avulla voidaan määritellä portaat, joilla organisaatio pääsee 14/28

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 toteutetaan valmisohjelmistoratkaisuna tai ASP-ratkaisuna, prosessin tarkennuksiin on oltava valmiudet. Tämä johtuu mm. siitä syystä, että on huomattavasti järkevämpää ja kustannustehokkaampaa räätälöidä omaa prosessia valmisohjelmistoon sopivaksi kuin räätälöidä valmisohjelmistoa prosessin mukaiseksi. 6.2.6 Kehitä toiminnan visiota tarvittaessa Arvioi, vaikuttaako kehittämisen tulos toiminnan tavoitetilaan ja korjaa visiota tarvittaessa. Päivitä vaatimukset ja ilmoita muutoksista vastuullisille tahoille. 6.2.7 Vaiheen lopputulokset Tavoitetilan suunnitteluvaiheen lopputulokset ovat: tavoiteprosessin kuvaukset. realistinen arvio prosessimuutosten toteutusmahdollisuuksista. arkkitehtuurikuvaukset kehittämiskohteena olevasta alueesta huomioiden muut näkökulmat ja kokonaisarkkitehtuuri. puuteanalyysi. toiminnan vision 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 pyrikiä 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 15/28

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. 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 jo suoritettu lainsäädäntövaiheessa eduskunnassa. Kiteytä ja konkretisoi hankkeen ja projektien hyötynäkökulmat esimerkiksi alla olevan kuvan (kuva 6) 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. Talous Kustannussäästöt Tuottavuuden kasvu Asiakkaat ja sidosryhmät Parempi asiakas- ja sidosryhmätyytyväisyys Vaikuttavuus Uudet asiakkaat ja sidosryhmät Prosessit ja toiminnallisuus Tehokkaat prosessit Palveleva teknologia ja järjestelmät Kyky innovoida ja tuottaa lisäarvoa Laatuodotuksiin vastaaminen Osaaminen, henkilöstö Osaamisen kehittyminen Oikeat henkilöt oikein kohdennettuna Työtyytyväisyyden lisääntyminen ja motivaation paraneminen Kuva 6 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. 16/28

Kuvan 6 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 3 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. 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äytäntöön viemistä? 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). Kehityshankkeen ehdotus kustannusarvio Esitutkimus alustava investointilaskelma tavoitehyötyjen asettaminen Vaatimusten määrittely nopeiden tavoitehyötyjen toteutuminen esim. 4 vuoden kuluttua tavoitehyötyjen toteaminen Kilpailutus 1. tarkennettu investointilaskelma hankeraportointi 2. tarkennettu investointilaskelma investointilaskelman toteutuminen Määrittely Toimittajan suunn., toteut. ja testaus Hyväksymistestaus Käyttöönotto Ylläpito Tietojärjestelmän alasajo Kuva 7 Investoinnin seurantamenettelyt 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 17/28

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 kuvaaminen. 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. 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ä hankintailmoituksen laatimista, mutta hankintailmoituksella on myös mahdollista ilmoittaa tietopyynnöstä. 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. Hyvä tapa kartoittaa mahdollisia ratkaisuja, on myös selvittää mitä järjestelmiä muissa vastaavissa organisaatioissa (virastot, kunnat) 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. 18/28

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. 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. 19/28

Kuva 8 Riskien arvioinnin ja hallinnan vaiheet (Murtonen 2003) 1. Riskianalyysin avulla löydetyt ja kuvatut riskit auttavat määrittämään, kuinka riskialttiiseen hankkeeseen kokonaisuudessaan ollaan lähdössä. tunnistamaan riskejä eri osa-alueilta ja suunnittelemaan jo aikaisessa vaiheessa niiden vähentämis- / eliminointitoimenpiteitä, esim. pyrkien vastaamaan seuraaviin kysymyksiin: - mitä kaikkea voi sattua? - miksi? - mitä siitä voi seurata? - miten suuri on aiheutuva riski? - mitkä riskit ovat suurimmat? luomaan pohjaa hankkeen suunnittelulle ja tunnistettujen riskien huomioimiselle suunnitelmissa. Tee riskianalyysi käyttäen yhtä tai useampaa menetelmää, kuten esimerkiksi riskipalavereita, joissa eri osa-alueiden avainhenkilöt miettivät ja tunnistavat kehittämisalueen riskejä, arvioivat niiden esiintymistodennäköisyyksiä ja vaikutuksia sekä suunnittelevat eliminointi- / vähentämistoimenpiteitä. haastatteluja tai kyselylomakkeita, jolloin aihealueeseen liittyviä riskejä kootaan esim. sidosryhmiltä. Riskit kootaan yhteen esiselvityksen avainhenkilöiden kokouksissa sekä arvioidaan ja suunnitellaan toimenpiteet. Huomioi riskipalavereissa aiemmin kehittämiskohteiden tunnistamisessa tehdyn SWOT analyysin tunnistetut uhat ja heikkoudet. Lisäksi riskejä voidaan tunnistaa ja analysoida neljästä eri näkökulmasta tulevan hankkeen kannalta: toiminnalliset riskit, tietotekniset riskit, hankkeen sisäiset riskit ja ulkoiset riskit. Riskien arvioinnissa voi käyttää apuna myös VAHTI -ohjetta Riskien arviointi tietoturvallisuuden edistämiseksi valtionhallinnossa. (http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvallisuus/53828 /name.jsp) 1 Murtonen Mervi, Riskin arviointi, STM:n työsuojeluoppaita ja -ohjeita 14 20/28

6.6.2 Tee tuottavuusvaikutusanalyysi Laadi alustava tuottavuusvaikutusanalyysi kehittämiskohteena olevasta alueesta. Huomioi investointilaskelmassa kaikki vaikuttavat tekijät, niin kustannus- kuin tuottoarviopuolellakin. Tässä vaiheessa tehtävä investointilaskelma on alustava ja suuntaa antava ja se tulee tarkentumaan viimeistään hankkeen ja/tai projektien kilpailutuksen jälkeen, jolloin tiedetään tarkoin ulkopuoliset kustannukset. Arvioi tuottavuusvaikutuksia myös arvioimalla määriteltyjen ratkaisujen ja ratkaisuvaihtoehtojen taloudellisia hyötyjä ja vertaamalla niitä määriteltyjen ratkaisujen ja ratkaisuvaihtoehtojen kustannuksiin ja kustannustekijöihin. Käytä hyödyksi kustannusten ja hyötyjen analysoinnissa liitteen 6 e-pohjois-suomen tekemää kustannushyötyanalyysin pohjaa (excel-taulukko). Erityisesti palveluratkaisuissa tuottavuuden vaikutusten arviointi on äärimmäisen tarpeellista, vaikka yksiselitteisen investointilaskelman laatiminen voi olla joskus hankalaa. Kuitenkin tuottavuusvaatimukset ovat yhä voimakkaammin toimintaa ohjaava tekijä, ja niiden tulee siksi olla myös esiselvityksen valintakriteereissä merkittävänä vaikuttajana. Pakollisissa, esim. lainsäädäntömuutoksen alulle panemissa hankkeissa varsinaista investointilaskentaa ei aina ole järkevää tehdä, ja sen sijaan laaditaankin useimmiten pelkästään kustannusarvio. 6.6.3 Vaiheen lopputulokset Tavoitetilan analyysit -vaiheen lopputuloksena kehittämisalueen riskien kartoitus on suoritettu sekä huomioitu tunnistettujen riskien eliminointi- / vähentämistoimenpiteet suunnittelussa ja tarvittaessa myös budjetoinnissa alustavat kehittämiskohteen investointilaskelmat ja tuottavuusarviot eri vaihtoehdoista ja / tai kustannuslaskelmat eri vaihtoehdoista on tehty. riskianalyysi on tehty. 6.7 Kehittämisvaihtoehtojen vertailu ja valinta Vaihtoehtojen vertailulle ja valinnalle pohja rakentuu edellisessä vaiheessa tarkentuneista ja kuvatuista tavoitetilasta kokonaisuutena sekä eri osa-alueilla. kehittämismahdollisuuksista ja rajoituksista. tavoitetilan kartoituksen analyyseistä. eri vaihtoehtojen alustavista kustannustekijöistä. Vaihtoehtojen vertailussa ja valinnassa on olennaista se, että kaikki tekijät tulevat ratkaisuissa tasapuolisesti tai ainakin oikealla painoarvolla huomioiduksi. Ratkaisuissa suuri painoarvo on tietenkin kustannustekijöillä. Huomioitavaa on silti, että kustannuksiltaan suurempi investointi voi olla kokonaisuuden kannalta edullisempi vaihtoehto. Vertailussa on siis pyrittävä kokonaistaloudellisesti edullisimpaan ratkaisuun, jolloin myös muutkin näkökulmat on huomioitava (esim. laatu, teknisen ratkaisun sopivuus). 6.7.1 Vertaile tavoitehyötyjä Vaihtoehtojen vertailuun ja valintaan perusta saadaan aikaisemmin kuvatuista tavoitehyödyistä: Taloudelliset hyödyt 21/28

Vertaile miten ja millä ratkaisuilla parhaiten toteutuvat taloudelliset tavoitteet mm. kustannustehokkuuden, tuottavuusvaikutusten ja mahdollisten säästöjen näkökulmasta. Määrittele ja tarkenna mittarit.. Hyödyt asiakkaille ja sidosryhmille Vertaile miten ja millä ratkaisuilla syntyvät parhaiten hyödyt asiakas- / sidosryhmävaikuttavuuden ja asiakas- / sidosryhmätyytyväisyyden kannalta. Määrittele ja tarkenna mittarit. Toiminnan tehostuminen Vertaile miten ja millä ratkaisuilla saavutetaan ne hyödyt, joita tavoitellaan esim. paranevana prosessien ja toiminnan tehokkuutena, toimintavarmuutena, parempina läpimenoaikoina, oikeellisempina tuloksina sekä parempana ja tehokkaampana tietotekniikan hyödyntämisenä. Määrittele ja tarkenna mittarit. Osaaminen ja henkilöstö Vertaa miten ja millä ratkaisuilla toteutetaan parhaiten hyödyt osaamisen kehittämisen / kehittymisen kannalta, parempana työtyytyväisyytenä, osaamisen ja osaamisvaatimusten kohdistamisen kannalta sekä organisoinnin kannalta. Määrittele ja tarkenna mittarit 6.7.2 Vertaile toiminnallisia vaihtoehtoja Vertaile toiminnallisia vaihtoehtoja, joita voivat olla esimerkiksi yhdistetään lähellä toisiaan olevia toimintoja, esimerkiksi tietojen tallennus suoritetaan samassa paikassa tai se ulkoistetaan. alueellinen tai toiminnallinen keskittäminen tai hajauttaminen. keskitytään ydinprosessien kehittämiseen ja karsitaan muita toimintoja. tarpeettomien toimintojen karsiminen. Toiminnallisiin vaihtoehtoihin kuuluvat myös palvelurakenteeseen ja palveluratkaisuihin liittyvät asiat, kuten esimerkiksi uusien asiakaspalvelukanavien käyttöönotto tai palveluissa suoritettavien toiminnallisuuksien laajentaminen koskemaan uusia alueita. Toiminnallisissakin vaihtoehdoissa valintakriteerit muodostuvat edellä mainittujen hyötynäkökulmien ja niiden painoarvojen perusteella. 6.7.3 Vertaile tietoteknisiä vaihtoehtoja Vertaile tietoteknisiä vaihtoehtoja, joita voivat olla esimerkiksi hankitaan kokonaan valmisohjelmistoratkaisu. osia tarpeesta toteutetaan valmisohjelmistoratkaisuilla, osia toteutetaan muulla tavoin (joko nykyisillä järjestelmillä, niiden muutoksilla tai rakentamalla uusia ratkaisuja). hankitaan valmisohjelmistoon perustuva ratkaisu / osaratkaisuja joita räätälöidään tarvetta vastaavaksi. nykyiset tietojärjestelmät kykenevät täyttämään tarpeet myös jatkossa. nykyiset tietojärjestelmät muutoksin kykenevät täyttämään tarpeet myös jatkossa. rakennetaan kokonaan uusi tietojärjestelmäratkaisu. hankitaan ratkaisu ASP palveluna (ASP = Application Service Provider. Tarkoittaa sitä, että hankitaan käyttöoikeus sovellukseen, joka toimii palvelun tarjoajan koneella). Huomioitava on, että ASP ratkaisu ei poista tietoturva-asioiden huomioimista. Pikemminkin tietoturvan analyysi on oltava syvällisempi, koska tuotteen kehittäminen ei ole omassa hallussa ja ASP:n yhteiskäyttöisyys asettaa joskus rajauksia turvallisuudessa, tai ASP ratkaisuissa ei huomioida eri toimijoiden vaatimuksia yhteismitallisesti. 22/28