ERP Preflight
Проверял одну гипотезу: можно ли снаружи, только на чтении, увидеть признаки того, что ИИ-агент на системе SAP будет ошибаться. Прототип отработал на учебной системе SAP. На боевом ландшафте не проверен — и до него есть чего решить. Дальше нужна ваша практика: семь вопросов в конце.
1. Гипотеза и рынок
Компания, собирающаяся посадить агента на свою ERP, не знает, готова ли к этому её система и её данные. Признаки неготовности видны снаружи, на чтении, через опубликованные интерфейсы. За такой вывод заплатят.
У SAP объявлены продукты почти на все смежные ниши: Knowledge Graph, agent mining в Signavio, AI Agent Hub. Ни одного — на вопрос «пригодны ли данные конкретного заказчика для того, чтобы агент на них действовал».
- 44 %называют качество и интеграцию данных барьером №1 при внедрении ИИ (IDC)
- 0партнёрских агентов на витрине SAP Store из 3159 карточек — все 8 агентских позиций у самой SAP
2. Дизайн теста
Три признака «система не готова к агенту», которые видны снаружи на чтении:
| Признак | Что это значит для агента |
|---|---|
| Тихая неполнота выдачи | Интерфейс отдал часть данных и не сообщил об этом. Агент думает, что прочитал всё. |
| Права как ложная уверенность | Учётка агента видит не то, что он предполагает. «Этого нет» неотличимо от «мне не показали». |
| Пустота там, где агент решает | Поле, на которое агент опирается, фактически не заполнено. |
Два условия, заданных до начала: только чтение — ни одной операции записи в систему заказчика; последовательность вызовов определяет код, а не языковая модель — иначе это попадает под ограничения политики API SAP.
3. Что построили
Инструмент читает опубликованные интерфейсы OData: каталог сервисов → описание интерфейса → записи. Три проверки поверх. На выходе — светофор по объектам и под ним список «здесь агент ошибётся, потому что…» с числами. Python, без внешних зависимостей.
4. Что прогнали и что получили
Учебная система SAP (ABAP trial), два прогона: по сервисам самой SAP и по сервисам, написанным другими пользователями этой общей системы.
- 175проверок в 40 сервисах — это 100 разных объектов, часть встречается в нескольких сервисах
- 17 из 20чужих сервисов вернули нашей учётной записи хотя бы одну запись; описание интерфейса отдали все 20
- 0объектов помечено как дефект — ни одного молчаливого усечения и ни одного null в поле, объявленном непустым
Главное — второй признак. Эти 20 сервисов написали 15 разных людей, среди тех 17, что вернули записи, — 12. По именам сущностей и полей это сотрудники, материалы с суммами и валютой, агентства с адресами и почтой, аэропорты, брони. Оговорюсь честно: часть из этого — справочные и мастер-данные, а не операционные, и авторство сервиса не доказывает принадлежность записей. Значения мы не сохраняем, только имена полей — поэтому и утверждать могу только про форму.
И это не «несанкционированный доступ»: в общей учебной системе разграничения арендаторов нет вовсе, поэтому «чужое» здесь означает «из чужого пространства имён». Ценность в механизме — снаружи не отличить «этого нет» от «мне не показали».
Ноль по двум другим признакам — это правильный ответ, но у него есть знаменатель. Из 175 проверок общее число записей удалось узнать в 110; выборка была достаточной для оценки заполненности в 100. В этих пределах: ни одного молчаливого усечения, ни одного нарушения контракта. Инструмент, который помечает проблемы там, где их нет, на живой системе бесполезен — заказчик проверит две находки, обе окажутся выдуманными, третью смотреть не станет. Что находить он умеет, проверяется отдельно, на поддельном шлюзе, который врёт так же, как настоящий.
Не проверка агента — ни одного агента и ни одной задачи мы не запускали. Не аудит качества данных вообще. И ещё не вердикт о готовности к бою: одна общая учебная система, два среза, без ролей заказчика и без представительного объёма.
5. Ограничения
Технический ключ, который SAP выдаёт автоматически, к данным не пускает. Отдельного ограниченного пользователя в учебной системе создать нельзя. Сработал только вход под личным паролем — а его заказчик не даст никогда. Без ответа нельзя начинать разговор ни с одной компанией. Это вопрос 1.
Бизнес-данные мы не меняем — откатывать нечего. Но чтение оставляет следы: статистика шлюза, журналы веб-сервера, а если у заказчика настроен Read Access Logging на нужном сервисе и полях — то и запись о том, какие поля прочитаны. Что именно попадёт в журналы, зависит от настроек, поэтому обещать «нас не будет видно» нельзя.
Данные внутренние: контрагенты, суммы, персональные данные сотрудников. Инструмент сохраняет только имена полей и статистику, не значения — но по проводу значения идут и живут в памяти во время прогона. Значит, до первого прогона нужно письменное поручение на обработку персональных данных (по GDPR мы становимся обработчиком, заказчик остаётся контролёром) и согласие службы безопасности, а не устное «ну посмотри».
Инструмент делает 4–5 чтений на объект: страницу записей, подсчёт общего числа и пробную большую выборку. Подсчёт по большой таблице — это полный проход, а параллельность занимает рабочие процессы. Первый прогон вытянул за раз 12 022 записи — с тех пор поставил жёсткий предел на любое чтение и убрал безлимитные запросы совсем, но на боевой системе это всё равно согласуется с Basis: список разрешённых сервисов, потолки, окно запуска, условие останова.
Отдельно: политика API SAP ограничивает не только «планирование вызовов моделью», но и систематическое масштабное извлечение данных. Детерминированный обход снимает первое, но не второе — рамку придётся согласовывать.
Форма, а не частота
В учебной системе нет ни объёма, ни беспорядка. Признаки существуют и измеримы. Как часто они встречаются на живом ландшафте — отсюда не узнать.
Нужно не меньше трёх систем
Наша норма после случая, когда 17 совпадений из 17 на подобранных примерах превратились в 23 % на живых данных.
6. Вопросы
Ради них всё и написано. Первые три — из вашей повседневной работы, у меня ответов нет.
1. Один конкретный сценарий
Возьмите любую агентскую задачу в SD, PP или MM, которую реально хотели бы автоматизировать. Какой сбой в данных, интерфейсе или правах привёл бы к неверному действию? Как это проверяют сегодня? Без такого примера «агент ошибётся» остаётся словами.
2. Где на самом деле пусто?
Объект → поле или статус, по которому принимается решение → чем оно бывает не заполнено → что из этого следует. Три таких цепочки превращаются в три проверки.
3. Как заказчик выдаёт доступ на чтение?
Коммуникационная система, пользователь и договорённость о связи — так? Кто согласует со стороны заказчика и сколько это занимает? Что определяет список открытых сервисов? Отдельно: облако, приватная версия и локальная установка — это разные ответы?
4. Как проверяют готовность сегодня?
Перед запуском агента или интеграции кто-то смотрит на пригодность данных? Чем — воркшоп, выгрузка, чутьё консультанта? Что при этом остаётся ручным и какое свидетельство изменило бы решение «запускаем / не запускаем»?
5. Где взять рабочие системы?
На учебной видно форму признаков, но не их частоту. Понять, есть ли проблема на самом деле, можно только на рабочих ландшафтах — нужно не меньше трёх. Развилка не «тест против прода», а: свежая маскированная копия против синтетики; представительные роли и объём против нет; и можно ли отдать инструмент, чтобы заказчик прогнал его сам и прислал только сводку.
6. Кто платит?
Кто держит бюджет, кто отвечает за риск, кто пользуется, кто может заблокировать — это четыре разных человека. И что становится поводом купить: новый проект, инцидент, аудит?
7. Что должно быть в отчёте?
Чтобы по строке отчёта можно было действовать — чего в ней не хватает? Объект и поле, доля и на какой выборке, какая задача агента на это опирается, под какой ролью читали, кто чинит, насколько мы уверены?