База знаний для команды — Confluence, Notion или встроенное в портал

Если спросить 10 HR-менеджеров, где живут их документы по онбордингу, ответы вернутся: 4× Notion, 3× Confluence, 1× SharePoint, 1× «папка на Google Диске», 1× «честно говоря, я уже не уверена». «Не уверена» — наиболее частое конечное состояние любой инициативы по знаниям, оставленной дрейфовать.

Этот текст конкретно про HR-владельческие знания — onboarding-плейбуки, политики, описания ролей, бенефиты, how-to-гайды по HR-системам. Не про техническую документацию, не про продуктовые wiki, не про юридические договоры. Три места, где эти знания обычно живут, с честными tradeoff'ами.

Вариант A: выделенная KB внутри портала

Как выглядит: у портала есть вкладка «Знания». Статьи редактируются во встроенном редакторе (markdown или rich-text), организованы по категориям, ищутся через глобальный поиск портала, на них можно ссылаться с других страниц портала (карточек сотрудников, типов отсутствий и т.п.).

Плюсы:

• Живёт там, где сотрудники уже находятся. Вопрос в 11 утра «где политика отпусков» не требует помнить «это в Notion или Confluence». Это в том же приложении, через которое запрашивают отпуск.
• Права наследуются из модели сотрудников. Новички автоматически видят onboarding-статьи. Документы уровня руководителя скрыты от линейных. Никакого отдельного user-management'а.
• Результаты поиска включают и KB-статьи И людей, отделы, этажи офиса — один поисковый бокс находит «политика командировочных» и «человек, отвечающий за командировочные».

Минусы:

• Редактор обычно беднее, чем Notion или Confluence. Не пытайтесь писать здесь технические RFC.
• Нет graph-style backlinking (как в Notion) и иерархической глубины (как в Confluence spaces).
• Риск дублирования, если инженерка уже ведёт onboarding-style документы в своей wiki.

Подходит когда: хотите HR-знания интегрированными в опыт портала, и согласны держать инженерные документы в отдельном инструменте.

Вариант B: Notion

Как выглядит: Notion-workspace, в котором у HR верхнеуровневая страница «Корпоративный справочник» с подстраницами.

Плюсы:

• Лучший опыт авторинга в категории с большим отрывом. Inline-базы, embed'ы, лёгкое форматирование, комментарии, @-mentions.
• Cross-team дружественный: инженерка и HR могут писать в одном workspace с правами per page-tree.
• Шаблоны и шаблоны-шаблонов отлично подходят для повторяющихся структур (описания ролей, onboarding-последовательности).

Минусы:

• Права per-page. Каждый новый чувствительный документ — вопрос «у кого доступ», который надо разруливать вручную. Ошибки утекают политикой по компенсациям.
• Онбординг новичков требует выдать им Notion-доступ (платный seat), потом показать дорогу к Справочнику. Половина забудет URL через неделю.
• Поиск по enterprise Notion workspace становится неюзабельно шумным при ~500 страницах. HR-статьи закапываются под инженерными.
• Discoverability страдает: HR-статьи не появляются рядом с «политикой отпусков» ни в каком контексте кроме «вспомнил, надо зайти в Notion».

Подходит когда: компания уже тяжело использует Notion для всего, есть админ активно курирующий структуру Справочника, и вы согласны что adoption — «надо помнить зайти в Notion».

Вариант C: Confluence

Как выглядит: Confluence Space «People» или «HR» с деревом страниц.

Плюсы:

• Best-in-class для иерархических, версионированных, формально-ревьюируемых документов. Approval workflow, аудит истории страниц, зрелые права.
• Если компания уже использует Jira + Confluence, не нужно вводить новый инструмент.
• Лучше Notion для документов, требующих формального ревью/одобрения до публикации (политики, юридически-смежные, compliance-материалы).

Минусы:

• Авторинг неудобнее Notion. Page-шаблоны помогают; всё остальное — трение.
• Мобильная версия функциональна, но не любима.
• Модель «spaces» концептуально тяжёлая для маленьких компаний. Часто overkill.
• Cost-per-user складывается на 100+ headcount.

Подходит когда: у вас уже есть Confluence для инженерки, есть небольшая группа HR-админов, авторствующая большинство контента, и нужны формальные approval workflow (регулируемые отрасли, большие компании с compliance-требованиями).

Как выбрать

Простое дерево решений:

• <50 сотрудников, нет существующих привычек wiki: портальная KB. Наименьшее трение для adoption. Легко мигрировать позже если перерастёте.
• 50–200 сотрудников, уже на Notion: оставьте Notion как источник правды, но линкуйте HR-релевантные страницы с портала. Не пишите в двух местах.
• 50–500 сотрудников, уже на Confluence: оставьте Confluence, та же оговорка. Не поддавайтесь желанию мигрировать в Notion просто потому что Notion блестящее.
• Сильно регулируемые отрасли (финансы, госкомпании, медицина) при любом размере: Confluence выигрывает по audit trail и approval workflow. Портал может линковать, но не должен владеть.
• Чисто удалённые 200+: портальная KB И deeper wiki (Notion или Confluence), портал как «с чего начать», wiki как «где живёт глубина».

Ловушка дублирования

Что каждый HR-ops в итоге делает не так — пишет один и тот же контент в двух местах. Сначала пишут onboarding-политику в Notion, потом думают «но сотрудники её там не найдут, давайте и в портал положим». Теперь две копии, и они дрейфуют.

Фикс — выбрать один источник правды и сделать другой ссылкой. Если Notion — каноничный Справочник, в KB портала статья-заглушка «Onboarding-политика → см. в Notion» со ссылкой, а не копия. Если канонично — портал, Notion-space линкует на портал.

Звучит очевидно. Почти никто не делает. Половину аудитов HR-ops-стека мы находим одну политику в трёх местах с последними правками, разбросанными по ним.

Что значит «портальной KB достаточно»

Если идёте по портальному маршруту, планка для «достаточно хорошо»:

• Markdown или rich-text редактор с картинками, таблицами, внутренними ссылками.
• Статьи организованы в дерево категорий (глубина 1–2 — с лихвой).
• Поиск по статьям с ранжированием по recency + небольшой буст для HR-тегированного.
• Черновики, которые админы итерируют до публикации.
• «Обновлено» timestamp для читателей (чтобы видеть устаревшее).
• Мобильное чтение.

Фичи, которые портальной KB не нужны: graph-style backlinking, real-time co-editing, версионные ветки, AI-резюме. Звучит хорошо; не меняет adoption.

Подход DTPulse

Мы шипим встроенную KB с указанными фичами (markdown-редактор, иерархические статьи, внутренние ссылки, интеграция в глобальный поиск портала, черновики, мобильное чтение). Спроектировано для HR-специфичного контента, описанного выше. Мы не претендуем конкурировать с Notion или Confluence как general-purpose wiki — это неправильная битва.

Клиентам, уже инвестированным в Notion/Confluence, рекомендуем оставлять инженерный контент там и использовать нашу KB для HR-специфичного, на который портал естественно ссылается. Без миграций, без давления на консолидацию.

Связанное чтение

• Что такое корпоративный портал и когда он реально нужен компании
• Карта офиса в HR-системе — зачем она и как её сделать