20.02.2018 / Ville Niemijärvi

Meidän blogissa on ollut melkoista radiohiljaisuutta.

Kaverit ovat olleet rintamalla, pari soluttautunut syvälle vihol… asiakkaan organisaatioon. On tehty onneksi tilalle pätevämpiä rekryjä ja se yksi markkinointiosaston hörhö on kadonnut startup-maailmaan.

Nyt se on kuitenkin raahattu autotallista toimistoon tekemään jotain osakkuutensa eteen.

Markkinointiin saatiin myös uutta verta kun Jyväskylän toimistolla aloitti Tia.

Nyt lähdetään yhdessä Tian kanssa piristämään meidän (sisältö)markkinointia ja somepresenssiä. Tavoitteena on alkaa taas säännöllisesti tuottamaan blogeja, vlogeja mutta myös podcasteja. 

Lisäksi tekemään asiantuntijoiden haastatteluja, niin omien kuin vieraiden.

Aiheina koneoppiminen, tiedolla johtaminen, digitalisaatio laajemminkin.

Tietovarastoinnit ja business intelligence on jäänyt meillä vähemmälle. Näitäkin käsitellään mutta vain silloin kun tavoitteena on nuo edellä mainitut.

Mitä sisältöä odottaisit Louhian blogissa/vlogissa/podcastissa?

Kysymys meidän blogin seuraajille: minkälaista sisältöä ja mitä aihealueita toivoisit kuulevan? Kun haastatellaan meidän omia osaajia tai jutellaan alan muille asiantuntijoille.

Kiinnostaisiko esimerkiksi, jokin näistä:

  • algoritmien eroista ja vahvuuksista
  • työvälineiden, kielien ja alustojen eroista ja vahvuuksista (esim. R vs Python)
  • how-to-do esimerkkejä eli rautalankamalli esim. hinnoittelun optimointiin tai kysynnän ennustamiseen
  • bloopers eli miten hommat ei suju kuin strömsöössä
  • business case-esimerkkejä meiltä ja maailmalta
  • arkkitehtuureista
  • vaadittavasta osaamisesta, data scientistien rekrytoinneista ja osaamisen kasvattamisesta
  • miten yritys X on päässyt digitalisaatiossa pisteestä X pisteeseen Y (tai luonut uuden dataan pohjautuvan liiketoimintamallin)
  • strategiatason humppaa
  • jotain muuta, mitä?

Vaiko ylätason diipadaapaa miten tekoäly pelastaa kaikki ja olet kusessa jos et jo maksa konsulttiarmeijalle siitä, että se kertoo sinulle itsestään selvyyksiä tietämättä miten niitä juttuja oikeasti tehdään?

Kerro, kommentoi, pistä mailia. Olisi hienoa tuottaa sellaista sisältöä jota oikeasti halutaan kuulla ja josta on teille arvoa.

Nyt palautetaan kuitenkin Louhian blogiin ja muihin kanaviin hieman vipinää pyttyyn. Monikanavaisesti, säännöllisesti ja jos autatte meitä kommentoimalla, niin myös lukijoille arvoa tuottavasti.

Koska tässä kirjoituksessa on ollut pari sotaista kielikuvaa, otetaan vielä lainaus Winston Churchillin kuuluisasta puheesta, jossa hän puhuu juuri monikanavaisesta markkinoinnista.

“We shall go on to the end. We shall fight in France, we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air…

We shall defend our Island, whatever the cost may be; we shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender…”


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

 


12.04.2017 / Ville Niemijärvi

Monet yritykset rekrytoivat data scientistejä ja analyytikkoja. Neuroverkkovelhoja ja deep learning -osaajia.

Mutta mitä konkreettista osaamista rekryltä pitäisi tällöin odottaa?

Tai mitä osaamista vastavalmistuneen, esimerkiksi tilastotieteen opiskelijan kannattaisi kehittää, voidakseen siirtyä työskentelemään data sciencen ja edistyneen analytiikan parissa?

Haastattelin Louhian data scientistejä, joilla on kymmenien ja taas kymmenien toteutusprojektien kokemus ja jotka myös kouluttavat suomalaisista uusia datatieteilijöitä.

Voit katsoa haastattelun tästä tai tämän kirjoituksen alta.

Käydään tässä läpi haastattelun keskeisimmät pointit.

Data Scientistin tärkeimmät taidot

Louhialla 5 vuotta työskennellyt, yksi maan kovimmista edistyneen analytiikan osaajista, Lasse Liukkonen yllättää hieman tiivistäessään osaamisvaatimukset:

  1. Tietokannat ja SQL
  2. Rajapinnat ja integraatiot (ns. ETL-osaaminen)
  3. Mallintaminen, sisältäen sekä
    1. tiedon mallintamisen että
    2. tilastollisen mallintamisen ja algoritmit

Haastattelussa Lasse tuo esille, että periaatteessa data scientistin työhön voi edetä, ilman tilastotieteen koulutusta. Lisäten kuitenkin, että haastavimmissa tapauksissa pitää kääntyä ammattilaisen puoleen. Tosin ilman osaamista haastavan keissin itsenäinen identifiointi voi olla vaikeaa.

Vastauksessa näkyy ehkä se, että Lasselle tupla-laudatur-maisterina (tilastotiede+matematiikka) ja erittäin kokeneena analyytikkona tilastollinen mallintaminen ja algoritmiosaaminen on ns. peruskauraa.

Useissa projekteissa Lassen kanssa mukana olleena, uskallan väittää että aika monelta IT/Controller/Business Intelligence -jantterilta putoisi hanskat alkumetreiltä jos törmäisi niihin mallinnuskeikkoihin mitä olemme tehneet.

Kun tehdään ennusteita liittyen ihmisten terveyteen ja turvallisuuteen, miljoonien eurojen tarjouskauppoihin tai ministeritasolta tulee mahtikäsky tehdä ennustemalli aiheesta X ja aikaa on 24h, itse ainakin haluan että taustalla on järeää tilastotieteen osaamista.

Mutta totta on, että suurin osa käytetystä ajasta menee tiedon muokkaamiseen, sen poimimiseen, siistimiseen, tutkimiseen ja datan kanssa puljaamiseen.

Itse algoritmien kanssa työskentelyyn, R tai Python koodaamiseen kuluu huomattavasti vähemmän aikaa.

Olli Leppänen, Louhian data scientist, nostaakin SQL:n eniten käytetyksi työvälineeksi.

Ja näitä taitoja ei juuri yliopistossa opeteta. Eli vinkiksi tilastotieteen opiskelijoille: täydentäkää tilastotieteen osaamista etenkin tietokannoilla (relaatio + nosql) ja SQL-kielellä.

Alan konkari, edistynyttä analytiikka jo yli 20 vuotta sitten ensimmäisen kerran tehnyt, Mika Laukkanen, täydentää vielä osaamisvaatimuksia:

  • (Liiketoiminta)ongelman ja datan välisen yhteyden ymmärtäminen. Kyky hahmottaa miten ja millaisen datan avulla ongelma voidaan ratkaista.
  • Mallinnus- ja menetelmäosaaminen (koneoppiminen, tilastotiede).
  • Käsien päällä istuminen. Etenkin kun tulee (odottamattomia) huipputuloksia, niin kannattaa tarkistaa datasettien sisältö sekä muodostus ja mallinnusprosessit n-kertaa, koska kyseessä voi hyvinkin olla tekemiseen liittyvä virhe (nimim. kokemusta on).

Huomasin vasta tänään, että Ari Hovilla on tarjolla “Data Scientist koulutusohjelma”. Sen ohjelma tukee hyvin edellä listattuja osaamisvaatimuksia.

Mukana on R:n ja machine learning -algoritmien lisäksi niin SQL:ää, liiketoimintatiedon mallintamista (data modeling) kuin Hadoopia.

Katso Louhian data scientistien haastattelu ja Louhian vlogin ensimmäinen osa alta.