Hei,
Tietovarastojen- ja alustojen rakentamisessa on olemassa kahta koulukuntaa.
Puhutaan mallinpohjaisesta toteutuksesta ja lähdejärjestelmäpohjaisesta toteutuksesta.
Asiaan liittyy myös IT-mailman ikiaikainen keskustelu siitä kummat tulevat ensin, liiketoimintaprosessit vai IT-järjestelmät?
Näkökulmana tässä on data-alustan rakentaminen, siis tyypillisesti tietovarasto ja tietoallas. Nämä toimivat analytiikan ja raportoinnin pohjana.
Olet tämän blogin lukijana todennäköisesti data ja IT-alan osaaja, joten asia on tullut sinullekin vastaan.
Kysymys on itse asiassa yllättävän vaikea, eikä siihen ole yhtä oikeaa vastausta. Käydään asiaa läpi tarkemmin.
Lähestymistapojen erot
Mallipohjaisella lähestymistavalla tarkoitetaan sitä, että data-alusta perustuu liiketoiminnan näkemykseen omista tiedoistaan sekä tietotarpeisiin.
Eli ensin laaditaan käsitemallit liiketoiminnan näkökulmasta. Tavoitteena siis kuvata tietoja nimenomaan niin kuin liiketoiminta tiedot näkee. Tämän jälkeen data-alustan tietokanta rakennetaan siihen perustuen.
Lähdejärjestelmälähtöisessä lähestymistavassa käytetään olemassa olevien tietojärjestelmien takana olevien tietokantojen rakenteita myös data-alustan rakenteiden pohjana.
Tässä ratkaisussa siis esim. ERP:n käyttämät rakenteet sekä myös käsitteiden nimet tulevat käyttöön. Jos järjestelmä puhuu nimikkeistä, ne tulevat käyttöön. Liiketoiminta ehkä käyttää kuitenkin enemmän käsitettä tuote..
Ohjaako siis hankittu tietojärjestelmä organisaation käyttämiä käsitteitä vai liiketoiminnan oma näkemys?
Käsitemallinnusta ei lähdeäjärjestelmälähtöisessä menettelyssä välttämättä hyödynnynetä lainkaan, eikä liiketoiminnan läsnäoloa tarvita.
Mallipohjainen lähestymistapa edellyttää liiketoiminnan sitomisen projektiin, kun taas lähdejärjestelmäpohjainen tapa on enemmä ns “IT-infrankehitysprojekti”.
Mutta kumpi näistä on parempi tapa?
Asia liittyy juuri tähän kirjoituksen alussa esitettyyn: kumpi on määräävämpi, IT-järjestelmän ohjaus vai omat liiketoimintaprosessit?
Kumpi ohjaa kumpaa, IT liiketoimintaa vai prosessi IT:tä
Alussa on aina liiketoiminta. Käytin edellisessä blogissani tätä esimerkkiä, eli kukaan ei osta laskutusjärjestelmää ensin ja sitten ala miettimään, että mistä saadaan ne laskutettavat asiakkaat.
Yleensä ei osteta ensin sähköistä rekrytointijärjestelmää ja aleta vasta sitten rekrytoimaan työntekijöitä.
Oletaan tilanne, jossa yrityksen nykyinen laskutusjärjestelmä ei enää vastaa sen tarpeita. On siis aika vaihtaa järjestelmää.
On kaksi vaihtoehtoa, joko teetättää järjestelmä koodareilla tai ostaa valmissofta.
Sama kysymys on lähes aina edessä, jos mietitään mitä tahansa ohjelmistojen ja IT-järjestelmien hankintaa ja kehittämistä.
Koska laskuttaminen ei ole varsinaista ydinliiketoimintaa (ellei yritys nimenomaan tarjoa laskutukseen liittyvää palvelua), hankitaan usein valmissofta,
Kuten tiedämme, tämä on varsin yleistä, eli hankitaan MS Dynamics, SAP:n tuotteita, Salesforce, Workday tai muu vastaava
Nykysuuntaus on, että räätälöintiä vältetään.
Järjestelmiä toki konfiguroidaan vastaamaan yrityksen tarpeita, mutta räätälöityjä ominaisuuksia ei yleensä lisätä puhumattakaan tietokantarakenteiden muuttamisesta. Räätälöinti vaikeuttaa tai estää ohjelmistojen uusien versioiden käyttöönottoa.
Mitä isompi hanke, sitä enemmän yritys joutuu itse muokkaamaan omia prosessejaan, jotta he voisivat hankkia vaikka SAP:n toiminnanohjausjärjestelmäksi.
Toisin sanoen on helpompi muuttaa omia prosessejaan kun ohjelmistoa.
Nyt olemmekin tilanteessa, jossa IT-järjestelmä tulee ensin, eli prosessit muuttuvatkin sen mukana.
Heiluttaako häntä koiraa?
Toimittajan valmiit prosessit
Juuri edellämainitun vuoksi konsulttifirmoissa on töissä kaikenlaisia liiketoimintakonsulttteja. IT-järjestelmän käyttöönotto tai muu digitalisointi on mitä suurimmassa määrin johdon kehitysprojekti.
Valmisohjelmistot sisältävät ideaaliprosessit. Järjestelmä saadaan nopeiten käyttöön, jos noudatetaan tarkasti näitä prosesseja.
Onko SAP:n, Oraclen, Microsoftin tai Salesforcen tarjoama prosessi parempi kuin yrityksen oma? Onhan sitä kehitetty vuosien ajan tuhansien asiakkaiden kanssa.
Mutta miten saadaan meidän linjastot sopimaan sen uuden valmisohjelmiston muottiin? Puhutaan isomman mittakaavan muutoshankkeesta.
Joskus tämä on johdon ajatuskin: uuden järjestelmän avulla saadaan tehokkaammat ja yhtenäisemmät prosessit sisäänajettua. Järjestelmän kalleuteen vedoten nujerretaan muutosvastarinta.
Pieni muistutus: osa yrityksen liiketoiminnan ytimen prosesseista on luonnollisesti niin uniikkeja, että niihin on luotu omat prosessit ja usein omat räätälöidyt järjestelmätkin.
Kumpi siis on lopulta parempi, muokata omia prosesseja IT-järjestelmän mukaan vai päinvastoin?
Mallipohjaisuus voittaa silti
Kaikki tämä liittyy juuri data-alustan rakentamiseen: kumpi on parempi malli- vai lähdejärjestelmäpohjainen lähestymistapa?
Mallipohjaisuus lähteen siitä että data-alusta noudattaa liiketoiminnan näkemyksiä. Järjestelmälähtoinen lähtee taas siitä, että IT-järjestelmät ohjaavat tekemistä.
Olllaanko klassisessa muna-kana-ongelmassa?
Yksi tapa ajatella asiaa on se, että kumpi muuttuu todennäköisemmin ja kumpi on vakaampi.
Jos mietitään jotain liiketoimintaprosessia, kuten vaikkapa tuotantoprosessia tai myyntiprosessia, niin eihän sitä kovin usein muuteta. Ajatelkaapa vaikka jotain tehdasta, niin kuinka usein kaikki linjastot pistetään uusiksi? Aika harvoin.
Toisaalta ei niitä ERP järjestelmiäkään joka päivä osteta. Oraclen tietokannat ovat tunnettuja siitä, että niiden vaihtaminen on tehty hyvin vaikeaksi.
Kysin asiaa Arilta, että sinulla kun on vuosikymmenien kokemus asiasta, niin miten näet tämän.
Ari sanoi, että hän on hyödyntänyt kumpaakin lähestymistapaa suhteellisen paljon.
Ja kuulemma mallipohjainen onnistuu lähes aina paremmin. Miksi, kysyin.
Liiketoiminta ohjaa tekemistä
Jos data-alustasta halutaan tehdä laajennettava, ymmärrettävä ja monikäyttöinen, voittaa mallipohjainen lähestymistapa aina.
Siinä data-alustan rakenne ohjataan liiketoiminnasta käsin ja sen sisältö tunnetaan.
Näin se oikeasti hyödyttää liiketoimintaa, kehitystyö on nopeampaa ja laadukkaampaa. Se voi tuntua vaativammalta, kun on seurusteltava enemmän liiketoiminnan kanssa.
Lähdejärjestelmäpohjaisessa lähestymistavassa kopioidaan lähdejärjestelmien rakenteet data-alustalle sellaisenaan.
Juuri esimerkkinä käyttämäni SAP:in rakenteet eivät välttämättä ole analytiikan ja raportoinnin kannalta ideaalja, onko silloin järkevää kopioida ne suoraan sellaisenaan alustalle? Latausvaiheessa ehkä, mutta itse tietovarastoon ei missään nimessä.
Tämä johtaa hyvin vaikeasti kehittävään data-alustaan. Sen rakenteet ovat monimutkaisia ja vaikeasti ymmärrettäviaä.
Parhaat käytännöt
Ari sanoi, että hänen pitkäaikainen yhteistyökumppaninsa, Data Vaultin kehittäjä, Dan Linstedt on samaa mieltä hänen kanssaan mallipohjaisen lähestymistavan ylivertaisuudesta.
Lähes kaikki alan asiantuntijat ovat myös sitä mieltä, esim Snowflaken väki. John Giles on kirjoittanut tästä uusimman kirjansa.
Miksi siis ollaan päädytty ylipäänsä alun perinkään tekemään lähdejärjestelmäpohjaisia alustoja? Osissa yrityksistä ja organisaatioissa datatekeminen nähdään vain IT-osaston hankkeina, joihin ei otetan mukaan liiketoimintaa.
Ne ovat ns perus- IT-infran rankentamista ja data integrointia siinä missä muukin datan integrointi.
Jotkut ihan järkevätkin data-alan ihmiset saattavat olla sitä mieltä, että miksi tehdä mitään käsitemalleja, kun joka tapauksessa ainoa mistä dataa on saatavilla, ovat ne lähdejärjestelmät.
Eli että se on vain ylimääräinen vaihe, kun kuitenkin sinne lähdejärjestelmien uumeniin on sukellettava.
Mallipohjainen lähestymistapa ei tietysti tarkoita, ettei lähdejärjestelmiä tarvitse tuntea. Tottakai pitää.
Emme voi tuottaa BI-raportteja sellaista datasta jota ei esimerkiksi ole, vaikka se olisi kuinka määritetty käsitemalliin.
Käsitemallit kuvaavat liiketoiminnan näkemystä omasta datastaan. Tehtyjen käsitemallien avulla sitten selvitetään mitä dataa ja miten sitä saadaan lähtöjärjestelmistä.
Esimerkiksi Data Vaultissa käsitemalliin pohjautuvaan runkoon liitetään sitten lähtöjärjestelmäkohtaiset komponentit.
Tavallaan kyseessä on kahden tavan hybridi. Kumpikaan menetelmä täysin sellaisenaan ei riitä.
Ystävällisin terveisin,
Johannes HoviPs. Vielä olisi joitain paikka vapaana Data Gorvernance & MDM etäkolutukseen, jonka vetäjänä on alan huippu, eli Mike Ferguson.
Enterprise Data Governance & Master Data Management, 15.04.2021 – 16.04.2021
Data Governance nyt listattu yhdeksi tärkeimmäksi tiedonhallinnan kehitysalueeksi maailmalla. Eikä turhaan.
Uusien teknologioiden sekä datan tehokas hyödyntäminen nimittäin edellyttävät toimivaa hallintamallia. Tässä huippuvalmennuksessa opit laatimaan Data Governance-mallin sisältäen ihmiset, prosessit, metodit sekä teknologiat.
Opit myös Master Data Managementin (MDM) periaatteet ja miten ydintietoa hyödynnetään liiketoiminnassa.
Lisätiedot ja ilmoittatuminen tästä.
