14.11.2019 / Antti Lyytikäinen

Noniin! Olet lukenut edelliset blogikirjoitukseni ja tullut siihen tulokseen, että tietovarastosi haisee kellarilta ja on ehkä aika tehdä jotain.

Mikäli olet SAP-asiakas, sinua varmastikin askarruttaa mihin SAP:n tietovarastotarjooma on menossa ja mitkä olisivat aikaa kestäviä valintoja esimerkiksi kolmen vuoden aikajänteellä. Suunta vaikuttaa hyvin selvältä – SAP keskittyy isoin satsauksin pilvitarjoomansa kehittämiseen.

Pilviratkaisut tuovatkin niitä tuttuja hyötyjä: nopeutta, joustavampaa hinnoittelua, yksinkertaisuutta ja skaalautuvuutta. Uusimpaan tietovarastotuotteeseen SAP Data Warehouse Cloudiin on luvattu juuri tätä ja ajatuksena tämä tietenkin kutkuttaa, varsinkin kun perinteisesti on-premise-pokerin hinta on ollut jotain aivan muuta kuin nyt luvattu käytettyyn tallennustilaan ja prosessoriaikaan perustuva kuukausihinnoittelu.

Tarkempia hintatietoja varmaan saadaan lähiaikoina, niitä odotellessa voi tutustua SAP Data Warehouse Cloudin ilmaiseen kokeilujaksoon.

Onko tuote sitten valmis itsenäisesti korvaamaan esimerkiksi ikääntyvän SAP Business Warehouse 7.x :n vai tulisiko harkita esimerkiksi SAP BW/4HANA-projektia?

Otin osaa SAP Data Warehouse Cloudin beta-ohjelmaan ja vaikka osa toiminnallisuuksista ei ollut beta-vaiheessa kokeiltavissa, uskoisin että yksinkertaisempiin tarpeisiin pilviratkaisu soveltunee varsin nopeasti. Lisää kokemuksia uudesta tuotteesta sain SAP TechEdissä ja varsinkin mallinnuksen helppous sekä suoraan tietovarastovälineeseen integroitu  SAP Analytics Cloud yhdessä teki vaikutuksen jopa kaltaiseeni vanhaan kyynikkoon.

Spaces-konseptin myötä tietomallinnus on toteutettu siten, että mennään aika paljon lähemmäs visiota itsepalvelu-BI:stä, jossa myös loppukäyttäjät pystyvät yhdistelemään tietoja joustavasti. SAP HANA Cloud -alustalla toimiva SAP Data Warehouse Cloud tuo uutta myös persistenssiin: tietoa voidaan säilöä usean tehoisella ja hintaisella medialla aina muistista data laken kautta hadoopiin asti ja lisäksi ratkaisuissa voidaan käyttää myös virtualisointia, jossa tiedot luetaan lähteestä säilömättä niitä erikseen tietovarastoon. Kaiken kaikkiaan olen pitänyt näkemästäni tähän mennessä.

Tuote on kuitenkin uusi ja ominaisuuksiltaan vielä rajattu ja varmasti juuri tästä syystä SAP tarjoaa lähitulevaisuuteen hybridimallia on-premise-sovellusten ja pilvimaailman välillä. Siirtymävaihe on varmaan arkitodellisuudessakin juuri tätä, eli nykyratkaisua kehitetään ja ylläpidetään ja pilviratkaisua kokeillaan uusiin tarpeisiin ja laajennetaan tarvittaessa. Toisaalta kilpailijoiden ratkaisutkaan eivät ole 100% verrattavissa esimerkiksi ominaisuuksilla kyllästettyyn BW:hen. Yhdellä hyppäyksellä pilvitietovarastoon ei siis ehkä vielä mennä, mutta ajateltavaa riittää, mikäli vanhan uusiminen on kovinkin ajankohtaista.

SAP Data Warehouse Cloudin kehitystahti on uskottavan ripeä – uusia iteraatioita uusine ominaisuuksineen julkaistaan muutaman viikon välein. Samalla vauhdikkaalla metodilla kehitetty SAP Analytics Cloud on melko lyhyessä ajassa kasvanut hyvinkin uskottavaksi tuotteeksi raportoinnin, analyyttisten sovellusten,  visualisoinnin ja suunnittelutoimintojen saralla.  Tämän vahvistaa esim. BARC BI Survey, joka on hyvin mielenkiintoista luettavaa.

Analytics Cloudin ottaminen integroiduksi osaksi lähes jokaisen SAP-pilvituotteen (S/4HANA Cloud, Successfactors, Cloud for Customer jne.) operatiivista analytiikkaa osoittaa myös SAP:n omaa uskoa tuotteeseen. Tästä kertoo myös se, että SAC on jatkossa SAP:n analytiikkatuotestrategian kärjessä, ks. tämä tuore  SAP Analytics & Business Intelligence statement of direction.

SAP Analytics Cloud onkin melko luonteva paikka aloittaa analytiikan pilvisiirtymä huokean hintansa ja tuotteen maturiteetin ansiosta. Seuraava askel voi olla sitten sen tietovaraston seuraaminen perässä.

Blogisarjan muissa osissa:

 


24.01.2019 / Lasse Ruokolainen
Good news: according to Señior Data Scientist, Lasse Ruokolainen, you don’t have to!

 

Monesti olen kouluttaessa kuullut kysymyksen: ”Kumpi on parempi, R vai Python”? Hätäisimmille lukijoille annan saman tien lyhyen, kokemusperäisen vastauksen: ei kumpikaan.

Jos et kuitenkaan tyytynyt tähän vastaukseen, taustoitan alla hieman, miksi olen tätä mieltä.

Historiaa

Olen itse pitkän linjan R-koodaaja. Tutustuin R-kieleen ensimmäisen kerran opintojeni loppuvaiheessa keväällä 2004. Tuolloin komentorivi herätti vielä melkoista hylkimisreaktiota (niin kuin monessa muussakin). Kuitenkin jo tulevana syksynä, kun aloitin siviilipalveluksen Metsäntutkimuslaitoksessa, aloin ymmärtää, että R:n opettelu tulisi olemaan välttämätöntä. Avoimen lähdekoodin ohjelmana uudet innovaatiot tuppaavat ilmestymään R:ään ensimmäisenä, ja laaja käyttäjäkunta tarjoaa korvaamatonta vertaistukea ongelmiin.

Kaksi viikkoa kestäneen intensiivisen treenaamisen jälkeen aloin olla riittävän sujut komentorivin kanssa, jotta kykenin jotenkin soveltamaan R:ää käytännössä. Takana on nyt lähes 15 vuotta lähes päivittäistä aktiivista tekemistä ja itseopiskelua. Tästä huolimatta en voi siltikään voi sanoa hallitsevani R:ää täydellisesti; opin jatkuvasti uutta. Etenkin R-Studion tulo ”markkinoille” on kasvattanut R:n mahdollisuuksia huimasti ja samalla tietysti lisännyt tarvetta omaksua uusia asioita.

Python onkin sitten itselleni paljon tuoreempi tuttavuus. Aloin ottaa tuntumaa ”pyyttoniin” noin vuosi sitten, kun siirryin yliopistosta yrityspuolelle. Käytännön asiakasprojektin kanssa työskentely joudutti oppimista, ja nyt kärmes alkaa totella jo melko kesysti. Toki osaamiseni rajoittuu pitkälti data-analytiikkaan, mikä on vain murto-osa siitä, mihin Python taipuu.

Näistä lähtökohdista voisi luulla, että kallistuisin ilman muuta R:n kannalle. Millä perusteella päädyin kuitenkin tylsään tasapeliin? Myönnän: olisin voinut valita toisinkin, kummankin kielen eduksi. Tämä johtuu siitä, että R ja Python on kehitetty hyvin eri tarkoituksiin. R:n (jonka beta-versio julkaistiin vuonna 2000) kehittivät tilastotieteilijät nimenomaan tilastoanalytiikan tarpeisiin, kun taas Python (ensimmäinen versio käytössä jo 80-luvulla) on yleisohjelmointikieli. Data-analytiikan saralla Pythonia on alettu toden teolla hyödyntää vasta 2010-luvun jälkeen, Pandas- ja Sklearn-kirjastojen myötä. Nykyään tilastomenetelmien kehitys tapahtuu edelleen ensisijaisesti R:ssä, kun taas koneoppimismenetelmiä (esim. neuroverkot ja vahvisteoppiminen) viedään voimakkaasti eteenpäin Pythonissa.

Molempi parempi?

Todenperään olen henkilökohtaisesti sitä mieltä, että on hyödyllistä hallita molemmat kielet, koska ne täydentävät kivasti toisiaan. Tämä ei kuitenkaan ole mitenkään välttämätöntä — kummalla tahansa pärjää mainiosti. Toki, R on kiistatta oikea valinta, jos tarpeena on tehdä monipuolisesti tilastoanalytiikkaa, kun taas Python on mielestäni parempi esimerkiksi datan lukemiseen (pandas-kirjastoa on vaikea päihittää tässä).

Yhdellä kielellä pärjäämistä helpottaa erityisesti se, että R ja Python lähentyvät jatkuvasti toisiaan data-analytiikan saralla. Koska molemmilla kielillä on mittava käyttäjä- ja kehittäjäkunta, on helppo ymmärtää, että molempiin kieliin tuodaan jatkuvasti parhaita ominaisuuksia toisesta kielestä.

Otetaan yksinkertainen esimerkki: datan muokkaukseen on R:ssä lyömätön dplyr-paketti (osa laajempaa tidyverse-kokonaisuutta). Jos esimerkiksi haluan laskea otoskoon moninaisen ryhmittelyn sisällä, on syntaksi yksinkertaisuudessaan:

data %>% 
group_by(grouping1, grouping2) %>% 
summarize(counts = n())

missä %>% on ns. putki-operaattori, jolla erillisiä operaatioita voidaan ketjuttaa. Tämän esimerkin toimenpiteen saisi tietysti myös tehtyä esim. aggregate-funktiolla, mutta dplyr:in hienous piileekin siinä, että operaatioita voidaan ketjuttaa loputtomasti, mikä mahdollistaa hyvin monimutkaiset muokkaukset. Jos on tykästynyt dplyr:iin ja kaipailee samanlaista Pythoniin (pandas toki mahdollistaa lähes vastaavan funktionaalisuuden), tähän on olemassa ratkaisu: dfply-kirjasto, jolla em. esimerkki koodataan näin:

(data >> 
 group_by(X.grouping1, X.grouping2) >> 
 summarize(counts = n()))

Rython, PythoR, …

R-Python integraatio on nykyisin sen verran aktiivista, että voisi luulla tämän olevan ihan päämäärätietoista. Python-puolella yhdentymistä pyrkii edistämään rpy2 -kirjasto, joka tuo käytännössä R:n Pythoniin. Vastaavasti, Pythonin koneoppimisvahvuuksia on tuotu R:n puolelle, esimerkiksi kääntämällä Keras-kirjasto R-kielelle. R:stä on myös mahdollista tehdä kutsuja Pythoniin ja pyytää dataa takaisin rPython-paketin avulla.

Toiminnallisesti vastaavia paketteja löytyy molemmista kielistä. Pythonin suosittua sklearn-kirjastoa taas vastaa hyvin pitkälti caret-R-paketti ja R:n visualisointipaketti ggplot2:a vastaa Pythonissa seaborn-kirjasto. Alustojenvälistä työskentelyä on helpotettu jopa luomalla uusi dataformaatti, jota molemmat kielet tukevat. Formaatin nimi on feather, ja se on käytännössä kieliagnostinen binäärinen tiedostorakenne datataulukoiden säilömiseen. Lukemalla feather-tiedoston R:ään (read_feather-funktiolla) palauttaa data.frame -objektin, kun taas Python (feather.read_dataframe-funktiolla) palauttaa pandas.DataFrame -objektin.

R:n ja Pythonin yhteen naittaminen on tehty jopa niin helpoksi, että molempia voi käyttää rinnan samassa ohjelmassa. Asentamalla reticulate -paketti on R-Studiossa mahdollista ajaa Python-blokkeja (kuten myös esim. bash, SQL ja Stan -blokkeja) R-Notebook-tiedostoissa. Esimerkiksi datan lukeminen Pythonin avulla R-Studiossa onnistuu vaikka näin:

```{python}
import pandas as pd
df = pd.read_csv('data.csv')
```

missä ` ` `{python} ` ` ` rajaa Python-koodi blokin.

Primääristi Pythonille tarkoitetuissa Jupyter Notebook -tiedostoissa taas voi ajaa R-blokkeja (sekä esim. julia, java ja ruby -blokkeja). Varsinkin Jupyter Notebook-maailmaan perehtymistä voi suositella, sillä monilla moderneilla koneoppimis-alustoilla — mm. DataBricks, Azure ML Service ja kotimainen Valohai — operoidaan pitkälti juuri näitä ”muistivihkoja” käyttäen. Jupyter Notebook:issa Star Wars hahmojen keskipituuden laskeminen silmien värin ja sukupuolen suhteen onnistuu R:llä esim. näin:

%load_ext rpy2.ipython
%%R
require(dplyr)
starwars %>% 
   group_by(eye_color,gender) %>% 
   summarize(`mean height` = mean(height)

Loppuun pieni mainos: Jos kiinnostuit aiheesta ja haluaisit tietää lisää, tervetuloa osallistumaan vetämiini R- ja/tai Python -koulutuksiin (tai muihin koulutuksiimme).


5.10.2016 / Jaana Lahtinen

Autamme asiakkaitamme mittaamaan heidän asiakaskohtaamisia mm. verkkokaupoissa, jolloin siitä saadut tiedot antavat hyvää informaatiota asiakkaidensa käyttäytymisestä. Oikein analysoituna tämä tieto auttaa verkkokauppayhtiötä parantamaan kaupan toimintoja ja kohdistamaan kampanjoitaan paremmin – siis tuottamaan lisämyyntiä, mutta myös tuottamaan parempia asiakaskohtaamisia. Samaan aiheeseen pureutui Jenna Ruostela blogissaan Jalosta asiakaskohtaamisista, kerätty data ymmärrykseksi ja toimenpiteiksi.

Mittaamme myös omia asiakaskohtaamistamme niin projektien kuin palveluiden näkökulmasta. Analysoimme tulokset yhdessä asiakastiimien kanssa. Opimme ja kehitämme tapaamme toimia ihan joka viikko. Pyrimme pelkkien numeroiden lisäksi käymään avointa keskustelua asiakkaidemme ja tiimiemme kanssa, sillä pelkät numeroista tehdyt päätelmät voivat johtaa harhaan. Blogissaan Todistuksenjako Kristiina Sarén avaa lisää tapaamme analysoida asiakaskohtaamisiamme.

Oli kyseessä sitten sähköinen kohtaaminen verkkokaupassa tai projektin/jatkuvan kehittämisen kasvokkain tapahtuva asiakaskohtaaminen, pitää olla määriteltynä miten haluamme kohdata asiakkaan yrityksenä – asiakaskohtaamisen kulttuuri. Tällaisessa asiayhteydessä kulttuuri on mielestäni jaettuja asenteita, tavoitteita ja käytäntöjä, jotka yhdistävät organisaatiota.

Jokaisen asiakaskohtaamisen takana on aina yksi tai useampia henkilöitä, ihmisiä, jotka kohtaavat, siksi ei riitä, että pelkästään analysoimme saatua dataa lukuina. Huomioitavaa on myös se, että tämä koskee kaikkia yrityksessä työskenteleviä ei vain ns. asiakaspalvelua, jokainen kohtaaminen vaikuttaa asiakkaan kokemukseen yrityksestämme – olemme siis kaikki vaikuttajia.

Asiakaskohtaamisten kulttuuri kajakissa Kuva: Jaana Lahtinen

Oletammeko vain, että kaikki asiakaskohtaamisissa olevat henkilöt luonnostaan tietävät miten me yrityksenä haluamme kohdata asiakkaan? Olemmeko oikeasti määrittäneet sen yritystasolla, onko meillä asiakaskohtaamisen kulttuuri? Uskoisin, että monessakin yrityksessä oletetaan ja pidetään tätä jotenkin itsestään selvyytenä. Miten uusi yritykseen tuleva työntekijä voi tietää mitä me yrityksenä odotamme asiakaskohtaamisista?  Kuinka moni kouluttaa jatkuvasti kaikkia asiakasrajapinnassa olevia hengittämään haluttua kulttuuria? Kenkiä myyvä Zappos kouluttaa henkilöstönsä asiakaskohtaamisen kulttuuriin, tästä kerrotaan Kissmetrics:n blogissa Zappos-art-of-culture, olisiko vastaavanlaisesta ajattelumallista opittavaa myös Suomessa?

Kun avoin asiakasakohtaamiskulttuuri on saatu eloon, on paljon helpompaa määrittää mitä haluamme mitata, miten saatua dataa analysoidaan ja miten saadut tulokset jalkautetaan osaksi kulttuuria. Miten teidän yrityksessänne, onko kulttuuri kunnossa?


25.08.2016 / Jukka-Pekka Sokero

Ote elävästä elämästä: Asiakaspalvelu käy lävitse seinälle kiinnitettyjä printtejä löytääkseen asiakkaan tiedot, avaa ERP:n käyttöliittymän hyvityksen kirjaamiseksi, kirjoittaa sähköpostin tuotepäällikölle tuotevirheestä ja tallentaa exceliin ERP-kirjauksen tiedot hyvitysten seuraamiseksi johdon kojetaululla.

Edeltävä voi olla hyvinkin menneisyyttä, mutta yllättävän monessa yrityksessä edelleen todellisuutta. On vaikea kiivetä tikkaita ylöspäin kohti yhdenmukaista, ylivertaista asiakaskokemusta ja analyyttistä myynnin ja markkinoinnin kehittämistä, jos pohja pettää alta.

Miten teillä?

Asiakkuuksien johtaminen on paljon enemmän kuin asiakastietoa ja tapahtumia CRM-järjestelmässä. Keskeistä on, mitä yrityksesi strategia sanoo, miten sitä voi asiakasanalytiikan pohjalta mahdollisesti haastaa ja miten saat strategian osaksi päivittäistä toimintaa – järjestelmien tukemana.

Strategisen asiakkuuksien kehittämisen pohjaksi tulee kerätä kaikki mahdollinen data asiakkaista. Eri asiakaskohtaamisten kanavilla ja käyttäjäryhmillä on kuitenkin erilaisia tarpeita, joten tarjolla olevan asiakasymmärryksen tulee olla suurelta osin valmiiksi pureskeltua ymmärrystä – ei vain raakaa dataa. Tämän mahdollistavat helposti saatavilla oleva inhimillisellä näkemyksellä täydennetty asiakasanalytiikka ja mittaristot.

Analyyttinen asiakaskohtaamine n ja CRM - miten jalostaa datasta polttoainetta omalle avaruusmatkalle?

Viisi vinkkiä asiakaskohtaamisten kehittämiseen CRM:n avulla:

1. Määrittele yrityksen tavoitteet ja toimintamallit asiakaskokemuksen, yrityksen strategian, asiakkaan ja itselle saatavan arvon pohjalta.
2. Varmista, että käytössä on yhdenmukainen, ajantasainen ja laadukas perustieto. Asiakastiedon ytimenä voi toimia niin ERP, CRM kuin master data -järjestelmäkin.
3. Tarjoa kaikille asiakkaita kohtaaville 360-asteen asiakasymmärryksen kattava työkalu. Se voi pohjautua CRM- tai analytiikkaratkaisuihin.
4. Liitä CRM-alustaan markkinointiprosessit, tuo analytiikan tuottama asiakasymmärrys sekä päättäjille että automaation avulla suoraan digitaalisiin asiakaskohtaamisiin
5. Käytä, kysy ja kyseenalaista saatavilla olevaa tietoa.

Harvard Business Review 2014: The New Marketing: Real-Time, Relevant and Engaged -raportti tarjoilee lisää ajatuksia aiheesta.
Lataa Harvard Business Review käyttöösi

Lue lisää asiantuntijoidemme ajatuksia aiheesta:





19.08.2016 / Mikko Mattila

Gartner ennustaa, että vuoteen 2018 mennessä yli puolet suurista, maailmanlaajuisista organisaatioista kilpailee käyttäen edistyksellistä analytiikkaa ja omia algoritmejaan aiheuttaen luovaa tuhoa kokonaisille toimialoille.
Menestyäkseen yritysten on kyettävä tarjoamaan asiakkailleen, ei hyvä, vaan erinomainen asiakaskokemus.

Paras yksilöity kohtaaminen tarvitsee tuekseen automaatiota, jota ohjaa analytiikka. Miksi? Koska kone päihittää ihmisen monella saralla:

  • Koneellisesti kerätty, merkityksellinen taustatieto vrs. asiakaspalvelijan kohtaamisen aikana luettelemat kysymykset
  • Nopeat, koko tietovarastoa hyödyntävät johtopäätökset vrs. yhden henkilön kokemuksiin perustuvat päätökset

Käytännön elämässä automatisoidut ja analyyttiset kohtaamiset ilahduttavat muun muassa silloin, kun Uberin sovellus kertoo, mikä auto saapuu ja milloin. Sovellus kertoo myös reitin ja ennakoi hinnan. Vastaavassa tilanteessa taksikeskus tarjoaa vain varausnumeron, jonka perusteella voin vain olettaa kyydin saapuvan joskus.
Edistyksellisimpi analytiikan hyödyntäjiä ovat B2C-allalla toimivat yritykset. Väitän, että edistyneen analytiikan kirkuvin kipupiste B2B-sektorin yrityksillä on laadukkaan datan puute.

Mutta mihin tarvitaan dataa, jos tuote on kunnossa?

Räjähdysvaara-Analyyttinen-asiakaskohtaaminen

Havainnollistetaanpa asiaa viettämällä hetki avaruusalalla. Ennustavaa analytiikkaa voi verrata avaruusrakettiin. Tarvitset voimakkaan moottorin eli analytiikkaohjelmiston ja rakettipolttoainetta eli laadukasta dataa. Lentäjän ja moottorin saat rahalla ja pienellä koulutuksella. Vaativimmaksi kehityskohteeksi erityisesti B2B-yrityksissä näen rakettipolttoaineen keruun. Päivittäisissä kohtaamisissamme lähes jokainen CIO korostaa, kuinka paljon heillä on dataa. Tämä data on avaruusraketti-kontekstissamme raskaaseen polttoöljyyn verrattavaa tavaraa, jolla raketti ei lennä. Jotta raskaasta polttoöljystä saa rakettibensaa, sitä on jalostettava, ja ennen kaikkea siihen on lisättä lukemattomia lisäaineita. Perusjalostus on B2B-yrityksissäkin kohtuullisesti kunnossa, mutta arvokkaisiin lisäaineisiin verrattavaa tietoa loppuasiakkaista riittävän monesta kanavasta heillä on olemattoman heikosti.

Mitä pitäisi tehdä tänään, jotta voisi lentää seuraavalla tilikaudelle Marsiin? Alla lista, ajatuksia joihin kannattaa tarttua tänään:

  1. Julkista tuote, jonka perimmäinen tarkoitus on kerätä arvokasta dataa asiakkaasta. Niin maailman parhaatkin tekevät jo. Luo hyvä palveluportaali tai käynnistä lopulta se IoT-hanke. Keskustele verkossa. Analysoi yksityiskohtaisesti, milloin ja miten loppukäyttäjä käyttää tuotettasi tai palveluasi.
  2. Kerää kaikki raakadata talteen: web-palvelimet, some-analytiikka, digikampanjoiden tiedot. Näiden avulla luot todellisia kohderyhmiä ja teet aidosti osuvia next-best-offer-ehdotuksia verkkosivuilla ja asiakaskäynneillä.
  3. Kerää kaikki data yhteen paikkaa, myös asiakastyytyväisyystulokset, mielikuvamittaukset – aivan kaikki. Monet maailman johtavista hyödyntävät tähän Hadoopia.
  4. Kutsu kaikki talkoisiin. Viritä rakettimoottoriasi ja kehitä henkilöstöäsi, niin he kertovat mitä lisäaineista sinulta vielä uupuu.

Data ja osaaminen jalostuvat käyttämällä. Ryhdy keruuseen tänään ja voit lentää heti – pian huomaat olevasi yksi heistä, joka saa aikaan luovaa tuhoa.

Harvard Business Review 2014: The New Marketing: Real-Time, Relevant and Engaged -raportti tarjoilee lisää ajatuksia aiheesta.
Lataa Harvard Business Review käyttöösi

Lue lisää asiantuntijoidemme ajatuksia aiheesta:





15.07.2016 / News Team

Bilot toimitti Heinon Tukulle asiakas- ja tuotekannattavuuslaskennan sekä raportoinnin ratkaisut. Ratkaisu perustuu kustannusten tehokkaaseen jakamiseen aina laskuriville asti hyödyntäen SAP:n uusimpia kustannus- ja kannattavuuslaskennan sekä tietovarastoinnin teknologioita. Lukujen
analysointiin ja raportointiin.

Heinon Tukku käyttää SAP:n raportointityökalua.
Tehokkaat työkalut ja hyvin rakennettu laskentamalli mahdollistavat nyt kustannusten ja kannattavuuden tarkastelun useista eri näkökulmista
mm. asiakkaittain, tuotteittain, myyntikanavittain ja prosesseittain.

Heinon Tukku harjoittaa päivittäistavaroiden, alkoholijuomien ja toimistotarvikkeiden tukkukauppaa ja maahantuontia sekä liha- ja kalatuotteiden jalostusta. Yritys haluaa tarjota parasta niin asiakkailleensa, henkilöstölleen kuin ympäristöllekin. TukkuHeino-konsernin liikevaihto vuonna 2014 oli n. 239M euroa ja henkilöstömäärä 450 henkilöä. Heinon Tukku on yksi Tuko Logistics Osuuskunnan omistajista Wihuri Oy:n, Suomen Lähikauppa Oy:n ja Stockmann Oyj Abp:n rinnalla.

Heinon Tukku on ollut SAP:n käyttäjä vuodesta 2006. Bilot on ollut Heinon Tukun ratkaisutoimittajana vuodesta 2009, toimittaen ratkaisuja verkkokauppaan, varastonhallintaan, ostolaskujen hyväksyntään ja asiakkuudenhallintaan – ja nyt uutena alueena asiakas- ja tuotekannattavuuslaskentaan.

Kannattavuuslaskennan kehittäminen
Heinon Tukku on tehnyt aiemmin pieniä selvityksiä kustannus- ja kannattavuuslaskennan saralla kuten vuonna 2011 toimintolaskennan yleiskustannusten allokointiharjoitus prosessi- ja toimintotasolla. Tällöin kustannuksia ei kuitenkaan vielä viety asiakas- ja tuotetasolle. Heinon Tukulla on enemmän kuin 25 000 tuotetta ja tuhansia asiakkaita, joten kustannusten hajoittamiseksi tuotteille ja asiakkaille tarvittiin tehokas allokointityökalu. Kuukausittain käsiteltävät 114 000 keräilyriviä vaativat lisäksi paljon työkalun suorityskyvyltä.

Allokointityökaluksi valittiin SAP:n kustannus- ja kannattavuuslaskentaratkaisu jo aiemmin laajan SAP-tuotteiden käytön myötä. Lisäksi otettiin käyttöön raportointiin ja analytiikkaan SAP:n tietovarastoinnin työkalu.
”Toimittajaksi valitsimme Bilotin, koska heillä oli selkeästi teknisen toteutusosaamisen lisäksi tarjota liiketoimintakonsultointia siitä, miten toimintolaskentamalli kannattaa rakentaa tarpeiden täyttämiseksi ja miten saatuja laskentatuloksia voidaan hyödyntää liiketoiminnan ohjaamisessa”, Heinon Tukulla kannattavuuslaskennan kehitysprojektista vastannut kehityspäällikkö Tommi Klemola kertoo.

Aikaperusteinen toimintolaskenta helpottaa ja selkeyttää mallia ja sen ylläpitoa
Määrittely aloitettiin laskentasääntöjen mallintamisella Excelissä. Bilotin suosituksesta yleiskustannusten allokoinneissa on hyödynnetty aikaperusteista toimintolaskentaa, minkä myötä toimintojen tarkastelu on ollut selkeää. Mallinnuksessa on aikaa vievien kyselyiden ja suhteellisten osuuksien arvioinnin sijaan arvioitu ja mitattu toimintojen tekemiseen käytettyjä aikoja.


”Toimittajaksi valitsimme Bilotin, koska heillä oli teknisen toteutusosaamisen lisäksi tarjota liiketoiminnalista näkemystä, josta saimme erityistä lisäarvoa.” Marja Hämäläinen, toimitusjohtaja, Heinon Tukku Oy.

Aikaperusteinen tarkastelu tukee aiempaa paremmin prosessien ja näiden kustannusrakenteiden kehittämistä tulevaisuudessa ja pystyy tuottamaan parempaa tietoa esimerkiksi palveluiden hinnoitteluun. Hyvin suunniteltu malli antaa paljon liiketoimintakriittistä tietoa.

”Lähtötavoitteena oli saada tarkempi kuva asiakkaiden ja tuotteiden kustannuksista ja kannattavuuksista aina EBIT:iin asti”, Tommi Klemola kuvaa.

Tietoa prosessien kustannuksista tarvitaan enenevässä määrin tukemaan keskusteluja asiakkaiden kanssa. Bilotin toimittama laskentamalli ja raportointi mahdollistavat kannattavuuden raportoinnin asiakkaittain, tuotteittain ja kanavittain ja sen analytiikkaan on mahdollista tuoda helposti uusia myynnin dimensioita, jolloin tuotettu informaatio on rikkaampaa ja sillä on laajemmat käyttökohteet. Lisäksi itse laskentamallin laajentaminen uusilla prosesseilla ja toiminnoilla on jatkossa helppoa. Mallin tuottamista luvuista pystytään näkemään helposti syy-seuraus –suhteet, esimerkiksi että pienien erien keräily per kilogramma tulee kalliimmaksi, kuin suurien erien keräily tai että sähköinen tilaus ja puhelintilaus ovat kustannuksiltaan erilaiset.

”Jatkossa kustannus- ja kannattavuusraportoinnin antamia tietoja tullaan käyttämään kasvavassa määrin yrityksen ohjaamisessa – niin hinnoittelun tukena kuin suuremmissakin liiketoiminnan linjauksissa. Lisäksi mallin käyttöä tullaan laajentamaan Heinon toimitustukun Espoon yksiköstä muihin yhtiön yksiköihin”, Tommi Klemola summaa.