Kehittämisen näkökulmat datastrategiassa

Datastrategiamatkallamme on tähän asti opittu tunnistamaan business case -aihioita eri näkökulmista ja tekemään näille kevyttä priorisointia. Tässä vaiheessa matkaa on siis muodostunut melkoisen kattava näkemys organisaation tietotarpeista ja datan tuomista mahdollisuuksista liiketoiminnan kehittämisessä. Usein myös pahimmista kipupisteistä ja pullonkauloista.

Mitäs seuraavaksi?

Ennen kuin sukelletaan suoraan datavarallisuuden kartoittamiseen, data-aarteiden metsästämiseen, tietopääomakarttojen piirtämiseen tai arkkitehtuurien suunnitteluun, on hyödyllistä pysähtyä hetkeksi miettimään, mitkäs ne aidot tulevaisuuden kehittämisen näkökulmat taas ovatkaan.

Kaikessa yksinkertaisuudessaan ajatuksena on puristaa kasaan kaikesta tähän asti tuotetusta materiaalista muutama (organisaation liiketoiminnan tavoitteisiin liittyvä) ydinasia, joiden kautta muun muassa myöhempää arkkitehtuurisuunnittelua tehdään. Ei aina helppo harjoitus, mutta kyllä ne sieltä löytyvät, kun nostaa hieman lentokorkeutta. Ideaalisesti näkökulmat kattavat valtaosan (80/20, 70/30) tunnistetuista liiketoimintatarpeista.

Pari esimerkkiä.

Jos datastrategiaprojekti on rajattuna vaikkapa myyntiin ja asiakkuuden hallintaan, niin näkökulmat voisivat olla:

1. Asiakas-360, jotta voidaan tarkastella kaikkea asiakkaaseen liittyvää dataa eri näkökulmista — jaettu tilannekuva mahdollistaa tehokkaan toiminnan ja ennakoinnin. Aikas perusjuttuja vielä
2. Asiakkuuden elinkaaren ymmärtäminen, jotta voidaan ensinnäkin tarkastella asiakkaan elinkaarta kokonaisuutena, mutta tuottaa myös asiakasryhmäkohtaisia peruselinkaaria. Myöhemmin voidaan ymmärtää paremmin, miten eri segmentit kehittyvät, miten vertaisryhmät ovat kehittyneet ja missä elinkaaren vaiheessa asiakasta kannattaa optimaalisesti kontaktoida. Menee jo piirun verran vaikeammaksi, mutta ihan tehtävissä
3. Asiakasanalytiikka, jotta voidaan tehdä tekoälyjutskia ja tulevaisuusraportointia. Arkkitehtuurin kehittämisen näkökulmasta on hyvä muistaa, että analytiikan tuotannollistaminen tarvitsee toimiakseen modernin arkkitehtuurin
4. Digitaaliset palvelut, jotta voidaan tarjota dataa lähes reaaliajassa eri suuntiin, saada sovellukset keskustelemaan keskenään ja tuottaa asiakkaalle yhtenäistä asiakaskokemusta eri kanavissa. Lisäksi verkko- ja mobiilipalvelut luovat uutta dataa asiakkaan käyttäytymisestä, joka on tietenkin tarpeen säilöä talteen. Hiukan ainakin itseäni ärsyttää, jos ostaa verkkokaupasta jotain ja hetken päästä mainostetaan samaa tuotetta alennushintaan. Data pitää saada virtamaan joka suuntaan

Mikäli datastrategiaa on tehty laajemmin koko organisaatioon, niin esimerkiksi seuraavat näkökulmat saattavat nousta esiin:

1. Sisäisen toiminnan tehokkuus, jotta ymmärretään eri toimintojen kustannukset paremmin ja voidaan allokoida ne prosesseille, toiminnoille ja lopulta vaikkapa asiakkaalle, palvelulle tai jakelukanavalle
2. Asiakasymmärrys ja asiakaskokemus, jotta tunnistetaan ainakin kasvavat ja hiipuvat asiakkaat, löydetään optimaalinen palvelutaso asiakkaalle (minimipalvelutaso kuulostaa hieman asiakasta aliarvioivalta…) ja ennakoidaan esimerkiksi asiakkaan maksuvaikeuksia
3. Kilpailuetu, jotta tunnistetaan asiakkaalle merkityksellisiä kilpailutekijöitä, joiden avulla voidaan houkutella uusia asiakkaita ja pitää toki kiinni vanhoista. Jos algoritmit eivät osaa kertoa, niin voidaan ottaa puhelin kouraan ja kysellä asiakkaalta tulon (ja lähdön) syytä. Kilpailijoista voi puolestaan erottua esimerkiksi digitaalisten palveluiden tai personoitujen asiakaskohtaamisten avulla

Näihin esimerkkeihin tarvitaan hieman erilaista dataa kuin aiemmassa tapauksessa.

Kun kehittämisen näkökulmia on pohdiskeltu liiketoimintalähtöisesti ja rajattu sopivasti, on paljon helpompi miettiä, millaisilla tietopääomilla, arkkitehtuureilla, sovelluksilla ja osaamisilla asioita lähestytään.

Linjaukset ja arkkitehtuuriperiaatteet

Toisinaan voi olla hyödyllistä miettiä jo tässä kohtaa myös ylätason linjauksia sekä arkkitehtuuriperiaatteita. Tällaisia ovat tyypillisesti ei-toiminnalliset vaatimukset, kuten saavutettavuus, skaalautuvuus ja tietoturva sekä erilaiset toiminnalliset vaatimukset.

Ei-toiminnalliset vaatimukset ovat käytännössä copy-pastea projektista toiseen, joten toiminnallisten vaatimusten tai tavoitteiden pohdintaan kannattaa käyttää hieman enemmän aikaa. Esimerkiksi:

1. Cloud-exit -tilanteessa datan tulee olla kotiutettavissa pilvestä omaan konesaliin — huomioidaan sopimukselliset rajoitteet, kustannukset, regulaation vaatimukset sekä vastaavan toiminnallisen logiikan rakentamisen on-premises-ympäristöön
2. Perustiedot ovat keskitetysti hallittuna — jos samaa dataa löytyy useasta eri järjestelmästä, on tunnistettava mikä on ns. master-järjestelmä, jonka vastuulla tietojen ylläpitäminen ja oikeellisuus on
3. Ulkopuolisen datan ja tietolähteiden lisääminen on joustavaa — oli kyse sitten tietovaraston eri kerroksista tai dataa hyödyntävistä sovelluksista

Samoin on hyvä luoda sopivia linjauksia myös arkkitehtuurin kehittämiselle:

1. Kaikki data kierrätetään delta lake -pohjaisen staging-alueen kautta
2. Snowflake toimii tulevaisuuden teknologiana tietovarastoalueella
3. Tietovarasto mallinnetaan Data Vault 2.0 -metodologian mukaisesti
4. Jne.

Ja jos tarmoa riittää, ei hullumpi ajatus uhrata hieman aikaa tulevaisuuden arkkitehtuurilta vaadittavien kyvykkyyksien ja komponenttien pohdintaan eri näkökulmista.

Kun nämä kaikki ovat kasassa, hyppy teknologiaan on jo huomattavasti helpompaa. Ensi blogissa ei kuitenkaan mennä vielä teknologian tasolle, vaan pysytellään turvallisesti liiketoiminnan ja teknologian väliin jäävässä tietoarkkitehtuurissa ja opitaan esimerkiksi, mikä ihme on tietopääomakartta ja vieläkö käsitemalli on käyttökelpoinen työkalu.

Bloggaaja

Mika Aho

Bilot Alumni

See profile