Техника 3.3: Связывание

Важность связывания

Возможность связать заявку со статьей, в которой решается проблема, является важнейшим элементом методологии KCS. Данные, которые мы получаем из этого связывания, необходимы для многих аналитических действий Цикла Развития. Например, расчет повторного использования статей и/или анализ новых и известных проблем, или паттерны и тренды в использовании продукта. Привязка статей к заявкам чаще всего осуществляется внутри тикетной системы или с помощью дополнительно ПО, которое интегрируется с тикетной системой и базой знаний.

Ссылка на существующую статью

Если найдена статья с соответствующим решением, она должна быть привязана к заявке. Существующая статья может быть обновлена (улучшена) с учетом любых дополнительных симптомов или информации об окружении.

Если соответствующая статья не найдена в базе знаний, следует создать новую статью. В этом случае мы создаем WIP-статью, в которой есть слова и фразы, которые мы или клиент впервые использовали для поиска (поиск — это создание), или, если если клиент уже создал заявку и описал эти симптомы в ней. WIP также должен содержать заметки, которые мы делаем в процессе поиска и решения проблемы. Теперь все, что нам нужно сделать, это обновить поле Решения (и поле Причины, если это необходимо), проверить релевантность окружения и перевести WIP в статус Draft.

Ссылки на другие источники информации

Ни один ресурс не может содержать все знания, необходимые для решения всех проблем. Эмпирическое правило при создании статьи KCS заключается в том, чтобы разместить ее на одной странице и вставить гиперссылки на другие статьи и/или определенные разделы онлайн-документации (рабочие инструкции, документы политики, руководства по продуктам, руководства по диагностике). Поскольку статьи KCS/СОЗ написаны в контексте клиента, статьи могут выступать в качестве контекстно-зависимого индекса для других ресурсов. Такой подход устраняет избыточность и необходимость хранения информации в нескольких разных местах.

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

Лучшей практикой при наличии нескольких источников информации является предоставление унифицированной возможности поиска: единый поиск по нескольким базам данных. В большинстве инструментов поиска можно установить предпочтения для определения приоритета источников данных, чтобы в первую очередь выполнялся поиск в текущей базе знаний и предпочитаемых вторичных ресурсах. Также может быть полезно предоставить сотрудникам поддержки возможность выбирать источники, в которых они хотят вести поиск.

Ссылки на контент, не относящийся к KCS

Поскольку за последние несколько лет технология поисковых систем улучшилась, многие организации теперь могут индексировать и выполнять поиск в нескольких репозиториях или базах данных с различными типами контента. В этой среде ссылка на контент, не являющийся базой знаний, которая решает проблему, является разумной, если выполняются следующие критерии:

Информация фиксируется в поддерживаемом репозитории или базе данных.
Конкретное решение или ответ (предложение или абзац) может быть найден поисковой системой.
Контент доступен для аудитории статьи (могут быть внутренние или внешние пользователи).
Контент находится в контексте аудитории, которая его ищет (они могут найти его, используя свои слова и фразы, и они могут его использовать и/или понять).

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

Управление версиями статей

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

Вот несколько мыслей о том, как это сделать.

Зафиксируйте решение, предоставленное клиенту в рамках заявки.
Любой сотрудник поддержки должен быть в состоянии установить связь между заявками и статьями. Ссылки должны быть реализованы таким образом, чтобы быть доступными для других процессов, например, для создания отчетов, алгоритмов ранжирования поиска и отображения результатов поиска. (Другими словами, гиперссылка, встроенная в текстовое поле как часть заметки об инциденте, не удовлетворяет этому требованию.) .Сотрудники поддержки должны иметь возможность связывать и удалять ссылки на статьи.
Механизм связывания должен позволять сотруднику, просматривающему заявку, видеть как текущее состояние связанных статей, так и содержание статьи на момент ее отправки клиенту. (Например, путем записи решения в заявке и включения ссылки на конкретную версию статьи, если база знаний поддерживает историю версий.)

Связь «многие ко многим» между заявками и статьями

Механизм связывания должен позволять связывать как несколько заявок с одной статьей, так и несколько статей с одной заявкой.

При наличии продуктовых дефектов (багов) связка много заявок-статья-баг дает понимание к каким затратам в поддержке приводит тот или иной продуктовый дефект, а так же позволяет оценить и расставит приоритеты для их исправления.