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

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

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

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

Третий шаг — назначить владельца смысла и редактора. Эксперт отвечает за корректность, но не обязан переписывать страницу. Редактор собирает изменения, задаёт вопросы, убирает противоречия и выпускает новую версию. Это снимает вечную проблему «эксперт занят, поэтому документ устарел».

Четвёртый шаг — фиксировать причину изменения. Простая строка «обновлено после изменения процесса внедрения» полезнее безымянной даты. Через год команда понимает не только что поменялось, но и почему.

Пятый шаг — смотреть, какие материалы реально используют. Если страницу никто не открывал год, возможно, её надо не обновлять, а удалить или объединить с другой. Хорошая база знаний не обязана расти бесконечно. Иногда качество появляется именно после уборки.

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