Chat-ikkunan alla tapahtuu jotain muuta kuin kysymys ja vastaus. Ketju on sarja peräkkäisiä vaiheita, jotka seuraavat toisiaan ilman, että ihmisen täytyy joka vaiheen välissä painaa uudelleen käynnistysnappia. Hakemus saapuu, luetaan, tarkistetaan säännön mukaan, siirretään järjestelmään, ja tulos ilmoitetaan takaisin sille, joka sitä tarvitsee. Ihmiselle se on sarja peräkkäisiä toimintoja. Ketjulle se on yksi liike, kunhan kukin vaihe tietää, mitä edellinen tuotti ja mitä seuraava tarvitsee.
Yhden tehtävän automatisointi on hallittavissa: asiakirjan lukeminen, yhteenvedon tekeminen, kysymykseen vastaaminen. Ketju on eri asia, koska virhe vaiheessa kaksi vaikuttaa vaiheeseen viisi, ja kukaan ei näe virhettä ennen kuin lopputulos on jo päätynyt jonnekin. Se on syy, miksi ketjut vaativat enemmän kuin yksittäiset vaiheet: on oltava jokin, joka tarkistaa, että vaiheiden välinen siirto on oikein, ja on oltava joku tai jokin, joka puuttuu asiaan, jos näin ei ole. Sitä vaille ketjusta tulee liukuhihna vailla hätäpysäytintä.
Ketju koskettaa useita järjestelmiä, ja se tarkoittaa, että näiden järjestelmien on kyettävä puhumaan toisilleen. Jos CRM, suunnittelutyökalu ja laskutusjärjestelmä käyttävät kukin omaa määritelmäänsä 'asiakkaasta' tai 'tilasta', ketju katkeaa siihen kohtaan, jossa siirto tapahtuu. Se ei ole AI-ongelma; se on kysymys, joka edeltää AI:ta, siitä, onko infrastruktuuri ja datanhallinta järjestetty niin, että tieto voi siirtyä järjestelmästä toiseen ilman manuaalista korjausta.
Lisäksi ketju vaatii organisaatiota, joka tietää, kuka on vastuussa mistä, kun jokin menee pieleen. Yksittäisessä tehtävässä tämä kysymys on pieni: joku tarkistaa tuloksen ja korjaa sen itse. Ketjussa kysymys on suurempi, koska virhe voi ilmaantua eri kohdassa kuin missä se tulee näkyväksi. Kuka valvoo ketjua, kuka huomaa häiriön ja kuka päättää, saako ketju jatkaa toimintaansa vai pitääkö sen pysähtyä, ovat kysymyksiä, joihin täytyy olla vastaus ennen kuin ketju käynnistetään.
Yleinen malli on signaali, joka johtaa jatkotoimeen: jokin havaitaan, ja tämä havaitseminen käynnistää seuraavan toimenpiteen sen sijaan, että jäätäisiin ilmoitukseen. Se, mitä tämä vaatii, on kuvattu sivulla seurannasta, joka kytkeytyy automaattisesti jatkotoimeen. Toinen malli on, että ketju siirtää vaiheita osastojen välillä: jokin, joka alkaa hankinnasta, kulkee talouden läpi ja päättyy toimintoihin, ilman että kenenkään täytyy jatkuvasti lähettää sitä uudelleen eteenpäin. Mitä tämä vaatii organisaatiolta, on kuvattu sivulla osastojen välisestä yhteensovittamisesta, joka nyt kulkee ihmisten kautta. Myös ketju, joka alkaa saapuvasta asiakirjasta — lukeminen, arvioiminen, eteenpäin lähettäminen — rakentuu sen päälle, mitä löytyy sivulta asiakirjoista, jotka luetaan ja tiivistetään ennen kuin joku lähettää ne eteenpäin.
Se, mitä ketju tuottaa, riippuu siitä, kuinka moni näistä vaiheista todella liittyy toisiinsa. Ketju, joka paperilla käsittää kymmenen vaihetta mutta pysähtyy vaiheessa kolme, koska järjestelmä ei välitä ajantasaista tietoa, tuottaa vähän verrattuna kolmen vaiheen ketjuun, joka todella etenee keskeytyksettä. Ketjun pituus on vähemmän tärkeä kuin kysymys siitä, liittyykö kukin lenkki todella seuraavaan.
Yleisin syy siihen, että ketju ei etene, on se, että perustavat kerrokset eivät ole sitä varten valmiit. Data, joka on jäsennelty eri tavalla yhdessä järjestelmässä kuin toisessa, IT-infrastruktuuri, joka ei osaa siirtää vaiheita automaattisesti, tai organisaatio, jolla ei ole selvyyttä siitä, kuka käynnistää keskeytyneen ketjun uudelleen — näitä kysymyksiä ketju ei ratkaise itse. Juuri sen takia järjestyksellä on merkitystä: ensin perustavat kerrokset kuntoon, vasta sitten se riippuvainen vaihe ketjusta, joka todella etenee. Organisaatio, joka kääntää tämän järjestyksen toisin päin, rakentaa ketjua perustukselle, jota ei ole vielä valettu.
Toimiva ketju on harvoin puhtaasti tekninen ongelma. Se on organisatorinen kysymys: kuka omistaa prosessin, kun sitä ei enää ole pilkottu erillisiin tehtäviin, vaan se on olemassa yhtenä jatkuvana liikkeenä? Kuka arvioi, saako poikkeus ketjussa jatkaa kulkuaan vai täytyykö se poistaa? Näihin kysymyksiin katsoo juuri hybridresourcingin kypsyysmittaus, seitsemän ulottuvuuden yli, ennen kuin voidaan sanoa mitään tietystä ketjusta.
Se, voiko ketju toimia organisaatiossanne, on valmiutta koskeva kysymys. Se, mikä osa tämän ketjun työstä on todella siirrettävissä AI:lle, on eri kysymys, ja siihen vastaa FTE TO AI:n työscanaus, joka laskee tehtäväkohtaisesti, mikä osa työstä soveltuu siirrettäväksi. Mitä tämä vaatii organisaatiolta, kun AI ei enää vastaa yksittäiseen tehtävään vaan suorittaa prosessin, on kuvattu sivulla mitä työtä suorittavien AI-agenttien käyttöönotto vaatii organisaatioltanne. Ennen kuin tähän kysymykseen kannattaa vastata mielekkäästi, on selvitettävä, ovatko perustavat kerrokset kunnossa — ja siitä tämä mittaus alkaa.
Hybridresourcingin kypsyysmittaus on rakenteilla. Ken haluaa tietää, miten viisi tasoa seitsemän ulottuvuuden yli suhteutuvat omaan organisaatioon, ja miten plot-kierros tekee näkyväksi hajonnan kollegoiden välillä, voi ilmoittautua jonotuslistalle. Tulosta ei ole nyt tarjolla; on kuitenkin paikka, josta kuulee ensimmäisenä, kun se on.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.