Apotin kaksi virhettä: Vastine saamiini palautteesiin

Apotin kehityksessä oli ollut mukana käyttäjiä, käytettävyysammattilaisia, oli määritetty käytettävyysvaatimuksia sekä oli tehty käytettävyysvertailuja ja -arviointeja. Apotin - kuten minkään muunkaan järjestelmän - käytettävyyden onnistumisen arviointiin tämän tasoiset tiedot eivät kuitenkaan riitä. Onnistumisen arviointiin tarvitaan tarkempaa tietoa käytetyistä käytettävyysmittareista, tavoitetasoista, ja siitä, miten nämä oli johdettu. Rakenteinen kirjaaminen on toimiva lähtökohta. 

Sain aika paljon palautetta edellisestä Apotti-kirjoituksestani. Erityisesti sain kommentteja LinkedInissä. Sain myös suoraa palautetta Apotilta.

Edellinen kirjoitukseni perustui niihin tietoihin, joita Helsingin sanomien artikkelissa kerrottiin. Nyt sain enemmän tietoa siitä, mitä Apotissa tehtiin käytettävyyden eteen: mukana oli ollut käyttäjiä, käytettävyysammattilaisia, oli määritetty käytettävyysvaatimuksia, oli tehty käytettävyysvertailuja ja -arviointeja.

Tällaiset toimenpiteet ovat tärkeitä, mutta itsessään "eivät takaa mitään". On lukuisia esimerkkejä, että kehitystyössä on tehty käytettävyystoimenpiteitä - jopa massivisesti - ja silti lopputulos epäonnistui käytettävyydeltään. Yksi aiempi esimerkki on HSL:n matkakortinlukija, josta tein moniosaisen analyysin.

Aukaisen seuraavassa tarkemmin näitä kohtia (saamani palautteet kirjoitettu kursiivilla).

1. Rakenteisuus

Aloitetaan positiivisella asialla: 

”Suurin muutos on ollut siirtyminen rakenteiseen kirjaamiseen sekä toimintaa ohjaavaan järjestelmään. Niin oudolta kuin saattaa kuulostaakin, tähän saakka kaikki potilastietojärjestelmät ovat itse käyttäjän tekstin osalta olleet muistikirjoja, ja nyt rakenteisuutta lisäämällä päästään tilanteeseen, jossa koko potilasdata voi olla käytettävissä hoidon laadun seurantaan ja parantamiseen".

Rakenteisuus kuulostaan erinomaisen hyvältä!

Olen kuullut negatiivista palautetta joistakin aiemmista rakenteisista järjestelmistä. Itse olen ollut sitä mieltä, että kyse ei ole ollut siitä, että itse rakententeisuus olisi ollut ongelma, vaan siitä, että se oli toteutettu huonosti (”epäkäytettävästi”).

Jos Apotti on onnistunut rakentamaan käytettävyydeltään hyvän rakenteisuuden, niin hienoa! 

2. "Käytettävyydeltään paras"

”Käytettävyydeltään epic oli selkeästi paras tarjolla olleista”.

Jotta voidaan arvioida sen väitteen paikkaansa pitävyyttä, että epic oli ”käytettävyydeltään paras”, niin pitäisi tietää

1. mitkä olivat käytetyt käytettävyysmittarit 
2. miten nämä mittarit olivat määritetyt 

Mittarien pitää siis olla validit (mitataan oikeita asioita) ja riittävän kattavat (että mittauksissa ei jää huomioimatta oleellisia osa-alueita järjestelmästä). 

Ydinkysymys on: mitä olivat mittarit, ja miten ne oli johdettu?

3. Arvioinnin tekijät 

"Arvioinnin tekijät olivat käyttäjät ja ennen kaikkea käytettävyyden arvioinnin ammattilaiset”. 

Tässä ei sanota, miten käytettävyyttä arvioitiin. Voi kuitenkin todeta, että yleensä ottaen ei ole validi tapa, että käyttäjät arvioivat käytettävyyttä. 

Se on toki validia, että käyttäjät antavat palautetta omasta käyttökokemuksestaan. Mutta palautteen antaminen käyttäjäkokemuksesta on (ihan) eri asia kuin käytettävyyden arviointi.

Olen nähnyt paljon tapauksia, jossa käytettävyyden arvioinnista on käytetty epävalideja mittareita. Esimerkiksi arvioijat ovat  pisteyttäneet käytettävyyttä järjestelmän läpikäyntien tai demojen pohjalta. Näin ei pitäisi tehdä.

Myöskään se ei takaa mitään, että mukana oli käytettävyyden ammattilaisia. On esimerkiksi enemmän kuin tavallista, että käytettävyysammattilaisten näkemyksiä jätetään huomioimatta. Hyvänä esimerkkinä Nokia: epäonnistui käytettävyydessä vaikka yrityksessä oli mitä pätevimpiä ammattilaisia.

Myöskin käytettävyysammattilaisten tuotosten laadussa on vaihtelua. Tätä on tutkittu ns. CUE-tutkimuksissa, joista kirjoitin täällä.  

4. Käytettävyysvaatimukset

”Käytettävyydelle oli vaatimukset, ja ne jotka eivät läpäisseet, eivät päässeet kilpailutuksessa jatkoon".

Jotta käytettävyysvaatimusten validiteettia voisi arvioida, tässä pitäisi tietää, mitä nämä vaatimukset konkreettisesti olivat. Tarkemmin, pitäisi tietää:

• Käytetytyt mittarit, ja miten ne on johdettu (kuten kohdassa 2) 
• Ja sen lisäksi pitäisi tietää tavoitetasot, ts. mitkä olivat hyväksymisrajat kullekin mittarille, ja edelleen pitäisi tietää, millä tavalla tavoitetasot oli johdettu.

Omasta kokemuksestani voin todeta, että validien käytettävyysvaatimusten määrittäminen on erityisen haastavaa. Ei siis riitä, että määrittää mittarit ja tavoitetasot. Lisäksi nämä kumpikin pitäisi olla myös johdettu uskottavalla tavalla liiketoiminnan tavoitteista.

Ydinkysymys jatkuu: Mitä olivat mittarit, tavoitetasot ja niiden perusteet?

5. Parhaan valikoituminen

"Valikoitui se, joka oli käytettävyydeltään paras".

Kaksi näkökulmaa tähän: 

• Ei voida tietää valikoituiko käytettävyydeltään paras, ellei tiedä mittareita ja niiden validitettia (ks. edelliset kohdat)
• Jos käytettävyys on pisteytettävä kriteeri julkisessa hankinnassa, niin käytettävyydeltään paras ei välttämättä ollenkaan tule valituksi (vaan valituksi tulee se, joka saa korkeimmat yhteispisteet kaikista pisteytettävistä kriteereistä) 

Jos Apotti-kilpailutuksen tosiaan voitti käytettävyydeltään paras, niin voi sanoa, että kilpailutuksessa oli "onnea" käytettävyyden suhteen. Kun periaatteessa olisi voinut käydä niin, että käytettävyydeltään huonoin olisi voittanut. 

6. Järjestelmän rakentamisesta
"Itse järjestelmän rakennuksessa käyttäjät rakensivat lääke- ja hoitotieteellisen sisällön". 

Tämäkin on sanottu sen verran yleisellä tasolla, että vaikea ottaa suoraan kantaa. Mutta yleisesti ottaen, käyttäjien ei pitäisi rakentaa mitään. Maailma on täynnä esimerkkejä, miten tämä tietää epäonnistumista. 

Sen sijaan kehittäjien pitäisi rakentaa, ja sen perustaksi kehittäjien tulisi hankkia riittävän syvä osaaminen käyttäjien maailmasta. Kuten totean edellisessä kirjoituksessani, sellaisen ymmärryksen hankkiminen ei ole ollenkaan kohtuuton tehtävä. (Itse olen kirjoittanut aiheesta enemmän Kohdemaailma-analyysi -kirjassa).

Kyse ei ole vain suunnittelun laadusta, vaan myös etiikasta. Jos käyttäjät rakentavat jotain, silloin he luonnollisesti myös ovat vastuussa suunnitteluratkaisuista. Jos suunnitteluratkaisu ei toimi, niin syyttävä sormi osoittaa luonnollisesti noita käyttäjiä. Ja järjestelmäkehityksessä ei koskaan pitäisi vastuuttaa käyttäjiä. 

Miten käyttäjät ottaa mukaan tietojärjestelmäkehitykseen, ja miten ei, olen kirjoittanut eduskunnan tulevaisuusvalikunnan julkaisussa Silmät auki IT-etiikkaan. 

Apotin hankinnassa tehtiin kaksi vanhaa perusvirhettä

Pääkaupunkiseudun potilasitietojärjestelmän Apotin käytettävyys näyttää todella pettävän. Tässä muutama uutisjuttu asiasta huhtikuulta: 

• It-järjestelmän käyttäjät antoivat tylyjä arvosanoja – Vantaa muutti mieltään käyttöönoton “onnistumisesta”

• Apotti aiheuttaa yhä niin paljon virhetilanteita sairaaloissa, että osa lääkäreistä toivoo vanhoja järjestelmiä takaisin koronakriisin ajaksi

• Espoo hylkää sittenkin Apotin – ”Käyttäjäkokemus on ollut murskaavaa, harvoin näkee näin huonoja arvioita”

Apotin käytettävyysongelmia tuovat esiin myös professorit Antti Oulasvirta ja Johanna Kaipio. Oulasvirta pitää ”monimutkaisia valikoita, välilehtiä ja lisäikkunoita kömpelöinä”. 

Vaikka Apotin eteen tehtiin paljon käytettävyystyötä, sen vaikeakäyttöisyys oli ennakoitavissa jo sen perusteella, miten hankinta tehtiin. 

Tehtiin kaksi päävirhettä.

Virhe 1: Käytettävyys oli tarjouspyynnössä vertailutekijä eikä pakollinen vaatimus. Tämän toteaa myös prof. Oulasvirta: ”Hankintaa tehdessä arvioitiin, mikä kuudesta kisassa mukana olevasta järjestelmästä olisi paras. Ei, onko mikään tarpeeksi hyvä.” Kun käytettävyys on vertailutekijä, voi käydä niin, että valituksi tulee jopa käytettävyydeltään huonoin vaihtoehto, jos se pärjää hyvin muissa vertailutekijöissä. 

Oikea ratkaisu olisi ollut, että käytettävyys olisi ollut tarjouspyynnössä pakollinen vaatimus. Olisi pitänyt määrittää validein mittarein ja tavoitetasoin, mikä on potilastietojärjestelmän riittävä, ”tarpeeksi hyvä” käytettävyys. Valitun järjestelmän olisi ollut pakko täyttää tämä vaatimus.  

Virhe 2: Käyttäjät otettiin mukaan väärällä tavalla hankinnassa. Artikkelin mukaan kehitystyössä oli mukana ”paljon terveydenhuollon ammattilaisia muokkaamassa sitä Suomeen sopivaksi”. Tämä kuulostaa hyvältä, mutta itse asiassa on ydinongelma. Voidaan karkeasti yleistää, että hyvän käytettävyyden esimerkkejä ovat IT- ja käytettävyysammattimaisten suunnittelemat kulutustuotteet kuten Applen puhelimet. Sen sijaan huonoja esimerkkejä ovat puolestaan tietojärjestelmät, joiden suunnitteluun käyttäjiä on osallistettu, kuten tehtiin Apotissa.  

Oikea ratkaisu olisi siis ollut se, että Apotin käyttöliittymän suunnittelusta olisivat vastanneet yksiselitteisesti suunnittelun ammattilaiset. Toki käyttäjillä toki olisi ollut oma roolinsa: olla suunnittelijoiden tietolähteenä siitä, millainen on terveydenhuollon maailma ja testihenkilöinä kokeilemassa suunnitteluratkaisuja. Oleellista on, että käyttäjät olisivat olleet puhtaasti oman työnsä ja ammattinsa edustajina, eivät suunnitteluun liittyvissä tehtävissä. 

Itse yritin vaikuttaa Apotin käytettävyyskäytäntöihin sekä julkisesti - esimerkiksi vieraskynäkirjoitus (HS 2.7.2012) - sekä henkilökohtaisilla keskusteluilla. Kuitenkin Apotissa valittiin samat vanhat tavat, jotka olivat osoittautuneet toimimattomiksi. Tässä ei voi kuitenkaan osoittaa pelkästään Apottia, vaan näin on toimittu myös jälkikäteen. Esimerkiksi HSL:n matkakortinlukijan käytettävyysongelmia puitiin paljon myös julkisuudessa. 

Oikeiden toimintatapojen haasteet

Jotta julkisten tietojärjestelmien hankinnoissa päästäisiin hyvään käytettävyyteen, tarvitaan siis kaksi perusmuutosta nykyisiin käytäntöihin: 

• käytettävyys tarjouspyynnön pakolliseksi vaatimukseksi ja 
• käyttäjien ja suunnittelijoiden roolituksen muuttaminen

Käytettävyys pakollisena vaatimuksena on menetelmällisesti haastavaa. Se tarkoittaa pioneerityötä: uutta ajattelua ja vaativaa, erilaista käytännön menetelmätyötä. Olisi kuvitellut, että nimenomaan Apotissa olisi olisi ollut motivaatiota ja resursseja valita muu kuin toimimattomaksi tiedetty tapa. 

Sen sijaan suunnittelijoiden on mahdollista saada kohtuu ponnistuksin syvällinen ymmärrys monimutkaisestakin ympäristöstä kuten terveydenhuolto ja sairaalaympäristö. Usein muutaman päivän oikein kohdennetut haastattelut riittävät, että tuntee käyttäjien maailman ”paremmin kuin he itse”. Kynnys lienee siinä, että suunnittelutiimille on houkuttavaa välttää vastuuta suunnitteluratkaisujen laadusta ja sälyttää se käyttäjille. 

Mikä julkinen taho olisi edelläkävijä?

Helppokäyttöisten järjestelmien hankkiminen on mahdollista. Edellytyksenä on, että tehdään asioita eri tavalla kuin aiemmin. Apotilla olisi luultavasti ollut taloudellisia ja resurssiedellytyksiä tehdä tässä pioneerityötä. Toimivista vaihtoehdoista on olemassa tietoa. Mikä julkinen taho ottaisi edelläkävijän askeleen?

-----

(Lähetin tämän kirjoituksen suurin piirtein tällaisenaan Helsingin sanomiin, kun Apotti-keskustelu taas herähti käyntiin huhtikuussa. Lehti ei kuitenkaan julkaissut tätä. Mikä onkin kohtuullista, kun on sen verran usein juttujani julkaissut)

Edit 18.5.2020. Tarkensin juttua Johanna Kaipion kommentin perusteella. Pahoittelen epätarkkuuksia. 

Miten toimia käytettävyysasiantuntijana eettisesti oikein?

Käytettävyysasiantuntijana olen törmännyt tilanteisiin, jossa asiakas edellyttää vääriä toimenpiteitä. Miten toimia eettisesti oikein?

Tapaus muutaman vuoden takaa

Muutama vuosi sitten sain ennalta ajateltuna mielenkiintoisen toimeksiannon: määrittää käytettävyysnäkökulma erääseen julkishallinnon tarjouspyyntöön. Mielessäni oli se, että tekisin asian niin kuin se pitäisi tehdä: määrittää riittävän käytettävyyden kriteerit pakollisina vaatimuksina. 

(Väärä tapa on siis se, että määritetään käytettävyys pisteytettävänä vertailukriteerinä. Se on yleinen mutta toimimaton tapa, niin teoriassa kuin käytännössäkin. Olen kirjoittanut asiasta monessa yhteydessä, viimeksi edellisessä blogikirjoituksessani/ Helsingin sanomissa 1.8.2019.).

Toimeksianto eteni kuitenkin siten, että toimeksiantajan käyttöliittymävastaavalla oli jo etukäteen näkemys, miten käytettävyys pitäisi huomioida. Ja tietenkin se oli juuri tuo toimimaton ”käytettävyys pisteytettävänä vertailutekijänä” -tapa.

Miten minä käytettävyysasiantuntijana sitten toimin? Käyttöliittymävastaava piti kiinni näkemyksestään, ja tietenkin hänen näkemyksensä meni edelle omastani. Olin eettisen ongelman edessä: piti noudattaa sopimusta (jossa ei ollut määrittelyä työn sisällöstä tällä tarkkuudella) mutta olisi pitänyt tehdä sellaisia asioita, mitä mitkä olivat sisällöllisesti vääränä.

Ratkaisin asian niin, että otin yhteyttä käyttöliittymävastaavan esimieheen, ja kerroin, että käyttöliittymävastaavan ajama menettely on väärä. Perustelin yhteydenottoani UXPA:n Code of Professional Conduct -ohjeella, ja esimerkiksi ohjeen kohdalla ”Be Honest with Everyone”.

Esimies ymmärsi näkökulmani, mutta näki, että pitää kuitenkin tehdä, niin kuin vastuuhenkilö näkee.

Tein sitten toimeksiannon niin hyvin kuin osasin, vaikka tiesin, että tein väärää asiaa. Ei ollut mukavaa (eikä tullut jatkotilausta) mutta mieltäni kuitenkin helpotti se, että olin tehnyt asian selväksi toimeksiantajan kanssa.

Toinen tapaus

Eräässä yhteydessä tuli eteen koulutuspyyntö, jossa asiakas pyysi koulutusta sille, miten määrittää käytettävyys pisteytettävänä kriteerinä julkisen hallinnon tarjouspyyntöön. Käytännössä siis asiakas haluaa itselleen väärää koulutusta.

Miten suhtautua tällaiseen koulutuspyyntöön? Kysymys on siis siitä, että (a) ottaako tilauksen ja antaa väärää koulutusta, vai (2) kertoo asiakkaalle, että hän pyytää väärää asiaa, ja kertoo, millainen olisi oikea koulutus. Jälkimmäiseen tietenkin sisältyy riski, että menettää sitten tilauksen.

Tämä pyyntö ei tullut minulle asti, eli minun ei tarvinnut tehdä tuota valintaa. Jos asiaa ajattelee eettisesti, niin mielestäni jälkimmäinen on ainut oikea vaihtoehto. Mutta toisaalta voi olla tilanne, jossa tilauksen saaminen on syystä tai toisesta erityisen tärkeää. Mitä sinä ajattelet tästä?


PS. Muutama vuosi sitten Eduskunnan tulevaisuusvaliokunta julkaisi kirjan Silmät auki IT-etiikkaan. Kirjan yksi kappale on kirjoittamani, ja siinä kerron käytettävyyssuunnittelun etiikasta laajemmin, menetelmäkohtaisesti.

Ratkaisu julkisten hankintojen laatuongelmiiin: pitää määrittää "riittävä laatu"

Huomasin Hesarissa mielipidekirjoituksia julkisista hankinnoista, ja erityisesti niiden ongelmallisesta laadusta.

Kun kirjoitukset eivät mielestäni menneet asian ytimeen, niin kirjoitin, mistä asia kiikastaa. Eli siitä, että hankkijat eivät määritä tarjouspyyntöön hankittavalle palvelulle (järjestelmälle) riittävää laatua. Käytettävyyden suhteen se tarkoittaa, että ei määritetä (oikealla tavalla) riittävää käytettävyyttä/ käyttökokemusta.

Jos tarjouspyynnössä vaadita riittävää laatua, sitä mitä todennäköisimmin ei myöskään saada.

Kirjoitukseni, julkaistu 1.8.2019, näkyy tästä linkistä. Kirjoitus on kopioitu myös alle.

PS. Olen kirjoittanut tähän asiaan liittyen Hesariin ensimmäisen kerran vuonna 2011. Ja myös moniin muihin foorumeihin. Kukaan ei ole kumonnut näkemystäni, mutta käytäntöjen muuttamiseen ei tunnu  olevan innostusta. Ehkä syynä se, että kenelläkään (hankkijalla) ei lopulta ole motivaatiota...?

PPS. Jos luet kirjoitusta käytettävyysnäkökulma mielessä, niin korvaa sana "laatu" sanalla "käytettävyys".

-----------------

Palveluille pitää määrittää riittävä laatu

Julkiset hankinnat tarvitsevat uutta ajattelua. 

Helsingin sanomat 1.8.2019

MIELIPIDESIVUILLA on kirjoitettu julkisten hankintojen laadusta. Toimitusjohtaja Ilpo Niemen mukaan (HS 28.7.) parempi laatu ja korkeampi hinta voivat lopulta tulla hankkijalle edullisemmaksi kuin halvimman tarjouksen hyväksyminen. Hankintajohtaja Timo Martelius ehdotti (HS 30.7.) yhtenä ratkaisuna käänteistä kilpailutusta: hankintayksikkö ilmoittaa hinnan, jonka on valmis maksamaan palvelusta, ja kilpailu käydään vain laatuun liittyvillä perusteilla.

Kumpikaan näistä kirjoituksista ei kuitenkaan anna konkreettista ratkaisua hankintojen yleiseen ja perimmäiseen ongelmaan: miten varmistaa hankinnan riittävän hyvä laatu? Korkeampi hinta tai tietty hintaraja ei takaa laatua. Ratkaisu on riittävän laadun määrittäminen hankittavalle palvelulle.

Riittävä laatu tarkoittaa laadun vähimmäistasoa, jolla palvelu toimii riittävän hyvin käyttötarkoituksessaan. Riittävä laatu täyttää liiketoiminnan, asiakkaiden, käyttäjien ynnä muiden tarpeet.

Jos palvelun laatu on alle vähimmäistason, seurauksena on ongelmia, käyttäjien tyytymättömyyttä, lisäkustannuksia ja niin edelleen. ”Ylilaadusta” taas ei kannata maksaa, koska se ei tuo palveluun merkittävää lisäarvoa.

Haaste on, että jokaiselle hankinnalle pitää määrittää omat riittävän laadun mittarit ja kriteerit, eikä se yleensä ole helppoa. Riittävään laatuun liittyvä ajattelu on kuitenkin välttämätöntä hankintojen laadun kehittämiseksi. Vaikka lähestymistavassa on haasteensa, se vapauttaa resursseja yleisesti käytetyltä laatutekijöiden vertailulta, joka on tarpeetonta, hankalaa ja raskasta eikä lopulta takaa laatua.

Tarjouspyynnössä riittävä laatu näkyy sitten pienenä yllätyksenä. Kun riittävä laatu on pakollisena vaatimuksena ja kun laatuvertailuja ei tarvita, ainoaksi valintakriteeriksi jää hinta. Lopputulema kuulostaa nurinkuriselta. Jos julkisissa hankinnoissa haluaa hyvää laatua, valinnan tuleekin ratkaista viime kädessä hinta.

Timo Jokela

filosofian tohtori, dosentti, Helsinki

Matkakortinlukijan uusi versio: onko käytettävyysongelmat ratkaistu?

Vuosien 2016 - 2017 vaiheessa julkaisin moniosaisen analyysin silloin uudesta pääkaupunkiseudun paikallisliikenteen matkakortinlukijasta. Raportoin ongelmista niin lukijan käytettävyydessä kuin hankintatavassa.

Keväällä 2019 matkakortinlukijasta tuli uusi versio uusien matkustusvyöhykkeiden myötä. Paraniko käytettävyysongelmat uuden version myötä? Katso video alta (pituus: 3 min 32 sek).

MIllainen on UX -strategia?

Vaikka UX -strategiaa pidetään tärkeänä, konkreettiset esimerkit puuttuvat. 

Jotta saataisiin konkreettisia esimerkkejä, UXPA Boston järjesti "UX Strategy" -kilpailun osana 2019 UXPA Boston -konferenssia. Tanskalaisen UX-konsultin Rolf Molichin toimisto DialogDesign sponsoroi 3000 dollarin palkinnon jaettavaksi parhaille ehdotuksille. 

Kilpailussa jaettiin viisi palkintoa. Parhaan (1000 dollaria) sai Ann Thompsonin ehdotus. Neljä ehdotusta palkittiin "toisella" sijalla (500 dollaria) ja itse pääsin tähän joukkoon. 

Oma ehdotukseni arvioitiin seuraavasti: "It challenges assumptions about how we typically strategize. It differs from the other submissions in a thought-provoking way". En pidä arviotani yllättävänä - sen verran usein olen huomannut olevani "toisinajattelija" omalla alallani. 

Tietoa kilpailusta ja palkittujen UX-strategiaehdotukset löytyvät täältä. 

Millainen on onnistunut julkinen hankinta? Perusasiat

Julkisen hankinnan tavoite on hieno: asettaa tarjoajat samalla viivalle. Julkisen hankinnan osaamisen tärkein kriteeri on se, miten määrittää riittävä laatu tarjouspyyntöön. Tämä usein ymmärretään väärin ja tässä usein epäonnistutaan. 


Julkisen hankinnan ongelmat ovat nousseet viimeksi esiin, kun tuli ilmi yksityisten toimijoiden laiminlyönnit vanhusten hoidossa. Ja monet ovat moittineet julkista hankintaa, ja esittäneet erilaisia "parempia" tapoja, miten hankinnat pitäisi hoitaa.

Valitettavasti monilla kommentaattoreilla ei näytä olevan edes perusymmärrystä julkisen hankinnan perussäännöistä.

Seuraavassa yritän vetää yhteen julkisen hankinnan oleellisimmat piirteet. Tarkoitukseni on, että asiaan perehtymätönkin lukija saisi peruskäsityksen siitä, mistä julkisissa hankinnoissa on kyse.

Myös aiemmin olen kirjoitellut ja tehnyt videoita asiasta, esim.

• "Miksi julkinen taho hankkii hankalakäyttöisiä tie...
• Miten hankkia helppokäyttöisiä tietojärjestelmiä? ...
• Matkakortinlukija. Osa 1: Massiivia käytettävyyste... (moniosainen analyysi pääkaupunkiseudun matkakortinlukijan hankinnasta ja käytettävyysongelmista)

Julkisten hankintojen tavoite on hieno

Julkisten hankintojen käytännöillä on hieno tavoite: varmistaa se, että julkinen taho on puolueeton, että kaikki tarjoajat ovat samalla viivalla.

Siis että vältettäisiin tuttujen ja tiettyjen yritysten suosimista. Ja että tehtäisiin mahdolliseksi, että myös uusilla yrityksillä on mahdollisuus päästä tasapuolisesti mukaan julkisen tahon toimittajaksi.

Julkisia hankintoja ja sen käytäntöjä ei siis pidä itsessään arvostella. Sen sijaan voi arvostella sitä, miten julkiset hankinnat käytännössä toteutetaan. Julkisen hankinnan laadukas toteuttaminen ei ole helppoa, ja hankinnat tehdään usein kyseenalaisella laadulla.

Tarjouspyyntö on julkisen hankinnan keskeisin asia

Julkisten hankintojen keskeisin dokumentti on tarjouspyyntö. Tarjouspyynnön perusteella

• tarjoajat laativat tarjouksensa sisällön, ts. mitä sitoutuvat toimittamaan asiakkaalle
• valitaan voittava tarjous

Tarjouspyyntö sisältää kolme keskeistä asiaa: 

1. Kelpoisuusvaatimukset. Tarkoittaa vaatimuksia, mitkä asetetaan tarjoavalle yritykselle. Esimerkiksi jos hankittava tuote tai palvelu on sisällöltään "iso", voidaan vaatia, että tarjoava yritys on vähintään tietyn kokoinen. Tai voidaan vaatia, että tarjoavalla yrityksellä on aiempaa kokemusta samantyyppisten tuotteiden/ palvelujen toimittamisesta. 
2. Laatuvaatimukset (käytetään usein nimitystä "pakolliset vaatimukset"). Tarkoittaa vaatimuksia, mitkä asetetaan tarjotulle tuotteelle tai palvelulle. Jos hankitaan vanhusten hoivapalvelua, niin pakolliseksi resurssivaatimukseksi voitaisiin asettaa "0,7", eli 7 hoitohenkilökunnan jäsentä 10 vanhusta kohden. 
3. Vertailukriteerit. Määrittää mittarit, joiden perusteella valitaan voittaja niiden tarjousten joukosta, jotka täyttävät sekä kelpoisuusvaatimukset että pakolliset vaatimukset. Vertailukriteereissä yksi tekijä on aina hinta; lisäksi voi olla laatukriteereitä. Esimerkiksi hinnan painoarvo voi olla 70%, laatutekijä a 20%, laatutekijä b 5% ja laatutekijä c 5%. Voittaja on se, joka saa eniten pisteitä, kun eri valintakriteerien pisteet lasketaan painotetusti yhteen. 

Huomioitavaa on siis se, että 

• laatuvaatimukset määrittävät, millainen tuote tai palvelu tilataan
• voittavaa tarjousta ei valita "älyllisesti", vaan voittaja määritetään mekaanisesti laskemalla vertailukriteerien pisteitä yhteen
• ja siis se, että tarjouspyynnön sisältö - miten kelpoisuusvaatimukset, laatuvaatimukset ja vertailukriteerit on laadittu - "ratkaisee kaiken"

Käytännön huomiot osoittavat, että tarjouspyyntöjä ei useinkaan osata tehdä oikein

Julkisen hankinnan onnistumisen ratkaisee siis se, miten tarjouspyyntö on laadittu. 

Itse olen seurannut tietojärjestelmien hankintoja, ja huomannut, että tarjouspyynnöissä on paljon ongelmia. Esimerkiksi en ole nähnyt ensimmäistäkään tarjouspyyntöä - ja olen käynyt niitä läpi ehkä 200 - jossa tietojärjestelmän  käytettävyys (helppokäyttöisyys) olisi osattu laittaa tarjouspyyntöön oikealla tavalla (= että varmistettaisiin, että järjestelmän käytettävyys on riittävän hyvä). 

Oletukseni on, että myös muiden kuin tietojärjestelmien tarjouspyynnöissä on ongelmia. Jos ei olisi, niin ei pitäisi olla myöskään ongelmia tarjotuissa palveluissa, kuten vanhusten huollossa. 

Mahdollisia ongelmia voi olla kaikissa katergorioissa (kelpoisuusvaatimuksissa, laatuvaatimuksissa ja vertailukriteereissä), esimerkiksi

• määritetään kelpoisuusvaatimuksia, jotka turhaan sulkevat pois joitakin yrityksiä
• asetetaan laatuvaatimuksia, jotka ovat tarpeettomia ja tekevät toimittajien ratkaisuista turhan monimutkaisia, laaduttomia ja kalliita
• jätetään oleellisia laatuvaatimuksia asetettamatta
• vertailukriteerit asetetaan väärin 

Suuri väärinkäsitys laadun ja hinnan suhteessa

Ehkä merkittävin virhe ja väärinkäsitys, mikä tarjouspyynnöissä tehdään, on miten hinta ja laatu sisällytetään niihin.  

Ajatellaan, että jos vertailukriteereissä hinnan painoarvo asetetaan pieneksi (esim. 30%) ja laatutekijöiden painoarvo suureksi (esim 70%), niin saataisiin hyvää laatua. Tämä on täydellinen väärinkäsitys. Näin ei varmisteta laatua. 

Oikea tapa on määrittää riittävä laatu pakollisiin vaatimuksiin, ja asettaa vertailukriteereiksi pelkästään hinta (vertailukriteereissä hinnan painoarvo on 100%). Näin saadaan riittävän hyvä tuote tai palvelu edullimmalla hinnalla. 

Haasteena on sitten tietenkin usein se, mikä on riittävä laatu ja miten se määrittää. Tämän määritys onkin julkisen hankinnan aidon osaamisen mittari. 

Uusi kirja julkaistu: "Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa".

Uusi kirjani "Kohdemaailma-analyysi. Syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa" julkaistiin 11.1.2019.

Kirjan sisällön voi tiivistää erään palautteen sanoin: ”Aivan ehdoton tapa aloittaa joku projekti, jotta voi varmistua, että kaikki puhuu jatkossa samaa kieltä ja ymmärtää asiat samalla tavalla.”

Enemmän kirjasta:

• esittelytilaisuuden videotallenne
• aiempi blogikirjoitukseni
• kustantajan Ketterät kirjat sivulta, josta kirjan voi myös tilata. 

Kohtele asiakasta samoin kuin käytettävyystestauksessa kohdellaan käyttäjää

Kohdemaailma-analyysi on menetelmä, jolla pääset nopeasti syvälliseen asiakasymmärrykseen heti kehityshankkeen alussa. Menetelmä ja siitä kertova kirja julkaistaan webinaarissa perjantaina 11.1.2019 klo 13. 

Webinaarin ilmoittautumissivulle pääset tästä (paikkoja rajoitetusti). 

-----------------------------
Seuraavassa johdatusta Kohdemaailma-analyysi -menetelmään.

1. Aluksi käytettävyystestauksesta, mistä löytyy menetelmän tausta.
2. Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?
3. Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?

1. Käytettävyystestauksen keskeinen periaate

Käytettävyystestaus on käytettävyyssuunnittelun perinteisin menetelmä. Sen kulku pääpiirteissään on:

• lähtökohtama on kehitettävän järjestelmän jonkintasoinen prototyyppi
• pyydetään käyttäjiä testihenkilöiksi
• annetaan käyttäjälle tehtäviä, joita käyttäjän pitäisi suorittaa
• annetaan käyttäjälle ohjeistukset: 
• "Tee tehtävä parhaasi mukaan". (usein pyydetään samalla ajattelemaan ääneen)
• "Keskity omaan suoritukseesi, tehtäväsi ei ole arvioida käyttöliittymän hyvyyttä".
• "Jos et osaa tehdä tehtävää, niin vika ei ole sinussa vaan suunnitteluratkaisuissa".
• testiä seuraava suunnittelutiimi havainnoi käyttäjän suoriutumista, yrittäen ymmärtää käyttäjän suoriutumisen perusteella, mikä suunnitteluratkaisussa toimii ja mikä ei toimi
• korjataan suunnitteluratkaisut, jotka eivät näyttäneet toimivan

Käytettävyystestauksessa on siis keskeistä, että käyttäjä on pelkästään tiedon lähde. Hän toimii ainoastaan omana itsenään, kun hän yrittää tehdä tehtäviä. 

Käyttäjällä siis ei ole mitään vastuuta käyttöliittymän kehittämisestä: 

• ei analysointi- eikä jäsentämisvastuuta testin aikana
• eikä vastuuta siitä, millainen käyttöliittymä lopulta kehitetään.

Jos tämän muotoilee suunnitteluperiaatteeksi, niin se voisi kuulua: 

Suunnittelutiimi vastaa kaikesta käytettävyydestä. Käyttäjä ei mistään. 

2. Miksi asiakkaan ymmärtäminen ei useinkaan onnistu järjestelmäsuunnittelussa?

Järjestelmäkehityksessä asiakaslähtöisyys tarkoittaa usein asiakkaan vastuuttamista. Pyydetään asiakasta määrittämään vaatimuksia, esittämään toiveita, osallistumaan työpajoihin jne. 

Tämä ei yleensä vain toimi: lopputuleman laatu kun voi olla mitä tahansa. Tilanne on vähän sama kuin jos käyttäjät laitettaisiin suunnittelemaan käyttöliittymiä. (joo, tiedän, että näinkin tehdään...)

Miksi tämän tyyppinen asiakkaan osallistaminen ei toimi? 

Sen vuoksi, että on hyvin sattumanvaraista, kuinka hyvin asiakkaat pystyvät jäsentämään oikein tarpeitaan ja maailmaansa. Vaatimusten, toiveiden ym. esittäminen laadukkaasti on hyvin haastava tehtävä, johon monellakaan ei ole aidosti resursseja: ei aikaa eikä usein kiinnostustakaan. 

Laatuongelman ohella asiakkaan laittaminen tällaiseen työskentelyyn on myös eettisesti kyseenalaista. 

3. Mitä tarkoittaa "kohdella asiakasta samoin kuin käyttäjää"?

Käytettävyystestauksen periaatteen (ks. yllä) voisi muotoilla järjestelmäsuunnittelun tasolle seuraavasti: 

Suunnittelutiimi vastaa yksin siitä, että suunnitteluratkaisut ovat asiakkaan tarpeiden mukaiset. Asiakas ei ollenkaan. 

Mitä tämä tarkoittaa käytännössä? Miten pitäisi kommunikoida asiakkaan kanssa, kun halutaan ymmärtää hänen maailmaansa ja tarpeitaan? Niin että vastuu on suunnittelutiimillä, ja tuloksena on aito asiakasymmärrys?

Tähän vastaa Kohdemaailma-analyysi -menetelmä. Menetelmä - ja siitä kertova kirja - esitellään webinaarissa pe 11.1. klo 13. Tässä vielä linkki ilmoittautumissivulle. 

Mikä meni Nokian käyttöliittymissä pieleen?

Nokialla sai 1990-luvulla vallan erikoinen käyttöliittymäparadigma, jossa yhdeksi puhelinten segmentointitekijäksi otettiin erilaiset käyttöliittymät. Monet erilaiset käyttöliittymät osaltaan vaikuttivat Nokian luopumiseen puhelinbisneksestä.

Luin Risto Siilasmaan kirjan ”Paranoidi optimisti”, jossa hän kertoo kokemuksistaan Nokian hallituksessa vuodesta 2008 eteenpäin. Mukaansa tempaava, mielenkiintoinen kirja!

Ehkä merkittävin Nokian ongelma oli se, että ohjelmistokehityksen isoja ongelmia ei tuotu avoimesti esiin johdolle: ei hallitukselle, mutta ei myöskään alemmille johtoportaille. Ja kun asia selvisi, oli liian myöhäistä. 

Ohjelmistokehityksen yksi osasyy oli puhelinten käyttöliittymissä. Niihin liittyi kaksi selkeää ongelmaa:  

1. Aluksikin, puhelinten käytettävyys oli ongelmallista, käytettävyys ei ollut (läheskään) Applen tasoa. 
2. Toiseksi, Nokian eri puhelimissa oli erilaisia käyttöliittymiä. Kun Apple pystyi keskittymään yhden käyttöliittymän kehittämiseen, niin Nokian tarvitsi paljon resursseja ylläpitämään ja kehittämään monia käyttöliittymiä. 

Tässä nyt keskityn tuohon jälkimmäiseen (2) ongelmaan. Yksinkertainen peruskysymys on: 

Miksi Nokialla oli eri puhelimissa erilaisia käyttöliittymiä? 

Itse olin Nokialla Oulun yksikössä 1990-luvun loppupuolella, jolloin tämä kehitys sai alkunsa. Mitä tarkalleen tapahtui 2000-luvulla, sitä en tiedä. Mutta ainakin tilanne oli sama: erilaisia käyttöliittymiä eri puhelimissa. 

Nokialla sai 1990-luvulla valtaa sellainen ajattelu, että käyttöliittymä on yksi segmentointitekijä. Eri markkinasegmenteille suunniteltiin erilaisia ominaisuuksia sisältäviä puhelimia (sinällään järkevää). 

Mutta se, että yhdeksi segmentointitekijäksi otettiin erilaiset käyttöliittymät, oli käytettävyysmielessä tietenkin älytön ajatus. 

Monet käyttöliittymätyylit veivät siis Nokialta paljon kehitysresursseja. Lisäksi paradigmaan liittyy (ainakin) kaksi käytettävyysongelmaa:  

1. Erilaiset käyttöliittymät tarkoittivat, että eri puhelimet olivat erilaisia käyttää. Kun oli oppinut käyttämään yhtä nokialaista, ei osannut käyttää toista mallia. Ilmiö näkyi myös Nokian sisällä. Nokian omatkin työntekijät kertoivat, kuinka hankalaa oli opetella käyttämään erimallista nokialaista.
2. Erilaiset käyttöliittymät tietenkään eivät ole käytettävyydeltään saman vertaisia. Ja erityisesti alemman segmentin vähänäppäimisissä malleissa oli käytettävyysongelmia. Karrikoiden voikin sanoa, että Nokian ratkaisu konkretisoitui - toki tiedostamatta - siten, että ”köyhemmille saa kelvata huonompikin käytettävyys”. 

Lienee ilmeistä, että käytettävyysasiantuntijan näkökulmasta tilanne oli vähintään turhauttava. Varsinkin kun tätä erikoista suunnitteluparadigmaa markkinoitiin Nokian sisällä ”käytettävyydellä”. (Tämän enempää en kuitenkaan mene siihen, miten tällainen kehitys sai Nokialla vallan). 

Koin oman käytettävyysasiantuntijan roolini erittäin ristiriitaisena. Toisaalta käytettävyysasiantuntijana olin tukemassa näiden eri tyylien käytettävyyden hiomista (ja niistä tulikin kohtuullisia). Toisaalta koko ajan olin siinä ristiriitatilanteessa, että mitä paremmin tein työni, sitä enemmän välillisesti tuin tuota älytöntä monen erilaisen käyttöliittymätyylin paradigmaa. 

Risto Siilasmaa kertoo useampaan otteeseen kirjassaan, miten hän tuoreena johtoryhmän jäsenenä oli ”arka”, eikä ottanut esiin asioita, jotka häntä vaivasivat. 

Ehkä myös minä omalta osaltani olin ”arka”. Yritin kyllä viestiä asiasta Nokia sisällä, mutta en ehkä oikeille tahoille. Enkä välttämättä oikeilla tavoilla. Ongelma oli esimerkiksi se, että miten viestiä käytettävyyttä, kun johdolle oli viestitty, että vallalla ollut paradigma ikään kuin edusti käytettävyyttä? 

Kun sitten tässä tilanteessa minulle tarjottiin Oulun yliopistolta professorin tehtävän hoitamista, niin siirryin Nokialta pois. Ei mikään tavallinen ratkaisu tilanteessa, jossa Nokia oli kuumimmassa nousukierteessä.  

PS. Sen ajan avaintermi oli ”käytettävyys”, ”usability”. Tänä päivänä varmaan puhuttaisiin ”käyttäjäkokemuksesta”, ”user experience”.