Susanna Koskinen 

Henkilöstötietojärjestelmän hankinnan 
päätöksentekoprosessi 

Tietojärjestelmän ja järjestelmäkumppanin valintaan vaikuttavat tekijät 

 

 

 

 

 

 

 
  

Vaasa 2020 

Tekniikan ja innovaatiojohtami-
sen yksikkö 

Tietojärjestelmätieteen pro 
gradu -tutkielma  

Teknisen viestinnän koulutus-
ohjelma 



2 

 

VAASAN YLIOPISTO 
Tekniikan ja innovaatiojohtamisen yksikkö 

Tekijä: Susanna Koskinen 
Tutkielman nimi: Henkilöstötietojärjestelmän hankinnan päätöksentekoprosessi: Tie-

tojärjestelmän ja järjestelmäkumppanin valintaan vaikuttavat teki-
jät 

Tutkinto: Kauppatieteiden maisteri 
Oppiaine: Tietojärjestelmätiede 
Työn ohjaajat: Tiina Koskelainen, Tero Vartiainen 
Valmistumisvuosi: 2020 Sivumäärä: 95 

TIIVISTELMÄ : 
Organisaatiot tekevät päätöksiä investoida tietojärjestelmiin hyvin säännöllisesti. Päätökset voi-
vat syntyä nopeasti ongelman huomaamisesta ja vaihtoehtojen tutkimisesta suoraviivaiseen rat-
kaisun valintaan, tai päätöstä voivat edeltää laaja haku, seulonta, ratkaisun muotoilu sekä neu-
vottelut, jotka saattavat kestää vuosia. Tämän tutkimuksen tavoitteena oli selvittää, minkälaista 
päätöksentekoprosessia suomalaiset keskisuuret ja suuret organisaatiot käyttävät valitessaan 
henkilöstötietojärjestelmää. Tutkimuksessa kartoitetaan mitkä roolit osallistuvat päätöksenteko-
prosessiin ja miten hankinnan kriteerit määritellään. Tutkimus toteutettiin laadullisena tutkimuk-
sena ja tutkimusaineisto kerättiin kasvotusten tai Skypen välityksellä teemahaastattelun avulla. 
Haastattelut etenivät etukäteen jäsennettyjen teemojen mukaisesti. Teemahaastattelun osallis-
tujat edustivat suomalaisten keskisuurten ja suurten organisaatioita, joissa on lähivuosina tehty 
hankintapäätös henkilöstöjärjestelmästä. Haastateltavat ovat toimineet keskeisessä roolissa 
henkilöstöjärjestelmän hankinnan päätöksentekoprosessissa ja edustavat joko henkilöstö- tai IT-
osastoa. Aineisto analysoitiin fenomenologisella tutkimusotteella, jonka mukaisesti aineistossa 
esille nousseet haastateltavien käsitykset esitettiin erilaisten luokitteluiden muodossa. Teema-
haastattelun ja fenomenologisen tutkimusmenetelmän avulla pystyttiin tunnistamaan haastatel-
tavien näkemyksiä siitä, mitkä henkilöstöjärjestelmän hankintaprosessin vaiheet, roolit ja kritee-
rit nousevat merkittävimmiksi tekijöiksi uutta henkilöstöjärjestelmää hankittaessa ja miten hen-
kilöstöjärjestelmän hankinnassa päädyttiin tiettyyn järjestelmään ja järjestelmäkumppaniin. Tut-
kimuksessa henkilöstöjärjestelmän hankintaprosessin tärkeimmäksi vaiheeksi nousi liiketoimin-
tatarpeen ja kriteeristön määrittely. Tutkimuksen kohteena olleissa organisaatioissa järjestelmä-
prosessit noudattivat pääpiirteittäin samoja vaiheita ja tiettyyn järjestelmään ja toimittajaan 
päädyttiin usean eri vaiheen ja karsinnan jälkeen. Tutkimuksen tulokset osoittavat, että yksittäis-
ten hankintaorganisaatiossa mukana olevien ihmisten rooli ja heidän luottamuksensa järjestel-
mään sekä sen toimittajaan ovat tärkeitä tekijöitä henkilöstöjärjestelmän hankintapäätöksissä. 
Avainrooleissa hankintapäätöksenteossa ovat henkilöstöjärjestelmästä organisaation johdolle 
vastaavat henkilöt, organisaatiosta riippuen henkilöstöhallinnon tai IT-järjestelmien johtajat. 
Hankintaprosessissa käytetään päätöksenteon tukena kriteerejä, joiden avulla järjestelmä- ja toi-
mittajakandidaatit pisteytetään ja näiden sopivuutta arvioidaan. Markkinoiden johtavat henki-
löstöjärjestelmäratkaisut vastaavat asiakasorganisaatioiden vaatimuskriteeristöjä usein yhtä hy-
vin, jolloin lopullinen päätös on hankintaorganisaation preferenssin varassa. Tutkimuksen tulok-
set osoittavat, että järjestelmätoimittajien kannattaa keskittyä luomaan luottamuksellinen suhde 
hankintaorganisaation avainhenkilöiden kanssa.     
 

 

AVAINSANAT: Henkilöstötietojärjestelmä, tietojärjestelmähankintaprosessi, päätöksenteko-
prosessi, projektin hankinnan hallinta 

  



3 

 

Sisällys 

1 Johdanto 6 

2 Henkilöstötietojärjestelmät 9 

3 Päätöksentekoprosessin vaiheet 12 

3.1 Tietojärjestelmähankinnan taustat ja syyt 12 

3.2 Päätöksentekoprosessi 17 

3.3 Valintaprosessi 22 

3.4 Hankintaprosessi 28 

4 Projektin hankinnan hallinta 35 

4.1 Projektin hankinnan vaiheet ja hallinta 35 

4.1.1 Hankintaorganisaatio 40 

4.1.2 Toimittajan ja kumppanin rooli tietojärjestelmähankkeissa 44 

4.2 Hankintasuunnitelma 46 

5 Tutkimuksen suorittaminen 48 

5.1 Tutkimuksen tavoite 48 

5.2 Tutkimusmenetelmä 49 

5.3 Teoreettinen viitekehys 52 

5.4 Aineistonkeruu 53 

5.5 Aineiston analysointi ja vertaaminen 56 

6 Tutkimustulokset 60 

6.1 Henkilöstötietojärjestelmän hankinta käytännössä 60 

6.2 Henkilöstötietojärjestelmän hankintaprosessin vaiheet   65 

6.3 Päätöksentekoon vaikuttavat tekijät 70 

7 Pohdinta ja johtopäätökset 76 

7.1 Henkilöstötietojärjestelmän hankinta 76 

7.2 Miten henkilöstöjärjestelmän hankinnassa päädytään tiettyyn järjestelmään ja 

järjestelmäkumppaniin 77 

7.3 Päätöksentekoprosessin vaiheet 80 

7.4 Roolit päätöksenteossa 82 



4 

 

7.5 Hankinnan kriteerien määrittely 84 

8 Yhteenveto 86 

Lähteet 89 

Liitteet 93 

Liite 1. Teemahaastattelun kysymykset 93 

 

  



5 

 

 
 

Kuviot 
 
Kuvio 1. Hankintaprosessin yleiskuva (Moe 2014 : 1324).                                              30 

Kuvio 2. Tutkimuksen suorittaminen.                                                                                  49 

Kuvio 3. Teema-alueiden paikka tutkimuskokonaisuudessa (Hirsijärvi & Hurme 2000: 67). 

                                                                                                                                             57 

Kuvio 4. Henkilöstöjärjestelmän hankintaprosessin vaiheet.                                                 81                                

 

 

Taulukot 
 
Taulukko 1. Tietojärjestelmän valintaan vaikuttavat päätöksentekoprosessit. (Boonstra 

& Offenbeek 2018: 908). 24 

Taulukko 2. Haastattelututkimuksen kohteet. 54 

Taulukko 3. Tuote, ihmiset, budjetti. 73 

 

 
 
 
  



6 

 

1 Johdanto 

Organisaatiot tekevät päätöksiä investoida tietojärjestelmiin hyvin säännöllisesti. Pää-

tökset voivat syntyä hyvinkin nopeasti ongelman huomaamisesta ja vaihtoehtojen tutki-

misesta suoraviivaiseen ratkaisun valintaan, tai päätöstä voivat edeltää laaja haku, seu-

lonta, ratkaisun muotoilu sekä neuvottelut, jotka saattavat kestää vuosia. Prosessista, 

jolla organisaatiot ja niiden johto päättävät tietojärjestelmien kehittämisestä, ei ole vielä 

2000-luvun alussa tehty hirveästi täsmällistä tutkimusta.  (Boonstra 2003: 195). 

 

Koska vain harvat yritykset ja julkiset yksiköt kehittävät edelleen omaa ohjelmistoa, han-

kinnoista on tullut yleisin tapa hankkia tietojärjestelmiä (IS). Näiden järjestelmien han-

kinta on kuitenkin erittäin monimutkainen prosessi. Tietojärjestelmät kattavat hyvin eri-

laiset järjestelmät, jotka vaihtelevat paketista yleisestä toimisto-ohjelmistosta erikoistu-

neisiin järjestelmiin, kuten julkisiin sosiaalipalveluihin. Merkittäviä haasteita syntyy suu-

rempien ja erikoistuneempien järjestelmien hankinnassa, kuten haasteiden määrittämi-

sessä ennen tarjousten ilmoittamista ja kilpailevien järjestelmien vertailua. Ne johtuvat 

siitä, että hankintayksiköt ostavat tavaroita, joita he eivät ole ostaneet ennen tai ainakin 

viimeisten 4-5 vuoden aikana. Prosessi aiheuttaa sen riskin, että hankintayksiköt voivat 

määritellä väärät ominaisuudet ja toiminnallisuudet ja että he voivat jättää käyttämättä 

uusia toimintoja, joita he eivät ehkä tiedä. Uudet tietojärjestelmät vaikuttavat käyttäjien 

prosesseihin ja työn sisältöön; näin ollen niiden panos on välttämätöntä vaatimusten 

määrittämiseksi ja oikean järjestelmän valitsemiseksi. IS-hankintoja koskeva tutkimus 

voisi edistää tietämystämme antamalla selvityksen vaatimusmäärittelyprosessista sekä 

käyttäjien osallistumisesta ja eri sidosryhmien etujen hallinnasta hankintaprosessissa. 

(Moe 2014: 1320).  

 

Espoon kaupungin satoja miljoonia maksaneesta ja epäonnistuneesta tietojärjestelmä-

hankkeesta on uutisoitu tiuhaan syksyllä 2018 muun muassa Helsingin Sanomissa. Kau-

punki osti tietojärjestelmän Kuntien Tieralta, josta se omistaa itse osan. Tietojärjestelmä 

ei sopinut kaupungin organisaatiorakenteeseen, sillä se on alun perin rakennettu tuke-

maan perinteisten yritysten liiketoimintaa. Lisäksi kaupungin edustaja myönsi, että 



7 

 

järjestelmän tiedettiin olevan jo ostettaessa osittain vanhentunut. (Kuokkanen 2018; 

Moilanen & Salomaa 2018).   

 

Tietojärjestelmäprojektit päätyvät otsikoihin usein vain silloin, kun ne epäonnistuvat. 

Tämä johtunee siitä, että tietojärjestelmien tarkoitus on olla organisaatioiden ja ihmisten 

elämää helpottava taustavoima. Järjestelmät herättävätkin huomiota usein vasta silloin, 

kun niiden toiminta takkuaa tai niissä on jokin vika. Siksi on tärkeä tietää, mitä tietojär-

jestelmää hankittaessa kannattaa ottaa huomioon ja tiedostaa, mitkä eri tekijät vaikut-

tavat onnistuneeseen päätöksentekoprosessiin.  

 

Boonstra (2003: 195) esittää, että tietojärjestelmähankinnoista päättävien tahojen tulisi 

olla tietoisia päätöksentekoon vaikuttavista eri tekijöistä, jotta he voivat suunnitella pää-

töksentekoprosessin, joka sopii parhaiten juuri tiettyihin olosuhteisiin. Yhtäkään päätök-

sentekoprosessia ei voida pitää universaalisti toimivana, sillä päätökseen vaikuttavat mo-

net eri tekijät, jotka vaihtelevat tilanteesta riippuen.  

 

Tietojärjestelmäpäätös on päätös investoida, tai vastaavasti päätös olla investoimatta, 

uuteen tietojärjestelmään. Tavallinen tietojärjestelmän ylläpito tai pienet muutokset val-

miiseen järjestelmään eivät kuulu siis tässä tutkimuksessa tietojärjestelmäpäätöksen 

alueeseen. (Boonstra 2003: 196).  

 

Tässä tutkimuksessa käsitellään henkilöstöjärjestelmän hankintaan vaikuttavia tekijöitä, 

rooleja, sidosryhmiä ja sitä prosessia, jolla hankintapäätös tehdään. Vaikka jokaisen or-

ganisaation päätöksentekoprosessi on erilainen ja voi vaihdella myös organisaation si-

sällä, jokaisesta prosessista löytyy samoja tiettyjä tekijöitä. Boonstra (2003: 206) on mää-

ritellyt nämä tekijät seuraavissa kysymyksissä: sisältyykö projektin laajuuteen ratkaisun 

suunnittelu (valmiiksi tehty, muokattu vai räätälöity); täytyykö erilaisia tietojärjestelmä-

vaihtoehtoja etsiä (yksi, muutama vai monta vaihtoehtoa); kiireellisyyden ja välttämät-

tömyyden aste päätöksentekijöiden näkökulmasta (kriisi, ongelma, mahdollisuus); voi-

daanko tietojärjestelmäpäätös jakaa noudattamaan asteittaisempia prosessireittejä 



8 

 

(suunniteltu vs. inkrementaalinen(vähitellen lisääntyvä)); onko suunta epäselvä; sidos-

ryhmien määrä, vaikutusvalta ja missä määrin heidän intressinsä vaihtelevat ja eroavat 

toisistaan.  

  

Projektin hankinnan hallinta, eli project procurement management, liittyy erityisesti tie-

tojärjestelmäprojektien elinkaaren alkuvaiheeseen. Siihen kuuluvat vaatimusten analy-

sointi, projektin määrittely, suunnittelu ja valmistelu. Projektin hankinta sisältää tavaroi-

den tai palveluiden ostamisen parhaalla mahdollisella kustannushyötysuhteella. (Jing-

chun, Rong & Song, 1: 2009). Tehtyä hankintaa on kuitenkin syytä arvoidan myös projek-

tin aikana ja vielä projektin jälkeen, samassa yhteydessä, kun arvioidaan projektin onnis-

tumista kokonaisvaltaisesti. Projektia voidaan pitää onnistuneena toimittajankin kan-

nalta vain siinä tapauksessa, että projektille asetetut vaatimukset on saavutettu ja tieto-

järjestelmähankinnan tehnyt organisaatio on lopputulokseen tyytyväinen.  

 

 

 



9 

 

2 Henkilöstötietojärjestelmät 

Henkilöstötietojärjestelmä, englanniksi Human Resource Information System eli HRIS, on 

käytetyin ohjelmisto HR:n alalla. Henkilöstötietojärjestelmää käytetään keräämään ja 

säilyttämään tietoja organisaation työntekijöistä. Useimmiten järjestelmä kattaa ne pe-

rustoiminnot, joita tarvitaan henkilöstön ja heidän työsuhteensa kokonaisvaltaiseen hal-

lintaan. Järjestelmä toimii paikkana, josta sekä yrityksen HR, johto, esimiehet ja työnte-

kijät voivaat tarkistaa tarpeellisia henkilöstö- ja työsuhdetietoja. (Van Vulpen 2019).  

 

Henkilöstötietojärjestelmät ovat tietojärjestelmiä, joiden avulla käsitellään ja säilytetään 

organisaation henkilöstöön liittyviä henkilö- ja työsuhdetietoja, muutostietoja, organisa-

torisia tietoja sekä suoritetaan erilaisia henkilöstöprosesseja. Henkilöstöjärjestelmä voi-

daan hankkia joko yhteen tai useampaan edellä mainituista käyttötarkoituksista. Järjes-

telmä voi olla keskittynyt esimerkiksi pelkästään suorituksen johtamisen tukemiseen tai 

rekrytointiin, tai voi yhdistää monia eri toimintoja. (Van Vulpen 2019). 

 

Nykyaikainen henkilöstöjärjestelmä on dynaaminen tietokanta, joka muodostuu jokai-

sen työntekijän demografisista ja suorituskykyä koskevista tiedoista. Henkilöstöjärjes-

telmä sisältää tietoja ja toimintoja liittyen rekrytointiin, työnhakijoihin, työtehtäviin, or-

ganisaation rakenteisiin, henkilöstön ammatilliseen kehitykseen, koulutuksiin, suorituk-

sen arviointiin, henkilöstön monimuotoisuuteen ja henkilöstön vaihtuvuuteen. Henkilös-

töjärjestelmää voidaan myös pitää strategisena suunnitteluvälineenä, jonka avulla voi-

daan luoda erilaisia raportteja ja ennusteita henkilöstöön liittyen. (Duc, Siengthai & Page 

2013: 113). 

 

Henkilöstötietojärjestelmä on yksi organisaation hallintotietojärjestelmistä. Se ei kuiten-

kaan vain tallenna ja hallinnoi tietoa, vaan myös seuraa liiketoimintaan liittyviä proses-

seja. Koska jokainen organisaatio omaksuu tietyt menettelytavat ja rutiinit päivittäisessä 

toiminnassaan, on hyödyllistä, jos organisaatio voisi seurata päätöksentekoprosessia 

sekä tehtyjen päätösten tuloksia ja kykenisi välittämään nämä tiedot useille eri käyttäjille 

tai käyttäjäryhmille. Ihmisten hallinta kokeilun ja erehdyksen kautta on suhteellisen 



10 

 

kallista yrityksen tuottavuudelle sekä työntekijöiden moraalille, joten on välttämätöntä, 

että henkilöstöjärjestelmä varmistaa työntekijöiden tietojen tarkkuuden ja johdonmu-

kaisuuden. Tietojärjestelmiä arvioidaan operatiivisen tehokkuuden varmistamisen näkö-

kulmasta, sekä sen perusteella, mikä niiden strateginen rooli on organisaatiossa. (Mar-

kova 2012: 84-85).  

 

Henkilöstötietojärjestelmä käytetään hankkimaan, tallentamaan, käsittelemään, analy-

soimaan, hakemaan ja levittämään organisaation HR: tä koskevia olennaisia tietoja. Se 

voi vaihdella yksinkertaisesta tiedostojen tallennusohjelmasta monimutkaisiin toimintoi-

hin, jotka auttavat päätöksenteossa. (Markova 2012: 84). 

 

Henkilöstötietojärjestelmä voi toimia organisaation omalla teknisellä infrastruktuurilla, 

kuten perinteinen toiminnanohjausjärjestelmä, mutta yleisempää on, että järjestelmä 

on pilvipohjainen. Tämä tarkoittaa, että ohjelmisto toimii yrityksen tilojen ulkopuolella 

ja sen päivittäminen on paljon helpompaa. (Van Vulpen 2019). 

 

Henkilöstötietojärjestelmällä on päätöksentekoa tukevana järjestelmänä useita ominai-

suuksia, joista voi olla hyötyä organisaatioille. Kuten muutkin tietojärjestelmät, myös 

henkilöstöjärjestelmä lisää organisaation tehokkuutta, tarkemmin määriteltynä henki-

löstötoimintojen tehokkuutta. Kun HR-ammattilaiset pystyvät tuottamaan järjestelmän 

avulla suuren määrän henkilöstöpäätöksiä koskevia raportteja, he voivat keskittyä tois-

tuvien rutiininomaisten ja hallinnollisten tehtävien sijaan strategisiin kysymyksiin. Tällä 

tavoin henkilöstöjärjestelmä voi parantaa organisaation sisäisten asiakkaiden, eli työnte-

kijöiden, palveluita. Henkilöstöjärjestelmä voi myös lisätä työntekijöiden osallistumista 

omien henkilökohtaisten tietojensa hallintaan ja muokkaamiseen. Näiden toimintojen 

avulla järjestelmä voi parantaa yrityksen johtamisen lisäksi myös työntekijöille tarjotta-

via palveluita. (Markova 2012: 84). 

 



11 

 

Henkilöstöjärjestelmän pääasiallisia käyttäjiä ovat HR:n lisäksi erityisesti esimiehet. 

Myös muu henkilöstö voi käyttää järjestelmää omien tietojensa tarkasteluun ja hallin-

nointiin, organisaation tietojen tarkasteluun tai lomien anomiseen.  

 

Henkilöstötietojärjestelmä helpottaa käytettävissä olevan henkilöstön hyödyntämistä 

organisaatiolle parhaalla mahdollisella tavalla. Resurssien jakaminen, johdonmukainen 

henkilöstöpolitiikka ja hallinnollinen tehokkuus paranevat. Se myötävaikuttaa myös ar-

von luomiseen palvelemalla organisaation ainutlaatuisinta ja korvaamattominta resurs-

sia - sen ihmisiä. (Markova 2012: 92). 

 

Kun henkilöstöhallinnon prosessit tietokoneistettiin, HR:n päätöksenteosta tuli nopeam-

paa kehittämiseen, suunnitteluun ja hallinnollisiin asioihin liittyen, sillä järjestelmän an-

sioista datasta tuli paljon helpompaa tallentaa, hakea, päivittää, luokitella ja analysoida. 

Jotta organisaatiot voisivat lisätä henkilöstöhallinnon tehokkuutta, ne ovat yhä enem-

män riippuvaisia henkilöstötietojärjestelmistä. Helpottamalla pääsyä erilaisiin mittarei-

hin järjestelmä voi parantaa hallinnollista tehokkuutta nopeammalla tietojenkäsittelyllä, 

parannetulla henkilöstöviestinnällä, paremmalla tiedon tarkkuudella, alentamalla HR:n 

kustannuksia ja yleisesti parantamalla HR:n tuottavuutta. Yhä useammat yritykset käyt-

tävät henkilöstötietojärjestelmää tukemaan aktiivisesti sekä henkilöstöjohtoa että liike-

toimintajohtoa. (Obeidat 2012: 195). 

 

Jotta henkilöstöjärjestelmä olisi organisaatiolle hyödyllinen, on käytäjien luotettava sii-

hen. Duc, Siengthai & Pagen (2013) mukaan luottamus perustuu siis siihen, kuinka hyvän 

arvion käyttäjät antavat järjestelmä. Luottamuksen taso perustuu käyttäjien odotuksiin, 

järjestelmän ennustettavuuteen, motivaatioon käyttää järjestelmää, sekä käyttökoke-

muksen eheyteen.  



12 

 

3 Päätöksentekoprosessin vaiheet 

3.1 Tietojärjestelmähankinnan taustat ja syyt  

Tietojärjestelmän hankinta on osa tietojenkäsittelyn kehittämisen suurempaa kokonai-

suutta, johon sisältyvät myös suunnitteluprojektit, investointien valmistelut, tietojenkä-

sittelyyn liittyvän toiminnan kehittäminen sekä tietotekniikan kehittäminen. Useita eri 

osapuolia sisältävän tietojärjestelmäprojektin onnistuminen edellyttää hyvin tehtyä 

taustatyötä, toimivaa projektin hallintaa sekä muutoksen hallinnan prosesseja. (Tieto-

tekniikan liitto ry 2002: 14). 

 

Tarve tietojärjestelmähankintoihin lähtee usein yrityksen strategiasta, tai ainakin se 

määritellään osaksi strategiaa. Strategiassa määritellään liiketoiminnan tavoitteet ja 

suunnitellaan toiminnan päälinjat usein yhden tai kahden vuoden sykleinä. Liiketoimin-

tastrategian määrittely käynnistää yksityiskohtaisempien alueiden strategian määrittelyn, 

kuten tietojärjestelmästrategiatyön. (Tietotekniikan liitto ry 2002: 15). 

 

Strategisen suunnittelun lisäksi organisaatiot tekevät lyhyemmän aikavälin suunnitelmia, 

kuten vuosisuunnitelmia. Vuosisuunnitelmassa käydään läpi organsiaation toiminnat ja 

tavoitteet yksityiskohtaisemmin kuin strategiassa ja se liittyy usein organisaation budje-

tointiprosessiin. Tietojärjestelmän hankinta- tai uudistamisprojekti voi päätyä mukaan 

vuosisuunnitelmaan esimerkiksi sen takia, että halutaan muuttaa toimintaa, tai siksi, että 

aiempi järjestelmä ja toimintatapa on vanhentunut ja näitä halutaan uudistaa tietojär-

jestelmähankkeen avulla. Tietojärjestelmäprojekti merkitsee kuitenkin aina organisaa-

tion toiminnan muutosta jollakin tapaa. Yleensä tietojärjestelmäprojektin hyödyt reali-

soituvatkin vasta toiminnan muutoksen myötä ja tietojärjestelmärojekti on vain osa ko-

konaisvaltaisempaa toiminnan kehittämistä. (Tietotekniikan liitto ry 2002: 15 - 16).  

 

Tämä tulisi aina pitää mielessä, mutta se tuntuu usein unohtuvan ja toimintatapojen 

muutosta odotetaan tapahtuvaksi heti, kun tietojärjestelmäprojekti on saatu maaliin. To-

tuus on, että muutosprosessi alkaa kunnolla vasta tästä hetkestä, kun loppukäyttäjät 



13 

 

alkavat opetella uusi toimintamalleja ja järjestelmän käyttöä. Muutosprosessille pitää 

antaa aikaa ja muutoksen hallinta ja käyttäjien koulutus sekä tuki tulisi suunnitella huo-

lellisesti osana projektisuunnitelmaa. Tietojärjestelmäprojektia voidaan pitää onnistu-

neena vain, jos loppukäyttäjät ovat tyytyväisiä järjestelmään.  

 

Organisaation johto pukee yleensä pitkäaikaiset kehityssuunnitelmat strategian muo-

toon. Tyypillinen strategian kesto on viisi vuotta, kun taas tietojärjestelmien elinkaaret 

ovat selkeästi strategioiden elinkaaria pidempiä. Tietojärjestelmäprojektit ovat yleensä 

liiketoiminnan kehityshankkeita, joilla toteutetaan strategiaa käytännön tasolla. Strate-

gian on laatinut yleensä organisaation ylin johto, sen toimeenpanijana projektiryhmä ja 

kohteena organisaation henkilökunta. Onnistuneissa projekteissa kaikki kolme ryhmää 

saadaan saman tavoitteen taakse. Epäonnistuneissa projekteissa hanke on usein työn-

netty it-projektina organisaation it-osaston harteille, jolloin projektiryhmällä ei ole ollut 

valtuuksia tehdä tarvittavia muutoksia liiketoimintaan tai heillä on vaikeuksia saada koko 

henkilökuntaa mukaan hankkeeseen. Elinkaarensa alussa olevalle projektille kannattaa-

kin tehdä kysymys siitä, minkä strategisen tavoitteen projektin on tarkoitus täyttää, jos 

se ei ole jo selvillä. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 20-21). Näin on 

helpompi perustella projekti myös muulle organisaatiolle projektiryhmän ulkopuolella.  

 

Monesti uudet toimitusjohtajat aloittavat koko organisaation yhteisen ERP-projektin tai 

One Company -strategian, joiden tarkoituksena on hankkia yksi yhteinen toiminnanoh-

jausjärjestelmä organisaation eri liiketoiminta-alueille. Monet organisaatiot ovat kuiten-

kin lama-ajan seurauksena varsin kapeita, eikä henkilökuntaa riitä suuriin kehityshank-

keisiin, kun voimavarat menevät päivittäiseen operatiivisen toiminnan ylläpitoon. Usein 

projektiin kiinnitetyt liiketoiminnan resurssit ovat ennemminkin pelkkä nimilista henki-

löistä, joiden pitäisi olla projektin käytettävissä, mutta oikeasti heidän projektiin allokoitu 

aikansa kuluu muuhun. On yleistä, että liiketoiminnan sitoutuminen omaa toimintaansa 

kehittävään projektiinsa horjuu. Pahimmassa tapauksessa koko projekti delegoidaan tie-

tohallinnolle, jonka mahdollisuudet saada muutoksia aikaan liiketoiminnan prosesseissa 

ovat hyvin rajalliset. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 22-23). 



14 

 

 

Valmiiden ohjelmistoratkaisujen käyttö on viime vuosina laajentunut räätälöityjen järjes-

telmien kustannuksella (Holland & Light 1999). Organisaatiot luottavat yhä enemmän 

käyttövalmiisiin järjestelmiin, joten kaikista sopivimman järjestelmätuotteen tunnistami-

nen on tärkeää. Monet päätöksentekomenettelyt on kehitetty tämän päätöksentekopro-

sessin tehostamiseksi (Șen, Baracli & Șe 2009). Tieteellisessä kirjallisuudessa näitä on ar-

vioitu toiminnallisia, taloudellisia, ja poliittisia perusteita vasten. (Pollock & Williams 

2007).  

 

Toiminnallisen perusteen mukaan ohjelmistopaketti on valittava, kun se parhaiten vastaa 

muotoiltuja vaatimuksia. Taloudellisen perusteen mukaan valinnan, hankinnan ja ylläpi-

don kustannukset tulisi vallita, kun taas poliittisen perusteen mukaan keskeisintä on va-

lintaperusteiden hyväksyttävyys tärkeille sidosryhmille. (Howcroft & Light 2010). 

 

Valmiiden tietojärjestelmäprojektien tarjonta oli jo vuonna 2002 niin laajaa, että pidet-

tiin virheenä, jos valmitta järjestelmäpaketteja ei edes otettu mukaan harkintaan, kun 

suunniteltiin tietojärjestelmän hankkimista. Useimmissa tietojärjestelmien hankintati-

lanteissa valmisohjelmat tulevat edullisemmiksi ja niissä on matala riski verrattuna jär-

jestelmän kehittämiseen itse alusta alkaen. Usein valmisohjelman käyttö voi jopa olla 

hankinnan lähtökohtana. Valmiiden ratkaisujen hankinnassa korostuu järjestelmän toi-

mintojen ja mahdollisuuksien arviointi sekä vertailu kilpaileviin tuotteisiin nähden. Arvi-

ointia tehdään yleensä erilaisien pisteytys- ja päätöksentekomenetelmien avulla. (Tieto-

tekniikan liitto ry. 2002: 16). 

 

Rutiininomaisia hankintoja varten yrityksen kannattaa hankkia hyvin testattu, valmis jär-

jestelmä (Moe 2017: 157). Tällainen on esimerkiksi henkilöstöjärjestelmä. Moen tutki-

muksen kehys perustuu kahteen ulottuvuuteen: vaatimusten monimutkaisuuteen ja jär-

jestelmän ainutlaatuisuuteen. Molemmat käsitteet määritellään hankintaryhmän suh-

teen, eli mitä tietoa hankintaryhmällä on näihin kahteen ulottuvuuteen liittyen. (Moe 

2017: 158).  



15 

 

 

Valmisohjelmien räätälöinnin kohdalla kustannukset voivat kuitenkin kasvaa suuriksi. Jär-

jestelmän kustannuksia laskiessa pitää ottaa huomioon paljon muutakin, kuin vain lisens-

sihinta, sillä se on usein vain pieni osa koko järjestelmän elinkaareen kokonaiskustannuk-

sista (engl. TCO, Total Cost of Ownership). Kustannuksia nostavat muun muassa järjestel-

män ylläpito, järjestelmäkapasiteetin tai lisenssien lisäys, muut käyttökustannukset sekä 

järjestelmäkoulutus- ja tukikustannukset. Piilokustannuksia muodostuu esimerkiksi siitä, 

kun käyttäjät opettelevat järjestelmän käyttöä tai kun järjestelmään tulee jokin ennalta 

arvaamaton virhe.  (Tietotekniikan liitto ry. 2002: 16). 

 

Tietojärjestelmiä on ennen kehitetty suoraan tietyn organisaation tarpeisiin, mutta ny-

kyään yhä useampi organisaatio valitsee valmiin järjestelmän. Järjestelmäkehitysprojek-

tissa otetaan yleensä paremmin huomioon organisaation tarpeet, ohjelmistoon ei tar-

vitse ostaa erikseen lisenssejä ja tietokannat sekä muut järjestelmän osat voidaan valita 

niin, että ne sopivat organisaation kokonaisarkkitehtuuriin. Jos saatavilla olisi kuitenkin 

valmisohjelma kyseiselle osa-alueelle ja mahdollisesti vielä useita eri vaihtoehtoja, ei 

uutta ohjelmaa kannata välttämättä alkaa kehittää oman organisaation tarpeisiin. Val-

misohjelmat tarjoavat parhaiden käytäntöjen mukaisia prosesseja, jotka voivat hyvin olla 

parempia, kuin yrityksen aiemmat, kyseenalaistamattomat, toimintamallit. Ohjelman ai-

nutlaatuisuus saattaa johtaa siihen, että yritys on yksin ainutkertaisen räätälöidyn ratkai-

sunsa kanssa ja näin kustannukset ohjelmiston ylläpidosta kasvavat. Ohjelmistoprojektit 

soveltuvatkin sellaisille yksityiskohtaisille ja rajatuille alueille, joilla valmisohjelmistoja ei 

ole saatavilla. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 123). 

 

Myös valmisohjelmiin liittyy tiettyjä ongelmia. Valmisohjelmien prosessit voivat olla or-

ganisaation tarpeisiin riittämättömiä. Näin voi käydä varsinkin, jos tavoiteprosessit on 

määritelty hyvin yksityiskohtaisesti. Valmisjärjestelmää hankittaessa omien prosessien 

ainutlaatuisuus kannattaa kyseenalaistaa. Prosessien räätälöinti sitoo yrityksen vanhoi-

hin, mahdollisesti tehottomiin, toimintatapoihin, joihin standardiprosessit voisivat tuoda 

avun tuottamalla organisaatiolle lisäarvoa järjestelmän mukana. Turha räätälöinti 



16 

 

maksaa ja voi estää järjestelmän kehittämisen ja version vaihdot myöhemmin, kun stan-

dardiprosessin uutta versiota ei voi soveltaa organisaatiolle räätälöityyn ratkaisuun. 

(Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 124-125). 

 

Mahdollisuudet mukauttaa valmisjärjestelmiä ilman vaativaa räätälöintiä kasvavat kui-

tenkin koko ajan. Valmisjärjestelmiä hankittaessa kannattaa noudattaa toimittajan neu-

voja, sillä muuten eteen voi tulla odottamattomia ongelmia. Huomio järjestelmähank-

kinnassa kannattaakin kiinnittää niihin asioihin, jotka ovat organisaation kilpailukyvyn 

ydin. Räätälöinneillä on monella tapaa negatiivinen vaikutus projektin onnistumiseen, ja 

sitä kannattaakin mahdollisuuksien mukaan välttää. Vaihtoehtona voi pohtia mahdolli-

suutta toteuttaa organisaation erikoistarve pääjärjestelmään integroidulla erillisellä jär-

jestelmällä tai vain hyväksyä standardiprosessit. Haastavalta vaikuttavaa räätälöintiä kan-

nattaa pitää viimeisenä vaihtoehtona. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 

2011: 124-125). 

  

Kun tietojärjestelmäksi valitaan valmis järjestelmä uuden järjestelmän kehittämisen si-

jaan, hankinnan painopiste on tällöin tuotekeskeinen. Hankinnassa keskitytään markki-

noilla olevien vaihtoehtojen kartoittamiseen, tuotteiden ominaisuuksien arviointiin ja 

sopivimman tuoteen valintaan. Tuote pitää myös pystyä sovittamaan organisaation val-

miiseen toimintaympäristöön, kuten olemassa oleviin muihin järjestelmiin. Räätälöinti-

projektissa painopiste on palvelun ostamisessa sekä sopivimman toimittajan valinnassa. 

(Tietotekniikan liitto ry. 2002: 26). 

 

Valmisohjelmia käytettäessä vaatimuksista joudutaan usein tinkimään ainakin jossain 

määrin, koska järjestelmän huomattava räätälöinti johtaa kustannuksien ja riskien kas-

vamiseen. Räätälöintiä vaikeuttaa myös, jos organisaatiolta puuttuvat kunnolliset ku-

vaukset liiketoiminnan prosesseista. Valmisjärjestelmän mukana voi tulla jo valmiiksi 

omia toimintaprosesseja. Organisaation prosessien muttaminen ja uusien työtapojen 

omaksuminen voi olla hankalaa, mutta kannattavaa, sillä uudet järjestelmän tuomat mal-

lit edustavat usein alan parhaita käytäntöjä. (Tietotekniikan liitto ry. 2002: 27). 



17 

 

 

 

3.2 Päätöksentekoprosessi 

Organisaatiot tekevät päätöksiä investoida tietojärjestelmiin hyvin säännöllisesti. Pää-

tökset voivat syntyä hyvinkin nopeasti ongelman huomaamisesta ja vaihtoehtojen tutki-

misesta ratkaisun valintaan suoraviivaisesti tai päätöstä voivat edeltää laaja haku, seu-

lonta, ratkaisun muotoilu ja neuvottelut, jotka saattavat kestää vuosia.  

 

Albert Boonstra (2003) määrittelee tietojärjestelmäpäätöksen päätökseksi investoida, 

tai vastaavasti päätökseksi olla investoimatta, uuteen tietojärjestelmään. Tavallinen tie-

tojärjestelmän ylläpito tai pienet muutokset valmiiseen järjestelmään eivät kuulu hänen 

mukaansa järjestelmäpäätöksiin. Organisaatioiden päätöksentekoprosesseihin vaikutta-

vat yleensä ihmisten rajoittunut tiedonprosessointikyky, sidosryhmien erimielisyydet, 

muutos, epävarmuus ja epäselvät tavoitteet, yksilöiden ja ryhmien psykologiset esteet 

sopeutua tietoon ja käyttäytyä rationaalisella tavalla, sekä taipumus inkrementalismiin 

ja mielivaltaisuuteen päätöksenteossa.  

 

Tietojärjestelmähankinnoista päättävien tahojen tulisi olla tietoisia näistä päätöksente-

koon vaikuttavista eri tekijöistä, jotta he voivat suunnitella prosessin, joka sopii parhaiten 

juuri tiettyihin olosuhteisiin. Yhtäkään päätöksentekoprosessia ei nimittäin voida pitää 

universaalisti toimivana, sillä päätökseen vaikuttavat monet eri tekijät, jotka vaihtelevat 

tilanteesta riippuen.  

 

Sabherwal & King (1995) ovat toteuttaneet tutkimuksen liittyen päätöksentekoproses-

siin tietojärjestelmähankintojen taustalla. He ovat kehittäneet luokittelun tietojärjestel-

mäprosessien päätöksenteosta ja tunnistaneet viisi erillistä prosessiryhmää: suunniteltu 

päätöksenteko, eristetty päätöksenteko, inkrementaalinen päätöksenteko, juokseva 

(fluid) päätöksenteko sekä poliittinen päätöksenteko.  

 



18 

 

Ensimmäiseen prosessiryhmän suunnitellut tietojärjestelmäpäätökset sisältävät suun-

nittelumetodeja ja ylimmän johdon määräävä toiminta on niille ominaista päätöksente-

koprosessin aikana. Ylin johto käsittelee suuria ongelmia, liittää päätöksentekoprosessin 

liiketoiminnan tavoitteisiin ja koittaa sen vuoksi kontrolloida prosessia.  

 

Eristetyissä päätöksissä tietojärjestelmäosastolla on suurempi vaikutusvalta, sillä tieto-

järjestelmien ajatellaan olevan heidän aluettaan. Tämä päätöksentekoprosessi on lyhyt-

näköisempi ja ei juurikaan käytä hyväkseen virallisia tietojärjestelmäsuunnittelun meto-

dologioita. Inkrementaaliset tietojärjestelmäpäätökset kohtaavat suurempia viivästyk-

siä ja kestävät pidempään. Niiden taustalla ovat usein lyhyen aikavälin tavoitteet ja sisäi-

set vaikutteet ja ne joutuvat usein keskeytetyksi eri syistä.  

 

Juoksevat (engl. fluid) tietojärjestelmäpäätökset tehdään nopeammin, ilman suurem-

pia viivästyksiä. Hidastukset liittyen uudelleenharkintaan, ongelmien etsimiseen, tiedon-

hakuun ja sopivan ajankohdan odottamiseen ovat epätodennäköisempiä kuin muissa 

prosesseissa.  Myös sisäiset voimat vaikuttavat tähän prosessiin vähemmän, kuin muihin 

prosesseihin. Poliittiset tietojärjestelmäpäätökset sisältävät enemmän politiikkaa ja si-

säistä vastustusta, kuin muut prosessit, ja niihin vaikutetaan organisaation sisältä. Tässä 

prosessissa ylin johto ottaa yleensä projektijohtajan tehtävän ja auttaa pääsemään sisäi-

sen vastustuksen yli matkan varrella.   

 

Sabherwalin & Kingin (1995) löydökset tietojärjestelmäpäätöksistä täydentävät Hickso-

nin (1986) kattavaa tutkimusta liittyen strategisiin päätöksiin organisaatiossa. Hickson 

tutki 150 strategista päätöstä 30 eri organisaatioista. Useiden ominaisuuksien perus-

teella tunnistettiin kolmenlaisia päätöksentekoprosesseja: ahdas (tuttu), juokseva (le-

vittyvä) ja harvinainen (pyörteinen).  

 

Ahtaat prosessit ovat näistä kolmesta suoraviivaisimpia, ne eivät ole uusia, niillä on vain 

rajatusti vaikutusta organisaatioissa ja ne eivät juurikaan ole poliittisia. Ne ovat lähellä 

Sabherwalin & Kingin (1995) “nurkkakuntaisia” päätöksiä. Juoksevat prosessit ovat 



19 

 

suhteellisen vakaita ja niitä johdetaan muodollisella vuorovaikutuksella. Ne ovat usein 

suoraviivaisia, vähemmän monimuotoisesti osallistavia ja vähemmän vakavia, niiden vai-

kutukset organisaatiossa ovat hajanaisia ja ne ovat kolmesta päätöksentekoprosessista 

vähiten poliittisia. Harvinaiset prosessit ovat monimutkaisia, monimuotoisia, poliittisia 

ja niillä on organisaatioon suuria vaikutuksia. 

 

Albert Boonstra (2003) käsittelee tietojärjestelmiin liittyvän päätöksentekoprosessin ra-

kennetta. Boonstra analysoi 20 eri tietojärjestelmäpäätöksentekoprosessia ja tämän 

pohjalta määrittelee neljä kilpailevaa voimaa, jotka voivat vaikuttaa tietojärjestelmäpää-

töksen tekoon vaihtelevilla intensiteeteillä: perusteltu/rationaalinen, tarve, politiikka ja 

innovatiivisuus. 

 

Nämä neljä keskenään kilpailevaa voimaa; innovatiivisuus, rationaalisuus, tarve ja poliit-

tisuus, vaikuttavat tietojärjestelmäpäätöksiin. Näiden taustavaikutteiden vahvuus riip-

puu tietojärjestelmään liittyvästä ongelmasta, organisatorisesta kontekstista ja ominai-

suuksista sekä muista laajemmista ympäristötekijöstä. Boonstran (2003) mukaan monet 

tietojärjestelmäpäätökset noudattavat samaa hankalaa polkua, kuin muutkin strategiset 

päätökset. Muutenkin mallit ja teoriat päätöksenteosta yleensä sopivat johdon tietojär-

jestelmien kenttään. Tämä tarkoittaa, että monet havainnot päätöksentekoprosesseista 

yleensä ovat sovellettavissa tietojärjestelmäpäätöksiin ja lopulta kehittämään tietojär-

jestelmäpäätöksenteon malleja ja käytäntöjä. Boonstran määrittelemät päätöksen taus-

tatekijöitä ja voimia voidaan käyttää tietojärjestelmäpäätöksenteon mallin suunnitte-

lussa.  

 

Monet nykyiset päätöksentekomallit ja lähestymistavat, joita käytetään esimerkiksi joh-

don tietojärjestelmien hankinnassa, käyttävät oletuksia, jotka perustuvat pääasiassa ra-

tionaalisen päätöksenteon malliin. Ne eivät ota huomioon olennaisia eroja tietojärjes-

telmäpäätöksissä, organisatorisissa ominaisuuksissa ja ulkoisissa tekijöissä. Tämän 

vuoksi nämä lähestymistavat jättävät huomioimatta tiedon päätöksenteosta yleensä, 

sillä ne rakentuvat suurimmaksi osaksi johdon tietojärjestelmäkentän ulkopuolella. 



20 

 

Rationaalinen päätöksentekomalli ottaa huomioon vain yhden hallitsevan voiman, 

vaikka tutkimus osoittaa, että myös muut voimat ja tekijät vaikuttavat päätöksenteko-

prosessiin. Boonstra (2003: 200). 

 

Rationaalisissa päätöksentekoprosesseissa on selkeä ja tunnistettava ongelma ja eri si-

dosryhmät kokevat ongelman samalla tavoin suhteessa ratkaisukeinoihin ja päämäärään. 

Päätöksentekoa varten käytettävissä oleva informaatio on suhteellisen yksiselitteistä. 

Hankintapäätös parantaa selkeästi nykytilannetta tärkeimpien sidosryhmien mielestä ja 

parannuksen olisi oltava mitattavissa mieluiten myös taloudellisesti. Prosessin valinta 

riippuu mahdollisesta järjestelmästä, joka voi olla räätälöity, valmis tai muokattava. Ra-

tionaaliset päätökset ovat usein suunniteltuja, koska niitä varten on ollut tarjolla tar-

peeksi luotettavaa tietoa ja sidosryhmät ovat samaa mieltä suunnitellusta lähestymista-

vasta. Rationaalisesta päätöksentekoprosessista puhutaan silloin, kun saatavilla oleva in-

formaatio on yksiselitteistä, on olemassa jonkinlainen sopimus tärkeimpien sidosryh-

mien välillä ja tärkeimmät osapuolet uskovat, että päätös johtaa selkeään parannukseen. 

(Boonstra 2003: 200-203).  

 

Kun tietojärjestelmäpäätöksen vaikutteena on kriisi, ennemmin kuin mahdollisuus tai 

ongelma, vaikuttava voima päätöksen taustalla on usein tarve. Tarvelähtöiset päätökset 

ovat usein myös rationaalisia, sillä niitä varten on myös saatavilla perusteltua tietoa. Nii-

den vaikutteena voi joissain tapauksissa olla myös ongelma. (Boonstra 2003: 200-203). 

 

Boonstran (2003) mukaan poliittisella toiminnalla on usein tärkeä rooli monissa tietojär-

jestelmäpäätöksentekoprosesseissa. Tämä toiminta osoittaa, että yksilöillä ja ryhmillä or-

ganisaation sisällä ja ulkopuolella voi olla erilaisia tavoitteita ja he koittavat vaikuttaa tie-

tojärjestelmäpäätöksentekoprosessiin, jotta lopputulos edistäisi juuri heidän intresse-

jään. Poliittisen toiminnan ollessa taustavaikutteena, päätöksentekoprosessit yleensä 

venyvät. Kun päätös vaikuttaa asiakkaisiin, toimittajiin tai muihin ulkoisiin sidosryhmiin, 

heistä voi tulla osa prosessia. Poliittisessa prosessissa päätöksenteko on neuvottelevaa 

ja päätös saattaa muuttua poliittiseksi vasta siinä vaiheessa, kun se on jo melkein tehty.  



21 

 

 

Päätöksentekoprosessit luokitellaan innovatiivisiksi, kun niiden taustalla on ollut mah-

dollisuus. Tällainen järjestelmä voi tarjota mahdollisuuden tavoittaa uusia asiakkaita, esi-

tellä uusia tuotteita, tarjota parempaa palvelua ja saada kilpailuetua muilla tavoin. Inno-

vatiiviset päätökset perustuvat usein odotuksiin ja ennusteisiin tulevasta ilman kunnon 

todisteita. Joskus investointien tuotto voidaan laskea, mutta se perustuu usein hyvin sub-

jektiivisiin odotuksiin. Innovatiivisilla päätöksillä voi myös olla poliittisia tai rationaalisia 

ominaisuuksia. Esimerkiksi vaikuttavien sidosryhmien etujen ollessa kyseessä, innovatii-

viset päätökset voivat olla innovatiivisia ja poliittisia. Jossain tutkimustapauksissa päätös 

nähtiin tilaisuutena, joka vain ilmaantui, ja siihen tartuttiin ilman selvää keinojen ja pää-

määrien tarkastelua. Cohen (1972) kutsui tämäntyyppistä ratkaisua roskapönttöpää-

tökseksi.   

 

Boonstran (2003) mukaan tietojärjestelmäpäätökset ovat usein monimutkaisia ja dy-

naamisia, mutta myös vastaanottavaisia analyysille ja erialisille rakenteille. Tietojärjes-

telmäpäätökset voidaan luokitella eri ryhmiin riippuen niihin vaikuttavista tekijöistä ja 

taustavoimista. Kaikille tietojärjestelmäpäätöksille yleisesti sovellettavaa päätöksenteko-

prosessia ei ole. 

  

Määritellessä sopivaa päätöksentekoprosessia, tiettyä kaavaa voidaan kuitenkin seurata. 

Boonstra (2003) on tunnistanut viisi kysymystä, joiden avulla päätöksentekoprosessin va-

linta tulee helpommaksi:  

 

1. Sisältyykö projektin laajuuteen uuden järjestelmän suunnittelu (valmiiksi tehty, 

muokattu vai räätälöity)? 

2. Täytyykö erilaisia tietojärjestelmävaihtoehtoja etsiä (yksi, muutama vai monta 

vaihtoehtoa)? 

3.  Mikä on kiireellisyyden ja välttämättömyyden aste päätöksentekijöiden näkökul-

masta (kriisi, ongelma, mahdollisuus)? 



22 

 

4.  Voidaanko tietojärjestelmäpäätös jakaa noudattamaan asteittaisempia prosessi-

reittejä (suunniteltu vs. inkrementaalinen)? 

5. Mikä on sidosryhmien määrä, vaikutusvalta ja missä määrin heidän intressinsä 

vaihtelevat ja eroavat toisistaan? 

 

Kysymysten avulla tehdyt havainnot voivat auttaa päättäjiä ymmärtämään ja diagnosoi-

maan tietojärjestelmiin liittyviä ongelmia heti päätöksentekoprosessin alussa, jotta pro-

sessi voidaan suunnitella juuri kyseessä olevan tilanteen ja ongelman mukaan. Mitään 

prosessia ei voida pitää universaalisti sopivana ja mitä tahansa päätöksentekoprosessia 

voidaan käyttää riippuen olosuhteista. Usein aluksi ajatellaan, että tietojärjestelmään liit-

tyvä ongelma ja päätökset ovat rationaalisia ja sopivia suunnitellulle lähestymistavalle. 

Prosessin aikana kuitenkin saatetaan huomata, että alkuperäinen lähestymistapa on liian 

optimistinen ja riittämätön. Tällaisissa tilanteissa prosessin mukautukset ovat välttämät-

tömiä, mutta ne puolestaan voivat johtaa sekaannuksiin, huonosti johdettuihin päätök-

sentekoprosesseihin tai tehottomiin päätöksiin. Boonstra (2003) on pyrkinyt tarjoamaan 

näkemystä tietojärjestelmäpäätöksentekoprosesseihin, jotta päätöksentekijöiden tueksi 

olisi saatavilla tarkoituksenmukaisempia päätöksentekomalleja ja tätä kautta saataisiin 

parempia tietojärjestelmäpäätöksiä. 

 

Se, miten ohjelmistovalintaan johtava päätöksenteko käytännössä tapahtuu, on jäänyt 

vähemmälle tieteelliselle huomiolle (Boonstra 2003 & Moe 2014) huolimatta siitä, että 

tietämys valintakäytännöistä on tärkeää sekä päätöksentekijöiden että tutkijoiden kan-

nalta, sillä juuri tähän päätöksentekoon liittyy paljon epävarmuustekijöitä ja jännitteitä 

(Pollock & Williams 2007: 131). 

 

 

3.3 Valintaprosessi 

Strategisessa päätöksentekoprosessissa käytettävät kilpailevat perusteet ovat funktio-

naalinen, taloudellinen ja poliittinen. Tutkimuskirjallisuudessa funktionaalista eli toi-

minnallista syytä pidetään muodollisena ja suoraviivaisena. Toiminnallisen perusteen 



23 

 

periaatteena on, että sen mukaan tehty päätöksentekoprosessi johtaa organisaation 

kannalta parhaaseen teknologiaan (Howcroft & Light 2010), ja siksi toiminnalliset ja tek-

niset vaatimukset ovat valinnassa pääosassa. Funktionaalisessa päätöksenteossa tausta-

oletus on, että kaikki tarvittavat tiedot ostajan vaatimuksista ja ohjelmiston ominaisuuk-

sista ovat saatavilla (Pollock & Williams 2007). Toiminnallisen perusteen mukaan ohjel-

miston valintaprosessin tulisi sisältää seuraavat vaiheet: (1) organisatoristen vaatimus-

ten ymmärtäminen; (2) saatavilla olevien järjestelmäratkaisujen tunnistaminen ja arvioi-

minen vaatimuksia vasten; (3) ohjelmistoratkaisun valinta ja hankinta; sekä (4) ohjelmis-

toratkaisun räätälöinti. Toiminnallinen peruste on kolmesta päätöksentekoprosessissa 

käytettävästä perusteesta selkeästä suosituin. Funktionaalista perustetta käytetään esi-

merkiksi, kun halutaan löytää asiakkaan vaatimuksiin sopiva tuote; tuote, joka tukee lii-

ketoiminnan tavoitteita ja strategiaa tai tuote, joka vastaa parhaiten kuhunkin asetet-

tuun kriteeriin. 

(Boonstra & Offenbeek 2018: 907 - 908). 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



24 

 

Taulukko 1. Tietojärjestelmän valintaan vaikuttavat päätöksentekoprosessit. (Boonstra & 

Offenbeek 2018: 908). 

 

 Funktionaalinen    

peruste 

Taloudellinen peruste Poliittinen peruste 

Filosofinen taustao-
letus 

Paras järjestelmärat-
kaisu valitaan toimin-
nalisen logiikan perus-
teella vertaamalla jär-
jestelmäratkaisuja 
käyttäjävaatimuksiin. 

Optimaalisin järjestel-
märatkaisu valitaan 
kvantitatiivisella logii-
kalla vertailemalla so-
pivien järjestelmärat-
kaisujen kuluja ja hyö-
tyjä. 

Paras tietojärjes-
telmä valitaan po-
liittisen logiikan, eli 
sidosryhmien 
kanssa tehtyjen 
neuvottelujen, pe-
rusteella. 

Päätöksentekopros-
essin painopiste 

Sopivia järjestelmärat-
kaisuja verrataan tek-
nisten ominaisuuksien 
perusteella ja pistey-
tetään käyttäjäorgani-
saation määrittele-
mien toiminnallisten 
kriteerien pohjalta.  

Sopivia ohjelmistorat-
kaisuja verrataan ja 
arvotetaan taloudelli-
sesti hyödyllisimmän 
tarjouksen valitse-
miseksi kustannuste-
hokkaalla tavalla. 

Sidosryhmät käyt-
tävät valtaansa 
päätöksentekopro-
sessissa ja valinta 
kohdistuu heidän 
etujaan parhaiten 
ajavaan järjestel-
märatkaisuun.  

Arviointinormit Asianmukaiset käyttä-
jävaatimukset sopi-
vimman teknologian 
löytämiseksi. 

Päätöksentekoproses-
sin kulut sekä talou-
dellisesti hyödyllisim-
män tarjouksen va-
linta.  

Päätöksentekopro-
sessin oikeutus ja 
hyväksyttävä lop-
putulos sidosryh-
mien kannalta. 

 

 

Taloudellinen lähestymistapa ohjelmiston valintaan ei eroa suurissa määrin toiminnalli-

sesta perusteesta (taulukko 1). Molemmat lähestymistavat edellyttävät, että päätöksen-

teossa mukana olevat päättäjät sekä tärkeimmät sidosryhmät ovat yhtä mieltä ratkai-

susta ja ratkaisu on loogisesti perusteltavissa. Taloudellinen päätöksentekoprosessin pe-

ruste edellyttää myös sitä, että ratkaisun hinta pystytään laskemaan. Siinä missä toimin-

nallinen peruste keskittyy parhaiten soveltuvan teknologian löytämiseen, taloudellinen 

peruste keskittyy taloudellisesti edullisimman ohjelmistopaketin valintaan. 



25 

 

Taloudellinen näkökulma keskittyy minimoimaan kustannukset pitkällä aikavälillä, ja 

olettaa, että organisaatiot pystyvät noudattamaan taloudellisia motiiveja, vaikka muut 

vaihtoehdot olisivat toiminnallisesti parempia tai hyväksyttävämpiä tärkeimmille sidos-

ryhmille. Tämän perusteen taloudelliset normit arvioivat, helpottaako päätöksenteko-

prosessi taloudellisesti edullisimman tarjouksen valintaa ja vertailevat päätöksenteko-

prosessin kustannuksia (eli transaktiokustannuksia) päätöksentekomenettelyissä. Pää-

töksentekoprosessissa mukana olevat johtajat ottavat yleensä ennemmin huomioon jär-

jestelmän toiminnallisuuden, räätälöitävyyden ja ratkaisun luotettavuuden ja taloudelli-

set kriteerit jäävät toissijaisiksi. Kustannuksilla on kuitenkin merkitystä lopullisen valin-

nan kannalta. (Boonstra & Offenbeek 2018: 908). 

 

Poliittisen perusteen taustaoletuksena on, että päätöksenteossa mukana olevat eri osa-

puolet kamppailevat keskenään saavuttaakseen ensisijaisesti omat tavoitteensa. Tämän 

näkemyksen mukaan ohjelmiston valinta on seurausta prosessista, jossa neuvottelevilla 

osapuolilla on keskenään erilaiset lähtökohdat, tavoitteet ja kriteerit. Näin ollen päätök-

sentekoprosessin tulos ei ole koskaan neutraali (Wilson & Howcroft, 2005). Hankintaor-

ganisaation on tehtävä kaupankäyntiä toisinaan ristiriitaisista vaatimuksista. Wybon 

(2007) mukaan myös toimittajat voivat vaikuttaa päätöksen lopputulokseen. Toimittajat 

eivät ainoastaan edistä omia ohjelmistoratkaisujaan, vaan muokkaavat myös ostajan 

mielipidettä järjestelmävaatimuksiin ja järjestelmäratkaisun sopivuuteen liittyen.  

 

Poliittisen perusteen normit koskevat päätöksentekoprosessin ja sen tulosten hyväksyt-

tävyyttä tärkeiden sidosryhmien näkökulmasta. Poliittinen peruste on kuitenkin vähiten 

näkyvissä, kun eri valintamenetelmiä on tarkasteltu tutkimuskirjallisuudessa. Tutkimus-

kirjallisuudessa ei juurikaan esiinny poliittista perustetta päätöksentekoprosessina, 

mutta sen olemassaolo on todennetty tapaustutkimusten avulla. (Boonstra & Offenbeek 

2018: 908 - 909). 

 



26 

 

Päätöksentekoprosessissa mukana olleiden johtajien ja asinatuntijoiden voi olla vaikea 

myöntää eri toimijoiden, kuten sisäisten ja ulkoisten sidosryhmien, vaikutusta heidän 

päätöksentekoonsa, mutta sidosryhmien vaikutus päätöksen syntymiseen on todellinen.  

 

Yleisin tapa valita järjestelmä ja toimittaja on lähettää potentiaalisille toimittajille pyyntö 

toimittaa tietoa, RFI, eli Request For Information. Toimittajien lähettämiä vastauksia ver-

rataan järjestelmälle ja toimittajalle asetettuihin tavoitteisiin, reunaehtoihin ja toisten 

toimittajien vastauksiin. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 41). 

 

Potentiaalisimmista järjestelmistä voidaan järjestää demotilaisuus, jossa toimittaja esit-

telee järjestelmän eri toiminnallisuuksia. Jatkoon valituilta potentiaalisimmilta toimitta-

jilta pyydetään ehdotusta järjestelmähankkeesta, RFP, eli Request For Proposal. Toimit-

tajista yhden tai useamman kanssa edetään sopimusneuvotteluihin, joita voi edeltää 

vielä erillinen tarjouspyyntövaihe, eli RFT, Request For Tender. Valinta muuttuu vaiheit-

tain raskaammaksi ja seuloo joukosta pois huonoimmin sopivat vaihtoehdot, jolloin 

nämä toimittajat säästyvät turhalta myyntityöltä. Osapuolten tuntemus toisistaan lisään-

tyy prosessin edetessä. Prosessi on silti toimittajille melko raskas, sillä välillä hyvin yksi-

tysikohtaisiinkiin vaatimuksiin vastaaminen vie aika, vaikka prosessi olisikin rutinoitunut. 

(Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 41-42).  

 

Mitä pidemmälle vaatimusmäärittelyt voidaan tehdä ennen valintavaiheeseen etene-

mistä, sen parempi hankinnan kannalta. Jos prosessit ja käyttötapaukset on kuvattu sel-

keästi, tämä visio on helppo viestiä eteenpäin potentiaalisille toimittajille. Jos lisäksi jär-

jestelmän tietomalli ja tulevat integraatiot muihin järjestelmiin on kuvattu ennakkoon, 

on projektin ennustettavuus jo melko hyvä. Tämä lisää onnistumisen todennäköisyyttä. 

Vaatimusmäärittelyn tason perusteella voi ennustaa projektin lopputuloksen tason. Pro-

jektin hyväksymisen tulisi perustua projektin alussa tehtyihin vaatimusmäärittelyihin. 

Kun määrittelyt on tehty alkuun tarkasti ja kattavasti, toteutusvaiheeseen voidaan edetä 

verrattain nopeasti. (Tietotekniikan liitto ry. 2002: 20-21). 

 



27 

 

Valintaa tekevien henkilöiden olisi hyvä perehtyä tarjouksiin ensin itse ja omasta ydin-

osaamisalueestaan käsin ja sen jälkeen tarjoukset tulisi vasta käydä läpi yhdessä ryh-

mässä, muodostaen lopulta ryhmän yhteinen käsitys tarjouksista. Tarjousten vertailuun 

on syytä varata riittävästi aikaa, esimerkiksi kahdesta useampaan viikkoa. Tarjousvertai-

lussa otetaan huomioon kirjallisten tuotosten lisäksi toimittajien tekemät tarjousten esit-

telyt palaverissa, kuten demot sekä toimittajayrityksen tiedot ja referenssit heidän aiem-

milta tai nykyisiltä asiakkailtaan. On hyvä myös tavata kasvokkain ja haastatella tarjottuja 

projektin ydinhenkilöitä, kuten projektipäällikköä. (Tietotekniikan liitto ry. 2002: 55). 

 

Jos selvästi parasta tarjousta ei vertailun tuloksena löydy, voidaan pyytää tarkennusta 

jonkun kriteerin, vaatimuksen tai sopimusehdon osalta ja vertailua voidaan jatkaa pyy-

tämällä parhaat ehdokkaat jatkoneuvotteluihin ja pyytämällä heiltä tarkentavia tarjouk-

sia. Parhaisiin vaihtoehtoihin tutustutaan myös henkilökohtaisten tapaamisten muo-

dossa. Tätä voi pitää välttämättömänä yhteistyön, toimittajan kokemuksen ja ammatti-

taidon arvioimiseksi. Toimittajan projektihenkilöstön ansioluetteloihin kannattaa myös 

perehtyä. Tarjousten arvioinnin kohteena ovat siis: 

 

• Toimittajan organisaatio 

• Toimittajan käsitys hankittavasta järjestelmäkokonaisuudesta, hankinnan taus-

toista ja ympäristöstä 

• Toimittajan tarjoama ratkaisu ja palvelut 

• Kokonaistoteutussuunnitelma 

• Projektiorganisaatio ja -suunnitelmat 

• Hinnat ja muut veloitukset 

• Käytettävät sopimusehdot, maksuehdot ja -aikataulu 

• Ylläpidon, eli käyttäjätuen ja järjestelmätuen, saatavuus 

• Omistus- tai lisenssikysymykset 

• Takuu  

 



28 

 

Tärkeimpinä näistä voidaan pitää tarjottua järjestelmäratkaisua, palveluja, hintaa ja ko-

konaistoteutussuunnitelmasta projektin suunniteltua aikataulua.  

 (Tietotekniikan liitto ry 2002: 57-58). 

 

Toimittajan organisaation arviointi on myös ensiarvoisen tärkeää tehdä kunnolla, sillä 

parhaimmillaan hankintaa seuraa vuosia kestävä yhteistyösuhde tai kumppanuus. Tavoi-

tellun yhteistyön laadusta riippuen on etsittävä erilaisia merkkejä siitä, kuinka hyvin esi-

merkiksi yrityskulttuurit sopivat yhteen. Projektihenkilöstön kyvykkyys on merkittävä te-

kijä projektin onnistumisen kannalta, mutta kommunikaation ja yhteensopivan kulttuu-

rin merkitystä ei pidä myöskään väheksyä.  Tarjousta on myös hyvä arvioida kokonaisuu-

tena; miten hyvin on osattu kitetyttää tarjotun ratkaisun edut, rajoitukset ja miten se 

kokonaisuutena toteuttaa hankinnan tavoitteita. Työmääräarvioissa kannattaa kiinnittää 

huomiota siihen, kuinka paljon aikaa on varattu testaukseen verrattuna suunnitteluun, 

määrittelyihin ja toteutukseen. Näiden pohjalta voidaan jo ennalta arvioida lopputulok-

sen laatua ja toimittajaorganisaation tehokkuutta. (Tietotekniikan liitto ry. 2002: 59). 

 

Kun valinta on tehty, siirrytään sopimuksen tekemiseen. Sopimuksen tulee kattaa sekä 

projektin käyttöönotto, että ylläpitoon siirtymisen vaihe. Sopimuksissa ei saisi olla liian 

suuria tai hallitsemattomia riskejä taikka vastuita. Asiakkaan kannalta ihannetilanteessa 

sopimus on asiakkaan kirjoittama, mutta yleensä päädytään toimittajan laatimaan sopi-

muskokonaisuuteen, joka tarkistutetaan ensin asiantuntijoilla. (Myllymäki, Hinkka, Hir-

vensalo & Hämäläinen 2011: 42). 

 

 

3.4 Hankintaprosessi 

Suurten ohjelmistojen hankinnassa julkisten elinten on noudatettava tiettyjä hankinta-

menettelyjä. Tarjouskilpailua koskevan lainsäädännön tavoitteena on varmistaa ohjel-

mistotoimittajien tasapuolinen kohtelu, valintaprosessin läpinäkyvyys, vaatimusten suh-

teellisuus ja syrjimättömyys toimittajien kansallisen taustan perusteella (Moe 2014).  

 



29 

 

Nämä normit eivät kuitenkaan koske ohjelmien valinnassa käytettäviä päätöksenteko-

menettelyjä. Myös tutkimuksissa on kiinnitetty vain vähän huomiota julkisten ohjelmis-

tojen hankintaprosessiin, lukuun ottamatta näiden strategisten prosessien erityistehtä-

vien kuvaustutkimuksia, kuten Moen katsaus osoittaa (Moe 2014). Tässä tyhjiössä kehi-

tetään vastakkaisia näkemyksiä julkisista hankinnoista. Jotkut tekijät viittaavat siihen, 

että ostajat voivat silti helposti manipuloida valintaprosessia, jotta se voi antaa tilauksen 

ensisijaiselle toimittajalle. Tämä näkemys merkitsee sitä, että tarjouskilpailulainsäädäntö 

on tuskin tehokas julkisten hankintojen valvonnassa. Vastoin tätä näkemystä toiset, myös 

Euroopan unioni (2014), vaativat, että tarjouskilpailulainsäädäntö antaa toimittajille yh-

täläiset mahdollisuudet ja helpottaa ostajia hankkimalla ohjelmistoja, jotka täyttävät hei-

dän vaatimuksilleen alhaisimman hinnan. (Boonstra & Offenbeek 2018: 906). 

 

Tieotojärjestelmien hankintojen analyysi on ollut niukkaa (Heiskanen, Newman & Similä 

2000), ja vaikka julkisia hankintoja koskevien julkaisujen määrä on kasvanut huomatta-

vasti, sama niukkuus vaivaa edelleen tutkimusta. Tutkimuksia tehdään yleisesti enem-

män julkisista, kuin yksityisistä hankkeista. Tämä johtunee siitä, että julkisista hankkeista 

on saatavilla tietoa enemmän ja helpommin.  

 

Tähän mennessä tutkimus on keskittynyt erityisesti tietojärjestelmähankintojen proses-

siin ja yllättävän harvat järjestelmälliset tutkimukset kattavat ohjelmistopakettien han-

kinnan (Pollock & Williams 2007). On kuitenkin olemassa joitakin tutkimuksia, joissa kä-

sitellään prosessin tiettyjä vaiheita ja tehtäviä. (Moe 2014: 1323). Näitä myös Moe (2014) 

käsittelee omassa tutkimuksessaan. Kuvio 1. esittelee hankintaprosessin yleiskuvan 

vaihe vaiheelta. Sama tietojärjestelmähankintaprosessin yleiskaava pätee sekä julkisen 

että yksityisen puolen järjestelmähankintoihin.  



30 

 

 

Kuvio 1. Hankintaprosessin yleiskuva (Moe 2014: 1324). 

 

Kun organisaatio on hankintaprosessissa, sen on ensin päätettävä, mitä ollaan hankki-

massa, sekä miten valita paras vaihtoehto. Tämä vaihe suoritetaan yleensä vaatimus-

määrityksessä. Vaatimusmäärittelyn perusteella organisaatio pyytää tarjouksia. Tarjous-

kilpailu on toimittajille tarkoitettu kutsu valmistella tarjous ja toimittaa se tietyssä mää-

räajassa. Tietojärjestelmähankinnoissa neuvottelut voidaan toteuttaa osana toimittajan 

valintaa. Neuvotteluissa voidaan käsitellä eri kysymyksiä kuten hintaa, toteutusaikatau-

lua ja sitä, mitä lisäpalveluja projektiin on tarkoitus sisällyttää. Nämä neuvottelut voivat 

myös helpottaa päätöstä siitä, kattaako tarjous kaikki vaatimukset. Julkisissa hankin-

noissa voittaja voidaan valita ainoastaan hinnan tai hinnan ja laadun perusteella. Yksityi-

sellä organisaatiolla on mahdollista perustaa päätös myös muihin kriteereihin. Kun voit-

taja on valittu, tehdään kyseisen toimittajan kanssa sopimus. Julkisissa hankinnoissa 

hankintayksikkö ilmoittaa päätöksenkaikille tarjouskilpailuun osallistuneille tahoille ja 

antaa heille määräajan, jonka kuluessa valitus hankinnasta voidaan tehdä, jos uskotaan, 

että prosessi ei ole ollut asetusten mukainen. (Moe 2014: 1324). 

 

Tutkimus on osoittanut, että järjestelmän hankintaprosessi jatkuu vielä valinnan jälkeen-

kin, koska valittu myyjä ei välttämättä pysty täyttämään 

Vaatimusmäärittelyn 
kehitys

Tarjouskilpailu Valinta

Sopimusneuvottelut Toteutus
Valmistuminen / 

loppuun saattaminen



31 

 

lopullisia vaatimuksia. Eri toiminnallisilta alueilta tulevien käyttäjien osallistuminen on 

todettu olevan tarpeen. Eri sidosryhmien välisten eturistiriitojen mahdollisuus 

edellyttää sidosryhmien hallinnointia. (Moe 2014: 1328). 

 

Ne tunnistavat useita kriittisiä menestystekijöitä toiminnanohjausjärjestelmien hankin-

nassa, mukaan lukien sidosryhmien lähestymistapa hankkijaryhmä, johon osallistuvat 

henkilöt, joilla on ennakkotieto järjestelmän tyypistä. Tutkimus käsittelee tietojärjestel-

mähankinnan vaiheita ehdotuspyynnöstä (RFP), tarjouskilpailuun, toimittajien valin-

nasta (mukaan lukien neuvottelut), sopimuksiin, hankinnan täytäntöönpanoon ja projek-

tin loppuun viemiseen saakka. (Moe 2014: 1328). 

 

Vaatimusten täsmentäminen on hankkeen ensimmäinen muodollinen vaihe. Prosessi 

kuitenkin alkaa siitä, kun hankkitaan tietoja tarpeista järjestelmähankinnan taustalla. 

Tarve voi syntyä eri syistä: vanha järjestelmä saattaa olla tarpeen päivittää uusilla toimin-

noilla tai sen tulisi olla integroitu muihin järjestelmiin, vanha järjestelmä ei ehkä enää 

tue nykyisiä toiminnalisuusvaatimuksia, tai hankintayksiköllä ei ehkä ole järjestelmää 

lainkaan. Syyt hankinnan taustalla voivat vaikuttaa vaatimuksien määrittelyn monimut-

kaisuuteen. Myyjät eli järjestelmäpartnerit voivat myös itse osallistua vaatimuksien mää-

rittelyyn. Tapaustutkimus laboratoriojärjestelmän hankinnasta norjalaisessa sairaalassa 

osoittaa, miten yksi järjestelmäpartnereista oli mukana innovaatioprojektissa, joka myö-

hemmin käytettiin perustana vaatimusten määrittelylle. (Moe 2014: 1325). 

 

Toinen asia, joka voi vaikuttaa vaatimusten määrittelyyn on politiikan laatiminen ja sen 

hallitseminen (ks. kuvio 1 ylempänä). Me voivat odottaa jännitteitä tai dilemmeja avoi-

men ja reilun kilpailun tavoitteen ja hankinnan soveltamisen välillä välineitä tiettyjen po-

liittisten tavoitteiden saavuttamiseksi. Molemmat ongelmat vaativat enemmän tutki-

musta. (Moe 2014: 1325). 

 

Tietohallintojohtajat, hankintapäälliköt ja myyjät kokevat merkittäviä haasteita vaati-

muksien kanssa. Vaikka hankintapäälliköt ja tietohallintoviranomaiset koittaisivat luoda 



32 

 

selvää ja täydellistä kuvaa vaatimuksista ja tarvittavista yksityiskohdista, myyjien tai jär-

jestelmäpartnereiden mielestä vaatimusmääritykset voivat olla liian yksityiskohtaisiksi 

kuvattuja ja toisaalta taas laajoja (Moe & Päivärinta, 2013). Tästä syystä tarvitaan lisää 

tutkimusta niistä syistä, jotka johtavat näihin keskenään ristiriitaisiin vaatimusmääritte-

lyiden ongelmiin ja miten ne voitaisiin välttää. (Moe 2014: 1325). 

 

Käyttäjien vähäinen osallistuminen järjestelmäkehitykseen johtaa ongelmiin ja sama asia 

koskee myös tietojärjestelmähankintojen vaatimusmäärittelyä. Tähän mennessä tieto-

järjestelmähankintoja koskevassa tutkimuksessa ei ole käsitelty asiaa, mutta se olisi tär-

keää, jotta voitaisiin ymmärtää miten käyttäjiä ja muita sidosrymiä voidaan ottaa tehok-

kaasti mukaan hankintaprosessiin. (Moe 2014: 1326). 

 

Järjestelmän valintavaihe alkaa siitä, kun organisaation hankintaryhmä saa tarjouksia kil-

pailevilta toimittajaehdokkailta ja päättyy toimittajan valintaan. Julkista tarjousta edel-

lyttävien hankintojen osalta valinta voi perustua yleensä joko alimpaan hintaan tai talou-

dellisesti edullisimpaan tarjoukseen (engl. most economically advantageous tender, 

MEAT). Taloudellisesti edullisin tarjous yhdistää eri kriteerejä, mukaan lukien kustannus-

tehokkuus, esteettinen ominaisuus (käyttöliittymä) sekä järjestelmän ylläpitopalvelut. 

Kaikkien hankintaan osallistujien tulisi olla tietoisia valintakriteereistä, kun ehdotus-

pyyntö (Request For Proposal) ilmoitetaan. (Moe 2014: 1326). 

 

Huomattava osa hankintaprosessin työstä keskittyy päätöksentekokriteereihin ja opti-

maalisiin ratkaisuihin. Järjestelmätoimittajan pätevyys on tärkeää toimittajan valinnassa. 

Lisäksi yksityisten ja julkisten terveydenhuoltopalvelujen järjestelmähankinnoista tehty 

tutkimus osoittaa, että vaikka aiemmat suhteet toimivat usein merkittävänä valintakri-

teerinä yksityisen sektorin valinnoissa, julkinen sektori perustaa valintansa lähes yksin-

omaan hintaan. Avointen markkinoiden kilpailua käytetään hintaan perustuvissa hankin-

tamenetelmissä ja jokaisen hankinnan tulisi ideaalitilanteessa olla riippumatton aiem-

mista suhteista ja hankinnoista. (Moe 2014: 1326). Käytännössä tämä harvoin toteutuu 

yksityisellä sektorilla. Julkisellakin puolella sääntelyssä on joitain aukkoja, jotka 



33 

 

mahdollistavat järjestelmävalinnan perustuen jossain määrin aiempiin toimittajasuhtei-

siin. (Moe 2014).  

 

Eri kriteerien tasapainottelun haastavuus kasvaa sen mukaan, mitä enemmän sidosryh-

miä valinnassa on mukana. Valmiiden järjestelmien hankiinnassa on tärkeää, että loppu-

käyttäjät ovat jo valintavaiheessa mukana ja organisaation tulisi varautua tekemään 

kompromisseja eri toiminnallisuuksien suhteen. Tutkimuksissa onkin ollut keskiössä eri 

käyttäjä- tai sidosryhmien tavoitteiden väliset erot toimittajaa ja järjestelmää hakittaessa. 

Päätöksentekomalli sisältää usein sekä esikarsinnan että lopullisen valinnan ja siihen voi 

osallistua useita eri sidosryhmiä (Moe 2014: 1327).  

 

Henkilöstöjärjestelmä poikkeaa tässä kohden muista järjestelmähankinnoista, sillä sekä 

esikarsintaan että lopulliseen valintaan osallistuu rajatumpi joukko henkilöitä. Ainakaan 

useampi sidosryhmä ei ole yleensä edustettuna päätöksenteossa, vaan sen tekevät or-

ganisaation sisäiset henkilöt. Yleensä nämä henkilöt ovat henkilöstö- ja IT-osaston päät-

täjät sekä lopullisessa päätöksentekovaiheessa johtoryhmä, joka antaa viimeisen hyväk-

synnän hankintaryhmän ehdotukselle.   

 

Valintavaiheessa on mahdollista, että hankkijan ja myyjän välille muodostuu informaa-

tion epäsymmetria. Tietojen epäsuhtaisuus on tavallista etenkin tietojärjestelmäkonsul-

toinnin alalla. Näiden havaintojen pitäisi olla merkityksellisiä myös järjestelmän ostajille. 

Hankintaryhmän on hyvä käyttää neuvotteluja apukeinona palveluntarjoajan valinnassa. 

Myös tapaustutkimuksen tulokset osoittavat, että neuvottelumenettely on kaikista sopi-

vin järjestelmähankintoja ajatellen. (Moe 2014: 1327). 

 

Teollisuuden analyytikoiden, kuten Gartner-ryhmän, tiedetään vaikuttavan hankintapro-

sesseihin (Pollock & Williams 2007). Pollockin ja Williamsin tutkimus osoittaa, että mark-

kina-analyysi vaikuttaa erityisesti toimittajien valintaan. Tarvittaisiinkin lisätutkimuksia 

siitä, missä määrin virallisia ja objektiivisia markkina-analyysien myöntämisperusteita so-

velletaan järjestelmävalinnassa ja mitkä muut kriteerit vaikuttavat valintaan.  



34 

 

 

Moen (2014) tutkimuksen tulokset osoittavat, kuinka monimutkaisia julkisten järjestel-

mähankintojen prosessit ovat. On haastavaa kehittää selkeitä, mutta ei kuitenkaan liian 

yksityiskohtaisia vaatimuksia. On myös vaikeaa tasapainotella vaatimuksien etukäteisen 

määrittelyn ja hankintaprosessin aikana tehtävän järjestelmän yksityiskohtaisemman 

määrittelyn välillä. Moen tutkimuksen tulokset osoittavat myös, että järjestelmän tarjo-

ajille jää valtuus vastata siitä, täyttävätkö he järjestelmävaatimukset vai eivät, ja usein 

kommunikointi julkisen hankintayksikön ja myyjien välillä on kielletty. Tällöin ei siis jää 

tilaa vaatimusten tarkentamiselle. Eri sidosryhmistä loppukäyttäjien osallistaminen ko-

rostuu hankintaprosessissa, mutta myös muita sidosryhmiä tulee osallistaa tarpeen mu-

kaan prosessiin. Tällöin eri sidosryhmien potentiaalisesti keskenään ristiriitaiset tavoit-

teet luovat lisähaastetta. Kaiken kaikkiaan järjestelmän hankintaprosessi on pitkä, eikä 

pääty ennen hankittu järjestelmä on otettu käyttöön ja hankintaorganisaatio katsoo, että 

sopimus on pantu täytäntöön. Itse hankinnasta ja prosessin eri vaiheista ei ole tehty tar-

peeksi tutkimusta. (Moe 2014: 1330). 

 



35 

 

4 Projektin hankinnan hallinta 

4.1 Projektin hankinnan vaiheet ja hallinta  

Projektin hankinnan hallinta (engl. Project procurement management) on yksi tärkeim-

piä osa-alueita tietojärjestelmähankkeissa, sillä uuden järjestelmän käyttöönotto tarkoit-

taa lähes poikkeuksetta projektiin ryhtymistä. Hankinnan kustannuksien laskenta jäl-

keenpäin, riskien arviointi ja hallinta sekä laadun valvonta ovat tietojärjestelmähankin-

taprojektien heikoimmin hoidettuja osa-alueita. Jokainen ohjelmistohankinta on inves-

tointi, joka vaatii kustannusten, hyötyjen ja haittavaikutusten arviointia. (Tietotekniikan 

liitto ry 2002: 14). Varsinkin henkilöstöjärjestelmien hankinnassa kokonaiskustannusten 

arviointi etukäteen voi olla haastavaa ja investoinnista saatavaa hyötyä ei välttämättä 

pystytä mittaamaan tarkkaan rahallisesti.  

 

Määrittelyjä, jotka tehdään projektin valmisteluvaiheessa, joudutaan usein tarkenta-

maan ja muokkaamaan ennen itse järjestelmäprojektin toteutusta. Määrittelytyöhön 

voidaan ostaa apua ulkopuolelta osana kokonaishankintaa, mutta vaatimuksien ja toimi-

tatapojen määrityksien ja tarpeiden täytyy kuitenkin tulla organisaation sisältä. Ulkopuo-

lisen konsultin näkemys määrittelyn tukena voi kuitenkin tuoda prosessiin mukaan hyviä 

uusia näkökulmia, joita organisaatio ei olisi itse löytänyt. Ulkopuolisella konsultilla olisi 

hyvä olla kokemusta samalle toimialalle tehdyistä järjestelmähankkeista tai toimialan jär-

jestelmistä ja toimittajan menetelmien ja käytäntöjen tulisi olla yhteensovitettavissa 

hankkivan organisaation omien mallien kanssa. (Tietotekniikan liitto ry 2002: 28). 

 

Jos määritysprosessissa käytetään ulkopuolista apua, voi olla järkevää tehdä myös tekni-

nen suunnittelu saman toimittajan kanssa, jos tässäkin vaiheessa halutaan käyttää ulko-

puolista apua. Myöhemmin myös käyttöönoton tukemisessa saatetaan tarvita ulkopuo-

lista apua ja tämä olisi hyvä huomioida jo hankintaa suunniteltaessa. Apua voidaan tar-

vita esimerkiksi järjestelmäasennuksiin, käyttäjien ja järjestelmän pääkäyttäjien tai tuki-

henkilöiden koulutuksiin, viestintään, käyttöohjeiden tekemiseen ja itse käyttäjätukeen. 

(Tietotekniikan liitto ry 2002: 29). 



36 

 

 

Projektia ei välttämättä tarvitse hankkia tarjouskilpailun kautta. Se saattaa jopa olla kallis 

ja aikaa vievä prosessi, mutta toisaalta usein myös ainoa tapa saada selville kaikista ta-

loudellisen vaihtoehto sekä toimittajan että järjestelmän suhteen. Julkisisssa hankin-

noissa tarjouskilpailu on usein kuitenkin ainoa mahdollinen tapa tehdä hankintaa, puite-

sopimuksien ollessa poikkeus. (Tietotekniikan liitto ry 2002: 29). 

 

Hankintasuunnitelmassa tulee kuvata tarjousvaiheessa sovellettavat prosessit, joita käy-

tetään potentiaalisten toimittajien kanssa kommunikointiin ja asioiden hoitamiseen. Esi-

merkiksi toimittajien kysymykset ja niihin annettavat vastaukset on hyvä saattaa kaikkien 

potentiaalisten toimittajien tietoon, jotta kaikilla olisi yhtäläiset mahdollisuudet tarken-

taa tarjoustaan tilanteen mukaan. Hankintatilanteessa asiakas, eli hankkivan organisaa-

tion edustaja, on aina oman toimintansa asiantuntija ja toimittaja taas edustaa järjestel-

mäasiantuntijaa. Asiakkaan on kuitenkin kannattavaa kuunnella toimittajien näkemyksiä 

hankintavaiheessa, eikä omista näkemyksistä kannata pitää liian tiukasti kiinni vielä val-

misteluvaiheessa. Asiakkaan omia näkemyksiä on syytä jopa muutta hyvien perustelujen 

edessä, eli jos joku toimittajaehdokkaista esittää idean tai näkökannan, jota asiakas ei 

ollut tullut ajatelleeksi. Ideaalitilanteessa hankintavaiheessa esille tulleita uusia ideoita 

pystytään hyödyntämään järjestelmäprojektin myöhemmissä vaiheissa. (Tietotekniikan 

liitto ry 2002: 29-30). 

 

Julkiset hankinnat on periaatteessa Suomessa aina tehtävä kilpailutuksen kautta. Poik-

keukset on perusteltava hyvin ja tiettyjen kriteerien, kuten budjetin, täyttäessä rajan jul-

kinen hankinta täytyy lisäksi kilpailuttaa EU-direktiivin mukaisesti. Tällöinkin hankinnassa 

on kolme eri vaihtoehtoa; avoin, rajoitettu tai julkinen hankinta. (Tietotekniikan liitto ry 

2002: 30).  

 

Boonstra & Offenbeek (2018) käsittelevät sitä, miten tarjouskilpailulainsäädännöllä voi-

daan vaikuttaa ostajan tietojärjestelmävalikoimaan. Lainsäädännön tavoitteena on pa-

rantaa kilpailukykyä edistämällä tasa-arvoa, suhteellisuutta, avoimuutta ja 



37 

 

syrjimättömyyttä. Tällaista lainsäädäntöä sovelletaan julkisten laitosten ohjelmistopaket-

tien hankintaan monissa maissa. Boonstra ja Offenbeek tutkivat tapaustutkimuksen 

kautta, miten tarjouskilpailulainsäädäntö muodostaa ostajan ohjelmistovalintaprosessin 

kilpailevien päätöksentekoratkaisujen kautta. Tapausesimerkkinä toimii suuri terveyden-

huoltoalan organisaatio, joka valitsi tietojärjestelmätoimittajan laajan tarjouskilpailun 

jälkeen. Monet organisaatiossa tysökentelevät terveydenhuollon ammattilaiset kannat-

tivat tiettyä ohjelmistoratkaisua, mutta järjestö päätyi ostamaan toisen paketin melko 

tuntemattomalta toimittajalta. Järjestelmäprojekti epäonnistui. Tutkimuksen tulokset 

osoittavat, että tarjouskilpailulainsäädäntö voi olla uhka hankkeen toiminnalliselle pe-

rusteelle. 

(Boonstra & Offenbeek 2018: 905). 

 

Hankinta voi koostua yhdestä tai useammasta sopimuksesta ja sille voidaan asettaa ta-

loudellisia, normatiivisia tai projektityöhön liittyviä vaatimuksia. Erityisesti sopimuksen 

joustavuuden määrittämiseen kannattaa kiinnittää huomiota ja määritellä tarkkaan, 

mistä pidetään ehdottomasti kiinni, missä voidaan joustaa ja minkä verran. Sopimus-

luonnos kannattaa käydä läpi kokeneen sopimusvastaavaan tai esimerkiksi lakimiehen 

toimesta. (Tietotekniikan liitto ry 2002: 30).  

 

Kerzner (2017) määrittelee hankinnan palveluiden ja tavaroiden ostamiseksi. Hankinta 

on prosessi, jossa on kaksi osapuolta ja näillä osapuolilla eri tavoitteet ja jotka kohtaavat 

tietyllä markkinasegmentillä. Hyvät hankintamenetelmät voivat lisätä organisaation tu-

loksellisuutta esimerkiksi paljousalennuksien hyödyntämisen avulla sekä valitsemalla 

laadukkaita toimittajia. Koska hankinta liittyy läheisesti tuottavuuteen, se on usein kes-

kitetty ja organisaation hankintakäytännöt on standardisoitu. Hankintastrategiat ovat vii-

tekehyksiä, joiden avulla organisaatio pääsee tavoitteisiinsa.  

 

Hankinnan suunnittelussa valitaan usein yksi seuraavista strategioista: 

• Keskitetään hankinta yhdelle toimittajalle 

• Hankitaan useammalta eri toimittajalta 



38 

 

• Hankitaan vain osa palvelusta 

• Ei hankita mitään  

(Kerzner 2017: 662 - 663). 

 

Valinta voi olla joko hintaperusteinen tai se voidaan tehdä arvioimalla, mikä tarjous tuot-

taa parhaan arvon orgnanisaatiolle. Parasta arvoa tuottavan vaihtoehdon valinnan ai-

kana oganisaation on tehtävä kompromisseja hinnan, suoritustuskyvyn, ja muiden hin-

taan liittymättömien tekijöiden välillä. Tärkeimmät kriteerit yleensä aikataulu, hinta, ole-

tettu projektitiimi, sekä aiempi suoriutuminen vastaavista projekteista. Kriteerejä voi-

daan painottaa eri tavoin. (Kerzner 2017: 669 - 670). 

 

Valintaa ei tehdä välttämättä pelkästään tämän kriteeristön avulla. Neuvottelut voivat 

esimerkiksi kuulua valintaprosessiin. Asiakas voi pitää useasta eri tarjolla olevasta ideasta 

eri tarjouksissa ja siten yrittää saada parhaan toimittajan ottamaan mukaan lisätyötä 

muiden toimittajien tarjouksista, kuitenkin ilman lisäkustannuksia. Neuvotteluproses-

sissa käydään myös läpi mitä projektiin sisältyy ja mitä jätetään sen ulkopuolelle. Neu-

votteluprosessi voi olla joko kilpailutilanne, tai se voidaan käydä vain yhden toimittajan 

kanssa. Kilpailuttomia neuvotteluja kutsutaan yhden lähteen hankinnoiksi. Neuvottelu-

suunnitelmaan kuuluvat kehitystavoitteet, vastapuolen arviointi, strategian ja taktiikan 

määrittely, faktojen kerääminen, hinta/kustannusanalyysi, sekä hygieniatekijöiden huo-

mioon ottaminen. Toimittajasuhteet ovat kriittisiä neuvotteluprosessin aikana. Suhteen 

eheys ja aiempi historia toimittajan kanssa voivat lyhentää neuvotteluprosessia. Tässä 

kolme päätekijää ovat kyky kompromisseihin, sopeutumiskyky sekä hyvä usko. (Kerzner 

2017: 669 - 670). 

 

Järjestelmäprojektissa hankitaan ensisijaisesti palvelua, eikä pelkkää järjestelmää. Tämä 

tarkoittaa, että hankintaa koskee ihmisten tekemää työtä ja siksi on tärkeää, että hankin-

taorganisaation henkilöt pystyvät arvioimaan oikein mahdollisia toimittajayrityksiä kos-

kevia tietoja, kuten referenssejä, osaamistasoa sekä projektiin tarjottuja henkilöitä. Tar-

jotun ratkaisun arvioimiseen tarvitaan osaamista järjestelmän toiminnallisuuksista, 



39 

 

teknisistä ja laadullisista vaatimuksista sekä ominaisuuksista. Käyettävissä olevien resurs-

sien määrää ja laatua on osattava arvioida realistisesti sekä toimittajan että ostavan or-

ganisaation puolelta ja niitä on arvioitava projektin suunnitelmaa, kuten vaiheistusta, 

tehtävien järjestystä ja keskinäisiä riippuvuussuhteita sekä työmäärää vasten. Hintojen 

arviointi edellyttää markkinatilanteen tuntemusta sekä investointiajattelua. Halvin hinta 

ei yleensä ole ratkaisevin valintakriteeri. (Tietotekniikan liitto ry. 2002: 38). 

 

Toimittajaa koskevilla vaatimuksilla voidaan karsia sopimattomia toimittajia jo ennalta. 

Tällä voidaan säästää myös aikaa, kun tarjouspyyntöä tarkasteltaessa voidaan todeta, 

ettei yritys täytä asetettuja vaatimuksia. Tarjouspyynnössä voidaan myös mainita erik-

seen kriteerit, joilla tietty toimittaja voidaan valita suoraan ilman erillistä tarjouskilpailua. 

Vaatimukset voivat liittyä organisaation kokoon ja vakavaraisuuteen, erilaisiin sertifioin-

teihin sekä referensseihin samalta toimialalta tai muuten vastaavasta toimituksesta. Ali-

hankkijoiden käyttämisen rajoituksista voidaan myös mainita jo tarjouspyynnössä. (Tie-

totekniikan liitto ry. 2002: 48). 

 

Tietojärjestelmän hankintapäätös kannattaa aina tehdä kokonaistaloudellisen edullisuu-

den mukaan, mikä tarkoittaa valintakriteerien ja niiden painoarvojen kuvaamista ja käyt-

tämistä valinnassa. Arviointikriteereissä luetellaan, mtä kriteereitä käyttäen ja millaisin 

painoarvoin toimittajia ja ratkaisuja arvioidaan. Kriteerit voidaan luetella esimerkiksi tau-

lukkomuodossa. Kun on kyse julkisesta hankinnasta, kriteerit on pitänyt ilmoittaa en-

nalta ja vain niitä voidaan käyttää valintaa tehdessä. Ehdottomiksi kriteereiksi kutsutaan 

niitä vaatimuksia, joita ilman tarjousta ei voida hyväksyä. Kriteerit tulee lisäksi perustella 

ja kertoa painotuksien taustat, sekä kuvata menettely, miten kriteereitä sovelletaan toi-

mittajia ja järjestelmiä vertaillessa. (Tietotekniikan liitto ry. 2002: 49). 

 

Hankintapäätöksellä vahvistetaan parhaan tarjouksen tehneen toimittajan valinta. Tar-

jousta verrataan hankintasuunnitelmaa vasten, eli tarkistetaan, että tarjous vastaa suun-

nitelman liiketoiminnallisiin tavoitteisiin sekä verrataan tarjousta muihin varteenotetta-

viin vaihtoehtoihin. Kun päätös on tehty, laaditaan varsinainen sopimus toimittajan 



40 

 

kanssa sekä ryhdytään projektin toteutukseen. Hankinta tulee perustella ja esittää erilli-

senä hankintaesityksenä. Esitys sisltää perustelujen lisäksi muun muassa vaihtoehtojen 

vertailun ja kustannusanalyyysin organisaatiosta riippuen. Lopullinen ja virallinen han-

kintapäätös tehdään tämän esityksen pohjalta. Sen tekee usein yrityksen johtoryhmä, tai 

hankintapäätös voidaan joutua hyväksyttämään useallakin eri taholla, jotka tarkastelevat 

esitystä eri näkökulmista, kuten teknologian ja liiketoiminnan kannalta. Päätöksestä tie-

dotetaan kaikille tarjouskilpailuun osallistuneille. (Tietotekniikan liitto ry. 2002: 61-63). 

 

 

4.1.1 Hankintaorganisaatio 

Hankintaa suorittavassa kokoonpanossa, eli hankintaorganisaatiossa, tulee olla riittä-

västä sekä tekniikan että liiketoiminnan päälle ymmärtäviä henkilöitä. Tämänkaltaisten 

henkilöiden tulisi myös osallistua projektiin implementointivaiheessa. On siis varattava 

riittävästi osaavia resursseja koko projektin ajaksi, sillä kaikkea ei voi jättää toimittajan 

harteille. Osaavakaan toimittaja ei voi tehdä projektia itse, sillä vaikka toimittajan puo-

lelta löytyy järjestelmäosaamista, orgnanisaation on pystyttävä toimimaan itse omien 

vaatimustensa ja tarpeidensa asiantuntijana. (Tietotekniikan liitto ry 2002: 31). 

 

Hankintaorganisaation kokoonpano voi vaihdella hankinnan eri vaiheissa. Hankintaor-

gansaation roolit voidaan jakaa karkeasti kolmeen eri ryhmään;   

1. niihin, jotka osallistuvat valintaprosessin valmisteluun ja toteuttamiseen,  

2. niihin, jotka tekevät hankintapäätöksen koskien järjestelmää ja sen toimittajaa  

3. sekä niihin, jotka osallistuvat hankittavana olevan projetkin toteuttamiseen, oh-

jaukseen ja viimeistelyyn.  

(Tietotekniikan liitto ry 2002: 31). 

 

Hankintaorganisaatioon kuuluvilla henkilöillä on oltava valtuudet tehdä hankintaa kos-

kevia ratkaisuja ja päätöksiä. Tärkeä rooli on hankittavan järjestelmän omistajuus, ja tä-

män henkilön olisi hyvä olla mukana jo heti hankintavalmisteluissa ja hänellä tulisi olla 



41 

 

päätösvaltaa hankintaprosessissa, jotta voidaan varmistaa hänen sitoutumisensa hank-

keeseen. (Tietotekniikan liitto ry 2002: 31). 

 

Organisaation johtamisjärjestelmän ja kulttuurin tulisi tukea projektin onnistumista. Tätä 

edesauttaa prosessien tunnistaminen ja omistajien nimeäminen proseseille, se, että or-

ganisaatiossa on tunnistettu avaintiedot ja niille on nimetty omistajat, ja näillä omistajilla 

on riittävästi osaamista, aikaa, valtaa ja vastuuta hoitaa tehtävänsä kunnolla. (Myllymäki, 

Hinkka, Hirvensalo & Hämäläinen 2011: 25). 

 

Johdon tuki on projektin ensimmäinen onnistumisen edellytys. Johdolta projektille saa-

daan budjetti sekä muut raamit, joista jo pystyy päättelemään, kuinka tärkeästä projek-

tista on kysymys. Uuden tietojärjestelmän käyttöönotto vaatii aina jonkin tasoisen toi-

minnan muutoksen organisaatiossa. Muutos voi olla organisaatiolle hyvinkin vaikeaa ja 

ilman johdon tukea muutosprosessin onnistuminen on usein vaakalaudalla. (Tietoteknii-

kan liitto ry. 2002: 20). 

 

Organisaation hankintayksiköillä ei välttämättä ole tarvittavaa ole sisäistä pätevyyttä eri 

järjestelmävaihtoehtojen arvioimiseen, joka on omiaan vaikeuttamaan vaatimusten 

määrittelyprosessia. Usein hankintayksikön ja toimittajan tietämys eri kysymyksistä on 

eri tasolla, kuten esimerksi tietämys järjestelmävaatimuksista. Jotta hankittava tietojär-

jestelmä vastaisi parhaalla mahdollisella tavalla organisaation monitahoisiin vaatimuk-

siin, on keskusteluyhteys toimittajaehdokkaiden ja hankkivan organisaation välillä tär-

keää hankintaprosessin eri vaiheissa. Kun on kyse julkisesta hankinnasta, EU-sekä kan-

sallinen lainsäädäntö rajaavat tätä mahdollisuutta. Oikeudelliset vaatimukset johtavat 

siihen, että julkisella sektorilla hankintaprosessi on monimutkaisempi yksityiseen verrat-

tuna, eikä dialogi toimittajien ja hankintaryhmän välillä ole välttämättä edes sallittua. 

(Moe 2017: 144-145).  

 

Tietojärjestelmähankinnoissa kokemus on ehdottomasti kriittinen tekijä hankinnan on-

nistumisen kannalta. Lisäksi vuoropuhelu toimittajaehdokkaiden kanssa, sekä prosessien 



42 

 

demonstrointi oikean datan avulla auttavat määrittelemään järjestelmävaatimukset tar-

peeksi tarkasti, sekä huomaamaan jo ennen projektin alkamista, mitkä vaatimuksista on 

oikeasti mahdollista ja realistista täyttää. Yksityiskohtaisten vaatimusten laatiminen sekä 

tarpeeksi syväluotaava tarjouskilpailu vievät paljon aikaa ja resursseja, mutta se kannat-

taa hankinnan lopputuloksen kannalta. Jos hankintayksiköiltä puuttuu sisäinen pätevyys, 

he voivat saada apua vaatimuksien määrittelyyn esimerkiksi oppimalla vastaavien orga-

nisaatioiden hankintaprosesseista ja vaatimuksista, joita ne ovat käyttäneet. Tämän kal-

tainen toiminta vähentää tarvetta olla yhteydessä suoraan toimittajien kanssa, mutta ei 

korvaa sitä. (Moe 2017: 155). 

 

Jos vaatimukset eivät ole monimutkaisia ja järjestelmä ei ole ainutlaatuinen, hankintayk-

siköllä todennäköisesti on riittävä sisäinen pätevyys määritellä vaatimukset. Jos ei, vaa-

timukset voidaan 'lainata' muilta vastaavilta organisaatiolta, joilla on samantyyppinen 

järjestelmä käytössä. Nämä vaatimukset on kuitenkin räätälöitävä koskemaan juuri tätä 

hankintaa ja organisaatiota. Tehokkaimpia hankintamenettelyjä ovat avoimet tai rajoite-

tut tarjouskilpailut. Jos vaatimukset ovat monimutkaisia, mutta järjestelmä ei ole ainut-

laatuinen tai hankintayksiköllä on rajallinen pätevyys, oppiminen muiden vastaavien or-

ganisaatioiden verkoston kautta on tehokas strategia. Vuoropuhelua toimittajaehdokkai-

den eli myyjien kanssa voidaan edelleen vaatia, jotta vaatimukset saadaan varmasti täy-

tettyä. Tällöin hankinnassa käytetään menettelynä tarjouskilpailua, joka sisältää myös 

neuvottelun toimittajien kanssa. (Moe 2017: 158).  

 

Järjestelmän tulevia loppukäyttäjiä voidaan hyödyntää vaatimusten määrittelyssä tehok-

kaana tietolähteenä. Käyttäjät tulisikin aina osallistaa mahdollisuuksien mukaan hankin-

taprosessiin. Jos hankintayksikkö edustaa itse käyttäjiä ja vaatimukset ovat silti epäselvät, 

vuorovaikutus toimittajien kanssa auttaa selvittäämään niitä. Vuorovaikutus toimittajien 

kanssa antaa myös oppimismahdollisuuden hankintayksikölle. Parhaimmillaan hankinta 

tapahtuu yhdessä toimittajan ja hankintayksikön kanssa vuorovaikutuksessa. Tässä piilee 

kuitenkin vaara toimittajan hyväksikäytölle, kun heidän valtansa hankinnassa lisääntyy. 



43 

 

Asiakassuhteen jatko ja pitkäaikaisuus ovat kuitenkin hyvin tärkeitä toimittajille, samoin 

kuin hyvä maine. (Moe 2017: 157). 

 

Hankintaorganisaatioon voi kuulu myös ulkopuolisia konsultteja tai muita tukihenkilöitä. 

Ulkopuolista apua kannattaa käyttää silloin, kun omasta organisaatiosta ei löydy riittä-

västi hankinnassa tarvittavaa asiantuntijuutta ja osaamista. Itse hankintaa vetää yleensä 

hankinnan vastuuhenkilö, joka voi olla erikseen nimetty projektipäällikkö tai muu osa-

alueesta vastaava henkilö. Hankintaorganisaatioon kuuluu lisäksi sekä teknisiä että liike-

toiminnan asiantuntijoita. Usein hankinnan ohjausryhmää vetää järjestelmän tuleva 

omistaja, eli hankinnan kohteena olevan toiminnan johtaja tai vastuuhenkilö. Organisaa-

tion hankintoja voidaan myös käsitellä muissa ryhmissä, kuten strategia- tai johtoryh-

mässä sekä tietohallinnon ryhmässä. Hankintapäätöksen tekee yleensä valintaryhmä ja 

valintaa esitetään ylemmälle taholle, kuten johtoryhmälle, joka päätyy joko hyväksy-

mään tai hylkäämään esityksen. (Tietotekniikan liitto ry 2002: 32). 

 

Vaatimusmäärittelyn teko vaadittavan tarkalla tasolla vaatii erityistä osaamista. Jos sitä 

ei löydy organsiaation sisältä, sitä voi hakea esimerkiksi ulkopuoliselta konsultilta. Joskus 

vaatimusmäärittelyjä ei syystä tai toisesta pystytä tekemään kovin ykistyiskohtaisella ta-

solla. Määrittely saattaa jäädä keskeisten liiketoiminnan muutostavoitteiden tasolle. 

Määritykset laaditaan vasta toteutusvaiheessa yhdessä toimittajan kanssa. Tällaisessa ti-

lanteessa asiakkaalla itsellään ei ole selkeää kuvaa siitä, miten järjestelmän toteutus tu-

lisi tehdä ja mitä toimintoja järjestelmään kannattaa (ja toisaalta ei kannata) sisällyttää. 

Tällöin asiakkaan kannattaa kääntyä toimittajan puoleen ja tehdä yhteistyötä tarvittavien 

määritelmien kuvaamiseksi. Varsinkin projektin ulkopuolelle jäävät toiminnallisuudet ja 

teknologiat on hyvä kuvata tarkasti, sekaannusten ja väärinymmärrysten välttämiseksi. 

Projektialueen tulisi aina olla selkeästi rajattu. (Tietotekniikan liitto ry. 2002: 20-21). 

 

 



44 

 

4.1.2 Toimittajan ja kumppanin rooli tietojärjestelmähankkeissa 

Asiakkaan, eli tietojärjestelmää hankkivan organisaation, ja toimittajan kumppanuus 

mahdollistaa parhaimmillaan molemminpuolisen luottamuksen, tehokkaan oppimisym-

päristön, hyvin toimivan keskinäisen viestinnän sekä yhteistyön kehittymisen henkilöi-

den kesken. Toimittajalla on mahdollisuus kehittyä asiakkaan toiminnan ja tietojärjestel-

män syvälliseksi asiantuntijaksi sekä osaajaksi ja toimittaa tulevaisuudessa entistä pa-

rempia ratkaisuja entistä tehokkaammin. Asiakkaan näkökulmasta kumppanuuteen liit-

tyy kuitenkin haaste, sillä toisaalta olisi hyvä olla riippumaton yksittäisestä toimittajasta. 

Esimerkiksi julkisten hankintojen kohdalla tämäntasoinen kumppanuus voi olla hyvin 

haasstavaa, kun lainsäädäntö määrää hankintoja niin tiukasti. Käytännössä tämä johtaa 

suurten julkisten tietojärjestelmähankkeiden kohdalla siihen, että aikataulut venyvät ja 

lopulta käyttöönotettava järjestelmä on jo valmiiksi osittain vanhentunut, joko tekniikan 

tai ratkaisun puolesta. (Tietotekniikan liitto ry. 2002: 15). 

 

Toimittajan ja ratkaisun valinta kattaa asiakkaan kannalta seuraavat vaiheet: 

• Tarjouspyynnön tekemisen 

• Tarjousten vertailun  

• Hankintapäätöksen tekemisen 

• Sopimuksen laatimisen 

• Alustavan projektisuunnitelman laatimisen. 

(Tietotekniikan liitto ry. 2002: 36). 

 

Ihannetilanteessa asiakkaan ja toimittajan koko, toiminta-alue ja arvot sopivat yhteen. 

Tällaisella tilanteella on otolliset lähtökohdat pitkäaikaiselle kumppanuudelle. Toimitta-

jan toimialaosaaminen asiakkaan toimialasta ei ole välttämätöntä, jos asikkaalla on an-

taa riittävästi osaamista kehitysprojektiin. Toimittajan toimialaosaamiseen ei muuten-

kaan kannata nojata liikaa, sillä osaaminen voi myös siirtyä toiselle toimittajalle ja osaa-

minen myös vanhenee nopeasti. Liian suuri tai liian pieni toimittaja ovat organisaatiolle 

riskejä. Pieni toimittaja saattaa konkurssin myötä kadota markkinoilta ennen projektin 

loppuunsaattamista. Pieniin yrityksiin liittyy kuitenkin myös monia hyviä puolia. Pieni 



45 

 

yritys on usein ketterä. Heikkous on taas voimakas henkilöriippuvuus ja sijaisjärjestelyt 

ovat esimerkiksi sairaustapauksien sattuessa hankalia. (Myllymäki, Hinkka, Hirvensalo & 

Hämäläinen 2011: 92-93). 

 

Käyttöönotettavan järjestelmän sekä toimittajan on sovittava parhaalla mahdollisella ta-

valla organisaation toimintaan. Sopivuuteen vaikuttavat esimerkiksi yrityksen toimiala ja 

koko, mutta joskus myös pienimmelläkin yksityiskohdilla on merkitystä. Toiset järjestel-

mät taipuvat organisaation tarpeisiin helpommin, kuin toiset. Saman toimialan referens-

sit voivat siksi olla todella arvokkaita. Järjestelmätoimittajan tulisi olla asiakkaalle sopi-

van kokoinen; ei liian pieni, jotta toimittajan konkurssin riski ei olisi liian suuri ja toisaalta 

toimittajan koko ei saa olla liian suuri, sillä tällöin asiakas ei välttämättä ole toimittavalle 

taholle tarpeeksi tärkeä. Toimittajalla tulee olla kokemusta hankittavan järjestelmän 

käyttöönottoprojekteista ja mielellään myös organisaation toimialalta. Järjestelmän li-

säksi myös toimittajaan liittyvät referenssit ovat tärkeitä. (Myllymäki, Hinkka, Hirvensalo 

& Hämäläinen 2011: 41). 

 

Toimittajan ja toimittajan henkilöstön osaamisen merkitystä ei voi aliarvioida. Kannattaa 

varmistaa, että toimittajalle on ehtinyt kertyä sopiva osaaminen joko projektien toteut-

tamisen, rekrytointien, tai kouluttautumisen kautta. Globaaleilta toimijoilta voi löytyä 

osaajaa spesifiinkin asiaan, mutta tällöin projektiryhmän yhteinen kieli on usein huonosti 

puhuttu englanti. Kannattaa miettiä, voisiko projektihenkilökunnalta edellyttää samaa 

äidinkieltä, mutta täytyy ottaa myös huomioon, että uuden tai harvinaisen teknologian 

kohdalla tämä ei ole välttämättä mahdollista. (Myllymäki, Hinkka, Hirvensalo & Hämäläi-

nen 2011: 122). Nykyisin myös monet kotimaiset organisaatiot ovat kansainvälisiä ja 

niissä työskentelee henkilöitä, joiden pääasiallinen työskentelykieli on englanti tai joku 

muu, kuin suomi.  

 

 



46 

 

4.2 Hankintasuunnitelma 

Mitä isommasta tietojärjestelmäprojektista on kysymys, sitä huolellisemmin hankinta on 

suunniteltava. Hankinnan valmistelun tehtävänä on tuottaa hyväksytty suunnitelma tie-

tojärjestelmähankinnan toteuttamiseksi. Mitä paremmin projekti suunnitellaan, sitä te-

hokkaammin ja edullisemmin se onnistuu. Suunnitteluun käytetty aika ja raha tulevat 

yleensä helposti moninkertaisina säästöinä takaisin projektin aikana. Suunnitteluun käy-

tettäviin resursseihin saatetaan suhtautua kriittisesti, sillä hyvän suunnitelman tekemi-

seen kuluu aikaa ja tulokset eivät näy heti. Huolellinen suunnittelu kuitenkin nopeuttaa 

itse projektin läpivientiä ja parantaa sen laatua sekä lopputulosta. (Tietotekniikan liitto 

ry. 2002: 18). Kun suunnitteluvaihe on tehty kunnolla, projektin aikana tai sen jälkeen 

kohdataan myös vähemmän yllätyksiä ja odottamattomia vastoinkäymisiä. 

 

Jotta järjestelmän hankinta onnistuisi, on ennen hankintaprosessiin lähtöä projektilla ol-

tava kattavat ja selkeät tavoitteet, että business case, eli liiketoiminnasta lähtöisin tuleva 

tarve. Tavoitteet tulisi meittiä ja jakaa osiin jokaiselle käyttäjä- ja sidosryhmälle erikseen. 

Käyttäjäryhmien huomioiminen erikseen jo tässä vaiheessa helpottaa muutoksenhallin-

taa. Kehitystoimenpiteiden oikeutus löytyy organisaation strategiasta ja jokaisen kehitys-

toimenpiteen tulisi totetuttaa jotakin strategian osaa ainakin välillisesti. (Myllymäki, 

Hinkka, Hirvensalo & Hämäläinen 2011: 43). 

 

Hankintasuunnitelmasta tulisi vähintään käydä esille hankkeen liiketoiminnallinen tarve 

sekä perustelut sille, miksi hankinta tehdään. Liiketoimintatarpeen tulisi olla yhteydessä 

organisaation strategiaan. Liiketoimintatarpeessa määritellään, mitä hankinnalla tavoi-

tellaan, paljonko hankinta tulee mahdollisesti kustantamaan ja mitkä ovat hankinnan on-

nistumisen kriteerit. Lisäksi tulisi määritellä mitä ollaan hankkimassa, eli minkälainen rat-

kaisu liiketoiminnan tarpeeseen halutaan. Suunnitelmassa tulisi jo karkeasti kuvata han-

kittava tietojärjestelmä tai ongelma-alue ja tarve sekä avata järjestelmän kohderyhmää. 

On hyvä myös määritellä, mitä asioita hankinta ei koske, eli rajata hanke. (Tietotekniikan 

liitto ry. 2002: 18-19). 

 



47 

 

Suunnitelmassa otetaan kantaa myös itse hankintaprosessin läpivientiin, eli millä tavalla 

hankita toteutetaan. Hankintaprojekti aikataulutetaan, kuvataan sen eri vaiheet ja miten 

hankinta etenee, tehdäänkö hankinta itse vai otetaanko siihen ulkopuolista apua, miten 

projektin toimittaja valitaan, miten kommunikointi organisaation sisällä ja ulkopuolella 

hoidetaan, miten hankintaa ohjataan, ketkä ovat mukana hankinnassa ja missä rooleissa, 

mitä päätöksiä tulee tehdä sekä miten hankintaprosessi dokumentoidaan. Lisäksi tulisi 

ottaa huomioon hankinnan riskit ja sekä missä mahdollisissa tilanteissa hankinta tulisi 

keskeyttää. (Tietotekniikan liitto ry. 2002: 19). 

 

Hankintasuunnitelma täytyy tehdä tarkasti. Siinä tulisi käsitellä selkeästi projektin tavoit-

teet ja lähtökohtatiedot. Jos suunnitteilla oleva projekti on esimerkiksi jatkoa jollekin 

aiemmalle projektille, tarkoilla tiedoilla aiemmin tehdystä projektista on paljonkin mer-

kitystä ja hyötyä uuden projektin kannalta. Suunnittelun viimeinen vaihe on tarkkaan 

mietitty aikataulu ja tulevan projektin vaiheistaminen. Aikataulun tulisi kuitenkin olla 

joustava niin, että esimerkiksi yhden osa-alueen viivästyminen ei tule keskeyttämään 

koko projektia. Aikataulussa tulisi huomioida realistisesti resurssien käyttö ja henkilöiden 

saatavuus, mahdolliset poissaolot ja muut henkilöihin liittyvät riskit. Uuden tietojärjes-

telmän testaamiseen kuluu yleensä aikaa, ja varsinkin, jos järjestelmään tulee yksi tai 

useampi integraatio toisiin järjestelmiin, testaamisesta tulee monimutkaisempaa ja se 

saattaa usein vaatia projektin ulkopuolisten henkilöiden työpanosta. (Tietotekniikan 

liitto ry. 2002: 19). 

 

Tietojärjestelmäprojekteissa kustannusten aliarviointi on yleistä. Näkemys projektin on-

nistumisesta on kuitenkin jokseenkin subjektivinen, sillä onnistumista arvioidaan aina 

omasta näkökulmasta käsin. Syynä tietojärjestelmäprojektien epäonnistumiseen on lä-

hes joka kerta valmistelujen puute. Joko valmisteluvaiheessa on tehty virheitä, tai joita-

kin tehtäviä on jätetty kokonaan tekemättä. Valmisteluvaiheen puutteet kostautuvat pro-

jektin myöhemmissä vaiheissa. (Myllymäki, Hinkka, Hirvensalo & Hämäläinen 2011: 11-

13).  

 



48 

 

5 Tutkimuksen suorittaminen 

5.1 Tutkimuksen tavoite 

Tämän tutkimuksen tavoitteena on selvittää, minkälaista päätöksentekoprosessia suo-

malaiset keskisuuret ja suuret organisaatiot käyttävät valitessaan henkilöstötietojärjes-

telmää. Tarkoituksena on myös kartoittaa, mitkä roolit osallistuvat päätöksentekoon pro-

sessin eri vaiheissa ja mitkä sisäiset ja ulkoiset tekijät vaikuttavat päätöksen syntyyn.  

 

Tutkimuksen tavoite kiteytyy tutkimusongelman eli tutkimuskysymyksen määrittelyyn. 

Hyvää tutkimuskysymystä on vaikea määritellä, mutta parhaimmillaan se on yksiselittei-

nen ja selkeä. Tutkimuskysymys kertoo kiteytyksen siitä, mitä halutaan tutkia ja tietää. 

(Saaranen-Kauppinen & Puusniekka 2006). Kysymys tai tutkimuskysymykset pitävät tut-

kimuksen kasassa ja auttavat sekä tutkijaa että tutkimuksen lukijaa pysymään aiheessa 

läpi tutkimuksen. Tutkimuskysymys toimiikin tutkimuksen punaisena lankana. 

 

Päätutkimuskysymys on ”Miten henkilöstöjärjestelmän hankinnassa päädytään tiettyyn 

järjestelmään ja järjestelmäkumppaniin?”. Tavoite kysymyksen taustalla on saada koko-

naiskuva henkilöstöjärjestelmän hankinnan päätöksentekoprosessista sekä selkeyttää 

kokonaiskuvaa hankinnasta.  

 

Päätutkimuskysymyksen lisäksi tutkimuksessa on muutama alikysymys, jotka jaottelevat 

pääkysymyksen eri osiin. Kysymyksen “Millaisia vaiheita hankinnan päätöksentekopro-

sessiin kuuluu?” tavoitteena on selvittää, millaisia vaiheita päätöksentekoprosessiin kuu-

luu ja onko vaiheissa eroja eri organisaatioiden välillä.  Kysymyksen “Mitkä roolit ovat 

mukana päätöksenteossa?” tavoitteena on selvittää, ketkä organisaatiosta tai sen sidos-

ryhmistä ovat mukana päätöksenteon eri vaiheissa. Kysymyksen “Miten hankinnan kri-

teerit määritellään?” tavoitteena on selvittää miten ja kuka määrittelee kriteerit.  

 

 



49 

 

 

 

 

Kuvio 2. Tutkimuksen suorittaminen.  

 

Tutkimus etenee kuvio 2.:ssa kuvatulla tavalla. Tutkimusaiheesta kerätään ensin teoria-

pohja, sen jälkeen suoritetaan tutkimus valitulla tutkimusmenetelmällä; laadullisella 

haastattelututkimuksella. Tämän jälkeen haastatteluaineisto analysoidaan ja sitä verra-

taan aiemmin kerättyä teoriapohjaa varten. Lopuksi tutkimuksesta tehdään johtopäätök-

set. Seuraavissa luvuissa avataan tarkemmin tutkimuksen suorittamisen vaiheita. 

 

 

5.2 Tutkimusmenetelmä 

Tutkimusmenetelmäksi on valittu laadullinen haastattelututkimus, sillä se on luonnolli-

sin tapa tutkia prosessia, jossa eri ihmisillä ja heidän taustamotiiveillaan ja tunteillaan on 

suuri vaikutus lopputulokseen. Aiheesta on myös aiemmin tehty tutkimusta samalla me-

netelmällä.  Hyvän kvalitatiivisen otoksen saaminen on myös tutkimuksen kannalta rea-

listisempaa ja sopii paremmin aikatauluun, kuin ison kvantitatiivisen tutkimuksen toteut-

taminen. Kvalitatiivisella tutkimuksella aiheeseen pääsee pureutumaan syvemmin, kuin 

1. Teoriapohjan 
kerääminen ja 
kirjoittaminen

2. Kvalitatiivinen 
tutkimus: 

Teemahaastattelut

3. 
Tutkimusaineiston 

analysoini

4. Aineiston 
vertaaminen 
teoriapohjaa 

vasten

5. Johtopäätökset



50 

 

esimerkiksi monivalintatekniikalla toteuttavalla kvalitatiivisella kyselytutkimusella. Tutki-

muksessa kiinnostus kohdistuu nimenomaan ihmisten toimintaan järjestelmää valitta-

essa eikä itse järjestelmään. 

 

Tutkimuksen tutkimusstrategia on fenomenologinen, sillä tutkimuksessa selvitetään 

haastattelujen avulla käsityksyksiä tutkittavasta aiheesta. Tässä strategiassa lähtökoh-

tana ajatellaan, että ihmisillä on hyvin erilaisia käsityksiä tutkittavasta ilmiöstä. Tutkijan 

tehtävänä on tarkastella, millaiseksi tutkimusaiheen sisältö muodostuu näiden eri käsi-

tysten valossa. (Saaranen-Kauppinen & Puusniekka 2006).  

 

Aineiston hankintamenetelmänä käytetään haastattelututkimusta ja ihmisten subjektii-

viset käsitykset aiheesta tulevat kuitenkin vääjäämättä vaikuttamaan tutkimustulokseen. 

Tarkoituksena on keskittyä haastateltavien kuvaukseen päätöksentekoprosessista ja sii-

hen vaikuttaneista ilmiöistä. 

 

Haastattelu on joustava menetelmä ja sopii moneen erilaiseen tutkimustarkoitukseen. 

Haastattelu antaa mahdollisuuden suunnata tiedonhankintaa itse tilanteessa ja tuo 

mahdollisuuden saada esiin vastausten taustalla olevia motiiveja, kun eleet ja ilmeet aut-

tavat ymmärtämään vastauksia. Aiheiden järjestystä on mahdollista muunnella tilanteen 

mukaan. Haastattelussa ihminen nähdään tutkimustilanteessa subjektina ja hän tarkas-

telee tutkimusaihetta aina omasta lähtökohdastaan käsin. Haastattelu sopii tutkimusme-

netelmäksi, kun haastateltavan puhe pyritään sijoittamaan laajempaan kontekstiin ja 

kun tiedetään jo ennalta, että tutkimusaihe tuottaa monitahoisesti ja moniin suuntiin 

viittaavia vastauksia. Haastattelussa vastauksia voidaan selventää ja näin syventää saa-

tua tietoa. (Hirsijärvi & Hurme 2000: 34 - 35). 

 

Tutkimusmenetelmänä haastattelusta löytyy myös ongelmallisia puolia. Haastattelijalta 

vaaditaan taitoa, jotta hän voi säädellä aineiston keräämistä joustavasti kunkin haastat-

telutilanteen edellyttämällä tavalla ja vastaajia myötäillen. Itse haastattelu vie aikaa, sa-

moin sitä edeltävä sopiminen ja toteutuksen suunnittelu. Haastattelun jälkeen äänitetty 



51 

 

puhe täytyy avata tekstiksi ja litterointi on varsin hidasta puuhaa. Haastattelu voi sisältää 

virheellisiä lähteitä niin haastattelijasta kuin haastateltavastakin johtuen. Haastatelta-

valla saattaa olla taipumus antaa sosiaalisesti suotavia vastauksia. Vapaamuotoisen 

haastatteluaineiston analysointi, tulkinta ja raportointi on usein ongelmallista, kun val-

miita esimerkkejä tai malleja ei ole tarjolla tähän työhön. (Hirsijärvi & Hurme 2000: 34 - 

35). 

 

Haastattelun hyviä puolia on esimerkiksi se, että sillä on suuremmat mahdollisuudet mo-

tivoida vastaajaa, kuin kyselylomakkeessa. Haastattelussa voidaan säädellä aiheen jär-

jestystä ja se on joustavampi ja sallii täsmennykset kysymyksiin. Haastattelua voidaan 

käyttää moneen tarkoitukseen, kuten kartoitukseen, sillä voidaan saavuttaa muun tie-

don ohella uusia hypoteeseja, ja se voi osoittaa ilmiöiden välisiä yhteyksiä.  

(Hirsijärvi & Hurme 2000: 36). 

 

Haastattelua käytetään usein aineiston hankinnan menetelmänä, kun tutkitaan ihmisiin 

liittyviä asioita. Tutkimushaastatteluista voidaan tunnistaa kaksi perustyyppiä: struktu-

roitu haastattelu ja teemahaastattelu. Tässä tutkimuksessa käytetään teemahaastattelua, 

jossa edetään vapaamuotoisesti haastattelijan määrittelemien aihepiirien pohjalta. Tee-

mahaastattelusta saadaan syvällisesti ti