Miksi tekoälypilotit epäonnistuvat — ja mitä toimivissa tehdään toisin

Lyhyt vastaus

Tekoälypilotit epäonnistuvat harvoin teknisistä syistä. Yleisimmät syyt ovat: pilotiksi valitaan näyttävä mutta harvinainen käyttötapaus toistuvan sijaan, onnistumista ei määritellä mitattavana lukuna etukäteen, automaatiolla ei ole nimettyä omistajaa organisaation sisällä, ja pilotti rakennetaan erilliseen ympäristöön josta sitä ei koskaan siirretä tuotantoon.

Tekoälypilotteja on tehty Suomessa nyt muutaman vuoden. Suurin osa niistä ei ole tuotannossa. Julkisuudessa on siteerattu tutkimusarvioita, joiden mukaan jopa yhdeksän kymmenestä yritysten tekoälykokeilusta ei tuota mitattavaa hyötyä. Tarkka luku vaihtelee tutkimuksesta toiseen, mutta suuruusluokka on kaikissa sama.

Kiinnostavampi kuin luku on syy. Kun epäonnistuneita pilotteja katsoo jälkikäteen, tekniikka toimi lähes aina. Kaaduttiin muualla.

1. Pilotiksi valittiin näyttävä, ei toistuva

Tämä on ylivoimaisesti yleisin. Pilotiksi valitaan asia, joka näyttää hyvältä johtoryhmän kalvolla: tarjouslaskennan tekoälyavustaja, chatbot asiakkaille, ennustemalli. Ne ovat vaikeita ongelmia ja tulevat vastaan harvoin.

Toimiva pilotti valitaan päinvastoin: mikä on tylsin asia, jota tehdään useimmin? Talotekniikan yrityksessä se on melkein poikkeuksetta jokin näistä:

materiaalien hintavertailu ja tilaaminen
tarjouspyyntöjen lähettäminen alihankkijoille ja vastausten vertailu
ostolaskujen kierrätys ja litterointi
saman tiedon näppäileminen kahteen järjestelmään

Näissä on volyymia, ne noudattavat sääntöjä ja säästö on laskettavissa etukäteen. Ne ovat myös niin tylsiä, ettei kukaan puolusta niiden säilyttämistä käsityönä.

2. Onnistumista ei määritelty numerona ennen aloitusta

”Katsotaan mitä tästä saadaan” on tapa, jolla pilotti hiipuu ilman että kukaan joutuu myöntämään sitä. Ilman etukäteen sovittua lukua tulos on aina tulkinnanvarainen, eikä tulkinnanvarainen tulos johda koskaan päätökseen laajentaa.

Kirjatkaa ennen rakentamista kolme lukua: montako tuntia tähän kuluu nyt, montako tuntia siihen saa kulua jatkossa ja mihin päivämäärään mennessä. Kaikki kolme mahtuvat yhdelle riville sähköpostissa.

3. Automaatiolla ei ollut omistajaa

Automaatio, jolla ei ole omistajaa, lakkaa toimimasta. Ei heti — se pyörii kuukausia. Sitten toimittaja muuttaa hinnaston muotoa, ERP päivittyy tai joku vaihtaa sähköpostikansion nimeä, ja automaatio menee hiljaa rikki. Kukaan ei korjaa sitä, koska kukaan ei ollut siitä vastuussa. Parin viikon päästä työ tehdään taas käsin.

Siksi nimeämme AI-championit ennen kuin rakennamme mitään. Champion on tavallinen työntekijä — usein työnjohtaja tai toimistopäällikkö — joka tuntee prosessin ja saa valmennuksen sen ylläpitoon. Ei IT-osasto, koska IT ei tunne prosessia. Eikä konsultti, koska konsultti lähtee.

4. Pilotti rakennettiin väärään paikkaan

Erillinen ”pilottiympäristö” houkuttaa, koska se tuntuu turvalliselta. Se on myös syy siihen, ettei pilotti koskaan siirry tuotantoon: siirto on oma projektinsa, sille pitää saada oma budjetti, ja siinä vaiheessa innostus on jo laantunut.

Rakentakaa siihen ympäristöön, jossa työ oikeasti tehdään, ja rajatkaa riski käyttöoikeuksilla ja hyväksyntävaiheilla — ei erillisellä hiekkalaatikolla. Ensimmäisessä versiossa ihminen saa hyvin hyväksyä jokaisen toimenpiteen ennen suoritusta. Hyväksyntä poistetaan vasta kun luottamus on ansaittu.

Mitä toimivissa tehdään toisin

Neljä asiaa:

Valitaan toistuva ja tylsä, ei näyttävä ja harvinainen.
Kirjataan tavoiteluku ja päivämäärä ennen ensimmäistä riviä.
Nimetään omistaja talon sisältä ja valmennetaan hänet ennen luovutusta.
Rakennetaan tuotantoon hyväksyntävaiheiden kanssa, ei erilliseen hiekkalaatikkoon.

Mikään näistä ei ole teknologiakysymys. Se on hyvä uutinen: näihin te pystytte vaikuttamaan itse riippumatta siitä, kenen kanssa työn teette.