Введение
Под адаптивной маршрутизацией понимается динамическое назначение исполнителя с учетом загрузки и ретроспективы; неоптимальное назначение – передача заявки менее релевантному специалисту; текущее состояние исполнителя – загрузка и доступность; замкнутый контур – наличие обратной связи; MAPE – средняя ошибка прогноза.
Применяемые в службе технической поддержки алгоритмы маршрутизации и приоритизации реализуют статическое управление без учета состояния исполнителей [1; 2]. Это приводит к высокой доле ручного труда, нарушениям SLA и нерациональному распределению ресурсов [3–5]. Для преодоления этих ограничений требуется адаптивная система поддержки решений на основе формализованных бизнес-правил, учитывающих динамику организационной системы [6; 7].
Цель исследования – разработка моделей и методов управления в организационных системах применительно к процессам технической поддержки ИТ-инфраструктуры холдинга, обеспечивающих формирование адаптивных управляющих воздействий на основе формализованных бизнес-правил.
Задачи:
1. Выполнен системный анализ и моделирование существующих процессов технической поддержки как элемента организационной системы холдинга.
2. Выявлены ограничения действующих алгоритмов маршрутизации и приоритизации заявок и обоснована необходимость их совершенствования в рамках управления организационными системами.
3. Разработана целевая функциональная модель системы поддержки принятия управленческих решений с использованием современных методов моделирования организационных процессов.
4. Формализована система продукционных бизнес-правил, направленная на автоматизацию процессов управления в организационной системе технической поддержки.
Материалы и методы исследования
Исследование выполнено на данных трех холдинговых компаний (ИТ-услуги, финансы, промышленность) за 2024–2025 гг. с использованием методов системного анализа [8], функционального моделирования бизнес-процессов [9] и экспертных оценок [10].
Для ретроспективного анализа отобраны 15 000 завершенных заявок после очистки (удалены дубликаты и некорректные записи). Распределение: ИТ-услуги – 40 %, финансы – 35 %, промышленность – 25 %. Категории: инциденты (62 %), запросы (28 %), консультации (10 %). Приоритеты: критические (8 %), высокие (22 %), средние (45 %), низкие (25 %). Включены заявки с полными атрибутами, исключены без исполнителя или с нулевым временем решения. Экспертная оценка (7 экспертов, стаж ≥ 5 лет) проведена методом Дельфи (два тура), коэффициент конкордации – 0,82.
Анализ текущего процесса (AS-IS) выявил ручную маршрутизацию, статическую приоритизацию и отсутствие прогнозной аналитики. Сравнительный анализ типовых ITSM-систем (ServiceNow, Jira Service Management, 1С:УСЦ) выполнен на основе тех же 15 000 заявок [11, с. 120]. Выявлены узкие места: высокая доля ручной маршрутизации, значительное время реакции, частые нарушения SLA. С использованием IDEF0/IDEF3 построены контекстная диаграмма и декомпозиции [12]. Разработана функциональная модель СППУР (UML, BPMN 2.0) [13] и формализованы продукционные правила «ЕСЛИ – ТО».
Результаты исследования и их обсуждение
Сравнение полученных результатов с целевыми показателями SLA позволило выявить следующие системные ограничения существующих алгоритмов управления, реализованных в типовых ITSM-системах [14]:
1. Статическая приоритизация. Приоритет назначается по шаблону (тип инцидента, время простоя) без учета загрузки исполнителей и срочности бизнес-процессов. Следствие: 12 % высокоприоритетных заявок ожидают из-за перегруженности назначенной группы.
2. Отсутствие адаптивной маршрутизации. Назначение исполнителей жестко привязано к категориям заявок, что не позволяет перераспределять нагрузку между группами. В 25 % рабочих дней одна группа перегружена при простое другой.
3. Неспособность к обучению на ретроспективных данных. Алгоритмы не анализируют историю решений, успешность назначений и обратную связь, поэтому не могут адаптироваться к изменяющимся условиям.
4. Слабая интеграция с системами мониторинга. Приоритет назначается по пользовательскому вводу, а не по реальным данным о загрузке или предвестникам отказов, что лишает систему проактивности.
5. Неформализованная эскалация. Эскалация запускается по таймеру (например, через 4 ч) без учета сложности инцидента, доступности специалистов третьей линии и срочности.
Показатели эффективности существующих алгоритмов маршрутизации и приоритизации
|
Показатель |
Фактическое значение |
Целевое значение (SLA) |
|
Доля автоматически назначенных заявок |
45 % |
> 80 % |
|
Среднее время реакции на критические инциденты, с |
180 |
120 |
|
Доля нарушений SLA по времени отклика |
12 % |
< 5 % |
|
Точность прогноза пиковых нагрузок (MAPE) |
9,1 % |
< 5 % |
|
Доля заявок с неоптимальным назначением |
18 % |
< 5 % |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Рис. 1. Диаграмма вариантов использования СППУР Примечание: составлен авторами по результатам данного исследования
Выявленные ограничения системны и взаимосвязаны: статическая приоритизация и жесткая маршрутизация не позволяют гибко реагировать на нагрузку (простой одних групп при перегрузке других), отсутствие обучения консервирует неэффективные назначения, а слабая интеграция с мониторингом лишает информации о состоянии инфраструктуры. В итоге – неоптимальное распределение ресурсов и систематические нарушения SLA. Количественные показатели, подтверждающие эти ограничения, которые были получены в ходе анализа, сведены в таблицу.
Сравнение фактических показателей с целевыми значениями SLA показывает существенное отставание по всем ключевым критериям. Особенно критичной является низкая доля автоматических назначений, что свидетельствует о высокой доле ручного труда. Среднее время реакции на критические инциденты превышает целевое на 50 %, а доля нарушений SLA в 2,4 раза выше допустимого уровня. Предлагаемая продукционная система правил позволяет формализовать экспертные знания и реализовать адаптивную маршрутизацию и приоритизацию, что обеспечивает повышение эффективности управления.
Для устранения выявленных ограничений разработана функциональная модель СППУР.
На рис. 1 представлена диаграмма вариантов использования. Варианты использования: администрирование, ведение БД, учет заявок, выполнение заявок, подготовка отчетов. Акторы: администратор, диспетчер, инженер, начальник ТП.
Для варианта использования «Выполнять заявки» разработан детализированный сценарий в нотации BPMN 2.0, представленный на рис. 2.
Рис. 2. Сценарий процесса «Выполнение заявок на СППУР» Примечание: составлен авторами по результатам данного исследования
Сценарий описывает действия от входа до закрытия заявки. Ключевые элементы: открытие пула, выбор и анализ заявки, определение алгоритма, назначение исполнителя, изменение статуса, уведомление диспетчера. Для ветвления по статусу и приоритету использованы шлюзы XOR.
Аналогично разработаны сценарии для процессов «Администрирование СППУР», «Ведение базы данных СППУР», «Подготовка отчетов» и «Учет заявок».
Все диаграммы построены в среде Bizagi Modeler и верифицированы с участием экспертов отдела технической поддержки.
На основе анализа ограничений и разработанной функциональной модели сформирована система продукционных бизнес-правил для автоматической приоритизации, маршрутизации и эскалации заявок. Правила записаны в стандартном формате «ЕСЛИ – ТО» с использованием атрибутов заявки.
Группа 1. Правила приоритизации:
1. R1.1 (критический инцидент): ЕСЛИ (заявка.тип=’Критическая’ И заявка.время_простоя > 15 минут) ТО заявка.приоритет=’Высокий’; заявка.назначить_группу (‘Специалисты 3 линии’); заявка.уведомить (‘Начальник ТП’).
2. R1.2 (массовый сбой): ЕСЛИ (количество_аналогичных_заявок_за_час > 10) ТО заявка.приоритет = ‘Высокий’; создать_инцидент_проблемы (‘Массовый сбой’).
Группа 2. Правила маршрутизации (автоназначения):
1. R2.1 (ошибка 1С): ЕСЛИ (заявка.категория = ‘ПО’ И заявка.ключевые_слова СОДЕРЖИТ (‘1С’, ‘ошибка’, ‘документ не проводится’)) ТО заявка.назначить_исполнителю(Смирнов А. И.).
2. R2.2 (проблема с сетью): ЕСЛИ (заявка.категория = ‘Сеть’ И заявка.ключевые_слова СОДЕРЖИТ (‘VPN’, ‘доступность’, ‘таймаут’)) ТО заявка.назначить_группу(‘Сетевые инженеры’).
Группа 3. Правила эскалации:
1. R3.1 (эскалация по времени): ЕСЛИ (заявка.статус = ‘В работе’ И заявка.время_в_статусе > 4 часа) ТО заявка.статус = ‘Требует эскалации’; заявка.уведомить(‘Начальник ТП’).
2. R3.2 (эскалация по сложности): ЕСЛИ (заявка.количество_переоткрытий > 2) ТО заявка.статус = ‘Требует эскалации’; заявка.назначить_группу (‘Специалисты 3 линии’).
Группа 4. Правила интеграции с мониторингом:
R4.1 (прогнозирование нагрузки): ЕСЛИ (прогноз_нагрузки_сервера(отдел) > 85 % И текущее_время ∈ [9:00, 11:00]) ТО создать_уведомление(‘Вероятна пиковая нагрузка на сервера отдела продаж’); автоматически увеличить_вычислительные_мощности (отдел, +10 %).
Обучение реализовано через ежемесячный пересчет успешности правил: при успешности < 70 % приоритет понижается или предлагается корректировка; неиспользуемые > 90 дней правила помечаются для пересмотра. Для прогнозирования (R4.1) используется модель Хольта – Винтерса (пересчет ежедневно; MAPE = 9,1 %). Правила интегрируются в ядро СППУР через механизм бизнес-правил из БД; приоритет выше у более специфичного правила.
Дизайн апробации: для проверки эффективности проведен пилотный проект в з компаний в течение 3 месяцев. Использовался прототип на базе Jira Service Desk. В пилоте обработано 1200 заявок. Сравнение выполнялось с аналогичным периодом предыдущего года для контроля сезонности. До пилота показатели: доля автоматических назначений – 45 %, время реакции – 180 с, доля нарушений SLA – 12 %. После пилота: 68 %, 145 с и 7 % соответственно. Статистическая значимость различий проверена с помощью двухвыборочного t-теста. Доверительные интервалы (95 %): для времени реакции (140–150 с), для доли назначений (65–71 %), для нарушений SLA (6–8 %). Это подтверждает устойчивость улучшений.
После внедрения прототипа наблюдалось повышение доли автоматически назначенных заявок с 45 до 68 %, сокращение времени реакции с 180 до 145 с и снижение доли нарушений SLA с 12 до 7 %. Причинная интерпретация этих изменений требует дополнительной проверки, так как на результаты могли повлиять сезонные факторы и параллельные изменения в процессах. Тем не менее полученные данные свидетельствуют о потенциальной эффективности предложенного подхода [15].
Заключение
В результате исследования разработана модель адаптивного управления организационной системой технической поддержки, где СППУР выступает как замкнутый контур управления с обратной связью. Формализована продукционная система правил для генерации управляющих воздействий, предложена функциональная модель (UML, BPMN 2.0). Апробация прототипа подтвердила повышение эффективности управления за счет снижения ручного труда, минимизации нарушений SLA и оптимизации распределения ресурсов.
Ограничения исследования. Анализ выполнен на данных трех компаний, пилот на Jira Service Management, структура заявок может отличаться в других отраслях, отсутствие контрольной группы, настройка правил зависит от экспертов и требует калибровки. Дальнейшие исследования будут направлены на адаптивную настройку весов правил и прогнозирование инцидентов на основе статистического анализа ретроспективных данных, а также на механизмы самоадаптации системы.
Конфликт интересов
Финансирование
Библиографическая ссылка
Неволин Ф.Д., Ромашкова О.Н. МОДЕЛИРОВАНИЕ ПРОЦЕССОВ И ФОРМАЛИЗАЦИЯ БИЗНЕС- ПРАВИЛ ДЛЯ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ В ИТ-ИНФРАСТРУКТУРЕ ХОЛДИНГА // Современные наукоемкие технологии. 2026. № 7. С. 117-122;URL: https://top-technologies.ru/ru/article/view?id=40866 (дата обращения: 12.08.2026).