В крупных командах проблема с правами доступа превращает базу знаний в минное поле: один сотрудник видит лишнее и случайно меняет критические документы, другой не может найти нужный регламент из-за запутанных настроек, нервничает и дёргает коллеги и руководителей. Администраторы теряют часы, вручную настраивая доступы каждому новичку, подрядчику или гостю как при добавлении, так и при удалении, рискуя что-то оставить. Всё усугубляется отсутствием привязки к оргструктуре. Эта рутина съедает человеко-дни на поддержание порядка вместо создания ценного контента.
Ролевая модель в TEAMLY — это способ задать понятные, масштабируемые правила доступа для всей компании: от ста человек до нескольких тысяч. Она решает классическую боль крупных команд: как давать людям ровно столько прав, сколько им нужно для работы, не превращая базу знаний в хаос и не рискуя утечками.
Традиционно начнём с Confluence, которая по многим причинам стала стандартом де-факто в организации базы знаний для многих компаний.
Зачем менять Confluence на TEAMLY
Многие команды привыкли к Confluence: страницы, пространства, отдельные настройки прав — знакомая и, на первый взгляд, понятная модель. Но в России с ней есть проблемы — и не только в том, что знания, включая персональные данные, нужно хранить на территории страны. С самими правами и их настройкой тоже не всё гладко и удобно.
TEAMLY как отечественная платформа управления знаниями и обучением даёт не только юридически комфортный контур, но и гибкую правовую модель, которая изначально спроектирована под российские процессы, оргструктуры и регламенты согласования. При этом привычные сущности — пространства, диски, разделы, документы — никуда не делись, так что переход с Confluence или Notion не вызывает у пользователей и администраторов когнитивного диссонанса.
Базовые сущности: пространства и диски
В TEAMLY доступы завязаны на несколько типов объектов:
Пространства — тематические области (отделы, проекты, продукты), внутри которых живут статьи базы знаний и другие материалы.
Диски — логическое хранилище документов, файлов и сопроводительных материалов, которое можно выделить под проект, департамент или тип контента.
Права пользователей задаются именно на этих уровнях, а дальше в дело вступают механизмы наследования и уточнения доступа для отдельных документов. Это позволяет крупной команде держать единую структуру, но показывать каждому сотруднику только то, что ему действительно нужно.
Почему критично удобно управлять доступом
Грамотная модель назначения ролей и прав — это не только про безопасность, но и про скорость работы команды.
Во-первых, так обеспечивается конфиденциальность: информацию не увидят те, кому видеть её не положено.
Во-вторых, у сотрудников не возникает вопросов о том, где найти тот или иной шаблон отчёта, регламент, FAQ — права даются не каждому, а группе, поэтому риск случайного сокрытия информации от пользователя минимален.
TEAMLY использует централизованную базу пользователей и интеграции с корпоративными системами (например, с Active Directory), поэтому изменения в оргструктуре (перевод в новый отдел, смена руководителя) автоматически отражаются в доступах. Это снижает нагрузку на ИТ и уменьшает число ручных операций с правами.
Типы пользователей: сотрудник и гость
Первый срез ролевой модели — тип пользователя, который задаётся при приглашении в систему.
Сотрудник — основной пользователь TEAMLY, который работает с базой знаний, обучением и проектами. Он может быть встроен в оргструктуру, входить в отделы и группы, получать доступ по ролям и наследованию. При этом сотрудник может и не состоять в штате — это только роль.
Гость — внешний консультант, подрядчик или представитель партнёрской компании, чьи возможности сознательно ограничены. Гостю можно открыть доступ к конкретным статьям, пространствам или курсам, но он не видит общую структуру базы знаний компании и не получаит прав на административные операции.
Такое разделение на сотрудников и гостей помогает сразу отстроить безопасный периметр: штатным пользователям доступен весь набор действий, а для внешних изначально задаётся минимально достаточный набор прав.
Роли внутри контента: читатель, редактор, администратор
Второй уровень — роли, которые назначаются в конкретных пространствах, дисках или разделах. Они определяют, что человек может делать с контентом:
Читатель может просматривать материалы, а при необходимости оставлять комментарии. Это базовая роль для большинства сотрудников, которым важен доступ к знаниям без риска что‑то случайно сломать.
Редактор создаёт и изменяет контент: пишет статьи, обновляет инструкции, переносит документы, работает с версиями. При этом редактор не управляет правами других пользователей и не вмешивается в общую структуру базы знаний.
Администратор обладает максимальным набором полномочий: может управлять структурой, назначать роли, настраивать наследование доступа и архивировать материалы.
Комбинация типов пользователей и ролей позволяет, например, сделать внешнего эксперта гостем‑редактором в одном проектном пространстве и одновременно держать его читателем в общих обучающих материалах.
Правовая модель: доступы, права, полномочия
Если ролевая модель отвечает за «кто» и «на каком уровне», то правовая модель в TEAMLY описывает «к чему» и «что именно можно делать». Она включает три взаимосвязанных слоя:
Уровни доступов: пространство, диск, папка, документ, отдельная статья базы знаний или курс обучения.
Права на взаимодействие: просмотр, комментирование, редактирование, удаление, публикация, пометка как официальный документ и т.п.
Расширенные административные полномочия: управление пользователями в контуре, настройка интеграций, резервное копирование, аналитика использования.
Именно сочетание этих слоёв делает модель гибкой: один и тот же человек может быть администратором диска «Юридические документы», редактором в пространстве «Обучение продажам» и читателем во всех остальных разделах.
Наследование и точечная настройка прав
Для крупных компаний ключевой вопрос — как не утонуть в ручной настройке доступов. В TEAMLY проблему решает наследование прав и работа с группами:
Права можно выдать на верхнем уровне (пространство или диск), а далее они автоматически наследуются вложенными папками и докуме��тами.
В отдельных случаях наследование можно переписать правами на специфический доступ для чувствительных разделов — например, личные дела сотрудников или проекты под NDA.
Особенно удобно и логично выглядит назначение прав отделам, соответствующим оргструктуре организации (Служба поддержки, отдел продаж) и функциональным группам, созданным по разным признакам для удобства назначения прав доступа (Руководители отделов, Авторы, Наставники).
В случае, когда нужно выдать права новому сотруднику, достаточно внести его в соответствующие группы. А чтобы отнять права — удалить из групп. Полное прекращение доступа к базе знаний тоже возможно. И это не удаление аккаунта, как можно бы было подумать.
Пример: поддержка и база знаний
Служба поддержки — один из ключевых бенефициаров чёткой ролевой модели.
Для линии первой поддержки создаётся пространство «Helpdesk», где сотрудники работают как читатели: у них всегда под рукой актуальные скрипты, ответы на частые вопросы и инструкции по продукту.
Редакторы в этом пространстве — методологи, старшие специалисты поддержки, руководители групп, менеджеры продуктов — обновляют контент по результатам новых кейсов и изменений в продукте.
Администраторы отвечают за структуру: разбивают разделы по продуктам и уровням поддержки, архивируют устаревшие статьи и следят, чтобы права новичков соответствовали их задачам.
В результате операторы не редактируют критические регламенты на ходу, но при этом всегда работают с актуальной версией базы знаний.
Пример: продажи и доступ к данным
Отдел продаж обычно работает с чувствительными данными клиентов и планами по выручке.
В TEAMLY для продаж создаётся отдельное пространство с материалами: скрипты, презентации, коммерческие предложения, победные кейсы.
Менеджеры выступают читателями для финансовых прогнозов и KPI, но могут быть редакторами в разделе «Кейсы» или «База скриптов», где постоянно собирают обратную связь и уточняют формулировки.
Руководители продаж и финансовые аналитики получают расширенные права: доступ к отчётам, аналитике, сводным таблицам и интеграциям с CRM.
Так достигается баланс: команда продаёт на основе прозрачных данных, но доступ к стратегическим цифрам остаётся только у ограниченного круга лиц.
Пример: обучение и онбординг новичков
TEAMLY из коробки совмещает базу знаний и модуль обучения, что помогает завязать права на реальные процессы онбординга.
Для новых сотрудников создаётся пространство «Onboarding» в каждом конкретном подразделении, где собраны курсы, тесты, регламенты и инструкции.
Новички получают роли читателя и участника курсов именно в этом контуре, не имея доступа к внутренним проектам до завершения ключевых этапов обучения.
Методологи и HR выступают редакторами и администраторами: обновляют программы, отслеживают прогресс сотрудника и регулируют, какие материалы становятся доступны мо мере прохождения курсов.
Это тоже реализуется не индивидуально, а через группы пользователей. Новичок последовательно добавляется в группы со всё более широким доступом. Благодаря этому онбординг становится управляемым: права доступа привязаны к этапам обучения, а не только к дате выхода человека на работу.
Пример: работа с внешними подрядчиками
Один из частых сценариев — совместные проекты с агентствами, консультантами и студиями разработки.
Для каждого клиента или проекта создаётся отдельное пространство, куда добавляются как внутренняя команда, так и внешние участники.
Внешние специалисты приглашаются как гости и получают роль редактора только внутри этого пространства: они могут вести документацию по проекту, согласовывать материалы и оставлять комментарии.
Доступ к остальным пространствам компании остаётся закрытым, а внутренние обсуждения и документы, не относящиеся к проекту, не отображаются гостям вообще.
Такой подход позволяет вести совместную работу в единой системе, не размазывая контент по сторонним сервисам и не рискуя раскрытием лишней информации.
Пример: минимизация рисков при увольнении
Когда сотрудник уходит, важно не «выдернуть провод из розетки», а аккуратно прекратить все его доступы.
Так как права завязаны на отделы, группы и роли, достаточно вывести человека из оргструктуры и отключить его учетную запись.
Он сразу теряет доступ к закрытым пространствам и дискам, но все созданные им документы и статьи остаются в системе и передаются под ответственность других администраторов.
Если нужно сохранить человеку ограниченный доступ к части корпоративных материалов (например, для временного консультирования после увольнения), его можно перевести в тип гость и оставить роль читателя в необходимых разделах.
Расширенные административные права
Для тимлида или руководителя направления важно видеть картину целиком и при этом не становиться «бутылочным горлышком» для всех прав в своём домене.
В TEAMLY можно выдавать расширенные админ‑права, отвечающие за управление конкретным набором пространств или дисков, а не всей системой.
Такой человек сможет создавать новые пространства под проекты, приглашать туда сотрудников, настраивать ролевую модель и следить за структурой, не трогая соседние домены.
Это особенно полезно в компаниях с матричной структурой, где у каждого проектного офиса или продуктовой команды есть свой «мини‑администратор» в рамках общей платформы.
Ролевая и правовая модели в TEAMLY превращают управление доступами из нудного и долгого процесса в минутное дело. В результате читатели, редакторы и администраторы получают ровно столько прав, сколько нужно для задач, а гибкая настройка учитывает специфику каждой команды. Сокращение рутины ведёт к уменьшению выгорания,
А редакторы администраторы базы знаний получают дополнительное время для работы над контентом и структурой.
