Урок 3: AS-IS / TO-BE и Value Stream Map — как рисовать «до и после» AI

Чему вы научитесь

• Переводить идею «давайте внедрим AI» в инженерный документ «как работает процесс сейчас и как будет работать после внедрения»
• Строить AS-IS / TO-BE так, чтобы CFO и директор завода видели не только технологию, но и деньги
• Накладывать AI-сценарии на Value Stream Map и быстро находить точки, где проект реально даёт эффект
• Делать roadmap Discovery → Pilot → Scale-out → Expansion без магии и без фразы «посмотрим по ходу»
• Замечать ошибки, из-за которых защита проекта рассыпается: нет базовой метрики, не учтён контур, не определён владелец процесса

Демо модели не защищает бюджет. Бюджет защищает только разница между «как процесс живёт сегодня» и «что конкретно изменится после внедрения». Именно поэтому сильные промышленные кейсы почти всегда показывают не «какая модель стояла», а метрику до и после. Например, BMW в Debrecen заявляет снижение затрат на планирование производства до 30% за счёт виртуальной фабрики и цифровых двойников (Assembly Magazine, 2025). ЕВРАЗ сообщал об экономическом эффекте цифровых проектов на 5,8 млрд ₽ за 2024 год (TAdviser, 2025).

Для защиты AI-проекта этого достаточно как принципа: сначала рисуем процесс, потом метрики, потом деньги, и только потом — модель, контур и бюджет. Формула денег уже разобрана в уроке 1 этого модуля, а выбор модели и контура — в уроке p.2/04.

Что такое AS-IS / TO-BE в AI-проекте

AS-IS — это текущий процесс с реальными ограничениями. Не «как должно быть», а «как живёт цех сегодня». TO-BE — будущий процесс после внедрения конкретного AI-сценария, с теми же KPI, но уже в новой конфигурации ролей, систем и точек принятия решения.

Ключевая ошибка в AI-проектах — рисовать TO-BE как презентационную мечту. Правильный TO-BE всегда начинается с трёх жёстких вопросов:

• где рождаются данные и в каком контуре их можно обрабатывать;
• кто принимает финальное решение: модель, инженер или мастер;
• за счёт какой именно метрики проект вернёт деньги.

Пятишаговая методика: как рисовать «до и после»

1. Зафиксируйте AS-IS без косметики. Нарисуйте реальный поток: кто что делает, сколько времени занимает шаг, где накапливается очередь, где происходят ошибки, где решение принимается «на глаз». Если метрики нет, это тоже факт процесса.

2. Назовите точки боли в единицах бизнеса. Не «оператору тяжело», а «ручной контроль охватывает только часть продукции», «дефект ловится поздно», «повторный передел съедает маржу», «мастер тратит часы на разбор журналов».

3. Подберите AI-сценарий под задачу, а не наоборот. Для этого удобно открыть матрицу «задача × модель × контур»: часть задач решается CV или forecasting, а не LLM. Если проект упирается в КИИ или санкционный контур, сразу сверяйте его с уроком про КИИ и уроком про санкции.

4. Опишите TO-BE как эксплуатационный процесс. Где стоит модель, кто видит алерт, кто подтверждает решение, какой fallback включается при ошибке, как ведётся журнал и кто отвечает за качество данных.

5. Переведите разницу в деньги. Для каждой метрики считайте годовой эффект и только потом прикладывайте CapEx и TCO. Формулу ROI и payback берите из урока 1 этого модуля, иначе TO-BE останется красивой схемой без защиты перед CFO.

Учебный пример: ОТК на прокате

Ниже — не публичный кейс конкретного комбината, а учебная модель по шаблону, который обычно используют для защиты CV-проекта в ОТК. Все числа в ней требуют сверки с вашими данными. Поэтому каждая цифра помечена как «учебный пример, нужна проверка».

Этот пример полезен именно как шаблон. Он показывает, какие столбцы нужны в защите. Но в нём есть важная проверка на здравый смысл: если убыток падает с 30 млн ₽ до 10 млн ₽ в год, то валовая разница составляет 20 млн ₽/год (учебный пример, нужна проверка). При CapEx 1,2 млн ₽ простой payback по формуле из урока 1 получится ближе к 1 месяцу, а не к 5 месяцам (учебный пример, нужна проверка). Значит, в реальной защите одна из предпосылок должна быть уточнена: либо учтён не весь эффект, либо выше полный TCO, либо эффект возникает не с первого месяца.

Именно это и есть польза AS-IS / TO-BE. Он не даёт вам принести в бюджетный комитет красивую, но внутренне противоречивую математику.

Как наложить AI на Value Stream Map

Value Stream Map нужен не для слайда «мы тоже знаем lean-термины». Он нужен, чтобы показать, где AI убирает потери — ожидание, передел, ручную сортировку, поиск причин, повторный ввод данных. В AI-проекте VSM особенно полезен там, где один и тот же дефект или инцидент много раз проходит через людей, Excel, почту и поздний разбор.

Практическое правило простое: на карту процесса ставятся не «модели», а маркеры изменения потока.

• AI-Detect — система находит событие раньше человека;
• AI-Classify — система сразу относит случай к категории;
• AI-Prioritize — система поднимает наверх критичные случаи;
• AI-Explain — система помогает быстро понять причину;
• AI-Assist — система готовит черновик решения, но финальный выбор остаётся у человека.

flowchart LR
    A[Прокатная линия] --> B[Ручной визуальный контроль]
    B --> C{Есть дефект?}
    C -->|Нет| D[Продукция идёт дальше]
    C -->|Да| E[Запись в журнал]
    E --> F[Разбор мастером]
    F --> G[Решение: передел или отгрузка]
    G --> H[Позднее выявление брака у клиента]

    A -. AI-Detect .-> B2[Камеры + CV]
    B2 -. AI-Classify .-> E2[Автокарточка дефекта]
    E2 -. AI-Prioritize .-> F2[Очередь дефектов по критичности]
    F2 -. AI-Explain .-> G2[Подсказка причины и похожие кейсы]

На хорошей VSM-карте AI-точка отвечает на один из трёх вопросов:

1. где можно поймать проблему раньше;
2. где можно снять ручную сортировку и переписывание;
3. где можно сократить цикл принятия решения.

Типовой roadmap на 6-12-24 месяца

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

Roadmap нужен не для красоты. Он выполняет три управленческие функции.

Во-первых, показывает, что проект не обрывается на пилоте. Если после Pilot у вас нет бюджета и оргсхемы на Scale-out, вы почти наверняка строите очередной «успешный PoC», который не доедет до эксплуатации.

Во-вторых, roadmap делает видимой зависимость от контура. Иногда Pilot можно показать в частном облаке, а Scale-out упирается в то, что промышленный контур должен быть on-prem. Это нормальная проблема, но её надо вытащить заранее через матрицу выбора модели и контура и уроки p.3 про КИИ и санкции.

В-третьих, он делает прозрачной стоимость change management. Если вы не заложили обучение операторов, параллельный прогон и режим fallback, TO-BE на бумаге не переедет в живой процесс.

Как выглядит сильная защита проекта на одном листе

Хороший AS-IS / TO-BE можно пересказать в четырёх предложениях.

1. Сегодня процесс теряет деньги вот здесь.
2. AI меняет конкретный шаг процесса, а не «всё сразу».
3. После внедрения меняются вот эти KPI и вот так они переводятся в деньги.
4. Для этого нужен вот такой контур, вот такая команда и вот такой roadmap.

Если вы не можете изложить проект в этих четырёх предложениях, проблема почти всегда не в презентации. Проблема в том, что TO-BE пока не определён как операционная система процесса.

Проверочный список перед защитой AS-IS / TO-BE

• Есть владелец процесса с бизнес-KPI, а не только владелец пилота
• Зафиксирован baseline хотя бы по одной ключевой метрике
• Понятно, какая именно потеря переводится в деньги
• Выбран минимально достаточный AI-сценарий, а не самый модный
• Проверен допустимый контур обработки данных
• Описан fallback: что происходит, если модель не уверена или недоступна
• Есть ответственный за качество данных и журналирование
• Есть отдельный бюджет не только на пилот, но и на масштабирование
• В TO-BE указано, кто принимает финальное решение
• Внутренняя математика примера сходится по ROI и payback