sunnuntai 5. toukokuuta 2013

Positiivinen SUS (System Usability Scale) suomeksi

Positiivisen SUS -skaalan on todettu antavan yhtä luotettavia tuloksia kuin perinteisen SUS -skaalan, mutta on helpompi täyttää (ja sitä kautta käytettävämpi!). Ks.  http://www.amazon.com/Quantifying-User-Experience-Practical-Statistics/dp/0123849683/ref=la_B006LTIRUO_1_1?ie=UTF8&qid=1367820523&sr=1-1.

Kyselyähän käytetään käytettävyystestisession jälkeen mittaamaan koettua käytettävyyttä.

Kyselyt ovat kuitenkin herkkiä käännöksille. Alla on oma käännökseni. Pyydän itse kutakin antamaan palautetta käännöksestä: jos näette käännöksessä ongelmia tai teillä on ehdotuksia, miten parantaa käännöstä. 



1
I think that I would like to use this website frequently          
Luulen, että mielelläni käyttäisin tätä verkkosivustoa usein.
2
I found the website to be simple.
Huomasin verkkosivuston olevan yksinkertainen.
3
I thought the website was easy to use.
Ajattelin, että verkkosivuston käyttäminen on helppoa.
4
I think that I could use the website without the support of a technical person
Luulen, että osaisin käyttää verkkosivustoa ilman teknisen henkilön opastusta.
5
I found the various functions in this website were well integrated.
Huomasin verkkosivuston eri toimintojen toimivan hyvin yhteen.
6
I thought there was a lot of consistency in this website.
Ajattelin, että verkkosivuston eri osat toimivat keskenään samalla tavalla.
7
I would imagine that most people would learn to use this website very quickly.
Luulen, että useimmat oppivat verkkosivuston käytön erittäin nopeasti.
8
I found the website very intuitive
Mielestäni verkkosivuston käyttö oli erittäin intuitiivista (oli helppo arvata, miten verkkosivustoa käyttää)
9
I felt very confident using the website
Tunsin itseni hyvin varmaksi, kun käytin verkkosivustoa.
10
I could use the website without having to learn anything new
Osaisin käyttää verkkosivustoa ilman, että minun täytyy opetella mitään uusia asioita.

maanantai 4. maaliskuuta 2013

Esimerkki: Jos haluaa laatua, niin hinta tarjousten valintaperusteeksi!

Jos haluaa laatua, niin laatu pakollisiin vaatimuksiin ja hinta päävertailukriteeriksi.

Tästä olen kirjoitellut aiemminkin: käytettävyys (ja laatu yleisemminkin) pakollisiin vaatimuksiin eikä vertailukriteereihin tarjouspyynnöissä: http://hankikaytettavyytta.blogspot.fi/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html

Vielä esimerkin valossa, miksi näin. Jatkuvasti näkee tarjouspyyntöjä, joissa tämä ei toteudu. Toisaalta kukaan ei ole pystynyt minulle osoittamaan vääräksi sitä yksinkertaista päättelyä, miksi laatu pitäisi olla pakollisissa vaatimuksissa. Kuvaan vielä asian esimerkin kautta. 

Oheisessa taulukossa erään tarjouspyynnön vertailukriteerit; aika paljon näkee tämän tyyppisiä. Hinnan painoarvo on 40% ja laadun 60%. Vertailukriteerit tarkoittavat siis sitä, että pakolliset vaatimukset täyttävistä toimittajista valitaan tarjouskilpailun voittajaksi se, joka saa vertailukriteereistä eniten pisteitä. 


Valituksi tulee siis toimittaja, joka saa korkeimmat pisteet. Pisteet lasketaan periaatteessa mekaanisella yhteenlaskulla: lasketaan kunkin tarjouksen vertailukriteereistä saadut pisteet yhteen. Korkeimman pistemäärän saanut tarjous voittaa ja on valittava. Piste. 

Nyt kun laatu on vertailukriteereissä, niin ongelma on se, että valituksi voi tulla toimittaja, joka saa joiltakin laadun alueilta "nollan". Toisin sanoen, asiakas ei saa siltä osa-alueelta minkäänlaista laatua. 


Tämän esimerkin vertailukriteereissä käytettävyyden ("kokonaiskäytettävyys") painoarvo on 16%. Nyt voi olla täysin mahdollista, että valituksi voi tulla toimittaja, joka saa käytettävyydestä "nollan", jos se saa korkeat pisteet muilta osa-alueilta.

Eikä tämä siis koske pelkästään käytettävyyttä vaan myös muita laatukriteereitä. Esimerkin vertailukriteereissä "toimittajan kokemus ja projektiosaaminen" on painoarvolla 5%. On siis tosi suuri mahdollisuus, että valituksi voi tulla toimittaja, joka saa kokemuksesta ja projektiosaamisesta "nollan". Kelpaako tällainen toimittaja ihan oikeasti järjestelmän hankkijalle?

Yhteenveto: jos haluaa laatua, niin laatu pois vertailukriteereistä ja laatu pakollisiin vaatimuksiin, ja hinnan ratkaista valinnnan (siis hinta on 100%). Niin oudolta kuin se aluksi ehkä kuullostaakin. (Valintakriteereissä voi toki olla jonkin verran "ylimääräistä" laatua; mutta näkisin, että hinnan painoarvon olisi yleisesti oltava vähintään 80%). 

"Se ei toimi", ei kirkossakaan

Kirkon uusi Kirjuri-jäsentietojärjestelmä on aiheuttanut pöhinää kirkon sisällä, ainakin Kirkko & kaupunki -lehden pääkirjoituksen (lue tästä) (html) mukaan: "Järjestelmässä ei olekaan kuin yksi vika. Se ei toimi". 




Itse kommentoin mielipideosastolla jutulla (lue tästä), jonka sisällöllä ei varmaan yllätä tämän blogin lukijoita. Vaikka en hankintaa tarkemmin tunne, niin valistunut arvaukseni on, että ongelma on ollut järjestelmän (kehittämisen) kilpailuttamisessa.  



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!  

tiistai 11. joulukuuta 2012

Yksi vaikeakäyttöinen järjestelmä lisää kouluihin?

Katso asiaan liittyvä kirjoitukseni Opettaja-lehden numerossa 50/2012: http://www.opettaja.fi/pls/portal/docs/PAGE/OPETTAJALEHTI_EPAPER_PG/2012_50/page10.htm)

Kuntien Tiera Oy:n oppimisympäristön hankintailmoituksessa käytettävyys on korostetusti esillä mutta siten, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto. 

Kuntien Tiera Oy on julkaissut hankintailmoituksen sähköisestä oppimisympäristöstä: http://www.hankintailmoitukset.fi/fi/notice/view/2012-061560/. Kuntien Tiera kilpailuttaa oppimisympäristöä "edelläkävijäasiakkaille", jotka hankintailmoituksen mukaan ovat ns. kuumakuntia: Järvenpää, Mäntsälä jne. 


Hankintailmoitus on osallistumispyyntö rajoitettuun neuvottelumenettelyyn, eli siinä haetaan rajoitettu määrä toimittajia, joiden kassa neuvotellaan. Neuvottelujen perusteella sitten Kuntien Tiera laatii tarjouspyynnön, joka ei ole julkinen eikä sitä siten pääse näkemään. 


Hankintailmoituksen käytettävyyssisältö


Hankintailmoitus ei siis sisällä tarjouspyyntöä.  Kuitenkin hankintailmoituksessa kerrotaan, miten käytettävyys aiotaan huomioida tarjouspyynnössä.  Hankintailmoituksessa lukee: 

-------------------
"7. Käytettävyyden testaus osana tarjousten vertailua

Tarjottujen tuotteiden käytettävyys tullaan testaamaan osana tarjousten arviointia tarjousten vastaanottamisen jälkeen. Niille toimijoille, joille tarjouspyyntö lähetetään, tulee tarjota demo- tai vastaava ympäristö ja tarvittava määrä käyttäjätunnuksia käytettävyyden testaamista varten viikolle 6. Testausta tullaan tekemään alakoulu- yläkoulu- ja lukiotasolla. Käytettävyystestaukselle vaadittavat järjestelyt kuvataan tarkemmin tarjouspyynnössä.

Käytettävyys on vain osa tarjousten kokonaistaloudellisuuden arviointia. Vertailuperusteet kuvataan täsmällisesti tarjouspyynnössä."
--------------------

Vaikka kuvaus on aika suppea, siitä selviää keskeiset periaatteet: käytettävyys on osa vertailuperusteita, ja vertailu tehdään demojen käytettävyystestauksilla.

Ensi silmäyksellä voi saada kuvan, että kilpailutuksessa pärjää sellainen oppimisympäristö, jonka käytettävyys on hyvä tai paras. Näin kuitenkaan ei ole. Itse asiassa kuvatulla menettelyllä on aika sattumanvaraista, millainen valitun oppimisympäristön käytettävyys on, niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin. Alla tarkempi analyysi. 

Hyvää


Aloitetaan hyvästä puolesta. Hyvää on se, että lähestymistapa perustuu käyttäjien suoriutumisen arviointiin. Ja tämä on oikea tapa. Käyttäjien suoriutuminen on viime kädessä ainoa validi käytettävyyden kriteeri. 

Ongelmia


Hankintailmoituksen käytettävyysosion ongelmat ovat sen kummatkin keskeiset periaatteet: (1) käytettävyys on osana vertailuperusteita, ja (2) määrällinen käytettävyystesti tehdään demoilla. Kumpikin näistä piirteistä yksistään riittäisi siihen, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto.

(1) Käytettävyys osana vertailuperusteita

Ongelma hankintailmoituksen lähestymistavassa on se, että käytettävyys (laatu) on vertailuperusteissa eikä pakollisissa vaatimuksissa. Jos aidosti halutaan käytettävyyttä (tai muuta laatua), käytettävyyden (laadun) paikka on pakolliset vaatimukset eikä vertailuperusteet.

Kun käytettävyys on vertailuperusteissa, periaatteessa valituksi aina voi tulla oppimisympäristö, jonka käytettävyys on "nolla" (jos kyseinen vaihtoehto on vahva muissa valintaperusteissa). Tästä olen kirjoittanut useasti aikaisemmin esim. http://hankikaytettavyytta.blogspot.fi/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html

(2) Määrällinen käytettävyystesti demoilla 

Aluksikin, kun käytettävyyttä verrataan, niin kyse on määrällisestä käytettävyystestauksesta, koska tuloksena tarvitaan arvosanoja. Yleisin käytettävyystestauksen muoto on laadullinen testaus, jonka tavoitteena on löytää suunnitteluongelmia (ja -vahvuuksia) järjestelmästä. Mutta tästähän ei vertailutyyppisessä testauksessa voi olla kyse, vaan siis määrällisestä testauksesta. 

Määrällisessä käytettävyystestauksessa mitataan käyttäjien suoriutumista annetuista tehtävistä. Ja vertailutilanteessa tasapuolisen kohtelun vuoksi käyttäjiä ei saa auttaa tms., vaan käyttäjien on suoriuduttava tehtävistä täysin itsenäisesti. 

Määrällisessä käytettävyystestauksessa on tyypillistä, että käyttäjien suoriutumiseen voi vaikuttaa merkittävästi pieni yksityiskohtaisen tason suunnitteluratkaisu. Käyttäjän suoritus saattaa pysähtyä esimerkiksi siihen, että käyttöliittymässä on termi, jota käyttäjä ei ymmärrä.

Kun demot eivät ole yksityiskohdiltaan lopullisia järjestelmiä, niin niissä tällaisia "viilaamattomia" suunnitteluratkaisuja voi olla useitakin. Sen vuoksi demo saattaa saada määrällisessä käytettävyystestissä huonot pisteet, vaikka käyttäjälle ongelmia aiheuttavia piirteitä ei olisikaan lopullisessa toteutuksessa ja perustaltaan järjestelmä olisi muutenkin käytettävyydeltään hyvä.

Tämän vuoksi demojen määrällinen käytettävyystestaus ei ole validi menetelmä.  Siinä mitataan demon käytettävyyttä, ja testitulos voi olla ihan eri kuin jos olisi testattu lopullista järjestelmää. Huonot pisteet voi saada järjestelmä, jonka lopullinen toteutus olisi käytettävyydeltään korkealuokkainen.

Olen kirjoittanut asiasta aiemminkin, esim.  http://hankikaytettavyytta.blogspot.fi/2011/05/vertaileva-kaytettavyystestaus-demoilla.html.

- Ja vielä yksi käytännön näkökulma. Hankintailmoituksen mukaan rajoitettuun menettelyyn valitaan viisi ehdokasta. Totean vain, että on aikamoinen haaste suunnitella ja toteuttaa vertaileva käytettävyystesti viiden järjestelmän välillä niin, että se tehdään syrjimättömästi ja että tulokset ovat valideja (= että paljastavat aidosti parhaan järjestelmän). No, jos testit tehdään demoilla, niin tulosten validius on siis joka tapauksessa ongelma kuten edellä olen todennut.

Yhteenveto


Valituksi voi tulla oppimisympäristö, joka on käytettävyydeltään "mitä tahansa", niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin:
  • Valituksi voi tulla oppimisympäristö, joka saa parhaat pisteet käytettävyydestä. Mutta valituksi voi myös tulla järjestelmä, joka se saa huonoimmat pisteet käytettävyydestä. 
  • Parhaat pisteet käytettävyydestä voi saada järjestelmä, joka on käytettävyydeltään paras. Mutta myös käytettävyydeltään huonoin järjestelmä voi saada parhaat pisteet. 

Hyvässä tapauksessa asiakaskunnat voivat saada helppokäyttöisen oppimisympäristön. Mutta mahdollista on, että valituksi tulee ympäristö, jonka seurauksena on pähkäileviä käyttäjiä, vastahankaista käyttöönottoa, korkeita koulutuskustannuksia, jatkuvaa tuen tarvetta, käyttövirheitä ja kaiken maailman sekaannuksia.

Mikä olisi oikea tapa huomioida käytettävyys tarjouspyynnössä?


Perusaskel on määrittää käytettävyys pakollisiin vaatimuksiin. Siis määrittää se, mikä on riittävän hyvä taso järjestelmän käytettävyydelle. Tämän itse asiassa voinee vieläkin tehdä oppimisympäristön kilpailutuksessa, koska toki käytettävyys voi olla pakollisissakin vaatimuksissa sen lisäksi, että se on vertailuperusteissa.

Ja toinen perusaskel on perustaa vaatimukset käyttäjien suoriutumiseen. Niinhän tässäkin hankinnassa tehdään, mutta siis ei-toimivalla tavalla.

(On muuten hankintailmoituksia - myös Kuntien Tieran julkaisemia - jossa tehdään päinvastoin: käytettävyys on pakollisina mutta ei-valideina vaatimuksina. Yhtä toimimaton ratkaisu.)

Mutta se, miten tämä asia tehdään validisti ja miten vaatimusten saavuttaminen todennetaan, onkin sitten se haaste. Asian vaikeuden osoittaa, että niin tässä kuin käytännössä missään muissakaan Hilmassa julkaistuissa hankintailmoituksissa käytettävyyttä ei ole osattu aidosti edellyttää. Tässä suhteessa tämä hankintailmoitus ei ole muita huonompi mutta ei kyllä parempikaan.   - Olen analysoinut hankintailmoituksia aiemminkin niin tässä blogissa kuin useissa julkaisuissani ja esityksissäni. Ja varmaan teen jatkossakin. 

Asiaan ei siis ole helppoja ratkaisuja. Joitakin ratkaisumalleja mielestäni on, mutta niiden raportoinnin aika on, kun ratkaisuista on enemmän empiriaa (esimerkkejä). Itse teen tätä työtä, ja sen lisäksi tätä työtä tehdään jossain määrin Tekesin FlowIT-projektissa, jossa olen myös mukana. En tiedä, onko asian kimpussa muita tahoja; en ole tätä  ainakaan huomannut (en juuri myöskään kansainvälisesti).

Paljon helpompi on kertoa, millä tavoin käytettävyyttä ei tule laittaa tarjouspyyntöihin. Tämä hankintailmoitus on yksi esimerkki; ja muista ei-toimivista tavoista olen kirjoittanut ja pitänyt esityksiä, niin kuin edellä totean.

Mikä olisi sitten suositus?

Yksinkertaisesti ja vähän provokatiivisestikin: älä laita käytettävyyttä ollenkaan tarjouspyyntöön, ellet tiedä oleellisesti parempaa lähestymistapaa kuin se, miten tähän asti käytettävyys on huomioitu tarjouspyynnöissä! Ei pakollisiin vaatimuksiin eikä vertailuperusteisiin.

Niiden miettiminen vie vain turhia resursseja eikä niistä ole viime kädessä mitään hyötyä. Ja itse asiassa ne voivat olla vahingollisia siinä mielessä, että niistä voi tulla väärää mielenrauhaa: ajatellaan, että kun jotakin laittaa, niin sillä olisi jotain positiivista merkitystä. Ja kun ajatellaan kilpailutuksen yleistä logiikkaa, tällaiset toiveet on syytä hylätä alkuunsa. 

tiistai 30. lokakuuta 2012

Potilastietojärjestemää ei "valita"...

Potilastietojärjestelmää ei "valita" vaan se tulee valituksi tarjouspyynnön vaatimusten ja valintaperusteiden perusteella. Sen vuoksi keskeinen keskustelunaihe pitäisi olla se, mikä on potilastietojärjestelmien tarjouspyynnön sisältö - puhuminen potilastietojärjestelmän "valinnasta" voi antaa väärän kuvan asiasta. 

Suomen Telelääketieteen ja e-Health seura (STeHS) ja Sosiaali- ja terveydenhuollon tietojenkäsittely-yhdistys (STTY) järjestävät yhteistyössä Suomen Kuntaliiton sekä hyvinvoinnin klusteriohjelman kanssa seminaarin aiheesta "Mikä on sähköisten potilastietojärjestelmien valintatilanne tänään? - mitä uutta lääkintälaitedirektiivistä?"

Seminaarin tarkemmat tiedot löytyvät täältä.
Ajankohtainen ja mielenkiintoisen oloinen seminaari, johon minäkin aion osallistua. 

Mutta yksi huomio ohjelmasta. Seminaarin kahdessa otsikossa puhutaan potilastietojärjestelmän valinnasta

  • Onko lääkärillä osaa tai arpaa potilastietojärjestelmien valinnassa? (Tinja Lääveri)
  • Mikä on sähköisten potilastietojärjestelmien valintatilanne tänään? (Paneeli)

Voi olla, että ohjelmassa on vain kerrottu asiat epätarkasti. Mutta "valinta" on epätarkka ilmaisu ja voi antaa väärän kuvan asiasta. Voi tulla sellainen käsitys, että jokin porukka kävisi älyllisesti läpi eri vaihtoehtoja ja päättäisi sitten järjestelmän valinnasta. Näin asia ei kuitenkaan suoraan etene. 

Potilastietojärjestelmää ei "valita" vaan potilastietojärjestelmä tulee valituksi.  Potilastietojärjestelmä kilpailutetaan, ja se tulee valituksi sen perusteella, mitkä ovat tarjouspyynnössä olevat vaatimukset ja valintaperusteet

Potilastietojärjestelmän "valinta" siis on periaatteessa mekaaninen prosessi sen jälkeen, kun tarjouspyyntö on tehty. Eli tarjouspyyntö on ratkaiseva asia. Keskustelun aihe pitäisi olla, mikä on potilastietojärjestelmän tarjouspyynnön sisältö

Kuvaavammat yllä mainittujen esitysten otsikot olisivatkin: 

  • Onko lääkärillä osaa tai arpaa potilastietojärjestelmien tarjouspyyntöjen sisällön (pakollisten vaatimusten ja valintaperusteiden) määrittämisessä
  • Mikä on sähköisten potilastietojärjestelmien tarjouspyyntöjen sisällön (pakollisten vaatimusten ja valintaperusteiden) tilanne tänään? 
Ja erityisen tärkeää potilastietojärjestelmien helppokäyttöisyyden kannalta on keskustella siitä, miten käytettävyys näkyy tarjouspyynnön pakollisissa vaatimuksissa ja valintaperusteissa. 


--------------
PS. Tuo Tinja Lääverin puheenvuoron otsikko on muutenkin mielenkiintoinen. Toivon vain, että lääkäreille eikä muillekaan käyttäjille anneta väärällä tavalla vastuuttavia osia tai arpoja prosessissa. Käyttäjiä ei pitäisi väärin vastuuttaa tietojärjestelmähankinnoissa eikä siis myöskään järjestelmän valinnan kannalta ratkaisevassa asiassa eli tarjouspyynnön valmistelussa (ks. aihetta käsittelevä juttu). 


maanantai 29. lokakuuta 2012

Käytettävyyskurssi 12.-13.11.12


Tietotekniikan liitto järjestää ja minä pidän käytettävyyskurssin 12.-13.11.12. Viime keväänä vastaava kurssi oli täynnä, ja kurssista tuli ihan mukavaa palautetta. 


Kurssin toinen päivä keskittyy erityisesti siihen, miten käytettävyys olisi otettava huomioon tietojärjestelmien hankinnoissa (ja miten ei...)