
Vieläkin sylettää, kun muistelen muutama vuosi sitten julkistettua tutkimusraporttia tietohallinnon kehityshankkeiden onnistumisesta. Aalto-yliopisto oli yhdessä Sofigaten ja Tivian kanssa selvittänyt, että 34 prosenttia yritysten IT-projekteista ei pysy aikataulussa ja budjetissa. Kolmannes, ei helevettiläinen! Silti paljon huolestuttavampi fakta on, että yli 40 prosenttia suomalaisista yrityksistä ei seuraa kehityshankkeidensa liiketoiminnallisten tavoitteiden saavuttamista. Tämä kertoo vielä pahemmasta ongelmasta.
Projektien myöhästymisen ja ylipaukkuvien budjettien syyt ymmärrän. Ihmisluonto nyt vain sattuu olemaan ylioptimistinen aikatauluja ja kustannuksia allokoidessaan, eikä kaikkia muuttujia tule aina otetuksi huomioon.
Sitä en jaksa ymmärtää, miten yritys käyttää miljoonan IT-hankkeeseen, mutta ei seuraa, miten hankkeelta odotetut hyödyt saavutetaan. Numerosokeudesta ei ole kyse. Liiketoiminta kyllä tietää, miten tavoitteita asetetaan ja onnistumista seurataan, se on heidän leipätyötään. Mutta kun kehitysprojekti heitetäänkin aidan yli IT-maailman puolelle, tämä ymmärrys ei seuraa perässä. Liiketoiminnan pitäisi osata avata tilanne IT:lle heidän ymmärtämällään kielellä. Pelkkä prosessikaavioiden piirtäminen ja Lean-ajattelusta puhuminen ei riitä.
”Sitä en jaksa ymmärtää, miten yritys voi käyttää miljoonan IT-hankkeeseen, mutta ei seuraa, miten hankkeelta odotetut hyödyt saavutetaan.”
Väitän, että IT-projektin liiketoiminnallisten tavoitteiden saavuttamista ei seurata, koska tavoitteita ei projektin alkuvaiheessa osata asettaa.
Päämäärätöntä palloilua siiloutuneella pelikentällä
Samassa tutkimuksessa noin kolmannes tutkittavista yrityksistä vastasi, että liiketoiminnan ei ole helppo ymmärtää tiedohallinnan toimintakenttää. Eli bisnes ei ymmärrä, mitä IT tekee. Kyse on pitkälti kommunikaatio-ongelmista, jotka ovat jälleen peräisin ihmisyyden ytimestä: miten moni meistä saa sanotuksi, että hetkonen, nyt en ymmärrä? Tällaisessa tilanteessa tulee helposti delegoitua asia sen kuuluisan Jonkun Muun hoidettavaksi. Bisnes huikkaa aidan raosta IT-osastolle, että ”Meillä täällä prosessit sakkaavat! Ohjelmistorobotiikka on nyt kuuminta hottia, tuloksia kuulemma syntyy, kun se otetaan käyttöön ja myös me haluamme sitä hyödyntää. Tässä on valmiiksi maksettu RPA-lisenssi, hoitakaa homma!” Odotukset on tässä vaiheessa pelattu jo korkealle, vaikka ollaankin hakemassa helppoa ratkaisua oireeseen, jonka juurisyytä ei tunneta. Voi esimerkiksi olla, että prosessiin sisään tuleva data on erittäin huonolaatuista ja se sotkee koko arvovirran. Sitä ei väärään kohtaan implementoitu ohjelmistorobotiikkakaan korjaa.
Homma toki hoituu, mutta sokkona ja ilman ymmärrystä ratkaistavan ongelman syistä ja liiketoimintakontekstista. Millaisia tuloksia tällaiselta projektilta voi odottaa, ja millaisia tavoitteita sille voi asettaa?
Teknologiaratkaisusta kustannustehokas: diagnosoi ja hoida juurisyy, älä oireita
Liiketoimintanäkemyksen siirtyminen IT-osastolle on vaikeaa. Olen tavannut sekä sosiaalisesti taitavia insinöörejä, joilla on bisnesvainua ja silmää liiketoiminnalle, että teknisesti taipuvaisia bisnesihmisiä. Tällaiset monitaiturit ovat harvassa. Ilman yhteistä ymmärrystä tavoitteista, liiketoiminta ei uskalla haastaa IT:tä ja toisin päin. Molemmat piilottelevat omien vahvuuksiensa takana.
”Väitän, että projekti johon on lähdetty helpompaa reittiä, tulee teknologiaratkaisun koko elinkaaren aikaisilta kustannuksiltaan kalliimmaksi kuin vaikeampi reitti.”
Parhaaseen lopputulokseen pääsisi etenemällä vaikeamman, juurisyihin pureutumisen, kautta. Koska ihmisiä ja resursseja sitova mielletään usein kalliiksi, päädytään valitsemaan helpompi ja näennäisen nopea reitti, eli tunnistetaan oireet ja hoidetaan niitä. Juurisyyn oireet kuitenkin kipuilevat läpi koko turhauttavan, venyvän ja kalliin projektin. Väitän, että projekti johon on lähdetty helpompaa reittiä, tulee teknologiaratkaisun koko elinkaaren aikaisilta kustannuksiltaan kalliimmaksi kuin vaikeampi reitti.
Ohjelmistoprojektissa kriittisiä osia ovat scouppi, eli laajuus, ja vaatimusmäärittely. Jotta nämä IT-projektin suuntaviivat parhaiten tukisivat arjessa toimivaa lopputulosta, täytyisi scouppi ja vaatimusmäärittely tehdä tiiviissä yhteistyössä liiketoiminnan ja teknisten ihmisten kanssa. On iso todennäköisyys, jos listan tekee vain liiketoimintaa tai vain teknologiaa ymmärtävät ihmiset, että alussa luettelemani madonluvut realisoituvat venyneenä projektina, joka maksaa maltaita eikä edes tehosta toimintaa.
Siilot roskiin; liiketoiminnan ja tietohallinnon yhteiset business caset tilalle
Ensimmäinen askel siilojen poistamiseen on se, että liiketoiminnan ja tietohallinnon ihmiset analysoivat yhdessä tilannetta ja miettivät, miten ongelma ratkaistaan. Nykytilanteen kartoittaminen voidaan aloittaa mallintamalla liiketoiminnan prosessit: aluksi piirretään standardin mukainen prosessikaavio, sitten selvitetään mitä ihmiset tekevät, mitä järjestelmät tekevät, mitä prosesseihin menee sisään ja mitä niistä saadaan ulos. Kun heitetään päälle sovelluskulkuja, tsekataan organisaatio, IT-arkkitehtuuri ja miten data kulkee eri sovellusten välillä prosesseissa, niin analyysin ainekset alkavat yleensä olla kasassa.
Tässä vaiheessa ei uhrata vielä ajatustakaan teknologioille, vaan lyödään miellyttäville lisenssikauppiaille kättä nenään. Kun on yhdessä selvitetty, millainen tekninen ratkaisu tai toimintatapojen muutos tilannetta voisi parantaa, aloitetaan yhdessä ratkaisun suunnitteleminen. Luodaan bisneskeissi: mitä ja miten paljon liiketoiminnan ja IT:n resursseja kehitysprojekti vaatii, ja mitkä sen elinkaarikustannukset ovat. Lasketaan ROI, jonka perusteella tiedetään, onko hanke kannattava. Osassa yrityksistä pelataan joukkuepeliä yli siilorajojen, mutta monessa organisaatiossa projekteista suoriudutaan oman osaston voimin. Maailma siilojen ympärillä kuitenkin digitalisoituu ja automatisoituu hurjaa vauhtia – mutta pysytäänkö tämän perässä?
Varmaa on, että jos haluaa pysyä yhä nopeutuvassa kehityssyklissä mukana, pelkkä holtiton perässä juokseminen ei riitä. Vauhdissa pysyäkseen on otettava hetki aikaa uudenlaisen ajattelun ja toimintatavan opettelemiseen. Automaatiomarkkina tulee kuitenkin kasvamaan kovalla käyrällä seuraavien vuosien aikana, joten ne yritykset jotka tekevät asiat oikein tulevat hyötymään kilpailua paremmin.
Kuva: Älykkään automaatiomarkkinan kasvu
2018 12,4 miljardia dollaria
2020 27,4 miljardia dollaria
2025 232 miljardia dollaria
lähde: KPMG – Ready Set Fail (2018)
Näin valjastat it-projektisi tuottamaan tulosta! – Case asiakaspalvelu
Jos bisneksen ja IT:n keskusteluyhteydessä on perustavanlaisia valuvikoja vauhdilla kasvavassa markkinassa, tarkoittaa se paitsi rahan valuttamista suoraan viemäriin, myös kissanpäiviä projekteja oikoville konsulteille. En tohtisi uhota huonojen käytäntöjen järjettömyydestä, ellen tietäisi paremmasta.
Olen saanut olla mukana kehityshankkeissa, joissa ongelmien juurisyy on kaivettu selville ennen kuin on sännätty ostamaan liian isoa laastaria ongelman peittämiseksi. Yksi erinomainen esimerkki on ulkomaisesta infra-alan yrityksestä, jossa asiakaspalvelun taso oli heikkoa, asiakaspalvelijoiden vaihtuvuus kovaa ja uusien kouluttaminen kallista ja hidasta.
Prosessien kehittäminen, prosessiajattelu ja prosessijohtaminen olivat tavoitteita, mutta asiakas ei oikein päässyt tekemisessä alkuun. Asiakasorganisaatiossa tunnistettiin ongelman olemassaolo, tehtiin strateginen päätös korjata se ja tilattiin analyytikot paikalle. Edustamani firma alkoi purkamaan tilannetta käymällä ”liiketoimintatuskan” läpi alkuun liikejohdon kanssa. Tämän jälkeen menimme syvemmälle organisaatioon ja analysoimme kipupisteet sen prosessiomistajan kanssa. Juurisyyt ongelmille löysimme työntekijöiden vieressä istuen ja heidän työskentelyään seuraten.
Ilmeni, että ERP-järjestelmä oli uudelle työntekijälle liian monimutkainen ja vaikea käyttää. Asiakaspalvelutilanteessa järjestelmästä tarvittiin vain pieni tieto tai ruksaus, mutta asian tekeminen oli monen mutkan takana. Asiakaspalvelijalla kesti kuukausia oppia käyttämään ERP-järjestelmää tehokkaasti. Pitkän oppimisajan ja korkean henkilöstön vaihtuvuuden yhtälö rapautti asiakaspalvelun tason.
”Strategiseksi tavoitteeksi asetettiin tulla oman alansa parhaaksi asiakaspalveluorganisaatioksi. Tämä strateginen linja ohjasi myös liiketoimintaprosessien kehittämistä. ”
Asiakasorganisaatiossa ymmärrettiin prosessilähtöisen ajattelun arvo. Strategiseksi tavoitteeksi asetettiin tulla oman alansa parhaaksi asiakaspalveluorganisaatioksi. Tämä strateginen linja ohjasi myös liiketoimintaprosessien kehittämistä. Organisaatioon perustettiin monitaitoinen tiimi, jossa oli johdon sponsori, liiketoiminnan ja tietohallinnon edustajia sekä ulkopuolisia konsultteja, joilla oli vastaavista projekteista kokemusta. Yhdessä löytyi ratkaisu, joka ei ollut ERP-järjestelmän kallis ja monimutkainen kustomointi, vaan ERP:n käyttäminen asiakaspalvelun osalta tietovarastona prosessimoottorille, joka yksinkertaisti, tehosti ja ohjasi asiakaspalvelijoiden työtä.
ERPin ympärille rakennettiin ketterästi prosessikerros, jossa oli mahdollisimman helppo käyttöliittymä. Asiakaspalvelijan näytöllä näkyivät ainoastaan ne asiat, joita hän asiakkaansa palvelemiseksi tarvitsi. Uudet asiakaspalvelijat omaksuivat uuden käyttöliittymän muutamassa tunnissa useamman kuukauden sijaan. Asiakaspalvelun taso, läpimenoajat ja asiakastyytyväisyys kasvoivat rinta rinnan yhtä jyrkässä käyrässä.
Kyseisessä tapauksessa noudatettiin prosessijohtamisen metodia: tehtiin strategiset linjaukset siitä, mitä halutaan saavuttaa. Tämän jälkeen rauhassa analysoitiin nykytilanne yhdessä bisneksen ja IT:n kanssa ja perustettiin tiimi, jossa oli mukana työntekijöitä kaikilta osa-alueilta. Mietittiin ratkaisua yhdessä: mikä on paras tekninen ratkaisu ja miten toimintaa täytyy muuttaa. Tämän jälkeen laskettiin business case, se todettiin hyväksi ja toteutettiin ketterä IT-projekti. Tämä kaikki tapahtui muutamassa kuukaudessa, jonka jälkeen myös bisneskeissi toteutui, ja hankkeelle asetetut strategiset tavoitteet saavutettiin.
Edelleen lämmittää sydäntä ajatella kyseisen kaltaisia hankkeita.
Piditkö tästä artikkelista? Saattaisit olla kiinnostunut myös näistä prosessijohtamiseen liittyvistä artikkeleista:
- Viisi vinkkiä onnistuneeseen RPA-projektiin
- Ei mittausta, ei tulosta – prosessikehitys ilman mittausta takaa epäonnistumisen
- Ohjelmistorobotiikan skaalaaminen — mikä siinä on niin vaikeaa?
- Prosessimoottori ohjaa yrityksesi parempii tuloksiin
Tutustu prosessikehityksen palveluihimme ja muihin palveluihimme.

Veli-Pekka, eli tuttavallisemmin Vepe on toiminut pitkään IT- ja teknologia-aloilla. Viimeiset vuodet hän on ollut prosessikonsulttina Hollannissa ja Suomessa. Vepellä on tausta liiketoimintapuolella, mutta hän ei ole omien sanojensa mukaan ”ihan täysi puusilmä” myöskään teknisissä asioissa. Vepe on tehnyt konsultin hommia pörssifirmoista pieniin putiikeihin ja hallitustason strategisesta neuvonannosta ruohonjuuritason prosessien kuvantamiseen sekä vaatimusmäärittelyyn. Näkemystä ja osaamista siis löytyy. Nuorena miehenä Vepe on myynyt olutta karaokekuppilassa, sekä tehnyt myös portsarinhommia. Tämän seurauksena hän osaa tarvittaessa laulaa ja pitää seuraa.

Ota yhteyttä, jos haluat keskustella tarkemmin:
Outi Mattila, Head of Process Development, outi.mattila@solidabis.com / +358 40 900 2802