Beérkezik egy jelzés: egy felhasználó nem tud bejelentkezni, egy nyomtató nem működik, egy szerver hibaüzeneteket ad. Valaki a szervizdesk-en ezt átalakítja egy jegybe, kiválaszt egy kategóriát és meghatározza a sürgősséget. Át tudja ezt venni az AI? Nagyrészt igen, egy fontos kivétellel, amely vállalatonként eltérő.
Három tengely a döntő: a mennyiség, a mérlegelési tér és az ügyfélkapcsolat.
A mennyiség magas. Egy szervizdesk naponta tucatnyi-száznyi jelzést kezel, és ezek nagy része variáció egy kis számú ismert probléma köré: elfelejtett jelszó, nincs hozzáférés egy megosztott mappához, a laptop nem indul el. Nagy mennyiségnél és ismétlődésnél egy feladat definíció szerint alkalmas az automatizálásra, mert egy modell megtanulja a gyakran ismétlődő mintákat.
A mérlegelési tér korlátozott. A sürgősség és a kategória általában egy döntési fából következik: hány felhasználót érint, van-e átmeneti megoldás, melyik rendszerről van szó. Ez pontosan az a fajta munka, amiben a szövegmodellek jók: egy jelzés elolvasása, a jellemzők kinyerése belőle, és egy kategorizálási modellel való összevetése. Amit az AI ma ebben kezelni tud, az a szöveg — a jelzések maguk, amelyeket a felhasználó gyakran szabad megfogalmazásban ír, és ennek visszafordítása egy strukturált jegybe.
Az ügyfélkapcsolat funkcionális, nem kapcsolati jellegű. Egy felhasználó, aki egy üzemzavart jelez, elsősorban azt akarja, hogy foglalkozzanak vele, nem azt, hogy beszélgetés alakuljon ki. Ez másképp áll, amint valami rosszul megy vagy érzékennyé válik — lásd ehhez azt is, hogyan kommunikálják egy üzemzavar felhasználók felé történő közlését, mert ez egy másik feladat, más profillal.
A fizikai összetevő nem játszik szerepet: ez képernyő előtt végzett irodai munka, nem eszközön végzett fizikai beavatkozás. A hibaköltségek átlagosak. Egy hibásan priorizált jelzés ritkán vezet közvetlen kárhoz, de olyan rendszereknél, amelyekre megfelelőségi (compliance) előírások vonatkoznak — egy pénzügyi rendszer, egy betegdosszié — ez másképp áll, és a megfelelőség tengelye itt ezért az átlagosnál magasabbra pontoz. Egy üzemzavar egy törvényi bejelentési kötelezettséggel rendelkező környezetben rögzített indoklást igényel a besoroláshoz, nem csupán egy címkét.
A gyenge pont a kreativitás, és éppen ez az oka, hogy ez nem teljes átvétel. Egy jelzés, amely nem illik az ismert mintába — a szimptómák új kombinációja, egy rendszer, amely most esik ki először, egy felhasználó, aki a problémát homályosan írja le — olyan valakit igényel, aki gondolkodik, nem csak besorol. Ehhez felügyelet tartozik: az AI javasol egy kategóriát és sürgősséget, egy ember jóváhagyja vagy módosítja, indoklással. Ez más felépítés, mint a teljes átvétel, és ez a leggyakoribb gyakorlat azoknál a vállalatoknál is, amelyek már ezzel dolgoznak.
Egy vállalatnál, amelynek kis, jól áttekinthető alkalmazáslandzsája és néhány száz felhasználója van, a jelzések kilencven százaléka egy olyan dolog megismétlődése, amely már százszor előfordult. Ott egy modell egy jó kategorizálási modellel a bejövő jelzések legnagyobb részét önállóan kezelheti, egy emberrel, aki csak a kivételeket látja.
Egy vállalatnál, amelynek sok örökölt (legacy) rendszere, egyedi fejlesztésű szoftvere és fúziók története van, a minta kevésbé kiszámítható. A jelzések változatosabbak, a kategóriák kevésbé élesen elhatároltak, és nagyobb az esély arra, hogy egy jelzés kilép az ismert mintából. Ott a munka nagyobb része egy embernél marad, nem azért, mert az AI nem akarná elvégezni, hanem mert a bemenet túl strukturálatlan ahhoz, hogy belőle automatikusan valami megbízhatót lehessen csinálni.
A feltétel tehát nem a technika, hanem a bevétel (intake): a strukturált bevételi formanyomtatványok és egy kidolgozott incidens-kategorizálási modell nagyrészt meghatározzák, hogy ennek a munkának mekkora része adható át már ma. Ezek nélkül a munka nagy része kézi munka marad, az AI-val mint segédeszközzel, nem mint végrehajtóval.
Ez nem személyzeti tanács és nem alátámasztás egy szervizdesk-csapat leépítéséhez. Hogy egy szervezet von-e le és hogyan von le személyzeti következtetéseket a változó munkából, az a munkaadó dolga, és erre saját törvényi előírások vonatkoznak; lásd az ehhez tartozó gondosságot a funkciók megszüntetésénél alkalmazandó gondossági szempontoknál. Ez az oldal csak azt írja le, mi történik a feladattal magával.
Hasznos ezt a feladatot nem elszigetelten nézni a többi informatikai üzemeltetési munkától. Az incidensregisztráció összefügg olyan munkával, mint a rendszerteljesítmény monitorozása, amely gyakran korai jelzéseket ad, mielőtt egy jelzés megérkezik, és olyan üzemeltetési feladatokkal, mint a biztonsági mentések végrehajtása és ellenőrzése vagy az alapadatok naprakészen tartása, amelyek ugyanazt a nagy mennyiség és korlátozott mérlegelési tér kombinációt ismerik. Aki az egész informatikai osztály esetében szeretné tudni, hol van már elmozdulás, az legjobban az összes feladatot együtt vizsgálja, nem egyetlen jegykezelési folyamatot.
Az Ön saját szervizdeskjének eredménye attól függ, hogy jelzéseinek mekkora része esik felismerhető mintákba, és mennyire strukturált már a bevétele. Ez vállalatonként eltérő, és nem mondható meg egy fix ökölszabállyal.
Az FTE TO AI ingyenes gyorstesztje ehhez ad egy első indikációt: tizenkét kérdés, fiók nélkül, azzal az indikációval, hogy az Ön profiljában az órák mekkora része vehető át ma az AI által. A teljes munkateszt, amely egy egész vállalat munkáját feladatonként számolja át fte-kapacitásra, még fejlesztés alatt áll.
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.