ftetoai На списъка с чакащи

Kennisbank

AI и регистрирането и приоритизирането на IT инциденти

Въпросът

Постъпва сигнал: потребител не може да влезе в системата, принтер не работи, сървър дава съобщения за грешка. Някой от сервизния деск превръща това в тикет, избира категория и определя спешността. Може ли AI да поеме това? До голяма степен да, с едно важно изключение, което варира според компанията.

Защо тази работа се поддава добре на AI

Три оси са决定 определящи: обем, пространство за преценка и контакт с клиента.

Обемът е висок. Сервизен деск обработва ежедневно десетки до стотици сигнали, и много от тях са вариации на малък брой познати проблеми: забравена парола, липса на достъп до споделена папка, лаптоп не се стартира. При висок обем и повторяемост дадена задача по дефиниция е подходяща за автоматизиране, защото моделът се учи от модели, които се повтарят често.

Пространството за преценка е ограничено. Спешността и категорията обикновено следват от дърво на решенията: колко потребители са засегнати, има ли обходно решение, коя система е засегната. Точно това е видът работа, в която текстовите модели са добри: да прочетат сигнал, да извлекат характеристиките и да ги сравнят с модел за категоризация. Това, с което AI може да се справи днес, е текст — самите сигнали, често въведени със свободни формулировки от потребителя, и превръщането им обратно в структуриран тикет.

Контактът с клиента е функционален, не отношенчески. Потребител, който съобщава за неизправност, иска най-вече тя да бъде поета, не да се завърже разговор. Това е различно, щом нещо се обърка или стане чувствително — вижте за това и как се комуникира неизправност към потребителите, защото това е друга задача с друг профил.

Къде е границата

Физическият компонент не играе роля: това е административна работа пред екран, не действие върху оборудване. Разходите от грешки са средни. Погрешно приоритизиран сигнал рядко води до пряка вреда, но при системи, попадащи под изисквания за съответствие — финансова система, картон на пациент — това е различно, и оста съответствие тук отчита резултат по-висок от средния. Неизправност в среда със законово задължение за уведомяване изисква документирана причина за класификацията, не само етикет.

Слабото място е креативността, и точно затова това не е пълно поемане. Сигнал, който не се вписва в познатия модел — нова комбинация от симптоми, система, която за пръв път спира да работи, потребител, който описва проблема неясно — изисква някой, който мисли, а не просто класифицира. Тук е необходим надзор: AI предлага категория и спешност, човек одобрява или коригира, с обосновка. Това е различна организация от пълно поемане, и е и най-разпространената практика при компаниите, които вече работят с това.

Пример за разликата между компании

В компания с малък, лесно обозрим ландшафт от приложения и няколкостотин потребители, деветдесет процента от сигналите са повторение на нещо, което вече се е случвало сто пъти. Там модел с добър модел за категоризация може самостоятелно да обработи по-голямата част от приема, като човек вижда само изключенията.

В компания с много остарели системи, софтуер по поръчка и история на сливания, моделът е по-малко предвидим. Сигналите са по-разнообразни, категориите са по-слабо разграничени, а вероятността сигнал да попадне извън познатия модел е по-голяма. Там по-голяма част от работата остава при човек, не защото AI не би искал да я върши, а защото входните данни са твърде неструктурирани, за да се направи от тях нещо надеждно автоматично.

Условието следователно не е технологията, а приемът: структурирани формуляри за прием и разработен модел за категоризация на инциденти до голяма степен определят колко от тази работа е прехвърляема днес. Без тези две неща по-голямата част от работата остава ръчна, като AI е помощно средство, а не изпълнител.

Какво не е това

Това не е съвет за персонал и не е обосновка за съкращаване на екип на сервизен деск. Дали и как една организация извежда персонални последици от променящата се работа, е решение на работодателя, и за това важат собствени законови изисквания; вижте за необходимата грижа точките за внимание при съкращаване на функции. Тази страница описва само какво се случва със самата задача.

Полезно е също тази задача да не се разглежда отделно от останалата част от IT операциите. Регистрацията на инциденти е свързана с работа като мониторинга на системна производителност, която често дава ранните сигнали, преди да има сигнал за инцидент, и с управленски задачи като извършването и проверката на резервни копия или поддържането на основни данни актуални, които имат същата комбинация от висок обем и ограничено пространство за преценка. Който иска да знае за целия IT отдел къде вече е изместването, най-добре разглежда всички задачи заедно, не един процес за тикети.

Какво можете да направите сега

Резултатът за вашия собствен сервизен деск зависи от това колко от вашите сигнали попадат в разпознаваеми модели и колко добре е структуриран вече вашият прием. Това варира според компанията и не може да се обобщи с фиксирано правило.

Безплатният quickscan на FTE TO AI дава първоначална индикация за това: дванадесет въпроса, без акаунт, с индикация коя част от часовете във вашия профил може да бъде поета от AI днес. Пълният работен анализ, който изчислява работата на цяла компания задача по задача до fte капацитет, все още се разработва.

KIPPde assistent van de werkscan

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.