Motnja je prijavljena, sistem za prijavo napak sveti rdeče, in uporabniki želijo vedeti: kaj se dogaja, koliko časa bo to še trajalo in kdaj bodo znova obveščeni. To je delo, ki ga vsak dan opravljajo sodelavci pomoči uporabnikom (servicedeska) in komunikacije. Vprašanje tukaj ni, ali lahko AI napiše besedilo, temveč ali lahko AI to specifično komunikacijsko delo samostojno prevzame. Odgovor: deloma, in to je močno odvisno od tega, za kakšno motnjo gre.
Naloga dosega visoko strukturiranost (4): prijava motnje pogosto sledi fiksnemu vzorcu — kaj je narobe, od kdaj, kateri sistemi so prizadeti, kakšen je pričakovani čas odprave. Ta vzorec je natanko tisto, kar lahko jezikovni model dobro izpolni, pod pogojem, da so osnovni podatki pravilni. Tudi fizičnost (5) ni ovira: ni potrebno nobeno dejanje v resničnem svetu, le besedilo, ki ga je treba poslati.
Nasproti temu stoji, da stik s strankami dosega nizko oceno (1). Gre po definiciji za komunikacijo z ljudmi, ki so pogosto že frustrirani, ker njihovo delo stoji. Ton, trenutek in natančnost sporočila določajo, ali se uporabniki počutijo slišane ali ravno nasprotno, prezrte. Ustvarjeno sporočilo, ki je vsebinsko pravilno, a napačno oceni nujnost, povzroči več škode kot brez sporočila.
Stroški napak (3) so zmerni, vendar ne nepomembni: napačen čas odprave ali status, ki se ne posodablja, spodkopava zaupanje in vodi v val nadaljnjih vprašanj — natanko delo, ki ga je bilo treba prihraniti. Skladnost s predpisi (4) je pomembna, kolikor incident spada pod dogovore SLA ali, v nekaterih sektorjih, obveznost prijave: takrat mora biti komunikacija dokazljivo pravočasno in po fiksnih standardih poslana. Prostor za presojo (2) in ustvarjalnost (2) sta nizki: malo je prostora za samostojno odločanje o tem, kaj se sporoča, gre v veliki meri za sledenje predlogi z aktualnimi podatki. Obseg (4) je visok: pri veliki motnji gre za sto ali tisoč uporabnikov, ki potrebujejo isto sporočilo, in ravno tam avtomatizacija sprosti čas.
Tri osi določajo sliko. Strukturiranost naredi to tehnično izvedljivo: če je status incidenta enolično zapisan v sistemu, lahko jezikovni model iz tega zgradi sporočilo po fiksni predlogi. Toda nizek stik s strankami to zavira — ne ker AI ne bi znal napisati pravilnega stavka, temveč ker je tveganje napačno časovno usklajenega ali napačno tonranega sporočila večje kot pri interni ali administrativni besedilu. In stroški napak povzročijo, da nadzor ostane potreben: posodobitev statusa, ki gre v obtok, preden je popravek potrjen, ali ki preveč optimistično oceni čas odprave, vodi v nove pritožbe namesto v manj pritožb.
Primer to naredi konkretno. Pri motnji v internem sistemu e-pošte, kjer je vpliv znan in je čas odprave razmeroma predvidljiv, lahko AI pripravi prvo obvestilo in vmesno posodobitev statusa na podlagi prijave napake, s sodelavcem, ki na kratko potrdi, preden se sporočilo pošlje. Pri motnji, ki vpliva na plačilno funkcionalnost strank, s finančnimi posledicami in negotovim časom odprave, je stvar drugačna: tam je potrebna človeška presoja o tem, kaj se pove in kaj ne, in kdaj.
Pri podjetju z zrelo statusno stranjo in sistemom za prijavo napak, ki samodejno izpolni pravilna polja, je delež, ki ga AI zmore, večji: besedilo lahko izhaja neposredno iz strukturiranih podatkov. Pri podjetju, kjer se motnje sporočajo ustno, v razpršenih sporočilih Slack ali prek IT-vodje, ki jih sam presoja, manjka strukturirana osnova in je malo tega, kar AI lahko samostojno pripravi. Prav tako šteje narava uporabnikov: interni sodelavci sprejmejo kratko, dejansko posodobitev; zunanje stranke s pogodbo in SLA pričakujejo ton in popolnost, ki prej terja človeški nadzor.
Ta naloga ni ločena od preostale verige incidentov. Ali je motnja učinkovito komunicirana, je odvisno od tega, kako dobro se spremljajo sistemske zmogljivosti — brez zanesljivega spremljanja ni aktualnega statusa za komuniciranje. Povezano je tudi s tem, kako je incident registriran in prioritiziran, saj to določa, kateri podatki so na voljo za osnovo sporočila. In v nekaterih primerih komunikacija poteka vzporedno z dejanskim reševanjem prvonivojskega IT-incidenta, pri čemer je posodobitev dobra le toliko, kolikor je dober dejanski napredek.
Konkretno: priprava besedila na podlagi fiksnih predlog, z aktualnim statusom incidenta kot vhodnim podatkom, je izvedljiva, takoj ko sta izpolnjena ta dva pogoja. Odločitev, kdaj se sporočilo pošlje, v kakšnem tonu in ali je čas odprave realistično formuliran, ostaja pri sodelavcu. To ni vmesna faza na poti do popolnega prevzema — to je struktura, ki ustreza tej vrsti komunikacije, dokler stroški napak zaradi neprimernega sporočila ostajajo večji od časa, potrebnega za preverjanje.
Če vas ta analiza pripelje do razmisleka o zaposlovanju sodelavcev pomoči uporabnikom ali komunikacije, velja, da zanje veljajo lastne zakonske zahteve glede dela in soodločanja; ta stran ne ponuja kadrovskega svetovanja in ni podlaga za odločitev o odpustitvi. Za širšo skrbnost pri spremembah delovnih mest glejte skrbnost pri ukinjanju delovnih mest.
Bi radi izvedeli, koliko komunikacije o motnjah v vašem lastnem podjetju danes že sodi znotraj teh pogojev? Brezplačni hitri test podjetja FTE TO AI vsebuje dvanajst vprašanj, ne zahteva računa in poda oceno, kolikšen delež ur v tem profilu je danes mogoče prevzeti z AI. Celovita delovna analiza, z obsežno analizo nalog po posameznih ekipah, je še v izdelavi — tega tukaj zavestno še ne ponujamo.
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.