Nörtit syyllisiä?

Luin tuoreeltaan Kauppalehden artikkelin “Eduskunta pui it-pulmia: nörtit hihittävät ja käärivät rahat” ja jonkinasteisen tunteenpurkauksen myötä koin tarvetta kommentoida.

Kyllä nörtit ovat tähän tilanteeseen täysin syyttömiä. Tai jos oikeastaan tarkkoja ollaan, ilman nörttejä homma olisi kategorisesti pahemmin levällään, sillä vain nörttien ansiosta olla edes tässä tilanteessa.

Kauppalehden artikkelissa siis pohditaan, että kumpi, nörtti vai systeemi, on syyllinen tilanteeseen, jossa järjestelmät eivät ole yhteensopivia ja “nörtit käärivät rahat”. Eivät nörtit ole rahoja käärineet, hehän ovat vain nostaneet kuukausipalkkaa, joka on todennäköisesti mennyt lähinnä asuntolainan maksamiseen ja paikalliseen ruokakauppaan. He ovat usein jopa siviilielämänsä kustannuksella ahertaneet ylitöitä, jotta järjestelmät olisi saatu edes yhteensopimattomina toimimaan (ei siis keskenään, vaan ylipäänsä). Kyllä rahat ovat menneet muiden taskuun.

Kuka on siis syyllinen? Onko se systeemi vai joku muu? Kenen on vika, jos tilataan tietoisesti yhteensopimattomia järjestelmiä? Onko taustalla joku “systeemi”, joka tuollaista edellyttää? Vai onko taustalla epämääräistä lainsäädöntöä ja tietotekniikasta tietämättömiä päättäjiä? Vai liiketoiminnan konsultteja (siis ei nörttejä), jotka ovat neuvoneet tietämättömiä päättäjiä aiheesta? Vai onko kaikilla osansa sopassa?

Mikä on “systeemi” tässä tilanteessa? Keskustan Pekka Vilkuna totesi artikkelissa, että “syy on tässä systeemissä, jossa ei valvota riittävästi”. Hänen mielestään siis ilmeisesti valvonnan lisääminen olisi ratkaisu. Henkilökohtaisen kokemuksen valossa “valvontaa” on ihan riittävästi (ja usein liikaakin). Se, mitä puuttuu, on “vastuu”. Ohjelmistoprojekteja ostetaan vahvasti ulkoistettuina eikä ostaja ota todellista vastuuta hankittavan järjestelmän todellisesta soveltuvuudesta organisaation toimintaan ja tavoitteisiin. Tässä kohtaa kyllä voidaan “systeemiä” syyttää osasyylliseksi, sillä perinteinen vaiheistettu projektirakenne ei anna juurikaan mahdollisuutta todelliseen vastuunottoon projektin aikana.

Vaikka tiedän, että jokaiseen omenapuuhun mahtuu mätiä omenia, uskon kuitenkin vahvasti, että suurin osa “omenista” on varsin terveitä ja pyrkivät varsin vilpittömästi hyvään lopputulokseen. Mutta jos nuo hyvään pyrkivät ihmiset opetetaan tilaamaan tietojärjestelmiä tavalla, joka perimmäisiltä lähtökohdiltaan estää projektin aikaisen oppimisen ja reagoimisen ympäristön muutoksiin, eikä heille opeteta parempia tapoja hankkia ohjelmistoja (mikä ei edes ole heidän ammatillista perusosaamistaan), niin mielestäni heitä ei oikein voi syyttää tilanteesta. Se, että heitä on opetettu tietyllä tavalla, on “systeemin” vika, mutta ei niin, että “systeemi” olisi joku henkilö tai taho, vaan “systeemi” on IT-alaan juurtunut projektikulttuuri.

Tätä projektikulttuuria ruokittiin 20-30 vuotta ja taustalla on illuusio siitä, että tietojärjestelmäkehitys olisi samankaltaista perinteisen insinöörityön kanssa. Perinteisen insinöörityön perusta on huolellinen suunnittelu ja toteutettavan rakenteen huolellinen pikkutarkka suunnittelu, joka sitten jalkautetaan vähemmän osaaville tehtäväksi tarkkojen ohjeiden mukaan. Lähestymistapa on soveltuva vain tilanteisiin, joissa tehtävä työ ei edellytä tekijöiltään hartioiden yläpuolella olevien elinten aktiivista käyttöä (ja siis vain työtä ohjaavilta tahoilta vaaditaan pään käyttöä) JA voidaan perustellusti olettaa, että rakennelman suunnittelun ja toteutuksen aikana ei ole oletettavissa olennaisia muutoksia rakennelman käyttötarpeisiin ja ympäristöön.

Tietojärjestelmähankkeissa kumpikaan edellisistä ehdoista ei toteudu. Vähänkään pidempiaikaisen projektin (ml. hankintaprosessi) aikana yrityksen tai julkisen organisaation toimintaympäristö ja -tarpeet muuttuvat väistämättä niin paljon, että toteutuksessa olevaa järjestelmää pitäisi muuttaa olennaisesti, jotta se vastaisi valmistumishetkellään organisaation sen hetkisiin tarpeisiin. Lisäksi tietojärjestelmien suunnittelu ja toteutus vaatii mitä enemmissä määrin nimenomaan harmaan massan rasittamista. Kun tähän vielä lisätään se, että toteutetut tietojärjestelmät ovat enemmän tai vähemmän uniikkeja, joudutaan käytännössä jokaisen projektin yhteydessä ratkaisemaan ongelmia, joita ei sellaisenaan ole missään aikaisemmin ratkaistu (tai ainakaan tieto muualla tehdyistä ratkaisuista ei ole tekijöiden käytettävissä).

Systeemin muuttamisen perimmäinen edellytys siis on, että hylkäämme perinteisen projektihankinnan, -suunnittelun ja -johtamisen mallin, ja korvaamme sen todellisen toimintaympäristön vaatimusten mukaisella toimintatavalla. Tämän toimintatavan ydinelementtejä on projektinaikaisen muutoksen haltuunotto, jatkuvan muutoksen mahdollistava systeemityötapa sekä kaikki osapuolet koko projektin ajan aktiivisesti osallistuttava johtamistapa. Ohjelmistotuotannon puolella tuolla työtavalla on nimikin – ketterät ohjelmistotuotannon menetelmät. Nuo menetelmät on kuitenkin ymmärrettävä laajemmassa mittakaavassa kuin missä ne ottavat kantaa itse ohjelmiston tuotantotapaan tai ohjelmistoprojektin johtamiseen. Ne vaikuttavat myös ostavan organisaation ostotapaan, ostavaan yksikköön sekä ylempään liiketoimintajohtoon ja tukifunktioihin. Jos vaikutus ei ulotu sinne asti, ei organisaatio voi myöskään todellisesti hyötyä projektitason ketteryydestä.

Jottei lukijoille jää virheellistä mielikuvaa, todettakoon vielä, ketterät menetelmät eivät ole mikään hopealuoti, joka muuttaisi ohjelmistotuotannon helpoksi. Ei tehokkaiden, käytettävien, organisaation tavoitteita täyttävien tietojärjestelmien rakentaminen ole helppoa niilläkään. Tarvitaan riittävää osaamista ja ymmärrystä kaikilta projektitoiminnan osapuolilta, jotta järjestelmä syntyy tehokkaasti ja että se oikeasti vastaa tilaavan organisaation ja sen asiakkaiden tarpeisiin. Tällä hetkellä meillä on käyttävissä perusmalli – kattava osaaminen ja kokemus meiltä vielä liiketoiminta-alana puuttuu.