22.01.2020

Business casen määrittely

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:

Hieman teknisempiä kysymyksiä voisivat olla:

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.

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

  1. datasta laskea eri tekijöiden vaikutus poistumaan
  2. 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:

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.

Share
Contact Person

Bloggaaja

Mika Laukkanen