Антон Слученков, ПЭК: Искусственный интеллект как надстройка над бизнес-процессами

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

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

Условия для внедрения ИИ

Запуск проектов в области искусственного интеллекта не должен быть самоцелью или разовым пилотным экспериментом. К моменту начала этой работы в нашем распоряжении уже была сложившаяся IT-инфраструктура и значительный массив отчётности – 2600 отчётов Power BI, из которых 600 относятся к категории регулярно используемых на всех уровнях управления.

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

Искусственный интеллект следует рассматривать не как обособленный слой, а как надстройку, интегрированную поверх существующих систем. Аналогично тому, как решение «1С:Управление холдингом» объединяет данные из различных контуров, ИИ не должен существовать в отдельном периметре. Его место – над вашей текущей IT-инфраструктурой.

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

Организация процесса в компании ПЭК

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

Сам по себе пилот – это короткая демонстрация уже работающей функции. Моя коммуникация строится вокруг поиска бизнес-лидера: кому это реально интересно? Функция попадает в платформу, только когда лидер находится. Если лидера нет – продолжать бессмысленно, идём дальше.

Основные барьеры

В процессе внедрения выделяются несколько типовых препятствий.

Архитектура и эволюция данных

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

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

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

В компании функционирует множество источников: системы 1С, Confluence, JIRA, телефония, электронная почта. Существует платформа данных и BI-контур. Поверх всех этих компонентов мы развернули ИИ-надстройку. Наша внутренняя нейросеть с интерфейсом, получившая имя Leo, через MCP-серверы взаимодействует со слоями DWH, почтовой системой, Confluence и другими массивами. Пользователь формулирует запрос естественным языком и получает структурированный ответ.

Кейс 1: замещение множества отчётов чат-ботом

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

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

Некоторые коллеги выражали сомнение: не приводит ли обилие отчётов к их дублированию и потере управляемости? Наш опыт опровергает это опасение. Ни одного дублирующего отчёта в компании нет. 600 метрик – каждая из них имеет самостоятельную ценность. Общее количество отчётов достигает 2600, дополнительно существуют 80 Olap-кубов и ad-hoc-запросы. Топ-менеджмент использует около полутора десятков специализированных отчётов, но отчётная система охватывает все уровни управления. Например, кладовщик может обратиться с запросом: «Покажи мою выработку». Система Leo предоставит информацию исключительно о его индивидуальных показателях и заработной плате – это соответствует настройкам ролевой модели. Мы перенесли ролевую модель из традиционных отчётов в ИИ-интерфейс. То, что ранее работало в BI-контуре, теперь функционирует в ИИ-контуре.

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

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

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

Кейс 2: аналитика аудиоданных

В компании функционирует крупный колл-центр, обрабатывающий десятки тысяч звонков ежедневно. Подавляющее большинство запросов (9 из 10) типовые: «Где находится мой груз?», «Когда ожидать доставку?», «По какой причине задержана отгрузка?». Ранее выборочный контроль звонков осуществляла система качества: выявлялись случаи нарушения скриптов и некорректного общения с клиентами, предпринимались попытки извлечения бизнес-инсайтов.

В настоящее время подход трансформировался. Поступают запросы совершенно иного характера: «Какую обратную связь дают клиенты о направлении FTL (полные грузовые отправки)?», «Какие клиенты обращались по данному направлению, но получили отказ, и по какой причине?»

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

В настоящий момент тематика звонков определяется автоматически.

Переход от множества показателей к единому проблемному маркеру

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

Бюджетирование и работа с внешними сервисами

Мы выбрали путь развёртывания собственной LLM внутри корпоративного контура – той самой системы Leo. В эту систему можно без опасений загружать данные, поскольку они не покидают внутренний периметр. Нейросеть практически не способна раскрыть индивидуальную заработную плату конкретного сотрудника. С наибольшей вероятностью она оперирует среднеотраслевыми показателями. Можно утверждать, что персональные данные остаются защищёнными с вероятностью, близкой к 100%.

Роль владельца процесса

У каждого процесса должен быть назначен ответственный владелец – представитель бизнеса, который действительно заинтересован в изменениях. Это не должен быть специалист по внедрению или IT-отдел. Это человек, который стремится к повышению эффективности и сокращению рутинной работы. Вы демонстрируете ему возможности: «Мы можем облегчить вашу деятельность, оптимизировать работу колл-центра». Заинтересованный руководитель отвечает: «Давайте попробуем» – и становится движущей силой преобразований.

Реализация без разрушения существующей инфраструктуры

Базовая схема внедрения включает три компонента: наличие формализованного процесса, лидера (владельца) и технической основы.

После получения первого успешного результата решение масштабируется на всю компанию.

Типичные ошибки при внедрении

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

Мы реализовали иной подход. Интеграция построена по принципу: есть формализованные процессы, структурированные данные, понятные роли и мотивы участников. Эта схема работает при условии корректной подачи данных и объяснения их назначения.

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

Технические аспекты: сбор данных, эксперименты с моделями и организация работы

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

В рамках экспериментов с открытыми моделями мы работали с Gemma, Qwen и ChatGPT OSS. В последнее время наиболее пристальное внимание уделяется Qwen 3.6 – мультимодальной модели, выпущенной в самое недавнее время. До этого мы использовали Gemma, а ещё ранее – gpt-oss-120b.

В качестве примера: мы подключили справочно-правовую систему «Гарант». Туда направляются документы, оттуда получается релевантная юридическая практика, после чего модели даётся инструкция: «Используй исключительно данные, возвращённые системой "Гарант"». В таком сценарии Qwen демонстрирует точность 8 из 10 ответов. Этого пока недостаточно для промышленной эксплуатации, поскольку проигрыш судебного дела из-за двух ошибочных ответов может нанести значительный ущерб. При достижении точности 9 из 10 мы введём дополнительный контроль силами одного сотрудника и сможем заявить о полноценном промышленном решении. Показатель 8 из 10 – это уже работающий инструмент, но требующий контроля.

Данные не накапливаются в отдельном хранилище. Доступ осуществляется исключительно через MCP-сервер. У нас существует BI-контур, куда стекается информация из 80 различных систем: 1С, Confluence, JIRA, телефония и другие. Вся эта информация объединена. Поверх этого контура ИИ через MCP-сервер запрашивает необходимые данные. Пользователь задаёт промпт, модель определяет целевой источник, генерирует SQL-код, извлекает данные и выдаёт ответ.

Например, сотрудник хочет получать ответы на вопросы, под которые ещё не написан скрипт. Моя задача – не достраивать DWH, а просто работать с промптом и MCP-сервером. Приводился показательный случай: я задал запрос «покажите отклонение текущей недели от прошлой». ИИ выдал результат: падение на 40%. При открытии традиционного отчёта выяснилось, что показатели улучшились. Анализ реальных данных показал, что модель просто сравнила сумму текущей неполной недели с полной суммой прошлой недели. После этого было добавлено правило в схему: при отсутствии дополнительного контекста сравнивать только выполненные дни текущей недели с соответствующими днями прошлой недели. Такая настройка на основе реальных данных позволила получать корректные ответы. Без предварительного анализа данных и добавления правил результат модели был бы ошибочным.

Данные хранятся в BI-слое, на их основе строятся отчёты. Интерфейс – это, по сути, промпты. Промпты могут генерироваться с помощью ChatGPT, DeepSeek и других инструментов.

В компании работает четыре специалиста, непосредственно отвечающих за внедрение ИИ. Первый отвечает за фронтальную часть: корректное распознавание PDF-файлов, удобство интерфейса. Второй специализируется на телефонии и извлечении инсайтов – на запросах типа «предоставьте информацию о деятельности компании в целом». Третий отвечает за работу с базами данных – векторной и графовой. Руководитель направления курирует весь комплекс задач: тестирование LLM, контроль корректности ответов, написание промптов.

Моя роль заключается в координации и инициации. Пилотный проект MCP-надстройки был реализован мной лично для демонстрации потенциала: «Обратите внимание на эту технологию». Это была не промышленная система, а прототип с несколькими примерами: «вот вопрос – вот ответ». После получения запросов от бизнеса я передал дальнейшую реализацию команде.

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

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

Антон Слученков, директор департамента разработки и визуализации данных, ПЭК