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?


7.06.2016 / Jani Liimatta

Otsikon kysymys on tällä hetkellä hyvin monen raportointityövälineestä päätöksiä tekevän huulilla. Kysymykseen ei ole yhtä suoraa vastausta. Perataanpa avuksi hieman auki tuotteen plussia ja miinuksia.

Plussia

+ Datan käsittelypuoli on vahva. Tämä osio on rakennettu paljon vakaammalle pohjalle kuin esim. Qlik:issä. Qlik:in heikkous ovat taustalle luotavat latausskriptit, jotka leviävät helposti käsiin. Monimutkaisemmissa ympäristöissä lopputuloksena on tutkimustenkin mukaan muutaman vuoden päästä spagettikoodia, jonka ylläpidettävyys on hyvin kyseenalaista. PowerBI:n vastaus tietomallin rakennukselle on DAX-kieli, jonka osaamista tietomallin luonti käytännössä siis vaatii. Laskennat tehdään tietomalliin, ei raportille (esim. YTD, Previous Year jne).

+ Taustalla on vahva yritys ja tuotekehityksen jatkuvuuteen pystynee luottamaan - eikä omistajavaihdoksia ole tulossa - toisin kuin Qlik:illä ja Tableau:lla tulee jatkossakin tapahtumaan

+ Nopea ja avoin tuotekehitys. Käyttäjien mielipiteitä otetaan todistetusti hyvin huomioon uusia ominaisuuksia priorisoitaessa. Uusia versioita tuotteesta putkahtelee tasaisesti kerran kuussa. https://ideas.powerbi.com/forums/265200-power-bi-ideas

+ Halpa hinta. Ei vaadi investointeja lisensseihin.

+ Avoimuus. Visualisointeja voi koodata itse lisää tai käyttää muiden tekemiä valmiita komponentteja https://app.powerbi.com/visuals/

+ Tietty yksinkertaisuus. Ensimmäisen PowerBI-raportin luonti tyhjästä on kilpailijoihin nähden hyvin nopeaa.

+ Natiivi tuki hyvin monelle eri tietolähteelle

Miinuksia

- Suurin miinus juontaa juurensa tuotteen historiasta. Alun perin minkään esityskerroksen komponentin takana ei ollut ensimmäistäkään propertyä. Eli mitään ominaisuuksia ei pystynyt säätämään. Propertyjä on tullut mukaan yksi kerrallaan. Eli suomeksi, graafien värejä, fontteja, skaaloja jne on päässyt säätämään yksitellen, sitä mukaa kun asetuksia on tuotu komponenttien taustalle.

- Samaa suurinta miinusta on edelleen se, ettei PowerBI:ssä ole olemassa Expressioneja. Expressioneilla pystytään säätämään kilpailevissa välineissä käytännössä kaikkea ruudulla näkyvää. Expressionien ja funktioiden puute esityskerroksessa rajoittaa raportintekijän mahdollisuuksia joskus ratkaisevan paljon. Alla muutama käyttötapausesimerkki expressioneista. Näitä esimerkkejä on lähes mahdotonta toteuttaa PowerBI:ssä:

  • Raportilla valittujen parametrien kirjoittaminen käyttäjälle on mahdotonta. Esimerkiksi otsikkoon haluttaisiin kirjoittaa 'Kuukausimyynti, Osasto: Puutarhatyökalut, Kausi: Q3/2015', ei onnistu. Tai jos haluat kirjoittaa vaikkapa ToolTips:iin jotain jossa tarvitaan logiikkaa (IF..ELSE..), eipä onnistu.
  • Juoksevan summan tai ehdollisen summauksen toteuttaminen raportilla. Aina ei vaan ole mahdollista, että raportointityökalu summaa automaattisesti yhteen kaikki mitä näytöllä näkyy
  • Ehdollisen hyperlinkin toteuttaminen. Toisaalta linkit esim. aliraportteihin puuttuvat itse asiassa kokonaan (no, onhan siellä nykyään Drill-toiminnallisuus, mutta ei aja samaa asiaa)
  • Ehdollisen parametrin toteuttaminen. Hyvin yleistä että parametriarvoja sisältävän komboboxin sisältöä täytyy muokata lennossa toisaalla tehtyjen valintojen, tai vaikka käyttäjän osaston perusteella

- Datan esityskerros on vielä toiminnallisuuksiltaan vaatimaton. Tässä kilpailijat vetävät pidemmän korren. Esimerkiksi eri graafityyppejä on hankala yhdistää. Excelin grafiikkaominaisuuksista jäädään PowerBi:ssä vielä kauas. Tätä paikkaa toisaalta se, että nykyään lokaali-Excelin Pivot-taulukosta saa yhteyden PowerBI-tietomalliin. Tätä kautta voi hyödyntää Excel-grafiikkaa.

- Puutteet kalenterikäsittelyssä. Tähän on tullut lisää viimeisissä päivityksissä - mutta kunnollista kalenteri- ja aikakäsittelyä PowerBI:ssä ei vielä ole (esim. Alkaen PVM, päättyen PVM). Aikakäsittely vaatii käytännössä pientä manuaalista jumppaa, esim. http://www.sqlservercentral.com/articles/Power+BI/141037/

- Ideologia: Microsoftin visio on, että kaikki käyttäjät luovat omia tietomallejaan ja se on PowerBI:n suurimpia jujuja. Fakta on se, että suurimmissakaan yrityksissä ei ole montaa käyttäjää, joilla riittää aikaa ja taitoja luomaan tietomalleja. Tämä visio on suurimmaksi osaksi utopiaa. Nyt paukut on laitettu tietomallin kehittämisen helppouteen kun kilpailijat ovat keskittyneet enemmän monipuoliseen esityskerrokseen (Qlik, Tableau)

- Raporttien automatisoitu lähettäminen dynaamisilla, automaattisesti valituilla parametreilla esim. sähköpostiin ei ole mahdollista

- On Premises-käyttö ei ole vielä mahdollista (taitaa olla työn alla Microsoftilla).

- Arkkitehtuurisista puutteistaan johtuen (yllä mainitut propertyt ja expressionit) osa uusista ominaisuuksista on pettymyksiä - ja lähes käyttökelvottomia vaativammilla asiakkailla. Esimerkiksi toukokuun uusi 'Conditional Formatting'. Eipä sillä päässytkään formatoimaan muuta kuin solun väriä, ja optioinakin formatoinnille vain kiinteä luku tai datasetin maksimiluku. Käytännössä tällaisiin vaan joutuu usein kirjoittamaan taustalle jonkin yksinkertaisen IF-kaavan tms...

PowerBI Conditional Formatting

 

 

 

 

 

 

 

 

Tai 'complex filters' toisena esimerkkinä. Jotta tämä olisi käyttökelpoisempi, pitäisi dataa pystyä filtteröimään muuttujan arvoilla, kuten käyttäjällä, GETDATE()-funktiolla tms. https://powerbi.microsoft.com/en-us/blog/smarter-auto-generated-insights-with-complex-filters/
Eli:

Jos PowerBI on yrityksesi ensimmäinen raportointityökalu, et välttämättä edes huomaa sen puutteita. Sillä saa aikaan raportointia nopeasti ja yksinkertaisesti, sekä jaeltua tietoa helposti organisaation ulkopuolellekin. Jos taas olet aikeissa vaihtaa nykyisen raportointityökalusi (esim Cognos, SSRS, QlikView, Oracle) PowerBI:hin, olet todennäköisesti ongelmissa.

Yksinkertaisemmissa ympäristöissä voi PowerBI:n puutteiden kanssa pystyä elämään, etenkin hintalappua toisella silmällä vilkuillen. Mutta jos on vaateita monimutkaista logiikkaa sisältäviin pixel perfect-raportteihin, jotka toimitetaan automaattisesti kuun viides päivä avainasiakkaiden sähköposteihin, valitse joku muu työkalu PowerBI:n rinnalle. Nykyään on hyvin yleistä että yrityksen raportointitarpeet täytetään useammalla eri työvälineellä.

Tietovaraston tarpeen osalta PowerBI:tä koskevat ihan samat lainalaisuudet kuin Qlik:iäkin (REPLACE('Qlik', 'PowerBI')) http://www.louhia.fi/2015/03/15/miksi-qlikview-ilman-tietovarastoa-on-typera-ratkaisu/


14.12.2015 / Ville Niemijärvi

Business intelligence tuotekoulutus Louhia Consulting 7.12.2015Järjestin viime viikolla Talentum Eventsillä koulutuksen: Business Intelligence- työvälineiden vertailu ja kilpailuttaminen. Sain tänään kurssipalautteen. Vastausprosentti oli 82 %, eli 9/11 osallistujasta vastasi palautekyselyyn. Arviointiasteikko on 5-1, jossa 5 on erinomainen ja 1 heikko.

Alla saamani palaute:

Miten hyvin tämä koulutus vastasi odotuksiasi? 5 = koulutus ylitti odotukseni, 1 = koulutus ei vastannut odotuksiani

Business intelligence koulutuspalaute 7.12.2015 Louhia Consulting Oy

Kouluttaja:

Business intelligence koulutuspalaute 7.12.2015 Louhia Consulting Oy 2

Koulutus vastasi siis odotuksia 4,33 / 5 ja kouluttaja eli meikäläinen sai tuomioksi 4,44 / 5.

Ja tässä vapaan sanan osuus:

  • Hieman enemmän olisi voinut jäädä aikaa kilpailuttamiselle.
  • Oikein asiallinen kouluttaja.
  • Hyvä, kun näytettiin demoilla eri raportointijärjestelmien toimintaa. Tilaosuudessa myös selitettiin asioita sopivasti sellaisella kielellä, että alan ammattilainenkin kykeni seuraamaan, vaikka antoi tiettyjen it-käsitteiden valua ohi. Kuultiin selotuksia mm. "kuutioista" ja selvitettiin esim. mitä metatiedoilla tarkoitetaan. Parasta on, että nyt on asiansa osaava konsultti tiedossa nimeltä ja on lupa olla yhteydessä häneen, jos tarvetta ilmaantuisi.
  • Hyvä, selkeä kokonaisuus. Hieman haparointia demojen kanssa mutta muuten hyvin koostettu kokonaisuus, joka antoi eväitä työvälineiden hankintaan ja kilpailutukseen.
  • Konkretia, konkretia, konkretia,...

Demoja pitää siis petrata edelleen ja kilpailutukselle jättää enemmän aikaa. Syksyllä ensimmäisessä kurssissa demot menivät ihan penkin alle, josta sietäisin saada sapiskaa. Jos joku syksyn kurssilaisista on kuulolla niin minä tarjoan oluet jos törmätään kylillä.

Nyt meni siis paremmin mutta kehitettävää riittää. Ensi kerralla paremmin ja otetaan demottavaksi vähän enemmän tuotteita. Kuulisin mielelläni myös kommentteja jos koulutus halutaan kaksipäiväisenä, kattaen esimerkiksi käyttötapauksia vielä syvällisemmin.

Muuten täytyy olla tyytyväinen kurssiin ja palautteen pohjalta näyttäisi kuulijatkin olleet. Kiitos vielä kaikille osallistumisesta.

Seuraavassa postauksessa avaan vähän kurssilla esitettyjä kysymyksiä mm. siitä mihin BI-markkinat ovat menossa.


Ps. Seuraava Business Intelligence -työvälinekoulutus on 13.4.2016. Sitä ennen tarjolla myynti- ja markkinointijohtajille suunnattu Asiakkuuksien johtaminen -analytiikan avulla 28.1.2016. Muita Louhian järjestämiä kursseja löydät sivuiltamme: http://www.louhia.fi/tuotteet/koulutukset Tervetuloa mukaan!


7.05.2015 / Ville Niemijärvi

Minulta kysyttiin keskiviikkona business intelligence -softien valintakriteereistä. Mitä tulee huomioida kun on valitsemassa uutta raportointi- ja analysointiohjelmistoa?

Laadin pikaisesti oheisen päätöspuun yrityksille ketkä kamppailevat näiden asioiden kanssa. Ehkä siitä on teille apua.

Voit ladata päätöspuun myös tästä pdf:nä: Louhian Päätöspuu BI-softan valitsijalle.pdf

Tämä on ensimmäinen drafti ja myönnän, että se on tehty vähän kieliposkessa ja joitain mutkia on oikaistu. Taustalla on kuitenkin useimpien softien kanssa vietetty 5-12 vuoden pitkä moniavioinen rakkaussuhde eli ihan hatusta analyysiä ei ole vedetty.

Kuulisin kuitenkin mielelläni lukijoiden kommentteja ja kehittäisin tätä huipputieteellistä päätöspuuta eteenpäin. Millä kriteereillä sinä valitsit raportointisoftan?

Voit kommentoida tähän blogikirjoitukseen tai Louhian LinkedInissä: https://www.linkedin.com/company/louhia-consulting-oy. Kannattaa muuten käydä painamassa seuraa-painiketta LinkedInissä. Paljon mielenkiintoista materiaalia analytiikan ja tiedolla johtamisen saattaa livahtaa muuten ohi suun.

Louhian Päätöspuu BI-softan valitsijalle


 

Ps. Järjestän syyskuussa 10.9.2015 Talentum Eventsillä BI-työvälineiden vertailu ja kilpailuttaminen -koulutuksen. Tarkempia tietoja löydät seuraamalla blogiamme, LinkedIniä ja Talentumin sivuilta: www.talentumevents.fi


18.03.2015 / Ville Niemijärvi

Edellisessä kirjoituksessa muistutin miksi vähänkään isomman yrityksen ja vakavasti itsensä ottavan CIO:n ei kannata rakentaa yrityksensä tietoarkkitehtuuria ja johtamisjärjestelmää pelkästän Qlikin varaan. Tai minkään raportointityövälineen.

Turvallisempi, suorituskykyisempi, skaalautuvampi ja pitkällä tähtäimellä edullisempi ratkaisu on rakentaa se tietovaraston päälle.

Tästä huolimatta tiedän, että Suomessa valtaosa Qlik-ratkaisuista on tehty suoraan operatiivisten järjestelmien päälle.

Tällaisissa tapauksissa voidaan mennä parin vuoden sisällä todella syvälle suohon tai koittaa selviytyä tilanteesta kunnialla. Eli nyt tarkkana: kumpaan kastiin haluat kuulua?

Käyn seuraavaksi läpi jälkimmäisen vaihtoehdon; miten tehdä hyvä Qlik-ratkaisu ilman tietovarastoa.

Simuloi Qlikillä tietovarastointia

Qlikissä on alkeellinen sql:n kaltaiseen komentokieleen perustuva ns. etl-työväline. Voit ladata ja muokata sillä dataa aika monipuolisesti. Qlikissä on myös omat datatiedostot (tiedosto.qvd), joihin voi tallentaa suuria määriä tietoa, ennen kuin sen vie varsinaiseen qlik-sovellukseen (tiedosto.qvw).

Qlikillä on siis kaikki komponentit, joilla voidaan toteuttaa samankaltainen arkkitehtuuri ja toiminnallisuus kuin tietovarastossa. Lisäksi kun otat käyttöön muutamia parhaita käytäntöjä, jotka ovat tietovarastomaailmassa arkipäivää, pääset varmasti säädyllisen lopputulokseen (edelleen olet menossa perse edellä puuhun mutta nyt sentään tyylillä).

Seuraavassa on kolme tärkeää oppia tietovaraston maailmasta, jotka kannattaa ottaa käyttöön Qlik-ympäristöä toteuttaessa.

1. Tietomallinnus ja datan harmonisointi on tärkeintä

Tietovarastossa on tärkeää määrittää yhteiset käsitteet ja laskentasäännöt. Tietovaraston perusperiaatteita on datan yhteismitallistaminen – tarjota yhdet yhteiset luvut yhdestä paikasta.

Tähän päästään mallintamalla yrityksen tiedot, päättämällä miten se kate lasketaan tai mikä on yrityksen virallinen tuote- tai tilihierarkia. Miten hyvitykset ja alennukset huomioidaan myynnissä ja puhutaanko ylipäätään myynnistä, liikevaihdosta vai laskutuksesta.

Tämän lopputuloksena on tietomalli. Tai käsitemalli. Se kuvaa yrityksen tärkeimmät käsitteet ja niiden väliset suhteet selkokielellä. Tietomalli on tietovaraston sydän ja sisäelimet, runko ja ranka.

tietomalli
Tietomalli, joka sopii 9/10 suomalaisista tietovarastoista.

 

Tietomalli toimii ennen kaikkea kommunikointivälineenä IT:n ja liiketoiminnan välillä. Se auttaa myös Qlik-kehittäjiä hahmottamaan, miten eri tietokokonaisuudet linkittyy toisiinsa.

Qlik-sovelluksia tehdessä kannattaa käyttää hetki aikaa käsitemallinnukseen. Lupaan, että tämä maksaa itsensä takaisin moninkertaisesti.

2. Kerroksellinen arkkitehtuuri (2- tai 3-kerros)

Tietovarastot toteutetaan kerroksittain. Alunperin tietovarastoissa oli kaksi kerrosta: ns. datan latausalue (staging-tietokanta) ja varsinainen tietovarasto. Nykyään data vaultin myötä näkee 4-tasoarkkitehtuureja. Tätä samaa kerroksellisuutta kannattaa suosia Qlikissä.

Onkin erittäin tärkeää erotella Qlikissä data ja sovellukset toisistaan. Tallenna siis operatiivisten järjestelmien data kuten laskutus, ostotilaukset, varastosaldot, tuotteet… kukin omaan Qlikin datatiedostoon (qvd).

Määrittele lisäksi hallintamalli kullekin datatiedostolle ja dokumentoi latausrutiinit hyvin: millä syklillä, järjestyksellä ja millä logiikalla tärkeitä yhteisiä käsitteitä ja etenkin dimensioita päivitetään.

Tuotteet, asiakkaat, organisaatio, tilihierarkia jne. ovat useimmiten tärkeimpiä yhteisiä dimensioita. Määrittele näille tiedon omistaja, joka vastaa siitä, että dimensiot pysyvät kunnossa ja data on validia.

Näin datatiedostot ajavat tietovaraston virkaa. Tärkeimmät tiedot ovat keskitetyssä paikassa ja Qlikin sovellukset pystyvät myös lukemaan niitä huomattavasti nopeammin kuin operatiivisia tietolähteitä.

Pyri minimoidaan suoraan Qlik-sovelluksiin (esim. johdon työpöytä) tietojen lataaminen, vaikka se kuinka kivalta ja nopealta tuntuisikin. Se, että viet datan ensiksi qvd-tiedostoon, vie ehkä 15 min enemmän aikaa mutta vuoden sisällä tämä voi säästää sinulta 15 päivää. Lue aiheesta lisää: Usain Bolt Jukolan viestissä.

3. Datan yhteiskäyttö: pyritään yhteen totuuteen

Kun datat on keskitetysti ylläpidetyissä datatiedostoissa, voit käyttää samoja tiedostoja useissa eri sovelluksissa. Tuotteita saatetaan tarvita kymmenellä eri sovelluksella ja raportilla – nyt se haetaan kaikille raporteille yhdestä keskitetystä paikasta. Sama pätee myynteihin, ostoihin, saldoihin, kiertonopeuksiin ja muihin tärkeisiin mittareihin.

Tällöin käyttäjät saavat yhteismitallista tietoa mutta helpotat myös IT-osaston työtä kun tiedot ovat helpommin hallittavissa kun liittymiä on vähemmän ja laskentalogiikat hallitaan keskitetysti.

Yhteenveto

Vaikka päädyt innoissasi tekemään Qlik-ratkaisun ilman raportointikantaa tai tietovarastoa, älä hätäänny. Plöröt on housuissa mutta ne voi pestä ja tilanteesta voi selvitä kunnialla. Tässä tiivistetyt ohjeet:

  1. Tee tietomalli
  2. Tee kevyt hallintamalli, määritä latausrutiinit ja tiedon omistajuudet
  3. Erota data ja sovellukset toisistaan (2- tai 3-tasohierarkia)
  4. Yhteismitallista ja yhteiskäytä: pyri yhteen yhteiseen totuuteen

Alla vielä kuvina miten Qlikillä voi tehdä a.) tuhoa b.) kohtuullisen fiksusti ja c.) todella järkeviä ja kestäviä ratkaisuja. Valinta on sinun (kuten vastuukin).

Qlik arkkitehtuuri tehtynä väärin
Qlik sillisalaatti: älä lataa sovelluksiin tietoa suoraan lähdejärjestelmistä.

 

Qlik arkkitehtuuri tehtynä lähes oikein
Erottele data- ja sovelluskerros toisistaan. Näin simuloit tietovarastointia ja teet eheämmän kokonaisuuden.

 

Qlik arkkitehtuuri tietovaraston kanssa on kestävä
Fiksuin ratkaisu on kuitenkin rakentaa Qlik-ratkaisu tietovaraston päälle. Näin varmistat modulaarisuuden, turvallisuuden, skaalautuvuuden ja suorituskyvyn.

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.


25.01.2015 / Ville Niemijärvi

"
No niin, aion kertoa teille valituille siis ensimmäisenä maailmassa, uraa-uurtavasta prediktiivisen analytiikan menetelmästä, jolla voitte tahkoa miljoonia massia, pysäyttää ISIS, toteuttaa Sote-uudistus, päteä pomolle ja saattaapa teille lykästää tämän ansiosta kotonakin. Joten aloitetaan. Menetelmän pointtina on siis...

- Anteeksi keskeytys, mutta minulla olisi kysymys.

Joo, antakaa tulla vain.

- Mikä on paras analytiikkasofta? Onks SAS kova vai mitä? Kiinnostaisi tosi kovasti! 

"

Meillä on käytössä menetelmiä, joilla voimme oikeasti tehdä rahaa. Nostaa myyntiä, pienentää kustannuksia, ehkäistä kalliiden koneiden hajoaminen ennakkoon, ehkä jopa ehkäistä sairauksia, pelastaa ihmishenkiä, parantaa vähintäänkin asiakaspalvelua.

Silti löytyy kavereita, jota kiinnostaa vain softa. Kun keskustelemme prediktiivisestä analytiikasta, löytyy aina ihmisiä, joita ei kiinnosta hyödyt, sovelluskohteet, menetelmät, keinot, kustannukset. Ainoastaan mikä softa on paras.

Analytiikassa tuotteen merkitys on pieni

Olen monasti paasannut siitä, miten perinteisessä raportoinnissa (business intelligence) on oikeastaan aivan sama minkä tuotteen valitset. Kaikki pystyy tekemään kaiken.

Analytiikassa tämä on vielä selvempi asia. Analytiikassa tuotetta tärkeämpää on mitä mallinnusmenetelmää tai algoritmia käyttää mihinkin ongelmaan. Tuotteella ei ole tällöin merkitystä. Logistiset regressiot, päätöspuut, ARIMAXit ja satunnaiset metsät löytyy jotakuinkin kaikista.

Menetelmääkin tärkeämpää on päästä käsiksi oikeaan lähdedataan ja pystyä muokkaamaan sitä. Rikastamaan sitä, summaamaan, siivoamaan, korjaamaan. Sillä et koskaan saa täydellistä dataa. Tietovarastoinnista tuttu ETL-softa ja SQL-taidot ovatkin usein tärkeämmässä asemassa kuin analytiikkasofta.

Datan muokkaamistakin tärkeämpää on ymmärtää alkuperäinen liiketoimintaongelma. Ymmärtää liiketoiminnan lainalaisuudet. Liiketoiminnan ymmärtäminen on välttämätöntä, jotta ratkaistava ongelma voidaan määritellä ja jotta analyysin tuloksia voidaan tulkita ja soveltaa käytäntöön.

Liiketoiminnan ymmärrystä vielä tärkeämpää on saada valmiit tulokset tuotantoon. Sillä analyysi ilman tuotantoon vientiä on ajan ja rahan hukkaa. Tämä on vaikein kohta missä tahansa analytiikkahankkeessa. Tehdä analyysin tuloksilla rahaa. Pelastaa ne ihmishenget.

Kyse ei ole siitä, etteikö näin voisi tehdä. Useimmiten kyse on siitä, että analytiikkaprosessia ei ole määritelty loppuun asti. On tilattu pistemäinen ratkaisu. Tai yrityksen johtaminen ei ole kypsä vielä tiedolla johtamiselle.

Siinä tulikin käytyä analytiikkaprojekteissa käyttämämme standardoitu CRISP-DM prosessi läpi.

CRISP-DM Process

 

Huomaatko missä vaiheessa CRISP-mallia puhutaan analytiikkatuotteesta?

Ei missään.

Mallinnuksen osuus prosessissa on ehkä 5-10%. Tuotteen osuus tuosta mallinnuksesta on sitten se 5-10%. Eli tuotteella on häviävän pieni merkitys.

Suomesta löytyy kourallinen yrityksiä, jotka tekevät analytiikkaa siinä mittakaavassa ammattimaisesti ja liukuhihnalta, että tuotteiden ominaisuuksilla alkaa olemaan merkitystä prosessien tehokkuudessa. Tai heillä on spesifi liiketoimintaongelma, johon SAS:ilta löytyy valmis kilke ja tuhti hintalappu päälle. Muut pärjäisivät vaikka ilmaisella R:llä.

Siinä vaiheessa kun sinua kiinnostaa enemmän softat kuin tulokset, on aika pysähtyä ja miettiä mitä olet tekemässä. Haluatko saada CV:tä komistamaan uuden härpäkkeen vai haluatko tehdä oikeasti jotain merkittävää?


6.06.2014 / Ville Niemijärvi

Tiedon visualisoinnissa ja raportoinnin nopeudessa QlikView on todennäköisesti markkinoiden paras.

QlikView:llä saa rakennettua näyttäviä ja informatiivisia työpöytiä helposti. Tämän voi käydä toteamassa QlikView:n demoista, joista tässä yksi esimerkki. Ei ehkä valtavasti silmänkarkkia mutta selkeä ja informatiivinen.

 

QlikView

 

Reality bites - kun mopo karkasi

Todellisuus ei ole aina yhtä ruusuista ja kaunista (lue myös Usain Boltista Jukolan viestissä). Lukuisia QlikView-toteutuksia eri asiakkailla nähneenä ja toteuttaneena, uskallan väittää, että tämä on QlikView-raportoinnin todellisuutta paremmin kuvaava raportti:

QlikView gone bad

"No kun oli kova kiire ja tietoa oli niin helppo vaan lisätä, sitten se vaan lähti lapasesta."

"Ei sitä koskaan tiedä kuka tarvii mitä, parempi lisätä vaan kaikki."

 

Yleisimmät puutteet, joihin törmään valitettavan useilla QlikView-raporteilla näkee yllä olevasta esimerkistä:

  1. Raportille on tuupattu kaikki mahdollinen tieto mitä organisaatiosta löytyy. Välilehtiä on kymmeniä, kullakin on kymmeniä valintalistoja ja erillisiä raporttiobjekteja (listoja, kaavioita jne.) ja kaikki sekaisin. Yhden yksittäisen tiedon jyvän etsimiseen menee tolkuttomasti aikaa.
  2. Layout: tasaus, sijoittelu, ilmavuus? DDR:n kulta-ajan kerrostalolähiöarkkitehtuuri on oikeasti kaunista katseltavaa verrattuna QlikView-tuotoksiin mihin törmään.
  3. Tyylejä ei ole asetettu (esim. taustavärit) koska se veisi 5 minuuttia kallista aikaa, joka käytetään mielummin taas uuden chartin luontiin. Tai sitten kehittäjät vain todella rakastavat harmaata.
  4. Vierityspalkkeja tulee niin listaraporteilla kuin koko selaimelle, johtuen valtavasta määrästä tietoa ja siitä, että raporttia ei ole suunniteltu näytölle sopivaksi. Pahimmassa tapauksessa käyttäjä joutuu vierittämään ensiksi selaimen palkkia ja sitten listaraportin, vaakaan ja pystyyn totta kai.
  5. Tiedostojen koot ovat useita gigatavuja: koska samalle raportille pitää saada mahtumaan koko maailma, kasvaa raportin koko valtaviin mittoihin. Tämä taas näkyy huonona suorituskykynä ja valtavana muistin tarpeen.

 

Onkin jotenkin nurinkurista, että juuri visualisuudestaan ja helppokäyttöisyydestään tunnettu tuote, tuottaa (yli) innokkaiden käyttäjien ja kehittäjien käsissä kaikista epävisuaalisinta jälkeä.

Sama pätee suorituskykyyn. Luen eräällä asiakkaallani miljardin rivin relaatiotaulusta Cognos-raportilla täsmähaulla esim. yhden tuotteen myynnit parilta vuodelta n. 5 sekunnissa (kiitos indeksien). n. 20 GB QlikView-mammuttiraportin avaaminen kestää yksissään 5 minuuttia. Valintojen tekemisen jälkeen ja tulosten tultua tuote onkin jo poistunut myynnistä. Cognos-palvelimella on muuten muistia 16 GB. QlikView-palvelimella muistia on 512 GB.

Vanha ja jäykkä pitää ruodussa

Itseasiassa vanhemmat ja perinteisemmät raportointivälineet kuten IBM Cognos, Oracle Discoverer tai Microsoftin Reporting Services tarjoavat tässä suhteessa paremman ja turvallisemman vaihtoehdon. Niiden heikkous eli jäykkyys ja/tai käytön vaativuus, on niiden vahvuus.

Kun teen näillä välineillä raporttia, mietin todella tarvitsenko (tai tarvitseeko asiakas) kutakin tietoa tai valintalistaa. Jos mahdollista, tiputan sen pois. Jos jo valmiille raportille halutaan lisätä uusia tietoja, on jokaisella pienelläkin muutoksella hintansa ja näin se ohjaa järkevään toteutukseen. Niin kustannusten kuin suorituskyvyn suhteen.

Luopumisen tuska: syötkö mielummin Michelin tähtien kera vai snägärillä

Vika ei ole tietenkään työkalussa. QlikView itsessään on mainio softa, sillä tehdyt toteutukset aloitetaan usein vain liian vauhdilla miettimättä päämäärää - päätöksenteon tukemista. Tällöin pitää tietää mitä tietoa tarvitaan päätösten taustalla.

Hyvien raporttien teko on aina karsimista ja luopumista.

Hienon ja laadukkaan ravintolan erottaa mättölästä siitä, että annokset on pieniä ja maut ovat tarkkaan harkittuja. Kokonaisuus on elämys.

Sanomalehtien etu on ammattitaitoiset journalistit, jotka keräävät, valitsevat ja taustoittavat niitä uutisia joista minä olen kiinnostunut tai joita minun kannattaa seurata. Näin minun ei tarvitse penkoa koko maailmaa saadakseni siitä tolkullisen kuvan.

Kun menen museoon, intendentti on laittanut koko ammattitaitonsa peliin ja valinnut puolestani seinille harmonisen kokonaisuuden joka tarjoaa minulle taide-elämyksen.

"Mutta kun käyttäjät vaativat nähdä kaiken."

Antaa vaatia. Ei Michelin ravintolan kokki väännä sinulle jättiannosta spydäria vaikka kuinka ruikutat nälkääsi. Hän tietää paremmin. Tiedätkö sinä?


7.03.2014 / Jani Liimatta

Tuoreessa markkina-analyysissaan Gartner oli tipauttanut KPI (Key Performance Indicator)-toiminnallisuudet pois vertailtavien ominaisuuksien listoilta BI-tuotteiden osalta. Tämä onkin aika lailla ymmärrettävää. Maailmalla ei ole tullut törmättyä kovinkaan moneen projektiin, jossa KPI-mittareita olisi käytetty onnistuneesti. Sen sijaan useampaan epäonnistuneeseen projektiin on tullut törmättyä. Epäonnistumiset ovat johtuneet seuraavista asioista:

  • Mittareita on ollut liikaa
  • Osa mittareista on ollut keksimällä keksittyjä
  • Liian suuri osa mittareista päivittyy kerran vuodessa (esim. työtyytyväisyys, henkilömäärät jne). Tämän takia niitä ei seurata ja lisäarvo mittariston kannalta on nolla.
  • Iso osa mittareista vaatii käsin täyttämistä. Täyttäminen joko unohtuu, luvut ovat epäluotettavia tai irrelevantteja - tai jopa sanallisia.
  • Tavoitteita ei pystytä asettamaan
  • Mittareiden laskentasäännöt ovat olleet monimutkaisia. Jos takana on kovin monimutkaista logiikkaa, miten työntekijä pystyy vaikuttamaan mittarin arvoon?

Työurani alkupuolella ollessani töissä ABB Servicellä näin maailman parhaan KPI-mittariston. Mittariston käyttöliittymänä toimi sihteerin pöydällä levännyt helmitaulu. Joka aamu kun toimitusjohtaja astui hissistä ulos, osui helmitaulu ensimmäisenä silmään. Sihteeri oli päivittänyt edellisen päivän päätteeksi helmitauluun yrityksen ajantasaisen kassatilanteen. Mikä tästä teki ylivoimaisen mittarin?

  • Oli tunnistettu yrityksen tärkein mittari
  • Mittareita ei totisesti ollut liikaa
  • Käyttöliittymä oli koeteltua tekniikkaa ja käytettävyys erinomainen
Maailman paras KPI
Maailman paras KPI-mittaristo