Tietojärjestelmähankinnat ovat lähes aina sen kokoluokan investointeja, että olisi hyvä varmistaa, että investointi kohdistuu oikein. Hankkeen valmistelu kannattaa aina, riippumatta siitä, ollaanko ostamassa valmista tuotetta, toteutusprojekteja vai resursseja. Hyvällä valmistelulla vältämme virhehankintoja ja laastariratkaisuja, ja samalla varmistetaan, että eurot kohdistuvat oikeaan asiaan. Tähän tulee avuksi hankkeen esiselvitys. Esiselvityksellä varmistetaan, että ollaan ratkaisemassa oikea ongelma ja myös, että ratkaistaan se oikein ja laadukkaasti.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
7.11.2022
Tarpeet ensin, ratkaisu sitten
Tyypillisesti esiselvitysvaihe aloitetaan kartoittamalla tarpeet. Ensimmäinen kysymys onkin usein, mitä haluamme saavuttaa uudistuksella tai investoinnilla? Vasta toinen kysymys on, miten me pääsemme tavoitteeseen. Tarpeita on sekä loppukäyttäjillä että palvelun tuottavalla organisaatiolla. Verkkopalvelua ei rakenneta eikä tietojärjestelmää hankita pelkästään loppukäyttäjän tarpeisiin, vaan sillä tulee olla myös organisaation kannalta joku funktio, ja tämä on erityisen tärkeä kirkastaa esiselvityksellä. Miksi ylipäätänsä haluamme laittaa eurojamme johonkin uuteen järjestelmään?
Tarpeita voidaan kartoittaa hyvin monella eri tavalla. Käyttäjien tarpeita voidaan selvittää mm. kohderyhmähaastatteluin, erilaisin kyselyin tai tutkimalla organisaation saamia palautteita ja tilastoja. Organisaation tarpeita ja tavoitteita puolestaan kartoitetaan esimerkiksi avainhenkilöhaastatteluilla, nykyratkaisuja analysoimalla sekä peilaamalla olemassa olevia ratkaisuja strategiaan ja liiketoiminnan tavoitteisiin. Esiselvitysvaiheeseen voi myös sisältyä laajempaa palvelumuotoilua mutta näin ei aina ole.
Tarpeiden tunnistaminen on kaiken pohja, mutta tarpeista ei voida vetää suoraa viivaa ratkaisuun, sillä harvoin on olemassa vain yksi tapa ratkaista ongelmaamme tai päästä tavoitteisiimme. Juuri meille soveltuvaa ratkaisua voi haarukoida kahdella tapaa – joko niin, että otetaan valmis tuote, ja tarkastellaan, miten tämä vastaa meidän tarpeisiimme, tai niin, että tarpeista johdetaan palvelukonsepti, ja lähdetään tarkastelemaan, mitä ratkaisuja tai vaihtoehtoja on tarjolla, joilla palvelukonsepti voidaan toteuttaa.
Palvelukonseptin kirkastaminen onkin yksi vaihe esiselvityksessä, ja se on erityisen tarpeellista silloin, kun ollaan hankkimassa verkkopalvelun toteutusta projektina. Verkkokauppahankinnoissa puolestaan tuotteet ja niiden ominaisuudet ovat usein lähtökohtana, vaikka niissäkin palvelukonseptia voidaan hyvin pohtia. Räätälöidyissä järjestelmissä tai asiointipalveluissa lähtökohtana on taas usein käyttäjien palvelupolkujen mallinnukset ja näistä johdettavat vaatimukset järjestelmälle.
Samalla kun suunnitellaan palvelukonseptia, tulee priorisoitavaksi mitkä tarpeistamme ja vaatimuksistamme on toista tärkeämpiä. Kaikkea kun ei voi saada ja toisaalta tarpeet ja vaatimukset voivat olla toistensa kanssa ristiriidassa niin, että toimivan kokonaisuuden aikaansaamiseksi on jostain luovuttava.
Markkinatuntemus on avainasemassa
Riippumatta siitä, olemmeko ostamassa asiakaskohtaista toteutusprojektia jonkun tuotteen päälle, vai jotain valmista ratkaisua, meidän on tunnettava ja arvioitava vaihtoehdot, ennen kuin hankintaan kannattaa lähteä. Ellei hyvää markkinatuntemusta ole päässyt kertymään, on markkinakartoitus paikallaan.
Kun tarjonta on tiedossa, eri vaihtoehtoja on hyvä myös vertailla. Markkinoilla olevia ratkaisuja ei kuitenkaan ole mielekästä vertailla keskenään tyhjössä, vaan vaihtoehtoisia ratkaisuja tulisi aina punnita omia tarpeita ja suunniteltua ratkaisua vasten. Ratkaisut voivat paperilla olla yhtä hyviä, mutta ydinkysymys on, kuinka hyvin ne soveltuvat niin suunniteltuun palvelukonseptiin, tarpeisiin, olemassa olevaan järjestelmäarkkitehtuuriin ja budjettiin? Ratkaisuvaihtoehtoja arvioidessa on hyvä myös tarkastella toimittajakenttää – onko riskinä toimittajalukko, vai onko riittävästi toimittajia tarjolla, jotta saadaan kunnon kilpailu aikaiseksi?
Tässä vaiheessa on hyvä tarkastella myös omia resursseja ja miettiä, minkälaista yhteistyötä halutaan. Kuinka paljon apuja tarvitaan esimerkiksi käyttöönottoon ja jatkokehitykseen? Riittääkö meille, että toimittaja tekee projektin tai hoitaa tuotteen käyttöönoton, jonka jälkeen perävalot vilkkuvat, vai haluammeko ennemmin löytää pitkäaikaisen kumppanin?
Tiekartta auttaa aikataulujen ja resurssien hahmottamisessa
Jos toiveena on, että toteutusprojekti tai uuden tietojärjestelmän käyttöönotto menee mahdollisimman sujuvasti, kannattaa esiselvitysvaiheessa vielä pysähtyä pohtimaan hankkeen läpivientiä ja kokonaisaikataulua.
Tiekartta on hyvä apu silloin, kun on tarve hahmottaa esimerkiksi projektin läpiviennin eri vaiheita ja niiden suhteita toisiinsa. Projektin – tai hankinnan - ulkopuolella voi olla asioita, jotka vaikuttavat aikatauluun, ja nämä saadaan hyvin tiekartalle näkyviin. Näin voidaan ennakoida sellaiset päätökset, muutokset ja resurssitarpeet, jotka vaikuttavat uuden järjestelmän tai esimerkiksi verkkopalvelun toteutukseen, eikä aseteta alkuun epärealistisia aikatauluja, joista joudumme kuitenkin tinkimään.
Tiekartta ei ole sama kuin tarkka projektisuunnitelma, vaan ylätason kuva siitä, mitä tarvitaan milloinkin ja mitä pitää tehdä ennen kuin jokin toinen asia on mahdollinen.
Hyvä suunnitelma maksaa itsensä takaisin
Hyvin valmisteltu hanke sujuvoittaa lopulta myös koko hankintaprosessia ja auttaa oikean hankintamenettelyn valinnassa. Lisäksi esiselvitykseen ja hankkeen valmisteluun panostettu aika ja raha, maksavat itsensä helposti takaisin, kun toteutus lähtee heti liikkeelle oikeilla raiteilla.
Hyvä valmistelu ja esiselvitys ei myöskään ole millään tavalla este ketterälle toteutukselle, joka on tänä päivänä tietojärjestelmähankkeissa käytännössä de facto toimintatapa. Hyvällä alkuvaiheen pohjatyöllä varmistetaan, että tekeminen saadaan ohjattua heti alusta oikeaan suuntaan. Muutaman kuukauden ylimääräinen valmistelu alkuun harvoin harmittaa, kun näin vältytään monelta hutiratkaisulta.
