7.06.2018 / Lasse Ruokolainen

Kun toimarimme Mika Laukkanen alkuvuodesta alkoi vihjailla osallistumisesta Bilot:in järjestämään hackathoniin, en oikein tiennyt mitä tästä olisi pitänyt ajatella. Eihän tällaisella (entisellä) pitkän linjan akateemisella tutkijalla ollut mitään hajua koko käsitteestä.
Tiedossa oli kuulemma erinäisten asiakkaiden sparraamista AI:n saralla – vieläpä suurelta osin omalla ajalla, joten suhtauduin ajatukseen, sanotaanko, melko avoimesti.

 

Kahden vuorokauden uneton rutistus, pitsa- ja kokispalkalla…

Kun häkki sitten polkaistiin käyntiin huhtikuun alkupuolella, oli kuvio ehtinyt jo kirkastua melkoisesti. Etenkin, kun pääsin osallistumaan häkkiin osallistuvien asiakkaiden potentiaalisten bisnesongelmien ennakkokartoitukseen.

Kyseessä oli huolella järjestetty, kahden kuukauden häkki, jossa ratkottiin koneoppimisen ja tekoälyn turvin Reiman, Altian, Raision ja KONEen liiketoimintaongelmia. Kisaan lähdettiin Bilotin konsulteista ja Louhian Data Science -tiimin jäsenistä kootuin joukkuein.
Itse osallistuin KONEen ja Raision joukkueisiin.

Hissi

 

 

 

Kuten arvata saattaa, tavoitteet olivat melko erilaiset – toisessa keississä keskityttiin hisseihin ja toisessa maidontuotantoon. Tämä tarjosi, ainakin allekirjoittaneelle, kaksi erilaista oppimiskokemusta.

 

 

 

Se tuskin on kenellekään yllätys, että suurimmat haasteet liittyivät näissäkin projekteissa dataan.
Ei niin että se olisi ollut huonoa, mutta datan hankkimiseen, yhdistelyyn ja muokkaamiseen saatiin taas kulumaan leijonan osa häkkiin uponneista työtunneista. Loput ajasta käytettiin analytiikan hiomiseen ja varsinkin käyttöliittymien kehittämiseen; kysehän oli kuitenkin ennen kaikkea tekoälyratkaisuista, ei pelkästä analytiikasta.

 

… vai lähdetäänkö Piilaaksoon?

Lopulta, tämän viikon tiistaina, koitti suuri päivä, jolloin asiantunteva, ulkopuolinen tuomaristo laittoi häkin lopputulokset Voittoparemmuusjärjestykseen.

Hienojen esittelyiden jälkeen saatoin joukkuetovereineni jopa hieman hymyillä, kun team-Raisio julistettiin voittajaksi.

Kaikki joukkueet pystyivät osoittamaan itselleen ja asiakkaille, että lyhyessäkin ajassa voidaan saada aikaan melko päräyttäviä ratkaisuja. Tämä olikin tässä häkissä mainetta ja kunniaa (hienoja palkintoja unohtamatta) tärkeämpää.
Näille ratkaisuille voidaan osoittaa konkreettisia ja merkittäviä liiketoimintahyötyjä!

Saavutettu lopputulos oli varmasti vasta alku, jonka pohjalta voidaan tulevaisuudessa kehittää todellisia tuotantoratkaisuja.

Lopetan pariin melko kulahtaneeseen fraasiin. Minusta tuntuu, että aletaan jo melko hyvin ymmärtää, että: don’t underestimate the power of data science. Tämän harjoituksen perusteella olen myös vahvasti sitä mieltä, että parempi data-ukko (tai akka) häkissä kuin yksin kotona koodia vääntämässä.

 

Lue lisää Bilotin Mathias Hjeltin blogi Hackathoneista ja pistä 29.8 kalenteriin – pääset kuulemaan lisää hackatonista Dixital X -tapahtumassa.


21.03.2018 / Nanni Koski

Lyhenteiden viidakossa kehitin itselleni muistukseksi uuden: DBD. Mistä tämä sitten on lyhennys? Käydään ensin katsomassa Googlesta, jos satuttiin osumaan johonkin nuorison käyttämään hypetermiin. Itse asiassa Urban Dictionaryn kaksi ylintä termiä sopii teemaan, joten pidetään vielä jännitystä yllä.

 DBD = ”Damn, bro, damn”

Yleensä käytetty ilmaisemaan ilmeisesti vaikuttuneisuutta, mutta tässä tapauksessa toi mieleeni päivän, joka tuntui data scientistin painajaiselta. Olen erityisen ihastunut kreikkalaisiin aakkosiin, joten otetaan ne mukaan selventämään tilannetta. Eli latinalaiset aakkoset viittaavat tunnettuihin asioihin ja kreikkalaiset johonkin tuntemattomaan, mikä ei suorilta ole selvää. Sanottakoon, että projektin vetohahmo sattui olemaan tänä päivänä lomalla, mikä lisäsi tulevan tehtävän haastetta.

Tehtävä: Asiakas A lähettää Excel-tiedoston B, jonka välilehdistä osalla, merkitään [math] \alpha_1, \ldots, \alpha_\beta [/math]  on tietoja, jotka tulee päivittää tiedostoon / tiedostoihin [math] \gamma_1, \ldots, \gamma_\delta [/math] kansiossa [math] \varepsilon [/math] palvelimella [math] \zeta [/math] ja sen jälkeen ajaa tauluihin [math] \eta_1, \ldots, \eta_\theta [/math] kannassa [math] \iota [/math] latauksilla [math] \kappa_1, \ldots, \kappa_\lambda [/math].

Juuri niin helppoa kuin se ääneen luettuna kuulostaa olevan.

Vaikea palapeli

Ehkä tunnin työ, jos kreikkalaisten aakkosten merkitys tässä kontekstissa on tuttu. Jos selvittäminen vaatii valistuneita arvauksia, niin tällaista ongelmaa ei ratkaista googlettamalla.

Tästä päästään sanakirjan seuraavaan ehdotukseen:

DBD = ”Don’t be Dumb”

Sanonnan kirjaimellinen käännös sopii aiheeseen paremmin kuin tarkoitettu ”Don’t worry”. Eli älä ole typerä – dokumentoi tekemisesi.

Mitä uusia muuttujia dataan luotiin, miksi ja millä tavalla? Rajattiinko osa havainnoista tarkastelun ulkopuolelle? Toki osa asioista on haastavampia dokumentoida. Ja joskus vasta kokeilut osoittavat, mikä toimii ja mikä ei. Ja kyllähän sen muistaa, miksi koodi meni näin ja missä järjestyksessä eri tiedostot tulee ajaa. Se on selvää, että tämä koodi löytyy täältä kansioista. Ja tuo tiedosto valitaan tässä tietyssä tilanteessa. Ja se päivitettävä osio koodissa on juuri tuo. Ja että jos haluaa saada aikaan tämän, niin käy muuttamassa tuolla valikossa arvoja. Niin ja muuttujien datatyyppien muunnokset pitää ottaa huomioon. Mutta sehän on selvää tulevan virheilmoituksen perusteella, jos sen sattuu saamaan. Eikö vaan?

Liian monta sekavaa ohjetta

No ei.

Miksi, mitä, miten ja mihin siis dokumentoida? Ja se tärkein eli:

Kuka? Sinä, juuri sinä. Just do it.

Mitä? Ajatukset ja toteutukset projektiin liittyen.

Miksi? Asiantuntemus. Muistipaikkojen vapauttaminen omasta päästä. Lähimmäisenrakkaus. Sharing is caring. Ja ehkä silloin saa viettää jonkun lomapäivän tarvitsematta vastata yhteenkään työpuheluun.

Miten? Tiimin / Asiakkaan saataville. Vaikka Wordillä, PowerPointilla, Notepadilla, R Markdownilla tai Trelloon.

Mihin? Dokumentoinnista ei ole hyötyä, jos sitä tarvitseva ei sitä löydä. Eli varmista, että tiimille on selvää, mistä työsi hedelmät on poimittavissa muidenkin iloksi.

Ehkä suurin ongelma dokumentoinnissa on kuitenkin se, kun into lähtee lapasesta ja perille pääsee nopeammin raskaalla kaasujalalla kuin jokaisen taukopaikan kautta. Kun tässä eräänä päivänä lisäilin koodin joukkoon jälkikäteen selityksiä siitä, miksi olin muokannut dataa esitetyllä tavalla, totesin, että eipä olisi ollut suuri vaiva kirjoittaa ne jo tehdessä.

DBD = ”Document before Doing”

Tästä eteenpäin pyrin seuraavaan: Sunnittele – kirjoita ylös – tee – vaikutu tuloksista tai yritä uudestaan. Sitä tarkoittaa minun DBD. Ihan aina ei (ehkä) ole mahdollista kirjoittaa suunnitelmia ja toteutuksia ylös ennen tekemistä.  Ja joskus on hyvä työskennellä flown mukana. Mutta tavoitteena on selvät ohjeet tai muistiinpanot edes kaikesta lopputuloksen kannalta oleellisesta tai toimivan tuotteen toiminnasta. Ehkä sitten pääsee käyttämään ensimmäistä fraasia alkuperäisessä tarkoituksessa.

Suuri vaikuttuneisuuden huudahdus: Wow!

Pahimmassa tapauksessa dokumentoinnin puuttuminen aiheuttaa moninkertaisen työn siihen vaivaan verrattuna, että asiat voi käydä tarkistamassa jostain. Datamuokkauksien tekeminen uudelle dataversiolle ajamalla siistit koodit läpi mahdollistaa useamman päivän työn tekemisen muutamassa minuutissa.

Mielelläni kuulisin lukijoiden kokemuksia toimivasta tai ei niin toimivasta dokumentoinnista. Tai jäikö jotain oleellista puuttumaan?

Tästä on hyvä siirtyä kahden viikon lomalle. Toivottavasti kaikki tieto on saatu välitettyä työkavereiden ulottuville ja löydettäväksi eivätkä päivät kaadu piilotteleviin dokumentaatioihin. Tai siihen minulle ihan itsestään selvään asiaan. Bye!


22.12.2017 / Mika Laukkanen

On vuosi 2021 ja kävimme Korvatunturilla kysymässä, että miten tekoäly ja digitalisaatio on näkynyt arjessa. Tapaamiset luonnollisesti järjestyivät Tonttu-botin avustuksella, joka muuten osaa kommunikoida myös ruotsiksi. Tässä parhaita kommentteja koostetusti.

Asiakasmuotoilu-Tonttu

”Tänä päivänä toiminnan ytimessä on asiakaskokemus, joka on noussut Korvatunturilla strategiseksi arvoksi ja toimintaa ohjaavaksi tekijäksi. Katsos, olemme sellainen asiakkaan digitaalinen matkakumppani ja opas. Ja me palvellaan asiakasta koko elinkaaren ajan – aina helistimestä rollaattoriin saakka. Niin ja se asiakaskokemuksen mittaaminen ohjaa ihan kaikkea toimintaa täällä.. ja se onkin helppoa, koska dataa riittää.”

”… meidän Deep Santa -tekoäly on auttaa tietämään asiakkaasta lähes kaiken. Usein ennen kuin asiakas itsekään tietää ja paremmin. Ihan huippua. Keräämme dataa mm. netti- ja puhelinseurannalla, web-kameroilla, lennokeilla ja leluihin upotetuilla siruilla sekä antureilla. Deep Santa pystyykin jo syyskuussa ennustamaan mitä kukin haluaa ja tarvitsee lahjaksi. Tyytyväisyys lahjoihin onkin noussut huimasti.. etenkin vaimojen osalta, jotka eivät enää saa joka kodin silityskeskuksia romanttiseksi lahjaksi. Eikä kenenkään tarvitse kirjoitella kömpelöitä kirjeitä pukille, joskin niitäkin otetaan vielä vastaan, jotka ohjelmistorobotit lukevat ja arkistoivat.”

Tuotanto-Tonttu

”Eipä tässä ole valittamista, kun nuo robo-tontut jaksaa painaa 24/7 linjalla narisematta työoloista tai siitä, että riisipuuroa on aina lounaaksi, pipareita välipalaksi ja laatikoita illallisella. Eivätkä ne tee juurikaan virheitä… ellei lasketa pattereiden loppumisesta johtuneita sammahduksia. Automatisaation ja ohjelmistorobotiikan ansiosta tuotantomäärät ovat nousseet huimasti, koska maailman väkiluku kasvaa ja kaikki haluavat joululahjoja vuosi vuodelta enemmän. Mistähän sekin johtuu?”

“.. toisaalta tämä on vain väliaikaisratkaisu, sillä vuonna 2026 kaikki lahjat tulostetaan omilla 3D-tulostimilla. Ne ovat jo pilottikäytössä.”

Turvallisuus-Tonttu

”Mielestäni koko internetti ja muut höpötykset pitäisi kieltää. Ennen asiat olivat paremmin. Tämä nykymeno tietää tuhoa. Hamstratkaa säilykkeitä ja pattereita.”

Talous-Tonttu

”Aiemmin Korvatunturin toiminta rahoitettiin kullan louhimisella. Nyt louhitaan Bitcoineja ja muita kryptovaluuttoja. Jos niitä jää yli, niin ne kelpaavat myös lahjaksi. Joskin verottajan suhtatuminen on vielä hieman avoinna. Mutta kokonaisuutena all good.”

Tonttu-Duuniton

”Huokaus.. tilastojen mukaan suurin osa tontuista on nyt työttömiä tai tempputyöllistettyjä. Vaikka täällä on aktiviteetteja, ilmainen ylläpito, kansalaistonttupalkka ja osaamisen päivityskursseja, niin eihän ne korvaa oikeaa työtä. Moni miettiikin muuttamista esim. Kajaaniin työn perässä. Jopa LinkedIn profiileita on perustettu. Ja onhan tässä näitä lieveilmiöitäkin ollut.. joillakin tontuilla on lähtenyt ns. poro keulimaan. Etenkin yhdellä Hakkaraisella.”

Duunari-Tontut

”..huikeeta.. vuosisatojen yksipuolinen, tylsä ja mediassa yliromantisoitu liukuhihnatyö on vaihtunut mielekkäämpiin hommiin… kuten Python koodaukseen ja Deep Santan neuroverkkoparametrien optimointiin. Näissä kuluu parisen tuntia päivässä… usein vähemmän. Sitä jos liikaa yrittää, niin siitä tulee stressiä ja paha mieli.”

”.. ja olihan se ikkunoista kurkkiminen vähän semmoista hommaa. Paleltumat, kehnot säät ja vihaiset koirat olivat yleinen riesa. Puhumattakaan aikuisista. Kun siinä yritti kylmissään katsella jäisen ikkunan lävitse ja tehdä memoa, niin yhtäkkiä huuto ’katsokaa lapset tonttua ikkunassa!! ’. Ei helvata.. juokse siinä pakoon umpihangessa minkä tonttujaloilla ehtii. Oli ne aikoja.. tosin silloin oli luntakin, toisin kuin nyt. ”

”.. nythän me kaikki ollaan ihan fiiliksissä ja meillä on säkkituolit..”

Entä mitä Joulupukki toivoo joululahjaksi?

”.. lohkoketjua, viimeinkin. Ja hyvää Joulumieltä kaikille!


3.11.2016 / Jani Liimatta

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

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

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

Esimerkki: kenkätehtaan budjetointihaasteet.

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

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

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

 

 

 

 

 

 

 

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

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

rlogo

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

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

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

Graafi

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

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

 

 

 

 


13.10.2016 / Juha Kostamo

Lauleskelee Hanna Ekola jo legendaariseksi viisuksi muodostuneessa kipaleessaan, josta on muuten Vesterinen Yhtyeineen tehnyt ihan mainion version.

Reilun kuukauden Louhia kokemuksen jälkeen muotoilisin kysymyksen tiedolla johtamisen maailmaan sopivaksi eli Vieläkö on tietovarastoja?

Vastaus on, että kyllä on ja niitä rakennetaan koko ajan lisää – fiksusti (ei siis 3 v, 3 miljoonaa ja lopputuloksena kasa tauluja, jotka eivät enää vastaa mihinkään valmistumishetken liiketoimintakysymykseen). Tietovarastointi ei tosiaankaan ole kuollut, päinvastoin. Tarve laittaa nykyinen tietopääoma järjestykseen ja mahdollistaa uusien tietolähteiden joustava tuominen tiedolla johtamisen piiriin kasvaa päivä päivältä. Klassinen talon rakennus vertaus: kannattaako talon perustusten rakentaminen tehdä helpoimman kautta ja luottaa siihen, että talon 2.kerroksen lattia kantaa ja seinät pysyvät pystyssä tai vielä suoraviivaisemmin toimien kannattaako talon rakennus aloittaa suoraan 2. kerroksesta? No ei kannata.

Aika monella ihmisellä on visuaalista silmää, tätä silmää  miellyttämään on tarjolla toinen toistaan näyttävämpiä ja käyttökokemukseltaan hyviä analytiikkaratkaisuja. Visuaalisuus ja käyttöönoton näennäinen helppous houkuttelee menemään helpoimman kautta. Jonkin aikaa kaikki onkin hyvin, mutta jossain vaiheessa alkaa lattia kallistua ja seinät halkeilla. Tiedolla johtamisen Spagetti Bolognese on valmis.

Tietovarastoinnin etuja on monia. Yksi yhteinen totuus lienee se yleisimmin tunnistettu –  keskitetty, harmonisoitu ja luotettava tieto johtamisen tueksi. Tietovarastointi mahdollistaa kokonaiskuvan saamisen yrityksen toiminnasta ja mahdollistaa niin alakerran tapettien (lähdejärjestelmät) kuin yläkerran kylppärin kaakelien (raportointijärjestelmien) vaihtamisen hallitusti – tiedot ovat tallessa.

Itselläni on tällä hetkellä olo kuin Väyrysellä, takki on kääntynyt. Vielä pari vuotta sitten olin melko voimakkaasti sitä mieltä, että tietovarastointiin käytetylle rahalle ja ajalle olisi parempiakin sijoituskohteita. Tähän on saattanut hieman vaikuttaa näkemäni huonot tietovarastohankkeet (maksaa, ei valmistu…). Näin ei kuitenkaan tarvitse enää olla. Tietovarastollakin tulee olla hyvä ROI ja sen pitää pystyä mukautumaan tulevaisuuden muutoksiin toimintaympäristössä. Data Vault voi olla yksi hyvä vaihtoehto toteutustavaksi.

 Long live tietovarastointi!

PS: Louhialta saa muuten hyviä palveluja tietovarastoinnin kehittämiseen (auditointia, määrittelyä ja rakentamista) eli kannattaa tsekata http://www.louhia.fi/palvelut/bidw-ratkaisut/


7.10.2016 / Mika Aho

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

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

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

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

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

Q3-osavuosikatsaukset

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

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

Vai onko riski kuitenkin talon sisällä?

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

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

Pitäisikö asialle tehdä jotain?

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

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

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


29.09.2016 / Ville Niemijärvi

Järjestin pari vuotta sitten asiakkaalle business intelligence -työvälineen kilpailutusta. Olin hankintakonsultti ja muun RFP-materiaalin ja esiselvityksen ohella hoidin kommunikoinnin toimittajien suuntaan.

Eräs BI-talon myyjä oli poikkeuksellisen aktiivinen minua kohtaan. Puhelin soi taukoamatta. Kysymykset oli hyvin suoria: ketä on mukana pelissä, onko se ja se toimittaja, mitä asiakas painottaa, mikä on budjetti, ketä pitää panna…?

 Oudoksi tilanne meni kun myyjä ehdotti minulle vähän kiertäen ja kaartaen:

Jos meidän tuote valitaan asiakkaalle, voitaisiin me järjestää jonkinlainen ulkomaan matka sulle.

Mitä ihmettä? Tällaistako on kun joku lahjoo sinua?

Hän pehmensi selvää lahjontayritystä heti perään puhumalla jotakin kumppanuusohjelmasta ja niin edespäin.

Kerroin asiasta asiakkaalleni. Heidän johtoryhmä nauroi asialle ja totesivat ihan oikein, että heitähän tässä pitäisi lahjoa eikä minua. Lopulta hankinta hoidettiin tyylipuhtaasti maaliin ja ulkomaan reissut on senkin jälkeen tehty omalla rahalla.

Eihän tämä ensimmäinen kerta ollut kun vastaavaan törmäsi. Pari työpaikkaa takaperin muistan kuinka todella isossa julkisen puolen tietovarastoprojektissa silloisen firmani toimari vei vastapuolen toimarin golffaamaan Espanjan aurinkorannikolle. Kuulemma ”seminaarimatka”. Maan tapa.

En tiedä minkälaiset provikat BI-softamyyjät saavat mutta sen tiedän, että

a.) ne eivät ole niin isot, että oma maine ja vapaus kannattaa riskeerata hölmöilemällä ja

b.) puheet Suomesta täysin puhtoisena korruptiovapaana maana ovat höpöhöpöä.

Tykkään käyttää blogeissani aina silloin tällöin musiikkivideoita kuvaamaan tunnelmaa. Jotenkin MC Hammerin ”U can’t touch me” ei sovellu tähän fiilikseen. Ehkä Ennio Morricone toimii paremmin?

 

 


17.08.2016 / Ville Niemijärvi

IT-toimittajat. Kun asiakas on tuttavallinen ja vähän epäformaalisti kutsuu teitä ”vaan juttelemaan” tai lähettämään keskustelun jälkeen ”ihan vaan jonkin etenemisehdotuksen”, niin olkaa varuillanne.

Älkää koskaan kuvitelko, että kyse olisi vain juttelusta tai vain etenemisehdotuksesta. Astutte miinaan.

Oikeasti he tarkoittavat, että:

  • tule juttelemaan = tule myyntikäynnille ja näytä kyntesi. Esittele tarjontasi ja hurmaa meidät. Myy meille ja myykin kunnolla sillä toista kertaa ei tule.
  • heitä jokin etenemisehdotus = meillä on tarjouskilpailu menossa ja pyydämme tarjoukset 10 muulta toimittajalta. Tarjoukset arvioi koko henkilöstömme ja toimitusjohtaja tekee päätöksen. Laita hiton hyvä tarjous tulemaan.

Joskus aikoinaan menimme vipuun ja tuttavallisen ”heitä pari ranskalaista viivaa miten tästä eteenpäin” pyynnön jälkeen lähetimme tosiaan maililla pari ranskalaista viivaa. Oli sanomattakin selvää, että homma jäi siihen.

Sillä kannattaa muistaa, että se kuka tarjouksen pyytää, ei useinkaan ole se kuka päätöksen tekee.

Jos kaverisi pyytää tarjousta, saattaa olla että hänelle riittää ne parit ranskalaiset viivat. Mutta hänen pomonsa ei tunne sinua. Kun hänelle forwardoidaan huoleton emailisi, voit olla varma että ammattimainen, formaali, asiapitoinen oikea Tarjous voittaa kisan.

Tästä syystä tätä nykyä tulkitsemme kaikki ”etenemisehdotukset” tarjouspyynnöiksi ja ”tule juttelemaan” kutsut myyntikäynneiksi. Tästä syystä jokaiseen pyyntöön vastataan niin hyvällä tarjouksella kuin ikinä vain osaammekaan. Tästä syystä jokaisen tarjouksen käy läpi minimissään 2 henkilöä, joskus koko firma.  Luonnollisesti tarjouspohjat on hiottu ja sisältö on timanttia.

Silti ennen kesälomia tuli vedettyä yksi huonoimmista myyntikäynneistä. Astuin ”tule juttelemaan” miinaan. Vieläkin hävettää. Siitä joku toinen päivä lisää.


16.05.2016 / Lasse Liukkonen

Viime kirjoituksessa käytiin läpi IBM Watson analytics-palvelun käyttökokemuksia ja oleellisia toiminnallisuuksia. Kuten kirjoituksessa tuli luvattua, on seuraavaksi luvassa kurkistus “kilpailevaan” Microsoftin Azure ML-palveluun. Heti kättelyssä voisi kuitenkin mainita, että oikeastaan palvelut painivat eri sarjassa: Watson analytics painottuu tutkivaan aineiston analysointiin ja Azure ML puolestaan prediktiiviseen. Kirjoituksen kannalta oleellisinta onkin saada käsitys siitä miten nämä käsitteiden erot näkyvät konkreettisesti data-analyysin tekemisessä, löydöksissä ja tuloksissa.

Käydään seuraavaksi läpi Azure ML:n käyttöliittymää ja ominaisuuksia esimerkkiprosessin rakentamisen avulla, samaan tapaan kuin Watsonia tarkasteltaessa. Viime kirjoituksessa Katsaus IBM Watson Analyticsiin “uhkailtiin” Niemijärveä tulevasti taskista, hän kuitenkin joutui kieltäytymään piinapenkistä vedoten työkiireisiin, joten toteutin itse esimerkkiaineiston analysoinnin ja mallintamisen (yksinkertaisella tavalla, ikäänkuin en tuntisi aineistoa entuudestaan).

 

1) a. Miten pääsen käsiksi Azure ML-palveluun:

Käytännössä Azure ML-palvelun käyttäminen vaatii Microsoft-tilin, Azure tilauksen (subscription) ja Azure ML workspace:n luontia. Microsoft on kuitenkin luonut mahdollisuuden tutustua palveluun ilman edellä mainittujen toimenpiteiden suorittamista, Guest-tunnuksilla pystyt testaamaan palvelua 8 tunnin ajan. Jo tässä 8:ssa tunnissa pääsee melko hyvin perille palvelun monipuolisuudesta. Azure ML:ssä on myös runsaasti valmiita esimerkkejä, joista voi olla hyötyä ensimmäisillä kokeilukerroilla. Huomioi kuitenkin, että Guest-tunnuksilla joudut käyttökokemuksen osalta turvautumaan esimerkkiaineistoihin. Esimerkkiaineistot ovat suurilta osin selkeitä, joten aikaa ei liiemmin tuhriudu aineistoa ihmetellessä.

23_Azure

1) b. Azure ML-ympäristön luonti:

  • Microsoft-tilin luominen: https://signup.live.com/
  • Lyhyt opastus Azure ML-pavelun käyttöönotosta: https://azure.microsoft.com/en-us/trial/get-started-machine-learning/

Seuraavassa palvelun hinnoittelu, joka koostuu mahdollisesta workspace:n maksusta ja Azure ML:n käytöstä. Yrityskäytössä hinnat eivät todellakaan päätä huimaa…

2_Azure

 

Azure ML-palvelun käyttöönotto ei ole ydinfysiikkaa vaikka aluksi voi kuullostaa monivaiheiselta. Luomasi tilit ja tunnukset ovat likipitäen heti käytössäsi, joten pääset nopeasti käsiksi itse palveluun antiin.

 

2) Palveluun kirjautuminen ja palvelun komponentit

Sitten itse asiaan. Azure ML-palveluun voit kirjautua osoitteessa https://studio.azureml.net/. Kun olet kirjautunut palveluun sinulle pitäisi avautua seuraavan kaltainen näkymä:

24_Azure

 

Welcome-näkymässä on Watson analyticsin tapaan selkeästi ilmaistu palvelun oleellisimmat kokonaisuudet:

Experiment – Tallentamasi prosessiketjut (mallinnus, datan muokkaus, jne…)

Web services – Tallentamasi web service-prosessit (mahdollisuus kutsua esimerkiksi mallinnusprosessiketjua rajapinnan kautta)

Datasets – Tallentamasi aineistot (tai valmiina olevat esimerkkidatat)

Trained models – Tallentamasi ennustemallit

Settings – Workspacen tiedot ja tila

(Projects – Mahdollista kasata projektikohtaiset komponentit yhdeksi kokonaisuudeksi.)

 

3) Luodaan ensimmäinen prosessiketju (experiment), jossa esimerkkiaineistoa aluksi analysoidaan ja lopuksi muodostetaan ennustemalli

+ New kohdasta voit luoda tyhjän prosessiketjun: New -> Experiment -> Blank Experiment

25_Azure

26_Azure

 

Toisin kuin Watsonissa, Azure ML:ssä täytyy käyttäjän itse rakentaa ETL-prosessia muistuttava prosessiketju, jossa eri operaatioita (operaattoreita) linkitetään toisiinsa loogisessa järjestyksessä. Prosessiketjun luonti tyhjästä on kohtalaisen helppoa, jopa ensimmäisellä käyttökerralla. Drag & Drop- käyttöliittymä tekee prosessiketjun luonnista nopeaa ja mielekästä.

Muodostetaan seuraavaksi mallinnuksen prosessiketju palapalalta ja samalla tarkastellaan eri operaattoreiden käyttöä ja ominaisuuksia. Lopullisena tavoitteena on siis luoda malli esimerkkiaineistomme pohjalta, jonka ”ennustetarkkuus” päihittää Watson analyticsin luoman mallin. Lisäksi pyrimme saamaan selville mitkä tekijät (sarakkeet) vaikuttavat poistumaan (kiinnostuksen kohde aineistossa) vahvimmin. Ennustetarkkuus on laitettu lainausmerkkeihin siitä syystä, että Watsonissa ei niinkään laskettu ennustetarkkuutta vaan mallin sopivuutta aineistoon (näin ainakin voisi olettaa tuloksista päätellen).

 

a) Lähdeaineiston lukeminen:

Import Data – operaattorilla pystyt lukemaan aineistosi suoraan Azure:n data storage-lähteistä, esim. Azuren tietokannasta tai blobista (bulkkilevytilaa pilvessä). Kun Import Data-operaattori on hiirellä aktivoitu ilmestyy käyttöliittymän oikeaan reunaan valintalistoja ja muita säädettäviä parametreja. Tässä Properties-osanäkymässä määritellään tarkemmin operaattorin hienosäätöä koskevat parametrit. Säädettävien parametrien määrä vaihtelee operaattorikohtaisesti. Quick-help kohdan linkistä saat tarkempaa tietoa operaattorin käytöstä ja parametrien merkityksestä.

Import Data-operaattorin osalta valitaan esimerkissä lähteeksi Azure DB, jonka jälkeen täytetään tarvittavat tiedot: osoite, käyttäjä, salasana, SQL-kysely…

Jos kuitenkin haluat ladata palveluun lähdeaineistosi lokaalista lähteestä valitse + New -> Datasets -> from local files. Tämä lienee paras (ja ainoa) vaihtoehto ensimmäisellä käyttökerralla, varsinkin, jos muita Azure-palveluita ei ole käytössäsi.

27_Azure

 

b) Jakaumien tarkastelu, visualisoinnit

Azure ML:n omilla komponenteilla ja visualisoinnilla saa todella pintapuolisen raapaisun sarakkeiden/muuttujien jakaumista ja aineiston laadusta verrattuna Watsoniin. Azure ML:n aineiston analysointiominaisuudet eivät ole parhaat mahdolliset, huomattavasti heikommat kuin Watsonissa. Pelkästään ennustemallinnuksen kannalta lähestyttäessä kaikki oleelliset tiedot löytyvät sarakekohtaisesta metadata-näkymästä ja pienestä graafista.

28_Azure

20_Azure

 

Herää kysymys: Jos minulla on paljon sarakkeita, tarvitseeko minun yksitellen aktivoida ne Visualize-näkymässä saadakseni tarvittavat metatiedot koko aineistosta? Ei onneksi! Operaattori-valikosta löytyy Summarize Data-operaattori, jonka avulla saat hieman kattavammat metatiedot aineistostasi yhdessä näkymässä.

 

c) Sarakkeiden metadatan muokkaaminen

Kuten Watsonissa, täytyy myöskin Azure ML:ssä pitää jonkinlaista huolta sarakkeiden rooleista ja tyypeistä, ettei esimerkiksi identifioiva sarake pääse livahtamaan mukaan ei toivotussa merkityksessä. Edellä mainittuja sarakekohtaisia ominaisuuksia pystyt vaihtamaan Edit Metadata-operaattorilla.

29_Azure

 

d) Turhien sarakkeiden redusointi

Analyysin kannalta turhien sarakkeiden pois siivoaminen onnistuu Project Columns-operaattorilla. Huomioi, että esimerkkiprosessissa on poistettu sarakkeet, jotka korreloivat vahvasti keskenään, tästä syystä kuvassa näkyy myös operaattori Compute Linear Correlation, jonka avulla aineistosta lasketaan (numeerisien) sarakkeiden väliset korrelaatiokertoimet. Metadatan asettaminen vaste-muuttujan kannalta ei välttämättä ole oleellinen heti alussa, sillä mallinnusmenetelmissä tulee valita erikseen se sarake, jota halutaan ennustaa.

30_Azure

 

e) Aineiston jakaminen testi- ja opetusaineistoksi

Split Data-operaattorilla pystyt jakamaan aineiston kahteen osaan haluamallasi tavalla (mahdollisuuksia: koon, osuuksien, ehtojen… mukaan). Split Data-operaattori toimii myös yleisesti rivitason redusointi operaattorina. Monimutkaisempi rivitason redusointi voidaan toteuttaa esimerkiksi Regular Expression-option avulla (https://en.wikipedia.org/wiki/Regular_expression).

31_Azure

 

f) Mallien vertailu ja parametrien optimointi

Mallin muodostaminen ja vertaileminen on tehty todella helpoksi. Myöskään mallin hyperparametrien optimointi ei ole yhtään sen haasteellisempaa. Esimerkin prosessiketjussa käytetään hyperparametrin optimoinnissa random sweep vaihtoehtoa, joka voi olla hyödyllinen varsinkin silloin, kun tietämys mallinnusmenetelmien hyperparametrien merkityksistä on vähäistä. Random sweep ei välttämättä päädy “optimaaliseen ratkaisuun”, mutta antaa yleensä huomattavasti default-arvoisia hyperparametrisäätöjä paremmat tulokset.

 

g) Merkitsevien sarakkeiden haarukointi (Permutoimalla)

Poistumaan vaikuttavia tekijöitä (sarakkeita) voidaan selvittää mallispesifisesti Permutation Feature importance-operaattorin avulla. Huomioitavaa tässä tapauksessa on se, että merkitsevyysmittarin arvot ovat mallisidonnaisia, eli jos vaihdat mallinnusmenetelmää on odotettavissa, että merkitsevyydet voivat vaihdella (oleellista ei välttämättä ole niinkään itse lukuarvo vaan eri sarakkeiden merkitsevyyslukujen suhteelliset erot).

33_Azure

35_Azure

 

 

h) Tulosten tarkastelu

Esimerkkiaineiston tapauksessa mallinnusmenetelmä 1 antoi selkeästi paremman tarkkuuden kuin menetelmä 2, joten lopullinen mallin ennustetarkkuus laskettiin käyttäen mallinnusmenetelmä 1:stä (Boosted decision tree). Päihitimme Watsonin “ennustetarkkuudessa”, mutta hävisimme kyllä mallin tulkinnassa selkeästi (valittu mallinnusmenetelmä ei niitä tulkinnallisempia, ensemble-method).

34_Azure

 

36_Azure

Oleellinen ero Watsoniin on siinä, että Azure ML:llä voimme todella ennustaa uutta vasteen suhteen tuntematonta aineistoa, saamme siis ulos asiakaskohtaiset ennusteet. Toki Watson avulla voisimme päätöspuun säännöstön implementoida esimerkiksi Exceliin tai raportointityövälineeseen.

 

Yhteenvetoa (ja vertailua IBM Watson analyticsiin):

1) Azure ML on selkeästi prediktiiviseen analytiikkaan ja aineistojen yhdistämiseen ja muokkaukseen suunnattu palvelu, kuten edellä muodostettu esimerkkiprosessi antanee ymmärtää. Käyttäjän tulee siis tuntea vähintäänkin perusperiaatteet ennustamisesta/aineiston mallintamisesta, sekä mallinnusmenetelmistä ennen palvelun käyttöä ennustamistarkoituksessa.

2) Mikäli yritykselläsi on joku tai joitakin Azuren storage-palveluita on Azure ML järki ratkaisu ennustavan analytiikan työvälineeksi.

3) Azure ML:n omilla operaattoreilla pääsee melko pitkälle mallintamisessa ja tarvittaessa voi turvautua myöskin R:n apuun palvelun sisällä (esimerkiksi aikasarja-analyysi)

4) Azure ML ei ole paras mahdollinen väline aineistojen visualisointiin ja tutkimiseen (jos et ole sinut R-ohjelman ja sen visualisointi-pakettien kanssa)

5) Azure ML oppimiskynnys on hyvin matala ja käyttöliittymä on enemmän tai vähemmän identtinen esimerkiksi Rapidminerin, SSPS Modellerin kanssa, oppimiskynnys on siis hyvin matala

6) Prosessiketjun suorittaminen (ajoaika) kestää välillä turhankin kauan, vaikka tehtäisiin vain yksinkertaisia toimenpiteitä (usein tyypillistä pilvipalveluille). Tämä seikka voi hieman nakertaa alkuvaiheessa, on siis ihan järkevää suunnittella vähintäänkin mielikuvaharjoitteena alustava prosessiketjun kulku ennen toteuttamista.

7) Web servicen rakentamista ei käyty läpi tässä kirjoituksessa, mutta se on pakko nostaa esille tässä yhteenvedossa erittäin positiviisena asiana. Web servicen julkaisu on erittäin helppo toteuttaa Azure ML:ssä, tarvitsee käytännössä asettaa prosessiketjun aineistolähde web servicen inputuksi ja tulostaulu outputiksi. Lisäksi annetaan skriptin pätkät, joilla voidaan web serviceä kutsua esimerkiksi R:llä tai Pythonilla.

 

IBM Watson Analytics                                                Azure ML

37_Azure_Watson

 

Lyhyesti voisi siis tiivistää, että Watson on business-käyttäjän työväline (ei data-analyytikko) ja Azure ML data-analyytikon. Itse käyttäisin molempia, analyysin alkuvaiheessa Watson, lopullisen ratkaisun implementointi ja hienosäätö Azure ML:ssä!