#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ää.

#GOOGLE­CLOUD­JOURNEY: Cloud Digital Leader -sertifikaatti – miksi ja miten?

#GOOGLECLOUDJOURNEY: Cloud Digital Leader -sertifikaatti – miksi ja miten?

Kirjoittaja: Anthony Gyursanszky, toimitusjohtaja, Codento

 

Esipuhe

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:

  • Pilviteknologian perusteet ja mahdollisuudet organisaatioille
  • Erilaiset datahaasteet ja -mahdollisuudet sekä miten pilvi ja Google Cloud voivat olla avuksi, huomioiden myös koneoppiminen ja tekoäly
  • Erilaisia ​​polkuja  organisaatioiden pilvisiirtymään ja miten Google Cloudia voidaan hyödyntää sovellusten modernisoinnissa
  • Kuinka suunnitella, ajaa ja optimoida pilvi pääasiassa liiketoiminnan ja vaatimustenmukaisuuden näkökulmasta

Mikäli nämä aiheet ovat sinulle tärkeitä ja haluat ottaa vastaan ​​sertifiointihaasteen, Cloud Digital Leader on sinua varten.

Kuinka valmistautua testiin?

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.

 

Kuinka rekisteröityä kokeeseen?

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:

  • Työskentelyhuone, jossa voit työskennellä yksityisesti
  • Pöytä oltava kohtuu tyhjä
  • Henkilöllisyystodistus saatavilla
  • Sinun on asennettava suojattu selain ja lähetettävä valokuvasi etukäteen (vähintään 24 tuntia)
  • Muut ohjeet kuten ilmoittautumisprosessissa

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.

 

Oliko se sen arvoista?

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:

  • Tarjoaa rooliriippumattomia entry-sertifikaatteja, myös yleisille rooleille, kuten muissa ekosysteemeissä (Azure / AWS Fundamentals)
  • Tuoda Google Cloud -ekosysteemi paremmin yhteen oikeanlaisen yhteisen kielen ja näkemyksen kautta, mukaan lukien kumppanit, kehittäjät, Googlen työntekijät ja asiakkaiden päätöksentekijät
  • Kohdistaa liike-elämän ja tekniset ihmiset työskentelemään paremmin yhdessä puhumaan samaa kieltä ja ymmärtämään korkean tason käsitteitä samalla tavalla
  • Tarjota myynnin peruskoulutusta laajemmalle yleisölle, jotta myyjät voivat tuntea itsensä ”sertifioiduiksi”

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:

#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.

#BIZML: Koneoppimisen pilotointia ylinopeudella – Google Cloud ja AutoML hyötykäytössä

Koneoppimisen pilotointia ylinopeudella – Google Cloud ja AutoML hyötykäytössä

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ä?

 

Koneoppiminen ja automaatio

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.

 

Google Cloud ja AutoML saivat käytännön haasteen

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.

 

Mallin rakentaminen käytännössä

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.

 

Lopputulos yllätti positiivisesti

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.

 

Jatkohyödyntäminen kannattaa

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:

  1. Google Cloud AutoML, https://cloud.google.com/automl 
  2. Kaggle, House Prices – Advanced Regression Techniques, https://www.kaggle.com/competitions/house-prices-advanced-regression-techniques/ 

 

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:

#GOOGLE­CLOUD­JOURNEY: Sertifikaatit luovat tavoitteellisuutta

Sertifikaatit luovat tavoitteellisuutta

Author: Jari Timonen, Codento Oy

Mistä IT-alan sertifikaateista on kyse?

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.

Tavoitteellisuus keskiössä

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ää.

Aikataulu sitoutumisen pohjana

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.

Lukemista sekä töissä että vapaa-ajalla

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ä.

Opiskelu säännöllisesti kannattaa

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.

Loppusanat: sertifikaatit ja käytännön kokemukset takaavat yhdessä menestyksen

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ä.

#BIZML: Liiketoimintalähtöinen koneoppija Google Cloudin avulla

Liiketoimintalähtöinen koneoppija Google Cloudin avulla: monikielinen asiakaspalauteluokittelija viikossa

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:

  • Dataan piilotettujen säännönmukaisuuksien paljastaminen
  • Analysoinnin automatisointi
  • Inhimillisten virheiden minimointi
  • Uudet liiketoimintamallit ja -mahdollisuudet
  • Kilpailukyvyn parantaminen ja turvaaminen
  • Moniulotteisen ja monipuolisen data-aineiston jalostaminen

Tässä blogikirjoituksessa käyn läpi oppeja tuoreesta asiakascasestamme.

Asiakaspalautteen syväymmärtämisestä kilpailuetua

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.

Codento suositteli koneoppimisen hyödyntämistä

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.

Voiko tuloksia oikeasti odottaa viikossa?

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.

Google Cloud avainasemassa

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.

Oliko tuloksista hyötyä?

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.

Mitä saavutettiin?

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.

Ratkaisun hyödyntäminen liiketoiminnassa

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.