Kuolemantähti.
Kyllä – aloitan tämän blogin Tähtien Sota -referenssillä. Syy, miksi tuon Kuolemantähden esille on se, että se on erittäin tunnettu fiktionaalinen esimerkki puutteellisesta suunnitelmallisuudesta. Imperiumi oli luonut täydellisen aseen… yhtä virhettä lukuun ottamatta. Jos hävittäjä pääsi kohteen lähelle, se pystyi tuhoamaan koko rakennelman. Hyökkäys 100, suojaus 90.
Kuinka sitten tämänkaltaiset intergalaktiset sudenkuopat vältetään, kun jotain, tässä tapauksessa aiheena on tiedolla johtaminen, lähdetään rakentamaan? On hyvä aloittaa prosessin suunnittelusta, määrittelystä ja datan keräämisestä.
Suunnitelmallisuuden puuttuessa suunnittelet epäonnistuvasi. Tai jotain sinne päin.
Taisi olla Benjamin Franklin, joka sanoi noin. Jos olisin sisustavampi ja taiteellisempi ihminen, WC:ni seinän inspirationaalinen teksti olisi varmaan: ”Live, Love and Plan. Plan before anything else.”
Mutta mennäänpä itse asiaan.
Kuten viimeisessä blogissani toin esille, tällä hetkellä maailmalla liikkuu paljon megatrendejä, joiden suosta on vaikea määritellä mitkä niistä ovat organisaatiollesi tarpeellisia, missä laajuudessa ne ovat tarpeellisia ja kuinka näitä konkreettisesti otetaan käyttöön. Ensimmäinen askel ymmärrykseen on prosessin suunnittelu.
Tai no, ihan ensimmäinen askel on oikeastaan se, että organisaatio on herännyt tarpeeseen. On ymmärretty, että emme johda organisaatiotamme tai jotain sen osa-aluetta tarpeeksi hyvin tietoon pohjautuen vaan johtaminen perustuu enemmän mutuun. Lausahdukset, kuten “No kun miettii, miten päätöksiä on tehty ja asioita on johdettu viimeiset 10 vuotta, niin uskoisin asian menevän suurin piirtein näin”, ovat merkki siitä, että organisaatiossasi saattaa olla mutu-johtamista. Johtamista ja päätöksiä tehdään vanhoihin tietoihin ja fiilikseen perustuen. Mutu-johtaminen ei ole sama asia kuin tiedolla johtaminen.
Pitkän kokemuksen tuomaa intuitiota, viisautta ja näkemyksiä ei pidä tietenkään täysin poissulkea, mutta jotta päätöksenteko- ja johtamisprosessista saadaan entistä parempi, tulee päätöksenteon ja johtamisen tueksi ottaa mukaan faktuaalista tietoa. Tämä on kuitenkin vähän nuoralla tanssimista; ei pidä unohtaa, että nuansseillakin on merkitystä. Yleensä mikään ei ole täysin mustavalkeaa tai välttämättä suoraviivaista.
Kun organisaatio on herännyt tarpeeseen, sen tulee miettiä, että mihinkäs sitä tiedolla johtamista sitten tarvitaan? Mitä hyötyä organisaatio voi sillä saavuttaa? Miksi tiedolla johtaminen on tärkeää juuri meille? Yleisesti ottaen organisaatiot hakevat tiedolla johtamisella eritasoisia strategisia, taktisia tai operatiivisia mittareita.
Tässä vaiheessa on hyvä kartoittaa organisaation raportointitarpeet hallitustoiminnasta operatiiviselle tasolle asti ja määrittää tärkeimmät ja nopeimmat voitot, joita tiedolla johtamisella voidaan saavuttaa organisaation jollain osa-alueella.
Kun organisaation raportointitarpeet ovat selvillä, seuraavaksi on hyvä miettiä sitä, mitä dataa organisaatio omistaa. Missä tuo data sijaitsee ja miten saavutettavissa se on? Tarvitaanko sen saavuttamiseksi jotain integraatioita ja rajapintoja, joihin tarvitaan palveluntoimittajien panosta? Tämän kartoituksen jälkeen organisaatiolla on selvillä kriittisimmät raportointitarpeet sekä datan sijainti, saavutettavuus sekä mahdolliset kehitystarpeet toimittajille.
Mistä resurssit, kuka hoitaa, mitä tehdään?
Viimeistään tässä vaiheessa prosessia on hyvä alkaa keskustelemaan resursoinnista, vastuista, maturiteeteista ja kirkastaa vielä kokonaistavoitteita. On hyvä tietää, miten paljon budjettia on käytössä raportointiympäristön rakentamiseen ja onko henkilöstöllä aikaa asiaan paneutumiseen ja osallistumiseen. Pystyykö organisaatio rakentamaan raportointiympäristön yksin vai tarvitseeko se avuksi toimittajaa? Kuka vastaa raportoinnista organisaation sisällä? Ylläpidetäänkö raportointiympäristöä talon sisällä vai hoitaako toimittaja sen? Onko prosessin myötä tarve uusille rekrytoinneille? Onhan määritellyt tavoitteet realistiset ja saahan organisaatio niistä parhaimman ja nopeimman hyödyn irti?
Myös hallintoa on hyvä miettiä. Kuinka tekemistä hallitaan järkevällä tavalla? Perustetaanko oma ohjausryhmä jonka vastuulla tiedolla johtaminen on, ja joka tarkastelee toiminnan kehittymistä, ohjaa toimintaa ja tuo uusia raportointitarpeita kehitysorganisaatiolle esimerkiksi kuukausi- tai kvartaalitasolla? Miten toimintaa ohjataan viikkotasoisesti? Käytetäänkö kehityksessä jotain ketterää viitekehystä kuten esimerkiksi Kanbania, SCRUM:ia tai Agilea?
Kunnolla tehty suunnitteluvaihe nostaa esille todella paljon kysymyksiä, jos ei muuta. Vastaukset eivät ole yksiselitteisiä ja niihin liittyy vahvasti se, että millainen organisaatio on kyseessä. Mitä tavoitteita sillä on, mikä maturiteetti sillä on tiedolla johtamisen suhteen ja millainen kehittämisen malli sillä on käytössä?
Taas lisää kysymyksiä. On tämä kyllä erikoinen blogi.
Kysymyksien tarkoituksena on kuitenkin herätellä sinua, lukija, ajattelemaan itse oman organisaatiosi toimintaa ja sitä, miten tiedolla johtamista kannattaisi joko aloittaa tai mahdollisesti kehittää eteenpäin.
Ollakko vai eikö olla… tietovarasto siis.
Yksi tärkeä suunnitteluun liittyvä asia on kysymys: Tarvitseeko organisaatiomme tietovarastoa? Tähän on helppo vastata, jos kyseessä on organisaatio, jolla on käytössä kaksi järjestelmää, ei lähitulevaisuuden tarpeita lisätä tuota määrää ja päivittäinen kumulatiivinen uuden datan määrä on 50MB.
Vastaus on ei. Ette tarvitse tietovarastoa.
Tietovaraston osalta kyseessä olisi mahdollisesti yli 1000 euron kuukausitasoiset kulut + varaston rakennuskulut päälle, eikä tuossa esimerkkitapauksessa saavutetulla hyödyllä voisi perustella kuluja millään järkevällä tavalla. Tuossa tilanteessa organisaatio pärjää aivan hyvin raportointityökalun natiiviformaattiin luodulla kansio- ja tiedostorakenteella. Tällöin rakennettaisiin MDM (Master Data Management) tiedostorakenteisesti. Toki organisaatiot kehittyvät ja järjestelmien määrät ja datamäärät kasvavat, jolloin tilannetta on suotavaa arvioida uudestaan.
Jos taas organisaatiolla on käytössään 15 järjestelmää ja päivittäinen uuden datan kumulatiivinen kertymä on 1GB, silloin tietovaraston käyttöönottoa olisi ainakin hyvä harkita. Tietovarasto on äärimmäisen hyvä ratkaisu silloin, kun historiadatan ja uuden päivittäin kumuloituvan datan määrä on korkea. Hyödyt syntyvät siinä mielessä, että tietovarastoon viedyt datat (muistakaamme edellisessä blogissa mainittu ETL-prosessi!) voidaan ladata tietovarastoon, jossa niitä voidaan muokata ja mallintaa. Tämä mahdollistaa esimerkiksi sen, että dataa voidaan käyttää muihinkin tarkoituksiin kuin raportointiin (esimerkiksi joitakin laskelmia voi antaa järjestelmien hyödynnettäväksi, dataa voidaan viedä uusiin sovelluksiin tai alustoihin jne.).
Tämä myös helpottaa raportointityökalun vaihtamista. On työlästä lähteä vaihtamaan raportointityökalua, jos organisaation tietovarasto, MDM, on jonkin raportointityökalun tiedostoformaatissa ja kyseisen tietovaraston koko on vaikkapa 400GB. Siinä saa tehdä hetken verran konversiotyötä, jotta datat saadaan muunnettua käyttökelpoiseen muotoon eri raportointityökalujen hyödynnettäväksi tai tietovarastoon laitettavaksi.
Tässä on siis yksi sudenkuoppa, jota kannattaa miettiä tulevaisuutta ajatellen. Toki, tehtiinpä sitten mitä tahansa liiketoimintaan liittyvää, on tekemistä hyvä reflektoida tasaisin väliajoin ja miettiä, että kuinka voisimme parantaa tekemistä ja mitä haasteita kohdataan tulevaisuudessa.
Tähän kohtaan on hyvä pistää neula myös asialle, johon en nyt paneudu syvemmin, nimittäin oikean BI-työkalun valinnalle. Organisaation tulee ymmärtää, että mikä markkinoilla oleva työkalu (Power BI, Qlik Sense, Tableau ym.) on juuri sille parhaiten sopiva. Käyn tätä puolta kuitenkin läpi tarkemmin tulevissa teksteissäni.
Mitä h******n käsitteitä?
Käsitemallinnus. Siinäpä vasta äärimmäisen tärkeä asia.
Tämä voi kuulostaa hyvinkin turhalta tai tympeältä vaiheelta, mutta todellisuudessa se luo hyvää pohjaa kaikelle tekemiselle jatkossa. Käsitemallinnuksen ideana on se, että organisaation eri sidosryhmät kokoontuvat yhteen eri käsitteiden suhteen ja pyrkivät määrittelemään liiketoimintaan liittyvät käsitteet mahdollisimman yhtenäisesti ja kattavasti, sekä tunnistamaan eri relaatiot näiden käsitteiden välillä. Tätä voisi äkkiseltään luulla IT:n tekemiseksi tai datavelhoiluksi, mutta yksinkertaisuudessaan kyse on liiketoimintalogiikan ja -kielen yhtenäistämisestä ja tämän mallinnuksen hyödyntämisestä dataan. Käsitemallinnukseen on olemassa erilaisia mallinnustekniikoita, ER-malleja, kuten UML, ORM, DSD, ERD jne. Pick your poison, kuten amerikkalaiset tuppaavat sanoa.
Mallinnustyössä pyritään löytämään liiketoiminnan yhtenäiset käsitteet, niiden kriittisyys, relaatiot sekä metatiedot. Esimerkkinä monen organisaation käytössä oleva käsite Asiakas. Asiakas-käsitteen metatietoja ovat esimerkiksi AsiakasID, Nimi, Puhelinnumero, SopimusID ja niin edelleen. Relaationa voidaan taas todeta, että Asiakkaaseen yleensä liittyy yksi tai useampi Sopimus. Sopimuksella on taas omat metatietonsa. Kun relaatio on käsitteiden väliltä tunnistettu, on myös hyvä tarkastella asiaa toisin päin: onko organisaation liiketoimintalogiikassa mahdollisuus tilanteeseen, jossa voi olla vain yksi Asiakas yhdellä tai useammalla sopimuksella? Usein vastaus tähän on ei, joten Asiakkaan ja Sopimuksen välistä relaatiosuhdetta pitää muuttaa kuvauksessa.
Tätä työtä tulee tehdä mahdollisimman laajasti, jotta kaikki organisaation käsitteet, niiden metatiedot ja relaatiot saadaan tunnistettua. Työn apuna voidaan käyttää erilaisia ohjelmistoja. Perinteinen vaihtoehto on piirtää käsitteet ja relaatiot fläppitaululle ja mallintaa ne sen jälkeen esimerkiksi Microsoftin Visiolla. Olemassa on myös erinomaisia käsitemallinnukseen luotuja työkaluja. Tarve, organisaation koko ja käytössä oleva budjetti toki määrittää myös käytössä olevat metodit ja työkalut aika pitkälle.
Tässä vaiheessa prosessia on saatu synnytettyä organisaation kattava käsitekartta. Nyt onkin hyvä aika lähteä miettimään datamallien tai tietovarastoratkaisun rakentamista.
1. Collect data 2. ????? 3. Profit
Kunnollisen pohjatyön tekeminen helpottaa datan keräämistä. Kun tekeminen, tavoitteet ja myös käsitemallit on määritelty, saadaan luotua datamalleja ja arkkitehtuuri tietovarastolle tai kansiorakenteelle. Näitä valintoja pohtiessaan kannattaa palata aiempaan kohtaan ” Ollakko vai eikö olla… tietovarasto siis.” (Ja kyllä, tiedän, olen erittäin paha varastamaan muiden tunnettuja lausahduksia. Saa haastaa oikeuteen).
Riippuen valinnasta, datamallien ja tietovaraston rakentaminen tapahtuu hieman eri paikoissa ja eri vaiheilla. Jos organisaatio on päätynyt tietovaraston hankintaan, on järkevää esimerkiksi rakentaa datamallit ja viedä raakadata data lakeen ja data warehouseen. Yleensä hyvä tietovarastoratkaisu mahdollistaa ETL-prosessin (Extract, Transform, Load -prosessi) toteuttamisen. Käytännössä tämä tarkoittaa sitä, että työkaluilla otetaan yhteyttä erilaisiin tietolähteisiin (kuten järjestelmien raportointikannat, rajapinnat, Excelit, CSV:t ja muut datalähteet), valmistellaan data tallennusta varten ja lopuksi tallennetaan se.
Jos ei päädytä tietovarastoon, yleensä BI-työkalut tarjoavat omat yhdistysmoduulinsa, joilla voidaan ottaa yhteyttä edellä mainittuihin datalähteisiin. Tässäkin tapauksessa toistetaan samat ETL-prosessit kuin tietovaraston osalta, mutta tällöin on myös hyvä miettiä millaista tietovarastointia rakennetaan kansio- ja tiedostorakenteisiin pohjautuen. On hyvä ottaa huomioon kansiorakenteen kapasiteetti ja se, miten sitä kasvatetaan tarpeen tullen ja miten dataa varmuuskopioidaan. Luonnollisesti näitä asioita tulee miettiä myös tietovaraston osalta, mutta yleensä asiat on silloin mietitty jo valmiiksi joko toimittajan ja tilaajan toimesta.
Tässä kohtaa työtä esiin tulee usein mielenkiintoisia asioita. Data on varsin eri näköistä järjestelmien käyttöliittymillä kuin tietokannoissa, toimittajilla ei ole välttämättä tarjota dokumentaatiota tietokannasta, data päivittyy eri järjestelmistä eri aikaan, kriittistä tietoa ja tietoa ylipäätään voi olla monistettuna useaan eri paikkaan jne. Näistä päästään kuitenkin yli vain kovalla tekemisellä.
Kun datamalli on rakennettu johonkin tietovarastoratkaisuun tai sitä matkivaan kansiorakenteeseen BI-työkalun tiedostoformaatissa, on mietittävä miten usein dataa päivitetään ja miten varmistetaan sen oikeellisuus. Miten usein datamallin X datan tulee päivittyä? Mihin raportteihin datamalleja käytetään? Kuinka varmistetaan, että data on oikeellista raportilla vs. järjestelmässä? Kysymyspatteristo kasvaa siis jälleen.
Lopetus, ennen kuin nukahdat
Kyllähän tässä tuli taas tavaraa, huh! Onko sinulla tietoähky?
Haluan kertoa vielä lopuksi asioita, jotka on hyvä pitää mielessä:
1. Kehitys on iteratiivista. Colosseumin ei tarvitse olla valmiina heti kättelyssä. Tekemisen kokoisia palasia, nopeita voittoja.
2. Suositaan ketteriä malleja. Vaikka annoinkin pitkän tovin suunnittelulle, määrittelylle ja datan keräämiselle, tulee tekemisen silti olla ketterää. Tavoitteet vaihtuvat jatkuvasti, organisaatio muuttuu koko ajan ja meillä ei ole varaa vain suunnitella. On hyvä tunnistaa mikä toimintamalli sopii juuri omaan organisaatioon.
3. Suunnitelmallisuutta ei silti pidä unohtaa. Ketteryys on hyvä asia, mutta ilman suunnittelua päädytään ketterästi metsään. Suosi suunnitelmallista ketteryyttä, jossa on jatkuvasti päivittyvät lyhyen tähtäimen suunnitelmat ja tavoitteet sekä myös pidemmän aikavälin versiot näistä.
4. Ongelmia, haasteita, pettymyksiä ja viivästyksiä tulee. Tämä on itsestään selvää monessa asiassa, mutta silti on hyvä pitää se mielessä. Tässä ei ole kyse nopeasti rakennettavasta hopealuodista, joka vie organisaation kilpailun edelle.
5. Samaan hengenvetoon on myös sanottava, että prosessi tuottaa myös onnistumisia, vahvistusta johtamiselle, tukea päätöksenteolle ja kehitysideoita prosesseille läpi organisaation erästä tärkeää aineetonta pääomaa hyödyntäen – dataa nimittäin.
6. Tiedolla johtamisen hyötyjä kannattaa miettiä organisaation, uusien innovaatioiden ja eritoten asiakkaiden näkökulmasta. Nykyään asiakkaat haluavat itsestään tai ympäristöstään mahdollisimman paljon tietoa sekä mahdollisuuden vaikuttaa omiin olosuhteisiinsa. Tämä on siksi äärimmäisen tärkeä näkökulma pitää mielessä.
Uskoisin, että tässä lienee tarpeeksi tekstiä tähän blogiin. Jatkan taas tiedolla johtamisesta seuraavassa blogissani. Seuraavien datateesien aiheena onkin datamallien rakentaminen, datan johtaminen sekä datavetoisen kulttuurin rakentaminen. Koodailla saa aiheesta minulle savumerkein tai modernein viestikanavin. Palataan seuraavissa lukuhetkissä, tsau!
Suunnitelmallisin terveisin,
Tuukka