03.11.2015

Miten arvioida tietovarasto- ja raportointiprojektin kustannuksia?


-100 päivää, sen verran se kestää, piste.

Mutta Matti kiltti, voisitko kuitenkin avata vähän tätä rakentamiseen menevää aikaa. 100 päivää on aika ylimalkainen…
-Ei näitä aleta pilkkomaan. Se vie minkä se vie.

Kuuntelin sivukorvalla kun projektipäällikkö yritti saada tietovarastoarkkitehtiä purkamaan noin 100 päivän eli karkeasti 100 000 euron investointia tarkemmalle tasolle. Pätevä ja mukava kaveri mutta todella old school, oli tottunut tekemään töitä, paperinpyörittely ja työmääräarviot kuului muille.

Itse annoin raporttiarkkitehdin ominaisuudessa omat työmäärät puolenpäivän tarkkuudella ja erittelin joukosta vielä vessa- ja kaffetauot. Kunnon etupenkin ahterin lipoja siis.

Haluaako toimittaja laittaa vähän ilmaa työmääriin vai onko hän vain epäpätevä?

Vaikka Matti (osoite muutettu) on mukava ja pätevä niin kokeneen ammattilaisen pitää pystyä pilkkomaan työmäärät tarkalle tasolle. Tämä on osa kokemuksen tuomaa ammattitaitoa. Jotain mitä myös asiakkaiden pitää vaatia toimittajilta.

Jos toimittaja ei pilko työmääriään könttäsummaa tarkemmalle tasolle, hän ei joko:

a.) osaa tehdä sitä eli ei tiedä miten tietovarastoja rakennetaan tai
b.) hän on ylimielinen asiakasta kohtaan ja haluaa laittaa työmääriin ilmaa eli rahastaa asiakasta

Pahimmassa tapauksessa molempia.

Mikä on tarkka taso työmäärille? Itse pyrin siihen, että tehtävät laitetaan päivän tai parin palikoihin. Jos nyt 3-5 päivän könttiin päästään niin sekin on hyvä. Mutta 10 päivää on jo turhan ylimalkainen, sadasta puhumattakaan.

Okei, kun tehdään +1000 päivän hanketta ja alussa hahmotellaan projektisuunnitelmaa niin sallitaan vähän isommatkin köntsät, kunhan ne ei ole konsultin housuissa.

Miten arvioida DW/BI –hankkeen kustannuksia?

Kerron seuraavaksi yhden karkean tavan arvioida työkustannuksia ennen kuin projekti on alkanut ja kun ei vielä tiedetä kaikkia detaileja. Malli ei pidä sisällään asiakasyrityksen omia työmääriä.

Tämä on karkea, suuntaa-antava ja ei tarkoituksella pidä sisällään kaikkia DW-projektin tehtäviä ja yksityiskohtia. Nämä pilkotaan sitten esille projektisuunnitelmaa tehdessä. Malli ei ota kantaa käytetäänkö jotain kehitystyön nopeuttajaa ja se sopii parhaiten perinteiseen dimensionaaliseen tietovarastomalliin, sovellettavissa toki vaikka data vault -maailmaan.

Tämän on tarkoitus olla tyhjää parempi, tämä ohjaa oikeaan kokoluokkaan. Kun halutaan tietää onko kyseessä 20ke vai 200k€ hanke. Mallin avulla myös asiakas voi itse päätellä nopeasti, mitä kustannus voisi olla. Tämän avulla asiakas voi arvioida, onko toimittajan arviot tai toteuma laisinkaan realistisella tasolla.

Muistakaa kuitenkin, että aina, siis ihan aina, tulee eteen jotain yllättävää. Jokin vaatimus muuttuu, lähdetiedoista paljastuu outouksia, testaus venyy kun asiakkaalla on muita kiireitä… Mitään pomminvarmaa millimetripaperin tarkkaa mallia ei ole olemassakaan. Emmekä pyri selittämään koko maailmaa, emme edes tietovarastointia.

Mutta yksinkertainenkin malli on parempi kuin ei mitään. Ja kun edes hieman yrittää miettiä ja tuotteistaa tekemistä, johtaa se yleensä aina parempaan tulokseen kuin ei tekisi mitään. Tai yrittäisi selittää kaiken.

Kaikki palaute ja parannusehdotukset laskentamalliin otetaan vastaan, joten kommentoikaa rohkeasti tai laittakaa mailia. Ja kärsimätön twitter-sukupolvi, joka ei jaksa lukea pitkiä sepustuksia voi hypätä kirjoituksen loppuun jossa homma on vedetty yhteen esimerkin kera.

Laskentamalli DW/BI-hankkeen työkustannuksille

Tietovarastoinnin työkustannusten arviointiin kuuluu tietyt enemmän tai vähemmän kiinteät osiot, kuten projektin aloitus ja suunnittelu, teknisen ympäristön pystytys, vaatimusmäärittely… ja sitten on liikkuvat osat kuten toteutus (tietovarasto + raportit).

Kiinteitä osioita ovat:

En avaa tässä tarkemmin mitä nämä vaiheet pitää sisällään. Poraudutaan sen sijaan olennaiseen eli miten arvioida sitä isointa epämääräistä kokonaisuutta eli toteutuskustannuksia.

DW:n toteutuskustannuksiin vaikuttaa seuraavat tekijät:

  1. Tietolähteiden ja asiakokonaisuuksien (käsite/kohde/entiteetti) määrä
  2. Datan määrä ja ennen kaikkea laatu
  3. Raporttien, mittarien, työpöytien määrät
  4. Tekninen monimutkaisuus ja erityisvaatimukset (DW, raportit, jakelu)
  5. Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen
    (esim. osallistuminen suunnitteluun ja määrittelyyn, testaaminen)
  6. Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradetaan)

Seuraavassa malli miten arvioida kunkin tekijän vaikutusta.

1.) Tietolähteiden ja asiakokonaisuuksien määrä
(asiakokonaisuus: esim. myynti, varastosaldot, tuote, asiakas)

Suuntaa antava yleisohje: 1 kokonaisuus vie 2 htpv toteutustyötä per tietolähde.

Laskukaava on siis: 2 pv * lähteiden määrä * asiakokonaisuuksien määrä.

Mihin tuo 2 päivää sitten menee? Sen aikana tiedot ladataan lähdejärjestelmästä (muodostetaan SQL-kysely, joka lukee esimerkiksi myyntitilausotsikot ja –rivit ERP:stä ja lataa ne tietovaraston staging-alueelle. Tämän jälkeen tiedot viedään DW:n faktatauluun, harmonisoidaan data jos se tulee useasta taulusta, muodostetaan surrogaattiavaimet, hoidetaan tiedon historiointi (hitaasti muuttuvat dimensiot) ja muut perusrutiinit.

Tässä muutama esimerkki:

Myynti-faktataulun muodostaminen yhdestä lähteestä: 2*1*1 = 2 htp
Myynti-fakta ja tuotedimensio kahdesta lähteestä: 2*2*2 = 8 htp
Myynti, tuote ja saldotaulu kolmesta lähteestä: 2*3*3 = 18 htp
Myynti, tuote, saldot, asiakkaat, myymälät, toimittajat ja varastotapahtumat 3 lähteestä: 2*7*3= 42 päivää

Tämä laskumalli on tehty DW:n tähti-/lumihiutalemallia varten käyttäen 2-tasoista hierarkiaa (stage+DW). Jos mallinnat DW:n data vault –mallilla, joudut vähän soveltamaan tätä.

Data vault vaatii usein 3 kerrosta (stage+raw vault + business vault) ja tähän päälle pitää rakentaa vielä tähtimalli, jotta raportointi on mahdollista. Eli 4-kerrosarkkitehtuurin myötä työmäärät kasvavat jonkin verran. Oma kokemus data vaultista on sen verran vähäistä, että joku kokeneempi data vault konkari voi arvioida ja kommentoida tätä. Yhden lähteen mukaan data vaultin työmäärät ovat kolminkertaiset dimensionaaliseen mallintamiseen verrattuna. Toisaalta useilla suomalaisilla data vaultilla toteuttavilla konsulttitaloilla on jotain kehitystyötä kiihdyttäviä apuvälineitä. Mutta ei mennä siihen tällä erää tarkemmin.

Tuo edellä mainittu 2 päivää asiakokonaisuutta kohden tarkoittaa sitten nappisuoritusta. Että kaikki menee hyvin. Se edellyttää kokenutta ETL-tekijää ja ei ole haittaa, että tuntee vähän miten datat on mallinnettu ERP:ssä. Se tarkoittaa, että liiketoiminnan säännöt tunnetaan hyvin ja tiedetään esim. miten rajataan sisäinen laskutus pois myyntilaskuista tai miten valuuttamuunnokset tehdään. Toisin sanoen se tarkoittaa, että tekninen määrittely on tehty hyvin.

Jos teknistä määrittelyä ei ole tehty ja jos lähdedataa ei tunneta, tuo 2 päivää voi kasvaa 20 päiväksi. Jos tiedetään, että esim. tuotekoodit eroavat tietolähteiden välillä, lisätään mäppäystyöhön extrapäiviä.

2.) Datan määrä (rivejä tietokannan tauluissa)

Suuntaa antava yleisohje:

Esim. DW-toteutus (etl-työ) pienellä datalla  = 30 htpv, keskiverto datamäärillä 45 htpv ja suurilla data määrillä 60 htpv.

Miksi lisääntynyt data aiheuttaa ongelmia? Kyse on kahdesta tekijästä:

3.) Raporttien, mittarien yms. määrä

Luokittelen raportit 3 luokkaan vaatimustason mukaan:

Taso 1: Helpot raportit: 1 htpv/raportti

Taso 2: Keskivaikeat raportit : 1-3 htpv/raportti

Taso 3: Vaikeat raportit: +4 htpv/raportti (15 htpv monimutkaiseen raporttiin ei ole harvinaisuus)

Raportteja ennen pitää tehdä usein metamalli, esimerkiksi SAP:n Universe, Cognoksen Framework Manager –malli tai Microsoftissa esim. data source view Reporting Servicen osalta. Metamallin päälle, tai rinnalle, saatetaan tehdä raportointikuutio.

Jos tietovarasto on hyvin mallinnettu, metamallin tekeminen on yleensä hyvin suoraviivainen. Varaan itse Cognoksen Framework Manager –mallinnukseen 2 päivää. Jos suunnitellaan suurta enterprise-tason mallia, jossa on tiedon suojauksia ja paljon liiketoimintalogiikkaa, on hyvä varata 5-10 htpv.

Kuutioiden toteutukseen varaan 5 htpv. Kuutioista saadaan yleensä ensimmäinen malli ulos päivässä mutta sitten se varsinainen hierominen vasta alkaa.

QlikViewn tapauksessa ei ylläoleva laskenta ihan päde koska siellä tehdään enemmänkin raporttiapplikaatioita, jotka sisältävät useita erillisiä raporttiobjekteja. Laskentaa voi kuitenkin soveltaa QV maailmaankin.

Esimerkkilaskelma Cognos-maailmasta:

4.) Tekninen monimutkaisuus, erityisvaatimukset raportoinnille

Yksinkertainen toteutus: yrityksen sisäiseen käyttöön, pienelle käyttäjämäärälle, ei erityisiä toiminnallisia vaatimuksia.

Monimutkaisuutta lisää mm.

Arviota näiden vaikutuksista ei voida antaa ennen raporttien määrittelyä. Usein lisäkerroin työmääriin koskee jotakin tiettyä kohdetta, esim. monimutkainen tuote-käsittely tai kustannusten allokointi ja jyvitys katelaskentaa varten. Harvoin koko ympäristö on erityisen monimutkainen.

Esimerkkinä: eräässä kuluttajille suunnatussa raportointiprojektissa käyttöoikeuksien hallinta /kirjautuminen oli oma n. 100 00€ aliprojekti.

5.) Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen

Kun lähdetään toteuttamaan tietovarasto- tai raportointiprojektia, kaikki yritykset vakuuttavat että he ovat ylintä johtoa myöten sitoutuneita homman läpivientiin ja kaikki tuki on hankkeen takana.

Mutta sitten kun pitää alkaa iskemään päiviä kalenteriin tästä juhannukseen saakka eli investoimaan omaa aikaa työhön, ääni muuttuu usein kellossa.

Sama pätee hankkeiden ja datan omistajuuteen. Sitoutuminen tarkoittaa myös sitä, että hankkeesta ottaa vastuun yksi henkilö. Joku jolla on riittävän suuri mandaatti ja natsat puhua hankkeen puolesta yrityksen johtoryhmässä, saada sille riittävästi huomiota ja rahoitusta muiden kymmenien hankkeiden joukosta.

Sitoutumisen määrää on vaikea mitata ja sen vaikutusta työmääriin hankala arvioida. Jos kuitenkin yritys epäilee jo alussa oman ajankäytön riittävyyttä, jos projektille ei löydy omistajaa ja jos datalle (esim. tuote-dimensio) ei löydy omistajaa, kannattaa valmistautua työmäärien lisääntymiseen.

6.) Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradataan)

Kirjoitin taannoin siitä, miten tietovarastot eivät ole enää mammuttihankkeita. Tarkoitin tällä sitä, että kun yritys on tehnyt jo yhden tai pari tietovarastoa tai raportointiympäristöä, on sen maturiteetti jo aika hyvä.

Miten maturiteetti näkyy työmäärissä?

Jos tehdään ihka ensimmäistä tietovarastoa, käyttäisin kerrointa 1,5 arvioidessa työmääriä. Eli kun korkean maturiteetin yritys joka tekee uuden sukupolven tietovarastoa arvioi toteutustyöksi 100 htp niin matalan maturiteetin yrityksen kannattaa varata samaan työhön 150 htp.

Yhteenveto: tietovarastojen toteutustyön ja kustannusten arviointi

Tietovarastoympäristöjä rakentaessa työmäärät voivat heilahdella todella paljon ja olen nähnyt samasta työstä annettavan 20 päivän ja 120 päivän työmääräarvioita. Molemmat olivat pihalla kuin lumiukko ja osoittivat vähäistä ammattitaitoa ja toisen osalta halua kupata asiakas kuiviin.

Purkamalla toteutustyön osuuden atomeiksi eli mahdollisimman pieniin osiin, voidaan työmääriä arvioida usein hyvinkin tarkalla tasolla. Lisääntynyt läpinäkyvyys ei ole haitaksi luottamuksen rakentamisessa asiakkaan ja toimittajan välillä.

Oma suuntaa-antava arviointimalli perustuu seuraavaan kaavaan:

  1. Tietolähteiden ja asiakokonaisuuksien (käsite/kohde/entiteetti) määrä:
    • 2 pv * lähteiden määrä * asiakokonaisuuksien määrä.
    • Esim. myynti ja tuote -taulut yhdestä tietolähteestä: 2 htp * 1 tietolähde * 2 kohdetta = 4 htp
  2. Datan määrä ja ennen kaikkea laatu:
    • Vähän dataa: kerroin 1
    • Keskiverto: kerroin 1,5
    • Paljon dataa: kerroin 2
  3. Raporttien, mittarien, työpöytien määrät
    • Helppo raportti: 1 htp/raportti
    • Keskivaikea raportti: 1-3 htp/raportti
    • Vaikea raportti: +4 htp/raportti
  4. Tekninen monimutkaisuus ja erityisvaatimukset (DW, raportit, jakelu)
    • tapauskohtaista, vaatimusmäärittelyn jälkeen tiedetään paremmin
  5. Yrityksen/organisaation sitoutuminen projektin läpivientiin ja tukemiseen
    • Arvioitava näppituntumalla. Vaikea asia perustella asiakkaalle jos käyttää isoa kulmakerrointa.
  6. Tekniset valmiudet ja maturiteetti (0 –taso vs. valmis BI-ympäristö, joka upgradetaan)
    • Aivan uusi tietovarasto, alhainen maturiteetti: kerroin 1,5
    • Yritys on jo tehnyt aiemmin tietovarastoja, korkea maturiteetti: kerroin 1

Esimerkkilaskelma tietovaraston ja raporttien rakennuskustannuksista, sisältäen kiinteät osuudet:

Esimerkkiympäristön kuvaus: 2 ERP-järjestelmää. Tunnistettuja faktakäsitteitä on myynti, ostot, varastosaldot ja varastotapahtumat. Tunnistettuja dimensioita on tuote, asiakas, organisaatio, aika. Yhteensä siis 8 asiakokonaisuutta/kohdetta ja 2 lähdejärjestelmää.

Yritys tekee ensimmäistä tietovarastoa ja tiedon laatu on kysymysmerkki. Valmiita sql-lauseita ei ole saatavilla kuin osittain vanhoilta Excel-raporteilta. Teknisesti ei ole asetettu mitään erityisehtoja toiminnallisuuteen. Raportteja tehdään 1 isompi työpöytä ja 4 perinteistä listaraporttia.

Rivimäärät on keskivertoja, kaikki taulut yhteensä n. 2 miljoonaa riviä.

Arvioidut työmäärät:

KAIKKI YHTEENSÄ: 120 htp

Käytän itse tätä mallia tehdessä karkeata arviota tietovarastoprojektin tai vaikka projektiin liittyvien lisätöiden kustannuksista. Se luo läpinäkyvyyttä ja nostaa luottamusta myös asiakkaassa kun hän tietää mitä tulemme tekemään ja mistä näemme työn muodostuvan.

Projektisuunnitelmassa ja tuntiseurannassa työt jaetaan sitten vielä paljon pienempiin osiin, esimerkiksi yksi faktataulu voidaan laittaa kolmeksi seurantakohteeksi: 1. stagelataus, 2. dw-lataus ja 3. testaus. Käyttäjähallinta, ympäristön automatisointi, virheiden valvonta, käyttöönotto, koulutukset ja dokumentoinnit tulevat tietenkin päälle. Mutta tietovarastojen projektin hallinnan vaihejako ja parhaat käytännöt on sitten toisen kirjoituksen aihe.

Toivottavasti tästä mallista on hyötyä muillekin ja jos teillä on parempia laskentamalleja tai korjausehdotuksia niin laittakaa tulemaan mailia tai kommentoikaa tätä kirjoitusta alla.


Ps. Jos aihe kiinnostaa, lue myös vanha kirjoitus: Paljonko tietovarasto maksaa?

Share
Contact Person

Blog writer

Ville Niemijärvi

Vincit Bilot

Bilot & Vincit have joined forces!

See where the story continues 

You have Successfully Subscribed!

Vincit Bilot

Bilot & Vincit have joined forces!

See where the story continues 

You have Successfully Subscribed!