Hei,
Minun ikuisuusteemani data-alalla on, miten liiketoiminnan tulisi olla mukana datakehityksessä. Se perustuu yksinkertaiseen ajatukseen: jos rakennamme teknistä ratkaisua jollekin muulle kuin itsellemme, eli sillä on käyttäjä, käyttäjän tulisi olla mukana sen rakentamisessa.
Olenko idealisti? Ehkä. Mutta seuraukset ovat konkreettisia.
Datatiimit palvelevat — mutta ketä?
Keskustelen lähes päivittäin datatiimien vetäjien ja muiden alan ammattilaisten kanssa. Kaikki eivät toimi samalla mallilla, mutta väittäisin, että suurin osa.
Valtaosa yrityksistä sekä julkisen puolen organisaatioista toimii niin sanotulla service desk -mallilla. Siinä data-alustaa kehitetään ja bugeja korjataan reaktiivisesti. Liiketoiminta toimittaa tikettejä datatiimin backlogille, ja kaikki työ perustuu sen hallintaan. Aikaa ei jää kehitystyölle juuri lainkaan.
Tässä mallissa datatiimi ei myöskään käy bisneksen kanssa strategisia keskusteluja: missä on liiketoiminnan pullonkaula, voisiko hävikkiä vähentää, voisiko myyntiprosessia tehostaa datan avulla? Kyllä, datatiimi työskentelee esimerkiksi hävikin minimointiin liittyvän datan kanssa — mutta ei strategisena kumppanina.
Erään datajohtajan ajasta yli 70 % menee tikettien käsittelyyn. Hänen tiimillään luku on 100 %.
Tämä ei motivoi datainsinöörejä: keskustelujeni pohjalta voin väittää, että suurin osa haluaisi myös tehdä työtä liiketoiminnan kehityksen eteen.
Miksi datatiimit päätyvät IT:n alle?
Miten tähän on päädytty, johtuu koko organisaation rakenteesta ja johtamisjärjestelmistä.
Moni dataosaaja ja muu asiantuntija peräänkuuluttaa mallia, jossa datatiimit olisivat bisneksen alla. Usein tukifunktioiden, kuten talouden, HR:n ja IT:n, kohdalla kuitenkin päädytään keskitettyyn malliin.
Miksi datatiimit päätyvät IT:n alle? Data tallentuu IT-järjestelmiin, esimerkiksi CRM:ään ja ERP:hin, ja sen kaivaminen käytettävään muotoon edellyttää teknistä osaamista. On siis tavallaan loogista, että datatiimi on IT:n alla.
Sitten IT miettii, miten tätä voi automatisoida ja tehostaa: hankitaan Databricks, Snowflake, dbt ja Power BI. Yks kaks ollaan syvällä IT:ssä, vaikka alkuperäinen tarve oli liiketoiminnan kehittäminen.
Osassa yrityksiä datatiimit toimivat CDO:n alaisuudessa. Periaatteessa tämä vaikuttaa hyvältä ratkaisulta, onhan yritys nimittänyt C-tason johtajan data-alueelta. Käytännössä tämä voi kuitenkin olla jälleen bisneksen tapa ulkoistaa data-asiat jollekin muulle. Kohta näemme yrityksissä Chief AI Officereita, vaikka nimenomaan bisneksen tulisi olla AI-kehityksen ajureita.
Usein käy myös niin, että CDO-funktiosta muodostuu ajan myötä tekninen IT-funktio, vaikka alkuperäinen tavoite oli tuoda data aidosti osaksi liiketoiminnan ydinpäätöksiä.
Data mesh yritti ratkaista tämän, miksi se ei riittänyt?
Data mesh oli hyvä yritys taklata tätä haastetta: dataosaaja sijoitetaan liiketoimintaan, omaan domainiinsa. Data product -ajattelussa liiketoiminta on mukana kuluttajan roolissa, jota kuunnellaan ja jonka palautteen perusteella tuotetta kehitetään.
Haaste on se, että iso osa yrityksistä on teollisuutta, rakentamista, tuotantoa ja vähittäiskauppaa. Päätökset datatiimien rakenteesta tehdään ylhäällä, eivätkä ne ole pelkästään CIO:n käsissä, muitakin C-tason johtajia tarvittaisiin data meshin toteutuksessa mukaan. Data meshiä ei voi jalkauttaa yksin, sillä keskittämisen paradigma ei ole IT:n päätettävissä.
Tiedän kyllä hyviä CIO:ta ja datajohtajia, jotka pystyvät ajamaan tätä muutosta. Esimerkiksi UPM:n Turkka Keskinen ja ex-upmlainen Tero Miikki ymmärsivät data-alan mahdollisuudet ja pystyivät vaikuttamaan muihin johtajiin sen tärkeydestä. Heillä oli hyvin moderni malli datapuolella jo ennen kuin data mesh -termi lanseerattiin.
Semanttinen kerros ja conversational BI — tässä on mahdollisuus
Olen puhunut paljon viime aikoina semanttisesta kerroksesta ja conversational BI:stä (kirjoitin aiheesta myös edellisessä blogissani). Ajatus on se, että AI-työkalu, kuten Claude tai ChatGPT, kytketään data-alustan päälle, vaikka Snowflakeen tai Databricksiin.
Pelkkä kytkentä ei riitä, koska konteksti puuttuu: AI ei osaa hakea sieltä dataa luotettavasti. Datamalli, tai niin sanottu rikastettu datamalli, sisältäen KPI:t, käsitemäärittelyt ja liiketoimintalogiikan, toimii tässä kontekstina ja auttaa AI:ta hakemaan oikean luvun.
Semanttinen kerros on se tapa, joka mahdollistaa tämän ja auttaa sen skaalaamisessa. Ideaalitilanteessa mukaan tulisi bisneksen edustaja määrittämään KPI:t ja muut speksit.
Haaste: service desk -mallissa datatiimit eivät tee tämän tyyppistä kehitystyötä bisneksen kanssa. Omistajuuskysymykset ovat auki, oikea bisneskontakti puuttuu, tai datatiimille on suoraan sanottu, ettei se saa häiritä liiketoimintaa.
Toki välillä speksausta tehdään, mutta se tehdään ennen uutta kehitystä. Monesti vahinko on kuitenkin jo tapahtunut, eli termit ja KPI:t pitäisi kuvata jälkikäteen. Tähän on vaikea kiireen keskellä varata aikaa.
Voidaanko tämä rakentaa ilman bisnestä?
Vastaus on kaksijakoinen. Uskon, että jotain toimivaa voidaan rakentaa olemassa olevien KPI-määritysten ja data-alustan perusteella, ja se on hyvä lähtökohta.
Testaa tätä: valitse yksi KPI, jota bisnes oikeasti käyttää. Rakenna sen perusteella POC, jossa testataan conversational BI:tä. Se madaltaa kynnystä sitouttaa bisnestä myöhemmin.
Mutta jos halutaan rakentaa jotain, joka oikeasti hyödyttää liiketoimintaa, conversational BI, jossa myyntijohtaja kysyy AI:lta asiakaspoistumaa tai katteita, bisnes on jossain kohdassa otettava tiiviimmin mukaan.
Näin se on kaiken teknologian kanssa. Kun olin aikoinani töissä HR SaaS -firmassa, oli selvää, että tuote myydään suoraan HR:lle ja HR on tiiviisti mukana sen kehityksessä ja käyttöönotossa. Asiakkuudenhallintajärjestelmä (CRM) omistaa aina bisnes, ja olisi absurdia kuvitella, että sellainen otettaisiin käyttöön ilman myyntitiimiä.
Tarkoitan tässä, että teknologiassa on ikään kuin universaali laki: tuotteen käyttäjän ja sen rakentajan välille on muodostettava iteratiivinen prosessi. Vain näin voidaan tuottaa ratkaisu, joka oikeasti hyödyttää käyttäjää.
On vaikea kuvitella, että data-ala, BI tai tekoälyn hyödyntäminen olisi tästä poikkeus.
On tosin olemassa teknologiaa ja konsepteja, jotka mahdollisesti auttavat tässä. Palaan tähän blogin lopussa.
Self-service BI ei toimi ilman bisnestä
Olen itse toiminut toimitusjohtajana, eli juuri sen bisneksen edustajana, josta puhun. Olen suhteellisen varma, ettei bisnes lopulta tarvitse BI-dashboardeja mihinkään, jos se saisi saman tiedon AI:lta suoraan chatissa.
Siksi uskon, että edellä mainittu self-service BI on tulossa kaikille: se on niin selkeä käyttötapaus AI:lle.
Mutta kuten aiemmin totesin, jos organisaatio haluaa hyödyntää AI:ta tosissaan, se ei voi toimia niin, että yrityksen IT-osasto on tästä yksin vastuussa, ilman bisneksen osallistumista. Usein käytetään myös ohjelmistokonsultteja, mutta ulkoistus ei ratkaise tätä perimmäistä ongelmaa.
Nykyinen self-service-malli ei oikein toimi AI-aikakautena. Data mesh, datakatalogit ja self-service-BI-työkalut ovat kaikki olleet yrityksiä ratkaista sama perusongelma.
Data mesh ei toiminut, koska sen lanseeraus vaatii liian isoja muutoksia organisaation prosesseihin. BI-softat ovat hyvä yritys, mutta ne ovat lopulta liian teknisiä bisnekselle. Sama ongelma koskee datakatalogeja: jos näytät datakatalogin bisnekselle, se ei ymmärrä sen käyttöliittymästä hölkäsen pöläystä.
Entä Genie Ontology?
Yhtä asiaa olen miettinyt potentiaalisena ratkaisuna, ja se on linjassa edellä kuvatun kanssa: Databricks julkaisi Genie Ontologyn, joka yrittää kaivaa semanttisen kerroksen automaattisesti Teamsista, sähköposteista ja dokumenteista.
Voisiko tämä toimia? Eli sen sijaan, että keskustelisimme myyntitiimin kanssa siitä, mikä on asiakas ja miten asiakaspoistuma lasketaan, antaisimmekin AI-agentin tutkia myyntitiimin chatit, sähköpostit, kokoustranskriptiot ja Outlook-tiedostot.
Kiinnostava ajatus, ja palaan siihen seuraavissa kirjoituksissa. Mutta sillä välin kannattaa jutella bisneksen kanssa.
AI-kehitys tarvitsee datatiimejä
AI-kehitys on nyt kaikkien bisnesihmisten huulilla. Mutta se tarvitsee dataa, ja ennen kaikkea data-infraa: perustan (foundation) ja governancen. Data engineering on juuri tekoälyn hyödyntämisen sydämessä.
Tämä kannattaa sanoa liiketoiminnalle suoraan: teidän omat datatiimit ovat erinomainen resurssi AI:n hyötykäyttöön, koska heidän vastuullaan on juuri se semanttisen kerroksen rakentaminen. Jos haluamme ottaa tekoälyn käyttöön data-analytiikassa, ja conversational BI on siinä tietysti se kruununjalokivi , se tapahtuu parhaiten liiketoiminnan ja datatiimin yhteistyöllä.
Ja tämä on viesti datatiimeille: myykää datamallinnus, governance ja muu datankehitys AI-työnä. Se on helpompi tapa saada bisnes mukaan.
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.
Ystävällisin terveisin,
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:
- Semanttinen kerros — mikä se on? → hoviai.fi/blogi/semanttinen-kerros/
- Contextual layer — vanha ongelma uudella nimellä → hoviai.fi/blogi/contextual-layer/
- Anthropic: How Anthropic enables self-service data analytics with Claude → claude.ai/blog/how-anthropic-enables-self-service-data-analytics-with-claude
