Sain palautetta vieraskynääni

Sain palautetta vieraskynääni Hesarin mielipidepalstalla 4.7, kirjoittajana Suomen taitohankinta Oy:n toimitusjohtaja Kari Annala. Ohessa linkki kirjoitukseen (koko kirjoitus näkyy valitettavasti vain Hesarin digilehden tilaajille).

Mielestäni Annala ehdottaa niitä asioita, joita tänä päivänä käytetään ja jotka vain eivät toimi. Kirjoitin vastineen Hesariin; katsotaan sitten, julkaistaanko se.

Palaan asiaan joka tapauksessa tarkemmin kesälomien jälkeen.

http://www.hs.fi/digilehti/mielipide/Tietoj%C3%A4rjestelm%C3%A4hankinnoissa+saa+sen+mit%C3%A4+osaa+pyyt%C3%A4%C3%A4/a1341292373075

Timon vieraskynä HS 1.7.2012: "Helppokäyttöisyyttä osattava vaatia"

Näin kesäloman alkajaisiksi Hesari julkaisi vieraskynäni: 

"Helppokäyttöisyyttä osattava vaatia. Tarjouskilpailussa päädytään liian usein tietojärjestelmään, joka on käyttäjilleen tuskallinen". 

Pääset lukemaan koko jutun osoitteesta: 

http://www.hs.fi/paakirjoitukset/Helppok%C3%A4ytt%C3%B6isyytt%C3%A4+on+osattava+vaatia/a1341031828126

Käytettävyys ja käyttäjäkokemus -tapahtuma 19.-20.9.12

Talentum Events järjestää kaksipäiväisen tapahtuman. Tarkempaa tietoa: http://www.talentumevents.fi/tapahtumat/conferences/kaytettavyys+ja+kayttajakokemus+12/a2099213

Käytettävyysseminaari 29.5.02

Vähän myöhään tämä ilmoitus mutta tule jos ehdit! http://www.sytyke.org/kaytettavyysosy/toiminta

Tarjouspyyntö ratkaisee HUSin uuden potilastietojärjestelmän helppokäyttöisyyden

Käytettävyys tulee määrittää oikealla tavalla tarjouspyyntöön, jos halutaan valita aidosti helppokäyttöinen potilastietojärjestelmä ja oikeasti päästä tavoitteeseen "hoitohenkilökunta voi käyttää enemmän aikaansa hoitotyöhön". 

Yle uutisoi viime viikolla HUSin uuden potilastietojärjestelmän kilpailuttamisesta. Jutussa todetaan nykyisistä järjestelmistä, että "suurimmat ongelmat liittyvät järjestelmien käytettävyyteen. Ne ovat moniportaisia ja hankalia. Työntekijä joutuu käyttämään aivan suhteettoman paljon aikaa tietokoneensa kanssa".

Uutisen mukaan ulkomaiset ohjelmistoyritykset ovat tulossa mukaan, kun HUS kilpailuttaa uutta potilastietojärjestelmää.

Ovatko ulkomaiset potilastietojärjestelmät sitten käytettävyydeltään parempia? Mahdollisesti - siitä minulla ei ole tietoa. Mutta vaikka olisivatkin, ei ole itsestään selvää, että "paremman käytettävyyden" järjestelmä tulee valituksi. 

Ratkaisevaa on se, miten käytettävyys sisällytetään potilastietojärjestelmän tarjouspyyntöön: miten käytettävyys on huomioitu tarjouspyynnön vähimmäisvaatimuksissa ja vertailukriteereissä. 

Julkisessa kilpailutuksessa järjestelmän tarjouspyyntö on ratkaisevassa asemassa. Tarjouspyyntö kun on käytännössä järjestelmän tilausdokumentti: se määrittää, millainen järjestelmä halutaan. Hankkijan tulee valita järjestelmä tarjouspyynnössä määritettyjen vähimmäisvaatimusten ja vertailukriteereiden perusteella.

Historia osoittaa, että käytettävyyttä ei osata määrittää julkisten tietojärjestelmien tarjouspyynnöissä aidoksi vaatimukseksi tai valintakriteeriksi. Sinällään se ei ole ihme, koska käytettävyyden aito vaatiminen on menetelmällisesti haastavaa.  (Näistä olen monessa aiemmassa yhteydessä kirjoittanut, ks. tämän blogin aiemmat kirjoitukset ja julkaisut.)

Miten käytettävyysnäkökulmat sitten olisi sisällytettävä potilastietojärjestelmän tarjouspyyntöön? Jos siis halutaan sellainen järjestelmä, että "hoitohenkilökunta voi käyttää enemmän aikaansa hoitotyöhön", niin kuin jutussa todetaan. Kaksi keskeistä asiaa: 

• Käytettävyys tulisi sisällyttää mahdollisimman pitkälle vähimmäisvaatimuksiin. Miksi näin? Logiikka on yksinkertainen: jos käytettävyys on pelkästään vertailukriteereissä, niin periaatteessa aina voi tulla valituksi järjestelmä, joka saa käytettävyydestä nolla (0) pistettä. Siis voi tulla valituksi järjestelmä, jonka käytettävyys on "nolla". 
• Koska käytettävyys tarkoittaa käyttäjien suoriutumista työstään, niin viime kädessä ainoa validi tapa määrittää käytettävyysvaatimukset tulee perustua käyttäjien suoriutumiseen työssään. 

Miten määrittää tällaiset käyttäjien työssään suoriutumiseen perustuvat vähimmäisvaatimukset tarjouspyyntöön? Lyhyesti sanottuna: tulee määrittää validit mittarit, mittausinstrumentit ja tavoitetasot. Ja jotta vaatimukset olisivat sisällöllisesti oikeita, vaatimusten määrittämisen perustaksi tarvitaan käyttäjien työn syvällinen jäsentäminen.

Käyttäjien työn syvällinen jäsentäminen on erittäin keskeinen toimenpide, joka kuitenkin käytännössä tehdään hankinnoissa kovin pintapuolisesti. Tämä tulisi tehdä ajoissa, ja sitä varten pitäisi varata resursseja. Ja välttää esimerkiksi sitä suodenkuoppaa, että käyttäjät (tai heidän edustajansa) laitetaan itse tekemään työnsä jäsennys.

- Tämän jutun puitteissa näiden asioiden seikkaperäinen kuvaus ei ole mahdollista.  Tarkempaa tietoa saa - kysymällä minulta.

Kokemuksia "Käytettävyys tietojärjestelmien hankinnoissa" -kurssista

Pidin ensimmäisen "Käytettävyys järjestelmien hankinnoissa" -kurssin maaliskuussa, http://www.ttlry.fi/koulutus/kaytettavyyden-varmistaminen-hankinnoissa-1232012.

Kurssin keskeinen sisältö oli esittää ratkaisuja sille, miten käytettävyys saataisiin aidosti mukaan tietojärjestelmien tarjouspyyntöihin: miten laatia todennettavia ja valideja käytettävyysvaatimuksia.

Kurssi oli täysi, 12 osallistujaa. Kaikki halukkaat eivät päässeet mukaan. Luultavasti 12 on sopiva maksimi määrä tällaiselle ryhmätyöintensiiviselle kurssille.

Sekä oman tuntuman että kurssilaisten palautteen perusteella kurssi meni ihan kohtullisesti. Varsinkin ottaen huomioon, että kurssi oli ensimmäinen laatuaan. Mutta parannettavaakin löytyi. Itse tiivistäisin palautteet ja oppimat seuraavasti:

• Aihe koettiin kiinnostavaksi ja harjoitukset ja case hyviksi, sekä kouluttaja asiantuntevaksi...;)
• Esityksessä hiomista
• Yksi päivä ei riitä tällaiseen sisältöön; mennään kuitenkin sekä käytettävyyden että hankintojen "syvällisyyksiin". Ehkä seuraavalla kerralla niin, että kaksi kurssipäivää; ehkä kaksi erillistä kurssia

Palataan asiaan uudestaan syksyllä!

--------------------------------------
Osallistujien palautteita

Hyvää:

• "käytettävyysopit hyviä & kiinnostavia"
• "ajatuksia ja ideoita siitä, miten käytettävyyttä voitaisiin ylipäätään parantaa"
• "erittäin mielenkiintoista tietoa"
• "kouluttaja käytettävyyden huippuasiantuntija", "erittäin hyvä asiantuntemus"
• "päivä avasi käytettävyyteen liittyvää problematiikkaa", "tuli selväksi, että asia on vaikea"
• "vetäjän tietämys"
• "ajattelutavan muutos"
• "harjoitukset olivat hyviä, sitä kautta asiat konkretisoituivat"
• "tapaukset, caset"

Kehitettävää:

• "kouluttajalla oli selvästi paljon enemmän asiaa kuin päivään mahtui, joten jonkunlainen jäsentely tulee varmaan tapahtumaan"
• "kouluttajan tapa esiintyä oli hieman pomppiva", "poukkoileva esitystapa", "sujuvampi esitystapa"
• "jättäisin harjoituksia vähemmälle"
• "harjoitusten toteutus vaatii vielä kehittämistä"
• "paljon asiaa, vähän aikaa"

Erään tarjouspyynnön käytettävyysanatomia, osa 1: Vähimmäisvaatimukset

Tämän tarkasteltun kohteena olevassa tarjouspyynnössä on määritetty käytettävyyteen liittyviä vähimmäisvaatimuksia (1) asiantuntijoille, (2) palvelulle ja (3) kehitysprosessille. Positiivista on, että käytettävyyteen on kiinnitetty monipuolisesti huomiota. Kuitenkin vähimmäisvaatimuksissa on merkittäviä puutteita sekä todennettavuuden että validiuden näkökulmasta.  Yhteenvetona on vaikea nähdä, miten näillä vaatimuksilla on merkittävyyttä käytettävyyden saavuttamisen näkökulmasta.

Toisaalta, kuten blogia seuranneet tietävät, käytettävyyden vaatiminen on aidosti haastavaa, eikä hyviä esimerkkejä juuri löydy.

(Osassa 2 tarkastellaan tarjouspyynnön vertailuperusteita)

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

Tarkastelun kohteena on Oikeushallinnon tietotekniikkakeskuksen tarjouspyyntö aloitepalvelun kehittämisestä. Ja siinä erityisesti se, miten käytettävyys on huomioitu.

Tämän analyysin tausta on se, että Teemu Ropponen tietotekniikkakeskuksesta "haastoi" minua arvioimaan tätä tarjouspyyntöä. Mikä on hieno asia, ja tekee toivottavasti lukijallekin asiasta mielenkiintoisemman ja konkreettisen; tarjouspyyntöhän on vielä julkisesti saatavilla. Aiemmin blogissani olen ottanut esimerkkejä anonyymisti (vaikka lukijoilla tietenkin on periaatteessa ollut mahdollisuus jäljittää alkuperäinen lähde). 

Tarjouspyynnössä on tavanomaiseen tapaan määritetty:

• vähimmäisvaatimukset: vaatimukset, jotka tarjoajan on täytettävä, jotta olisi mukana kilpailussa
• vertailuperusteet: näin perusteella valitaan voittava tarjous niiden joukosta, jotka täyttävät pakolliset vaatimuksen

Tässä kirjoituksessa ("osa 1") tarkastellaan sitä, miten käytettävyys näkyy vähimmäisvaatimuksissa. Omasta mielestäni vähimmäisvaatimukset on se "tärkeämpi" osa, koska valituksi voi periaatteessa tulla sellainen toimittaja, joka pelkästään täyttää nämä vähimmäisvaatimukset (ks. myös: http://hankikaytettavyytta.blogspot.com/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html)

Mitä tarjouspyynnön vähimmäisvaatimuksiin on kirjoitettu käytettävyydestä 

Löysin tarjouspyynnöstä seuraavia vähimmäisvaatimuksia: 

1. Asiantuntijoihin liittyvät vähimmäisvaatimukset

Edellytetään käytettävyysasiantuntijaa/ käyttöliittymäsuunnittelijaa, jolla "tulee olla vastaavasta tehtävästä vähintään kolmen vuoden kokemus… vuorovaikutteisen verkkopalvelun rakentamisesta". Kyseisellä palvelulla on oltava "vähintään 500 keskimääräistä käyttäjää päivässä ja vähintään 2 käyttökieltä". 

2. Palveluun liittyvät vähimmäisvaatimukset:
Toimittajan tulee sitoutua noudattamaan "liitteen 7 mukaisen palvelun". Ja liitteestä 7 löysin seuraavat palvelun käytettävyyteen liittyvät vaatimukset:

• Näistä seikoista johtuen järjestelmän käyttöliittymän on täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys- ja saavutettavuusvaatimukset.
• Koska kyseessä on verkkopalvelu, jota käyttää lukuisa määrä satunnaisia käyttäjiä (aloitteen tekijät), on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen, jotta se kannustaisi käyttäjiä sähköisten palveluiden käyttämiseen ja positiivisen kokemuksen saamiseen.
• Helppokäyttöisyys (huom. PETOn käytettävyysvaatimukset) sekä kansalaiselle että viranomaiselle
• Järjestelmä on rakennettava siten, että kannatusilmoitusten keräämisen käsittelysääntöjä on helppo muuttaa tarvittaessa (esim. on mahdollista että jossain vaiheessa kannatusilmoitusten keräämisen käynnistys muuttuu siten, että aloitteelle kerätään ensin OM:n verkkopalvelussa 50 kannatusilmoitusta, ja aloite tulee vasta sen jälkeen tarkistettavaksi OM:ään)
• Järjestelmän on tuettava aloitteen vireillepanijaa eri tyyppisten aloitteiden tekemisessä (ohjeet, pakolliset tiedot)
• Järjestelmän käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä.

3. Kehitysprosessiin liittyvät vähimmäisvaatimukset:
Liitteestä 7 löysin seuraavat kehitysprosessiin liittyvät vaatimukset: 

• Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti.
• Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa.

Vaatimusten arviointia

Tarkastelen vaatimuksia kahdesta näkökulmasta:

• todennettavuus: onko vaatimus määritetty siten, että sen täyttyminen voidaan tarkistaa niin, että ei tule erimielisyyksiä siitä, toteutuuko vaatimus vai ei (itse asiassa, josa vaatimus ei ole todennetava, niin se ei käytännössä ole vaatimus ensinkään)
• validius: onko vaatimus on sisällöllisesti oikea (= sen täyttyminen tarkoittaa, että sillä on aidosti vaikuttavuutta järjestelmän parempaan käytettävyyteen)

1. Henkilöihin liittyvät vähimmäisvaatimukset

• Vaatimus ("... vähintään kolmen vuoden kokemus...) on kohtuullisesti todennettavissa
• Mutta vaatimuksen validius on ongelmallinen: käyttöliittymä-/ käytettävyyskokemus kun sinällään ei takaa viime kädessä aitoa käyttöliittymäsuunnittelun tai käytettävyyden ammattitaitoa.  Käyttöliittymiä ja myös käytettävyysaktiviteetteja kun on voinut suorittaa ilman mitään alan koulutusta. Minun on myöskään vaikea nähdä, miten vaatimus "vähintään 500 käyttäjää" on relevantti käytettävyysasiantuntijan näkökulmasta?

Eli käytännössä tämä vähimmäisvaatimus ei edellytä ammattitaitoista käytettävyys-/ käyttöliittymäsuunnittelijaa.

2.  Palveluun liittyvät vähimmäisvaatimukset

•  "... täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys-.... vaatimukset". Tässä ei suoraan määritetä, mitä nuo vaatimukset ovat; ehkä JHS-suosituksiin?
  Joka tapauksessa, tämän tyyppisessä vaatimuksessa on kaksi ongelmaa. (1) Useimmat JHS-suositusten yksittäisistä vaatimuksista ovat luonteeltaan ei-todennettavia. (2) Tällaiset yleiset vaatimukset  - vakka olisivatkin todennettavia - yleensäkään eivät kata käytettävyydestä kuin ehkä 10 - 20%.
•  "... on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen", "helppokäyttöisyys.... sekä kansalaiselle että viranomaiselle", "käsittelysääntöjä on helppo muuttaa", "järjestelmän on tuettava aloitteen vireillepanijaa", "käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä". Tällä tavalla muotoillut "pyöreät" vaatimukset eivät ole todennettavia eivätkä siten varsinaisia vaatimuksia. 

3. Kehitysprosessiin

 liittyvät vähimmäisvaatimukset

• "Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti." Aluksikaan, en löytänyt noita käytettävyystestimäärittelyjä tarjouspyynnöstä. Mutta vaikka siellä sellaiset vaatimukset olisikin, niin niin käytettävyystestit sinällään eivät takaa mitään käytettävyydestä, toisin sanoen, niiden edellyttäminen ei ole validi vaatimus (tähän on montakin syytä, yksi esimerkiksi CUE-tutkimusten tulokset, ks.  http://hankikaytettavyytta.blogspot.com/2011/04/lahtokohta-kaytettavyyden-varmistus-ei.html). 

• "Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa". No, tätä ei oikein tulkitse vaatimukseksi ollenkaan, koska sen voi jokainen toteuttaa. Käytettävyystestaustahan on mahdollista tehdä hyvinkin keskeneräisellä järjestelmällä, jopa paperitasolla. 

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

Yhteenveto: ks. tiivistelmä ylhäällä.