Palvelumuotoilunmetodeilla rikastettu prosessimalli

Kuva 18 Esimerkki BI-raportin low-fi prototyypistä sekä sen eri elementeistä (mukail-len Yuk ja Diamond, 2014)

High-fi prototyyppejä, jotka voivat sisältää funktionaalisia ominaisuuksia viimeistellyn ulkoasun lisäksi, voidaan lähteä työstämään low-fi prototyyppien pohjalta, kun yksimie-lisyyteen BI-raportoinnin rakenteesta ja sisällöstä on päästy. Kun lähdetään tarkemmin suunnittelemaan, minkälaisia visualisointitapoja raportoinnissa hyödynnetään, on muis-tettava, että visualisointeja tehdään datan vuoksi, sen sijaan että data sovitettaisiin tiettyyn visualisointimalliin. BI-raportointia suunniteltaessa tulee siis muistaa, että data tulee näyttää muodossa, joka on katsojalle selkein ymmärtää – ei tavoitella jotain tiettyä visu-alisointityyppiä, koska se näyttää hienolta. Datan visualisoinnin tarkoitus on ennen kaik-kea toimittaa informaatio katsojalle sellaisessa muodossa, josta katsojan on kaikista hel-pointa poimia tarvittava tietämys. Tämän takia kaikista tehokkaimmat visualisoinnit ovat-kin usein yksinkertaisia. (Yuk ja Diamond, 2014)

Taulukko 21 Yhteenveto BI-järjestelmän käyttäjävaatimusprosessissa hyödynnettä-vistä metodeista

Prosessin vaihe Metodi Tarve Kuvaus hyödyntämisen syistä

Esiselvitys

Puoliavoin haastattelu Käytetään aina Selvitetään liiketoimintatavoitteet, rapor-tointitarpeet, järjestelmän luonne ja kehi-tysympäristö

5*Miksi Tarvittaessa Käytetään haastattelutekniikkana tarvitta-essa

Aivoriihi Tarvittaessa Ongelmakontekstin ratkaisu epäselvä, vaaditaan ideoiden generoimista

Käyttökontekstin ja

käyttäjätarpei-den määritys

Puoliavoin haastattelu Käytetään aina Selvitetään mm. sidosryhmät ja niiden ominaisuudet, käyttäjätarpeet, KPI:t ja jär-jestelmän ympäristö

5*Miksi Tarvittaessa Käytetään haastattelutekniikkana tarvitta-essa

Tutustuminen olemassa olevaan ratkaisuun

Tarvittaessa

Tutustuminen olemassa olevaan ratkai-suun ja sen dokumentointiin, havainnointi, kontekstuaalinen haastattelu samalla kuin käyttäjä käyttää järjestelmää

Sidosryhmäkartta

ja persoonat Tarvittaessa

Mikäli BI-järjestelmän sidosryhmiä on useita, voi sidosryhmäkartan tekeminen helpottaa niiden määritystä ja organisoin-tia. Persoonat voidaan luoda määritettyjen sidosryhmien pohjalta tekemään sidosryh-mien edustajista samaistuttavampia, ja edistämään ihmislähtöistä suunnittelua

Käyttäjätarinat, skenaariot, asiakkaan polku

Tarvittaessa

Käyttäjätarinoiden ja skenaarioiden inhi-millistävät järjestelmän käyttöä, jotta ke-hittäjät pystyvät samaistumaan ja ymmär-tämään paremmin käyttäjien tarpeita. Asi-akkaan polku -kartta tarjoaa yleiskuvauk-sen käyttäjä-järjestelmä interaktiosta ja järjestelmän käyttäjäkokemukseen vaikut-tavista tekijöistä käyttäjän näkökulmasta.

Voidaan tunnistaa interaktion ongelma-kohtia ja ymmärtämään paremmin käyttä-jän toimintaa järjestelmän kanssa.

Korttien lajittelu Tarvittaessa

Mikäli BI-raportoinnin informaatioarkki-tehtuuri on epäselvä, voidaan korttien la-jittelua hyödyntää luomaan rakenne, joka on käyttäjälle intuitiivinen

Käyttäjävaati-musten määritys

Puoliavoin haastattelu Tarvittaessa -

Vaatimusneuvottelu-tekniikat Tarvittaessa

Mikäli vaatimukset ovat ristiriidassa kes-kenään, tai ominaisuuksien prioriteeteista on eri mielisyyttä, voidaan vaatimusneu-vottelutekniikan ajatusmalleja hyödyntää

Prototyypit ja dokumentointi

Low-fi prototyypit Käytetään aina Prototyyppejä kehitetään iteratiivisesti yhdessä sidosryhmien edustajien kanssa High-fi prototyypit Tarvittaessa Toteutetaan mikäli lopullista visuaalista ulkoasua, toiminnallisuutta ja muita yksi-tyiskohtia halutaan evaluoida

Korttien lajittelu Tarvittaessa

Mikäli BI-raportoinnin informaatioarkki-tehtuuri on epäselvä, voidaan korttien la-jittelua hyödyntää luomaan rakenne, joka on käyttäjälle intuitiivinen

Kun taulukon 21 metodit yhdistetään kappaleessa 3 tuloksiin ja esitettyyn BI-järjestelmän vaatimusmäärittelyprosessin primäärimalliin, voidaan prosessimallia rikastaa tavoitteilla, prosessiin mukaan otettavilla henkilöillä, tukidokumentaatiolla, toteutettavalla dokumen-taatiolla ja metodeilla. Metodien käyttökohteet on kerätty edelliseen taulukkoon 21. Esi-selvitysvaiheen tavoite on selventää BI-järjestelmän liiketoimintatavoitteet, ja ongelmat, joita järjestelmällä pyritään ratkaisemaan. Lisäksi tarkennetaan projektin yleisluonne.

Seuraavan vaiheen tavoite on selvittää järjestelmän sidosryhmät, käyttäjätarpeet, käyttö-konteksti sekä kerätä kaikki tarvittavat KPI:t. Käyttäjävaatimusten määrityksessä käyttä-jätarpeiden pohjalta johdetaan käyttäjävaatimukset, organisoidaan ja priorisoidaan ne sekä varmistetaan että vaatimukset eivät ole ristiriidassa keskenään. Lisäksi KPI:t priori-soidaan. Viimeisen vaiheen tavoitteena on low-fi prototyyppien tekeminen. Lopuksi do-kumentaatio kerätään yhteen ja viimeistellään ja hyväksytään relevanttien osapuolten ja sidosryhmien kesken. Dokumentaatio muodostaa sopimuksen eri osapuolten välille jär-jestelmän ominaisuuksista. Liitteessä 1 on esitetty rikastettu käyttäjävaatimusmäärittelyn preliminäärimalli

Esiselvitys vaiheessa tulee mukana olla BI-hankkeen sponsori, sekä järjestelmää kosket-tavien liiketoiminta-alueiden eri sidosryhmien edustajat. On tärkeää, että hankkeella on johdon tuki, jotta liiketoimintatavoitteet pystytään määrittämään luotettavasti ja oikein (Yuk ja Diamond, 2014). Käyttökontekstin ja käyttäjätarpeiden määrityksessä tulee olla mukana eri käyttäjäsidosryhmien edustajat, jotta voidaan tunnistaa kaikkien sidosryh-mien tarpeet ja KPI:t. Mikäli sidosryhmillä on poikkeavat tarpeet järjestelmältä, on to-dennäköisesti syytä kerätä kaikkien ryhmien tarpeet omissa työpajoissa, jotta tarpeet saa-daan luotettavasti kerättyä, eikä synny intressien välistä konfliktia, jonka seurauksena osa käyttäjätarpeista jäisi ilmaisematta. Tässä prosessin vaiheessa halutaan kerätä kaikki mahdollinen tieto, ja vasta käyttäjävaatimusten määritys vaiheessa puututaan mahdolli-siin konflikteihin ja priorisoidaan vaatimukset. Käyttäjävaatimusten määritys vaiheessa on mukana samat henkilöt kuin edellisessä vaiheessa. Prototyyppien iteroinnissa tulee olla myös samat henkilöt, ja lopullisen dokumentaation hyväksyvät relevanttien sidos-ryhmien edustajat, jotka katsotaan projektin kontekstissa tarpeellisiksi.

Prosessissa voidaan katsoa olevan kahden tyyppistä dokumentaatiota: tukidokumentaa-tio, joka ohjastaa ja edesauttaa prosessin etenemistä, sekä toteutettava dokumentaatukidokumentaa-tio, jo-hon kootaan prosessin vaiheiden tulokset. Tukidokumentaatio voi monissa tapauksissa kehittyä toteutettavaksi dokumentaatioksi, kun se prosessin edetessä täydennetään. Kuva 21 havainnollistaa toteutettavan dokumentaation kehittymistä läpi projektin. Esiselvitys-vaiheessa on tukidokumentaationa kysymyspohja, johon puoliavoimen haastattelun

peri-aatteiden mukaan haetaan vastaukset. Vastausten pohjalta syntyy projektin visio -doku-mentti. Käyttökontekstin ja käyttäjätarpeiden määritysvaiheessa tukidokumentaationa on KPI-määrityspohja, johon tässä tutkimuksessa sovelletaan Yukin ja Diamondin (2014, s.

90) esittämää KPI:den määrityspohjaa. Tämän lisäksi tukidokumentaationa toimii sidos-ryhmien ja käyttäjätarpeiden määrityspohjat, joiden avulla pyritään varmistamaan, että kaikista käyttäjätarpeista ja sidosryhmistä dokumentoidaan tarvittavat asiat. Lisäksi mu-kana on tarkastuslista, joka ohjaa esimerkiksi metodien valintaa tarvittaessa. Tuloksena tästä vaiheesta syntyy käyttökontekstin ja käyttäjätarpeiden määritysdokumentti, sekä täytetty KPI-lista. Kolmannessa vaiheessa on tukena tarkastuslista, joka ohjaa käyttäjä-vaatimusten organisointia, priorisointia ja ristiriitojen ratkaisemista. Käyttäjävaatimukset voidaan yhdistää samaan pohjaan, johon edellisessä vaiheessa kerättiin käyttäjätarpeet.

Tuloksena syntyy käyttäjävaatimusdokumentti, lisäksi edellisessä vaiheessa koottu KPI-lista priorisoidaan. Prototyyppien tekemistä tukee low-fi prototyyppien mallipohja. Pro-sessin viimeistelyssä on lisäksi mukana tarkastuslista, jonka avulla tarkistetaan, että pro-jekti viimeistellään onnistuneesti loppuun. Edellisissä vaiheissa koottu dokumentaatio muodostaa osin järjestelmävaatimus- ja käyttäjävaatimusdokumentaation kuvan 21 mu-kaisesti. Lopuksi relevantit sidosryhmät hyväksyvät nämä kaksi dokumenttia, ja näistä muodostuu sopimus osapuolten välille.

Kuva 19 Projektidokumenttien kehittyminen

Oleellista BI-järjestelmän vaatimusmäärittelyprojektin preliminäärimallissa on muistaa, että vaikka malli esitetään luettavuuden vuoksi vesiputousmaisesti etenevänä mallina, on todennäköistä ja jopa suotavaa, että prosessin vaiheita kannattaa suorittaa lomittain. Esi-merkiksi käyttäjävaatimuksia voidaan johtaa käyttäjätarpeista saman aikaisesti käyttäjä-tarpeiden määrityksen kanssa. Lisäksi prototyyppien valmistelu kahden edeltävän vai-heen kanssa saman aikaisesti tukee prosessin onnistumista kokonaisuudessaan, sillä

pro-totyyppien teko tukee keskustelua ja voi herättää uusia käyttäjätarpeita. Toisaalta on tär-keää, että esiselvitysvaiheeseen kuuluva liiketoimintatavoitteiden selvittäminen tehdään ennen kuin lähdetään keräämään käyttäjätarpeita, jotta fokus osataan keskittää oikein.

Seuraavassa kappaleessa esitellään empiirisen tutkimuksen toteutus, jossa kehitetty BI-järjestelmän käyttäjävaatimusmäärittelyn preliminäärimalli esitellään BI-alan asiantunti-joille kehityskohtien löytämiseksi.