perjantai 15. helmikuuta 2013

Näin hankitaan käytettävyyttä: päävaiheet

Olen monissa aiemmissa kirjoituksissani - vaikkapa edellisessä - tarkastellut kriittisesti tapoja, miten käytettävyyttä on yritetty ottaa huomioon tietojärjestelmien hankinnnoissa.

Millainen lähestymistapa olisi sitten toimiva ratkaisu?  Tässä esitän, miten hankinta pitäisi periaatteessa tehdä. Tämä pätee hankintoihin, jossa tarkoituksena on hankkia tietojärjestelmä, jotka perustuvat olemassa olevaan tietojärjestelmäratkaisuun ja jotka räätälöidään tai konfiguroidaan asiakkaan tarpeiden mukaan. Tällaisia ovat usein esimerkiksi matkanhallinta-, HR- ja CRM-järjestelmät. (Asiakaskohtaisesti kehitettävän järjestelmän hankkiminen on sitten eri tapaus).

  1. Perustaksi on tärkeä määrittää, miten tärkeää käytettävyys on hankittavassa järjestelmässä (tämä pätee tietenkin kaikkiin tietojärjestelmien kehityshankkeisiin, ei vain hankintoihin). Tässa vaiheessa asetetaan tavoitteet, millaista vaikuttavuutta käytettävyydeltä halutaan: mitä etuja halutaan saavuttaa, mitä riskejä välttää. 
  2. Keskeinen toimenpide on sitten selvittää markkinoilla olevien vaihtoehtojen potentiaalinen käytettävyys ennen kilpailutusta, niin että tiedetään, että minkätasoisia tarjolla olevat järjestelmät ovat käytettävyydeltään suhteessa asetettuihin tavoitteisiin. Jos käytetään neuvottelumenettelyä, niin tämä vaihe voitanee tehdä neuvotteluvaiheessa. 
  3. Sitten varsinaista kilpailutusta (tarjouspyyntöä) suunniteltaessa tiedetään, onko yleensäkään tarjolla järjestelmiä, joissa on halutun tasoinen käytettävyys. Jos on, niin kilpailutus käyntiin. Jos ei, niin voidaan harkitaan, hankitaanko "huono" järjestelmä, kehitetäänkö uusi omien tarpeiden mukaan, vai mitä tehdä. Jos kilpailutetaan, niin ainakin tiedetään jo etukäteen, mikä on olemassa oleva taso. 
  4. Sitten varsinaisessa kilpailutuksessa käytettävyys tulisi laittaa pakollisiin vaatimuksiin (miksi: katso tästä ja tästä). Tässä vaiheessa pitäisi siis olla jo tiedossa, että on olemassa järjestelmiä, jotka täyttävät nämä vaatimukset. 
Tämä malli on mielestäni looginen (vai ajatteleeko joku toisin?). Kuitenkin kun tarkastelee julkisia tarjouspyyntöjä, niin havainto on, että käytännössä ei toimita näin. Sen sijaan toimitaan siten, että käytettävyyttä arvioidaan vasta kilpailutusvaiheessa sen jälkeen, kun on saatu tarjoukset. Tällöin mennään kilpailutukseen väkisin vähän riskillä, kun ei tiedetä, millaista laatua vaihtoehdot edustavat (ajatteleeko tästä joku toisin?)


En väitä, että kuvaamani prosessi on helppo. Esimerkiksi vaiheessa 2  pitäisi arvioida järjestelmiä, joista voi paljolti puuttua käyttäjärajapinnan yksityiskohdat (koska ne sitten luodaan räätälöinnin yhteydessä). Arvioinnissa siis pitäisi pystyä selvittämään, mikä on perusratkaisun käytettävyys, siis millaisen käytettävyyden voi perusratkaisun pohjalle kehittää. 

Tällaisessa tilanteessa käyttäjäpohjaiset käytettävyysarvioinnit eivät tule kysymykseen. Itse näen, että riittävän syvään substanssiymmärrykseen perustuva asiantuntija-arviointi on ratkaisu. Ja tässä on tuon substanssiymmärryksen hankkiminen se ensiarvoisen tärkeää (minun käyttämäni menetelmä substanssiymmärryksen saamiseksi on ExposeThings). 

Tämän jälkeen siis tehdään vaihtoehtojen käytettävyysarvioinnit asiantuntijan silmin. Se, miten tämä tehdään, on oma lukunsa. Joka tapauksessa voi sanoa, että demoesittelyissä (joita hankinnoissa harrastetaan paljon) tällaiset asiat eivät kyllä selviä, vaan järjestelmään on päästävä tutustumaan syvällisemmin. 

Minun tietääkseni esittämääni tapaa käytettävyyden huomioimiseen ei ole käytetty (vai tietääkö joku?) Avoimissa tarjouspyynnöistä (joita olen käynyt läpi varmaan pari sataa) en ole tällaista nähnyt; "suljettuja" neuvottelumenettelyjä en tietenkään ole voinut seurata. 

Omasta mielestäni tietenkin tällaista lähestymistapaa kannattaisi käytettävyydestä aidosti kiinnostuneen hankkijan kokeilla. Sen voin sanoa, että ihan oikeasti en tiedä, mikä olisi jokin toinen toimiva vaihtoehto. Jos jollakin on idea tai eri näkemyksiä, niin ehdottomasti saa haastaa!