Ohjelmiston elinkaari: mitä tapahtuu hankintapäätöksen jälkeen
Ohjelmisto ei ole kertaostos, vaan pitkä suhde, joka jatkuu käyttöönoton jälkeen vähintäänkin vuosia. Tässä oppaassa käydään läpi koko elinkaari ulkoistuspäätöksestä siihen hetkeen, kun järjestelmä joko uudistuu yrityksen mukana tai tulee tiensä päähän.



Ohjelmiston hankinnan ja elinkaaren vaiheet, jotka on hyvä tiedostaa toimittajaa valitessa
Ohjelmiston elinkaari voidaan jakaa karkeasti kuuteen vaiheeseen:
2. Hankinta ja kilpailutus
4. Ylläpito
5. Kehitys ja tekninen velka
6. Uudistaminen tai irtautuminen
Kaksi ensimmäistä vaihetta ovat yritysten päätöksenteossa yleensä parhaiten tiedossa. Neljä viimeistä jäävät usein vähemmälle huomiolle, vaikka juuri niissä syntyvät suurimmat kustannukset ja riskit.
Ulkoistuspäätös: valinta jota harvoin tehdään systemaattisesti
Moni yritys päätyy ulkoistamaan ohjelmistokehityksen ilman, että vaihtoehtoa, oman kehitystiimin rakentamista, on oikeasti punnittu rinnalla. Päätös syntyy usein resurssitilanteen tai aikataulupaineen perusteella, ei pitkän aikavälin analyysin.
Taloustieteessä ulkoistuspäätöstä arvioidaan yleensä sillä, kuinka paljon yhteistyö vaatii valvontaa ja koordinointia suhteessa siitä saatavaan hyötyyn. Jos toimittajasuhde vaatii jatkuvaa tarkkailua ja yksityiskohtaista ohjausta, ulkoistamisen hyöty pienenee. Jos toimittaja pystyy toimimaan itsenäisesti selkeän tavoitteen suuntaan, ulkoistaminen kannattaa yleensä paremmin.
Käytännössä tämä tarkoittaa, että ulkoistuspäätöstä kannattaa arvioida yhtä huolellisesti kuin mitä tahansa muuta investointia. Kysymys ei ole vain siitä, onko yrityksellä osaamista sisällä, vaan myös siitä, kuinka paljon toimittajaa pitää valvoa ja ohjata halutun tuloksen saavuttamiseksi.
Hankinta ja kilpailutus: mitä tarjousvertailu ei kerro
Kun ulkoistuspäätös on tehty, edessä on toimittajan ja ratkaisun valinta.
Yleisin ongelma ei ole väärän toimittajan valinta, vaan se, että tarjouksia ei voi aidosti verrata keskenään. Jos hankinnan kohdetta ei ole määritelty riittävän tarkasti, jokainen toimittaja tulkitsee tarpeen omalla tavallaan. Tarjousten hintaero voi tällöin kertoa enemmän tulkintaeroista kuin toimittajien tehokkuudesta. Halvin tarjous on usein se, jossa on ymmärretty vähiten – tai jossa on tietoisesti jätetty eniten pois.
Hankinnan valmisteluun: tarpeen kirkastamiseen, tavoitteiden asettamiseen ja realistisen budjetin määrittelyyn kannattaa varata oma aikansa. Olemme koonneet nämä lähtökohdat erilliseen artikkeliin: Ota nämä asiat huomioon ohjelmistopalvelun hankinnassa.
Käyttöönotto: vaihe jossa ongelmat ensin näkyvät
Käyttöönotto on hetki, jolloin suunnitelmat kohtaavat todellisuuden. Puutteelliset vaatimusmäärittelyt, integraatio-ongelmat ja käyttäjien totutut työtavat nousevat esiin juuri tässä vaiheessa.
Käyttöönotto ei ole vain tekninen suoritus. Se on myös palvelumuotoilun kysymys: miten käyttäjät otetaan mukaan, miten muutos viestitään ja miten uusi työtapa juurtuu osaksi arjen prosesseja. Kukaan toimittaja ei halua markkinoida hetkeä, jolloin oma työ näyttää keskeneräiseltä, joten juuri tähän vaiheeseen kannattaa varata enemmän aikaa ja resursseja kuin mitä tarjousvaiheessa yleensä oletetaan.
Integraatiot: kohta jossa käyttöönotto useimmiten venyy
Harva järjestelmä toimii yksin. Integraatioilla tarkoitetaan eri sovellusten, järjestelmien tai tietolähteiden yhdistämistä toisiinsa ja niiden välistä vuorovaikutusta. Ne mahdollistavat tiedon jakamisen ja uudenlaisten ominaisuuksien tarjoamisen loppukäyttäjille ilman, että kaikkea tarvitsee rakentaa alusta asti itse.
Integraatiot ovat samalla se kohta, jossa aikataulut tyypillisesti pettävät. Syy on harvoin oman toimittajan osaamisessa: integraatio riippuu aina toisesta osapuolesta, jonka rajapinta, dokumentaatio ja vastausnopeus eivät ole hankkeen hallinnassa.
Ostajan kannalta kolme asiaa ratkaisee, sujuuko integraatio vai ei:
1. Määrittely ennen toteutusta. Ennen integraation toteutusta selvitetään, mitä tietoja ja toimintoja halutaan integroida ja miten.
2. Rajapintojen dokumentaation taso. Dokumentoidut rajapinnat helpottavat toteutusta ja antavat jo alkuvaiheessa hyvän yleiskuvan siitä, mikä on ylipäätään mahdollista. Jos vastapuolen rajapintaa ei ole dokumentoitu, työmääräarvio on aina epävarma.
3. Dokumentointi ja testit myös oman toteutuksen osalta. Käytetyt rajapinnat ja integraatiopisteet kannattaa dokumentoida ja niille kannattaa tehdä automaattisesti ajettavat testit. Tällöin käyttöönoton jälkeen syntyvät häiriöt havaitaan hälytysten avulla ennen kuin käyttäjä huomaa ne.
Tämä kolmas kohta ei ole vain tekninen yksityiskohta. Dokumentoimattomat integraatiopisteet ovat yksi yleisimmistä syistä siihen, miksi järjestelmästä on myöhemmin vaikea irtautua: tieto siitä, mitä järjestelmä oikeastaan keskustelee ympäristönsä kanssa, on vain yhden toimittajan tiimin muistissa.
Ylläpito: näkymätön budjettirivi
Kun järjestelmä on käytössä, alkaa ylläpito. Ylläpidolla varmistetaan, että tuote tai palvelu pysyy toimintakykyisenä, optimoituna ja tietoturvallisena. Käytännössä se kattaa laajemman joukon tehtäviä kuin ostaja usein olettaa:
- infrastruktuurin tarjoaminen ja ylläpito
- sovellusten ylläpito ja käyttäjätuki
- varmuuskopiointi ja palautusten testaaminen
- suorituskyvyn seuranta ja optimointi
- luotettavuuden seuranta ja ylläpito
- tietoturvapäivitykset ja riippuvuuksien päivittäminen
- jatkuvan integroinnin ja toimituksen prosessien automatisointi
- pienet muutokset muuttuviin tarpeisiin
Kaikki nämä maksavat, ja ne maksavat joka vuosi. Silti ylläpito jää usein hankintapäätöksen varjoon: budjetointi keskittyy kehityshintaan, ja ylläpito lasketaan vasta myöhemmin, erillisenä ja usein aliarvioituna eränä. Todellisuudessa ylläpito on jatkuva, vuosittain toistuva kuluerä, joka kertyy koko järjestelmän elinkaaren ajan.
Toimivasta ylläpidosta saatava hyöty on kuitenkin konkreettinen. Hyvin hoidettu ylläpito laskee uusien ominaisuuksien lisäämisen kustannusta, koska pohja pysyy muutoskelpoisena. Se myös vähentää häiriöistä aiheutuvia katkoja ja niiden liiketoimintavaikutuksia. Huonosti hoidettu ylläpito tekee päinvastoin: jokainen uusi ominaisuus maksaa hieman enemmän kuin edellinen.
Toinen huomioitava asia on ylläpitosopimuksen hinnankehitys. Jos sopimusta ei kilpailuteta uudelleen, hinta voi nousta vuosi vuodelta ilman selkeää perustetta. Tähän kannattaa varautua jo sopimusvaiheessa sopimalla hinnoitteluperiaatteista ja tarkistusväleistä etukäteen.
Kannattaa myös tarkistaa, mitä sovittu ylläpito tosiasiassa sisältää. Ero "vikojen korjaamisen" ja yllä kuvatun kokonaisuuden välillä on kustannuksissa merkittävä, eikä se aina käy tarjouksesta yksiselitteisesti ilmi.
Tekninen velka: syy miksi pienikin muutos muuttuu kalliiksi
Jokainen ohjelmisto kehittyy ajan myötä. Jokainen aikataulupaineen alla tehty nopea ratkaisu, joka vaatii myöhemmin korjausta, synnyttää "velkaa" koodiin.
Käsite on tuttu ohjelmistokehittäjille, mutta harvoin avattu liiketoimintapäättäjälle. Käytännössä tekninen velka näkyy ostajalle yhtenä oireena: muutokset, jotka aiemmin olivat nopeita ja edullisia, muuttuvat vuosien varrella hitaammiksi ja kalliimmiksi. Syy ei useinkaan ole huono kehittäjä, vaan kertyneet pikaratkaisut tai vanhentuneet ratkaisut, joita ei koskaan ole ehditty korjata.
Tekninen velka ei ole automaattisesti huono asia. Joskus se on tietoinen ja perusteltu valinta, esimerkiksi kun tuote pitää saada markkinoille nopeasti. Ongelma syntyy silloin, kun velkaa ei tunnisteta eikä siitä kerrota. Ostajan kannattaa kysyä suoraan, miten teknistä velkaa seurataan ja raportoidaan osana ylläpitoa.
Uudistaminen tai irtautuminen: kaksi mahdollista polkua
Parhaassa tapauksessa ohjelmisto kehittyy ja kasvaa yrityksen mukana, jolloin vanhentuneita osia korvataan sitä mukaa kun tarve syntyy eikä muutos koskaan kasva erilliseksi hankkeeksi. Toisessa tapauksessa muutos tulee kertarysäyksellä: edessä on toimittajan vaihto, uudelleenrakennus tai siirtymä toiseen ratkaisuun.
Kumpi polku toteutuu, ei ole sattumaa. Osa laukaisijoista on oman hallinnan ulkopuolella: alustan tuki päättyy, toimittaja myydään, sääntely muuttuu. Osa on kokonaan omissa käsissä: teknisen velan taso, dokumentaation kunto, oikeudet lähdekoodiin ja arkkitehtuurin muutoskyky.
Samat toimet, joilla irtautumiseen varaudutaan, vähentävät sen todennäköisyyttä.
Julkishallinnon tarkastuksissa on havaittu tapauksia, joissa vanhasta järjestelmästä ei ole voitu irtautua, koska lähdekoodin oikeudet ovat jääneet kokonaan toimittajalle. Tällöin ylläpitoa ei ole voitu edes kilpailuttaa, ja tilaaja on käytännössä jäänyt yhden toimittajan varaan. Tämä ei ole poikkeus vaan tunnettu riski, joka voidaan välttää sopimalla oikeuksista ja dokumentaatiosta jo hankintavaiheessa.
Oikeudet ovat kuitenkin vain puolet asiasta. Vaikka lähdekoodi olisi tilaajan omaisuutta, irtautuminen voi olla haastavaa, jos dokumentaatiota ei ole tai integraatiopisteitä ei ole kuvattu. Uusi toimittaja joutuu tällöin selvittämään järjestelmän toimintalogiikan koodista käsin, ja se maksaa. Tästä syystä dokumentaatiovaatimus kannattaa kirjata sopimukseen yhtä täsmällisesti kuin oikeudetkin, ja mieluiten niin, että dokumentaatio päivittyy ylläpidon yhteydessä eikä vasta yhteistyön päättyessä.
Irtautumisen todellinen hinta ei ole vain mahdollinen sopimussakko. Siihen kuuluu tiedon ja dokumentaation siirto, uuden toimittajan perehdytys ja usein myös rinnakkaiskäyttöjakso, jonka aikana molemmat järjestelmät pyörivät yhtä aikaa. Nämä kustannukset jäävät helposti huomaamatta, kunnes tilanne on jo käsillä.
Miksi koko ketju kannattaa nähdä yhtenä kokonaisuutena
Nämä vaiheet eivät ole toisistaan irrallisia. Ulkoistuspäätöksen aikana tehdyt valinnat vaikuttavat siihen, millaiseksi ylläpito muodostuu. Käyttöönotossa syntyneet integraatiot ja niiden dokumentaatio määrittävät, kuinka helposti järjestelmää voi myöhemmin kehittää. Ylläpidon aikana syntyy teknistä velkaa, jos aikataulupaineet ohjaavat päätöksiä. Kertynyt velka puolestaan määrittää, kuinka helppoa tai vaikeaa irtautuminen lopulta on.
Kun koko ketju nähdään yhtenä kokonaisuutena, moni myöhemmin kallis yllätys voidaan ennakoida jo hankintavaiheessa. Tämä ei tarkoita, että kaikkea pitäisi osata etukäteen. Se tarkoittaa, että oikeat kysymykset kannattaa esittää ajoissa, ei vasta silloin kun ongelma on jo edessä.
Mitä kannattaa selvittää ennen sopimuksen allekirjoittamista
Muutama kysymys, joka kannattaa käydä läpi jo ennen kuin sopimus allekirjoitetaan:
Kuka omistaa lähdekoodin ja dokumentaation? Tämä ratkaisee, kuinka vapaasti järjestelmää voi myöhemmin kehittää tai siirtää toiselle toimittajalle.
Mitä ylläpito tarkalleen sisältää? Kattaako se pelkän virheiden korjauksen vai myös infrastruktuurin, varmuuskopioinnin palautustestauksineen, tietoturvapäivitykset ja suorituskyvyn seurannan?
Miten ylläpidon hinnoittelu kehittyy ajan myötä? Sopimuksesta kannattaa löytyä selkeät periaatteet hinnankorotuksille, ei vain lähtöhinta.
Mihin järjestelmiin integroidutaan ja kuka vastaa niiden rajapinnoista? Jos integraation toinen pää on kolmannen osapuolen hallussa, kannattaa sopia etukäteen, kenen vastuulla viivästykset ja muutokset ovat.
Miten teknisestä velasta raportoidaan? Jos toimittaja ei osaa vastata tähän kysymykseen, se on itsessään tieto.
Mitä irtautuminen käytännössä vaatisi? Tiedonsiirto, dokumentaatio ja mahdollinen rinnakkaiskäyttö kannattaa käydä läpi periaatteen tasolla jo ennen kuin niitä tarvitaan.
Näihin kysymyksiin vastaaminen ei takaa ongelmatonta hanketta. Se kuitenkin siirtää useimmat isot yllätykset sinne, missä niihin on vielä helppo vaikuttaa: neuvottelupöytään, ei kolme vuotta myöhemmin syntyneeseen kriisiin.
Tarvitsetko apua?
Mietitkö ylläpidon kustannuksia, integraatioita tai toimittajariippuvuutta omassa järjestelmässäsi? Keskustelemme mielellämme tilanteestanne.
Varaa aika tapaamiseenPerehdy lisää
Koostimme muistilistan yrityksille, jotka ovat ohjelmistotoimittajan valinnan edessä.
Katso muistilistaTutustu, miten voimme auttaa sinua rakentamaan ja ylläpitämään järjestelmiäsi.
OhjelmistokehitysPerehdy, miten voit lähteä kanssamme ketterästi liikkeelle.
Digikartoitus