FEAR-projekti Finnish Enterprise Architecture Research Project Valtionhallinnon kokonaisarkkitehtuurin tutkimusprojekti Kehittämishankkeiden FEAR-ohjausmalli Hankealoitteesta tavoiteasetannan kautta kilpailutukseen ja muutostenhallintaan Versio 2.0 Final 15.3.2010 Jukka Heikkilä Tapani Kella Katja Liimatainen Ville Seppänen
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 2 (32) TIIVISTELMÄ Raportissa esitämme FEAR-tutkimusprojektissa laaditun kehittämishankkeiden ohjausmallin, joka pyrkii tavoitteelliseen valtionhallinnon toiminnan kehittämiseen ja samalla menettelytapojen ja toimijoiden kyvykkyyksien uudistamiseen. Ohjausmallin perimmäisenä tavoitteena on luoda edellytykset uusille tavoille kehittää hallintoa ja helpottaa kansalaisten ja yritysten asiointia. Ohjausmallin käytöllä varmistetaan järjestelmien ja toimintatapojen yhteentoimivuus ja luodaan laadunvarmistusmekanismit kehittämisohjelmille ja niiden muutostenhallinnalle. Ohjausmalli on suunniteltu julkishallinnon kokonaisarkkitehtuurin kehittämiseen vähitellen hankkeiden myötä ja yhteensopivaksi ISO/IEC 38500 IT johtamisstandardin kanssa. ASIASANAT Valtionhallinto, julkishallinto, kokonaisarkkitehtuuri, ohjausmalli, kehittämishanke ABSTRACT This report introduces FEAR governance model, which aims at developing public services by setting targets and simultaneously improving processes and capabilities. The objective of the governance model is to make administration more efficient and easy to approach. In addition, the governance model ensures interoperability between processes and information systems, and helps in implementing relevant quality assurance mechanisms for development programs, and their change management. FEAR governance model is designed for incremental development of the government enterprise architecture and be compliant with ISO/IEC 38500 Corporate Governance of Information Technology standard. KEYWORDS Public administration, enterprise architecture, governance, development program
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 3 (32) KIITOKSET Kiitämme FEAR-projektin innovatiivista johtoryhmää, rahoittajia ja ohjausmallin kehittämiseen osallistuneita organisaatioita, joita ovat olleet Valtiovarainministeriö, Puolustusministeriö, Oy International Business Machines Ab, Tieto Oyj, Ixonos Teknologiakonsultointi Oy, Microsoft Oy ja SAS Institute Oy. Kiitokset myös projektissa opinnäytteitään Jyväskylän yliopistossa tehneille Anssi Heikkiselle, Henri Lehtoselle, Mikko Maliselle, Antti Pyykölle ja Hannu Vänttiselle vihkiytymisestään julkishallinnon arkkitehtuurityöhön. Lisäksi seuraavien henkilöiden jakamat näkemykset ja kokemukset ovat vaikuttaneet työhön: Esa Auramäki, Tomi Dahlberg, John Gøtze, Mika Helenius, Kristian Hjort-Madsen, Ari Hirvonen, Antti Holmroos, Ari Häkkinen, Heikki Ihanainen, Hannakaisa Isomäki, Pauli Kartano, Kimmo Kaskikallio, Jari Kekkonen, Timo Kestilä, Juha Koivula, Harri Kreus, Veijo Kuosmanen, Jarmo Kärkkäinen, Antti Larsio, Esko Liimatta, Jouni Lähteenmäki, Kari Miskala, Pasi Mäkinen, Aleksi Niemelä, Tommi Oikarinen, Samuli Pekkola, Jouko Poutanen, Tero Päivärinta, Mika Rajanen, Risto Rasimus, Jaakko Riihinen, Hannu Ritvanen, Christian Rupp, Hannu Salmela, Juha Siltanen, Aki Siponen, Richard Soley, Jari Syvänen, Pirjo Syväoja, Jukka Uusitalo, Teija Uusitalo, Raija Varkkola, Tomi Voutilainen, Hannes Werthner ja TTL ry:n KAOS osaamisyhteisön jäsenet.
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 4 (32) SISÄLLYSLUETTELO 1. JOHDANTO... 5 2. KEHITTÄMISHANKKEIDEN OHJAUSMALLI... 7 2.1. Roolit... 10 2.2. Hankealoite... 10 2.3. Hankkeen vaikuttavuuden arviointi... 11 2.4. Toteuttamismahdollisuudet... 12 2.5. Kokonaisarkkitehtuurin mukaisuuden arviointi ja hankkeen julkistus... 13 2.6. Liiketoimintamallinnus... 14 2.7. Toimintamallien valinta... 15 2.8. Kilpailutuksen valmistelu... 16 2.9. Hankinta... 16 3. HANKEHALLINTA... 17 3.1. Muutostenhallinnan johtaminen... 20 3.2. Muutoksen hyväksyminen ja toteuttaminen... 21 3.3. Portfolion hallinta... 22 4. OHJAUSMALLIN LÄPÄISEVÄT TOIMINNOT... 24 4.1. Laadunvarmistus ja riskianalyysi... 24 4.2. Hyötyjen varmistus... 24 5. FEAR-OHJAUSMALLI HANKEALOITTEESTA HANKEHALLINTAAN... 25 LÄHDELUETTELO... 26 LIITE: OHJAUSMALLIN VAIHEIDEN LÄHTÖ- JA TULOSTIEDOT SEKÄ ARVIOINTIVÄLINEET... 29 KUVAT Kuva 1. Kokonaisarkkitehtuurin ja kehittämishankkeiden suhde... 7 Kuva 2. Kehittämishankkeiden ohjausmalli (suunnitteluvaihe)... 8 Kuva 3. Tulosprisma... 12 Kuva 4. Hankkeen vaikuttavuusarvio: lähtötiedot ja tulostiedot... 12 Kuva 5. Toteuttamismahdollisuudet: lähtötiedot ja tulostiedot... 13 Kuva 6. Kokonaisarkkitehtuurin mukaisuuden arviointi ja hankkeen julkistus: lähtötiedot ja tulostiedot... 14 Kuva 7. Liiketoimintamallinnus: lähtötiedot ja tulostiedot... 15 Kuva 8. Toimintamallien valinta: lähtötiedot ja tulostiedot... 16 Kuva 9. Kilpailutuksen valmistelu: lähtötiedot ja tulostiedot... 16 Kuva 10. Muutos- ja hankehallinta eri rooleissa... 18 Kuva 11. Muutosten heijastusvaikutukset (perustuen Leavitt 1964; 2004)... 19 Kuva 12. Ohjausmallin roolit RACI-matriisissa esim. muutospyynnön käsittely (mukaellen BABOK, 2009)... 19 Kuva 13. Hyvän tietohallintotavan mukainen johtaminen... 20 Kuva 14. Ohjausmallin suhde dynaamiseen arkkitehtuuriin, jossa on sekä arkkitehtuurinmukaisesti että ilman toteutettuja hankkeita.... 23 Kuva 15. Sidosryhmät, josta RACI vähintään johdetaan (mukaellen, IIBA, 2009)... 24
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 5 (32) 1. JOHDANTO Valtion IT-toimintojen kehittämiseksi perustetun yhteentoimivuuden kehittämisohjelman tavoitteina ovat järjestelmien yhteentoimivuus, johdonmukainen tietohallinto, aiempaa asiakaslähtöisempi näkemys hallinnon palveluiden tuottamiseen, kustannustehokkuuden parantaminen sekä osaamisen ja tietotekniikan kehittäminen palvelemaan ydintoimintaa. Keskeinen väline hallinnon palveluiden systemaattiseen kehittämiseen yhteentoimivuuden kehittämisohjelman mukaisesti on kokonaisarkkitehtuuri (KA), jolla hallinnollinen työ ja tietojärjestelmät voidaan sovittaa yhteen hallitusti 1. Kokonaisarkkitehtuuri on strategisen johtamisen väline, jonka avulla yhtenäistetään toiminnan kehittämistä sekä tieto- ja viestintäteknologian hyödyntämistä julkishallinnossa. Valtionhallinnossa ValtIT:n työn yhteydessä kehitetty arkkitehtuurimenetelmä on käyttöönottonsa alkuvaiheissa 2. Se pitää sisällään julkishallinnon KA-menetelmäluonnoksen 3, sen mukaisesti tuotetut arkkitehtuurilinjaukset ja -kuvaukset sekä hallintamallin 4. Näiden avulla organisaatioiden toiminta, niiden tiedot, tietojärjestelmät ja tekniset alustat voidaan suunnitella toimintakokonaisuuden kannalta. ValtIT KA -menetelmän hallintamalli on yleiskuvaus kehittämistyön nivomisesta toiminnan ja talouden ohjausprosesseihin valtionhallinnossa ja kokonaisarkkitehtuurin itsensä hallinta- ja ylläpitoprosesseista. Täten ValtIT:n mallissa näkyy ajatus arkkitehtuurin kaksijakoisuudesta: toisaalta se kuvaa järjestelmäkokonaisuuden riippuvuuksineen ja toisaalta sen tehtävänä on ohjata hallinnon ja sitä tukevien järjestelmien kehittämistä hallintamallin avulla. Onnistunut KA:n kehittämistyö vaatiikin yleensä taustalle vahvan hallintamallin 5. Esimerkiksi Yhdysvalloissa virastot on velvoitettu Clinger-Cohen Act -lailla varmistamaan yhteentoimivuus ja se, ettei päällekkäisiä hankkeita ja investointeja tehdä. Näin vahvaa hallintamallia ei ole pidetty Suomessa tarpeellisena, sillä virkamieskunnan on oletettu muutenkin pystyvän kehittämishankkeissa yhteistyöhön. FEAR-projektissa on kuitenkin huomattu, että KA-työ ei valtionhallinnossa etene halutulla vauhdilla muutoshankkeita on käynnissä lukuisia, mutta resursseja kehittämistoimintaan ja varsinkaan johdon tukea kehittämistyölle ei tahdo löytyä 6. Usein tämä näkyy niin, että kehittämishankkeiden tavoitteet ovat epärealistiset suhteessa resursseihin, eri toimijoiden väliltä puuttuu koordinointi ja tavoiteasetanta on puutteellista 7. Valtionhallinnon ja muunkin julkishallinnon sektoroituminen, tai siiloutuminen, on johtanut siihen, että kokonaisuuden hallinta ontuu. Valtiontalouden tarkastusvirasto (VTV) on puuttunut kehittämishankkeiden ongelmiin ja on usein saanut tukea riippumattomista lähteistä. Esimerkiksi Sitran arviointien mukaan merkittävä osa terveydenhoidon hankkeista on jäänyt kauas tavoitteistaan. Korpelan ja Mäkitalon mukaan valtakunnallisten kehityshankkeiden ohjaus tarvitsee yleisesti ottaen uutta otetta 8 ja mielestämme kysymys on nimenomaan selkeämmän, strategisemman hallintamallin tarpeesta, jota jatkossa kutsumme ohjausmalliksi. Ohjausmallin tarve saa tukea myös VTV:n raporteista. Arvioidessaan alueellisten tietoyhteiskuntahankkeiden toteutusta VTV raportoi mm. seuraavaa: Hankkeiden tavoitteet olivat epärealistisia suhteessa asetettuun aikatauluun, henkilöstöresursseihin, toteutettuun hankeohjausmalliin ja käytössä ol- 1 Pulkkinen ym. 2007 2 ks. esim. Seppänen 2009 3 Valtiovarainministeriö 2007a, Arkkitehtuurimenetelmä 4 Valtiovarainministeriö 2007b, Arkkitehtuurin hallintamalli 5 Liimatainen ym. 2007 6 Seppänen ym. 2009 7 Malinen & Pyykkö 2010 8 Korpela & Mäkitalo 2008, s. 206
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 6 (32) leeseen rahoitukseen nähden. Lisäksi ohjauksesta vastanneet toimijat eivät olleet sitoutuneet riittävästi hankkeen tavoitteisiin. VTV pitää tärkeänä, että tulevia poikkihallinnollisia ohjelmia käynnistettäessä ja toteutettaessa seurantajärjestelmät ovat kattavia ja seuranta jatkuvaa. VTV myös velvoittaa valtiovarainministeriön asettamaan uusille hankkeille selkeät tavoitteet ja kehittämään hankehallinnoinnin menettelytapoja. 9 Hallintamallin tulee ohjata kehittämishankkeita tavoitteellisesti yhteentoimivuusohjelman mukaisesti ja samalla parantaa arkkitehtuurityön ongelmakohtia, kuten laadunvarmistuksen puutetta, tavoiteasetannan epäselvyyttä ja sen viestimisen puutteita kyvykkyyksien ja infrastruktuurin kehittämisen riittämättömyyttä sekä vähäistä innovointia uusien vaihtoehtoisten menettelytapojen kehittämiseksi. Valtion tuottavuusohjelmien arvioinnissa ulkopuoliset konsultit kiinnittivät huomiota jokseenkin samoihin asioihin 10, jotka myös hallinnon sisäpiiriläiset Korpela ja Mäkitalo erittelevät paremmalla ohjauksella ratkaistaviksi ongelmiksi. Tässä tilanteessa yhteentoimivuusohjelmaa seuraavassa FEAR-tutkimushankkeessa päädyttiin kehittämään konkreettista ohjaamismenettelyä kokonaisarkkitehtuurityön yhteyteen, sillä tietojärjestelmät ja toimintaprosessit ovat nykyisen ja etenkin tulevan hallinnon keskeisimpiä palvelurakenteita. Parhaana pidämme lähestymistapaa, jossa julkishallinnon suosittelemalla menettelyllä (JHS) 11 kokonaisarkkitehtuuria kehitetään asteittain käytännön kehityshankkeiden pohjalta valtion kokonaisarkkitehtuurin kanssa yhteensopivasti. Menettelyllä selkeytetään osapuolten välistä kommunikaatiota ja tavoiteasetantaa, sillä havaintojemme mukaan kehityshankkeiden suunnitteluvaiheessa kaivataan ohjausta kokonaisarkkitehtuurista. Nykyistä vahvemman ohjausmallin tarve on noussut esille myös SADe-hankkeen raportissa 12. Näistä lähtökohdista hahmottelemme julkishallinnon kehittämiseen soveltuvan FEAR-ohjausmallin, joka auttaa hankkeiden hallintaa tavoiteasetannalla, suunnitelmallisella resurssien kehittämisellä, toiminnallisella laadunvarmistuksella ja vaihtoehtojen innovoinnilla. Ohjausmalli soveltuu sekä yksittäisten kehittämishankkeiden että kokonaisuuden hallintaan. Ohjausmallia suunniteltaessa on pyritty luomaan edellytykset sille, että toiminnoista vastaavat pystyvät itse parantamaan palvelujensa laatua ja kustannustehokkuutta jatkuvasti ja suunnitelmallisesti. Tulosohjauksen ja tuottavuusohjelman paineessa julkinen sektori on parantanut tulostaan 13 ja joutuu tekemään sen jatkossa aikaisempaa pienemmin panoksin 14. Sen on kyettävä yksityisen sektorin tavoin kasvattamaan tuottavuuttaan nykyistä menettelytapoja, työskentelyolosuhteita ja työilmapiiriä parantamalla, mikä lisää tietojärjestelmien ja pitkäjänteisen ohjauksen tarvetta. 15 Käytännössä tämä tarkoittaa, että todellista vaikuttavuutta on arvioitava entistä tarkemmin ja erityisesti taloudellisin perustein 16. Vaikuttavuudella tarkoitamme tässä keskipitkän ja pitkän aikajänteen kuluessa syntyviä, perimmäisiä tavoiteltuja muutoksia ja parannuksia, joiden kohteena on kehittäjäorganisaation lisäksi yhteiskunta jäsenineen laaja-alaisesti. Pakollisenakin pi- 9 VTV 2008 10 Sintonen 2008 ja PricewaterhouseCoopers 2008 11 JHS, Julkishallinnon suositus 12 SADe 2009 13 Tilastokeskus 2009 14 http://www.vm.fi/vm/fi/05_hankkeet/02_tuottavuusohjelma/index.jsp 15 Korpela & Mäkitalo 2008, s. 93-94 16 Hyytinen, Lähteenmäki-Smith, Kallio & Saari (toim.) 2008
JYVÄSKYLÄN YLIOPISTO FEAR-projekti OHJAUSMALLI 7 (32) 15.3.2010 Versio 2.0 Final detyt hankkeet on pystyttävä perustelemaan vertailemalla sidosryhmille koituvia hyötyjä ja hait- toja toteutus- ja muutoskustannuksia vasten. Tällöin on eriytettävä nykyistä enemmän tavoi- teasetanta, toteutus ja tulosten saavuttamisen arviointi toisistaan. Vaikuttavuusarviointi voi olla etukäteistä, toiminnan aikaista tai jälkikäteistä ja se pitää tehdä aina suhteessa asetettuun tavoit- teeseen. 17 Ohjausmallin soveltaminen on onnistunut, jos alusta pitäen tiedetään mitä toiminnallisia paran- nuksia tavoitellaan ja voidaan valita tilanteeseen sopivin toteutustapa vaihtoehtojen joukosta te- hokkuuden ja innovatiivisuuden jatkumolla 18. Tärkeää on myös määrittää kertyvätt hyödyt ja kustannukset eri sidosryhmien näkökulmasta sekä hallita muutosta suhteessa kokonaisuuteenn päällekkäisyyksien ja epäyhteensopivienn menettelyjen välttämiseksi. Kuva 1. Kokonaisarkkitehtuurin ja kehittämishankkeiden suhde Kuvan esittämään lähestymistapaan on mukseen perustuvista syistä: 2. KEHITTÄMISHANKKEIDEN OHJAUSMALLI Lähestymistavassamme kokonaisarkkitehtuuri kehittyy eri hankkeissa kertyneiden kokemusten ja niiden arvioinnin kautta. Tällöin kokonaisarkkitehtuurityön kautta kumuloituva tietämys pa- rantaa tulevien kehittämishankkeiden yhteentoimivuutta ja helpottaa niiden vaikuttavuuden ar- viointia (Kuva 1). Säännöllinen kokonaisarkkitehtuurille rakentuva ohjausprosessi parantaa yk- sittäisten hankkeiden koordinointia ja hallintaa osana hankesalkkua. päädytty käytännöllisistä ja kokonaisarkkitehtuuritutki- Kokonaisarkkitehtuurin luominen hallinnonalalle ei ole kertaluonteinenn projekti vaan jatkuvaa prosessi, jonka aikana arkkitehtuuria ylläpidetään ja muokataan muuttuvien tavoittei- den, yhteentoimivuusvaatimusten ja uusien palveluiden vuoksi. Hallinnon toimivuus ja jatkuvuus on turvattava myös uutta toimintamallia kehitettäessä ja käyttöönotettaessa. Tämän vuoksi hallittu muutos on välttämätön reunaehto. Hallinnonalojenn kehittämishankkeidenn ja arkkitehtuurin kehittämisen kokemukset muodosta- vat kokoelman parhaita käytänteitä. Käytänteiden oppiminen ja kokemusten välittämi- nen eri yhteyksistä ja tilanteista tapahtuvat käytännön projektien ja arkkitehtuurin kehit- tämisen vuoropuhelussa, eivät kaavamaisesti soveltaen. 17 Korpela & Mäkitalo 2008, s. 120 18 Ståhle, 2008
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 8 (32) Ehdottamamme malli on tarkoitettu käytettäväksi kehittämisohjelman tai hankealoitteen ohjauksessa hanke-ehdotuksesta kilpailutukseen (hanke-ehdotuksen suunnitteluvaihe) ja toteutettavan hankkeen päättymiseen (hankehallinta) asti. Ohjausmalli painottaa johtamisen, huolellisesti perusteltujen päätösten ja hyvän suunnittelun merkitystä onnistuneelle toteutukselle ja toteutuksen aikaiselle hankehallinnalle. Tässä luvussa on esitetty suunnitteluvaiheen tehtävät (Kuva 2). Näitä täydennetään hankehallinnan kuvauksella luvussa 3. Kuva 2. Kehittämishankkeiden ohjausmalli (suunnitteluvaihe) Kehittämisen lähtökohtana on hallinnon kehittämiseen tähtäävä hankealoite. Se tulee sidosryhmiltä ja sisältää mitattavat tavoitteet, mutta sen tulisi jättää toteutus tässä vaiheessa pitkälti avoimeksi 19. Hankealoitteen vaikuttavuus eri sidosryhmiin, kuten kansalaisiin, yrityksiin sekä viranomaisten ja palveluntuottajien toimiin arvioidaan vaiheessa vaikuttavuusarviointi, jonka valmistelee hankkeen omistaja yhdessä toteuttajan kanssa. Myös olemassa olevat resurssit ja niiden kehittämistarpeet otetaan toteuttamismahdollisuuksien arvioinnin kohteeksi, jolloin kartoitetaan soveltuva infrastruktuuri, toimijoiden resurssit ja heidän kyvykkyytensä hallita kehitys- ja muutostoimia. Kyvykkyyksien kehittämisellä varmistetaan ja aikataulutetaan mm. hankinnat, koulutus ja riittävä resursointi hankkeen toteuttamiseksi toivotussa ajassa. Toivottu aika tarkoittaa tässä aikajännettä, jolla hyödyt alkavat todellisuudessa kertyä sidosryhmille, ei siis esimerkiksi tietojärjestelmäprojektin käyttöönottoajankohtaa. Näin löydetään alustavasti ne toiminnalliset ja resurssien kehittämiskohteet, joilla tavoitteisiin arvellaan päästävän nykyisiä ja lisäresursseja käyttäen. Sekä vaikuttavuusarviointi että toteuttamismahdollisuuksien arviointi on hankkeen omistajan ja toteuttajan yhteinen tehtävä ja tässä vaiheessa on tarpeen käyttää ulkopuolisia asiantuntija-arvioita. Näissä kahdessa vaiheessa syntyvän tavoiteasetannan, hyötykustannusarviot ja resurssikartoitukset/-suunnitelmat tarkastaa kokonaisuudessaan laadunvarmistaja, jonka tehtävänä on myös pohtia hanketta suhteessa arkkitehtuuri- ja yhteentoimivuussuosituksiin toteuttajien kanssa. Kokonaisarkkitehtuurin mukaisuuden arviointi auttaa koordinoimaan hankkeita, kehittämään arkkitehtuurimallia ja ehkäisemään päällekkäisyyksiä valtionhallinnon kokonaisuuden tasolla jo varhaisessa vaiheessa hankealoitteen käsittelyä. Lisäksi kokonaisarkkitehtuurissa määritellyt toimintatavat, suositukset ja reunaehdot on tarpeen huomioida läpi koko ohjausmallin. Muokattu hanke-ehdotus siirtyy seuraavaksi liiketoimintamallin- 19 Hallinnollisia muutoksia on toteutettu usein organisatorisin uudelleenjärjestelyin ja asetusteitse, jolloin on normitettu paitsi tavoite, myös sen toteutustapa. Käytännön tietojärjestelmien tukemassa hallintotyössä tämä on koettu usein kaavamaisena, ylhäältä saneltuna, mielivaltaisena ja joissakin tapauksissa jopa mahdottomana toteuttaa suunnitellusti käytössä olevin resurssein. (Korpela & Mäkitalo, 2008).
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 9 (32) nus-vaiheeseen, jossa toteuttaja etsii vaihtoehtoisia toimintamalleja ja kustannusrakenteita tavoitteiden toteuttamiseksi ja riittävien resurssien hankkimiseksi. Vasta tämän jälkeen hankkeen omistajat (vastuussa olevat viranomaiset) valitsevat toteuttamiskelpoisimman vaihtoehdon laillisuustarkastelun kautta (toimintamallien valinta). Näin pyritään löytämään taloudellisin ja julkishallinnossa toteuttamiskelpoinen, arkkitehtuurin mukainen vaihtoehto sen sijaan, että lähdetään toteuttamaan kaavamaisesti ensimmäisenä mieleen tullutta vaihtoehtoa. Ohjaava vaikutus on rakennettu vaiheistuksen, laadun ja hyötyjen varmistuksen avulla. Laadunvarmistaja tarkistaa laadunvarmistuspisteissä, että vaiheet on tehty riittävällä tarkkuudella ja vastaavat toiminnallisia tavoitteita ja resurssisuunnitelmia. Suunnitellessamme ohjausmallia, sijoitimme nämä mahdollisimman harvat, mutta mielestämme riittävät laadunvarmistuspisteet Kuvassa 2 merkittyihin kohtiin (kuvassa pienillä ympyröillä). Näissä pisteissä on määritelty tavoitteellisen kehittämisen ja yhteentoimivuuden kannalta välttämättömät vaatimukset. Laadunvarmistuksen lisäksi ne toimivat myös myöhemmin valvonnan riskienhallinnan ja hankehallinnan apuna, koska niissä dokumentoidaan hankkeelle asetettujen tavoitteiden saavuttaminen ja kehittämistoimenpiteiden edistyminen sekä hankkeen riskit (esim. päivittämällä hankkeen SWOT-analyysi 20 laadunvarmistuspisteessä). Laadunvarmistus, riskienhallinta ja hyötyjen varmistaminen käsitellään raportissa viimeksi, sillä ne sijoittuvat ohjausmalliin sen alusta loppuun. Hankehallintaan suosittelemme määrämuotoista muutostoimikuntamenettelyä muutostenhallintaan ja portfolionhallintaa järjestelmien ja menettelytapojen elinkaarien hallitsemiseksi. Näin menetellen johdon tehtäväksi jää valvoa hyötyjen toteutumista ja mallin noudattamista yhdessä arkkitehtien kanssa, jotka taas yhdessä projektijohdon ja työntekijöiden kanssa hallinnoivat muutoksia ja järjestelmien elinkaarta johdon asettamien tavoitteiden mukaisesti. Malliin sisältyy jatkuva takaisinkytkentä, vaikka sitä ei ole kuvassa havainnollistettu. Laadunvarmistuspisteissä todetut puutteet aiheuttavat prosessissa paluun edeltäneen vaiheen tehtäviin, jopa mahdollisesti hankkeen keskeyttämisen, mikäli toiminnallisia parannuksia ei saada aikaan tai kehittämistyölle ei ole saatavilla riittävästi resursseja. Tältä osin malli noudattelee ns. päätösporttimallia 21. Määrämuotoisten tarkistuslistojen käyttö ohjausmallissa jää hankkeen omistajan ja toteuttajan harkittavaksi, sillä käytännössä niiden ohjaava vaikutus on ollut vähäinen. Esimerkiksi terveydenhuollon NPfIT- hankkeen Gateway-arviot osoittivat hankkeen olevan vakavissa vaikeuksissa, ja silti sitä jatkettiin 22. Mekanismin kaavamainen toteuttaminen ei riitä, jos eri osapuolten välinen kommunikaatio ja johdon ohjaus eivät toimi. Huomattakoon, että Kuvan 1 mukaisesti ohjausmallin käyttö johtaa iterointiin: hankeohjelmasta johdetut tavoitteet ovat ohjenuorana yhteentoimivuuden, vaihtoehtoisten toimintamallien, resursoinnin ja toteutettavan toimintamallin suunnittelussa, mutta samalla vaihtoehtoja kehittämällä voidaan asettaa kunnianhimoisempia tavoitteita. Yksittäisten, sattumanvaraisesti arkkitehtuuria rakentavien tietojärjestelmähankkeiden sijaan, ohjausmallin avulla arkkitehtuurityötä voidaan ohjata toiminnallisen kehittämisen kautta. Lopuksi, tavoitteet ja dokumentit tarkentuvat vähitellen. Prosessista voidaan niin haluttaessa tehdä läpinäkyvä ja määrämuotoinen tietokonetuettu prosessi, jolloin siihen voidaan jo toteuttamiskelpoisuuden arviointi- ja innovointivaiheissa kerätä palautetta ja ideoita muilta yhteisöiltä (esim. yhteisöalustoja käyttäen ja arkkitehtuurivälineitä käyttäen). 20 SWOT-analyysillä tarkoitetaan tässä tavoitteiden toteutumista edesauttavia tai haittaavia projektin, sen ympäristöstä ja projektilaisten kyvyistä johtuvia menestys- tai uhkatekijöitä sekä mahdollisuuksia ja heikkouksia. Alustavien kokemustemme mukaan se on julkishallinnossa yleisesti tunnettu ja käytetty, nopea ja riittävän yksinkertainen opittavaksi ja sovellettavaksi riskien hallinnassa. 21 esim. Gateway 2009, Gateway 2010; Gateway OGC 2010 22 Malinen & Pyykkö 2010
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 10 (32) 2.1. Roolit Julkishallinnon hankkeet koskettavat lähes poikkeuksetta laajaa sidosryhmien joukkoa. Hallinnollisten muutosten ja järjestelmien riippuvuuden lisääntyessä tarve ottaa laajalti huomioon eri näkökulmia ja hyviä käytänteitä kasvaa. Tätä taustaa vasten pidämme seuraavia rooleja välttämättöminä kehittämishankkeiden hyvän hallinnointitavan kannalta: Hankealoitteesta hyötyvät edunsaajat ovat kansalaisia, yrityksiä ja muita yhteisöjä, sekä viranomaiset itse. Odotettavissa olevat hyödyt on tarpeen arvioida kustakin näkökulmasta ja pyrkiä saamaan hankkeeseen edunsaajien edustus. Hankealoitteesta vastaava viranomainen on hankkeen omistaja. Hankkeen omistajan tehtävänä on järjestää hankkeen riittävä resursointi ja valvoa sen suunnittelu, toteutus ja käyttöönotto ohjausmallin avulla, mahdollisesti sidosryhmien edustajien kanssa. Siihen tulee kuulua ainakin investoinneista ja hankkeista vastaavaa johtoa. Hankkeen toteuttaja vastaa hankkeen johtamisesta, yhteentoimivuudesta ja resursoinnista parhaiden käytänteiden mukaan ohjausmallin mukaisesti. Se on tyypillisesti projekti- tai muutosryhmä, joka koostuu kohdealueen johdosta, arkkitehdeistä, asiantuntijoista ja työntekijöistä tai heidän edustajistaan. Ratkaisutoimittaja vastaa siitä, että toimitettu (osa-)ratkaisu on vaatimusten mukainen. Kansalaiset ja yritykset voivat olla myös viranomaisten lisäksi innovaattoreiden roolissa. Hankkeen laadunvarmistuksesta vastaa toteuttajista ja omistajista välittömästi riippumaton osapuoli. Laadunvarmistaja käyttää tavoiteasetantaa ja -laskelmia arvioidessaan projektitoimien vaikuttavuutta laadunvarmistuspisteissä. Esimerkiksi valtion keskitetyssä rahoitusmallissa rahoittajalla voi olla samalla laadunvarmistajan rooli. Hankkeen tarkastaja on täysin riippumaton osapuoli, joka tarkastelee hankkeen tavoitteiden toteutumista pitkällä aikavälillä. Valtiontalouden tarkastusvirasto on esimerkki tämän roolin toteuttavasta organisaatiosta. Samanlaiseen rooliin sopii valtion kokonaisarkkitehtuurista vastaava taso, kun yhteensopivuutta arvioidaan. Näiden mallin kannalta välttämättömien roolien lisäksi on muita rooleja, jotka ovat sidoksissa kehittämistoimintaan. Niiden tunnistamiseksi mm. tiedottamista ja kuulemista varten suosittelemme RACI-menettelyä, jossa asianosaiset on jaettu neljään päärooliin: Velvollisiin (= Responsible), vastuutettuihin (Accountable), kuultaviin (Consulted) ja informoitaviin (Informed) 23. 2.2. Hankealoite Hankealoite voi tulla hallitusohjelmasta, julkishallinnon organisaatioilta tai kansalaisilta. Kaikista hankealoitteista varmistetaan, että niille määritellään aina tavoitteet, hankkeesta hyötyvät tahot ja erityisesti kenen asemaa hankkeella pyritään parantamaan. Jos näitä ei ole määritelty, hankealoite on palautettava uudelleenvalmisteltavaksi laadunvarmistuspisteestä. 23 Ks tarkemmin luku hyötyjen varmistus.
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 11 (32) 2.3. Hankkeen vaikuttavuuden arviointi Hankkeiden vaikuttavuuden arviointiin osallistuvat eri sidosryhmät (esim. virastot, kansalaiset ja yritykset). Tällöin tarkistetaan hankkeen tavoitteiden realistisuus tulosprisman avulla ja arvioidaan hankkeen tulosten vaikutukset erityisesti kansalaisten sekä yritysten ja yhteisöjen ns. hallinnolliseen taakkaan. Useimmiten hallinnollinen kehittäminen Suomessa tehdään välttämättömyydestä, kiinnittämättä erityistä huomiota siihen, mitä uudistaminen maksaa kansalaisille ja yrityksille. Tästä on ollut seurauksena korkeampia kustannuksia kuin maissa, joissa byrokratian aiheuttamiin hallinnon kannalta välillisiin kustannuksiin asennoidutaan kriittisesti 24. Hankkeiden kustannusten sekä hyötyjen ja hyötyjien arviointiin voidaan käyttää apuna esimerkiksi Laun 25 esittämää mallia. Malli jakaa hyötyjät kahteen luokkaan. Ne ovat julkinen hallinto ja kansalaiset, yritykset ja yhteisöt. Hyötyjä ja kustannuksia voi olla kolmenlaisia: suoria taloudellisia, suoria ei-taloudellisia ja epäsuoria. Vaikuttavuuden arvioinnissa sidosryhmien osallistuminen on keskeistä. Hallinnon kehittämistoiminnassa asiakkaan ja muiden toimijoiden roolit ovat olleet vähäiset, koska viranomaiset ovat toteuttaneet palvelunsa hyvin itsenäisesti ja riippumattomasti. Vaikuttavuuden arviointia voidaankin pitää askeleena kohti parempaa tarve- ja kysyntävaikutusten huomioon ottamista. Se on yksi keino vastata julkisrahoitteisten palvelujen laatu-, kustannus- ja kehityspaineisiin. Aiemmin julkisrahoitteiset palvelut on järjestetty normiohjatulla, hierarkkisella ja resurssiorientoituneella suunnittelu- ja toimintamallilla. 26 Tämä ei aina ole johtanut kansalaisten ja yritysten kannalta sujuvimpiin palveluihin, vaan palvelujen tuotantokustannusten minimointiin ja samalla myös vaikeisiin kapasiteettiongelmiin, kun palvelut on järjestetty niin sanottuina universaalipalveluina hyödyntämättä eri palvelukanavien differointi- ja segmentointi- ja ulkoistamismahdollisuuksia 27. Vaikuttavuuden arvioiminen on tuloksellisuutta koskevan arvioinnin haasteellisin tehtävä 28. Esimerkiksi KuntaIT-hankkeessa on avustettu virastoja hankealoitteiden arvioinnissa konsulttivoimin. Valtionhallinnossa vaikuttavuuden arviointiin käytetään tulosprismaa (Kuva 3), joka määrittää yhteiskunnallisen vaikuttavuuden ja tuloksellisuuden peruskriteerit 29. Sen taustalla on pitkä kehitystyö, joka nojautuu liiketoiminnasta tuttuihin malleihin kuten tasapainotettuun tuloskorttiin (balanced scorecard). Tulosprisma luo pohjan ministeriöiden ja laitosten strategiatyöskentelyyn ja se toimii ohjausvälineenä julkisessa hallinnossa. Vaikka käytännön soveltaminen on selvitystemme mukaan ollut vähäistä, tulosprisma on otettavissa käyttöön suhteellisen vaivattomasti. Vaikuttavuuden arviointi luo myös edellytykset hankkeen omistajalle ja toteuttajalle varmistaa tavoitellut hyödyt 30. Johdon tulee varmistaa tai ylittää asetetut tavoitteet hankkeen elinkaaren suunnittelun, toteutuksen, käytön kuin muutostenkin aikana. Koeteltu tapa on käyttää ns. tavoitekarttaa tavoitellun hyödyn jakamista pienempiin, toisiinsa liittyviin hyötyihin. 24 Korpela & Mäkitalo 2008, s. 105 25 Lau 2007 26 Korpela & Mäkitalo 2008, s. 129 27 Erilaistamisen ja kohdentamisen käyttö voi johtaa eriarvoiseen, ei-yhdenvertaiseen kohteluun. Tämä otetaan mallissa myöhemmin huomioon laillisuustarkastelun muodossa. 28 Hyytinen ym. 2008 29 Valtiovarainministeriö 2005 30 Benefits Realisation Management tai Benefit Assurance.
JYVÄSKYLÄN YLIOPISTO FEAR-projekti OHJAUSMALLI 12 (32) 15.3.2010 Versio 2.0 Final Kuva 3. Tulosprisma FEAR-mallimällä vaiheen aloitusehdot (lähtötiedot), lopetusehdot (tulostiedot) ja arvioinnissa käytettävätt välineet. Kunkin vaiheen tuottamia tulostietoja käytetään seuraavissa vaiheissa lähtötietoina. vaikuttavuuden arviointivaihetta on tarkennettu seuraavassaa (Kuva 4) määrittele- Kuva 4. Hankkeenn vaikuttavuusarvio: lähtötiedot ja tulostiedot 2.4. Toteuttamismahdollisuudet Kohdeorganisaation edellytykset hankkeen toteuttamiseksi arvioidaan rinnan vaikuttavuuden arvioinnin kanssa. Tässä vaiheessa arvioidaan organisaation prosessien, sääntöjen, säännöksien n ja tietojärjestelmien kypsyys suhteessa aiottuun kehittämishankkeeseen. Arviointi sisältää kehit- tämistyön vaatimusten ja edellytysten selvittämisen, mm. infrastruktuurin (laitteet, ohjelmistot, tietokannat) ja kyvykkyyksien osalta. Kyvykkyyksien arvioinnissa voidaan käyttää esimerkiksi i
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 13 (32) EAMM-mallia (Enterprise Architecture Maturity Model 31 ) tai yhteentoimivuuden kehittämisohjelmassa kehitettyä kypsyysarviointimallia, mutta mielestämme pelkkä arviointi ei riitä. Kypsyysarvioinnin tarkoitus on tunnistaa ne kehittämiskohteet aineellisissa ja henkisissä resursseissa (esim. henkilöstön kielitaito, suunnittelu- ja muutoksenhallintakyvyt), jotka ovat välttämättömiä kyseisen hankkeen ja pitkän aikavälin arkkitehtuurin kehittämisen näkökulmasta. Tällöin joudutaan ottamaan väistämättä kantaa lisäresurssitarpeisiin, jolloin on luonnollista, että kypsyysarviointia tehdään vaikuttavuuden arvioinnin kanssa rinnan. Huomattakoon, ettei hankkeen vaikuttavuuden ja toteutusmahdollisuuksien arvioinnissa ole tarkoitus tehdä pikkutarkkaa analyysia toteuttamistavoista, sillä jatkossa sekä kokonaisarkkitehtuurin ja liiketoimintamallintamisen myötä lopullinen toteutus voi vielä muuttua resursseiltaan ja toiminnoiltaan huomattavastikin. Karkea hahmotelma riittää. Seuraavassa kuvassa (Kuva 5) on esitetty toteuttajien arviointivaiheen lähtötiedot, tulostiedot sekä arviointivälineet. Kuva 5. Toteuttamismahdollisuudet: lähtötiedot ja tulostiedot 2.5. Kokonaisarkkitehtuurin mukaisuuden arviointi ja hankkeen julkistus Kokonaisarkkitehtuurin mukaisuuden arvioinnissa tarkistetaan onko hanke linjassa muiden hankkeiden ja esim. valtion/kunnan palvelukartan kanssa. Viimeistään tässä kohdassa otetaan huomioon valtion kokonaisarkkitehtuurissa määritellyt yhteentoimivuusvaatimukset. Tämän arvioinnin tekemisen edellytyksenä on, että joku taho (esimerkiksi ValtIT, KuntaIT tai toteuttajaorganisaation arkkitehdit) on vastuussa kokonaisuuden hallinnasta. Tärkeää on pitää alussa kuvattu vuorovaikutus kehittämishankkeiden ja arkkitehtuurin kehittämistyön välillä käynnissä koordinoidusti. Näin tiedetään käynnissä olevat hankkeet, niiden väliset kytkennät ja ihannetapauksessa rekisteröidään ne kaikkien nähtäväksi (kuten esim. USA:n FEA:ssa, jossa hankkeet ovat julkisesti www:ssä nähtävillä etenemisarvioineen) ja saadaan tiedotettua ja siirrettyä parhaat käytänteet maanlaajuisesti. Lähtökohdaksi on luontevaa ottaa ValtIT/KA arkkitehtuurimalli. Kuvaukset tulee vaatia toteutettavaksi yhteensopivalla tavalla. Niitä tulee voida hallita välineillä, joissa on edistyneet kuvauskirjastot ja keinot niiden hallintaan. Arkkitehtien toiminnan helpottamiseksi voi olla tarpeen 31 NASCIO 2003
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 14 (32) yhtenäistää myös työskentelyprosessi hyvien käytänteiden, sanastojen ja standardoitujen kuvaustekniikoiden muodossa. Kuvassa 6 on tarkennettu kokonaisarkkitehtuurin mukaisuuden lähtöja tulostiedot sekä suositeltavat arviointivälineet. Vaiheen laadunvarmistuspisteessä keskustellaan hanke-ehdotuksen päällekkäisyyksien lisäksi sen tavoitteisiin ja toteuttamismahdollisuuksiin liittyvistä riskeistä. Tarvittaessa hanke-ehdotusta on täsmennettävä tai se on pysäytettävä kokonaan. Kuva 6. Kokonaisarkkitehtuurin mukaisuuden arviointi ja hankkeen julkistus: lähtötiedot ja tulostiedot Vaiheen päättyessä kehittämishanke tulee julkistaa vähintään toteuttavan organisaation sisällä sekä sidosryhmille, joihin hanke tai sen tulokset tulevat liittymään, mutta mieluiten kansallisesti. 2.6. Liiketoimintamallinnus Vaiheessa palataan ideoimaan tavoitteiden ja suorituskykymittareiden asettamia vaatimuksia. Hankkeen osapuolet suunnittelevat organisoinnin ja roolit. Liiketoimintamallinnukseen kuuluu innovointi, johon osallistuvat eri toimijaryhmät, kuten osallistuvien ministeriöiden/virastojen edustajat, konsultit, ohjelmistotoimittajat ja tutkijat ja niin halutessa myös yhteisöt ja/tai yksittäiset kansalaiset 32. Erityisen tärkeiksi voidaan nähdä sellaiset innovaatiot, palvelumallit ja teknologiaratkaisut, jotka vapauttavat rutiinitehtävistä työpanosta inhimillistä vuorovaikutusta edellyttäviin palveluihin ja toimintoihin. Tämä edellyttää nykyisten toimintamallien ja hallinnollisten rakenteiden uudistamista käyttäen hyväksi teknologian mahdollisuuksia ja uusia ideoita. Niitä voivat esittää myös kansalaiset ja yhteisöt julkishallinnon ulkopuolelta, etenkin silloin kun tarvitaan uusia ennakkoluulottomaan tieto- ja viestintätekniikan (esim. sosiaalisen median) käyttöön perustuvia palvelumalleja ja -konsepteja. Kehitystyön painopistettä voi tällöin siirtää pois organisaatio- ja tekniikkalähtöisistä kehitystavoista 33 kohti avoimempaa ja läpinäkyvämpää toimintaa. Liiketoimintamallinnukseen soveltuvia menetelmiä ovat esimerkiksi yhden palvelutapahtuman kuvaava ja määrittelevä malli 34, palvelukanavien erikoistamiseen perustuva malli 35, sekä palvelutarjoomaa ja sen yhteistuotannon (co-creation, crowd-sourcing) suunnittelua avustavat mallit 36, 37, 38 ja kuvaustekniikat 39. Arkkitehtuurityön yhteydessä pyritään yleiskäyttöisiin kom- 32 Vertaa SADe 2009 33 Korpela & Mäkitalo 2008, s. 200-202 34 Kambil & van Heck 1998 35 Luomala ym. 2001 36 Osterwalder & Pigneur 2003 37 Faber ym. 2003 38 Heikkilä ym. 2008
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 15 (32) ponentteihin, joilla omat ja kumppanien resurssit voidaan yhdistää yleiskäyttöisiksi operatiivisiksi palveluiksi, joiden avulla toteutetaan kullekin asiakasryhmälle sopivat liiketoimintamallit. Tarkoituksena on siis yksinkertaistaa operatiivisten mallien avulla asiakassegmenttikohtaiset liiketoimintamallit. Kuva 7. Liiketoimintamallinnus: lähtötiedot ja tulostiedot Kuvassa 7 mainitulla diffuusioarviolla tarkoitetaan aika-arvioita siitä, kuinka pian kansalaiset, yritykset ja yhteisöt omaksuvat ja ottavat käyttöön suunnitellun muutoksen. 2.7. Toimintamallien valinta Toimintamallien valinnan päämääränä on tarkoituksenmukainen resurssien kohdentaminen suhteessa tavoitteisiin ja vaihtoehtoisiin toteutustapoihin. Hanke voidaan toteuttaa sisäisesti tai ulkoistamalla. Toimintamallin valintaa rajoittavat olemassa olevat säännöt ja kustannukset. Näiden huomioimiseksi tarvitaan edellisten vaiheiden tuloksia ja viimeistään tässä vaiheessa toteuttamisesta vastuussa olevan viranomaisen on tehtävä laillisuustarkastelu 40. Skenaariotyöskentely on yleensä tässä vaiheessa arkkitehtuurityössä käytettävä väline. Skenaariotyöskentelyn tukena voidaan käyttää esimerkiksi SWOT- tai kuiluanalyysiä 41. Tässä vaiheessa varmistetaan tavoiteasetannan realistisuus, päivitetään ja hyväksytetään kustannus-hyötylaskelmat, tarkastetaan lopullisesti arkkitehtuurin ja suositusten mukaisuus, sekä arvioidaan uudelleen aineellisten ja aineettomien resurssien tarve ja toimenpiteiden ajoitus. Vaiheen tehtävät luovat myös perustan yhteistoimintamenettelylle, sillä tässä vaiheessa aletaan tietää tulevista muutoksista ja henkilöstön on mahdollista osallistua vaihtoehtoisten toimintatapojen arviointiin. Tämä on tehtävä ennen kilpailutusta, jotta tarjoajille tulevat yksiselitteisesti selväksi tavoiteltavat parannukset ja toteutuksesta vastuussa olevan toimijan valitsema toteutusvaihtoehto. Seuraavassa kuvassa on esitetty toimintamallien valintavaiheen lähtö- ja tulostiedot sekä eri osa-alueet kattava skenaariotyöskentely. 39 Tølle ym. 2003 40 Laillisuustarkastelussa verrataan esitettyä toimintamallia lakisäädöksiin ja yhdenvertaisuusperiaatteen toteuttamiseen. 41 JHS 171, 2009
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 16 (32) Kuva 8. Toimintamallien valinta: lähtötiedot ja tulostiedot 2.8. Kilpailutuksen valmistelu Ohjausmallin edeltävillä vaiheilla pyritään varmistamaan onnistunut kilpailutus. Sen lähtötietoina käytetään kaikkien edellisten vaiheiden tuottamia lopputietoja. Vaiheen tulostietona syntyy hankintalain mukainen tarjouspyyntö, joka siis noudattaa soveltuvin osin edellisten vaiheiden tulosaineistoja sekä JHS-suosituksia (Kuva 9). Kuva 9. Kilpailutuksen valmistelu: lähtötiedot ja tulostiedot Kilpailutuksen valmistelussa joudutaan tekemään hankintaan ja toteutukseen liittyviä päätöksiä: kehitetäänkö itse vai ryhdytäänkö hankintaan; ovatko kaikki tarjouspyyntöön tarvittavat kokonaisuuden kuvaavat taustadokumentit riittävät; tehdäänkö tarjouspyyntö, suorahankinta vai käytetäänkö jo aikaisemmin kilpailutettua puitesopimusta. Tarjouskilpailun voi järjestää itse, alihankintana tai osittaisena alihankintana. Tarjouspyynnön jättämisestä sovelletaan lakia julkisista hankinnoista, joka vaiheena sijoittuu ohjausmallin ulkopuolelle. 2.9. Hankinta Tarjouspyynnön jättämisestä eteenpäin tilaukseen asti sovelletaan lakia julkisista hankinnoista. Hankintaa ei kuvata mallissa tarkemmin, vaan siitä on oma säännöstönsä 42. Huomattakoon, kuitenkin seuraavat seikat: mallin vaiheissa syntyy suuri osa tarjouskilpailutuksessa tarvittavasta dokumentaatiosta siten, että se on suhteessa tavoitteisiin ja pyrkien välttämään tarpeetonta ylenmääräistä dokumentaatiota. malli korostaa tavoitteellisuutta, yhteistyötä ja toteuttavan organisaation oppimista osana julkishallinnon kokonaisuutta. Hankittaessa on muistettava siksi koko julkishallinnon etu: toimivat, käytännön tasolla kehitetyt ratkaisut on voitava ottaa käyttöön ja soveltaa myös muissa julkishallinnon yksiköissä. Hyödyntämis- ja omistusoikeus tietoihin ja toimintamalleihin on muistettava turvata myös muille valtion yksiköille. 42 Finlex 2009
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 17 (32) 3. HANKEHALLINTA Julkishallinnon kehittämishankesalkku on kasvanut jatkuvasti pienentämispyrkimyksistä huolimatta 43. Laajentuvan hankesalkun seurauksena muutoksenhallinta kumuloituu vähitellen hallitsemattomaksi etenkin, jos järjestelmien välillä on paljon riippuvuuksia. Riippuvuuksien ja muutoksien hallinta on yksi arkkitehtuurityön tärkeimmistä ohjausmallilla varmistettavista tehtävistä. Käytännön ongelmat tavoitteiden asetannan epäselvyydessä, osallistumisen vähäisyydessä ja johdon sitoutumattomuudessa 44 vaikeuttavat muutostenhallintaa. Siksi esitämme seuraavassa, että FEAR-ohjausmallin alkuvaiheistuksen roolitusta täsmennetään RACI-mallilla työnjaon selventämiseksi hankesalkun ja muutosten hallinnassa. Muutostenhallinnan ohjauksen lähtökohtana ovat yleiset ja FEAR-tutkimushankkeen havainnot: Lainsäädännön ja ympäristön muutokset aiheuttavat väistämättömiä muutostarpeita ja korjauksia hankkeen perusteisiin ja tavoitteisiin. Etukäteen ei voida varautua kaikkeen vaan muutoksista joudutaan päättämään aidosti suhteessa tavoitteisiin suunnittelu- ja kehittämistyön jo päätyttyä. Muutostarpeet kasautuvat ajallisesti kehittämishankkeen loppupäähän, kun muutokset alkavat hahmottua käytännön arkipäiväisessä työssä. Käyttöönotossa ja käytön aikana paljastuu korjattavaa käytettävyydessä sekä yhteentoimivuudessa muiden järjestelmien kanssa. Muutokset vaikuttavat laajalle, joten niiden vaikutusten arviointi perustuu useimmiten sidosryhmä-analyysiin, kokonaisarkkitehtuurikuvauksiin ja KA-työkaluohjelmistoihin, jotka yhdistetään päätösmenettelyyn. Johdon selkeästi asettamat tavoitteet ja käyttäjien näkemys toiminnallisista vaikutuksista ovat välttämättömät muutosten priorisoimiseksi, ajoittamiseksi ja toteuttamiseksi. Muutoksenhallinta on johdon, arkkitehtien, käyttäjien ja hankehallinnon yhteistoimintaa ja viestimistä. Kaikki järjestelmähankkeet eivät kuitenkaan noudattele arkkitehtuurityön menetelmiä tai tule toteutetuksi arkkitehtuurimenetelmien mukaisesti. Hankehallinnassa ohjausmalli yhdistää tavoitejohtamisen hyvään tietohallintotapaan selventämällä ja eriyttämällä muutoksenhallinnan vastuita. Johdon, johon kuuluu hankkeen omistaja ja osa toteuttajista, tehtävänä on yhdessä käyttäjien kanssa varmistaa hyötyjen toteutuminen vähintään tavoitteiden mukaisesti. Toisaalta projektijohdon tehtävänä on viedä muutokset käytäntöön ja saavuttaa asetetut toiminnalliset ja laatutavoitteet (osa toteuttajista ratkaisutoimittajat). Kokonaisarkkitehtuurista vastaavilla pääarkkitehdeillä ja osa-alueiden kohdearkkitehdeillä on luonteva rooli toteuttajina yhdessä ohjelma- tai projektipäällikön kanssa ohjata hankkeen etenemistä ja välittää ratkaisutoimittajien ja johdon näkemyksiä suhteessa tavoitteisiin koko ohjelman/hankkeen aikana. Alla olevassa kuvassa osapuolten näkökulmat yhtenäistyvät kohti toteutuksen valintaa, jonka jälkeen roolit alkavat taas eriytyä. Alkuvaiheissa erilaiset näkemykset käytettävistä olevista ja 43 Liimatainen ym 2007, Valtiovarainministeriö 2007c. 44 Seppänen ym 2009, Malinen ja Pyykkö 2010.
JYVÄSKYLÄN YLIOPISTO FEAR-projekti OHJAUSMALLI 18 (32) 15.3.2010 Versio 2.0 Final tarvittavista resursseista ja tavoitteista muokkaavat ohjelmaa tai hanketta. Arkkitehtuurinmukai- suustarkastelun jälkeen tiedetään mihin hankkeisiinn ja järjestelmiin kehittämisohjelmalla on liit- tymiä. Tämän jälkeen haetaan yhdessä innovatiivisempia toteutusvaihtoehtoja, joista YT- neuvottelujen ja laillisuustarkastelujen jälkeen voidaan valita toteuttamiskelpoisin toteutus. Täl- löin yhteisen näkemyksen ja yhteistyön olisi syytä olla tiiveimmillään. Kuva 10. Muutos- ja hankehallinta eri rooleissa Hankehallinta alkaa korostua muutostarpeiden kasautuessa projektitoteutuksessa ja käyttöön- otossa. Monet muutoksista ovat pienehköjä ja vaativat ensisijaisesti ratkaisutoimittajien ja arkki- tehtien yhteistyötä 45 (ks. kuva). Johdon mielenkiinto on usein jo erkanemassa uusiin kehittämis- hankkeisiin, ihmiset vaihtuvat, tilanteet muuttuvat ja tekniset ongelmat vievät ratkaisutoimitta- jan huomion. Toteuttajien kannalta kysymys on kriittisestä koordinaatiosta, johtamista, aikaa ja resursointia vaativasta vaiheesta, jossa tavoitteet, laatu ja toiminnallisuus on pidettävä tinkimät- tä mielessä. Siksi arkkitehtien ja ratkaisutoimittajien on kuultava toteuttajia muutostilanteissa ja johdon puututtavaa tarvittaessaa muutostilainteisiin. Ohjausmalli korostaa arkkitehtien roolia: tavoitteisiin tai resursointiin merkittävästi vaikuttavatt muutokset viedään johdon käsiteltäväksi, muut käsitellään kokonaisuudesta vastaavien arkkiteh- tien ja ratkaisutoimittajien yhteistyönä. Määrämuotoisten portfolion- ja muutoshallintamenette- lyjen tarve on keskeistä, jotta yhteistyö saadaan pidettyä vähintään tarpeen mukaan käynnissää (ks. kuvan oikean laidan pystynuolet). Yhteistyön tarve on tunnistettu muutosjohtamisessaa jo pitkään 46. Esim. Leavitt esitti mallissaan muutosten heijastusvaikutuksista, että organisaationn toiminnat ovat niin sidoksissa toisiinsa, että yhden neljästä tekijästä muuttaminen aiheuttaa ainaa vaikutuksia muihin tekijöihin. Näiden hei- jastusvaikutusten hallinta on onnistuneen muutoksenhallinnan ehtona - ja hallitsematta jättämi- nen esteenä. Arkkitehtuurityöllä muutosten kohteet voidaan tunnistaa ja tiedostaa. 45 Tyypillinenn projektinhallintamenettelyn katselmointi ja revisiointikäytäntö. 46 Leavitt 1965
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 19 (32) Rakenne Ympäristö Tehtävät Teknologia Toimijat Kuva 11. Muutosten heijastusvaikutukset (perustuen Leavitt 1964; 2004) Kolme vuosikymmentä myöhemmin hierarkkinen organisaatiomalli on heikkouksistaan huolimatta pystynyt pitämään puolensa ympäristön muutoksia vastaan 47. Eräs keskeisimpiä tekijöitä tässä on ollut systeemisen johtamisen ja tietojärjestelmien käytön lisääntyminen. Se on edellyttänyt määrämuotoisuuden lisäämistä sekä toiminnan kuvaamisessa että joustavampien, osallistuvien ja keskustelevien menetelmien käyttöönottoa muutoksen johtamisessa toiminnan verkostoituessa. Ohjausmallin alussa esitetty roolitus on tarkoituksenmukaista säilyttää myös muutostenhallintavaiheessa, jotta valtuuksien ja vastuiden jako voidaan toteuttaa laatujärjestelmien ja arkkitehtuurityön edellyttämällä tavalla. Käytännössä tämä tarkoittaa sitä, että johto ei ulota toimivaltaansa liian pitkälle vaan delegoi siitä osan käytännössä kokonaisarkkitehtuurista ja osaarkkitehtuureista vastaaville arkkitehdeille, muutosryhmälle ja varsinkin muutoksia käsittelevälle muutostoimikunnalle (näistä enemmän luvussa Muutoksen hyväksyminen ja toteuttaminen). Samalla kommunikaatiokanavien ja sidosryhmien määrä kasvaa ja niiden hallitsemiseksi ja viestimiseksi tarvitaan järjestelmällistä hallintaa, esim. roolien perusteella kuten kuvassa 12 alla. Kuva 12. Muutospyyntö Omistaja: Viraston johto Omistaja, toteuttaja: Pääarkkitehti Toteuttaja, ratkaisutoimittaja: Projektipäällikkö Toteuttaja. Sovellussuunnittelija Toteuttaja, ratkaisutoimittaja: Kohdealueen arkkitehti Toteuttaja, ratkaisutoimittaja: Kouluttaja, koulutussuunnittelija Ratkaisutoimittaja, toteuttaja: Testaaja Edunsaajat: Pilottikäyttäjät Toteuttaja, edunsaaja: Viraston työntekijät, ratkaisun käytännön toteuttajat Toteuttaja, ratkaisutoimittaja: tietojenhallinta ja tietokanta Ohjausmallin roolit RACI-matriisissa esimerkkinä muutospyynnön käsittely (mukaellen BABOK, 2009) R A R R I C I I C C C 47 Leavitt 2004
JYVÄSKYLÄN YLIOPISTO FEAR-projekti OHJAUSMALLI 20 (32) 15.3.2010 Versio 2.0 Final Mallissa hankintaaa edeltävät vaiheet luovat perustan hanke- ja muutostenhallinnalle. Tavoitteett on määritelty, hanke resursoitu, ja vaihtoehtoisista suunnitelmista on päädytty toteuttamiskel- poiseen, arkkitehtuurin mukaiseen malliin. Sen laillisuus on tarkastettu, tavoitteet, riskit ja re- surssisuunnitelmatt on dokumentoitu laadunvarmistuspisteissä ja viestitty RACI:n mukaisestii osallisille. Ohjausmalli antaa johdolle velvoitteen muuttaa tavoitteita hallitusti, seurata hyötyjen toteutumista ja päättää oleellisista muutoksista läpinäkyvällä tavalla. Muutostenhallinnalla varmistetaan, että kehittämishankkeen tavoitteet toteutuvat alunperin aiotulla tai sitä paremmalla tavalla tarkoi- tuksenmukaisesti arkkitehtuuri on pelkistetty ja mahdollisimman yksinkertainen; järjestelmien ja liittymien määrä on minimoitu sivuvaikutukset on minimoitu, jotta muutokset eivät haittaa tai keskeytä muita hankkeita en- nakoimattomasti. Muutostenhallintaa pitää sisällään siten varsinaisen muutostenh hallinnan johtamisen, menettelyta- vat muutosten esittämiseksi, hyväksymiseksi ja portfolion hallintaan. 3.1. Muutostenhallinnan johtaminen Ohjausmallissa muutostenhallinnan tavoitteena on auttaa johtoa (omistajan ja toteuttajan rooarkkitehtien kanssa perustelemaan ja priorisoimaan muutokset hallitsemaan kokonaisuudet ja riippuvuudet myös toiminnann kannalta kriittisten järjestelmien tunnistamiseksi. leissa): saavuttamaan tai ylittämään asetetut tavoitteet yhdessä toteuttajien, erityisesti Kuva 13. Hyvän tietohallintotavan mukainen johtaminen n 48 48 ISO/IEC 38500 2008
JYVÄSKYLÄN YLIOPISTO OHJAUSMALLI 21 (32) toteutettavista muutoksista päättämisen ja tiedottamisen sekä muutosjohtamisen. Muutostenhallinnan voi jakaa suunnitelmalliseen muutoksenhallintamenettelyyn tai joustavaan muutoksenhallintaan (IIBA, 2009). Ensin mainitulla tarkoitetaan sitä, että muutostarve todetaan, suunnitellaan, kommentoidaan, revisioidaan ja pannaan täytäntöön määrämuotoista menettelyä käyttäen. Tällainen menettely on käytössä mm. Puolustusvoimissa ja Helsingin kaupungin han- Muutostenhallinnassa johtajien tehtävänä on ohjata, seurata ja arvioida sekä resursoida arkkitehtuurityöhön perustuva hankekokonaisuuden hallinta (sekä kehittämishankkeet että järjestelmien ja menettelytapojen muutokset) ISO/IEC 38500 standardin mukaisesti. Johdon tulee arvioida hanke-esitykset suhteessa ulkoisiin paineisiin ja toiminnan tarpeisiin (Kuva 13). Hankinnan jälkeisissä vaiheissa johdon rooli on päättää tavoitteisiin vaikuttavien muutosten toteuttamisesta. Johto puuttuu siis toteutukseen vain silloin, kun muutoksella on vaikutusta tavoitteisiin (eli lähinnä edunsaajien hyötyihin) tai merkittävässä määrin kustannuksiin, resurssitarpeeseen, hankintoihin tai toteutuksen lainmukaisuuteen (ks. kuva 10 yllä). ISO/IEC 38500 standardin 48 keskeisten periaatteiden mukaan hankkeita tulee ohjata ja seurata vastuuttamalla ja valtuuttamalla johdonmukaistamalla pitkän ja lyhyen aikavälin toiminta- ja IT-strategiat perustelemalla huolella ja läpinäkyvästi tarpeelliset hankintapäätökset huolehtimalla, että tietojärjestelmät palvelevat organisaation nykyistä ja tulevaa toimintaa varmistamalla, että tietojärjestelmät ovat lainmukaisia ja käytänteet selkeästi määriteltyjä ja toimivia ottamalla huomioon tietojärjestelmäpolitiikassa, käytänteissä ja päätöksissä osallisten oikeudet, käyttäytymismallit ja tarpeet. Keskeiset periaatteet sisältyvät myös operatiivisen toiminnan hallintamalleihin; esim. COBIT 49 - ja ValIT 50 -hallintamalleihin ja näiltä osin ohjausmallin käyttö soveltuu myös niiden yhteydessä käytettäväksi. 3.2. Muutoksen hyväksyminen ja toteuttaminen Suunnitelmallisista muutoksenhallintamenettelyistä on pitkä kokemus teollisuuden verkostoituneiden tuotantoprosessien hallitussa muuttamisessa 51 ja ICT-alalla 52. Näitä ajatuksia soveltaen kehittämisohjelmien ja -hankkeiden johdon ja arkkitehtien toiminta hyväksymis- ja toteuttamisvaiheessa sisältää: muutosvaikutusten analysoinnin hyötyjen saavuttamiseksi, arkkitehtuuria noudattamattomien järjestelmien riippuvuuksien määrittelyn sekä ratkaisut järjestelmien elinkaarikysymyksistä hanke- ja järjestelmäsalkun optimoimiseksi, 49 ITGI 2007 50 ITGI 2008 51 Kuciak 1992 52 ISO/IEC 20000-1, 9.2, ITGI 2007, ITGI 2008, Gateway OGC 2010