Как спроектировать базу знаний с нуля: структура и ошибки 2026

Спроектировать базу знаний — значит принять решения по её устройству до того, как в неё зальют первую статью: выбрать ось группировки, глубину дерева, статусы страниц, правила именования и роли доступа. Переделать пустой макет дёшево, наполненную базу — дорого, поэтому вся работа идёт до контента. Отдельный слой — кадровая специфика: доступ к персональным данным, ознакомление с ЛНА под подпись, связка с КЭДО. Это часть большого материала про базу знаний компании, где разобрано, зачем она нужна, какие бывают виды и как измерять её эффективность.

Автор статьи — Мария Ж, юрист со стажем более 20 лет, соучредитель сервиса КЭДО Добыто, спикер на конференциях по КЭДО и юриспруденции, судебный эксперт в сфере корпоративного и трудового права. Занимается наймом персонала более 13 лет. Автор более 1000 статей о цифровой подписи, трудовом праве, КЭДО и HR.

Автор статьи

Мария Ж.

Кофаундер сервиса электронного документооборота Добыто

Кофаундер сервиса электронного документооборота Добыто. Юрист с 20 летней практикой. В 2008 году получала красный диплом юриста по корпоративной практике. Руководитель HR-отдела. Спикер на конференциях по КЭДО и юриспруденции.

Чем «спроектировать» базу знаний отличается от «создать»

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

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

Мария Ж, HR-эксперт с 13-летним стажем:
«Самые дорогие грабли — когда база знаний растёт из папки на общем диске. Люди кидают туда файлы «чтобы было», ось группировки не задана, и через год это ворох документов, в котором даже кадровик не находит актуальную версию положения. Спроектировать скелет на берегу — полдня. Разгрести это потом — недели.»

Что проектируют до первой статьи

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

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

Ось таксономии: одна ось на уровень

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

Договорённость о терминах (глоссарий)

Глоссарий кажется бюрократией, пока не столкнёшься с последствиями его отсутствия. Один называет документ «регламент адаптации», другой «инструкция для новичка», третий «онбординг-чеклист». В итоге три статьи про одно и то же, все немного разные, и при обновлении меняют одну, а две забывают. До старта проектирования полезно зафиксировать 20-30 базовых терминов и договориться, что называем ЛНА, что регламентом, что инструкцией. Для кадровой базы это особенно важно: путаница между «положением», «порядком» и «инструкцией» приводит к тому, что сотрудник ознакамливается не с тем документом.

Как выбрать структуру базы знаний: иерархическая, сетевая, смешанная

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

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

Как называть разделы, чтобы их находили

Находимость определяется не поиском, а названиями разделов. Если раздел называется «Управление жизненным циклом персонала», сотрудник, которому надо оформить отпуск, туда не зайдёт — он ищет слово «отпуск». Метод простой: собрать реальные вопросы, с которыми люди приходят в кадровую службу, в рабочие чаты и к руководителям, и назвать разделы их словами. Не «Нормативно-справочная документация», а «Как оформить». Не «Адаптационные мероприятия», а «Новичку в первый день».

Внутренний жаргон методолога и юридические формулировки в названиях убивают находимость. Точное название по ГОСТу может быть уместно внутри статьи, но раздел называется так, как его спросит живой человек. Проверка элементарная: показываете список разделов новому сотруднику и просите найти, где лежит инструкция по больничному. Если он тычет мимо — названия переделываем.

Мария Ж, специалист по трудовому праву и КЭДО:
«Я всегда прошу дать список разделов не методологу, а свежему сотруднику — тому, кто ещё не «отравлен» внутренней терминологией. Он читает названия так, как их прочитает вся массовка. Если он завис на первом же разделе — это не он тупит, это раздел назван на птичьем языке. Переименовали — и доходимость до нужной статьи выросла без всякого поиска.»

Проектируем поиск и навигацию

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

Читайте нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

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

Метки. Теги работают, только если у них есть роли. Разводим три группы: статусные (актуально, черновик, на согласовании, архив), тематические (по функции: подбор, адаптация, охрана труда, оплата) и технические (для служебных выборок). Тогда по метке можно одним запросом вытащить, например, все статьи по охране труда и отправить их владельцу на актуализацию. Без ролей метки превращаются в свалку, где «отпуск», «отпуска» и «отпускные» — три разных тега.

Перекрёстные связи и хлебные крошки. Статья про перевод сотрудника ссылается на статью про доп. соглашение, а не пересказывает её. Один факт живёт в одном месте, остальное — ссылки. Хлебные крошки показывают, где человек находится и как вернуться. Это дёшево заложить на макете и дорого добавить в наполненную базу.

Как заложить обновляемость на этапе проектирования

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

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

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

И отдельно — запрет на copy-paste. Когда один и тот же кусок текста скопирован в пять статей, при обновлении меняют один, а четыре остаются со старой формулировкой. Принцип «один факт — одно место, остальное ссылки» убирает рассинхрон на корню. В сервисе Добыто мы собираем кадровые документы из справочников: реквизиты, формулировки согласий, тексты ЛНА лежат в одном месте, а документ собирается ссылками — меняешь источник, обновляется везде.

Мария Ж, судебный эксперт по трудовому праву:
«Косяк, который всплывает при проверке ГИТ, — в базе висит старая редакция ЛНА, а сотрудники якобы с ней ознакомлены. Поэтому статусную модель и триггер «изменился ЛНА» я закладываю в кадровую базу сразу. Обновили положение — статья автоматом падает на корректировку, и пока владелец её не подтвердил, стоит статус «на корректировку». Никакого задним числом.»

Образцы документов для системы обучения и адаптации

Роли и права доступа в базе знаний

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

Читайте нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

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

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

Особенности базы знаний для HR и кадров

Кадровая база знаний отличается от продуктовой или технической тремя вещами: составом разделов, режимом доступа к ПДн и тем, что часть материалов надо не просто прочитать, а ознакомиться под подпись. Разделы обычно строятся вокруг жизненного цикла сотрудника: приём и онбординг, ЛНА и регламенты, обучение и аттестация, охрана труда, отпуска и больничные, увольнение. Плюс блок для новичка отдельно — ему нужен не весь массив, а короткий маршрут первых дней.

Ознакомление с ЛНА — тот сценарий, который отличает кадровую базу от всех остальных. Мало положить положение в раздел. По ст. 22 ТК РФ работника надо ознакомить с ЛНА под подпись, и факт ознакомления надо доказать при проверке. Требования к порядку ознакомления и оформлению кадровых процедур можно свериться на портале онлайнинспекция.рф — официальном ресурсе Роструда с разъяснениями по трудовому законодательству. Когда раздел ЛНА связан с системой электронного ознакомления, сотрудник открывает документ и подписывает его тут же, а система фиксирует, кто и когда ознакомился.

Именно здесь база знаний смыкается с КЭДО. Наши специалисты в Добыто настраивают связку так: обновился ЛНА — статья в базе падает на корректировку по триггеру, после подтверждения рассылается сотрудникам на ознакомление, а вся цепочка подписей фиксируется с отметками времени. Для кадровой базы это снимает главный риск — доказуемость ознакомления при проверке ГИТ и в суде.

Мария Ж, соучредитель сервиса КЭДО Добыто:
«Кадровая база без связки с ознакомлением — это верхушка айсберга. Сотрудник вроде и прочитал положение в базе, а доказать ознакомление кадровик не может. Мы поэтому раздел ЛНА не отделяем от КЭДО: залил документ в систему, назначил маршрут — и человек читает и подписывает в одном окне, хоть с телефона в командировке. Для проверяющего это закрытый вопрос.»

Как спроектировать базу знаний с нуля: пошаговая инструкция

1. Шаг 1. Зафиксируйте глоссарий: 20-30 базовых терминов, чтобы разделы и статьи назывались одинаково.
2. Шаг 2. Выберите ось группировки верхнего уровня (роли, процессы или типы документов) и не смешивайте оси на одном уровне.
3. Шаг 3. Задайте глубину дерева — два-три шага до документа, и определите тип структуры по таблице выбора.
4. Шаг 4. Спроектируйте статусную модель страниц и триггеры обновления, привязав их к разделам.
5. Шаг 5. Настройте систему меток (статусные, тематические, технические) и перекрёстные связи между статьями.
6. Шаг 6. Назовите разделы словами реальных запросов сотрудников, а не внутренним жаргоном.
7. Шаг 7. Пропишите роли и права доступа, отдельно закрыв разделы с ПДн и зарплатой.
8. Шаг 8. Проверьте пустой макет на сценариях с замером времени — и только потом наполняйте контентом.

Проверка структуры до наполнения

Макет проверяют до того, как в него зальют контент, потому что переделать пустое дерево дёшево, а наполненное — нет. Метод называется card sorting, но суть простая: берёте 2-3 типовых сценария («новичок ищет, как оформить пропуск», «менеджер ищет регламент возврата», «кадровик ищет актуальную форму согласия на ПДн») и просите реального сотрудника найти нужное в пустой структуре. Засекаете время и число кликов.

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

Ошибки проектирования базы знаний и их цена

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

Смешение осей на одном уровне. Цена — переезд всей базы: материал подходит сразу под несколько разделов, его дублируют, при обновлении правят одну копию. Лечится только сведением верхнего уровня к одной оси, то есть повторным проектированием.

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

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

Запуск без статусной модели. Цена — потеря доверия: одна старая статья с отменённым порядком, на которой обжёгся сотрудник, обесценивает всю базу. Вернуть доверие дороже, чем заложить статусы на старте.

Дубли из copy-paste. Цена — рассинхрон на проверке: один факт скопирован в пять статей, обновили одну, четыре остались со старой формулировкой, и для кадровых документов это прямой риск при проверке ГИТ.

Мария Ж, юрист со стажем более 20 лет:
«Самая недооценённая ошибка — запуститься без владельцев разделов. Из коробки кажется, что база сама себя поведёт. Не поведёт. Раздел без хозяина устаревает первым, потому что спросить не с кого. Я на проектировании сразу прибиваю каждый раздел к конкретному человеку — это не бюрократия, это единственное, что держит базу живой через год.»

Стоимость проектирования и запуска базы знаний в КЭДО Добыто

Стоимость зависит от численности штата, выбранного тарифа и набора модулей — для кадровой базы обычно считают по числу сотрудников, которые будут в ней работать и подписывать документы. Проектирование структуры под кадровые процессы и связку с ознакомлением ЛНА входит в работы по внедрению.

Итоговая сумма зависит от численности персонала, глубины интеграции с учётной системой и объёма подключаемых модулей — актуальные тарифы сервиса Добыто помогут рассчитать точнее под вашу компанию. Для тарифа Корпорация стоимость рассчитывается индивидуально после оценки числа сотрудников и требований к SLA.

Выводы: как спроектировать базу знаний с нуля

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

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

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

Часто задаваемые вопросы

Как переделать уже наполненную базу знаний, не сломав ссылки?

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

Нужен ли отдельный методолог или структуру спроектирует кадровик?

Для базы на 5-8 верхних разделов достаточно кадровика или HR, который знает реальные запросы сотрудников. Отдельный владелец таксономии нужен, когда база растёт, появляются теги поперёк дерева и смешанная структура: без одного ответственного за правила именования и метки дерево и теги рассинхронизируются. Роль можно совмещать, но она должна быть закреплена за конкретным человеком, а не размазана по отделу.

Можно ли обойтись общим диском вместо базы знаний?

Пока материалов немного и ими пользуется несколько человек, папок на диске хватает. Диск ломается, когда нужны поиск по содержимому, версионность, разграничение доступа и контроль актуальности. Для кадровых документов диск не подходит с самого начала: на нём нет статусной модели, нет ограничения доступа к персональным данным и нет фиксации ознакомления с ЛНА.

Как связать базу знаний с ознакомлением сотрудников с ЛНА?

Раздел с ЛНА увязывают с системой электронного ознакомления. Обновился документ — по триггеру статья уходит на корректировку, после подтверждения рассылается сотрудникам, а факт ознакомления фиксируется с датой и подписью. По ст. 22 ТК РФ работника нужно ознакомить с ЛНА под подпись, и такая связка делает факт ознакомления доказуемым при проверке ГИТ.

Что делать с устаревшими статьями — удалять или архивировать?

Архивировать. Удаление рвёт входящие ссылки и историю изменений, а статус «архив» сразу показывает, что опираться на статью нельзя. Рабочее правило: страница, которую квартал никто не открывал и не редактировал, автоматически уходит в архив на разбор владельцем раздела.

Как понять, что структуру базы пора переделывать?

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