Edellisessä blogissani kerroin miten käsitemallista voidaan edetä loogiseen malliin ja tähtimalliin.
Nyt jatkan samaa käsitemalliesimerkkiä menemällä syvemmälle itse käsitteiden määrittelyyn.
Käsitteiden tunnistaminen
Me ihmiset opimme käsitteiden tunnistamista noin yksivuotiaana. Taapero osoittaa sormellaan ja sanoo ”auto”, ”heppa”, ”hauva”. Hän siis tunnistaa reaalimaailman kohteita ja pystyy kielen avulla kommunikoimaan niistä.
Yrityskontekstissakin monet käsitemallinnuksen käsitteet tuntuvat melko selviltä, vaikkapa ”Tuote” tai ”Asiakas”. Mutta asia ei ole niin yksinkertainen.
Tuote vai nimike?
Esimerkiksi käsitteen ”Tuote” kohdalla voi olla, että organisaatiossa jotkut puhuvat tuotteista, toiset nimikkeistä ja kolmannet artikkeleista. Liiketoiminnan henkilöt ehkä käyttävät termejä tuote, puolivalmiste, raaka-aine ja valmiste – kaikilla oma merkityksensä. Mutta käytössä olevassa tietojärjestelmässä näitä kaikkia kutsutaankin nimikkeiksi (esim SAPissa item).
Tällaisessa tilanteessa on hyvä tehdä ”Tuote” -käsitteestä oma käsitemallinsa, joka kattaa kaikki aiheeseen liittyvät termit, kuten mainitut puolivalmisteet, raaka-aineet, nimikkeet jne. Ja myös määritellä hyvin kukin käsite.
Pääkäsitemallissa päätetään sitten yhteisesti, mitä liiketoiminnan termiä käytetään. Muut käytössä olevat termit kuvataan myös. Niitä varten meillä on kuvauksissa kohta synonyymit. Näin kaikki näkemykset saadaan dokumentoitua yhteiseen määrittelypankkiin.
Mikä on tilaus
Otetaan toinen esimerkki. Olin hakupalveluja tarjoavassa yrityksessä tekemässä käsitemallinnusta liiketoimintaihmisten kanssa, mukana mm. markkinointijohtaja ja myyntipäällikkö.
Tuli pitkä keskustelu siitä mikä on ”Tilaus”. Toisten mielestä tilaus on tapahtuma, josta tulee rahaa. Toiset rakensivat nettiin ilmaisia palveluja, joilla käyttäjät saadaan rekisteröitymään ja toivon mukaan myöhemmin maksaviksi asiakkaiksi. Heidän kielenkäytössään nämäkin olivat tärkeitä ”Tilauksia”.
Voidaan siis istua palaverissa puhumassa tilauksista ja siitä paljonko meillä on tilauksia. Toinen puhuu aidasta, toinen aidanseipäästä. Kommunikointi ei pelaa.
Jos on tarkoitus analysoida, tutkia ja raportoida tuotteita, tilauksia, asiakkaita jne, on ensimmäinen edellytys, että ymmärretään mitä näillä käsitteillä juuri meidän organisaatiossamme tarkoitetaan. Käsiteet on yhteistyössä määriteltävä.
Esimerkkejä
Käsitteiden määrittelyssä kuvataan useita asioita. Käyn niitä tässä läpi esimerkkien avulla.
Mutta katsotaan ensin jo edellisessä blogissani esitettyä esimerkkikäsitemallia. Malli kuvaa yritystä, joka myy huonekaluja yrityksille ja muille organisaatioille.
Mallin kohdealue eli domain on laskutus. Asiakkaat siis ovat tilanneet tuotteita, ja niistä on sitten tehty laskuja. Yhteen laskuun liittyy yleensä monta tuotetta (edellisessä blogissani kerron tästä yhteydestä tarkemmin).
Työntekijät ovat myyneet tuotteita, ja myyntiprovisioiden laskemiseksi on oltava tiedossa, kuka on myynyt mitäkin. Siksi henkilöt liittyvät laskuihin. Työntekijät kuuluvat pääosin tiimeihin ja kaikki kuuluvat johonkin organisaatioyksikköön.
Mikä on hintasopimus? Löydät sen määritelmän alempana.
Käsitteiden määrittelyjä
Tämän blogin aihe on oikeastaan metadata. Metadata on tietoa tiedosta. Tietokannassa oleva numero 231456 ei sellaisenaan kerro mitään. Jos tiedämme, että tuo numero on ”asiakasnumero” -nimisessä kentässä, ymmärrämme numeron merkityksen. 231456 on dataa, termi ”asiakasnumero” (eli attribuutin nimi) on metadataa, joka siis kuvaa dataa. Asiakasnumerolle voidaan vielä lisätä tarkentava huomautus, esim. ”tietojärjestelmän antama juokseva numero”. Sekin on metadataa, joka lisää ymmärrystämme
Mitä kaikkea metadataa käsitteestä sitten tulisi kuvata? Minusta ei tässä kohtaa kannata pyrkiä täydellisyyteen. On haettava sopivaa kompromissia työn määrän ja kuvausten hyödyllisyyden välillä.
Aika hyvä taso saavutetaan, jos käsitteistä saadaan kuvattua seuraavat; käsitteen sanallinen määritelmä, käytännön esimerkkejä, synonyymit, tärkeimmät järjestelmät (jossa ko. käsitteen tietoa on) ja mahdollisesti muutama attribuutti. Kaikista käsitteistä ei tarvitse näitä kaikkia kuvata, mutta mitä epäselvempi käsite on, sitä enemmän metadatasta on hyötyä.
Alla olevassa esimerkkikuvassa on asiakkaan metadataa.
Attribuuttien kohdalle tässä käsitetasolla ei välttämättä tarvitse laittaa mitään (attribuutithan kuvataan erikseen), mutta esim. pääavaimet selventävät käsitettä, kuten vaikkapa asiakasnumero, Y-tunnus ja laskunumero.
Synonyymeihin voidaan kuvata juuri ne muut termit, joita samasta käsitteestä on yrityksessämme käytössä. Kuvassa oleva termi ’Account’ on usein tietojärjestelmien tietokannoissa kuvaamassa asiakasta.
Esimerkit ovat erittäin hyvä lisä metadatassa. Käsitteet saattavat tuntua hieman abstrakteilta, mutta ottamalla esimerkkejä oikeasta datasta saadaan konkretiaa. Esimerkeillä kuvataan yhtä tai useampaa käsitteen esiintymää, eli juuri niitä reaalimaailman kohteita, jota käsite edustaa.
Yllä kuvassa asiakkaan esimerkeistä paljastuu asiakkaan voivan olla yritys, kunta tai vaikka rekisteröity yhdistys. Määritelmästä jo nähtiin, että yksityishenkilöt eivät ole asiakkaita.
Alla on toinen käsitemääritysesimerkki, käsitemallin hintasopimuksesta.
Huomaatko, kuinka paljon lisäymmärrystä tämä määrittely tuo, verrattuna pelkkään käsitemalliin?
Attribuuttien metadata
Alla on esimerkki asiakkaan attribuuttien metadatasta. Kuvassa esimerkinomaisesti vain muutama attribuutti. Itsestään selviä, kuten nimi, ei tarvitse kuvata. Kuvauksen lisäksi mahdollista attribuuttien metadataa ovat: tietotyyppi, pituus, pakollisuus, perusavain jne.
Asiakaskoodi on esimerkki tietokentästä, jonka nimi operatiivisessa järjestelmässä on epäselvä (tällaisia kenttiä on usein paljon!). Tämän pääkäyttäjältä saadun määrittelyn avulla tiedämme mitä asiakaskoodi tarkoittaa.
Näin on saatu vain joidenkin tai jopa vain yhden henkilön (joka on juuri jäämässä eläkkeelle…) tiedossa olevaa hiljaista tietoa dokumentoitua.
Tämä onkin yksi koko käsitemallinnuksen metadatakuvaamisen suuria hyötyjä: eri puolilla taloa olevien asiantuntijoiden tietämystä ja ei-dokumentoitua tietoa saadaan kuvattua ja talteen. Parhaimmillaan yhteiskäytössä olevaan, pilvipohjaiseen metadatavälineeseen (näissä blogeissa on käytetty Ellietä).
Jos käsitemallinnusta tehdään tavoitteena rakentaa tietokanta, valitaan termit tietysti mahdollisimman hyviksi jo alusta asti.
Yritystason näkökulma
On tilanteita, joissa mallinnetaan vain jotain domainia. Mutta jos tavoitteena on olla aidosti tieto-ohjattu organisaatio, tavoitteena on kuvata yrityksen kaikki tärkeät tiedot. Erityisasemassa ovat monille domaineille yhteiset käsitteet. Konsulttimme Hannu Järvi kutsuu tärkeimpiä käsitteitä kiintopisteiksi.
Silloin esimerkiksi käsite ”Asiakas” määritellään siten, että se voidaan hyväksyä koko organisaatiossa. Jos asiakasalue on monimutkainen, kannattaa tehdä itse asiakkaasta oma malli. Usein syntyy tarkentavia alakäsitteitä, kuten yritys ja henkilö, joilla sitten on omat määritelmänsä ja tyypillisesti omia attribuutteja tai yhteyksiä. Esimerkiksi Yritys-käsitteellä on Y-tunnus, Henkilö-käsitteellä on hetu.
Tällainen tarkastelu on erittäin tärkeää tietoa kommunikoidessa analyysi- ja raportointiratkaisuista.
Käyttöaluieta
Kun käsitteet ja attribuutit tällä tavoin määritellään, syntyy samalla eräänlainen organisaation ”sanakirja” tai ”business glossary”, jossa on määritelty yrityksen ydintiedot. Jos uudelle työntekijälle annetaan käsitemallit ja määritelmät, hän on hetkessä mukana yrityksen keskusteluissa!
Hyvin tärkeä käyttöalue on data-analytiikka ja DW/BI (ns tietojen toisiokäyttö). Käsitemallien avulla saadaan ratkaisut heijastelemaan liiketoiminnan näkemyksiä.
Tietovaraston, analyysien ja raporttien tekijät löytävät valmiita määrittelyjä ymmärryksensä tueksi eikä heidän tarvitse aloittaa haastattelukierroksia alusta.
Uuden tietojärjestelmän tietokantaa rakennettaessa käsitemallien tueksi tehdyt hyvät metadatamäärittelyt nopeuttavat toteutusporukan työtä kohtalokkaiden väärinkäsitysten vähentyessä. Ylläpitotilanteet käsitemallien ja hyvien määritysten kautta auttavat pitämään tietokannan selkeänä.
Isoissa tietojärjestelmämuutoksissa ja hankinnoissa huomataan usein, että ko. järjestelmä käyttää hieman erilaisia käsitteitä kuin oma liiketoiminta. Käsitteiden määrittelyiden vertailu ko. järjestelmän käyttämiin määrityksiin on tärkeä lisä ”tietojärjestelmäkulttuurin” ja oma kulttuurin yhteensovittamisissa.
Lopuksi
Käsitemallinnuksen eduista on puhuttu paljon, meidän blogeissammekin. Käsitteiden ja attribuuttien sopivan tasoinen määrittely nostaa käsitemallien hyödyllisyyttä huomattavasti.
Olen itse tehnyt paljon mallinnusta yhdessä liiketoiminnan kanssa. Edellisen blogin yhteydessä tuli kysymyksiä, että kuinka tämä tehdään. Kuinka saada liiketoiminta kiinnostumaan mallinnuksesta? Kirjoitan tästä myöhemmin lisää.
Käsitemallinnus hyvin tehtynä muodostaa yritykselle liiketoimintalähtöisen informaatioarkkitehtuurin. Kun teemme mallinnusta eri alue (domain) kerrallaan hyväksikäyttäjen selkeitä ja jaettuja määrityksiä, saamme lopulta aikaiseksi hyvin dokumentoidun kuvan data-asseteistamme.
Ystävällisin terveisin,
Ari Hovi
Ps. Nyt olisi tarjolla etätoteutuksena erittäin ajankohtainen koulutus, joka vetää alan huippu Rick van der Lans!
Practical Guidelines for Designing New Data Architectures 02.03 – 03.03.2022
Älä missaa tätä perustavanlaatuista tietopakettia data-arkkitehtuurien suunnittelusta. Kurssilla on vielä paikkoja jäljellä, eli vielä ehdit mukaan!
Data-arkkitehtuuria ei suunnitella joka päivä, joten käytä nyt maailman huippuosaaminen hyväksesi ja vältä sudenkuopat jo alkumetreillä.
Kurssilla käydään läpi yleisimmät kysymykset ja tekniikat, kuten data lakes, big data, data vault, pilvi, tietojen virtualisointi, Hadoop, NoSQL, tietovaraston automaatio.
Lisätiedot ja ilmoittautuminen tästä.
