Данная статья является продолжением предыдущей статьи, в которой был анонс о подходе к управлению знаниями в компании по методологии KCS. Если вкратце, то было дано коротенькое определение, анонсированы результаты, которые даёт внедрение KCS, а также основная идея KCS — управление знаниями через двойной цикл. О нём сегодня и пойдёт речь. Постараюсь максимально просто и коротко донести идеи, потому что оригинал руководства по практическому использованию (practice guide) перепечатывать совсем не хочется, а там целых 184 страницы. И все важные!

Глоссарий

Долго думал, как переводить practices и techniques с английского. В итоге остановился на «Практики» и «Приёмы». Так показалось более благозвучно.

Так что же такое двойной цикл?

Прежде чем переходить к самим процессам, хотелось бы обозначить что же по KCS является знанием или другими словами, какие виды интеллектуальных активов (knowledge assets в оригинале) можно выделить. По KCS их 4 типа:

1. Статья в базе знаний. Фактически — это опыт, накопленный в ходе работы службы поддержки организации. Статьи помогают решать возникающие проблемы.
2. Профили сотрудников. Это информация об опыте сотрудника, его навыках, интересах и репутации.
3. Информация о клиентах. Например, бизнес-модель клиента, цели организации. Чем более полный профиль компании, тем лучше.
4. Конфигурация ПО клиента.

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



Итак, двойной цикл включает в себя цикл решения и цикл развития. Не очень понятно, правда? Если раскрывать каждое понятие, то цикл решения — это про то, какие действия должен совершить сотрудник, что решить проблему пользователя. А цикл развития про то, как поддерживать и развивать KCS, чтобы работалось только лучше, быстрее и качественнее. Напоминаю, что очень вольная моя трактовка. Решил, что такой способ подачи лучше, чем дословный перевод оригинала, с которым кстати вы всегда можете познакомиться.

Каждый из двух циклов включает в себя 4 практики, а уже каждая практика содержит конкретные приёмы. От 2-х до 8-ми. Практики мы перечислим, а вот приёмы, конечно же, разбирать не будем.

Цикл решения

Цикл решения состоит из 4-х практик:

1. Сбор знаний в ходе рабочего процесса;
2. Структурирование знания;
3. Повторное использование;
4. Постоянное улучшение.

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

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

Повторное использование — это краеугольный камень создания базы знаний. Ведь никому не нужна статья, к которой никто никогда не будет обращаться. Однако проблема в том, что в момент создания статьи непонятно, будет ли она востребована. Поэтому одним из хитрых приёмов, который может помочь, является сохранение поисковых запросов. Все помнят негласное правило git «commit early, commit often». Здесь то же самое, только про поиск. «Search early, search often». Лучшей практикой считается поиск непосредственно в момент общения с клиентом.

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

Через все практики цикла решения проходит одно важное правило —

коллективное владение.

Мысль простая: «Если я пользуюсь какой-либо статьёй, я несу ответственность за её качество.»

Цикл развития

Цикл развития так же состоит из 4-х практик:

1. Актуальность и качество контента;
2. Интеграция процесса;
3. Оценка эффективности;
4. Лидерство и коммуникации.

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

Что касается интеграции процессов, то это самый проблемный пункт. Основная идея — ваша система service desk должна быть интегрирована с системой управления знаниями. Как пример, если статья в базе знаний и конкретная заявка в service desk могу быть пролинкованы связью «решена с помощью», то у нас есть хороший инструмент по оценке качества статьи. Т, е. сколько раз данная статья помогла в решении конкретной проблемы. Ещё лучше, если база знаний будет интегрирована с вашим мессенджером. Вспомните, как часто вам приходилось пользоваться поиском в вашем корпоративном мессенджере, чтобы найти совет или рекомендацию коллеги? И хорошо, если это slack, а не скайп.

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

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

Вместо итога

Написав всего лишь по абзацу про каждую из рекомендованных практик, которые включает в себя KCS, начинает казаться, что KCS огромен и необъятен. Думаю, что так оно и есть, но его преимущество на мой взгляд в том, что можно брать какие-то его части и пробовать вводить их у себя в организации. Плюс KCS — это хороший пример «а как ещё бывает». Можно не наступать на грабли и побыстрее добиться лучшего качества в работе.

Практические примеры

В прошлой статье меня спрашивали, где можно почитать про внедрение KCS. Публичные примеры в России есть. Вот опыт Parallels — http://netology.ru/blog/parallels-support