Mittaristo ja mittarien määritelmät

Sama luku, kaksi arvoa

Tilanne on tuttu jokaisesta organisaatiosta, jossa raportteja on enemmän kuin yksi. Myynti sanoo kuukauden liikevaihdoksi 412 000, talous sanoo 388 000, ja johtoryhmässä käytetään kaksikymmentä minuuttia sen selvittämiseen kumpi on oikein. Vastaus on yleensä että molemmat — ne laskevat eri asian.

Myynnin luku sisältää tilaukset, jotka on voitettu mutta joita ei ole vielä laskutettu. Talouden luku sisältää vain kirjatut laskut ja vähentää hyvitykset. Kumpikaan ei ole virhe. Virhe on siinä, että molempia kutsutaan liikevaihdoksi.

Tämän oireen tunnistaa siitä, että keskustelu kääntyy luvuista lukujen alkuperään. Kun kokouksessa kysytään "mistä tämä luku on", raportti on jo menettänyt tehtävänsä: se ei enää tue päätöstä vaan on itse keskustelun aihe. Siitä hetkestä eteenpäin jokainen luku kyseenalaistetaan, myös ne jotka ovat oikein.

Korjausta haetaan tavallisesti väärästä suunnasta. Vaihdetaan raportointityökalu, rakennetaan tietovarasto, ostetaan integraatio. Mikään näistä ei auta, koska mikään niistä ei päätä mitä liikevaihto tarkoittaa. Se on päätös, ja sen tekee ihminen.

Mittari ei ole luku vaan sopimus

Hyödyllinen tapa ajatella asiaa: mittari ei ole se luku, joka raportilla näkyy. Mittari on sopimus siitä, miten se luku muodostetaan. Luku on sopimuksen lopputulos, ja se voi olla oikein vain jos sopimus on olemassa.

Tästä seuraa kaksi asiaa, jotka ovat käytännössä koko oppaan sisältö. Ensinnäkin sopimus pitää kirjoittaa auki niin tarkasti, ettei kahta tulkintaa jää. Toiseksi sopimuksella pitää olla omistaja, koska sopimus ilman osapuolta ei sido ketään.

Tekninen toteutus tulee vasta kolmantena. Se on tärkeä — palaamme siihen, koska ilman sitä sopimus rapautuu muutamassa kuukaudessa — mutta se on sopimuksen toteutus eikä korvaa sitä. Datatiimi voi rakentaa laskennan, mutta se ei voi päättää lasketaanko peruutettu tilaus mukaan. Se on liiketoiminnan päätös, ja jos datatiimi joutuu tekemään sen, päätös on tehty väärässä paikassa.

Mitä määritelmään kuuluu

Toimiva määritelmä on lyhyt mutta täsmällinen. Alla oleva runko kattaa ne kohdat, joissa tulkinta käytännössä eroaa. Se mahtuu yhdelle ruudulle, mikä on tarkoituskin: määritelmä jota kukaan ei jaksa lukea ei ohjaa mitään.

Kaksi kenttää ansaitsee erillisen huomion, koska ne unohtuvat lähes aina. Aikaleima ratkaisee, mille kaudelle rivi kohdistuu — tapahtumapäivä, kirjauspäivä ja maksupäivä tuottavat kolme eri lukua samasta datasta. Ja rajaukset, eli se mitä nimenomaan ei lasketa mukaan, on se osa jota kukaan ei muista kysyä ennen kuin luku on väärä.

nimi: Liikevaihto
kysymys: Paljonko myyntiä kaudella syntyi?
paatos: Kuukausiraportti, budjettiseuranta, myynnin ohjaus

laskenta: >
  Myyntilaskujen veroton summa kaudella. Hyvityslaskut
  vähennetään samalta kaudelta jolle ne on kirjattu.

tarkkuustaso: kuukausi x kustannuspaikka
aikaleima: laskun kirjauspäivä (ei laskutus- eikä maksupäivä)
valuutta: EUR, muut kurssilla kirjauspäivän mukaan

ei_lasketa_mukaan:
  - arvonlisävero
  - konsernin sisäinen laskutus
  - käyttöomaisuuden myyntivoitot

lahde: analytics.fct_myyntilaskut
omistaja: talousjohtaja      # päättää määritelmän
toteuttaja: data-tiimi       # vastaa laskennasta
voimassa_alkaen: 2026-01-01

# Tämä kenttä säästää enemmän aikaa kuin mikään muu:
# kerro etukäteen mihin lukuun tämä EI täsmää ja miksi.
ei_tasmaa:
  - CRM:n myynti: sisältää voitetut tilaukset ennen laskutusta
  - verkkokaupan raportti: sisältää ALV:n ja toimituskulut

Viimeinen kenttä on kokemuksemme mukaan se, joka tuottaa suurimman hyödyn suhteessa kirjoittamiseen käytettyyn aikaan. Kun määritelmässä lukee valmiiksi mihin lukuun tämä ei täsmää ja miksi, ero lakkaa olemasta epäilyttävä. Ilman sitä sama keskustelu käydään uudelleen joka kvartaali.

Neljä kysymystä, jotka paljastavat keskeneräisen määritelmän

Määritelmä on valmis silloin, kun kaksi ihmistä laskee siitä saman luvun toisistaan riippumatta. Se on myös paras tapa testata se: antakaa määritelmä kahdelle ihmiselle, pyytäkää molempia laskemaan luku, ja verratkaa. Jos luvut eroavat, määritelmä on kesken — ei laskija.

Ennen sitä kannattaa käydä läpi nämä neljä kysymystä. Ne kattavat suurimman osan tapauksista, joissa kaksi rehellistä ihmistä päätyy eri lukuun.

• Millä päivällä rivi lasketaan? Tapahtumapäivä, kirjauspäivä, maksupäivä ja toimituspäivä ovat neljä eri lukua. Valitse yksi ja kirjoita se näkyviin.
• Mitä tehdään peruutuksille, palautuksille ja korjauksille? Vähennetäänkö ne alkuperäiseltä kaudelta vai siltä, jolla korjaus tehtiin? Molemmat ovat puolustettavissa, mutta vain toinen voi olla voimassa.
• Mitä ei lasketa mukaan? Tämä on se kohta, joka jää kirjaamatta, koska rajaukset tuntuvat itsestäänselviltä sille joka ne tietää.
• Millä tarkkuustasolla luku lasketaan, ja summautuuko se ylöspäin oikein? Prosenttiluvut ja keskiarvot eivät summaudu. Jos mittari on osuus, kokonaisuuden luku on laskettava kokonaisuudesta — ei osien keskiarvona.

Neljäs kohta on se, joka tuottaa hiljaisimmat virheet. Kun kustannuspaikkojen katemarginaalit lasketaan yhteen ja jaetaan neljällä, tulos ei ole yhtiön katemarginaali vaan luku, jolla ei ole nimeä. Se näyttää uskottavalta, ja siksi se elää raportilla vuosia.

Nimi on osa määritelmää

Nimeäminen ei ole kosmetiikkaa. Suurin osa väärinymmärryksistä syntyy siitä, että kaksi eri asiaa kulkee samalla nimellä — ja se on nimen ongelma, ei laskennan. Kaksi sääntöä riittää pitkälle.

Ensimmäinen: sama nimi ei saa tarkoittaa kahta eri laskentaa. Tämä on se vakavampi tapaus, koska se johtaa harhaan aktiivisesti. Toinen: sama laskenta ei saisi kulkea kahdella nimellä. Se on vähemmän vaarallinen mutta tuottaa jatkuvaa epävarmuutta siitä, ovatko luvut sama asia.

Kun samasta ilmiöstä tarvitaan aidosti kaksi lukua eri lähteistä, ratkaisu ei ole valita niistä toinen vaan nimetä molemmat lähteen mukaan. Konversiot GA4:stä ja konversiot Google Adsista ovat eri lukuja eri syistä, ja molempia tarvitaan. Ne eivät kuitenkaan saa kilpailla samasta nimestä, koska silloin kysymys "montako konversiota meillä oli" on vastaamaton.

• Käytä liiketoiminnan sanoja, ei tietokannan sarakenimiä. Raportin lukija ei tiedä mikä on net_rev_excl_vat.
• Erottele lähde nimessä silloin kun samasta asiasta on useampi virallinen luku.
• Vältä nimiä, jotka lupaavat enemmän kuin laskenta antaa. "Asiakastyytyväisyys" on eri asia kuin "NPS-vastausten keskiarvo".
• Kun määritelmä muuttuu olennaisesti, muuta myös nimi. Sama nimi, uusi laskenta on tehokkain tapa tuhota aikasarjan luettavuus.

Mittaristo ei ole luettelo mittareita

Määritelmät ratkaisevat sen, että luvut ovat oikein. Mittaristo ratkaisee sen, että katsotaan oikeita lukuja. Ne ovat eri ongelma, ja jälkimmäinen jää useammin tekemättä.

Organisaatio, joka seuraa kuuttakymmentä mittaria, ei seuraa mitään. Toimiva mittaristo on hierarkia: yksi luku, joka kertoo miten menee, kolmesta viiteen ajuria jotka selittävät sen, ja loput porautumista. Kun päämittari liikkuu, ajureista näkee miksi. Jos ei näe, ajurit ovat väärät.

Käytännön testi mittarille: mikä päätös muuttuu, jos tämä luku on eri? Jos vastausta ei ole, luku voi olla kiinnostava mutta se ei kuulu mittaristoon. Kiinnostavan ja ohjaavan luvun ero on juuri tässä, ja raportin arvo syntyy siitä että ne pidetään erillään.

• Erottele toteavat ja ohjaavat mittarit. Liikevaihto kertoo mitä tapahtui, tarjouskanta kertoo mitä on tapahtumassa. Mittaristossa tarvitaan molempia, mutta niitä ei lueta samalla tavalla.
• Jokaiselle mittarille tavoite tai vertailukohta. Luku ilman vertailua ei kerro onko tilanne hyvä.
• Jokaiselle mittarille joku, joka voi vaikuttaa siihen. Mittari, johon kukaan ei voi vaikuttaa, on sää — sitä katsotaan mutta siitä ei tehdä päätöstä.
• Uusi mittari mittaristoon tarkoittaa, että jokin toinen poistuu. Ilman tätä sääntöä mittaristo kasvaa aina.

Kuka omistaa määritelmän

Omistaja on se, joka omistaa päätöksen — ei se, joka rakentaa laskennan. Liikevaihdon määritelmän omistaa talousjohtaja, liidin määritelmän myyntijohtaja. Datatiimi omistaa toteutuksen ja on se, joka sanoo ääneen kun raportilla käytetään lukua väärin, mutta se ei päätä mitä luku tarkoittaa.

Tämä työnjako kannattaa sanoa ääneen, koska ilman sitä se menee lähes aina toisin päin. Datatiimi joutuu päättämään lasketaanko peruutettu tilaus mukaan, koska joku on kysynyt lukua ja vastaus tarvitaan tänään. Päätös tehdään, sitä ei kirjata mihinkään, ja puolen vuoden päästä siitä tulee riita.

Yksi omistaja per mittari. Kaksi omistajaa tarkoittaa käytännössä nollaa, koska kumpikaan ei voi päättää yksin eikä kumpikaan koe vastuuta. Jos mittari koskee kahta osastoa, omistaja on silti yksi — ja hänen tehtävänsä on kuulla toista.

• Omistajan tehtävä on hyväksyä muutokset määritelmään ja vastata rajatapauskysymyksiin. Se on muutama tunti vuodessa, ei rooli.
• Omistajan nimi kirjataan määritelmään. Nimetön määritelmä on ehdotus.
• Kun omistaja vaihtuu, määritelmä käydään läpi. Se on halvin hetki huomata, ettei kukaan enää muista miksi jokin rajaus on siellä.
• Muutoksista pidetään päätöslokia: mitä muutettiin, milloin, kuka päätti ja miksi. Yksi rivi per muutos riittää.

Määritelmä, joka ei ole koodissa, ei ole voimassa

Tässä kohtaa sopimus muuttuu tekniikaksi, ja tämä on se kohta jossa useimmat mittaristoprojektit epäonnistuvat. Määritelmät kirjoitetaan dokumenttiin, dokumentti hyväksytään, ja sen jälkeen laskenta toteutetaan erikseen jokaisessa raportissa. Muutamassa kuukaudessa dokumentti ja toteutus ovat eri mieltä, eikä kukaan tiedä kumpi on voimassa.

Vastaus tähän on yksinkertainen ja ehdoton: kun dokumentti ja koodi eroavat, koodi on se, joka tuottaa luvut. Dokumentti kertoo mitä pitäisi laskea, koodi kertoo mitä lasketaan. Siksi määritelmä pitää toteuttaa kerran, yhdessä paikassa, ja kaikkien raporttien pitää lukea sitä.

Se paikka on datamalli — SQL-näkymä, DBT-malli tai vastaava — ei raportointityökalun laskentakenttä. Ero näkyy siinä hetkessä, kun joku kysyy miten mittari on laskettu. Kun laskenta on mallissa, vastaus on tiedosto, jonka voi lukea ja jonka historiasta näkee milloin se muuttui. Kun se on raportilla, vastaus on se ihminen joka ehti rakentaa raportin.

Tähän ei tarvita erillistä semanttisen kerroksen tuotetta. Näkymä, jolla on selkeä nimi ja jota kaikki raportit käyttävät, on semanttinen kerros — riippumatta siitä mikä sen päällä on.

-- Rajaukset ovat mallissa, eivät raportin suodattimissa.
-- Suodatin unohtuu seuraavasta raportista, malli ei.
create or replace view `analytics.metric_liikevaihto` as
select
  date_trunc(kirjauspvm, month)  as kausi,
  kustannuspaikka,
  sum(summa_veroton)             as liikevaihto
from `analytics.fct_myyntilaskut`
where laskutyyppi in ('myynti', 'hyvitys')  -- hyvitys negatiivisena
  and konsernin_sisainen = false            -- rajaus määritelmästä
  and not myyntivoitto                      -- rajaus määritelmästä
group by kausi, kustannuspaikka

Vertailukohta: sama kolme rajausta kirjoitettuna kolmen eri raportin suodattimiin. Ne ovat siellä oikein sinä päivänä kun ne kirjoitetaan. Neljäs raportti rakennetaan puoli vuotta myöhemmin kiireessä, kaksi rajausta muistetaan ja yksi ei — ja siitä syntyy se luku, joka ei täsmää eikä kukaan tiedä miksi.

Testit tekevät määritelmästä pitävän

Määritelmä koodissa on parempi kuin määritelmä dokumentissa, mutta se ei vielä estä sen rapautumista. Lähdedata muuttuu, joku lisää uuden laskutyypin, rajaus lakkaa osumasta. Laskenta pyörii edelleen ja tuottaa luvun, joka on vain hiljaa väärä.

Tähän auttavat testit, jotka koodaavat määritelmän ehdot. Ne eivät ole yleisiä datan laatutestejä vaan väitteitä siitä, että laskenta vastaa yhä sovittua määritelmää. Ero on olennainen: not_null kertoo että arvo on olemassa, tämä kertoo että arvo on oikea.

• Tarkkuustaso on osa määritelmää: testaa että kausi ja kustannuspaikka muodostavat uniikin avaimen. Jos ei muodosta, mittari monistuu eikä sitä näe summasta.
• Osien summa vastaa kokonaisuutta: kustannuspaikkojen summa on sama kuin koko yhtiön luku.
• Täsmäytys lähdejärjestelmään: mittarin luku vastaa kirjanpidon lukua sentin tarkkuudella. Tämä on tärkein yksittäinen testi, ja se on myös se, jota harvimmin tehdään.
• Rajauksen vaikutus näkyviin: seuraa montako riviä kukin rajaus pudottaa. Kun määrä muuttuu yllättäen, rajaus on lakannut osumasta — ja se on tieto, jota ei saa mistään muualta.
• Merkkiraja: jos liikevaihto voi määritelmän mukaan olla vain positiivinen, testaa se. Negatiivinen luku on nopein tapa huomata että hyvitykset lasketaan kahdesti.

-- tests/liikevaihto_tasmaa_kirjanpitoon.sql
-- Testi palauttaa rivin vain kun jokin on pielessä, jolloin ajo
-- kaatuu ennen kuin väärä luku ehtii raportille.
with mittari as (
  select kausi, sum(liikevaihto) as summa
  from {{ ref('metric_liikevaihto') }}
  group by kausi
),
kirjanpito as (
  select kausi, sum(summa) as summa
  from {{ ref('fct_tuloslaskelma') }}
  where raporttirivi = 'Liikevaihto'
  group by kausi
)
select
  coalesce(m.kausi, k.kausi)  as kausi,
  m.summa                     as mittari,
  k.summa                     as kirjanpito
from mittari m
full join kirjanpito k using (kausi)
where abs(coalesce(m.summa, 0) - coalesce(k.summa, 0)) > 0.01

Täysliitos on tässä tarkoituksellinen. Sisäliitos vertaisi vain niitä kausia, jotka ovat molemmissa — ja jättäisi huomaamatta juuri sen tapauksen, jossa kokonainen kausi puuttuu mittarista.

Kun määritelmä muuttuu

Määritelmät muuttuvat, ja niiden kuuluukin muuttua. Liiketoiminta muuttuu, uusi tuotelinja ei mahdu vanhaan jaotteluun, tai huomataan että alkuperäinen määritelmä oli väärä. Kysymys ei ole miten muutos estetään vaan miten se tehdään niin, ettei se tuhoa luottamusta raporttiin.

Vaihtoehtoja on kaksi, ja valinta on tehtävä tietoisesti. Ensimmäinen on laskea historia uudelleen uudella määritelmällä. Silloin aikasarja on vertailukelpoinen läpi historian, mutta kaikki aiemmin raportoidut luvut muuttuvat — mukaan lukien ne, jotka on esitetty hallitukselle tai lähetetty ulos. Toinen on ottaa uusi määritelmä käyttöön tietystä päivästä eteenpäin. Silloin vanhat luvut pysyvät sellaisina kuin ne raportoitiin, mutta aikasarjaan tulee katkos.

Nyrkkisääntö: laske historia uudelleen, kun vanha määritelmä oli virheellinen. Ota uusi määritelmä käyttöön eteenpäin, kun liiketoiminta aidosti muuttui — uusi organisaatio, uusi tuotevalikoima — koska silloin vanha luku oli oikein omana aikanaan.

Kolmatta vaihtoehtoa ei ole. Määritelmää ei muuteta hiljaa. Luku, joka muuttui ilman että kukaan kertoi, maksaa enemmän luottamusta kuin luku, joka oli väärin ja korjattiin näkyvästi.

• Kirjaa muutokselle voimaantulopäivä ja säilytä vanha määritelmä luettavissa. Kysymys "miten tämä laskettiin viime vuonna" tulee varmasti.
• Merkitse katkos raportille siihen kohtaan, jossa se on. Alaviite aikasarjan alla riittää.
• Kerro muutoksesta ennen kuin luvut muuttuvat, ei sen jälkeen.
• Kun historia lasketaan uudelleen, tee se hallitusti ja kerralla — ei niin, että osa raporteista päivittyy ja osa ei. Uudelleenlaskennan tekninen puoli on käsitelty Dagster-oppaassamme.
• Jos muutos on niin suuri että luku tarkoittaa eri asiaa, anna sille uusi nimi vanhan päivittämisen sijaan.

Mittaristo, joka pysyy elossa

Määritelmät eivät ole projekti vaan ylläpidettävä asia. Ilman ylläpitoa mittaristo kasvaa ja rapautuu samaan aikaan: uusia mittareita lisätään pyynnöstä, vanhoja ei poisteta koskaan, ja muutaman vuoden päästä puolet raporteista on sellaisia joita kukaan ei avaa.

Ylläpito ei vaadi paljon. Kerran vuodessa tehty läpikäynti riittää useimmille organisaatioille, ja sen lisäksi tarkistus aina kun organisaatio, tuotevalikoima tai lähdejärjestelmä muuttuu. Läpikäynnissä kysytään jokaisesta mittarista kaksi asiaa: katsooko tätä kukaan, ja onko määritelmä yhä se mitä tarkoitamme.

Ensimmäiseen kysymykseen on olemassa data. Raportointityökalut kertovat kuka on avannut raportin ja milloin. Mittari, jota kukaan ei ole katsonut vuoteen, kannattaa poistaa — ja jos joku huomaa sen puuttuvan, se palautetaan. Käytännössä huomaamatta jää lähes aina.

Näin pääsette alkuun

Tästä aiheesta on helppo tehdä liian iso. Yleisin epäonnistumistapa ei ole se, ettei määritelmiä tehdä, vaan se että niistä tehdään hallintaprojekti: kuusikymmensivuinen dokumentti, työryhmä ja kolme kuukautta aikaa, eikä yhtään korjattua lukua. Määrittely on päivien työ, ei kuukausien.

Toimiva eteneminen on kapea ja nopea. Aloittakaa niistä luvuista, joista on jo eri käsityksiä — ne tuottavat suurimman hyödyn, ja niistä myös huomaa heti onko työstä ollut apua.

• Kahden tunnin työpaja: listatkaa ne luvut, joita johtoryhmässä oikeasti käytetään. Niitä on tyypillisesti 8–15, ei enempää.
• Merkitkää ne, joista on eri käsityksiä tai joista on jo riidelty. Aloittakaa näistä.
• Kirjatkaa määritelmät sovitussa muodossa, yksi mittari kerrallaan. Nimetkää omistaja jokaiselle samalla istumalla.
• Toteuttakaa kymmenen tärkeintä datamalliin ja lisätkää täsmäytystestit. Loput odottavat vuoroaan.
• Rakentakaa raportit vasta tämän jälkeen. Raportti valmiiden määritelmien päälle on päivien työ; raportti ilman niitä on loputon.

Yksi merkki siitä, että työ on onnistunut: kokouksessa lakataan kysymästä mistä luku tulee. Se on myös ainoa mittari, jolla tämän työn hyötyä kannattaa arvioida.

Yleisimmät virheet lyhyesti

• Luvut eivät täsmää, ja ratkaisuksi vaihdetaan työkalu. Uusi työkalu tuottaa samat kaksi lukua uudessa käyttöliittymässä.
• Määritelmä kirjoitetaan dokumenttiin mutta toteutetaan erikseen jokaiseen raporttiin. Dokumentti ja toteutus eroavat muutamassa kuukaudessa, eikä kukaan tiedä kumpi on voimassa.
• Aikaleimaa ei ole kirjattu. Sama data tuottaa neljä eri lukua sen mukaan, mitä päivää käytetään.
• Rajaukset jäävät kirjaamatta, koska ne ovat itsestäänselviä sille joka ne tietää. Seuraava toteuttaja ei tiedä.
• Osuudet ja keskiarvot summataan ylöspäin. Kokonaisuuden luku on laskettava kokonaisuudesta.
• Mittarilla on kaksi omistajaa, mikä tarkoittaa ettei sillä ole yhtään.
• Määritelmä muutetaan hiljaa. Luvut muuttuvat takautuvasti, kukaan ei kerro, ja luottamus menee kerralla.
• Sama nimi jätetään käyttöön, vaikka laskenta on muuttunut. Aikasarja näyttää muutokselta, joka ei ole tapahtunut.
• Mittaristoon lisätään mittareita mutta ei koskaan poisteta. Kuudenkymmenen mittarin mittaristo ei ohjaa mitään.
• Määrittelystä tehdään hallintaprojekti. Dokumentti valmistuu, luvut eivät korjaannu.