Почему искусственный интеллект не приносит пользы команде

В российских компаниях повсеместно используются генеративные технологии. Вот только есть большая разница между «мы внедрили инструменты искусственного интеллекта» и «мы получили полезный результат». Как понять – вы просто продлеваете подписку на нейросеть или получаете реальный эффект для бизнеса?

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

Представим обычное рабочее совещание. Коммерческий директор объясняет: «Мне нужна кнопка «Подготовить предложение». Менеджер нажал, получил документ, отправил клиенту. Что там делать-то?». Через сорок минут он уже знает, что у компании сложная архитектура, исторические ограничения и высокая загрузка команды из-за технического долга. Кнопка, конечно, от этого не появляется, зато стало гораздо понятнее, почему ее отсутствие – результат серьезной и кропотливой работы.

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

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

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

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

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

Поэтому предварительная аналитика, прототипирование и согласования имеют вполне понятный экономический смысл. Они помогают не начинать дорогую работу до появления достаточной определенности. Но бывает и так, что заказчик действительно не может заранее сформулировать решение: ему необходимо увидеть вариант и обнаружить, почему тот не подходит. Фраза «покажите что-нибудь, а я скажу, что не так» раздражает исполнителя, но иногда довольно точно описывает видение клиента.

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

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

Когда подписка на ИИ-сервисы не заменит компетенции специалистов

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

Можно нанять подрядчика с почасовой оплатой. Однако исполнителя все равно нужно найти, объяснить задачу и передать контекст. «Там буквально на полчаса посмотреть», – говорит заказчик. Спустя две встречи выясняется, куда смотреть, а заодно, что нужен другой специалист. Никто не бездельничал, но стоимость получаса уже заметно выросла.

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

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

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

Как быстрая технология замедляет процессы

Возьмем условный процесс подготовки коммерческого предложения. Документ делают 4 часа, еще 36 часов занимают ожидание информации и согласований. Весь цикл составляет 40 часов. Допустим, ИИ сокращает подготовку до получаса, но остальные этапы остаются прежними. Значит ли это, что операция ускорилась в восемь раз? Нет, потому что клиент получит предложение через 36,5 часа вместо 40 – полный цикл сократился примерно на 9%. Это тоже хороший результат, но клиент вряд ли разделит восторг. Он просто ждал предложение.

Чтобы получить больший эффект, придется разбираться с оставшимся временем:

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

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

Именно поэтому я рекомендую разделять два вопроса:

• Что стало дешевле производить?
• Что компания смогла сделать благодаря этому?

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

Почему важно сомневаться в результатах ИИ

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

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

• Почему вы считаете, что клиенту это нужно?
• Кто будет выполнять обещанное?
• Что произойдет с текущим обслуживанием?
• Нельзя ли решить задачу без нового продукта, отдела, информационной системы?

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

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

Что делать, чтобы ИИ создавал реальный результат

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

1. Опишите процесс как очередь задач

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

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

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

2. Проверьте, ту ли задачу вы собрались ускорять

Перед автоматизацией каждого этапа спросите: что случится, если мы перестанем его выполнять? Например, еженедельный отчет давно аккуратно собирают и рассылают, но на вопрос «какое решение вы по нему приняли в последний раз?» наступает небольшая пауза. Возможно, отчет нужен реже, другому получателю или в другом виде. Ускорять его подготовку стоит после этого разговора, а не вместо него.

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

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

3. Назначьте владельца результата, дайте ему полномочия

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

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

Договоритесь и о жизни после пилота: кто обновляет правила, следит за качеством, разбирает исключения и оплачивает сопровождение. Здесь полезно назвать людей и выделенное время, а не только подразделения. Ответ «после запуска разберемся» означает, что запуск пока спроектирован лучше, чем дальнейшая работа. Подрядчик покажет результат, рабочая группа разойдется, а клиентские запросы на этом почему-то не закончатся.

4. Определите самостоятельность системы

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

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

Одновременно придется собрать контекст: действующие правила, исключения, ограничения, ответственных за спорные случаи. И привести в порядок сведения для выбранного процесса. Если в папке лежат «Прайс_финальный», «Прайс_новый» и «Этот_отправляем», модель не должна угадывать, какой файл пережил последнее совещание. Человек, кстати, тоже.

5. Объясните, во что превратятся сэкономленные часы работы

До запуска договоритесь, какой результат должна дать экономия:

• Менеджеры обработают больше запросов?
• Команда справится с ростом нагрузки без дополнительного найма?
• Уменьшатся переработки, расходы на подрядчиков или число потерянных сделок?

Это разные цели. Утверждение «сотрудники станут эффективнее» приятно произносить, но трудно использовать при проверке результата.

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

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

6. Разрешите пилоту оказаться неудачным

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

Проверяйте обычный поток работы, включая неудобные случаи. Три удачно выбранных примера доказывают, прежде всего, способность выбрать три удачных примера. Если опытный сотрудник по вечерам исправляет результаты модели, его труд тоже необходимо включить в расчет. Фраза «система работает автоматически, просто Марина потом немного проверяет» особенно интересна, если спросить саму Марину, сколько занимает это «немного».

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

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

Выводы

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

Также читайте: