Umělá inteligence se v posledních letech stala jedním z nejdiskutovanějších témat v IT. Většina organizací však stále hledá odpověď na mnohem praktičtější otázku: Jak může AI pomoci řešitelům ticketů už dnes?
Právě na to se zaměří náš workshop. Nepůjde o teorii ani o vize vzdálené budoucnosti. Uvidíte reálné AI agenty navržené pro každodenní provoz Service Desku, kteří pomáhají řešit konkrétní provozní situace. Představíme jak během několika vteřin shromáždit informace o zařízení ze CMDB. Ukážeme jak rozpoznat podobnosti mezi zdánlivě nesouvisejícími incidenty. Velkou pozornost věnujeme kvalitě dat a znalostí. Automaticky zkontrolujeme kvalitu popisu řešení při uzavírání ticketů. Automaticky vytvoříme návrh znalostních článků.
Přijďte se podívat, jak mohou AI agenti převzít rutinní práci, odhalovat skryté souvislosti a proměnit Service Desk z reaktivní podpory na inteligentní službu řízenou daty a znalostmi.
Znáte tu situaci, kdy řešitel dostane hlášení o zařízení a první, co potřebuje, je vědět, s čím má tu čest — jaký je to typ zařízení, kdo ho vlastní, jestli s ním v minulosti nebyly problémy. Téměř každý incident začíná ručním pátráním po systému: otevřít CMDB, dohledat konfiguraci, zvlášť projít historii problémů na tomtéž zařízení, a teprve pak se pustit do samotného řešení. V kritických situacích je to čas, který se v tu chvíli nedá ztrácet. Ukážeme vám, jak agent tuhle práci udělá za řešitele: na vyžádání sesbírá technické údaje o zařízení z CMDB, dohledá jeho problémovou historii a obojí předloží přímo u incidentu. Řešitel tak nezačíná od nuly, ale s hotovým přehledem v ruce, a může se rovnou soustředit na řešení místo hledání podkladů.
Dostali jste se někdy do situace, kdy deset lidí nahlásí deset zdánlivě různých problémů — a jen zkušené oko pozná, že za nimi stojí stejná příčina? Každé hlášení zvlášť vypadá jako izolovaná záležitost, kterou řešitel vyřídí a zapomene; teprve když se podobná hlášení sečtou, je vidět, že jde o jeden a tentýž problém. Bez pomoci tahle souvislost často vyjde najevo až tehdy, když je škoda hotová a incidentů se nahromadilo příliš mnoho na to, aby to byla náhoda. Ukážeme vám agenta, který podobná hlášení najde sám, shrne, v čem se shodují, a navrhne řešiteli založit Incident, do kterého se všechna související hlášení propojí — ten poslední krok, potvrzení, je vždy na řešiteli. Získáte tak systémovou příčinu na stole dřív, než naroste do velkého incidentu, a řešitelé přestanou stejný problém řešit opakovaně od začátku.
Setkali jste se s tím, že se ticket zavře s popisem řešení „vyřešeno" nebo „hotovo" — a za týden nikdo neví, co se vlastně stalo? Takový záznam je k ničemu pro reporting, nedá se z něj udělat znalostní článek a při auditu jen přidělává práci. Problém je v tom, že se to zjistí vždycky až zpětně, kdy je pozdě cokoli opravit. Ukážeme vám agenta, který kontroluje kvalitu popisu v okamžiku uzavření ticketu — ne po něm. Když operátor vyplní řešení, agent posoudí, jestli obsahuje dost detailu, popisuje konkrétní provedenou akci a uvádí příčinu problému; pokud ne, uzavření se zablokuje a operátor dostane rovnou zpětnou vazbu, co má doplnit. Žádné čekání na nadřízeného, žádná obecná hláška o chybě. Získáte tak konzistentní dokumentaci napříč celým týmem od prvního dne, bez školení a bez ručního dohledu nad každým ticketem.
Stalo se vám, že řešitel vyřeší incident, zavře ticket a znalost, jak se to dělá, mu zůstane jen v hlavě? Napsat z toho pořádný znalostní článek je práce navíc, na kterou v provozu skoro nikdy nezbyde čas — a tak se stejný problém za měsíc řeší od začátku znovu, možná i jiným člověkem. Ukážeme vám agenta, který z informací na vyřešeném incidentu sám sestaví návrh znalostního článku: doplní krátké shrnutí a klíčová slova, aby byl článek dohledatelný a pošle ho do schvalovacího procesu, kde ho znalostní tým jen zkontroluje a publikuje. Získáte tak rostoucí znalostní bázi bez toho, aby na ni řešitelé museli aktivně myslet a psát ji navíc ke své běžné práci.
Znáte to — nový ticket přistane ve frontě a než se dostane ke správnému člověku, musí ho nejdřív někdo přečíst, odhadnout, do které skupiny patří, a pak ještě zvážit, kdo z týmu má zrovna kapacitu? Tahle úvaha se dělá ručně u každého jednoho ticketu — a v provozu se řídí spíš pocitem než skutečným vytížením, takže někdo končí přetížený, zatímco jinému leží fronta prázdná. Ukážeme vám agenta, který tohle rozhodování udělá za operátora: podle názvu a popisu ticketu vybere nejvhodnější skupinu, zjistí, kolik aktivních ticketů má kdo z jejích členů na starosti, a přiřadí ticket tomu, kdo je na tom právě nejlíp. Skupina i vlastník se zapíšou přímo na ticket, bez jediného kliknutí navíc. Získáte tak rovnoměrně rozložené vytížení týmu a rychlejší start práce na každém novém ticketu.
Znáte tu chvíli, kdy operátor otevře ticket a musí znovu přečíst celou historii, odhadnout, v jakém je uživatel rozpoložení, a teprve pak začít psát odpověď tak, aby seděla tónem i obsahem? U desítek ticketů denně je to čas, který se sčítá, a přitom jde často o odpovědi, které se svým obsahem hodně podobají. Ukážeme vám agenta, který tuhle přípravu udělá za operátora: z názvu, popisu a historie komentářů vyhodnotí, jak je uživatel naladěný a jakým tónem s ním komunikovat, a na základě toho připraví konkrétní návrh odpovědi, kterou operátor jen zkontroluje a odešle. Získáte tak rychlejší a konzistentnější komunikaci s uživateli, aniž by operátor musel s každým ticketem začínat psaní od prázdné stránky.
Dostal se váš tým někdy do situace, kdy řešitel problému dostane symptom a před sebou hodiny ruční práce — projít historii souvisejících změn, projít incidenty na stejné službě, a z toho všeho si teprve sám sestavit, co mohlo být příčinou? U komplexní infrastruktury je to práce, která snadno zabere celý den a výsledek stejně záleží na tom, jestli řešitel nic nepřehlédl. Ukážeme vám agenta, který tuhle rešerši udělá za něj: na jedno kliknutí dohledá změny a incidenty na stejné službě nebo komponentě, porovná je se symptomy aktuálního problému a vrátí až tři nejpravděpodobnější hypotézy příčiny, každou s konkrétními kroky, jak ji ověřit. Výsledek se zapíše přímo k problému, seřazený podle pravděpodobnosti, připravený k posouzení týmem L3. Získáte tak výrazně kratší čas do vyřešení problému, protože řešitel nezačíná pátrání od nuly, ale rovnou u ověřování konkrétních hypotéz.
V případě zájmu o účast na daném workshopu vyplňte registrační formulář