Onko blockchain yrityksellesi pelkkä troijan hevonen?

Harvat uudet teknologiat ovat yhtä kiinnostavia ja samalla yhtä vaikeita hyödyntää olemassaoleviin liiketoimintamalleihin kuin lohkoketju, eli blockchain. Lohkoketjun kansikuvajutut bitcoin-kurssikäyrän kera ovat helposti kirjoitettavia, teknologiaan on sijoitettu valtava määrä rahaa ja näyttää siltä, kuin lohkoketjulla olisi todella helppo tienata miljoonia tai miljardeja. Lohkoketju on vieläpä todella hienoa teknologiaa!

Väitän silti voimakkaasti, että useimmille yrityksille lohkoketju on tässä vaiheessa pelkkä kangastus tai troijan hevonen, vaikeasti kaupallistettava superkiinnostava teknologia, joka häiritsee aivan yhtä kiinnostavien mutta nopeasti kaupallistettavien teknologioiden kehitystä.

Blockchain-hypestä tulee Itselle mieleen Ford-autovalmistajan Nucleon -konsepti, kuvankaunis amerikanrauta, jonka moottorina piti olla ydinreaktori. Kun ydinreaktorit olivat kuuminta hottia, niitä ajateltiin asennettavan autoihin, lentokoneisiin, juniin ja jokaiselle asuinalueelle. Todellisuus olikin sitten jotain muuta.

Vähän sama tilanne on lohkoketjun kanssa. Valtavan hienoa teknologiaa, jolla voidaan tehdä uusia palveluita, joita ennen ei olisi voinut kuvitellakaan. Valitettavasti suurin osa nykyisen liiketoimintamallin ja lohkoketjun yhdistelmistä on yhtä banaaleja kuin Fordin ydinreaktorilla käyvä henkilöauto – teoriassa mahdollisia, mutta härveleitä, joiden haitat eivät koskaan vastaa niistä saatua hyötyä.

Mistä sitten kannattaisi aloittaa? Itse ehdotan, että nyt on oikea aika jakaa uusien teknologioiden kehitys kolmelle eri tiimille tai striimille, jos tilanne on samanlainen kuin monilla asiakkaillamme.

  • Tiimi I

Useimmat organisaatiot ovat yllättävän käsityövaltaisia, kun niihin kunnolla tutustuu. Arkisia työvaiheita varten tulostetaan A4:ia, tieto siirretään järjestelmästä toiseen käsin tai eri järjestelmissä olevaa tietoa ei saada yhdistettyä fiksumpaa toimintaa varten.

Yritys, jonka tiedot ovat tällä tavalla hujan hajan ei voi onnistua uudistumisessa, mutta onneksi nykyään yhteisen näkymän luominen on halvempaa ja nopeampaa kuin koskaan aiemmin, eikä tätä varten ole pakko ostaa SAP:pia tai mitään muutakaan monoliittista sovellusta.

  • Tiimi II

Toisena striiminä etsisin kaikki ne kohdat, joissa arkisia päätöksiä tehdään täysin prosessin mukaisesti. Jokainen käsityönä tehty, tarkkaa byrokraattista prosessia noudattava päätös kannattaa automatisoida. Tiedon käsittelyn nopeuttaminen tuo yllättäviä hyötyjä, useimmiten sekä asiakkaalle että myynnille ja markkinoinnille.

  • Tiimi III

On vaikea saada rahoitusta tiimeille I ja II ilman vanhoista malleista poikkeavia liiketoimintasuunnitelmia. Asiat ovat rempallaan, koska loppujen lopuksi vanhassa maailmassa on ollut halvempaa teettää enemmän käsityötä kuin automatisoida prosessit loppuun saakka. Tämä on muuttunut viime vuosina. Automatisointi on jatkossa onnistumisen edellytys, eikä siitä voi tinkiä. Uudet tekoälyyn perustuvat liiketoimintamallit vaativat perustuksekseen hyvää tietoa ja organisaation, joka ei tuhlaa aikaa ja rahaa turhaan käsipelillä tunkkaamiseen.

Tekoäly, tai oikeastaan sen koneoppimiseksi kutsutut toteutustavat, ovat jo arkipäiväisiä. Kaikkien suurten internetyritysten, Googlesta Spotifyhyn, onnistumisen salaisuus on fiksussa koneoppimisen käytössä. Useimmilla toimialoilla tekoälyä fiksusti hyväksikäyttävä yritys tulee seuraavina vuosina pieksemään ne, joiden tekoälytiimi ei ole päässyt vauhtiin.

Kolmostiimi toimii myös loistavana kirittäjänä kahdelle muulle tiimille. Tieto, jonka yhdistäminen on vaikeaa tai johon liittyvät päätökset tehdään vielä käsipelillä, tulee yhdistetyksi ja automatisoiduksi, kun kolmostiimi lupaa sellaista, jota kilpailijalla ei ole – automaattisen asuntolainapäätöksen, juuri sinulle halvalla räätälöidyn puvun valmistuksen tai juuri sinun makuusi viritetyn illallisreseptin.

Me Codentossa autamme teknologiavalinnoissa ja olemme ammattilaisia Tiimien I, II ja III työssä. Etsimme jatkuvasti uusia arkkitehtejä teknologiatiimiimme ja teemme niin suuria kuin pieniä teknologiavalinta toimeksiantoja yksityisellä ja julkisella puolella.

 

Banneri Uuden verkkopalvelun teknologiavalinnat 2018

Hankintalaki on tekosyy – 7 neuvoa päättäjälle

Kun ostaa sian säkissä, se ei ole hankintalain vika – vaikka julkishallinnon puolella sen taakse helposti piiloudutaan. Turhan harva tietää, ettei hankintalaki estä tekemästä hyvää ostosta. Julkishallinnossa hankitaan jatkuvasti laajoja järjestelmiä kohtuukustannuksilla ja loistavalla laadulla.

Se mikä ei julkisella puolella onnistu, on jättihankkeen nopea läpivienti. Jonkun on pitänyt käynnistää hankinta jopa vuosia ennen kuin uutta järjestelmää tarvitaan, jottei projekti menisi mönkään.

Hankintalaki, huolellinen tarveanalyysi, kilpailutus ja hankkeen läpivienti vaativat julkisella sektorilla jokainen enemmän aikaa ja taitoa kuin vastaavan hankkeen läpivienti yksityisellä puolella.

Alla 7 neuvoani päättäjälle


1. Eriytä valmisteluvaihe.
Kaikkein vaikeinta tuntuu olevan se, että hankinnan ja määrittelyn pitää olla täysin erillään toisistaan. Ei riitä, että valitsee parhaan tuotteen tai palvelun tarjotuista, vaan valinnan kriteerit on pitänyt asettaa jo ennen hankinnan läpivientiä. Tilanne on joskus yhtä koominen, kuin aviopuolison lähettäminen hänelle vieraaseen kauppaan. Tarkimmatkaan ohjeet eivät riitä ja oivariinin ja ruokakerman sijaan kassista löytyy helposti pari senttiä halvempaa tarjousvoita ja kahvikermaa.

2. Kehitä osto-osaamista. Käytännössä hankintoja pitää tehdä jatkuvasti ja tarkasti, jotta hankintataidot kehittyvät ja säilyvät. Isojen hankintojen ammattilainen on kuin kirurgi, joka tarvitsee kokonaisen yliopistollisen sairaalan potilasmassan, jotta käsi pysyy vakaana. Monessa organisaatiossa ei yksinkertaisesti ole riittävästi isoja hankintoja ammattitaidon kehittämiseksi ja säilyttämiseksi.

3. Resursoi riittävällä tasolla. Jatkuvien hankintojen parhaille ammattilaisille on tarjolla töitä kosolti sekä julkisella että yksityisellä puolella. Haasteena on se, että vain harva julkisen puolen organisaatio on perustanut virkoja, joiden palkkaus vastaa työn vaativuutta. Vielä harvempi aloittaa työt riittävän aikaisin, jotta välttyisi paniikilta ja ‘veren maku suussa’ -vaiheilta.

4. Maalaa visio ja polku ymmärrettävästi. Hankinnasta on vaikeaa saada poliittinen päätös tilanteessa, jossa nykyinen ratkaisu tuntuu olevan vielä ihan käyttökelpoinen. Poliittinen päättäjä on harvoin toimialan ammattilainen ja sellaisten päätösten teko, joista ei ole näkyvää hyötyä nykyisellä vaalikaudella vaatii lujaa poliittista selkärankaa.

5. Aloita ajoissa. Kiusallisen vaikeaksi ajoissa hankinnan aloittamisen tekee valmistelevan työn näennäinen helppous…jonkun on tutustuttava toimittajiin, alalla tyypillisiin ratkaisuihin, sopimusmalleihin, käyttöönottojen vaikeuksiin ja sudenkuoppiin. Etäisen johtajan voi olla vaikea erottaa toisistaan lahjakasta markkinan ja omien tarpeiden selvittäjää messuilla käyvästä laiskottelijasta.

6. Valaise päätöksentekoa. Monessa virastossa on helpompi saada miljoonabudjetti hankkeelle, jonka luullaan olevan helppo, sillä sitä ei ole riittävästi tutkittu, kuin sellaiselle, jonka tunnetut vaikeudet ja sudenkuopat on selvitetty, dokumentoitu ja selätetty hyvällä hankintatavalla. Jälkimmäisessä joudutaan dokumentoimaan riskit, edellisessä päätös voidaan tehdä kuin riskejä ei olisikaan.

Tätä projektien fiksun hankinnan teemaa sanoittaa myös mainio Helsingin Sanomien juttu, lue ex-nokialaisen psykologin Ari-Pekka Skarpin haastattelu.

7. Suosi ketterää. Ari-Pekka Skarp ehdottaa pilkkomaan hankkeen ketterän metodologian mukaisesti ja niin ehdotamme mekin Codentossa. Kaupunki rakennetaan talo kerrallaan ja laaja systeemi niin, että jokaisen laajennuksen jälkeen on toimiva, entistä parempi systeemi. Lähes kaikki suuret tietojärjestelmien kertahankinnat voidaan palastella sarjaksi pienempiä ja samalla riskittömämpiä hankintoja.

Eikä tässä vielä kaikki, alla muutama nämä seitsemän neuvoa koostavaa vinkkiä, eräänlainen hankinnan litmustesti:

+1. Bonusneuvo “vendor-lock-in”. Monimutkaisten palvelujen hankinta on aina vaikeaa. Tee kaikkesi, että voit vaihtaa toimittajaa kesken hankkeen ilman suurempia kustannuksia tai myöhästymisiä. Tämä “jos et käyttäydy kunnolla, en leiki kanssasi” on parasta mitä julkisessa hankinnassa voi omalle toteutustiimille hankinnan aikana antaa.

+2. Bonusneuvo “nuukailu”. Jos pisteytyskriteerit jättävät hankintahinnalle suurimman painoarvon, et todennäköisesti ole ymmärtänyt, mitä kollegasi järjestelmällä aikovat tehdä. Jos painotat hankintahintaa samalla itseasiassa väheksyt hyötyjä ja tulet helposti valinneeksi järjestelmän, josta on vähiten hyötyä. Sekä hinnalla että laadulla on hankinnassa merkitystä, kallein ei välttämättä ole paras. Hankintahinnan painotus johtaa helposti siihen, että todellinen hankintakustannus on moninkertainen hankintahintaan nähden, koska minimisetti ei sittenkään riittänyt työnne tekemiseen.

Petri Aukia
Twitter @aukia

#hankintalaki #julkishallinto #osto-osaaminen #ketteryys #lean #johtaminen #länsimetro 

Tuoteomistaja, ahdistaako ketterä kehitys?

Ketterät kehitysmenetelmät ratkovat tehokkaasti kehitystiimin pulmia, mutta eivät juuri auta tuoteomistajan haasteissa. Sen sijaan ne ovat monien tuoteomistajan kohtaamien ongelmien juurisyy. Ongelmien ratkaisu vaatii muita menetelmiä.

Ketterällä mallilla lähdettiin ratkomaan kolmea pulmaa:

  1. Kehittäjien työ on tehokkaampaa, kun työtä ei koko ajan häiritä.
  2. Liiallinen dokumentaatio ei itse asiassa olekaan välttämätöntä.
  3. Softaprojekti, joka on luovittavissa oikeaan suuntaan, on parempi kuin vuoksiksi raiteille tiukasti sidottu etenemistapa.

Ketterä kehitys, ketteryys, on ollut kuluneen vuosikymmenen megatrendi ohjelmistokehityksessä ja se on korvannut monessa hankkeessa totutun toimintatavan, vesiputousmallin. Uudelle tavalle toimia keksittiin iteratiivista kehitystä hienompi konteksti ja termit – ja sanastoomme ilmestyivät ketteryys, ketterä ja agile. Ketterä kehitys löi läpi koko ICT-alan ja nykyisin ketterää ohjelmistokehitystä tehdään Suomessa valtavirtana pelifirmoista pankkisoftaan saakka.

Miten tuoteomistaja hyötyy ketterästä?

Valitettavasti ketterä kehitys jätti softahanketta vetävän johtajan tai tuoteomistajan leikin, riemun ja uusien ratkaisujen ulkokehälle. Ennen vastuuroolissa oli kuukausia aikaa miettiä mitä tarvitaan ja miten saadaan kaikkien hyväksyntä jokaisen vaiheen sisällölle. Nyt vastuunkantaja joutuu kahden viikon välein yksin taistelemaan projektin puolesta tuulimyllyjä vastaan. Se ei useinkaan ole se voittava arpa.

Kun päätettäviä asioita on käsillä kahden viikon välein, vaatii malli tuekseen selkeän päätöksentekotavan. Näin usein ei ole aikaa miettiä kaikkea alusta asti vaan tarvitaan roteva selkäranka, jonka varassa saa nopeasti tehtyä hyviä päätöksiä.

Selkärankana ei toimi pelkkä hähmäinen visio eikä sellaista ehdi jokaista hanketta varten tyhjästä rakentaakaan. Parempaa tekemistä löytyy aina. Post-ketteryys edellyttää valmismallia, joka soveltuu organisaation tulevaisuuden kannalta kriittisimpään päätöksentekoon.

Post-ketteryys = lean + ketterä

Olen käyttänyt lean-maailmasta tuttuja lähestymistapoja ketterien kehityshankkeiden tukemiseen nyt parisen vuotta ja kokemukseni on, että lähestymistapa on lähes kaikissa tapauksissa nappivalinta.

Lean-maailman Toyotat ja Four Seasons -hotellit ovat lähteneet ratkomaan samaa pulmaa kuin ketterä tuoteomistaja: “miten palveluamme tai tuotettamme kannattaisi parantaa, jotta kauppa kävisi paremmin?”

Hyvä tuoteomistaja tai liiketoiminnan kehittäjä: et varmaankaan ole ensimmäistä kertaa tämän kimurantin pulman edessä – valmiita ratkaisuja löytyy, samoin kirjallisuutta, konsultteja ja parhaita käytäntöjä. Älä jää yksin kääntelemään backlogia talikolla, vaan etsi avuksesi lean-maailman voittavia ratkaisuja. Post-ketteryys on täällä.

Lukusuositus: kollegani Karoliina Luodon laatima Tuoteomistajan Scrum-pikaopas.

Petri Aukia
Twitter @aukia

#tuoteomistaja #ketterä #ketteryys #postketterä #postagile #lean #scrum #ithanke

***

Kuva: Flickr CC / Stewart Black 

Kundit kuntoon – entä tietojärjestelmät?

Helsingin kaupunki tietää, että terveystarkastuksessa “joka kolmannella helsinkiläisellä miehellä todetaan kohonnut riski sairastua sydän- ja verisuonisairauksiin.Kaupunki tietää myös, että sairastumisriski nousee ripeästi miehen täytettyä 40 vuotta. Sydän- ja verisuonisairaudet ovat ikäviä ja niiden hoitaminen on kallista. Kaupunki haluaa siksi löytää riskiryhmään kuuluvat miehet ja erilaisin terveydenhuollon keinoin auttaa heitä lykkäämään sairastumistaan.

Aiemmin kaupunki kutsui kaikki 40 vuotta täyttävät miehet terveystarkastukseen terveyskeskukseen. Tarkastukseen saivat kutsun myös riskiryhmään kuulumattomat kaksi miestä kolmesta. Tämä oli kallista. Kaupunki päätti ratkaista ongelman hankkimalla sähköisen terveystarkastuksen eli verkkopalvelun, jolla miehet voivat itse tarkistaa riskitasonsa ja sen perusteella hakeutua terveyskeskukseen tarkempiin tutkimuksiin.

9 kohtaa tehtävää – ennen kuin pääset edes koko terveystarkastukseen

Joonas Lyytinen täytti 40 vuotta ja sai kutsun sähköiseen terveystarkastukseen. Kutsun mukana tuli ohje,kundit jossa on 9 kohtaa tehtävää ennen varsinaista terveystarkastusta. Ennen terveystarkastusta 40-vuotiaan miehen on tunnistauduttava sähköisesti, luotava kahdesti itselleen tunnukset ja navigoitava useilla tarkastukseen liittymättömillä verkkosivuilla. Lyytisen kokemuksen mukaan moni riskiryhmässä oleva jättänee tarkastuksen tekemättä sen hankaluuden vuoksi. Moni riskiryhmään kuuluva ei saa tietoa riskeistä. Seurauksena on turhia sairastumisia, kustannuksia ja myös ennenaikaisia kuolemia.

Mikä meni pieleen? Miten tällaisen monimutkaisuuden olisi voinut välttää? Miten olisi voinut varmistaa, että sähköinen terveystarkastus ei jää tekemättä tietojärjestelmän kömpelyyden vuoksi?

Suunnittelun lähdettävä käyttäjien tarpeista

Kaikkien järjestelmien, ja ehkäpä erityisesti tietojärjestelmien, suunnittelu on hyvä aloittaa asiakkaan ja hänelle järjestelmän käytöstä syntyvän arvon miettimisellä. Koska arvo on hyödyn ja kustannusten erotus, on arvioitava niitä erikseen.

Terveystarkastusjärjestelmällä on kaksi asiakasta eli käyttäjää: 40-vuotias mies ja kaupunki. Heidän järjestelmästä saamansa arvot on helppo ymmärtää:

  • Mies saa järjestelmästä hyötyinä tiedon riskeistään ja ajanvarauksen tarkempiin tutkimuksiin. Miehen kustannukset ovat järjestelmän käyttöön kuluva aika ja käytöön kuluvat henkiset voimavarat. Ajan ja voimavarojen käytön minimoinnin siis oltava järjestelmän suunnittelun tavoitteena.
  • Kaupunki saa järjestelmästä hyötynä säästöjä terveydenhuollon kustannuksista. Kaupungin kustannukset ovat järjestelmän hankintakulut ja tarkempien terveystarkastusten kustannukset. Hankintakulut ovat varmasti kertaluokkaa tai paria pienemmät kuin tarkempien terveystarkastusten kulut, sairauksien hoitokuluista puhumattakaan. Kaupungin kannalta on siis olennaista saada mahdollisimman moni riskiryhmään kuuluva tarkempaan tarkastukseen.

Asiakkaiden hyödyt ovat erilaiset. Samoin ovat hyödyistä johdettavat tarpeetkin. Mies tarvitsee tietoa tarkastuksen tuloksista, mutta kaupunki ei miehen tietoja tarvitse. Sekä mies että kaupunki tarvitsevat keinon saada tarkastuksen mukaan riskiryhmään kuuluva mies mahdollisimman pian ja vaivattomasti terveyskeskukseen tarkempaan tarkastukseen.

Ratkaisu: turhat mutkat suoriksi!

On hyvin vaikeata ymmärtää, miksi nykyinen järjestelmä kysyy miehen henkilötietoja. Niiden syöttäminen järjestelmään ei luo arvoa miehelle eikä kaupungille. Mies tietää kuka on, kaupungin ei tarvitse tietää. Kaupungin ei myöskään tarvitse tietää terveystarkastuksen tuloksia, koska ne on kuitenkin tarkastettava vastaanotolla.

Yksinkertainen 40-vuotiaiden terveystarkastusjärjestelmä toimisi seuraavasti:

  1. Mies saa kaupungilta kutsun tarkastukseen. Kutsussa on suora linkki tarkastukseen. Koska olennaista on saada riskiryhmään kuuluvat tarkempaan tarkastukseen terveyskeskukseen, linkin ei tarvitse olla yksilöity. Mikäli joku 43-vuotias tekee sähköisen tarkastuksen ja huomaa kuuluvansa riskiryhmään, kaupungille syntyy arvoa.
  2. Mies tekee terveystarkastuksen verkossa.
  3. Mikäli tarkastuksessa ei löydy riskejä, mies saa onnittelut ja kehoituksen jatkaa hyviä elintapojaan.
  4. Mikäli tarkastuksessa löytyy riskejä, järjestelmä kysyy mieheltä mieluisia terveysasemia ja ehdottaa niiltä 10 eri aikaa tarkemmalle tarkastukselle. Mies varaa hänelle parhaiten sopivan ajan käyttämällä vaikkapa henkilötunnustaan. Sähköistä tunnistautumista ei tarvita.

Tällainen järjestelmä tuottaisi huomattavasti enemmän arvoa sekä miehille että kaupungille. Järjestelmän toteuttaminen ei ole vaikeata eikä kallista. On mystistä, miksi ja miten nykyiseen järjestelmään on päädytty.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Maksaako esiselvitys vaivan?

Esiselvityksen tärkein tehtävä on varmistaa, että projektista saatavat hyödyt ovat todellisia, toteutettavissa olevia, rahaksi muutettavissa ja kuluja suurempia.  Hyödytöntä projektia ei pidä toteuttaa – ei, vaikka budjetissa olisi ylimääräistä rahaa.

Miksi esiselvittää?

Ennen projektia on tapana tehdä esiselvitys. Joskus esiselvitys tehdään, koska niin on ollut aina tapana tehdä. Joskus esiselvitys tehdään osana kilpailutusta, jolloin esiselvitys on osa kilpailutusdokumentaation tekemistä. Joskus esiselvitys tehdään, koska budjetissa on rahaa ja se on syytä käyttää – selvitetään siis onko rahan käyttäminen johonkin tarkoitukseen mahdollista teknisesti, osaamisen suhteen ja monelta muulta kannalta.

Kaikki nämä näkökannat ovat tärkeitä. Onhan ennen projektia tiedettävä

  • mitä on tarkoitus saada aikaan,
  • miten se on tarkoitus saada aikaan,
  • kuka sen tekisi ja
  • paljonko asian tekeminen maksaisi. 

Nämä tiedot eivät kuitenkaan vielä riitä. Yksi olennainen asia jää puuttumaan. Jokaisen projektin tarkoituksena on nimittäin luoda jotain hyötyä jollekulle. Projekti on perusteltavissa, jos siitä saadut hyödyt ovat suuremmat kuin projektin kulut. Mikäli kulut lopulta osoittautuvat suuremmiksi kuin hyödyt, on projekti epäonnistunut vaikka se olisi pystytty toteuttamaan aikataulussa ja jopa budjetoitua halvemmalla. Epäonnistuneeseen projektiin käytetyt voimavarat olisi pitänyt käyttää johonkin hyödylliseen.

Esiselvityksen tärkein tehtävä on varmistaa, että projektista saatavat hyödyt ovat todellisia, toteutettavissa olevia, rahaksi muutettavissa ja kuluja suurempia.  Tämän selvittämiseksi on toki syytä tutkia toteutusteknologioita, käytössä olevien henkilöiden osaamista, markkinoilta saatavissa olevia valmisjärjestelmiä ja montaa muuta seikkaa. Todellista merkitystä on kuitenkin ainoastaan hyödyillä. Hyödytöntä projektia ei pidä toteuttaa – ei, vaikka budjetissa olisi ylimääräistä rahaa.

Mitä hyödyt ovat?

ICT-projekti, kuten mikä tahansa projekti, voi auttaa organisaatiota (yritystä, ministeriötä, tms.) tekemään nykyiset tehtävät paremmin, tekemään uusia asioita tai välttämään joidenkin asioiden tekemisen kokonaan. Osaa hyödyistä voi mitata suoraan rahana (esimerkiksi tarvittavien raaka-aineiden määrän vähenemisenä), osan jonain muuna mitattavana suureena (esimerkiksi säästyneenä työaikana) ja osan voi havaita, muttei mitata tarkasti (esimerkiksi parantuneena maineena tai muuna vaikeammin rahaksi muutettavana suureena). Kaikki nämä hyödyt ovat hyviä perusteita projektin toteuttamiselle, joskin pelkästään maineen parantumisella perustellut projektit osoittautuvat myöhemmin vain vähän hyötyä luoviksi.

Hyötyjen suunnitteleminen ja arvioiminen on hankalaa

Hyötyjen arvioiminen tarkasti ja realististisesti on vaikeaa. Tutkimusten – ja yleisen projektikokemuksen – mukaan hyödyt usein yliarvioidaan. Tämä on inhimillistä, onhan onnistumisen ennustaminen kivempaa kuin epäonnistumisen. Esiselvityksen tekijä saattaa olla myös projektin toteuttaja – silloin on vaikeata sanoa, ettei projektista olisi hyötyä. Säästyneen työajan käyttäminen tuottavasti saattaa osoittautua paljon hankalammaksi toteuttaa kuin esiselvityksessä on arvioitu. Toisinaan näet säästynyt työaika pitäisi realisoida hyötynä irtisanomalla henkilöstöä. Mikäli tämä on tarkoitus, on irtisanomista sovittava jo esiselvityksen aikana ja ne on toteutettava ajallaan. Tätä tapahtuu hyvin harvoin.

Hyötyjen tarkkaa arviointia ja suunnittelua vaikeuttaa myös se, että esiselvitystä tekemässä harvoin ovat henkilöt, joille projektista olisi hyötyä ja joiden pitäisi toteuttaa prosessi- ja henkilöstömuutokset, joiden avulla projektin hyödyt saadaan aikaiseksi. Esiselvitystä ja hyötyjen suunnittelua ei voi tehdä vain tietohallinnon ja konsulttien voimin, vaan mukaan on otettava laaja joukko uuden järjestelmän käyttäjiä.

Tarkistuslista: kannattaako projekti toteuttaa esiselvityksen perusteella?

Esiselvityksessä on siis pystyttävä arvioimaan projektin hyödyt mahdollisimman tarkkaan. On myös luotava – yhdessä hyödyn toteuttajien ja saajien kanssa – tarkka suunnitelma hyötyjen toteuttamisesta projektin aikana ja erityisesti projektin valmistuttua. Projektin hyödyt toteutuvat vähitellen uuden järjestelmän ja uusien toimintatapojen myötä. Hyötyjen toteutumista on seurattava koko projektin ajan ja verrattava toteutumaa esiselvityksessä suunniteltuun. Mikäli hyödyt eivät projektin aikana toteudu suunnitellusti, on harkittava projektin keskeyttämistä. Rajalliset resurssit on syytä siirtää hyödyttömästä tekemisestä hyödylliseen mahdollisimman aikaisessa vaiheessa.

Esiselvityksen hyötysuunnitelman tarkistamiseen voi käyttää esimerkiksi seuraavaa tarkistuslistaa. Mitä vähemmän listalla on kyllä-vastauksia, sitä epävarmemmalla pohjalla projektin kannattavuus on.  

#KysymysKyllä/Ei/Osittain
1.
Ovatko kaikki hyötyjen saamiseksi vaadittavat kustannukset
tiedossa - myös käyttäjien prosessimuutokset,
henkilöstöjärjestelyt, koulutukset ja vaikkapa toimitilamuutokset?
2.Ovatko käyttäjät ja heidän esimiehensä sitoutuneet yksimielisesti
uuden järjestelmän käyttöönottoon ja sen vaatimiin muutoksiin
toiminnassa?
3.Ovatko kaikki hyödyt selkeästi ilmaistut säästettynä rahana, kasvaneena
liikevaihtona, pienentyneenä riskinä tai jonkin
strategisen tavoitteen määrällisenä täyttymisenä?
4.Liittyvätko hyödyt todellakin hankkeen päätarkoitukseen vai
syntyvätkö ne hankkeesta riippumatta?
5.Onko hyödyistä sovittu hyötyjen saajien kanssa ja ovatko
hyödyt mukana budjeteissa, henkilöstövähennyksissä,
strategioissa ja henkilökohtaisissa tavoitteissa, ja onko
mahdollisiin YT-neuvotteluihin varauduttu?
6.Käykö liiketoimintasuunnitelmasta selvästi ilmi, että aiempien
projektien kokemukset on otettu huomioon?
7.Onko väitettyjen tehokkuusparannusten toteutumismekanismi
selvä: esim. pienempi budjetti, vähemmän työntekijöitä,
säästyneen työajan käyttö johonkin tuottavaan?
8.Onko varmaa, ettei hyötyjä ole liioiteltu? Onko hyötyjä verrattu
edellisten projektien ja hankkeiden toteutumiin?
9.Onko olemassa kirjallinen suunnitelma, josta käy ilmi miten
hyödyt toteutuvat, kuka on vastuussa toteutumisesta, milloin
hyödyt toteutuvat ja miltä maailma näyttää hyötyjen
toteutumisen jälkeen?
10.Onko liiketoimintasuunnitelmassa otettu huomioon hyötyjen
hallinnointiin, seuraamiseen ja raportointiin liittyvät
kustannukset?
Bonus 1Onko mahdollista, että esiselvityksen perusteella päätetään
olla ryhtymättä projektiin? Jos ei, mitä merkitystä
esiselvityksellä on?
Bonus 2Ovatko hyödyt selkeästi kustannuksia suuremmat?
Bonus 3Onko projekti paras tapa suunniteltujen hyötyjen
toteuttamiseen? Onko olemassa muita tapoja?

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.