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.


31.05.2019 / Teemu Lainiola

A lot of data is created and collected in many businesses. Do you have a data strategy in place to change that data into new business?

Data strategy is all about understanding what data you have and how it could be used to run your business better. A good data strategy also considers the possibilities of new business models and monetization of your own data.

Before starting to think about creating a complete data strategy in your company, the focus should be more on the data value design and data assets since data assets may be the most important assets you’ll have in the near future.

But how to sort out, what kind of data assets you have in your organization and what kind of data does your business need within the next 3-5 years? Check out our video to hear more.

Read more about the topic: https://www.bilot.fi/service/data-strategy/ 

Or contact Teemu Lainiola (+358 44 500 8031, teemu.lainiola@bilot.fi)


27.05.2019 / Mika Laukkanen

Heti aluksi on mainittava, että tämä blogi on kohdistettu pääasiassa henkilöille, joilla on liittymäpintaa Business Intelligence ratkaisuihin ja nyt niiden parantaminen tekoälyn avulla on alkanut kiinnostaa.


Tekoälyyn liittyvissä esityksissä käytetään usein seuravaanlaista esitystapaa, kun halutaan kuvata mihin tekoäly asemoituu datan hyödyntämisessä.

 

Kuvan alkupää lähtee perusraportoinnista (mitä tapahtui) ja etenee kohti edistyneempää analytiikkaa (ennustamista) – samalla kun vaikeusaste ja ratkaisun arvo kasvaa. Loppupäässä on luonnollisesti kyse nykytermein tekoälystä tai AI:sta.

Pitäisikö kuvaa tulkita niin, että tekoäly on kehittyneempää Business Intelligenceä? 

Yllättävän usein olen törmännyt eri yrityksissä ajatteluun, jossa tekoälyn kehittäminen on sidottu Business Intelligence järjestelmien kehittämiseen. Ajatuksena se, että kun kerätään dataa ja tehdään raportteja, niin sen jälkeen ollaan kypsiä hyödyntämään koneoppimista (tekoälyä) samassa aihepiirissä.

Eli tekoälyprojektien aloittamista saatetaan (turhaan) viivytellä, jos “perusraportointi ei ole kunnossa”.

Kynttilöistä ei kehittynyt hehkulamppuja

Jos katsotaan reaalimaailman tekoälysovelluksia, niin vain melko harvassa niistä on havaittavissa em. kehityskulku raportoinnista tekoälyyn. Seuraavissa tapauksissa ko. esitystapa ei oikein edes toimi. Eikä varmaan ole tarkoituskaan.

  • Kuvantunnistus ja konenäkö
  • Tekstianalytiikka ja luonnollisen kielen tunnistus
  • Ennakoiva huolto reaaliaikaisella IoT datalla
  • Anomalioiden löytäminen Big Datasta
  • Musiikin tai kuvien tuottaminen tekoälyn avulla

Eli tekoälyratkaisuja syntyy paljon alueille, joissa perinteisellä Business Intelligencellä ei ole roolia.

Toisaalta, tekoälyratkaisuja voidaan usein kehittää ilman taustalla olevaa BI ratkaisua vaikka se toisikin lisäarvoa tai asioiden välillä näyttäisi olevan luonnollinen jatkumo.

Otetaan esimerkki asiakasanalytiikasta, vaikka asiakaspoistuma. Jos BI:n ja AI:n sitoo toisiinsa, niin on luonnollista rakentaa ensiksi BI-järjestelmä, jossa asiakastiedot ovat tietovarastossa, josta tehdään nippu raportointia, esim. “kuinka monta % asiakkaista poistuu vuosittain”.  Ja kun tämä on valmiina, niin hyödynnetään tekoälyä ennustamaan, että ketkä ovat seuraavat kytkimen nostajat.

Näin voi toimia, mutta käytännön elämässä on toimittu myös käänteisesti.

Kuvassa on esitetty erään oikean tekoälyprojektin vaiheet. Siinä aloitettiin keräämällä asiakastietoja monista eri lähteistä, vain ennustamista varten. Kun myöhemmin ennustemallit huomattiin toimiviksi (olivat jo tuotannossa), niin ko. tietoja alettiin tuoda BI-järjestelmään.

Kuulin joskus hauskan vertauksen, jossa todettiin ettei kynttilöistä kehittynyt hehkulamppuja. Siinä oli kyse disruptiivista keksinnöistä, hehkulamppu ei ollut vain parempi kynttilä. Mielestäni sama analogia toimii myös aika hyvin BI:n ja AI:n välillä.

Eri tarkoitus, eri kehityspolut

Business Intelligence -ratkaisut ovat nyt ja jatkossa kivijalka yritysten raportoinnille ja analytiikalle, jota ilman ei tule toimeen. Omenakauppiaan tulee tietää monta omenaa meni kaupaksi eilen, viime viikolla ja joulumyynnissä.

Tekoälyratkaisut eivät auta omenakauppiasta vain ennustamaan omenoiden menekkiä, vaan myös tulkkaamaan kiinalaisten turistien omenatiedustelut ja automatisoimaan kirjanpidon.

BI ja AI ratkaisuilla on yleensä eri tavoitteet, mutta myös itse projektit saattavat erota kuin yö ja päivä toisistaan. Näistä syistä en sitoisi niiden kehittämissuunnitelmia liian tiukasti toisistaan riippuvaiseksi.