Räätälöityjen ohjelmistojen tarpeen ennustettiin vähenevän, kun useat valtavirtateknologiat ja monikäyttöiset konfiguroitavat SaaS-ohjelmistoalustat alkoivat yleistyä. Molemmille lähestymistavoille on kuitenkin löytynyt selkeä perusteltu rooli yritysten digitalisoidessa omaa toimintaansa ja palvellessaan entistä vaativampia loppukäyttäjiä ja asiakkaita.

Näihin osa-alueisiin käytetään Suomessa satoja miljoonia euroja vuodessa joko investoimalla omiin kehittäjiin tai ostamalla kehitystä palveluna, mutta saadaanko tästä panostuksesta kaikki irti?  Lue artikkelin lopusta, miten asiantuntijat näkevät tilanteen Suomessa.

 

Hyödyksi vai hukkaan?

Kaikessa ohjelmistokehityksessä pitäisi toteuttaa pitkällä aikavälillä riittävä arvontuotto. Omaa ohjelmistoa kehitettäessä myytäväksi tuotteeksi tulisi sen liikevaihdon pidemmän ajanjakson yli tarkasteltuna olla vähintään viisinkertainen tuotekehitysinvestointiin nähden, jotta myynti-, markkinointi-, tuki- ja hallinnointi-investoinnit katetaan ja yritykselle syntyy tulosta.

Kehitettäessä räätälöityä ohjelmistoa omiin tarpeisiin on tuotettua arvoa hankalampi mitata ja sitä harvoin tietoisesti tavoitellaan tai mitataan. Räätälöidyn ohjelmiston arvo voi syntyä yhden tai useamman osa-alueen yhdistelmänä, esimerkiksi automatisoinnista, prosessitehostamisesta, paremmasta loppuasiakaskokemuksesta tai lisämyynnistä yrityksen tuotteille ja palveluille.

 

Webinaari-itseohjautuvuudesta-yhdessä-ohjautuvuuteen-landing-page

 

Oikeita valintoja sumun keskellä

Ohjelmistokehitysinvestointien johtaminen ja suuntaaminen vaikeutuu vielä entisestään, kun monet uudet teknologiat, kuten DevOps, AI, mikropalveluarkkitehtuurit, pilvialustat ja data-analytiikka, sekä loppukäyttäjävaatimukset kehittyvät valtavalla vauhdilla ja kohtaavat omien nykyohjelmistojen kehitysvelan.

Ei ihme, että digitaalisten palvelujen yksiköiden ja tuotekehityksen ohjelmistokehityksen suuntaamisessa muhii mahdollisesti huikea tehostamispotentiaali.

 

Mistä hukka syntyy?

Kysyin toimialan johtavilta yrityksiltä ja asiantuntijoilta mistä osa-alueesta he kokevat isoimman kehityspotentiaalin ja hyödyn omissa tilanteissaan ja toimialalla yleensä. Esittelin heille seuraavat neljä väittämää. Tulokset mielipiteistä esitellään artikkelin lopun yhteenvedossa.

  1. Ohjelmistokehitykseen liittyvät päätökset ovat liiketoiminnallisesti oikein suunnattuja ja pitkäjänteisesti arvoa tuottavia
  2. Ohjelmistojen arkkitehtuurivalinnat on toteutettu niin, että ohjelmiston elinkaarikustannukset ovat hallinnassa
  3. Ohjelmistokehityksen prosessit ja toteuttaminen on tehokasta, toimitukset ovat nopeita eikä laatuongelmia synny
  4. Jatkuvasti kehittyvä ohjelmistokehityksen toteutuskapasiteetti on hallittavaa, joustavaa ja kustannustehokasta

Tarkastellaan näitä neljää osa-aluetta nyt hieman tarkemmin.

 

VÄITTÄMÄ 1:
Ohjelmistokehitykseen liittyvät päätökset ovat liiketoiminnallisesti oikein suunnattuja ja pitkäjänteisesti arvoa tuottavia

Oikeilla markkina-ja asiakasvalinnoilla sekä sidosryhmien ymmärtämisellä varmistetaan, että kehitettävien ohjelmisto-ominaisuuksien peitto osuu mahdollisimman tehokkaasti ja oikea-aikaisesti tarpeeseen.

Kokeileva asiakaspalautetta ja kysyntää jatkuvasti ymmärtävä iteratiivinen liiketoimintasuunnittelu ja palautteen kautta oppiminen lienee paras tapa varmistaa, että arvon tuotanto pysyy tasapainossa panostusten kanssa. Täydellinenkään ohjelmistokehityskyvykkyys ei auta, jos arvonluonnin hyötysuhde on heikko, asiakasvaatimukset paisuvat ja työmääräarviot kasvavat hallitsemattomasti.

Räätälöidyn ohjelmiston arvonluontia tekee haastavammaksi sen ainutkertaisuus, jolloin skaalautuvuusefekti on lähtökohtaisesti rajattu. Ohjelmistotuoteliiketoiminnassa taas joudutaan keskiarvoistamaan ominaisuuksia ja tekemään kompromisseja sekä osin yli-investoimaan laatuun esimerkiksi suurten loppuasiakasmäärien ja sopimusvelvoitteiden riskinhallinnan vuoksi.  Suomen pienehköt kotimarkkinat rajaavat ohjelmistoliiketoiminnan skaalautuvuusmahdollisuuksia.

Elinkaaren yli toteutettavat kehityskustannukset saattavat jäädä epähuomiossa roikkumaan liian korkeaksi, kun uusien tilaisuuksien määrä hiipuu, nykyasiakkaat sanovat irti sopimuksia, sopimusten ylläpitovelvoitteet ovat jääneet liian laveiksi tai yrityksen sisäinen ohjelmiston hyödyntäminen jää vajaaksi. Palveluita ei uskalleta ajaa hallitusti alas ja vapauttaa kapasiteettia muualle. Toisaalta lyhytnäköisyys ja poukkoilu ohjelmiston elinkaaren aikana lisää helposti hukkaa.

 

VÄITTÄMÄ 2:
Ohjelmistojen arkkitehtuurivalinnat on toteutettu niin, että ohjelmiston elinkaarikustannukset ovat hallinnassa

Kun on ensin varmistettu, että ohjelmistoinvestoinnit on suunnattu oikeaan liiketoimintatarpeeseen nousee ammattimaisen ohjelmistoarkkitehtuurin merkitys kustannusten hallinnassa keskeiseen rooliin. Ohjelmistoarkkitehtuurilla ohjataan pitkäjänteisesti tasapainoa lyhyen ja pitkän aikavälin hyödyn optimointiin. Jos ohjelmiston käyttötarve on lyhytaikainen, ohjelmisto on yksinkertainen ja käyttäjämäärät pieniä selvitetään kevyemmällä pohdinnalla, mutta päinvastaisessa tapauksessa väärillä ratkaisuilla kustannukset saattavat moninkertaistua ja arvontuotannon hyötysuhde rapautua.

Hyvä arkkitehtuurityö ottaa huomioon mm. seuraavia näkökulmia yli ohjelmiston elinkaaren:

  • Ohjelmiston sisäinen rakenne ja joustavuus tarpeiden muuttuessa
  • Teknologioiden kypsyys ja uusien teknologioiden muutosvauhti
  • Skaalautuvuus, luotettavuus, tietoturva, uudelleenkäytettävyys
  • Testattavuus ja jatkuva asiakaspalautteen kerääminen
  • Riippuvuudet muista ohjelmistoista, rajapinnat ja integraatiot
  • Uudelleenkäytettävyys
  • Datamallit ja datan laatu
  • Lisenssien ja pilviohjelmistojen kustannukset, infrastruktuuriresurssien käyttö
  • Ohjelmiston kehitysprosessin ja ylläpidon optimointi suhteessa muihin kehitettäviin ohjelmistoihin
  • Ohjelmiston siirrettävyys toisiin ympäristöihin
  • Käyttöliittymät, eri käyttöympäristöt ja kieliversiot
  • IP suojaus ja hallinta
  • Osaamisen saatavuus ja kustannukset

 

VÄITTÄMÄ 3:
Ohjelmistokehityksen prosessit ja toteuttaminen on tehokasta, toimitukset ovat nopeita eikä laatuongelmia synny

Taitava ohjelmistokehittäjä on tuottoisampi kuin kymmenen keskivertoa sanotaan. Yksinpuurtava guru ei kuitenkaan yksin auta paljoakaan, mikäli tiimi ei yhdessä toteuta arvoa tuottavaa backlogin toiminnallisuuksia, seuraa arkkitehtuurisuuntaviivoja tai toimi saumattomasti yhteen toisiaan täydentäen ja tukien.

Huonolaatuinen ja heikosti dokumentoitu koodi johtaa henkilö- tai toimittajariippuvuuteen, laatuongelmiin, hitaaseen vianselvitykseen ja heikkoon ylläpidettävyyteen. Mitä toistettavampi ja ennakoitavampi kehitysprosessi on sitä helpompi sitä on mitata, oppia ja kehittyä matkan varrella ja saada toiminnallisuuksia nopeammin tuotantoon. Läpinäkyvyys helpottaa eri tiimin välistä kommunikaatiota ja kokonaisuuden johtamista. 

 

frantic-ketteryysvalmennus-1

 
VÄITTÄMÄ 4:
Jatkuvasti kehittyvä ohjelmistokehityksen toteutuskapasiteetti on hallittavaa, joustavaa ja kustannustehokasta

Olisihan se hienoa, jos kehityshankkeisiin tarvittavaa osaamista olisi aina oikeaan aikaan oikea määrä saatavilla kustannustehokkaasti. Omalla rekrytoinnilla päästään laskennallisesti usein alempaan kuukausikuluun, mutta hyötysuhdetta heikentää kiinteä resurssivaraus, panostukset jatkuvaan osaamisen kehittämiseen sekä riski mahdollisiin vähennystarpeisiin.

Osaamiskapasiteetin ulkoistus nostanee näennäisesti laskennallisia kustannuksia ja lisää huonosti hallittuna toimittajariippuvuutta, mutta oikein johdettuna lisää joustavuutta sekä varmistaa tarvittavan osaamisen saamisen juuri oikeaan aikaan. Hukkaa on helpompi hallita.

 

Miten hyötysuhdetta voi arvioida?

Kaikissa näissä neljän väittämän alueella syntyy jonkin verran hukkaa ideaalitilanteeseen nähden ja tilanne luonnollisesti muuttuu ajan funktiona.

F3A5136A-E540-47C0-8555-9E4095D918A2

Yhtenä ajanhetkenä voi ohjelmistokehityksen tehokkuuden yksinkertaistaa seuraavalla hyvin pelkistetyllä ajatusmallilla: 

 

Ohjelmistokehityksen hyötysuhde = (1 – LTH %) x (1 – ARKH %) x (1 – PRH %) x (1 – KPH %), jossa LTH=Liiketoimintahukka, ARKH=Arkkitehtuurihukka, PRH= Prosessihukka ja KPH = Kapasiteettihukka

'

Mikäli kaikilla neljällä osa-alueilla toimitaan lähes täydellisesti vain esimerkiksi 20% hukalla, niin ohjelmistokehityksen hyötysuhde jäisi kuitenkin tämän yksinkertaisella mallilla vain 40%:iin. Esimerkiksi miljoonan vuosi-investoinnista peräti 600 t€ käytettäisiin tällöin turhaan. Pienentämällä kutakin hukkakerrointa 5%:lla säästettäisiin tässä esimerkissä vuositasolla jo 120 t€.

 

Missä Suomessa mennään?

Mitä mieltä olivat toistakymmentä suomalaista ohjelmistokehitysliiketoiminnan ammattilaista näiden väitteiden tilasta ja merkityksestä tätä blogia varten tekemässäni kevyessä kyselyssä. Vastaajien kirjalliset vastaukset on arvioitu 0-80% hukkaprosenteiksi kussakin osa-alueissa. Vastausten mukaan jokainen osa-alue katsottiin hyvin merkityksellisiksi ja olivat painoarvoiltaan hyvin lähellä toisiaan.

 

Koetut oman toimialan hukkaprosentit ja hyötysuhde

 

Liiketoimintahukka:  18%

Arkkitehtuurihukka: 55%

Prosessihukka: 45%

Kapasiteettihukka: 60%

Hyötysuhde: 8%

 

Koetut omien organisaatioiden hukkaprosentit ja hyötysuhde:

 

Liiketoimintahukka: 26%

Arkkitehtuurihukka: 30%

Prosessihukka: 67%

Kapasiteettihukka: 55%

Hyötysuhde: 8%

 

Todelllisuus toimialalla eikä yritysten omassa tilanteissa ei varmaan  ole ihan näin synkkä: yli 90% kokonaispanostuksesta menisi hukkaan. Korkeat hukka-arviot arkkitehtuuri-, prosessi- ja kapasiteettihukissa yllättivät ja osoittavat, että tehostamismahdollisuuksia laaja-alaisesti varmasti on. Toisaalta  arvioidut liiketoimintaosalueen hukat toimialalla voivat olla arvoitu jopa alakanttiin, kun esimerkiksi aika pieni osa ohjelmistostartup-organisaatioita lopulta onnistuu kannattavasti asiakastarpeisiin vastaamaan vaikka teknisesti ohjelmistoratkaisut toimisivat. 

Tiedätkö mikä on oman organisaatiosi ohjelmistokehityksen hukka ja paljon siinä on hyödyntämispotentiaalia?

 

Lisätietoa palvelusivuiltamme

Ota yhteyttä ja kysy lisää

 

toimitusjohtaja-ilman-johtoryhmaa_listing

Artikkelin kirjoittaja Codenton toimitusjohtaja Anthony Gyursanszky aloitti työuransa ohjelmistokehittäjänä Nokialla, mutta sen jälkeen on toiminut liiketoiminnan johtotehtävissä ohjelmisto- ja teknologiayhtiöissä , kuten F-Secure, SSH, Tellabs ja Microsoft sekä ohjelmisto- ja IT-palveluyhtiöissä Elisa Appelsiini, Innofactor  ja Endero/Knowit. Codento on asiakkaan etua ajatteleva ohjelmistopalveluyritys, joka pyrkii haastamaan asiakkaita kehityspanostustensa suuntaamisessa. 

 

 

Tilaa uutiskirje

Codento