Поиск общих проблем

Выявление общих проблем

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

Во-первых, мы увидим, что у нас есть дубликаты статей. Можно ли их объединить?

Во-вторых, мы часто обнаруживаем, что одна проблема (или набор общих проблем) может возникнуть по множеству различных причин, каждая из которых имеет свое решение. Например, «Машина не заводится» может иметь много возможных причин: в машине может закончиться бензин, может потребоваться зарядить аккумулятор или поменять стартер. Проблема или симптом, с которым столкнулся клиент, недостаточен для определения правильного решения. Необходима дополнительная информация, возможно, требующая диагностических шагов для определения отличительных характеристик ситуации, чтобы предоставить релевантное решение.

Сначала мы обсудим, как поступать с повторяющимися статьями, а затем расскажем, как создавать статьи-хабы.

Объединение статей

При работе с дубликатами статей следует учитывать несколько моментов.

Для простых повторяющихся статей, при принятии решения об объединении статей следует проверять:

• Действительно ли причина и решение в каждой из статей одни и те же?
• Предназначены ли эти статьи для разных аудиторий? Если да, то наличие двух версий статьи может иметь смысл. Снизит ли объединение этих статей возможность поиска для целевой аудитории?

Для более сложных проблем нам может потребоваться создать статью-хаб и/или перевести статью в архивное состояние.

Для статей, которые мы идентифицировали как дубликаты и кандидаты на слияние, мы сохраняем самую старую статью как активную и объединяем в нее соответствующую информацию, метаданные и ссылки из более новых статей.

Статья-хаб или шаги для диагностики?

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

Цель обоих этих подходов состоит в том, чтобы как можно быстрее привести клиента или сотрудника поддержки к правильному.

• Если квалифицирующие критерии для уникального решения просты ( например: если условие A верно, то статья X имеет правильное решение ) — это можно сделать через статью-хаб.
• Если для оценки ситуации необходимо много шагов или уточняющих вопросов, то следует создать диагностическую процедуру.

Статья-хаб

В статье-хабе перечисляются уточняющие вопросы/условия, которые отличают одно решение от другого, и для каждого условия есть ссылка на статью с соответствующим решением. Итак, хаб-статья — это список «если это верно, то вот статья с правильным разрешением». Они действуют как своего рода индекс статей, т.к. не содержат решений, а лишь указывают на другие статьи.

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

Два соображения относительно последовательности уточняющих вопросов:

1. Если из исторических данных мы можем сказать, что частота использования решений не одинакова, уточняющие вопросы должны располагаться в порядке от наиболее часто используемого решения к наименее часто используемому.
2. Учитывайте усилия клиента по применению того или иного решения. Если есть решения, требующие минимальных усилий, они являются хорошими кандидатами на первое место в списке. Решения, требующие больших усилий, например такие как «переустановите операционную систему», должны быть внизу.

Диагностические шаги

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

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

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

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

Проектирование путей решения

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

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

Создание статей с диагностическими шагами

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

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