как правильно завести сотрудников и настроить оргструктуру в битрикс24

зачем оргструктура влияет не только на визуал

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

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

На аудите я всегда сверяю оргструктуру с фактическим списком прав доступа по каждому отделу — расхождение находится в 7 из 10 компаний, которые не привлекали интегратора к первичной настройке. Обычно это не злой умысел, а просто накопившиеся точечные правки за месяцы работы.

как добавить сотрудника — короткая версия

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

Важный момент, который часто упускают: отдел нужно указать сразу при создании, а не «потом донастроим». Если завести человека без отдела, а затем перенести — часть автоматических правил (роботы, назначенные по отделу) не подхватят сотрудника, пока кто-то вручную не проверит правила заново.

структура «плоско» или «по подчинению» — как выбрать

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

Иерархическая структура (отдел → подотдел → сотрудник, несколько уровней руководителей) подходит компаниям с 2-3 уровнями управления: РОП → старшие менеджеры → менеджеры. На моих проектах граница простая: если у вас уже есть люди с реальным правом принимать решения по своей группе (не просто «старший по стажу», а тот, кто реально управляет) — им нужен отдельный уровень в структуре, иначе права доступа придётся выставлять вручную, в обход логики иерархии.

назначение руководителя отдела — где чаще всего ошибаются

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

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

права доступа: наследуются или назначаются заново

В стандартной логике Битрикс24 права в CRM настраиваются ролями (например, «менеджер продаж», «руководитель отдела продаж»), а не индивидуально под каждого сотрудника. Роль привязывается к отделу или к позиции в иерархии — «руководитель видит сделки своего отдела и всех вложенных подотделов» настраивается один раз в роли, а не переписывается при каждом новом сотруднике.

Практический совет: не создавайте роль под конкретного человека («права для Иванова»). Создавайте роль под должность («права руководителя отдела продаж») и назначайте её всем, кто эту должность занимает. Когда Иванов уволится, а на его место придёт Петров — роль останется, поменяется только человек в карточке отдела.

типовые ошибки при построении структуры

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

что делать при реорганизации без потери данных

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

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

чек-лист онбординга нового сотрудника

Само добавление аккаунта — только первый шаг. На моих проектах онбординг нового менеджера состоит из пяти пунктов, которые я прохожу в первый рабочий день: 1) аккаунт создан, отдел и должность указаны; 2) назначена нужная роль доступа CRM, а не «дали доступ администратора, потому что быстрее»; 3) сотрудник добавлен в рабочие группы и чаты, которые реально нужны его отделу; 4) настроены уведомления о новых лидах/задачах, если это часть его обязанностей; 5) проведён короткий инструктаж по интерфейсу — 15-20 минут, не больше, иначе человек забудет половину до того, как начнёт применять.

Пропуск пункта 2 — самая частая проблема, которую вижу на аудитах: новому сотруднику из спешки выдают права «как у соседа», без проверки, что именно нужно конкретно ему. В 6 из 10 случаев это приводит к тому, что рядовой менеджер видит чужие сделки или, наоборот, не видит нужные ему функции месяцами, пока кто-то не заметит проблему случайно.

отпуска, больничные и временное отсутствие

Отдельная тема — что происходит со сделками сотрудника, который временно недоступен. Если у него есть срочные задачи с дедлайном на время отпуска, автоматических уведомлений «руководителю» о просрочке недостаточно — я всегда настраиваю на такой случай понятного заместителя, который получает доступ к горящим задачам на этот период.

Встроенный функционал отсутствий в Битрикс24 показывает статус сотрудника коллегам (в отпуске, на больничном), но не переназначает его сделки и задачи автоматически — это ручное действие. Хорошая практика: перед плановым отпуском сотрудник сам помечает в сделках, кто подхватывает горящие вопросы, а не оставляет это на усмотрение руководителя постфактум.

связанные материалы

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

частые вопросы