Введение

Под адаптивной маршрутизацией понимается динамическое назначение исполнителя с учетом загрузки и ретроспективы; неоптимальное назначение – передача заявки менее релевантному специалисту; текущее состояние исполнителя – загрузка и доступность; замкнутый контур – наличие обратной связи; 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 ч) без учета сложности инцидента, доступности специалистов третьей линии и срочности.

Показатели эффективности существующих алгоритмов маршрутизации и приоритизации

Примечание: составлена авторами на основе полученных данных в ходе исследования.

Рис. 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, структура заявок может отличаться в других отраслях, отсутствие контрольной группы, настройка правил зависит от экспертов и требует калибровки. Дальнейшие исследования будут направлены на адаптивную настройку весов правил и прогнозирование инцидентов на основе статистического анализа ретроспективных данных, а также на механизмы самоадаптации системы.