25.02.2014 / Antti Ollikainen

Käsi ylös kaikki, joiden mielestä mittaukseen lisätty mittausvirhe heikentää mittauksen tarkkuutta. Melko monen käsi varmaankin nousi?

Mutta tehdäänpä seuraavaksi pieni ajatusleikki: oletetaan vaaka, joka kyllä havaitsee henkilön tarkan painon, mutta näytön tarkkuus estää kilogrammaa tarkemman lukeman näyttämisen.

Oletetaan edelleen, että vaa’alle hyppää hypoteettinen Antti O. hypoteettisine 83,7 kg elopainoineen. Vaaka näyttää 84,0kg. Tilannetta ei auta mittauksen toisto, vaan mittausvirhe on pysyvä: aina tulee tulokseksi tuo sama 84,0kg.

Oletetaan seuraavaksi, että muokataan vaakaa siten, että se lisää virhettä mittaukseen, välillä muutama kilo ylöspäin ja välillä muutama kilo alaspäin. Mittausvirheet ovat sattumanvaraisia esim. normaalijakaumasta arvottuja desimaalilukuja.

Jos nyt tämä hypoteettinen Antti O. hyppää näin peukaloidulle vaa’alle vaikkapa sata kertaa, tulee tulokseksi vaihtelevasti eri painoja vaikkapa välillä 80-88 kg, kaikki toki edelleen tasakilogrammoja näytön tarkkuudesta johtuen.

Arvatkaapa mikä luku saadaan, kun noista sadasta virheellä höystetytystä mittauskerrasta lasketaan keskiarvo? Kyllä, hämmästyttävästi juurikin tuo 83,7 kg, sen tarkemmin mitä enemmän mittauksia on.

    • Mittausvirheen lisääminen siis paransi mittauksen tarkkuutta!

Alla on esimerkkinä vaa’an näyttämien jakauma, kun on arvottu 100 mittausvirhettä normaalijakaumasta, jonka hajonta on 5 ja odotusarvo 0. Tässä nimenomaisessa realisaatiossa pienin vaa’an näyttämä on 71 kg ja suurin 95 kg. Sadan mittauskerran keskiarvo on 83,63 kg, joka on jo huomattavan lähellä 83,70 kilogramman todellista mitattavaa painoa.

KernelRealisaatio

Miten vaakaesimerkki sitten liittyy Kernel-estimointiin? Kun vaa’an annettiin lisätä mittaukseen mittavirhettä, se muodosti tuon datapisteen 83,7 kg kohdalle ns. kernelin eli pienen symmetrisen paikallisen jakauman, jonka keskipiste on 83,7 kg. Toistuvat punnitukset eivät tällöin enää kohdistuneet kiinteään datapisteeseen vaan tuohon laajempaan jakaumaan. Käytännössä vaa’alle annettiin mittavirheen (kernelin) avulla mahdollisuus kertoa, että tämä pyöristettynä tasan 84 kg painoiselta näyttävä henkilö voi tosiasiassa olla painoltaan jossain välillä 83,50 – 84,49 kg. Toistuvilla mittauksilla ja keskiarvolla tämä todellinen arvo paljastui, vaikka vaa’an näyttö ei sitä suoraan mahdollistanut.

Tämä on juuri kernel-estimoinnin ajatus: jokainen yksittäinen havainto korvataan pienellä paikallisella jakaumalla, usein normaalijakaumalla. Tämän jälkeen jatkolaskennat ja analyysit –vaakaesimerkkimme tapauksessa keskiarvon laskenta– kohdistetaan kerneleihin. Vaakaesimerkissä tehtiin sata mittausta samasta havainnosta, mutta useimmiten kernel-estimointia sovelletaan tilanteeseen, jossa on tehty mittauksia useista eri havainnoista, yksi per havainto (on vaikkapa mitattu kymmenen henkilön painot).

    • Pistemäisistä havainnoista siirrytään pienten paikallisten jakaumien (kerneleiden) analyysiin.
    • Havainnot ovat kerneleiden keskipisteitä.

Toinen jo enemmän filosofinen argumentti kernel-estimoinnin taustalla on se, että kukin datapiste edustaa itsensä lisäksi jossain määrin myös niitä lähellä olevia havaintoja, jotka eivät tulleet valituksi otokseen. Esimerkiksi tietoa 83,7 kg painoisesta Antti O:sta voidaan pitää todisteena siitä, että on todennäköisesti olemassa myös vaikkapa 83,0 kg painavia henkilöitä, vaikka heitä ei juuri nyt otokseen tullut. Kernelin arvo (tiheys/korkeus) kohdassa 83,0 kg kertoo, kuinka todennäköistä tämä on. Alla oleva kuva havainnollistaa tilannetta:

NormjakLeikkisästi voidaankin todeta, että kun analyytikko ottaa käyttöön kernel-estimoinnin, hän tavallaan tömäyttää dataa kylkeen, jolloin jokainen havainto tärähtää ja leviää pieneksi datapilveksi, jolla on sumeat rajat. Yksi kernel-estimoinnin haaste onkin se, miten lujaa dataa tulisi tömäyttää: liian hiljaa (kapea jakauma), niin kernel-estimoinnin edut jäävät saavuttamatta, liian kovaa (leveä jakauma), niin aineiston alkuperäinen informaatio katoaa, koska havaintoja ei voi enää erottaa toisistaan.

Kernel-estimoinnilla on lukuisia sovelluskohteita. Yleisin sovellustilanne syntyy, kun jatkuva muuttuja luokitellaan ja sen jakaumasta tehdään esim. histogrammi. Luokittelu tekee muuttujalle samaa “väkivaltaa” kuin vaa’an tekemä pyöristys teki painolle. Kernel-estimointia voidaan tällöin käyttää jatkuvan muuttujan alkuperäisen jakauman paljastamiseen aivan kuten vaakaesimerkissä mittausvirhettä käytettiin oikean painon paljastamiseen.

Alla on tästä esimerkki. Data koostuu viiden henkilön painoista: 79, 80, 81, 84 ja 85 kilogrammaa. Vasemmalla on histogrammi datasta ja oikealla vastaava kernel-estimoitu jakauma (kiinteä viiva), kun kernelit (katkoviiva) on muodostettu normaalijakaumasta, jonka hajonta on 1 ja odotusarvo nolla. Kernel-estimoitu jakauman tiheysfunktio on yksinkertaisesti yksittäisten kernel-tiheysfunktioiden pystysuuntainen summa.

HistogKernel

Myös moniulotteisille jakaumille voidaan hyödyntää Kernel-estimointia.

Kerneleitä käytetään apuna myös silloin, kun jokin toinen tilastomatemaattinen menetelmä hyötyy datan sisältämän informaation esittämisestä hieman sumeammassa (“täräytetyssä”) muodossa. Esimerkiksi support vectors machines -menetelmän yhteydessä epälineaarisen ongelman ratkaisu on teknisesti helpompaa kernelien (tai tarkemmin kernel-funktioiden) kanssa (ns. Kernel-trick -tekniikka).

Lopuksi varoituksen sana: vaikka datan kernel-täräyttäminen voi tuntua data miningin turhauttavimmilla hetkillä kertakaikkisen mahtavalta idealta, ei ajatuksesta tule innostua liikaa:

SiinäSinulleKernel


24.02.2014 / Kristiina Sarén

Bilotissa elämme positiivisen kiireistä aikaa, kaikilla on kädet täynnä töitä. Työt liittyvät olemassa olevien asiakasratkaisujen kehittämiseen, mutta enenevässä määrin myös ihan uusiin aihealueisiin joissa toimimme Bilotin hengen mukaisesti tien raivaajina. Juurikin kerättyjen kokemusten vuoksi on hyvä nostaa katse hiukan ylöspäin ja miettiä minkälaista lisäarvoa voimme tuottaa asiakkaillemme kertomalla kokemuksistamme ja ns. lessons learned ajatuksista eri ratkaisualueilta.

Jakaaksemme näitä kokemuksia ja osaamistamme tulemme järjestämään kevään aikana aamiaistilaisuuksia useilta eri aihealueilta. Aamiaistilaisuuksien saama suosio perustuu niiden sisältämien aiheiden ajankohtaisuuteen sekä mahdollisuuteen pienessä ryhmässä keskustella myös muiden asiakkaiden mietteistä ja kokemuksista. Aihealueet, joita käsittelemme sisältävät lähes aina ns. poikkitieteellisen näkökulman eli tilaisuudessa käsittelemme ko. ratkaisun lisäksi myös sen miten ratkaisua voidaan hyödyntää monipuolisesti, integroida muihin järjestelmiin ja kehittää eteenpäin.

Aamiaisseminaarien asiaosuus kestää noin 1,5 tuntia ja ne kohdistuvat ratkaisualueille kuten SAP Cloud for Customer, SAP HANA, Analytiikka, eAnalytics, Hybris on SAP HANA,  Microsoft on Top of SAP käytettävyysratkaisut jne. Asiakkaamme saavat kevään tilaisuuksien kalenterin lähiviikkojen aikana. Mikäli haluat varmistaa, että myös sinä saat tämän aikataulun laita minulle viestiä tästä linkistä.

Tänä vuonna Bilot on toisena pääkumppanina SAP:n vuosittaisessa asiakastapahtumassa SAP Innovation Forumissa 5.3 Finlandia-talolla. Mikäli et ole jo ilmoittautunut tapahtumaan voit tehdä sen tästä linkistä.  Tule keskustelemaan ständillemme mm. Hybris + SAP HANA ratkaisusta sekä tietenkin käytännön kokemuksista  SAP Cloud for Customers toteutuksista.


21.02.2014 / Ville Niemijärvi
Kyltti Mumbaissa
Kyltti Mumbaissa

Olin pari vuotta sitten Intiassa reissaamassa. Kiersimme Keralan maakuntaa, piipahdimme viidakossa, lojuimme rannalla ja toisinaan oluella Ismo Alangon kanssa. Eli sitä perinteistä mitä nyt Intiassa tehdään.

Yksi asia pisti kuitenkin ärsyttämään intialaisessa autoilukulttuurissa: äänitorven käyttö.

Intialaiset autot, riksat ja mopot ajavat käytännössä koko ajan, jatkuvasti töötti pohjassa. Ihan aina. Kaikkialla. Jos vastaan tulee auto, painetaan torvea. Jos jalkakäytävällä on ihmisiä, painetaan torvea. Ja Intiassa autoja ja ihmisiä riittää. Eli torvi on pohjassa aina.

Olimme lähellä luonnonsuojelualuetta, käytännössä täysin maaseudulla. Näimme kilometrin päässä auton lähestyvän leveällä tiellä. Auto läheni ja läheni. Ja kun se pääsi juuri meidän kohdalle, ei 50 metriä ennen vaan juuri siinä korvan juuressa, kuski iskee töötin pohjaan ja värisyttää tärykalvojamme.

Voitte siis uskoa, että äänitorvi on käytännössä turha väline intialaisissa autoissa. Jos se on koko ajan pohjassa, ei sitä noteerata. Se ei ole poikkeus muusta äänimassasta. Se on standardi. Aina vallitseva melu.

No miten intialainen autoteollisuus vastaa tähän haasteeseen ja ilmiselvään turvallisuusongelmaan? Näin uutisen missä automerkki mainosti kovempia äänitorvia! “Meidän äänitorvi ylittää 180DB ja se on roimasti enemmän kuin kilpailijalla.” Tämä oli oikeasti firman ainoa myyntiargumentti.

Ja sitten liiketoimintaan ja hiljaiseen härmään.

Jos olet yrityksesi raportointi- tai tietovarastovastaava, yritykselläsi on hieno business intelligence -softa ja olet panostanut muutaman vuoden ajan raportoinnin kehittämiseen, olet todennäköisesti kuin intialainen autoteollisuus tai taksikuski Mumbain ruuhkassa.

Toisin sanoen hukutat liiketoiminnan käyttäjät tietoon ja estät heitä näkemästä olennaisen. Estät näkemästä muutoksen, joka heidän pitäisi havaita ajoissa.

Entisaikaan kun liiketoiminnan käyttäjä halusi uuden raportin, se piti tilata IT:stä. Jokainen tarve puntaroitiin tarkkaan. Nykypäivän tehokkailla, helppokäyttöisillä raportointityövälineillä pystyy jokainen tekemään omia visualisointeja ja raportteja. Ollaan siis kuin noutopöydässä. Ja kun suomalainen on noutopöydässä ei turhia nirsoilla. Ylin nappi aukaistaan jo pöytään astuessa. Eli raportointimaailmassa tuloksena on, että kaikki mahdollinen tieto siirretään raporteille. Tarvittiin sitä tai ei.

Laske kuinka monta erillistä raporttia yritykselläsi on. Laske montako sivua/välilehteä kullakin raportilla on. Kuinka monta erillistä listaa, graafia, pivottia, taulukkoa tai kuvaa niissä on. Kuinka monta riviä ja saraketta kussakin taulukossa on, kuinka monta solua dataa niissä on. Päädyt todennäköisesti satoihintuhansiin tiedonjyviin.

Niin, sinä olet intialainen autokuski joka ajaa torvi pohjassa ja ihmettelet kun sillä ei ole mitään vaikutusta.

Kysy huviksesi liiketoiminnan raporttien käyttäjiltä, milloin viimeksi he tekivät raporttien dataan perustuvan päätöksen. Päätöksen, jota ei olisi voinut tehdä ilman raportin sisältämää tietoa, päätöksen joka tuo firmaasi lisää rahaa, pienentää kustannuksia. Päätöksen, jolla on ylipäätään jokin vaikutus.

Sillä tästähän BI-järjestelmistä ja tiedolla johtamisesta on kyse. Päätöksenteosta ja asioihin (asiakkaisiin, markkinoihin, henkilöstöösi…) vaikuttamisesta. Jos tarjoat päätöksentekijöille melusaastetta, ei noita päätöksiä ole helppo tehdä. Tällöin BI-välineiden käyttö on vain päämäärätöntä ajelua, torvi pohjassa.

Joskus kun sinun pitää oikeasti varoittaa kanssakulkijoita tai haluat, että sinua varoitetaan edessä olevasta vaarasta, pidä huoli että ympärillä on hiljaista jotta viesti kuullaan.


20.02.2014 / Mika Tanner

I spend a lot of time talking with our customers’ decision makers, I meet regularly with peers and of course I keep an eye on analysts’ predictions and speculations. Technology trends and business trends are typically slightly out of sync as are hype and reality – and for the same reason. I sympathize with our customers’ challenges to make sense of all the buzz, trying to make educated decisions on their future IT landscape, when to invest, which software solutions to go for, with whom to partner with, how to buy. No decision is immune to the unexpected, making decisions is a discipline of combining probabilities and calculating risk.

We are experiencing really exciting times. Operational efficiency is now the norm, but no longer the center of gravity – eyes are set on topline revenue generating solutions, added-value services, new channels, harnessing digitalization to improve customer experience. And there is a clear shift from maintenance to development.

The office of the CIO became business-minded a while ago and now businesses’ increasing IT-acumen and a rapidly growing appetite for new solutions is putting pressure on shortening the innovation-to-profit process. Businesses are also finally admitting IT can bring genuine business benefits and even improve their competitive advantage. Business-driven-IT is finally here. Digitalization is a source of endless opportunity – it provides possibilities to engineer new business models, create net-new revenue streams, reach new customer segments, access global markets and understand and harness information in ways which were not long ago entirely unimaginable.

The ongoing shift of on-premise to cloud is accelerating. SAP’s recent announcement on their strategy will have ripple-effects, which have monumental proportions. The business critical nervous system, back-bone ERP, related core-business applications and analytics are now cloud-eligible. The migration has started and it will not end any time soon.

For today’s IT partners (formerly known as systems integrators), the situation has also changed. The set-up is increasingly polarized. Outsourcing of systems maintenance and routine services have been commoditized, service performance is excellent and supply is maturing. Developing new solutions on the other hand – providing the sought-after competitive advantage is not just based on software selection, but it is a cocktail of software, architecture, connectivity, deployment, access, presentation and customer intimacy. Those who can demonstrate they have genuinely internalized the customers’ business, those who benefit from the changing environment and those who can orchestrate the abundance of options into sustainable, customer-specific solutions will prevail.

B2BC is the new transaction. Solutions need to be fitted for the Business-to-Business-Consumer. New solutions need to respect platform guidelines and policies yet tailored to the individual need. Decision makers cannot wait for release-cycles or consensus-driven applications. Business agility requires responsive business IT solutions, easy access and easy consumption. Digital business applications need to be an experience.

For Customers, there is a paradox in this evolution. On one hand, what could be easier than just buying software as a service or as cloud-based solutions? Pay-as-you-go, scalable licensing, no shelf-ware…Sounds familiar? Even if there were no budgetary limitations or nobody cared about sunk costs, or gave a damn about who owns the data, or worried how to integrate everything with everything – the new era is maybe even more difficult to manage than the old nut-and-bolt IT. Partners play an increasingly important role as interpreters and advisors. Ones who can decipher hype and put it into a customer context. Ones who can navigate and network with the new ecosystem on behalf of the customer. Ones who have the guts to challenge the customers’ fixations with best-practices.

The boundaries between business, IT, partners and solutions are becoming fuzzier and more converged. This makes tomorrow interestingly different compared to today. It also means that tomorrow’s IT partners, real-time business digitalists, will need to qualify in many new disciplines just to survive, and excel in them to succeed. And the transformation has needed to start yesterday for those who aspire to lead the way.


18.02.2014 / Jani Liimatta

Saimme joku aika sitten tehtäväksi mielenkiintoisen projektin. Pohjimmiltaan kyse oli antureiden tuottamasta raakadatasta. Tehtävänä oli tuottaa nivaska raportteja eri laitteiden antureilta saapuvasta datasta. Laitteiden määrä lisääntyy koko ajan, jokainen anturi tuottaa dataa 5-15 sekunnin välein 24/7. Osa datasta on kumulatiivista summadataa, osa taas antureiden tuottamia mittausarvoja.

Teknologiavalinta oli tehty etukäteen, SQL Server 2012 Standard. Aikataulu oli tiukka ja budjetti pieni. Muutamia haasteita  tunnistettiin heti alkuun:

  • Dataa on paljon, ja on varauduttava siihen että vuoden päästä sitä on paljon enemmän
  • Anturidata on muodoltaan haasteellista raportointia ajatellen. Datassa oli mukana kumulatiivisia summia, lisäksi raporteilla pitäisi tutkia kestoaikoja sekä muita mittareita, jotka saadaan laskettua rivien välisistä erotuksista. Koko datanmassa sellaisenaan SQL-kannassa aiheuttaisi lisäksi takuuvarmasti suorituskykyongelmia.
  • Antureiden antamat lukuarvot eivät kerro loppukäyttäjälle mitään, ne on käännettävä ymmärrettäviksi, tämä nyt oli kuitenkin ongelmista pienin
  • On myös otettava  huomioon antureilta tulevat virhearvot, nollautumiset jne.

Jossain vaiheessa projektia naureskelimme että hei, tämähän onkin nyt sitä hypetettyä Big Dataa!

Hieman dataa tutkittuamme totesimme että yli 95% antureiden tuottamasta datasta ei kiinnosta ketään. Itse asiassa raportoinnin kannaltahan käyttäjää kiinnostavat ne rivi, joilla on tapahtunut jotain, eli anturin antama arvo on muuttunut. Täytyy saada kiinni se rivi – ja ajanhetki –  jolla haluttu anturiarvo on muuttunut – sekä tätä edeltävä rivi. Tämän jälkeen lasketaan kestot, kappaleet, rivimäärät sekä otetaan kumulatiivista summista erotukset.

Tällöin päästään eroon itse asiassa kaikista datan ongelmista; data saadaan raportointiin kelpaavaksi, sekä suorituskykyongelmista päästään eroon kun, suuri osa riveistä heitetään romukoppaan.

Miten tämä sitten tehdään teknisesti? Saamme joka päivä snapshotin päivän tapahtumista. Kaikeksi onneksi yhden päivän datamassa mahtuu serverin muistiin helposti nyt ja tulevaisuudessa. Tästä datasta rakennetaan tietovarastoon kelpaava datasetti seuraavasti Transact SQL:llä:

  1. Luetaan anturidata tietotyyppi kerrallaan @Temp-tauluun, tauluun luodaan PRIMARY KEY IDENTITY(1,1)-sarake
  2. Käyttäen hyväksi tuota muistissa olevaa IDENTITY-saraketta, loopataan taulun sisältö läpi rivi kerrallaan. Koska data on serverin muistissa, sen läpikäynti SQL:llä on hyvin nopeaa. Verrataan rivi kerrallaan käsissä olevia arvoja edellisen käsitellyn rivin arvoihin.
  3. Jos käsissä olevalla rivillä on tapahtunut relevantti muutos, kirjoitetaan ko. rivi raporttitauluun. Muistissa on myös edellisen rivin arvot – sekä edellisen raporttitauluun kirjoitetun rivin anturiarvot, niitä käyttäen saadaan laskettua tarvittavat kestot kumulatiivisten summien erotuksina sekä aikaleimoista laskettua kestot.

Lopputuloksena käsissä on nopeasti toimiva, käyttäjäystävällinen, pieni tietovarasto alun perin massiivisesta anturidatasta.

SQL-logiikan läpiajo päivittäin vie muutaman minuutin. Tässä esimerkissä siis paljon hypetetty Big Data puristetaan vanhanaikaisilla, halvoilla ja nopeilla SQL-logiikoilla  loppukäyttäjän hyödynnettävään muotoon.

Vastaavan kompressoinnin datalle voi tehdä muillakin tekniikoilla, tässä tapauksessa yllä kuvattu SQL-logiikka oli nopein, käyttäjäystävällisin ja kustannustehokkain tapa ratkoa anturidatan raportintekijälle heittämät haasteet.


14.02.2014 / Lasse Liukkonen

Aikasarjat

Aikasarjat monelle lienee tuttu käsite, aikasarjoja esiintyy viikottain esimerkiksi useissa lehdissä, webbisivuilla ja talousuutisissa. Jos kuitenkin aikasarjat eivät ole sinulle tuttuja voidaan lyhyesti sanoa, että aikasarja on jonkin ilmiön (esim. pörssikurssi) ilmenemistä ajan suhteen mitattuna. Itse aikasarja-analyysi on tilastotieteen osa-alue, jossa pääpainona on usein miten löytää tarkastelevan sarjan generoima yleisempi (stokastinen) prosessi, jonka teoreettisia ominaisuuksia tunnetaan entuudestaan. Kuitenkin businessmaailmassa pääpainona ovat ennusteiden tekeminen tulevaisuuteen, sekä ennusteiden uskottavuuden estimointi, hieman teorian antamien raamien ulkopuolella.

Jos olet kiinnostunut aikasarjan analysoimisesta ja ennustamisesta antaa tämä blogi sinulle muutamia alkuaskelia, sekä ymmärrystä yksinkertaisen aikasarjan rakenteesta. Blogin teoreettinen sisältö, eksaktius ja optimaalisuus on jätetty “kotikokki” tasolle.

Blogin tarkoitus on esitellä aikasarjan “AD HOC” dekomponointi, jolla saamme melko hyvän kuvan aikasarjan komponenttien rakenteesta; trendi, kausivaihtelu, jäännökset. Kätevimmin aikasarjan dekomponoinnin saa tehtyä valmiilla R-ohjelman funktiolla stl, joka tekee dekomponoinnin automaattisesti LOESS-menetelmän avulla.

Aikasarjan formulointi

Käsittelemme blogissa esimerkkiä, jonka aikasarja on additiivinen, joka koostuu seuraavasti komponenteista:

Y(t) = T(t) + S(t) + R(t), missä

  • Y(t) on tarkasteltava aikasarja,
  • T(t) on trendikomponentti,
  • S(t) on kausikomponentti,
  • R(t) on satunnaisvaihtelun komponentti, ajan hetkellä t.

Se miksi ylhäällä mainittua aikasarjaa Y(t) kutsutaan additiiviseksi johtuu siitä, että sillä on summamuotoinen rakenne. Lisäksi estimoinnissa oletamme, että komponentit ovat (likimain) riippumattomia toisistaan. Vertailun vuoksi mainittakoon multiplikatiivinen aikasarjan rakenne

M(t) = MT(t) * MS(t) * MR(t).

Multiplikatiivinen aikasarja tulee tunnistaa ennen aikasarjan tarkempaa analysointia, jolloin voimme aikasarjan alkuaskelissa tehdä esimerkiksi logaritminen-muunnos, joka palauttaa aikasarjan additiiviseksi

m(t)=log(M(t)) = log(MT(t)) + log(MS(t)) + log(MR(t)).

Pitääksemme kirjoituksen sisällön ymmärrettävällä tasolla, oletamme additiivisuuden lisäksi ettei aikasarja sisällä satunnaisia mainoskamppanjoiden vaikutuksia tai muita epäsäännöllisiä tekijöitä, jotka vaikuttavat aikasarjan ”luonnolliseen” käyttäytymiseen esim. virheellinen aineisto.

Seuraavassa kuvat blogissa käsiteltävästä aikasarjasta (vasemmalla), sekä esimerkki multiplikatiivisesta aikasarjasta (oikealla).

Graafit

aikasarja

Käsiteltävä aikasarja

aineisto

“AD HOC”- ratkaisu

Tässä kappaleessa käymme läpi selkeän ja loogisen tavan estimoida tuntemattomat aikasarjan komponentit: T(t), S(t) (ja R(t)).

Askel 1:

Trendikomponentti T(t) voidaan estimoida aikasarjasta Y(t) esimerkiksi lineaarisen regression tai liikkuvan keskiarvon menetelmän avulla. Lineaarinen regressio tuottaa trendikomponentin suoran yhtälön muodossa, jolloin estimoitavana on suoran kulmakerroin ja lähtötaso. Mikäli aikasarjassa ei ole selkeää ”suuntaa” koko tarkasteluvälin ajan voi käyttää liikkuvan keskiarvon menetelmää. Liikkuvan keskiarvon menetelmän liukuma tulee määrittää aikasarjan “käytöksen” tai liiketoiminnan näkökannan avulla. Esimerkkiaineistomme muodostuu vuosittaisista kvartaaleista, joten luonnollinen valinta liukuvan keskiarvon liukumalle on 4 kvartaalia (4:n havaintopisteen liukuva keskiarvo, 1 vuosi).

Seuraavassa kuvat estimoiduista trendeistä; lineaarinen ennuste punainen ja liukuvan keskiarvon ennuste sininen. Käytämme jatkossa lineaarisen regression antamaa trendin ennustetta.

trendi_estimaatit

Askel 2:

Koska esimerkkiaineistossa oletimme, että aikasarjamme Y(t) on additiivinen, aloitamme kausikomponentin S(t) estimoinnin poistamalla aikasarjasta estimoidun trendin T*(t), jolloin jäljelle jäävät kausivaihtelu- ja jäännöskomponentti:

Y(t)-T*(t)=S(t) + R(t).

Nyt voimme helpoimmin estimoida kausivaihtelun ottamalla kvartaalittaiset keskiarvot (4 kpl sarakekeskiarvoja) ja toistamalla saatua keskiarvovektoria läpi tarkasteluajan. Tuloksena saamme kausivaihtelukomponentin (vuosittainen kausivaihtelu vakio läpi tarkasteluajan).

season

Askel 3:

Jäännöskomponentti saadaan jälleen vähentämällä aikasarjasta Y(t) jo estimoidut komponentit T*(t) ja S*(t)

Y(t) – T*(t) – S*(t) = R(t).

jaannos

Alkuperäinen aikasarja saadaan summaamalla edellä estimoidut komponentit T*(t), S*(t), R*(t) keskenään (aikasarja additiivinen). Nyt kun aikasarjan komponentit on estimoitu on esimerkiksi lyhyiden myyntiennusteiden tekeminen helppoa. Esimerkiksi, jos haluaisimme ennustaa vuoden 1981 ensimmäisen kvartaalin Q1(1981) myyntiennusteen saadaan se seuraavasti (tässä oletuksena, että trendi on estimoitu lineaarisen regression avulla, huom! vaikuttaa myös muiden komponenttien estimaatin arvoihin).

T*(1981) =-325.5476 + 0.1668*1981 , S*(1981)=0.01090243

Y*(1981)=T*(1981) + S*(1981)=4.88,

vertailuna Y(1980)=4.79.

Vertailtavana dekomponointina R-ohjelman stl-funktion (LOESS-menetelmä) antamat graafit aikasarjan komponenttien estimaateista.

R_loess

Mitä hyötyä ja etuja “AD HOC”/dekomponoinnista on?

  • Helppo implementoida esimerkiksi EXCEL:iin,
  • Antaa lisäymmärrystä aikasarjan komponenteista,
  • Auttaa manuaalisten ennusteiden tekemisessä,
  • Hyvä lähtökohta esimerkiksi ARIMA-mallien luomiselle.

EXTRA: Kuinka tarkistaa dekomponoinnin “onnistuminen” R-ohjelmalla?

Aikasarjan dekomponointi näyttää yleensä hyvältä silmämääräisesti, kuitenkin vasta tilastolliset tarkastelut kertovat todellisen komponoinnin onnistumisen. Tähän on R-ohjelmassa helposti käytettävät autokorrelaatioita laskevat funktiot acf ja pacf. Yleinen oletus tilastotieteessä on se, että jäännökset (tässä tapauksessa jäännöskomponentti) ovat korreloimattomia. Funktiot acf ja pacf laskevat autokorrelaatiot jäännöksistä erikokoisilla viiveillä, esimerkin tapauksessa riittänee 0-4 aikayksikköä. Mikäli acf- ja pacf-funktioiden antamista graafeista ilmenee, että autokorrelaatiot viiveillä 0.25,0.5,0.75,1 (kvartaalit) eivät ole tilastollisesti nollasta poikkeavia voidaan dekomponointia pitää hyvin onnistuneena. Huomioitavaa on, että yleensä tälläiseen optimaaliseen tilanteeseen ei päästä suoraan, eikä pidäkkään tuhlata merkittäviä työmääriä sen saavuttamiseen. Se kun on nyt vaan niin, että tosielämässä kaikki ei mene aina kuten Miedolla Innsbruckissa 1976.


14.02.2014 / Kristiina Burtsoff

Palautteen antaminen on taitolaji. Se on niinkin suurta taitoa vaativa laji, että aiheesta järjestetään kursseja ja kirjoitetaan oppaita. Useimmat tuntevat palautteenannon hampurilaismallin. Kyseenalaistaisin kuitenkin, miksi pihvin ympärillä pitäisi olla sämpylä? Pihvi on pihvi, ja se kannattaa syödä ensin, varsinkin jos se on hyvä pihvi. Sämpylän voi syödä, jos vielä pihvin jälkeen on nälkä. Palautteen kanssa on sama juttu. Hyvä palaute on hyvä sellaisenaan, oli se sitten korjaavaa tai kiittävää.

Olisiko jokaisen mahdollista antaa palautetta itse itselleen? Aikuinen ihminen yleensä tietää, mitä omaan työrooliin kuuluu, minkälaisia suorituksia häneltä työssään odotetaan ja minkälainen käyttäytyminen ja asenne vaikuttaa työyhteisöön hyvällä tavalla ja minkälainen huonolla. Jos ei tiedä, kannattaa äkkiä kipaista kysymään esimieheltä.

Palautetta saa myös pyytää, vaikka tyypilliseen esimies-alais-käyttäytymiseen usein kuuluu vain palautteen vastaanotto. Ja jos tällä saralla aikoo aktivoitua, niin samalla kun antaa itselleen palautetta ja pyytää sitä lisää esimieheltään, voi antaa sitä myös muille ympärillään; kollegoille, esimiehelle ja työpaikkaruokalan tädille. Aktiivisuus palautteenannossa synnyttää lisää palautteenantoa ympäristössä.

Koska palautteen antaminen ja vastaanottaminen on niin vaikeaa, olemme kehitelleet useita erilaisia prosesseja tukemaan tätä toimintaa. Kehityskeskustelu tulee mieleen ensimmäisenä. Jos terve itsearviointiprosessi pyörisi jokaisen työläisen aivoissa päivittäin, voisimme jättää palautekohdat lomakkeista täyttämättä. Omia ajatuksiaan voisi täydentää muistelemalla esimiehen ja kollegojen kommentteja vuoden varrella. Onhan selvää, että esimies kommunikoi alaisensa kanssa säännöllisesti tai edes joskus. Ja esimiehen sanavarastoon pitäisi kuulua seuraavia termejä: ”hienoa”, ”hyvin tehty”, ”kiitos”, ”entäpä jos…”.

Tähän loppuun voin myöntää, että olen itse huono systemaattisen palautteen antaja. Annan palautetta aina äkillisen innostuksen vallassa, ja kiireessä se unohtuu. Siksi on hyvä, että meilläkin on kehityskeskusteluprosessi.


12.02.2014 / News Team

Certia on vuoden 2013 aikana kilpailuttanut ostolaskujen ja muiden sähköisten dokumenttien kierrätysjärjestelmän asiakasyliopistojen käyttöön. Kilpailutuksen optiona ovat tilaukselliset ostolaskut sekä mobiiliratkaisu järjestelmän käyttöön.

Järjestelmäkumppanina Bilot Oy

Kilpailutuksen perusteella ostolaskujen kierrätysjärjestelmän toimittajaksi valittiin Bilot Oy. Ratkaisu on osa SAP-järjestelmää.

Käyttöönottoprojektin aloittaminen

Ostolaskujen kierrätysjärjestelmän käyttöönottoprojekti aloitetaan helmikuussa 2014. Tavoitteena on, että uusi järjestelmä on käytössä vuodenvaihteessa 2014/2015. Ensimmäisessä vaiheessa otetaan käyttöön myös kilpailutuksessa optiona ollut mobiiliratkaisu. Tilauksellisten ostolaskujen käyttöönotto ratkaistaan ensimmäisen käyttöönoton jälkeen.

Projektin tavoitteena on saada ostolaskuprosessi suoraviivaisemmaksi ja automaattisemmaksi käyttäen laskujen automaattista käsittelyä ja nopeampaa hyväksymiskiertoa. Uudella ratkaisulla Certia haluaa kasvattaa käyttäjätyytyväisyyttä harmonisoidulla ja yksinkertaistetulla prosessilla ja käyttöliittymällä.

Bilotin Line of Business Director Vesa Niininen on mielissään, että Bilot valittiin Certian kumppaniksi.  ”Bilot on toimittanut useita ostolaskujen kierrätysjärjestelmä- ratkaisuja yksityisellä sektorilla, mutta nyt pääsemme näyttämään kykymme myös julkishallinnon puolella. Ratkaisun täydentäminen mobiilikäyttöliittymällä antaa Certialle erityiset mahdollisuudet kasvattaa käyttäjätyytyväisyyttä palvelun käyttäjien keskuudessa. ”

Uutinen Certian sivulla

Lisätietoa:

Vesa Niininen, Line of Business Director, Bilot
+358 50 4420012


11.02.2014 / Ville Niemijärvi

FinnairFinnair ilmoitti tänään viime vuoden tappioista. Jotta kotimainen ylpeys saadaan taas liitoon, kannamme kortemme kekoon ja annamme ilmaisen vinkin Vauramolle ja samalla esimerkin kohdennetusta markkinoinnista ja ripauksen analytiikasta.

Jos Guggenheim ei tule Suomeen, Suomi menee Guggenheimin luokse (Bilbaoon)

Viime viikolla saatiin tieto, että Suomen koripallomaajoukkue, Susijengi, pääsee tämän vuoden koriksen MM-kisoihin Espanjaan. Ensimmäistä kertaa maan historiassa eli tämä on todella iso juttu.

Suomen alkulohko otellaan Bilbaossa elo-syyskuun vaihteessa ja nyt baskimaahan on suuntaamassa tuhansia suomalaisia korisintoilijoita. Viime vuonna Slovenian EM-kisoissa oli yli 3000 suomalaista fania ja Espanjaan povataan jopa 10 000 fanin ryntäystä. Siis oikea kansainvaellus!

Jonkun pitää kuitenkin lennättää korisväki paikalle. Juuri nyt netti käykin kuumana kun korisväki, minä siinä mukana, etsivät lentoja Bilbaoon. Guggenheim on hankalasti saavutettavissa sillä suoria lentoja ETA:n pääkallopaikalle ei Suomesta tehdä. Pitää siis kikkailla ja vaihdella lentoja/junia ties minkä kautta. Menee vaikeaksi. Ja menee kalliiksi koska kysyntää on siis ihan pöljänä.

Nyt tarvitaankin sinivalkoista sankaria paikalle. Nyt kaivataan Finnairia.

Korisväen matkakeskusteluissa on  esiintynyt lentoyhtiöistä niin Norwegian kuin KLM, mutta ei Finski. Missä vika? Finnair panostaa mainostamiseen niin netissä, suorana mailina kuin printissä. Mutta kohdennettu täsmämainonta ei näytä kuuluvan konseptiin vaikka tuotto-odotukset olisivat huimia.

Oikein tehty kohdennettu mainonta on palvelus vastaanottajalle

Se on odotettu tai iloisesti yllättävä viesti, jossa tarjotaan parhaimmassa tapauksessa tarpeellista tuotetta. Tänään mailiini Finnair Plus jäsenyyden kautta saamani Finnairin ystävänpäivän mainos ei kolahtanut niin ollenkaan. Roskiin meni. Mutta korisväelle suunnattu lentopaketti uppoaisi sukkana kuin Sasu Salinin kolmonen.

Ei tarvita analyytikkoa hoksaamaan, että nyt on kysyntää mutta ei tarjontaa.

Miten etenisin itse jos olisin Finnairin markkinoinnista vastaava:

  • hankkisin koripalloliitolta kaikkien suomalaisten lisenssipelaajien yhteystiedot
  • paketoisin helposti ostettavan tuotteen, jolla päästään Bilbaoon. Huom: USA-peli on 30.8 ja siihen pitää ehtiä! Paketti sisältäisi esim. Lennot Madridiin ja juna/lento Bilbaoon. All inclusive. Näin peitotaan norskit ja pilviyhtiöt.
  • lähettäisin kohdennetun mainosviestin maililla/postilla kaikille lisenssipelaajille, valmentajille ja tuomareille. Nopeus on valttia sillä väki on sormet näppäimistöllä luottokortti valmiina ostamaan.
  • viestiä ryydittämään nettimainos korisfoorumeille eli koripallo.comiin ja liiton sivuille basket.fi:hin

Kampanja maksaisi pari tonnia ja takaan, että sillä liikahtaisi muutama tuhat suomalaista punaviinin, taiteen ja koriksen ääreen sinivalkoisin siivin. Kansa maksaisi ja kansa kiittäisi.

Finnair, odotan mainostanne. Vinkatkaa jos tarvitsette apua noissa yhteystiedoissa. Tai muutenkaan.

Oikein tehty kohdennettu mainonta antaa moninkertaisen konversion massamainontaan nähden. Olennaista on löytää oikea kohderyhmä. Yleensä se tehdään analytiikan keinoin. Joskus riittää kuitenkin vain kun löytää tarpeeksi suuren joukon (urheilu)hulluja.