Почему база знаний проигрывает обычному чату

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

Новый сотрудник приходит, видит этот бедлам, открывает для порядка 5-6 документов, не находит нужную информацию и идёт в чат к руководителю или HR — занимать его ценное время.

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

Когда база знаний — не система, а склад

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

Часто встречал случаи, когда саппорт или техлид собирал свою личную БЗ в Notion, потому что в официальной БЗ 70% статей уже год как устарели. И к нему ходили все новички. Сколько рабочих задач он выполнит, пока ответит на все вопросы?

Вот как системы ломаются на практике:

• Нет единого владельца, отвечающего за базу знаний

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

  Потом в потоке рутины руководителю сложно отследить, какие статьи ещё актуальны, а какие нет. Часто одно и то же решение описывают несколько документов разной степени достоверности: один писали несколько лет назад, потеряли, написали новый, и так по кругу. С такой базой знаний я столкнулся в digital-performance агентстве пару лет назад.

• Базу знаний наполняют просто как файловый архив

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

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

• Нет исследований и построения сценариев поиска

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

  Это так же важно для продуктовых компаний с развитой системой поддержки, как и предыдущий пункт.

• Нет управления жизненным циклом знаний

  Вряд ли кто-то задумывается о том, как часто нужно проверять актуальность документов в базе, да и вообще о необходимости регулярного системного аудита. А между тем в молодых и быстро развивающихся компаниях БЗ устаревает за год на 60-80%! А неактуальная инструкция опаснее отсутствия инструкции.

• Слишком объёмные тексты без адаптации под целевую аудиторию

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

  Как-то я потратил целый рабочий день, чтобы разобрать одну статью. Из неё получилось 3 инструкции к разным маркетинговым инструментам, 5 чек-листов и описание бизнес-процесса в придачу.

Отличия рабочей системы от кладбища инструкций

Пока знания живут в людях, а не в системе, рост компании всегда будет упираться в перегруженных экспертов

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

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

• Встроена в процессы менеджмента, разработки, найма и обучения. Это вопрос настройки бизнес-процессов, в которых при каждом изменении системы работы есть пункт «обновить документ» или «добавить новую инструкцию»

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

• Имеет владельца, который премией отвечает за качество своего продукта. Премия строится на показателях из предыдущего пункта

• Проектируется под сценарии поиска и использования информации. Для этого нужно объединять взгляд «сверху» — со стороны руководителей, и «снизу» — со стороны сотрудников, проводить бета-ридинг и консультироваться как с экспертами, так и с пользователями

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

Изменения к лучшему

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

• После систематизации и актуализации знаний в агентстве резко сократилось время на обучение — удалось ускорить онбординг на 30%. Помимо этого, высвободилось до 20% времени руководителей и экспертов, благодаря чему постепенно поднялись KPI отделов

• В крупной продуктовой компании, где очень важна скорость ответа саппортов, скорость поиска информации в базе знаний увеличилась на 40%, что потянуло за собой и основные показатели команд

• В оконной компании после внедрения системы управления знаниями и создания постоянно актуализирующийся базы время стажировки менеджеров по продажам сократилось на 50%.

Компании годами игнорируют проблему

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

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

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