Tietojärjestelmän uudistaminen tai järjestelmäkokonaisuuden täydentäminen: Millainen dokumentaatio on riittävä tarjouspyyntöä varten? Riittääkö, että laatii joukon kuvauksia tulevan järjestelmän piirteistä? Voiko vaatimusmäärittely syntyä vanhan järjestelmän määrityksistä lisäämällä niihin uudet piirteet?
Seuraavassa kokenut konsulttimme Jaakko Wegelius käy läpi onnistuvan määrittelyprojektin ainekset ja nimeää sudenkuopat ja niiden seuraukset. Rahanarvoista asiaa – tätä ei kannata jättää lukematta!
Onnistumisen edellytykset
Vaatimusmäärittely tehdään hankintaa varten. Tätä ei pidä sekoittaa järjestelmän toteutusvaiheessa tuotettaviin määrittely- ja suunnittelun kuvauksiin, jotka laaditaan järjestelmän rakentamista varten, nekin toki perustuvat vaatimusmäärittelyyn ja täsmentävät niitä.
Hankinnan taustalla on jokin toiminnan tarve, jonka ratkaisemiseen tarvitaan tietojärjestelmäuudistusta. Onnistuneessa hankinnassa oleellista onkin kuvata, mitä toiminta tarvitsee ja minkä osan hankittava tietojärjestelmä siitä toteuttaa.
Toiminnan tarve voidaan kuvata kolmen periaatteen mukaisesti:
- käyttäjälähtöisesti niin, että kaikki oleelliset käyttötilanteet (käyttötapaukset) tulevat ilmi
- systemaattisesti siten, että kaikki potentiaaliset toimittajat ymmärtävät “pihvin” oikein
- kattavasti niin, että kuvaus kattaa toimintaprosessin tarvittavat toiminnot.
Tällöin toimittajat osaavat tarjota omien lähtökohtiensa perusteella parasta ratkaisua ja tarjousten vertailu on helppoa ja tasapuolista.
Onnistuneessa tilanteessa toimitus vaiheistetaan niin, että pilotointi ja käyttö voidaan tehdä vaiheittain. Tällöin kokemuksia ja hyötyä saadaan heti alusta alkaen. Tämä edellyttää, että toiminnan kannalta mielekkäät ja tärkeimmät kokonaisuudet on tunnistettu vaatimusmäärittelyn yhteydessä.
Alun laiminlyönnit maksetaan karvaasti
Hyvin suunniteltu on puoliksi tehty – pätee valitettavasti myös käänteisesti eli hankaliksi osoittautuneiden tietojärjestelmähankkeiden taustalla on usein alkuvaiheiden ongelmat
Ikävän kierteen kaava: Tilaaja on kuvannut tarjouspyynnössään joitakin yksityiskohtia (järjestelmän piirteitä) > toimittaja tarjoaa niihin toteutustyön > kuvatut yksityiskohdat (=laskutusperusteet) toteutuvat, mutta järjestelmän toiminnot eivät tue toimintaprosesseja ja niiden työvaiheita kunnolla > projekti ajautuu jatkuviin muutospyyntöihin (=lisälaskutus) > järjestelmän käyttöönotto siirtyy jatkuvasti eteenpäin > lopulta otetaan jokin karsittu versio käyttöön ja käyttäjät täydentävät toimintoja omilla excel-taulukoilla, paperitulosteilla, muistiinpanoilla ja sähköpostilla välitetyillä tiedoilla.
Vaaran merkit, tunnista ja eliminoi!
Seuraavat piirteet johtavat usein epätyydyttävään tai jopa toimimattomaan ratkaisuun:
- On kuvattu erilaisia piirteitä, joita järjestelmän tulisi toteuttaa.
- Ei kuvata käyttäjien tarpeita, vaan osajoukko jostakin ratkaisusta perustuen oletettuun toteutustapaan.
- Kuvaukset eivät ole systemaattisia ja kuvaustapa vaihtelee.
- Osa kuvauksista liittyy vanhan järjestelmän toimintoihin ja määrityksiin.
- Esim. näyttökuvia, vanhan järjestelmän kerrosarkkitehtuuripiirros, nykyisen tietokannan tietomalli tai yksittäisten toimintojen toteutustasoisia määrityksiä (jopa ohjelmiston lähdekoodia).
- Kuvitellaan, että mitä yksityiskohtaisempia määrityksiä, sen parempi.
- Exceliin on laadittu vaatimusluettelo, johon tilaajan eri henkilöt ovat listanneet lyhyesti toivomuksiaan uusina haluttuina piirteinä.
- Luettelon rivit on kuvattu yhteen excelin soluun eikä ole kokoavaa kuvausta, josta ilmenisi toiminnallinen kokonaisuus, johon vaatimus liittyy (esim. käyttötilanne).
- Jälkikäteen ei tiedetä, mistä kukin vaatimus on lähtöisin. Jos järjestelmän rajaus muuttuu, niin ei pystytä nimeämään, mitkä vaatimukset ovat sen jälkeen relevantteja.
- Kaikki vaatimukset on merkitty pakollisiksi.
- Jos vaatimusluettelo on vaikeasti tulkittava, on yksinkertaisinta (ja nopeinta) merkitä kaikki pakolliseksi.
- Kuvausten ja vaatimusten kattavuudesta ei voida olla varmoja.
- Jos toimintaprosesseja ja käyttötapauksia ei ole käyty systemaattisesti läpi, niin kuvaukset ja vaatimukset perustuvat siihen mikä on tullut mieleen.
- Järjestelmän rajausta ei ole kuvattu täsmällisesti. Mikä on kyseisen järjestelmän vastuulla ja miten se liittyy muihin järjestelmiin?
- Tilaajan eri käyttäjäryhmät mieltävät eri tavoin sen, mitä ajatellaan kuuluvan järjestelmään.
- Kuvauksissa on otettu jotenkin kaikkien toiveet huomioon, mutta käsitykset lopputuloksesta poikkeavat: joku ajattelee sen rekisterinä, toinen laskentajärjestelmänä, kolmas asiointijärjestelmänä ja neljäs asianhallintajärjestelmänä.
- Väärät mielikuvat ketterästä kehittämisestä.
- Eihän niitä kuvauksia tarvita, vaan asiat ratkaistaan ketterän toteutusvaiheen aikana!
Ja kuinkas sitten käykään:
- Toiminnan tarvitsema kokonaisuus ja muutos nykyiseen ei tule selvästi esille.
- Oleellisia vaatimuksia jää puuttumaan.
- Vanhan järjestelmän piirteet tulevat mukaan, vaikka osasta voisi luopua.
- Vanhan järjestelmän jokin piirre johtuu sen toteutustekniikasta ja tämä (vanhentunut) toteutustapa kopioituu vaatimukseksi uuteen järjestelmään.
- Ei erotu, mikä on tärkeää (ratkaistava ongelma) ja mikä ehdotus (toteutustavan toive).
- Vain vanhan järjestelmän toimittaja ymmärtää tarjouspyynnön kohteen > tilaaja on toimittajan armoilla.
- Toimittaja joutuu tekemään väkinäisiä tulkintoja, jopa arvauksia.
- Vaatimusmäärittelyn avoimet asiat siirretään toimitusprojektin vastuulle.
- Tulevan toteutuksen laajuudesta joudutaan sopimaan uudelleen toteutusprojektin yhteydessä.
Sinä päätät isosta kuvasta
Älä kuvaa yksityiskohtia, vaan keskity kokonaiskuvaan.
Tarvitaan kokoava jäsennys siitä, mitä toimintaa tietojärjestelmän tulisi tukea ja minkä osan siitä hankittava tietojärjestelmä toteuttaa. Oleelliset käyttötilanteet tulee esittää systemaattisesti esim. käyttötapauksina, ei järjestelmän piirteinä.
Vaatimusluettelo on hyvä olla olemassa. Vaatimuksista tulee kuitenkin vain osan olla pakollisia ja jokaisesta vaatimuksesta tulisi tietää, mistä ne ovat peräisin. Vaatimusten kattavuus ja mahdolliset ristiriitaisuudet on tarkistettava. Toteutuksesta on syytä kuvata MVP (Minimum Viable Product) eli pienin toimiva tuote, jota voidaan käyttää toimintaprosessien tukena.
Vaikka tietojärjestelmä toteutettaisiin ketterillä menetelmillä, vaatimukset pitää kuitenkin kuvata. Hankinnan kohde on kuvattava, jotta tilaajan eri käyttäjäryhmät ovat yksimielisiä hankinnasta ja toimittajat osaavat tarjota hyviä ratkaisuja. Jos asioita jätetään paljon auki ketterään toteutusprojektiin, niin silloin tilaajan edustajan on varattava aikaa kysymysten ratkaisuun toteutusprojektin aikana. Kaikkiin avoimiin asioihin pitää ottaa kantaa ja tilaajan edustajan on osattava kertoa kaikkien tilaajan käyttäjäryhmien tarpeet nopeastikin. Tilanne voi eskaloitua ikävästi kaikkien osapuolten kannalta ja lopullinen valmistuminen viivästyä, sillä useimmiten tilaajan edustaja osallistuu toteutusprojektiin vain muiden töidensä ohessa. Etukäteen systemaattisesti kuvatuilla vaatimuksilla helpotetaan toteutusprojektia, jossa voidaan keskittyä tarkemman toteutuksen määrittelyyn ja suunnitteluun.
Siedettävä keveys
Eikö sitten aiempia kuvauksia ja koottuja toivelistoja voida käyttää lainkaan hyväksi? Onko tehtävä aina hyvin laaja ja puolen vuoden mittainen vaatimusmäärittely?
Ensinnäkin: vaatimusmäärittely oikein tehtynä ei vie puolta vuotta vaan on tehtävissä nopeastikin. Keskeistä on käyttäjälähtöisyys ja systemaattisuus. Liiketoiminnan edustajat kuvaavat tarpeet ja kokenut vaatimusmäärittelijä koostaa riittävän kuvauksen, jolla päästään hankinnan valmisteluun. IT-asiantuntija ei voi kuvata toiminnan tarpeita yksinään ja toiminnan edustajat eivät ole rutinoituneita vaatimusmäärittelyssä. Siksi vaatimusmäärittely kannattaa tehdä vuorovaikutteisesti yhdessä.
Aiempia kuvauksia ja toivelistoja voidaan käyttää työn tukena ja ne toimivat apumateriaaleina. Kattavuuden varmistamiseksi, tietojärjestelmän vastuun rajaamiseksi ja mahdollisten ristiriitojen selvittämiseksi tulee kokonaisuus kuitenkin käydä systemaattisesti läpi.
Summa summarum: Aikaa ja työtä säästyy, jos ei tehdä alustavaa piirteiden tai toiveiden keräämistä, vaan aloitetaan käyttäjälähtöisellä vaatimusmäärittelyllä ja tämän työn ohessa tunnistetaan mahdolliset käyttökelpoiset aiemmat kuvaukset ja määritykset. Aiemmissa yhteyksissä kootut listaukset, vaatimukset tms. hyödynnetään työn taustamateriaaleina. Ulkopuolinen konsultti on usein se koostava voima, joka pitää määrittelytyön fokuksessa ja riittävän kattavana.
Jaakko Wegelius