VAASAN YLIOPISTO TEKNILLINEN TIEDEKUNTA TUOTANTOTALOUS. Mikko Hammar ICT-PALVELUHANKINTOJEN ARVIOINTI Tapaus: Tiehallinto - PDF\nVAASAN YLIOPISTO TEKNILLINEN TIEDEKUNTA TUOTANTOTALOUS. Mikko Hammar ICT-PALVELUHANKINTOJEN ARVIOINTI Tapaus: Tiehallinto\nDownload "VAASAN YLIOPISTO TEKNILLINEN TIEDEKUNTA TUOTANTOTALOUS. Mikko Hammar ICT-PALVELUHANKINTOJEN ARVIOINTI Tapaus: Tiehallinto"\n1 VAASAN YLIOPISTO TEKNILLINEN TIEDEKUNTA TUOTANTOTALOUS Mikko Hammar ICT-PALVELUHANKINTOJEN ARVIOINTI Tapaus: Tiehallinto Tuotantotalouden oppiaineen pro gradu tutkielma VAASA 2010\n2 2 ALKUSANAT Tämän tutkimuksen tekeminen on ollut pitkä prosessi, jonka aikana olen päässyt tutustumaan yhä paremmin Tiehallinnon toimintaan. Haluan kiittää nykyisen Liikenneviraston tieto-osastoa tuesta ja mielenkiinnosta tutkimusta kohtaan. Tämän työn ohjaajana toimi professori Josu Takala, joka auttoi tutkimuksen alussa, kun tutkimusta vasta hahmoteltiin. Haluan kiittää häntä kannustamisesta ja työni ohjaamisesta. Liikennevirastosta haluan erityisesti kiittää yksikönpäällikkö, FM Juha Siltasta. Juha on toiminut työn ohjaajana opastaen ja tukien tutkimuksen aikana tulleissa ongelmissa. Hän on myös kommentoinut tutkimusta useaan otteeseen ja ollut näin suureksi avuksi. Haluan kiittää myös kotijoukkoja tauottomasta tukemisesta ja kannustamisesta. Erityisesti kiitos kuuluu Emmalle. Helsingissä Mikko Hammar\n3 3 VAASAN YLIOPISTO Teknillinen tiedekunta Tekijä: Tutkielman nimi: Mikko Hammar ICT-palveluhankintojen arviointi. Tapaus: Tiehallinto. Josu Takala Kauppatieteiden maisteri Tuotannon laitos Tuotantotalous Ohjaaja: Tutkinto: Laitos: Oppiaine: Opintojen aloitusvuosi: 2008 Tutkielman valmistumisvuosi: 2011 Sivumäärä: 118 TIIVISTELMÄ: Tässä tutkimuksessa tarkasteltiin Tiehallinnon ICT-palvelunhankintaprosessia kolmen loppuun asti viedyn ICT-hankkeen perusteella. Tarkasteltavat hankkeet olivat kookkaita ja niillä on ollut vaikutus useisiin tietojärjestelmiin ja käyttäjiin. Jokainen tietojärjestelmä on hankittu eri hankintatavalla. Hankintatavat ovat silloisen Tiehallinnon suosimia tapoja. KOKA2008-hankinta toteutettiin osittaisräätälöintinä, jossa palvelualusta rakennettiin eri tuotteista. Häiriötietojärjestelmä toteutettiin kokonaisräätälöintinä tietojärjestelmän spesifisyyden takia. Matka-aikatietopalvelu toteutettiin Tiehallinnon puolelta ensimmäisenä isona palveluhankintana, jossa Tiehallinto osti käytännössä toimittajan tuottamaa tietoa Suomen tieverkolta. Tutkimus on toteutettu hyväksikäyttäen aineistoanalyysiä, jonka pohjalta tehtiin haastattelukysymysten sarja. Tutkimuksen osana on haastatteluanalyysi, jossa haastateltiin projekteissa eri tehtävissä toimineita henkilöitä. Yritysten keskittäessä toimintansa ydinosaamiseensa on esimerkiksi ICT-ratkaisuja pyritty ulkoistamaan niihin erikoistuneille yrityksille. Ulkoistamisprosessi, erityisesti tietojärjestelmätasolla, on haastava prosessi. Siihen liittyvät tekijät kuten loppukäyttäjät, budjetti, aikataulu ja sidosryhmät luovat lisää haastetta prosessille, jonka odotetaan tuottavan toimiva tietojärjestelmä tai palvelu. Myös valtionhallinnon sisällä on todettu ulkoistamisen olevan ratkaisu, jolla viraston toiminta saadaan kohdistettua enemmän sen ydintoimintoon. Tiehallinto on kokenut saman muutoksen 2000-luvun vaihteessa. Vuoden 2010 alusta Tiehallinnon keskushallinto on osa Liikennevirastoa AVAINSANAT: hankintaprosessi, palveluhankinta, tietojärjestelmä, prosessimalli\n4 4 UNIVERSITY OF VAASA Faculty of Technology Author: Mikko Hammar Topic of the Master s Thesis: Analyzing ICT-Services purchase prosesses, Case:Tiehallinto. Instructor: Josu Takala Degree: Master of Science in Economics and Business Administration Department: Department of Production Major subject: Industrial Management Year of Entering the University: 2008 Year of completing the Master s Thesis: 2011 Pages: 118 ABSTRACT: The purpose of this research is to analyze ICT services purchasing processes in Tiehallinto, Finnish Road Administration. The base for analyze comes from three different purchase. Each purchase presents different way of purchasing: tailored implementation, partly tailored implementation and service purchase. This research combines two research methods: analyze of project documentation and theme interviews. Theme interviews were based on analyze of the project documentation and frame of reference. From each purchase three different roles were interviewed, purpose to cover three organization levels. Common trend is to focus on companies core competencies which lead companies into outsourcing some of their business functions. Especially outsourcing ICTknowledge has been one of those functions. Outsourcing is massive and challenging process. Operating in the role of customer is also enormous challenge. Customer s knowledge will play big role when defining and ordering ICT-services. Focusing into core competencies was introduced into Finnish Government s Agencies. Tiehallinto outsourced its ICT-department in the early KEYWORDS: Process of purchasing, Service purchasing, Information System, process model\n5 5 SISÄLLYSLUETTELO sivu 1. JOHDANTO TUTKIELMAN TAVOITTEET Tutkimusmenetelmät Tutkimuksen rakenne PALVELUNHANKINTAPROSESSIN VIITEKEHYS Hankintaprosessin rakenne Työvälineet tietojärjestelmähankinnassa Prosessimallit Mallinnuskieli Henkilöstöresurssit osana palvelunhankintaa Projektipäällikön merkitys Asiakas Käyttäjä Käyttöpalvelutoimittaja Työvaiheet Vaatimusmäärittely Riskianalyysi Kilpailutus ja sen vaikutus Suunnittelu Toteutus Testaus Käyttöönotto Ohjaavat tekijät Budjetti Käyttöympäristö Aikataulu Tavoite Yhteenveto viitekehyksestä...48\n6 6 4. TUTKIMUSKOHTEEN ESITTELY Liikennevirasto TAPAUS: Häiriötietojärjestelmä (Häti) TAPAUS: Matka-aikapalvelu TAPAUS: KOKA TUTKIMUKSEN TOTEUTUS Tutkimusmenetelmät ja eteneminen Tutkimuksen luotettavuus TULOKSET TAPAUS: HÄIRIÖTIETOJÄRJESTELMÄ (Häti) Projektityöskentely Koulutus ja käyttöönotto Yhteenveto:HÄTI Viitekehyksen yhteys kohdetapaukseen TAPAUS:KOKA Ohjeistus ja KOKA:n ymmärtäminen Yhteenveto:KOKA Viitekehyksen yhteys kohdetapaukseen TAPAUS:Matka-aikatietopalvelu Lupamenettely Kameroiden soveltuvuus Linkkitolppien tiedonsiirto Viestintäsuunnitelma Yhteenveto: Matka-aikatietopalvelu Viitekehyksen yhteys kohdetapaukseen...90\n7 7 7. PARANNUSEHDOTUKSET Häiriötietojärjestelmä (Häti) KOKA Matka-aikatietopalvelu (MTP) Yhteenveto YHTEENVETO Vastaukset tutkimusongelmiin Tämän tutkimuksen rajoitteet Lähdekritiikki Jatkotutkimusongelmat LÄHTEET LIITTEET LIITE 1: Haastattelujen kysymyssarja 115\n8 8 KÄSITTEET Häti = Häiriötietojärjestelmä KOKA2008 = Korkean käytettävyyden palvelualusta, rakennettu vuonna Käyttöpalvelutoimittaja = Liikenneviraston perusinformaatioteknologian toimittaja ja ylläpitäjä. Liikennevirasto = kolme valtion virastoa yhdistyi. (Tiehallinnon keskushallinto, Merenkulkulaitos ja Ratahallintokeskus). Loppukäyttäjä = Henkilö joka tulee työskentelemään kohteena olevan tietojärjestelmän kanssa. Matka-aikatietopalvelu (MTP) = Ajantasaisen liikennetiedon lähdejärjestelmä Monitoimittajaympäristö = Tilaajan ja toimittajan lisäksi palvelun toimitukseen osallistuu kolmas tai useampi osapuoli. Sidosryhmä = henkilö tai yritys, joka liittyy kohteeseen roolilla. SONJA = Tiehallinnon viestinvälityspalvelu. Tielaitos = Valtion virasto, josta vuonna 1998 eriytettiin tuotanto (Tieliikelaitos(nykyisin Destia Oy)) ja hallinto (Tiehallinto). Tielaitos nimi poistui käytöstä. Toimittaja = Tietotekniikkapalveluja tarjoava yritys.\n9 9 1. JOHDANTO Tietojärjestelmän toteutus voi pohjautua markkinoilla oleviin tuotteisiin, mutta useimmissa hankinnoissa valmisohjelmaa joudutaan räätälöimään tai rakentamaan täysin oma sovelluskerros, joka hyödyntää valmisohjelmistoa. Tietojärjestelmän hankintaprosessi on muuttunut paljon viimeisen kahdenkymmenen vuoden aikana. Tietojärjestelmien laajentuminen ja monimutkaistuminen on vaikuttanut hankintaprosessiin, tehden siitä monimutkaisen. Tässä tutkimuksessa käsitellään entisen Tiehallinnon ( alkaen osa Liikennevirastoa) tietojärjestelmähankkeita, kolmen kohdehankinnan perusteella. Tiehallinto, joka nykyään on Liikenneviraston tieosasto, on Suomessa yksi tieverkon ylläpidosta vastaavista viranomaisista. Väylänpitoon suunnattuja tietojärjestelmiä ei ole tarjolla valmiina, vaan ne joudutaan räätälöimään tilanteen mukaan. Monimutkaiseksi tietojärjestelmän hankintaprosessin Liikennevirastossa tekee se, ettei käytössä oleva palvelinympäristö tai muu tietotekniikka ole omaksi hankittua, vaan sarja käyttöpalvelutoimittajan tarjoamia palveluita. Tämä monimutkaistaa palvelunhankintaprosessissa, koska Liikenneviraston ja tietojärjestelmätoimittajan lisäksi hankintaprosessiin liittyy kolmas toimija, joka on käyttöpalvelutoimittaja. Edellä kuvattua ympäristöä voidaan kutsua termillä monitoimittajaympäristö. Monitoimittajaympäristössä tiedonkulku, yhteistyö ja ylipäänsä vuorovaikutus eri osapuolien välillä on hankinnan kannalta erittäin tärkeää. Monitoimittajaympäristö ja pitkälle kehittyneet ICT-arkkitehtuurit luovat ympäristön, jossa vaikuttavia muuttujia on lukuisia ja niiden ymmärtäminen ja hallinta vaatii asiantuntijuutta ja yhteistyötä. Tässä tutkimuksessa tutkitaan Tiehallinnon tietojärjestelmien hankintaprosessia kolmen toteutuneen hankinnan perusteella. Hankinnat edustavat eri tekniikoihin perustuvia toteutuksia ja kuvaavat Tiehallinnon tietojärjestelmäympäristöä kattavasti.\n10 10 2. TUTKIELMAN TAVOITTEET Tämän tutkielman tavoitteena oli paikallistaa palvelunhankintaprosessin tehostamista vaativat vaiheet sekä tehdä parannusehdotukset näiden vaiheiden parantamiseksi. Tiehallinnon palvelunhankintamallissa hankinta on jaettu eri vaiheisiin, joista jokainen toimii omana kokonaisuutena. Vaiheet noudattavat pitkälti yleisesti tunnettua vesiputousmallia. Vesiputousmalli käsitellään tarkemmin kappaleessa Kohdehankinnoista yksi noudatti osittain ketterää menetelmää. Ketterää menetelmää ei ollut aiemmin käytetty Tiehallinnossa, joten tämä tutkimus arvioi menetelmän toimivuutta Tiehallinnon kaltaisessa organisaatiossa. Tutkimuskysymyksiksi muodostuivat seuraavat kaksi. 1. Mikä tai mitkä palvelunhankintaprosessin vaihe/vaiheet aiheuttavat ongelmia ja minkälaisia ongelmat ovat. 2. Kuinka palvelunhankintaprosessia voidaan tehostaa olemassa olevilla resursseilla. Palvelunhankintaprosessin vaiheita tutkittiin kolmen kohdehankinnan perusteella, jotka olivat Häiriötietojärjestelmä (Häti), KOKA2008 ja Matka-aikatietopalvelu. Valitut hankinnat edustavat Tiehallinnossa käytössä olleita erilaisia hankintatapoja. Hankinnat olivat työmääriltä laajoja ja teknisesti vaativia, siksi näiden hankintoja, jolloin näiden hankintojen edustamat käytännöt ja prosessit edustavat Tiehallinnon suuria hankintoja. Hankkeiden lopputuloksina on täysin räätälöity tietojärjestelmä (Häti), täysin palveluna ostettu tietojärjestelmä (Matka-aikatietopalvelu) ja osittain räätälöity palvelualustaratkaisu (KOKA2008). Yksi tutkielman yksi tavoitteista oli myös löytää mahdolliset eroavaisuudet tehostamista vaativista osa-alueista, kun hankinnan lopputuloksena oleva tietojärjestelmän ratkaisutapa eroaa toisistaan sekä tehdä ohjeistus erojen hallitsemiseen. Tietojärjestelmien hankinta on monimutkainen ja pitkä prosessi, varsinkin niissä hankinnoissa joissa yhtä tai useampaa tuotetta joudutaan räätälöimään asiakkaan toiveiden mukaiseksi.\n11 Tutkimusmenetelmät Tutkimus käsittelee palveluhankintaprosessia kokonaisuutena, joka sisältää prosessin kaikki vaiheet tavoitteen asettamisesta valmiiseen tuotteeseen ja sen ylläpitoon. Tutkimuksen kannalta on merkittävää se, että jokainen hankintaprojekti oli saatu päätökseen ennen tutkimuksen aloittamista. Tällöin voidaan nähdä hankintaprojektin eri vaiheiden vaikutukset keskenään. Metsämuurosen mukaan kvalitatiivinen tutkimus muodostuu joukosta erilaisia tulkinnallisia tutkimuskäytäntöjä. Kvalitatiivisen tutkimuksen aineisto on yleensä einumeerista. (Metsämuuronen, 2005: ) Tämä tutkimus suoritettiin empiirisenä tutkimuksena, joka koostui pääasiassa haastatteluosiosta ja kyselyosiosta. Tutkimus on kvalitatiivinen, koska tutkimusaineisto on pääasiassa verbaalista (haastatteluaineisto). Tutkimuksen aikana suoritettiin myös aineistoanalyysi tutkimuskohteiden dokumentaatiosta. Aineistoanalyysin päätarkoituksena oli luoda pohja kysymyksille, joita käytettiin haastatteluissa kysymysrunkona. Tutkimuskohteina olevat tietojärjestelmät ja tietopalvelu on hankittu Tiehallinnon hankintaprosessin mukaisesti, jolloin toteutukset kilpailutettiin ulkopuolisilla palveluntoimittajilla. Tutkittaviksi hankinnoiksi valittiin räätälöity tietojärjestelmä, joka hankittiin omaksi, korkeakäyttöinen sovellusalusta, joka toteutettiin käyttöpalvelutoimittajan hallinnoimaan palvelinmetsään ja matka-aikapalvelu, joka hankittiin täysin ulkopuolisena palveluna. Esimerkkihankinnat valittiin niin, että ne edustaisivat Tiehallinnon kaikkia hankintatapoja mahdollisimman hyvin. Uusitalon mukaan aina ei ole mahdollista eikä edes järkevää pyrkiä tutkimaan koko aineistoa, joka Tiehallinnon tapauksessa tarkoittaisi toistasataa tietojärjestelmää. Silloin on siitä valittava edustava otanta, jota tässä tutkimuksessa edustaa kolme aiemmin mainittua tietojärjestelmää. (Uusitalo, 2001: )\n12 12 Vertailtavien hankkeiden koot vaihtelevat keskenään, kuitenkin kaikki ylittivät kilpailutuskynnyksen, jolloin hankinnat on suoritettu karkeasti arvioiden samoilla työvaiheilla. Yhtenevien työvaiheiden seuraaminen on tutkimuksen kannalta tärkeä, koska silloin voidaan verrata eri prosessin vaiheita. (Uusitalo, 2001: 70 71; Eskola ja Suoranta, 2000: 18; Hirsjärvi, 2001:155.) Jotta tutkimus ei jäisi vain kuvailuksi tai selvitykseksi on sen sisällettävä teoriaa, johon tutkimus pohjautuu. (Eskola ja Suoranta, 2000: ) Tutkimuksessa esitellään kaksi yleisintä tietojärjestelmäprosessimallia, vesiputousmalli ja spiraalimalli. Tutkimuksen hankintaprosessin viitekehys on muodostettu pääasiassa näiden mallien pohjalta. Viitekehystä on verrattu myös muihin prosessimalleihin, mutta tutkimuksen kannalta ei ole olennaista esitellä kaikkia mahdollisia tietojärjestelmän hankintaprosessimalleja. Valitut pohjateoriat edustavat kahta perushankintatyyppiä. Vesiputousmalli edustaa perinteistä vaiheittain etenevää mallia, kun spiraalimalli edustaa yleistyvää iteroivaa hankintamallia. Tutkimuskohteista kaksi on hankittu noudattaen vesiputousmallia ja yksi iteroivaa prosessimallia. Teoria on koottu pääasiassa ulkomaisista lähteistä, käyttäen kohdeaihetta koskevien julkaisujen viitteissä usein ilmaantuvista lähdeaineistoista. Tietojärjestelmän hankintaan tai kehittämiseen keskittyneessä kirjallisuudessa ei yleisesti tunneta Suomen julkishallinnon hankintalakia, joka vaikuttaa hankintaprosessin viitekehykseen voimakkaasti. Tämä lainsäädännön tuoma ominaisuus on tuotu viitekehykseen lisänä. Tietojärjestelmähankkeet olivat Tiehallinnossa pääsääntöisesti ainutlaatuisia ja Tiehallinnon toiminnan takia hyvin spesifisiä. Tästä johtuen eri tietojärjestelmien välille on hyvin vaikea luoda selkeitä mittauspisteitä tai numeerisia vertauskohtia. Metsämuuronen ja Hirsjärvi esittävät kvalitatiivisen tutkimuksen soveltuvan tutkimuskohteisiin, joita ei voida mitata määrällisesti. (Muuronen, 2005: 43 44,199; Hirsjärvi et al., 2001: 152.)\n13 13 Henkilötyöpäivät, budjetti ja aikataulu ovat täysin hankintaspesifiä, eikä niiden vertailulla saavuteta toivottua tulosta. Tutkimuksen tulos perustuu aineistoanalyysin pohjalta tehdyn haastattelun tuloksiin, jossa hankinnoissa mukana olleet henkilöt ovat saaneet esittää oman näkemyksensä eri hankinnan vaiheiden läpimenoon ja onnistumiseen. Kvalitatiivisessa tutkimuksessa Eskolan ja Suorannan mukaan tavoite on mm. löytää ja paljastaa asioita. Tämän tutkimuksen tavoitteena oli löytää Tiehallinnon hankintaprosessin pullonkaulat. Teollisuudessa tuotantolinjan pullonkaulojen löytäminen voi onnistua mittaamalla esimerkiksi tietyn tuotantovaiheen läpimenoaikaa, tämän tutkimuksen kohteiden pullonkaulojen löytämiseen on käytettävä erilaisia menetelmiä, kuten henkilöhaastattelua. Tutkimusmenetelmistä ja tutkimuksen etenemisestä kerrotaan tarkemmin luvussa viisi Tutkimuksen rakenne Tutkielman tavoitteet kappaleessa käydään läpi mitä tällä tutkielmalla pyritään saavuttamaan ja mitkä ovat tutkimuksen hyödyt nykyiselle Liikennevirastolle. Toisessa luvussa esitellään palvelunhankintaprosessin viitekehyksen teoriapohja, joka pitää sisällään henkilöstöresurssit, työvaiheet, työkalut ja ohjaavat tekijät. Kolmannessa luvussa esitellään tämän tutkimuksen kohdehankinnat ja Liikennevirasto, jolle tämä tutkimus tehdään. Neljännessä luvussa esitellään tutkimusmenetelmät, joilla tämä tutkimus on tehty. Viidennessä luvussa esitellään tämän tutkimuksen tulokset. Luvussa esitellään lisäksi parannusehdotuksia, palveluhankintaprosessin parantamiseksi, sekä projektitoiminnan parantamiseksi. Kuudennessa luvussa nostetaan esiin mahdollisia jatkotutkimusaiheita palvelunhankintaprosessin tehostamiseksi. Luvussa arvioidaan myös tämän tutkimuksen pätevyyttä yleisesti nykyisessä Liikennevirastossa ja yleisesti. Tutkimuksen päättää yhteenveto.\n14 14 3. PALVELUNHANKINTAPROSESSIN VIITEKEHYS Kun tavoitteena on hankkia laadukas tietojärjestelmä, eri prosessimalleja tutkineen Gaon yhteenvedon mukaan oikean prosessimallin merkitys tietojärjestelmähankkeessa on suuri. (Gao, 2010.) Gaon tutkimuksen tulokseen yhtyvät Kettunen kirjassaan Tietojärjestelmän ostaminen sekä Pressmann kirjassaan Software Engineering. (Kettunen 2002; Pressman 2005: ) Pressmanin ja Kettusen lisäksi useat aihepiirin teokset käsittelevät prosessimallia hankinnan runkona, joka vaihtelee tavoitteen ja siihen vaikuttavien tekijöiden mukaan. (Pfleeger, 2001: 45-48; Sommerville, 2001: 44.) 3.1. Hankintaprosessin rakenne Hankintaprosessi koostuu erilaisista elementeistä, jotka kaikki vaikuttavat suoraan hankinnan lopputulokseen, näistä yksi on prosessimalli. Aikataulu ja raha rajaavat hankintaa tarkasti, mutta näiden kahden elementin rajaamalla alueella voidaan toteuttaa hyvinkin erilaisia ratkaisuja. Tällöin hankintaprosessiin muut elementit korostuvat. Ratkaisu, jota tässä tutkimuksessa kuvataan tietojärjestelmänä tai tietopalveluna, saa vaikutteita ennen kaikkea projektiryhmän toiminnasta, jolloin henkilöiden toiminta. Pfleeger painottaa asiakkaan, käyttäjän ja kehittäjän välistä yhteistyötä ja kommunikaatiota. Hänen mukaansa on ensiarvoisen tärkeää ymmärtää mitä asiakas sekä käyttäjät haluavat. (Pfleeger, 2001: 50.) Vesiputousmallin mukaisesti etenevässä tietojärjestelmähankkeessa tietojärjestelmän rakenne, toiminnot, ominaisuudet ja näkymät päätetään hankintaprosessin alkuvaiheessa. Tämä voi osoittautua ongelmaksi hankinnoissa, joissa esimerkiksi käyttäjävaatimukset voivat muuttua hankinnan edetessä. Vesiputousmallia onkin tämän syyn takia kritisoitu sopimattomaksi tietojärjestelmähankintaan sen kankeuden takia. Vesiputousmallia ei koeta ongelmia ratkaisevaksi prosessimalliksi, jollaista kaivataan nykyaikaisten tietojärjestelmien kehittämiseen. (Bowles, 2006: 111; Pressman 2005: 26-29; Pfleeger, 2001: 50.)\n15 15 Projektiryhmä on projektia edistävä ryhmä, jonka tehtävänä on jakaa hankintaan liittyvät tehtävät niin, että kutakin tehtävää edistää siihen sopivin henkilö. (Hrvoje ja Zeljka, 2004: 391.) Projektiryhmän tietotaito vaikuttaa suoraan siihen, kuinka hyvin hankinta onnistuu. Ihmisen vaikutus tietojärjestelmän hankintaan huomattiin jo luvulla muun muassa Victor Basilin toimesta, joka tutki ihmisen vaikutusta tietojärjestelmän kehittämisessä. Muita projektia rajaavia tekijöitä tai siihen suoraan vaikuttavia tekijöitä ovat tavoite, budjetti, teknologia ja aikataulu. (Basili, 1979.) Pressmanin mukaan kommunikaatio, suunnittelu, mallintaminen, toteutus ja käyttöönotto kuuluvat hankintaprosessiin riippumatta siitä mikä prosessimalli on kyseessä. Pressmanin mukaan toteutusvaihe pitää sisällään myös testaamisen. (Pressman, 2005: 56.) Kommunikaation rooli tulee esille heti hankintaprosessin alussa, kun projektiryhmä aloittaa vaatimusmäärittelyn. Muut vaiheet tulevat mukaan hankintaprosessiin myöhemmässä vaiheessa riippuen prosessimallista. (Pressman, 2005: 56.) Tiehallinnon toimintaympäristö on haastava kokonaisuus, jossa yhdistyy useita eri teknologioilla toteutettuja tietojärjestelmiä. Tiehallinnon ICT-ympäristöä voidaan kuvata termillä monitoimittajaympäristö. Monitoimittajaympäristössä tietojärjestelmäprojektiin ovat sidoksissa jo olemassa olevat tietojärjestelmät, tietojärjestelmätoimittajat ja käyttöpalvelutoimittaja. Hankittavan ICT-palvelun tulee mukautua näihin rajaaviin tekijöihin. Seuraavissa luvuissa esitellään viitekehykseen liittyvät elementit. Elementit on jaettu eri ryhmiin työkaluihin, työvaiheisiin, henkilöstöresursseihin ja rajaaviin tekijöihin.\n16 Työvälineet tietojärjestelmähankinnassa Prosessimalli ei sellaisenaan ole ratkaisu, joka poistaa tietojärjestelmähankintaprosessin ongelmat ja tuottaa laadukkaan tietojärjestelmän tai -palvelun. Eri prosessimallit on kehitetty helpottamaan hankintaprosessia. Projektiryhmä käyttää prosessimallia työkaluna Prosessimallit Roger Pressman kuvaa kirjassaan Software Engineering tietojärjestelmäprosessimallin kehyksenä, joka pitää sisällään erilaisia tehtäviä ja menetelmiä, jotka vaaditaan laadukkaan tietojärjestelmän rakentamiseen.(pressman, 2005: 53.) Työkalut Menetelmät Prosessi Laatunäkökulma Kuva 1: Tietojärjestelmäsuunnittelun tasot, mukailtu. (Pressman, 2005: 54). Pressman kokoaa kuvan 1 mukaisesti tietojärjestelmän kehittämisprosessin tasot: laatunäkökulma, prosessi, menetelmät ja työkalut tasoista. Laatunäkökulmalla Pressman tarkoittaa sitä, kuinka hyvin tietojärjestelmä tukee yrityksen/organisaation liiketoimintaa. Tietojärjestelmän tulee tuottaa hyötyä toiminnalle, joko rutiineja helpottavana työkaluna tai tuottoa parantavana työkaluna. Liiketoiminnan laatuajattelu on oltava tietojärjestelmähankkeen takana. Prosessitaso toimii tietojärjestelmäkehittämisen perustana. Sen tarkoitus on yhdistää eri teknologiatasot toisiinsa, yhteisesti sovitelluilla käytännöillä. Prosessitaso määrittelee myös viitekehyksen, joka on oltava muodostettuna ennen kuin voidaan tavoitella tehokasta tietojärjestelmää.\n17 17 Prosessitaso määrittelee tietojärjestelmäprojektin hallintaan tarvittavan perustason. Perusprosessitason ideana on helpottaa rutiineja yhteisillä käytännöillä, jolloin resursseja jää enemmän itse työhön. Perustason tietojärjestelmähankinnan hallintaan Pressman luettelee muun muassa dokumentaation (lomakkeet ja raportit) sekä tarkastuspisteet (milestones). Menetelminä Pressman esittää kommunikaation, vaatimusmäärittelyn, suunnittelun, järjestelmän rakenteen, testauksen ja tuen. Työkalutaso tarjoaa tietokoneavusteisia menetelmiä tukemaan tietojärjestelmän kehittämistä. (Pressman, 2005: ) Pressmanin esittämä tasoajattelu on pohja monille prosessimalleille. Useimmat prosessimallit pitävät sisällään Pressmanin luettelemia elementtejä. Pressmanin esittämä rakenne on yksinkertainen, mutta sen tarkoitus ei ole olla prosessimalli jota käytetään, vaan yleinen ohjeistus prosessimallien rakenteesta. (Pressman, 2005: ) Erilaisia prosessimalleja on useita, joista tunnetuimpana ja muiden prosessimallien lähtökohtana pidetään jo mainittua vesiputousmallia. Vesiputousmallin pohjalta on kehitetty erilaisia prosessimalleja, kuten spiraalimalli (McConnell 2002: ), prototyyppimalli (McConnell 2002: ; Pressman 2005), Unified Process (Pressman 2005: ; Haikala ja Märijärvi 2006: 45-46) sekä ns. ketterien menetelmien prosessimallit: extreme programming (Pressman 2005: ) ja agile (Pressman 2005: ) Mainituista prosessimalleista tässä tutkimuksessa esitellään vesiputousmalli ja spiraalimalli, koska ne ovat yleisimmät käytössä olevat ja niitä käytetty Tiehallinnossa. Prosessimalleja on luotu eri tarkoituksiin ja olemassa olevia projektimalleja on muokattu pienin muutoksin sopimaan eri tarkoituksiin Vesiputousmalli Vesiputousmalli (Waterfall model) myös lineaarisena mallina tunnettu prosessimalli on todennäköisesti vanhin tietojärjestelmien kehittämiseen suunnattu prosessimalli. Vesiputousmallia käsitteli Royce W.W luvulla kirjoituksessaan Managing the Development of Large Software Systems. (Haikala ja Märijärvi, 2006: 25.)\n18 18 Roycen vesiputousmalli perustuu Beningtonin jo 1950-luvulla esittämään yhdeksänvaiheiseen prosessimalliin, mutta Roycen seitsemänportainen malli vakiintui käyttöön. (Madhavji, 1991.) Vesiputousmallia pidetään yhtenä yleisimmistä tietojärjestelmähankkeen prosessimalleista. (McConnell, 2002: ) Malli on rakenteeltaan jaettu vaiheisiin kuvan 2 mukaisesti, jotka on helppo nähdä omina kokonaisuuksina. Jokaisen vaiheen on tarkoitus tuottaa seuraavalle vaiheelle alkutiedot ja pohja josta edetä. Royce esitti 1970-luvulla julkaistussa kirjoituksessa seuraavanlaisen vesiputousmallin rakenteen. Järjestelmävaatimukset Sovellusvaatimukset Analysointi Suunnittelu Ohjelmointi Testaus Operaatiot Kuva 2: Vesiputousmalli (Royce, 1970). Vesiputousmallin rakennetta esitellään monessa alan julkaisussa kutakuinkin samanlaisena, jollaisena Royce sen esitti 1970-luvulla. (McConnell, 2002: ; Pressman, 2006.) Usein vesiputousmalli kuvataan suoraviivaisesti eteneväksi malliksi, jossa edellisiin välivaiheisiin ei ole palaamista. Royce itse ehdotti lanseeratessaan vesiputousmallia, että malliin olisi hyvä soveltaa feedback loop -ajattelua, joka mahdollistaisi edellisen vaiheen tarkastelun ja siihen palaamisen, vaikka edellinen vaihe olisi viety päätökseen. (Royce, 1970; Pressman, 2005:79-86.) Vesiputousmallia onkin kritisoitu sen kankeuden takia. Vesiputousmallin mukaisesti etenevä tietojärjestelmähankinta, joutuu sitoutumaan hankinnan alkuvaiheissa ratkaisuihin, joiden toimivuudesta ei välttämättä ole varmaa tietoa. Vesiputousmallin mukaisesti järjestelmä-, sovellus- ja käyttäjävaatimukset vaaditaan hankinnan alussa, mikä ei sinällään ole ongelma, mutta harvemmin esimerkiksi käyttäjät tietävät tarkkaan mitä he haluavat. Tästä voi aiheutua ongelmia siinä vaiheessa, kun käyttäjät saavat sovelluksen ensimmäistä kertaa testattavaksi.\n19 19 Vesiputousmallin mukaisesti etenevässä tietojärjestelmähankkeessa ei kovin helposti voi palata takaisin alkuun ja suunnitella toisenlaista ratkaisua. Yrityksessä, joka ulkoistaa ICT-teknologian ja ICT-palvelut, vesiputousmalli voi toimia hyvin, mutta vain sillä ehdolla, että vaatimusmäärittely ja suunnittelu on tehty hyvin. Usein kuitenkin ICTalaa koskevissa artikkeleissa ja kirjallisuudessa on moitittu sitä, että tarpeeksi täydellisen vaatimusmäärittelyn tekemiseen menee paljon aikaa ja resursseja. Tämä aiheuttaa usein sen, että projektit etenevät vajaalla vaatimusmäärittelyllä, jota yritetään paikata toteutusvaiheessa, silloin kustannukset ja aikataulut usein pettävät. (Pressman, 2005: 79 80; Sommerville, 2001: 45 46; Pfleeger, 2001: ) Spiraali- eli iteratiivinen malli Spiraalimalli on Barry Boehmin 1980-luvulla määrittelemä malli tietojärjestelmän kehittämiseen ja parantamiseen. (Pressman, 2005: 86.) Vuonna 1986 julkaistussa artikkelissaan Boehm kuvaa spiraalimallin syntyä ja sen toimintaa. Boehmin spiraalimallin pohjana on vesiputousmalli ja Millsin vuonna 1971 esittelemä top-downmenetelmä. Menetelmän perusideana on huolellinen suunnitteleminen ja järjestelmän täydellinen ymmärtäminen, jolloin koodin kirjoittamista ei aloiteta, ennen kuin on selkeä kuva siitä mihin hankinnalla pyritään. Boehm seurasi vesiputousmallin kehittämistä, mutta tuli siihen tulokseen, että kaikkia ongelmia ei saatu karsittua vesiputousmallista. (Boehm, 1986: 23.) Vesiputousmallissa edelleen olevien ongelmien takia Boehm suunnitteli spiraalimallin, jonka tarkoituksena oli edetä tietojärjestelmän kehityksessä syklein. Jokainen sykli noudattaisi samoja vaiheita. Käytännössä seuraava sykli tarkastaa aiemman syklin tulokset, analysoi ne ja analyysin pohjalta tehdään suunnitelman joka toteutetaan. Boehmin spiraalimalli on tietojärjestelmien kehittämisessä ainutlaatuinen. Sitä on parannettu myöhemmin, mutta pääpiirteittäin spiraalimaista kehittämistä noudattavat menetelmät pohjautuvat vuonna 1986 esiteltyyn malliin. Teollisuudessa vastaavanlainen kehitysmenetelmä on ollut käytössä pitkään. Walter Stewhart työskenteli luvulla Bellin laboratoriossa ja kehitti PDCA (Plan, Do, Check, Act) ympyrän. Tunnetuksi PDCA:n teki Edwards Deming 1950-luvulla, siitä lähtien menetelmää on usein kutsuttu Demingin ympyräksi.\n20 20 Teollisuudessa tunnettu Six Sigma -laatujohtamisen työkalu käyttää PDCA:sta kehiteltyä versiota DMAIC (Define, Measure, Analyze, Improve, Control).(Brockman, 1997.) Spiraalimainen kehittäminen ei kuitenkaan ollut yleistynyt tietojärjestelmien kehittämisessä ennen Boehmin esittelemää mallia. Käytännössä Boehmin spiraalimalli toimii kuten PDCA, jolloin jokainen kierros pitää sisällään PDCA-kierroksen. Spiraalimalli etenee käytännössä evoluutioversioiden avulla, jossa ensimmäiset versiot voivat olla paperiversiota kuvan kolme mukaisesti. Versioiden käyttäminen auttaa projektiryhmää ymmärtämään mistä on kyse. Kun yhteinen ymmärrys on syntynyt, voidaan siirtyä eteenpäin ja aloittaa ohjelmointi. Suunnittelu Kommunikointi Mallintaminen analyysi 1.0 Käyttöönotto / Palaute 2.0 x.0 = Prototyypit = Riskien arviointi 3.0 Toteutus Kuva 3: Spiraalimallin rakenne, mukailtu (Pressman, 2005: 87 ja Boehm, 1986: 25). Boehmin mukaan spiraalimallin etu verrattuna perinteiseen vesiputousmalliin on sen sykleittäin etenevä toteuttaminen, jossa riskejä arvioidaan jokaisen syklin jälkeen. (Boehm, 1986.) Pressman tukee Boehmin väitettä ja kirjoittaa: Yksi spiraalimallin tärkeimmistä eduista on se, että kustannusten noustessa riskit vähenevät. (Pressman, 2005: 143.)\n21 21 Pressman perustelee väitettä sillä, että mitä enemmän riskejä saadaan kartoitettua alussa ja etenekin eliminoitua, sitä vähemmän niitä tulee projektin loppuvaiheessa vastaan. Lopussa esiintyvät ongelmat voivat moninkertaistaa hankinnan budjetin, siksi alkuvaiheessa lisätty panos riskien kartoittamiseen maksaisi itsensä takaisin. Boehmin alkuperäinen spiraali oli jaettu neljään osa-alueeseen. Käytännössä osa-alueita oli viisi, koska prototyypin luominen jakaantui kahdelle eri osa-alueelle. Pressman on jakanut spiraalin viiteen osaan. (Pressman, 2005: 143.) Spiraalimallin mukaisesti etenevässä tietojärjestelmähankkeessa vaatimusmäärittelyn tekeminen on vesiputousmallin tapaan erittäin tärkeää. Spiraalimallin suurin ero vesiputousmalliin tulee toteutus- ja testausvaiheessa. Mallin mukaisesti tilaajalle tuodaan mahdollisimman aikaisessa vaiheessa nähtäville jotain konkreettista, koska yleisesti tietojärjestelmähankkeissa ongelmaksi on koettu tietojärjestelmän näkymättömyys ennen viimeisiä testauksia, juuri ennen käyttöönottoa. Spiraalimallin haasteellisuus piilee sitoutumisessa. Spiraalimalli vaatii tilaajaosapuolen läsnäoloa tietojärjestelmän kehittämisessä aina alusta loppuun asti. Tilaajaosapuolen tulisi pystyä vastaamaan toimittajan pyytämiin välitestauksiin ja niiden arvioimiseen, jonka perusteella toimittaja lähtee suorittamaan seuraavaa sykliä. Sitoutumista kaivataan erityisesti testaajilta, joilla on kokemusta kohdealueesta, johon tietojärjestelmää ollaan hankkimassa. (Pfleeger, 2001: 58; Sommerville, 2001: 53-56; Pressman, 2005: ) Mallinnuskieli Nykyaikaiset tietojärjestelmät ovat monimutkaisia, laajoja ja useasti niin sidoksissa muihin tietojärjestelmiin, että kokonaisuutta ei voi hallita ilman dokumentointia. Työhön vaaditaan työkalu, joka auttaa hallitsemaan suuria ja monimutkaisia kokonaisuuksia. Robillard esittää, että tietojärjestelmäprojekti koostuu kolmesta osatekijästä kokeneesta työryhmästä, ryhmää tukevista työkaluista sekä tietojärjestelmän mallintamiskielestä.\n22 luvulla kehitetty UML-mallinnus (Unified Modeling Language) on yksi tunnetuimmista mallinnuskielistä. (Nordström ja Cegrell, 2005.) Yhteisen mallinnuskielen ideana on tarjota helpompi ja rakenteellisempi tapa ymmärtää tietojärjestelmän rakenne kuin tutkia sitä valmiista sovelluskoodista. Mallinnuskielen avulla voidaan tietojärjestelmän eri osa-alueet kuvata helposti ymmärrettävään graafiseen muotoon. Erityisesti ICT-toimintojaan ulkoistavissa yrityksissä mallinnuskieli voi auttaa alkutilanteen hahmottamista eri osapuolille, koska ulkoistamisen voi hoitaa henkilö, joka ei välttämättä ole samassa maassa, eikä puhu samaa kieltä. (Robillard et al., 2003: ) UML-mallinnuskieli noudattaa tiettyä notaatiota, jossa tietty symboli tarkoittaa tiettyä asiaa ja objektien (esimerkiksi sovelluksen osa tai henkilö) välillä olevat suhteet riippuvat tehtävistä (lähettäjä - vastaanottaja). Esimerkiksi käyttäjä tai muu luonnollinen henkilö on kuvattu selkeästi ihmistä muistuttavalla objektilla, jolloin mallia tarkasteleva henkilö saa nopeasti käsityksen siitä keneen tietty ohjelman osa vaikuttaa. Tietojärjestelmää kuvaavia kaaviotyyppejä on useita. UML-kaavioita on kolmetoista erilaista ja ne on jaettu ryhmiin: käyttäytymis-, vuorovaikutus- ja rakennekaavioihin. Näistä käytetyimpiä ovat käyttötapaus- ja luokkakaavio. (Fowler, 2000: 1-9.) Robillardin mukaan ensimmäinen kaavio tulisi tehdä käyttötapauksista (use-case), joita tulevalta tietojärjestelmältä odotetaan. Myös Lunn tukee Robillardin esitystä. (Lunn, 2003.) Tällöin projektissa mukana olevien on helpompi ymmärtää se kokonaisuus, jonka kanssa ollaan työskentelemässä. Käyttötapauskuvaukset voivat tietojärjestelmähankinnan alkuvaiheessa toimia mindmappeina, joiden avulla voidaan kartoittaa mahdolliset henkilöriippuvuudet (käyttäjä, päivittäjä, järjestelmävastaava ja omistaja). (Robillard et al., 2003: ) Luokkakaavio kuvaa tietojärjestelmän eri toimintojen riippuvuuksia toisiinsa. Luokkakaavioiden tuoma etu on havaittavissa erityisesti hajautetuissa järjestelmissä, joissa tietojärjestelmä rakentuu pienemmistä itsenäisistä sovelluksista.\n23 23 Luokkakaavioissa kuvataan mitä sovellus tekee karkealla tasolla. Luokkakaaviot ovat suoraan liitoksissa komponenttikaavioihin, jotka kokoavat luokat isoimmiksi kokonaisuuksiksi. (Chang, 2001: ) Robillard jakaa aika- ja tapahtumakaaviot eri kaavioihin, aikakaaviossa kuvataan vaiheittain mitä tapahtuu siitä kun käyttäjä ensimmäisen kerran antaa syötteen järjestelmälle. Kaavioon kuvataan tapahtumat aikajanalle, joka päättyy siihen kun käyttäjä lopettaa järjestelmän käyttämisen ja automatisoidut toiminnot ovat loppuneet käyttäjän session osalta. (Robillard et al., 2003: ) Tilakaaviossa Robillardin mukaan tulee kuvata järjestelmän tila tietyissä käyttövaiheissa. Esimerkiksi, kun käyttäjä antaa käyttäjätunnuksen, tulee tilakaaviossa kuvata tapahtumat, jotka seuraa sitä kun käyttäjä antanut syötteen Henkilöstöresurssit osana palvelunhankintaa Ilman osaavia henkilöstöresursseja ei prosessimalleilla saavuteta haluttuja tuloksia. Ihmiset ovat sovelluskehityksessä ja tietojärjestelmien hankintaprojekteissa pääroolissa. (Phillips, 2000: 13-14; Reel, 1999: 20.) Phillipsin mukaan on tärkeää, että ihmiset eli projektiryhmä tietää, mitä ollaan tekemässä. Yleinen käsitys päämäärästä ja sitä rajaavista tekijöistä on tietojärjestelmähankinnan kannalta tärkeää. Phillips esittää kirjassaan The Software Project Manager s Handbook ajattelumallin nimeltä 3P. (Phillips, 2000: 13.) 3P tulee englanninkielisistä sanoista People (ihmiset), Process (prosessi) ja Product (tuote). Tietojärjestelmän hankintaprojekti on tasapainottelua näiden kolmen eri elementin välillä. Kaikki lähtee kuitenkin ihmisistä, projektin henkilöstöresursseista. Riippumatta tuotteesta tai käytettävästä prosessimallista, ihmisen rooli projektissa on kriittinen. Projektiryhmä voi muuttua ja tuote eli projektin päämäärä voi muuttua kun aloitetaan uusi hankintaprojekti, mutta prosessimallit pysyvät.\n24 24 Tällä Phillips tarkoittaa sitä, että prosessimalli on valittava sen mukaan, minkälainen projektiryhmä ja mikä on sen tavoite. Sommerville tukee Phillipsin 3P ajattelumallia kirjassaan Software Engineering. (Sommerville, 2001: 490.) Myös Sommervillen mukaan organisaatiossa työskentelevät ihmiset ovat tietojärjestelmäprojektin kannalta sen tärkein voimavara. (Sommerville, 2001: 490.) Sommerville esittää yleiseksi säännöksi projektiryhmän koosta maksimissaan kahdeksan henkeä. Hän perustelee sääntöä sillä, että projektiryhmän henkilömäärän ollessa noin kahdeksan pystyy projekti keskustelemaan hankinnasta helposti, koska projektiryhmän saaminen koolle on aina ongelma, joka vain korostuu mitä enemmän henkilöitä on projektissa mukana. Samalla tarve monimutkaiselle viestintämekanismille vähenee. (Sommerville, 2001: 490.) Rajattaessa projektiryhmän kokoa, ryhmän jäsenten taidot ja yhteistyökyky nousevat esille. Pieni projektiryhmä pystyy siis kommunikoimaan paremmin. Hyvä kommunikaatio, jonka pieni projektiryhmä mahdollistaa, ei välttämättä takaa sitä, että projekti onnistuu. Sommervillen mukaan projektiin tulisi valita sellaisia ihmisiä, jotka kykenevät saavuttamaan halutun päämäärän. Pfleeger esittää kirjassaan Software Engineering kuinka paljon lisäkommunikointia yksi lisättävä projektijäsen aiheuttaa. Sommervillen kahdeksan projektihenkilön säännöllä projektiryhmän kommunikaatiolinjojen eli eri projektijäsenten välisten kommunikaatioiden määrä on 28 kappaletta. (Sommerville, 2001: 490; Pfleeger, 2001.) Projektipäällikön merkitys Projektipäällikön rooli tietojärjestelmän hankintaprosessissa on tärkeä. Projektipäällikön vastuulla on ohjata projektia niin teknisessä mielessä kuin myös hallinnollisessa mielessä. Projektipäällikön on oltava tietoinen siitä mitä on meneillään ja kenen vastuulla mikäkin projektin osa on. Usein projektiin nimetty projektipäällikkö ei kuitenkaan ole tekniseltä taustaltaan yhtä pätevä, kuin projektin tekninen asiantuntija, jolloin roolit saattavat muuttua ilman päätöstä. Sommervillen ehdotus on, että projektissa on yhden projektipäällikön sijaan kaksi projektipäällikköä. Kahden projektipäällikön ajatus perustuu Sommervillen mukaan siihen, että tehtävät jaoteltaisiin niin, että projektissa on tekninen sekä hallinnollinen projektipäällikkö. (Sommerville, 2001: 498.)\n25 25 Henkilöt, jotka ovat teknisesti päteviä, eivät välttämättä ole aina päteviä johtamaan koko projektia. Kyse on kuitenkin henkilöstöresursseista, tekninen tausta ei pois lue johtamiskykyjä eikä hallinnollinen tausta pois lue teknistä ymmärtämistä. Sommerville luettelee yleisiä ominaisuuksia joita projektipäälliköllä olisi hyvä olla. Näihin kuuluvat yhteistyökyky kaikkien kanssa riippumatta henkilöiden taustoista sekä tasa-arvoisuus. Tiedon jakaminen voi joissakin tilanteissa olla vaikeaa, koska esimerkiksi tämän tutkimuksen kohteena olevassa Tiehallinnossa on monitoimittajaympäristö. Se tarkoittaa käytännössä sitä, että riippumatta projektista, mukana on tilaajan ja toimittajan lisäksi ainakin käyttöpalvelutoimittaja. (Sommerville, 2001: 498.) Projektia koskevat muut dokumentit tulisi olla helposti esillä kaikille projektin jäsenille, jolloin tiedonkulku ja tavoitteiden ymmärtäminen olisi helpompaa. Tiedon jakamisella on myös vaikutus projektihenkilöihin. Jos projektissa mukana olevat henkilöt eivät saa tarvittavia tietoa, voi heidän motivaationsa laskea. Projektipäällikön tehtävänä on huolehtia siitä, että projektiin osallistuvat henkilöt ovat ajan tasalla. (Sommerville, 2001: ; Pfleeger, 2001: ) Asiakas Asiakkaalla tarkoitetaan tietojärjestelmän hankintaprosessissa sitä tahoa, joka tilaa tietojärjestelmän. Asiakas ei aina toimi projektipäällikkönä, projektipäälliköksi voidaan valita henkilö liiketoiminnan ulkopuolelta. Asiakas ei myöskään välttämättä ole hankinnan kohteena olevan tietojärjestelmän loppukäyttäjä. Asiakkaan tehtävänä on tavoitteiden esittäminen. Tavoitteista keskustellaan hankintaa suorittavan projektipäällikön kanssa. Yhteisen tavoitekuvan muodostaminen on tärkeää. Tavoitekuvaan asiakas tuo pääsääntöisesti liiketoiminnan tavoitteen ja vaatimukset. (Pfleeger, 2001: 15.) Käyttäjä Käyttäjän mielipiteiden ja tarpeiden merkitys hankintaprosessissa on suuri. Käyttäjä on se taho, jolle tietojärjestelmä tehdään. Käyttäjä ei välttämä tilaa itse tietojärjestelmää, mutta tulee käyttämään sitä työnteossa.\n26 26 Erityisesti graafisen käyttöliittymän suunnitteluun tulisi käyttäjä ottaa mukaan. Tietojärjestelmän suunnittelijat, projektipäälliköt ja liiketoiminnan asiantuntijat, eivät yleensä ole tulevia käyttäjiä, jolloin käyttäjän (myös tunnettu loppukäyttäjänä) mielipidettä tulisi kuunnella. (Sommerville, 2001: 188.) Täysin uutta tietojärjestelmää suunniteltaessa prototyypin tekeminen loppukäyttäjälle on hyvä tapa aloittaa tietojärjestelmän käyttöliittymän suunnittelu. (Sommerville, 2001: 189.) Käyttäjän voi olla vaikea määrittää vaatimuksia tietojärjestelmälle, jos ei ole käytettävissä mallikäyttöliittymää. Suunnittelun voi aloittaa hyvin yksinkertaisella paperiversiolla. Käyttäjän osallistuminen tietojärjestelmän suunnitteluun auttaa häntä omaksumaan järjestelmä. Käyttäjän osallistuminen vaikuttaa myös siihen kuinka hyvin lopullinen tietojärjestelmä otetaan käyttöön. Käyttäjän kokee tietojärjestelmän paremmin omakseen, jos hän on saanut olla mukana suunnitella sitä. Suunnittelussa mukana ollut käyttäjä todennäköisesti aloittaa tietojärjestelmän käytön huomattavasti helpommin, kuin sellainen käyttäjä, jolla ei ole ollut vaikuttamassa tietojärjestelmään. (Phillips, 2000: 197; Xiaochun ja Yuanchun, 2008.) Tietojärjestelmän suunnittelijan on kuitenkin oltava varovainen antaessaan käyttäjän vaikuttaa tietojärjestelmän suunnitteluun. Suunnittelijan tulee selvittää käyttäjälle tarkoin mitä sovelluksella tavoitellaan, erityisesti jos hankittava tietojärjestelmä on uusi. Käyttäjän vapautta on rajoitettava sen verran, että käyttäjä pääsee suunnittelemaan perustoimintoja ja karkealla tasolla graafista ulkoasua, mutta mitä näiden toimintojen taustalla tapahtuu, tulee jättää asiantuntijoiden ratkaistaviksi. (Phillips, 2000: 197; Xiaochun ja Yuanchun, 2008.) Käyttöpalvelutoimittaja Käyttöpalvelutoimittajan roolia ei ole tämän tutkimuksen taustamateriaalissa käsitelty tarkkaan. Usein käyttöpalvelutoimittajan rooli on yhdistetty sidosryhmään. Tiehallinto toiminnassa käyttöpalvelutoimittajan rooli on suuri.\n27 27 Tiehallinto työasemat, palvelimet ja muu tietotekniikkaan liittyvä toteutus on kilpailuttamisen kautta valitun käyttöpalvelutoimittajan omistamaa, jonka Tiehallinto hankkii käytettäväksi tietyksi sopimusajaksi. Käyttöpalvelutoimittajan rooli hankintaprosessi on ilmeinen varsinkin silloin kuin hankittava tietojärjestelmä sijoitetaan toimimaan Tiehallinnon palvelinalustalle. Käyttöpalvelutoimittaja vastaa tällöin asennusvaiheesta ja sopimuksista riippuen se myös avustaa testiympäristön pystyttämisessä ja tietoliikenneratkaisuissa Työvaiheet Hankintaprosessin viitekehys rakentuu eri elementeistä. Työvaiheet ovat joukko elementtejä, jotka esiintyvät hankintaprosessissa riippumatta käytettävästä prosessimallista. Seuraavaksi kyseiset elementit käsitellään yksitellen. Kilpailutus kuuluu erityisesti julkishallinnon hankintaprosessiin, jota ei yleensä käsitellä tietojärjestelmäkehitystä koskevissa teoksissa Vaatimusmäärittely Vaatimusmäärittelyn rooli tietojärjestelmäprojektin kannalta on erityisen suuri. Tutkimusten mukaan % loppuunsaatetuista tietojärjestelmistä ei vastaa täysin käyttäjävaatimuksia. (Bowles, 2006.) Syyksi Bowles esittää vaatimusmäärittelyn. Tietojärjestelmien kehittämiseen on tarjolla erilaisia prosessimalleja. Prosessimalleja on kehitetty erilaisiin tietojärjestelmäkehitystarpeisiin. Riippumatta prosessimallista (esimerkiksi vesiputousmalli tai spiraalimalli) mallit sisältävät yhteneviä elementtejä kuten esimerkiksi vaatimusmäärittelyn. Standish yhtiön 1990-luvun puolivälissä suorittaman CHAOS-tutkimuksen mukaan hieman yli 30 % kaikista tietojärjestelmähankkeista lopetetaan ennen kuin ne valmistuvat. Yleisimpänä syynä on puutteellinen vaatimusmäärittely, seuraavaksi yleisimpänä Chaos-tutkimuksen mukaan on puutteellinen käyttäjän osallistuminen ja kolmantena puutteelliset resurssit (aika, budjetti). (Boehm, 2000.)\n28 28 Vaatimusmäärittelyn tulisi koota kaikki tietojärjestelmän vaatimukset, mutta todellisuudessa tämä ei ole mahdollista. (Sommerville, 2001: 98.) Sommerville ryhmittää vaatimukset kolmeen ryhmään käyttäjävaatimukset, järjestelmävaatimukset ja tietojärjestelmän suunnittelun vaatimukset. Pfleeger esittää myös ryhmittelyn vaatimuksille, mutta eri näkökulmasta. Pfleeger ryhmittää tietojärjestelmän vaatimukset myös kolmeen eri ryhmään, jotka on luokiteltu sen mukaan mikä kyseisen vaatimuksen vaikutus on tietojärjestelmälle. Ensimmäiseen vaatimusryhmään luokitellaan ne vaatimukset, jotka on täytyttävä, jotta tietojärjestelmä olisi onnistunut. Toiseen tulevat ne vaatimukset, jotka ovat suotavia, mutta eivät välttämättömiä. Viimeisessä ryhmässä on vaatimukset, jotka voidaan toteuttaa, mutta ne voidaan myös yhtä hyvin jättää pois. Vaatimusmäärittelyn vaikutus tuli esille myös vuonna 1995 Standish yhtiön teettämässä tutkimuksessa, joka koski tietojärjestelmien kehittämistä. Tutkimuksessa keskityttiin asioihin, jotka vaikuttavat tietojärjestelmän onnistumiseen. (Bowles, 2006: 110; Boehm, 2000.) Tutkimuksessa käsiteltiin yli 350 eri yritystä ja niiden yli 8000 tietojärjestelmähanketta. Tutkimuksessa tietojärjestelmistä noin 31 prosenttia lopetettiin ennen kuin ne ehtivät valmistua. Vain yhdeksän prosenttia tietojärjestelmistä toimitettiin ajallaan ja budjetin pysyessä asetetuissa summissa. Suurimmaksi syyksi tietojärjestelmien epäonnistumiseen tutkimuksen mukaan oli epätäydellinen vaatimusmäärittely. (Pfleeger, 2000: 137.) McConnell esittää kirjassaan Rapid Development taulukon, jossa kuvataan tietojärjestelmähankkeen osa-alueiden kokonaisuudet prosentteina kokonaistyömäärästä. Hän esittää kaksi erisuuruista projektia, joista pienempi on 2500 koodiriviä ja suurempi koodiriviä. Pienemmässä projektissa painopiste on jakautunut suhteellisen tasaisesti, painopiste on ohjelmoinnissa. Isossa projektissa painopiste on selkeästi havaittavissa, sen ollen alussa eli arkkitehtuurin ja yksityiskohtien suunnittelussa. (McConnell, 2002: )\n29 29 McConnellin mukaan alkuvaiheen suunnittelutoimintoja ei pidä leikata siinä toivossa, että tietojärjestelmähanke toteutettaisiin halvemmalla. McConnellin mukaan leikkaukset suunnitteluvaiheesta tulevat maksamaan moninkertaisesti tietojärjestelmän toteutus- ja testausvaiheessa. Hän esittää, että suunnitteluvaiheessa käytetty 1,5 tuntia suunnitteluvian ratkaisemiseen, moninkertaistuu vähintään kahteen päivään, jos virhe havaitaan vasta järjestelmätestauksessa. (McConnel, 2002: ) Boehm ja Papaccio arvioivat artikkelissaan Understanding and control software costs, että tietojärjestelmässä esiintyvän virheen korjaaminen hankkeen alkuvaiheessa on kertaa halvempaa, kuin jos se korjataan tietojärjestelmän elinkaareen myöhäisemmissä vaiheissa. (Boehm ja Papaccio, 1988: 1466.) Phillips ehdottaa vaatimusmäärittelyn pohjaksi mindmap-menetelmää, jossa hankinnan kohdetta tarkasteltaisiin mindmap-menetelmää käyttäen. Menetelmässä ideana on, että hankintaprojektiryhmä kerää hankinnan ympärille asioita, jotka heidän mielestään on liitoksissa hankintaan tai saattavat vaikuttaa siihen muulla tavalla. (Phillips, 2000: 94.) Use case- eli käyttötapauskaaviota on käsitelty Maciazekin kirjassa Requirements Analysis and System Design, joka keskittyy pääsääntöisesti tietojärjestelmän vaatimusmäärittelyyn ja suunnitteluun. Käyttäjän näkemys siitä, miten ohjelman tulisi toimia, on tärkeä, koska käyttäjä työskentelee valmiin tuotteen kanssa. Ongelmaksi muodostuu tilanne, jossa kehitetään täysin uutta tietojärjestelmää, jota ei ole vielä tehty. Vanhan tietojärjestelmän kehittäminen tai vastaavanlaisen rakentaminen alusta alkaen on käyttäjälle helpompi tilanne. Käyttäjä pystyy muodostamaan kuvan toiminnoista, jotka ovat toimineet aiemmassa tietojärjestelmässä hyvin ja toisaalta taas käyttäjä pystyy muodostamaan kuvan huonoista toiminnoista. Käyttäjän toimintamallia on hyvä kuvata käyttötapauskaavioina. (Maciazek, 2005: )\n30 30 Pfleeger esittää vaatimusmäärittelyn koostuvan yhdeksästä eri osa-alueesta, joita kuvataan kuvassa 4. Jokainen osa-alue sisältää Pfleegerin kirjassa joukon tarkentavia kysymyksiä, joiden avulla pyritään selvittämään osa-alueeseen vaikuttavia tekijöitä. Tietojärjestelmän fyysinen ympäristö Data/Tieto Dokumentaatio Rajapinnat Resurssit Montako järjestelmää lähettää tietoa? Vaatimustyypit Toiminnallisuus Laatu Onko tulevalle tai lähtevälle tiedolle määritetty formaatti? Turvallisuus Käyttäjä- ja ihmistekijät Kuva 4: Vaatimusmäärittelyn eri osa-alueet Pfleegerin mukaan, (Pfleeger, 2001: ) Maciazek jaottelee vaatimukset kahteen pääryhmään, toiminnallisiin ja ei toiminnallisiin vaatimuksiin. Toiminnalliset vaatimukset ovat hankittavan tietojärjestelmän omistajan ja sen loppukäyttäjän määrittelemiä toiminnallisia vaatimuksia hankinnalle. Eitoiminnallisiksi vaatimuksiksi Maciazek luettelee käytettävyyden, uudelleenkäytön, toimintavarmuuden, suorituskyvyn, tehokkuuden, tuen mahdollisuuden ja muut rajoitteet. (Maciazek, 2005: ) Riskianalyysi Pressman sekä Sommerville mainitsevat yhdeksi tärkeimmäksi osa-alueeksi hankintaprosessissa riskianalyysin, jossa tarkastellaan hankittavaan tietojärjestelmään liittyviä riskejä. Mahdollisiksi riskeiksi molemmat listaavat hankinnan kohteena olevan tuotteen koon, työryhmän ja teknologian. Myöhäisessä vaiheessa havaitut riskit voivat olla kokoluokaltaan niin suuria, että saattavat olla vaaraksi koko hankkeelle. Tästä syystä riskianalyysin tulisi olla osa vaatimusmäärittelyä, jossa käytäisiin läpi jokainen vaatimus. (Pressman, 2005: ; Sommerville, 2001: )\n31 31 Ensimmäisenä tehtävänä riskianalyysissa on selvittää eri riskiryhmät, joita on teknologia-, henkilöstö-, organisaatio-, työkalu- ja tavoiteriskit. (Sommerville, 2001: 86.) Sommerville pohjaa lajittelua Boehmin 1980-luvun lopulla julkaisemaan Software Risk Management -artikkeliin, jossa Boehm ottaa kantaa tietojärjestelmähankkeiden riskeihin. Erityisesti Boehm painottaa riskien tunnistamista. (Boehm, 1991.) Boehmin mielestä projektissa tulisi määrittää kymmenen suurinta riskiä. Sommerville ehdottaa, että määritettävien riskien määrä tulisi riippua hankintaprojektin koosta. Sommerville perustelee väitteen sillä, että riskien lukumäärä voi aiheuttaa hankinnan laajuuden ja vaikuttavuuden kannalta liian suuren työmäärän. Riskienlukumäärä tulisi sovittaa hankinnan kokoon. Tunnistaminen Riskien arviointi Analysointi Priorisointi Riskianalyysi Hallintasuunnitelma Riskien hallinta Ratkaisu Seuranta Kuva 5: Tietojärjestelmähankinnan riskienhallinta, mukailtu (Boehm, 1991). Kuvassa viisi on mukailtu Boehmin esittämää rakennetta riskienhallinnalle. Sama rakenne löytyy mukailtuna mm. Phillipsin kirjasta. (Phillips, 2000: 177.) Riskianalyysiä tehtäessä tulisi kiinnittää huomio kolmeen yleisimpään riskiin. Ne ovat hankinnan koosta riippumatta: informaation puute, kontrolli ja aika. Muita mahdollisia riskejä ovat häiriöt, henkilöstö ja projektin ympäristö. (Rook, 1989.) Phillips käyttää Boehmin esitystä pohjana ja soveltaa sen Phillipsin omaan 3P (People, Process, Product) ajattelumallin. Hän esittää, että riskienanalysoinnissa tulisi esittää kysymyksiä, jotka pyrkivät löytämään mahdollisia ongelmia jokaisesta 3P:n alueesta. (Phillips, 2000: 177.)\n32 32 Esimerkkinä kysymyksistä, joita Phillipsin mukaan tulisi esittää, on seuraavassa kysymys, joka on kohdistettu 3P:n ensimmäisen P:hen eli ihmisiin (people). "Mitä jos meidän toinen projektimme ei anna meille graafisia ohjelmoijia, jotka he lupasivat?" (Phillips, 2000:178.) Phillipsin menetelmää voisi kutsua skenaarioajatteluksi, jossa luodaan erilaisia skenaarioita siitä, mitä tehdään jos jokin ongelma esiintyy Kilpailutus ja sen vaikutus Entisen Tiehallinnon aikana voimaan tullut lainsäädäntö ICT-palveluiden ostamisesta viraston ulkopuoliselta toimittajalta toi mukanaan kilpailuttamiskäytännön. Kilpailuttaminen perustuu hankintalakiin, joka määrää valtion viraston kilpailuttamaan tietyn hintarajan ylittävät hankinnat. (Finlex, 2010a.) Kilpailuttaminen vaikuttaa tietojärjestelmähankintaan lisäämällä työvaiheen, jossa hankintaprojektin tulee määrittää vaatimukset toimittajalle, määritellä tarjouspyyntö, pisteyttää toimitetut tarjoukset ja tehdä toimittajavalinta. Tarjouspyynnön sisältö on hankinnan kannalta erittäin kriittinen, koska tarjoajat pyrkivät tarjoamaan ratkaisun, joka vastaa mahdollisimman tarkasti annettuja vaatimuksia. Tarjouspyynnön tulee sisältää hankintaan merkittävästi vaikuttavat rajaukset, poikkeukset ja vaatimukset. Tarjouspyynnöstä pois jääneet vaatimukset, mutta hankinnan kannalta elintärkeät vaatimukset aiheuttavat yleensä lisätöitä, joita ei ole budjetoitu hankintabudjetissa. Kilpailuttaminen on tapahduttava niin, että jokaiselle tarjoajalle tarjotaan tasa-arvoinen lähtötilanne hankintaan. Tarjouspyynnön lisäksi hankintaprojektiryhmä tarkastaa tarjoukset ja pisteyttää ne laskukaavalla, joka on annettu tiedoksi tarjoajille. Parhaimmat pisteet saanut tarjoaja saa mahdollisuuden allekirjoittaa sopimuksen Suunnittelu Suunnitteluvaihetta edeltää vaatimusmäärittely, joka määrittelee rakennettavan tietojärjestelmän. Suunnitteluvaiheen merkitys tietojärjestelmän kannalta on suuri. Nykyaikaisissa tietojärjestelmäympäristöissä tietojärjestelmät ovat kytkeytyneitä useisiin tietolähteisiin ja tietojärjestelmiin. Vaatimusmäärittely määrittelee mitä tietojärjestelmän tulisi tehdä. Suunnitteluvaiheen tarkoitus on suunnitella kuinka se voidaan toteuttaa.\n33 33 ICT-arkkitehtuurissa yleistynyt SOA (Service-Oriented Architecture) eli palvelukeskeinen arkkitehtuuri ohjaa tietojärjestelmiä enemmän moduuli- ja palvelupohjaiseen rakenteeseen. Palvelupohjainen arkkitehtuuri mahdollistaa optimitilassa uusien liiketoimintaa tukevien tietojärjestelmien rakentamisen nopeasti. Jotta organisaation SOA olisi optimaalinen, tulee jokaisen uuden tietojärjestelmän noudattaa SOAajattelumallia, jonka eroa perinteiseen tietojärjestelmään on kuvattu kuvassa 6. SOA luo haasteita niin tietoarkkitehtuurille, järjestelmäarkkitehtuurille kuin myös sovellusarkkitehtuurille. (Kuang-Yu, Shao-Chen, Ming-Tsung, 2008; Altman ja Manes, 2010.) Input: Käyttäjä Järjestelmä Y GUI Järjestelmä Z GUI Palvelin Järjestelmä X Järjestelmän osa 1 Järjestelmän osa 2 DB GUI Haku Muunnin Laskenta Koonti Tarkastus Koodi Palvelin Palvelin DB DB Palvelin Palvelin Palvelu Palvelu Integrointi Sisäinen/ ulkopuolinen Output: Käyttäjä Perinteinen SOA Kuva 6: Perinteinen tietojärjestelmän rakenne ja SOA, mukailtu (Kuan-YU et al., 2008). Gartnerin vuonna 2010 tekemissä tutkimuksissa on tutkittu SOA:n toimivuutta yrityksissä ja organisaatioissa. (Kung-Yu et al., 2008.) Tutkimuksia yhteen kokoavassa artikkelissa on poimittu löytöjä tutkimuksista. Palvelukeskeinen arkkitehtuuri ei ole vapauttava tekniikka, joka poistaa tietojärjestelmien kanssa koettuja ongelmia. Palveluarkkitehtuurin hyöty tulee esille silloin, kun tietojärjestelmä tarvitsee suoriutuakseen tehtävistään toisen tietojärjestelmän tietoja. Tietojen kopioimisen sijaan tietojärjestelmään luodaan palvelurajapinta, jonka kautta toinen tietojärjestelmä voi tehdä kyselyn.\n34 34 Suunnittelun merkitys kasvaa palvelukeskeisessä arkkitehtuurissa, koska tietojärjestelmä ei ole enää itsenäinen sovellus, vaan sen toiminta ei vaikuttaa muihin tietojärjestelmiin. Suunnittelussa on otettava huomioon palvelurajapinnat ja niitä hyödyntävät tietojärjestelmät. Gartnerin artikkelissa kehotetaan keskittymään tekniikan sijasta enemmän arkkitehtuurin ja siihen kuinka se rakennetaan. Suunnittelun tarkoitus on luoda palveluita, joita voivat muut tietojärjestelmät käyttää ja varmistaa, että käytössä olevat palvelut säilyvät muutoksen jälkeen. (Altman ja Manes, 2010.) Tieto-, järjestelmä- ja sovellusarkkitehtuurit on suunniteltava etukäteen huolellisesti. Etenkin hajautetuissa tietojärjestelmissä voidaan huonolla suunnittelulla saada aikaan monimutkaisia tietojärjestelmiä, joiden ylläpito voi olla työlästä. Esimerkkinä monimutkaisuudesta toimii kuva 7. Maciaszekin esittää hajautetun tietojärjestelmän rakenteen ilman sovelluskerroksia ja sovelluskerrosten kanssa. (Maciaszek, 2005: ) Maciazekin esimerkissä eri tasot voivat tarjota tietynlaisia palveluja, joita voidaan käyttää sellaisinaan tai rakentaa niiden päälle sovellus, joka yhdistää useampia tasoja ja toteuttaa halutun palvelun. A A G C G C B D B D F E F E 21 yhteyttä 42 reittiä 4 tasoa - 13 yhteyttä 26 reittiä Kuva 7: Vasemmalla ilman tasoja ja oikealla tasojen kanssa toteutettu tietojärjestelmä, Maciazek, 2005:\n35 35 Suunnitteluvaiheessa projektiryhmän tulee olla tietoisia siitä, mistä tietojärjestelmä saa tietoa ja tarjoaako se tietoa jollekin tietojärjestelmälle. Tietolähteitä varten on suunniteltava tietoliikenneyhteydet ja rajapinnat. (Maciazekin, 2005: ) Pressman, Sommerville ja Pfleeger jakavat suunnitteluvaiheen eri vastuualueisiin. Vastuualueiden tarkoitus on yksinkertaisesti se, että kukin alue keskittyy tiiviisti tietyn tietojärjestelmäosan suunnitteluun. Rakenteellisesti selkein jaottelu on Pressmanilla, kuva 8. (Pressman, 2001: 260.) Vastuualueet edistävät omaa suunnittelualuetta yhteistyössä muiden suunnittelualueiden kanssa. Komponentti Rajapinta Järjestelmä Tieto Kuva 8: Pressmanin näkemys suunnittelun vastuualueista. Mukailtu (Pressman, 2001: 260.) Pressman kuvaa suunnittelua kuvan 8 mukaisesti pyramidina, jonka perustana on tietoarkkitehtuuri. Tietoarkkitehtuurin tarkoituksena on kuvata tietojärjestelmän tiedot eri tasoilla. Tietoarkkitehtuuri on tietorakenne toteutettavalle tietojärjestelmälle. Tietoa voidaan saada eri rajapintojen kautta ulkopuolisista lähteistä, joten tietoarkkitehtuurin suunnittelussa joudutaan ottamaan myös sidokset huomioon. Mistä tieto tulee, kuinka usein tieto päivittyy, minkä tyyppistä tieto on, ovat kysymyksiä, jotka esiintyvät tietoarkkitehtuurin suunnittelussa. Kuvassa 9 on kuvattu käsitteeseen tie liittyviä käsitteitä ja niiden ominaisuuksia. Tiehen voi liittyä silta, jolla on rajoitus- ja leveysominaisuustieto. Samannimiset attribuutit löytyvät myös tiehen liittyvältä sillalta. Tietoarkkitehtuurin suunnittelussa tulee miettiä attribuuttien yhteyksiä, riippuvuuksia ja sijaintia.\n36 36 Tie Risteys Silta Tunneli Pysäkki Rajoitus Leveys Leveys Rajoitus Paino Korkeus Akseli Kokonais Kuva 9: Tietoarkkitehtuurin mallinnus, sovellettu Pressman, 2001: ja Tietojen luokittelu selventää tietoarkkitehtuurin rakennetta. Luokituksia voidaan tehdä eri tasoilla. Kuvan 9 tapauksessa tieoja voitaan voidaan luokitella niin, että luokat ovat risteys, silta, tunneli ja pysäkki. Luokkaa kuvaa joukko attribuutteja, tässä tapauksessa attribuutteina toimivat mm. rajoitus, korkeus ja paino. Suunnittelussa tulee miettiä tietojärjestelmän eri osien uudelleenkäyttö. Palvelukeskeisessä arkkitehtuurissa tietojärjestelmien tulee suunnitella rakenne niin, että sen tuottamia tietoja on mahdollista myös jakaa palvelurajapintojen kautta muille tietojärjestelmille. (Pressman, 2005: ) Vesiputousmallia noudatettaessa suunnitteluvaiheen tulee olla valmis kokonaisuus, jota ei tarvitse lähteä toteutusvaiheessa muuttamaan. Iteratiivisessa kehittämisessä suunnitteluvaiheita on useita ja ne saavat syötteen edellisen toteutuksen analysoinnista. Kuitenkin jo ennen ensimmäistä vaihetta iteratiivisessa kehittämisessä tulee keskittyä tietojärjestelmän suunnitteluun Toteutus Kun tietojärjestelmää varten on tehty kattava määrittely- ja suunnitteluvaihe voidaan aloittaa tietojärjestelmän toteuttaminen eli ohjelmointi. Tämä on erityisesti vesiputousmallin mukaisesti edistyvässä tietojärjestelmähankinnassa etenemisjärjestys. Myös iteroivaa menetelmää noudattava hankinta on määriteltävä ja suunniteltava ennen sen aloittamista. Erona näissä on se, että iteroivassa menetelmässä ohjelmoijat työstävät sovellusta palasina, eivätkä suoraan tähtää koko tietojärjestelmän rakentamiseen.\n37 37 Iteroiva menetelmä on haasteellinen tilaajalle, koska tilaajan on oltava kehittämisessä mukana testaajana ja hyväksyjänä, vesiputousmallia huomattavasti useammin. Harvoin toteutusta voidaan suorittaa niin, ettei mitään testattaisi ennen kuin koko tietojärjestelmä on rakennettu. Ohjelmoijat testaavat oman koodin toimintaa yleensä samalla kuin rakentavat sitä eteenpäin. Perusteellinen testaaminen tapahtuu vesiputousmallissa sitten vasta kun tietojärjestelmä on valmis, kun taas iteroivassa menetelmässä testausvaiheita on siis usein, mutta ne eivät ole kooltaan laajoja. Ulkoistetussa tietojärjestelmähankinnassa toteutus on käytännössä ensimmäinen ja ainoa työvaihe, joka tehdään ilman tilaajan osallistumista. Iteroivassa menetelmässä tilaaja on kuitenkin läsnä testausvaiheissa, mutta ohjelmointiin ei tilaaja ota osaa. Tällöin tilaajan on pystyttävä luottamaan siihen, että toimittajalla on käytössään osaavia ohjelmoijia, jotka ovat ymmärtäneet tietojärjestelmän tarkoituksen. (Pressman, 2005: ) Testaus Testaamisen tärkeys eri riipu siitä tehdäänkö tietojärjestelmä iteroimalla vai vesiputousmallin mukaisesti yhtenä suurena kokonaisuutena. Testaamisen tarkoitus on löytää tietojärjestelmästä mahdolliset virheet ennen kuin järjestelmä annetaan loppukäyttäjille käytettäväksi. Perusteellisesta suunnitelmasta ja vaatimusmäärittelystä huolimatta valmiiseen tietojärjestelmään on saattanut päätyä virheitä, jotka voivat johtua pelkästään inhimillisestä virheestä ohjelmoinnin aikana. Pfleeger on jakanut testaamiseen eri osa-alueisiin kuvan 10 mukaisesti. Osa-alueet ovat perusteltuja erityisesti suuren ja monimutkaisen tietojärjestelmän yhteydessä. Testaamisen suorittaminen siinä vaiheessa kun tietojärjestelmä on valmis voi muodostua vaikeaksi, koska mahdollista vikaa ei välttämättä saada paikallistettua suoraan tiettyyn kohtaan tietojärjestelmässä. (Pfleeger, 2001: 338.)\n38 38 Pfleegerin mukaan suuren tietojärjestelmän eri yksiköille tulisi suorittaa omat testitapahtumat ennen yksikköjen integraatiota ja sen testaamista. Testaaminen tulisi siis suorittaa portaittain alhaalta ylöspäin. Erityisesti palvelukeskeisen tietojärjestelmän testaaminen tulisi suorittaa niin, että jokainen palvelu ja tietojärjestelmän osa testattaisiin erikseen ja omana yksikkönä. Palvelukeskeisessä tietojärjestelmässä integraatioiden testaamisella on suuri merkitys, koska palvelut joista tietojärjestelmät rakentuvat eivät välttämättä sijaitse samassa ympäristössä. (Pfleeger, 2001: 338.) Yksikkötestaus Suunnittelu Järjestelmän toiminnalliset vaatimukset Muut sovellusvaatimukset Asiakkaan vaatimukset Käyttäjät Yksikkötestaus Integraatiotestaus Toimintatestaus Suorituskykytestaus Integraatiotestaus Hyväksymistestaus Yksikkötestaus Käyttöönotettu tietojärjestelmä Kuva 10: Testaamisen osavaiheet Pfleegerin mukaan, (Pfleeger, 2001: 338). Sommervillen esittää testaamisen myös Pflegeerin tapaan modulaarisena, kuten kuvasa kymmenen on esitetty. Jokainen moduuli tai sovelluksen muu osa testataan erikseen. Hän esittää hyvin yksityiskohtaisen yleisen testausmenetelmän jokaiselle moduulille. Jokaista moduulitestausta edeltää testauksen suunnittelu, testauksen valmistelu, testaaminen ja tulosten arvioiminen. Sommervilllen mukaan jokaisen yksittäisen pienen moduulin erikseen testaaminen ei kuitenkaan ole kannattavaa eikä käytännöllistä. Ideana testaamisessa on erilaisten testitapausten luominen ennen testauksia ja suorittaa testitapaus. (Sommerville, 2001: ) Testitapauksella tarkoitetaan esimerkiksi lomakkeen täyttäminen, lähettäminen ja vastaanottaminen. Näistä kolmesta vaiheesta jokainen pitää sisällään erilaisia toimintoja, jotka on hyvä testata. (Sommerville, 2001: )\n39 39 Testitapauksen tulisi olla tehdä niin, että se testaisi koko tapahtumasarjaa, kuten kuvassa 11 on tehty. Kuva esittää tilanteen, jossa tietojärjestelmälle on annettu syötteenä tietoa, kuvan tapauksessa syötetty tieto on sellaista, mitä tietojärjestelmän on oletettu saavan eli tietomuoto on oikeaa. Kuvan tilanteessa tietojärjestelmä tuottaa tietoa toiselle tietojärjestelmälle. Kyseissä tilanteessa vastaanottava osapuoli saa virheellistä tietoa. Virheen syntyperä ei kuvasta selviä, eikä se ole välttämättä itsestäänselvyys tietojärjestelmän suunnitellulle ryhmälle. Ongelma voi johtua kuvassa eri osa-alueista kuten moduulin sisäisistä toiminnoista, moduulien välisistä tietoliikenneongelmista, rajapintojen reitityksistä, ulkopuolisista tietoliikenneyhteyksistä tai käyttöliittymän sisäisistä toiminnoista. Kuvassa tietojärjestelmän rakenne on hyvin yleinen hajautetuissa tietojärjestelmissä, joissa samoja moduuleja voi käyttää useampi käyttöliittymä. Testaaminen tulee suorittaa mahdollisimman laajasti, jotta voidaan todeta tietojärjestelmän toimivuus. (Sommerville, 2001: ) Input: tekstiä Tietojärjestelmä Moduuli-2 Output: tekstiä Käyttöliittymä-1 Moduuli-4 Moduuli-3 Käyttöliittymä-2 Input: lukuarvo Moduuli-1 Moduuli-5 ERROR Rajapinta / palomuuri Kuva 11: Tietojärjestelmän testaamista toimintatapauksilla. Mukailtu (Pressman, 2005: ; Sommerville, 2001: ; Pfleeger, 2001:341, ). Useissa testaamista käsittelevissä kirjoituksissa kehotetaan saada tietojärjestelmä kohtaamaan jokin ongelma. Toisin sanoen yritetään syöttää tietojärjestelmälle virheellistä tietoa kuten puhelinnumeroksi tekstiä ja katsotaan kuinka tietojärjestelmä reagoi syötettyyn tietoon. (Pressman, 2005: 420; Sommerville, 2001: ; Pfleeger, 2001: ; Maciazek, 2005: 29 30; Beizer, 1995: 7; Akingbehin, 2006: )\n40 40 Vaatimusmäärittelyssä mahdollisesti tehdyt käyttötapauskaaviot antavat kuvan siitä kuinka tietojärjestelmän tulisi toimia. Hyvin tehdyistä käyttötapauskaavioista voidaan nähdä esimerkiksi mitä on oletettavissa kun tietyssä vaiheessa käyttäjä antaa jokin komennon tietojärjestelmälle. Tietojärjestelmän toimivuutta voidaan peilata myös vaatimusmäärittelyn vaatimuslistaa vastaan. Vaatimusmäärittelyn vaatimusten toteutumisen testaaminen on tärkeää tietojärjestelmän kannalta ja on suoritettava riippumatta tietojärjestelmästä. Vaatimusmäärittelyn vaatimuksen testaaminen voidaan suorittaa aiemmin kuvaillulla testitapauksella. Esimerkkinä vaatimus, jonka mukaan tietojärjestelmän tulee lähettää vastaanotettu tieto tietyn ajan sisällä siitä kun se on vastaanottanut tiedon. Luodaan testitilanne, jossa tietojärjestelmälle syötetään tietoa ja otetaan aikaa siitä kuinka kauan tiedon kulku kestää. Esitetty tilanne tulisi suorittaa useamman kerran ja eri tilanteissa. Tietoliikenneyhteydet tai muut itse tietojärjestelmästä riippumattomat muuttujat saattavat vaikuttaa vaatimusmäärittelyn vaatimuksen onnistumiseen. Vaatimusmäärittelyn vaatimusten 100 % täyttyminen voidaan saavuttaa esimerkiksi toimistolla, mutta sitä ei välttämättä saavuteta etäyhteydessä tai tietyllä sovellusversiolla. Tällöin tietojärjestelmän vaatimusmäärittelyssä tulisi olla priorisoitu vaatimukset ja esimerkiksi asettaa eri käyttötavoille omat vaatimuksensa. Pfleegerin mukaan käyttäjien ja asiakkaiden mukaan ottaminen testaamiseen on tärkeää, mutta vasta siinä vaiheessa kun kehittäjäryhmä on saanut testattua kaikki komponentit. (Pfleeger, 2001: ) Phillips ohjeistaa ottamaan käyttäjät mukaan, vasta siinä vaiheessa kun tietojärjestelmä on saatu testattua moduulien, tietoliikenteen ja integraatioiden osalta. Käyttäjien päästessä testaamaan ei näistä johtuvia ongelmatilanteita saa esiintyä. Tietojärjestelmän toimivuus siinä vaiheessa kun käyttäjät pääsevät testaamaan sitä on tietojärjestelmän kannalta erittäin tärkeää. Käyttäjien saama ensivaikutelma tietojärjestelmästä antaa yleensä suunnan sille, kuinka tietojärjestelmä otetaan vastaan. Ensivaikutelma tietojärjestelmästä jää voimaan. (Phillips, 2001: 231.)\n41 41 Pfleegerin mukaan erityisesti tietojärjestelmän vaatimusmäärittelyssä ja suunnittelussa mukana olleiden käyttäjien mukanaolo on testausvaiheessa erittäin tärkeää. Suunnittelussa mukana olleet käyttäjät tietävät minkälaista tietojärjestelmää on oltu rakentamassa, joten heitä ei tarvitse kouluttaa tietojärjestelmän käyttäjiksi, ainakaan samalla laajuudella kuin täysin uutta henkilöä. (Pfleeger, 2001: 413.) Pressman painottaa tietojärjestelmän testaamisen lisäksi myös dokumentaation testaamista. Hänen mukaansa ongelmat dokumenteissa voivat olla yhtä katastrofaaliset tietojärjestelmän käyttöönoton kannalta kuin ohjelmakoodissa olevat virheet. Dokumentaation testaamisella Pressman tarkoittaa sitä, että esimerkiksi ohjeistus käydään tarkasti läpi, jotta ohjeistus vastaa sitä mitä käyttäjä näkee ruudullaan. (Pressman, 2005: ) Pfleeger mainitsee myös dokumentaation merkityksen, ei pelkästään koulutusvaiheessa, vaan myös koko tietojärjestelmähankinnan onnistumisessa. Tällä hän tarkoittaa käyttöohjeistuksen lisäksi ylläpito-ohjeistusta (esim. toipumisohjeet, asennusohjeet). (Pfleeger, 2001: 453.) Käyttöönotto Tietojärjestelmän käyttöönottovaihe on enemmän kuin ilmoitus käyttäjille, että he voivat aloittaa tietojärjestelmän käytön. Tulevat käyttäjät tulee tutustuttaa ja kouluttaa tietojärjestelmään perusteellisesti. Hyväkään tietojärjestelmä ei auta jos käyttäjät eivät koe sitä omakseen. Pfleegerin mukaan onnistuneeseen tietojärjestelmän käyttöönottoon vaaditaan hyvä koulutus ja dokumentaatio. (Pfleeger, 2001: 448.) McConnellin mielestä koulutuksen rooli on tärkeä käyttöönotossa, koska huonolla käyttöönottokoulutuksella voidaan pilata hyvä tietojärjestelmä. (McConnell, 2002: 359.) Koulutusta on järjestettävä tietojärjestelmän käyttäjän lisäksi myös tietojärjestelmän ylläpitäjälle. (Phllips, 2001: 254.) Ylläpitäjällä tarkoitetaan tässä tapauksessa tahoa, jolle palvelinten ja muun teknologian ylläpito on ulkoistettu, eli käyttöpalvelutoimittajaa. Pfleeger jakaa koulutettavat kolmeen eri ryhmään sen mukaan missä asemassa ne ovat. Pääasiassa käyttäjäryhmiä on vain kaksi: normaalit käyttäjät ja ns. pääkäyttäjät, jotka voivat tarjota tukea normaaleille käyttäjille. Kolmas käyttäjäryhmä on ne henkilöt, jotka aloittavat tietojärjestelmän käytön vasta sen jälkeen kun tietojärjestelmä on otettu käyttöön. (Pfleeger, 2001: )\n42 42 Pitkien ohjeistustekstien ja manuaalien sijasta Pfleeger ehdottaa käyttämään esimerkiksi online-tyyppisiä ohjeistuksia, joissa tilanteet on kuvattu käyttäen oikeita kuvankaappauksia tietojärjestelmästä. Kurssityyppinen ratkaisu on Pfleegerin mukaan toimiva. Hän viittaa Scharerin vuonna 1983 tekemään tutkimukseen, jossa tutkittiin käyttäjien ohjeiden lukuaktiivisuutta, joka oli noin % kohderyhmästä. Lukuaktiivisuudella tarkoitettiin henkilöiden määrää, jotka lukevat annetun ohjeistuksen Ohjaavat tekijät Tietojärjestelmähanketta ohjaavat erilaiset rajat, jotka asetetaan yleensä projektin ulkopuolisten henkilöiden toimesta. Rajaavina tekijöiksi voidaan mainita muun muassa budjetti, aikataulu ja tavoite Budjetti Budjetin ylittyminen on yleinen ongelma tietojärjestelmähankkeissa. Jälkeenpäin on helppo nähdä mistä ylittyminen johtuu. Tästä voidaan toki oppia seuraavia vastaavanlaisia projekteja varten, mutta esimerkiksi Tiehallinnossa tilanne on usein ainutlaatuinen eli vastaavaa tietojärjestelmää ei ole tehty. Pressman ehdottaa, että budjettiarvio tulisi tehdä mahdollisimman myöhään, sitten vasta kun on saatu selvitettyä projektiin vaikuttavia muuttujia. (Pressman, 2005: 680.) Pressmanin esittämä tapa on hyvä, mutta se ei sovellu organisaatioihin, joissa budjetti annetaan projektin ulkopuolelta. Tällöin projektin on tultava toimeen annetulla budjetilla. Pressmanin ehdotus sopii yritykselle, joka odottaa uudelta hankinnalta selkeää tuottoa, koska silloin budjettiylitys on helpommin perusteltavissa. Tsang-Ming ja Coynerin artikkelissa Software Process Disturbances käsitellään tietojärjestelmä hankkeeseen vaikuttavia tekijöitä, jotka usein nostavat hankkeen kustannuksia. Yleisimmäksi syyksi he nostavat vaatimusmäärittelyn puutteet. Toisin sanoen, projektin aikana tulee vastaan odottamattomia vaatimuksia, joiden lisääminen tietojärjestelmään saattaa aiheuttaa lisätyötunteja ohjelmoijille ja sitä kautta nostaa hankintakustannuksia.\n43 43 Testaamisen tärkeyttä korostetaan myös, koska testaamisvaihe on se projektin vaihe, jossa tarkastetaan, ettei lopulliseen tuotteeseen päädy virheitä. Jos tässä vaiheessa yritetään päästä mahdollisimman pienillä kustannuksilla, voi säästetty summa olla pieni sen rinnalla mitä tulee maksamaan virheiden korjaaminen kun tietojärjestelmä on jo käytössä. Liian usein testivaihe on leikkausten kohteena, jos tietojärjestelmäprojektin aikataulu uhkaa venyä. Testaamisen vähentäminen tai pahimmassa tapauksessa sen väliin jättäminen voi kostautua myöhemmin. Tämä viittaa aikataulusuunnitteluun, jossa ei pitäisi aliarvioida projektin vaiheita. Aikatauluarvioista tehdään Tsang-Mingin ja Coynerin mukaan liian tiukkoja, joka johtuu siitä, että projektin vaiheiden vaatima aika aliarvioidaan. Olemassa olevan arkkitehtuurin sivuuttaminen saattaa myös aiheuttaa tietojärjestelmälle ylimääräisiä ylläpitokustannuksia tai mahdollisesti tietojärjestelmän kanssa tullaan hankkineeksi teknologiaa, jota yrityksellä/organisaatiolla on jo käytössä. Ylimääräiset ylläpitokustannukset johtuvat siitä, että hankittua tietojärjestelmää ei voida ylläpitää olemassa olevilla toimilla, vaan sitä varten joudutaan kehittämään esimerkiksi tukijärjestelmiä. (Tsang-Ming ja Coyner, 2000.) Jones Capers on tutkinut tutkijayhteisönsä kanssa tietojärjestelmähankkeita luvulta lähtien. (Jones, 1995: Jones, 2003.) Tutkimuksen piiriin kuuluu yli erikokoista tietojärjestelmähanketta. Jonesin mukaan suurimmat syyt budjetin ylittymiseen ja aikataulun venymiseen on huonosti tehdyt alkuvalmistelut, kuten vaatimusmäärittely ja suunnitelma. Jonesin mukaan esimerkiksi aikataulu tehdään usein aliarvioimalla vaadittava aika. Tietojärjestelmähankintaan vaikuttavien tekijöiden arvioiminen voi olla haastavaa myös sen takia, että kyseessä ei ole samanlainen tuote kuin teollisuudessa. Tietojärjestelmää ei voi kokea samalla tavalla kuin esimerkiksi talon voi kokea. Tämä on Jonesin mukaan yksi mahdollinen syy siihen miksi alkuvalmisteluissa epäonnistutaan. (Jones, 1995: Jones, 2003.)\n44 Käyttöympäristö Yrityksen tai organisaation jo olemassa oleva tietotekninen ympäristö asettaa uusille tietojärjestelmille vaatimuksia, jotka on otettava huomioon tietojärjestelmähankkeen aikana. Vaatimukset eivät välttämättä ole rajaavia, vaan ne voivat olla myös tietojärjestelmää tukevia ominaisuuksia. Esimerkiksi Tiehallinnon SONJA-palvelu on viestinvälitysjärjestelmäpalvelu, joka pystyy keskustelemaan eri tietojärjestelmien kanssa. Etuna viestinvälitysjärjestelmällä on se, että jos kehitettävä tietojärjestelmä suunnitellaan toimivaan saumattomasti sen kanssa, voi rakennettavaan tietojärjestelmään yhdistää tietojärjestelmiä, jotka eivät muuten kykenisi keskustelemaan. Teknisessä ympäristössä on sovelluksia, joiden sovellusversiot saattavat aiheuttaa ongelmia, jos niitä ei oteta huomioon ajoissa. Tämän tutkimuksen tutkimuskohteista yksi on Tiehallinnon KOKA2008-projekti, siinä toteutettiin korkeankäytettävyydenpalvelualustan. Se on sovellusalusta, joka antaa järjestelmätukea järjestelmille. Kyseisen alusta kykenee tarjoamaan aiemmin mainitun SONJAN:n lisäksi esimeriksi SSO (Single- Sign ON) palvelun, joka helpottaa käyttäjiä, koska heidän ei tarvitse muistaa kuin yksi käyttäjätunnus-salasanapari. Vastaavanlaiset ympäristöt on syytä ottaa huomioon tietojärjestelmää suunniteltaessa, koska ne saattavat oikein hyödynnettynä pienentää kustannuksia ja lyhentää hankintaan tarvittavaa aikaa. (Pressman, 2005: )\n45 Aikataulu Yleisesti tietojärjestelmähankintoja haittaa myöhästyminen. Aikataulut luodaan usein liian optimistisiksi. Yleensä syynä on henkilö, jonka työnkuvaan ei kuulu tietojärjestelmähankinnat. (Pressman, 2005: 706.) Aikataulun seuranta pettää Tekniset vaikeudet Odottamattomat ongelmatilanteet Projektiaikataulu Projektin vaativuuden arvioiminen Projektiryhmän sisäiset kommunikaatioongelmat Henkilöstöresurssit Vaatimusten muuttaminen, ilman suunnittelua Kuva 12: Aikatauluun vaikuttavia tekijöitä, mukailtu (Pressman, 2005: 706). Pressmanin mukaan aikatauluja muuttavat hankinnan aikana tulevat odottamattomat tehtävät, joita ei osattu tai ei onnistuttu ennustamaan. Aikatauluun vaikuttavia tekijöitä Pressman esittelee kuvan 12 mukaisesti Tavoite Tietojärjestelmähankkeen ensimmäinen ja tärkein tehtävä on tavoitteen määritteleminen. Tavoite koetaan eri tavalla eri liiketoimintayksiköissä, kuten kuvassa 13 on esitetty. Liiketoiminnan tavoitteet muodostuvat eri käyttäjäryhmistä ja siitä, mitä hankittavan tietojärjestelmän tulisi tehdä. Hankkeen alkuvaiheessa on liiketoiminnalle oltava selvänä käyttötarkoitus ja tarpeet. Ilman liiketoiminnan ymmärrystä, on hyvin vaikeaa siirtää tavoitekuvaa toteuttajille. Epäselvä tavoite johtaa siihen, että toteuttajat pyrkivät arvailemaan mitä tilaaja haluaa.\n46 46 Tietojärjestelmän onnistumisen kannalta on erittäin tärkeää, että yhteinen päämäärä eli tavoite määritellään ennen kuin hanketta on viety sen pidemmälle. Yhteisen ymmärryksen saaminen vaatii, että eri liiketoiminnan yksiköt keskustelevat hankinnasta. Useimmiten vaatimukset ja liiketoiminnan tavoite eivät ole yhtenäisiä, joten jotta myöhemmin hankinnan aikana ei tulisi suuria yllätyksiä, yhteisen tavoitteen selvittäminen ja tavoitteessa pysyminen hankinnan läpi on tärkeää. Se että vaatimukset ja liiketoiminnan tavoitteet eivät ole yhtenäisiä, ennen yhteisiä tavoitekeskusteluja johtuu Schnabelin ja Pizkan mukaan siitä, että liiketoiminnan asiantuntijoilla ei ole tarpeeksi syvää tuntemusta tietojärjestelmien hankinnasta, jolloin he eivät pysty analysoimaan muutosten, toivomusten ja vaatimusten vaikutusta hankintaan. Kuvan 13 mukaisesti yhteiseen tavoitteeseen pääsemiseen vaikuttaa useat eri tekijät. Yhteinen tavoite Liiketoiminnan tavoitteet Liiketoiminnan omistaja Teknologia ohjaavuus Tietohallinnon tavoitteet Toimivuus Liiketoiminnan asiantuntija Käyttäjä Elinkaaren tilanne Tuetut ratkaisut Ohjelmistoversiot Uudelleenkäyttö Liiketoiminnan omistaja Kuva 13: Yhteisen tavoitteen muodostuminen, mukailtu (Schnabel ja Pizka, 2006.) Liiketoiminnan tavoite on mahdollinen, mutta vain jos tavoitteelle ei ole asetettu tiukkaa aikataulua, resursseja on runsaasti tarjolla ja se ei ole sidoksissa ympäristöön. Pieni muutos voi olla nopea ja halpa työ, mutta kun muutos kohdistuu tietojärjestelmän monimutkaiseen moduuliin, voi työhön kuluva aika olla ei teknisen henkilön mielestä käsittämätön, puhumattakaan työn hinnasta. (Schnabel ja Pizka, 2006.) Lee ja Nien- Lin esittävät, että tavoitehakuisessa tietojärjestelmäkehityksessä on hyvä käyttää käyttötapauskuvauksia heti alussa hahmottamaan, että mihin tarkoitukseen hankittava tietojärjestelmä tulee.\n47 47 Pressman ehdottaa myös käyttötapausskenaarioiden tekemistä, eri käyttäjäryhmille, jotta kehittäjäryhmän olisi helpompi havainnoida millaista tietojärjestelmää ollaan rakentamassa. (Pressman, 2005: ) Käyttötapauskuvien avulla voidaan lähteä hyvinkin karkealta tasolta selvittämään tietojärjestelmän rakennetta ja käyttötarkoitusta. Ensimmäiset käyttötapaukset kuvaavat hyvin karkealla tasolla, minkälaisen tiedon kanssa tietojärjestelmä tulee toimimaan. Seuraavat kuvaukset määrittelevät mitä käytettävälle tiedolle tulisi tehdä. Kolmannen tason kuvauksissa siirrytään kuvaamaan käyttäjän näkökulmasta kuinka tietojärjestelmän tulisi toimia. Kesken tietojärjestelmähankintaprojektin esiin tulevat vaatimusmuutokset vaikeuttavat tietojärjestelmän rakentamista ja voivat aiheuttaa suuria aikataulupoikkeamia, sitä kautta vaikuttaen myös projektin budjettiin. Barry Boehm tarkastelee artikkelissaan Project Termination Doesn t Equal Project Failure tunnetun Chaos-raportin tulosta, jonka mukaan hieman yli 30 % tietojärjestelmäprojekteista peruutetaan ennen kuin ne ehtivät edes kunnolla käynnistyä, saati sitten valmistua. Chaos-raportti esittää 30 % prosentin määrän negatiivisena tuloksena, kun taas Boehm arvostelee tulosta, koska se antaa hänen mielestään väärän kuvan tilanteesta. Tietojärjestelmähanke, joka lopetetaan ennen kuin se valmistuu, ei Boehmin mukaan aina ole yhtä kuin epäonnistuminen. (Boehm, 2000: Pressman, 2005: ) Vesiputousmallin mukaan edenneessä tietojärjestelmähankkeessa on riskinä, että alkuvaiheen määrittely ja suunnittelu eivät ole olleet aukottomia. Vesiputousmallin mukaisesti etenevä tietojärjestelmähankintaprojekti ei ole yhtä ketterä vastaanottamaan muuttuvia vaatimuksia kesken projektia kuin iteroiva malli. Boehmin mukaan projekti ei ole täysin epäonnistunut, jos se lopetetaan, kun huomataan siihen kohdistuvien muutoksien muodostuvan niin suuriksi, että toteutuva tietojärjestelmä ei palvele tavoitetta. Ongelmana usein on henkilökohtaiset tavoitteet eikä niinkään liiketoiminnan tavoitteet. Projektin lopettaminen, ennen kuin se on valmis, koetaan henkilötasolla epäonnistumiseksi. Tämä johtaa usein tilanteeseen jossa projektia edistävä taho päättää viedä projektin loppuun tavalla tai toisella. (Boehm, 2000.)\n48 48 Pressman viittaa Boehmiin esittelemään HH -periaatteeseen, jonka avulla voidaan aloittaa mikä tahansa projekti, oli se sitten tietojärjestelmä- tai siltaprojekti. tarkoittaa yksinkertaisesti kysymyssarjaa why (miksi), what (mitä), when (milloin), who (kuka/ketkä), where (missä), how (kuinka) ja how much (kuinka paljon). Boehmin ideana on, että projekti aloitetaan mahdollisimman yksinkertaisilla kysymyksillä. Saatujen vastausten perusteella tehdään projektisuunnitelman ensimmäinen luonnos. (Pressman, 2005: 644; Boehm, 1996.) W 5 W 5 HH 3.6. Yhteenveto viitekehyksestä Kuvassa 14 kuvataan tämän tutkimuksen viitekehys joka mukailee Pfleegerin, Phillipsin ja Pressmanin tietojärjestelmän hankinnan viitekehyksiä. Viitekehys on jaettu neljään ryhmään, jotka ovat työvaiheet, ohjaavat tekijät, työkalu ja henkilöstöresurssit. Ne muodostavat kokonaisuuden, jota sovelletaan tässä tutkimuksessa. Työvaiheet Vaatimusmäärittely Riskianalyysi Kilpailutus Suunnittelu Toteutus Hankintaprosessi Työkalut Prosessimalli Mallinnuskieli Ohjaavat tekjiät Henkilöstöresurssit Asiantuntija(t) Projektipäällikkö Asiakas Toimittaja Testaus Budjetti Aikataulu Käyttöpalvelun edustaja Käyttöönotto Tavoite Käyttöympäristö Käyttäjä Kuva 14: Hankintaprosessiin vaikuttavat tekijät (mukailtu Pfleeger, 2001; Phillips, 2000; Pressman, 2005). Kuvan viitekehyksessä kilpailutus on korostettu muista eroavaksi. Kilpailutus on erityisesti julkishallintoa koskeva työvaihe.\n49 49 Julkishallinnolle asetetut säädökset ja lait tuovat oman lisänsä hankintarakenteeseen, ne ovat yleensä jääneet vähemmälle huomiolle tietojärjestelmien hankintaa käsittelevässä kirjallisuudessa. Tiehallinto joutuu kilpailuttamaan julkisella kilpailumenettelyllä hankinnat, jotka ylittävät tietyn hankintahinnan. Tiehallinnossa ja nykyisessä Liikennevirastossa tuo hankintahintaraja ylitettiin lähes poikkeuksetta. Kilpailutusprosessi koostuu vaiheista kuten tarjouspyynnön tekeminen, mahdolliset lisäkirjeet, tarjousten läpikäynti ja niiden pisteytys. Kilpailutuksen vaiheet vaativat aikaa ja paneutumista projektiryhmältä. Kilpailuttamisprosessi noudattaa voimassa olevaa hankintalakia, joka ohjaa kilpailuttamista tarkasti. Päämääränä hankintalailla on tarjota kaikille vaatimukset täyttäville tarjoajille tasapuolisen mahdollisuuden tehdä tarjous. Suunnitteluvaiheeseen siirrytään kun toimittaja on valittu, jonka jälkeen prosessia jatketaan käytössä olevan prosessimallin mukaisesti. Tiehallinnossa yleisesti käytössä oleva hankintaprosessi noudattaa vesiputousmallin mukaisia vaiheita. Vesiputousmallissa vaiheet saatetaan päätökseen ennen siirtymistä seuraavaan vaiheeseen. Seuraavasta vaiheesta ei palata edelliseen vaiheeseen. Tämä luo suuren paineen perusteelliselle esitutkimukselle, vaatimusmäärittelylle, riskianalyysille ja suunnittelulle. Edellä mainitut neljä vaihetta luovat mahdollisuuden hankkeen menestymiseen tai epäonnistumiseen. (Kettunen, 2002; Pressman 2000.)\n50 50 4. TUTKIMUSKOHTEEN ESITTELY Tämän tutkimuksen kohteena on liikenne- ja viestintäministeriön alaisuudessa toiminut Tiehallinto, joka on nykyään osa Liikennevirastoa. Tässä tutkimuksessa tarkasteltiin viraston ICT-palvelunhankintaprosessia kolmen tapauksen perusteella Liikennevirasto Liikennevirasto aloitti toimintansa yhdistäen kolmen eri väyläviraston päätoiminnot. Liikennevirasto toimii Liikenne- ja viestintäministeriön alaisuudessa ja vastaa liikenteen palvelutason ylläpidosta ja kehittämisestä valtion hallinnoimilla liikenneväylillä. Liikennevirasto koostuu Merenkulkulaitoksen väylätoiminnoista, Ratahallintokeskuksesta ja Tiehallinnon keskushallinnosta, jota kuvataan kuvassa 15. Kuva 15: Tiehallinnon muutoksen vaiheita matkalla Liikennevirastoksi.\n51 51 Liikenneviraston vastuulla on noin 6000 kilometrin pituinen rautatieverkosto (Ratahallintokeskus 2009), yli kilometriä tieverkostoa (Tiehallinto 2009) ja noin kilometriä vesiliikenneväyliä (Merenkulkulaitos 2009). (Finlex, 2010; LVM, 2010.) Suomen eri väylämuodoista kootun tiedon määrä on suuri, laskettiin se tietokantojen riveinä tai gigatavuina. Tiedon hallittavuus on erittäin suuressa roolissa Liikennevirastossa. Liikenneviraston Tiedonhallintayksikön vastuulla on nykyään noin 400 tietojärjestelmää. Tietojärjestelmien lisäksi yksikön vastuulla on Liikenneviraston perustietopalvelujen, sovellusalustojen ja tietoliikenteen ylläpitäminen. Liikennevirasto tarjoaa väylien käyttäjille runsaasti informaatiota, joista esimerkkeinä Ratahallintokeskuksen matkustajainformaatio ja Tiehallinnon tiesää- ja kelitiedot. Liikennevirasto informoi pääasiassa Internet-palvelujen kautta, mutta käytössä on myös liikenneväylien varrella olevia sähköisiä opasteita. Liikenneviraston tietojärjestelmät mahdollistavat informaatiopalveluiden tarjoamisen monipuolisesti. Tietojärjestelmät tukevat myös Liikenneviraston omaa toimintaa integroiden sidosryhmien järjestelmät suoraan Liikenneviraston järjestelmiin. Tiehallinto, jonka hankintaprosessia tarkastellaan tässä tutkimuksessa, on 2000-luvulla toiminut tilaajaorganisaationa Liikenne- ja Viestintäministeriön 1990-luvun lopulla tekemä tulosohjauspäätös. Hankintaprosessi on suuntautunut tietojärjestelmien ja tietopalveluiden hankintaan. Liikennevirastossa noudatetaan kaikissa hankinnoissa hankintalakia. Tutkittava prosessi noudattaa pitkälti yleisesti tietojärjestelmähankkeissa käytettäviä prosessimalleja. Prosessien runkona voidaan pitää vesiputousmallia, joka on useissa lähteissä esitetty olevan prosessimallien lähtökohta. (McConnell, 2002; Pressman, 2005; Finlex, 2010b.) Tiehallinnossa hankintaprosessin merkitys vahvistui, kun toiminnan tuli keskittyä ydinosaamiseen eli Suomen tieverkon ylläpitoon ja kehittämiseen. Tiehallinnon tehtävä muuttui hallinnolliseksi toimijaksi, asiantuntijaorganisaatioksi.\n52 52 Tästä syystä Tiehallinnon tuli ulkoistaa organisaation ne osa-alueet, jotka eivät ole sen ydinosaamista. Tällöin Tiehallinnosta eriytettiin tuotanto-osastot, niin tienpidon kuin myös IT-osaamisen osastot. Sovellustuotantoa ei Tiehallinnolla ole, vaan tietojärjestelmien toteutus ostetaan tietotekniikkayrityksiltä. Tiehallinto ei omista palvelimia tai henkilöstön työasemia, vaan ne on hankittu erilaisilla leasing-sopimuksilla. (Laki Tiehallinnosta /568.) Tiehallinnon, Ratahallintokeskuksen ja Merenkulkulaitoksen välillä on kulttuurieroja toiminnan eri osa-alueilla, niin myös tietohallinnon alueella. Esimerkkinä voidaan esittää Tiehallinnon ja Merenkulkulaitoksen ero järjestelmien kehittämisessä. Merenkulkulaitoksessa oli tietotekniset ratkaisut toteutettu suurelta osin itse, jolloin vastuu oli myös ohjelmointiin liittyvistä tehtävistä Merenkulkulaitoksella. Tiehallinnossa nämä toiminnot ovat ulkoistettu TAPAUS: Häiriötietojärjestelmä (Häti) Liikenneviraston tieosaston vastuulle vuodesta 2010 alkaen kuuluva tieliikennekeskus valvoo Suomen tieverkon tilaa ympäri vuorokauden. Tieliikennekeskuksessa toimii liikennepäivystäjiä, jotka seuraavat tieltä välittyviä tietoja videokuvan, erilaisten antureiden ja tienkäyttäjiltä tulleiden viestien avulla sekä yhteistyössä eri sidosryhmien kanssa mm. poliisi ja hätäkeskukset. Havaituista ongelmista tiedotetaan asianosaisia, jotta vika saataisiin korjattua ja tien käyttö olisi turvallista tiellä liikkujille. Liikennepäivystäjien päätyökaluna on häiriötietojärjestelmä, Häti. Hätin merkitys liikennepäivystyksessä on erittäin suuri, sen kautta kulkee tieto tiellä olevista häiriötekijöistä. Hätiin kirjataan liikennepäivystäjien vastaanottamat puhelut automaattisesti. Liikennepäivystäjä voi tarkentaa näyttöpäätteelle aukeavan lomakkeen avulla ilmoitusta. Häiriötietojärjestelmän toimivuus on liikennekeskukselle erityisen tärkeää, koska sen kautta välitetään liikennetiedotteet tienkäyttäjien lisäksi viranomaisille ja urakoitsijoille.\n53 53 Häti saa tietoja useista eri tietolähteistä ja välittää niitä useille eri tahoille. Integraatiot muihin järjestelmiin ja tahoihin asettivat hankinnalle paineita ja erityisvaatimuksia. Tarve uudelle tietojärjestelmälle oli selkeä, vanha järjestelmä ei enää palvellut käyttäjiään tarpeeksi monipuolisesti ja suurin syy oli sen hitaus. Liikennepäivystäjä vastaanottaa työvuorossaan useita yhteydenottoja, jolloin jo muutaman sekunnin viivytys vaikuttaa. Häiriötietojärjestelmän hankinnan alussa projektiryhmä suoritti yhteistyössä ulkopuolisen toimittajan kanssa hankintatapa-analyysin, jonka tarkoituksena oli arvioida erilaisia tapoja hankkia tietojärjestelmä. Analyysin tuloksena oli Tiehallinnon tarpeisiin räätälöitävä tietojärjestelmä. Vastaavanlaiseen käyttötarkoitukseen ei ollut valmisohjelmistoa tarjolla. Hätille luotiin yhteydet Tiehallinnon sanomanvälityspalvelimeen (SONJA) sekä paikkatietojärjestelmään (PTJ). SONJA mahdollistaa viestien lähetyksen sellaisten järjestelmien välillä, jotka eivät sellaisinaan pystyisi välittämään tietoa rajapintojensa kautta. PTJ mahdollistaa sen, että tiellä olevat häiriöt voidaan paikallistaa graafiselle karttaalustalle, jolloin mahdollisen kiertoreitin suunnittelu nopeutuu. Toteutusvaihe noudatti ketterää menetelmää, jota ei ollut kokeiltu Tiehallinnossa aiemmin. Ketterän menetelmän perusajatus on se, että edetään pienissä niin sanotuissa sprinteissä. Liikennepäivystäjien työskentely vuorotyössä aiheutti ongelman, koska työvuoro oli entuudestaan täynnä suoritettavia työtehtäviä, jolloin heiltä ei riittänyt tarpeeksi aikaa testaamiselle. Käyttäjiltä on kysytty jälkeenpäin tietojärjestelmähankkeen onnistumisesta, johon käyttäjät ovat vastanneet, että ovat olleet tyytyväisiä. Käyttöönoton jälkeinen mielipide oli kielteinen, jonka johdosta järjestelmään tehtiin muutoksia. Parannusten jälkeen liikennepäivystäjät ovat olleet tyytyväisiä uuteen tietojärjestelmään.\n54 TAPAUS: Matka-aikapalvelu Matka-aikatietopalvelun tarkoitus on parantaa tienkäyttäjien mukavuutta, tarjoamalla runkotieverkon sujuvuustietoja. Matka-aikatietopalvelu tuottaa tietoa matka-ajoista, keskinopeuksista ja sujuvuusluokista. Matka-aikatietopalvelu päätettiin hankkia täysin ulkopuolisena palveluna, jolloin Tiehallinnon omistukseen ei siirry tietojärjestelmää tai muuta sovellusta. Tiehallinto määritteli palveluntarjoajalle, minkälaisella palvelutasolla osti tietoa. Hankintaa valmisteltiin tutkimalla eri toteutusvaihtoehtoja. Vaihtoehtojen määrä oli hyvin pieni, jolloin päädyttiin aiemmin kokeiltuun malliin. Toimittajan tehtäväksi tuli pystyttää tieverkolle 160 linkkiä, jotka laskevat ohitse kulkevien autojen määrää ja liikennetiheyttä. Kilometreinä kattavuus on noin 3200 kilometriä. Toimittajalle annettiin mahdollisuus hyödyntää tilaajan omistamia sähköliitäntöjä. Sähkökytkentöjen lupakäsittely oli odotettua suurempi ja aiheutti viivästyksiä asennustöissä. Myös vuodenaika asetti rajoitteet työlle. Linkkiasemien tiedonsiirrot muodostuivat ongelmaksi. Ongelmana oli liian heikko tiedonsiirtokyky. Linkkiasemat käyttivät matkapuhelinverkon avulla toteutettua tietoliikennettä, joka osoittautui haja-asutus alueilla liian heikoksi, jolloin linkkiasema ei saanut välttämättä yhteyttä tai se käytti nopean 3G:n sijasta hidasta 2G-verkkoa. Matka-aikatietopalvelu on ollut toiminnassa ja tuottanut odotettua palvelua ulkopuolisille toimijoille. Tietopalvelu oli ainutlaatuinen Suomessa, joka osittain antaa heikon lähtökohdan hankinnalle, koska vertailukohtia ei ollut tarjolla TAPAUS: KOKA2008 KOKA2008 eli korkeankäytettävyydenalusta valmistui vuonna Sen tarkoitus on tarjota erilaisille tietojärjestelmille monipuolinen alusta ja järjestelmäpalveluita. Tavoitteena projektin alussa oli tuottaa tehokas ja hyvin palveleva palvelualusta Tiehallinnon tietojärjestelmille.\n55 55 Alustojen elinkaari on noin kolme vuotta ja edellisen alustan elinkaari oli lopussa. Se synnytti tarpeen uudelle alustalle, jolloin KOKA2008 sai alkunsa. KOKA2008 merkitys Tiehallinnon tietohallinnolle oli merkittävä, sen oli tarkoitus palvella useampaa tietojärjestelmää. KOKA tarjoaa esimerkiksi viestinvälityspalvelun, jonka avulla tietojärjestelmät voivat keskustella sellaisten tietojärjestelmien kanssa, joiden rajapinnat eivät kykene yhteistyöhön sellaisenaan. Käyttäjäystävällisyyttä tuova SSO (single-sign-on) mahdollistaa eri tietojärjestelmien salasanakäytäntöjen piilottamisen käyttäjältä. KOKA2008-projektin tavoite oli selkeä, haluttiin varmistaa, että tietojärjestelmille voidaan tarjota toimiva ja luotettava ajoalusta. Tavoite toteutui ja alustan tarjoamiin palveluihin ollaan oltu tyytyväisiä. Elinkaareksi oli ajateltu aiemman alustan mukaan kolme vuotta. Alustan elinkaari on siis tulossa päätökseen piakkoin. Projektia vaivasivat viivästymiset, jotka sijoittuivat projektin loppuvaiheessa olleeseen testausvaiheeseen. Testausvaiheen ongelmia oli muun muassa pula testaajista ja testitapauksista. Projekti saatiin valmiiksi viivästyksistä huolimatta.\n56 56 5. TUTKIMUKSEN TOTEUTUS Tässä luvussa esitellään tutkimuksessa käytetyt tutkimusmenetelmät ja tutkimuksen eteneminen. Tämä tutkimus on luonteeltaan laadullinen eli kvalitatiivinen. Tutkimus toteutettiin tapaustutkimuksena, joka on yksi laadullisen tutkimuksen tavoista. Kohdetapausten valinnan jälkeen tutkimuksessa keskityttiin aineistoanalyysiin ja ICTpalveluhankintaan liittyvään teoriatutkimukseen. Aineistoa tapauksista kerättiin teemahaastatteluilla ja kohdetapausten dokumenteista. Analyysin tavoitteena oli dokumentaation perusteella paikantaa kohtia, joihin tarvittaisiin lisäselvitystä. Lisäselvitys toteutettiin teemahaastattelulla, jossa kysymykset oli muotoiltu teoriaosuuden viitekehyksen perusteella. Seuraavaksi omina lukuina esitellään tässä tutkimuksessa käytetyt tutkimusmenetelmät, tutkimuksen luotettavuus, tapausten esittely ja tutkimuksen eteneminen Tutkimusmenetelmät ja eteneminen Laadullinen, kvalitatiivinen, ihmistieteellinen, pehmeä, ymmärtävä ja tulkinnallinen tutkimus kuvaavat kirjallisuudessa laadullisen tutkimuksen luonnetta. Laadullista tutkimusta määrittäessä peruskysymykseksi muodostuu laadullisen tutkimuksen suhde teoriaan ja teoreettiseen. Teorian merkitys laadullisessa tutkimuksessa on keskeinen ja siksi sitä tarvitaan. Tutkimuksissa teorialla tarkoitetaan tutkimuksen viitekehystä eli tutkimuksen teoreettista osuutta. (Tuomi&Sarajärvi, 2009: ) Tässä tutkimuksessa viitekehyksessä kuvataan tutkimuksen keskeisimmät käsitteet ja niiden väliset suhteet. Viitekehys siis muodostaa tutkimusta ohjaavan metodologian ja sen mitä tutkittavasta ilmiöstä jo tiedetään. Laadullisen tutkimuksen yleisimmiksi aineistonkeruutavoiksi on lueteltu, haastattelu, kysely, havainnointi ja erilaisiin dokumentteihin perustuva tieto. (Tuomi&Sarajärvi, 2009: 71; Darke et al., 1998: 275.) Tässä tutkimuksessa aineistoa kerättiin haastattelemalla ja erilaisista dokumenteista.\n57 57 4.Tutkimussuunnitelma 7.Lisätutkimustarpeiden määrittely 1.Aiheen valinta 6.Kirjoittaminen 6.Aineiston analysointi 2.Tavoitteiden määrittely 3.Aiheeseen tutustuminen 5.Aineiston keruu Tutkimusspiraali Kuva 16: Tutkimusspiraalin vaiheet. Mukailtu (Tuomi&Sarajärvi, 2009: 151.) Tutkimuksen eteneminen noudatti tutkimusspiraalin työvaiheita. Työvaiheet ovat esitelty kuvassa 16. (Tuomi&Sarajärvi, 2009: 151.) Aiheeseen tutustuminen auttaa hahmottamaan muun muassa mistä ja miten kyseisen aiheen omalla alalla keskustellaan ja mitkä olisivat mielekkäitä tutkimusongelmia. Tutustumisen yhteydessä tarkennettiin tutkimukselle asetettuja tavoitteita, jotka koottiin tutkimussuunnitelmaan. Tämän jälkeen tutkimusongelmaa lähdettiin selvittämään lähdekirjallisuuden perusteella. Kysymyksiä tehtiin yhdessä viitekehystä hahmotellessa. Kysymyksiä tarkennettiin teorian avulla. Kohdetapauksiin tutustuttiin dokumentaation perusteella. Dokumentteja käsiteltiin teoriaohjaavalla aineistoanalyysillä. Haastattelupyyntö lähetettiin yhdeksälle etukäteen valitulle henkilölle. Kaikki henkilöt suostuivat haastatteluun Tuomi ja Sarajärvi pitävät haastattelun etuna joustavuutta. Joustavuus ilmenee haastattelutilanteessa, jolloin haastattelijalla on mahdollisuus toistaa kysymys, oikaista väärinkäsitys, selventää ilmausten sanamuotoa sekä käydä keskustelua haastateltavan kanssa. Joustavuutta on myös se että haastattelijalla on mahdollisuus esittää kysymykset siinä järjestyksessä kuin katsotaan aiheelliseksi. Haastattelutilanne ei saa muodostua tietokilpailuksi, joten on perusteltua antaa haastattelukysymykset tai aiheet tiedonantajalle jo etukäteen.\n58 58 Tämä myös lisää haastattelun onnistumista ja haastattelun tarkoituksenahan on saada mahdollisimman paljon tietoa tutkittavasta kohteesta. (Tuomi&Sarajärvi, 2009: 73.) Tämän tutkimuksen haastattelutilanteet pyrittiin pitämään avoimina ja sitä kautta joustavina, jolloin haastateltaville annettiin mahdollisuus tuoda paremmin mielipiteensä esille. Haastattelun runkona toimi etukäteen haastateltaville lähetetty kysymyssarja. (LIITE1.) Laadullisessa tutkimuksessa on erilaisia tekniikoita haastatteluille. Lomake-, teema sekä syvähaastattelulla pystytään tutkimaan erilaisia ilmiöitä ja hakemaan vastauksia erilaisiin tutkimusongelmiin. Jokaisella haastattelumuodolla on erilainen suhde tutkittavaa ilmiöt kuvaavaan teoriaan ja menetelmää perusteleviin oletuksiin. (Tuomio&Sarajärvi, 2009: ) Tässä tutkimuksessa haastattelutilanteet olivat luonteeltaan teemahaastatteluita eli puolistrukturoituja. Teemahaastattelun piirteet ovat lähellä syvähaastattelua. Tässä tutkimuksessa edettiin tiettyjen etukäteen valittujen teemojen ja tarkentavien kysymysten mukaan, joka on teemahaastattelulle ominaista. Teemahaastattelussa halutaan saada selville tiedonantajien tulkintoja valituista teemoista sekä heidän asioilleen antamia merkityksiä ja miten merkityksen syntyvät vuorovaikutuksessa. (Tuomio&Sarajärvi, 2009: ) On selvää, että teemahaastattelutilanteessa ei voi tiedonantajalta kysyä mitä tahansa, vaan tarkoituksena on löytää vastauksia tutkimusongelmiin. Tutkimuksen haastatteluissa otettiin huomioon tutkimuksen viitekehys, joka johdatteli haastattelua. Tuomen ja Sarajärven mukaan periaatteessa etukäteen valitut teemat perustuvat tutkimuksen viitekehykseen eli tutkittavasta ilmiöstä jo tiedettyyn. Jokainen teemahaastattelu on kuitenkin luonteeltaan omanlaisensa. Tutkijan päätettäväksi jää kysytäänkö jokaiselta tiedonantajalta kaikki suunnitellut kysymyksen ja pitääkö kysymykset esittää samassa järjestyksessä. (Tuomi&Sarajärvi, 2009: 75.) Voidaan todeta, että laadullisessa tutkimuksessa ei pyritä tilastollisiin yleistyksiin. Tutkimuksessa pyritään kuvamaan ilmiötä ja ymmärtämään tiettyä toimintaa sekä antamaan teoreettisesti mielekäs tulkinta ilmiölle.\n59 59 On siis tärkeää, että tiedonantajat joilta tietoa kerätään tietävät tutkittavasta ilmiöstä mahdollisimman paljon tai heillä on kokemusta. Laadullisessa tutkimuksessa tiedonantajat valitaan harkinnanvaraisesti ennen haastatteluja. Tarkoitus on saada vertailtavista tapauksista vertailukohteita. (Tuomi&Sarajärvi, 2009: 85; Darke et al., 1998: ) Teemahaastatteluihin valittiin jokaisesta hankinnasta kolme roolia, jotka olivat tilaajan ja toimittajan projektipäälliköt, sekä ohjausryhmän puheenjohtaja. Valinnalla pyrittiin luomaan organisaatiotasolla kolmen eri tahon näkemys kyseiseen hankintaan. Haastattelutilanteet kehotetaan yleensä nauhoittamaan, jotta niitä voidaan käydä läpi useamman kerran, erityisesti ylemmän koulutustason tutkimuksissa. Joskus nauhoittaminen voidaan kokea kiusalliseksi ja näin vaikuttaa haastateltaviin. (Darke et al., 1998: 283.) Tämän tutkimuksen haastattelut nauhoitettiin. Nauhoittamisesta ilmoitettiin haastattelupyynnössä. Ilmoittamalla etukäteen nauhoituksesta oli tarkoitus vähentää nauhoittamisen aiheuttamaa kiusallisuutta. Haastateltaville luvattiin myös että nauhoitukset eivät päädy kolmannen osapuolen haltuun. Haastattelujen aineisto tulee käydä läpi järjestelmällisesti. Läpikäyminen voidaan tehdä litteroimalla tai koodaamalla. (Tuomi&Sarajärvi, 2009: ) Tämän tutkimuksen aineisto koodattiin kysymysten mukaan. Tämän jälkeen aineisto tulisi luokitella, tyypittää tai jakaa teemoihin. (Tuomi&Sarajärvi, 2009: 92.) Kysymykset noudattivat hankintaprosessin eri vaiheita. Aineisto siis jaettiin teemoihin viitekehykset mukaisesti. Haastateltaville kerrottiin myös, että nauhoituksista koottua dokumentoitua aineistoa ei luovuteta kolmansille osapuolille. Lupauksella pyrittiin saavuttamaan haastateltavien luottamus. Tästä johtuen tämän tutkimuksen liitteeksi ei liitetä nauhoituksista koostettua aineistoa. Dokumentoitu aineisto analysoitiin ja siitä poimittiin tutkimuksen kannalta oleelliset asiat, jotka on avattu tarkemmin tuloksia koskevassa luvussa. Joissakin laadullisen tutkimuksen raporteissa analyysin tukena käytetään lainauksia alkuperäisistä haastatteluista. Tuomen ja Sarajärven mukaan tutkijan kannattaa miettiä käyttääkö haastattelujen alkuperäisiä ilmaisuja raportissaan. (Tuomi&Sarajärvi, 2009: 22.) Vapaamuotoisuudesta johtuen tässä tutkimuksessa suoria lainauksia ei nähty tutkimuksena kannalta hyödyllisiksi.\n60 60 Poikkeuksena yksi lainaus, joka kuvastaa tietohallinnon suhtautumista itse määriteltyihin toimintatapoihin. Tutkimuksessa analysoitavat dokumentit voidaan jakaa kahteen luokkaan, yksityisiin dokumentteihin ja joukkotiedotuksen tuotteisiin. (Tuomio&Sarajärvi, 2009.) Tämän tutkimuksen kohdetapauksista tutkittava dokumentaatio oli hankinnan aikana projektiryhmän tuottama dokumentaatio, kuten määrittelydokumentti, seurantaraportit ja projektisuunnitelma. Tässä tutkimuksessa on käytetty teoriaohjaavan sisällönanalyysin piirteitä. Keskeistä on poimiiko tutkija alkuperäisestä aineistosta asioita tai ilmauksia alun alkaenkaan tietyn viitekehyksen mukaan vai lähestyykö hän aineistoa sen omilla ehdoilla ja vasta analyysin edessä pakottaa sen tiettyyn sopivaksi katsomaansa viitekehykseen. (Tuomi&Sarajärvi, 2009: 117.) 5.2. Tutkimuksen luotettavuus Tutkimusraportin luotettavuus on keskeinen asia mietittäväksi tutkijalle. Tuomen ja Sarajärven mukaan tietoisuus itsestä jakaa maailman kahtia subjektiin ja objektiin. Tästä jaosta nousee esille kysymys siitä, kuinka tutkija voi ymmärtää tiedonantajaa eli tässä tutkimuksessa haastateltavaa. (Tuomi&Sarajärvi, 2009: ) Tutkijan subjektiiviset näkemykset vaikuttavat aineiston analyysissa. Tuomen ja Sarajärven mukaan on kyse keksimisen logiikasta ja tutkimuksen tekijän on itse tuotettava analyysinsa viisaus. Jotta tutkimus on luotettava ja uskottava on tutkijan noudatettava laadullisen tutkimuksen metodeja. (Hirsjärvi&Hurme, 2000: 18, 23-24; Tuomi&Sarajärvi, 2009: 100.) Tutkimuksessa on tutkittu sitä kohdetta mitä on luvattu. Tutkimus eteni tutkimussuunnitelman mukaisesti. Myös tutkimusvaiheiden julki tuominen lisää tutkimuksen luotettavuutta. Tutkimuksen vaiheita on kuvattu edellisessä luvussa. (Tuomi&Sarajärvi, 2009: )\n61 61 6. TULOKSET Kohteiden tulokset avataan seuraavaksi omina lukuinaan. Luvuissa esitetään projektin eteneminen ja huomioita aiheuttaneet vaiheet. Ongelmalliset kohdat on nostettu omiksi aliluvuikseen. Lukujen lopussa on yhteenveto, jossa ongelmat tiivistetään muutamaan kappaleeseen. Tulokset perustuvat pääsääntöisesti tutkimuksen aikana tehtyihin haastatteluihin TAPAUS: HÄIRIÖTIETOJÄRJESTELMÄ (Häti) Tarve ja tavoite tuntuivat olevan selkeitä kaikille osapuolille projektin alussa, erityisesti projektipäällikkö ja loppukäyttäjät tiesivät mitä haluttiin. Yhteisen päämäärän löytyminen on tärkeää tietojärjestelmähankinnan kannalta. (Pressman, 2005: 630.) Käytössä ollut tietojärjestelmä ei enää kyennyt palvelemaan käyttäjiä jokapäiväisessä työssä. Hankinta käynnistyi hankintatapa-analyysilla, jonka suoritti ulkopuolinen toimittaja, eri toimittaja kuin toteutuksen tehnyt toimittaja. Analyysissä vertailtiin kolmea eri tapaa hankkia Häti (taulukko 1). Hankintatapoina olivat palveluhankinta, osittaisräätälöinti ja kokonaisräätälöinti. Analyysissa päädyttiin hankkimaan Häti kokonaisräätälöintinä. Analyysi oli tehty kattavasti ja siinä arvioitiin eri riskejä, jotka pisteytettiin. Tiehallinnon projektipäällikkö ja ohjausryhmän puheenjohtaja pitivät hankintatapa-analyysia onnistuneena. Hankintatapa-analyysi ei ollut Tiehallinnon käytännön mukainen toimenpide, koska pääsääntöisesti hankinnat oli tehty noudattaen strategista päätöstä. Tutkimuksessa ei voida ottaa kantaa siihen kuinka hankinta olisi onnistunut muita tapoja käyttämällä. Ottaen huomioon tilanne, jossa tehdään Hätin kaltainen erittäin kohdealuespesifinen tietojärjestelmä, on kokonaisräätälöinnin valitseminen perusteltua. Sopivia ja kaikkia vaatimuksia täyttäviä tietojärjestelmiä ei ollut tarjolla valmiina ratkaisuina. Häti toimii liikennepäivystäjän tärkeimpänä työkaluna työvuoron aikana, jolloin sen käytön on oltava sujuvaa ja häiriötöntä. Hätiltä odotetaan saumatonta toimintaa ympäri vuorokauden.\n62 62 Tehtäessä vaatimusmäärittelyä ei loppukäyttäjiä ollut edustettuna. Oletettiin, että projektipäällikön tuntemus substanssista oli riittävä. Projektipäällikkö tiesi pääpiirteittäin liikennepäivystäjien mielipiteet silloisesta tietojärjestelmästä. Loppukäyttäjän ottaminen mukaan projektiin on suositeltua ja usein voisi sanoa jopa välttämätöntä. (Pressman, 2005: 630.) Projektipäällikön substanssituntemus on projektin onnistumisen kannalta erittäin tärkeää. (Pressman, 2005: ) Pressmanin edellä mainitut huomiot kumoavat tässä tapauksessa toisensa. Tiehallinnon projektipäälliköllä oli riittävä tuntemus kohdejärjestelmästä sekä kohdekäyttäjistä. Projektipäällikkö työskenteli tiiviisti liikennepäivystäjien kanssa, hän tiesi mitä liikennepäivystäjät pitivät käytössä olleesta tietojärjestelmästä. Projektipäällikkö oli saanut kerättyä kohdekäyttäjien uuteen tietojärjestelmään kohdistuneita toivomuksia. Hätiä koskevissa haastatteluissa projektipäällikön asiantuntijuus ja osaaminen tuli esille eri osapuolilta. Tiehallinnon päätös oli ottaa loppukäyttäjät mukaan vasta suunnitteluvaiheessa. Toimittajan mukaan tavoite tarkentui heidän päästessä keskustelemaan loppukäyttäjien kanssa. Käyttötapauskuvausten tai vastaavien dokumenttien sijasta toimittaja tuntui antavan enemmän arvoa keskustelulle liikennepäivystäjien kanssa. Ihanteellinen tilanne olisi ollut, jos liikennepäivystäjät olisivat olleet mukana vaatimusmäärittelyssä. Toimittaja kaipasi kontaktia liikennepäivystäjiin aiemmin eli jo ennen suunnitteluvaihetta. Kilpailutuskäytännön takia se ei ollut mahdollista. Tarjouksen mukana lähtenyt dokumentaatio ei muutenkaan auttanut toimittajaa kovin paljon, koska ICT-ympäristö muuttui ja ohjelman rakenne selvisi vasta keskusteluvaiheessa. Kilpailutus suoritettiin hankintalain ja Tiehallinnon käytäntöjen mukaan koettiin yleisesti ongelmalliseksi sekä toimittajan että tilaajan puolelta. Hankintalaki asettaa kilpailutuksella tarkat säännöt, joiden puitteissa tulee toimia. Säännöt asettavat toimittajat kiusalliseen tilanteeseen, koska heidän on tarjottava juuri sitä mitä tarjouspyynnössä pyydetään. Muuten heillä on riskinä pudota pois kilpailusta. He eivät voi tarjota omaa ratkaisua, jos kokevat tarjouspyynnössä olevan jotain vialla.\n63 63 Toimittajan mukaan laajat tietojärjestelmäprojektit, kuten Häti ovat niin suuria ja monimutkaisia ratkaisuja ettei niitä pysty hallitsemaan päässä tai paperilla, jolloin yhteistyö alusta alkaen on erityisen tärkeää. Toimittaja tarjosi sen mitä tilaaja pyysi, vaikka tiedosti tarjouksessa esitetyn toteutustavan saavuttamisen vaikeuden sen aikaisella tekniikalla. Tilaajan vaatimuksista kuitenkin puuttui asioita jotka tehtiin lisätöinä. Sekä Tiehallinnon projektipäällikkö että toimittajan projektipäällikkö ovat sitä mieltä, että lisätyöt olivat tarpeellisia. Tiehallinnon projektipäällikön mukaan toimitettu vaatimusmäärittely oli hyvin pitkälti lista niistä toiminnoista jotka haluttiin parantaa verrattuna silloiseen tietojärjestelmään. Vaatimusmäärittely ei kuitenkaan sisältänyt tarpeeksi kattavasti niitä toiminnallisuuksia, jotka silloisessa tietojärjestelmässä olivat todettu toimiviksi. Toisin sanoen Tiehallinnon tekemä vaatimusmäärittely oli lista parannuksista. Se ei ollut määrittelydokumentti, jossa aloitettaisiin tyhjältä pöydältä ja suunniteltaisiin tietojärjestelmä. Tiehallinnon puolella oletettiin, että valitulla toimittajalla oli hyvä tuntemus Tiehallinnon ympäristöstä. Toimittajalla oli kokemusta Tiehallinnon kanssa toimimisesta useamman projektin ajalta. Kokemus Tiehallinnon kanssa oli varmasti suureksi avuksi toimittajalle, mutta se yksistään ei voi sulkea pois vaatimusmäärittelyn tarpeellisuutta. Toimittajan kanta vaatimusmäärittelyyn oli selkeä, se ei ollut tarpeeksi kattava. Toimittajan mukaan: Jos lisätyöt olisivat jäänet tekemättä, toteutus ei olisi vastannut tarvetta. Toisaalta toimittaja painotti myös sitä, että jos haluaa saada kaiken kattavan vaatimusmäärittelyn, se vie paljon aikaa ja työtä. Vaikka vaatimusmäärittelyä tehtäisiin pitkään ja hartaasti ei se välttämättä silloinkaan antaisi vastauksia kaikkiin tietojärjestelmää koskeviin ongelmatilanteisiin. Erityisesti tästä syystä toimittajan mielestä suurissa tietojärjestelmähankkeissa tulisi siirtyä ketterään menetelmään, toteutustavasta riippumatta. Vesiputousmallin mukaisesti toteutettu tietojärjestelmähanke on hyvin riippuvainen vaatimusmäärittelystä.\n64 64 Toimittajan puolella uskotaan ketterän menetelmän tuomiin etuihin, koska silloin edetään pieninä tehtäväkokonaisuuksina kohti tavoitetta, eikä haukata vesiputousmenetelmän mukaisesti suurta kokonaisuutta. Toimittajalla oli ketterästä menetelmästä hyviä kokemuksia muilta asiakkailta. Ketterän menetelmän hyötyjä ei kuitenkaan voida saavuttaa sataprosenttisesti Tiehallinnossa, koska menetelmän ideana on se, että työryhmät ovat mukana tekemässä alusta alkaen. Hankintalain takia se on mahdotonta. Menetelmän hyödyntämistä haittaa myös Tiehallinnon kankea hyväksymiskäytäntö, jossa nopeat päätökset eivät ole mahdollisia. Vesiputousmenetelmä Määrittely Suunnittelu Toteutus Testaus Käyttöönotto Ketterä menetelmä Määrittely Määrittely Määrittely Määrittely Suunnittelu Suunnittelu Suunnittelu Suunnittelu Käyttöönotto Toteutus Toteutus Toteutus Toteutus Testaus Testaus Testaus Testaus Kuva 17: Ketterän menetelmän ja vesiputousmenetelmän rakenteellinen ero. Toteutusvaihe eteni toimittajan projektiryhmälle esittelemän ketterän menetelmän mukaan. Kokemuksia ketterästä menetelmästä ei Tiehallinnossa ollut. Toimittajan esittämä ketterä menetelmä sitoo käytännössä suunnittelun, toteutuksen ja testaamisen yhteen sprintiksi. (Sommerville, 2001: 52; Pressman, 2005: ) Toimittaja järjesti pienimuotoisen koulutustilaisuuden ketterästä menetelmästä. Tiehallinnon projektipäällikön mukaan ketterä menetelmä oli jälkeenpäin ajatellen positiivinen kokemus, jonka tuoma etu oli se, että ensimmäinen versio tietojärjestelmästä oli hyvin nopeasti saatavilla jo ensimmäisen sprintin jälkeen. Ketterän menetelmän mukaiset sprintit aiheuttivat kuitenkin ongelmia Tiehallinnossa.\n65 65 Toimittajan mukaan sprintin normaali kesto olisi noin 2-3 viikkoa, mutta tämä aikamääre ei ollut mahdollinen Tiehallinnon kanssa. Sprintin pituudeksi tuli noin kuusi viikkoa. Testaajat eivät pystyneet testaamaan tarpeeksi tiheästi ja päätökset etenemisestä kestivät liian pitkään. Projektille palkattu ulkopuolinen testausapu ei tuonut toivottuja tuloksia, koska testaaja ei päässyt testaamaan vähäisten testityöasemien takia. Testaamisen vähyys hankaloitti ketterän menetelmän käyttöä, koska testaustulokset antavat suunnan seuraavalle sprintille. Tiehallinnon projektipäällikkö testasi pääasiassa itse sprinttien aikana, joka poikkesi alkuperäisestä suunnitelmasta, koska testaustoteutus-vaiheessa oli tarkoitus olla kolme liikennepäivystäjää mukaan. Testaamisen vähyyteen vaikutti olennaisesti suunnitteluvaiheessa vaihdettu toteutustapa, jota käsitellään seuraavaksi. Tarjouksen hyväksymisen jälkeen toimittaja ilmoitti ensimmäisessä yhteisessä suunnittelukokouksessa, ettei tarjouksessa esitetty www-pohjainen toteutus olisi mahdollista, vaan se olisi parempi toteuttaa client-ratkaisulla. Perimmäisenä syynä tähän esitettiin www-pohjaisen toteutuksen kyvyttömyyttä saavuttaa toivottuja vasteaikoja. Clientpohjainen toteutus ei ollut tuettu ratkaisu Tiehallinnossa ja se aiheutti useita ongelmia. Työasemaympäristö, johon client-ratkaisu tuli asentaa oli käytännössä jäädytetty muutoksilta. Tiehallinnossa pyrittiin tuottamaan palvelut www-pohjaisina yhdeltä yhteiseltä palvelualustalta KOKA:lta, joka tosin tässä vaiheessa oli vasta osittain valmis tai sen muutoksenhallintaa ei ollut tarpeeksi hyvin avattu kehittäjille. www client Selain Client Kuva 18: WWW - Client toteutus. Kuvan 18 mukaan toteutustavat näyttävät olevan samanlaisia. Todellisuudessa tilanne oli hyvin erilainen.\n66 66 Tiehallinnon työasemissa oli jo entuudestaan selain, joten työasemaan ei olisi tarvinnut tehdä mitään muutoksia. Myös alusta www-palvelujen tuottamiseen oli valmisteilla ja joiltakin osilta jo valmis. Käyttöönottovaiheessa käyttäjille olisi kerrottu URL-osoite, josta uusi palvelu löytyisi ja käyttö olisi voitu aloittaa. Toimittajan ehdottamassa client-pohjaisessa ratkaisussa työasemaan asennettiin client-sovellus, joka oli toimittajan räätälöimä. Client-sovellus keskustelee palvelimella olevan server-sovelluksen kanssa. Tiehallinnon työasemaympäristö ei ollut aluksi sopiva clientille, vaan siihen jouduttiin tekemään muutoksia, joita ei ollut sovitettu muuhun tietohallinnon toimintaan. Toisin sanoen muutokset vaativat osallistumista, johon ei ollut varauduttu, koska Hätin piti olla www-pohjainen. Clientin saaminen työasemaan kesti kauan ja hidasti projektia. Pääasiassa client-ongelmien takia toimittajalle tarjottiin vain yksi testityöasema, johon he saivat etäyhteyden. Työasema oli monilta osin puutteellinen siihen nähden, minkälaisessa työasemassa client-sovelluksen tulisi toimia. Samat syyt aiheuttivat ongelmia liikennepäivystäjille, joiden oli tarkoitus toimia testaajina vuorotyönsä ohessa. Liikennepäivystäjien piti alkuperäisen suunnitelman mukaan saada testisovellus työasemiinsa, mutta näin ei kuitenkaan tapahtunut. Liikennepäivystäjien olisi pitänyt käydä vuorotyön ohessa fyysisesti eri paikassa sijainneella testiasemalla testaamassa testisovellusta. Tämä ei onnistunut ja testauspalaute jäi saamatta. Testaamisen hoiti Tiehallinnon projektipäällikkö, jolla oli tarpeeksi substanssiosaamista, jotta hän pystyi toteamaan sovelluksen toimivuuden. Projektipäällikön suorittamat testaukset olivat tärkeitä, mutta niissä oli yksi ongelma, hänellä oli erilaiset oikeudet niin työasemaan kuin myös sovellukseen. Nämä eroavaisuudet liikennepäivystäjään verrattuna aiheuttivat lisää ongelmia testausvaiheessa. Muutenkin hankala testiympäristö kärsi yhdestä merkittävästä puutteesta, testityöasemalla ei ollut mahdollisuutta testata sen toimimista VoIP-järjestelmän kanssa. Toimittaja sai kuitenkin tietoonsa rajapintatiedot, joiden mukaan liittymä voitiin ohjelmoida. Liittymä ei toiminut kuitenkaan ensimmäisellä yrityksellä.\n67 67 Kun liittymä saatiin toimimaan, siinä esiintyi kiusallinen hiljainen hetki, jolloin päivystysnumeroon soittanut henkilö ei kuullut mitä liikennepäivystäjä sanoi. Ongelmaksi muodostui myös testiympäristönä toimineentyöaseman näytönohjain. Työasema oli varustettu erilaisella näytönohjaimella kuin liikennepäivystäjien käyttämät työasemat. Liikennepäivystäjät käyttävät neljää näyttöä tukevia näytönohjaimia, jota ei ollut asennettu testityöasemaan. Testiympäristö aiheutti ongelmia niin testaajille kuin myös sovelluskehittäjälle. Ketterää menetelmää hyödyntävä projekti on tiukasti sidoksissa testausvaiheeseen ja erityisesti siitä saatuihin palautteisiin. Toteutusvaihetta varjosti Tiehallinnon muut intressit, jotka ajoivat Häti-projektin edelle. Samaan aikaan Hätin kanssa Tiehallinnolla oli menossa suuri tiehanke, jossa toteutettiin tunneliosuuksia Helsingin ja Turun väliselle E-18 moottoritielle. E-18 hankkeeseen kuului tunneleiden valvontateknologian rakentaminen ja käyttöönotto. Tunneleiden hallintajärjestelmillä on rajapintayhteys SONJA-viestinvälityslaitteeseen, jota myös Häti hyödyntää. E-18 hanke asetettiin etusijalle ja työpanos kohdistettiin tälle projektille, jolloin Hätin osalta SONJA:n tehtävät rajapinnat siirtyivät toteutettavaksi myöhemmin. Käyttöönottovaihe siirtyi huomattavasti, koska E18-hankkeen tuoma viivästys siirsi Hätin käyttöönoton aikataulu. Yleensä talvikaudella ei tehdä suuria muutoksia järjestelmiin, koska tietojärjestelmien on toimittava. Talvikausi on tieliikennekeskuksessa kriittisin vuodenaika lumi- ja jääolosuhteiden takia. Liikennekeskuksen tietojärjestelmien avulla ohjataan muun muassa tieverkon kunnossapitoa, kuten esimerkiksi auraamista. Kesällä vastaavia vuodenajan tuomia vaatimuksia ei ole. Hätin käyttöönottoa siirrettiin E18-hankkeen ja talvikauden takia keväälle. Käyttöönottovaiheessa ilmeni muutama virhe, jotka kaatoivat koko tietojärjestelmän. Virheistä päästiin eroon ja tietojärjestelmä saatiin käyttöön, jonka jälkeen käyttäjät ovat olleet tyytyväisiä uuteen häiriötietojärjestelmään.\n68 Projektityöskentely Työskentely Häti-projektissa onnistui pääsääntöisesti hyvin, vaikka mukana oli Tiehallinnon, käyttöpalvelutoimittajan ja kilpailutuksen voittaneen toimittajan lisäksi neljäs osapuoli(sonja). Ongelmatilanteissa keskusteltiin usein siitä kenen vastuulle jokin tietty tehtävä kuului, joka johti siihen, että vastuiden jakaminen oli välillä työlästä. Pääsääntöisesti vastuut oli jaettu projektin alussa, mutta sen aikana tehtävien vastuita siirreltiin henkilöltä toiselle. Tiehallinnon projektipäällikkö joutui toimimaan tehtävässä käytännössään yksin, huolimatta siitä, että projektin aluksi mukaan oli nimetty useampi testaaja. Tietohallinnon tukea olisi kaivattu enemmän, koska työasemaympäristöstä ei ollut projektiryhmän mukaan tarpeeksi selkeitä ohjeita. Projektia tuki Tiehallinnon tietohallinnon asiantuntija, mutta muiden työtehtäviensä takia hän ei pystynyt osallistumaan kokouksiin niin usein kuin olisi ollut tarpeellista. Toisaalta alkuperäinen suunnitelma oli toteuttaa Häti Tiehallinnon suosiman www-pohjaisen toteutustavan mukaisesti, eikä client-pohjaisena, johon Tiehallinnossa ei ollut varauduttu. Työskentelyyn vaikutti suuresti toimittajan suosima ketterä menetelmä, joka on todettu hyväksi keinoksi kehittää suuria tietojärjestelmiä. Tiehallinnossa ketterää menetelmää ei ollut käytetty. Tiehallinnon projektipäällikön mukaan Tiehallinnossa ei ollut järjestetty koulutusta ketterään menetelmään. Projektiin lähdettiin toimittajan järjestämän tietoiskun voimin. Ketterän menetelmän edut tulivat tietoiskussa esille. Edut koettiin Tiehallinnon puolella hyviksi ja ketterää menetelmää pidettiin hyvänä ratkaisuna. Tiehallinnon projektiryhmäläisille tilaajan vastuu ketterässä menetelmässä oli jäänyt epäselväksi. Erityisesti nopea testaus- ja palautesykli yllätti tilaajan. Tämä osittain vaikutti siihen, että syklien eli sprinttien kesto piteni toimittajan suosittelemasta 2-3 viikosta noin kuuteen viikkoon.\n69 69 Sprintin venyminen heikensi hieman ketterän menetelmän tuomia etuja, mutta tilaajapuoli oli silti pääosin tyytyväinen niihin etuihin joita ketterässä menetelmässä oli. Suurena etuna pidettiin sitä, että ensimmäinen testiversio saatiin hyvin nopeasti nähtäville ja projektiryhmässä päästiin keskustelemaan siitä, oliko toimittaja ymmärtänyt Tiehallinnon tavoitteet oikein. Projektin aikana tuotettava dokumentaatio on noussut ongelmaksi, erityisesti projektin lopussa ja sen jälkeen. Tiehallinnon projektipäällikkö kertoi haastattelussa, että kaikkia sovittuja dokumentteja ei ole toimitettu vieläkään. Toimitetuissa dokumenteissa on todettu olevan puutteita tai joitakin kohtia on pyydetty tarkentamaan. Toimittajan näkökulma asiaan on se, etteivät he täysin tiedä mitä Tiehallinto haluaa vaikka heille olisikin toimitettu haluttujen eri dokumenttien pohjat. Toimittajan mielestä heillä ei ole edes mahdollisuutta vastata kaikkiin dokumenttien kohtiin, koska eivät ole olleet kyseisestä kohdasta vastuussa projektin aikana. Ketterä menetelmä ei tässä tapauksessa yltänyt dokumentaatiovaiheeseen vaan se jäi toimittajan tehtäväksi, jolla ei ole mahdollisuutta täyttää dokumenttia. Toimittajan mukaan heidän sitoutumisensa projektiin oli hyvä, vaikka aikataulu muuttuikin useita kertoja. Myös tilaajan puolella oltiin projektipäällikön mukaan sitoutuneita. Sitoutumista heikensi tilaajan puolella kuitenkin se, että henkilöiden aikataulut eivät sopineet Häti-projektin kanssa yhteen. Poikkeus sitoutumisessa oli testaajat, jotka käytännössä luopuivat testaamisesta lähes heti ensimmäisten testauspyyntöjen jälkeen. Projektipäällikön lisäksi yksi henkilö suoritti testauksia. Testaajilla oli kuitenkin omat työnsä hoidettavanaan ja alkuperäisen suunnitelman mukaan heidän piti saada Hätin testiversio käyttämiinsä työasemiin. Joten testaamisen kannalta projektipäällikön rooli vahvistui yhä enemmän, koska käytännössä hän hoiti testaamisen.\n70 Koulutus ja käyttöönotto Koulutus kuului tarjouspyyntöön, mutta toimittajan lähettämässä tarjouksessa sitä ei ollut huomioitu. Koulutuksen kuuluessa tarjouspyyntöön on toimittajan järjestettävä se. Koulutus järjestettiin ennen oletettua käyttöönottoa, talvikauden jälkeen. Koulutuskertoja järjestettiin kuusi eri kertaa, johtuen liikennepäivystäjien vuorotyöstä. Koulutus oli sinällään hyvin järjestetty, koska koulutuskertoja lisättiin, jotta kaikki saivat koulutuksen. Koulutusta hankaloitti kuitenkin se, ettei liikennekeskuksella ollut käytössään koulutustilaisuuteen sopivaa huonetta. Eikä Liikennepäivystäjillä ollut käytössään kannettavia tietokoneita, vaan he työskentelivät pöytätietokoneilla. Pöytätietokoneet olivat vuorossa olevien päivystäjien käytössä, joten näitä ei voitu käyttää koulutuksessa. Koulutusluokka jouduttiin hankkimaan toimittajalta erikseen, koska sitä ei ollut mainittu tarjouspyynnössä. Viivästys (E-18) tietojärjestelmän käyttöönotossa aiheutti sen, että järjestetty koulutus järjestettiin liian aikaisin. Tiehallinnon projektipäällikkö joutui pitämään uuden koulutustilaisuuden vähän ennen lopullista käyttöönottoa Yhteenveto:HÄTI Häiriötietojärjestelmä Tavoite: Riippuvuudet: Tekninen toteutus: Prosessimenetelmä: Onnistuneet kohdat: Onnistumista vaikeuttaneet kohdat: Taulukko 1: Häiriötietojärjestelmän esittely. Tuottaa tietojärjestelmä vanhentuneen tietojärjestelmän tilalle. Paikkatietojärjestelmä, SONJA(viestinvälitys), VoIP(puhelin), joukko muita tietojärjestelmiä Kokonaisräätälöinti Sekoitus vesiputousta ja ketterää menetelmää. Tilaajan asiantunteva projektipäällikkö, ketterä menetelmä (niiltä osin kuin sitä pystyttiin hyödyntämään) Testiympäristö, testaaminen, suunnitteluvaiheen muutos (www client), tilaajan kyky mukautua ketterän menetelmän sprinttikäytäntöön. Häiriötietojärjestelmä (taulukko 1) saatiin käyttöön viivästymisten jälkeen. Käyttäjät ovat olleet tyytyväisiä tietojärjestelmään sen jälkeen kun käyttöönotossa havaitut virheet korjattiin. Projektia voidaan pitää onnistuneena, koska käyttäjät eivät olleet halukkaita vaihtamaan takaisin vanhaan tietojärjestelmään.\n71 71 Osittain syynä siihen, että käyttäjien palaute oli positiivista, on se, että viivästymiset mahdollistivat toimittajan parantamaan tietojärjestelmää lisätöillä. Lisätöillä tietojärjestelmä saatiin vastaamaan paremmin asetettuja tavoitteita. Kuva 19: Häiriötietojärjestelmän hankintaan kohdistuneet ongelmat. Kuvassa 19 on esitetty Häiriötietojärjestelmän hankinnassa esiintyneet kohdat, jotka aiheuttivat ongelmia hankinnan aikana. Ketterä menetelmä sai kehuja Tiehallinnon projektipäälliköltä, vaikka sitä ei voitukaan hyödyntää täysin. Erityisesti ensimmäisen testausversion syntyminen nopeasti koettiin hyväksi, huolimatta siitä, ettei sen testaaminen onnistunut niin kuin oli ajateltu. Kuitenkin projektiryhmä pääsi näkemään jotain valmista huomattavan aikaisin. Toimittajan mukaan Tiehallinnon työntekijöitä on helpompi sitouttaa projektiin, kun he saavat jo aikaisessa vaiheessa jotain konkreettisia tuloksia nähtäville. Client-sovellus aiheutti monenlaisia ongelmia, jotka vaikuttivat testaamiseen ja tietojärjestelmän valmistumiseen. Toimittajan mukaan www-pohjainen toteutus ei olisi välttämättä vieläkään mahdollista jos tavoitteena ovat vasteajat joita Hätiltä vaadittiin. Toimittaja epäili hieman oliko tavoiteaikavaatimukset realistisia vai perustuivatko ne toiveeseen. Hankintaan vaikutti E18-tiehanke, jonka vaikutusta oli lähes mahdotonta arvioida ennen hankinnan aloittamista. Päätös siirtää käyttöönotto talvikauden takia oli projektin aikataulun kannalta huono ratkaisu, mutta liikennekeskuksen toiminnan kannalta todennäköisesti ainoa oikea ratkaisu. Se myös mahdollisti tietojärjestelmän kehittämisen.