Kysy lisää palvleuistamme:
Kirjoittaja: Antti Pohjolainen, Codento
Tämä on viimeinen osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Aiemmat kirjoitukset ovat täällä: Osa 1, osa 2 ja osa 3.
Lopputyöni tutkimuskysymys on ”Mitä liiketoimintahyötyjä on saatavilla monipilviarkkitehtuurista?” Kirjallisuusanalyysin mukaan merkittävimpiä etuja ovat kustannussäästöt, toimittajalukkojen välttäminen ja IT-valmiuksien parantaminen hyödyntämällä useiden julkisten pilvien tarjoamia kehittyneimpiä ominaisuuksia.
Haastatteluista saatujen tietojen mukaan toimittajalukkoja ei koeta suureksi ongelmaksi. Joidenkin haastateltavien mukaan eri julkisten pilvien parhaat ominaisuudet kannattaa hyödyntää. Monipilven käyttöönotto voi johtaa kustannussäästöihin. Kuitenkin näyttää siltä, että “monipilvi-uhkaa” käytetään sopimusten uusimisneuvottelujen aikana lähinnä neuvottelutaktiikkana. Tällä painostetaan nykyistä julkista pilven toimittajaa laskemaan kustannuksia, jotta uusi sopimus olisi edullilsempi.
Kirjallisuusanalyysi ja haastattelut paljastivat, että keskeisimmät ongelmat monipilviarkkitehtuurissa olivat sen lisääntynyt monimutkaisuus, turvallisuus ja taitovaatimukset. Haastattelujen suurin yllätys minulle oli se, ettei asiakkailla ollut valintakriteereita hyperskaalaajien valinnalle. Haastattelujen perusteella markkinoilla on selvä tilaus sekä Google Cloudille että monipilvelle.
Akateemisen tutkimuksen ja haastatteluista poimittujen tietojen mukaan useimmat asiakkaat valitsevat monipilviarkkitehtuurin siten kuin tässä tutkimuksessa monipilvi määriteltiin. Pilviteknologian hyödyntämisestä saatujen hyötyjen pitäisi olla suurempia kuin lisätyö, joka tarvitaan monipilviarkkitehtuurin rakentamiseen, vaikka monipilveen liittyykin useita riskejä.
Haastateltujen päättäjien mukaan heidän nykyinen päätöksensä on toteuttaa yksi, ensisijainen pilvi, jota täydennetään palveluilla yhdestä tai useammasta muusta pilvestä. Suurimman osan työkuormista odotetaan kuitenkin pysyvän nykyisessä ensisijaisessa pilvessä.
Suosittelen, että yritykset arvioisivat ja päivittäsivät säännöllisesti pilvistrategiaansa. Sen sijaan, että arkkitehtuurin annettaisiin kehittyä mielivaltaisesti pelkästään palvelutoimittajien tai ulkoistettujen kumppaneiden tarpeiden perusteella, yrityksen tulisi ottaa strategia täysin hallintaansa.
Yritysten tulee minimoida pilvipalveluntarjoajien omistamien rajapintojen ja tekniikoiden käyttö, ellei 1) siitä ole todistettavissa olevaa taloudellista hyötyä, 2) muita teknisiä vaihtoehtoja ole olemassa, esimerkiksi muut palveluntarjoajat eivät tarjoa kyseistä toiminnallisuutta tai 3) niistä saada muita teknisiä hyötyjä, kuten merkittäviä suorituskyvyn parannuksia. Yritykset voivat vähentää toimittajalukkojen todennäköisyyttä noudattamalla näitä neuvoja.
Jos yritys käyttää tällä hetkellä vain yhden hyperskaalaajan pilvipalveluita, kannattaa konseptin testaus (Proof-of-concept, PoC) muiden pilvipalveluntarjoajien kanssa aloittaa heti, kun liiketoimintatarve syntyy. Jos mahdollista, toimittajakohtaisia teknologioita, API:ita tai palveluita tulisi välttää konseptitoteutuksissa.
Suosittelen, että yritykset luovat pilvitoimittajien hallintakäytännöt, jotka kattavat kaiken hankinnasta operatiiviseen hallintaan. Toimittajien hallinta monipilviympäristössä vaatii enemmän suunnittelua ja taitoa verrattuna vain yhteen hyperskaalaajaympäristöön.
Lisäksi suosittelen rakentamaan käytäntöjä ja menetelmiä kustannusten seurantaan, sillä pilvipalvelun käytön odotetaan lisääntyvän tulevina vuosina.
Tämä blogikirjoitus päättää Matkani monipilven maailmaan -sarjan. Me täällä Codentossa autamme mielellämme sinua matkallasi monipilven maailmaan. Ota rohkeasti yhteyttä minuun keskustelun aloittamiseksi. Tavoitat kollegani tai minut täältä.
Kirjoittaja: Antti Pohjolainen, Codento
Kirjoittajasta: Myyntijohtaja Antti “Apo” Pohjolainen aloitti Codenton palveluksessa vuonna 2019. Antti on johtanut Innofactorin Suomen myyntiorganisaatiota (pohjoismainen Microsoftin IT-toimittaja) ja työskennellyt sitä ennen Microsoftin julkisen sektorin johtotehtävissä Suomessa ja Itä-Euroopassa. Apo on työskennellyt eri myyntitehtävissä kauemmin kuin hän muistaa. Hän saa ”myyjän onnistumisen tunteen” tavatessaan asiakkaita ja etsiessään ratkaisuja, jotka tarjoavat arvoa kaikille osapuolille.
Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:
Kirjoittaja: Antti Pohjolainen, Codento
Tämä on kolmas osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Aiemmat kirjoitukset ovat täällä: Osa 1 ja osa 2.
Tämä kirjoitus kuvaa joitain oivalluksia, joita sain varsinaisista haastatteluista. Kuten osassa 1 kerrottiin, minulla oli tilaisuus haastatella 11 yritysjohtajaa ja alan asiantuntijaa.
Haastatteluista saatujen tietojen perusteella suomalaiset asiakkaat käyttävät enimmäkseen yhtä julkista pilveä hoitaakseen suurimman osan työkuormistaan. Nykyisen ajattelun mukaan, jos olemassa oleva pilvipalveluntarjoaja ei tarjoa tiettyä palvelua, voidaan pilven tueksi lisätä pistemäisiä ratkaisuja muista pilvistä. Näin ollen muiden pilvipalveluntarjoajien täydentävät tekniset valmiudet ovat ensisijainen perustelu rakennettaessa monipilviarkkitehtuuria.
Toisin kuin akateemisessa kirjallisuudessa (katso lisätietoja osasta 2), jossa säästöt mainitaan usein yhtenä tärkeimmistä kriteereistä monipilven valinnassa, suurin osa haastatelluista ei pitänyt monipilviä merkittävänä kustannussäästökeinona.
Kustannussäästöjä on vaikea arvioida, ja haastattelujen perusteella useimmat yritykset eivät tällä hetkellä ole asiantuntijoita pilvikäsittelyn kustannusten seurannassa. Hinnoittelukäytännöt vaihtelevat hyperskaalaajien välillä, ja niiden katsotaan muuttuvan usein.
Lisäksi haastateltavat eivät olleet huolissaan mahdollisista toimittajalukoista. Tämä havainto on tärkeä ja se poikkeaa akateemisesta kirjallisuudeta, jossa toimittajien sulkemista pidetään tärkeänä, kenties kriittisimmäksi ongelmaksi yrityksille.
Useiden haastateltujen, jotka edustivat kaikkia tutkittuja ryhmiä, mukaan merkittävin este monipilveen sopeutumiselle on osaamisen ja valmiuksien puute. Tämä johtuu kahdesta taustalla olevasta tekijästä:
Suomessa IT-palvelujen ulkoistustaso on poikkeuksellisen korkea. Haastattelut osoittivat, että Suomen korkealla ulkoistamisella on merkittävä negatiivinen vaikutus pilvipalveluiden käyttöönottoon.
Asiakkaiden ulkoistamat konesali-infrastruktuurit ja hosting-palveluntarjoajan omat palvelimet tuottavat merkittävän osan ulkoistuskumppaneiden liiketoiminnasta. He ovat investoineet rakennuksiin ja IT-laitteisiin, joten he menettävät rahaa, jos asiakkaat käyttävät laajasti pilvilaskentaa.
Kerätyt vastaukset jakautuivat turvallisuus- ja tietosuojakysymyksissä. Jotkut haastateltavat pitivät pilviturvallisuutta suurinpana esteenä kriittisten sovellusten pilveistämisessä. Yksikään haastattelemista tietotekniikan palveluntarjoajista ei kuitenkaan pitänyt tätä aitona huolenaiheena.
Julkinen sektori – erityisesti valtionhallinto – on ollut hidas julkisen pilven käyttöönotoissa. Joidenkin haastateltujen mukaan hallinnonalan laajuiset politiikat pilvipalveluiden käyttöönotossa ovat epäselviä.
Monet kyselyyn vastanneista uskoivat, että koska pilvipalvelun käyttöönotosta ei ollut vakiintuneita, selkeitä valtionhallinnon laajuisia säännöksiä, organisaatiot viivyttelivät valintaansa sopeutua pilveen.
Jotkut haastatelluista olivat huolissaan siitä, että heidän yritykseltään tai asiakkaaltaan puuttui selkeä pilvistrategia, pilvipalvelun valintastandardit tai pilvipalvelun toteutusstrategia. Tämän huolen esittivät haastateltavat kaikista kolmesta ryhmästä.
Yritykset hyötyisivät selkeästi muotoillusta suunnitelmasta ja valintakriteeriluettelosta, kun ne harkitsevat uusien ominaisuuksien lisäämistä olemassa olevaan pilviarkkitehtuuriinsa, koska yhä useampi henkilö on mukana valitsemassa pilvipalveluita.
Sarjan viimeinen blogikirjoitus on nimeltään ”Johtopäätös ja suositukset”. Pysy kanavalla!
Kirjoittaja: Antti Pohjolainen, Codento
Kirjoittajasta: Myyntijohtaja Antti “Apo” Pohjolainen aloitti Codenton palveluksessa vuonna 2019. Antti on johtanut Innofactorin Suomen myyntiorganisaatiota (pohjoismainen Microsoftin IT-toimittaja) ja työskennellyt sitä ennen Microsoftin julkisen sektorin johtotehtävissä Suomessa ja Itä-Euroopassa. Apo on työskennellyt eri myyntitehtävissä kauemmin kuin hän muistaa. Hän saa ”myyjän onnistumisen tunteen” tavatessaan asiakkaita ja etsiessään ratkaisuja, jotka tarjoavat arvoa kaikille osapuolille.
Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:
Kirjoittaja: Antti Pohjolainen, Codento
Tämä on toinen osa neljän blogikirjoituksen sarjasta, joka kattaa matkani monipilven maailmaan. Edellisessä postauksessa kerrottiin tämän sarjan taustasta.
Tämä postaus esittelee lyhyesti, mitä akateemisessa kirjallisuudessa yleensä luetellaan monipilviarkkitehtuurin hyödyiksi ja haasteiksi.
Akateemisessa kirjallisuudessa mainitaan yleisesti seuraavat monipilviarkkitehtuurista koituvat hyödyt:
Kustannussäästöt johtuvat siitä, että hyperskaalaajien markkinaosuuskilpailu on kovaa, mikä on johtanut laskenta- ja tallennuskustannusten laskuun.
Lisääntynyt saatavuus (availability) ja redundanssi, katastrofipalautus ja geolokaatiot ovat usein esimerkkejä paremmista IT-ominaisuuksista, jotka voidaan saavuttaa käyttämällä useamman kuin yhden hyperskaalaajan tarjoamia pilvipalveluita.
Ehkä tärkein syy, ainakin akateemisen kirjallisuuden näkökulmasta katsottuna, usean pilven arkkitehtuurin toteuttamiseen on toimittajalukon välttäminen. Palvelujen hankkiminen vain yhdeltä hyperskaalaajalta luo suuremman riippuvuuden toimittajaan verrattuna tilanteeseen, jossa pilvipalveluntarjoajia on useampi kuin yksi.
Siten termi ”toimittajalukko”. Tyypillisesti pilvipalveluntarjoajalta vaihtaminen aiheuttaa huomattavia kuluja, sillä palveluntarjoajan vaihtaminen vaatii usein järjestelmän uudelleensuunnittelua, uudelleenkäyttöönottoa ja datan siirtoa.
Yhteenvetona voidaan todeta, että valitsemalla parhaan laajasta pilvipalveluiden valikoimasta monipilviinfrastruktuuri lupaa ratkaista toimittajalukot ja johtaa käyttäjien tarpeiden optimointiin.
Monipilvi-infrastruktuurin käyttöönotto tuo mukanaan useita haasteita, joihin tulisi vastata, jotta niistä saataisiin täysi hyöty. Seuraavat kappaleet käsittelevät yleisimmin akateemisessa kirjallisuudessa viitattuihin haasteisiin.
Kun data, alustat ja sovellukset ovat hajallaan useissa paikoissa, kuten erilaisissa pilvissä ja yrityspalvelinkeskuksissa, syntyy uusia haasteita. Eri toimittajien hallinta kaikkien sovellusten näkyvyyden varmistamiseksi, erilaisten järjestelmien ja tietokantojen suojaaminen sekä kulujen hallinta lisäävät monipilvistrategian monimutkaisuutta.
Monimutkaisuus lisääntyy, kun kunkin toimittajan tarpeet ja vaatimukset ovat tyypillisesti erilaisia, ja niitä on käsiteltävä erikseen. Esimerkiksi hyperskaalaajat vaativat usein omat rajapinnat antaakseen pääsyn resursseihin ja palveluihin.
Tietoturva on yleisesti ottaen monipilviympäristössä monimutkaisempi toteuttaa kuin yhden pilvipalveluntarjoajan arkkitehtuurissa.
Monipilvi vaatii erityisosaamista ainakin tekniseltä ja liiketoimintalähtöiseltä henkilökunnalta sekä toimittajanhallintaryhmältä. Rekrytointi-, koulutus- ja monipilvistrategiainvestointien budjetit kasvavat, mikä pakottaa yritykset hankkimaan uutta tietoa ja kykyjä esimerkiksi ylläpidon, toteutuksen ja kustannusten optimoinnin aloilla.
Lisäksi sanotaan, että pilvipalvelun avulla voidaan edistää innovaatioita, muuttaa IT-osaston roolia rutiinihuollosta liiketoiminnan tukemiseen sekä tehostaa yritysten sisäistä ja ulkoista yhteistyötä. Siten IT:n roolia voidaan joutua säätämään monipilviarkkitehtuuria toteutettaessa.
Toimittajahallinta– tai hankintatiimien on ehkä opittava uusia taitoja ja menetelmiä voidakseen valita sopivan hyperskaalaajan erilaisiin tarpeisiin. Jokaisella hyperskaalaajalla on erilaiset palvelut ja hinnoittelumenetelmät, ja niiden ymmärtäminen vaatii asiantuntemusta, jota ei välttämättä tarvita, jos työskentelee vain yhden hyperskaalaajan kanssa.
Seuraavassa postauksessa kerron, mitä opin tätä tutkimusprojektia varten tekemistäni haastatteluista. Pysy kanavalla!
Kirjoittaja: Antti Pohjolainen, Codento
Kirjoittajasta: Myyntijohtaja Antti “Apo” Pohjolainen aloitti Codenton palveluksessa vuonna 2019. Antti on johtanut Innofactorin Suomen myyntiorganisaatiota (pohjoismainen Microsoftin IT-toimittaja) ja työskennellyt sitä ennen Microsoftin julkisen sektorin johtotehtävissä Suomessa ja Itä-Euroopassa. Apo on työskennellyt eri myyntitehtävissä kauemmin kuin hän muistaa. Hän saa ”myyjän onnistumisen tunteen” tavatessaan asiakkaita ja etsiessään ratkaisuja, jotka tarjoavat arvoa kaikille osapuolille.
Tutustu Codenton online-tapahtumien nauhoituksiin, niin kuulet lisää:
Kirjoittaja: Janne Flinck, Codento
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.
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.
Pohjimmiltaan LTV-malleja voidaan käyttää vastaamaan seuraavanlaisiin kysymyksiin:
Asiakkaan elinkaaren arvoa ennustaessa yleensä kohdataan erilaisia ongelmia, jotka vaativat erilaisia lähestymistapoja:
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:
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.
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.
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.
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.
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.
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:
Jos pystyt vastaamaan näihin kysymyksiin, olet valmis elinkaaren arvon mallinnuksen käyttöönottoon.
Tutustu demoon täällä.
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ää.
Kirjoittaja: Anthony Gyursanszky, toimitusjohtaja, Codento
Koska meidän Codenton tekniset konsulttimme ovat olleet kiireisiä Google Cloud -sertifikaattien suorittamisessa, minä ja enemmän kaupalliset kollegani olemme yrittäneet pysyä tahdissa käymällä Googlen myyntikurssit (nämä vaaditaan yritystason kumppanistatuksen saavuttamiseksi) ja opiskelemalla perusasiat Courseran Google Cloud -peruskurssien avulla. Vaikka jälkimmäisten kurssien tekniset labrat olivatkin mielenkiintoisia ja konkreettisia, niitä ei niinkään tarvita omissa tehtävissämme.
Näistä näkökulmasta heräsikin kysymys: mikä on oikea tapa hankkia riittävästi tietoa pilviteknologiasta ja digitaalisesta transformaatiosta liiketoiminnan näkökulmasta sekä oppia uusimmat Google Cloud -tuotteet ja tiekartat?
Olenkin viime aikoina huomioinut, että monet kollegani muissa ekosysteemiyrityksissä ovat suorittaneet Googlen Cloud Digital Leader -sertifikaatin. Uteliaisuuteni heräsi: olisiko tämä sertifikaatti hyödyllinen myös minulle?
Miksi ylipäätään vaivautua?
Googlen sanoin ”Cloud Digital Leader on lähtötason sertifiointikoe, ja sertifioitu voi osoittaa Google Cloud -ydintuotteiden ja -palveluiden ominaisuudet ja niiden hyödyn organisaatioille. Cloud Digital Leader voi myös kuvata yleisiä yrityskäyttötapauksia ja kuinka pilviratkaisut tukevat yritystä.”
Oletin aiemmin, että tämä sertifikaatti kattaa sekä Google Cloudin että Google Workspacen ja erityisesti miten kulttuurinen muutos johdetaan Workspace-alueella, mutta tämä oletus osoittautui täysin vääräksi. Workspacea ei käsitellä, kyse on pelkästään Google Cloudista. Tämä oli hyvä uutinen minulle, sillä vaikka olemmekin tyytyväisiä Workspacen käyttäjiä Condetolla, konsultointiliiketoimintamme perustuu yksinomaan Google Cludiin.
Mitä sertifikaatti sitten kattaa? Kuvailisin sisältöä seuraavasti:
Mikäli nämä aiheet ovat sinulle tärkeitä ja haluat ottaa vastaan sertifiointihaasteen, Cloud Digital Leader on sinua varten.
Kun etenin sertifikaattimatkassani sain tietää, että Google tarjoaa ilmaisia koulutusmoduuleja kumppaneille. Kumppanien tekninen koulutussisältö on saatavilla kumppaneille Google Cloud Skills Boost for Partners -palvelussa. Mikäli et ole Google Cloud -kumppani, sama koulutus on saatavilla myös ilmaiseksi täältä.
Koulutusmoduulit ovat korkealaatuisia, erittäin selkeitä ja helppoja seurata. Jokaisessa neljässä moduulissa on kalvopaketti, jossa kussakin on noin 70 kalvoa. Tekstin ja tiedon määrä kalvoa kohden on pieni, eikä niiden läpikäyminen vie montaa minuuttia.
Varsinaiset koulutusvideot voi katsoa läpi kaksinkertaisella nopeudella, ja jokaisen osion jälkeen on vastattava 80 %:n oikein. Toisin kuin varsinaisessa sertifiointitestissä, kysymykset osoittautuivat hieman vaikeammiksi, koska vastaan tuli myös monivalintakysymyksiä.
Kokemukseni mukaan koulutuksen läpikäymiseen ja varsinaisen sertifikaatin suorittamiseen menee noin 4-6 tuntia. Tämä on siis hyvin erilainen vaatimustasoltaan kuin tekniset sertifikaatit, joissa on kyse viikkojen ponnisteluista ja tarvittavista kattavista esitiedoista.
Helpoin tapa suorittaa sertifikaatti on varata verkossa valvottu testi Webasessorin kautta. Hinta on 99 USD plus ALV, joka tulee maksaa etukäteen. Etätesteille on tarjolla runsaasti aikoja 15 minuutin välein käytännössä kaikkina arkipäivinä. Ja kyllä, jos mietit, aikavälit esitetään paikallisessa ajassasi, vaikka sitä ei mainitatkaan.
Kuinka suorittaa online-testi? Ennen koetta on muutama asia varmistettava:
Tenttilinkki ilmestyy Webassessor-sivustolle muutama minuutti ennen suunniteltua ajankohtaa. Tämän jälkeen joudut odottamaan ensin 5-15 minuuttia aulassa ja sinut ohjataan muutaman vaiheen läpi, kuten henkilöllisyystodistuksesi näyttäminen ja huoneesi ja pöytäsi näyttäminen web-kamerallasi. Tämä osa kestää noin 5-10 minuuttia.
Kun olet ilmoittautunut kokeeseen, aikalaskuri näkyy koko kokeen ajan. Vaikka enimmäisaika on 90 minuuttia, kaikkiin 50–60 kysymykseen vastaaminen vie todennäköisesti vain noin 30 minuuttia. Kysymykset ovat melko lyhyitä ja yksinkertaisia. Vaihtoehtoja ehdotetaan neljää ja vain yksi on oikea. Jos epäröit kahden mahdollisen oikean vastauksen välillä (kuten minulle kävi muutaman kerran), voit palata niihin lopuksi. Joidenkin lähteiden mukaan riittää, että 70 prosenttiin kysymyksistä on vastattava oikein.
Kun olet lähettänyt vastauksesi, saat heti tiedon siitä läpäisitkö vai et. Tietoja arvosanoista tai oikeista/vääristä vastauksista ei kuitenkaan anneta. Google lähettää sinulle varsinaisen todistuksen muutaman arkipäivän kuluessa. Mahdollinen uusi testi voidaan ajoittaa aikaisintaan 14 päivän ajanjakson jälkeen.
Cloud Digital Leader -sertifikaattia ei lasketa varsinaisesti Googlen ammattisertifikaatiksi, ja sitä ei sisällytetä yritystason kumppanistatuksiin tai spesialisaatioihin. Tämä saattaa kuitenkin muuttua tulevaisuudessa.
Oletan, että Googlella on seuraavat tavoitteet tälle sertifikaatille:
Sertifiointi on voimassa kolme vuotta, mutta vaikka perusperiaatteet pätevät jatkossakin Google Cloud -tuotetuntemus vanhenee melko nopeasti.
Oliko ajankäyttö panostuksen arvoista? Minulle ehdottomasti kyllä. Kävin käytännössä läpi aineiston yhdessä iltapäivässä ja varasin serttitestin seuraavalle aamulle, joten tähän ei mennyt liikaa aikaa. Mutta koska olen jo jonkinlainen pilviveteraani ja Google Cloudin puolestapuhuja, olettaisin, että tämä olisi arvokkaampi silmien avaaja AWS/Azure-kannattajille, jotka eivät vielä ole perehtyneet Google Cloudin laajaan potentiaaliin. Peukut pystyssä myös meille kaikille Googlen ekosysteemissä oleville liiketoiminnan ammattilaisille – tämä on käytännössä pakollinen portti ekosysteemissämme työskentelemiseen.
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.
Ota yhteyttä ja kysy lisää Codenton palveluista:
By Codenton konsultit
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:
Käydään seuraavaksi yhdessä Codenton konsulttien kanssa tätä mielenkiintoista vuoropuhelua läpi.
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.”
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.”
“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.”
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.
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.”
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:
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.
Sudenkuoppiin putoamisen ennaltaehkäisyksi Codenton konsultit ovat luvanneet tarjota kahden tunnin veloituksettomat työpajat halukkaille organisaatioille aina yhteen näistä sudenkuopista kerrallaan keskittyen:
Kysy meiltä lisää ja varataan aika jo elokuulle, niin syksy lähtee mukavasti käyntiin sudenkuoppia vältellen.
Voiko moderneilla koneoppimistyökaluilla tehdä viikon työt yhdessä iltapäivässä? Koneoppimismallien kehitystyö on perinteisesti ollut erittäin iteratiivinen prosessi. Perinteinen koneoppimisprojekti aloitetaan datasettien valinnalla ja esikäsittelyllä: puhdistuksella ja preprosessoinnilla. Vasta tämän jälkeen voidaan aloittaa varsinainen koneoppimismallin kehitystyö.
On erittäin harvinaista, käytännössä mahdotonta, että uusi koneoppimismalli kykenee ensimmäisellä yrittämällä antamaan riittävän hyviä ennusteita. Kehitystyö sisältääkin perinteisesti merkittävän määrän epäonnistumisia niin algoritmien valinnassa kuin niiden hienosäädössä, ammattikielellä hyperparametrien tuunauksessa.
Kaikki tämä vaatii työaikaa, toisin sanoen rahaa. Entä, jos datan puhdistamisen jälkeen kaikki kehitystyön vaiheet voisi automatisoida? Entä, jos kehitysprojekti voitaisiin viedä läpi ylinopeudella tahdilla sprintti per päivä?
Viime vuosina koneoppimismallien rakentamisen automatisointi (AutoML) on ottanut merkittäviä harppauksia. Karkeasti kuvattuna perinteisessä koneoppimisessa data scientist rakentaa koneoppimismallin ja kouluttaa sen isohkolla datasetillä. AutoML puolestaan on uudehko lähestymistapa, jossa koneoppimismalli rakentaa ja kouluttaa itse itsensä isohkon datasetin avulla.
Data scientistin ei tarvitse kuin kertoa, millainen ongelma on kyseessä. Kyseessä voi olla esimerkiksi konenäköön, hinnoitteluun tai vaikkapa tekstianalyysiin liittyvä ongelma. Työttömäksi data scientist ei kuitenkaan AutoML-mallien takia jää. Työkuorma siirtyy mallin hienosäädöstä validointiin ja explainable-AI -työkalujen käyttöön.
Jokin aika sitten testasimme Codentolla Google Cloud AutoML-pohjaisia koneoppimistyökaluja [1]. Tavoitteenamme oli selvittää, miten Google Cloudin AutoML-työkalu suoriutuu Kagglen House Prices – Advanced Regression Techniques -haasteesta [2].
Tavoitteena haasteessa on rakentaa mahdollisimman tarkka työkalu ennustamaan asuntojen myyntihintoja niiden ominaisuuksien perusteella. Hinnoittelumallin rakennuksessa käytetty datasetti sisälsi noin 1400 asunnon tiedot: Yhteensä 80 erilaista potentiaalisesti hintaan vaikuttavaa parametria sekä asuntojen toteutuneet myyntihinnat. Osa parametreista on numeerisia, osa puolestaan kategorisia.
Käytettävä data oli valmiiksi siivottua. Koneoppimismallin rakentamisen ensimmäinen vaihe oli siis valmiiksi tehty. Ensin datasetti, csv-muotoinen tiedosto, ladattiin sellaisenaan Google Cloudin BigQuery-datavarastoon. Latauksessa hyödynnettiin BigQueryn kykyä tunnistaa tietokantaskema suoraan tiedoston rakenteesta. Varsinaisen mallin rakentamisessa hyödynnettiin VertexAI-työkalusta löytyvää AutoML Tabular -ominaisuutta.
Lyhyen kliksuttelun jälkeen työkalulle oli saatu kerrottua, mitkä hintaa ennustavista parametreista olivat numeerisia ja mitkä kategorisia muuttujia. Lisäksi työkalulle kerrottiin, minkä nimiseltä sarakkeelta löytyy ennustettava parametri. Kaikkeen tähän kului työaikaa noin tunti. Tämän jälkeen koulutus käynnistettiin ja ryhdyttiin odottamaan tuloksia. Noin 2,5 tuntia myöhemmin Google Cloudin robotti lähetti sähköpostin ilmoittaen mallin olevan valmis.
AutoML:n luoman mallin tarkkuus yllätti kehittäjät. Google Cloud AutoML kykeni rakentamaan itsenäisesti hinnoittelumallin, jonka ennustaa asuntojen hintoja noin 90% tarkkuudella. Tarkkuustaso sinänsä ei poikkea hinnoittelumallien yleisestä tarkkuustasosta. Huomattavaa tässä on kuitenkin se, että tämän mallin kehitystyöhön kului yhteensä puolikas työpäivä.
Google Clloudin AutoML:n edut eivät kuitenkaan lopu tähän. Tämä malli olisi mahdollista liittää hyvin pienellä vaivalla osaksi Google Cloudin dataputkistoa. Malli voitaisiin myös ladata konttina ja ottaa käyttöön muissa pilvipalveluissa.
AutoML:ään perustuvia työkaluja voi hyvästä syystä pitää koneoppimisen uusimpana merkittävänä kehitysaskeleena. Työkalujen ansiosta yksittäisen koneoppimismallin kehitystyötä ei enää tarvitse ajatella projektina tai investointina. Näiden työkalujen koko potentiaalia hyödyntämällä voidaan malleja rakentaa likimain nollabudjetilla. Uusia koneoppimiseen pohjautuvia ennustemalleja voidaan rakentaa melkeinpä hetken mielijohteesta
AutoML-työkalujen tehokas käyttöönotto kuitenkin vaatii merkittäviä alkuinvestointeja. Työkaluja hyödyntävän organisaation liiketoiminnan koko datainfra, säilytysratkaisut, dataputket sekä visualisointikerrokset, on ensin rakennettava pilvinatiiveilla työkaluilla. Codenton sertifioidut pilviarkkitehdit ja datainsinöörit auttavat näissä haasteissa.
Lähteet:
Artikkelin kirjoittaja on Jari Rinta-aho, Senior Data Scientist & Consultant, Codento. Jari on koneoppimisesta ja matematiikasta kiinnostunut konsultti ja fyysikko, jolla on laaja kokemus koneoppimisen hyödyntämisestä ydinenergian parista. Hän on myös opettanut yliopistossa fysiikkaa sekä johtanut kansainvälisiä tutkimusprojekteja. Jarin kiinnostuksen kohteet ovat ML-Ops, AutoML, Explainable AI ja Teollisuus 4.0.
Kysy lisää Codenton AI- ja datapalveluista:
Author: Jari Timonen, Codento Oy
Henkilökohtaiset sertifikaatit tarjoavat IT-palveluyrityksille keinon kuvata omien konsulttien osaamisen taso ja laajuus. IT-palveluiden hankkijalle sertifikaatit ainakin teoriassa takaavat, että henkilö osaa asiansa.
Sertifikaattitesti suoritetaan valvotuissa olosuhteissa ja sisältää yleensä monivalintakysymyksiä. Lisäksi markkinoilta löytyy myös tehtäväpohjaisia kokeita, jolloin vaadittu tehtävänanto tehdään vapaasti kotona tai töissä.
Sertifikaatteja on monen tasoisia erilaisille kohderyhmille. Yleensä ne ovat hierarkkisia, jolloin täysin vieraan aiheen voi aloittaa helpoimmasta päästä. Korkeimmalla tasolla ovat vaikeimmat sekä arvostetuimmat sertifikaatit.
Henkilökohtaiset sertifikaatit kuuluvat Codentolla olennaisena osana itsensä kehittämiseen. Ne ovat yksi mittari osaamisesta. Tuemme sertifikaattien suorittamista mahdollistamalla työajan käyttämistä opiskeluun sekä maksamalla kursseja ja itse tentin. Googlen valikoimasta löytyy jokaiselle oikean tasoinen ja aiheinen sertifikaatti suoritettavaksi.
Ajantasainen lista sertifikaateista löytyy Google Cloudin sivuilta.
Sertifikaattien suoritus pelkän “plakaattien” vuoksi ei ole kovin järkevä lähestymistapa. Sertifikaattien saavuttaminen pitäisi nähdä tavoitteellisena maalina, jota kohti opiskellessa tulee luettua rakenteellisesti. Tämä tarkoittaa, että itsensä kehittämisessä on jokin punainen lanka, jota noudattaa.
Tavoitteellisuus voi olla ainoastaan yhden sertifikaatin suorittaminen tai esimerkiksi suunniteltu polku kolmen eri tason läpi. Tällä tavalla itsensä kehittäminen on paljon helpompaa, kuin lukea artikkeli sieltä täältä ilman päämäärää.
Päämäärän asettamisen jälkeen tulee valita aikataulu kokeen suorittamiselle. Tämä vaihtelee todella paljon riippuen lähtötasosta ja suoritettavasta sertifikaatista. Jos olemassa olevaa osaamista on ennestään, lukeminen saattaa olla pelkkää kertaamista. Yleisesti ajatellen lukemiseen tulisi varata muutamia kuukausia. Pidemmällä aikavälillä opiskelusta jää enemmän muistiin ja siten opiskelusta on enemmän hyötyä.
Aika ajoin tulisi tehdä testitenttejä. Ne auttavat selvittämään, mitä kokeen osa-aluetta tulisi lukea enemmän ja mitkä alueet ovat jo hallussa. Testitenttejä kannattaa tehdä jo lukemisen alkuvaiheilla vaikka tulos olisi huono. Näin kertyy kokemusta varsinaista koetta varten eivätkä kokeen kysymykset tule täytenä yllätyksenä.
Koe tulisi varata noin 3-4 viikkoa ennen aikataulutettua suorituspäivää. Tässä ajassa ehtii tekemään tarpeeksi testitenttejä sekä vahvistamaan osaamista.
Lukeminen kannattaa aloittaa koealueen ymmärtämisellä. Tämä tarkoittaa kokeen eri painotuksien selvittämistä ja asioiden listaamista. Lukemisesta kannattaa tehdä karkea suunnitelma aikataulutettuna eri osa-alueiden mukaan
Suunnitelman jälkeen opiskelun voi aloittaa aihealue kerrallaan. Aiheita voi lähestyä ylhäältä alaspäin, eli yrittää ensin ymmärtää kokonaisuus, jonka jälkeen pureutua yksityiskohtiin. Yksi tärkeimmistä työkaluista pilvipalveluiden sertifikaatteihin opiskelussa on tekeminen. Asioita tulisi tehdä itse, eikä pelkästään lukea kirjoista. Muistijälki on paljon vahvempi, kun pääsee itse kokeilemaan, miten palvelut toimivat.
Lukemista ja tekemistä tulisi tehdä niin töissä kuin vapaa-ajalla. Yleensä kannattaa varata kalenterista aikaa opiskeluun. Sama kannattaa aikatauluttaa myös vapaa-ajalle, mikäli se on mahdollista. Tällöin opiskelu tulee tehtyä suuremmalla todennäköisyydellä.
Vuosien saatossa olen suorittanut useita eri sertifiointeja eri aihealueilta: Sun Microsystems, Oracle, AWS ja GCP. Kaikissa näissä ratkaisee oma into ja halu oppia. Edellisistä sertifioinneista saa aina pohjaa seuraavalle, joten lukeminen helpottuu ajan myötä. Esimerkiksi jos olet suorittanut AWS:n arkkitehti -sertifiointeja, voi niistä ponnistaa GCP:n vastaaviin sertifikaatteihin. Teknologiat ovat erilaisia, mutta arkkitehtuurissa ei ole juurikaan eroa, koska pilvinatiivi arkkitehtuuri ei ole pilviriippuvainen.
Tärkein asia minkä olen oppinut: Opiskele säännöllisesti ja asia kerrallaan.
Sertifikaatit ovat hyödyllisiä välindeitä itsensä kehittämiseen. Ne eivät vielä takaa täyttä osaamista, vaan antavat hyvän pohjan ponnistaa ammattilaiseksi. Sertifiointi yhdistettynä arkipäivän tekemiseen on yksi vahvimmista tavoista opiskella moderneja pilvipalveluita josta hyötyvät kaikki – työntekijä, työnantaja ja asiakas – riippumatta osaamistasosta.
Uskomme Codentolla jatkuvaan kehitykseen. Tule kuulemaan lisää #GCPJOURNEY pilviammattilaisten ja sellaisiksi haluavien online-tapahtumassa 28.1.2022 klo 10-11! Rekisteröidy tapahtumaan täältä.
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ä.
Author: Jari Rinta-aho, Codento
Olemme Codentossa vauhdilla laajentaneet palveluitamme datan ja koneoppimisen vaativiin toteutuksiin ja palveluihin. Asiakkaidemme kanssa keskustellessa seuraavat liiketoiminnalliset tavoitteet ja odotukset ovat nousseet usein keskiöön:
Tässä blogikirjoituksessa käyn läpi oppeja tuoreesta asiakascasestamme.
Eräällä suomalaisella B-to-C -toimijalla nousi tänä keväänä esiin hyvin konkreettinen liiketoimintatarve: asiakaspalautedataa tulee valtavat määrät, mutta miten hyödyntää palaute älykkäästi päätöksenteossa oikeiden liiketoimintapäätösten tekemiseksi.
Codenton suositus oli hyödyntää haasteseen sopivia koneoppimisen lähestymistapaa ja Google Cloud valmisominaisuuksia, jotta asiakaspalautteiden luokittelija olisi valmiina toivotusti viikossa.
Tavoitteena oli luokitella lyhyitä asiakaspalautteita automaattisesti kolmeen koriin: Positiivisiin, neutraaleihin ja negatiivisiin. Asiakaspalautteet olivat pääosin lyhyehköjä suomenkielisiä tekstejä. Joukossa oli tosin myös muutamia tekstejä kirjoitettuna ruotsiksi ja englanniksi. Luokittelijan piti siis pystyä tunnistamaan myös lähdetekstin kieli automaattisesti.
Projekti oli yhtäaikaisesti aikataulultaan tiukka ja kunnianhimoltaan kova. Projektissa ei ollut yhtään aikaa hukattavaksi, vaan tulokset oli käytännössä saatava ensimmäisellä yrittämällä. Codento päättikin hyödyntää mahdollisimman paljon valmiita kognitiivisia palveluita.
Luokittelija päätettiin toteuttaa yhdistämällä kaksi Google Cloud Platformista löytyvää valmista työkalua: Translate API ja Natural Language API. Tarkoituksena oli kääntää tekstit koneellisesti englanniksi ja määrittää niiden sävy. Koska Translate API kykenee tunnistamaan lähdekielen automaattisesti noin sadan eri kielen joukosta, työkalu ainakin paperilla täytti asetetut vaatimukset.
Tulosten validoinnissa hyödynnettiin satunnaisotantaa ja käsityötä. Käytössä olleesta aineistosta valittiin satunnaisotannalla 150 tekstiä luokittelijan validointia varten. Ensin nämä tekstit lajiteltiin käsityönä kolmeen luokkaan: positiivisiin, neutraaleihin ja negatiivisiin. Tämän jälkeen sama luokittelu tehtiin kehittämällämme työkalulla. Lopulta työkalun ja käsityön tuloksia verrattiin toisiinsa.
Työkalu ja analysoija olivat samaa mieltä noin 80 %:ssa palautteista. Yhtään päinvastaista näkemystä ei ollut. Validoinnin tulokset koottiin yhteen confusion -matriisiksi
Kuvan confusion -matriisin lävistäjällä olevat luvut 18, 30 ja 75 kuvaavat palautteita, joissa validoija ja työkalu olivat samaa mieltä palautteen sävystä. Yhteensä 11 palautetta oli sellaisia, joissa validoija piti sävyä positiivisena, mutta työkalu neutraalina.
Merkittävin tekijä, joka selittää työkalun tekemää erilaista tulkintaa on asiakaspalautteen sanamuotojen kulttuurisidonnaisuus, ja kun suomalainen sanoo “Ei valittamista”, hän kehuu.
Yhdysvaltalaisen suusta kuultuna tämä on neutraali palaute. Tämä kulttuuriero riittää yksin selittämään, miksi suurin yksittäinen virheryhmä oli “validoijan mielestä positiivinen, työkalun mielestä neutraali.” Muutoin virhe selittyy vaikeudella tehdä eroja rajatapauksista. On mahdotonta sanoa yksiselitteisesti, milloin lievästi positiivinen palaute muuttuu neutraaliksi ja päin vastoin.
Datan perusteella validoitu lähestymistapa soveltui hyvin haasteen ratkaisemiseksi ja tästä on erinomaiset lähtökohdat jatkossa ymmärtää palautteen luonne, kehittää jatkomalleja tarkempaan analyysiin, nopeuttaa analyysia ja vähentää manuaalista työtä. Ratkaisua voi soveltaa myös hyvin moneen vastaavaan tilanteeseen ja tarpeeseen muissa prosesseissa tai toimialoilla.
Artikkelin kirjoittaja on Jari Rinta-aho, Senior Data Scientist & Consultant, Codento. Jari on koneoppimisesta ja matematiikasta kiinnostunut konsultti ja fyysikko, jolla on laaja kokemus koneoppimisen hyödyntämisestä mm. ydin- ja lääketeknologioiden parissa. Hän on myös opettanut yliopistossa fysiikkaa sekä johtanut kansainvälisiä tutkimusprojekteja.
Codento on innovatiivinen konsulttiyritys, jonka sovelluskehityksen ja tekoälyn ammattilaisilla on jatkuva palo kehittyä. Me teemme työtä asiakkaidemme kilpailuedun parantamiseksi, tarjoten Google Cloud -palveluihin pohjautuvia sovelluskehityksen, sovellusmodernisoinnin sekä tekoälyn ratkaisuja heidän käyttöönsä.
