Как построить "умный" интерфейс для поиска информации из разрозненных источников для службы service desk

1. База знаний
для службы техподдержки
презентация прототипа

2. 1
ПРОБЛЕМЫ:
 Службы техподдержки используют
несколько багтрекеров для разных
продуктов/услуг.
 Много неструктурированной
информации в разных источниках:
багтрекеры, FAQ, документация, статьи,
форумы.
 Параметры продуктов/услуг,
существенные для поиска решений,
меняются со временем.
 В ПО и в головах у людей не разделяются
инциденты (конкретные ситуации)
и проблемы (факторы, приводящие
к инцидентам).
Проблемы и решения
РЕШЕНИЯ:
 Создать единую концептуальную модель всей
информации, относящейся к техподдержке – в том числе
модель инцидента, модель проблемы. Выявить смысловые
признаки инцидентов и проблем, которые можно
использовать для поиска решений.
 Создать единую программную витрину для работы с этой
информацией в терминах концептуальной модели.
 Создать инструменты автоматического/ручного описания
смысла хранимой информации – перейти от данных
к знаниям.
 Создать новые инструменты поиска решений, которые
помогут как сотрудникам техподдержки, так и клиентам.

3. 2До и после
База данных
инцидентов
(багтрекер 1)
База данных
инцидентов
(багтрекер 2)
База данных
инцидентов
(багтрекер N)
Документация
Форумы
Статьи
До:
Сотрудник техподдержки использует множество инструментов
и должен сам ориентироваться в их содержимом.
Основной инструмент поиска – поиск по ключевым словам.

4. 2До и после
После:
База данных
инцидентов
(багтрекер 1)
База данных
инцидентов
(багтрекер 2)
База данных
инцидентов
(багтрекер N)
Документация
Форумы
Статьи
Онтологическая модель знаний
SD/HD
Витрина знаний для поиска
решений
• Варианты решений
• Возможные причины
• Похожие инциденты
• Дополнительная
документацияСотрудник техподдержки использует одну
точку входа для поиска любой информации.
Инструменты поиска позволяют конструировать
логические условия и получать точные ответы
на запросы.

5. 3Как это работает?
Представим компанию, занимающуюся обслуживанием оргтехники (принтеры, сканеры, МФУ).
Составим «семантический портрет» типичного инцидента:
Здравствуйте! Я приобрела в вашей компании принтер. Через неделю после
начала работы я стала замечать, что при включении принтера он не подает
никаких признаков жизни (не горят индикаторы, не стартуют ролики).
Но через 3-5 минут принтер становится доступен для печати.
Что мне делать в таком случае? Помогите, пожалуйста!
Вид продукта: принтер
Состояние: включен
(или Ситуация:
при включении)
Признаки
неисправности:
 не горят индикаторы
 не стартуют ролики
=> нарушена функция:
инициализация
устройства
Выполняется функция:
печать
Характеристика функции:
Выполняется с задержкой
Система анализа текста может выделить
семантические признаки и маркировать
инцидент в соответствии с ними

6. 4Ядро концептуальной модели
Тип продукта
(принтер, МФУ…)
Функция
(печать, сканирование…)
Состояние продукта
(включен, индикатор горит,
лоток открыт…)
Тип продукта
выполняет функцию
Тип продукта
может находиться
в состоянии
Конкретный
продукт в ситуации
Успешно
выполняется
функция
Нарушено
выполнение
функции
Характеристика
выполнения
функции
Продукт находится
в состоянии
Инцидент
Проблема
Статья
Здесь представлен фрагмент
одного из вариантов модели.
Реальная модель создается
для конкретного заказчика
с учетом специфики сферы
его деятельности.

7. 5Способ использования
Один из способов использования такой модели – инструмент помощи сотруднику поддержки (клиенту).
В интерфейс существующего багтрекера можно встроить форму, в которой пользователь сможет быстро
охарактеризовать суть проблемы:
1) Выбрать тип устройства 2) Указать состояние устройства
набор доступных опций зависит от типа устройства
3) Указать состояние выполнения функций
Система проведет поиск решений
среди всех материалов
базы знаний:
 других инцидентов,
 выявленных ранее
и обобщенных проблем,
 статей, документации и др.

8. 6Способ использования
Система найдет материалы с похожими семантическими признаками и выведет их:
Кроме того, она определит признаки, которыми еще обладают найденные материалы, и на этом основании
предложит уточнить вопрос:

9. 7Процесс создания системы
1. Анализ предметной области, обследование бизнес-процесса заказчика
2. Выделение типовых моделей проблемных ситуаций,
с которыми имеет дело служба поддержки
3. Создание концептуальной модели (включая модели проблемных ситуаций)
в нашем ПО
4. Интеграция с багтрекерами и другими источниками информации.
Создание средств семантического описания элементов информации
в соответствии с моделью – структурирование знаний.
5. Создание инструментов использования базы знаний:
встраивание в существующее ПО интерфейсов, соответствующих
функциональным потребностям заказчика, или создание новых приложений.
6. Обучение специалистов заказчика работе с системой.