Taking usability into account in the procurement process of IT-systems

Informaatioverkostojen koulutusohjelma

Anna Törrönen

Käytettävyyden huomioiminen IT-järjestelmien hankinnassa

Diplomityö

Helsinki, 20. helmikuuta 2012

Valvoja: Professori Marko Nieminen, Aalto-yliopisto Ohjaaja: Tekniikan tohtori Kari Pihkala, Accenture Oyj

Aalto-yliopisto

Perustieteiden korkeakoulu Tietotekniikan talon kirjasto

Aalto-yliopisto Aalto-yliopisto

A?

Perustieteiden korkeakoulu DIPLOMITYÖN

Informaatiover kosto jen koulutusohjelma TIIVISTELMÄ Tekijä:

Työn nimi:

Anna Törrönen

Käytettävyyden huomioiminen IT-järjestelmien hankinnassa Päiväys: 20. helmikuuta 2012 Sivumäärä: 8 + 79 Professuuri: Käyttöliittymät ja käytettävyys Koodi: T-121 Työn valvoja: Professori Marko Nieminen

Työn ohjaaja: Tekniikan tohtori Kari Pihkala

Tässä työssä selvitetään miten käytettävyysnäkökulma otetaan tällä het­

kellä huomioon Luottokunnassa IT-järjestelmän hankintavaiheessa ja teh­

dään suosituksia, miten se voitaisiin vastaisuudessa ottaa vahvemmin mu­

kaan. Tutkimuksen kohteena ovat Luottokunnan ja Accenturen yhteis­

työsopimuksen puitteissa toteuttamat kolme järjestelmäprojektia. Työ on tehty tutustumalla olemassa olevaan teoriaan sekä kirjallisen materiaalin ja haastatteluaineiston laadullisella analyysillä.

Tutkimuksessa selvisi, että käytettävyyttä ei juuri huomioitu hankintaa edeltävässä vaatimus- tai määrittelymateriaalissa. Lisäksi käytettävyyden huomiointi vaihteli projektikohtaisesti, koska Luottokunnalta puuttui yri­

tyksen tasoinen ohjeistus. Käytettävyyttä pidettiin kuitenkin tärkeänä laatuominaisuutena ja siihen halutaan panostaa, jos sen merkitys on pro­

jektin lopputuloksen kannalta keskeinen.

Tutkimustulosten pohjalta Luottokunnalle annettiin suositukset käytettä­

vyyden huomioinnista hankinnassa. Nämä suositukset koostuvat tarkem­

masta käyttäjäryhmien määrittämisestä, käytettävyyden merkityksen ar­

vioinnista ennen projektin hankintaa, käytettävyyden huomioimisesta pro­

sessitasolla ja Luottokunnan käyttöliittymäohjeistuksen ja ulkoasumallin laatimisesta.

Avainsanat: Käytettävyys, hankintatoimi, käytettävyysvaatimukset, hankinnan määrittely, IT-järjestelmä

Kieli: suomi

li

Aalto University

A!

School of Engineering ABSTRACT OF

Degree Program of Information Networks MASTER’S THESIS Author: Anna Törrönen

Title of thesis: Taking Usability into Account of IT-systems

in the Procurement Process Date: February 20, 2012 Pages: 8 + 79

Professorship: Usability and User Interfaces Code: T-121 Supervisor: Professor Marko Nieminen

Instructor: Kari Pihkala Ph.D. (Tech.)

In this thesis we explore how usability is taken into account in the pro­

curement process of an IT-system in Luottokunta. Also recommendations of how usability could be better addressed in the future are given. The research subject is three IT-system projects done under the collaboration agreement between Luottokunta and Accenture. The research is done by going through existing theory and by doing qualitative analysis of written material and interviews.

In the research it became clear, that usability in not really taken into account in the requirement and definition material that predates the pro­

curement decision. In addition, how usability was addressed varies from project to another, because Luottokunta was lacking any company level in­

structions on usability. Usability was however considered as an important quality factor and there is a desire to invest in it in cases were usability is a significant factor for the end result of the project.

Several recommendations of how usability should be taken into account by Luottokunta in the procurement process were given based on the re­

search. These were more detailed definition of user groups, defining the significance of usability before the project starts, addressing usability on the process level and creating Luottokunta’s own user interface and ap­

pearance guides.

Keywords: Usability, procurement, usability requirements procurement definitions, IT-system

Language: Finnish

Tätä työtä ei olisi syntynyt ilman Luottokunnan ja Accenturen suostumusta ja koen olevani etuoikeutettu, että pääsin käsiksi näin hienoon tutkimusai­

neistoon. Haluan kiittää kaikkia haastatteluihin osallistuneita Luottokunnan ja Accenturen edustajia ja työtovereitani molemmista yrityksistä siitä, että he jaksoivat kysellä miten kirjoitushommat etenevät ja kuunnella pohdinto­

jani aihepiiristä. Haluan erityisesti kiittää Tommi Pälliä ja Eeva Kekkosta, jotka järjestivät minulle tämän diplomityötilaisuuden.

Tutkimus olisi edennyt hitaammin ja ollut laadultaan huomattavasti hei­

kompi ilman valvojaani professori Marko Niemistä ja ohjaajani Kari Pihka­

laa, joille myös haluan lausua kiitokset. Molemmat olivat, oma-aloitteisia ja innostuneita työn valvomisessa ja sain paljon hyvää palautetta, joka ohjasi vahvasti työn kehitystä. Heille lupaamani diplomityön eri versioiden palau­

tuspäivät olivat paras kannuste kirjoitustyön etenemisessä.

Lisäksi haluan vielä kiittää ystäviä, perhettä, sukulaisia ja työkavereita siitä, ettei elämä ollut pelkkää diplomityötä tämän prosessin aikana. Speksiyhtei- sö, Anna Torvinen, Katri Vilkman, Oona Korhonen, Matti Koivisto ja Laura Kainulainen auttoivat minua diplomityössä ja erityisesti sen unohtamisessa.

Äiti, isä, veli ja muut sukulaiset asettivat sopivaa painetta valmistumiselle kyselemällä, että milloin saa pitää juhlat ja hankkimalla etukäteen upeita valmistujaislahjoja. Ja silloin kun tuntui, ettei mikään etene ja valmistumi­

nen on epätodennäköisempää kuin levitoimisen oppiminen, lähdin merenran- talenkille Usvan ja Zuleykan kanssa ja asiat olivat taas paljon paremmin.

Munkkiniemessä 20. helmikuuta 2012

Anna Törrönen

1 Johdanto 1

1.1 Tutkimuskysymykset ja tavoitteet... 2

1.2 Diplomityön rakenne... 3

2 Hankintatoimi 4 2.1 Hankintatoimi... 4

2.2 Hankinnan määrittely ja toimittajan valinta... 5

2.3 IT-järjestelmien hankinnan erityispiirteet... 6

2.3.1 IT-ulkoistus ja strateginen kumppanuus ... 8

3 Käytettävyysvaatimukset 9 3.1 Vaatimukset... 9

3.2 Käytettävyysvaatimukset... 10

3.2.1 Käytettävyysvaatimusten todennettavuus ja mitattavuus 11 3.3 Käytettävyysvaatimukset IT-järjestelmien hankinnassa .... 13

3.3.1 Käytettävyysvaatimusten rooli IT-järjestelmien hankin­ nassa ... 13

3.3.2 Hankkijan ja toimittajan rooli... 14

3.3.3 Käytettävyysvaatimukset tarjousvaiheessa... 15

3.3.4 Validien ja todennettavien käytettävyysvaatimusten luo­ minen ... 16

4 Tutkimuksen metodologia ja aineisto 21 4.1 Aineiston laadullinen analyysi...21

v

4.4 Tutkimuksen rajaukset... 30

5 Tutkimuksen tausta 31 5.1 Tutkimuksen yritysosapuolet - Luottokunta ja Accenture ... 31

5.1.1 Hankinta Luottokunnassa... 32

5.2 Tutkittavat projektit... 33

5.2.1 Korttitilitysten raportointipalvelu... 33

5.2.2 Business Eurocard -uudistus... 36

5.2.3 Luottokunta Sopimusportaali...38

6 Tulokset 42 6.1 Käytettävyyden huomioiminen hankinnan kirjallisessa mate­ riaalissa ... 42

6.1.1 Projekteista tunnistettavissa olevat käytettävyysvaati­ mukset ... 43

6.1.2 Käytettävyyden huomioiminen projektien muussa han­ kinnan määrittelydokumentaatiossa... 47

6.2 Haastattelutulokset... 49

6.2.1 Hankintaprosessi ja hankinnan määrittely yleisellä ta­ solla ... 50

6.2.2 Käytettävyyden huomiointi hankinnan määrittelyssä . 53 7 Tulosten analyysi ja johtopäätökset 59 7.1 Tulosten analyysi... 59

7.1.1 Yhteenveto projektien käytettävyysvaatimuksista ... 60

7.1.2 Yhteenveto käytettävyyden huomioinnista projektien muussa hankinnan määrittelydokumentaatiossa .... 60

7.1.3 Yhteenveto käytettävyyden huomioinnin haastattelu- tuloksista ... 61

7.1.4 Yhteenveto käytettävyyden huomioinnin nykytilasta han- kintavaiheessa Luottokunnassa...62

VI

7.2.1 Hankintaprosessi... 63 7.2.2 Hankinnan määrittely ...64 7.2.3 Käytettävyyden huomiointi hankinnan määrittelyssä . 65

8 Yhteenveto ja pohdinta 68

8.1 Pohdintaa annetuista suosituksista...69 8.2 Tutkimuksen luotettavuus ja yleistettävyys... 70 8.3 Jatkotutkimuskysymyksiä . . . ... 73

Lähdeluettelo 73

A Teemahaastattelujen rakenne 77

vii

1 Korttitilitysten raportointipalvelu -projektin käsitelty vaatimus- ja määrittelydokumentaatio... 24 2 Business Eurocard -uudistuksen käsitelty vaatimus- ja määrit­

telydokumentaatio ... 25 3 Luottokunta Sopimusportaalin -uudistuksen käsitelty vaatimus-

ja määrittelydokumentaatio... 26 4 Haastatellut henkilöt... 29 5 Korttitilitysten raportointipalvelu -projektin hankintaa edel­

täneiden vaatimusten tyyppi ja määrä... 44 6 Eri projektien sisältämien käytettävyysvaatimusten määrä . . 60

Johdanto

Käytettävyys on laatuominaisuus, joka kuvaa tuotteen tai palvelun tehok­

kuutta, tuloksellisuutta ja miellyttävyyttä [13]. Käytettävyys on myös lii- ketoiminnallisesti merkittävää, koska se vaikuttaa esimerkiksi parantamal­

la tuottavuutta ja asiakasuskollisuutta ja vähentämällä virheitä ja tarvitta­

vaa asiakastukea [6]. Käytettävyys ei ole käsitteenä tai alana enää uusi ja sen huomioinnilla on paljon myönteisiä vaikutuksia, mutta silti sen merkitys tunnutaan sivuutettavan turhan helposti.

Lehdistä ja Internetistä löytyy artikkeleita, mielipidekirjoituksia ja bloge- ja, joissa parjataan milloin mitäkin uutta IT-järjestelmää tai -palvelua sen huonosta käytettävyydestä. VR:n verkkolippukaupan uudistus ja muutaman vuoden takainen sähköinen äänestys ovat esimerkkejä järjestelmistä, joissa käytettävyyteen ei ole kiinnitetty riittävää huomiota [18, 17].

VR:n lippukauppa ja sähköinen äänestys eivät ole omistajiensa tekemiä, sil­

lä VR:n ja sähköisen äänestyksen tilanneen oikeusministeriön toimintaan ei kuulu IT-järjestelmien toteuttaminen. Nämä järjestelmät on hankittu ulko­

puoliselta toimittajalta kilpailutuksen kautta. Hankkija, eli VR tai oikeusmi­

nisteriö, on tehnyt toimittajille tarjouspyynnön, jossa he kuvaavat mitä tu­

levalta järjestelmältä toivotaan, ja tähän toimittajat ovat vastanneet omalla tarjouksellaan.

Käytettävyyden kannalta ei ole epäolennaista mitä tarjousvaiheessa hankki­

jan ja toimittajan kesken sovitaan. Projektin aikataulu, budjetti ja resurssit asettavat puitteet myös mitä käytettävyyden eteen voidaan tai halutaan teh­

dä. Jos tarjouspyynnössä ei edellytetä järjestelmän käytettävyyttä, ei toimit­

taja lähde sitä tarjoamaan korkeampien kustannusten takia |4], Toimittajan itsenäisesti lisäämät käytettävyystoimenpiteet nostavat tarjouksen hintaa ja sopimuksen voittaminen olisi hankalampaa. On löydettävissä jonkin verran

1

tutkimuksia, joissa käsitellään tarjousprosessia ja hankinnan aikaista käytet­

tävyyden huomioimista esimerkiksi vaatimuksina. Näissä tutkimuksissa on havaittu, että tarjouspyyntöjen käytettävyysvaatimukset ovat puutteellisia tai niitä ei yksinkertaisesti ole olemassa [22, 20].

Yksi suurimmista järjestelmäprojektien epäonnistumisen syistä on väärin tai riittämättömästi ymmärretyt käyttäjätarpeet [13]. Tämän takia on olennais­

ta, että järjestelmän kehityksen alkuvaiheessa kerätään riittävä ymmärrys niihin vaikuttavista tekijöistä. Tätä on kuitenkin mahdoton tehdä, jos työn realiteetit tulevat vastaan: ei ole aikaa, rahaa tai osaamista, jolla tämä teh­

täisiin. Projektin alkuvaiheessa tehdään myös isot linjaukset, joilla on vaiku­

tusta järjestelmän käyttökokemukseen. Silloin lyödään lukkoon esimerkiksi käytettävä toteutustapa, joka luo muulle tekemiselle rajoitukset ja mahdol­

lisuudet. Käytettävyys ja käyttöliittymä eivät ole vain järjestelmän päälle liimattavia osia, vaan niiden asettamat vaatimukset tulisi huomioida jo pro­

jektin alusta asti.

Tässä työssä tutustutaan käytettävyyden huomiointiin jo projektin hankinta- vaiheessa. Empiirisessä tutkimuksessa käydään läpi kolme projektia, joiden avulla selvitettiin, mikä on käytettävyyden huomioinnin nykytaso Luotto- kunnassa. Työn tavoitteena on myös selvittää, miten käytettävyysnäkökul- ma saadaan konkretisoitua ja tuotua mahdollisimman varhain mukaan pro­

jektiin.

1.1 Tutkimuskysymykset ja tavoitteet

Tämän diplomityön tutkimuskysymykset ovat

Miten käytettävyys otetaan huomioon IT-järjestelmien hankintavaiheessa Luottokunnassa? ja

Miten käytettävyys voitaisiin huomioida paremmin hankintavaiheessa?

Työn tavoitteena on ensin selvittää Luottokunnan käytettävyyden huomioin­

nin nykytilanne hankintavaiheessa. Tutkimuksen pohjalta pyritään esittä­

mään, miten käytettävyyteen liittyviä asioita voitaisiin vastaisuudessa ilmais­

ta ja tuoda paremmin esiin jo hankintavaiheessa.

Koska aihepiiristä ei ole olemassa paljonkaan aikaisempaa tutkimusta tai se on tehty pääosin julkishallinnon näkökulmasta, tämä työ täydentää olemassa olevaa kirjallisuutta ja tuo mukaan yksityisen sektorin näkökulmaa käytettä­

vyyden huomiointiin hankinnassa.

1.2 Diplomityön rakenne

Tämä työ jakaantuu neljään kokonaisuuteen jotka ovat tutkimuksen teoria­

pohja, tutkimuksen tausta, tutkimuksen tulokset ja niiden analyysi sekä yh­

teenveto ja pohdinta. Tutkimuksen teoria rakentuu luvuista 2 Hankintatoimi ja 3 Käytettävyysvaatimukset, joissa käydään läpi hankintatoimea ja han­

kinnan määrittelyä yleisellä tasolla ja tarkemmin käytettävyysvaatimuksia.

Työn empiriaosuus aloitetaan tutkimuksen taustoituksella. Luvussa 4 Tutki­

muksen metodologia ja aineisto kerrotaan käytetystä metodologiasta ja luvus­

sa 5 Tutkimuksen tausta tutkittavasta tapauksesta ja projekteista. Seuraavat kaksi lukua, 6 Tulokset ja 7 Tulosten analyysi ja johtopäätökset, käsittelevät tehdyn empiirisen tutkimuksen tuloksia, niiden analyysia ja tehtyjä johto­

päätöksiä. Työ päättyy lukuun 8 Yhteenveto ja pohdinta, jossa työn tulokset vedetään yhteen sekä pohditaan tehtyä työtä ja sen laatua.

Hankintatoimi

Tässä luvussa kerrotaan hankintatoimesta yrityksen toimintona ja siihen liit­

tyvästä teoriasta. Luvussa käsitellään hankintatoimen yleiskuvauksen jälkeen hankinnan määrittelyä ja toimittajan valintaa, jotka liittyvät läheisesti tut­

kittavaan tapaukseen. Lopuksi käsitellään IT-järjestelmien hankinnan erityis­

piirteitä suhteessa muihin hankintoihin, IT-ulkoistuksia ja strategista kump­

panuutta.

2.1 Hankintatoimi

Hankintatoimi ohjaa organisaation ulkopuolisilta tahoilta tekemiä ostoja.

Hankinnat ovat resursseja, tuotteita tai palveluita, joiden avulla saavute­

taan organisaation yleisiä ja erityisiä liiketoiminnallisia tavoitteita tai ylläpi­

detään sen olemassa olevaa toimintaa. Hankinnat pyritään tekemään organi­

saation kannalta optimaalisesti, esimerkiksi hinnan, laadun ja toimitusajan suhteen. Usein hankintahintaa olennaisempaa on laskea hankinnan kokonais­

kustannus, johon pyritään tunnistamaan hankittavan kohteen kaikki suorat ja epäsuorat kulut koko sen elinkaarelta. [29]

Hankintaprosessi lähtee liikkeelle organisaation sisäisestä tarpeesta, jota or­

ganisaatio ei voi tai jota sen ei ole kannattavaa itse täyttää. Tästä tarpees­

ta tulee tehdä tarkempi määritys, esimerkiksi hankittavan tuotteen laatu ja määrä, jolloin saadaan muodostettua hankintakriteerit. Seuraava askel on ulkopuolisen toimittajan valinta, joten organisaation tulee ottaa selvää po­

tentiaalisista toimittajista, valmistella hankintaa ja käydä neuvotteluja so­

pimuksen aikaansaamiseksi. Hankkijan tulee seurata toimittajan toimintaa, jotta varmistetaan hankinnan eteneminen. Kun haluttu kokonaisuus on toi­

4

mitettu, tehdään vielä laadunvarmistus ja arviointi, joilla varmistetaan että saadaan sitä mitä on tilattu. [29]

Hankintaprosessi ei välttämättä etene lineaarisesti, vaan voi sisältää esimer­

kiksi useampia tarjouskierroksia ja potentiaalisten toimittajien karsimista [30]. Hankintaprosessiin voivat vaikuttaa sen ominaisuuksien lisäksi myös hankinnan strateginen merkitys, hankinnan hinta, siihen liittyvät riskit ja miten kyseinen hankinta vaikuttaa organisaation toimintaan. Mitä merkittä­

vämpi, monimutkaisempi, kalliimpi ja riskialttiimpi hankinta, sitä enemmän eri osastojen ja alojen päätöksentekijöitä hankintaan liittyy. [29]

2.2 Hankinnan määrittelyjä toimittajan valin­

ta

Hankintaprosessin ensimmäinen askel sisäisen tarpeen havaitsemisen jälkeen on hankinnan tarkempi määrittely. Hyvät määritykset ovat olennaisia, kos­

ka toimittajat tarjoavat hankkijalle tuotteita ja palveluita näiden pohjalta.

[29] Määritykset esitetään usein vaatimuksina, jotka ovat sanallisia kuvauk­

sia halutuista ominaisuuksista. VanVVeelen mukaan [29] vaatimukset voidaan jakaa teknisiin ja toiminnallisiin vaatimuksiin. Teknisiä vaatimuksia ovat esi­

merkiksi halutun tuotteet kaaviokuva tai tietyn tekniikan käyttäminen sen valmistuksessa. Toiminnalliset vaatimukset sen sijaan kuvaavat korkeammal­

la tasolla mitä toimintoja halutun hankinnan tulee mahdollistaa, jolloin ne ovat avoimempia ja mahdollistavat paremmin toimittajan erikoisosaamisen hyödyntämisen. [29]

Lauesen [20] laajentaa vaatimusten luokittelua teknisten ja toiminnallisten vaatimusten lisäksi ei-toiminnallisilla vaatimuksilla. Jos toiminnalliset vaati­

mukset kuvaavat mitä järjestelmän tulee tehdä, ei-toiminnalliset, vaatimukset kuvaavat miten hyvin sen tulisi nämä toiminnot tehdä [20]. Ei-toiminnalliset.

vaatimukset kuvaavat siis järjestelmän laatua, esimerkiksi sen kestävyyttä, käytettävyyttä tai tietoturvallisuutta ja velvoittavat toimittajan ottamaan myös laadulliset aspektit toimituksessaan huomioon.

Hankinnan prosessimallissa hankinnan määrittely tulisi olla tehtynä ennen toimittajan valintaa, mutta käytännössä nämä vaiheet limittyvät toisiinsa.

Esimerkiksi teknisiä vaatimuksia tehtäessä mietitään jo joidenkin tiettyjen toimittajien komponentteja, jotta rakennettavan tuotteen toteutettavuutta ja hintaa voidaan arvioida. [29] Erityisesti jos hankinta on iso ja komplek­

sinen, hankkija voi toimia yhteistyössä toimittajien kanssa, jolloin neuvotte­

luissa tarkennetaan itse hankinnan vaatimuksia. [30]

Toimittajan valintaa varten suoritetaan tarjouskilpailu jossakin laajuudessa.

Tarjouskilpailun laajuus ja avoimuus riippuvat voimakkaasti siitä toimiiko hankkijaorganisaatio julkisella vai yksityisellä sektorilla. Julkisella sektorilla avoin tarjouskilpailu (engl. call-for-tenders), johon kaikki halukkaat toimit­

tajat voivat osallistua, on lainsäädännöllinen vaatimus, jolla pyritään estä­

mään korruptiota ja nepotismia. Esimerkiksi Euroopan unionin lainsäädän­

nössä määritellään, että julkishallinnon organisaatioiden tulee tehdä julkinen tarjouspyyntö (engl. request for tender, RET) hankittaessa ulkopuoliselta toi­

mittajalta [22]. Tällöin viranomaisen tulee valita se toimittaja, jonka tarjous vastaa parhaiten tarjouspyynnössä määritettyjä vaatimuksia ja valittu toi­

mittaja sitoutuu tuottamaan tarjouksensa mukaisen järjestelmän [22].

Yksityisellä sektorilla käytetään yleisemmin suljettua tarjouskilpailua. Sulje­

tussa tarjouskilpailussa tarjouksen pääsevät tekemään vain ennalta määritel­

lyt, potentiaaliset toimittajat (29]. Hankkijaorganisaatio kokoaa toimittajista niin sanotun pitkän listan, johon kerätään kaikki potentiaaliset, esiehdot täyt­

tävät toimittajat [29]. Näille toimittajille voidaan lähettää tiedustelupyyntö (engl. request for information, RFI), jossa pyydetään heitä esimerkiksi kuvaa­

maan referenssitoimituksia ja muita tähän toimitukseen pätevöittäviä tietoja [29]. Tiedustelupyynnön lisäksi voidaan järjestää tapaamisia ja esimerkiksi tehdasvierailuja toimittajan kyvykkyyden selvittämiseksi |29].

Näiden tietojen perusteella kootaan niin sanottu lyhyt lista, jossa osa pit­

kän listan toimittajista on karsittu pois. Listan toimittajille voidaan lähet­

tää tarjouspyyntö (engl. request for proposal, RFP). Toimittajat vastaavat tähän tarjouksella, joka vastaa tarjouspyynnössä määritettyjä vaatimuksia ja sisältää heidän hankinnalle tarjoaman hinnan. Hankkija analysoi tarjoukset ja vertaa niitä toisiinsa ja päättää lopulta yhden toimittajan, jonka kanssa sopimus tehdään. [29]

2.3 IT-järjestelmien hankinnan erityispiirteet

IT-järjestelmähankinta ei ole yksiselitteinen kokonaisuus vaan voi sisältää esimerkiksi laitteistohankintoja, paketti- tai räätälöityjä ohjelmistoja ja nii­

den kehitystä, verkkoyhteyksiä, konesalihuoneiden rakentamista, huolto- ja ylläpitopalvelulta ja ulkoistamista [19]. Uusi teknologia tuo tullessaan myös organisaation toimintaan ja prosesseihin vaikuttavia muutoksia, jotta tuot­

tavuutta saadaan aidosti parannettua [5]. Verrattuna esimerkiksi raakama- teriaalien hankintaan, joka on organisaation operatiivista toimintaa, uuden IT-järjestelmän hankinta on yleensä luonteeltaan strategista ja keskittyy yri­

tyksen tuotteiden sijasta itse yrityksen toiminnan mahdollistamiseen.

Fisher [10] esittää, että hankintapäätöksen tekemisen prosessiin vaikuttaa pääasiallisesti kaksi tekijää, jotka ovat hankinnan monimutkaisuus ja talou­

dellinen epävarmuus, jotka liikkuvat skaalalla matala-korkea. Tuotteen kor­

keaa monimutkaisuutta kuvaavat esimerkiksi kustomointi, monimutkainen teknologia, asennuksen vaikeus ja oston jälkeisen tuen tarve, kun taas korke­

aa taloudellista epävarmuutta kuvaavat esimerkiksi suuri sijoitettava summa, pitkäaikainen vaikutus, organisaation sopeutuksen tarve ja suuri vaikutus ta­

loudelliseen tulokseen. [10] Tästä voidaan havaita, että uuden IT-järjestelmän hankintapäätös on sekä monimutkainen että taloudellisesti epävarma. Tämä tarkoittaa, että itse hankintapäätöksen tekeminen on monimutkaisempaa, ai­

kaa vievempää ja useamman eri näkökulmien edustajien osallistumista vaati­

vampi verrattuna yksinkertaisiin ja taloudelliselta merkitykseltään vähäisiin hankintoihin [29].

Kyriazoglou [19] kuvaa kirjassaan “IT Strategic and Operational Controls”

organisaation IT-järjestelmän hankintaprosessin luomisen ja hankintaproses­

sin keskeiset toiminnot. Lähtökohtana ovat IT-hankintaprosessin strategiset tavoitteet: nopea ja tehokas hankintojen käsittely, mahdollisimman korkea­

laatuisten IT-tuotteiden, ratkaisujen ja palveluiden hankinta sekä mahdolli­

simman hyvät hintajärjestelyt [19].

IT-hankintaprosessista tulee suunnitella hankintamenettelyt, luoda tarjous­

ten arviointikriteerit, valvonta ja budjettihyväksyntä ja rajata mitä hankinto­

ja prosessi koskee. Hankintaprosessin lisäksi määritetään IT-hankintabudjetti, joka voidaan määritellä vuosi- tai projektitasolla. [19]

Kun toiminnalle on saatu nämä organisatoriset kehykset, voidaan niiden poh­

jalta tehdä hankintaehdotus tarpeellisesta hankinnasta. Ehdotuksessa kuva­

taan tarkasti mitä vaatimuksia hankittavaan tuotteeseen, ohjelmistoon tai palveluun liittyy [19]. Ehdotukseen voidaan suoraan lisätä aikaisemmin käy­

tetyt ja uudet IT-toimittajat, jolta hankinnan voi tehdä [19].

Jos hankintaehdotus hyväksytään, lähdetään tutkimaan markkinoita tavoit­

teena saada tarjouksia toimittajilta. Jos kyseessä on pelkkä tiedustelu (engl.

request for information), kerätään haluttu toimittajatieto, jonka perusteella prosessia voidaan jatkaa tai lopettaa se tähän. Jos tehdään tarjouspyyntö, sen tulisi sisältää haluttavan kokonaisuuden tekninen kuvaus, taloudellinen ana­

lyysi, oikeudelliset näkökohdat ja arviointiperusteet. Sen perusteella potenti­

aalisten toimittajien tulisi tietää kaikki tarpeet, vaatimukset, määritykset ja ehdot joiden perusteella organisaatio tekee valinnan voittavasta tarjouksesta.

[19]

Saadut tarjoukset arvioidaan teknisesti ja taloudellisesti ja niitä verrataan alkuperäiseen tarjouspyyntöön. Jos tarjous ei vastaa tarjouspyyntöä, se tulee

hylätä. Riippuen tapauksesta valinnassa tehdään painotuksia eri vaatimusten tärkeyden mukaan, minkä perusteella valitaan hankinnan toimittaja. [19]

Jos kyseessä on hinnaltaan merkittävä tai strategisesti tärkeä IT-hankinta, hankkija- ja toimittajaorganisaatio tekevät siitä keskinäisen sopimuksen. So­

pimuksessa voidaan määrittää esimerkiksi toimituksen laajuus ja aikatau­

lu. Hankkija valvoo, että toimittaja toimittaa tai tuottaa kaikki sopimuksen määrittämät tuotteet ja palvelut sopimuksen ehtojen mukaisesti. Kun hank­

kijan ja toimittajan mielestä toimituksesta ei ole enää selvitystä vaativia avoimia asioita, järjestelmätoimitus on valmis. [19]

IT-projektin selkeä rajaus on sen onnistumisen ehdoton edellytys. Jos pro­

jektin rajaus on kovin avoin eli se sisältää esimerkiksi määrittelemättömiä käyttäjäryhmiä, useita maantieteellisiä sijainteja, kirjaamattomia käyttäjä- tarpeita, sen sisältämien riskien määrä kasvaa huomattavasti. Hyvään rajauk­

seen kuuluvat esimerkiksi riittävät, hyvin dokumentoidut vaatimukset, jotka on hyväksytetty loppukäyttäjillä ja muilla sidosryhmillä, sovittu aikataulu toteutukselle, projektin virstanpylväät ja lopputuotteet, laatustandardit, hy- väksymiskriteerit sekä virheidenkorjaus- ja valitusmenettelytavat. [19]

2.3.1 IT-ulkoistus ja strateginen kumppanuus

IT-ulkoistuksessa osa tai kaikki organisaation IT-toiminnoista siirretään ul­

kopuoliselle toimijalle. Koska IT on keskeinen ja strategisesti tärkeä osa orga­

nisaation toimintaa jälkiteollisessa taloudessa, kyse ei ole pelkästään palvelu­

jen hankinnasta ulkopuoliselta toimittajalta, vaan hankkijan ja toimittajan välille syntyy väistämättä keskinäisesti riippuvainen strategisen kumppanuu­

den suhde [27].

IT-ulkoist,uksen etuja ovat keskittyminen omaan ydintoimintaan, mahdolliset kustannussäästöt, teknologian tason nostaminen ja ulkoistuksen mahdollis­

tama organisaation oman IT-kyvykkyyden vapautuminen rutiinien suoritta­

misen sijaan suunnittelemaan liiketoimintaan vaikuttavia strategisia toimia.

Ulkoistuksen riskejä ovat ulkoistuksen vaikea peruminen, eli organisaation si­

säisen IT-kyvykkyyden uudelleenkokoaminen, ja tietyn joustavuuden menet­

täminen, jos organisaatio sitoutuu määrättyyn teknologiaan tai lisensseihin.

|27|

Jotta ulkoistuksen riskit saadaan minimoitua, toimittajalla tulee olla syväl­

linen ymmärrys hankkijan liiketoiminnasta ja osapuolten välillä tulee vallita tiukka luottamus, jotta esimerkiksi strategisesti tärkeää tietoa voidaan käsi­

tellä. Myös samankaltainen yrityskulttuuri ja strategiset tavoitteet tekevät ulkoistuksesta helpommin molempia osapuolia hyödyttävän. |27|

Käytettävyysvaatimukset

Tässä luvussa kerrotaan käytettävyysvaatimuksista ja niihin liittyvästä teo­

riasta. Luvussa käsitellään ensin käytettävyysvaatimusten yläluokkaa vaati­

muksia ja mitä ominaisuuksia on hyvillä vaatimuksilla. Tästä syvennetään käytettävyysvaatimuksiin ja niiden erityispiirteisiin keskittyen käytettävyys- vaatimusten mitattavuuteen. Viimeiseksi käsitellään käytettävyysvaatimus­

ten roolia IT-järjestelmien hankinnassa ja validien käytettävyysvaatimusten luomisen problematiikkaa.

3.1 Vaatimukset

Vaatimukset ovat sanallisesti muotoiltuja kuvauksia, mitä tulevan järjestel­

män tulee tehdä tai mitä ominaisuuksia sillä tulee olla. Eri lähteistä on löy­

dettävissä erilaisia ominaisuuksia hyville vaatimuksille. Hyvät vaatimukset ovat esimerkiksi tarpeellisia, priorisoituja, yhtenäisiä, täydellisiä ja johdon­

mukaisia (9, 31]. Tässä työssä keskitytään erityisesti vaatimusten validiteet­

tiin ja todennettavuuteen, koska näissä on havaittu ongelmia aikaisemmassa tutkimuksessa [22, 14]. Validit vaatimukset ovat oikeellisia, hyvin perusteltu­

ja ja sovellettavissa kyseiseen tapaukseen. Todennettavat vaatimukset ovat osoitettavissa toteutetuiksi objektiivisella tavalla.

Vaatimukset voidaan jakaa niiden tyypin mukaisesti erilaisiin luokkiin. Kap­

paleessa 2.2 Hankinnan määrittely ja toimittajan valinta esiteltiin tekniset, toiminnalliset ja ei-toiminnalliset vaatimukset. Teknisiä vaatimuksia ovat esi­

merkiksi käytettävä ohjelmointikieli tai valmistustekniikka (29]. Toiminnal­

liset vaatimukset sen sijaan kuvaavat korkeammalla tasolla mitä toimintoja järjestelmän tulee mahdollistaa |29]. Ei-toiminnalliset vaatimukset kuvaavat

9

laatuominaisuuksia tai järjestelmän yleisiä toimintaperiaatteita [20]. Näiden vläkategorioiden sisällä vaatimuksia voidaan jaotella eri tavoilla esimerkiksi vaatimusten kohteen tai lähteen mukaisesti käyttöliittymä- ja arkkitehtuuri- vaatimuksiin tai liiketoiminnallisiin ja asiakaspalvelun vaatimuksiin.

Hankintaprosessin alkuvaiheessa hankkija kerää omalta organisaatioltaan vaa­

timuksia tulevan järjestelmän halutuista toiminnallisuuksista ja ominaisuuk­

sista. Järjestelmän vaatimusmäärittelyä voidaan jatkaa hankinnan jälkeen yhteistyössä toimittajan kanssa. Lauesen [21] ja Faulkner |8) ovat listanneet erilaisia määrittelyaktiviteetteja, joita voidaan käyttää tähän työhön. Hyö­

dynnettäviä menetelmiä ovat esimerkiksi

• nykyisten käyttäjien muodolliset ja epämuodolliset haastattelut,

• kontekstuaaliset havainnointimenetelmät,

• kyselyt,

• eksperttikäyttäjien ottaminen mukaan suunnitteluryhmään, e aivoriihet, kohderyhmät ja työpajat ja/tai

• kirjalliseen materiaaliin tutustuminen.

[21^, 8^[

Käyttäjiä osallistavien menetelmien, kuten työpajojen tai haastattelujen, ta­

voitteena ei ole kysyä käyttäjiltä, miten he haluavat järjestelmän rakentuvat, vaan tiedon kerääminen käyttäjien maailman jäsentämiseksi. Järjestelmän suunnittelijan vastuulla on tiedon analysointi ja tilanteen aito ymmärtämi­

nen. 116] Tämän ymmärryksen pohjalta voidaan kirjoittaa järjestelmälle sen korkean tason vaatimukset.

3.2 Käytettävyysvaatimukset

Käytettävyysvaatimusten tavoitteena on järjestelmän käytettävyyden takaa­

minen. Suosittu lähde käytettävyyden määrittämiseen on ISO 9241-110 - standardi, jonka mukaan käytettävyyden ominaisuudet ovat tehokkuus, tu­

loksellisuus ja miellyttävyys [13]. Kuitenkin käytettävyysvaatimusten muo­

dostamisen tulisi olla jokaiselle tapaukselle ja organisaatiolle yksilöllistä, kos­

ka muuten vaarana on mekaaninen standardin täyttämiseen pyrkiminen [4],

Käytettävyysvaatimukset ovat eri asia kuin käyttäjävaatimukset. Käyttäjä- vaatimukset kuvaavat mitä eri sidosryhmien tulee järjestelmällä saada aikai­

seksi, kun taas käytettävyysvaatimukset ovat korkeamman tason laatuvaati­

muksia. Käyttäjävaatimukset siis ovat järjestelmän toiminnallisia vaatimuk­

sia (mitä järjestelmällä tehdään), kun taas käytettävyysvaatimukset kuuluvat ei-toiminnallisiin vaatimuksiin (miten järjestelmän tehtävät tehdään).

Hankkijaa ja käyttäjiä ei tulisi kiinnostaa minkälaisia käyttöliittymäratkai­

suja tai -elementtejä järjestelmässä käytetään, vaan oleellista on, miten ne toimivat käytännössä [I6j. Tämän takia käytettävyysvaatimusten ei tulisi tar- jousvaiheessa olla liian tarkkoja ja esimerkiksi määrittää eksplisiittisiä suun­

nitteluratkaisuja. Tällöin päästään täysimittaisesti käyttämään hyväksi IT- järjestelmän toimittajan erikoisosaamista suunnitteluratkaisujen tuottami­

sesta [15].

3.2.1 Käytettävyysvaatimusten todennettavuus ja mi­

tattavuus

Wilson [32] nimeää yhtenä käyttäjäkeskeisen suunnittelun tulevaisuuden tren­

dinä sijoitetun pääoman tuoton selkeämmän osoittamisen. Aiheesta on ollut jo pitkään keskustelua ja tutkimusta, mutta vuodesta 2000 alkanut talouden taantuma vahvisti tätä vaatimusta. Hän kehottaa käytettävyyden asiantun­

tijoita keräämään metriikoita, joilla osoitetaan, miten ei pelkästään tuotetta, vaan myös prosessia on parannettu. Voidaanko esimerkiksi osoittaa, että ha­

vaitsemalla virheet aikaisemmin, on vähennetty niiden korjaukseen kuluvaa aikaa. [32]

Wilson tuo esille käytettävyysalan suuren ongelman eli tulosten todennetta­

vuuden ja mitattavuuden vaikeuden. Miten osoitetaan, että käytettävyyteen laitettu panostuksella on ollut vaikutusta lopputulokseen? Erilaiset käytettä­

vyyden määritelmät sisältävät listan termejä kuten helppokäyttöinen, käyt­

täjäystävällinen, miellyttävä ja tehokas joiden mittaaminen on vaikeaa ellei mahdotonta. Jos järjestelmän vaatimuksiin on listattu tämän kaltaisia ter­

mejä, miten voidaan varmistaa, että ne on saavutettu?

Sanonta “sitä saadaan, mitä mitataan” kuvaa ohjelmistokehitystyön arkea.

Käyttäjäkeskeisen suunnitteluprosessin tarkoituksena on tuottaa mahdolli­

simman käytettävä järjestelmä, mutta jos käytettävyydelle ei ole määritetty mitään kriteeristöä tai mittaristoa, jää se usein vain sanahelinäksi. Sen ta­

kia on keskeistä määrittää mitkä ovat järjestelmän käytettävyysvaatimukset ja -tavoitteet. Täydellistä järjestelmää on mahdoton saavuttaa, joten yleen­

sä sovitaan joku hyväksyttävä taso tai käytettävyysongelmien määrä, jolla

järjestelmä katsotaan riittävän hyväksi [21].

Erilaiset metriikat ovat hyödyllisiä testattaessa esimerkiksi järjestelmän suo­

rituskykyä ja niillä saatava tieto on kvantitatiivista. Kuitenkin, jotta järjes­

telmä tulee arvioitua kattavasti ja osataan löytää parannuskohteita, tarvitaan myös kvalitatiivista tietoa. [8] Mahdollisia käytettävyyden mittareita ovat esi­

merkiksi tehtävän suorittamiseen käytettävä aika, (käytettävyys)ongelmien lukumäärä, näppäinpainallusten määrä, mielipidekyselyn tulokset, ymmär­

ryksen mittaaminen sekä käyttöliittymäohjeiden ja -periaatteiden noudatta­

minen (engl. guideline adherence) [21].

Tässä työssä käytettävyyden määritelmänä käytetään ISO 9241-210 -standar­

dia, joka määrittää käytettävyyden keskeisiksi ominaisuuksiksi tehokkuuden, tuloksellisuuden ja miellyttävyyden [13]. Näille eri ominaisuuksille on kir­

jallisuudessa koottu erilaisia mittaustapoja. Virheiden määrä ja niiden tois­

tuvuus on klassinen esimerkki käytettävyyden mittaamisesta ja se vaikuttaa kaikkiin ISO 9241-210 -standardin ominaisuuksiin. Virheellä tarkoitetaan täs­

sä käyttäjän suorittamaa toimintoa, joka ei ole haluttu tavoitteen kannalta, esimerkiksi väärän napin painallus tai väärin valittu eteneminen [8]. Sen si­

jaan tekniset viat tai muut käyttäjästä riippumattomat vikatilanteet eivät ole virheitä. Jos tehtävä voidaan tehdä virheettömästi, se tehdään nopeammin ja tehokkaammin. Lisäksi virheiden korjaukseen kuluu aikaa, joka on hyödytön­

tä tavoitteen kannalta ja vaikuttaa näin tuloksellisuuteen. Virheet vaikutta­

vat myös miellyttävyyteen käyttäjäkokemuksen kautta aiheuttaen ärtymystä ja turhautumista, joka voi johtaa edelleen uusiin virheisiin. [8]

Tehokkuus tarkoittaa tavoitteiden saavuttamista tarkasti ja kokonaisuute­

na suhteessa kulutettuihin resursseihin [8[. Resursseilla voidaan tarkoittaa ajan lisäksi tehtävän kuluttavuutta tai fyysisiä resursseja. Kellotettavia te­

hokkuuden arvioinnin kohteita ovat esimerkiksi tehtävän suoritukseen, apu- toimintoihin, tietojen etsimiseen, virheiden oikaisuun tai dokumentaation lu­

kemiseen käytetty aika. Muita mitattavia tehokkuuden kohteita ovat tehtä­

vän suoritukseen tarvittujen toimintojen, hiiren klikkauksien tai näppäinten painalluksien määrä. [8]

Tuloksekkuus tarkoittaa halutun lopputuloksen saavuttamista. Tuloksekkuut- ta voidaan mitata suoritettavien tehtävien onnistumisella, onnistumisien ja epäonnistumisien suhteella, saatavalla ulostulon laadulla tai käytettävyyson­

gelmien määrällä. Jos tehtävä on monimutkainen, voi olla mielekästä jakaa se alatehtäviin, jotta nähdään mitkä osat. kokonaisuudesta toimivat ja mitkä eivät. Järjestelmän tuloksellisuutta voidaan tutkia myös sen eri osien käyt­

töasteella, jolloin voidaan havaita turhat tai vaikeat ominaisuudet, joiden käyttöä vältetään. [8]

Miellyttävyydellä tarkoitetaan ihmisen subjektiivisesti kokemia positiivisia tunteita järjestelmän käytön aikana. Koska kyse on yksittäisten ihmisten ko­

kemuksista, miellyttävyyden mittaaminen on suhteellisen vaikeaa. Tätä voi­

daan kuitenkin mitata erilaisin kyselyin, mutta ei ole takuuta, että arvot ovat keskenään verrannollisia [8|.

Validien ja todennettavien käytettävyysvaatimusten luomisen problematiik­

kaa avataan enemmän kappaleessa 3.3.4 Validien ja todennettavien käytettä­

vyysvaatimusten luominen. Kappaleesssa niitä käsitellään tutkimustapauk- sen mukaisesti IT-järjestelmien käytettävyysvaatimusten näkökulmasta teo­

riasta löydettävien esimerkkien avulla.

3.3 Käytettävyysvaatimukset IT-järjestelmien hankinnassa

Tässä kappaleessa keskitytään käytettävyysvaatimuksiin IT-järjestelmän han- kintavaiheessa eri näkökulmista. Ensimmäisessä kappaleessa käytettävyys rin­

nastetaan järjestelmän muihin laatuominaisuuksiin. Toisessa kappaleessa kes­

kitytään siihen, kuka on lopulta vastuussa käytettävyydestä ja miten vaati­

mukset vaikuttavat tähän. Kahdessa viimeisessä kappaleessa tutustutaan tut- kimustapausten kautta käytettävyysvaatimuksiin tarjousvaiheessa ja validien ja todennettavien käytettävyysvaatimusten luomiseen.

3.3.1 Käytettävyysvaatimusten rooli IT-järjestelmien han­

kinnassa

Käytettävyys on yksi IT-järjestelmän olennainen laatuaspekti, mutta se on kuitenkin vain yksi monista. IT-järjestelmän muita laatuaspekteja ovat esi­

merkiksi virheettömyys, saavutettavuus, suorituskyky, tietoturvallisuus ja ylläpidettävyys [21]. Osa näistä voidaan nähdä myös käytettävyyden osa- alueina, esimerkiksi virheettömyys ja suorituskyky vaikuttavat vahvasti käyt­

tökokemukseen, mutta niissä saavutettu taso riippuu pitkälti teknisistä läh­

tökohdista.

Vaatimusten todennettavuuden vaikeus ei liity pelkästään käytettävyysvaa­

timuksiin, vaan samaa epämääräisyyttä on havaittavissa myös muissa IT- järjestelmän laatuvaatimuksissa. Arkkitehtuuri vaatimukset voivat olla esi­

merkiksi “Järjestelmän ylläpidettävyyden tulee olla mahdollisimman hyvä”

tai “Suorituskyvyn pitää olla tyydyttävä peruskäyttäjälle” [7]. Laatuvaati-

musten mitattavuus nostetaan tässäkin olennaiseksi tekijäksi, mutta akatee­

misesti kehitetyt menetelmät ovat olleet liian raskaita, kun suhteutetaan työn määrä sillä saatuun hyötyyn [7].

Käytettävyyttä ei voida miettiä ohjelmistosta ja teknologiasta erillisenä kom­

ponenttina, koska ne asettavat puitteet sille mikä on mahdollista tai mah­

dotonta. Esimerkiksi Bosch [7] toteaa, että usein sovelluksen laatuvaatimus­

ten täyttymättömyys on peräisin käytetystä sovellusarkkitehtuurista. Tämän muuttaminen projektin elinkaaren loppuvaiheissa on lähes mahdotonta, jo­

ten laatuvaatimukset pitää ottaa jo heti alussa mukaan järjestelmän tekni­

seen suunnitteluun [7].

3.3.2 Hankkijan ja toimittajan rooli

Jotta järjestelmän käytettävyys tulee varmistettua, tulee hankinnassa olla osapuoli, joka siitä vastaa. Vastuu tarkoittaa tässä yhteydessä sitä, että jos järjestelmän käytettävyys osoittautuu ongelmalliseksi, vastuullinen osapuoli vastaa sen korjaamisesta tai korjaamatta jättämisestä taloudellisesti 115].

Tuotteita tai ohjelmistoja kehittävissä tuotekehitysyrityksissä vastuu käytet­

tävyydestä on selkeästi yrityksellä itsellään. Jos asiakkaat eivät ole tyytyväi­

siä tai yrityksen tuotteet eivät mene kaupaksi, yritys voi syyttää vain itseään käytettävyyden laiminlyönnistä. [15] Hankinnalla ostettavissa järjestelmissä vastuunjako ei ole näin selkeä.

Koska hankkija tekee tarjouspyynnön tai hyväksyy vaatimukset, joilla järjes­

telmää lähdetään tekemään, on lopullinen vastuu järjestelmän käytettävyy­

destä hankkijalla. Hankkija itse ei tätä välttämättä tiedosta, vaan olettaa järjestelmän käytettävyyden tulevan suunnittelutoimenpiteiden sivutuottee­

na. [16, 4|

Hankkijan vastuu näkyy esimerkiksi järjestelmän toteutusvaiheessa suunnit­

teluratkaisujen hyväksynnässä. Toimittaja on ideoinut suunnitteluratkaisu­

ja käyttäjätarpeista ja vaatimuksista saamansa tiedon perusteella. Ratkaisut esitetään hankkijalle, joka hyväksyy ne mahdollisin muutospyynnöin. Hyväk­

sytyt ratkaisut siirretään muutoshallintaan, jolloin niitä voi edelleen muuttaa, mutta ainoastaan hankkijan maksamilla lisätilauksilla. Jos suunnitteluratkai­

suista paljastuu myöhemmin käytettävyysongelmia, on taloudellinen vastuu niiden korjaamisesta tai korjaamattomuuden seurauksista hankkijalla, joka on suunnitteluratkaisut hyväksynyt. [16]

Yllä kuvattu hyväksyttämismenettely on yleisesti käytetty toimintatapa. Hy­

väksyjinä voivat olla asiakkaiden lisäksi loppukäyttäjät, mikä sinänsä lisää

prosessin käyttäjäkeskeisyyttä, mutta käyttöliittymän läpikäynti pala palal­

ta ei vastaa sen tuloksellisuutta järjestelmän todellisessa käytössä. Tämä me­

nettely ei ole myöskään poistanut nykyisistä järjestelmistä huonon käytettä­

vyyden ongelmia. [16]

Jos hankkija haluaa vastata järjestelmän käytettävyydestä, tulisi hankkijan ottaa merkittävämpi rooli käyttöliittymän suunnittelussa ja toimittajan oh­

jaamisessa. Erityisesti hankkijan tulisi syvällisesti jäsentää käyttäjätarpeet ja suunnitella tietorakenne ja käyttöliittymäarkkitehtuuri yhteistyössä toimit­

tajan kanssa, jotta toteutusnäkökulmat tulevat huomioiduiksi. Toimittajan rooli on käyttöliittymäratkaisujen suunnittelu ja toteutus tarjoamansa tek­

nologian avulla, mutta tässäkin hankkijan tulee toimia vahvassa yhteistyös­

sä, jotta laatu saadaan varmistettua. [15] Keskeinen haaste hankkijan ak­

tiivisemmassa roolissa on resurssien puute. Tähänkin osa-alueeseen voidaan hankkia ulkopuolinen resurssi, jonka valinnassa on kuitenkin omat haasteen­

sa. [15]

Vastuuta käytettävyydestä saadaan siirrettyä toimittajalle vain selkeästi edel­

lyttämällä käytettävyyttä tarjousvaiheessa. Käytettävyysvaatimuksien avul­

la toimittaja voi arvioida mitä osaamista ja toimenpiteitä tämän pitää sisäl­

lyttää tarjoukseen ja voi sitä kautta myös määrittää niiden hintavaikutukset tarjoushintaan. [15] Hankkijan tulee tehdä vaatimuksien muodostukseen vaa­

dittavat käytettävyystoimenpiteet, sillä järjestelmän toteuttajan ei ole suo­

tavaa asettaa omalle työlleen vaatimuksia [16].

Jokela |15| pohtii artikkelissaan myös vastuun jakamista, mutta toteaa sen olevan ongelmallista, kun on kysymys rahasta. Ilman selkeästi määritettyä vastuuta on vaikea edellyttää korjaustoimenpiteitä ongelmatapauksissa [15].

3.3.3 Käytettävyysvaatimukset tarjousvaiheessa

Käytettävyysvaatimusten ongelma on, että perinteisesti ne määritellään si­

ten, että ne voidaan todentaa vasta toteutetulla järjestelmällä. Tarjousvai­

heessa vaatimusten tulisi vaikuttaa ja ohjata IT-järjestelmän suunnittelua, jolloin tämänkaltaiset vaatimukset ovat hyödyttömiä, f 111

Yksi harvoista aihepiiriä käsittelevistä artikkeleista on Lehtonen et ai. [22], jossa analysoidaan 38 viranomaisten tekemää tarjouspyyntöä. Tutkimuksen tavoitteena on selvittää miten ja missä määrin näissä tarjouspyynnöissä on asetettu käytettävyysvaatimuksia. Metodina on käytetty tarjouspyyntöjen vaatimusten laadullista analyysia, jonka jälkeen löydetyt käytettävyysvaati­

mukset on kategorisoitu. [22]

Tarjouspyynnöistä löydettiin yhteensä 191 käytettävyysvaatimusta, mutta ne jakautuivat epätasaisesti. Yhdeksässä tarjouspyynnössä ei ollut yhtäkään käytettävyysvaatimukseksi laskettavaa vaatimusta ja suurimmassa osassa vaa­

timuksia oli vain 1-5. Käytettävyysvaatimukset kategorisoitiin ISO 9241-210 -standardinkäytettävyyden määritelmän kolmen attribuutin eli tehokkuuden, tuloksellisuuden ja miellyttävyyden mukaan, jonka lisäksi kirjoittajat lisäsi­

vät kolme kategoriaa, koska nämä eivät riittäneet kattamaan kaikkia vaati­

muksia. Lisätyt kategoriat ovat yleiset vaatimukset, suunnitteluvaatimukset ja prosessivaatimukset. [22]

Yleiset vaatimukset, joita löydettiin yhteensä 55, ovat niin korkealla tasolla, etteivät ne sopineet mihinkään muuhun kategoriaan. Esimerkkejä tällaisista vaatimuksista ovat “Järjestelmän tulee olla käyttäjäystävällinen” ja “Järjes­

telmän käyttöliittymän tulee olla käyttäjäystävällinen ja selkeä”. Suunnit­

teluvaatimukset, joita oli 87 kappaletta, kuvaavat esimerkiksi miten tietoa tulisi esittää tai minkälaista palautetta käyttäjille tulisi antaa, esimerkiksi

“Järjestelmän navigaatio on selkeä, yhdenmukainen ja samankaltainen läpi koko järjestelmän”. Prosessivaatimuksia löydettiin yksi, jossa haluttiin, et­

tä järjestelmälle suoritetaan käytettävyystestaus. Tehokkuusvaatimuksia löy­

dettiin vain kolme, tuloksellisuusvaatimuksia 45, kun taas miellyttävyydestä ei löydetty yhtäkään vaatimusta. [22]

Käytettävyysvaatimuksista arvioitiin myös niiden validiteetti ja todennet­

tavuus, jonka perusteella kirjoittajat tulevat lopputulokseen, ettei yksikään käytettävyysvaatimuksista täytä näitä kumpaakin. Usein puutteena on to­

dennettavuus, esimerkiksi vaatimukset “Virhetilanteisiin joutumista tulee vält­

tää” tai “Ohjelmistossa tulee olla nykyaikainen ja käyttäjäystävällinen käyttö­

liittymä” ovat sinänsä valideja, mutta niiden toteutumisen arviointi on mah­

dotonta. [22]

Yhteenvetona kirjoittajat toteavat, että jotkut viranomaiset huomioivat käy­

tettävyyden tarjouspyynnön vaatimuksissa, mutta niiden laadussa on paljon parannettavaa. Koska vaatimukset eivät ole valideja tai todennettavia tai pa­

himmillaan molempia, ne eivät aseta IT-toimittajalle todellisia vaatimuksia käytettävyydestä. [22]

3.3.4 Validien ja todennettavien käytettävyysvaatimus­

ten luominen

Jokela [14] on omassa tutkimuksessaan selvittänyt miten tarjousvaiheen käy­

tettävyysvaatimuksia voi muodostaa, jotta ne ovat valideja, todennettavia ja kattavia. Tutkimustapauksena hänellä on Oulun kaupungille toteutettava

terveydenhuoltoportaali, jossa käytettävyys on määritetty strategisesti tär­

keäksi tekijäksi. 114]

Jotta käytettävyysvaatimukset voivat olla todennettavia, niiden tulee olla mi­

tattavia. Käytettävyyden mittareista on olemassa paljon kirjallisuutta, mutta niitä sovelletaan tyypillisesti järjestelmän arviointiin. Tarjouspyyntökonteks- tissa tulee määrittää mitattavat käyttäjävaatimukset, jotka ovat lähtökohta järjestelmän kehitykselle. Tästä seuraa, että niille tulisi asettaa saavutetta­

vat tavoitetasot, mutta sopivista tavoitetasoista ei ole olemassa ohjearvoja.

[14]

Lähtökohta käytettävyysvaatimuksille tulee olla strategisissa liiketoimintave- toisissa korkean tason käytettävyystavoitteissa. Näistä johdetaan operatiivi­

set mitattavat käytettävyysvaatimukset, joissa tulee olla mitattavan vaati­

muksen kolme elementtiä: käytettävyysmittarin määritelmä, mittausinstru- mentin kuvaus ja saavutettava tavoitetaso. |14]

Tutkimustapauksessa käytettävyysvaatimukset pyrittiin luomaan ISO 9241 - 210 käytettävyyden määritelmän kolmelle attribuutille eli tehokkuudelle, tu­

loksellisuudelle ja miellyttävyydelle. Näistä ainoastaan tehokkuudelle saatiin luotua mitattava vaatimus, tehtävien onnistumisaste, joka mittaa kuinka mo­

ni käyttäjä saa suoritettua tietyn tehtävän halutusti valmiiksi. Mittausinstru- mentti on käytettävyystestaus, josta määritettiin ketkä ovat testikäyttäjiä, mitä ovat suoritettavat tehtävät ja milloin tehtävä katsotaan valmiiksi. Jot­

ta tulos olisi tilastollisesti pätevä eikä riippuvainen testihenkilöistä, tavoi­

tetasoksi määritettiin, että 95% luottamuksella 75% tavoitekävttäjistä saa suoritettua tehtävän halutusti valmiiksi. |14]

Tuloksellisuudelle ja miellyttävyydelle mitattavia vaatimuksia ei sen sijaan saatu luotua. Tuloksellisuuden mittaamisen vaihtoehdoksi pohdittiin esimer­

kiksi tehtävien suoritukseen kuluvaa aikaa, mutta koska näistä ei ollut mitään vertailuarvoja tavoitetasojen lähtökohdaksi ja projektin resurssit eivät riit­

täneet laajemman vertailututkimuksen tekemiseen, tästä luovuttiin. Myös käytettävyyden suuntaviivoja ISO 9241-110 standardista harkittiin, mutta ne ovat liian yleisellä tasolla, jolloin ne eivät ole todennettavia. Miellyttä­

vyyden mittaamiseen harkittiin esimerkiksi SUS- tai SUMI-kyselyitä, mutta myös niissä tavoitetason määrittäminen oli ongelmallista. Näiden sijaan kir­

joittaja loi työryhmänsä kanssa oman mittarin, joka pyrkii yhdistämään tu­

loksellisuuden ja miellyttävyyden, mutta kirjoittaja on itsekin skeptinen sen toimivuuden suhteen. |14]

Käytettävyysvaatimuksista, kuten muissakin vaatimuksissa, tulee huomioi­

da, etteivät ne karkota potentiaalisia tarjoajia. Tämän takia esimerkiksi mit- tausinstrumenttin tulee olla objektiivinen, toteuttajalle reilu eikä vaatia lii­

kaa resursseja [14, 20]. Oulun kaupungin terveydenhuoltoportaalin tapauk­

sessa tarjouspyyntödokumentista tuli hyvin kattava, noin 70-sivuinen doku­

mentti, johon on listattuna erikseen kaikki järjestelmän mahdollistamat teh­

tävät [14]. Koska kaupunki sai useampia tarjouksia, voidaan todeta, etteivät käytettävyysvaatimukset pelästyttäneet IT-toimittajia [14]. Artikkelin kirjoi­

tushetkellä 2010 toimittaja oli valittu ja toteutustyö alkamassa [14].

Jokelan artikkelissa tutkimustapauksena on kokonaan uuden IT-järjestelmän kehittäminen. Lauesen [20] on tutkinut käytettävyysvaatimusten luontia ta­

pauksessa, jossa hankinnan kohteena on valmis IT-järjestelmä, jota osittain muokataan ja parannetaan uudelle asiakkaalle. Tutkimustapauksena on kes­

kisuuri tanskalainen telakka, joka uusi suurimman osan liiketoimintasovelluk- sistaan. Tarjouksessa vaatimuksina käytettiin järjestelmän alkuperäisiä mää­

ritelmiä muutamalla korjauksella. Tarjouskilpailun perusteella valittiin yksi toimittaja, joka toteutti järjestelmän. [20]

Toteutuksen jälkeen järjestelmän toiminnassa havaittiin käytettävyysongel­

mia. Tutkittaessa vaatimuksia löydettiin neljä, joissa käsiteltiin käytettävyyt­

tä, esimerkiksi “Käyttöliittymän oppiminen tulee olla helppoa” ja “Kyselytoi- mintojen tulee olla nopeita ja tuntua tehokkaammilta kuin nykyinen arkis­

tointijärjestelmä, joka perustuu manuaalisiin kirjetiedostoihin”. Näiden vaa­

timusten todentaminen on vaikeaa toteutuksen aikana ja sen jälkeen, eivätkä ne ole kattavia, kuten löydetyistä ongelmista voidaan havaita. [20]

Artikkelissa Lauesen [20] luo uudet käytettävyysvaatimukset vanhojen ti­

lalle hellittämällään metodilla. Ensimmäinen vaihe on keskeisten käytettä- vyyskohteiden tunnistus esimerkiksi kriittisten tehtävien, käyttäjäprofiilien, tavoitteiden ja aikaisempien käytettävyysongelmien avulla. Kun kohteet on tunnistettu, valitaan vaatimustyylit, jotka kattavat nämä tarpeet, ja metrii­

kat ja tavoitearvot vaatimusten todentamiseen. Käytetty metodi ei ole for­

maali toimenpide vaan vaatimusten luonnissa on käytetty paljon tekijöiden luovuutta, kokemusta ja arviointia. [20]

Tapauksesta tunnistetaan 9 keskeistä käytettävyyskohdetta, kuten laskutuk­

sen tehokkuus. Näille on kerätty vaatimustyylit, joilla ne voidaan kuvata ja muotoiltu tyylien mukaiset vaatimukset. Osalle vaatimuksista annetaan vaih­

toehtoja. Esimerkiksi jos vaatimus on tehty suoritusperusteisesti ja toimittaja ei halua sitoutua tähän, voi hän valita sen sijaan prosessivaatimuksen. Osaan vaatimuksista on määritetty tavoitearvot analogisten käyttötilanteiden avul­

la, mutta osassa tavoitearvon tilalla on vain tyhjä viiva. Tässä toivotaan, että toimittajat itse määrittävät järjestelmälleen tavoitearvot, erityisesti jos kyse on olemassa olevista pakettituotteista. Tällöin hankkija saa lisää ver- tailuperusteita eri järjestelmien välillä ja toimittajat eivät jätä vastaamatta

tarjouspyyntöön liian tiukkojen vaatimusten takia. [20]

Lauesen [20] listaa kuusi tyyliä käytettävyysvaatimusten tekemiselle. Hänen tunnistamansa tyylit ovat suoritukseen, (käytettävyys)virheisiin, prosessiin, subjektiiviseen arvioon, suunnitteluun ja suuntaviivoihin perustuvat vaati­

mukset. Hänen mukaansa mikään näistä ei ole ideaalinen ja paras käytäntö on yhdistää erityylisiä vaatimuksia. [20]

Suoritusvaatimuksessa määritetään käyttäjän toimintaa ajan suhteen, esi­

merkiksi kuinka nopeasti hän saa tietyn tehtävän tehtyä. Mittaustavaksi kir­

joittaja ehdottaa käytettävyystestausta, jota voi tehdä jo prototyypeillä ke­

hityksen alkuvaiheissa. Keskeisten tehtävien ja tehokkuuden tavoitearvojen valinta vaativat vaivannäköä ia mahdollisesti iterointia toteutuksen aikana.

[20^]

Virhevaatimus voi olla esimerkiksi muotoa “Noviisikäyttäjä saa kohdata vä­

hemmän kuin 0.2 vakavaa käytettävyysvirhettä suoritettaessa tehtävää X”.

Tämä tarkoittaa, että noin 80% käyttäjistä saa tehtyä tehtävän itsenäisesti, koska vakava käytettävyysvirhe on virhe, joka estää tehtävän loppuunsaat­

tamisen. Mittaustapana on käytettävyystestaus ja käyttäjän ääneen ajat­

telu. Vaatimuksella asetetaan käytettävyysongelmien hyväksyttävä taso ja mittauksessa tunnistetaan olemassa olevat ongelmat mahdollista korjausta varten. Vaatimus ei sen sijaan kuvaa järjestelmän käytettävyyttä kattavasti, esimerkiksi päivittäisen käytön tehokkuutta. [20]

Prosessivaatimukset kuvaavat miten järjestelmä tulee toteuttaa, jotta sen käytettävyys tulee varmistettua. Esimerkiksi käytetäänkö prototyyppejä, suun­

nittelun iteratiivisuutta tai heuristista arviota. Tällöin vältetään tavoitear­

vojen löytämisen ongelma, mutta vaatimus jättää paljon avoimeksi ja toteut­

tajan oma-aloitteisuuden varaan. [20] Jokela [16] kritisoi tämän tyylisiä vaa­

timuksia, koska ne voidaan kyllä todentaa, mutta eivät sinänsä takaa käytet­

tävyyttä. Jos suunnitteluratkaisut on tehty huonojen vaatimusten pohjalta, niitä testaamalla ja parantamalla perusongelmat kuitenkin säilyvät. [ 16]

Subjektiiviseen arvioon perustuvat vaatimukset todennetaan kysymällä käyt­

täjien mielipidettä esimerkiksi haastatteluilla tai kyselyillä. Esimerkki tällai­

sesta vaatimuksesta on “80% käyttäjistä pitää järjestelmää helposti opitta­

vana”. Subjektiiviseen arvioon liittyy kuitenkin monia ongelmia, esimerkik­

si toteutustyön ulkopuoliset organisatoriset tekijät voivat vaikuttaa mielipi­

teisiin tai käyttäjät ilmaisevat olevansa tyytyväisiä, vaikka järjestelmä olisi epäkäytännöllinen. [20]

Suunnitteluvaatimukset kuvaavat käyttöliittymän yksityiskohtia, esimerkiksi näyttökuvauksin. Jos tällaiset vaatimukset on tehty huolella, saadaan toteu­

tetulle järjestelmälle suunnitelmaa vastaava käytettävyys. Huono puoli on, että mahdollisten muutosten tekeminen on mahdotonta, koska vaatimukset ovat niin tarkat. Kirjoittaja toteaa, että tätä tyyliä käytetään valitettavasti yleensä jälkimmäisellä tavalla. Käytettävyystestaamattomia prototyyppejä tulisi käyttää vain esimerkkeinä, eikä vaatimuksina sinänsä. [20]

Suuntaviivoihin perustuvat vaatimukset kuvaavat käyttöliittymän yleisiä piir­

teitä, kuten sen ulkoasun tai käyttäjälle annettavan palautteen tavat. Näiden vaatimusten todentaminen on tehtävissä, mutta vaivalloista, koska ne koske­

vat järjestelmän jokaista näkymää. Vaikka suuntaviivat yleensä parantavat käytettävyyttä, ne eivät takaa että järjestelmä on käytettävä. Tämän takia suuntaviivoihin perustuvia vaatimuksia tulisi käyttää muiden vaatimusten tukena. [20]

Yhteenvetona tutkimuksista voidaan todeta, ettei ole löydetty mitään yksi­

selitteistä suositeltavaa tapaa käytettävyysvaatimusten luontiin. Tutkimuk­

sissa on nostettu esille monia käytettävyysvaatimuksiin liittyviä ongelmia, mutta vastauksia näihin ei ole aina annettu. Parhaaksi käytännöksi muo­

dostuu erilaisten vaatimustyyppien yhdistäminen, jolloin niiden osittaisella päällekkäisyydellä voidaan kiertää toisen vaatimustyypin ongelmia.

Tutkimuksen metodologia ja aineisto

Tässä luvussa kerrotaan empiirisen tutkimuksen suorittamisen menetelmistä ja aineistosta. Luvussa kuvataan metodeihin liittyvää teoriapohjaa, rajoituk­

sia ja miksi kyseiset menetelmät on valittu juuri tähän työhön. Ensimmäi­

sessä kappaleessa esitellään päämenetelmänä eli aineiston laadullinen ana­

lyysi. Kahdessa seuraavassa kappaleessa esitellään analyysin kohteena oleva aineisto, eli kirjallinen materiaali ja teemahaastattelut, ja niiden keräämisen menetelmät. Viimeisenä luvussa käsitellään työtä tarkentavia rajauksia.

4.1 Aineiston laadullinen analyysi

Koska tutkittavat projektit ovat keskenään hyvin erilaisia ja niitä on määräl­

lisesti vähän, tutkimusmetodina on aineiston laadullinen analyysi. Metodina aineiston laadullinen analyysi vaihtelee tapauskohtaisesti riippuen tutkimus­

kysymyksestä ja materiaalista, mutta alla on kuvattuna sen peruspiirteet

[281^.

1. Tutustuminen kerättyyn dataan

Kerättyyn aineistoon tutustutaan huolella esimerkiksi lukemalla se mo­

neen kertaan. Samalla tehdään muistiinpanoja ja validoidaan datan laatua. [28|

21

2. Analyysin rajaus ja datan kategorisointi

Analyysin rajaus voidaan tehdä esimerkiksi kysymysasettelun kautta tai keskittymällä yksittäisiin kokonaisuuksiin. Analysoitua dataa kate­

gorisoidaan eli koodataan tunnistamalla teemoja ja toistuvia asioita koherentteihin kategorioihin. Kategoriat voivat olla ennalta määritel­

tyjä tai niitä voidaan muodostaa analyysin edetessä. |28|

3. Yhteyksien tunnistaminen ja tiedon tulkitseminen

Datasta pyritään löytämään esimerkiksi kategorioiden suhteellista tär­

keyttä, niiden välisiä ja niiden sisällä olevia yhteyksiä ja yläkategorioita, jotka yhdistävät useamman kategorian. Analyysin tuloksena pyritään tulkitsemaan mitä kategorisoinnilla löydetyt havainnot tarkoittavat ja mikä on niiden merkitys. Tulokset kootaan mielekkäästi selitetyksi ko­

konaisuudeksi. [28]

Laadullisen analyysin avulla käsiteltävänä tutkimusaineistona on projektien kirjallista materiaalia ja projekteihin osallistuneiden Luottokunnan ja Accen­

turen avainhenkilöiden haastatteluja. Seuraavissa kappaleissa kerrotaan tar­

kemmin kirjallisen ja haastattelumateriaalin keruusta ja niissä käytetyistä menetelmistä.

4.2 Kirjallinen materiaali

Projektien kirjallinen materiaali on koottu projekteihin osallistuneilta hen­

kilöiltä sähköpostitse pyytämällä tai Luottokunnan ja Accenturen hankinta- ja myyntiorganisaatioiden jäseniltä. Suurin osa materiaalista on kuitenkin kerätty itsenäisesti projektien arkistokansioita, joihin on koottu kaikki pro­

jektin aikainen materiaali. Saatu materiaali vaihtelee tapauksesta toiseen, mutta kaikista projekteista pyrittiin saamaan mahdollisimman paljon pro­

jektin hankintaan liittyvää dokumentaatiota, kuten vaatimuslistauksia, ko­

kousmuistioita, sopimuksia ja tarjouksia.

Tässä työssä tutustutaan kolmeen eri projektiin, jotka ovat Korttitilitysten raportointipalvelu, Business Eurocard -uudistus ja Luottokunta Sopimuspor- taali, jotka kuvataan tarkemmin kappaleessa 5.2 Tutkittavat projektit. Näistä projekteista käsitellyt dokumentit on koottu kolmeen erilliseen taulukkoon.

Taulukosta 1 löytyvät Korttitilitysten raportointipalvelu -projektin, taulu­

kosta 2 Business Eurocard -uudistuksen ja taulukosta 3 Luottokunta Sopi- musportaali -projektin tässä työssä käsitellyt dokumentit.

Taulukoihin koottujen dokumenttien lisäksi tutustuttiin yli kolminkertaiseen määrään dokumentaatiota. Tähän työhön valikoituivat saaduista dokumen­

teista ne, joiden päivämäärä edelsi tai oli sama kuin projektin hankintapää­

tös ja joissa kuvailtiin järjestelmää, sen ominaisuuksia, hankintaa tai tulevaa projektia. Valitut dokumentit antavat kuvaa projektin määrittelystä ja ra­

jauksesta ennen hankintaa ja hankintaprosessin etenemisestä. Dokumenteista karsittiin pois kaikki hankinnan jälkeinen, projektityönä toteutettu materi­

aali ja muihin kuin tutkittuihin projekteihin kuuluva materiaali. Jos samasta dokumentista oli useampi versio, niistä valittiin tutkimukseen mukaan han- kintapäivää edeltävistä viimeisin versio.

Taulukko1:Korttitilitystenraportointipalvelu-projektinkäsiteltyvaatimus-

j a

ooo oCM

00o oCM

CM

00o oCM

00o oCM

<D ai

ooo oCM Oi

00o oCM

<D LOCM

00o oCM

CO

r-LO

"en>

00xr

d d

>

LOen

‘en>

CMCO DCM

>en CM Oen

O

o

en

£

ir.O -öo;

S

c CD en S

"Co3 3dcfi S

'oc

Cu—

Oi£

CUO

c/1o -oQJ

-Ui

s en o en

>= 4U 3 en Ui d end

d d :d d d d > d d >

ä ³³ d -us

0 en d 0 en dd

JO3, d E dd

JD

o a;

en

£ S .i

,§ d e<D 'o1u

a d en a5 >

G 5 o5 ^

dcti

tig tio5

K en

tio5

cd en -s 11S ci G 3dc .25 cdcd aO) E 3d £o a

>> cd

cd >

C 3d 3

■43c 25 s ä >»

oc .s

s

ti

eCD

'o1u CL

:ti:c5 dd dE äo5 äd L5do5 K

■4J dd -ä i g

■% j*

>) 3

-4Jd

CD

Ed -LtO T5r>3

eä>

d

’Sen

>3 .s eCD

’o_S—<

(X j;K*-) .S s.o

’o*Ui Ph

do5

>

3en 3 .S ,2eCD

*o_u Ph

do

CD

Ou

>3

:cäd

d 2 ti 2

cd d

-Li >

£ 5 O ^ -uti_en

*cn d

C Ga; o

^ id ’o

cd ^ H

•E ä .23

£ £ s -S ^ °

1_{cu cd} 53

cd

• S E■i 3

3d .3

e ticd 5

K >

ti d 55 tCD dL2 >

-LdO J3 ä .t: oT o •—

o '—1

•E 0

•d q; +2 en a; ^ T3 2 0) 3 3 en dd .d

äo

^den 3j>

15CL

tC<D

£d 4-Jen

1

4-0+0<D

4-0

PLa o dg

*0

"3Em

T-d

^2 ti 3 :d:d O

Oh

en

<D

dPL PLO dti 'oS 3_4-0x ddd dK*~l : d :d

dc Oh

s

.d CD d ^ O en -E Eqjen ti E

4-0 CD

-d a;o5 en ä 5>- o 3 24J ID :d ^:d iS S S

J4_D

"o'_u a dD

ddX Sd

tDL2u

4-0d ä g>> E

D 3

tidti

"tio

3

"sD

:ti :ti

E

:tio:

tio;

T3ti

"ti

Sh

tiO OSh

Mti

oCM CM CM

00o oCM

CM O CM O CM

O CM

O CM

-ti -ti

:ti :ti

> >

:cd :cd

O a; O) M T3 T3

>

1

cd O _>

"cd

-Cd

cd O>

1

CD

cd

J>O Oried CO

OriC Ori

£ M

en

—

'en0 1 C

"o

Oh s-,<D

£O Oh

ento

"og Oh fcH CL

£O

0-

g

'oOh CD

•So

Oh

enO.

O

CL,Sh CD

£O Oh

ecd

S -en .EOri to

S "E

JS eK cd

- 'E

-4-01

"ti 3/

:E ci

£ § S e

E f ti ti ti 03 .E DE E

Ori Ori C o cd TJ

cc ^

-4-0e

4-3

' ti

:rr :ti

tidti

"tiO

5

tidti

^ C/h

JD

.S

"ti

tid

"o

Sh Dh

titi

>ti

tid03

*5

^5

.S

3do;

‘oSh

Dh

CD tido

-dd

£

ti 03

O ti

^ ti ti ti03

"ti ti03

tidti ti

£ ti0

1

§03 ti ^d

:titi

*03 03

"ti 03 titi _j 03 -4J

ti •—<

I 1

.E cd

Ori CL

e cdcd +=

cd ^S

CSh

a

3^.ti

:ti

-3

"ti

03ti ti

g Id

4-3 ’CT5 03 C ti *-<

ti CL titi

> ti ti <D

4-3 c/3

I S

OriOi

en

Ori >

Ö S=5 Cd en

CD ,b

es ä

ti ti

^dO tide

►> K ä scd rti

-H ti ti

Oh