20.11.2015 / Janne Vihervuori

“Same as last year, nothing new.” That is a general comment about the SAP TechEd within our Finnish SAP ecosystem. Particularly among those who had not even participated last year, or even in several years. I do agree that some TechEd’s do not contain anything particularly new or flashy, but then again sometimes a paradigm shifting technology or product, like HANA, is introduced. Our universe functions the same: a quantum level wave function is beneath each physical observation. Sometimes we are on the peak of the (hype) wave and sometimes descending to reality where the innovations work.

Our Bilot crew of 8 attended the SAP TechEd in Barcelona last week. SAP did not publish any groundbreaking news or launch major products, so in that sense we got “same as last year.” However, some recently announced products were showcased, especially in the Analytics and Big Data areas, such as Cloud for Analytics (C4A) and VORA. Then, there’s the Digital Boardroom, but I am just wondering does it come with the furniture?-)

When it comes to the traditional SAP TechEd sessions, I concentrated on the Hands-On sessions. I thought that I can read the lecture slides later on, and if something is in the roadmap, it is in the roadmap as long as it is general availability. This is why I chose to take 6 Hands-On sessions. Can you beat that? Pro-tip for TechEd participants: as we know that one can reserve two dedicated sessions, there is no limit on how many additional sessions you can participate by taking the effort and queueing a little. I was usually the first guy in the queue taking care of business-as-usual and emails while standing there.

What was different, then?

  1. “The Digital Core”: HANA is not any more Vishal Sikka’s “little baby girl”, but a full-blown platform. This platform represents the Digital Core of an Enterprise together with S/4HANA. The concept of Core rhymes very well with something we’ve been developing at Bilot. It is called Bilot 3-Mode™, more about it later…
  2. SAP’s full Enterprise Stack that is standing on top of the “Digital Core”: back in the day someone would have named the individual pieces of this stack as “best of breed”. Let’s say you were implementing a green-field landscape: would you turn down SAP’s full enterprise stack offering of the Digital Core (HANA + S/4HANA), VORA with Hadoop, HCP, Cloud for Analytics, SuccessFactors, Concur, Ariba, hybris and Cloud for Customer that is available now? SAP has a “best-of-breed” Enterprise IT stack today.
  3. Shots Fired at Oracle in the Keynote: Steve Lucas aimed some tough shots at Oracle in his keynote. Then again, I guess the O-company fired the first shots, with poor accuracy. I have just one comment for the O-company: why don’t you set up and run an Oracle 12c database benchmark with S/4HANA? Yes. That is why.

Also, while am at it making lists: here are two wishes and suggestions to SAP AG regarding TechEd’s:

  1. Licensing: it is great to get one’s hands dirty on a variety of new technologies, such as Lumira, BO Design Studio, (S/4)HANA, VORA, HCI of HCP, API Management of HCP, etc. However, the reality that is called licensing will bite you when you get to discuss these topics with customers. As an SAP partner, it would be good to gain some leverage in the licensing area, maybe in the form of onboarding packages or new customer license collections? Maybe the licensing could be simpler, also?
  2. Complexity: while SAP “runs it simple”, the complexity remains and even grows. As entropy is eternally increasing in our universe, a similar observation can be done in the Enterprise IT. There, that was the second physics analogy of this post; I will not add a third. What I mean, as an example, is taking the hybris Data Hub and receiving the lecture information that, yes, you can implement asynchronous data transfer scenarios from the raw data model to a canonic one, but should you? Many new tools and solutions have overlapping functionalities and SAP could have a strong say on what to avoid and what to recommend – not just say that “you can do it all.”

16.11.2015 / Kristiina Burtsoff

Bilot started its journey to become a self-organizing company five months ago. First discussions about the whole thing happened only a couple of months before the kickoff, but the actual change process started just a few weeks before the first self-organizing pilot team of 24 experts was established. Many people have asked and are still asking, why Bilot is doing this.

Bilot is an independent and customer focused business technology company with 120 experts in Finland and in Poland. Bilot was founded in 2005 by leading experts in their field and is regarded as a pioneer when it comes to adopting and developing the latest SAP and Microsoft solutions. Bilot is a growth company and adapting to change has meant regular evolution in organizational and management structures.

The structure has always been a traditional line organization. Technology based consultant teams have been small and every team manager has had 3-8 subordinates. Team managers have reported to a director on the senior management team. Sales, operations, business support and development were matrix functions.

People have been taken really good care of. Development discussions were coordinated and trained by HR, employees’ satisfaction to their supervisors was surveyed twice a year and line management was coached to communicate and implement company strategy in their teams. Feedback was gathered and filtered by the manager and discussed in development discussions.

When everything was supposedly fine, why did we want to change?

Bilot operates in a business which changes rapidly. Challenges to hold on to and increase ones market position and keep ahead of others are enormous to any company, let alone in the IT business. We operate in many solution areas and we cater to large customers with complex IT environments. The demands to understand our customers’ businesses in many industry segments is pretty tough. This kind of business dynamic requires versatile skills from every single consultant. In order to be the best-in-class consultant you must follow your customer’s business closely and develop your technical skills continuously.

Our moderate size and fast growth defines us as a comparatively agile company. We have never been allowed to be stuck in old ways of thinking, but our organizational structure has not entirely reflected our philosophy. We do not believe in any company’s senior management’s superiority in sufficiently understanding our customer’s needs and always making the best decisions. We do believe in leadership, but leadership is not something that should be limited to a handful of people in a company. Leadership belongs to every role from the shop floor to the board room.

There are many critical success factors in this change at Bilot. People need support no matter which organizational structure they belong to. So we have trained mentors and coaches to offer support and sparring, when anyone feels the need for it. We are improving our communication methods, from top-down communication to collaboration and facilitation. Again, tools and training are needed. Direct feedback is essential for every expert, so no filtering is allowed anymore. The trick is how you provide the feedback, and this is the reason we emphasize in facilitation skills.

Processes and roles are changing quite a bit. Role descriptions are important for communicating the new ways of working and new sets of responsibilities. We also came up with a new way of describing processes and we changed the old swim lines and boxes to process maps based on the network of roles. Our organizational chart is a picture of a living organism with cells and neural networks with axons and synapses.

And last but not least, we must be able to dismantle the old power structures and distribute it appropriately. This is the hardest part. Every employee needs to feel that they have authority to do a good job and make great and successful business, as part of a self-organizing team. This is a challenge for every member of the self-organizing teams from now on.



13.11.2015 / Ville Niemijärvi

Myynti on seuraus. Eurot jotka kilahtavat kassaasi ovat seuraus yrityksesi ponnistuksista, oikeista tai vääristä toimista, sattumasta, luonnonvoimista.

Kun seuraat myyntieurojasi eli laskutustasi, katsot lopputulemaa. Jotain mihin et voi koskaan vaikuttaa. Löysät on jo housuissa. Aivan kuten jääkiekkovalmentaja tuijottaisi hävityn ottelun jälkeen pelkästään lopputulosta. Numeroita taululla. Ja koittaisi näin keksiä miten tähän tultiin. Miksi taas tuli pataan?

Myynnin seuranta on ajanhukkaa.

Syy on se mitä sinun pitäisi seurata. Asia mikä johti seuraukseen. Tappioon, voittoon, euroihin kassassasi.

Huomio raportoinnissa kiinnittyy vääriin asioihin

95% yritysten ja konsulttien tekemistä raporteista, analyyseistä ja tiedon visualisoinneista kohdistuu yleensä myynteihin eli tarkemmin laskutukseen. Tämä pitäisi olla 5%. Kerron miksi.

Ajatellaan normiyrityksen (teollisuus, vähittäis-/tukkukauppa jne.) ydinprosesseja, jotka näet kuvassa alla. Raaka-aineita/tuotteita ostetaan toimittajilta tai niitä valmistetaan itse. Tuotteita varastoidaan, joku markkinoi niitä ja myyntimies-mynttiset luukuttaa niitä asiakkaille. Sitten asiakas tekee tilauksen, joka toimitetaan. Sitten tehdään lasku. Jälkimarkkinointi, huolto, ylläpito tulee perästä.

Näinhän se toimitusketju jotakuinkin menee.
Yrityksen ydinprosessit Louhia

Otetaan sitten mukaan toiminnot mitä näihin prosesseihin liittyy. Eli aktiviteetit mitä ihmiset ja koneet tekevät eri vaiheissa.

Yrityksen prosessit ja niihin liittyvät toiminnot Louhia

Kuten kuvasta yllä näkee, osto ostaa tavaraa, markkinointi miettii mitä tuotteita mainostaa ja missä kanavassa, myyntijohtaja koittaa allokoida vähäisiä resursseja oikeille asiakkaille. Kun asiakas ostaa tuotteen, se toimitetaan hänelle nopeasti ja varmuudella.

Yhdestä asiasta seuraa toinen. Oston toiminta paisuttaa varastoa. Markkinoinnin aktiteetit työllistää myyntiä tai hyvässä lykyssä johtaa suoraan tilauksiin ja toimituksiin. Toimitus vähentää taas varastoa ja taas pitää ostaa ettei myydä ei-oota.

Asia vaikuttavat toisiinsa. Tämä on sitä työtä missä luodaan arvoa.

Sitten kun siirrytään prosessissa laskutukseen, ei siellä enää luoda arvoa, siellä niitetään sitä mitä on aiemmin kylvetty. Laskutus on lapiotyötä, täysin automatisoitavissa.

Kuitenkin raportoinnissa, business intelligence -hankkeissa tilanne on useimmiten alla kuvattu.

Yrityksen prosessit, toiminnot ja niiden mittaaminen Louhia

“Myynnin seuranta” tarkoittaa käytännössä lapiotyön seurantaa, että teemme tusinan verran raportteja, joilta näemme paljon myimme viime kuussa vs. edellinen. Kuinka paljon millekin asiakkaille, mitä tuotteita jne.

Hyvin harva raportti koskee markkinointia. Tai myyntiaktiviteetteja eli myyntien touhuja. Tai näiden kombinaatioita.

Keskittyessään pelkkään myynnin laskutukseen, raportointijärjestelmät ovat pistemäisiä seurantajärjestelmiä. Eivät johtamisjärjestelmiä.

 

Yritysten pitäisi ryhtyä seuraamaan syitä seurausten sijaan

Asioilla on seurauksensa. Yrityksen tulokseen vaikuttaa monen muuttujan ohella niin liikevaihto (laskutus) kuin varaston koko (sitoutuneen pääoman, velan ja varastointikustannusten muodossa).

Nämä ovat kuitenkin seurauksia, jotka johtuvat esimerkiksi kysynnän laskusta tai asiakaspoistumasta, joiden taustalla taas löytyy se primaarisyy. Joen alkulähde.

Liiketoiminnan Syy-seuraussuhteiden analysointi Louhia

 

Mutta ennen kuin voit seurata oikeita syitä jotka johtavat seuraukseen, sinun pitää löytää ne syyt. Saiko ovipumpun vinkumaan kaunis sää vai mainos lehdessä?

Osasiko puhelinmyyntikomppaniasi arvata oikean kohderyhmän tai ajoittaa soitot otollisimpaan aikaan päivästä ja saivat näin hyvän konversion? Vai oliko karmean myyntipäivän takana huonosti hoidettu asiakaskohtaaminen joka räjähti sosiaalisessa mediassa lokakampanjaksi vai pilaantuneet tuotteet hyllyssä, sateinen sää tai kilpailijan polkuhintakampanja?

Näihin kysymyksiin löytyy vastaukset. Jos niitä haluaa kysyä ja etsiä. Inttiaikojen Vekaranjärven everstiä lainatakseni: meillä on tahto, taito ja välineet. Edistyneen analytiikan -menetelmät ja työvälineet ovatkin yksi apu. Taitoa on markkinoilla varmasti riittävästi.

Mutta suurempi ongelma löytyy tahdosta. Yrityksestä itsestään. Useimmiten kenelläkään, toimitusjohtajaa lukuunottamatta, ei ole vastuuta koko prosessista. Moni (palkka)johtaja tyytyy turvaamaan oman tontin. Oman siilonsa.

Business controllereiden, kehityspäälliköiden tai trendikkäiden CDO:n (chief digital officer) rooli olisi kenties kehittää tiedolla johtamista tähän suuntaan. Harmiksemme monet todella fiksut business controllerit on valjastettu bio-mekaanisiksi releiksi lapioimaan lukuja raporteilta exceleihin ja exceleistä johdon powerpointeille. Voi sitä kaikkea hukattua ammattitaitoa.

Tämä on harmi, sillä löytämällä ne myynnin ajurit, primaarisyyt seurausten taustalla, luodaan todellista kilpailuetua. Tämän merkitystä ei valitettavasti ole vielä ymmärretty.

Voitkin tehdä tuhansia myynnin seurannan raportteja mutta myyntisi ei niitä tuijottamalla liikahda minnekään. Kun selvität syyt onnistumisten ja epäonnistumisten takana, voit vaikuttaa näihin. Voit toistaa ne. Voit vaikuttaa myyntiisi. Ja sitten homma muuttuu hauskaksi.


10.11.2015 / Lasse Liukkonen

Monesti olen törmännyt kysymykseen “Miten mitataan kahden eri tuotteen myynnin välistä korrelaatiota?” tai vastaavasti “Miten tuotteen A myynnin historiaa voidaan käyttää tuotteen B kysynnän ennustamisessa lähitulevaisuuteen?”. Konseptina näissä kysymyksissä esiintyivät aikasarjat.

Alkuun voisi kuvitella, että näihin kysymyksiin löytyisi selkeät ja yksikäsitteiset vastaukset, näin ei asianlaita kuitenkaan ole, ainakaan jokaiselle datan ja mallintamisen parissa työskentelevälle. Melkeinpä uskaltaisi väittää, että jokainen aikasarjojen kanssa puuhastellut data-analyytikko on ainakin kerran huomaamattaan laskenut kahden aikasarjan välisen korrelaation teoreettisessa mielessä virheellisesti. Se, onko korrelaation laskennan oletuksien huomiotta jättäminen aiheuttanut liiketoiminnan mielessä katastrofaalisia seuraamuksia on toinen seikka.

Käymme tässä kirjoituksessa läpi vastauksia edellä esitettyihin kysymyksiin esimerkkiaineiston avulla. Esimerkkiaineistoksi on generoitu seuraavat kuvitteelliset myynnin aikasarjat:

1) Lada Samaran kappalemääräinen myynti kuukausitasolla; 2010-01 -> 2013-12,

2) Lada Samaran sytytyspuolien kappalemääräinen myynti kuukausitasolla; 2010-01 -> 2013-12.

Se, miksi tarkastelemme juuri Lada Samaran ja sen varaosana sytytyspuolia ei ole titenkään kovinkaan oleellista, mutta se, että tarkastelemme tuoteparia {auto, varaosa} on oleellista jatkon tarkasteluissa. Oletetaan vielä lisäksi, että tarkasteltavan Lada Samaran kanta on pienehkö ennen tarkasteltavaa aikaväliä ja, että sytytyspuolien rikkoutuminen on Lada Samaroiden tyyppivika.

Seuraavassa tarkasteltavien aikasarjojen kuvaajat:

ladasamara

ladasamarapuola

 

Kuinka mitata kahden aikasarjan välistä korrelaatiota? Mitä on syytä ottaa huomioon? Onko korrelaation laskentatapa yksikäsitteinen?

 

Ennen korrelaation (vai korrelaatioiden?) laskemista on syytä tarkastella aikasarjojen kuvaajia samasta kuvasta päällekkäin ajallisesti sijoitettuna, sillä usein jo silmämääräinen tarkastelu antaa tietoa tuotteiden myyntien välisestä suhteesta. Tässä esimerkkitapauksessa voimme ajatella korrelaation arvon heijastavan myös “kausaalisuuden suuruutta”, koska tarkasteltavaksi tuotepariksi oli valittu {auto, varaosa}.

ladasamara_ladapuola

 

Ensipuraisulla näyttää siltä, että myyntien välillä voisi vallita vahva korrelaatio, mutta kuinka korrelaatio tässä esimerkkitapauksessa laskettaisiin?

1) Tavallisesti numeerisien satunnaismuuttujien välisenä (lineaarisen riippuvuuden) korrelaationa käytetään Pearsonin korrelaatiokerrointa. Aikasarjojen tapauksessa korrelaatio lasketaan tarkastelemalla aikasarjojen vastakkaisia havaintopareja, esimerkin tapauksessa 3 ensimmäistä havaintoparia ovat (1028030, 2991930), (597848, 1021953), (1220731, 1222494). Havaintoparien ensimmäiset lukuarvot vastaavat Lada Samara:n myyntiä ja vastaavasti jälkimmäiset sytytyspuolien myyntiä tarkasteltavana ajankohtana. Pearsonin korrelaatiokerroin on tässä tapauksessa 0.46 (yllättävän pieni arvo?), kerroin näyttää hyvältä ja sen merkkikin ongelman kannalta lienee oikea. Olemmeko tyytyväisiä? Emme!

Mikä edellisen kohdan laskennassa jäi huomioitta?

2) Itse ilmiötä pohtiessa tulee mieleen, että eikö autojen myynnin ja varaosien ostojen välillä tulisi ilmetä jokin “keskimääräinen viive”, ainakin tapauksissa, jossa varaosan hankkiminen johtuu tyyppiviasta? Pitäisikö siis laskea 1)-kohdan tapaan korrelaatiokertoimien arvot eri viiveillä (siirretään sytytyspuolien myynnin aikasarjaa taaksepäin kuukausi kerrallaan)? Tässä kertoimet 9:llä eri viiveen arvolla:

korrelaatio_kertoimet

 

Näyttäisi siltä, että suurin aikasarjojen välinen korrelaatiokerroin esiintyy, kun tarkastellaan sytytystulppia 6kk viiveellä. Pillit pussiin, case solved, alakerran baariin? Ei!

Jäiköhän jotain vielä huomioimatta?

3) Itseasiassa edellisessä kohdassa laskettiin ns. ristikorrelaatioita, eli kahden aikasarjan välisiä korrelaatioita eri viiveen arvoilla. Jos olemme jossain määrin täsmällisiä, niin ristikorrelaatio on (ensisijaisesti) määritelty (vahvasti) stationaarisille aikasarjoille.

Onko esimerkissä tarkasteltavat aikasarjat stationaarisia, ts. tulee tarkastaa muuttuuko niiden jakaumat eri ajanhetkien välillä, jos muuttuvat, niin kyseiset aikasarjat eivät ole stationaarisia. Molemmissa aikasarjoissa on selkeästi havaittavissa nouseva trendi, joten aikasarjat eivät selvästikkään ole stationaarisia. Tyypillisin “todellista” korrelaatiota vääristävä tilanne on juuri se, että molemmat tarkasteltavista aikasarjoista sisältävät likipitäen saman suuntaisen trendin. Tälläisissa tapauksissa laskennallinen korrelaation arvo tulee olemaan yli arvioitu, vaikkei aikasarjojen välillä todellisuudessa tulisikaan esiintyä merkittävää korrelaatiota (kausaalisuutta).

Ratkaisuna edellä mainittuun ongelmaan voidaan yrittää dekomponoida aikasarjat (huom! vaatii kuukausittaisilta aikasarjoilta yleensä väh. 3 vuoden datan). Dekomponoinnissa aikasarjat paloitellaan kolmeen erilliseen komponenttiin: trendi-, kausivaihtelu- ja jäännöskomponentti. Seuraavassa kuvat aikasarjojen dekomponoinneista:

decomp_ladasamara

decomp_sytytyspuola

 

Erityisen kiinnostavaa esimerkkitapauksessa on tutkia kausikomponenttien välistä yhteyttä, sillä sytytyspuolien myynnin kausivaihtelu ei näytä olevan ainakaan vuodenaikaan loogisesti sidottuna => sytytyspuolien myynnin kausivaihtelu “täytyy” johtua kausittaisesta autojen myynnistä. Auton myynnin ja sytytyspuolien (6kk viive) myynnin kausikomponenttien välinen ristikorrelaatio on 0.92. Voidaanko/pitäisikö kausikomponenttien ajatella olevan stationaarisia, satunnaisia, deterministisiä?

Ei paneuduta edellä esitettyihin pohdintoihin sen tarkemmin, pääasia on kuitenkin se, että pääsimme jossain määrin eroon trendin vaikutuksesta. Mainittakoon kuitenkin vielä kerran, että oleellista tässä laskennassa oli se, että kummankaan tuotteen kausivaihtelu ei seurannut mitään vuodenaikaa säännöllisesti. Jos näin kuitenkin päitisi tarkasteltavien kausikomponenttien suhteen, niin ristikorrelaation arvo ei olisi antanut oikeaa kuvaa tuotteiden välisestä suhteesta. Jos esimerkiksi molemmat tuotteet olisivat olleet kesäsesonki-tuotteita, niin ristikorrelaatio olisi varmasti ollut suuri vaikkei tuotteilla olisi mitään tekemistä keskenään. Korrelaatio laskettuna, wippii! Eiku…?

4) Yleisessä tapauksessa teoreettisessa mielessä lähinnä oikeaa laskentatapaa olisi laskea jäännössarjojen välinen ristikorrelaation arvo, olettaen, että aikasarjojen dekomponointi tuottaa jäännössarjat, jotka ovat likipitäen stationaarisia. Jäännöstermien välinen suurin ristikorrelaation arvo löytyy jälleen viiveellä 6kk ja on 0.39, mitäs hittoa? No jippohan piilee siinä, että tarkasteltavien tuotteiden kausivaihtelut ovat sen verran vahvat ja sidoksissa toisiinsa, että jos poistamme kausikomponentit alkuperäisistä sarjoista häviämme rutkasti informaatiota tuotteiden välisestä suhteesta, sillä kyseessä ei ollut tavanomainen vuodenajasta johtuva sarjojen kausivaihtelu.

5) Lasketaan vielä kerran ristikorrelaatioiden arvot de-trendatuille (kausi+jäännös) Lada Samaran ja sytytyspuolien aikasarjoille, päädymme ristikorrelaation arvoon 0.75 (viiveellä 6kk).

Kuten edellä esitetyt kohdat tuovat ilmi, ei korrelaation laskeminen aikasarjojen tapauksessa välttämättä ole aivan yksiselitteistä ja helppoa. Tässä esimerkin tapauksessa aikasarjojen välinen “todellinen” korrelaatio lienee 0.7 ja 0.92 välillä vai onko?

Olipa oikea korrelaation arvo mitä tahansa edellä mainittujen lukujen väliltä, voidaan varmasti todeta, että tuotteiden väliltä löytyy ilmeinen kausaalisuussuhde: autojen myynnin kasvu kasvattaa sytytyspuolien myyntiä ja tämähän on täysin loogista. Lisäksi voitanee olettaa, että viive auton myynnin ja sytytyspuolan rikkoutumisen välillä on keskimäärin 6kk.

 

Kuinka auton myynnin avulla voidaan ennustaa sytytyspuolien myyntiä lähitulevaisuuteen?

 

Edellisessä kohdassa saimme selville, että sytytyspuolien myynti (kysyntä) reagoi 6kk viiveellä autojen myyntiin. Tämän seurauksena voimme ennustaa historiatoteumien perusteella sytytyspuolien kysynnän 6kk päähän nykyhetkestä (melko tarkasti?) käyttämällä autojen myynnin toteumatietoa.

Seuraavassa kuvat ennusteista:

(Ylin) Ennusteet käyttämällä selittävänä muuttujana autojen myynnin aikasarjaa sellaisenaan,

(Keskellä) Ennusteet käyttämällä de-trendattua autojen myynnin aikasarjaa,

(Alin) Ennusteet käyttämällä selittävänä muuttujana auton myynnin kausivaihtelukomponenttia.

whole_timeseries

 

 

forecast_not_trend

 

 

decomp_only

Myöskään ennustamisessa ei ole yksiselitteistä käyttääkö selittävää aikasarjaa sellaisenaan vai esimerkiksi jotain sen dekomponoinnin tuottamaa komponenttiaikasarjaa. Ennusteet eroavat yllättävän paljon esimerkin tapauksessa. Ristiinvalidoinnin avulla voi tietysti tapauskohtaisesti katsoa mikä näistä vaihtoehdoista toimii parhaiten tarkastelavan ilmiön osalta, ongelmana ristiinvalidoinnissa on vain yleensä saatavilla oleva myyntihistoria.


7.11.2015 / Ville Niemijärvi

Mika Aho kirjoitti oivasti Talentum Eventsin blogissa data-ohjautuvan kulttuurin muodostumisesta. Hyviä pointteja, käy lukaisemassa täältä.

Tykkäsin erityisesti ideasta järjestää yrityksen sisällä yhteisiä datapajoja – tilaisuuksia, joissa dataa (raportteja, visualisointeja, työpöytiä) ihmetellään yhdessä, tulkitaan ja keskustellaan. Ei jätetä siis poloista päätöksentekijää itse tulkitsemaan mittareita ja kpi-arvoja.

Meillähän minkä tahansa järjestelmän käyttöönotto tarkoittaa korkeintaan käyttökoulutusta: miten softa avataan, mistä klikataan jne. Tiedolla johtamisessa kyse on kuitenkin ennen kaikkea sisällön ymmärtämisestä ja tulkitsemisesta. Siinä tarvitaan usein keskustelua kollegoiden kesken.

Aikalailla ennen kokematonta Suomessa, että joku kehtaisi edes kysyä miten se kate tai kiertonopeus meillä nyt laskettiin tai mitä ebitda tarkoittikaan ja mitä tällä tiedolla nyt pitäisi tehdä, mutta suosittelen kokeilemaan.

Oma kehittyminen alkaa siitä kun nöyrtyy kysymään.

Koulunpenkille ennen kuin annetaan avaimet auton rattiin

Tästä tulikin mieleen eräs asiakas vuosia sitten. Teollisuusalan yrityksen tuotteen valmistusprosessi oli pitkä, monivaiheinen ja siihen sisältyi useita eri toimijoita. Näin ollen myös kuluja kertyi pitkin matkaa useasta eri kanavasta: raaka-aineita, palveluja, työtä, lisää raaka-aineita jne.

Kate- ja tuottavuuslaskentaa varten yrityksessä oli tehty hyvin monimutkainen kustannusten allokointimalli. Tämän mallin tuloksia me raportoimme eteenpäin johdolle tyylikkäissä työpöydissä ja raporteilla.

Tavoitteena oli, että johto pystyy lukujen perusteella johtamaan ja ohjaamaan valmistusprosessia. Tietää missä vaiheessa kuluja kertyy, paljonko se vaikuttaa katteeseen? Mitkä tuotteet ylipäätään ovat kannattavia ja miten kannattavuutta voitaisiin nostaa?

Mutta ennen kuin yksikään loppukäyttäjä pääsi käsiksi raportointiportaaliin ja työpöytiin, heidän piti käydä läpi sisäinen koulutus. Jos et käy kurssia, et näe raportteja. Piste.

Yritys halusi varmistaa, että käyttäjä todella ymmärtää sisällönMistä luvut ovat peräisin? Miten laskenta on tehty, mitä laskukaavoja on käytetty? Miten lukuja pitää tulkita?

Tieto on valtaa ja valtaa seuraa vastuu

Tämä tiukka ja jokseenkin puritanistinen näkökulma nykypäivän avoimen datan ja organisaatiokulttuurin aikakautena kuulostaa kummalliselta, mutta ymmärsin täysin yrityksen linjavedon.

He olivat tehneet business intelligence -järjestelmästä strategisesti ja taktisesti tärkeän johtamisvälineen. Kun käytössäsi on voimakas työväline, jonka varassa sinun pitää tehdä päätöksiä, pitää olla täysin varma että tiedät miten lukuja tulkitaan. Ja kyse ei ollut nappikaupasta.

Kannatan itse täysin avoimen datan ja läpinäkyvyyden periaatteita. Tiedon suojaaminen (muista kuin laillisista tai turvallisuuteen liittyvistä perusteista) on turhaa. Kaikilla pitää olla lähtökohtaisesti pääsy vähintäänkin itselle relevanttiin tietoon. Eli informaatio pitää demokratisoida kuten Aho nostaa blogissaan esille.

Vanhan kliseen mukaan: tieto on valtaa. Tiedon demokratisointi antaa tämän vallan kaikille. Tällöin tulee muistaa, Hämähäkkimiestä lainatakseni, että valtaa seuraa vastuu: “With great power comes great responsibility.”


3.11.2015 / Ville Niemijärvi


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