Wille Asikainen 

Käyttäjälähtöinen ohjelmistohankinta 

Prosessimalli loppukäyttäjien osallistamiseen käytettävyyden 
parantamiseksi 

 

 

 

 

 

 

 
  

Vaasa 2023 

Tekniikan ja innovaatiojohtami-
sen akateeminen yksikkö 

Pro gradu- tutkielma 
Tietojärjestelmätiede 



2 

VAASAN YLIOPISTO 
Tekniikan ja innovaatiojohtamisen akateeminen yksikkö 

Tekijä: Wille Asikainen 
Tutkielman nimi: Käyttäjälähtöinen ohjelmistohankinta: Prosessimalli loppukäyttä-

jien osallistamiseen käytettävyyden parantamiseksi 
Tutkinto: Kauppatieteiden maisteri 
Oppiaine: Tietojärjestelmätiede 
Työn ohjaaja: Juho-Pekka Mäkipää 
Valmistumisvuosi: 2023 Sivumäärä: 62 

TIIVISTELMÄ: 
 

Monet terveydenhuollon ammattilaiset ovat kokeneet uudet tai nykyiset potilastietojärjestel-
mät haastaviksi käyttää ja jopa haittaavan työskentelyä. Tutkimusten mukaan heidän kokemuk-
siaan tai kehitysehdotuksiaan ei oteta riittävällä tasolla huomioon. Aihetta on syytä tutkia tar-
kemmin hankinnan näkökulmasta, jotta terveydenhuollon hankintaprosessia ja ohjelmistonke-
hitystä saataisiin vietyä enemmän loppukäyttäjälähtöisen kehittämisen suuntaan. Tutkielma 
pyrkii vastaamaan kysymykseen, millä keinoilla loppukäyttäjä osallistetaan ohjelmiston hankin-
taprosessiin, jotta käytettävyysongelmat tietojärjestelmissä saadaan vähenemään? Tutkielma 
on rajattu julkiseen sosiaali- ja terveydenhuoltoon, koska alueelta löytyy paljon tutkimusta oh-
jelmistojen käytettävyydestä. Työn tavoitteena oli luoda prosessimalli hankinnoista vastaaville 
tahoille, mikä tukee loppukäyttäjälähtöistä ja käytettävyyskeskeistä ohjelmistohankintaa. 
 
Tutkielma toteutettiin suunnittelutieteellisen tutkimuksen menetelmää hyödyntäen. Teoreetti-
nen viitekehys muodostettiin käytettävyyttä, käyttäjälähtöisyyttä ja julkista hankintaprosessia 
käsittelevillä kirjallisuudella. Empiirinen aineisto prosessimallin kehittämiseen kerättiin loppu-
käyttäjiltä kyselyillä ja hankinnoista vastaavilta tahoilta teemahaastatteluilla. Loppukäyttäjiltä 
kerätyn aineiston pohjalta muodostettiin teemahaastattelun kysymykset. Aineistonkeruu rajat-
tiin ohjelmistoprojekteissa mukana olleisiin sosiaali- ja terveysalan loppukäyttäjiin ja hankinta-
vastaaviin.  
 
Tutkielman tuloksena syntyi prosessimalli, joka antaa hankintavastaaville tukea loppukäyttäjien 
osallistamiseen tulevaisuuden ohjelmistohankintoihin julkisessa sosiaali- ja terveydenhuollossa. 
Tulokset osoittavat, että ohjelmistohankinnoissa tulee huomioida, ei ainoastaan hankintavai-
heen loppukäyttäjien resursointi, vaan myös käyttöönottovaiheen ja tuotantovaiheen. 
 
 
 
 

AVAINSANAT: (Hankinta, loppukäyttäjät, käyttäjälähtöisyys, käytettävyys, osallistaminen). 
  



3 

Sisällys 

1 Johdanto 6 

2 Kirjallisuuskatsaus 10 

2.1 Käytettävyys 10 

2.2 Käyttäjän osallistaminen 14 

2.3 Julkiset hankinnat 16 

2.4 Aiemmat tutkimukset 21 

3 Menetelmä 32 

3.1 Suunnittelutieteellinen tutkimus 32 

3.2 Suunnittelutieteellisen tutkimuksen prosessi 35 

3.3 Kysely 38 

3.4 Teemahaastattelu 39 

4 Tulokset 41 

4.1 Kysely loppukäyttäjille 41 

4.2 Haastattelut 42 

4.3 Artefaktin kuvaus 46 

4.4 Artefaktin arviointi 50 

5 Diskussio ja yhteenveto 52 

5.1 Tutkimuksen kontribuutio tieteelle 53 

5.2 Tutkimuksen kontribuutio käytäntöön 54 

5.3 Tutkimuksen rajoitteet 54 

5.4 Jatkotutkimusaiheet 55 

Lähteet 56 

Liitteet 61 

Liite 1. Kysely 61 

Liite 2. Haastattelu 62 

  



4 

Kuviot 
 
Kuvio 1 Käytettävän tuotteen kehitys (Mooij & Lammi, s.182, 2005) Muokattu 11 

Kuvio 2 Hankintasidosryhmien suhteet (Torvinen & Ulkuniemi, s.62, 2016) Muokattu 15 

Kuvio 3 Prosessien kuvaustasot (JHS 152 Prosessien Kuvaaminen | Suomidigi, n.d.) 20 

Kuvio 4 Käytettävyys- ja loppukäyttäjänäkökulma tietojärjestelmähankinnassa (Kaipio ja 

muut, s.110, 2015) 25 

Kuvio 5 Vaatimusmäärittelyn viitekehys (Scheuer ja muut, s.6 2022) 26 

Kuvio 6 Suunnittelutieteellisen tutkimuksen syklit (Hevner, s.88, 2007) 33 

Kuvio 7 DSRM Prosessi (Peffers ja muut, s.54, 2007) Muokattu ja suomennettu 36 

Kuvio 8 Tutkielman eteneminen 38 

Kuvio 9 Käyttäjälähtöinen ohjelmistohankintamalli 46 

Kuvio 10 Loppukäyttäjän osallistamisen vaikutukset 52 

 
 

Taulukot 
 
Taulukko 1 Heuristinen käytettävyysarviointi (Kaplan, 2021) 12 

Taulukko 2 Hankintamenettelyt (Eskola ja muut, s.285-288, 2017) 17 

Taulukko 3 Julkinen hankintaprosessi (Valtion Hankintakäsikirja OSA 1, 2017, s.33-34) 18 

Taulukko 4 Käyttäjäkeskeisyys yrityksessä (Cajander ja muut, 2022) 29 

Taulukko 5 Hankintaan liittyvät huolet (Riihimäki & Pekkola, 2021) 31 

Taulukko 6 Suunnittelutieteellisen tutkimuksen ohjeet (Hevner ja muut, s.83, 2004) 34 

Taulukko 7 Artefaktin perustietolomake esimerkki 47 

Taulukko 8 Artefaktin toiminnot 48 

Taulukko 9 Artefaktin arviointi 50 

 
 

Lyhenteet 
 
DSR – Design Science Research, Suunnittelutieteellinen tutkimus 
 
DK – Design Knowledge, Suunnittelutietämys 
 



5 

DSRM – Design Science Research Method, Suunnittelutieteellisen tutkimuksen mene-
telmä 
IS – Information Systems, Tietojärjestelmät 
 
UCD – User Centered Design, Käyttäjälähtöinen suunnittelu 
 
ISO – International Organization Standardization, Kansainvälisiä standardeja 
 
JHS – Julkisen hallinnon suosituksia 



6 

1 Johdanto 

Monet terveydenhuollon ammattilaiset ovat kokeneet uudet tai nykyiset potilastietojär-

jestelmät haastaviksi käyttää ja jopa haittaavan työskentelyä (Vehko ja muut, 2019). Ai-

hetta on syytä tutkia tarkemmin hankinnan näkökulmasta, jotta terveydenhuollon han-

kintaprosessia ja ohjelmistonkehitystä saataisiin vietyä vielä enemmän loppukäyttäjäläh-

töiseen kehittämisen suuntaan. Tutkielma pyrkii vastaamaan kysymykseen: Miten loppu-

käyttäjä osallistetaan hankintavaiheessa, jotta käytettävyysongelmat saadaan vähene-

mään? Taloudellisesta näkökulmasta markkinoilla pitäisi olla riittävästi tietoa järkevien 

päätösten tekemiseen. Huomio hankinnoissa kiinnittyy yleensä, vastaako tuote siihen 

tarpeeseen, mihin hankintaa ollaan tekemässä ja kuinka hyvin voidaan käytettävyyttä 

testata (Pollock & Williams, 2007). 

 

Moen (2014) tekemän tutkimusten tulosten mukaan julkinen tietojärjestelmien hankin-

taprosessi on monimutkainen. Ongelmana vaatimusmäärittelyn yksityiskohtaisuus, yk-

sinkertaisen sijaan. Moen mukaan vaatimusmäärittelyn tekeminen mahdollisimman ai-

kaisessa vaiheessa osana hankintaprosessia, antaa parhaimman lopputuloksen. Hyvin 

usein hankinnan päätösvalta jätetään toimittajalle ja Moe toteaa loppukäyttäjien osallis-

tumisen kriittisenä lopputuloksen kannalta. Hankintaprosessi on pitkä ja päättyy käyt-

töönottoon (Moe, 2014). Moe ja Päivärinta (2013) toteaa usean tutkimuksen löydösten 

viittaavan hankintojen sidosryhmäongelmiin. Erilaisilla sidosryhmillä on luonnollisesti 

erilaiset näkökulmat hankinnan haasteisiin ja ratkaisuna nähdään vaatimusmäärittelyn 

selkeyttäminen ennen varsinaista tarjouspyyntöä ja kilpailutusta. 

 

Martikaisen ja muiden (2018) mukaan ohjelmistotoimittajat eivät ole tarpeeksi kiinnos-

tuneita loppukäyttäjien näkemyksistä ohjelmistokehityksessä, vaikka palautetta annet-

taan ja resursseja käytetään tutkimuksiin. Käytettävyyteen keskitytään muilla aloilla erit-

täin laajasti, mutta terveydenhuollon järjestelmissä kehitys laahaa perässä ja pahasti. 

Kyytsösen ja muiden (2020) artikkelin mukaan potilastietojärjestelmissä on edelleen 

työtä hankaloittavia ominaisuuksia, vaikka kehitys on mennyt eteenpäin. Käytettävyys on 



7 

osa digitaalisen järjestelmäkokonaisuuden laatua ja hankintalaki ei ohjaa käytettävyyden 

arviointia suoraan, mutta mahdollistaa sen (Koulu ja muut, s.16 2022). 

 

Iansiti (2012) kirjoittaa tyypillisen hankintaprosessin koostuvan monesta vaiheesta, 

mutta hankintaorganisaatio aloittaa määrittelemään ohjelmiston tarpeet ja turvallisuu-

den. Tarpeet ja vaatimukset asettavat viitekehyksen hankinnalle, jota vastaan tarjouksia 

käydään läpi. Vilpponen ja muut (2020) kirjoittavat tutkimuksessaan käyneen läpi use-

amman tekstin, joissa käsitellään IT projektien epäonnistumista ja listaavat kymmenen 

kriittisintä tekijää projektin onnistumiseen. Ensimmäinen on projektin missio, mission 

täytyy olla selkeästi ilmaistu ja tavoitteet kirkkaasti mielessä. Projektin onnistumiseen 

viittaa merkittävästi ylimmän johdon sitoutuminen, koska he ovat loppujen lopuksi vas-

tuussa projektin resursoinnista ja auktoriteetin ylläpitämisestä. Kolmanneksi nousee 

esille asiakaskonsultointi. Kommunikointi täytyy olla selkeää ja aktiivista koko projek-

tiorganisaation sidosryhmille. Neljänneksi onnistumistekijäksi on listattu yksityiskohtai-

nen kuvaus projektin tehtävistä ja viides tekijä painottaa osaavan organisaation resursoi-

mista koko projektin ajaksi. Kuudes käsittelee teknisiä asioita ja oikean teknologian var-

mistamista sekä sen osaamista projektin aikana. Seitsemäs kohta liittyy vahvasti muutos-

johtamiseen ja projektin perustelemiseen käyttäjille. Käyttäjillä täytyy olla kattava tieto, 

miksi projekti toteutetaan ja projektiorganisaatiolla selkeät tavoitteet. Kolmessa viimei-

sessä kohdassa korostuu palautteen kerääminen ja sen aito hyödyntäminen projektissa 

sekä kommunikoinnin kattavuus koko projektin sidosryhmille, mukaan lukien loppukäyt-

täjät. Viimeinen kohta muistuttaa riskienhallinnasta projektissa, jotta pystytään varautu-

maan yllättäviin tilanteisiin, koska niitä tulee aina eteen. (Vilpponen et al., 2020) 

 

Käytettävyyssuunnittelun etupainoitteinen lähestymistapa on koettu käytännössä kuor-

mittavaksi, koska esityön määrä on yleensä laaja. Toinen merkittävä käytettävyysnäkö-

kulman väheksymiseen ohjelmistohankinnoissa on todettu olevan kustannus- ja hyö-

tyvaikutusten mitattavuus lyhyellä aikavälillä. Toimivien tietojärjestelmien ja palveluiden 

suunnittelu ilman toimintaympäristöön liittyvää aitoa ymmärrystä perustuu ainoastaan 

asiantuntijoiden parhaisiin arvioihin. Olettamusten perusteella tehdyt ratkaisut tuovat 



8 

ongelmia käyttöönottovaiheeseen ja niiden korjaamiseen tarvittavat toimet tulevat yh-

teiskunnalle todella kalliiksi sekä lisäksi kuormittaa henkilökuntaa tarpeettomasti. (Viita-

nen & Nieminen, s.133-134 2009) 

 

Julkisen terveydenhuollon ongelmia ovat järjestelmien heikko käytettävyys, käytössä 

olevien järjestelmien suuri määrä ja tiedonkulun ongelmat. Järjestelmät ovat epäkäytän-

nöllisiä ja käytettävyyteen ei ole juuri kiinnitetty huomiota. Tilaaja organisaatioissa tar-

vitaan lisää hankintaosaamista ja loppukäyttäjät tulisi osallistaa hankintaan, jotta han-

kinnat olisivat mahdollisimman käyttäjäystävällisiä ja toimintaympäristöön sopivia. (Uk-

konen, 2019) 

 

Julkisia hankintoja ohjaa lainsäädäntö. Lain tarkoituksena on taata tasapuolinen kohtelu 

tarjousten antajien välillä ja tavoitteena edistää julkisten varojen käyttöä. Lain tavoit-

teena on myös ”Edistää laadukkaiden, innovatiivisten ja kestävien hankintojen tekemistä 

sekä turvata kaikille mahdollisuus osallistua kilpailuun”. Hankintayksiköiden vastuulle jää 

toiminnan järjestäminen tavalla, jossa huomioidaan taloudellinen, laadullinen ja suunni-

telmallinen näkökulma. Hankintayksiköiden tulee myös ottaa huomioon hankinnan ym-

päristö- ja sosiaalinen näkökulma. (FINLEX ®, 2016) 

 

Tutkielman tavoitteena on kehittää loppukäyttäjälähtöinen ohjelmistohankintaprosessi, 

jotta käytettävyysongelmat käyttöönotoissa saadaan vähenemään. Tutkielma rajattiin 

sosiaali- ja terveydenhuollon tietojärjestelmien hankintaprosesseihin, koska useiden tut-

kimusten mukaan sosiaali- ja terveydenhuollon ammattihenkilöt kokevat heidän kehitys-

ehdotusten ja kokemustensa laiminlyöntiä. 

 

Ovaska ja muut (2005) kirjoittavat käytettävyyden tutkimisen olevan pitkä prosessi, joka 

kestää aina järjestelmän suunnitteluvaiheesta, kehittämisvaiheen loppuun. Käytettävyy-

den tutkiminen vaatii ymmärrystä käyttäjän tarpeista ja siksi tiedonkeruu on oltava mah-

dollisimman kattava. Tässä tutkimuksessa oli tarkoituksena kerätä aineistoa loppukäyt-



9 

täjiltä ohjelmistohankintaan osallistumiseen liittyen kyselyn avulla. Loppukäyttäjäky-

selyn perusteella muodostettiin kysymykset teemahaastatteluun, joka kohdennettiin 

hankinnoista vastaaville tahoille. Teemahaastattelussa käytettiin julkista hankintaproses-

sia, joka käytiin vaihe vaiheelta asiantuntijoiden kanssa läpi. 

 

Laadullisessa tutkimuksessa tutkimusongelma ei välttämättä ole kirkkaana mielessä heti 

tutkimuksen alussa, vaan ongelma täsmentyy tutkimusta tehtäessä. Tutkimushaastatte-

lun ominaispiirteisiin kuuluu tutkijan tehtävä välittää lukijalle kuvaa haastateltavien aja-

tuksista, käsityksistä, kokemuksista ja tunteista (Hirsjärvi & Hurme, s.47, 2008). Kohden-

netussa haastattelussa tiedetään, että haastateltavat ovat kokeneet tietyn tilanteen 

aiemmin. Haastattelu on kohdennettu tiettyyn teemaan ja tuo esille ihmisten tulkinnat 

ja merkitykset asioihin (Hirsjärvi & Hurme, s.47-48, 2008). 

 

Tutkielman tutkimusmenetelmänä käytettiin suunnittelutieteellistä menetelmää ja ai-

neiston keruumenetelmänä oli sekoitus kvalitatiivista sekä kvantitatiivista menetelmää. 

Tutkimuksen haastatteluiden ja kyselyn lisäksi toteutettiin kirjallisuuskatsaus käytettä-

vyyttä, käyttäjän osallistamista, julkista hankintaprosessia ja aiempaa tutkimusta käsit-

televistä artikkeleista ja tietokirjoista. Tutkimuksessa hyödynnettiin pääosin internetläh-

teitä. Tärkeimpiä teoriakokonaisuuksia ovat käytettävyyden ja käyttäjälähtöisen suunnit-

telun teoriakokonaisuudet. Suunnittelutieteellisestä menetelmästä tarkemmin luvussa 

kolme. 

 

Tutkielma suoritettiin yhteistyössä SOTE-alan loppukäyttäjien ja hankintavastaavien 

kanssa, joten siitä tulee olemaan kansallista hyötyä terveydenhuoltoalan ohjelmistohan-

kinnoissa ja mahdollisesti toimia vuoropuhelun avaajana ohjelmistontoimittajiin kohti 

asiakaslähtöisempää kehittämistä. Tutkielma tehtiin aikavälillä joulukuu 2022-toukokuu 

2023.  



10 

2 Kirjallisuuskatsaus 

Tämän luvun on tarkoitus avata lukijalle käytettävyyden teoriaa, julkista hankintaproses-

sia, osallistamisen menetelmiä, käyttäjälähtöisyyttä ja tuoda esille tarkemmin, minkälai-

sia tuloksia aiemmat tutkimukset aihealueesta ovat tuottaneet. 

 

2.1 Käytettävyys 

Ihmiset tykkäävät käyttää digitaalisia tuotteita tai palveluita, jos ne toimivat tavalla kuin 

niiden odotetaan toimivan. Siihen on syynsä. Käytettävyys. Käytettävyys mahdollistaa 

helpon oppimisen, helppokäyttöisyyden, intuitiivisuuden ja joidenkin sovellusten tai 

tuotteiden kohdalla jopa hauskuuden (Barnum, s.1, 2011). ISO 9241-11 (2018) standar-

din mukaan puhutaan käytettävyydestä, kun käyttäjä saavuttaa tavoitteensa tehokkaasti 

ja on tyytyväinen tuotteeseen tai palveluun. Käytettävän digitaalisen palvelun tai 

tuotteen täytyy olla myös uusille käyttäjille helppo oppia ja sisäistää. Toimintavarmuus 

lähes 100 prosenttia ja ylläpitotehtävien olla tehokkaasti sekä nopeasti suoritettavia. 

Käytettävyys tulee huomioda suunnittelussa, arvioinnissa, kehityksessä, hankinnassa, 

vertailussa tai tutkimuksen tekemisessä (ISO 9241-11:2018). 

 

Käytettävyys voidaan kuvata viiden eri laatukomponentin mukaan : Opittavuus, tehok-

kuus, muistettavuus, virheet ja tyytyväisyys. Opittavuus käsittelee kuinka helposti käyt-

täjä pystyy tekemään perustehtäviä ensimmäisellä käyttökerralla. Opittavuus on mi-

tattavissa miten nopeasti uusi käyttäjä oppii uuden tehtävän. Tehokkuus tulee oppimisen 

jälkeen ja sitä mitataan suoritusnopeudella. Tehokkuus mitataan myös ajassa, mutta 

siinä kiinnitetään huomiota myös napinpainallusten määrään ja tehtävän suorittamisen 

suoraviivaisuuteen. (Kaminski, 2020) 

 

Kolmas komponentti on muistettavuus. Muistettavuutta voidaan mitata, kuinka helposti 

käyttäjä saa palautettua opitun asian mieleensä, oltuaan hetken käyttämättä järjes-

telmää. Ohjaako järjestelmä käyttäjää riittävästi vai joutuuko hän opettelemaan kaiken 



11 

uudelleen. Neljäs komponentti on virheet. Virheiden määrä ja laatu luokitellaan käyt-

täjän ja järjestelmän tekemiin virheisiin. Kuinka usein käyttäjä tekee virheen tai kuinka 

usein järjestelmä kaatuu. Virheitä mitataan niiden määrän ja niistä toipumisen pe-

rusteella. Auttaako järjestelmä käyttäjää välttämään virheitä ja kuinka helposti käyttäjä 

voi korjata tilanteen. Viides komponentti on tyytyväisyys. Käyttäjätyytyväisyydellä on iso 

merkitys käytettävyyteen ja sitä voidaan mitata erilaisilla käyttäjähaastatteluilla ja ky-

selyillä. (Kaminski, 2020) 

 

 Kuviossa 1 kuvataan käyttäjälähtöisen suunnittelun prosessia tuotteen kehityksessä. Uu-

den teknologian suunnittelussa käytettävyyden huomioiminen on erityisen tärkeää eten-

kin terveydenhuollossa. Toimintojen puuttumisella, järjestelmän luotettavuuden 

puutteella tai käyttöliittymien epäjohdonmukaisuudella on suuret negatiiviset 

vaikutukset käyttäjän toimintaan. Huono käytettävyys vähentää käyttäjän sitoutu-

neisuutta omaan työhönsä , laskee tuottavuutta, laskee tehokkuutta ja vähentää tyytyv-

äisyyttä omaan työympäristöönsä merkittävästi. (Kaminski, 2020) 

 

 

Kuvio 1 Käytettävän tuotteen kehitys (Mooij & Lammi, s.182, 2005) Muokattu 

 

Käyttäjälähtöinen suunnittelu, englanniksi User-Center-Design (UCD), on interaktiivisten 

järjestelmien suunnittelun ja kehityksen lähestymistapa. UCD: n tarkoitus on hyödyntää 

loppukäyttäjiltä saatua tietoa palvelun tai tuotteen kehitykseen. UCD: n tavoitteena on 

tuottaa järjestelmä, joka tuottaa käyttäjälle mahdollisimman hyvän käyttäjäkokemuksen. 



12 

UCD lähestymistapa on standardoitu ja sen tarkka kuvaus on määritelty ISO 9241-210 

standardissa. (Deuff & Cosquer, s.14-15, 2013) 

 

Standardin mukaan UCD: lla on kuusi pääperiaatetta, jotka ohjaavat toimintaa. Ensim-

mäisen periaatteen mukaan suunnittelun keskeisin tavoite on ymmärtää käyttäjiä, hei-

dän ympäristöään ja tekemiään tehtäviä. Toinen periaate ohjaa osallistamaan käyttäjät 

suunnitteluun ja kehitykseen. Kolmannen periaatteen mukaan käyttäjäarvioinnit tulee 

olla suunnittelun lähtökohtana. Neljäs periaate on iteratiivinen prosessi. Viides periaate 

kuvaa käyttäjäkokemuksen kokonaisvaltaista huomioimista suunnittelussa ja kuudes pe-

riaate korostaa suunnittelijoiden monitieteellisiä taitoja ja näkökulmia. UCD on iteratii-

vinen prosessi, jossa on neljä päävaihetta. Ensimmäinen vaihe on käyttöympäristön ym-

märtäminen. Toinen, käyttäjävaatimusten määrittely. Kolmas, ratkaisujen suunnittelu. 

Neljäs, arviointi. (Deuff & Cosquer, s.14-15 2013) 

 

Kaplanin (2021) mukaan myös monimutkaisten järjestelmien käytettävyysarvioinnissa 

voidaan hyödyntää Nielsenin (2020) kehittämää kymmenen kohdan heuristista käytettä-

vyysarvointia, joka perustuu käyttäjälähtöisyyteen. Arviointi on tehty ohjaamaan suun-

nittelijoiden työtä kohti käyttäjälähtöisempiä käyttöliittymiä. Taulukko 1 kuvaa monimut-

kaisten järjestelmien heuristista käytettävyysarviointia. 

 

Taulukko 1 Heuristinen käytettävyysarviointi (Kaplan, 2021) 

Huomioi Kuvaus 

Järjestelmän tila Järjestelmän tulee aina pitää käyttäjä ajanta-

salla ja informoida mitä on tapahtumassa tai ta-

pahtuu. Ilman järjestelmän palautetta käyttä-

jälle saattaa jäädä epäselväksi mitä on tapahtu-

massa tai mitä pitäisi tehdä. 

Yhdistäminen reaalimaailmaan Järjestelmän tulee tukea käyttäjän tuntemia kä-

sitteitä. 



13 

Kontrolli ja vapaus Käyttäjät saattavat käyttää järjestelmää virheel-

lisellä tavalla, joten heille täytyy tarjota keino 

ulospääsyyn tai peruuttamiseen. 

Johdonmukaisuus ja standardit Käyttäjien ei tulisi kohdata tulkinnanvaraisia kä-

sitteitä, tilanteita tai tapahtumia. Johdonmukai-

suus helpottaa käyttäjiä ennakoimaan ja oppi-

maan järjestelmän käyttö nopeammin. 

Vikatilojen välttäminen Vikatilojen viestit ovat tärkeitä, mutta tärkeäm-

pää on vikatilojen välttäminen. Vahingossa ta-

pahtuneet virheet voidaan yleensä eliminoida 

kysymällä käyttäjältä vahvistus muutoksien te-

kemiseen tai jonkin asian suorittamiseen. 

Tunnistaminen, muistamisen sijaan Järjestelmää suunniteltaessa tulee huomioida 

käyttäjän rajallinen työmuisti. Käyttäjän ei tule 

muistaa jotain tiettyä asiaa, vaan sen tulisi olla 

näkyvillä ja ohjeiden saatavilla. Monimutkai-

sissa järjestelmissä on paljon informaatiota, jo-

ten vinkkien tulee olla sisäänrakennettuna jär-

jestelmään. 

Joustavuus ja tehokkuus Tehokkuus on arvokasta ja käyttäjät saavuttavat 

maksiminsa vasta opittuaan käyttöliittymän täy-

dellisesti. Pikatoiminnot tai kuvakkeet yleensä 

tehostavat käyttäjien toimintaa. 

Estetiikka ja minimalismi Käyttöliittymissä ei tule olla mitään ylimää-

räistä, joka voi sekoittaa käyttäjän olennaisten 

asioiden tunnistamisen. 

Diagnosointi ja toipuminen Vikatilojen viestit tulee olla selkokielisiä ja tar-

jota ratkaisu ongelmaan. 

Ohjeet ja dokumentaatio Monimutkaiset järjestelmät vaativat käyttäjien 

koulutusta, mutta kokeneillakin käyttäjillä tulee 



14 

käytön kanssa ongelmia. Ohjeiden tulee olla sel-

keitä ja johdonmukaisia. 

 

 

 

2.2 Käyttäjän osallistaminen 

Nykyaikana käyttäjät osallistuvat tuotekehitykseen lähes jokaisen tuotteen tai palvelun 

kohdalla, joten käyttäjien hyödyntämättä jättäminen kehityksessä on resurssien tuhlaa-

mista. Suorassa käyttäjäyhteistyössä käyttäjille annetaan aktiivinen rooli ja on parhaim-

millaan silloin, kun kehittäjät eivät tunne kohdemarkkinoita erityisen hyvin. Käyttäjillä on 

tieto omasta markkinastaan ja he voivat perehdyttää suunnittelijoita jakamalla tietoa. 

Käyttäjän osallistaminen on yksinkertaisimmillaan vuoropuhelua käyttäjien ja suunnitte-

lijoiden välillä ongelmista tai tuotteen vaatimuksista. Käyttäjien jakaman tiedon perus-

teella voidaan suunnitella ja kehittää tuote, joka sopii heidän käyttötarkoituksiinsa. Kes-

kustelua käydään erilaisten mallien avulla, sillä ne konkretisoivat käyttäjien ja suunnitte-

lijoiden näkökulmat sekä osaamisen. Esimerkiksi työtehtävien listauksia, työnkulkuja, 

näyttökuvia ja virheitä käytetään usein apuvälineinä kehitystyössä. (Hyysalo, s.93-94 

2009) 

 

Kehitystyöhön valittavien käyttäjien valinta suoritetaan harkiten. Yhteistyötä tehdään 

sellaisten henkilöiden kanssa, jotka tuntevat käyttöympäristön ja haluavat jakaa tietoa. 

Yleensä yhteistyökumppaneiksi valikoituvat oman alansa johtavat asiantuntijat, koska se 

nostaa tuotteiden uskottavuutta. Aina johtava asiantuntija ei ole se paras vaihtoehto, 

koska heillä on yleensä visionäärin rooli organisaatiossa, eikä he välttämättä tiedä miten 

muut käyttäjät työtänsä tekevät. Johtavat käyttäjät kohtaavat työssään teknologiset 

muutokset muita käyttäjiä aikaisemmin, joten heitä kannattaa hyödyntää kehityksessä. 

Johtavat käyttäjät ovat saattaneet kehitellä mielessään parempia tapoja toimia, joten 

heiltä löytyy yleensä arvokasta tietoa. Kehityksessä on kuitenkin tärkeää testata ideoita 

ja ratkaisuja tavallisilla käyttäjillä sekä ratkaisevilla käyttäjillä, koska he edustavat pää-

joukkoa. Ratkaisevat käyttäjät ovat ”käyttäjiä, jotka ovat avainasemassa laitteen laaja-



15 

alaiselle leviämiselle, mutta eivät saa siitä hyötyjä, jotka motivoisivat heitä käyttämään 

huonosti toimivaa laitteistoa”.  (Hyysalo, s.96-97 2009) 

 

 

Kuvio 2 Hankintasidosryhmien suhteet (Torvinen & Ulkuniemi, s.62, 2016) Muokattu 

 

Käyttäjäyhteistyössä on nopeita ja hitaita menetelmiä. Ongelmien ja parannusehdotus-

ten kartoitus on yleisin yhteistyömuoto, joka osallistaa käyttäjän ja on nopea toteuttaa. 

Tässä menetelmässä käyttäjiä pyydetään raportoimaan ongelmia ja esittämään kehitys-

ehdotuksia. Kehitysehdotuksia voidaan kerätä käyttäjille suunnatuissa työpajoissa, joissa 

kehitetään olemassa olevaa tuotetta tai kokonaan uutta tuotetta. Parannusehdotukset 

saattavat olla ristiriidassa toistensa kanssa ja jonkun asian toteuttaminen saattaa olla 

mahdotonta. Käyttäjäkerhot, jotka koostuvat harkituista käyttäjistä ovat yksi hyvä keino 

tuoda ongelmia ja kehitysehdotuksia esille kootusti. Käyttäjäseminaarit ovat tilaisuuksia, 

joihin organisaatio kutsuu tärkeimmät sidosryhmät keskustelemaan muutosaiheista. Se-

minaarit ovat hyviä tilaisuuksia perustella jotain tulevaa muutosta tai kehityksen koh-

detta. (Hyysalo, s.99 2009) 

 

Toinen käyttäjäyhteistyön osa-alue on toimintaympäristöön tutustuttaminen. Menetel-

mässä sitoutetaan käyttäjä järjestämään tutustumiskäyntejä, suostumaan havainnointiin 



16 

ja tuottamaan kaikenlaista relevanttia informaatiota toimintaympäristöstä. Menetel-

mässä hyödynnetään keskustelua käyttäjien keskuudessa heidän omissa toimintaympä-

ristöissään. Keskustelulla saadaan selville asioita, joita haastattelemalla ei välttämättä 

osattaisi kysyä. (Hyysalo, s.100-101 2009) 

 

Kolmas osa-alue, jossa osallistetaan käyttäjiä on uusien teknologioiden ennakointi ja sii-

hen liittyvä tuotekonseptien ideointi. Tässä menetelmässä keskustellaan oman alansa 

edistyneiden käyttäjien kanssa heidän oman alansa trendeistä ja teknologisesta kehityk-

sestä. Systemaattinen toiminta vaatii organisaatiolle perustettavaa asiantuntijaryhmää, 

jota konsultoidaan projektin tai muutoksen edetessä. (Hyysalo, s.101 2009) 

 

Neljäs osa-alue on käyttäjien suora osallistuminen suunnittelutyöhön. Käyttäjät osallis-

tuvat suunnittelutapaamisiin tai organisaation yleisiin suunnittelukokouksiin. Laajim-

malle ulottuva suunnitteluyhteistyön muoto on teknologian juurruttaminen. Juurrutta-

misesta puhutaan, kun uusi teknologia ei ole yhteensopiva suoraan olemassa olevaan 

tekniseen infrastruktuuriin. Aikaisempi teknologia on niin syvällä lainsäädännössä, jake-

lussa, huollossa, valmistuksessa ja käyttötavoissa, ettei uusi teknologia kykene niitä kor-

vaamaan. Juurruttamisessa lupaavia teknologioita pyritään kehittämään organisaatioi-

den, käyttäjien ja viranomaisten kanssa yhteistyössä. (Hyysalo, s.102 2009) 

 

2.3 Julkiset hankinnat 

”Hankinnalla tarkoitetaan tavaroiden ja palveluiden ostamista, vuokraamista tai siihen 

rinnastettavaa toimintaa sekä urakalla teettämistä.”(Eskola ja muut, s.44, 2017). Julkis-

yhteisöön kuuluu valtion ja kuntien eri yksiköt sekä liikelaitokset. Hankintalaissa määri-

tellään tarkemmin, keitä kaikkia hankintalainsäädäntö koskee. Hankintojen säätelyä on 

pidetty tärkeänä, koska niihin käytetään julkisia varoja. Julkisten varojen tehokas käyttö 

on kansantaloudellisesti erittäin merkittävä asia. (Karinkanta & Lahtinen, s.14, 2017) 

 

Julkisten hankintojen ominaisuuksiin kuuluu avoimuus ja hankinnoista ilmoitetaan han-

kintailmoituksella virallisia tiedottamiskanavia käyttäen. Avoimuuden tarkoituksena on 



17 

edistää tarjoajien tasapuolista kohtelua ja yhtäläistä mahdollisuutta osallistua kilpailu-

tuksiin. Julkisiin hankintoihin vaikuttaa myös EU-direktiivit, kun ne ylittävät tietyn euro-

määräisen kynnysarvon ja näistä tulee ilmoittaa EU- laajuisesti. Näin annetaan ulkomai-

sille toimijoille mahdollisuus osallistua kilpailuun. (Karinkanta & Lahtinen, s.14-15 2017) 

 

Hankintailmoituksen tekeminen tehdään EU-kynnysarvot ylittäviltä hankinnoilta TED-

tietokantaan ja sen jälkeen kotimaisessa Hilma-ilmoituskanavassa. EU-kynnysarvot alit-

tavista hankinnoista tehdään ainoastaan ilmoitus Hilma: ssa. Hankintailmoituksen julkai-

seminen käynnistää virallisen hankintamenettelyn ja hankinnan kilpailutus alkaa. (Karin-

kanta & Lahtinen, s.46-47 2017) Taulukossa 2 kooste erilaisista hankintamenettelyistä 

kuvauksineen. 

 

Taulukko 2 Hankintamenettelyt (Eskola ja muut, s.285-288, 2017) 

Menettely Kuvaus 

Avoin Voidaan käyttää kaikissa hankinnoissa, yksivaiheinen, käynniste-

tään hankintailmoituksella, kaikki kiinnostuneet oikeutettuja 

tarjouspyyntöön, sopii perushankintoihin 

Rajoitettu Voidaan käyttää kaikissa hankinnoissa, kaksivaiheinen, käynnis-

tetään hankintailmoituksella, hankintailmoituksessa kerrottava 

soveltuvuusehdot, tarjoajat valitaan hakemusten jättäneistä, 

tarjoukset pyydetään vähintään viideltä toimittajalta, ei neuvot-

telu mahdollisuutta, sopii perushankintoihin, joissa rajoitetaan 

tarjoajien määrää tai halutaan valita viisi parasta toimittajaa 

Neuvottelu Laissa määritetty tarkat käyttöedellytykset, kaksivaiheinen, 

käynnistetään hankintailmoituksella, hankintailmoituksessa ker-

rottava soveltuvuusehdot, tarjoajat valitaan hakemusten jättä-

neistä, neuvotteluvaiheeseen valitaan vähintään kolme toimit-

tajaa 

Kilpailullinen neu-

vottelu 

Samat kuin edellä, lisäksi yritykset tekevät ratkaisuehdotuksia 

hankinnan toteuttamisesta  



18 

Innovaatiokumppa-

nuus 

Hankinnan kohdetta ei löydy markkinoilta, kilpailutetaan tutki-

mus- ja kehittämistyö, hankintayksikkövoi tehdä hankinnan il-

man uutta tarjouskilpailua, mikäli kehitystyön tulokset ovat po-

sitiivisia, valinta tehdään, hinta-laatusuhteen perusteella, 

kumppaneille asetettava välitavoitteita 

Puitejärjestely avoin-, rajoitettu- tai neuvottelumenettely 

Dynaaminen han-

kintajärjestelmä 

Sähköinen hankintamenettely, monivaiheinen, käynnistetään 

hankintailmoituksella 

Suunnittelukilpailu Tarkoituksena hankkia suunnitelma, jonka tuomaristo valitsee 

Suorahankinta Laissa määritetty tarkat käyttöedellytykset 

 

Hankintaprosessi alkaa valmistelusta, joka on julkisissa hankinnoissa kaikkein tärkein 

vaihe. Vaiheessa määritellään toteutus ja määritellään kohteen tavoitteet sekä periaat-

teet. Hankintalaki ohjaa hankintaprosessia ja sen tavoitteena on tehostaa julkisten varo-

jen käyttöä, edistää laadukkaiden, innovatiivisten ja kestävien hankintojen tekemistä. 

(Karinkanta & Lahtinen,s. 35 2017) 

 

Hankinnan kohteen muuttuessa monimutkaisemmaksi, korostuu prosessissa valmistelun 

ja rahoituksen merkitys. Kohteen kompleksisuus saattaa vaatia esiselvitystä ja ratkai-

suehdotuksia toimittajilta, jotta tarjouspyynnöt ja päätökset voidaan tehdä mahdollisim-

man kattavilla tiedoilla. Teknistä vuoropuhelua suoritetaan jo tarjouspyynnön tekovai-

heessa. (Karinkanta & Lahtinen, s. 37. 2017) Taulukosta 3, selviää Valtion Hankintakäsi-

kirjan mukainen hankintaprosessi ja sen vaiheet. 

 

Taulukko 3 Julkinen hankintaprosessi (Valtion Hankintakäsikirja OSA 1, 2017, s.33-34) 

1 Hankinnan suunnittelu, valmistelu ja toteutusvaihtoehdon valinta 

2 Hankinnan kohteen määrittely sekä hankintaehdotuksen teko tarvittaessa 

3 Hankintamenettelyn valinta 

4 Tarjouspyynnön laatiminen ja hankinnasta ilmoittaminen 



19 

5 Ehdokkaiden osallistumishakemusten arviointi ja tarjoajien valinta kaksivai-

heisessa menettelyssä 

6 Tarjousten vastaanottaminen ja avaaminen 

7 Tarjoajien soveltuvuuden arviointi muissa kuin kaksivaiheisissa menettelyissä 

8 Tarjousten tarjouspyynnönmukaisuuden tarkistaminen 

9 Tarjousten vertailu 

10 Hankintapäätöksen tekeminen 

11 Hankintapäätöksen tiedoksianto 

12 Sopimuksen tai tilauksen tekeminen 

13 Sopimuksen ja toimituksen valvonta 

14 Sopimushallinta ja toimittajayhteistyö 

15 Laskujen käsittely ja maksaminen 

16 Määrärahojen seuranta 

 

Hankintailmoituksessa tai tarjouspyynnöissä ilmoitetaan tarjoajien soveltuvuuskriteerit 

ja -ehdot. Ehtojen ja kriteerien tavoitteena on pienentää riskiä karsimalla pois ne toimit-

tajan, jotka eivät pysty toimittamaan hankintaa. Tarjoukset käydään läpi ehtojen ja kri-

teerien perusteella ennen kuin ne otetaan varsinaiseen vertailuun. Automaattinen pois-

sulku tulee kyseeseen, jos toimittajalla on jonkinlaisia rikosseuraamuksia viimeisen vii-

den vuoden ajalta. (Karinkanta & Lahtinen, s. 50-51 2017) 

 

JHS 152 suositus käsittelee julkisen hallinnon prosessien kuvaamista. Suositus on tehty 

prosessien selkeyttämisen ja yhdenmukaistamisen vuoksi. Prosessikuvauksia voidaan 

hyödyntää johtamisessa ja toiminnan kehittämisessä. Kuvaukset ovat myös käytössä pe-

rehdyttämisessä, koulutuksessa ja tietojärjestelmien kehittämisessä. Julkisen sektorin 

prosessien mallintamisessa käytetään Object Management Groupin Business Process 

Modeling Notation- määritystä ja suositusten käyttäjiä ovat jokainen julkisen hallinnon 

henkilöt, jotka työkseen kuvaavat prosesseja. Organisaation johto tunnistaa prosessit ja 

määrittelee niille omistajat. Omistajat määrittelevät prosessien kuvaustasot. (JHS 152 



20 

Prosessien Kuvaaminen | Suomidigi, n.d.) Kuviossa 4 nähdään prosessien kuvaustasot. 

Yksityiskohtaisuus lisääntyy siirryttäessä vasemmalta oikealle. 

 

 

Kuvio 3 Prosessien kuvaustasot (JHS 152 Prosessien Kuvaaminen | Suomidigi, n.d.) 

 

Tämän tutkielman osalta oleellisimmat kuvaustasot ovat prosessinkulku ja työnkulku. 

Molemmat vaiheet kuvataan uimaratakaaviolla. Prosessinkulkutasolla kuvataan toimin-

nan työvaiheet, toiminnot ja niistä vastaavat toimijat. Tällä tasolla tarkastellaan prosessin 

ja osaprosessien välistä vuorovaikutusta ja voidaan lisätä resursseja tarpeen mukaan. 

Tällä tasolla eritellään toiminnot, tehtävät ja syötteet sekä nimetään tai numeroidaan 

asiat tunnistettavalla tavalla. (JHS 152 Prosessien Kuvaaminen | Suomidigi, n.d.) 

 

Työnkulku- tasolla kuvataan sisäiset ja ulkoiset riippuvuudet. Kuvauksesta tulee ilmi mi-

ten tieto eri toimintojen välillä liikkuu. Tasoa käytetään prosessien kehittämiseen, työoh-

jeiden laatimiseen tai prosessin digitalisoimiseen. (JHS 152 Prosessien Kuvaaminen | 

Suomidigi, n.d.) 

 



21 

2.4 Aiemmat tutkimukset 

Vuonna 2013 Suomessa suunniteltiin siirtymistä valtakunnallisiin sähköisiin asiakastieto-

järjestelmiin. Valtakunnallisella siirtymisellä tavoiteltiin muun muassa tietojen ajantasai-

suutta ja parempaa tietoturvaa. Kansallinen terveysarkisto KanTa perustettiin vuonna 

2013 edeltävästi. KanTa palveluita käyttävät sekä ammattilaiset että terveyspalveluiden 

käyttäjät. Kansallisen terveysarkiston palveluihin kuuluu sähköinen lääkemääräys, poti-

lastietoarkisto ja terveyspalvelun käyttäjän mahdollisuus katsoa internetin kautta omia 

terveystietojaan. (Valta, s.21, 2013) 

 

Sosiaali- ja terveydenhuollon tietojärjestelmien ja sähköisen asioinnissa on hyödynnetty 

uutta teknologiaa, sillä se luo mahdollisuuden sosiaali- ja terveydenhuollon ammattilais-

ten työn tuottavuuden ja tehokkuuden lisäämiseen. Tietojärjestelmien käyttöönotto ei 

ole riskitöntä. Tietojärjestelmät ovat kalliitta ja lisäksi kaikki virheet ja puutteet voivat 

vaikuttaa kielteisesti potilaisiin ja työntekijöihin. Puutteellisissa tietojärjestelmissä ja 

huonosti suunnitellussa käyttöönotossa potilaan kohtaamiseen ei välttämättä ole riittä-

västi aikaa, sillä potilaskontaktiin varattu aika kuluu tietokoneella työskentelyyn. Tieto-

järjestelmien käyttöönotossa on tärkeintä, että työntekijät pystyvät ja osaavat hyödyntää 

uutta teknologiaa työssään. (Valta, 2013) 

 

Tadeliksen (Tadelis, 2012) mukaan julkisen ja yksityisen sektorin hankinnat eivät poikkea 

merkittävästi toisistaan, mutta hankintaprosessit ovat täysin erilaiset. Kansainvälisesti 

sähköisten potilastietojärjestelmien käyttöönotosta on tehty paljon kansainvälistä tutki-

musta. Tutkimustulokset järjestelmistä ja niiden hyödyistä ja haitoista ovat hyvin ristirii-

taisia keskenään. Suomessa tieteellistä tutkimusta on tehty hyvin vähän sähköisistä po-

tilastietojärjestelmistä, vaikka mediassa keskustelua on ollut paljon. ,(Valta, s.22-24, 

2013) 

 

”Käytettävyysongelmat eivät ratkea itsestään”. Tutkimuksen tarkoitus: Potilastietojärjes-

telmiä on aiemmin tutkittu toimintojen, mukautuvuuden ja käyttötarkoituksiin keskit-



22 

tyen. Säännöllisiä käytettävyystutkimuksia ei ole tehty terveydenhuollon ammattihenki-

löiden toimesta ollenkaan. Tutkimuksessa tehtiin kysely kliinistä työtä tekevien lääkärei-

den käytettävyyskokemuksista käytössä olevista potilastietojärjestelmistä. Tutkimusky-

symyksenä oli: Miten tilanne käytettävyyden osalla on muuttunut 2010-2014 ja onko jul-

kisen ja yksityisen sektorin välillä eroavaisuuksia? Tutkimus osoitti lievää parannusta käy-

tettävyydessä, mutta korosti käytettävyystutkimuksen jatkamista säännöllisin väliajoin. 

Hyvä käytettävyys myös nostaa lääkäreiden tehokkuutta ja parantaa potilasturvallisuutta. 

(Kaipio ja muut., 2017) 

 

”Kyvykkäät ja innokkaat lääkärit että hoitajat ovat alihyödynnettyjä tietojärjestelmien ke-

hittämisessä terveydenhuoltoalalla”. Loppukäyttäjän osallistaminen ohjelmistokehityk-

seen on erittäin tärkeää, jotta saadaan järjestelmiä, jotka sopivat terveydenhuollon am-

mattilaisille. Tutkimus toteutettiin 2017 ja siinä perehdyttiin, kuinka suuri osa ammatti-

henkilöistä on osallistunut ohjelmistokehitykseen ja minkälaiset kokemukset heillä siitä 

jäi. Sama kysely on toteutettu jo vuonna 2010 ja 2014. Tutkimukseen osallistui yli 7600 

terveydenhuollon ammattilaista, joista vähän yli puolet olivat lääkäreitä ja vähän alle 

puolet sairaanhoitajia. (Martikainen ja muut., 2018) 

 

Tutkimuksen tulokset osoittivat noin puolen molemmista ammattiryhmistä osallistu-

neen ohjelmistokehitykseen. Vain alle 20 prosenttia kaikista vastanneista eivät olleet ha-

lukkaita osallistumaan kehitykseen ollenkaan. Huomattava löydös oli myös se, että oh-

jelmistosta riippuen, 43-93 prosenttia vastaajista tunsi ettei ohjelmistotalot olleet kiin-

nostuneita heidän kehitysehdotuksistaan. Tutkimuksen mukaan tilanne ei ollut muuttu-

nut vuoden 2010 lukemista parempaan suuntaan. (Martikainen ja muut, 2018) 

 

Tutkimuksen mukaan monet terveydenhuollon ammattilaiset ovat todellakin kiinnostu-

neita osallistumaan terveydenhuollon ohjelmistokehitykseen, mutta riittäviä työkaluja 

loppukäyttäjän osallistamiseen ei ole tuotu esille. Kehitykseen osallistuminen vaatii ai-

kaa ja aika tulisi sijoittaa työajalle ja johdon tulisi ymmärtää, että ohjelmistokehitykseen 



23 

varattu aika luo mahdollisuuksia alalle. Kehityksen tulisi kuitenkin keskittyä vielä kliinistä 

työtä tekevien keskuuteen. (Martikainen ja muut., 2018) 

 

Esimerkiksi Haukipuron ja muiden (2016) mukaan loppukäyttäjän osallistaminen julkisiin 

hankintoihin on lisännyt innovatiivisuutta. Tutkimuksessa käytettiin Living Lab menetel-

mää, joka osallistaa loppukäyttäjän tuotekehitykseen. Käyttäjät testasivat tuotteita ja oli-

vat mukana kehityksessä tuotteiden käyttöympäristöissä. Paras ratkaisu ei ollut se halvin, 

vaan tuote, jonka laatu oli paras loppukäyttäjien mielestä. Tutkimus osoittaa, että julkis-

ten hankintojen tulisi keskittyä myös testaamiseen loppukäyttäjillä, jolloin sopivan hinta-

laatu suhteen määrittäminen saadaan päätösten tueksi. Tutkimuksessa esitetään lopuksi 

käyttäjätestauksen viitekehyksen luomista osaksi julkisia hankintoja. (Haukipuro ja muut., 

2016) 

 

Tarpeellisuus loppukäyttäjän sitouttamiseen terveydenhuollon ohjelmistokehitykseen 

on väistämätöntä. Edelleenkään tutkimusta aiheesta ei ole tarpeeksi ja etenkin kokemus-

ten. Parhaiden käytäntöjen luominen loppukäyttäjän sitouttamiseen terveydenhuollon 

ohjelmistokehitykseen on edelleen olematonta. (Martikainen ja muut., 2020) 

 

Martikaisen ja muiden (2020) toteuttaman tutkimuksen mukaan, johon osallistui noin 

5600 terveydenhuollon ammattilaista, edelleen noin puolet vastasivat osallistuneen oh-

jelmistokehitykseen. Osallistuneiden joukosta 85 prosenttia vastasivat, ettei ohjelmisto-

talot ole kiinnostuneita heidän kokemuksistaan ja kehitysideoistaan. Yli puolet vastaa-

jista kertoi haluavansa osallistua kehitykseen sellaisen henkilön kautta, joka on vastuussa 

ohjelmistokehityksestä kyseisessä organisaatiossa. Huomattavaa on, että vain 10 pro-

senttia vastaajista kertoi kehitysideoidensa tulleen huomioiduksi ja alle 10 prosenttia 

vastasi toimenpiteiden kehityksessä olleen riittävän nopeita. Terveydenhuollon ammat-

tilaiset eivät edelleenkään koe, että heidän loppukäyttäjänäkemystänsä huomioitaisiin 

tai, että he oikeasti pääsisivät vaikuttamaan kehitykseen. (Martikainen ja muut, 2020) 

 



24 

Kaipion ja muiden (2015) tekemässä tapaustutkimuksessa kerrotaan kuinka sosiaali- ja 

terveydenhuollon tietojärjestelmähankinnoissa loppukäyttäjä- ja käytettävyys näkökul-

mien huomioiminen on ollut lähes olematonta. Tapaustutkimuksessa kuvataan menet-

telyprosessi käytettävyyden ja loppukäyttäjänäkökulman huomioimiseen tietojärjestel-

mähankinnassa. Menettelyprosessissa on viisi kokonaisuutta: käytettävyystavoitteiden 

määrittely, toiminnallisten vaatimusten ja käyttäjätarinoiden tuottaminen, käytettävyys-

arvioinnin suunnittelu tuotevertailun tarpeisiin, käytettävyysarvioinnin toteutus osana 

tuotevertailua ja käytettävyyteen liittyvien vaatimusten määrittely.  

 

Apotti-hankkeen käytettävyystyö aloitettiin kuvaamalla koko hankkeen käytettävyysta-

voitteet. Tavoitteiden määrittely perustettiin ISO standardiin ja Nielsenin määritelmiin 

käytettävyydestä. Käytettävyystavoitteiden määrittelyä suoritettiin yhtä aikaa järjestel-

män toiminnallisten vaatimusten määrittelyn kanssa. Toiminnallisten vaatimusten mää-

rittelyyn osallistui yli 400 sosiaali- ja terveydenhuollon sekä tietotekniikan ja johtamisen 

sekä potilasjärjestöjen edustajaa. Vaatimusmäärittely toteutettiin ohjatusti noin sadassa 

työpajassa, joiden perusteella vaatimukset ja tavoitteet saatiin määriteltyä käytettävyys-

arvioinnin suunnitteluun tuotevertailua varten. Tuotevertailun ja lopullisten käytettä-

vyysvaatimusten perusteella luotiin lopullinen tarjouspyyntö. Kuviossa 4 on hahmotelma 

menetelmäprosessista, jossa huomioidaan loppukäyttäjä ja käytettävyys. (Kaipio ja 

muut., s.110-116 2015) 

 



25 

 

Kuvio 4 Käytettävyys- ja loppukäyttäjänäkökulma tietojärjestelmähankinnassa (Kaipio ja 
muut, s.110, 2015) 

 

Loppukäyttäjien rooli toiminnanmuutoksessa ja järjestelmähankinnassa on tärkeä. Han-

kintaorganisaation on tunnettava loppukäyttäjä, jotta se pystyy ymmärtämään hankin-

nan kohteena olevan ympäristön ja toimintamallit. Loppukäyttäjien koulutukseen ei 

kuulu vaatimusmäärittelyosaaminen, joten heidän valintaan ja osallistamiseen tulee 

käyttää erityistä huomiota. Loppukäyttäjien kouluttaminen oman alansa tietojärjestel-

mätoiminnallisuuksien asiantuntijoiksi tulee aloittaa heti, sillä tietoa tarvitaan myös 

käyttöönotto- ja tuotantovaiheen aikana. (Kaipio ja muut, s.118 2015) 

 

Scheurerin ja muiden (2022) tekemän tutkimuksen tuloksena syntyi vaatimusmääritte-

lyviitekehys, kuvio 5, joka sopii kaikenlaisiin ohjelmistoprojekteihin. Viitekehys koostuu 

neljästä vaiheesta, joissa jokaisessa on vähintään kaksi erillistä tehtävää tai tapahtumaa. 

Ensimmäisessä vaiheessa tehdään kirjallisuuskatsaus, joka keskittyy julkaisuihin, jotka 

käsittelevät kehityksen kohteena olevaa asiaa. Kirjallisuuskatsausta käytetään ensimmäi-

sen työpajan pohjana, joissa tehdään vaatimusmäärittelyä tai käyttötapauksia. Ensim-

mäisessä vaiheessa voidaan ottaa jo loppukäyttäjiä mukaan määrittelytyöhön.  

 



26 

Toisessa vaiheessa kerätään vaatimuksia ulkopuolisilta sidosryhmiltä kyselyiden avulla. 

Kyselyiden tavoitteena on kerätä tietoa laajemmalta joukolta, jotta saadaan käsitys ko-

konaisuudesta. Tämän vaiheen työpajaan osallistetaan loppukäyttäjät ja niiden on tar-

koitus olla riittävän ohjattuja, jotta loppukäyttäjien kiinnostus projektiin saadaan säily-

mään. Näiden työpajojen on tärkeää tuoda esille projektin tavoitteet ja mitä loppukäyt-

täjiltä halutaan. 

 

 

Kuvio 5 Vaatimusmäärittelyn viitekehys (Scheuer ja muut, s.6 2022) 

 

Kolmannen vaiheen tarkoituksena on arvioida ja priorisoida kerätty aineisto, jonka pe-

rusteella voidaan muodostaa hankkeen vaatimukset tai käyttötapaukset. Vaatimusmää-

rittelyaineistosta tehdään lista, jotta niitä voidaan priorisoida. Valmiiden analyysipohjien 

perusteella loppukäyttäjät voivat arvioida kerätyn aineiston ja näin saadaan selville asi-

oiden riippuvuuksia. Viimeisessä vaiheessa aineisto käydään läpi toimittajien kanssa ja 



27 

määritellään tarvittavat resurssit. Tämän vaiheen tavoitteena on tuoda esille loppukäyt-

täjien tärkeimmät vaatimukset toteutukselle, mitä voidaan käyttää hankkeen myöhem-

missä vaiheissa. 

 

Torvisen ja Haukipuron (2018) tekemän tutkimuksen mukaan hankinnoissa on tunnistet-

tavissa neljä erilaista loppukäyttäjän roolia: Perinteinen, yhteistyökykyinen, yhteistyö-

hön perustuva ja kontrolloiva. Perinteinen käyttäjärooli kuvaa asetelmaa, jossa käyttäjä 

nähdään ainoastaan hankinnan kohteena olevana asiana, joten hankintaorganisaation 

interaktiivisuus on vähäistä käyttäjään nähden ja kommunikointi jää ainoastaan toimit-

tajan ja hankintaorganisaation välille. Yhteistyökykyinen rooli käyttäjällä on arvoa tuot-

tava ja käyttäjää osallistetaan hankintaan hieman. Tässä roolissa käyttäjä jää kuitenkin 

taustalle, koska toimittajan ja hankintaorganisaation tavoitteet käyttäjän osallistamisesta 

projektiin poikkeavat merkittävästi. Yhteistyöhön perustuvassa roolissa kaikki kolme osa-

puolta toimivat tasapuolisina kumppaneina läpi hankintaprosessin ja jakavat tietoa toi-

silleen. Käyttäjän ollessa yhteistyöhön perustuvassa roolissa, on kommunikointi avointa 

ja prosessia tukevaa. Neljännessä roolissa prosessia kontrolloi käyttäjä. Tämän roolin on-

gelmiin saattaa kuulua käyttäjän omien intressien näkyminen liian voimakkaana loppu-

tuloksen kannalta, jolloin muu joukko saattaa jäädä huomioimatta ja lopputulos jäädä 

kauas halutusta.  

 

Torvisen ja Haukipuron (2018) mukaan käyttäjäroolit täytyy tunnistaa hankintaorgani-

saation tai toimittajan toimesta. Yksi käyttäjä voi toimia kaikissa rooleissa hankinnan eri 

vaiheissa. Tärkeää on kuitenkin hallita, miten eri rooleja hyödynnetään eri kontekstissa. 

Perinteisen roolin osallistaminen voi olla projektin kannalta tärkeää esimerkiksi, kun 

suunnitellaan lapsiin liittyviä palveluita, joihin vanhemmat voivat vaikuttaa. Yhteistyöky-

kyisen roolin osallistaminen voi tulla kyseeseen esimerkiksi koulun yhteisten alueiden 

suunnittelussa oppilaiden voimin. Tärkeää on kuitenkin tunnistaa kontrolloivan roolin 

haitallisuus tietyissä tilanteissa.  

 



28 

Gulliksenin ja muiden (2003) tekemässä tapaustutkimuksessa testattiin heidän itse ke-

hittämäänsä muutaman kohdan käyttäjäkeskeisen suunnittelun periaatetta. Tutkimus 

seurasi uuden digitaalisen työkalun kehittämistä alusta loppuun. Ensimmäinen periaate 

keskittyy käyttäjän ympäristön ja käytännön työn toimivan kehityksen ohjaajana. Toinen, 

käyttäjän aktiiviseen osallistamiseen koko projektin aikana. Osallistaminen periaatteen 

mukaisesti sisältää analyysivaiheen, suunnitteluvaiheen, kehityksen ja arvioinnin. Tämä 

periaate ehdottaa huolellista käyttäjävalintaa, joka keskittyy kahteen käyttäjäryhmään, 

pääkäyttäjiin ja loppukäyttäjiin. Pääkäyttäjät tulisi olla mukana läpi hankkeen ja loppu-

käyttäjiltä kerätään informaatiota haastatteluin ja havainnoimalla. Lopullisen arvioinnin 

tekevät loppukäyttäjät. 

 

Kolmas periaate kehottaa tekemään prototyyppejä ja arvioimaan ne käyttäjien kanssa 

mahdollisimman aikaisessa vaiheessa, jotta tuote vastaa käyttäjien tarpeita nyt ja tule-

vaisuudessa. Neljäs periaate liittyy jatkuvaan iteratiiviseen ratkaisukehitykseen. Iteraa-

tion syklit, suunnittelu, arviointi ja uudelleen suunnittelu tulisi toistaa mahdollisimman 

useasti ja arvioinnin tulee perustua tuotteen empiiriseen testaamiseen, jossa käyttäjät 

toimivat omassa työympäristössään. Testaamisen tulee keskittyä käyttäjien reaktioihin 

ja asenteisiin tuotetta käyttäessä. Viidennessä periaatteessa mainitaan monialaiset 

suunnitteluryhmät, joissa on erilliset käytettävyyteen erikoistuneet henkilöt. Kuuden-

nessa periaatteessa mainitaan tuotteen suunnittelun, kehityksen ja koulutuksen synkro-

noimista. (Gulliksen ja muut, 2003) 

 

Gulliksenin ja muiden (2003) tutkimuksen tuloksissa mainitaan käytettävyyssuunnitteli-

jan ja käytettävyystutkijan fasilitoineen prototyyppityöpajoja käyttäjien kanssa ja nämä 

olivat avain onnistuneeseen lopputulokseen. Loppukäyttäjät saivat tuoda luonnoksien 

avulla esille heidän omat näkemyksensä, jotka huomioitiin varsinaisessa tuotteen suun-

nittelussa. Työpajojen perusteella käytettävyys suunnittelijat pystyivät tekemään varsi-

naisen suunnittelun ja kehityksen tueksi käyttäjätarinoita, joita hyödynnettiin käyttöta-

pausten tekemiseen. Projektissa törmättiin myös ongelmiin. Ongelmat liittyivät käytet-



29 

täviin resursseihin, käyttäjäkeskeisen suunnittelun vastustamiseen, käytettävyyden ym-

märtämättömyyteen, viestintään ja osaamisen sekä riittävän aikaiseen osallistamiseen 

puutteeseen projektin aikana. Merkittävänä huomiona tutkimuksessa oli käyttäjien liial-

linen osallistaminen, joka vaikutti negatiivisesti suunnitteluun, koska he etääntyivät käy-

tännön työstään liikaa. 

 

Cajanderin ja muiden (2022) tekemän tutkimuksen mukaan, mihin oli haastateltu kah-

deksaatoista henkilöä eri organisaatioryhmistä, suhtautuivat tulevaisuuteen järjestel-

mien osalta positiivisesti. Taulukossa 4 on Cajanderin ja muiden (2022) tekemän tutki-

muksen merkittävimpien tulosten koonti käyttäjäkeskeisyydestä yrityksessä. Asiantunti-

joiden suunta käyttäjäkeskeisempään ajatteluun yrityksessä on äärimmäisen tärkeää, 

mutta he eivät usko loppukäyttäjien systemaattiseen osallistamiseen tulevaisuudessa ja 

teknologian hankkiminen tulee perustumaan edelleen vain kiinnostuksesta uutta tekno-

logiaa kohtaan, ei organisaation ja käyttäjien tarpeiden mukaan. (Cajander ja muut, 2022) 

 

Taulukko 4 Käyttäjäkeskeisyys yrityksessä (Cajander ja muut, 2022) 

 Asiantuntijat Johtajat Projektipäälliköt 

Käytössä oleva tek-

nologia 

Kehittäjät eivät ole tietoisia käyttäjien muuttuvista tarpeista 

• Käyttäjien osal-
listaminen 
kriittistä 

• Käyttäjiä ei tällä 
hetkellä osallis-
teta 

• Organisaatiora-
jat ylitettävä 

• Muutoksen joh-
taminen on to-
della raskasta 

• Käyttäjiä osal-
listetaan, mutta 
erittäin vähän 

• Kehittäjät eivät 
tunne käyt-
täjäkeskeistä 
suunnittelua 

• Muutoksen 
johtaminen on 
raskasta 

Teknologia strate-

gia 

Optimistinen suhtautuminen tulevaisuuteen 

• Päätöksenteko 
perustuu aino-
astaan kiinnos-
tukseen uu-
desta teknolo-
giasta 

• Epäilys ettei 
käyttäjät osaa 
viestiä omia tar-
peitaan riittä-
vän selkeästi 

• Positiivinen su-
htautuminen 
uusiin hal-
lintomalleihin 

• Mallit vaativat 
radikaalimpia 



30 

• Päätökset eivät 
perustu käyttä-
jien tarpeeseen 

muutoksia kuin 
ollaan osattu 
ajatella 

Teknologian luonne • Järjestelmät 
täytyy sopeut-
taa organisaa-
tion ja käyttä-
jien tarpeiden 
mukaan 

• Aiemmin on 
keskitytty asia-
kasjärjestel-
mien kehittämi-
seen, eikä niin-
kään organisaa-
tion käyttäjien 
käyttämiin jär-
jestelmiin 

• Positiivinen 
asenne itseke-
hitettyihin jär-
jestelmiin 

• Itsekehitetyt 
järjestelmät, 
joissa on käytet-
tävyys ongel-
mia tuottavat 
haasteita 

 

Johtajien näkökulmasta muutosjohtaminen on äärimmäisen raskasta ja ovat epäileväisiä 

organisaation käyttäjien kyvystä ilmaista tarpeitaan teknologian osalta riittävän selkeästi, 

jotta siitä olisi hyötyä kehityksessä. Projektipäälliköiden mukaan käyttäjien osallistami-

nen on liian rajoittunutta ja sitä täytyisi lisätä, jotta kehittäjille saataisiin ajantasaista tie-

toa. Ongelmana on kehittäjien tietämättömyys käyttäjäkeskeisestä toimintamallista. (Ca-

jander ja muut, 2022) 

 

Lantzin ja Holmlidin (2010) tekemän tutkimuksen mukaan hankintaorganisaation ja IT 

organisaation välillä on yleensä liian syvä kuilu. Molemmat organisaatiot toimivat erilli-

sinä toimijoina ja käytettävyyden määritelmä poikkeaa merkittävästi toisistaan. Kumpi-

kaan osapuoli ei ole riittävän tietoinen toistensa prosesseista, joten yhteistyö jää olemat-

tomaksi. Tutkimuksessa haastateltujen mielestä hankintaorganisaation tulisi olla aktiivi-

sin toimija ja alkaa luomaan parempaa sidosryhmäyhteistyötä ja luopua ajatuksesta, 

jossa hankinnan vaatimusmäärittelyn vastuu siirretään ilman kontrollia suoraan IT orga-

nisaatiolle. (Lantz & Holmlid, 2010) 

 

Lee ja muut (2016) kirjoittavat tutkimuksessaan hankintaorganisaation olevan kriitti-

sessä roolissa hankittaessa monimutkaisia järjestelmiä. Yhteishankinnoissa projektin 

johtajuus jää yleensä epäselväksi ja vaatimusmäärittely etukäteen laajoissa järjestelmä 

hankkeissa tämän vuoksi epäonnistuu. Lee ja muut (2016) nostavat esille toimittajien 

kanssa tehdyt sopimukset, joissa ei ole huomioitu kaikkien tarpeita ja koko hankinnan 



31 

rajoitteet ja vaatimukset jäävät epäselviksi sekä tehdyt sopimukset keskeneräisiksi. Toi-

mittajalle annetaan liikaa valtaa ja hankintojen vaatimusten tulisi keskittyä ”bottom-up” 

lähestymistapaan, jossa aidosti huomioidaan toimintaympäristön vaatimukset ja käyttä-

jän tarpeet. 

 

Riihimäki ja Pekkola (2021) ovat tekemässään tutkimuksessa analysoineet hankintaan 

liittyviä ongelmia, ja etenkin ostajan kannalta. He ovat koonneet neljän kokonaisuuden 

mallin, mistä selviää heidän tulkintansa suurimmista huolista, taulukko 5.  

 

Taulukko 5 Hankintaan liittyvät huolet (Riihimäki & Pekkola, 2021) 

Projektin tavoittei-

den ja ajureiden 

huolet 

Huolet ratkaisun 

soveltuvuudesta 

Hankintaan liittyvät 

huolet 

Projektin onnistu-

neeseen toimituk-

seen liittyvät huolet 

• Kiirehdityt ai-
kataulut 

• Rajoitettu 
budjetti 

• lainsäädännön 
muutokset 

• Sisäisen kyvyk-
kyyden puute 

• Operatiiviset 
tavoitteet 

• Tehokkuus 

• Ympäristön 
vaatimukset 

• Ratkaisu on 
vasta pro-
totyyppi 

• Ratkaisun tur-
vallisuus 

• Arkkitehtuurin 
soveltuvuus 

• Operatiivinen 
soveltuvuus 

• Hankinnan ra-
joitteet 

• Markkinakorko 

• Hankinnan tur-
vallisuus 

• Vastuullinen ja 
luotettava 
toimittaja 

• Oikean 
tarjouksen 
hyväksyminen 

• Tarjouskilpailun 
haasteet 

• Toimitus 

• Monialainen 
osaaminen 

• Paikallisuus 

• Sitoutuneisuus 

• Taloudellinen 
vakaus 

• Toimittaja tur-
vallisuus 

• Yhteistyö 

 

Huolet esiintyvät julkisisissa hankinnoissa jo aikaisessa vaiheessa. Projektilla on yleensä 

jonkinlainen tavoite ja liian kireä aikataulu toteutukseen. Pitkissä projekteissa yleenä 

lainsäädäntökin muuttuu kesken kaiken ja tuo haasteita hankinnalle. Toinen asia johon 

kiinnitetään huomioita on ratkaisun relevanttius siihen ympäristöön mihin sitä ollaan 

tuomassa. Onko toimittaja tarpeeksi luotettava ja vastuullinen ja saadaanko projekti toi-

mitettua ajallaan. (Riihimäki & Pekkola, 2021) 



32 

3 Menetelmä 

Tutkielman tavoitteena oli luoda hankintaprosessi, joka osallistaa loppukäyttäjän hankin-

taan. Aihe valikoitui valtakunnallisesti terveydenhuollon ja sosiaalihuollon käyttöönotta-

man tietojärjestelmän käytettävyysongelmista, josta uutisointi on ollut pelkästään nega-

tiivista. 

 

Tässä tutkielmassa käytettiin suunnittelutieteellistä tutkimusmenetelmää. Tietoperusta 

ongelman ratkaisuun muodostui kirjallisuuskatsauksesta, kyselystä ja teemahaastatte-

luista. Kysely (liite 1) rajattiin sosiaali- ja terveydenhuollon ammattilaisiin, jotka ovat ol-

leet ohjelmistohankinnassa mukana. Loppukäyttäjäkyselyn perusteella saatiin muodos-

tettua teemat haastatteluihin (liite 2). Tietoperustan avulla suunniteltiin ensimmäinen 

luonnos artefaktista, joka annettiin hankinta-asiantuntijoille kommentoitavaksi. Kom-

mentointikierrosten jälkeen artefaktia paranneltiin ja tuotettiin lopullinen artefakti, 

jonka hyödyllisyys arvioitiin hankinta-asiantuntijoiden toimesta. Valmiin artefaktin arvi-

oinnin pohjana käytettiin Hevnerin ja muiden (2004) luoman suunnittelutieteellisen tut-

kimuksen ohjeita (taulukko 4). 

 

3.1 Suunnittelutieteellinen tutkimus 

Suunnittelutieteellinen tutkimus, englanniksi Design Science Research (DSR), on ongel-

man ratkaisu paradigma, joka parantaa ihmisten tietoisuutta innovatiivisten artefaktien 

luomisen avulla. Menetelmä tähtää teknologiseen kehitykseen ja tuomaan jotain uutta 

tieteelliseen yhteisöön. Tuloksena uusia artefakteja ja uutta suunnittelutietämystä (DK) 

nykyajan ongelmiin. (Brocke ja muut, s.1-2, 2020; Peffers ja muut, s. 9 2018) Alla kuva 

suunnittelutieteellisen tutkimuksen sykleistä. 

 



33 

 

Kuvio 6 Suunnittelutieteellisen tutkimuksen syklit (Hevner, s.88, 2007) 

 

Hyvä suunnittelutieteellinen tutkimus alkaa yleensä ongelman tai mahdollisuuksien tun-

nistamisesta tietyssä ympäristössä. Relevanssisykli osoittaa tutkimukselle vaatimukset ja 

määrittelee sen arviointikriteerit. Artefaktin tulee täyttää kriteerit, ratkaista jokin on-

gelma tai luoda uusia mahdollisuuksia sen käyttöympäristössä. Artefaktin testaus ja ar-

viointi määrittää, tarvitaanko uusia iteraatioita. (Hevner, s.88-89, 2007) 

 

Suunnittelutieteellisessä tutkimuksessa hyödynnetään aikaisemmin tuotettua tietoa ja 

menetelmiä, jotta voidaan luoda uutta tietoa perustuen jo tutkittuihin asioihin. Täsmäl-

lisyyssykli varmistaa aiemman tiedon perusteella tutkimuksen innovatiivisuuden. Suun-

nittelutieteelisessä tutkimuksessa on tärkeää tietää mitä on aiemmin kehitetty, jotta teo-

rioita ja menetelmiä voidaan uuden artefaktin luomisessa hyödyntää. (Hevner, s.89-90, 

2007) 

 

Suunnittelusykli on suunnittelutieteellisten projektien sydän. Suunnittelusykli perustuu 

iteraatioihin, joissa arvioidaan ja rakennetaan uutta artefaktia, hyödyntäen aiempaa tie-

toa ja asetettuja vaatimuksia aiheesta ratkaisemaan ongelman. Suunnittelusyklissä on 

tärkeää säilyttää tasapaino rakentamisen ja arvioinnin välillä. Suunnittelutyö täytyy arvi-

oida ja testata suunnittelusyklissä ennen kenttätestausta. (Hevner, s.90 2007) 

 



34 

Suunnittelutieteellinen tutkimus tähtää tuottamaan tietoa parhaista käytännöistä, jotta 

ihmiset saavuttaisivat tavoitteitaan. DSR tulokset tietojärjestelmätieteessä ovat näyttä-

neet tuovan taloudellisia ja sosiaalisia hyötyjä yhteiskuntaan. DSR: tä on tullut tietojär-

jestelmätieteen keskeisin tutkimusparadigma informaatioteknologian alalla. Sitä hyö-

dynnetään insinööritoiminnassa, arkkitehtuurissa, yritystoiminnassa ja taloustieteessä. 

(Brocke ja muut, 2020) Alla taulukko suunnittelutieteellisen tutkimuksen ohjeista. 

 

Taulukko 6 Suunnittelutieteellisen tutkimuksen ohjeet (Hevner ja muut, s.83, 2004) 

Ohje: Kuvaus: 

1 Artefaktin suunnittelu Hyödyllinen artefakti (rakennelma, malli, 

menetelmä, toteutus). 

2 Ongelman merkityksellisyys Tavoitteena kehittää teknologialähtöinen 

ratkaisu johonkin työelämän ongelmaan. 

3 Suunnittelun arviointi Artefaktin hyödyllisyys, laatu ja tehokkuus 

tulee demonstroida perusteellisesti käyt-

täen arviointimenetelmiä. 

4 Tutkimuksen tuoma lisäarvo Tutkimuksen tulee tuottaa jotain uutta, 

selkeää ja näyttöön perustuvaa. 

5 Tutkimuksen perusteellisuus Tutkimuksen tulee olla selkeä ja jäsen-

nelty. 

6 Suunnittelun tiedonhaku Vaikuttavan artefaktin löytämiseen on 

hyödynnettävä keinoja, joilla päästään ha-

luttuun lopputulokseen toimintaympä-

ristö huomioiden. 

7 Tutkimuksen esittäminen Tutkimus tulee esittää ymmärrettävästi 

teknisellä ja hallinnollisella tasolla. 

 



35 

3.2 Suunnittelutieteellisen tutkimuksen prosessi 

Käytetyin suunnittelutieteen tutkimuksen prosessimalli on Peffersin ja muiden (2007) 

luoma DSRM. Prosessiin kuuluu kuusi vaihetta: Ongelman tunnistaminen, tavoitteen 

määrittely, suunnittelu ja kehitys, demonstraatio, arviointi ja kommunikointi. (Brocke ja 

muut, s.4-5, 2020; Peffers ja muut, s.54, 2007) 

 

Ensimmäisessä vaiheessa määritellään tutkimusongelma ja motivoidaan kohdeyleisöä. 

Vaiheessa perustellaan ratkaisun tärkeyttä ja sen tuomaa lisäarvoa toimintaan. Ratkai-

sun tuoma perusteltu lisäarvo motivoi sekä tutkijaa, että kohdeyleisöä. Tässä vaiheessa 

tutkimusta tutkijan täytyy perehtyä ongelman tilaan ja sen ratkaisun tärkeyteen. (Brocke 

ja muut, 2020) 

 

Toisessa vaiheessa määritellään tavoitteet ratkaisulle. Tavoitteet voidaan päätellä ongel-

man laadusta ja mitä ratkaisuja on mahdollista tehdä olemassa olevan tiedon perusteella. 

Tavoitteet voivat olla kvalitatiivisia tai kvantitatiivisia. Ratkaisun tavoitteet tulee olla pää-

telty ongelman yksityskohdista. (Brocke ja muut, s.4-5 2020)  

Kolmannessa vaiheessa tapahtuu varsinainen suunnittelu ja kehitys. Vaiheessa luodaan 

artefakti, joka voi olla mikä tahansa objekti, mihin tutkimusta on hyödynnetty. Tässä vai-

heessa kuvataan artefaktin toivotut ominaisuudet ja arkkitehtuuri sekä lopuksi luodaan 

itse artefakti. (Brocke ja muut, s.4-5, 2020) 

 

Neljänteen vaiheeseen kuuluu ratkaisun demonstrointi. Vaiheessa suoritetaan artefaktin 

hyödyllisyyden testaaminen tutkimusongelman ratkaisemisessa. Demonstrointi voi olla 

artefaktin kokeilua, simuloimista, tapaus tutkimuksen tekemistä, todistamista tai jotain 

muuta, mikä todistaa artefaktin ratkaisevan ongelman. 

 

Viidennessä vaiheessa artefakti arvioidaan ja kuinka hyvin se ratkaisee asetetun ole-

massa olevan tutkimusongelman. Arvioinnissa tulee ilmi, kuinka hyvin tavoitteet saavu-

tetaan niiden ympäristössä. Artefaktille asetettuja tavoitteita verrataan tehtyihin tutki-

muksen tuloksiin. Arvioinnin perusteella tutkijat päättävät onko tavoitteet saavutettu 



36 

riittävällä tasolla. Jos tavoitteet jäävät asetetuista, palataan takaisin vaiheeseen kolme ja 

yritetään saavuttaa toivottu lopputulos, jotta voidaan siirtyä vaiheeseen kuusi. (Brocke 

ja muut, s.4-5, 2020) 

 

Kuudennessa vaiheessa artefakti ja sen saavuttamat tulokset julkaistaan sidosryhmille. 

Kommunikointitapa riippuu hyvin paljon kohdeyleisöstä. Tärkeää on tuoda esille kaikki 

ongelman näkökulmat esille. (Brocke ja muut, s.4-5, 2020) Alla kuvio DSRM- prosessista. 

 

 

Kuvio 7 DSRM Prosessi (Peffers ja muut, s.54, 2007) Muokattu ja suomennettu 

 

Tämän tutkielman ongelma tunnistettiin valtakunnallisesti tunnetun terveydenhuollon 

tietojärjestelmähankinnan käyttöönoton epäonnistumiseen. Kirjoittaja halusi luoda pro-



37 

sessimallin hankintaan, joka vähentäisi käyttöönoton ja tuotantovaiheen käytettävyys-

ongelmia. Kuviossa 8 kuvataan tutkielman eteneminen, joka noudattaa Peffersin ja mui-

den (2007) kehittämää tieteellisen tutkimusmenetelmän prosessia. 

 

Artefaktin eli prosessimallin suunnittelu ja rakentaminen aloitettiin tietoperustan kerää-

misellä ja prosessimallin käyttöympäristöön tutustumisella. Tietoperustaa kasvatettiin 

kirjallisuuteen ja tutkimuksiin tutustumisella, jonka jälkeen haluttiin muodostaa kuva 

suurimmista ongelmaan vaikuttavista tekijöistä loppukäyttäjäkyselyn avulla. Loppukäyt-

täjäkyselyn tarkoituksena oli lisätä ymmärrystä ongelman ympäristöstä ja lisätä kirjoitta-

jan tietoperustaa aiheen ympärillä. Loppukäyttäjiltä kerätyn aineiston perusteella luotiin 

teemat asiantuntijahaastatteluille. Prosessimallista luotiin ensimmäinen vedos haastat-

teluiden perusteella, jonka jälkeen se arvioitettiin hankinta-asiantuntijoilla ja palattiin 

tietoperustan laajentamiseen. Toinen vedos suunniteltiin ja rakennettiin arvioinnin pe-

rusteella ja tietoperustan laajentamisen avulla, jonka jälkeen palattiin arviointiin ja siir-

ryttiin eteenpäin prosessissa kommunikointiin. 

 



38 

 

Kuvio 8 Tutkielman eteneminen 

 

Hevnerin ja muiden (2008) luoman suunnittelutieteellisen tutkimuksen ohjeen mukaan 

kommunikointi tulee esittää tavalla, jotta ratkaisu on ymmärrettävä hallinnollisella ja tek-

nisellä organisaation tasolla. Tietoperustaa laajennettiin kommunikoinnin osalta, jotta 

tutkielma tulisi esitettyä ohjeiden mukaisesti. 

 

3.3 Kysely 

Kvantitatiivinen tutkimus eli tilastollinen tutkimus selvittää lukumääriin ja prosentti-

osuuksiin liittyviä kysymyksiä. Se vastaa kysymyksiin, mikä, missä, paljonko ja kuinka 

usein. Tilastollisessa tutkimuksessa kyselylomakkeet ovat yleensä standardoituja. Tutki-

muksessa asiat kuvataan numeeristen suureiden avulla ja tuloksia havainnollistetaan 

taulukoin ja kuvioin. Tilastollisella tutkimuksella voidaan myös selvittää asioiden välisiä 

riippuvaisuuksia tai ilmiöiden muutoksia. Kvantitatiivisella tutkimuksella ei yleensä saada 

selville asioiden syitä, mutta voidaan hyvin kartoittaa nykytilanne ja hyödyntää sitä täy-

dentämään laadullista eli kvalitatiivista tutkimusta. (Heikkilä, s.15, 2014) 



39 

 

Tässä tutkielmassa kyselyn tarkoitus oli juuri Heikkilän (2014) mukainen nykytilankartoit-

taminen. Kysely haluttiin kohdentaa terveyden- ja sosiaalihuollon ammattilaisille, jotka 

ovat olleet ohjelmistohankinnassa loppukäyttäjäroolissa mukana. Kyselyn avulla halut-

tiin selvittää mihin asioihin tulisi haastatteluissa keskittyä, jotta kehitettävä prosessimalli 

palvelisi parhaiten käytännössä ja käytettävyys ongelmat ohjelmistohankinnoissa saatai-

siin vähenemään. 

 

3.4 Teemahaastattelu 

Teemahaastattelu on tapa kerätä laadullista tietoa tutkimusta varten. Haastattelun tar-

koituksena on saada tietoa mitä haastateltava ajattelee kyseisestä asiasta, johon kysy-

mykset viittaavat. Haastattelu ei ole yksipuolinen, vaan parhaiten se toimii vuoropuhe-

luna ja on erittäin yleinen tiedonkeruumenetelmä. Teemahaastattelussa aihepiiri on en-

nalta määrätty, mutta sen ominaisuksiin kuuluu kysymysten epätarkka muotoilu ja jär-

jestys. (Heikkilä, 2014; Valli, 2018) 

 

Haastateltavan tulee tuntea haastattelun aihepiiri, koska hänen tulee osata keskustella 

siitä. Aihepiirin tunteminen helpottaa kysymyksien laadintaa, mutta täytyy varmistua, 

ettei kysymyksiä ole liikaa. Haastattelija johtaa koko haastattelun ja ohjaa tarvittaessa 

takaisin aiheeseen. Haastattelussa tulisi esittää selkeitä ja selkokielisiä kysymyksiä, jotta 

tulee ymmärretyksi oikein. Haastattelijan perusominaisuuksiin tulee kuulua tietty ute-

liaisuus erilaisia asioita kohtaan ja hänen täytyy pystyä havainnoimaan ihmisten kehon-

kieltä sekä sanojen painotuksia. Haastattelijan täytyy myös tiedostaa, että hänen oma 

käytös vaikuttaa suoraan haastateltavaan ja tulisi käyttäytyä mahdollisimman neutraa-

listi koko haastattelun ajan. (Hirsjärvi & Hurme, s.68, 2008) 

 

Aineistonkeruumenetelmänä haastattelu on tietoisuuden ja ajattelun sisältöihin kohdis-

tuva ja sen tavoitteena on kerätä aineisto, jonka perusteella voidaan tehdä päätelmiä 

tutkittavasta ilmiöstä. Haastatteluiden avulla kerätty aineisto on haastateltujen henkilöi-

den omakohtainen tulkinta asioista, tapahtumista ja ilmiöistä. Haastatteluiden analyysi 



40 

perustuu yleensä tutkimusta suorittavan henkilön omiin tulkintoihin aineistosta ja ei si-

ten välttämättä aina kuvaa autenttisesti haastateltujen kuvaa tutkimuksen aiheesta. 

(Puusa ja muut, 2020) 

 

Tämän tutkielman teemahaastatteluiden haastateltavat kirjoittaja valikoi hankintakoke-

muksen määrän perusteella ja kokemuksella julkisista hankinnoista. Hankintakokemusta 

kolmella haastateltavalla oli yhteensä lähes 50 vuotta. Jokainen haastateltava oli eri han-

kintaorganisaation jäsen ja he toimivat erilaisissa tehtävissä. Yksi haastateltavista oli han-

kintajohtaja, toinen julkisten hankintojen erityisasiantuntija ja kolmas oli johtava hankin-

takonsultti. Haastatteluiden avulla pyrittiin saamaan selville loppukäyttäjän rooli ja osal-

listamisen taso tällä hetkellä julkisessa hankintaprosessissa, millainen viestintä sidosryh-

mien välillä on ja kolmanneksi, minkälainen prosessimalli tukee parhaiten hankintaor-

ganisaatiota. 



41 

4 Tulokset 

Empiirinen aineisto kerättiin kahdessa osassa. Ensimmäisessä osassa tehtiin kysely (liite 

1) loppukäyttäjille, minkä tulosten perusteella muodostui haastattelukysymysten teemat. 

Kysely kohdennettiin sosiaali- ja terveydenhuollon ammattilaisille, jotka ovat olleet han-

kintaprosessissa mukana loppukäyttäjän roolissa. Kysely julkaistiin kirjoittajan omalla so-

siaalisen median alustalla ja lisäksi lähetettiin sähköisesti jokaisen hyvinvointialueen kir-

jaamoon levitettäväksi eteenpäin. Kyselyyn vastasi 4 henkilöä. 

 

Aineistonkeruun toisessa vaiheessa suoritettiin 45 minuutin teemahaastattelut. Haastat-

telussa oli kolme pääteemaa: loppukäyttäjä hankintaprosessissa, viestintä hankintapro-

sessissa ja artefaktin hyödyllisyys. Teemahaastattelut suoritettiin kolmelle hankintaan 

erikoistuneelle ammattilaiselle, joilla oli kokemusta sosiaali- tai terveydenhuollon ICT- 

hankinnoista ja niihin liittyvistä prosesseista. Asiantuntijoihin oltiin yhteydessä sähkö-

postitse ja teemahaastattelut suoritettiin videoyhteyden avulla, koska etätyöskentely on 

nykyään monille arkipäivää. Haastattelutilanteet nauhoitettiin.  

 

Haastatteluiden jälkeen muodostui ensimmäinen vedos prosessimallista, jonka jälkeen 

haastateltavat saivat kommentoida ja esittää kehitysehdotuksia artefaktin parantami-

seen. Kommentit ja parannusehdotukset kerättiin sähköpostitse, koska työpajojen jär-

jestäminen ei aikataulusyistä onnistunut. Lopullinen prosessimalli muodostui ensimmäi-

sen kommentointikierroksen jälkeen, jonka jälkeen se arvioitiin. 

 

4.1 Kysely loppukäyttäjille 

Kyselyn tavoitteena oli kartoittaa loppukäyttäjien kokemuksia ja tietämystä hankintapro-

sessista. Vastausmäärän ollessa neljä henkilöä, ei kovinkaan luotettavaa nykytilan kartoi-

tusta saatu tehtyä, mutta tulokset tukevat osittain teemahaastatteluiden tuloksia. Kyse-

lyssä oli 13 kysymystä, jotka käsittelivät käytettävyyttä, viestintää ja hankintaprosessia. 

Puolet vastanneista työskenteli alle 50 hengen organisaatiossa ja loput vastanneista yli 

250 henkilön organisaatiossa.  



42 

Vastanneiden digitaaliset taidot olivat hyvällä tasolla. Vastanneista puolet arvioivat pär-

jäävänsä perehdytyksellä ja loput olivat valmiita neuvomaan muita lyhyen perehdytyk-

sen jälkeen. Jokainen vastanneista piti käytettävyyttä merkittävänä asiana hankintapää-

töstä tehdessä. 

 

Vastanneista neljäsosa tiesi organisaatiossaan olevan kuvattu hankintaprosessi, mutta 

merkittävää on, että loput eivät tienneet tai vastasivat prosessikuvauksen puuttuvan ko-

konaan organisaation dokumentoinneista. Puolet kuitenkin vastasivat tuntevansa orga-

nisaationsa hankintaprosessin hyvin. Vain neljäsosa ei tuntenut prosessia ollenkaan.  

 

Puolet vastanneista totesi, ettei hankinnasta tehty missään vaiheessa kyselyitä ja loput 

kertoivat vastanneensa useampaan kyselyyn prosessin aikana. Kyselyitä saaneet loppu-

käyttäjät olivat hankintaprosessissa alusta alkaen ja toinen puolikas toimittajavalinnan 

jälkeen tai vasta perehdytyksessä. Merkittävää on, että kolme neljäsosaa vastanneista 

koki päässeensä vaikuttamaan lopputulokseen ja siihen oli varattu riittävästi aikaa. 

 

Hankintaprosessin viestintään oli tyytyväisiä puolet, tyytymättömiä neljäsosa ja loput ei-

vät osanneet sanoa. Tyytyväisimpiä olivat loppukäyttäjät, jotka kertoivat viestinnän ta-

pahtuneen yhdellä kanavalla, monen kanavan sijaan. Tyytyväisyys laski, kun kanavia oli 

käytössä kolme tai enemmän.  

 

Vastaajat olivat tyytyväisiä ohjelmistohankintoihin, joihin oli varattu riittävästi aikaa. Tyy-

tyväisyyteen vaikutti myös laajat keskustelut loppukäyttäjien kanssa ja ”riittävä esityö 

ennen hankintaa”. Tyytymättömyys johtui viestinnällisistä ongelmista ja ettei ohjelmisto 

lopulta tarjonnutkaan haluttua lopputulosta.  

 

4.2 Haastattelut 

Loppukäyttäjille suunnatun kyselyn perusteella muodostui asiantuntijahaastatteluihin 

teemat. Haastatteluiden tavoitteena oli kartoittaa loppukäyttäjän rooli hankintaproses-



43 

sissa, viestintä hankintaprosessissa ja loppukäyttäjän osallistavan prosessimallin hyödyl-

lisyys. Haastattelut suoritettiin kolmelle hankinta-alan asiantuntijalle, joilla on useam-

man vuoden kokemus julkisista hankinnoista. Haastateltavat halusivat pysyä anonyy-

meinä, joten tuloksia käsitellään henkilöille annetuilla kirjaimilla, A, B, C. 

 

Haastateltavien mukaan loppukäyttäjien digitaalinen tietotaito on merkittävässä osassa 

heidän osallistamiseensa ohjelmistohankinnoissa tällä hetkellä. Ainoastaan valveutu-

neet käyttäjät osasivat vaatia koekäyttöjä itse ja tuottaa järkeviä vaatimuksia hankitta-

valle järjestelmälle. Loppukäyttäjien osallistaminen valmisohjelmistoissa oli merkittä-

västi laajempaa kuin räätälöidyissä, koska käytettävyyttä valmisratkaisuissa voidaan tes-

tata ja pisteyttää. Räätälöityjen ohjelmistojen kohdalla koettiin hankaluuksia ja yhden 

haastateltavan mukaan ”A: räätälöidyissä ohjelmistoissa ostetaan niin sanottu sika sä-

kissä”, koska mitään konkreettista ei olla vielä hankintavaiheessa tuotettu sen tuomien 

lisäkustannusten takia. Erilaisista hankinnoista todettiin: 

 

”A: Jos me puhutaan jostain apotista, jossa on käytössä erittäin iso kasa rahaa, niin niis-

sähän sä voit vaatia aika paljon siltä kilpailutusprosessilta. Sä voit sitten jo vaatia jotain 

vedoksia, mutta sitten jos sanotaan että ei ole ihan sitten satoja miljoonia, niin sitä pitää 

pohtia, että kuinka paljon sä vaadit, niinku niiltä tarjoajilta itse kilpailutusvaiheessa sel-

laista tätä kisaa varten tehtyä työtä, mikä menee sitten hukkaan, jos niitä ei tule valittua. 

Kun yleensä vaan yks voi voittaa ja kerätä sen potin.” 

 

Haastatteluissa korostui jokaisen kohdalla tarpeellisuus esityön tekemiselle riittävän kat-

tavasti, koska esityön perusteella on helpompi tehdä tarjouspyyntö. Hyvin usein törmä-

tään hankintaorganisaatiossa tilanteeseen, jossa esityö on tehty todella huonosti, eikä 

asiaan ole perehdytty lainkaan. Ongelmana epärealistisia odotuksia hankinnalta tai sit-

ten käyttäjän osallistaminen hankintaan kirjataan dokumentteihin: ”A: tulee olla käyttä-

jäystävällinen”. Haastatteluissa tuli myös esille tietohallinnon dominointi ohjelmistohan-



44 

kinnoissa, mikä saattaa johtaa tilanteeseen, jossa tietohallinto ei välttämättä hanki kaik-

kea sitä informaatiota mitä loppukäyttäjiltä voitaisiin saada. Yksi haastateltava totesi pro-

sessista näin:  

 

”B: Paljon sellaisia asioita suunnittelun ja valmistelun kohdalla, jotka hyvin tehtäessä ra-

jatuilla arvoilla helpottaa tarjouspyynnön laatimista, mutta julkisella puolella ongel-

mana, että halutaan kaikki maailman herkut, eikä mietitä yhtään. Mennään ikään kuin 

suoraan tarjouspyynnön laatimiseen. Sitten tajutaan tarjousvertailussa, ettei ole saatu 

yhtään sellaista tarjousta, jossa päätöstenteko olisi järkevää.” 

 

Lainsäädäntö ohjaa hyvin pitkälle julkista hankintaprosessia, mutta esityötä ei ole sään-

nelty. Haastateltavien mukaan loppukäyttäjiä tulee hyödyntää monipuolisesti valmiste-

luvaiheessa. Loppukäyttäjiltä saadaan tärkeää tietoa tarjouspyyntövaiheeseen tavoittei-

den ja rajoitteiden asettamiseen. Tällä hetkellä loppukäyttäjiä hyödynnetään hankinta-

vaiheessa vähän. Yleensä vuoropuhelu alkaa vasta käyttöönottovaiheessa ja kehityk-

sessä. Hankinnoissa käytetään paljon asiantuntija-arvioita ja johtajat luottavat heidän 

ehdotuksiinsa sokeasti. Haastatteluissa selvisi, että johtajat hyvin yleensä olettavat tie-

tävänsä, mitä loppukäyttäjät haluavat ja harvoin kysytään kokemuksia. Hankintaorgani-

saatio nähdään myös usein pelkkänä ”A, B, C: suorittavana koneistona, joka tuntee pro-

sessin”, jolloin myyntipuheiden sopeuttaminen käytäntöön saattaa hankintaosaamisen 

puuttuessa johtaa ongelmiin. Haastattelussa tuli myös esille, että allekirjoitusvaiheessa 

sopimuksista saattaa löytyä kohta, ”A: tämä sopimus on kaikki mitä asiasta sovitaan ja 

kaikki aikaisemmin tuotettu materiaali unohdetaan”. Tällainen kohta sopimuksessa 

unohtaa esityön kokonaan, jolloin loppukäyttäjien kanssa tuotettu informaatio jää huo-

mioimatta lopullisessa toimituksessa.  

 

Haastateltavat mainitsivat, että kaikki loppukäyttäjien osallistamiset tulisi olla ohjattuja. 

Ohjatusti loppukäyttäjät pystyvät tuottamaan tarpeellisia vaatimuksia järjestelmille, 

koska rajoitteet ovat tiedossa. Myös johdolle tulisi viestiä hankinnan rajoitteet, jotta han-



45 

kinta olisi mahdollisimman realistinen ja vaatimusten mukainen. Prosessin selkeä kuvaa-

minen ja sen esilletuominen nähtiin puutteellisena joissain organisaatioissa, joka heiken-

tää loppukäyttäjän tietoisuutta. Haastatteluiden perusteella viestintä oli kovin yksipuo-

lista tiedottamista. Yksi haastateltavista totesi: 

 

”A: Viestintä yleensä yksipuolista ja tiedottamista liian vähän. Tiedottamista ei voi olla 

koskaan liian paljon, tiedottamista on myös se, ettei ole mitään tiedotettavaa. Tiedotta-

minen hälventää loppukäyttäjien epävarmuutta ja pitää heidät kiinni siinä asiassa” 

 

Loppukäyttäjille aloitetaan viestimään muutoksesta yleensä hyvissä ajoin, jotta muutos-

vastarintaa saadaan hälvennettyä. Yksi haastateltava kuvaili tiedottamista näin: 

 

”B: Aika useinhan siis on se, että infotaan, että ollaan hankkimassa järjestelmä x syystä 

y. Eli vähän valmistellaan sitä pohjaa, että meidän järjestelmä tulee vaihtumaan ja mistä 

syystä se esimerkiksi johtuu. Aina kun vaihdetaan järjestelmästä toiseen niin siinä on 

niinku… Miten sen nyt sanoisi, muutosvastarintaa niin, sen niin sanottu murtaminen 

yleensä aloitetaan sillä, että on ennakkoviestintää. Siitä asiasta esimerkiksi se, että mitä 

tulee tapahtumaan, ettei tule yllätyksenä ja mistä syystä” 

 

Haastatteluista kävi ilmi, että muutoksesta loppukäyttäjät ovat hyvin vähän kiinnostu-

neita hankintavaiheessa. Hankinta alkaa vasta kiinnostaa siinä vaiheessa, kun se otetaan 

käyttöön ja käytössä tulee ongelmia. ”B: Hankintavaiheessa harvoja yleensä kiinnostaa 

koko projekti, mutta sitten kun hankinta on käyttöönotettu, niin valitusta alkaa tule-

maan.”. Kehitystyön merkittävyys hankinnoille koettiin tarpeelliseksi, mutta samalla ol-

tiin huolissaan sen kustannuksista. Hankinta tulisi nähdä kokonaisuutena, jossa otetaan 

huomioon sen koko elinkaari, eikä vain yhtä vaihetta. ”A, B, C: Hyvin usein käy, niin että 

hankintavaiheeseen ja käyttöönottovaiheeseen resursoidaan riittävästi porukkaa, mutta 

sitten unohdetaan kokonaan se ylläpito ja kehitys.”. 

 



46 

Haastatteluissa tuli ilmi, että ohjeistuksia ja parhaita käytäntöjä hankintoihin on ole-

massa ja niitä kehitetään jatkuvasti. Ongelmana ohjeistusten ja käytäntöjen olematon 

jalkauttaminen, jolloin niitä ei saada käyttöön tai huomioida ollenkaan. ”A: Yhtenäinen, 

käyttäjää osallistava hankintamalli olisi hyödyllinen ohjelmistohankinnoissa.”. 

 

4.3 Artefaktin kuvaus 

Artefakti toteutettiin JHS 152 suosituksen mukaisesti. Suositukseen kuuluu kolme doku-

menttia: Perustietolomake, prosessin toiminnot- lomake ja graafinen kuvaus prosessista. 

Prosessiin valittiin kolme toimijaa: Palveluorganisaatio, hankintaorganisaatio ja loppu-

käyttäjät. Haastatteluiden perusteella tunnistettiin seitsemän toimintokokonaisuutta, 

joita lähdettiin kuvaamaan graafisesti yhteen malliin. Kuviossa seitsemän on graafinen 

kuvaus hankintaprosessista. 

 

 

Kuvio 9 Käyttäjälähtöinen ohjelmistohankintamalli 

 

Artefaktin perustietolomake sisältää nimensä mukaisesti prosessin perustiedot. Perus-

tietolomakkeessa on 17 kohdan taulukko, josta selviää mihin tarkoitukseen prosessi on 



47 

kehitetty ja mitkä ovat sen tavoitteet. Taulukosta 5 selviää tarkemmat lisätiedot perus-

tietolomakkeen sisällöstä. 

 

Taulukko 7 Artefaktin perustietolomake esimerkki 

1 Prosessin nimi Ohjelmistohankinta 

2 Kuvauksen laatija ja laa-

dintapäivämäärä 

Wille Asikainen 18.3.2023 

3 Kuvauksen hyväksyjä ja 

hyväksymispäivämäärä 

 

4 Versionumero 1.1 

5 Prosessin tarkoitus Loppukäyttäjälähtöinen ohjelmistohankinta 

6 Prosessin omistaja Wille Asikainen 

7 Prosessin mallintajat ja 

mallinnuspäivämäärä  

Wille Asikainen 26.3.2023 

8 Prosessin lähtötilanne Esiintyy tarve ohjelmistolle 

9 Prosessin lopputilanne Lopullinen tarjouspyyntö 

10 Prosessin asiakkaat Tilaaja 

11 Prosessin sidosryhmät Tilaajaorganisaatio, hankintaorganisaatio, loppukäyt-

täjät 

12 Prosessin asiakkaiden 

tarpeet ja vaatimukset  

Ohjelmistohankinta, joka vastaa loppukäyttäjien 

käytettävyysvaatimuksia 

13 Prosessin menes-

tystekijät  

Loppukäyttäjien osallistaminen määrittelyyn ohjatusti. 

Hankinnan selkeät tavoitteet ja rajoitteet. 

14 Prosessin mittarit Käytettävyys 

15 Prosessin keskeiset re-

surssit ja muut volyymi-

tiedot 

Loppukäyttäjät 

16 Prosessin ohjaus ja 

kehittämismenettely 

Tilaajaorganisaatio, hankintaorganisaatio 



48 

17 Rajapinnat muihin 

prosesseihin 

ICT hankinta 

 

Artefaktin kolmannessa lomakkeessa kuvataan toiminnot. Tästä taulukosta selviää tar-

kemmin toimintojen tehtävät, toimijat sekä tulostila ja suoritteet. Jokaisen toiminnon 

tuotos tulee olla seuraavan toiminnon syöte. Taulukossa 7 kuvataan loppukäyttäjälähtöi-

sen ohjelmistohankinnan toiminnot yksityiskohtaisesti. 

 

Taulukko 8 Artefaktin toiminnot 

Toiminnot Tehtävät Toimijat Tulostila/suoritteet 

Alku Tarpeen kirjaami-

nen ja viestintä si-

dosryhmille 

Palveluorganisaatio Viestintäsuunni-

telma 

Valmistelu Palveluorganisaa-

tion tukeminen 

prosessissa 

Hankintaorganisaa-

tio 

Prosessikuvaus 

Suunnittelu Aikataulu, tavoit-

teet, rajoitteet, 

markkinaselvitys, 

loppukäyttäjän si-

touttaminen han-

kintaan 

Palveluorganisaa-

tio, hankintaorgani-

saatio, loppukäyttä-

jät 

Suunnitelma 

Määrittely Vaatimusmäärit-

tely, arvioinnin 

suunnittelu, päätös 

valmisohjelmiston 

ja räätälöidyn oh-

jelmiston välillä 

Palveluorganisaa-

tio, hankintaorgani-

saatio, loppukäyttä-

jät 

Vaatimusmäärittely 



49 

Testaus ja arviointi Käytettävyyden ar-

viointi loppukäyttä-

jien kanssa 

Palveluorganisaa-

tio, loppukäyttäjät 

Käytettävyys 

Käyttönotto- ja tuo-

tantovaiheen resur-

sointi 

Tavoitteiden, rajoit-

teiden ja vaatimus-

ten koonti tarjous-

pyyntöä varten. 

Käyttöönoton ja 

tuotannon suunnit-

telun aloittaminen 

Palveluorganisaa-

tio, hankintaorgani-

saatio, loppukäyttä-

jät 

Kooste 

Menettelyn valinta Palveluorganisaa-

tion tukeminen 

prosessissa 

Hankintaorganisaa-

tio, palveluorgani-

saatio 

Menettelytapa 

Tarjouspyynnön 

laatiminen ja ilmoi-

tus 

Palveluorganisaa-

tion tukeminen 

prosessissa 

Hankintaorganisaa-

tio, palveluorgani-

saatio 

Lopullinen tarjous-

pyyntö ja ilmoitus 

 

Prosessi alkaa hankintatarpeen esiintymisestä, jolloin se kirjataan palveluorganisaation 

toimesta ja aloitetaan viestintäsuunnitelman tekeminen. Samaan aikaan hankintaorgani-

saatio valmistelee hankintaa omalta osaltaan ja tuo hankintaprosessia esille sidosryh-

mille. Suunnitteluvaiheeseen osallistuu kaikki hankintaprosessin toimintaorganisaatiot. 

Tässä vaiheessa määritellään prosessin aikataulu, tavoitteet ja rajoitteet. Suunnitteluvai-

heen tavoitteena on tutustua markkinoihin mahdollisimman kattavasti ja valita loppu-

käyttäjät, jotka sitoutuvat hankintaan. Loppukäyttäjät pyritään valitsemaan niin, että ne 

edustaisivat mahdollisimman kattavasti koko loppukäyttäjäjoukkoa. 

Määrittelyvaiheessa suoritetaan hankittavan ohjelmiston vaatimusmäärittely mahdolli-

simman kattavasti loppukäyttäjien kanssa ja tehdään päätös valmisohjelmiston ja räätä-

löidyn ohjelmiston välillä. Mikäli päädytään valmisohjelmistoon, niin voidaan suunnitella 

käytettävyysarviointia testaus ja arviointivaihetta varten. Käyttöönotto- ja tuotantovai-



50 

heen resursointi vaiheen tavoitteena on tehdä kooste siihen mennessä kerätystä mate-

riaalista ja esitellä se kaikille sidosryhmille, jolla varmistetaan oikeiden vaatimusten pää-

tyminen lopulliselle tarjouspyynnölle. Tähän toimintoon osallistuvat kaikki sidosryhmät 

ja koosteen jälkeen aloitetaan käyttöönotto ja tuotantovaiheen resursoinnin suunnittelu. 

Kun ohjelmistohankinnan esityö on tehty, niin hankintaorganisaatio päättää palveluor-

ganisaation kanssa hankintamenettelyn ja suorittaa lopullisen tarjouspyynnön laatimi-

sen ja hankintailmoituksen tekemisen. 

 

4.4 Artefaktin arviointi 

Artefaktin arviointi pohjautui Hevnerin ja muiden (2004) laatiman suunnittelutieteelli-

sen tutkimuksen ohjeeseen. Taulukossa 7 arvioidaan artefaktin suunnittelua, merkityk-

sellisyyttä ja menetelmän toteutumista tutkielman aikana. Artefaktia ei päästy testaa-

maan käytännössä, mutta se antaa hyvät lähtökohdat jatkokehittämiselle. 

 

Taulukko 9 Artefaktin arviointi 

Kohde: Kuvaus: 

1 Artefaktin suunnittelu Loppukäyttäjälähtöinen prosessimalli ohjelmisto-

hankintaan, joka perustuu tutkittuun tietoon ja 

luotettaviin lähteisiin. 

2 Ongelman merkityksellisyys Ohjelmistohankintojen käyttäjätyytyväisyys on tut-

kimusten mukaan todella huonolla tasolla. Onnis-

tuneet hankinnat tehostavat julkisten varojen käyt-

töä. 

3 Suunnittelun arviointi Perehtyminen kirjallisuuteen ja empiirisen tiedon 

kerääminen sekä niiden monipuolinen hyödyntä-

minen artefaktin suunnittelussa. Loppukäyttäjien 

ja asiantuntijoiden näkökulmat huomioitu. 



51 

4 Tutkimuksen tuoma lisäarvo Selkeä ja yhdenmukainen prosessimalli ohjelmis-

tohankintaan, joka ottaa hankinnan kokonaisuu-

den huomioon. 

5 Tutkimuksen perusteellisuus Artefakti pohjautuu JHS 152 suosituksen mukai-

seen prosessikuvaamiseen, jota hyödynnetään jul-

kisella sektorilla yleisesti ja aineisto prosessimallin 

toteuttamiseen on kerätty luotettavista lähteistä.  

6 Suunnittelun tiedonhaku Teoria ja tutkimukset: 

- käytettävyys 

- käyttäjälähtöisyys 

- käyttäjälähtöinen suunnittelu 

- Julkinen hankintaprosessi ja sen kuvaami-

nen 

Empiirinen aineisto: 

- Loppukäyttäjäkysely 

- Hankinta-asiantuntijoiden haastattelu 

7 Tutkimuksen esittäminen Artefaktin esittäminen seminaarissa ja loppurapor-

tin julkaiseminen verkossa. 

 

Artefaktista tuli vaatimukset täyttävä kokonaisuus, joka saatiin aikaiseksi hyödyntämällä 

iteraatioita. Aineistonkeruun jälkeen tehtiin ensimmäinen vedos prosessista (1.0), joka 

lähetettiin haastatelluille sähköpostitse kommentointia varten. Versio 1.1 muodostui pa-

lautteen perusteella. Haastateltavat eivät arvioineet aikataulusyistä lopullista mallia, 

mutta jo ensimmäisen vedoksen perusteella todettiin artefaktin hyödyllisyys käytäntöön. 

Artefaktin kehitysvaiheessa kirjoittajan mielestä toteutui Hevnerin (2007) kuuvaamat 

suunnittelutieteellisen tutkimuksen syklit (kuvio 6): relevanssi, täsmällisyys ja suunnit-

telu. Kirjoittajan aiempi kokemus terveydenhuoltoalalta oli apuna relevanssisyklin ja täs-

mällisyyssyklin aikana.  



52 

5 Diskussio ja yhteenveto 

Tutkielman aiheena oli loppukäyttäjälähtöinen ohjelmistohankinta ja tutkielman oli tar-

koitus vastata kysymykseen: Miten loppukäyttäjät osallistetaan hankintavaiheeseen, 

jotta käytettävyysongelmia saadaan vähennettyä tulevaisuudessa? Tavoitteena oli luoda 

prosessimalli, joka auttaa hankintavastaavia onnistumaan työssään paremmin. Tut-

kielma lähti liikkeelle kuvion 8 hahmottamisella. Kuvio toimi kirjoittajan hypoteesina. Ku-

viossa kuvataan loppukäyttäjien osallistamisen vaikutuksia ohjelmistohankintaan ja min-

kälaisia kokonaisuuksia siihen liittyy. Hypoteesina oli: Käyttäjäkeskeinen ohjelmistohan-

kinta keskittyy käyttäjien osallistamiseen vaatimusmäärittelyyn, testaukseen, kehityk-

seen, kommunikointiin, arviointiin ja palautteeseen. Kaikki nämä komponentit paranta-

vat lopullisen hankinnan käytettävyyttä ja siten lisää loppukäyttäjien käyttäjätyytyväi-

syyttä. 

 

 

Kuvio 10 Loppukäyttäjän osallistamisen vaikutukset 

 



53 

Loppukäyttäjille suunnatun kyselyn perusteella viestintä ja esityön merkitys nousi mer-

kittävimpään rooliin ohjelmistohankinnan osalta. Hyvällä viestinnällä oli selvä yhteys 

käyttäjätyytyväisyyteen. Laajat keskustelut loppukäyttäjien kanssa, sopiva aikataulu ja 

perehtyminen hankintaan vaikuttivat positiivisesti hankinnan käytettävyyteen. 

 

Haastatteluiden perusteella hankinta-asiantuntijoiden mukaan viestinnässä oli paranta-

misen varaa. Merkittävimmiksi tekijöiksi lopullisen tarjouspyynnön laatimisen tuke-

miseksi koettiin tavoitteiden ja rajoitteiden asettaminen ennen loppukäyttäjien osallis-

tamista hankintaprosessiin, jotta loppukäyttäjiltä saataisiin tarpeellista informaatiota tu-

kemaan hankintaa käytettävyyden osalta. Toinen merkittävä tekijä oli hankinnan koko-

naisuuden hahmottaminen jo alussa, missä huomioidaan hankintavaiheen, käyttöönot-

tovaiheen ja tuotantovaiheen resursointi. Hankinnan esityön tulisi olla kattava ja osallis-

tettavien loppukäyttäjien tulisi edustaa mahdollisimman hyvin koko joukkoa. Tärkeänä 

mainittiin myös myyntipuheiden erottaminen käytännössä. Kuvion 7 mukainen proses-

simalli koettiin hyödylliseksi käytännössä ja siinä on huomioitu kaikki tutkielman aikana 

esille tulleet mahdollisuudet loppukäyttäjän osallistamiseen ja sitä kautta käytettävyy-

den parantamiseen. 

 

5.1 Tutkimuksen kontribuutio tieteelle 

Useat tutkimukset näyttävät sosiaali- ja terveydenhuollon ohjelmistohankintojen käytet-

tävyyden olevan heikolla tasolla. Esimerkiksi Martikaisen ja muiden (2018) tekemän tut-

kimuksen mukaan ohjelmistokehitykseen osallistuvien ammattihenkilöiden määrä olisi 

korkea, mutta tämän tutkielman loppukäyttäjät olivat hämmästyttävän passiivisia kyse-

lyyn vastaamisen kanssa. Loppukäyttäjäkysely jaettiin sähköisesti hyvinvointialueilla, 

mutta vastausprosentti jäi silti olemattomaksi. Ovatko käyttäjät passivoituneet käytettä-

vyysongelmien ympärillä? 

 

Kaipion ja muiden (2015) tekemän tutkimuksen mukaan Apotti- hankkeeseen osallistet-

tiin loppukäyttäjiä. Käytettävyystavoitteet hankkeelle perustettiin ISO standardin ja Niel-



54 

senin määritelmien mukaan. Vaatimusmäärittelyyn osallistui 400 sosiaali- ja terveyden-

huollon ammattihenkilöä. Tutkimuksessa ei kuitenkaan tullut esille tämän tutkielman 

osalta merkittävintä havaintoa: Hankinnan kokonaisuuden hahmottaminen. Käyttäjiä 

osallistetaan, mutta ei resursoida koko hankinnan elinkaarelle. Tämä tutkielma paikkaa 

osittain hankintatutkimuksen aukkoa käyttäjälähtöisyydestä ohjelmistohankinnoissa ja 

antaa erilaisen näkökulman hankintaprosessiin. 

 

5.2 Tutkimuksen kontribuutio käytäntöön 

Tutkielman tarkoituksena oli tuottaa prosessimalli hankintavastaavien tueksi tulevaisuu-

den ohjelmistohankintoihin. Haastateltavien mukaan yhtenäiselle prosessimallille oli tar-

vetta ja luotu prosessimalli sopii käytäntöön. Hankintaprosessi on kuvattu JHS 152 suo-

situksen mukaisesti, joten se on suoraan hyödynnettävissä julkisella sektorilla. 

 

Loppukäyttäjien tietoisuus hankintaprosessista lisää käyttäjätyytyväisyyttä ja prosessi-

malli toimii hyödyllisenä työkaluna muutosjohtamisessa. Selkeä ja avoin viestintä on yksi 

merkittävimmistä tekijöistä ohjelmistohankinnan onnistumiseen.  

 

5.3 Tutkimuksen rajoitteet 

Tutkielman merkittävin rajoite oli huono vastausprosentti loppukäyttäjille suunnattuun 

kyselyyn. Kirjoittajan arvio huonoon vastausprosenttiin on, että Ihmiset passivoituvat 

ongelman ympärillä, koska asialle ei oikeasti koskaan tehdä mitään. Loppukäyttäjille 

suunnattu kysely toimitettiin hyvinvointialueiden vastaamoihin ja jaettiin kirjoittajan 

omalla sosiaalisen median alustalla. Kyselyn olisi voinut vaihtaa loppukäyttäjien teema-

haastatteluiksi. 

 

Toinen merkittävä rajoite oli haastateltujen palautteiden kerääminen prosessimallista ai-

noastaan sähköisesti. Laadulliseen tutkimusmenetelmään kuuluu Hirsjärven ja Hurmeen 

(2008) mukaan vuoropuhelu haastateltavien kanssa, joten tässä tutkielmassa tuo vuoro-

puhelu ei toteutunut palautteen ja arvioinnin osalta täydellisesti. 



55 

 

5.4 Jatkotutkimusaiheet 

Ehdotan jatkotutkimusaiheeksi käytettävyystutkimuksen tekemistä tutkielman tulok-

sena syntyneen prosessimallin mukaisesti suoritetulle ohjelmistohankinnalle. Olisi myös 

kiinnostavaa tietää miten tuotettu prosessimalli jalkautetaan tehokkaasti toimintaympä-

ristöön hankintavastaavien tueksi.  

 

Julkisten varojen tehokas käyttö on yhteiskunnan tärkeimpiä tehtäviä, joten ICT hankin-

tojen vieminen eteenpäin käytettävyys edellä on erittäin tärkeää, mutta tutkimusta te-

hokkuuden lisääntymisestä tarvitaan enemmän. 

  



56 

Lähteet  

Barnum, C. M. (2011). Usability Testing Essentials : Ready, Set ... Test. Morgan Kaufmann. 

Brocke, J. vom., Havner, Alan., & Maedche, Alexander. (2020). Design Science Research. 

Cases. Springer International Publishing. 

Cajander, Å., Lárusdóttir, M. K., Lind, T., & Nauwerck, G. (2022). Walking in the jungle 

with a machete: ICT leaders’ perspectives on user-Centred systems design. Behav-

iour & Information Technology, 41(6), 1230–1244. 

https://doi.org/10.1080/0144929X.2020.1864776 

Deuff, Dominique., & Cosquer, Mathilde. (2013). User-Centered Agile Method. Wiley-

ISTE. 

Eskola, S., Kiviniemi, E., Krakau, T., & Ruohoniemi, E. (2017). Julkiset hankinnat. Alma 

Talent. 

Gulliksen, J., Göransson, B., Boivie, I., Blomkvist, S., Persson, J., & Cajander, Å. (2003). 

Key principles for user-centred systems design. Behaviour & Information Technol-

ogy, 22(6), 397–409. https://doi.org/10.1080/01449290310001624329 

Haukipuro, L., Väinämö, S., & Torvinen, H. (2016). End-user involvement enhancing inno-

vativeness in public procurement. evidence from a healthcare procurement. Jour-

nal of Innovation Management, 4(4), 98–121. https://doi.org/10.24840/2183-

0606_004.004_0007 

Heikkilä, T. (2014). Tilastollinen tutkimus. Edita. 

Hevner, A. R. (2007). A Three Cycle View of Design Science Research. Scandinavian Jour-

nal of Information Systems, 19(2), 4-. 

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information sys-

tems research. MIS Quarterly: Management Information Systems, 28(1), 75–105. 

https://doi.org/10.2307/25148625 

Hirsjärvi, Sirkka., & Hurme, Helena. (2008). Tutkimushaastattelu : teemahaastattelun 

teoria ja käytäntö. Gaudeamus. 

Hyysalo, S. (2009). Käyttäjä tuotekehityksessä. Taideteollisen Korkeakoulun Julkaisu B 97. 

https://aaltodoc.aalto.fi/bitstream/han-

dle/123456789/11826/isbn9789515583017.pdf?sequence=1&isAllowed=y 



57 

Iansiti, M. (2012). Government IT procurement Processes and Free Software. Public Con-

tract Law Journal, 41(2), 197–232. 

ISO 9241-11:2018(en), Ergonomics of human-system interaction — Part 11: Usability: 

Definitions and concepts. (n.d.). Retrieved February 3, 2023, from 

https://www.iso.org/obp/ui/#iso:std:iso:9241:-11:ed-2:v1:en 

JHS 152 Prosessien kuvaaminen | Suomidigi. (n.d.). Retrieved February 2, 2023, from 

https://www.suomidigi.fi/ohjeet-ja-tuki/jhs-suositukset/jhs-152-prosessien-

kuvaaminen 

Kaipio, J., Lääveri, T., Hyppönen, H., Vainiomäki, S., Reponen, J., Kushniruk, A., Borycki, 

E., & Vänskä, J. (2017). Usability problems do not heal by themselves: National sur-

vey on physicians’ experiences with EHRs in Finland. International Journal of Medi-

cal Informatics, 97, 266–281. https://doi.org/10.1016/J.IJMEDINF.2016.10.010 

Kaipio, J., Lääveri, T., Tyllinen, M., laitos, T., kaupunki, H., Tulehduskeskus ja Helsingin 

yliopisto, H., Johanna Kaipio, F., & ja käytettävyysasiantuntija, A. (2015). Menettely-

prosessi käytettävyys- ja loppukäyttäjänäkökulman integroimiseksi tietojärjestel-

mähankintaan: Tapaus Apotti. Finnish Journal of EHealth and EWelfare, 7(2–3), 

104–121. https://journal.fi/finjehew/article/view/50897 

Kaminski, J. (2020, December 21). Theory applied to informatics – Usability. Canadian 

Journal of Nursing Informatics. https://cjni.net/journal/?p=8442 

Kaplan, K. (2021, August 15). 10 Usability Heuristics Applied to Complex Applications. 

https://www.nngroup.com/articles/usability-heuristics-complex-applications/ 

Karinkanta, P., & Lahtinen, T. (2017). Julkiset hankinnat yrityksille käytännönläheisesti (1. 

painos). Kauppakamari. 

Koulu, R., Sankari, S., & Sormunen, S. (2022). Digitalisoituva julkishallinto: Käytettävyys 

kuuluu kaikille. Edilex, 36. www.migri.fi, 

Kyytsönen, M., Hyppönen, H., Koponen, S., Kinnunen, U.-M., Saranto, K., Kivekäs, E., Kai-

pio, J., Lääveri, T., Heponiemi, T., & Vehko, T. (2020). Information systems as sup-

porters of nurses’ work: experiences by system brand. Finnish Journal of EHealth 

and EWelfare, 12(3), 250–269. https://doi.org/10.23996/FJHW.95704 



58 

Laki julkisista hankinnoista ja… 1397/2016 - Ajantasainen lainsäädäntö - FINLEX ®. (n.d.). 

Retrieved May 8, 2023, from https://www.finlex.fi/fi/laki/ajantasa/2016/20161397 

Lantz, A., & Holmlid, S. (2010). Interaction design in procurement: the view of procurers 

and interaction designers. CoDesign, 6(1), 43–57. 

https://doi.org/10.1080/15710881003671890 

Lee, L., Williams, R., & Sheikh, A. (2016). How does joint procurement affect the design, 

customisation and usability of a hospital ePrescribing system? Health Informatics 

Journal, 22(4), 828–838. https://doi.org/10.1177/1460458215592915 

Martikainen, S., Kaipio, J., & Lääveri, T. (2020). End-user participation in health infor-

mation systems (HIS) development: Physicians’ and nurses’ experiences. Interna-

tional Journal of Medical Informatics, 137, 104117. https://doi.org/10.1016/J.IJME-

DINF.2020.104117 

Martikainen, S., Kotila, J., Kaipio, J., & Lääveri, T. (2018). Lääkärit ja hoitajat parempien 

tietojärjestelmien kehittämistyössä: kyvykkäät ja innokkaat käyttäjät  alihyödynnet-

tyinä. Finnish Journal of EHealth and EWelfare, 10(2–3), 236–250–236–250. 

https://doi.org/10.23996/FJHW.70097 

Moe, C. E. (2014). Research on public procurement of information systems: The need for 

a process approach. Communications of the Association for Information Systems, 

34(1), 1319–1335. https://doi.org/10.17705/1cais.03478 

Moe, C. E., & Päivärinta, T. (2013). Challenges In Information Systems Procurement in the 

Public Sector. Electronic Journal of E-Government, 11(2), 308-. 

Mooij, M. de., & Lammi, Miia. (2005). Kompassina asiakas : näkemyksiä ja kokemuksia 

käyttäjälähtöisyydestä. Teknologiainfo Teknova. 

Nielsen, J. (2020, November 15). 10 Usability Heuristics for User Interface Design. Nielsen 

Norman Group. https://www.nngroup.com/articles/ten-usability-heuristics/ 

Ovaska, S., Aula, A., & Majaranta, P. (2005). Käytettävyystutkimuksen menetelmät. 

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science 

research methodology for information systems research. Journal of Management 

Information Systems, 24(3), 45–77. https://doi.org/10.2753/MIS0742-1222240302 



59 

Pollock, N., & Williams, R. (2007). Technology choice and its performance: Towards a 

sociology of software package procurement. Information and Organization, 17(3), 

131–161. https://doi.org/10.1016/j.infoandorg.2007.05.001 

Puusa, A., Juuti, P., & Aaltio, I. (2020). Laadullisen tutkimuksen näkökulmat ja menetel-

mät. Gaudeamus. 

Riihimäki, E., & Pekkola, S. (2021). Public buyer’s concerns influencing the early phases 

of information system acquisition. Government Information Quarterly, 38(4), 

101595-. https://doi.org/10.1016/j.giq.2021.101595 

Scheuer, S., Ferner, P., Prinzellner, Y., & Aumayr, G. (2022). Collection of End User Re-

quirements and Use Cases during a Pandemic—Towards a Framework for 

Applied Research Projects. Information 2022, Vol. 13, Page 255, 13(5), 255. 

https://doi.org/10.3390/INFO13050255 

Tadelis, S. (2012). Public procurement design: Lessons from the private sector. Interna-

tional Journal of Industrial Organization, 30(3), 297–302. 

https://doi.org/10.1016/j.ijindorg.2012.02.002 

Torvinen, H., & Haukipuro, L. (2018). New roles for end-users in innovative public pro-

curement: case study on user engaging property procurement. Public Management 

Review, 20(10), 1444–1464. https://doi.org/10.1080/14719037.2017.1400581 

Torvinen, H., & Ulkuniemi, P. (2016). End-user engagement within innovative public pro-

curement practices: A case study on public–private partnership procurement. In-

dustrial Marketing Management, 58, 58–68. https://doi.org/10.1016/J.INDMAR-

MAN.2016.05.015 

Ukkonen, C. (2019, May 22). Kehnot tietojärjestelmät stressaavat lääkäreitä ja hoitajia - 

Tiedon silta. Työhyvinvointi. https://www.tsr.fi/tiedon-silta/kehnot-tietojarjestel-

mat-stressaavat-laakareita-ja-hoita-

jia/?_ga=2.188935019.1549714476.1569303675-575867404.1569303675 

Valli, R. (2018). Ikkunoita tutkimusmetodeihin. 1, Metodin valinta ja aineistonkeruu : vi-

rikkeitä aloittelevalle tutkijalle. In R. Valli & E. Aarnos (Eds.), Ikkunoita tutkimusme-

todeihin 1, Metodin valinta ja aineistonkeruu: virikkeitä aloittelevalle tutkijalle (Vol. 



60 

5). PS-kustannus. https://oula.finna.fi/Record/oy_electro-

nic_oy.