Модуль p.11 · Урок 2
Урок 2: Выход из PoC-ада — почему пилоты не становятся production и что с этим делать
Содержание
- Чему вы научитесь
- Три главные причины PoC-ада
- Как выглядит паттерн успеха: AI factory
- Четыре признака живой AI-программы
- Что видно на кейсах ADNOC, Татнефти и Aker BP
- ADNOC: масштабирование начинается с контракта на программу, а не на демо
- Татнефть: программа начинается с управленческой мобилизации
- Aker BP: реальная ценность приходит через операционную скорость
- Roadmap «пилот → production → fleet»
- Что делать на каждом этапе масштабирования
- Когда пилот надо убивать, а не тянуть в production
- Что делать уже завтра, если вы чувствуете PoC-ад
Чему вы научитесь
- Разводить три разных механизма PoC-ада: data gap, integration gap и operations gap
- Видеть, почему красивый пилот почти ничего не гарантирует на масштабе
3–5активов и тем более на уровне холдинга - Использовать паттерн AI factory на примере Shell как модель перехода от одного пилота к десяткам production-сценариев
- Понимать, какие пилоты надо тиражировать, а какие честно убивать после validation phase
- Строить roadmap scale-out так, чтобы MLOps, data pipeline и reference architecture появлялись раньше fleet-wide rollout
PoC-ад — это не «мы сделали мало пилотов». Это состояние, в котором пилоты случаются регулярно, эффект иногда даже виден, но production-масштабирования не происходит. Организация ходит по кругу: идея, демо, локальный успех, новая идея, новый демо-стенд — и никакого повторяемого механизма доставки результата в цех. Чтобы не путать хороший локальный эффект с масштабируемой экономикой, полезно держать рядом урок p.4/02 про payback-бенчмарки: он помогает понять, в каких классах задач scale вообще имеет смысл.
Урок p.4/06 уже разбирал риски и change management. Здесь фокус другой: что делать, когда пилот уже не умер на старте, но всё ещё не стал промышленной функцией.
Три главные причины PoC-ада
| Разрыв | Как он выглядит | Почему пилот ещё жив, а production уже умирает | Что делать |
|---|---|---|---|
| Data gap | На пилоте был cleaned dataset, а в бою идут пропуски, шум, незакрытые идентификаторы, другая частота данных | Пилот доказывал идею на frozen sample, а не жизнеспособность data path | До scale-out строить data foundation, quality checks, lineage и owner данных; иначе каждый новый актив будет отдельным mini-project |
| Integration gap | Модель умеет предсказывать, но не встроена в SCADA, MES, EAM, ERP, service desk | Production требует не только prediction, но и action path, алерты, наряды, safe override, мониторинг | Сначала reference architecture и integration template, потом тиражирование на второй и третий актив |
| Operations gap | Drift не виден, SLA нет, модель некому обновлять, бизнес не понимает кто on-call | Пилот переживает руками энтузиастов, но не переживает отпуск, квартальный релиз и первый инцидент | Строить MLOps и операционную службу до fleet rollout; см. p.9/06 |
Самая дорогая ошибка здесь — лечить все три разрыва новыми пилотами. Новый пилот обычно только откладывает момент, когда компания признает, что у неё нет platform layer.
Как выглядит паттерн успеха: AI factory
Если нужен канонический индустриальный пример выхода из PoC-ада, это Shell + C3 AI. Официальный кейс фиксирует у Shell 10 000+ единиц оборудования, 3 млн+ data streams, 20 млрд строк данных в неделю, 10 000+ production-grade моделей и 15 млн+ предсказаний в день (C3 AI, 07.03.2022). Это не «много пилотов». Это фабрика.
Ключевой вывод из кейса Shell: масштабирование начинается не тогда, когда у вас появился ещё один сильный data scientist. Оно начинается тогда, когда появилась единая платформа для данных, модели актива, регистрации моделей, раскатки, мониторинга и action path. Подробно архитектура разобрана в уроке p.6/02 про Shell + C3 AI.
Четыре признака живой AI-программы
| Признак | Почему он критичен | Как проверить за 15 минут |
|---|---|---|
| Есть data foundation до запуска AI | Иначе каждый новый use case превращается в повторный data cleanup | Попросите показать карту источников, owner данных и quality checks, а не только parquet-файл пилота |
| Есть owner с KPI из EBITDA | Без этого пилот остаётся инициативой «про инновации» | Спросите, чьим бонусом и какой строкой P&L измеряется результат |
| Заложен бюджет на scale, а не только на PoC | Иначе пилот закончится актом и слайдом | В смете должны быть интеграция, сопровождение, MLOps, обучение и тиражирование |
| Операторы обучены до запуска | Иначе реальный процесс отвергнет систему независимо от качества модели | Есть ли training sign-off, SOP и режим ручного обхода |
Эти четыре пункта звучат банально, но именно они чаще всего отличают программу от витрины.
Что видно на кейсах ADNOC, Татнефти и Aker BP
ADNOC: масштабирование начинается с контракта на программу, а не на демо
В ноябре 2024 ADNOC подписала контракт на $920 млн для расширения AI-powered well digitalization на 2000+ скважин с private 5G, edge AI, smart cameras и RoboWell для автономных операций в реальном времени (ADNOC, 05.11.2024). Здесь важен не только размер контракта, а структура мысли: масштабирование купили как программу инфраструктуры и операций, а не как очередной PoC.
Татнефть: программа начинается с управленческой мобилизации
Кейс Татнефти показывает другую сторону scale-out: перед тем как говорить о заводском MLOps, компания собрала 38 топ-менеджеров и 28 ML-специалистов и получила 150+ идей применения AI (Napoleon IT, 09.02.2023). Это важно, потому что масштабирование начинается не с rollout board, а с того, что у компании появляется pipeline use cases и единый язык между бизнесом и ML.
Aker BP: реальная ценность приходит через операционную скорость
Aker BP сократила время root cause analysis более чем на 70% — по отдельным источникам, до 97% — с недель до часов благодаря Cognite Atlas AI и общей промышленной data foundation (Aker BP, 16.09.2025). Это полезный ориентир для AI-чемпиона: scale нужен не ради красивой карты use cases, а ради кратного ускорения реальных инженерных циклов.
Roadmap «пилот → production → fleet»
flowchart LR
A[Pilot validation and hardening
1 месяц] --> B[Reference architecture
2 месяца]
B --> C[MLOps foundation and data pipeline
3 месяца]
C --> D[Scale to 3-5 assets
3-6 месяцев]
D --> E[Fleet-wide rollout
6-12 месяцев]Эта дорожная карта не означает, что любой use case обязан пройти все блоки именно в таком темпе. Она означает, что scale-out всегда требует отдельной фазы hardening и отдельной фазы platform building.
Что делать на каждом этапе масштабирования
Pilot validation + hardening. Подтвердите, что эффект выше margin of error, датасет воспроизводим, а ручной обход и baseline зафиксированы. Это ещё не rollout.
Reference architecture. Опишите единый шаблон интеграции: откуда идут данные, где inference, как работает мониторинг, куда уходит action. Без этого второй актив станет новым проектом.
MLOps foundation + data pipeline. Здесь появляется registry, CI/CD моделей, versioning данных, observability и правила обновления. Это уже не факультатив.
Scale к 3–5 активам. Нужен не большой rollout, а controlled replication: проверяем переносимость данных, стабильность quality gate и нагрузку на команду.
Fleet-wide rollout. Только после того как reference architecture и operating model пережили хотя бы несколько активов, можно говорить о масштабировании на весь парк.
Когда пилот надо убивать, а не тянуть в production
Самое дорогое решение в AI-программе — не закрыть слабый пилот, а год удерживать его в статусе «почти полетело».
Что делать уже завтра, если вы чувствуете PoC-ад
- Остановите поток новых пилотов на
2–4недели. - Соберите список всех живых use cases и разложите их по трем gaps: data, integration, operations.
- Найдите хотя бы один repeatable path: use case, который реально можно тиражировать на второй объект.
- Назначьте owner платформенного слоя: кто отвечает не за одну модель, а за путь модели в production.
- Зафиксируйте kill criteria для слабых пилотов и budget line для сильных.
Если после этого у вас осталось два-три пилота с понятной экономикой и повторяемой архитектурой, это уже начало программы. Если осталось двенадцать разношёрстных пилотов без платформы — у вас PoC-коллекция, а не AI-функция.