Tuoreessa Talouselämässä on kirjoitus* tietojärjestelmätieteen professori Reima Suomelta ja valtio-opin professorilta Matti Wibergiltä, jossa he käsittelevät tietojärjestelmien hankinta- ja arviointikriteerejä. Kirjoittajat myös väittävät otsikossa suoraan, että ”It-ostajat eivät ymmärrä kokonaiskustannuksia*”.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
27.10.2011
Jutun terävin kritiikki kohdistetaan hankintaprosesseihin, joissa taustatyö on jätetty liian kevyeksi eikä sidosryhmien tarpeita ole todella selvitetty – eikä käyttöön liittyviä prosesseja ole selvitetty, ja kyseenalaistettu.
Juttu on ajankohtainen nyt kun isojen IT-hankkeiden epäonnistumisia käsitellään lehdissä (esim. VR:n lipunmyyntijärjestelmä), mutta aihe kannattaa ottaa vakavasti myös pienempien projektien näkökulmasta. Jos tietojärjestelmiä kehitetään vain liiketoiminnan näkökulmasta, niin usein päädytään ottamaan käyttöön järjestelmiä, joiden kanssa käyttäjät viettävät varsin paljon aikaa – ja joiden käyttö ei ole käyttäjien kannalta loogista. Tästä taas voi yhtälailla syntyä miljoonien eurojen kustannukset ja menetykset.
Reima ja Wiberg listaavat artikkelissaan joukon erilaisia ominaisuuksia, joihin IT-ostajien tulisi kiinnostaa huomiota. Nämä kriteerit ovat ammattiostajille varmasti tuttuja, mutta niissä on muutamia huomioita joiden takia ne kannattaa toistaa. Reiman ja Wibergin kriteerit (tiivistäen ja hieman muokaten):
- Hankintahinta, mukaan lukien käyttö- ja ylläpitomaksut (raha, koulutus, sisäiset resurssit)
- Toimintakyky ja vastaavuus käyttötarkoitukseen
- Käytettävyys (etenkin subjektiivinen käytettävyys jonka käyttäjät arvioivat)
- Helppokäyttöisyys ja sen tukimateriaali (erillisenä kohtana tässä listassa siis ohjelmiston omaksuttavuuskynnys)
- Toimintavarmuus (eri olosuhteet, erilaiset käyttöjärjestelmät)
- Toimittajan luotettavuus (”toimittajan soisi pysyvän bisneksessä ainakin lähitulevaisuuden”)
- Toimintatapa (ostetaanko palvelua vai omaan ympäristöön asennettava ohjelmisto)
- Referenssit (ketkä suosittelevat ja miksi?)
- Helpdesk-tuki (millainen tuki? millä kielellä? miten nopeasti?)
- Integraatio ja integraatiopolut (yhteentoimivuus yleisesti ja valmiiksi mietityt integrointipolut/lisäosat)
- Lähdekoodi (onko lähdekoodi käytettävää? avoimuus ei tässä ole itseisarvo, vain omistusoikeus asiakkaan näkökulmasta)
- Päivitys (miten usein ohjelmisto tulee päivittymään?)
- Ympäristö (tekninen ympäristö ja sen vaatimukset)
- Käytäntö (miten ylläpidetään, miten päivitetään, miten tuetaan – käytännössä)
- Palaute (miten toimittaja kerää palautetta, ja miten hyödyntää sen)
Lista kärki on lihavoitu tämän jutun kirjoittajan toimesta, koska vaikka kärkikohta (hinta) on varsin perinteinen kriteeri, niin toinen ja kolmas kohta ovat asioita joiden todella toivoisi näkyvän enemmän järjestelmävalinnoissa. Kun halutaan aidosti hankkia tietojärjestelmiä, jotka helpottavat ja tehostavat käyttäjien päivittäistä työtä, niin käyttötarkoitukseen sopivuus ja käytettävyys täytyy olla listan kärkikolmikossa.
Haasteena tässä on se, että ostajien on oltava realistinen sen faktan kanssa, että jos todella priorisoidaan käyttötarkoitukseen sopivuus korkealle, niin voidaan joutua tinkimään aika rajustikin listalla myöhemmin olevista asioista.
Monet organisaatiot lähtevät kyllä valintaprosesseihin tuon kaltaisen listan kanssa, mutta kun havaitsevat markkinan olevan puutteellinen (etenkin Suomessa, jossa it-toimittajia ei ole rajattomasti), niin päätyvät ylikorostamaan listan loppupäätä, koska pelkäävät saavansa haukut myöhemmin ostettuaan liian pieneltä tai tuntemattomalta toimijalta. Listan loppupäähän korostaa turvallisuutta, ja etupää korostaa soveltuvuutta.
Kärjistäen voisi sanoa, että mitä enemmän korostetaan listan loppupäätä, niin sitä todennäköisemmin päädytään leikkimään Tiedon, Accenturen, Logican tai jonkun muun elefantin kanssa – ja yleensä järjestelmien valmistajan nimikin on jokin jättiläinen, kuten Microsoft, Oracle tai SAP. Joskus tietysti näiden mainittujenkin kanssa voi saavuttaa käyttötarkoitukseen sopivuutta ja kustannustehokkuutta, mutta kokemus lienee VR:llekin osoittanut, että elefantit tuppaavat olemaan parempia tuon listan loppupuoliskon asioiden kanssa.
Jutun kommenteissa nostetaankin esille ajatus projektien pilkkomisesta, ja ylipäätään ison hankkeen ketjuttamisesta siten, että kerralla ei yritetä hankkia kaikkea. Tämä on tärkeätä myös käyttötarkoitukseen sopivuuden ja käytettävyyden näkökulmasta. Myyntidemojen ja hienojen powerpoint-esityksien avulla ei kovin usein saada todennettua esimerkiksi järjestelmän käytettävyyttä todellisten loppukäyttäjien toimesta. Listan loppupään ylikorostuminen hankinnoissa johtuu siis siitäkin, että alkupään asioiden arvottaminen ja vertailu on paljon vaikeampaa.
Tosin käytännön muutoksen kannalta kenties isoin ongelma piilee silti siinä, että ”isojen juttujen” ostaminen on vain yksinkertaisesti paljon ”seksikkäämpää” hommaa monien tahojen mielestä. Isot organisaatiot haluavat tehdä isoja ostoksia, ja isot IT-talot haluavat myydä isoja paketteja. Pienten palasten ostaminen ja tekeminen ei vain saa samanlaista johtoryhmätason huomiota isossa talossa mitä ”tosi iso IT-projekti” saa. Tämä on yksinkertaisesti harmillista.
Ehkä näissä isoissa epäonnistumisissa piilee pieni siemen siihen, että ostajatkin ryhtyvät arvostamaan pienten palasten ostamista, ja ehkä jopa isotkin talot ryhtyvät arvostamaan pienempien projektien myymistä.
