21.03.2018 / Nanni Koski

Lyhenteiden viidakossa kehitin itselleni muistukseksi uuden: DBD. Mistä tämä sitten on lyhennys? Käydään ensin katsomassa Googlesta, jos satuttiin osumaan johonkin nuorison käyttämään hypetermiin. Itse asiassa Urban Dictionaryn kaksi ylintä termiä sopii teemaan, joten pidetään vielä jännitystä yllä.

 DBD = ”Damn, bro, damn”

Yleensä käytetty ilmaisemaan ilmeisesti vaikuttuneisuutta, mutta tässä tapauksessa toi mieleeni päivän, joka tuntui data scientistin painajaiselta. Olen erityisen ihastunut kreikkalaisiin aakkosiin, joten otetaan ne mukaan selventämään tilannetta. Eli latinalaiset aakkoset viittaavat tunnettuihin asioihin ja kreikkalaiset johonkin tuntemattomaan, mikä ei suorilta ole selvää. Sanottakoon, että projektin vetohahmo sattui olemaan tänä päivänä lomalla, mikä lisäsi tulevan tehtävän haastetta.

Tehtävä: Asiakas A lähettää Excel-tiedoston B, jonka välilehdistä osalla, merkitään [math] \alpha_1, \ldots, \alpha_\beta [/math]  on tietoja, jotka tulee päivittää tiedostoon / tiedostoihin [math] \gamma_1, \ldots, \gamma_\delta [/math] kansiossa [math] \varepsilon [/math] palvelimella [math] \zeta [/math] ja sen jälkeen ajaa tauluihin [math] \eta_1, \ldots, \eta_\theta [/math] kannassa [math] \iota [/math] latauksilla [math] \kappa_1, \ldots, \kappa_\lambda [/math].

Juuri niin helppoa kuin se ääneen luettuna kuulostaa olevan.

Vaikea palapeli

Ehkä tunnin työ, jos kreikkalaisten aakkosten merkitys tässä kontekstissa on tuttu. Jos selvittäminen vaatii valistuneita arvauksia, niin tällaista ongelmaa ei ratkaista googlettamalla.

Tästä päästään sanakirjan seuraavaan ehdotukseen:

DBD = ”Don’t be Dumb”

Sanonnan kirjaimellinen käännös sopii aiheeseen paremmin kuin tarkoitettu ”Don’t worry”. Eli älä ole typerä – dokumentoi tekemisesi.

Mitä uusia muuttujia dataan luotiin, miksi ja millä tavalla? Rajattiinko osa havainnoista tarkastelun ulkopuolelle? Toki osa asioista on haastavampia dokumentoida. Ja joskus vasta kokeilut osoittavat, mikä toimii ja mikä ei. Ja kyllähän sen muistaa, miksi koodi meni näin ja missä järjestyksessä eri tiedostot tulee ajaa. Se on selvää, että tämä koodi löytyy täältä kansioista. Ja tuo tiedosto valitaan tässä tietyssä tilanteessa. Ja se päivitettävä osio koodissa on juuri tuo. Ja että jos haluaa saada aikaan tämän, niin käy muuttamassa tuolla valikossa arvoja. Niin ja muuttujien datatyyppien muunnokset pitää ottaa huomioon. Mutta sehän on selvää tulevan virheilmoituksen perusteella, jos sen sattuu saamaan. Eikö vaan?

Liian monta sekavaa ohjetta

No ei.

Miksi, mitä, miten ja mihin siis dokumentoida? Ja se tärkein eli:

Kuka? Sinä, juuri sinä. Just do it.

Mitä? Ajatukset ja toteutukset projektiin liittyen.

Miksi? Asiantuntemus. Muistipaikkojen vapauttaminen omasta päästä. Lähimmäisenrakkaus. Sharing is caring. Ja ehkä silloin saa viettää jonkun lomapäivän tarvitsematta vastata yhteenkään työpuheluun.

Miten? Tiimin / Asiakkaan saataville. Vaikka Wordillä, PowerPointilla, Notepadilla, R Markdownilla tai Trelloon.

Mihin? Dokumentoinnista ei ole hyötyä, jos sitä tarvitseva ei sitä löydä. Eli varmista, että tiimille on selvää, mistä työsi hedelmät on poimittavissa muidenkin iloksi.

Ehkä suurin ongelma dokumentoinnissa on kuitenkin se, kun into lähtee lapasesta ja perille pääsee nopeammin raskaalla kaasujalalla kuin jokaisen taukopaikan kautta. Kun tässä eräänä päivänä lisäilin koodin joukkoon jälkikäteen selityksiä siitä, miksi olin muokannut dataa esitetyllä tavalla, totesin, että eipä olisi ollut suuri vaiva kirjoittaa ne jo tehdessä.

DBD = ”Document before Doing”

Tästä eteenpäin pyrin seuraavaan: Sunnittele – kirjoita ylös – tee – vaikutu tuloksista tai yritä uudestaan. Sitä tarkoittaa minun DBD. Ihan aina ei (ehkä) ole mahdollista kirjoittaa suunnitelmia ja toteutuksia ylös ennen tekemistä.  Ja joskus on hyvä työskennellä flown mukana. Mutta tavoitteena on selvät ohjeet tai muistiinpanot edes kaikesta lopputuloksen kannalta oleellisesta tai toimivan tuotteen toiminnasta. Ehkä sitten pääsee käyttämään ensimmäistä fraasia alkuperäisessä tarkoituksessa.

Suuri vaikuttuneisuuden huudahdus: Wow!

Pahimmassa tapauksessa dokumentoinnin puuttuminen aiheuttaa moninkertaisen työn siihen vaivaan verrattuna, että asiat voi käydä tarkistamassa jostain. Datamuokkauksien tekeminen uudelle dataversiolle ajamalla siistit koodit läpi mahdollistaa useamman päivän työn tekemisen muutamassa minuutissa.

Mielelläni kuulisin lukijoiden kokemuksia toimivasta tai ei niin toimivasta dokumentoinnista. Tai jäikö jotain oleellista puuttumaan?

Tästä on hyvä siirtyä kahden viikon lomalle. Toivottavasti kaikki tieto on saatu välitettyä työkavereiden ulottuville ja löydettäväksi eivätkä päivät kaadu piilotteleviin dokumentaatioihin. Tai siihen minulle ihan itsestään selvään asiaan. Bye!


4.10.2017 / Juha Kostamo

Monessa organisaatiossa ollaan tunnistettu se tosiasia, että ilman datan parempaa käyttöastetta ja koneoppimisen/tekoälyn tuomien mahdollisuuksien hyödyntämistä ollaan kusessa. Tehoja pitää saada lisää irti, pitää tunnistaa uusia myynnin mahdollisuuksia rikastamalla asiakasdataa jne. Kilpailijat painavat vasemmalta ohi ja uusia innovatiivisia, dataa hyödyntäviä toimijoita, on tulossa samalle ruokakupille. Ja useilla toimialoilla tuo ruokakuppi ei ole kasvamaan päin.

Yllä mainitun tilannetietoisuuden saavuttaminen on vaatinut muutamassa tai useassa alan seminaarissa käyntiä ja altistumista erilaisten AI- tai AI- wanna be- yritysten markkinointiviestinnälle. Tähän kun vielä lisätään kaikkien liiketoimintaongelmien ratkaisujen äiti eli digitalisointi (tai kavereiden kesken digitointi), niin voidaankin yhteen ääneen huudahtaa (bullshit) BINGO!

Kaikkia ratkaisun avaimia olisi runsaasti saatavilla, mutta missä on lukko?

Louhian kokemuksen mukaan yritykset voidaan tällä hetkellä jakaa kolmeen eri kategoriaan niiden tilanteen mukaan suhteessa edistyneeseen analytiikkaan ja koneoppimiseen:

”Tarttis tehrä jotain”

”We have seen the light”

”Data is the new oil, wtf?”

Suomessa on paljon “Tarttis tehrä jotain”- yrityksiä , melkein yhtä paljon kuin järviä. Ollaan tiedostettu tarve lähteä tutkimaan paremman datan hyödyntämisen tuomia mahdollisuuksia. Omat kyvykkyydet tiekartan laatimiseen ovat vähäiset, mutta oma liiketoiminta tunnetaan kyllä yksityiskohtaisesti. Ja ehkä se datakin. Tarvitaan joku, joka ottaa kädestä kiinni, katsoo silmiin ja kertoo mahdollisuuksista.

”We have seen the light”- organisaatiot ovat jo askeleen edellä. Ollaan tunnistettu selkeä kohde tekoälyn hyödyntämiselle ja business casekin on jo haarukoitu. Asiakaspoistuman pienentäminen, ostohinnan optimointi, lisämyynti, laitteen vikaantumisen ennakointi, tarjonnan ja kysynnän tasapainottaminen…täytyisi vaan kirkastaa tarve, kuvata käytettävissä oleva data ja lähteä vaiheittain matkaan. Ei vaan ole kaikkea tarvittavaa osaamista in-house.

Kolmannen kategorian yrityksiä on harvemmassa, mutta niitäkin löytyy. Datan säilömisen kustannuksen merkittävä lasku on mahdollistanut tislaamoyrittäjän oppien soveltamisen dataan. Ikävä kyllä varastoidulle datalle ei käy kuin rommille. Näissä yrityksissä on tiedostettu se, että datalla on arvoa, mutta ei tiedetä miten se ulosmitataan. Jonkun pitää esimerkkien kautta kertoa, mitä meidän datasta voisi taikoa.

Oikotietä onneen ei ole

Koska oppikirjojen mukaan blogeissa ei saisi varsinaisesti mainostaa, niin en sitten kerro, että meillä on noihin kolmeen eri tilanteeseen tuotteistettu työpajalähtöinen lähestymismalli ja Louhia AI Framework tekee loput.

Niille lukijoille, joille tekoälyn/koneoppimisen hyödyntäminen ei ole tuttua, haluan kertoa yhden faktan.

Perinteisessä raportoinnissa (BI) käyttäjä kertoo mitä haluaa datasta raportoida. Talousdatasta saa aina talousraportin aikaiseksi, kun tarpeeksi yrittää.

Koneoppimisessa data määrittelee sen, mitä siitä saa irti. Ilman dataa ei ole analyysiä.

Kakasta ei saa timanttia vaikka miten puristaa. Jos joku väittää muuta, niin hän puhuu paskaa.


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?


11.10.2015 / Ville Niemijärvi

Asiakastiedon rikastamisen tavoitteena on ymmärtää paremmin asiakkaan käyttäytymistä. Ymmärtää ylipäätään keitä asiakkaamme ovat. Mitä he haluavat? Mikä liikuttaa heitä?

Kun ymmärtää tämän, voi vaikuttaa asiakkaisiin. Ja sitä kautta oman yrityksen menestykseen.

Edellisessä osassa toin esille neljä keinoa rikastaa yrityksen asiakastietoa:

  1. Hyödynnä monipuolisesti jo olemassaolevia tietolähteitä
  2. Osta tai kerää 3. osapuolelta dataa (esim. Trafi, VRK, Tilastokeskus, Asiakastieto)
  3. Kerää suoraan asiakkailta itseltään
  4. Johda ja sovella pienemmästä joukosta kerättyä tarkempaa tietoa koko asiakasjoukolle

Pureudutaan tässä kirjoituksessa ensimmäiseen kohtaan ja avataan mitä tämä tarkoittaa käytännössä. Taustalla tässä on pari tosielämän analytiikkacasea, jossa lähtökohdat analytiikalle oli varsin kehnot mutta dataa rikastamalla pääsimme aika hyviin tuloksiin.

Näitä kokemuksia voi hyödyntää myös ihan perinteisessä raportoinnissa, useat esitetyt mittarit ovat sellaisia, jotka pitäisi olla jokaisen yrityksen seurannassa. Teki edistynyttä analytiikkaa tai ei.

1. Hyödynnä monipuolisesti jo olemassaolevia tietolähteitä

Ehdottomasti paras tietolähde asiakastiedon rikastamisessa on asiakkaan oma käyttäytyminen. Eli ostohistoria. Tämä tieto löytyy toimialasta riippuen laskutus- tai kassajärjestelmästä (POS, verkkokauppa), tilausjärjestelmästä (esim. mediatalojen lehtitilaukset) ja/tai ERP-järjestelmästä.

Ostohistoria on lahjomaton. Useimmat meistä ovat kysyttäessä luontoa rakastavia luomuilijoita, mutta kaupan kassalla tiskille eksyykin tehotuotettua pollea, potkaa ja bisseä.

Tiedot myös vanhenevat. Esimerkiksi kanta-asiakkaaksi liittyessä asiakkailta kysytyt tiedot eivät ole välttämättä ajantasalla vuoden päästä eikä asiakkaita ole helppo saada päivittämään niitä.

Ostokäyttäytyminen kertookin paljon helpommin ja totuudenmukaisemmin:

  • milloin asiakas ostaa (kellonaika, viikonpäivä, ostojen tiheys)
  • mitä hän ostaa (mitä tuoteryhmiä tai palveluita hän käyttää)
  • missä hän asioi (missä liikkeissä tai kanavissa)
  • kuinka kauan hän on ollut asiakas
  • kuinka suurilla määrillä hän ostaa (keskiostos, montako tuotetta ostoskorissa...)

Ja näistä tiedoista voidaan päätellä se olennainen: miksi hän käyttäytyy näin.

Otetaan seuraavaksi käytännön esimerkki valottamaan asiaa.

1.1 Sata tietoa, joista kaksi käyttökelpoista.

Lähdimme tekemään analytiikkaprojektia asiakkaan kanssa, tarkoituksena segmentoida kuluttajia parempaa kohdennettua markkinointia varten.

Aluksi kaikki näytti hyvältä, asiakasdataa oli paljon. CRM:stä löytyi asiakkaista lähes toista sataa muuttujaa. Asiakkaiden itse syöttämiä tietoja.

Hyvin nopea datan esianalyysi paljasti kuitenkin, että suurin osa oli roskaa. Datan täyttöaste oli useimmissa tiedoissa 0-20% luokkaa. Täysin käyttökelvotonta analytiikan kannalta.

Data oli myös virheellistä. Asiakkaat olivat saaneet käyttää pitkälti vapaita tekstikenttiä joten Helsingin kaupungista löytyi jo edellisessä kirjoituksessa mainitsemani 30 eri kirjoitustapaa. Osoitetiedot olivatkin enimmäkseen turhia.

Asiakastiedot lähtötilanne

Ainoastaan nimi ja postinumero olivat valideja.

Kuva ohessa näyttää tilanteen CRM:n asiakastaulussa. Vihreät laatikot kuvaavat eheää dataa, punaiset virheellistä.

Harmaat kuvaa sitä, että dataa ei ollut saatavilla eli asiakkaat eivät olleet syöttäneet tietoja. Analytiikassa, oli kyseessä segmentointi tai luokitteluongelma kuten poistuma-/tai lisämyyntimallinnus, ei datalla tee juuri mitään jos täyttöaste on alle 70-80%.

Eli lopputulemana päädyimme ottamaan kovalla työllä rakennetusta CRM:stä kaksi tietoa: asiakkaan nimen ja postinumeron.

Näiden pohjalta lähdimme rakentamaan uutta asiakastietämystä.

Asiakastiedot lähtötilanne 2

 

1.2 RFM-analyysi ja vähän muuta

Seuraava steppi, joka on itselle vakiintunut tapa, on tehdä hieman sovellettuna nopea RFM-pisteytys. Tämä tarkoittaa kolmen tunnusluvun laskemista asiakkaille

  • Recency - Milloin viimeksi asiakas on ostanut?
  • Frequency - Kuinka usein asiakkaat ostavat (asiointitiheys)?
  • Monetary Value - Mikä on asiakkaan kokonaismyynti?

Kukin kolmesta mittarista voidaan pisteyttää esimerkiksi asteikolla 1-5 (tai voidaan painottaa jotakin osa-aluetta enemmän). Näin täydet pisteet parhaimmilla asiakkailla olisi 15 ja huonoimmat saisi 3.

Asiakkaan kokonaismyynnin (monetary value) aikojen alusta laskettuna on hieman huono mittari koska se väheksyy uusia asiakkaita. Usein otan tämän rinnalle tai tilalle asiakkaan keskimääräisen kuukausilaskutuksen. Tällöin uusi iso asiakas saa hyvät pisteet Monetary value -kohdassa.

Perinteisen RFM-mittariston lisäksi lasken aina myös seuraavat tunnusluvut:

  • keskiostos
  • asiakkuuden kesto
  • montako tuotetta ostoskorissa keskimäärin

Riippuen käyttötarkoituksesta, voidaan laskea helposti myös:

  • milloin asiakas ostaa (kellonaika, viikonpäivä, vuodenaika)
  • missä kanavassa (verkko, kivijalka, muu)

Pisteytys ei ole itseisarvo enkä juuri koskaan puhu RFM-analyysistä. Nämä nyt vain sattuvat olemaan hyviä mittareita, joita yritysten tulisi seurata ja nämä yhdistettynä muihin asiakastietoihin, voidaan päätellä paljon asiakkaasta (esim. vain kerran viikossa ruokakaupassa käyvät ja isoja keskiostoksia tekevät asiakkaat ovat useimmiten isoja perheitä ja kenties haja-asutusalueelta. Kauppaan lähdetään harvoin ja silloin sinne mennään tositarkoituksella.)

Kuva alla näyttää mitä tietoja saimme aikaan kun yhdistimme asiakkaan perustiedot (CRM:stä) ja kassatapahtumia eli asiakkaan todellisen ostokäyttäytymisen.

Suosittelen laskemaan nämä tunnusluvut omaan tietovarastoon tai raportointisovellukseen, vaikka syvempää analytiikkaa ei olisi tarkoitus tehdäkään. Nämä tunnusluvut saadaan esimerkiksi vähittäiskaupan osalta suoraan sieltä kuittirivitason tiedoista tai laskuriveiltä joten kyse on yhdestä tietokannan taulusta ja ehkä 1/2h työstä.

Asiakastiedon rikastaminen RFM Analyysi

 

1.3 Tuotetiedot, maantieteellinen sijainti

Se, mitä tuotteita asiakas ostaa, voi olla ensiarvoisen tärkeää. Etenkin jos haluat tehdä kohdennettua markkinointia tai lisämyyntiä ja haluat, että viestisi osuu maaliin.

Seuraavaksi otimmekin mukaan yrityksen tuotehierarkian ja liitimme sen ostohistoriaan. Täältä pystyimme päättelemään mitä tuoteryhmiä tai palveluita asiakas todella käyttää.

Jos kyseessä olisi urheiluvälinekauppa, näkisimme heti mitä lajia asiakas todennäköisesti harrastaa. Tai jos kyseessä on kuntosaliketju, näkisimme onko hän enemmän yksinäinen kuntosalipuurtaja vai tykkääkö käydä ryhmätunneilla. Ruokakaupan osalta näemme suosiiko asiakas luomua, kotimaisia tuotteita, kalliimpia ja laadukkaampia brändejä vai onko hän tarkan markan kuluttaja?

Tuotetasolla ostosten perusteella asiakastiedon rikastaminen vaatii päätöksiä: kuinka paljon asiakkaan pitää ostaa tuotetta X, ennen kuin uskallamme luokitella hänet tuotteen X kuluttajaksi? Tässä vaiheessa tarvitaan sitä kauppiaan tarkkaa nenään ja kokemusta asiakkaista.

Tuotetietojen ohella olennainen tieto on maantieteellinen sijainti. Asiakkaan kaupunki on OK mutta omien kokemusten mukaan ei sisällä kovin paljoa ns. selitysvoimaa. Parempi tieto voi olla esim. etäisyys yrityksen toimipisteestä tai jaottelu maaseutu vs. kaupunki. Se, asuuko kuluttaja Kouvolassa vai Kotkassa, ei ole juuri merkityksellistä mutta se asuuko hän keskellä metsää vai keskustassa voi olla todella merkityksellistä.

Kuva alla näyttää mitä tietoja meillä on kasassa kun haemme ostohistoriasta mitä tuotteita asiakas on ostanut. Tässä esimerkissä haluamme vain tiedon, kuluttaako asiakas tiettyä meille strategisesti tärkeää tuoteryhmää vai ei.

Asiakastiedon rikastaminen tuotetiedoilla

1.4 Markkinointiaktiviteetit, asiakaspalvelu ja muut

Jos lopullisena tavoitteena on tehdä parempaa kohdennettua markkinointia, kannattaa asiakastietoa rikastaa markkinointiaktiviteeteillä. Suoramarkkinakirjeet, niin printit, emailit ja sms-viestit kuin myös puhelinsoitot ja f2f kontaktit ovat tällaisia.

Näiden perusteella päättelimme, reagoiko asiakas markkinointiviestiin ja millaiseen viestiin. Jos asiakas sai torstaina emailissa mainoskirjeen ja hän ei ollut ostanut sunnuntaihin mennessä, voidaan olettaa, että mainos ei osunut kohteeseen.

Jälleen kerran vaaditaan päätöksiä: miten päätellään, että toimiiko markkinointiviesti? Kuinka monta kertaa asiakkaan pitää olla ostamatta tai ostaa viestin saatua, että voimme sanoa hänen reagoivan siihen positiivisesti tai negatiivisesti? Mikä saa olla viive?

Päivittäistavarakaupassa olettaisin, että lehtimainoksen nähtyä asiakas ostaa samana tai seuraavana päivänä.

Markkinointiponnistelujen lisäksi luonnollisesti asiakaspalvelu ja palvelun laatu ylipäätään kiinnostaa. Esimerkiksi:

  • Kuinka monta kertaa asiakas on ottanut yhteyttä aspaan?
  • Kuinka monta reklamaatioita asiakas on tehnyt?
  • Kuinka monta tuotepalautusta asiakas on tehnyt?
  • Onko asiakkaan palvelussa ollut katkoja (esim. teleoperaattorit)?

Tänä päivänä on myös trendikästä puhua NPS:stä eli Net-promoter-score:sta. Kyseessä on asiakastyytyväisyyttä kuvaava mittari, yksi lukuarvo, joka kertoo: Kuinka todennäköisesti asiakas suosittelisi yrityksen palvelua muille?

Olen kuullut palvovia kommentteja tästä maagisesta mittarista. Kuulemma juuri mitään muuta ei yritys tarvitsekaan.

Ja ei siinä mitään, kyseessä on varmasti hyvä mittari ja otetaan se analyysiin mukaan. Itse näen sen yhdeksi pieneksi osaksi koko asiakastietämystä.

Alla kuvassa näkyy kooste tiedoista mitä olemme saaneet aikaan yhdistämällä CRM-dataa, laskutusdataa eli ostohistoriaa ja tuotetietoja sekä markkinoinnin aktiviteetteja.

Asiakastiedon rikastaminen markkinoinnin tiedoilla

Olemme tulleet valtavan harppauksen eteenpäin mutta varsin pienellä työllä. Asiakastietämys on rikastunut 2 sarakkeesta (nimi + postinumero) useisiin kymmeniin, laadukkaisiin ja todenmukaisiin tietoihin asiakkaista.

Jo tällaisenaan voidaan puhua todella rikkaasta asiakastietämyksestä, jonka perusteella asiakkuuksien johtaminen ja esimerkiksi kampanjoiden älykkäämpi suunnittelu on mahdollista.

Mutta todellisuudessa olemma vasta aluissa. Tässä käytiin alussa esitetyistä neljästä kohdasta vasta ensimmäinen. Paras osa on vielä tulematta. Niistä lisää seuraavalla kerralla, pysy kuulolla.

 

 


23.04.2015 / Jani Liimatta

Viime vuosina on itselläni on ollut mahdollisuus nähdä melkoinen nivaska muiden yritysten ja kehittäjien toteuttamia tietovarastoja, ETL:stä tietokantoihin. Toteutusten yleinen taso on ollut hyvin kirjavaa, samoin kuin asiakastyytyväisyyskin näihin projekteihin. Yksi suurimmista riskeistä on siinä miten kovan osaajan toimittaja pöydän toiselle puolelle tällää määrittely- ja toteutusvaiheissa.

Tietovaraston tekeminen ei ole mitään rakettitiedettä. Onnistunut projekti vaatii tekijältä siltikin harvinaisen laajaa osaamista. Tarvitaan mm

  • Asiakkaan prosessien ja liiketoiminnan laajaa ymmärrystä
  • Osaamista lähdejärjestelmistä, niiden toiminnoista ja tietokantarakenteista
  • Mallinnusosaamista tietovaraston osalta - jotta se palvelee mahdollisimman hyvin raportointi yms. tarpeita.
  • Tietokantojen mallinnus niiltä osin mitä se vaikuttaa suorituskykyyn ja latausnopeuksiin
  • ETL-välineen teknistä osaamista ja ymmärrystä
  • Vahvaa tietokantaosaamista suorituskyvyn ja teknisen toteutuksen osalta

Kolmeen ensimmäiseen kohtaan eivät auta tekniset työvälineet - tai koulutuskaan välttämättä. Näissä osaaminen tulee aika pitkälti kokemuksen kautta. Auttaa paljon jos tekijä on tehnyt elämässään jotain muutakin kuin kirjoittanut koodia. Kannattaa perehtyä tekijän referensseihin huolella.

tx2014Kokemusteni mukaan tekijöillä on suuria puutteita myös teknisessä osaamisessa. Nämä riskit ovat osittain taklattavissa teknisillä apuvälineillä. TimeXtender automatisoi tekniset asiat ja suorittaa sen aina parhaiden käytäntöjen mukaisesti. Kehittäjän ei välttämättä tarvitsekaan osata esimerkiksi

 

  • tehdä Update/Insert-logiikkaa niin että se on latausajoiltaan mahdollisimman nopea
  • Osata käyttää ETL-välineen oikeita palikoita oikeissa paikoissa. Sekin näyttäisi olevan monelle perustekijälle hämmästyttävän vaikeaa. On helppoa syyttää suorituskykyongelmista liian kevyttä rautaa tai työkalun ongelmia.
  • Osata indeksoida tietokantaa - ja nimetä indeksejä oikeaoppisesti. Luoda suurten tapahtumataulujen partitioinnit
  • Luoda mahdollisimman tehokkaasti toimivaa hitaasti muuttuva-dimensio-rakennetta
  • jne

Entä virhealttius? Jokainen tietovarastoprojekti on erilainen, jopa silloinkin kun kahdella asiakkaalla on sama lähdejärjestelmä ja asiakkaat toimivat samalla toimialalla. Raportointitarpeet ovat siltikin uniikkeja. Tämä johtaa siihen että myös tietovarastot ja niihin liittyvä logiikka ovat uniikkeja. Jos automaatio hoitaa logiikan rakennuksen, eikö silloin tule väkisinkin vähemmän virheitä ja testaustarvekin on pienempi?

Kolmas riski liittyy projektin sisältöön. Jos määrittely on massiivinen, logiikka kompleksinen ja työmäärät valtavia - voi käydä niin että projektin valmistuessa liiketoiminnan vaatimukset ovat jotain ihan muuta kuin mitä määrittelyissä todettiin. Tätä voi osin taklata agileilla menetelmillä. Vielä paremmin taklaus onnistuu jos avuksi otetaan jotain kättä pidempää jolla projektin läpimenoajat saadaan järkevälle tasolle.

Lue lisää TimeXtender-tuotteesta: www.timextender.com tai varaa oma demoaika 040-777 1142,

tai tule paikalle katsomaan demo TDWI-tapahtumaan 28.5.


9.04.2015 / Jani Liimatta

Tietovarastojen tekeminen on kokemassa suurta murrosta. Meidän lisäksi pari muutakin kilpailijaa kotimaassa on puuhastelemassa automatisointituotteiden parissa. Louhia on valinnut tuotteekseen yhden maailman markkinajohtajista, tanskalaisen TimeXtenderin. TimeXtender toimii täysin Microsoftin BI-stack:in päällä.

Miten tuo otsikossa mainittu 80% ajansäästö on mahdollista? Olen itse asiassa hyvin vakuuttunut tästä. Ajan säästö koostuu mm.

  • Automaattisesta tietokantaskeemojen ylläpidosta (kehittäjä ei enää lisää sarakkeita, indeksejä, näkymiä jne tietokantaan)
  • SQL:n määrän radikaalista vähenemisestä
  • Pienemmästä virhemäärästä (mm. partitioinnit, hitaasti muuttuvat dimensiot, inkrementaaliset lataukset kun hoituvat tavallaan itsestään, aina samalla tavalla)
  • Pienemmästä aivotyöstä (aikaa kuluu vähemmän ratkaisujen pohdiskelemiseen)
  • Tietovaraston ylläpito voidaan hoitaa asiakkaan pääkäyttäjän toimesta (vaikka nyt uuden sarakkeen tuonti lähdejärjestelmästä kuutioon/Qlik:iin/raporteille asti)

Toki - jos lähdejärjestelmä on kovin monimutkainen, tarvittavat laskennat ja datan muokkaukset hyvin vaativia, datan laatu huttua, ei tuo 80% toteudu. Kaikkea ei kuitenkaan voi automatisoida.

Tietovarastohankkeessa kuitenkaan ei pidä ajatella pelkän yksittäisen projektin kustannusta. On ajateltava myös koko hankkeen elinkaarta. Esimerkiksi - jos haluat valmiista tietovarastosta raportille uuden puuttuvan sarakkeen, tapahtuu perinteisessä ympäristössä seuraavia steppejä:

  1. Ota yhteyttä toimittajaan. Määrittele lähdejärjestelmän sarake ja kuvaa mihin se pitäisi raportilla/tietovarastossa saada
  2. Odota toimittajan resurssin toimenpiteitä. Tässä voi mennä aikaa 1-15 päivää
  3. Toimittaja tekee seuraavaa stagen osalta: muokkaa lähde-SQL:ää, lisää stage-kantaan sarakkeen, muuttaa ETL-latausta, suorittaa latauksen
  4. Toimittaja tekee seuraavat toimenpiteet tietovaraston osalta: muokkaa lähde-SQL:ää, lisää kantaan tai metamalliin sarakkeen, päivittää tietokannan, ajaa ETL:n
  5. Toimittaja päivittää dokumentaatiota, jos päivittää. Tässä vaiheessa ollaan vasta kehitysympäristössä.

Tässä menee yleensä kalenteriaikaa 3...15 päivää. Suuren toimittajan laskutus tästä ilosta voi olla 2 htp sisältäen muutokset testiympäristössä, testaukset, viennit tuotantoon. ISTU JA PALA! YHDEN SARAKKEEN LISÄÄMINEN RAPORTILLE!

TimeXtenderillä homma hoituu seuraavasti:

  1. Avaa työkalu
  2. Klikkaa lähdejärjestelmän saraketta, prosessoi (tietokantaan lisätään sarake automaattisesti, ETL päivitetään automaattisesti)
  3. Klikkaa stagella oleva data mukaan tietovarastotauluun. Prosessoi (tässäkin kaikki tapahtuu automaattisesti taustalla)
  4. Dokumentaatio on automaattisesti ajan tasalla

Asiakas pystyy pienellä opastuksella tekemään tämän itse. Aikaa tähän kuluu latausten lisäksi ehkä 15 minuuttia. Toimittaja ei lähetä laskua. Näin tämän homman pitääkin mennä. Pysy kuulolla, tästä aiheesta kirjoittelemme lähiaikoina lisää.

Tule katsomaan miten homma tehdään 28.4. PASS-tapahtumaan

Jos et ehtinyt PASS-tapahtumaan, varaa oma demoaika 040-777 1142 tai tule paikalle TDWI-tapahtumaan 28.5.

Lue lisää TimeXtenderistä: www.timextender.com


15.03.2015 / Ville Niemijärvi

Olen kirjoittanut aiheesta Qlik ja tietovarastointi aiemminkin (Qlik ilman tietovarastoa on kuin talo ilman perustuksia) mutta törmään jatkuvasti uusiin asiakkaisiin ja Qlik-toimittajiin, jotka sinnikkäästi uskovat, että on ihan fiksua rakentaa yrityksen tietoarkkitehtuuri puhtaasti Qlikin varaan.

Sanon suoraan: teette virheen. Mitä isompi putiikki ja mitä isommassa merkityksessä tieto on teillä, sitä isomman virheen teette. Kerron seuraavaksi miksi.

5 syytä miksi Qlik ilman tietovarastoa on typerä ratkaisu

  1. Qlik ei ole tarkoitettu organisaation tiedon tallennusalustaksi, tietovarasto on
  2. Qlik ei ole integraatioalusta, tietovarasto on
  3. Tiedon lukeminen ulos Qlikistä (esim. budjetointiin, analytiikkaan, ERP:iin, CRM:ään..) ei onnistu, tietovarastosta onnistuu
  4. Qlik ei ole ammattimainen tiedon muokkaussovellus (ns. etl-sovellus)
  5. Qlik ei ole vaihtoehto master data –ratkaisuksi, tietovarasto on

Qlik on markkinoiden johtavia tiedon visualisointi ja raportointivälineitä. Se on siinä todella hyvä. Olen käyttänyt sitä yli 6 vuotta ja se on omassa roolissaan mahtava. Mutta kaikessa muussa yllämainitussa, se on keskinkertainen tai todella huono.

Teetkö pistemäistä ratkaisua vai kestävää, monikäyttöistä tietoarkkitehtuuria?

Jos aiot tehdä pistemäisen raportointiratkaisun, esimerkiksi vain ja ainoastaan myynnin tarpeisiin, voit tehdä sen huoletta Qlikillä suoraan ERP:stä tai mistä tahansa järjestelmästä.

Tiedon harmonisointi ja hallinta
Mutta jos aiot rakentaa laajemmin yrityksen tietoarkkitehtuuria, haluat rakentaa yhden yhtenäisen paikan esimerkiksi masterdatalle tai määritellä yhteiset käsitteet (asiakas, tuotehierarkia, kate + muut tärkeät kpi-mittarit) ylitse järjestelmä- ja osastorajojen ja hallita näitä keskitetysti, ei tätä kannata missään nimessä rakentaa puhtaasti Qlikin varaan.

Integraatiot
Tietovarastoa ei pidä ajatella vain raportoinnin tietolähteenä (ja hidasteena). Tietovarasto on usein välttämätön ennakoivan analytiikan toteutuksissa. Se toimii myös yhä useammin integraatioalustana kun siellä laskettua business logiikkaa ja analyysien tuloksia halutaan viedä esimerkiksi CRM:ään, taloushallinnon järjestelmiin tai takaisin ERP:iin.

Modulaarisuus ja riskien hallinta
Tietovarasto tuo myös ratkaisuun modulaarisuutta ja on elintärkeä riskienhallinnan kannalta. Kun liiketoimintalogiikka, käsittelysäännöt ja historiadata on tietovarastossa (ja siihen liittyvässä etl-sovelluksessa), voidaan tarvittaessa raportointisovellus heittää hiiteen ja ottaa milloin vain uusi tilalle. Samoin ERP-järjestelmä voidaan vaihtaa ja vanhat tiedot jäävät talteen. Puhtaasti Qlikin varassa oleva yritys on suoraan sanoen lirissä siinä vaiheessa kun ERP menee vaihtoon tai halutaankin siirtää raportointi vaikka sitten Tableauhun.

Kestävä arkkitehtuuri vs. sillisalaatti

Alla on kaksi kuvaa. Ensimmäisessä on raportointiarkkitehtuuri rakennettu Qlikin varaan suoraan operatiivisista tietolähteistä.

Qlik arkkitehtuuri ilman tietovarastoa on kestämätön ratkaisu
Qlik-sovellusarkkitehtuuri ei ole kestävä ratkaisu tiedon tallennusalustaksi.

Jälkimmäisessä kuvassa alla on rakennettu kestävämpi ratkaisu tietovaraston pohjalle. Tämä mahdollistaa tiedon integroinnin 3. osapuolen tuotteisiin, raportoinnin vaihtoehtoisilla tuotteilla sekä ennakoivan analytiikan hyödyntämisen - kaikki yhdestä lähteestä.

Edelleen on mahdollisuus raportoida Qlikillä suoraan operatiivisista tietolähteistä.

Tietovarastoarkkitehtuuri ja Qlik
Tietovarastoarkkitehtuuri luo kestävän ja monikäyttöisen pohjan sekä raportoinnille, analytiikalle että integraatioille muihin järjestelmiin.

 

Milloin Qlik ilman tietovarastoa on järkevä ratkaisu

Jos vastaat alla oleviin kysymyksiin kaikkiin "kyllä", on ihan OK rakentaa raportointi puhtaasti Qlikin varaan:

  1. Sinulla on vain yksi lähdejärjestelmä, tietoa ei tarvitse harmonisoida
  2. Lähdejärjestelmäsi ei tule koskaan vaihtumaan
  3. Et tule koskaan luopumaan Qlikistä
  4. Tietoa ei tarvitse integroida muihin järjestelmiin ja siirtää pois Qlikistä, esim. CRM:ään, ERP:iin tai ennakoivan analytiikan tarpeisiin.
  5. Sinulla on varaa sijoittaa koko touhuun max. 20 000€ (jonka tietovarasto usein vähintäänkin vie).

Olen viimeisen vuoden aikana keskustellut noin kourallisen yrityksiä kanssa siitä, miten he ovat menneet solmuun puhtaasti Qlikiin perustuvan arkkitehtuurin kanssa. He halusivat edetä nopeasti ja saivatkin tuloksia aikaan. Sitten raportointi laajeni, vaatimukset kasvoivat ja nyt pelkkä Qlik-ratkaisu on kestämätön. Ja nyt he maksavat siitä kovan hinnan kun koko hoito rakennetaan uudestaan.

Tämä sama koskee tietenkin myös Tableauta ja Microsoftin PowerBI –tuotteita. Tai oikeastaan mitä tahansa business intelligence -tuotetta.

Voit mennä perse edellä puuhun, kyllä niinkin sinne pääsee. Mutta jos käytät hetken aikaa miettiäksesi miten sinne puuhun kannattaa kiivetä, pääset sinne nopeammin ja turvallisemmin.


11.02.2015 / Ville Niemijärvi

Tehtiin vuosia sitten isohko tietovarasto- ja raportointihanke. Kustannukset oli jotain 300 000€ tietämillä. Tämä siis konsulttityötä. Talon oma väki ahersi vuoden verran määrittely- ja testaussessioissa. Kokonaiskustannukset kenties jossain puolen miljoonan luokkaa. DW+BI lisenssit päälle. Pelkkä etl-softa jossain 100k€ hujakoilla tai vähän päälle.

Nyt suunnittelemme tuon tietovaraston uudelleenrakentamista. Tai paremminkin migraatiota. Tietovarasto on tehty vanhalla kunnon IBM Cognos Data Managerilla, joka on tullut tiensä päähän. Vaihdamme sen Microsoftin SSIS:ään. Koska asiakkaalla on jo SQL Server lisenssit, ei SSIS tuo lisäkustannuksia. Se on siis ilmainen kun taas Data managerin (tai DataStagen johon IBM on lisenssit vaihtanut) pelkät ylläpitomaksut olisi jotain +10k€ tienoilla per vuosi.

90% leikkaus työmääriin ja miten se tehdään

Työmääräarviomme tietovaraston migraatiolle on 30 htp.

Eli n. 300 htp rakennustyö saadaan siis kutistettua 30 htp, vaikka käytännössä migraatioon ei ole mitään apukeinoa ja ajoketjut tehdään uudestaan käsin*.

Miten työmäärät saadaan pudotettua 1/10 osaan vuosien takaisesta?

Tähän ei ole mitään poppakonsteja, pitää vain tuntea tietovarasto- ja raportointiympäristöjä. Sanottakoon, että kokemus on puolellamme. Tässä tekijät, jotka vaikuttavat työmäärien pienentämiseen:

1. Tiedon laatu on hyvä

Tiedon laatu on yksi isoimmista sudenkuopista missä tahansa raportointi- ja tietovarastohankkeessa. Varsinkin jos tietoa pitää yhdistellä useista lähteistä. Eräässä isossa DW-hankkeessa ennen kuin päästiin tekemään tietovarastoa, toteutettiin n. 100 000€ laatuprojekti. Keskittyen selvittämään mitä tietoa tarvitaan, missä se on, mitä puutteita siinä on ja miten nuo puutteet korjataan. Tehtiin toimintasuunnitelmat miten ERP:in prosesseja pitää korjata.

Kun puhutaan tietovaraston uudelleenrakentamisesta, on laatu yleensä kohdallaan. Laatuongelmat fiksattiin vuosia sitten. Lukuihin voi nyt luottaa. Ei tarvitse enää täsmäytellä myyntiraportin lukuja kirjanpidon virallisiin totuuksiin viikkokausia.

Säästämme tässä helposti 50 htp konsulttityötä ja varmaan 100 htp asiakkaan omaa työtä.

2. Tietolähteet ovat tiedossa, kyselyt ovat valmiina

Kun lähdemme tekemään tietovarastoa uudestaan, voimme hyödyntää jo olemassaolevia SQL-kyselyitä. Tiedämme mistä ERP:in, crm:n, fina-järjestelmän tauluista ja kentistä mikäkin tieto pitää hakea. Suurin osa työstä on copy-pastea.Meidän ei tarvitse miettiä myöskään miten toimittajat, asiakkaat, tuotteet mäpätään keskenään eri järjestelmien välillä, ei tarvitse luoda Excel-hässäköitä tai miettiä master data asioita (jollei DW:tä tehdä uudestaan nimenomaan tästä syystä).

Tämä tietolähteiden selvitystyö ja datan mäppäys ja harmonisointi on tiedon laadun kanssa suurin yksittäinen tehtävä missä tahansa tietovarasto-/raportointihankkeessa. Se vie joskus jopa 50% työajasta.

3. 80-20 sääntö eli viikatteelle on töitä

Jos puhutaan vuosia käytössä olleesta tietovarastosta tai raportointiympäristöstä, on sinne kertynyt valtava määrä huttua. Turhia raportteja, kuutioita, työpöytiä, tietokannan tauluja ja etl-ajoja.Useimmissa projekteissa 80-20 suhdeluku eli Pareton sääntö (80% asioista johtuu 20%:sta syistä) on aliarvio. Oma arvioni on 90-10. Esim. 10% kaikista BI-ympäristöön toteutetuista raporteista muodostaa 90% käytöstä. Toisin sanoen 90% raporteista voisi heittää roskiin.

Viikatteelle on siis töitä.

Tämä taas tarkoittaa, että kun tehdään migraatiota tai toteutetaan tietovarasto uudestaan, ei tarvitse toteuttaa usein edes puoliakaan siitä mitä tehtiin ensimmäisellä kerralla.

Näin asia on tässä käsillä olevassakin projektissa. Toki teemme siinä sivussa paljon lisää hyvää. Tuomme uusia tietolähteitä , rikastamme dataa, mallinnamme sitä paremmin ennakoivaa analytiikkaa silmälläpitäen.

Tämän kaiken voisi tiivistää yhteen sanaan: maturiteetti. Yrityksen tiedon hallinnan ja tiedolla johtamisen maturiteetti vaikuttaa erittäin suuresti siihen, miten helppoa ja nopeaa tietovarasto- ja raportointihankkeen läpivienti on. Ja paljonko se maksaa.

Vihdoinkin voidaan keskittyä olennaiseen: asiakastarpeisiin ja päätöksenteon tukeen

Ja se tärkein juttu. Kun uuden sukupolven tietovarasto saadaan pystyyn nopeasti ja pienellä kustannuksella, voidaan laittaa paukkuja oikeasti tuottavaan työhön. Voimme keskittää voimamme:

  • asiakastarpeiden kartoittamiseen
  • organisaation tietomallinnukseen
  • uudenlaiseen ketterään protoiluun ja uusien teknologisten innovaatioiden kokeilemiseen
  • tiedon visualisointiin ja analytiikkaan, jolla oikeasti tehdään tulosta eikä vain katsella peräpeilistä miten meni

Tällöin painopiste työmäärissä kääntyykin päälaelleen. Aiemmin leijonanosa työstä meni DW-prosessin alkupäähän, joka ei tuota vielä oikein mitään arvoa. Kun tietovarastoja tehdään uudestaan, painopiste on putken oikeassa päässä eli asiakkaassa. Tällöin tehdään korkeamman jalostusasteen työtä ja tuotetaan asiakkaalle arvoa.

Tietovarastojen työmäärät kun maturiteetti on matala.
Tietovarastojen työmäärät kun maturiteetti on matala.

 

Tietovarastojen työmäärät painottuvat asiakastarpeisiin ja arvon tuottamiseen kun maturiteetti on korkea.
Tietovarastojen työmäärät painottuvat asiakastarpeisiin ja arvon tuottamiseen kun maturiteetti on korkea.

 

* Kollega kirjoitti alkuviikosta tietovarastojen automatisoinnista. Tässä migraatio casessa meillä on itseasiassa mahdollisuus toteuttaa metamallinnuksen kautta automatisoitava tietovarasto, jolloin toteutustyö saadaan varmaankin pudotettua tuonne 20 htp tienoille. Raportoimme tuloksista joten pysy kuulolla.


3.02.2015 / Ville Niemijärvi

d_vitamiiniNappaan joka aamu viranomaisten suositusten mukaisesti D-vitamiinipillerin naamaan. Vitamiinit on purkissa ja purkki on kaapissa korin sisällä. Korissa on D-vitamiinin lisäksi sekaisin kaikki mahdolliset tropit vanhentuneista malarialääkkeistä aina valium... siis aspiriiniin ja rakkolaastareihin. 95% lääkkeistä on sellaisia mitä käytetään kerran vuodessa, jos silloinkaan. Yhden oleellisen purkin etsiminen sieltä käsikopelolla aiheuttaa joka aamua hammastenkiristyksen. Joskus talven pimeinä tunteina tulee napsittua D-vitamiinin sijaan vahingossa Lariamia tai kyypakkauksen hydrokortisonia.

Liiketoiminnan seurannassa ja raportoinnissa toistuu sama ilmiö. Joka aamu pitää saada se vakioannos informaatiota, mutta se on piilotettu samaan läjään kymmenien tuhansien muiden tiedon jyvästen kanssa - toisin sanoen jonnekin raportointiportaalin uumeniin satojen raporttien sekaan.

Eräällä asiakkaalla olennaiset, joka päivä tarpeelliset, myyntitiedot löytyvät yhdeltä raportilta joka on yli 10 GB kokoinen massiivinen möhkäle. Siinä on lähes kaikki tieto mitä ikinä tuosta yrityksestä irti saadaan.

Sieltä näkee halutessa 5 vuoden takaa jonkun mitäänsanomattoman maanantain klo 9.50 myynnin kun eräs mummo kävi Hyrynsalmen myymälässä ostamassa vessapaperia ja kissanruokaa.

Tämän kiinnostavan detailin rinnalla samalta raportilta löytyy se olennainen, oikeasti tärkeä tieto jota käytetään liiketoiminnan johtamisessa. Se tieto, joka pitää olla juuri nyt, ehkä joka aamu johdon käytettävissä. Ehkä jopa strategisesti tärkeä tieto. Heidän D-vitamiini.

Jotta he saavat päivittäisen D-vitamiini annoksen, heidän pitää ajaa työpaikalle. He avaavat tietokoneen, kirjautuvat sisään, avaavat raportointiportaalin, avaavat +10 GB raportin, odottavat pari minuuttia, valitsevat 20 raporttivälilehden joukosta oikean (odottavat), valitsevat oikean raporttielementin eli listan, graafin, taulukon (odottavat), tekevät valintalistoista suodatuksia, jotta saavat rajattua halutut tiedot esille (odottavat) ja lopulta tunnin tai parin jälkeen saavat haluamansa luvun eteensä. Ja jatkavat päivätyötänsä.

Entä jos... entä jos se D-vitamiinipurkki odottaisikin aina siinä keittiön pöydällä?

Kaikki tiedot eivät ole samanarvoisia. Kaikkia ei tarvitse laittaa samaan läjään. Tärkeimmät, eniten käytetyt mittarit, kpi:t ja tunnusluvut kannattaa toimittaa käyttäjille nopeasti, helposti ja massasta erillään. Vaikka suoraan heidän kännykkään.

Kun pienintäkin tiedon jyvää varten pitää avata massiivinen raportti, vaatii se myös paljon palvelin- ja muistiresursseja. Jokainen käyttäjä joka avaa esimerkiksi QlikView-raportin, haukkaa ison palan muistia. Kun 100 käyttäjää tekee tämän joka aamu, menee tehokkainkin softa tukkoon. Ja sitten hankitaan rautaa rajalle - usein turhaan. Sen sijaan, että tungetaan kaikki sisään siitä samasta oviaukosta samaan aikaan, voitaisiin miettiä pitääkö kaikkien todella päästä sen saman hunajapurkin ääreen? Toisille riittää vain pikainen vilkaisu, että purkki on riittävän täynnä.