Useimmat tiedolla johtamiseen (BI, AI, DW) liittyvät projektit lähtevät liikkeelle liiketoiminnan tarpeista ja siten business casen määrittelyllä. Aika usein tämä vaihe kuitenkin jää köykäiseksi harjoitukseksi, jonka seurauksena projekteja aloitetaan puutteellisin tiedoin.
Tässä kirjoituksessa käyn esimerkin kautta lävitse yhden tavan toteuttaa business casen määrittely.
Esimerkkinä business casesta on asiakaspoistuman torjunta vakuutusyhtiössä, vakuutuslajin XYZ osalta.
Vaihe 1 – tiedonkeruu
Ensimmäisen vaiheen tehtävänä on kerätä mahdollisimman kattavasti tietoa ko. business casesta. Tietoja voidaan kerätä sekä sisäisistä (liiketoiminnan asiantuntijat, raportointi,..) että ulkoisista (toimialakohtaiset raportit, avoin data…) lähteistä.
Vakuutusyhtiön asiakaspoistumaan liittyen kerättävää tietoa voisi olla esimerkiksi:
- Kasvaako tai pieneneekö markkina kokonaisuutena?
- Miten pärjätään suhteessa kilpailijoihin?
- Onko tullut uutta suoraa tai epäsuoraa kilpailua?
- Mikä on ollut poistumaprosentti viimeisen 5 vuoden aikana?
- Paljonko on poistuman euromääräinen arvo?
- Paras arvio luonnollisen poistuman (esim. ei tarvetta) ja estettävissä olevan poistuman jakautumisesta?
- Onko poistumaan tullut isoja muutoksia? Miksi?
- Mitä poistuman syitä on tunnistettu?
- Millaisia toimenpiteitä on tehty poistuman estämiseksi?
- Miten tehokkaita tehdyt toimenpiteet ovat olleet?
- Kenen vastuulla on asiakaspoistuman torjunta?
Hieman teknisempiä kysymyksiä voisivat olla:
- Miten poistumaprosentti on laskettu, onko laskenta luotettava ja kestää yli vuosien vertailun?
- Millaista dataa ja miten pitkältä ajalta on saatavissa liittyen asiakkaisiin?
- Onko datassa laatuongelmia, jotka tulisi huomioida eri vuosia vertailtaessa tai muuten vaan?
- Onko data integroitavissa eri järjestelmien välillä (esim. tietovarasto voi olla jo olemassa)?
- Onko tulevaisuudessa tiedossa muutoksia tietojärjestelmiin tai prosesseihin, jotka vaikuttavat poistuman mittaamiseen?
Ensimmäinen vaihe on siis tiedon keräämistä ja sen perusteella tehtävää kvalitatiivista analyysia, jonka perusteella pyritään saamaan mahdollisimman kattava käsitys business casesta.
Tässä vaiheessa voidaan jo tulla siihenkin tulokseen, että ko. casen osalta ei kannata aloittaa BI/AI/DW projektia. Tällainen tilanne oli taannoin, kun asiakkaalla oli datan luokitteluperusteet muuttumassa, joka teki vanhan ja uuden datan vertailukelvottomaksi.
Vaihe 2 – ongelman purkaminen osiin
Seuraavaksi hajoitetaan tunnistettu business case loogisiin osiin, joka helpottaa analysointia ja ratkaisujen löytämistä.
Esimerkin XYZ vakuutuslajin poistumaksi on tunnistettu 10% ja siitä muodostetaan seuraava puurakenne, perustuen vaiheen 1 aikana kerättyyn tietoon.
Nyt kun haluamme vähentää asiakaspoistumaa, niin emme tässä analyysissa keskity luonnollisen poistuman boxiin, koska siihen emme voi vaikuttaa. Tosin siitä voisi muodostaa oman business casen, esim. ideana tarjota toisenlaisia vakuutuksia.
Esimerkin analyysi voisi syventyä seuraavalla tavalla.
Nyt olemme päässeet tilanteeseen, jossa estettävissä oleva poistuma on jaettu loogisiin kokonaisuuksiin, joita voidaan analysoida erikseen ja löytää niihin omia ratkaisumalleja.
Vaihe 3 – ratkaisujen etsiminen
Jatketaan siis edellisen kuvan perusteella.
Haaste: Parempi tarjous kilpailijalta
Mikäli asiakas on saanut kilpailijalta paremman tarjouksen, niin se johtaa kahteen eri vaihtoehtoon.
- Asiakas kysyy meiltä kilpailevaa tarjousta, johon voimme vastatata paremmalla, yhtä hyvällä tai heikommalla tarjouksella.
- Mikäli asiakas irtisanoutuu kysymättä meiltä tarjousta, niin voimme silti tehdä aiempaa paremman ehdotuksen tai olla tekemättä mitään.
Mikäli tässä valitaan aktiivisia keinoja, niin ne ovat relevantteja poistumantorjunnan kannalta. Tässä blogissa ei mennä tämän asian suhteen pidemmälle. Joka tapauksessa näistä kaikista toimenpiteistä on mahdollista kerätä myös dataa, jota voidaan hyödyntää jatkossa, jotta tiedetään esim. mitkä toimet ovat tehokkaita ja mitkä eivät.
Haaste: Tyytymätön
Tiedetään siis, että meillä on asiakkaita, jotka eivät ole ihan tyytyväisiä ja siten potentiaalisia lähtijöitä. Käytännön haaste on, että asiakkaita on paljon eikä missään tietojärjestelmän kentässä lue "tyytymätön" tai "miksi on tyytymätön", eli mikä avuksi?
Vedetään kani hatusta ja todetaan, että hyödynnetään koneoppimista, jonka avulla voidaan
- datasta laskea eri tekijöiden vaikutus poistumaan
- ennustaa poistuvia asiakkaita (scoret)
Koneoppimisen kautta saatavat tulokset siis mahdollistavat useita konkreettisia toimenpiteitä, esim. asiakastuntemuksen, markkinoinnin ja palveluiden kehittämisen osalta. Ja ennen kaikkea, tulosten avulla voidaan vaikuttaa asiakaspoistumaan.
Vaihe 4 – ratkaisujen arviointi
Seuraavaksi prosessi etenee siten, että arvioidaan eri ratkaisuvaihtoehdot, huomioiden riittävän kattavasti niihin liittyvät tekijät.
Käytetään esimerkkinä äsken mainittua koneoppimista, ja laitetaan sekin puurakenteeseen.
Kuvassa listatut kohdat eivät ole kattavia, vaan lähinnä esimerkkinä. Olennaista on, että mukana olisi onnistumisen kannalta kaikki keskeiset asiat. Käytännössä noihin sinisiin boxeihin kirjattuihin kohtiin pitäisi löytää uskottavat vastaukset.
Kannattaa myös huomata, että usein hyvältä vaikuttavat ratkaisuvaihtoehdot (kalvoilla) saattavat luoda uusia potentiaalisia haasteita ratkottavaksi. Toisinaan niin suuria etteivät ne ole ratkaisuja ollenkaan.
Lisäksi on tärkää löytää sellaiset tekijät, joita ilman ratkaisu ei tule tuotannollistumaan eikä business tavoitteita siten saavuteta.
Esimerkkinä vuosia sitten ollut poistumaprojekti, jossa tuotantokäyttöön ei päästy, koska siellä ei ollut liiketoimintavastaavaa asialle.
Perusteellisemmin tehty business casen määrittely olisi kenties säästänyt turhalta POC-projektilta.
Kannattavuuslaskelma
Ratkaisun arvioinnissa on tietysti huomioitava sen kustannukset ja oletettu tuottopotentiaali. Yleensä tällöin käytetään ROI tai takaisinmaksuaikalaskelmia, joilla perustellaan investoinnin kannattavuus. Etenkin koneoppimisratkaisujen osalta on hyvä tiedostaa, että tulokset eivät ole varmoja, jolloin kannattaa hakea epäsymmetristä riski-tuottoskenaariota (pieni riski, iso tuotto).
Tässä esimerkissä luvut voisivat olla:
- Investoinnin kokonaiskulu (sisältäen kaiken: data, koneoppiminen, tuotannollistaminen, markkinointi..) -150 000 eur ensimmäisenä vuonna ja sitten -50 000 eur / vuosi
- 2% pudotus poistumassa tuottaa +200 000 eur / vuosi
- 5 vuoden investointi, -350 000 eur
- 5 vuoden tuotto, +1 000 000 eur
- 5 vuoden nettotuotto +650 000 eur
Noilla luvuilla projektin aloitus olisi todennäköisesti järkevää. Ainakin houkuttelevaa.
Käytännön elämässä on kuitenkin usein tilanteita, joissa suoraviivaisen kannattavuuslaskelman tekeminen ei oikein onnistu. Silloinkin pitäisi pystyä järkeilemään, että miksi investointi olisi kannattava.
Vaihe 5 – päätösten aika
Lopuksi ollaan tilanteessa, jossa on kerätty kaikki relevantti tieto business casen osalta, jaettu ongelma osiin, muodostettu hyvin pohdittuja ratkaisuehdotuksia, tehty kannattavuuslaskelma (tai vastaava ajatustyö) ja varmistuttu ettei tunnistettuja show-stoppereita ole matkalla.
Mikäli ratkaisuvaihtoehtoja on useita, niin niiden priorisoinnissa voi käyttää apuna esim. seuraavaa matriisia.
Nyt kun ollaan vielä business casen määrittelyvaiheessa, niin priorisoinnin tekeminenkin perustuu aiempiin analyyseihin ja koulutettuun arvaukseen. Vasta kun toimenpiteitä on oikeasti koeponnistettu, niin tiedetään tulosten ja panosten välinen suhde.
Tässäpä tämä tällä kertaa, eikun pohtimaan business caseja.
