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 10000 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

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.

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.

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 vaikeaa 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 (ks. 3T).
  • 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.

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, 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 ulkopuoliseen 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 voi 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.

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.

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.

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.

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.

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.