Hyvin suunniteltu on puoliksi tehty ketteränkin kehityksen aikakaudella. Tietojärjestelmähankinnan valmistelussa on ymmärrettävä, mistä uuden järjestelmän arvo syntyy ja mikä sen toteuttamista rajoittaa. Millainen on nykypäivän vaatimusmäärittely?
Ketterä kehitys vaatii kurinalaista valmistelua
Nyt intoillaan ketteristä menetelmistä, ja hyvä niin. Ketteryydessä painottuu asiakkaan visio, vastuu ja priorisointikyky hankkeen ohjauksessa, ja toisaalta jatkuva keskustelu toteuttajan kanssa. Molemmat tekevät hankkeen onnistumisesta todennäköisempää.
Ketterät menetelmät eivät vähennä suunnittelutyön merkitystä ennen hankintaa, oikeastaan päinvastoin. Ketterä kehitys on tiukkaa paneutumista kehitystyöhön. Kehityssprintin numero yksi koittaessa tavoitteiden on syytä olla kirkkaasti selvillä ja avointen kysymysten hyvin rajattuja, jotta kalliita kehityspäiviä ei kulu hukkaan.
Vesiputousvalmistelussa jätettävä tilaa teknologian tehokkaalle käytölle
Ketterien menetelmien rinnalla kulkee edelleenkin se projektimaailma, jossa organisaatiokulttuurin, hyvin rajatun ongelman tai ohjausresurssien rajallisuuden vuoksi ei haluta lähteä ketterään malliin. Silloin hankinnan valmistelussa määritellään kehitystyön tavoitteet ja rajat, ja annetaan hankinnalla kehitystyö toimittajan prosessikoneen huolehdittavaksi.
Tässäkään tapauksessa viisas asiakas ei halua määritellä toteutustyötä tukkoon. Sen sijaan tilaaja antaa kirkkaan kuvan tulevan järjestelmän liiketoiminta- ja käyttötavoitteista, piirtää hyvin näkyviin taustajärjestelmien luomat reunaehdot ja tunnistaa ehdottomat vaatimukset ominaisuuksille. Loppu jää toimittajan ratkaistavaksi tehokkaimmalla ja laadukkaimmalla mahdollisella tavalla valittujen teknologioiden näkökulmasta.
Millainen sitten on moderni hankinnan valmistelu? Tässä malli, jolla esim. Codento niitä asiakkailleen tekee:
Esiselvityksen perusteella voidaan käynnistää hanke
Esiselvityksessä muodostetaan kehitysprojektin liiketoimintatavoitteet ja visio, hahmotetaan järjestelmän taustaprosessit ja niiden muutokset sekä kartoitetaan karkeasti taustajärjestelmät. Mikäli kehityshankkeen teknologiat eivät ole ostajalle tuttuja, osana esiselvitystä tehdään markkinakatsaus tai tekninen vuoropuhelu. Prototyyppien tekeminen osana esitutkimusta voi mutkikkaammissa kokonaisuuksissa olla järkevää. Oleellista on tunnistaa hankkeen omistaja ja tärkeimmät muut vaikuttajat.
Esiselvityksen lopputuloksena saadaan muodostettua hankkeelle ohjausryhmä tai muu tarpeellisella vallalla varustettu päätöksentekotiimi, tehtyä periaatepäätös hankkeeseen lähtemisestä sekä hahmotettua projektimalli, budjetti ja aikataulu. Kun nämä päätökset ovat taskussa, hankinnan valmistelu voi alkaa.
Mieti hankintamalli, järjestelmän arvo ja onnistumisen reunaehdot
Varsinainen hankinta valmistellaan sitten näiden avulla:
- Visio. Hankitaan kuva siitä, mitä käyttäjät järjestelmältä tarvitsevat. Tämän äärellä kannattaa viettää aikaa, sillä jos käyttäjät eivät hyödy järjestelmästä, sitä ei käytä kukaan. Silloin kehitystyö menee väistämättä hukkaan.Käyttäjätarpeen lisäksi visiossa kuvataan, miten järjestelmän onnistuminen muuttaa liiketoimintaa ja organisaation päivittäisissä käytännöissä, sekä asetetaan onnistumiselle yksinkertaiset indikaattorit. Vision osana on myös palvelun alustava konsepti eli toteutuksen perusidea ja sitä hahmottava visuaalinen mallinnus tai prototyyppi.
- Käyttäjäpersoonat. Palvelukehityksen suurille ja pienille päätöksille tarvitaan konkreettinen peilipinta. Tällaisena toimii käyttäjäpersoonat, jotka tehdään käyttäjätutkimuksen tai vaikkapa asiakaspalvelun ja analytiikan tuoman ymmärryksen perusteella. Jo persoonia tehtäessä kannattaa priorisoida: kuka persoonista on kehityksen kannalta ensisijainen? Kenen tarpeet pystytään toteuttamaan vasta järjestelmän seuraavassa versiossa?
- Kuvaus taustajärjestelmistä. Kuvataan järjestelmät, joita vasten järjestelmä toteutetaan. Keskitytään erityisesti niiden lähiaikojen kehitykseen ja rajapintoihin.
- Vaatimusmäärittely tai alustava kehitysjono. Jos toteutetaan vesiputosmallilla, tarvitaan vaatimusmäärittely. Siinä keskitytään kuvaamaan järjestelmän hahmotetut funktiot ja niiltä vaaditut ominaisuudet. Varotaan kuvaamasta sellaisia asioita, jotka on viisainta jättää toimittajan ratkaistavaksi valitun teknologian ja toimittajan työtapojen perusteella.Jos taas tehdään ketterästi, muodostetaan jo hankintavaiheessa asiakkaan näkemys alustavasta kehitysjonosta. Sitä voidaan jalostaa yhdessä valitun toimittajan kanssa, kun toteutustyö alkaa. Kehitysjonon vaatimukset kuvataan ylätasolla, käyttäjän näkökulmasta ja mahdollisimman visuaalisesti.
- Tarjouspyyntö ja sopimusluonnos. Tarjouspyynnössä kuvataan käytettävä hankintamalli, hankittavan kokonaisuuden osat ja eteneminen, ja mikäli kyse on julkishallinnon hankkeesta, kilpailutuksessa vertailtavat asiat ja vertailun kriteerit. Sopimusluonnoksessa naulataan kiinni ostajan kannalta oleelliset reunaehdot ja jätetään neuvottelun varaa niihin kohtiin, joissa sitä on.
Hankintaa valmistellesasi mieti jo projektin aloitusta
Jo hankintavalmistelua aloitettaessa on hyvä varmistaa kolme käytännön asiaa, jotta projekti pääsee alkamaan ajoissa ja sillä on onnistumisen mahdollisuudet:
- Hankkeella on sitoutunut ohjausryhmä, joka on valmis ryhtymään töihin hankkeen hyväksi heti hankintapäätöksen syntyessä, sekä resurssit projektin päivittäiseen pyörittämiseen (esim. ketterässä hankkeessa neljän hengen kehitystiimille täysipäiväinen tuoteomistaja)
- Tarjousten vertailuun on käytettävissä tarvittava asiantuntemus, myös kyseessä olevasta teknologiasta, ja
- Kehitystyöhön tarvittavat palvelimet ja työtilat on mahdollista saada kasaan toteutustyön aloittamiseen mennessä.
Hyvä Renki 
Edellä kuvattu malli on pitkälti avoimeen kilpailutukseen soveltuva ja IT-hankkeissa ei välttämättä paras mahdollinen.
Hankintaa valmistellessa pitää miettiä myös kilpailutustapa. Järjestelmähankintaa tehtäessä tehokkain tapa saada rahalla vastinetta on järjestää kilpailutus kilpailullisella neuvottelumenettelyllä. Tällöin järjestelmiin liittyviä speksejä voidaan tarkentaa neuvotteluiden eri vaiheissa ja myös toteutustapakin voi muuttua. Näin toimittajat pääsevät osaltaan vaikuttamaan teknisiin määrityksiin. Lopullista tarjouspyyntöä laadittaessa toimittajille on syntynyt selkeä käsitys, mitä hankinnalla todellisuudessa halutaan. Kun toimittajat lopullista tarjousta laativat, ei enään yksittäisillä seikoilla (kuten hinta) voida voittaa kilpailutusta.
Todella moderni määrittely siis tapahtuu kilpailutuksen aikana eikä ennen kilpailutusta.
Codento on selvästikin soveltanut tätä modernia ”osaamista” AHTin kautta toteutetulle valtioneuvoston yhteiselle julkaisujärjestelmälle!
Valtioneuvoston yhteisestä julkaisujärjestelmästä en ole kuullutkaan, eikä Codentolla ole sen kanssa mitään tekemistä. Haluaisitko kertoa enemmän, mikä sen kanssa on ollut ongelmana?
Jos olisimme olleet, olisimme sen toki pyrkineet tekemään modernimmin käytännöin, jolloin harmituksen aiheetkin ehkä voisivat olla vähäisempiä.
Kuvattu malli sisältää tunnettuja ja paljon käytettyjä lähestymistapoja (visio, käyttäjäpersoonat, vaatimusmäärittely…). Näitä on käytetty ennenkin, ja silti monesti tietojärjestelmäprojektit ovat epäonnistuneet.
Onko esitetyssä mallissa jokin erityinen uusi asia, jolla se eroaa vanhoista (toimimattomista) käytännöistä?
(Itse olen kuullut joskus jossakin hankinnassa sanottavan ratkaisuna, että tehdään vanhat asiat ”kunnolla”. Minun korvissani ei oikein uskottavaa.)
Hyvin kiteytetty Timo, postauksessa ei esitellä uutta avaruusteknologiaa eikä hopeluoteja. Tiivistettynä tarkoitukseni oli sanoa että mitä välineitä hankinnan valmistelussa sitten käytetäänkin, on syytä keskittyä järjestelmällä ratkaistavien liiketoiminnan ja käyttäjien tarpeiden kuvaamiseen, ei tulevan järjestelmän toiminnan kiinnittämiseen. Tällöin ei suljeta pois onnistumisen mahdollisuutta.