Taattua hyötyä IT-hankinnoista?

Perusongelma: Tietotekniikan ja päivittäistavaroiden hankinta on erilaista

Miksi tietotekniikkaa on niin hankalaa hankkia kilpailutuksilla? Löydän tähän kolme eri syytä:

1. Koska ohjelmat ja sähköiset palvelut ovat erilaisia kuin useimmat muut hankittavat asiat. Hankintahetkellä on harvoin selvää, mitä tarkalleen ottaen ollaan hankkimassa: mikä on hankinnan lopputulos tai ”tuote”. Sukkia ostettaessa voi helposti vaihtaa toiseen tuotteeseen, koska sukat toimivat sellaisinaan korvikkeina toisilleen. Tietotekniikkamaailmassa lähin vastine tälle ovat ohjelmat, jotka toteuttavat täsmälleen saman rajapinnan, esimerkiksi eri LDAP-palvelimet. Useimmille standardoiduille rajapinnoille on saatavilla avoimen lähdekoodin toteutukset. Kannattaako siis hankkia rahalla mitään, kun ilmaiseksi saa saman toteutuksen?
2. Useimmista hankinnoista on helppoa arvioida niiden hyödyllisyys, kun tuotteita käyttää. Tietotekniikkatuotteiden puutteet ja ongelmat tulevat ilmi hyvin hitaasti ja vasta perusteellisen käytön jälkeen. Kun asiakas on saanut kerätyksi riittävästi kokemusta tietääkseen, mitä oikeasti tarvitsee, on toimittajasuhde siinä vaiheessa jo kauan sitten päättynyt.
3. Yksi haaste on hankinnan tekeminen ennen käsitystä järjestelmän vähimmäistoiminnallisuudesta. Mahtavimmankin IT-toimittajan onnistumismahdollisuudet tällaisissa tilanteissa ovat heikot.

Tietotekniikkatuotteiden ulkoinen ja sisäinen laatu

Tietotekniikkatuotteilla on ’ulkoisen’ laadun (miltä tuotos näyttää, onko helppo käyttää) lisäksi tärkeää ’sisäinen’ laatu.

Sisäinen laatu tarkoittaa, kuinka usein järjestelmä kaatuu. Menetätkö tietoja/työtä? Kuinka vaikea järjestelmä on päivittää? Kuinka paljon resursseja se kuluttaa? Kuinka vaikeaa sitä on kehittää edelleen? Kuinka helppoa se on saada toimimaan yhteen muiden järjestelmien kanssa.

Järjestelmissä on organisaatiolle keskeistä tietoa, eikä sen siirto toisiin järjestelmiin aina ole vaivatonta. Lisäksi järjestelmät ovat sidoksissa sisäisiin toimintatapoihin ja prosesseihin. Työntekijät erikoistuvat käytännön pakosta käyttämiinsä tietotekniikkajärjestelmiin, olivatpa ne sitten kuinka huonoja tai vaikeakäyttöisiä hyvänsä.

Tarjouspyynnölläkään ei aina voi estää hankinnan keikahtamista hyödyttömäksi. Vaikka asiakkaana on sidottuna hankintansa lopputuloksiin pitkän aikaa.

Osittaisratkaisut perusongelmaan

Projektin tuottavuuden tuhoavia käytäntöjä on monta.

* Jos palvelun kehittämisen palautetiheys on liian hidas, projektin tuottamat tulokset eivät hyödytä ketään. Pitkiä palautesyklejä aiheuttaa liian pitkällinen suunnittelu ja asioiden kokeilu vasta myöhäisessä vaiheessa.

* Käytännöt, jotka estävät automatisointia, nakertavat tuottavuutta sekä ohjelmistojen ja palveluiden laatua. Esimerkiksi jos asennusohjeet ovat käsin kirjoitettuja ja käsityönä noudatettuja dokumentteja automatisoitujen asennusten sijasta.

* Voit varmistaa, että toimittajalle aiheutuu vähintään yhtä paljon haittaa kuin sinulle. Konsti toimii, mutta tuhoaa tuottavuuden. Käytännössä se tarkoittaa, että jokaisesta virheestä, missatusta kehityksen aikarajasta hankkeessa ja palvelukuvauksen supistuksesta tulee rankkoja korvausvaatimuksia toimittajalle. Silloin yleensä saa varsin tarkasti sen, mitä sopimuksessa lukee.

Onko se sitten hyödyllistä? Riippuu siitä, kuinka tarkkaan sopimuksen tekohetkellä tiesi, mitä tarvitsee. Ja kuinka hyvin sen sai sopimukseen kuvatuksi.

Huono puoli: kun tällaiseen tarjouspyyntöön annetaan tarjouksia, riskit nostavat tarjousten hintaa. Sitä paitsi sopimussakot toimivat lähinnä uhkana. Kun asiat alkavat mennä pieleen, ei yleensä paljonkaan ilahduta, että toimittaja on yhtä kovassa pulassa kuin itsekin on.

Keinoja, joita voi kokeilla

#1 Osta ”tietotekniikkaratkaisujen” sijasta fiksuja ihmisiä, jotka kehittävät ratkaisut ja ottavat kokonaisvastuun sen miettimisestä, mitä oikeastaan tarvitaan.

Ihmiset voi palkata omaan organisaatioon, mutta konsultitkin kelpaavat, jos he ovat sitoutuneet organisaatiosi pitkän aikavälin menestykseen. Kun ostat ihmisiä hoitamaan tietotekniikka-asiat puolestasi, et välttämättä osaa sanoa, tekevätkö he työnsä hyvin. Tietotekniikkataitojen arviointi vaatii niitä arvioijaltakin.

#2 Luota toimittajaan ja yritä tarjota kaikki mahdollinen tieto, mitä tämä tarvitsee onnistuakseen.

Jos IT-toimittaja on fiksu ja hyväntahtoinen, se pystyy tuottamaan hyötyä tällaisessa tilanteessa. Tiedän ammattitovereideni yrittävän parhaansa, mutta en silti voi luvata onnistumista jokaisella kerralla. Pyrimme myös kertomaan asiakkaillemme, jos meitä arveluttaa toteutuksen järkevyys. En voi taata aina onnistumista siinäkään. Mutta me yritämme kumminkin!

#3 Toteutetaan sama järjestelmä (eli samat käyttötapaukset) parissa tai kolmessa toisistaan eriytetyssä hankkeessa.

Tällä tavoin on helpompaa nähdä erillisten toteutusten suhteelliset vahvuudet ja heikkoudet. Kuulostaa kalliilta, mutta ei välttämättä ole sitä. Tällaista lähestymistapaa en ole – vielä – nähnyt käytettävän. Se voisi tuottaa mielenkiintoisia tuloksia!

#4 Lähdetään liikkeelle toimivasta (mieluiten avoimen lähdekoodin) ohjelmistosta, ja rakennetaan ohjelmisto/palvelu sen päälle.

Tällä tavoin voi vähentää ohjelmistohankkeiden riskejä. Silloin jokaisella kehitysiteraatiolla – vaikkapa kahden viikon välein – pitäisi olla toimiva ratkaisu. Edistymistä on myös helpompi arvioida. Toimiva ohjelmisto on eräänlainen varasuunnitelma, jos haluaakin lopettaa projektin hankaluuksien takia. Ohjelmistoa voi käyttää sellaisenaan kuin se sillä hetkellä sattuu olemaan. On kuitenkin hyvä muistaa, että kehitetyn ohjelmiston sisäinen laatu saattaa olla surkea, vaikka se päältä näyttäisikin hyvältä. Tämä ei siis ole taikaratkaisu kaikkiin ongelmiin.

Entä kun vahinko on jo tapahtunut?

Mitäs sitten tehdään, kun ollaan tilanteessa, jossa valittu IT-toimittaja ei saa hoidetuksi hommaa tai ei saa aikaiseksi sitä mitä tarvittaisiin? Silloin on vain huonoja vaihtoehtoja. Kokemukseni mukaan lähes kaikissa organisaatioissa aliarvioidaan, kuinka paljon haittaa aiheutuu huonon ohjelmistotuotteen tai palvelun viemisestä loppuun asti.

Huono, automatisoinnin estävä ja epäintuitiivinen IT-järjestelmä on kuin vihamielinen ja hankala työtoveri: siitä on vaikeaa hommautua eroon, se hankaloittaa prosesseja ja laskee työmotivaatiota.

Ja huonokin IT-järjestelmä tulee niin sidotuksi organisaation toiminnan kanssa, ettei sille oikein voi tehdä mitään… Lisäksi tulevissa hankinnoissa pitää ottaa vanha järjestelmä huomioon ja varata lisätyötä yliheittoon.

Tärkeintä on epäonnistua mahdollisimman varhain. Se on vaikeaa, koska organisaatio on yleensä jo valmistautunut uuteen palveluun ja toimintatapaan. Ei ole paljonkaan väliä, yrittääkö pitää hyvät välit IT-toimittajaan, jonka sopimus on päätetty vai sakottaa – tai mitä jälkiselvittelyitä seuranneekaan. Yleensä suurin haitta on keksiä, mitä tehdään, jotta saadaan jatketuksi töitä ilman sitä odotettua palvelua. Mitä aiemmin peli vihelletään poikki, sitä pienemmiksi seuraamukset jäävät. Koskaan ei ole liian myöhäistä keskeyttää projektia, jonka tuotokset eivät ole tuotannossa.

Voi tietysti yrittää löytää uuden IT-toimittajan, joka jatkaa töitä siitä, mihin edellinen jäi. Ei kannata kuitenkaan odottaa ihmeitä. Jos homma ei toiminut hyvin edellisen toimittajan kanssa, todennäköisesti ohjelmiston/palvelun sisäinen laatu on vielä huonompi kuin ulkoinen.

Vaikka seuraava IT-toimittaja olisi kyvykäs, huonon työnjäljen korjaamiseen menee paljon työtä. On rajansa, kuinka paljon vikoja ohjelmistossa voi olla: kaikki kehittämisaika ei voi kulua vikojen kanssa pärjäämiseen. Huonosti kirjoitettuun ohjelmaan on hidasta kehittää uusia ominaisuuksia. Silloin pitää varautua siihen, että kehittämistyö keskittyy sisäisen laadun parantamiseen. Käytännössä se tarkoittaa hitaampaa edistymistä käyttökokemuksen tai toiminnallisuuksien työstämisessä.

Joskus kannattaa heittää vanhat tuotokset pois. Sitten voi tarkastella ensimmäistä projektia kokeiluna, joka kasvatti ymmärrystä mitä hankinnalla tavoitellaan. Se saattaa osoittautua arvokkaaksi, jos hanke päätetään käynnistää uudestaan.

Miten valmistautua kilpailutuksiin?

Jos ei ole keinoa varmistaa, että kaikki menee hyvin, mitä kannattaisi tehdä?

* Pitää olla varasuunnitelma, johon voi tukeutua, jos hankkeesta ei synny hyödyllisiä tuloksia.

* Varmista, että asiat voi perua niin kauan, kun on epäilyksiä pystyykö uusi ohjelma/palvelu hoitamaan ne asiat, mitä piti.

* Varmista, että sopimuksen voi lopettaa aina ja mistä tahansa syystä, vaikkapa vain huonon fiiliksen vuoksi. Jos on jokin pakottava syy hankkia uusi järjestelmä (esim. vanha järjestelmä on tukikaarensa loppuvaiheessa), yritä ensin korjata pakottava syy pienimmin mahdollisin muutoksin.

* Älä yritä ympätä kaiken maailman parannuksia päivitysprojektiin, jonka on tuotettava tulosta tiettyyn päivään mennessä. Joudut hyvin epämiellyttävään tilanteeseen, jos hanke epäonnistuu.

Siitäkin on apua, jos organisaatiossa on ihmisiä, jotka pystyvät arvioimaan IT-toimittajan ja toimitetun palvelun tasoa. Näin voi keskeyttää projektin nopeammin, ja siitä aiheutuu vähemmän haittaa.

Millainen suhtautuminen sinulla on hankintaan?

Synkistelyyn ei tarvitse vaipua! Pointtini on, että hankinnat pitäisi nähdä pikemminkin kokeiluina kuin pelastavina ratkaisuina. Hankinnat voivat mennä joskus pieleen. Kun näin käy, niistä saa silti arvokasta kokemusta.

Kohtele hankittuja ohjelmistoja ja palveluita kokelaina. Älä anna toimintasi riippua niistä, ennen kuin toimivuus on osoitettu. Näin saat uuden näkökulman, jossa kaikki vaihtoehdot ovat hyviä: joko jatketaan vanhalla, toimivalla tavalla tai saadaan vielä parempaa ottamalla uudet palvelut ja niihin liittyvät toimintatavat käyttöön.

Varmista, että voit perua. Luota toimittajaasi. Yritä saada jotain käyttökelpoista mahdollisimman varhaisessa vaiheessa. Kerää niin paljon kokemusta kuin voit. Joskus saattaa mennä rahaa hukkaan, kuten muissakin investoinneissa, joskus saattaa osua kultasuoneen.

Mitä paremmin ymmärtää tarpeensa, sitä paremmat mahdollisuudet on onnistua myös IT-hankinnoissa.

Kiinnostuitko? Lue lisää sähköinen asiointi ja asianhallinta -verkkosivultamme, sekä tutustu ajankohtaisiin blogeihimme. Voit lukea lisää ohjelmistokehittäjiemme ajatuksia myös suoraan kehittäjiemme ylläpitämästä blogista. Etsimme jatkuvasti uusia solitalaisia joukkoomme, joten kurkkaappa myös avoimet työpaikamme verkkosivuiltamme.