Бизнес-модель под ИИ: зачем пересчитывать процессы до внедрения нейросетей

автор:
Роман Васильев


Автор: Шананина Евгения — эксперт по стратегическому управлению и операционной эффективности, специализируется на трансформации производственных и технологических компаний.

Я присутствовала на десятках презентаций, где команда с гордостью показывает: «Мы внедрили нейросеть. Она генерирует / предсказывает / анализирует. Смотрите, как работает». А в конце — тишина. Потому что никто не может ответить на вопрос, который задает генеральный директор: «А что это меняет в нашей прибыли?»

Не потому, что технология плохая, а потому что она никуда не встроена. Она висит поверх бизнес-модели, как красивая витрина на пустом складе. Сегодня я объясню, как сделать так, чтобы ИИ перестал быть демо и стал строиком в вашей модели дохода.

Бизнес-модель в одном предложении

Я более 15 лет занимаюсь операционной трансформацией — в ПАО «Полюс», ПАО ГМК «Норникель», ИТ-Холдинге Т1. И каждый раз первый мой шаг — не технология, а один вопрос: кто, что, как и за сколько.

Кто — клиент, для которого мы создаём ценность.

Что — конкретная ценность: продукт, услуга, решение.

Как — цепочка процессов, которая эту ценность создаёт и доставляет.

За сколько — себестоимость, цена, маржа.

ИИ не должен «улучшать» эту модель в абстрактном смысле. Он должен бить по конкретным параметрам:

Себестоимость одного цикла (меньше ручных операций, меньше ошибок, меньше переделок).

Скорость (короче время цикла — от запроса до результата).

Конверсия (больше полезных решений, меньше мусора на выходе).

Потери (Lean-термин, который я использую ежедневно: всё, что не создаёт ценность для клиента, — это потеря).

Если вы подключили нейросеть, а эти четыре числа не сдвинулись — вы не внедрили ИИ. Вы купили софт. Разница в ордерах, и я это видела на многих проектах.

Пример из розницы: когда прогноз не работает

Возьмём задачу, которая встречается в ритейле, логистике, производстве — предсказание спроса.

Ситуация «до». 

У компании 500 SKU в одном складе, 530 — в другом, потому что справочники номенклатуры дублируются в трёх системах и никем не синхронизируются. Правила пополнения витрины: «менеджер смотрит по ощущениям и по продажам за прошлую неделю». SLA по срокам поставки от поставщика — «обычно 3–5 дней, но может быть 7».

В такой контур подключают ИИ-прогноз. Модель обучается на данных, которые: содержат дубли и расхождения в наименованиях; не отражают реальных правил пополнения (потому что их не существует в явном виде); дают размытое окно поставки, а не конкретный SLA.

Результат: прогноз «красивый», но на складе остаются излишки на 12% по одной категории и дефицит на 9% по другой. Финансовый эффект — ноль. Проект закрывают как «пилот не оправдал ожиданий».

Ситуация «после». 

Прежде чем трогать модель, мы:

1. Привели номенклатуру к единому справочнику (один SKU — одна запись, один владелец).

2. Записали правила пополнения в явном виде: при каком уровне остатка, с каким коэффициентом безопасности, по какому циклу.

3. Зафиксировали SLA по поставке: 3 дня — норма, 5 дней — с оповещением, 7 дней — эскалация.

И только после этого подключили ИИ-прогноз. Модель теперь обучается на чистых данных, считает дефицит/излишек по понятным правилам и опирается на конкретные сроки, а не на «обычно».

Результат: 

Снижение излишков и дефицита на 15–20%. Не потому, что нейросеть стала умнее. Потому что под ней появился скелет, по которому она может опереться.

Я видела этот кейс в нескольких компаниях. Алгоритм один и тот же. Разница — в том, что предшествовало включению модели.

Язык результатов, а не язык инструментов

Вторая типичная ошибка — фиксировать эффект в терминах технологии, а не бизнеса.

Сравните две формулировки, которые я слышу на уровнях совета директоров:

«-»  «Мы внедрили ИИ для анализа договоров. Модель обработала 1 200 документов за квартал.»

«+» «Мы сократили средний цикл согласования договора с 12 до 7 дней. Стоимость переделок из-за ошибок в формулировках снизилась на 22%. Выполнили 1 200 документов с 2% возвратов, а не с 9%.»

Первая формулировка — факт о инструменте. Вторая — факт о бизнес-модели. В совете директоров бюджет на следующий этап дают за вторую. За первую — кивают и спрашивают: «И что?»

Это не формальность. Это Lean-принцип, который я привожу из Toyota T-TPS: эффект измеряется на выходе процесса, а не на входе инструмента. Входящие данные — это то, что вы дали системе. Выходящий результат — это то, что система дала бизнесу. ROI считается по выходу.

Когда я в «Полюсе» строила экосистему обучения наставников и проведения стажировок, мы не отчитывались «провели 400 часов обучения». Мы отчитывались: «Текучесть снизилась на 47%, производительность выросла на 15%, затраты на энергию упали на 27%». Именно эти цифры позволили компании войти в ТОП-3 золотодобытчиков мира и именно они легли в основу моего диплома MBA-LEAN.

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

Мини-шаблон: три вопроса перед стартом

Я предлагаю простой фильтр, который использую и в проектах на производственных предприятиях, и в трекинге ИТ-стартапов. Три вопроса. Если на все три вы можете ответить до подключения модели — вы внедряете ИИ. Если хотя бы на один нет — вы покупаете демо.

1. Какую метрику бизнес-модели мы меняем?

Не «что умеет модель», а какой параметр в формуле «кто, что, как, за сколько» сдвигается. Время цикла? Себестоимость единицы? Конверсия в положительное решение? Процент ошибок? Напишите одну цифру: «Мы снижаем X с A до B». Если не можете — у вас нет цели, а есть эксперимент.

2. Как мы считаем эффект?

Формула, базовая линия (baseline), период измерения, источник данных. Без baseline невозможно доказать, что изменение произошло. Без формулы невозможно отделить эффект от случайности. Без периода невозможно не принять сезонный скачок за результат. Это не бюрократия. Это та же логика, что в Toyota – цикл Деминга: сначала меряешь, потом улучшаешь.

3. Кто отвечает за результат?

Не «команда ИИ-проекта». Конкретный человек, роль, SLA. Кто принимает решение, если модель дала ошибку. Кто обновляет правила, если процесс изменился. Кто закрывает вопрос, если метрика не сдвинулась через 90 дней. Без владельца результата ИИ остаётся «проектом». С владельцем — становится частью операционной модели.

Эти три вопроса занимают 20 минут. И они экономят вам три месяца работы и шестизначный бюджет, которые ушли бы на «красивое демо», которое так и не изменило ни один параметр бизнес-модели.

Итог

Моя миссия — трансформировать сложное в простое. И в теме ИИ простое правило звучит так: организация — единый организм, а ИИ — новый орган, который должен иметь, к чему прикрепиться.

Бизнес-модель — это скелет. Процессы — это мышцы. Данные — это кровь. ИИ — это нервная система, которая ускоряет сигналы. Но нервная система не работает на теле без костей.

Пересчитайте процессы. Зафиксируйте метрики. Назначьте владельца. И только потом подключайте интеллект. Тогда он перестанет быть демо. И начнёт работать на прибыль.

Евгения Шананина — эксперт по операционной трансформации бизнеса, трекер Skolkovo, эксперт ФРИИ, НТИ и МСП.РФ, преподаватель ИТМО и ВШМ СПбГУ. Победитель международного конкурса проектов трансформации. 15 лет юридической практики. 10+ лет опыта управления проектами трансформации в корпорациях (Полюс, Норникель, ИТ-Холдинг Т1).

Фото: пресс-служба



Комментарии

Ваше имя:
Ваш комментарий:
Код с картинки: