Hei,
Kuten te hyvät lukijat tiedätte, olen tehnyt ja kehittänyt käsitemallinnuksena (conceptual data modeling, business oriented data modeling) tunnettua menetelmää ison osan urastani.
Käsitemallinnus on tiedon mallinnukset korkein taso, josta edetään on loogiselle taso (logical data modelling) ja sitten fyysinen ja tarkin (physical data modeling) tietokanta taso.
Yritysten datat ovat suurimmaksi osaksi siellä tietokannoissa, joten siksi nimenomaan tiedon mallinnus on siihen oikea menetelmä, eikä esimerkiksi prosessi-, järjestelmämallinnus.
Kokonaisarkkitehtuurin yhteydessä puhutaan myös mallinnuksesta, mutta sekin on eri asia kun tiedon mallinnus (tietomallit ovat usein osa laajempaa kokonaisarkkitehtuuria).
Kaikki nämä mallinnustavat ovat tärkeitä, mutta mikäli kohteena on data-analytiikka tai muu datan hyödyntämiseen liittyvä hanke, käytä aina tiedon mallinnusta ensisijaisena menetelmänä.
Se on erittäin tehokas ja siksi hyvin suosittu menetelmä moneen data- ja IT-alan hankkeisiin. Tiivistän seuraavaksi, että miksi näin on.
Väärinymmärrykset ovat aikasyöppö
Käsitemallinnuksen abstraktiotaso sopii hyvin liiketoiminnan edustajien kanssa keskusteluun ja siksi menetelmä on niin hyvä juuri vaatimusmäärittelyihin.
Tavoitteena on silloittaa sitä kuilua tai harmaata aluetta mikä vallitsee liiketoiminnan ihmisten ja tietojärjestelmä/tietokanta-asiantuntijoiden ja välillä.
Käsitystä datoista kyllä onkin, mutta se yleensä sirpaloitunutta, eri ihmisten päissä, hiljaisena tietona. Käsitemallinnuksen avulla voimme koota näitä näkemyksiä yhteiseen karttaan ja saavuttaa yhteinen ymmärrys
Näin säästetään valtavasti aikaa, koska vältetään väärinymmärrykset, niistä johtuvat virheet ja niiden korjaamiseen menevä aika, useat jatkopalaverit, Teams-keskustelut, sähköpostit ja muu “ylimääräinen” selvitystyö.
Olen nähnyt erittäin paljon sitä, että tietoasiantutijat koittavat tuskissaan päätellä lähdejärjestlmistä käsin mistä datassa on kyse, kun kaiken voisi hoitaa suhteellisen kivuttomasti mallinnnustyöpajoissa liiketoiminan ja lähdejärjestelmien adminien kanssa.
Ymmärrän, että monelle IT-asiantuntijalle mallinnustyöpajan vetäminen liiketoiminnan edustajien kanssa ei ole aina helppoa. Minä olen alunperin ihan samanlainen “propellipää koodari”, mutta harjoittelun kautta aloin oppia.
Käydään läpi hieman vinkkejä
Perusperiaatteita
Ensin pitää tietysti saada liiketoiminnan ihmiset ylipäänsä tulemaan mallinnustyöpajaan. On tärkeää motivoida mallinnukseen haluttuja henkilöitä, perustelemalla miksi työ on tärkeää.
Kannattaa lähteä hyödyistä ja tavoitteista liikkeelle. Mallinnustyöpajassa tehdään esimerkiksi vaatimusmäärittelyä dataprojektille, jonka kautta liiketoiminta saa parempaa dataa omasta liiketoiminta alueesta päätöksenteon tueksi.
“Liiketoiminta” on terminä hieman hämäävä, koska sillä usein tarkoitetaan voi monen tyyppisiä osaajia tai vaikka eri IT-järjestelmien vastuuhenkilöitä. Kuka vain voi toimia ns “tietolähteenä, esimerkiksi business controller.
Terveydenhoidon alalla hyvä mallinnuksen osallistuja voisi olla esim potilasjärjestelmän pääkäyttäjänä toimiva sairaanhoitaja.
On tärkeää pitää mallinnusistunnot liiketoimintalähtöisinä. Käytetään siis vain liiketoiminnan termejä; ei ei puhuta it-termeillä, ei tietokannoista, tietovarastoista, netistä yms. asioista, eikä missään tapauksessa käytetä mitään IT-lyhenteitä.
Jos mallinnetaan pankkitoimintaa, puhutaan asiakkaista, tileistä, tilitapahtumista jne.
Kokemuksen mukaan liiketoimintaihmiset ovat usein ilahtuneita, kun kerrankin puhutaan “asiaa” eli vain heidän liiketoiminnastaan tai vastuualueestaan.
Mikä tärkeintä, näin saadaan liiketoiminnan omia näkemyksiä selkeytettyä ja tärkeitä käsitteitä määriteltyä. Ihmisten päissä olevaa arvokasta kokemustietoa saadaan dokumentoitua ja talteen myöhempää käyttöä varten.
Alku
Alussa voi kysellä ko kohdealueen ensimmäisistä prosesseista. Pankkiesimerkissämme voidaan kysyä: ”miten pankissa henkilö oikein tulee asiakkaaksi?” Vastaus saattaa olla: ”henkilö tulee konttoriin ja hänelle perustetaan tili, silloin hänestä tulee asiakas. Yleensä sinne talletetaankin heti jotakin eli tehdää tilillepano.”
Näissä vastauksissa jokainen substantiivi on käsite-ehdokas, eli henkilö, konttori, tili asiakas, tilillepano. Osasta näitä tulee oikeasti käsite (tili, asiakas, konttori), osa ei ole tässä yhteydessä käsite (henkilö), osaa tarkennetaan kysymyksillä (tilillepano).
Jälkimmäisessä tapauksessa huomataan, että tilillepano voidaan yleistää käsitteeksi tilitapahtuma.
Kunnon psykoterapeutti kuuntelee mitä sanoja asiakas käyttää kun hän kertoo ongelmistaan. Sitten hän käyttää noita samoja sanoja kysellessään lisää. Näin hän alkaa ymmärtää asiakasta ja asiakas myös kokee, että häntä ymmärretään, kun terapeutti ”puhuu samaa kieltä”. Mallintajana kannattaa toimia samoin.
Käytetään koko ajan asiakkaan esittämiä termejä, puhutaan samaa kieltä. Jossakin vaiheessa mallintaja sitten ehkä ehdottaa uutta nimeä jollekin käsitteelle, etenkin kun ruvetaan yleistämään. Ehkä mallintaja ehdottaa, että asiakas, yhteistyökumppani ja alihankkija ovatkin kaikki käsitteen ”osapuoli” takana. Tätä ei kannata tehdä liian aikaisin, jotta ei menetetä kommunikaatiota.
Käsitetyypit
Mallintaa voi monella eri tavalla, mutta itse yleensä kehotan noudattamaan seuraavaa jaottelua:
Luokittelemalla käsitteet kolmeen eri tyyppiin saadaan selkeyttä ja nopeutta mallinnukseen. Käsitetyypit ovat Masterkäsitteet, Sopimuskäsitteet ja Tapahtumakäsitteet.
Masterdatatyyppiset käsitteet ovat itsenäisiä, toisin sanoen niiden kuvaamia asioita voi tallettaa milloin vain, riippumatta muista tiedoista. Esimerkiksi tuote voidaan tallettaa milloin vain, se ei edellytä muiden käsitteiden olemassaoloa.
Sopimustyyppiset käsitteet kuvaavat asioita, joilla on alku- ja loppu pvm. Loppupäivä voi olla ”auki”, eli sopimus on toistaiseksi voimassa. Sopimusta ei voi tallettaa itsenäisesti, vaan se liitetään yleensä useampaan Masterkäsitteeseen. Tyypillinen sopimuskäsite on juuri jokin sopimus esimerkiksi asiakkaan ja yrityksen jonkin organisaatioyksikön välillä. Esimerkkejä ovat projekti, vakuutussopimus, pankkitili, puhelinliittymä ja kampanja. Ne eivät ole masterdatoja, mutta eivät myöskään tapahtumia
Tapahtumakäsitteet kuvaavat nimensä mukaan jotain reaalimaailman tapahtumaa, kuten tilillepano, maksu, yhteydenotto asiakkaaseen. Tapahtumilla on yksi päivämäärä ja yleensä kellonaika. Tapahtumat eivät ole itsenäisiä, vaan ne liittyvät aina sopimuksiin ja/tai Masterkäsitteisiin, joskus myös johonkin toiseen tapahtumaan.
Piirtämisohjeita
Tavoitteena on laatia mahdollisimman selkeitä ja luettavia malleja. Yksi hyvä pyrkimys on välttää risteäviä yhdysviivoja.
Masterkäsitteet kannattaa sijoitella reunoille. Keskelle tulevat sopimukset ja tapahtumat, usein niin, että sopimukset ovat ylempänä ja niihin liittyvät tapahtumat niiden alapuolella.
Kun nyt yhdistetään Masterkäsitteitä sopimuksiin, vältetään risteäviä viivoja.
Jos on sopimuksia, joilla on samanlaisia yhteyksiä ympäröiviin masterkäsitteisiin, niitä kannattaa ryhmitellä box-in-box -menetelmällä yläkäsitteen sisään.
Näin kuva yksinkertaistuu ja tulee huomattavasti vähemmän yhdysviivoja. Näin kannattaa tehdä varsinkin ylätason malleissa. Myös tapahtumat voi ryhmitellä yläkäsitteen sisään.
Lopuksi
Mallinnusistuntoihin on erilaisia välineitä, kuten esimerkiksi fläppitaulu tai powerpoint. Käsitemallista saatava arvo oikeastaan moninkertaistuu, kun niitä voidaan tarkastella tietyn projektin eri vaiheissa ja myös muissa projekteissa.
Niiden ylläpito ja jakaminen muille ei onnistu perinteisillä välineillä kovin hyvin.
Olenkin ollut alkuvaiheessa mukana kehittämässä Ellie-mallinnustyökalua, joka on nimenomaan suunniteltu mallinnuksen helpottamiseen ja data governanceen.
Sillä on nyt satoja käyttäjiä ympäri maailmaan aina Uutta Seelantia myöten, joten kysyntää tämän tyyppiselle lähestymistavalle näyttää olevan.
Iso asia näyttää olevan meneillään oleva trendi, jossa datan kehittämistä tuodaan lähemmäs liiketoimintaa – Data Mesh on on nyt kaikkien huulilla ja siinä tämä ajatus on juuri keskiössä.
Oikein hyvää alkanutta syksyä kaikki dataosaaijille!
Ystävällisin terveisin,
Ari Hovi
Ps. Mikäli liiketoiminnan kanssa tehtävä mallinnus on sinulle ajankohtainen aihe, suosittelen varaamaan paikan kiireen vilkkaa alan legendan Alec Sharpin vetämältä live-koulutukselta:
Business-Oriented Data Modelling Masterclass, 26.-28.9.2022
Kyseessä on Live-koulutus pitkästä aikaa! Tämä Alec Sharpin koulutus on alan klassikko, joka täyttää luokkahuoneen kerta toisensa jälkeen. Kurssilla opit miten mallinnat dataa yhdessä liiketoiminnan kanssa parhaiden käytäntöjen mukaisesti. Monet pitävät Alecin kursseja parhaina, joissa ovat olleet. Pidä siis varasi – tapa jolla katsot dataa voi muuttua lopullisesti!
Katso lisätiedot ja ilmoittautuminen tästä.
