Рефлексивная оценка использования текстовой аналитики в корпоративной ИТ-среде

Введение

В любой крупной корпоративной организации есть ИТ-отдел, который обслуживает остальную часть компании с любыми компьютерными или технологическими запросами. Однако процесс запроса помощи в ИТ-отделе посредством телефонного запроса или подачи онлайн-заявок может быть несколько запутанным, сбивающим с толку и даже разочаровывающим. Один из способов улучшить это - иметь модуль поиска, с помощью которого пользователь может ввести определенное количество слов, и система будет возвращать список статей базы знаний для рассмотрения пользователями. Это может быть невероятно полезно и даже может означать, что пользователю даже не нужно отправлять запрос в ИТ-отдел. Детали, лежащие в основе этой программы, должны быть оптимизированы для обеспечения скорости и точности, потому что в конечном итоге цель состоит в повышении эффективности использования и полезности каждого сотрудника в организации.

Некоторая предыстория

Когда я работаю служащим в крупной компании, неизбежно возникают моменты, когда мне нужно что-то попросить у ИТ-отдела. Это может означать, что мне нужно будет позвонить в службу ИТ по поводу чего-то вроде установки нового программного обеспечения, проблем с паролем или какого-либо сбоя системы. Понятно, что запросы такого типа требуют вмешательства человека и, следовательно, должны выполняться по телефону. Тем не менее, бывают случаи, когда мне нужно связаться с ИТ-командой по вопросам низкого приоритета, таким как вопросы с инструкциями, запросы на создание новых списков рассылки электронной почты или чтобы узнать, какие развертывания системы запланированы и какие проблемы. разрешение. Для таких запросов компаниям требуется отправить тикет запроса на обслуживание, который будет выполнен в течение 3–7 рабочих дней. Это типичный сценарий, соответствующий соглашениям об уровне обслуживания и матрицам приоритетов любого ИТ-отдела предприятия.

Однако, когда мой запрос довольно прост, на его исправление может уйти всего 10 минут (например: «как я могу настроить новый принтер?» Или «как мне запустить конкретный отчет?»), И тогда я сказал, что мне нужно подождать 3–7 рабочих дней, это может расстроить. Более того, процесс отправки билета через онлайн-систему продажи билетов может быть запутанным, запутанным и в равной степени разочаровывающим. Вспомните, когда вы в последний раз искали в Интернете информацию о том, как что-то сделать? Когда вам нужно было отправить запрос в Google и ждать ответа от 3 до 7 рабочих дней? Ответ в том, что этого никогда не было. Поэтому я спрашиваю себя, как это может быть лучше на моем рабочем месте?

Решение

Одно из решений, которое, как я считаю, принесет много пользы бизнесу, - это упростить интеграцию между страницей IT ‘Ticket Submission’ и репозиториями Business ‘Knowledge Bank’. В частности, чтобы реализовать метод прогнозной аналитики на основе ввода текста, аналогично тому, как Google прогнозирует страницы на основе всего нескольких набранных слов. Алгоритм интеллектуального анализа текста, лежащий в основе этого прогноза, должен брать каждое введенное слово в строку поиска, затем сравнивать эти слова с каждой страницей (будь то страница интрасети, внутренняя вики-страница, рабочая инструкция или внутренние страницы блога) и возвращаться к пользователю упорядоченный список, основанный на том, какие статьи будут наиболее полезны для запроса пользователя. По сути, он направляет пользователя в наиболее подходящее место для ответа на свой вопрос, прежде чем он даже задаст вопрос более крупной ИТ-команде. Однако, если на вопрос пользователя невозможно ответить из перечисленных статей, он все равно сможет отправить заявку обычным способом.

Специфика

Чтобы реализовать это решение с максимальной эффективностью, необходимо учитывать три предварительных условия:

  1. Достаточное количество документов и статей. Алгоритм прогнозирования документа бесполезен, если нет значительного количества материала, к которому он может запросить. Следовательно, должно быть достаточно написанных статей с практическими рекомендациями, а также стандартизированных рабочих инструкций, стандартных рабочих процедур и подтверждающих документов, которые могут быть проанализированы и возвращены пользователю по запросу.
  2. Оптимизированные, проиндексированные и сетевые репозитории. Каждая из этих статей должна находиться в сетевом расположении, доступном для всех сотрудников компании. Кроме того, его необходимо оптимизировать и проиндексировать таким образом, чтобы ускорить запрос и быстро вернуть результаты пользователю. Бессмысленно, если пользователю нужно подождать 30 секунд для выполнения запроса; это должно произойти почти мгновенно. Если Google может оценивать миллионы страниц за миллисекунды, то внутренний алгоритм вполне может анализировать тысячи страниц за секунды.
  3. Надежный алгоритм, улучшенный для скорости и точности. Выбранный алгоритм должен быть достаточно надежным, чтобы запрашивать важность термина во всех сетевых репозиториях и возвращать наиболее релевантные для пользователя документы. Требуется дальнейшее понимание бизнеса, чтобы определить, следует ли выбрать алгоритм кластеризации / иерархии, алгоритм распределения Дирихле или свернутую нейронную сеть. Однако достаточно сказать, что пользователи не захотят его использовать, если алгоритм не будет быстрым и точным.

В конечном итоге предлагаемое решение должно быть настроено таким образом, чтобы дать пользователю возможность найти ответ для себя; если запрос достаточно простой. Однако, если пользователь не может найти свой ответ в документах, то возможность отправить запрос все равно должна быть доступна.

Разница

И наоборот, чем это решение отличается от чат-бота? По сути, решение не настроено на общение с пользователем. Предполагается, что пользователь не хочет задавать четыре или пять вопросов, чтобы найти ответ, который он ищет, и у него нет свободного времени для обсуждения с роботом. Решение настроено таким образом, чтобы предсказывать и возвращать пользователю статьи базы знаний на основе важности и релевантности небольшого количества слов, отправленных в строку поиска. Очевидно, что одно или два слова будут иметь только определенный уровень точности, однако по мере того, как пользователь вводит больше слов, модель будет более точной в предсказании наиболее подходящей статьи. Тем не менее, пользователю не нужно вводить более десяти слов, чтобы найти идеальную статью для своего запроса.

Вывод

Иногда мне нужно отправить запрос в ИТ-отдел для очень простого запроса (например: «как мне настроить новый принтер?»), И для таких запросов нередко бывает, что запрос будет на рассмотрение в течение 3–7 рабочих дней. Это так, даже если запрос может быть решен в течение 10 минут. Этот процесс можно улучшить, используя текущие остаточные знания в рамках бизнеса (в форме информационных статей, СОП, инструкций и блогов) и направляя таких сотрудников, как я, в эти репозитории перед отправкой запроса в ИТ. Для этого в сети должно быть достаточно этих страниц, они должны быть оптимизированы, а алгоритм поиска должен быть быстрым и точным, чтобы предсказывать наиболее подходящую статью для пользователя. В случае доставки это решение сделает мою жизнь намного менее разочаровывающей и значительно сократит количество билетов для ИТ-команды; таким образом создавая беспроигрышный вариант для всех.

использованная литература

Azure 2019, Анализ текста, изображение, просмотрено 2 июня 2019 г., ‹https://azure.microsoft.com/en-in/services/cognitive-services/text-analytics/›.

QueryCare 2019, Системы управления контентом, изображение, просмотрено 2 июня 2019 г. ‹http://querycare.com/content-management-system/›.

WebTown 2019, eZ Platform Enterprise CMS, изображение, просмотрено 2 июня 2019 г., ‹https://www.webtown-group.com/ez-platform-enterprise-cms›.