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:

• Projektin suunnittelu (ns. 0-vaihe: scope, tavoitteet, toimintamallit)
• vaatimusmäärittely, suunnittelu (tietomallit, arkkitehtuuri jne.)
• Toteutus x iteraatiota: sis. tietovarasto + raportointi
• Testaus, käyttöönotto: n. 10% toteutuksen työmääristä
• projektinhallinta: n. 10-15% koko projektin työmääristä

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:

• Vähän dataa: 10 000 – 1 000 000 riviä per faktataulu (esim. myynti, sis. koko historian)
• Keskiverto: 1 000 000 – 100 000 000 riviä per faktataulu
• Paljon dataa: 100 000 000 ->
  
  Vaikutus työmääriin (DW-toteutustyöhön lisäkerroin):
• Vähän dataa: kerroin 1
• Keskiverto: kerroin 1,5
• Paljon dataa: kerroin 2

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ä:

• isojen tietomassojen lataus vie aikaa. Jos päivität tauluun satoja miljoonia rivejä dataa update/insert:llä ja teet sille paljon laskentaa, haet surrogaatit jne., saattaa tämä kestää tuntikausia. Kun taas 100 000 riviä menee yleensä muutamassa minuutissa. Eroja alkaa tulemaan kun latauksia pitää tehdä kehitystyön aikana jatkuvasti uudestaan ja uudestaan kun huomataan virheitä latauksissa.
• pitkä historia sisältää usein huonolaatuista dataa. Mitä pidemmältä ajalta dataa on, sitä suurempi todennäköisyys on, että historiassa on ollut jotain eri käsittelysääntöjä tai muuten vain erilaista dataa. Tämä aiheuttaa aina lisätyötä etl-prosessissa.

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

Luokittelen raportit 3 luokkaan vaatimustason mukaan:

Taso 1: Helpot raportit: 1 htpv/raportti

• yksinkertainen lista/graafi
• ei toiminnallisuuksia, ei vaatimuksia vasteajoille (raportin ajo saa kestää hieman)

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

• useampi lista/graafi
• pientä toiminnallisuutta, esim. valintalistoja, porautuminen, monimutkaisempia filttereitä ja aikavertailuja

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

• useampi lista/graafi, dashboard, karttapohja
• monimutkainen toiminnallisuus: esim. filtteröinti käyttäjätunnuksen mukaan
• tarkat vaatimukset layoutille ja vasteajoille

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:

• tehdään nopea metamalli: 2 htpv
• tehdään 1 kuutio: 5 htpv
• tehdään 1 vaativa raportti ja 4 helppoa raporttia: 8 htpv
  Yhteensä: 15 htp

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.

• käyttäjät ovat ”tuntemattomia” eli tehdään extranet-ratkaisu (heidän selaimet, näyttöjen resoluutiot , käyttötavat jne. ovat tuntemattomia)
• raportointi on julkisessa internetissä, käyttäjämääriä ei tiedetä
• toiminnallisia vaatimuksia (esim. datan suodatus rivitasolla käyttäjäoikeuksiin perustuen monimutkaisen matriisiorganisaation tarpeisiin)
• erillisen käyttäjähallinnan toteutus (ei voida hyödyntää valmista Active Directory:ä)
• dataa pitää kirjoittaa raporteilta takaisin tietokantaan
• monimutkaiset simuloinnit joissa x vaikuttaa y:hyn 20 eri muuttujan kautta
• monimutkaiset dashboardit ja balance scorecard -toiminnallisuudet

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ä?

• käyttäjät tietävät mitä haluavat > määrittely on nopeampaa, iteraatioita tarvitaan vähemmän
• data tunnetaan, tietolähteet ovat tuttuja > etl-työssä kuluu aikaa huomattavasti vähemmän
• tiedon laatu on kunnossa > testaus on huomattavasti nopeampaa

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:

• Projektin suunnittelu ja aloitus: 5 htp
• Vaatimusmäärittely: 10 htp
• Tekninen ympäristö (palvelimet, ohjelmistot): 2 htp
• Toteutus:
  • DW (ETL-työ): 2 htp * 2 lähdettä * 8 kohdetta = 32 htp. Lisäkerroin datamääristä 1,5*32= 48 htp
  • Raportit: 4 htp * 1 iso työpöytä + 1 htp * 4 helppoa raporttia = 8 htp
  • Yhteensä totetutus: 56 htp. Lisäkerroin alhaisesta maturiteetista: 1,5 * 56 htp = 84 htp
• Testaus: 10% toteutuksen työmääristä eli pyöritettynä: 8 htp
• Projektinhallinta: 10% kokonaistyömääristä: 109 htp * 0,1 = 11 htp

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?

Blog writer

Ville Niemijärvi

See profile