Как создать базу знаний

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

Запуск базы знаний в службе поддержки: с чего начать

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

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

Шаг 1. Построение процессов  

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

Выделение этапов и ролей. Здесь служба поддержки решает базовые организационные вопросы:

• кто отвечает за проект и его отдельные части;
• с какой периодичностью и по каким поводам создаются и обновляются материалы;
• как проверяется качество контента.

Для управления подобным проектом следует назначить куратора базы знаний. Этот специалист планирует темы, распределяет задачи, следит за сроками и публикует готовый контент. К подготовке материалов куратор подключает разных членов команды. Как правило, за ними закрепляются задачи по написанию, тестированию и редактуре. 

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

Шаг 2. Разработка концепции базы знаний

Чем насыщать и как структурировать базу знаний, зависит от особенностей бизнеса. Вместе с тем есть несколько универсальных подходов. 

Определение групп пользователей. Инструмент может быть ориентирован исключительно на специалистов поддержки (внутренняя БЗ) либо клиентов (внешняя БЗ). Первый вариант подойдет, если в компании большой поток новых сотрудников. На этапе онбординга материалы базы знаний позволяют «закрывать» типовые вопросы, а значит новички быстрее изучат специфику рабочих задач. Для критичных сервисов, поддержка которых отнимает у специалистов много времени, структурированные знания также помогают ускорить процессы обслуживания.   

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

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

Выбор типов контента. Материалы базы знаний бывают самыми разными в зависимости от специфики поддержки. Перечислим наиболее распространенные. 

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

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

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

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

Учет обратной связи. Разработанная на начальном этапе структура не «высекается в камне». Необходимо принимать во внимание отзывы тех, кто непосредственно пользуется базой знаний. Рубрики, разделы можно менять и переформатировать, если что-то оказывается неудобным.   

Шаг 3. Построение системы мотивации 

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

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

Внедрение отдельных KPI. Зачастую расширение числа авторов тормозится, если  специалисты не видят пользы для себя. Помехой в популяризации проекта может стать система KPI сотрудников, которая никак не учитывает показатели по «оцифровке» знаний. Скажем, основной акцент делается на скорости решения вопросов: кто быстрее всех устраняет проблемы пользователей, тот получает премию. В таком случае специалисты предпочитают оставаться хранителями уникальных знаний и не спешат делиться опытом с коллегами.

Чтобы переломить такую ситуацию, следует пересмотреть систему KPI и включить в них новые показатели. Например, если статья помогла в выполнении определенного количества запросов, ее автор получает бонус. Реализовать такую мотивационную политику помогают автоматизированные ИТ-системы, в которых настраивается аналитика по решенным заявкам на основе материалов базы знаний.

Шаг 4. Формализация требований к материалам 

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

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

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

Шаг 5. Актуализация базы знаний 

Базу знаний потребуется дополнять новыми материалами и менять по мере развития бизнес-процессов. Вот несколько рекомендаций для эффективной актуализации единого источника информации. 

Составление тем публикаций. Специалистам поддержки нужны простые способы внести соответствующие предложения по «горячим следам», чтобы ни одна тема не потерялась. К примеру, в некоторых service desk при выполнении клиентской заявки исполнитель может сразу отметить, какой вопрос «дозрел» до отдельной статьи. Куратору базы знаний остается провести мониторинг таких тем и сформировать план.

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

Учет загрузки команды. Нередки ситуации, когда автор запланированной статьи занят срочной задачей, допустим, устранением инцидента. Тогда подготовку контента для базы знаний придется передать сотруднику, который сможет написать материал быстрее.

Если служба поддержки использует для автоматизации процессов service desk, то распределить статьи между авторами помогут реализованные в таких системах канбан-доски. Они наглядно визуализируют загрузку каждого специалиста и позволяют быстро «перекидывать» задачи между исполнителями.

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

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