Vaikuttavuus on tärkeää - mutta miten se pitäisi ottaa huomioon julkisissa hankinnoissa?

Tietojärjestelmän vaikuttavuuden mittareiden ja tavoitteiden määrittäminen on tärkeää. Niitä ei kuitenkaan pitäisi sisällyttää sellaisinaan tarjouspyyntöön vaatimuksiksi, koska vaikuttavuuden todentaminen on mahdollista vasta käytön aikana, ehkä paljonkin kehitystyön päättymisen jälkeen. Sen sijaan haluttu vaikuttavuus olisi määritettävä tarjouspyyntöön sellaisilla alemman tason vaatimuksilla, (1) joiden saavuttaminen voidaan todentaa heti kehitystyön päättyessä ja (2) joiden saavuttaminen tarkoittaa riittävän luotettavasti, että saavutetaan myös haluttu vaikuttavuus. 

Olin mukana 13.10.2022 Hankinta-yhdistyksen aamukahveilla, jonka aiheena oli Kustannusvaikuttavuuden laskenta osana hankintaprosessia. 

Aihe on sikäli kiinnostava, että itse olen korostanut käytettävyyden vaikuttavuuden määrittämisen tärkeyttä (esimerkiksi tässä Sytyke-lehden artikkelissa). Tarkoittaa sitä, että ensin pitäisi määrittää haluttu käytettävyyden vaikuttavuus, ja vasta sen jälkeen käytettävyysvaatimukset.  

Aamukahvien esimerkki: toimittajan palkitseminen vaikuttavuuden saavuttamiseksi

Aamukahvien keskustelussa kerrottiin esimerkki julkisen hallinnon tietojärjestelmähankinnasta, jossa vaikuttavuus oli otettu huomioon näin:

• Toimittajaa palkittiin sen mukaan, kuinka paljon palvelu houkuttelisi käyttäjiä. Siis mitä enemmän käyttäjiä palvelulla, sitä enemmän palkitaan toimittajaa. Muistaakseni tavoite oli 60.000 käyttäjää. 
• Tässä ei siis suoraan vaikuttavuutta mitattu rahassa, mutta vaikuttavuudesta kyse on joka tapauksessa.

Oletan, että tämä palkitsemismalli oli osana tarjouspyyntöä; tosin tästä ei ollut puhetta tilaisuudessa.

Toimittajan palkitseminen vaikuttavuusmittarilla - miksi voi olla ongelma?

Edellä mainitussa lähestymistavassa on yksi periaatteellinen ongelma. Vaikuttavuuden käyttäminen tavoitteena tai palkitsemisperusteena (tarjouspyynnössä) on ongelma sitä kautta, että vaikuttavuuden saavuttamista ei voi todentaa kehitystyön päättyessä: 

• Vaikuttavuushan tulee esiin vasta ajan myötä, kuten edellä mainitussa esimerkissä käyttäjien lukumäärä. 
• Käytännössä tarkoittaa sitä, että haluttu vaikuttavuuden saavuttaminen jää arvoitukseksi siinä vaiheessa, kun kehitystyö on päättynyt. 

Jos käy niin, että esimerkin järjestelmä ei houkuttele käyttäjiä, niin tilaajalta säästyy toimittajan bonusrahat. Mutta mitä tilaaja tekee järjestelmällä, jota käyttäjät eivät käytä?

Jos ottaa konkreettisemman esimerkin, niin moni varmaan muistaa muutaman vuoden takaisen yrityksen käyttää äänestyskonetta kunnallisvaaleissa. Sehän päättyi epäonnistumiseen, kun jotkut äänestäjät jättivät epähuomiossa äänestysprosessin kesken (kyseessä siis selkeä käytettävyysongelma...).

Kuvitellaan, että yllämainittua vaikuttavuusajattelua olisi käytetty äänestyskoneen kehittämisessä. Siis että looginen toimittajan palkitsemisen mittari olisi se, että vaalit onnistuvat äänestyskoneella. Mutta silloin ollaan jo auttamattomasti myöhässä, koska äänestyskoneen *pitää* toimia vaaleissa. Ei oikein voi ajatella niin, että toimittajan palkitsemismekanismi on se, että vaalit onnistuvat äänestyskoneella, ja samalla ottaa riski, että vaalit eivät onnistukaan. (On muuten esimerkki vaikuttavuudesta, jonka mittaaminen rahassa on vaikeaa). 

Miten sitten ottaa vaikuttavuus huomioon hankinnoissa?

Tavoitteellista pitäisi olla, että haluttu vaikuttavuus voitaisiin mitata - riittävän luotettavasti - heti kehitystyön päättyessä. 

Miten tämä voidaan tehdä? 

Ihan niin kuin yllä, aluksi hankkijan pitää määrittää vaikuttavuusmittarit- ja tavoitteet. Määritetään esimerkiksi, kuinka paljon käyttäjiä halutaan kehitettävälle järjestelmälle. Tai että äänestyskoneen on oltava sellainen, että vaalit onnistuvat. 

Sitten perusratkaisu vaatimusten määrittämiselle tarjouspyyntöön on, että määritetään sellaiset alemman tason vaatimukset, että

1. vaatimusten saavuttaminen voidaan todentaa kehitystyön päättyessä
2. vaatimusten saavuttaminen tarkoittaa riittävän luotettavasti sitä, että myös haluttu vaikuttavuus saavutetaan

Kummatkin edellämainitut esimerkit (tietojärjestelmä, äänestyskone) ovat sellaisia, joissa haluttu vaikuttavuus (paljon käyttäjiä, onnistuneet vaalit) riippuu suoraan järjestelmän käytettävyydestä. 

Alemman tason vaatimuksia olisivat silloin käytettävyysvaatimukset. Käytettävyysvaatimukset (valituilla käytettävyysmittareilla) pitää siis määrittää sellaisiksi, että niiden saavuttaminen tarkoittaa riittävän luotettavasti sitä, että kehitetyllä järjestelmällä saavutetaan haluttu vaikuttavuus järjestelmän käytön aikana. Käytännössä käytettävyysvaatimuksilla tarkoitetaan käyttäjien suoriutumiseen perustuvia vaatimuksia, niin kuin olen useassa kirjoituksessa todennut (esimerkiksi tässä). 

Hankkijan on tehtävä sisäisesti käytettävyysvaatimusten analyysi- ja määrittämistyö ennen hankintaa. Tarjouspyyntöön määritettäisiin sitten käytettävyysvaatimukset (eikä vaikuttavuusmittarit). Kyseiset käytettävyysvaatimukset olisivat sitten osa järjestelmän hyväksymiskriteereitä kehitystyön päättyessä. Ja jos käytettävyysvaatimukset on määritetty oikein, niin järjestelmällä pitäisi tulla saavuttamaan myös haluttu vaikuttavuus.  

Seitsemän (7) väärää ja neljä (4) oikeaa tapaa ottaa käyttäjät mukaan järjestelmän hankinnassa ja kehityksessä

Kirjoitin elokuussa blogikirjoituksen potilastietojärjestelmän tarjouspyynnöstä. Sen jälkeen tuli keskustelua LinkedInissä liittyen siihen, miten käyttäjien pitäisi olla mukana järjestelmien hankinnassa ja kehityksessä, ja miten ei. 

Olen kirjoittanut asiasta aiemmin seikkaperäisesti, esimerkiksi kappaleen Miten käyttäjät mukaan tietojärjestemäkehitykseen - ja miten ei? Eduskunnan tulevaisuusvaliokunnan julkaisuun Katse kohti IT-etiikkaa. 

Nyt sitten ajattelin kerrata lyhyesti: luettelo niin laadullisesti kuin eettisesti vääristä ja oikeista tavoista. 

Väärät tavat ottaa käyttäjät mukaan: 

1. Käyttäjiä pyydetään määrittelemään järjestelmän ominaisuuksia ja kertomaan mielipiteitä tulevasta järjestelmästä 
2. Käyttäjiä pyydetään määrittelemään vaatimukset järjestelmälle 

3. Suunnitellaan yhdessä käyttäjien kanssa
4. Käyttäjiä pyydetään antamaan käyttöliittymistä laadullisia ”asiantuntija-arviointeja” 

5. Käyttäjiä pyydetään katselmoimaan käyttöliittymiä 
6. Käyttäjiltä kysytään ehdotuksia paremmiksi suunnitteluratkaisuiksi 
7. Käyttäjät laitetaan pisteyttämään järjestelmän käytettävyys toimittajien esittämien demojen perusteella 

Oikeat tavat ottaa käyttäjät mukaan:

1. Sisällölliset haastattelut: käyttäjiltä haastatellaan heidän työstään tai ammattiosaamisestaan 
2. Käyttäjiä havainnoidaan heidän työssään 
3. Käyttäjiä pyydetään käytettävyystestien testihenkilöiksi 
4. Käyttäjiltä kysytään heidän käyttökokemuksestaan 

Jos nämä vetää yhteen periaatteiksi, niin voisi tiivistää, että käyttäjät otetaan mukaan laadullisesti ja eettisesti oikein, kun  

• Käyttäjien ei pidä olla missään muussa roolissa kuin oman ammattinsa ja työtehtävänsä edustajana (käyttäjät ovat siis ainoastaan omalla mukavuusalueellaan)
• Käyttäjiä ei pidä vastuuttaa mistään asiasta järjestelmän hankinnan ja kehitystyön aikana; ei esimerkiksi siitä, että osaavatko jäsentää haastatteluissa vastauksiaan oikein ("oikeat tavat" kohta 1). Kaikki vastuu suunnitteluratkaisujen  - ja myös vaatimusten - oikeellisuudesta on aina suunnittelutiimillä. 

Jos kiinnostaa, miten tehdään tuloksellisesti ja tehokkaasti sisällöllisiä haastatteluja ("Oikeat tavat" kohta 1),  olen kirjoittanut menetelmästä kirjan Kohdemaailma-analyysi. Menetelmässä kerrotaan, miten haastatella asiakkaita niin, että saadaan nopeasti syvällinen ymmärrys asiakkaan tarpeista samalla, kun haastateltavia kohdellaan eettisesti oikein. 

PS. Jos sinulla on kommentoitavaa ym. oikeisiin ja vääriin tapoihin (tai muuten kirjoitukseen), niin mielellään sellaisia kuulisin!

Lappican potilastietojärjestelmän tarjouspyyntö: ei uutta käytettävyyden suhteen

Lapin alueella toimiva Lappica Oy on tehnyt tarjouspyynnön potilastietojärjestelmästä. Tavoitteena on hankkia "helppokäyttöinen" järjestelmä. Kun tutkii tarjouspyynnön sisältöä, siinä ei kuitenkaan käytännössä edellytetä helppokäyttöisyyttä. Sinällään tämä ei ole yllättävää: kun isommatkaan hankintayksiköt eivät osaa aidosti vaatia käytettävyyttä tarjouspyynnössä, miten pienehköllä hankintayksiköllä olisi edellytyksiä olla uranuurtaja. 

HUOM! Korostan vielä, että tätä analyysia ei pidä ottaa erityiseksi kritiikiksi Lappica Oy:ta kohtaan. Tarjouspyyntö sattui vain osumaan silmääni, kun kyse on potilastietojärjestelmästä. Olen seurannut aika tiiviisti Apotti-potilastietojärjestelmän hankintaa (monet kirjoitukset tässä blogissa, ja esimerkiksi Helsingin Sanomissa). Otin tämän tarjouspyynnön tarkasteluun ihan tämän kiinnostuksen pohjalta. 

Mistä kyse

Pääkaupunkiseudun Apotti-potilastietojärjestelmän käytettävyysongelmat ovat tunnettuja. Nyt Apotista on tekeillä jopa kantelu. 

Keskeinen syy Apotin käytettävyysongelmiin on se, että vaikka käytettävyyttä pidettiin lähtökohtaisesti erittäin tärkeänä asiana, sitä ei edellytetty oikealla tavalla tarjouspyynnössä (analyysia esimerkiksi tässä). Käytettävyys oli kyllä keskeisenä laatutekijänä tarjouspyynnössä, mutta ei sillä tavalla, että se olisi aidosti sitonut toimittajaa tuottamaan hyvää käytettävyyttä. 

Nyt sitten osui sattumoisin silmiini uusi potilastietojärjestelmän kilpailutus, kun Lapin sairaanhoitopiirin tarjouspyyntö on julkaistu (luettavissa luultavasti 15.8.2022 asti, jolloin on tarjousten viimeinen jättöpäivä). 

Kun kyseessä on potilastietojärjestelmä, tarjouspyyntö kiinnosti sen verran, että analysoin sitä seuraavassa käytettävyyden kannalta. 

Miten käytettävyys määräytyy yleensä tarjouspyynnöissä?

Tarjouspyynnössä halutun käytettävyyden tason määrittä kaksi asiaa: 

• miten käytettävyysasioita vaaditaan pakollisissa vaatimuksissa
• miten käytettävyysasioita on sisällytetty vertailuperusteisiin, ja mitkä ovat näiden painoarvot vertailussa

Valintaprosessi menee sitten lyhyesti ilmaistuna: 

    1. Tarkistetaan, täyttyvätkö pakolliset vaatimukset: 

• Jos täyttyvät, tarjous etenee vertailuvaiheeseen
• Jos eivät täyty, tarjous tipahtaa pois kilpailutuksesta

    2. Lasketaan yhteen vertailupisteet. Tarjouskilpailun voittaja on se, joka saa eniten vertailupisteitä. 

Käytännössä keskeisin asia on se, miten käytettävyys on määritetty pakollisiin vaatimuksiin. Hyvin valmistellussa tarjouspyynnössä kaikki käytettävyysasiat on pakollisissa vaatimuksissa. Vain erityisissä tapauksissa käytettävyysasioita on perusteltua laittaa vertailuperusteisiin. 

Lappican tarjouspyynnön sisällön kuvausta

Tarjouspyynnön johdanto-osassa lukee esimerkiksi: 

"Tavoitteena on saada käyttöön helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava työterveyshuollon järjestelmä. Järjestelmän perustoiminnallisuuksien pitää olla joustavia ja käyttäjien muokattavissa...  Järjestelmän pitää tukea ja helpottaa yhteistyötä työnantaja-asiakkaiden kanssa. Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla."

Tällä perusteella käytettävyys on hankkijalle tärkeä asia.

Mutta. On huomattava, että tällaisella epäformaalilla johdantotekstillä ei ole mitään merkittävyyttä kilpailutuksessa. Toimittajien ei kannata kiinnittää tällaiseen mitään huomiota, koska tällaiset yleiset tavoitteet eivät vaikuta voittajan valintaan millään tavalla, eivätkä velvoita voittajaa mihinkää niitä ratkaisun kehittämisessä.  

Mitä käytettävyysasioita vaaditaan tarjouspyynnössä?

Tässä tarjouspyynnössä vertailuperusteet ovat:

• laadulliset vaatimukset 40 pistettä, joista
• "pisteytettävät vaatimukset" 35 pistettä 
• projektisuunnitelma 5 pistettä
• hinta 60 pistettä
• (yhteensä 100 pistettä)

"Pisteytettävät vaatimukset", samoin kuin pakolliset vaatimukset on esitetty samassa, isossa excel-taulukossa

• pakolliset vaatimukset tarkoittavat, että toimittajan on pakko täyttää ne (muuten tipahtaa pois kilpailutuksesta)
• pisteytettävät vaatimukset tarkoittavat, että toimittajan ei ole pakko niitä täyttää, mutta niiden täyttäminen tarkoittaa enemmän pisteitä vertailuperusteisiin ja sitä kautta paremmat mahdollisuudet voittaa kilpailutus

Yksittäisiä vaatimuksia - pakollisia ja pisteytettäviä - on yhteensä muutamia satoja.  Excel-taulukko sisältää noin 15 välilehteä, joihin on vaatimukset on luokiteltu aiheittain: Työterveyshuolto, Ajanvaraus, Ilmoittautuminen,  Lausunnot ja lähetteet jne. 

Ja on siellä sitten yksi välilehti nimeltään Käyttäjälähtöisyys. Alla kuvankaappaus taulukon ko. kohdasta.

Sisältäänkö tarjouspyyntö käytettävyysvaatimuksia?

Käytettävyys tarkoittaa lyhyesti ilmaistuna sitä, missä määrin käyttäjät onnistuvat saavuttamaan tavoitteensa. Tarkemmin käytettävyyden määritelmästä esimerkiksi täällä.

Kun tarkastelee "Käyttäjälähtöisyys" -vaatimuksia, niin useimmissa vaatimuksissa lukee, että jokin asia

• "pitää voida tehdä" 
• "pitää olla mahdollista" 
• "pitää päästä tekemään" 
• tms. 

Tällaiset muotoilut tarkoittavat yleensä toiminnallisia vaatimuksia eivätkä käytettävyysvaatimuksia. Ja nämä ovat eri asioita. 

Toiminnallinen vaatimus kertoo, millainen ominaisuus pitää järjestelmässä olla, kun taas käytettävyysvaatimus määrittää, missä määrin käyttäjien pitää onnistua järjestelmän käytössä. Se, että onko jokin vaatimus käytettävyysvaatimus vai toiminnallinen vaatimus, voidaan todeta yksinkertaisella kysymyksellä: 

Voiko vaatimuksen täyttää niin, että sen toteutus on vaikeakäyttöinen? 

Jos vastaus on kyllä, niin kyseessä ei ole käytettävyysvaatimus. 

Otetaan esimerkiksi yllä olevasta taulukosta vaatimus Käy_03: PTJ:ssä on sisäinen ohjeistus hakutoiminnolla. Kysytään sitten,  voiko kyseisen vaatimuksen täyttää siten, että toteutus on vaikeakäyttöinen? 

Vastaus on, että (tietenkin) voi. Vaikka ohjeet ja hakutoiminta ovat sinällään käyttäjän kannalta hyviä toimintoja, niiden olemassaolo ei ole itsessään sama kuin käytettävyys. Ne kun on periaatteessa mahdollista toteuttaa kuinka vaikeakäyttöisiksi.  

Huom. Tämä ei tietenkään tarkoita sitä, että toimittaja suunnittelisi ohjeiston tietoisesti vaikeakäyttöiseksi. Mutta jos tarjouspyyntö ei aidosti edellytä käytettävyyttä, niin se tarkoittaa, että toimittajan ei kannata kiinnittää käytettävyyteen huomiota, koska se lisäisi kehityskustannuksia ja sitä kautta huonontaisi mahdollisuuksia voittaa tarjouskilpailu. 

Ainoastaan taulokon viimeinen vaatimusta - Käy_36: Tutkimustulosten ja lähetteiden palautteiden siirtyy automaattisesti sijaistajalta seuraavalle sijaistajalle - voi pitää käytettävyysvaatimuksena. On tietenkin  parempaa käytettävyyttä, jos jokin toiminto tehdään automaattisesti ilman, että käyttäjän tarvitsee tehdä mitään. 

Jos ottaa esiin toisen piirteen vaatimuksista, niin yksi käyttäjäryhmä nousee ylitse muiden: peräti 8 vaatimuksen käyttäjäryhmä on pääkäyttäjät. Käytettävyyden kannalta tietenkin pitäisi keskittyä "tavallisiin" loppukäyttäjiin, joita tässä tapauksessa ovat työterveydenhuollon henkilökunta ja järjestelmää käyttävät yritysten edustajat. 

Pakolliset vaatimukset vs. pisteytettävät vaatimukset

Kun en ole työterveyshuollon asiantuntija, niin minun on vaikea arvioida, ovat kaikki pakolliset vaatimukset todellakin välttämättömiä. Tai toisaalta, ovatko jotkut pisteytettävät vaatimukset sellaisia, jotka pitäisivät olla pakollisia. Joka tapauksessa ne ovat nähtävästi hyödyllisiä, koska niistä saa vertailupisteitä.   

Yleisesti tällainen jako on vähän keinotekoinen. Parempi ratkaisu olisi yksinkertaisesti, että kaikki vaatimukset olisivat pakollisia. Ja pisteytettäviä vaatimuksia käytettäisiin vain hyvin harkitusti sellaisissa tapauksissa, joissa hyvin tullaan toimeen kyseisiä ominaisuuksia mutta joiden olemassa olosta kannattaa maksaa vähän enemmän. 

Muut vaatimuskategoriat

Tarjouspyynnössä on siis noin 15 samantyyppistä vaatimuslistaa kuin Käyttäjälähtöisyys -vaatimukset. 

Hyvin monessa julkisessa tarjouspyynnössä käytettävyysvaatimuksia on paljon muuallakin kuin mahdollisessa käytettävyysosiossa. Niin luultavasti tässäkin. Tätä blogia varten en käynyt systemaattisesti läpi muiden osioiden vaatimuksia, mutta esimerkiksi seuraavia käyttäjiin liittyviä osui silmään: 

• Käyttäjät voivat valita valmiin kalenteripohjan kalenterimallista tai luoda oman kalenteripohjan erilaisia aikatyyppejä käyttäen
• Ammattilainen voi tarkastella PTJ:n ajanvarausnäkymässä olevia aikatauluja esimerkiksi päivä- ja viikkokohtaisesti
• Lääkärillä on oltava tieto uudistamista odottavien lääkemääräysten uudistuspyynnön voimassaolosta

Nämäkin ovat siis käytännössä toiminnallisia vaatimuksia: järjestelmä voi täyttää tällaiset vaatimukset, vaikka ne olisivat vaikeakäyttöisesti toteutettu. 

Yhteenveto

Johtopäätös on, että Lappican tarjouspyyntö ei millään tavalla takaa, että valituksi tulisi sellainen järjestelmä, joka on esitetty tavoitteeksi tarjouspyynnön johdannossa: 

"helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava... Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla".

Mutta. Eipä tämä tarjouspyyntö ole sen huonompi käytettävyyden osalta kuin julkisen hallinnon tarjouspyynnöt yleensäkään. 

Ja itse asiassa tässä tarjouspyynnössä on hyviäkin puolia: 

• Tarjousten käsittely ei vie käytettävyyden osalta paljon resursseja - katsotaan vain, mitä tarjoajat ovat ruksanneet. Joissakin kilpailutuksissa käytettävyysvaatimusten osalta on hyvinkin raskaita testejä ilman, että lopputulos on sen kummempi. Hyvänä esimerkkinä pääkaupunkiseudun paikallisliikenteen matkakortin lukija, jossa massiivisista testeistä huolimatta lopputuloksessa oli jopa ihan perustason käytettävyysongelmia. Lue tästä lisää.

• Laatutekijöiden painoarvo vertailuperusteissa oli "vain" 40%. Hyvin laaditussa tarjouspyynnössä laatutekijöiden painoarvon pitäisi olla lähellä nollaa, joka tapauksessa korkeintaan 20%. Mutta pahimmillaan on tarjouspyyntöjä, joissa laatutekijöiden painoarvo on peräti 70%. (Päinvastoin kuin usein luullaan, laatu vertailutekijöissä nimenomaan ei takaa tuotteen laatua). Eli siinäkään mielessä tämä tarjouspyyntö ei missään tapauksessa ollut pahimmasta päästä. 

Mikä olisi oikea tapa sisällyttää käytettävyys tarjouspyyntöön?

Jotta tarjouspyyntö edellyttäisi aidosti käytettävyyttä, niin 

• Käytettävyys olisi sisällytettävä pakollisiin vaatimuksiin. Vain erityistapauksissa käytettävyyttä voisi olla valintakriteereissä, ja silloinkin korkeintaan pienellä painoarvolla. 
• Käytettävyysvaatimukset olisi määritettävä suhteessa käyttäjien suoriutumiseen.  Silloin, kun käyttäjät suoriutuvat tehtävistään riittävän hyvin, järjestelmä on käytettävyydeltään hyvä. 

Miten sitten määritetään käytettävyysvaatimukset suhteessa käyttäjien suoriutumiseen? Sitä varten tarvitsee määrittää

• mittarit: millä mittarilla mitataan käyttäjien suoriutumista
• tavoitetasot: mikä mittaustulos ko. mittarilla on riittävän hyvä
• mittausinstrumentit: miten mittaus käytännössä suoritetaan (yleensä tämä tarkoittaa käyttäjätestejä, mutta ei välttämättä)

Ja vielä pitää ottaa huomioon, että mitkä tahansa mittarit, tavoitetasot ja instrumentit eivät kelpaa. Käytettävyysvaatimusten on oltava

• valideja: vaatimusten on aidosti kuvattava haluttua käytettävyyttä
• riittävän kattavia: niin, että vaatimukset ottavat huomioon riittävästi erilaiset käyttäjät ja heidän erilaiset käyttötarpeensa
• (tähän luetteloon yleensä kuuluva todennettavuus tuleekin täytetyksi sitä kautta, että määritetään mittarit ja mittausinstrumentit)

Olen kirjoittanut näistä asioista useammassa tämän blogin kirjoituksessa, ja pitänyt myös kursseja. Ehkä kirjakin on tulossa tässä lähiaikoina. Yksi yhteenvetovideo tässä.  

--------

Vastaus Sepon alla olevaan kommenttiin 

(blogialusta ei antanut tehdä pitkää kommenttia, niin kirjoitan sen tähän): 

Seppo: "1. Jos järjestelmää ollaan vasta tilaamassa, eikä se ole millään tarjoajalla vielä valmiina, niin miten käytettävyyttä voi arvioida? Käytännössä kai nämä järjestelmät rakennetaan aika suurelta osin vasta sitten, kun tilaus on saatu. Järjestelmistä lienee yleensä olemassa ”backend” eli tiedostojärjestelmä, joka ehkä on joissain toimitetuissa järjestelmissä pohjalla, mutta itse näkyvä osa eli käyttöliittymä tehdään vasta, kun tilaajalta saadaan siihen toiminnalliset vaatimukset. Ja siten käytettävyyttä pystytään mittaamaan vasta jälkeenpäin. Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten”, mutta vertailua ei pysty tarjousvaiheessa tekemään."

Timo: Muutama huomio tähän: 

a) Tässä nyt on eri vaihtoehtoja, riippuen siitä, kuinka valmista järjestelmää ollaan tilaamassa. Tässä videossa selitän vähän asiaa https://www.youtube.com/watch?v=WJHHExdIwlU. 

"b) ”Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten””. Niin, mielestäni vaatimukset pitää olla toimittajia sitovia. Jos ei täytä vaatimuksia, tilaajan ei tarvitse hyväksyä toimitusta. En tiedä onko toimittajat tällaiseen tottuneet, mutta jos oikeasti halutaan käytettävyyttä edistää, niin jotain tällaista pitää tehdä. 

c) ”Vertailua ei pysty tarjousvaiheessa tekemään”. Niin, pointti on se että vertailuja ei tehdä. Vaan testataan, täyttääkö järjestelmä vaatimukset. Käytettävyys on siis pakollisena vaatimuksena. 

 

Seppo: "2. Tai sitten pitäisi jo tarjousvaiheeseen sisällyttää tehtävä, jossa tarjouskilpailuun osallistujan pitää toimittaa jokin ”sample”, jolle on annettu täsmälliset arviointkriteerit. Tässä on ainakin se ongelma, että jonkin pienen palikan tekeminen käytettäväksi voi olla helppoa verrattuna koko järjestelmään, koska sen ei silloin tarvitse toimia koko järjestelmän kanssa yhteen, mutta siinä ei silloin myöskään luultavasti näy, miten hyvä koko järjestelmä on käytettävyydeltään silloin, kun kaikki osat oikeasti ovat olemassa."

Timo: Tässä olet ihan oikeassa. Käytettävyysvaatimuksilla on kolme pääkriteeriä: niiden itää olla validit, todennettavat ja riittävän kattavat. Ja tuo jälkimmäinen tarkoittaa juuri sitä mitä kommentoit.

Seppo: "3. Käytettävyyskriteerien pitäisi olla hyvin tarkat, ja niiden pitäisi kattaa periaatteessa koko systeemi. Muuten tulos voi olla se, että vaaditut osat täyttävät vaatimukset, mutta muut osat ovat sutta ja sekundaa. Käytettävyys kun on asia, jossa jokaisen lenkin pitää olla kunnossa, tai homma ei toimi."

Timo: Kylläpä näin. Ks. edellisen kohdan kommenttini. 

Seppo: "Sitten hieman sivuun tästä tarjouspyyntöasiasta. Olen seuraillut näitä tietojärjestelmäuutisia ja lukenut myös tutkimusartikkeleita. On alkanut muodostua sellainen käsitys, että iso osa ongelmaa on siinä. että järjestelmissä on rakenteinen tietokanta, jossa kaikki diagnoosit ja muut tiedot pitää luokitella tarkasti. Tämä johtaa siihen, että käyttäjät saavat eteensä loputtomasti valikoita ja ruudukoita, joista pitää klikkailla oikeat vaihtoehdot, jotka sitten tallentuvat järjestelmään. Vaikka käyttöliittymäsuunnittelijat tietenkin pyrkivät tekemään kaikista näkymistä mahdollisimman käytettäviä, niin näkymiä on vain liikaa ja niissä liikaa läpi käytäviä kohtia. Tämä lomakkeiden täyttely vie kohtuuttomasti aikaa verrattuna vanhaan systeemiin, jossa lääkäri saneli potilaan epikriisin suoraan proosana. Tästä monimutkaisuudesta pitäisi päästä eroon, mutta kuitenkin niin, että järjestelmään tallentuisi täsmällinen tieto, joka myös olisi käytettävissä myöhemmin. Arvelen, että tekoäly jossain muodossa olisi tässä mahdollinen ratkaisu: lääkäri voisi sanella vastaanoton jälkeen potilastapaamiseen liittyvät asiat, ja tekoäly tulkitsisi ja muodostaisi sanelusta rakenteisen datan, jonka lääkäri sitten vain tarkistaisi, ja se menisi tietokantaan."

Timo: Ihan mielenkiintoisia ajatuksia. Itse kyllä olen ajatellut, että rakenteinen tietokanta on hyvä lähestymistapa. Ja olettanut, että paremmalla suunnittelulla ne voitaisiin saada käytettävyydeltään hyviksi. Mutta. Minulla ei ole käytännön kokemusta niistä, enkä osaa varmuudella sanoa mitään.