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

Transcription

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
. . . . . . . . . . . . . . . . . .
.
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 vaatimusja 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
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ä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 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.
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.
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.
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.
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
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.
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.
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.
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.
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
ja projektin yleiskuvaus
lydokumentaation
Hankinnan muun määritte-
lydokumentaation
portti
loppura-
Määrittelyn
katselmoinnin
tettavasta webpalvelusta
analyysi
lydokumentaation
vaatimuslistauksen liite, kuvaus toteu-
tason
korkean
edeltäneen
analyysi
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 vaatimusja määrittelydokumentaatio
LUKU 4.
23
Hankinnan
Hankintaa edeltänyt
Määrittelyn tehtäväluettelo
Liiketoimintavaatimusten
Projektin loppuesitys
suunnitelma
Päivitetty kokonaisprojekti-
suunnitelma
lydokumentaation analyysi
sikuvaus
projekti-
Hankintaa edeltänyt proses-
määrittämisen
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 vaatimusja määrittelydokumentaatio
LUKU 4.
24
Hankinnan muun määrittelydokumentaation analyysi
Hankintaa edeltänyt tarjousluon-
nos Luottokunnan asiakkaalle 1.
nos Luottokunnan asiakkaalle 2.
määrittelyvaiheesta
Esisuunnittelun
allekirjoitettavaksi
sopimusluonnos
ja
Tarjousluonnos esisuunnittelusta
Accenturen mukaantulosta
Sopimus
Accenturen mukaantulosta
tään määrittelyn aloituksesta ja
Kokousmuistio,
pääte-
liite Luottokunnan asiakkaalle
jossa
Hankintaa edeltäneen tarjouksen
osa
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 vaatimusja määrittelydokumentaatio
Dokumentin kuvaus
LUKU 4.
25
LUKU 4.
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.
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öä.
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 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 vaatimusja 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 vaatimusja 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.
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
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 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 vaatimusja 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 vaatimusja 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 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.
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 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.
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 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
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.
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.
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.
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,
hankintaja 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
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.
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.
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.
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.
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
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
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.
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.
Kun käytettävyyden huomiointi yhdistetään yksiselitteiseen käyttöliittymäohjeistukseen, voidaan käytettävyys viedä myös vaatimusja 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.
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.
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
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

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

Transcription

Similar documents

USEIN KYSYTTYJÄ KYSYMYKSIÄ YLEISTÄ: K: ”Mitä rajapintaa

automaatio käytettäVyyden tehoStaJana

Strategia on tekemistä, ei sanoja.

KÄYTETTÄVYYS

Palvelua tuottavuutesi lisäämiseksi

Kaikki liiketoiminta on digitaalista – mutta mitä sen

Nets Oy Maksupäätepalvelusopimus, kassapisteet

Harmaa Talous 2/2007 - Tietojohtajakilta Man@ger

Lataa tästä FireFit Cloud