Анализ новых и известных проблем

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

Важно понимать также понимать процент открытых инцидентов, связанных с известными проблемами или вопросами, по сравнению с новыми.

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

Задача

Рассматривая закрытые инциденты с точки зрения новых и известных проблем, и анализируя инциденты в каждой категории, мы можем определить:

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

Подход

Анализ новых и известных данных следует проводить периодически в течение года, возможно, не чаще одного раза в квартал.

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

Четыре шага

1) Определение исследуемой области знаний

2) Сбор данных 1. Создайте отчет, в котором перечислены все инциденты, закрытые за последние 30-60 дней в исследуемой области знаний. 2. Этот отчет должен включать инциденты со ссылками на статьи и без них. Если возможно, этот отчет должен исключать инциденты типа «проблем не обнаружено» или «отменено клиентом». В идеале отчет должен иметь следующие поля: - Идентификатор инцидента - Название инцидента или краткое изложение - Код закрытия инцидента - Идентификатор статьи связанной с инцидентом - Название статьи - Резюме статьи (если доступно) - Поля для анализа

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

4) Определите и обсудите возможности:

1. Каков процент новых и известных проблем, которые решаются?
2. Что может сделать служба поддержки, чтобы уменьшить количество инцидентов с известными проблемами?

3. Проанализируйте и отсортируйте инциденты с учетом следующих критериев:

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

4. Какие улучшения можно внести в процесс решения новых проблем?

   1. Проанализируйте и отсортируйте данные, чтобы увидеть, что потребовалось для решения:
      1. Эскалация?
      2. Диагностика?
      3. Воспроизведение?

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

Что представляет собой "Известная проблема"?

• Инцидент закрыт со ссылкой на правильную, уже существующую статью.
• Правильная статья существует, но не связана с инцидентом.
• В некоторых организациях известной определяют проблему, которую "и так все знают", но она не зафиксирована в базе знаний. (Если такое условие существует, это указывает на то, что они на самом деле не используют KCS. Если задается вопрос, он должен быть в базе знаний.)
• Некоторые организации определяю известные проблемы, используя отметку даты открытия инцидента по сравнению с датой создания статьи. Если статья существовала до инцидента, это считается «известным». Такой метод штампа данных основан на аккуратности и точности ссылок. Рекомендуется сначала выполнить анализ новых и известных данных вручную, пока вы не будете уверены , что сотрудники поддержки правильно связывают инциденты с релевантными статьями.