Přichází hlášení: uživatel se nemůže přihlásit, tiskárna nefunguje, server hlásí chybová hlášení. Někdo na servicedesku to převede na tiket, vybere kategorii a určí naléhavost. Může to převzít AI? Do značné míry ano, s jednou důležitou výjimkou, která se liší podle firmy.
Rozhodující jsou tři osy: objem, prostor pro úsudek a kontakt s klientem.
Objem je vysoký. Servicedesk denně zpracovává desítky až stovky hlášení, a mnohá z nich jsou variace na malý počet známých problémů: zapomenuté heslo, chybějící přístup ke sdílené složce, notebook se nespustí. Při vysokých objemech a opakování je úloha z definice vhodná k automatizaci, protože model se učí z opakujících se vzorců.
Prostor pro úsudek je omezený. Naléhavost a kategorie většinou vyplývají z rozhodovacího stromu: kolik uživatelů je postiženo, existuje náhradní řešení, o jaký systém se jedná. To je přesně druh práce, ve kterém jsou textové modely dobré: přečíst hlášení, vytáhnout z něj charakteristiky a porovnat s kategorizačním modelem. Co AI dnes zvládá, je text — samotná hlášení, často napsaná uživatelem volnou formou, a jejich zpětný převod do strukturovaného tiketu.
Kontakt s klientem je funkční, nikoli vztahový. Uživatel, který nahlásí poruchu, chce především, aby se s tím něco udělalo, ne aby vznikl rozhovor. To se liší, jakmile se něco pokazí nebo je situace citlivá — viz k tomu také, jak probíhá komunikace o poruše směrem k uživatelům, protože to je jiná úloha s jiným profilem.
Fyzická složka nehraje roli: jde o administrativní práci u obrazovky, nikoli o zákrok na zařízení. Náklady na chybu jsou průměrné. Chybně prioritizované hlášení jen zřídka vede k přímé škodě, ale u systémů, na které se vztahuje compliance — finanční systém, zdravotnická dokumentace pacienta — je to jiné, a osa compliance zde tedy skóruje nadprůměrně. Porucha v prostředí se zákonnou ohlašovací povinností vyžaduje zaznamenaný důvod pro zařazení, nikoli jen štítek.
Slabým místem je kreativita, a to je přesně důvod, proč se nejedná o úplné převzetí. Hlášení, které nezapadá do známého vzorce — nová kombinace symptomů, systém, který vypadl poprvé, uživatel, který problém popisuje nejasně — vyžaduje někoho, kdo přemýšlí, nikoli jen zařazuje. K tomu patří dohled: AI navrhne kategorii a naléhavost, člověk to schválí nebo upraví, s odůvodněním. To je jiné uspořádání než úplné převzetí, a je to také nejběžnější praxe u firem, které s tím již pracují.
Ve firmě s malým, přehledným portfoliem aplikací a několika sty uživateli je devadesát procent hlášení opakováním něčeho, co se už stokrát vyskytlo. Tam může model s dobrým kategorizačním modelem samostatně zvládnout většinu příjmu hlášení, přičemž člověk vidí jen výjimky.
Ve firmě s mnoha legacy systémy, softwarem na míru a historií fúzí je vzorec méně předvídatelný. Hlášení jsou rozmanitější, kategorie jsou méně ostře vymezené a pravděpodobnost, že hlášení nezapadne do známého vzorce, je vyšší. Tam zůstává větší část práce na člověku, nikoli proto, že by to AI nechtěla dělat, ale protože vstup je příliš nestrukturovaný, aby se z něj automaticky dalo vytvořit něco spolehlivého.
Rozhodujícím předpokladem tedy není technika, ale příjem hlášení: strukturované vstupní formuláře a propracovaný kategorizační model pro incidenty do velké míry určují, kolik z této práce je dnes již převoditelné. Bez těchto dvou věcí zůstává většina práce ruční, s AI jako nástrojem, nikoli jako tím, kdo úlohu vykonává.
Toto není personální poradenství ani podklad pro zmenšování týmu servicedesku. Zda a jak organizace vyvodí personální důsledky z proměňující se práce, je na zaměstnavateli, a platí pro to vlastní zákonné požadavky; k pečlivosti, která k tomu patří, viz body, na které je třeba dát pozor při rušení funkcí. Tato stránka popisuje pouze to, co se děje se samotnou úlohou.
Je také užitečné nevnímat tuto úlohu odděleně od zbytku IT provozu. Evidence incidentů souvisí s prací jako monitorování výkonu systémů, která často dává včasné signály dříve, než hlášení vůbec vznikne, a se správcovskými úlohami jako provádění a kontrola záloh nebo udržování kmenových dat aktuálních, které mají stejnou kombinaci vysokého objemu a omezeného prostoru pro úsudek. Kdo chce pro celé IT oddělení zjistit, kde už posun nastal, udělá nejlépe, když se podívá na všechny úlohy najednou, ne na jeden proces s tikety.
Výsledek pro váš vlastní servicedesk závisí na tom, kolik z vašich hlášení zapadá do rozpoznatelných vzorců a jak dobře je již strukturován váš příjem hlášení. To se liší podle firmy a nelze to vyjádřit pevným pravidlem.
Bezplatný quickscan od FTE TO AI k tomu dává první indikaci: dvanáct otázek, bez nutnosti účtu, s indikací, jakou část hodin ve vašem profilu je dnes možné převést na AI. Kompletní pracovní scan, který propočítá práci celé firmy úlohu po úloze na fte kapacitu, je ještě ve výstavbě.
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.