Mikä arkkitehtuuri sopii parhaiten laadun mittaamiselle?

Kuten blogisarjan edellisestä osasta kävi ilmi, tiedon laatu on monitahoinen ongelma. Yrityksellä tulisi olla määriteltyjä prosesseja, joilla tiedon laatua pyritään aktiivisesti parantamaan. Näiden tulisi olla osa yrityksen laajempaa datastrategiaa. Mittaamisen tulisikin olla keskeinen osa strategiaa, ja sen toteuttamiseksi Data Platform on arkkitehtuurillisesti luonteva paikka.

Data Platform on datan keruuseen, tallentamiseen, jalostamiseen ja jakelemiseen keskittyvä järjestelmä. Sillä on näin ollen aktiivinen tekninen rooli tiedon laadun mittaamisessa ja varmistamisessa. Mittaamisen tulisi olla aina perustana mille tahansa parannettavalle asialle, koska muuten muutosten ja edistymisen arviointi on mahdotonta.

Kevyesti liikenteeseen

Ensimmäinen ja usein helpoin askel on aloittaa mittaamalla tiedon teknistä laatua. Blogisarjan ensimmäisessä osassa käytiin läpi tiedon laatuun liittyviä yleisimpiä käsitteitä. Pääkohdat olivat tarkkuus, kattavuus, luotettavuus, merkityksellisyys ja ajantasaisuus. Osa näistä linkittyy suoraan tekniseen mittaukseen, ja ne ovat näin ollen käsitteitä, joita on helpoin muuntaa seurattaviksi mittareiksi. Esimerkiksi puhtaat datansiirtovirheet, käsittelemättä jäävän tiedon osuus ja latenssi ovat kaikki suhteellisen yksinkertaisia mitattavia suureita. Attribuuttitason virheenseuranta, esimerkiksi oikean muotoisen tiedon syötön tai pakollisten kenttien tarkkailu, on toinen taso, joka on helppo koota seurattaviksi mittareiksi. Haastavampia mitattavia asioita ovat luotettavuus ja merkityksellisyys. Näiden suhteen on usein käytettävä ihmisten suorittamaa arviointia tai tarkempaa aineistokohtaista analyysiä.

Ongelmat kannattaa korjata mahdollisimman aikaisessa vaiheessa

Kun saadaan aikaiseksi seurattavia mittareita sekä lähtötaso, jolla järjestelmä toimii, voidaan analysoida mistä virheet johtuvat, ja suunnitella tarvittavia toimenpiteitä laadun parantamiseksi. Henkilökohtaisesti uskon, että tiedon laadun korjaaminen tulisi aina aloittaa mahdollisimman läheltä tiedon lähdettä. Mikäli jonkin järjestelmän tiedoissa on virheitä, olisi toivottavampaa raportoida virheet järjestelmän käyttäjille, arvioida mistä laatupoikkeamat johtuvat ja pyrkiä korjaamaan tietoa tuottava prosessi. Liian monesti näkee suunnitelman, jossa laatupoikkeamia lähdetään aktiivisesti korjaamaan tietoa vastaanottavassa järjestelmässä.

Tekniseen korjaukseen perustuvasta laadun parannuksesta muodostuu kaksi perustavan laatuista ongelmaa. Ensimmäiseksi tietoa luova prosessi ei korjaannu, itseasiassa pahimmassa tapauksessa se huononee entisestään, koska korjaus hetkellisesti parantaa tilannetta, ja luo näin tunteen, ettei laatuun tarvitse panostaa. Toiseksi datan laadun parantaminen keinotekoisesti, sitä tuottavan prosessin ulkopuolelta, ei koskaan ole täysin luotettava tai kattava ratkaisu. Se ei koskaan toimi 100 % varmuudella, ja näin ollen mitä huonompaa lähdeaineisto on, sitä huonompi on myös lopputulos. Tällöin laatupoikkeamien selvitystyö saa myös ylimääräisiä kerroksia, mikä tekee selvityksestä entistä ongelmallisempaa ja hitaampaa. Mitä monimutkaisempi tekninen korjausprosessi on, sitä monimutkaisemmaksi ja kalliimmaksi virheiden selvitystyö lopulta muodostuu.

“Mittaamisen tulisikin olla keskeinen osa strategiaa, ja sen toteuttamiseksi Data Platform on arkkitehtuurillisesti luonteva paikka.”

Aina ei tietoa pysty korjaamaan

On kuitenkin tilanteita, joissa tietoa ei pystytä jälkikäteen korjaamaan. Tästä esimerkkinä vaikkapa striimattava IoT-data. Jos mittarissa on toimintahäiriö, tai yhteyskatkos estää tiedon siirron, on tieto monesti menetetty lopullisesti. Tällöin kannattaa kuitenkin vielä pysähtyä miettimään, onko tarpeellista pyrkiä generoimaan puuttuva tai korjaamaan virheellinen data, vai olisiko järkevämpää korvamerkitä poikkeama tiedoksi, joka on virheellinen tai epäluotettava. Prosessia mittaava laite saattaa esimerkiksi rikkoutua vähitellen. On välillä haastavaa määritellä tarkalleen, milloin tiedot ovat muuttuneet viallisiksi, ja laajemmin, milloin tieto on muuttunut käyttökelvottomaksi kaikille sitä hyödyntäville tahoille. On kuitenkin aina hyvä olla tietoinen, mikä osa käytettävästä tiedosta ei varmistetusti ole luotettavaa.

Käytännössä kaikki yrityksen ulkopuoliset lähteet ovat sellaisia, joiden laatuun ei voida suoraan vaikuttaa. Onkin tärkeää miettiä, miten tällaisten lähteiden kohdalla tulee epäluotettava tieto käsitellä. Yhtenä hyvänä vaihtoehtona on pyrkiä merkitsemään epäluotettava data. Mitä aikaisemmin virheellinen data tunnistetaan ja käsitellään, sen pienemmiksi siitä aiheuttamat kustannukset muodostuvat. Parhaimmillaan tämä tapahtuu jo uutta järjestelmää valittaessa, jolloin vaikutus on suurin. Mitä pidemmälle huono data Data Platformin prosessissa ehtii, sitä suuremmat sen vaikutukset ovat. Potentiaalisesti vaikutukset ovat suurimmat silloin, kun ne tiedostamatta pääsevät vaikuttamaan päätöksiin. Tiedon laadun merkkaaminen, on välillä ainut vaihtoehto informoida käyttäjiä, ja suojella heitä näin viallisen datan aiheuttamilta vaikutuksilta. Prosessien ja teknisen alustan täytyy olla kuitenkin silloin valmis tällaiseen toimintoon, joka ei tule suoraan valmiina paketista.

Lokien käyttö lähtöpisteenä

Tiedon laatua pystyy mittaamaan monesta paikasta, mutta mistä olisi hyvä lähteä liikkeelle? Usein hyvä lähtöpiste varsinaisen valmiuden muodostamiseen on sieltä missä se on helpointa. Olemassa olevien lokien päältä pystyy monesti mittaamaan, ja näin myös valvomaan, osaa tiedon laatuun kiinteästi liittyvistä teknisistä tekijöistä. Tiedon ajantasaisuuteen vaikuttaa merkitsevästi tietosiirtojen tekninen onnistuminen, jota voidaan mitata esimerkiksi rivimääristä ja latenssista. Reaaliaikaisen tapahtumadatan latenssina voidaan esimerkiksi hyväksyä sekunti- tai minuuttiviiveitä. Dimensionaalisen tiedon oletetaan usein päivittyvän vähintään tunti tai päivätasolla.

Jos tietovuo siirtää vain tyhjiä sanomia, tai sanomia ei tule oletetulla latenssilla, voidaan monessa tapauksessa tulkita kyseessä olevan kriittinen katko. Tämän tyyppisten virhetilanteiden käsittelystä on helppo lähteä liikkeelle, ja modernien Data Platformien teknologiat tarjoavat valmiita lokeja, joihin monitorointi voidaan liittää. Lokien pohjalta onkin helppo miettiä ja toteuttaa teknisiä minimivaatimuksia vastaavat perustoiminnallisuudet, ennen haastavampien käyttökohteiden taklaamista.

“Tekniikka ei yksinään pysty ratkaisemaan tiedon laadun ongelmia. Tarvitaan hyvä strategia.”

Mittaamisessa on monta teknistä tasoa

Tiedon laadun haastavampiin kysymyksiin siirrytään, kun aletaan käsitellä varsinaisen tietosisällön ongelmia. Tyhjien arvojen määrien, tiedon muutostaajuuden ja raja-arvojen rikkoutumisen monitorointi on mahdollista toteuttaa yksittäisen datasetin ja/tai attribuutin näkökulmasta. Riippuen monitorointialgoritmista, tämä voidaan tehdä suoraan rivitasolla, tai vertailemalla arvoja historiaa vasten. Tiedon linkittymisen ongelmat ovat taas tilanteita, joissa päättelyyn tarvitaan usean tietojoukon yhdistäminen. Esimerkiksi tilaukselle tulee löytyä toimitus ja toimitukselle maksu. Tällaisissa tapauksissa tiedot saattavat sijaita erillisissä järjestelmissä. Kaikkien ongelmien selvittämiseksi ei laatua voi siis laskea vain yhdestä tietojoukosta tai lähteestä. Koska ongelmia on hyvin erityyppisiä ja tasoisia, on toivottavaa tutkia minkä tason häiriöt aiheuttavat eniten ongelmia tietoa hyödynnettäessä, eli määriteltävä mitkä asiat vaikuttavat laatuun eniten. Tätä kautta panostusta voidaan kohdentaa sinne, missä siitä saadaan suurimmat hyödyt, sen sijaan, että toteutusta rakennettaisiin tekniikka edellä.

Näiden ongelmien lisäksi mainittakoon perinteisemmät, usein MDM ratkaisulla korjattavat ongelmat, kuten tiedon yhtenäisyys ja golden record -haasteet. Konseptimallin mukaisesti mallinnettu ja toimiva tieto on tärkeää tiedon laadun varmistamiseksi, mutta se on tärkeää myös tiedon hyödyntämiseksi ja toimivan laatumonitoroinnin rakentamiseksi. Ei siis pidä unohtaa tai väheksyä MDM hankkeiden osuutta tiedon laadun parantamisessa. Niissä määritellään monesti teknisten virheiden lisäksi prosessien tuottamia sisällöllisiä virheitä, joita saattaa olla vaikeata ja työlästä havaita pelkästään käyttämällä teknisiä algoritmeja.

Hyviä prosesseja tarvitaan tekniikan lisäksi

Mistä siis tiedon laatustrategian tulisi muodostua? Ensiksi lähtöpisteestä, jota voidaan ja ollaan valmiita mittaamaan. Toiseksi toimenpiteistä, joilla parannetaan mitattavia asioita. Viimeiseksi itse prosessin jatkuvasta iteroinnista, jossa arvioidaan prosessin onnistumista nykytilanteessa ja tarvittavia korjaus- ja lisäystarpeita sekä varaudutaan uusien tietojoukkojen tuomiin haasteisiin. Azuresta löytyy paljon palveluita, joilla tarvittavat tekniset kyvykkyydet voidaan toteuttaa tukemaan tiedon laadun hallintaa.

Ilman hyvää strategiaa ja laatua tukevia prosesseja tekniikka ei yksinään pysty ratkaisemaan tiedon laadun ongelmia.