27.05.2019 / Mika Laukkanen

Heti aluksi on mainittava, että tämä blogi on kohdistettu pääasiassa henkilöille, joilla on liittymäpintaa Business Intelligence ratkaisuihin ja nyt niiden parantaminen tekoälyn avulla on alkanut kiinnostaa.


Tekoälyyn liittyvissä esityksissä käytetään usein seuravaanlaista esitystapaa, kun halutaan kuvata mihin tekoäly asemoituu datan hyödyntämisessä.

 

Kuvan alkupää lähtee perusraportoinnista (mitä tapahtui) ja etenee kohti edistyneempää analytiikkaa (ennustamista) – samalla kun vaikeusaste ja ratkaisun arvo kasvaa. Loppupäässä on luonnollisesti kyse nykytermein tekoälystä tai AI:sta.

Pitäisikö kuvaa tulkita niin, että tekoäly on kehittyneempää Business Intelligenceä? 

Yllättävän usein olen törmännyt eri yrityksissä ajatteluun, jossa tekoälyn kehittäminen on sidottu Business Intelligence järjestelmien kehittämiseen. Ajatuksena se, että kun kerätään dataa ja tehdään raportteja, niin sen jälkeen ollaan kypsiä hyödyntämään koneoppimista (tekoälyä) samassa aihepiirissä.

Eli tekoälyprojektien aloittamista saatetaan (turhaan) viivytellä, jos “perusraportointi ei ole kunnossa”.

Kynttilöistä ei kehittynyt hehkulamppuja

Jos katsotaan reaalimaailman tekoälysovelluksia, niin vain melko harvassa niistä on havaittavissa em. kehityskulku raportoinnista tekoälyyn. Seuraavissa tapauksissa ko. esitystapa ei oikein edes toimi. Eikä varmaan ole tarkoituskaan.

  • Kuvantunnistus ja konenäkö
  • Tekstianalytiikka ja luonnollisen kielen tunnistus
  • Ennakoiva huolto reaaliaikaisella IoT datalla
  • Anomalioiden löytäminen Big Datasta
  • Musiikin tai kuvien tuottaminen tekoälyn avulla

Eli tekoälyratkaisuja syntyy paljon alueille, joissa perinteisellä Business Intelligencellä ei ole roolia.

Toisaalta, tekoälyratkaisuja voidaan usein kehittää ilman taustalla olevaa BI ratkaisua vaikka se toisikin lisäarvoa tai asioiden välillä näyttäisi olevan luonnollinen jatkumo.

Otetaan esimerkki asiakasanalytiikasta, vaikka asiakaspoistuma. Jos BI:n ja AI:n sitoo toisiinsa, niin on luonnollista rakentaa ensiksi BI-järjestelmä, jossa asiakastiedot ovat tietovarastossa, josta tehdään nippu raportointia, esim. “kuinka monta % asiakkaista poistuu vuosittain”.  Ja kun tämä on valmiina, niin hyödynnetään tekoälyä ennustamaan, että ketkä ovat seuraavat kytkimen nostajat.

Näin voi toimia, mutta käytännön elämässä on toimittu myös käänteisesti.

Kuvassa on esitetty erään oikean tekoälyprojektin vaiheet. Siinä aloitettiin keräämällä asiakastietoja monista eri lähteistä, vain ennustamista varten. Kun myöhemmin ennustemallit huomattiin toimiviksi (olivat jo tuotannossa), niin ko. tietoja alettiin tuoda BI-järjestelmään.

Kuulin joskus hauskan vertauksen, jossa todettiin ettei kynttilöistä kehittynyt hehkulamppuja. Siinä oli kyse disruptiivista keksinnöistä, hehkulamppu ei ollut vain parempi kynttilä. Mielestäni sama analogia toimii myös aika hyvin BI:n ja AI:n välillä.

Eri tarkoitus, eri kehityspolut

Business Intelligence -ratkaisut ovat nyt ja jatkossa kivijalka yritysten raportoinnille ja analytiikalle, jota ilman ei tule toimeen. Omenakauppiaan tulee tietää monta omenaa meni kaupaksi eilen, viime viikolla ja joulumyynnissä.

Tekoälyratkaisut eivät auta omenakauppiasta vain ennustamaan omenoiden menekkiä, vaan myös tulkkaamaan kiinalaisten turistien omenatiedustelut ja automatisoimaan kirjanpidon.

BI ja AI ratkaisuilla on yleensä eri tavoitteet, mutta myös itse projektit saattavat erota kuin yö ja päivä toisistaan. Näistä syistä en sitoisi niiden kehittämissuunnitelmia liian tiukasti toisistaan riippuvaiseksi.


21.02.2019 / Mika Laukkanen

Kun aloitin työurani 1990 luvun lopulla, niin tietovarastojen ja raportoinnin toteutus oli nykyistä paljon selkeämpää. Tietolähteet olivat pääasiassa relaatiokantoja tai melko yksinkertaisia tekstitiedostoja.  Eikä raportointikaan ollut kovin monimutkaista, koska silloisilla työvälineillä rajat tulivat nopeasti vastaan. Itsensä tunsi kuninkaaksi, jos sai graafin ja taulukon samalle sivulle.  Datan laatu oli toki samaa puppua kuin se nykyäänkin tuppaa olemaan.  Tuon ajan tyypillinen DW arkkitehtuuri oli seuraava.

Nykyiset arkkitehtuurikuvat ovat yksinkertaisimmillaan vastaavia, mutta yleensä kuitenkin monipuolisempia. Nyt on enemmän erilaisia tietolähteitä, samoin kuin datan tallennus- ja esityspään ratkaisuja.

Miksi sitten tietovarastoja alettiin alunperin rakentaa? Tässä muutamia syitä, jotka löytyivät vuonna 2001 tehdyiltä powerpointeilta.

  • Tietojen yhdistely ja harmonisointi eri tietojärjestelmistä
  • Yksi totuus päätöksentekoon
  • Käyttäjien ad-hoc kyselyt mahdollisia ja tietohallinnolle jää aikaa muuhun työhön
  • Tietovarasto historioi yrityksen datat, saadaan aikasarjoja ja analytiikkaa
  • Ei rasiteta operatiivisia järjestelmiä raportoinnilla

Nämä samat argumentit pätevät varsin hyvin vielä nykyäänkin. Mainittakoon että jossakin vaiheessa oli buumi, jonka mukaan kaikki yrityksen datat pitäisi saada keskitettyyn EDW ratkaisuun. Nyt ajatus tuntuu vähän hassulta, mutta ei tuntunut silloin, koska dataa syntyi suhteellisen pieniä määriä ja lähinnä omissa järjestelmissä.

Tietovarastot tehtiin raportoinnin tarpeisiin

Perinteisesti tietovarastoihin tuotava data on määräytynyt raportointitarpeiden mukaisesti. Esimerkiksi talousraportteja varten on tuotu talousdataa ja HR-raportteja varten HR-dataa. Lisäksi tietysti löytyy kombinaatioita, joissa raporteille on yhdistelty eri alueiden tietoja.

Nyt kun tiedetään, että koneoppimis- ja tekoälyratkaisut tarvitsevat dataa oppiakseen, niin eikös ole loistavaa, että vuosikymmeniä dataa on purkitettu tietovarastoihin?

Vastaus on toisinaan kyllä, mutta usein ei.

Kun dataa on kerätty vain raportointitarpeita ajatellen, niin on sattuman kauppaa, että sopiiko se koneoppimisen hyödyntämiseen. Selvennetään asiaa esimerkillä.

Tietovarastoon XYZ kerätään asiakasdataa, josta on tarkoituksena raportoida asiakaskohtaiset eurot tuotteittain, tuoteryhmittäin, asiakassegmenteittäin ja vaikkapa päivätasolla. Kerätään siis tietovarastoon laskutus-, tuote- ja asiakastiedot.

Tässä vaiheessa paikalle saapuu datatieteilijä, joka haluaisi tehdä asiakaspoistumamallin. Hetken dataa tutkailtuaan hän havaitsee, että tietovarastoon ei ole tuotu asiakkaan sopimukseen liittyviä tietoja. Ne olisivat todennäköisesti keskeinen elementti asiakaspoistumamallissa. Tai ehkä sopimustiedot ovat tietovarastossa, mutta niistä tunnetaan vain viimeisin tilanne – ei koko asiakkaan sopimushistoriaa, joka olisi jälleen olennaista asiakaspoistumamallin kannalta. Dataa siis voi olla, mutta siitä ei silti ole olennaista hyötyä.

Olen ollut mukana kymmenissä koneoppimisharjoituksissa, ja vain harvoissa kaikki tarvittava data on ollut saatavilla ns. perinteisestä tietovarastosta. Tyypillisimmät haasteet ovat olleet:

  • Tarvittavaa dataa ei ole ollenkaan tietovarastossa tai vain osittain
  • Dataa on tietovarastossa, mutta liian lyhyeltä ajalta (historiaa poistettu)
  • Tarvittavan datan historiointi on liian harvaa / epätäydellistä

 

Miten huomioida tekoäly tietovarastojen suunnittelussa?

Koska tietovarastojen suunnitteluun ja tekemiseen joka tapauksessa upotetaan valtavia summia rahaa, niin kannattaisi tehdä muutamia toimenpiteitä, jotka tukisivat ajatusta, että tietovaraston sisältö voisi olla syötteenä tekoälyratkaisuille jatkossa. Esimerkiksi.

  • Samalle datalle on hyvä olla useampi käyttötarkoitus (esim. asiakkaaseen liittyvä perinteinen raportointi, asiakaspoistumamallinnus ja asiakaskohtaiset myyntiennusteet).
  • Raportointitarpeiden lisäksi tarvitaan siis näkemystä, että millaisia tekoälyratkaisuja jatkossa halutaan tehdä. Jos ei ole dataa, niin ei tule ratkaisujakaan.
  • Datan historiointi kattavasti. Tämä vaikuttaa mm. tietovaraston mallinnustapaan. Näyttäisi siltä, että Data Vault ei ole hassumpi vaihtoehto vaikka pelkkään yksinkertaiseen BIDW projektiin se saattaakin olla järeähkö menetelmä.
  • Datan määrällä on merkitystä tekoälylle vaikkei raportoinnissa tarvittaisi kuin 3 viimeistä vuotta. Tietovarastoja ei siis kannata tyhjentää ”turhasta datasta”, vaan mieluummin siirtää vanhaa dataa muuhun ympäristöön. Jos vain vähääkään näkee, että sillä voisi olla käyttöä myöhemmin.
  • Kaikkea tekoälyratkaisuissa käytettävää dataa ei tarvitse tai kannata tuoda välttämättä tietovarastoon. Usein on viisaampaa pitää esim. IoT sensoridatat tai nettisivujen verkkolokit jossakin muussa ratkaisussa.

Näillä muutamalla opilla tietovarastoista tulee jo tekoälykelpoisempia. On kuitenkin hyvä huomata, että datan purkittaminen yhteen paikkaan ei itsessään synnytä tekoälyratkaisuja – siihen tarvitaan selkeät business caset. Data toimii sitten mahdollistajana.


9.01.2018 / Mika Laukkanen

Otsikon mukainen kysymys tuli mieleeni, kun eräänä päivänä katselin lävitse Louhian tekemiä koneoppimis- ja AI-projekteja. Kävi nimittäin ilmi, että kymmenistä eri harjoituksista vain murto-osassa datat olivat tulleet yrityksen tietovarastosta tai tietovarastoista (DW, EDW). Noihin tietovarastoihin on kuitenkin upotettu miljoonia, mutta ensimmäisten AI-kokeilujen osalta ne olivat pääosin hyödyttömiä.

Aloin selvitellä asiaa tarkemmin ja syyksi “hyödyttömyyteen” paljastuivat seuraavat kaksi asiaa. 

  1. Tarvittavaa dataa ei ollut lainkaan tietovarastossa
  2. Tarvittava data oli tavallaan tietovarastossa, mutta puutteellisena

Kohta 1 on varsin selvä. Tietovarastot on suunniteltu ihmisen toteuttaman raportoinnin tarpeita ajatellen. Ja nämä raportointitarpeet ovat yleensä historiaan katsovia mittareita, kuten montako omppua myytiin viime vuonna ja paljon niistä jäi katetta. Tai ketkä olivat suurimpia omppujen ostajia. Tai paljonko meiltä jäi omppuja myymättä.

Koneoppimisen ja tekoälyn avulla taas yleensä ratkotaan ongelmia, joilla ennustetaan tulevaisuuden skenaarioita. Esimerkiksi, halutaan ennustaa omppujen hintakehitystä tulevien viikkojen aikana, jotta voidaan ostaa niitä optimaalisella hinnalla.

Miksi sitten esim. tällaisessa keississä perinteinen tietovarasto ei yleensä sisällä relevanttia dataa ennustamisen kannalta?

  • Omppujen hintakehitykseen vaikuttavat kasvattajamaan säätilat –> tuskin löytyy tietovarastosta valmiina, koska niistä ei tehdä BI-raportteja
  • Omppujen hintakehityksen osalta olisi olennaista tietää kulloisetkin markkinahinnat, joilla omput ovat olleet tarjolla –> tietovarastosta kuitenkin löytyy vain ostohinnat

Vastaavia tilanteita tulee jatkuvasti esiin AI-projekteissa.  Lisäksi ne saattavat mennä osa-alueille, joissa ei ns. perinteistä raportointia ole tehty aiemmin ollenkaan. Esimerkiksi lokeista tehtävään vikaantumisen ennustamiseen. Tällöin dataa ei varmastikaan ole firman EDW:ssä. Puhumattakaan kuvien tunnistukseen tai tekstianalytiikkaan liittyvistä projekteista.

Kohdan 2 tilanteessa tietovarastossa on jo melkein relevanttia dataa. Esimerkiksi tietovarastoon on kerätty asiakastietoja ja tehty siitä raportointia. Tässä tilanteessa voidaan törmätä siihen, että dataa ei ole historioitu oikein tai riittävästi. Esimerkiksi asiakaspoistuman ennustamiseksi voidaan tarvita tietoja asiakkaan aiempien sopimustilanteiden statuksista eri ajanhetkinä. Näitä ei kuitenkaan välttämättä ole tallennettu, vaan tietovarastossa on vain viimeisin status asiakkaan sopimustilanteesta.

Dataa on myös voitu summata liian karkealle tasolle, jotta siitä olisi mielekästä tehdä koneoppimista.

Kun tietovarastoja on kehitetty, niin ei vain ole osattu ajatella näitä uudenlaisia tarpeita. Todellinen haaste kuitenkin voi olla, että osataanko vieläkään? Rakennetaan innolla versiota 3.0 EDW:stä ilman, että huomioidaan tulevia tarpeita riittävästi. Tehdään vain parempi ja kattavampi versio vanhasta.

Ketterästi vai hooposti?

Oletaan lähtötilanne, jossa on kaksi yritystä, X ja Y, jotka molemmat haluavat ennustaa omppujen myyntiä ja hintaa. Näillä on kuitenkin erilaiset lähtökohdat tehdä projekti.

  • Yritys X päättää, että tarvittavat datat on tuotava ensiksi tietovarastoon. Pitää käynnistää siis projekti tietovarastotoimittajan kanssa. …(hypätään ajassa eteenpäin..) Kaksi vuotta myöhemmin  datat todellakin löytyvät EDW:stä käyttökelpoisena.
  • Yritys Y taas päättää kerätä datat ensiksi vaikkapa csv-tiedostoihin eri lähteistä ja yhdistellä ne data-analyytikon läppärillä. Tähän kuluu pari viikkoa.

Molemmissa yrityksissä tehdään Deep-Omppu malleja ennustetaan omppujen myyntiä ja hintaa tuleville viikoille. Molemmissa paikoissa päästään samoihin päätelmiin mallin kannalta olennaisesta datasta ja muuttujista. Huomataan että kaikesta kerätystä alkudatasta vain alle puolet on merkityksellistä mallin kannalta.

Nyt yritys X on investoinut jo valmiiksi paljon aikaa ja rahaa viedäkseen tietovarstoon myös merkityksettömät datat. Yritys Y sen sijaan aloittaa vasta tässä vaiheessa datan tietovarastoon viennin – nyt kun tiedätään mistä siellä oikeasti tarvitaan. Kumpihan on fiksumpaa?

Esimerkki saattaa olla vähän karrikoitu, mutta perustuu kokemuksiin useista eri projekteista tällä alalla.

Yhteenvetona

  • Varaudu siihen, että aiemmin tehty tietovarasto ei taivu koneoppimisen ja tekoälyn tarpeisiin
  • Suunnittele tulevat tietovarastot siten, että ne taipuvat
  • Etene ketterästi ja kokeile ensiksi toimiiko tekoälyideat ennen kuin aloitat EDW-projektia sen vuoksi

 


21.08.2017 / Mika Laukkanen

Seuraava kirjoitus on julkaistu Tieke lehden numerossa 1-2017. Jaetaan se nyt täälläkin.


Tärkeintä on laadukas data

Voimme päivittäin lukea uutisvirrasta uusien tekoälyratkaisujen tulevaisuuden potentiaaleista. Datamäärien ja laskentatehon kasvu yhdessä algoritmien kehityksen kanssa ovat potkaisseet tekoälyn kehitysvauhdin uudelle kiertoradalle.

Nykyään lähes kaikki tekoälyratkaisut perustuvat neuroverkkoihin, joiden prosessoitavaksi on ohjattu dataa. Neuroverkko ohjelmoidaan oppimaan datasta, jossa on syötteitä (esimerkiksi asiakkaan taustatietoja ja ostohistoriaa) ja vasteita (esimerkiksi ostiko asiakas tuotteen vai ei).
Näin neuroverkko muodostaa mallin, jonka avulla se ennustaa syötteiden avulla vasteita.

Varmista vahva perusta

Kun tekoälyä ryhdytään valjastamaan liiketoiminnan resurssiksi, ensin onkin ymmärrettävä, että kaikki lähtee laadukkaasta datasta. Fiksuinkaan tekoälysovellus ei palvele tarkoitustaan, jos sille syötetään epärelevanttia dataa. Toisin sanoen: mitä kattavammat ja paremmat datavarannot yrityksellä on, sen järeämmät edellytykset sillä on rakentaa toimivia tekoälyratkaisuja liiketoiminnan eri osa-alueille.

Vältä järjettömät ratkaisut

Datan huonosta laadusta esimerkkinä käy botti, jonka piti opetella twiittailemaan. Valitettavasti Twitter-käyttäjät syöttivät sille rasistisia ja sovinistisia twiittejä, ja bottihan oppi ne nopeasti, ja alkoi heittää vastaavia twiittejä. Kunnes joutui itse jäähypenkille konekatumaan.
Yksi tekoälyratkaisujen heikkous onkin, että niillä ei ole kontekstia ympäröivään maailmaan, ja siksi ne voivat päätyä joissakin tilanteissa järjettömiin ratkaisuihin.

Korvaamaton resurssi

Jatkossa yritysten datavarannot ovat yksi tärkeimmistä kilpailutekijöistä, kun taistellaan paikasta auringossa. Ne ovat tärkeämpiä kuin vaikkapa ohjelmistot tai tekoälyalgoritmit, koska jälkimmäiset ovat melko helposti kopioitavissa tai ostettavissa. Datavarannot ovat taas rahanarvoista omaisuutta, jota kilpailijat eivät voi kopioida. Esimerkiksi Google julkaisee tekoälykoodejaan avoimesti, mutta datasta saa maksaa. Eikä kaikkea dataa tietenkään saa edes rahalla!

Laadi tekoälystrategia

Monissa yrityksissä datavarantojen muodostamisesta vastaa it-osasto, joka hankkii ohjelmistoja ja teknologioita asian toteuttamiseksi. Liiketoiminnat osallistuvat tiedonkeruuseen käyttämällä ohjelmistoja (esimerkiksi ERP tai CRM). Tämän mallin riskinä on, että datavarantojen sisällön kehitystä ei vie eteenpäin ennalta mietitty strategia. Seurauksena voi olla siilomaisia ja pistemäisiä ratkaisuja, jotka eivät kustannuksiin nähden tuo riittävästi arvoa. Yrityksissä olisikin korkea aika pohtia datan strategista arvoa liiketoiminnan kannalta ja kehittää datan keräämistä sekä hyödyntämistä sen mukaisesti.

 


9.08.2017 / Mika Aho

Kävin toukokuussa Prosessipäivillä höpisemässä tietovarastoinnin ja tekoälyn/koneoppimisen yhteydestä. Nyt kun aihe on monella suunnalla aktiivinen, kirjoittelin siitä myös oman bloginsa.

Ajatuksena oli herätellä yleisöä pohtimaan ensinnäkin tekoälyn ja tietovarastoinnin nykytilaa, mutta ennen kaikkea mihin näitä kahta voisi yhdessä soveltaa. Alla varsinainen esitys sekä muutamia käyttötapauksia ja sovelluskohteita.

[slideshare id=75973994&doc=prosessipivt2017-korvaakotekolyperinteisentietovarastonnetti-170515055044&w=750]

Ei syvennytä tässä kirjoituksessa tekoälyyn tai moderniin tietovarastointiarkkitehtuuriin, vaan keskitytään enemmänkin neljään eri sovelluskohteeseen.

Tietomallinnus

Tietomallinnusta tehdään useammalla eri tasolla. Tyypillisesti luodaan jonkinlainen (ylätason) käsitemalli, ehkä pilotoidaan mallinnusta tietyssä liiketoiminnassa ja luodaan siitä osa-aluekohtainen käsitemalli, näistä edelleen looginen malli ja vielä fyysinen malli valittuun tietokantateknologiaan. Jokaisessa eri vaiheessa syntyy myös metatietoa, esimerkiksi tietovirtakuvauksia, rakennekuvauksia, käsitemääritelmiä ja niistä muodostettuja sanastoja.

Hyvän tavan mukaisesti mallinnusta tehdään tietomallinnusvälineessä (esim. ER/Studio, Enterprise Architect), jotta homma pysyy paremmin hanskassa, eivätkä hanskat huku toimittajan vaihtuessa.

Tämän lisäksi on olemassa erilaisia tapoja mallintaa tietoa. Perinteisesti tietovarastoja on mallinnettu Kimballin tähtimallin mukaisesti ja nykyisin entistä enemmän Lindstedin Data Vault -menetelmällä. Jälkimmäinen on hieman työläämpi, mutta siinä on omat etunsa ja tiettyjä vaiheita pyritään usein automatisoimaan.

tietomallinnus

Missä välissä koneoppiminen ja tekoäly sitten tulevat mukaan? Itse näen, että meillä on paljonkin mahdollisuuksia automatisoida mallinnusprosessia. Kone on mahdollista opettaa oppimaan rakenteita, muokkaamaan niitä lennossa, “ajattelemaan” kontekstia ja korjaamaan prosesseja. Oppiminen tapahtuu esimerkiksi loppukäyttäjän tekemien kyselyiden ja analyysien kautta.

Ei ehkä kovin kaukaista tulevaisuutta, että koneelta kysellään luonnollisella kielellä dataa ja se muodostaa tarvittavat tietorakenteet lennossa lähdejärjestelmiin perustuen. Tämän jälkeen tietovarastosta tuleekin enemmänkin musta laatikko, joka imaisee lähdejärjestelmien rakenteita sekä datoja ja muodostaa tuloksen loppukäyttäjän tarpeen mukaan. Ei meidän tarvitse sille tulevaisuudessa enää opettaa, että järjestelmän X taulun J8KA13KF sarake I0NYX5H1 pitäisi mapata tietovaraston F_SALES.SalesAmountEUR-kenttään.

Tällainen “tekoälykäs” tietoalusta pystyy toimimaan minimaalisella inhimillisellä ohjauksella, oppii kokemuksistaan ja tunnistaa piilossa olevia malleja tietovirroissa ja tietopyynnöissä. Se pystyy myös hakemaan itsenäisesti lisätietoa esimerkiksi datan laatua koskevan ongelman vahvistamiseksi tai vaikkapa tietojen hankkimiseksi vaihtoehtoiselta lähteeltä.

Datan laadunvalvonta

Datan laatu on ollut perinteisesti IT:n tehtäviä: on seurattu dataa, yritetty ymmärtää sen sisältöä (profilointi) ja luotu tietojen puhdistus- ja yhteensovitussääntöjä (standardointi). Koneoppimisella on paljonkin mahdollisuuksia datan laadun arvioinnissa.

Virheitä on ainakin kahdenlaisia:

  1. Järjestelmälliset virheet, jotka esiintyvät säännöllisesti tietyissä olosuhteissa
  2. Satunnaiset virheet, jotka tapahtuvat epäsäännöllisesti tietyissä olosuhteissa

Järjestelmälliset virheet ovat huonompi kandidaatti koneoppimiselle, sillä ongelman tunnistaminen vaatii tietämystä datan käytöstä. Käyttäjien onkin helpompi tunnistaa tällaisia virheitä, varsinkin jos ne esiintyvät usein.

Satunnaisia virheitä on puolestaan helpompi havaita tilastollisten menetelmien avulla. Tällainen voi olla vaikkapa äkillinen muutos datan arvoissa. Ihmisille tämän tyyppiset virheet helposti piiloutuvat suurien tietomäärien taakse varsinkin jos ne esiintyvät harvakseltaan.

Otetaan esimerkki. Meillä on runsaasti erilaisia dataa kerääviä järjestelmiä, kuten ERP, CRM, tuotanto, talous ja HR. Dataa integroidaan näiden järjestelmien välillä ja osa tiedoista siirretään myös tietovarastoon. Isossa organisaatiossa erilaisia automatisoituja datasiirtoja voi olla sadoista useisiin tuhansiin.

Miten varmistutaan, että dataa siirtyy oikea määrä?

dataaDW

Analytiikka seuraa siirrettävän datan volyymeja ja antaa varoituksen, jos dataa tulee liian vähän tai liikaa. Alla (ei niin kuvitteellinen) esimerkki myyntirivien seurannasta tuoteryhmittäin, jossa tässä tapauksessa tuoteryhmän myynti on tasaista ympäri vuoden. Dataa tulee yli sadasta eri kauppaliikkeestä ja joskus niiden latauksissa on ongelmia.

Tilastollinen malli luo automaattisesti luottamusvälit datavolyymin vaihtelulle. Mikäli toteutunut datavolyymi rikkoo luottamusvälin, niin siitä lähtee tiedote ylläpitoon. Alla esimerkkikuva oikeasta datasta laskettuna:

data_luottamusvälit

Punaisen raksin kohdalla osa tiedosta ei tullut lainkaan, joten volyymit putosivat. Usein tällainen virhe ei jää kiinni ETL-prosessissa, vaan se menee nätisti läpi, joskin pienemmillä datamäärillä. 

Pidemmälle vietynä tällainen malli ei pelkästään auta määrittämään ja parantamaan tiedon laatua, vaan tarjoaa myös älykkäämpiä suositeltuja toimenpiteitä tietojen laadulle sekä toiminnallisille parannuksille. Se pystyy myös luokittelemaan datan laatuongelman tyypin tai vakavuuden mukaan.

Datan standardointi

Kolmas hyvä sovelluskohde koneoppimiselle on datan standardointi.

Aika usein datan siivoamista tehdään käsityönä eli poistetaan duplikaatteja ja yhdistellään tietueita keskenään. Käsin tehtynä sääntöjen määrittäminen kestää, vaatii syvällistä ymmärrystä datasta ja on lisäksi kallista. Ymmärrettävästi tietolähteiden kasvaessa ja datan formaattien sekä tietotyyppien lisääntyessä sääntöjen rakentamisesta tuleekin äkkiä iso harjoitus. Lisäksi datan manuaalinen yhteensovittamisen tarkkuus on aina kyseenalaista.

Koneoppimisen avulla modernilla data-alustalla voidaan luoda matchaussääntöjä automaattisesti datasta. Järjestelmä myös oppii ja mukautuu käyttäjien käyttäytymiseen. Tämän tyyppistä toiminnallisuutta löytyy esimerkiksi Talendin Data Fabric -tuotteesta.

Datan paikkaaminen

Koneoppimista voidaan hyödyntää myös datan rikastamiseen tai paikkaamiseen ilman käyttäjän syötettä. On mahdollista laskea erilaisia segmentointiattribuutteja, arvioida asiakaspoistumaa, luottotappiota tai vaikkapa laskennallisesti täydentää asiakkaiden tietoja. Mika ja Ville ovat kirjoittaneet tästä aikaisemmin Louhian blogiin, kannattaa lukaista läpi.

Asiakkaiden tietojen täydentämiseen liittyen kannattaa muuten olla tarkkana. Kun seuraavan kerran törmäät Facebookissa tai vastaavassa kyselyyn, jossa sinua pyydetään vastaamaan “10 viattomaan kysymykseen”, kannattaa miettiä pari kertaa, vastaisiko. Silloin tällöin niissä taustalla olevat algoritmit muodostavat mallin, jotka pystyvät 10 vastatun kysymyksen perusteella ennustamaan ”100 syvällisen kysymykseen” liittyviä asioita. Tällöin sinusta tiedetäänkin aika paljon enemmän ja se iPhone jää kuitenkin saamatta.

voitaIphone


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


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

 

 

 

 


17.10.2016 / Jani Liimatta

Vaikka SSAS-kuutioiden käyttöoikeudet mahdollistavat melkein kaikki mahdolliset kombinaatiot, mitä vaativammallakin asiakkalla voi mieleen juolahtaa, on dimension tai attribuutin piilottaminen kokonaisuudessaan käyttöoikeuksilla mahdotonta.

Esimerkiksi kuutiossa on mahdollista:

  • Dimension detaljit voi piilottaa käyttäjäryhmältä
  • Mittarin voi arvot voi piilottaa käyttäjäryhmältä
  • Osan riveistä voi piilottaa oikeuksiin perustuen, käyttäjä voi esimerkiksi nähdä vain oman osastonsa luvut

Mutta, käyttäjiltä ei siis pysty piilottamaan esimerkiksi tietoa siitä, että joku muu saa dataa ulos tarkemmalla tasolla. Harvemminhan tämä on tarpeellista, mutta pari kertaa on tullut tällainenkin tarve eteen. Piilottamiseen on olemassa workaround, joka ei ainakaan itselläni tullut ihan heti mieleen. Sen voi nimittäin toteuttaa kuution Linked Object:eja käyttämällä.

Steb-by-step:

Skenaaario, jossa osa osastoista ei saa nähdä, että myyjätasoinen data on olemassa kuutiossa.

1.Luodaan minuutissa peruskuutio, jossa on ‘kaikki’ dimensiot käytössä. Käytetään tässä erimerkissä hmm… persoonallisesti mallinnettua, vanhaa ja tuttua Microsoftin AdventureWorks DW:tä pohjana.

peruskuutio
 

 

 

2. Luodaan tyhjä kuutio (Create Empty Cube) projektipäälliköille (ProjectSales). Projektipäälliköt eivät saa nähdä myyjäkohtaisia myyntejä.

uusikuutio

 

 

 

 

3. Avaa tämä uusi kuutio. Valitse oikalla napilla ‘New Linked Object’-wizard. Valitaan nykyisestä kuutiosta kaikki measuret. Näiden mukana pöllähtää mukana myös kaikki liittyvät dimensiot.

linkedobject

 

 

 

 

 

 

 

4. Nyt on siis käsissä uusi kuutio, joka sisältää vain linkit alkuperäiseen kuutioon. Poistetaan siitä Employee-dimensio

removeemployee

 

 

 

 

 

5. Seuraavaksi voidaan käyttöoikeuksilla säätää kuutioihin pääsy. Nyt on käsissä siis peruskuutio – sekä projektimyyntikuutio, josta ei edes näe, että myyjätasolle on mahdollista päästä.

excel

 

 

 

 

 

Harvemmin on oikeasti tarvetta piilottaa koko dimensio, mutta jos tulee tarvetta, linkatut objektit ovat ainut järkevä tapa toteutukseen. Toinen tapa on tehdä peruskuutiosta kopioita – mutta silloin haukataan levytilaa, kadotetaan kuutioiden prosessointiaikaa, sekä duplikoidaan logiikkaa. Linkattujen objektien ansioista kun peruskuutio on prosessoitu, on linkkikuutiokin ajan tasalla.

Toisaalta tässä on olemassa sellainen ‘hauska ominaisuus’, että muutokset eivät automaattisesti periydy eteenpäin. Eli jos muutat peruskuution rakennetta, on linkkikuutio käytännössä tehtävä uusiksi. Tai ainakin muutettu measure group poistettava ja lisättävä takaisin. Se ei onneksi ole kummoinenkaan tehtävä. Paitsi jos muut käyttöoikeusasetukset ovat monimutkaisia… periytymisongelman takia ei näitä linkattujen objektien kuutiossa ei oikein muuta logiikkaa kannata ollakaan.

https://msdn.microsoft.com/en-us/library/ms174899.aspx

Lisensoinnin kannalta linkatut objektit toimivat std-SQL Serverissä, jos kuutiot ovat saman SSAS-kannan sisällä. Toisen projektin/kannan kautta tarvitaan Enterprise-lisenssi.


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/