В статье исследуется актуальная тема разработки автоматизированной системы поддержки принятия решений для руководителя ИТ-подразделения на промышленном предприятии.

Ключевые слова: СППР, Python, Django, ИТ-инфраструктура.

Основная задача любой управленческой деятельности — это принятие решений. Отметим, что принятие решений происходит на всех уровнях управления в условиях огромного количества информации, поступающей из разных источников, а принятые решения имеют как краткосрочные, так и долгосрочные последствия. Неудивительно, что в таких условиях все большее применение находят автоматизированные системы поддержки принятия решений (СППР) [1].

СППР — компьютерные автоматизированные системы, которые помогают работникам принимать решения по финансовому планированию в сложных условиях, проводя полный и объективный анализ предметной деятельности. СППР возникли в результате слияния управленческих информационных систем и систем управления базами данных [2].

СППР должна учитывать особенности процесса принятия решений на предприятии и существующих данных в организации.

Разработкой СППР занимаются как крупные корпорации, так и небольшие команды разработчиков. Для разных процессов применяются разные методы и математические модели [3,4]. Ряд работ посвящен классификации методов, применяемых для построения СППР [5].

В работе [6] представлена система NERPA ERP от компании NOVOSOFT, которая в структуре программы NERPA ERP использует модуль аналитики BI. С помощью этого модуля процесс поддержки управления процессами в различных отраслях реализуется в виде результатов анализа, представленных разнообразными бизнес-отчётами, помогающими быстрой и результативной выработке оптимальных управленческих решений. Система ERP NERPA — эффективная и современная система планирования ресурсов предприятия со сложным функционалом. Стоимость её внедрения в целом на мировом рынке может варьироваться от 180 000 до 750 000 долларов США для компаний среднего размера, что для решений непервостепенных задач является слишком дорогим [6].

В работе [7] представлена комплексная информационная система управления предприятием «1С: Предприятие», которая за счет большого количества модулей может быть использована для автоматизации различных видов учетной и управленческой деятельности на разных предприятиях. Однако в «1С: Предприятие» существуют ограничения в возможностях BI-аналитики. В первую очередь, это — проприетарный формат хранения данных в базе данных (БД) в файловом режиме: он делает недоступным к разбору на таблицы [7]. Во-вторых, отметим клиент-серверный вариант БД, в котором таблицы данных 1С генерируются автоматически с использованием «внутренних идентификаторов». Это делает невозможным прямое обращение к таблицам БД 1С 8.х для извлечения данных в аналитическое хранилище BI [7].

В [8] представлена программная система поддержки принятия решений «ИГЛА» (Интеллектуальный Генератор Лучших Альтернатив), которая основана на применении нечетких когнитивных моделей и обеспечивает поддержку группового построения и согласования нечеткой когнитивной карты, выполнение расчета и анализа ее системных показателей, а также динамического моделирования сценариев развития ситуации. Аналитическая low-code платформа Loginom [9] позволяет проводить анализ данных любого уровня сложности без программирования. Система поддержки принятия решений «Выбор» [10] предназначена для структуризации проблемы, построения набора альтернатив, помогает выделить характеризующие их факторы, задать значимость этих факторов, оценить альтернативы по каждому из факторов. Такие программные продукты, как программная платформа Интеграл Аналитика [11], многопользовательский цифровой инструмент интерактивного анализа Analytic Workspace [12], Аналитическая платформа Visiology [13], Almaz BI [14], — позволяют визуализировать данные, обрабатывать и обобщать информацию из разнородных автоматизированных систем.

Основными достоинствами готовых решений СППР [8–14], представленных на рынке, можно назвать проработанные решения с учетом мировых и отечественных практик и стандартов, помощь по внедрению системы опытными специалистами, наличие технической поддержки.

Однако большая стоимость внедрения таких продуктов, избыточный и громоздкий функционал, невозможность предварительной оценки эффективности программного продукта приводят к необходимости разработки собственного продукта, функционал которого ориентирован на сопровождение производственных задач предприятия. ИТ направление на промышленных предприятиях, как правило, не является профильным, поэтому зачастую финансирование ИТ подразделений — сильно ограничено.

В данной работе предложен недорогой вариант СППР для руководителя ИТ подразделения промышленного предприятия — АО «Синарский трубный завод». Разработанная автоматизированная система имеет ограниченный функционал и рассчитана под конкретные задачи предприятия: собирает данные из смежных подсистем, анализирует их, формирует отчеты с рекомендациями о необходимости замены оборудования и приобретения нового ПО, а также генерирует отчеты по оценке работы ИТ службы.

Методическая часть

Особенности объекта автоматизации текущего процесса принятия решений на предприятии

В ходе наблюдений было установлено, что в соответствии с внутренним регламентом сотрудники завода при возникновении неисправностей вычислительной техники подают заявки в службу поддержки посредством телефонных звонков, электронной почты или через портал самообслуживания. Первая линия поддержки обрабатывает поступившие заявки и передает их специалистам ИТ для устранения неисправностей. В случае невозможности устранения проблемы формируется заявка на приобретение нового оборудования, которая передается в отдел закупок. Закупленное оборудование передается в подразделение, где сотрудники ИТ осуществляют его установку. По завершении работ заявка закрывается, о чем уведомляется пользователь. При необходимости оснащения новых рабочих мест вычислительной техникой формируется обращение к руководителю ИТ для организации закупки и установки нового оборудования.

В связи с потребностью в специализированном программном обеспечении, руководитель собирает требования по ПО, учитывает необходимость регулярного продления лицензий, приобретения дополнительных модулей и обновлений существующих лицензий.

Таким образом, решение задачи определения статуса комплектации производства оборудованием и программным обеспечением, необходимым для бесперебойной работы ИТ инфраструктуры, сводиться к анализу обращений пользователей, состояния оборудования, а также потребности предприятия в лицензиях, дополнительных модулях и обновлениях ПО.

По результатам анализа формируется бюджет на следующий год, в рамках которого сотрудники ИТ приобретают необходимое оборудование и ПО.

Основная проблема процесса принятия решений на предприятии заключается в необходимости обработки большого объема данных за годовой период при отсутствии единой базы данных по оборудованию и программному обеспечению. В настоящее время специалисты службы поддержки ведут собственные списки оборудования с фиксированием его состояния, а отдел закупок — свои списки с привязкой к инвентарным номерам. Все данные заводятся вручную, поэтому в списках встречаются ошибки, связанные с человеческим фактором. Это создает сложности в управлении ресурсами и контроле за выполнением потребностей.

Также необходимо учитывать ограниченность бюджета на ИТ-инфраструктуру, который строго контролируется и должен полностью покрывать все потребности организации.

Таким образом, важной задачей является создание автоматизированной системы, позволяющей централизованно собирать и анализировать данные по оборудованию и ПО для оптимизации расходов и обеспечения бесперебойной работы всей инфраструктуры.

Требования к разрабатываемому программному продукту

Построение функционала автоматизированной системы проводилось в соответствии с требованиями к разрабатываемому программному продукту, для определения которых проводилось комплексное исследование, включающее опрос заинтересованных сторон, наблюдение за текущими рабочими процессами и анализ используемых инструментов в деятельности руководителя ИТ-подразделения АО «СинТЗ». В процессе выполнения работы информация собиралась из существующих систем (Microsoft Exchange Server, Lansweeper), из заключенных договоров (для определения сроков действия лицензий), из сводных документов Excel.

Анализ показал, что значительная часть времени руководителя ИТ уходит на сбор, обработку и анализ данных, необходимых для формирования годового бюджета, позволяющего планировать ресурсы и расходы на ИТ-инфраструктуру.

Таким образом, в разрабатываемой СППР должны содержаться и быть легко доступны следующие данные:

– сведения о пользователе, за которым закреплено оборудование;

– сведения о технических характеристиках оборудования;

– инвентарный номер;

– потребности в специализированном программном обеспечении;

– сведения о заявке на замену.

Программные средства автоматизированной системы

Разрабатываемую систему поддержки принятия решений было решено реализовывать в виде WEB — приложения с использованием фреймворка Django [17], написанного на python.

Django — свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC [17]. Проект поддерживается организацией Django Software Foundation. Использование данного фреймворка позволит значительно ускорить процесс разработки.

Использование языка программирования Python позволит сосредоточиться на разработке методов анализа данных, а не на написании кода.

Для быстрого создания современных, отзывчивых и кроссбраузерных веб-интерфейсов используется Bootstrap 5, являющийся бесплатным и опенсорсным фронтенд-фреймворком. Он включает готовые компоненты, сеточную систему и утилиты для стилизации, использует современный JavaScript без зависимостей от jQuery и полностью распространяется под лицензией MIT, что позволяет свободно использовать и модифицировать его в любых проектах.

Результаты

Разработка программного продукта включила следующие этапы:

1. Реализация требований для СППР, наиболее важные из которых — низкая стоимость разработки и внедрения, работа на всех современных ОС;
2. Автоматизация процессов сбора данных, в том числе взаимодействие с используемыми на предприятии информационными системами;
3. Разработка методов задания критериев и правил для обработки и анализа данных;
4. Разработка простого и интуитивно понятного интерфейса пользователя.

Проект архитектуры базы данных

Структура разрабатываемого приложения представлена на рис.1.

Рис. 1. Структурная схема приложения

По результатам анализа данных разработан проект архитектуры базы данных (БД). Выделены её основные направления — обновление и приобретение новых персональных компьютеров (ПК), учет серверов и сетевого оборудования, планирование и продление программного обеспечения (ПО). На рис. 2–3. представлены схемы организации БД для ПК и БД лицензий.

Таблицы «Owner» и «State» являются промежуточными: в них собираются данные из Microsoft Exchange Server и Lansweeper соответственно. Таблицы «User» и «Role» предназначены для авторизации пользователей и разграничения полномочий пользователей через их роли. Такая архитектура в дальнейшем позволила значительно уменьшить объем данных, вводимых вручную.

Рис. 2. Схема БД-модуля ПК

БД для лицензий спроектирована таким образом, чтобы можно было учитывать связь между лицензиями (см. рис.3).

Рис. 3. Схема БД-модуля Лицензии

Например, есть лицензия на «Право использования программы» для ЭВМ «ГРАНД-Смета». В дополнение к основной лицензии, необходимо ежегодно приобретать «Право на использование обновлений версий программы» для ЭВМ «ГРАНД-Смета». Кроме того, требуются дополнительные библиотеки: «Право на использование БД «ФСНБ-2022 в формате программы для ЭВМ «ГРАНД-Смета»»», а также «Право на использование обновлений БД «ФСНБ-2022 в формате программы для ЭВМ «ГРАНД-Смета»»» и некоторые другие. Сроки действия лицензий могут отличаться. Также лицензии могут быть конкурентными или привязанными к конкретному пользователю, что учитывается при проектировании БД.

Работа с критериями. Таблица фильтров

Для работы с критериями спроектирована отдельная таблица фильтров по каждому модулю. В данной таблице имеется название соответствующего фильтра, а также организована связь «многие ко многим» с параметрами фильтров. В параметрах фильтров задаются критерии — по каким полям, условиям и значениям полей будет происходить выборка данных. Параметры собираются в фильтре по принципу логического «ИЛИ». В один фильтр можно добавлять один или несколько параметров. Такой подход позволяет заранее подготовить сложные правила, включающие несколько критериев для обработки данных, и по мере необходимости выбирать нужный вариант обработки. При этом не требуется изменение программного кода. Структура БД для обработки данных представлена на рис.4.

Рис. 4. Схема БД-фильтров

Используя таблицы фильтров, можно, например, задать логику функционирования системы для определения потребности в ПК:

– устанавливаются минимальные требования к компьютерам;

– все ПК, не соответствующие этим требованиям, получают атрибут «требуется замена»;

– компьютеры, удовлетворяющие минимальным требованиям, но по которым поступали обращения в службу поддержки в связи с неудовлетворительной работой, также получают атрибут «требуется замена»;

– ПК, не отвечающие минимальным требованиям и имеющие обращения в службу поддержки по причине неудовлетворительной работы, получают атрибут «требуется замена».

Аналогично выстраивается логика работы СППР в отношении лицензий:

– выбираются лицензии, действие которых заканчивается через 2 месяца;

– по выбранным лицензиям отправляется уведомление на электронный адрес руководителя ИТ-отдела с указанием используемого программного обеспечения с заканчивающимся сроком действия лицензии;

– по обращениям от подразделений заносятся запросы на приобретение необходимого программного обеспечения;

– созданные позиции без даты приобретения получают атрибут «требуется приобретение»;

Аналогичная логика работы настраивается для обработки данных по серверному и сетевому оборудованию. Кроме того, в описанные выше сценарии можно добавлять ситуационные фильтры для получения дополнительной информации.

Интерфейс пользователя

Важным аспектом интерфейса пользователя является простота работы пользователя с автоматизированной системой. Для того чтобы информация, собранная и обработанная в СППР, была наглядной, и работа с СППР не требовала специальных знаний, разработан прототип интерфейса с минимальным набором необходимых инструментов. Макет главной страницы (рис.5) выполнен в форме информационной панели — даш-борда, на которой выводиться графическая информация временного изменения потребности в оборудовании и лицензиях, а также его отношения к общему числу оборудования. Например, на начало года требовалось 354 ПК, из которых 276 ПК — уже существующее оборудование, требующее замены, а 78 ПК — новые рабочие места. В течение года было организовано две закупки оборудования по 100 единиц, т. е. всего 200 комплектов ПК. После установки необходимого ПО комплекты ПК передаются в подразделения в среднем по 30 комплектов в месяц. При этом необходимо отметить, что первоначальная потребность в течении года изменялась в связи с выходом оборудованием из строя, а также в связи с изменением штатного расписания предприятия.

Кроме графиков, планируется использовать столбчатые диаграммы для отображения изменения потребностей оборудования и ПО по месяцам и круговые диаграммы для сравнительной оценки потребностей в разрезе подразделений. Данные по месяцам позволят оценивать управляемость процессом выдачи ПК. При наличии оборудования может быть передано около 30 подготовленных ПК. Ожидается, что это значение в течение года не будет значительно меняться. Распределение потребности в оборудовании по подразделениям может использоваться при определении рабочих мест, на которые будет выдано новое оборудование.

Также на макете размещены блоки с информацией о количестве оборудования в ИТ-инфраструктуре: 2365 ПК, 54 сервера и так далее.

Рис. 5. Макет главной страницы

Помимо графического отображения информации предусмотрено табличное представление данных и отчетов. Формирование отчетов проводиться в соответствии с выбранными фильтрами.

Для уменьшения ошибок, связанных с человеческим фактором, ввод данных для большинства полей форм организован на основе справочников и данных из связанных таблиц БД с использованием автоматических подсказок. Пример макета формы ввода данных представлен на рис. 6.

Рис. 6. Экранная форма ввода данных

Важной составляющей обеспечения корректности данных является валидация форм. Для этого используются встроенные в Django механизмы проверки правильности введённых данных и созданы собственные правила валидации. Например, комплексные проверки, связанные одновременно с несколькими полями, позволяют не только предотвратить ошибочный ввод данных, но и обеспечить их соответствие заданным бизнес-правилам.

Проверка технических характеристик программного кода

Django предоставляет фреймворк для создания тестов. Фреймворк построен на основе иерархии классов, которые, в свою очередь, зависят от стандартной библиотеки Python unittest. Несмотря на название, данный фреймворк подходит и для юнит-тестирования, и для интеграционного тестирования. Фреймворк Django добавляет методы API и инструменты, которые помогают тестировать как веб, так и специфическое для Django поведение. Это позволило имитировать URL-запросы, добавлять тестовые данные, а также проводить проверку выходных данных приложения. Для проведения тестов в БД создаются тестовые таблицы, которые после завершения тестирования удаляются.

Результаты юнит тестов, которые проверяли корректность работы форм и передачи данных в БД, показали, что время выполнения 6 тестов составляет 0,137 с и 7 тестов — 0,832 с.

В результате интеграционного тестирования проверялись общие технические характеристики системы: доступность информации для авторизованного пользователя; проверка ограничения доступа для не авторизованного пользователя; проверка записи данных в БД, отправленных через формы; проверка редактирования данных в БД посредством запросов через форму.

Проиллюстрируем часть программного кода теста, написанного для проверки работы с БД через HTTP запросы.

Создаем тестовые данные и данные для авторизации в системе:

Также были написаны программные коды для тестирования доступности списка оборудования для авторизованного пользователя, проверки доступности детальной информации авторизованного пользователя, получения ошибки 404 для несуществующей страницы,

Проверка получения шаблона формы проводилась следующим образом:

Далее выполнялась проверка отправки данных в форму.

Приведём часть кода, осуществляющую проверку работы с формой редактирования записи:

Также проверяется доступ для неавторизованных пользователей:

В интеграционном тестировании проверяются все страницы прототипа системы. Запуск всех тестов производился командой: python manage.py tests. Для запуска отдельного теста в качестве опций необходимо указать название его скрипта.

При проведении интеграционного тестирования система создала тестовую базу данных «test database» и определила её как используемую по умолчанию для тестов.

Все 28 тестов, идентифицированных системой, прошли успешно: «no issues / 0 silenced». Время прохождения 28 тестов составило 6,529 секунд.

Рис. 7. результаты тестирования

В рамках стресс-тестирования система подвергалась нагрузкам, превышающим обычные эксплуатационные параметры, что позволило оценить её устойчивость и стабильность при экстремальных условиях эксплуатации. Среднее количество запросов, обрабатываемых в секунду, составляет 14. После выхода на рабочий режим RPS (Requests Pro Second) колеблется в полосе от 12 до 15 запросов в секунду. Количество ошибок — 0.

Описание технического параметра «Время отклика системы», определяемого в стресс- тестировании, было проведено для 5 %-го уровня значимости. Верхнее значение 95 %-доверительного интервала достигало 520 мс, что неплохо согласовывалось со средним значением «агрегированного» запроса, составляющего 380 мс.

Результаты тестирования показали, что разработанная система успешно прошла все этапы проверки: большинство ошибок было выявлено и устранено на ранних стадиях, а система продемонстрировала стабильную работу под высокой нагрузкой. По итогам тестирования можно сделать вывод, что прототип системы соответствует требованиям, изложенным в техническом задании (ТЗ), и выполняет все заявленные функции.

Заключение

Ожидается, что разрабатываемая система поддержки принятия решений значительно сократит время, затрачиваемое на обработку и анализ данных, что повысит оперативность реагирования на возникающие ситуации. Кроме того, автоматизация процессов снизит вероятность ошибок, связанных с человеческим фактором при вводе и обработке информации. Важной особенностью созданной автоматизированной системы является возможность апробации новых методов оценки её работы, что позволит постоянно совершенствовать автоматизированные процессы и повышать качество предоставляемых ИТ услуг. В целом, внедрение данной системы обеспечит более эффективное управление ИТ-инфраструктурой на предприятии за счет повышения удобства использования, гибкости настроек и расширяемости решений.

Литература:

1. Сергеев М. К. Системы поддержки принятия решений // Актуальные исследования. 2023. № 24 (154). Ч. I. С. 65–71. URL: https://apni.ru/article/6492-sistemi-podderzhki-prinyatiya-reshenij
2. Прокопенко Н. Ю. Системы поддержки принятия решений [Электронный ресурс]: учеб. пособие /Н. Ю. Прокопенко; Нижегор. гос. архитектур.-строит. ун-т. — Н. Новгород: ННГАСУ, 2017. — 188 с.
3. Спицина И. А. Метод поддержки принятия решений при разработке информационных систем на основе мультиагентного подхода: монография / И. А. Спицина, К. А. Аксенов; Министерство науки и высшего образования Российской Федерации ФГАОУ ВО «Уральский федеральный университет имени первого Президента России Б. Н. Ельцина»; ФГБОУ ВО «Уральский государственный педагогический университет». — Екатеринбург: УрГПУ, 2018. — 156 с. — ISBN 978–5–7186–1078–9.
4. Разработка и применение методов и программных средств поддержки принятия решений на основе интеграции имитационного, мультиагентного, эволюционного моделирования и численных методов решения задач оптимизации: заключительный отчет о НИР / Урал. федер. ун-т им. первого Президента России Б. Н. Ельцина; Руководитель К. А. Аксенов; Исполнитель А. С. Антонова. — Екатеринбург, 2013. — 27 с.
5. Stephany GarcíaOscar RomeroRuth Raventós DSS from an RE Perspective: A systematic mapping Journal of Systems and Software Volume 117, July 2016, Pages 488–507 DSS
6. Технологии поддержки принятия решений в системе NERPA // novosoft URL: https://www.novosoft.ru/nerpa/dss (дата обращения: 21.05.2024).
7. Система проектирования прикладных решений // 1С:Предприятие URL: https://solutions.1c.ru/catalog/model/features (дата обращения: 21.05.2024).
8. СППР «ИГЛА» // tu-bryansk.ru URL: http://iipo.tu-bryansk.ru/quill/index.html (дата обращения: 21.05.2025).
9. Loginom — аналитическая low-code платформа // loginom URL: https://loginom.ru/platform (дата обращения: 21.05.2025).
10. Система поддержки принятия решений «Выбор» // ЦИРИТАС URL: http://www.ciritas.ru/product.php?id=10#39 (дата обращения: 21.05.2024).
11. Программный продукт Аналитика // Интеград URL: https://www.integrad.ru/analitic.htm (дата обращения: 21.05.2025).
12. Российская BI-система Analytic Workspace (AW BI) // Analytic Workspace URL: https://analyticworkspace.ru (дата обращения: 21.05.2025).
13. Российская корпоративная Business Intelligence платформа № 1 // VISIOLOGY URL: https://ru.visiology.su (дата обращения: 21.05.2025).
14. Almaz BI удобная система анализа и визуализации данных // Almaz BI URL: https://inleksys.ru/almaz-bi/ (дата обращения: 21.05.2024).
15. Лабабиди М. Р. Система поддержки принятия решений (СППР) как инструмент принятия эффективных управленческих решений на промышленных предприятиях / М. Р. Лабабиди, Н. Р. Кельчевская. — Текст: электронный // Весенние дни науки: сборник докладов Международной конференции студентов и молодых ученых (Екатеринбург, 21–23 апреля 2022 г.). — Екатеринбург: УрФУ, 2022. — C. 377–381.
16. Дронов В. А. Django: практика создания Web-сайтов на Python. — СПб.: БХВ-Петербург, 2016. — 528с.: ил.
17. Меле А. Django 4 в примерах / пер. с англ. А. В. Логунова. — М.: ДМК Пресс, 2023. — 800 с.: ил. ISBN 978–5–93700–204–4
18. Django // Википедия URL: https://ru.wikipedia.org/wiki/Django (дата обращения: 21.05.2025).