Александр Бессарабенко, Systeme Electric: «Не каждую задачу нужно решать с помощью ИИ»

Александр Бессарабенко, руководитель цифровых проектов, Systeme Electric, и спикер Конференции «Операционная эффективность», рассказал CFO Russia, как управлять портфелем инициатив и честно считать выгоду.

Какие критерии вы использовали, чтобы из 30 пилотов выбрать именно те 6, которые пошли в продуктив? Как выстроен процесс оценки инициатив: кто участвует, какие метрики считаются ключевыми?

На входе у нас было более 100 идей. После первичного отбора около 30 инициатив дошли до стадии пилотирования. Сейчас 6 решений уже вышли в продуктив, ещё 5 находятся в активной разработке, остальные – в бэклоге в соответствии с приоритетами. Такая работа с портфелем быстро показала, что нужен единый подход к оценке и приоритизации. Мы перестали смотреть только на технологическую привлекательность идеи и начали проверять, действительно ли здесь нужен ИИ и какой бизнес-эффект он даст.

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

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

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

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

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

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

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

Смотрим на несколько показателей: экономический эффект, качество извлечения информации, скорость обработки, SLA по исключениям и долю случаев, когда сотруднику приходится исправлять результат ИИ. По touch rate наша целевая планка – не более 20%.

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

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

Мы не пытаемся выбирать между быстрыми и долгосрочными проектами. Для этого держим портфель с разными горизонтами – 3, 6 и 12 месяцев.

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

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

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

Сейчас ориентируемся примерно на 70% быстрых и среднесрочных инициатив и 30% долгосрочных. Это не жёсткая формула – портфель регулярно пересматриваем в зависимости от результатов и приоритетов бизнеса.

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

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

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

Какие уроки из этого полугодового опыта вы считаете наиболее ценными для других компаний, начинающих управлять портфелем ИИ-проектов?

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

Первое – данные нужно проверять раньше, чем модель.

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

Второе – мы недооценили объём работы с промптами.

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

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

Третье – не стоит привязываться к одной модели.

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

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

Четвёртое – о масштабировании нужно думать ещё до запуска пилота.

Быстрый и дешёвый пилот действительно нужен, но, если изначально не думать о дальнейшем использовании, можно получить набор отдельных решений, которые потом сложно объединить.

Мы стараемся сразу задавать вопрос: «Что произойдёт, если этим завтра будут пользоваться не 20 человек, а 200?» Это помогает принимать архитектурные решения ещё до того, как решение станет критичным для бизнеса.

Пятое – технология без пользователей результата не даст.

За полгода число пользователей ИИ в закрытом контуре у нас выросло в два раза. Но сам по себе рост пользователей ещё не означает рост эффективности.

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

Шестое – экономику нужно фиксировать до запуска.

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

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

И ещё один вывод – не каждую задачу нужно решать с помощью ИИ. По итогам пилотирования мы убедились, что для части задач эффективнее использовать классические инструменты – low-code, программирование и другие способы автоматизации. Это важно учитывать ещё на этапе оценки инициативы: не всякая задача становится лучше от добавления ИИ. Иногда более простое решение оказывается быстрее, дешевле и надёжнее.

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

Задать свои вопросы Александру и узнать больше об опыте Systeme Electric вы сможете на Конференции «Операционная эффективность», которая состоится 7 октября 2026 года.

Елизавета Гета