Kun dataa aletaan hyödyntämään liiketoiminnan päätöksenteossa ja optimoinnissa, on ratkaistavan ongelman määrittely eräs kehitysprosessin virhealtteimpia osia. Ongelma ja data määrittävät rakennettavan ratkaisun ja sen toiminnan. Tämän vuoksi dataa hyödyntäviin projekteihin saattaakin vaikuttaa ilmiö jota kutsun "saat mitä tilaat" -ongelmaksi.

Kuinka "saat mitä tilaat" -ongelma näyttäytyy?

Dataprojektien onnistumiseen vaikuttaa ilmiselvästi niissä hyödynnettävä data.

Jo kliseeksikin muodostuneet teesit datan laadun vaikutuksesta algoritmien toimintaan tuntuvat iskostuneen syvälle liiketoimintapäättäjien mieliin. Todellisuudessa  "datan laadukkuus" on kuitenkin monelle käsite, jota ei täysin ymmärretä. Kaikessa kompleksisuudessaan datan laadukkuuden kriteerit ovat selkeimpiä datan parissa työskenteleville ammattilaisille, jotka ymmärtävät mitä datalta pitää vaatia, ja mitä siltä voi odottaa. Nämä samat dataa ymmärtävät ammattilaiset saattavat kuitenkin olla sokeita toiselle dataprojektien kompastuskivelle - virheelliselle ongelmanmäärittelylle.

Kun vastaan kävelee oppikirjaesimerkki algoritmeillä ratkaistavasta ongelmasta, säntäävät jopa nämä samaiset ammattilaiset helposti notebookiensa ääreen. Pitäisikin pysähtyä miettimään jopa yksinkertaisilta kuulostavien tapausten edessä, onko ratkaistava ongelma valittu oikein. Vanha sanonta pitääkin siis paikkansa myös datan ammattilaisten keskuudessa: "jos ainoa työkalusi on vasara, näyttävät kaikki ongelmat nauloilta".

Esimerkki väärin määritellystä ongelmasta

Tarkastellaan kahta esimerkkitapausta. Molemmissa ratkotaan samaa haastetta: kuinka liiketoiminnan asiakasvaihtuvuus saataisiin vähenemään?

Kuvitteellinen keskustelu liiketoimintatiimin ja data science-tiimin välillä. Asiakaspoistuman ennustaminen on yleinen projekti, jossa "Saat mitä tilaat" -ongelma ilmenee.

Monet yritykset ovat yrittäneet ennustaa maksavien asiakkaiden vaihtuvuutta (churn / attrition). Usein ajatuksena on, että jos voimme tunnistaa asiakkaat jotka ovat vähentämässä tai lopettamassa palvelun käytön, voimme kohdistaa juuri heihin ennaltaehkäiseviä toimintoja, kuten esimerkiksi viestintää tai tarjouksia.

Asiakasvaihtuvuuden ennuste on juuri sellainen haaste, jonka ratkaisemista monet datatieteilijät odottavat kuola valuen! Alkuun se voikin kuulostaa hyödylliseltä ja kiinnostavalta tiedonhankinnalta, mutta projektin ongelmanasettelussa piilee kuitenkin vaarallinen ansa.

Jos analysoimme liiketoiminnan tarpeita hieman laajakatseisemmin, huomaamme, että ennustamisen sijaan lopullinen tavoite on itseasiassa asiakasvaihtuvuuden minimointi, ei vaihtuvuuden ennustaminen. Alkuperäinen ongelman määrittely ei siis osunut kerralla maaliin, vaan hätäisen rajauksen vuoksi lähdettiin ratkaisemaan oikopäätä aivan väärää asiaa.

Mutta mitä haittaa virheellisestä ongelman rajauksesta siis on? Mikäli asiakasvaihtuvuutta lähdetään minimoinnin sijaan ennustamaan, rakennettava malli oppii todennäköisesti tunnistamaan lähtemisvaarassa olevan käyttäjäryhmän, tietyssä mielessä tavoitteen mukaisesti. Samalla lähestymistapa luo kuitenkin merkittäviä ongelmia:

  1. Asiakkaiden vaihtumaa ennustava malli kertoo, että asiakkaat ovat vaarassa lähteä, mutta ei osaa suoraan sanoa, miksi.
    Mallin tuottama lopputulos yleistää kaikki lähtevät käyttäjät samaan kategoriaan, jolloin samassa luokassa on monella eri tavoin lähtemisvaarassa olevia käyttäjiä. Toisistaan poikkeavat asiakasryhmät tarvitsisivat erilaisia toimenpiteitä asiakassuhteen parantamiseksi, mutta malli tässä muodossaan ei mahdollista näiden erottamista toisistaan.

    Osuva esimerkki lähtemisvaaran väärästä luokittelusta ovat nukkuvat asiakkaat. Tämän ryhmän edustajat voivat olla esimerkiksi jonkin palvelun tilaajia, joilla tilaus juoksee odotetusti, eikä ongelmia ole esiintynyt. Asiakas ei ole ajatellut jatkuvasti juoksevaa laskua, saati tilauksen perumista. Ajatusleikkinä malli voisi datan pohjalta tulkita tällaisen passiivisuuden tyytymättömyyden merkiksi ja asettaa todellisuudessa hyvinvoivan asiakassuhteen virheellisesti vaaravyöhykkeelle. Pahimmassa tapauksessa yritys tarttuu toimeen ja käynnistää aktivoivana toimenpiteenä kohdistetun markkinointikampanjan, josta asiakas ärsyyntyy ja peruu koko palvelun - vaikka oli ollut siihen tähän saakka täysin tyytyväinen.
  2. Joidenkin asiakkaiden kohdalla malli toimii täsmälleen juuri kuten pitää, ja ennustaa lähdön vuorenvarmasti - eikä mitään ole tehtävissä. Osa asiakkaista saattaa nimittäin olla jo menetettyjä tapauksia, huolimatta siitä, kohdistetaanko heihin toimenpiteitä tai ei. Malli siis toimii, mutta oikeastaan minkäänlainen asiakkuuden hoito ei. Toimenpiteisiin kuluu turhaan rahaa, mutta tulosta ei synny.
  3. Kun mallia suunnitellaan, pohditaan usein minkälaisten signaalien perusteella käyttäjä voitaisiin luokitella "vaaravyöhykkeelle". Usein valitaan pelkästään käyttäjän aiheuttamat signaalit, kuten esimerkiski palvelun käytöstä syntyvät signaalit. Tämän kaltaista ongelmanasettelua ratkaisevien mallien suunnittelussa otetaan kuitenkin harvemmin huomioon palvelun puolelta käyttäjään kohdistetut toimenpiteet. Kun ennustemallia sitten aletaan hyödyntämään, analyysin perusteella suoritetut, asiakkaisiin kohdistuvat toimenpiteet saastuttavat datan. Oletetaan esimerkiksi, että kauppakassipalvelua tarjoavan verkkokaupan asiakaspalvelija käy läpi mallin tunnistamia lähtövaarassa olevia kanta-asiakkuuksia. Asiakaspalvelija huomaa, että osalla lähtövaarassa olleilla on ollut ongelmia toimituksissa, joten käännyttävänä toimena hän sujauttaa kaikille alennuskupongit. Tämän seurauksena asiakkaat jäävät palvelun käyttäjiksi, mutta malli ei tiedä mistä asiakkaiden kääntyminen johtuu. Kun malli seuraavan kerran uudelleenkoulutetaan uudella datalla, samankaltaiset tapaukset eivät enää luokitukaan samoin, koska mallin tietojen mukaan kuljetuksiin liittyvät ongelmat eivät aiheuttaneetkaan vaihtumaa.
Asiakasvaihtuvuutta ennustava malli kykenee tunnistamaan vaarassa olevat asiakkaat, mutta ei osaa kertoa, mitä asiakkaille pitäisi tehdä jotta vaihtuma vältetään

Kuinka "saat mitä tilaat" -ongelma käännetään eduksi?

Suunnittele ongelmaketju alusta loppuun saakka ja mieti minkä asian haluat lopulta saavuttaa

"Saat mitä tilaat" on paitsi dataprojektien jatkuva haaste, mutta myös niiden onnistunutta toteuttamista ohjaava perusluonne. Ongelman ja tavoitteden määrittely kantaa pitkälle.

Ratkaistavan ongelman muuttamisen lisäksi myös hyödyntämistapa muuttuu. Tämä voikin lopulta olla hankalin osuus upean algoritmin käyttöönotossa, sillä ihmisten on uskottava myös toimenpiteiden osalta koneen arvioon.

Ratkaistava ongelma tulisikin määritellä alusta alkaen siten, että se kuvaa haluttua lopputulemaa, eikä jotakin välivaihetta. Esimerkkitapauksessamme oikea ratkaisu olisikin siis rakentaa malli, joka ennustaa parasta mahdollista asiakassuhteen hoitotapaa, jonka avulla saadaan selville minkälaista kohtelua tyytyväiset ja tyytymättömät asiakkaat todellisuudessa kaipaavat. Ratkaistavan ongelman muuttamisen lisäksi myös hyödyntämistapa muuttuu. Tämä voikin lopulta olla hankalin osuus uuden upean algoritmin käyttöönotossa, sillä ihmisten on uskottava myös toimenpiteiden osalta koneen arvioon vaikka se tuntuisi intuitiivisesti väärältä.

Konkreettisesti katsottuna jo pienellä muutoksella ongelman määrittelyssä muutetaan koko tehtävän tuloksia merkittävästi. Esimerkkitapauksessamme kahden eri ongelmankuvauksen vertailu on melko helppoa; ensinnäkään emme enää pyri pelkästään koko asiakaskunnan binääriseen jakamiseen, vaan teemme personoituja päätöksiä eri asiakkaille.

Lisäksi siirrämme myös vaikutusten arvioinnin algoritmien pureksittavaksi sen sijaan, että vaivaisimme sillä ihmistä. Tietyissä tilanteissa voi olla mahdollista automatisoida myös tietyt asiakassuhteen hoitotavat samaan putkeen, jolloin tämä vähentää entisestään ihmisten työmäärää.

Ensimmäisen esimerkin yksi haaste oli, että asiakassuhteen hoitotoimenpiteet saastuttivat datan ja täten tuloksista tuli epäluotettavia. Tässä tapauksessa malli on kuitenkin luotu nimenomaan asiakassuhteen hoitamisen arviointiin, joten se oppii onnistuneista ja epäonnistuneista toimenpiteistä entistä paremmaksi ennustajaksi. Malli voikin siis arvioida erilaisten hoitotapojen vaikutusta suhteessa asiakkaaseen ja tunnistaa, mitkä toiminnot ovat kullekin asiakkaalle parhaimmat eri aikoina. Malli voi esimerkiksi tunnistaa, että useimpien asiakkaiden kohdalla oikea toimintamalli voi olla yksinkertaisesti jättää heidät rauhaan. Tähän aikaisempi malli ei pystynyt, ja saattoi esittää heidät virheellisesti lähtemisvaaraan kuuluviksi.

Saat mitä tilaat -ongelmaan on yksinkertainen ratkaisu: muuta tilaustasi.

Pähkinänkuoressa: kuinka "saan mitä tilaan" ja hyödyn siitä?

  1. ONGELMA. Käytä aikaa ongelman määrittelyyn ja varmenna, että olet ratkaisemassa oikeaa asiaa. Hyvänä työkaluna tähän toimii yksinkertainen vuokaavio, jolla määritellään tavoitteet, toiminta-alue, saatavissa oleva data ja toivottu lopputulos.
  2. DATA. Varmenna, että keräät tietoa asioista jotka liittyvät olennaisesti asiakassuhteeseen ja määrittelemiisi tavoitteisiin. Jos dataa ei ole vielä saatavilla, voiko sitä kerätä?
  3. TESTAA. Alussa testausta voidaan tehdä "paperilla". Hyvänä ohjeena on pohtia: "Auttaako tämä lopputulos suoraan alkuperäisen ongelman ratkaisussa?" Myös "kovia" malleja on mahdollista testata tuotannossa asti liiketoiminnan rinnalla ja usein sitä liikaa häiritsemättä.

Saat mitä tilaat -ongelmaan onkin siis yksinkertainen ratkaisu: jos projekti ei tuota haluttua lopputulosta, muuta tilaustasi. Esimerkissämme oli kyse asiakasvaihtuman minimoimisesta, mutta johtuen menetelmien luonteesta (olemassaolevan datan käyttö, metriikoiden optimointi) sama ongelma toistuu jossain muodossa lähes kaikissa algoritmisissa ratkaisuissa. Siksi on tärkeää tunnistaa hätiköidystä ongelman määrittelystä aiheutuva riski ja yrittää kiertää se.

Emblica on dataintensiivisiin sovelluksiin ja tekoälyyn keskittynyt teknologiayritys. Asiakkaitamme ovat mm. Sanoma, Uponor, Caruna ja Verohallinto. Emblica on 100% työntekijöidensä omistama.