Tietoja Teemu Leppänen

Teemu Leppäsellä on vahva kokemus vaativista liiketoiminnan tietojärjestelmistä ja kymmenistä suurille organisaatioille toteutetuista IT-projekteista. Koulutukseltaan Teemu on tekniikan tohtori ja diplomi-insinööri (TKK). Teemun perustama Cheetah Consulting Oy on liiketoiminnan tietojärjestelmiin liittyvään neuvonantoon ja IT-toimittajayhteistyön kehittämiseen erikoistunut yritys. Yritys tarjoaa kokonaisvaltaista, toimittajista riippumatonta palvelua pohjautuen kattavaan teknologia-, projekti- ja liiketoimintaosaamiseen

Onko tavoitteenasi IT:n tuottavuus vai tehokkuus?

Edellisessä blogissani kirjoitin IT-hankintojen arvioimisesta kolmen keskeisen kriteerin eli laadun, kustannusten ja riskitason kannalta. Tässä blogissa käsittelen IT:n laatua, jossa voidaan erottaa kaksi ulottuvuutta: tehokkuus ja tuottavuus. Käytännön kannalta voidaan ajatella, että tehokkuus liittyy IT-projektin (= järjestelmän aikaansaamiseksi tehtävä työ) laatuun ja toisaalta tuottavuus liittyy IT-ratkaisun (= tekninen tietojärjestelmä) laatuun.

Ensimmäinen laadun ulottuvuus, tehokkuus, liittyy siihen, että tehtäväksi päätetyt asiat tehdään oikein (”do the things right”). Tehokkuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-projektin pysyminen aikataulussa, parhaiden käytäntöjen mukainen tekninen työ (esim. toteutettavan IT-ratkaisun ylläpidettävyys ja skaalautuvuus) sekä riittävä ratkaisun toiminnallisen laadun varmistaminen kattavalla ja järjestelmällisellä testauksella.

Toinen laadun ulottuvuus, tuottavuus, liittyy siihen, että lähtökohtaisesti suunnitellaan tehtävän oikeita asioita (”do the right things”). Tuottavuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-ratkaisun toimintojen kattavuus ja helppokäyttöisyys, järjestelmässä käsiteltävän tiedon oikeellisuus sekä investoinnin takaisinmaksuajan (business case) toteutuminen konkreettisten hyötyjen kautta.

Seuraavaksi kaksi projektiesimerkkiä, joista ensimmäisessä on haasteita tehokkuuden ja jälkimmäisessä tuottavuuden kanssa.

Arevan Olkiluotoon rakentama ydinreaktori oli vuonna 2013 myöhästymässä seitsemän vuotta (YLE). Projektin tilanne oli seurausta tehokkuuteen liittyvistä laadullisista haasteista. Projektin aikataulu venyi, koska vaadittuja asioita ei oltu tehty oikein eli tehokkaasti. Projektin haasteena ei ollut varsinaisesti tuottavuus, koska projektin tuotoksena lopulta saatiin toimiva ja vaatimukset täyttävä ydinvoimala. Osin nimenomaan tuottavuuteen liittyvän riskin minimointi (eli sen välttäminen, että saadaan epäluotettavasti toimiva ydinvoimala) vähensi tehokkuutta. Näennäisesti projektin kustannusriski oli hallittu kiinteähintaisella sopimuksella. Mutta kai tilaajaorganisaation omien resurssien sitominen projektiin suunniteltua pidempään, investoinnin rahoituskustannukset ja menetetty sähkön myynnin liikevaihto maksoivat jotakin? Kyllä, TVO:n ja Arevan välimiesmenettelystä päätellen noin kaksi miljardia euroa.

Toinen käytännön esimerkki edustaa tuottavuuteen liittyvää laadullista haastetta. Yhdysvalloissa oli aiempina vuosina meneillään mittava armeijan ERP-järjestelmien uudistus. Viimeisimpänä ”virstanpylväänä” voidaan pitää sitä, että ilmavoimat päätti lopettaa projektinsa kesken seitsemän vuoden jälkeen. Projektin tilanne oli seurausta realisoituneesta tuottavuus-riskistä, mikä on jokaisen projektin tilaajan painajainen; joudutaan palamaan takaisin lähtöruutuun. Ilmavoimien projektin tapauksessa aikaa menetettiin noin 7 vuotta ja rahaa yli miljardi dollaria. Projektin haaste ei ollut, että lopputuloksena olisi saatu laadullisesti huonompi ratkaisu kuin mitä tavoiteltiin, vaan se, ettei saatu yhtään mitään.

Usein tuottavuuteen liittyviin haasteisiin yhdistyy myös tehokkuushaasteita, mutta ei aina. Se, että projekti ei tuota oikeita tuotoksia, ei tarkoita välttämättä sitä, etteikö tekeminen olisi itsessään voinut olla tehokasta. Esimerkiksi tehokkaasti toteutetut osakokonaisuudet voidaan saada valmiiksi ajallaan (=tehokkaasti) ja tekemään suunniteltuja asioita (=tuottavasti) kokonaisuuden silti toimimatta.

Edellä kerrotut projektiesimerkit ovat äärimmäisiä ja vastaavanlaisia tilanteita kohdataan melko harvoin. Esimerkit kuitenkin auttavat konkreettisesti ymmärtämään tehokkuuden ja tuottavuuden eron. IT-projekteissa tuottavuus on tyypillisesti tehokkuutta tärkeämpää, kun tuotettavan IT-ratkaisun hyödyt ovat merkittäviä (lyhyt takaisinmaksuaika) tai investointi on erittäin suuri (ei varaa epäonnistua). Tehokkuus on puolestaan usein tuottavuutta tärkeämpää, kun projektin tuotos on liiketoiminnan kannalta vähämerkityksellinen (kunhan se toimii) tai projekti nähdään suurena kulueränä (tiukka ja suurehko budjetti).

Tarvitsetko apua tai haluaisitko kysyä neuvoa IT-projekteihin tai -hankintoihin liittyen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Suuri, suurempi, IT-projekti…

Projekti on olemassaoloajaltaan ja resursseiltaan rajattu tilapäinen organisaatio, joka tuottaa määritetyt tuotokset. Juuri ajan ja resurssien rajallisuuden takia yksi projektinhallinnan tärkeimmistä osa-alueista on projektin laajuuden hallinta (scope management). Se tarkoittaa projektin tuotosten (deliverables) riittävän tarkkaa määrittelyä (projektin alussa) ja rajaamista (projektin aikana).

Panostus projektin laajuuden hallintaan on kriittistä projektin onnistumiselle, koska projektin laajuuteen sisältyvien tuotosten lukumäärän lisääminen tai monimutkaistaminen kasvattaa projektin laajuutta. Projektin laajuuden kasvattamisella on lähes poikkeuksetta vaikutusta projektin budjettiin ja aikatauluun. On yhtä tärkeää (tai jopa tärkeämpää) määritellä, mitä projektin laajuuteen ei sisälly kuin mitä siihen sisältyy. Yhden projektin laajuuteen sisältymättömät tuotokset voivat sisältyä toisen projektin laajuuteen.

IT-projektin tuotos on usein käyttöönotettu tietojärjestelmä. IT-projektin laajuuden voi määritellä esimerkiksi sen mukaan, mitä ominaisuuksia tietojärjestelmä tarjoaa käyttäjälle tai mitä tehtäviä (työtä) projektiin kuuluu. Esimerkiksi CRM-järjestelmän toteuttavan projektin laajuuteen voi sisältyä asiakkaiden yhteystietojen hallinta (=ominaisuus) ja asiakas master datan laadun parantaminen (=tehtävä), kun taas CRM:n integraatio ERP:hen (=ominaisuus) ja järjestelmän suorituskykytestaus (=tehtävä) voivat olla projektin laajuuden ulkopuolella.

Juuri IT-projektien riittävän tarkan määrittelyn haastavuuden takia ennen projektin aloittamista IT-projekteissa on usein kova paine projektin laajuuden kasvamiselle projektin aikana. IT-projektin laajuutta määriteltäessä on hyödyllistä tarkastella sitä kolmesta näkökulmasta:

  • liiketoiminnallinen laajuus (business scope)
  • prosessilaajuus (process scope)
  • tekninen laajuus (technical scope)

IT-projektin liiketoiminnallinen laajuus kuvaa projektin tuotoksia liiketoiminnan tavoitteiden ja tarpeiden kannalta. Esimerkki projektin liiketoiminnallisesta laajuuden määrittelystä voisi olla asiakastilausten syöttäminen asiakaskäynnin yhteydessä.

IT-projektin prosessilaajuus kuvaa projektin tuotoksia toiminnallisuuksien ja vaatimusten kannalta. Esimerkki projektin prosessilaajuuden määrittelystä voisi olla asiakkaan pyytämien tuotteiden varastosaldojen tarkastaminen ERP-järjestelmästä.

IT-projektin tekninen laajuus kuvaa projektin tuotoksia IT-arkkitehtuurin, toimintojen ja konfiguraatioiden kannalta. Esimerkkejä projektin teknisen laajuuden määrittelystä voisivat olla sovelluksen käytettävyys Android-älypuhelimella tai vaikkapa asiakastilauksen two-phase commit ERP-järjestelmään (tilaus tallennetaan vain, jos kaikki tilausrivit voidaan täyttää suoraan varastosta).

Tyypillisimmät IT-projektien laajuuden hallinnan haasteet johtuvat siitä, että projektin laajuus on projektin ohjausryhmän kannalta selkeintä linjata korkeammalla tasolla (liiketoiminnan laajuus). Toisaalta projektin onnistumisen kannalta projektin laajuus on kriittisintä määritellä prosessitasolla ja laajuutta on kriittisintä rajata teknisellä tasolla.

Seuraavat IT-projektin laajuuden hallinnan tasoihin liittyvät haasteet ovat tyypillisiä:

  • jos projektin liiketoiminnallista laajuutta korostetaan, projektin prosessilaajuutta ja teknistä laajuutta on vaikea määritellä ja rajata (koska ”kaikki” sisältyy liiketoiminnalliseen laajuuteen)
  • jos projektin prosessilaajuutta ei määritellä tarpeeksi tarkasti, sitä on vaikea rajata projektin aikana, kun ilmenee uusia tarpeita ja kehitysideoita (koska ei ole riittävän tarkkaa lähtökohtaa)
  • jos projektin teknisen laajuuden rajaamiseen ei kiinnitetä tarpeeksi huomiota, tuloksena voi olla tilanteesta riippuen joko liian yksinkertainen (käyttökelvoton) tai liian monimutkainen (tarpeeton) tekninen ratkaisu (koska ei huomioida projektin laajuuden ylempiä tasoja).

Projektin laajuuden hallinnan tärkeys korostuu erityisesti jo lähtökohtaisesti laajuudeltaan suurissa projekteissa, riippuvuuksien hallinnassa projektien välillä sekä projekteissa, joiden toteutukseen osallistuu useita toimittajia. Projektipäälliköltä vaaditaan huolellista projektin laajuuden muutosten hallintaa (change control) ja projektin ohjausryhmältä ymmärrystä kaikista kolmesta projektin laajuuden tasosta. Näin päätökset projektin laajuuden muutoksista voidaan tehdä perustellusti.

Tarvitsetko apua IT-projektissa tai etsitkö koulutusta IT-projektien parissa työskenteleville ammattilaisille? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

”Oho”, sanoi IT-asiantuntija

IT-asiantuntijan tehtävä: Pankin suurtietokoneen (mainframe) CA-7 eräajo-ohjelmiston rutiinipäivitys. Asiantuntijatyön lopputulos: Inhimillinen virhe ja arviolta 100 miljoonan euron suorat kustannukset ja korvausvaatimukset pankille, jonka 17 miljoonaa asiakasta eivät pystynyt käyttämään pankkitilejään viiteen päivään. Tällaisia IT-haasteita koki vuoden 2017 juhannusviikolla Iso-Britanniassa The Royal Bank of Scotland (RBS) pankki.

RBS:n pääjohtaja Stephen Hester on liiketoimintajohdolle tyypillisesti päässyt valittelemaan tapahtunutta: ”Asiat menevät joskus pieleen. Asiat menevät pieleen IT:n kanssa.” On luontevaa selitellä jälkikäteen ikään kuin mitään ei olisi ollut tehtävissä ja vedota IT-asioissa ”force majeure”-ajatteluun. Todellisuudessa kuitenkin oikein suoritetuilla laadun (quality management) ja riskien hallinta (risk management) toimenpiteillä sekä selkeällä IT-hallinnointimallilla (IT governance model) voidaan kustannustehokkaasti ehkäistä sellaisten riskien realisoituminen, joilla on potentiaaliset 100 miljoonan euron kustannukset.

Ohjelmistopäivityksen onnettomaan lopputulokseen ovat todennäköisesti vaikuttaneet ainakin tehtävän tyyppi (rutiinitehtävä), tehtävän määrittely (epäselvät toimintatavat), tehtävä suorittajan osaaminen (puutteellinen), tehtävän suorittamisen olosuhteet (kiire), tehtävän hallinnointi (epäselvät vastuut), tehtävän riskikategoria (väärin arvioitu) sekä tehtävän laatukriteerit (puutteellisesti hallittu).

Käytännössä tapahtumassa oli kyse siitä, että eräajo-ohjelmiston päivitys ei syystä tai toisesta onnistunut. Julkinen tarina ei kerro, oliko päivityksen toimivuus ennen tuotantoympäristöä varmistettu testiympäristöissä. Oli tai ei, niin joskus IT:n kanssa tulee yllättäviä ongelmia ja niihin vain pitää varautua. Päivityksen epäonnistumisen jälkeen palautusohjeistusta (roll-back procedure) ei noudatettu, vaan jostain syystä asiantuntija poisti järjestelmästä 100 miljoonaa jonossa odottavaa transaktiota (tilisiirtoa) ja ilmeisesti myös eräajo-ohjelmiston koko konfiguraation.

Julkinen tarina ei myöskään kerro, oliko palautusohjeistusta ylipäätään laadittu, oliko se ymmärrettävä ja tunsiko asiantuntija kyseisen ohjeistuksen. Ongelman laajuuden selviämisen jälkeen ympäristöön piti asentaa toimiva versio CA-7-ohjelmistosta, ohjelmiston konfiguraatio piti tehdä uudelleen ja tuhotut transaktiot piti palauttaa jonoon. Samalla jonossa olevien transaktioiden määrä kasvoi noin 100 miljoonalla päivässä. Lisähaasteen selvitykseen toi se, että transaktiot piti ajaa tileille alkuperäisessä järjestyksessä (tuhotut tiistain transaktiot ennen keskiviikon transaktioita jne.). Kolmen päivän päästä eräajojen tekniset ongelmat oli korjattu, mutta transaktioiden järjestyksessä oli edelleen korjattavaa.

Iso-Britanniassa RBS:n IT-ongelmat ovat herättäneet keskustelua paitsi pankin asiakkaille aiheutuneista käytännön haitoista, myös RBS:n vuonna 2010 tekemästä päätöksestä siirtää IT-toimintojaan Intiaan. RBS:lta aiemmin irtisanotut isobritannialaiset IT-asiantuntijat ovatkin kärkkäästi kommentoineet julkisuudessa, että nyt kohdatut ongelmat ovat väistämätöntä seurausta RBS:n johdon aiemmista päätöksistä luopua paikallisesta edistyneestä IT-osaamisesta, jolla oli kymmenien vuosien kokemus kyseisistä tietojärjestelmistä. RBS on jyrkästi kiistänyt, että intialaisilla olisi mitään tekemistä ongelmien kanssa. Eihän IT-asioissakaan ole kyse olekaan siitä kuka tekee vaan siitä mitä ja miten tehdään.

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #5: toimittajalukko

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta hankkeen valmistelussa ja toimittajavalinnassa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta). Kerron tyypillisistä IT-hankintoihin liittyvistä haasteista, mistä ne johtuvat ja miten sudenkuopat voidaan välttää. Haasteisiin voivat vaikuttaa sekä IT-toimittajan yksipuolinen oman etunsa ajaminen että ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun aiemmissa blogeissa käsitellyt IT-hankinnan sudenkuopat on onnistuttu välttämään, toteutettavalla IT-ratkaisulla on todellisen asiakastarpeen mukainen laajuus, realistinen projektisuunnitelma, projektin tavoitteisiin sitoutuneet pätevät tekijät sekä hyvin organisoitu toimittajajoukko. IT-hankintojen viides sudenkuoppa toimittajalukko liittyy siihen, miten tietojärjestelmäkokonaisuus toteutetaan säilyttäen joustavuus, mahdollisuudet muutoksiin sekä antamatta millekään toimittajalle liian vahvaa asemaa.

Toimittajalukko-sudenkuoppaan voidaan ajautua, jos asiakas ei sopimuksellisesti ja hyvin määritellyllä toimittajien ohjauksella aseta toimittajien tuotoksille ja toimintatavoille selkeitä raameja. Tällöin toimittaja saattaa tehdä joko tarkoituksellisesti tai huomaamattaan päätöksiä, jotka eivät edistä asiakkaan tietojärjestelmäkentän tai niiden hallinnoinnin joustavuutta. Pahimmassa tapauksessa tästä voi seurata jopa lukittuminen suhteessa ohjelmistoon, teknologiaan, menetelmään, organisaatioon tai jopa henkilöön. Toimittajalukko aiheuttaa useimmiten laadullisia haasteita tai kustannusten karkaamista käsistä. Mitä kauemmin toimittajalukko kestää ja mitä tiukempi se on, sitä enemmän ilmenee syitä vaihtaa toimittajaa, mutta toisaalta myös sitä haastavampaa toimittajan vaihtaminen on.

Mikä sitten aiheuttaa toimittajalukon? Se, että tietojärjestelmiin liittyvän tekemisen johtaminen on erittäin haastavaa, ja asiakkaan aktiivisen ohjauksen puuttuessa toimittajien työskentely voi joko ajattelemattomuuden tai (harvemmin) toimittajan tarkoitushakuisuuden takia ajaa tietojärjestelmän teknologiseen tai organisatoriseen toimittajalukkoon. Toisin kuin joskus ajatellaan, toimittajalukkoa ei voi välttää esim. open source –teknologioita käyttämällä tai sopimuksen irtisanomispykälät tarkasti määrittelemällä. Sen sijaan, tietojärjestelmän kehitystyö on alusta asti ohjattava asiakkaan toimesta kohti mahdollisimman läpinäkyvää ja joustavaa mallia niin teknisesti kuin toimintatapojen kannalta. Toimittajalukkoa ei myöskään voi aina kokonaan välttää. Esimerkiksi ohjelmistoja valittaessa tietojärjestelmän elinkaari voi olla yli 10 vuotta, mikä väistämättä lukitsee asiakkaan kyseiseen ohjelmistotoimittajaan tuoksi ajaksi.

Miten toimittajalukko-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. Ohjelmisto- tai laitetoimittajaa valittaessa kannattaa painottaa toimittajan mainetta, sopimuksellisia takuupykäliä, ohjelmistoja koskevaa escrow-sopimusta sekä kustannusrakenteeltaan mahdollisimman ennakoitavaa, kiinteää ja pitkää sopimista.
  2. Palvelutoimittajaa valittaessa kannattaa kirjata sopimukseen tietojärjestelmän ylläpidettävyyteen liittyviä tekijöitä (esim. ajantasainen dokumentaatio, saatavilla olevien asiantuntijoiden määrä ja osaaminen), valvoa sopimuksen noudattamista asettamalla selkeitä virstanpylväitä sekä pitää jatkuvasti tavoitteena, että on mahdollista vaihtaa palvelutoimittajaa muutamassa kuukaudessa (riippuu palvelun laajuudesta).
  3. Aina kannattaa selvittää etukäteen toimittajien tuotteiden tekniset ominaisuudet ja toimintatavat sekä ohjata tietojärjestelmäkenttää kohti avoimia rajapintoja ja parhaita arkkitehtuurikäytäntöjä sekä toimintatapoja.

IT-hankinnoissa usein tahattomastikin syntyvän toimittajalukko-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohtokokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio saa hankkeeseen riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Tarvitsetko apua IT-hankinnoissa? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #4: monitoimittajaparadoksi

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta hankkeen valmistelussa ja toimittajavalinnassa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta). Kerron tyypillisistä IT-hankintoihin liittyvistä haasteista, mistä ne johtuvat ja miten sudenkuopat vältetään. Haasteisiin vaikuttavat sekä IT-toimittajan yksipuolinen oman etunsa ajaminen että ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun aiemmissa blogeissa käsitellyt IT-hankinnan projektisuunnitteluun liittyvät sudenkuopat monimutkaistaminen, vähättely ja osaamisharha on onnistuttu välttämään, toteutettavalla IT-ratkaisulla on todellisen asiakastarpeen mukainen laajuus, realistinen projektisuunnitelma ja projektin tavoitteisiin sitoutuneet pätevät tekijät. IT-hankintojen neljäs sudenkuoppa monitoimittajaparadoksi liittyy toteutusprojektin sekä projektia seuraavan ylläpito- ja tukipalvelun organisoimiseen.

Tyypillisen suuren organisaation IT-toimittajiin lukeutuu muun muassa useita ohjelmistotoimittajia, laitetoimittajia, projektitoimittajia, sovelluspalvelutoimittajia, infrastruktuuripalvelutoimittajia, integraatiopalvelutoimittaja, työasema- ja client-sovellusten toimittajat sekä verkkopalvelutoimittaja. Ottaen huomioon toimittajien määrän ja teknologian etenemisvauhdin, kymmenet toimittajat asettavat organisaatiolle merkittävän johtamishaasteen, kun tavoitteena on saada kaikki toimittajat palvelemaan liiketoiminnan etua.

Monitoimittajaparadoksi-sudenkuoppaan voidaan ajautua, jos asiakas esimerkiksi turhautuu IT-toimittajien keskinäiseen vastuun pallotteluun tai kokee toimittajien työn johtamisen liian haastavaksi. Toinen mahdollinen syy ajautua tähän sudenkuoppaan ovat kustannuspaineet, joiden hallitsemiseksi useita sopimuksia yhdistämällä saadaan toimittajia kohtaan parempi neuvotteluasema. Monitoimittajaparadoksissa asiakkaan tavoitteena on löytää tietylle toiminnolle yksi vastuutoimittaja, nk. avaintoimittaja, jonka vastuulla on johtaa myös muita toimittajia. Paradoksi syntyy, jos keskittämisen taustalla on oletus pitää kontrolli toimittajiin ja IT:n laatu vähintään nykyisellä tasolla (tai jopa nostaa sitä), mutta samalla tehdä itse vähemmän ja maksaa vähemmän. Tämä ei kuitenkaan yleisesti ole mahdollista.

Mikä sitten aiheuttaa monitoimittajaparadoksin? Se, että tietojärjestelmiin liittyvän tekemisen johtaminen on sekä hallinnollisesti että sisällöllisesti erittäin haastavaa, ja keskittämällä toimittajia sopimuksellisesti yhden avaintoimittajan taakse osan johtamisvastuusta voi näennäisesti ulkoistaa. Kukapa asiakas ei haluaisi hankkia vaikka koko tietohallintoaan avaimet käteen? Tästä syystä toimittajat saattavatkin myyntivaiheessa olla hyvinkin myönteisiä tällaista visiota kohtaan, koska näennäisellä vastuunotolla saadaan kasvatettua sopimuksen immateriaalista arvoa. Asiakkaan täytyy kuitenkin muistaa, että toteutusvaiheessa mahdolliset lisäkustannukset tai laadun heikentymisen seuraukset kantava taho on asiakas itse. Lisäksi avaintoimittajalle keskittäminen ajaa usein kokonaisuudessaan IT:tä entistä kauemmaksi asiakkaan liiketoiminnasta, ja heikentää organisaation omaa sisällöllistä osaamista.

Miten monitoimittajaparadoksi-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. ymmärtämällä, että avaintoimittajalle keskittämällä saatava etu ulottuu lähinnä kustannusrakenteeseen ja sopimuksellisten riskien hallintaan – kokonaisuuden ja tekemisen johtamista ei voi ulkoistaa
  2. huolehtimalla, että organisaatiolla on käytössä sisäistä osaamista ja resursseja kokonaisuuden ohjaamiseen, toimittajien työskentelyn johtamiseen ja toimittajien työn laadun valvontaan
  3. varmistamalla toimittajan intressi laadun ylläpitämiseen sopimuksellisesti määrittelemällä yksiselitteiset laatukriteerit ja palvelutasot (SLA/OLA), käyttämällä osittain kiinteitä kustannusrakenteita sekä määrittelemällä selkeästi toimittajien väliset rajat sekä vastuut.

IT-hankinnoissa usein tahattomastikin syntyvän monitoimittajaparadoksi-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohtokokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio saa hankkeeseen riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Tarvitsetko apua IT-hankinnoissa? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #3: osaamisharha

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta hankkeen valmistelussa ja toimittajavalinnassa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta). Kerron näkemykseni tyypillisistä haasteista, mistä ne johtuvat ja miten sudenkuopat vältetään. Haasteisiin vaikuttavat sekä IT-toimittajan yksipuolinen etujen ajaminen että ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun aiemmissa blogeissa käsitellyt IT-hankinnan sudenkuopat monimutkaistaminen ja vähättely on onnistuttu välttämään, toteutettavalla IT-ratkaisulla on todellisen asiakastarpeen mukainen laajuus ja realistinen projektisuunnitelma. Tämän jälkeen projektiin pitää löytää resurssit eli asiantuntijat, jotka toteuttavat projektin. IT-hankintojen kolmas sudenkuoppa osaamisharha liittyykin näiden asiantuntijoiden nimittämiseen eli projektien resursointiin.

Osaamisharha-sudenkuoppaan ajaudutaan, jos projekti resursoidaan tekijöillä, joilla ei ole tarpeeksi tai oikeanlaista osaamista projektin läpi viemiseksi projektisuunnitelman mukaisesti. Parhaiden osaajien saaminen projektiin on usein haastavaa, joten tärkeää on, että resursointiin liittyvät kompromissit tehdään oikealla tavalla ja samalla tiedostetaan päätösten vaikutukset projektin aikatauluun ja laadunvarmistustarpeisiin. Osaamisharha pätee myös organisaation sisäisten resurssien osaamiseen, eikä pelkästään IT-toimittajan resursseihin.

Mikä sitten aiheuttaa osaamisharhan? Se, että projektiin tarvittavan osaamisen hahmottaminen ja tarjolla olevien resurssien osaamisen arviointi on erittäin haastavaa. Kukapa asiakas ei haluaisi projektiinsa parhaita mahdollisia osaajia? Toimittajat saattavatkin myyntivaiheessa esitellä asiakkaalle projektin tulevia toteuttajia osaavammat ja kokeneemmat resurssit. Jos asiakas tilaa projektin, resurssit muutetaan kokemattomampiin ja kokeneet resurssit katoavat vähin äänin taka-alalle.

Joskus resurssien osaamisen arvioinnissa ajaudutaan numero- ja termipeliin eli lasketaan ja vertaillaan resurssien CV:iden perusteella kokemusta kuukausissa tai etsitään tiettyjä IT-alan erikoistermejä pyrkimättä sen syvemmin tai laajemmin ymmärtämään tarvittavaa tai tarjolla olevaa osaamista. Projektit ovat aina erilaisia (vaikka olisi sama teknologia), joten myös tiimityötaidot sekä kokonaisuuksien ymmärtäminen ovat arvokasta osaamista. Harvoin ymmärretään, että asiantuntija, joka on aiemmin tehnyt teknologian X versiolla Y viisi projektia ei ole (useimmiten) viisi kertaa parempi osaaja kuin asiantuntija, joka on tehnyt samalla teknologialla vain yhden projektin ja neljä muuta projektia.

Miten osaamisharha-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. arvioimalla kattavasti resurssien kokemusta ja toiminnallista osaamista (kokemuksen kesto vs. sisältö, tekninen erikoistuminen vs. monipuolisuus, prosessiosaaminen, organisaatio-osaaminen)
  2. ottamalla huomioon myös resurssien ei-toiminnallinen osaaminen (tiimityö, viestintä, projektityö, kokonaisuuksien ymmärtäminen) sekä motivaatiotekijät (asenne, oppimishalu, oppimiskyky)
  3. valitsemalla ja sitouttamalla projektin avainhenkilöt (esim. projektipäälliköt, ratkaisun tekninen omistaja, laadunvarmistusroolit) sekä sopimuksellisilla että johtamistekijöillä.

IT-hankinnoissa usein tahattomastikin syntyvän osaamisharha-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohtokokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio saa hankkeen valmisteluun riippumattoman näkökulman, jolla varmistetaan hankkeen onnistuminen.

Tarvitsetko neuvoa IT-hankinnoissa ja haluatko varmistaa IT-hankintojen onnistumisen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #2: vähättely

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta (ks. Riippuvaisen IT-toimittajan keittokirjasta). Esittelen IT-toimittajien usein käyttämien kikkojen sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Ongelmiin myötävaikuttavat myös ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun toteutettavan ratkaisun laajuuteen liittyvä IT-hankintojen ensimmäinen sudenkuoppa monimutkaistaminen on vältetty, seuraavaksi pitää suunnitella, miten varsinainen toteutusprojekti ja tekeminen suunnitellaan. Laajuuden ja laadullisten tavoitteiden lisäksi projektilla on määritelmän mukaisesti aikataulu (kalenteriaikaa) ja budjetti (euroja). IT-hankintojen toinen sudenkuoppa onkin aikataulun ja/tai budjetin vähättely eli aliarviointi: toteutukseen varataan vähemmän aikaa tai euroja kuin mikä on realistisesti mahdollista. Kuten mediasta on voinut seurata, IT-projektien aikataulujen venähtäminen kaksin-, kolmin- tai nelinkertaiseksi alkuperäisestä suunnitelmasta ei valitettavasti ole niin harvinaista, kuin se voisi olla, mikäli IT-projektien laadun- ja riskienhallinnasta tehtäisiin kunnolla.

Miksi sitten toimittaja tarjoaisi asiakkaalle epärealistista projektisuunnitelmaa? Siksi, että projektisuunnitelman realistisuuden arviointi on ennen ratkaisun toteutustyön aloittamista toimittajalle ja etenkin asiakkaalle erittäin haastavaa. Jos taas toimittaja kysyy asiakkaalta, suunnitellaanko projektin kestoksi kolme kuukautta korkealla riskitasolla vai kuusi kuukautta matalalla riskitasolla, asiakkaan vastaus on (useimmiten): yritetään tehdä kolmessa kuukaudessa ja jossei tule valmista, niin sitten pidennetään projektia kolmella kuukaudella. Käytännössä tästä on lopputuloksena, että projektin lopullinen kesto asettuu tehottomuuksien takia 7-9 kuukauden välille riippuen siitä kuinka paljon ensimmäisen kolmen kuukauden aikana tehdystä työstä on tuottanut käyttökelpoisia tuotoksia.

Jos asiakas haluaa projektin valmiiksi ”mahdollisimman pian” ja ”mahdollisimman halvalla” (kukapa ei haluaisi), tämä asettaa IT-toimittajan ja asiakkaan yhteistyölle valtavat paineet ajautua vähättely-sudenkuoppaan. Tarjousprosessit vaativat IT-toimittajilta merkittäviä panostuksia, joten asiakkaan vaatiessa epärealistisia vaatimuksia, aikatauluja tai budjetteja, IT-toimittajalla on suuri kiusaus luvata nyt ja selvitellä myöhemmin. Projektin kustannusbudjetista voidaan toki neuvotella toteutusvaiheen aikana ja siihen voidaan liittää sopimusehtoja riskien siirtämiseksi asiakkaalta toimittajalle, mutta mikään ei tuo menetettyä kalenteriaikaa takaisin.

Miten vähättely-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. tekemällä työmäärien arviointi ja projektisuunnittelu parhaiden käytäntöjen mukaisesti (mm. aika vs. pisteet, työnopeus, top-down, bottom-up, koordinaatiohukka, projektointi),
  2. eriyttämällä kaupalliset sopimusneuvottelut asiantuntijoiden arviointityöstä ja muodostamalla asiakkaan ja toimittajan välille yhteisymmärrys projektin aikatauluun ja budjettiin liittyvistä riskeistä,
  3. yhteistyöhön ohjaavat sopimukselliset win-win-ehdot (esim. kiinteähintaiset elementit, kustannusbudjetin bonus/malus, myöhästymissakko, time-boxing, takuut)

IT-hankinnoissa usein tahattomastikin syntyvän vähättely-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohto kokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio voi tehostaa viestintää IT-toimittajien kanssa ja saada hankkeeseen riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Tarvitsetko apua IT-hankinnoissa? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #1: monimutkaistaminen

Esittelin aiemmassa blogissa Riippuvaisen IT-toimittajan keittokirjasta käytännön haasteita, joita kohdataan erityisesti riippumattoman neuvonannon puuttuessa IT-ratkaisuiden hankinnoista. Tässä ja muutamassa seuraavassa blogissa esittelen tarkemmin riippuvaisten IT-toimittajien usein käyttämien kikkojen sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Useimmat IT-toimittajat eivät johda asiakastaan tarkoituksellisesti harhaan. Ongelmiin myötävaikuttavat myös ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Uutta tietojärjestelmää hankittaessa monimutkaistaminen on usein ensimmäinen eteen tuleva sudenkuoppa, johon on vaara ajautua. Kyse on siitä, että IT-toimittaja tarjoaa asiakkaalle monimutkaisempaa ratkaisua kuin asiakas oli alunperin ajatellut hankkivansa ja todellisuudessa olisi asiakkaan etu. Ratkaisun monimutkaisuus voi syntyä esimerkiksi laajemmasta toiminnallisuudesta, edistyneemmästä teknisestä toteutuksesta tai heikosta sopivuudesta kokonaisarkkitehtuuriin. Joka tapauksesa ratkaisun monimutkaisuus vähentää sen luotettavuutta ja kustannustehokkuutta.

Miksi sitten toimittaja tarjoaa monimutkaisempaa ratkaisua asiakkaalle? Siinä, missä asiakkaan etu on saada liiketoimintatarpeen täyttävä, luotettava ja kustannustehokas ratkaisu, IT-toimittajan yksioikoinen etu on myydä ratkaisu, jonka toteuttaminen ja ylläpito vaativat mahdollisimman paljon laskutettavaa työtä. Tähän tavoitteeseen toimittaja pääsee monimutkaistamalla. Monimutkaistaminen tapahtuu huomaamatta, koska ratkaisun luotettavuuden ja kokonaiskustannuksen (total cost of ownership) arviointi ennen ratkaisun toteutustyön aloittamista ja osin myös toteutuksen jälkeen on erittäin haastavaa.

Varsinkin silloin, kun tietojärjestelmähanke on liiketoimintakriittinen ja investointina suuri, niin myös liiketoimintajohto on mukana hankinnassa. Kun kyseessä voi olla yrityksen tärkein IT-investointi vuosikymmeneen, asiakas joskus jopa haluaa kuulla IT-toimittajalta, että ratkaisua voidaan laajentaa uusilla toiminnallisuuksilla, joita ei alun perin ollut otettu huomioon määrittelyssä. Koska asiakkaan odotuksena on, että hankkeesta tulee suuri ja haastava, toimittaja mielellään ruokkii tätä odotusta tarjoutumalla toteuttamaan ratkaisun teknisesti edistyneemmin (esim. korkean käytettävyyden arkkitehtuurilla (high availability architecture, HA) tai geneerisin palvelurajapinnoin (service-oriented architecture, SOA)).

Miten monimutkaistaminen voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. tekemällä ratkaisun vaatimusmäärittely toimittaja- ja teknologiariippumattomasti sekä liiketoimintalähtöisesti (sis. toiminnalliset ja ei-toiminnalliset vaatimukset),
  2. arvioimalla tarjousvaiheessa toimittajien vaatimusmäärittelyyn ehdottamat laajennukset / muutokset sekä ratkaisun luotettavuuden että projektitoteutuksen kustannustehokkuuden kannalta,
  3. panostamalla projektityöskentelyn tuottavuuteen ja tehokkuuteen sekä laadun ja riskien hallintaan edistyneiden teknisten ratkaisuiden sijaan (jos tekniset ratkaisut eivät kriittisesti arvioiden läpäise listan kohtaa 2).

IT-hankinnoissa usein tahattomastikin syntyvän monimutkaistamis-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää määrittely- ja hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohto kokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio voi tehostaa viestintää IT-toimittajien kanssa ja saada hankkeen valmistelu- ja toteutusvaiheisiin riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Tarvitsetko neuvoa IT-hankinnoissa ja haluatko varmistaa IT-hankintojen onnistumisen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Riippuvaisen IT-toimittajan keittokirjasta…

Sitra teetti suurella palvelutoimittajalla selvityksen, kuinka Suomessa voitaisiin yhtenäistää terveydenhuollon potilastietojärjestelmät ostamalla ulkomailta valmis järjestelmä. Selvityksessä parhaiten tarkoitukseen soveltuvaksi todettiin Epic-ohjelmisto. Myöhemmin selvisi, että selvityksen tehnyt palvelutoimittaja on merkittävä asiakkaalle suosittelemansa Epic-ohjelmiston toimittaja, ja jopa ainut mahdollinen toimittaja Suomessa.

”Riippumaton” selvitys, jossa päädytään selvityksen tehneen toimittajan omaan ratkaisuun on IT-toimittajien vanha kikka. Toinen pidemmälle viety versio samasta kikasta on ratkaisun vaatimusmäärittely ”riippumattomasti” – siis tarkoituksena määritellä vaatimuksia, ei vielä tehdä teknologiavalintaa. Vaatimusten valmistuttua joudutaan monesti toteamaan, että oikeastaan vain vaatimusmäärittelyn tehnyt toimittaja ymmärtää asiakkaan vaatimusten sisällön, ja että yllättäen vaatimukset tehneen toimittajan projektitarjous täyttää vaatimukset parhaiten. Tämän jälkeen toimittajavalinta onkin sitten helppo.

Muita asiakkaan kokonaisedun vastaisia kikkoja IT-toimittajan keittokirjasta:

  • monimutkaistaminen (ratkaisun tarpeeton monimutkaistaminen ja / tai kasvattaminen)
  • vähättely (budjetin ja / tai aikataulun aliarviointi)
  • osaamisharha (toimittajan ja / tai asiakkaan osaamisen yliarviointi)
  • monitoimittajaparadoksi (avaimet käteen, mutta 100 % kontrolli alihankkijoihin)
  • toimittajalukot (suljetut rajapinnat, teknologia ja/tai toimintatavat)

Nämä termit eivät ole vakiintuneita, vaan allekirjoittaneen itse keksimiä. Käyn tulevissa blogeissa läpi termien sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Vaikka nämä ovatkin toimittajien kikkoja, on tärkeä ymmärtää, että ongelmien välttämisessä on keskeistä myös ostavan tahon puolella vallitsevan vääristyneen ajattelutavan korjaaminen tai osaamisen kehittäminen. Kaikki IT-työ on toimittajan ja asiakkaan yhteistyötä, ja tärkeää on huomioida molempien osapuolten intressit.

Suurin osa IT-toimittajista ei tarkoituksellisesti johda asiakastaan harhaan, mutta ohjelmisto- tai palvelutoimittajan näkökulma on väistämättä rajoittunut ja intressit asiakkaan kanssa osin ristiriitaiset. Olipa organisaatiossa työn alla sitten tarvekartoitus, vaatimusmäärittely, toimittajavalinta, projekti tai palvelutuotannon kehittäminen, hankkimalla aidosti riippumatonta neuvonantoa organisaatiot voisivat välttää yllämainitut sudenkuopat, ja tehdä kokonaisvaltaista IT:n laadun, kustannusten ja riskien hallintaa.

Tarvitsetko apua IT-projektin läpiviemisessä tai kaipaatko muita neuvoja IT-projekteihin liittyen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Valhe, emävalhe, IT-KPI?

Usein sanotaan, että et voi johtaa, mitä et mittaa. Tämä pätee myös IT-projekteihin, tietojärjestelmiin ja tietohallintoon. Hyvin valittuja ja jalkautettuja mittareita (Key Performance Indicator, KPI) seuraamalla voidaan varmistaa, että tiettyyn IT-projektiin, IT-palveluun tai tietojärjestelmään sijoitetut resurssit tuottavat odotettuja tuloksia odotetulla riskitasolla. Jotta KPI:sta saadaan maksimaalinen hyöty, organisaation tavoitteisiin ja toimintatapoihin kytkeytyvien KPI:den valitseminen ja määrittely tulee tehdä huolellisesti.

Yleisimmin käytössä olevat IT-KPI:t liittyvät kustannus- ja aikatauluseurantaan tai esimerkiksi toimittajasopimusten kriteereihin, kuten tietojärjestelmän palvelutasoon tai tukipalvelun vasteaikoihin. Varsinainen hyöty KPI:sta syntyy laajentamalla mittaristo kattamaan myös tietohallinnon muita tavoitteita sekä määrittelemällä seuranta- ja raportointiprosessi KPI:den ympärille.

KPI:ta voidaan luokitella ylätason kategorioihin esim. IT:n liiketoimintahyödyn (strateginen, taktinen, operatiivinen), IT-elinkaaren vaiheen (konsepti, projekti, palvelu) tai raportin käyttäjän (liiketoimintajohto, IT-johto, IT-päällikkö) mukaan. Organisaation tavoitteita vastaava mittaroinnin kehittämisen painopistealue on hyvä määritellä KPI-kategorian tasolla. Kun fokus on selvillä, olemassa olevia viitekehyksiä ja KPI-kirjastoja voidaan käyttää pohjana organisaatiolle parhaiten sopivien KPI:den määrittelemiseksi.

KPI:t eroavat muusta raportointitiedosta niiden jalostusasteen ja kontekstuaalisuuden kautta. KPI:t jalostetaan saatavilla olevasta tiedosta siten, että ne tiivistävät tietyn toiminnon tavoitteiden kannalta keskeiset tiedon yhteen tai muutamaan arvoon (esim. satojen erillisten numerojen sijaan). Toisaalta, KPI:hin liittyy aina konteksti, joka kertoo onko KPI:n arvo tavoitetason yläpuolella vai alapuolella, ja kuinka paljon (esim. meneekö hyvin vai erittäin hyvin).

KPI:den haasteet liittyvät usein esimerkiksi tiedon laatuun tai mittarointiprosessin jalkauttamiseen. Mittaroinnin keskeisin tavoite on tuottaa tietoa päätöksenteon tueksi. Tätä tavoitetta ei saavuteta, jos KPI-arvot eivät ole uskottavia raportin käyttäjälle (validiteetti) tai luvut heittelevät viikosta toiseen (reliabiliteetti). Tällöin voidaan ajautua tilanteeseen, jossa KPI:t eivät toimikaan tehokkaan viestinnän ja johtamisen välineenä, vaan ovat jatkuvan väittelyn kohteena esimerkiksi niiden vaikean tulkitsemisen tai epäluotettavuuden takia.

Reliabiliteetti ja validiteetti ovat erityisesti haasteena, jos mittarointia lähdetään kehittämään liian massiivisesti (mahdollisimman paljon KPI:ta) tai työkalukeskeisesti (mahdollisimman visuaalisia raportteja). Tällöin oikeiden KPI:den valitseminen ja tehokas raportointi- ja seurantaprosessin jää liian vähälle huomiolle. Lisäksi KPI:iden tulkinnanvaraisuuksia ja keskinäisiä riippuvuuksia ei tällöin useinkaan ymmärretä tarpeeksi hyvin korjaavia toimenpiteitä ja johtamista varten.

Hyvin määriteltyjen ja jalkautettujen KPI:den avulla yritys voi seurata suunnitelmien ja budjettien toteutumista, hallita suorituskykyä ja riskejä sekä varmistaa korjaavien kehitystoimenpiteiden vaikutukset. KPI:sta on suurta hyötyä myös toiminnan tavoitteiden asettamisessa ja viestinnässä IT:n suorituskyvystä organisaatioin eri sidosryhmille.

Tärkeintä on muistaa, että IT:n mittarointiinkin pätee: sitä saa mitä mittaa.

Tarvitsetko apua IT-projektien mittaamiseen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.