AI-transformaatio tarvitsee jatkuvaa prosessien selvitystä
AI-transformaatio ei tarvitse vain lisää käyttötapauksia. Se tarvitsee pysyvän kyvyn löytää, validoida ja priorisoida ne prosessit, jotka kannattaa suunnitella uudelleen agenttien, datan ja integraatioiden ehdoilla.
Tämä artikkeli on kolmas osa blogisarjaa Automaatiosta agenttinatiiviin yritykseen. Sarjassa käsittelemme, miten yritykset voivat siirtyä yksittäisistä AI- ja automaatiokokeiluista kohti jatkuvaa prosessien uudistamista, agenttien hyödyntämistä ja uutta digitaalista toimintamallia.
Tässä osassa esittelemme jatkuvan prosessien selvityksen: Builder AI -konseptin ydinkyvykkyyden, joka muuttaa yrityksen arjesta syntyvät signaalit perustelluiksi uudistamismahdollisuuksiksi ja vie ne hallitusti kohti toteutusta.
Builder AI lyhyesti
Builder AI on ratkaisukonsepti, jonka tavoitteena on tehdä yrityksen toimintamallin uudistamisesta jatkuva kyvykkyys.
Se ei ole yksittäinen agentti, prosessikaaviotyökalu tai automaatioalusta. Se on toimintamalli ja sitä tukeva digitaalinen kerros, joka auttaa yritystä ymmärtämään, miten työ todellisuudessa tapahtuu, mitä liiketoiminnallisia lopputuloksia prosesseilla tavoitellaan ja missä agentit tai uudet digitaaliset ratkaisut voisivat muuttaa työn tekemisen tapaa olennaisesti.
Konsepti muodostuu kahdesta toisiinsa kytkeytyvästä kokonaisuudesta:
Jatkuva prosessien selvitys muodostaa elävää ymmärrystä yrityksen toiminnasta ja tunnistaa uudistamisen tarpeita.
Agentifiointi ja digitaalinen infrastruktuuri muuttavat validoidut tarpeet uusiksi toimintamalleiksi, agenteiksi, integraatioiksi, dataratkaisuiksi ja digitaalisiksi työkaluiksi.
Näiden välille pitää muodostua jatkuva kierto. Havainnot johtavat toteutuksiin, toteutusten vaikutuksia mitataan ja tulokset tarkentavat jälleen ymmärrystä yrityksen toiminnasta.
Sarjan ensimmäisessä osassa esitimme, ettei nykyistä prosessia pidä pitää automaattisesti tulevaisuuden tavoitetilana. Nykyprosessi on todisteaineistoa: se paljastaa työn tavoitteet, päätökset, poikkeukset ja vanhojen rajoitteiden synnyttämät vaiheet.
Toisessa osassa kuvasimme yrityksen hermoston. Se yhdistää järjestelmien, dokumenttien, mittareiden ja ihmisten tuottamia signaaleja eläväksi ymmärrykseksi siitä, miten työ todella tapahtuu. Näiden signaalien varaan voidaan vähitellen rakentaa myös yrityksen toiminnan digitaalinen kaksonen.
Mutta havainnointi ei vielä itsessään muuta mitään.
Signaaleista pitää muodostaa perusteltuja havaintoja. Havainnot pitää validoida. Uudistamismahdollisuuksia pitää vertailla keskenään. Ja parhaiden mahdollisuuksien pitää edetä toteutukseen.
Tätä varten tarvitaan jatkuvaa prosessien selvitystä.
AI-vision ja toteutuksen väliin jää aukko
Monessa organisaatiossa tekoälyn mahdollisuudet tunnistetaan työpajoissa, ideakilpailuissa tai yksittäisten työntekijöiden aloitteista. Näin voidaan löytää hyödyllisiä käyttötapauksia, mutta menetelmä on satunnainen.
Usein toteutukseen päätyy idea, joka on helppo esitellä tai teknisesti nopeasti kokeiltavissa. Tällainen idea ei kuitenkaan välttämättä ole liiketoiminnan kannalta arvokkain. Sen vaikutus asiakaskokemukseen, läpimenoaikaan, laatuun tai tulokseen voi jäädä vähäiseksi.
Samalla parhaat uudistamiskohteet voivat jäädä piiloon organisaation arkeen. Ne näkyvät toistuvina kysymyksinä, pieninä käsin tehtävinä tarkistuksina, järjestelmien välisinä tiedonsiirtoina, epäselvinä vastuina ja poikkeuksina, joita kokeneet työntekijät ovat oppineet hoitamaan huomaamattomasti.
Näistä ei välttämättä synny aloitetta tai AI-käyttötapausta. Ne vain kuluttavat aikaa päivästä toiseen.
Siksi AI-vision ja teknisen toteutuksen väliin tarvitaan pysyvä kyvykkyys, joka etsii uudistamisen tarpeita sieltä, missä työ todella tapahtuu.
Mitä jatkuva prosessien selvitys tarkoittaa?
Jatkuva prosessien selvitys on toimintamalli, joka tunnistaa, tutkii, validoi ja priorisoi prosessien uudistamismahdollisuuksia.
Se hyödyntää yrityksen hermoston tuottamia signaaleja, mutta sen tehtävä on laajempi kuin havainnointi. Hermosto kertoo, että jossain tapahtuu jotain kiinnostavaa. Jatkuva prosessien selvitys arvioi, mitä havainto tarkoittaa, mistä se johtuu ja kannattaako sen perusteella muuttaa toimintamallia.
Yksittäinen signaali voi olla esimerkiksi tarjousprosessin kasvanut läpimenoaika. Se ei vielä kerro, onko ongelma hyväksynnässä, puuttuvassa datassa, toimituskyvyn arvioinnissa vai siinä, että tarjouksia käsitellään keskenään hyvin erilaisilla tavoilla.
Selvityksen tehtävä on liittää signaali oikeaan prosessiin, kerätä sitä tukeva aineisto ja kysyä ihmisiltä puuttuva konteksti. Vasta tämän jälkeen voidaan muodostaa hypoteesi siitä, mitä pitäisi muuttaa.
Signaalista uudistamismahdollisuudeksi
Jatkuvassa prosessien selvityksessä on tärkeää erottaa neljä asiaa toisistaan:
Signaali kertoo poikkeamasta, toistuvasta tapahtumasta tai muutoksesta. Läpimenoaika kasvaa, sama tukipyyntö toistuu tai tietoa siirretään usein järjestelmästä toiseen.
Havainto yhdistää signaalin prosessiin ja liiketoimintakontekstiin. Esimerkiksi suurin osa tarjousprosessin viiveestä syntyy toimituskyvyn manuaalisesta varmistamisesta.
Hypoteesi esittää mahdollisen selityksen tai paremman toimintatavan. Toimituskykyä koskeva tieto voitaisiin tuoda myynnin käyttöön jatkuvasti päivittyvänä arviona.
Validoitu uudistamismahdollisuus sisältää riittävän näytön, omistajan, tavoitellun vaikutuksen ja alustavan toteutussuunnan päätöksentekoa varten.
Tämä erottelu estää järjestelmää tekemästä liian nopeita johtopäätöksiä.
Kaikki poikkeamat eivät ole ongelmia. Kaikki manuaalinen työ ei ole turhaa. Eikä jokaiseen ongelmaan tarvita agenttia. Joskus oikea ratkaisu on poistaa työvaihe, selkeyttää vastuuta, parantaa lähtödatan laatua tai muuttaa liiketoimintasääntöä.
Jatkuvan prosessien selvityksen pitää etsiä parasta toimintamallia, ei perustelua ennalta valitulle teknologialle.
Selvitys toimii jatkuvana silmukkana
Käytännössä jatkuva prosessien selvitys voidaan kuvata kahdeksan vaiheen silmukkana:
Havainnoi. Kerää sallituista lähteistä prosessitapahtumia, mittareita, dokumentteja, palautetta ja ihmisten havaintoja.
Yhdistä. Liitä signaalit prosesseihin, asiakkaisiin, tavoitteisiin, rooleihin ja järjestelmiin.
Tunnista. Etsi toistuvaa kitkaa, odotusta, käsityötä, epäselvää omistajuutta ja poikkeusten kasautumista.
Muodosta hypoteesi. Päättele, mikä ilmiötä voisi selittää ja millainen toimintamallin muutos voisi auttaa.
Validoi. Pyydä prosessin tuntevilta ihmisiltä puuttuva konteksti ja korjaa virheelliset tulkinnat.
Priorisoi. Arvioi liiketoimintavaikutus, strateginen merkitys, toteutettavuus, riskit ja tarvittavat riippuvuudet.
Vie toteutukseen. Muotoile mahdollisuus niin selkeästi, että prosessin uudelleensuunnittelu ja tekninen selvitys voivat alkaa.
Mittaa ja opi. Seuraa muutoksen vaikutusta ja päivitä prosessin digitaalista mallia tulosten perusteella.
Silmukka on olennainen. Ilman viimeistä vaihetta Builder AI tuottaisi vain kehitysideoiden listan. Mittaamisen avulla yritys oppii myös siitä, mitkä oletukset olivat oikeita ja millaiset uudistukset tuottavat todellista arvoa.
Mitä järjestelmän pitäisi löytää?
Jatkuva selvitys voi tuoda näkyviin esimerkiksi:
samojen tietojen toistuvan tarkistamisen tai syöttämisen
hyväksynnät, joiden tarkoitus tai riskiperuste ei ole enää selvä
prosessit, joissa ihminen välittää tietoa järjestelmien välillä
pitkät odotusajat ilman aktiivista käsittelyä
epäselvät omistajuudet ja toistuvat siirrot tiimiltä toiselle
poikkeukset, joiden määrä kasvaa vähitellen normaaliksi työksi
asiakaskitkan, joka näkyy useissa eri kanavissa samana ilmiönä
epäviralliset Excelit, viestiketjut ja muut työn kannalta kriittiset kiertotiet
päätökset, joissa tarvittava tieto on hajallaan tai vaikeasti saatavilla
prosessit, jotka eivät enää tue yrityksen strategisia tavoitteita
Tärkein löydös ei aina ole automatisoitava työvaihe.
Arvokkaampi havainto voi olla se, että koko vaihe on tarpeeton, päätös pitäisi tehdä aiemmin tai asiakas voisi toimittaa tiedon rakenteisessa muodossa jo prosessin alussa.
Ihminen validoi tarkoituksen
Agentti voi löytää datasta malleja, mutta se ei tunne automaattisesti työn tarkoitusta.
Tapahtumaloki voi osoittaa, että yksi hyväksyntä kestää pitkään. Se ei kerro, ehkäiseekö hyväksyntä merkittävää riskiä. Keskusteluista voi löytyä toistuva kysymys, mutta ilman kontekstia ei tiedetä, johtuuko se puutteellisesta ohjeesta, järjestelmävirheestä vai aidosti vaikeasta päätöksestä.
Siksi ihmisten validointi ei ole selvityksen loppuvaiheen muodollisuus. Se on osa päättelyä.
Agentin pitäisi osata kysyä esimerkiksi:
Mitä riskiä tällä hyväksynnällä hallitaan?
Onko tämä poikkeus vai prosessin tavallinen kulku?
Kuka vastaa lopputuloksesta, kun työ siirtyy tiimien välillä?
Mitä tietoa päätöksentekijä tässä vaiheessa oikeasti tarvitsee?
Mikä estää tämän vaiheen poistamisen kokonaan?
Ihmisten pitää myös voida nähdä, mihin aineistoon havainto perustuu, korjata agentin tulkintaa ja tarvittaessa hylätä hypoteesi. Näin prosessista muodostuva digitaalinen malli tarkentuu sekä datasta että käytännön asiantuntemuksesta.
Toteutukseen tarvitaan enemmän kuin idea
Epämääräinen ehdotus, kuten "tähän tarvitaan AI-agentti", ei vielä auta toteutustiimiä tai liiketoimintaa tekemään päätöstä.
Validoidun uudistamismahdollisuuden pitäisi kuvata ainakin:
tavoiteltu liiketoiminnallinen lopputulos
nykytilasta tehty havainto ja sitä tukeva näyttö
ilmiön yleisyys, vaikutus ja kohderyhmät
prosessiin osallistuvat roolit ja järjestelmät
tarvittava data ja sen saatavuus
päätökset, säännöt, poikkeukset ja ihmisen vastuu
alustava näkemys uudesta toimintamallista
riskit, riippuvuudet ja avoimet kysymykset
mittarit, joilla muutoksen onnistumista arvioidaan
suositeltu seuraava askel
Tässä vaiheessa ei vielä tarvitse lukita lopullista teknistä ratkaisua. Tärkeämpää on määritellä ongelma, tavoiteltu tulos ja muutoksen reunaehdot niin hyvin, että vaihtoehtoja voidaan arvioida järkevästi.
Sama mahdollisuus voi johtaa agenttiin, integraatioon, uuteen sovellukseen, datan rakenteistamiseen, prosessin sääntömuutokseen tai näiden yhdistelmään.
Priorisointi tekee löydöksistä tiekartan
Jos jatkuva havainnointi toimii hyvin, mahdollisuuksia löytyy enemmän kuin yritys pystyy toteuttamaan.
Siksi Builder AI:n ei pidä tuottaa vain kasvavaa kehitysjonoa. Sen pitää auttaa vertailemaan mahdollisuuksia yhteisillä perusteilla.
Priorisoinnissa voidaan tarkastella esimerkiksi:
vaikutusta asiakkaaseen, liikevaihtoon, kustannuksiin, laatuun tai läpimenoaikaan
ongelman yleisyyttä ja kasvusuuntaa
yhteyttä strategisiin tavoitteisiin
datan ja integraatioiden valmiutta
toteutuksen monimutkaisuutta ja riippuvuuksia
liiketoiminta-, tietosuoja- ja turvallisuusriskejä
sitä, voidaanko samaa kyvykkyyttä hyödyntää useassa prosessissa
muutoksesta saatavaa oppia
Arvioita ei pidä esittää tarkempina kuin ne ovat. Alkuvaiheessa suuntaa antava vaikutusarvio ja näkyvä epävarmuus ovat hyödyllisempiä kuin näennäisen tarkka ROI-luku.
Kun havainnot, validointi ja priorisointi toistuvat samalla tavalla, yritykselle alkaa muodostua elävä AI- ja uudistamistiekartta. Se ei perustu kerran vuodessa pidettyyn ideointipäivään, vaan siihen, miten liiketoiminta oikeasti toimii ja muuttuu.
Aloita yhdestä tärkeästä prosessialueesta
Jatkuvaa prosessien selvitystä ei kannata aloittaa yrittämällä mallintaa koko yritystä kerralla.
Valitse yksi liiketoiminnallisesti tärkeä prosessialue, jossa on riittävästi tapahtumia, tunnistettua kitkaa ja halu kehittää toimintaa. Tällainen alue voi olla esimerkiksi asiakasavaus, tarjousprosessi, reklamaatioiden käsittely tai projektin käynnistys.
Käytännöllinen ensimmäinen versio voi edetä näin:
Määrittele tavoiteltava liiketoiminnallinen lopputulos ja prosessin omistaja.
Valitse muutama keskeinen signaalilähde, älä kaikkea mahdollista dataa.
Muodosta ensimmäinen kuva prosessista, sen päätöksistä ja poikkeuksista.
Käsittele agentin havainnot säännöllisesti prosessin tuntevien ihmisten kanssa.
Vie yksi tai kaksi vahvasti perusteltua mahdollisuutta uudelleensuunnitteluun.
Mittaa toteutuksen vaikutusta samoista liiketoimintamittareista, joilla tarve tunnistettiin.
Samalla pitää sopia läpinäkyvästi, mitä aineistoa käytetään, mihin tarkoitukseen ja kuka havaintoja näkee. Selvityksen kohteena ovat prosessit ja työn rakenteet, eivät yksittäisten työntekijöiden suoritukset.
Ensimmäisen kokeilun tärkein tulos ei ole suuri määrä käyttötapauksia. Se on toimiva oppimissilmukka havainnosta toteutukseen ja takaisin.
Puuttuva kerros on jatkuva kyky valita oikein
AI-transformaation ongelma ei yleensä ole ideoiden täydellinen puute.
Vaikeampaa on tietää, mitkä ideat perustuvat todelliseen tarpeeseen, mitkä prosessit pitäisi suunnitella kokonaan uudelleen ja missä järjestyksessä uudistuksia kannattaa viedä eteenpäin.
Builder AI:n tavoitteena on nopeuttaa ajan myötä myös toteutusta. Agentit voivat osallistua digitaalisten ratkaisujen määrittelyyn, rakentamiseen, testaamiseen, käyttöönottoon ja jatkuvaan kehittämiseen. Kun toteutuskapasiteetti kasvaa, keskeiseksi pullonkaulaksi nousee kyky valita oikeat uudistukset sekä määritellä niille liiketoiminnalliset tavoitteet, vastuut ja reunaehdot.
Jatkuva prosessien selvitys vastaa tähän ongelmaan. Se yhdistää yrityksen hermoston tuottamat signaalit, ihmisten kontekstin, liiketoiminnan tavoitteet ja toteutuksesta saadun oppimisen yhdeksi pysyväksi kyvykkyydeksi.
Silloin AI-tiekartta ei ole irrallisten pilottien kokoelma. Se on jatkuvasti päivittyvä näkemys siitä, miten yrityksen toimintamallia kannattaa uudistaa.
Seuraavassa osassa siirrymme löydöksistä suunnitteluun: miltä prosessi näyttää, kun sitä ei vain automatisoida vaan se rakennetaan alusta agenttinatiiviksi toimintamalliksi?
Terho Antila
CTO @ Locoda

