Sähköisten palvelujen käytettävyys on pitkä prosessi, päivitys 8.1.2016

Tietoasiantuntija-lehti 5/2015

Digitaalisten palvelujen käytettävyydestä tein jutun Tietoasiantuntija-lehden vuoden 2015 viimeiseen numeroon. Itse asiassa halusin otsikoksi tuon "sähköiset palvelut". Termiä pidettiin vanhanaikaisena. Olkoon tässä nyt molemmat otsikot. (1)

Sähköisten palvelujen käytettävyys pitkä prosessi

Sähköisten palvelujen käyttäjäkokemus on armoton mittari avoimilla markkinoilla. Väitetään, että yli 90% prosenttia palvelujen käyttäjistä hylkää palvelun, jos käyttäjäkokemus on huono. Henkilö siirtyy siis kilpailijan palveluita käyttämään. Käytettävyyden ydin on tuottaa asiakkaalle arvoa. Itse asiassa pitäisi aina verrata omaa palvelua parhaaseen mahdolliseen. 

Oppiminen. (2) Käytettävyydessä on useita komponentteja, jotka vaikuttavat palveluun. Palvelu voi olla käyttäjälleen vaikea oppia. Tässä on kolmentyyppisiä ihmisryhmiä: diginatiivit (digitaalisuus luonnollinen osa elämää, Y- ja Z-sukupolvet), digi-imigrantit (digitaalisuutta opeteltu aikuisiällä, myös perinteistä palvelu- ja mediavalikoimaa käytetään) ja digiressistantit (digimaailman ulkopuolisia orpoja). Kolmas ryhmä tarvitsee apua digi-imigrantilta tai diginatiivilta.  Diginatiivi solahtaa palveluun helposti, mutta osaa olla myös kriittinen. 

Luotettavuus. Käytettävyys on myös luotettavuutta. Palvelun pitää toimia periaatteessa 24x7. Muuten hukka perii. Luotettavuutta on myös se, että palvelun lopputulos on odotettu – ei synny väärinymmärryksiä. Luotettavuutta on myös, että palvelu ei sisällä virheitä tai vikoja. Virheet, viat ja häiriöt kielivät siitä, että ohjelmistossa on jotain vikaa. Virhe voi olla kriittinen, jolloin järjestelmää ei voi käyttää. Virhe voi estää myös jonkin pakollisen toiminnon toimimasta. Tai virhe voi hidastaa toimintoja.

Toimintatapojen muutos. Käytettävyys liittyy myös toimintatapojen muuttamiseen. Siirtyminen paperipohjaisesta toimintatavasta digitaaliseen toimintatapaan merkitsee myös uuden oppimista. Kyse on uuden oppimisesta koko palveluketjussa. Esimerkiksi terveydenhuollon alueella tehdyssä väitöskirjassaan Maija Valta tiivistää onnistumisen seuraaviin tekijöihin: 1. inhimilliset tekijät: oppiminen, kokonaisuuksien hallinta ja asenteet, 2. organisaatiotekijät: muutosjohtajuus, koko organisaation sitoutuminen., 3. teknologia: työasemat ja myös palvelinalustan on oltava suorituskykyisiä ja luotettavia, 4. työssä tapahtuvat muutokset: muutos työtehtävissä on tiedostettava ja varmistettava osaamispohja. (3)

Projektien onnistuminen. Käytettävyys on avainsana myös toiminnan muutosprojekteissa ja IT- projekteissa. Itse asiassa digimaailmassa ei enää tarvitse puhua erikseen IT- projekteista ja toiminnan muutosprojekteista. Kyse on aina samasta asiasta – toimintaa muutetaan. Projekteissa on aina kyse innovaatioista, uusista toimintatavoista, joiden toteutuksessa uusilla IT- järjestelmillä on ratkaiseva välinerooli. Käytettävyys lähtee liikkeelle hankintaprosessista eli miten tilaaja kykenee tuomaan riittävän yleisesti ja yksityiskohtaisesti muutostarpeet esille. Toisaalta toimittajan pitäisi kyetä tilaajan kanssa vuorovaikutuksessa rakentaa toiminnan muutosta tukeva IT- ratkaisu. Projektissa on aina kolme kovaa komponenttia: lopputulostavoite, aikatavoite ja kustannustavoite. Nämä muodostavat samalla keskeiset riskit. Nopeasti, vähillä resursseilla ja pienillä uudistuksilla saadaan aikaan minimitulos. Vaarana on tulla sutta ja sekundaa. Jos voidaan aikajanaa ja kustannuskattoa ylittää, saattaa olla myös mahdollista innovatiivisempi lopputulos. Vaarana on tulla ikuisuusprojekti, jossa rahapiikki on auki. 

Innovatiivisuus. Työteon tavat vaikuttavat myös projektiin. Ns. vesiputousmalli on perinteinen tekotapa ja omalla tapaa myös ennustettava. Uusi tietojärjestelmä rakennetaan selkeiden vaiheiden varaan: määrittely, suunnittelu, toteutus, testaus, ylläpito. Usein tilaaja tekee määrittelyvaiheen, jonka perusteella tehdään sitten tarjous. Hinnan ja laadun perusteella sitten tilaaja tekee valinnan.   Tekotapa ei ole kovin innovatiivinen eikä salli matkan varrella suuria muutoksia määrittelyyn verrattuna. Ketterät menetelmät ovat ajan sana. Lopputulos on määritelty väljästi, jolloin rakentaminen jaotellaan paketteihin (sprintteihin). Paketti kerrallaan edetään rakentamisessa vuorovaikutuksessa tilaajan ja tuottajan välillä. Tekotapa toimii hyvin, jos voidaan joustaa kustannuksissa ja aikataulussa. Kiinteä kustannus johtaa helposti ongelmiin tekemisen laadussa ja lopputuloksissa. Niin on tietysti myös kolmas tie eli vesiputouksen ja ketterän ristisiitos. (4)

Testaus ja auditointi. Käytettävyys edellyttää projektissa systemaattista testausta ja arviointi/auditointimenettelyä. Molemmat tehtävät pitää tehdä kahdella tapaa: palvelun rakentajan itsetestauksena ja itsearviontina (-auditointina) sekä ulkoisena testauksena ja arviointina (-auditointina). Auditointi kohdistuu ennen muuta teknisiin ratkaisuihin ja tietoturvaratkaisuihin. Testaus kohdistuu palvelun luotettavuuteen, toimivuuteen ja käytettävyyteen. Jos pelisääntöjä tilaajan ja tuottajan välillä ei ole sovittu alkutaipaleella, saattaa syntyä melkoisia ristiriitoja. Testauksia on kolmea tyyppiä. Yksikkötestaus varmistaa, että juuri tehty toiminto, moduli toimii. Integrointitestaus varmistaa, että järjestelmän eri toiminnot ovat yhteensopivia. Järjestelmällä saattaa olla myös (ja pitää yleensä olla) runsaasti liittymiä muihin järjestelmiin. Järjestelmätestaus varmistaa kokonaistoiminnnallisuuden. Kuormatestaus varmistaa sen, että järjestelmä toimii moitteetta suuren yhtäaikaisen käytön aikana. Hyväksymistestaus on se viimeinen vaihe, jossa varmistetaan, että järjestelmä toimii vaatimusten mukaisesti. Testauksella pitää olla laatukriteerit, jotka jakaantuvat tekniseen laatuun, asiakkaan kokemaan laatuun (usein myös hinnan ja laadun suhteeseen).

Kokonaisarkkitehtuuri. (5) Käytettävyys ja käyttäjäkokemus tulee linkittää yhteen kokonaisarkkitehtuuriajattelun kanssa. Kokonaisarkkitehtuurissa on neljä komponenttia: toiminta – tieto – tietojärjestelmä – teknologia. Lisäksi kokonaisarkkitehtuuriin liittyy yli neljän komponentin menevä tietoturva. Kokonaisarkkitehtuuri kannattaa kytkeä muutosprosessin kaikkiin vaiheisiin: muutostarpeen arvioinnista aina uuden palvelun käyttöönottoon. Se on osa organisaation muutosjohtamista. Kokonaisarkkitehtuuriin kuuluu myös keskeisenä osana dokumentaatio. Se on myös tie riskien minimointiin sekä mahdollisten riskien realisoituessa nopeisiin korjaustoimenpiteisiin. Käytettävyyden kannalta tulee esille seuraavia tekijöitä:

Toiminta: On selvitettävä asiakkuudet ja erilaiset asiakassegmentit. On löydettävä toiminnan muutokselle asiakkaan kannalta arvo. On käytävä läpi toimintaprosessit – niin ulkoiset kuin sisäisetkin. On haastettava vanhat paperipohjaiset toimintaprosessit. On jo alkuvaiheessa sitoutettava johto ja henkilöstö muutokseen.

Tieto: Kertakirjaus on yksi pääperiaate. Toinen pääperiaate on, että hyödynnetään jo olemassa olevaa tietoa (master-rekisterit). Kolmas periaate on, että käytetään mahdollisimman pitkälle jo standardoituja määrityksiä ja luokituksia. Ja vielä on otettava huomioon tiedon kaksi puolta – varsinainen tieto ja metatieto.

Tietojärjestelmä: Tietojärjestelmän tulee olla teknisesti avoin, mutta toiminnallisesti tietoturvallinen. Kaikki eivät pääse kaikkialle. Tietojärjestelmän tulee olla rakennettu siten, että sitä voidaan muuttaa ja kehittää tarpeiden mukaan ja riippumattomasti tietojärjestelmän rakentajasta. Tietojärjestelmän omistajuus on oltava selkeä.

Teknologia: Teknologian pitää olla luotettavaa ja rakennettu tietojärjestelmän tarpeiden mukaan. Ylläpidon periaatteet on jo määriteltävä tilausvaiheessa. Teknologiaan liittyy myös tietoturvavaatimukset, jotka muodostuvat tiedon arkaluontoisuuden perusteella. Teknologiaan liittyy myös tietovirtojen luotettavuus.

Tietoturva on läpimenevä periaate toiminnasta tietoon, tietojärjestelmiin ja teknologiaan. Luottamus tietoturvaan lisää palvelun käytettävyyttä. 

Yhteispeli. Käytettävyyteen liittyy monenlaista asiantuntijuutta, jotka on osattava linkittää yhteen. Jotta kaikki vaatimukset täyttyvät, on muutoksen organisointi alusta loppuun avainasia. Muutoksella pitää olla vastuullinen tekijä/organisaattori/projektipäällikkö. On myös oltava alusta loppuun keskinäinen ymmärrys ja yhteistyö eri osapuolten välillä. Käyttäjien on kyettävä tuomaan esille tarpeet ja toteuttajien on kyettävä tuomaan esiin ratkaisuvaihtoehdot. Yhteispelillä se sujuu.

Päivitys 4.1.2016: LinkedInin puolelta tuli hyviä kommentteja:

• Ilkka Tengvall Tässä sattumoisin esimerkki tältä aamulta. Vantaan terveyspalveluiden portaali ajanvaraukselle on tillin tallin. Kun palvelu tehdään, pitäisi myös valvonta ja operointi olla kunnossa. Koska nettivaraus ei toimi, tunti puhelinjonossa on näemmä lyhyt aika. Korjataanpas tälläiset prosessit kuntoon että digipalveluilla olisi edes toivoa saada suosiota. Puhumattakaan etuja käytettyyn rahaan nähden. https://eterveys.vantaa.fi/portal 

• Pekka Saarinen Olli: täydennys artikkeliin. Testaus ja auditointi-kappaleesta puuttuu järjestelmätestaus. Siinä testataan tietojärjestelmää kokonaisuutena, joten kyseessä on kehitystyön lopputuloksen kannalta kriittisin testausvaihe.

• Timo Ruohomäki Digisähköisten palvelujen käytettävyydessä ei tule myöskään unohtaa kuormatestausta. On ihan arkipäivää, että vaikkapa lain muuttuessa järjestelmä kohtaa tiettynä aamuna hyvin huomattavan käyttökuorman ja selaimella käytettävän järjestelmän tulisi käyttäytyä järkevästi. Tämä liittyy sekä integrointi- että hyväksymistestaukseen.
  Toinen hyvä suuntaus liittyen osittain kokonaisarkkitehtuuriin olisi se, että tavoiteltaisiin eri verkkopalveluissa yhtenäistä käyttökokemusta, "look&feel". Ainakin Yhdysvalloissa ja Australiassa julkinen sektori on julkaissut omat, yksityiskohtaiset human interface guidelines -ohjeistuksensa niin käytännöllisellä tasolla, että paketista löytyy valmiit ikonigrafiikat ja väriskeemat. Käyttäjä kokee hämmennystä jos esimerkiksi palveluun rekisteröityminen tapahtuu täysin erinäköisessä (ja pahimmillaan erikielisessä, terveisiä valtiolle.fi) käyttöliittymässä kuin itse palvelun käyttö

Päivitys 8.1.2016: LinkedInin puolelta tuli hyvä muistutus:

Timo Savolainen Tärkeä aihe! Asiakkaan polkuja kuvaamalla pääsee nopeasti kehittämään prosesseja ilman, että keskustelu menee liian tekniseksi.

Viitteet

(1) Olli Nylander: Digitaalisten palvelujen käytettävyys on pitkä prosessi, Tietoasiantuntija - lehti 5/2015, ss. 20-22. 

(2) Kai Koskela, Vesa Ilmarinen: Digitalisaatio. Yritysjohdon käsikirja, Talentum 2015

http://ollintuumailut.blogspot.fi/2015/09/digiagenda-sotemaailmaan.html 

(3) Maija Valta: Sähköisen potilastietojärjestelmän sosiotekninen käyttöönotto: seitsemän vuoden seurantatutkimus odotuksista omaksumiseen. Itä-Suomen yliopisto, 2013
http://ollintuumailut.blogspot.fi/2013/09/it-hankkeissa-voidaan-onnistuakin.html 

(4)  Jussi-Pekka Kasurinen: Ohjelmistotestauksen käsikirja, Docendo 2014

http://ollintuumailut.blogspot.fi/2014/04/ohjelmistotestaus-osa.html 

(5) Kokonaisarkkitehtuuri:  

Kokonaisarkkitehtuurista (VM:n malli)  kirjoitin taannoin blogikirjoituksen, josta tässä on ote: ”Kokonaisarkkitehtuuri on hyvä renki mutta huono isäntä. Kokonaisarkkitehtuurin pitää olla osa johtamisjärjestelmää ja johtamiskulttuuria. Toiminta, tieto, tietojärjestelmät ja teknologia pitää olla vuorovaikutuksessa keskenään. Samoin on tietoturvan kehittämisessä. Tieto on "öljy", joka pistää moottorit käyntiin. Suunta ja tarkoitus pitää olla selvä.” http://ollintuumailut.blogspot.fi/2014/12/kokonaisarkkitehtuuri-osaksi-johtamista.html