Вводная часть

Четвёртая промышленная революция предполагает не точечную автоматизацию отдельных участков производства, а сквозную интеграцию данных на всех уровнях управления предприятием — от датчиков технологического оборудования до систем стратегического планирования. Одним из наиболее распространённых препятствий на этом пути остаётся разрыв между SCADA-системами, обслуживающими операционный (технологический) контур, и корпоративными информационными системами (КИС/ERP), обслуживающими контур управления предприятием. На практике этот разрыв закрывается вручную: диспетчеры и специалисты учёта переносят данные между системами путём выгрузок, отчётов и ручного ввода, что порождает задержки, ошибки и дублирование труда.

Актуальность настоящего этапа исследования обусловлена тем, что при очевидной практической значимости задачи интеграции SCADA и КИС в открытом доступе преобладают работы, описывающие эту интеграцию на уровне архитектурных принципов (в частности, стандарта ISA-95) или отдельных технологических решений, но не показывающие воспроизводимую технологию перехода от анализа конкретного бизнес-процесса предприятия к формализованным требованиям на программный продукт. Практическая значимость работы состоит в том, что предложенная технология доводится до уровня, пригодного для непосредственного использования проектной командой: от диагностики процесса до готовых вариантов использования и плана внедрения с измеримыми показателями.

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

Для достижения цели решались следующие задачи:

— построить и проанализировать модель бизнес-процесса «как есть», выявить его функциональные ограничения;

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

— спроектировать целевую модель процесса «как будет» и его информационную структуру;

— дать количественную оценку ожидаемого эффекта методами бережливого производства;

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

— сформировать план практического внедрения с измеримыми показателями и обоснование решения, пригодное для совместного обсуждения заинтересованными сторонами.

Основная часть

1. Технология преобразования модели процесса в программное решение

Основным собственным результатом данного этапа является не единичная модель, а воспроизводимая технология — последовательность из шести этапов, каждый из которых использует отдельную, но согласованную с остальными нотацию моделирования и производит артефакт, необходимый для следующего этапа (табл. 1). Ключевой принцип технологии: на этапе формализации требований (этап 5) каждая задача самого детального уровня декомпозиции процесса, зафиксированная на предыдущих этапах, сопоставляется ровно одному варианту использования будущего программного продукта. Это обеспечивает полную прослеживаемость: любой элемент требований к программному обеспечению может быть возведён к конкретной задаче бизнес-процесса и, через неё, к стратегической цели предприятия, а не введён произвольно.

Таблица 1

Технология преобразования модели бизнес-процесса в требования к программному решению

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

2. Диагностика текущего состояния бизнес-процесса

Анализ методом IDEF0 показал, что в модели «как есть» функции мониторинга оборудования и обработки аварийных сигналов автоматизированы удовлетворительно, тогда как формирование отчётности и ввод данных в КИС выполняются вручную. Ключевым ограничением процесса является связь между этими группами функций: сводные данные передаются из технологического контура в контур управления предприятием периодически (по итогам смены) и вручную, что порождает задержку, риск искажения данных и дублирование труда.

3. Целевая модель процесса и его информационная структура

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

4. Количественная оценка эффекта

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

Таблица 2

Ключевые показатели процесса до и после предлагаемого решения

Рис. 1. Сопоставление ключевых показателей процесса до и после решения

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

5. От процесса к программному продукту: варианты использования

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

6. Практические рекомендации по внедрению

Практическая реализация технологии оформлена в виде плана мероприятий с указанием ответственных и сроков на горизонте одного года, включающего этапы проектирования, разработки, пилотного внедрения, тиражирования и оценки результатов. Обоснование решения дополнительно формализовано в виде модели мотивации бизнеса (Business Motivation Model), связывающей каждое мероприятие плана со стратегической целью предприятия, а риски, связанные с восприятием изменений персоналом, проанализированы с помощью карты пути клиента, построенной от лица оператора SCADA — сотрудника, чья повседневная работа меняется сильнее всего. Наибольший эмоциональный риск сосредоточен не на этапе объявления проекта, а на этапе первого практического использования платформы, что определяет необходимость быстрой технической поддержки именно на этом этапе.

Заключительная часть

Проведённый этап исследования позволяет сформулировать следующие выводы. Во-первых, разработана и апробирована воспроизводимая технология преобразования теоретической модели бизнес-процесса в требования к программному решению, состоящая из шести согласованных этапов моделирования и обеспечивающая полную прослеживаемость от стратегической цели предприятия до конкретного варианта использования программного продукта. Во-вторых, применение этой технологии к задаче интеграции SCADA и КИС позволило не только качественно, но и количественно обосновать ожидаемый эффект: сокращение времени выполнения процесса примерно в 18 раз и рост эффективности потока создания ценности с ≈9,8 % до целевых ≥70 %.

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

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

Литература:

1. ГОСТ Р 7.0.5–2008. Библиографическая ссылка. Общие требования и правила составления. — Введ. 2009–01–01. — М.: Стандартинформ, 2008. — 23 с.
2. Business Motivation Model (BMM), Version 1.3: OMG Document Number formal/15–05–19. — Needham, MA: Object Management Group, 2015. — URL: https://www.omg.org/spec/BMM/1.3/PDF (дата обращения: 23.08.2026).
3. Business Process Model and Notation (BPMN), Version 2.0.2: OMG Document Number formal/2013–12–09. — Needham, MA: Object Management Group, 2013. — URL: https://www.omg.org/spec/BPMN/2.0.2/PDF (дата обращения: 23.08.2026).
4. Integration Definition for Function Modeling (IDEF0): FIPS PUB 183. — Gaithersburg, MD: National Institute of Standards and Technology, 1993. — 116 p. — DOI: 10.6028/NIST.FIPS.183.
5. Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach / I. Jacobson, M. Christerson, P. Jonsson, G. Övergaard. — Boston, MA: Addison-Wesley, ACM Press, 1992. — 524 p.
6. Lemon, K. N. Understanding Customer Experience throughout the Customer Journey / K. N. Lemon, P. C. Verhoef // Journal of Marketing. — 2016. — Vol. 80, No. 6. — P. 69–96. — DOI: 10.1509/jm.15.0420.
7. Rother, M. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda / M. Rother, J. Shook. — Brookline, MA: Lean Enterprise Institute, 1999. — 102 p.
8. Tabim, V. M. Implementing Manufacturing Execution Systems (MES) for Industry 4.0: Overcoming buyer-provider information asymmetries through knowledge sharing dynamics / V. M. Tabim, N. F. Ayala, G. A. Marodin, G. B. Benitez, A. G. Frank // Computers & Industrial Engineering. — 2024. — Vol. 196. — Art. 110483. — DOI: 10.1016/j.cie.2024.110483.