21.02.2019 / Mika Laukkanen

Kun aloitin työurani 1990 luvun lopulla, niin tietovarastojen ja raportoinnin toteutus oli nykyistä paljon selkeämpää. Tietolähteet olivat pääasiassa relaatiokantoja tai melko yksinkertaisia tekstitiedostoja.  Eikä raportointikaan ollut kovin monimutkaista, koska silloisilla työvälineillä rajat tulivat nopeasti vastaan. Itsensä tunsi kuninkaaksi, jos sai graafin ja taulukon samalle sivulle.  Datan laatu oli toki samaa puppua kuin se nykyäänkin tuppaa olemaan.  Tuon ajan tyypillinen DW arkkitehtuuri oli seuraava.

Nykyiset arkkitehtuurikuvat ovat yksinkertaisimmillaan vastaavia, mutta yleensä kuitenkin monipuolisempia. Nyt on enemmän erilaisia tietolähteitä, samoin kuin datan tallennus- ja esityspään ratkaisuja.

Miksi sitten tietovarastoja alettiin alunperin rakentaa? Tässä muutamia syitä, jotka löytyivät vuonna 2001 tehdyiltä powerpointeilta.

  • Tietojen yhdistely ja harmonisointi eri tietojärjestelmistä
  • Yksi totuus päätöksentekoon
  • Käyttäjien ad-hoc kyselyt mahdollisia ja tietohallinnolle jää aikaa muuhun työhön
  • Tietovarasto historioi yrityksen datat, saadaan aikasarjoja ja analytiikkaa
  • Ei rasiteta operatiivisia järjestelmiä raportoinnilla

Nämä samat argumentit pätevät varsin hyvin vielä nykyäänkin. Mainittakoon että jossakin vaiheessa oli buumi, jonka mukaan kaikki yrityksen datat pitäisi saada keskitettyyn EDW ratkaisuun. Nyt ajatus tuntuu vähän hassulta, mutta ei tuntunut silloin, koska dataa syntyi suhteellisen pieniä määriä ja lähinnä omissa järjestelmissä.

Tietovarastot tehtiin raportoinnin tarpeisiin

Perinteisesti tietovarastoihin tuotava data on määräytynyt raportointitarpeiden mukaisesti. Esimerkiksi talousraportteja varten on tuotu talousdataa ja HR-raportteja varten HR-dataa. Lisäksi tietysti löytyy kombinaatioita, joissa raporteille on yhdistelty eri alueiden tietoja.

Nyt kun tiedetään, että koneoppimis- ja tekoälyratkaisut tarvitsevat dataa oppiakseen, niin eikös ole loistavaa, että vuosikymmeniä dataa on purkitettu tietovarastoihin?

Vastaus on toisinaan kyllä, mutta usein ei.

Kun dataa on kerätty vain raportointitarpeita ajatellen, niin on sattuman kauppaa, että sopiiko se koneoppimisen hyödyntämiseen. Selvennetään asiaa esimerkillä.

Tietovarastoon XYZ kerätään asiakasdataa, josta on tarkoituksena raportoida asiakaskohtaiset eurot tuotteittain, tuoteryhmittäin, asiakassegmenteittäin ja vaikkapa päivätasolla. Kerätään siis tietovarastoon laskutus-, tuote- ja asiakastiedot.

Tässä vaiheessa paikalle saapuu datatieteilijä, joka haluaisi tehdä asiakaspoistumamallin. Hetken dataa tutkailtuaan hän havaitsee, että tietovarastoon ei ole tuotu asiakkaan sopimukseen liittyviä tietoja. Ne olisivat todennäköisesti keskeinen elementti asiakaspoistumamallissa. Tai ehkä sopimustiedot ovat tietovarastossa, mutta niistä tunnetaan vain viimeisin tilanne – ei koko asiakkaan sopimushistoriaa, joka olisi jälleen olennaista asiakaspoistumamallin kannalta. Dataa siis voi olla, mutta siitä ei silti ole olennaista hyötyä.

Olen ollut mukana kymmenissä koneoppimisharjoituksissa, ja vain harvoissa kaikki tarvittava data on ollut saatavilla ns. perinteisestä tietovarastosta. Tyypillisimmät haasteet ovat olleet:

  • Tarvittavaa dataa ei ole ollenkaan tietovarastossa tai vain osittain
  • Dataa on tietovarastossa, mutta liian lyhyeltä ajalta (historiaa poistettu)
  • Tarvittavan datan historiointi on liian harvaa / epätäydellistä

 

Miten huomioida tekoäly tietovarastojen suunnittelussa?

Koska tietovarastojen suunnitteluun ja tekemiseen joka tapauksessa upotetaan valtavia summia rahaa, niin kannattaisi tehdä muutamia toimenpiteitä, jotka tukisivat ajatusta, että tietovaraston sisältö voisi olla syötteenä tekoälyratkaisuille jatkossa. Esimerkiksi.

  • Samalle datalle on hyvä olla useampi käyttötarkoitus (esim. asiakkaaseen liittyvä perinteinen raportointi, asiakaspoistumamallinnus ja asiakaskohtaiset myyntiennusteet).
  • Raportointitarpeiden lisäksi tarvitaan siis näkemystä, että millaisia tekoälyratkaisuja jatkossa halutaan tehdä. Jos ei ole dataa, niin ei tule ratkaisujakaan.
  • Datan historiointi kattavasti. Tämä vaikuttaa mm. tietovaraston mallinnustapaan. Näyttäisi siltä, että Data Vault ei ole hassumpi vaihtoehto vaikka pelkkään yksinkertaiseen BIDW projektiin se saattaakin olla järeähkö menetelmä.
  • Datan määrällä on merkitystä tekoälylle vaikkei raportoinnissa tarvittaisi kuin 3 viimeistä vuotta. Tietovarastoja ei siis kannata tyhjentää ”turhasta datasta”, vaan mieluummin siirtää vanhaa dataa muuhun ympäristöön. Jos vain vähääkään näkee, että sillä voisi olla käyttöä myöhemmin.
  • Kaikkea tekoälyratkaisuissa käytettävää dataa ei tarvitse tai kannata tuoda välttämättä tietovarastoon. Usein on viisaampaa pitää esim. IoT sensoridatat tai nettisivujen verkkolokit jossakin muussa ratkaisussa.

Näillä muutamalla opilla tietovarastoista tulee jo tekoälykelpoisempia. On kuitenkin hyvä huomata, että datan purkittaminen yhteen paikkaan ei itsessään synnytä tekoälyratkaisuja – siihen tarvitaan selkeät business caset. Data toimii sitten mahdollistajana.


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.05.2017 / Ville Niemijärvi

Olimme aikanaan tekemässä QlikView-toteutusta ja ihmettelimme miten karmean näköistä jälkeä edellinen konsulttitalo oli tehnyt.

Koodi oli hirveää spagettia ja ulkonäkö oli karmea. Miten niin hyvällä tuotteella, joka on tunnettu hyvästä visualisoinnista, voi tehdä tällaista jälkeä?

Paljastuikin, että kyse ei ollut konsulttien taidoista vaan siitä, että asiakas oli halunnut säästää ja investoida vain muutaman päivän kerralla.

Välillä yritys teki kehitystä omin voimin ja sitten taas konsultti paikalle pariksi päiväksi.

Toisaalta arkkitehtuurisuunnitteluun ja tietomallinnukseen ei panostettu laisinkaan. Lähdettiin vain tekemään.

Ei paljoa mietitty miten ja missä dataa summataan. Mikä lataus hoitaa keskitetysti tuotetiedot ja tallentuuko johonkin tuote- tai asiakasmaster.

Yhtenäisestä käyttöliittymäsuunnittelusta (UI/UX) puhumattakaan.

Tehtiin siis tilkkutäkkiä ja kokonaisuutta ei ehditty tai pystytty hahmottamaan. Vuosien varralle toteutus paisui ja paisui. Lopulta oli kasassa 20GB mötkylä, jonka suorituskyky oli heikko ja jota ei voitu laajentaa. Ja se näytti aivan karmealta.

Oltiin solmussa.

Vaikka et käytä tietovarastoa, älä laista arkkitehtuurisuunnittelusta ja tietomallinnuksesta.

Vaikka lähtisitkin nopeasti liikkeelle, älä unohda arkkitehtuurisuunnittelua ja tietomallinnusta.

Vaatimusmäärittelyn ohella nämä ovat tärkeimmät vaiheet business intelligence -hankkeissa.

Tämä pätee myös silloin kun et käytä tietokantaratkaisua pohjalla tiedon tallentamiseen.

Myös Qlik, Tableau tai PowerBI toteutus vaatii sen arkkitehtuurisuunnittelun.

Niihin ei tarvitse käyttää aikaa viikkotolkulla. Päivässäkin saat aikaan valtavasti ja saatat säästää ehkä kymmeniä tai satojatuhansia tai ainakin annat BI-ympäristöllesi pari vuotta lisäaikaa kun spagettikoodihirviöitä ei tarvitse rakentaa uudestaan vuoden päästä.

Tässä oma esimerkki yhdestä isohkosta tietovarastohankkeesta.

  • piirsin loogisen tietoarkkitehtuurin tunnissa powerpointiin. Karkea esimerkki löytyy edellisestä blogikirjoituksesta.
  • heitin sen asiakasorganisaation experttien kommentoitavaksi
  • muutamat asiat olivat vaihtoehtoisia, emme osanneet päättää (pilvi vs. on-premise vs. hybridi, datan aggregointi: miten ja missä, MPP vs. normirelaatio)
  • näitä päätöksiä varten tilasimme ulkopuolisen asiantuntijan, pidimme 2 kpl noin 3h työpajoja
  • vedimme konsulttien, meidän ja asiakasorganisaation suositukset yhteen ja teimme päätökset arkkitehtuurista

Kalenteriaikaa saattoi kulua ehkä pari viikkoa mutta työaikaa ehkä vain pari päivää. Ei kovin iso investointi kun lähdetään rakentamaan satojen tuhansien investointia.

Älä hinkkaa arkkitehtuuria liian kauan, tärkeintä on lähteä liikkeelle

On tapauksia missä yritys ei ole osannut lähteä liikkeelle laisinkaan.

On pohdittu kumpi on parempi:

  • MS SQL Server vai Oracle
  • Azure vai AWS
  • SSIS vai Informatica
  • normi-sql vai mpp vai datan virtualisointi

Vaihtoehtojen runsaus ja joskus myös konsulttien kykenemättömyys antaa suosituksia (ja olla jotain mieltä) on aiheuttanut sen, että ei ole tehty mitään tai että hanke on viivästynyt kuukausilla.

Vaikka tekisit “väärän” päätöksen, voi tuon päätöksen muuttaa. Ja hankkeen menestykselle on tärkeämpää saa loppukäyttäjän palautetta ja kokemusta uudesta arkkitehtuurista mahdollisimman nopeasti, kuin yrittää päättää täydellinen arkkitehtuuri kerralla.

Ahteri edellä puuhun, soitellen sotaan ja takki auki ei kannata edetä. Mutta älä yliajattele, älä ylisuunnittele. Sekään ei ole hyväksi.

Kyseessä on oppimisprosessi. Lähde siis liikkeelle pienesti ja opi matkan varrella. Tärkeintä on vain lähteä.

Kyllä nämä jutut vähän maksavatkin

Vedin kerran asiakkaalla toimittajien kilpailutusta. Erään toimittajan konsultin hieman ylimielinen kommentti hieman kummaksutti kun kysyimme häneltä perusteluja suurille työmääräarvioille:

“No kyllä nämä vaan maksavat”

Kaveri oli tietovarastoinnin huippuosaaja ja hänen leipälajina ei ollut myynti tai (potentiaalisten) asiakkaiden ärsyttäviin kysymyksiin vastaaminen.

Mutta hän oli oikeassa tuossa tylyssä vastauksessa.

Kyllä näissä vain menee aikaa ja se maksaa.

Ne ketkä tuntevat työtapaani tai kirjoituksiani, tietävät että halveksin ylisuuria työmääräarvioita ja asiakkaita kuppaavia konsultteja. Tykkään tehdä hommat nopeasti ja joskus oikoa mutkiakin.

Mutta olen itsekin joskus vääntänyt 20-30 päivää yhtä dashboardia. Se oli kallis työpöytä.

Mutta kannattaa huomata, että tuotetoimittaja haluaa myydä asiakkaalle lisenssin.

Hänen etuna on vähätellä työmäärän suuruutta. Jos työmäärä on kovin iso, voi se haitata lisenssimyyntiä. Siksi kannattaa mainostaa, että meidän softalla teet hienot raportit päivässä.

Konsultit näkevät usein pidemmälle. Se on heidän intresseissään. Ajatella pari vuotta eteenpäin. Ajatellaan laajennettavuutta, skaalautuvuuta, suorituskykyä, tulevia käyttötapauksia. Ajatellaan käytettävyyttä, käyttöönottoa, koulutusta.

Konsulttina tietenkin näen jälkimmäisen näkökannan paremmaksi.

Kuuntelit sitten konsulttia, tuotemyyjää tai lompakkoasi, suosittelen seuraavaa:

  • pysähdy edes edes päiväksi miettimään tietoarkkitehtuuriasi
  • älä mieti päätäsi puhki, loppukäyttäjän palaute ja oppi on niin tärkeämpää kuin saada täydellistä kerralla


11.11.2016 / Mika Aho

Tällä kertaa perjantaita keventävät dashboardit – nuo strategisen, taktisen ja operatiivisen tason rakkaat lempilapset – kutsuttakoon niitä yleisesti työpöydiksi tästä lähtien. Työpöydät, jotka keräävät lähestulkoon automaattisesti kaiken organisaatiossa ja sen ulkopuolella olevan datan ja summaavat sen nätisti muutaman avainmittarin sekä graafin taakse tuottaen ajankohtaisen tilannekuvan liiketoiminnastasi ja ennusteen tulevasta. Näin ainakin mainosesitteissä.

Usein sanotaan, että dashboardeilla on joko liian paljon tai liian vähän dataa. Avinash Kaushikin legendaarisen blogin innoittamana (ja sitä kohtalaisen surutta lainaamalla) lähdin tarkastelemaan, mitä muuta työpöydissä on mahdollisesti vialla.

Kaushiki puhuu avoimesti dataoksennuksesta, jossa työpöydät eivät enää olekaan syvällisesti prosessoituja liiketoimintatavoitteille merkityksellisiä data-analyysejä pitäen sisällään yhteenvedon suositelluista toimenpiteistä (HUH!), vaan niistä tulee dataoksennusta: numeroita ja kirjaimia vailla merkitystä. Dataa ilman kontekstia. Työpöytiä ilman näkemyksiä, toimenpidesuosituksia tai liiketoimintavaikutuksien arviointia.

Dataoksennus voi olla jotain tällaista:

digital-dashboards-google-search-1

Tällaista:

oksu2

Tai vaikka tällaista:

tokio-large

Eivätkä esimerkit ole edes pahimmasta päästä. Mietipä nyt näitä ylimmän johdon näkökulmasta? Ymmärtäväisetkö he näistä mitään? Ja kehtaisivatko kysyä, jos eivät ymmärrä?

Dataoksennus on erityisesti ylimmän johdon ongelma

Dataoksennus on erityisesti ylimmän johdon ongelma, joka istuu hyvin kaukana raakadatasta ja siitä tehdyistä analyyseistä. Ei ylin johto tiedä välttämättä yhtään, mitä työpöydällä näytettävälle moneen kertaan summatulle tilannekuvalle pitäisi tehdä. Tai mistä data tulee, miten sitä on analysoitu ja prosessoitu. Tällöin tuntuu väärältä jättää datan tulkinta ylimmälle johdolle ilman selityksiä datan alkuperästä, sen tuottamista näkemyksistä, toimenpidesuosituksista tai liiketoimintavaikutuksista.

Suinkaan en tarkoita, etteikö asioita pitäisi vetää yhteen. Parhaat visualisoinnithan ovat niitä, joissa äärimmäisen monimutkainen asia on saatu selitettyä hämmästyttävän yksinkertaisella tavalla. Tällaisesta on hyvä esimerkki tekstin loppupuolella ja se sisältää myös johdon peräänkuuluttamia näkemyksiä ja suosituksia. Yleisestikin voisi todeta, että mitä ylemmäksi organisaatiossa mennään, sitä selkeämpi työpöydän tulisi olla. Paras tapa on kuitenkin antaa yleisön päättää, millainen tarkkuustaso ja monimutkaisuus on kulloinkin tarpeen.

kyvykkyys

Toinen mielenkiintoinen asia yllä olevassa kuvassa on epäsymmetria analytiikkakyvykkyydessä eri ääripäiden välillä. Analyytikoilla on käsissään data ja ymmärrys organisaation suorituskykyyn liittyvistä syy-seuraussuhdetekijöistä. CXO:illa puolestaan on valta tehdä päätöksiä ja herätellä organisaatiolta talviuniltaan tekemään jotain toimenpiteitäkin. Mites nämä sitten kohtaavat?

No, sen sijaan, että laskettaisiin tai arvioitaisiin suositeltujen toimenpiteiden vaikutusta (tai ylipäänsä annettaisiin tällaisia), tarjoillaan ylimmälle johdolle vain valtava määrä dataa ilman mitään sen enempää järkeä. Kaiken lisäksi tämä pitää saada mahtumaan jostain kumman syystä yhdelle ruudulle – siinä sitten silmät ristissä tihrustetaan kirjainkoolla 6 olevia numeroita ja ihmetellään kymmenen graafin ja taulukon kautta, miten se maailma makaa.

Välistä puuttuu joku, kuka osaa tulkita datan. Analyytikoista saattaa löytyä poikkeuksia, mutta ei välttämättä uskallusta. Ylin johto voisi osatakin, muttei dataoksennukseltaan pysty.

Johto kaipaa auki selitettyjä tuloksia, ehdotuksia ja analyysejä pelkkien käppyröiden sijasta

Ei työpöytien ensisijainen tehtävä pitäisi olla informointi ja passiivisiin hälytyksiin reagoimien. Niiden tulisi herättää aktiivista ajattelua ja viedä toimintaa eteenpäin. Jossain välissä ne kuitenkin lakkaavat tarjoamasta merkityksellisiä data-analyyseja ja niistä tulee dataoksennusta. Ja varsinkaan strategisten työpöytien ei pitäisi olla dataoksennusta.

“Työpöytä on yhdellä silmäyksellä seurattava, yhdelle näytölle koostettu visuaalinen esitys kaikkein tärkeimmästä informaatiosta, jota tarvitaan yhden tai useamman tavoitteen saavuttamiseksi. (Stephen Few)”

Taktiset työpöydät

Alla oleva kuva on kovastikin arvostamani visualisointigurun Stephen Few:n esimerkkiaineistosta. Hän tykkää väreiltään hyvin pelkistetyistä ”minimalistisen musteen periaatteella” tehdyistä työpöydistä. Ajatuksena on korostaa vain niitä asioita, mitä on tarpeen ja jotka kaipaavat kulloinkin huomiota.

myynnin-dashboard

Esimerkkityöpöytä on oikeastaan ihan onnistunut yhteenveto myynnin suoriutumisista ja tavoitteista muutamalla trendillä höystettynä ottaen jopa yrityksen markkinaosuuden huomioon. Sen sijaan, että työpöydällä esitettäisiin esimerkiksi pelkästään myyntiä summattuna kaikkien alueiden yli, se myös hienosti segmentoi eri maanosia tai tuotteita. Tällöin pikasilmäyksellä voidaan tehdä pikaisia analyysejä ja vertailla segmenttejä keskenään. Tällaisiahan me olemme työpöydillämme tottuneetkin tekemään ja tarkastelemaan.

Työpöytä ei kuitenkaan sisällä yhtään näkemystä, toimenpidesuositusta tai liiketoimintavaikutuksen arviointia. Tässä tapauksessa asia on kuitenkin vielä ihan ok, sillä taktisempaa myynnin työpöytää käyttävät myyntijohtajat ja -päälliköt osaavat kyllä kaivaa (tai ainakin kysyä) ne itsekin datasta ja heillä on natsoja tehdä toimenpiteitä, joilla on myös liiketoimintavaikutuksia.

Minimalistisen musteen periaatteen mukaisesti voi sitten niin ikään pohtia, jääkö jotain merkittävää näkemättä, kun huomio kiinnittyy vain korostettuihin kohtiin. Esimerkiksi kate ei ole tavoitteessaan ja voidaan pohtia vaikka, syökö Chardonnay ehkäpä Merlotin mahdollisesti parempikatteisempaa markkinaa? Tai johtuuko huono kate siitä, että meillä liikaa uusia asiakkaita, joita ei pystytä palvelemaan?

Tässä oikeastaan yksi työpöytien haasteista onkin. Vaikka näemmekin Merlotin olevan tavoitteestaan jäljessä, työpöytä ei kerro meille miksi niin on tapahtunut tai mitä asialle pitäisi tehdä. Siitä puuttuvat Kaushikin peräänkuuluttamat näkemykset, toimenpidesuositukset ja liiketoimintavaikutukset. Näitä olemme hakeneet perinteisesti analyysityökaluilla konepellin alta työpöydän graafeista ja taulukoista porautumalla.

Strategiset työpöydät

Miltä strategisen työpöydän tulisi sitten näyttää? Hyvä kysymys. Lähdetään liikkeelle siitä, mitä niissä pitäisi olla.

Näkemykset eivät saisi olla itsesäänselvyyksien toistamista, esimerkiksi ”Merlotin myynti on pudonnut tammikuussa” – sen näkee jokainen itsekin työpöydältä. Ennemminkin pitäisi esittää syitä, mikä aiheutti myynnin putoamisen suuntaan tai toiseen – menikö esimerkiksi korkki kiinni tammikuussa. On tärkeä löytää juurisyy suorituskyvylle, joka on tunnistettu analyysin ja syy-seuraussuhteita kuvaavien tekijöiden kautta. Pelkkien summattujen graafien ja taulukoiden kautta tätä on usein hankala suoraan nähdä.

Alla oleva toisen visualisointigurun, Edward Tuften, blogista oleva esimerkki havainnollistaa hyvin graafin, siihen liitetyn taulukon ja tekstin avulla, miten Floridan eläkerahasto tarttui putoavaan puukkoon vuosituhannen alkupuolella . Otsikon alla olevassa ingressissä pohditaan myös syitä huonolle investoinnille.

00006x-20

Strategisille työpöydille pitäisi saada upotettua selityksiä, vastauksia ja ratkaisuja – vieläpä yllä olevan kaltaisella ymmärrettävällä tavalla. Ei se data niin usein päivity, ettei BI-väline tähän kykene. Jos ei kykene, niin vaihdetaan. Välillä strategiset työpöydät ovat melkein yhtä muuttumattomia kuin Sumerialaisten tekemät savitaulut 8000 eKr. Niihin koodattiin erilaisilla symboleilla määriä ja kohdetta kuvaavia tietoja eli ei maailma nyt kovin paljoa ole muuttunut.

Toimenpidesuositukset: Millaisia toimenpiteitä CXO:n pitäisi tehdä? Tämä on se aiemmin peräänkuulutettu mitä sitten, joka työpöydiltä usein puuttuu.

Esimerkiksi “Merlotin myynti on pudonnut tammikuussa, koska markkinointiosastomme mukaan suomalaisilla on korkki kiinni ja emme ole reagoineet tähän riittävän aikaisessa vaiheessa. Emme suosittele toimenpiteitä tämän suhteen, sillä historiatiedon perusteella odotamme myynnin tuplautuvan helmikuussa.

Liiketoimintavaikutukset:  Mikä on vaikutus liiketoimintaan, jos CXO hyväksyy suosituksen ja organisaatio tekee toimenpiteitä? Tämä on itse asiassa hyvin hankala asia ja vaikeasti laskettavissa. Mutta mikäli sen onnistuu tekemään, pystyy ylin johto arvioimaan vaikutuksia ja yhdistämään sekä peilaamaan siihen kokemuksiaan ja tietämystään liiketoimintastrategiasta.

Tee ennen viikonloppua happotesti

Ennen kuin lähdet viikonlopun viettoon, tarkista vielä, että:

  • Strategisilla työpöydillä on vähemmän numeroita, kuin sanoja
  • Työpöydiltäsi löytyy näkemyksiä, toimenpidesuosituksia ja liiketoimintavaikutusten arviointia
  • Datan tulkinta ei jää ylimmän johdon huoleksi
  • Datalla on jokin konteksti. Sisällytä työpöydille tavoitteita, benchmarkkeja ja ulkoista liiketoimintatietoa. Jos tavoitteet ja päämäärät puuttuvat, katselet dataoksennusta
  • Dataa vertaillaan eri aikaväleihin ja näet, ovatko asiat menossa parempaan tai huonompaan suuntaan

Jokaisen työpöydällä graafin ja taulukon kohdalla kysy itseltäsi “Mitä sitten?” Jos taustalla ei ole mitattavissa olevaa tai taloudellisesti tunnistettavissa olevaa syytä mitata sitä, otahan graafi tai taulukko pois.

P.S. Minulle taisi jäädä nyt nakki luoda esimerkki hyvästä strategisesta työpöydästä. Otan haasteen vastaan.

P.S.2. Jossain vaiheessa keinoäly tulee tekemään näkemykset, suositukset ja liiketoimintavaikutusten arvioinnit puolestamme. Mutta tästäkin lisää myöhemmin.


3.11.2016 / Jani Liimatta

Oikeaoppinen menetelmä budjettien laadintaanhan on aina alhaalta ylös. Eli laaditaan budjetit alimmalla mahdollisella tasolla, ja summataan sieltä ylöspäin yhteen. Näin yleensä saadaan aikaiseksi luotettavammat budjetit.

No, joskus voi tietysti miettiä, onko sinne alimmalle tasolle aina mielekästä tai edes mahdollistakaan pähkäillä oikeita lukuja? Joskus se vaan on mahdotonta. Ja olisi ehkä kuitenkin hyödyllistä nähdä ne budjettiluvut siellä atomitasolla. Esimerkiksi, jos tuote jakautuu satoihin eri variaatioihin. Askartelepa siitä sitten budjetti kaikille myyntialueille. Tai jos tarkin myyntialue on kuntataso? Budjetoinnin rivimäärä räjähtää käsiin. Perinteisesti tässä on käytetty staattisia kertoimia, tai viime vuoden myyntejä. Voisikohan tämän tehdä jotenkin tarkemmin ja automaattisemmin?

Eräällä asiakkaalla haasteena oli että budjetit luodaan tuotteittain ja kuukausittain. Nämä pitäisi sitten jakaa myyntialueille – eli esim. 10 tuotetta * 12 kk * 30 aluetta = 3600 riviä. Käsipelillä tekemätön paikka jo muutamallekin tuotteelle.

Esimerkki: kenkätehtaan budjetointihaasteet.

Kenkätehtaalla on laaja skaala kenkiä, joita myydään maantieteellisesti eri alueille. Kuukausimyyntien jakaumat poikkeavat toisistaan. Saappaita myydään pohjoisessa eri tahtiin kuin etelässä. Tarve on räjäyttää budjetoitu myynti alueille, joita Suomessa on kymmeniä. Lisäksi on erityyppisiä kauppoja; kenkäkauppoja, tavarataloja, nettimyyntiä jne.

Lisäksi eri tuotteet ovat eri vaiheissa elinkaartaan. Siksi mitään perinteisiä kertoimia budjetin jakamiseksi ei pystytä asettamaan. Täytyy keksiä jotain viisaampaa.

Budjetithan voisi ylätasolla syöttää vaikka SharePoint-listalle, josta ne luetaan jatkojalostusta varten eteenpäin. Eli syötetään budjetit tuotetasolle, myyntikanavittain. Lisäksi uusille tuotteille annetaan oma laskentamallinsa, jos historiamyynti puuttuu.

 

 

 

 

 

 

 

Data kirjoitetaan ja luetaan SSIS:n SharePoint-komponenteilla SQL Server-tietovarastoon.

Seuraavaksi valjastetaan maailmalla hypetetty R budjetointiprosessin tajunnanräjäyttäjäksi.

rlogo

  1. Tietovarastosta luetaan R:lle annettujen parametrien perusteella myyntihistoria alueittain taaksepäin useamman vuoden ajalta. Eli per yksi budjettirivi, meillä on käsissä useamman vuoden myyntihistoria kaikilla maantieteellisillä alueilla. Myyntihistorian muodostuksessa huomioidaan myös annetut parametrit: ‘Uusi kärkituote’-myyntihistoria muodostetaan uusien kärkituotteiden tuoteryhmästä. Kävelykengät-historia kaikista kävelykengistä alueittain.
  2. Integroidaan ennustavan analytiikan R osaksi ETL-prosessia. Hyödynnetään sinne itse rakennettuja älykkäitä aikasarjaennustemalleja. R-koodi valitsee parhaan algoritmin automaattisesti kullekin tuotteelle, sekä generoi myyntiennusteen hamaan tulevaisuuteen.

Eli: syöttämällä 1 budjettirivi per tuote, ennustemoottori jyvittää yhden budjettirivin 30:lle myyntialueelle automaattisesti. Näin saadusta myyntiennusteesta lasketaan vielä ennustettu suhteellinen myynnin jakauma. Jakaumalla kerrotaan käyttäjän antama budjetti.

Lopputuloksena on aluekohtainen raportti, jossa samalla saadaan näkyviin sekä toteutunut myynti, että myyntibudjetti. Budjetti jatkuu toteutuneen myynnin jatkeena hämmästyttävällä tarkkuudella.

Graafi

Saapas lyhyt on uusi tuote, jolla ei ole aikaisempaa myyntiä. Lenkkarilla sen sijaan on. Olisi voinut tehdä hieman monimutkaisemmat graafit tähän. Junamatka loppui kerrankin kesken.

Lopputuloksena saatiin generoitua automaattisesti hirmuinen nivaska budjettirivejä. Ja voidaan mainostaa turuilla ja toreilla nykyiseen liioittelevaan tyyliin, että käytettiin budjetoinnissa AI:tä, koneoppimista, machine learningia, ennustavaa analytiikkaa ja R:ää. Big Dataa ei nyt sentään. Mutta hetkonen… tähänhän olisi voinut lyödä sekaan vaikka pitkän aikavälin luotettavat sääennusteet. Tiedettäisiin etukäteen, kuinka moneen kumisaappaaseen täytyy tilata raaka-aineita. Ja somedatasta saataisiin selvitettyä onko kumisaappaista tulossa uusi muoti-ilmiö..

 

 

 

 


17.10.2016 / Jani Liimatta

Vaikka SSAS-kuutioiden käyttöoikeudet mahdollistavat melkein kaikki mahdolliset kombinaatiot, mitä vaativammallakin asiakkalla voi mieleen juolahtaa, on dimension tai attribuutin piilottaminen kokonaisuudessaan käyttöoikeuksilla mahdotonta.

Esimerkiksi kuutiossa on mahdollista:

  • Dimension detaljit voi piilottaa käyttäjäryhmältä
  • Mittarin voi arvot voi piilottaa käyttäjäryhmältä
  • Osan riveistä voi piilottaa oikeuksiin perustuen, käyttäjä voi esimerkiksi nähdä vain oman osastonsa luvut

Mutta, käyttäjiltä ei siis pysty piilottamaan esimerkiksi tietoa siitä, että joku muu saa dataa ulos tarkemmalla tasolla. Harvemminhan tämä on tarpeellista, mutta pari kertaa on tullut tällainenkin tarve eteen. Piilottamiseen on olemassa workaround, joka ei ainakaan itselläni tullut ihan heti mieleen. Sen voi nimittäin toteuttaa kuution Linked Object:eja käyttämällä.

Steb-by-step:

Skenaaario, jossa osa osastoista ei saa nähdä, että myyjätasoinen data on olemassa kuutiossa.

1.Luodaan minuutissa peruskuutio, jossa on ‘kaikki’ dimensiot käytössä. Käytetään tässä erimerkissä hmm… persoonallisesti mallinnettua, vanhaa ja tuttua Microsoftin AdventureWorks DW:tä pohjana.

peruskuutio
 

 

 

2. Luodaan tyhjä kuutio (Create Empty Cube) projektipäälliköille (ProjectSales). Projektipäälliköt eivät saa nähdä myyjäkohtaisia myyntejä.

uusikuutio

 

 

 

 

3. Avaa tämä uusi kuutio. Valitse oikalla napilla ‘New Linked Object’-wizard. Valitaan nykyisestä kuutiosta kaikki measuret. Näiden mukana pöllähtää mukana myös kaikki liittyvät dimensiot.

linkedobject

 

 

 

 

 

 

 

4. Nyt on siis käsissä uusi kuutio, joka sisältää vain linkit alkuperäiseen kuutioon. Poistetaan siitä Employee-dimensio

removeemployee

 

 

 

 

 

5. Seuraavaksi voidaan käyttöoikeuksilla säätää kuutioihin pääsy. Nyt on käsissä siis peruskuutio – sekä projektimyyntikuutio, josta ei edes näe, että myyjätasolle on mahdollista päästä.

excel

 

 

 

 

 

Harvemmin on oikeasti tarvetta piilottaa koko dimensio, mutta jos tulee tarvetta, linkatut objektit ovat ainut järkevä tapa toteutukseen. Toinen tapa on tehdä peruskuutiosta kopioita – mutta silloin haukataan levytilaa, kadotetaan kuutioiden prosessointiaikaa, sekä duplikoidaan logiikkaa. Linkattujen objektien ansioista kun peruskuutio on prosessoitu, on linkkikuutiokin ajan tasalla.

Toisaalta tässä on olemassa sellainen ‘hauska ominaisuus’, että muutokset eivät automaattisesti periydy eteenpäin. Eli jos muutat peruskuution rakennetta, on linkkikuutio käytännössä tehtävä uusiksi. Tai ainakin muutettu measure group poistettava ja lisättävä takaisin. Se ei onneksi ole kummoinenkaan tehtävä. Paitsi jos muut käyttöoikeusasetukset ovat monimutkaisia… periytymisongelman takia ei näitä linkattujen objektien kuutiossa ei oikein muuta logiikkaa kannata ollakaan.

https://msdn.microsoft.com/en-us/library/ms174899.aspx

Lisensoinnin kannalta linkatut objektit toimivat std-SQL Serverissä, jos kuutiot ovat saman SSAS-kannan sisällä. Toisen projektin/kannan kautta tarvitaan Enterprise-lisenssi.


7.10.2016 / Mika Aho

Jokusen BI- ja tietovarastointiprojektin läpi kahlanneena olen usein miettinyt, kuinka suureen määrään (liiketoiminta)dataa BI-veijareilla on mahdollisuus päästä, tulivatpa sitten talon sisältä tai konsultin roolissa ulkopuolelta.

Muutaman pääkäyttäjän oikeuksin ajetun valmiin raportin kautta löytyy usein koko organisaation taloudelliset tunnusluvut, budjetit ja ennusteet, myynti, ostot, tilauskanta, merkittävimmät asiakkaat ja projektista riippuen joskus palkkatietojakin. Ja paljon muuta.

Jos taitaa muutaman lauseen SQL:ää, simppelillä SELECT-lauseellakin saa kaivettua tietokannan uumenista vaikka mitä, varsinkin jos osaa filtteröidä tilejä WHERE-ehdolla. Yleensä tätäkään ei tarvitse tehdä, sillä tulos ja tase ovat jo valmiiksi rakennettuna summariveineen tietovaraston tilidimensioon.

Oikeastaan jo lähtökohtaisesti ajatus on huvittava: suuri määrä arkaluontoista dataa kerätään yhteen paikkaan, jossa toisilleen tuntemattomat ihmiset pääsevät siihen käsiksi. Ok, useimmiten dataa rajataan raportointipäässä vaikka liiketoimintayksikön tasolla, mutta edelleen BI-veijareilla on samat admin-natsat käytettävissä. Vaikka sensitiivisempää dataa, kuten palkkatietoja, rajattaisiin tietokantapäässä näkymien avulla, kyllä ne taustalla olevat taulut ovat edelleen löydettävissä – ainakin latausalueelta.

Mitäs sitten, kun asiakas ei olekaan tylsä teollisuusyritys, vaan julkishallinnon puolelta vaikkapa sairaanhoitopiiri, Poliisi tai verottaja? Toivottavasti potilastietojen kanssa työskentelevillä BI-veijareilla on tietoturva hanskassa ja salassapitosopimukset kunnossa.

Q3-osavuosikatsaukset

Pian saadaan taas seurata, mitenkäs se kesälomien jälkeinen aika pörssiyhtiöissämme menikään. Entäpä, jos BI-veijarille tulisikin kiusaus katsoa Arvopaperi-lehdestä analyytikoiden ennusteita ja verrata BI-, suunnittelu- ja konsolidointijärjestelmistä löytyviä toteumia sekä ennusteita näihin? Siinä voi sitten tulosjulkistuksen alla arpoa, lähteekö viikonlopun viettoon short-positiolla, lyökö rahaa tiskiin vai myykö vanhat osakkeet salkusta turskaamasta. Tässä tapauksessa kun suomalainen voittaa aina.

Mitäpä jos tulisi houkutus muuttaa tulosjulkistuksen alla numeroita parempaan tai huonompaan suuntaan? Tai muuten vain tehdä pientä kiusaa naapuriyksikön mulkvistille? Ei suotta sanota SQL:n olevan ilmaisuvoimainen kieli.

Vai onko riski kuitenkin talon sisällä?

Yksi ihan mielenkiintoinen elävä esimerkki oli eräästä konsernin hankintoihin liittyvästä raportointiprojektissa, jossa olin jo vuosia sitten mukana. Yrityksessä oli muutoin tietoturva hyvällä mallilla: VPN-putkia ei ollut eli työtä tehtiin asiakkaan tiloissa, henkkarit katsottiin aulan tiskillä, omia läppäreitä ei saanut käyttää, BI-palvelimilta ei päässyt ulkoverkkoon, tiloissa kuljettiin aina saattajan kanssa ja yksin ei saanut jäädä puuhailemaan. Vessassa sai sentään käydä rauhassa.

Rakennettiin hienot tietovarastot, kuutiot ja raportit. Testausvaiheessa aloin kuitenkin saada hankintajohtajalta työsähköpostiini suojaamattomana raportteja konsernin suurimmista toimittajista euromäärineen. Tuli heti turvallinen olo.

Pitäisikö asialle tehdä jotain?

Kyllä ja ei. Varsinkin kehittäjän näkökulmasta on hyvin hankalaa ja jopa raivostuttavaa, mikäli BI-työkalut eivät ole käytettävissä ja dataa saatavilla, kun kehitystyö on kuumimmillaan. Yleensä kun näissä hommissa painaa kiire päälle.

Toisaalta huhtikuussa hyväksytty EU:n tietosuoja-asetus (täällä kauniisti visualisoituna) ohjaa yrityksiä varmistamaan tietoturvansa riittävyyden ja varautumaan ongelmatilanteisiin. Ihan älytön hoppu ei ole, sillä Suomessa asetusta ryhdytään soveltamaan kahden vuoden siirtymäajan jälkeen eli aikaisintaan keväällä 2018. Kannattaa kuitenkin varautua ajoissa, sillä jopa 20 miljoonan euron sakko tietosuojasäännösten rikkomisesta rohkaisee kyllä laittamaan henkilötietojen käsittelyn kuntoon myös BI-projekteissa.

With Great Power Comes Great Responsibility. Louhia on hyvien puolella.


16.09.2016 / Ville Niemijärvi

Olen kilpailuttanut useita business intelligence -työvälinehankintoja. Usein asiakas haluaa hankkia samalla raportointi- ja analysointityövälineen lisäksi myös budjetointi- ja suunnittelusovelluksen.

Hankintojen keskittäminen on ymmärrettävää ja usein suosittelen tätä jos molemmat sovellukset on kuitenkin hankintalistalla.

Mutta onko tarpeen hankkia sovellukset samalta toimittajalta? Mitä hyötyjä ja haittoja tästä seuraa?

Käydään läpi muutamia kokemuksia ja oppeja vuosien varrelta.

 

Milloin keskittäminen kannattaa?

Kustannussäästö

Keskitetty hankinta, jossa kilpailutetaan samalla BI-työväline (raportointi, visualisointi, data discovery…) sekä budjetointi- ja suunnittelutyöväline, on usein edullisempi kuin jos tuotteet hankitaan erikseen.

Toimittajat joilta löytyy tuotepaletista molemmat komponentit, voivat niputtaa tuotteet samaan tarjoukseen ja tarjota paketin todella houkuttelevaan hintaan. Joskus toinen menee vähän niin kuin kaupan päälle.

Tällöin käy myös niin että ne BI-toimittajat, joilta ei löydy budjetointisovellusta tarjonnastaan, joutuvat ottamaan tarjoukseen mukaan jonkin 3. osapuolen budjetointisovelluksen. Koska budjetointi tulee toiselta toimittajalta, ei tähän hintaan usein voida vaikuttaa joten tinkivaraa ei jää.

Tämä tarkoittaa, että budjetointisovelluksen omaava toimittaja saa paremmat hintapisteet ja on vahvoilla kilpailutuksessa. Tätä voisi tulkita myös niin, että asiakas voisi halutessaan pelata tietyt pienemmät toimittajat kilpailutuksesta pois, ottamalla siihen mukaan molemmat komponentit.

Ajan- ja vaivansäästö

Kilpailuttaminen, varsinkaan julkishallinnon puolella, ei ole kenenkään mielipuuhaa. Yleensä yksityisellä puolella olen vetänyt RFP-prosessin läpi max. 2 kuukaudessa. Julkkaripuolella tämä venyy 3-6 kuukauteen.

Ihmisillä on muutakin tekemistä kuin miettiä hankintalain kiemuroita ja koota RFP-materiaaleja joten jos yhdellä kilpailutuksella voidaan hoitaa kaksi softaa niin miksikäs ei.

Miksi keskittäminen ei kannattaa?

Vuosien kokemus molempien (BI + budjetointi- ja suunnittelu) tuotteiden hankinnoista ja käyttöönotoista on kuitenkin opettanut, että yhteinen kilpailutus sisältää haasteita.

Tuotteet ovat itseasiassa aika kaukana toisistaan, vaikka tulisivat samalta toimittajalta

Toimittajat sanovat toista mutta todellisuudessa saman toimittajan raportointituote on aivan eri puusta veistetty kuin budjetointituote. Käytännössä monet budjetointituotteet ovat tulleet yritysoston mukana.

Esimerkiksi IBM Cognoksen budjetointituote on nimeltä TM1. Tämä ei ole kuitenkaan IBM:n kehittämä tuote vaan Cognos osti vuonna 2007 Applix:in, jonka mukana se sai TM1:n,

Toki sitä on tunkattu ja koodattu samaan sapluunaan mutta silti TM1 ja muu Cognoksen BI on kuin eri planeetalta. Kyselykieli datapoiminnoissa, käyttöliittymä, look ’n feel, teknologia konepellin alla… kaikki poikkeaa toisistaan.

Myyntimiesten puheissa tuote oli tietenkin heti ”täysin integroitu” muun Cognos BI tuoteperheen kanssa. Tämä oli tietenkin hölynpölyä. Me ketkä jouduimme taistelemaan TM1:n (tai sitä edeltävän Cognos Planningin tai sitä edeltävän Cognos Financen) kanssa ja integroimaan sitä Cognoksen BI-tuotteisiin tiedämme totuuden.

TM1 on käytännön työn kannalta yhtä lähellä Cognoksen BI palettia kuin Microsoft. Itseasiassa Microsoftin SSAS kuution saa toimimaan paremmin Cognoksen raportointituotteiden tietolähteenä kuin TM1:n. Testattu molemmat.

Vaikka kyse ei olisi yritysostolla hankitusta tuotteesta, saat silti hyvin vähän teknologista synenergiaa sillä, että tuote tulee samalta toimittajalta.

Jos budjetointidata tallentuu omaan tietokantaansa niin kuin usein tapahtuu, pystyy sitä lukemaan mikä tahansa BI-työväline.

Ja useimmiten budjetointisovelluksen datat viedään ensiksi tietovarastoon josta ne pyöräytetään raportointisoftaan. Tällöin varsinkaan ei ole mitään merkitystä miltä toimittajalta tuotteet ovat.

 

Blokkaat turhaan pois hyviä tuotteita

Tämä pätee etenkin julkisiin kilpailutuksiin. Suomen markkinoilta löytyy muutamia isoja IT-taloja, joilta löytyy sekä BI että budjetointituotteet. Näitä ovat mm. IBM Cognos, SAP ja Oracle.

Sitten on BI-toimittajia, joilta ei löydy budjetointisoftaa suoraan itseltään. Näitä on mm. Microsoft, Tableau, QlikView.

Nyt jos kilpailutat molemmat samalla ja hintaa sekä toiminnallisuutta arvioidaan kokonaisuutena, häviää jälkimmäinen porukka aika varmasti. Kuitenkin tiedon visualisoinnin ja ns. data discovery -kategoriassa juuri nämä kolme ovat markkinoiden parhaat. Ainakin Gartnerin mielestä.

Kilpailutuksissa Microsoft, Tableau, QlikView ja kumppanit joutuvat tarjoamaan jotain 3. osapuolen budjetointituotetta. Vallan hyviä vaihtoehtoja mutta kuten aiemmin sanoin, hinnan puolesta he eivät usein voi kilpailla isoja toimittajia vastaan koska he eivät usein voi vaikuttaa 3. osapuolen lisenssikustannukseen samalla tavalla.

Toisaalta myös monipuolisuudessa QlikViewn kylkeen usein tarjottavat budjetointituotteet (esim. Kliqplan) jäävät isojen toimijoiden vastaavista.

Tai sitten he häviävät suoraan jos kilpailutuksen vaatimukset asetetaan erityisen tiukaksi eikä sallita 3. osapuolen softia.

Tämä voi tietenkin olla tarkoituskin. Mene ja tiedä.

Suositus: keskitä mutta mahdollista erillinen hankinta

Itse kannatan, että tiettyyn tehtävään hankitaan aina paras tuote. Vaikka ne tulisi eri toimittajalta. Toisin sanoen tuotteen käytettävyys on avainasemassa, teknologisen yhdenmukaisuuden hieman kärsiessä (mutta oikeasti ei juurikaan kärsi koska kuten sanoin, saman toimittajankin tuotteet ovat yleensä eri maailmoista).

Suosittelenkin  siis seuraavaa BI- ja budjetointituotteita kilpailuttaessa:

  • keskitä hankinta niin säästät aikaa, rahaa ja vaivaa
  • keskittämällä saat mahdollisuuden puristaa isoilta toimittajilta hyvän nippuhinnan
  • mutta pidä ehdottomasti avoinna mahdollisuus hankkia tuotteet eri toimittajilta
  • tämä tarkoittaa oikein muodostettua RFP:tä. Pisteytys täytyy eriyttää.
  • Paras BI-tuote pitää pystyä voittamaan, ilman että sen huono/olematon budjetointiominaisuus vetää sitä alaspäin

 

Ensi kerralla aiheena: kannattaako BI ja data science -tuotteet kilpailuttaa samalla kertaa?


14.06.2016 / Ville Niemijärvi

Järjestämme tulevana perjantaina 17.6.2016 klo 8.30-10.00 yhdessä Keski-Suomen Kauppakamarin ja Powen Oy:n kanssa tiedolla johtamisen aamukahvit Jyväskylässä.

Powen kertoo yritysten arjen analytiikasta ja business intelligencestä, minä taas kerron kokemuksia ennakoivasta analytiikasta (machine learning, data science).

Tilaisuus on maksuton ja tarjolla on aamupala. Tervetuloa!

Ilmoittaudu mukaan tästä: http://www.kskauppakamari.fi/koulutus/hajota-hallitse-data