Aalto-yliopisto Perustieteiden korkeakoulu Informaatioverkostojen koulutusohjelma Anna Törrönen Käytettävyyden huomioiminen IT-järjestelmien hankinnassa Diplomityö Helsinki, 19. helmikuuta 2012 Valvoja: Ohjaaja: Professori Marko Nieminen, Aalto-yliopisto Tekniikan tohtori Kari Pihkala, Accenture Oyj i
Aalto-yliopisto Perustieteiden korkeakoulu Informaatioverkostojen koulutusohjelma DIPLOMITYÖN TIIVISTELMÄ Tekijä: Anna Törrönen Työn nimi: Käytettävyyden huomioiminen IT-järjestelmien hankinnassa Päiväys: 19. helmikuuta 2012 Sivumäärä: 8 + 77 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ä hetkellä huomioon Luottokunnassa IT-järjestelmän hankintavaiheessa ja tehdään suosituksia, miten se voitaisiin vastaisuudessa ottaa vahvemmin mukaan. Tutkimuksen kohteena ovat Luottokunnan ja Accenturen yhteistyö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 yrityksen tasoinen ohjeistus. Käytettävyyttä pidettiin kuitenkin tärkeänä laatuominaisuutena ja siihen halutaan panostaa, jos sen merkitys on projektin lopputuloksen kannalta keskeinen. Tutkimustulosten pohjalta Luottokunnalle annettiin suositukset käytettävyyden huomioinnista hankinnassa. Nämä suositukset koostuvat tarkemmasta käyttäjäryhmien määrittämisestä, käytettävyyden merkityksen arvioinnista ennen projektin hankintaa, käytettävyyden huomioimisesta prosessitasolla ja Luottokunnan käyttöliittymäohjeistuksen ja ulkoasumallin laatimisesta. Avainsanat: Kieli: Käytettävyys, hankintatoimi, käytettävyysvaatimukset, hankinnan määrittely, IT-järjestelmä suomi ii
Aalto University School of Engineering Degree Program of Information Networks ABSTRACT OF MASTER'S THESIS Author: Anna Törrönen Title of thesis: Taking Usability into Account in the Procurement Process of IT-systems Date: February 19, 2012 Pages: 8 + 77 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 procurement 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 denition material that predates the procurement decision. In addition, how usability was addressed varies from project to another, because Luottokunta was lacking any company level instructions 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 signicant 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 research. These were more detailed denition of user groups, dening the signicance of usability before the project starts, addressing usability on the process level and creating Luottokunta's own user interface and appearance guides. Keywords: Language: Usability, procurement, usability requirements procurement denitions, IT-system Finnish iii
Esipuhe Tätä työtä ei olisi syntynyt ilman Luottokunnan ja Accenturen suostumusta ja koen olevani etuoikeutettu, että pääsin käsiksi näin hienoon tutkimusaineistoon. 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 pohdintojani 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 heikompi ilman valvojaani professori Marko Niemistä ja ohjaajani Kari Pihkalaa, 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 palautuspä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. Speksiyhteisö, 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 valmistuminen on epätodennäköisempää kuin levitoimisen oppiminen, lähdin merenrantalenkille Usvan ja Zuleykan kanssa ja asiat olivat taas paljon paremmin. Järvenpäässä 19. helmikuuta 2012 Anna Törrönen iv
Sisältö 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.... 12 3.3.1 Käytettävyysvaatimusten rooli IT-järjestelmien hankinnassa............................ 12 3.3.2 Hankkijan ja toimittajan rooli.............. 13 3.3.3 Käytettävyysvaatimukset tarjousvaiheessa....... 14 3.3.4 Validien ja todennettavien käytettävyysvaatimusten luominen........................... 16 4 Tutkimuksen metodologia ja aineisto 20 4.1 Aineiston laadullinen analyysi.................. 20 v
4.2 Kirjallinen materiaali....................... 21 4.3 Teemahaastattelut........................ 27 4.4 Tutkimuksen rajaukset...................... 29 5 Tutkimuksen tausta 30 5.1 Tutkimuksen yritysosapuolet - Luottokunta ja Accenture... 30 5.1.1 Hankinta Luottokunnassa................ 31 5.2 Tutkittavat projektit....................... 32 5.2.1 Korttitilitysten raportointipalvelu............ 32 5.2.2 Business Eurocard -uudistus............... 35 5.2.3 Luottokunta Sopimusportaali.............. 37 6 Tulokset 41 6.1 Käytettävyyden huomioiminen hankinnan kirjallisessa materiaalissa.............................. 41 6.1.1 Projekteista tunnistettavissa olevat käytettävyysvaatimukset........................... 42 6.1.2 Käytettävyyden huomioiminen projektien muussa hankinnan määrittelydokumentaatiossa........... 46 6.2 Haastattelutulokset........................ 48 6.2.1 Hankintaprosessi ja hankinnan määrittely yleisellä tasolla............................ 49 6.2.2 Käytettävyyden huomiointi hankinnan määrittelyssä. 52 7 Tulosten analyysi ja johtopäätökset 58 7.1 Tulosten analyysi......................... 58 7.1.1 Yhteenveto projektien käytettävyysvaatimuksista... 59 7.1.2 Yhteenveto käytettävyyden huomioinnista projektien muussa hankinnan määrittelydokumentaatiossa.... 59 7.1.3 Yhteenveto käytettävyyden huomioinnin haastattelutuloksista......................... 60 7.1.4 Yhteenveto käytettävyyden huomioinnin nykytilasta hankintavaiheessa Luottokunnassa.............. 61 vi
7.2 Suositukset Luottokunnalle käytettävyyden huomioinnista hankinnan määrittelyssä....................... 61 7.2.1 Hankintaprosessi..................... 62 7.2.2 Hankinnan määrittely.................. 63 7.2.3 Käytettävyyden huomiointi hankinnan määrittelyssä. 64 8 Yhteenveto ja pohdinta 66 8.1 Pohdintaa annetuista suosituksista............... 67 8.2 Tutkimuksen luotettavuus ja yleistettävyys........... 68 8.3 Jatkotutkimuskysymyksiä.................... 71 Lähdeluettelo 71 A Teemahaastattelujen rakenne 75 vii
Taulukot 1 Korttitilitysten raportointipalvelu -projektin käsitelty vaatimusja määrittelydokumentaatio................... 23 2 Business Eurocard -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio........................ 24 3 Luottokunta Sopimusportaalin -uudistuksen käsitelty vaatimusja määrittelydokumentaatio................... 25 4 Haastatellut henkilöt....................... 28 5 Korttitilitysten raportointipalvelu -projektin hankintaa edeltäneiden vaatimusten tyyppi ja määrä.............. 43 6 Eri projektien sisältämien käytettävyysvaatimusten määrä.. 59 viii
Luku 1 Johdanto Käytettävyys on laatuominaisuus, joka kuvaa tuotteen tai palvelun tehokkuutta, tuottavuutta ja miellyttävyyttä [13]. Käytettävyys on myös liiketoiminnallisesti merkittävää, koska se vaikuttaa esimerkiksi parantamalla tuottavuutta ja asiakasuskollisuutta ja vähentämällä virheitä ja tarvittavaa 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 blogeja, 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ä, sillä VR:n ja sähköisen äänestyksen tilanneen oikeusministeriön toimintaan ei kuulu IT-järjestelmien toteuttaminen. Nämä järjestelmät on hankittu ulkopuoliselta toimittajalta kilpailutuksen kautta. Hankkija, eli VR tai oikeusministeriö, on tehnyt toimittajille tarjouspyynnön, jossa he kuvaavat mitä tulevalta järjestelmältä toivotaan, ja tähän toimittajat ovat vastanneet omalla tarjouksellaan. Käytettävyyden kannalta ei ole epäolennaista mitä tarjousvaiheessa hankkijan ja toimittajan kesken sovitaan. Projektin aikataulu, budjetti ja resurssit asettavat puitteet myös mitä käytettävyyden eteen voidaan tai halutaan tehdä. Jos tarjouspyynnössä ei edellytetä järjestelmän käytettävyyttä, ei toimittaja 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. 1
LUKU 1. JOHDANTO 2 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 olennaista, 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ä tehtäisiin. Projektin alkuvaiheessa tehdään myös isot linjaukset, joilla on vaikutusta järjestelmän käyttökokemukseen. Silloin lyödään lukkoon esimerkiksi käytettävä toteutustapa, joka luo muulle tekemiselle rajoitukset ja mahdollisuudet. 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 projektin alusta asti. On löydettävissä jonkin verran tutkimuksia, joissa käsitellään tarjousprosessia ja hankinnan aikaista käytettävyyden huomioimista esimerkiksi vaatimuksina. Näissä tutkimuksissa on havaittu, että tarjouspyyntöjen käytettävyysvaatimukset ovat puutteellisia tai niitä ei yksinkertaisesti ole, jolloin vastuu käytettävyydestä ei siirry halutusti hankkijalta toimittajalle [22]. Tässä työssä tutustutaan käytettävyyden huomiointiin projektin hankintavaiheessa. Empiirisessä tutkimuksessa käydään läpi kolme projektia, joiden avulla selvitettiin, mikä on käytettävyyden huomioinnin nykytaso Luottokunnassa. Työn tavoitteena on myös selvittää, miten käytettävyysnäkökulma saadaan konkretisoitua ja tuotua mahdollisimman varhain mukaan projektiin. 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 huomioinnin nykytilanne hankintavaiheessa. Tutkimuksen pohjalta pyritään esittämään, miten käytettävyyteen liittyviä asioita voitaisiin vastaisuudessa ilmaista 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
LUKU 1. JOHDANTO 3 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 teoriapohja, tutkimuksen tausta, tutkimuksen tulokset ja niiden analyysi sekä yhteenveto ja pohdinta. Tutkimuksen teoria rakentuu luvuista 2 Hankintatoimi ja 3 Käytettävyysvaatimukset, joissa käydään läpi hankintatoimea ja hankinnan määrittelyä yleisellä tasolla ja tarkemmin käytettävyysvaatimuksia. Työn empiriaosuus aloitetaan tutkimuksen taustoituksella. Luvussa 4 Tutkimuksen metodologia ja aineisto kerrotaan käytetystä metodologiasta ja luvussa 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ä johtopää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.
Luku 2 Hankintatoimi Tässä luvussa kerrotaan hankintatoimesta yrityksen toimintona ja siihen liittyvästä teoriasta. Luvussa käsitellään hankintatoimen yleiskuvauksen jälkeen hankinnan määrittelyä ja toimittajan valintaa, jotka liittyvät läheisesti tutkittavaan tapaukseen. Lopuksi käsitellään IT-järjestelmien hankinnan erityispiirteitä suhteessa muihin hankintoihin, IT-ulkoistuksia ja strategista kumppanuutta. 2.1 Hankintatoimi Hankintatoimi ohjaa organisaation ulkopuolisilta tahoilta tekemiä ostoja. Hankinnat ovat resursseja, tuotteita tai palveluita, joiden avulla saavutetaan organisaation yleisiä ja erityisiä liiketoiminnallisia tavoitteita tai ylläpidetään sen olemassa olevaa toimintaa. Hankinnat pyritään tekemään organisaation kannalta optimaalisesti, esimerkiksi hinnan, laadun ja toimitusajan suhteen. Usein hankintahintaa olennaisempaa on laskea hankinnan kokonaiskustannus, 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 organisaatio ei voi tai jota sen ei ole kannattavaa itse täyttää. Tästä tarpeesta 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ää potentiaalisista toimittajista, valmistella hankintaa ja käydä neuvotteluja sopimuksen aikaansaamiseksi. Hankkijan tulee seurata toimittajan toimintaa, jotta varmistetaan hankinnan eteneminen. Kun haluttu kokonaisuus on toi- 4
LUKU 2. HANKINTATOIMI 5 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ää esimerkiksi 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äärittely ja toimittajan valinta Hankintaprosessin ensimmäinen askel sisäisen tarpeen havaitsemisen jälkeen on hankinnan tarkempi määrittely. Hyvät määritykset ovat olennaisia, koska toimittajat tarjoavat hankkijalle tuotteita ja palveluita näiden pohjalta. [29] Määritykset esitetään usein vaatimuksina, jotka ovat sanallisia kuvauksia halutuista ominaisuuksista. VanWeelen mukaan [29] vaatimukset voidaan jakaa teknisiin ja toiminnallisiin vaatimuksiin. Teknisiä vaatimuksia ovat esimerkiksi halutun tuotteet kaaviokuva tai tietyn tekniikan käyttäminen sen valmistuksessa. Toiminnalliset vaatimukset sen sijaan kuvaavat korkeammalla 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 vaatimukset 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 kompleksinen, hankkija voi toimia yhteistyössä toimittajien kanssa, jolloin neuvotteluissa tarkennetaan itse hankinnan vaatimuksia. [30]
LUKU 2. HANKINTATOIMI 6 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 toimittajat voivat osallistua, on lainsäädännöllinen vaatimus, jolla pyritään estämään korruptiota ja nepotismia. Esimerkiksi Euroopan unionin lainsäädännössä määritellään, että julkishallinnon organisaatioiden tulee tehdä julkinen tarjouspyyntö (engl. request for tender, RFT) hankittaessa ulkopuoliselta toimittajalta [22]. Tällöin viranomaisen tulee valita se toimittaja, jonka tarjous vastaa parhaiten tarjouspyynnössä määritettyjä vaatimuksia ja valittu toimittaja sitoutuu tuottamaan tarjouksensa mukaisen järjestelmän [22]. Yksityisellä sektorilla käytetään yleisemmin suljettua tarjouskilpailua. Suljetussa tarjouskilpailussa tarjouksen pääsevät tekemään vain ennalta määritellyt, potentiaaliset toimittajat [29]. Hankkijaorganisaatio kokoaa toimittajista niin sanotun pitkän listan, johon kerätään kaikki potentiaaliset, esiehdot täyttävät toimittajat [29]. Näille toimittajille voidaan lähettää tiedustelupyyntö (engl. request for information, RFI), jossa pyydetään heitä esimerkiksi kuvaamaan 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 pitkän listan toimittajista on karsittu pois. Listan toimittajille voidaan lähettää 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 niiden kehitystä, verkkoyhteyksiä, konesalihuoneiden rakentamista, huolto- ja ylläpitopalveluita ja ulkoistamista [19]. Uusi teknologia tuo tullessaan myös organisaation toimintaan ja prosesseihin vaikuttavia muutoksia, jotta tuottavuutta saadaan aidosti parannettua [5]. Verrattuna esimerkiksi raakamateriaalien hankintaan, joka on organisaation operatiivista toimintaa, uuden IT-järjestelmän hankinta on yleensä luonteeltaan strategista ja keskittyy yrityksen tuotteiden sijasta itse yrityksen toiminnan mahdollistamiseen.
LUKU 2. HANKINTATOIMI 7 Fisher [10] esittää, että hankintapäätöksen tekemisen prosessiin vaikuttaa pääasiallisesti kaksi tekijää, jotka ovat hankinnan monimutkaisuus ja taloudellinen epävarmuus, jotka liikkuvat skaalalla matala-korkea. Tuotteen korkeaa monimutkaisuutta kuvaavat esimerkiksi kustomointi, monimutkainen teknologia, asennuksen vaikeus ja oston jälkeisen tuen tarve, kun taas korkeaa taloudellista epävarmuutta kuvaavat esimerkiksi suuri sijoitettava summa, pitkäaikainen vaikutus, organisaation sopeutuksen tarve ja suuri vaikutus taloudelliseen 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, aikaa vievempää ja useamman eri näkökulmien edustajien osallistumista vaativampi 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 hankintaprosessin keskeiset toiminnot. Lähtökohtana ovat IT-hankintaprosessin strategiset tavoitteet: nopea ja tehokas hankintojen käsittely, mahdollisimman korkealaatuisten IT-tuotteiden, ratkaisujen ja palveluiden hankinta sekä mahdollisimman hyvät hintajärjestelyt [19]. IT-hankintaprosessista tulee suunnitella hankintamenettelyt, luoda tarjousten arviointikriteerit, valvonta ja budjettihyväksyntä ja rajata mitä hankintoja 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 pohjalta tehdä hankintaehdotus tarpeellisesta hankinnasta. Ehdotuksessa kuvataan tarkasti mitä vaatimuksia hankittavaan tuotteeseen, ohjelmistoon tai palveluun liittyy [19]. Ehdotukseen voidaan suoraan lisätä aikaisemmin käytetyt ja uudet IT-toimittajat, jolta hankinnan voi tehdä [19]. Jos hankintaehdotus hyväksytään, lähdetään tutkimaan markkinoita tavoitteena 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 analyysi, oikeudelliset näkökohdat ja arviointiperusteet. Sen perusteella potentiaalisten 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
LUKU 2. HANKINTATOIMI 8 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. Sopimuksessa voidaan määrittää esimerkiksi toimituksen laajuus ja aikataulu. Hankkija valvoo, että toimittaja toimittaa tai tuottaa kaikki sopimuksen määrittämät tuotteet ja palvelut sopimuksen ehtojen mukaisesti. Kun hankkijan 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 projektin 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 rajaukseen 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, hyväksymiskriteerit sekä virheidenkorjaus- ja valitusmenettelytavat. [19] 2.3.1 IT-ulkoistus ja strateginen kumppanuus IT-ulkoistuksessa osa tai kaikki organisaation IT-toiminnoista siirretään ulkopuoliselle toimijalle. Koska IT on keskeinen ja strategisesti tärkeä osa organisaation toimintaa jälkiteollisessa taloudessa, kyse ei ole pelkästään palvelujen hankinnasta ulkopuoliselta toimittajalta, vaan hankkijan ja toimittajan välille syntyy väistämättä keskinäisesti riippuvainen strategisen kumppanuuden suhde [27]. IT-ulkoistuksen etuja ovat keskittyminen omaan ydintoimintaan, mahdolliset kustannussäästöt, teknologian tason nostaminen ja ulkoistuksen mahdollistama organisaation oman IT-kyvykkyyden vapautuminen rutiinien suorittamisen sijaan suunnittelemaan liiketoimintaan vaikuttavia strategisia toimia. Ulkoistuksen riskejä ovat ulkoistuksen vaikea peruminen, eli organisaation sisäisen IT-kyvykkyyden uudelleenkokoaminen, ja tietyn joustavuuden menettäminen, jos organisaatio sitoutuu määrättyyn teknologiaan tai lisensseihin. [27] Jotta ulkoistuksen riskit saadaan minimoitua, toimittajalla tulee olla syvällinen ymmärrys hankkijan liiketoiminnasta ja osapuolten välillä tulee vallita tiukka luottamus, jotta esimerkiksi strategisesti tärkeää tietoa voidaan käsitellä. Myös samankaltainen yrityskulttuuri ja strategiset tavoitteet tekevät ulkoistuksesta helpommin molempia osapuolia hyödyttävän. [27]
Luku 3 Käytettävyysvaatimukset Tässä luvussa kerrotaan käytettävyysvaatimuksista ja niihin liittyvästä teoriasta. Luvussa käsitellään ensin käytettävyysvaatimusten yläluokkaa vaatimuksia ja mitä ominaisuuksia on hyvillä vaatimuksilla. Tästä syvennetään käytettävyysvaatimuksiin ja niiden erityispiirteisiin keskittyen käytettävyysvaatimusten mitattavuuteen. Viimeiseksi käsitellään käytettävyysvaatimusten roolia IT-järjestelmien hankinnassa ja validien käytettävyysvaatimusten luomisen problematiikkaa. 3.1 Vaatimukset Vaatimukset ovat sanallisesti muotoiltuja kuvauksia, mitä tulevan järjestelmän tulee tehdä tai mitä ominaisuuksia sillä tulee olla. Eri lähteistä on löydettävissä erilaisia ominaisuuksia hyville vaatimuksille. Hyvät vaatimukset ovat esimerkiksi tarpeellisia, priorisoituja, yhtenäisiä, täydellisiä ja johdonmukaisia [9, 31]. Tässä työssä keskitytään erityisesti vaatimusten validiteettiin ja todennettavuuteen, koska näissä on havaittu ongelmia aikaisemmassa tutkimuksessa [22, 14]. Validit vaatimukset ovat oikeellisia, hyvin perusteltuja ja sovellettavissa kyseiseen tapaukseen. Todennettavat vaatimukset ovat osoitettavissa toteutetuiksi objektiivisella tavalla. Vaatimukset voidaan jakaa niiden tyypin mukaisesti erilaisiin luokkiin. Kappaleessa 2.2 Hankinnan määrittely ja toimittajan valinta esiteltiin tekniset, toiminnalliset ja ei-toiminnalliset vaatimukset. Teknisiä vaatimuksia ovat esimerkiksi käytettävä ohjelmointikieli tai valmistustekniikka [29]. Toiminnalliset vaatimukset sen sijaan kuvaavat korkeammalla tasolla mitä toimintoja järjestelmän tulee mahdollistaa [29]. Ei-toiminnalliset vaatimukset kuvaavat 9
LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 10 laatuominaisuuksia tai järjestelmän yleisiä toimintaperiaatteita [20]. Näiden yläkategorioiden sisällä vaatimuksia voidaan jaotella eri tavoilla esimerkiksi vaatimusten kohteen tai lähteen mukaisesti käyttöliittymä- ja arkkitehtuurivaatimuksiin tai liiketoiminnallisiin ja asiakaspalvelun vaatimuksiin. Hankintaprosessin alkuvaiheessa hankkija kerää omalta organisaatioltaan vaatimuksia tulevan järjestelmän halutuista toiminnallisuuksista ja ominaisuuksista. 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, aivoriihet, kohderyhmät ja työpajat ja/tai kirjalliseen materiaaliin tutustuminen. [21, 8] Käyttäjiä osallistavien menetelmien, kuten työpajojen tai haastattelujen, tavoitteena 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äminen. [16] 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 takaaminen. Suosittu lähde käytettävyyden määrittämiseen on ISO 9241-110, jonka mukaan käytettävyyden ominaisuudet ovat tuloksellisuus, tehokkuus ja mielekkyys [13]. Kuitenkin käytettävyysvaatimusten muodostamisen tulisi olla jokaiselle tapaukselle ja organisaatiolle yksilöllistä, koska muuten vaarana on mekaaninen standardin täyttämiseen pyrkiminen [4].
LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 11 Käytettävyysvaatimukset ovat eri asia kuin käyttäjävaatimukset. Käyttäjävaatimukset kuvaavat mitä eri sidosryhmien tulee järjestelmällä saada aikaiseksi, kun taas käytettävyysvaatimukset ovat korkeamman tason laatuvaatimuksia. Käyttäjävaatimukset siis ovat järjestelmän toiminnallisia vaatimuksia (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äratkaisuja tai -elementtejä järjestelmässä käytetään, vaan oleellista on, miten ne toimivat käytännössä [16]. Tämän takia käytettävyysvaatimusten ei tulisi tarjousvaiheessa olla liian tarkkoja ja esimerkiksi määrittää eksplisiittisiä suunnitteluratkaisuja. Tällöin päästään täysimittaisesti käyttämään hyväksi ITjärjestelmän toimittajan erikoisosaamista suunnitteluratkaisujen tuottamisesta [15]. 3.2.1 Käytettävyysvaatimusten todennettavuus ja mitattavuus Wilson [32] nimeää yhtenä käyttäjäkeskeisen suunnittelun tulevaisuuden trendinä 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 asiantuntijoita keräämään metriikoita, joilla osoitetaan, miten ei pelkästään tuotetta, vaan myös prosessia on parannettu. Voidaanko esimerkiksi osoittaa, että havaitsemalla virheet aikaisemmin, on vähennetty niiden korjaukseen kuluvaa aikaa. [32] Wilson tuo esille käytettävyysalan suuren ongelman eli tulosten todennettavuuden 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äyttä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 termejä, miten voidaan varmistaa, että ne on saavutettu? Sanonta sitä saadaan, mitä mitataan kuvaa ohjelmistokehitystyön arkea. Käyttäjäkeskeisen suunnitteluprosessin tarkoituksena on tuottaa mahdollisimman 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 takia on keskeistä määrittää mitkä ovat järjestelmän käytettävyysvaatimukset ja -tavoitteet. Täydellistä järjestelmää on mahdoton saavuttaa, joten yleensä sovitaan joku hyväksyttävä taso tai käytettävyysongelmien määrä, jolla
LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 12 järjestelmä katsotaan riittävän hyväksi [21]. Erilaiset metriikat ovat hyödyllisiä testattaessa esimerkiksi järjestelmän suorituskykyä ja niillä saatava tieto on kvantitatiivista. Kuitenkin, jotta järjestelmä tulee arvioitua kattavasti ja osataan löytää parannuskohteita, tarvitaan myös kvalitatiivista tietoa. [8] Mahdollisia käytettävyyden mittareita ovat esimerkiksi tehtävän suorittamiseen käytettävä aika, (käytettävyys)ongelmien lukumäärä, näppäinpainallusten määrä, mielipidekyselyn tulokset, ymmärryksen mittaaminen sekä käyttöliittymäohjeiden ja -periaatteiden noudattaminen (engl. guideline adherence) [21]. Validien ja todennettavien käytettävyysvaatimusten luomisen problematiikkaa avataan enemmän kappaleessa 3.3.4 Validien ja todennettavien käytettävyysvaatimusten luominen. Kappaleesssa niitä käsitellään tutkimustapauksen mukaisesti IT-järjestelmien käytettävyysvaatimusten näkökulmasta teoriasta 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 hankintavaiheessa eri näkökulmista. Ensimmäisessä kappaleessa käytettävyys rinnastetaan järjestelmän muihin laatuominaisuuksiin. Toisessa kappaleessa keskitytään siihen, kuka on lopulta vastuussa käytettävyydestä ja miten vaatimukset vaikuttavat tähän. Kahdessa viimeisessä kappaleessa tutustutaan tutkimustapausten kautta käytettävyysvaatimuksiin tarjousvaiheessa ja validien ja todennettavien käytettävyysvaatimusten luomiseen. 3.3.1 Käytettävyysvaatimusten rooli IT-järjestelmien hankinnassa 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 esimerkiksi virheettömyys, saavutettavuus, suorituskyky, tietoturvallisuus ja ylläpidettävyys [21]. Osa näistä voidaan nähdä myös käytettävyyden osaalueina, esimerkiksi virheettömyys ja suorituskyky vaikuttavat vahvasti käyttökokemukseen, mutta niissä saavutettu taso riippuu pitkälti teknisistä lähtökohdista. Vaatimusten todennettavuuden vaikeus ei liity pelkästään käytettävyysvaa-