22.01.2020 / Mika Laukkanen

Useimmat tiedolla johtamiseen (BI, AI, DW) liittyvät projektit lähtevät liikkeelle liiketoiminnan tarpeista ja siten business casen määrittelyllä. Aika usein tämä vaihe kuitenkin jää köykäiseksi harjoitukseksi, jonka seurauksena projekteja aloitetaan puutteellisin tiedoin.

Tässä kirjoituksessa käyn esimerkin kautta lävitse yhden tavan toteuttaa business casen määrittely.

Esimerkkinä business casesta on asiakaspoistuman torjunta vakuutusyhtiössä, vakuutuslajin XYZ osalta.


Vaihe 1 - tiedonkeruu

Ensimmäisen vaiheen tehtävänä on kerätä mahdollisimman kattavasti tietoa ko. business casesta. Tietoja voidaan kerätä sekä sisäisistä (liiketoiminnan asiantuntijat, raportointi,..) että ulkoisista (toimialakohtaiset raportit, avoin data...) lähteistä.

Vakuutusyhtiön asiakaspoistumaan liittyen kerättävää tietoa voisi olla esimerkiksi:

  • Kasvaako tai pieneneekö markkina kokonaisuutena?
  • Miten pärjätään suhteessa kilpailijoihin?
  • Onko tullut uutta suoraa tai epäsuoraa kilpailua?
  • Mikä on ollut poistumaprosentti viimeisen 5 vuoden aikana?
  • Paljonko on poistuman euromääräinen arvo?
  • Paras arvio luonnollisen poistuman (esim. ei tarvetta) ja estettävissä olevan poistuman jakautumisesta?
  • Onko poistumaan tullut isoja muutoksia? Miksi?
  • Mitä poistuman syitä on tunnistettu?
  • Millaisia toimenpiteitä on tehty poistuman estämiseksi?
  • Miten tehokkaita tehdyt toimenpiteet ovat olleet?
  • Kenen vastuulla on asiakaspoistuman torjunta?

Hieman teknisempiä kysymyksiä voisivat olla:

  • Miten poistumaprosentti on laskettu, onko laskenta luotettava ja kestää yli vuosien vertailun?
  • Millaista dataa ja miten pitkältä ajalta on saatavissa liittyen asiakkaisiin?
  • Onko datassa laatuongelmia, jotka tulisi huomioida eri vuosia vertailtaessa tai muuten vaan?
  • Onko data integroitavissa eri järjestelmien välillä (esim. tietovarasto voi olla jo olemassa)?
  • Onko tulevaisuudessa tiedossa muutoksia tietojärjestelmiin tai prosesseihin, jotka vaikuttavat poistuman mittaamiseen?

Ensimmäinen vaihe on siis tiedon keräämistä ja sen perusteella tehtävää kvalitatiivista analyysia, jonka perusteella pyritään saamaan mahdollisimman kattava käsitys business casesta.

Tässä vaiheessa voidaan jo tulla siihenkin tulokseen, että ko. casen osalta ei kannata aloittaa BI/AI/DW projektia. Tällainen tilanne oli taannoin, kun asiakkaalla oli datan luokitteluperusteet muuttumassa, joka teki vanhan ja uuden datan vertailukelvottomaksi.


Vaihe 2 - ongelman purkaminen osiin

Seuraavaksi hajoitetaan tunnistettu business case loogisiin osiin, joka helpottaa analysointia ja ratkaisujen löytämistä.

Esimerkin XYZ vakuutuslajin poistumaksi on tunnistettu 10% ja siitä muodostetaan seuraava puurakenne, perustuen vaiheen 1 aikana kerättyyn tietoon.

Nyt kun haluamme vähentää asiakaspoistumaa, niin emme tässä analyysissa keskity luonnollisen poistuman boxiin, koska siihen emme voi vaikuttaa. Tosin siitä voisi muodostaa oman business casen, esim. ideana tarjota toisenlaisia vakuutuksia.

Esimerkin analyysi voisi syventyä seuraavalla tavalla.

Nyt olemme päässeet tilanteeseen, jossa estettävissä oleva poistuma on jaettu loogisiin kokonaisuuksiin, joita voidaan analysoida erikseen ja löytää niihin omia ratkaisumalleja.


Vaihe 3 - ratkaisujen etsiminen

Jatketaan siis edellisen kuvan perusteella.

Haaste: Parempi tarjous kilpailijalta

Mikäli asiakas on saanut kilpailijalta paremman tarjouksen, niin se johtaa kahteen eri vaihtoehtoon.

  • Asiakas kysyy meiltä kilpailevaa tarjousta, johon voimme vastatata paremmalla, yhtä hyvällä tai heikommalla tarjouksella.
  • Mikäli asiakas irtisanoutuu kysymättä meiltä tarjousta, niin voimme silti tehdä aiempaa paremman ehdotuksen tai olla tekemättä mitään.

Mikäli tässä valitaan aktiivisia keinoja, niin ne ovat relevantteja poistumantorjunnan kannalta. Tässä blogissa ei mennä tämän asian suhteen pidemmälle. Joka tapauksessa näistä kaikista toimenpiteistä on mahdollista kerätä myös dataa, jota voidaan hyödyntää jatkossa, jotta tiedetään esim. mitkä toimet ovat tehokkaita ja mitkä eivät.

Haaste: Tyytymätön

Tiedetään siis, että meillä on asiakkaita, jotka eivät ole ihan tyytyväisiä ja siten potentiaalisia lähtijöitä. Käytännön haaste on, että asiakkaita on paljon eikä missään tietojärjestelmän kentässä lue "tyytymätön" tai "miksi on tyytymätön", eli mikä avuksi?

Vedetään kani hatusta ja todetaan, että hyödynnetään koneoppimista, jonka avulla voidaan

  1. datasta laskea eri tekijöiden vaikutus poistumaan
  2. ennustaa poistuvia asiakkaita (scoret)

Koneoppimisen kautta saatavat tulokset siis mahdollistavat useita konkreettisia toimenpiteitä, esim. asiakastuntemuksen, markkinoinnin ja palveluiden kehittämisen osalta. Ja ennen kaikkea, tulosten avulla voidaan vaikuttaa asiakaspoistumaan.


Vaihe 4 - ratkaisujen arviointi

Seuraavaksi prosessi etenee siten, että arvioidaan eri ratkaisuvaihtoehdot, huomioiden riittävän kattavasti niihin liittyvät tekijät.

Käytetään esimerkkinä äsken mainittua koneoppimista, ja laitetaan sekin puurakenteeseen.

Kuvassa listatut kohdat eivät ole kattavia, vaan lähinnä esimerkkinä. Olennaista on, että mukana olisi onnistumisen kannalta kaikki keskeiset asiat. Käytännössä noihin sinisiin boxeihin kirjattuihin kohtiin pitäisi löytää uskottavat vastaukset.

Kannattaa myös huomata, että usein hyvältä vaikuttavat ratkaisuvaihtoehdot (kalvoilla) saattavat luoda uusia potentiaalisia haasteita ratkottavaksi. Toisinaan niin suuria etteivät ne ole ratkaisuja ollenkaan.

Lisäksi on tärkää löytää sellaiset tekijät, joita ilman ratkaisu ei tule tuotannollistumaan eikä business tavoitteita siten saavuteta.

Esimerkkinä vuosia sitten ollut poistumaprojekti, jossa tuotantokäyttöön ei päästy, koska siellä ei ollut liiketoimintavastaavaa asialle.

Perusteellisemmin tehty business casen määrittely olisi kenties säästänyt turhalta POC-projektilta.

Kannattavuuslaskelma

Ratkaisun arvioinnissa on tietysti huomioitava sen kustannukset ja oletettu tuottopotentiaali. Yleensä tällöin käytetään ROI tai takaisinmaksuaikalaskelmia, joilla perustellaan investoinnin kannattavuus. Etenkin koneoppimisratkaisujen osalta on hyvä tiedostaa, että tulokset eivät ole varmoja, jolloin kannattaa hakea epäsymmetristä riski-tuottoskenaariota (pieni riski, iso tuotto).

Tässä esimerkissä luvut voisivat olla:

  • Investoinnin kokonaiskulu (sisältäen kaiken: data, koneoppiminen, tuotannollistaminen, markkinointi..) -150 000 eur ensimmäisenä vuonna ja sitten -50 000 eur / vuosi
  • 2% pudotus poistumassa tuottaa +200 000 eur / vuosi
  • 5 vuoden investointi, -350 000 eur
  • 5 vuoden tuotto, +1 000 000 eur
  • 5 vuoden nettotuotto +650 000 eur

Noilla luvuilla projektin aloitus olisi todennäköisesti järkevää. Ainakin houkuttelevaa.

Käytännön elämässä on kuitenkin usein tilanteita, joissa suoraviivaisen kannattavuuslaskelman tekeminen ei oikein onnistu. Silloinkin pitäisi pystyä järkeilemään, että miksi investointi olisi kannattava.


Vaihe 5 - päätösten aika

Lopuksi ollaan tilanteessa, jossa on kerätty kaikki relevantti tieto business casen osalta, jaettu ongelma osiin, muodostettu hyvin pohdittuja ratkaisuehdotuksia, tehty kannattavuuslaskelma (tai vastaava ajatustyö) ja varmistuttu ettei tunnistettuja show-stoppereita ole matkalla.

Mikäli ratkaisuvaihtoehtoja on useita, niin niiden priorisoinnissa voi käyttää apuna esim. seuraavaa matriisia.

Nyt kun ollaan vielä business casen määrittelyvaiheessa, niin priorisoinnin tekeminenkin perustuu aiempiin analyyseihin ja koulutettuun arvaukseen. Vasta kun toimenpiteitä on oikeasti koeponnistettu, niin tiedetään tulosten ja panosten välinen suhde.

Tässäpä tämä tällä kertaa, eikun pohtimaan business caseja.


2.01.2020 / Lauri Nurmela

The BilotGo hackathon concluded last June with the AI-boosted auditing tool, Risk Detector, taking first place. In brief, Risk Detector utilizes network science and machine learning to highlight various perspectives relating to government procurements and their inherent risks, thus enabling auditors to shift their work from tedious manual inspection of data to being able to explore curated points of interest relating to their work.

Risk Detector goes to Peru

As Risk Detector enters a piloting phase at the National Audit Office of Finland (NAOF), the tool has also enjoyed worldwide attention among similar national audit entities in countries all over Europe and elsewhere. One particularly interesting opportunity presented itself when our tool caught the eye of the organizers of the annual anti-corruption conference CAII at the Comptroller General’s Office of Peru.

With timing working out perfectly, we headed out with Jasmin Grünbaum from NAOF as speakers at the conference to present the level of Finnish data innovation to an audience of more than 1000 conference participants from over 20 countries. More specifically, Risk Detector was presented as part of a panel discussion on the control mechanisms of public officials.

Present with us were also a senior specialist on data-driven anti-corruption work from the World Bank, as well as a money-laundering expert from Mexico. As with our own ideas on how to take Risk Detector forward, there was particular interest on how the methodologies employed in the tool could be used in other contexts such as money laundering or drug trafficking.

The impact of open data

So what to take away as a data professional from attending an anti-corruption conference on the other side of the world? As it turns out, there was one great talking point that was persistently brought up in nearly every presentation I attended – the impact that open data is making in the world.

In terms of anti-corruption policies and activities, open data was highlighted at the conference as a crucial tool to increase transparency in government, enabling tax-payers to take part in ensuring the efficient use of their money. Besides fostering the opportunity to benefit from the work of citizen data scientists, it should also be recognized that open data also opens up resources within governments for data-related projects.

Having gained a global perspective at the conference, the impressive quality, breadth and depth of the open data sources we have here in Finland should be a point of pride that highlights the working design of the processes and standards that enable the existence of this resource. Say what you will about the dusty bureaucracies with endless rabbit holes of processes, comparing to other countries in terms of open data we are clearly doing something right!

Why you should look into open data

Besides the government and its citizens, there are also opportunities for businesses in exploiting open data sources. I’ve listed below two relatively low-hanging fruits that many companies involved with digitalization may find worth looking into.

Machine learning

Risk Detector is at this stage based 100% on open data sources. Working closely with auditors as end-users, our service design methodologies (shout-out to Katariina!) allowed us to develop a fully functional machine learning framework and a demo to answer business questions around a certain area.

While the initial hackathon project was very cost-efficient to the client, the benefit on our side is that the framework that was developed has great potential for generalization. Effectively this means that at this point it is a near-trivial amount of effort to pivot to analogous business questions, and thanks to that we are now able to offer a unique approach to the market.

Besides providing a data source for machine learning models for business, it’s also good for practitioners to recognize that they may often be a good resource just for practicing different methods as well.

Advanced analytics

Moreover, open data could also be utilized in advanced analytics. Concerning low-hanging fruits, I would point out the potential especially in geospatial analytics: Demographic statistics, for example, are relatively easy to join to geospatial data. This allows analysts to better answer questions concerning demand or behavioral patterns. In another example, open satellite imagery could be used in more specific cases to automate monitoring or progress reporting, for example.

Final point

In this article I’ve listed some of the potential selling points for open data. The motivation for this text could of course be seen as a promotion of our capabilities in demonstrably extracting value from data resources, but there is actually another point to be made. The simple reason that I chose to write extensively about this topic is that as open data resources gain popularity, it encourages other parties to offer up their data to the public as well – effectively resulting in a positive feedback loop. The more we use open data sources, the more likely we are to see even better resources in the future.

Happy hacking everyone,

Lauri


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.

 


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!


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.


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.


15.03.2019 / Mika Laukkanen

Kirjoitan aiheesta, jota olen sivunnut aiemminkin blogeissa ja somepostauksissa. Eli: miksi hyvin menneet AI POC:it ja pilotit meinaavat jäädä pöytälaatikkoversioiksi?

Tässä on viisi keskeistä syytä, jotka olen itse oppinut ns. kantapään kautta.

  1. POC projektissa on kokeiltu vain murto-osa toiminnallisuudesta (eli koneoppimismallin toimivuus), jota tarvittaisiin tuotantoympäristössä. Esimerkiksi tuotannossa pitää järjestää palvelimia, pilvipalveluita, datan automaattisia siirtoja, ETL-prosesseja, ML-mallien päivityksiä, ylläpitoa, jne. Nämä kannattaa miettiä jo jollakin tasolla valmiiksi heti alkuvaiheessa.
  2. Aluksi ei ole pohdittu, kenen tontille mahdollinen tuotantoratkaisu laskeutuu. Kuka sen omistaa ja vastaa siitä? Vaikka POC olisi menestys, niin se ei tarkoita, että kukaan ottaisi koppia sen tuotannollistamisesta ja kehittämisestä.
  3. Tuloksena saadun AI-ratkaisun tulokset saattavat olla vaikeita käyttää ihmiselle. Esimerkiksi, myyjä saa AI-ratkaisulta ehdotuksen "optimaalisesta hinnasta" tarjoukseen, jolla tarjouksen läpimenon todennäköisyys on korkein. Myyjä ajatteli laittavansa hinnaksi 10 000 ja AI ehdottaa 12 000. Myyjä tuntee (mielestään) asiakkaan ja markkinat eikä luota korkeampaan hintaan, etenkään kun AI-ratkaisu ei perustele ehdotustaan. Tässä tarvitaan ns. jalkauttamista, kouluttamista ja kärsivällisyyttä. Tämän asian haastavuutta voi tuskin korostaa liikaa.
  4. POC:in aihe on valittu alueelta, jolla on liian vähäinen merkitys, jotta sitä kannattaisi tuotannollistaa. Tämä on toisinaan seuraus siitä, että aluksi asetetaan rima liian alhaalle. Tahdotaan vain testata, että ”toimiiko koneoppiminen”. Yleisempi syy kuitenkin on, että aluksi ei ole pohdittu riittävästi casen business merkitystä, huomioiden vielä kohdan 1) seikat.
  5. Olen pistänyt merkille, että niissä projekteissa, joissa on henkisesti lähdetty tekemään heti tuotantoversiota (vaikka POC:illa aloitetaan), niin tuotantoversioon päätyminen on huomattavasti todennäköisempää kuin projekteissa, jossa lähdetään vaan kokeilemaan ”toimiiko AI”. Ehkäpä tämä on sitä johdon sitoutumista asiaan? Joka tapauksessa, asenteella on väliä.

Yhteenvetona voi todeta, että onnistuneiden AI POC ratkaisujen pöytälaatikkoon päätyminen johtuu usein liian suppeasta suunnittelusta alkuvaiheessa. Toisaalta tämä on ymmärrettävää, koska harvemmalla organisaatiolla tai konsultillakaan on merkittävää määrää kokemusta AI projektien läpiviennistä. Ollaan uusien asioiden äärellä.