Business Intelligence eli raportteja tietokoneella

Kun kerron uudelle ihmiselle työtehtävistäni, sanon yleensä tekeväni kannattavuus- ja tehokkuusraportteja tietokoneella. Termi Business Intelligence (lyh. BI) merkitsee harvoille mitään, ja voi johdattaa kuulijan väärille poluille. Tässä kirjoituksessa käyn läpi, mitä BI mielestäni on ja mitä tehtäviä siihen kuuluu.

Englanninkielinen hienolta kuulostava liiketoimintaan ja älyyn viittaava termi vakiintui yhdeksänkymmentäluvulla ja oman tulkintani mukaan tarkoittaa tietokoneelta käytettäviä klikkailuun reagoivia raportteja, jotka antavat käyttäjälleen kuvan yrityksen tilasta. Harhaanjohtavasti Business Intelligence -termiä käytetään myös toisenlaisessa merkityksessä, jolla on pidempi historia, mutta vähäisempi käyttö. Tällöin painopisteenä on tietokoneraporttien sijaan markkinatutkimukset, asiakastyytyväisyysmittaukset, toimittajaseurannat, kilpailijatutkimukset yms. ulkoisista sidosryhmistä kerätyt tiedot. Viimeksi törmäsin tähän määrittelyyn Kari Alholan ja Sanna Lauslahden kirjassa Laskentatoimi ja kannattavuuden hallinta. Mielestäni Business Intelligence -termin käyttö tässä merkityksessä on harhaanjohtavaa, ja käyttäisin mieluummin sanapareja competitive intelligence tai market intelligence. Vaikka näissäkin on kyse tiedonkeruusta, menetelmät eivät ole pelkästään teknisiä ja organisaation sisäisen tiedon sijaan keskitytään ulkoisiin sidosryhmiin. Kun kirjoitan BI:stä, käytän sitä rajatummassa organisaation datavarastointiin ja raportointiin liittyvässä merkityksessä.

Onnistuneen BI:n idea on, että yrityksen toimihenkilö voi istua aamulla tietokoneensa ääreen ja katsoa ruudulta, mitä yritykselle kuuluu. Hän voi katsoa kasvavaa myyntiä pylväsdiagrammista, punaista varoitustekstiä myöhästyneistä toimituksista tai listaa parhaiten tuottavista tuotteista. Yksinkertainen BI-raportti esittää yrityksen avainlukuja kuvaajina sekä lukutauluina, ja käyttäjä voi nappeja napsauttamalla rajata raportin tiettyyn myyntialueeseen, tuoteryhmään tai muuhun määriteltyyn ryhmään. Raportti reagoi valintoihin ja piirtää kuvaajat ja taulukot reaaliaikaisesti. Tavoitteena on, että käyttäjä näkee ensin kokonaiskuvan ja voi napsuttelemalla etsiä yksityiskohdista selittäviä tekijöitä.

BI-asiantuntija luo raporttien käyttöliittymät tehtävään tarkoitetuilla työkaluilla, joista suosituin Suomessa on ruotsalaisten kehittämä QlikView. Muita yleisiä vaihtoehtoja ovat Microsoftin Power BI ja IBM:n Cognos. Näissä kehitystyökaluissa on graafinen käyttöliittymä, jossa kehittäjä raahaa raporttinäkymälle taulukkoja, kuvaajia, nappeja, tekstilaatikoita ja kuvia. Nykypäivän BI:n tavoitteena on, että raportteja pystyisi laatimaan muutkin kuin BI-ammattilaiset, joten työkalut ovat melko helppokäyttöisiä. Isot ohjelmistotalot haluavat tehdä numeroiden pyörittelystä arkipäiväistä toimistotyöntekijöille, joten self-service on usein toistuva mainossana BI-työkaluissa. Käytännössä tässä tee se itse -raportoinnissa on kyse siitä, että analytiikka ei ole IT-osaston sanelemaa vaan kehitystä tekee ne myynnin, tuotannon ja talousosaston ihmiset, jotka haluavat järjestelmien luvuista vastauksia.

Olen huomannut, että monille raporttien käyttäjille BI tarkoittaa pelkästään raportointityökalua ja taustalla pyörivä datan keräys, jäsentely ja säilytys jää täysin huomioimatta. TV:n kokkausohjelmissa ruuan laitto näyttää helpolta, kun joku on pilkkonut ja mitannut raaka-aineet astioihin, jotka kokki vain heittää pataan. Samalla tavalla BI-raportointi on helppoa, kun järjestelmien data on kerätty ja siivottu helposti käytettävään muotoon. Arvioisin, että noin 80 % BI-asiantuntijan ajasta menee raaka-aineiden valmisteluun ja vain pieni osa itse raportin tekemiseen. Mikä tässä voi olla niin vaikeata, saattaa raportin käyttäjä kysyä? Useimmissa keskisuurissa ja suurissa yrityksissä on omat ohjelmansa jokaisella osastolla, jolla yritykseen liittyvää tietoa käsitellään. Työntekijät merkitsevät kirjanpidon tapahtumat yhteen järjestelmään, hallitsevat käyttöpääomaa toisessa ja palkanlaskentaa kolmannessa. Erilaisten järjestelmien määrä kasvaa helposti suureksi. Mitä useammassa järjestelmässä tieto on, sitä hankalampi tietoa on hakea ja hyödyntää raporteissa. Yhdessä ohjelmassa voi olla satoja tai tuhansia tauluja, joissa on kymmeniä kummallisesti nimettyjä sarakkeita. Esimerkiksi toiminnanohjausjärjestelmä SAP käyttää nimissään saksankielisiä lyhenteitä. Parhaimmassa tapauksessa ohjelmiston mukana tulee hyvät ohjeet ja debuggaus-työkalut, joiden avulla oikea tieto löytyy tietokannasta helposti. Pahimmillaan oikeat kentät löytyvät tietokannan tauluja lukemalla.

Yritysohjelmat säilövät tietonsa tietokantoihin tavalla, joka sopii erinomaisesti yksittäisten liiketapahtumien eli transaktioiden käsittelyyn, mutta ei raportoinnin useita tauluja ja tuhansia rivejä ynnäileviin raportteihin. BI-kehittäjä voi hakea raporttiinsa tiedot suoraan yritysohjelman tietokannasta SQL-kyselyllä, mutta tässä on omat heikkoutensa. Ensinnäkin raskaat SQL-kyselyt voivat tarpeettomasti rasittaa yrityksen ohjelmia, jolloin koko ohjelmisto hidastuu ja työnteko häiriintyy. Toiseksi raportin vaatima tieto ei välttämättä löydy yhdestä ohjelmasta ja tietokannasta, jolloin kahden eri järjestelmän tiedot pitää ensin yhdistää ennen esittämistä. Kolmanneksi suorat SQL-kyselyt johtavat helposti tilanteeseen, jossa eri raportit laskevat saman avainluvun hieman eri rajauksilla ja tavoilla, jolloin organisaatiossa ei ole yhtä totuutta laskelmissa. Ratkaisuna näihin ongelmiin on datavarasto, jonne BI-kehittäjä on kerännyt tiedon irrallisista järjestelmistä, siivonnut virheelliset merkinnät, täydentänyt puuttuvat tiedot ja jäsennellyt tiedon käyttäjälle ymmärrettävään muotoon. Datan kerääjää kutsutaan ETL-kehittäjäksi (extract, transform & load) ja datavaraston hallinnoijaa data-arkkitehdiksi.

Tietoa voi jäsennellä datavarastoon useilla tavoilla, mutta alan standardiksi on vakiintunut yhdysvaltalaisen konsultin Ralph Kimballin tähtiskeema. Tähtiskeeman perimmäisenä tavoitteena on helpottaa ja nopeuttaa raportointia siten, että tieto on säilötty business-käyttäjälle ymmärrettävällä tavalla, tietokantaan tehdyt kyselyt pysyvät yksinkertaisina ja laskelmat nopeina. Malli eroaa merkittävästi yritysohjelmien normalisoiduista tietokannoista, joissa päätavoitteena yksittäisten transaktioiden tehokas ja oikeellinen käsittely. Normalisoiduissa tauluissa tieto on pilkottu useisiin pieniin tauluihin, mutta tähtiskeemassa on rakennettu pieni määrä isoja tauluja, joita kutsutaan dimensioiksi ja faktatauluiksi. Esimerkiksi tähtiskeemassa voi olla yksi asiakasdimensio, joka sisältää asiakkaan nimen, toimitusosoitteen, vastaavan myyntihenkilön, ja asiakasluokittelun. Normalisoidussa tietokannassa olisi oma taulunsa asiakasnimelle, osoitteelle, myyntihenkilölle ja luokittelulle. Datamallinnus on oma taiteenalansa, johon liittyy paljon nyansseja, joita en tässä ala käymään läpi.

Mielestäni kaikkein tärkeintä BI-kehittäjälle on relaatiotietokantojen hallinta. Ilman ymmärrystä tietokannoista on mahdotonta hakea ja rakentaa tietovarastoja. Toiseksi tärkeimpänä pidän ymmärrystä Kimballin dimensiomallinnuksista, jotta datan osaa jäsennellä raportoinnille tehokkaalla tavalla. Dimensiomallinnus on usein uusi ja tuntematon lähestymistapa normalisointiin tottuneille tietokantaylläpitäjille. Valitettavasti rekrytoijat sivuuttavat nämä kaksi taitoa ja keskittyvät turhan usein yksittäisen BI-raportointityökalun osaamiseen, vaikka sen merkitys kokonaisuuden kannalta on vähäinen. On paljon nopeampaa ja helpompaa opetella yksittäisen BI-työkalun käyttö, kuin hankkia tarpeelliset tiedot tietokannoista ja dimensiomallinnuksesta. Lisäksi BI-kehittäjän työssä auttaa, jos tuntee yritystoiminnan perusasiat kuten myynnin, logistiikan, kirjanpidon tai johdon laskentatoimen. Ei riitä, että raportti on teknisesti toimiva vaan sen pitää olla liiketoiminnalle hyödyllinen. Raportin onnistumisen ratkaisee lopulta se, kuinka paljon apua siitä on liiketoiminnalle.