Техника 6.1: Структурированное решение проблем

Как мы уже упоминали, Цикл Развития определяет и включает в себя Цикл Решения. Структурированный процесс решения проблем создает контекст для практик Цикла Решения. Практики работают как независимые объекты и используются по мере необходимости при ответе на запросы.

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

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

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

Структурированный процесс решения проблем в KCS включает в себя две простые, но мощные концепции:

Во-первых, мы стремимся понять ситуацию в контексте клиента и фиксируем ее, чтобы сохранить в статье. Затем мы пытаемся понять, что мы все вместе знаем о проблеме (поиск в базе знаний). Эти концепции не уникальны для KCS; Чарльз Кепнер и Бенджамин Трего излагают те же методологии решения проблем в «Рациональном менеджере», что и Стивен Р. Кови в «Семь навыках высокоэффективных людей».

Как и в случае с местом преступления, мы начинаем с того, что записываем взгляд клиента на происходящее - симптомы проблемы, как он их видит. Затем мы просматриваем базу знаний, чтобы узнать, является ли это известной проблемой. Техника «ищи раньше, ищи часто» является ключевой частью Цикла Решения. Если найдена статья с решением, то мы можем предоставить решение и связать ее с тикетом (возможно требуется дополнить или изменить существующую статью). Если нет, то уточняем поисковый запрос, собирая дополнительную информацию с клиента.

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

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

Управление инцидентом

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

Совместная работа

Решение проблем — это совместный процесс. Спросите любого сотрудника, что он делает, когда понимает, что работает над чем-то новым или незнакомым, и он скажет вам, что обращается к своим коллегам: они сотрудничают. Слишком часто они делают это вопреки традиционным процессам и правилам эскалации. Что, если бы наш процесс и инфраструктура способствовали сотрудничеству, а не препятствовали ему?

Сотрудники поддержки обычно используют такие инструменты, как электронная почта и мессенджеры, или просто опрашивая окружающих. Возможность повысить эффективность сотрудничества заключается в способности знать такие вещи, как доступность эксперта, что он знает и в чем заинтересован. Эффективное сотрудничество, или то, что мы называем Моделью Пчелиного Роя (Intelligent Swarming), является функцией релевантности. Под релевантностью мы подразумеваем, что для данной проблемы мы хотим объединить наши лучшие ресурсы (людей и/или контент). Возникает идея профилей людей, которые охватывают их опыт, навыки и интересы.

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

Модель Роевого Интеллекта (Intelligent Swarming) это модель построения службы поддержки, которая основана на совместной работе сотрудников поддержки над тикетом до его полного решения, в отличие от традиционной модели, которая предполагает передачу тикета с уровня на уровень.

Некоторые примеры обеспечения совместной работы:

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