Vuosia sitten olin suurehkon tietovarasto- ja raportointiprojektin projektipäällikkönä. Annoin asiakkaalle projektin työmääräarvioiksi n. 300 henkilötyöpäivää. Vajaan vuoden jälkeen kun hanke saatiin maaliin, oli päiviä mennyt 400.
Olin ylittänyt siis asiakaslupaukseni 33%:lla ja päivähinnan ollessa n. 1000 euroa, olin hävittänyt asiakkaan rahaa 100 000 euroa.
No enhän minä niitä rahoja itse hupuloinut, projektiryhmä teki koko vuoden hommia ja asioita saatiin valmiiksi mutta silti – työmäärien ylitys oli valtava eikä asiakas ollut laisinkaan tyytyväinen vaikka muuten toimitettiin sitä mitä piti ja ihan aikataulussaan. Ja ei – asiakasta ei voinut syyttää tässä(kään) projektissa: vaatimukset eivät muuttuneet merkittävästi matkan aikana, asiakkaan johto ja projektiryhmä oli sitoutunut hankkeeseen ja saimme asiakkaalta kaiken mahdollisen tuen tehdä menestyksekäs projekti.
Mutta mikä sitten meni pieleen? Kun savu oli hälvennyt ja punoitus korvissa laskenut, kerrattiin mitä opimme:
Historiadata voi yllättää
Dataa oli kohtuullisen paljon (satoja miljoonia rivejä per faktataulu (5 kpl) ja joissain dimensioissa satojatuhansia rivejä) ja DW:n lähteenä toimivia ERP-järjestelmiä oli useita. Jotta suorituskyky olisi ollut riittävä ja toteutus ylipäätään mahdollista ja riittävän nopeaa, kehitystyössä käsiteltiin vain parin viimeisen vuoden dataa.
Mutta kävikin niin, että kun etl-lataukset oli valmiina ja testiraportit oli validoitu ja alettiin ladata isoa historiaa mukaan, ei historiadatan osalta toiminutkaan samat säännöt kuin tuoreelle datalle. Toisin sanoen historiadatassa saattoi yhdessä ERP:ssä olla erilaisia tuoterakenteita, faktadatassa saattoi olla virheellisiä merkkejä ja muuta sellaista, joka kaatoi etl-lataukset tai aiheuttivat virheellisiä tietoja raporteille.
Tämän vuoksi jouduimme tekemään joidenkin ERP:ien osalta DW-toteutuksen lähes uudestaan: lähdedatan analyysin, tietojen mäppäyksen DW:n tietomallia vasten ja etl-prosessin toteutuksen. Tähän kului helposti 20 htpv ylimääräistä.
Isojen datamassojen lataus vie pirusti aikaa, varsinkin kun sen tekee 10 kertaa
Riippuu toki miten paljon rautaa on rajalla mutta kun ERP:ssä on ladattavana miljardi riviä dataa ja sql-lauseke on monimutkainen, voi pelkästään parin kuukauden lataaminen kestää koko päivän. Ja kun ladataan 5 vuoden data, menee siinä helposti useita viikkoja.
Tänä aikana ei faktadataa vasten oikein sitten pystykään tekemään mitään muuta. Ja kun tulee valmista, huomaamme että historiadatassa onkin jokin bugi, joka tarkoittaa että parin vuoden datat on ladattava uudestaan. Tähän jumppaan saimme menemään muistaakseni n. 15-20 htpv extraa suunnitellusta (15-20 000 euroa).
Ylläpitokustannuksiin kannattaa varautua
Tietovarastoympäristöjen ylläpitokustannukset on kuluerä, johon ei yleensä varauduta, ainakaan riittävästi. Ylläpitokustannukset koostuvat etl-latausten korjauksista, uusinta-ajoista ja vian selvityksistä jos ne kaatuvat, raporttien tai kuutioiden uusinta-ajoista jne. Mitä enemmän on dataa, mitä useampi tietolähde ja mitä heikommin alunperin tunnetaan lähdedata ja mitä nopeammin hanke viedään läpi – sitä enemmän pitää varata rahaa ylläpitoon.
Olen tehnyt DW-ympäristöjä, joissa ylläpitoon on mennyt 1 htpv/vuosi (asiakas oikeasti otti vuoden jälkeen ensimmäisen kerran yhteyttä kun jokin tieto ei päivittynyt) mutta sitten taas joskus ylläpitoon menee ensimmäisen puolen vuoden aikana 10 htpv/kk.
Tässä hankkeessa ensimmäinen vaihe (pari faktaa ja kourallinen dimensioita) saatiin maaliin jo 3-4kk kuluessa. Projekti jatkui tästä mutta samaan aikaan jo toteutetut kokonaisuudet siirrettiin tuotantoon. Mutta projektipäällikkö eli allekirjoittanut ei ollut muistanut mainita asiakkaalle mitään uudesta kuluerästä joka oli alussa n. 5-10 htpv per kuukausi. Emme olleet eriyttäneet ylläpitoa erilliseksi kokonaisuudeksi ja budjetoineet sille erikseen rahaa. Emmekä olleet varautuneet todellakaan, että ylläpitoon voisi upota näin paljon massia – ja siihenhän upposi.
Varmasti asiakas oli ymmärtänyt, että ylläpito vie rahaa, kunhan joku olisi sen hänelle kertonut. Ja se joku pölvästi olin minä. Budjetoimatonta rahaa paloi tähän vähintäänkin 40 htpv edestä (40 000 euroa)
Ja kyllä ne vaatimuksetkin aina vähän muuttuvat
Sen verran perutaan puheita, että kyllä asiakkaan vaatimukset hieman muuttuivat. Mutta kumma olisi ollut jos ne olisi pysyneet vuoden aikana ennallaan, muuttuvat vaatimukset ovat tervetulleita koska silloin tietää että kehitysprosessi on todella iteratiivinen ja prosessin aikana opitaan uutta. Varsinkin DW/BI -hankkeissa asiakas todella ymmärtää mitä voi saada aikaan ja mitä haluaa kun hän näkee ensimmäiset raportit. Sitä ennen tehdyt vaatimusmäärittelyt ovat vain suuntaa-antavia harjoitelmia.
Muuttuneet raporttivaatimukset vaativat lisätyötä ja sitä kului n. 15-20 htpv ylimääräistä. Oleellista tässä kuitenkin oli, että alkuperäiset työmäärät olivat liian kunnianhimoiset. Niihin olisi pitänyt laittaa hieman puskuria ja varautua siihen, että muutoksia tulee ja raportteja iteroidaan useamman kerran.
Tätä projektia ennen olin aina välillä paukutellut henkseleitä miten hyvä track record meikäläisellä on ja miten nappiin projektit johdollani menee. Mutta kun on hassannut 100 000 euroa asiakkaan rahaa ja kuunnellut aivan ansaittua tilitystä asiakkalta, loppuu paukuttelu lyhyeen ja konsultti palaa nöyränä ruotuun.
Tietovarastoprojektin sudenkuoppia on edellä mainittujen lisäksi tusinan verran lisää. Jos haluat tietää miten vältät ne omalta osalta, ota yhteyttä.
Ainiin, yhteistyö kyseisen asiakkaan kanssa jatkuu edelleen ja erinomaisissa merkeissä.
