Почему технологичные проекты в B2B ломаются после красивой демонстрации

Когда я только начинала работать с ИИ проектами в B2B, я читала все что можно: разборы McKinsey, посты на Towards Data Science, Habr, смотрела доклады с конференций, презентации перед инвесторами, — там было много правильных и интересных подходов. Но не все они хорошо работают в реальности.

Не в реальности условного Netflix с тысячей инженеров и идеальным data lake. В реальности банка с легаси-системой 2008 года. Ритейлера, у которого данные о продажах живут в трех несвязанных системах. B2B-платформы, где владелец данных – это девушка из финансов, которая ведет сводную таблицу в Excel. Есть несколько вещей, которые я поняла через опыт – и которые расходятся с тем, что принято писать.

Почти любой B2B-AI проект можно разложить на 3 слоя успеха:1. Model – модель работает технически (качество, стабильность, данные).2. Adoption – ей реально пользуются (доверие, удобство, интеграция, обучение).3. Process change – меняется процесс и появляется эффект (регламенты, KPI, ответственность, контроль).

Если проект “не взлетел”, чаще всего проблема не на слое Model, а на Adoption или Process change — и это редко видно из метрик accuracy/F1.

Первое, что говорят, когда проект не идет, “данные плохого качества”. Иногда это правда. Чаще – это удобное объяснение, которое снимает ответственность со всех остальных участников.

Были проекты, где данные были реально плохими – и команда все равно делала что-то полезное, итеративно улучшая качество по ходу. И проекты, где данные были нормальными и ничего не взлетело, потому что никто не договорился о том, что делать с результатом модели.

Настоящие причины провалов обычно другие: нет спонсора, который защищает проект, нет договоренности об успехе, конечные пользователи не вовлечены. Рабочий вопрос на старте не “насколько хороши наши данные”, а “если модель завтра заработает – кто и как изменит свое поведение”.

В B2B это особенно острая проблема. Директор по операциям хочет снизить издержки. Менеджер, который будет работать с системой каждый день, хочет чтобы его работа стала проще, а не сложнее, и желательно чтобы его не сократили.

Эти два человека будут говорить вам разные вещи на интервью и оба будут искренни.

Проект, оптимизированный под директора, часто саботируется менеджером/ простым сотрудником – не из вредности, а потому что система не решает его задачу. Иногда создает новую: теперь нужно не только делать работу, но и объяснять системе что ты делаешь и почему ты не согласен с ее рекомендацией.

На старте лучше уточнить, кто будет пользоваться системой, и именно с ним провести отдельные интервью.

Статьи любят рассказывать про accuracy, F1, AUC-ROC. В реальном B2B-проекте меня гораздо больше интересует другое: на сколько изменилось поведение пользователей после внедрения системы? Сколько рекомендаций системы было принято? Сколько – проигнорировано, и почему?

Модель с 91% точностью, которую используют в 20% случаев, хуже модели с 78% точностью, которой доверяют и используют постоянно.

Adoption rate – более истинная метрика успеха в первые месяцы после запуска. Остальные, важны, но вторичны.

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

Это знают все кто делал и все равно каждый раз недооценивают.

Модель готова за месяц. Потом начинается: API legacy-системы задокументировано плохо и ведет себя не так как написано. Безопасность не согласовывает прямой доступ к боевой базе. Тесты в prod нельзя, нужен staging, которого нет. Владелец нужного сервиса в другом департаменте, и у него свой roadmap.

Дальше – изменение регламентов. Если система влияет на процесс, кто-то должен переписать инструкции. Это юридический или HR-процесс, который идет отдельно и медленно.

На старте нужно заложить на интеграцию столько же времени, сколько на разработку – и это при оптимистичной оценке, отдельно выяснить, сколько систем нужно интегрировать, кто владелец каждой, есть ли у них API, кто в команде безопасности отвечает за согласование доступа.

Это принципиальный сдвиг в мышлении, MVP принимается как компактная версия продукта, на которой тестируется, насколько оно будет работать. Цель MVP – понять то, что невозможно понять иначе.

В B2B это особенно ценно, потому что контекст всегда специфичен. Логистическая компания — это не просто «логистика», это конкретная операционная модель, конкретные люди, конкретные нюансы данных. Никакая статья и никакой референс не даст вам это знание. Только быстрый прототип в руках реальных пользователей.

Лучшие MVP, которые я видела, были намеренно кривыми: Excel с формулами вместо модели, Tableau вместо встроенного интерфейса, ручной расчет вместо пайплайна. Цель не произвести впечатление, а получить реакцию: “это бесполезно потому что вы не учли X” – найти этот Х перед внедрением продукта, – это победа.

Запуск – это праздник: демо, презентация завершенного продукта, все довольны. А потом начинается настоящая жизнь.

Через три месяца: часть пользователей перестала заходить, потому что система ошиблась несколько раз и они перестали доверять. Кто-то уволился и унес с собой понимание контекста. Данные немного изменились – сезонность, новый продукт, изменение процесса, – и модель начала давать странные рекомендации. Никто не знает что с этим делать, потому что план был “до” запуска, а не “после”.

План поддержки первых трех месяцев после запуска должен быть частью проекта, а не отдельным разговором потом.

Если на эти вопросы нет ответа на старте – проект в зоне риска с первого дня.

Компания со средними данными и сильной культурой принятия решений на основе данных сделает больше с AI, чем компания с отличной инфраструктурой и культурой, где данные для отчетов, решения – на интуиции.

Культура данных – это когда в компании на рабочих встречах и планировании принято спрашивать, есть ли данные перед тем, как принять решение; когда аналитик может сказать “эти данные не подтверждают вашу гипотезу” и это не вызывает конфликт, а вызывает вопрос “хорошо, что тогда говорят данные”; когда ошибка модели – это не повод закрыть проект, а сигнал для улучшения.

Это строится годами и ломается за месяц, если несколько раз подряд аналитика была проигнорирована на уровне топ-менеджмента.

При оценке потенциала AI-проекта в компании, лучше смотреть в первую очередь – не на стек технологий и не на качество данных.

AI в B2B прекрасно работает, я видела проекты которые реально изменили операционную эффективность, реально сэкономили деньги, реально сделали людей продуктивнее.

Но они работали потому что команды думали не только о модели, а о том, кто будет использовать результат, что изменится в процессе, что делать когда что-то пойдет не так.

Статьи о “как мы внедрили интеллектуальные системы в бизнес процессы и стало все круче” обычно пишутся в момент запуска, на большей дистанции картина выглядит иначе.