06.02.2019

Asiakasdatan hyödyntämisen haasteet

Hei,

Mikä on asiakas? Montako asiakasta meillä on? Kuulostaa itsestään selvältä kysymykseltä, mutta hyvin moni yritys ei pysty vastaamaan tähän kunnolla. Tai eri henkilöt antavat eri vastauksen.

Nyt joku voi sanoa, että eikö asiakas ole se, jota laskutetaan? Voin sanoa tähän, että asia on huomattavasti monimutkaisempi.

Kerron nyt hieman hieman tästä niin monia organisaatioita piinaavasta haasteesta ja miten se voidaan ratkaista.

Määrityksen merkitys

Tiedonhallinnan kouluttajamme Chris Bradley sanoo usein ”Organizations can’t count”. Tällä hän tarkoittaa sitä, että kun esim. asiakas-käsitettä ei ole määritelty, emme voi laskea montako asiakasta meillä on.

Määrittelyjen puuttuminen tai sekavuus siis vaikeuttaa raportointia ja analyysejä. Kuinka monta liidiä konvertoituu asiakkaaksi tai mikä on kannattavin asiakassegmentti?

Merkittävä osa datan hyödyntämisestä globaalisti liittyy juuri asiakastiedon analysointiin on kyse sitten perinteisestä BI:stä tai tekoälystä. Itsekin autan suurasiakkaita juuri tässä problematiikassa.

Näinkin yksinkertainen asia kuin määritellä mikä on asiakas on todella haastavaa.

Käyn läpi tässä jotain käytännön esimerkkejä asiakasdatan analysointiin ja hyödyntämiseen liittyvistä haasteista.

Teleoperaattori

Teleoperaattoreilla on usein haasteita asiakasdatan hyödyntämisessä optimaalisella tavalla.

Teleoperaattorilla on henkilöasiakkaita ja kuluttaja-asiakkaita. Yrityksillä on myös liittymiä, ja monasti jollain voi olla työpaikan kautta liittymä ja sitten oma henkilökohtainen liittymä.

Henkilöasiakkaana perheenisällä tai -äidillä voi olla useita liittymiä lapsille. Lisäksi teleoperaattoreilla on muitakin palveluja kuten viihdepalvelut, taas yksi asiakasryhmä lisää.

On haastavaa määritellä näistä, kuka oikeastaan on asiakas tai ”vain” liittymän käyttäjä. Palaamme tähän hetken päästä.

Kuluttajabrändit

Kuluttajabrändit, kuten vaikka Coca-Cola, Saarioinen tai Volvo, myyvät tuotteensa tyypillisesti jälleenmyyjille, kuten vähittäiskaupalle. Eli heidän maksava asiakkaansa on vaikkapa Kesko tai vastaava.

Nämä yritykset ovat kuitenkin erittäin kiinnostuneita loppukäyttäjistä, eli henkilöistä jotka ostavat yrityksen tuotteen kaupasta. Miten heidät sitten määritellään, koska brändi ei myy kuluttajalle suoraan vaan jälleenmyyjän kautta?

Kuluttajabrändit kuitenkin markkinoivat tuotteitaan kuluttajille ja siksi mieltävät tavallaan heidät myös asiakkaiksi ja haluavat analysoida tätä dataa markkinoinnin yhteydessä. Kuka on potentiaalisin asiakassegmentti, kenelle markkinointi halutaan suunnata?

Juuri asiakkaan määritelmä herättää helposti jyrkkiä mielipiteitä, joiden sovitteleminen ei ole helppoa. Asiakkaista nimittäin puhuvat kaikki ja niistä ovat eri yksiköt kiinnostuneita. Eikä ihme, raha tulee yrityksiin asiakkailta.

Verkkopalvelu

Verkkopalvelussa, kuten vaikka verkkolehti tai verkkokauppa, on useita eri käyttäjäryhmiä, jotka usein myös mielletään asiakkaiksi. Meillä on verkkosivulla vierailijoita, jotka eivät ole vielä ostaneet mitään. Nämä ovat kuitenkin tärkeitä, jos haluamme myydä mainostilaa.

Sitten meillä on kirjautuneita käyttäjiä, joista meillä on enemmän tietoa, mutta hekään ei välttämättä ole ostavia asiakkaita. Sitten on ostavat asiakkaat, joka usein vaatii kirjautumisen.

Eräässä nettipalveluja tarjoavassa yrityksessä johdon kanssa väännettiin pitkään kättä siitä mikä on tilaus. Heillä on ilmaispalveluja ja maksullisia palveluja. Osa johdosta oli sitä mieltä, että ilmaispalvelun hankkiminen ei voi olla tilaus, koska euroja ei liiku.

Ilmaispalveluista vastaava johtaja oli eri mieltä, koska kyllähän ilmaispalvelu myös tilataan, eli täytetään verkossa tilauslomake jolla saadaan asiakkaan tiedot (vai onko se nyt sitten asiakas…).

Voi vaan kuvitella, kuinka monessa palaverissa oli keskusteltu tilauksista ja asiakkaista ja tarkoitettu eri asioita!  Kokonaisia hankkeita on käynnistetty siten, että eri osapuolilla olikin eri näkemykset.

Yrityspalvelut

Yrityspalveluissa, kuten rakennus-, logistiikka- tai muut teollisuustuotanto, haasteet asiakkaan määrittämisessä ovat hieman erilaisia.

Onko asiakas yritys, joka ostaa tuotteitamme tai yritysasiakkaan yhteyshenkilö?

Eräässä yrityksessä mietittiin, että erotetaanko nämä siten että kutsutaan yritysasiakasta asiakkuudeksi ja yhteyshenkilöä asiakkaaksi. Mutta tämäkään ei ollut mitenkään läpihuutojuttu.

Sitten meillä on prospekteja ja liidejä, jotka eivät ole vielä ostaneet, mutta heille on lähetetty tarjous tai he ovat muuten potentiaalisia tulevia asiakkaita.

Meillä on vielä avainasiakkaat erikseen, ja joidenkin kanssa on puitesopimus, muttei iso tilaus on vielä saamatta.

Täytyy myös miettiä, että onko sellainen yritys enää ”asiakas”, joka on ostanut viimeksi viisi vuotta sitten ja jossa yhteyshenkilö on vaihtunut.

Esimerkkejä on paljon lisää. Esimerkiksi terveydenhuollossa vastaanotossa asioiva henkilöä kutsutaan asiakkaaksi mutta hän muuttuukin potilaaksi lääkärin vastaanotolla.

Monialakonsernissa tai pankissa asiakkaille tarjotaan monia eri palveluja, mutta 360-näkemystä asiakkaasta ei voida laatia, koska asiakasdatat eivät ole synkassa.

Meidän täytyy myös miettiä GDRP:ää ja muita regulaatioita.

Miten asiaa sitten kannattaa lähteä ratkomaan?

Mieti asiakasta roolien kautta

Koska asiakkaan määritelmiä on niin monia, suosittelen, että lähdetään liikkeelle hiukan alempaa, käsitteistä jotka ovat selkeämpiä ja neutraalimpeja.

Asiakkaan kohdalla lähdetään liikkeelle mallintamalla ensin käsitteitä organisaatio ja henkilö.

Teleoperaattorin tapauksessa osa henkilöistä on maksavia liittymän omistajia, osa perheenjäsenenä, vain nimellä mainittuna liittymän käyttäjänä. Osalla yksityishenkilöistä on lisäksi tärkeä rooli yrityksen liittymien yhteyshenkilönä. Ja osa on vain prospekteja.

Toisin sanoen henkilöillä ja organisaatioilla on yhteyksiä  meidän palveluihimme. Niillä on esim. sopimuksia liittyen meidän tuotteisiin, kuten liittymäsopimuksia, vuokrasopimuksia tai vaikka vakuutussopimuksia, jos olemme vakuutusyhtiö.

Kannattaa siis lähteä mallintamaan henkilöitä, ja heidän eri roolejaan suhteessa tuotteisiin ja palveluihin. Tai vastaavasti organisaatiota.

Tämän jälkeen voimme määritellä kriteerit eri rooleille, eli esimerkiksi avainasiakkaalle pitää olla tietyt yhteydet yritykseemme, jotta hänet voi luokitella kuuluvan tiettyy rooliin.

Henkilön rooli tilaukseen voi olla voi olla juuri esim ”tilaaja”. Saamme näin aikaiseksi tietyt säännöt, eli mikä tekee henkilöstä asiakkaan (esim juuri tilaus).

Asiakas-määritelmä alkaa hahmottua juuri edellä mainittujen roolien ja yhteyksien kautta. Kun ne on selvitetty, on liiketoiminnan tehtävä määritellä, mitä yhteyksiä on oltava, jotta henkilö tai organisaatio lasketaan asiakkaaksi.

Teleoperaattori saattaa päättää, että henkilö, jolla on liittymän omistajan rooli, on asiakas mutta henkilö jolla on liittymän käyttäjän rooli ei ole (tässä siis vain esimerkkinä).

Voi olla että tarvitaan asiakas-tasoa tarkempaa määrittelyä, esimerkiksi tilaaja-asiakas, maksava-asiakas.

Olen tätä menettelyä hyväksi käyttäen onnistunut ratkaisemaan hyvin monta kinkkistä asiakadatan hyödyntäminen haastetta, että olen aika vakuuttunut sen toimivuudesta.

Nyt kuitenkin jollain lukijalla saatta herätä kysymys, miksi tämä on niin tärkeää? Eikö tämä kuulosta hiusten halkomista tai turhan teoreettiselta? Miksi tämä on välttämätöntä asiakasdatan analysoinnin kannalta?

Datat sijaitsevat tietokannoissa

Lopulta asiakasdatan hyvä hallinta kulminoituu siihen, mitä asiakasdataa löytyy, ja missä rakenteissa se on tietojärjestelmien tai tietovaraston tietokannoissa.

Nyt kun meillä on ensin mallinnettu henkilöt, organisaatiot, yhteydet ja roolit sekä mietitty asiakkaan määritelmä, voimme tarkistaa saammeko tiedot ulos siinä muodossa kuin liiketoiminta haluaa tai onko kaikkia tarvittavia tietoja vielä tallennettu.

Käsitemallin ohjaamana voimme muuttaa tietokantojen sisältöä ja rakennetta liiketoiminnan näkemyksiä vastaavaksi. Liiketoiminnan näkemys asiakasdatasta ja rakenteista heijastuu tietokantoihin saakka!

Lopullinen hyöty on tietysti se, että nyt voidaan toteuttaa asiakastietojen haut, raportointi ja analysointi liiketoiminnan määritysten mukaan. Nyt tiedämme ja ymmärrämme montako asiakasta meillä on ja voimme toteuttaa monimutkaisempaa analytiikkaa.

Koko tämän harjoituksen tekninen toteutus liittyy siis juuri tietokantojen säätämiseen siten, että saamme datat hyödynnettyä.

Käsite- ja tietomallinnus

Se menetelmä mistä puhuin roolien yhteydessä, on käsite- ja tietomallinnus, joka on ylivoimaisesti paras työkalu juuri tähän.

Mallinnus on parasta tehdä liiketoiminnan kanssa, koska vain heillä on tarvittava substanssiosaaminen jota tarvitaan määrityksiä varten (käsitemäärittelyt, roolit, yhteydet).

Harjoituksen myötä olemme rakentaneet sillan liiketoiminnan, analyytikon ja IT-osaajan välille. Yhteinen kieli on löytynyt!

Ja edellisen lisäksi mallinnus rakentaa sillan käsitemallista tietokantoihin saakka. Mikä muu menetelmä on näin ilmaisuvoimainen?

Mutta mallinnusta pidetään usein liikaa aikaa vievänä ja vaikeana. Liiketoiminnan aika on yhä enemmän kortilla.

Juuri näistä syistä tarvitaan uutta kehitystä mallinnuksessa. Olemme kehittäneet Hovi Data Frameworkin (HDF), jonka avulla mallinnuksessa päästään nopeasti eteenpäin. Nyt sille näyttää olevan todella kova kysyntä. Uskon tämän johtuvan siitä, että ongelmat asiakasdatan analysoinnissa voivat olla hyvin krittisiä.

Ja siitä olen iloinen, että tämä liiketoiminnan edustajat ovat mielellään mukana tässä työssä.

Ellie – viedään homma uudelle tasolle

On erittäin tärkeää, että mallinnuksen tulokset dokumentoidaan, ts. käsittelyjen määrittelyt ja riippuvuuksien kuvaukset tallentuvat siten, että niihin on helppo palata milloin tahansa myöhemmin.

Dokumentointi on tärkeää tietovaraston toteuttajalle, mutta hyvin tärkeää myös datan kuluttajille, kuten Data Scientisteille ja analyytikoille. Datatuotteiden ja dashboardien rakentaminen helpottuu merkittävästi, kun käsitemallista löytyy määritelmät ja käytettävissä olevat tietojen väliset yhteydet.

Ongelmana itsellänikin on ollut, että fläpillä tehtyjä käsitemalleja on hankala jaella asianosaisille.

Jossain vaiheessa ne hukkuvat. Käsitemäärityksiä ei löydykään kun niitä tarvittaisiin. Tietokannan suunnitteluun tarkoitetut mallinnusvälineet ovat liian teknisiä ja aika harvalla niitä on asennettuna läppärillä.

Juuri tätä varten olemme kehittäneet mallinnustyökalumme Ellien. Selainpohjaisena käsitemallit ja määritelmät on helppo ottaa esille milloin vain ja jakaa katseluoikeuksia muille – ei siis asennuksia.

Se sopii hyvin myös etämallinnuksiin: samaa dokumentoitua mallia voi katsella päivittää useampi samaan aikaan.

Elliestä tulee ihan lähiaikoina omat nettisivut ja Johannes kirjoittaa siitä lisää myöhemmin.

Meillä on muutenkin todella mielenkiintoisen kuviot menossa Ellien suhteen.

Olemme esimerkiksi juuri integroimassa sitä asiakkaan pyynnöstä WhereScape- nimiseen tietovaraston automatisaatiotyökaluun. Tämä on tietysti vain tekninen yksityiskohta niille, jotka ponnistelevat tietovarasto-, alusta ratkaisujen kanssa.

On ollut ilo huomata, kuinka asiakkaamme todella pitävät Ellien käytöstä ja eivät enää luopuisi siitä – sen verran se tekee elämää helpommaksi.

Oma mallinnustyöni liiketoiminnan kanssa on nopeutunut HDF-menetelmän ja Ellie -mallinnustyökalun ansiosta arvioita 40%.

Samassa ajassa saadaan siis enemmän selkeitä ja valmiimpia malleja sekä aiempaa paljon pidemmälle meneviä käsitteiden ja attribuuttien määrittelyjä. Tätä juuri tarvitaan, nopeampaa, helpompaa ja selkeämpää mallinnusta!

Ystävällisin terveisin,

Ari Hovi

Ps. Nyt olisi jälleen Data Vault 2.0 Sertifiointikoulutus tarjolla!

Data Vault 2.0 Bootcamp + Certification – 12.03.2019–14.03.2019

Data Vault 2.0 on nyt erittäin suosittu menetelmä tietovarastojen-, ja alustojen toteutuksissa. Kurssille otetaan vain rajattu määrä osallistujia, joten varaa paikkasi nopeasti.

Lisätiedot ja ilmoittautuminen tästä

Saattaisit olla kiinnostunut myös näistä

Lähestymistapoja dataosaamisen kehittämiseen

Lue lisää

Tiedon elinkaari ja tiedon synty

Lue lisää

Tiedon elinkaari ja tiedonhallinta

Lue lisää