Konsulttiurani alussa sain projektipäällikön pestin. Tehtävänä oli hoitaa asiakkaalle pienimuotoinen tietovarasto- ja raportointiprojekti.
Kyseessä oli 3 eri lähdejärjestelmää ja nippu tekstitiedostoja, jotka piti viedä SQL Server SSIS:llä tietovarastoon, johon tuli pari-kolme faktataulua ja kymmenisen dimensiota. Tähän päälle metamalli Cognoksen Framework Managerilla ja iso joukko raportointikuutioita Cognos Transformerilla. Toisin sanoen hyvin suoraviivainen oppikirjaesimerkki. Ei mikään pienin mahdollinen toteutus (ottaen huomioon useat lähdejärjestelmät ja kuutiotkin olivat aika laajoja sisällöltään) mutta ei suurikaan.
Asiakas pyysi työmääräarviota. Tuumailin hieman, katsoin asiakkaan tekemiä esimäärittelyjä ja totesin, että tämä tehdään 20 päivässä.
Kun kerroin tämän tiiminvetäjälleni, häneltä meinasi leuka tippua. “Kuules Ville, en ole koskaan nähnyt, että DW-projektia olisi tehty alle 50 päivän, saati sitten 20 päivän.”
Kaverilla oli silloin lähes 10 vuoden kokemus alalta joten varmasti tiesi mitä puhui.
Homma kesti 21 htpv. Ylitin budjetin ja pahoittelin sitä asiakkaalle, joka ei ollut siitä moksiskaan. Tein siis kokeneen konsultin arvioiman vähintään 50 htpv työn 20 päivään ja se ei tehnyt edes tiukkaa. Miten tämä oli mahdollista? Tässä muutama pointti miksi homma toimi:
1. Keskity olennaiseen – Jätä kaikki turha pois.
Koska kyseessä on suoraviivainen toteutusprojekti jossa tiedetään mitä halutaan, mistä data haetaan ja miten sitä pitää käsitellä, ilman 3. osapuolia, ei tarvita monia niitä vaiheita mitä isommissa hankkeissa on. Ei tarvitse käyttää päiviä projektinhallintaan, johtoryhmän kokouksiin, projektisuunnittelman ja riskimatriisien kirjoittamiseen. Testaus on hyvin suoraviivaista lukujen mätsäämistä raporteilta tietovarastoon ja siitä lähdetauluun.
Mitä vähemmän liikkuvia osia sitä parempi. Ammattilainen osaa arvioida milloin voidaan jättää projektisuunnitelmasta osia pois ja milloin ne pitää ehdottomasti pitää mukana.
2. Uusiokäytä, kierrätä
Tässä casessa asiakkaalla oli käytössä vanha raportointijärjestelmä josta pystyimme nappaamaan SQL-lauseet ja muokkaamalla niitä hieman, upottamaan suoraan tietovaraston ETL:ää varten. Meidän ei tarvinnut tehdä syvällistä lähdejärjestelmien analysointia ja etl-prosessi pystyttiin viemään kymmenesosalla siitä mitä se normaalisti olisi vienyt (oppikirjasääntö: etl-toteutus vie normaalisti n. 70% koko DWBI-hankkeen kestosta).
Sama homma lähdetietokantojen “uusiokäyttämisen” kanssa. Useimmiten sama tietokantajärjestelmä sisältää samat tiedot samoissa tauluissa ja kentissä siirryttäessä yrityksestä toiseen. Toisin sanoen jos olet hakenut joskus myyntidataa Oraclesta tai SAP:sta ja siirryt toiselle asiakkaalle tekemään samaa homma, löydät samat myyntitilausotsikot ja -rivit aivan samoista tauluista. Toisin sanoen voit uusiokäyttää edellisessä projektissa tehtyjä SQL-kyselyitä ja jopa kokonaisia etl-ajoketjuja – ja säästää asiakkaalle kymmeniä tuhansia euroja.
Tietovarastoarkkitehtuuri on kolmas kierrättämisen paikka. Väitän, että sama tähtimalli sopii 9/10 tietovarastoprojekteista. Aivan, sinun yritykseksi on tietenkin juuri poikkeus joka tekee aivan erilaista liiketoimintaa kuin kukaan muu maailmassa. Voi olla, mutta silti valtaosa teollisuus- tai kaupan alan yrityksistä valmistaa/ostaa tuotteita, varastoi niitä ja lopulta myy asiakkailleen. Toisin sanoen heillä on faktatapahtumia (ostotilaukset, saldot ja myynnit). Lisäksi heillä on asiakkaita, tuotteita ja myyjiä/myymälöitä, toisin sanoen dimensioita.
Tästä saadaan tietovaraston tietomalli, jonka olen toteuttanut kymmenille suomalaisille yrityksille lähtien kansainvälisistä teollisuuden pörssiyrityksistä, suuriin vähittäiskauppoihin, tukkukauppoihin ja pieniin konepajoihin. Tietenkin kentät tauluissa hieman vaihtelevat mutta pääasiallisesti rakenne on identtinen. Jos olet siis tekemässä tällaiseen ympäristöön tietovarastoa, ei sen mallintamiseen tarvita kymmeniä päiviä määrittely- ja suunnittelutyötä, minulla on sinulle malli valmiina ja säästät taas kymmeniä tuhansia.
Kierrätystä on tietenkin toimittajan tuotteistus lähtien aina raporttimäärittelypohjista, joiden avulla edetään nopeasti ja määrätietoisesti. Tämä antaa asiakkaallekin kuvan, että toimittajalla on homma hanskassa.
3. Vähemmän porukkaa on parempi
Jos kullekin työvaiheelle on oma roolinsa: vaatimusmäärittely, testaus, etl, raportointi ja projektipäällikkö, tulee paljon ylimääräistä viestitystä ja työtä. Ammattilaiset osaavat useampia asioita, tulisi ainakin osata.
Tässä nimenomaisessa projektissa kollegani hoiti etl-työn ja etl:n testaamisen. Minä hoidin kaiken muun. Kaksi ammattilaista riittää useimmiten tekemään alle 100 henkilötyöpäivän hankkeet. Miksei isompiakin jos aikataulu sen sallii.
Esimerkiksi projektipäällikön ei siis pidä olla vain hallinnollinen kumileimasin ja tuntien tarkkailija, varsinkaan pienissä ja keskisuurissa hankkeissa. Tästä on minulla yleensä vain huonoja kokemuksia. Jos projektipäällikkö ei osallistu edes määrittelyihin ja ei tunne laisinkaan kohdealuetta tai projektin tuotoksia, on hän yleensä vain kiviriippa. Toisessa laidassa on tietenkin näitä +1000 henkilötyöpäivän ultramaratonhankkeita, joissa pp:n ei ole mahdollisuuttakaan ottaa osaa itse työhön. Näissä massiivivissa hankkeissa tosin on paljon isompiakin ongelmia (vinkki: älä lähde tekemään överimassiivisia DW-hankkeita kerralla, pilko ne aina pienempiin projekteihin. Kukaan, koskaan, missään ei ole niissä onnistunut).
Erillistä testaajaa ei kannata edes harkita, se on hukkainvestointi. Testaajat, teidän ammattitaitoa vastaan ei ole mitään enkä halua väheksyä testaamisen merkitystä. Ongelma on siinä että tietovarastohankkeiden testaamista ei kannata irroittaa aihealueen osaamisesta (liiketoiminta) tai tietovaraston sisällön osaamisesta (eli testaaja tuntee DW:n rakenteen). Parasta onkin, että raportoinnin testauksen suorittaa business käyttäjät, usein yrityksen controllerit jotka muutenkin pyörittelevät samoja lukuja. He näkevät heti jos luvuissa on jotain mätää.
Erillinen toimittajan tarjoama testaaja voi luoda testitapauksia tuhansia ja ihmetellä niitä edes takaisin mutta hän ei välttämättä saa kiinni olennaisia virheitä itse luvuissa. Syy on siinä, että välttämättä virhe ei ole etl-prosessissa tai raporteissa vaan koko logiikka on väärin. Ja usein tämän tajuaa vasta kun loppuasiakas näkee luvut raporteilla (vinkki: kun teet tietovarastoa, pyri siihen että alle kuukauden sisällä asiakas näkee ensimmäiset raportit ja pystyy validoimaan lukuja. Tästä alkaa vasta varsinainen kehitystyö).
4. Toimittaja osaa asiansa
Tunnet toimialan, työvälineet ja prosessit. Tunnustetaan tosiasiat: on päteviä tyyppejä ja sitten on niitä joita ei soisi edes pahimmalle viholliselleen töihin. Samaan työhön saattaa mennä yhdeltä kaverilta päivä ja toiselta viisi. Vinkki asiakkaalle: selvitä työntekijöiden osaamistaso, vaadi parasta. Pyydä referenssit. Tiedä mitä haluat.
5. Asiakas osaa asiansa
Annetaan todellinen kunnia sinne minne se kuuluu: tämän nimenomaisen projektin onnistumisen suurin syy oli asiakas. He olivat tehneet tietotarvemäärityksen lähes valmiiksi. He olivat poimineet valmiiksi nuo edellä mainitut sql-kyselyt. He tiesivät mitä haluavat, he tunsivat lähdejärjestelmän, datan ja sen käyttäytymisen. Ja luonnollisesti liiketoiminnan. Heiltä sai täyden tuen lyhyen projektin aikana. Olisin oikeasti joutunut tekemään töitä jotta olisin voinut töpeksiä tuon hankkeen.
Tämä ei tarkoita, että projektit onnistuvat vain kun käy niin hyvä tuuri, että toimittaja kohtaa tietovarastoinnin ja raportoinnin suhteen valveutuneen asiakkaan. Toimittajan tehtävänä on ennen projektin aloitusta ja sen aikana vaatia asiakkaalta noita edellä mainittuja ominaisuuksia. Asiakkaalta saa vaatia omistautumista projektille. Heiltä pitää vaatia liiketoiminnan tuntemusta ja heille tulee ehdottomasti teroittaa mikä merkitys niin ajallisesti kuin rahallisesti on sillä, että asiakas tietää todella mitä haluaa. Ja jos ei tiedä, niin toimittajan tehtävänä on auttaa selvittämään tuo tarve ennen kuin lähdetään itse toteutustyöhön.
Esimerkki tietovarastoprojektin työmääristä
No mihin se 21 päivää sitten meni? Päivät käytettiin jotakuinkin näin:
- Aloituspalaveri, tietotarvemäärittely, projektisuunnitelma: 1 htpv
- Tietomallinnus, lähdejärjestelmien ja tietomallin mäppäys: 2 htpv
- ETL-työ eli tietovaraston rakennus: 12 htpv
- Raportoinnin metamalli: Cognos Framework Manager -työ: 1 htpv
- Raportointikuution toteutus: Cognos Transformer -työ: 3 htpv
- Kuutioiden julkaisu, ajoketjujen automatisointi, virheiden valvonta: 1 htpv
- Testaus, parit pienet fiksaukset etl:ssä ja kuutioissa: 1 htpv
YHTEENSÄ 21 henkilötyöpäivää
Tuon uran alkuaikojen projektin jälkeen olen tehnyt lisää 20 htpv projekteja ja osa reilusti alle. Tietovarastohankkeiden ei tarvitse siis olla ikuisuusprojekteja ja ne voi myös pysyä budjetissa. Kun hankit seuraavan kerran konsulttia tekemään hommaa, kysy häneltä reilusti referenssejä ja pyydä pilkkomaan työmääräarviot mahdollisimman pieniin paloihin. Tai sitten pyydä tosiammattilaiset paikalle.
