Mikä IT-projekteissa oikein maksaa?

Klassisessa Kummeli-sketsissä (YouTube) rakennustyömaan vastaava mestari neuvoo määrätietoisin ottein ahkeria, mutta taitamattomia rakennusmiehiä. Alkuvaiheessa rakennusmiesten virheet aiheuttavat tehottomuutta: ”Tääl on poijaat sisällä niin paljon romua vielä, ettei näitä pääsisäänkäynnin laseja olis vielä missään nimessä pitänyt laittaa.” Työmaan edetessä virheet vaativat jo kalliimpia korjauksia: ”Nää LVI-putket piti tulla tonne kattoon betonin sisään.” Lopulta farssi kärjistyy virheeseen, joka ei ole edes korjattavissa: ”Se on poijjaat nyt kolmekymmentä metriä sivussa. Koko toi talo!” Kuulostaako tutulta? Ethän toivottavasti ole itse koskaan joutunut IT-projektissa hämilläsi tokaisemaan virheen ilmetessä: ”Selvä!”

Tuhansista satoihin tuhansiin tehtäviin

IT-projektissa projektitiimin jäsenet suorittavat projektin koosta riippuen tuhansia tai jopa satojatuhansia tehtäviä, jotka projektisuunnittelussa ketjutetaan tehtävien välisten riippuvuuksien perusteella (tietyt tehtävät on suoritettava ennen muita). Peukalosääntönä voidaan arvioida, että yhtä projektiin tehtyä henkilötyöpäivää (htp) kohden suoritetaan noin 2 – 10 erillistä tehtävää. Jokaisella tehtävällä on vaikutus jonkin seuraavan tehtävän suorittamiseen tai suoraan lopputulokseen.

”Miljoonan euron IT-projektissa tehtävien määrä voi nousta jopa useisiin kymmeniin tuhansiin.”

Edellinen tarkoittaa, että esimerkiksi budjetiltaan miljoonan euron IT-projektissa tehtävien määrä voi nousta jopa useisiin kymmeniin tuhansiin. Syntyvien virheiden määrän kertoo laatuprosentti eli se kuinka moni tehtävä suoritetaan ilman virheitä (first-time-right). Projektin koon kasvaessa virheiden määrä kasvaa vähintään lineaarisessa suhteessa tehtävien määrään, mutta kokonaisuuden monimutkaistuessa ja riippuvuuksien kasvaessa virheiden määrä alkaa kasvaa tehtävien määrää nopeammin.

Virheiden vaikutus IT-projektissa

Myös virheiden seuraukset kasvavat projektin edetessä. Virheiden takia saatetaan joutua tekemään uutta työtä huteralle pohjalle, korjaamaan aiemman työn tuotoksia tai pahimmassa tapauksessa tekemään jo kertaalleen tehty kokonaan uudelleen. Virheet viivästyttävät aikataulua ja lisäävät kustannuksia sitä enemmän mitä myöhemmässä projektin vaiheessa virheet ilmenevät.

On helppo ymmärtää virheen vaikutus, kun seuraavien tehtävien aloittaminen / valmistuminen viivästyy edellisessä vaiheessa tehdyn virheen vuoksi. Lisäksi virheen korjaaminen tarkoittaa tuplatyötä eli tuplakustannusta. Pohdittaessa panostuksia projektin eri vaiheisiin on tärkeää huomioida, että on paljon edullisempaa tehdä muutos rakennuspiirustuksiin kuin valmiiksi rakennetun talon perustuksiin.

Virheiden kustannukset

IT-projekteissa tehtävien virheiden kustannuksia on selvitetty tutkimuksissa. Esimerkiksi Capers Jones on esittänyt virheiden kustannuksen kasvavan IT-projektin eri vaiheissa oheisen kuvaajan esittämällä tavalla (kirja). 

Projektityön virheiden aiheuttaman kokonaiskustannuksen määrittää oheisen tutkimuksiin perustuvan graafin perusteella kolme tekijää:

  1. miten paljon virheitä tehdään (eli mikä on yleinen työn tuotosten laatu eri vaiheissa)
  2. missä projektin vaiheessa virheet tehdään (eli miten aikaisessa vaiheessa virheet korjataan)
  3. mikä on virheiden keskimääräinen ”yksikkökustannus” (eli miten pahoja virheitä tehdään)

Otetaanpa esimerkki virheiden kustannusten konkretisoimiseksi: oletetaan, että budjetiltaan miljoonan euron IT-projektissa tehdään töitä yhteensä 1250 htp:tä. Oletetaan edelleen, että projektitiimi suorittaa keskimäärin 90 % laadulla neljä tehtävää per htp (eli tehtäviä on yhteensä 5 000 kpl virheitä tehdään yhteensä 500 kpl). Oletetaan edelleen, että puolet virheistä ajoittuu kehitysvaiheen aloittamisen jälkeiseen aikaan.

Kasvattamalla tehtävien laatu 98 %:iin ja ratkaisemalla puolet testausvaiheen virheistä jo suunnitteluvaiheessa projektin kustannuksia voitaisiin alentaa noin 20 % eli 200 000 euroa.

Voit arvioida vastaavalla tavalla omalla vastuullasi olevan IT-projektin tai koko yrityksesi kehitysprojektiportfolion kustannussäästöpotentiaalia tällä Cheetah-laskurilla.

Virheiden aiheuttamat lisäkustannukset eivät aina näy suoraan toimittajien kasvaneessa laskutuksessa tai sisäisten kustannusten seurannassa, vaan voivat ilmetä vaikeammin seurattavina, eriteltävinä ja laskettavina piilokustannuksina, kuten esim.

  • projektiaikataulun viivästymisenä (liiketoimintahyödyn viivästyminen ja muuttuvien kustannusten kasvu)
  • ratkaisun heikompana käytettävyytenä tai soveltuvuutena (tehdään vain pakollinen ja minimilaadulla)
  • kompromisseina teknisten vaatimusten osalta (tingitään esim. ratkaisun ylläpidettävyydestä tai dokumentaatiosta)
  • korkeampana riskitasona (joka voi realisoitua projektin aikana tai sen jälkeen ratkaisun elinkaaren aikana)
  • projektiorganisaation henkilöiden ylikuormituksena (sairaslomina tai burn-outeina)

Varmista projektitiimin riittävä osaaminen

IT-projektit ovat liiketoiminnallisesti monimutkaisia ja teknisesti vaativia kokonaisuuksia. Kaikissa IT-projekteissa tapahtuu lukuisia virheitä, eikä kaikkia virheitä ole mahdollista estää asetetun aikataulun ja käytettävissä olevien resurssien puitteissa.  

On kuitenkin täysin mahdollista vähentää virheiden määrää ja ratkaista virheitä ennakoivasti projektin aikaisemmissa vaiheissa varmistamalla projektitiimin riittävä osaaminen koulutuksilla, parantamalla projektipäällikön työn edellytyksiä tarjoamalla valmennusta sekä käyttämällä IT-projekteissa kinkkisimmissä vaiheissa ulkopuolista neuvonantajaa. Tällä tavalla virheiden projektille aiheuttama kokonaiskustannus alenee merkittävästi.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektien kustannustenhallintaa projektityön laadun parantamisena kautta? 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.

Mikä IT-projekteissa oikein kestää?

Tämä tarina on tosi. IT-konsultilla oli kotona ongelma; keittiön lamppu oli alkanut välkkyä. Ongelman ratkaisemiseksi hän joutui yrittämään useita eri tapoja ja päätyi ratkomaan haastavaa ongelmaa useaan otteeseen monen päivän ajan. Lopulta ratkaisu löytyi ja lamppu paloi välkkymättä. Kuinka monta IT-konsulttia tarvitaan korjaamaan lamppu? Vain yksi, mutta siinä menee todella kauan.

Lamppuongelman ratkaisuun kului IT-konsultilta kokonaisuudessaan kalenteriaikaa 177 tuntia (reilu viikko) ja työn suorittamiseen kului bruttoaikaa yhteensä 1,5 tuntia (kuudessa eri osassa). Kun toimiva ratkaisu löytyi, sen toteutus kesti alle minuutin. Ongelman nettoratkaisuaika oli siis alle sadasosa työhön käytetystä kokonaisajasta ja 1/10000 osa aloittamisesta valmistumiseen kuluneesta kalenteriajasta!

Miten ihmeessä puolen minuutin hommaan voi kulua viikko kalenteriaikaa ja puolitoista tuntia erinäköistä ”työskentelyä”? Aika tuhlaantui mm. seuraaviin:

  • vitkasteluun epämiellyttävän ongelman edessä
  • väärien ratkaisuvaihtoehtojen kokeilemiseen
  • sen pohtimiseen, mitä ratkaisua seuraavaksi kannattaisi yrittää

Onneksi tämä kertomus on vain arkinen esimerkki kyvyttömän yrityksestä tehdä mahdottomia, eikä vastaavaa koskaan tapahdu IT-ammattilaisia IT-projekteissa. Eihän?

Viiveet tehtävien läpimenoajoissa

Valitettavasti raaka totuus on, että suurin osa IT-projektien aikataulu- ja kustannushaasteista johtuu nimenomaan edellä kuvatun kaltaisista viiveistä tehtävien läpimenoajoissa. Yksittäisen tehtävän kokonaisläpimenoajan määrittelee kolme elementtiä:

  • resurssien ajankäytön suunnittelu (paljonko aikaa käytössä, miten pitkä aika kerrallaan, mikä on muu työkuorma)
  • projektiympäristön ja tavoitteiden selkeys (paljonko ajasta kohdistuu tehtävän suorittamiseen)
  • asiantuntijaosaaminen (kuinka nopeasti tehtävä suoritetaan valmiin määritelmän (”definition of done”, DoD) mukaisesti)

Oheinen kuva selkeyttää eroja yksittäisen tehtävän suorittamisen kalenteriajan, bruttoajan ja nettoajan välillä:

IT-projekteissa tehtävien välillä on pitkiä riippuvuusketjuja (eli tehtävät täytyy suorittaa tietyssä järjestyksessä).  Ennen kuin seuraavan tehtävän voi suorittaa, pitää edelliset tehtävät suorittaa oikein.

Monesti tehtävien valmiin määritelmäkin (”definition of done”) on epäselvä. Tehtävät vaativat erilaista osaamista, joten peräkkäiset tehtävät suorittaa usein eri henkilö tai jopa eri organisaatio, mistä aiheutuu koordinaatioviiveitä. Kun IT-projektissa on useita tuhansia vaativia tehtäviä, jokainen ymmärtää, että viiveet tehtävien suorittamisessa kertautuvat ja vaikuttavat merkittävästi projektin aikatauluun ja sitä kautta myös kustannuksiin. Projektin kokonaistuottavuuden määritteleekin yksittäisten tehtävien läpimenoajan minimoinnin lisäksi tehtäväketjujen hukka-aikojen minimointi. Tässä avainasemassa on tehtävien suunnitelmallinen, keksinäinen priorisointi ja proaktiivinen työnohjaus.

Oheinen kuva selkeyttää viiveiden vaikutusta ja kalenteri-, brutto- ja nettoajan jakautumista kolmen tehtävän ketjussa:

IT-projekteissa on loppujen lopuksi kyse hyvin yksinkertaisesta asiasta: tuhansien ongelmien ratkaisemisesta pienin viivein, mahdollisimman nopeasti ja riittävän oikein. Käytännössä ongelmien ratkaisussa on kuitenkin aina viestinnästä tai ajanpuutteesta johtuvia viiveitä, asioiden monimutkaisuudesta tai epäselvyydestä johtuvia hitauksia ja huolimattomuudesta tai osaamisvajeesta johtuvia virheitä. Muilta osin IT-projektit ovat yhtä helppoja kuin lampun vaihto.

IT-projekteissa on loppujen lopuksi kyse hyvin yksinkertaisesta asiasta – tuhansien ongelmien ratkaisemisesta pienin viivein, mahdollisimman nopeasti ja riittävän oikein.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektien ajanhallintaa projektityön laadun parantamisena kautta? 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.

Onko IT-projektimenetelmistä hyötyä vai haittaa?

IT-projektit ovat haastavia. Pahimmillaan projektille asetetut tavoitteet ovat mahdottoman monimutkaisia, projektilta vaaditut valmistumisajat epärealistisia ja projektiin allokoidut resurssit riittämättömiä. IT-projektipäällikön arkea onkin taiteilu projektin laajuuden, aikataulun ja budjetin välillä kompromisseja tehden. Tasapainoisen projektinhallinnan tuloksena syntyy liiketoiminnalle hyötyjä tuottava tietojärjestelmäkokonaisuus, joka on siirrettävissä jatkuvaan palvelutuotantoon ja mahdollistaa jatkokehityksen.

Kuka sitten on vapaaehtoinen lähes mahdottomalta kuulostavaan IT-projektipäällikön tehtävään?

Kuka sitten on vapaaehtoinen lähes mahdottomalta kuulostavaan IT-projektipäällikön tehtävään? Ei juuri kukaan ja siksi osaavista IT-projektipäälliköistä pula. Monet varsinkin teknisen asiantuntijan tehtävissä toimivat välttelevät projektipäällikön tehtävän epämiellyttävältä kuulostavaa painetta ja vastuuta sekä sen edellyttämää ammatillista kasvua.

Tästä syystä erityisesti ketterät menetelmät ovat tulleet täyttämään IT-projektien johtamistyhjiötä. Nämä menetelmät ovat mahdollistaneet teknisille asiantuntijoille oman työnsä lisäksi enemmän vaikutusmahdollisuuksia myös projektikokonaisuuden osalta ilman todellista vastuuta projektista (esim. aikataulusta, kustannuksista, laajuuden hallinnasta ja riskeistä).

Metodologiat, menetelmät ja viitekehykset

Projektinhallinnan osaamisvajeen kompensoimiseksi eri tahot ovat kehittäneet erilaisia omiin näkemyksiinsä ja tarpeisiinsa IT-projektinhallinnan metodologioita, menetelmiä ja viitekehyksiä. Metodologioiden tarkoituksena on tarjota yleisluontoisia ohjeita siihen, mitä projektissa yleensä kannattaa tehdä ja miten.

Määrittelytavasta riippuen projektinhallinnan metodologioita voidaan listata kymmeniä (esim. SCRUM, Prince2, PMBOK, SAFe; täältä löytyy yksi lista metodologioita tai täältä toinen). Lisäksi sekä toimittajilla että asiakasorganisaatioilla on omiin tarkoituksiin räätälöityjä metodologioita, jotka voivat olla joko yksityiskohtaisia tai käsitteellisiä, ja joiden soveltamista valvotaan enemmän tai vähemmän kurinalaisesti.

Metodologioiden haasteena on se, että ne eivät pysty täyttämään vajeita projektin onnistumisen kannalta kriittisessä osaamisessa esim. liiketoimintavaatimusten määrittelyn, ratkaisuarkkitehtuurin suunnittelun tai konkreettisten tilanne- ja organisaatiokohtaisten työsuunnitelmien laatimisen osalta.

Projektimetodologia voi esimerkiksi ohjeistaa laatimaan viestintää ja vastuita selkeyttävän RACI-matriisin, mutta metodologia ei kerro mille projektin osa-alueille se kannattaa laatia, eikä myöskään millä tiedoilla matriisi pitää täyttää, jotta siitä olisi suurin hyöty. Metodologian kehittäjät eivät ole maanneet laakereilla, vaan RACI-matriisin tilalle on kehitetty ”parempia vaihtoehtoja” mm. PARIS-, PACSI-, RASCI-, RASI-, RACIQ-, RACI-VS-, CAIRO-, DACI-, RAPID- ja RATSI-matriisit (katso Wikipediasta, josset usko!). Kaikki tämä metodologia on olemassa ja silti mikään näistä ei kerro, miten matriisi kannattaa käytännön projektitilanteissa täyttää.

Johtajan osaaminen ja kyky soveltaa metodologiaa

Johtaja tarvitsee syvällisen perehtyneisyyden ja käytännön kokemuksen kautta muodostunutta osaamista myös johdettavan toiminnan sisällöstä. Samasta syystä sotilasorganisaatiotkin ovat hierarkkisia, eikä upseeriksi voi päätyä ilman, että on ensin ollut alokas. Oheisessa kuvassa on ote Hannes Olkkosen kirjasta Taktiikan perusteet, joka on julkaistu vuonna 1928. Kirjan sivulla 286 on esitetty jalkaväkirykmentin kiilaryhmitys hyökkäyssuuntaan.

Jääkärieversti Olkkosella oli merkittävä rooli talvi- ja jatkosodan upseereiden ja aliupseereiden kouluttamisessa.  Jos olisit ollut silloin päämajassa päättämässä, olisitko luottavaisena antanut rykmentin komentoon kenelle tahansa (sotilaskokemuksesta riippumatta) ja hoitamaan ”homman” noudattamalla piirrosta ja Olkkosen kirjan muita ohjeita? 

Avarasti ja luovasti ajateltuna projektimenetelmissä voidaan nähdä mm. seuraavat käytännön ”hyödyt”:

  1. Erilaiset yhdistykset voivat mahdollistaa olemassaolonsa jakaen oman projektimetodologiansa palvojille papukaijamerkkejä tai sertifikaatteja.
  2. Menetelmäkoulutuksia järjestävät yritykset voivat tehdä kannattavaa liiketoimintaa lupaamalla muutaman päivän koulutuksen tuottavan projektiammattilaisia, koska teoriassa käytännöllä ja teorialla ei ole mitään eroa.
  3. Organisaatiot voivat vaivatta ja hyvin perustein kuluttaa henkilöstön koulutusbudjetin helposti toistettavaan kirjainlyhenteeseen, jonka taakse uskotaan tiivistyvän kaikki projektit mullistava osaaminen.

Ei projektimetodologioista haittaa ole niin kauan, kun ohjausryhmä muistaa varmistaa, että projektipäälliköllä on riittävä osaaminen soveltaa metodologiaa konkreettisella tasolla kyseisen projektin erityistarpeet huomioiden. Liiallinen projektimetodologiaan nojautuminen on kuitenkin vaarallista. Projektin ohjausryhmä ei saa virheellisesti olettaa, että tietty projektimetodologia valitsemalla voitaisiin merkittävästi vähentää projektin riskejä tai että metodologia toisi suoraan ratkaisuja projektin konkreettisiin haasteisiin. Metodologian sijaan projektin onnistumisen tärkein avain on projektipäällikön osaaminen ja kyky soveltaa metodologian tarjoama viitekehys projektin tarpeisiin.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektityön laatua soveltamalla projektimenetelmiä tarkoituksenmukaisesti? 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.

Miten valitsen osaavan IT-projektipäällikön ja vältän huithapelit, jyrääjät ja tuuliviirit?

Mies meni eläinkauppaan. Häkissä oli kolme apinaa. ”Miten tuo apina voi maksaa 10.000 euroa?”, mies kysyi myyjältä. ”Se osaa koodata”, vastasi myyjä. ”Entä tuo toinen apina?”, kysyi mies. ”Se maksaa 15.000 euroa. Se osaa IT-arkkitehtuuria”, vastasi myyjä. ”Entä tuo kolmas sitten?”, kysyi mies. ”Se maksaa 20.000 euroa.”, vastasi myyjä. ”Mitä se oikein osaa?!?”, kysyi mies. Myyjä vastasi: ”En tiedä, mutta nuo kaksi muuta sanoo sitä projektipäälliköksi.”

Apina tietokoneella

Projektipäällikön valinta on yksi IT-projektin ohjausryhmän tärkeimmistä päätöksistä. Osaava projektipäällikkö on IT-projektin keskeinen menestystekijä. IT-projektipäälliköiden osaamisen arviointi ja vertailu on haastavaa, joten ohjausryhmät eivät useimmiten kiinnitä projektipäällikön valintaan riittävästi huomiota. IT-projekteihin liittyy useita epävarmuuksia, eikä edes osaava projektipäällikkö voi estää kaikkia ongelmia, minkä takia projektipäällikön merkitystä projektin onnistumiselle aliarvioidaan liian usein. Osaava projektipäällikkö osaa kuitenkin ennakolta estää monia ongelmia ja lieventää ennakoimattomien ongelmien vaikutusta, mikä näkyy pienempinä kustannus- ja aikatauluylityksinä.

Käytännön IT-arjessa kamppaillaan taivaita hipovien tavoitteiden, rajallisten resurssien ja tiukkojen aikataulujen ristipaineessa. Seuraavan kerran, kun olet nimittämässä IT-projektiisi projektipäällikköä, pysähdy hetkeksi ja varmista, ettet ole tietämättäsi syyllistymässä johonkin seuraavista virhearvioista IT-projektipäällikön valinnassa:

  • valitset huithapelin, jolla on kirkas visio, mutta jolle työn suunnittelu on utopiaa ja prioriteetit turhuuksia
  • valitset ahertajan, joka ratkaisee ongelmat nopeasti, mutta ei estä niiden syntymistä ennakoimalla
  • valitset hurmaajan, joka uskoo ilmapiirin, fiiliksen ja yhteishengen vievän vaikka läpi palomuurin
  • valitset kauppiaan, joka pitää ohjausryhmän ja sidosryhmät tyytyväisenä syöttämällä niille paskaa
  • valitset kylmäkallen, joka tehokkuuteen pyrkiessään kohtelee tiimiä mekaanisina suorittajina ja korvattavissa olevina resursseina
  • valitset ohjeistamispäällikön, jolle projektissa tärkeintä on hallinnollinen tarkkuus ja metodologinen kuri
  • valitset törmäysnuken, joka tietää kestävänsä palautetta, joten projektin onnistumisesta ei ole tarvetta stressata
  • valitset norsunluutornilaisen, jolle liiketoiminnan tavoitteet ovat selkeitä, mutta tekniikka-, arkkitehtuuri- ja vaatimusasiat ovat epämiellyttävää nippeliä
  • valitset propellipään, joka pyrkii edistykselliseen tekniseen ratkaisuun, mutta ei ymmärrä liiketoiminnan tarpeita
  • valitset höpöttäjän, joka osallistaa kaikki projektityöhön, mutta mittaa projektin etenemistä palaverien ja niiden osallistujien määrällä
  • valitset jyrääjän, joka toimittaa ala-arvoisen ratkaisun sovitussa aikataulussa ja budjetissa
  • valitset jokapaikanhöylän, joka on aina tekemisessä mukana ja ilmestyy mikromanageeraamaan myös silloin, kun ei tarvita
  • valitset tuuliviirin, joka etsii kompromisseja, mutta ei tee päätöksiä, koska ei halua sanoa kenellekään vastaan
  • valitset konkarin, jolla on pitkä kokemus teknisenä asiantuntijana, mutta jolle ei löydy enää muitakaan hommia
  • valitset juniorin, joka vakuuttaa olevansa motivoitunut IT-projektipäälliköksi, mutta ei ole aiemmin ollut IT-projektissa mukana

Vaikka IT-projektipäällikköjen osaamisen arviointi on haastavaa, kannattaa muistaa se tosiasia, että toiset projektipäälliköistä todella ovat osaavampia. Lisäksi erilaiset IT-projektit vaativat projektipäälliköltä erilaista osaamista riippuen esimerkiksi projektin liiketoimintakeskeisyydestä, ratkaisun teknisyydestä, projektin riskiprofiilista, projektiorganisaation muodosta tai ratkaisun loppukäyttäjistä. Nimenomaan vaativissa olosuhteissa projektipäällikön osaamisella on suurin vaikutus projektin onnistumiseen tai epäonnistumiseen.

Mount Everestin valloitus

Vaatii huomattavasti vähemmän osaamista retkenjohtajalta johtaa patikointia vehreälle kukkulalle kauniina kesäpäivänä kuin kiipeämistä Mount Everestille lumimyrskyn uhatessa. Kesäpäivänä kukkulalla voi olla vaikeaa nähdä eroja retkenjohtajien osaamisessa tai huonojen päätösten seurausten merkitystä. Sen sijaan Mount Everestilla jokainen retkenjohtajan päätös voi tehdä eron koko retkikunnan elämän ja kuoleman välillä. Valitsisitko itsellesi Mount Everestille retkenjohtajaksi joviaalin jutustelijan, joka patikoi ruohikolla kerran vuodessa aurinkoisessa säässä vai sherpan, joka on aiemmin vetänyt retken huipulle parikymmentä kertaa?

Kaikissa IT-projekteissa projektipäälliköltä vaaditaan monipuolista osaamista tasapainoisessa suhteessa. Projektinhallinnollisten menetelmien lisäksi mm. liiketoiminnan tavoitteiden syvällinen ymmärtäminen, organisaatiorajat ylittävät viestintätaidot, kokonaisuuden tilannekuvan säilyttäminen ja konkreettisten priorisoitujen toimintasuunnitelmien valmisteleminen ovat arvokkaita taitoja.

Älä ainakaan valitse seuraavan IT-projektiisi projektipäällikköä, jolta löytyy kovin monia aiemmin listatuista piirteistä. Muuten saatat pian löytää itsesi ja projektisi perinteisen sananlaskun kuvaamasta tilanteesta, jossa kyvyttömät yrittävät saada haluttomat tekemään mahdottomia.

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.

Mihin tarvitaan ei-toiminnallisia IT-vaatimuksia?

Useimmiten uuden IT-ratkaisun määrittelytyö keskittyy ratkaisun toiminnallisiin vaatimuksiin: Tietojärjestelmältä haluttuja toimintoja kuvataan käyttäjätarinoiden (user story), käyttötapausten (use case) ja käyttöliittymän näköismallien (wireframe / mockup) avulla. Toiminnalliset vaatimukset kuvaavat kattavasti ja yksityiskohtaisesti käyttäjän vuorovaikutuksen tietojärjestelmän kanssa. Ne määrittelevät, millä tavalla ja mitä syötteitä käyttäjä antaa tietojärjestelmään sekä järjestelmän antamat vasteet käyttäjän syötteisiin.

Tietojärjestelmän ei-toiminnalliset tai laadulliset vaatimukset (non-functional requirements) sen sijaan määrittelevät miten tietojärjestelmä antaa vasteet syötteisiin tai millainen se on. Ei-toiminnallisia vaatimuksia ovat esimerkiksi:

  • Saatavuus (availability). Jos IT-ratkaisun tulee olla käytettävissä 99 % ajasta, saako se olla pois käytöstä 14 minuuttia päivässä vai yhtäjaksoisesti 3,5 päivää vuodessa? Miten IT-arkkitehtuurilla ja toimintatavoilla varmistetaan, että ratkaisun suunnitellut ylläpitotoimenpiteet ja yllättävät virhetilanteet hoidetaan saatavuusvaatimukset täyttäen?
  • Skaalautuvuus (scalability). Jos IT-ratkaisu toimii 100 yhtäaikaisen käyttäjän kuormalla, niin toimiiko se samalla suorituskyvyllä myös 500 käyttäjän kuormalla? Miten IT-arkkitehtuurilla varmistetaan, että ratkaisu voidaan pienillä muutoksilla (infrastruktuuriin, alustaan tai sovellukseen) saada toimimaan myös 10 000 käyttäjän kuormalla?
  • Siirrettävyys (portability). Jos IT-ratkaisu toimii Windows PC:llä, niin toimiiko se myös Applen Mac-tietokoneella (OS X), Samsungin Galaxy-puhelimella (Android) tai Nokian Lumia-puhelimella (Windows Phone)? Miten teknologiavalinnoilla varmistetaan ratkaisun alustariippumattomuus tai minimoidaan työ, joka vaaditaan ratkaisun siirtämiseen uudelle alustalle?

Muita ei-toiminnallisia vaatimuksia ovat esimerkiksi tietojärjestelmän tietoturvaan (security), käytettävyyteen (usablity), ylläpidettävyyteen (maintainability), räätälöitävyyteen (modifiability), integroitavuuteen (interoperability) tai suorituskykyyn (performance) liittyvät vaatimukset. Kuten yllä olevat esimerkit auttavat ymmärtämään, ei-toiminnalliset vaatimukset määrittelevät rajoitteita ja reunaehtoja tietojärjestelmän tekniselle toteutukselle ja hallinnoinnille.

Tietojärjestelmän ei-toiminnallisia vaatimuksia on haastavaa määritellä selkeästi, koska ne liittyvät järjestelmän sisäisiin ja teknisiin ominaisuuksiin. Uuden tietojärjestelmän vaatimuksia määriteltäessä kiinnostavat tyypillisesti eniten ratkaisun käyttäjälle tarjoamat toiminnot eli toiminnalliset vaatimukset. Kuitenkin ei-toiminnalliset vaatimukset voivat työmäärällisesti vastata useita kymmeniä prosentteja ratkaisun toteutuksen kokonaistyömäärästä.

Ei-toiminnallisilla vaatimuksilla on kriittinen rooli tietojärjestelmän laadun, luotettavuuden ja kustannustehokkuuden takaamisessa koko elinkaaren ajan. Panostus ei-toiminnallisten vaatimusten määrittelyyn heti alussa on tärkeää, koska ratkaisun toteutuksen jälkeen ei-toiminnallisia vaatimuksia voi olla hyvin työlästä tai jopa mahdotonta täyttää.

Realististen ei-toiminnallisten vaatimusten määrittelyyn tarvitaan yhdistelmä teknistä ja liiketoiminnallista ymmärrystä. Ei-toiminnalliset vaatimukset laatii tyypillisesti projektin suunnitteluvaiheessa IT-arkkitehti, joka tasapainottelee liiketoiminnan ja tietohallinnon tarpeiden sekä teknologian mahdollisuuksien välillä. Ei-toiminnallisten vaatimusten määrittelyssä tarvitaan kompromisseja ja vaatimusten välistä priorisointia (trade-off), koska useimmiten kaikkia vaatimuksia ei ole mahdollista toteuttaa käytössä olevilla rajallisilla resursseilla. Esimerkiksi ratkaisun suorituskyvyn parantaminen saattaa vähentää ratkaisun siirrettävyyttä tai integroitavuus saattaa vähentää tietoturvaa.

Yksinkertaistaen voisi sanoa, että ratkaisun toiminnalliset vaatimukset määrittelevät ratkaisun liiketoiminnallisen hyötypotentiaalin (prosessien mahdollistaminen, tehostaminen, tukeminen), kun taas ei-toiminnalliset vaatimukset määrittelevät ratkaisun luotettavuuden, kustannustehokkuuden ja teknisen mukautuvuuden tulevaisuuden tarpeisiin. Usein määrittelyvaiheessa eniten keskustelua herättävä ei-toiminnallinen vaatimus on järjestelmän saatavuus, jonka voidaan erityisesti liiketoimintakriittiselle järjestelmälle suoraviivaisesti vaatia olevan 100 %. Keskusteluun tuo perspektiiviä se, että AT&T:n puhelinverkko USA:ssa on ainut tekninen järjestelmä maailman historiassa, jossa on tiettävästi paikallisesti päästy 99,999 % saatavuuteen. Esimerkiksi Google tähtää palveluissaan 99,99 %:n saatavuuteen, mutta ei uskalla luvata käyttäjille sitäkään.

Lisätietoa:
The New York Times
Wikipedia

Haluatko saada lisätietoja tietojärjestelmien toiminnallisista tai ei-toiminnallisista vaatimuksista? Tutustu palveluihini ja kysy lisää!

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.

Räätälöity valmisohjelmisto, kiitos!

Kaupallisten valmisohjelmistojen hyödyntäminen yrityksissä on nykypäivää. Kaukana ovat ne ajat alkaen 60-luvulta, kun liiketoimintaprosesseihin räätälöidyn liiketoimintalogiikan kehitystä tehtiin suurtietokoneympäristöissä COBOL- ja PL/1-kielillä. Tai siis tehtiin niissä suurissa organisaatioissa, joissa oli varaa investoida arvokkaaseen keskustietokoneeseen. 80-luvulta alkaen kaupalliset valmisohjelmistot ovat käytännössä tuoneet tietotekniikan myös pienempien yritysten ja kuluttajien saataville.

Yritysten tietohallinnossa valmisohjelmistojen lisääntyminen on tarkoittanut, että aiemmin vallinnut toimintatapa kehittää liiketoiminnan tarvitsemat ratkaisut alusta asti on osin korvautunut valmisohjelmistojen käytöllä. Valmisohjelmistoilla on kiistaton liiketoiminnan tuottavuuden ja tehokkuuden kasvattamisen mahdollistava vaikutus. Niiden ansiosta yrityksillä on mahdollisuuksia valjastaa liiketoiminnan käyttöön tietoteknisiä ratkaisuja, joiden rakentamiseen organisaatioilla itsellään ei riittäisi resurssit tai osaaminen – kukaan ei nykypäivänä edes harkitsisi käyttöjärjestelmän, internet-selaimen tai tietokantapalvelimen toteuttamista itse.

Toki kolikolla on myös kääntöpuoli. Tässä blogissa käsittelen haasteita, joita liittyy kaupallisten valmisohjelmistojen käyttöön liiketoiminnan tietojärjestelmien osana. Esitän näkökulmia, joita kannattaa pohtia, kun joutuu valitsemaan räätälöidyn ratkaisukehityksen ja valmisohjelmiston käytön välillä. Valmisohjelmistot lupaavat paljon ja niiden suurin haaste onkin, että ne lupaavat nopean tien korkeaan monimutkaisuuteen ja korkeaan laatuun ja samalla matalaan riskiin. Valitettavasti tämä on illuusio; asiakkaan tulee ymmärtää myös kompromissit, joita on pakotettu tekemään valitessaan valmisohjelmiston.

Käytännössä kaikissa liiketoiminnan tietojärjestelmissä on osana sekä valmisohjelmistoja (tietokannat, sovelluspalvelimet, integraatioalustat, verkkokomponentit) että räätälöityjä osia. Puhdas joko–tai-valinta räätälöidyn ratkaisukehityksen ja valmisohjelmiston välillä tehdään melko harvoin. Seuraavia vinkkejä voikin hyödyntää myös pohdittaessa valmisohjelmiston räätälöinnin astetta tai räätälöidyn ratkaisukehityksen standardoinnin astetta.

Räätälöity ratkaisukehitys kannattaa erityisesti, kun

  1. projektin tavoitteet ovat strategisia (kilpailuetu, tulevaisuuden tarpeet) ja liittyvät ydinliiketoimintaprosessien kehittämiseen (esim. tilaus-toimitusprosessi tai asiakaspalveluprosessi)
  2. ratkaisun visio, konsepti ja vaatimukset ovat realistisia ja selkeitä, mutta monimutkaisia (kun valitsemalla valmisohjelmisto jouduttaisiin tekemään kompromisseja ratkaisun laajuuden, soveltuvuuden tai luotettavuuden suhteen)
  3. ratkaisun liiketoimintahyödyt ja laatu ovat tärkeämpiä kuin toteutuksen aikataulu ja kustannukset
  4. organisaatiolla on käytössä osaamista ratkaisun toteutukseen ja tukemiseen (työskentely on parhaiden teknisten käytäntöjen mukaista, tuottavaa, tehokasta ja ennakoitavaa)

Valmisohjelmiston valinta kannattaa erityisesti, kun

  1. projekti liittyy toimialalla käytännöiltään yhtenäiseen prosessialueeseen (esim. asiakastietojen hallinta) tai pientä liiketoiminnan lisäarvoa tuottavaan prosessiin (esim. matkalaskujen hallinta) tai ratkaisu on teknisiltä ominaisuuksiltaan erityisen vaativa
  2. ratkaisulle ei ole organisaatiossa selkeää visiota tai tarkkoja vaatimuksia ja organisaation toimintatapoja ollaan valmiita muuttamaan ratkaisun käyttöönoton seurauksena (valmisohjelmisto sisältää ”vision”)
  3. ratkaisun edellyttämät laadulliset kompromissit voidaan hyväksyä kustannussäästöjen ja nopean käyttöönoton saavuttamiseksi
  4. organisaation oma osaaminen ja mahdollisuudet ulkopuolisen osaamisen käyttöön ovat rajalliset (riippuvuus ohjelmistotoimittajan tukipalvelusta tiedostetaan osana palvelutason ja riskien hallintaa)

Mikäli valinta tehdään väärin perustein ja päätetään valita valmisohjelmisto (kun tarvittaisiin räätälöity ratkaisu), ratkaisun karkeuden kompensoiminen räätälöimällä valmisohjelmistoa tai toimittajariippuvuuden vaikutusten väärinarviointi voi kasvattaa kustannuksia, aikataulua tai riskejä hallitsemattomasti. Mikäli valitaan räätälöity ratkaisu (kun riittäisi valmisohjelmisto), ratkaisun tekninen monimutkaisuus, realistisen ja selkeän ratkaisuvision puuttuminen, aikataulun / kustannuksen ylikorostaminen tai osaamisen puute voivat johtaa kovinkin heikkolaatuiseen ratkaisuun.

Sekä valmisohjelmistoille että räätälöidylle ratkaisukehitykselle on edelleen paikkansa nykyaikaisessa liiketoiminnan tietojärjestelmäarkkitehtuurissa, vaikkakin yleinen ohjelmistoteknologioiden kypsyyden kehittyminen ja viimeaikainen pilvipalveluiden yleistyminen lisäävät vähitellen valmisohjelmistojen osuutta. Kaikki aidosti liiketoimintaa palvelevat korkealaatuiset, luotettavat ja joustavat IT-ratkaisut eivät kuitenkaan pilvestä tule – ainakaan vielä vähään aikaan.

Tarvitsetko apua ohjelmistovalinnassa tai muissa IT-projekteihin liittyvissä asioissa? Tutustu palveluihini ja kysy lisää!

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.

Hyvää ei saa halvalla, edes IT-maailmassa

Erään kahvilan ovella oli kyltti, jossa luki: ”Täältä saa hyvää, nopeaa ja edullista palvelua. Valitse mitkä tahansa kaksi.” Jokainen kahvilan asiakas ymmärtää vitsin, mutta myös totuuden, joka siinä piilee. Tietotekniikkaan liittyviin hankintoihin voitaisiin soveltaa samaa sääntöä kriteereinä laatu, kustannukset ja riskitaso. IT-hankinnoissa tietohallinnon haasteena on, että tarjousten ”suhteellista hyvyyttä” on vaikea arvioida. Tässä blogissa annetaan muutamia vinkkejä, jotka kannattaa muistaa vaihtoehtoisia tarjouksia vertailtaessa.

IT-hankinnoissa kustannukset saavat usein tarjouksia arvioitaessa suuren painoarvon, koska kustannusten perusteella on helpointa asettaa tarjoukset järjestykseen. Ratkaisun tai projektitoimituksen laatua tai riskitasoa on sen sijaan varsin hankala arvioida – varsinkin tarjouksen perusteella etukäteen. Riskitaso tarkoittaa käytännössä hankinnan kustannuksiin tai laatuun liittyvää epävarmuutta. Kustannusriskejä voidaan osin hallita sopimuksellisesti, mutta laatuun liittyviä riskejä voidaan lieventää vain tekemällä kokonaistavoitteita palvelevia hankintapäätöksiä.

IT-hankintapäätöksiä tehtäessä ja vaihtoehtoisia tarjouksia arvioidessa kannattaa kuitenkin kiinnittää huomiota seuraaviin näkökohtiin:

  • Laatu. Onko tavoitteena optimoida tuottavuutta (paras ratkaisu) vai tehokkuutta (toimitus ajallaan)? Tuottavuus on tyypillisesti tehokkuutta tärkeämpää, kun projektin tavoitteet ovat strategisia (kilpailuetu, tulevaisuuden tarpeet) tai liittyvät ydinliiketoimintaprosessien kehittämiseen. Tehokkuus on puolestaan tuottavuutta tärkeämpää esimerkiksi suurissa IT-infrastruktuuriprojekteissa, jotka ovat välttämättömiä, mutta liiketoiminnallisesti vähämerkityksellisiä (”kunhan se toimii”).
  • Kustannus. Miten kustannusten halutaan jakautuvan? Konsultointipalvelujen osalta kannattaa arvioida tunti- tai päivähinnan lisäksi konsulttien laatu (osaaminen), koska se lopulta määrittelee kokonaistyömäärän. Ohjelmistojen osalta tulee huomioida lisenssien kertakustannuksen lisäksi käytön vuosittaiset lisenssien ylläpitokustannukset. Kokonaisratkaisun osalta kannattaa arvioida toteutuskustannuksen lisäksi elinkaarikustannukset (total cost of ownership, TCO) sisältäen tuki- ja ylläpitotyön ja kattaen koko ratkaisun infrastruktuurista sovelluskerrokseen asti. Matala yksikköhinta ei aina tarkoita matalaa kokonaiskustannusta.
  • Riskitaso. Sallitaanko projektille matala vai korkea riskitaso? Riskitasoon vaikuttavat useat tekijät, mutta sen vaikutukset näkyvät aina joko laadussa tai kustannuksissa. Mikäli ollaan valmiita ottamaan riskejä, tavoitteeksi voi asettaa korkeamman laadun ja matalammat kustannukset (tämä onnistuu harvemmin). Mikäli taas halutaan välttää riskejä, tulee hyväksyä matalampi laatu ja korkeammat kustannukset (tämä onnistuu useammin).

Kaikkihan haluaisivat IT-projektistaan laadullisesti tuottavan ja tehokkaan, alhaisilla kustannuksilla ja matalalla riskitasolla. Valitettavasti tämä ei ole mahdollista, edes IT-maailmassa! Käytännössä hankintapäätökset aina suosivat joko tuottavuutta, tehokkuutta, kustannusten minimointia tai riskien minimointia – parhaassa tapauksessa jopa kahta näistä tavoitteista. Siksi päätös eri tavoitteiden painotusten välillä kannattaa tehdä tietoisesti enemmin kuin jättää sitä sattumanvaraan.

Tarvitsetko apua IT-hankinnoissa tai haluatko varmistaa IT-hankintojen onnistumisen? 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.

Tiedätkö IT-riskiprofiilisi?

Lisäarvoa ei ole olemassa ilman riskiä. Lisäarvon tuottaminen vaatii aina toimintaa ja toimintaan liittyy aina riski. Riskienhallinnan tavoitteena on jatkuvasti arvioida organisaation ja osatoimintojen riskiprofiilia.

Riskiprofiilin perusteella resursseja ohjataan riskien hallitsemiseksi siten, että kokonaisriskiprofiili vastaa organisaation hallinnointitavan ja strategian määrittelemää hyväksyttävää riskitasoa.

Riski voidaan määritellä toiminnalla tavoiteltuun lisäarvoon liittyvänä epävarmuutena. Klassiset IT-riskit voivat liittyä esimerkiksi projektin myöhästymiseen tai tietomurron uhkaan. Perinteisesti IT-riskienhallinta onkin käsitetty kerran tai pari vuodessa tehtäväksi harjoitukseksi, jossa tarkastetaan esimerkiksi tietoturvaan tai tietojärjestelmien varmistukseen liittyviä toimintatapoja.

IT-riskienhallinnassa on harvoin kyse riskien poistamisesta. Sen sijaan tunnistetut riskit voidaan hyväksyä, lieventää (mitigate), siirtää, jakaa tai välttää. Riskiä voidaan lieventää joko vähentämällä sen todennäköisyyttä tai haittavaikutusta. Kun riskitaso on hyväksytyllä tasolla, usein jää jäljelle ns. jäännösriski (residual risk). On tärkeää, että osana IT-riskienhallintaa määritellään myös toimintatavat jäännösriskin toteutuessa.

Parhaiden käytäntöjen mukaan IT-riskienhallinnan tulee kattaa myös lisäarvon luomismahdollisuuksien tunnistamista ja lisäarvon luomista rajoittavat riskit. Monet IT-riskeistä kytkeytyvät liiketoiminnan riskienhallintaan. Esimerkiksi vanhanaikainen IT-arkkitehtuuri voi yrityskauppojen yhteydessä muodostua strategiseksi riskiksi aiheutuvien kustannusten (time-to-value) tai aikataulun (time-to-live) takia.

Liiketoimintaosaamisen lisäksi IT-riskienhallinta vaatii laajaa teknologista, operatiivista ja hallinnollista IT-osaamista. Hyvin toteutettu IT-riskienhallinta pitää yrityksen IT-riskiprofiilin joustavasti ja ymmärrettävästi liiketoiminnan prioriteettien mukaisena, ja mahdollistaa laskelmoidun liiketoiminnallisen riskinoton.

IT:n kasvaneen liiketoiminnallisen merkityksen ja kiihtyvän teknologiakehityksen takia IT-riskienhallinnasta (IT risk management) onkin tullut strategisen, taloudellisen ja operatiivisen riskienhallinnan (enterprise risk management) ohella keskeinen osa hyvää hallintotapaa (corporate governance).

Organisaation IT-riskitietoisuuden rakentaminen kannattaa aloittaa kartoittamalla organisaation todellinen ja tavoiteltu IT-riskiprofiili. Lopullisena tavoitteena on kehittää IT-riskienhallinnasta prosessien ja teknologioiden tukema organisaation jatkuva toiminto.

Tarvitsetko apua IT-riskienhallinnassa? Tutustu Käytännöllinen IT-riskienhallinta -koulutukseen 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-sopimuksissa isot vievät ja pienet vikisevät

Suuryritysten tietohallinnossa työskentelee usein IT-hankintoihin ja -sopimuksiin erikoistuneita asiantuntijoita, joiden tehtävänä on pitää huolta yrityksen etujen ja tavoitellun riskitason toteutumisesta IT-toimittajien kanssa tehtävissä sopimuksissa. Etenkin usein niin haastavalla IT-alalla hankinta- ja sopimusosaaminen on välttämätöntä ja omien etujensa turvaamiseen sopimuksellisesti kannattaa panostaa.

Pienissä ja keskisuurissa yrityksissä ei sen sijaan usein ole kunnollista tietohallinto-organisaatiota puhumattakaan IT-sopimusten erikoisosaamisesta. Siitä huolimatta PK-yrityksillä on yhtä suuri tai jopa suurempi tarve turvata etunsa sopimuksellisesti, sillä IT:n kustannukset ovat PK-yritykselle suhteellisesti suuryritystä suurempia ja IT-toimittajat ovat usein 10 tai jopa 1000 kertaa suurempia yrityksiä.

Tuon tässä blogissa esiin keskeisimpiä sopimuskohtia, joihin etenkin kannattaa kiinnittää huomiota tyypillisimmissä IT-sopimuksissa, joita ovat

  • valmisohjelmistojen lisenssisopimukset
  • asiakaskohtaisten ohjelmistojen projektisopimukset
  • ohjelmistojen ylläpito- ja tukipalvelusopimukset
  • konsultointi- ja asiantuntijasopimukset
  • käyttäjätuki- ja käyttöpalvelusopimukset
  • laitteiden hankinta- ja huoltopalvelusopimukset.

Sopimisen perussääntö sanoo, että sopimuksessa pitää aina sopia: mitä, mitä maksaa, milloin, miten ja mitä jos ei. Käytännönläheisemmin voidaan sanoa, että sopimuksesta tulee selkeästi ja yksiselitteisesti käydä ilmi seuraavat asiat:

  1. sopimuksen kohde (mitä)
  2. kaupalliset ehdot (mitä maksaa)
  3. aikataulu (milloin)
  4. toimintatavat (miten)
  5. sanktiot mistä tahansa edellisistä kohdista poikkeamisesta (mitä jos ei)

IT-alan sopimukset ovat monesti melko pitkiä, minkä voidaan arvailla johtuvan esimerkiksi IT-alan teknisestä monimutkaisuudesta, korkeasta riskitasosta tai alalla liikkuvista suurista rahasummista. Ja onhan esimerkiksi ohjelmistojen lisensointi pohjimmiltaan puhtaasti juridinen innovaatio, jonka avulla ohjelmistoyritykset lisensoimalla voivat tehdä lähes 100 % marginaalikatetta.

IT-sopimuksista voidaan edellä esitettyä jaottelua mukaillen nostaa tärkeiksi huomioitaviksi asioiksi:

  1. mitä: ohjelmistomoduulit, tuotokset, palvelut, palvelutaso, laitekokoonpanot
  2. mitä maksaa: hinnoittelu, kulukorvaukset, maksujen korotukset, sopimusmuutokset
  3. milloin: projektin aikataulu tai palvelun kesto; sopimuksen purku- ja irtisanomisajat
  4. miten: raportointi, testaus, hyväksyntä, laskutus, toimittajan ja asiakkaan vastuut
  5. mitä jos ei: vastuu- ja korvausrajoitukset, viivästyssakko, takuukorjaukset

Edellä listattujen tekijöiden huomioon ottamisen helpottamiseksi laaditut erityisesti PK-yrityksille suunnatut alan yleiset IT2010-ehdot voivat toimia hyvänä pohjana, lisänä tai liitteenä IT-toimittajan kanssa tehtävään sopimukseen. Toisaalta, eivät suuryrityksetkään ole turvassa IT-toimittajien yksipuolisilta sopimusehdoilta. On suurasiakkaitakin ajettu pois tolaltaan ohjelmistotoimittajien yksipuolisilla hinnankorotusilmoituksilla.

Tarvitsetko apua IT-sopimuksien tai -hankintojen valmistelussa ja tekemisessä? 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.

Tietojärjestelmäintegraatioiden ihanuus ja hurjuus

Kaikki nykypäivän tietojärjestelmäkokonaisuudet sisältävät integraatioita useiden eri tietojärjestelmien välillä. Käytännössä tietojärjestelmäintegraatiossa on kyse järjestelmissä olevan tiedon (datan) siirtämisestä järjestelmien välillä tietoverkon avulla. Integraatiossa tieto luetaan ohjelmallisesti lähdejärjestelmästä, jonka jälkeen tietoa voidaan muokata ennen sen tallentamista kohdejärjestelmään.

Integraatioiden avulla useista tietojärjestelmistä koostuva kokonaisuus saadaan tarjoamaan käyttäjilleen haluttu toiminnallisuus. Esimerkiksi verkkopankissa asioidessaan käyttäjän käyttöliittymä integroituu useisiin taustajärjestelmiin, joista yhdessä voi hallita maksuja, toisessa tehdä osakekauppaa ja kolmannessa käsitellä laina-asioita. Lisäksi kaikki edellä mainitut taustajärjestelmät integroituvat tilitransaktioiden hallintajärjestelmään, joka edelleen integroituu mm. vähittäiskauppojen maksupäätteisiin, pankkiautomaatteihin ja toisten pankkien tietojärjestelmiin.

Tietojärjestelmäintegraatiot ovat haastavia, koska integroitavat tietojärjestelmät voivat käyttää samaa tietoa eri tarkoituksiin, käsitellä samaa tietoa eri tavoin ja perustua eri teknologioihin. Halutun kokonaistoiminnallisuuden varmistamiseksi integraatioita toteutettaessa täytyy määritellä:

  1. tietosisällön rakenne (tietomalli, keskinäiset suhteet, attribuutit)
  2. tiedon käsittelysäännöt (tiedon oikeellisuus, omistajuus, transaktiosäännöt)
  3. tiedonsiirron tekniset periaatteet (väylät, standardit, protokollat, tilallisuus)

Esimerkkinä tietosisällön rakenteeseen (kohta 1 yo. listassa) liittyvistä integraatiohaasteista toimii e-reseptin suunnitteluvirhe, jonka takia osa reseptille tarkoitetusta tekstistä voi jäädä puuttumaan reseptiltä. Ongelman syynä lienee, että tietosisältö (mm. tietokenttien pituudet) ei ollut yksiselitteisesti ja yhtenäisesti määritelty kaikille e-reseptin tietoja käsitteleville järjestelmille ja osassa tietoa käsittelevistä järjestelmistä reseptin tekstikenttien merkkimääriä on rajoitettu (ks. YLE).

Tästä seuraa, että vaikka lääkäri pystyykin onnistuneesti syöttämään reseptin tiedot järjestelmään käyttöliittymänsä kautta, jossain integraatioketjun vaiheessa järjestelmä ei pystykään tallentamaan tiedosta kuin esim. ensimmäiset 50 merkkiä. Tämän seurauksena apteekin käyttöliittymässä näkyy tietyssä kentässä vain 50 merkkiä.

Esimerkkinä tiedon käsittelysääntöihin (kohta 2 yo. listassa) liittyvistä integraatiohaasteista toimii Puolustusvoimien SAP HR -järjestelmän käyttöönotto puutteellisesti testattuna, jonka takia tuhansien työntekijöiden palkanmaksussa oli virheellisyyksiä ja viivästymisiä. Ongelman syynä lienee, että tiedon käsittelysäännöt (mm. tiedon oikeellisuuden varmistaminen) oli puutteellisesti määritelty ulkoisen tiedon tuonnin kannalta (toisista järjestelmistä), jonka takia uudessa järjestelmässä oli työntekijöiden peruspalkassa, tehdyissä työtunneissa ja pankkitileissä virheellisyyksiä. Tästä seurasi, että ajettaessa palkanlaskenta-ajo SAP HR -järjestelmässä, tulokset olivat virheellisen tiedon takia väärin, vaikka itse ajon logiikka olisikin oltu testattu toimivan täydellisesti.

Esimerkkinä tiedonsiirron teknisiin periaatteisiin (kohta 3 yllä olevassa listassa) liittyvistä haasteista toimii suomalaisten teleoperaattoreiden kapasiteetin, VR:n maksupäätelaitteiden ja maksukorttien EMV-standardin vaatimusten keskinäiset riippuvuudet, jonka takia VR päätti lopettaa Visa Electronin hyväksymisen junissa (ks. YLE). Ongelman syynä lienee, että joko Visa Electron -kortille pankin online-tarkistuksen vaativa EMV-standardi tai VR:n maksupäätelaite ei salli sellaisia teknisiä viiveitä (latensseja), pakkausta tai protokollaa, jolla tietojärjestelmäkokonaisuus toimisi varmuudella suomalaisten mobiiliverkkojen kattavuudella ja kapasiteetilla. Tästä seuraa, että Visa Electron ei toimi aina junassa, vaikka tietosisällön rakenne ja tiedon käsittelysäännöt onkin pilkuntarkkaan määritelty.

Riippuen IT-projektista, tietojärjestelmien väliset integraatiot saattavat muodostaa jopa puolet projektin kokonaistyömäärästä (verrattuna siihen, että tehtäisiin yksi monoliittinen sovellus, mikä ei usein ole edes käytännössä mahdollista). Siksi on tärkeää, että järjestelmän toiminnalliset vaatimukset ja käyttötapaukset kytketään integraatioiden suunnitteluun jo projektin aikaisessa vaiheessa. Tietojärjestelmäintegraatioissa onnistumisen varmistamiseksi on olemassa lukuisia teknisiä ja metodologisia hyviä käytäntöjä. Mikään ei kuitenkaan korvaa tärkeintä menestystekijää eli avointa, selkeää ja tehokasta osapuolten (usein eri toimittajien) välistä viestintää.

Tarvitsetko apua tietojärjestelmäintegraatioissa? 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.