Права доступа: кто что видит и почему это решается до настройки

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

Почему это не вопрос безопасности

Формулировка «закрыть доступ» подразумевает защиту от чего-то. В реальности схема доступов описывает распределение ответственности.

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

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

Отсюда правило: схема доступов согласуется вместе с воронкой, на этапе архитектуры, а не после запуска. Как устроен этот этап — на странице хода внедрения.

Три модели, которые встречаются на практике

Первая — полная открытость внутри отдела. Все видят всё, руководитель видит всё и по другим отделам. Подходит небольшим командам и там, где сделки ведутся сообща.

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

Третья — строго своё. Менеджер видит только собственные сделки, передача происходит через руководителя. Применяется там, где база чувствительна или где отделы конкурируют за одних клиентов.

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

Что ломается при поздней настройке

Три вещи, и все три обходятся дороже настройки.

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

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

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

Именно поэтому роли и доступы входят в состав работ всех наших проектов, а в части из них выделены отдельным блоком решения — наравне с воронками и документами.

Что происходит при смене сотрудника

Самый частый практический случай и главная причина, по которой права вообще настраивают.

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

В проекте для поставщика сельхозтехники это было исходной задачей: клиентская база жила в личных телефонах менеджеров, и уход сотрудника означал потерю клиентов. После перевода работы в общий контур утрат данных при смене персонала стало ноль, а время передачи клиента новому менеджеру сократилось на 80%.

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

Как спроектировать схему за одну встречу

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

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

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

Что ещё входит в работы по внедрению — в разборе состава проекта.