Blog

Allianssimallilla onnistuneeseen IT-hankkeeseen?

Mikko Varjos Director, Public Business, Solita

Published 20 Dec 2018

Reading time 4 min

Maailman ensimmäiset allianssimallilla toteutettavat tietojärjestelmähankkeet ovat nyt täydessä vauhdissa. Vieläpä meillä Suomessa. Malli tavoittelee tiiviimpää yhteistyötä tilaajan ja toimittajien välillä jakaen hankkeen riskit ja hyödyt. Kokemukset allianssimallista ovat positiivisia, vaikka malli ei kuitenkaan sovellu kaikkiin hankkeisiin ja sen sovittamisessa IT-maailmaan on vielä työtä. Sovellettaessa tulee pitää huoli siitä, ettei menetetä niitä oppeja ja toimivia menetelmiä, mitä ketterät mallit parhaimmillaan tarjoavat.

Kohti ketteryyttä

Hankinta- ja hallintamalleja on kehitetty niin pitkään kuin tietojärjestelmiä ja ohjelmistoja on ollut olemassa. Pitkään luotettiin perinteiseen, eli ns. vesiputousmalliin, missä hanke suunniteltiin ja määriteltiin tarkasti ennen kilpailutusta ja toteutuksen aloittamista. Esimerkiksi rakentamisen monimutkaisissa kokonaisuuksissa tämän tyyppinen lähestyminen onkin mahdollista tai jopa välttämätöntä.

Sen sijaan tietojärjestelmien kehitystyö on kompleksi kokonaisuus, jossa ei etukäteen tiedetä, mikä tulee olemaan paras lopullinen ratkaisu. Niiden toteuttaminen vesiputousmaisesti johtaa harvoin hyvään lopputulokseen käyttäjien näkökulmasta. Ohjelmistoprojektin tyyppisissä hankkeissa tarvitaan mukautuvampaa ja empiiristä toimintamallia.

Ketterässä mallissa maailmaa ei suunnitella valmiiksi ennen toteutusta, vaan ymmärretään kompleksisen hankkeen vaatima tarve syventää ymmärrystä ja määrittelyjä toteutuksen edetessä.

Tämä antaa mahdollisuuden ohjata hanketta sitä mukaan, kun ymmärrys käyttäjien tarpeista ja bisneksen mahdollisuuksista hankkeen edetessä kasvaa. Käytännössä tilaaja tyypillisesti kilpailuttaa osaamista ja saa tiimin toteuttamaan visionsa mukaisen järjestelmän.

Tilaaja-toimittaja -mallinen ketterä hanke saattaa kuitenkin olla haastava hankkeen koon ja toimittajamäärän kasvaessa. Myös hankkeen ennustettavuus ja epätasapuolinen riskinkanto on luonut tarvetta kehittää yhteistyömallia edelleen.

Rakennuksilta bittimaailmaan

Rakennus- ja inframaailmasta yleistyvä allianssimalli on herättänyt kiinnostusta myös ohjelmistojärjestelmähankinnoissa. Allianssissa tilaaja ja toimittajat tekevät tiiviistä yhteistyötä jakaen hankkeen riskit ja hyödyt yhdessä. Hankemallin tavoitteena on sitouttaa eri osapuolet onnistuneeseen lopputulokseen hankkeen parhaaksi. Hankemallissa niin tilaaja kuin toimittajat voittavat ja häviävät yhdessä. Allianssilla on yhteinen organisaatio, missä myös tilaaja osallistuu aktiivisesti. Tämä tarkoittaa yhteisiä toimintatapoja osapuolille, minkä lisäksi usein käytössä on yhteinen tila (big room) kommunikaation edistämiseksi.

Liikennevirasto lähti noin kaksi vuotta sitten ensimmäisenä soveltamaan hyväksi koettua allianssimallia IT-hankkeeseen. Velho -hankkeessa rakennetaan tiestötiedon hallintaan järjestelmäkokonaisuus. Nyt syksyllä alkaneessa IHKU -hankkeessa niin ikään sovelletaan allianssimallia. Liikenneviraston ja kuuden suuren kaupungin IHKU uudistaa Suomen infrahankkeiden kustannuslaskennan. Solita on mukana molemmissa allianssissa.

Millaisissa it-hankkeissa allianssimalli toimii?

Allianssimallisessa hankkeessa lähtökohtana on, että hankkeessa tarvitaan useita eri toimijoita, osaamisia, kyvykkyyksiä, joita yksittäiset toimijat eivät yksin kykene tarjoamaan. Mallin tavoitteena on koota nämä kyvykkyydet yhdeksi allianssiksi.

Allianssimalli vaatii hankintavaiheessa niin tilaajalta kuin toimittajiltakin erityistä panostusta. Tilaajan näkökulmasta tarvittavien kyvykkyyksien tunnistaminen on ratkaisevaa oikeanlaisen kilpailutuksen läpiviemiseksi. Vastaavasti toimittajaosapuolille oikeanlaisten konsortioiden rakentaminen on avainasemassa menestyksekkään tarjousprosessin ja hankkeen mahdollistamiseksi.

Yhteistyön sujuvuus on allianssin ydin. Tilaajan kannattaa kiinnittää erityistä huomiota ehdolla olevien konsortioiden yhteistyön sujuvuuteen. Osaamiset ja yhteistyö ratkaisevat allianssin onnistumisen.

Suuresta alkupanostuksesta johtuen malli ei sovi pieniin hankkeisiin. Lähemmäs kymmenen miljoonan euron järjestelmähankkeissa voidaan saavuttaa niitä hyötyjä mitä allianssimalli tavoittelee.

Hankintaprosessin ja hankkeen käynnistämisen vaatimat resurssit ja ajallinen panostus tulee huomioida hankkeen suunnittelussa. Allianssimalli soveltuu siten kestoltaan minimissään useiden vuosien hankkeisiin.

Emmehän kangistu uudelleen

Rakennusmaailmasta yleisesti käytetty allianssimalli on jaoteltu kolmeen vaiheeseen: Kehitysvaihe (KAS), Toteutusvaiheen (TAS) ja ylläpitovaihe (YAS). Tämä jaottelu on tuotu myös IT-maailmaan sellaisenaan rungoksi hankkeen vaiheistamiseksi. Tässä kohtaa ketterien menetelmien puolestapuhujat todennäköisesti nostavat kätensä pystyyn vaaran merkiksi! Vaiheistus on tuulahdus menneiltä vuosikymmeniltä ja kuulostaa vahvasti vesiputoukselta.

Sopimuksellisesti tulisi varmistaa, että hankkeen vaiheistus ei ohjaa hanketta liian laajaan ja tarkkaan suunnitteluun hankkeen alussa.

”Emme tiedä tulevasta järjestelmästä tai palvelusta koskaan yhtä vähän kuin hankkeen alussa”, on edelleen erinomainen viisaus. Hankkeen aikana tapahtuva määrittely ja konseptointi tehdään tiiviissä yhteistyössä toteutuksen kanssa. Allianssissa tämä tulee huomioida yhteistyössä ja toimintatavoissa integroiden eri osapuolet ja tekijät arjessa. Tämä kaikki on kovin tuttua ketteristä hankkeista tietäville. Ei unohdeta näitä oppeja myöskään alliansseissa.

Vaikka ”maailmaa ei suunnitella valmiiksi” heti hankkeen alussa, sille tarvitaan visio ja roadmap. Suurissa ja monimutkaisissa hankkeissa on tärkeää ylläpitää näkemystä siitä, mihin hanke tähtää: mitkä ovat hankkeen merkittävimmät tavoitteet, toiminnallisuudet ja prosessit, jotka tullaan täyttämään hankkeen nimissä.

Roadmap ja visio ovat työkaluja suunnan ja merkitysten kommunikoimiselle niin sisäisessä kuin ulkoisessa viestinnässä. Ne myös luovat pohjan tuotehallinnan työlle arjessa.

Yhtenä esimerkkinä eroavaisuuksista rakennushankkeiden ja tietojärjestelmien kehittämisen välillä on suhde budjettiin. Ketterissä hankkeissa tarkan etukäteen tehdyn suunnitelman ja sisällön sijaan visioidaan tavoite (saavutettavissa oleva asiakasarvo) ja lähdetään rakentamaan ratkaisua pala kerrallaan (inkrementaalisesti) täsmentäen sitä käyttäjäpalautteen ja tehdessä opitun perusteella (iteratiivisesti). Tällöin rakennushankkeissa käytetty hankkeen tavoitebudjettiin liittyvä palkitsemisjärjestelmä sopii heikosti ketterän kehittämisen malliin.

Allianssisopimusmallien tulee tukea niitä toimintamalleja, joita ketterä ohjelmistokehityshanke tarvitsee. Nyt käytössä olevat sopimukset tarvitsevat vielä kokonaisvaltaisen läpikäymisen tietojärjestelmäkehittämisen näkökulmasta. Siten voitaisiin luoda edellytykset mallin laajemmalle hyödyntämiselle IT-alalla.

Allianssimallilla on paikkansa

Kahden hankkeen ja reilun vuoden allianssikokemuksella voidaan nähdä mallin toimivuus IT-järjestelmähankkeissa. Se on hyvä vaihtoehto suurten, moniosaamista vaativien ja kompleksisten hankkeiden läpi viemiseen. Työläs hankintaprosessi tulee toki huomioida, mutta vastapainoksi saadaan sitoutuneet tilaaja(t) ja toimittajat. Mikä tärkeintä, allianssi luo parhaimmillaan erinomaiset puitteet ja ohjauksen aidolle yhteistyölle eri osapuolien välillä. Hanke- ja sopimusmallin sovittaminen IT-maailmaan on vielä kesken. Työ voidaan saattaa loppuun yhteistyössä tilaajaorganisaatioiden, konsulttitalojen ja toimittajien yhteistyössä. Hyödynnetään niitä arvokkaita kokemuksia, joita on jo kertynyt.