Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Сотрудник запрашивает доступ к финансовой системе. Руководитель должен подтвердить потребность, а служба эксплуатации — выдать ограниченную роль. Сейчас письмо «согласовано» сразу закрывает заявку, хотя техническое действие иногда не выполнено или выдана другая роль. Нужна проверяемая цепочка от запроса до подтверждения результата.
Разберите одну реальную заявку от начала до конца и найдите подтверждение того, что было выдано. Если такое подтверждение отсутствует, основная проблема находится после согласования. Процесс должен сохранять связь между одобренным запросом и фактической ролью в системе, а не только время нажатия кнопки.
Модель и договорённости
Опишите четыре разные сущности: кто просит, кто согласует, что именно разрешено и кто исполняет. Укажите срок действия доступа и условия отказа. Согласующий не должен получать абстрактную кнопку без контекста: в заявке необходимы система, роль и обоснование. Изменение существенных параметров после решения требует заранее определённой повторной проверки.
Определите поведение при увольнении руководителя и отсутствии данных об организационной структуре. Нельзя молча выбирать случайного доступного согласующего. Для ручного назначения задайте круг уполномоченных сотрудников и требование указать причину, чтобы исключительный маршрут не стал обычным способом обхода контроля.
Порядок внедрения
Подготовьте статус ожидания согласования и отдельный этап выполнения. Настройте источник согласующего и маршрут отказа. Исполнителю передавайте конкретное одобренное действие, а не произвольный текст текущего описания. Завершайте обращение после подтверждения выдачи и уведомления заявителя. Для временного доступа заведите отдельный контроль срока отзыва.
Для пилота возьмите один тип доступа с понятным владельцем системы и небольшой группой заявителей. Сначала проверьте путь отказа, затем согласование и техническую выдачу. Сохраните одобренные параметры в момент решения. Перед автоматизацией исполнения вручную подтвердите, что эти данные позволяют однозначно выбрать нужную роль в целевой системе.
Проверки на реальных сценариях
Проведите положительное решение, отказ, отсутствие согласующего и замену руководителя. Измените запрошенную роль после согласования и проверьте предусмотренное поведение. Убедитесь, что заявитель видит понятный статус, а исполнитель получает только действительно одобренную заявку. Повторное уведомление не должно создавать вторую техническую операцию выдачи.
В тестах измените систему назначения, роль и срок доступа отдельно. Для каждого изменения заранее согласуйте, сохраняется ли прежнее решение или требуется повторное. После технической выдачи проверьте доступ со стороны целевой системы, а не только успешный статус интеграции в заявке.
Ошибки и диагностика
Типичный сбой — согласование записано, но интеграция не выполнила действие. Заявка должна оставаться в состоянии, которое отражает незавершённое исполнение. Не подменяйте технический результат решением руководителя. Отдельно обработайте случай ошибочного согласующего: автоматический выбор по неполному справочнику может направить чувствительные данные постороннему человеку.
Если выдана неверная роль, сверяйте исходное решение и фактическое действие. Исправление текста заявки задним числом не устраняет доступ и затрудняет понимание первоначально согласованного объёма полномочий.
Возврат и восстановление
При ошибочной выдаче сначала отзовите фактический доступ в целевой системе и подтвердите результат. Затем исправляйте статус и журнал заявки с объяснением причины. Возврат workflow назад сам по себе доступ не отзывает. Отключение автоматического маршрута должно сохранять возможность ручной обработки уже согласованных запросов без повторной выдачи.
При ошибке разделите три действия: остановка новых выдач, отзыв уже назначенных прав и исправление записи процесса. После отзыва проверьте фактическую роль пользователя в системе назначения. Заявку оставьте с доказательством исправления, чтобы последующий аудит мог понять исходное решение и последствия ошибки, а не увидел только аккуратный окончательный статус.
Приёмка и дальнейший контроль
Отслеживайте время ожидания решения отдельно от времени исполнения, число согласований без выполненной выдачи и просроченных отзывов. На выборке заявок проверяйте соответствие одобренной и реально назначенной роли. Процесс считается устойчивым, когда решение, действие и доказательство результата связаны, но не подменяют друг друга.
Для временных прав добавьте проверяемую дату отзыва и владельца действия. Закрытая заявка на выдачу не означает завершения всего жизненного цикла доступа. На регулярном обзоре сопоставляйте действующие права с первоначальным запросом и отдельно разбирайте случаи, где срок действия уже закончился.
Механизм продукта и применимость
В JSM шаг согласования можно связать со статусом рабочего процесса обращения. Само решение согласующего следует отличать от фактического выполнения запроса и технической выдачи доступа.
Механизм согласований JSM следует проверять для выбранного типа проекта. Company-managed и team-managed процессы настраиваются по-разному: в team-managed каждый request type имеет собственный workflow. Описанная последовательность решения и исполнения — проектный подход; конкретный редактор согласования выбирают по текущей конфигурации обращения.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу