Käytettävyyden huomioiminen IT-järjestelmien hankinnassa
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 DIPLOMITYÖN Informaatioverkostojen koulutusohjelma 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 Professuuri: Käyttöliittymät ja käytettävyys Koodi: T-121 Työn valvoja: Professori Marko Nieminen + 77 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: Käytettävyys, hankintatoimi, käytettävyysvaatimukset, hankinnan määrittely, IT-järjestelmä Kieli: suomi ii Aalto University School of Engineering ABSTRACT OF Degree Program of Information Networks Author: MASTER'S THESIS Anna Törrönen Title of thesis: Taking Usability into Account in the Procurement Process of IT-systems Date: Pages: 8 February 19, 2012 Professorship: Usability and User Interfaces Supervisor: Professor Marko Nieminen Instructor: Kari Pihkala Ph.D. (Tech.) + 77 Code: T-121 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: Usability, procurement, usability requirements procurement denitions, IT-system Language: 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 2 3 Johdanto 1 1.1 Tutkimuskysymykset ja tavoitteet . . . . . . . . . . . . . . . . 2 1.2 Diplomityön rakenne 3 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 8 IT-ulkoistus ja strateginen kumppanuus . . . . . . . . Käytettävyysvaatimukset 9 3.1 Vaatimukset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Käytettävyysvaatimukset . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 3.3 Käytettävyysvaatimusten todennettavuus ja mitattavuus 11 Käytettävyysvaatimukset IT-järjestelmien hankinnassa 3.3.1 . . . . 12 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 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Tutkimuksen metodologia ja aineisto 20 4.1 20 Aineiston laadullinen analyysi . . . . . . . . . . . . . . . . . . v 5 4.2 Kirjallinen materiaali . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Teemahaastattelut . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4 Tutkimuksen rajaukset . . . . . . . . . . . . . . . . . . . . . . 29 Tutkimuksen tausta 5.1 Tutkimuksen yritysosapuolet - Luottokunta ja Accenture . . . 30 . . . . . . . . . . . . . . . . 31 . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.1 Korttitilitysten raportointipalvelu . . . . . . . . . . . . 32 5.2.2 Business Eurocard -uudistus . . . . . . . . . . . . . . . 35 5.2.3 Luottokunta Sopimusportaali 37 5.1.1 5.2 6 30 Hankinta Luottokunnassa Tutkittavat projektit . . . . . . . . . . . . . . Tulokset 6.1 41 Käytettävyyden huomioiminen hankinnan kirjallisessa materiaalissa 6.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projekteista tunnistettavissa olevat käytettävyysvaatimukset . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 6.2 42 Käytettävyyden huomioiminen projektien muussa hankinnan määrittelydokumentaatiossa . . . . . . . . . . . 46 Haastattelutulokset . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1 Hankintaprosessi ja hankinnan määrittely yleisellä tasolla 6.2.2 7 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Käytettävyyden huomiointi hankinnan määrittelyssä . 49 52 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 7.1.3 . . . . 59 Yhteenveto käytettävyyden huomioinnin haastattelutuloksista 7.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Yhteenveto käytettävyyden huomioinnin nykytilasta hankintavaiheessa Luottokunnassa . . . . . . . . . . . . . . vi 61 7.2 Suositukset Luottokunnalle käytettävyyden huomioinnista hankinnan määrittelyssä 8 . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Hankintaprosessi . . . . . . . . . . . . . . . . . . . . . 7.2.2 Hankinnan määrittely 7.2.3 Käytettävyyden huomiointi hankinnan määrittelyssä . . . . . . . . . . . . . . . . . . . Yhteenveto ja pohdinta 61 62 63 64 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 2 23 Business Eurocard -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Luottokunta Sopimusportaalin -uudistuksen käsitelty vaatimusja määrittelydokumentaatio . . . . . . . . . . . . . . . . . . . 25 4 Haastatellut henkilöt . . . . . . . . . . . . . . . . . . . . . . . 28 5 Korttitilitysten raportointipalvelu -projektin hankintaa edel- 6 täneiden vaatimusten tyyppi ja määrä . . . . . . . . . . . . . . 43 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 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 2 LUKU 1. JOHDANTO 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. 3 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 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] 5 LUKU 2. HANKINTATOIMI 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. 6 LUKU 2. HANKINTATOIMI 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 7 LUKU 2. HANKINTATOIMI 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] 8 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 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]. 10 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 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 11 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 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- 12 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET timuksiin, vaan samaa epämääräisyyttä on havaittavissa myös muissa ITjärjestelmän laatuvaatimuksissa. Arkkitehtuurivaatimukset voivat olla esimerkiksi Järjestelmän ylläpidettävyyden tulee olla mahdollisimman hyvä tai Suorituskyvyn pitää olla tyydyttävä peruskäyttäjälle [7]. Laatuvaatimusten mitattavuus nostetaan tässäkin olennaiseksi tekijäksi, mutta akateemisesti 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ä komponenttina, koska ne asettavat puitteet sille mikä on mahdollista tai mahdotonta. Esimerkiksi Bosch [7] toteaa, että usein sovelluksen laatuvaatimusten täyttymättömyys on peräisin käytetystä sovellusarkkitehtuurista. Tämän muuttaminen projektin elinkaaren loppuvaiheissa on lähes mahdotonta, joten laatuvaatimukset pitää ottaa jo heti alussa mukaan järjestelmän tekniseen 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 [15]. Tuotteita tai ohjelmistoja kehittävissä tuotekehitysyrityksissä vastuu käytettävyydestä on selkeästi yrityksellä itsellään. Jos asiakkaat eivät ole tyytyväisiä 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ärjestelmää lähdetään tekemään, on lopullinen vastuu järjestelmän käytettävyydestä hankkijalla. Hankkija itse ei tätä välttämättä tiedosta, vaan olettaa järjestelmän käytettävyyden tulevan suunnittelutoimenpiteiden sivutuotteena. [16, 4] Hankkijan vastuu näkyy esimerkiksi järjestelmän toteutusvaiheessa suunnitteluratkaisujen hyväksynnässä. Toimittaja on ideoinut suunnitteluratkaisuja käyttäjätarpeista ja vaatimuksista saamansa tiedon perusteella. Ratkaisut esitetään hankkijalle, joka hyväksyy ne mahdollisin muutospyynnöin. Hyväksytyt ratkaisut siirretään muutoshallintaan, jolloin niitä voi edelleen muuttaa, mutta ainoastaan hankkijan maksamilla lisätilauksilla. Jos suunnitteluratkaisuista paljastuu myöhemmin käytettävyysongelmia, on taloudellinen 13 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET vastuu niiden korjaamisesta tai korjaamattomuuden seurauksista hankkijalla, joka on suunnitteluratkaisut hyväksynyt. [16] Yllä kuvattu hyväksyttämismenettely on yleisesti käytetty toimintatapa. Hyvä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 palalta ei vastaa sen tuloksellisuutta järjestelmän todellisessa käytössä. Tämä menettely 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 ohjaamisessa. Erityisesti hankkijan tulisi syvällisesti jäsentää käyttäjätarpeet ja suunnitella tietorakenne ja käyttöliittymäarkkitehtuuri yhteistyössä toimittajan kanssa, jotta toteutusnäkökulmat tulevat huomioiduiksi. Toimittajan rooli on käyttöliittymäratkaisujen suunnittelu ja toteutus tarjoamansa teknologian avulla, mutta tässäkin hankkijan tulee toimia vahvassa yhteistyössä, jotta laatu saadaan varmistettua. [15] Keskeinen haaste hankkijan aktiivisemmassa roolissa on resurssien puute. Tähänkin osa-alueeseen voidaan hankkia ulkopuolinen resurssi, jonka valinnassa on kuitenkin omat haasteensa. [15] Vastuuta käytettävyydestä saadaan siirrettyä toimittajalle vain selkeästi edellyttämällä käytettävyyttä tarjousvaiheessa. Käytettävyysvaatimuksien avulla toimittaja voi arvioida mitä osaamista ja toimenpiteitä tämän pitää sisällyttää tarjoukseen ja voi sitä kautta myös määrittää niiden hintavaikutukset tarjoushintaan. [15] Hankkijan tulee tehdä vaatimuksien muodostukseen vaadittavat käytettävyystoimenpiteet, sillä järjestelmän toteuttajan ei ole suotavaa 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 siten, että ne voidaan todentaa vasta toteutetulla järjestelmällä. Tarjousvaiheessa vaatimusten tulisi vaikuttaa ja ohjata IT-järjestelmän suunnittelua, jolloin tämänkaltaiset vaatimukset ovat hyödyttömiä. [11] Yksi harvoista aihepiiriä käsittelevistä artikkeleista on Lehtonen et al. [22], jossa analysoidaan 38 viranomaisten tekemää tarjouspyyntöä. Tutkimuksen 14 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET 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ävyysvaatimukset 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 vaatimuksia oli vain 1-5. Käytettävyysvaatimukset kategorisoitiin ISO 9241-11 käytettävyyden määritelmän kolmen attribuutin eli tehokkuuden, tuloksellisuuden ja miellyttävyyden mukaan, jonka lisäksi kirjoittajat lisäsivät kolme kategoriaa, koska nämä eivät riittäneet kattamaan kaikkia vaatimuksia. 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ärjestelmän käyttöliittymän tulee olla käyttäjäystävällinen ja selkeä . Suunnitteluvaatimukset, 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, että järjestelmälle suoritetaan käytettävyystestaus. Tehokkuusvaatimuksia löydettiin 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 todennettavuus, jonka perusteella kirjoittajat tulevat lopputulokseen, ettei yksikään käytettävyysvaatimuksista täytä näitä kumpaakin. Usein puutteena on todennettavuus, esimerkiksi vaatimukset Virhetilanteisiin joutumista tulee välttää tai Ohjelmistossa tulee olla nykyaikainen ja käyttäjäystävällinen käyttöliittymä ovat sinänsä valideja, mutta niiden toteutumisen arviointi on mahdotonta. [22] Yhteenvetona kirjoittajat toteavat, että jotkut viranomaiset huomioivat käytettävyyden tarjouspyynnön vaatimuksissa, mutta niiden laadussa on paljon parannettavaa. Koska vaatimukset eivät ole valideja tai todennettavia tai pahimmillaan molempia, ne eivät aseta IT-toimittajalle todellisia vaatimuksia käytettävyydestä. [22] 15 LUKU 3. 3.3.4 KÄYTETTÄVYYSVAATIMUKSET Validien ja todennettavien käytettävyysvaatimusten luominen Jokela [14] on omassa tutkimuksessaan selvittänyt miten tarjousvaiheen käytettä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ärkeäksi tekijäksi. [14] Jotta käytettävyysvaatimukset voivat olla todennettavia, niiden tulee olla mitattavia. Käytettävyyden mittareista on olemassa paljon kirjallisuutta, mutta niitä sovelletaan tyypillisesti järjestelmän arviointiin. Tarjouspyyntökontekstissa tulee määrittää mitattavat käyttäjävaatimukset, jotka ovat lähtökohta järjestelmän kehitykselle. Tästä seuraa, että niille tulisi asettaa saavutettavat tavoitetasot, mutta sopivista tavoitetasoista ei ole olemassa ohjearvoja. [14] Lähtökohta käytettävyysvaatimuksille tulee olla strategisissa liiketoimintavetoisissa korkean tason käytettävyystavoitteissa. Näistä johdetaan operatiiviset mitattavat käytettävyysvaatimukset, joissa tulee olla mitattavan vaatimuksen kolme elementtiä: käytettävyysmittarin määritelmä, mittausinstrumentin kuvaus ja saavutettava tavoitetaso. [14] Tutkimustapauksessa käytettävyysvaatimukset pyrittiin luomaan ISO 924111 käytettävyyden määritelmän kolmelle attribuutille eli tehokkuudelle, tuloksellisuudelle ja miellyttävyydelle. Näistä ainoastaan tehokkuudelle saatiin luotua mitattava vaatimus, tehtävien onnistumisaste, joka mittaa kuinka moni käyttäjä saa suoritettua tietyn tehtävän halutusti valmiiksi. Mittausinstrumentti on käytettävyystestaus, josta määritettiin ketkä ovat testikäyttäjiä, mitä ovat suoritettavat tehtävät ja milloin tehtävä katsotaan valmiiksi. Jotta tulos olisi tilastollisesti pätevä eikä riippuvainen testihenkilöistä, tavoitetasoksi määritettiin, että 95% luottamuksella 75% tavoitekäyttäjistä saa suoritettua tehtävän halutusti valmiiksi. [14] Tuloksellisuudelle ja miellyttävyydelle mitattavia vaatimuksia ei sen sijaan saatu luotua. Tuloksellisuuden mittaamisen vaihtoehdoksi pohdittiin esimerkiksi tehtävien suoritukseen kuluvaa aikaa, mutta koska näistä ei ollut mitään vertailuarvoja tavoitetasojen lähtökohdaksi ja projektin resurssit eivät riittä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 erilaisia kyselyitä, mutta myös niissä tavoitetason määrittäminen oli ongelmallista. Näiden sijaan kirjoittaja loi työ- 16 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET ryhmänsä kanssa oman mittarin, joka pyrkii yhdistämään tuloksellisuuden ja miellyttävyyden, mutta kirjoittaja on itsekin skeptinen sen toimivuuden suhteen. [14] Käytettävyysvaatimuksista, kuten muissakin vaatimuksissa, tulee huomioida, etteivät ne karkota potentiaalisia tarjoajia. Tämän takia esimerkiksi mittausinstrumenttin tulee olla objektiivinen, toteuttajalle reilu eikä vaatia liikaa resursseja [14, 20]. Oulun kaupungin terveydenhuoltoportaalin tapauksessa tarjouspyyntödokumentista tuli hyvin kattava, noin 70-sivuinen dokumentti, johon on listattuna erikseen kaikki järjestelmän mahdollistamat tehtävät [14]. Koska kaupunki sai useampia tarjouksia, voidaan todeta, etteivät käytettävyysvaatimukset pelästyttäneet IT-toimittajia [14]. Artikkelin kirjoitushetkellä 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 tapauksessa, jossa hankinnan kohteena on valmis IT-järjestelmä, jota osittain muokataan ja parannetaan uudelle asiakkaalle. Tutkimustapauksena on keskisuuri tanskalainen telakka, joka uusi suurimman osan liiketoimintasovelluksistaan. 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ävyysongelmia. Tutkittaessa vaatimuksia löydettiin neljä, joissa käsiteltiin käytettävyyttä, esimerkiksi Käyttöliittymän oppiminen tulee olla helppoa ja Kyselytoimintojen tulee olla nopeita ja tuntua tehokkaammilta kuin nykyinen arkistointijärjestelmä, joka perustuu manuaalisiin kirjetiedostoihin . Näiden vaatimusten 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 tilalle kehittämällään metodilla. Ensimmäinen vaihe on keskeisten käytettävyyskohteiden tunnistus esimerkiksi kriittisten tehtävien, käyttäjäproilien, tavoitteiden ja aikaisempien käytettävyysongelmien avulla. Kun kohteet on tunnistettu, valitaan vaatimustyylit, jotka kattavat nämä tarpeet, ja metriikat ja tavoitearvot vaatimusten todentamiseen. Käytetty metodi ei ole formaali toimenpide vaan vaatimusten luonnissa on käytetty paljon tekijöiden luovuutta, kokemusta ja arviointia. [20] Tapauksesta tunnistetaan 9 keskeistä käytettävyyskohdetta, kuten laskutuksen tehokkuus. Näille on kerätty vaatimustyylit, joilla ne voidaan kuvata ja muotoiltu tyylien mukaiset vaatimukset. Osalle vaatimuksista annetaan vaihtoehtoja. Esimerkiksi jos vaatimus on tehty suoritusperusteisesti ja toimittaja 17 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET ei halua sitoutua tähän, voi hän valita sen sijaan prosessivaatimuksen. Osaan vaatimuksista on määritetty tavoitearvot analogisten käyttötilanteiden avulla, 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ää vertailuperusteita 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 vaatimukset. 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, esimerkiksi kuinka nopeasti hän saa tietyn tehtävän tehtyä. Mittaustavaksi kirjoittaja ehdottaa käytettävyystestausta, jota voi tehdä jo prototyypeillä kehityksen alkuvaiheissa. Keskeisten tehtävien ja tehokkuuden tavoitearvojen valinta vaativat vaivannäköä ja 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 loppuunsaattamisen. Mittaustapana on käytettävyystestaus ja käyttäjän ääneen ajattelu. 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ä, suunnittelun iteratiivisuutta tai heuristista arviota. Tällöin vältetään tavoitearvojen löytämisen ongelma, mutta vaatimus jättää paljon avoimeksi ja toteuttajan oma-aloitteisuuden varaan. [20] Jokela [16] kritisoi tämän tyylisiä vaatimuksia, koska ne voidaan kyllä todentaa, mutta eivät sinänsä takaa käytettä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äyttäjien mielipidettä esimerkiksi haastatteluilla tai kyselyillä. Esimerkki tällaisesta vaatimuksesta on 80% käyttäjistä pitää järjestelmää helposti opittavana . Subjektiiviseen arvioon liittyy kuitenkin monia ongelmia, esimerkik- 18 LUKU 3. KÄYTETTÄVYYSVAATIMUKSET si toteutustyön ulkopuoliset organisatoriset tekijät voivat vaikuttaa mielipiteisiin 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 toteutetulle 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ä piirteitä, kuten sen ulkoasun tai käyttäjälle annettavan palautteen tavat. Näiden vaatimusten todentaminen on tehtävissä, mutta vaivalloista, koska ne koskevat 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] 19 Luku 4 Tutkimuksen metodologia ja aineisto Tässä luvussa kerrotaan empiirisen tutkimuksen suorittamisen menetelmistä ja aineistosta. Luvussa kuvataan metodeihin liittyvää teoriapohjaa, rajoituksia ja miksi kyseiset menetelmät on valittu juuri tähän työhön. Ensimmäisessä kappaleessa esitellään päämenetelmänä eli aineiston laadullinen analyysi. 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ällisesti vähän, tutkimusmetodina on aineiston laadullinen analyysi. Metodina aineiston laadullinen analyysi vaihtelee tapauskohtaisesti riippuen tutkimuskysymyksestä ja materiaalista, mutta alla on kuvattuna sen peruspiirteet [28]. 1. Tutustuminen kerättyyn dataan Kerättyyn aineistoon tutustutaan huolella esimerkiksi lukemalla se moneen kertaan. Samalla tehdään muistiinpanoja ja validoidaan datan laatua. [28] 20 LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO 2. Analyysin rajaus ja datan kategorisointi Analyysin rajaus voidaan tehdä esimerkiksi kysymysasettelun kautta tai keskittymällä yksittäisiin kokonaisuuksiin. Analysoitua dataa kategorisoidaan eli koodataan tunnistamalla teemoja ja toistuvia asioita koherentteihin kategorioihin. Kategoriat voivat olla ennalta määriteltyjä tai niitä voidaan muodostaa analyysin edetessä. [28] 3. Yhteyksien tunnistaminen ja tiedon tulkitseminen Datasta pyritään löytämään esimerkiksi kategorioiden suhteellista tärkeyttä, 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 kokonaisuudeksi. [28] Laadullisen analyysin avulla käsiteltävänä tutkimusaineistona on projektien kirjallista materiaalia ja projekteihin osallistuneiden Luottokunnan ja Accenturen avainhenkilöiden haastatteluja. Seuraavissa kappaleissa kerrotaan tarkemmin kirjallisen ja haastattelumateriaalin keruusta ja niissä käytetyistä menetelmistä. 4.2 Kirjallinen materiaali Projektien kirjallinen materiaali on koottu projekteihin osallistuneilta henkilöiltä sähköpostitse pyytämällä tai Luottokunnan ja Accenturen hankintaja myyntiorganisaatioiden jäseniltä. Suurin osa materiaalista on kuitenkin kerätty itsenäisesti projektien arkistokansioita, joihin on koottu kaikki projektin aikainen materiaali. Saatu materiaali vaihtelee tapauksesta toiseen, mutta kaikista projekteista pyrittiin saamaan mahdollisimman paljon projektin hankintaan liittyvää dokumentaatiota, kuten vaatimuslistauksia, kokousmuistioita, sopimuksia ja tarjouksia. Tässä työssä tutustutaan kolmeen eri projektiin, jotka ovat Korttitilitysten raportointipalvelu, Business Eurocard -uudistus ja Luottokunta Sopimusportaali, 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, taulukosta 2 Business Eurocard -uudistuksen ja taulukosta 3 Luottokunta Sopimusportaali -projektin tässä työssä käsitellyt dokumentit. 21 LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO Taulukoihin koottujen dokumenttien lisäksi tutustuttiin yli kolminkertaiseen määrään dokumentaatiota. Tähän työhön valikoituivat saaduista dokumenteista 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 rajauksesta ennen hankintaa ja hankintaprosessin etenemisestä. Dokumenteista karsittiin pois kaikki hankinnan jälkeinen, projektityönä toteutettu materiaali ja muihin kuin tutkittuihin projekteihin kuuluva materiaali. Jos samasta dokumentista oli useampi versio, niistä valittiin tutkimukseen mukaan hankintapäivää edeltävistä viimeisin versio. 22 katselmoinnin tarkennuksen projekti- pohjalta Toteutuksen projektisuunnitelma suunnitelma Määrittelyn tehty ehdotus etenemisestä Määrittelyn Määrittelyn katselmoinnin loppuesitys analyysi analyysi Projektin yleiskuvaus Projektin yleiskuvaus Projektin yleiskuvaus ja projektin yleiskuvaus lydokumentaation Hankinnan muun määritte- ja projektin yleiskuvaus lydokumentaation Hankinnan muun määritte- portti ja projektin yleiskuvaus loppura- Määrittelyn katselmoinnin tettavasta webpalvelusta analyysi lydokumentaation vaatimuslistauksen liite, kuvaus toteu- tason Hankinnan muun määritte- korkean ja projektin yleiskuvaus edeltäneen analyysi Hankinnan muun määritte- kuvaus Hankintaa tason tettavista kokonaistoiminnallisuuksista korkean lydokumentaation edeltäneen analyysi ja projektin yleis- vaatimuslistauksen liite, kuvaus toteu- Hankintaa vaatimuslistaus vaatimusten Hankinnan tason Mihin käytetty korkean Hankintaa edeltänyt Dokumentin kuvaus PowerPoint Tekstitiedosto Tekstitiedosto PowerPoint Tekstitiedosto Tekstitiedosto Tekstitiedosto Tekstitiedosto Tyyppi 16 kalvoa 14 sivua 12 sivua 26 kalvoa 32 sivua 15 sivua 48 sivua 57 sivua Koko 13.11.2008 10.7.2008 25.6.2008 19.6.2008 19.6.2008 11.1.2008 14.2.2008 14.1.2008 Päiväys Taulukko 1: Korttitilitysten raportointipalvelu -projektin käsitelty vaatimus- ja määrittelydokumentaatio LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO 23 Hankinnan Hankinnan muun määritte- Hankintaa edeltänyt Projektin yleiskuvaus Projektin yleiskuvaus Määrittelyn tehtäväluettelo Liiketoimintavaatimusten Projektin loppuesitys suunnitelma Päivitetty kokonaisprojekti- suunnitelma Projektin yleiskuvaus Projektin yleiskuvaus lydokumentaation analyysi sikuvaus projekti- Hankinnan muun määritte- Hankintaa edeltänyt proses- määrittämisen lydokumentaation analyysi tötapauslistaus käyt- analyysi kean tason vaatimuslistaus vaatimusten Mihin käytetty kor- Hankintaa edeltänyt Dokumentin kuvaus PowerPoint-esitys PowerPoint-esitys PowerPoint-esitys PowerPoint-esitys PowerPoint-esitys PowerPoint-esitys Excel-taulukko Tyyppi 26 kalvoa 13 kalvoa 16 kalvoa 6 kalvoa 13 kalvoa 1 kalvo dellä yhvälileh- riviä dellä 30 Koko 1.12.2011 11.10.2010 1.4.2010 10.3.2010 20.1.2010 12.11.2008 12.2.2010 Päiväys Taulukko 2: Business Eurocard -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO 24 Hankinnan muun määrittelydokumentaation analyysi Hankintaa edeltänyt tarjousluon- nos Luottokunnan asiakkaalle 1. lydokumentaation analyysi nos Luottokunnan asiakkaalle 2. määrittelyvaiheesta Projektin yleiskuvaus Esisuunnittelun allekirjoitettavaksi sopimusluonnos Projektin yleiskuvaus ja Tarjousluonnos esisuunnittelusta Accenturen mukaantulosta Sopimus Accenturen mukaantulosta tään määrittelyn aloituksesta ja Projektin yleiskuvaus Projektin yleiskuvaus Kokousmuistio, pääte- lydokumentaation analyysi liite Luottokunnan asiakkaalle jossa Hankinnan muun määritte- Hankintaa edeltäneen tarjouksen osa Hankinnan muun määritte- Hankintaa edeltänyt tarjousluon- osa Mihin käytetty Tekstitiedosto PowerPoint Tekstitiedosto Tekstitiedosto Excel-tiedosto Tekstitiedosto Tekstitiedosto Tyyppi 5 sivua 11 kalvoa 5 sivua 2 sivua lehdellä neljällä väli- Noin 300 riviä 4 sivua 9 sivua Koko 18.10.2010 21.9.2010 17.5.2010 31.5.2010 8.12.2009 8.12.2009 8.12.2009 Päiväys Taulukko 3: Luottokunta Sopimusportaalin -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio Dokumentin kuvaus LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO 25 LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO Kokousmuistioista, aikatauluista, sopimuksista, tarjouksista, tarjouspyynnöistä ja sähköpostikeskusteluista kerättiin faktatietoa hankinnasta, siihen osallistuneista henkilöistä ja sen aikataulusta. Näiden dokumenttien pohjalta koottiin yleiskuva kunkin projektin etenemisestä, jotka on kuvattu kappaleessa 5.2 Tutkittavat projektit. Vaatimuslistaukset ja alustava määrittelydokumentaatio käsiteltiin tarkemmin käytettävyysnäkökulmasta. Projekteista saatiin niiden vaatimuslistaukset, joista pyrittiin tunnistamaan käytettävyysvaatimukset. Käytettävyysvaatimuksiksi määritellään vaatimukset, joissa täyttyy käytettävyyden ISOmääritelmän (tehokas, tuloksellinen, miellyttävä) jokin aspekti [13]. Käytettävyysvaatimus ei siis kuvaa pelkkää toiminnallisuutta, esimerkiksi Järjestelmässä tulee olla toiminto X , vaan miten toiminto X tulisi tehdä. Käytettävyyden ISO-määritelmän lisäksi poimittiin myös vaatimuksia, joissa on käytettävyyteen liittyviä avainsanoja, kuten käyttäjä, käytettävyys tai helppokäyttöisyys. Vaatimusten käsittelyyn ja käytettävyysvaatimusten tunnistamiseen käytettiin laadullista analyysia. Vaatimukset käytiin huolella useamman kerran lävitse tehden samalla muistiinpanoja ja merkintöjä relevanttien vaatimusten osalta. Käytettävyysvaatimusten lisäksi tunnistettiin myös vaatimuksia, jotka vaatimusten laatijat itse määrittelivät käytettävyysvaatimuksiksi, vaikka ne eivät tämän työn määritelmän mukaisesti niitä olleet. Lehtonen et al. [22] kävivät tutkimuksessaan läpi 38 tarjousta käytettävyysnäkökulmasta. He käyttivät myös ISO 9241 -standardia ja avainsanoja, kuten käyttäjä tai käyttöliittymä, tunnistaakseen käytettävyysvaatimukset [22]. Lisäyksenä tähän lähestymistapaan tässä työssä vaatimukset jaetaan suoriin ja epäsuoriin käytettävyysvaatimuksiin. Suoralla käytettävyysvaatimuksella tarkoitetaan vaatimusta, jonka sanavalinnoista ja muotoilusta käy suoraan ilmi, että sillä haetaan hyvää käytettävyyttä ISO 9241 -määritelmän mukaisesti. Epäsuorat käytettävyysvaatimukset ovat vaatimuksia, joissa huomioidaan loppukäyttäjä ja joiden toteutuminen parantaa lopullisen järjestelmän käytettävyyttä, mutta joita ei ole välttämättä ensisijaisesti tarkoitettu käytettävyysvaatimuksiksi. Tällä erottelulla pyritään tarkentamaan kuvaa käytettävyyden huomioinnista: onko se huomioitu omana osa-alueenaan vai tuleeko se huomioitua osittain vahingossa hankinnan määrittelyssä? Epäsuorissa vaatimuksissa käytettävyys tulee huomioitua hyvän ratkaisun kautta, mutta näistä vaatimuksista ei voida tietää, onko vaatimuksen kirjoittaja tarkoituksellisesti ja tietoisesti huomioinut käytettävyyttä. Kaikki vaatimuksiin liittyvät löydökset esitellään kappaleessa 6.1.1 Projekteista tunnistettavissa olevat käytettävyysvaatimuk- 26 LUKU 4. TUTKIMUKSEN METODOLOGIA JA AINEISTO set. Vaatimusten lisäksi työssä tutustuttiin projektien hankintaa edeltävään muuhun määrittelydokumentaatioon. Tästä dokumentaatiosta pyrittiin tunnistamaan käytettävyyteen liittyviä kuvauksia, kehotuksia tai toiveita, joilla pyritään vaikuttamaan järjestelmän käytettävyyteen projektin edetessä. Kuten vaatimuksissa, lähtökohtana käytettiin ISO-määritelmää ja käytettävyyteen liittyviä avainsanoja. Dokumenttien käsittelyyn käytettiin laadullista analyysia. Jokainen niistä käytiin huolella useamman kerran lävitse tehden samalla muistiinpanoja ja merkintöjä relevanttien vaatimusten osalta. Muuhun määrittelydokumentaatioon liittyvät löydökset esitellään kappaleessa 6.1.2 Käytettävyyden huomioiminen projektien muussa hankinnan määrittelydokumentaatiossa. 4.3 Teemahaastattelut Kirjallista tutkimusaineistoa täydennettiin tarkentavilla haastatteluilla valittujen Luottokunnan ja Accenturen työntekijöiden kanssa. Pääosin haastateltavina oli projekteihin sen hankintavaiheessa osallistuneita henkilöitä, mutta muutama haastateltava oli ollut mukana vasta varsinaisessa projektityössä. Haastatteluja toteutettiin yhteensä kuusi ja ne pidettiin Luottokunnan ja Accenturen tiloissa joulukuussa 2011. Haastattelumetodina käytettiin teemahaastattelua, koska tapaukset ovat keskenään niin erilaisia ja niistä haluttiin keskittyä selkeisiin teemakokonaisuuksiin. Teemahaastattelussa haastattelu etenee ennalta valittujen teemojen eikä valmiiden kysymysten kautta [12]. Samat teemat käsitellään kaikkien haastateltavien kanssa, mutta käsittelyn laajuus ja järjestys voivat vaihdella haastattelusta toiseen [12]. Haastatteluissa käsitellyt teemat ja joitakin niihin liittyviä apukysymyksiä on koottu liitteeseen A Teemahaastattelujen rakenne. Liitteeseen kootut teemat on valittu kirjalliseen materiaaliin perehtymisen ja epävirallisten alustavien haastatteluiden avulla. Alla olevassa taulukossa 4 on kuvattu tutkimuksessa haastatellut henkilöt, heidän roolinsa projekteissa ja aikaisempi työkokemus. Haastattelut nauhoitettiin, jotta haastattelija pystyi keskittymään haastattelutilanteeseen ja varmistamaan kaikkien teemojen kattavan läpikäynnin. Haastattelun jälkeen nauhoitukset litteroitiin käsittelyä varten. Haastattelut käytiin laadullisen analyysin periaatteiden mukaisesti useaan kertaan läpi ja teemoiteltiin. Analyysityössä käytettiin Weft QDA -tietokoneohjelmaa, joka on tarkoitettu laadullisen aineiston käsittelyyn. 27 42 31 47 Luottokunta Accenture Luottokunta Accenture 1,5 vuotta 7 vuotta 10 vuotta 2 vuotta jektissa Rooli pro- likkö 2 vuotta 12 vuotta 4 vuotta 6 vuotta sä? vissa tehtävis- Kauan vastaa- likkö 1 projektipääl- taali Luottokunnan vetäjä 9 vuotta Toteutustiimin 3 vuotta omistaja Projektin Sopimuspor- Luottokunta taali Sopimuspor- Luottokunta -uudistus Eurocard Business likkö 1 projektipääl- -uudistus Accenturen Eurocard Business likkö palvelu 1 projektipääl- raportointi- Korttitilitysten Luottokunnan palvelu 1 projektipääl- raportointi- Korttitilitysten Accenturen Projekti Taulukko 4: Haastatellut henkilöt käyt- tar- käyt- tar- 2010 ottoon jouksesta käyttöön- Ensimmäisestä tar- ottoon jouksesta käyttöön- Ensimmäisestä tar- käyttöönottoon Elokuusta käyttöönottoon Määrittelyvaiheesta töönottoon kennuksesta Määrittelyn töönottoon kennuksesta Määrittelyn na? muka- projektin vaiheissa Missä Poikkeuksellisesti Business Eurocard -uudistuksessa ei ollut Luottokunnan projektipäällikköä. TUTKIMUKSEN METODOLOGIA JA AINEISTO jektipäällikkö ja heidän keskinäinen vastuunjakonsa vaihtelee projektista toiseen Luottokunnan ja toimittajan sopimuksen mukaan. 1 Luottokunnassa ulkopuolisen toimittajan sisältävässä projektiorganisaatiossa on yleensä sekä Luottokunnan että toimittajan pro- vuotta Mies, vuotta Mies, vuotta Mies, vuotta Nainen, 45 vuotta Luottokunta 3,5 vuotta 38 vuot- Mies, 10,5 jalla? ta Accenture työnanta- Työnantaja Kauan vuotta Nainen, 36 ja ikä Sukupuoli LUKU 4. 28 LUKU 4. 4.4 TUTKIMUKSEN METODOLOGIA JA AINEISTO Tutkimuksen rajaukset Tutkimuksen alussa oletettiin, että hankintoja on projektia kohden vain yksi: se, missä ulkopuolinen toimittaja valitaan mukaan projektiin. Toteutettu tutkimus kuitenkin osoitti, että varsinaista projektityötä on voitu tehdä jo hankintaa ennen tai sen aikana, ja hankintoja on ollut yhtä projektia kohden useita, kun projektit on jaettu pienempiin osakokonaisuuksiin. Projektien jakaminen teki tämän työn kannalta olennaiseksi määrittää, mihin hankintoihin tutkimus rajataan ja mitä dokumentaatiota tarkastellaan hankinnan määrittelydokumentaationa. Tässä työssä tutkitaan jokaisesta projektista vain sen ensimmäinen hankinta, jossa ulkopuolinen toimittaja, Accenture, on tullut mukaan projektiin. Tämä rajaus on valittu sen takia, että projektikokonaisuuden muissa vaiheissa hankinta on jatkoa jo käynnissä olevalle osaprojektille ja hankinnan määrittelydokumentaatio on Luottokunnan ja Accenturen yhteistyössä ensimmäisen hankinnan määrittelydokumentaatiosta jalostamaa. Projektikokonaisuuden ensimmäisessä hankinnassa materiaali on pelkästään Luottokunnan toimesta tuotettua, jolloin se kuvaa Luottokunnan käytettävyyden huomiointia hankinnassa ilman Accenturen mahdollista vaikutusta. 29 Luku 5 Tutkimuksen tausta Tässä luvussa kerrotaan empiirisen tutkimuksen taustana tutkimuksen kohteena olevista yrityksistä ja niiden yhteistyöstä. Ensimmäisenä kappaleessa tutustutaan tutkimuksen yritysosapuoliin Luottokuntaan ja Accentureen sekä hankintaan Luottokunnassa. Tämän jälkeen esitellään tutkittavat projektit, joista jokaisesta kuvataan lyhyesti niiden eteneminen, vaatimukset ja muu hankintaa edeltänyt määrittelymateriaali. 5.1 Tutkimuksen yritysosapuolet - Luottokunta ja Accenture Tutkimuksen yritysosapuolet ovat Luottokunta ja Accenture. Luottokunta on Suomen johtava korttimaksamisen palveluyhtiö, joka tarjoaa ja kehittää sujuvamman maksamisen ratkaisuja pankeille, kaupoille ja yrityksille [26]. Luottokunnan tarjoamaa ovat korttimaksamisen liikkeellelasku- ja vastaanottopalvelut, sekä erilaiset kortit ja setelit yrityskäyttöön [26]. Luottokunta on suomalaisten kauppojen ja pankkien yhteisesti osuuskuntana omistama yhtiö, jonka liikevaihto vuonna 2010 oli 173,2 miljoonaa euroa ja henkilöstöä sillä oli noin 450 [26]. Accenture on kansainvälinen liikkeenjohdon konsultoinnin, tietotekniikan ja ulkoistamisen palveluyritys. Accenture yhdistää vankan kokemuksen, kattavan toimialojen ja liiketoiminta-alueiden osaamisen sekä tutkimustiedon maailman johtavista yrityksistä. Ydinajatuksena Accenturella on työskentely yhdessä yritysten ja julkisen sektorin organisaatioiden kanssa tavoitteenaan auttaa näitä menestymään pitkäjänteisesti. Accenturen liikevaihto oli 31.8.2010 päättyneenä tilivuotena 21,6 miljardia dollaria. Yrityksen palveluk- 30 LUKU 5. TUTKIMUKSEN TAUSTA sessa työskentelee yli 223 000 ammattilaista, jotka palvelevat asiakkaita 120 maassa. [2] Suomessa Accenturella on noin 1200 työntekijää ja se on voittanut Suomen paras työpaikka -kilpailun neljänä perättäisenä vuonna [3]. Tutkimuksen kontekstina on Luottokunta-Accenture -yhteistyö. Luottokunta ja Accenture solmivat huhtikuussa 2009 viisivuotisen yhteistyösopimuksen, jolla Luottokunta ulkoistaa Accenturelle palveluitaan tukevien liiketoimintaja verkkosovellusten toteutuksen, ylläpidon ja kehittämisen [1]. Yhteistyösopimuksen taustana on Luottokunnan halu siirtyä kasvavissa määrin pois itse tehtävästä IT-toteutuksesta ja pyrkimys ulkoistaa tämän eri toimittajille. Yhteistyön tavoitteena on parantaa Luottokunnan kustannustehokkuutta ja asiakaspalvelua, mahdollistaa keskittyminen ydintoimintoihin sekä kehittää kokonaistoimintoja sujuvammiksi ja skaalautuvammiksi [1]. Sopimus helpottaa hankintaneuvotteluja tarjoamalla valmiit sopimusehdot, jotka voidaan periyttää projektin tai resurssin sopimukseen. Luottokunnan ja Accenturen yhteistyössä on kyse IT-ulkoistuksesta ja strategisesta kumppanuudesta, josta kerrottiin kappaleessa 2.3 IT-järjestelmien hankinnan erityispiirteet. Ulkoistuksen riskien minimoinnissa tärkeää on toimittajan syvällinen ymmärrys hankkijan liiketoiminnasta ja osapuolten välillä vallitseva luottamus. Accenturen saavutukset sovellusten kehittämisessä ja teknologiauudistuksissa yhdistettynä pankkitoimialan maailmanlaajuiseen erikoisosaamiseen tekevät Accenturesta meille ihanteellisen ja luotettavan kumppanin, toteaa Luottokunnan toimitusjohtaja Heikki Kapanen yhteistyösopimuksen lehdistötiedotteessa [1], joten strategisen kumppanuuden lähtökohdat kuulostavat hyviltä. 5.1.1 Hankinta Luottokunnassa Tässä kappaleessa kerrotaan yleisellä prosessitasolla hankinnasta Luottokunnassa. Kappaleen lähteenä on käytetty Luottokunnan sisäiseen ja yhteistyökumppaneiden käyttöön tarkoitettua Luottokunta Development Management Handbook:ia. Luottokunnassa hankinta tarkoittaa Luottokunnan organisaation ulkopuolisen tuotteen tai palvelun hankintaa. Luottokunnassa on oma erillinen hankintaorganisaationsa, Vendor Management, joka on mukana hankinnoissa projektipäällikön tukena ja omaa myös vahvan roolin valinnan valmistelussa, hankintaprosessissa ja hankinnan laadun varmistuksessa. Luottokunnassa hankinnat tulisi aina kilpailuttaa, ellei ole perusteltua syytä tilata suoraan tietyltä toimittajalta. Tarjoaminen voi olla avointa tai suljettua. Avoimessa tarjouksessa tarjouspyyntö lähetetään isolle määrälle toimit- 31 LUKU 5. TUTKIMUKSEN TAUSTA tajia, kun taas suljetussa tarjouksessa tarjouspyynnön saavat toimittajat on valittu ennalta. Kilpailutus voidaan tehdä osana projektia, omana projektinaan tai ennen projektia. Jos kilpailutus tehdään osana projektia, tarjouspyyntö tehdään osana projektin esivalmistelua. Ennen tarjouspyynnön lähettämistä toimittajan pitää allekirjoittaa salassapitovelvollisuus tarjouksen tiedoista. Projektin omistaja tekee ehdotuksen neuvotteluihin valittavista toimittajista osana projektin etenemispäätöksen esitystä ja projektin johtoryhmä hyväksyy tai hylkää nämä toimittajat. Projektin suunnitteluvaiheessa käydään sopimusneuvottelut toimittajan kanssa ja projektipäällikkö tekee Vendor Managementin avustuksella ehdotuksen valittavasta toimittajasta projektin seuraavan etenemispäätöksen esitykseen, jossa projektin ohjausryhmän tulee hyväksyä valinta. Tämän jälkeen allekirjoitetaan sopimus, hankinta tehdään tai sen suoritus alkaa ja lasku hyväksytään. Projektipäällikkö on vastuussa hankintaprosessista ja hankinnan laadun varmistuksesta tästä eteenpäin. Jos hankinta on hyvin merkittävä, iso ja/tai kompleksinen, sen tekemistä voidaan harkita omana valintaprojektinaan. Tällöin yllä kuvatut toimenpiteet suoritetaan omana projektikokonaisuutenaan ja projektin lopputuotteena on valittu toimittaja. Jos taas hankinta on suhteellisen yksinkertainen, voidaan hankinta tehdä ennen varsinaisen projektin alkua. 5.2 Tutkittavat projektit Tutkimuksen kohteena on osajoukko Accenturen Luottokunnalle toteuttamista IT-järjestelmäprojekteista, joihin on kuulunut käyttöliittymällisiä osakokonaisuuksia. Tutkittuja projekteja on yhteensä 3 ja ne ovat vuosilta 20082011. Tutkimuksesta rajattiin pois projektit, joissa ei ollut toteutettu käyttöliittymällisiä osakokonaisuuksia, kuten täysin tekniset taustajärjestelmäprojektit, jotka eivät suoraan näy loppukäyttäjälle. Lisäksi tutkimuksesta jouduttiin Luottokunnan pyynnöstä rajaamaan pois joitakin projekteja, joiden hankintaa, etenemistä ja lopputuotoksia ei voitu kuvata niiden sisältämien liikesalaisuuksien takia. 5.2.1 Korttitilitysten raportointipalvelu Korttitilitysten raportointipalvelu on Luottokunnan tarjoama raportointipalvelu kauppiaille, joilla on Luottokunnan kanssa sopimus korttimaksujen vas- 32 LUKU 5. TUTKIMUKSEN TAUSTA taanotosta. Palvelusta kauppias voi seurata korttimaksamisen rahaliikennettä raporteista, joissa kuvataan esimerkiksi maksutapahtumien kappalemääriä ja arvoja, Luottokunnan perimiä provisioita ja Luottokunnan kauppiaalle maksamia tilityksiä. Luottokunta luo kauppiaalle hallinnointitunnukset, joiden avulla kauppias voi tehdä palvelussa lisää käyttäjätunnuksia esimerkiksi eri myyntipisteille tai talousosastolle. [25] Palvelun käyttäjäkunta on monipuolinen ja koostuu niin pienten yritysten omistajista kuin suurten yritysten taloushallinnon ammattilaisista. Korttitilitysten raportointipalvelu -projekti oli sekä Luottokunnalle että Accenturelle merkittävä. Projektissa toteutettiin ensimmäinen Luottokunnan kauppiaille tarjoama verkkopalvelu ja sen aikana solmittiin Accenturen ja Luottokunnan viisivuotinen yhteistyösopimus. Korttitilitysten raportointipalvelu avulla Luottokunta pystyy tarjoamaan parempaa palvelua asiakkailleen ja antamaan valmista tietoa, esimerkiksi korttimaksuprovisioiden määrän, heidän kirjanpitoaan varten. Tässä kappaleessa esitellään Korttitilitysten raportointipalvelu -projektin eteneminen yleisellä tasolla. Tämän jälkeen tutustutaan projektin hankintaa edeltäneisiin vaatimuksiin ja muuhun hankintaa edeltäneeseen määrittelydokumentaatioon. Kappaleen lähteinä on käytetty projektista tehtyjä haastatteluja ja kirjallista dokumentaatiota, joka on listattu taulukkoon 1 Korttitilitysten raportointipalvelu -projektin käsitelty vaatimus- ja määrittelydokumentaatio. Projektin yleiskuva Korttitilitysten raportointipalvelu -projekti alkoi Luottokunnan sisäisenä kehityshankkeena, jossa koottiin Luottokunnan toimesta palvelun vaatimuksia ja määrittelydokumentaatiota. Jo alusta asti oli selvää, ettei Luottokunta tulisi toteuttamaan projektia itse, joten sille lähdettiin etsimään sopivaa toimittajaa. Accenture tuli projektiin mukaan toukokuussa 2008 eli jo ennen Luottokunta-Accenture -yhteistyösopimuksen solmimista, mutta neuvottelut sopimuksesta olivat jo käynnissä. Tämä projekti toimi pilottina yhteistyömallista ja sen onnistuneella toteutuksella on ollut vaikutusta sopimuksen allekirjoittamiseen, joka tapahtui tämän projektin aikana. Vaikka Luottokunnan sisäistä työtä oli jo tehty, toimittajaa lähdettiin hakemaan suhteellisen varhaisessa vaiheessa projektikokonaisuutta sen lopullisen laajuuden ja lopputuotteen kannalta katsoen. Hankinnalla, jota tässä työssä tarkastellaan, Accenture tuli mukaan tekemään Luottokunnan keräämän määrittelyn katselmointia ja selvittämään sen soveltuvuutta toteutustyöhön. 33 LUKU 5. TUTKIMUKSEN TAUSTA Tämän selvitystyön pohjalta todettiin, että vaatimuksissa ja määrittelydokumentaatiossa on puutteita, jotka tulisi täydentää ennen toteutusvaihetta. Tämän täydentämisen Luottokunta ja Accenture tekivät projektityönä yhteistyössä ja lopullisesta järjestelmän toteutuksesta vastasi Accenture. Järjestelmä otettiin lopulta käyttöön elokuussa 2009. Projektin vaatimukset Korttitilitysten raportointipalvelun vaatimusmäärittely oli aloitettu Luottokunnan toimesta jo ennen Accenturen mukaantuloa. Kaikki kerätyt vaatimukset oli koottu yhteen isoksi dokumentiksi, johon kuului toiminnallisia, eitoiminnallisia ja liiketoiminnallisia vaatimuksia sekä arkkitehtuurivaatimuksia. Vaatimusten valmiusaste vaihteli suuresti osa-alueittain, ollen joidenkin kohdalla hyvin kattava ja toisten kohdalla lähes kokonaan puuttuva. Määrällisesti vaatimuksia oli yli 200 kappaletta, mutta on tärkeää huomioida, että Luottokunnan vaatimusmäärittely kattoi Korttitilitysten raportointipalvelua laajemman liiketoiminnallisen kokonaistoiminnan, jolloin myöhemmin päätettiin, että vain osa näistä vaatimuksista poimittiin toteutettavaksi tässä projektissa. Hankinnan jälkeen Accenturen toteuttamassa projektityössä vaatimukset käytiin läpi ja varmistettiin niiden riittävyys ja soveltuvuus järjestelmän toteuttamista varten. Selvitystyön pohjalta todettiin, että vaatimuksissa ja määrittelydokumentaatiossa on puutteita, jotka tulisi täydentää ennen etenemistä. Lisäksi koska vaatimusten kattama liiketoiminnallinen kokonaisuus oli niin laaja, vaatimukset ryhmiteltiin useammaksi julkaisuksi, jotka ehdotettiin toteutettavaksi peräkkäin, siten että korkeimman prioriteetin kokonaisuus toteutettaisiin ensimmäisenä. Tämän ryhmittelyn ensimmäinen julkaisu muodostui Korttitilitysten raportointipalveluksi. Myöhemmin projektissa vaatimusmäärittelyä jatkettiin kerätyn dokumentaation pohjalta ja osittain puhtaalta pöydältä, koska vaatimusten jakaminen vaiheisiin muutti joitakin aikaisempia oletuksia. Vaatimukset tehtiin valmiiksi projektin määrittelyvaiheessa, mutta toteutusvaiheessa niitä päivitettiin, lisättiin ja poistettiin lopullisen toteutuman tuomien muutosten ja muutospyyntöjen osalta. Projektin muu määrittelydokumentaatio Vaatimusmäärittelyn lisäksi ennen hankintaa Luottokunnan toimesta toteutettiin dokumentaatiota järjestelmän toiminnallisuuksista ja prosesseista. Näi- 34 LUKU 5. TUTKIMUKSEN TAUSTA tä koottua 45-sivuista toiminnallista määrittelydokumenttia, jossa on yksitoista tarkentavaa liitettä, käytettiin hankinnan määrittelyssä. Alustavissa määrittelyissä ei ollut mukana kuvauksia, miten itse sovellus tulisi loppukäyttäjän näkökulmasta toimia ja muu määrittelydokumentaatio toteutettiin vasta projektityönä hankinnan jälkeen. 5.2.2 Business Eurocard -uudistus Business Eurocard on Luottokunnan yritysasiakkaille tarjoama palvelukokonaisuus, johon kuuluvat Yrityskortti, Matkatili sekä yrityksen talous- ja matkahallinnan käyttöön tarkoitettu Online-palvelu [23]. Business Eurocard kortilla yritykset voivat siirtyä matkakuluissa ja hankinnoissa korttimaksamiseen, jolloin voidaan luopua käteiskassasta, erillisistä bensakorteista tai henkilökohtaisten korttien käyttämisestä työostoksiin. Business Eurocard Matkatili on matkatoimisto-ostojen tilimuotoinen maksutapa, jolloin matkalaskut voidaan hoitaa kuukausittaisella koonnilla yksittäisten laskujen sijaan. [24] Business Eurocard Online -palvelulla voidaan seurata kaikkia yrityksen korteilla tehtyjä kortti- ja matkatiliostoja erilaisilla raporteilla, joista saa ajantasaista tietoa esimerkiksi yrityksen korteista ja matkatileistä, kortinhaltijoista, korttien numeroista, voimassaoloajoista ja käyttörajoista. [24] Tässä projektissa toteutettiin Business Eurocard -taustajärjestelmän uudistus, johon liittyy Luottokunnan asiakaspalvelijoiden käyttämien näyttöjen päivitys taustajärjestelmän mahdollistamien uusien käyttöominaisuuksien osalta. Tässä kappaleessa esitellään Business Eurocard -uudistuksen yleiskuva projektin hankinnan ja sen määrittelyn näkökulmasta. Kappaleessa tutustutaan projektin vaatimuksiin ja muuhun määrittelydokumentaatioon. Kappaleen lähteinä on käytetty projektista tehtyjä haastatteluja ja kirjallista dokumentaatiota, joka on listattu taulukkoon 2 Business Eurocard -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio. Projektin yleiskuva Business Eurocard -uudistusprojekti lähti liikkeelle Luottokunnan sisäisenä kehityksenä. Luottokunnassa oli jo aikaisemmin tehty kyseiseen taustajärjestelmään liittyvää uudistustyötä tietyiltä osin, mutta Business Eurocardin osalta tämä oli vielä tekemättä, jolloin myös siinä lähdettiin tekemään samantapaista uudistusta. Nämä uudistukset koskivat erityisesti taustajärjestelmän mahdollistamia tietorakenteita, mutta myös muita asiakastarpeista 35 LUKU 5. TUTKIMUKSEN TAUSTA lähtöisin olevia uusia ominaisuuksia. Projektin edetessä kävi ilmi, että määrittelyn ja testauksen tiettyihin rooleihin tarvitaan lisää tekijöitä, jolloin Accenturea on yhteistyösopimuksen puitteissa pyydetty tarjoamaan sopivia henkilöitä mukaan projektiin. Tarjoukset on tehty epämuodollisesti sähköpostilla ja niissä on kuvattu rooleihin haluttavien henkilöiden toivottuja osaamisalueita. Alkuun projektiin tuli vain yksi Accenturen työntekijä keväällä 2010 tukemaan Luottokuntaa määrittelytyössä, mutta myöhemmin määrä kasvoi pariin kolmeen henkilöön, jotka toimivat osittain eri aikoina projektissa ja joista yksi henkilö toimi kokonaisprojektin projektipäällikkönä. Accenturen henkilöitä hankittiin mukaan projektiin joustavasti työmäärän mukaisesti ja yhteistyösopimuksen kautta, jolloin isoja tarjous- tai hankintaneuvotteluja ei käyty. Accenturen tuli mukaan projektiin sen alkuvaiheessa ja oli mukana määrittelyssä. Määrittelystä projekti siirtyi liukuen toteutus- ja testausvaiheeseen, jossa määritellyt muutokset ja uudistukset vietiin järjestelmään. Tässä vaiheessa käytettiin määrittelyvaiheessa tuotettua määrittelymateriaalia, mutta määrittely jatkui osittain toteutuksen rinnalla, jolloin dokumentaatiota ja vaatimuksia tuotettiin lisää ja päivitettiin tarvittaessa. Uusittu järjestelmä otettiin käyttöön lokakuussa 2011. Projektin vaatimukset Luottokunta oli kerännyt projektin vaatimuksia jo ennen Accenturen mukaantuloa. Tämä on nähtävissä myös Business Eurocard -uudistuksen projektisuunnitelmasta, jossa kuvataan määrittelyvaiheen tehtäviksi olemassa olevan dokumentaation läpikäynnin ja uusien vaatimusten lisäämisen. Tavoitteena oli myös kehittää Luottokunnan menetelmiä vaatimusmäärittelyn osalta ja projektissa pilotoitiin Luottokunnan uutta systeemityömallia. Vaatimusdokumentaatio, jota on löydettävissä ennen sopimuksen muodostamista, koostuu yhdestä Excel-dokumentista, joka on hyvin alustava. Accenturen mukaantulon jälkeen projektin määrittelyvaiheessa kerättiin vasta varsinaiset vaatimukset. Vaatimusmäärittely toteutettiin projektissa pilotoitavalla Luottokunnan systeemityömallilla ja vaatimusten keräämisestä vastasivat Luottokunnan työntekijät Accenturen konsulttien tukiessa heidän työtään. Vaatimusmäärittelyä jatkettiin projektissa aina toteutusvaiheeseen asti, jolloin lisättiin vielä uusia vaatimuksia ja päivitettiin vanhoja. Tätä jouduttiin tekemään esimerkiksi uusien toiminnallisuuksien takia, jotka otettiin mukaan vasta toteutusvaiheessa. 36 LUKU 5. TUTKIMUKSEN TAUSTA Projektin muu määrittelydokumentaatio Luottokunnassa oli jo aikaisemmin tehty kyseiseen taustajärjestelmään liittyvää uudistustyötä tietyiltä osin, jolloin näiden muiden uudistusprojektien aineistoa pystyttiin soveltuvilta osin hyödyntämään lähtökohtana Business Eurocard -uudistukselle. Lisäksi on löydettävissä vain tätä projektia varten tuotettua materiaalia, jotka ovat vaikuttaneet resurssihankinnan työtehtävien määrittelyyn ja Accenturen tulevaan työhön. Business Eurocard -uudistusta koskevalla osa-alueella ei ollut aikaisemmin tehty käyttötapauskuvauksia, mutta oli päätetty, että sellaiset halutaan toteuttaa laajasti kaikista mahdollisista toiminnallisuuksista. Toteutettavia käyttötapauskuvauksia oli koottu yhteen dokumenttiin otsikkotasolla ennen hankintaa, mutta niitä ei ollut toteutettu sen pidemmälle. Toinen hankintaa edeltävä dokumentti kuvaa korkealla tasolla Business Eurocard -prosesseja. Accenturelta hankittiin ensimmäisenä mukaan konsultti auttamaan määrittelytyössä ja keskeisenä vaatimuksena oli menetelmäosaaminen käyttötapauskuvausten tekemisestä. Projektityönä toteutettiin kattava käyttötapauskaavio ja erilliset käyttötapaukset kaikista mahdollisista uudistukseen kuuluvista osa-alueista. Suurin osa dokumentaatiosta tuotettiin määrittelyvaiheessa, mutta määrittelyä jatkettiin osittain toteutuksen kanssa rinnan päivittämällä olemassa olevaa dokumentaatiota ja täydentämällä sitä tarvittaessa uudella dokumentaatiolla. 5.2.3 Luottokunta Sopimusportaali Luottokunta Sopimusportaali on Luottokunnan valituille asiakkailleen tarjoama verkkopalvelu kauppiaiden korttimaksupalvelusopimusten syöttämiseen ja hallintaan. Sen kautta asiakasorganisaatioiden työntekijät voivat syöttää, muokata ja lähettää käsittelemänsä sopimukset eteenpäin Luottokunnan asiakaspalvelijoille, jotka hyväksyvät tai palauttavat sopimuksen jatkokäsittelyyn. Portaalin muita toiminnallisuuksia ovat muun muassa sopimusten haku, käyttäjienhallinta ja PDF-materiaalien lataaminen. Luottokunta Sopimusportaali -projektiin kuului myös Korttitilitysten raportointipalvelun uudistamista, koska molemmat järjestelmät kuuluvat samaan palvelukokonaisuuteen ja Luottokunta Sopimusportaali toi mukanaan uusia ominaisuuksia, jotka tuli päivittää myös toiseen palveluun. Tässä kappaleessa esitellään Luottokunta Sopimusportaali -projektin yleiskuva projektin hankinnan ja sen määrittelyn näkökulmasta. Kappaleessa kuvataan projektin vaatimuksia ja muuta määrittelydokumentaatiota painottaen 37 LUKU 5. TUTKIMUKSEN TAUSTA hankintavaihetta, mutta myös hieman seuraten niiden kehittymistä loppuprojektin aikaina. Kappaleen lähteinä on käytetty projektista tehtyjä haastatteluja ja kirjallista dokumentaatiota, joka on listattu taulukkoon 3 Luottokunta Sopimusportaalin -uudistuksen käsitelty vaatimus- ja määrittelydokumentaatio. Projektin yleiskuva Projektin hankinnassa Accenturen kokemus aikaisemmista projekteista, erityisesti Korttitilitysten raportointipalvelu -projektista, syvällinen ymmärrys Luottokunnan toiminnasta ja solmittu yhteistyösopimus antoivat vahvan aseman verrattuna muihin toimittajiin. Tämän ja aikataulupaineiden takia hankintaneuvottelut tehtiin nopeasti ja suhteellisen epävirallisesti. Tällä projektilla oli kaksi hankintaa edeltävää lähtökohtaa. Ensimmäiseksi, ratkaisun ajateltiin olevan vain laajennus aikaisemmin toteutettuun Korttitilitysten raportointipalveluun, jolloin vaatimusten ja määrittelyjen pohjana ajateltiin käytettävän olemassa olevaa toteutusta ja sitä ennen kerättyjä, kyseistä toteutusta laajempia vaatimuksia. Lisäksi yhdeltä Luottokunnan asiakkaalta oli saatu tarjouspyyntö kyseisestä palvelusta, joka sisälsi kuvauksia heidän haluamistaan ominaisuuksista. Luottokunta vastasi tähän tarjouspyyntöön ja se toimi pohjana Luottokunnan sisäisissä valmistelutöissä. Accenture tuli mukaan projektiin hyvin sen alkuvaiheessa, kun vasta korkealla tasolla tiedettiin palvelun sisältö ja arkkitehtuuri. Hankinnan jälkeen Luottokunta ja Accenture keräsivät vaatimuksia sekä tekivät määrittelyä ja suunnittelua toteutusprojektin aloittamista varten. Projektin määrittelyn tarkentuessa todettiin, että tätä uutta palvelua ei voida tehdä vain laajennuksena Korttitilitysten raportointipalveluun, vaan sille tarvitaan oma, erillinen ratkaisunsa, jolloin projektin laajuutta muutettiin. Projektin edetessä Accenture tuki Luottokuntaa projekti- ja arkkitehtuurisuunnittelussa ja vaatimus- ja määrittelytyötä tarkennettiin. Määrittelyn jälkeen Accenture teki tarjouksen ratkaisuehdotuksesta toteutukselle, joka hyväksyttiin ja samalla Accenturen roolia muutettiin osatoimittajasta kokonaisvastuulliseksi toimittajaksi eli Accenture vastasi toteutusvaiheessa myös muiden toimittajien ja Luottokunnan sisäisten resurssien ohjauksesta teknisen toteutuksen osalta. Luottokunta Sopimusportaali otettiin lopulta käyttöön syyskuussa 2011. 38 LUKU 5. TUTKIMUKSEN TAUSTA Projektin vaatimukset Projektin hankintaa edeltäviä vaatimuksia löytyi Korttitilitysten raportointipalvelu -projektin vaatimuslistauksesta. Osa ominaisuuksista, joita ei toteutettu Korttitilitysten raportointipalvelu -projektissa, toteutettiin tässä projektissa. Nämä vaatimukset ovat täsmälleen samat, kuin mitä on käsitelty yllä Korttitilitysten raportointipalvelu -projektin yhteydessä. Muita varsinaisia vaatimusmuotoisia dokumentteja ei ole löydettävissä, mutta muusta dokumentaatiosta johdettiin myöhemmin vaatimuksia. Edellisessä kappaleessa kuvatuista hankintaa edeltävistä dokumenteista muodostettiin hankinnan jälkeisenä projektityönä vaatimuksia ja Accenture ja Luottokunta keräsivät näiden lisäksi uusia, täydentäviä vaatimuksia. Suunnittelun lähtökohtana oli ollut Korttitilitysten raportointipalvelun laajentaminen uusilla ominaisuuksilla, mutta tästä luovuttiin, kun huomattiin että järkevintä ja tehokkainta on tuottaa oma erillinen palvelunsa. Tässä vaiheessa uutta luotavaa palvelua kuvattiin hyvin korkealla tasolla, jolloin määrämuotoista vaatimusmäärittelyä ei tehty. Tähän vaikutti myös Luottokunnan asiakkaan kanssa kesken olleet neuvottelut, jolloin asiakasnäkökulmaa ei saatu käsittelyyn mukaan ja vaatimusmäärittelyn kanssa ei ollut tarkoituksenmukaista edetä. Projektin toteutusvaiheessa kirjoitetut vaatimukset jäivät vähän toissijaisiksi muun materiaalin takia. Käyttöliittymän suunnittelun tueksi otettiin Accenturen ehdotuksesta visualisointityökalu, jolla pystyi rakentamaan interaktiivisia käyttöliittymäprototyyppejä, jolloin tällä työkalulla tuotetut prototyypit toimivat vaatimuksina tulevalle toteutukselle. Kirjalliset vaatimukset päivitettiin projektin päätteeksi, mutta niitä ei kovin aktiivisesti käsitelty toteutuksen aikana. Projektin muu määrittelydokumentaatio Hankintaa edeltävänä muuna määrittelydokumentaationa voidaan pitää edeltävän Korttitilitysten raportointipalvelu -projektin erilaisia määrittelylopputuotteita, joita pystyttiin soveltuvilta osin hyödyntämään lähtökohtana Luottokunta Sopimusportaali -projektille. Tähän projektiin tuotettua uutta hankintaa edeltävää määrittelymateriaalia on Luottokunnan asiakkaalleen toimittama tarjous. Luottokunta sai asiakkaaltaan tarjouspyynnön, joka toi mukanaan asiakkaan näkökulman palveluun ja sen tarjoamiin ominaisuuksiin. Luottokunta vastasi tähän tarjouspyyntöön tarjouksella. Tarjouksessa ei itsessään ollut yksiselit- 39 LUKU 5. TUTKIMUKSEN TAUSTA teisiä vaatimuksia, vaan kuvauksia kokonaisuuksista ja reunaehtoja palvelun toteutukselle, jolloin siinä luvatuista asioista muodostettiin myöhemmin vaatimuksia uudelle järjestelmälle ja ne vaikuttivat myöhemmin tehtävään määrittelyyn. Muuta hankintaa edeltävää määrittelydokumentaatiota ei ole löydettävissä, vaan määrittely tehtiin pääosin hankinnan jälkeen projektityönä. Määrittelyssä toteutettiin esimerkiksi käyttötapauksia, sivukarttaluonnos ja alustavia rautalankamalleja. Projektin toteutusvaiheessa käyttöön otettiin interaktiivisten käyttöliittymäprototyyppien suunnitteluun tarkoitettu työkalu, jolla mallinnettiin palvelun näyttöjen toiminta ja ulkoasu. 40 Luku 6 Tulokset Tässä luvussa esitellään empiirisen tutkimuksen tulokset. Ensimmäiseksi tutustutaan projektien hankintaa edeltävään kirjalliseen materiaaliin ja niistä löytyviin käytettävyysvaatimuksiin tai käytettävyyden muuhun huomiointiin. Tämän jälkeen kerrotaan haastattelututkimuksen tuloksista, joissa kuvataan muun muassa miten haastateltavien mielestä käytettävyyttä huomioidaan Luottokunnassa ja miten käytettävyys näkyi tutkittavien projektien hankinnassa. 6.1 Käytettävyyden huomioiminen hankinnan kirjallisessa materiaalissa Tässä kappaleessa käydään läpi hankinnassa käytetyn määrittely- ja tarjousmateriaalin laadullisen analyysin tulokset. Miten ja mitä materiaaleja on tutkittu, on kuvattu kappaleessa 4.2 Kirjallinen materiaali ja yleiskuva eri projekteista ja materiaalin valmiusaste hankinnan aikaan on kuvattu kappaleessa 5.2 Tutkittavat projektit. Tässä kappaleessa käsitellään ensimmäiseksi projektista löydetyt, hankintaa edeltäneet vaatimukset, joista on pyritty tunnistamaan mahdollisia käytettävyysvaatimuksia. Vaatimusten jälkeen käsitellään muuta hankintaa edeltänyttä materiaalia, jota on käytetty avuksi hankinnan määrittelyssä ja Accenturen työn rajaamisessa. Tästä materiaalista on pyritty tunnistamaan käytettävyyteen liittyviä asioita, kuten toimenpiteitä, kehotuksia tai toiveita, joilla pyritään vaikuttamaan järjestelmän käytettävyyteen projektin edetessä. 41 LUKU 6. 6.1.1 TULOKSET Projekteista tunnistettavissa olevat käytettävyysvaatimukset Tässä kappaleessa kuvataan erikseen jokaisen projektin hankintavaihetta edeltäneiden vaatimusten mahdolliset käytettävyysvaatimukset ja arvioidaan niiden validiteettia ja mitattavuutta. Lisäksi jokaisesta projektista pyritään kuvaamaan yleisesti löydettyjen vaatimusten määrä, niiden kattavuus ja antamaan esimerkkejä erilaisista vaatimuksista, jotta lukija saa yleiskuvan projektin vaatimuksista ja ymmärtää mihin kontekstiin mahdolliset käytettävyysvaatimukset sijoittuvat. Vaatimusten jaottelu eri kategorioihin ja alakategorioihin on tehty dokumentaatiossa olevan luokittelun perusteella. Vaatimuksia on myös jaoteltu suoriin ja epäsuoriin vaatimuksiin sen mukaan, voidaanko niistä suoraan nähdä, että vaatimuksen taustalla on käytettävyyden huomiointi vai onko käytettävyys huomioitu epäsuorasti hyvän ratkaisun kautta. Vaatimusten analyysimenetelmästä kerrotaan tarkemmin kappaleessa 4.2 Kirjallinen materiaali. Tutkittavat vaatimuskokonaisuudet ovat olleet tässä vaiheessa Luottokunnan toimesta kerättyjä, ja niiden avulla on päätetty projektin etenemisestä ja Accenturen työn rajauksesta. Yleisesti voidaan todeta, että kaikissa projekteissa vaatimukset eivät olleet ensimmäisessä hankintavaiheessa valmiit, vaan jokaisessa projektissa oli Accenturen mukaantulon jälkeen määrittelyvaihe, jossa vaatimuksia päivitettiin ja täydennettiin. Korttitilitysten raportointipalvelu Korttitilitysten raportointipalvelun hankintaa edeltäneitä vaatimuksia on yli 200 koottuna yhteen isoon dokumenttiin. Vaatimuksia on todella runsaasti, mutta vain osa niistä koskee toiminnallisuuksia, jotka vietiin lopulta toteutukseen tämän projektin piirissä. Osa vaatimuksista toteutettiin Luottokunta Sopimusportaali -projektin yhteydessä, osa on päätynyt muihin projekteihin tai muuttunut myöhemmin tarpeettomiksi. Tässä kappaleessa käsitellään kuitenkin kaikkia yli 200 vaatimusta, koska Accenturen tullessa mukaan projektiin tästä joukosta poimittiin lopullinen toteutus, jolloin kyseinen vaatimuskokonaisuus oli hankinnan lähtökohtana. Nämä yli 200 vaatimusta on jaoteltu dokumentissa neljään pääkategoriaan taulukon 5 mukaisesti. Arkkitehtuurivaatimusten määrä ei ollut laskettavissa, koska ne ovat kirjoitettuina kappaleina ja kuvina, eivätkä numeroituina vaatimuksina kuten muut vaatimukset. Kaikilla muilla vaatimuksilla on yksiselitteinen ID, kuvaus, lähde ja prioriteetti. Vaatimusdokumentin alussa 42 LUKU 6. TULOKSET Taulukko 5: Korttitilitysten raportointipalvelu -projektin hankintaa edeltäneiden vaatimusten tyyppi ja määrä Vaatimustyyppi Määrä Liiketoiminnallinen 18 Toiminnallinen 171 Arkkitehtuuri Ei määritettävissä Ei-toiminnallinen 71 määritellään, että vaatimuksen kuvauksen tulee olla uniikki, yksiselitteinen ja tarkka . Liiketoiminnallisissa vaatimuksissa kuvataan liiketoiminnallisia prosesseja, palveluita ja tavoitteita, jotka järjestelmän tulee mahdollistaa, kuten Palvelun tulee tukea Luottokunnan tasolla saavutettavia synergiaetuja järjestelmäratkaisuissa . Liiketoiminnallisista vaatimuksista on tunnistettavissa yksi suora käytettävyysvaatimus, jossa todetaan, että asiakaspalvelijoiden pitää pystyä käyttämään järjestelmää järkevällä ja tehokkaalla tavalla ja listataan esimerkkitoiminnallisuuksia, kuten sopimusten tekeminen ja tietojen selailu, joissa tämä tulee ilmetä. Lisäksi on löydettävissä yksi epäsuora käytettävyysvaatimus, jonka toteuttaminen tekee järjestelmästä tehokkaamman ja miellyttävämmän käyttäjille: Järjestelmään tulee toteuttaa tiettyjen nykyjärjestelmässä manuaalisten prosessien automatisointi . Nämä molemmat vaatimukset ovat sisällöltään valideja, mutta niistä vain jälkimmäinen on yksiselitteisesti mitattava. Tiettyjen prosessien automatisointi voidaan todeta sillä, että nämä automatisoinnit on toteutettu, mutta tiettyjen toimintojen tekeminen järkevällä ja tehokkaalla tavalla ei mahdollista objektiivista arviointia vaatimuksen toteutumisesta. Toiminnalliset vaatimukset on jaoteltu 8 alakategoriaan tunnistettujen pääprosessien mukaisesti. Näistä vaatimuksista ei ollut tunnistettavissa suoria käytettävyysvaatimuksia. Vaatimuksissa kuvattiin runsaasti mitä järjestelmän tulee tehdä, mutta ei miten nämä toiminnot tulisi tehdä, esimerkiksi Järjestelmän pitää pystyä ottamaan vastaan ja tallentamaan määriteltyjä sopimustietoja ja Sopimuksella voi olla rajoitettu voimassaoloaika . Toiminnallisista vaatimuksista on löydettävissä kuitenkin muutamia epäsuoria käytettävyysvaatimusta, joiden toteutus vähentää manuaalista työtä, virheiden mahdollisuutta ja helpottaa käyttäjän toimimista järjestelmän kanssa. Vaatimukset Vanhaa sopimusta tulee voida käyttää uuden hakemuksen pohjana ja Extranet-lomakkeen tiedot tulee voida hakea muista lähteistä, esimerkiksi CRM-järjestelmästä tarkoittavat jo olemassa olevien tieto- 43 LUKU 6. TULOKSET jen tuomista täytettäville lomakkeille, jolloin virkailijat eivät joudu kirjaamaan kaikkia tietoja aina uudestaan, mikä tehostaa lomakkeiden täyttämistä. Kaikki järjestelmään syötettävä data tulee validoida tarkoittaa, että esimerkiksi tilinumeroista ja syntymäajoista tarkistetaan niiden oikeellisuus, jolloin virheiden määrä vähenee. Järjestelmän tulee voida lähettää huomautusviesti, kun siihen on saapunut uutta dataa mahdollistaa sen, ettei käyttäjän tarvitse aktiivisesti tarkkailla järjestelmää, vaan hän voi keskittyä muihin töihin. Nämä vaatimukset ovat kaikki valideja ja mitattavia. Niiden toteutumisen arviointi tarkentuu vasta kun määrittelyt tarkentuvat, esimerkiksi mitä kenttiä täytetään vanhasta sopimuksesta ja miten järjestelmään syötettävä data validoidaan. Arkkitehtuurivaatimukset on jaoteltu kuuteen alakategoriaan, kuten integraatioarkkitehtuuri ja sovellusarkkitehtuuri, joista osa jakautuu edelleen useampiin alaryhmiin. Nämä vaatimukset on kuvattu eri tavalla kuin dokumentin muut vaatimukset. Ne ovat pidempiä sanallisia kuvauksia tai arkkitehtuurikuvia, kun muissa vaatimuksissa on käytetty formaaleja ID, kuvaus, lähde ja prioriteetti -taulukoita. Kappaleessa kuvataan esimerkiksi miten järjestelmässä käsiteltävä tieto tulisi tallentaa tietokantaan, kuvataan korkealla tasolla tarvittavat integraatiot muihin järjestelmiin ja miten tietoturva tulee ottaa huomioon toteutuksessa. Arkkitehtuurivaatimuksissa ei ole löydettävissä suoria käytettävyysvaatimuksia, mutta niissä on muutamia epäsuoria käytettävyysvaatimuksia tai niiden tarkennuksia. Niissä kuvataan tarkemmin jo toiminnallisissa vaatimuksissa ollut vaatimus datan validoinnista. Siitä kerrotaan, että voidaan tarkistaa, että pakollisissa kentissä on sisältöä ja kenttien sisällön oikeellisuus niissä tapauksissa kun se on mahdollista, esimerkiksi päivämäärissä ja henkilöturvatunnuksissa. Lisäksi kuvataan, että järjestelmän tulee tukea käyttäjäryhmän tai -roolin mukaan eriteltäviä toiminnallisuuksia, esimerkiksi siten, etteivät kaikki kentät tai painikkeet näy kaikille käyttäjille. Nämä vaatimukset ovat valideja ja mitattavia, mutta myös näiden mittaustavan tarkempi suunnittelu vaatii tarkempaa määrittelyä esimerkiksi eri rooleista ja mitkä kentät ja painikkeet näkyvät kenellekin. Ei-toiminnalliset vaatimukset on jaoteltu kolmeen alakategoriaan niiden prioriteetin mukaan ja näiden alla edelleen toiminnallisuuden mukaan. Ei-toiminnallisiin vaatimuksiin kuuluvat muun muassa palvelun luotettavuus, suorituskyky ja skaalautuvuus. Näissä vaatimuksissa on havaittavissa osittaista päällekkäisyyttä arkkitehtuurivaatimusten kanssa, koska molemmissa kuvataan esimerkiksi saavutettavuutta ja tietoturvaa. Jo vaatimusten kuvaustyylien erilaisuuden perusteella voidaan olettaa, että dokumenttia on ollut tekemässä useampi 44 LUKU 6. TULOKSET ihminen ja kaikkia päällekkäisyyksiä ei ole saatu karsittua pois. Toiseksi korkeimman prioriteetin alta löytyy erillinen käytettävyysvaatimukset -alaotsikko, johon on listattu 7 vaatimusta. Nämä vaatimukset määrittävät tuettavan miniminäytön koon, tuetut selaimet ja selainasetusten huomioonottamisen, ja tuen kielille suomi, ruotsi, englanti ja mahdollisuuden lisätä muita kieliä tulevaisuudessa. Vaikka nämä vaatimukset on listattu dokumentissa käytettävyysvaatimuksiksi, nämä eivät ole tämän työn määritelmän mukaisesti käytettävyysvaatimuksia vaan pikemminkin teknisiä tai toiminnallisia vaatimuksia. Ei-toiminnallisista vaatimuksista on tunnistettavissa näiden ulkopuolelta viisi epäsuoraa käytettävyysvaatimusta. Ensimmäisessä kuvataan, että Käyttäjälle on annettava aina varoitus, jos hän yrittää toimintoa, johon hänen oikeutensa eivät riitä , jolloin käyttäjä saa selkeän viestin, miksi järjestelmä ei tee hänen pyytämäänsä toimintoa. Yhdessä suorituskykyvaatimuksessa listataan kuinka kauan saa mennä erilaisten tietojen lataamiseen, jolloin tämä vaikuttaa järjestelmän tehokkuuteen. Lisäksi on kolme erillistä vaatimusta, jossa kuvataan erilaisia käyttäjärooleja ja niiden erottelua toisistaan, jolloin eri käyttäjärooleille saadaan näkyviin vain heille tarkoituksenmukaisia tietoja ja toimintoja. Nämä vaatimukset ovat valideja ja mitattavia, esimerkiksi suorituskykyvaatimuksessa annetaan aikarajat ja kuvataan mistä mihin se tulee laskea. Käyttäjäroolien vaatimusten tarkka mittaaminen tarvitsee määrittelyn tarkentamista. Business Eurocard -uudistus Vaatimusdokumentaatio, jota on löydettävissä ennen sopimuksen muodostamista, koostuu yhdestä Excel-dokumentista, joka sisältää vaatimuksia ja niiden käsittelyä helmikuulta 2010 eli juuri ennen Accenturen mukaan tuloa. Viimeisimmässä versiossa on 29 vaatimusta, joista listataan tila, kuvaus, kommentti, prioriteetti, osa-alue ja vastuuhenkilö. Kaikkien vaatimusten tila on avoin, joten niiden käsittely on vielä kesken. Vaatimukset on jaettu viiteen osa-alueeseen ja niiden priorisointi on tehty arvoilla 1-3. Kuvauksien tai kommenttien perusteella vaatimuksista ei ole löydettävissä yhtäkään käytettävyysvaatimusta, vaan ne ovat hyvin korkean tason toiminnallisuuksien kuvausta, esimerkiksi Laskun sisältö ja Laskun ulkoasumuutokset . Loput saadusta vaatimusdokumentaatiosta on päiväyksen mukaan tehty vasta Accenturen tultua mukaan projektiin. Yleisesti voidaan todeta, että vaatimusmäärittely hankinnan aikana oli vielä hyvin kesken, koska vaatimuksia on niin vähän ja ne ovat hyvin korkealla 45 LUKU 6. TULOKSET tasolla. Hankinnan keskeisenä tarkoituksena oli nimenomaan vaatimusmäärittelyn tukeminen. Vaatimusmäärittely on päässyt todella vauhtiin Accenturen mukaan tulon jälkeen huhti-toukokuussa 2010, jolloin dokumentaatiota on alkanut syntyä. Dokumentaation vähyyteen vaikuttaa myös työn luonne olemassa olevan järjestelmän uudistuksena, mikä jo itsessaan rajaa kehittämisen vapausasteita. Lisäksi uudistuksen dokumentaatiossa ja toteutuksessa pyrittiin hyödyntämään mahdollisimman paljon aikaisemmissa uudistusprojekteissa tehtyä työtä. Luottokunta Sopimusportaali Luottokunta Sopimusportaalin hankintaa edeltäneitä vaatimuksia löytyy vain yhdestä lähteestä eli Korttitilitysten raportointipalvelua edeltäneestä korkean tason vaatimuslistauksesta. Tämän dokumentin sisältö on jo kuvattu ja käsitelty yllä olevassa kappaleessa Korttitilitysten raportointipalvelun vaatimuksista, joten sitä ei käsitellä tässä uudestaan. Tästä dokumentista osa vaatimuksista poimittiin toteutettavaksi tässä aikaisemmassa projektissa ja osa siirtyi toteutettavaksi myöhemmin Luottokunta Sopimusportaali -projektissa. Tälle projektille täysin omaa vaatimusmateriaalia on kerätty Luottokunnan vaatimustenhallintatyökaluun, jonka lisäyspäivämäärien perusteella se on otettu käyttöön vasta kesäkuussa 2010 eli Accenturen mukaantulon jälkeen. 6.1.2 Käytettävyyden huomioiminen projektien muussa hankinnan määrittelydokumentaatiossa Tässä kappaleessa kuvataan erikseen jokaisen projektin hankintavaihetta edeltäneestä muusta määrittelydokumentaatiosta löytyvät viittaukset käytettävyyteen ja sen huomiointiin. Yleisesti voidaan todeta, että koska Accenture tuli kaikkiin projekteihin mukaan tukemaan määrittelyä, hankintaa edeltävää dokumentaatiota ei ollut paljoakaan. Lisäksi osa tutkitusta materiaalista rajattiin tästä analyysistä pois, koska se ei koskenut itse järjestelmän määrittelyä, vaan esimerkiksi projektin prosessia, budjettia ja aikataulua. Määrittelydokumentaation keräämisen rajauksista ja analyysimenetelmästä kerrotaan tarkemmin kappaleessa 4.2 Kirjallinen materiaali. 46 LUKU 6. TULOKSET Korttitilitysten raportointipalvelu Hankinnan määrittelynä on vaatimusten lisäksi Luottokunnan toimesta toteutettu 45-sivuinen toiminnallinen määrittelydokumentti tarkentavine liitteineen. Dokumentissa kuvataan korkealla tasolla palvelun tarkoitus, toiminta, sisältö ja prosessit. Tässä dokumentaatiossa loppukäyttäjiä huomioitiin Korttitilitysten raportointipalvelun korkean tason kohderyhmien määrittämisellä. Kaikista ryhmistä annetaan yleiskuvaus ja lisäksi kerrotaan minkälaisilla syötteillä ja vasteilla he vuorovaikuttavat järjestelmän kanssa. Dokumentaatio sisältää myös korkean tason käyttötapauksia ja listauksia tarkemmista käyttötapauksista otsikkotasolla. Alustavissa määrittelyissä ei ole kuitenkaan mukana tarkempia kuvauksia, miten itse sovelluksen tulisi loppukäyttäjän näkökulmasta toimia, kuten käyttötapauksia tai lankamalleja, koska liikutaan vielä korkealla tasolla. Yhdessä liitteistä kuvataan hieman tarkemmin järjestelmän käyttöliittymää. Kappaleessa otetaan lyhyesti kantaa sen käytettävyyteen: Koska extranetin käyttöliittymä antaa palvelulle sen lopullisen tuntuman ja ulkoasun, on tärkeää että Luottokunnan ratkaisu toteutetaan tavalla, joka mahdollistaa tyydyttävän käyttökokemuksen. Käyttöliittymän suunnittelussa tulisi käyttää websovellusten ja käyttöliittymien parhaita käytäntöjä. Lisäksi käyttäjäryhmien pilottikäyttäjiä voitaisiin käyttää avainprosessien työnkulkujen testauksessa, kun niihin liittyy extranetin käyttöliittymä. Muuten kappaleessa keskitytään selainvalintoihin, tuettuihin kieliin ja käyttöliittymän versiointiin. Business Eurocard -uudistus Hankintaa edeltäneestä määrittelydokumentaatiosta on löydettävissä kaksi dokumenttia, jotka ovat vaikuttaneet Accenturen tulevaan työhön ja sen rajaukseen. Nämä ovat käyttötapauskuvausten otsikkotason listaus, jotka toteutettiin lopulta Accenturen mukaantulon jälkeen ja järjestelmän laaja prosessimalli. Käyttötapauskuvaukset oli listattu otsikkotasolla jo reilu vuosi ennen projektin alkua ja osaa niistä oli jo lähdetty määrittelemään eteenpäin. Niistä ei ole löydettävissä suoria viittauksia käytettävyyteen, mutta erilaisia käyttötapauksia on 20, joten järjestelmän eri toimijoiden näkökulmaa huomioidaan laajasti. Muutamaa kuukautta ennen projektin alkua koottu prosessikuvaus kuvaa uudistuksen kriittiset menestystekijät ja prosesseille strategiasta johdettavat asiat, joihin kuuluvat esimerkiksi kustannustehokkuus, laatu ja kilpailukykyisyys. Käytettävyyttä tai sen osa-alueita, tehokkuutta, tuottavuutta tai 47 LUKU 6. TULOKSET miellyttävyyttä ei suoraan listata, mutta kustannustehokkuus ja kilpailukykyisyys sisältävät näitä samoja elementtejä. Tähän projektiin liittyvä dokumentaatio oli hankintavaiheessa vaillinainen tämän projektin uudistusten toteutusta ajatellen. Tämän takia hankinnan yhteydessä määritettiin projektissa toteutettava tarkemman dokumentaation luominen, johon kuuluivat esimerkiksi käyttäjäryhmien analysointi, laajat käyttötapauskuvaukset ja nämä kokoava käyttötapauskaavio. Projektissa on tiedostettu, että loppukäyttäjien näkökulmaa tulee ottaa vahvemmin mukaan. Luottokunta Sopimusportaali Määrittelyä edeltävää muuta määrittelydokumentaatiota on Luottokunnan asiakkaalleen toimittama tarjous, jossa sovitaan liiketaloudellisten näkökulmien lisäksi järjestelmän toiminnallisuuksista ja ominaisuuksista korkealla tasolla. Käyttöliittymästä huomioidaan siinä käytettävät kielet ja joitakin toimintoja, joita sen tulee mahdollistaa. Käyttäjäryhmiä mainitaan pitkin tekstiä eri tehtävien yhteydessä, mutta heitä ei eritellä tai määritellä tarkemmin. Yksi käytettävyyteen liittyvä maininta löytyy asiakastietojen siirtämisestä toisista järjestelmistä, esimerkiksi jotta säästettäisiin aikaa ja vaivaa ja vähennettäisiin virheiden määrää uudelleensyötettäessä olemassa olevaa tietoa . Dokumentissa käsitellään pääosin sopimusteknisiä ja taloudellisia tekijöitä sekä toimijoiden vastuunjakoa, jolloin itse palvelulle ja sen käytettävyydelle ei jää suurta osaa. 6.2 Haastattelutulokset Tässä kappaleessa käydään läpi haastattelujen tuloksia hankinnan määrittelystä ja käytettävyyden huomioinnista hankinnan määrittelyssä. Ensimmäiseksi käydään läpi hankintaa ja hankinnan määrittelyä yleisellä tasolla, josta kuvataan hankintatoimea Luottokunnassa, hankinnan hyviä käytäntöjä ja hankinnan määrittelyssä huomioitavia ja sen tasoon vaikuttavia asioita. Hankinnan määrittelyn yleistä tasoa syvennetään keskittymällä käytettävyysnäkökulmaan. Kappaleessa käydään läpi haastateltavien käsitys käytettävyyden huomioinnin nykytilasta Luottokunnassa ja tutkittavissa projekteissa ja miten käytettävyyttä voitaisiin huomioida jatkossa. Haastateltavat ja haastattelumetodi on tarkemmin esitelty kappaleessa 4.3 Teemahaastattelut. Seuraavissa kappaleissa yksittäiset haastateltavat on ai- 48 LUKU 6. TULOKSET na kun mahdollista häivytetty taustalle ja heidän mielipiteensä yhdistetty, jotta heidän anonymiteettinsä säilyisi. Tuloksista kuvataan kuitenkin esittääkö mielipiteen Luottokunnan vai Accenturen edustaja vai molemmat ja kuinka moni on tuonut saman asian esille. Kirjoittajan tulkintaa vahvistetaan sopivissa kohdin suorilla lainauksilla, jotka on erotettu selkeästi muusta tekstistä. 6.2.1 Hankintaprosessi ja hankinnan määrittely yleisellä tasolla Tehdyissä haastatteluissa oli kolme käsiteltävää teemaa: hankintaprosessi, hankinnan määrittely ja vaatimukset sekä käytettävyyden huomioiminen. Tässä kappaleessa käsitellään kahta ensimmäistä teemaa. Näiden avulla saadaan yleiskuvaa Luottokunnan hankinnoista ja voidaan suhteuttaa käytettävyysnäkökulma tähän kokonaisuuteen. Hankintaprosessin lisäksi tässä kappaleessa käsitellään yleisellä tasolla hankinnan määrittely, mitä siinä tulee huomioida ja seikat, jotka vaikuttaa sen tasoon. Nämä asettavat reunaehtoja määrittelylle, jossa käytettävyysvaatimukset ja muu käytettävyyteen liittyvä määrittely hankintavaiheessa tehdään. Hankinta Luottokunnassa ja yhteistyö Accenturen kanssa Luottokunnan projekteissa käytetään vaiheistusta, johon kuuluu erillinen vaatimusmäärittelyvaihe. Tämä vaihe voidaan tarvittaessa ulkoistaa, jolloin Luottokunnassa tehdään vain hankintaa tukevat määrittelyt tai toteuttaa sisäisesti, jolloin määrittely toteutetaan tarkemmalla tasolla, Luottokunnan edustajat kertoivat. Kaikissa tutkittavissa projekteissa tämä vaihe on ulkoistettu kokonaan tai osittain Accenturelle, jolloin hankintaa edeltävää määrittelyä ei ole kummankin osapuolen haastateltavien mukaan tarvinnut viedä niin pitkälle kuin hankittaessa pelkkää toteutusta. Haastatellut Accenturen edustajat kertoivat, että yhdessä hankkijan kanssa tehtävä vaatimusmäärittelyvaihe on yleinen käytäntö myös Accenturella ja se tarjotaan yleensä ensimmäisenä uutena alkavaan projektiin. Vasta sen jälkeen ja sen tulosten avulla kiinnitetään varsinainen IT-toteutusprojekti. Tällä erillisellä vaiheella varmistetaan, että hankkija ja toimittaja molemmat ymmärtävät, mitä järjestelmältä halutaan ja sen avulla voidaan arvioida myös paremmin projektin laajuus ja työmääräarvio. Tämän menettelyn etuna on myös se, että se vähentää riskejä niin hankkijan kuin toimittajan 49 LUKU 6. TULOKSET näkökulmasta. Esimerkiksi laajuus saadaan varmemmin kattavaksi tai projekti voidaan tarvittaessa lopettaa tähän, jos etenemisen edellytykset eivät täyty. Kysyttäessä missä vaiheessa projektin elinkaarta Accenture on tullut mukaan, molempien osapuolien edustajat kertoivat, että Luottokunnan ja Accenturen yhteistyösopimukseen kuuluu, että Accenture on mukana projekteissa heti alusta alkaen. Lisäksi yhteistyösopimus ja Accenturen konsulttien Luottokunnan tarpeiden ja prosessien ymmärrys mahdollistavat sen, ettei hankinnan määrittelyjä ole tarpeen viedä niin pitkälle, kuin toiselle toimittajalle tulisi tehdä. Kuten yksi Luottokunnan edustaja vastasi kysyttäessä oliko hankinnan määrittelyn taso riittävä: No tässä hankintamallissa nyt ei ollut tarvetta oikeastaan niinku ihan siihen alkuvaiheeseen ollakkaan tarkempaa pakettia, kyllä niitä (vaatimuksia) saatiin hyvin tarkennettua sitten matkan varrella ihan aikataulun mukaisestikin... Kummankin osapuolen haastateltavat eri projekteista kertoivat, että yhteistyösopimus mahdollistaa kevyen hankintamenettelyn. Projektien etenemisen kannalta hankinta on toiminut sujuvasti, koska missään projektissa ei jouduttu paikallaan olevaan sopimusneuvottelutilaan. Projektit, joissa vaatimusmäärittely toteutetaan yhdessä toimittajan kanssa, ovat Luottokunnalle tuttuja ja hyvin hallinnassa. Kuitenkin eräs Accenturen haastateltava kritisoi, että Luottokunnan kyvykkyys hankkia IT-ratkaisuja ilman osallistumista sen tuottamiseen on vaillinainen. Tällaisissa tapauksissa pitäisi määritellä tarkkaan etukäteen mitä ollaan ostamassa, mitä halutaan ja mikä on lopputulos, kun taas kaikissa esimerkkiprojekteissa ja haastateltavien kuvaamissa tapauksissa on lähdetty liikkeelle epävarmemmalta pohjalta. Toisaalta tämä voi olla Luottokunnan tietoinen valinta ulkoistaa myös vaatimusmäärittely toimittajille, mutta haastateltavan mukaan tulisi varoa liikaa riippuvuutta toimittajan toteuttamasta vaatimusmäärittelystä ja tärkeiden päätösten siirtämistä ulkopuolisille. Hankinnan määrittelyyn vaikuttavat tekijät Kysyttäessä hankinnan määrittelystä ja sen sopivasta tasosta, haastateltavat aloittivat usein sanoilla riippuu tapauksesta . Haastateltavien mukaan hankinnan määrittely ei ole yksioikoista, vaan riippuu useista tekijöistä. Näitä ovat haastateltavien mielestä muun muassa projektin sopimusmalli, toimittajan aikaisempi kokemus ja hankittavan järjestelmän tyyppi. Tässä projektin sopimusmallilla tarkoitetaan kahta perustyyppiä, jotka ovat kiinteähintainen tai kuluperusteinen. Kiinteähintaisessa projektissa hankkija 50 LUKU 6. TULOKSET ja toimittaja sopivat tietyn hinnan etukäteen, kuluperusteisessa projektissa toimittaja laskuttaa hankkijaa kertyvän työmäärän mukaisesti. Jos projekti on kuluperusteinen, haastateltavien mielestä hankinnan määrittelyn ei tarvitse olla niin tiukka erityisesti toimittajan näkökulmasta. Jos projekti on kiinteähintainen, silloin kahden Accenturen edustajan mukaan määrittelylle tarvitaan tarkempi taso. Tämä tarvitaan projektin hinnan arvioimiseksi, koska muuten toimittajan on pakko laittaa laskelmiinsa niin paljon epävarmuuskerrointa, ettei hinta ole enää kilpailukykyinen. Kiinteähintaisessa projektissa määrittelyn tarkempi taso estää myös raskaaseen muutospyyntöprosessiin joutumisen. Jos projekti halutaan lähteä tekemään kiinteähintaisena ilman tarkentavaa määrittelyä, tulee toimittajan ja hankkijan kuvata, miten työn laajuus sovitaan. Esimerkiksi paljonko vaatimuksia kootaan ja mitä työhön voidaan ottaa. Työn tulee olla jollakin tasolla aina kiinnitetty, jotta voidaan puolin ja toisin ymmärtää, mitä toimitukseen sisältyy. Yksi kummankin osapuolen haastateltava totesi, että jos sama toimittaja on aikaisemmin ollut tekemässä projektin edellistä vaihetta, mahdollistaa tämä kevyemmän hankinnan määrittelyn. Tällöin toimittajalla on jo ymmärrys ja hiljaista tietoa siitä, mitä halutaan, jolloin kaikkea ei tarvitse dokumentoida niin tarkkaan. Tähän ei kuitenkaan tulisi mennä, jos vaiheet halutaan kilpailuttaa eri toimijoilla. Yksi Luottokunnan edustaja nimesi hankinnan määrittelyyn vaikuttavaksi tekijäksi myös ostettavan IT-järjestelmän tyypin eli onko se hankkijalle räätälöitävä sovellus vai valmistuote. Räätälöidyissä tuotteissa hankinnan vaatimuksiin ja määrityksiin voidaan jättää enemmän vapausasteita ja toteutusta tehdä iteratiivisemmin, koska Luottokunnan edustajat voivat olla mukana ohjaamassa ja varmistamassa järjestelmän etenemistä oikeaan suuntaan. Pakettiohjelmistoissa hankinnan vaatimukset ja määrittelyt tulee tehdä laajasti ja tarkasti, jotta ohjelmiston soveltuvuus haluttuun tehtävään saadaan käytyä kattavasti läpi, haastateltava kertoi. Hankinnan määrittely Tässä kappaleessa käsitellään hankinnan määrittelyä, sen hyviä käytäntöjä ja sen toivottua tasoa, kun ulkopuolinen toimittaja otetaan mukaan projektiin. Perinteinen suurin ongelma on se, että ostaja ei ihan tiedä mitä haluaa ja myyjä ei ihan tarkkaan tiedä mitä on myymässä ja sitten kun siitä yritetään se yhdistelmä rakentaa niin siinä on aika paljon mahdollisuuksia, jossa se menee vähän pieleen. Sen takia se pohjatyö, mitä pitäis tehdä ennen sitä, 51 LUKU 6. TULOKSET ennenkuin lähtee edes toimittajia valitsemaan se on kuitenkin se joka on aika keskeinen , eräs Luottokunnan edustaja painottaa. Hankkijan itsenäisesti tekemä pohjatyö on perusta, jolla hyvä hankinta lähtee liikkeelle. Yksi kummankin osapuolen edustaja nimesi hankinnan suunnittelun ensimmäiseksi askeleeksi sisäisten sidosryhmien tunnistamisen, jotka tulee ottaa mukaan hankinnan määrittelyyn. Tällä vähennetään riskiä, että määrittelyistä jäisi jokin olennainen osa tai näkökulma puuttumaan. Toinen haastateltava lisäsi, että erityisesti Luottokunnassa harvat henkilöt tuntevat koko liiketoiminnallisen prosessin, jolloin tarvittavien osa-alueiden edustajat tulee huomioida tarkemman tiedon saamiseksi. Esimerkiksi IT-, arkkitehtuuri, hankinta- ja liiketoimintanäkökulmat tulisi huomioida lähdettäessä hankkimaan uutta IT-järjestelmää. Yksi kummankin osapuolen edustaja totesi, että hankinnan määrittelyssä tärkeämpää kuin tarkka vaatimusten taso, on ymmärtää tavoitetila, johon hankinnalla pyritään pääsemään. Tällöin hankinnan määrittelyyn voidaan jättää joustoa siihen, miten tähän tavoitetilaan päästään ja eri toimittajat voivat tarjota omia ratkaisujaan. Esimerkiksi, jos kyseessä on tekninen projekti, teknistä arkkitehtuuria ei ole välttämätöntä määritellä, vaan keskitytään haluttuun toiminnallisuuteen, kumpikin haastateltava kertoo. Tähän teemaan eräs Accenturen haastateltava lisäsi, että hankinnan määrittelyssä tulee antaa selkeä linjaus siitä mitä halutaan. Tämä on aina hankkijan vastuulla ja sitä ei tulisi siirtää ulkopuoliselle. Jo hankintavaiheessa tulisi olla hankkijan puolelta nimettynä henkilöt, joilta vaatimuksia voidaan tarkentaa epäselvissä tapauksissa ja heillä riittävät valtuudet ratkaisujen tekemiseen, haastateltava jatkaa. Toimittajalle tulee selkeästi osoittaa hankintaan käytettävät lähtödokumentit muusta dokumentaatiosta, eräs Accenturen haastateltava toivoi. Jos nämä sisältävät vaatimuksia, tulisi niiden olla yksiselitteisiä ja mitattavia. Vaatimukset, jotka sisältävät epämääräisyyttä, ovat hankalia niin hankkijalle kuin toimittajalle, koska viimekädessä ei voida määrittää ovatko ne toteutuneet. Jos hankinnan määrittelyssä on ei-mitattavia vaatimuksia, niin toimittajan ja asiakkaan tulisi yhdessä sopia, miten niiden toteutuminen varmistetaan työn aikana. 6.2.2 Käytettävyyden huomiointi hankinnan määrittelyssä Tässä kappaleessa keskitytään haastattelujen kolmanteen teemaan eli käytettävyyden huomioimiseen hankintavaiheessa. Ensimmäisenä käydään läpi 52 LUKU 6. TULOKSET mitä haastateltavien mielestä tarkoitetaan käytettävyydellä ja miten heidän mielestään käytettävyyttä ylipäätänsä huomioidaan Luottokunnassa, jotta voidaan ymmärtää mistä lähtökohdista haastattelut on tehty. Seuraavaksi käydään läpi käytettävyyden huomioinnin nykytila tutkittavien projektien avulla. Kaksi viimeistä kappaletta keskittyvät käytettävyyden huomioinnin tulevaisuuteen. Niissä käydään läpi haastateltavien vastaukset kysymyksiin tulisiko käytettävyyttä ylipäätänsä huomioida jo hankintavaiheessa ja jos kyllä, niin millä toimenpiteillä se tulisi konkreettisesti ottaa mukaan hankinnan käsittelyyn. Haastateltavien käsitys termistä käytettävyys ja käytettävyyden huomiointi Luottokunnassa Haastattelujen aluksi jokaiselta haastateltavalta kysyttiin, mitä hänestä tarkoittaa termi käytettävyys. Tällä varmistettiin, että haastateltava ja haastattelija puhuivat samasta asiasta käyttäessään kyseistä termiä ja samalla selvitettiin miten tietoisia haastateltavat ylipäätänsä ovat käytettävyydestä. Haastateltavat ymmärsivät käytettävyyden muun muassa helppokäyttöisyytenä, käytön oppimisen helppoutena, miten hyvin järjestelmä palvelee käyttötarkoitustaan loppukäyttäjän näkökulmasta ja miten vaikeaksi, mielekkääksi tai käytännölliseksi tekeminen järjestelmällä koetaan. Haastateltavat ovat siis valistuneita käytettävyydestä ja sen merkityksestä, kuten osoittaa myös yhden haastateltavan kommentti: Helppokäyttöisyyttä, sitähän se on. ... No, se nyt, kirjatermeinkö siinä on nyt ne tuloksellisuus, tehokkuus ja tyytyväisyys. Haastateltavilta kysyttiin myös haastattelun alkupäässä aihepiiriin virittäytymiseksi miten käytettävyyttä ylipäätänsä huomioidaan Luottokunnassa. Tässä mielipiteet vaihtelivat ja on havaittavissa, että käsitys käytettävyyden huomioinnista riippuu paljon projekteista, joissa henkilö on ollut. Ylipäätänsä on hieman vaikea nyt sit kommentoida sitä, koska meillähän ei ole mun tietääkseni olemassa tämmöseen niinku käytettävyyteen liittyvää ohjeistusta, jossa vaikkapa jotkut tietyt toiminnallisuudet tai muut tämmöiset huomioitaisiin... ...et varmasti sitten projektikohtaisesti sitten jollakin tasolla huomioidaan , eräs Luottokunnan edustaja totesi. Toisessa projektissa mukana ollut Accenturen edustaja taas vastasi, että hänen mielestään käytettävyyttä huomioidaan Luottokunnassa erittäin hyvin ja se näkyi projektin etenemisessä esimerkiksi käyttöliittymän varhaisena suunnitteluna ja visuaalisen suunnittelun heuristisena arviona. Et sanotaan, että mä olen ollut myös projekteissa mukana, joissa käytettävyyttä ei oo sillä lailla asiakkaan 53 LUKU 6. TULOKSET toimesta aktiivisesti huomioitu, että tässä se kyllä otettiin hyvin mukaan , haastateltava kertoi. Käytettävyyden huomioinnin nykytila Käytettävyyden huomiointi hankinnan aikana vaihteli projektikohtaisesti todella paljon. Tämä käy ilmi esimerkiksi seuraavista lainauksista, kun molemmilta haastateltavilta on kysytty näkyikö käytettävyys hankintavaiheessa ja haastateltavat olivat työskennelleet eri projekteissa. Ensimmäisen kommentin esittäjä on Accenturen edustaja, jälkimmäisen taas Luottokunnan. Näkyi siinä mielessä, että siitä keskusteltiin siinä määrittelyn tarkennuksen tarjouspyynnön yhteydessä, et Accenture voi esimerkiksi tarjota käytettävyysarviontia ja myös asiakkaan (Luottokunta) puolella keskusteluissa mukana olevilla henkilöillä, kun puhuttiin esimerkiksi rautalankamalleista tai muista, niin heillä (Luottokunnan edustajilla) oli jo mielessä kysymys, et mitenkäs nää käytettävyysnäkökulmat otettais huomioon. Joo, mun lyhyt vastaus tohon varmasti olisi ei, ei näkynyt, en muista että Luottokunnan puolelta olisi erikseen pyydetty, jos aatellaan niinkuin tarjouspyynnön sisältöä, et erikseen nostettu käytettävyysnäkökulmaa esille, et varmaan sitä keskustelua käytiin siinä vaiheessa kun mentiin niinkuin enemmän detaljitasolle, et jos vois todeta, tällaisella pääasiatasolla, niin ei huomioitu. Haastateltavilta kysyttiin myös käytettävyyden huomioinnista hankinnan aikaisissa vaatimuksissa. Kolme haastateltavista muisteli, että hankintavaiheessa ei ollut ollenkaan käytettävyysvaatimuksia. Kaksi Luottokunnan edustajaa kertoi, että varsinaisia käytettävyysvaatimuksia ei ollut, mutta suorituskykyyn liittyvät vaatimukset lisättiin myös käytettävyyden takia. Näissä kuvattiin muun muassa sivun lataamiseen kuluvaa aikaa, jolloin huomioitiin käytön tehokkuutta. Tulisiko käytettävyys ottaa huomioon hankinnan määrittelyssä Kun käytettävyyden huomioinnin nykytila hankinnan määrittelyissä oli käyty läpi haastateltavien kanssa, heiltä kysyttiin tulisiko käytettävyyttä ylipäätänsä huomioida hankintavaiheessa. Tässä haastateltavat nostivat esiin ensimmäisenä askeleena käytettävyyden merkityksen määrittämisen kyseiselle projektille. Haastateltavat nimesivät useita tekijöitä, jolla tätä voidaan arvioida. Näitä ovat esimerkiksi onko järjestelmä käyttöliittymäkeskeinen vai tekninen taustajärjestelmä, mikä on käyttäjien teknisen osaamisen taso, onko käyttäjiä kuinka paljon ja käytetäänkö järjestelmää kuinka usein. Jos ky- 54 LUKU 6. TULOKSET seessä on esimerkiksi tekninen taustajärjestelmä, jota käyttää vain muutama tekninen käyttäjä, niin käytettävyys ei ole niin kovin merkityksellinen. Mitä käyttöliittymäkeskeisempi järjestelmä, mitä isompi ja monipuolisempi käyttäjäkunta ja mitä tiheämpi käyttökertojen väli, sitä tärkeämpää on huomioida projektissa käytettävyys jo alusta alkaen. Käytettävyyden huomioinnin tarve riippuu toimittajan näkökulmasta myös siitä, missä vaiheessa projektin elinkaarta hankinta tehdään, totesi kaksi Accenturen edustajaa. Koska projekteja vaiheistetaan, eri osuudet projekteista voivat olla saman tai eri toimittajan tai Luottokunnan sisäisesti tekemiä. Kuten toinen haastateltavista kertoi kysyttäessä tulisiko tiettyä käyttäjäkeskeistä dokumentaatiota olla tehtynä jo hankinnan aikaan: No sanotaan et ei sillä suurta merkitystä ole, et palaan taas siihen että tehdäänkö yhdessä määrittelyvaihe vai tuleeko joku, tai tullaanko mukaan vasta siinä määrittelyvaiheen jälkeen. Lähinnä musta on olennaista, että ne siinä jossain vaiheessa tulee jonkun toimesta tehtyä... ...mut jos miettii sitä käytettävyyden lopputulosta, niin en mä näe siinä suurta merkitystä, et kunhan ne huomioidaan jossain vaiheessa. Kenen toimesta, niin ei se ole ratkaisevaa. Tämä siirtää vastuuta käytettävyydestä toimittajalta hankkijalle, koska hankkija pysyy samana kaikkien projektivaiheiden läpi. Jos käytettävyys on projektissa merkityksellinen, viiden haastateltavan mielestä käytettävyys on hyvä aspekti ottaa huomioon hankintavaiheessa. Mitä enemmän mennään siihen et se järjestelmä on työkaluna esimerkiksi asiakaspalvelutoiminnassa tai jossain missä sillä tehokkuudella on huomattava kustannusvaikutus, niin kyllähän sen pitäis olla ihan tärkeitä kriteerejä siellä valintavaiheissa , eräs Luottokunnan edustaja kertoi. Vain yksi Luottokunnan edustaja on eri mieltä kysyttäessä tulisiko käytettävyyttä ottaa huomioon hankinnassa ja totesi: Niin, no en tiedä, et tän tyyppistä hankintaa kuin tämä oli, ostettiinko enemmän resursseja eikä kokonaistoimitusta niin onko sillä loppujen lopuksi niin merkitystä. Tietysti me halutaan, että se käytettävyysosaaminen löytyy sieltä (toimittajalta) sitten, mut kun ei niin mitään valmista tuotosta ostettu, niin ei niitä (käytettävyyteen vaikuttavat asiat) nyt ehkä tän tyyppisen projektin alkuvaiheessa tarvitse painottaa, nekin tulee siinä sitten määriteltyä jatkovaiheessa. Miten käytettävyys voidaan ottaa huomioon hankinnan määrittelyssä Haastateltavilta kysyttiin miten käytettävyyttä voisi ottaa huomioon hankinnan määrittelyssä konkreettisesti ja onko heillä jo tiedossa jotain hyviä 55 LUKU 6. TULOKSET käytäntöjä tähän. Heidän kuvaamansa käytettävyyden huomioimisen tavat voidaan jakaa kolmeen ryhmään, jotka ovat huomioiminen vaatimustasolla, muussa dokumentaatiossa ja prosessissa. Kaksi Luottokunnan edustajaa veisi käytettävyyden huomioimisen vaatimustasolle. Mä itse näkisin, että käytettävyysvaatimukset olisivat yksi vaatimustyyppi, jotka ainakin jollakin tasolla voisi tai pitäisi olla kuvattuna jos tehdään vaatimusmäärittelyä. Ihan samalla tavalla kuin kuvataat toiminnallisia tai tietoturva tai ei-toiminnallisia vaatimuksia, niin pitäisi olla käytettävyysvaatimuksia , toinen heistä totesi. Kuitenkin kolme haastateltavaa toi esiin teoriassakin näkyneen ongelman vaatimusten mitattavuudesta ja todennettavuudesta. Käytettävyysvaatimukset on vaikea formuloida niin, et niitä pystyttäis mittaamaan tai oikein seuraamaan, senhän takia se on perinteisesti keskittynyt tällaisiin vasteaikoihin ja muihin jotka on kellotettavia, mut ei ne anna kuin pienen osan siit kokonaisuudesta , eräs Luottokunnan edustaja kertoi. Käytettävyyden huomioiminen vaatimustasolla ei ollut osalle haastateltavista lainkaan tuttua, ja he myös epäilivät hyvien vaatimusten muodostamisen olevan vaikeaa. Lisäksi yhden Accenturen edustajan mielestä puhuttaessa käytettävyydestä ja käyttöliittymästä, pelkät vaatimuslistat eivät ole riittäviä, vaan määrittelyn aikana tulee tehdä jotakin visuaalista, asiaa tukevaa dokumentaatiota, joka ohjaa totutusta. Haastateltavat mainitsivat muuksi käytettävyyttä tukeviksi ja edistäviksi dokumenteiksi käyttäjäryhmien määrittelyn, käyttötapaukset ja käyttöliittymäprototyypin. Kysyttäessä, mitä käyttäjäkeskeisen suunnittelun dokumentaatiota tulisi olla valmiina jo hankintavaiheessa, palataan taas projektien vaiheistukseen. Jos on päätetty, että järjestelmän määrittely tehdään yhteistyössä jonkun toimittajan kanssa, haastateltavista ei ollut olennaista, että hankkija on valmistellut mitään dokumentaatiota, kuten käyttötapauksia tai rautalankamalleja. Ainoa poikkeus yllä olevaan on alustava käyttäjäryhmien määrittely, joka usein tehdäänkin alkuvaiheessa ja joka auttaisi myös käytettävyyden merkityksen määrittämisessä. Luottokunnassa käyttäjäryhmien määritys tehdään enemmän teknisestä näkökulmasta, esimerkiksi minkälaisia käyttäjärooleja ja -oikeuksia järjestelmässä tulee olla, kuin kuvaamalla käytettävyysnäkökulmasta minkä tyyppisiä ominaisuuksia eri käyttäjäryhmillä on. Vaatimusten ja dokumentaation lisäksi käytettävyyttä voi huomioida projektin prosessissa, josta voidaan neuvotella hankintavaiheessa. Esimerkiksi mahdollinen käytettävyysarvio voidaan ottaa esiin jo hankintavaiheessa, koska se tulisi tehdä mahdollisimman varhaisessa vaiheessa. Kuten eräs Accenturen edustaja totesi: ...niin keskustellaan siinä hankinnan yhteydessä tulisiko sii- 56 LUKU 6. TULOKSET hen (projektiin) sisällyttää käytettävyysarviointia, et me (Accenture) tuodaan se itse ainakin siinä esiin. Usein se on myös siinä optiona, et jos asiakas kokee, että he haluavat sen Accenturen kanssa tehdä, niin voidaan se sitten sopia projektin aikana. Kaksi Accenturen edustajaa mainitsi käytettävyysarvion ja erilaiset katselmoinnit loppukäyttäjien kanssa toivotuksi käytettävyystoimenpiteeksi. Näiden tuloksien perusteella voidaan tehdä järjestelmään käytettävyyttä parantavia muutoksia. Heistä toinen myös ehdotti, että prosessia koskevia päätöksiä voisi viedä myös vaatimuksiksi. Esimerkiksi Projektissa tulee tehdä käyttöliittymän arviointi käytettävyysnäkökulmasta. Eräs Luottokunnan edustaja totesi, että hankkijan puoleltaan haluttaisiin enemmän toimittajan omaa käytettävyysosaamista ja projektiin henkilöitä, jotka miettivät käyttöliittymää ja sen suunnittelua. Kaksi Accenturen edustaja totesi, että myös hankkijan tulisi huomioida mahdollinen omien ja asiakkaan loppukäyttäjien ajan varaaminen projektityöhön, jotta voidaan mahdollistaa heidän käyttämisensä projektin aikana esimerkiksi katselmointiin. Kuten haastateltava kertoi: Ongelmana mä näen sen, että ne ihmiset, jotka tekee sitä jokapäiväistä työtä, ..., niin sieltä ei ollut tässä projektissa koko aikana täyspäiväistä ihmistä mukana. Me tehtiin heille tässä samalla työkalua, jota he käyttävät, mutta he eivät edes halunneet olla määrittelemässä sitä, niin se on aika eturistiriita heille. Toinen haastateltavista taas koki, että jos jotain pitäisi projektissa parantaa, niin joitakin käyttäjäryhmiä olisi voinut ottaa voimakkaammin mukaan jo ihan alkuvaiheessa. Useampi Accenturen edustaja toivoi, että käytettävyyttä huomioitaisiin vahvemmin projektikokonaisuudessa. Luottokunnan edustajat taas toivoivat, että Accenture olisi joissakin tapauksissa oma-aloitteisemmin tuonut käytettävyyden yleisiä parhaita käytäntöjä mukaan projektityöhön. Näiden toiveiden konkretisoiminen oli kuitenkin vaikeaa. Kummankaan osapuolen edustajat eivät osanneet kertoa esimerkkejä projekteista, joissa käytettävyys olisi huomioitu hyvin. Sen sijaan vastaesimerkkejä pieleen menneistä projekteista oli helpompi kuvata. 57 Luku 7 Tulosten analyysi ja johtopäätökset Tämän luvun tärkeimpänä tavoitteena on vastata esitettyihin tutkimuskysymyksiin: Miten käytettävyys huomioidaan IT-järjestelmien hankintavaiheessa Luottokunnassa ja miten käytettävyys voitaisiin huomioida paremmin hankintavaiheessa? Ensimmäisessä kappaleessa keskitytään ensimmäiseen tutkimuskysymykseen. Tulosten analyysissä kuvataan eri aineistoissa näkynyt käytettävyyden huomiointi Luottokunnassa ja lopuksi kaikki vedetään yhteen käytettävyyden huomioinnin nykytilaksi. Toisessa kappaleessa keskitytään toiseen tutkimuskysymykseen. Nykytilan ja kerätyn aineiston avulla Luottokunnalle on koottu yleisiä suosituksia hankintaprosessista ja hankinnan määrittelystä. Luvun lopuksi keskitytään antamaan suosituksia käytettävyyden huomioinnin parantamisesta hankintavaiheessa. 7.1 Tulosten analyysi Tässä kappaleessa käsitellään yhteenvedonomaisesti käytettävyyden huomioinnin nykytila Luottokunnassa. Ensimmäiseksi käsitellään projekteista löytyneet käytettävyysvaatimukset, sitten projektien muu hankinnan määrittelydokumentaatio ja viimeiseksi haastatteluista saadut tulokset. Lopuksi kaikki nämä analysoidaan kokonaisuutena, jolla vastataan esitettyyn tutkimuskysymykseen: Miten käytettävyys huomioidaan IT-järjestelmien hankintavaiheessa Luottokunnassa? 58 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET Taulukko 6: Eri projektien sisältämien käytettävyysvaatimusten määrä Projekti Suorat Epäsuorat Korttitilitysten raportointi- 1 12 0 0 palvelu ja Luottokunta Sopimusportaali Business Eurocard - uudistus 7.1.1 Yhteenveto projektien käytettävyysvaatimuksista Projekteista oli tunnistettavia suoria ja epäsuoria käytettävyysvaatimuksia taulukon 6 mukaisesti. Korttitilitysten raportointipalvelu - ja Luottokunta Sopimusportaali -projektit on taulukossa yhdistetty samalle riville, koska niiden hankinnan vaatimusmateriaali on sama, eikä siitä voida erotella kumpaan projektiin tietyt vaatimukset kuuluvat. Lisäksi on myös mahdollista, ettei käytettävyysvaatimuksia toteutettu lopulta kummankaan projektin piirissä, jolloin luvut eivät täysin täsmää. Tuloksista huomataan, että tutkittavat projektit eivät juuri sisältäneet käytettävyysvaatimuksia hankintavaiheessa, jossa ulkopuolinen toimittaja tulee ensimmäistä kertaa mukaan projektiin. Löydetyt vaatimukset olivat lähinnä epäsuoria, eli käytettävyyttä ei erityisesti painotettu, vaan se tuli huomioitua välillisesti hyvien ratkaisujen kautta. Ainoa löydetty suora käytettävyysvaatimus, asiakaspalvelijoiden pitää pystyä käyttämään järjestelmää järkevällä ja tehokkaalla tavalla , on validi, muttei mitattava, jolloin sekin jää tavoitteessaan vaillinaiseksi. Hankintavaiheen vaatimukset olivat kaikissa tutkituissa projekteissa hyvin keskeneräiset, koska varsinainen vaatimusmäärittelytyö tehtiin vasta projektityönä. Lisäksi vaatimukset säilyivät kaikissa projekteissa elävinä loppuun asti, kuten kerrotaan projektien kuvauksissa kappaleessa 5.2 Tutkittavat projektit, eli niitä lisättiin ja päivitettiin koko projektin elinkaaren ajan. 7.1.2 Yhteenveto käytettävyyden huomioinnista projektien muussa hankinnan määrittelydokumentaatiossa Hankinnan muussa määrittelydokumentaatiossa keskitytään kuvaamaan korkealla tasolla järjestelmän tulevia toiminnallisuuksia ja dokumentaatio on vielä kovin puutteellista, koska projektit ovat alkuvaiheessa. Suoria käytettä- 59 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET vyyteen liittyviä viittauksia on löydettävissä vain muutama eli siihen ei ole kiinnitetty suurta huomiota. Käyttäjistä määritellään korkealla tasolla käyttäjärooleja, mutta näkökulma on lähinnä tekninen tai työnohjauksellinen. Alkavan projektin käytettävyystoimenpiteistä ja loppukäyttäjän huomioinnista on löydettävissä joitakin viitteitä, mutta ei tarkoituksellisella ja tietoisella tasolla. Käytettävyydestä haluttaisiin, että se huomioidaan ja käyttökokemuksesta toivotaan vähintään tyydyttävää, mutta sitä ei yksiselitteisesti vaadita. 7.1.3 Yhteenveto käytettävyyden huomioinnin haastattelutuloksista Luottokunnassa ei ole mitään yhtenäistä käytäntöä käytettävyyden huomioinnille hankinnan aikana tai projektien myöhemmissä vaiheissa, joten se vaihteli paljon projektista toiseen. Useampi haastateltava mainitsee, että käytettävyyttä on jollakin tavalla huomioitu tutkittavissa projekteissa, mutta kuten yksi Luottokunnan edustaja totesi: Yleisesti Luottokunnassa kiinnitetään hyvin huomiota käytettävyyteen, mutta sitten taas se vaatimusten määrämuotoistaminen ja niiden yksiselitteisyys tai mitattavuus on aika heikolla tolalla. Et paljon puhutaan käytettävyydestä, mut miten tuoda se toimittajalle asti esille, niin siinä on varmasti puutteita. Toisin kuin vaatimusten teorian perusteella voisi olettaa, vaatimusten loppuunsaattamisen myöhäiseen vaiheeseen vaikutti se, ettei niillä ollut kaikissa projekteissa suurta painoarvoa. Esimerkiksi Business Eurocard -uudistuksessa käyttötapauksilla oli suurempi merkitys ja Luottokunta Sopimusportaali projektissa käyttöliittymädemolla, ja niitä käytettiin vaatimusten asemassa. Kuten yksi Accenturen edustaja kertoi kysyttäessä olivatko vaatimukset staattinen dokumentti: Ei, ja nää kirjotetut vaatimukset oli vähän toissijaisia, tosiaan se käyttöliittymädemo toimi enemmänkin vaatimuksena, ja osittain nää kirjotetut vaatimukset unohtukin jossain määrin ja olivat huonolla tolalla. Kirjalliset vaatimukset eivät siis välttämättä takaa käytettävyyden huomioimista, varsinkin jos ne lisätään vasta projektin loppupuolella. Käytettävyyden lähes täydellinen puuttuminen hankinnan määrittelystä kuitenkin jättää toimittajan oman harkinnan varaan, miten paljon panostusta käytettävyyteen laitetaan. Hankinnassa tapahtunut huomiointi johti yhden projektin kohdalla kiiteltyyn lopputuotteeseen. Tässä projektissa käytettävyyttä pyrittiin viemään hankinnan jälkeen vaatimustasolle ja käytettävyys näkyi vähintään määrittelyn lopputuotteina, kuten käytettävyysarvioinnin raportissa ja käyttötapauksis- 60 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET sa. Toisessa projektissa, jossa käytettävyyttä ei niin huomioitu, lopputulos oli kuitenkin myös kiitelty ja loppukäyttäjien mielestä selkeä käyttää. Yhdeksi syyksi koettiin projektissa käytetty käyttöliittymätyökalu, jolla saatiin tehtyä interaktiivisia prototyyppejä, joita demottiin asiantuntijoille ja jonkin verran myös loppukäyttäjille. Et se käytettävyys tuli tuota kautta, jos mä sanon, että vahingossa huomioitua, se on ehkä vähän voimakas ilmaus, mutta näin jälkikäteen arvioiden niin se Accenturelta tullut ehdotus ottaa tuo väline (käyttöliittymämallinnustyökalu) käyttöön, oli yksi sellainen onnistumisen kriteeri näin jos katsoo sitä projektin läpivientiä ja että siitä saatiin sellainen, että se oli aika nopeasti myös asiakkaan mielestä hyvä... , Luottokunnan edustaja kertoi. Käytettävyyden huomiotta jättäminen hankinnassa ei siis tarkoita, etteikö lopputulos voisi olla hyvä käytettävyydeltään, mutta se jää arpapeliksi. 7.1.4 Yhteenveto käytettävyyden huomioinnin nykytilasta hankintavaiheessa Luottokunnassa Tutkimuksen perusteella voidaan todeta, että käytettävyys ei näy hankintavaiheessa juuri lainkaan dokumentaatiossa, mutta jonkin verran tulevan prosessin määrittämisessä. Käytettävyyden merkitys tiedostetaan Luottokunnassa ja siitä käydään jonkin verran keskusteluja projektien hankinnan yhteydessä, mutta sitä ei selkeästi vaadita osana hankinnan määrittelyä. Käytettävyyden hankinnan jälkeinen huomiointi riippuu projektista ja sen tekijöiden valveutuneisuudesta, vaikka järjestelmän käytettävyys koettaisiin projektin lopputuloksen kannalta merkitykselliseksi. 7.2 Suositukset Luottokunnalle käytettävyyden huomioinnista hankinnan määrittelyssä On monta syytä, miksi Luottokunnan tulisi huomioida käytettävyys sen hallinnoimissa IT-järjestelmissä. Luottokunnan sisäiseen käyttöön tarkoitetuissa järjestelmissä tehokkuus ja tuloksellisuus ovat tärkeitä, koska Luottokunnan liiketoiminnan kustannuksista ison osan muodostavat henkilökustannukset. Tällöin jo pieni parannus esimerkiksi käytön tehokkuudessa kumuloituu merkittäväksi kustannussäästöksi vähempien virheiden, niiden korjaamiseen käytetyn ajan vähenemisen ja tehokkaamman työskentelyn ansiosta. Luottokunnan asiakkaiden käytössä olevat järjestelmät luovat mielikuvaa yrityksestä, sen luotettavuudesta ja toiminnasta. Luottokunnan tunnuslause on 61 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET Ecient Payments ja se pyrkii tekemään korttimaksamisesta sujuvampaa kaikille osapuolille [26]. Tämän voi johtaa suoraan Luottokunnan tarjoamiin järjestelmiin, joiden tulee tarjota sujuva käyttökokemus, koska mielikuva jumittavasta järjestelmästä voi muuten levitä koskemaan koko yritystä. Helppokäyttöiset järjestelmät myös vähentävät Luottokunnan tarjoaman tuen tarvetta, jolloin saavutetaan jälleen kustannussäästöjä. Tässä kappaleessa kuvataan kerätyn teorian ja empirian pohjalta suositukset Luottokunnalle käytettävyyden huomioinnista hankinnan määrittelyssä. Toimintatapoja pyritään kuvaamaan yleistäen kaikille toimittajille, mutta johtuen tutkimuksen kohteesta, ne voivat soveltua parhaiten Accenturen kanssa toimimiseen, esimerkiksi yhteistyösopimuksen huomioimisen kannalta. Suositukset on jaettu kolmeen osaan, joista ensimmäinen koskee koko hankintaprosessia ja toinen hankinnan määrittelyä yleisesti. Näistä yleisemmistä asioista annetaan suosituksia, koska ne luovat puitteet käytettävyyden huomioinnille. Viimeisessä osassa käsitellään käytettävyyden huomioimista hankinnan määrittelyssä ja annetaan suositukset sen huomioinnista. 7.2.1 Hankintaprosessi Luottokunta pyrkii ulkoistamaan IT-kehityksen ja on solminut yhteistyösopimuksen Accenturen kanssa. Tämä mahdollistaa kevyemmän hankintaprosessin, koska esimerkiksi sopimusehdot periytyvät pääsopimukselta, jolloin niitä ei tarvitse erikseen joka projektin alussa neuvotella. Luottokunta ja Accenture myös käyttävät hyvin joustavaa sopimusmallia, jolloin esimerkiksi laajuutta tai aikataulua voidaan muuttaa yhteisellä päätöksellä. Tämä kuvaa hyvää luottamusta yritysten välillä. Luottokunnalle on luotu oma hankintaprosessi ja sen ohjeistus, mutta käytännössä hankinta on Accenturen suuntaan suhteellisen epävirallista. Tarjouspyynnöt tehdään suullisesti tai sähköpostitse suoraan Accenturen edustajille yhteistyösopimuksen puitteissa. Yhteistyösopimus vähentää kilpailutuksen ja muodollisuuden tarvetta, mutta Luottokunnan tulisi ylläpitää oman prosessinsa mukaista kyvykkyyttä tarjousten tekemiseen. Luottokunnassa IT-järjestelmähankinnat koskevat kerrallaan useita eri organisaation toimintoja. Harvat henkilöt tuntevat koko liiketoiminnallisen prosessin, joten lähdettäessä suunnittelemaan hankintaa, tulisi tunnistaa sisäiset sidosryhmät, jotka tulee ottaa mukaan hankinnan määrittelyyn. Tämä vähentää riskiä, että jokin olennainen näkökulma jäisi puuttumaan tarjouspyynnöstä. Tämä toimii Luottokunnassa tällä hetkellä hyvin, esimerkiksi liiketoiminnan eri tahoja otetaan mukaan jo varhaisessa vaiheessa. Olisi kui- 62 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET tenkin hyvä, että Luottokunnassa olisi myös useampia ihmisiä, jotka hahmottavat kokonaiskuvaa, jolloin järjestelmien päällekkäisyydet ja kokonaistehokkuus tulevat huomioiduksi. 7.2.2 Hankinnan määrittely Kaikissa tutkituissa projekteissa ja yleisemmin Luottokunnassa projekteihin kuuluu erillinen määrittelyvaihe. Tämä on hyvä käytäntö joka mahdollistaa tukevan pohjan rakentamisen tulevalle projektille. Jos kyseessä on ITjärjestelmäprojekti, on suositeltavaa, että vaihe ulkoistetaan, jos tilaajalla itsellään ei ole tarvittavaa teknistä osaamista. Tällöin toimittajan tekninen asiantuntemus saadaan täysimittaisesti käyttöön ja projektin toteutuksen näkökulmat voidaan ottaa huomioon jo heti alkuvaiheessa kustannustehokkuuden parantamiseksi. IT-järjestelmien toteuttaminen ei kuulu enää Luottokunnan omiin osaamisalueisiin, jolloin ulkoistamiselle on myös strateginen lähtökohta. Tutkituissa projekteissa toimittaja oli otettu jo varhaisessa vaiheessa mukaan projektiin, joten tämä toteutuu jo nykyisellään hyvin. Vaikka IT-toimittaja otetaan mukaan määrittelyyn, vastuu toiminnallisesta määrittelystä tulisi säilyä Luottokunnan asiantuntijoilla. Tämän takia Luottokunnan tulee kehittää myös omaa vaatimusmäärittelyn ja toiminnallisen määrittelyn osaamista ja käytäntöjä. Esimerkiksi eri projektien hankintaa edeltäneet dokumentointikäytännöt (mitä ja miten dokumentoidaan) ja vaatimusten taso vaihtelivat projektista toiseen. Tähän auttaisivat Luottokunnan intrasta saatavilla olevat dokumenttipohjat ja ohjeistus, miten niitä käytetään. Myös määrittelyvastuun keskittäminen tietyille liiketoiminnan henkilöille lisäisi heidän osaamistaan. Dokumentaation yhtenäistäminen ja sen laadun parantaminen mahdollistavat myös projektin eri vaiheiden helpomman kilpailutuksen edellisen vaiheen materiaalin toimiessa aina tarjouspyyntömateriaalina seuraavalle vaiheelle. Jotta siirto toimittajalta toiselle tai Luottokunnalta toimittajalle onnistuu sujuvasti, on materiaalin oltava mahdollisimman täydellistä ja itsenäistä. Tutkituissa projekteissa Accenture oli mukana usein projektin alusta aivan sen loppuun. Tässä hyvä puoli on ollut se, että tekijät pysyivät samoina, jolloin heidän keräämänsä osaaminen pysyi Luottokunnan käytössä. Uusi toimittaja tarkoittaa aina alussa tehottomuutta aiheen omaksumisen takia, mutta hyvä dokumentaatio tukee tässä ja mahdollistaa nopeamman siirtymisen tuottavaan työhön. 63 LUKU 7. 7.2.3 TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET Käytettävyyden huomiointi hankinnan määrittelyssä Kun Luottokunnassa lähdetään projektoimaan uutta IT-järjestelmää tai siihen liittyvää uudistusta, tulisi siitä selvittää, onko käytettävyys lopputuotteelle tai -palvelulle strategisesti tärkeä piirre. Tätä varten järjestelmän nykyinen tai suunniteltu käyttäjäkunta ja heidän korkean tason tehtävänsä tulisi selvittää. Käyttäjäryhmien määrittelyssä tulisi ottaa teknistä näkökulmaa, kuten käyttäjärooleja, laajemmin huomioon käyttäjien järjestelmän käyttöön vaikuttavia ominaisuuksia. Tällaisia ovat esimerkiksi teknisen osaamisen taso, käyttävätkö he järjestelmää harvoin vai usein ja onko käytön aikana mahdollisia häiriötekijöitä, jotka vaikuttavat käyttöön esimerkiksi sen keskeyttämällä. Käyttäjäpersoonien luomisella myös asiantuntijoille saataisiin konkretisoitua loppukäyttäjien näkökulmaa. Mitä monipuolisempi, laajempi ja teknisesti valveutumattomampi käyttäjäkunta järjestelmällä on, sitä enemmän tulisi kiinnittää huomiota järjestelmän helppokäyttöisyyteen ja opittavuuteen. Luottokunnan sisäisissä järjestelmissä huomiota tulisi kiinnittää erityisesti haluttuun tehokkuuteen ja virheettömyyteen ja Luottokunnan ulkopuolisille tarjoamissa järjestelmissä tarvitun tuen haluttuun tasoon. Jos käytettävyys nähdään projektissa epäolennaiseksi, esimerkiksi koska kyseessä on tekninen taustajärjestelmä, ei toimenpiteisiin tarvitse ryhtyä. Jos käytettävyys taas on olennainen laatuvaatimus, otetaan se huomioon jo hankinnan määrittelyssä. Kaikissa tutkituissa projekteissa vaatimuksia päivitettiin ja täydennettiin koko projektin elinkaaren ajan, jolloin hankintavaiheen vaatimusten ei voikaan olettaa olevan kattavia. Vaatimukset eivät myöskään olleet niin isossa roolissa kaikissa projekteissa, vaan muu dokumentaatio saattoi hoitaa niiden roolin. Tässä tutkimustapauksessa myös Luottokunnan ja Accenturen välinen yhteistyösopimus on mahdollistanut väljemmän hankinnan määrittelyn joustavan sopimusmallin ja yhteistyön takia. Löydetyssä teoriassa keskityttiin paljon käytettävyyden viemiseen vaatimustasolle, koska tutkitut tapaukset ovat usein julkishallinnon puolelta, joissa tarjousdokumentaatioon kuuluu projektin laajuuden tarkka määritys vaatimusten kautta. Luottokunnassa tämän ei tulisi olla keskeisin keino, koska hankinnan aikaiset vaatimukset ovat epätäydellisiä ja vaatimusten rooli ylipäätänsä ei ole merkittävä. Käytettävyyden huomioiminen muussa dokumentaatiossa ei myöskään ole keskeisin keino, koska nämä tehdään yleensä vasta projektityönä hankinnan jälkeen. Tutkituissa projekteissa Accenturelta haettiin oikeastaan enemmän resursseja toteutuksen määrittelyyn, kuin valmiiksi vaatimuksilla tai muulla do- 64 LUKU 7. TULOSTEN ANALYYSI JA JOHTOPÄÄTÖKSET kumentaatiolla määritellyn tuotteen tarjousta, jolloin ei voidakaan keskittyä tuotteen ominaisuuksiin ja niiden käytettävyyteen. Käytettävyyden huomioiminen tulisi tämän takia tehdä prosessitasolla hankintavaiheessa. Tällöin hankintavaiheessa voidaan vaatia toimittajalta, että se pystyy osoittamaan tarvittaessa oikealla osaamisproililla olevan, käyttöliittymäsuunnitteluun erikoistuneen henkilön projektiin. Hankintaneuvotteluissa tulisi keskustella, otetaanko projektiin mukaan käyttäjäkeskeisen suunnittelun toimenpiteitä, kuten käytettävyysarviointia tai -katselmointia, jolloin näihin ja niistä seuraaviin mahdollisiin korjauksiin osataan varautua aikataulullisesti. Projektista tulee myös huomioida, minkälaista käyttäjäkeskeisen suunnittelun dokumentaatiota projektin aikana tullaan tuottamaan. Hankkijan itse tulee huomioida omien työntekijöidensä saatavuus määrittelyn avuksi ja mahdollisten ulkopuolisten loppukäyttäjien rekrytointi katselmointiin, ellei tätä ulkoisteta erikseen toimittajalle. Haastateltavat kaipasivat käytettävyyden yleisten käytäntöjen ja hyvien periaatteiden noudattamista. Lisäksi Luottokunta tarjoaa jo useita erilaisia verkkopalveluita, mutta yhtenäinen linjaus niiden toiminnasta puuttuu. Jotta näitä yleisiä periaatteita voitaisiin konkretisoida ja Luottokunnan tarjoamia palveluita yhtenäistää, tulisi koota Luottokunnan oma käyttöliittymäohjeistus ja ulkoasumalli, jossa määritettäisiin korkean tason toimintaperiaatteet verkkosivuille, -portaaleille ja -palveluille. Ohjeistus koskisi esimerkiksi yleisiä noudatettavia periaatteita, käytettävää asettelua sekä käyttöliittymäelementtejä ja niiden toimintalogiikkaa. Ohjeistus voidaan tarvittaessa tehdä erikseen Luottokunnan sisäiseen käyttöön ja Luottokunnan asiakkaiden käyttöön tuleville järjestelmille. Tämä tarkoittaisi, että vastaisuudessa kaikki Luottokunnan omalla brändillään tarjoamat järjestelmät muodostaisivat yhtenäisen kokonaisuuden, jolloin käyttäjä heti tietäisi, millä logiikalla järjestelmä toimii. Lisäksi tämä muodostaisi haluttaessa selkeän ja mitattavan vaatimuksen, Toteutuksen tulee olla Luottokunnan käyttöliittymäohjeistuksen mukainen , jolloin vastuu sen noudattamisesta siirtyy toteuttajalle. Järjestelmän käytettävyys- ja systeemitestausta voidaan toteuttaa projektin sopivassa vaiheessa tätä ohjeistusta vasten. 65 Luku 8 Yhteenveto ja pohdinta Tässä työssä tutustuttiin kolmeen Accenturen Luottokunnassa toteuttamaan projektiin aineiston laadullisen analyysin avulla. Työssä selvitettiin, miten projektien hankintavaiheessa on huomioitu käytettävyyttä ja annettiin suosituksia, miten Luottokunta voisi jatkossa ottaa käytettävyyden paremmin huomioon IT-järjestelmähankinnoissaan. Työssä tehtiin aineiston laadullista analyysiä. Aineisto koostui projektien kirjallisesta dokumentaatiosta ja projekteihin osallistuneiden henkilöiden haastatteluista. Projektia edeltäneestä materiaalista tutustuttiin vaatimuksiin ja mahdolliseen muuhun dokumentaatioon pyrkien löytämään niistä käytettävyyteen liittyviä asioita. Projektien vaatimuksista havaittiin, etteivät ne sisältäneet lainkaan valideja ja mitattavia suoria käytettävyysvaatimuksia ja tutkimuksessa löydettiin vain muutamia epäsuoria vaatimuksia ja yksi validi, muttei mitattava käytettävyysvaatimus. Hankinnan muussa määrittelydokumentaatiossa keskityttiin kuvaamaan korkealla tasolla järjestelmän toiminnallisuuksia ja suoria käytettävyyteen liittyviä viittauksia oli vain muutama kappale. Tulevan projektityön aikana tehtävästä käytettävyyden huomioinnista on viitteitä, muttei konkretiaa. Haastatteluissa kartoitettiin käytettävyyden huomioinnin nykytilaa hankinnassa ja miten sitä voitaisiin ottaa huomioon vastaisuudessa. Käytettävyyden huomiointi vaihtelee tällä hetkellä täysin projektikohtaisesti ja siitä ei ole mitään koko Luottokunnan tasoista ohjeistusta. Toisissa projekteissa se otetaan hyvin huomioon ja toisissa sitä ei kovin aktiivisesti huomioida. Käytettävyys tulisi ottaa huomioon, jos se on projektissa merkityksellinen tekijä onnistuneen lopputuloksen kannalta. Käytettävyyden vieminen vaatimustasolle aikaansai ristiriitaisia kommentteja ja muu dokumentaatio todettiin yleensä tehtävän vasta projektityönä. Sen sijaan useampi haastateltava mainitsi käy- 66 LUKU 8. YHTEENVETO JA POHDINTA tettävyysarviot hyvänä käytäntönä ja käyttöliittymäasiantuntijan tuomisen mukaan projektityöryhmään. Tutkimustulosten pohjalta Luottokunnalle annettiin seuraavia suosituksia käytettävyyden huomioinnista: 1. Käyttäjäryhmien ominaisuuksien määrittäminen: Käyttäjäryhmien määrittelyssä tulisi ottaa teknistä näkökulmaa laajemmin huomioon käyttäjien järjestelmän käyttöön vaikuttavia ominaisuuksia. 2. Käytettävyyden merkityksen määritys uudessa projektissa: Mitä monipuolisempi, laajempi ja teknisesti taitamattomampi käyttäjäkunta, sitä olennaisempaa on ottaa käytettävyys huomioon. Jos käytettävyys todetaan epäolennaiseksi, ei jatkotoimenpiteitä tarvita. 3. Huomioidaan käytettävyys hankintavaiheessa prosessitasolla: Pyydetään toimittajalta tarvittaessa projektiryhmään käyttöliittymäsuunnitteluun erikoistuneita henkilöitä, päätetään tehdäänkö projektissa käytettävyysarvio ja varataan tarvittaessa aikaa loppukäyttäjiltä 4. Luottokunnan käyttöliittymäohjeistuksen ja ulkoasumallin kokoaminen: Konkretisoidaan haluttuja käytäntöjä ja yhtenäistetään Luottokunnan tarjoamia palveluita 8.1 Pohdintaa annetuista suosituksista Kirjallisuudessa kritisoidaan käytettävyyden huomioimista hankintavaiheessa prosessitasolla, koska tällaiset vaatimukset ovat helposti todennettavia, mutta ne eivät ole valideja siinä mielessä, että niiden toteutuminen takaisi mitään järjestelmän käytettävyydestä [22]. Hyvistä käytettävyysvaatimuksista hankintavaiheessa ei kuitenkaan anneta mitään hyviä esimerkkejä niiden vaikean muotoilun takia, vaikka tutkimuksissa tunnutaan oletettavan, että ne olisivat ainoa oikea tapa varmistaa lopputuotteen käytettävyys. Tässä tutkimustapauksessa vaatimukset ja muu dokumentaatio olivat kuitenkin hankintavaiheessa vielä pääosin tekemättä, jolloin ainoa mihin voidaan todella vaikuttaa, on itse prosessi. Käytettävyysasiantuntijan tai käytettävyysarvioinnin mukaan ottaminen projektiin ei takaa käytettävää lopputuotosta, mutta varmistaa sen, että käytettävyyttä pyritään aktiivisesti ottamaan huomioon. Tällä hetkellä käytettävyyden huomiointi on satunnaista, jolloin se on selkeä parannus nykytilaan. 67 LUKU 8. YHTEENVETO JA POHDINTA Kun käytettävyyden huomiointi yhdistetään yksiselitteiseen käyttöliittymäohjeistukseen, voidaan käytettävyys viedä myös vaatimus- ja määrittelytasolle. Kun näitä toimenpiteitä käytetään, saadaan lisää tietoa niiden vaikutuksesta lopputuotteen käytettävyyteen ja prosessia voidaan edelleen kehittää. 8.2 Tutkimuksen luotettavuus ja yleistettävyys Tutkimuksen metodina käytettiin aineiston laadullista analyysiä ja aineistona projektien kirjallista materiaalia ja teemahaastatteluja. Tutkimuksen luotettavuuden ongelmat keskittyvät aineiston keruun ja kattavuuden ongelmiin ja laadullisen analyysin ongelmiin. Tässä kappaleessa käsitellään mahdollisten luotettavuusongelmien lisäksi tutkimuksen yleistettävyyttä muihin vastaaviin tapauksiin. Tutkimuksen aineistona käytettiin projekteista kerättyä materiaalia ja projekteihin osallistuneiden henkilöiden haastatteluja. Tämän aineiston keruussa oli useita haasteita, joilla on voinut olla vaikutusta tutkimuksen luotettavuuteen. Hankintaa edeltäneiden vaatimusten ja materiaalien kerääminen tapahtui itsenäisesti projektien verkkolevyiltä ja sähköisistä arkistoista sekä projekteihin osallistuneilta henkilöiltä pyytämällä. Jokaisella projektilla oli erikseen Luottokunnan ja Accenturen tiedostoja, joita piti kerätä eri kohteista, joista kaikki sisälsivät satoja, ellei tuhansia dokumentteja. Dokumentit valittiin pääosin niiden päiväyksen mukaisesti, eli dokumentin viimeisin muokkauspäivämäärä tuli olla ennen hankintapäätöksen päivämäärää. Jos dokumenttia on muutettu tämän jälkeen, tarkoittaa se, että se ei päätynyt tutkittavien dokumenttien joukkoon, vaikka olisi sinne kuulunut. Toisaalta näissä tapauksissa olisi ollut mahdotonta erottaa, mikä osa dokumenttia on kirjoitettu ennen hankintaa ja mikä sen jälkeen. Useita dokumentteja oli onneksi versioitu niin, että niistä oli erikseen hankintaa edeltävä versio ja useampia hankinnan jälkeisiä, eteenpäin vietyjä versioita erotettuina versionumeroinnilla. Jokaisesta projektista löydettiin kuitenkin otos hankintaa edeltävää dokumentaatiota ja vaatimuslistaus, ja niiden tuloksia voidaan yleistää koskemaan myös mahdollisesti puuttunutta dokumentaatiota. Kerätyllä aineistolla saatu kuva käytettävyyden huomioinnin nykytilasta hankinnassa myös vastasi haastattelujen tuloksia, joten voidaan todeta aineiston olleen riittävä. Kirjallisen materiaalin lisäksi tutkimusaineistona käytettiin projektihenkilöiden haastatteluja. Kaikki haastateltavat olivat osallistuneet aktiivisesti projektityöhön, mutta kaikki eivät olleet mukana jo hankintavaiheessa. Tämä tarkoittaa, että osa haastatteluilla kerätystä tiedosta on toisen käden tietoa, 68 LUKU 8. YHTEENVETO JA POHDINTA jonka haastateltavat ovat saaneet projektissa aikaisemmin olleilta ihmisiltä. Osa hankintavaiheessa mukana olleista ihmisistä, jotka olisivat olleet parempia tietolähteitä, oli jo vaihtanut työnantajaa tai Accenturella toiseen asiakkuuteen, jolloin heitä ei tavoitettu tai heillä ei ollut kiinnostusta osallistua tutkimukseen. Toisen käden tiedon ongelmaa vähennettiin kahdella haastateltavalla per projekti, jolloin tietoja pystyttiin vahvistamaan ja saamaan lisää toisesta haastattelusta. Lisäksi joitakin tietoja, kuten aikataulua ja hankintadokumentaatiota, pystyttiin verioimaan myös kirjallisen materiaalin avulla. Kerättyä aineistoa käsiteltiin laadullisella analyysillä. Vaatimusten analyysissä käytettävyysvaatimusten tunnistaminen ja rajaaminen oli haastavaa. Esimerkiksi onko eri aikavyöhykkeillä olevien käyttäjien huomioiminen tai tiettyjen toimintojen vasteajat käytettävyysvaatimuksia? Monet asiat vaikuttavat järjestelmän käyttökokemukseen, jolloin ne ovat eräänlaisia käytettävyysvaatimuksia. Tätä varten käytettävyysvaatimusten jaottelussa otettiin käyttöön termit suora ja epäsuora käytettävyysvaatimus, jolloin tätä ongelmaa pystyttiin ainakin osittain kiertämään. Suorat käytettävyysvaatimukset oli aineistosta helppo tunnistaa, mutta joitakin epäsuoria on saattanut jäädä huomioimatta. Muusta määrittelydokumentaatiosta poimittiin vain suorat viittaukset käytettävyyteen, käyttäjiin ja käyttöliittymään, jolloin niissä ei ollut samaa problematiikkaa kuin vaatimuksissa. Haastatteluaineiston käsittelyssä selkeä menetelmä ja hyvät työkalut auttoivat tulosten käsittelyssä. Menetelmänä teemahaastattelu soveltui tutkimustapaukseen ja -kysymyksiin, koska käsiteltiin laajoja ja vaikeita aiheita laadullisesti ilman selkeää hypoteesia lopputulemasta. Kaikki haastattelut nauhoitettiin, litteroitiin ja siirrettiin laadullisen aineiston käsittelyyn tarkoitettuun työkaluun. Nauhoittaminen mahdollisti keskittymisen haastattelutilanteeseen ja aineiston luotettavamman käsittelyn myöhemmin. Työkalu mahdollisti haastattelutulosten selkeän jäsentämisen ja kategorisoinnin. Työkalussa eri kategorioista säilyi suora yhteys haastateltavien kommentteihin, mikä näkyy luotettavempina ja vähemmän subjektiivisina tuloksina. Haastatteluissa onnistuttiin keskittymään tutkimuskysymyksien kannalta olennaisiin teemoihin, jolloin niihin pystyttiin kerätyllä aineistolla vastaamaan. Tutkimuksen luotettavuuteen on osaltaan voinut vaikuttaa yrityssalaisuuksien säilyttäminen. Esimerkiksi tutkittavia projekteja piti olla alun perin viisi, mutta niistä kahta ei voitu ottaa mukaan tietojen salaisuuden takia. Lisäksi tekstiä on jouduttu jonkin verran muotoilemaan ja joitakin asioita jättämään pois Luottokunnan toivomuksesta. Koska minulla työn kirjoittajana on työsuhde Accentureen, en välttämättä saanut kaikkea tietoa Luotto- 69 LUKU 8. YHTEENVETO JA POHDINTA 70 kunnan sisäisestä toiminnasta, esimerkiksi projektien kilpailutus muille toimittajille kuin Accenturelle ei ole julkista tietoa. Yrityssalaisuuksien kanssa auttoivat Accenturen kautta oleva salassapitovelvollisuus ja Luottokunnan kanssa erikseen tehty salassapitosopimus, jotka mahdollistivat pääsyn lähes kaikkeen tietoon. Haastattelutilanteissa yritin tuoda esiin roolini puolueettomana tutkijana, enemmän kuin Accenturen edustajana ja haastattelutilanteet olivat rentoja ja epämuodollisia. Haastattelujen aluksi myös kerroin, että tiedot ovat luottamuksellisia ja ennen julkaisua työ tullaan käymään läpi, jolloin haastateltavien ei tarvinnut kontrolloida omaa puhettaan. Tutkimuksesta pois jääneet kaksi projektia olivat samantyylisiä kuin kaksi tutkimukseen kuulunutta projektia, jolloin niissä oli päällekkäisyyttä jo tutkittujen projektien kanssa. Jo nyt tutkitulla kolmella projektilla oli havaittavissa samojen vastausten toistumista eri haastatteluissa ja kirjalliset aineistot vastasivat toisiaan, joten kaksi lisäprojektia olisi varmasti tuonut joitakin lisäyksiä, mutta tuskin muuttaneet työn johtopäätöksiä ja suosituksia. Tutkimuksen teoriapohjan kautta vaatimusten huomioiminen sai suuren painoarvon, joka näkyy muun muassa kirjallisen materiaalin analyysissa, jossa kiinnitetään erityisesti huomiota vaatimuksiin. Tämän takia työn edetessä haastatteluihin tuli isona yllätyksenä, että vaatimukset eivät olleetkaan projekteissa niin olennaisessa roolissa. Jos tämä olisi tiedetty jo aikaisemmin, työn teoriaa ja tutkimusta olisi voinut painottaa enemmän prosessiin ja muuhun hankinnan dokumentaatioon, kun nyt keskitytään paljon osa-alueeseen, joka osoittautui suhteellisen epäolennaiseksi hankintavaiheessa. Tämä tutkimus koski vain kolmea Luottokunnalle toteutettua IT-järjestelmäprojektia. Tästä tutkimuksesta saadaan kuvaa miten Luottokunnassa toteutetaan ITjärjestelmäprojekteja, joissa on käyttöliittymällinen osuus, yhteistyössä Accenturen kanssa. Tutkimus ei ole yleistettävissä, eikä sen tarvitse ollakaan, teknisiin taustajärjestelmäprojekteihin, koska näissä käytettävyyttä ei tarvitse huomioida. Tutkimus ei myöskään ole yleistettävissä toisten toimittajien kanssa tehtävään projektityöhön, koska solmittu yhteistyösopimus vaikuttaa vahvasti Luottokunnan ja Accenturen toimintaan. Tutkimusta ei voi myöskään suoraan yleistää muihin yksityisen sektorin yrityksiin ja niiden hankintaan, koska tapaustutkimus koski vain Luottokuntaa. Tutkimuksesta kuitenkin saa suuntaviivoja siihen, miten yksityisen ja julkisen puolen hankinta eroavat toisistaan ja on todennäköistä, että samoja piirteitä on löydettävissä myös muista suomalaisista yksityisyrityksistä, jotka ulkoistavat ITjärjestelmäprojektejaan ulkoiselle toimittajalle. Tutkimuksen suositukset on tehty ajatellen Luottokunnan erityispiirteitä, jolloin niitä ei voi suoraan sellaisenaan soveltaa toiseen tapaukseen, mutta niistä voidaan poimia kyseiseen tapaukseen sopivat toimenpiteet. LUKU 8. 8.3 YHTEENVETO JA POHDINTA Jatkotutkimuskysymyksiä Tämän tutkimuksen aikana on noussut esille monta mielenkiintoista kysymystä, joita ei tässä työssä pystytty käsittelemään. Näistä käytännön käytettävyystyön ja tutkimuksen suosituksien kannalta tärkein on käytettävyyden merkityksen selkeä ja helppo määrittäminen alkavalle IT-projektille. Alan tutkimuksessa käytettävyyden oletetaan olevan lähtökohtaisesti ehdottoman tärkeää lähes joka tilanteessa, eikä mittaria sen tärkeyden määrittämiselle tilanteesta riippuen löytynyt. Tosiasia kuitenkin on, että projekteilla on erilaisia päämääriä ja painopisteitä ja käytettävyyttä ei ole aina mahdollista täysimittaisesti huomioida. Millä kriteereillä käytettävyyden merkitys erilaisille projektille voitaisiin määrittää, jotta se osattaisiin huomioida edes niissä tapauksissa, kun se on kriittistä lopputuloksen kannalta? Olisiko mahdollista muodostaa selkeä mittari, jolla tämä voitaisiin analysoida? Käytettävyyden huomioinnista hankintavaiheessa on löydettävissä vain niukasti tutkimusta, vaikka hankintavaiheessa tehdään tulevan projektin isot päätökset esimerkiksi budjetista, resursseista ja aikataulusta, jotka vaikuttavat myös mahdollisuuksiin huomioida käytettävyyttä itse projektityössä. Lisäksi suurin osa tästä tutkimuksesta keskittyy julkisen sektorin toimijoihin. Tämän takia tarvittaisiin ehdottomasti lisää perustutkimusta yksityiseltä sektorilta, koska näiden kahden sektorin hankintamenettelyt eroavat selvästi toisistaan. Yksityisen sektorin tutkimuksen lisääntyessä voidaan syventyä myös erilaisiin tapauksiin. Tässä tutkimuksessa toimittajan ja hankkijan sopimusmalli oli joustava ja mahdollisti kevyen määrittelyn. Miten käytettävyyden huomiointi eroaa, jos sopimusmalli onkin tiukempi ja määrittelyä tehdään enemmän ennen hankintapäätöstä? Tämä tutkimus keskittyi myös vain yhteen hankkijaan ja yhteen toimittajaan, joten miten hankinnan määrittely ja mahdollinen käytettävyyden huomiointi tapahtuu, jos toimittajia onkin useampi ja toteutus on jollain tavalla jaettu heidän kesken? Voiko vastuu käytettävyydestä olla useammalla taholla vai häviääkö kokonaiskuva? Toinen näkökulma, joka jäi puuttumaan on valmistuotteiden hankinnan määrittely. Koska nämä tuotteet ovat jo olemassa, on niiden vaatimukset tehtävä tarkasti, jotta voidaan varmistaa tuotteen soveltuvuus haluttuun tehtävään. Miten valmistuotteen hankinnassa voidaan huomioida käytettävyysnäkökulma ja voidaanko siihen käyttää esimerkiksi testikäytöä? Tavoitteena tällaisella tutkimuksella on saada käytettävyys selkeämmin osaksi kokonaisprojektia ja huomioiduksi jo projektin hankintavaiheessa. 71 Lähdeluettelo [1] Accenture Oy: Luottokunta valitsi Accenturen kumppanik- http: //www.accenture.com/fi-en/company/newsroom-finland/Pages/ accenture-luottokunnan-kumppaniksi.aspx. seen sovellusten kehittämiseen ja ylläpitoon, 2009. http://www.accenture. com/fi-en/company/overview/description/Pages/index.aspx. [2] Accenture Oy: Company Description, 2011. http://www. accenture.com/fi-en/company/Pages/about-accenture-finland. aspx. [3] Accenture Oy: Facts about Accenture in Finland, 2011. [4] Artman, Henrik: Procurer Usability Requirements: Negotiations in Contract Development. Teoksessa NordiCHI'02, sivut 6170, 2002. [5] Benjamin, Robert I. ja Eliot Levinson: A Framework for Managing ITEnabled Change. Sloan Management Review, 34(4):2333, 1993. [6] Bias, Randolph G. Justifying Usability. ja Deborah J. Mayhew (toimittajat): Cost- Morgan Kaufmann Publishers, 2. painos, 2005, ISBN 0-12-095811-2. [7] Bosch, Jan: Design and Use of Software Architecture: Adopting and evolving a product-line approach. Pearson Education Limited, 2000, ISBN 0-201-67494-7. [8] Faulkner, Xristine: Usability Engineering (Grassroots). Palgrave, 2000, ISBN 0-333-77321-7. [9] Firesmith, Donald: Specifying Good Requirements. Journal of Object Technology, 2(4):7787, 2003. [10] Fisher, Lawrence: Industrial Marketing: an analytical approach to planning and execution. Business Books, 1969, ISBN 0-220-66292-4. 72 73 LÄHDELUETTELO [11] Folmer, Eelke, Jilles van Gurp ja Jan Bosch: A framework for capturing the relationship between usability and software architecture. Soft- ware Process: Improvement and Practice, 8(2):6787, huhtikuu 2003, ISSN 1077-4866. [12] Hirsjärvi, Sirkka ja Helena Hurme: Tutkimushaastattelu. Teemahaastattelun teoria ja käytäntö. Yliopistopaino, Helsinki, 2000. [13] ISO 9241-210:2010(E): Ergonomics of human-system interaction - Part 210: Human-centered design for interactive systems. ISO, Geneva, Swit- zerland, 2010. [14] Jokela, Timo: Determining Usability Requirements into a Call-forTenders . A Case Study on the Development of a Healthcare System. Teoksessa NordiCHI'10, sivut 256265, 2010. [15] Jokela, Timo: Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien hankinnoissa? Vaihtoehdot ja niiden haasteet. Teoksessa Häy- rinen, Kristiina (toimittaja): Sosiaali- ja terveydenhuollon tietojenkäsittelyn tutkimuspäivät. Tutkimuspaperit 2011, nide 13, sivut 1824, Helsin- ki, 2011. [16] Jokela, Timo: Terveydenhuollon tietojärjestelmät - sitä saa miten tilaa. FINNANEST, 44(3):219222, 2011. [17] Kangasniemi, Tuomas: Huono käytettävyys pilasi sähköisen äänestyksen, http://www.tekniikkatalous.fi/ict/huono+kaytettavyys+ pilasi+sahkoisen+aanestyksen/a151271. 2008. [18] Korhonen, Suvi: Selvitys: VR:n nettikauppa ongelmien pesä, 2011. http://www.talouselama.fi/uutiset/vr+sai+nettikaupastaan+ pyytamatta+selvityksen++173+ongelmakohtaa/a716484. [19] Kyriazoglou, John: IT Strategic and Operational Control. IT Governance Ltd, 2010, ISBN 978-1849280617. [20] Lauesen, Soren: Usability Requirements in a Tender Process. Teoksessa OZCHI'98, sivut 114121. IEEE Computer Society, 1998. [21] Lauesen, Sören: User Interface Design: A Software Engineering Perspective. Addison-Wesley, 2005, ISBN 9780321181435. 74 LÄHDELUETTELO [22] Lehtonen, Taina, Juha Kumpulainen, Tapani N. Liukkonen ja Timo Jokela: To what extent usability truly matters? A study on usability requirements in call-for-tenders of software systems issued by public authorities. Teoksessa NordiCHI'10, sivut 719722, 2010, ISBN 9781605589343. Business Eurocard yrityksille, 2010. http://www. luottokunta.fi/fi/kortit_ja_setelit/business_eurocard/ yrityksille. [23] Luottokunta: [24] Luottokunta: Luottokunnan Business Eurocard - Ajattelevan yrityksen http://www.luottokunta.fi/portal/page/portal/fi/ liitetiedostot/BEC_ESITE_VERKKOON_082010.pdf. kortti, 2010. http:// www.luottokunta.fi/fi/vastaanottopalvelut/raportointi/ luottokunta_verkkopalvelu. [25] Luottokunta: Luottokunta Verkkopalvelu, 2010. [26] Luottokunta: Vuosikertomus 2010 . 2010. [27] Martinsons, Maris G.: Outsourcing information systems: A strategic partnership with risks. Long Range Planning, 26(3):1825, kesäkuu 1993, ISSN 00246301. [28] Taylor-Powell, Ellen ja Marcus Renner: Analyzing Qualitative Data. University of Wisconsin-Extension, Cooperative Extension, Madison, 2003. [29] Van Weele, Arjan J.: Purchasing and Supply Chain Management: Analysis, Strategy, Planning and Practice. Cengage Learning, 2010, ISBN 978-1-4080-1896-5. [30] Vehviläinen, Juha: Procurement in project implementation. väitöskirja, Lappeenrannan Teknillinen Yliopisto, 2006. [31] Wiegers, Karl E.: Software Requirements. O'Reilly Media, Inc., 2. painos, 2009, ISBN 0-735-61879-8. [32] Wilson, Chayncey E.: Usability and user experience design: The next decade. Intercom, (January):69, 2005. Liite A Teemahaastattelujen rakenne Haastattelun aloitus: Pyydetään suullisesti lupa nauhoitukseen. Kerrotaan haastattelun luottamuksellisuudesta, tulokset käsitellään nimettöminä. Kerrotaan, että haastattelun saa lopettaa kesken, haastattelijan saa keskeyttää ja kysyä tarkennuksia. Kysytään haastateltavalta, saako vastauksista esittää tarvittaessa jatkokysymyksiä tai tarkennuksia myöhemmin, esimerkiksi sähköpostitse. Taustatiedot • Ikä • Työkokemus Kuinka kauan kyseisessä yrityksessä Kuinka kauan nykyisissä työtehtävissä • Haastateltavan rooli kyseisessä projektissa • Missä projektin vaiheissa ollut mukana • Mitä haastateltavasta tarkoittaa käsite käytettävyys? • Miten ajattelee, että Luottokunnassa huomioidaan käytettävyyttä? 1. Hankintaprosessi • Hankintapäätös • Hankinnan perustiedot 75 LIITE A. • TEEMAHAASTATTELUJEN RAKENNE Miten hankintaprosessi eteni aikataulullisesti / neuvottelullisesti? 2. Hankinnan määrittely ja vaatimukset • Miten hankinta oli määritelty ennen hankinnan neuvotteluprosessin alkua? • Mistä pisteestä Accenture tuli mukaan? • Mikä henkilön rooli oli tässä? • Millä määrittelyllä Luottokunta lähtee hankintaa tekemään? Mikä olisi tarkoituksenmukainen vaatimusten ja määrittely taso? • Millä määrittelyn tasolla Accenture menee mukaan projekteihin? Mikä olisi tarkoituksenmukainen vaatimusten ja määrittelyn taso? • Tarkennettiinko hankinnan määrittelyä hankinnan neuvotteluprosessin aikana? • Miten tarkkaan hankinta oli määritetty sopimuksen syntyessä? • Miten määrittely tarkentui hankintapäätöksen jälkeen? • Oliko hankinta määritelty vaatimuksina, vai luotiinko vaatimukset myöhemmin? • Mitä hyviä käytäntöjä on hankinnan määrittelyssä? Tässä tapauksessa? Yleisesti? • Mitkä asiat ovat ongelmallisia hankinnan määrittelyssä? Tässä tapauksessa? Yleisesti? 3. Käytettävyysnäkökulma • Näkyikö käytettävyys hankintakriteeristössä? Näkyikö tarjouspyynnössä tai tarjouksessa? Näkyikö tarjousdokumentaatiossa? Oliko alustavissa määrittelyissä mukana käyttäjäryhmien määrittelyä / use caseja / käyttöliittymäkuvia? 76 LIITE A. • TEEMAHAASTATTELUJEN RAKENNE Mikä oli käytettävyyden merkitys ja vaikutus projektissa? Mitkä käytettävyystoimenpiteet näkyvät tämän rakentamisessa? • Oliko käytettävyyttä huomioitu vaatimustasolla? Miten tämä konkreettisesti näkyi? • Miten tai millä työskentelytavoilla vaatimuksia tarkennettiin? Käytettiinkö Luottokunnan vai Accenturen menetelmiä? Kenellä oli vastuu vaatimuksista ja niiden edistämisestä? • Tulisiko haastateltavien mielestä käytettävyyttä huomioida hankintavaiheessa? Jos kyllä, niin miten? • Minkälaisia käyttäjäkeskeisen suunnittelun aktiviteetteja voisi tehdä jo tarjousvaiheessa? Käytettävyysvaatimukset, käyttäjäryhmien määrittely, käyttökonteksti, käyttötapaukset? • Onko jossain projektissa ollut hyviä käytettävyyteen liittyviä käytäntöjä? 77
© Copyright 2024