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

На дашборде такого ответа может не быть. Он показывает заранее выбранные метрики, а новый виджет ради одной проверки никто не станет проектировать, согласовывать и поддерживать. Можно открыть 1С, найти документ, сверить реквизиты, потом вернуться в рабочее место. Если вопрос возникает редко, этот путь кажется терпимым — пока таких редких вопросов не становится много.

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

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

Что вообще такое дашборд

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

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

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

• подтверждена ли оплата по определённому договору;

• какие реквизиты указаны у конкретного контрагента;

• до какой даты сотрудник находится в отпуске;

• есть ли остаток по нужному счёту на текущий момент;

• совпадает ли статус документа в 1С со статусом задачи в процессе;

• почему сумма в заявке отличается от суммы, проведённой в учётной системе.

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

Поэтому мы не рассматриваем агента как замену BI. У дашбордов и агента разные зоны применения.

Такой подход близок к тому, как развивается рынок аналитики. SAP развивает Joule Agents, Databricks — Genie, ThoughtSpot — Spotter, Tableau — Pulse. Общая идея у этих продуктов похожая: человек должен иметь возможность спросить о данных обычным языком, не дожидаясь появления нового отчёта.

Почему чат-бот не решает проблему ответов на вопросы

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

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

Он задаёт в рабочем месте вопрос: 

Оплата по счёту № 154 от 3 сентября прошла? Какая сумма отражена в 1С?

Чтобы дать полезный ответ, агенту нужно знать, как обычно устроены платежи, а также текущие данные конкретной базы: реквизиты документа, статус, дата проведения, сумма, а иногда и связанный договор или контрагент. Далее агент определяет, какие сведения нужны для ответа, и вызывает инструмент доступа к 1С. В нашем случае это read-only-коннектор, который позволяет получить данные и вернуть их в процессное рабочее место.

Ответ может выглядеть так:

По данным 1С оплата по счёту № 154 отражена 5 сентября. Сумма — 248 000 рублей.

В задаче указана сумма 250 000 рублей: есть расхождение в 2 000 рублей, его стоит уточнить до закрытия задачи.

Важная часть такого ответа — прослеживаемость. Пользователь должен видеть, что сведения получены из конкретного запроса к 1С, а не придуманы моделью на основе похожих примеров.

Почему нельзя полагаться на память модели

Большая языковая модель хорошо формулирует ответы, умеет работать с неструктурированным контекстом и помогает выбрать следующий шаг. Но она не знает, как именно устроена конкретная конфигурация 1С у конкретной компании. Тем более она не знает, какие остатки были на счёте сегодня утром и как изменился статус документа несколько минут назад.

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

• общие знания о предметной области;

• документацию по системе;

• информацию из предыдущего контекста;

• правдоподобное предположение.

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

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

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

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

Как агент работает с 1С

1С — не единая стандартная схема данных, которую можно однажды описать и применять везде. Конфигурации различаются, содержат сотни и тысячи объектов: справочники, документы, регистры сведений, регистры накопления, отчёты и отраслевые доработки.

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

Коннектор получает метаданные 1С динамически. Агент работает не с жёстко зашитым набором полей, а с актуальным каталогом объектов конкретной конфигурации. Это позволяет постепенно добавлять сценарии и не привязывать всю систему к одной версии учётного контура.

Сейчас в числе поддерживаемых сценариев есть:

• поиск карточки контрагента;

• проверка договоров и реквизитов;

• поиск документа по идентификатору;

• проверка статуса платежа;

• получение расчётного листка;

• запросы к регистрам, например для проверки остатка.

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

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

Как агент работает внутри процесса

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

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

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

Например, агент может сообщить:

В 1С платёж проведён на 248 000 рублей, а в карточке задачи указано 250 000 рублей.

По данным процесса задача находится на этапе «Ожидание оплаты». Возможно, нужно скорректировать сумму или обновить статус.

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

Доступ на чтение — часть проектного решения

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

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

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

Не менее важны права доступа. В 1С агент ходит под отдельной учётной записью с ограниченными правами на чтение, а доступ к самому агенту управляется на стороне «Первой Формы». То же правило действует и для источников под ответом: нельзя показать в доказательстве сведения, которые пользователь не имеет права открыть самостоятельно.

Такой подход отвечает на частую критику наивного text-to-SQL: недостаточно научить модель строить запросы. Нужно заранее определить, какие действия ей доступны, какие данные она может вернуть и как пользователь проверит результат.

Происхождение ответа

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

Упрощённо механизм выглядит так:

Вопрос пользователя

↓

Агент выбирает инструмент

↓

Read-only-запрос к 1С

↓

Результат сохраняется в контексте выполнения

↓

Агент формирует ответ

↓

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

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

Такой механизм не стоит путать с самопроверкой модели. Мы не просим одну генерацию проверить другую генерацию. Ограничение заложено в архитектуру: происхождение источника формируется вне модели.

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

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

Что остаётся за дашбордами и отчётами

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

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

Мы считаем, что это нормальные ограничения. ИИ экономит время, но пока эта технология не всесильна.

Заключение

Дашборды хорошо отвечают на частые и заранее известные вопросы. Они остаются важной частью работы с данными. Но для вопросов вроде «Прошла ли эта оплата?», «Какой остаток сейчас?» и «Почему сумма в задаче не совпадает с 1С?» отдельный отчёт не создашь, и тут помогает ИИ-ассистент. Он находит актуальные сведения в пределах выданных ему прав, объясняет их в контексте процесса и показывает, на какие факты опирается ответ.

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

Делитесь в комментариях, используете ли вы ИИ для поиска в корпоративных данных и как у вас это устроено?