За последний год российский бизнес заметно оживился в плане интереса к CRM и ERP с ИИ-функционалом. Цифры говорят сами за себя. Запросов по «Битрикс24 ИИ» стало в семь раз больше, по «CRM с нейросетью» — в 6,5 раза, а «ИИ в 1С» подрос на 85%. Вроде бы все хотят, но реальность чуть скромнее. Согласно данным «СберАналитики» и «Сбер Бизнес Софт», 39% компаний уже пилотируют или используют ИИ-ассистентов в документообороте, финансах и кадрах. А вот к ERP-системам умные алгоритмы пока только подбираются — в основном в виде обособленных сателлитов, которые просто стыкуются с основной системой по API. Почему так происходит и как правильно заводить ИИ в уже сложившиеся контуры корпоративных систем разбирает Илья Бычков, директор направления разработки практики 1С компании «Рексофт».

Ажиотаж есть, массовости нет

Российский ERP-рынок по итогам прошлого года оценивается примерно в 100 млрд рублей, и он продолжает расти. Спрос от клиентов на интеграцию ИИ внутри этих систем есть. Но если посмотреть на реальные внедрения, то картина выходит довольно пестрая.  Единицы по-настоящему используют нейросети внутри своего управленческого ядра, пока что мы видим скорее отдельные ИИ-сервисы, которые подключаются снаружи через API. И прежде чем стартовать внедрение (а хочется быстро взять Open Source модель, настроить и сделать красивый проект хочется всем ИТ-подразделением), компаниям стоило бы остановиться и ответить себе на пару важных вопросов.

Где в нашем контуре нейросети реально могут выстрелить?

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

Что же реально сделать за месяц? Развернуть внутри компании локальные модели и построить на них распознавание документов. Хороший вариант для такого проекта  — коммерческие предложения от поставщиков. Они приходят в закупки постоянным потоком, в произвольных форматах — PDF, сканы, письма, — и их содержимое во многих компаниях сотрудники до сих пор перебивают в систему руками. При этом наружу такие документы отдавать нельзя — это коммерческая тайна, поэтому обработка должна идти строго внутри контура. Моя команда собирает такой проект примерно за месяц. Первую неделю занимает развертывание оборудования и открытых моделей в контуре заказчика, вторая посвящена настройке конвейера распознавания и извлечения ключевых полей (поставщик, номенклатура, цены, сроки, условия поставки; оставшееся время). Здесь идет интеграция по API с учетной системой на базе 1С и донастройка на реальных документах компании. На выходе закупщик получает не стопку PDF, а структурированные данные и готовую сравнительную таблицу предложений. В систему они попадают черновиком, который подтверждает человек. Ключевое здесь то, что модели не обучаются с нуля, берутся зрелые открытые модели и настраиваются под форматы документов конкретной компании. Именно поэтому счет идет на недели, а не на годы.

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

Отдельная история — ИТ-поддержка. Там ИИ может разгрузить сотрудников, беря на себя классификацию обращений, маршрутизировать их куда надо, подсказывать следующие шаги менеджерам в CRM, а в Service Desk — набрасывать черновики ответов, чтобы сотрудникам оставалось проверить, подкорректировать и отправить. С письмами, коммерческими предложениями и документацией та же схема — драфты генерируются за секунды. Дополню список ИИ функционала помощью разработчикам - автодополнение кода, разбор логов, внутренний ИИ- Service Desk для техподдержки. Главное не заниматься внедрением сразу всего, а идти от проекта к проекту.

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

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

Первый — экономика самой задачи. Важен не объем документов сам по себе, а произведение объема на трудоемкость одной операции: тысячи однотипных накладных — или сотни сложных документов вроде коммерческих предложений, на каждое из которых закупщик тратит десятки минут. Дальше нужно оценить возможную точность. Для распознавания первички рабочий уровень корректного распознавания с помощью ИИ - 85–95%. Довести его до абсолюта невозможно, поэтому процесс должен учитывать проверку человеком. По моему опыту экономика сходится, когда на ручную верификацию уходит 10–20% результатов, а не каждый второй ответ. Также принципиальна проверяемость результата. Выгода есть там, где проверить ответ модели значительно дешевле, чем выполнить работу самому. Черновик письма человек вычитывает за минуту. Если же проверка равносильна выполнению заново, ИИ ничего не экономит.

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

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

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

Менять всё или точечно апгрейдить

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

При таком раскладе вы попросту выбрасываете годы тонкой настройки процессов, выстроенных интеграций, накопленных данных и, что немаловажно, доверия пользователей, которые уже привыкли работать в этой системе. Сам по себе ИИ почти никогда не стоит того, чтобы менять из-за него всё с нуля. Коробочные AI-решения, как правило, довольно универсальны и слабо учитывают специфику именно вашего предприятия, ваши данные и ваши бизнес-процессы. Данные всё равно придётся перетаскивать, процессы — перенастраивать, а людей — переучивать заново. Полная замена оправдана только в исключительных случаях. Например, если система окончательно зашла в тупик и её развитие невозможно, если вендор ушёл с рынка и поддерживать стек больше некому, или если технологическая платформа откровенно мертва. Во всех остальных ситуациях гораздо разумнее достраивать. Брать проверенные, зрелые компоненты (те же сервисы 1С, GigaChat, YandexGPT) и аккуратно «вшивать» их в существующий контур, затачивая под свои бизнес-задачи.

Главное правило: не навреди

Ключевой принцип при внедрении ИИ в корпоративную рутину — все интеллектуальные модули подключаются как изолированный внешний сервис. Модель может дать сбой, выдать ерунду или вообще «упасть». При этом основная система должна продолжать работать в прежнем режиме. Обязательно нужен резервный план на случай отказа ИИ, и в критических действиях в цепочке должна быть обеспечена проверка человеком. Особенно это касается всего, что связано с цифрами. Генеративные модели по своей природе вероятностны, и они могут ошибаться, причём очень правдоподобно, так что неспециалист и не заметит. Если ИИ допустил промах в черновике письма или в кратком пересказе — беда небольшая, человек быстро поправит. А если ИИ ошибется в бухгалтерской проводке или в налоговом регистре — последствия могут быть уже совсем нешуточными, вплоть до проблем с ФНС и СФР. Именно поэтому в регламентированном учёте ИИ выступает только как ассистент. Он распознаёт, подсказывает, заполняет черновик, но итоговый документ формирует уже проверенный механизм системы, а критическое действие обязательно подтверждается сотрудником. Кроме того, каждое действие модели должно быть полностью отслеживаемым — какая версия модели использовалась, на каких данных она обучалась, кто утвердил результат. Иначе аудитор не сможет восстановить, откуда взялась та или иная цифра. ИИ подготавливает данные, но ответственность за них несёт человек и система.

Защита

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

Периметром, впрочем, защита не исчерпывается. У генеративных моделей есть специфические риски, которые нужно закрывать отдельно. Например, утечки через запросы. Сотрудник может скопировать в промпт конфиденциальный документ, поэтому обращения к внешним моделям фильтруются, а чувствительные сценарии переводятся на модель внутри контура. Нужно последовательно заниматься внедрением инструкций по работе с ИИ. Вредоносный текст в обрабатываемом документе или письме может «перехватить» управление моделью, поэтому входящие данные очищаются, а права сервиса ограничиваются так, чтобы даже скомпрометированный ответ не привел к необратимым действиям. Еще один блок предстоящих работ – верификация базы знаний. Если ассистент опирается на корпоративную вики, одна ошибка в ней тиражируется во все ответы. Источники должны проходить контроль и версионироваться. Обновление модели: новая версия может незаметно изменить поведение, поэтому версии фиксируются, а перед переключением прогоняется набор контрольных задач. Наконец, нужно учесть вопрос зависимость от поставщика. Архитектура должна позволять заменить модель без переделки интеграций — это еще один аргумент в пользу изолированного сервисного слоя. И после запуска ИИ в продуктив работа не заканчивается. Доля ошибок, объем ручных доработок и время отклика отслеживаются постоянно, как у любого промышленного сервиса.

Советы для ИТ-директоров на старте проекта

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

Модель расчета не так сложна, как кажется. На стороне затрат пять статей. Лицензии или подписка на модель, инфраструктура (для развертывания в своем контуре — серверы с GPU), интеграция с учетной системой, подготовка данных, а также сопровождение — мониторинг качества, дообучение и время сотрудников, проверяющих результаты. На стороне эффекта — высвобожденные часы персонала, ускорение процессов и снижение потерь от ошибок ручного ввода. Дальше идет стандартный расчет окупаемости, который ИТ-директор делает для любого проекта. Почему ИИ может оказаться дешевле классической автоматизации? Классический подход требует заранее формализовать все правила, а на неструктурированных данных — сканах, письмах, логах — это либо невозможно, либо запредельно дорого. Готовая модель снимает именно этот барьер. Но верно и обратное. Если задача хорошо алгоритмизируется, обычная автоматизация будет дешевле и предсказуемее. Поэтому честный расчет экономики нужен до старта, а не после.

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

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

Автор: Илья Бычков, директор направления разработки практики 1С компании «Рексофт».

Источник: IT World.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.