Miksi useimmat pienten organisaatioiden tekoälykokeilut epäonnistuvat, ja kolme ehtoa jotka pelastavat ne

Pieni organisaatio pyörittää tekoälykokeilua. Joku esittelee chatbotin, joka vastaa henkilöstökäsikirjaa koskeviin kysymyksiin. Kaikki nyökyttelevät. Pöytäkirjaan kirjataan "onnistunut pilotti". Kolme kuukautta myöhemmin sitä ei käytä enää kukaan, ja puhe on hiljaa siirtynyt siihen, että "ehkä meidän pitäisi paneutua tekoälyyn kunnolla ensi vuonna".

Olen nähnyt tämän tapahtuvan, ja olen myös itse aiheuttanut sen. Vedin parin vuoden ajan tekoälyn käyttöönottoa eräässä suomalaisessa nuorisojärjestössä, ja epäonnistumiset opettivat minulle enemmän kuin onnistumiset. Sitä ei sano ääneen kukaan, että syy epäonnistumiseen ei juuri koskaan ole tekninen. Malli toimi. Integraatio toimi. Demo toimi. Pilotti kuoli silti, koska kyse oli siitä, miten työ oli järjestetty, ei siitä, mihin työkalu pystyi.

Jos pyörität pientä organisaatiota, järjestöä, alueellista tiimiä tai säätiötä, tässä piilee ansa. Luulet tekeväsi teknologiakoetta. Todellisuudessa teet organisaatiokoetta, ja arvioit sitä väärällä mittarilla.

Demoansa: miksi toimiva pilotti silti kuolee

Tässä on kaava, ja kun sen kerran näkee, sitä ei voi enää olla näkemättä.

Valitset pilotille tehtävän. Valitset sen siksi, että se on turvallinen. Mikään ei mene rikki, vaikka tekoäly menisi siinä metsään. Käsikirjabotti on klassinen esimerkki: matalat panokset, helppo esitellä, kukaan ei ole siitä riippuvainen. Niinpä rakennat sen, se toimii, kaikki ovat vaikuttuneita, ja sitten se kuolee, koska juuri se mikä teki siitä turvallisen pilotin tekee siitä myös helposti unohdettavan. Kenenkään päivä ei helpottunut. Yksikään deadline ei tullut nopeammin täytetyksi. Se ei poistanut mitään kipua, joten siitä ei synny tapaa.

Kutsun tätä demoansaksi. Pilotti on viritetty näyttämään hyvältä kokouksessa, ei selviämään tavallisesta tiistaista. Ja nämä kaksi ovat melkein toistensa vastakohtia. Työkalu, joka oikeasti muuttaa jonkun työtapaa, näyttää demossa vähän kömpelöltä, koska se on kytketty todelliseen sotkuun: oikeaan dataan, oikeisiin reunatapauksiin, siihen kollegaan joka tekee kaiken vähän eri tavalla. Siisti demo on varoitusmerkki, ei vihreä valo.

Tämä toistuu siksi, että pienet organisaatiot kohtelevat pilottia riskin pienentämisenä. Totta kai kohtelevat. Budjetti on tiukalla, aika vielä tiukemmalla, eikä kukaan halua olla se ihminen joka rikkoi lahjoittajarekisterin chatbotilla. Niinpä riskiä karsitaan valitsemalla jotain merkityksetöntä. Ja sitten ihmetellään, ettei sillä merkityksettömällä ollutkaan mitään merkitystä.

Pilotit kaatuvat organisaatioon, eivät tekniikkaan

Sanon nyt täsmällisesti, millä kolmella tavalla nämä jutut oikeasti kuolevat, koska "organisatoriset syyt" on juuri sellainen epämääräinen fraasi, jonka tavallisesti kehottaisin poistamaan.

Tehtävällä ei ollut panoksia. Kukaan ei tuntenut helpotusta, kun se toimi. Helpotus on merkki siitä, että valitsit oikean ongelman. Jos pilotin loppuminen ei muuta mitään kenenkään työtaakassa, se oli teatteria.

Pilotilla ei ollut omistajaa. Se kuului "tiimille", mikä tarkoittaa, ettei se kuulunut kenellekään. Kun uutuudenviehätys haihtui, ei ollut yhtään ihmistä jonka työ olisi vaikeutunut sen lakatessa toimimasta, joten se vain lakkasi toimimasta, eikä kukaan huomannut mitään viikkokausiin.

Se eli työn vieressä, ei sen sisällä. Työkalu oli erillinen sivusto, erillinen kirjautuminen, erillinen välilehti, joka piti muistaa avata. Jokainen erillinen asia on vero tarkkaavaisuudelle, ja pienessä organisaatiossa tarkkaavaisuus on kaikkein niukin resurssi. Ihmiset eivät kierrä huonoa työkalua. He kiertävät ylimääräisen vaiheen.

Huomaa, ettei mikään näistä koske mallia. Loistava malli voi kaatua kaikkiin kolmeen, ja keskinkertainen malli voi pärjätä kaikissa kolmessa. Organisaation ehdot ratkaisevat. Juuri tämän alan kokeneet osaajat ymmärtävät väärin neuvoessaan pieniä organisaatioita: he vatvovat mallivalintaa ja suorituskykyä, vaikka todellinen vaihtelu piilee työn rakenteessa ja omistajuudessa.

Kolme ehtoa, jotka saavat tekoälyn käyttöönoton pysymään

Tässä on siis ajatusmalli, jota nykyään käytän ennen kuin annan vihreää valoa millekään. Kolme ehtoa. Jos ehdotettu pilotti ei täytä kaikkia kolmea, en pyöritä sitä, koska tiedän jo miten siinä käy.

1. Aitoja panoksia, tarkoituksella

Valitse tehtävä, jossa virheellä on hintansa ja nopeudella palkkionsa. Ei katastrofaalista hintaa, ethän pane tekoälyä päättämään lastensuojelusta ensimmäisenä päivänä, vaan aito. Tehtävä, jota joku juuri nyt inhoaa. Jono joka ei tyhjene koskaan. Se ärsyttävä toistuva juttu, joka syö yhden aamun joka viikko.

Varovaiselle organisaatiolle tämä tuntuu nurinkuriselta. Haluat aloittaa turvallisesti. Mutta turvallinen tarkoittaa panoksetonta, ja panokseton tarkoittaa helposti unohtuvaa. Oikea siirto on aloittaa pienestä ja aidosta, ei suuresta ja valheellisesta. Kahden tunnin viikkotehtävä, joka oikeasti kutistuu kahteenkymmeneen minuuttiin, kerää enemmän vauhtia kuin hiotuin käsikirjabotti minkä voit kuvitella, koska joku saa tiistai-iltapäivänsä takaisin ja puolustaa sitä työkalua henkeen ja vereen.

2. Yksi nimetty omistaja

Ei komiteaa. Ei "digitaalista työryhmää". Yksi ihminen, jonka nimi on kirjattu ylös ja joka vastaa siitä, elääkö vai kuoleeko tämä työkalu. Mieluiten ihminen, joka tuntee tehtävän kivun tänään, koska hänellä on omaa nahkaa pelissä ja hän huomaa sen hetken, jolloin työkalu lakkaa auttamasta.

Omistajan tehtävä ei ole olla kehittäjä. Hänen tehtävänsä on välittää. Hän virittää kehotteet, hän nappaa huonot tulosteet, hän kertoo sinulle, kun todellisuus on erkaantunut siitä mitä työkalu olettaa. Käyttöönotto on suhde, ja suhteet tarvitsevat jonkun, joka kantaa niistä vastuun. Työkalu ilman omistajaa on orpo, ja orvot hylätään hiljaa.

3. Työn sisällä, ei sen vieressä

Työkalun on elettävä siellä missä työ jo tapahtuu. Jos tiimisi elää sähköpostissa, tekoälyn tuotoksen pitää saapua sähköpostiin. Jos he elävät taulukossa, sen pitää kirjoittaa taulukkoon. Jokainen uusi välilehti, uusi kirjautuminen, jokainen "muista käydä tarkistamassa se juttu" on kitkaa, ja kitka kasaantuu kunnes työkalu on kuollut.

Tähän ehtoon ihmiset panostavat vähiten, koska se on vähiten näyttävä ja eniten näpertelyä vaativa. Mallin kytkeminen olemassa olevaan virtaan on epäseksikästä putkityötä. Mutta juuri se putkityö ratkaisee, tuleeko jutusta tapa vai kuriositeetti.

Esimerkki käytännöstä: avustusraportoinnin pilotti joka jäi käyttöön

Tässä yksi joka selvisi hengissä, ja miksi.

Pyöritimme monivuotista valtionavustusprosessia, mikä tarkoittaa selkokielellä tasaista raportointivelvoitteiden virtaa: väliraportteja, indikaattoritaulukoita, samoja kysymyksiä hieman eri muodoissa rahoittajien ja vuosien välillä. Luonnostelu oli puurtamista, ja mikä pahempaa, se oli juuri sellaista puurtamista joka söi sen ihmisen aikaa, jolla oli siihen vähiten varaa.

Kolmea ehtoa vasten:

• Aitoja panoksia. Raporteilla on deadlinet ja niihin liittyy rahaa. Myöhästyneellä tai heikolla raportoinnilla on todellinen hinta. Nopeammalla ja siistimmällä luonnostelulla oli ilmeinen palkkio, ja sitä tekevä ihminen inhosi tehtävää, mikä on juuri sitä inhoa jota etsit.
• Nimetty omistaja. Sen omisti se ihminen joka oikeasti kirjoitti raportit, ei "tiimi". Hän piti kehotekirjastoa hallussaan, hän päätti miltä hyvä tuotos näyttää, ja hänellä oli kaikki syy pitää se hengissä, koska kyse oli hänen iltapäivästään.
• Työn sisällä. Luonnostelu tapahtui niissä dokumenteissa ja muodoissa joita jo käytimme, syöttäen niihin rakenteisiin joita rahoittajat jo odottivat. Ei erillistä tekoälyportaalia muistettavaksi. Malli teki toistuvan rungon, indikaattoritaulukot, ristiinviittaukset, muotoilun, kun taas ihminen piti hallussaan sen strategisen kerronnan joka oikeasti voittaa rahoituksen.

Se jäi käyttöön koska kaikki kolme ehtoa pitivät yhtä aikaa. Ja kontrasti käsikirjabotin kaltaiseen pilottiin on koko pointti: sama organisaatio, samat ihmiset, sama yleinen kyvykkyys. Ero oli kokonaan siinä, miten työ oli järjestetty työkalun ympärille.

Kompromissit ja virhetilat

En aio teeskennellä että tämä malli olisi ilmainen. Sillä on hintansa, ja sinun kannattaa lähteä liikkeelle ne tiedostaen.

Aidon panoksen tehtävän valitseminen tarkoittaa, että ensimmäiset epäonnistumiset näkyvät. Kun työkalu mokaa jotain tehtävässä jolla on väliä, ihmiset huomaavat, ja se on epämukavaa tavalla jollainen käsikirjabotti ei koskaan ollut. Tarvitset inhimillisen tarkistuspisteen juuri siksi että panokset ovat aitoja. Vastaus korkeampiin panoksiin ei ole matalammat panokset, vaan tiukempi tarkistus tuotokselle ja ihminen jolla on viimeinen sana.

Yhden omistajan mallilla on oma riskinsä: bussikerroin. Jos ainoa omistajasi lähtee, ja pienissä organisaatioissa ihmiset kantavat montaa hattua ja vaihtavat maisemaa, työkalu voi kuolla hänen mukanaan. Tätä hallitset kirjaamalla ylös sen mitä omistaja tietää, kehotteet, sudenkuopat, tilanteet joissa työkalu hiljaa valehtelee, jotta tieto elää ihmistä pidempään. Omistajuuden pitäisi olla rooli, ei panttivankitilanne.

Ja kaikkein pahin virhetila, se jonka haluan jäävän mieleesi: uskottava demo. Hiottu pilotti joka ei täytä yhtäkään kolmesta ehdosta mutta näyttää upealta hallituksen edessä. Se on vaarallisin lopputulos, vaarallisempi kuin rehellinen epäonnistuminen, koska se ruokkii väärää itsevarmuutta. Organisaatio päättelee että tekoäly toimii heillä, panostaa sellaisen jutun varaan joka ei koskaan ollut selviämässä todellisesta työkuormasta, ja polttaa sitten hyvän tahdon kun oikea käyttöönotto juuttuu. Rehellinen epäonnistuminen opettaa jotain. Imarteleva demo opettaa väärän asian ja laskuttaa oppitunnista vasta myöhemmin.

Mitä tehdä ennen seuraavaa pilottiasi

Ennen kuin annat vihreää valoa millekään, käy se kolmea ehtoa vasten ääneen, samassa huoneessa, nimet kiinnitettyinä. Onko tällä tehtävällä aitoja panoksia jotka joku tuntee? Kuka, nimeltä, vastaa siitä elääkö se? Eläkö se työn sisällä vai sen vieressä? Jos et osaa vastata kaikkiin kolmeen siististi, sinulla ei ole pilottia. Sinulla on demo joka odottaa pettävänsä sinut.

Skaalautuminen lepää järjestelmien varassa, ei hyvän tahdon, ja sama pätee käyttöönottoon. Työkalut eivät koskaan olleet se vaikea osa. Vaikea osa on olla rehellinen sen suhteen, oletko rakentanut jotain mitä todellinen tiistai oikeasti käyttää.