Ilmoitus tulee sisään: käyttäjä ei pääse kirjautumaan, tulostin ei toimi, palvelin antaa virheilmoituksia. Servicedeskin työntekijä muuttaa tämän tiketiksi, valitsee kategorian ja määrittää kiireellisyyden. Voiko tekoäly ottaa tämän haltuunsa? Suurelta osin kyllä, mutta yhdellä tärkeällä poikkeuksella, joka vaihtelee yrityksittäin.
Kolme akselia ratkaisee: volyymi, harkintavara ja asiakaskontakti.
Volyymi on suuri. Servicedesk käsittelee päivittäin kymmeniä tai satoja ilmoituksia, ja moni niistä on muunnelma pienestä joukosta tunnettuja ongelmia: unohtunut salasana, ei pääsyä jaettuun kansioon, kannettava ei käynnisty. Kun volyymi on suuri ja toistuvuus korkea, tehtävä soveltuu määritelmällisesti automatisoitavaksi, koska malli oppii usein toistuvista kaavoista.
Harkintavara on rajallinen. Kiireellisyys ja kategoria seuraavat yleensä päätöspuusta: kuinka moni käyttäjä on kärsinyt, onko olemassa väliaikaisratkaisua, mikä järjestelmä on kyseessä. Tämä on juuri sitä työtä, jossa tekstimallit ovat hyviä: ilmoituksen lukeminen, ominaisuuksien poimiminen ja niiden vertaaminen kategorisointimalliin. Se, mihin tekoäly tänään pystyy, on teksti — itse ilmoitukset, jotka käyttäjä usein kirjoittaa vapaamuotoisesti, ja niiden kääntäminen takaisin jäsennellyksi tiketiksi.
Asiakaskontakti on toiminnallinen, ei suhteellinen. Häiriöstä ilmoittava käyttäjä haluaa ennen kaikkea, että asia otetaan käsittelyyn, ei että syntyy keskustelu. Tilanne on toinen, kun jotain menee pieleen tai asia muuttuu arkaluontoiseksi — katso siitä myös, miten häiriöstä viestitään käyttäjille, sillä se on eri tehtävä eri profiililla.
Fyysisellä osatekijällä ei ole roolia: tämä on hallinnollista työtä näytön ääressä, ei toimenpiteitä laitteille. Virhekustannukset ovat keskimääräisiä. Väärin priorisoitu ilmoitus johtaa harvoin välittömään vahinkoon, mutta compliance-alaisissa järjestelmissä — talousjärjestelmä, potilastietojärjestelmä — tilanne on toinen, ja compliance-akseli saakin täällä keskimääräistä korkeamman pisteen. Häiriö ympäristössä, jossa on lakisääteinen ilmoitusvelvollisuus, vaatii dokumentoidun perustelun luokittelulle, ei pelkkää tunnistetta.
Heikko kohta on luovuus, ja juuri siksi tämä ei ole täydellinen haltuunotto. Ilmoitus, joka ei sovi tunnettuun kaavaan — uusi oireyhdistelmä, järjestelmä, joka kaatuu ensimmäistä kertaa, käyttäjä, joka kuvaa ongelman epäselvästi — vaatii jonkun, joka ajattelee sen sijaan että luokittelee. Siihen kuuluu valvonta: tekoäly ehdottaa kategoriaa ja kiireellisyyttä, ihminen hyväksyy tai korjaa, perustellusti. Tämä on eri järjestely kuin täydellinen haltuunotto, ja se on myös yleisin käytäntö yrityksissä, jotka jo työskentelevät tämän kanssa.
Yrityksessä, jolla on pieni, hallittava sovellusympäristö ja muutama sata käyttäjää, yhdeksänkymmentä prosenttia ilmoituksista on toistoa jostain, mikä on jo tapahtunut sata kertaa aiemmin. Siellä hyvällä kategorisointimallilla varustettu malli pystyy hoitamaan suurimman osan käsittelystä itsenäisesti, ihmisen käsitellessä vain poikkeukset.
Yrityksessä, jolla on paljon vanhoja järjestelmiä, räätälöityä ohjelmistoa ja fuusioiden historiaa, kaava on ennustettavampi vähemmän. Ilmoitukset ovat monimuotoisempia, kategoriat vähemmän tarkkarajaisia, ja todennäköisyys, että ilmoitus jää tunnetun kaavan ulkopuolelle, on suurempi. Siellä suurempi osa työstä jää ihmiselle, ei siksi ettei tekoäly haluaisi tehdä sitä, vaan koska syöte on liian jäsentymätöntä muuttuakseen automaattisesti luotettavaksi.
Reunaehto ei siis ole tekniikka vaan intake: jäsennellyt intake-lomakkeet ja pitkälle viety häiriöiden kategorisointimalli määrittävät suurelta osin, kuinka paljon tästä työstä on jo tänään siirrettävissä. Ilman näitä kahta suurin osa jää käsityöksi, tekoälyn toimiessa apuvälineenä suorittajan sijaan.
Tämä ei ole henkilöstöneuvo eikä perustelu servicedesk-tiimin supistamiselle. Se, tekeekö ja miten organisaatio henkilöstöllisiä johtopäätöksiä muuttuvasta työstä, on työnantajan päätettävissä, ja siihen sovelletaan omia lakisääteisiä vaatimuksia; katso tähän liittyvästä huolellisuudesta toimien poistamiseen liittyvät huomioitavat seikat. Tämä sivu kuvaa vain sitä, mitä itse tehtävälle tapahtuu.
On myös hyödyllistä olla erottamatta tätä tehtävää muusta IT-toiminnasta. Häiriöiden kirjaaminen liittyy sellaiseen työhön kuin järjestelmän suorituskyvyn seuranta, joka usein antaa varhaiset signaalit ennen kuin ilmoitusta edes on, sekä ylläpitotehtäviin kuten varmuuskopioiden tekeminen ja tarkistaminen tai perustietojen ajan tasalla pitäminen, joissa on sama yhdistelmä suurta volyymia ja rajallista harkintavaraa. Jos haluaa selvittää koko IT-osaston osalta, missä muutos jo tapahtuu, kannattaa tarkastella kaikkia tehtäviä yhdessä, ei yhtä tikettiprosessia.
Oman servicedeskinne lopputulos riippuu siitä, kuinka moni ilmoituksistanne osuu tunnistettaviin kaavoihin ja kuinka hyvin intake on jo jäsennelty. Tämä vaihtelee yrityksittäin, eikä siihen ole kiinteää nyrkkisääntöä.
FTE TO AI:n maksuton pikatesti antaa siihen ensimmäisen suuntaa-antavan arvion: kaksitoista kysymystä, ilman tiliä, ja arvion siitä, kuinka suuri osa profiilinne tunneista on jo tänään tekoälyn siirrettävissä. Koko yrityksen työn tehtävä kerrallaan henkilötyövuosikapasiteetiksi laskeva täydellinen työanalyysi on vielä rakenteilla.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.