Tiina Koskelainen, Eila Nummi, Reko Mätäsaho, Hannu Vänttinen

Transkriptio

1 Tiina Koskelainen, Eila Nummi, Reko Mätäsaho, Hannu Vänttinen KEHITTÄMISHANKKEIDEN OHJAUSMALLI HANKEPROSESSIN MALLINTAMINEN Tietojärjestelmätieteen harjoitustyö Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Jyväskylä

2 1 JOHDANTO Tässä harjoitustyössä tarkastellaan FEAR-projektissa laadittua kehittämishakkeiden ohjausmallia ja mallinnetaan kehittämishankkeen ohjausprosessi. Työssä tarkastellaan prosessin parannusehdotuksia, mallinnuksessa käytetyn työkalun IBM Rational Systems Architect käytettävyyttä sekä prosessiin osallistuvien rooleja kehittämishankkeessa.

3 3 2 KEHITTÄMISHANKKEEN OHJAUSMALLI 2.1 Kuvaus Harjoitustyön aineistona käytettiin FEAR-projektissa laadittua kehittämishankkeiden ohjausmallia (Heikkilä et al 2009). Ohjausmallin tavoitteena on parantaa valtionhallinnossa toteutettavien tietojärjestelmähankkeiden laatua tavoittelemalla järjestelmien yhteentoimivuutta, kustannustehokkuutta sekä asiakaslähtöistä palveluiden tuottamista. Keskeistä on myös osaamisen ja tietotekniikan kehittäminen organisaatioiden ydintoimintaa varten. Ohjausmallissa konkretisoidaan hankeprosessi hanke-ehdotuksesta hankepäätökseen asti. Tärkeänä tavoitteena on varmistaa hankkeen kelpoisuus valtionhallinnon kokonaisarkkitehtuuriin. 2.2 Kehittämisehdotuksia Ryhmätyössämme havaittiin, että harjoitustyössä käsiteltävänä olevassa kehittämishankkeiden ohjausmallissa ei ollut keskeytysmahdollisuutta prosessin aikana. Tekstistä ei käy ilmi prosessin keskeyttämispistettä sen aikana ollenkaan. Näin ollen päädyimme siihen, että prosessi on hyvä saada keskeytettyä arviointipisteissä hukkatyön välttämiseksi, mikäli arviointi antaa niin huolestuttavia tuloksia. Toinen ideamme parantaa prosessia on lisätä päätöksentekopiste ohjausmalliin toimintamallien valinnan ja kilpailutuksen valmistelun väliin. Tällöin saadaan vietyä prosessi joko kilpailutuksen valmisteluun tai omaan toteutukseen. Meistä tämä päätös pitäisi tehdä tässä vaiheessa, koska kilpailutuksen valmistelun hoitava taso ei ole se taso joka voi tehdä päätöstä toteutuksesta. Kilpailutuksen valmistelun alussa hoidettava päätöksenteko voi toki olla parempi vaihtoehto, jos kilpailutuksen valmistelussa käy vielä joitakin asioita ilmi, mutta silloinkin pitäisi olla selkeä keskeytyspiste jossa päätös tehtäisiin. Siirto hankehallintaan ei ole myöskään kilpailutuksen jälkeen itsestään selvää, vaan hanke voidaan jättää kilpailutuksen jälkeenkin toteuttamatta. Tarjoajien

4 4 tekemät tarjoukset voivat ylittää hankkeelle budjetissa varatun summan ja näin ollen toteutusta ei voida suorittaa ilman seuraavaa budjettikierrosta ja sieltä mahdollisesti hankkeelle saatavia varoja.

5 5 3 ROOLIT KEHITTÄMISHANKKEESSA Tässä luvussa käsitellään hanke-ehdotuksen käsittelyyn osallistuvien rooleja. Käsittelyyn osallistuu henkilöitä ja sidosryhmiä sekä organisaation sisältä että sen ulkopuolelta. Hankkeesta tulee koitua hyötyjä joko julkiselle hallinnolle tai kansalaisille ja yrityksille. Valtiontalouden tarkastusvirasto toimii valtionhallinnon hankkeiden valvojana. Viraston tehtävänä on varmistaa, että valtion varoja käytetään eduskunnan päättämiin kohteisiin lakia noudattaen ja varoja järkevästi käyttäen (VTV 2009). Valtiontalouden tarkastusviraston rooli on tutkia toteutuneita hankkeita ja antaa lausuntoja saatujen tulosten perusteella. Kehittämishankeprosessi käynnistyy hankealoitteesta. Hankealoite voi tulla hallitusohjelmasta, organisaation sisältä tai kansalaisilta. Sidosryhmillä on rooli myös hankkeen toteuttamiskelpoisuuden arvioinnissa. Esimerkiksi verohallinnon asiakkaiden tarpeita voidaan kuunnella sähköisen asioinnin kehittämishankkeissa. 3.1 Roolit toteuttamiskelpoisuuden arvioinnissa Virastossa tai muussa valtionhallinnon organisaatiossa hankealoitteen käsittelyn ensimmäisessä vaiheessa arvioidaan toteutuskelpoisuutta organisaation toiminnan kannalta. Toteutuskelpoisuuden arvioinnissa organisaation johto osallistuu hankkeen liiketoiminnallisten hyötyjen arviointiin ja arvioi hankkeen soveltuvuuden organisaation ydintoimintaan. Keskeistä arvioinnissa on myös, että toimintojen laatu ja kustannustehokkuus otetaan huomioon. Käsittely voi tapahtua johtoryhmässä tai osastopäällikkökokouksissa riippuen siitä, miten organisointi on virastossa toteutettu. Ylimmän johdon tulee kuitenkin sitoutua hankkeeseen ja sen esiselvitystyöhön tässä vaiheessa. Organisaation talous- ja suunnitteluyksiköt vastaavat hankkeen vaikuttavuuden arvioinnista. Vaikuttavuuden arviointiin voidaan

6 6 valtionhallinnon tulosmittaristoa tulosprismaa tai muuta organisaatiossa käytössä olevaa tuloksellisuuden mittaamisjärjestelmää. Tasapainoisen tulosmittariston käytön etuna on, että kaikkien sidosryhmien hyödyt voidaan kuvata tavoiteasentantaan. Hanke-ehdotuksen käsittelyä varten voidaan jo tässä vaiheessa valita projektipäällikkö vastaamaan eri yksiköiden ja ulkopuolisten konsulttien laatimien arviointien yhteenvedosta. Toteutuskelpoisuuden arvioinnissa korostuvat siis organisaation johdon, sidosryhmien ja konsulttien roolit. 3.2 Toteuttajien arvioinnin roolit Toteuttajien arviointi suoritetaan yhtä aikaa toteuttamiskelpoisuuden arvioinnin kanssa. Arviointi sisältää kypsyys- ja kyvykkyysarviot sekä kehittämistarpeet aineellisissa ja henkisissä resursseissa. Samalla arvioidaan myös ostopalvelujen ja yhteistyökumppaneiden tarve ja saatavuus. Arkkitehdin, organisaation johtajan ja projektipäällikön roolit ovat tärkeitä toteuttajien arvionintivaiheessa. 3.3 Kokonaisarkkitehtuurin mukaisuuden arvioinnin roolit Virastoissa on otettu jo huomioon tarve kokonaisarkkitehdille. Usein tehtävää hoitaa järjestelmäsuunnittelija oman tehtävänsä ohella. Ministeriöissä, kuten esimerkiksi sisäasiainhallinnossa, voi olla myös omia arkkitehtuuriryhmiä, jotka arvioivat ensin ministeriön tasalla soveltuvuuden yhteiseen arkkitehtuuriin. Organisaation kokonaisarkkitehti arvioi sekä toimintojen että teknisestä näkökulmasta hankkeen soveltuvuutta organisaation arkkitehtuurin. Oman arvioinnin jälkeen tulee hanke-ehdotus toimittaa ValtIT:n yhteentoimivuuden arviointiin. ValtIT:n arvioinnin tarkoituksena on varmistaa, että järjestelmät ovat mahdollisimman yhteiskäyttöisiä ja niissä on mahdollisimman hyvät liittymämahdollisuudet muihin järjestelmiin. Yhteiskäyttöisyys ja palveluarkkitehtuurin sopivuus ovat keskeisiä arviointikohteita. Vielä nyt ei tällaista arviointia ole olemassa, mutta virastoissa

7 7 on selkeä tarve kyseiselle toiminnolle. Rooleista korostuvat sekä arkkitehdin että yhteentoimivuuden varmistajan roolit. 3.4 Liiketoimintamallinnuksen roolit Kun organisaation projektitoimisto tai projektipäällikkö on keräännyt tarvittavat tiedot hankkeen esiselvitykseksi, palataan arvioimaan tavoitteita ja suorituskykymittareita. Tässä vaiheessa hanketta käsitellään mahdollisimman laajasti ja eri näkökulmista. Sidosryhmillä on tärkeä roolinsa liiketoimintamallinnuksessa. Tässä vaiheessa voidaan käyttää konsulttia sekä kansalaisia ja asiakkaita kommentoimassa hanketta. Projekti- tai hankepäällikkö kerää sidosryhmien mahdollisimman innovatiiviset näkökulmat hankkeeseen. Kansalaiset hallinnon asiakkaina ovat tässä vaiheessa tärkeässä roolissa. 3.5 Toimintamallien valinnan roolit Toimintamallien valinnassa tarvitaan oikeudellista osaamista. Organisaation lakimiehen tulee tarkistaa hankkeen laillisuus. Henkilöstöhallinto sekä tietohallinto tarkastavat hankkeelle riittävät resurssit. Henkilöstöhallinnon tai lakimiehen tehtävänä on myös suorittaa YT-menettely, jos hankkeella on henkilöstöä koskevia vaikutuksia. Suunnittelu- ja talousosaston tulee vielä varmistaa kustannushyötylaskelmat. Projektipäällikkö kokoaa arkkitehtuurivaatimukset ja tarkistaa tavoiteasetannan realistisuuden. Hänen johdollaan laaditaan myös vaihtoehtoiset liiketoimintamallit. Projektipäällikön johdolla myös tarkistetaan toimittajien luotettavuus ja toimituskyky. Tämän jälkeen esitellään hanke-ehdotus organisaation johdolle perusteluineen. Organisaation johto päättää hankkeen aloittamisesta. Tässä vaiheessa johdon tehtävänä on tiedottaa organisaatiossa hankkeesta ja toimittaa hanke kilpailutuksen valmisteluun.

8 8 3.6 Kilpailutuksen valmistelun roolit Projektipäällikön tehtävänä on käynnistää toimet kilpailutuksen valmistelemiseksi. Vaatimusmäärittely kootaan hankeprosessin aikana tuotetuista asiakirjoista. Hankinta-asiakirjat valmistellaan yhdessä kaupallisen yksikön kanssa. Hankintapäällikkö tarkastaa asiakirjat ja varmistaa niiden oikeellisuuden. Tarvittaessa asiakirjat katselmoidaan oikeudellisen osaston toimesta. Organisaation johto vahvistaa hankinta-asiakirjat ja kilpailutus voi alkaa.

9 9 4 SYSTEM ARCHITECT TYÖVÄLINEENÄ Ohjeistukseltaan ja käytettävyydeltään System Architectin käyttöönottoa ei voida suositella kenellekään ilman soveltuvaa koulutusta. Mallien valinta aiheuttaa jo monipuolisuudeltaan ongelmia yrityksissä, sillä ihmiset voivat ruveta ilman ohjeistusta käyttämään heistä mielenkiintoisinta tai sopivinta mallia, jolloin voidaan joutua tilanteeseen, että prosessit ovat kuvattu eri malleilla. System Architecht on prosessien kuvaamiseen turhan raskas ja kömpelö, koska se on tarkoitettu arkkitehtuurikuvauksien tekemiseen. Business-prosessien kuvaamisessa käytettävä notaatio ei ole selkeä ja vaikuttaa monilta osin puutteelliselta; tai sitten käyttäjät eivät osaa käyttää sitä puute tämäkin. System Architechissa on muutamia mielenkiintoisia piirteitä, jotka pitäisi tuntea ennen työskentelyn aloittamista: Graafeissa on paljon sisäänrakennettuja toimintoja ja tietoa, näitä vain pitäisi osata käyttää - ei ole mikään muutaman tunnin tutustumisjakson asia. Data Flow vaikuttaisi olevan ainoa keino kuvata prosessin etenemistä vaiheesta toiseen Kaavio tallentuu palvelimelle. Ryhmämme epäili, että kaaviot ovat sidottuja käyttäjän tunnukseen, eivätkä näin ole yhteiskäyttöisiä. SA:ssa on raporttigeneraattori, muttemme saaneet sitä toimimaan kohtuullisella vaivalla. Voisi odottaa, että näinkin arvostetussa välineessä raporttien genereointi pitäisi olla helppoa ja monipuolista. Esim. BPELraporttien generointi pitäisi onnistua muutamalla napin painalluksella, sen tekeminen ei saisi vaatia koko manuaalin kahlaamista.

10 1 5 YHTEENVETO Kehittämishankkeen kuvaaminen prosessina oli haastava prosessi, koska pelkästään kehityshankkeen suunniteltu läpivienti eli prosessin aikana. Samalla meidän mielestämme kehittämishankkeen suunnitellussa kuvauksessa oli muutamia puutteita, jotka toimme esille tässä raportissa. System Architech itsessään tälläiseen prosessikuvaukseen on liian raskas väline ja sen opettelu parissa tunnissa itsenäisesti ei mielestämme ole mahdollista. Neljännellä käyttökerralla vasta pystyimme luomaan assosiaatioita uimaradoilta toiselle. Toki ensimmäisellä kerralla olimme kokeilleet toimintaa ja huomaneet joitain hankaluuksia käytössä. Uskomme kuitenkin että System Architech on toimiva sovellus sellaisenaan arkkitehtuurien kuvauksiin, kunhan käyttöönottava organisaatio järjestestää riittävän koulutuksen sen käyttäjille. Emme usko tämän järjestelmän opettelun olevan yhden päivän koulutuksella opittava asia, vaikka koulutettavilla olisikin hyvä käsitys siitä mitä yritysarkkitehtuuri on. Varsinkin raporttien luomiseen pitäisi saada koulutusta, koska ohjeiden löytäminen siihen oli hakalaa eivätkä kokeilemalla tuotetut raportit eivät olleet lähelläkään sitä mitä haluttiin. Kokonaisuudessaan ryhmätyöstä olisi ehkä saanut enemmän irti, jos tehtävänanto olisi ollut selkeämmin määritelty ja System Architechin käyttöön olisi opastettu paremmin. Käytännön tekeminen opettaa kyllä paremmin kuin pelkät luennot, joten sen suhteen ryhmätyön tekeminen on perusteltua.

11 11 LÄHDELUETTELO Heikkilä J., Kella T., Liiimatainen K. ja Seppänen V Kehittämishankkeidenohjausmalli. Hankealoitteesta tavoiteasetannan kautta kilpailutukseen. FEAR-projekti. Jyväskylän Yliopisto.