Управление знаниями: как сделать, чтобы опыт не уходил вместе с людьми

Зачем управление знаниями

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

Пять слов, без которых дальше не обойтись

ITIL — самый известный в мире сборник советов о том, как организовать работу ИТ-отдела: свод проверенных приёмов, которым следуют добровольно.

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 — одно направление такой работы: например, «разбираться со сбоями» или «выпускать новые версии». Управление знаниями — одна из практик. В справочнике у каждой практики есть короткий код: KNW, INC, PRB и так далее.

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

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

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

Как это выглядит в жизни. Возьмём условную компанию-разработчика. В ней 60 человек, они делают мобильное приложение и личный кабинет для сети фитнес-клубов: запись на тренировки, оплата абонементов, уведомления.

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

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

Беда не в ошибке: ошибки бывают у всех, и исправили её быстро. Беда в том, что знание о выпуске версии жило в одной голове.

Что можно было сделать заранее? Олег мог бы несколько раз выпустить версию вместе с коллегой Леной. Мог бы записать инструкцию. Руководитель команды мог бы собрать инструкции по выпуску, тестированию и откату в один документ. А Лена прочитала бы его, выпустила пару версий под присмотром и научилась. Эти четыре действия и составляют суть управления знаниями — они разобраны ниже.

Цель практики по ITIL — чтобы сведениями и знаниями по всей организации пользовались с толком, без лишних затрат и без мучений 1. То есть превращать то, что знают отдельные люди, в пользу для всех: и для сотрудников, и для клиентов 1. ITIL описывает, как выглядит организация, где со знаниями всё хорошо 1:

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

Знание бывает двух видов 1. Явное можно записать, передать, проверить и хранить: инструкция «Как выпустить новую версию» с шагами и тем, что делать при ошибке. Неявное трудно выразить словами, оно держится на опыте. Олег смотрит на журнал ошибок и через минуту говорит: «Это не код, это база данных тормозит, так уже было в прошлом декабре». По шагам он это не распишет — это опыт шести лет работы.

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

Когда практика работает

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

Ответ находится там, где идёт работа. Сотрудник поддержки открывает жалобу и прямо в ней видит подсказку: «похожая ошибка, вот что делать». Ему не нужно искать её по пяти папкам или писать в общий чат.

Делиться принято. Новичок не стесняется спросить, а опытный разработчик не жалеет времени на объяснение. Никто не прячет свои приёмы, чтобы оставаться незаменимым. ITIL предлагает мерить именно это — насколько культура обмена прижилась 1.

Качество знаний проверяют. ITIL называет пять признаков качества сведений 1. На примере вики разработчиков:

• точность — в инструкции указан правильный адрес тестового сервера, а не прошлогодний;
• полнота — описаны все шаги выпуска, включая то, как откатить версию, если она сломалась;
• непротиворечивость — в одной статье не написано «сборку запускаем вручную», а в другой «сборка запускается сама»;
• без дублей — в вики одна страница «Как выпустить версию», а не три с разными датами;
• своевременность — инструкцию обновили сразу после смены инструмента сборки, а не через полгода.

Что входит и что рядом

По ITIL у практики четыре области 1:

• создать среду, где знаниями делятся: привычки, приёмы, правила, инструменты и умения;
• знать, какие знания у компании есть и где они лежат, и советовать, как ими распоряжаться;
• следить, как знаниями пользуются, и улучшать это;
• находить ответ по запросу, если готового знания нет.

Кроме этих четырёх областей, в практику входят ещё две задачи: вести общий словарь и модель сведений (это один из трёх процессов ITIL, о них ниже) и улучшать саму практику.

Что на входе и что на выходе

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

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

Четыре способа передачи знания

Японские исследователи Икудзиро Нонака и Хиротака Такэути описали, как знание переходит от человека к человеку и от человека ко всей организации 1. Их модель называют SECI, по первым буквам четырёх английских названий. Идея простая: знание бывает «в голове» (неявное) и «записанным» (явное) и переходит между этими состояниями четырьмя путями 1.

Способ	Что происходит	Пример в компании-разработчике
Общение (Socialization)	Из головы в голову: показывают, работают рядом, обсуждают	Лена садится рядом с Олегом, пока он выпускает версию, и он по ходу объясняет, куда смотреть и почему. Сюда же относятся парное программирование и совместный разбор сбоя
Выражение (Externalization)	Из головы в запись: опыт описывают словами	Олег пишет в вики инструкцию «Как выпустить версию», а после сбоя с оплатой — статью «Что делать, если платёжный сервис отвечает ошибкой 504»
Соединение (Combination)	Из записей в новую запись: собирают целое из частей	Руководитель команды соединяет инструкцию Олега, список проверок от тестировщиков и правила работы с кодом в единый регламент выпуска
Усвоение (Internalization)	Из записи в голову: прочитанное становится умением	Лена по регламенту выпускает три версии, сначала под присмотром, потом сама. Через месяц она делает это, не заглядывая в инструкцию

Что из этого следует. База знаний помогает трём способам из четырёх: в неё записывают, в ней собирают, по ней учатся. Но она не заменяет живого общения, а через общение передаётся самое трудное — неявное знание. Если компания вкладывается только в статьи и забывает про наставников, совместные разборы и парную работу, чутьё Олега уйдёт вместе с Олегом.

Способность впитывать (absorptive capacity) — ещё одно важное понятие из ITIL. Это умение компании заметить, что новые сведения ценны, связать их с тем, что она уже знает, и применить 1. Пример: тестировщик на конференции узнаёт о новом инструменте для автоматических проверок. Команда понимает, что он решает её старую беду — проверки идут по два часа, — пробует его на одном проекте и за месяц переводит на него остальные. ITIL советует развивать эту способность постоянно и сразу на четырёх уровнях: человека, команды, всей компании и её связей с внешним миром 1.

Как это работает

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

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение работа с людьми и сторонами

Первый шаг про культуру, и это не случайно. По ITIL приёмы и инструменты работают только там, где люди готовы делиться и где их применяют правильно и вовремя 1. Если компания купила дорогую систему для базы знаний, а делиться опытом там невыгодно, система так и останется пустой.

Четвёртый шаг избавляет от вечного спора. Где кончаются данные, начинаются сведения и появляется знание — вопрос договорённости, а не истины 1. Об этом — в следующем разделе.

Что с чем путают

Данные, сведения и знание. Разберём на примере платёжной ошибки. Данные — просто значение без смысла: «504». Сведения — данные с объяснением: «платёжный сервис отвечает ошибкой 504 на каждый тридцатый запрос». Знание — понимание, что со сведениями делать: «если в последние дни месяца таких ошибок становится больше, провайдер перегружен, нужно переключиться на резервный платёжный сервис и предупредить поддержку». ITIL опирается на пирамиду «данные — сведения — знание — мудрость» (DIKW), но оговаривает: чётких границ между ступенями нет, и компания сама решает, как их называть 1.

Знание и база знаний. База — инструмент для явного знания 1. Чутьё Олега на то, где искать причину сбоя, через базу не передашь: для этого нужно разбирать сбои вместе.

Управление знаниями и обучение. Это соседи, но разные практики. Обучение и развитие людей относятся к TLNУправление персоналом и талантами 1. Управление знаниями следит, чтобы было чему учить и чтобы это знание было верным.

Статья и решение. Записанное решение помогает, только если его находят в момент работы. Инструкция по выпуску версии, которую в пятницу вечером никто не может найти, ничем не лучше её отсутствия.

Много статей и хорошее знание. Тысяча устаревших статей хуже сотни свежих. Мерить нужно качество по пяти признакам, а не количество 1.

Кто участвует

Как измерять

Руководство ITIL по этой практике привязывает показатели не к шагам процесса, а к двум факторам успеха — тому, без чего практика не даёт результата 1: создавать ценное знание и передавать его по всей компании и пользоваться сведениями для решений.

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

Единственно верного набора показателей нет, и ITIL сам это признаёт 1. Показатели выбирают, исходя из стратегии, приоритетов компании и того, в создании каких услуг для клиентов участвует практика 1. Удобная проверка для собственной таблицы: показатель, который не служит ни одному фактору успеха, меряет занятость практики, а не её пользу.

Зрелость управления знаниями

✕

Где ломается чаще всего

Шесть типичных поломок.

Знание живёт в головах. Неявное знание не записывают, и уход человека означает потерю целой области. Олег уволился — и никто не знает, где лежат ключи для подписи приложения.

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

Делиться невыгодно. Если незаменимого сотрудника ценят больше, чем того, кто научил других, знание будут прятать. Без культуры обмена не выполнить первый фактор успеха практики — создавать и передавать знание 1.

Знание не доходит до места работы. Ответ существует, но не там, где он нужен. Решение для частой жалобы записано в вики разработчиков, а у поддержки туда нет доступа.

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

Качество не проверяют. Устаревшие статьи лежат рядом с верными, и базе перестают доверять 1. Лена дважды сделала всё по инструкции, которая уже не работает. В третий раз она пойдёт спрашивать Олега, а не открывать вики.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL выделяет знания в отдельную практику с двумя факторами успеха: создавать и передавать ценное знание и пользоваться сведениями для решений 1.

ГОСТ Р ИСО/МЭК 20000-1 требует определить и поддерживать знания, нужные для работы сервисов и системы менеджмента сервисовСистема менеджмента сервисовНабор взаимосвязанных элементов организации — структура, роли, политики, процессы, — которыми управляют сервисами.ГОСТ Р ИСО/МЭК 20000-1—2021, и обеспечить, чтобы эти знания были соответствующими, пригодными и доступными 2.

COBIT выделяет управление знаниями в отдельную цель управления в домене разработки, приобретения и внедрения 3.

В чём они расходятся. Стандарт требует, чтобы нужные знания были определены и доступны. ITIL добавляет к этому культуру и способы передачи опыта. Компания, которая выполнила только требования стандарта, наведёт порядок в документах, но опыт от человека к человеку передаваться может так и не начать.

Где описано

Что почитать дальше

Три соседние практики, с которыми знания работают в паре: TLNУправление персоналом и талантами — как люди учатся, SDKСлужба поддержки — где знание нужно чаще всего, PRBУправление проблемами — откуда берётся самое ценное знание: почему что-то ломается.