13.11.2019 / Aarni Vanamo

Lähtökohta

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

Demon tarkoitus

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

Demon aihe ja rajaus

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

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

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

Toteutus

Palvelin

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

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

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

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

Mittausdatan kerääminen

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

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

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

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

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

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

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

Mittausdatan tallentaminen palvelimelle

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

Mittausdatan julkaiseminen

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

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

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

Applikaation suunnittelu ja toteutus

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

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

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

Joitain lisäpaketteja asenneltiin sitten vielä tarpeen mukaan:

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

Yhteenveto

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

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

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

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

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

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


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.


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ä.


21.02.2019 / Mika Laukkanen

Kun aloitin työurani 1990 luvun lopulla, niin tietovarastojen ja raportoinnin toteutus oli nykyistä paljon selkeämpää. Tietolähteet olivat pääasiassa relaatiokantoja tai melko yksinkertaisia tekstitiedostoja.  Eikä raportointikaan ollut kovin monimutkaista, koska silloisilla työvälineillä rajat tulivat nopeasti vastaan. Itsensä tunsi kuninkaaksi, jos sai graafin ja taulukon samalle sivulle.  Datan laatu oli toki samaa puppua kuin se nykyäänkin tuppaa olemaan.  Tuon ajan tyypillinen DW arkkitehtuuri oli seuraava.

Nykyiset arkkitehtuurikuvat ovat yksinkertaisimmillaan vastaavia, mutta yleensä kuitenkin monipuolisempia. Nyt on enemmän erilaisia tietolähteitä, samoin kuin datan tallennus- ja esityspään ratkaisuja.

Miksi sitten tietovarastoja alettiin alunperin rakentaa? Tässä muutamia syitä, jotka löytyivät vuonna 2001 tehdyiltä powerpointeilta.

  • Tietojen yhdistely ja harmonisointi eri tietojärjestelmistä
  • Yksi totuus päätöksentekoon
  • Käyttäjien ad-hoc kyselyt mahdollisia ja tietohallinnolle jää aikaa muuhun työhön
  • Tietovarasto historioi yrityksen datat, saadaan aikasarjoja ja analytiikkaa
  • Ei rasiteta operatiivisia järjestelmiä raportoinnilla

Nämä samat argumentit pätevät varsin hyvin vielä nykyäänkin. Mainittakoon että jossakin vaiheessa oli buumi, jonka mukaan kaikki yrityksen datat pitäisi saada keskitettyyn EDW ratkaisuun. Nyt ajatus tuntuu vähän hassulta, mutta ei tuntunut silloin, koska dataa syntyi suhteellisen pieniä määriä ja lähinnä omissa järjestelmissä.

Tietovarastot tehtiin raportoinnin tarpeisiin

Perinteisesti tietovarastoihin tuotava data on määräytynyt raportointitarpeiden mukaisesti. Esimerkiksi talousraportteja varten on tuotu talousdataa ja HR-raportteja varten HR-dataa. Lisäksi tietysti löytyy kombinaatioita, joissa raporteille on yhdistelty eri alueiden tietoja.

Nyt kun tiedetään, että koneoppimis- ja tekoälyratkaisut tarvitsevat dataa oppiakseen, niin eikös ole loistavaa, että vuosikymmeniä dataa on purkitettu tietovarastoihin?

Vastaus on toisinaan kyllä, mutta usein ei.

Kun dataa on kerätty vain raportointitarpeita ajatellen, niin on sattuman kauppaa, että sopiiko se koneoppimisen hyödyntämiseen. Selvennetään asiaa esimerkillä.

Tietovarastoon XYZ kerätään asiakasdataa, josta on tarkoituksena raportoida asiakaskohtaiset eurot tuotteittain, tuoteryhmittäin, asiakassegmenteittäin ja vaikkapa päivätasolla. Kerätään siis tietovarastoon laskutus-, tuote- ja asiakastiedot.

Tässä vaiheessa paikalle saapuu datatieteilijä, joka haluaisi tehdä asiakaspoistumamallin. Hetken dataa tutkailtuaan hän havaitsee, että tietovarastoon ei ole tuotu asiakkaan sopimukseen liittyviä tietoja. Ne olisivat todennäköisesti keskeinen elementti asiakaspoistumamallissa. Tai ehkä sopimustiedot ovat tietovarastossa, mutta niistä tunnetaan vain viimeisin tilanne – ei koko asiakkaan sopimushistoriaa, joka olisi jälleen olennaista asiakaspoistumamallin kannalta. Dataa siis voi olla, mutta siitä ei silti ole olennaista hyötyä.

Olen ollut mukana kymmenissä koneoppimisharjoituksissa, ja vain harvoissa kaikki tarvittava data on ollut saatavilla ns. perinteisestä tietovarastosta. Tyypillisimmät haasteet ovat olleet:

  • Tarvittavaa dataa ei ole ollenkaan tietovarastossa tai vain osittain
  • Dataa on tietovarastossa, mutta liian lyhyeltä ajalta (historiaa poistettu)
  • Tarvittavan datan historiointi on liian harvaa / epätäydellistä

 

Miten huomioida tekoäly tietovarastojen suunnittelussa?

Koska tietovarastojen suunnitteluun ja tekemiseen joka tapauksessa upotetaan valtavia summia rahaa, niin kannattaisi tehdä muutamia toimenpiteitä, jotka tukisivat ajatusta, että tietovaraston sisältö voisi olla syötteenä tekoälyratkaisuille jatkossa. Esimerkiksi.

  • Samalle datalle on hyvä olla useampi käyttötarkoitus (esim. asiakkaaseen liittyvä perinteinen raportointi, asiakaspoistumamallinnus ja asiakaskohtaiset myyntiennusteet).
  • Raportointitarpeiden lisäksi tarvitaan siis näkemystä, että millaisia tekoälyratkaisuja jatkossa halutaan tehdä. Jos ei ole dataa, niin ei tule ratkaisujakaan.
  • Datan historiointi kattavasti. Tämä vaikuttaa mm. tietovaraston mallinnustapaan. Näyttäisi siltä, että Data Vault ei ole hassumpi vaihtoehto vaikka pelkkään yksinkertaiseen BIDW projektiin se saattaakin olla järeähkö menetelmä.
  • Datan määrällä on merkitystä tekoälylle vaikkei raportoinnissa tarvittaisi kuin 3 viimeistä vuotta. Tietovarastoja ei siis kannata tyhjentää ”turhasta datasta”, vaan mieluummin siirtää vanhaa dataa muuhun ympäristöön. Jos vain vähääkään näkee, että sillä voisi olla käyttöä myöhemmin.
  • Kaikkea tekoälyratkaisuissa käytettävää dataa ei tarvitse tai kannata tuoda välttämättä tietovarastoon. Usein on viisaampaa pitää esim. IoT sensoridatat tai nettisivujen verkkolokit jossakin muussa ratkaisussa.

Näillä muutamalla opilla tietovarastoista tulee jo tekoälykelpoisempia. On kuitenkin hyvä huomata, että datan purkittaminen yhteen paikkaan ei itsessään synnytä tekoälyratkaisuja – siihen tarvitaan selkeät business caset. Data toimii sitten mahdollistajana.


28.08.2018 / Mika Laukkanen

Tässä on kollega Ville Niemijärven kirjoitus analytiikan (nykyään tekoäly tai koneoppiminen) hyödyntämisestä vuodelta 2014. Ajattelin hieman päivittää sitä ja laittaa uudelleen jakoon, kun aihe on ajankohtaisempi kuin artikkelin ilmestymisvuonna. Kukapa muuten tietää, että millä termillä näitä ratkaisuja kutsutaan seuraavan neljän vuoden päästä?


Asiakaspoistuma-analyysi (eng. churn) tarkoittaa analytiikan prosessiketjua, jossa selvitetään mitkä asiakkaat ovat vaarassa poistua, millä todennäköisyydellä ja miksi. Poistuma tarkoittaa sitä kun asiakas lopettaa sopimuksen palveluntarjoajan kanssa tai yksinkertaisesti lopettaa asioimisen yrityksessä. Voidaan puhua myös asiakaspidosta (eng. retention). Termi liittyy läheisesti myös asiakkuuden elinkaaren arvon määrittämiseen (customer life-cycle value) ja nykypäivän yhteen muotitermiin; customer journey. Itse näkisin kuitenkin, että kyseessä on enemmänkin yksinkertaisesti paremmasta asiakashallinnasta ja huolenpidosta…

Poistuma-analyysi sopii hyvin sopimusliiketoimintaan, esimerkiksi sähköyhtiöille, puhelin- ja internet operaattoreille, kuntosaliketjuille tai lehtitaloille. Mutta poistuma-analyysiä voidaan tehdä myös vähittäiskaupassa, jos vain asiakas tunnistetaan (kanta-asiakasjärjestelmän avulla). Tällöin pitää vain päättää milloin asiakas on poistunut? Mikä on riittävän pitkä aika, että asiakas ei ole käynyt kaupassa, jotta voidaan päätellä hänen vaihtaneen vakiokauppaansa.

Tässä kirjoituksessa käydään läpi asiakaspoistuma-analyysiä ja miten se tehdään käytännössä. Lähestymme aihetta yleisestä yksityiseen. Lopussa näytämme kädestä pitäen miten homma tehdään alusta loppuun.

Asiakaspoistuma-analyysin tuotto on helppo laskea

Kaikessa analytiikkatyössä tulee laskea mitä saamme analyysistä irti, mikä on investoinnin ROI, paljonko jää viivan alle. Jollei investointi tuota moninkertaisesti enemmän kuin analyysi ja tiedon keräys maksaa, ei sitä kannata tehdä.

Asiakaspoistuman osalta tämä on erittäin helppoa tehdä. Otetaan esimerkki sähkön myynnistä.

Sähköyhtiöllä on 100 000 asiakasta. Keskimääräinen laskutus per asiakas on 1000e/vuosi. Nopea selvitys sähköyhtiön sopimuskannasta kertoo, että keskimäärin vuodessa sopimuksen lopettaa 8% asiakkaista.

Tämä tarkoittaa, että asiakkaita poistuu 8000 kpl/vuosi. Rahassa tämä on siis 8000kpl*1000e=8 miljoonaa euroa. Tuo on se potti, jota lähdemme pienentämään ja sitä kautta tekemään asiakkaallemme lisää rahaa.

Osa näistä 8000:sta poistuu luonnollisen poistuman kautta, osa vaihtaa kaupunkia. Ja sitten on se osa joka vaihtaa palveluntarjoajaa koska yrityksen tuote, palvelu tai hinta ei ole riittävän hyvä. Tai kilpailijalla on parempi. Kutsuttakoon tätä laadulliseksi poistumaksi.

Kun menemme asiakkaalle, teemme aina vastaavan laskelman ja arvioimme asiakkaan kanssa yhdessä, mikä on tuon laadullisen poistuman osuus ja kuinka paljon on realistista saada pienennettyä sitä. Sähköyhtiöiden osalta voimme katsoa julkisesta datasta, esim. THL:ltä, mikä on muuttoliike kunnasta pois päin ja paljonko poistuu jalat edellä. Näin emme joudu arvailemaan vaan meillä on faktaa laskelmien taustalla. Sanottakoon esimerkkinä, että sähköyhtiön tapauksessa 3% on luonnollista/muuttopoistumaa ja loput 5% on laadullista poistumaa. Poistumaa, johon voimme vaikuttaa. Tähän iskemme kyntemme.

Entä jos voimme pudottaa tuota 5% poistumaa vaikka vain yhden prosenttiyksikön? Tämä tarkoittaisi 1000 asiakasta ja miljoonaa euroa vuodessa lisämyyntiä. Jos analyysi maksaa 20 000 euroa, on investoinnin tuotto aika huima. Se on jotain sellaista, jota kannattaisi kaikkien tavoitella.

Mitä dataa poistuma-analyysi tarvitsee?

Ensiksi otamme historiatietoa eli tietoa jo poistuneista ja ei-poistuneista asiakkaista. Toisin sanoen sähköyhtiön tapauksessa luemme sopimustietokantaa ja sähkönkulutustietoja (yhä yleisemmin tietovarastoa tai edistyneimmissä yrityksessä erikseen toteutettua analytiikkakantaa) ja haemme sieltä mahdollisimman pitkän historian, mahdollisimman monelta asiakkaalta. Mitä enemmän sitä parempi. Historia-aineistoon otetaan mukaan asiakkaiden taustatietoja sekä käyttäytymiseen liittyvää tietoa.

Taustatietoja ovat esimerkiksi

  • alue/kaupunki/postinumero
  • demografiatiedot (tulo- ja koulutustaso)
  • sukupuoli
  • ikä
  • asiakkuuden kesto
  • talotyyppi, koko, lämmitysmuoto jne. toimialaspesifistä tietoa

Käyttäytymiseen liittyviä tietoja ovat esimerkiksi:

  • kulutus- ja laskutushistoria (esim. keskimääräinen kulutus per kk)
  • ostetut tuotteet (eli millainen sopimus)
  • reklamaatiota, asiakaspalautteet, yhteydet asiakaspalveluun
  • maksuhäiriöt
  • muut toimialaspesifit tiedot
  • Ja lopuksi se tärkein tieto: onko asiakas poistunut vai ei (K/E)

Monilta yrityksiltä ei löydy kaikkia näitä tietoja, olen nähnyt yrityksiä joilla asiakkaista tiedetään käytännössä vain numero ja osoite. Ei edes nimeä tai sitä onko kyseessä yritys- vai henkilöasiakas. Ennen kuin analytiikkaa päästään hyödyntämään täysillä, on edessä usein systemaattinen tiedon keräämisvaihe ja mahdollisesti muutokset lähdejärjestelmiin/tietovarastoon.

Ennen analyysia emme tiedä mitkä tiedot ovat relevantteja ja vaikuttavat poistumisen takana ja sen selvittäminen onkin koko homman ydin.

Miten poistuma-analyysi tehdään?

Kun tiedot on kasassa, jaamme datan kahteen eri settiin: opetusdataan ja testidataan (esimerkiksi suhteessa 60-40). Mainittakoon että data voitaisiin jakaa myös kolmeen eri settiin: opetus-, testi- ja validointidata. Joka tapauksessa, opetusdatan avulla muodostamme ennustemallin, käyttäen liiketoimintaongelmaan sopivaa analytiikka-algoritmia (esim. gradient boosting, neuroverkko, logistinen regressio, naive-bayes). Parhaan mallin löytäminen vaatii useita iteraatioita.

Työ vaatii analytiikkasoftan. Itse suosimme Pythonia ja R:ää, jotka sitten voivat pyöriä vaikkapa Azuren tai AWS:n pilvessä.

Muodostunutta ennustemallia testataan testidataa vasten. Koska testidata on historiadataa, tiedämme onko asiakas poistunut vai ei. Testin voisi ajatella siten, että peitämme tuon poistuma-tiedon ja kuvittelemme, että kyseessä olisi täysin uutta dataa. Annamme mallin tehdä ennusteen eli kertoa todennäköisyydet poistua kullekin asiakkaalle. Tämän jälkeen tarkastamme tuloksen ja arvioimme mallin tarkkuuden. Näin varmistamme toimiiko malli ja kannattaako sitä hyödyntää uutta dataa vasten vai pitääkö sitä parantaa.

Asiakaspoistuma-analyysin tulokset

Poistuma-analyysi tuottaa nipun tuloksia, esim.:

  1. Kaikki nykyiset asiakkaat listattuna poistumatodennäköisyyden mukaan
  2. Selittävät tekijät poistuman taustalla
  3. Ennustemallin hyvyyden kriteerit (AUC, Confusion matrix..)

asiakaspoistuma_tulos

Ensimmäinen tarkoittaa siis konkreettista listaa, jonka voit heittää myynti-/asiakaspalveluyksikölle tai soittokoneistolla ja käskeä kontaktoimaan heti aluksi akuuteimmat top 100 poistujaa.

Toinen tuotos eli selittävät tekijät antavat tulkinnan ilmiölle. Ne kertovat miksi asiakkaat poistuvat. Nämä tulokset on erittäin arvokasta tietoa niin asiakaspalvelulle, myynnille kuin tuotepäälliköille, liiketoiminnan kehittämiselle ylipäätään.

Analyysissä voi tulla esille, että hinta ei olekaan merkittävä tekijä poistuman taustalla vaan huono asiakaspalvelu tai tietylle asiakassegmentille sopimaton tuotepaletti (esim. sähköyhtiöltä puuttuu ekosähkö valikoimastaan). Riippuen valitusta menetelmästä, tulee eroja miten suoraviivaisesti näitä selittäviä tekijöitä voidaan tulkita. Esimerkiksi syvän neuroverkon (deep learning) tulkinta on huomattavasti monimutkaisempaa kuin logistisen regression antamisen tulosten.

Parhaimmassa tapauksessa analyysin tuotoksista voidaan generoida sääntökoneisto ja sisällyttää se esimerkiksi asiakaspalvelun työpöydälle tai CRM-järjestelmään. Säännöt voivat olla yksinkertaisuudessaan kertoimia ja IF-lauseita ja voidaan toteuttaa esimerkiksi SQL-komentoina. Analytiikan tulokset kirjoitetaankin usein takaisin joko operatiivisiin järjestelmiin tai tietovarastoon.

Kolmas tuotos kertoo, että miten tarkka ja hyvä malli on. Ei mennä tässä siihen matematiikkaan tarkemmin. Kannattaa vaan tietää, että siihen on suhteellisen objektiiviset keinot käytössä.

Analyysistä toimintaan

Analytiikan pitää johtaa toimintaan. Sen pitää tuottaa tulosta. Tämä erottaa sen perinteisemmästä raportoinnista ja business intelligencestä, jossa tuijotetaan enemmänkin raportteja ja taulukoita. Näytti käppyrät mitä tahansa, hommia jatketaan kuten ennenkin. Kunnes ollaan karilla tai kortistossa.

Poistuma-analyysissa toiminta tarkoittaa monta asiaa, esimerkiksi:

  1. kontaktoidaan poistumariskissä olevat asiakkaat
  2. pyritään pitämään heidät tai parhaimmassa tapauksessa tekemään lisämyyntiä
  3. kehitetään asiakaspalvelun laatua
  4. kehitetään tuotteita/palveluita vastaamaan paremmin kysyntää
  5. ennakoidaan liikevaihdon muutos kun tiedetään ennuste tulevasta poistumasta

Miksi yritys ei tee asiakaspoistuma-analyysiä?

Olemme tehneet vuosien varrella valtavan määrän eri analytiikan sovelluksia ja projekteja. Asiakaspoistuma-analyysi on antanut näistä todennäköisesti parhaimmat tulokset, varsinkin jos mitataan euroissa asiakkaiden saamaa hyötyä. Menetelmä on helppo ja suhteellisen nopea toteuttaa, se on helppo ymmärtää ja tulokset ovat käsin kosketeltavat.

Silti yllättävän harva yritys todella hyödyntää sitä. Syyt ovat moninaiset lähtien tietämättömyydestä aina itsepetokseen.

Surullisin on itseriittoisen sinnikäs toteamus, että ei meidän asiakkaat poistu muuta kuin manan majoille tai hinnan perässä, ne pihit penteleet.

Yrityksen tuotteessa ei ole kuulema mitään vikaa. Palvelu on priimaa ja markkinaosuus olisi 100% jos vain kilpailijat eivät myisi arvelluttavan halvalla sekundatuotteitaan. Jostain syystä liikevaihto kuitenkin mataa.

Uuden asiakkaan hankinta on aina kalliimpaa kuin vanhan pitäminen. Parhaimmassa tapauksessa tekemämme asiakaspoistuma-analyysin tuloksena kontaktoiduille asiakkaille saatiin myytyä aivan pöljänä lisää tavaraa. Asiakkaat eivät aina ole siis tyytymättömiä palveluun, he ovat vain herkkiä myynnille. Sinun kannattaa olla silloin ensimmäisenä paikalla.


 


22.08.2018 / Mika Laukkanen

Artikkelin kirjoittaja on Data Scientist Pekka Tiusanen Bilotilta, jonka kanssa Louhia yhdistyi kesäkuussa 2018.  Jatko-osa seuraa ensi viikolla.

ABOUT HIT RATE FORECASTING

Challenges in the sales process and management are common to many organizations. Improved data availability and machine learning algorithms provide means to forecast sales opportunity hit rates, which brings forth two interesting ML use cases. On the sales management level, keeping track of the sales funnel is essential and expected profit from the current sales pipeline is definitely of interest. On the contrary, individual salespersons have to be aware of critical price points in order to optimize profitability. Machine learning can answer such questions as “How much money do I currently have in the sales pipeline?” and “What price should I offer in this situation?”.

DATA ACQUISITION & MANIPULATION

The forecasting results will be only as good as your model and data. Opportunity hit rate is in the least to some extent dependent on price, lead type and margin. Hence, CRM attributes are worthwhile to consider in any hit rate engine. However, relevant information may reside in various data sources, such as ERP, IoT and social media. In large organizations, it is often most convenient to import all the forecasting attributes from an existing data warehousing architecture. Having finished the compilation stage, one may have to spend some time on joining tables and transforming data to form a comprehensive set of relevant features with good data quality.

1. The Process of Adopting a Hit Rate Engine

After the data has been cleaned, some data manipulation might still be required. For example, depending on the method and analysis platform, categorical features may have to be separately converted to dummy variables. In the modelling stage, each categorical feature forms as many binary variables as there are factor levels.

One may also want to combine classes within some of the features to achieve less specific categorizations. For instance, all the lead types that relate to marketing could be combined, leaving the rest of the lead types untouched. This type of considerations are ad hoc and they may improve or deteriorate forecasting performance depending on the chosen methodology and data.

Moreover, there is often a logical order to some of the categorical model features. Such ordinal features are converted into numeric form by applying the associated logical order. For example, a variable with values “satisfactory”, “better than satisfactory”, “good”, “very good” and “excellent” would naturally convert to a scale from 1 to 5.

For some features, it is important to find the optimal level of detail, often referred to as granularity in data warehousing jargon. This applies to, for instance, geographical location and organizational data. A good rule of thumb is that all the classes of each feature should have enough examples to justify inclusion. If only a few sales were recorded at a freshly opened sales office, including this sales office as a class in the training data probably displays an excessive level of detail. This type of a situation would allow two options: (1) either substitute “sales office” with a less specific feature, such as “sales region”, or (2) replace the values of offices having too few recorded sales with NAs.

Finally, it is often sensible or even necessary to derive new variables from the set of ML features extracted, transformed and loaded (ETL). For example, if margin is not provided, it can be calculated based on cost and price. It is also common to use some type of ratios as variables. One should also verify that the chosen statistical model is not sensitive to the number of variables or correlations between them. Truncating the number of features at some point depending on the purpose of your analysis and the chosen machine learning algorithm should be considered. It is sometimes useful to reduce dimensionality of the data by applying principle component analysis, for example.

PROPOSED METHODOLOGY

The gradient boosting algorithm is based on steepest descent and loss function minimization. The method first fits training set mean or some other rudimentary model to the target series which, in this case, consists of “won” or “lost”. A decision tree is fitted to the resulting error terms of this crude approximation. Another tree is fitted to the residuals of the first tree and iterations are continued until the chosen number of trees has been reached. Gradient boosting thus produces a forest which consists of individual trees. It makes sense to use regression tree based gradient boosting instead if your dependent variable is continuous. The process of fitting a gradient boosting model minimizes mean squared error analogous to loss function in mathematical terms.

The resulting statistical model is just an ensemble of trees generated based on your training data. The training series can be formed by taking a 70-80 % random sample of the total observations. Passing an individual opportunity to the forest-like model yields a hit rate forecast. One opportunity is just a row with the corresponding model feature values. The feature values of this particular opportunity determine the forecasting outcome of each tree. All the trees shift the resulting forecast up or down.

The forecasting model is tested against the validation set which typically comprises 20-30 % of total observations. Prediction accuracy can be determined by benchmarking the model with a confusion matrix. The matrix indicates how many lost (0) opportunities were correctly identified lost and, on the contrary, the number won (1) opportunities correctly forecasted.

Receiver operating characteristic (ROC) analysis is another way to benchmark classification models. The ROC curve displays the true positive rate (TPR) on the y-axis, whereas the false positive rate (FPR) is reflected on the x-axis. The true positive rate is the share of won opportunities correctly identified as such in the validation set. Furthermore, the false positive rate is for the proportion of lost opportunities incorrectly predicted won.

Estimated raw probabilities are used for classification scoring. The ROC curve illustrates how the TPR and FPR values behave as the classification threshold is changed. The intuition is that model performance improves in terms of detecting won opportunities along with a decline in the accuracy of catching lost opportunities as a consequence of shifting the threshold.

Possible overfitting of the model can be assessed by reviewing the ROC curves of training and validation sets. Any statistical model is overfitting if there is considerably more area under the curve in the training set compared to validation. Overfitting means that a statistical model is too specific so that it overestimates the associated predictive power. Complex statistical models are prone to overfitting. Hence, one should avoid using an excessive number of trees and tree depth as gradient boosting is employed.

2. Forecast Benchmarking

FROM FLASHCARDS TO TRULY DATA-DRIVEN SALES FUNNEL

Now that the hit rate engine is up and running, it is time to feed it some opportunity data! The model predicts the probability of acceptance for each individual opportunity fed to the algorithm, which allows better approximation of the sales funnel. The expected aggregate revenue can be estimated by multiplying predicted hit rates by the corresponding opportunity prices and summing up the results. Assuming that margin for each opportunity is known or derivable, it is possible to produce profitability estimates as well. The forecasting results can be integrated to the current BI reporting solution, which enables enhanced sales management and coordination.

3. Intelligent Sales Funnel

The gradient boosting method also allows extraction of the most relevant features predicting hit rate, which provides sales management with interesting insights. Hit rate drivers can be considered valuable from the product portfolio viewpoint too. However, some of these attributes are bound to be rather obvious — if price and margin are not listed among the most important hit rate features, your model may be misspecified.

Gradient boosting is a non-linear modeling procedure, so a direct two-way interpretation for factor contribution does not exist. Usually a combined feature importance metric is used because model attributes have three importance dimensions to them. Firstly, the “gain” metric is a volume-oriented forecast contribution statistic. On the contrary, “frequency” conveys how often features occur as tree splits within the model. Finally, the “cover” metric is for the relative number of opportunities associated with each particular feature. In case you are not satisfied with the combined metric nor individual components, it is also possible to visualize individual trees to truly understand the model dynamics.

SCENARIO-BASED PROFITABILITY MODELLING

The hit rate engine enables “what-if” analysis for individual opportunities, which allows the model to be deployed as a sales assistant. This ML implementation provides salespeople with a statistically justifiable estimate on how hit rate and profitability evolve as opportunity price is increased or decreased. More attributes for a salesperson to tinker with can be included as well.

4. Hit Rate Engine as a Sales Assistant

To fulfil the requirements set by the sales assistant use case, a range of prices has to be fed to the algorithm. The resulting impulse response is a range of hit rates. If the margin is included in the model, it has to be dynamically adjusted as price changes by using a suitable dependency function.

Hit Rate = Model(Price, Margin, Features1-N) + Ɛ

Now that we get the curve of hit rates out by dynamically changing price and margin, it is time to add profitability into the equation. This is fairly straightforward as we already have hit rate and margin calculated for each price level. The formula of expected profit includes probability of winning, corresponding price and margin at this price. This is obviously something that corporations want to maximize.

Expected Profit = Hit Rate * Opportunity Price * Margin

Forecasting accuracy increases along with the number of entered model input features assuming that the underlying statistical model has been produced according to best practices. The behaviour of hit rate and profitability with respect to price can be visualized and embedded as a sales assistant feature in a CRM or CPQ system. Of course, this requires proper usability design to ensure that the complexity of the underlying model is hidden from the salesperson. The model does not have to be trained constantly, so response time is not an issue.