После аудита: как довести внедрение ИИ до работающего решения

После аудита обычно появляется ощущение, что большая часть работы уже сделана: задачи собраны, приоритеты расставлены, одна задача выбрана.

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

Я бы разделял процесс на четыре этапа: аудит, R&D, разработка и внедрение. Их можно объединять в одном проекте, но результат каждого этапа должен оставаться понятным.

Аудит показывает, где есть смысл работать

На аудите мы выясняем, какие задачи выполняет компания и каким способом. Для этого проводим созвоны с заказчиком и сотрудниками, собираем информацию из чатов, фиксируем действия и приводим всё к единой структуре.

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

Из таких фрагментов нужно собрать последовательность действий.

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

На выходе аудита должны появиться карта задач, приоритеты, предварительная оценка эффекта и одна задача для детального погружения.

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

R&D проверяет реализуемость

R&D (Research and Development), объединяет исследование и разработку. На этом этапе команда проверяет, может ли ИИ выполнить выбранную задачу с нужным качеством.

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

Текущий процесс называют As-Is. Это подробная схема того, как задача выполняется сейчас. Будущий процесс называют To-Be. В нём уже учитывается роль ИИ, новые точки контроля и изменения в работе сотрудников.

Для описания процессов можно использовать CJM (Customer Journey Map), BPMN (Business Process Model and Notation) или обычную Flow-схему. Конкретный формат зависит от сложности задачи. Важнее зафиксировать логику работы, чем выбрать красивое название схемы.

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

В будущем процессе система может извлекать требования из вакансии, сравнивать их с резюме, объяснять результат и передавать HR список кандидатов для финальной проверки.

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

R&D также помогает оценить стоимость разработки. Если этап исследования включён в проект, смету можно подготовить здесь. Если компания пропускает R&D, оценку нужно сделать перед разработкой и отдельно зафиксировать уровень неопределённости.

Разработка начинается с перевода бизнес-задачи

Фраза «автоматизировать проверку резюме» для программиста слишком общая.

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

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

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

Для уже понятного процесса ориентир может выглядеть так: около 50% усилий занимает разработка и автоматизация, около 30% сбор и подготовка данных, ещё 10% коммуникация и анализ и 10% настройка моделей.

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

В новом бизнес-процессе распределение меняется ещё сильнее. Команда тратит время на поиск методики, эксперименты, консультации с экспертами и проверку результата.

Иногда исследование задачи оказывается сложнее самой автоматизации.

Новый процесс требует методики

Есть два разных сценария внедрения ИИ.

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

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

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

Затем методику переводят в промпты, инструкции, примеры и правила проверки.

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

Старый процесс переносится быстрее

Второй сценарий связан с уже работающим процессом.

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

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

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

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

Компания может знать, что хочет увеличить конверсию до 30%, но не понимать, какие действия приводят к такому результату. В этом случае сначала нужно найти методику. Одного целевого показателя для автоматизации недостаточно.

Инструкции для ИИ становятся частью процесса

ИИ работает устойчивее, когда получает не общее пожелание, а подробное описание методики.

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

Особенно полезно это для задач, которые специалист выполняет интуитивно.

Обратный промпт-инжиниринг

Метод позволяет восстановить скрытую логику по входным данным и готовому результату.

Возьмём работу HR с интервью. На входе есть описание вакансии, информация о компании, требования к кандидату и его будущие обязанности. На выходе находятся вопросы, которые HR задал на собеседовании.

Эти материалы можно передать модели с инструкцией:

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

Так можно получить первую версию методики. Затем её нужно проверить на новых примерах и показать опытному HR.

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

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

Что делать, если бизнес не понимает собственный процесс

Это одна из самых частых проблем на аудите.

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

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

Помогает и обратный промпт-инжиниринг. Он позволяет извлечь часть правил из уже выполненной работы.

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

Сотрудников нужно включать в проект

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

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

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

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

Иначе система может быть технически готова, но не войти в ежедневный процесс.

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

До начала проекта компания оценивает, сколько времени занимает задача и какой эффект даст автоматизация.

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

Затем прогноз сравнивается с фактом.

Если ожидалась экономия 40% времени, а фактическая экономия составила 25%, это не означает, что проект провалился. Возможно, сотрудники используют систему только на части процесса или тратят время на дополнительную проверку результата.

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

С чего начать первый проект

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

Затем провести небольшой R&D, проверить решение на ограниченном наборе данных и только после этого переходить к разработке.

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

Так внедрение ИИ превращается в управляемый проект. Компания понимает, какую задачу решает, что именно разрабатывается, кто отвечает за результат и как измеряется эффект.

AnthonyJuly 22