#BIZML: Asiakkaan elinkaaren arvon mallinnus hyödyttää sekä asiakasta että toimittajaa

Asiakkaan elinkaaren arvon mallinnus hyödyttää sekä asiakasta että toimittajaa

 

Kirjoittaja: Janne Flinck, Codento

 

Johdatus asiakkaan elinkaaren arvoon

Asiakasanalytiikka ei tarkoita jokaisen euron optimointia asiakassuhteessa, eikä keskittymistä lyhyen aikavälin toimintaan. Asiakasanalytiikan tulisi pyrkiä maksimoimaan jokaisen asiakassuhteen täysi arvo. Tätä ”täyden arvon” mittaria kutsutaan asiakkaan elinkaaren arvoksi (LTV).

Yrityksen tulisi tarkastella kuinka arvokkaita asiakkaat ovat olleet aiemmin, mutta puhtaasti tämän arvon ekstrapoloiminen tulevaisuuteen ei todennäköisesti ole tarkin mittari asiakassuhteen tulevaisuuden arvolle.

Mitä arvokkaampi asiakas on yritykselle tulevaisuudessa, sitä enemmän yrityksen tulisi panostaa kyseiseen asiakassuhteeseen. Asiakkaan elinkaariarvoa tulisi ajatella win-win-tilanteena yritykselle ja asiakkaalle. Mitä korkeammaksi asiakkaan elinkaaren arvo estimoidaan, sitä todennäköisemmin yrityksen tulisi panostaa kyseiseen asiakassuhteeseen.

Pareto-periaate sanoo, että 20 % asiakkaista edustaa 80 % myynnistä. Mitä jos voisit tunnistaa nämä asiakkaat – ei vain menneisyydessä, vaan myös tulevaisuudessa? LTV:n ennustaminen on datalähtöinen tapa tunnistaa nämä asiakkaat.

 

Liiketoimintastrategia ja elinkaaren arvo

On enemmän tai vähemmän ”tavallisia” tapoja laskea LTV, joista osaa käsittelen tässä artikkelissa. Nämä valmiit laskentamenetelmät voivat toimia jopa sellaisenaan, mutta tärkeintä on, että ne tarjoavat hyviä esimerkkejä alkuun.

Elinkaaren arvon pitäisi olla jotain, joka määrittää yrityksellesi suunnan, koska se on myös osa liiketoimintastrategiaa. Elinkaaren arvo ei ole sama kaikille yrityksille ja se voi jopa muuttua ajan myötä saman yrityksen kohdalla.

Jos yrityksen strategia koskee kestävää kasvua, elinkaaren arvoon tulisi sisällyttää joitakin sitä mittaavia tekijöitä. Ehkä asiakkaalla on enemmän strategista arvoa yritykselle, jos hän ostaa kestävämmän version tuotteesta. Tämä ei myöskään ole “aseta ja unohda” -mittari, vaan mittaria tulee tarkastella uudelleen ajan kuluessa, jotta nähdään onko se yhä linjassa yrityksen strategian ja tavoitteiden kanssa.

LTV on tärkeä myös siksi, että siitä voidaan johtaa muita tärkeitä mittareita. Esimerkiksi elinkaaren arvo on luonnollisesti asiakkaan hankintamenojen yläraja, ja brändin kaikkien asiakkaiden elinkaaren arvojen summa on tärkeä mittari liiketoiminnan arvostuksissa.

 

Elinkaaren arvon laskentamenetelmät

Pohjimmiltaan LTV-malleja voidaan käyttää vastaamaan seuraavanlaisiin kysymyksiin:

  • Kuinka monta tapahtumaa asiakas tekee tietyssä tulevassa aikaikkunassa?
  • Kuinka paljon arvoa asiakas tuottaa tietyssä tulevaisuuden aikaikkunassa?
  • Onko asiakas vaarassa jäädä pysyvästi epäaktiiviseksi?

Asiakkaan elinkaaren arvoa ennustaessa yleensä kohdataan erilaisia ongelmia, jotka vaativat erilaisia lähestymistapoja:

  • Nykyisten asiakkaiden tuleva arvo
  • Uusien asiakkaiden tuleva arvo

Monet yritykset ennustavat asiakkaan elinkaaren arvoa vain analysoimalla myynnin kokonaismäärää ilman kontekstia. Esimerkiksi asiakas, joka tekee yhden suuren tilauksen, voi olla vähemmän arvokas kuin toinen asiakas, joka ostaa useita kertoja, mutta pienempiä määriä.

LTV-mallinnus voi auttaa ymmärtämään asiakkaiden ostoprofiileja. Mallintamalla asiakkaan elinkaaren arvoa, organisaatio voi priorisoida seuraavia toimintoja:

  • Mille asiakkaille keskittää enemmän resursseja
  • Kuinka paljon sijoittaa mainontaan
  • Mille asiakkaille kohdistaa mainontaa
  • Kuinka siirtää asiakkaat segmentistä toiseen
  • Hinnoittelustrategiat

LTV-malleja käytetään asiakkaan arvon kvantifiointiin ja yrityksen mahdollisesti toteuttamien toimien vaikutusten arvioimiseen. Tarkastellaan kahta esimerkkiskenaariota elinkaaren arvon laskennassa: sopimukseton ja sopimuksellinen liiketoiminta. Nämä ovat kaksi melko yleistä tapaa lähestyä tuotteen elinkaaren arvon mallintamista.

 

Sopimukseton liiketoiminta

Yksi yksinkertaisimmista tavoista laskea elinkaaren arvo on tarkastella ostojen ja asiakasvuorovaikutusten historiallisia lukuja ja laskea tapahtumien määrä asiakasta kohti ja tapahtuman keskimääräinen arvo euroissa.

Käytettävissä olevien tietojen avulla on rakennettava malli, joka pystyy laskemaan ostotodennäköisyyden asiakasta kohti määritellyssä aikaikkunassa. Kun sinulla on seuraavat kolme mittaria, saat elinkaariarvon kertomalla ne:

LTV = Transaktioiden määrä x Transaktioiden arvo x Oston todennäköisyys

Tässä lähestymistavassa on muutamia haasteita. Ensinnäkin, mikä on transaktion arvo? Onko se myynti, tuotto vai myyty määrä? Kasvattaako jonkin tuotteen tietty ominaisuus myyntitapahtuman arvoa?

Transaktion arvon tulee olla jotain, joka noudattaa liiketoimintastrategiaasi ja edistää pitkäaikaisia ​​asiakassuhteita lyhyen aikavälin voiton tavoittelun sijaan.

Toinen haaste on, että uusien asiakkaiden elinkaarten arvojen ennustaminen vaatii erilaisia ​​menetelmiä, koska dataa historiallisista tapahtumista ei ole.

 

Sopimuksellinen liiketoiminta

Tilausmallissa elinkaaren arvo on erilainen kuin sopimuksettomassa liiketoiminnassa, koska asiakas on sitoutunut ostamaan sinulta sopimuksen voimassaolon ajan. Asiakasvaihtuvuuden mittaaminen taas on helppoa tilausmallissa. 

Esimerkiksi lehden kuukausitilaukselle tai suoratoistopalvelulle voidaan laskea elinkaaren arvo sen mukaan kuinka monta kuukautta asiakas tilaa uudelleen:

LTV = Selviytymisprosentti x Tilauksen arvo x Diskonttokorko

Selviytymisprosentti kuukausittain olisi niiden asiakkaiden osuus, jotka säilyttävät tilauksensa. Tämä voidaan arvioida tiedoista asiakassegmenttikohtaisesti elinaika-analyysi avulla. Tilauksen arvo voisi olla liikevaihto vähennettynä palvelun tarjoamisen kustannuksilla ja asiakkaan hankintakustannuksilla.

 

Toimenpiteet LTV:n perusteella

Nyt sinulla on asiakassuhteen elinkaaren arvo, johon organisaatiosi päättäjät ovat tyytyväisiä. Mitä seuraavaksi? Laitatko sen vain osaksi raportointia? Lasketko mittarin uudelleen kerran kuukaudessa ja näytätkö mittarin kehityksen raportilla?

Onko LTV vain yksi mittari, jonka analytiikkatiimi tarjoaa sidosryhmille ja odottaa heidän käyttävän sitä jollain tavalla ”liiketoiminnan tulosten ajamiseen”? LTV:n sisällyttäminen osaksi raportointia on hyvä idea, mutta ei usein suoraan johda toimintaan.

Tietoa elinkaaren arvosta voidaan käyttää useilla tavoilla. Esimerkiksi markkinoinnissa toimenpiteitä voidaan suunnitella segmenteittäin ja kokeilla millaiset toimenpiteet maksimoivat LTV:n lyhyen aikavälin tuoton sijaan. Todennäköisyys reagoida myönteisesti toimenpiteeseen kerrottuna LTV:llä on odotusarvo toimenpiteelle. Tästä saamme jokaisesta toimenpiteestä odotusarvon per asiakas, josta voimme valita kullekin asiakkaalle tai asiakassegmentille parhaan toimenpiteen. Tämän laskelman tekeminen koko asiakaskunnasta antaa tiedon asiakkaista, joille tulisi kohdistaa erityisiä toimenpiteitä elinkaaren arvon maksimoimiseksi markkinointibudjetin raameissa. Se auttaa myös tunnistamaan asiakkaat, jotka kannattaisi siirtää segmentistä toiseen.

Hinnoittelussa puolestaan voidaan LTV:n avulla arvioida, kuinka eri asiakassegmentit reagoivat erilaisiin hinnoittelustrategioihin. LTV voidaan myös ottaa huomioon dynaamisissa hinnoittelualgoritmeissa. 

Yrityksen tulee seurata KPI-arvoja, jotka vaikuttavat heidän hallitsemaansa elinkaariarvolaskelmaan. Esimerkiksi sopimussuhteen ulkopuolisessa yhteydessä tuotetiimiä voidaan mitata sen perusteella, kuinka hyvin he kasvattavat tapahtumien keskimääräistä määrää tai sopimuskontekstissa sitä, kuinka monta kuukautta tyypillinen asiakas pysyy asiakkaana.

Asiakastuen tiimiä voidaan mitata sillä, miten hyvin he tarjoavat asiakaspalvelua asiakkaiden vaihtuvuuden vähentämiseksi. Tuotekehitystiimiä voidaan mitata sillä, kuinka hyvin he kasvattavat transaktion arvoa. Markkinointitiimiä voidaan mitata ostotodennäköisyyden lisäämisellä.

Loppujen lopuksi sitä saa mitä mittaa.

 

Tarvittava data

LTV-mallit pyrkivät yleensä ennustamaan asiakkaiden käyttäytymistä havaittujen asiakkaiden ominaisuuksien funktiona. Siksi on tärkeää kerätä tietoja asiakasvuorovaikutuksista, toimenpiteistä ja asiakkaan käyttäytymisestä.

Ostokäyttäytymistä ohjaavat tekijät, kuten tuotteen tai palvelun arvostus verrattuna kilpaileviin tuotteisiin tai palveluihin. Nämä tekijät voivat olla (tai eivät ole) suoraan mitattavissa, mutta tietojen kerääminen kilpailijoiden hinnoista ja toimista voi olla ratkaisevan tärkeää analysoitaessa asiakkaiden käyttäytymistä. Tärkeää tietoa syntyy myös asiakkaan ja brändin välisestä vuorovaikutuksesta.

Tärkein tieto on käyttäytymisdata. Tämä voi olla ostotapahtumia, verkkosivustokäyntejä, selaushistoriaa ja sähköpostin avaamista. Nämä tiedot kuvaavat asiakkaan vuorovaikutuksia yksittäisten tuotteiden tai kampanjoiden kanssa.

Yllä kuvattuihin tietoihin tulee myös yhdistää yrityksen muita tietoja, kuten luettelotiedot, kausivaihtelut, hinnat, alennukset ja myymäläkohtaiset tiedot.

 

LTV:n käyttöönoton edellytykset

Tähän mennessä on käyty läpi miksi LTV on tärkeä, miten se voidaan laskea ja miten hyödyntää sitä. Tässä on muutamia kysymyksiä, joihin on vastattava ennen LTV:n käyttöönottoa:

  • Keitä asiakkaat ovat?
  • Mikä on paras arvon mitta?
  • Miten sisällyttää liiketoimintastrategia LTV-laskelmiin?
  • Onko kyseessä sopimuksellinen vai sopimukseton liiketoiminta?

Jos pystyt vastaamaan näihin kysymyksiin, olet valmis elinkaaren arvon mallinnuksen käyttöönottoon.

 

 

Blogin kirjoittajasta: Janne Flinck  on Codenton AI & Data Lead. Janne liittyi Codentoon Accenturelta vuonna 2022. Jannella on laaja kokemus Google Cloud -teknologioista. Hänen kiinnostuksen kohteena on dataintensiivisten sovellusten ja työkalujen luominen ja arkkitehtuuri. Jannella on kolme Google Cloud -sertifikaattia.

 

Ota meihin yhteyttä niin keskustellaan asiakkaan elinkaaren arvosta ja sen hyödyntämisestä lisää.

#NEXTGENCLOUD: Kilpailuetua digitaalisessa murroksessa

#NEXTGENCLOUD: Kilpailuetua digitaalisessa murroksessa

 

Kirjoittaja: Anthony Gyursanszky, CEO, Codento

Uuden aikakauden keskiössä

Muutama vuosikymmen sitten varhaisten yliopistovuosieni aikana tutustuin pascal-koodaukseen ja Michael Porterin kilpailustrategiaan. ”Valitse seuraavaksi tietoliikennekurssit – sillä alalla on tulevaisuus”, minulle kerrottiin. Niin tein, ja tietoliikennealan murros todellakin vauhditti ensimmäisiä työvuosiani.

Telemurros loi puolestaan pohjan entistä suuremmalle muutokselle, jota nyt pilvikyvykkyydet, datateknologiat, tekoäly ja modernit ohjelmistot vauhdittavat. Näemme organisaatioiden valitsevan Porterin alhaisimpien kustannusten, erillaistamis- tai fokusstrategioiden asemesta niiden kaikkien yhtäaikaisen hyödyntämisen.

Meillä Codentossa tehtävämme on auttaa eri organisaatioita menestymään digitaalisen murroksen läpi, ymmärtämään kyvykkyydet, visioimaan tulevaa liiketoiminta- ja teknologiaympäristöä, suunnittelemaan järkevimmät askeleet siirtymiseen kohti digitaalista edelläkävijyyttä ja tukemaan koko prosessia suosituksillamme. Tälläkin osa-alueella teemme tiivistä yhteistyötä johtavien pilviteknologian mahdollistajien kuten Google Cloudin kanssa.

Tässä artikkelissa avaan matkaa kohti digitaalista edelläkävijyyttä kokemuksiemme ja saatavilla olevien globaalien tutkimusten perusteella.

 

Mitä ymmärrämme digitaalisella transformaatiolla nykyään?

Blair Franklin, avustava kirjoittaja Google Cloud, julkaisi äskettäin blogitekstin Miksi ”digitaalisen transformaation” määritys muuttuu? Tätä varten Google haastatteli yli 2 100 globaalia teknologia- ja yritysjohtajaa kysymyksen ympärille: ”Mitä digitaalinen transformaatio merkitsee sinulle?

Viisi vuotta sitten vallitseva näkemys kyseiselle termille oli IT-infrastruktuurin siirto (“lift-and-shift”)  julkiseen pilveen. Suurin osa organisaatioista on nyt edennyt tässä lähinnä kustannussäästöjä etsiessään, mutta asiakassuuntaan on syntynyt hyvin vähän näkyvää liiketoiminta-arvoa.

Nykyään ”digitaalisen transformaation” määritelmä on laajentunut Google Cloud -kyselyn mukaan. 72 % käsittää sen paljon laajempana kuin aiemmin. Tutkimuksen mukaan esiin nousee erityisesti kaksi uutta merkitystä:

  1. Prosessien optimointi ja ketterämpi toimintakyvykkyys (47 %). Tämä tukee sekä kustannus- että differointistrategioita.
  2. Asiakaskokemuksen parantaminen teknologian avulla (40 %). Tämä tehostaa sekä fokus- että erottautumisstrategioita.

Yhteenvetona voidaan todeta, että olemme nyt siirtyneet  IT-infrastrukruurin pilveensiirron aikakaudesta digitaalisen edelläkävijyyden aikakauteen.

 

Mitä hyötyä on digitaalisesta edelläkävijyydestä?

Boston Consulting Group ja Google Cloud tutkivat Keys of Scaling Digital Value 2022 -tutkimuksessa mitä etuja on panostaa ”digitaaliseen edelläkävijyyteen”, joiden kaltaisiksi noin 30 prosenttia organisaatioista luokiteltiin.

Todella mielenkiintoista on se, että, digitaaliset edelläkävijät ovat yleensä tuloksekkaampia kuin vertailuyritykset: he luovat kaksi kertaa enemmän skaalautuvia ratkaisuja ja näitä hyödyntäen ne saavuttavat huomattavasti parempia taloudellisia tuloksia (kolme kertaa korkeampi sijoitetun pääoman tuotto, 15-20% nopeampi liikevaihdon kasvu ja vastaavat kustannussäästöt).

Tutkimus tuo esiin useita digitaalisen edelläkävijän tunnuspiirteitä, mutta suurin korrelaatio liittyy siihen, miten nämä hyödyntävät ohjelmistoja pilvessä: digitaaliset johtajat ottavat käyttöön pilvinatiiveita ​​ratkaisuja (64 % vs. 3 % muut) moderneilla modulaarisilla arkkitehtuureilla (94% vs. 21% muut).

Pilvinatiivi-termi tarkoittaa pilven tarjoamien kyvykkyyksien ja kapasiteetin hyödyntämistä kehittämällä ja ajamalla sovelluksia pilvessä. Pilvipohjaiset sovellukset puolestaan ​​on suunniteltu hyödyntämään pilven skaalautuvuutta, suorituskykyä ja joustavuutta.

Termin vastakohtana ovat ns. legacy-sovellukset, jotka on aikoinaan suunniteltu paikallisiin IT-ympäristöihin, ja jotka ovat lukittu tiettyihin teknologioihin, integraatioihin ja jopa erityisiin käyttöjärjestelmä- ja tietokantaversioihin.

 

Kuinka kehittyä digitaaliseksi edelläkävijäksi?

On selvää, että matka kohti digitaalista edelläkävijyyttä vaatii kirkasta visiota, päättäväisyyttä ja investointeja. On kaksi keskeistä syytä, joiden on havaittu merkittävästi estävän onnistumista:

Tämän lisäksi Boston Consulting Groupin ja Google Cloudin ”Keys of Scaling Digital Value 2022” -tutkimuksessa täsmennetään edelleen uudenlaista lähestymistapaa digitaaliseen edelläkävijyyteen. Tutkimus osoittaa, että digitaaliset edelläkävijät:

  • Organisoituvat tuotejohtoisten alustatiimien ympärille (83 % edelläkävijät vs. 25 % muut)
  • Synnyttävät toimintojen yhteistyötä tukevat rakenteet (88 % edelläkävijät vs. 23 % muut)
  • Käyttävät tätä varten optimoitua johtamisjärjestelmiä  (59 % edelläkävijät vs. 4 % muut)

Kuten olemme havainneet myös täällä Codentossa useimmat yritykset ovat aikoinaan kehittäneet roolinsa ja prosessinsa IT-aikakakauden alussa siilomaisesti automatisoidessaan manuaalisia toimintatapojaan. IT-organisaatiot sijoitettiin nykyisten toimintojen viereen jättäen liiketoiminnat ja tuotekehitystoiminnot erilleen.

Kun aikaa on kulunut, on kaikilla näillä kolmella avaintoiminnolla ollut omat enimmäkseen itsenäiset näkemyksensä datasta, sovelluksista ja pilven käyttöönotosta, vaikka pilvi nykypäivänä mahdollistaisi toimimisen yhtenä kokonaisuutena. Organisaatioiden onkin mietittävä uudelleen tapansa organisoitua ns. diginatiivilla tavalla.

Ilman aiempia investointeja muutos olisi luonnollisesti paljon helpompi toteuttaa, kuten ns. “diginatiivit” organisaatiot, esimerkiksi Spotify, ovat osoittaneet. Diginatiivit suunnittelevat toimintansa ”vapaana siiloista” pilvipohjaisen sovelluskehityksen ympärille hyödyntäen alusta saakka kehittyneitä pilviominaisuuksia, kuten yhtenäistä tiedon tallennusta, käsittelyä ja tekoälyä.

Diginatiivit organisaatiot ovat nopeampia, ketterämpiä ja joustavampia. Esimerkkinä toimintatavoista ovat DevOps- ja Site Reliability Engineering -mallit, jotka laajentavat roolien vastuita ja lisäävät yhteistyötä varsin tuloksekkaasti. DORA:n vuoden 2021 Accelerate: State of DevOps -raportti paljastaa, että huippusuorittajat tällä alueella raportoivat 1,8 kertaa todennäköisemmin paremmista liiketoimintatuloksista.

 

Kuulostaa hyvälle, miten pääsen alkuun?

Yhteenvetona voidaan todeta, että digitaaliset edelläkävijät menestyvät paremmin kuin verrokkinsa ja onkin vaikea löytää hyviä perusteluita ottaa oppeja näistä.

Digitaaliset edelläkävijät eivät koe digitaalisen transformaation olevan ainoastaan infrastruktuurin pilveistysharjoitus, vaan he hakevat kilpailukykyä optimoimalla prosessejaan ja parantamalla asiakkaidensa kokemaa lisäarvoa. Digitaaliseksi edelläkävijäksi kehittyminen edellyttää selkeää visiota, ylimmän johdon tukea ja uusia toimintamalleja, jotka mahdollistavat integroidun dataa ja tekoälyä hyödyntäviä pilvinatiiveja sovelluksia.

Me Codentossa olemme erikoistuneet konsultoimaan asiakkaitamme kehittymään menestyksekkäästi digitaalisiksi edelläkävijäksi kolmivaiheisella lähestymistavalla, joka kiteyttää vastaukset seuraaviin kysymyksiin:

  • Miksi? Arvioidaan millä tasolla organisaation kyvykkyydet ovat tällä hetkellä ja mitä tarvitaan menestykseen tulevassa liiketoimintaympäristössä.
  • Mitä? Valitaan strategiset elementit ja tavoitteet eri vaihtoehdoista.
  • Miten? Rakennetaan ja toteutetaan muutosmatka aiempien vaiheiden näkemyksen perusteella.

Autamme asiakkaitamme koko suunnittelu- ja toteutusprosessin lisäksi myös erityisillä täsmäprojekteilla tilanteen mukaan. Käytännönläheisiä esimerkkejä löydät näistä meidän case-arkistostamme:

Voit myös tilata  uutiskirjeemme, osallistua tuleviin online-tapahtumiimme ja katsoa tapahtumatallenteitamme.

Blogin kirjoittajasta: Anthony Gyursanszky, toimitusjohtaja, liittyi Codentoon vuoden 2019 lopulla yli 30 vuoden kokemuksella IT- ja ohjelmistoalalta. Anthony on aiemmin toiminut johtotehtävissä F-Securessa, SSH:ssa, Knowit / Enderossa, Microsoft Finlandissa, Tellabsissa, Innofactorissa ja Elisassa. Gyursanszky on toiminut myös ohjelmistoyritysten hallituksissa, mukaan lukien Arc Technology ja Creanord. Anthony toimii myös arvokartoituspalveluiden johdon konsulttina. Anthonyn kokemus kattaa liikkeenjohdon, tuotehallinnan, tuotekehityksen, ohjelmistoliiketoiminnan, SaaS-liiketoiminnan, prosessihallinnan ja ohjelmistokehityksen ulkoistamisen. Ja Anthony on nyt myös sertifioitu Cloud Digital Leader.

 

Tutustu arvokartoituspalveluihimme:

#NEXTGENCLOUD: Codenton yhteisöblogi: Digitalisaation kuusi sudenkuoppaa – ja miten ne välttää

Codenton yhteisöblogi: Digitalisaation kuusi sudenkuoppaa – ja miten ne välttää

By Codenton konsultit

 

Johdanto

Me codentolaiset olemme ahkeroineet viimeiset kuukaudet erilaisissa digitalisaatiohankkeissa konsultteina ja kohdanneet kymmeniä erilaisia asiakastilanteita. Samalla olemme pysähtyneet huomaamaan, kuinka paljon näillä työmailla kohdataan samoja sudenkuoppia, jotka olisivat voitu välttää etukäteen.

Codenton kaltaisen konsulttiyrityksen elämäntehtävä lienee kaksijakoinen näkemyksen tuottaminen asiakkaidemme suuntaan: yleisesti havaittujen onnistumisten toistaminen ja vastaavasti sudenkuoppien välttäminen.

Vältettävissä oleviin toistuviin sudenkuoppiin ajautuminen aiheuttaa aina todella paljon pettymyksiä ja turhautumista ja pysähdyimmekin näin kesää vasten koko Codenton konsulttiporukan kanssa yhdessä pohtimaan ja kokoamaan omia ajatuksiamme erityisesti näiden sudenkuoppien välttämiseksi.

Syntyi elävä ja monitahoinen yhteisöllinen ajatustenvaihto,  joka meidän oman kokemuksen ja näkemyksen pohjalta tiivistyi kuuteen juurisyyhyn ja kokonaisuuteen:

  1. Lähdetään ratkaisemaan alunperin väärää ongelmaa
  2. Jäädään olemassaolevien sovellusten ja infrastruktuurin vangiksi
  3. Jäädään nykyisten toimintamallien vangiksi
  4. Ei hyödynnetä optimaalisesti uusien pilviteknologioiden mahdollisuuksia
  5. Dataa ei hyödynnetä liiketoiminnassa riittävästi
  6. Koneoppimisen ja tekoälyn hyödyntämisellä ei kehitetä kilpailuetua

Käydään seuraavaksi yhdessä Codenton konsulttien kanssa tätä mielenkiintoista vuoropuhelua läpi.

 

Suodenkuoppa 1: Lähdetään ratkaisemaan alunperin väärää ongelmaa

Kuinkakohan monta Design Sprinttiä ja MVP:ta on maailmassa toteutettu uusien ratkaisuiden luomisessa niin, että alkuperäinen ongelmanasettelu ja asiakastarve on perustunut vääriin oletuksiin tai muuten ollut puutteellinen?

Tai että moni liiketoiminnalille arvokkaampi ongelma on jäänyt ratkaisematta, kun ne ovat jääneet jonossa varasijille? Teknologiavalinta esimerkiksi valmistustuotteen tai räätälöidyn ohjelmiston välillä on puolestaan usein se helpoin vaihe.

Vikaa ei sinänsä ole Design Sprint- tai Minimum Viable Product -metologiassa: nehän soveltuvat erittäin hyvin epävarmuuteen ja kokeilevaan lähestymiseen ja turhan tuotantokelpoisen työn välttämiseen, mutta parannettavaa on varmasti siinä mihin ongelmiin niitä sovelletaan.

Veera muistelee erästäkin tilannetta: “Aletaan ratkoa ongelmaa MVP-henkisesti miettimättä kovin pitkälle, miten sovelluksen pitäisi toimia erilaisissa käyttötapauksissa. Sovelluksesta voi tulla kokoelma erilaisia erikoistapauksia ja yhdistävä tekijä niiden välillä jää puuttumaan. Myöhemmin voidaan joutua tekemään isoja remontteja, kun alkuperäinen arkkitehtuuri tai tietomalli ei kanna riittävän pitkälle.”

Markku luettelee sujuvasti tyypillisä ongelmia, jotka liittyvät konseptointi- ja MVP-vaiheeseen: “Tietty jäykkyys nopeassa ja jatkuvassa kokeilussa, taipumus täydellisyyteen, loppuasiakkaan väärin ymmärtäminen, väärä teknologia tai toimintamalli.”

“Oma ratkaisutapani on aina pienentää ongelman määritys niin pieneksi osaongelmaksi, että sen ratkaiseminen on nopeampaa ja oppiminen tehokkaampaa. Samalla positiivinen tunnelma kasvaa, kun saadaan aina aikaan jotain näkyvää.”, Anthony täydentää.

Toni näkee kolme olennaista vaihetta ratkaisuksi: “Tarvitaan paljon erilaisia ongelmakandidaatteja. Valitaan niistä yhteisillä kriteereillä yksi kirkastettavaksi. Työstetään ongelmanmääritystä sekä laaja-alaisesti että syvälle. Vasta tämän jälkeen kannattaa lähteä Design Sprintttiin.”

 

Suodenkuoppa 2: Jäädään olemassaolevien sovellusten ja infrastruktuurin vangiksi

Helppoahan se on “greenfield”-hankkeissa, joissa “pöytä on puhdas”, mutta mitä tehdä silloin, kun kunnianhimoisen digivision esteenä on vuosikausien pölyttynyt sovellus- ja IT-ympäristö?

Olli-Pekka aloittaa: “Softahan ei ole valmis ennen kuin se poistetaan tuotannosta. Siihen asti siihen uppoaa enemmän tai vähemmän rahaa, joka olisi kiva saada takaisin joko säästettynä työaikana, tai sitten ihan suoraan tuloina. Jos tuotannossa olevia järjestelmiä ei pidetä kehityksen kyydissä, niin niihin uppoavat kulut ohittavat taatusti niistä saatavat hyödyt ennemmin tai myöhemmin. Tästä pitää huolen inflaatio ja teknologian eksponentiaalinen kehitys.”

“Yrityksen liiketoimintaa tukeva todella vanha järjestelmä, jonka korvaus on käytännössä mahdotonta.”, jatkaa Jari T. “Siitä tuleva pieni liikevaihto ja teknologian vanhuus tarkoittaa, että järjestelmää ei kannata korvata. Järjestelmä ajetaan alas kuin viimeiset liiketoiminnan osat on lakkautettu järjestelmästä.”

“Mieleen tulee monoliittinen järjestelmä, jota ei pysty uudistamaan osa kerrallaan. Koko järjestelmän uusiminen taas olisi liian iso kustannus.”, täydentää Veera.

Olli- Pekka hahmottaa kolme erilaista tilannetta: “Käyttäjäkunnasta riippuen paineet modernisoinnille ovat erilaisia, mutta tarve sille ei poistu missään vaiheessa. Otetaanpa muutama esimerkki.

Kuluttajatuotteet – tämän luulisi olevan itsestäänselvää. Antiikkituotteille ei tällä alalla ole markkinoita, ellei liiketoimintasi perustu NFT:iden myyntiin Doomin alkuperäisestä lähdekoodista, eikä silloinkaan. Vai milloin olet viimeksi ihastellut Win-XP:n romppuja kaupan hyllyssä?

Yritystuotteet – vähän monimutkaisempi tapaus. Tässä hommaa hoputtaa se, että jotta käytettävä järjestelmä olisi liiketoiminnan kannalta oleellinen, sen on syytä pelata kiltisti yhteen muiden organisaation käytössä olevien järjestelmien kanssa. Muussa tapauksessa sille kyllä arvotaan korvaaja, koska manuaaliset stepit prosessissa ovat sekä kalliita, että virhealttiita. Ongelmaa ei tosin ole, mikäli kukaan ei päivitä tuotteitaan. En tuudittautuisi tämän varaan.

Sisäinen käyttö – näitähän ei tarvitse modernisoida? Tässä riittää vain, että koulutat itse uudet osaajat poistuvien tilalle, koska kukaan muu ei sitä sinun stackillesi enää tee. Muista myös toivoa, että kaikki ne, jotka onnistut tähän teknologiseen umpikujaan houkuttelemaan, eivät keksi ryhtyä kurkkimaan aidan yli. Ja muista myös varata hieman ylimääräistä valuuttaa ylläpitosopimuksiin, koska ulkopuoliset toimittajat saattavat nostaa hintojaan kun käyttäjämäärät heidän auringonlaskun tuotteilleen tippuvat.”

Iirolle tuli heti mieleen muutamia käsitteitä: “Polkuriippuvuus ja Sunk cost fallacy. Näistähän voisi molemmista kirjoittaa oman blogin?”

“Mitä syitä tai hankaluuksia tulee vastaan eri tutkimuksista?” kysyvät Sami ja Marika.

“Itselleni on mieleen ainakin jäänyt budjettihaasteet, ympäristöjen monimutkaisuus, integraatiokyvykkyyden puute, tietoturva ja lainsäädäntö. Mikä sitten avuksi?”, vastaa ja kysyy Anthony samalla kertaa.

Olli-Pekan kolme ideaa syntyvät nopeasti: “Kartoita järjestelmäsi – tähän kannattaa käyttää myös ulkopuolisia silmäpareja, koska ne osaavat tunnistaa sellaisetkin yksityiskohdat, joihin oma silmä on jo tottunut. Ulkopuolinen asiantuntija osaa myös kysyä oikeita kysymyksiä, sekä onkia näihin vastaukset. Suunnittele reittisi ulos loukusta – harvemmin kannattaa rynnistää sokkona joka suuntaan samaan aikaan. Riittää, että puhkaiset aukon siihen, missä aita on heikoin. Tästä voit sitten lähteä laajentamaan ja rakentamaan uusille laitumille itsellesi sopivaan tahtiin. Investoi osaamiseen – reikä aitaan syntyy helpoiten oikeilla työkaluilla. Ja taitava tekijä puhkaisee aukon niin, että siitä on helppo kulkea jatkossakin repimättä vaatteitaan. Ei kannata tuudittautua siihen, että tämä tekijä löytyisi talosta sisältä, koska jos näin olisi, niin se aukko olisi jo siinä. Tai sitten prosessi mättää. Joka tapauksessa apua tarvitaan.”

 

Suodenkuppa 3: Jäädään nykyisten toimintamallien vangiksi

“Kumpikohan on lopulta isommin esteenä: infrastuktuuri ja sovellukset vai omat toimintamallit ja muutoskyvykkyyden puute?”, pohtii Tommi. 

“Itse kallistuisin toimintamallien suuntaan.”, näkee Samuel. “Siiloutuminen erityisesti liiketoiminnan ja IT:n välillä, riskien ylempalttinen välttäminen, muutoskyvykkyyden puute, ohjaavan digivision epämääräisyys, ja näkemyksen puute tulevat vahvasti itselleni mieleen.” 

Veera täydentää: “Lähdetään mallintamaan vanhoja prosesseja sellaisenaan uuteen sovellukseen, sen sijaan että mietittäisiin, miten prosesseja voisi samalla muuttaa ja saada hyötyä myös paremmista prosesseista.”

Elmo luettelee heti muutamia käytännön esimerkkejä: “Word+Sharepoint-dokumentaatio rajoittaa, koska “näin on toimittu aina”. Muutosvastarinta aiheuttaa sen, että ei voida hyödyntää moderneja toimintatapoja ja uusimpia välineitä ja suljetaan tätä kautta osa kontribuutiosta pois tekemisestä. Tämä rajaa käyttäjäkuntaa, koska ei voida käyttää organisaation rajat ylittävää osaamista.”

Anne jatkaa: “Excel+word-dokumentaatiomallit johtavat siihen, että tieto on levällään ja ylläpito vaikeaa. Sähköpostitse tiedon kulku. Suurin este kulttuuri ja tekemisen tapa, ei tekniikka itsessään.”

“Mitä pitäisi tehdä ja mistä saada motivaatio?”, pohtii puolestaan Perttu ja jatkaa ratkaisuehdotuksella: “Pieniä voittoja nopeasti – matalalla roikkuvat hedelmät olisi poimittava. Mitä pidempään jatkaa tehotonta toimintaa, sitä kalliimpaa sieltä pois pääseminen. Sunk Cost Fallacy tulee ajatusvinoumana myös mieleen.”

“Parannettavia toimintamalleja on rajattomasti.”, Markku avaa vaihtoehtojen kirjoa: ”Liiketoimintayhteistyö, tuotehallinta, sovelluskehitys, DevOps, testaus, integraatio, tuotantoonsiirto, jatkokehitys, johtaminen, resursointi, alihankinta, työkalut, prosessit, dokumentaatio, mittarit. Kaikessa ei tarvitse olla maailmanluokkaa, mutta on hyvä parantaa osa-aluetta tai osa-alueita, joilla saadaan isoin vaikuttavuus optimaalisella panostuksella.”

 

Sudenkuoppa 4: Ei hyödynnetä uusien pilviteknologioiden mahdollisuuksia

Google Cloud, Azure, AWS vai monipilvi? Onko tämä keskeisin kysymys?

Markku vastaa: “Mielestäni ei. Talousohjauksen mittarit siirtävät pilvikulut pois poistojen puolelta suoraan ylemmäksi tuloslaskelman rivejä ja tähän ei monen yrityksen tavoiteasetanta taivu, vaikka todellisuudessa kassavirtaan saatisi pidemmällä aikavälillä paljon positiivista vaikutusta.”

Sannalle tulee mieleen muutamia vastaantulleita tilanteita: “Valitaan teknologia, jonka uskotaan sopivan parhaiten omaan tarpeeseen. Tämä siksi, ettei ole tarpeeksi kattavaa tietoa ja kokemusta olemassa olevista teknologioista ja niiden mahdollisuuksista. Siksi saatetaan päätyä tilanteeseen, jossa valitun teknologian päälle on jo rakennettu paljon logiikkaa ja ominaisuuksia kun huomataan, että jokin toinen malli olisi sopinut käyttötapaukseen paremmin.  Kokemus tosielämästä: “näillä funktioillahan tämän saa toteutettua näppärästi”,  kaksi vuotta myöhemmin: “miksi ihmeessä ei valittu IoT-hubia”.” 

Perttu korostaa: ”Lähempänä jokapäiväistä bisnestä muuallakin kuin pilviteknologian kylmässä ja teknisessä ytimessä löytyy esimerkkinä digitaalisten alustojen käyttö työskentelyssä (esim. drive, meet, teams jne). Varsinkin, kun viimeaikoina julkinen keskustelu on pyörinyt muutaman ison firman ohjeistusten, joissa käskytetään työntekijät takaisin lähityöhön, ympärillä.”

Perttu jatkaa: “Tähän verraten digitaalisten alustojen tarjoamat palvelut tekevät toiminnasta ketterämpää ja mahdollistavat suuremman kirjon elämäntyylejä sekä kaiken lisäksi tehostavat liiketoimintaa. Muistettava tietysti, että fyysiset kohtaamiset ovat myös tärkeitä ihmisille, mutta voitaneen olettaa, että minkä tahansa alan asiantuntijat ovat parhaita määrittelemään itse tehokkaat työskentelyn tavat. Win-win, eikö?”

Mikä sitten ratkaisuksi?

“Minusta tärkeintä on, että pilvikyvykkyyksien käyttöönotettavat ominaisuudet sovitetaan valittuihin lyhyen ja pitkän aikavälin käyttötapauksiin”, summaa Markku.

 

Sudenkuoppa 5: Dataa ei hyödynnetä liiketoiminnassa riittävästi

Ei taida olla juuri yrityksiä, jotka voivat välttää, että heillä on pääosa datastaan hyvin hallussa ja eheää? Mutta millaisia erilaisia haasteita tähän liittyy?

Aleksi pohjustaa: “Datan laajemman hyödyntämisen käytännön esteenä on  organisaatiossa melko usein huono näkyvyys saatavilla oleviin datoihin. Saattaa löytyä monia piilossa lymyäviä datajoukkoja, joiden olemassaoloa ei tunne kuin pari ihmistä. Nämä saattavat olla löydettävissä ainoastaan sattumalta keskustelemalla oikeiden ihmisten kanssa.

Toinen samankaltainen ongelma on, että joidenkin datajoukkojen osalta datan sisältöä, rakennetta, alkuperää tai syntymistapaa ei enää nykytilanteessa oikeasti tunne kukaan – ja  mitään dokumentaatiota asiasta ei juurikaan ole.”

Aleksi jatkaa, “Liian ehdoton ja varhaisessa vaiheessa sovellettava business case -lähestyminen estää datan hyödyntämisen kokeilun ja kehittämisen tapauksissa, joissa mukana on ”tutkimuksellinen aspekti”. Näin on esimerkiksi monissa uusissa koneoppimisen tapauksissa: etukäteen ei ole selvillä mitä on odotettavissa, tai edes saadaanko aikaiseksi mitään hyödynnettäväksi kelpaavaa. Näin ollen tällaista varhaista tekemistä on vaikea perustella tavanomaisen business casen avulla.

Parempi voisi olla arvioida mahdollisia hyötyjä, joita lähestymisellä voisi onnistuessaan olla. Jos nämä hyödyt ovat riittävän suuret, voi lähteä kokeilemaan, tarkastella tilannetta jatkuvasti kriittisesti ja torpata huonoksi osoittautuvat ideat nopeasti. Business casen aika voi olla myöhemmin.”

 

Sudenkuoppa 6: Koneoppimisen ja tekoälyn hyödyntämisellä ei kehitetä kilpailuetua

Taitaa olla nykyaikana muotia, että liikkeenjohtaja osallistuu erilaisille koneoppimisen kursseille ja organisaatioissa on käynnissä vaihteleva määrä kokeiluja. Vielä ei kuitenkaan olla kovin pitkällä, vai ollaanko?

Aleksi avaa kokemuksiaan: “Nykyinen ”perinteisellä tavalla” toteutettu toimintamalli on ajan saatossa viilattu jo melko hyväksi, ja parannuspotentiaalia on jäljellä hyvin rajallisesti. Ensimmäiset koneoppimisen kokeilut eivät tuota nykyistä parempaa lopputulosta, joten niiden tarkastelu ja kehittäminen päätetään lopettaa. Monesti tilanne näissä saattaa olla kuitenkin se, että nykyisen toimintamallin mahdollistama potentiaali on ajan saatossa ulosmitattu lähes täysin, kun taas koneoppimisen puolella parannuspotentiaali yltäisi huomattavasti korkeammalle tasolle. Jäädään ikään kuin lukkoon nykyiseen tapaan vain, koska ensimmäiset yritykset eivät heti tuoneet parannusta.”

Anthony tiivistää haasteet kolmeen kokonaisuuteen: “Liiketoiminta-arvo on epäselvä, data ei ole saatavilla eikä osaamista koneoppimisen hyödyntämiseen ole riittävästi.”

Jari R. haluaa mainostaa omaa aiempaa puheenvuoroaan kevään liiketoimintalähtöisen koneoppimisen online- tapahtumassa. “Jos nyt muistan oikein niin kokosin juuri tähän aiheeseen sovelutuvaa listan peräti kymmenestä sudenkuopasta. Tässä tapahtumamateriaalissa ne ovatkin sujuvasti luettavissa:

  1. Konkreettista liiketoimintaan liittyvää ongelmaa ei määritellä kunnolla. 
  2. Mallin luotettavuudelle ei määritellä tavoitetta tai tavoite on epärealistinen.
  3. Datalähteiden valinta jätetään data scientistien ja engineerien tehtäväksi eikä liiketoiminta-alueen asiantuntijoiden osaamista hyödynnetä.
  4. ML-projekti toteutetaan yksinomaan IT-osaston omin voimin. Liiketoiminta-alueen asiantuntijoita ei osallisteta projektissa.
  5. Mallin rakentamiseen ja hyödyntämiseen tarvittavat datat pidetään sirpaleisena eri järjestelmissä eikä pilvialustojen dataratkaisuja hyödynnetä.
  6. Mallin uudelleenkoulutettavuutta pilvialustalla ei oteta huomioon jo kehitysvaiheessa.
  7. Malliin valitaan mahdollisimman muodikkaat algoritmit. Algoritmien tarkoituksenmukaisuutta ei pohdita.
  8. Mallin tekemien virheiden juurisyitä ei analysoida vaan luotetaan sokeasti tilastollisiin tarkkuusparametreihin.
  9. Mallin rakennetaan toimimaan data scientistin omalla koneella eikä sen siirrettävyyttä pilvialustalle mietitä kehitysvaiheessa.
  10. Mallin kykyä analysoida oikeaa liiketoimintadataa ei seurata systemaattisesti eikä mallia uudelleenkouluteta.”

Tämä toimineeksin hyvänä esimerkkinä data scientistin perinpohjaisuudesta. Tuohon listaan on helppo yhtyä ja uskoa, että meiltä codentolaisilta löytyy näkemystä sudenkuoppien välttämiseen tälläkin alueella.

 

Yhteenveto – Vältä sudenkuopat ajoissa

Sudenkuoppiin putoamisen ennaltaehkäisyksi Codenton konsultit ovat luvanneet tarjota kahden tunnin veloituksettomat työpajat halukkaille organisaatioille aina yhteen näistä sudenkuopista kerrallaan keskittyen:

  • Digiarvotyöpaja: Täsmennetty ja ymmärrettävä liiketoimintaongelma ratkaistavaksi konseptointivaiheeseen
  • Sovellusuudistustyöpaja: Priorisoitu etenemiskartta sovellusten modernisoinnissa
  • Toimintamallityöpaja: Potentiaalisten toimintamallihaasteiden tunnistaminen arviointivaihetta varten
  • Pilviarkkitehtuurityöpaja: Auttaa tunnistamaan konkreettiset askeleet kohti laadukasta pilviarkkitehtuuria ja sen jatkokehittämistä
  • Data-arkkitehtuurityöpaja: Alustava data-arkkitehtuurin nykytilanne ja potentiaaliset kehityskohteet jatkosuunnittelua varten
  • Tekoälyarvotyöpaja: Priorisoidut käyttötapauskuvaukset liiketoiminnan toteutettavuuden näkökulmasta tarkempaan suunnitteluun

 

Kysy meiltä lisää ja varataan aika jo elokuulle, niin syksy lähtee mukavasti käyntiin sudenkuoppia vältellen.

#NEXTGENCLOUD: Yhden vai usean pilven taktiikalla – liiketoimintalähtöinen asiantuntijablogi

#NEXTGENCLOUD: Yhden vai usean pilven taktiikalla – liiketoimintalähtöinen asiantuntijablogi

Author: Markku Tuomala, CTO, Codento

 

Tausta pilvitaktiikan valitsemiselle

Perinteisesti organisaatioissa on arkkitehtuuria valittaessa päädytty keskittämään kaikki voimat yhden julkisen pilven ratkaisuihin. Taustalla on ollut usein ajatus kapasiteettipalveluiden tehokkuuden optimoimisesta. Käytännössä tämä tarkoittaa olemassa olevien sovellusten siirtämistä maksimaalisesti pilveen –  ilman sovellusarkkitehtuurin muutoksia.

Tavoitteena on keskittää volyymi yhdelle pilvipalveluiden toimittajalle ja sitä kautta saavuttaa mahdollisimman suuri hyöty infrapalveluiden operoinnista ja palvelukustannuksista.

 

Merkittävimmät käyttötapaukset

Marraskuun 2021  #NEXTGENCLOUD -online tapahtumassamme keskityimme seuraavan sukupolven pilven kyvykkyyksiin ja millaisia liiketoimintahyötyjä voi saavuttaa jo lyhyessäkin ajassa. #NEXTGENCLOUD-ajattelussa katse käännetään asiakkaan tarpeen ratkaisemiseen sopivimmilla työkaluilla.

Tästä näkökulmasta jakaisin merkittävimmät käyttötapaukset seuraavasti katergoriaa:

  1. Uusien palveluiden kehittäminen
  2. Sovellusmodernisoinnit

Tarkastelen näitä seuraavaksi tarkemmin.

 

Uusien palveluiden kehittäminen

Uusien palveluiden kehittämisessä lähdetään liikkeelle kokeilemalla, palvelun tulevia käyttäjiä aktivoimalla ja iteratiivisella oppimisella. Jo nämä teemat sinällään aiheuttavat arkkitehtuurin suunnitttelulle mielenkiintoisen haasteen, jossa suunta ja päämäärä saattavat muuttua hyvinkin nopeasti oppimisen myötä.

On tärkeää, että arkkitehtuuri tukee laajamittaisesti valmiiden kyvykkyyksien käyttöönottamista, kasvattaa palvelun autonomiaa ja varmistaa käyttäjille entistä paremman käyttökokemuksen. Usein näissä ratkaisuissa päädytään käyttämään useamman julkipilven valmiita kyvykkyyksiä, jotta tuloksiin päästäisiin nopeammin. 

 

Sovellusmodernisoinnit

Pilvet on rakennettu toisistaan poikkeavilla tavoilla. Erot eivät rajaudu vain teknisiin yksityiskohtiin, vaan käsittävät myös hinnoittelumallit sekä muita käytäntöjä. IT-ympäristössä toimivien sovellusten erilaiset tarpeet tekevät lähes mahdottomaksi ennustaa mikä pilvi sopii liiketoimintatarpeille sekä sovelluksille optimaalisesti. Tästä seuraa se että oikea tarve määräytyy yksittäisen liiketoimintatarpeen tai sovelluksen perusteella, joka yhden pilven toimintaympäristössä tarkoittaa tarpeettomia kompromisseja sekä teknisesti epäoptimaalisia valintoja. Nämä konkretisoituvat kustannustehottomuutena sekä kehityksen hitautena. 

IT-ympäristöjen sovellusmodernisoinnissa kannattaa jo suunnitteluvaiheesta alkaen maksimoida eri pilvipalveluiden hyödyt kompromissien välttämiseksi, sujuvan käyttökokemuksen varmistamiseksi, autonomian kasvattamiseksi, tuotannollisen riskin hajauttamiseksi sekä tulevaisuuden liiketoiminnan tarpeiden tukemiseksi. 

 

Pullonkaulana osaaminen?

Löytyykö kaikkeen tähän osaamista, onko useamman pilven teknologian osaaminen suurin este?

Sovellusarkkitehdeille ja ohjelmistokehittäjille on normaalia opetella useampia ohjelmointikieliä siinä missä lääkäreiden tai sairaanhoitajien uusia hoitomenetelmiä. monipilviteknologioiden osaamisen kehittymisessä pätevät samat lainalaisuudet. Tänä päivänä jo yhä useampi meistä on työskennellyt useamman pilviteknologian kanssa ja hyödyntänyt valmiita palveluita. Samalla teknologia useampien pilvien hallintaan on kehittynyt merkittävästi, joka helpottaa niin kehitystoimintaa kuin pilvien operointiakin.

 

Artikkelin kirjoittaja, Markku Tuomala, CTO, Codento. Markulla on 25 vuoden kokemus ohjelmistokehityksestä ja pilvestä, työskenneltyään Suomen johtavalla teleoperaattorilta Elisalla. Markku vastasi Telco- ja IT-palveluiden pilvistrategiasta ja kuului Elisan tuotannon johtoryhmään. Keskeisiä tehtäviä olivat Elisan ohjelmistostrategia ja liiketoimintakriittisten IT-ulkoistusten operatiivisten palveluiden johtaminen. Markku ajoi asiakaslähtöistä kehitystä ja oli avainasemassa liiketoiminnan kasvussa, palveluiden kuten Elisa Viihde, Kirja, Lompakko, itsepalvelu ja verkkoautomaatio parissa. Markku johti myös Elisan konesalitoimintojen muutosta DevOpsiin. Markku toimii Codenton Value Discovery -palveluiden senior-tason konsulttina.

 

Kysy meiltä lisää:

#NEXTGENCLOUD, Osa 2. Tulevaisuuden pilvi – oikeilla valinnoilla pitkäjänteistä kilpailukykyä

#NEXTGENCLOUD, Osa 2. Tulevaisuuden pilvi – oikeilla valinnoilla pitkäjänteistä kilpailukykyä

Author: Jari Timonen, Codento Oy

# NEXTGENCLOUD – tulevaisuuden pilvi – on viitekehys, jonka varaan me Codentolla uskomme asiakkaidemme pitkäjänteisen menestyksen rakentuvan.

Valtavirtatoimittajien pilvikyvykkyyksien kehittyessä kiihtyvällä vauhdilla on äärimmäisen tärkeää ottaa näiden uusien ominaisuuksien tuomat mahdollisuudet huomioon oikeita valintoja tehtäessä ja suunnitelmia kirkastettaessa.

Me Codentolla koemme tämän osa-alueen näkemyksen kehittämisen olevan keskeinen roolimme. Yhteistyössä teknologiatoimittajien ja asiakkaiden kanssa tuemme asiakkaiden liiketoimintaa sekä mahdollistamme sovellusinnovaatiot ja -modernisoinnin.

Kaksiosaisessa blogisarjassamme ja tulevassa #NEXTGENCLOUD-tapahtumassa avaamme keskeisiä näkemyksiämme.

  • Osa 1: Tulevaisuuden pilvi: liiketoimintanäkökulmia (julkaistu 17.11.)
  • Osa 2: Tulevaisuuden pilvi: Oikeilla valinnoilla pitkäjänteiseen kilpailukykyyn

Tässä blogissa pohdimme miten tulevaisuuden pilven arkkitehtuuri mahdollistaa pitkäjänteisen kilpailukyvyn.

Tavoitearkkitehtuuri on kaiken uuden tukirakenne

Taloissa on kantavat seinät ja erikseen kevyemmät rakenteet perustelluista syistä. Millaisia rakenteita tarvitaan pilviarkkitehtuureissa?

Toimivien rakenteiden valintoja ohjaavat seuraavat tekijät.

  • Toiminnallisen kerrosten tunnistaminen
  • Käyttötarkoitukseen soveltuvien palveluiden valinta
  • Löyhä integrointi kerrosten välillä
  • Kattava tietoturva

Kunkin julkisen pilven toimittajan kyvykkyyksien mukaan voidaan määritellä omanlaisensa tavoitearkkitehtuuri. Monipilviratkaisuissa vastaavasti usean eri pilven kyvykkyyksien mukainen monipilviarkkitehtuuri.

Google Cloud -teknologioita hyödyntävässä tulevaisuuden arkkitehtuurissa tulisi huomioida seuraavat neljä osaa:

  • Tiedon tuonti ja prosessointi (Ingestion and processing)
  • Tiedon tallennus (Data Storage)
  • Sovellukset (Applications)
  • Analytiikka ja raportointi (Analytics, Reporting and Discovery)

Jokaisessa osassa on käytettävissä useita eri vaihtoehtoisia ja toisiaan täydentäviä pilvipalveluita, jotka ratkaisevat erilaisia liiketoiminta- ja teknisiä haasteita. Huomionarvoista arkkitehtuurissa on, että mikään palvelu ei ole toisiin palveluihin nähden keskeisessä tai alisteisessa roolissa.

Tulevaisuuden pilven ratkaisut ja palvelut ovat osa kokonaisarkkitehtuuria. Mahdollisesti poistuvat tai korvattavat palvelut eivät aiheuta laajamittaista muutostaakkaa kokonaisarkkitehtuuriin.

Uuden sukupolven pilvi mahdollistaa laskennan pilven reunalla (edge computing)

Suunniteltaessa tavoitearkkitehtuuria pitää ottaa huomioon pilven tarjoamat kyvykkyydet hajauttaa laskentaa ja tiedon tallennusta lähemmäksi tiedon kuluttajaa tai käyttäjää.

Internetin alkuaikoina sovelluskoodia ajettiin pelkästään palvelimilla. Tämä sai aikaan skaalautuvuushaasteita käyttäjämäärien kasvaessa. Myöhemmin sovellusarkkitehtuureja uudistettaessa sovelluksen osia jaettiin eri tietokoneille, eritoten käyttöliittymien osalta. Tämä helpotti palvelimien skaalautuvuutta sekä vähensi suunnittelemattomien käyttökatkosten riskiä. Suurin osa käyttäjälle näkyvästä sovelluskoodista suoritetaan puhelimilla, tableteilla tai tietokoneilla, kun taas liiketoimintalogiikka suoritetaan pilvessä.

Samankaltainen murros on tapahtumassa nyt pilven laskentakapasiteetissa.

Tulevaisuudessa kaikkia työkuormia ei ajeta pelkästään pilvipalveluiden suurissa palvelukeskuksissa, vaan niitä ajetaan myös lähempänä asiakasta. Esimerkkejä tällaisista ratkaisuista ovat mm. analytiikka-, koneoppimis- ja muuta laskentatehoa vaativat sovellukset, kuten esineiden Internet (Internet of Things).

Osa sovelluksista vaatii niin alhaista latenssia, että se edellyttää laskentatehoa lähellä asiakasta. Konesalin läheinen maantieteellinen sijainti ei välttämättä riitä vaan tarvitaan paikallista laskentakapasiteettia reunalaskentaan.

Pilven älykkäät ominaisuudet mahdollistavat uusia sovelluksia

Pilvi on kehittynyt alun kustannuksia ja kapasiteettia optimoivasta virtuaalikonekeskeisestä ajattelumallista kohti älykkäämpiä palveluita. Näiden älykkäiden palveluiden käyttäminen mahdollistaa keskittymisen olennaiseen, eli liiketoiminta-arvon tuottamiseen. Uuden sukupolven pilven kyvykkyyksien ja palvelujen kehitys tulee kiihtymään tulevaisuudessa.

Yhä laajemmin tulemme näkemään ja hyödyntämään pilvinatiiveja älykkäitä sovelluksia, jotka hyödyntävät tehokkaasti uuden sukupolven pilven kyvykkyyksiä verkon reunalta keskitettyihin palveluihin saakka.

Tämä mahdollistaa modernien tietoliikenneratkaisujen kanssa asiakkaille aivan uudenlaiset palvelut, joiden arkkitehtuuri kantaa pitkälle tulevaisuuteen. Esimerkkeinä laaja tuki Teollisuus 4.0:n reaaliaikaisuusvaatimuksille, itseohjautuvat autot, uudet terveydenhuollon palvelut tai todenmukainen virtuaalikokemus.

Kestävä ja uusiutuva pilviarkkitehtuuri, reunalaskennan hyödyntäminen ja älykkäiden palveluiden käyttö ovat kaikki osana #NEXTGENCLOUD-viitekehystämme.

Blogin kirjoittaja Jari Timonen on kokenut ohjelmistoalan ammattilainen, jolla on yli 20 vuoden kokemus tietotekniikka-alalta. Jarin intohimo on luoda siltoja liiketoiminnan ja teknisten tiimien välille, jossa hän on toiminut esimerkiksi Cargotecin edellisessä tehtävässään. Codentossa hän on elementissään luotsatessaan asiakkaita kohti tulevaisuuden kanssa yhteensopivia pilvi- ja hybridipilviympäristöjä.

#NEXTGENCLOUD Osa 1. Tulevaisuuden pilvi – ohituskaista liiketoimintahyötyihin?

Osa 1. Tulevaisuuden pilvi – ohituskaista liiketoimintahyötyihin?

Author: Jari Timonen, Codento

#NEXTGENCLOUD – tulevaisuuden pilvi – on viitekehys, jonka varaan me Codentolla uskomme asiakkaidemme pitkäjänteisen menestyksen rakentuvan.

Valtavirtatoimittajien pilvikyvykkyyksien kehittyessä kiihtyvällä vauhdilla on äärimmäisen tärkeää ottaa näiden uusien ominaisuuksien tuomat mahdollisuudet huomioon oikeita valintoja tehtäessä ja suunnitelmia kirkastettaessa.

Me Codentolla koemme tämän osa-alueen näkemyksen kehittämisen olevan keskeinen roolimme. Yhteistyössä teknologiatoimittajien ja asiakkaiden kanssa tuemme asiakkaiden liiketoimintaa sekä mahdollistamme sovellusinnovaatiot ja -modernisoinnin.

Kaksiosaisessa blogisarjassamme ja tulevassa #NEXTGENCLOUD-tapahtumassa avaamme keskeisiä näkemyksiämme

  • Osa 1: Tulevaisuuden pilvi: ohituskaistaa liiketoimintahyötyihin?
  • Osa 2: Tulevaisuuden pilvi: teknologian avulla pitkäjänteistä kilpailukykyä?

Tässä blogissa pohdimme miten tulevaisuuden pilvi mahdollistaa liiketoimintahyötyjen saavuttamisen nopeasti.

Liikkeellelähdössä avarakatseisuus on arvokasta

Pilvipalveluihin liittyvien liiketoimintanäkökulmien pohdinta vaatii monitasoista tarkastelua. Tässä pohdinnassa yhdistyvät tavoiteltavat liiketoimintahyödyt, sovellusten ominaispiirteet ja eri sidosryhmien toimintatavat ja tavoitteet.

Kuinka yhdistää nopea innovaatioiden hyödyntäminen kustannustehokkuuden parantamiseen? Oikeiden valintojen ja toteutusten kautta voidaan uutta liiketoimintaa tukea ja kehittää sekä nopeammin että tehokkaammin. Sovellusten näkökulmasta kyse on teknisen pilvialustan kyvykkyyksistä mahdollistaa tavoiteltavat hyödyt. Prosessien ja toimintatapojen näkökulmasta tavoitteena on läpinäkyvyys, joustavuus, automaatio ja skaalautuvuus.

Tukevaisuuden pilven hyödyt vaativat pilvikyvykkäitä sovelluksia

Liiketoiminnalle tärkeiden sovellusten modernisointi on keskeinen toimenpide liiketoimintahyötyjen saavuttamisessa.

Moni asiakas ei ole täysin saavuttanut tavoittelemiaan pilven hyötyjä ensimmäisen sukupolven pilviratkaisuissa. Osa pettymyksistä liittyy ns. lift-and-shift -typpiseen pilvisiirtymään, jossa sovellukset on siirretty lähes sellaisenaan pilveen. Tällöin lähes ainoa mahdollinen hyöty löytyy infrastruktuurikustannusten säästöistä.

Pilvikyvykkäät ns. pilvinatiivit sovellukset ovat lähtökohtaisesti ainoa oikea kestävä tie pilven laajojen liiketoimintahyötyjen saavuttamiseksi.

Tukevaisuuden pilven tuki sovelluksille

Tulevaisuuden pilvi tukee liiketoimintasovelluksia monella eri tasolla:

  • Pilvinatiivi, kustannustehokas ajoympäristö
  • Liiketoimintasovelluksia tai niiden osia korvaavat Platform-as-a-Service (PaaS) ja Software-as-a-Service (SaaS) -palvelut
  • Lisäarvotoiminnallisuudet, kuten kustannustehokas analytiikka- ja raportointi

Esimerkkeinä tällaisista liiketoimintasovelluksia tukevista pilviteknologioista ovat mm:

  • Google Cloud Anthos / Google Kubernetes Engine (Hybridi-, moni- ja yksipilviympäristöt)
  • Google Cloud BigQuery (Data Warehouse)
  • Google Data Studio (Raportointi)
  • Google Cloud Looker (Enterprise-tason analytiikka)

Pilvikyvykkyydet ja uusien mahdollisuuksien tunnistaminen

Useimmat organisaatiot ovat rakentaneet ensimmäisen sukupolven pilvikyvykkyytensä yhteen pääpilviteknologiaan perustuen.

Samanaikaisesti vaihtoehtoisten mahdollisuuksien kirjo on kasvanut ja käytännön oppien kautta on syntynyt hyvin nopeasti aiemman rinnalle suunnaksi ns. monipilvi (multi-cloud) -polku.

Molemmat etenemispolut edellyttävät jatkuvaa ja nopeaa uudistumis- ja innovointikykyä  koko organisaatiolta pilven liiketoimintahyötyjen saavuttamiseksi.

Tällä matkalla tarvitaan vankkaa liiketoiminnan tukea. Innovointi tapahtuu kehittäjien, arkkitehtien sekä heitä ohjaavan organisaation roolien yhteistyönä. Mukana olijat tarvitsevat realistiset taloudelliset mahdollisuudet onnistua. Aktiivinen vuorovaikutus eri osapuolien välillä on tärkeää onnistumisen kannalta. On tärkeää luoda kulttuuri, jossa voidaan kokeilla, epäonnistua, kokeilla uudestaan sekä onnistua.

Innovointia tukee ketteristä kehitysmenetelmistä tuttu iteratiivinen prosessi, jonka aikana tehdään hypoteeseja ja testataan niitä. Nämä lopputulokset näkyvät tulevaisuuden käytäntöön viedyissä toiminnallisuuksissa, toimintatavoissa ja tuotteistuksissa.

Tulevaisuuden pilvi ja innovoinnin kolme tasoa

Innovointi pilvessä nyt ja tulevaisuudessa voidaan jakaa karkeasti kolmeen eri osa-alueeseen:

  • Liiketoiminta pitää olla oikea-aikaista, kannattavaa sekä tulevaisuuteen katsovaa. Innovoinnilla luodaan uutta liiketoimintaa tai kiihdytetään nykyistä.
  • Konsepti varmistaa, että olemme tekemässä oikeita asioita. Tämän pitää olla asiakkailla varmistettua ja mahdollisimman oikeaksi todettua. Asiakas tarkoittaa kohderyhmää, joka voi koostua sisäisistä tai ulkoisista käyttäjistä.
  • Tekninen kyvykkyys luo pohjan kaikelle innovaatiolle sekä tulevaisuuden tuotteistamiselle. Kyvykkyys kasvaa ja kehittyy liiketoiminnan mukana joustavasti ja ketterästi.

Tulevaisuuden pilvi tukee edellä mainittuja kolmea polkua vielä tehokkaammin kuin aiemmin. Pilveen kasvaa uusia alusta- sekä API-talouden mahdollistavia palveluita, jotka vähentävät ylläpitoon tarvittavaa aikaa.

Nopein tapa liiketoimintahyötyihin kulkee MVP:n kautta

Pilveen kehittämisen tulee olla merkityksellistä sekä arvoa tuottavaa. Tämä kuulostaa itsestään selvältä, mutta se ei aina ole sitä.

Arvontuotto voi merkitä eri asioita eri ihmisille. Siksi Minimum Viable Product (MVP) -lähestyminen on hyvä tapa aloittaa toteutus. MVP on tapa, jolla kuvataan pienin arvoa tuottava yksikkö mikä voidaan toteuttaa ja viedä tuotantoon. Monesti tässä vanhat ajatusmallit tuottavat ansoja: “Kaikki ominaisuudet pitää olla valmiina, jotta saataisiin hyötyä.” Kuitenkin, jos tuotetta aletaan ”harjaamaan”, niin sieltä löytyy asioita, joita ei tarvita ensimmäisessä vaiheessa.

Näitä voi olla esimerkiksi oman profiilin muutokset, loppuun asti hiotut visuaaliset animaatiot tai laaja lista ominaisuuksia. MVP on hyvä tapa myös validoida omia suunnitelmia ja arvioida sovelluksen arvolupausta.

Pilvi tukee tätä tarjoamalla innovointiin ja kehitykseen työkaluja sekä melkein rajattoman kapasiteetin. Tämä kehitys tulee jatkumaan tulevaisuuden pilvessä antaen uusille sovelluksille paremman mahdollisuuden onnistua tavoitteissaan.

Ja lopuksi

Nopein ja todennäköisin onnistumisen kiihdytyskaista liiketoimintahyötyihin kulkee siis #NEXTGENCLOUD-ajattelun, pilvikyvykkäiden sovellusten ja MVP-toimintamallin kautta.  Blogikokonaisuuden toisessa osassa pohditaan myöhemmin enemmän teknologianäkökulmia ja pitkäjänteisten hyötyjen saavuttamista.

Artikkelin kirjoittaja, Codenton Lead Cloud Architect, Jari Timonen, on kokenut ohjelmistoalan ammattilainen, jolla on yli 20 vuoden kokemus tietotekniikka-alalta. Jarin intohimo on luoda siltoja liiketoiminnan ja teknisten tiimien välille, jossa hän on toiminut esimerkiksi Cargotecin edellisessä tehtävässään. Codentossa hän on elementissään luotsatessaan asiakkaita kohti tulevaisuuden kanssa yhteensopivia pilvi- ja hybridipilviympäristöjä.