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, без внешних зависимостей.
Сейчас это скрипт, который читает S/4 снаружи: так удобно было прогонять по учебной системе. Продукт живёт иначе — как приложение в BTP самого заказчика, обращающееся к S/4HANA через стандартные OData-сервисы. Прогон идёт внутри его контура, наружу уходит только отчёт.
4. Что прогнали и что получили
Учебная система SAP (ABAP trial), два прогона: по сервисам самой SAP и по сервисам, написанным другими пользователями этой общей системы.
- 175проверок в 40 сервисах — это 100 разных объектов, часть встречается в нескольких сервисах
- 17 из 20чужих сервисов вернули нашей учётной записи хотя бы одну запись; описание интерфейса отдали все 20
- 0объектов помечено как дефект — ни одного молчаливого усечения и ни одного null в поле, объявленном непустым
Главное — второй признак. Эти 20 сервисов написали 15 разных людей, среди тех 17, что вернули записи, — 12. По именам сущностей и полей это сотрудники, материалы с суммами и валютой, агентства с адресами и почтой, аэропорты, брони. Оговорюсь честно: часть из этого — справочные и мастер-данные, а не операционные, и авторство сервиса не доказывает принадлежность записей. Значения мы не сохраняем, только имена полей — поэтому и утверждать могу только про форму.
И это не «несанкционированный доступ»: в общей учебной системе разграничения арендаторов нет вовсе, поэтому «чужое» здесь означает «из чужого пространства имён». Ценность в механизме — снаружи не отличить «этого нет» от «мне не показали».
Ноль по двум другим признакам — это правильный ответ, но у него есть знаменатель. Из 175 проверок общее число записей удалось узнать в 110; выборка была достаточной для оценки заполненности в 100. В этих пределах: ни одного молчаливого усечения, ни одного нарушения контракта. Инструмент, который помечает проблемы там, где их нет, на живой системе бесполезен — заказчик проверит две находки, обе окажутся выдуманными, третью смотреть не станет. Что находить он умеет, проверяется отдельно, на поддельном шлюзе, который врёт так же, как настоящий.
Не проверка агента — ни одного агента и ни одной задачи мы не запускали. Не аудит качества данных вообще. И ещё не вердикт о готовности к бою: одна общая учебная система, два среза, без ролей заказчика и без представительного объёма.
5. Ограничения
Заказчик заводит технического пользователя с технической ролью, как для внешнего аудитора: роли под задачу, ничего лишнего. OData-сервисы при этом открываются отдельно. Это привычная процедура, а не что-то, чего никто не делал.
Отсюда требование к методике: диагностику надо гонять под теми же ролями и с тем же набором открытых сервисов, что и будущий агент. Шире — опишем систему, которой агент не увидит; уже — придумаем проблемы.
Кто со стороны заказчика согласует заведение пользователя и открытие сервисов, и сколько это занимает. Это уже не «есть ли путь», а «сколько недель» — вопрос 3.
Инструмент разворачивается в его BTP и читает S/4 изнутри. Наружу отдаётся отчёт: имена объектов и полей, доли, числа — не записи. Значений мы не получаем вовсе, а не «получаем и обещаем не хранить». Это снимает поручение на обработку персональных данных, трансграничную передачу и проверку внешнего читателя службой безопасности.
Что остаётся честно сказать: бизнес-данные не меняются, менять нечего и откатывать нечего. Но чтение оставляет следы в статистике шлюза и журналах, а при настроенном Read Access Logging — и запись о том, какие поля прочитаны. Объём чтения согласуется с Basis: список сервисов, потолки, окно запуска.
Инструмент делает 4–5 чтений на объект: страницу записей, подсчёт общего числа и пробную большую выборку. Подсчёт по большой таблице — это полный проход, а параллельность занимает рабочие процессы. Первый прогон вытянул за раз 12 022 записи — с тех пор поставил жёсткий предел на любое чтение и убрал безлимитные запросы совсем, но на боевой системе это всё равно согласуется с Basis: список разрешённых сервисов, потолки, окно запуска, условие останова.
Отдельно: политика API SAP ограничивает не только «планирование вызовов моделью», но и систематическое масштабное извлечение данных. Детерминированный обход снимает первое, но не второе — рамку придётся согласовывать.
Форма, а не частота
В учебной системе нет ни объёма, ни беспорядка. Признаки существуют и измеримы. Как часто они встречаются на живом ландшафте — отсюда не узнать.
Нужно не меньше трёх систем
Наша норма после случая, когда 17 совпадений из 17 на подобранных примерах превратились в 23 % на живых данных.
6. Вопросы
Ради них всё и написано. Первые три — из вашей повседневной работы, у меня ответов нет.
1. Один конкретный сценарий
Возьмите любую агентскую задачу в SD, PP или MM, которую реально хотели бы автоматизировать. Какой сбой в данных, интерфейсе или правах привёл бы к неверному действию? Как это проверяют сегодня? Без такого примера «агент ошибётся» остаётся словами.
2. Где на самом деле пусто?
Объект → поле или статус, по которому принимается решение → чем оно бывает не заполнено → что из этого следует. Три таких цепочки превращаются в три проверки.
3. Сколько занимает получить доступ?
Технический пользователь, роли под задачу, открытие OData-сервисов, приложение в BTP — механика понятна. Кто это согласует у заказчика и сколько недель занимает на практике? Что тормозит чаще — безопасность, Basis, закупки? И отличаются ли ответы для облака, приватной версии и локальной установки?
4. Как проверяют готовность сегодня?
Перед запуском агента или интеграции кто-то смотрит на пригодность данных? Чем — воркшоп, выгрузка, чутьё консультанта? Что при этом остаётся ручным и какое свидетельство изменило бы решение «запускаем / не запускаем»?
5. Где взять рабочие системы?
На учебной видно форму признаков, но не их частоту. Понять, есть ли проблема на самом деле, можно только на рабочих ландшафтах — нужно не меньше трёх. Развилка не «тест против прода», а: свежая маскированная копия против синтетики; представительные роли и объём против нет; и можно ли отдать инструмент, чтобы заказчик прогнал его сам и прислал только сводку.
6. Кто платит?
Кто держит бюджет, кто отвечает за риск, кто пользуется, кто может заблокировать — это четыре разных человека. И что становится поводом купить: новый проект, инцидент, аудит?
7. Что должно быть в отчёте?
Чтобы по строке отчёта можно было действовать — чего в ней не хватает? Объект и поле, доля и на какой выборке, какая задача агента на это опирается, под какой ролью читали, кто чинит, насколько мы уверены?