CC BY
17DOI: 10.12731/2070-7568-2023-12-1-172-198 УДК 004
МЕТОДИКА УПРАВЛЕНИЯ РЕСУРСАМИ ДЛЯ IT-КОМПАНИИ, ЗАНИМАЮЩЕЙСЯ СЕРВИСНЫМ ОБСЛУЖИВАНИЕМ
Т.В. Аветисян, Я.Е. Львович, А.П. Преображенский, Ю.П. Преображенский
В данной статье рассматриваются особенности управления компанией, связанной с сервисным обслуживанием. Показано, каким образом происходит подготовка входных данных и их преобразование. Продемонстрированы особенности подготовки модели для обучения и тестирования. Приведена общая схема взаимодействия конечных пользователей заказчика с проектной и сторонними техническими поддержками учетом условий сервисного обслуживания. Показана схема логики обработки входящих инцидентов между линиями поддержки. Дана логическая схема модуля предсказания для определения команды поддержки. После того, как в работе получили обученную модель, которая позволяет осуществлять предсказывание команды поддержки на основе методов логистической регрессии, средствами языка Python ее можно сохранить в виде специального файла, его можно затем подключать как самостоятельный модуль.
Цель - определение способов и приемов анализа, применяющих при проведении анализа экспортных операций.
Метод или методология проведения работы: в статье использовались методы системного анализа и управления предприятием.
Результаты: рассмотрен пример данных по решенным инцидентам для конкретной команды поддержки с инженерами, а также пример расчетов числовых характеристик для корректировки базового предсказания инженера команды поддержки. Показана логическая схема улучшенной модели программного решения.
Область применения результатов: могут использоваться с совершенствованием управления IT-обслуживанием с точки зрения деятельности инцидент-координатора.
Ключевые слова: компания; управление ресурсами; сервисное обслуживание
Для цитирования. Аветисян Т.В., Львович Я.Е., Преображенский А.П., Преображенский Ю.П. Методика управления ресурсами для IT-компании, занимающейся сервисным обслуживанием //Наука Красноярья. 2023. Т. 12, №°1. С. 172-198. DOI: 10.12731/2070-7568-2023-12-1-172-198
DEVELOPMENT OF A RESOURCE MANAGEMENT METHODOLOGY FOR A SERVICE COMPANY
T.V. Avetisyan, Ya.E. Lvovich, A.P. Preobrazhensky, Yu.P. Preobrazhensky
This article discusses the specifics of managing a service-related company. It shows how the preparation of input data and their transformation takes place. Peculiarities of model preparation for training and testing are demonstrated. The general scheme of interaction between customer end-users and project and third-party technical support taking into account the conditions of service maintenance is given. The scheme of logic of processing incoming incidents between support lines is shown. The logic diagram of the prediction module for determining the support team is given. After the work has received the trained model that allows to carry out prediction of a support team on the basis of methods of logistic regression, by means of language Python it can be saved as a specialfile, it can then be connected as an independent module.
Purpose. Determination of methods and techniques of analysis used in the analysis of export operations.
Methodology the article used systems analysis and enterprise management methods.
Results: an example of resolved incident data for a specific support team with engineers is considered, as well as an example of numerical feature calculations to adjust the support team engineer's baseline prediction. A logic diagram of the improved software solution model is shown.
Practical implications can be used with the improvement of IT service management in terms of incident coordinator activities.
Keywords: company; resource management; customer service
For citation. Avetisyan T. V., Lvovich Ya.E., Preobrazhensky A.P., Preobrazhensky Yu.P. Development of a Resource Management Methodologyfor a Service Company. Krasnoyarsk Science, 2023, vol. 12, no. 1, pp. 172-198. DOI: 10.12731/20707568-2023-12-1-172-198
Сервис-менеджмент является достаточно распространенным в крупных компаниях [19, 22]. Многие предприятия не стремятся открывать у себя IT-отделы в силу ряда причин и передают соответствующие функции на аутсорсинг [20, 26].
Для этого предприятия заключают договор с обслуживающей компанией, которая предоставляет для заказчика оборудование в аренду, инфраструктуру и кадры, которые должны обеспечивать обслуживание предоставленных ресурсов, а также конечных пользователей заказчика [25]. Способность сервисной компании эффективно выполнять заявки заказчика во многом зависит от ее качества организации бизнес-процессов обработки этих заявок [23, 24].
В данной работе мы рассмотрим организацию работы компании, которая занимается поддержкой бизнес-пользователей сторонних фирм. Несмотря на то, что договоренности по организации обслуживания для разных проектов будут значительно отличаться [1, 2], принципиальное построение IT-поддержки осуществляется согласно процессам сервис-менеджмента в рамках методологии Information Technology Infrastructure Library (ITIL). Затем мы рассмотрим устройство и взаимодействие обслуживающего IT департамента для примера некоторого проекта.
Теоретические основы исследования
Согласно процессам сервис-менеджмента, в проекте можно выделить следующих участников (рис. 1):
• Конечные пользователи со стороны заказчика.
• Первая линии поддержки, предоставленная третьей стороной.
• Вторая и третья линии поддержки со стороны обслуживающего IT-департамента.
• Команды поддержки третей стороны и вендоров
Конечные пользователи работают в штате Заказчика и выполняют
ежедневные задачи бизнеса согласно своей роли. Чтобы была обеспечена непрерывность работы, необходим механизм решения возникающих проблем, которые описываются как «Инцидент» согласно терминам ITIL (это событие, при котором происходит внеплановое
прекращение предоставления сервиса или снижение его качества) [**]. Эти задачи покрывает процесс Инцидент менеджмента. Когда у пользователя возникает проблема, он должен быть уверен, что при оформлении запроса он в кратчайшие сроки, или временные рамки, установленные в договоре по сервисному обслуживанию, получит необходимое решение [21, 27].
Пользователь
Пользователь
Пользователь
Агент первой линии поддержки
Агент первой линии сторонней поддержки
Команда 2-ой линии поддержки
Команда 3-ой линии поддержки
Команда сторонней поддержки приложения
Рис. 1. Общая схема взаимодействия конечных пользователей заказчика с проектной и сторонними техническими поддержками
Для осуществления правильного и быстрого реагирования на возникающую проблему должны выполняться следующие условия:
• Пользователь должен иметь несколько видов связи с точкой контакта технической поддержки
• Необходимо высокофункциональное программное обеспечение, которое позволяет вести учет входящих инцидентов в системе, для качественной поддержки и решения возникающих проблем на стороне заказчика
• Дополнительные роли, отвечающие за координацию инцидентов с целью уменьшения времени выполнения, изучения и решения инцидентов. Ниже представлена схема с учетом вышеперечисленных условий [7].
• В компании соблюдаются минимальные требования по поддержке конечных пользователей. Компания, которая предо-
ставляет сервисное обслуживание конечным пользователям заказчика, отвечает за вторую и третью линии поддержки.
Основные различия такого разделения заключается в том, что инцидент, который не был решен на первой линии поддержки, должен быть отправлен на вторую линию для изучения проблемы. Если же инцидент не может быть решен силами второй линии технической поддержки, то инцидент должен быть переправлен на третью линию поддержки для дальнейшего поиска решения [3, 4]. Такой подход позволяет отсеивать инциденты на соответствующих линиях поддержки, тем самым обеспечивая возможность изучения проблемы по соответствующим уровням компетенций инженеров на линиях поддержки.
Стоит отметить, что количество линий поддержки может быть сколь угодно много, но обычно используется всего три линии поддержки, и если третья линия не может справиться с инцидентом, то могут быть инициализированы другие процессы, например, процесс Управления Проблемами, или инцидент может быть передан в техническую поддержку приложения или вендора (рис. 2).
1Т-инженеры сторонней поддержки
Рис. 2. Общая схема взаимодействия конечных пользователей заказчика с проектной и сторонними техническими поддержками учетом условий сервисного обслуживания
Для обработки и содержания серверов используются дата-центры с большим количеством физических серверных стоек.
Одним из видов деятельности Координатора инцидентов являются задачи распределения инцидентов между соответствующими командами поддержки.
Рис. 3. Схема логики обработки входящих инцидентов между линиями поддержки
Инженеры работают с двумя видами инцидентов:
• Пользовательские инциденты (в них выбраны конкретные затронутые бизнес-сервисы)
• Мониторинговые инциденты (инциденты, полученные в результате мониторинга)
Система IT Service Management, то есть, управление ИТ-услугами (ITSM) на исследуемом проекте имеет следующую особенность -когда агенты первой линии поддержки создают инцидент, они не назначают их на конкретную команду поддержки, так как могут не знать в чем основная причина инцидента и это частая ситуация, когда сотрудники первой линии технической поддержки не обладают достаточными компетенциями для точного определения причины проблемы, описанной в инциденте.
Для этого предлагается создать специальную общую очередь для инцидентов (рис. 4), относящихся к командам поддержки IT департамента, который содержит в себе участников второй линии поддержки.
Рис. 4. Схема создания специальной общей очереди
Несмотря на то, что общая очередь инцидентов включает в себя всех участников со второй линии поддержки, для каждой команды существует своя очередь инцидентов и в нее входят участники второй и третей линии по соответствующей поддержке приложения или части инфраструктуры.
Общая очередь используется для пользовательских инцидентов, которые заводятся агентами технической поддержки на первой ли-
нии и для мониторинговых инцидентов, которые были изначально настроены на отправку в общую очередь инцидентов в мониторинговой системе. Таким образом, инженеры второй линии должны постоянно следить за общей очередью на наличие появляющихся инцидентов.
Здесь есть большой риск нарушения сервисного времени выполнения инцидентов по причине несогласованности действий инженеров. Причинами могут служить как человеческий фактор, так и недобросовестность инженеров, что приводит к нарушению договора по выполнению и решению инцидента и последующими санкциями со стороны заказчика.
Рис. 5. Логическая схема разделения стеков команд поддержки в ITSM системе
Чтобы избежать подобных проблем, в процесс инцидент менеджмента вводится дополнительная роль Координатора инцидентов. Основной задачей в соответствии с целями данного исследования является высокоуровневая координация инцидентов, их распределение между командами и инженерами, с целью обеспечения максимального быстрого назначения инцидентов на инженеров [5, 6].
На вход обученной модели подается краткое и полное описание инцидента, которое после преобразования выдает результат в виде рейтинга вероятных команд поддержки по убыванию.
Пример предполагаемых команд поддержки:
1. Команда поддержки почтовых серверов - 94%
2. Команда поддержки конечных пользователей серверов - 5%
3. Команда поддержки IIS Web Services - 1%
Результаты работы программы выводятся в виде удобочитаемого текста, который на данном этапе выполняет информационную роль в помощь Координатору решения в принятии решения о назначении инцидента в стек команды. Выполнение программы с момента входа исходных данных до отображения результата занимает несколько секунд и покрывает первые 4 этапа процедуры Координатора инцидентов с приблизительной точностью около 90%, в то время как Координатор инцидентов при самостоятельном принятии решения тратит около 10 минут времени с высокой долей ошибки определения команды, ответственной за решение инцидента. При использовании модели поддержки принятия решения Координатору остается только выбрать подходящего инженера.
Подготовка входных данных и их преобразование
После того, как получены данные в необработанном виде, наступает этап подготовки и описания модели. Можно выделить несколько этапов преобразования данных:
1) Преобразование описания инцидентов. Краткое описание и полное описание объединяется в одну строку для последующей трансформации. Впоследствии используется в качестве входных данных.
2) Проверка маркеров. Маркеры - это результат предсказания модели. На примере данных таблицы 1 маркерами являются значения столбца Команда поддержки для текущей подзадачи.
3) Текстовый препроцессинг.
• Векторизация текста. При создании модели использовался векторизатор, потому что он эффективно справляется с трансформацией текста в векторы на сравнительно небольшом количестве данных. Основной идей векторизации является
развертывание всего текста в матрицу, где столбец является элементом документов, а строка - самим документом. К примеру, у нас есть 4 документа:
• 1. Почта не открывается на компьютере, 2. Почта открывается очень долго, 3. Компьютер завис и не отвечает, 4. Компьютер запускается очень долго.
• Каждый элемент документа - слово, которое называется юни-граммой.
На примере этих документов мы получаем колонки матрицы.
Таблица 1.
Заголовки матрицы векторизатора, состоящая из элементов (юниграмм)
Почта Не Открывается На Компьютер Завис Отвечает И Запускается
После этого происходит определение элементов, которое встречается в каждом документе. После того, как шаблон сгенерирован, заполнение матрицы происходит по следующему механизму: если элемент встречается в текущем документе, то ему присваивается 1, иначе присваивается 0.
Таблица 2.
Итоговая матрица векторизации
Почта е к Открывается а к Компьютер Завис Отвечает к Запускается
Почта не открывается на компьютере 1 1 1 1 1 0 0 0 0
Почта открывается очень долго 1 0 1 0 0 0 0 0 0
Компьютер завис и не отвечает 0 1 0 0 1 1 1 1 0
Компьютер запускается очень долго 0 0 0 0 1 0 0 0 1
В конечном итоге образуется многомерная матрица, где для каждого документа составляется вектор слов, которые встречаются в документе.
Стоит отметить, что именования колонок матрицы следует именовать как характеристики документов.
Был рассмотрен простейший пример векторизации ^-грамм. В исследовании используется преобразование текста в число (разреженная матрица) с TF-IDF п грамм. Минимальная частота для функции равна 3.
Использование TF-IDF позволяет преобразовать используемые документы в следующую матрицу:
Таблица 3.
Итоговая матрица векторизации на базе TF-IDF
« о й а в ft я т « с й а
Почта U к 5 6 CD а к 8 Завис св 5 [2 о s X с За
Почта не открывается на компьютере 0,32 0,32 0,61 0,61 0,48 0 0 0 0
Почта открывается очень долго 0,32 0 0,32 0 0 0 0 0 0
Компьютер завис и не отвечает 0 0,32 0 0 0,61 0,48 0,48 0,61 0,48
Компьютер запускается очень долго 0 0 0 0 0,32 0 0 0 0,48
Подготовка модели для обучения и тестирования
После того, как все этапы подготовки, преобразования и трансформации текста выполнены, наступает этап обучения модели. Как упомянуто ранее, в качестве модели выбран алгоритм логистической регрессии, который обучается на 70% данных и тестируется на оставшихся тридцати процентах. Так как преобразования текста, создание модели и ее обучение производится в программной среде языка Python, используется библиотека для научных вычислений sklearn, которая также содержит необходимый векторизатор TF_IDF для трансформации текста в вектора.
В основе обучения, как упоминалось ранее, лежит использование полиноминальной логистической регрессии, результатом которой является прогнозирование соответствующей команды поддержки по определенной проблеме. В ходе эксперимента выясняется, что нельзя брать как результат только одну команду поддержки, так как инцидент может иметь составную проблему, где требуется привлечение сразу несколько команд для решения [7]. С другой стороны,
описание инцидента может быть составлено некорректно, и основная причина проблема пользователя может заключаться в области ответственности другой команды. Поэтому было принято решение выводить рейтинг самых вероятных команд для решения проблемы, описанной в инциденте [8].
Согласно определенным требованиям, можно получить ответ как должна обучаться модель [9].
Анализ и проведение экспериментов по повышению качества работы модели
После того, как была получена обученная модель, которая предсказывает команду поддержки, средствами языка Python ее можно сохранить в виде специального файла, который можно потом подключать как самостоятельный модуль (рис. 6).
Экспериментальным путем было выяснено, что для каждой команды поддержки будет создана своя обученная модель, которая будет подключаться в зависимости от предсказанной команды поддержки первой моделью. Каждая модель команды поддержки содержит в себе все те же преобразования, которые использовались для первой модели. Единственное отличие заключается в том, что для каждой модели исходные данные будут преобразовываться и фильтроваться по соответствующей команде поддержки.
Рис. 6. Логическая схема модуля предсказания для определения команды поддержки
Таким образом, фильтруя данные только по конкретной команде поддержки, можно предотвратить зашумленность данных, которая может повлиять на получаемое предсказание.
Для каждой модели в данных используется маркер столбца инженеров, так как именно их планируется предсказывать по результа-
там выполнения работы обученной модели. Как и в первой модели происходят последовательные этапы преобразования текста, в результате которого мы получаем матрицы неточностей по количеству инцидентов и с нормализованными значениями по предсказаниям инженеров.
Таблица 4.
Пример данных по решенным инцидентам для конкретной команды поддержки с инженерами
Краткое описание Полное описание Статус Команда поддержки Инженер
Почта. Не работает На моем ноутбуке не работает почта <. > Решен Поддержка конечного пользователя Инженер 1
Интернет отсутствует Не получается открыть страницу в веб-браузере <. > Решен Поддержка конечного пользователя Инженер 3
Приложение не открывается на ноутбуке Не удается открыть приложение Решен Поддержка конечного пользователя Инженер 5
Инженер отсутствует на рабочем месте Инженер отсутствует на рабочем месте Ушел Поддержка конечного пользователя Инженер 2
Таблица 5.
Нормализованная матрица неточностей между инженерами команды поддержки в процентном соотношении
Engineer1 0.59 0.00 0.09 0.09 0.17 0.06
No in the team 0.03 0.00 0.16 0.24 0.57 0.00
Engineer2 0.08 0.00 0.54 0.08 0.19 0.11
Engineer3 0.05 0.00 0.09 0.59 0.16 0.12
Engineer4 0.19 0.00 0.14 0.10 0.54 0.03
Engineer5 0.27 0.00 0.18 0.45 0.00 0.09
Engineer! No in the team Engineer2 Engineer3 Engineer4 Engineer5
Рассмотрим матрицу неточностей для одной команды поддержки, участниками которой являются 5 инженеров. Проанализировав рисунок 25, можно сделать вывод, что процент неточностей достаточно высок. Помимо инженеров здесь присутствуют значения Not in the
Team, которые указывают на то, что некоторые инциденты могли закрываться без явного указания инженера или этот инженер когда-то был участником команды поддержки. Так как данные берутся за несколько лет и кадровые перестановки являются неотъемлемой частью динамического бизнеса, нельзя очищать данные, которые могут содержать в себе важные связи, влияющие на обучение и точность предсказания.
Одной из важных характеристик матрицы неточностей с нормализованными значениями является тот факт, что сумма значений по горизонтали для инженера (фактические значения) равна 1 по каждой метке, но суммы по вертикали (предсказанные значения) обычно далеки от единицы. Это означает, что некоторые инженеры будут предсказываться чаще, чем другие, и это может создать общий дисбаланс для модели. Основываясь на этом, модель обучается, корректируя начальные веса, чтобы достичь суммы по вертикали, близкой к 1.0 (+- 0.05).
Таким образом, с точки зрения алгоритма, модель берет базовые веса и начинает их перераспределять, из цикла в цикл. Одним из условий является, что цикл имеет в среднем около 15 итераций, чтобы предотвратить бесконечное выполнение или излишнего переобучения модели.
Важными отличиями моделей предсказания подходящих инженеров от первой модели по определению команды являются:
• Для каждой модели будет строго предопределен словарь актуальных инженеров. Это позволит избежать ошибок в обучении и предсказании инженеров, которые уже не участвуют в деятельности команды поддержки.
• Задается словарь корректировочных весов для инженеров, которые участвовали в решении инцидентов, но теперь не участвуют в деятельности проектной команды (Not in the Team). Эти значения нельзя игнорировать, и они будут равномерно распределяться по весам остальных, актуальных инженеров в процессе обучения и с помощью математических преобразований
Bode lDef i neResolver=LogisticRegression (cía s s_we ight=d i ctweighrt,
solver='saga'jrnaK_iter=i0000, c=l, inulti_class='niultirionial').fit(x_train, res_train)
Рис. 7. Основная функция обучения модели по инженерам команды поддержки
Выше представлена общая функция обучения модели мульти-номинальной логистической регрессии, которая имеет следующие параметры:
• Class_weight = dictWeight - подключения словаря весов для распределения весов неактуальных инженеров среди действующих инженеров команды поддержки
• Solver='SAGA' - нестандартный метод оптимизации алгоритма мультиноминальной логистической регрессии, повышающий скорость и точность обучения алгоритма
• Max_iter=10000 - количество итераций прогонов при обучении алгоритма
• С=1 - параметр регуляризации, который был подобран экспериментальным путем
• Multi_class='multinominal' - параметр отвечающий за выполнения не бинарной классификации, таким образом количество классов будет зависеть от количества инженеров команды поддержки.
• Fit(X_train, res_train) - обучение модели на тренировочных данных X_train и последующей тренировкой на тестовых данных res_train, которые до этого не участвовали в процессе обучения
После того, как каждая модель будет обучена для каждой команды поддержки по инженерам, полученные модели будут также сформированы в модульные файлы, которые будут подключаться на основе результатов модели определения команды поддержки. Структура обобщенной модели будет выглядеть следующим образом:
□ Предсказание команды / Подключение модели I—К
О—
о—
Модель определения Модели определения Выбранная модель Предсказание
команды поддержки инженера поддержки инженера
Рис. 8. Логическая схема улучшенной модели программного решения
Таким образом, улучшенная модель позволит определять инженеров соответствующей команды поддержки. При определении команды поддержки первой моделью (наиболее вероятную в списке предлагаемых), срабатывает механизм подключения соответствующей модели для предсказанной команды, и после ее выполнения программа выдаст базовое предсказание наиболее подходящих инженеров для решения инцидента.
В ходе эксперимента, автором исследования были обнаружены следующие недостатки:
• Несмотря на высокую точность первой модели по определению команды поддержки, самая вероятная команда может быть неправильно предсказана, что влечет за собой подключение неправильной модели по предсказанию инженеров.
• Базовое предсказание инженеров опирается только на статистические данные, на которых обучалась модель, не учитывая текущее состояние инженера и его доступность для решения инцидента.
Авторами исследования было предпринято решение по поиску оптимизации предсказанного значения, который будет максимально соответствовать действительности. Для этого были рассмотрены следующие направления по улучшению:
• Получение данных о состоянии инженера, посредством получения статуса в коммуникаторе Skype. Статусы: доступен, занят, не в сети имеют свои весовые характеристики, которые будут влиять на значение предсказания инженера. Эмпирическим путем была получена зависимость значения веса от времени отсутствия инженера на месте. Чем больше прошло времени, согласно статусу«Ушел», тем меньше будет результирующий вес предсказания для выбора подходящего инженера.
• Получение данных о загрузке инженера. Данный коэффициент влияет на вес предсказания согласно проектной загрузке инженера в проектной работе. Для этого должно быть подсчитано количество инцидентов, назначенных на инженера, количество инцидентов в очереди команды.
• Полученное процентное соотношение также будет влиять на результирующий вес предсказания, чтобы избежать излишней нагрузки на одного инженера.
Автор исследования полагает, что принятые меры по оптимизации предсказанных результатов позволят получить наиболее точное предсказание в сравнении с базовым предсказанием. Ниже приведена таблица с учетом коэффициентов, которые влияют на вес итогового предсказания:
Таблица 6.
Пример расчетов числовых характеристик для корректировки
базового предсказания инженера команды поддержки
Кол-во инцидентов Коэффициент отклонения Нормализованное значение коэффициента Базовое предсказание Предска-зание*Загрузка Нормализованный итоговый результат
Engmeer1 8 -1.4 4.38 0.08 0.3504 5.908937605
Engmeer2 2 4.6 10.38 0.03 0.3114 5.251264755
Engineer3 10 -3.4 2.38 0 0 0
Engineer4 10 -3.4 2.38 0.09 0.2142 3.612141653
Engineer5 10 -3.4 2.38 0.25 0.595 10.03372681
Engineer6 5 1.6 7.38 0.05 0.369 6.222596965
Engineer7 3 3.6 9.38 0.15 1.407 23.72681282
Как можно видеть из таблицы 6, базовое предсказание указывало на Инженера 5 как на самого подходящего инженера для решения инцидента. С учетом применения корреляционных весов, итоговый результат указывает на Инженера 7 как наиболее подходящего инженера для решения задачи в данный момент времени.
Таким образом было рассмотрено устройство модели принятия решения автоматизированный информационный комплекс (АИК) с точки зрения построения принципов взаимодействия компонентов и ролей в инцидент менеджменте.
Заключение
Международные исследования в области ^ обслуживания показывают, что с возрастанием объемов бизнеса и конечных пользователей, пропорционально возрастает и объем данных, которые должны обрабатываться большим количеством инженеров и коорди-
нироваться компетентными людьми для предоставления качественного сервиса, поэтому в рамках диссертационного работы были изучены методы и алгоритмы машинного обучения, которые входят в основу программного решения по автоматизации деятельности Координатора инцидентов в рамках управления IT обслуживанием.
В данной работе спроектировано и создано программное решение на языке Python, которое содержит в себе интеллектуальную обученную модель принятия решения.
Были изучены и описаны процессы управления инцидент менеджмента на существующем проекте сервисного обслуживания. Рассмотрены этапы создания модели принятия решения, обучаемые на входных данных, отличительные особенности обучения модели и ее параметризация, которая подбиралась опытным путем в рамках проведения экспериментов. Полученные экспериментальные данные показывают, что точность прогнозирования в принятии решения достигает 90%, при наименьших затратах времени.
При разработке программного решения по управлению IT-обслуживанием на основе методов машинного обучения были решены следующие задачи:
- Углубленное изучение принципов ITIL как основополагающую методологию в сфере IT-обслуживания для поиска приоритетных проблем с целью их автоматизации.
- Проведен анализ роли координатора инцидентов в описательной модели сервисного IT обслуживания.
- Были сформулированы и проработаны предложения по совершенствованию управления IT-обслуживанием в контексте деятельности инцидент-координатора.
- Реализована модель принятия решения на основе методов логистической регрессии средствами среды разработки языка Python.
Список литературы 1. Родионова В.О., Федоркова Н.В. Исследование и моделирование
организационной культуры региональных конкурентоспособных
машиностроительных предприятий // Моделирование, оптимизация и информационные технологии. 2022. Т. 10. № 3 (38). С. 7-8.
2. Ковалев И.В., Ковалев Д.И., Амбросенко Н.Д., Боровинский Д.В. Анализ тестовых задач мультиверсионного формирования отказоустойчивых программных систем // Моделирование, оптимизация и информационные технологии. 2022. Т. 10. № 2 (37).
3. Львович Э.М., Чупринская Ю.Л., Кравцова Н.Е. Способы оценки и анализа проектных рисков // Вестник Воронежского института высоких технологий. 2021. № 2 (37). С. 107-109.
4. Коростелева Н.А., Попова С.С., Новичкова А.А. О проблемах моделирования функционирования организаций // Вестник Воронежского института высоких технологий. 2021. № 2 (37). С. 31-33.
5. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Simulation of agricultural enterprises based on the optimization of the components with the transformation - game model // IOP Conference Series: Earth and Environmental Science. conference proceedings. Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2020. С. 32060.
6. Коростелева Н.А., Батищев П.А., Денисенко С.С. Проблемы оценки эффективности работы организаций // Вестник Воронежского института высоких технологий. 2021. № 2 (37). С. 101-103.
7. Lvovich Y., Tishukov B., Preobrazhenskiy A., Choporov O. Optimizing modeling of complex-structured objects in the problem of improving the efficiency of their functioning // IOP Conference Series: Materials Science and Engineering. International Workshop "Advanced Technologies in Material Science, Mechanical and Automation Engineering - MIP: Engineering - 2019". Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2019. С. 42047.
8. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Optimization processes in the internet of things system at agricultural enterprises // IOP Conference Series: Earth and Environmental Science. III International Scientific Conference: AGRI-TECH-III-2020: Agribusiness, Environmental Engineering and Biotech-
nologies. Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2020. С. 22086.
9. Прохорова О.К., Могунов И.В. Человеческий капитал как источник устойчивого конкурентного преимущества организации // Вестник Воронежского института высоких технологий. 2022. № 2 (41). С. 140-145.
10. Чупринская Ю.Л., Линкина А.В. Краткий обзор современных технологических трендов в контексте цифровой трансформации // Вестник Воронежского института высоких технологий. 2022. № 1 (40). С. 107-109.
11. Воронов А.А., Блинов Р.А., Смирнов А.О., Иванов П.Т., Александров А.А. Применение методов системного анализа для повышения эффективности работы транспортных предприятий // Вестник Воронежского института высоких технологий. 2022. № 1 (40). С. 114-117.
12. Прохорова О.К., Куршин И.А., Прохорова А.Е. Методические подходы к оценке конкурентных преимуществ организации // Вестник Воронежского института высоких технологий. 2022. № 2 (41). С. 146-150.
13. Маслова Е.В., Колесникова О.А. К вопросу об обеспечении организаций кадрами в современных демографических условиях // Вестник Воронежского института высоких технологий. 2022. № 3 (42). С. 135-146.
14. Львович Э.М., Чупринская Ю.Л., Кравцова Н.Е. Особенности типологии проектных рисков // Вестник Воронежского института высоких технологий. 2021. № 2 (37). С. 104-106.
15. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Modeling and optimization of software components for control of industrial enterprises // Journal of Physics: Conference Series. Krasnoyarsk, Russian Federation, 2020. С. 32008.
16. Рындин Н.А. Компонентная оптимизация развивающейся цифровой среды управления в организационных системах // Моделирование, оптимизация и информационные технологии. 2022. Т. 10. № 2 (37).
17. Lvovich I.Ya., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Lvovich Ya.E. Modeling and optimization of resources in information systems //
Proceedings of SPIE - The International Society for Optical Engineering. Сер. "Computer Applications for Management and Sustainable Development of Production and Industry, CMSD 2021" 2022. С. 122510E.
18. Муха В.В. Оптимизация цифровой нити логистических цепочек в практике управления организационными системами // Моделирование, оптимизация и информационные технологии. 2022. Т. 10. № 1 (36).
19. Кебадзе, Е. А. Управление бизнес-процессами в сфере it с использованием методов сервис-менеджмента и BPM // Управленческие науки в современном мире. - 2018. - Т. 2. - № 1. - С. 187-190. - EDN UQVOYZ.
20. Тушавин, В. А. Особенности аутсорсинга в сфере информационно-коммуникационных технологий // Менеджмент и бизнес-администрирование. - 2014. - № 1. - С. 79-86. - EDN SAFSHL.
21. Т. А. Блатова, В. В. Макаров, М. Г. Слуцкий. Роль повышения удовлетворенности потребителей в системе управления качеством провайдера цифровых услуг и решений // Экономика и бизнес: теория и практика. - 2022. - № 7(89). - С. 23-26. - DOI 10.24412/2411-04502022-7-23-26. - EDN NTXDCG.
22. Апатова, Н. В. Управление процессами цифровой трансформации бизнеса // Ученые записки Крымского федерального университета имени В.И. Вернадского. Экономика и управление. - 2022. - Т. 8. -№ 2. - С. 3-8. - EDN SCWJEG.
23. Степанова, Т. В. Подходы к управлению бизнес-процессами торговых организаций // Образование, экономика, общество. - 2014. - № 3-4(43-44). - С. 64-67. - EDN UMBYRP.
24. О. В. Воронова, И. В. Ильин, О. Ю. Ильяшенко. Формирование архитектуры данных сетевых компаний FMCG-ритейла на основе моделирования основных бизнес-процессов (на примере бизнес-процесса «закупка») // Известия Санкт-Петербургского государственного экономического университета. - 2019. - № 6(120). - С. 105-115. - EDN HROIRS
25. Тушавин, В. А. Методика оптимизации численности персонала провайдера // Информационно-управляющие системы. - 2014. - № 6(73). - С. 129-133. - EDN TFOXXP.
26. Котляров, И. Д. Аутсорсинг как форма межфирменной кооперации: теоретический анализ // Вестник Института экономики Российской академии наук. - 2015. - № 5. - С. 19-31. - EDN UMLXDF.
27. Блинникова А.В., Нестерова Ю.О. Управление инцидентами в itsm с использованием искусственного интеллекта // Вестник университета. 2020. № 6. С. 36-40.
References
1. Rodionova V.O., Fedorkova N.V. Issledovanie i modelirovanie organi-zacionnoj kul'tury regional'nyh konkurentosposobnyh mashinostroi-tel'nyh predpriyatij [Research and modeling of organizational culture of regional competitive machine-building enterprises] // Modelirovanie, optimizaciya i informacionnye tekhnologii. 2022. T. 10. № 3 (38). S. 7-8.
2. Kovalev I.V., Kovalev D.I., Ambrosenko N.D., Borovinskij D.V. Anal-iz testovyh zadach mul'tiversionnogo formirovaniya otkazoustojchivyh programmnyh system [Analysis of test problems of multiversion formation of fail-safe software systems] // Modelirovanie, optimizaciya i informacionnye tekhnologii. 2022. T. 10. № 2 (37).
3. L'vovich E.M., CHuprinskaya YU.L., Kravcova N.E. Sposoby ocenki i analiza proektnyh riskov [Methods of project risk assessment and analysis] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2021. № 2 (37). S. 107-109.
4. Korosteleva N.A., Popova S.S., Novichkova A.A. O problemah mod-elirovaniya funkcionirovaniya organizacij [On the problems of modeling the functioning of organizations] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2021. № 2 (37). S. 31-33.
5. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Simulation of agricultural enterprises based on the optimization of the components with the transformation - game model // IOP Conference Series: Earth and Environmental Science. conference proceedings. Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2020. С. 32060.
6. Korosteleva N.A., Batishchev P.A., Denisenko S.S. Problemy ocenki ef-fektivnosti raboty organizacij [Problems of Assessing the Effectiveness
of Organizations] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2021. № 2 (37). S. 101-103.
7. Lvovich Y., Tishukov B., Preobrazhenskiy A., Choporov O. Optimizing modeling of complex-structured objects in the problem of improving the efficiency of their functioning // IOP Conference Series: Materials Science and Engineering. International Workshop "Advanced Technologies in Material Science, Mechanical and Automation Engineering -MIP: Engineering - 2019". Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2019. C. 42047.
8. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Optimization processes in the internet of things system at agricultural enterprises // IOP Conference Series: Earth and Environmental Science. IIIInternational Scientific Conference: AGRI-TECH-III-2020: Agribusiness, Environmental Engineering and Biotechnologies. Krasnoyarsk Science and Technology City Hall of the Russian Union of Scientific and Engineering Associations. 2020. C. 22086.
9. Prohorova O.K., Mogunov I.V. CHelovecheskij kapital kak istochnik usto-jchivogo konkurentnogo preimushchestva organizacii [Human capital as a source of sustainable competitive advantage of the organization] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2022. № 2 (41). S. 140-145.
10. CHuprinskaya YU.L., Linkina A.V. Kratkij obzor sovremennyh tekhnolog-icheskih trendov v kontekste cifrovoj transformacii [Brief overview of modern technological trends in the context of digital transformation] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2022. № 1 (40). S. 107-109.
11. Voronov A.A., Blinov R.A., Smirnov A.O., Ivanov P.T., Aleksandrov A.A. Primenenie metodov sistemnogo analiza dlya povysheniya effektivnosti raboty transportnyh predpriyatij [Application of methods of system analysis to improve the efficiency of transport enterprises] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2022. № 1 (40). S. 114-117.
12. Prohorova O.K., Kurshin I.A., Prohorova A.E. Metodicheskie podhody k ocenke konkurentnyh preimushchestv organizacii [Methodical Approaches to the Assessment of Competitive Advantages of the Organization] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2022. № 2 (41). S. 146-150.
13. Maslova E.V., Kolesnikova O.A. K voprosu ob obespechenii organizacij kadrami v sovremennyh demograficheskih usloviyah [On the issue of providing organizations with personnel in modern demographic conditions] // Vestnik Voronezhskogo instituta vysokih tekhnologij. 2022. N° 3 (42). S. 135-14б.
14. L'vovich E.M., CHuprinskaya YU.L., Kravcova N.E. Osobennosti tipologii proektnyh riskov [Peculiarities of the typology of project risks]// Vestnik Voronezhskogo instituta vysokih tekhnologij. 2021. Я 2 (37). S. 104-10б.
15. Lvovich I.Ya., Lvovich Ya.E., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Choporov O.N. Modeling and optimization of software components for control of industrial enterprises // Journal of Physics: Conference Series. Krasnoyarsk, Russian Federation, 2020. С. 3200S.
16. Ryndin N.A. Komponentnaya optimizaciya razvivayushchejsya cifrovoj sredy upravleniya v organizacionnyh sistemah [Component Optimization of the Developing Digital Control Environment in Organizational Systems] // Modelirovanie, optimizaciya i informacionnye tekhnologii. 2022. T. 10. Ш 2 (37).
17. Lvovich I.Ya., Preobrazhenskiy A.P., Preobrazhenskiy Yu.P., Lvovich Ya.E. Modeling and optimization of resources in information systems // Proceedings of SPIE - The International Society for Optical Engineering. Сер. "Computer Applications for Management and Sustainable Development of Production andIndustry, CMSD 2021" 2022. С. 122510E.
1S. Muha V. V. Optimizaciya cifrovoj niti logisticheskih cepochek v praktike upravleniya organizacionnymi sistemami [Optimization of the digital thread of logistics chains in the practice of management of organizational systems] // Modelirovanie, optimizaciya i informacionnye tekhnologii. 2022. T. 10. Ш 1 (3б).
19. Kebadze, E. A. Upravlenie biznes-processami v sfere it's ispol'zovaniem metodov servis-menedzhmenta i BPM [Business process management in the field of it using service management and BPM methods] // Upra-vlencheskie nauki v sovremennom mire. - 201S. - T. 2. - Я 1. - S. 187190. - EDN UQVOYZ.
20. Tushavin, V. A. Osobennosti autsorsinga v sfere informacionno-kommu-nikacionnyh tekhnologij [Features of outsourcing in the sphere of infor-
mation and communication technologies] // Menedzhment i biznes-ad-ministrirovanie. - 2014. - N 1. - S. 79-8б. - EDN SAFSHL.
21. T. A. Blatova, V. V. Makarov, M. G. Sluckij. Rol' povysheniya udov-letvorennosti potrebitelej v sisteme upravleniya kachestvom provajdera cifrovyh uslug i reshenij [The role of increasing customer satisfaction in the quality management system of the provider of digital services and solutions] // Ekonomika i biznes: teoriya ipraktika. - 2022. - No 7(89). -S. 23-2б. - DOI 10.24412/2411-0450-2022-7-23-2б. - EDN NTXDCG.
22. Apatova, N. V. Upravlenie processami cifrovoj transformacii biznesa [Management of the processes of digital transformation of business] // Uchenye zapiski Krymskogo federal 'nogo universiteta imeni V.I. Vernadskogo. Ekonomika i upravlenie. - 2022. - T. 8. - N 2. - S. 3-8. - EDN SCWJEG.
23. Stepanova, T. V. Podhody k upravleniyu biznes-processami torgovyh organizacij [Approaches to the management of business processes of trade organizations] // Obrazovanie, ekonomika, obshchestvo. - 2014. -N 3-4(43-44). - S. б4-б7. - EDN UMBYRP.
24. O. V Voronova, I. V. Il'in, O. YU. Il'yashenko. Formirovanie arhitektury dan-nyh setevyh kompanij FMCG-ritejla na osnove modelirovaniya osnovnyh biznes-processov (na primere biznes-processa "zakupka") [Formation of FMCG-retail network companies data architecture based on the modeling of key business processes (on the example of the business process "purchase")] // Izvestiya Sankt-Peterburgskogo gosudarstvennogo ekonomicheskogo universiteta. - 2019. - N б(120). - S. 105-115. - EDN HROIRS
25. Tushavin, V. A. Metodika optimizacii chislennosti personala provajdera [Methodology for optimizing the number of provider personnel] // Infor-macionno-upravlyayushchie sistemy. - 2014. - N б(73). - S. 129-133. - EDN TFOXXP.
26. Kotlyarov, I. D. Autsorsing kak forma mezhfirmennoj kooperacii: teo-reticheskij analiz [Methodology for optimizing the number of provider personnel] // Vestnik Instituta ekonomiki Rossijskoj akademii nauk. -2015. - N 5. - S. 19-31. - EDN UMLXDF.
27. Blinnikova A.V., Nesterova YU.O. Upravlenie incidentami v itsm s is-pol'zovaniem iskusstvennogo intellekta [Incident management in itsm using artificial intelligence] // Vestnik universiteta. 2020. N б. S. 3б-40.
ДАННЫЕ ОБ АВТОРАХ Аветисян Татьяна Владимировна, специалист проектного отдела ВИВТ
Автономная некоммерческая образовательная организация высшего образования Воронежский институт высоких технологий ул. Ленина, 73а, г. Воронеж, 394043, Российская Федерация vtatyana_avetisyan@mail.ru
Львович Яков Евсеевич, профессор, доктор технических наук, профессор
ФГБОУ ВО «Воронежский государственный технический университет»
ул. 20 лет Октября, 84, г. Воронеж, 394006, Российская Федерация office@vivt.ru
Преображенский Андрей Петрович, профессор, доктор технических наук, профессор
Автономная некоммерческая образовательная организация высшего образования Воронежский институт высоких технологий ул. Ленина, 73а, г. Воронеж, 394043, Российская Федерация Komkovvivt@yandex.ru
Преображенский Юрий Петрович, проректор по ИТ, кандидат технических наук, доцент
Автономная некоммерческая образовательная организация высшего образования Воронежский институт высоких технологий ул. Ленина, 73а, г. Воронеж, 394043, Российская Федерация office@vivt.ru
DATA ABOUT THE AUTHORS Tatiana V. Avetisyan, specialist of the VIVT project department
Voronezh Institute of High Technologies
73a, Lenin Str., Voronezh, 394043, Russian Federation
vtatyana_avetisyan@mail.ru
ORCID: https://orcid.org/0000-0003-3559-6070
Yakov E. Lvovich, Doctor of Technical Sciences, Professor Voronezh State Technical University
84, 20 years of October Str., Voronezh, 394006, Russian Federa-
tionKomkovvivt@yandex.ru
ORCID: https://orcid.org/0000-0002-7051-3763
Andrey P. Preobrazhenskiy, Professor, Doctor of Technical Sciences, Associate Professor
Voronezh Institute of High Technologies
73a, Lenin Str., Voronezh, 394043, Russian Federation
Komkovvivt@yandex.ru
ORCID: https://orcid.org/0000-0002-6911-8053
Yuri P. Preobrazhensky, Vice-Rector for IT, Candidate of Technical Sciences, Associate Professor
Voronezh Institute of High Technologies
73a, Lenin Str., Voronezh, 394043, Russian Federation
office@vivt.ru
Поступила 18.01.2023
После рецензирования 30.01.2023
Принята 10.02.2023
Received 18.01.2023 Revised 30.01.2023 Accepted 10.02.2023
