Roles, actions and evidenceРоль, действие и подтверждение

Start with actions rather than job titlesНачните с действий, а не должностей

Take a workflow from request to completion and list its decisions: create an order, approve a substitution, revise an amount and confirm handover. Name the operator and expected outcome for each. One job may participate in several workflows with different boundaries; matching titles across locations do not establish matching responsibility.Возьмите процесс от запроса до завершения и выпишите решения: создать заказ, согласовать замену, изменить сумму, подтвердить выдачу. Для каждого назовите исполнителя и ожидаемый результат. Одна должность может участвовать в разных процессах с разными границами; одинаковые названия в разных точках не доказывают одинаковую ответственность.

Check authority using the actual employee role: can the person see the required object and perform the step? If a task is assigned without access, the approval route must remain visible. Do not fix every gap by granting full access; first identify the missing action and data scope.Проверьте полномочия у реального сотрудника: видит ли он нужный объект и может ли сделать требуемый шаг. Если задача назначена без доступа, маршрут согласования должен оставаться видимым. Не исправляйте любой такой пробел выдачей всех прав: сначала определите недостающее действие и область данных.

Separate viewing from changingРазделите просмотр и изменение

For a business object, distinguish viewing, creation, editing, cancellation, approval and export to the extent the system supports separate controls. An employee may need the current status without being able to revise a price. Permission to correct an order should not automatically require authority to change rules for every order.Для рабочего объекта различайте просмотр, создание, изменение, отмену, подтверждение и выгрузку, насколько система позволяет задавать их отдельно. Сотруднику может быть нужен текущий статус без возможности изменить цену. Право корректировать заказ не обязательно должно давать право изменять правила для всех заказов.

Add scope to each action: assigned records, one location or several branches. Test direct access to an out-of-scope object and routes through related screens. A hidden button alone does not establish that an action is restricted. If the required boundary cannot be expressed in configuration, record it as a separate workflow decision.Дополните действие областью: назначенные записи, своя точка или несколько подразделений. Проверяйте прямое открытие чужого объекта и доступные переходы из связанных экранов. Скрытая кнопка сама по себе не доказывает ограничения действия. Если требуемую границу нельзя выразить в конфигурации, зафиксируйте это как отдельное решение по процессу.

The access lifecycleЖизненный цикл доступа

Define approval and coverОпределите согласование и замещение

In the map, identify who requests an exception, who decides and who executes the approved action. These roles should overlap only where the process owner has deliberately accepted that arrangement. A disputed return or unusual adjustment needs a clear decision owner rather than unrestricted permission for every participant.В матрице укажите, кто запрашивает исключение, кто принимает решение и кто выполняет согласованное действие. Эти роли могут совпадать только там, где это сознательно принято владельцем процесса. Для спорного возврата или нестандартной корректировки нужен понятный решающий, а не неограниченное разрешение всем участникам.

A manager’s absence should not lead to sharing their account. Define a covering role, decision boundaries and a process for ending temporary access. If automatic expiry is unavailable, assign manual removal and verification. This is a testable operating condition rather than an assumed feature.Отсутствие руководителя не должно превращаться в передачу его учётной записи. Назначьте заменяющую роль, границы решения и порядок завершения временного доступа. Если система не поддерживает автоматическое окончание, нужен ответственный за ручной отзыв и проверку. Это проверяемое условие работы, а не предполагаемая функция.

• Cover check: the team knows where to send an exception when the usual approver is unavailable.Проверка замещения: команда знает, куда направить исключение, когда основной согласующий недоступен.

Link decisions to their historyСвяжите решение с его историей

For each significant action, define the evidence needed: object, operation, actor or process, time and basis. Approval and execution may produce different entries. Check whether they can be connected without assuming that the operator’s name also identifies the decision-maker.Для каждого значимого действия запишите, какое подтверждение должно остаться: объект, выполненная операция, исполнитель или процесс, время и основание. Согласование и выполнение могут давать разные записи. Проверьте, можно ли связать их, не предполагая, что имя исполнителя одновременно означает автора решения.

Permissions describe possible actions; history describes recorded ones. When reviewing an error, compare authority at the time, the task and available records. The current role may have changed after the event. If historical permission state is unavailable, state that limitation instead of confidently concluding whether the earlier action was allowed.Права показывают возможное действие, история — зарегистрированное. При разборе ошибки сопоставьте фактические полномочия на тот момент, задачу и доступные записи. Текущая роль могла измениться после события. Если прошлое состояние прав недоступно, обозначьте ограничение вместо уверенного вывода о разрешённости прежнего действия.

Accept the map through scenariosПримите матрицу на сценариях

Run a normal completion, an out-of-role action, an approved exception and a shift handoff. Use accounts with the relevant roles in an authorized environment. For each case, inspect available context, outcome, refusal or approval route and the evidence left afterward.Проведите обычное завершение, действие за пределами роли, согласованное исключение и передачу между сменами. Используйте учётные записи с нужными ролями в разрешённой среде. Для каждого случая проверьте доступный контекст, результат, отказ или маршрут согласования и сведения, остающиеся после действия.

Resolve gaps with the process owner and administrator separately: one owns the rule, the other the available configuration. Verify supported action and scope boundaries in SABSUS before accepting the map. After a change of job, location or workflow, repeat affected scenarios so the role description remains operationally useful.Согласуйте найденные пробелы с владельцем процесса и администратором отдельно: один отвечает за правило, другой — за доступную настройку. В SABSUS подтвердите поддерживаемые границы действий и областей до принятия матрицы. После смены должности, точки или процесса повторяйте затронутые сценарии, чтобы описание роли оставалось рабочим.

Action-history acceptanceПриёмка истории действий

Quick answersКороткие ответы