Hei,
Datakeskeinen ajattelu ja tiedolla johtaminen ovat nyt kaikkien yritysten agendalla.
Liian usein tehdyt toteutukset eivät kuitenkaan kohtaa liiketoiminnan ajattelua. Tärkeää assettia eli dataa ei yhteisesti ymmärretä eikä sitä ole kuvattu.
Tarvitaan yhteistä kieltä ja toimivia menetelmiä liiketoiminnan ja IT-henkilöiden kommunikointiin.
Konsultoidessani suuryrityksiä, huomaan mielenkiintoisen asian. Moni tekee käsitemallinnusta (conceptual data modelling) pelkästän IT-porukan kesken.
Tiedonhallinnnan kulttuurin kannalta on kuitenkin verrattomasti hyödyllisempää mallintaa varsinaisten substanssiosaajien eli liiketoimintaihmisten kanssa.
Käsitemallinnus on itse asiassa luotu juuri sitä varten.
Käsitemallinnus kannattaa tehdä työpajassa yhdessä liiketoiminnan kanssa sen sijaan, että se tehdään jälkeenpäin muistiinpanojen perusteella IT-osaajien kesken.
Se kuuluu nimittäin oikeasti osaksi vaatimusmäärittelyä, kun kohteena on IT-järjestelmän tai data-alustan kehitys tai hankinta.
Vaatimusmäärittely on aikaavievää ja monesti turhauttava hommaa. Sitä säädetään edestakaisin ja silti meillä saattaa huonot speksit.
Olemme onnistuneet parantamaan merkittävästi tätä työtä ja omasta mielestäni tekemään siinä jonkinlaisen läpimurron. Kerron siitä kohta lisää.
Minua pyydetään todella paljon tekemään tätä työtä asiakkailke, mutta en ehdi ihan joka paikkaan. Siksi haluan tässä blogissa kertoa miten se kannattaa tehdä omin voimin.
Annan ohjeita miten liiketoimintalähtöiset mallinnustyöpajat viedään läpi, käyttäen menetelmääni Hovi Data Frameworkia (HDF)
HDF lähtee yleisesti käytetystä ER-mallinnusmenetelmästä selkiyttäen, helpottaen ja nopeuttaen mallinnustyötä. Toisena apuna on Ellie -mallinnustyökalu.
Tärkeitä asioita ovat motivointi (miksi tätä tehdään), teknisen kielenkäytön välttäminen ja mallien ymmärrettävyys ja selkeys.
Liiketoiminnan aika on kortilla, joten työn pitää olla tehokasta.
Mallinnuksen läpivienti on jaettu tässä HDF-menetelmän mukaan seuraaviin vaiheisiin:
1. Mallinnuksen tavoite
Määritellään selvästi mitä tarkoitusta varten käsitemalleja tehdään. Esimerkiksi tietovaraston tai data-alustan toteuttaminen.
Tai ehkä suunnitellaan uutta tietojärjestelmää tai halutaan kuvata selkeästi olemassa olevan järjestelmän tietosisältöä (Data engineering).
Valmisohjelmiston hankinnassa on hyvä olla käsitemalli keskusteluun ”tältä meidän datamaailma näyttää, miltä se näyttää teidän softassa?” Käsitemallit kuvaavat useimmiten dataa, joka on talletettu tai tullaan tallentamaan tietokantaan.
Meillä voi olla useita alatavoitteita, esim juuri data-alustan vaatimusmäärittelyn onnistuminen. Se ei kuitenkaan ole vielä lopullinen tavoite. Sellainen on esim tietyn tuotesegmentin katteen laskeminen.
Tämä kiinnostaa todella paljon tuotepäälikköä ja myyntijohtajaa ja hän ilman muuta haluaa auttaa tämän tiedon saamiseksi.
2. Mallinnusalueet
Päätetään, mitkä ovat mallinnusalueet. Esimerkiksi taloushallinto, henkilöstöhallinto, laskutus ja myynti voivat olla sopivia yhden istunnon aiheita. Kannattaa valita sopivan kokoinen alue.
Työpajan osallistujien kannalta on hyvä, että käsitellään juuri omaa aluetta eikä kovin pitkään naapurialuetta.
Toisaalta tarvitaan myös yhteistä näkemystä esim. asiakkaasta, jolloin nimenomaan on hyvä, että eri alueiden asiantuntijat tulevatkin ulos siiloistaan ja saadaan määrittelemään yhdessä yhteisiä datojaan.
Mallinnusalueen valinta vaikuttaa keskeisesti siihen, kenet saadaan osallistumaan palaveriin.
Tieystä alueesta vastaava tulee siihen yleensä mielellään. Mutta jos osallistuja kokee, että tässä puhutaan oman alueen vierestä, alkaa helposti kännykän selailu tai työpajaan osallistuminen perutaan viime hetkellä.
3. Osallistujat
Hyvän käsitemallin laatimisessa tarvitaan kahdenlaista osaamista: käsitemallimenetelmän osaaja, joka vetää istuntoa, ja itse kuvattavan alueen asiantuntijoita.
Käsitemallinnuksen osaajalta edellytetään kykyä olla menemättä liian tekniselle tasolle. Usein parhaat tähän ovat ne henkilöt, jotka tekevät muutakin vaatimusmäärittelyä liiketoiminnan kanssa.
Heidän yhteistyöllään malleja alkaa syntyä nopeasti. Osaajia tarvitaan eri alueilta, sillä datan lisäksi dataosaaminen on siiloutunut.
On tärkeää saada kohdassa 2 valitun alueen substanssiosaajia kuhunkin istuntoon. Ehdokkaita ovat esim. nykyiset Excel-raporttien tekijät ja järjestelmien pääkäyttäjät.
Lisäksi on hyvä olla laajempaa näkemystä omaavia, kuten kehityspäälliköitä tai esimiehiä. Vaikka puhun liiketoimintamallinnuksesta, pitkän linjan IT-osaajilla on myös usein paljon tietoa.
Osallistuvien henkilöiden arvokasta hiljaista tietoa ja näkemyksiä yrityksen eri alueista saadaan näin dokumentoitua selkeästi käsitemalleihin. Alkaa syntyä laaja, yrityksen keskeisten tietojen datakartta.
4. Mallinnustyöpaja
Ennen istuntoa osallistujille lähetetään lyhyt tietopaketti siitä, mistä mallinnuksessa on kysymys. Istunnon aluksi kerrataan vielä kohdan 1 asia eli mitä tarkoitusta varten työtä tehdään.
Tärkeintä on kertoa hyvin yksinkertaisesti, että miksi kannattaa osallistua ja mitä osallistuja hyötyy tästä.
Lisäksi lyhyt perehdytys mallinnusmenetelmään, jossa on esimerkki sekä selostus siitä, mitä HDF:n käsitetyypit master, sopimus ja tapahtuma tarkoittavat.
On hyvä aloittaa tunnistamalla mallinnusalueen keskeiset masterkäsitteet.
Ne selviävätkin yleensä pian, niitä ovat esim. asiakas, organisaatioyksikkö ja työntekijä. Käy ilmi, että masterkäsitteitä on itse asiassa vähän, on siis päästy nopeasti eteenpäin!
Seuraavaksi voi alkaa laajentamaan sopimus- ja tapahtumatyyppisiin entiteetteihin.
Vetäjä ohjaa työtä kyselemällä tyyliin ”asiakas voi siis tehdä monta tilausta, voiko yhteen tilaukseen liittyä useampi asiakas?”
Käsitteet perustetaan saman tien Ellie-ohjelmistoon, ja jatketaan käsitteiden välisten yhteyksin piirtämistä siellä. Alkaa heti syntyä selkeä malli.
Ellien kanssa aikaa säästyy, jolloin istunnossa ehditään jo miettiä käsitteiden määritelmiä ja esimerkkejä, jotka saman tien kirjataan Ellieen ja ovat siten myöhemmin helposti kaikkien osallistujien löydettävissä.
Mallinnuksen vetäjän tehtävä on vaativa, mutta täysin opittavissa. On tärkeää pitää yllä innostusta.
Työ on ikään kuin yhteisymmärryksen johtamista. Vetäjä ehdottaa päätöksiä, kuten ”sovitaanko, että tätä käsitettä kutsutaan tässä termillä Customer, ja laitetaan synonyymiksi se toinen nimitys eli Account?”.
Ellien Business Glossary-ominaisuuden ansiosta käsitemääritykset jäävät talteen, eli se muodostaa keskeisten liiketoimintakäsitteiden talletus- ja ylläpitopaikan.
Syntyvä malli on osallistujien yhteinen näkemys heidän datamaailmastaan. Tehdyt mallit ovat samantien asianosaisten katsottavissa ja kommentoitavissa Elliessä.
5. Mallinnuksen jatkotyöt
Istunnon lopuksi esitetään miten malleista edetään ja sovitaan mahdollisesti tarvittavat jatkotoimet. Malleja tarkennetaan taustatyönä ja mahdollisissa lisätyöpajoissa.
Ellien avulla jokin tietty työpajaan osallistunut henkilö ja mallintaja voivat jatkaa etänä mallien työstämistä; Ellie on pilvipohjainen ja siten mahdollistaa useamman käyttäjän kirjautumisen samaan malliin.
Näin esim Skypen välitykselle projektia voidaan viedä hyvin eteenpäin ilman, että aina järjestetään erillinen työpaja. Tämä on liiketoiminnalle mieleen, koska kukaan ei halua jatkuvasti juosta palavereissa ja työpajoissa.
Malleja vasten on hyvä tehdä ns. tietotarveanalyysiä, eli esimerkiksi tutkia, miten määriteltyjen raporttien data irtoaa käsitemallista. Ts. löytyvätkö raportin edellyttämät käsitteet, yhteydet ja attribuutit – ja tarvittaessa täydennetään. Tai tutkitaan vastaavasti miten jokin käyttöliittymä saisi datansa.
Mallien alkaessa valmistua, on hyvä järjestää mallien esittelytilaisuus, mieluiten laajemmallekin yleisölle.
6. Toteutus
Riippuen mallinnuksen tavoitteista, malleista edetään tietokantatoteutukseen, kuten tietovarastoon.
Esimerkiksi HUS:ssa Ellie-mallit viedään automaattisesti WhereScape -nimiseen tietovaraston automaatiotyökaluun, jonka avulla generoidaan itse tietovaraston tietokantarakenteet.
Ellie voidaan integroida hyvin helposti myös muihin tietojärjestelmiin.
Näin tekemällä maksimoidaan automatisaatio ja säästetään todella paljon kustannuksissa.
Tämä on juuri se merkittävä läpimurto tuottavuuden parantumisessa, josta kirjoituksen alussa puhuin.
Lopputuloksena meillä on teknisen, monimutkaisen tietokantaratkaisun lisäksi selkeä käsitemallitaso, joka kuvaa juuri sitä, mitä tietovarastossa on. Tarvitaan siis kahden tason kuvaukset.
Jos ollaan suunnittelemassa operatiivista tietokantaa, edetään käsitemalleista tietokantatoteutukseen saakka.
Tämä johtaa parempaan, monikäyttöisempään ja pitkäikäisempään tietokantaratkaisuun kuin menettely, jossa ohjelmoija perustaa tauluja sprintti kerrallaan käyttötapausten perusteella.
Jos oli tavoitteena selvittää, mitä dataa sovelluspaketin tietokannassa on, ei toteutusta suoranaisesti ole: lopputulos on se, että vihdoin meillä on selkeä kuvaus tuon järjestelmän taustalla olevasta tietokannasta.
Jos ollaan valitsemassa tietojärjestelmää, malleja käytetään järjestelmien arviointiin ja toimittajien kanssa keskusteluun.
Oman datan käsitemallin vertaaminen toimittajan järjestelmän vastaavaan saattaa paljastaa oleellisia puutteita, jotka muutoin selviäisivät vasta myöhään, käyttöönoton jälkeen.
7. Jatkokehitys
Käsitemallinnustyö ei lopu toteutukseen. Tämä on yksi iso ero perinteisen käsitemallinnuksen ja HDF:n välillä.
Kun tulee muutostarpeita, uutta dataa tms, niin käsitemalleja muokataan ja laajennetaan.
On tärkeää, että mallit ovat ajan tasalla ja käytettävissä. Tämä onnistuu hyvin Elliellä, jossa mallit voi milloin vain avata selaimessa tutkittavaksi ja muutettavaksi.
Eräällä asiakkaalla Ellieen merkataan, mitkä data on jo viety tietovarastoon, ja mitkä eivät – esim. siksi että dataa ei vielä ole saatavilla.
Näin kontrolli tietovaraston kehittämisessä pysyy omissa käsissä. Kun data-analyytikko saa tietotarpeen liiketoiminnalta, hän näkee Elliestä heti mitä dataa on saatavilla ja mitä ei.
Käsitemallit toimivat mainiona lähtökohtana kun mietitään KPI-mittareita ja muita johdettuja tietoja.
Tekoälyhankkeissa on myös olennaisen tärkeää alusta saakka ymmärtää lähtödatat. Ellie tukee hyvin näitä toimintoja, kun mallit ovat aina nopeasti saatavilla.
Ennen mietittiin, että käsitemalli on jotain joka tehtiin piirtotaululle, Powepointille tai Visioniin. Nyt näin ei enää toimita. Ellie mahdollistaa uudenlaisen tavan kuvata ja ylläpitää kuvauksia datavarannosta täysin uudella tavalla.
Hyviä vinkkejä mallintamiseen
Kunnon psykoterapeutti kuuntelee mitä sanoja asiakas käyttää kertoessaan 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ä”.
Liiketoimintaihmiset ovat kyllästyneitä kuulemaan IT-jargonia, josta eivät ymmärrä mitään. Mallinnustyöpajassa puhutaan vain businesskieltä!
Ei käytetä IT-termejä eikä lyhenteitä. Ei puhuta tietotekniikasta. Esim. pankkitoiminnan alueella puhutaan asiakkaista, tileistä, tilitapahtumista jne.
Käsitteiden tunnistus on joskus ongelmallista. Tuote ja asiakas tuntuvat selviltä käsitteiltä. Joskus on malliin ilmestynyt outo käsite, kuten ‘Analytiikka’.
Se ei ole käsite, vaan kuvaa toimintaa tai prosessia.
Yksi käsitteen tunnusmerkki on, että käsitteen esiintymiä voi laskea. Montako asiakasta meillä on? Ei voi kysyä montako anaytiikkaa meillä on. Sitä ei vastaa mikään reaalimaailman esiintymä.
Käsitemallien selkeyteen kannattaa kiinnittää erityistä huomiota. Liiketoiminta juoksee karkuun sekavia, monimutkaisia ja liian teknisiä malleja.
Et ostaisi asuntoa esittelijältä, joka näyttää tarkkoja rakennuspiirustuksia (vrt. tekniset tietokantakaaviot). Tarvitset selkeät pohjapiirustukset (vrt. käsitemalli).
Jokaiselle käsitteelle voi tarvittaessa tehdä taulukon, jossa on esimerkkidatarivejä ko. käsitteestä.
Tällaiset oikeaa dataa sisältävät esimerkit auttavat liiketoimintaihmisiä ymmärtämään paremmin käsitemalleja.
Lopultahan käsitemallin mukaan tehdyssä tietokannassa (tietovarasto tai operatiivinen kanta) on käsitteen mukaista dataa, vietynä tietokannan tauluun.
Eri alueiden mallit muodostavat kokonaisuuden. Kerran määritelty asiakas -käsite on käytettävissä muissakin malleissa.
Ellie tukee tätä hyvin, eli sieltä voi katsoa missä eri malleissa on asiakas ja mitä muita käsitteitä asiakkaaseen liittyykään – syntyy se kuuluisa asiakkaan kokonaisnäkemys.
Lopuksi
HDF-menetelmän ja Ellien avulla nostetaan tiedonhallinnan kulttuuri aivan uudelle tasolle.
Busineksen näkemykset saadaan oikeasti otettua huomioon vaatimusmäärittelyn yhteydessä ja ne välittyvät toteutuksiin asti.
Mikä parasta, me rakennamme näin sillan vaatimusmäärittelyn ja teknisen toteutuksen välille hyödyntäen automatisaatiota.
Me dataihmiset olemme jo pitkään haaveilleet systeemistä, jossa voimme kerralla saada liiketoiminnan määritykset talteen ja edetä sieltä automaattisesti tietokantaan asti – Nyt se on mahdollista Ellien avulla!
Ilmankos niin monet pörssiyritykset haluavat kuulla tästä lähestymistavasta ja ovat ottaneet HDF:n käyttöön.
Olemme todella onnistuneet automatisoimaan ison osan sellaista työtä, johon ennen meni hirveästi aikaa.
Toivottavasti ohjeista on apua.
Järjestämme mielellämme myös koulutuksia, jonka kautta voit ottaa HDF:n itse omaan käyttöön osaksi sisäistä tai ulkoista vaatimusmääritelyprosessia.
Toivotan menestyksellisiä mallinnusistuntoja!
Ystävällisin terveisin,
Ari Hovi
Ps. Järjestämme jälleen ainutlaatuisen Deep Learning-menetelmään pohjautuvan tekoälyvalmennuksen – Käytämme koulutuksessa TensorFlowta ja PyTorchia, jotka ovat kuumimpia teknologioita tällä hetkellä.
AI Development in Practice with Deep Learning and TensorFlow and PyTorch, 5.6 – 6.6.2019, Helsinki
Vetäjänä on alan huippu Tarry Singh, joka on ollut tekoälypioneerin Andrew Ng:n opissa. Tämä Courseralle suunniteltu koulutus on valittu toiselle sijalle Inc -teknologiajulkaisun äänestyksessä maailman parhaista tekoälykursseista.
Koulutus on ainutlaatuinen ja sinne otetaan vain rajoitettu määrä osallistujia. Varaa siis paikkasi ajoissa!
Lue lisää tästä
