Скопировать ссылку
Проблема устаревших баз знаний
До модернизации в нашей базе знаний можно было найти регламенты о том, как правильно носить маску и перчатки в COVID (хотя пандемия закончилась миллион лет назад), инструкции к уже неактивным сервисам и документы, которые противоречили друг другу.
Полезные материалы там, безусловно, тоже были. Но они тонули в этом океане мусора. Устаревшие статьи копились, сотрудники ошибались, а затраты на обучение новых работников росли. Информацию передавали устно, от старших коллег к младшим.
База знаний перестала выполнять свою основную функцию — быть единым источником актуальной информации. Люди работали «по понятиям», а не по правилам, что стало слишком дорого обходиться бизнесу.
5 этапов модернизации базы знаний
Модернизация базы знаний — это фундаментальный процесс, к которому я много лет боялся подступиться, слишком трудозатратно он выглядел. В нашем случае было недостаточно «обновить пару страниц» или «удалить неактуальные материалы». База знаний нуждалась в полной трансформации. Была цель создать систему, которая будет работать в интересах компании и помогать команде, а не мешать ей.
Весь процесс мы разделили на пять шагов.
Шаг 1: формирование принципов работы базы знаний
Мы начали с того, что сформировали основные принципы работы новой базы знаний:
- Она структурирована и разбита на сервисы. Любой человек может сориентироваться в ее структуре, не прибегая к поиску.
- За каждым сервисом закреплен ответственный delivery-manager.
- Все процессы в рамках сервисов описаны четко формализованными регламентами.
- Для каждого регламента описана процедура инспекции (контроль выполнения регламента).
- Вся справочная информация описана памятками.
- Определена редакционная политика.
- Все статьи регулярно обновляются.
На основании этих принципов создали «регламент регламентов», который берется за основу при написании любой новой статьи. Так у нас появилась логика, на которую можно опираться при пересборке базы знаний.
Выдержка из «регламента регламентов»
Шаг 2: формирование структуры и бэклога
Далее мы определили структуру. Для этого мы разбили всю работу в компании на сервисы и подсервисы.
Верхний уровень структуры
Пример вложенной структуры сервисов и подсервисов
Примеры вложенной структуры с регламентами и памятками
Далее для каждого сервиса был сформирован бэклог статей на основании анализа старой версии базы знаний и интервью с руководителями отделов. Каждая статья, которая нуждалась в актуализации, или еще не описанный ранее процесс превратились в тикет на канбан-доске.
Шаг 3: запуск сервиса для управления процессом
Затем мы запустили отдельный сервис, который назвали «AGIMA Дума». Это метаплатформа, которая координирует создание всех регламентов и сервисов и «переваривает» бэклог. Название пришло не случайно: изначально мы хотели, чтобы документы воспринимались как обязательные «законы», а не пожелания. Так и родилось название — как символ регламентирующего органа.
Даже внутренние встречи называются «заседаниями»
Внутри «Думы» бэклог на тысячу тикетов на канбан-доске по каждому направлению — от управленческого учета до мотивационных схем. Мы их приоритизировали и начали системно прорабатывать. Каждый тикет — это новая задача по написанию актуальной статьи.
Доска Kanban, в которой работают сотрудники AGIMA
Кроме того, мы внедрили чек-листы для регламентов и памяток. Там все: от рекомендаций использовать ссылки и указывать роли вместо имен до требований к орфографии и пунктуации. Мы даже подключили телеграм-бота для автоматической редактуры текста.
Пример чек-листа. Здесь можно посмотреть все примеры чек-листов AGIMA для регламентов и памяток
Каждая статья проходит обязательную проверку: сначала редактор структурирует материал, затем представитель топ-менеджмента валидирует ее по чек-листу, а уже после финальной сверки документ публикуется с нужными ссылками, а старая статья удаляется. В результате мы перешли от хаоса к прозрачной системе управления знаниями, где каждый шаг понятен, а каждая публикация — это результат командной работы, а не чья-то импровизация.
Шаг 4: постоянное развитие сервиса и повышение его эффективности
Ограничение прав редактирования. Ранее любой сотрудник мог создать статью, которая быстро устаревала и становилась ненадежным источником информации. Теперь только руководители сервиса «Дума» могут вносить изменения или создавать статьи в рабочей версии базы знаний (остальные сотрудники могут работать только с черновиком).
Строим систему на ролях. На одном из этапов мы осознали, насколько опасно строить базу знаний на людях, а не на ролях. Раньше в документации можно было встретить фразы вроде «ответственный — Вася Пупкин». Но стоило Пупкину уволиться, и процесс терял актуальность (обновить статью, конечно же, забывали). Поэтому мы убрали имена, остались только роли: «руководитель отдела найма» или «рекрутер, закрепленный за вакансией». Это усилило гибкость — теперь не важно, кто именно выполняет задачу, важно, чтобы роль была закрыта.
Ввели теги по ролям. Например, если нажать на тег «РПО», перед вами открываются все статьи, которые актуальны для этой роли. Это исключает необходимость вручную собирать ссылки. По этим тегам мы проводим онбординг и грейдирование с помощью LLM-агента, который собирает все статьи по соответствующей роли и формирует список вопросов, на которые сотрудник должен ответить на аттестации. По той же логике происходит и ознакомление сотрудников с новыми регламентами.
Этот блок виден на главной странице базы знаний. Теги проставлены к каждой статье
Изменили подход к регулярным встречам. Сначала у нас были общие еженедельные встречи по сервису «Дума», на которые собирались все участники процесса. Но вскоре стало понятно, что это неудобно: продакт-менеджер не интересуется тем, что происходит в HR, а HR не нужно знать, что происходит в разработке. Тогда мы разделили «Думу» на девять компонентов: HR, финансы, сервис-деск, разработка и другие. Каждый компонент получил свой отдельный еженедельный синк по статусу и ежемесячный синк по пополнению, на котором разбираем бэклог и генерируем новые задачи.
Топ-менеджеры не правят статьи за сотрудников. Главное — не пытаться сделать все в одиночку, а научить людей. В начале мы сами переписывали каждый регламент, затем стали давать точечные комментарии, а позже начали записывать видео, объясняя, что не так и где нужно внести корректировки. Это значительно ускорило процесс обучения и расширило бутылочное горлышко в виде топ-менеджеров.
Метрики сервиса «Дума». Чтобы выпускать статьи быстрее, мы начали отслеживать метрики Throughput (пропускная способность) и Lead Time (время от постановки задачи до ее публикации) и внедрили KPI на их улучшение. Например, однажды HR-отдел получил сразу 50 тикетов. Задачи казались важными, но такой объем сотрудники не могли осилить разом, из-за чего месяц все статьи находились в работе, но ни одна не выпускалась. Так родилась идея ввести ограничения на количество одновременно выполняемых задач. Вместо сорока тикетов за раз давать только два. Завершив работу над ними, можно приступать к следующим задачам.
Релизы. Мы стали собирать пачку новых статей в релиз и раз в неделю рассылать на всю компанию, обращая внимание сотрудников на новые регламенты.
Пример письма, которое получают сотрудники AGIMA
Шаг 5: регулярная актуализация и поддержание порядка
Финальный и, пожалуй, самый долгий этап — регулярное обновление контента. Все статьи обновляются по циклу раз в полгода или раз в год. На данный момент в экосистеме 185 тикетов — и это не предел. Мы прошли почти половину, но бэклог продолжает расти. Чем системнее подход, тем больше становится видно точек роста. Мы больше не ведем базу знаний ради базы знаний — мы проектируем рабочую среду, в которой информация не лежит мертвым грузом, а ежедневно помогает команде двигаться быстрее.
Результаты, которые получает бизнес
Как и в любой сфере, успех модернизации не всегда можно прочувствовать. Хорошая база знаний не вызывает восторгов, а воспринимается как нечто должное. Поэтому отсутствие жалоб и ошибок является главным индикатором того, что система работает хорошо.
Вот ключевые результаты, которых мы достигли за счет модернизации базы знаний:
- Снизилось количество ошибок.
- Онбординг новых сотрудников ускорился, они быстрее находят нужную информацию. Фрустрация новичков из-за непрозрачных правил работы также снизилась.
- Теперь мы можем уменьшить требования к квалификации специалистов. Если регламенты четкие и понятные, для работы достаточно уверенного мидла, а не только сеньора.
- Уменьшился объем «мусорных» коммуникаций, встреч и созвонов. Чем четче правила — тем меньше возникает нестандартных ситуаций в работе, чаще всего достаточно просто действовать по инструкции.
Наши дальнейшие планы связаны с ускорением процессов и их автоматизацией, что повысит гибкость и адаптивность компании.
Чек-лист: как понять, что ваша база знаний устарела
Если вы замечаете хотя бы несколько пунктов из списка ниже — пора заняться обновлением базы знаний:
- В статьях упоминаются сотрудники, которые давно уволились.
- Есть противоречивые или дублирующие друг друга документы.
- Даже по стандартным поводам собирается созвон для определения плана действий.
- В базе знаний можно найти устаревшую информацию.
- Новичкам тяжело разобраться — тратится много времени на онбординг.
- Нет единых стандартов оформления, редактирования и обновления статей.
- Информацией сложно управлять: непонятно, кто за что отвечает.
- В базу знаний боятся заходить — проще спросить, чем найти ответ самому.
Модернизация базы знаний — это не одноразовая задача, а постоянный процесс, который требует регулярной актуализации и вовлечения всей команды. Для бизнеса это инвестиция в долгосрочную эффективность и рост, которая, как показал опыт, ведет к улучшению качества работы и снижению затрат.
