Qlikview ilman tietovarastoa on kuin talo ilman perustuksia

Qlikview on mahtava raportointityöväline. Omassa kategoriassaan, datan nopeassa etsimisessä (Gartnerin termeillä: data discovery) ja visualisoinnissa se on parhaita mitä markkinoilta löytyy.

Se on nopea (niin raporttien kehitys, tietojen lataus kuin itse käyttö), intuitiivinen ja helppokäyttöinen. Monet asiakkaat ovat silminnähden ihastuneet Qlikview:n sen jälkeen kun ovat ensiksi taistelleet jäykempien raportointivälineiden kanssa.

Mutta tuote ei ole täydellinen ja niin kuin kaikissa softissa, siinä on puutteensa. Yksi suurimmista ongelmista ei liity itse tuotteeseen vaan se on joillekin yrityksille (ja myyntimiehille) pesiytynyt harhaluulo, että Qlikview olisi jotenkin vaihtoehtoinen tai kilpaileva teknologia tietovarastoille. Olen parikin kertaa kohdannut asiakkaan kysymyksen: ”Pitäisikö meidän ostaa Qlikview vai tietovarasto?”

Tietovarastot ja Qlikview eivät ole kilpailevia vaihtoehtoja vaan toisiaan tukevia.

Vastauksena sanonkin usein: Parhaaseen lopputulokseen pääset jos teet molemmat.

Tietovarasto ei ole nimittäin (kilpaileva) ohjelmisto vaan ympäristö, joka rakentuu prosesseista, etl-softasta, tietokannoista ja tiedoista. Itsessään sillä ei tee muuta kuin säilöö tietoa. Jotta siitä saa hyötyä, pitää käytössä olla myös jokin raportointi-/analysointityöväline – kuten Qlikview.

Mutta tarvitaanko sitten Qlikview:n kanssa tietovarastoa? Ei välttämättä varsinkaan pienissä, yksinkertaisissa ympäristöissä. Mutta isoissa konsernitason hankkeissa ja ympäristöissä joissa tietoa pitää prosessoida enemmän, se on erittäin suositeltavaa. Kerron seuraavaksi miksi.

Haluatko rakentaa jämäkän kivitalon vai puumajan?

Pelkästään Qlikview:llä toteutettu raportointiympäristö on kuin puumaja. Sitä on kiva nikkaroida vaikka koko perheen kanssa yhdessä. Kaikki voivat osallistua, se on helppoa, todella nopeaa ja hauskaa.

Lopputuloksena on kiva maja mutta ei siinä suomalaista talvea vietetä. (voit myös tehdä tuhat kivaa pikkumajaa jolloin sinulla on kiva hökkelikylä)

Tietovarastoon perustuva raportointiympäristö on taas se kivitalo kunnallistekniikan kera. Se vaatii kokonaisvaltaista määrittelyä ja suunnittelua. Taloa tekemässä on erilaisia rooleja arkkitehdistä timpuriin. Homma kestää usein kauan mutta lopputulos on kestävä, monikäyttöinen, eheä ja luotettava.

Vertauskuvat sikseen, tässä 3 tärkeintä syytä miksi tietovarastoa ei kannata unohtaa yhtälöstä kun mietit raportointiarkkitehtuuriasi (oli sinulla Qlikview, Cognos, Oracle, SAP, MS, Tableua tai vaikka Excel)

Miksi pelkkä Qlikview ilman tietovarastoa on huono ratkaisu?

1. ETL-prosessi ja datan muokkaaminen

ETL-prosessi (extract-transform-load) tarkoittaa sitä kun dataa ladataan tietolähteistä, muokataan, siivotaan, yhdistetään ja tuupataan lopulta kohdejärjestelmään (usein tietovarastoon) raportointia varten.

Qlikview:llä voidaan simuloida etl-työvälinettä mutta se ei tarjoa kovin monipuolisia ja kehittyneitä työvälineitä siihen – verrattuna oikeisiin etl-softiin, joilla tietovarastoja rakennetaan (esim. Informatica, SSIS, Datastage…).

Voit kirjoittaa monimutkaisia Qlikview-skriptejä mutta jos esim. tuotetiedot sijaitsee kolmessa eri ERP:ssä ja 10 eri taulussa ja nämä pitää yhdistää raportointia varten yhteen tauluun (todellinen tilanne parilla asiakkaallani), tulee QV-skripti olemaan aikamoinen spagetti ja toteutus sekä ylläpidettävyys yhtä tuskaa.

ETL-työ sekä tiedon laatuun liittyvät ongelmat ja niiden ratkaiseminen muodostavat valtaosan minkä tahansa raportointiympäristön toteutustyöstä (oli tietovarastoa tai ei). Tähän työhön suosittelen oikeaa etl-työvälinettä.

Puhumattakaan jos kyseessä on niin sanottu hitaasti muuttuva dimensio (esim. asiakkaan asiakasryhmä muuttuu ja haluat seurata jatkossa sekä asiakasta kokonaisuutena että vanhaa ryhmää ja uutta ryhmää). Äkkiseltään en edes tiedä pystyykö Qlikview:llä toteuttamaan hitaasti muuttuvia dimensioita?

Spagettikoodattujen Qlikview-skriptien ylläpidettävyyttä ja hallintaa ei auta yhtään Qlikviewn heikko metadatan hallinta (tai metadatan puute).

2. Datan siirtäminen tai lukeminen toiseen ohjelmistoon (esimerkiksi analytiikan käyttöön)

Kun tiedot on tallessa Qlikview:ssä (joko qvd tai qvw -tiedostoissa), ei niitä pysty lukemaan sieltä toisella softalla tai sql-kyselyillä. Sama kuin liiketoimintasi ja päätöksentekosi kannalta kriittiset datat olisi jemmassa pdf- tai ppt-tiedostoissa – niiden jatkojalostaminen on todella hankalaa ja sisältää todellisen liiketoimintariskin.

Usein ERP:stä poistetaan joitakin tietoja ajan myötä, ihan vain tilan puutteen vuoksi ja koska operatiivisessa toiminnassa harvoin kiinnostaa 10 vuotta vanha tieto (mutta päätöksenteon ja analytiikan kannalta se voi olla todella tärkeää). Ja joskus koko ERP uusitaan ja uuteen ERP:iin pitää siirtää vanhat historiat.

Haluaisitko, että nuo tärkeät tiedot olisivat ainoastaan tallessa Qlikviewssä (tai pdf-tiedostoissa)? Miten siirrät ne Qlikview:stä uuteen ERP:iin?

Tovi sitten meillä oli analytiikkaprojekti, jossa asiakkaan myyntidataa piti saada siirrettyä eteenpäin meidän palvelimelle, jotta voimme tehdä hieman numeronmurskausta ja tiedon louhintaa. Asiakkaalla ei ollut tietovarastoa eikä operatiivisten järjestelmien tuntemusta eikä välttämättä edes pääsyä niihin. Koko raportointi oli rakennettu Qlikview:n päälle.

Jotta saimme datat itsellemme, piti tehdä qlikview-sovellus johon tehtiin listaraportti, johon koottiin tarvittavat datat. Tämän jälkeen Excel-exportin kautta siirrettiin dataa pienin erin Exceliin ja sitä kautta meille. Virhealtista ja hidasta käsityötä siis. Homma hoitui hyvin kun dataa oli vain muutama satatuhatta riviä. Kuvittele millainen työ on kun dataa on miljardiriviä.

Liiketoiminnallesi kriittiset tiedot kannattaa säilyttää operatiivisten järjestelmien lisäksi paikassa, johon pääset käsiksi sql-kyselyillä ja 3. osapuolen välineillä nyt ja 10 vuoden päästä. Relaatiokanta on tähän paras vaihtoehto.

3. Dataa ei voi muokata

Kun olet ladannut datat Qlikview:n tiedostoihin, et voi enää muokata dataa. Et voi päivittää dataa update/insert-komennolla. Et voi deletoida dataa, poistaa esimerkiksi yhtä virheellistä riviä. Kaikki perustoiminnallisuudet mitä voit tehdä relaatiokantaa vasten, on poissa – lukuunottamatta kaiken datan lataamista uudestaan.

Ajattele tilannetta, jossa huomaat että tuotteella on ollut väärä hinta viimeisen puolen vuoden ajan ja tuotteen katteet on pielessä Qlikview-raportoinnissa. Miten teet korjauksen Qlikview:n? Korjaat hinnan ERP:iin ja lataat kaikki myynnit uudestaan. Entä jos tiedot on jo poistettu syystä tai toisesta ERP:stä ja virheellinen data on ainoastaan tallessa Qlikview:ssä? Miten korjata se?

Paras vaihtoehto: Qlikview ja tietovarasto yhdessä

Kun on kyse isoista business intelligence -ympäristöistä, dataa tulee useista tietolähteistä ja tietoa pitää muokata muokata ja yhdenmukaistaa paljon, suosittelen rakentamaan aina tietovaraston – oli raportointityöväline mikä tahansa. Se on varmin, kestävin ja huom: edullisin tapa pitkällä tähtäimellä hallita tietojasi ja raportointiympäristöäsi.

Voit rakentaa toki koko raportointisi pelkästään Qlikview:n varaan: se on nopeaa ja aloitus on paljon edullisempaa kuin lähteä rakentamaan ensiksi tietovarastoa. Mutta ympäristön elinkaarikustannukset tulevat olemaan tällöin isommat ja otat isoja riskejä tiedon hallinnan suhteen.

Qlikview on mahtava työväline ja siitä tekee vielä paremman kun hyödyntää sen parhaita puolia tietovaraston kanssa yhdessä.

Suositus: Tee kestävä kivitalo mutta jätä tontille varaa puumajoille

Parhaaseen lopputulokseen pääset kun toteutat tietovaraston, johon otat mukaan kaikista yleiskäyttöisimmät ja/tai hankalimmin toteutettavat dimensiot ja faktataulut.

Tuotteet, asiakkaat, myyjät, kustannuspaikat, tilikartat ovat tällaisia dimensioita. Myynnit/laskutus, tilaukset, avoin tilauskanta, varastotapahtumat, saldot… ovat tällaisia faktatauluja.

Raportoi näitä tietoja Qlikview:llä tietovaraston kautta. Mutta jätä varaa luovuudelle, ketteryydelle ja Qlikview:n vahvuuksille. Anna käyttäjille mahdollisuus yhdistää Qlikview:ssä tietovaraston tietoihin muita tietolähteitä: Exceleitä, csv-tiedostoja ja muita tietokantoja.

Jos käyttäjälle tulee tarve tarkastella myyntidatan (tietovarastosta) rinnalla CRM:n dataa, voi hän (tai QV-admin) ladata CRM-datan vaikka lennosta raporteilleen – hyödyntäen Qlikviewn nopeutta ja helppokäyttöisyyttä.

Tällöin sinulla on vankka kivitalo kunnallistekniikalla mutta samalla sinulla on iso verstas ja mahtava tontti, jossa nikkaroida leikkimökkiä, puumajaa, autotallin laajennosta ja mitä mieleesi juolahtaakaan.

4 kommenttia artikkeliin ”Qlikview ilman tietovarastoa on kuin talo ilman perustuksia

  1. Jani Liimatta sanoo:

    Ilmeisesti Microsoftin alkuperäinen ajatus oli mennä QV:n tontille PowerPivot:illa. Office 2013:ssa PowerPivot, PowerQuery ja PowerMap kuuluvat kuitenkin vain Professional Plus-pakettiin. Tämä äkkikäännös lisensoinnin suhteen oli huono uutinen monille. Pahimmassa tapauksessa nämä kolme uutta tuotetta jäävät vain harvojen herkuksi.

    PowerPivot-suvilla mainostetaan edelleen: ”Bring self-service business intelligence to everyone”. Tämä ei ihan pidä siis paikkaansa. Tämä on kummallista, koska etenkin raportoinnin osalta tässä on kyse aivan elinkaarensa alkutaipaleella olevasta tuotteesta.

    Palataan tähän ja muuhunkin Microsoft-BI-problematiikkaan lähitulevaisuudessa blogin muodossa.

Jätä kommentti