18.01.2016 / Ville Niemijärvi

Käytännön analytiikan blogisarjamme jatkuu. Viime kerralla määrittelimme liiketoimintaongelman, joka pitää ratkoa ja sovimme toimenpiteistä joilla tähän päästään.

Ennen kuin päästään itse datan pariin, pitää meidän pystyttää tekninen ympäristö. Käydään se nyt läpi. Otetaan ensiksi katsaus ylätason arkkitehtuuriin, tuotteisiin ja komponentteihin. Sen jälkeen alempana näytetään miten kaikki tehdään käytännössä.

Edistyneen analytiikan arkkitehtuuri

Mitä tuotteita, tietokantoja ja sovelluksia tarvitaan kun rakennetaan täysiverinen, tuotantokelpoinen analytiikkaympäristö? Otetaan selvää.

Katsotaan ensiksi ihan ylätasolla, mitä meillä pitää olla ja mitä pitää tehdä?

  • lähdedata: meillä pitää olla jotain mitä työstää ja analysoida
  • tietojen poiminta, muokkaus ja integrointi. Eli meillä pitää olla jokin ns. etl-työväline (extract-transform-load, tuttu tietovarastomaailmasta). Yleensä valtaosa analytiikkaprojektin työajasta (n. 70%) menee datan muokkaamiseen ja käsittelyyn.
  • tietokanta, johon lähdetieto tallennetaan, jossa sitä myös muokataan etl-välineellä ja jonne myös valmiit tuotokset tallennetaan
  • analytiikkatyöväline: eli se missä varsinainen tiedon mallinnus, data science ja algoritmit sijaitsee
  • visualisointi, julkaisu: analytiikkatyöväline on harvoin se missä tulokset näytetään loppukäyttäjille. Usein, miltei aina tulokset viedään johonkin raportointi- tai visualisointiohjelmistoon.

Eli tiedon arvon jalostusta ja niihin liittyviä komponentteja voisi kuvata kuten alla.

Analytiikka-arkkitehtuuri Azure-ympäristössä Louhia

Arkkitehtuurin voi myös kuvata perinteisesti tietovarastotyyliin kuten alla kuvassa:

Analytiikka-arkkitehtuuri Azure-ympäristössä Louhia 2

Ja muistetaan, että kaikki tuotteet, palvelimet ja komponentit pitää löytyä pilvestä. Lähdetietoja lukuunottamatta. Mitään ei asenneta omalle koneelle tai omaan palvelinsaliin.

Heitän seuraavaksi pallon Lasselle, joka toipui influessasta yhdessä päivässä, kuulemma pelkästään proteiinipatukoiden voimalla.

Teknisen ympäristön pystyttäminen

Seuraavassa käydään läpi miten edellä luetellut kaikki tarvittavat tuotteet, tietokannat ja palvelimet otetaan käyttöön Microsoft Azure -ympäristössä.

1. Luo Azure tili

Azure tilin osalta voidaan puhua ihan tavallisesta Microsoftin käyttäjätilistä. Microsoftin käyttäjätilillä (yritys/yksityinen) pääsee kirjautumaan kaikkiin Microsoftin palveluihin. Microsoftin käyttätilin voi luoda osoitteessa signup.live.com

22_Create_azure_account

 

Kun Microsoftin käyttäjätili on luotu, pääset kirjautumaan osoitteessa https://account.windowsazure.com/, jossa seuraavaksi luodaan Azure-tilaus (Subscription). Tässä yhteydessä valitaan haluttu maksutapa ja kerrotaan kenen pussista rahat otetaan. Meidän blogisarjaa varten rahat viedään minun eli Lassen tililtä Pay-As-You-Go-tyyppisesti, eli maksetaan kiltisti viulut mitä palveluiden käytöstä aiheutuu, eikä tippaakaan ylimääräistä (kiitos Lasse uhrauksesta. T. Johto)

31_Azure_Subscription

Kun edellä olevat kohdat kyselyineen ovat täytetty, voidaan siirtyä seuraavaan kohtaan.

 

2. Azure virtuaalipalvelin ja sinne ETL-työväline (SSIS)

Kirjautumalla osoitteeseen https://portal.azure.com/ edellisessä kohdassa luomalla käyttäjätililläsi, pääset käsiksi Azuren palveluihin, yhdestä paikasta. Tarkkasilmäisimmät huomaavat, että alla olevassa kuvassa näyttäisi olevan jo ostettuina palveluita, mm. Azure SQL-tietokanta, Azure Virtuaalipalvelin, jne… Eli ei pitkälle päästy, kun jäätiin housut kintuissa kiinni,

a. Emme luoneet blogisarjaa varten uutta Microsoft-käyttäjätiliä vaan käytimme jo olemassa olevaa,

b. Unohdin ottaa screenshotin portaalin aloitusnäkymästä ennen kuin suoritin kohdat 3.-4.

Aloitusnäkymä poikkeaa täten aivan blankosta näkymästä

32_Azure__portal

Valitaan New -> Compute -> Windows Server 2012 R2 Datacenter

33_Azure_VM_1

Deployment method: Recource Manager (tai Classic) -> Create

33_Azure_VM_2

Seuraavaksi määritellään virtuaalipalvelimen asetukset

33_Azure_VM_4

Huomioitavaa on se, että tässä vaiheessa luodaan uusi Resource Group, jonka alle eri palveluita voidaan ottaa käyttöön (seuraaminen/hallinnointi helpompaa). Seuraavaksi määritellä raudan speksit, demoa varten meille riittää A1 Basic-tason virtuaalikone. Saamme valinnalla tuulahduksen nostalgisista 386:n ajoista. Tämän tason virtuaalimasiinasta on kokemuksia ja tiedän ettei hyvä heilu suorituskykymielessä, mutta mennään tällä jotta luottorajat ei pauku ja saan tuotua leivän perheelle ensi kuussakin.

33_Azure_VM_3

Ja kun kun kaikki on tarkistettu vähintään kertaalleen, painetaan OK

33_Azure_VM_5

Kun OK-nappia on painettu palaa Azure-portaali aloitusnäkymään, johon on ilmestynyt sininen suorakulmio, jossa viuhahtelee valkoisia viivoja, tämä tarkoittaa sitä, että palvelinta ollaan pystyttämässä. Pystytystä odotellessa voidaan siirtyä seuraavaan kohtaan ja palata ETL-työvälineen asentamiseen kun virtuaalipalvelin on luotu.

ETL-työväline, ts. Microsoftin Data Toolsin (tarkemmin demosarjan tapauksessa: (Microsoft SQL Server Data Tools – Business Intelligence for Visual Studio 2012) saa ladattua Microsoftin sivuilta (https://www.microsoft.com/en-us/download/confirmation.aspx?id=36843).

Nyt kun virtuaalipalvelin on luotu, voimme kirjautua sinne esimerkiksi suoraan Remote Desktop Connectionilla (palvelimen tiedot löytyvät Azure-portaalista). Kiikutetaan Data Toolsin sisältävä tiedosto (SSDTBI_VS2012_x86_ENU.exe) virtuaalipalvelimelle, keinoja on tietysti monia, esimerkiksi “copy & paste”. Exe-tiedosto purkautuu automaattisesti haluttuun kansioon, jonka jälkeen käydään klikkaamassa SETUP-applikaatio käyntiin ja edetään lyehkön wizardin mukaisesti. Ei siis tämä ETL-työvälineenkään asentaminen ole vaikeaa (huomattavasti vaikeampaa voi olla löytää palvelinspekseihin sopiva Data Toolsin sisältävä tiedosto).

[Villen lisäys tähän väliin]. Huom: koko virtuaalipalvelin hässäkkä on tarpeen vain SSIS:ää eli etl-työvälinettä varten. Toki sitä voi käyttää myös tiedostojen tallennuspaikkana.

Useimmiten (=aina) analytiikkahankkeissa meidän pitää yhdistää eri tietolähteitä ja/tai muokata dataa, laskea uusia muuttujia jne.

Ja harvoin analytiikkatyövälineen oma tiedonkäsittely ja integraatio-ominaisuudet riittävät tähän. Tai se vaatisi kovaa koodaamista. Itse pitäisin analytiikkasoftan analytiikkakäytössä ja hankkisin aina parhaan työvälineen sille tarkoitettuun tehtävään. ETL-työväline ja sille dedikoitu palvelin tulee käyttöön viimeistään siinä vaiheessa jos rakennetaan tietovarastoa tai erillistä raportointitietokantaa.

Vaihtoehto SSIS:lle olisi Microsoftin Data Factory, mutta se ei ole vielä valmis tuote oikeaan datan käsittelyyn, enemmänkin tietojen lataukseen paikasta a paikkaan b. Tulevaisuudessa Data Factoryn pitäisi kuitenkin olla Microsoftin ykkösvaihtoehto pilvipohjaiseen ETL-työhön.

3. Azure SQL tietokanta

SQL tietokannan luonti on helppoa Azure Portaalin kautta, seuraava kuvasarja näyttää kuinka helppoa se on.

Valitaan New -> Data + Storage -> SQL Database

32_Azure_SQL_1

Määritellään tietokannalle nimi, kontin tilavuus, hevosvoimat, maksutapa ja lopuksi Create

32_Azure_SQL_2

Demon aineiston luonteen ja Louhian maksaman tilinauhan perusteella jätimme hevosvoimat minimiin valitsemalla B Basic-tyypin tietokannan. On siis hyvä alustavasti tuntea tarpeet ennenkuin tietokannan luo, skaalaus/hevosvoimien vaihtaminen onnistuu myös jälkikäteen (ei paneuduta tässä kuitenkaan siihen).

Azure-portaalin aloitusnäkymään ilmestyy jälleen sininen suorakulmio, nyt tiedätte jo mitä se tarkoittaa… hetken odottelun päästä tietokanta on käyttövalmiina. Valmistumista odotellessa voidaan siirtyä jälleen seuraavaan kohtaan.

Noniin, nyt se on pystytetty, tässä todiste siitä (tietokantaan pääsee käsiksi vaikkapa omalta läppäriltä SQL Management Studio:lla, edellyttää, että määrittelet ip:si sallituksi Azure-portaalista: Firewall settings)

35_Azure_SQL

 

4. Azure Machine Learning Studio

Sanotaanko, että hommat senkun helpottuu tässä vaiheessa, tämä on jo niin helppoa, oikein hirvittää. Siispä asiaan, tässä on käytännössä vain 2 välivaihdetta

Valitaan Azure-portaalista New -> Data + Analytics -> Machine Learning

34_Azure_ML

Kun valinta on tehty, ponnahtaa selaimeesi uusi ikkuna, joka näyttää seuraavalta

34_Azure_ML_2

Tämä on vanha näkymä ja uusi näyttäisi olevan myös tarjolla (sininen laatikko ylälaidassa), mutta kun sitä painaa päästään takaisin samalle sivulle (loogista?).

Azure ML:n käyttöä varten tarvitsee (ainakin ensimmäisellä kerralla) luoda ns. Azure ML Workspace (työtila) ja Storage account. Nämä 2 asiaa saadaan luotua yhdellä kertaa seuraavasti

Valitse New -> Data Services -> MACHINE LEARNING -> Täytä tiedot ja luo

34_Azure_ML_3

Azure ML:n käyttöliittymän kuvia tulee blogisarjan edetessä.

 

Enää puuttuu siis Power BI, Ville ota koppi ja nopeasti, menee mun laskuun, hopihopi!

5. Microsoft Power BI

Ville tässä taas. Olen ottanut aiemmin käyttöön MS Power BI desktopin. Asennus + ensimmäiset raportit kesti pari minuuttia. Katsotaan mitä kestää pilvipalvelun käyttöönotto.

Huomioikaa, että nyt ei olla enää Azure-ympäristössä. Tämä on enemmänkin sitä Office 365 maailmaa. Mutta mennään asiaan.

  • Mene osoitteeseen: https://powerbi.microsoft.com/en-us ja klikkaa Get started free
  • Valitse joko Power BI Desktop for Windows tai Power BI (pilviversio). Me otamme jälkimmäisen
  • Kirjaudutaan Microsoftin käyttäjätilillä (ks. kohta 1.), painetaan kerran tai pari OK
  • Ja valmis. Kesto: 42 sek.
Microsoft Power BI käyttöönotto 1 Louhia
Valitse haluatko desktop-sovelluksen vai pilviversion. Molemmat ilmaisia.

Microsoft Power BI käyttöönotto Louhia

Microsoft Power BI käyttöönotto 2 Louhia

Microsoft Power BI käyttöönotto 3 Louhia
Power BI valmiina ottamaan yhteyttä Azure SQL -tietokantaan tai muihin tietolähteisiin.

Otimme nyt käyttöön Power BI:n ilmaisversion. Siinä on rajoituksensa verrattuna Pro-versioon. Löydät erot täältä: https://powerbi.microsoft.com/en-us/pricing/

Pro-version hinta on siis 9,99$/kk/käyttäjä eli esim. 10 hengen organisaatiossa vuosikustannus olisi 1200$.

No niin, nyt meillä on koko paketti kasassa. Asensimme siis:

  • Azure virtuaalipalvelimen
  • ETL-työvälineen ko. virtuaalipalvelimelle
  • Azure SQL -tietokannan
  • Azure ML  analytiikkaa varten
  • MS Power BI:n raportointia ja analytiikkatulosten visualisointia varten

Nyt meillä on pystyssä täysiverinen, skaalautuva, täysin pilvipohjainen arkkitehtuuri, jolla voisi lähteä toteuttamaan myös tietovarasto- ja raportointiympäristöä.

Toisaalta jos sinulla on jo oma ETL-työväline (esim. SSIS, Informatica, IBM DataStage, Pentaho…) tai datasetti on valmiina ja odottaa pelkkää numeronmurskausta, voit skipata kohdat 1-3 eli hankkia pelkän Azure Machine Learning Studion.

Teknisen arkkitehtuurin ja sovellusten asennukseen käytetty aika

[Lasse]: Kohtien 1.-4. suorittaminen kesti pyöreästi 4h, sisältäen ruoka- ja kahvitauot. Suurin osa ajasta meni tiedoston SSDTBI_VS2012_x86_ENU.exe siirtämiseen ja asentamiseen palvelimelle, onneks säästy kuitenkin massii.

[Ville]: Kohdan 5 suorittaminen kesti 42 sekuntia. Sisältäen vessa- ja kahvitauot.

Seuraavassa osassa siirrymme lähdetietojen pariin. Pysy kuulolla!


13.01.2016 / Ville Niemijärvi

parked-bikeKäytännön ennustavan analytiikan blogisarjamme ensimmäinen osa kuvaa kuvitellun yrityksemme liiketoimintaongelman. Eli määritellään miksi analytiikkaa ylipäätään lähdetään tekemään.

Yrityksen esittely

Yrityksemme on vähittäiskauppa. Se myy polkupyöriä ja niihin liittyviä tarvikkeita ja lisävarusteita.

(Kyllä, kyseessä on Microsoftin AdventureWorks -demoaineisto. Voit ladata omasi vaikka täältä)

Toimitusjohtajan nimi on Eddy. Entinen pyöräilijä, jonka vanhemmat olivat ruokakauppiaita. Hänellä on intohimo työhönsä. Eddy haluaa nähdä kaikki kansalaiset viilettävän muna-asennossa trikoissa asfalttiteitä pitkin.

Suomen Polkupyörätukku olkoon hyvä vertailukohta. Yritys voisi olla myös sopimusliiketoimintaa harjoittava, esimerkiksi sähköyhtiö, mediatalo (sanomalehdet, TV, tilauskanavat kuten HBO, Netflix), kuntosaliketju tai pankki- ja vakuutusalan yritys.

Aivan samat menetelmät pätevät näihin toimialoihin. Sopimusliiketoiminnassa tosin asiakkuuksien johtaminen hieman poikkeaa koska usein asiakas on naimisissa yrityksen kanssa, kunnes lopettaa asiakassuhteen. Poistumamallinnus eli asiakaspito on tärkeää. Samoin lisä- ja ristiinmyynti.

Vähittäiskaupassa shoppaillaan naapurissakin ja siellä mitataan taas esimerkiksi brändilojaliteettia mutta voidaan tutkia myös poistumaa, sen määrittäminen on vain hankalampaa. Ostoskorianalyysi on yksi vaihtoehto tutkia mitä tuotteita ostetaan yhdessä.

Sopimusliiketoiminnassa älykkäällä prospektoinnila voidaan etsiä ne asiakkaat, jotka todennäköisemmin tarttuvat myyjän puhelinsoittoon tai tarjoukseen ja parantaa konversiota. Vähittäiskaupassa taas suurempi merkitys on mainonnalla – oli se kohdennettua suoramainontaa tai massana eri medioissa.

Molemmissa tapauksissa asiakkaskäyttäytymisen ymmärtäminen edesauttaa asiakkaisiin vaikuttamista .

Liiketoimintaongelma

Analytiikka pitäisi tukea yrityksen liiketoimintastrategiaa. Tai siitä johdettuja taktisia ja operatiivisia tavoitteita.

Tai sitten analytiikan pitäisi olla työväline liiketoimintaongelmien ratkaisemisessa.

Toki analytiikka voi olla erilaisten hypoteesien testaamista mutta mielellään niin, että ne tähtäävät johonkin suurempaan tavoitteeseen.

Analytiikka ei ole nättiä käppyrää, visualisointia tai nice-to-know raportteja. Niiden sijaan analytiikan avulla pyritään muuttamaan toimintaa. Aiheuttamaan muutos.

Polkupyöräkauppamme toimari, Eddy, on yhdessä hallituksen kanssa tehnyt linjavetoja. He haluavat muutosta. Yritys tulee satsaamaan jatkossa vaatelinjaston liikevaihdon kasvattamiseen. Eddy näkee, että kireät pyöräilyshortsit takapuolipehmusteilla tulee lyömään itsensä läpi ensi kesän helteillä rahvaankin joukossa.

Toisaalta Eddy haluaa, että markkinointipäällikkö Lance, joka haaveilee salaa oman “lisäravinnekaupan” pystyttämisestä, karsii kulujaan ja keskittää mainoskampanjansa fiksummin. Jokaisen persaukisen perusautoilijan luokse ei tarvitse suoramarkkinointikirjettä lähettää vaan keskitytään vihreisiin, muotitietoisiin kaupunkilaisiin, joilla löytyy kuitenkin pätäkkää.

Eddy järkeilee, että on parempi antaa luonnon ja sepelvaltimotaudin hoitaa autoilevat möhömahat. Sitä kautta markkinoille saadaan parempia kuluttajia. Pyöräileviä kuluttajia.

Lisäksi Eddy laittaa osto-johtaja Bernardille ukaasin:

“Älä tilaa niitä väärän värisiä rättejä varastoon jos niitä ei kerran kukaan osta. Nehän homehtuu sinne. Ranskalaisena luulisin sinun tajuavan jotain muodin päälle?, tuhahtaa Eddy sillä tavoin ivallisesti kuten voisi kuvitella belgialaisen tekevän kun pääsee pomottamaan ranskalaista.

Toimitusjohtaja-Eddyn ja hallituksen muodostamat tavoitteet ja ns. must-win-battles kirjataan ylös:

  • vaatelinjaston myynnin pitää kasvaa 20%
  • myynnin kulujen pitää laskea 20%
  • varaston arvon pitää pienentyä 30%

Lance ja Bernard ryhtyvät hommiin koska heidän oma palkkansa riippuu siitä, miten hyvin he täyttävät tavoitteensa. Niin kuin kaikissa fiksuissa yrityksissä on, vai mitä?

Kaverit lyövät pyöräilykypäränsä yhteen ja tuumailevat:

  • jotta me voimme myydä enemmän vaatteita, meidän pitää tietää ketkä vaatteita ylipäätään ostavat, meidän pitää ymmärtää asiakaskäyttäytymistä
  • kun tiedämme ketkä vaatteita ostavat, voimme kohdistaa myynnin pelkästään heille.
  • näin myynnin konversio kasvaa eli saamme myytyä pienemmällä myyntiväellä isommalle porukalle
  • jotta varaston arvo laskee, meidän pitää välttää huonosti kiertävien tuotteiden sisäänoston
  • tulevien kuukausien myynnit pitää siis nähdä etukäteen. Näin voimme ennakoida kysynnän nousut ja pudotukset hyvissä ajoin ja osto voi reagoida niihin.

Kaverukset johtavat tavoitteista seuraavat toimenpiteet:

  • mallinnetaan keitä asiakkaamme ovat, selvitetään miten he käyttäytyvät
  • mallinnetaan ketkä ostavat vaatelinjaston tuotteita ja mitkä taustatekijät selittävät ostoa (ikä, sukupuoli, maantieteellinen sijainti, muu ostokäyttäytyminen jne.)
  • sovelletaan mallia nykyiselle aktiiviselle asiakaskannalle ja selvitetään ketkä heistä olisivat todennäköisempiä ostajia uusille tuoteryhmille
  • kohdennetaan suoramarkkinointi vain näille todella potentiaalisille kuluttajille
  • tehdään jatkuvasti päivittyvät myyntiennusteet tuleville kuukausille per tuoteryhmä ja annetaan nämä ostajille ostopäätösten tueksi

“Päivän päätteeksi tehdään enemmän rahaa pienemmilä kustannuksilla, saadaan mojovat bonukset ja pidetään työpaikkamme.”

Näin yritys on määrittänyt itselleen strategiasta johdetut tavoitteet, jotka on purettu konkreettisiksi toimenpiteiksi. Seuraavaksi selvitämme millä analytiikan keinoin voimme tukea tai ratkaista nämä liiketoimintaongelmat. Mitä työvälineitä ja mitä dataa siihen tarvitaan?

Lasse, maailman vahvin analyytikko, oletko selättänyt jo influessan? Meillä olisi hommia!


Kuva: Sylwia Bartyzel (https://unsplash.com)

12.01.2016 / Ville Niemijärvi

Aloitamme lyhyen blogisarjan miten tehdä analytiikkaa Azure Machine Learning:llä.

Sarja käydään läpi tehokkaasti vajaassa 3 viikossa, sisältäen 3-4 juttua. Sarja päättyy Talentum Eventsillä pitämääni asiakasanalytiikka koulutukseen, jossa koko prosessi käydään läpi.

Ei teorioita, ei jaaritteluja, pelkkää asiaa

Suun louskuttajia aina löytyy hype-termien tiimoilta ja olemme mekin varmasti syyllistyneet kliseiden toistamiseen.

Dilbert

Nyt onkin aika näyttää miten analytiikkaa todella tehdään. Käytännössä ja konkreettisesti. Alusta loppuun. Ja mitä se maksaa. Ei teorioita. Ei höpöhöpöä ja liirulaarumeita.

Toteutamme sarjassa koko prosessin liiketoimintaongelman määrittämisestä, teknisen ympäristön pystyttämiseen, datan muokkaamiseen, mallintamiseen ja tulosten visualisointiin sekä tuotantokäyttöön.

Käytämme juuri niitä samoja työvälineitä ja menetelmiä mitä käytämme todellisissakin projekteissa. Seuraamalla blogisarjaa, näet siis miten käytännössä analytiikka tehdään Microsoft Azure -ympäristössä ja voit toistaa sen omassa yrityksessäsi ja säästää konsultointikustannuksissa.

Noudatamme hieman modifioitua CRISP-DM metodologiaa. Sisältäen seuraavat vaiheet:

Vaiheet:

  1. Määrittele liiketoimintaongelma
  2. Kerää data
  3. Muokkaa, käsittele ja rikasta tietoa (ns. etl-prosessi) ja tallenna se tietokantaan
  4. Analytiikka eli erilaisten ennustemallien toteutus Azure ML:ssä
  5. Tulosten visualisointi (MS Power BI)
  6. Ennustemallien tuotantokäyttö eli kohta jossa naureskellaan matkalla pankkiin

Pelkkää pilveä: All-in-Azure

Rakennamme koko touhun ETL-prosessista (datan lataus, muokkaus ja käsittely), tietokantaan ja analytiikkamallinnukseen Azureen. Eli pilveen. Yhtään kilkettä ei asenneta omalle palvelimelle.

Otamme käyttöön Azure virtuaalikoneen jota käytämme lähinnä ETL-työhön (MS SSIS). Toinen vaihtoehto olisi hyödyntää Data Factoryä, Microsoftin pilvipohjaista integraatiotyövälinettä. Tämä ei ole kuitenkaan vielä läheskään valmis suorittamaan vähänkään vaativimpia datan muokkaus toimenpiteitä eli ns. etl-työtä. Tai se vaatii koodaamista. Näin on fiksummat opastaneet.

Otamme käyttöön Azure SQL -tietokannan, jonne datat tuupataan. Tällä yhdistelmällä voisimme rakentaa myös varsinaisen tietovaraston, aivan kuten rakentaisimme sen yrityksen omille palvelimille on-premise. Looginen arkkitehtuuri on aivan sama.

Lisäksi käytämme Azure Machine learning studiota analytiikkamallintamiseen eli mallinnamme dataa tarpeesta riippuen eri algoritmeilla. Teemme ainakin:

  • asiakassegmentoinnin
  • asiakaspoistumamallinnuksen
  • myyntiennusteen
  • lisämyyntiennusteen

Vaikkakin teemme nyt kaiken Azuressa, voisimme yhtä hyvin käyttää Amazonia tai analytiikkamallinnuksessa RapidMinerin pilveä. Käytämme nyt Azurea ja Microsoftin työvälineitä koska se on yksinkertaisesti tutuin vaihtoehto ja paljon kattavampi/monikäyttöisempi (virtuaalikoneet, blob-storage, SSIS, Power BI, ML) kuin esim. pelkkä RapidMiner.

Ja vaikka keskitymme nyt asiakasanalytiikkaan, voi samaa arkkitehtuuria ja algoritmeja hyödyntää toimialasta riippumatta ja vaikka tuoteanalytiikassa (esim. vikaantumisen ennakointi, tuotemenekkien ennustaminen).

Laitamme kaiken Lassen, maailman vahvimman analyytikon, luottokortille. Blogisarjan päätteeksi katsomme mikä on Lassen kortin saldo ja meneekö ensi kuukausi ylitöiksi. Toisin sanoen näytämme mitä tämä oikeasti maksaa ja voit arvioida mitä se maksaisi sinulle.

Jos sinua kiinnostaa tietää aihepiiristä lisää tai haluat, että näytämme/selvitämme jotain erityistä osa-aluetta tarkemmin, ole rohkeasti yhteydessä.

Voit nakata meille viestiä:

Aikaa on vähän joten Lasse, paras ryhtyä hommiin.


 

Jos haluat vähän makustella mitä asiakasanalytiikka tai asiakastiedon rikastaminen on, kannattaa tutustua seuraaviin juttuihin:

http://www.louhia.fi/tag/asiakasanalytiikka/


22.12.2015 / Ville Niemijärvi

Viime viikon ja syksyn aiemmalla business intelligence -kurssilla esitettiin muutamia hyviä kysymyksiä liittyen BI-markkinoihin. Laitan tässä vastaukset ja pitkähkön pohdinnan muillekin lukijoille.

1. Mikä on paras QlikView-konsulttitalo?

Tämmöisen miinan pudottivat. Nyt oli mahdollisuus haukkua kaikki lyttyyn tai vetää överisti kotiin päin. Mutta asia on vain niin, että Qlik-konsulteilla on alalla järjestään hyvä maine. Ajatellen IT-alaa kokonaisuutena.

Olen järjestänyt useita kilpailutuksia (niin työväline kuin konsultointi) ja kierrän vuodessa kymmeniä asiakkaita, joilla useilla on Qlik-ympäristö. Järjestään palaute valitusta konsulttitalosta on positiivista, oli se kahden henkilön nyrkkipaja tai isompi puulaaki.

Positiivinen palaute johtunee osittain työvälineestä, joka edesauttaa nopeiden projektien toteuttamisessa. Tableau-asiakkaiden palaute omasta toimittajasta on myös positiivista. Hieman kömpelömmillä tuotteilla myös toteuttava konsulttitalo saa kuraa niskaan jos hommat ei etene tai tulos ei tyydytä.

Jos joitain Qlik-taloja pitäisi nostaa esille niin oma valintani olisi Infrastone. Olemme tehneet kolmessa projektissa yhteistyötä ja jälki on mainiota ja laadukasta. Infrastone on omien sanojen mukaan Suomen kokenein Qlik-kumppani ja väkeä on siis enemmän kuin mies ja koira.

Ennen kaikkea asiakkaan edun laittaminen aidosti etusijalle lisenssi- tai projektimyynnin kustannuksella on hatun noston arvoinen juttu. Korupuheissa kaikki väittää tätä mutta tositapahtumassa harva toimii näin. Infrastone on näyttänyt tämän pari kertaa toteen mikä on oikeasti poikkeuksellista.

Muita Qlik-toimittajia, joita en itse enempiä tunne mutta joita asiakkaat ovat kehuneet ovat ainakin EVRY, Eximia ja käyttöliittymäsuunnitteluun erikoistunut Adage. Käyttöliittymäsuunnittelun mukaan tulosta BI-kehitykseen lisää vähän alempana.

Tämä ei tarkoita, että muut Qlik-kumppanit olisivat kuraa. Löydät kaikki Qlik-kumppanit täältä.

Ja hei yritykset: hyviä toimittajia kannattaa mainostaa muillekin. Se on teidän etu, että hyvä kumppaninne menestyy. Muutenkin kuin vain toimittajien väsyneissä referenssitarinoissa (“toimittaja X teki sen mitä pyydettiin ja nönnöönöö booring!…”)

Ja huonoja saa myös kritisoida. Se on rehtiä ja reilua liiketoimintaa. Niin pakotetaan toimittajia nostamaan tasoa, kouluttamaan tekijöitä ja kehittämään prosesseja. Näistä asioista puhutaan ihan liian vähän.

2. Mihin Business Intelligence -työvälineet ovat menossa?

Lyhyt analyysi: isot perinteiset toimijat lähestyvät pieniä, ketteriä visualisointi-experttejä kehittämällä omia data discovery ja visualisointi ominaisuuksia. Pienet, ketterät taas kehittävät enterprise-tason kyvykkyyttä.

Eli isot BI-talot ovat tehneet hartiavoimin töitä kehitellessään omia visualisointivälineitä. Esimerkkinä SAP:in Lumira, Microsoftin Power BI, IBM Cognoksen Workspace (ja nyt julkaistu Cognos Analytics) ja SAS Visual Analytics. Olen tutustunut näihin kaikkiin ja suunta on oikea.

Pienet entiset niche-toimijat taas laajentavat repertuaariaan pyrkiessään aidoksi enterprisetason ratkaisuksi. Esimerkkinä Qlik, joka osti NPrintingin vakioraportointiin. Metadatan hallintasovelluksen (vrt. SAP Universe, Cognos Framework Manager) puutetta paikataan ohjaamalla oikeaoppiseen tietoarkkitehtuuriin erottaen Qlikin data- ja sovelluskerroksen. Tiedon hallittavuutta ja auditointia (data governance) parannetaan Governance dashboardilla, jota tosin harmittavan harva asiakas käyttää.

Nyt alkaa näyttämään siltä, että lähes kaikki BI-tuotteet ovat ns. one-size-fits all -tuotteita eli yksi tuote sopii kohtuu hyvin koko organisaation käyttöön.

Tableau on tosin poikkeus. Ainakin minulle heidän myynti on sanonut selvästi, että perinteinen vakioraportointi ei ole heidän pallokenttä. Yrityksellä ei näytä olevan hinkua pyrkiäkään enterprise-tason tuotteeksi ja useimmiten Tableau onkin yrityksessä se “kakkostuote” eli pienemmän osaston käytössä puhtaasti visualisointiin, perinteisen vuosia sitten hankitun Cognoksen tai SAP:in hoitaessa vakioraportoinnin. Tästä päästääkin seuraavaan kysymykseen.

3. Onko kahden BI-tuotteen strategiassa järkeä?

Kannattaako kuitenkaan laittaa kaikki munat samaan koriin vai voisiko elää kahden tuotteen kanssa?

Vastaus: Kaksi BI-tuotetta on ihan toimiva ratkaisu. Tämä on nykyään enemmänkin sääntö kuin poikkeus. Etenkin silloin kun a.) halutaan tarjota käyttäjille parasta ja b.) käyttötapaukset ja käyttäjäroolit eroavat selkeästi toisistaan.

Vaikka visualisointityövälineellä (esim. Tableau tai QlikSense) on kiva kikkailla ja käyttö on pelkkää hattaransyöntiä, ei se sovi kaikille käyttäjille. On paljon käyttäjiä jotka eivät halua/tarvitse mennä porautumaan tietoon ja joiden ei tarvitse nähdä nättiä käppyrää. Toisin sanoen on sellaisia käyttäjiä joiden pitää tehdä oikeita töitäkin ja kriittisimmät luvut pitää saada käyttöön muuta kautta.

Esimerkiksi jos käyttäjien tarpeena on vakioraportointi tai vaikka raporttien helppo jakelu monipuolisessa formaatissa (pdf, html, xls) burstaten sähköpostitse tai levyn kulmalle huolehtien rivitason tietosuojauksesta, ei tähän kannata tarjota Qlikiä, Tableauta tai PowerBI:tä.

Toisaalta jos puntarissa painaa etunenässä ostamisen helppous, helppo käyttöönotto, toteutuksen ja käytön nopeus, IT:n tehtävien minimoiminen, käyttömukavuus ja visuaalisuus, niin edelleenkään isot perinteiset BI-toimijat eivät yllä tässä Tableaun tai Qlikin tasolle. Visualisointia ja data discovery -ominaisuuksia tarjoavat kaikki mutta muissa ominaisuuksissa (esim. ostamisen ja käyttöönoton helppous, hinnoittelun selkeys, IT:n pieni merkitys jne.) tulee suuria eroja.

Jos et usko, tee testi. Käy ottamassa netistä Tableaun serveri + client ilmaiseen koekäyttöön. Saat serverin pystyyn ja ensimmäiset raportit julkaistua tunnissa. Kokeile samaa Cognoksella, SAP:lla tai vaikka Oraclella. Ensimmäisessä tunnissa löydät ehkä myynnin puhelinnumeron jenkkeihin.

Alla kuvassa on hyvin karkea yleistys eri käyttäjärooleista. Vasemmalla on karrikoiden se iso pomo, jota ei kikkailut kiinnosta vaan hän haluaa tulos-, tase- ja myyntiraportin määrämuotoisesti esimerkiksi kerran kuukaudessa. Myös operatiivinen toiminto, jota BI-tukee voi olla tällaista. BI-palvelu tuuppaa kaupan vihannesosastolle tiedon milloin kurkut on homeessa. Lue lisää alempana upotetusta BI:stä.

Oikealla on controller, analyytikko, assistentti, (keski) johdon edustaja joka ymmärtää datan ja sen analysoinnin päälle. Hänelle jäykät vakioraportit eivät riitä, työvälineen pitää tarjota visualisointi ja ns. data discovery -ominaisuuksia (drill up/down, slice ‘n dice, assosiatiivisuus) sekä mahdollisuus lisätä uusia tietolähteitä (ns. data mash-up).

Raportoinnin roolit Louhia

 

Kaikki isot BI-toimijat taklaa kaikki nämä käyttötapaukset ja paljon muuta. Tableau keskittyy selkeästi oikealle laidalle, jenkkituote on ääri republikaani, vasenta ei suosita juurikaan. Qlik on vahvasti oikealla mutta kurottelee vasemmistoa eli raportoinnin sosiaalidemokraatteja kohden.

Toistan vielä:

  • kyse onkin siitä, haluatko parasta vai kelpaako aika hyvä?
  • kuinka monipuoliset ja poikkeavat käyttötapaukset ja käyttäjäroolit ovat?

Jos melko hyvä kelpaa visualisointiin ja käyttötapauksia löytyy myös perinteisemmästä raportoinnista, on perinteiset toimijat hyvä vaihtoehto, saat yhdestä talosta kaikki. Varsinkin kun monessa talossa on vuosien kokemus ja hiljainen tieto tuotteista eikä tuotteiden vaatima IT-hallinta tuota tuskaa.

Jos haluat parhaan ja helppokäyttöisemmän visualisointi ja analysointituotteen, ota Tableau. Se on paras vaihtoehto ns. kakkostuotteeksi ja myös ainoaksi tuotteeksi jos käyttötapaukset liikkuvat pääosin visualisoinnissa ja itsepalvelussa.

4. Mihin näet business intelligencen käytön yrityksissä suuntautuvan noin ylipäätään?

Pari suuntausta mihin olen törmännyt:

  • käyttöliittymäsuunnittelun ja UX-osaajien käyttö raporttien toteutuksessa
  • BI:n siirtäminen lähemmäksi ja upotetuksi osaksi liiketoimintaa (ns. embedded BI)
  • BI-funktion siirtyminen IT-tuotannosta ja järjestelmäylläpidosta palveluliiketoiminnaksi

Käyn näitä lyhyesti läpi.

Käyttöliittymäsuunnittelu

Olen törmännyt kolmella asiakkaalla käyttöliittymäsuunnittelijan käyttöön BI-projekteissa ja tulos on ollut kaikissa todella hyvä.

Yhdessä casessa yritys teki tietopalvelua omille asiakkailleen, jolloin priima käytettävyys on tietenkin A ja O. Koska kyseessä on maksullinen palvelu, siis yrityksen myytävä tuote. Tällöin designia ei ehkä kannatta jättää raportoinnin juhasipilöille. He osaavat insinööritekniikan mutta toteutuksen käyttömukavuus ja ulosanti loppuasiakkaan kanssa keskustellessa ja iteroidessa voi olla vähän tönkköä.

Käyttöliittymäsuunnittelu BI:ssä ei tarkoita, että jokaista raporttia varten tilataan UX-expertti paikalle. Pitkälle päästään, että UX-expertti on mukana projektin alussa luomassa suuntaviivat, ohjesäännöt fonteille, värien käytölle, layoutille ja erilaisille painikkeille. He voivat toteuttaa esimerkiksi sen ensimmäisen raporttipohjan tai työpöydän yhdessä raporttiexpertin kanssa.

Tämän jälkeen raporttien vääntäjät voivat käyttää tätä pohjana ja tuottaa näyttäviä ja visuaalisesti yhdenmukaisia tuotoksia.

Käyttöliittymäsuunnitteluun Qlik-sovelluksissa on erikoistunut Adage. Isoimmilta konsulttitaloilta löytyy tietty omia käyttöliittymäsuunnittelijoita.

BI upotettuna lähemmäksi liiketoimintaa

Näen, että tulevaisuudessa oleelliset tiedot pitää viedä sinne missä päätöksiä tehdään, lähemmäksi tai osaksi liiketoimintaprosesseja.

Kyseessähän on kuitenkin ensisijassa päätöksenteon tukijärjestelmä. Päätöksiä harvemmin tehdään juuri siinä raportointiportaalissa vaikka ns. single-point-of-access eli tiedot yhdestä tuutista onkin tavoiteltavaa.

Tietoja tarvitaan siellä missä liiketoimintaprosessi tapahtuu. Esimerkiksi CRM:ssä, markkinoinnin automaatiossa, intranetissä, asiakaspalvelun sovelluksessa, myymälöiden osastovastaavilla liikkuessa hyllyjen välissä, varaston trukkikuskeilla tai ylimmällä johdolla golf-kentällä.

Tällöin BI:tä ei tule ajatella raportteina, visualisointeina ja työpöytinä. Käyttötapaukset ja tiedon toimitustapa on tyystin toinen. Integraatioiden määrä BI:stä muihin järjestelmiin ja päätelaitteisiin kasvaa. Tämä asettaa uusia vaatimuksia BI-ympäristön suunnitteluun ja myös softille. Enää ei riitä se, että voit upottaa Cognos-raportin Sharepointiin.

Tällöin erillisen raportointitietokannan tai tietovaraston rooli kasvaa. Integraatio järjestelmien välillä ja päätöksenteossa tarvittavan tiedon toimittaminen sinne missä sitä tarvitaan, on usein helpompaa tietovarastosta oikealla integraatiotyövälineellä (etl-sovellus), sen sijaan, että mietitään miten se Tableaun visualisointi saadaan upotettua myyntimies-mynttisen Audin äly-kojelautaan.

BI-funktio ratkomaan liiketoimintaongelmia
BI-funktio (etenkin edistyneen analytiikan avulla) pitäisi tarjota liiketoiminnalle palvelua, jonka tarkoituksena on ratkoa liiketoimintaongelmia.

Esimerkiksi:

  • Ongelma 1: tuoteryhmän X varaston kierto on liian hidas. Miten voisimme nopeuttaa kiertoa?
  • Ongelma 2: lehtimainosten vaikutus on tippunut. Miten nostaa mainosten vaikutusta myyntiin?
  • Ongelma 3: alennuskampanja meni perseelleen, tuotteita myytiin miinuskatteella. Miten löytää oikea hinta ja oikea tuote kampanjaan, jotta maksimoimme kannattavuuden?
  • Ongelma 4: työvoimakustannukset ovat liian suuret ja ylimitoitetut hiljaisina aikoina mutta ruuhka-aikaan asiakaspalvelu kärsii. Miten optimoida työvuorot kysynnän mukaan?

Näiden kysymysten vastaaminen yhdessä liiketoiminnan kanssa pitäisi olla BI-palvelutuotannon tavoite.

Nämä ovat kaikki ongelmia mitä BI+analytiikkatiimit ratkoo tänäkin päivänä. Ehkä niissä kahdessa yrityksessä Suomessa. Tämä tulee muuttumaan.

BI ei ole siis jatkossa IT:n erityinen osasto missä firman ainoa SQL:ää puhuva nörtti tekee rapsoja aina tilauksesta. Eikä se ole pelkästään liiketoiminnan itsepalvelua ja visualisointi-kikkailua.


 

Tässä oli taas vähän pitkäksi venähtänyt kooste BI-työvälinekoulutuksesta heränneistä ajatuksista.

Vuosi alkaakin olemaan sitten paketissa. Saatamme tuupata vielä yhden kirjoituksen ennen vuoden vaihdetta. Toivottavasti olet viihtynyt blogin parissa ja pysy kuulolla myös ensi vuonna. Oikein hyvää joulua ja uutta vuotta!


10.11.2015 / Lasse Liukkonen

Monesti olen törmännyt kysymykseen “Miten mitataan kahden eri tuotteen myynnin välistä korrelaatiota?” tai vastaavasti “Miten tuotteen A myynnin historiaa voidaan käyttää tuotteen B kysynnän ennustamisessa lähitulevaisuuteen?”. Konseptina näissä kysymyksissä esiintyivät aikasarjat.

Alkuun voisi kuvitella, että näihin kysymyksiin löytyisi selkeät ja yksikäsitteiset vastaukset, näin ei asianlaita kuitenkaan ole, ainakaan jokaiselle datan ja mallintamisen parissa työskentelevälle. Melkeinpä uskaltaisi väittää, että jokainen aikasarjojen kanssa puuhastellut data-analyytikko on ainakin kerran huomaamattaan laskenut kahden aikasarjan välisen korrelaation teoreettisessa mielessä virheellisesti. Se, onko korrelaation laskennan oletuksien huomiotta jättäminen aiheuttanut liiketoiminnan mielessä katastrofaalisia seuraamuksia on toinen seikka.

Käymme tässä kirjoituksessa läpi vastauksia edellä esitettyihin kysymyksiin esimerkkiaineiston avulla. Esimerkkiaineistoksi on generoitu seuraavat kuvitteelliset myynnin aikasarjat:

1) Lada Samaran kappalemääräinen myynti kuukausitasolla; 2010-01 -> 2013-12,

2) Lada Samaran sytytyspuolien kappalemääräinen myynti kuukausitasolla; 2010-01 -> 2013-12.

Se, miksi tarkastelemme juuri Lada Samaran ja sen varaosana sytytyspuolia ei ole titenkään kovinkaan oleellista, mutta se, että tarkastelemme tuoteparia {auto, varaosa} on oleellista jatkon tarkasteluissa. Oletetaan vielä lisäksi, että tarkasteltavan Lada Samaran kanta on pienehkö ennen tarkasteltavaa aikaväliä ja, että sytytyspuolien rikkoutuminen on Lada Samaroiden tyyppivika.

Seuraavassa tarkasteltavien aikasarjojen kuvaajat:

ladasamara

ladasamarapuola

 

Kuinka mitata kahden aikasarjan välistä korrelaatiota? Mitä on syytä ottaa huomioon? Onko korrelaation laskentatapa yksikäsitteinen?

 

Ennen korrelaation (vai korrelaatioiden?) laskemista on syytä tarkastella aikasarjojen kuvaajia samasta kuvasta päällekkäin ajallisesti sijoitettuna, sillä usein jo silmämääräinen tarkastelu antaa tietoa tuotteiden myyntien välisestä suhteesta. Tässä esimerkkitapauksessa voimme ajatella korrelaation arvon heijastavan myös “kausaalisuuden suuruutta”, koska tarkasteltavaksi tuotepariksi oli valittu {auto, varaosa}.

ladasamara_ladapuola

 

Ensipuraisulla näyttää siltä, että myyntien välillä voisi vallita vahva korrelaatio, mutta kuinka korrelaatio tässä esimerkkitapauksessa laskettaisiin?

1) Tavallisesti numeerisien satunnaismuuttujien välisenä (lineaarisen riippuvuuden) korrelaationa käytetään Pearsonin korrelaatiokerrointa. Aikasarjojen tapauksessa korrelaatio lasketaan tarkastelemalla aikasarjojen vastakkaisia havaintopareja, esimerkin tapauksessa 3 ensimmäistä havaintoparia ovat (1028030, 2991930), (597848, 1021953), (1220731, 1222494). Havaintoparien ensimmäiset lukuarvot vastaavat Lada Samara:n myyntiä ja vastaavasti jälkimmäiset sytytyspuolien myyntiä tarkasteltavana ajankohtana. Pearsonin korrelaatiokerroin on tässä tapauksessa 0.46 (yllättävän pieni arvo?), kerroin näyttää hyvältä ja sen merkkikin ongelman kannalta lienee oikea. Olemmeko tyytyväisiä? Emme!

Mikä edellisen kohdan laskennassa jäi huomioitta?

2) Itse ilmiötä pohtiessa tulee mieleen, että eikö autojen myynnin ja varaosien ostojen välillä tulisi ilmetä jokin “keskimääräinen viive”, ainakin tapauksissa, jossa varaosan hankkiminen johtuu tyyppiviasta? Pitäisikö siis laskea 1)-kohdan tapaan korrelaatiokertoimien arvot eri viiveillä (siirretään sytytyspuolien myynnin aikasarjaa taaksepäin kuukausi kerrallaan)? Tässä kertoimet 9:llä eri viiveen arvolla:

korrelaatio_kertoimet

 

Näyttäisi siltä, että suurin aikasarjojen välinen korrelaatiokerroin esiintyy, kun tarkastellaan sytytystulppia 6kk viiveellä. Pillit pussiin, case solved, alakerran baariin? Ei!

Jäiköhän jotain vielä huomioimatta?

3) Itseasiassa edellisessä kohdassa laskettiin ns. ristikorrelaatioita, eli kahden aikasarjan välisiä korrelaatioita eri viiveen arvoilla. Jos olemme jossain määrin täsmällisiä, niin ristikorrelaatio on (ensisijaisesti) määritelty (vahvasti) stationaarisille aikasarjoille.

Onko esimerkissä tarkasteltavat aikasarjat stationaarisia, ts. tulee tarkastaa muuttuuko niiden jakaumat eri ajanhetkien välillä, jos muuttuvat, niin kyseiset aikasarjat eivät ole stationaarisia. Molemmissa aikasarjoissa on selkeästi havaittavissa nouseva trendi, joten aikasarjat eivät selvästikkään ole stationaarisia. Tyypillisin “todellista” korrelaatiota vääristävä tilanne on juuri se, että molemmat tarkasteltavista aikasarjoista sisältävät likipitäen saman suuntaisen trendin. Tälläisissa tapauksissa laskennallinen korrelaation arvo tulee olemaan yli arvioitu, vaikkei aikasarjojen välillä todellisuudessa tulisikaan esiintyä merkittävää korrelaatiota (kausaalisuutta).

Ratkaisuna edellä mainittuun ongelmaan voidaan yrittää dekomponoida aikasarjat (huom! vaatii kuukausittaisilta aikasarjoilta yleensä väh. 3 vuoden datan). Dekomponoinnissa aikasarjat paloitellaan kolmeen erilliseen komponenttiin: trendi-, kausivaihtelu- ja jäännöskomponentti. Seuraavassa kuvat aikasarjojen dekomponoinneista:

decomp_ladasamara

decomp_sytytyspuola

 

Erityisen kiinnostavaa esimerkkitapauksessa on tutkia kausikomponenttien välistä yhteyttä, sillä sytytyspuolien myynnin kausivaihtelu ei näytä olevan ainakaan vuodenaikaan loogisesti sidottuna => sytytyspuolien myynnin kausivaihtelu “täytyy” johtua kausittaisesta autojen myynnistä. Auton myynnin ja sytytyspuolien (6kk viive) myynnin kausikomponenttien välinen ristikorrelaatio on 0.92. Voidaanko/pitäisikö kausikomponenttien ajatella olevan stationaarisia, satunnaisia, deterministisiä?

Ei paneuduta edellä esitettyihin pohdintoihin sen tarkemmin, pääasia on kuitenkin se, että pääsimme jossain määrin eroon trendin vaikutuksesta. Mainittakoon kuitenkin vielä kerran, että oleellista tässä laskennassa oli se, että kummankaan tuotteen kausivaihtelu ei seurannut mitään vuodenaikaa säännöllisesti. Jos näin kuitenkin päitisi tarkasteltavien kausikomponenttien suhteen, niin ristikorrelaation arvo ei olisi antanut oikeaa kuvaa tuotteiden välisestä suhteesta. Jos esimerkiksi molemmat tuotteet olisivat olleet kesäsesonki-tuotteita, niin ristikorrelaatio olisi varmasti ollut suuri vaikkei tuotteilla olisi mitään tekemistä keskenään. Korrelaatio laskettuna, wippii! Eiku…?

4) Yleisessä tapauksessa teoreettisessa mielessä lähinnä oikeaa laskentatapaa olisi laskea jäännössarjojen välinen ristikorrelaation arvo, olettaen, että aikasarjojen dekomponointi tuottaa jäännössarjat, jotka ovat likipitäen stationaarisia. Jäännöstermien välinen suurin ristikorrelaation arvo löytyy jälleen viiveellä 6kk ja on 0.39, mitäs hittoa? No jippohan piilee siinä, että tarkasteltavien tuotteiden kausivaihtelut ovat sen verran vahvat ja sidoksissa toisiinsa, että jos poistamme kausikomponentit alkuperäisistä sarjoista häviämme rutkasti informaatiota tuotteiden välisestä suhteesta, sillä kyseessä ei ollut tavanomainen vuodenajasta johtuva sarjojen kausivaihtelu.

5) Lasketaan vielä kerran ristikorrelaatioiden arvot de-trendatuille (kausi+jäännös) Lada Samaran ja sytytyspuolien aikasarjoille, päädymme ristikorrelaation arvoon 0.75 (viiveellä 6kk).

Kuten edellä esitetyt kohdat tuovat ilmi, ei korrelaation laskeminen aikasarjojen tapauksessa välttämättä ole aivan yksiselitteistä ja helppoa. Tässä esimerkin tapauksessa aikasarjojen välinen “todellinen” korrelaatio lienee 0.7 ja 0.92 välillä vai onko?

Olipa oikea korrelaation arvo mitä tahansa edellä mainittujen lukujen väliltä, voidaan varmasti todeta, että tuotteiden väliltä löytyy ilmeinen kausaalisuussuhde: autojen myynnin kasvu kasvattaa sytytyspuolien myyntiä ja tämähän on täysin loogista. Lisäksi voitanee olettaa, että viive auton myynnin ja sytytyspuolan rikkoutumisen välillä on keskimäärin 6kk.

 

Kuinka auton myynnin avulla voidaan ennustaa sytytyspuolien myyntiä lähitulevaisuuteen?

 

Edellisessä kohdassa saimme selville, että sytytyspuolien myynti (kysyntä) reagoi 6kk viiveellä autojen myyntiin. Tämän seurauksena voimme ennustaa historiatoteumien perusteella sytytyspuolien kysynnän 6kk päähän nykyhetkestä (melko tarkasti?) käyttämällä autojen myynnin toteumatietoa.

Seuraavassa kuvat ennusteista:

(Ylin) Ennusteet käyttämällä selittävänä muuttujana autojen myynnin aikasarjaa sellaisenaan,

(Keskellä) Ennusteet käyttämällä de-trendattua autojen myynnin aikasarjaa,

(Alin) Ennusteet käyttämällä selittävänä muuttujana auton myynnin kausivaihtelukomponenttia.

whole_timeseries

 

 

forecast_not_trend

 

 

decomp_only

Myöskään ennustamisessa ei ole yksiselitteistä käyttääkö selittävää aikasarjaa sellaisenaan vai esimerkiksi jotain sen dekomponoinnin tuottamaa komponenttiaikasarjaa. Ennusteet eroavat yllättävän paljon esimerkin tapauksessa. Ristiinvalidoinnin avulla voi tietysti tapauskohtaisesti katsoa mikä näistä vaihtoehdoista toimii parhaiten tarkastelavan ilmiön osalta, ongelmana ristiinvalidoinnissa on vain yleensä saatavilla oleva myyntihistoria.


23.10.2015 / Mika Laukkanen

Tiedolla johtamisen ratkaisut (analytiikka, raportointi, big data, tietovarastot, data science..) ovat teknologian osalta voimakkaassa murroksessa. Uusia innovaatisia tuotteita ja ratkaisuja tulee markkinoille rivakalla tahdilla.  Asiakkaalla on vaihtoehtoja enemmän kuin koskaan aiemmin, joten myös sopivan tuotteen valitseminen on tullut huomattavasti hankalammaksi.

Sen sijaan lupaukset em. ratkaisujen hyödyistä eivät ole kehittyneet ihan samassa tahdissa. Selailin taannoin erästä Data Mining kirjaa vuodelta 1999. Siinä oli jo suunnilleen samat lupaukset asiakasanalytiikan hyödyistä kuin mitä nytkin näkee markkinoilla. Isossa kuvassa dataa siis yhdistellään jatkossakin eri lähteistä johonkin purkkiin, josta sitä analysoidaan ja raportoidaan eteenpäin.

Teknisesti tämä kehittyy jatkuvasti helpommaksi ja halvemmaksi. Periaatteessa tämä tarjoaakin liiketoiminnalle loistavia mahdollisuuksia.

Teknologia kehittyy, mutta entäpä ihmiset ja organisaatiot?

Jotta nopea teknologinen kehitys tulisi hyödynnetyksi, niin myös ihmisten ja organisaatioiden tulisi kehittyä ajan hengessä. Realismia taitaa olla, että tämä kehitys ei ole kovin nopeaa. Ihmiset ja organisaatiot muuttuvat hitaasti ja usein vasta pakosta, esim. kriisien kautta. Vapaaehtoinen muutos ‘ihan-mukavassa-tilanteessa’ on harvinaista.

Millaiset muutokset sitten auttaisivat tiedolla johtamisessa? Tässä muutamia havaintoja.

  • Johdon olisi keskeistä ymmärtää miten tiedolla voidaan parantaa liiketoimintaa ja tulosta. Aika usein törmää siihen, että analytiikka tms. kehitysprojektia yritetään myydä ensiksi omalle johdolle sen sijaan, että se olisi sieltä lähtöisin. Kannettu vesi pysyy huonosti kaivossa.
  • Organisaatioiden siilomaisuus voi tuottaa hullunkurisia kannustimia. Esimerkiksi keskustelimme erään rahoituslaitoksen kanssa asiakaspoistuman torjunnasta. Teimme muutamia laskelmia ja spottasimme aika ison potentiaalisen hyödyn. Ongelma, asiakaspoistuman torjunta ei ollut (siiloissa) kenenkään tontilla. Myynti vastasi myynnistä, markkinointi markkinoinnista, talous taloudesta, jne. Monissa siiloissa siis pyöriteltiin asiakasdataa vain oman siilon näkövinkkelistä. Tällaisessa tilanteessa ‘Asiakas 360’ hankkeet jäävät kauaksi tavoitelluista hyödyistä. Eikä mikään teknologia korjaa ongelmaa.
  • Varsin harvassa yrityksessä on ammattilaisia analysoimassa tietoa. Ammattilaisuus tarkoittaa data-analyytikkoa (data scientist), jolla on vahva menetelmällinen työkalupakki analysoida tietoa tehokkaasti. Toisaalta ei ole mieltä kehittää tätä osa-aluetta ellei johto osaa ensiksi kysyä oikeita kysymyksiä, joihin data-analyytikko voi pureutua. Ilman relevantteja kysymyksiä data-analyytikon homma on lähinnä arvailua ja harhailua.
  • Saatavan tiedon (raportti, analyysi, mittari, tms.) pitäisi johtaa entistä useammin toimintaan ja sen mittaamiseen. Sehän on koko homman pointti. Ilman toimintaa on melko sama millä mittareilla johtaa.

Kokonaisuutena nämäkin asiat kehittyvät jatkuvasti parempaan suuntaan, joskin nopeudessa voisi kiriä. Ainakin näin konsultin näkövinkkelistä katsottuna.


11.10.2015 / Ville Niemijärvi

Asiakastiedon rikastamisen tavoitteena on ymmärtää paremmin asiakkaan käyttäytymistä. Ymmärtää ylipäätään keitä asiakkaamme ovat. Mitä he haluavat? Mikä liikuttaa heitä?

Kun ymmärtää tämän, voi vaikuttaa asiakkaisiin. Ja sitä kautta oman yrityksen menestykseen.

Edellisessä osassa toin esille neljä keinoa rikastaa yrityksen asiakastietoa:

  1. Hyödynnä monipuolisesti jo olemassaolevia tietolähteitä
  2. Osta tai kerää 3. osapuolelta dataa (esim. Trafi, VRK, Tilastokeskus, Asiakastieto)
  3. Kerää suoraan asiakkailta itseltään
  4. Johda ja sovella pienemmästä joukosta kerättyä tarkempaa tietoa koko asiakasjoukolle

Pureudutaan tässä kirjoituksessa ensimmäiseen kohtaan ja avataan mitä tämä tarkoittaa käytännössä. Taustalla tässä on pari tosielämän analytiikkacasea, jossa lähtökohdat analytiikalle oli varsin kehnot mutta dataa rikastamalla pääsimme aika hyviin tuloksiin.

Näitä kokemuksia voi hyödyntää myös ihan perinteisessä raportoinnissa, useat esitetyt mittarit ovat sellaisia, jotka pitäisi olla jokaisen yrityksen seurannassa. Teki edistynyttä analytiikkaa tai ei.

1. Hyödynnä monipuolisesti jo olemassaolevia tietolähteitä

Ehdottomasti paras tietolähde asiakastiedon rikastamisessa on asiakkaan oma käyttäytyminen. Eli ostohistoria. Tämä tieto löytyy toimialasta riippuen laskutus- tai kassajärjestelmästä (POS, verkkokauppa), tilausjärjestelmästä (esim. mediatalojen lehtitilaukset) ja/tai ERP-järjestelmästä.

Ostohistoria on lahjomaton. Useimmat meistä ovat kysyttäessä luontoa rakastavia luomuilijoita, mutta kaupan kassalla tiskille eksyykin tehotuotettua pollea, potkaa ja bisseä.

Tiedot myös vanhenevat. Esimerkiksi kanta-asiakkaaksi liittyessä asiakkailta kysytyt tiedot eivät ole välttämättä ajantasalla vuoden päästä eikä asiakkaita ole helppo saada päivittämään niitä.

Ostokäyttäytyminen kertookin paljon helpommin ja totuudenmukaisemmin:

  • milloin asiakas ostaa (kellonaika, viikonpäivä, ostojen tiheys)
  • mitä hän ostaa (mitä tuoteryhmiä tai palveluita hän käyttää)
  • missä hän asioi (missä liikkeissä tai kanavissa)
  • kuinka kauan hän on ollut asiakas
  • kuinka suurilla määrillä hän ostaa (keskiostos, montako tuotetta ostoskorissa…)

Ja näistä tiedoista voidaan päätellä se olennainen: miksi hän käyttäytyy näin.

Otetaan seuraavaksi käytännön esimerkki valottamaan asiaa.

1.1 Sata tietoa, joista kaksi käyttökelpoista.

Lähdimme tekemään analytiikkaprojektia asiakkaan kanssa, tarkoituksena segmentoida kuluttajia parempaa kohdennettua markkinointia varten.

Aluksi kaikki näytti hyvältä, asiakasdataa oli paljon. CRM:stä löytyi asiakkaista lähes toista sataa muuttujaa. Asiakkaiden itse syöttämiä tietoja.

Hyvin nopea datan esianalyysi paljasti kuitenkin, että suurin osa oli roskaa. Datan täyttöaste oli useimmissa tiedoissa 0-20% luokkaa. Täysin käyttökelvotonta analytiikan kannalta.

Data oli myös virheellistä. Asiakkaat olivat saaneet käyttää pitkälti vapaita tekstikenttiä joten Helsingin kaupungista löytyi jo edellisessä kirjoituksessa mainitsemani 30 eri kirjoitustapaa. Osoitetiedot olivatkin enimmäkseen turhia.

Asiakastiedot lähtötilanne

Ainoastaan nimi ja postinumero olivat valideja.

Kuva ohessa näyttää tilanteen CRM:n asiakastaulussa. Vihreät laatikot kuvaavat eheää dataa, punaiset virheellistä.

Harmaat kuvaa sitä, että dataa ei ollut saatavilla eli asiakkaat eivät olleet syöttäneet tietoja. Analytiikassa, oli kyseessä segmentointi tai luokitteluongelma kuten poistuma-/tai lisämyyntimallinnus, ei datalla tee juuri mitään jos täyttöaste on alle 70-80%.

Eli lopputulemana päädyimme ottamaan kovalla työllä rakennetusta CRM:stä kaksi tietoa: asiakkaan nimen ja postinumeron.

Näiden pohjalta lähdimme rakentamaan uutta asiakastietämystä.

Asiakastiedot lähtötilanne 2

 

1.2 RFM-analyysi ja vähän muuta

Seuraava steppi, joka on itselle vakiintunut tapa, on tehdä hieman sovellettuna nopea RFM-pisteytys. Tämä tarkoittaa kolmen tunnusluvun laskemista asiakkaille

  • Recency – Milloin viimeksi asiakas on ostanut?
  • Frequency – Kuinka usein asiakkaat ostavat (asiointitiheys)?
  • Monetary Value – Mikä on asiakkaan kokonaismyynti?

Kukin kolmesta mittarista voidaan pisteyttää esimerkiksi asteikolla 1-5 (tai voidaan painottaa jotakin osa-aluetta enemmän). Näin täydet pisteet parhaimmilla asiakkailla olisi 15 ja huonoimmat saisi 3.

Asiakkaan kokonaismyynnin (monetary value) aikojen alusta laskettuna on hieman huono mittari koska se väheksyy uusia asiakkaita. Usein otan tämän rinnalle tai tilalle asiakkaan keskimääräisen kuukausilaskutuksen. Tällöin uusi iso asiakas saa hyvät pisteet Monetary value -kohdassa.

Perinteisen RFM-mittariston lisäksi lasken aina myös seuraavat tunnusluvut:

  • keskiostos
  • asiakkuuden kesto
  • montako tuotetta ostoskorissa keskimäärin

Riippuen käyttötarkoituksesta, voidaan laskea helposti myös:

  • milloin asiakas ostaa (kellonaika, viikonpäivä, vuodenaika)
  • missä kanavassa (verkko, kivijalka, muu)

Pisteytys ei ole itseisarvo enkä juuri koskaan puhu RFM-analyysistä. Nämä nyt vain sattuvat olemaan hyviä mittareita, joita yritysten tulisi seurata ja nämä yhdistettynä muihin asiakastietoihin, voidaan päätellä paljon asiakkaasta (esim. vain kerran viikossa ruokakaupassa käyvät ja isoja keskiostoksia tekevät asiakkaat ovat useimmiten isoja perheitä ja kenties haja-asutusalueelta. Kauppaan lähdetään harvoin ja silloin sinne mennään tositarkoituksella.)

Kuva alla näyttää mitä tietoja saimme aikaan kun yhdistimme asiakkaan perustiedot (CRM:stä) ja kassatapahtumia eli asiakkaan todellisen ostokäyttäytymisen.

Suosittelen laskemaan nämä tunnusluvut omaan tietovarastoon tai raportointisovellukseen, vaikka syvempää analytiikkaa ei olisi tarkoitus tehdäkään. Nämä tunnusluvut saadaan esimerkiksi vähittäiskaupan osalta suoraan sieltä kuittirivitason tiedoista tai laskuriveiltä joten kyse on yhdestä tietokannan taulusta ja ehkä 1/2h työstä.

Asiakastiedon rikastaminen RFM Analyysi

 

1.3 Tuotetiedot, maantieteellinen sijainti

Se, mitä tuotteita asiakas ostaa, voi olla ensiarvoisen tärkeää. Etenkin jos haluat tehdä kohdennettua markkinointia tai lisämyyntiä ja haluat, että viestisi osuu maaliin.

Seuraavaksi otimmekin mukaan yrityksen tuotehierarkian ja liitimme sen ostohistoriaan. Täältä pystyimme päättelemään mitä tuoteryhmiä tai palveluita asiakas todella käyttää.

Jos kyseessä olisi urheiluvälinekauppa, näkisimme heti mitä lajia asiakas todennäköisesti harrastaa. Tai jos kyseessä on kuntosaliketju, näkisimme onko hän enemmän yksinäinen kuntosalipuurtaja vai tykkääkö käydä ryhmätunneilla. Ruokakaupan osalta näemme suosiiko asiakas luomua, kotimaisia tuotteita, kalliimpia ja laadukkaampia brändejä vai onko hän tarkan markan kuluttaja?

Tuotetasolla ostosten perusteella asiakastiedon rikastaminen vaatii päätöksiä: kuinka paljon asiakkaan pitää ostaa tuotetta X, ennen kuin uskallamme luokitella hänet tuotteen X kuluttajaksi? Tässä vaiheessa tarvitaan sitä kauppiaan tarkkaa nenään ja kokemusta asiakkaista.

Tuotetietojen ohella olennainen tieto on maantieteellinen sijainti. Asiakkaan kaupunki on OK mutta omien kokemusten mukaan ei sisällä kovin paljoa ns. selitysvoimaa. Parempi tieto voi olla esim. etäisyys yrityksen toimipisteestä tai jaottelu maaseutu vs. kaupunki. Se, asuuko kuluttaja Kouvolassa vai Kotkassa, ei ole juuri merkityksellistä mutta se asuuko hän keskellä metsää vai keskustassa voi olla todella merkityksellistä.

Kuva alla näyttää mitä tietoja meillä on kasassa kun haemme ostohistoriasta mitä tuotteita asiakas on ostanut. Tässä esimerkissä haluamme vain tiedon, kuluttaako asiakas tiettyä meille strategisesti tärkeää tuoteryhmää vai ei.

Asiakastiedon rikastaminen tuotetiedoilla

1.4 Markkinointiaktiviteetit, asiakaspalvelu ja muut

Jos lopullisena tavoitteena on tehdä parempaa kohdennettua markkinointia, kannattaa asiakastietoa rikastaa markkinointiaktiviteeteillä. Suoramarkkinakirjeet, niin printit, emailit ja sms-viestit kuin myös puhelinsoitot ja f2f kontaktit ovat tällaisia.

Näiden perusteella päättelimme, reagoiko asiakas markkinointiviestiin ja millaiseen viestiin. Jos asiakas sai torstaina emailissa mainoskirjeen ja hän ei ollut ostanut sunnuntaihin mennessä, voidaan olettaa, että mainos ei osunut kohteeseen.

Jälleen kerran vaaditaan päätöksiä: miten päätellään, että toimiiko markkinointiviesti? Kuinka monta kertaa asiakkaan pitää olla ostamatta tai ostaa viestin saatua, että voimme sanoa hänen reagoivan siihen positiivisesti tai negatiivisesti? Mikä saa olla viive?

Päivittäistavarakaupassa olettaisin, että lehtimainoksen nähtyä asiakas ostaa samana tai seuraavana päivänä.

Markkinointiponnistelujen lisäksi luonnollisesti asiakaspalvelu ja palvelun laatu ylipäätään kiinnostaa. Esimerkiksi:

  • Kuinka monta kertaa asiakas on ottanut yhteyttä aspaan?
  • Kuinka monta reklamaatioita asiakas on tehnyt?
  • Kuinka monta tuotepalautusta asiakas on tehnyt?
  • Onko asiakkaan palvelussa ollut katkoja (esim. teleoperaattorit)?

Tänä päivänä on myös trendikästä puhua NPS:stä eli Net-promoter-score:sta. Kyseessä on asiakastyytyväisyyttä kuvaava mittari, yksi lukuarvo, joka kertoo: Kuinka todennäköisesti asiakas suosittelisi yrityksen palvelua muille?

Olen kuullut palvovia kommentteja tästä maagisesta mittarista. Kuulemma juuri mitään muuta ei yritys tarvitsekaan.

Ja ei siinä mitään, kyseessä on varmasti hyvä mittari ja otetaan se analyysiin mukaan. Itse näen sen yhdeksi pieneksi osaksi koko asiakastietämystä.

Alla kuvassa näkyy kooste tiedoista mitä olemme saaneet aikaan yhdistämällä CRM-dataa, laskutusdataa eli ostohistoriaa ja tuotetietoja sekä markkinoinnin aktiviteetteja.

Asiakastiedon rikastaminen markkinoinnin tiedoilla

Olemme tulleet valtavan harppauksen eteenpäin mutta varsin pienellä työllä. Asiakastietämys on rikastunut 2 sarakkeesta (nimi + postinumero) useisiin kymmeniin, laadukkaisiin ja todenmukaisiin tietoihin asiakkaista.

Jo tällaisenaan voidaan puhua todella rikkaasta asiakastietämyksestä, jonka perusteella asiakkuuksien johtaminen ja esimerkiksi kampanjoiden älykkäämpi suunnittelu on mahdollista.

Mutta todellisuudessa olemma vasta aluissa. Tässä käytiin alussa esitetyistä neljästä kohdasta vasta ensimmäinen. Paras osa on vielä tulematta. Niistä lisää seuraavalla kerralla, pysy kuulolla.

 

 


25.09.2015 / Ville Niemijärvi

1236296_713535151996903_1161666421_nKonttoriin tarvittiin uudet työtuolit. Mielestäni kelvot pilkkijakkarat eivät kuitenkaan uusille työntekijöille kelvanneet joten piti kääntyä tuolikaupan puoleen. Sovin puhelimessa tilauksen Kuopion Martela Outletin lupsakan myyjän kanssa perjantaina. Myyjä lupasi, että tuolit ovat Jyväskylän toimistollamme “ehkä keskiviikkona”.

Tuolit saapuivat heti viikonlopun jälkeen maanantaina ennen puolta päivää. Priimakunnossa ja pari päivää ennen luvattua aikaa.

Martelan palvelu oli häkellyttävän hyvää ja muistin paasata siitä tutuille.


Kesällä olin ruokakaupassa ja pyysin kalatiskillä kaveria fileoimaan kuhan. Ajattelin, että siinä kalamestarin touhutessa, ehdin käydä hoitamassa muita asioita leipä- ja maitohyllyillä. En ehtinyt liikahtaa paikoiltani kun veitsimestari teki noin neljä ranneliikettä ja kalaparka oli jo irroitettu elimistään ja nahoistaan.  Noin 30 sekunnin kuluttua tilauksestani sain kuhafileet paketissa ja saisikoollamuuta siihen päälle. Olin vähällä alkaa aplodeeraamaan ammattitaitoisesta suorituksesta mutta maltoin suomalaisesti mieleni ja nyökkäsin hyväksyvästi sanomatta mitään.


Tovi sitten sai oma kyltymätön egoni silkkihansikkaan hyväilyä kun asiakkaalta satoi kehuja hoitamastani projektista. Otin tietenkin kiitokset vastaan hyvilläni sillä hanke sujui oikein mainosti. Mutta myöhemmin mietin, että projekti oli omalta osaltani oikeastaan rutiinisuoritus, ei mitenkään normaalista poikkeava. En tehnyt pitkää päivää, en venynyt urosuorituksiin. Toki tarjosin asiakkaalle käyttöön parhaan osaamiseni (oli siellä ehkä joku kollega myös mukana…), pääsimme maaliin aikataulussa, budjetissa ja tulokset olivat sitä mitä tilattiin. Siinä se. Tein työni ja sen mikä sovittiin, en enempää.

Huonosta palvelusta on tullut standardi

Onko huonosta palvelusta tullut standardi, johon verrataan kaikkea (palvelu)työtä?

Asiakkaat taputtaa niin kuin hassenmatkalaiset charter-lentojen laskeutumisen jälkeen Kanariansaarille konsanaan aina kun ammattilainen tekee työnsä?

Jos normaalilla suorituksella erottuu joukosta ja lyö asiakkaan ällikällä, minkälaiseen tulokseen mahtaa päästä kun oikein yrittää?

Älykäs yritys = yritys joka tekee työnsä?

Vaikka saan leipäni liiketoiminnan analytiikasta ja “tiedolla johtamisesta”, niin ollaan rehellisiä:

Iso osa yrityksistä voisi heittää balanced scorecardit, performance managementit, bigdatat ja business intelligencet hetkeksi sivuun ja keskittyä tekemään vain työnsä. Löytämään sen ytimen, mikä määrittää heidän olemassaolon.

Tarkoitan sitä, että kaupassa on myyjiä, jotka tuntevat tuotteet ja osaavat myydä niitä. Kalamestari osaa käsitellä kalaa, asiakaspalvelu vastaa puhelimeen ripeästi, tavarat ja ihmiset liikkuu ajallaan ja ehjänä perille ja jopa IT-projektipäällikkö vie projektin maaliin edes joskus oikeaan aikaan ja budjetissa.

Kun perustat on kunnossa, on aika ottaa älykkäämmät vipstaakit käyttöön.


20.08.2015 / Ville Niemijärvi

Mitä tietoja tarvitset asiakkaasta, jotta voit tehdä todellista ennakoivaa analytiikkaa ja sitä myöten esimerkiksi kohdennettua markkinointia tai parempaa ristiinmyyntiä?  Miten rikastaa dataa ja saada siitä enemmän irti? Tässä ja seuraavassa kirjoituksessa käydään läpi arkipäivän ongelmia ja käytännön vinkkejä miten niitä on taklattu oikeissa analytiikkaprojekteissa.


Me tiedämme asiakkaistamme kaiken. Tai ainakin nimen. Ehkä.

Olemme tehneet vuosien varrella kymmeniä asiakaspoistuma-mallinnuksia, ristiinmyyntianalyysejä, asiakassegmentointeja, elinkaarimalleja tai sitten vain stalkanneet kuluttajia. Lähes kaikissa analytiikkahankkeissa, yhtenä suurimpana kompastuskivenä on ollut puutteellinen asiakasdata.

“Meillä on yli 300 000 kanta-asiakasta, tiedämme heistä lähes kaiken. Meillä on kerättynä lähes 100 muuttujaa.”

Yritysten mielestä heidän oma asiakastietonsa on tietenkin priimaa. Asiakkaita on paljon, heistä kerätty tieto on validia ja erinäisiä taustamuuttujia on tukuttain. He tuntevat käytännössä puoli-Suomea tai ainakin koko kirkonkylän.

Alla oleva kuva näyttää asiakastietojärjestelmän siten kuten yritys itse sen kokee. Tiedot ovat tip top täydellisesti täytettyjä ja data eheää.

Asiakassegmentointi_1_Louhia
Miten yritys uskoo asiakastietojen löytyvän järjestelmistä.

Sitten kun olemme saaneet käsiimme asiakasdatan esimerkiksi CRM-järjestelmästä, on totuus hieman toinen.

Alla totuudenmukaisempi kuva.

Asiakassegmentointi_2_Louhia
Miten asiakastiedot todella näkyvät.

Yleisimpiä puutteita datassa:

  • data on harvaa. Osa muuttujista on täytetty 1-5%:lle asiakkaista
  • virheellisiä merkkejä. Esimerkiksi numerokenttään (ikä) on tuotu kirjaimia
  • vapaat tekstikentät ovat mahdollistaneet kymmeniä variaatioita esimeriksi kaupunkien nimistä
  • tietoa ei ole vain kerätty, asiakastiedolle ei ole nähty arvoa koska sitä ei ole tarvittu päivittäisessä toiminnassa

Olemme olleet hankkeessa, jossa asiakastiedoista löytyi noin 30 eri tapaa kirjoittaa Helsinki. Näimme kaikki variaatiot kuten Stadi, snadi, hesa, Helzinki, Hell, isokirkko…

Lähes 50:stä asiakkaasta kerätystä taustamuuttujasta ehkä kaksi tai kolme oli relevantteja analyysin kannalta. Mutta rikastamalla asiakasdataa, saimme lopulta luotua hyvän asiakasymmärryksen segmentointia ja jatkotoimia kuten kohdennettua markkinointia varten.

Asiakastiedon rikastaminen vaatii usein muutosta liiketoimintaprosesseissa

Monilla yrityksillä tilanne ei ole edes näin valoisa, koska mitään asiakastietoja ei systemaattisesti tallenneta. Monilta osin asiakkaista on kerätty talteen se olennainen: osoite tai puhelinnumero.

Tiedän kourallisen suomalaisia yrityksiä, joilla on satojatuhansia asiakkaita mutta he eivät pysty erottelemaan ketkä ovat yritysasiakkaita ja ketkä kuluttaja-asiakkaita. Valtaosa B2C yrityksistä eivät tiedä asiakkaiden sukupuolta tai ikää, monin paikoin erittäin relevantteja tietoja mallinnettaessa ja ennustettaessa asiakaskäyttäytymistä.

Asiakasanalytiikka usein lähteekin siitä, että yrityksen pitää muuttaa toimintaprosessejaan, alkaa systemaattisesti keräämään asiakastietoa. Joskus tietoa voidaan rikastaa olemassaolevista lähteistä helposti, joskus palaamme asiaan vuoden tai kahden päästä.

Miten rikastaa asiakasdataa?

Asiakastiedon rikastamiseen ja asiakasymmärryksen lisäämiseen on toisiaan täydentäviä vaihtoehtoja.

1.Hyödynnä monipuolisesti jo olemassaolevia tietolähteitä kuten:

– kassa-, verkkokauppa-, laskutus- ja tilausjärjestelmät (ostohistoria, ostokäyttäytyminen)
– asiakaspalautteet ja -kyselyt, aspa-järjestelmät (reklamaatiot, palautteet, NPS-rating)
– markkinointiaktiviteetit, kampanjadata
– asiakkaan perustiedot, CRM-järjestelmä

2. Osta tai kerää 3. osapuolelta dataa (esim. Trafi, VRK, Tilastokeskus, Asiakastieto)

– viranomaisten hallussa olevan datan osalta tämä on helpommin sanottu kuin tehty, johtuen lainsäädännöstä, tästä myöhemmin lisää

3. Kerää suoraan asiakkailta itseltään, esim.

– kanta-asiakasjärjelmään liittyessä
– erilaisin kilpailuin ja tapahtumin tai
– suorita kyselytutkimus (kartoita esim. mielipiteet, arvot, asenteet).
– koko asiakaskunnalle kyselyn teettäminen on usein liian kallista, jolloin joudut soveltamaan tuloksia lopulle populaatiolle (ks. alla)

4. Johda ja sovella pienemmästä joukosta kerättyä tarkempaa tietoa koko asiakasjoukolle

– vähän kuten vaaligallupeissa: muutama tuhat haastatellaan ja nämä tulokset sovelletaan koko kansalle
– olennaista, että haastatelluilla löytyy taustamuuttujia (esim. ikä, sukupuoli, alue), jotka löytyvät myös lopulta asiakaskunnalta.
– myös monissa analytiikan sovelluksissa (esim. asiakaspoistuma, ristiinmyynti) on kyse pienemmällä joukolla tehdystä (ennuste) mallista, jota sovelletaan loppuihin ja uusiin asiakkaisiin

Ensi alkuun monissa yrityksissä CRM-järjestelmän sisältö voi näyttää todella köyhältä. Mutta asiakasymmärrystä voi lisätä monella eri tapaa ja nämä eivät vaadi mitään poppakonsteja.

Yllä listattuihin keinoihin ja kokemuksiin pureudutaan seuraavassa osassa.


Pst. Asiakastietojen rikastamisesta ja laajemmin asiakkuuksien johtamisesta lisää Talentum Eventsin koulutuksessa: http://talentumevents.fi/asiakkuuksienjohtaminen