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:

 


13.11.2019 / Antti Lyytikäinen

Miksi valita BW/4HANA?

Ei ainakaan nimen takia. Kirjainlyhenteet, numerot ja kenoviivat samassa pötkössä, herra mun vereni. SAP tunnetaan talona, joka vaihtaa tuotteidensa nimiä, eikä se aina ole hyvästä. Tuoreessa muistissa on esimerkiksi työpöytien ja visuaalisen analytiikan luomisen välineiden SAP Design Studion ja Lumiran niputtaminen Lumira-nimen alle – entuudestaan hyväksi havaittu Design Studio sai tässä iholleen tatuoinnin, jota varmasti katuisi, jos omaisi tietoisuuden. Silti toivon, että nämä kenoviivatuotteet vaihtaisivat nimeään.

Ei nimi kuitenkaan itse tuotetta pahenna, sillä kyseessähän on robustiksi jalostunut tietovarasto-ohjelmisto, luonnollinen lisä SAP-merkkisen toiminnanohjausjärjestelmän kaveriksi. Tällä SAP ERP + Business Warehouse (BW) parivaljakolla useat yritykset ovat pärjäilleet oikein mukavasti pitkään. Moni BW-installaatio alkaa kuitenkin olla elinkaarensa päässä ja hyppy tutusta 7.x -ympäristöstä ”uuteen” BW/4HANAan arveluttaa jo senkin takia, että uusin iteraatio on erikseen lisensoitava tuote.

BW:n käyttöönottoa ja tunnettuutta onkin taatusti jouduttanut se, että sen on saanut aiemmin ikään kuin kylkiäisenä. Kolikon toisella puolella on kuitenkin se fakta, että monissa asioissa kilpailijoitaan parempi tuote ei ole tuottanut itsenäisesti pennin pyörylää toimittajalleen, kehityspanostuksista huolimatta.

Tätä rahareikää on sitten tilkitty erilaisilla lisenssikummajaisilla (OpenHUB-lisenssin tuntenevat kaikki BW-kiemuroissa pitkään painineet) ja rajoituksilla, jotka pääosin liittyvät datan vientiin ulos järjestelmästä. Ilmainen mutta suljettu järjestelmä.

BW/4HANA on datan loppukohteista vähemmän mustasukkainen: dataa saa viedä toisiin järjestelmiin, nimettyjä SAP-käyttäjiä ei tarvita ja analyytiikkavälineet tietovaraston saa valita vapaammin itse. Myös kolmannen osapuolen lähteistä tiedon tuominen sisään on aiempaa joustavampaa. Tämän päivän monitoimittajaympäristöissä nämä ovat käytännössä pakollisia vaatimuksia. Maksullinen mutta avoin järjestelmä.

Teknisesti BW/4HANAssa on paljon samaa kuin viimeisimmissä 7.x -sarjan versioissa. Mallinnus on kuitenkin siirtynyt käytännössä kokonaan SAP GUI:sta Eclipseen, joten kulmakerrointa on jonkin verran myös vanhoille BW-ketuille. Mallinnus itsessään on aiempaa yksinkertaisempaa, koska ”osattavaa” on vähemmän, sillä mallinnusobjektien määrä on tippunut radikaalisti. Napanuora 3.x: n antiikkisiin objekteihin on myös viimein lopullisesti katkaistu.

Ehkä suurin lisäarvo tulee kuitenkin uudistetusta Business Contentista. Business Content tarkoittaa SAP:n toimittamia valmiita malleja, joilla mahdollistetaan nopea tietomallien kehitystyö lähteestä raportille asti. Eli esimerkiksi talouden tai logistiikan osa-aluille on mahdollista aktivoida valmis sisältö, jolla perustarpeet tyydyttävä raportointiratkaisu on helppo toteuttaa. Tämä toki on ollut BW:n etu kilpailijoihin nähden jo vuosikaudet, mutta nyt sisältö on tehty uusiksi uudempia mallinnuskäytäntöjä hyväksikäyttäen. Esimerkkinä tästä on näkymien käyttö fyysisten objektien sijaan, kannan vaatima tila pienenee huomattavasti.

Viimeinen motivaattori voi olla käytännön pakko: 7.x -tuki loppuu joidenkin vuosien kuluttua, vanhan järjestelmän elinkaari voi olla jo turhankin pitkä, tietotarpeet pakottavat viemään tietoa muihin kohteisiin, ylläpito hankalaa, infran uusiminen liian suuri investointi suuren kannan vuoksi, heikko tai turhan monimutkainen toteutus, jossa häärännyt liian monta kokkia ja niin edelleen.

Miksi siis BW/4HANA?

  • Avoimuus
  • Aiempaa joustavampi ja helpompi mallinnus
  • Uusi Business Content
  • Tukea tiedossa 7.x -versioita pidempään
  • On jo korkea aika

Bilot tuntee SAP:n, BW:n, HANA:n ja näiden yhdistelmät sekä vaihtoehtoiset ratkaisut. Vyöllä komeilevat tosielämän toteutukset, joista kerromme mielellämme lisää.

Blogisarjan muissa osissa:


12.11.2019 / Antti Lyytikäinen

Seuraa täysin hypoteettinen skenaario, yhtymäkohdat todelliseen elämään ovat täysin sattumanvaraisia.

Otetaan yksi kappale keskisuuria tai suuria yrityksiä. Laitetaan sinut vastuuseen raportoinnista.

Yrityksen raportointi on rakennettu SAP Business Warehouse -tietovarastoalustalle, se kattaa ehkä ydintarpeet talousraportoinnista, ehkä logistiikkaraportoinnin ja muita osa-alueita. Tärkeä päivittäinen, viikoittainen tai kuukausittainen työväline.

Tietovarasto on rakennettu ERP-projektin jälkitöinä 11 vuotta sitten. Peruspäivitykset on tehty, mutta muuten tietovarastossa alkaa haista jo kellarilta. Tukitoimittaja on vaihtunut kolme kertaa ja se yksi taitava kaveri, joka aikoinaan teki paljon itse, on jo lähtenyt talosta.

Raporttien ajamiseen käytät raportointiportaalia, josta vartin tiimalasin jälkeen saat luvut ruudukkomuodossa selaimeesi. Äh, unohdit kuitenkin täyttää yhteen triviaaliin muuttujavalintaan oikean arvon.

Ajat uutta raporttia toisen vartin.

Tiputat luvut Exceliin ja teet taulukkoon käsin korjauksia, koska tiedät että osa luvuista ei näy uusimman organisaatiorakenteen mukaisesti. Olet korjannut sen käsin jo kahden edellisenkin organisatorisen mullistuksen jälkeen, menee jo rutiinilla.

Mutta hetkinen, kuluvan kuukauden tiedot puuttuvat. Avaat tiketin.

Palvelusopimustason mukaisesti saat iltapäivällä vastauksen, että asiaa tutkitaan.

Seuraavana päivänä tikettiin on ilmestynyt tekninen selvitys aiheesta: tiedot lähdejärjestelmältä lataava prosessiketju on jumittunut koska taulualue on täyttynyt, tulee virhettä ja monitorit ovat ihan punaisella. Tukiorganisaatiolla propellit pyörivät hatuissa niin että savu nousee, pitää soittaa Basis-asiantuntijalle joka työskentelee eri aikavyöhykkeellä, avata palvelupyyntö SAP:lle, tai jotain muuta mukavaa. Kuukausiraportoinnin takaraja alkaa uhkaavasti lähestyä ja tiedot pitäisi vielä visualisoida Powerpointilla johdoportaalle ymmärrettävään muotoon.

Tukipalvelun tarjoaja koittaa ratkaista ongelmaa. Muutaman, erittäin pitkään kestävän, uusintalatauksen jälkeen järjestelmäjumalat ovat suosiolliset ja uusimmat tiedot on ladattu. Huraa, pääsit käyttäjänä pälkähästä! Jupiset kuitenkin, kun kesti taas kauan.

Juurisyy jää kuitenkin epäselväksi, koska tukipalveluoperaattorin pitäisi sitä varten perata satoja rivejä dokumentoimatonta ja kommentoimatonta koodia siirtosääntöjen abap-rutiineista, ratkoa miksi osa ratkaisuista löytyy vain tuotantojärjestelmästä, keksiä miksi käytetään räätälöityä ratkaisua standardin sijaan, ymmärtää miksi tauluista toisiin ladataan tietoja loputtoman tuntuisissa loopeissa, ymmärtää miksi asiakkaan ympäristössä käytetään jatkuvassa tuotantokäytössä objekteja jotka on nimetty ”Do not use!!” ”OLD”, ”ZDELETE, ”, ”obsolete”, miksi käytetään vanhentuneita mallinnustapoja, miksi latausjärjestystä ei datan keskinäisen riippuvuuden takia voi muuttaa ja mitäköhän ihmettä se yksi taitava kaveri, joka on jo lähtenyt talosta, oikein on ajatellut tehdessään kymmenen päällekkäistä DSO-taulua tietomalliin…

No, jos se toimii, niin ei kosketa siihen, eikä tätä nyt voida ainakaan tukipyyntöihin varatulla ratkaisuajalla tehdä, aika ei riitä. Käyttäjäkin sai jo datansa ja tikettijonossa on jo viisi uutta tapausta ratkottavaksi.

Tuen näennäisen kalleuden ja historiallisten uponneiden kustannusten takia kukaan ei uskalla ajatellakaan, että tehtäisiin asiat uudestaan fiksummin. Ehkä uusitaan vain se-ja-se raportointialue nyt ja katsotaan puolen vuoden päästä, kun käyttäjät itsepintaisesti käyttävät sitä vanhaa versiota, kun ovat siihen tottuneet.

Pitkästä elinkaaresta, moneen kertaan vaihtuneista toimittajista, nopeista ratkaisuista, purkkavirityksistä, pitkistä latausajoista, mysteerikoodista, jo lähteneistä taitureista ja päällekkäisistä nimeämiskäytännöistä se iäkkäämpi tietovarasto aika usein koostuu.

Mikäli edellä mainittu soittaa kelloja, olisiko aika auditoida nykyiset ratkaisut ja käytännöt?…

Blogisarjan seuraavissa osissa syynissä:

• BW/4HANA – Tietovarastoinnin työjuhta
• SAP Data Warehouse Cloud – Tietovarasto pilvessä


16.10.2019 / Mika Aho

Datastrategiaprojektin ehkäpä mielenkiintoisin vaihe on dataan pohjautuvien liiketoiminnan kehittämismahdollisuuksien tunnistaminen. Tänään pääsemme niiden kimppuun.

Jostain syystä näitä on kuitenkin vaikea tunnistaa. Gartnerin (2018) tutkimuksen mukaan noin kolmasosassa organisaatioista on vaikeuksia löytää sopivia käyttötapauksia datalle, johon varmaankin osasyynä on, että vain 12 %:lla on organisaation laajuinen datastrategia (Forbes, 2018).

Tiedä häntä ja tuskinpa noin. Isoimpana syynä luulisin, ettei tiedetä. Tämä näkyy erityisen hyvin vetämissämme bisnestyöpajoissa. Jos maturiteettitaso on alhainen, myös datan käyttötapaukset jäävät raportoinnin, analysoinnin ja manuaalisten työvaiheiden korvaamisen tasolle. Näillä ei ihan vielä luoda uutta distruptiivista liiketoimintaa, vaikka se konsernin strategiakalvoissa vilahtelisikin. Ei tiedetä datan mahdollisuuksista liiketoiminnassa tai olla kypsiä soveltamaan niitä.

Poikkeuksiakin löytyy — totta kai — ja usein vielä saman organisaation sisällä eri yksiköistä, toiminnoista tai ihmisistä.

Toisinaan konsulttina tekisi mieli muuttaa maailmaa hetkessä, mutta mitä enemmän eri (suur)yrityksiä on nähnyt, sitä enemmän tuntuu siltä, että niiden on vain kuljettava tietty polku mahdollisuuksien ymmärtämiseksi.

Mutta, asiaan.

Datasta näkemyksiksi ja business case -aihioiksi

Dataan pohjautuvia tietotarpeita ja liiketoiminnan kehitysmahdollisuuksia kannattaa tunnistaa eri näkökulmista. Kerron seuraavaksi muutaman niistä.

Siinä missä AI-työpajoissa business-ongelman identifiointi on systemaattisempi ja syvällisempi, pyritään datastrategiaprojektissa alkuun löytämään isompi joukko kehitysmahdollisuuksia sekä tekemään karsintaa myöhemmin. Halutaan ennemminkin muodostaa kokonaiskuva organisaation tarpeista ja datan mahdollisuuksista. Kevyttä priorisointia on silti hyvä harrastaa, kuten myöhemmin opimme.

Lähestytään kehitysmahdollisuuksia alkuun kolmen näkökulman kautta.

 

1. Datasta näkemyksiksi – jos kaikki olisi mahdollista

Mitäpä jos kaikki olisi mahdollista? Mitä haluaisit nähdä ensimmäisenä tietokoneesi tai mobiililaitteesi ruudulla kun tulet töihin?

Lähdetään alkuun liikkeelle loppukäyttäjästä (eli sinusta) ja mietitään, miten data käännetään helposti saatavilla olevaksi informaatioksi ja näkemyksiksi.

Olen vetänyt tätä harjoitusta useammalle sadalle henkilölle noin kymmenen vuoden aikana (on tullut muuten muutama takan pesällinenkin sytytettyä top-secret-dashboardeilla). Edelleen hämmästelen sitä, miten hyvin tämä harjoitus toimii ajatusten herättäjänä varsinkin kun ihmiset pääsevät aidosti kertomaan omista tarpeistaan. Hämmästyttävää on myös se, miten vähän eri yrityksissä keskustellaan tai tiedetään toisten (liiketoimintojen) tarpeista, vaikka istutaan melkein naapuripöydissä. Usein ollaan kuitenkin ihan perusjuttujen äärellä, kuten myyntipipen visualisoimisessa tai varastoarvojen raportoinnissa.

Tusseja, paperia ja post-it-muistilappuja

Dashboard-harjoitukseen tarvittavat välineet ovat tussit, oikein iso paperi (ideaalisesti revittynä fläppitaulusta) ja kasa post-it-muistilappuja.

Ajatuksena on yksinkertaisesti piirrellä omaa ideaalista dashboardia, jos kaikki olisi mahdollista. Korostaen vielä, että kaikki olisi mahdollista ilman datan, organisaation, teknologian tai prosessien tuomia rajoitteita.

Kun ideaaliset dashboardit on piirretty, kannattaa hetkeksi pysähtyä miettimään mikä toiminnassasi tai päätöksenteossasi aidosti muuttuisi, jos kaikki tämä informaatio olisi käytettävissä?

Usein vastaukset ovat ajansäästöä manuaalisten työvaiheiden karsimisessa tai parempia dataan pohjautuvia päätöksiä, jolloin ollaan vielä kaukana datan oikeista mahdollisuuksista liiketoiminnassa. Mutta se ei tämän harjoituksen tarkoitus ollutkaan.

 

2. Kysymykset datalle

Askarteluharjoitusten jälkeen on hyvä pohtia, millaisiin kysymyksiin et juuri nyt saa vastausta? Tämä tietenkin mielellään täydentäen nykyistä dashboardiasi.

Jos näkökulmana on esimerkiksi asiakas tai jo syventynyt asiakkuus, voivat kysymykset olla seuraavanlaisia:

  • Mitkä asiakkaat kasvavat?
  • Mikä on asiakassuhteen keskimääräinen kesto ja arvo?
  • Mitkä ovat asiakaspoistuman taustalla olevat syyt?
  • Miten brändimme vertautuu suhteessa kilpailijoiden brändeihin?

Tai jos mietit sisäisiä toimintoja, niin seuraavat kysymykset saattavat kiinnostaa:

  • Miten optimoimme toimitusketjumme?
  • Mitkä toimittajat ovat epäluotettavimpia ja miksi? Miten iso riski toimittajan konkurssilla on omaan toimintaamme?
  • Mikä liiketoiminnan osa altistuu eniten petokselle?
  • Mitkä ovat suurimmat keskeiset laatuongelmat, joihin törmäämme?

Tai jos olet vaikkapa henkilöstöhallinnosta, niin mahdollisesti nämä askarruttavat:

  • Mitkä työntekijät ovat todennäköisiä eläkkeelle jääjiä tulevan viiden vuoden aikana? Mitä osaamista tuolloin poistuu? Miten se voidaan korvata?
  • Minkälaisten työntekijöiden kohdalla on suurin riski lähteä ensi vuonna?
  • Mikä on näiden todennäköisten lähtijöiden osaamisprofiili?
  • Mitkä ovat kustannustehokkaimmat rekrytointikanavat tiettyihin positioihin?

Näitä kun kerää riittävästi ympäri organisaatiota, alkaa olla kasassa melkoinen lista tulevaisuuden tarpeista. Myöhemmin tietopääomavaiheessa sitten ihmettelemme, miten ja mistä näihin kysymyksiin saadaan datat.

Jotta linkki organisaation visioon ja missioon pysyy vahvana, ei muuten huono ajatus, jos tunnistetut kysymykset liittyvät jollain tapaa liiketoiminnan tavoitteisiin tai liiketoimintastrategiaan.

 

3. Liiketoiminnan kehityskohteet

Seuraava taso on miettiä eräänlaisia kevyitä business case -aihioita datalle. Puhun mieluummin aihioista, sillä business case itsessään on paljon laajempi asia.

Olen usein käyttänyt ajatusten herättelyn apuna seuraavaa nelikenttää, jossa tarkastellaan niin organisaation sisäisiä, kuin ulkopuoleltakin löytyviä kehittämiskohteita. Kuvassa oleva harmaa kolmio jakaa nelikentän näihin kahteen osaan.

Jos miettii pari aikaisempia harjoituksia, meillä itse asiassa on jo melkoinen nippu tavaraa kahteen alempaan lokeroon. Jonkin verran myös siniseen, mutta veikkaanpa, ettei juurikaan vielä keltaiseen.

Liiketoiminnan kehityskohteita onkin hedelmällistä pohtia ennen kaikkea asiakaskokemuksen sekä datan monetisoinnin ja kasvun näkökulmista. Tähän ei mitään hopealuotia ole olemassa, mutta erilaisia ryhmätöitä tekemällä on päästy oikeinkin hyviin tuloksiin. Hyvä tekniikka on jalostaa myös jo tunnistettuja kysymyksiä, joihin ei saada vastausta.

Kehityskohteiden listaamisen lisäksi kannattaa tuoda esiin myös saavutettavat hyödyt tai esimerkit sekä miettiä arvioitua euromääräistä hyötyä tai sopivaa KPI-mittaria.

Otetaan esimerkki digitaalisen asikaskokemuksen puolelta:

  • Käyttötapaus: Ostokäyttäytymisen siirtäminen private label -tuotteisiin sekä tähän liittyvä kampanjoiden optimointi
  • Edut/esimerkit:
    • Tunnistetaan substituuttituotteet
    • Löydetään asiakkaalle tarjottavat kombinaatiot
    • Optimoidaan markkinointikampanjoita sisällyttämällä niihin omia “pirkkatuotteita”, jotka nostavat kokonaismyyntiä (kannibalisoimatta kuitenkaan muuta myyntiä)
    • Tuotesuosittelut verkkosivuilla ja verkkokaupassa
  • Eurot ja mittarit:
    • “Pirkkatuotteiden” lisämyynti €
    • Potentiaalisten säästöjen kommunikointi asiakkaalle
    • Ostoskorin maksimointi

Kasvun ja datan monetisoinnin kautta dataidentiteetin tunnistamiseen

Talouselämässä oli hiljattain mielipidekirjoitus dataidentiteetistä, joka kirjoittajien mukaan määrittelee datastrategian ytimen ja antaa suunnan erottautumiselle, jolla peitota kaikki kilpailijat.

Erityisesti kasvuun ja datan monetisointiin liittyviä asioita tunnistamalla muodostuu organisaation oma dataidentiteetti ja matka kohti dataohjautunutta organisaatiota ottaa melkoisen kasvuloikan.

Kasvuun ja datan monetistointiin liittyviä näkökulmia on paljon, kuten:

  • Miten käyttää dataa hyväksi organisaation kokonaisarvon kasvattamiseksi? (data-analytiikan lisääminen tuotteisiin, esim. älykellot, tai palveluihin, kuten Amazonin tuotesuosittelut)
  • Miten luoda lisäarvoa tai pääomaa datasta myymällä se takaisin asiakkaille tai muille kiinnostuneille osapuolille? (Nielsen myy markkinadataa, Foreca säädataa, Bisnode yritysdataa, Facebook kohdennettua mainontaa profiiliimme perustuen jne.)
  • Miten keksiä kokonaan uusia ansainta- ja liiketoimintamalleja, tuotteita tai palveluita datan ympärille? (joukouttamiseen liittyvät palvelut kuten Waze; data ja algoritmit energiatuotannon optimoinnissa jne.)
  • Miten virtualisoida arvoketjuja? (Uberit, Airbnbt, Alibabat ym.)
  • Miten kasvattaa markkinoita datan avulla? (esim. tekoälybuustattu verkkokaupparatkaisu, jolla otetaan globaalit markkinat haltuun)

Näistä syntyvät myös ne hedelmällisimmät business case -aihiotkin.

Arviointi ja arvottaminen

Äskeisiä harjoituksia kun tekee, niin ollaan (ja ollaan todellakin oltu) tilanteessa, jossa meillä on Excelissä satoja hienoja liiketoiminnan kehityskohteita, tarpeita ja ajatuksia datan hyödyntämiselle. Mitäs sitten? Miten eteenpäin?

Viimeistään tässä vaiheessa on paikallaan tehdä kevyttä priorisointia. Apuna voidaan käyttää nelikenttää, jossa akseleilla ovat liiketoimintahyöty sekä toteuttamisen helppous.

Liiketoimintahyödyllä tai -vaikutuksella haetaan ennen kaikkea taloudellista (kustannus tai tuotto) etua, jolloin kannattaa antaa myös kohteelle jonkinlainen euromääräinen arvio (tyyliin puhutaanko sadoista euroista vai sadoista tuhansista euroista).

Toteuttamisen helppous on astetta moninaisempi. Siihen liittyy muun muassa datan keräämisen helppous, saatavilla olevan datan laatu, teknologia, olemassa olevat kyvykkyydet tai sisäinen politikointi.

 

Lopuksi: funtsi hetki

Loppuun yksi tuore esimerkki (viime viikolta), jossa sinällään ison ja tärkeän jutun ratkaiseminen voi tuntua hienolta datan ja analytiikan avulla.

Haasteeksi asetettiin asiakaspalvelun ruuhkahuippujen ennustaminen. Ajatuksena tietenkin, että ennakoimalla paremmin ruuhkia ja varautumalla niihin omaa väkeä resursoimalla saavutettaisiin parempi asiakastyytyväisyys.

Kyseinen ennustemalli rakennettiin yhteen yritykseen. Perimmäinen ongelma ei kuitenkaan ollut toisinaan ruuhkautunut asiakaspalvelu, vaan asiakaspalvelun ruuhkahuippujen taustalla olevat syyt. Kuten kehnosti toimiva tuote, hintavirhe tai esimerkiksi manuaalinen vaihe prosessissa, joka tuli hoitaa asiakaspalvelijan kanssa.

Toisinaan siis kannattaa funtsia hetki ennen varsinaisen projektin aloittamista ja laittaa taustalla olevat asiat ensin kuntoon.

 

Seuraavaksi kehittämisen näkökulmia

Seuraavassa blogissa sukellamme kehittämisen näkökulmiin ja linjauksiin, joka toimii eräällä tapaa siltana datastrategian liiketoiminnallisemman sekä teknisen osuuden välissä.

Kehittämisen näkökulmissa luodaan linjauksia tulevaisuuden kehittämistyölle niin liiketoiminnan kuin teknologian näkökulmista menemättä vielä liian syvälle teknisiin yksityiskohtiin. Kehittämisen näkökulmissa pohdimme asioita kuten:

  • Millaisia liiketoiminnan tärkeimpiä tavoitteita tulee mahdollistaa?
  • Mikä on keskeisin (uuteen ratkaisuun vietävä) tietosisältö?
  • Mitkä ovat arkkitehtuurin reunaehdot ja tärkeimmät linjaukset (julkisen pilven käyttö, tietosuojavelvoitteet jne.)?

Eikä siinä vielä kaikki.

Sitä ennen avaan kuitenkin tarkemmin tässäkin blogissa vilahtanutta värikästä datapohjaisten business case -aihioiden nelikenttää ja kerron kustakin laatikosta konkreettisia asiakasesimerkkejä. Pysyhän kuulolla.




10.09.2019 / Mika Aho

IT-projekteissa tuppaa usein unohtumaan, että mitähän liiketoimintatavoitetta tässä oikein palvellaan. Yhtä lailla datastrategiaprojekteissa on alkuun ensiarvoisen tärkeätä ymmärtää organisaation strategia sekä tavoitteet ja mitä organisaatio oikeastaan haluaa saavuttaa datan avulla. Muutoin ollaan nopeasti sivuraiteilla.

Liikkeelle datasta vai liiketoiminnasta?

Toisinaan datan hyödyntämisen potentiaalia lähestytään olemassa olevan datan näkökulmasta. Esimerkiksi “meillä on tällaista asiakas- ja kuittidataa ja kertokaahan, mitä kaikkea siitä voisi saada irti?”.

Siitähän voi toki tehdä kaikenlaista (teoriassa siis, oikeassa elämässä harvemmin), kuten laskea asiakkuuden arvoa, ennustaa myyntiä, tehdä ostoskori- tai hintajoustoanalyysiä, arvoida kampanjoiden vaikutuksia tai vaikka optimoida mainontaa. Tärkeitä asioita kaikki, mutta ihan alkuun on hyvä nostaa lentokorkeutta hieman. 

Liiketoimintaprosessien mallintaminen

Eräänlainen välimalli on lähteä liikkelle liiketoimintaprosessien mallintamisesta ja ymmärtää millaista dataa ne kuluttavat ja toisaalta myös, millaista uutta dataa ne tuottavat. Tyypillisesti myös tunnistetaan päätietoryhmiä, joita voidaan puolestaan käyttää esimerkiksi löytämään keskeisin masteroitava tieto. Samoin ymmärretään, missä tietojärjestelmä(kokonaisuuksissa) datat lymyävät. Jos vielä missään.

Tärkeitä harjoituksia nämäkin, mutta johtavat helposti siihen, että metsä hämärtyy puilta. Riskinä on nimittäin mennä alla olevan nelikentän vasempaan alalaitaan ja ainoastaan virtaviivaistaa liiketoimintaprosesseja unohtaen muut laatikot.

Tällöin jäävät löytämättä ne oikean yläkulman moonshotit, jota datastrategia palvelee osana isompaa digitaalista transformaatiota. Säästetään siis prosessien mallintaminen datastrategiatyön myöhempiin vaiheisiin. Palaamme myös nelikenttään myöhemmin.


Liikkeelle visiosta, strategiasta ja tavoitteista

Ennen datastrategiaprojektia ainakin näistä asioista olisi hyvä olla tietoinen:

  • Yrityksen visio ja missio
  • Strategiset teemat seuraaville vuosille
  • Tulevaisuuden painopistealueet
  • Liiketoimintaympäristö (rakenteet, asiakkaat, kasvun moottorit ja jarrut, liiketoiminta-alueet, kilpailuasetelma, kilpailuetu jne.)
  • Keskeisimmät mittarit

Ja lisäksi ymmärrys:

  • Miten organisaatio on valmistautunut muuttamaan toimintaansa KUN distruptiivisia liiketoimintamalleja ilmaantuu alalle?
  • Mikä estää organisaatiota saavuttamasta visiotaan?
  • Miten data auttaisi asetettujen tavoitteiden (visio ja strategia) saavuttamisessa?

Ja vielä “operatiivisemmin”:

  • Miten datastrategia yhdistyy liiketoimintastrategiaan?
  • Miten datastrategia liittyy käynnissä oleviin ohjelmiin ja hankkeisiin?
  • Mitkä ovat datastrategiaprojektin odotukset ja tavoitteet?

Esimerkiksi strategisista teemoista nousee jo heti esiin tärkeitä asioita. Jos yhtenä strategisena teemana on asiakkaan kokeman arvon kasvattaminen, niin voi olla tarpeen miettiä miten asiakassuhdetta voidaan parantaa. Voidaanko esimerkiksi asiakkaan käyttäytymisestä sekä mieltymyksistä oppia lisää elinkaaren eri vaiheissa ja mitä teknologiaa sekä dataa tähän tarvitaan.

Kriittiset menestystekijät eivät ole huonoja nekään. Jos toimitustäsmällisyys on logistiikkafirman yksi kriittinen menestystekijä (toivottavasti on), johtaa tämä nopeasti keskusteluihin reittien optimoimisesta (tekoälyn avulla) ja tätä kautta toimintakustannuksien alentamiseen. Sitten ratkaistaan enää kauppamatkustajan ongelma.

Data on business casejen raaka-ainetta ja datan tulee palvella organisaation strategisia vaatimuksia. Liiketoimintastrategiasta johdettu datastrategia luo raamit ja ohjenuorat datan hallinnalle.

 

Data Awareness

Miten rajata datastrategiaprojekti?

Lopettelin edellistä blogia avoimella kysymyksellä datastrategiaprojektien rajaamisesta. Hieman kärjistäen on mahdollista tunnistaa kaksi ääripäätä:

  1. Holistinen datastrategia, jossa tarkastellaan laajasti datan mahdollisuuksia koko organisaatiossa tai sen osassa
  2. Prosessikohtainen datastrategia, jossa syvennytään tiettyyn liiketoimintaprosessiin, kuten liidistä maksuun tai teemaan, kuten jäsenien edunvalvontaan (eräällä etujärjestöllä)

Molemmissa on omat vahvuutensa ja ne palvelevat eri käyttötarkoituksia.

Holistinen datastrategia

Holistisemmassa datastrategiassa tunnistetaan usein valtava joukko erilaisia liiketoiminnan kehitysmahdollisuuksia, mutta ei mennä erityisen syvälle niihin. Priorisoinnin jälkeen nostetaan esille usein muutama business case, jolla taustalla piilevää toteutushanketta on helpompi myydä myöhemmin johdolle tai hallitukselle.

Tämä on hyvä vaihtoehto, jos fokuksessa on rakentaa esimerkiksi uusi data platform -ympäristö ja tarpeena on selvittää vaatimukset sekä saada pitkä lista liiketoiminnan kehitysaihoita jatkotyöstettäväksi.

Holistisen datastrategian kehittämisessä korostuu myös arkkitehtuurisuunnittelu eli miten data saadaan mahdollisimman järkevästi integroitua eri tietolähteistä, käsiteltyä, yhdistettyä, rikastettua ja jaettua sitä tarvitseville henkilöille, digitaalisille palveluille ja keskeisille sidosryhmille. Arkkitehtuurisuunnittelussa kuvataan tyypillisesti nyky-, tavoitetila- ja transitiovaiheen arkkitehtuurit.

Ei ole kerta eikä toinenkaan, kun tämän tyyppisessä harjoituksessa valmis materiaali on toiminut myös kilpailutusmateriaalina kuvaamassa hankittavaa kohdetta.

Prosessikohtainen datastrategia

Nimensä mukaisesti prosessikohtainen datastrategia keskittyy rajatumpaan kokonaisuuteen, usein liiketoimintaprosessiin. Esimerkiksi myynnin tai asiakkuudenhallinnan osalta se voisi tarkoittaa prosesseja kuten kontaktista liidiin, liidistä myyntimahdollisuuteen, myyntimahdollisuudesta tarjoukseen, tarjouksesta tilaukseen ja tilauksesta maksuuun.

Tällöin keskitytään kuvaamaan tarkemmin, millaista dataa prosessissa syntyy, millaista dataa prosessi kuluttaa, millaisia käyttökohteita datalle löydetään eri vaiheissa (esim. älykäs asiakasprospektointi, liidien scoraus, dynaaminen hinnoittelu, asiakaspoistuman mallintaminen jne.), mistä tarvittavat datat löytyvät (jos löytyvät vielä mistään) ja millaisilla tempuilla, teknologioilla ja rooleilla sekä osaamisilla ne saadaan hyödynnettäväksi.


Miten saada johtoryhmä kiinnostumaan datasta?

Eräs pitkän uran tehnyt ja isoa suomalaisyritystä rautaisella otteella johtanut vanhempi herrasmies totesi kerran työpajassa, että

En ole kymmeneen vuoteen tarvinnut dataa. Jos tarvitsen jotain, soitan talousjohtajalle.

Oletettavasti tällaisessa organisaatiossa dataohjautuneen kulttuurin rakentaminen on hieman hankalampaa. Jos liiketoimintajohto ei pidä dataa ja analytiikkaa tärkeänä, ei dataohjautuvaa organisaatiota voi luoda. Ja juurinkin kulttuurin rakentaminen tai muuttaminen on usein se vaikein asia, jotta datasta saisi jotain pidempiaikaista arvoa.

Toinen ääripää on pelifirmat, joissa datan hyödyntäminen on rakennettu jo geeneihin. Hyvässä asemassa ovat myös teknologiastartupit sekä diginatiivit yritykset, joiden liiketoimintamalli lähtökohtaisesti perustuu dataan (Google, Amazon, Alibaba, Facebook jne.). Itse asiassa myös isot yritykset ovat verraten hyvässä asemassa, sillä niillä on tyypillisesti mahdollista tehdä tarvittavia investointeja - hyvänä esimerkkinä usein mediassa näkyvä Stora Enso.

Entäpä jos olet keskisuuressa yrityksessä, joka ei ole millään tavalla teknologiaintensiivisessä liiketoiminnassa ja tekee vieläpä B2B-kauppaa?

Osaamisen ja ennakkoluulojen päivittäminen

Yleisesti ylin johto kyllä ymmärtää, että data (ja analytiikka) voivat muuttaa liiketoimintaa, mutta eivät välttämättä tiedä miten. Näin ollen on usein tarpeen avata datan mahdollisuuksia, joka tietenkin parhaiten onnistuu toimialalle sopivien esimerkkien avulla. Kun mieli on avoin datalle, on myös kehityskohteiden innovointi (tai pölliminen muilta) helpompaa.

Datalobbarin tai dataevankelistan löytäminen

Erityisen hyvässä asemassa olet, jos löydät organisaatiosi sisältä energisen muutosagentin, joka toitottaa datan tärkeyttä, luo kiinnostusta datan ympärille, verkottuu, kertoo miten data auttaa liiketoimintaa, rakentaa yhteistä tarinaa, toimii siltana liiketoiminnan ja IT:n välissä ja ennen kaikkea saa asioita tapahtumaan.

Ylimmän johdon esimerkki

Parhaat kokemukset onnistuneista (datastrategia)projekteista tulevat, kun ylin johto on sitoutunut. Muutoin tulokset jäävät helposti laihoiksi tai ainakin ilman rahoitusta. Kannattaa ottaa johtoryhmän jäsen(iä) mukaan tekemiseen.

Nopeat voitot

Lueskelin jostain, että sisäiset kilpailut ja Hackathonit ovat ylimmän johdon tuen jälkeen toiseksi tärkein asia dataohjautuneen kulttuurin rakentamisessa. Näiden kautta saadaan nopeasti ihan hyviä tuloksia, mutta on toki hyvä muistaa, että tuotannollistaminen voi viedä pitkäänkin.

Eurot ja älyttömät arvolupaukset

Loppupeleissä raha ja hyvä business case ratkaisevat. Mitäs jos miettisitkin jonkun älyttömän arvolupauksen, jossa data on avainroolissa.

Kymmenen esimerkkiä:

  1. Karsimalla kannattamattomat asiakkaat portfoliostamme, saamme viivan alle vuosittain 1 M€ enemmän ja vapautamme resurssejamme tuottavampaan toimintaan
  2. Vähennämme logistiikkakustannuksia 20 % paremmalla rekkojen / konttien täyttöasteella, pienemmällä hävikillä ja paremmalla toimitusvarmuudella
  3. Tiputamme käyttöpääoman määrää 20 M€ paremmalla varastojen / toimitusketjun ohjauksella
  4. Ensi vuonna dataan perustuvat palvelut tuovat 30 % liikevaihdostamme
  5. Nostamme yrityksemme valuaatiota 20 % datamme ja tehokkaan dataohjautuvuuden ansiosta
  6. Parantamalla verkkokauppamme tuotetietoja, saamme välittömän vaikutuksen asiakkaan pysyvyyteen ja ostohalukkuuteen
  7. Nostamme keskihintojamme 2 % paremman hinnoitteluanalytiikan johdosta - mikä on 2 M€/vuosi lisää omistajille tai investoitavaksi 100 M€ vaihtavassa yrityksessämme
  8. Parannamme hinnoitteluamme saadaksemme 2 % paremman katteen, joka tarkoittaa 40 M€ puhdasta tuottoa
  9. Vähennämme reklamaatioita 20 % paremmilla poikkeamien ennustamisella
  10. Vuoden loppuun mennessä data parantaa kolmen miljoonan loppuasiakkaamme kokemusta palvelusta päivittäin

Eivätkä nuo niin älyttömiä edes ole  -  näistä melkein kaikki on toteutunut ihan oikeastikin. 😉

Seuraavassa blogisarjan osassa sukelletaan liiketoiminnan kehityskohteiden tunnistamiseen teemalla business caset datalle. Tämä on myös yksi lempiaiheistani eli pysyhän kuulolla!




29.08.2019 / Ilpo Järvinen

Tämä kirjoitus keskittyy Databricksin käytettävyyteen erityisesti Microsoftin Azure-pilviympäristössä.

Moni Microsoft Azuren pilvipalveluja käyttänyt on saattanut törmätä Azure Databricksiin. Databricks onkin kovassa nosteessa. Yhtenä syynä tähän on juuri Databricksin integroituminen osaksi Azure-pilviympäristöä. Tässä kirjoituksessa selvennän, mikä rooli Databricksillä on AI- ja ETL-työkaluna. Lisäksi käyn läpi, mikä Databricks oikeastaan on ja mitä etuja sen integroituminen Azureen tuo tullessaan. Mainittakoon myös, että Databricksin Azure-laajennus on Microsoftin ”first-party service”, minkä vuoksi Databricksin käyttö Azure-ympäristössä on saumatonta ja vastaa yritysmaailman turvallisuusstandardeja.

Databricks pähkinänkuoressa

Databricks tuo käytännössä data science ja data engineering -työskentelyn samaan paikkaan. Kyseessä on siis toteutus, joka mahdollistaa AI-prosessien toteutuksen alusta loppuun. Datan voi ladata useista eri lähteistä, sille voi tehdä transformaatioita, rakentaa mallinnusputkia ja lopulta mallinnusputket voi julkaista tuotantoon useille eri alustoille. Näiden ominaisuuksien avulla Databricks kattaa kaikki AI/ML-toteutuksiin vaadittavat komponentit. Lisäksi se suoriutuu kaikesta tästä erittäin hyvin. Esimerkiksi, datan voi ladata suoraan Databricksiin, tehdä datatransformaatiot SQL-kielellä, opettaa ja tallentaa koneoppimismalleja Pythonilla, ja lopuksi ladata mallit tuotantoon Java tai Scala -formaatissa.

Databricksin ohjelmointiympäristönä toimivat web-pohjaiset Notebookit, jotka muistuttavat monelle datatieteilijälle tuttuja Jupyter Notebookeja. Databricks Notebookit kuitenkin sisältävät vielä lukuisia hyödyllisiä ominaisuuksia, jotka tekevät muun muassa versionhallinnasta sekä tulostaulujen ja diagrammien piirtämisestä erittäin helppoa. Samassa Notebookissa voi käyttää useaa eri ohjelmointikieltä ilman että käyttäjän tarvitsee tehdä minkäänlaista konfigurointia. Notebookit mahdollistavat myös useamman kehittäjän samanaikaisen työskentelyn.

Olennaista on myös, että Databricks on suunniteltu erityisesti big-datan kanssa työskentelyyn. Databricksin ydin on Apache Sparkissa, joka tiivistetysti on suuren datan prosessointiin tarkoitettu laskentamoottori, joka peittoaa muut nopeudellaan, käytettävyydellään ja sovelluskohteidensa laajuudella. Nopeudesta puhuminen veisi turhiin yksityiskohtaisuuksiin, mutta käytettävyyden puolesta vahvuus on Sparkin datataulujen selkeydessä ja siinä, että Spark tarjoaa rajapinnan useaan eri ohjelmointikieleen. Sovelluskohteista muutaman mainitakseni Spark soveltuu datan prosessoinnissa niin eräajoihin kuin striimaukseen eli virtaavan datan prosessointiin, tekoälytoteutuksien rakentamiseen ja SQL-operaatioihin.

Spark – Databricksin ydin

Spark on rinnakkaislaskennan mahdollistava laskentamoottori, jossa laskenta tapahtuu hajautetusti klusterissa. Tämä mahdollistaa laskentaoperaatiot sellaisissa tilanteissa, joissa yksittäisen koneen muisti ei kapasiteetiltaan riittäisi. Juuri tämä tekee Sparkista erinomaisen big-dataan liittyvässä laskennassa.

Käytännössä tämä tekee Sparkin datatauluista erilaisia kuin esimerkiksi Pythonin tai R:n perinteiset datataulut. Sparkin datataulut eivät lepää yhdessä paikassa, vaan ne ovat hajautettu klusterin ylitse. Ominaisuuksiltaan Sparkin datataulut muistuttavatkin pikemminkin tietokantojen tauluja tai Hadoopin hajautettuja tiedostoja.

Spark-tauluille on luotu rajapinta useaan eri kieleen: Pythoniin, Scalaan, R:ään ja SQL:ään. Näistä jonkin (tai useamman) kielen hallitseminen ei kuitenkaan tarkoita saumatonta liukumaa Sparkin käyttämiseen, vaan Sparkin käyttämän taulurakenteen ymmärtäminen ja tauluilla operoiminen vaatii omaa perehtymistä.

Mikään ei tietenkään estä suorittamasta Sparkin avulla operaatioita vaikkapa Pythonilla käyttäen Pandas-kirjaston datataulukoita, mikä voi joissain tilanteissa olla jopa järkevää. Tällöin data on kuitenkin tuomittu lepäämään vain yhdessä klusterin solmussa, jolloin klusterilaskennan hyödyt jäävät saamatta. Sparkin oma taulutyyppi onkin luotu juuri hajautettu laskenta silmällä pitäen. Perinteisiä (Python/R) datataulukoita ei ole suunniteltu tähän.

Spark on myös erittäin hyvä laskentaoperaatioiden optimoinnissa. Sparkin datataulukot tuovat käyttäjälleen sen mukavuuden, että pääasiallisesti laskennan optimointi tapahtuu automaattisesti ilman, että käyttäjän tarvitsee murehtia operaatioiden järjestyksestä tai laskentaresurssien jakamisesta. Toki pieni viilaus on käyttäjän puolesta välillä paikallaan.

Entä sitten Azure Databricks?

Databricks on Apache Sparkin tekijöiden luoma alusta, joka tekee Sparkin hyödyntämisestä helppoa datatieteilijöille ja -insinööreille. Databricks kokoaa kattavan määrän ominaisuuksia yhteen mahdollistaen tekoäly/koneoppimisratkaisujen tekemisen aina datan lataamisesta mallin tuotantovaiheeseen asti. Myös ETL-työt onnistuvat Databricksin avulla.

Sitten on Azure Databricks.

Azure Databricksiä voi ajatella Databricksin ”Azure-laajennuksena”, joka tarjoaa Databricksin integroituna Azure-ympäristöön. Integraation myötä Azure Databricks voi muun muassa hyödyntää Azuren data connectoreita sekä sen sisältämää dataa voi tarkastella Power BI:ssä.

Erityismaininnan arvoinen integraatio on Azure Databricksin soveltuvuus osana Azure Data Factoryn pipelineja eli ETL-putkia. Azure Databricksin notebookit voidaan saumattomasti yhdistää osaksi Azure Data Factoryn pipelinea. Tämä korostaa Azure Databricksin kykyä toimia ETL-työkaluna. Esimerkiksi datan voi pipelinessa koota useista lähteistä Blobiin, jonka jälkeen Azure Databricks tekee datalle halutut transformaatiot ja palauttaa takaisin Blobiin. Viimeisenä vaiheena voi olla esimerkiksi transformoidun datan siirtäminen Blobista SQL-tietovarastoon. Kaikki tämä tapahtuu näppärästi Azure Data Factoryn putkessa.

Ja mitä AI-toteutuksiin tulee, Azure Databricksissä luodut mallit voi rekisteröidä Azure Machine Learning servicen työtilaan, jonka kautta mallit voi julkaista verkkopalveluina. Azure Databricks on siis loistava komponentti osana Azure-pohjaisia ratkaisuja.


15.08.2019 / Mika Aho

”Kuulostaa liian juhlalliselta meille”, totesi eräs pörssiyhtiön johtaja käydessämme aiemmin tänä vuonna esittelemässä aiheeseen liittyvää tarjousta. Lopulta päädyimme nimeämään ehdotuksemme jotakuinkin ”mahdollisuuksia datan hyödyntämiselle liiketoiminnan kehittämisessä” ja fokusoiduimme auttamaan asiakasta keräämään ympäri organisaatiota olemassa olevat ideat ja innovoimaan uusia mahdollisuuksia eri liiketoiminnoissa. Ja paljon muutakin toki.

Digiä, dataa, strategiaa ja transformaatiota

Aihe ei ole mitenkään uusi. Toisinaan olemme puhuneet digitalisaatiosta, digitaalisesta transformaatiosta, digistrategiasta, digiloikasta, dataloikasta, digiagendasta, analytiikkastrategiasta tai vaikkapa tiedolla johtamisen esiselvityksestä. Laajemmissa kokonaisuuksissa yritys- tai kokonaisarkkitehtuurista. Asiassa on paljon erilaisia näkökulmia ja rakkalla lapsella on monta nimeä.

Itse olen päässyt tekemään tusinan verran erilaisia datastrategiaprojekteja asiakaskunnassamme eri toimialoilla muun muassa rahoitus-ja vakuutusalan sekä ravintola- ja hotellibisneksen kautta tukkukauppaan, valmistavaan teollisuuteen, ammattiliiton kiemuroihin ja rasvaiseen huoltobisnekseen. Kahta samanlaista projektia ei ole vielä tullut vastaan, mutta niitä kaikkia yhdistävät tietyt asiat.

Ei ehkä yllättävää, että samanlaisissa vaiheissa ja samalla toimialla olevat yritykset painivat paikoin samanlaisten ongelmien parissa. Myös analytiikan käyttökohteet ovat pääsääntöisesti samoja: kustannuksia syntyy ja tuottoja haetaan samantyyppisistä kohteista. Varastot pitäisi saada kiertämään nopeammin, laitteet huollettua ennakoivasti, asiakaspoistumaa vähennettyä, kysyntää ennustettua, tarjousten läpimenoa optimoitua tai vaikka syötettyä lehmille oikea määrä sapuskaa.

Asiakaskokemuksen parantaminen ja datan monetisointi tuovat kuitenkin hyviä erottumisen sekä kilpailukyvyn parantamisen paikkoja. Näistä lisää myöhemmin.

Uusi blogisarja datastrategiasta

Syksyn aikana avaan blogisarjassa, miten kehittää datastrategiaa omaan organisaatioon ja millaisia asioita kussakin vaiheessa kannattaa ottaa huomioon. Niin ikään availen onnistumisen edellytyksiä ja kokemusten kautta kertyneitä vastoinkäymisiä. Koitan saada myös asiakkaan äänen kuuluviin mahdollisimman paljon.

Blogisarja jakaantuu seuraavasti:

  1. Liiketoiminnan tahtotilan sekä vision ymmärtäminen (ja miten saada johtoryhmä kiinnostumaan datasta)
  2. Business caset datalle – dataan sekä analytiikkaan liittyvien liiketoiminnan kehitysmahdollisuuksien tunnistaminen
  3. Kehittämisen näkökulmien valinta – yksinkertaistaminen on kaunista
  4. Organisaation tietopääoman tunnistaminen – tänään ja tulevaisuudessa
  5. Modernin data-arkkitehtuurin suunnittelu – millaisiin pönttöihin ja rakenteisiin data kannattaa nykypäivänä tallentaa
  6. Gap-analyysin sekä kehityspolun rakentaminen – mitä huomioida ja miten mitata?
  7. Operationalisointi – data ja teknologia on helppoa, mutta ihmisten ja prosessien muuttaminen ei. Lopuksi kerron, miten asiat viedään osaksi arkea

Samantyyppisen ”viitekehyksen” kautta on juoksutettu käytännössä kaikki meidän datastrategiaprojektit, ainoastaan painopiste on ollut kussakin hieman erilainen.

Mitä sitten on datastrategia?

Kuten alussa tuli ilmi, moni termi kattaa saman asian ja puhun jatkossa systemaattisesti datastrategiasta. Mitään uutta ja ihmeellistä asiassa ei ole, mutta syystä tai toisesta se on kovinkin ajankohtainen eri puolilla.

Strategia sanana on sikäli hieman harhaanjohtava, että datastrategia ei suinkaan ole kertaluontoinen harjoitus tietyn päämäärän saavuttamiseksi, vaan sen pitäisi olla ennemminkin jatkuva prosessi tai toimenpidesuunnitelma, jota päivitellään rullaavan budjetin tavoin vaikkapa puolivuosittain. Toimintaympäristö muuttuu jatkuvasti ja riskinä on, että vaivalla tehty arvokas työ happanee (pöytälaatikkoon).

Eräs potentiaalinen asiakas kritisoikin, että hehän ovat jo aika pitkällä näissä asioissa ja datastrategia kuulostaa enemmänkin siltä, että lähdettäisiin aivan alusta liikkeelle. Näin ei tietenkään ole.

Datastrategiassa ei myöskään varsinaisesti tehdä liiketoimintastrategiaa, vaikka välillä sillekin tielle eksytään. Liiketoiminnan suunta ja tavoitteet tulevat enemmänkin annettuna. Niinkin on kuitenkin käynyt, että datastrategiaprojektin myötä organisaatio on lähtenyt valloittamaan uudenlaista asiakassegmenttiä ja markkinaa.

Eräällä tapaa datastrategian voi käsittää visioksi ja pelisuunnitelmaksi datan hyödyntämiselle liiketoiminnassa.

Samalla se on myös astetta teknisempi suunnitelma, jonka avulla parannetaan tapoja hankkia, hallita ja jakaa sekä hyödyntää dataa tulevien vuosien aikana tunnistettujen liiketoimintatarpeiden mukaisesti. Taustalla hieman huomaamatta rakennetaan organisaation tavoitteita tukevia dataohjautuneita kyvykkyyksiä ja valmennetaan organisaatiota muutokseen murrokseen.

Millaisiin tilanteisiin datastrategian oikein kehittäminen sopii?

Tarpeet ovat usein moninaisia. Alla muutama oikea esimerkki datastrategian kehittämisen tarpeista:

  • Halutaan kartoittaa nyky- ja tavoitetila sekä luoda etenemissuunnitelma
  • Ennakoidaan muutoksia ja valmistaudutaan muutokseen
  • Nostetaan digitalisaatioastetta
  • Harmonisoidaan liiketoimintaprosesseja
  • On pakko (esim. carve-out -tilanne, jossa tulee tunnistaa keskeisimmät tietopääomat ja -järjestelmät)

Tarpeet voivat olla toki tarkempiakin, kuten:

  • Tunnistetaan, mistä (datasta) on eniten hyötyä
  • Ymmärretään, mitä dataa prosessit kuluttavat ja millaista dataa ne tuottavat
  • Ymmärretään, miten data saadaan näkyväksi ja hyötykäyttöön oikeilla työkaluilla sekä teknologioilla
  • Tunnistetaan painotuksia, millä alueilla halutaan liikkua ja mihin panostaa
  • Saadaan tukea ja perusteluita valinnoille sekä business caseille
  • Tuetaan portolion hallintaa aina bisnesportfolioon saakka
  • Luodaan järkevät investointisuunnitelmat, joilla maksimoidaan ROI (datasta)

Yleistä kaikelle kuitenkin on, että datastrategiaa tyypillisesti tarvitaan liiketoiminnan käännekohdissa.

Datastrategia projektina

Aika monessa tekemisessä pätee Sarasvuon sanonta ”ei niin paljon kuin mahdollista, vaan niin vähän kuin on tarpeen”. Datastrategiaprojektitkaan eivät tee tähän poikkeusta.

Yleisesti olen huomannut, että asiakkaat hakevat nykypäivänä käytännönläheistä ja ennen kaikkea liiketoimintalähtöistä lähestymistapaa monimutkaisten sekä raskaiden viitekehysten sijaan, joita näkee erityisesti paljon yritysarkkitehtuurin (EA) kehittämisessä.

Ideaalisesti datastrategiaprojekti:

  1. Lähtee liiketoiminnan tarpeista ja tukee liiketoiminnan tavoitteita
  2. Osallistuttaa liiketoiminnan ja ylintä johtoa (tämä on avainasiassa projektin onnistumiselle)
  3. On käytännönläheinen ja itseään selittävä
  4. On helposti kommunikoitava organisaation sisällä
  5. On riittävän joustava mukautumaan muuttuviin liiketoiminnan ja teknologian tarpeisiin

Datastrategiaharjoitukseen on hyvä varata noin kolme kalenterikuukautta ja osallistuttaa muutamia kymmeniä henkilöitä organisaation sisältä. Tällöin saadaan suuntaviivat riittävän tarkalla tasolla selville, jonka jälkeen alkaa sitten raaka työ jalkauttamisen muodossa.

Seuraavassa blogissa kirjoitan tarkemmin liiketoiminnan tahtotilan ja vision ymmärtämisestä (ja miten saada johtoryhmä innostumaan datasta). Odotellessa voit miettiä, miten datastrategiaprojektia kannattaisi rajata – vai pitäisikö ollenkaan?




17.06.2019 / Juha Kostamo

Datastrategia vai datatragedia? Näillä sanoilla on vain muutaman kirjaimen ero, mutta huomattava ero näkyy siinä, kuinka näitä kahta ilmiötä edustavat organisaatiot toimivat päivittäin, suunnittelevat tulevaisuuttaan ja sopeutuvat säännöllisesti kohtaamiinsa muutoksiin.

Organisaatiot, joissa toimintaa ohjaa datatragedia, on helppo tunnistaa. Ko. organisaatioilla ei ole kykyä kertoa helposti ymmärrettävästi (sisäisesti tai ulkoisille sidosryhmille) omista IT- arkkitehtuureistaan, tulevaisuuden kehityssuunnitelmistaan tai datan/järjestelmien omistajuuksista. Muutostarpeet nykyiseen arkkitehtuuriin (uusia lähdejärjestelmiä, sovelluksia…) laukaisevat aina mittavan selvitysprojektin, joissa pyörää keksitään uudestaan ja uudestaan.

Jatkuvat muutokset aiheuttavat stressiä työntekijöille, ja eri osapuolten väliseen, tietotekniikan ja prosessien kehitystä koskevaan sisäiseen viestintään ei ole olemassa käteviä työvälineitä. Innostus liiketoiminnan kehittämiseen on rajallista. Koska se on niin tuskallista.

Datatragedian synnyttämiseen ei tarvita strategiaa eikä johtajuutta. Annetaan vaan asioiden kehittyä omalla painollaan.

 

Mistä datastrategiassa sitten on kyse?

Datastrategia on liiketoimintastrategian tytär (tai poika). On tärkeää hahmottaa, mihin liiketoiminnalla pyritään nykyhetkenä ja tulevaisuudessa ja mitä hyötyä datasta on näiden liiketoimintatavoitteiden saavuttamisessa.

Datastrategiassa ei ole kyse mahdollisimman nopeista voitoista vaan pitkän aikavälin kilpailuedusta. Lyhyen aikavälin voitot ovat osa datastrategiaa.

Kokonaisvaltainen datastrategia kattaa esimerkiksi päätöksenteon tehostamisen, toiminnan tehokkuuden ja datan monetisoinnin. Käyttötapauksien ja business case- aihioiden kerääminen on välttämätön vaihe datastrategian hahmottelun alkuvaiheessa.

Se koostuu myös pitkän aikavälin arkkitehtuurisuunnitelmasta, joka mukautuu tarvittaessa muutoksiin. Nykytila-, siirtymä- ja tavoitearkkitehtuureita tarvitaan lähdejärjestelmien, integrointien, operatiivisten ja analyyttisten järjestelmien sekä eri osien välisten riippuvuuksien ohella. Arkkitehtuurin periaatteet laaditaan ohjaamaan tulevaa kehitystä.

Sisäisten ja ulkoisten osapuolten välisen vuoropuhelun helpottaminen voi vaatia myös kaikille yhteisten termien ja käsitteiden määrittelyä. Esimerkiksi sana ”juna” voi tarkoittaa eri henkilöille eri asioita.

Tietojärjestelmien ja datan omistajuus on monissa organisaatioissa epäselvää. Nimien ja tietojärjestelmien listaaminen Excel-taulukossa ei vielä kerro omistajuudesta. Omistajuuden käsite (esim. talon tai auton omistajuus) tarkoittaa ainakin minulle sitä, että omistaja osallistuu omaisuuden ylläpitoon aktiivisesti.  Tavoitteena omaisuuden arvon säilyttäminen ja jopa kasvattaminen. Tämän pitäisi näkyä myös datastrategiassa.

Jos haluat hyödyntää uusimpia teknisiä innovaatioita liiketoiminnan haasteiden ratkaisemisessa, taidot ja pätevyydet ovat entistä tärkeämmässä osassa. Teknologia itsessään kattaa vain noin 30–40 prosenttia koko liiketoimintaratkaisusta. Loppu onkin kiinni ihmisistä. MS Excelin avulla voi tehdä ihmeitä, jos osaaminen on kohdallaan. Tulevaisuuden tarpeiden ja tämänhetkisen osaamistason puutteiden hahmottamisesta voi seurata tarve palkata uusia työntekijöitä, perustaa uusia työtehtäviä ja tarkastella myös tarpeiden ulkopuolista osaamista.

Kun tiedetään, mihin ollaan tähtäämässä ja mitä kaikkea tarvitaan, voidaan laatia etenemissuunnitelma, joka huomioi sekä lyhyen aikavälin voitot että pitkän aikavälin mahdollisuudet. Etenemisen suunta on todennäköisesti hyvä tarkistaa säännöllisin väliajoin liiketoimintaympäristön kehittyessä. Näiden kotitehtävien tekemisen jälkeen liiketoiminta voi taas jatkua tuttuun tapaan. Ei siis mikään ylivoimainen tehtävä.

Lopuksi voidaan todeta, että datastrategian laatiminen ei ole mikään läpihuutojuttu tai lastenleikkiä. Se ei tapahdu itsestään.

Datastrategian laatiminen on vaativa tehtävä, johon johtoryhmän on osallistuttava tiiviisti ja sitouduttava lujasti.

Mutta kuten yleensäkin -missä on tahtoa, siinä on tie.


17.06.2019 / Juha Kostamo

Datastrategi eller datatragedi? Bara några få bokstäver skiljer dessa tillstånd åt, men det finns stora skillnader i hur organisationer på vardera sida lever sina dagliga liv, planerar för framtiden och anpassar sig efter de ständiga förändringar de möter.

Organisationer som lever i tillståndet ”datatragedi” är lätta att känna igen. De har inga möjligheter att internt (eller externt!) kommunicera infrastrukturens aktuella status, vägkartor för framtida utveckling eller ägarskap över data eller system, och alla ändringsbegäranden för den befintliga konfigurationen (nya källsystem, nya applikationer …) verkar alltid leda till att ett omfattande utredningsprojekt initieras.

Människor blir stressade vid förändring, och det finns inget enkelt sätt att internt kommunicera med olika intressenter om IT- och processutveckling. Villigheten att utveckla verksamheten begränsas ytterligare.

Du behöver inte ledarskap eller planer för att hamna i en datatragedi – det räcker att du låter saker och ting evolvera över tid.

 

Så vad handlar ”datastrategi” om?

Datastrategi är affärsstrategins barn. Det är viktigt att förstå vad företaget vill uppnå nu och i framtiden, och hur data kan bidra till att dessa mål nås.

Datastrategi handlar inte om snabba vinster, det handlar om att skapa långsiktiga konkurrensfördelar. Datastragetin medför också snabba vinster.

En omfattande datastrategi täcker områden som förbättrat beslutsfattande, effektivitet i verksamheten och intäktsgenerering via data. Att samla in användnings- och företagsfall är ett nödvändigt steg när en datastrategi ska formuleras.

Detta innefattar också en mer långsiktig arkitekturplan som kan anpassas efter förändring. AS-IS-, övergångs- och TO-BE-arkitekturer med källsystem, integreringar, drifts- och analyssystem och beroenden mellan de olika delarna krävs. Arkitekturprinciper skapas som vägledning till framtida utveckling.

För att kunna möjliggöra diskussionerna mellan interna och externa intressenter kan det också finnas behov av att skapa ett gemensamt och delat språk och gemensamma begrepp. ”En hylla” kan betyda olika saker för olika personer.

I många organisationer är ägarskapet över IT-system och data inte tydligt. Ett namn i ett Excel-blad med IT-system är inte detsamma som ägarskap. Ägarskapskonceptet innebär (i likhet med att äga ett hus eller en bil) att man tar aktivt ansvar för att upprätthålla tillgångens kvalitet, åtminstone för mig. Datastrategin ska också inbegripa denna aspekt.

Om du vill utnyttja ny teknisk innovation för att hantera utmaningarna i verksamheten spelar också kompetens och skicklighet en viktig roll. Tekniken självt står bara för 30–40 procent av hela affärslösningen. Resten handlar om människorna. Du kan göra under med MS Excel om du har rätt personer på rätt plats. Att förstå framtidens behov och klyftan i förhållande till dagens kunskapsbas kan innebära att ny personal rekryteras, att nya roller skapas och att titta utåt efter den kompetens som behövs.

När du vet vart du ska ta vägen och vad som krävs går det att skapa en vägkarta som ger både snabba vinster och långsiktiga möjligheter. Du kommer förmodligen att behöva verifiera riktningen regelbundet efterhand som affärsmiljön förändras. Men om du har gjort din läxa flyter affärerna bara på – utan någon överväldigande arbetsinsats.

Som en sammanfattning är det inte någon barnlek att skapa en datastrategi. Det kommer inte att gå av sig självt.

Att skapa en datastrategi är en viktig åtgärd som kräver starkt engagemang och aktivt ansvar från ledningsgruppen.

Men som alltid – vill man så går det.