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. 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)
- Teknistä velkaa, joka on suurella todennäköisyydellä siis heikompaa laatua
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".
Mitä on tekninen velka?
Tässäkään asiassa 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.
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.
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.
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.
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ä.
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. Pahimmassa tilanteessa joudutaan mahdollisesti palkkaamaan jopa ulkoinen konsultti selvittämään ja korjaamaan itse aiheutettua ongelmien sekamelskaa.
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.
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.
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ä.
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.
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?
Menikö tunteisiin? Herättikö ajatuksia? Jaa ne meidän kanssamme LinkedIn-sivullamme.
Kuvitus: Inga Metsola