Hei,
Kun puhumme semanttisen kerroksen rakentamisesta ja conversational BI:stä, keskustelu kääntyy yllättävän nopeasti teknologiaan.
Pitäisikö käyttää Ellie.ai:ta, dbt:tä, Snowflakea, Databricksiä, Microsoft Fabricia vai jotain muuta? Missä mittarit määritellään? Missä käsitteet sijaitsevat? Millä työkalulla AI lopulta kysyy dataa?
Nämä ovat kaikki tarpeellisia kysymyksiä. Mutta mielestäni ne tulevat liian aikaisin.
Ensin pitäisi ratkaista paljon vaikeampi asia: mitä meidän liiketoimintamme käsitteet ja mittarit oikeastaan tarkoittavat?
Tämä kuulostaa yksinkertaiselta kysymykseltä, mutta käytännössä juuri tässä kohtaa moni semanttisen kerroksen hanke alkaa vaikeutua.
Teknologia voi laskea CAC:n. Se ei päätä, mitä CAC tarkoittaa.
Otetaan esimerkiksi Customer Acquisition Cost eli CAC. Kaava näyttää yksinkertaiselta: asiakashankintaan käytetyt kustannukset jaetaan uusien asiakkaiden määrällä.
Teknisesti tämän laskeminen ei ole kovin vaikeaa. Mutta mitä tarkoittaa uusi asiakas? Onko asiakas uusi silloin, kun hän allekirjoittaa sopimuksen, tekee ensimmäisen tilauksen vai maksaa ensimmäisen laskunsa?
Entä mitä asiakashankinnan kustannuksiin kuuluu?
Maksettu mainonta on helppo tapaus. Entä markkinointitiimin palkat? Myyjien palkat? Messut? Kumppaneille maksettavat palkkiot? CRM-järjestelmän kustannukset? Ulkopuoliset toimistot?
Jo näillä päätöksillä CAC voi muuttua merkittävästi ilman, että yhdessäkään laskukaavassa on teknisesti mitään väärää.
Sitten tulee vielä kysymys datasta.
Sama tieto voi sijaita useassa järjestelmässä. Liikevaihtoa löytyy CRM:stä, laskutusjärjestelmästä ja kirjanpidosta. Markkinointikustannuksia löytyy mainosalustoilta, talousjärjestelmästä ja Excelistä. Asiakasmäärä voi olla CRM:ssä yksi ja talousjärjestelmässä toinen. Kaikki luvut voivat olla omassa käyttötarkoituksessaan oikein.
Teknologia pystyy laskemaan CAC:n erittäin täsmällisesti. Teknologia ei kuitenkaan päätä, mikä näistä määritelmistä on se, jota organisaation pitäisi käyttää.
Semanttisessa kerroksessa on kaksi hyvin erilaista työtä
Tässä kohtaa semanttisen kerroksen rakentaminen jakautuu mielestäni kahteen eri kokonaisuuteen.
Ensimmäinen on liiketoiminnan työ.
Jonkun pitää päättää, mitä aktiivinen asiakas tarkoittaa. Jonkun pitää päättää, mitä CAC:n kustannuksiin sisällytetään. Jonkun pitää päättää, mikä järjestelmä on virallinen lähde silloin, kun CRM:n ja kirjanpidon luvut poikkeavat toisistaan.
Samalla pitää ymmärtää, miksi mittaria ylipäätään seurataan. Jos CAC nousee 20 prosenttia, mitä tapahtuu? Jos aktiivisten asiakkaiden määrä laskee, mitä organisaatio tekee sen perusteella? Mittari ilman päätöksentekokontekstia on helposti vain numero.
Toinen osa on tekninen. Kun määritelmä on päätetty, on tekisen toteutuksen aika.
Mistä tauluista tieto haetaan? Millä avaimilla ne liittyvät? Mikä on oikea granulariteetti? Miten historiatieto käsitellään? Miten aikarajat määritellään? Miten sama laskenta saadaan toistettavaksi eri raporteissa ja sovelluksissa?
Nämä ovat täysin olennaisia kysymyksiä. Mutta ne tulevat vasta sen jälkeen, kun tiedämme, mitä olemme toteuttamassa. Ja vasta sitten kannattaa miettiä, millä työkaluilla ja teknologioilla tämä tehdään.
Datatiimi voi toteuttaa määritelmän, mutta ei päättää sitä yksin
Me data-ihmiset katsomme ongelmaa helposti alhaalta ylöspäin. Näemme lähdejärjestelmän, taulun, kentän ja relaation.
Jos esimerkiksi teleoperaattorin datassa on:
subscription_status = active
Houkutus on suuri todeta, että siinäpä on aktiivisen asiakkaan määritelmä. Mutta tekninen status voi kertoa vain, että sopimus on voimassa.
Liiketoiminta voi tarkoittaa aktiivisella asiakkaalla henkilöä, joka on käyttänyt palvelua viimeisten 30 päivän aikana. Tai ehkä asiakkaan pitää olla laskutettava. Tai aktiivisuus määritellään näiden yhdistelmänä.
Kaikki ovat teknisesti mahdollisia määritelmiä. Datatiimi ei voi päätellä pelkän tietokantarakenteen perusteella, mikä niistä vastaa sitä liiketoimintakysymystä, johon halutaan vastata.
Tämä näkyy hyvin esimerkiksi dbt Semantic Layerissa. Sinne voidaan määritellä mittari active_customer_count ja sille sääntö, että asiakkaalla pitää olla käyttöä viimeisten 30 päivän aikana.
Sen jälkeen teknologia pystyy laskemaan aktiivisten asiakkaiden määrän samalla tavalla joka kerta. Tämä on juuri sitä, mitä semanttisen kerroksen pitääkin tehdä. Mutta dbt ei päätä, että 30 päivää on oikea raja. Se voisi yhtä hyvin olla 60 päivää. Aktiivisuus voisi perustua laskutukseen. Tai voimassa olevaan sopimukseen.
Vaikein vaihe tapahtuu siis usein ennen kuin yhtään YAML-riviä kirjoitetaan. Tämä korostuu isoissa organisaatioissa, joissa kukaan ei tunne kaikkien liiketoiminta-alueiden logiikkaa.
Myynti tuntee oman prosessinsa. Talous tuntee talouslogiikan. HR tuntee henkilöstöprosessit. Verkkoliiketoiminta tuntee oman maailmansa. Asiakaspalvelu omansa.
Siksi semanttisen kerroksen rakentaminen ei voi olla vain data engineering -projekti. Data- ja IT-tiimi voivat rakentaa infrastruktuurin, integraatiot, datamallit ja teknisen laskennan. Mutta liiketoimintalogiikka pitää saada niiltä ihmisiltä, jotka tuntevat kyseisen toiminnan ja käyttävät mittareita päätöksenteossa.
Teknologia toteuttaa määritelmän täsmällisesti. Se ei tee liiketoimintapäätöstä puolestamme.
AI tekee vanhasta ongelmasta näkyvämmän
Tämä ongelma ei syntynyt tekoälyn mukana. Dashboardeissa on ollut ristiriitaisia lukuja niin kauan kuin dashboardeja on rakennettu. AI muuttaa kuitenkin tilanteen luonnetta. Aikaisemmin käyttäjä näki raportin, jossa oli tietty määrä mittareita. Hän pystyi ehkä kysymään analyytikolta, mistä luku tuli.
Olen kirjoittanut paljon Conversational BI:stä. Conversational BI:ssä käyttäjä voi kysyä lähes mitä tahansa.
”Miten paljon meillä on aktiivisia asiakkaita Suomessa?”
AI vastaa: ”2500 kpl.”
Vastaus tulee nopeasti, ja se näyttää täsmälliseltä ja kuulostaa vakuuttavalta. Mutta jos aktiivisen asiakkaan määritelmää ei ole päätetty, AI joutuu joko arvaamaan tai käyttämään sitä tulkintaa, jonka se sattuu löytämään datasta.
Tällöin ongelma ei ole se, etteikö AI osaisi kirjoittaa SQL:ää. Päinvastoin. Se saattaa kirjoittaa täydellisen SQL-kyselyn ja antaa täysin oikean vastauksen väärään kysymykseen.
Se on paljon vaarallisempi virhe kuin syntaksivirhe.
AI-käyttötapauksessa meidän pitää yhdistää kaksi maailmaa
Tässä mielestäni on koko semanttisen kerroksen ydin.
Meillä on liiketoiminnan näkökulma. Sitten meillä on tekninen näkökulma. Missä data on? Miten se mallinnetaan? Miten taulut liittyvät? Miten määritelmä toteutetaan? Miten laskenta testataan? Miten se tarjotaan sovelluksille?
AI tarvitsee molemmat. Pelkkä tietokantaskeema ei riitä, koska se ei kerro liiketoiminnan merkitystä. Pelkkä business glossary ei myöskään riitä, jos määritelmiä ei ole linkitetty fyysiseen dataan ja laskentalogiikkaan.
Tarvitsemme yhteyden liiketoimintakäsitteestä määritelmään, määritelmästä laskentaan ja laskennasta fyysiseen dataan. Juuri tätä yhteyttä semanttisen kerroksen pitäisi rakentaa.
Mutta meillähän on nämä määritelmät jo dashboardeissa?
Tässä kohtaa joku aivan perustellusti kysyy: miksi tekisimme tämän työn uudelleen? Meillähän on jo dashboardit, raportit ja KPI:t. Niissä on määritelty, miten luvut lasketaan.
Ja niitä pitääkin käyttää.
Olemassa olevat dashboardit, raportit, Excelit ja KPI-kuvaukset ovat erinomainen lähtöaineisto semanttisen kerroksen rakentamiseen. Niihin on vuosien aikana kertynyt valtava määrä liiketoimintalogiikkaa.
Mutta niissä oleva laskentakaava kertoo ennen kaikkea, miten mittari on tähän asti laskettu. Se ei vielä kerro, onko tämä organisaation yhteisesti hyväksytty määritelmä.
Jos löydämme Power BI:stä CAC-mittarin, seuraava kysymys ei ole ensimmäisenä, miten kopioimme DAX-kaavan semantic layeriin.
Ensin pitäisi kysyä: onko tämä meidän hyväksymämme CAC? Kuka sen määritteli? Käyttääkö talous samaa määritelmää? Entä markkinointi? Mikä järjestelmä toimii kustannusten virallisena lähteenä? Onko määritelmä edelleen voimassa?
Usein juuri olemassa olevien raporttien läpikäynti paljastaa, miksi semanttista kerrosta tarvitaan. Sama KPI löytyy viidestä paikasta viidellä hieman erilaisella laskentalogiikalla.
Dashboard-maailmassa tämän kanssa on voitu elää, koska jokainen dashboard vastaa ennalta määriteltyihin kysymyksiin omassa kontekstissaan.
Conversational BI:ssä tilanne muuttuu. Käyttäjä ei enää valitse vain valmiiksi rakennettua mittaria. Hän voi kysyä:
”Mikä oli CAC yritysasiakkaissa viime vuonna ilman partner-kanavaa?”
Nyt järjestelmän pitää ymmärtää CAC:n lisäksi yritysasiakas, partner-kanava, aikarajaus, kustannusten lähde ja näiden käsitteiden suhteet.
Siksi olemassa olevia BI-määritelmiä ei pidä heittää pois. Ne ovat lähtöpisteitä semanttiselle kerrokselle, eivät automaattisesti valmiita semanttisia kerroksia.
Työ ei siis ala tyhjästä. Monessa organisaatiossa ensimmäinen vaihe voisi olla juuri nykyisten dashboardien, KPI-katalogien, raporttien ja Excelien läpikäynti: mitä määritelmiä meillä jo on, missä ne ovat ristiriidassa ja mitkä niistä liiketoiminta haluaa jatkossa tehdä virallisiksi?
Miten tämä tieto sitten saadaan liiketoiminnalta?
Olen nähnyt monia erilaisia menetelmiä siihen, miten liiketoiminta määrittelee ratkaisuja yhdessä dataosaajien ja kehittäjien kanssa. Minusta datamallinnus on tähän edelleen yksi tehokkaimmista menetelmistä.
En tarkoita pelkästään tietokantataulujen mallintamista. Tarkoitan prosessia, jossa käydään yhdessä läpi liiketoiminnan käsitteet, niiden määritelmät, suhteet, KPI:t, laskentasäännöt ja niiden linkitys fyysiseen dataan.
Business glossary kertoo, mitä käsitteillä tarkoitetaan. Käsitemalli ja looginen datamalli näyttävät, miten asiat liittyvät toisiinsa. KPI-määritykset kertovat, miten asioita mitataan. Ja fyysiseen dataan tehtävä linkitys kertoo, mistä tieto lopulta löytyy.
Näiden läpikäynti on samalla fasilitointimenetelmä. Kun liiketoiminnan edustajan kanssa piirretään näkyviin asiakas, sopimus, liittymä ja palvelu, ja kysytään, miten ne liittyvät toisiinsa, epäselvät määritelmät tulevat nopeasti esiin.
Sama tapahtuu KPI:n kanssa. Kun kysytään, mistä luvuista CAC muodostuu ja mitä kustannuksia siihen kuuluu, keskustelu muuttuu nopeasti paljon konkreettisemmaksi kuin jos kysyttäisiin vain yleisesti, mitä raportteja ihmiset tarvitsevat.
Tällä tavalla liiketoiminnan päässä oleva hiljainen tieto saadaan muutettua eksplisiittiseksi rakenteeksi.
Olen myös itse huomannut, että liiketoiminta oikeastaan tykkää näistä keskusteluista, kun ne tehdään oikein eikä käytetä data-alan jargonia. Psykologina on kiinnostavaa nähdä se reaktio, eli kuulluksi tulemisen tunne. Moni bisnesihminen kokee, ettei häntä kuunnella tarpeeksi, ja siksi tuntuu hyvältä käydä omaa aluetta läpi, kun toinen oikeasti kuuntelee.
Nämä keskustelut voi nauhoittaa, ja mallin pohjan saa tehtyä transkripteista, eli tätäkin prosessia voidaan nopeuttaa. Ja juuri tätä kontekstia, liiketoiminnan taustatietoa, AI tarvitsee.
Älä aloita isolla määrittelyprojektilla
Tähän liittyy kuitenkin yksi varoitus. En lähtisi rakentamaan koko organisaation kattavaa semanttista mallia yhdellä kertaa.
Se on helppo tapa tehdä projektista liian suuri, tiedätte kyllä, sellainen ikuinen data governance- tai arkkitehtuuriprojekti, josta kuukauden päästä kukaan ei enää muista, miksi sitä edes tehtiin.
Kerran yksi firma tilasi meiltä mallinnuspalvelua, CIO oli ollut yhdessä workshopissa, ihastunut mallinnukseen ja halusi, että kaikki domainit mallinnettaisiin samalla tavalla. Olimme innoissamme: tuntuu tietysti hyvältä, kun palvelua halutaan lisää.
Haaste oli vain se, että jossain kohtaa ihmiset rupesivat miettimään, miksi tätä tehdään. Mihin tämä johtaa ja miksi ylipäätään istumme workshopissa? Se on vähän kuin piirtäisi arkkitehtipiirustuksia taloista, joita ei ikinä toteuteta.
Sama pätee mallinnukseen: tee DW/BI- tai AI-ratkaisu ensin yhdelle alueelle ja etene sitten seuraavaan.
Sitten pala palalta alkaa muodostua pienistä osista kokonaisuus, ”tilkkutäkki”, joka alkaa muistuttaa semanttista kerrosta. Liiketoiminnan ei tarvitse edes tietää koko kerroksesta. He osallistuvat vain oman alueensa speksaukseen.
Parempi tapa on valita yksi todellinen AI-käyttötapaus ja yksi tai muutama tärkeä KPI. Don’t try to boil the ocean at once, niin kuin sanonta kuuluu.
Esimerkiksi asiakaspoistuma. Määritellään ensin, mitä asiakas tarkoittaa. Mitä poistuma tarkoittaa? Rakennetaan tämän ympärille tarvittava semanttinen malli ja annetaan AI:n käyttää sitä. Sen jälkeen testataan, saadaanko sillä oikeita ja toistettavia vastauksia.
Jos saadaan, otetaan seuraava KPI. Näin semanttinen kerros kasvaa käyttötapaus kerrallaan eikä erillisenä vuosia kestävänä määrittelyprojektina.
Ja ehkä kaikkein tärkeintä: liiketoiminnan kanssa ei välttämättä kannata edes aloittaa puhumalla datamallinnuksesta tai semanttisesta kerroksesta.
Puhutaan AI:n hyödyntämisestä.
”Halutaan rakentaa ratkaisu, jolta voit kysyä suoraan, miksi asiakaspoistuma kasvoi viime kuussa. Jotta AI osaa vastata oikein, meidän pitää ensin yhdessä määritellä, mitä asiakaspoistuma juuri meidän liiketoiminnassamme tarkoittaa.”
Se on liiketoiminnalle paljon ymmärrettävämpi keskustelu. Tätä toistamalla meillä on pian business glossary, semanttiset mallit ja KPI:t kuvattu siten, että AI:ta voidaan oikeasti hyödyntää enterprise-tasolla.
Olemme työskennelleet valtaosassa Suomen 30 suurimmasta yrityksestä. Ota yhteyttä, jos kaipaat näkemystä tai käsipareja semanttisen kerroksen sekä data-alustojen rakentamisessa. Verkostostamme Hovi Data Hubista löydät parhaat osaajat, freelancerit ja gurut.
Johannes Hovi
Growth Director, Ari Hovi. Yksi Ellie.ai:n perustajista. Kirjoittaa data-arkkitehtuurista, semanttisesta mallinnuksesta ja AI:n hyödyntämisestä BI-kontekstissa.
Lue myös:
- Miten BI-ala siirtyy raporteista keskusteluun — ja miksi semanttinen kerros ratkaisee sen
- Service desk -malli ei toimi AI:n aikakautena
