Loppuvuodesta 2016 julkisuudessa keskusteltiin tiiviisti tekoälystä ja siitä, miten se muokkaa finanssisektorin palveluita ja ansaintaa. Keskustelussa nousi esiin kolme ennestään hyvin tuttua aluetta: 1. automaatioasteen kohottamisen kautta muodostuva parempi tehokkuus, 2. asiakaskokemuksen parannus sekä 3. uudet innovaatiot ja liiketoimintamahdollisuudet.  

Osuuspankilla tilanne tulkittiin niin, että tekoälyosaamisesta muodostuu toimintamme kannalta yhtä merkittävä asia kuin mobiiliosaamisesta vuonna 2011 ja designosaamisesta 2014. Asiaa lähettiin edistämään ripeästi mutta mielessä kaihersi miten epäkypsää ja liiketoimintaan mahdollisesti laaja-alaisesti vaikuttavaa aihealuetta pitäisi lähestyäPerinteisen visio/strategia/tiekartta muutosmatkan hitaus arveluttiValitsemamme uutosmatka onkin kiinnostanut lukuisia yrityksiä, avaan tässä artikkelissa ajatukseni muutosmatkan keskeisistä valinnoista ja samalla nitistää muutamia tekoälyyn liittyviä sitkeitä myyttejä.  

POC:t ja sitoutuminen 

Monet konsultit uskovat, että viiden viikon POC (Proof of Conseptratkaisun/konseptin todennus) pelastaa maailman. POC:n tavoitteena on arvioida yksittäisen käyttötapauksen potentiaali ja saada aikaan jonkinlaisia tuloksia. POC on vaikea toteuttaa hyvin koska tiiviissä aikataulussa toiminnallinen laajuus ja lähdedata ovat väkisinkin hyvin kapeita, että tulokset ehditään aidosti validoida. Tästä seuraa puolestaan se, että tulokset ovat usein tulkinnanvaraisia tai kehnoja. Viimeistään kuudennen tällaisen POC:n jälkeen mielenkiinto ja into kummasti laantuu. Tässä vaiheessa sitoutuminen testataan, pidetäänkö vuoden tauko ennen seuraavaa  POC:ia vai kokeillaanko edelleen. 

Kyvykkyys 

Pienen tekoälytiimin rekrytointi organisaatioon, jossa nykyinen osaaminen on ohutta, saattaahelposti viedä puoli vuotta. Liiketoiminnan käyttötapauksien tunnistaminen ei kuitenkaan voi odottaa kuukausia. Mielestäni liiketoiminnan käyttötapauksien oivaltaminen kannattaa aloittaa heti kun riittävä osaaminen on koottu sekä kumppaneilta että talon sisältä. Toisaalta pelipaikkojen tunnistamista ei tule ulkoistaa pelkästään konsulteille vaan mukana on oltava omasta organisaatiosta vähintään projektipäällikkö. Tämä etenemistapa vaatii tasapainoilua annettujen lupauksien lunastamisen ja oman kyvykkyyden kasvattamisessa, mutta sekin on parempi kuin puolivuotinen tiimin rekrytointiharjoitus, jota seuraa vielä puolivuotinen strategiatyö. 

Tavoite 

Tuleeko tekoälyvision, -strategian ja tiekartan olla kirkkaita ennen kuin toteutustyöhön lähdetään? Ennen visiota tai strategiaa on kerättävä kokemuksia. Ilman konkretiaa ja omakohtaista kokemusta tekoälykäsite on aivan liian abstrakti, että visiotyöstä saadaan suurtakaan hyötyä. Asian ympärille kannattaa perustaa projekti tai ohjelma, joka edistää asiaa siihen täysin keskittyen. Projektin ensikuukaudet kannattaa strategian jauhamisen sijaan käyttää käyttötapauksien tunnistamiseen ja kehitystyöhön. 

Käyttötapaukset ja pelipaikat 

Ihmiset ovat tottuneet hyödyntämään tietoa samalla tavoin 1990 luvulta lähtien ja tällaisesta dashboardajattelusta” poisoppiminen on tekoälyn käyttötapauksien tunnistamisen suurin haaste. Itse uskon että vuodessa kannattaa toteuttaa mieluummin viisikymmentä pienempää kuin viisi isompaa kokonaisuutta. Alkuun kannattaa hyväksyä, että lopputuotokset eivät ole tiiviisti integroituja tuotteita tai palveluita vaan kokeillessa pistemäisetkin ratkaisut ovat ok. Muutaman käyttötapauksen lähestymistavan suurin ongelma on riskienhallinta, käyttötapauksia pilkottaessa tunnistetaan usein tilanteita, jotka estävät koko käyttötapauksen tai sen osan toteuttamisen. Käyttötapauksissa tulee hakea liiketoiminnan haasteita – riskiä, tehokkuutta, asiakaskokemusta ja kasvua. Koko tekoälytekemiseltä on liian helppoa vetää matto alta, ellei portfoliossa ole arvoltaan selkeästi arvioitavissa olevia operatiivisen tehokkuuden käyttötapauksia.  

Rahoitus – liiketoiminta vai keskitetty? 

Mielestäni projektia on rahoitettava yhteisestä budjetista ainakin kaksi ensimmäistä vuotta. Hyötyjen logiikan arviointi on selkeää asiakasymmärrystä, kasvua ja riskienhallintaa parantavissa käyttötapauksissa. Hyötyjen euromääräinen kvantifiointi sen sijaan on vaikeaa. Kuinka paljon enemmän myymme jos ymmärrämme asiakasta paremmin, kuin paljon parempia palveluita kehitämme, jos ymmärrämme asiakastarpeita paremmin? Saammeko chatbotin vastaamaan asiakkaiden kysymyksiin viisi vai viisikymmentäprosenttisesti? Näihin kysymyksiin on vaikea vastata ja investointipäätökset jäävät tekemättä, jos rahoitus tulee yksiköistä tai eri liiketoiminnoista. Kahdessa vuodessa käyttötapauksien hyötyjen kokoluokka kirkastuu ja liiketoiminnot ja yksiköt rahoittavat tämän jälkeen ilomielin hyödylliset hankkeet.  

Omistaja 

Liiketoiminta vai IT – siinäpä pulma? Tekoälyn avulla on ratkaistava liiketoiminnan haasteita. Datojen saattaminen Data Scientistien saataville esimerkiksi neljään eri tekniseen alustaan on hullutta. Työssä on oltava mukana sekä liiketoiminnan käyttötapauksien oivallutuksen hallitsevat että teknisten ratkaisujen reunaehdot ymmärtävät osaajat. Ratkaistaanko kaikki ongelmat yhdessä? Ei, mutta tuoko tekoäly IT:n ja liiketoiminnan yhteenPitäisi tuoda. 

Työkalut ja teknologiat 

Itse uskon avoimen koodin välineisiin AWS:ään tai Azureen yhdistettynä. Tekoäly on laaja alue, jonka käyttötapauksien ääripäiden tekninen tarve vaihtelee huomattavan paljon. Teknisesti yksinkertainen tapaus on kerta-analyysi jonka Data Scientist voi hätätilanteessa toteuttaa vaikka omalla läppärillään. Teknisesti moniulotteinen puolestaan esimerkiksi propensiteettimalli, jonka tuloksia kysytään ruuhka-aikoina tuhansia kertoja sekunnissa. Kerta-analyyseissä painottuu mallinnusosaaminen ja teknisesti moniulotteisessa puolestaan ohjelmointiosaaminen. Näiden roolien yhdistäminen ei ole tyypillinen ensimmäisen vuoden ongelma, mutta se tulee huomioida tiimien osaamisten kehittämisessä. Etenkin alkumetreillä kannattaa harkita tarkkaan ’puolivalmisteiden’ kuten Databricks:n tarjoamia etuja, jotka saattavat nopeuttaa työtä kuukausilla 100% itse tekemiseen verrattuna. Alkuvaiheen kehitysinnossa Osuuspankkikin kehitti neljällä eri alustalla, mutta määrää oli pakko skaalata alas. Korkean volyymin tuotantojärjestelmien tuki useammalla alustalla sen sijaan vaatii huomattavan panostuksen, ainakin jos haluaa ettei Data Scienstistien arki täyty pelkästä tuesta.  

Data 

Ilman dataa ei ole tekoälyä. Älä aliarvioi dataan liittyvää kompleksisuutta ja laadun haasteita, kompleksisuus riippuu suuresti tietovarastojen määrästä ja sisällöstä. Jos tietovarastot koostuvat kolmesta SQL-palvelimesta, niiden sisällön migrointi esimerkiksi Snowflakeen ja ennustavan analytiikan tekemisen aloittaminen ei ole kovin monen viikon työ.  Jos tietovarastoja on kaksisataa tai suurin osa tiedosta on suoraan operatiivisissa järjestelmissä, datan siirto pilveendatan laadun tai masterdatan hallinta on jatkuva päänsärky. 

Muutosmatkaa on helppo katsoa taaksepäin mutta edes jälkikäteen oikeaa ratkaisua ei ole aina helppoa tunnistaa. Kokemukset kehittyvät nopeasti mutta tekoäly ilmiönä on vielä niin epäkypsä, että parhaiden käytäntöjen ja oikeiden ratkaisujen antaminen on melkoista käärmeöljykauppaa.  

Saavuttiko Osuuspankki tekoälyn avulla ensimmäisen kahden vuoden tavoitteitaan? Saavutimme, mutta eri alueiden hyödyt yllättivät meidät. Asiakasymmärrys ja kasvun hakeminen onnistui hienosti, riskienhallinnan hyödyt yllättivät positiivisesti, mutta operatiivisen tehokkuuden merkittävä parannus on ollut muutosmatkan suurin yllätys. 


Antti Myllymäki on työskennellyt suuren mittakaavan tietojen hyödyntämisen parissa kaksi vuosikymmentä. Ennen OP:ta esimerkiksi DeloittellaEficodella ja Samlinkillä antti.myllymaki(at)op.fi ja  https://www.linkedin.com/in/anttimyllymaki/