Hei,
Kuten olemme saaneet todistaa, semanttinen kerros käsitemalleineen on noussut takaisin huomion keskipisteeseen tekoälyn myötä. Edellisessä blogissa käsittelin contextual layeria, joka on yksi näkökulma tähän kokonaisuuteen.
Syy on selvä: tekoälyn hyödyntämiseen kohdistuu valtava paine, mutta ilman kontekstia se ei ymmärrä, mistä datassa on kyse.
Samasta syystä kaikki suuret data-alustatoimijat ovat lähteneet rakentamaan omia “semanttisia kerroksiaan”. Snowflake puhuu Semantic Vieweistä ja OSI:sta, Databricks Unity Catalogista. Suunta on oikea: data tarvitsee kontekstia.
On kuitenkin hyvä ymmärtää yksi keskeinen rajoite.
Suurin osa nykyisistä semanttisista kerroksista keskittyy mittareiden, dimensioiden ja liittymien määrittelyyn. Tämä on erittäin hyödyllistä: se standardoi raportointia ja varmistaa, että dataa kysytään yhtenäisesti.
Silti kyse on pitkälti alustaan sidotusta metadatasta.
Se ei vielä anna varsinaista liiketoiminnan käsitemallia tai ymmärrystä siitä, miten asiat liittyvät toisiinsa.
Tämä rajoite tulee nopeasti vastaan, kun mennään raportoinnin ulkopuolelle.
Jos järjestelmän pitää tehdä päätöksiä, ohjata prosesseja tai yhdistää tietoa useista lähteistä, pelkkä yhtenäinen määrittely ei enää riitä. Tarvitaan ymmärrys siitä, mitä asiat oikeasti ovat ja miten ne liittyvät toisiinsa.
Esimerkiksi valmistavassa teollisuudessa:
- yritys ostaa komponentteja toimittajilta
- rakentaa niistä tuotteita
- ja myy tuotteet asiakkaille
Jos yksi komponentti puuttuu, kysymys kuuluu:
Mitkä asiakastoimitukset viivästyvät?
Enkä kysy yhtä mittaria.
Tarvitset ymmärrystä useiden käsitteiden ja niiden välisten suhteiden yli:
- komponentit
- tuotteet
- tilaukset
- asiakkaat
- toimittajat
Toisin sanoen sinun pitää ymmärtää, miten nämä liittyvät toisiinsa, ei vain mitä ne ovat.
Lisäksi toinen käytännön haaste on hajanaisuus.
Vaikka semanttisia kerroksia kutsutaan joskus “avoimiksi”, ne elävät usein yhden alustan sisällä. Kun mukaan tulee useita ympäristöjä, kuten Snowflake, Databricks, SaaS-järjestelmät ja legacyt — merkitykset hajoavat uudelleen.
Jokainen järjestelmä kuvaa todellisuutta omalla tavallaan.
Siksi pelkkä alustan sisäinen semanttinen kerros ei vielä ratkaise koko ongelmaa.
Alla kerron modernista ja tähän use caseen sopivasta tiedon mallinnuksen prosessista. Se on erittäin toimiva tapa päästä alkuun alustariippumattomasti. Sen avulla voidaan määrittää terminologia ja käsitteiden väliset yhteydet.
1. Aloita liiketoiminnasta
Ensimmäinen askel ei ole tekninen, vaan liiketoiminnallinen.
Keskustele sidosryhmien kanssa ja selvitä, mitä esimerkiksi asiakas, tilaus tai tuote oikeasti tarkoittavat teidän organisaatiossanne.
Yllättävän usein, käytännössä poikkeuksetta, eri tiimit ymmärtävät samat käsitteet eri tavoin.
2. Tunnista synonyymit ja ratkaise homonyymit
Et voi pakottaa kaikkia yksiköitä käyttämään samaa terminologiaa.
Esimerkiksi taloushallinto ja markkinointi voivat käyttää käsitteitä “asiakas” tai “account” eri merkityksissä.
Voit kuitenkin tehdä erot näkyviksi: määrittää synonyymit ja tunnistaa homonyymit.
Tämä on kriittistä, jotta väärinkäsitykset eivät siirry dataan tai KPI:hin.
Emme voi laskea esimerkiksi asiakkaan elinkaaren arvoa tai asiakashankintakustannuksia, jos emme ymmärrä, mitä “asiakas” tarkoittaa.
3. Määrittele käsitteiden väliset suhteet
Yksittäinen käsite voi olla epäselvä. Merkitys syntyy usein suhteista.
Esimerkiksi:
- Asiakas → tekee → Tilauksen
- Tilaus → sisältää → Tuotteen
Tätä vaihetta kutsutaan käsitemallinnukseksi (conceptual data modeling).
Tässä vaiheessa määritetään myös liiketoiminnan logiikka ja keskeiset säännöt.
Esimerkiksi:
- voiko asiakas tehdä useita tilauksia
- voiko tilaus sisältää useita tuotteita
- voiko tuote kuulua useaan tilaukseen
Nämä säännöt ovat usein juuri sitä hiljaista tietoa, jota ei ole kunnolla dokumentoitu, mutta joka ohjaa toimintaa käytännössä.
Ilman näitä sääntöjä malli näyttää oikealta, mutta ei vastaa todellisuutta.
4. Lisää attribuutit
Keskeisten attribuuttien lisääminen auttaa erityisesti data-asiantuntijoita osallistumaan prosessiin.
Liiketoiminta voi kuvata käsitteitä yleisellä tasolla, mutta yhtä tärkeää on määrittää, mitä tietoa niistä tallennetaan.
Esimerkiksi asiakas voi sisältää:
- nimi
- asiakastyyppi
- status
Tämä vie mallia kohti loogista datamallinnusta.
5. Hyödynnä tekoälyä
Tekoäly voi auttaa luomaan ensimmäisiä määritelmiä ja kuvauksia.
Mutta liiketoiminnan täytyy edelleen validoida lopputulos.
Tavoitteena on kuvata organisaation omat nyanssit. Mitä geneerisempi malli, sitä vähemmän siitä on hyötyä.
AI nopeuttaa, mutta ei korvaa ymmärrystä.
6. Lisää hallintatiedot (governance)
Konteksti ei ole pelkästään merkitystä, vaan myös vastuuta.
Esimerkiksi:
- kuka omistaa mittarin
- kuka vastaa datasta
- missä järjestelmässä tieto syntyy
Ilman omistajuutta tämä prosessi ei yleensä toimi.
Kun omistajuus on määritelty, käsitteistä tulee oikeita yrityksen assetteja.
7. Kytke malli todellisuuteen
Seuraavaksi malli yhdistetään dataan: skeemat linkitetään käsitteisiin.
Tekoäly auttaa yhdistämään tauluja ja sarakkeita liiketoimintakäsitteisiin.
Tässä vaiheessa design kohtaa todellisuuden.
8. Varmista teknologia
Kaikki tämä toimii vain, jos tieto on saatavilla ja ajan tasalla.
Vaikka aloitimme liiketoiminnasta, jossain vaiheessa on ratkaistava, missä semanttinen kerros elää.
Pelkkä data-alusta ei yleensä riitä.
BI-työkalut taas johtavat usein pistemäisiin ratkaisuihin.
Toteutustapa
Siksi kannattaa miettiä organisaatiolle sopivin ratkaisu.
Itse suosin, että ensimmäinen versio tehdään manuaalisesti. Se toimii hyvänä pohjana myöhemmälle toteutukselle.
Yksi vaihtoehto on erillinen teknologiaratkaisu, joka toimii semanttisena kerroksena alustasta riippumatta.
Olennaista on, että:
- versionhallinta toimii
- määritelmät ovat helposti saatavilla
- tekoäly on osa prosessia
Lopuksi
Monelle tämä prosessi on tuttua: tiedon mallinnuksessa on pitkään puhuttu käsite-, loogisesta ja fyysisestä tasosta.
Yllä kuvatussa lähestymistavassa painotetaan perinteistä mallinnusta enemmän liiketoimintametadatan roolia.
Toinen keskeinen alue on mallien ja metadatan jakaminen, versionhallinta ja ylläpito.
Kolmas merkittävä ero on tekoälyn tuominen mukaan prosessiin.
Perinteisesti mallinnusta on tehty tietokantojen ja alustojen suunnitteluun tai data governancen yhteydessä.
Tässä käyttötapauksessa fokus on tekoälyn hyödyntämisessä data-analytiikassa.
Meillä on todella mielenkiintoinen Tiedon mallinnus -koulutus tulossa keväällä, jossa syvennytään juuri näihin teemoihin! Katso lisätiedot täältä.
Ystävällisin terveisin,
Johannes Hovi
P.S. Myös merkittävä osa data governance -ongelmista ratkeaisi tällä lähestymistavalla, mutta se on toisen kirjoituksen aihe.
