1. Введение

Конкурентоспособность современного металлургического предприятия напрямую зависит от его способности обеспечивать стабильно высокое качество продукции при постоянном снижении издержек. ПАО «Северсталь», являясь одним из лидеров отрасли, сталкивается с рядом вызовов: рост требований клиентов, ужесточение конкурентной среды, необходимость снижения внутренних затрат в условиях опережающего роста себестоимости. Несмотря на наличие сертифицированной системы менеджмента качества (СМК) и положительную динамику внешних оценок, анализ внутренних метрик выявил парадокс: улучшение контроля качества привело к росту объема внутренней отсортировки (брак и несоответствующая продукция), что свидетельствует о недостаточной эффективности процесса постоянного совершенствования и работы с первопричинами дефектов [1, 2, 3].

Проблематика заключается в следующем:

— Неэффективное использование ресурсов: Сотрудники тратят до 80 % времени на рутинные задачи (сбор данных, первичная проверка гипотез), а не на творческий анализ и поиск системных решений.

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

— Утрата специфических знаний: Решения проблем часто не документируются, что препятствует накоплению и повторному использованию опыта.

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

2. Методологическая основа системного инжиниринга

Системный инжиниринг — это междисциплинарный подход и методология, направленные на создание и валидацию сложных систем, которые на протяжении всего жизненного цикла удовлетворяют потребностям заказчика и всех стейкхолдеров [4]. Его применение к разработке программного обеспечения, особенно в сложной предметной области, такой как металлургия, позволяет управлять сложностью, минимизировать риски и обеспечивать соответствие системы реальным бизнес-потребностям [5, 6].

В основе работы лежал рамочный алгоритм применения методического инструментария СИ, включающий пять ключевых этапов:

— Структурирование требований к системе.

— Разработка функциональной архитектуры.

— Анализ альтернативных решений.

— Интеграция инструментов СИ (QFD, FMEA, V-модель).

— Разработка методов верификации и валидации.

Для реализации каждого этапа использовался набор конкретных инструментов:

— Для работы с требованиями: Метод анализа иерархий (AHP), интервью, анкетирование, язык моделирования SysML для формализации.

— Для проектирования: Функциональное моделирование (деревья функций), «Дом качества» (QFD — Quality Function Deployment)

— Для анализа и выбора решений: Многокритериальный анализ, метод Гермейера, анализ рисков (FMEA — Failure Mode and Effects Analysis).

— Для управления разработкой и качеством: V-модель, WBS (Work Breakdown Structure), планирование верификации и валидации.

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

3. Анализ и структурирование требований

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

В ходе командных сессий и мозговых штурмов был сформирован исходный перечень из 16 ключевых требований. Среди них:

Для пользователей: Автоматизация рутинных разборов, ИТ-среда для работы с инцидентами и рабочими группами, инструмент для выгрузки и анализа данных без навыков программирования, ИИ-помощник («Чат-Технолог») для генерации гипотез.

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

Для обработки этого массива разнородных требований был применен метод анализа иерархий (AHP). Путем попарного сравнения требований внутри групп «Пользователи» и «Заказчик» были получены нормализованные веса их важности. Наивысший приоритет у пользователей получили «Автоматический разбор инцидента» (0,30) и «Выгрузка и анализ данных» (0,25). Для заказчика наиболее критичными оказались «Идентификация инцидента» (0,24) и «Автоматический разбор инцидента» (0,19).

Далее для установления корреляций между потребностями пользователей и техническими требованиями заказчика был построен «Дом качества» (HoQ) в его усовершенствованной форме (уДК). Анализ матриц взаимосвязей подтвердил высокую значимость требований к автоматизированной идентификации и разбору инцидентов, что стало ключевым драйвером при проектировании архитектуры системы. Этот шаг позволил трансформировать часто субъективные пожелания стейкхолдеров в объективные, измеримые и приоритизированные технические характеристики системы.

4. Проектирование функциональной и физической архитектуры системы

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

Идентификация инцидента:

— Функция автоматического выявления отклонений (снижение CPK, рост нарушений).

— Функция мониторинга состояния критичного оборудования.

— Функция ручного создания инцидента пользователем.

Распределение и первичный разбор:

— Функция назначения ответственных и оповещения.

— Функция автоматического проведения шаблонных разборов (проверка известных гипотез).

— Функция фиксации результатов разбора.

Системное решение проблемы (Рабочие группы):

— Функция объединения инцидентов в рабочие группы (РГ).

— Функция назначения лидера РГ, постановки целей и контроля этапов.

— Функция создания и контроля исполнения корректирующих мероприятий.

Аналитическая поддержка:

— Функция выгрузки данных из производственных систем (MES, АСУ ТП).

— Функция статистического и регрессионного анализа данных.

— Функция доступа к ИИ-помощнику («Чат-Технолог»).

Воздействие:

— Функция автоматического внесения изменений в смежные ИТ-системы (SAP, MES) по заданным сценариям.

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

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

Технологический стек: Бэкенд на C# с API для интеграции, фронтенд на React, СУБД PostgreSQL. Для модулей анализа данных и ИИ используется Python.

Инфраструктура: Для пилотной эксплуатации в одном цехе запланированы серверные мощности: 60 CPU ядер, 176 ГБ ОЗУ, 1,39 ТБ HDD.

Интеграция: Система будет взаимодействовать с внешним контуром предприятия: SAP ERP, MES, АСУ Аттестация, АСУ Технология, витрины данных.

Выбор технологического стека для реализации системып роводился методом Гермейера включая анализ рисков (FMEA). Рассматривались несколько архитектурных альтернатив, удовлетворяющих функциональным требованиям.

Критерии выбора включали:

— Функциональное соответствие — способность технологии обеспечить выполнение ключевых функций системы (идентификация инцидентов, автоматические разборы, аналитика).

— Интеграционный потенциал — совместимость с существующей ИТ-инфраструктурой предприятия.

— Рыночная зрелость — доступность подрядчиков и готовых решений на рынке.

— Внутренние компетенции — наличие экспертизы у персонала предприятия для поддержки и развития системы.

— Снижение рисков — минимизация вероятности и последствий отказов, простота обнаружения проблем.

Результаты анализа показали:

Для фронтенд-разработки оптимальным решением стал React как отраслевой стандарт для создания сложных веб-интерфейсов с богатой экосистемой компонентов.

Для бэкенд-разработки выбор между Java и C# был сделан в пользу C# на основе комплексной оценки. Критическими факторами стали:

— Глубокая интеграция с существующей ИТ-инфраструктурой предприятия, в значительной степени построенной на технологиях Microsoft

— Наличие внутренних компетенций по поддержке.NET-решений, что снижало операционные риски

— Рыночная доступность квалифицированных подрядчиков для разработки на C#

Для модулей аналитики и ИИ был выбран Python благодаря безальтернативной экосистеме библиотек для машинного обучения и анализа данных (Pandas, Scikit-learn, PyTorch).

5. Разработка графика реализации

Для управления сложностью и минимизации рисков внедрения был разработан иерархический план проекта (WBS) и поэтапный график реализации, основанный на принципах V-модели.

Этапы реализации:

— Проектирование: Структурирование требований, разработка функциональной и физической архитектуры.

— Разработка: Создание ядра системы и ключевых модулей (работа с инцидентами, РГ, мероприятиями, аналитика).

— Настройка: Конфигурирование правил генерации инцидентов, шаблонов авто-разборов, справочников (дефекты, параметры, оборудование).

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

— Масштабирование: внедрение решения по всем цехам предприятия и доработка функционала до целевой версии.

6. Верификация и валидация системы

Заключительный этап проектирования в рамках СИ — планирование процедур верификации (проверка «строим ли систему правильно?») и валидации (проверка «строим ли правильную систему?»). Для АСУИК был разработан детальный план, включающий конкретные метрики и методы проверки.

Верификация была нацелена на проверку соответствия системы техническим требованиям и внутренним стандартам. Были определены ключевые критерии, часть из которых представлена в Таблице 1.

Таблица 1

Фрагмент плана верификации АСУИК

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

— Согласование бизнес-требований: Формальное подтверждение целей системы с заказчиком (метод: инспекция).

— Демо-дни: Оценка макетов интерфейса и пользовательских сценариев ключевыми пользователями (метод: демонстрация).

— Внутреннее тестирование: Совместная проверка системы проектной командой и пользователями на тестовом стенде (методы: демонстрация, испытания).

— Опытно-промышленная эксплуатация (ОПЭ): Работа системы в реальных условиях пилотного цеха для выявления критичных и некритичных замечаний перед полномасштабным внедрением.

Ключевыми критериями валидации стали: снижение времени на разбор инцидента, повышение удовлетворенности пользователей, достижение целевых показателей по снижению потерь (брак -27 %, рекламации -14 %).

7. Заключение

Проведенная работа служит наглядным практическим примером эффективности методологии системного инжиниринга для создания сложных программно-аппаратных комплексов в реальном промышленном секторе. Последовательное применение инструментов СИ (AHP, QFD, SysML, FMEA) позволило трансформировать изначально разрозненные и субъективные пожелания в стройный, обоснованный и реализуемый проект.

Наиболее значимым практическим результатом применения методологии системного инжиниринга стало кардинальное ускорение процесса создания системы. Благодаря использованию данного инструментария удалось не просто разработать концепцию, а реализовать работоспособный MVP (Minimum Viable Product) системы всего за 1 год с момента выделения финансирования. Данный результат важен на фоне предыдущего опыта предприятия, когда на разработку и пилотное внедрение схожих по сложности систем уходило от 2 до 3 лет, причем зачастую без достижения изначально запланированных экономических результатов.

Уже на этапе пилотной эксплуатации в одном цехе была продемонстрирована реальная эффективность системы: достигнуто снижение внутренних потерь на 7 %. Этот показатель, хотя и является промежуточным по отношению к стратегической цели в 27 %, служит важным доказательством верности выбранного подхода и позволяет с уверенностью прогнозировать достижение полного экономического эффекта при масштабировании системы.

Ключевые результаты:

Операционный прорыв: Сокращение цикла разработки в 2–3 раза и достижение измеримого экономического эффекта на этапе MVP.

Для бизнеса: Разработана и апробирована система, не имеющая прямых аналогов на рынке, внедрение которой позволяет достичь значительного экономического эффекта.

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

Для организации: Заложена основа для фундаментального улучшения процесса непрерывного совершенствования и подтверждена стратегическая ценность системного подхода к цифровой трансформации.

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

Литература:

1. Внутренние отчеты ПАО «Северсталь» по качеству за 2019–2025 гг.

2. Стратегия ПАО «Северсталь» в области качества и цифровизации.

3. ГОСТ Р ИСО 9001–2015. Системы менеджмента качества. Требования.

4. Романов А. А. Прикладной системный инжиниринг: на пути к цифровому инжинирингу. 2025.

5. Chakraborty, S., Prasad, K. A QFD-based expert system for industrial truck selection in manufacturing organizations. Journal of Manufacturing Technology Management, 2016.

6. Idilia Batchkova, Iskra Antonova. Improving the software development life cycle in process control using UML/SysML. Preprints of the 18th IFAC World Congress, 2011.