14.11.2019 / Antti Lyytikäinen

Noniin! Olet lukenut edelliset blogikirjoitukseni ja tullut siihen tulokseen, että tietovarastosi haisee kellarilta ja on ehkä aika tehdä jotain.

Mikäli olet SAP-asiakas, sinua varmastikin askarruttaa mihin SAP:n tietovarastotarjooma on menossa ja mitkä olisivat aikaa kestäviä valintoja esimerkiksi kolmen vuoden aikajänteellä. Suunta vaikuttaa hyvin selvältä – SAP keskittyy isoin satsauksin pilvitarjoomansa kehittämiseen.

Pilviratkaisut tuovatkin niitä tuttuja hyötyjä: nopeutta, joustavampaa hinnoittelua, yksinkertaisuutta ja skaalautuvuutta. Uusimpaan tietovarastotuotteeseen SAP Data Warehouse Cloudiin on luvattu juuri tätä ja ajatuksena tämä tietenkin kutkuttaa, varsinkin kun perinteisesti on-premise-pokerin hinta on ollut jotain aivan muuta kuin nyt luvattu käytettyyn tallennustilaan ja prosessoriaikaan perustuva kuukausihinnoittelu.

Tarkempia hintatietoja varmaan saadaan lähiaikoina, niitä odotellessa voi tutustua SAP Data Warehouse Cloudin ilmaiseen kokeilujaksoon.

Onko tuote sitten valmis itsenäisesti korvaamaan esimerkiksi ikääntyvän SAP Business Warehouse 7.x :n vai tulisiko harkita esimerkiksi SAP BW/4HANA-projektia?

Otin osaa SAP Data Warehouse Cloudin beta-ohjelmaan ja vaikka osa toiminnallisuuksista ei ollut beta-vaiheessa kokeiltavissa, uskoisin että yksinkertaisempiin tarpeisiin pilviratkaisu soveltunee varsin nopeasti. Lisää kokemuksia uudesta tuotteesta sain SAP TechEdissä ja varsinkin mallinnuksen helppous sekä suoraan tietovarastovälineeseen integroitu  SAP Analytics Cloud yhdessä teki vaikutuksen jopa kaltaiseeni vanhaan kyynikkoon.

Spaces-konseptin myötä tietomallinnus on toteutettu siten, että mennään aika paljon lähemmäs visiota itsepalvelu-BI:stä, jossa myös loppukäyttäjät pystyvät yhdistelemään tietoja joustavasti. SAP HANA Cloud -alustalla toimiva SAP Data Warehouse Cloud tuo uutta myös persistenssiin: tietoa voidaan säilöä usean tehoisella ja hintaisella medialla aina muistista data laken kautta hadoopiin asti ja lisäksi ratkaisuissa voidaan käyttää myös virtualisointia, jossa tiedot luetaan lähteestä säilömättä niitä erikseen tietovarastoon. Kaiken kaikkiaan olen pitänyt näkemästäni tähän mennessä.

Tuote on kuitenkin uusi ja ominaisuuksiltaan vielä rajattu ja varmasti juuri tästä syystä SAP tarjoaa lähitulevaisuuteen hybridimallia on-premise-sovellusten ja pilvimaailman välillä. Siirtymävaihe on varmaan arkitodellisuudessakin juuri tätä, eli nykyratkaisua kehitetään ja ylläpidetään ja pilviratkaisua kokeillaan uusiin tarpeisiin ja laajennetaan tarvittaessa. Toisaalta kilpailijoiden ratkaisutkaan eivät ole 100% verrattavissa esimerkiksi ominaisuuksilla kyllästettyyn BW:hen. Yhdellä hyppäyksellä pilvitietovarastoon ei siis ehkä vielä mennä, mutta ajateltavaa riittää, mikäli vanhan uusiminen on kovinkin ajankohtaista.

SAP Data Warehouse Cloudin kehitystahti on uskottavan ripeä – uusia iteraatioita uusine ominaisuuksineen julkaistaan muutaman viikon välein. Samalla vauhdikkaalla metodilla kehitetty SAP Analytics Cloud on melko lyhyessä ajassa kasvanut hyvinkin uskottavaksi tuotteeksi raportoinnin, analyyttisten sovellusten,  visualisoinnin ja suunnittelutoimintojen saralla.  Tämän vahvistaa esim. BARC BI Survey, joka on hyvin mielenkiintoista luettavaa.

Analytics Cloudin ottaminen integroiduksi osaksi lähes jokaisen SAP-pilvituotteen (S/4HANA Cloud, Successfactors, Cloud for Customer jne.) operatiivista analytiikkaa osoittaa myös SAP:n omaa uskoa tuotteeseen. Tästä kertoo myös se, että SAC on jatkossa SAP:n analytiikkatuotestrategian kärjessä, ks. tämä tuore  SAP Analytics & Business Intelligence statement of direction.

SAP Analytics Cloud onkin melko luonteva paikka aloittaa analytiikan pilvisiirtymä huokean hintansa ja tuotteen maturiteetin ansiosta. Seuraava askel voi olla sitten sen tietovaraston seuraaminen perässä.

Blogisarjan muissa osissa:

 


8.11.2019 / Mika Aho

Aiemmissa blogeissa on vilahdellut värikäs nelikenttä, jonka hilpeitä värejä peittää läpinäkyvä kolmio. Mitä nelikentän eri laatikot sitten tarkemmin ottaen tarkoittavat? Tässäpä kustakin lyhyt kuvaus ja muutamia asiakasesimerkkejä.

 

Tehokkuuden ja päätöksenteon parantaminen

Perimmäisenä kysymyksenä on miten organisaatio toimii sujuvammin ja tehokkaammin datan avulla?

Tehokkuutta haetaan esimerkiksi:

  • automatisoimalla tai tukemalla päätöksentekoa—toteutimme VTV:lle tekoälybuustatun työkalun valtionhallinnon hankinnoissa tapahtuvien mahdollisten riskitapausten tunnistamiseksi. Työkalu ei korvaa tarkastajia, mutta auttaa heitä potentiaalisten riskitapausten löytämisessä
  • optimoimalla päätöksiä—eräälle toiselle valtion virastolle toteutettiin koneoppimismalli hakemusten automaattiseen luokitteluun, joka kykeni 90 % tarkkuudella luokittelemaan hakemukset oikein useiden eri luokkien kesken ja teki vuoden työt noin sekunnissa
  • ymmärtämällä paremmin asiakkaita tai markkinoita—rakensimme tukkukaupalle mallin vihannesten maailmanmarkkinahintojen vaihtelun ennakointiin, jotta voitiin optimoida ostoja ennen hintojen nousua
  • vähentämällä manuaalista työtä (tai kustannuksia) automatisoimalla toistettavia prosesseja—korvasimme mediatalon manuaalisen julkaisulevikin jatkuvan seurannan ja ennustamisen koneoppimiseen perustuvalla ratkaisulla, joka ennustaa levikkiä kuukausia eteenpäin

Ja aina tähän ei tarvita edes mitään edistynyttä analytiikkaa (tekoälyä). Ihan dataan tutustumalla ja sitä analysoimalla voidaan saavuttaa hyviä tuloksia.

Elävä esimerkki Suomen huipulta: Eräässä yrityksessä tehtiin konfiguroitavia tuotteita oletuksella, että turvallisuusstandardin mukaisesti kaikkiin heidän tuotteisiinsa pitäisi lisätä uusi osa. Kymmenien tuhansien eurojen tuotteessa yksittäinen osa on sinällään halpa, asennettuna itse asiassa alle 200 euroa.

R&D:n toimesta pelkästään dataa analysoimalla tunnistettiin yli viisinumeroinen määrä tapauksia, joihin tätä osaa ei tarvitse vuosittain asentaa. Tämä johti usean miljoonan euron vuotuisiin säästöihin.

 

Operatiivinen erinomaisuus

Perimmäisenä kysymyksenä on miten maksimoida tehokkuus ja kannattavuus dataa hyödyntäen?

Operatiivista erinomaisuutta haetaan esimerkiksi

  • niputtamalla yhteen pienempiä kokonaisuuksia, jotka yhdessä muodostavat jotain suurempaa tai kunnianhimoisempaa—mitäpä jos myydessäsi tori.fi:ssä krääsää, ottaisitkin vain kuvan tuotteesta ja palvelu tunnistaisi, mitä olet myymässä, luokittelisi sen oikein, tekisi kuvauksen ja hinnoittelisi tuotteen puolestasi ja löytäisi vieläpä potentiaalisen ostajan?
  • optimoimalla kokonaisia liiketoimintaprosesseja (esim. tilauksesta kassaan)—kuten edelläkin, maksimoidaan hyödyt käyttämällä oikeita (AI-)ratkaisuja oikeissa paikoissa. Tilauksia tulee monesta kanavasta ja AI voisi käsitellä sähköpostin kautta tulevat tilaukset (ja antaa hankalat ihmisten käsiteltäviksi), myyntisaamisten puolella ennustaa asiakkaiden maksuvaikeuksia, laskutusvaiheessa huomioimalla maakohtaiset säännökset ja erot jne.
  • ennustamalla myyntiä tai kysyntää—tämä on aika klassinen käyttökohde. Yhtenä mielenkiintoisena casena ennakoimme aikoinaan vanhusten pitkäaikaishoitotarvetta perustuen sote-toimijan anonymisoituun dataan. Tavoitteena oli ennustaa hoitotarpeen kokonaismäärää, jota pystyy käyttämään muun muassa sote-palveluverkon kapasiteetin ennakointiin. Ennustetarkkuus oli todella hyvä ja ratkaisu on nykyään osa FCG Prodacapo Finlandin Ecomed-alustaa
  • optimoimalla tarjousten läpimenoa—toteutimme KONEelle ratkaisun, joka auttaa myyjiä etsimään todennäköisesti optimaalisimman hinnan (tai oikeammin hintaluokan) kullekin tarjoukselle

Talviliukkaiden vaaniessa nurkan takana on YIT:lle pari vuotta sitten tekemämme Kelikoneäly oivallinen esimerkki operatiivisesta erinomaisuudesta. Teiden oikea-aikainen auraus ja suolaus ovat erittäin tärkeitä tekijöitä, sillä liian aikaiset lähdöt maksavat paljon (pitää lähteä toisenkin kerran) ja liian myöhäiset lähdöt vaikuttavat turvallisuuteen ja tuovat korvausvastuut.

Kelikoneälyssä ennustetaan koneoppimisen keinoin kelitilanteen muutoksia ja liukkautta muutamaa tuntia eteenpäin. Kun tiesää on ennakoitavissa, on myös helpompi tehostaa suolan käyttöä, varata oikea määrä kalustoa teille ja toimia kustannustehokkaasti urakan, tilaajan ja myös tienkäyttäjän parhaaksi. Toisin sanoen maksimoida tehokkuus ja kannattavuus.

 

Digitaalinen asiakaskokemus

Perimmäisenä kysymyksenä on miten käyttää dataa asiakaskokemuksen parantamiseksi? (tai ehkä sisimmissään auttaa asiakkaita tuntemaan, että heitä palvellaan ja arvostetaan)

Digitaalista asiakaskokemusta haetaan esimerkiksi:

  • itsepalveluasteen nostamisella—chatbotit sekä virtuaaliavustajat antavat nopeat vastaukset yleisimpiiin kysymyksiin ja asiakaspalvelijoiden aika tulee käytettyä hankalampiin tapauksiin. Sitä paitsi botit jaksavat palvella väsymättä 24/7 ja myös osata ohjata asiakasta kohti ostopäätöstä
  • parantamalla personointia—Netflix ja Spotify ovat tästä huikeita esimerkkejä, mutta miksei myös verkkosivusi ja sähköpostimarkkinointisi personointi asiakkaan näköiseksi ja tarpeiden mukaiseksi. Hyvin toteutettuna on molempien etu, että asiakas tunnistetaan aina palveluita käyttäessään—parhaimmillaan asiakkaalle tulee fiilis, että tämähän on räätälöity ihan minua varten
  • vähentämällä kitkaa—tutkimalla asiakaspolun eri vaiheissa syntyvää dataa voi löytyä paikkoja, jossa asiakaskokemus (hetkellisesti) laskee. Nostamalla lentokorkeutta voi löytyä myös samankaltaisesti toimivia asiakassegmenttejä, joita hiertävät samat asiat
  • parantamalla ostokokemusta—mielenkiintoista nähdä, milloin kassalinjat jäävät Suomessakin historiaan ja hyllystä poimittujen tuotteiden kanssa kävellään kaupasta ulos ja ne veloitetaan tililtä automaattisesti. Tai, että jääkaappi täyttää ihan itse itsensä

Eräässä projektissa ennustimme postipaketin toimitusaikaa paikasta A paikkaan B ja pystyimme tarkentamaan ennustetta paketin edetessä reitillä.

Loppuasiakas hyötyy tästä (jos hyötyy, kun on kuitenkin töissä) tietämällä aiempaa tarkemmin, milloin paketti saapuu noudettavaksi. Pakettien toimittaja puolestaan nopeuttaa kiertoa ja saa tyytyväisempiä asiakkaita. Mielenkiintoista tässä oli myös se, että neuroverkkomalli kykeni ennustamaan erittäin hyvin toimitusaikoja myös sellaisille reitti-tuote-kombinaatioille, joita ei ole aikaisemmin ollut datassa.

 

Datan monetisointi ja kasvu

Perimmäisenä kysymyksenä on millaisia uusia (disruptiivisia) palveluita, tuotteita ja liiketoimintamalleja voidaan luoda datan ympärille?

Monetisointia ja kasvua haetaan esimerkiksi:

  • myymällä dataa (luomalla siitä pääomaa)—tämä tulee varmasti monella ensimmäisenä mieleen. Kannattaa miettiä, myykö datansa raakamuodossa, vai kannattaisiko se paketoida ennemminkin (rajapinnan läpi käytettäväksi) palveluksi. Hyviä esimerkkejä ovat Bisnoden yritysdata tai vaikkapa Forecan myymä säädata. Dataa voi myydä myös tuottamalla siitä näkemyksiä, kuten MarketVisionin maksulliset tutkimukset
  • lisäämällä dataa ja analytiikkaa tuotteisiin tai palveluihin—toinen perinteinen tapa kasvattaa organisaation kokonaisarvoa dataa hyödyntämällä on lisätä sitä tuotteisiin ja palveluihin (kuten älykelloihin, termostaatteihin, golf-mailoihin…), luoda sen päälle uusia maksullisia palveluita ja mahdollisuuksien mukaan myydä dataa (anonymisoituna) eteenpäin
  • antamalla jotain ilmaiseksi—Googlen veloituksettomat palvelut ovat tästä loistoesimerkki, jossa saamalla jotain ilmaiseksi luovutamme samalla tietojamme Googlelle sekä mainostajille
  • virtualisoimalla arvoketjuja—perinteisenä esimerkkinä Airbnb, jossa ihmiset voivat tarjota majoituspalveluita. Suomalainen Combi Works on myös mielenkiintoinen peluri tarjoamalla asiakkailleen laajaa teollista tuotantoa hyödyntämällä olemassa olevien vapaiden tehtaiden kapasiteettia. Tämä vaatii myös perinteisemmässä teollisuudessa siirtymistä toimitusketjulogiikasta alustalogiikkaan

Datan myymiseen liittyen olimme mukana toteuttamassa Lääketietokeskukselle Pharmarket-markkinatilastopalvelua, jossa lääkealan yritykset ja muut toimijat voivat analysoida Suomen lääkemarkkinaa valtakunnallisella ja alueellisella tasolla.

Lääketietokeskus myy palveluaan muun muassa lääkkeitä markkinoiville yrityksille, viranomaisille, yhdistyksille, tutkimusyrityksille sekä konsulttipalveluita tarjoaville yrityksille. Dataa hyödynnetään esimerkiksi kilpailijaseurannassa, uusien tuotteiden markkinointimahdollisuuksia analysoitaessa, myyntitavoitteiden seurannassa sekä lääkkeiden hinta- ja myyntianalyyseissä.


15.08.2019 / Mika Aho

”Kuulostaa liian juhlalliselta meille”, totesi eräs pörssiyhtiön johtaja käydessämme aiemmin tänä vuonna esittelemässä aiheeseen liittyvää tarjousta. Lopulta päädyimme nimeämään ehdotuksemme jotakuinkin ”mahdollisuuksia datan hyödyntämiselle liiketoiminnan kehittämisessä” ja fokusoiduimme auttamaan asiakasta keräämään ympäri organisaatiota olemassa olevat ideat ja innovoimaan uusia mahdollisuuksia eri liiketoiminnoissa. Ja paljon muutakin toki.

Digiä, dataa, strategiaa ja transformaatiota

Aihe ei ole mitenkään uusi. Toisinaan olemme puhuneet digitalisaatiosta, digitaalisesta transformaatiosta, digistrategiasta, digiloikasta, dataloikasta, digiagendasta, analytiikkastrategiasta tai vaikkapa tiedolla johtamisen esiselvityksestä. Laajemmissa kokonaisuuksissa yritys- tai kokonaisarkkitehtuurista. Asiassa on paljon erilaisia näkökulmia ja rakkalla lapsella on monta nimeä.

Itse olen päässyt tekemään tusinan verran erilaisia datastrategiaprojekteja asiakaskunnassamme eri toimialoilla muun muassa rahoitus-ja vakuutusalan sekä ravintola- ja hotellibisneksen kautta tukkukauppaan, valmistavaan teollisuuteen, ammattiliiton kiemuroihin ja rasvaiseen huoltobisnekseen. Kahta samanlaista projektia ei ole vielä tullut vastaan, mutta niitä kaikkia yhdistävät tietyt asiat.

Ei ehkä yllättävää, että samanlaisissa vaiheissa ja samalla toimialla olevat yritykset painivat paikoin samanlaisten ongelmien parissa. Myös analytiikan käyttökohteet ovat pääsääntöisesti samoja: kustannuksia syntyy ja tuottoja haetaan samantyyppisistä kohteista. Varastot pitäisi saada kiertämään nopeammin, laitteet huollettua ennakoivasti, asiakaspoistumaa vähennettyä, kysyntää ennustettua, tarjousten läpimenoa optimoitua tai vaikka syötettyä lehmille oikea määrä sapuskaa.

Asiakaskokemuksen parantaminen ja datan monetisointi tuovat kuitenkin hyviä erottumisen sekä kilpailukyvyn parantamisen paikkoja. Näistä lisää myöhemmin.

Uusi blogisarja datastrategiasta

Syksyn aikana avaan blogisarjassa, miten kehittää datastrategiaa omaan organisaatioon ja millaisia asioita kussakin vaiheessa kannattaa ottaa huomioon. Niin ikään availen onnistumisen edellytyksiä ja kokemusten kautta kertyneitä vastoinkäymisiä. Koitan saada myös asiakkaan äänen kuuluviin mahdollisimman paljon.

Blogisarja jakaantuu seuraavasti:

  1. Liiketoiminnan tahtotilan sekä vision ymmärtäminen (ja miten saada johtoryhmä kiinnostumaan datasta)
  2. Business caset datalle – dataan sekä analytiikkaan liittyvien liiketoiminnan kehitysmahdollisuuksien tunnistaminen
  3. Kehittämisen näkökulmien valinta – yksinkertaistaminen on kaunista
  4. Organisaation tietopääoman tunnistaminen – tänään ja tulevaisuudessa
  5. Modernin data-arkkitehtuurin suunnittelu – millaisiin pönttöihin ja rakenteisiin data kannattaa nykypäivänä tallentaa
  6. Gap-analyysin sekä kehityspolun rakentaminen – mitä huomioida ja miten mitata?
  7. Operationalisointi – data ja teknologia on helppoa, mutta ihmisten ja prosessien muuttaminen ei. Lopuksi kerron, miten asiat viedään osaksi arkea

Samantyyppisen ”viitekehyksen” kautta on juoksutettu käytännössä kaikki meidän datastrategiaprojektit, ainoastaan painopiste on ollut kussakin hieman erilainen.

Mitä sitten on datastrategia?

Kuten alussa tuli ilmi, moni termi kattaa saman asian ja puhun jatkossa systemaattisesti datastrategiasta. Mitään uutta ja ihmeellistä asiassa ei ole, mutta syystä tai toisesta se on kovinkin ajankohtainen eri puolilla.

Strategia sanana on sikäli hieman harhaanjohtava, että datastrategia ei suinkaan ole kertaluontoinen harjoitus tietyn päämäärän saavuttamiseksi, vaan sen pitäisi olla ennemminkin jatkuva prosessi tai toimenpidesuunnitelma, jota päivitellään rullaavan budjetin tavoin vaikkapa puolivuosittain. Toimintaympäristö muuttuu jatkuvasti ja riskinä on, että vaivalla tehty arvokas työ happanee (pöytälaatikkoon).

Eräs potentiaalinen asiakas kritisoikin, että hehän ovat jo aika pitkällä näissä asioissa ja datastrategia kuulostaa enemmänkin siltä, että lähdettäisiin aivan alusta liikkeelle. Näin ei tietenkään ole.

Datastrategiassa ei myöskään varsinaisesti tehdä liiketoimintastrategiaa, vaikka välillä sillekin tielle eksytään. Liiketoiminnan suunta ja tavoitteet tulevat enemmänkin annettuna. Niinkin on kuitenkin käynyt, että datastrategiaprojektin myötä organisaatio on lähtenyt valloittamaan uudenlaista asiakassegmenttiä ja markkinaa.

Eräällä tapaa datastrategian voi käsittää visioksi ja pelisuunnitelmaksi datan hyödyntämiselle liiketoiminnassa.

Samalla se on myös astetta teknisempi suunnitelma, jonka avulla parannetaan tapoja hankkia, hallita ja jakaa sekä hyödyntää dataa tulevien vuosien aikana tunnistettujen liiketoimintatarpeiden mukaisesti. Taustalla hieman huomaamatta rakennetaan organisaation tavoitteita tukevia dataohjautuneita kyvykkyyksiä ja valmennetaan organisaatiota muutokseen murrokseen.

Millaisiin tilanteisiin datastrategian oikein kehittäminen sopii?

Tarpeet ovat usein moninaisia. Alla muutama oikea esimerkki datastrategian kehittämisen tarpeista:

  • Halutaan kartoittaa nyky- ja tavoitetila sekä luoda etenemissuunnitelma
  • Ennakoidaan muutoksia ja valmistaudutaan muutokseen
  • Nostetaan digitalisaatioastetta
  • Harmonisoidaan liiketoimintaprosesseja
  • On pakko (esim. carve-out -tilanne, jossa tulee tunnistaa keskeisimmät tietopääomat ja -järjestelmät)

Tarpeet voivat olla toki tarkempiakin, kuten:

  • Tunnistetaan, mistä (datasta) on eniten hyötyä
  • Ymmärretään, mitä dataa prosessit kuluttavat ja millaista dataa ne tuottavat
  • Ymmärretään, miten data saadaan näkyväksi ja hyötykäyttöön oikeilla työkaluilla sekä teknologioilla
  • Tunnistetaan painotuksia, millä alueilla halutaan liikkua ja mihin panostaa
  • Saadaan tukea ja perusteluita valinnoille sekä business caseille
  • Tuetaan portolion hallintaa aina bisnesportfolioon saakka
  • Luodaan järkevät investointisuunnitelmat, joilla maksimoidaan ROI (datasta)

Yleistä kaikelle kuitenkin on, että datastrategiaa tyypillisesti tarvitaan liiketoiminnan käännekohdissa.

Datastrategia projektina

Aika monessa tekemisessä pätee Sarasvuon sanonta ”ei niin paljon kuin mahdollista, vaan niin vähän kuin on tarpeen”. Datastrategiaprojektitkaan eivät tee tähän poikkeusta.

Yleisesti olen huomannut, että asiakkaat hakevat nykypäivänä käytännönläheistä ja ennen kaikkea liiketoimintalähtöistä lähestymistapaa monimutkaisten sekä raskaiden viitekehysten sijaan, joita näkee erityisesti paljon yritysarkkitehtuurin (EA) kehittämisessä.

Ideaalisesti datastrategiaprojekti:

  1. Lähtee liiketoiminnan tarpeista ja tukee liiketoiminnan tavoitteita
  2. Osallistuttaa liiketoiminnan ja ylintä johtoa (tämä on avainasiassa projektin onnistumiselle)
  3. On käytännönläheinen ja itseään selittävä
  4. On helposti kommunikoitava organisaation sisällä
  5. On riittävän joustava mukautumaan muuttuviin liiketoiminnan ja teknologian tarpeisiin

Datastrategiaharjoitukseen on hyvä varata noin kolme kalenterikuukautta ja osallistuttaa muutamia kymmeniä henkilöitä organisaation sisältä. Tällöin saadaan suuntaviivat riittävän tarkalla tasolla selville, jonka jälkeen alkaa sitten raaka työ jalkauttamisen muodossa.

Seuraavassa blogissa kirjoitan tarkemmin liiketoiminnan tahtotilan ja vision ymmärtämisestä (ja miten saada johtoryhmä innostumaan datasta). Odotellessa voit miettiä, miten datastrategiaprojektia kannattaisi rajata – vai pitäisikö ollenkaan?




6.08.2019 / Mika Laukkanen

AI projektit ovat monella tapaa vaikeita saada onnistumaan ja viedä tuotantokäyttöön saakka. Erilaisten selvitysten mukaan vain 5% – 10% aloitetuista AI projekteista päätyy tuotantokäyttöön.

BilotGo AI-hackissa toteutimme 2018 neljä projektia, joista kaikki ovat tuotantokäytössä 2019 aikana. Kuluvan vuoden AI-hack päättyi nyt kesäkuussa, joten näistä ratkaisuista ei vielä mikään ole ehtinyt tuotantokäyttöön, mutta aika hyvältä näyttää.

Tarkennuksena mainittakoon, että AI-hackissa siis ratkotaan asiakkaiden oikeita business ongelmia tekoälyn avulla. Kisaamassa ovat tähän saakka olleet Reima, Altia, Kone, RaisioAgro (nyk. Lantmännen Feed), Skanska, VTV ja Metsä Wood.

En käy tässä kirjoituksessa tarkemmin kisaa lävitse, mutta kerron kolme tärkeintä asiaa, joiden avulla AI projektien onnistumisprosentti on saatu nostettua korkeaksi.

Business ongelman valinta

Rohkenen väittää, että oikeanlaisen business ongelman valinta on ylivoimaisesti tärkein asia AI projektin onnistumisen kannalta. Mikään teknologia tai huipputason osaaminen ei pelasta, jos business ongelma on löperösti valittu. Sun Tzukin painotti tiedustelun ja oikeiden taisteluiden valintaa. Tässä on vähän samasta kyse.

Projektien alkuvaiheessa me pidetään strukturoitu AI-Työpaja, joissa käydään asiakkaan valitsemat business ongelmat lävitse kriittisen tarkastelun kautta. Esimerkiksi tuosta AI-hackista on jäänyt pois kiinnostuneita asiakkaita, koska kriteerit täyttävää business ongelmaa ei ole kyetty identifioimaan AI-Työpajassa.

Datan verifiointi alkuvaiheessa

Tekoäly tarvitsee dataa riittävästi ja riittävän laadukkaana. Ja se mikä on riittävästi, vaihtelee huomattavasti eri ratkaisujen välillä. Alkuvaiheessa tehtävän datan verifioinnin lisäksi on tärkeää ymmärtää, että miten data saadaan käyttöön luotettavasti ja riittävän nopeasti myös tuotantoratkaisussa. Moni AI-POC (proof-of-concept) on tähän kompastanut.

Oikeat ihmiset ja osaaminen

Onnistuneen AI ratkaisun luomiseksi ihmisiä tarvitaan yleensä useista eri funktioista ja erilaisilla osaamisilla. Kyseessä ei siis ole nerokkaan Data Scientistin yksilösuoritus. Esimerkiksi tänä vuonna AI-Hackin voittaneessa tiimissä oli osaamista seuraavasti:

  • Osaavat projektipäälliköt (asiakas ja Bilot)
  • Syvää liiketoimintaosaamista (asiakkaan edustajat)
  • Datan mallinnus ja kerääminen (Data Engineer)
  • Koneoppiminen ja tekoäly (Data Scientist)
  • Tulosten visualisointi (Service Designer ja BI expert)

Toiseksi tulleessa joukkueessa kokoonpano oli hieman erilainen, sisältäen mm. verkkokauppaosaamista, koska kyseessä oli verkkokaupan AI ratkaisu.

Kun ratkaisut tuotannollistetaan, niin usein tarvitaan vielä lisää osaamista, jotta tehdyt ratkaisut voidaan integroida osaksi nykyisiä IT ratkaisuja.

BilotGo AI-Hackathon 2019 esittelytilaisuus 12.9.2019

Mikäli haluat tarkemmin kuulla kuluvan vuoden AI-hack projekteista, niin ilmoittaudu mukaan oheisesta linkistä.

https://www.bilot.fi/event/bilotgo-ai-2019/

Aluksi Jaakko Lempinen Yleltä ja Kimmo Pentikäinen Elisalta kertovat miten tekoälyä heillä hyödynnetään. Tämän jälkeen lavan valtaavat VTV:n (Valtiontalouden tarkastusvirasto), Skanskan ja Metsä Woodin AI hackathon esitykset.

Konkreettista ja hyödyllistä tekoälyasiaa siis tiedossa. Unohtamatta aamiaista ja ilmaista lounasta.

Varaa paikkasi ja nähdään 12.9.2019!

Alla voittajatiimin tuuletukset


13.06.2019 / Mika Laukkanen

Otsikon kysymys tulee eteen useimmille Data Scientisteille jossakin vaiheessa. Useammankin kerran olen ollut tilanteessa, jossa tekoälystä tai koneoppimisesta innostunut asiakas haluaisi ottaa helpon startin asiaan, ja esittää ko. kysymyksen.

En varsinaisesti ihmettele, että tällaisia keskusteluja syntyy, koska aiheen markkinoinnissa on useammin pää pilvessä kuin jalat maassa. Ei siis moitita kysyjiä.

Mutta eipä noista keskusteluista ole haittaakaan ollut, sillä ne ovat avanneet hyvän tilaisuuden jutella aiheesta tarkemmin.

Data on hyvä renki

Miksi ei sitten kannata edetä data edellä tekoälyprojekteihin? Tässä kolme pointtia.

Ensimmäinen pointti on, että tekoälyratkaisujen ”äly” perustuu (nykyisellään) koneoppimismenetelmiin, jotka eivät ymmärrä asioiden välisiä konteksteja. Siinä mielessä ne eivät ole laskimia älykkäämpiä. Kun meillä runsaasti dataa, niin osa muuttujista voi korreloida keskenään, ilman todellista syy-seurausyhteyttä. Dataa sokeasti louhimalla on hyvä mahdollisuus löytää ”jotakin”, joka ei siis ole oikeasti mitään.

Tässä pari kuvaa aihepiiristä.

 

Toinen pointti on, että vaikka datasta löydettäisiin aitoja yhteyksiä asioiden välillä (ei pelkkää korrelaatiota), niin niillä ei välttämättä ole juurikaan liiketoiminta-arvoa. Esimerkiksi tehdään ennusteita asioista, joita ei kukaan tarvitse tai niitä ei voi käyttää. Kerran keksimme eräässä projektissa ennustaa puuttuvia CRM tietoja asiakkaan ostojen perusteella. Malli toimi hienosti, mutta asiakas ei tarvinnut päivitettyjä tietoja. Samoin kävi myös päivystyskäyntiennusteille ja eräälle tilauskannan realisoitumisennusteelle. Ei tarvetta.

Kolmas pointti on, että datan sokeaa tutkailua voi pitää huonona ajankäyttönä. Paljon dataa, paljon tutkimista. Tutkailun tuloksena sitä lopulta keksii jonkin kysymyksen, esim. ennustettavan kohteen. Tämä jälkeen valmistelee datat, tekee mallit ja tulkitsee tulokset. Jos tulokset olivat huonoja, niin sitten toisen kysymyksen kimppuun. Jos ne taas olivat hyviä, niin silti pointin 2 riski voi realisoitua. Tämä ehkä sopii kesätyöksi opiskelijalle, jolle työnantaja ei keksinyt parempaakaan tekemistä.

Mahdollinen poikkeus

Data edellä eteneminen voi ainakin yhdessä tilanteessa olla perusteltavissa. Nimittäin silloin, kun Data Scientist on sen alueen asiantuntija, jonka dataa hänen tulisi tutkailla.

Esimerkiksi osakemarkkinoihin perehtynyt Data Scientist ymmärtää heti ko. alueen datat ja termit (esim. volatiliteetti, pe-luku, beta tai sharpen luku). Ja millaisia asioita näistä dataseteistä on yleensä järkevää etsiä.

Vastaavasti markkinointiin erikoistunut Data Scientist pystynee porautumaan erilaisiin markkinoinnin datasetteihin, ja tekemään niistä tuloksellistakin louhintaa.

Mutta näissä tapauksissa on hyvä huomioida, että Data Scientistin asiantuntijuus ko. alueella on jo lähtökohtaisesti rajannut tutkittavia vaihtoehtoja eikä se ole vain sokeaa hapuilua.

Kokonaisuutena tällaista louhintaa voi pitää innovatiivisena prosessina, jossa pyritään löytämään uusia lähestymiskulmia ja ideoita. Ei niinkään tiettyyn tulokseen pääsemisenä joissakin budjetti- ja aikatauluraameissa.

Minkä asian haluat ratkaista?

Reaalimaailmassa nuo budjetti- ja aikatauluraamit on kuitenkin huomioitava. Uskoisin että seuraavan muistilistan avulla on helpompaa päästä hyödyllisiin lopputuloksiin kuin vain dataa tutkailemalla ja parasta toivoen.

  • Identifioi minkä ongelman haluat ratkaista tekoälyn avulla. Mitä selvempi ongelma, niin sen parempi. Esimerkiksi, myyntiennuste tuotteille x, y ja z kaksi kuukautta eteenpäin. Tai onko tuotantolinjalla kulkeva tuote kuvan perusteella a) virheellinen, b) virheetön.
  • Mieti jos tekoäly jo toimisi, niin mistä sen taloudellinen hyöty syntyy (ROI)? Vähentävätkö uudet myyntiennusteet esim. hävikkiä? Tai paljonko rahaa säästyy, kun virheellisten tuotteiden palautukset puolittuvat?
  • Ennen projektin aloittamista varmista myös, että teillä on dataa, joka vastaa identifioituun ongelmaan ja sitä on saatavilla alkukokeilujen jälkeen myös tuotantokäytössä.
  • Hanki oikeat ihmiset mukaan eri vaiheisiin (kehittäminen, tuotantokäyttö)

Sinällään tässä postauksessa ei varsinaisesti ollut uusia asioita. Jo 1990-luvulla IBM:n kehittämä CRISP-DM kehikko aloitti Business kysymyksestä. Ja se pitää edelleen pintansa.


27.05.2019 / Mika Laukkanen

Heti aluksi on mainittava, että tämä blogi on kohdistettu pääasiassa henkilöille, joilla on liittymäpintaa Business Intelligence ratkaisuihin ja nyt niiden parantaminen tekoälyn avulla on alkanut kiinnostaa.


Tekoälyyn liittyvissä esityksissä käytetään usein seuravaanlaista esitystapaa, kun halutaan kuvata mihin tekoäly asemoituu datan hyödyntämisessä.

 

Kuvan alkupää lähtee perusraportoinnista (mitä tapahtui) ja etenee kohti edistyneempää analytiikkaa (ennustamista) – samalla kun vaikeusaste ja ratkaisun arvo kasvaa. Loppupäässä on luonnollisesti kyse nykytermein tekoälystä tai AI:sta.

Pitäisikö kuvaa tulkita niin, että tekoäly on kehittyneempää Business Intelligenceä? 

Yllättävän usein olen törmännyt eri yrityksissä ajatteluun, jossa tekoälyn kehittäminen on sidottu Business Intelligence järjestelmien kehittämiseen. Ajatuksena se, että kun kerätään dataa ja tehdään raportteja, niin sen jälkeen ollaan kypsiä hyödyntämään koneoppimista (tekoälyä) samassa aihepiirissä.

Eli tekoälyprojektien aloittamista saatetaan (turhaan) viivytellä, jos “perusraportointi ei ole kunnossa”.

Kynttilöistä ei kehittynyt hehkulamppuja

Jos katsotaan reaalimaailman tekoälysovelluksia, niin vain melko harvassa niistä on havaittavissa em. kehityskulku raportoinnista tekoälyyn. Seuraavissa tapauksissa ko. esitystapa ei oikein edes toimi. Eikä varmaan ole tarkoituskaan.

  • Kuvantunnistus ja konenäkö
  • Tekstianalytiikka ja luonnollisen kielen tunnistus
  • Ennakoiva huolto reaaliaikaisella IoT datalla
  • Anomalioiden löytäminen Big Datasta
  • Musiikin tai kuvien tuottaminen tekoälyn avulla

Eli tekoälyratkaisuja syntyy paljon alueille, joissa perinteisellä Business Intelligencellä ei ole roolia.

Toisaalta, tekoälyratkaisuja voidaan usein kehittää ilman taustalla olevaa BI ratkaisua vaikka se toisikin lisäarvoa tai asioiden välillä näyttäisi olevan luonnollinen jatkumo.

Otetaan esimerkki asiakasanalytiikasta, vaikka asiakaspoistuma. Jos BI:n ja AI:n sitoo toisiinsa, niin on luonnollista rakentaa ensiksi BI-järjestelmä, jossa asiakastiedot ovat tietovarastossa, josta tehdään nippu raportointia, esim. “kuinka monta % asiakkaista poistuu vuosittain”.  Ja kun tämä on valmiina, niin hyödynnetään tekoälyä ennustamaan, että ketkä ovat seuraavat kytkimen nostajat.

Näin voi toimia, mutta käytännön elämässä on toimittu myös käänteisesti.

Kuvassa on esitetty erään oikean tekoälyprojektin vaiheet. Siinä aloitettiin keräämällä asiakastietoja monista eri lähteistä, vain ennustamista varten. Kun myöhemmin ennustemallit huomattiin toimiviksi (olivat jo tuotannossa), niin ko. tietoja alettiin tuoda BI-järjestelmään.

Kuulin joskus hauskan vertauksen, jossa todettiin ettei kynttilöistä kehittynyt hehkulamppuja. Siinä oli kyse disruptiivista keksinnöistä, hehkulamppu ei ollut vain parempi kynttilä. Mielestäni sama analogia toimii myös aika hyvin BI:n ja AI:n välillä.

Eri tarkoitus, eri kehityspolut

Business Intelligence -ratkaisut ovat nyt ja jatkossa kivijalka yritysten raportoinnille ja analytiikalle, jota ilman ei tule toimeen. Omenakauppiaan tulee tietää monta omenaa meni kaupaksi eilen, viime viikolla ja joulumyynnissä.

Tekoälyratkaisut eivät auta omenakauppiasta vain ennustamaan omenoiden menekkiä, vaan myös tulkkaamaan kiinalaisten turistien omenatiedustelut ja automatisoimaan kirjanpidon.

BI ja AI ratkaisuilla on yleensä eri tavoitteet, mutta myös itse projektit saattavat erota kuin yö ja päivä toisistaan. Näistä syistä en sitoisi niiden kehittämissuunnitelmia liian tiukasti toisistaan riippuvaiseksi.


21.02.2019 / Mika Laukkanen

Kun aloitin työurani 1990 luvun lopulla, niin tietovarastojen ja raportoinnin toteutus oli nykyistä paljon selkeämpää. Tietolähteet olivat pääasiassa relaatiokantoja tai melko yksinkertaisia tekstitiedostoja.  Eikä raportointikaan ollut kovin monimutkaista, koska silloisilla työvälineillä rajat tulivat nopeasti vastaan. Itsensä tunsi kuninkaaksi, jos sai graafin ja taulukon samalle sivulle.  Datan laatu oli toki samaa puppua kuin se nykyäänkin tuppaa olemaan.  Tuon ajan tyypillinen DW arkkitehtuuri oli seuraava.

Nykyiset arkkitehtuurikuvat ovat yksinkertaisimmillaan vastaavia, mutta yleensä kuitenkin monipuolisempia. Nyt on enemmän erilaisia tietolähteitä, samoin kuin datan tallennus- ja esityspään ratkaisuja.

Miksi sitten tietovarastoja alettiin alunperin rakentaa? Tässä muutamia syitä, jotka löytyivät vuonna 2001 tehdyiltä powerpointeilta.

  • Tietojen yhdistely ja harmonisointi eri tietojärjestelmistä
  • Yksi totuus päätöksentekoon
  • Käyttäjien ad-hoc kyselyt mahdollisia ja tietohallinnolle jää aikaa muuhun työhön
  • Tietovarasto historioi yrityksen datat, saadaan aikasarjoja ja analytiikkaa
  • Ei rasiteta operatiivisia järjestelmiä raportoinnilla

Nämä samat argumentit pätevät varsin hyvin vielä nykyäänkin. Mainittakoon että jossakin vaiheessa oli buumi, jonka mukaan kaikki yrityksen datat pitäisi saada keskitettyyn EDW ratkaisuun. Nyt ajatus tuntuu vähän hassulta, mutta ei tuntunut silloin, koska dataa syntyi suhteellisen pieniä määriä ja lähinnä omissa järjestelmissä.

Tietovarastot tehtiin raportoinnin tarpeisiin

Perinteisesti tietovarastoihin tuotava data on määräytynyt raportointitarpeiden mukaisesti. Esimerkiksi talousraportteja varten on tuotu talousdataa ja HR-raportteja varten HR-dataa. Lisäksi tietysti löytyy kombinaatioita, joissa raporteille on yhdistelty eri alueiden tietoja.

Nyt kun tiedetään, että koneoppimis- ja tekoälyratkaisut tarvitsevat dataa oppiakseen, niin eikös ole loistavaa, että vuosikymmeniä dataa on purkitettu tietovarastoihin?

Vastaus on toisinaan kyllä, mutta usein ei.

Kun dataa on kerätty vain raportointitarpeita ajatellen, niin on sattuman kauppaa, että sopiiko se koneoppimisen hyödyntämiseen. Selvennetään asiaa esimerkillä.

Tietovarastoon XYZ kerätään asiakasdataa, josta on tarkoituksena raportoida asiakaskohtaiset eurot tuotteittain, tuoteryhmittäin, asiakassegmenteittäin ja vaikkapa päivätasolla. Kerätään siis tietovarastoon laskutus-, tuote- ja asiakastiedot.

Tässä vaiheessa paikalle saapuu datatieteilijä, joka haluaisi tehdä asiakaspoistumamallin. Hetken dataa tutkailtuaan hän havaitsee, että tietovarastoon ei ole tuotu asiakkaan sopimukseen liittyviä tietoja. Ne olisivat todennäköisesti keskeinen elementti asiakaspoistumamallissa. Tai ehkä sopimustiedot ovat tietovarastossa, mutta niistä tunnetaan vain viimeisin tilanne – ei koko asiakkaan sopimushistoriaa, joka olisi jälleen olennaista asiakaspoistumamallin kannalta. Dataa siis voi olla, mutta siitä ei silti ole olennaista hyötyä.

Olen ollut mukana kymmenissä koneoppimisharjoituksissa, ja vain harvoissa kaikki tarvittava data on ollut saatavilla ns. perinteisestä tietovarastosta. Tyypillisimmät haasteet ovat olleet:

  • Tarvittavaa dataa ei ole ollenkaan tietovarastossa tai vain osittain
  • Dataa on tietovarastossa, mutta liian lyhyeltä ajalta (historiaa poistettu)
  • Tarvittavan datan historiointi on liian harvaa / epätäydellistä

 

Miten huomioida tekoäly tietovarastojen suunnittelussa?

Koska tietovarastojen suunnitteluun ja tekemiseen joka tapauksessa upotetaan valtavia summia rahaa, niin kannattaisi tehdä muutamia toimenpiteitä, jotka tukisivat ajatusta, että tietovaraston sisältö voisi olla syötteenä tekoälyratkaisuille jatkossa. Esimerkiksi.

  • Samalle datalle on hyvä olla useampi käyttötarkoitus (esim. asiakkaaseen liittyvä perinteinen raportointi, asiakaspoistumamallinnus ja asiakaskohtaiset myyntiennusteet).
  • Raportointitarpeiden lisäksi tarvitaan siis näkemystä, että millaisia tekoälyratkaisuja jatkossa halutaan tehdä. Jos ei ole dataa, niin ei tule ratkaisujakaan.
  • Datan historiointi kattavasti. Tämä vaikuttaa mm. tietovaraston mallinnustapaan. Näyttäisi siltä, että Data Vault ei ole hassumpi vaihtoehto vaikka pelkkään yksinkertaiseen BIDW projektiin se saattaakin olla järeähkö menetelmä.
  • Datan määrällä on merkitystä tekoälylle vaikkei raportoinnissa tarvittaisi kuin 3 viimeistä vuotta. Tietovarastoja ei siis kannata tyhjentää ”turhasta datasta”, vaan mieluummin siirtää vanhaa dataa muuhun ympäristöön. Jos vain vähääkään näkee, että sillä voisi olla käyttöä myöhemmin.
  • Kaikkea tekoälyratkaisuissa käytettävää dataa ei tarvitse tai kannata tuoda välttämättä tietovarastoon. Usein on viisaampaa pitää esim. IoT sensoridatat tai nettisivujen verkkolokit jossakin muussa ratkaisussa.

Näillä muutamalla opilla tietovarastoista tulee jo tekoälykelpoisempia. On kuitenkin hyvä huomata, että datan purkittaminen yhteen paikkaan ei itsessään synnytä tekoälyratkaisuja – siihen tarvitaan selkeät business caset. Data toimii sitten mahdollistajana.


24.01.2019 / Lasse Ruokolainen
Good news: according to Señior Data Scientist, Lasse Ruokolainen, you don’t have to!

 

Monesti olen kouluttaessa kuullut kysymyksen: ”Kumpi on parempi, R vai Python”? Hätäisimmille lukijoille annan saman tien lyhyen, kokemusperäisen vastauksen: ei kumpikaan.

Jos et kuitenkaan tyytynyt tähän vastaukseen, taustoitan alla hieman, miksi olen tätä mieltä.

Historiaa

Olen itse pitkän linjan R-koodaaja. Tutustuin R-kieleen ensimmäisen kerran opintojeni loppuvaiheessa keväällä 2004. Tuolloin komentorivi herätti vielä melkoista hylkimisreaktiota (niin kuin monessa muussakin). Kuitenkin jo tulevana syksynä, kun aloitin siviilipalveluksen Metsäntutkimuslaitoksessa, aloin ymmärtää, että R:n opettelu tulisi olemaan välttämätöntä. Avoimen lähdekoodin ohjelmana uudet innovaatiot tuppaavat ilmestymään R:ään ensimmäisenä, ja laaja käyttäjäkunta tarjoaa korvaamatonta vertaistukea ongelmiin.

Kaksi viikkoa kestäneen intensiivisen treenaamisen jälkeen aloin olla riittävän sujut komentorivin kanssa, jotta kykenin jotenkin soveltamaan R:ää käytännössä. Takana on nyt lähes 15 vuotta lähes päivittäistä aktiivista tekemistä ja itseopiskelua. Tästä huolimatta en voi siltikään voi sanoa hallitsevani R:ää täydellisesti; opin jatkuvasti uutta. Etenkin R-Studion tulo ”markkinoille” on kasvattanut R:n mahdollisuuksia huimasti ja samalla tietysti lisännyt tarvetta omaksua uusia asioita.

Python onkin sitten itselleni paljon tuoreempi tuttavuus. Aloin ottaa tuntumaa ”pyyttoniin” noin vuosi sitten, kun siirryin yliopistosta yrityspuolelle. Käytännön asiakasprojektin kanssa työskentely joudutti oppimista, ja nyt kärmes alkaa totella jo melko kesysti. Toki osaamiseni rajoittuu pitkälti data-analytiikkaan, mikä on vain murto-osa siitä, mihin Python taipuu.

Näistä lähtökohdista voisi luulla, että kallistuisin ilman muuta R:n kannalle. Millä perusteella päädyin kuitenkin tylsään tasapeliin? Myönnän: olisin voinut valita toisinkin, kummankin kielen eduksi. Tämä johtuu siitä, että R ja Python on kehitetty hyvin eri tarkoituksiin. R:n (jonka beta-versio julkaistiin vuonna 2000) kehittivät tilastotieteilijät nimenomaan tilastoanalytiikan tarpeisiin, kun taas Python (ensimmäinen versio käytössä jo 80-luvulla) on yleisohjelmointikieli. Data-analytiikan saralla Pythonia on alettu toden teolla hyödyntää vasta 2010-luvun jälkeen, Pandas- ja Sklearn-kirjastojen myötä. Nykyään tilastomenetelmien kehitys tapahtuu edelleen ensisijaisesti R:ssä, kun taas koneoppimismenetelmiä (esim. neuroverkot ja vahvisteoppiminen) viedään voimakkaasti eteenpäin Pythonissa.

Molempi parempi?

Todenperään olen henkilökohtaisesti sitä mieltä, että on hyödyllistä hallita molemmat kielet, koska ne täydentävät kivasti toisiaan. Tämä ei kuitenkaan ole mitenkään välttämätöntä — kummalla tahansa pärjää mainiosti. Toki, R on kiistatta oikea valinta, jos tarpeena on tehdä monipuolisesti tilastoanalytiikkaa, kun taas Python on mielestäni parempi esimerkiksi datan lukemiseen (pandas-kirjastoa on vaikea päihittää tässä).

Yhdellä kielellä pärjäämistä helpottaa erityisesti se, että R ja Python lähentyvät jatkuvasti toisiaan data-analytiikan saralla. Koska molemmilla kielillä on mittava käyttäjä- ja kehittäjäkunta, on helppo ymmärtää, että molempiin kieliin tuodaan jatkuvasti parhaita ominaisuuksia toisesta kielestä.

Otetaan yksinkertainen esimerkki: datan muokkaukseen on R:ssä lyömätön dplyr-paketti (osa laajempaa tidyverse-kokonaisuutta). Jos esimerkiksi haluan laskea otoskoon moninaisen ryhmittelyn sisällä, on syntaksi yksinkertaisuudessaan:

data %>% 
group_by(grouping1, grouping2) %>% 
summarize(counts = n())

missä %>% on ns. putki-operaattori, jolla erillisiä operaatioita voidaan ketjuttaa. Tämän esimerkin toimenpiteen saisi tietysti myös tehtyä esim. aggregate-funktiolla, mutta dplyr:in hienous piileekin siinä, että operaatioita voidaan ketjuttaa loputtomasti, mikä mahdollistaa hyvin monimutkaiset muokkaukset. Jos on tykästynyt dplyr:iin ja kaipailee samanlaista Pythoniin (pandas toki mahdollistaa lähes vastaavan funktionaalisuuden), tähän on olemassa ratkaisu: dfply-kirjasto, jolla em. esimerkki koodataan näin:

(data >> 
 group_by(X.grouping1, X.grouping2) >> 
 summarize(counts = n()))

Rython, PythoR, …

R-Python integraatio on nykyisin sen verran aktiivista, että voisi luulla tämän olevan ihan päämäärätietoista. Python-puolella yhdentymistä pyrkii edistämään rpy2 -kirjasto, joka tuo käytännössä R:n Pythoniin. Vastaavasti, Pythonin koneoppimisvahvuuksia on tuotu R:n puolelle, esimerkiksi kääntämällä Keras-kirjasto R-kielelle. R:stä on myös mahdollista tehdä kutsuja Pythoniin ja pyytää dataa takaisin rPython-paketin avulla.

Toiminnallisesti vastaavia paketteja löytyy molemmista kielistä. Pythonin suosittua sklearn-kirjastoa taas vastaa hyvin pitkälti caret-R-paketti ja R:n visualisointipaketti ggplot2:a vastaa Pythonissa seaborn-kirjasto. Alustojenvälistä työskentelyä on helpotettu jopa luomalla uusi dataformaatti, jota molemmat kielet tukevat. Formaatin nimi on feather, ja se on käytännössä kieliagnostinen binäärinen tiedostorakenne datataulukoiden säilömiseen. Lukemalla feather-tiedoston R:ään (read_feather-funktiolla) palauttaa data.frame -objektin, kun taas Python (feather.read_dataframe-funktiolla) palauttaa pandas.DataFrame -objektin.

R:n ja Pythonin yhteen naittaminen on tehty jopa niin helpoksi, että molempia voi käyttää rinnan samassa ohjelmassa. Asentamalla reticulate -paketti on R-Studiossa mahdollista ajaa Python-blokkeja (kuten myös esim. bash, SQL ja Stan -blokkeja) R-Notebook-tiedostoissa. Esimerkiksi datan lukeminen Pythonin avulla R-Studiossa onnistuu vaikka näin:

```{python}
import pandas as pd
df = pd.read_csv('data.csv')
```

missä ` ` `{python} ` ` ` rajaa Python-koodi blokin.

Primääristi Pythonille tarkoitetuissa Jupyter Notebook -tiedostoissa taas voi ajaa R-blokkeja (sekä esim. julia, java ja ruby -blokkeja). Varsinkin Jupyter Notebook-maailmaan perehtymistä voi suositella, sillä monilla moderneilla koneoppimis-alustoilla — mm. DataBricks, Azure ML Service ja kotimainen Valohai — operoidaan pitkälti juuri näitä ”muistivihkoja” käyttäen. Jupyter Notebook:issa Star Wars hahmojen keskipituuden laskeminen silmien värin ja sukupuolen suhteen onnistuu R:llä esim. näin:

%load_ext rpy2.ipython
%%R
require(dplyr)
starwars %>% 
   group_by(eye_color,gender) %>% 
   summarize(`mean height` = mean(height)

Loppuun pieni mainos: Jos kiinnostuit aiheesta ja haluaisit tietää lisää, tervetuloa osallistumaan vetämiini R- ja/tai Python -koulutuksiin (tai muihin koulutuksiimme).


28.08.2018 / Mika Laukkanen

Tässä on kollega Ville Niemijärven kirjoitus analytiikan (nykyään tekoäly tai koneoppiminen) hyödyntämisestä vuodelta 2014. Ajattelin hieman päivittää sitä ja laittaa uudelleen jakoon, kun aihe on ajankohtaisempi kuin artikkelin ilmestymisvuonna. Kukapa muuten tietää, että millä termillä näitä ratkaisuja kutsutaan seuraavan neljän vuoden päästä?


Asiakaspoistuma-analyysi (eng. churn) tarkoittaa analytiikan prosessiketjua, jossa selvitetään mitkä asiakkaat ovat vaarassa poistua, millä todennäköisyydellä ja miksi. Poistuma tarkoittaa sitä kun asiakas lopettaa sopimuksen palveluntarjoajan kanssa tai yksinkertaisesti lopettaa asioimisen yrityksessä. Voidaan puhua myös asiakaspidosta (eng. retention). Termi liittyy läheisesti myös asiakkuuden elinkaaren arvon määrittämiseen (customer life-cycle value) ja nykypäivän yhteen muotitermiin; customer journey. Itse näkisin kuitenkin, että kyseessä on enemmänkin yksinkertaisesti paremmasta asiakashallinnasta ja huolenpidosta…

Poistuma-analyysi sopii hyvin sopimusliiketoimintaan, esimerkiksi sähköyhtiöille, puhelin- ja internet operaattoreille, kuntosaliketjuille tai lehtitaloille. Mutta poistuma-analyysiä voidaan tehdä myös vähittäiskaupassa, jos vain asiakas tunnistetaan (kanta-asiakasjärjestelmän avulla). Tällöin pitää vain päättää milloin asiakas on poistunut? Mikä on riittävän pitkä aika, että asiakas ei ole käynyt kaupassa, jotta voidaan päätellä hänen vaihtaneen vakiokauppaansa.

Tässä kirjoituksessa käydään läpi asiakaspoistuma-analyysiä ja miten se tehdään käytännössä. Lähestymme aihetta yleisestä yksityiseen. Lopussa näytämme kädestä pitäen miten homma tehdään alusta loppuun.

Asiakaspoistuma-analyysin tuotto on helppo laskea

Kaikessa analytiikkatyössä tulee laskea mitä saamme analyysistä irti, mikä on investoinnin ROI, paljonko jää viivan alle. Jollei investointi tuota moninkertaisesti enemmän kuin analyysi ja tiedon keräys maksaa, ei sitä kannata tehdä.

Asiakaspoistuman osalta tämä on erittäin helppoa tehdä. Otetaan esimerkki sähkön myynnistä.

Sähköyhtiöllä on 100 000 asiakasta. Keskimääräinen laskutus per asiakas on 1000e/vuosi. Nopea selvitys sähköyhtiön sopimuskannasta kertoo, että keskimäärin vuodessa sopimuksen lopettaa 8% asiakkaista.

Tämä tarkoittaa, että asiakkaita poistuu 8000 kpl/vuosi. Rahassa tämä on siis 8000kpl*1000e=8 miljoonaa euroa. Tuo on se potti, jota lähdemme pienentämään ja sitä kautta tekemään asiakkaallemme lisää rahaa.

Osa näistä 8000:sta poistuu luonnollisen poistuman kautta, osa vaihtaa kaupunkia. Ja sitten on se osa joka vaihtaa palveluntarjoajaa koska yrityksen tuote, palvelu tai hinta ei ole riittävän hyvä. Tai kilpailijalla on parempi. Kutsuttakoon tätä laadulliseksi poistumaksi.

Kun menemme asiakkaalle, teemme aina vastaavan laskelman ja arvioimme asiakkaan kanssa yhdessä, mikä on tuon laadullisen poistuman osuus ja kuinka paljon on realistista saada pienennettyä sitä. Sähköyhtiöiden osalta voimme katsoa julkisesta datasta, esim. THL:ltä, mikä on muuttoliike kunnasta pois päin ja paljonko poistuu jalat edellä. Näin emme joudu arvailemaan vaan meillä on faktaa laskelmien taustalla. Sanottakoon esimerkkinä, että sähköyhtiön tapauksessa 3% on luonnollista/muuttopoistumaa ja loput 5% on laadullista poistumaa. Poistumaa, johon voimme vaikuttaa. Tähän iskemme kyntemme.

Entä jos voimme pudottaa tuota 5% poistumaa vaikka vain yhden prosenttiyksikön? Tämä tarkoittaisi 1000 asiakasta ja miljoonaa euroa vuodessa lisämyyntiä. Jos analyysi maksaa 20 000 euroa, on investoinnin tuotto aika huima. Se on jotain sellaista, jota kannattaisi kaikkien tavoitella.

Mitä dataa poistuma-analyysi tarvitsee?

Ensiksi otamme historiatietoa eli tietoa jo poistuneista ja ei-poistuneista asiakkaista. Toisin sanoen sähköyhtiön tapauksessa luemme sopimustietokantaa ja sähkönkulutustietoja (yhä yleisemmin tietovarastoa tai edistyneimmissä yrityksessä erikseen toteutettua analytiikkakantaa) ja haemme sieltä mahdollisimman pitkän historian, mahdollisimman monelta asiakkaalta. Mitä enemmän sitä parempi. Historia-aineistoon otetaan mukaan asiakkaiden taustatietoja sekä käyttäytymiseen liittyvää tietoa.

Taustatietoja ovat esimerkiksi

  • alue/kaupunki/postinumero
  • demografiatiedot (tulo- ja koulutustaso)
  • sukupuoli
  • ikä
  • asiakkuuden kesto
  • talotyyppi, koko, lämmitysmuoto jne. toimialaspesifistä tietoa

Käyttäytymiseen liittyviä tietoja ovat esimerkiksi:

  • kulutus- ja laskutushistoria (esim. keskimääräinen kulutus per kk)
  • ostetut tuotteet (eli millainen sopimus)
  • reklamaatiota, asiakaspalautteet, yhteydet asiakaspalveluun
  • maksuhäiriöt
  • muut toimialaspesifit tiedot
  • Ja lopuksi se tärkein tieto: onko asiakas poistunut vai ei (K/E)

Monilta yrityksiltä ei löydy kaikkia näitä tietoja, olen nähnyt yrityksiä joilla asiakkaista tiedetään käytännössä vain numero ja osoite. Ei edes nimeä tai sitä onko kyseessä yritys- vai henkilöasiakas. Ennen kuin analytiikkaa päästään hyödyntämään täysillä, on edessä usein systemaattinen tiedon keräämisvaihe ja mahdollisesti muutokset lähdejärjestelmiin/tietovarastoon.

Ennen analyysia emme tiedä mitkä tiedot ovat relevantteja ja vaikuttavat poistumisen takana ja sen selvittäminen onkin koko homman ydin.

Miten poistuma-analyysi tehdään?

Kun tiedot on kasassa, jaamme datan kahteen eri settiin: opetusdataan ja testidataan (esimerkiksi suhteessa 60-40). Mainittakoon että data voitaisiin jakaa myös kolmeen eri settiin: opetus-, testi- ja validointidata. Joka tapauksessa, opetusdatan avulla muodostamme ennustemallin, käyttäen liiketoimintaongelmaan sopivaa analytiikka-algoritmia (esim. gradient boosting, neuroverkko, logistinen regressio, naive-bayes). Parhaan mallin löytäminen vaatii useita iteraatioita.

Työ vaatii analytiikkasoftan. Itse suosimme Pythonia ja R:ää, jotka sitten voivat pyöriä vaikkapa Azuren tai AWS:n pilvessä.

Muodostunutta ennustemallia testataan testidataa vasten. Koska testidata on historiadataa, tiedämme onko asiakas poistunut vai ei. Testin voisi ajatella siten, että peitämme tuon poistuma-tiedon ja kuvittelemme, että kyseessä olisi täysin uutta dataa. Annamme mallin tehdä ennusteen eli kertoa todennäköisyydet poistua kullekin asiakkaalle. Tämän jälkeen tarkastamme tuloksen ja arvioimme mallin tarkkuuden. Näin varmistamme toimiiko malli ja kannattaako sitä hyödyntää uutta dataa vasten vai pitääkö sitä parantaa.

Asiakaspoistuma-analyysin tulokset

Poistuma-analyysi tuottaa nipun tuloksia, esim.:

  1. Kaikki nykyiset asiakkaat listattuna poistumatodennäköisyyden mukaan
  2. Selittävät tekijät poistuman taustalla
  3. Ennustemallin hyvyyden kriteerit (AUC, Confusion matrix..)

asiakaspoistuma_tulos

Ensimmäinen tarkoittaa siis konkreettista listaa, jonka voit heittää myynti-/asiakaspalveluyksikölle tai soittokoneistolla ja käskeä kontaktoimaan heti aluksi akuuteimmat top 100 poistujaa.

Toinen tuotos eli selittävät tekijät antavat tulkinnan ilmiölle. Ne kertovat miksi asiakkaat poistuvat. Nämä tulokset on erittäin arvokasta tietoa niin asiakaspalvelulle, myynnille kuin tuotepäälliköille, liiketoiminnan kehittämiselle ylipäätään.

Analyysissä voi tulla esille, että hinta ei olekaan merkittävä tekijä poistuman taustalla vaan huono asiakaspalvelu tai tietylle asiakassegmentille sopimaton tuotepaletti (esim. sähköyhtiöltä puuttuu ekosähkö valikoimastaan). Riippuen valitusta menetelmästä, tulee eroja miten suoraviivaisesti näitä selittäviä tekijöitä voidaan tulkita. Esimerkiksi syvän neuroverkon (deep learning) tulkinta on huomattavasti monimutkaisempaa kuin logistisen regression antamisen tulosten.

Parhaimmassa tapauksessa analyysin tuotoksista voidaan generoida sääntökoneisto ja sisällyttää se esimerkiksi asiakaspalvelun työpöydälle tai CRM-järjestelmään. Säännöt voivat olla yksinkertaisuudessaan kertoimia ja IF-lauseita ja voidaan toteuttaa esimerkiksi SQL-komentoina. Analytiikan tulokset kirjoitetaankin usein takaisin joko operatiivisiin järjestelmiin tai tietovarastoon.

Kolmas tuotos kertoo, että miten tarkka ja hyvä malli on. Ei mennä tässä siihen matematiikkaan tarkemmin. Kannattaa vaan tietää, että siihen on suhteellisen objektiiviset keinot käytössä.

Analyysistä toimintaan

Analytiikan pitää johtaa toimintaan. Sen pitää tuottaa tulosta. Tämä erottaa sen perinteisemmästä raportoinnista ja business intelligencestä, jossa tuijotetaan enemmänkin raportteja ja taulukoita. Näytti käppyrät mitä tahansa, hommia jatketaan kuten ennenkin. Kunnes ollaan karilla tai kortistossa.

Poistuma-analyysissa toiminta tarkoittaa monta asiaa, esimerkiksi:

  1. kontaktoidaan poistumariskissä olevat asiakkaat
  2. pyritään pitämään heidät tai parhaimmassa tapauksessa tekemään lisämyyntiä
  3. kehitetään asiakaspalvelun laatua
  4. kehitetään tuotteita/palveluita vastaamaan paremmin kysyntää
  5. ennakoidaan liikevaihdon muutos kun tiedetään ennuste tulevasta poistumasta

Miksi yritys ei tee asiakaspoistuma-analyysiä?

Olemme tehneet vuosien varrella valtavan määrän eri analytiikan sovelluksia ja projekteja. Asiakaspoistuma-analyysi on antanut näistä todennäköisesti parhaimmat tulokset, varsinkin jos mitataan euroissa asiakkaiden saamaa hyötyä. Menetelmä on helppo ja suhteellisen nopea toteuttaa, se on helppo ymmärtää ja tulokset ovat käsin kosketeltavat.

Silti yllättävän harva yritys todella hyödyntää sitä. Syyt ovat moninaiset lähtien tietämättömyydestä aina itsepetokseen.

Surullisin on itseriittoisen sinnikäs toteamus, että ei meidän asiakkaat poistu muuta kuin manan majoille tai hinnan perässä, ne pihit penteleet.

Yrityksen tuotteessa ei ole kuulema mitään vikaa. Palvelu on priimaa ja markkinaosuus olisi 100% jos vain kilpailijat eivät myisi arvelluttavan halvalla sekundatuotteitaan. Jostain syystä liikevaihto kuitenkin mataa.

Uuden asiakkaan hankinta on aina kalliimpaa kuin vanhan pitäminen. Parhaimmassa tapauksessa tekemämme asiakaspoistuma-analyysin tuloksena kontaktoiduille asiakkaille saatiin myytyä aivan pöljänä lisää tavaraa. Asiakkaat eivät aina ole siis tyytymättömiä palveluun, he ovat vain herkkiä myynnille. Sinun kannattaa olla silloin ensimmäisenä paikalla.