Рабочие файлы: шаблон и пример
- Пустой протокол прав и проверок — скачать HTML · открыть
- Заполненный учебный пример — скачать HTML · открыть
Пустой HTML можно заполнить в браузере и сохранить через печать в PDF. Ввод не сохраняется автоматически; сначала сохраните заполненный результат. Учебный пример содержит вымышленные данные.
Сотрудник нашёл на полке девять единиц вместо десяти. Чтобы сообщить о расхождении, ему нужен доступ к результату пересчёта. Чтобы изменить учётный остаток, требуется отдельное полномочие и основание. Если оба действия доступны всем, разница может исчезнуть из программы раньше, чем станет понятна её причина.
Рабочая матрица отвечает на пять вопросов: кто выполняет действие, над какими данными, при каком условии, кто подтверждает решение и где остаётся след. В этой статье — методика для владельца склада и руководителя операций. Названия ролей ниже условные: это распределение ответственности, которое нужно сопоставить с настройками вашей системы.
Сначала заполните матрицу
В шаблоне есть паспорт конфигурации, десять действий, условия согласования, десять положительных и отрицательных проверок, карточка временного доступа и решение о допуске. Светлые поля можно заполнить в браузере, затем распечатать или сохранить через «Печать → PDF». Автоматического сохранения нет. Пример заполнен вымышленными данными; его результаты не являются испытанием Skirbo.
Начните с одного склада и конкретной группы сотрудников. Запишите точные действия из их смены, добавьте область данных — клиент, склад, кабинет, состояние заказа — и назначьте принимающего результат. Только после этого сопоставляйте строки с настройками программы. Если нужное ограничение пока не проверено, отметьте его как «не проверено» и не разрешайте соответствующую операцию.
Три разные границы доступа
Кнопка в меню показывает, куда можно перейти. Она ещё не отвечает на вопрос, что сотрудник сможет сделать внутри и чьи данные увидит. Для каждой строки матрицы проверьте три границы.
| Граница | Пример разрешения | Отрицательная проверка |
|---|---|---|
| Раздел | Сборщику открывается очередь заданий | Не открывается управление сотрудниками |
| Действие | Можно записать фактическое количество при пересчёте | Нельзя самостоятельно применить корректировку |
| Данные | Разрешены задания клиента A на складе W1 | Заказ, файл или этикетка учебного клиента B не доступны |
Такое разделение соответствует рекомендациям OWASP: выдавать права по рабочей потребности, проверять разрешение при каждом запросе и обеспечивать контроль на стороне сервера. Скрытая кнопка полезна для интерфейса, но не заменяет отказ в недопустимом действии. Источник: OWASP Authorization, проверено 31.10.2026.
Как распределить действия между людьми
Ниже — исходный вариант для обсуждения. В вашем складе должности могут называться иначе. «После согласования» означает, что есть конкретное решение другого уполномоченного человека; наличие автоматического согласования в программе нужно проверить.
| Действие | Исполнитель | Кто подтверждает | Что ограничить |
|---|---|---|---|
| Зафиксировать результат пересчёта | Сборщик или пересчитывающий сотрудник | Руководитель принимает расхождение | Назначенная зона, товар, единица измерения |
| Применить поправку к остатку | Назначенный ответственный | Владелец учёта или другой уполномоченный | Конкретное расхождение, причина, исходное состояние |
| Списать брак или недостачу | Ответственный за учётное действие | Уполномоченный по основанию списания | Строка, количество, владелец товара, документ |
| Изменить начатый заказ | Руководитель процесса | Ответственный за заказ | Версия состава, стадия исполнения, последствия для резерва |
| Перепечатать этикетку | Упаковщик своего задания | По принятому правилу повторной печати | Тот же заказ и экземпляр; причина повторного оттиска |
| Выдать, изменить или отозвать права | Администратор доступа | Владелец соответствующей области | Именной пользователь, действия, данные и срок |
Принцип разделения обязанностей описан в NIST SP 800-53, AC-5; минимальных полномочий — в AC-6. Здесь они применены как организационная методика, а не обязательная для каждого склада нормативная схема. Источник: NIST SP 800-53 Rev. 5, проверено 31.10.2026.
Администратор доступа не становится автоматически владельцем товарного учёта. Он настраивает утверждённые права. Если этому же человеку требуется списывать товар, такое полномочие фиксируют отдельно. Сотрудник, который запрашивает расширение собственных прав, не должен единолично его согласовывать.
На небольшом складе один человек может совмещать несколько функций. Тогда запишите совмещение явно: какое действие он принимает сам, какие доказательства сохраняет и кто проверит результат. Обозначение двух ролей у одного человека не создаёт независимого согласования.
Пересчёт: отделите факт от поправки
При пересчёте сотрудник фиксирует место, владельца, товар, единицу измерения, фактическое количество и время. Пустое поле означает, что результат не записан; ноль — что пересчёт выполнен и единиц не найдено. Не подменяйте одно другим.
Дальше ответственный разбирает разницу: не было ли движения после исходного снимка, не учтён ли товар в другой зоне, нет ли активного резерва или ошибки идентификации. Если во время счёта движение продолжалось, сначала восстановите последовательность событий. Старый пересчёт нельзя без проверки применять поверх нового остатка.
Право «записать факт» и право «применить поправку» должны иметь отдельные строки в матрице. Программа может разделять их по-разному. Если оба действия технически объединены, не выдавайте широкое право всем пересчитывающим: выберите проверенный способ передачи факта тому, кто уполномочен менять учёт.
Учебный пример. У клиента A на складе W1 в учёте 10 единиц, резерв — 0. Сотрудник записал факт 9 и создал расхождение D-01. Руководитель подтвердил повторный счёт; владелец учёта согласовал поправку APR-01; назначенный исполнитель изменил остаток 10 → 9. В записи остались D-01, причина, согласующий, исполнитель и время. Попытка сборщика применить ту же поправку до согласования должна завершиться отказом без изменения остатка.
Списание: проверьте основание и последствия
Физически изолировать повреждённый товар, признать причину и провести учётное списание — отдельные этапы. Разрешение на один этап не должно молча давать право на остальные.
В запросе на списание укажите владельца, товар и вариант, количество, место, причину, основание и связь с заказом или актом, когда она нужна. До выполнения выясните, затрагиваются ли резерв и данные, отправляемые площадке. Если товар уже обещан заказу, сотрудник останавливает действие и передаёт конфликт ответственному: широкие права сами по себе не решают, что делать с заказом.
В протоколе сохраните количество до и после, идентификатор операции и итог. При потере ответа сначала выясняют, была ли операция выполнена; повторное нажатие не должно становиться способом «добиться зелёного сообщения». Подтверждённый факт исполнения и проверка безопасного повтора важнее самого сообщения на экране.
Для маркированного товара отдельно определяют допустимое действие с кодом и документом. Эта матрица не предоставляет полномочий подписанта и не устанавливает порядок вывода из оборота. Нужную развилку разбирают по товарной группе и схеме работы в справочнике по маркировке.
Изменение заказа: учитывайте стадию исполнения
У заказа в очереди и уже упакованного отправления разные последствия правки. В матрице полезно разделить изменение состава до начала работы, изменение после подбора, отмену после упаковки и действие после передачи перевозчику или площадке.
Для начатого задания проверьте, кто останавливает работу, кто утверждает новую версию и кто повторно сверяет товар. Нужно установить судьбу прежней этикетки, уже привязанного кода и резерва. Если одна роль может изменить состав, а другая продолжает работать со старой версией, отметка «сохранено» не подтверждает правильную упаковку.
После передачи используйте предусмотренную процедуру отмены, возврата или исправления внешних данных. Одного изменения локальной карточки недостаточно для решения о фактической судьбе товара. Не расширяйте полномочия сборщика только для того, чтобы он мог убрать заказ из неудобного статуса.
Как проверить роль на искусственных данных
Подготовьте два учебных клиента A и B, отдельные заказы и небольшой искусственный остаток. Сотрудник A должен иметь доступ только к согласованной области A. Это проверка настроек на заранее подготовленном стенде: реальные данные чужих клиентов не используются.
Выполняйте проверки под отдельной учётной записью сотрудника, без административных полномочий. Назначенный технический специалист проверяет альтернативные входы — прямую ссылку, экспорт, печать или API — в согласованных границах. Руководитель смены может провести обычный путь в интерфейсе и принять понятные ему доказательства.
| Проверка | Ожидаемый результат |
|---|---|
| 1. Прочитать разрешённый заказ A | Видны необходимые данные и правильный владелец |
| 2. Открыть подготовленный заказ B | Чужие данные, вложения и ссылки не выдаются |
| 3. Записать факт пересчёта | Факт сохранён; учёт не изменён до решения |
| 4. Применить поправку от имени сборщика | Отказ; остаток, резерв и внешние задачи не меняются |
| 5. Применить согласованную поправку ответственным | Одна операция с основанием и проверяемым результатом |
| 6. Списать без необходимого основания | Отказ без изменения учёта |
| 7. Изменить упакованный заказ без полномочия | Отказ; состав и связанные данные сохранены |
| 8. Напечатать или выгрузить данные B | Не создаются чужой файл и задание печати |
| 9. Повысить себе права | Отказ; прежние полномочия не меняются |
| 10. Продолжить работу после отзыва доступа | Запрещены чтение и запись из прежнего сеанса и при новом входе |
Для каждого теста запишите роль, объект, исходное состояние, действие, ожидание, фактический результат и ссылку на доказательство. Сообщение «доступ запрещён» проверяют вместе с состоянием данных после попытки. Если всё-таки изменился остаток или появился файл, тест не пройден.
В заполненном примере последняя проверка намеренно сначала не проходит: старая вкладка продолжает читать заказ. Допуск откладывают; после штатного исправления делают повторную проверку T10-R1. Так в журнале остаётся и проблема, и основание для нового решения. Все эти результаты учебные.
Что проверено в Skirbo, а что нужно подтвердить в вашем кабинете
Редакционная проверка кода Skirbo от 31 октября 2026 года показала отдельный механизм доступа сотрудников к разделам и ролевые проверки конкретных операций. В проверенных обработчиках немедленная запись результата инвентаризации в остаток, ручная отмена FBS и списание витринного остатка по документу требуют управленческого уровня.
Это описание проверенного кода. Оно не подтверждает, что любая произвольная матрица прав, согласование двумя людьми, ограничения по каждой ячейке или полный журнал всех действий уже доступны в вашей конфигурации. Названия должностей в шаблоне не следует искать в интерфейсе как обязательный список встроенных ролей.
Перед выдачей прав уточните и испытайте:
- какие действия ограничиваются отдельно, а какие объединены одним разрешением;
- как ограничиваются клиент, склад и состояние заказа;
- какие поля сохраняются в истории, кто может её читать и как долго она доступна;
- каким штатным способом прекращается доступ в уже открытой вкладке и на другом устройстве.
Не считайте снятие всех отметок в списке разделов подтверждённым отзывом доступа. Смысл пустого набора разрешений зависит от модели системы. Используйте согласованный способ ограничения или блокировки и проверьте результат под тестовым сотрудником.
Временные права и уход сотрудника
Временный доступ оформляют с действием, областью данных, основанием, согласующим и моментом окончания. «Помочь с инвентаризацией» слишком широко; «применить согласованную поправку D-01 клиента A на W1» позволяет проверить границу.
Если автоматическое окончание срока не подтверждено, назначьте человека и контрольный момент ручного отзыва. После отзыва повторите запрещённое действие в уже открытой вкладке, затем проверьте новый вход. OWASP отдельно рассматривает смену полномочий как событие, затрагивающее управление сеансами. Источник: OWASP Session Management, проверено 31.10.2026.
При уходе сотрудника проверьте связанные устройства, отдельные ключи, делегированные доступы и незавершённые задания. Отзыв одной учётной записи не следует считать доказательством прекращения каждого другого способа доступа. Передайте незавершённую работу новому ответственному с её текущим состоянием.
Когда матрица готова к работе
Владелец области принимает матрицу, когда нужные действия выполняются, запрещённые отклоняются, область данных соблюдается, результат можно восстановить по записи и отзыв проверен. Пункт «не проверено» остаётся ограничением допуска.
Если система пока не разделяет опасное действие так, как требует процесс, зафиксируйте этот разрыв. Рабочий временный вариант — поручить действие конкретному ответственному под его собственным именем, с основанием и проверкой результата. Ручной журнал помогает организовать работу, но не создаёт технического запрета для остальных: если запрет необходим, этот участок ждёт настройки или доработки.
Проверку повторяют после изменения роли, перечня клиентов, маршрута операции, способа входа или значимого обновления системы. Период планового пересмотра назначает владелец процесса; универсального срока для всех складов здесь нет.
Следующий шаг
Заполните матрицу для одной группы сотрудников и пройдите её на учебных данных. Для проверки в Skirbo подготовьте обезличенные строки: нужное действие, роль, клиент/склад, условие и ожидаемый отказ. Обсудить конфигурацию с поддержкой. Сообщение в поддержку начинает разбор; готовность ограничений подтверждает результат испытаний.
Дополнительно: обучение сборщика и лист допуска, проверка рабочего места упаковщика, план автоматизации фулфилмента.
Частые вопросы
Можно ли дать начальнику смены доступ администратора?
Сначала перечислите действия, которые ему действительно нужны. Если для рабочей операции достаточно ограниченного права, используйте его. Административный доступ оформляйте как отдельное полномочие, а не способ устранить любую ошибку доступа.
Достаточно ли скрыть кнопку списания?
Нет. Проверка должна подтвердить отказ в самом действии, включая альтернативный допустимый для теста вход, и отсутствие изменений учёта. Скрытая кнопка сама по себе этого не доказывает.
Что делать, если некому независимо подтвердить операцию?
Зафиксировать совмещение ролей, основания и последующую проверку владельцем. Это управленческое решение с ограничениями; две записи роли у одного человека не заменяют второго участника.
Источники и границы
Первичные источники проверены 31.10.2026: OWASP Authorization, OWASP Session Management, NIST SP 800-53 Rev. 5, AC-5 и AC-6. Матрица, последовательность испытаний и учебные ситуации — авторская методика. Проверка кода не является испытанием рабочего кабинета, проверкой безопасности всей системы или подтверждением наличия каждой функции шаблона.