Power BI määrittely

Yleensä, kun asiakkaat lähestyvät minua Power BI raportoinnin tiimoilta, viesti kuuluu suurin piirtein näin:

“Haluaisimme tuottaa tietoa päätöksenteon tueksi ja liiketoimintanäkemyksen tuottamiseksi. Meillä olisi tarve raportille x. Siihen pitäisi hakea dataa järjestelmästä a sekä b ja sitten tuottaa mittarit z ja y. Ainiin, meinasi jo unohtua, mutta tämä tarvitaan heti.”

Kuulostaako tutulta?

Ymmärrän kiireen, mutta on olemassa myös parempi vaihtoehto. Minä uskon siihen, että on paras tehdä kerralla kunnolla. Kiirehtiminen on yleensä huono idea. Kunnolla tekeminen ei tietenkään tarkoita, että hommaa ei voida hoitaa ketterästi.

Näin minä toimin

Aluksi annan sinun kertoa kaikki kielenpäällä olevat ajatukset raporttiin liittyen, mutta sitten ehdotan, että otamme askeleen taakse päin. Jotta lopputulos olisi paras mahdollinen, minun täytyy ymmärtää, miksi raportti tarvitaan. Pelkkä mitä ei siis riitä, vaan tarvitaan enemmän taustoja.

Taustan kartoitus

Jotta ymmärrän raporttitarpeen taustat, kysyn määrittelyn yhteydessä muutamia onnistumisen kannalta olennaisia kysymyksiä.

  1. Ketkä tai mitkä roolit käyttävät raporttia?
  2. Mitkä ovat ne avainkysymykset, joihin käyttäjä etsii vastausta?
  3. Mitä toimenpiteitä tai päätöksiä käyttäjä tekee raportin perusteella?

Ensiksi kannattaa huomioida se, että raportti tehdään aitoon käyttötarkoitukseen ja aidolle henkilölle. Jos käyttötarkoituksesta on epävarmuutta, kannattaa raportti tehdä “proof of concept” -näkökulmalla.

Toiseksi minun pitää ymmärtää, että minkälaista näkemystä käyttäjät haluavat datasta. Minulla saattaa olla kokemusta toimialaltasi, mutta sinulla on sitä enemmän. On siis tärkeätä, että teemme yhteistyötä ja yhdistämme tietomme.

Kolmanneksi on hyvä huomioida, että muutamia poikkeuksia lukuun ottamatta jokaisen rakentamani raportin pitää johtaa päätöksen tekoon tai muuhun toimintaan. Yleensä “nice to know” kategoriaan kuuluva tieto ei oikeasti ole tarpeellista.

Bonus: Usein, kun selität liiketoimintasi tyhmälle ja ennakkoluulottomalle konsultille, saattaa syntyä uusia ideoita ja vanhaa on helpompi kyseenalaistaa.

Yksityiskohtien kartoitus

Kun taustat ovat selvillä, on aika sukeltaa yksityiskohtiin.

  1. Minkälaisia mittareita tarvitaan?
  2. Mistä näkökulmista mittareita halutaan tarkastella?
  3. Minkälaista vertailua pitää pystyä tekemään?
  4. Mitä ovat datalähteet?
  5. Oletko sinä tai onko joku muu teillä datan asiantuntija?

Yksi esimerkki mittarista voi olla liikevaihto. Liikevaihtoa halutaan tarkastella esimerkiksi liiketoimintayksikön ja ajan suhteen. Vertailuiksi olisi hyvä ottaa budjetti ja edellisen vuoden liikevaihto. Data haetaan ERP:stä tai jostain muusta järjestelmästä.

Toistaiseksi yksinkertaista.

Viimeinen puuttuva pala ovat datan yksityiskohdat. Yleensä on paras, jos organisaatiosta löytyy jo henkilö, joka tuntee vähintään järjestelmän käyttöliittymän, mutta mielellään myös kaikki tietokannan nurkat ja kolot. Aina niin ei tietenkään ole, jolloin on turvauduttava apuun tai salapoliisityöhön.

Jos lähdejärjestelmässä on noin 30 taulua, on järjestelmän ymmärtäminen yleensä aika yksinkertaista myös tietokantatasolla. Jos tauluja on satoja, niin silloin datan tuntemus nopeuttaa todella paljon projektin etenemistä.

Pysähdy

Viimeinen tsekkaus ennen töihin ryhtymistä on menetelmän sopivuuden varmistaminen.

Rakastan Power BI:tä ja se on upea työkalu, mutta joskus siitäkin loppuu poweri kesken. Silloin joudutaan turvautumaan järeämpään data-arkkitehtuurin esimerkiksi Azurea hyödyntäen, mutta siitä lisää joskus tulevaisuudessa.

Lopuksi

Artikkelin pointti: Vastaus kysymykseen miksi on lopputuloksen kannalta usein tärkeämpi kuin mitä. Ja mitä paremmin sinua ymmärretään, sitä parempi on lopputulos.