Конфликт между IT-департаментом и службой главного инженера при внедрении IIoT приводит к затягиванию сроков ввода в эксплуатацию на 4–8 месяцев и увеличению бюджета проекта на 20–30% из-за переделок архитектуры. Основная проблема заключается в столкновении парадигмы IT (конфиденциальность и целостность данных) с парадигмой OT (доступность и непрерывность технологического процесса).
Точки конфликта: доступность против безопасности
Главный инженер (OT) требует мгновенного доступа к данным с датчиков и ПЛК для оперативного управления, тогда как IT-директор настаивает на многоуровневой аутентификации и строгой сегментации. В реальности попытка внедрить стандартные корпоративные политики безопасности (например, принудительную смену паролей каждые 90 дней или автоматическую блокировку сессий) на промышленных HMI-панелях приводит к остановке мониторинга цеха в критические моменты.
Кейс: на одном из заводов по производству полимеров внедрение стандартного антивирусного ПО на инженерных станциях вызвало задержку обновления данных в SCADA-системе на 2–5 секунд, что привело к срабатыванию аварийного останова. Убытки от одного такого простоя составляют от 500 000 до 2 000 000 рублей в зависимости от объема партии.
Экспертный вывод: Безопасность в IIoT не может быть копией офисной. Приоритетом должна быть доступность (Availability), а затем уже целостность (Integrity) и конфиденциальность (Confidentiality), что прямо противоположно классическому IT-треугольнику CIA.
Разграничение зон ответственности по модели Purdue
Для устранения конфликтов необходимо внедрение модели Purdue, которая четко разделяет уровни производства. Уровни 0–2 (датчики, контроллеры, локальные панели) остаются в полном ведении главного инженера, уровни 3–4 (MES, ERP, серверы сбора данных) — в совместном управлении с IT. Границей ответственности становится DMZ (демилитаризованная зона) между промышленной сетью (OT) и корпоративной (IT).
Технический регламент должен фиксировать: IT-департамент отвечает за инфраструктуру передачи данных и защиту периметра, а служба главного инженера — за работоспособность конечных устройств и корректность передаваемых тегов. Это исключает ситуацию, когда IT-специалист обновляет прошивку коммутатора в разгар смены, вызывая потерю связи с контроллером.
Экспертный вывод: Единственный способ избежать саботажа со стороны производства — передать им полный контроль над L0-L2, ограничив влияние IT-службы уровнем сетевого шлюза и политиками маршрутизации.
Регламент управления изменениями и обновлениями
Основной риск при развертывании единой сети данных — несанкционированное обновление ПО. В IT принято обновлять системы «по мере выхода патчей», в промышленности любое изменение конфигурации требует верификации. Ошибки при обновлении прошивок ПЛК или сетевых мостов могут привести к простою линии стоимостью от 100 000 до 1 000 000 рублей в час.
Оптимальный регламент включает создание «зеркального» тестового стенда (Digital Twin или физический макет), где изменения проверяются в течение 2–5 рабочих дней перед раскаткой на производство. Согласование окна обновления происходит через запрос в службу главного инженера, который подтверждает период минимальной нагрузки на оборудование.
Экспертный вывод: Любое обновление в промышленном сегменте должно проходить через процедуру Change Management, где финальное слово остается за технологом/инженером, а не за системным администратором.
Экономика взаимодействия и KPI обеих служб
Конфликты часто растут из разных KPI: IT оценивается по аптайму серверов и отсутствию инцидентов ИБ, а главный инженер — по объему выпуска продукции и снижению OPEX. Для синхронизации необходимо внедрить общие метрики эффективности. Например, внедрение комплексной архитектуры построения экосистемы от физического уровня до бизнес-аналитики должно оцениваться через сокращение времени реакции на сбой (MTTR) и повышение OEE (общей эффективности оборудования).
Пример: переход на единую сеть данных при правильном взаимодействии снижает затраты на поддержку разрозненных сетей на 15–25% в год. При этом стоимость лицензий на промышленные шлюзы с поддержкой MQTT/OPC UA варьируется от 500 до 3 000 долларов за единицу, что окупается за 6–12 месяцев за счет автоматизации сбора данных.
Экспертный вывод: Чтобы проект IIoT не стал «игрушкой» IT-отдела, его успех должен быть привязан к производственным показателям, а не к техническому совершенству сети.
Вывод
Для успешного развертывания IIoT следует отказаться от попыток «поглощения» производства IT-департаментом. Рекомендую начать с внедрения жесткой сегментации по модели Purdue и создания совместного комитета по изменениям (Change Control Board), где голос главного инженера имеет приоритет в вопросах доступности системы. Избегайте внедрения стандартных корпоративных средств защиты (EDR/AV) непосредственно на контроллерах и HMI — используйте промышленные межсетевые экраны и системы обнаружения вторжений (IDS) на уровне анализа трафика. Только такой баланс обеспечит стабильность техпроцесса при соблюдении норм кибербезопасности.
Подробный разбор всей темы смотрите в обзоре Искусственный интеллект в работе: от автоматизации.