Teen paljon
vaatimusmäärittelyä osana kilpailutuksia hyvinkin laidasta laitaan erilaisten
sovellusten (esimerkiksi ERP) valinnasta IT-palveluiden ulkoistamiseen tai
konesalitoimittajan valintaan. Yhteinen haaste näille kaikille on ollut kaivaa
esiin asiakkaan todellinen tarve, mikä on monesti asiakkaalta vielä hämärän
peitossa. Jokaisen määrittelyn osalta olen joutunut pohtimaan samaa
ikuisuusasiaa: mikä on riittävää asiakkaalle (kuten myös toimittajalle
vaatimusmäärittelyn osalta) kilpailutusta tehdessä? Kilpailutukset ovat olleet
melko suoraviivaisia käyttöönottoja, toimittajan kilpailutusta ja sopivimman
toimittajan valintaa. Ei siis niinkään ketteriä sovellusprojekteja, joissa on
aivan omat haasteensa.
Aivan ensimmäiseksi,
ennen vaatimusmäärittelyn tekoa, tulee selvittää nykytila. Harvemmin on
saatavilla kuvauksia nykytilanteesta saatikka prosessinomaisia kuvauksia
toiminnasta. Nykyisen menetelmän tai prosessien kuvaaminen visuaalisesti auttaa
muodostamaan käsityksen ratkaistavasta ongelmasta. Tämän pohjalta on helpompi
määritellä mikä on tavoite tai visio. Esimerkiksi ERP-järjestelmät ovat laajoja
kokonaisuuksia, jolloin helposti saattaa iskeä vauhtisokeus ja kaikki tuntuu
tärkeältä ja hyödylliseltä.
Nykytilan kuvaus toimii
myös vertailukohtana, kun mitataan uuden järjestelmän käyttöönoton tuomia
hyötyjä. Monesti uutta työkalua hankittaessa joudutaan miettimään omia
prosesseja ja työmenetelmiä uusiksi. Uuden työkalun käyttöönotto tuo aina
jotain muutosta totuttuihin toimintatapoihin. Tavoite tai visio tulee pitää
kirkkaana mielessä, sillä muutos itsessään on jo suuri. Kaikkea ei kannata
haalia kerrallaan. Toiveiden tynnyri on purettava selkokielisiksi vaatimuksiksi
ja tehtävä selkeät rajaukset, jotka sekä asiakas että toimittajat ymmärtävät. Jokainen
asiakas on uniikki, joten vaatimusmäärittelyä et voi kopioida joltain toiselta.
Et vaikka olisit hankkimassa ERP-järjestelmää samoin kuin naapuriyritys.
Kokosin muutamia seikkoja,
joihin olen omissa vaatimusmäärittelyissä ja käyttöönottoprojekteissa törmännyt
ja joihin mielestäni tulee erityisesti panostaa. Tarjouspyyntövaiheessa ei
kannata säästää aikaa ja vaivaa. Selkeä määrittely, tapahtui projekti sitten
ketterästi tai vesiputousmallilla, maksaa itsensä varmasti
käyttöönottovaiheessa takaisin. Tärkeää on osallistaa määrittelyyn kaikki
tarvittavat osapuolet. Mitä isommasta hankkeesta ja organisaatiosta on kyse,
sidosryhmien määrä saattaa nousta yllättävän suureksi. Keitä muutos koskee?
Ketkä kaikki tulevat käyttämään uutta järjestelmää? Ketkä vaikuttavat
välillisesti työkaluun? Tai ketkä käyttävät ulkoistettuja IT-palveluita?
Millaisia tarpeita heillä kullakin on? Haastatteluihin eri osapuolten kanssa
tulee varata riittävästi aikaa. Tämä takaa varmasti onnistuneemman käyttöönoton
ja tyytyväisemmät loppukäyttäjät. Asiakas tietää ja määrittelee omat tarpeensa,
vaatimusmäärittelyä ei voi ulkoistaa täysin organisaation ulkopuoliselle.
Asiakkaan osallistuminen vaatimusmäärittelyyn riittävin resurssein on
onnistumisen kannalta ehdoton edellytys!
Vinkkejä vaatimusmäärittelyn tekemiseen
2. Luokittele vaatimukset hierakisesti. Näin pystytään keskittymään jokaiseen kokonaisuuteen mahdollisimman kattavasti. Vaatimusmäärittelyä tehtäessä vaatimukset tulee luokitella toiminnallisiin ryhmiin. Esimerkiksi ERP-järjestelmän määrittelyssä tuotetiedon hallinta, asiakkuuden hallinta, varastonhallinta, ostotilaustenhallinta jne.
3. Identifioi vaatimukset. Vaatimukset, joita ei ole numeroitu, tekee jäljitettävyydestä suorastaan painajaisen. Vaatimuksiin on tällöin helppo viitata jälkeenpäin niitä läpikäytäessä.
4. Määrittele lyhenteet ja termit. Hyvä tapa on kuvata vaatimusmäärittelyn ensimmäisessä luvussa kaikki käytetyt termit ja lyhenteet.
5. Imperatiivien käyttö. Käytä ainoastaan yhtä tapaa johdonmukaisesti. Esimerkiksi ”Asiakkaan yhteyshenkilön tulee saada hälytykset vikatilanteista.”, ei ”Asiakkaan tulisi saada…” tai ” Järjestelmän on hälytettävä tiettyjen asetettujen hälytysrajojen lauetessa”.
6. Varmista, että jokainen vaatimus on testattavissa tai varmennettavissa. Toki palveluita määritettäessä laadullisten vaatimusten mittaaminen saattaa olla haasteellista, muttei mahdotonta. Esimerkiksi ”Palveluntarjoajalla on riittävän teknisen osaamisen omaava lähitukihenkilö, jolla on myös ymmärrystä asiakkaan liiketoiminnasta ja IT-tarpeista.” Mikä on riittävää? Mitä teknistä osaamista tarvitaan? Mitä ymmärrystä ja millä tasolla? Pelkkä ylätason vaatimus ei riitä, toimittajan on todistettava vaatimuksen täyttyminen. Osaamista voidaan arvioida esim. vaatimalla näyttöä osaamisesta, määrittelemällä tekninen osaaminen mahdollisimman tarkoin, kuvaamalla vaadittava liiketoimintaosaaminen tarkemmin, CV:n avulla ja kyselemällä referensseiltä. Itse soitan mielelläni myös sellaisille referensseille, joita toimittaja ei ole tarjouksessaan luetellut. Tällä tavoin olen saanut erittäin arvokasta tietoa ja hyviä vinkkejä asiakkaiden näkökulmasta kilpailutuksia tehdessäni.
7. Vaatimus tulee olla lyhyt, ytimekäs ja
yksiselitteinen. Useimmiten vaatimusta
joudutaan kuvaamaan tarkemmin. Vaatimukset voidaan otsikoida, jolloin otsikko
on ytimekäs ja vaatimusta tarkennetaan kuvauksessa. Esimerkiksi ”Palvelupyyntöjen hallintaprosessi.
Toimittajalla tulee olla asiakkaiden palvelupyyntöjen hallintaprosessi, joka
kattaa häiriöiden (incident) lisäksi asiakkaiden avainhenkilöiden
neuvontapalvelun sekä toimeksiantojen vastaanoton ja käsittelyn (customer
request management).” Ensin siis selkeä,
ytimekäs otsikko, mitä vaaditaan (”Palvelupyyntöjen hallintaprosessi”). Vaatimuksessa
tarkennetaan mitä hallintaprosessilta odotetaan.
8. Muista, että vaatimus sisältää vain yhden vaatimuksen!
Ei näin: ”Palvelun tulee kattaa
häiriöhallinnan ja korjaukset sekä muutostenhallinnan ja toimittaja vastaa ko.
palveluiden kuvausten ja määrittelyiden tuottamisesta.” vaan häiriöhallinta
ja muutostenhallinta omina vaatimuksinaan. Häiriönhallinnan kriittisyydestä
riippuen tätä voi tarvittaessa pilkkoa useammaksikin vaatimukseksi jatkuvuuteen
ja vikasietoisuuteen liittyvän luokittelun alle.
9. Älä käytä epämääräisiä tai epäselviä sanoja. Näitä on yleensä adverbit, adjektiivit ja verbit,
joilla ei ole konkreettista kvantitatiivista merkitystä. Hyvä vaatimus ei
sisällä seuraavia sanoja: tehokas, tehostaa, nopea, nopeasti, nopeuttaa, helppo,
luotettava, normaali, käyttäjäystävällinen, vähän, jne.
10. Käytä kielteisiä vaatimuksia todella harkiten. Käytä
negatiivista vaatimusta vain korostaaksesi jonkin vaarallisen tai haitallisen
toiminnan kieltämiseksi. Älä käytä negatiivista vaatimusta, mikäli se voidaan
ilmaista positiivisesti! Esimerkki funktionaalisesta vaatimuksesta: ”Käyttäjiä, joilla on kolme tai useampia
käyttäjätunnuksia, ei saa siirtää.” Muunnettuna positiiviseksi
vaatimukseksi: ”Järjestelmä siirtää vain
ne käyttäjät, joilla on vähemmän kuin kolme käyttäjätunnusta.”
11. Vältä käyttämästä / merkkiä. Merkin tulkinta on epäselvää. Tarkoittaako se, ”ja”,
”tai”, ”yksi jostain” tai niiden yhdistelmää (ja / tai)? Kukin tulkitsee sen
omalla tavallaan.
12. Käy vaatimusmäärittely vielä lopuksi kaikkien
asianomaisten kanssa läpi. Varmista,
että vaatimukset ovat ymmärrettäviä ja kaikki osapuolet ymmärtävät ne samalla
tavalla.
13. Mikään vaatimusmäärittely ei ole täydellinen. Valmistaudu
ja varaudu muutoksiin ja tarkentuviin vaatimuksiin. Toimittajan asiantuntijat
tuntevat työkalut paremmin kuin myyntihenkilöstö ja osaavat ohjata työkalua
konfiguroitaessa oikeaan suuntaan.
Pelkän vaatimusmäärittelyn onnistunut koonti ei välttämättä takaa käyttöönottoprojektin onnistumista, mutta takaa hyvän pohjan sopimusneuvotteluille.