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


25.04.2017 / Ville Niemijärvi

Istahdin taas alas Lassen, Louhian johtavan Data Scientistin kanssa ja rupateltiin vähän mitä työvälineitä edistyneen analytiikan toteutustöissä tarvitaan.

Edellisessä kirjoituksessa käytiin Lassen kanssa läpi mitkä ovat Data Scientistin 3 tärkeintä taitoa. Noista taidoista voi jo vähän päätellä minkälaista työkaluosaamista pitää myös hallita.

Voit katsoa videon tästä tai tämän blogin alta.

Data Scientistin tärkeimmät työvälineet

Louhialla jo reilun 5 vuoden ajan kymmeniä data science -toteutuksia tehnyt Lasse luettelee ison listan tuotteita, joita käyttää päivittäin työssään.

  • ETL-työ, data integraatio ja muokkaus: SQL Server Integration Services
  • Tietokannat: SQL Server Management Studio
  • Mallintaminen, data science: R, Python, RapidMiner, Azure ML
  • Tiedon visualisointi, raportointi: QlikView, Power BI

Jokaisella tuotteella on oma roolinsa ja jotta saadaan parempi ymmärrys missä niitä käytetään, sijoittelimme ne alla olevassa kuvassa tyypilliseen business intelligence/analytiikka -arkkitehtuuriin.

Tyypillinen analytiikka-arkkitehtuuri ja data scientistin työvälineet

Tyypillinen tietovarasto/business intelligence/analytiikka -arkkitehtuuri
Tyypillinen tietovarasto/business intelligence/analytiikka -arkkitehtuuri

Kuvassa yllä näkyy tyypillinen arkkitehtuuri, joka on joko valmiina rakennettuna yrityksessä tai me rakennamme sellaisen osana analytiikka- tai laajempaa tiedolla johtamisen hanketta.

Alimpana on tietolähteet eli organisaation lukuisat operatiiviset järjestelmät, CRM:t, taloushallinto  jne. Sekä yhä useammin myös ulkoiset tietolähteet, joka avoimien rajapintojen kautta tai ostettuna 3. osapuolelta.

Tieto täytyy tämän jälkeen ladata analytiikkaa varten jollekin tallennusalustalle. Latauksen yhteydessä tietoa usein yhdistetään, muokataan, siivotaan. Tätä kutsutaan tietovarastopiireissä ETL-prosessiksi (extract-transform-load) mutta usein puhutaan vain tiedon integraatiosta.

Tässä Lasse hyödyntää lähinnä SQL Server Integration Serviceä (SSIS). Itse olen käyttänyt SSIS:n lisäksi Pentahoa ja IBM Cognos Data Manageria, joka on nykyään korvattu IBM Infosphere DataStagella.

Muita markkinoilta löytyviä tuotteita on mm. Informatica, Oracle Warehouse builder, SAS Data Integration Studio.

Tieto siis tallennetaan jollekin tallennusalustalle ja useimmiten se edelleen on relaatiotietokanta. Lassen tapauksessa useimmiten SQL Server jota hallitaan SQL Server Management Studiolla.

Big data (esim. Hadoop) ja NoSQL -tietokannat ovat yleistyneet ja niitä on asiakkaillamme mutta lopulta tieto on helpointa viedä relaatiokantaan, jotta sitä voidaan hyödyntää tilastollisessa mallintamisessa eli varsinaisessa data science -työssä.

Tällöin käyttöön otetaan mallinnustyövälineet kuten R, Python, RapidMiner tai Azure Machine Learning.

Muita markkinoilta löytyviä tuotteita ovat mm. SAS, Knime, SPSS, Amazon Machine Learning, IBM Watson.

Kun ennustemallit tai muu edistyneen analytiikan mallinnus on tehty, tulokset viedään usein visualisoituna liiketoiminnalle (jolleivät mene osaksi jotain operatiivista prosessia tai applikaatiota).

Tällöin käyttöön otetaan raportointi-, visualisointi- ja business intelligence -tuotteet. Lasse suosii näissä QlikView:tä ja Power BI:tä.

Muita asiakkaillamme yleisiä BI-tuotteita ovat mm. Tableau, Cognos, SAP ja Oracle.

Data Scientistin pitää hallita iso joukko tuotteita

Kuten yltä näkyy, ainakin konsulttifirmoissa Data Scientistin pitää hallita iso joukko eri tuotteita.

Totta kai isoissa projekteissa usein on omat erikoismiehet tietovaraston tai data laken rakentamiseen ja omansa tiedon visualisointiin.

Mutta prosessi menee todella hitaaksi jos data scientisti joutuisi joka kerta kun tarvitsee uutta data settiä tai muokkauksia olemassa olevaan, kutsumaan ETL-osaajaa avuksi.

Työ on niin iteratiivista, että on tehokkainta, että DS-roolissa pystytään ottamaan myös ETL-työ, tietokannat ja datan visualisointi haltuun.

Katso video kokonaisuudessaan alta. Muista laittaa Louhian Youtube-video seurantaan ja kommentoi rohkeasti jos haluat kuulla ja nähdä lisää analytiikka-asiaa meiltä.

 


22.12.2015 / Ville Niemijärvi

Viime viikon ja syksyn aiemmalla business intelligence -kurssilla esitettiin muutamia hyviä kysymyksiä liittyen BI-markkinoihin. Laitan tässä vastaukset ja pitkähkön pohdinnan muillekin lukijoille.

1. Mikä on paras QlikView-konsulttitalo?

Tämmöisen miinan pudottivat. Nyt oli mahdollisuus haukkua kaikki lyttyyn tai vetää överisti kotiin päin. Mutta asia on vain niin, että Qlik-konsulteilla on alalla järjestään hyvä maine. Ajatellen IT-alaa kokonaisuutena.

Olen järjestänyt useita kilpailutuksia (niin työväline kuin konsultointi) ja kierrän vuodessa kymmeniä asiakkaita, joilla useilla on Qlik-ympäristö. Järjestään palaute valitusta konsulttitalosta on positiivista, oli se kahden henkilön nyrkkipaja tai isompi puulaaki.

Positiivinen palaute johtunee osittain työvälineestä, joka edesauttaa nopeiden projektien toteuttamisessa. Tableau-asiakkaiden palaute omasta toimittajasta on myös positiivista. Hieman kömpelömmillä tuotteilla myös toteuttava konsulttitalo saa kuraa niskaan jos hommat ei etene tai tulos ei tyydytä.

Jos joitain Qlik-taloja pitäisi nostaa esille niin oma valintani olisi Infrastone. Olemme tehneet kolmessa projektissa yhteistyötä ja jälki on mainiota ja laadukasta. Infrastone on omien sanojen mukaan Suomen kokenein Qlik-kumppani ja väkeä on siis enemmän kuin mies ja koira.

Ennen kaikkea asiakkaan edun laittaminen aidosti etusijalle lisenssi- tai projektimyynnin kustannuksella on hatun noston arvoinen juttu. Korupuheissa kaikki väittää tätä mutta tositapahtumassa harva toimii näin. Infrastone on näyttänyt tämän pari kertaa toteen mikä on oikeasti poikkeuksellista.

Muita Qlik-toimittajia, joita en itse enempiä tunne mutta joita asiakkaat ovat kehuneet ovat ainakin EVRY, Eximia ja käyttöliittymäsuunnitteluun erikoistunut Adage. Käyttöliittymäsuunnittelun mukaan tulosta BI-kehitykseen lisää vähän alempana.

Tämä ei tarkoita, että muut Qlik-kumppanit olisivat kuraa. Löydät kaikki Qlik-kumppanit täältä.

Ja hei yritykset: hyviä toimittajia kannattaa mainostaa muillekin. Se on teidän etu, että hyvä kumppaninne menestyy. Muutenkin kuin vain toimittajien väsyneissä referenssitarinoissa (“toimittaja X teki sen mitä pyydettiin ja nönnöönöö booring!…”)

Ja huonoja saa myös kritisoida. Se on rehtiä ja reilua liiketoimintaa. Niin pakotetaan toimittajia nostamaan tasoa, kouluttamaan tekijöitä ja kehittämään prosesseja. Näistä asioista puhutaan ihan liian vähän.

2. Mihin Business Intelligence -työvälineet ovat menossa?

Lyhyt analyysi: isot perinteiset toimijat lähestyvät pieniä, ketteriä visualisointi-experttejä kehittämällä omia data discovery ja visualisointi ominaisuuksia. Pienet, ketterät taas kehittävät enterprise-tason kyvykkyyttä.

Eli isot BI-talot ovat tehneet hartiavoimin töitä kehitellessään omia visualisointivälineitä. Esimerkkinä SAP:in Lumira, Microsoftin Power BI, IBM Cognoksen Workspace (ja nyt julkaistu Cognos Analytics) ja SAS Visual Analytics. Olen tutustunut näihin kaikkiin ja suunta on oikea.

Pienet entiset niche-toimijat taas laajentavat repertuaariaan pyrkiessään aidoksi enterprisetason ratkaisuksi. Esimerkkinä Qlik, joka osti NPrintingin vakioraportointiin. Metadatan hallintasovelluksen (vrt. SAP Universe, Cognos Framework Manager) puutetta paikataan ohjaamalla oikeaoppiseen tietoarkkitehtuuriin erottaen Qlikin data- ja sovelluskerroksen. Tiedon hallittavuutta ja auditointia (data governance) parannetaan Governance dashboardilla, jota tosin harmittavan harva asiakas käyttää.

Nyt alkaa näyttämään siltä, että lähes kaikki BI-tuotteet ovat ns. one-size-fits all -tuotteita eli yksi tuote sopii kohtuu hyvin koko organisaation käyttöön.

Tableau on tosin poikkeus. Ainakin minulle heidän myynti on sanonut selvästi, että perinteinen vakioraportointi ei ole heidän pallokenttä. Yrityksellä ei näytä olevan hinkua pyrkiäkään enterprise-tason tuotteeksi ja useimmiten Tableau onkin yrityksessä se “kakkostuote” eli pienemmän osaston käytössä puhtaasti visualisointiin, perinteisen vuosia sitten hankitun Cognoksen tai SAP:in hoitaessa vakioraportoinnin. Tästä päästääkin seuraavaan kysymykseen.

3. Onko kahden BI-tuotteen strategiassa järkeä?

Kannattaako kuitenkaan laittaa kaikki munat samaan koriin vai voisiko elää kahden tuotteen kanssa?

Vastaus: Kaksi BI-tuotetta on ihan toimiva ratkaisu. Tämä on nykyään enemmänkin sääntö kuin poikkeus. Etenkin silloin kun a.) halutaan tarjota käyttäjille parasta ja b.) käyttötapaukset ja käyttäjäroolit eroavat selkeästi toisistaan.

Vaikka visualisointityövälineellä (esim. Tableau tai QlikSense) on kiva kikkailla ja käyttö on pelkkää hattaransyöntiä, ei se sovi kaikille käyttäjille. On paljon käyttäjiä jotka eivät halua/tarvitse mennä porautumaan tietoon ja joiden ei tarvitse nähdä nättiä käppyrää. Toisin sanoen on sellaisia käyttäjiä joiden pitää tehdä oikeita töitäkin ja kriittisimmät luvut pitää saada käyttöön muuta kautta.

Esimerkiksi jos käyttäjien tarpeena on vakioraportointi tai vaikka raporttien helppo jakelu monipuolisessa formaatissa (pdf, html, xls) burstaten sähköpostitse tai levyn kulmalle huolehtien rivitason tietosuojauksesta, ei tähän kannata tarjota Qlikiä, Tableauta tai PowerBI:tä.

Toisaalta jos puntarissa painaa etunenässä ostamisen helppous, helppo käyttöönotto, toteutuksen ja käytön nopeus, IT:n tehtävien minimoiminen, käyttömukavuus ja visuaalisuus, niin edelleenkään isot perinteiset BI-toimijat eivät yllä tässä Tableaun tai Qlikin tasolle. Visualisointia ja data discovery -ominaisuuksia tarjoavat kaikki mutta muissa ominaisuuksissa (esim. ostamisen ja käyttöönoton helppous, hinnoittelun selkeys, IT:n pieni merkitys jne.) tulee suuria eroja.

Jos et usko, tee testi. Käy ottamassa netistä Tableaun serveri + client ilmaiseen koekäyttöön. Saat serverin pystyyn ja ensimmäiset raportit julkaistua tunnissa. Kokeile samaa Cognoksella, SAP:lla tai vaikka Oraclella. Ensimmäisessä tunnissa löydät ehkä myynnin puhelinnumeron jenkkeihin.

Alla kuvassa on hyvin karkea yleistys eri käyttäjärooleista. Vasemmalla on karrikoiden se iso pomo, jota ei kikkailut kiinnosta vaan hän haluaa tulos-, tase- ja myyntiraportin määrämuotoisesti esimerkiksi kerran kuukaudessa. Myös operatiivinen toiminto, jota BI-tukee voi olla tällaista. BI-palvelu tuuppaa kaupan vihannesosastolle tiedon milloin kurkut on homeessa. Lue lisää alempana upotetusta BI:stä.

Oikealla on controller, analyytikko, assistentti, (keski) johdon edustaja joka ymmärtää datan ja sen analysoinnin päälle. Hänelle jäykät vakioraportit eivät riitä, työvälineen pitää tarjota visualisointi ja ns. data discovery -ominaisuuksia (drill up/down, slice ‘n dice, assosiatiivisuus) sekä mahdollisuus lisätä uusia tietolähteitä (ns. data mash-up).

Raportoinnin roolit Louhia

 

Kaikki isot BI-toimijat taklaa kaikki nämä käyttötapaukset ja paljon muuta. Tableau keskittyy selkeästi oikealle laidalle, jenkkituote on ääri republikaani, vasenta ei suosita juurikaan. Qlik on vahvasti oikealla mutta kurottelee vasemmistoa eli raportoinnin sosiaalidemokraatteja kohden.

Toistan vielä:

  • kyse onkin siitä, haluatko parasta vai kelpaako aika hyvä?
  • kuinka monipuoliset ja poikkeavat käyttötapaukset ja käyttäjäroolit ovat?

Jos melko hyvä kelpaa visualisointiin ja käyttötapauksia löytyy myös perinteisemmästä raportoinnista, on perinteiset toimijat hyvä vaihtoehto, saat yhdestä talosta kaikki. Varsinkin kun monessa talossa on vuosien kokemus ja hiljainen tieto tuotteista eikä tuotteiden vaatima IT-hallinta tuota tuskaa.

Jos haluat parhaan ja helppokäyttöisemmän visualisointi ja analysointituotteen, ota Tableau. Se on paras vaihtoehto ns. kakkostuotteeksi ja myös ainoaksi tuotteeksi jos käyttötapaukset liikkuvat pääosin visualisoinnissa ja itsepalvelussa.

4. Mihin näet business intelligencen käytön yrityksissä suuntautuvan noin ylipäätään?

Pari suuntausta mihin olen törmännyt:

  • käyttöliittymäsuunnittelun ja UX-osaajien käyttö raporttien toteutuksessa
  • BI:n siirtäminen lähemmäksi ja upotetuksi osaksi liiketoimintaa (ns. embedded BI)
  • BI-funktion siirtyminen IT-tuotannosta ja järjestelmäylläpidosta palveluliiketoiminnaksi

Käyn näitä lyhyesti läpi.

Käyttöliittymäsuunnittelu

Olen törmännyt kolmella asiakkaalla käyttöliittymäsuunnittelijan käyttöön BI-projekteissa ja tulos on ollut kaikissa todella hyvä.

Yhdessä casessa yritys teki tietopalvelua omille asiakkailleen, jolloin priima käytettävyys on tietenkin A ja O. Koska kyseessä on maksullinen palvelu, siis yrityksen myytävä tuote. Tällöin designia ei ehkä kannatta jättää raportoinnin juhasipilöille. He osaavat insinööritekniikan mutta toteutuksen käyttömukavuus ja ulosanti loppuasiakkaan kanssa keskustellessa ja iteroidessa voi olla vähän tönkköä.

Käyttöliittymäsuunnittelu BI:ssä ei tarkoita, että jokaista raporttia varten tilataan UX-expertti paikalle. Pitkälle päästään, että UX-expertti on mukana projektin alussa luomassa suuntaviivat, ohjesäännöt fonteille, värien käytölle, layoutille ja erilaisille painikkeille. He voivat toteuttaa esimerkiksi sen ensimmäisen raporttipohjan tai työpöydän yhdessä raporttiexpertin kanssa.

Tämän jälkeen raporttien vääntäjät voivat käyttää tätä pohjana ja tuottaa näyttäviä ja visuaalisesti yhdenmukaisia tuotoksia.

Käyttöliittymäsuunnitteluun Qlik-sovelluksissa on erikoistunut Adage. Isoimmilta konsulttitaloilta löytyy tietty omia käyttöliittymäsuunnittelijoita.

BI upotettuna lähemmäksi liiketoimintaa

Näen, että tulevaisuudessa oleelliset tiedot pitää viedä sinne missä päätöksiä tehdään, lähemmäksi tai osaksi liiketoimintaprosesseja.

Kyseessähän on kuitenkin ensisijassa päätöksenteon tukijärjestelmä. Päätöksiä harvemmin tehdään juuri siinä raportointiportaalissa vaikka ns. single-point-of-access eli tiedot yhdestä tuutista onkin tavoiteltavaa.

Tietoja tarvitaan siellä missä liiketoimintaprosessi tapahtuu. Esimerkiksi CRM:ssä, markkinoinnin automaatiossa, intranetissä, asiakaspalvelun sovelluksessa, myymälöiden osastovastaavilla liikkuessa hyllyjen välissä, varaston trukkikuskeilla tai ylimmällä johdolla golf-kentällä.

Tällöin BI:tä ei tule ajatella raportteina, visualisointeina ja työpöytinä. Käyttötapaukset ja tiedon toimitustapa on tyystin toinen. Integraatioiden määrä BI:stä muihin järjestelmiin ja päätelaitteisiin kasvaa. Tämä asettaa uusia vaatimuksia BI-ympäristön suunnitteluun ja myös softille. Enää ei riitä se, että voit upottaa Cognos-raportin Sharepointiin.

Tällöin erillisen raportointitietokannan tai tietovaraston rooli kasvaa. Integraatio järjestelmien välillä ja päätöksenteossa tarvittavan tiedon toimittaminen sinne missä sitä tarvitaan, on usein helpompaa tietovarastosta oikealla integraatiotyövälineellä (etl-sovellus), sen sijaan, että mietitään miten se Tableaun visualisointi saadaan upotettua myyntimies-mynttisen Audin äly-kojelautaan.

BI-funktio ratkomaan liiketoimintaongelmia
BI-funktio (etenkin edistyneen analytiikan avulla) pitäisi tarjota liiketoiminnalle palvelua, jonka tarkoituksena on ratkoa liiketoimintaongelmia.

Esimerkiksi:

  • Ongelma 1: tuoteryhmän X varaston kierto on liian hidas. Miten voisimme nopeuttaa kiertoa?
  • Ongelma 2: lehtimainosten vaikutus on tippunut. Miten nostaa mainosten vaikutusta myyntiin?
  • Ongelma 3: alennuskampanja meni perseelleen, tuotteita myytiin miinuskatteella. Miten löytää oikea hinta ja oikea tuote kampanjaan, jotta maksimoimme kannattavuuden?
  • Ongelma 4: työvoimakustannukset ovat liian suuret ja ylimitoitetut hiljaisina aikoina mutta ruuhka-aikaan asiakaspalvelu kärsii. Miten optimoida työvuorot kysynnän mukaan?

Näiden kysymysten vastaaminen yhdessä liiketoiminnan kanssa pitäisi olla BI-palvelutuotannon tavoite.

Nämä ovat kaikki ongelmia mitä BI+analytiikkatiimit ratkoo tänäkin päivänä. Ehkä niissä kahdessa yrityksessä Suomessa. Tämä tulee muuttumaan.

BI ei ole siis jatkossa IT:n erityinen osasto missä firman ainoa SQL:ää puhuva nörtti tekee rapsoja aina tilauksesta. Eikä se ole pelkästään liiketoiminnan itsepalvelua ja visualisointi-kikkailua.


 

Tässä oli taas vähän pitkäksi venähtänyt kooste BI-työvälinekoulutuksesta heränneistä ajatuksista.

Vuosi alkaakin olemaan sitten paketissa. Saatamme tuupata vielä yhden kirjoituksen ennen vuoden vaihdetta. Toivottavasti olet viihtynyt blogin parissa ja pysy kuulolla myös ensi vuonna. Oikein hyvää joulua ja uutta vuotta!


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.


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ä.


21.01.2015 / Ville Niemijärvi

Louhia järjestää avoimet ovet vanhalla Harmoonitehtaalla Jyväskylässä perjantaina 6.2.2015 klo 14-17. Tervetuloa!

Ohjelma:

14.00: Azure Machine Learning -esittely* (eng.). Arun Justus, Microsoft
14.30: Azure Machine Learning: Louhian analytiikkapilvi ja case asiakaspoistuma-analyysi
15-17: Vapaa tustustuminen analytiikkatuotteisiin ja -palveluihin, ständeillä ainakin:

  • Azure Machine Learning ja Microsoftin asiantuntija
  • Itsepalveluanalytiikka (self-service analytics): tule katsomaan miten QlikView:stä käsin tehdään prediktiivistä analytiikkaa kuten poistumamallinnusta tai myyntiennusteita. Propellipäitä voi kiinnostaa miten olemme integroineet Qlikin R:ään ja Azure ML:ään.
  • Asla Asuntolaskuri: miten analytiikan ja tilastotieteen avulla arvioidaan asuntojen myyntihinta. Tule arvioimaan vaikka oma kämppä. Tai käy tsekkaa palvelu täällä: www.asla.fi
  • Älykkäät suosittelualgoritmit ja hakumoottorit verkkokauppaan ja raportointiin
  • Tietovarastojen toteutuksen automatisointi metamallien avulla. Näe miten DW-toteutus tehdään 1/5 ajasta perinteiseen toteutukseen verrattuna. Odotellessa rakennamme sinulle oman DW:n.
  • Some-data osana liiketoiminnan ohjausta. Näe miten maailman suurin suomenkielinen sosiaalisen median tietokanta integroidaan osaksi liiketoiminnan ohjausta ja normaalia business intelligenceä nappia painamalla. Haemme myyntitoteuman rinnalle minkä tahansa tuotteen tai brändin lähes kaikki maailman some-keskustelut ja maininnat sekunneissa.

Voit myös keskustella vapaasti louhialaisten kanssa, ihailla Smegiä, hodarikonettamme ja kysellä vaikka veikkausvinkkejä ammattilaisilta. Tilaisuuteen on vapaapääsy. Mukavaa jos kuitenkin ilmoittaudut (ville.niemijarvi@louhia.fi) niin tiedämme hankkia sinullekin Bollingeria. Tervetuloa!

*Introduction to Microsoft Azure Machine Learning and Use Cases (20-30 minutes)

Abstract: Microsoft’s vision with Azure Machine Learning is to make machine learning accessible to every enterprise, data scientist, developer, information worker, consumer, and device anywhere in the world. Customers and partners can now offer premium SaaS applications that leverage the Azure Machine Learning platform.

This is achieved through the following offerings within Azure Machine Learning:

  • Machine Learning Studio: an easy to use browser-based solution for rapid building and experimenting with predictive models.
  • Machine Learning Algorithms – best in class Algorithms and models enhanced by Microsoft research for internal projects
  • Machine Learning Operationalization: a cloud service that can host a massive selection of intelligent web services, automatically scaling. You can put any machine learning model into production by a single click.
  • Azure Machine Learning Marketplace: a marketplace/appstore for intelligent web services where an external customer can come and consume web service applications that are relevant to their business.

This session will introduce Azure ML as a product and focus on its features, functionalities and typical use cases.