Матрица доступов: примеры для менеджера, бухгалтера и руководителя, с разбором прав смотреть, менять и выгружать. Шаги, ошибки, чеклист.
Во многих компаниях права выдают «на глаз»: новому сотруднику нужно быстро начать работу, и ему открывают почти все, «чтобы не мешать». Через пару месяцев уже никто не помнит, почему у менеджера есть доступ к бухгалтерским данным, а у стажера - к выгрузке клиентской базы.
Матрица доступов раскладывает права по полочкам: кто, к чему и что именно может делать. По сути это таблица, где по строкам идут роли (например, менеджер, бухгалтер, руководитель), а по столбцам - данные и действия. Когда матрица есть, споры решаются быстрее: права выдаются не по просьбе в чате, а по понятному правилу.
На практике почти все упирается в три операции: смотреть, менять и выгружать.
Почему это важно:
Простой пример: менеджеру дали право менять реквизиты контрагента «на всякий случай». Он исправил ИНН со слов клиента, и бухгалтерия позже не смогла провести платеж. Матрица заранее фиксирует границы: менеджер может смотреть и предлагать правку, но менять может только бухгалтер.
В итоге матрица дает две вещи: понятные границы и ответственность. Становится ясно, кто делает работу, кто проверяет, и какие данные нельзя трогать без причины.
Матрица доступов держится на трех простых вещах: кто человек в системе (роль), к чему он обращается (объект) и что именно он может сделать (действие). Если не разделить эти понятия, права быстро превращаются в хаос.
Роль - это набор типовых прав для задачи, а не для конкретного человека. Пользователь - конкретный сотрудник, которому назначают одну или несколько ролей. Группа - удобный способ назначать роли сразу нескольким людям (например, всем менеджерам). Владелец данных - тот, кто отвечает за запись или документ по смыслу (автор заявки, ответственный за клиента) и часто получает дополнительные права именно на свои записи.
Объект доступа - это то, к чему применяются правила. В реальной системе объектами обычно становятся разделы и сущности, которые можно открыть и с которыми можно что-то сделать: карточка клиента, счет, договор, справочник товаров, отчет по продажам. Лучше называть объекты так, как их видит сотрудник в интерфейсе: тогда матрицу проще читать.
Действия - конкретные операции над объектом. Чаще всего хватает базовых уровней:
Экспорт стоит выделять отдельно, даже если формально это тоже «чтение». Выгрузка в файл или отправка отчета наружу повышает риск утечки, поэтому для нее часто задают отдельные ограничения: только по своему отделу, только агрегированные данные, только по запросу.
Принцип минимально необходимого доступа означает простую вещь: сотруднику дают ровно те права, которые нужны для ежедневной работы, и не больше. Если сомневаетесь, лучше начать с меньших прав и добавлять позже по понятному запросу, чем сразу открыть лишние данные и потом разбираться с последствиями.
В матрице доступов эти три действия выглядят простыми, но за каждым из них стоят разные риски.
Смотреть - это не только «открыть карточку». Иногда чтение уже раскрывает чувствительные данные: зарплаты, скидки, личные телефоны, паспортные данные, себестоимость, маржинальность. Когда «просто посмотреть» становится привычкой, границы размываются, а утечку потом сложно отследить.
Менять - любые действия, которые влияют на учет, деньги или ответственность. Даже мелкая правка (смена реквизитов, перенос оплаты, корректировка статуса, изменение цены) может привести к потере денег или спору с клиентом. Для таких операций часто вводят правила: правка только по заявке, с подтверждением руководителя или с обязательным комментарием.
Выгружать - это уже «вынести данные наружу»: файл, таблица, отправка на почту, копирование списка. Экспорт отличается от просмотра отчета тем, что выгрузку проще переслать, сохранить «на потом» и объединить с другими источниками. Поэтому выгрузку обычно ограничивают сильнее, чем просмотр.
Полезно заранее определить, какие данные можно видеть только в системе без копирования, какие можно выгружать только агрегированно (итоги без персональных данных), а какие - полностью, но только конкретным ролям и с журналом действий.
Отдельная категория - массовые действия: импорт, пакетные правки, загрузка списков, массовое удаление. Они экономят время, но одна ошибка в файле или фильтре меняет сотни записей сразу. Обычно такие операции дают только опытным сотрудникам и добавляют защиту от случайности: предпросмотр изменений, лимиты на количество строк, подтверждение вторым шагом и возможность отката или резервную копию.
Начинайте не с таблицы, а с реальной работы людей. Матрица полезна только тогда, когда роли и права совпадают с тем, что сотрудники делают каждый день, а не с тем, как выглядит оргструктура.
Выделяйте роли по задачам и ответственности, а не по фамилиям. Если два человека делают одно и то же и несут одинаковые риски, им обычно подходит одна роль. Отдельные роли нужны там, где различаются данные (например, зарплата) или важно подтверждение (например, проведение платежей).
Составьте список разделов и данных, которые есть в вашей системе. Обычно это клиенты и сделки (CRM), счета и договоры, зарплата и кадровые данные, отчеты и выгрузки, настройки и справочники.
Дальше уточните уровень детализации: «все клиенты» или «только свои», «все счета» или «только по своему юрлицу».
Действия лучше формулировать простыми глаголами: создать, изменить, удалить, провести, согласовать, экспортировать. Отдельно договоритесь, что именно считается «экспортом»: выгрузка в Excel/CSV, отправка отчета на почту, доступ к API, копирование больших списков.
Сделайте таблицу: строки - роли, столбцы - разделы и действия. На пересечении ставьте «можно/нельзя» и, если нужно, условия (например, «только свои сделки»).
Чтобы не запутаться, удобно идти по порядку: сначала «смотреть», потом «менять», затем «удалять». Отдельно отметьте «выгружать» для чувствительных данных, задайте фильтры (по отделу, проекту, юрлицу) и зафиксируйте, кто утверждает операции, если требуется.
Финальное слово обычно за владельцем процесса (например, руководитель продаж), вместе с администратором системы и ИБ. Пройдитесь по нескольким сценариям: «менеджер ушел в отпуск», «новый сотрудник», «ошибка в счете».
Если вы описываете процессы и роли в TakProsto, матрицу удобно держать рядом с документацией в режиме планирования и обновлять при изменениях.
Менеджеру по продажам нужен доступ, который помогает вести клиента от первого контакта до оплаты, но не дает возможности случайно (или намеренно) менять чувствительные данные. Обычно это роль с широким просмотром по своей воронке и аккуратными правами на изменения.
Как правило, менеджеру достаточно видеть то, что связано с его клиентами: карточки клиентов и контактов, свои сделки и этапы, задачи и комментарии, историю общения, личные отчеты по плану и факту.
Важно разделить «видеть» и «видеть всех». Частый вариант по умолчанию: менеджер видит только свои сделки и клиентов, а доступ к чужим дают точечно (например, на время подмены коллеги).
Разрешенные изменения обычно понятны и безопасны: обновлять контакты клиента, фиксировать результаты звонка, менять статус сделки, создавать и править коммерческие предложения в рамках шаблонов, добавлять товары в сделку в пределах полномочий.
Ограничения чаще всего ставят на чужие сделки и карточки клиентов (кроме передачи или подмены), скидки и условия (например, только в пределах лимита, выше - через согласование), реквизиты и платежные данные (часто зона бухгалтерии), а также на изменение шаблонов и справочников.
Пример лимитов: менеджер может дать скидку до 5% сам, а все выше - только после подтверждения руководителем. Так продажи не тормозятся, но маржа остается под контролем.
С выгрузками стоит быть осторожнее: даже «безобидный» экспорт клиентов может стать утечкой базы. Практичный вариант - разрешать выгрузку только своего сегмента (свои клиенты, свои сделки, свой отчет) и ограничивать формат и объем. Если нужен экспорт по отделу или по всей базе, лучше делать это по запросу и с согласованием.
Дополнительно обычно запрещают массовое удаление и массовое редактирование, а также закрывают доступ к изменению справочников. Это снижает риск, что одним действием будет испорчена воронка или данные в классификаторах.
Бухгалтеру нужен доступ к документам, на которых держится учет, но ему не обязательно видеть все подряд. В матрице доступов для этой роли важно разделить «просмотр» и «правку», а также заранее описать правила выгрузок: именно через выгрузки чаще всего утекают лишние данные.
По просмотру бухгалтеру обычно достаточно финансового контура: первичные документы (накладные, счета, акты), платежи и банковские операции, карточки контрагентов и договоры. Если в компании несколько юрлиц, доступ лучше ограничить только своими организациями.
По изменениям бухгалтеру чаще всего нужны права, которые влияют на корректность учета и отчетности: вносить и исправлять проводки (а в закрытом периоде - только по согласованию), менять статус оплаты, редактировать реквизиты с подтверждением, формировать закрывающие документы, исправлять ошибки в первичке без права «тихого» удаления.
Есть зоны, которые лучше отделить даже от бухгалтерии «по умолчанию». Зарплата и кадровые данные обычно доступны только конкретным сотрудникам: расчетчику, HR или руководителю. Управленческие скидки, маржинальность и внутренние отчеты по прибыли тоже не всегда нужны для бухучета и могут жить в отдельной роли.
С выгрузками помогает простой регламент: что выгружается, в каком формате, как часто и кому передается. Обычно выделяют сценарии для банка (платежки и реестры), для налоговой (декларации и книги), для аудитора (выборки документов). Логи выгрузок полезны не меньше самих ограничений.
Контроль критичных действий лучше закрепить заранее. Например, правку банковских реквизитов контрагента подтверждает главный бухгалтер или финансовый директор, а удаление документов заменяют на «аннулирование» с обязательным комментарием и записью, кто и когда это сделал.
Руководителю важно видеть картину целиком, а не тонуть в первичке. В матрице доступов для этой роли обычно закрепляют право читать сводные показатели по компании или своему блоку: выручка, маржа, дебиторка, выполнение планов, просрочки, ключевые риски. Полезны отчеты в разрезе отделов и сотрудников, чтобы быстро находить узкие места.
При этом руководитель редко должен менять операционные данные. Его зона ответственности - правила и рамки: цели, лимиты, маршруты согласования, назначение ответственных. Это снижает риск ошибок и конфликтов, когда один человек может и менять данные, и утверждать результат.
Обычно для роли «руководитель» фиксируют такие действия: смотреть отчеты по своим подразделениям, менять цели и лимиты, настраивать правила согласования, утверждать заявки и документы без ручного «проведения» и правки строк, оставлять статусы и комментарии по итогам контроля.
Чего лучше не выдавать: правки в первичных документах, ручное проведение, возможность удалять записи, менять реквизиты контрагентов «в обход» ответственных, массовые корректировки задним числом.
Выгрузка данных руководителю обычно нужна, но в безопасном виде: агрегированные данные и утвержденные отчеты. Например, можно разрешить экспорт ежемесячного P&L по филиалам и списка просроченной дебиторки, но запретить выгрузку полной базы клиентов с телефонами и внутренними комментариями.
Особый случай - временные расширенные права для проверки или аудита. Их лучше выдавать с ограничением срока (например, 48 часов), области (один отдел или период) и обязательным журналом действий, а также с понятным ответственным за выдачу и отзыв.
Так матрица доступов остается понятной: руководитель управляет решениями и правилами, а не переписывает данные руками.
Выгрузка - самый частый путь утечки данных: файл легко переслать, сохранить на личный диск или потерять в общем чате. Поэтому в матрице доступов выгрузку лучше описывать отдельно от просмотра отчета на экране.
Сначала решите, где фиксировать факт выгрузки. Для небольшой компании иногда хватает журнала: кто выгрузил, что именно, когда и с какой целью. Если процессы строже, делайте выгрузку только по заявке или хотя бы требуйте обязательный комментарий, чтобы всегда был контекст.
Важно разделять права: «смотреть отчет» и «выгрузить в файл» - разные уровни риска. На экране данные можно ограничить и частично скрыть, а в файле человек получает полный набор строк и может использовать его дальше без контроля.
Хорошая практика - ограничивать выгрузки по полям. Например, менеджеру для сверки достаточно ФИО и статуса оплаты, но не нужны паспортные данные, детализация зарплат или маржинальность по каждой позиции. Чувствительные поля лучше скрывать или маскировать (например, показывать только последние 4 цифры).
Дальше задайте рамки по периодам и объему. Это снижает ущерб даже при ошибке: лимит по датам (не больше 30-90 дней), лимит по строкам (например, до 5 000 записей), только преднастроенные шаблоны отчетов вместо «выгрузи все», и ограниченный список форматов.
Чтобы избежать споров, используйте короткий шаблон формулировки доступа: кто (роль или сотрудник), что (какой отчет), зачем (цель), на какой срок, какие условия (поля, период, объем, запись в журнале).
Пример: бухгалтеру можно выгружать реестр оплат за месяц для банка, но без персональных данных сотрудников и только по заявке руководителя финслужбы.
Самая частая проблема - слишком широкая роль «на всех». Когда появляется единый «сотрудник» с почти полным доступом, матрица доступов превращается в формальность. Люди видят лишнее, случайно меняют данные, а при разборе инцидента трудно понять, кто и зачем это сделал.
Вторая ошибка - путать роль и должность. Один и тот же человек может быть менеджером в одном процессе и ответственным за склад в другом. Если закрепить права только по должности, вы либо дадите лишнее, либо не дадите нужное. Надежнее мыслить задачами: что человек делает именно в этом процессе и к каким объектам обращается.
Отдельная боль - выгрузка данных. Ее часто считают безобидной, хотя на практике это означает унести базу клиентов или финансовые отчеты в файл и отправить куда угодно. Например, менеджеру дали право на экспорт «чтобы удобно работать», и через неделю по почте уходит таблица со всеми клиентами, ценами и скидками - без ограничений и без учета.
Чаще всего забывают предусмотреть:
Еще одна типичная ошибка - «дали доступ и забыли». Сотрудник ушел в другой отдел, а права остались. Или подрядчик закончил проект, но его учетная запись активна. Если вы часто меняете роли и доступы (например, при создании внутренних сервисов), назначьте ответственного и заведите простой порядок: кто запрашивает, кто согласует, как пересматриваются роли и что делается при увольнении.
Перед тем как включать доступы всем сотрудникам, пройдитесь по короткому списку. Он помогает поймать типовые проблемы, из-за которых потом появляются «лишние права», утечки и споры.
Проверьте роли: у каждой должен быть владелец (обычно руководитель функции или процесса) и понятная цель. Если цель звучит как «на всякий случай», роль лучше пересобрать.
Дальше пройдитесь по ключевым разделам и зафиксируйте минимум действий: смотреть, менять и выгружать. Часто забывают, что «менять» - это не только редактировать, но и удалять, проводить, отменять, согласовывать. По выгрузкам заранее договоритесь, что именно считается выгрузкой (Excel, PDF, API, пересылка отчета) и кто может это делать.
По выгрузкам отдельно проверьте: лимит по объему, ограничение по полям (без паспортных данных, лишних контактов, зарплат), ограничение по сроку, отметки в отчетах и выдачу выгрузок только там, где есть бизнес-необходимость.
После этого убедитесь, что есть контроль и понятный порядок. Нужен журнал изменений прав: кто и когда менял доступ и что именно изменилось. И нужен простой процесс запроса доступа: куда обратиться, кто согласует, на какой срок и что будет основанием для отказа.
И последнее - пересмотр прав. Запланируйте регулярную проверку (например, раз в квартал) и обязательную проверку при смене должности, увольнении или переводе между отделами. Без этого матрица быстро устаревает и превращается в набор случайных исключений.
Начните с простого: соберите черновик матрицы на одну страницу. Пусть там будут ключевые роли, основные объекты (клиенты, счета, договоры, отчеты) и три действия (смотреть, менять, выгружать). Такой черновик проще обсуждать, чем «идеальный документ» на 20 страниц.
Дальше согласуйте матрицу с владельцами процессов - обычно это руководители продаж, финансов и операционных функций. Важно, чтобы они подтвердили не только «кому можно», но и «кому точно нельзя», особенно для выгрузок.
После согласования перенесите роли в систему и проверьте на тестовых пользователях. Проверка должна быть практической: сможет ли менеджер открыть карточку клиента, сможет ли бухгалтер исправить реквизиты, сможет ли руководитель скачать отчет, и что произойдет при попытке сделать лишнее.
Минимальный план внедрения:
Регламент лучше держать максимально простым: кто заводит заявку, кто согласует, сколько времени на выдачу, что делать при срочном отзыве, как фиксировать исключения (временный доступ на неделю, доступ только к одному отчету).
Матрица - это не «настроил и забыл». Планируйте пересмотр раз в квартал, а еще после любых изменений: новые продукты, новая схема продаж, новая бухгалтерия, появление новых отчетов. Хороший сигнал к пересмотру - когда люди начинают просить «просто дайте админку, так быстрее».
Если вы проектируете внутренний сервис и хотите быстрее проверить роли и экраны, это удобно сделать в TakProsto (takprosto.ai): описать сценарии в режиме планирования, собрать прототип и при необходимости вернуться к предыдущей версии снапшотом. Когда схема устроит, можно выгрузить исходный код и передать результат в обычную разработку.
Матрица доступов нужна, чтобы права выдавались по понятному правилу, а не «на глаз». Она помогает сразу видеть, кто что может смотреть, менять и выгружать, и быстрее разбирать спорные ситуации.
Начните с ролей по задачам, а не по фамилиям, затем перечислите объекты в системе теми словами, как их видят сотрудники в интерфейсе. После этого определите действия (смотреть, менять, выгружать и другие) и проставьте условия вроде «только свои» или «только по своему юрлицу».
Потому что выгрузка превращает данные в файл, который легко переслать, сохранить «на потом» или объединить с другими источниками. Просмотр внутри системы обычно проще контролировать, а файл часто выходит из-под контроля почти сразу.
Дайте доступ по принципу минимально необходимого: сначала только то, что нужно для ежедневной работы, без «на всякий случай». Если доступ все же нужен, выдавайте его с условиями: срок, область (отдел, период), обязательный комментарий и фиксация в журнале.
Менеджеру обычно достаточно видеть и вести своих клиентов и сделки, менять статусы, задачи и безопасные поля, но не трогать финансово критичные вещи. Реквизиты, платежные данные, крупные скидки и массовые операции лучше оставить бухгалтерии или выдавать только через согласование.
Частый вариант — разрешить выгрузку только по своему участку: свои клиенты, свои сделки, свои отчеты, с ограничением объема и периода. Для выгрузки по отделу или по всей базе лучше требовать согласование и фиксировать цель, чтобы не получить утечку базы «для удобства».
Бухгалтеру нужны права на финансовый контур: документы, платежи, контрагентов и договоры, но обычно в рамках своего юрлица. Критичные правки стоит делать по правилам, особенно в закрытых периодах, а удаление заменять на аннулирование с комментарием, чтобы сохранялся след действий.
Потому что руководитель чаще должен управлять правилами и контролировать результаты, а не править первичку руками. Если руководитель может и менять данные, и утверждать итог, растет риск ошибок и конфликтов, а разбор инцидентов становится сложнее.
Выдавайте такие права на ограниченный срок и с понятной областью доступа, например на один отдел или период. Полезно заранее договориться, кто утверждает такие доступы и как они автоматически отзываются, чтобы временное не стало постоянным.
Самый быстрый чек — посмотреть, нет ли роли «на всех» с почти полным доступом, и отдельно проверить права на выгрузку. Затем убедиться, что есть журнал выдачи и изменения прав, понятный процесс запросов и регулярный пересмотр прав при переводах и увольнениях.
