Hei,
Data-alalla on hurja vauhti päällä ja se kasvaa jatkuvasti.
Syy on yksinkertainen, teknologiat datan hyödyntämiseen ovat ottaneet melkoisia harppauksia viime aikoina.
Mutta eräs asia on nyt alkanut vaivaamaan monia organisaatioita. Tai oikeastaan sen puute.
Sitä voisi kutsua domain-ajatteluksi ja malliksi. Voidaan puhua myös Data Meshistä, datan toimitusketjusta tai data lineagesta, koska ne kaikki viittaavat tavallaan samaan asiaan.
Domainilla tarkoitetaan jotain liiketoiminta-aluetta, kuten myynti, tuotanto, talous tai HR.
Domain ajattelussa on keskeistä on siirtää datatekemisen painoa datan tuotantopäähän sekä käyttäjien ymmärtämiseen.
Pitkän aikaa kaikki ovat kehittäneet sitä toista päätä, eli datan hyödyntämiseen liittyvää teknologiaa.
Juuri tällä alueella on meneillään erittäin paljon kehitystä, kuten pilvipohjaisia tietoalustoja, data katalogeja, tekoälyä ja vaikka mitä visualisointityökaluja.
Mutta nyt ollaan ymmärretty, ettei mitkään teknologioista oikein ratkaise datan tuotannon ongelmaa, eli juuri sitä prosessin alkupäätä.
Väitän myös, että pelkästään legacy-teknologian uusiminen ei tee yrityksestä dataohjautuvaa (data driven).
Datan tuotantoketjun alku
Dataa tuotetaan pääasiassa yritysten IT-järjestelmissä, kuten ERP tai CRM. Sitä tuottavat nykyään myös koneet (Iot), verkkopalvelut jne.
Kaikki data, jota halutaan analysoida, asuu siis näissä järjestelmien tietokannoissa ja tiedostoissa.
Käytetään esimerkkinä vaikkapa CRM:ää, eli asiakkuuksien hallintaan soveltuvaa IT-järjestelmää.
Sinne viedään asiakkaiden kontakti,- sekä muut tiedot. Voisi sanoa, että CRM on keskeinen systeemi, jossa asiakasdata syntyy.
CRM:n käyttöönottoa draivaa yleensä myyntijohtaja ja ns myynti-domain.
Myyntijohtaja ja hänen kollegansa istuvat päiväkausia palavereissa jossa tehdään vaatimusmäärittelyä sekä muuta käyttöönoton suunnittelua.
Mitä laajempi softa, sitä enemmän kuluu palaverikahvia.
Kun ollaan homma saatu maaliin, eli viety sinne datat vanhasta legacystä, rakennettu integraatiot ja koulutettu käyttäjät alkaa varsinainen käyttö.
Datan omistajuus kuuluu domainille
Jos mietitään, että kuka tämän CRM-järjestelmän tuntee, eli tietää mitä dataa siellä on, niin se on luonnollisesti myyntijohtaja ja hänen tiiminsä.
Myös CRM:n toimittaja tuntee alueen datat, koska on speksaamisen yhteydessä oppinut tuntemaan asiakasorganisaation hyvin.
Kuka muu tuntee CRM-aluetta?
Pääkäyttäjät. Kaikilla softilla on yleensä pääkäyttäjät organisaation sisällä. He ymmärtävät usein myös, että mitä sinne on viety ja miten integraatiot muihin järjestelmiin on tehty.
Sitten on arkkitehtejä ja sisäisiä IT-osaajia, jotka myös tuntevat jollain tasolla kyseistä järjestelmää.
Tämä kaikki on selvää, mutta kuka omistaa tämän CRM:n datan? Omistaa kuulostaa “raskaalta” mutta asian voisi muotoilla, että kuka on vastuussa siitä, mitä dataa CRM;ään kirjataan tai tuodaan?
Vastaus pitäisi olla minusta myyntijohtajan osasto, mutta onko näin?
Datan “toisiokäyttö on hankalaa”
Usein puhutaan, että datalla on ikään kuin ensisijainen käyttö, joka on juuri esimerkiksi sitä, että myyjä kirjaa tietoja CRM:ään.
Data-analytiikkaa kutsutaan usein toisiokäytöksi, jolla tarkoitetaan, että tätä samaa dataa käytetään esimerkiksi, data-analytiikassa, raportoinnissa ja erilaisissa datan hyödyntämisen hankkeissa kuten tekoälyratkaisuissa.
Data-analytiikkaan ovat yleensä erikoistuneet eri ihmiset, kuin operatiivisiin järjestelmiin. Heillä on osittain eri näkemys maailmasta ja he katsovat asioita tietysti omien “silmälasiensa” läpi.
Sanotaan, että tämä esimerkkiorganisaatio päättää rakentaa tietoalustan, jolla CRM-dataa voitaisiin analysoida entistä kattavammin.
Ollaan todettu, että CRM-dataa pitää yhdistää esimerkiksi laskutustietoihin, jotka ovat eri järjestelmässä.
Kuulostaa helpolta, mutta asia on monisyinen.
Tietoalustojen haasteet
Data-alustaa ollaan siis lähdetty kehittämään ja usein tehdään seuraavasti. Päätetään valita menetelmäksi Data Vault, koska se on laajennettava tarkoittaen sitä, että samaan alustaan voidaan lisätä ja integroida myös muiden osastojen tietoja.
Organisaation datatiimi, IT-osasto ja konsultit alkavat tutkia ja selvittää CRM sekä muiden integroitavien lähdejärjestelmien tietokantoja.
Nämä rakenteet kopioidaan alustalle sellaisenaan Data Vault-rakenteeksi.
Sisäisen IT:n ja raportoinnin osaajat usein nimittäin tuntevat nykyiset tieto- ja raportointitarpeet, joiden mukaan uutta Data Vault -ratkaisua lähdetään speksaamaan.
Nyt sitten mietitään, miten BI ja data-analytiikka -hommat saadaan sujumaan uudella systeemillä entistä tehokkaammin.
Toisin sanoen siirretään ”vanha tekeminen” uudelle paremmalle tietoalustalle.
Tietoalustasta voi tällä menettelyllä tulla teknisesti onnistunut. Sinne voi tallentaa huikea määrä dataa eri lähteistä ja manuaalisen työ vähenee entisestään.
Mutta onko se liiketoimintaa aidosti palveleva ratkaisu?
Datatiimi on irrallaan data tuotannosta
Tämä prosessi johtaa yleensä siihen, että data-alusta kyllä voidaan rakentaa teknisesti ikään kuin oikein, mutta sen hyödyllisyys liiketoiminnan näkökulmasta jää vajavaiseksi.
Sen laajennettavuus on olematon ja edellä kuvattu ratkaisu johtaa lopulta ongelmiin ja suurempaan manuaaliseen työhön.
Juuri keskustelin erään asiakkaan arkkitehdin kanssa.
Heillä on tietovaraston automaatiotuotteet, Snowflaket, Tableau ja ties mitkä systeemit käytössä, mutta silti homma ei toimi. Kysyin, että mikäs siinä mättää?
Ongelma on juuri siinä, että datatiimi ei kunnolla ymmärrä mitä dataa alustalle on viety. Ja jos ei tiedä mitä siellä on, niin miten alustaa voi käyttää liiketoiminnan kehittämisen tukena?
Datatiimille saatetaan esittää hyvin epäselviä pyyntöjä, vaikkapa että tarvitaan dataa myyntiliideistä.
Ja vaikka olisi alkuun käyty jokin käyttötapaus läpi ja pokattu koko dataputki, niin se ei riitä. Tarpeet nimittäin muuttuvat jatkuvasti!
Juuri tämä on olennainen asia tulisi miettiä heti alkuun – ollaanko tekemässä vain rajatun alueen raportointiratkaisua, jossa tiedon kuluttajan tarpeet on jot etukäteen määritelty ja hakattu kiveen?
Ja jos näin on, ei edes kannata välttämättä lähteä tekemään Data Vault-pohjaista alustaa.
Itse asiassa Data Vaultin rakentamisen idea on juuri rakentaa monikäyttöinen ja monia tarpeita palveleva ratkaisu.
Data Vaultin hyvät ominaisuudet menevät hukkaan
Domain-ajattelun puute ikään jyrää Data Vaultin tuomat edut. Eli tehdään uudenlainen ratkaisu, joka mahdollistaisi laajennettavuuden, mutta se tehdään kuitenkin “vahojen” tarpeiden pohjalta.
Palataan tähän CRM esimerkkiin. Erillinen data engineerien tiimi, joka tämän Data Vault-ratkaisun tuottaa, ei tunne myyntialuetta ja sen dataa lopulta kunnolla.
Harva data engineerien tiimistä tietää, mikä on liidi ja miten se liittyy asiakkaaseen.
Ongelma johtuu juuri siihen, että kyseisen domainin ihmisiä ei ole mukana data-alustan rakentamisessa. He kyllä tietäisivät ja osaisivat kertoa lisää CRM-datasta ja liideistä, mutta data-alustan tekemiseen heitä ei ole vaivattu.
Mietin usein, että miksi näin on ja miten tälläinen kulttuuri on päässyt syntymään.
Jos hankitaan uutta operatiivista järjestelmää, vaikka juuri CRM:ää, niin on selvä, että siellä ovat alueen asiantuntijat, siis myyntiporukka sitä säätämässä ja workshoppaamassa.
Mutta kun pitäisi miettiä data-alustan rakentamista, niin sama porukka loistaa poissaolollaan.
Toisin sanoen hanke nähdään puhtaasti teknisenä harjoituksena. Ja teknisissä hankkeissa IT,- ja datatiimi ei halua häiritä liiketoimintaa.
Mikäli yritys tai organisaatio haluaisi oikeasti tulla datalla ohjautuvaksi, niin kulttuuriin pitää muuttua.
Domain-ajattelu kunniaan
Jos myyntijohtaja ja kumppanit omistaisivat tämän datan oikeasti, niin silloin heidän pitäisi olla mukana data-alustan kehityksessä itsekin. Tietysti!
Juuri tätä on domainkeskeinen ajattelu – otetaan domainin edustajat mukaan data-alustaprojektiin.
Nyt tähän ollaan alettu pikkuhiljaa herätä ja osataan paremmin artikuloida että mistä on kyse. Kyse on datan toimitusketjun hallinnasta.
Pitäisi lähteä siitä, että kun otetaan ERP tai CRM käyttöön, niin jo siinä vaiheessa mietittäisiin data-analytiikkaa tovi pidempään. Sama pätee räätälöityjen ohjelmistojen kehitykseen.
Pitäisi myös ajatella datakeskeisesti, eli mitä dataa kyseinen järjestelmä tarkkaan ottaen tuottaa ja mitä vaikutuksia tällä on data-analytiikkaan ja BI-tekemiseen.
Mielestäni termi “datan toisiokäyttö” sietäisi joutaa romukoppaan. Ei liiketoiminnan kehittäminen voi olla mitenkään toissijaista.
Jos myyntijohtaja haluaa kehittää myyntiä, mitä hän tekee? Hän analysoi juuri kuinka monta liidiä tarvitaan tarjouksen läpimenoon ja missä kohtaa myyntiprosessia on pullonkauloja.
Tähän tarvitaan tietysti dataa myynnistä. Tämä data ei siis ole mitenkään sekundääristä, vaan yrityksen kehityksen kannalta olennaista.
Näin ollen on luonnollista, että myyntijohtaja on mukana data-alustan kehittämässä, koska hänen työstään siinä on lopulta kyse.
Vinkkejä kehittämiseen
Kun kehitämme Ellietä, tämä on juuri kaiken ytimessä: miten datatiimi voisi paremmin ymmärtää liiketoimintaa ja sen tuottamaa dataa?
Tämä pätee myös toiseen suuntaan, eli miten liiketoiminta ymmärtäisi paremmin data-alustoja.
Paras tapa on saada liiketoiminta mukaan hankkeisiin, on tuoda hänellä mahdollisimman nopeasti dataa nähtäväksi. Ei kannata miettiä mitään skaalaamisia liian aikaisin.
Kannattaa hyödyntää käyttötapauksia sekä käsitemalleja rinnakkain. Käsitemalli kääntää liiketoimintaongelman datan kielelle.
Sanotaan vaikka liiketoimintaongelma: “kuinka monta liidiä konvertoituu asiakkaaksi viime kuussa” pystytään mallintamaan suhteellisen helposti siten, että data-arkkitehti ja insinööri ymmärtävät mistä on kyse.
Kannattaa järjestää tiimit siten, että niissä on henkilöitä operatiivisten järjestelmien kehittämisestä sekä sekä data-analytiikasta.
Jos tiimien uudelleen järjestäminen on vaikeaa, mitä se tietysti usein on, kannattaa luoda alkuun keskustelukanavia ja foorumeja, joissa datan toimitusketjun eri vaiheen tekijät voivat keskustella keskenään.
Ellie-mallinnustyökalu mahdollistaa sen, että käsitemallit ovat ajan tasalla, kaikkien saatavilla.
Sen avulla liiketoiminnan tarpeet ohjaavat data-alustan rakenteita, eivätkä vanhojen IT-järjestelmien rakenteet.
Ellie mahdollistaa näiden liiketoimintatarpeiden viemisen automaattisesti muihin dataputken järjestelmiin, kuten WhereScapeen.
Ja mikä hienointa, se muodostaa taustalle automaattisesti liiketoimintalähtöistä informaatioarkkitehtuuria ja organisaatiotason tietomallia (enterprise data model).
Ystävällisin terveisin,
Johannes
Ps. Olemme julkaisseet nyt uusitun painokset SQL-oppaasta (uusi ulkoasu + Snowflake mukana), joka on Suomen luetuin alan opus. Se on käytössä SQL-koulutuksissa, joista saat sen itsellesi myös omaksi. Jos haluat lisätietoa SQL:stä, niin tule ilmaiseen webinaariin, jossa kirjan kirjoittaja Ari kertoo mm:
- Ymmärrät miksi SQL on digiajan perustaitoja.
- Mihin SQL:ää käytetään?
- Mitä etuja saavutetaan, kun on mahdollista päästä suoraan omiin datoihin.
