Builder AI siirtää painopisteen löydöksistä toteutukseen

Builder AI on ratkaisukonsepti, jonka tavoitteena on tehdä yrityksen toimintamallin uudistamisesta jatkuva kyvykkyys.

Konseptin ensimmäinen kokonaisuus on jatkuva prosessien selvitys. Se muodostaa yrityksen toiminnasta elävää ymmärrystä ja muuttaa arjen signaalit validoiduiksi uudistamismahdollisuuksiksi. Toinen kokonaisuus on agentifiointi ja digitaalinen infrastruktuuri, joiden avulla löydökset muutetaan uusiksi toimintamalleiksi, agenteiksi, integraatioiksi ja työkaluiksi.

Sarjan ensimmäisessä osassa esitimme, ettei nykyistä prosessia pidä hyväksyä automaattisesti tulevaisuuden tavoitetilaksi. Toisessa osassa kuvasimme yrityksen hermoston ja toiminnan digitaalisen kaksosen, joiden avulla yritys voi muodostaa jatkuvasti tarkentuvan kuvan todellisesta työstään. Kolmannessa osassa määrittelimme jatkuvan prosessien selvityksen kyvykkyydeksi, joka tunnistaa, validoi ja priorisoi uudistamisen tarpeita.

Selvityksen tuloksena yrityksellä voi olla perusteltu näkemys siitä, että esimerkiksi tarjousprosessin suurin ongelma ei ole tarjoustekstin kirjoittamiseen käytetty aika. Todellinen kitka voi syntyä hajallaan olevasta asiakastiedosta, toimituskyvyn manuaalisesta selvittämisestä, epäselvistä hinnoittelusäännöistä ja samanlaisina toistuvista hyväksynnöistä.

Tällöin seuraava askel ei ole valita, mihin vanhan prosessin vaiheeseen agentti lisätään.

Seuraava askel on suunnitella, miten tarjous pitäisi saada aikaan.

Kolme eri tapaa hyödyntää tekoälyä prosessissa

Tekoälyn käyttöä prosesseissa käsitellään usein yhtenä kokonaisuutena, vaikka käytännössä kyse voi olla kolmesta hyvin erilaisesta muutoksesta.

1. Tekoälyavusteinen työ

Ihminen omistaa edelleen työn etenemisen ja käyttää tekoälyä yksittäisten tehtävien tukena. Tekoälyavustaja voi tehdä yhteenvedon asiakkaasta, luonnostella viestin tai etsiä tietoa dokumenteista.

Työ voi nopeutua, mutta prosessin vaiheet, vastuut ja päätöspisteet säilyvät pääosin ennallaan.

2. Työnkulkuautomaatio

Järjestelmä suorittaa ennalta määritellyn vaihesarjan ja sääntöpohjaiset siirtymät. Kun tietty ehto täyttyy, järjestelmä luo tehtävän, lähettää hyväksyntäpyynnön tai päivittää toisen järjestelmän.

Työnkulkuautomaatio toimii hyvin, kun prosessi on vakaa, säännöt ovat yksiselitteisiä ja poikkeuksia on vähän. Se on jatkossakin tärkeä osa yritysten digitaalista infrastruktuuria.

3. Agenttinatiivi toimintamalli

Agenttinatiivissa toimintamallissa lähtökohtana ei ole yksi kiinteä tehtäväjärjestys vaan tavoiteltu lopputulos, käsiteltävän asian tila ja toimijoille määritellyt vastuut.

Agentti voi kerätä tilanteeseen tarvittavan kontekstin, arvioida vaihtoehtoisia etenemistapoja, käyttää järjestelmien toimintoja, pyytää puuttuvaa tietoa ja muuttaa suunnitelmaansa uuden tiedon perusteella. Se toimii kuitenkin määriteltyjen oikeuksien, sääntöjen ja eskalointirajojen sisällä.

Ero ei siis ole siinä, käytetäänkö prosessissa kielimallia. Ero on siinä, onko tekoäly nykyisen työn apuväline vai osa uudelleen suunniteltua tapaa tuottaa liiketoiminnallinen lopputulos.

Prosessikaaviosta tavoitteen ja tilan ohjaamaan työhön

Perinteinen prosessikuvaus etenee usein vaiheesta seuraavaan: ensin A, sitten B ja lopuksi C. Malli on hyödyllinen, kun kaikki tapaukset kulkevat suunnilleen samaa reittiä.

Moni asiantuntijaprosessi ei todellisuudessa toimi näin.

Tarjouksen eteneminen riippuu asiakkaasta, sopimuksen arvosta, toimituksen monimutkaisuudesta, käytettävissä olevasta kapasiteetista ja kaupallisesta riskistä. Reklamaation käsittely riippuu tuotteen historiasta, ongelman vakavuudesta, sopimusehdoista ja asiakassuhteesta. Projektin käynnistys riippuu siitä, mitä on myyty, mitä tietoa puuttuu ja mitä riippuvuuksia toimitukseen liittyy.

Tällaisessa työssä jäykkä työnkulku tuottaa helposti kaksi huonoa vaihtoehtoa. Kaikki tapaukset pakotetaan samaan prosessiin tai prosessin ympärille syntyy epävirallisia kiertoteitä.

Agenttinatiivissa suunnittelussa prosessin keskiöön voidaan nostaa käsiteltävä asia ja sen tavoitetila. Tarjouksen kohdalla agentti ylläpitää ajantasaista tilannekuvaa siitä, mitä asiakkaasta tiedetään, mitä vielä puuttuu, mitä päätöksiä on tehtävä ja mitkä riskit estävät etenemisen. Seuraava toimenpide määräytyy tämän tilan perusteella, ei vain prosessikaavion edellisen laatikon mukaan.

Tämä ei tarkoita, että agentti saisi keksiä toimintatavan vapaasti. Liiketoimintasäännöt, hyväksyntärajat ja pakolliset kontrollit voidaan edelleen toteuttaa deterministisesti. Agentin tehtävä on käsitellä vaihtelevaa kontekstia niiden ympärillä.

Hyvä agenttinatiivi toimintamalli yhdistääkin kahta logiikkaa:

• Deterministinen automaatio huolehtii täsmällisistä säännöistä, laskennasta, pakollisista tarkistuksista ja järjestelmätransaktioista.

• Agentit käsittelevät hajanaista tietoa, valmistelevat vaihtoehtoja, koordinoivat työtä ja tunnistavat tilanteet, joissa tarvitaan ihmisen harkintaa.

Agentti ei korvaa työnkulkua kaikkialla. Se tekee toimintamallista joustavamman niissä kohdissa, joissa yksi ennalta määrätty polku ei riitä.

Agenttinatiivi prosessi suunnitellaan lopputuloksesta taaksepäin

Vanhan prosessikaavion käyttäminen uuden ratkaisun vaatimusmäärittelynä lukitsee helposti myös vanhat oletukset. Parempi suunnittelutapa alkaa tavoitellusta lopputuloksesta ja etenee siitä taaksepäin.

Suunnittelussa pitää vastata ainakin seitsemään kysymykseen.

1. Mikä lopputulos halutaan saada aikaan?

Tavoitetta ei pidä määritellä vain tehtävän suorittamisena. "Tarjouksen laatiminen" kertoo tuotoksesta, mutta ei vielä liiketoiminnallisesta onnistumisesta.

Parempi tavoite voisi olla: asiakkaan tarpeeseen ja yrityksen toimituskykyyn sopiva, kaupallisesti kannattava tarjous toimitetaan sovitussa ajassa.

Tavoite antaa suunnittelulle suunnan ja mahdollistaa sen, että prosessia arvioidaan lopputuloksen eikä suoritettujen vaiheiden perusteella.

2. Mitä tietoa ja tilannekuvaa työ vaatii?

On määriteltävä, mitä agentin ja ihmisen pitää tietää asiakkaasta, tuotteesta, kapasiteetista, historiasta, säännöistä ja riskeistä. Samalla pitää erottaa tieto, joka voidaan hakea järjestelmistä, tiedosta, joka täytyy pyytää asiakkaalta tai asiantuntijalta.

Agentin ei pitäisi vain tuottaa vastausta. Sen pitäisi pystyä osoittamaan, mihin tietoon vastaus perustuu, mitä tietoa puuttuu ja kuinka epävarma tulkinta on.

3. Mitä päätöksiä prosessissa tehdään?

Moni prosessivaihe on todellisuudessa tiedon keräämistä yhtä myöhempää päätöstä varten. Kun päätökset tehdään näkyviksi, voidaan arvioida, mitä niistä voidaan automatisoida, mitä agentti voi valmistella ja mitkä kuuluvat ihmiselle.

Esimerkiksi hinnoittelu voi perustua selkeisiin sääntöihin normaalitapauksissa. Poikkeava kate, uusi sopimusmalli tai merkittävä toimitusriski voi puolestaan vaatia nimetyn henkilön hyväksynnän.

4. Mikä kuuluu ihmiselle, agentille ja järjestelmälle?

Työnjaon ei pitäisi perustua oletukseen, että kaikki mahdollinen siirretään agentille.

Järjestelmä sopii täsmälliseen laskentaan ja muuttumattomien sääntöjen toteuttamiseen. Agentti sopii kontekstin kokoamiseen, vaihtoehtojen muodostamiseen ja työn koordinointiin. Ihmistä tarvitaan erityisesti vastuullisiin päätöksiin, neuvotteluun, asiakassuhteen hoitamiseen ja tilanteisiin, joissa tavoitteet tai arvot ovat keskenään ristiriidassa.

Ihmistä ei myöskään kannata jättää käsittelemään vain kaikkein vaikeimpia poikkeuksia. Jos kaikki tavanomainen työ katoaa, asiantuntijan tilannetieto ja kyky arvioida harvinaisia tapauksia voivat heikentyä. Toimintamallissa pitää säilyttää tarkoituksenmukaiset pisteet, joissa ihminen seuraa kokonaisuutta, kalibroi agentin toimintaa ja oppii sen ratkaisuista.

5. Kuinka paljon autonomiaa agentille annetaan?

Autonomia ei ole kyllä tai ei -valinta. Se voidaan määritellä päätös- ja toimintokohtaisesti.

Agentti voi:

1. havaita tilanteen ja tuoda sen ihmiselle

2. ehdottaa seuraavaa toimenpidettä

3. valmistella toimenpiteen hyväksyttäväksi

4. toteuttaa sen ennalta määritellyissä rajoissa

5. toteuttaa ja raportoida jälkikäteen

Sopiva taso riippuu vaikutuksesta, palautettavuudesta, epävarmuudesta ja riskistä. Sisäisen luonnoksen laatiminen ja asiakkaalle sitovan tarjouksen lähettäminen eivät tarvitse samaa kontrollia.

6. Milloin työ pitää eskaloida?

Agentin pitää tunnistaa oman toimivaltansa rajat. Eskalointi voi perustua esimerkiksi puuttuvaan tietoon, ristiriitaisiin lähteisiin, poikkeavaan taloudelliseen vaikutukseen, sopimusriskin kasvuun tai siihen, ettei agentti pysty perustelemaan suositustaan riittävällä varmuudella.

Hyvä eskalointi ei ole pelkkä ilmoitus ongelmasta. Agentti kokoaa ihmiselle tilanteen, olennaiset lähteet, tehdyt tarkistukset, avoimet kysymykset ja vaihtoehtojen seuraukset. Näin ihminen voi käyttää aikansa päätökseen eikä asian historian selvittämiseen.

7. Miten tulosta ja toimintaa mitataan?

Agentin suorittamien tehtävien määrä ei vielä kerro prosessin onnistumisesta. Mittareiden pitää palata alussa määriteltyyn liiketoimintatulokseen.

Tarjousprosessissa voidaan seurata esimerkiksi läpimenoaikaa, tarjousten katetta, konversiota, tehtyjen korjausten määrää, asiakaspalautetta ja sitä, kuinka moni tapaus vaatii poikkeuskäsittelyä. Lisäksi pitää seurata agentin toiminnan laatua: virheellisiä ehdotuksia, turhia eskalointeja, ihmisten tekemiä korjauksia ja sääntöjen noudattamista.

Esimerkki: tarjousprosessi suunnitellaan uudelleen

Perinteisessä tarjousprosessissa myyjä toimii usein sekä asiantuntijana että integraationa. Hän etsii tietoa CRM:stä ja aiemmista tarjouksista, kysyy taloudelta hinnoittelutietoja, selvittää toimitukselta kapasiteettia, kokoaa dokumentin ja huolehtii hyväksynnöistä.

Prosessiin voidaan lisätä tekoälyavustaja, joka kirjoittaa tarjoustekstin. Se säästää aikaa yhdessä vaiheessa, mutta ei poista tiedon hajanaisuutta, odottamista tai koordinointia.

Työnkulkuautomaatiolla voidaan puolestaan lähettää hyväksyntäpyyntö automaattisesti, kun tarjous on valmis. Sekin voi olla hyödyllistä, mutta hyväksyntä saattaa edelleen olla samanlainen kaikille tarjouksille riippumatta niiden riskistä.

Agenttinatiivissa toimintamallissa kokonaisuus voisi toimia toisin:

1. Agentti havaitsee CRM:stä riittävän pitkälle edenneen myyntimahdollisuuden ja muodostaa tarjoustapauksen.

2. Se kokoaa asiakkaan historian, tarpeet, sovitut asiat, aiemmat ratkaisut, hinnoittelusäännöt, toimituskyvyn ja tunnistetut riskit yhteiseksi tilannekuvaksi.

3. Jos olennaista tietoa puuttuu, agentti pyytää sen oikealta henkilöltä täsmällisin kysymyksin tai valmistelee kysymykset asiakkaalle.

4. Agentti muodostaa yhden tai useamman tarjousvaihtoehdon ja näyttää niiden oletukset, katteen, toimitusvaikutukset ja riskit.

5. Tavanomainen, sääntöjen mukainen tarjous voi edetä kevyellä tarkistuksella. Poikkeava hinta, suuri arvo, uusi sopimusehto tai epävarma toimituskyky ohjaa tapauksen nimetylle päätöksentekijälle.

6. Ihminen arvioi kaupallisen lähestymistavan, neuvottelee tarvittaessa asiakkaan kanssa ja tekee ne päätökset, joihin liittyy merkittävää harkintaa tai vastuuta.

7. Agentti viimeistelee materiaalin, tallentaa päätösten perustelut, päivittää järjestelmät ja seuraa asiakkaan vastausta sekä sovittuja jatkotoimia.

Prosessi ei vain nopeudu. Sen rakenne muuttuu.

Myyjän ei tarvitse toimia tiedonvälittäjänä järjestelmien ja tiimien välillä. Hyväksyntä ei ole kaikille samanlainen vaihe, vaan riskiin perustuva kontrolli. Tarjouksen muodostaminen ei ala tyhjästä dokumenttipohjasta, vaan ajantasaisesta tilannekuvasta. Ihminen osallistuu niissä kohdissa, joissa hänen asiakasymmärryksensä, neuvottelukykynsä ja vastuunsa tuottavat eniten arvoa.

Hallittu autonomia vaatii näkyvän vastuun

Agenttinatiivi ei tarkoita autonomista hinnalla millä hyvänsä.

Mitä enemmän agentti voi tehdä, sitä tärkeämpää on määritellä, kuka omistaa prosessin lopputuloksen, millä perusteella agentti toimii ja miten sen toiminta voidaan jäljittää. Vastuu ei siirry kielimallille, vaikka osa työstä siirtyisi agentille.

Jokaisella agenttinatiivilla prosessilla pitäisi olla liiketoiminnallinen omistaja. Hänen vastuullaan on määritellä tavoite, hyväksyä toimivallan rajat, seurata vaikutuksia ja päättää, milloin toimintamallia muutetaan.

Lisäksi jokaisesta merkityksellisestä toimesta pitää jäädä riittävä jälki: mitä tietoa käytettiin, mitä sääntöä sovellettiin, mitä agentti ehdotti tai teki, millä varmuudella ja kuka mahdollisesti hyväksyi päätöksen. Virhetilanteita varten tarvitaan tapa keskeyttää toiminta, palauttaa tehty muutos ja ohjata tapaus ihmiselle.

Nämä eivät ole vasta teknisen toteutuksen yksityiskohtia. Ne ovat osa toimintamallin suunnittelua.

Agenttinatiivi toimintamalli ei synny yhdellä suunnittelukerralla

Ensimmäinen versio uudesta prosessista perustuu aina oletuksiin. Kaikkia poikkeuksia ei tunneta etukäteen, kaikkien tietolähteiden laadusta ei ole varmuutta eikä sopivaa autonomian tasoa voida päätellä pelkässä työpajassa.

Siksi käyttöönotto kannattaa nähdä hallitusti laajenevana oppimisprosessina.

Aluksi agentti voi vain koota tilannekuvan ja ehdottaa toimenpiteitä. Kun ehdotusten laatua, ihmisten korjauksia ja poikkeuksia on seurattu riittävästi, se voi valmistella toimia hyväksyttäväksi. Rajatuissa ja matalan riskin tilanteissa agentille voidaan myöhemmin antaa oikeus toimia itsenäisesti.

Samalla toteutuksesta syntyvä tieto pitää palauttaa Builder AI:n jatkuvaan prosessien selvitykseen. Jos ihmiset korjaavat aina saman oletuksen, eskalointeja syntyy liikaa tai liiketoimintamittari ei parane, toimintamallia pitää muuttaa. Jos taas jokin päätöstyyppi osoittautuu vakaaksi ja hyvin ennustettavaksi, sen käsittelyä voidaan yksinkertaistaa tai automatisoida pidemmälle.

Agenttinatiivi prosessi ei siis ole valmis kaavio. Se on mitattava ja kehittyvä tapa järjestää työ.

Teknologia tulee toimintamallin jälkeen, mutta ilman sitä malli ei toimi

Agenttinatiivin toimintamallin suunnittelu alkaa liiketoiminnan lopputuloksesta, ei teknologiasta. Silti suunnitelma muuttuu käytännöksi vasta, kun agentilla on hallittu pääsy tarvittavaan dataan, järjestelmien toimintoihin ja prosessin tilaan.

Tarvitaan integraatioita, käyttöoikeuksia, laadukasta dataa, sääntöjen hallintaa, seurantaa ja auditointia. Tarvitaan myös tapa rakentaa, testata, julkaista ja kehittää agentteja turvallisesti osana yrityksen muuta digitaalista ympäristöä.

Ilman tätä perustaa agentti jää avustajaksi, joka antaa neuvoja työn ulkopuolelta. Hallitun digitaalisen infrastruktuurin avulla siitä voi tulla osa yrityksen operatiivista toimintakykyä.

Seuraavassa ja sarjan viimeisessä osassa tarkastelemme, mitä agenttinatiivin yrityksen rakentaminen käytännössä vaatii: millaiset data-, integraatio-, agentti- ja hallintakerrokset yhdistävät jatkuvan prosessien selvityksen toimivaksi digitaaliseksi infrastruktuuriksi.