3.12.2019 / News Team

Digitaalisen asiakaskokemuksen edelläkävijä, teknologiayhtiö Bilot on nimittänyt BBA Mikko Marttisen (s. 1976) konsernin talousjohtajaksi (CFO) ja johtoryhmän jäseneksi 1.1.2020 alkaen. Marttinen siirtyy Bilotiin Avidly Oyj:stä, jossa hän on toiminut konsernin CFO:na vuodesta 2014 ja kesästä 2019 lähtien myös yhtiön vt. toimitusjohtajana. Marttisella on pitkä taloushallinnon kokemus muun muassa ManpowerGroup Oy:stä, Elan IT Resource Oy:stä, TBWA/PHS Helsinki Oy:stä ja Luottokunta Oy:stä.

”Bilot kasvaa ja kansainvälistyy vakaasti, ja meillä on Suomessa vahva asema etenkin suurten ja keskisuurten yritysten digitaalisen asiakaskokemuksen ja kehittyneen analytiikan kumppanina. Nyt on otollinen hetki virittää myös yhtiön taloustoimintoja seuraavaan kasvuvaiheeseen. Mikko tuo tullessaan vankkaa kokemusta ja osaamista taloushallinnosta sekä tuoretta näkemystä johtajuudesta useilta eri toimialoilta. Mikko sopii loistavasti osaksi Bilotin tiimiä: hän on tuloshakuinen ja näyttänyt kykynsä vaativissa kasvuyhtiöiden johtotehtävissä myös kansainvälisessä ympäristössä. Kiitän lämpimästi Mikon edeltäjää Juha Riippiä hänen erinomaisesta panoksestaan menestyksemme tukemiseksi”, kertoo Bilotin toimitusjohtaja Mika Tanner.

”On hienoa päästä mukaan luotsaamaan Bilotin kasvutarinaa tässä mielenkiintoisessa kehitysvaiheessa. Yhtiön taloudellinen kehitys on viime vuosina ollut vaikuttavaa ja myös kansainvälistyminen on hyvässä vauhdissa Ruotsissa ja Puolassa. Yhtiön maine sekä asiakkaiden että työntekijöiden keskuudessa on erinomainen. Uskon vahvasti Bilotin kykyyn toteuttaa kannattavan kasvun strategiaansa myös tulevaisuudessa”, sanoo uusi talousjohtaja Marttinen.

Bilotin uusi CFO Mikko Marttinen.
Bilotin uusi CFO Mikko Marttinen

Lisätietoja antaa:

Mika Tanner
toimitusjohtaja
Bilot Consulting Oy
040 5440477
mika.tanner@bilot.fi

 

Bilot – Etumatkaa digitaalisesta asiakaskokemuksesta 

Bilot on suomalainen teknologiayhtiö, joka luo yrityksille ratkaisevaa etumatkaa rakentamalla ylivertaista digitaalista asiakaskokemusta. Bilot tunnistaa merkittävimmät yrityselämää ravisuttavat digitaaliset innovaatiot ja muuntaa ne ketterästi asiakkaidensa liiketoimintaa ja kilpailuetua uudelle tasolle rakentaviksi kokonaisvaltaisiksi ratkaisuiksi.

Bilot tarjoaa asiakkailleen kattavan valikoiman digitaalisia palveluja ja ratkaisuja asiakaspolun eri vaiheisiin sekä tekoälyä ja analytiikkaa valjastavia älykkäitä myynnin ja markkinoinnin työkaluja. Yhtiöllä on vahvaa osaamista ja merkittävä markkina-asema johtavissa ohjelmistoalustoissa ja keskeisissä ekosysteemeissä (mm. SAP ja Microsoft) sekä niiden integroinnissa saumattomaksi osaksi asiakkaiden liiketoimintaa. Bilot syntyi vuonna 2005 halusta luoda alan paras työpaikka parhaille osaajille. Tänään Bilotilla on jo lähes 160 työntekijää Suomessa, Ruotsissa ja Puolassa. Vuonna 2018 Bilot-konsernin liikevaihto oli noin 17 miljoonaa euroa ja liikevoitto noin 1,4 miljoonaa euroa.

www.bilot.fi


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 / Aarni Vanamo

Lähtökohta

Uuden kehittäminen on hauskaa, mutta yhdessä kehittäminen on hauskempaa. Pari viikkoa sitten mietime tiimin kesken toimistolla, että mitä kivaa voisimme tehdä yhdessä. Pienen brainstorm-session jälkeen päädyimme ideaan, kuinka voisimme hyödyntää IoT -antureita tai koneoppimista meidän omassa toimistoympäristössä.

Demon tarkoitus

Halusimme tehdä demon ihan demomerkityksessä, niin itsellemme, kuin myös asiakkaillemme. Nyt kun IoT-pohjaisia ratkaisuja on tehty Bilotilla muutama, niin halusimme myös kokeilla, kuinka nopeasti ja helposti tällainen nousisi. Alkuvaiheessa kuuntelimme pari vinkkiä kokeneemmilta, mutta aika nopeasti demo-tiimimme pääsi ratkaisun kanssa vauhtiin.

Demon aihe ja rajaus

Päädyimme tekemään palvelun, joka erillisten sensoreiden kautta kerää mittaustietoja neuvotteluhuoneiden ilmasta kahden minuutin välein (lämpötila, kosteus, paine), ja näyttää nämä tiedot kätevässä yhteenvetomuodossa jatkuvasti päivittyvän web-applikaation kautta. Toteutettu versio demosta on katsottavissa täältä: Bilot IoT Demo, ensikäynnistyksellä pitää hetkinen odotella datan latautumista.

Tämän tyyppisen ratkaisun kohdalla tietoteknisiä arkkitehtuurivaihtoehtoja ei tarvinnut kauan puntaroida. Tässä tarvitaan jokin komponentti keräämään ja syöttämään dataa, toinen komponentti tallettamaan datat, kolmas palvelu jakelemaan tallennettu data, ja neljäs esittämään tiedot käyttäjälle kätevässä ja miellyttävässä muodossa.

Lähes yhtä nopeasti meille valkeni oikeat teknologiat: sensoreina käytetään suomalaisen Ruuvi -yhtiön IoT-sensoreita, paikallisena tiedonkeruualustana (ns. ”edge device”) käytetään Raspberry Pi -minitietokonetta, palvelimena meillä on Microsoft Azure ja applikaatio toteutetaan Reactilla.

Toteutus

Palvelin

Aloitimme palvelun rakentamisen keskeltä, eli tarvittavista Azure-palveluista. Pienen selvittelyn jälkeen Azuren tarjonnasta valittiin tähän ratkaisuun käytettäväksi:

  • Azure IoT Hub, jonka kautta määritettiin ulkoiset laitteet millä dataa kerättiin, ja joka ottaa ulkoa lähetetyn datan talteen.
  • Azure Stream Analytics, jota käytettiin lukemaan IoT hubin vastaanottamat mittaustiedot ja kirjoittamaan tiedot tietovarastoon sopivassa muodossa
  • Azure SQL Database, mihin mittaustiedot tallennettiin
  • Azure functions jota käytettiin välittämään haluttuja tietoja käyttöliittymään.

Isommassa ratkaisussa tietovarastona pelkkä Azure SQL Database ei ehkä olisi riittävä, mutta tähän käyttöön se kelpasi hyvin. Muista palveluista poiketen se ei ole ilmainen, mutta tässä tapauksessa edullisimmat versiot riittävät hyvin. Kustannus on alle 12 euroa kuukaudessa.

Varsinaiseksi palvelintoteutukseksi jäi siis IoT -hub -palvelun konfigurointi, SQL-tietokannan ja -taulujen perustaminen, Stream Analytics -palvelun ja siihen liittyvän kyselyn konfiguroiminen ja aplikaatiota palvelevan Azure-funktion laatiminen.

Mittausdatan kerääminen

Ruuvi-yhtiön Bluetooth-sensorit olivat lopulta helppo valinta, verrattuna muihin vastaaviin. Laitteiden saatavuus on hyvä, ne ovat edullisia, ja käyttäjäkunta on aktiivista, joten erilaisia foorumi- ja blogipostauksia oli sopivasti tarjolla.

Sensorit käyttäytyvät Bluetooth-majakoina, eli tällaisen lukemiseksi laitteita ei tarvitse erityisesti parittaa. Mittalaitteet vain lähettävät dataa yltympäriinsä, ja jokainen kantavuusalueella oleva Bluetooth-laite voi tätä signaalia kuunnella. Jossakin käyttötapauksessa tämä saattaa olla turhan huoleton käytäntö, mutta ainakaan demon tapauksessa emme tästä olleet murheissamme.

Lisäksi päädyimme käyttämään niin sanottua ”Edge deviceä”. Termille ei ole kovin vakiintunutta suomenkielistä käännöstä, mutta jonkinlainen ”Reunalaite” se on. Kyseessä on tietynlainen silta, internetiin kytketty laite, joka osaa keskustella Azure IoT Hubin kanssa, ja joka osaa kerätä mittaussensorien lähettämät tiedot. Edge devicen tarve on helppo nähdä tässä tilanteessa, jossa mittalaitteet lähettävät tietonsa vain Bluetoothilla, mutta tällainen välilaite on usein hyödyllinen silloinkin, kun mittaussensorit osaisivat itsekin kytkeytyä internetiin.

Meiltä kun sattui löytymään Raspberry Pi 3 valmiina ja sen käyttöön tässä tarkoituksessa löytyi hyvin ohjeita, niin se oli aika luonnollinen valinta tähän tarkoitukseen.

Seuraavaksi piti ohjelmoida Raspberry-tietokone ottamaan vastaan mittausdataa sensoreilta, ja lähettämään tämä data sopivassa muodossa Azure IoT Hub -palvelulle. Tämänkin olisi voinut tehdä monin keinoin, mutta tässä valitsimme pienimmän vastuksen tien, ja teimme Edge Device -ohjelman Pythonilla. Azuren IoT-palvelu olisi tarjonnut tähän hienompiakin konsteja, jotka olisivat mahdollistaneet Edge devicen etähallinnan ja muutakin, mutta demon vaatimustason kannalta nämä olivat tarpeettomia.

Pythoniin meille taas oli tarjolla valmis ruuvitag-sensor -kirjasto, joka tarjosi paljon aihepiiriin liittyvää toiminnallisuutta valmiina. Lisäksi tarjolle paljastui myös DeviceClient.py -kirjasto, joka tarjoaa metodit tietojen lähettämiseksi Azure IoT Hubille. Python-ohjelmalle syötettiin Azure IoT Hubista saadut tunnistetiedot, jotka toimivat tietojenlähetyksessä tunniste- ja pääsynhallintatietoina. Python-ohjelma ottaa kahden minuutin välein sensorien tiedot talteen, ja lähettää ne IoT Hubille.

(Raspberry Pi -koneeseen olisi voinut asentaa myös Windows 10:n IoT -version, mutta tätä emme kokeilleet. Koneen käyttöjärjestelmänä sai toimia oletuksena asentunut Raspbian.)

Mittausdatan tallentaminen palvelimelle

Koska palvelinpään toiminnallisuus oli tehty jo alkuvaiheessa, varsinaisen kerätyn datan tallennus ei vaatinut kuin pienen tarkastuksen. Raspberry Pi -tietokoneen Python ohjelma keräsi ja edelleen lähetti mittaustiedot aivan odotetusti, joten palvelimella lähinnä riitti todeta tilanne ja katsoa miten mittaustietorivejä ilmestyi tietokantaan.

Mittausdatan julkaiseminen

Palvelimen ja applikaation välinen tietoliikenne toteutettiin tämänhetkisen normaalikäytännön mukaisesti REST-palveluna. Azure-palveluun laadittiin ja asennettiin Azure-funktio, joka palauttaa mittaustiedot JSON -sanomana, kahdessa eri muodossa. Toinen muoto tuottaa suoraviivaisen mittausdatan: mikä lämpötila on milläkin hetkellä kussakin huoneessa ollut, toinen muokkaa mittausriveistä koostedataa, eli päivittäiset keskiarvot jokaisesta huoneesta.

Funktio toteutettiin Visual Studio 2019:lla, joka tarjoaa Azure-funktion valmiina projektityyppinä. Tietokantayhteyttä varten emme ottaneet käyttöön Entity Frameworkia, koska ajattelimme näin suoraviivaisen toteutuksen hoituvan nopsemmin suorilla ADO-kyselyillä. Todennäköisesti EF olisi kuitenkin ollut helpompi, mutta menee se näinkin. Palvelinfunktiota varten emme perustaneet CI/CD -putkea, funktio julkaistaan suoraan Visual Studiosta.

Rajapinnan hallinnan tähden otimme käyttöön Azuren API Management -palvelun, jonka kautta funktiota kutsutaan. API Managementilla pystymme rajoittamaan montako rajapintakutsua suostumme aikayksikön sisällä palvelemaan, ja täten kontrolloimaan resurssien käyttöä ja kustannuksia.

Applikaation suunnittelu ja toteutus

Kuten oikeissakin projekteissa, niin ennen kuin käyttäjäpuolen applikaatiota lähdettiin toteuttamaan, niin ensiksi se piti tietenkin suunnitella. Tässä tapauksessa käyttäjätarpeet kerättiin suoraan tiimistä, koska itsellemmehän me tätä pitkälti teimme. Kun post-iteja oli lätkitty tarpeeksi, niin alettiin sitten rakentelemaan designia Adobe XD:llä ja visuaalisia komponentteja Adobe Illustraattorilla.

Koska React on ollut viime aikoina ahkerassa käytössä, niin siihen Reduxin kanssa päädyttiin JavaScript kirjasto/framework vertailussa lähes automaattisesti.

Applikaation ulkoasun rakentamisessa lähdettiin ensiksi hyödyntämään suosittua React käyttöliittymä frameworkia, Material UI:ta, mutta jotenkin se vain tuntui epäkäytännölliseltä ja saikin poistua lähes saman tien perinteisen SCSS lähestymisen tieltä.

Joitain lisäpaketteja asenneltiin sitten vielä tarpeen mukaan:

  • Recharts osoittautui nopeaksi ja käteväksi graafi-työkaluksi
  • API-kutsut hoidettiin Axioksen avulla
  • Päivämäärien ja kellonaikojen esittämisessä hyödynnettiin js:ää

Yhteenveto

Demo valmistui jopa yllättävän sukkelasti. Azure-palveluiden asennus ja konfigurointi vei työaikaa parilta ihmiseltä noin päivän. Edge-laitteen konfigurointi ja ohjelmointi vei päivän sekin, sisältäen yllättäen eteen tulleen tarpeen opiskella Pythonia. Ensimmäisen toimivan version jälkeen molempia kohtia viimeisteltiin vielä jonkin verran, mutta voimme pää pystyssä todeta tällaisen syntyvän muutamassa päivässä.

Eniten aikaa kului applikaation toteutukseen. Tässäkin tapauksessa ensimmäinen versio syntyi parin päivän työllä, mutta suunnittelun iterointi, responsiivisuus ja käytettävyyden yksityiskohtien hiominen toivat muutamia päiviä lisää ja tuovat vielä jatkossakin, kun kerrankin on ratkaisu minkä käyttöliittymä kehityksessä ei ole mitään rajoitteita ja mihin voi palata aina yhä uudelleen, uusien ideoiden kanssa.

Alkuvaiheessa tehdyt arkkitehtuuri- ja teknologiavalinnat osoittautuivat kaikki hyviksi. Muutama pieni tyyliseikka jäi kaihertamaan, Azure-funktiota varten olisi kuitenkin kannattanut tehdä CI/CD -putki, ja olisi sen Entity Frameworkin voinut myös mukaan ottaa. Edge -laitteen Python-sovellus on myös hieman harrastusprojektihenkinen, tuotantokäyttöön tekisimme hieman viimeistellymmän ja vakaamman toteutuksen, mutta ei tämä nykyinenkään ole käynnistyksensä jälkeen mitään ongelmia tai poikkeuksia aiheuttanut.

Kaiken kaikkiaan ”projekti” oli onnistunut kokonaisuus, jossa muutaman ihmisen pienellä panostuksella saatiin hauska kokonaisuus aikaiseksi, opittiin hieman uutta ja luotiin pohja minkä päälle rakentaa lisää.

Jatkoakin on jo suunniteltu. Tarkoituksena olisi seuraavaksi integroida applikaatioon tieto neuvotteluhuoneiden varaustilanteesta, käyttöasteista jne.

Tämä blogi on kirjoitettu yhteistyössä Erkka Puustin kanssa.


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.




20.09.2019 / Toni Haapakoski

Yritysarkkitehtuurille (eng. Enterprise Architecture, EA) on olemassa useita määritelmiä ja painotuksia, mutta pohjimmiltaan kyseessä on kokonaisvaltainen näkemys liiketoiminnan tavoitteiden saavuttamisesta liiketoimintaprosessien, datan, tietojärjestelmien ja IT infrastruktuurin yhteen sitomisen kautta.

business data applications technology

Sain keväällä toimeksiannon eräältä asiakkaaltamme suunnitella heidän yritysarkkitehtuurinsa kolmessa kuukaudessa. Tällaisen pitkän tähtäimen kehityssuunnitelman on tarkoitus helpottaa keskusteluita sekä liiketoimintaprosessien kehittämisestä että tarvittavista IT investoinneista.

Tehtävän työn laajuus ja aikataulu asettivat haasteen sekä meille että asiakkaan puolella osallistuville henkilöille. Valmista hyödynnettävää materiaalia oli lähinnä nykyinen järjestelmäkartta sekä osittaiset liiketoimintaprosessikuvaukset. Onnekseni muut konsulttikollegani tunsivat asiakkaan prosessit, järjestelmät ja niiden integraatiot erittäin laaja-alaisesti ja syvällisesti, mikä jossain määrin helpotti urakkaani. Silti työtä riitti paljon haastattelujen suunnittelusta niiden toteutukseen ja dokumentointiin sekä koko yritysarkkitehtuurin nyky- ja tavoitetilakuvauksiin.

Tiekartta liiketoimintalähtöiselle IT-arkkitehtuurille

Hyvin usein yritysarkkitehtuurin suunnittelu nähdään IT:n tekemänä harjoituksena, jolloin se kuvataan vain teknisestä järjestelmä- ja palvelin infran näkökulmasta ilman selkeää kytköstä liiketoiminnan tavoitteisiin ja strategiaan. Liiketoiminnan nivoutuminen dataan ja järjestelmiin strategian kautta voidaan myös välillä kokea haastavaksi, koska se usein jää vaille selkeää konkretiaa eikä anna selkeitä suuntaviivoja IT:n kehittämiselle.

Hyvä tapa lähestyä yritysarkkitehtuurin kehittämistä on liiketoimintamallin kautta. Erityisesti tämä on oleellista yrityksissä, joissa on useita liiketoimintoja ja jotka ovat vielä hajaantuneet maantieteellisesti. Liiketoimintamallissa selvitetään eri liiketoimintojen riippuvuussuhteita liiketoimintaprosessien välisten integraatiovaatimusten sekä prosessien standardoimisvaatimusten kautta.

Toimeksiannossa yksi kantava teema ja tavoite oli mallintaa ja kuvata liiketoimintalähtöinen IT.  Tätä varten haastattelimme yrityksen ylintä johtoa tunnistaaksemme liiketoimintojen väliset riippuvuudet, globaalit liiketoimintaprosessit ja niiden harmonisointitavoitteet sekä koko yrityksen liiketoimintatavoitteet, strategiat ja niiden mahdollistajat. Näiden haastattelujen avulla saimme mallinnettua tavoitetilan mukaisen liiketoiminta-arkkitehtuurin, joka ohjaa tarvittavaa tietoarkkitehtuuria.

Tietoarkkitehtuurista järjestelmäarkkitehtuuriin

Tietoarkkitehtuurin kuvaamisessa lähestymistavaksi valittiin kuvata yrityksen hallussa olevat tietopääomat ja niiden riippuvuussuhteet sekä tulevaisuudessa tarvittavat strategisten tavoitteiden mukaiset datat. Uuden datan hyödyntämiskohteista tärkeimpänä nähtiin analytiikka ja vastausten saaminen strategisiin kysymyksiin. Tarvittava teknologia sekä keinot uuden datan hankkimiseen olivatkin jo pääasiassa olemassa ja kysymys oli enemmän datan systemaattisesta käsittelemisestä, tiedon hallinnasta ja sen johtamisesta.

Järjestelmäarkkitehtuurin kehittyminen etenee yrityksissä erikseen tunnistettavina vaiheina, joiden painotus vaihtelee yrityksittäin. Ensimmäisessä kehitysvaiheessa liiketoiminnot suunnittelevat ja rakennuttavat heille yksinomaan räätälöityjä ratkaisuja. Toisessa kehitysvaiheessa tyypillisesti haetaan säästöjä jaettujen resurssien kautta, kuten yhteisien teknisten alustojen käyttöönotolla. Kolmannessa vaiheessa harmonisoidaan järjestelmissä ajettavia liiketoimintaprosesseja ja dataa ja lisäksi haetaan kustannussäästöjä yhteisistä järjestelmistä. Tällöin yritys hankkii käyttöönsä yhteisen ERP järjestelmän, jonne yrityksen ydinprosessit mallinnetaan.

Siinä vaiheessa kun eri liiketoimintojen ydinprosessit on viety yhteiseen ERP:iin, liiketoiminnoilla on usein kuitenkin tarve omille räätälöidyille sovelluksille, jotka voivat tuoda strategista ketteryyttä ja kilpailuetua. Tällöin arkkitehtuurin pitäisi mahdollistaa sekä räätälöidyt modulaariset ratkaisut että toimivat taustajärjestelmät, joissa yrityksen ydinprosessit toimivat vuoren varmasti.

Toimeksiannon asiakkaalla järjestelmäarkkitehtuurin kehittyminen sisälsi kaikkia edellämainittuja kehitysvaiheita, mutta isolta osin ydinprosessit olivat keskitetyssä ERP:issä ja liiketoimintaketteryyttä oltiin mahdollistamassa uudella käyttöliittymäteknologialla, joka kytkeytyy suoraan ydinprosesseihin yhteisessä taustajärjestelmässä ja myös pystyy hyödyntämään siellä olevia valmiita toiminnallisuuksia.

Yritysarkkitehtuurin jalkauttaminen

Viimeiseksi loimme johtamisen ja keskeisten arvojen viitekehikon yritysarkkitehtuurin periaatteista, joiden avulla ohjataan arkkitehtuuriin liittyvää päätöksentekoa. Periaatteet luotiin kaikille yritysarkkitehtuurin tasoille yhdessä asiakkaan liiketoiminta- ja IT-johdon kanssa. Lisäksi kuvattiin yritysarkkitehtuurin periaatteisiin liittyvät liiketoiminnan ja IT:n vaatimukset sekä liiketoimintahyödyt.

Yritysarkkitehtuurin seuraava vaihe on viedä suunnitelma käytäntöön. Käytännössä tämä tarkoittaa tarvittavien muutosten implementoimista kaikilla tasoilla – liiketoiminta-, tieto-, järjestelmä- ja teknologia-arkkitehtuureissa. Vaiheittaisen projektietenemisen kautta nykyarkkitehtuuri päivittyy lähemmäksi tavoitearkkitehtuuria ja muutos on selkeästi kaikkien nähtävissä ja todennettavissa.

Koska kyseessä on pitkän aikavälin suunnitelma, on hyvin todennäköistä, että liiketoiminnan tavoitteet ja strategia muuttuvat matkalla. Tällöin yritysarkkitehtuurin tavoitetilaa on syytä arvioida, kuinka hyvin se vastaa ja pystyy palvelemaan muuttuneita tavoitteita. Mikäli yritysarkkitehtuuri on rakennettu fiksusti liiketoimintamallin ympärille, niin strategiamuutokset eivät yleensä vie tältä työltä pohjaa.

yritysarkkitehtuuri


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.