Tekoälystä perääntyminen: johtajien todellisia tarinoita
Tekoälyn opit: Monet johtajat sivuuttavat epäonnistuneista tai keskeytetyistä tekoälyhankkeista saatavat arvokkaat opit, vaikka ne tarjoavat ratkaisevan tärkeitä näkemyksiä.
Pysähdy ennen etenemistä: Yritykset hyötyvät usein tekoälyhankkeiden keskeyttämisestä, jotta perustavanlaatuiset prosessit ja datan laatu voidaan saada kuntoon.
Ensin manuaalisesti: Automatisoinnin tulisi tulla vasta manuaalisen toteutuksen jälkeen, jotta prosessit on määritelty selkeästi ja niiden toimintaperiaatteet ymmärretään.
Mittaa vaikutus: Menestyksen kannalta on olennaista arvioida nykyiset prosessit ja tekoälyn mahdolliset vaikutukset ennen käyttöönoton aloittamista.
Dokumentoinnin merkitys: Tehokkaassa dokumentaatiossa tulisi kuvata prosessien lisäksi myös päätösten perustelut ja poikkeukset.
Useimmat tekoälyn käyttöönottoa käsittelevät tarinat kerrotaan voittajien näkökulmasta. Harvempi johtaja puhuu hetkestä, jolloin he vetivät töpselin irti — perutusta automaatiosta, keskeytetystä käyttöönotosta tai pilotista, joka oli rakennettava kokonaan uudelleen. Juuri näissä tarinoissa piilevät kuitenkin usein todelliset opit.
Kysyimme kolmelta asiantuntijalta, jotka ovat käyneet tämän läpi: mikä purettiin, miksi ja mitä tekisit toisin? Heidän vastauksensa yhdistyvät yllättävän johdonmukaiseksi teemaksi — ongelma ei lähes koskaan ole itse tekoäly.
Kun viisain ratkaisu on pysähtyä eikä jatkaa eteenpäin
Useimmille organisaatioille tekoälyinvestoinnin täydellinen purkaminen ei ole realistista sen jälkeen, kun rahaa on jo käytetty. Deloitte Consultingin senior manager Tejinder sanoo suoraan, ettei kaiken poistaminen ollut jo tehtyjen investointien vuoksi vaihtoehto — mutta harkittu tauko oli. Kun tulokset eivät olleet riittävän hyviä, hänen tiiminsä astui askeleen taaksepäin ja “tarkasteli ensin perusasioita” kysyen, olivatko taustalla olevat prosessit vakiintuneita, oliko “datan laatu” “hyvä” ja ymmärsivätkö suunnittelijat agenttien ja oman roolinsa välisen eron. “Kun näihin kysymyksiin oli vastattu, uudelleenkäynnistys tuntui järkevältä”, hän sanoo.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Oregon State Universityn osaamisen kehittämisestä vastaava johtaja ja oppimisprosessin omistaja, tohtori Priyanka Dave, on nähnyt saman kaavan toistuvan yhä uudelleen. “Olen havainnut useiden organisaatioiden viivästyttävän tarkoituksellisesti tekoälyhankkeiden laajentamista sen jälkeen, kun ne ovat tunnistaneet, etteivät ne olleet toiminnallisesti valmiita.” Näissä tapauksissa vetäytyminen ei ollut epäonnistuminen — se oli suunnanmuutos. “Sen sijaan, että johto olisi laajentanut tekoälyn käyttöä välittömästi, se keskitti huomionsa organisaation perustan vahvistamiseen”, Dave selittää. Tämä tarkoitti sitä, että “organisaatiot investoivat liiketoimintaprosessien dokumentointiin, työnkulkujen standardointiin, datan hallinnan parantamiseen sekä henkilöstön valmiuksien kehittämiseen jäsennellyn oppimisen ja muutosjohtamisen avulla.”
Sen sijaan, että johto olisi laajentanut tekoälyn käyttöä välittömästi, se keskitti huomionsa organisaation perustan vahvistamiseen.
Älä automatisoi sitä, mitä et ole tehnyt manuaalisesti
Joskus taaksepäin ottaminen tarkoittaa projektin suoraa perumista — ja sen oivaltamista, että se oli koko ajan oikea ratkaisu. Swift Ops Solutionsin perustaja ja pääkonsultti Jaime Gil Martinez oppi tämän kantapään kautta. “Rakensin kerran automaation tuottamaan markkinointimateriaalia asiakkaalle, joka ei ollut koskaan toteuttanut prosessia manuaalisesti”, hän muistelee. “Koska prosessi oli heille uusi, ajattelimme molemmat, että se olisi parempi rakentaa alusta alkaen automatisoituna. Paperilla se vaikutti järkevältä. Jälkikäteen ajatellen se oli aloittelijan virhe.”
Järjestelmä toimi teknisesti. “Automaatio toimi”, Gil Martinez sanoo. “Ongelma oli siinä, että aina kun tarvittiin uusi tulos, jotain täytyi harkita uudelleen tai säätää (eri kohderyhmä, eri muoto, eri asettelu), joten rakensin sen jatkuvasti uudelleen. Muutaman tällaisen kierroksen jälkeen kaava oli ilmeinen – automatisoin prosessia, jota kukaan ei ollut vielä määritellyt.”
Muutaman [säätökierroksen] jälkeen oli ilmeistä, että automatisoin prosessia, jota kukaan ei ollut vielä määritellyt.
Ratkaisu oli palata taaksepäin. “Joten peruutimme projektin kokonaan ja palasimme tuottamaan materiaalit käsin”, hän sanoo. “Se osoittautui koko asian tarkoitukseksi: jokainen manuaalinen kierros antoi meille sen, mikä oli puuttunut, eli kultaisen standardin mukaisia esimerkkejä ja selkeän kuvan siitä, mikä vaihteli ja mikä ei. Jatkoimme automaatiota myöhemmin, ja manuaalisesta tuotoksesta tuli tietopohja, jonka annoimme tekoälyn käyttöön.” Kokemus synnytti säännön, jota hän soveltaa nykyään omassa yrityksessään ja asiakkaidensa kanssa: “älä automatisoi mitään, ennen kuin olet tehnyt sen manuaalisesti vähintään kolme kertaa. Sen jälkeen voit alkaa harkita automaatiota.”
Vaihe, jonka kaikki ohittavat: mittaa ennen rakentamista
Kysy Gil Martinezilta, mitä useimmista tekoälyn käyttöönoton suunnitelmista puuttuu, ja hänen vastauksensa tulee heti: ”Mittaaminen ennen rakentamista. Useimmilta yrityksiltä puuttuu aloitushetkellä kaksi lukua: kuinka hyvä tai huono niiden nykyinen prosessi todellisuudessa on ja millaisen vaikutuksen tekoäly voisi siihen realistisesti saada aikaan. Ilman molempia et voi tietää, kuinka tehokas toteutuksesi oli tai olivatko kustannukset perusteltuja.”
Hän viittaa terveydenhuollon klinikkaan, joka halusi automatisoida ajanvarauksen yli 100 potilaalle. ”He eivät tienneet, kuinka kauan siihen kului aikaa, vaan ainoastaan sen, että se oli aikaa vievää ja turhauttavaa”, hän kertoo. ”Ja jos et tiedä, kuinka kauan johonkin kuluu aikaa, et tiedä, kuinka paljon se maksaa sinulle.” Ennen minkään rakentamista hänen ensimmäinen askeleensa olikin laskea ajanvaraukseen kuluneet työtunnit ja niiden rahallinen arvo. ”Se antoi meille lähtötason: kahden viikon edestä täysin manuaalista työtä. Automaatio lyhensi ajan yhteen päivään tekoälyn avustamaa työtä, ja kustannus oli pienempi kuin heidän nykyinen vastaava kulunsa.” Kun nämä luvut olivat käsillä, ”päätös syntyi itsestään.”
Dave näkee toisen, mutta yhtä kriittisen puutteen: valmius ei liity vain teknologiaan. ”Useimmiten näen organisaatioiden laiminlyövän henkilöstön valmiuksien arvioinnin ennen tekoälyn käyttöönottoa”, hän sanoo. Puutteet eivät myöskään yleensä liity työkalujen käyttöön perehdyttämiseen. Useissa valmiusarvioinneissa ”arvioinnit paljastivat johdonmukaisesti, että suurimmat valmiuspuutteet liittyivät analyyttiseen ajatteluun, kriittiseen ajatteluun, datalukutaitoon, konsultatiiviseen viestintään ja ongelmanratkaisuun.” Hänen johtopäätöksensä on: ”Teknologinen valmius ja henkilöstön valmius ovat eri haasteita. Kestävä tekoälyn käyttöönotto edellyttää molempia.”
Mitä tapahtuu, kun tekoäly otetaan käyttöön prosessissa, joka ei ole valmis
Mikä oikeastaan hajoaa, kun tekoälyä aletaan käyttää epäkypsässä prosessissa? Tejinder näki tämän läheltä, kun ”tekoäly upotettiin liiketoimintaprosessiin (tilausten käsittelyyn ja allokointiin), joka ei ollut riittävän kypsä” — tuloksena oli ratkaisu, joka oli täynnä virheitä. Hän kuitenkin korostaa selkeästi, missä vika oli: ”En usko, että tekoäly oli tässä ongelma”, hän sanoo ja viittaa sen sijaan prosessin kypsyyteen, perustietojen ongelmiin, sulkemattomiin vaatimuspuutteisiin ja riittämättömään testaukseen.
Tekoäly upotettiin liiketoimintaprosessiin (tilausten käsittelyyn ja allokointiin), joka ei ollut riittävän kypsä.
Dave kuvailee samaa ilmiötä arviointiensa pohjalta: eri osastot tekevät saman työn eri tavoin, dokumentaatio on puutteellista ja poikkeukset elävät vain työntekijöiden mielissä. ”Huolena oli, että tekoäly yksinkertaisesti toistaisi epäjohdonmukaiset käytännöt koko organisaatiossa”, hän sanoo. Kyse on seurauksesta periaatteelle, johon hän palaa usein: ”Tekoäly ei ratkaise organisaatioiden ongelmia. Se vahvistaa olemassa olevia järjestelmiä. Jos prosessit ovat epäjohdonmukaisia tai huonosti dokumentoituja, tekoäly usein laajentaa näitä epäjohdonmukaisuuksia sen sijaan, että parantaisi niitä.” Hänen sanoinensa johtopäätös on: ”Toistuva opetus oli, että organisaatioiden tulisi parantaa prosessejaan ennen kuin ne yrittävät automatisoida niitä.”
Jos prosessit ovat epäjohdonmukaisia tai huonosti dokumentoituja, tekoäly usein laajentaa näitä epäjohdonmukaisuuksia sen sijaan, että parantaisi niitä.
Gil Martinezilla on tästä omakohtaista kokemusta — liidien generointisovellus, joka ”epäonnistui ensimmäisellä kerralla täysin”. Rakentamisessa siirryttiin puolimanuaalisesta täysin automatisoituun ratkaisuun ilman määriteltyjä vaatimuksia tai testejä. ”Virheeni oli olettaa, että tekoäly selvittäisi osan logiikasta itse, koska logiikka vaikutti ilmeiseltä ja yksinkertaiselta”, hän myöntää. Tilanne paheni siitä. ”Koodista tuli hallitsematonta, ja tekoäly omisti sen kokonaan siinä määrin, etten voinut palata turvalliseen välivaiheeseen. Silloin tiesin, että rakenne oli rikki, eikä kyse ollut vain virheistä.”
Toipuminen edellytti täydellistä uudelleenkäynnistystä. ”Korjaus oli yhtä tuskallinen kuin ilmeinenkin: aloita alusta”, hän sanoo. ”Tällä kertaa hahmottelin jokaisen vaatimuksen ja sitä vastaavan testin, rakensin ratkaisua vaiheittain ja annoin tekoälylle selkeät ohjeet epäonnistumisten ja onnistumisten kirjaamiseen asianmukaisen versionhallinnan ohella.” Kurinalainen toinen yritys ”vei suunnilleen puolet siitä ajasta, jonka olin tuhlannut ensimmäiseen yritykseen, ennen kuin saavutin toimivan, tuotantotasoisen ratkaisun.”
Miltä hyvä tekoälyä koskeva dokumentaatio todellisuudessa näyttää
Kaikkien kolmen tarinan taustalla on sama ratkaisu: dokumentaatio, joka kuvaa, miten työ todella tehdään. Davelle se tarkoittaa tehtäväluetteloita pidemmälle menemistä. ”Hyvä prosessidokumentaatio selittää paitsi sen, mitä ihmiset tekevät, myös sen, miksi he tekevät tiettyjä päätöksiä”, hän sanoo. Arvokkain aineisto onkin yleensä se, mitä ei koskaan kirjoiteta muistiin. ”Yksi yleisimmistä virheistä, joita organisaatiot tekevät, on vain vakiotyönkulun dokumentointi. Suurin osa organisaation tiedosta on usein poikkeuksissa, harkintaa vaativissa ratkaisuissa ja asiayhteyteen liittyvissä päätöksissä, joita kokeneet työntekijät tekevät.”
Gil Martinez tarkastelee asiaa näkökulmasta, jonka projektipäälliköt tunnistavat yhä useammin: ”Hyvä prosessidokumentaatio heijastelee kehotteiden suunnittelua. Samojen elementtien, jotka opimme antamaan tekoälylle kehotteessa (rooli, konteksti, tehtävä, ohjeet, rajoitteet), tulisi näkyä projektitasolla.” Tämä muutos vaikuttaa siihen, miten ammattilaiset käyttävät aikaansa. ”Ihmisten suorittamiseen käyttämä aika katoaa, kun tehtävät siirretään tekoälyn hoidettaviksi, joten meidän on keskityttävä hyvään suunnitteluun ja tuotosten validointiin. Meidän on toimittava kuin tekoälyn hallinnoijat.”
Yhteenveto: järjestys on strategia
Yksikään näistä johtajista ei kadu tekoälyyn investoimista. He katuvat – tai ovat nähneet muiden katuvan – toimenpiteiden järjestystä. Tejinder tiivistää asian näin: ”Yritysten tekoälyn käyttöönotto epäonnistuu, kun malli otetaan käyttöön ennen toiminnan perustekijöitä. Oikea järjestys on ensin prosessien kypsyys, datan laatu ja roolien selkeys. Tekoäly vasta sen jälkeen. Kun organisaatiot kääntävät tämän järjestyksen päinvastaiseksi, ne syyttävät tekoälyä, vaikka taustalla oleva ongelma on lähes aina ympäristö, johon tekoäly tuotiin.” Kävi ilmi, että jälkikäteen korjaaminen ei olekaan epäonnistuminen. Käyttöönotto ennen valmiutta on.
Haluatko lisää tällaisia näkemyksiä? Rekisteröidy maksuttomalle DPM-tilille kuullaksesi lisää näiltä asiantuntijoilta.
