Search
  • Datapääoma | Tommi & Markku

Tekninen velka ei näy kirjanpidossa. Pitäisikö näkyä? Vältä “korkoa korolle”-ilmiötä!

Tekninen velka, tuo erityisesti digitaalisen ratkaisukehityksen ammattilaisille tuttu asia, ja eritoten sen aiheuttamat seuraukset tulee jo saattaa paremmin myös liiketoimintajohdon tietoisuuteen.


https://dilbert.com/strip/2017-01-03
https://dilbert.com/strip/2017-01-03

Hyvä lukija, jos tunnistat itsesi liiketoimintajohtajaksi tai jos sinulla on vastuullasi edes jonkin verran ATK:ta tai digitaalista ratkaisukehityksen johtamista, niin tämä kirjoitus on kohdennettu erityisesti sinulle (muut: saa ja kannattaa lukea siitä huolimatta pidemmälle!). Ymmärräthän, että joka ikinen kerta, kun vaadit nopeita tuloksia tai toteat välinpitämättömästi, että “joo joo, tehkää nyt vaan jotain nopeasti” digitaalisen ratkaisukehityksen ammattilaisille, tulet todennäköisesti ottaneeksi kontollesi teknistä velkaa. Unohtamalla muut tekijät ja vaatimalla vain laiskasti “kovempaa kehitysnopeutta”, tulet projektikolmion lakien vallitessa saamaan syliisi samaan aikaan sivutuotteena jompaa kumpaa seuraavista:


  • Vähemmän lopputuotoksia (jotainhan pitää pudottaa laajuudesta/scopesta pois, jos resurssit pysyvät samana tai vaihtoehtoisesti resurssien lisääminen hidastaa projektia)

  • Teknistä velkaa, joka on suurella todennäköisyydellä siis heikompaa laatua


Ennen teknisen velan määritelmän syväsukellusta on hyvä palauttaa mieleen myös digitaalisen ratkaisukehityksen maailman työkaluista yksi tärkein: projektikolmio. Elämme aikaa, jossa nopeus ja nopeat toimenpiteet ovat valttia ja vaikka projektikolmio ja sen käyttö liitetäänkin nykyään poikkeuksetta “wanhan liiton vesiputousmallin mukaiseen kehittämiseen”, on siitä kuitenkin hyvä muistaa perusasiat: venytit sitten mitä kulmaa tai sivutahkoa tahansa, yksi asia on ATK-hankkeissa varmaa: tulet joko tiedostaen tai tiedostamatta kerryttäneeksi teknistä velkaa. Se on terminä IT- ja ATK-ammattilaisille pääsääntöisesti selkeä ja ymmärrettävä asia, mutta sen ymmärrys ATK- ja digiosastojen ulkopuolella kaipaa usein terästystä.

Jos tarkastelemme asiaa datan ja sen toimitusketjujen johtamisen näkökulmasta, yksi varsin perinteinen skenaario lienee se, että “joku” meni ulkoistamaan datan ja sen johtamisen IT-osastolle ja sen jälkeen mikään asia ei enää onnistu liiketoiminnan haluamalla aikataululla.

Kuten jo aikaisemmissa kirjoituksissamme totesimme, organisaatiosi datatoimitusketjut ovat olemassa, halusit sitä tai et. Datatoimitusketjut ovat muodostuneet organisaatiosi ytimeen vuosien ja vuosikymmenien saatossa ja useimmat niistä eivät todennäköisesti edes kestä päivänvaloa. Aivan kuten se lahoamispisteessä oleva, “itse koodattu ERP-järjestelmäkään”. Velkaa on siis otettu, joko tiedostaen tai mikä pahinta: tiedostamatta. Mikäli organisaatiossa ummistetaan silmät datatoimitusketjuille sekä niiden tehokkuudelle, annetaan tässä myös alkusysäys potentiaaliselle kaikkien aikojen koronkorkopommille ja sen kumuloitumiselle. Kuulostaako vakavalta? Kyllä, sitä se pahimmillaan onkin. Avataan asiaa hieman tarkemmin ja hypätään nyt teknisen velan käsitteeseen ja sen määritelmään.


Mitä on tekninen velka?


Tässäkään asiassa (kuten ei itse asiassa datassa ja sen toimitusketjuissakaan) ei lopulta ole mitään ihmeellisempää mystiikkaa. Tekninen velka nimittäin toimii, kuten mikä tahansa muukin velka: se pitää maksaa aikanaan pois tavalla tai toisella. Riippuen korkotasosta ja takaisinmaksuajasta, lopullinen maksuun erääntyvä potti voi valitettavasti kasvaa hallitsemattomankin suureksi.


Liian usein tekninen velka koetaan kuitenkin hankalaksi ja vaikeaksi asiaksi ymmärtää ja se nähdään primääristi osana “uponneita kustannuksia”. Uponneiden kustannusten käsitteellä onkin sitten tunnetusti monia, toinen toistakin mielenkiintoisempia kiertoilmauksia. Milloin joku “integraatio on vähän haastava”, milloin joku toistuva asia pitää teettää aina sillä yhdellä tyypillä, kun kukaan muu ei asiaa osaa (tai viitsi!) ratkaista. Ehkä dokumentaatio jäi aikanaan tekemättä ja nyt rimpuillaan spagettisen, jo hieman bolognesen makuisen softakoodin ylläpidon kanssa. Joskus kriittisiä ja tehdyksi tarkoitettuja asioita yksinkertaisesti vain jätetään tekemättä, koska ne ovat joko liian vaikeita, hitaita tai kallista toteuttaa. Jos tarkastelemme asiaa datan ja sen toimitusketjujen johtamisen näkökulmasta, yksi varsin perinteinen skenaario lienee se, että “joku” meni ulkoistamaan datan ja sen johtamisen IT-osastolle ja sen jälkeen mikään asia ei enää onnistu liiketoiminnan haluamalla aikataululla. Olisiko tässä kenties tehty pahin virhearvio mies/naismuistiin: datahan ei edes ole IT-asia, eikä siten IT:n asia hoitaa!


Ehdoton klassikko on kuitenkin se, että joku kriittinen, liiketoiminnan toiminnanohjausjärjestelmä jätetään uusimatta “korkeiden kustannusten takia”. Toisin sanoen: eilisen järjestelmäinvestointi on tänään ihka oikeaa ja kouriintuntuvaa teknistä velkaa! Itse asiassa kaikki edellä mainitut esimerkit ovat teknisen velan ilmentymiä arjen johtamisen näkökulmasta.



Miksi teknistä velkaa syntyy tai miksi sitä otetaan?


Miksi teknistä velkaa sitten kertyy? Juurisyyt löytyvät tyypillisesti joko projektien monimutkaisuudesta, osittamisen haasteesta ja osaamisen puutteesta. Usein myös liiketoiminnalta saattaa puuttua riittävän tason ymmärrys digitaalisen ratkaisukehityksen perusasioista. Liiketoimintajohto voi pahimmillaan (tietoisella tai tiedostamattomalla) painostuksellaan sysätä ensiaskeleet, ongelmallisen teknisen velan syntymiselle. Datatoimitusketjujen johtaminen on vielä hyvin uusi ilmiö. Yritykset ja organisaatiot ovat matkan alussa, mitä tulee kokonaisarkkitehtuurien johtamiseen ja samalla pitäisi ottaa myös datatoimitusketjut viimein haltuun. Tässä on jo aika paljon vaadittuna. Liiketoimintajohtamisen kehitys polkee Suomessa hieman takamatkalla näiden osaamislajien kehityksessä, ja yritykset hapuilevat joka vuosi ilmestyvien hype-aaltojen perässä keskittymättä ydinliiketoiminnan kehittämiseen ja sen kasvattamiseen.

Tärkeintä teknisen velan suhteen on tunnustaa sen olemassaolo ja oppia tunnistamaan sen läsnäolo. Tahaton tekninen velka ilmenee oppirahoina hyvinkin nopeasti; “vahinkoja sattuu”.

Kuten missä tahansa digitaalisessa ratkaisukehityshankkeessa, tekninen velka kerryttää ylläpidon kuormaa ja nostaa kustannuksia. Asiaa voi hahmottaa laskemalla valitun datatoimitusketjun kustannusta luonnin hetkessä käytön hetkeen. Jos pelkästään tämän kustannuksen esittäminen on haastavaa organisaatioissa, on se jo riittävä todiste kertomaan, että sinulla on teknistä velkaa. Tiedätkö esimerkiksi paljonko organisaatiossasi maksaa tilinpäätöksen luominen? Oletko miettinyt voisiko se olla kenties kustannustehokkaampaa? Oletko selvittänyt mikä on datatoimitusketjun osuus kokonaiskustannuksista ja ennen kaikkea, onko tuohon pottiin laskettu mukaan myös manuaalinen työ, joka tehdään esimerkiksi ostolaskujen tiliöimisessä? Ja niin edelleen. Vanha satu kolmesta pienestä porsaasta kuvastaa hyvin teknisen velan perusluonnetta: heikosti rakennetut ratkaisut eivät lopulta yksinkertaisesti kestä ympäröivän maailman painetta.


Miten tekniseen velkaan tulisi suhtautua? Muista “korkoa korolle”-ilmiö!


Tärkeintä teknisen velan suhteen onkin tunnustaa sen olemassaolo ja oppia tunnistamaan se osana operatiivista arkea. Tahaton tekninen velka ilmenee oppirahoina hyvinkin nopeasti ja tällaiset, “fail fast and cheap”-tyyppiset tilanteet voidaankin usein ohittaa olankohautuksella: “vahinkoja sattuu”. Kaikessa kehittämisessä tulisi kuitenkin aina merkitä ylös kaikki otettu tekninen velka ja tehdä siitä näin näkyvää. Olemme saaneet vuosien saatossa vierailla YLE:llä useita kertoja ja jokaisella kerralla vakuutumme siitä ammattimaisuudesta ja kunnianhimon tasosta, jolla digitaalista ratkaisukehitystä heillä vaalitaan. Erityisesti YLE:n tavassa toimia vaikutuksen meihin on tehnyt nimen omaan "teknisen velan läpinäkyvyys" eli konkreettiset, tälle asialle omistetut kanban-taulut, joissa tuo velka oli näkyvillä. Tekninen velka pitää olla näkyvillä, jotta sitä voi johtaa.


Eli aivan kuten “normaalit” kehitysbacklogin kehitettävät uudet ominaisuudetkin ovat näkyvillä, myös tekninen velka tulisi olla selkeästi jossain kirjattuna ylös (toim.huom. “teknisen velan kuvaava data”). Jos joku asia ei ole näkyvillä, tätä asiaa et voi johtaa. Tekninen velka myös toimii kuten koron korko. Jos maksamme velan kerralla pois, kustannukset ovat jollain tasolla mitattavissa. Jos kuitenkin venytämme maksuaikaa pitkälle tulevaisuuteen, tulemme näin raahaamaan myös velkaa, eli ylimääräistä, vältettävissä ollutta operatiivista tekemistämme mukanamme. Asiaa voi tarkastella finassinäkökulmasta myös seuraavasti: voimme valita, otammeko nyt saman tien mittavan investointikustannuksen vai maksammeko kulun pois operatiivisena osamaksusopimuksella tuntuvalla korolla? Nämä ovat valintoja, jotka olisi hyvä tehdä tiedostaen eikä tiedostamatta.


Taloudesta tuttu “korkoa korolle”-ilmiö on siis läsnä myös teknisen velan tapauksessa. Kun teknisen velan korjaus- ja takaisinmaksutoimenpiteisiin ryhdytään viipymättä sen tunnistamishetken jälkeen, on korjauskustannus (takaisinmaksukustannus) myös halvempi. Tämä johtuu siitä, että kaikki korjaamisen liittyvät ja tarvittavat resurssit ovat edelleen läsnä. Lisäksi teknisen velan kohde on “tuoreessa muistissa” ja sen tunnistamisen kautta ratkaisun avaimet ovat helpommin saatavilla. Jos taas annamme ajan kulua ja odottelemme pitkään, “korkoa korolle”-ilmiö iskee välittömästi: ne resurssit, jotka olivat velan ottamishetkellä läsnä, eivät välttämättä enää ole käytettävissä ja jonkun muun tahon pitää ensin selvittää miksi velka on otettu ja miten se maksetaan takaisin. Asian uudelleen opettelu on merkittävästi kalliimpaa, kuin vaihtoehtoisesti saman asian korjaaminen välittömästi. Pahimmassa tilanteessa joudutaan mahdollisesti palkkaamaan jopa ulkoinen konsultti selvittämään ja korjaamaan itse aiheutettua ongelmien sekamelskaa. Tällaisen konsultin kustannukset ovat hyvä esimerkki “korkoa korolle”-ilmiöstä, jonka juurisyy on nimenomaan tekninen velka, joka on otettu taseeseen jo mahdollisesti paljon, paljon aikaisemmin.


Tekninen velka mahdollistajana? Miten sitä johdetaan oikein?



Miten teknistä velkaa ja mahdollisesti sen syntymistä voi sitten estää tai johtaa? Tärkein asia on yksinkertaisesti siihen suhtautuminen normaalina arjessa tapahtuvana asiana, eikä niinkään tabuna, josta ei voi puhua ja jos puhutaan niin se indikoi korkeintaan vain siitä, että joku on mokannut tai ei ole vain osannut tehdä laadukasta työtä. Ei, tästä ei ole kyse, vaan kuten jo aiemmin tuotiin esiin: valitettavan usein teknisen velankin juurisyyt piilevät huonossa johtamisessa ja perusasioiden kuten projektikolmion lainalaisuuksien ymmärtämättömyydessä.


Tekninen velka ei kuitenkaan aina ole pelkästään paha ja jollain tavalla negatiivinen lieveilmiö. Tekninen velka, kuten mikä tahansa velka, voidaan, ja pitääkin usein ajatella myös mahdollistajana. Mikäli esimerkiksi ratkaisukehityshankkeellesi asetettu “time-to-market”-vaatimus on äärimmäisen kova ja ennusteet näyttävät lupaavalta, voi tekninen velka parhaimmillaan toimia vipuvartena liikevaihdon kasvattamiseen ja kenties jopa markkinaposition vahvistamiseen. On kuitenkin syytä muistaa, että ainoastaan kun tekninen velka on oikeasti ymmärretty ja kirjattu ylös, on sen korjaus- ja takaisinmaksukustannuksiakin helpompi käsitellä ja näin sitä voidaan johtaa kuten mitä tahansa instrumenttia - tekninen velka voi näin toimia myös tehokkaana työkaluna!


Teknisen velan merkitys datatoimitusketjujen tehokkuudelle ja johtamiselle. Älä ota velkaa datan luonnin hetkellä!


Palataan lopuksi dataan ja sen kahteen kohtalon hetkeen: luonnin hetkeen sekä hyödyntämishetkeen. Näistä kohtalon hetkistä se ensimmäinen, datan luonnin hetki on periaatetasolla se hetki, jossa mitataan jokaisen organisaation johtamisen laatu. Tässä hetkessä teknistä velkaa (lue: vaillinainen data, epätarkka data, virheellinen data) ei pidä missään nimessä ottaa.


Toistetaan: datan luonnin hetkellä ei tule koskaan ottaa teknistä velkaa!


Data- ja informaatiovirrat lähtevät aina luonnin hetkestä, jonka jälkeen ne haarautuvat useiden ketjujen kautta käytön hetkeen ja sen lukuisiin käyttötapauksiin. Mikäli tekninen velka, eli datan laatuongelma on päässyt syntymään luonnin hetkessä, kertaantuu sen kustannus monikertaisena kohti hyödyntämisen hetkeä ja näin myös takaisinmaksun koronkorko kumuloituu moninkertaisena.


Kuten edellä nähtiin, datan toimitusketjujen johtamisen ei tarvitse olla mitenkään erilaista kuin se mitä niin monelle opiskelijalle opetetaan jo koulun penkillä. Laatujohtamisen perusoppien mukaisesti laatuvirheiden korjauskustannukset kasvavat eksponentiaalisesti mitä pidemmälle toimitusketjussa kuljetaan ”tehtaalta” kohti asiakasta. Tehtaalla virheiden korjauskustannus on 1x, seuraavassa vaiheessa 10x, sitten 100x, sitten 1000x ja luoja ties kuinka isoja. Emme usko, että kenenkään päätä varsinaisesti silitellään, kun esimerkiksi autonvalmistaja joutuu vetämään kymmeniätuhansia autoja pois asiakkailta takaisin tehtaalle korjaustoimenpiteitä varten. Kysymmekin nyt: miksi ihmeessä siis toimimme datan, tuon 2020-luvun tärkeimmän aineettoman pääoman kanssa kuitenkin päinvastoin? Kallispalkkaiset asiantuntijat ”prosessoivat” ja ”fiilaavat ja höyläävät” dataa juuri ennen sen hyödyntämishetkeä eli esim. dashboard-ratkaisua tai vaikkapa tekoälyratkaisua. Eli juuri siellä missä laadun korjaamisen kustannukset ovat korkeimmillaan! Jokainen organisaatio, jossa tällaista toimintaa harrastetaan, on velvollinen kysymään tuon organisaation toimitusjohtajalta, mitä mieltä hän on tästä toimintatavasta? Mitä luulette hänen vastaavan? Otetaanko kustannukset 1x vai 10 000x? Aivan.

Datan toimitusketjujen yläjuoksulla virheiden korjaaminen alentaa siis alajuoksun kustannuksia. Jos siis kuitenkin päätät vivuttaa kehitystä teknisellä velalla, älä tee sitä yläjuoksulla!


Organisaation datapääoma on:


Dataomaisuus - [velvoitteet sis. tekninen velka].


Tiedätkö sinä mikä on organisaatiosi datapääoman todellinen arvo?


- Markku & Tommi, Datapääoma


Ps. Menikö tunteisiin? Herättikö ajatuksia? Jaa ne meidän kanssamme LinkedIn-sivullamme: https://www.linkedin.com/company/datapaaoma/


Kuvitus: Inga Metsola


344 views0 comments