Jari Turkia

Jari Turkia

Data-analyytikko

Kun seuraavaksi katsot raporttia, niin mieti, miten tulkitset ne luvut ja osaatko tehdä oikeita päätöksiä raportin pohjalta? Onko kaikki tarpeelliset tekijät otettu huomioon? Entä jos raportti kertoisi myös, mitä ne luvut tarkoittavat? Olitpa sitten hankkimassa tai tekemässä raportointia, niin nyt on aika tarkistaa, mikä on raportoinnin uusi normaali.

Aiemmin on saatettu pitää aivan riittävänä, että raportit vain kaiuttavat taustajärjestelmien luvut ulos ja niitä yritetään sitten yhdessä tulkita. Nykyään raporteilta kannattaa vaatia enemmän, sillä mahdollisuuksia ja työkaluja on tarjolla parempaankin. Tyypillinen perinteinen raportti, sanotaan vaikka Raportti 1.0, tarjoaa kokoelman aiheeseen liittyviä tunnuslukuja, joista sitten käyttäjä itse koostaa mielessään asiaa kuvaavan mallin. Säännöllisesti lukuja seuraamalla käyttäjä voi oppia, miten systeemi toimii ja mitkä asiat ainakin näyttäisivät liittyvän toisiinsa.

Kuvitellaan esimerkki, jossa eri järjestelmien käyttöä raportoidaan lokitietojen perusteella niin, että toisella mittarilla seurataan järjestelmän käyttöä ja toisella mittarilla järjestelmän vasteaikaa. Viikkojen kuluessa näyttää vahvasti siltä, että eräs järjestelmä usein perjantaisin hidas ja silloin käyttöäkin on enemmän, joten siitä se varmasti johtuu. Pitäisiköhän kapasiteettia lisätä? Entä, jos oikeaksi syyksi paljastuukin toisen järjestelmän yhtäaikainen käyttö, joka tukkii yhteiset sisäiset rajapinnat. Olisiko tämä voitu havaita? Olisi varmaan, jos käyttäjä olisi tullut samalla seuranneeksi tätäkin järjestelmää, mutta käytännössä inhimillinen kapasiteetti loppuu usein kesken.

Paradigman muutos tulee siinä, että tämä yksinkertaisten lähtötietojen seuraaminen ja systeemin toiminnan oppiminen voidaan ulkoistaa raporttia kehitettäessä vähitellen raportoinnin data-alustalle. Tuloksena saadaan hyödyllisempi Raportti 2.0, joka näyttää oikeasti tärkeitä asioita ja ehkä jopa asioiden syitä ja seurauksia. Raportin sisällä on tällöin laskennallinen malli, johon on asiantuntijan ja koneoppimisen yhteistyöllä tiivistetty paras tietämys raportoitavasta ilmiöstä. Tämä raportin ydin on jopa ulkoista käyttöliittymää arvokkaampi, sillä se kuvaa hiljaista tietoa, jota raportin oikeassa tulkinnassa vaaditaan. On erittäin tärkeää, että myös se saadaan organisaatioissa talteen ja muidenkin hyödyksi.

 

Ongelmaa ratkaistaan vaiheittain

Havainnekuva raportoinnin vaiheista
Perusasiat on hyvä olla kunnossa ennen kuin voit viedä raportointisi uudelle tasolle. Raportin tietoihin syventyminen on arvokas prosessi jo itsessään. Opit luultavasti sisällöstä paljon uutta ja samalla ainakin helppo päättely saadaan automatisoitua ja vietyä muidenkin avuksi.

  

Raportoi koko ilmiötä, älä vain pintaa

Jos toimiva Raportti 1.0 jo olemassa, niin ollaan hyvässä tilanteessa. Tällöin luultavasti integraatiot tietolähteisiin ovat kunnossa, raportoinnin tietovarasto on pystytetty ja raportin sisältökin ehkä ymmärretään. Kokemuksiemme mukaan uudet ominaisuudet on tehokkainta tuoda vaiheittain nykyisten raporttien osaksi, sillä toivottavasti ne raportit ovat jo liiketoiminnan käytössä, ja näin uusi laskennallinen älykkyys saadaan suoraan tukemaan oikeita prosesseja. Laskennallinen malli ei ole kerralla valmis vaan sitä on kehitettävä vaiheittain, kuten raportteja muutenkin. Tällöin on tärkeää, että malliin tuotavat lähtötiedot ovat raportilla edelleen nähtävissä ja laskenta tuodaan lähtötietojen rinnalle. Tällä läpinäkyvyydellä saadaan kasvatettua päättelyyn luottamusta ja kriittiset puutteet tulevat havaituksi. Tavoitteena on hyödyllinen malli, mutta ei välttämättä täydellinen.

Tekniikkaa, joka osaltaan on mahdollistanut ketterän mallinnuksen osana raportointia, kutsutaan todennäköisyysohjelmoinniksi (probabilistic programming). Sen ajatuksena on erottaa ilmiötä kuvaava malli sitä suorittavasta laskenta-alustasta ja algoritmista. Näin mallikoodi voidaan tallettaa versiohallintaan raporttitiedostojen mukana ilman turhaa taakkaa laskennan yksityiskohdista. Kuten nimikin kertoo, niin menetelmän ideana on määrittää todennäköisyyksiä raportoitavan asian käyttäytymiselle ja sitä mukaa, kun havaintoja kertyy lisää, niin todennäköisyys ilmiön oikeaan ymmärtämiseen kasvaa. Keskeistä on, että saadaan kuvattua, millaisia rakenteita tietoaineistossa oikeasti on, eikä vain sitä, miten se on satuttu mallintamaan esimerkiksi tietokantaan. Suosittuja todennäköisyysohjelmoinnin välineitä ovat mm. Stan, TensorFlow Probability ja Pyro.

 

Esimerkki: Epätyypillisen käytön raportointi

Parhaimmillaan toimiva mallinnus avaa monia uusia käyttötapauksia, kuten ehdotuksia parhaista toimenpiteistä ja erilaisten uusien skenaarioiden testaamisen. Usein ratkaistavat ongelmat ovat kuitenkin hyvin arkipäiväisiä.

Esimerkiksi asiakkaamme Väylävirasto raportoi Tableaulla eri järjestelmiinsä myönnettyjä käyttöoikeuksia ja niiden käyttöä. Erityisesti halutaan tunnistaa oikeuksien myöntämisessä tapahtuneita inhimillisiä virheitä, poistaa turhia käyttöoikeuksia ja seurata normaalista poikkeavaa käyttöä. Näiden poikkeavien tapausten löytämiseksi ei kuitenkaan osattu muotoilla yleispätevää sääntöä. Ratkaisuna tähän lisäsimme raportin laskentaan koneoppimisella verkkomallin, joka rakentuu käyttöoikeuksien ja käytön yhdistelmistä, joita raportilla jo muutenkin tarkasteltiin. Tuloksena saatiin tyypillistä toimintatapaa ja sen todennäköisyyksiä kuvaava malli. Vertaamalla oikeaa käyttöä tähän tyypillisen käytön malliin, löytyivät helposti myös ne yksittäiset poikkeamat, joita on ehkä syytä katsoa tarkemmin. Samalla nähdään myös perustelu siihen, miksi tapaus näyttäisi poikkeavan. Järjestelmien kytkeytyminen toisiinsa oli osittain jo asiantuntijoiden tiedossa, mutta koko rakenne paljastui vasta, kun kaikki 60000 myönnettyä oikeutta sekä järjestelmien käyttö mallinnettiin verkkoalgoritmilla.

Järjestelmien tyypillistä kytkeytymistä kuvaava verkkomalli
Kuvassa on visualisoitu järjestelmien tyypillistä kytkeytymistä kuvaava verkkomalli. Normaalisti tämä raportin sisäinen tietämys voidaan jättää piiloon käyttäjältä, mutta on hyödyllistä, että sitä voidaan tarvittaessa myös tutkia lähtötietoja vasten.

  

Raportoinnin kannalta on olennaista, että mallin parametreilla on selkeä reaalimaailman tulkinta. Käytettäessä valmiita mallinnusvälineitä tähän parametrisointiin voidaan yleensä huonosti vaikuttaa, mutta käyttämällä todennäköisyysohjelmointia, voidaan malli määrittää niin, että parametrit selittävät systeemin toimintaa juuri kyseisen raportin kannalta järkevästi. Olisi siis aivan mahdollista tehdä malli, joka ennustaa lopputuloksen tarkasti, mutta sen parametreilla ei ole mitään reaalimaailman tulkintaa. Tällöin malli jää mustaksi laatikoksi, jonka toimintaa ei voi kuin arvailla ja hyöty on raportoinnin kannalta vähäinen. Tässä esimerkissä verkkomalli koostuu järjestelmiä kuvaavista solmuista ja niitä yhdistävistä kaarista. Verkkomalliin liittyviä parametreja on mm. solmun aste, joka tarkoittaa siihen tulevien kaarien lukumäärää. Tämä parametri kuvaa suoraan järjestelmän tyypillisyyttä eli sitä kuinka yleistä on, että kyseisellä käyttäjällä on oikeus tähän järjestelmään. Tätä parametria voidaan käyttää suoraan raportilla yhtenä suodatustekijänä. Monet käytännön ongelmat mallintuvat parhaiten verkkoina. Asiat ovat harvoin kovin yksinkertaisia ja kaikki tuntuu liittyvän toisiinsa.

Lopputuloksen kannalta tärkeintä on kuitenkin se, että käyttäjä näkee tulokset edelleen tutusta raportointivälineestä. Nyt vain tuloksista osataan näyttää ne tärkeät ja kiinnostavimmat. Jos raportoinnin data-alustana on joku nykyaikainen pilvipalvelu, niin mallinnusvälineetkin odottavat siellä jo valmiina. Pilvialustalle on myös helppoa toteuttaa raporttiin kytkeytyvän mallin automaattinen seuranta ja päivitys (MLOps), joka huolehtii siitä, että raportin ilmiöstä on tarjolla aina paras tietämys, kun aineistoa tulee lisää ja maailma muuttuu.

Kirjoittajasta

Jari Turkia

Jari Turkia

Data-analyytikko

Olen Jari Turkia ja toimin CGI:llä data-analyytikkona. Minulla on kahdenkymmenen vuoden kokemus digitaalisista palveluista ja niiden arkkitehtuureista. Opastan teitä mielelläni kokonaisratkaisuissa, jotka alkavat tarpeiden ymmärtämisestä ja tietojen analysoinnista, päätyen Big Data-ratkaisun ja integraatioiden kautta helppokäyttöisiksi ja visuaalisesti näyttäviksi palveluiksi.