28.11.2019 / News Team

Last spring, Bilot and The National Audit Office of Finland (NAOF) developed the Risk Detector tool as part of the BilotGo hackathon as an aid to auditors. Risk Detector has attracted plenty of international attention during the course of the year. Many countries struggle with similar challenges in the monitoring of government spending, and Risk Detector has been presented for example to the Supreme Audit Offices of Sweden, Norway and Brazil and to representatives of the European Court of Auditors.

Risk Detector is a tool which utilizes network analysis and artificial intelligence to help design and implement audit work. The tool visualizes government procurement networks and uses artificial intelligence to highlight vendors with profiles that stand out in some way. In this way, with the help of artificial intelligence, auditors can gain new perspectives on the movement of public money.

“The tool gives us the opportunity to look at the subject from multiple angles, and that’s exactly what we were looking for,” praises NAOF project advisor Jasmin Grünbaum.

Risk Detector’s victory march is now continuing across the ocean, as Bilot and NAOF have been invited by the Comptroller General of the Republic of Peru to present the tool at the International Annual Conference for Integrity in Lima on December 3rd. Bilot’s Data Scientist Lauri Nurmela and NAOF’s Jasmin Grünbaum will discuss Risk Detector as part of a panel discussion on bribery and collusion control and detection mechanisms for public officials.

“It is clear the ideas implemented so far are just scratching the surface. The approach we have developed can be applied to so many different contexts, which I’m sure was also noticed by the Peruvians when we introduced the tool. It could even be applied to detecting and preventing criminal networks or black market activity, for example,” muses Lauri.

Case Risk Detector hackathon team after their BilotGo win.
Case Risk Detector hackathon team after their BilotGo win.

26.11.2019 / Mika Laukkanen

Olen ollut  lukuisia kertoja tilanteessa, jossa (mahdollinen) asiakas kysyy “Paljonko tämä suunniteltu AI ratkaisu maksaa kokonaisuutena?”

Luonnollisesti kysymys on relevantti ja oikeutettu, kukapa ei haluaisi tietää kustannuksia ostopäätöksiä tehdessään. Järkevän vastauksen antaminen ei ole aina ihan yksinkertaista, ja tätä dilemmaa avaan tässä jutussa tarkemmin.

Aloitetaan siitä, että miten räätälöidyt AI projektit vaiheistuvat.

Yleensä aloitetaan AI työpajoilla tai vastaavilla määrittelyprojekteilla, jossa arvioidaan business case monesta eri näkökulmasta. Mitä paremmin tässä onnistuu, niin sitä todennäköisempää on, että ratkaisu päätyy myöhemmin tuotantoonkin.

Toinen vaihe on tyypillisesti POC-projekti, jonka keskeisin tavoite on testata toimiiko koneoppiminen käytettävissä olevalla datalla. Tässä samalla myös arvioidaan, että onko itse data riittävän laadukasta ja onko sitä tarpeeksi.

POC-projektin onnistuttua ratkaisua voidaan pilotoida, eli kokeillaan sitä oikeassa ja rajatussa kontekstissa. Esimerkiksi, pilotoidaan asiakaspoistumaennusteiden pohjalta tehtyjä toimenpiteitä rajatulle joukolle asiakkaita. Verrokkiryhmien avulla nähdään erikseen, että toimiiko ennustemalli ja tehty toimenpide.

Ja mikäli POC ja pilotti onnistuivat, niin sitten on valmiudet skaalata ratkaisu tuotantokäyttöön saakka. Muussa tapauksessa, prosessissa voidaan palata taaksepäin, ja tehdä muutoksia/korjauksia tai päättää projekti ylpeästi kokemusta rikkaampana.

Kustannuksiin vaikuttavat tekijät

Otetaan mukaan kolme esimerkkiä, jotka havainnollistavat mistä projektin kokonaiskustannukset muodostuvat.

  • Case 1) yhden tuotteen menekin ennustaminen
  • Case 2) asiakaspoistuman ennustaminen vakuutusyhtiössä
  • Case 3) konenäkö tuotantolinjan laadunvalvonnassa

Kaikissa tapauksissa kahden ensimmäisen vaiheen kustannusten arviointi on suhteellisen helppoa, koska niiden sisältö, tehtävät ja vaiheistus on etukäteen yleensä hyvin selvillä. Eli määritellään business case, kerätään (staattinen) datasetti ja testataan koneoppimista ja datan validiteettia.

Kun arvioidaan pilotoinnin ja tuotantoratkaisun kustannuksia, niin asiat saattavat mutkistua olennaisesti. Miksikö? Seuraava kuva antaa tästä osviittaa.

Kuvan lähde (Google, Inc): “Hidden Technical Debt in Machine Learning Systems”, D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, Dan Dennison

Tuolla keskellä näkyvä punainen ympyrä kuvaa, mitä  POC-projektissa yleensä koeponnistetaan – eli mennään minimillä. Tuotantoratkaisun toteuttamiseksi kaikki muutkin boxit saattavat olla välttämättömiä.

Pilotti/tuotantoratkaisun kustannukset case-esimerkkien osalta?

Case 1) yhden tuotteen menekin ennustaminen, esim. vihreiden omenien.  Tämä on  hypoteettinen esimerkki kaikkein yksinkertaisimmasta ja myös halvimmasta skenaariosta. Nimittäin tässä organisaatiossa tarvittava data on jo valmiiksi tietovarastossa, joka päivittyy joka vuorokausi. Lisäksi POC:issa todettiin, että ennustemallina perinteinen ARIMA toimi mitä parhaiten. Ei tarvita LSTM neuroverkkoja tai muuta hienoa.

Tässä tapauksessa tuotantoratkaisu voisi olla, että ko. ennustemalli ajetaan ETL ajojen mukana kerran vuorokaudessa ja ennusteet tallennetaan tietovarastoon, josta ne lisätään loppukäyttäjän PowerBI Dashboardille. Käytännössä ennustemalli saataisiin tuotantoon hyvin pienellä kustannuksella heti POC:in jälkeen, ja ilman uusia infra- tai ohjelmistokustannuksia.

On mahdollista, että POC-vaihe olisi kustannuksiltaan jopa suurempi kuin varsinainen tuotannollistaminen.

Case 2) asiakaspoistuman ennustaminen vakuutusyhtiössä. Tässä tapauksessa ennustemallin toteutukseen tarvittava data löytyy neljästä eri lähdejärjestelmästä, jotka eivät ole keskenään yhteensopivia, eli tarvitaan huomattava määrä ETL-koodia (~ manuaalista työtä) datan harmonisoinnin toteuttamiseksi.

Näistä järjestelmistä ei myöskään ole liityntää pilvesssä toimivaan tietovarastoon. Niinpä sinne on rakennettava dataputket, tietomallit, käyttäjäoikeudet, jne.

Myös AI ympäristö toteutetaan nyt ensimmäistä kertaa pilveen (esim. ottaen käyttöön Databricks ja Python). Ja uusien teknologioiden käyttöönotto voi hyvinkin johtaa tarpeeseen hankkia koulutuksia asian piirissä toimiville henkilöille.

Eikä tässä vielä välttämättä kaikki, nimittäin Servicedesk järjestelmään aiotaan tuoda poistumaennusteet asiakaspalvelijan tueksi.

Kaiken kaikkiaan kustannuksia generoituu monesta eri lähteestä, ja niiden arviointi alkuvaiheessa on aika haastavaa. Tärkeintä olisikin tunnistaa, että mitä erilaisia kulueriä syntyy ja mikä on niiden kokoluokka?

Tässä tapauksessa POC-vaihe saattaisi olla ehkä 10-20% kokonaiskustannuksista. Jos asiakastiedot jo olisivat harmonisoituna ja kattavasti tietovarastossa, niin tuotannollistaminen olisi merkittävästi edullisempaa. Silloin niistä datoista olisi toki hyötyä muussakin asiakasanalytiikassa.

Case 3) konenäkö tuotantolinjan laadunvalvonnassa. Oletetaan tämä case on toteutettu käyttäen valmista ja maksullista konenäkö API:a, jota on opetettu omilla kuvilla ja tulokset ovat erinomaisia. Eli konenäkö spottaa tuotantolinjalta erehtymättömästi virheelliset tuotteet – kunhan vaan saa kuvia. Tekniseksi ratkaisuksi aiotaan hankkia tehokas laskentapönttö tuotantolinjan välittömään läheisyyteen.

Tähän saakka kustannukset ovat melko hyvin ennakoitavia, mutta tarinaa on vielä jäljellä.

Nimittäin kuvien tuottaman informaation perusteella pitäisi ohjata tuotantolinjan toimintaa. Eikä tuotantolinjan konfiguraation muuttaminen ole välttämättä ihan pieni juttu. Ja mikäli tuotantontilinjalla ei ole vielä kameroita ollut, niin nekin pitää hankkia, asentaa, testata ja huomioida ylläpitoasiat.

Luultavasti POC-vaihe, jossa testattaisiin konenäön kyvykkyyttä tunnistaa virheelliset tuotteet, olisi vain pienehkö osa kokonaiskustannuksesta.

 

Kolme vinkkiä kustannusten pohdintaan

  1. Varmista aluksi, että sinulla on riittävän tärkeä business case ratkaistavaksi. Pitää tulla lisää tuloja, karsia menoja tai optimoida toimintoja.
  2. Mieti tarkkaan, että mitä kaikkia kulukohteita tulee eteen – aina alkuvaiheesta tuotantoon saakka. Arvioi kulukohteiden kokoluokka karkeasti ja plussaa yhteen. Sitten kerro tulos jollakin mielestäsi sopivalla riskikertoimella, sillä jotain jäi kuitenkin listalta pois tai tuli väärin arvioitua.
  3. Vedä yhteen kohdat 1 ja 2, laske uudelleen että onko business case riittävän tärkeä vs. siihen tarvittava investointi.

Mainittakoon vielä lopuksi, että nyt eletään AI ajan alkuvaihetta, jonka vuoksi tarvitaan alkuinvestointeja (esim. data- ja AI ympäristöt sekä osaamisen kehittäminen).

Uskon siis, että jatkossa räätälöityjen AI-projektien toteutus tehostuu ja tulee kustannusmielessä alaspäin.

 


18.11.2019 / Arto Pihlaja

Zeszłej wiosny miałem przyjemność uczestniczyć w hackathonie BilotGo.ai, w teamie który wyszedł z zawodów zwycięsko! Chcę podzielić się kilkoma przemyśleniami – co sprawiło, że osiągnęliśmy sukces? Myślę, że te wskazówki mogą być przydatne również przy innych projektach, które opierają się na danych.

1.   Znalezienie odpowiedniego pytania

Wszyscy słyszeliśmy fascynujące przykłady zastosowania sztucznej inteligencji oraz uczenia maszynowego. Te przypadki są często wynikiem długoletniej, zorientowanej na konkretny cel pracy. Przede wszystkim nasz cel musi mierzyć odpowiednio wysoko, nawet gdy praca postępuje etapowo. O wiele łatwiej jest najpierw podjąć decyzję o projekcie pilotażowym i następnie iść do przodu małymi krokami niż starać się o zatwierdzenie projektu, który potrwa wiele lat, kosztuje miliony, a jego wynik jest niepewny. Jest jednak ważne, by każdy krok przynosił rezultaty korzystne dla biznesu.

Nasz zespół z BilotGo.ai razem ze zleceniodawcą poświęcił dużo czasu na zidentyfikowanie i określenie konkretnego wyzwania do rozwiązania z użyciem technik uczenia maszynowego. Musieliśmy postawić problem, na który odpowiedź miałaby istotne znaczenie dla biznesu oraz który można było rozwiązać z pomocą danych, do których mieliśmy dostęp, jak również zmieścić się w wyznaczonym czasie. Nasz pierwszy pomysł polegał na zbudowaniu modelu, który ustala jak karmienie krów wpływa na ilość i jakość dawanego przez nie mleka, ale wraz z postępem prac byliśmy zmuszeni przedefiniować pytanie. Zdecydowaliśmy, że przygotujemy prognozy ilości dawanego mleka przez krowy na podstawie ich wieku i ocielenia, a pozostałe problemy zostawiliśmy innym projektom.

2.    Zebranie danych

Kiedy wiadomo, jaki jest cel projektu, zaczyna się zbieranie danych, które będą potrzebne do wytrenowania modelu uczenia maszynowego dającego rozwiązanie. Oczywiście początkowo może się okazać, że trzeba przedefiniować pytania i szukać informacji na nowo, ponieważ ilość i jakość danych bywa rozbieżna z oczekiwaniami.

W BilotGo.ai podjęliśmy najpierw zadanie przygotowania modelu prognozy na podstawie przykładowych danych. Kiedy minęła połowa czasu na wykonanie projektu, okazało się, że pliki były zbierane ręcznie z pojedynczych źródeł. W rzeczywistości dane miały zupełnie różną strukturę, a najgorsze, że informacje nie były do końca zrozumiałe. Musieliśmy więc cofnąć się do etapu definiowania problemu. Ustaliliśmy też, że po zawodach przygotujemy plan zbierania i przetworzenia danych.

3.   Przygotowanie danych

Mówi się, że projekt uczenia maszynowego w 80% składa się z przygotowania danych i zaledwie w dwudziestu procentach z rozwinięcia modelu ML. Podobnie było i w tym projekcie, gdy doszło do implementacji! Gdyby wziąć pod uwagę etap przygotowań do pracy oraz później do startu, czas spędzony na pisaniu algorytmów był proporcjonalnie krótki.

Główną częścią naszych danych były wyniki pomiarów uzyskane od robotów, więc można było założyć, że były one odpowiednio uformowane i konsekwentne. W praktyce roboty różniły się i wysyłały dane w różnych formach. Poza tym trudno było zinterpretować dane odstające. Przykładowo, jeśli zawartość tłuszczu w mleku według pomiaru wynosiła 30 procent, błąd w wyniku był oczywisty, ale co jeśli wartość wskazywała między 6 a 12 procent? Przygotowanie informacji wymaga dogłębnego zrozumienia ich znaczenia. Z tego powodu intensywnie współpracowaliśmy z klientem.

4.    Przedstawienie

Nawet najlepsza innowacja może spalić na panewce, jeżeli grupa docelowa jej nie zaakceptuje.

Hackathon zakończył się prezentacją przez zespoły swoich rozwiązań przed jury złożonym z zewnętrznych ekspertów. Nasz zespół poświęcił tydzień z łącznego czasu ośmiu tygodni na ulepszenie interfejsu użytkownika oraz przygotowanie końcowego demo na 15 minut. Zastanawialiśmy się nad nośną opowieścią do prezentacji i sprzątaliśmy zawartość, aby podkreślić innowację i jej korzyści. Tak jak powiedział nasz coach, Antti Apunen: „grupa docelowa nie jest zainteresowana algorytmem, którego użyto – oni ufają waszym zdolnościom i chcą zobaczyć rezultat oraz korzyść”.

W świecie biznesu projekt rzadko da się zamknąć w piętnastominutowym wystąpieniu przed jury, ale nawet w innych projektach launch jest często krótki, a zarazem kluczowy – niezależnie czy jest to wewnętrzny system czy web service. Klienci rzadko dają drugą szansę i nie można spodziewać się zbyt dużej pobłażliwości ze strony użytkowników. Korzyść z rozwiązania musi być wyraźnie podkreślona a zastosowanie jak najłatwiej przedstawione. W końcowym etapie projektu należy więc postawić na komunikację zamiast na dopieszczaniu strony technicznej. Jeśli start się powiedzie, zagwarantuje to możliwość dokończenia rozwiązania w kolejnych etapach.

Myślę, że w hackathonie to właśnie przemyślana prezentacja przechyliła szalę zwycięstwa na naszą korzyść i dała nam nagrodę. Wierzę również, że staranne wykończenie zapewnia sukces każdego projektu.

Więcej o idei stojącej za hackathonem BilotGo.ai można przeczytać tutaj.


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.




19.09.2019 / Pekka Tiusanen

What Do I Need and How Will It Fit?

What tools for AI/ML should be adopted in my organization and how to integrate advanced analytics in data architecture? Implementations are driven by business cases with various technological requirements. There are plenty of options in the market and different SaaS products have characteristic strengths and weaknesses. Existing architecture is a significant factor in decision making as well.

Limited Use of AI/ML within Reporting Tools

Although programming language support and AI/ML capabilities exist for reporting tools, there are certain limitations and hindrances to them. For example, writing R scripts in Tableau requires one to adopt a product-specific workflow and programming logic.

Reporting software can still be utilized to produce small-scale solutions. One of the common use cases for advanced analytics in reporting is key figure forecasting. URL-based integration also allows to embed AI/ML applications in reporting. For example, interactive Shiny apps ® dashboards can be included in Tableau reports. However, these are minimal implementations.

Shortcomings of Graphical AI/ML Tools

Graphical AI/ML utilities, such Azure ML Studio and RapidMiner, are a step up from reporting tools, but they still lack flexibility that is necessary to fulfil large-scale production requirements. Despite having support for R and Python, this is not the standard way to use graphical tools for AI/ML, which reflects to associated usability.

When it comes to training workloads, adding a powerful computation engine on top of other features has not been sufficient for RapidMiner to remain relevant. This is partially because the industry is taken over by end-to-end design and seamlessly conacatenated cloud products from source to consumption.

Finally, mere REST API model deployment without scalability is often not good enough for real-time implementations. On the contrary, IaaS-based solutions for scaling are too tricky to maintain for many organizations. Such solutions also require extra DevOps programming work compared to standardized cloud products for the purpose.

Microsoft Azure Cloud Platform for Scalability, Power and End-To-End Features

Cloud-based programming environments have invaded the AI/ML scene. These products provide calculation power, scaling features and end-to-end readiness. Model training may necessitate a true computation cannon to be swift enough. Furthermore, it is sometimes required for models to be consumed by X thousands of users with a minimal response time. Reasons to prefer such SaaS or MLaaS (machine learning as a service) solutions over custom applications include cloud platform compatibility, ease of maintenance and standardization.

AI tools

Note: Model training in Spark is available for Azure ML Service. However, Databricks a more comprehensive tool for AI/ML development work.

Azure Databricks – Where Data Science Meets Data Engineering

Demand for large scale training computation loads can be met by employing a Spark-driven tool called Azure Databricks. It supports role-based access control and allows data scientists, data engineers and other people involved to collaborate in advanced analytics projects. Developers can write R, Scala, Python and SQL in Databricks notebooks. The resulting AI/ML modelling pipelines can be scheduled by using Azure Data Factory. Version control is typically managed through Azure DevOps.

Note: Databricks is available in AWS too. 

Real-Time Scenario

Scalability requirements for a large user base and stable real-time performance can be addressed by adding Azure ML Service to the chain of sequentially employed cloud products. A typical way to do this would be deploying the solution to Azure Container Service. Kubernetes clusters are often employed in this scenario, but other deployment targets are supported too. Additional custom features can be built inside the web service.

Batch Scenario

If real-time responses are not required by the AI/ML business case, Azure building blocks can be used to generate a batch forecasting pipeline. This is a common scneario where Azure Databricks trains the AI/ML model and writes a batch of forecasts to a pre-defined table. Once again, Databricks workloads can be scheduled with Data Factory. The forecast table is consumed by a reporting tool, such as Microsoft Power BI.

Concluding Remarks

Although AI/ML development is business case driven, cloud environment for POCs and production solutions is also a strategic asset. Modern cloud-hosted solutions provide means to build production ready advanced analytics pipelines. They can also be extended with additional features stemming from business needs and technological landscape. Some of the early AI/ML adopters may have to shift from custom IaaS solutions towards end-to-end cloud platforms to ensure architecture viability in the long-term.


6.08.2019 / Mika Laukkanen

AI projektit ovat monella tapaa vaikeita saada onnistumaan ja viedä tuotantokäyttöön saakka. Erilaisten selvitysten mukaan vain 5% – 10% aloitetuista AI projekteista päätyy tuotantokäyttöön.

BilotGo AI-hackissa toteutimme 2018 neljä projektia, joista kaikki ovat tuotantokäytössä 2019 aikana. Kuluvan vuoden AI-hack päättyi nyt kesäkuussa, joten näistä ratkaisuista ei vielä mikään ole ehtinyt tuotantokäyttöön, mutta aika hyvältä näyttää.

Tarkennuksena mainittakoon, että AI-hackissa siis ratkotaan asiakkaiden oikeita business ongelmia tekoälyn avulla. Kisaamassa ovat tähän saakka olleet Reima, Altia, Kone, RaisioAgro (nyk. Lantmännen Feed), Skanska, VTV ja Metsä Wood.

En käy tässä kirjoituksessa tarkemmin kisaa lävitse, mutta kerron kolme tärkeintä asiaa, joiden avulla AI projektien onnistumisprosentti on saatu nostettua korkeaksi.

Business ongelman valinta

Rohkenen väittää, että oikeanlaisen business ongelman valinta on ylivoimaisesti tärkein asia AI projektin onnistumisen kannalta. Mikään teknologia tai huipputason osaaminen ei pelasta, jos business ongelma on löperösti valittu. Sun Tzukin painotti tiedustelun ja oikeiden taisteluiden valintaa. Tässä on vähän samasta kyse.

Projektien alkuvaiheessa me pidetään strukturoitu AI-Työpaja, joissa käydään asiakkaan valitsemat business ongelmat lävitse kriittisen tarkastelun kautta. Esimerkiksi tuosta AI-hackista on jäänyt pois kiinnostuneita asiakkaita, koska kriteerit täyttävää business ongelmaa ei ole kyetty identifioimaan AI-Työpajassa.

Datan verifiointi alkuvaiheessa

Tekoäly tarvitsee dataa riittävästi ja riittävän laadukkaana. Ja se mikä on riittävästi, vaihtelee huomattavasti eri ratkaisujen välillä. Alkuvaiheessa tehtävän datan verifioinnin lisäksi on tärkeää ymmärtää, että miten data saadaan käyttöön luotettavasti ja riittävän nopeasti myös tuotantoratkaisussa. Moni AI-POC (proof-of-concept) on tähän kompastanut.

Oikeat ihmiset ja osaaminen

Onnistuneen AI ratkaisun luomiseksi ihmisiä tarvitaan yleensä useista eri funktioista ja erilaisilla osaamisilla. Kyseessä ei siis ole nerokkaan Data Scientistin yksilösuoritus. Esimerkiksi tänä vuonna AI-Hackin voittaneessa tiimissä oli osaamista seuraavasti:

  • Osaavat projektipäälliköt (asiakas ja Bilot)
  • Syvää liiketoimintaosaamista (asiakkaan edustajat)
  • Datan mallinnus ja kerääminen (Data Engineer)
  • Koneoppiminen ja tekoäly (Data Scientist)
  • Tulosten visualisointi (Service Designer ja BI expert)

Toiseksi tulleessa joukkueessa kokoonpano oli hieman erilainen, sisältäen mm. verkkokauppaosaamista, koska kyseessä oli verkkokaupan AI ratkaisu.

Kun ratkaisut tuotannollistetaan, niin usein tarvitaan vielä lisää osaamista, jotta tehdyt ratkaisut voidaan integroida osaksi nykyisiä IT ratkaisuja.

BilotGo AI-Hackathon 2019 esittelytilaisuus 12.9.2019

Mikäli haluat tarkemmin kuulla kuluvan vuoden AI-hack projekteista, niin ilmoittaudu mukaan oheisesta linkistä.

https://www.bilot.fi/event/bilotgo-ai-2019/

Aluksi Jaakko Lempinen Yleltä ja Kimmo Pentikäinen Elisalta kertovat miten tekoälyä heillä hyödynnetään. Tämän jälkeen lavan valtaavat VTV:n (Valtiontalouden tarkastusvirasto), Skanskan ja Metsä Woodin AI hackathon esitykset.

Konkreettista ja hyödyllistä tekoälyasiaa siis tiedossa. Unohtamatta aamiaista ja ilmaista lounasta.

Varaa paikkasi ja nähdään 12.9.2019!

Alla voittajatiimin tuuletukset


25.06.2019 / News Team

The succession to last year’s historic reverse AI hackathon BilotGo.ai is now over and we have a winner! With confetti showers and oversized champagne, it is a pleasure to announce that team Valtiontalouden Tarkastusvirasto VTV (National Audit Office of Finland) was elected as the best team.

Our prominent jury comprised of Jussi Tolvanen (Managing Director, Microsoft Finland), Rasmus Roiha (Managing Director, Ohjelmisto- ja e-Business Ry, Taneli Leppä (Customer Engineer, Google Cloud) and Otto Virtomaa (Head of Digital Business Services, SAP Finland).

The level of competition was very good, but the jury was finally unanimous. In their summary, led by Jury spokesperson Jussi Tolvanen, the verdict was eventually very clear, but in reality, all three cases were of really high standards and sophistication, and selecting the winner was very hard. Here is the summary of the jury’s argumentation.

On Skanska – “Very good in utilising AI and business value was well considered. The main question was whether there is a similar solution out on the market.”

On Metsä – “There were very clear business problems to be solved. They were very clear and fairly productized solutions, the main question remained was how to implement them. The jury wondered if by solving the primary solution, was the team’s BilotGo.ai solution actually creating a new one or a substitute for the new.”

On VTV – “A big goal and a big ambition. It will change the overall work in the organization and that auditors were heavily involved in the discussion. The team and customer commitment was very good and this was visible in the presentation as well. The biggest potential in the use of AI and data was still just scratching the surface and seen to have great potential in the future.”

As we saw already last year, BilotGo.ai seems to be a good platform to not only build thought leadership, but also to plant the seed for future development projects in this area. Reportedly Reima’s BilotGo.ai solution from last year’s competition is going to be further developed into a mobile application with worldwide coverage, meaning that all four of last year’s BilotGo cases have now proceeded from the POC stage to actual implementation.

VTV’s case already scored some international coverage and seems to be attracting appeal as far as South America!

The happy winners of BilotGo.ai 2019: team VTV.

Want to hear more about this year’s BilotGo.ai? Attend our event on September 12th!


22.06.2019 / Pekka Tiusanen

Aligning AI strategy and operations with technological solutions can be challenging, but it is definitely more efficient than re-building or patching infrastructure later. The planner should have a clear overall vision of the enterprise architecture and how AI fits in there. Keeping track of the technological landscape with potential business cases in mind is essential too.

Technically speaking, having AI/ML models in production requires data manipulation, model development and model deployment. These steps can be done in various environments and there are multiple approaches for them. Best practices are still evolving and they are often somewhat case specific.

For example, data manipulation can be carried out in the server environment, AI/ML notebooks or by using a cloud-based SaaS tool, such as Databricks available in Azure and AWS. Data science oriented programming is still very relevant, but the environment where modeling scripts are written is shifting towards SaaS as well. Emerging SaaS solutions for AI also provide computing capacity that is sometimes quite critical in data operations and model training.

Modern AI/ML model deployment is often performed by employing an API or a web service. APIs are queried with a certain set of parameters and the output is typically a prediction or recommendation. API-based model deployment has a lot of benefits, such as separation, maintenance and interactivity. There are, of course, out-of-the-box solutions for cloud deployments.

It is common to choose the correct tools separately for data manipulation, model development and deployment. A single SaaS solution can often handle all of these stages sufficiently in the scope of the project. However, it is not unusual to use AI tools in conjunction with one another. For instance, one might use Spark-based Databricks for data manipulation and model training and, on the contrary, handle model deployment in Azure ML Service.

Databricks is quite ideal for data manipulation and model training. It can manage heavy computation loads being still relatively flexible in terms of programming language support. There are also collaborative features associated with the software, which is important as there are more and more people involved in advanced analytics projects. However, the trained model would still be deployed as a web service with Azure ML Service in the joint implementation scenario. The approach allows efficient solution scaling. Azure ML Service has built-in model management and monitoring capabilities as well.

In summary, SaaS solutions have quickly become emphasized in the AI scene. Maintenance of SaaS solutions is often easier compared to tailored custom applications although ready solutions are not as flexible. If you are happy with the set of features provided by an AI SaaS solution, use of it definitely reduces the amount of development work required to reach something functional.

 


13.06.2019 / Mika Laukkanen

Otsikon kysymys tulee eteen useimmille Data Scientisteille jossakin vaiheessa. Useammankin kerran olen ollut tilanteessa, jossa tekoälystä tai koneoppimisesta innostunut asiakas haluaisi ottaa helpon startin asiaan, ja esittää ko. kysymyksen.

En varsinaisesti ihmettele, että tällaisia keskusteluja syntyy, koska aiheen markkinoinnissa on useammin pää pilvessä kuin jalat maassa. Ei siis moitita kysyjiä.

Mutta eipä noista keskusteluista ole haittaakaan ollut, sillä ne ovat avanneet hyvän tilaisuuden jutella aiheesta tarkemmin.

Data on hyvä renki

Miksi ei sitten kannata edetä data edellä tekoälyprojekteihin? Tässä kolme pointtia.

Ensimmäinen pointti on, että tekoälyratkaisujen ”äly” perustuu (nykyisellään) koneoppimismenetelmiin, jotka eivät ymmärrä asioiden välisiä konteksteja. Siinä mielessä ne eivät ole laskimia älykkäämpiä. Kun meillä runsaasti dataa, niin osa muuttujista voi korreloida keskenään, ilman todellista syy-seurausyhteyttä. Dataa sokeasti louhimalla on hyvä mahdollisuus löytää ”jotakin”, joka ei siis ole oikeasti mitään.

Tässä pari kuvaa aihepiiristä.

 

Toinen pointti on, että vaikka datasta löydettäisiin aitoja yhteyksiä asioiden välillä (ei pelkkää korrelaatiota), niin niillä ei välttämättä ole juurikaan liiketoiminta-arvoa. Esimerkiksi tehdään ennusteita asioista, joita ei kukaan tarvitse tai niitä ei voi käyttää. Kerran keksimme eräässä projektissa ennustaa puuttuvia CRM tietoja asiakkaan ostojen perusteella. Malli toimi hienosti, mutta asiakas ei tarvinnut päivitettyjä tietoja. Samoin kävi myös päivystyskäyntiennusteille ja eräälle tilauskannan realisoitumisennusteelle. Ei tarvetta.

Kolmas pointti on, että datan sokeaa tutkailua voi pitää huonona ajankäyttönä. Paljon dataa, paljon tutkimista. Tutkailun tuloksena sitä lopulta keksii jonkin kysymyksen, esim. ennustettavan kohteen. Tämä jälkeen valmistelee datat, tekee mallit ja tulkitsee tulokset. Jos tulokset olivat huonoja, niin sitten toisen kysymyksen kimppuun. Jos ne taas olivat hyviä, niin silti pointin 2 riski voi realisoitua. Tämä ehkä sopii kesätyöksi opiskelijalle, jolle työnantaja ei keksinyt parempaakaan tekemistä.

Mahdollinen poikkeus

Data edellä eteneminen voi ainakin yhdessä tilanteessa olla perusteltavissa. Nimittäin silloin, kun Data Scientist on sen alueen asiantuntija, jonka dataa hänen tulisi tutkailla.

Esimerkiksi osakemarkkinoihin perehtynyt Data Scientist ymmärtää heti ko. alueen datat ja termit (esim. volatiliteetti, pe-luku, beta tai sharpen luku). Ja millaisia asioita näistä dataseteistä on yleensä järkevää etsiä.

Vastaavasti markkinointiin erikoistunut Data Scientist pystynee porautumaan erilaisiin markkinoinnin datasetteihin, ja tekemään niistä tuloksellistakin louhintaa.

Mutta näissä tapauksissa on hyvä huomioida, että Data Scientistin asiantuntijuus ko. alueella on jo lähtökohtaisesti rajannut tutkittavia vaihtoehtoja eikä se ole vain sokeaa hapuilua.

Kokonaisuutena tällaista louhintaa voi pitää innovatiivisena prosessina, jossa pyritään löytämään uusia lähestymiskulmia ja ideoita. Ei niinkään tiettyyn tulokseen pääsemisenä joissakin budjetti- ja aikatauluraameissa.

Minkä asian haluat ratkaista?

Reaalimaailmassa nuo budjetti- ja aikatauluraamit on kuitenkin huomioitava. Uskoisin että seuraavan muistilistan avulla on helpompaa päästä hyödyllisiin lopputuloksiin kuin vain dataa tutkailemalla ja parasta toivoen.

  • Identifioi minkä ongelman haluat ratkaista tekoälyn avulla. Mitä selvempi ongelma, niin sen parempi. Esimerkiksi, myyntiennuste tuotteille x, y ja z kaksi kuukautta eteenpäin. Tai onko tuotantolinjalla kulkeva tuote kuvan perusteella a) virheellinen, b) virheetön.
  • Mieti jos tekoäly jo toimisi, niin mistä sen taloudellinen hyöty syntyy (ROI)? Vähentävätkö uudet myyntiennusteet esim. hävikkiä? Tai paljonko rahaa säästyy, kun virheellisten tuotteiden palautukset puolittuvat?
  • Ennen projektin aloittamista varmista myös, että teillä on dataa, joka vastaa identifioituun ongelmaan ja sitä on saatavilla alkukokeilujen jälkeen myös tuotantokäytössä.
  • Hanki oikeat ihmiset mukaan eri vaiheisiin (kehittäminen, tuotantokäyttö)

Sinällään tässä postauksessa ei varsinaisesti ollut uusia asioita. Jo 1990-luvulla IBM:n kehittämä CRISP-DM kehikko aloitti Business kysymyksestä. Ja se pitää edelleen pintansa.