Tiedon elinkaari voidaan jakaa kolmeen vaiheeseen: tiedon suunnittelu, tiedon tuottaminen ja tiedon hyödyntäminen. Tämä artikkeli käsittelee tiedon elinkaaren vaihetta: tiedon suunnittelu, koska se jää usein piiloon ja on kuitenkin se tärkein vaihe varmistamaan tiedon elinkaari tulevaisuudessa. Tiedon suunnittelulla on vahva yhteys teknisen tietoratkaisun toteutuksen kanssa. Tiedon suunnitteluvaihe yhdessä teknisen toteutuksen kanssa ratkaisevat siis pitkälti sen, miten hyvin tieto on tuotettavissa ja hyödynnettävissä.
Tiedolla hyödyntäminen vaatii laadukasta tietoa. Laadukas tieto ei synny itsestään, vaan tietoa tuotettaessa on ymmärrettävä tiedon laatuvaatimukset. Ongelma tiedon tuottamisen ja hyödyntämisen osalta tulee siitä, että tietoa tuotetaan eri prosessissa kuin sitä hyödynnetään. Tästä syystä tulee suunnitteluvaiheessa jo ymmärtää tiedon laatuvaatimukset. Käytännössä siis tiedon kuvaamisen yhteydessä suunnitellaan ja dokumentoidaan ne säännöt, joiden avulla varmistetaan, että tieto tuotetaan oikein.
Tiedon kuvaamisen lisäksi on myös muita toiminnallisuuksia, joilla tietoa hallitaan. Kaiken tiedonhallinnallisen työn tukemiseksi on olemassa useita viitekehyksiä, joista tässä artikkelissa esittelen yhden tunnetuimmista eli DAMA Internationalin DMBok 2.0 – viitekehyksen. Viitekehystä ei ole virallisesti käännetty suomeksi, joten nämä käännökset ovat tulkintoja englanninkielisille termeille. Tästä viitekehyksestä käytetään myös lempinimeä copyright versio tähän artikkeliin
“DAMA-Wheel”, joka kuvaa hyvin tiedonhallinnan työtä. Pyörässä on kuvattu 11:nä sektorina näkemys tiedonhallinnan osa-alueista ja akselina on tiedon ohjaus ja johtaminen, joka pyörittää toimintaa.
Dama viitekehyksestä on olemassa toinenkin kuva, jossa tiedonhallinta on kuvattu enemmän tiedon elinkaaren ja operatiivisen mallin kautta. Tässä artikkelissa kuitenkin pysytään nyt alkuperäisen DAMA-Wheelin viitekehyksessä ja ensimmäisessä vaiheessa kuvataan lyhyesti Ensimmäiset 3 sektoria, jotka vaikuttavat erityisesti siihen, miten suunnitellaan tiedonhallintaa. Myöhemmin käydään läpi muita sektoreita, näiden erityispiirteiden osalta. Sektorit, jotka tässä artikkelissa ovat mukana ovat: tietoarkkitehtuuri, tietomallinnus ja metadatan hallinta.
Tietoarkkitehtuuri
Tietoarkkitehtuuri on kuvassa ylimmäisenä ja ensimmäisenä sektorina ihan syystä. Koko tiedonhallinta pohjautuu siihen, että meillä on vahva tietoarkkitehtuuri. Tietoarkkitehtuurilla kuvataan arkkitehtuuria tietojen näkökulmasta. Tietoarkkitehtuuri on yksi osa-alue myös organisaation kokonaisarkkitehtuurikuvauksissa. Tietoarkkitehtuuri joskus virheellisesti mielletään tietojärjestelmäarkkitehtuuriksi, Se ei kuitenkaan kuvaa järjestelmä- eikä prosessiarkkitehtuuria. muutoin kun tietovirtojen osalta. Tietoarkkitehtuurin tehtävänä on kuvata, mitä tietoja organisaatiossa on ja miten ne liittyvät toisiinsa. Tietoarkkitehtuuriin kuuluu myös kuvaus, missä tiedot sijaitsevat ja miten ne liikkuvat organisaatiossa eli tietovirrat. Tietoarkkitehtuurin tärkeimpiä dokumentaatioita onkin tietomallit, joista organisaation liiketoiminnan termistön kuvaama käsitemalli on kaiken pohjana.
Tiedon kuvaamisessa tulee lähteä liikkeelle liiketoiminnallisten sanojen kuvaamisella ja jättää myöhempään vaiheeseen tekninen tietojen kuvaaminen. Tällä varmistetaan, että sama liiketoimintatieto ymmärretään eri osa-alueilla samalla tavalla ja voidaan ns. linkittää myöhemmin kuvattava tekninen tieto liiketoiminnan käyttämään sanaan eli käsitteeseen. Tekninen kuvaus tarvitaan myös, mutta lähtökohtana on ensin ymmärtää toimintaan liittyvät käsitteet. Esimerkiksi meillä on käsite asiakas, johon liittyy tietoina mm. asiakkaan nimi ja osoite. Koko organisaation tasolla tulee ymmärtää asiakas samalla tavalla. Teknisissä ratkaisuissa voi olla eroja, esim jokin ratkaisu kohdistuu vain henkilöasiakkaisiin ja toinen yritysasiakkaisiin.
Käsite siis kuvaa tietojen kokonaisuutta, joilla kaikilla on yhteinen tunniste. Asiakas-käsitteellä tuo yhteinen nimittäjä voi olla esim. asiakasnumero tai henkilötunnus. Käsite voi olla konkreettinen näkyvä asia tai se voi olla abstrakti asia. Käsitteiden välillä on luonnollisia suhteita ja nämä suhteet kuvataan myös. Näin saadaan aikaan ns. käsitemalli. Käsitemalli on siis ylätason kuvaus toiminnassa tarvittavista asioista ja näiden välisistä suhteista. Näistä tiedoista, jotka liittyvät käsitteeseen käytetään usein sanaa attribuutti.
Käsitteiden lisäksi on kuvattava myös tarkemmalla tasolla tiedot eli aikaisemmin mainitut attribuutit. Lisäksi teknistä ratkaisua kuvattaessa on tunnistettava tekniset vaatimukset tietojen osalta. Tietoa siis kuvataan usealta tasolta sen käyttötarkoituksen mukaisesti. Näiden teknisten tietomallien rooli näkyy vahvemmin seuraavassa sektorissa eli tietomallinnuksessa.
Tietomallinnus
Tietomallit rakentuvat tietojen järjestelmällisestä kuvaamisesta. Kuten jo edellä tietoarkkitehtuurin yhteydessä kerrottiin, tietoja kuvataan usealla eri tasolla, koska tietoihin liittyy erilaisia tarpeita. Kuvausta tarvitaan sekä liiketoiminnan että teknisen ratkaisun ymmärtämässä muodossa.
Ylätasolla kuvatut käsitteet muodostavat liiketoiminnan konseptuaalisen tason tai kuten DAMA viitekehyksessä puhutaan kontekstitasosta. Näillä sis ei ole vielä sidosta mihinkään tekniseen ratkaisuun.
Tietomallin seuraavalla tasolla lähestyttäessä teknistä toteutusta kuvataan tiedot loogisena kokonaisuutena. Erona konseptitasoon on se, että nyt tarkennetaan tietojen kuvauksia ja myös tarkennetaan eri käsitteiden välisiä suhteita. Mahdollisesti myös syntyy uusia käsitteitä, jotka tukevat tarkemman tason kuvaamisvaatimuksia. Esimerkiksi tilanteessa, jossa on käsitteet asiakas ja sopimus ja käsitemallissa on tunnistettu näiden välillä yhteys, tarkennetaan loogisessa mallissa tuota yhteyttä. Mikäli asiakkaalla voi olla useita sopimuksia ja vastaavasti sopimuksessa voi olla useita asiakkaita, tulee tämä yhteys “purkaa” uudella käsitteellä asiakkaan_sopimus, jotta tiedetään kenen asiakkaan sopimuksesta kulloinkin on kyse. Loogisella ja teknisellä tasolla siis pitää tietää tarkasti millaiset yhteydet käsitteiden välillä on
Tekninen tietomalli kuvaa teknisen ratkaisun tarpeet. Eli siinä on jo mukana tieto, mitä tauluja ja näihin liittyviä attribuutteja meillä ratkaisuun on tulossa. Mahdollisesti myös muokataan loogisen mallin käsitteitä uuden muotoisiksi tauluiksi.
Yleissääntönä pidetään, että käsitetasosta siirryttäessä tarkempaan kuvaustasoon syntyy noin viisinkertainen määrä loogisia käsitteitä ja loogisista käsitteistä tulee mahdollisesti kaksin tai kolminkertainen määrä lopullisia tauluja teknisen ratkaisun toteutukseen.
Jotta tietomalleista tulee ymmärrettäviä, tulee ne tehdä standardoidulla notaatiolla. Yleisesti tunnettuja notaatioita ovat mm. “harakanvarvasnotaatio” ja UML:n luokkakaaviot. Harakanvarvasnotaatio toimii hyvin käsitteellisellä tasolla. Molemmat notaatiot toimivat hyvin, kun kuvataan tietoja ja näiden välisiä suhteita. Itse käytän harakanvarvasnotaatiota, koska se on visuaalisesti kuvaavampi. Harakanvarpaiden avulla kuvataan, millaisia suhteita eri käsitteiden välillä on.
Tietomallinnukseen on olemassa siihen dedikoituja työvälineitä, joissa saadaan myös kuvattua tiedot tarkemmin. Tietomallinnusvälineen käytössä on se etu, että kaikki kuvatut tiedot ovat samassa ns. repositoryssa, eli tietokannassa. Näitä tietoja voidaan uudelleen hyödyntää, kun tietomalliin tulee laajennuksia tai kuvataan uusi tietomalli eri käyttötapauksen näkökulmasta. Toki jo se, että on olemassa graafinen kuva, auttaa ymmärtämään tietojen rakentumista organisaatiossa. tarkalla tasolla tietojen dokumentointi tuottaa meille organisaation metadataa.
Metadatan hallinta
Kolmantena sektorina tässä artikkelissa käydäänkin läpi tarkemmin, mitä on metadata ja miksi sitä tarvitaan. Metadata on siis tietojen kuvausta. Voisikin sanoa, että tarvitaan metadataa, jotta ymmärretään dataa eli tietoa. Metadatan merkitys tulee esille parhaimmin siinä, kun tietoa hyödynnetään. Kun tiedoista on tehty metadatakuvaukset, niin ymmärrämme tiedot oikein.Esimerkiksi asiakas-käsitteen metadatassa kuvataan mitä asiakas- käsite tarkoittaa ja mitä tietoja siihen liittyy. Tiedolle dokumentoidaan tarkalla tasolla, mitä tieto tarkoittaa ja miten sitä tulee käyttää. Yleisimmin metadataan kuvataan tiedon nimi, kuvaus, sen muoto kuten pituus ja merkkisyys. Lisäksi voidaan kuvata, missä tietoa syntyy, missä sitä käytetään, millaisia sääntöjä tiedon hallinnointiin ja sen laadun varmistamiseen on.
Metadata ei siis ole vain teknistä kuvausta tiedoista, vaan siihen kuuluu ainakin myös näiden hallinnoinnin kuvaaminen, ja liiketoiminnan sekä laadunvarmistuksen säännöt. Metadataan dokumentoidaan myös tietoturvaan ja tietosuojaan liittyvä ohjaus.
Metadataa voidaan kuvata excelillä, mutta vielä parempi tapa on kuvata metadata joko tietomallinnusvälineeseen tai metadatan hallintaratkaisuun. Metadatan kuvaamiselle tulee organisaatiossa olla yhteinen kuvauspohja, jotta kaikki tiedot kuvataan samalla tavalla
Tavoite on kuvata kaikki organisaation metadata samalla muotilla ja samaan paikkaan, jotta näitä voidaan käyttää parhaalla mahdollisella tavalla.
Viime vuosien hittisana “Data Catalog” on paikka jonne metadataa voidaan kerätä teknisistä ratkaisuista automatisoiden. Tämä toimintamalli tehostaa metadatan hallintaa, kun muutokset tiedoissa tulevat automaattisesti näkyviin myös metadatan puolelle. Data Catalog toimii tiedon hyödyntäjille listana, josta nähdään, mitä tietoja on käytettävissä. Teknisen data catalogin lisäksi tulisi joko samassa tai erillisessä ratkaisussa olla myös liiketoimintasanasto. Liiketoimintasanaston tuottaminen automaattisesti on vaikeampaa, koska liiketoimintaa ei ole kuvattu useinkaan järjestelmällisesti. Tietomallinnusväline otimii hyvänä liiketoimintasanastona myös.
Metadatan rooli on tärkeä koko tiedon elinkaaren osalta. Ei voida olettaa, että kerran suunniteltu tieto pysyisi samana, vaan tietojen kuvauksiin tulee aina muutoksia.
Käytännön esimerkki
Tietoarkkitehtuuri lähtee siis liikkeelle siitä, että tunnistetaan organisaation tärkeät tiedot. Mistä nämä tiedot sitten löytyvät? Käytännössä meillä on kaksi lähtökulmaa. Tietoja lähdetään kuvaamaan joko täysin “puhtaalta pöydältä” tai sitten olemassa olevaa kuvaillen. Näistä molemmista on omakohtaista kokemusta ja tässä muutamia tärkeimpiä havaintoja työstä.
Molemmissa vaihtoehdoissa tiedot löytyvät liiketoiminnan käyttämästä termistöstä. Ei siis teknisistä tietoratkaisuista. Puhtaalta pöydältä lähdettäessä liikkeelle liiketoiminnalla on olemassa tietotarpeita, jotka tunnistetaan. Olemassa olevaa ympäristöä kuvattaessa voidaan lähteä liikkeelle esim. raportoinnin tietojen kautta. Molemmista lähtökulmista päästään siis liikkeelle, koska sekä tietotarpeista että raporteista on löydettävissä liiketoiminnan käsitteet, jotka ovat tietoarkkitehtuurin runko.
Koska puhutaan liiketoiminnan kieltä, tulee tietojen määrittelyyn osallistua liiketoiminnasta henkilöitä. Ei riitä, että meillä on vain raportin tai teknisen ratkaisun toteuttajat mukana kuvaamassa tietoja. ERP:ien yleistyttyä organisaatioissa on alkanut näkyä ilmiö, jossa kielenä puhutaan esim “SAP”:ia eikä enää käytetäkään liiketoiminnan omia termejä. Mukaan siis tarvitaan liiketoiminnan ymmärtäjiä sekä tiedon tuottamisen että tiedon hyödyntämisen näkökulmista, jotta saadaan kaikkien näkemykset tiedoista kuvattua. Lopulliseen käsitemalliin tehdään kuitenkin tarvittavia kompromisseja valittujen käsitteiden osalta, jotta saadaan yhtenäinen termistö eli ns. yhteinen kieli. . Valittujen käsitteiden rinnalla voidaan dokumentoida myös näistä käytettävät synonyymit, koska tietyissä liiketoimintaprosesseissa on käytettävä tiettyä sanastoa.
Raportointi on ollut myös hyvä lähtökulma, kun dokumentoidaan organisaation tietovirtoja. Raportoinnista “peruutetaan taaksepäin” tiedon syntyyn asti samalla dokumentoiden tietovirran eri prosessit tekniset ratkaisut ja näiden käsitteet.
Viikon vinkit tietoarkkitehtuuriin ja käsitemallinnukseen
- Kuvataan tietoarkkitehtuurin runko, eli käsitteet liiketoiminnan kielellä
- Piirretään käsitemalli yksinkertaisena kuvana, jossa ei ole yksityiskohtia
- Käsitemallinnus on iteratiivista työtä, jossa mallia tulee muuttaa, kun liiketoimintaympäristö muuttuu
Käsitemallin avulla sitoutetaan ja koulutetaan organisaatiota käyttämään yhteistä kieltä
Minna Oksanen
