OLA для выполнения инфраструктурных работ по ЗнИ
0
541
24.07.2026
Что это за процесс
Процесс описывает логику расчета сроков (OLA) для инфраструктурных работ в рамках Запросов на изменение (ЗнИ). Он начинается с момента создания ЗнИ в системе ITSM и завершается назначением наряда на группу ответственных с фиксированным сроком выполнения. Основная цель — стабилизировать сроки работ со стороны инфраструктуры за счет автоматизированного назначения сложности и блокировки некорректных изменений.
Как читать эту схему
Схема построена на эксклюзивных шлюзах, которые направляют поток в зависимости от параметров наряда. Ключевая развилка происходит при проверке сложности ЗнИ: если сложность «Легкая», система блокирует изменения наряда; если «Средняя» или «Сложная», поле «Тип наряда» становится неактивным, а для средней сложности запускается расчет срока по метрике 16 часов. Отдельная ветка предусмотрена для «Нетиповых» задач, где требуется ручное вмешательство. Также есть проверка на наличие группы ответственных в справочнике: если группа не найдена, процесс прерывается до новых изменений. Ошибки, такие как незаполненный тип наряда или невозможность создания, обрабатываются как исключения.
Кому подойдёт
Эта схема полезна для IT-отделов и служб поддержки, работающих с системами ITSM. Она актуальна для менеджеров изменений, которые формируют наряды, и для разработчиков систем, настраивающих бизнес-логику на стороне сервера и интерфейса. Подойдет компаниям, где важно строго регламентировать сроки выполнения инфраструктурных задач и минимизировать ручные ошибки при их создании.
Как адаптировать под свою компанию
- Замените метрику расчета срока (16 часов) на актуальные значения для вашей инфраструктуры.
- Настройте справочник групп ответственных под реальную структуру ваших команд.
- Измените логику блокировки полей в зависимости от требований вашей системы ITSM.
- Добавьте уведомления в корпоративный мессенджер или почту, если Exchange не используется.
- Пересмотрите критерии «Легкой», «Средней» и «Сложной» сложности под ваши бизнес-процессы.
Типичные ошибки
Частая ошибка — игнорирование ветки «Нетиповой», что приводит к зависанию задач, не входящих в стандартные шаблоны. Другая проблема — отсутствие проверки наличия группы ответственных в справочнике до назначения, из-за чего наряды уходят в «никуда». Также часто забывают блокировать изменения наряда для легких задач, что позволяет пользователям менять сроки вручную, сводя на нет расчет OLA.
Опубликуйте свой шаблон
У вас есть отличная схема, которой стоит поделиться? Мы поможем превратить её в шаблон и показать всему сообществу.
Какие элементы BPMN здесь использованы
Нажмите на элемент, чтобы разобраться, что он означает и когда его применяют.
Частые вопросы
Что происходит, если группа ответственных не найдена в справочнике?
Проверка запускается автоматически при создании наряда. Если группа отсутствует, процесс прерывается, и создание наряда останавливается до тех пор, пока не будут внесены корректные изменения.
Как рассчитывается срок для нарядов средней сложности?
Для нарядов со сложностью «Средний» система автоматически применяет расчет по метрике 16 часов. Это значение зашито в логику эксклюзивного шлюза при проверке сложности.
Можно ли изменить тип наряда после его создания?
Нет, для нарядов средней и сложной сложности поле «Тип наряда» становится неактивным. Для легких задач изменения наряда блокируются полностью.
Кто принимает решение о том, что менять в процессе?
Решение принимает Менеджер изменения (МИ). Его действия влияют на то, будет ли процесс продолжен или прерван в случае нетиповых ситуаций.
Что такое OLA в контексте этой схемы?
OLA (Operational Level Agreement) — это соглашение об уровне сервиса, определяющее сроки выполнения работ со стороны инфраструктуры. Схема автоматизирует расчет и контроль этих сроков.
Как система реагирует на незаполненный тип наряда?
Система генерирует ошибку «Не заполнен тип наряда». Это исключение останавливает процесс создания наряда, требуя обязательного заполнения поля.
Похожие процессы
