Tietojärjestelmän Hankinta: Hyötyjen Arviointi ja Vaatimusmäärittely

Tietojärjestelmäprojekteista vain alle puolet onnistuu. Tämän faktan innoittamana päätimme luoda oman oppaamme aiheesta.

Tietojärjestelmäprojektin neljä päävaihetta ovat:

1. tietojärjestelmäinvestoinnin hyötyjen arviointi
2. vaatimusmäärittely
3. vaihtoehtojen vertailu
4. hankinta ja käyttöönotto

Kerromme tässä blogitekstissä, miten toteutat tietojärjestelmäinvestoinnin hyötyjen arvioinnin sekä vaatimusmäärittelyn onnistuneesti. Hyvin toteutettuna ne luovat vankan pohjan onnistuneelle tietojärjestelmän hankinnalle.

Käsittelemme vaihtoehtojen vertailua sekä hankintaa ja käyttöönottoa seuraavassa artikkelissamme.

Tietojärjestelmäinvestoinnin hyötyjen arviointi

Mielessäsi olet jo varmasti onnistunut perustelemaan, miksi uusi tietojärjestelmä on hankittava. Olet myös ehkä myynyt idean muille.

Mutta oletko varma, että kaikki investoinnin hyödyt ovat varmasti tunnistettu ja arvioitu oikein?

Kokemuksemme mukaan tietojärjestelmähankkeissa tämä vaihe jää monesti usein kovin pintapuoliseksi.

Tässä muutama syy, miksi sinun kannattaa kiinnittää huomiota investoinnin hyötyjen arviointiin:

1. Ymmärrät, millaisia hyötyjä voit oikeasti saavuttaa ja miten ne syntyvät.
2. Osaat kohdistaa investointipanostukset oikeisiin järjestelmäominaisuuksiin. Hienon väriset napit eivät välttämättä tehosta järjestelmän käyttäjien toimintaa.
3. Sinulla on ylivertaiset perusteet investointipäätökselle. Et joudu jännittämään, meneekö investointiehdotuksesi läpi.
4. Vältät turhat investoinnit. On ikävää huomata vuoden projektin päätteeksi, että investoinnin hyödyt jäivät todellisuudessa kovin laihoiksi.

11 hyvää käytäntöä tietojärjestelmäinvestoinnin arviointiin

Susanna Lappi (2020) esittelee EP:llä tehdyssä diplomityössään työn tekemisen aikana tunnistettuja tietojärjestelmäinvestoinnin arvioinnin hyviä käytäntöjä. Ne auttavat sinua tekemään investoinnin hyötyjen arvioinnin paremmin. Seuraava lista on tiivistelmä Susannan diplomityön luvusta 6.1.

1. Selvitä, miksi tietojärjestelmäinvestointi ollaan tekemässä. Syy kertoo paljon siitä, mitä hyötyjä investoinnilla voidaan saavuttaa tai mistä liiketoimintaprosesseista ne löytyvät. Vaikka investoinnin syynä olisi pakko, on hyötyjen tunnistaminen aivan yhtä tärkeää.
2. Tunnista liiketoimintaprosessit, joihin investointi liittyy. Rajaa hyötyjen arviointi näihin prosesseihin.
3. Priorisoi hyödyt. Tällöin toimittajan ja järjestelmän valinta myöhemmässä vaiheessa on helpompaa.
4. Valmistele investointiehdotus huolella. Huolellisesti valmisteltu esiselvitys toimii uskottavana argumenttina taloudellisten perustelujen tukena.
5. Kirjaa kaikki havaitut hyödyt ylös. Ei haittaa, vaikka kaikkia niitä ei voisikaan arvioida taloudellisesti.
6. Rajaa hyödyt selkeästi. Hyödyiltä tulee löytyä syy-seuraussuhteet.
7. Huomioi prosesseissa tapahtuvat muutokset. Ei ole väliä, ovatko muutokset positiivisia tai negatiivisia.
8. Varmista päättäjien ymmärrys tietojärjestelmäinvestoinnista.
9. Pyri tekemään investoinnista taloudellinen arvio. Jos tämä ei onnistu, muodosta selkeä kokonaiskuva investoinnin hyödyistä, joiden avulla päätöksentekijä pystyy arvioimaan investoinnin arvoa vaistomaisesti.
10. Kaikkea ei tarvitse tehdä heti. Osa hyödyistä voidaan jättää saavutettavaksi jatkokehityksen yhteydessä.
11. Tee hyötyjen arviointia iteratiivisesti. Huomaat varmasti uusia hyötyjä investointiprojektin edetessä, joiden avulla voit täydentää ja tarkentaa alkuperäistä hyötyarviota.

Tietojärjestelmän vaatimusmäärittely

Vaatimusmäärittely on tietojärjestelmäprojektin seuraava vaihe, mikäli edellisessä vaiheessa tulit siihen lopputulokseen, että investoinnilla voidaan saavuttaa riittävästi hyötyjä.

Vielä tässäkään vaiheessa sinulla ei ole syytä lähteä tutustumaan tarjolla oleviin tietojärjestelmiin. Ennen sitä, sinun on järkevää määrittää, mitä tarpeita yritykselläsi on tietojärjestelmälle.

Karkeasti ottaen vaatimusmäärittelyssä kuvataan yrityksen vaatimukset ja tarpeet selkeästi ja ymmärrettävästi.

Vaatimusten osalta sinun on hyvä huomioida niiden kytkeytyminen johonkin edellä tunnistettuun hyötyyn. Jos vaatimus ei edistä minkään hyödyn toteutumista, sitä ei välttämättä kannata vaatia.

Millaisia ovat hyvät vaatimukset?

Hyvät vaatimukset vaatimusmäärittelyssä ovat yksiselitteisiä, ytimekkäitä, määrällisiä, mitattavia, toteuttamiskelpoisia, testattavia sekä jäljitettäviä. Alla on vielä lista siitä, mitä näillä ominaisuuksilla tarkoitetaan.

Vaatimusmäärittelyn dokumentit: miten vaatimukset esitetään?

Ensimmäisenä monille varmasti tulee vaatimusmäärittelystä mieleen pitkä dokumentti, jossa vaatimukset ovat luokiteltuna ja numeroituna.

Ennen tällaisen dokumentin laatimista kannattaa kuitenkin keskittyä käyttäjäryhmien tunnistamiseen.

Tämä voidaan toteuttaa esimerkiksi käyttäjäryhmien kuvauksena eli miettimällä, ketkä ja mitkä tulevat käyttämään uutta tietojärjestelmää. Käyttäjiä voidaan ryhmitellä esimerkiksi käyttötapojen tai käyttöoikeuksien mukaan.

Yllä mainittu yksityiskohtainen vaatimusmäärittelydokumentti on yksi parhaista tavoista esittää vaatimuksia. Jos käytät tällaista dokumentaatiota, varmista, että vaatimukset ovat täsmällisiä ja helposti ymmärrettävissä. Anna kullekin vaatimukselle tarkka nimi ja numeroi se erikseen.

Hieman luovempi tapa esittää vaatimuksia ovat käyttötarinat.

Käyttötarinat kuvaavat, miten käyttäjä suoriutuu tyypillisestä tehtävästään uudessa järjestelmässään. Jos käytät käyttötarinoita, muista aina nimetä henkilöt, kuvaa ainoastaan onnistunutta järjestelmän käyttöä sekä huomioi kaikki käyttäjäryhmät.

Käyttötarinat ovat hyviä, koska ihmiset ovat taitavia perustelemaan tarinoita ja havaitsemaan niistä epäjohdonmukaisuuksia sekä puutteita ja riskejä.

Me käytimme oman PSA-järjestelmän hankinnassamme muun muassa käyttäjätarinoita. Alla esimerkki resursoinnin käyttäjätarinasta. Ensin tarina järjestelmän käytöstä, sitten nimetyt henkilöt ja viimeisessä sarakkeessa prioriteetti.

Edellä esitetyt mallit ovat vain pieni osa mahdollisista vaatimusmäärittelyn dokumenteista. Sinun kannattaa tutustua myös esimerkiksi prosessikuvauksiin ja -kaavioihin.

Vaatimusmäärittelyn vaiheet

Vaatimusmäärittelyn läpiviemiseksi on lukuisia erilaisia prosessimalleja. Esitämme tässä sinulle yhden suosikeistamme, joka on rakenteeltaan selkeä ja huomioi kaiken oleellisen.

Vaikka kuvassa vaatimusmäärittely on esitetty lineaarisena prosessina, se on usein hyvin iteratiivinen. Esimerkiksi uusia vaatimuksia tulee varmasti projektin edetessä, jolloin ne voidaan ihan hyvin sisällyttää mukaan vaatimusmäärittelyyn, vaikkei virallisesti ollakaan enää vaatimusten kerääminen -vaiheessa.

1. Vaatimusten kerääminen

Tässä vaiheessa sinun on oleellista tunnistaa kaikki järjestelmän sidosryhmät.

Näin toimimalla voit varmistua siitä, että kaikki näkökulmat tulevat huomioitua heti alusta alkaen. Sidosryhmät voivat olla esimerkiksi järjestelmän käyttäjiä, kehittäjiä tai päätöksentekijöitä.

Sidosryhmien tunnistamisen jälkeen voit aloittaa itse vaatimusten keräämisen heiltä. Vaatimusten keräämiseen voit käyttää lukuisia eri menetelmiä kuten kyselyitä, työpajoja tai ryhmätöitä. Me olemme kuitenkin kokeneet haastattelut monessa tapauksessa parhaaksi menetelmäksi.

Älä kiinnitä tässä vaiheessa liikaa huomiota vaatimusten laatuun ja muotoiluun. Tässä vaiheessa on oleellista saada kaikki mahdolliset vaatimukset vain talteen.

2. Vaatimusten analysointi

Vaatimusten analysoinnin tavoitteena on tunnistaa ja ratkaista ristiriitaiset vaatimukset, tunnistaa järjestelmän rajat ja sen käyttäytyminen muiden järjestelmien kanssa.

Kiinnitä tässä vaiheessa myös huomiota vaatimusten toteutettavuuteen sekä mahdollisiin aukkoihin, joita vaatimusten keräämisestä on jäänyt.

Ristiriitaisten vaatimusten selvittäminen ei ole aina kovin helppoa. Niiden selvittämiseksi kannattaa kokeilla ainakin trade-off-analyysia sekä vaatimusten priorisointia. Ristiriitaisten vaatimusten kohdalla kannattaa muistaa kommunikoida kaikkien kanssa, jotka liittyvät kyseisiin vaatimuksiin.

3. Vaatimusten dokumentointi

Kun olet onnistuneesti kerännyt ja analysoinut vaatimukset, voit dokumentoida aikaansaannoksesi. Tätä dokumenttia kutsutaan vaatimusmäärittelydokumentiksi. Tämä sanahirviö sisältää kuvauksen koko järjestelmän ulkoisesta käyttäytymisestä.

Hyvän vaatimusmäärittelyn piirteet:

• Täydellisyys. Kaiken ei tarvitse olla täydellistä, mutta vaatimusmäärittelydokumentin tulee sisältää kaikki oleellinen tieto vaatimuksista.
• Johdonmukaisuus. Varmista, että dokumentissa ei ole ristiriitaisia vaatimuksia. Käytä myös johdonmukaista kieltä, jossa kullakin sanalla on vain yksi merkitys. Ole siis tarkkana esimerkiksi ammattisanaston ja käännösten kanssa.
• Muokattavuus. Huolehdi, että dokumentti on muokattavissa jälkikäteen. Muokkausta helpottaa muun muassa se, että kukin vaatimus on vain yhdessä paikassa.

Olemme huomanneet, että pienemmissä projekteissa yksittäinen dokumentti saattaa riittää, mutta järjestelmän koon kasvaessa ja monimutkaisuuden lisääntyessä, dokumentteja kannattaa luoda useampia.

Voit jaotella vaatimukset esimerkiksi käyttäjien, käyttöliittymän sekä liiketoiminnan vaatimuksiin.

4. Vaatimusten validointi

Vaatimusten validoinnin aikana sinun tulee varmistaa kaikilta vaatimusmäärittelyyn osallistuneilta sidosryhmiltä, että vaatimusmäärittelydokumentti sisältää oikeat vaatimukset ja että ne ovat asetettu oikein. Tässäkin haastattelu on havaittu hyväksi keinoksi.

5. Vaatimusten hallinta

Voit ajatella vaatimusten hallintaa prosessina, jossa varmistetaan, että vaatimusmäärittelydokumentit vastaavat rakennettavaa ja rakennettua järjestelmää. Hallinta ei lopu siis seinään tietojärjestelmäprojektin alussa, vaan se kattaa koko sen elinkaaren.

Vaatimusten hallinnassa voit törmätä esimerkiksi pyydettyjen muutosten analysointiin ja niiden hylkäämiseen tai hyväksymiseen. Tutkimukset ja kokemus ovat osoittaneet, että parhaiten onnistuneissa tietojärjestelmäprojekteissa ymmärrettiin, että vaatimukset saattavat muuttua ja kehittyä projektin edetessä.

Eli älä vain lukkiudu alkuperäiseen määrittelyyn, mikäli haluat kasvattaa onnistumisen todennäköisyyttä.

Yhteenveto

Nyt olemme käyneet läpi kaksi ensimmäistä vaihetta tietojärjestelmän hankinnasta. Toivottavasti sait tekstistä jotain uusia ajatuksia tekemiseesi!

Seuraavassa blogitekstissä käsittelemme tietojärjestelmäprojektin loput vaiheet eli vaihtoehtojen vertailun sekä tietojärjestelmän hankinnan ja käyttöönoton.

Sinua voisi kiinnostaa myös