Miksi tekoäly nopeuttaa yksittäisiä tehtäviä mutta ei asiantuntijaorganisaatiota

Tehtävä nopeutuu, prosessi ei

Asiantuntijaprosessissa yksittäisen vaiheen suorittamiseen kuluva aika on harvoin pullonkaula. Pullonkaula on kaikki se, mikä on vaiheiden välissä: odotus, että joku ehtii katsoa. Kontekstin vaihto, kun tekijä palaa asiaan kolmen päivän päästä. Tarkistuskierros, joka odottaa palaverin. Tiedon siirto ihmiseltä toiselle, ja se pieni hävikki, jonka jokainen siirto tuottaa. Kun nopeutat yhden vaiheen tekemistä mutta jätät ketjun ennalleen, kokonaisuus ei liiku. Kymmenen tuntia kirjoitustyötä muuttuu kahdeksi, mutta jos sen ympärillä on kolme viikkoa odotusta ja kolme katselmointikierrosta, läpimenoaika lyhenee muutaman prosentin. Ja tehtäviä unohtuu. Projektipäälliköllä ei ole kaikkea hallussaan, koska kokonaisuutta ei näe mistään yhdestä paikasta. Tämä ei korjaannu sillä, että yksittäinen vaihe tehdään nopeammin. Vaihe, joka ei ollut kenenkään muistissa, ei nopeudu. Se puuttuu. Toinen asia näkyy vasta mittakaavassa. Kun samaa työtä tekee kymmenen asiantuntijaa, jokaisella on omat promptinsa. Prompteja toki jaetaan, ja se on hyvä tapa, mutta se ei ratkaise ongelmaa. Jokainen on ladannut oman keskustelunsa kontekstin itse: eri taustatiedot, eri esimerkit, eri painotukset. Sama prompti eri kontekstissa tuottaa eri lopputuloksen. Hajonta ei siis synny siitä, että joku promptaa huonommin kuin muut. Se syntyy siitä, että kymmenen ihmistä tekee kymmentä eri prosessia, jotka näyttävät ulospäin samalta. Tästä seuraa koko kysymyksen ydin. Prosessin pitää olla koko yksikön prosessi, ei kymmenen ihmisen kymmenen tapaa. Niin kauan kuin se asuu henkilön päässä ja henkilön chat-ikkunassa, se ei ole yksikön prosessi, vaikka kaikki tekisivät sitä samalla nimellä ja samalla työkalulla. Tämä on syytä myöntää suoraan: yksilön promptaus toimii. Se vain toimii väärällä tasolla. Se optimoi sitä osaa työstä, joka ei ollut pullonkaula.

Kolme syytä, miksi hyöty ei kumuloidu

Hyötyä ei voi laskea yhteen

Kun jokaisen nopeutuminen tapahtuu eri tavalla, organisaatiolla ei ole kymmenen prosenttia parempaa prosessia. Sillä on kolmesataa erilaista tapaa tehdä sama työ, joista osa on nyt nopeampia. Laatu asuu henkilössä eikä prosessissa, ja henkilökohtaiset parannukset eivät summaudu miksikään, jota voisi johtaa, mitata tai luvata asiakkaalle.

Konteksti rakennetaan joka kerta uudelleen käsityönä

Kielimalli tuottaa hyvän lopputuloksen silloin, kun sille annetaan hyvä konteksti: taustatiedot, säännöt, esimerkit siitä miltä kelvollinen tulos näyttää. Tämän kontekstin kokoaminen on ihmistyötä, ja se tehdään uudelleen jokaisella kerralla. Sitä ei lasketa mihinkään, koska se näyttää työn tekemiseltä eikä sen valmistelulta. Mitä vaativampi tehtävä, sitä suurempi osuus ajasta menee kontekstin rakentamiseen. Siksi hyöty on suurin siellä, missä panokset ovat pienimmät.

Kukaan ei omista lopputulosta

Kun tekijä vaihtaa tehtävää tai lähtee talosta, hänen tapansa lähtee mukana. Mitään ei jäänyt organisaatioon, koska mitään ei kirjattu muualle kuin yhden ihmisen työtapaan. Vuoden päästä samaa työtä tekevä aloittaa alusta.

Mittarit mittaavat käyttöönottoa, eivät muutosta

Useimmissa organisaatioissa seurataan lisenssien käyttöastetta, aktiivisten käyttäjien määrää ja käyttäjäkyselyn tyytyväisyyslukua. Kaikki kolme nousevat, ja raportti näyttää hyvältä. Yksikään niistä ei mittaa sitä, mitä oltiin ostamassa. Ne kertovat, että työkalu on otettu käyttöön. Ne eivät kerro läpimenoajasta, kapasiteetista, laadun hajonnasta tai virheiden määrästä. Lisenssi on kuitti, ei muutos. Kokeile tätä vaihtoa: mittaa yhden toistuvan toimeksiantotyypin läpimenoaika ja hajonta ennen ja jälkeen. Jos luku ei liiku, käyttöaste ei ole vastaus vaan harha.

Mitä tapahtuu, kun yksikkö on prosessi eikä tehtävä

Kun asiantuntijaprosessi puretaan riittävän pieniin osiin, siitä paljastuu kaksi asiaa, jotka eivät näy tehtävätasolla. Ensimmäinen: iso osa työstä ei tarvitse kielimallia lainkaan. Kun asiantuntijaprosessi puretaan toteutuskelpoisiksi vaiheiksi, niitä tulee tyypillisesti neljästäkymmenestä kuuteenkymmeneen. Mitatussa esimerkissä, kolmessa työnkulussa yhdestä myyntiprosessista, yli puolet vaiheista oli deterministisiä teknisiä tehtäviä: tiedonhakuja, muunnoksia, tarkistuksia ja siirtoja, jotka toimivat aina samalla tavalla. Noin 30 prosenttia oli kielimallikutsuja, joissa tarvitaan tulkintaa. Loput olivat ihmisen hyväksyntäpisteitä. Yli puolessa vaiheista ei siis ole mitään hallusinoitavaa, koska niissä ei käytetä kielimallia lainkaan. Tämä on tärkeä havainto kahdesta syystä. Riskikeskustelu muuttuu, koska riski ei jakaudu tasaisesti vaan keskittyy tunnistettaviin kohtiin. Ja kustannuskeskustelu muuttuu, koska halvin token on se, jota ei käytetä. Toinen: pullonkaula on asiakkaan omassa kalenterissa. Samasta toteutuksesta mitattu ihmistyön jakauma määrittelyvaiheessa: asiakkaan omat asiantuntijat 80 prosenttia, ulkopuolinen määrittelijä 10 prosenttia, tekninen toteuttaja 10 prosenttia. Asiakkaan osuus on 80 prosenttia siksi, että määrittely on hiljaisen tiedon esiin saamista, ja se tieto on vain niillä ihmisillä, jotka työn oikeasti osaavat. Ensimmäisen toimivan version kone koodasi valmiista speksistä noin kahdessakymmenessä tunnissa. Se ei ollut vielä valmis, eikä sen kuulunutkaan olla. Sen jälkeen alkaa iterointi, ja siinä sama epäsuhta toistuu. Katselmoinnissa istuu tyypillisesti yksi kehittäjä ja kahdesta neljään asiakkaan osaajaa, eli jokainen yhteinen tunti kuluttaa asiakkaan aikaa moninkertaisesti kehittäjän aikaan verrattuna. Iterointivaiheesta ei ole vielä mitattua jakaumaa, mutta rakenne on sama kuin määrittelyssä, ja syy on sama: vain asiakas tietää, toimiiko prosessi niin kuin oli tarkoitus. Pullonkaula ei siis poistu, kun toteutus valmistuu. Se siirtyy. Ensin tieto ulos ihmisistä, sitten arviointi takaisin ihmisille. Kummassakin havainnossa on sama johtopäätös. Se, mikä ratkaisee, tapahtuu ennen ensimmäistä ajoa.

Neljä kysymystä, joihin vastaatte itse

Jos kaksi eri asiantuntijaa tekee saman toimeksiannon, kuinka paljon lopputulokset poikkeavat toisistaan? Jos vastaus on "paljon", ongelma ei ole työkalussa. Montako vaihetta tärkeimmässä toistuvassa prosessissanne on? Jos ette osaa sanoa, sitä ei voi antaa koneelle. Missä kohdassa prosessia joku hyväksyy jotain, ja mistä hän tietää että tulos kelpaa? Jos vastaus on kokemus, hyväksymisehtoa ei ole kirjoitettu. Kun paras tekijänne jää eläkkeelle, mitä jää jäljelle? Jos vastaus on kansio ja hyvä muisti, tieto ei ole vielä siirtynyt mihinkään. Jos tunnistitte itsenne useammasta kuin kahdesta, olette siinä vaiheessa, jossa helpot työkalut on kokeiltu ja todettu riittämättömiksi. Se on oikea paikka, ei epäonnistuminen. Se on vain eri ongelma kuin se, jota työkaluilla ratkaistiin.

Mitä tälle tehdään

Työ kuvataan tarkkuudella, jolla sen voi antaa koneelle: vaiheet, tietovirrat, hyväksymisehdot, ihmisen valvontapisteet ja riskiluokitus. Kuvaus tehdään koneluettavaan muotoon, ja se jää organisaatiolle riippumatta siitä, kuka lopulta rakentaa toteutuksen tai millä alustalla. Tämä työ tehdään joka tapauksessa. Kysymys on vain, tehdäänkö se hallitusti etukäteen vai kalliisti toteutuksen aikana, jolloin jokainen epäselvyys löytyy vasta rakennettaessa. Tarkemmin siitä, mitä spec-first tarkoittaa käytännössä ja mitä toteutuskelpoinen määritys sisältää, kirjoitamme Näkemys-osiossa.

Seuraava askel

Aloita 30 minuutin kartoituskeskustelulla. Tunnistamme yhdessä asiantuntijatyönne tihentymät ja arvioimme, mistä prosessista kannattaa aloittaa. Ei toteutussitoumusta.