Moniko on inventoinut tietopääomansa? Entäpä toimistokalusteensa? Kummat ovat arvokkaampia?
Niinpä.
Useimmissa organisaatioissa data-aarteet ovat hyvin jemmattuna. Itse asiassa niin hyvin, ettei organisaatiolla ole edes käsitystä, millaisia data-aarteita ne omistavat tai mikä niiden käypä arvo on. Hyvin usein aarrearkkuja on vieläpä useampia ympäri organisaatiota ja monesta on avain hukassa tai ne ovat ulkopuolisen huoltoyhtiön hallussa.
Kuukausittaiset vastikemaksut juoksevat ja tekisi mieli kurkistaa arkun sisälle. Mikäs apuun?
Kuten aiemmin opimme, organisaation strategia ja sen liiketoimintatavoitteet ovat hyvä lähtökohta datan keräämiselle. On tärkeätä keskittyä liiketoiminnalle oikeaan eli dataan, joka tuo organisaatiota lähemmäksi sen pidemmän aikavälin liiketoimintatavoitteita. Kuulostaa melko itsestään selvältä, mutta valitettavasti harvemmin on sitä.
Tietopääomien tunnistamisessa on pohjimmiltaan tarkoitus löytää ne organisaation nykyiset ja tulevat tietopääomat, joita tarvitaan aiemmin tunnistettujen tietotarpeiden ja business case -aihioiden toteuttamiseksi sekä organisaation muiden liiketoimintatavoitteiden saavuttamiseksi. Tästä muodostuu liiketoimintalähtöinen tiekartta datan hyödyntämiselle ja keräämiselle.
Tietopääomalla muuten viittaan enemmänkin organisaation hallussa olevaan tallennettuun informaatioon, kuin muuhun aineettomaan pääomaan (henkilöstön osaaminen, prosessit, yrityskulttuuri, asiakassuhteet jne.).
Työkaluja tietopääomien tunnistamiseen ja hallintaan
Tietopääomien tunnistaminen pitäisi tavalla tai toisella johtaa ymmärrykseen organisaation tietolähteistä, eri tyyppisistä tietojoukoista, datan rakenteista, datan laadusta, käsittelysäännöistä, tallennuspaikoista ja monesta muusta asiasta.
Seuraavaksi muutama työkalu tietopääomien inventoimiseksi.
Liiketoiminnan käsitemalli
Käsitemallinnus on perinteinen tapa kuvata organisaation käsitteitä ja niiden välisiä suhteita. Esimerkiksi sähkösopimuksiin liittyvä käsitemalli energiayhtiön näkökulmasta voisi näyttää seuraavalta:

Tähän saa mukavasti lisää informaatioarvoa lisäämällä myös lähdejärjestelmät käsitteiden alle. Mitä enemmän laatikoita on, sitä enemmän pitää olla huolissaan datan laadusta ja sen masteroinnista.
Luettavuutta saadaan värikoodaamalla numeerista tietoa sisältävät faktat ja luokittelevaa tietoa sisältävät dimensiot eri värein.
Mitä hyötyä tästä on?
Käsitemalli toimii hyvänä tulkkina IT:n ja liiketoiminnan välillä muun muassa ymmärtämään, mitä kaikkea dataa on saatavilla:
- Näytä minulle keskimääräinen päiväkohtainen sähkönkulutus käyttöpaikoittain Pirkanmaalla — okei, tarvitaan mittausdataa, käyttöpaikkoja sekä liittymän takaa löytyvää osoitetietoa. Nämä löytyvät ja raportti voidaan toteuttaa.
- Tai analytiikkacase tyyliin haluamme optimoida kaukolämpöverkoston ajoja ja pienentää verkostohäviöitä sekä käyttökustannuksia — tarvitaan (varmaankin) dataa verkoston rakenteesta, verrokkiverkostoista, osto- ja myyntienergiasta, virtaus- ja lämpötila-antureilta jne. Nopeasti huomataankin, että kaikkea dataa ei ole vielä saatavilla analytiikkacasen toteuttamiseksi.
Toisinaan käsitemallin piirtäminen on yllättävän tuskallista. Liiketoiminnan on helppo tuottaa erilaisia prosessikuvia, mutta käsitemallinnuksessa aivot pitääkin kääntää hieman eri asentoon.
Käsitemallinnuksessa keskitytään käsiteltävien tietojen rakenteeseen ja suhteisiin, kun taas prosessien mallinnuksessa lähtökohtana on käsittelytapahtumien muodostama prosessi. Esimerkki alla:

Ensimmäisistä versioista tulee helposti jotain käsitemallien ja prosessikaavioiden sekamelskaa. Vaikka ei kai siinä mitään vikaa ole.
Ei muuten mikään salaisuus, että lähes joka toimialalle ja prosessille on jo olemassa valmiita käsitemalleja. Enempi näissä harjoituksissa onkin tärkempää itse matka ja organisaation osallistaminen sekä oivaltaminen.
IT:n suuntaan käsitemalli toimii hyvänä pohjapiirustuksena sekä ohjeistuksena esimerkiksi tietovaraston rakentamiseksi. Käsitemallin pohjalta IT:n on helppo jalostaa edelleen erilaisia teknisempiä tietomalleja. Tyypillisesti alkuun tunnistetaan käsitteiden liiketoiminta-avaimet (esimerkiksi laskun numero, asiakas-id jne.) tai luodaan ne keinotekoisesti. Toisinaan mietitään myös tarkemmin käsitekohtaisesti määritelmiä, sen elinkaarta, attribuutteja, hierarkioita ja vaikkapa luokitteluita.
Käsitemallista on edelleen helpohko rakentaa Data Vault -mallit, dimensionaaliset tietomallit, fyysiset taulurakenteet sun muut eri työkalujen avulla. Näihin löytyy Wherescapen kaltaisia kaupallisia tuotteita ja jokaisella toimittajalla tuntuu olevan myös omansa.
Tietopääomakartta (eli data-aarrekartta)
Käsitemallinnusta kevyempänä vaihtoehtona olen viime aikoina suosinut eräänlaisen tietopääomakartan rakentamista organisaatioon, jossa ryhmitellään liiketoiminnan käsitteitä isompien kokonaisuuksien taakse. Tämän piirtää suht nopeasti nättiin muotoon Visiolla tai vaikka LucidChartilla.
Kokonaisuudet voisivat olla esimerkiksi:
- Asiakkaan perustiedot — yhteystiedot, demografiatiedot…
- Asiakkuuden hallinnan tiedot — tapaamiset, toimenpiteet…
- Sensitiivinen asiakastieto — terveystiedot, palkka- ja varallisuustiedot…
- Digimarkkinoinnin tieto — kampanjoiden vasteet, näyttökerrat, sitoutuminen, klikit…
- Prosesseissa syntyvä uusi tieto — asiakassegmentit, asiakkaan arvo, psykografiset tiedot…
- Jne.
Kuten käsitekarttakin, tietopääomakartta toimii apuna organisaation tietopääoman hahmottamisessa ylätasolla. Tietopääomakartta voisi näyttää esimerkiksi tällaiselta (esimerkki pöllitty Microsoftin Common Data Model -konseptista):

Liiketoimintaprosessien mallintaminen
Yksi hyvä ja liiketoimintalähtöisempi tapa lähestyä tietopääomia on mallintaa liiketoimintaprosesseja ja miettiä, mitä dataa prosessi kuluttaa, mitä uutta dataa se synnyttää ja millaisissa tietojärjestelmissä dataa käsitellään. Esimerkiksi näin:

Prosessien mallintaminen auttaa (mm.):
- osallistuttamaan ja sitouttamaan liiketoiminnan ihmisiä
- luomaan linkin liiketoiminnan ja datan välille
- liinaamaan prosesseja, dataa ja tietojärjestelmiä
- tunnistamaan isommassa kuvassa, mitä dataa koko prosessiin tarvitaan sisään ja mitä sieltä tulee ulos. Auttaa mukavasti vaikkapa tietovaraston tai AI-ratkaisun määrittämisessä
Ja mikä parasta, vihdoinkin on keksitty ikiliikkuja:

Data Catalog -työkalut
Excelillä ja Visiolla pärjää pitkälle, mutta jossain vaiheessa tulee tarve työkalulle, johon kuvata organisaation tietopääomia.
Siinä missä aikaisemmin blogeissa on lähestytty tietopääomaa enemmän liiketoimintalähtöisesti, Data Catalog -työkalut ovat (omien kokemuksieni mukaan) enemmän datalähtöisiä. Ne tarkastelevat organisaation olemassa olevaa tallennettua dataa ja eri tallennuspaikkojen metadatoja.
Parhaat työkalut organisaation datastrategian kuvaamiseen tuntuvat löytyvän nyt kokonaisarkkitehtuuurien mallintamisen puolelta. Hyvänä esimerkkinä Arterin ARC, joita pystyy soveltamaan mainiosti eri tarkoituksiin datastrategiankin kehittämisessä.
Mutta takaisin datakatalogeihin.
Datakatalogilla (joskus kutsutaan myös informaatiokatalogiksi) tarkoitetaan työkalua, jonka avulla on saadaan yleiskatsaus organisaation dataan, informaatioon sekä näihin liittyvään metadataan. Laajimmillaan datakatalogin kautta saadaan hallittavuutta koko data platformille.
Ideaalisesti työkalu kaivelee itsekseen tietokantoja ja muita tallennuspaikkoja, muodostaa metadataa, profiloi fyysistä dataa, tunnistaa poikkeavaisuuksia tai vastaavuuksia datassa, taggailee dataa (esimerkiksi tunnistaen PII-tyyppistä aineistoa automaattisesti), tunnistaa automaattisesti muutoksia datassa, luokittelee dataa, oppii käyttäjän toiminnoista jne.
Lisäksi datakatalogissa on mahdollista ylläpitää muun muassa organisaation sanastoa sekä parhaimmillaan kokonaiskuvaa koko tietoalustalla olevista artefaktoista (mm. datalataukset, Business Intelligence -raportit, AI-algoritmit) sekä eri tyyppisistä rooleista (mm. Data Steward, Data Engineer).
Kaupallista tarjontaa löytyy yllin kyllin, mainittakoon esimerkiksi:
- Alation
- Apacle Atlas (avoin lähdekoodi)
- AWS Glue Data Catalog
- Azure Data Catalog
- Collibra Catalog
- IBM Watson Knowledge Catalog
- Talend Data Catalog
- Qlik Data Catalyst (ex. Podium Data)
Loppuun vielä muutama mainio esimerkki, miten tietopääomia voisi kuvata ja luokitella:
Seuraavaksi arkkitehtuuriin
Blogisarjassamme hypätään seuraavaksi tietoarkkitehtuurista teknologian puolelle ja keskitytään modernin data-arkkitehtuurin suunnitteluun.
Piirtelemme muun muassa tietovirtakuvauksia sekä arkkitehtuurikuvia, ihmettelemme, miten data-arkkitehtuurista on tullut hirvittävän monimutkaista muutaman viime vuoden sisällä ja pohdimme, pitääkö kaikki data tunkea pilveen.
