Тендеры и лиды
Информация
MobileUp организовал серию мероприятий, где эксперты по ИИ делятся сокровенным и рассказывают о набитых шишках. Публикуем материалы с первой встречи, это первый из серии, где Дмитрий Зобов, генеральный директор Insight AI, рассказывает о принципах золотого пилота. Пригодится, если перед вами стоит задача внедрения ИИ.
Компании всё чаще ищут задачи, которые можно решить с помощью ИИ. Но цифры показывают, что одного интереса к технологии недостаточно: 95% пилотов генеративного ИИ не дают измеримого финансового эффекта, а 40% агентских ИИ-проектов, по прогнозу Gartner, могут быть отменены к концу 2027 года.
Причины кроются в процессах ещё до разработки. Бизнес неправильно формулирует задачу, не проверяет данные или не понимает, как будет считать эффект. Разбираемся, как оценить ИИ-проект до старта и каким должен быть «золотой» пилот, а в конце статьи делимся чек-листом для быстрой проверки.
Показательный пример: крупный обувной ритейлер пришел с запросом решить проблему дедупликации товаров на Wildberries. На первый взгляд задача понятная: нужно найти дубли и убрать их. Но аудит показал, что прямых дублей в привычном смысле нет и один артикул на WB соответствует одному технически уникальному товару.
При этом проблема у бизнеса действительно была. На витрине нужно было динамически управлять составом групп товаров, которые пользователь видит вместе. А ежедневный out-of-stock «уводил» часть трафика к конкурентам, и в этом была основная боль. Получается, запрос и реальная задача — не одно и то же.
Бизнес часто приходит с симптомом, а не с самой проблемой. И задача команды — разобраться, что на самом деле происходит, и подобрать процесс, который повлияет на результат. В этом случае дедупликация была не при чём: нужно было улучшить группировку товаров и управление их вариантами. Гипотезу стоило проверить через A/B-тест.
Такой аудит до разработки помогает не тратить ресурсы на решение проблемы, которой на самом деле нет. Поэтому критически важно оценить проект перед запуском и оценить все «за» и «против».
Бизнес хочет автоматизировать рутинные операции, сократить нагрузку на сотрудников, ускорить обработку данных и улучшить клиентский сервис. Отсюда растёт интерес к ИИ и количество инициатив в этой сфере. Но сам факт использования нейросетей ещё не делает проект полезным для бизнеса.
Есть несколько распространенных заблуждений о том, как должна проходить ИИ-трансформация.
«Дадим людям инструмент — и всё само изменится».
Само появление нового инструмента ещё не означает, что он внедрится в работу. Можно дать сотруднику доступ к LLM и предложить использовать её в работе. Но если для этого ему каждый раз нужно отдельно открыть сервис, скопировать данные, получить ответ и перенести результат обратно в рабочую систему, процесс практически не изменится, и, возможно, даже ухудшится.
Поэтому важно встраивать инструмент в рабочий процесс так, чтобы он становился её неотъемлемой частью. а не очередным «сторонним» сервисом.
«Сделаем то, что попросили сотрудники».
Запрос членов команды — хороший источник информации о проблемах, но не всегда готовая постановка задачи. Представим финансовый отдел, который хочет автоматизировать обработку первичной документации. Сотрудники тратят много времени на ручную работу, поэтому кажется логичным внедрить ИИ и освободить часть нагрузки. Но если посчитать экономику, картина может оказаться другой.
Например, автоматизация действительно может освободить 0,45 ставки. Но это не означает, что бизнес получит экономию в размере 0,45 зарплаты. Если сотрудника не планируют сокращать или переводить, финансового эффекта может не возникнуть. Поэтому перед разработкой нужно понять не только, что сотрудники хотят автоматизировать, но и какую бизнес-задачу это решит.
«Построим агентов — и они всё сделают».
На самом деле, далеко не каждой задаче нужны агенты. В некоторых случаях достаточно правил, исторических данных, RAG, API или другого более простого решения.
Поэтому начинать стоит не с выбора технологии и даже не с разработки. Сначала нужно проверить саму бизнес-задачу: есть ли у нее понятная цель, данные, измеримый эффект, приемлемые риски и возможность встроить решение в процесс.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13757 тендеров
проведено за восемь лет работы нашего сайта.
Ниже — несколько критериев и вопросы, на которые стоит ответить перед тем, как брать проект в работу. Они помогут объективно оценить все нюансы, и выбрать проект, который максимально готов к запуску и принесёт больше пользы.
Даже правильно сформулированная задача не станет ИИ-проектом без хорошей базы данных. Обязательно проверяем:
собраны ли необходимые данные,
доступны ли они на старте,
достаточно ли они полные, точные и свежие.
Мы в качестве базовых ориентиров используем такие значения: точность данных — выше 95%, полнота — выше 90%, свежесть — не старше 24 часов. Но это не универсальные требования. Для одного процесса данные недельной давности могут быть приемлемыми, для другого даже несколько часов будут критичны. Конкретные пороги нужно адаптировать под задачу, тип данных и допустимую цену ошибки.
Главное, что требования к данным должны быть определены до разработки. Если нужной информации нет или её качество недостаточно, это может застопорить процессы и вылиться в лишние траты.
Чтобы понять, как именно качественно изменится бизнес после внедрения ИИ-проекта, нужно знать два момента:
какие значения показателей есть сейчас,
сколько стоит существующий процесс на данный момент.
При этом важно разделять операционный эффект и экономию. Вспомним пример, когда 45% автоматизация не означает экономию бизнеса в размере 0,45 зарплаты.
Мы оцениваем окупаемость проекта на горизонте трех лет. Базовый ориентир — показатель выше 2,5. Но и здесь порог стоит рассматривать как отправную точку, а не универсальное правило для всех компаний и задач.
Даже перспективный проект может потерять смысл, если результат слишком далеко. Поэтому до начала разработки стоит ответить на простой вопрос: когда мы увидим первый измеримый результат? Важно, что это срок не до старта или завершения внедрения, а именно до первых плодов.
На этом этапе важно не обещать точную дату, а проверить саму гипотезу: способен ли выбранный подход дать измеримый результат в разумные сроки.
Для наших проектов ориентир — первый результат в пределах одного квартала. Но конкретный срок зависит от бизнеса, задачи и сложности решения. Если для проверки идеи потребуется несколько месяцев для сбора инфраструктуры, а результат будет доступен только после внедрения, стоит подумать, нельзя ли разбить проект на более короткие этапы.
Любая автоматизация связана с риском ошибки. Для ИИ-проектов особенно важно заранее определить, что произойдет, если система даст неверный результат. Проверяем:
понятно ли, кого затронет ошибка,
определено ли, где в процессе остается человек,
понятно ли, что происходит при нестандартной ситуации.
Риски могут быть технологическими, организационными и финансовыми. Например, система может выдавать ошибки, сотрудники откажутся пользоваться новыми процессами, а стоимость разработки окажется не той, что изначально планировалась.
Поэтому полезно заранее определить триггеры: при каких условиях проект нужно пересмотреть, остановить или изменить. Это может быть превышение бюджета, увеличение сроков или другой показатель, критичный для конкретного проекта.
Даже хорошо работающий ИИ-инструмент может не прижиться, если для его использования сотрудникам придется постоянно делать дополнительные действия.
Поэтому нужно проверить: как решение встроится в существующий процесс?
Если сотруднику приходится выгружать данные из одной системы, загружать их в отдельный сервис, получать результат, а затем вручную переносить его обратно, решение остается приложением к процессу, а не его частью. Чем больше дополнительных движений требуется «извне», тем сложнее сделать новый инструмент естественной частью работы.
На этапе оценки стоит заранее понять, какие интеграции понадобятся и что придется изменить в существующем процессе.
Теперь применим эти критерии к нескольким типам ИИ-проектов. Разберём три инициативы.
Первая — нейросетевой ассистент для первой линии поддержки. Для него есть структурированные истории обращений, регламенты и скрипты. Задача понятна: снизить нагрузку на первую линию и автоматизировать часть типовых обращений.
Вторая — автоматический перенос запросов из чатов в Task Tracker. Здесь задача также сформулирована через конкретный процесс, а для интеграции используется API.
Третья — автоматическое формирование коммерческих предложений на основе переписки. На первый взгляд, задача кажется похожей на предыдущие: нужно убрать ручную работу. Но данные находятся в трёх-четырёх системах, а часть информации вообще хранится только в головах менеджеров. Это сразу создаёт дополнительные вопросы к данным и интеграции.
На первый взгляд, третий проект кажется самым результативным. Менеджеры будут отправлять больше коммерческих предложений — значит, бизнес заработает больше денег. Но при детальным разборе всё выглядит иначе.
Нейроассистент первой линии техподдержки. Данные — структурированные обращения, регламенты и скрипты есть. Эффект — подтвержденный: нагрузка операторов снижается с 80 до 32 человеко-часов в день, доля авторешений — 85%. Срок — около двух месяцев. Риски — небольшой организационный риск из-за возможного сопротивления сотрудников. Интеграция — полностью встраивается в систему техподдержки.
Чтобы быстро оценить проекты, можно использовать простую матрицу.
По итогам анализа изначальный фаворит оказался самым нежизнеспособным ИИ-проектом.
Смысл проверки — быстро понять, готов ли проект к запуску прямо сейчас. Если не хватает данных — сначала разбираемся с данными. Если непонятен эффект — возвращаемся к бизнес-задаче. Если решение не встраивается в процесс — думаем не только о разработке, но и об изменении самого сценария работы. И только после этого имеет смысл переходить к бюджету и разработке.
На этом примере мы демонстрируем ещё одну идею: для одной компании стратегия внедрения ИИ должна быть не более, чем на три проекта. Больше просто не имеет смысла.
Итак, по итогам оценки мы выявили, что нейро-ассистент становится целевым проектом, так как риск минимален, а по остальным критериям он отлично подходит. Формирование КП по переписке стоит нужно отложить и переформулировать — в нынешнем виде это провальный проект. А передачу запросов в таск-трекер стоит взять в пилотную разработку.
Первый пилот не проверяет технологию — он покупает организации право на следующие проекты. Поэтому необязательно делать его масштабным или сложным.
У «золотого пилота» есть пять характеристик.
Измеримый эффект определён до старта. Нужна конкретика: какой процесс хотим изменить, почему и что будет являться критерем успеха.
Данные уже есть и доступны. В противном случае пилот не получится запустить быстро, а проверять будет просто нечего.
До результата — недели или месяцы, не кварталы. Время — деньги.
Ограниченный периметр риска. Ошибка пилота не приводит к критическим последствиям, а человек остается в контуре там, где это необходимо.
Есть владелец процесса, который этого хочет. Именно он будет двигателем прогресса и амбассадором среди команды.
Первый этап ИИ-трансформации — не поиск самой впечатляющей технологии. Сначала нужно выбрать задачу, которую действительно стоит решать. Для неё должны быть доступны данные, понятен ожидаемый эффект, определён разумный срок и ограничены риски.
Тогда ИИ становится не самоцелью, а инструментом изменения конкретного бизнес-процесса. И чем раньше это будет проверено, тем меньше вероятность потратить время и бюджет на проект, который не даст результатов.
А чтобы быстро проверить ваш ИИ-проект, пользуйтесь нашим чек-листом, В нём компактно собраны все критерии и простые вопросы для проверки. Внутри стоят удобные статусы и четко подсвечена критичность каждого блока. Проверка займёт 15 минут, и вы сразу увидите, за что хвататься в первую очередь, а что лучше пока не трогать.
Ссылка на чек-лист — в канале Дмитрия в Телеграме https://t.me/itb2bsales/49
