Почему мы начали работать с искусственным интеллектом
Я хочу поговорить о том, как измерять бизнес-эффекты при внедрении инструментов искусственного интеллекта и как трансформировать экспериментальный подход к внедрению в измеримую пользу.
Для начала – предпосылки, из-за которых мы обратились к теме искусственного интеллекта и решили, что она подходит для решения тех проблем, которые мы видели.
Мы запустили эти идеи в работу в конце 2024 года. Достаточно активным трендом на рынке был явный рост фонда оплаты труда специалистов, который фактически опережал рост рыночных ставок. Поскольку мы работаем на довольно конкурентном рынке, в явном виде следовать за этим ростом мы не могли. Задача была в том, чтобы найти способ оптимизации затрат на зарплату.
Когда говорят об искусственном интеллекте, на рынке есть два подхода: AI First и Human First. Я придерживаюсь Human First. Все задачи, которые мы решали, направлены на то, чтобы сохранять людей, оптимизируя их задачи: не сокращать людей за счет автоматизации, а повышать качество их работы.
Следующий тренд – бюрократизация процессов. Мы наблюдаем активное повышение требований к качеству документации на проектах. В силу развития организации требования ко внутренним документам также активно растут – и к качеству их подготовки, и к скорости.
Немаловажны и задачи смежных подразделений. Есть определенный набор задач, которые по функции должны выполнять не мы, но ответственность за их неисполнение или некачественное исполнение по факту несем напрямую мы. Когда я исчерпал инструменты убеждения, чтобы эти задачи решались так, как я считаю нужным, я понял, что мне все-таки необходимо решать их самому. Возвращаясь к первому тезису: просто увеличивать затраты на подобные задачи я себе позволить не могу.
Еще один немаловажный тренд преследует меня все время работы. Я считаю, что любые подобные задачи, которые находятся в фокусе внимания рынка и интересны специалистам, – это отличный инструмент нематериальной мотивации. Мы работаем на монорынке: конкретно мое подразделение в основном занимается продуктами 1С и определенными сферами. Когда ты занимаешься одним и тем же на протяжении долгого времени – а только долгая работа делает тебя экспертом, – это неизбежно приводит к эмоциональному выгоранию. Подобные инструменты и их внедрение в наши локальные процессы – хороший способ поддерживать интерес к сфере, которая активно развивается.
Бюрократия
Начнем с основного, базового слоя – набора бюрократических задач. Моей задачей как менеджера было добиться того, чтобы сотрудники – прежде всего эксперты – вместо работы руками работали головой. С одной стороны, самый дорогой набор их задач – мышление и когнитивные функции. С другой стороны, он самый эффективный: наши клиенты платят нам за компетенции сотрудников. При этом у нас огромное количество сопутствующих задач, где мы работаем не головой, а руками, просто ходим и общаемся, и это общение не всегда эффективно. Подобный набор задач хотелось сократить.
Я выделил три направления в рамках бюрократических задач, которые мы решали.
Первое – упаковка опыта: резюме как опыт конкретного специалиста, портфолио как опыт команды в целом, кейсы как опыт решения этой командой задач у клиентов и «Проект года» как инструмент упаковки кейсов для дальнейшего маркетинга.
Следующий блок – операционная документация: протоколы первичных и рабочих встреч, инструкции, различные списки задач, которые мы вынуждены фиксировать в порядке оперативной деятельности. Чем больше у нас такой операционной документации, тем, по опыту, легче решать задачи и, самое главное, разрешать споры.
Последний блок – результирующая документация: отчеты AS IS и TO BE, техническое задание, технический проект.
Приведенные примеры – не все, что мы делаем через инструменты GenAI, но это ключевое, на что, на мой взгляд, стоит обратить внимание.
Тестирование
Дальше начался процесс тестирования гипотез. Мы сформулировали примерно следующую идею: на самом деле у нас уже все есть. Наша задача заключается в том, чтобы переработать имеющиеся результаты в разные, так скажем, агрегатные состояния. О чем я говорю?
Если посмотреть на цепочку взаимосвязанных документов, становится понятно, почему я называю бюрократию базовым слоем. Мы занимаемся проектной деятельностью, а в рамках первых этапов работ используем классическую водопадную технику. У нас есть блоки обследования, моделирования и проектирования. По сути, это упакованный, приземленный на бумагу результат встреч с клиентами.
Если мы качественно провели первичную встречу и положили ее результат на бумагу в виде протокола, то получили основной объем информации, который в дальнейшем используем, например, для подготовки отчета AS IS. По сути, отчет AS IS – это описание бизнес-процессов, которое мы взяли из результатов первичных встреч. Далее можно взять это описание в виде текста и переработать в графическое представление. Сейчас мы тоже делаем это через инструменты искусственного интеллекта. Затем тот же набор данных перерабатываем в другом виде – в виде функциональных требований к системе.
Таким образом, взяв за фундамент встречи, мы прогоняем полученные данные через различные итерации и получаем разные виды документов. Ключевое в подходе с использованием больших языковых моделей – а в вопросах бюрократии мы в основном говорим именно о них – то, что он позволяет избавиться от непосредственной работы с текстом и оставить сотрудникам когнитивную функцию, в рамках которой они этот текст анализируют.
Следующий пример – тест-кейсы. Мы делаем отчет AS IS на базе первичных встреч. Далее проводим серию встреч, где вместе с клиентом прорабатываем, как процесс будет выглядеть в будущем, то есть TO BE. Эти встречи становятся основой для формирования тест-кейсов, которые мы будем использовать при написании ТЗ и документов по тестированию и которые станут основой для валидации системы при запуске.
Все это можно упаковать в некоторый набор результирующей документации. В итоге он даст нам систематические наблюдения о том, что происходит с процессами клиентов и на что можно обратить внимание с помощью генеративной модели. Она отлично анализирует тексты и на их массиве может давать пищу для размышлений.
Менеджмент
Поработав с задачами экспертов – в первую очередь мы шли от задач аналитиков, – мы довольно быстро поняли, что LLM – хороший инструмент не только для экспертов, но и для менеджмента.
Один из примеров – юридическая служба. Она у нас очень загружена, но при этом есть работа с типовыми договорами. На менеджмент в некотором смысле можно посмотреть как на работу с контекстом. Ровно так умеют работать LLM. Насколько я знаю, у многих на рынке юридическая служба довольно загружена, потому что ее задача – решать эскалационные вопросы, а на мелочи вроде проверки отдельных договоров времени не остается. Но, погрузив в модель определенный объем контекста из наших качественных типовых договоров, можно быстро сделать бота, который помогает выявлять явные риски в формулировках. Это полезно, потому что отдельные пункты договора мы часто меняем по согласованию с клиентами.
Следующий пример – task-менеджмент и операционный контроль. Деятельность устроена так, что мы используем мессенджеры, какие бы они ни были, и большое количество групп создает множество проблем с контролем операционных задач. Скриптовыми методами это решается плохо, потому что задачи далеко не всегда формулируются в явном виде. Сейчас у нас есть бот, который живет в группах, анализирует задачи по контексту и в конце каждого дня формирует их список. Руководитель проекта или подразделения может посмотреть, что происходит в группе и какие задачи необходимо взять на контроль.
Еще одно направление – использование открытой информации, которой сейчас полон мир. Мы используем ее при подготовке к первичным и рабочим встречам, чтобы повышать их качество, а в случае первичных встреч – напрямую влиять на конверсию.
Последний пункт – статистика. Этим словом я обозначаю барьер упаковки опыта, который регулярно встречаю у специалистов. По моим наблюдениям, специалисты не очень любят работать с документацией и считают ее неизбежным злом. Для меня как для менеджера это очень важная задача и с точки зрения контроля рисков, и с точки зрения дальнейшей трансляции опыта. Для клиента документация тоже довольно важна с точки зрения его собственных задач по представлению информации руководству.
Раньше добиться от специалиста описания того же кейса, чтобы использовать его в «Проекте года», было довольно сложно. Сейчас мы можем подготовить описание на основе разработанных промптов: например, взять переписку рабочей группы, направить набор документации, получить результат и отдать его специалисту на финальную вычитку. Такой подход работает гораздо лучше, чем просьба к специалисту изначально написать документацию с нуля.
Результаты
Теперь о результатах, то есть о бизнес-эффектах, которые можно измерить.
Ключевой на данный момент результат – сокращение затрат на ФОТ. Возвращаясь к тому, что я озвучивал в начале: под этим сокращением я подразумеваю не увольнение сотрудников, а то, что мы стали меньше тратить времени на обслуживающие функции, которые не являются для нас источником дохода. За счет этого то же время специалистов можно потратить, с одной стороны, на более выгодные для нас задачи, с другой – на более интересные для них.
В конкретных цифрах сокращение ФОТ составляет примерно 8 млн рублей в год. Это около 320 человеко-часов в месяц на задачах по документации. Мы считали показатель по таймшитам на одни и те же связанные с документацией разделы проектов на начало и конец периода.
Следующий результат – ускорение поставки за счет сокращения тестирования. Здесь стоит оговориться, что это произошло не только благодаря инструментам искусственного интеллекта, но и в целом благодаря автоматизации процессов разработки и тестирования. Однако ИИ тоже сыграл значимую роль. В среднем у нас было четыре итерации тестирования, и одну из них мы смогли сократить. Это привело примерно к двум неделям сокращения тестирования в разработке и одной неделе тестирования в ОПЭ. Я говорю «примерно», потому что детальной аналитики по подобным этапам у нас недостаточно: мы ориентируемся на собственные таймшиты.
Как следствие, увеличилось качество тестирования. Здесь я говорю о показателе возвращения из пользовательского тестирования обратно на доработку во внутреннее тестирование. Экономия составляет примерно 140 человеко-часов в месяц, или около 3 млн рублей.
Все это позволило быстрее выходить на SLA. По моим расчетам, мы смогли обеспечить дополнительный поток – плюс 2 млн рублей в год уже на непроектной выручке.
Мы также сократили сроки оценки работ. Этот показатель мне тяжело пересчитать в деньги, потому что он в первую очередь пресейловый: влияет на конверсию, но очень опосредованно. Раньше средний срок выдачи оценки работ составлял три-пять рабочих дней, сейчас – один-два рабочих дня. Целевой ориентир – выдавать любые оценки за один рабочий день. Эта задача пока в работе, но, думаю, в рамках этого года мы ее решим.
Последний пункт спорный с точки зрения результата: потребность в персонале сократилась примерно на пять вакансий в год. Все эти показатели применимы к масштабам моего подразделения. С одной стороны, это сокращение затрат на наем и адаптацию сотрудников. С другой стороны, сейчас у меня есть сложность с тем, как растить джунов. Как растить мидлов – понятно. Но раньше джуны выполняли те задачи, которые теперь мы отдали ИИ. На чем им теперь расти и как развиваться – очень сложный вопрос.
А что там с затратами?
Ранее я говорил о том, что подобные задачи – отличный инструмент нематериальной мотивации. Благодаря этому мне не приходится наращивать CAPEX на внедрение таких инструментов. Здесь хочется сказать большое спасибо сотрудникам моей команды за то, что они готовы внедрять эти инструменты, повышая качество нашей и моей работы и, как следствие, мой результат. Это подход, который позволяет дать экспертам интересную задачу, а менеджменту – не увеличивать затраты на обслуживание процессов.
У нас были минимальные затраты на развертывание дополнительного стека оборудования. Более или менее заметные расходы появляются только сейчас, когда мы масштабируем опыт подразделения на бизнес-юнит в целом с объемом выручки 3–4 млрд рублей. На этом уровне уже возникают затраты на инфраструктуру и часть затрат на интеграцию процессов. Но относительно бизнес-эффектов они тоже незначительны.
От протокола встречи до ТЗ: готовые инструменты для запуска GenAI
В качестве примеров оставил цепочку, о которой уже говорил и которая начинается со встречи. К статье прикреплен качественно отшлифованный промпт, который можно взять и загрузить в любую нейросеть. Логика простая: промпт плюс транскрибация встречи дают качественный протокол, который становится основой для той документации, о которой шла речь.
Для себя мы уже сделали инструмент, который работает по одной кнопке: отправляешь запись встречи и на выходе получаешь готовый финальный протокол.
Следующий пример – работа на базе ТЗ. К статье прикреплен шаблон ТЗ, который также можно взять за основу для работы с нейросетями. Сейчас, когда к нам приходит заказчик, который по логике должен сам написать ТЗ, чтобы разместить его на открытой или закрытой площадке для тендера, мы пишем ТЗ за него. Снимаем минимальный первичный запрос на реализацию и через набор промптов выдаем финальную версию ТЗ. В рамках этой работы также обсуждаем критерии, которые будут интересны нам для повышения вероятности победы.
Кроме того, к статье прикреплен базовый чек-лист по запуску инструментов на базе GenAI: как выбрать процессы, на что обратить внимание, как подойти к безопасности данных и как оценивать эффект. Этот чек-лист можно использовать как отправную точку для запуска подобных инструментов.
Управление изменениями
Отдельно хочется обратить внимание на блок по управлению изменениями. Я вижу и готовность работать с инструментами, и широкий набор самих инструментов. Но когда сталкиваюсь с их масштабированием, возникает большое количество сопротивления. Мне кажется, что мы придаем ему слишком много значения.
Пока у меня родилась гипотеза, что преодолевать это сопротивление можно через презентацию бизнес-эффектов. Когда люди видят, какой именно результат может принести внедрение инструментов искусственного интеллекта, они начинают больше им доверять. В других статьях говорили и о базовых инструментах вроде живого общения и конкретных экспериментов вместе с сотрудником. Это тоже хорошо работает. На изображении я хотел обратить внимание на то, что ограничениям, которые мы видим, на мой взгляд, уделяется слишком много внимания и, возможно, это не всегда оправданно.
Будущее уже здесь. Если кажется, что мы к нему не готовы, начинать готовиться нужно прямо сейчас. Как известно, лучший момент посадить дерево был 20 лет назад. Второй лучший момент – сейчас. ИИ активно входит в нашу жизнь, и нам нужно научиться с ним взаимодействовать.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
