Как внедрить ИИ в бизнес и получить рабочий процесс

Выберите операцию с понятным результатом

Начните с последнего рабочего дня. Какие действия повторялись? Где сотрудник копировал данные между таблицами, искал ответ в переписке, переименовывал файлы или ждал подтверждения? Для каждой операции запишите вход, ожидаемый выход и человека, который принимает результат. Формулировка «повысить эффективность отдела» слишком широкая для первого запуска. «Из фотографий и таблицы характеристик подготовить комплект карточек по артикулу» уже позволяет подобрать инструменты и проверить качество.

Выбирать только самую трудоёмкую операцию тоже недостаточно. У неё могут быть редкие исключения, отсутствующие исходники и множество согласующих. Для первого проекта удобнее регулярный процесс с доступными примерами и понятными правилами. Официальное руководство Google Cloud связывает выбор сценария с измеримой бизнес целью и отдельно предлагает определить, требуется ли вообще ИИ для её достижения. Руководство по выбору сценария.

Разберите путь заявки или материала целиком

Результат часто теряется на стыке отделов. Текст уже написан, но неизвестно, кто его утверждает. Заявка уже пришла, но менеджер её не увидел. Фото обработано, но у файла неправильный артикул. Поэтому схема внедрения должна включать весь путь: получение исходника, обработку, проверку, передачу в следующую систему и подтверждение приёма. Так становится видна реальная причина задержки, которую нельзя устранить одним удачным запросом к модели.

В RIGHTHALL я работал с внутренним контуром агентства: новостройками и вторичным жильём, каталогом, задачами и согласованием договоров. В таком проекте важны связи между объектом, брокером, источником информации и дальнейшим действием. Создание объявления полезно только тогда, когда оно относится к актуальному объекту, использует корректные данные и попадает в нужный маршрут. Подробный кейс показывает, как эти части собираются в систему.

Подготовьте данные и определите источник правды

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

В проектах MUNZ и Salamander фотографии поступают вместе с артикулами и XLS. Табличные характеристики связываются с инфографикой, а при нехватке данных вопрос возвращается администрации. Это принципиальная деталь: отсутствие свойства не превращается в выдуманное преимущество товара. До запуска полезно решить, какие поля обязательны, кто их дополняет и что происходит с неполной строкой. Та же логика работает в любых производственных документах.

Разделите генерацию и действия в системах

Модель может предложить формулировку или классифицировать обращение. Изменение карточки клиента, публикация статьи и отправка уведомления требуют отдельных правил. Опишите, какие действия выполняются автоматически, какие показываются человеку и какие доступны только определённой роли. Особенно важно отличать предложение модели от поручения сотрудника. Красиво сформулированная рекомендация сама по себе не даёт права изменять данные компании.

В собственной системе Macari я использую знания на сервере и подключение через MCP. Этот протокол позволяет помощнику обращаться к инструментам системы. Рабочий смысл здесь в том, чтобы сохранять поручения и получать доступ к данным в пределах выданных прав. Для внедрения в другой компании нужно отдельно описать её роли, источники и правила изменений. Сам факт подключения чата не означает, что каждый сотрудник уже получил проверенный рабочий доступ.

Запустите пилот на реальных исключениях

Пилот проверяет один выбранный маршрут на ограниченной партии. Включите в неё хорошие исходники, неполные данные, длинные названия, повторные обращения и материалы, которые обычно требуют ручной правки. Зафиксируйте, что считается принятым результатом. Для карточки это соответствие товару и корректный комплект файлов; для заявки — запись в CRM с нужными полями; для ответа по базе — правильный источник и отсутствие чужих данных.

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

Назначьте владельца процесса и правила поддержки

После пилота остаются практические вопросы: кто меняет шаблоны, кто следит за актуальностью данных, куда сотрудник обращается при ошибке и как восстановить работу после сбоя. У системы должен быть понятный ответственный. Иначе полезная разработка постепенно превращается в набор забытых настроек, а люди возвращаются к ручному копированию, потому что не понимают, какие изменения безопасны.

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

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