Автоматизация бизнес-процессов с ИИ: с чего начать

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

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

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

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

Как выбрать процесс для первого пилота с ИИ

Для первого пилота подходит повторяемая операция с доступными примерами, понятным результатом и возможностью исправить ошибку до отправки сообщения или изменения рабочих данных. Разбор заявки, подготовка черновика ответа или извлечение сведений из документа позволяют задать проверяемый результат. Формулировка автоматизировать продажи объединяет слишком много решений.

На старте рекомендуем распределить ответственность:

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

Это распределение задач для пилота. В небольшой команде один человек может совмещать роли, но выбор операции, сбор примеров и приёмка должны иметь назначенных ответственных.

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

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

Для одной компании началом станет разбор писем, для другой подойдёт подготовка материалов по утверждённому заданию. Автоматизация бизнес-процессов требует выбора конкретной операции: удобный для испытания участок не обязательно совпадает с самым заметным или самым дорогим процессом компании.

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

Какие операции выполнять по правилам, а какие поручать ИИ

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

В статье Building effective agents Anthropic различает рабочие процессы с заранее заданными путями и агентов, которые сами выбирают действия. Компания рекомендует начинать с простых решений, усложнять их по необходимости и учитывать стоимость, задержку и оценку результата. Это рекомендация по устройству системы, без доказательства экономии в конкретной компании.

В учебном процессе обязанности можно разделить так:

Таблица задаёт требования к реализации. Наличие нужных действий в выбранном инструменте проверяют при настройке.

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

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

Как описать входные данные и условия приёмки результата ИИ

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

В учебном процессе входом служит сохранённое сообщение клиента вместе с явно переданным контекстом. Если система получает только последнее письмо, опираться на предыдущую переписку она не должна.

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

Слабое задание: «Разбери заявку и подготовь хороший ответ». В нём не определено, что считать хорошим ответом и какие сведения разрешено использовать.

Рабочая формулировка для учебного пилота:

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

Проверяющий принимает результат по следующим условиям:

1. Подтверждённые сведения: каждое заполненное поле опирается на переданные материалы.
2. Пропуски: отсутствующие данные остаются неизвестными, обязательные уточнения перечислены.
3. Противоречия: несовместимые условия отмечены и переданы сотруднику.
4. Черновик: ответ не содержит несогласованных обещаний цены, срока или состава работ.
5. Доступность материалов: исходное сообщение и результат разбора доступны для сопоставления.
6. Разрешение на действие: подготовленный текст остаётся черновиком до согласования.

Первый пилот автоматизации. Учебная памятка.

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

Как измерить ручную работу до подключения ИИ

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

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

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

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

Для варианта с ИИ предлагаем считать:

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

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

Единицей сравнения может стать одинаковый набор обращений с одинаковыми условиями приёмки. Это помогает проверить, уменьшилась ли работа при сохранении требований к результату. При этом журнал должен показывать трудоёмкость каждого типа заявок: общее среднее способно скрыть рост затрат на неполные или спорные обращения.

Как испытать ИИ на прошлых заявках

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

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

В набор стоит включить:

1. Полное обращение: задача и необходимые сведения названы прямо.
2. Неполное обращение: потребность понятна, но данных для следующего действия недостаточно.
3. Противоречивый вход: части сообщения задают несовместимые условия.
4. Повторную заявку: клиент прислал прежнее сообщение ещё раз.
5. Дополнение: новое сообщение уточняет или меняет ранее переданные сведения.
6. Неподходящий вход: обращение не относится к выбранному процессу или требует недоступного контекста.

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

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

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

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

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

Сообщения и решения в этом разделе вымышлены для учебного примера.

Здравствуйте. Нужен сайт к запуску нового направления. Сейчас есть старый лендинг, можем прислать ссылку. Хотим понять сроки и стоимость.

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

Контакт для ответа берётся из сохранённых данных обращения. Если его нет, заявка передаётся сотруднику с пометкой о невозможности отправить уточнение. Выдумывать адрес или выбирать похожий контакт нельзя.

После разбора правило проверяет сведения, обязательные для оценки работ. Заявка получает статус требуется уточнение, ИИ готовит черновик:

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

Сотрудник проверяет вопрос перед отправкой. Часть сведений может быть в переписке, которую система не получила. Тогда потребуется дополнить контекст или отредактировать черновик. В журнале отмечают причину исправления, чтобы отличить ошибку разбора от неполного входа.

Статус ожидания ответа клиента присваивается после подтверждённой отправки уточнения. До отправки заявка остаётся на проверке. Сотрудник должен видеть, от кого требуется действие сейчас.

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

Как обработать сбой и дубликат и вернуть заявку сотруднику для ручной работы

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

В документации n8n по обработке ошибок описаны обработка ошибок рабочего процесса, отдельный сценарий для ошибок и особенности ошибок запуска. Команде нужно определить, какое состояние сохраняется и кто продолжает работу.

Для учебного процесса предлагаем проверить такие ситуации:

1. ИИ не вернул результат. Исходное сообщение сохраняется, заявка получает статус ошибки разбора и попадает в ручную очередь. Сотрудник продолжает работу с исходным текстом. Для повторной попытки задаются условие запуска и предел повторов.
2. Результат не прошёл приёмку. Обязательные поля отсутствуют или сведения не подтверждены. Последующие действия останавливаются. Сотрудник видит причину и выбирает исправление, повторный разбор либо ручную обработку.
3. Пришёл дубликат. Правило обнаружило повтор по идентификатору источника или другому согласованному признаку. Система связывает его с исходной заявкой и проверяет выполненные действия. Повторное уточнение автоматически не отправляется.
4. Сотрудник забрал заявку в ручную работу. Автоматические действия прекращаются. Исходный текст, результат разбора и причина передачи сохраняются. Возобновление автоматизации требует явно выбранного этапа.

Возврат после ошибки. Учебная памятка.

Совпадение текста не всегда означает дубликат: клиент мог повторить часть письма и добавить новые сведения. Если заданных признаков недостаточно для решения, сообщение передают сотруднику.

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

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

Какие действия оставлять на подтверждение сотруднику

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

Microsoft описывает согласования в Power Automate как механизм согласования рабочих процессов. Это пример реализации подтверждения; доступность нужных действий в выбранной конфигурации проверяют отдельно.

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

Такой процесс можно проектировать как AI-ассистента, который получает материалы, готовит результат и передаёт его на проверку. Условия приёмки, права на действия и порядок передачи сотруднику задаются при проектировании. Само подключение ИИ их не создаёт.

Как выбрать инструмент и ограничить права доступа ИИ к данным

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

Для работы с таблицами или документами Google одним из механизмов запуска служат установленные триггеры Apps Script. Документация Google описывает запуск по событиям и времени. Такие триггеры выполняются с правами создавшего их пользователя. Сценарий не получает автоматически права любого читателя документа.

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

Как сравнить ручную обработку и работу с ИИ по трудозатратам

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

Все числа в расчётах учебные. Они иллюстрируют метод и не относятся к результатам Звонко или другой компании.

Предположим, набор содержит 40 заявок. Ручная обработка занимает в среднем 8 минут на заявку, включая чтение, поиск контекста, запись сведений и подготовку согласованного ответа. Всего получается 320 минут активной работы.

Один из возможных учебных результатов после подключения ИИ:

В этом учебном варианте регулярная работа сократилась на 60 минут. Настройка и первичное испытание в таблицу не входят. Для решения о запуске их учитывают отдельно вместе с расходами на инструменты и ожидаемым объёмом обращений.

Второй учебный вариант даёт отрицательный результат:

Во втором варианте ИИ добавил 30 минут работы: 350 минут против 320 минут при ручной обработке того же набора.

Полная трудоёмкость процесса. Учебная памятка.

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

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

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

Что передать команде после завершения пилота

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

В итог пилота предлагаем включить:

1. Объём автоматизации: какие действия выполняют правила, ИИ и сотрудник.
2. Примеры приёмки: принятые результаты и ошибки с причинами исправлений.
3. Сравнение трудоёмкости: одинаковое начало и завершение работы в обоих вариантах.
4. Порядок восстановления: действия при сбое, дубликате и передаче заявки сотруднику.
5. Ответственность: кто обновляет инструкцию, разбирает ошибки и останавливает процесс.

Спроектировать пилот автоматизации. Если вы хотите сократить работу с обращениями или подготовкой материалов, обсудите с нами в Звонко первый процесс для пилота. Начнём с входных данных, условий приёмки и способа сравнить трудозатраты. Цель пилота: определить, какую часть работы оправдано автоматизировать.

Вопросы перед запуском автоматизации с ИИ

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

Можно ли начать, если старые заявки содержат персональные данные?

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

Как сравнить два инструмента без внедрения обоих?

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

Как оценивать пилот, если заявки зависят от сезона?

Набор для проверки стоит разделить по типам обращений и условиям работы. Если в спокойный период приходят полные заявки, а во время запуска много коротких и повторных сообщений, среднее время по одной группе не описывает другую. Для каждого типа записывают трудозатраты отдельно. Решение о внедрении относят к проверенным условиям; для другого периода сохраняют необходимость дополнительного испытания.

Что делать, если ответственный за автоматизацию уходит в отпуск?

До запуска назначают замену и проверяют, может ли этот сотрудник увидеть состояние заявок, остановить сценарий и продолжить обработку вручную. Инструкция должна описывать доступы и действия при ошибке без зависимости от объяснений отсутствующего коллеги. Если замены нет, на период отсутствия ответственного можно оставить подготовку черновиков либо вернуться к ручному процессу. Такой режим нужно согласовать заранее.

Можно ли перенести удачный пилот в другой отдел?

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

Что делать, если сотрудники обходят автоматизацию?

Разобрать вместе с сотрудниками случаи, в которых привычный способ оказался удобнее. Причиной может быть отсутствие контекста, трудная проверка, лишние уведомления или неудобный ручной возврат. Время на обход и последующее восстановление записывают в журнал пилота. Если такие случаи повторяются, расчёт экономии пересматривают. Дальнейшее решение зависит от причины: изменить процесс, сократить автоматизацию или оставить ручную обработку.

ОБ АВТОРЕ

Сергей Бурый Сооснователь Звонко. Эксперт по практическому применению ИИ, главный редактор международных медиапроектов, преподаватель СПбГУ