Меню
Журнал TimLabs

Как поставить бизнес-цель перед автоматизацией

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

Какую работу вы хотите изменить

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

В документе NIST AI RMF 1.0 постановка задачи связана с назначением системы: раздел MAP 1.3 требует описать цели, MAP 1.4 — деловой контекст, а MAP 3.3 — область применения. Это рекомендации по управлению рисками ИИ, а не свидетельство, что выбранная автоматизация окупится.

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

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

Сначала посмотрите, что происходит сейчас

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

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

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

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

Соберите карточку пробного процесса

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

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

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

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

Чем подтвердить результат

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

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

В NIST AI RMF раздел MANAGE 1.1 предлагает определять, достигает ли система заявленного назначения, и учитывать это при решении о продолжении разработки или внедрения. Я применяю эту логику к пробе: решение должно опираться на её задачу, а не на число запусков.

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

Когда расширять задачу, а когда остановиться

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

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

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

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

Что оставить в рабочем документе

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

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

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

Источники

  1. NIST AI RMF 1.0 — Core, MAP and MANAGE

Частые вопросы

Можно ли начать без точного процента экономии?

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

Что считать первым результатом?

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

Нужно ли сразу разрешать отправку сообщений?

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

Подобрать мастера за минуту

Отметьте, что вам сейчас нужно, — посоветую специалиста или практику, которые знаю сам.

Что важно сейчас?
Формат
Когда
Ответы не сохраняются на сайте: они только складываются в текст сообщения, и вы сами решаете, отправлять ли его. Не указывайте диагнозы и сведения о здоровье. Подробнее — в политике обработки данных. Практики мастеров носят велнес-характер и не являются медицинской помощью.

Проверьте одно обращение

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

📬 Новые статьи журнала «Компас» — в Telegram-канале Подписаться

Материал носит информационный характер. Актуальность деталей уточняйте самостоятельно.

Поддержать проект