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.

Kommentointi on suljettu.