Инженерия ПО в Manufacturing: Agile встречает железо
Крупный автопоставщик, с которым я консультировал в 2024, получил production-баг во вторник в 03:15. Фикс написали за 8 минут и выкатывали 19 дней — потому что требовался софт-апдейт PLC на 14 производственных ячейках, каждую из которых можно было обновить только в 4-минутное окно между сменами. Средний lead time инженерной команды на офисной IT-стороне — 31 час. На shop-floor-стороне — 14 дней. Та же команда, тот же репозиторий, две разные вселенные constraint'ов delivery.
Manufacturing software engineering — это Agile, столкнувшийся с железом. Практики, работающие в SaaS-стартапе — deploy-whenever, feature flags, canary-релизы — сталкиваются с регулируемой реальностью plant floor: цели OEE, стоимость changeover, разделение OT/IT и production-линии, которые нельзя остановить ради деплоя. Исследование Deloitte Smart Factory 2023 обнаружило, что 73% производителей называют «интеграцию IT/OT» главным барьером цифровизации. Дело не в технологии — дело в том, что метрики и ритуалы, придуманные для чистого софта, ломаются, когда софт касается физического процесса.
{/* truncate */}
Почему инженерия в manufacturing другая
Manufacturing-софт охватывает четыре слоя, каждый со своей моделью деплоя, режимом отказа и реальностью измерения:
Четырёхслойный manufacturing-стек. Два нижних слоя накладывают ограничения на два верхних так, как чистые SaaS-команды редко предвидят.
| Слой | Типичная технология | Cadence деплоя | Blast radius |
|---|---|---|---|
| Shop floor (PLC / SCADA) | Rockwell, Siemens, Codesys | Недели — месяцы | Остановка линии, брак, безопасность |
| MES (execution) | GE Proficy, Siemens Opcenter, custom | Дни — недели | Разрывы traceability, задержки смен |
| ERP-интеграция | SAP, Oracle, custom middleware | Неделя — месяц | Ошибки биллинга, лаг отчётности |
| Analytics / BI | Snowflake, дашборды, custom | Ежедневно (офис IT) | Косметика до задержки решения |
Верхние слои выглядят как SaaS. Нижние — как аэрокосмос. Dev-команда живёт во всех четырёх.
Метрики, которые здесь важны
1. Lead time, разрезанный по слоям
DORA lead time сжимает полезный сигнал в manufacturing. 4-часовая медиана по команде маскирует 2-часовой MES-lead и 14-дневный PLC-lead. Разрезайте их — или спрячете настоящее узкое место.
| Слой | Реалистичный lead-time | Elite-диапазон |
|---|---|---|
| Analytics / BI | 2-24 ч | < 2 ч |
| ERP-интеграция | 1-7 дн | < 1 дн |
| MES | 3-14 дн | 1-3 дн |
| Shop floor / PLC | 7-60 дн | 3-7 дн |
Статья IEEE 2022 по моделям delivery в Industry 4.0 подтвердила бимодальное распределение: команды, шипящие в оба слоя, имеют 2 пика lead time, а не один.
2. Change failure rate, взвешенный по production-импакту
Фейл в BI-дашборде стоит инженеру полдня. Фейл в MES — срывает отгрузки. Change failure rate нужно взвешивать по blast radius — иначе он пропустит рискованный PLC-change, потому что «фикс дашборда сработал».
Схема весов, которую мы видели рабочей:
- Analytics / BI-фейл = 1x
- ERP-интеграция-фейл = 3x
- MES-фейл = 10x
- Shop-floor-фейл = 50x (потенциальная остановка + rework + брак)
Команды, отслеживающие взвешенный CFR, расставляют тестовые инвестиции на слои, которые бьют.
3. OEE-aware deployment windows
OEE (Overall Equipment Effectiveness) — священная метрика shop floor. Это произведение Availability × Performance × Quality, фабрики целятся в 85%+ («world-class»). Любой софт-деплой, не вытягивающий 85% OEE на пост-change-линии, считается failed независимо от того, что говорит CI.
Это меняет инженерный вопрос с «деплой прошёл?» на «деплой деградировал OEE?» — и ответить может только интеграция с production-данными.
Как manufacturing-ограничения меняют playbook
Deployment-окна — результат переговоров, а не инженерного решения
В SaaS-платформе инженерия выбирает, когда деплоить. На shop floor инженерия получает окно от plant operations:
- Changeover смены (обычно 5-15 мин каждые 8 часов)
- Плановое обслуживание (еженедельно, 2-4 часа)
- Квартальный shutdown (единственное окно для крупных изменений)
Это значит, deploy-автоматизация — не про «пушим в прод когда угодно», а про подготовку изменений так, чтобы они помещались в предварительно согласованное окно без человеческого bottleneck. Команды, пропускающие это, до сих пор делают ручные deploy PR, подписанные plant-менеджерами в 14:00 в пятницу.
Минимум две Git-ветки
Manufacturing-команды, с которыми я работал, приходили к двух-branch-модели:
office-it/*ветки — cloud/SaaS-pipeline, деплой много раз в деньot/*ветки — батчи, гейт через plant-floor review, медленнее cadence
Попытка пропустить все изменения через один pipeline замедляет офисную cadence до OT-скорости. Разделение даёт каждому слою двигаться в своём ритме.
Feature flags работают по-разному на shop floor
Нельзя feature-flag'нуть PLC ladder-logic change. Можно — MES UI, analytics-слой и ERP-middleware. Команда должна явно знать, какие слои поддерживают флаги, а какие нет — иначе инженеры тратят усилия на SaaS-паттерны в embedded-коде.
Типовой паттерн: 40-инженерная manufacturing-команда
Из паттернов 6 customer-команд в automotive, food-processing и промышленном оборудовании:
- 12 инженеров на офисном IT / analytics-слое — web-стек, стандартный CI/CD, DevOps-практики
- 16 инженеров распределены на MES и ERP-интеграции — Java/.NET-heavy, медленнее cadence, сильнее интеграционные тесты
- 8 инженеров на shop-floor-софте — PLC/SCADA-специалисты, глубокое знание железа, тестовые циклы на недели
- 4 инженера на cross-cutting platform / infra — CI, data-pipeline, безопасность
Четыре популяции не смотрят одни и те же дашборды. Единый «team velocity» на все 40 маскирует реальное здоровье каждой подкоманды. Мы видели эту ловушку: руководство ставит OKR «deploy frequency +20%», офисная IT-команда перевыполняет, MES-команда перенапрягается, shop-floor-инженеры теряют мотивацию.
Какие метрики отслеживать (и не смешивать)
| Метрика | Офис IT | MES | ERP | Shop floor |
|---|---|---|---|---|
| Deploy frequency | Ежедневно | Еженедельно | Еженедельно | Ежемесячно |
| Lead time | < 24 ч | 1-5 дн | 3-7 дн | 7-30 дн |
| Change failure rate | 5-15% | 5-10% | 3-8% | < 2% (стоимость остановки линии) |
| MTTR | < 1 ч | < 4 ч | < 8 ч | Часы — дни |
| Focus time (IDE heartbeat) | 1-2 ч/д | 1.5-2.5 ч/д | 1-2 ч/д | < 1 ч/д (много workshop) |
Числа IDE heartbeat — самое удивительное. Shop-floor-инженеры проводят меньше времени в редакторе, потому что 40-50% их работы — workshop, дебаг и on-site plant. Наши данные по manufacturing-customer'ам подтверждают этот паттерн. Судить shop-floor-инженеров по SaaS-бенчмаркам IDE-time — значит misrank'нуть ваши сильнейшие hardware-software-мозги.
Где вписывается PanDev Metrics
PanDev Metrics автоматически собирает IDE heartbeat и Git-события во всех четырёх слоях. Для manufacturing-команд хорошо работает маркировка репозиториев по слою (мы поддерживаем per-project labels) и сегментированные дашборды — lead-time для office-IT, для MES, для shop-floor — вместо единого усреднённого числа, не говорящего ничего.
Один клиент в automotive tier-1 supply обнаружил реальное узкое место shop-floor именно так: очередь code review, где 6 инженеров ждали одного domain-эксперта с медианой ревью PR 4,3 дня. Видно, когда сегментировано. Невидимо в смешанном view.
Типичные ошибки
- Применение SaaS-порогов DORA к shop-floor-коду. 60-дневный lead time на PLC ladder logic — не провал, а физика plant-floor change control.
- Один Grafana-дашборд на всю команду. Office-IT green прячет shop-floor red. Сегментируйте или слепните.
- Найм только дженералистов. Manufacturing-софту нужны глубоко-доменные спецы. 5-инженерная shop-floor-подкоманда с 12-летним опытом PLC обыгрывает 15-инженерную подкоманду дженералистов — каждый раз.
- Считать OT-проблемой pipeline. Это проблема change-control. Замедление не в CI — а в том, что PLC-изменение влияет на физическую линию и кто-то ответственный должен сказать «go».
- Игнорировать OEE во время деплоя. Если post-deploy OEE падает на 5 пунктов и держится смену, это failed-релиз, пусть даже все тесты прошли.
Контр-тезис
Manufacturing-инженерным командам нужно не меньше Agile — а Agile, применённый послойно, с разным cadence и разными метриками на слой. Команды, пытающиеся подтянуть все четыре слоя к единому cadence, либо замедляют быстрые слои (office-IT), либо безрассудно ускоряют медленные (shop-floor). Правильный ответ — четыре pipeline, уважающих физику.
Честные ограничения
Наш manufacturing-датасет — 6 customer-команд (automotive, food-processing, промышленное оборудование) — значительный, но не широкий. У нас пока нет сильного сигнала по pharma / регулируемым FDA-cGMP-средам, где overhead валидации доминирует над cadence. PLC-специфичные метрики (строки ladder logic в день, затронутые tag-points) — пока вне нашего ядра измерения; мы коррелируем через Git-активность, но native ladder-logic-парсинга нет.
Дополнительное чтение
- DORA Metrics: полный гайд для инженерных лидеров (2026) — чистый SaaS-baseline, от которого эта статья отстраивается
- Инженерные метрики в Fintech: комплаенс, скорость, безопасность — другой regulated-environment-компаратор
- Lead Time for Changes: разбор по 4 стадиям — стадийный анализ, обобщающийся на многослойные manufacturing-pipeline'ы
- External: Deloitte Smart Factory 2023 Study — индустриальные бенчмарки по барьерам IT/OT-интеграции