Я с удовольствием почитаю Ваши статьи, это реально интересно.
Однако же позволю себе небольшую шпильку авансом.
Выше, в ответе на вопрос, Вы привели небольшой скрин. И на этом скрине я вижу по сути сырцы формирующейся BRMS, системы управления требованиями. Использовать для этой цели LLM я уже пару раз "начинал делать", но меня каждый раз останавливал колоссальный объём работы по первичному наполнению и дальнейшему сопровождению RAG-ов под каждый чих. Одно дело, сделать специализированный экспертный модуль для ... ну скажем коммерсов или юристов, и совсем другое - всю торговую сеть.
Ну и мне пока не приходит в голову как запилить переход именно в транзакции учёта. Как и зачем. Это всё есть в ERP
На мой взгляд, учёт ещё долго будет сохраняться в БД ERP-шек. Названный автором срок излишне оптимистичен по двум причинам, которые в целом отражены в статье.
Конфиденциальность данных, которая требует разворачивания своей собственной инфоаструктуры под модель и агентов. Далеко не у всех хватит железа и рук, а в конечном счёте - денег
Лютое недоверие к результатам работы LLM. Для тех, кто серьёзно погружается в методы повышения качества в целом и детерменизма в частности работы моделей, это недоверие потихоньку проходит. Но это процесс не быстрый и возвращает нас к п.1. Не всем по силам
А вот пользовательские интерфейсы - да, переезжать будут разумеется. Но это и так нормальная практика, создавать лёгкие сервисы над учётом вместо упарывания на желто-голубых окошках.
Здесь просто добавляется ещё одна возможность. Но она также требует непрерывной поддержки.
Вы же сейчас не серьёзно приводите пример внешней модели как место, куда можно спокойно взять и загрузить счета, договора и прочую коммерческую информацию предприятия?
Не поленитесь, напишите книгу, выложите на Озон. Бестселлером будет.
Не существует "универсального заказа". Просто потому, что в ГК РФ есть статья "свобода договора". Стороны могут догрвориться о любых условиях, не регаментированных иными статьями ГК.
А значит бизнес-подразделения конкретных компаний имеют возможность заявлять самые смелые фантазии в рамках условий, не попадающих под УК и КоАП, а временами и за этими рамками, если готовы рискнуть.
А раз нет "универсального заказа", то нет и универсального решения.
Есть только общий шаблон вида:
"заказчик-плательщик-поставщик"
"условия оплаты-условия отгрузки-условия транспортрировки-условия приемки-условия возврата", включая возможность частичной отгрузки, частичного отказа от позиций до момента поставки, частичной оплаты включая кредиты и встречное предоставление
"Скидки на заказ/позиции"
"Возможность частичной замены позиций при сборке"
.... Извините, дальше лень.
Реализацию какой комбинации этих условий Вы считаете "по человечески"?
Когда Вас включают в какой-нибудь "мамкочатик 5а класса" или общедомовой в вацапе* - Ваш номер сразу становится доступным нескольким десяткам, а то и сотням человек, которым Вы этот номер не давали и возможно даже не хотели бы давать.
Принимать решения "с риском для собственной пятой точки" должна быть какая-то мотивация. У чиновников же такой мотвации нет, но есть риск как минимум улететь на "свободный рынок труда" с очень смутными перспективами найти нормальную работу и попутно остаться без стажа с повышающим коэффициентом к пенсии. Как максимум - получить общение с прокуратрурой. Это кстати не редкость, поверьте. И за описанное Вами нарушение сметы ей бы прилетело почти гарантированно при первой же проверке.
И чего Вы ожидали от описанной чиновницы при таком раскладе?
Нет, я их не защищаю. Просто предлагаю смотреть на них как на людей, у которых абсолютно нет мотивации что-либо решать. А вот мотивация "не решать" - есть. И нехилая.
По некоторому опыту работы с легаси-системами, мне лично как функциональному архитектору, больше всего проблем доставляли "потеряшки" в интеграционных схемах. Когда уже никто не помнит не только как сделано, но и почему именно так
Повторю, я не могу отвечать за разаботку, но чисто умозрительно было бы полезным давать llm-кам задачу генерить кроме кода erd-шку на mermaid и подкладывать её рядом
Когнитивным долгом называют другую вещь - просаживание когнитивных способностей при регулярном делегировании сложных задач ИИ-шке.
Нет пока устойчивого толкования термина ;)
....
За разработку не скажу, в бизнес-аналитике LLM-ки применям. В первую очередь для парсинга транскриптов встреч и генерации документации по схемам, если их можно сбросить в xml или mermaid
Правило примерно то же. Документ, сгенеренный LLM, в самом начале имеет метку "AI Generation" и по всем соглашениям не двигается дальше статусам"черновик". То есть аналитики используют этот материал для рабочих документов. Но уже под своим авторством и со своей ответственностью.
В приведённой BPM-ке - бесконечный цикл на проверке варианта доставки. Не нашлось валидной схемы?
EPC - графическое представление юзкейса.
Описать в этих нотациях взаимодействие даже 3-4 систем - уже сложно. Построить же даже самую базовую карту интеграции 10 и более систем в happy path кейсе - получится нечитаемый монстр.
Это инструменты процессного и бизнес-аналитика.
Почему не упомянут archimate ?
Фиолетовый, желтый, голубой и частично зелёный слои - основная среда обитания описанного Вами специалиста
Если сравнивать результаты "поиска" по бытовым вопросам, мне DeepSeek нравится гораздо больше Qwen. Он не злоупотребляет информацией с VC, Дзен и прочих сомнительных источников.
Делюсь подходом, который решает ту же боль без «Excel-ядер». Он проверен и работает.
Суть (итеративно):
Берёте любой старый документ или транскрипт встречи. Прогоняете через LLM по прилагаемому промпту (первый проход).
На выходе — глоссарий (все термины, незнакомые помечены [? ТЕРМИН ?]) + очищенный текст.
По этому глоссарию рисуете ERD на Mermaid (сущности, атрибуты, связи, ключи). Это архитектурная база, а не таблица в Excel.
Следующие документы подаёте модели вместе с текущим глоссарием и ERD — LLM отлично парсит Mermaid и не путает сущности.
Новые термины -> дополняете глоссарий и ERD (человек или LLM под контролем).
На этой очищенной базе генерируете чистую документацию (процессы, инструкции, требования) — без галлюцинаций.
Важный совет: не изобретайте промежуточных сущностей вроде «слоистых ядер». ERD + итеративный цикл — проще, архитектурно чище и легко поддерживается.
Скрытый текст
Твоя роль
Опытный системный и бизнес-аналитик (розничная торговля, логистика, РФ)
Цель
Создать Протокол встречи для страницы в Confluence (минимальный копипаст)
Границы уровня Base
Табличное форматирование для Confluence
ОДНА диаграмма в формате ERD (Mermaid)
Требования в едином формате
Время выполнения: 15-20 минут
Входные данные
Транскрипт встречи (файл transcript-*.txt)
Проблемы транскрипта:
Посекундная разбивка фраз спикеров
Шум, отвлечённые разговоры
Ошибки распознавания
Ограничения
Для дальнейшего анализа:
Работай строго по тексту транскрипта
Если требуемая информация не найдена — пиши [НЕТ ИНФОРМАЦИИ]
НЕ добавляй собственные интерпретации и предположения
Приоритет секций (если время ограничено):
Глоссарий + Ключевые инсайты
Принятые решения
Перечень требований
ERD (Mermaid)
Форматирование:
Используй: текст, списки, таблицы
НЕ используй: ссылки, выделение жирным/курсивом
Если автор требования или иной параметр не определён — пиши [НЕ ОПРЕДЕЛЕН]
Задача
Очисти транскрипт от всего, что не относится к бизнес-задаче:
Мемо от системы транскрибации (Тема, Краткое содержание, Ключевые моменты, Принятые решения)
Приветствия и прощания в начале/конце
Личные разговоры (шутки, обсуждения)
Технические обсуждения качества связи
Склей фразы одного спикера в связные абзацы. Убери метки времени.
Выяви и отметь проблемные места: [НЕЯСНО]
Выяви предварительный глоссарий:
[термин]:[описание] — для расшифрованных терминов
[? ТЕРМИН ?]:[описание] — для незнакомых аббревиатур (CAPS + вопрос)
Зафиксируй требования с атрибуцией [автор]
Зафиксируй принятые решения
Построй ERD в формате Mermaid (синтаксис entity relationship diagram). Извлеки основные сущности из разговора (например: Заказ, Товарная позиция, Покупатель, Поставщик, Склад, Статус заказа, Счет, НДС). Укажи атрибуты и связи (один-ко-многим, один-к-одному). Если связь неясна — отметь [?].
Формат вывода
Титул
Поле Значение Наименование [Заполняет аналитик] Заказчик [Заполняет аналитик] Номер в Jira [Заполняет аналитик] Концепт эпика Для (кто), чтобы (что), необходимо (как) Статус Черновик Аннотация [Краткое описание]
Глоссарий
Термин Сокращение Описание [термин] [если есть] [описание] [? ТЕРМИН ?] [если есть] [требует уточнения]
Предпосылки (AsIs)
[Текст из транскрипта]
Задача бизнеса (ToBe)
[Текст из транскрипта]
Цель задачи
[Измеримая цель если озвучена]
Ключевое решение
[Концептуальный план если озвучен]
Требования
ID Наименование Описание Автор Статус REQ-{Jira}-001 [Название] [Текст] [Автор] Черновик
Ограничения и допущения
ID Наименование Описание Автор Статус SC-{Jira}-001 [Название] [Текст] [Автор] Черновик
ERD (Mermaid)
erDiagram
% Здесь сгенерируй ERD на основе выявленных сущностей
% Пример:
% ЗАКАЗ {
% int номер_заказа PK
% date дата_создания
% string статус
% }
% ПОКУПАТЕЛЬ {
% int id PK
% string фио
% string перс_данные_для_таможни
% }
% ЗАКАЗ ||--|| ПОКУПАТЕЛЬ : оформляет
Промпт даю свой, проверенный. Чуток адаптировал его под Вашу задачу (у меня в базе LLM схему чертит под draw.io в mxgraph xml).
Кирилл, добрый день. Прочитал статью. Впечатлён объёмом и системностью. Видно, что проделана серьёзная работа.
Я сам немного архитектор, и мне хорошо знакомо это чувство: когда появляется новая технология, хочется сразу затащить её в контур, чтобы «расширить капабилити».
Но у нас, похоже, разные стартовые точки. Вы глубоко разобрали «как» интегрировать ИИ в ERP. Для меня же первичен ответ на вопрос «зачем?». Не в перспективе «когда ИИ дозреет», а здесь и сейчас. Какую конкретную бизнес-задачу это решает? Что станет дешевле, быстрее или надёжнее для компании в текущем контуре? От этого и нужно смотреть конкретное исполнение.
Давайте посмотрим на историю внедрений. ERP эволюционировали в современные монолиты именно так – поэтапно поглощая крупные функциональные блоки.
Что прижилось внутри ядра: * MDM: модули управления НСИ. * BPM: маршруты согласований, статусные модели, эскалации. * WMS/TMS: управление складом и логистикой (часто в ядре или на бесшовной интеграции). * BI/OLAP: встроенные кубы, отчёты, дашборды. Базовая аналитика – штатный модуль. * GRC: контроль доступа, аудит, SOX-отчётность, разделение полномочий. * Rule Engines: конструкторы скидок, условий ценообразования, валидаторы.
Что осталось снаружи или не взлетело: * Полноценные CRM (обычно пристроены сбоку с синхронизацией). * Блокчейн (экономика, приватность и пропускная способность не сошлись). * Корпоративные соцсети (попытки вроде SAP Jam быстро сошли на нет). * Ранний ML на полках/кассах: единичные пилоты, массового внедрения не случилось.
Вывод напрашивается сам: в ядро ERP успешно «затащили» только то, что:
* Детерминировано (правила, маршруты, справочники). * Требует жёсткой консистентности (запасы, финансы, аудит). * Имеет чётко локализованную область применения.
Всё остальное ушло в интегрированные внешние сервисы или осталось экспериментами.
Примерим это к ИИ: * Детерминизм? Нет. Вероятностная природа. Можно обложить ИИ RAG-ом, MD-инструкциями, сбить ему температуру до нуля, но косинусное сходство не станет равенством. * Консистентность? Не требуется. Модель работает с «любым» входом, лишь бы хватило контекста. * Локализация области? Тоже нет. LLM по определению универсальны, а не заточены под узкий контур.
Добавлю ещё два практических аспекта, которые критичны в энтерпрайзе:
* Управляемость и откаты. В ERP мы точно знаем, что изменилось в релизе, и можем откатить пакет. В случае с ИИ (особенно внешним или часто обновляемым) мы не всегда фиксируем, когда и как изменились веса модели, версия промпта или логика выборки RAG. «Откатить галлюцинацию» сложнее, чем откатить транзакцию или патч. * Экономика и безопасность. Свои модели – это GPU, ML-инженеры, пайплайны для датасетов. Внешние API в контуре документооборота – риски утечки коммерческих данных и вопросы комплаенса. Всё это должно окупаться, а без чёткого «зачем» бюджет на содержание быстро съест гипотетическую выгоду.
Отвечу на ваш финальный вопрос: да, мы используем ИИ, и есть ряд рабочих кейсов (возможно, позже опишем). Но ни один из них пока не требует «нормализации терминов» внутри ERP-контура.
Ну и по сути. То, что Вы называете «семантическим ядром для ИИ», в enterprise-архитектуре последние 20 лет известно под другими именами: предметная область, НСИ, метамодель, регламенты ведения данных. Проблема обычно не в том, что ИИ «не понимает» контекст, а в том, что бизнес не хочет тратить ресурсы на дисциплину данных, пока не прижмёт. Встраивать дополнительный слой как решение галлюцинаций – это лечить симптом, а не корень.
Или я что-то упустил в Вашей логике? Буду рад конструктивной дискуссии.
Благодарю.
Я с удовольствием почитаю Ваши статьи, это реально интересно.
Однако же позволю себе небольшую шпильку авансом.
Выше, в ответе на вопрос, Вы привели небольшой скрин. И на этом скрине я вижу по сути сырцы формирующейся BRMS, системы управления требованиями. Использовать для этой цели LLM я уже пару раз "начинал делать", но меня каждый раз останавливал колоссальный объём работы по первичному наполнению и дальнейшему сопровождению RAG-ов под каждый чих. Одно дело, сделать специализированный экспертный модуль для ... ну скажем коммерсов или юристов, и совсем другое - всю торговую сеть.
Ну и мне пока не приходит в голову как запилить переход именно в транзакции учёта. Как и зачем. Это всё есть в ERP
На мой взгляд, учёт ещё долго будет сохраняться в БД ERP-шек. Названный автором срок излишне оптимистичен по двум причинам, которые в целом отражены в статье.
Конфиденциальность данных, которая требует разворачивания своей собственной инфоаструктуры под модель и агентов. Далеко не у всех хватит железа и рук, а в конечном счёте - денег
Лютое недоверие к результатам работы LLM. Для тех, кто серьёзно погружается в методы повышения качества в целом и детерменизма в частности работы моделей, это недоверие потихоньку проходит. Но это процесс не быстрый и возвращает нас к п.1. Не всем по силам
А вот пользовательские интерфейсы - да, переезжать будут разумеется. Но это и так нормальная практика, создавать лёгкие сервисы над учётом вместо упарывания на желто-голубых окошках.
Здесь просто добавляется ещё одна возможность. Но она также требует непрерывной поддержки.
Автору вопрос.
Вы же сейчас не серьёзно приводите пример внешней модели как место, куда можно спокойно взять и загрузить счета, договора и прочую коммерческую информацию предприятия?
Ну ведь правда не серьёзно?
Сергей, может быть я не заметил в статье, но вроде не было.
Поэтому задам таки подлый вопрос. А экономику самой ЧП Вы считали на окупаемость затрат на её поддержку?
Понятно, что есть не только ЧП, но ещё и НГ и 8М. Но это всё-равно не 51 неделя пиковой нагрузки. И вне всплесков инфраструктура работает вхолостую?
А “по-человечески" - это как?
Не поленитесь, напишите книгу, выложите на Озон. Бестселлером будет.
Не существует "универсального заказа". Просто потому, что в ГК РФ есть статья "свобода договора". Стороны могут догрвориться о любых условиях, не регаментированных иными статьями ГК.
А значит бизнес-подразделения конкретных компаний имеют возможность заявлять самые смелые фантазии в рамках условий, не попадающих под УК и КоАП, а временами и за этими рамками, если готовы рискнуть.
А раз нет "универсального заказа", то нет и универсального решения.
Есть только общий шаблон вида:
"заказчик-плательщик-поставщик"
"условия оплаты-условия отгрузки-условия транспортрировки-условия приемки-условия возврата", включая возможность частичной отгрузки, частичного отказа от позиций до момента поставки, частичной оплаты включая кредиты и встречное предоставление
"Скидки на заказ/позиции"
"Возможность частичной замены позиций при сборке"
.... Извините, дальше лень.
Реализацию какой комбинации этих условий Вы считаете "по человечески"?
Космолёт конечно знатный этот ваш CUSUM, судя по описанию :)))
Хотя, на таком ассортименте и оборотах это скорее всего оправданно
Есть и другой кейс.
Когда Вас включают в какой-нибудь "мамкочатик 5а класса" или общедомовой в вацапе* - Ваш номер сразу становится доступным нескольким десяткам, а то и сотням человек, которым Вы этот номер не давали и возможно даже не хотели бы давать.
Принимать решения "с риском для собственной пятой точки" должна быть какая-то мотивация. У чиновников же такой мотвации нет, но есть риск как минимум улететь на "свободный рынок труда" с очень смутными перспективами найти нормальную работу и попутно остаться без стажа с повышающим коэффициентом к пенсии. Как максимум - получить общение с прокуратрурой. Это кстати не редкость, поверьте. И за описанное Вами нарушение сметы ей бы прилетело почти гарантированно при первой же проверке.
И чего Вы ожидали от описанной чиновницы при таком раскладе?
Нет, я их не защищаю. Просто предлагаю смотреть на них как на людей, у которых абсолютно нет мотивации что-либо решать. А вот мотивация "не решать" - есть. И нехилая.
В вот интересно.
А какой примерно процент задач из разряда "гигиенический минимум сервиса" Вы считаете допустимым запускать без оценки экономической эффективности?
Если Вы не относите это к разряду коммерческой информации разумеется.
Умозрительно то всё понятно. Но дебет с кредитом это дебет с кредитом
По некоторому опыту работы с легаси-системами, мне лично как функциональному архитектору, больше всего проблем доставляли "потеряшки" в интеграционных схемах. Когда уже никто не помнит не только как сделано, но и почему именно так
Повторю, я не могу отвечать за разаботку, но чисто умозрительно было бы полезным давать llm-кам задачу генерить кроме кода erd-шку на mermaid и подкладывать её рядом
Любопытно, что в соседней статье
https://habr.com/ru/articles/1046678/
Когнитивным долгом называют другую вещь - просаживание когнитивных способностей при регулярном делегировании сложных задач ИИ-шке.
Нет пока устойчивого толкования термина ;)
....
За разработку не скажу, в бизнес-аналитике LLM-ки применям. В первую очередь для парсинга транскриптов встреч и генерации документации по схемам, если их можно сбросить в xml или mermaid
Правило примерно то же. Документ, сгенеренный LLM, в самом начале имеет метку "AI Generation" и по всем соглашениям не двигается дальше статусам"черновик". То есть аналитики используют этот материал для рабочих документов. Но уже под своим авторством и со своей ответственностью.
Пока что это работает реально хорошо
В приведённой BPM-ке - бесконечный цикл на проверке варианта доставки. Не нашлось валидной схемы?
EPC - графическое представление юзкейса.
Описать в этих нотациях взаимодействие даже 3-4 систем - уже сложно. Построить же даже самую базовую карту интеграции 10 и более систем в happy path кейсе - получится нечитаемый монстр.
Это инструменты процессного и бизнес-аналитика.
Почему не упомянут archimate ?
Фиолетовый, желтый, голубой и частично зелёный слои - основная среда обитания описанного Вами специалиста
НДС на самом деле совсем не тривиальная штука
В банках НДФЛ тоже чудесатый по слухам.
Да без разницы на самом деле. Суть то не сильно меняется.
Быстрые прототипы - это реально очень нужная вещь
Однако же позвольте поинтересоваться таким нюансом. Расчёт и подачу НДС Вы тоже навайбкодите ?
Неужто именно в этом суть прогнозируемого Вами грандиозного шухера?
Тон ответа в настройках профиля пользователя пробовали подбирать?
В дефолте там "баланс профессионализма и дружелюбия"
Александр, вот реальное большое человеческое спасибо, что не поленились.
Плюсы ствол покинули 😁
Я в курсе. У меня в каждом проекте пре-промпт с настройкам под лимит в 1000 символов забит.
Да даже если бы оставалось место под блэклисты - меня устраивают результаты дипсика в большинстве запросов
Я просто отметил, что по моим наблюдениям квен 3.6 плюс значительно более тяготеет к поиску на массовых не специализированных площадках, чем дипсик.
Не думал, что перерастёт в дискуссию :))
Если сравнивать результаты "поиска" по бытовым вопросам, мне DeepSeek нравится гораздо больше Qwen. Он не злоупотребляет информацией с VC, Дзен и прочих сомнительных источников.
Это абсолютно субъективно разумеется
Кирилл, всё.
Я увидел 3ю статью, пока что только по диагонали глянул.
Вам бы по-честному с неё начать.
Потому что первые 2 без неё - это серьёзный труд по решению абсолютно абстрактной задачи.
Отвечал в полном недоумении "что же нужно на самом деле"
Всё, паззл сошёлся, вопросы снял.
...
Временно.
Ту статью надо на свежую голову курить и уже предметно обсуждать конкретные вещи
Я кажется понял ...
Кирилл, добрый день.
Делюсь подходом, который решает ту же боль без «Excel-ядер». Он проверен и работает.
Суть (итеративно):
Берёте любой старый документ или транскрипт встречи. Прогоняете через LLM по прилагаемому промпту (первый проход).
На выходе — глоссарий (все термины, незнакомые помечены [? ТЕРМИН ?]) + очищенный текст.
По этому глоссарию рисуете ERD на Mermaid (сущности, атрибуты, связи, ключи). Это архитектурная база, а не таблица в Excel.
Следующие документы подаёте модели вместе с текущим глоссарием и ERD — LLM отлично парсит Mermaid и не путает сущности.
Новые термины -> дополняете глоссарий и ERD (человек или LLM под контролем).
На этой очищенной базе генерируете чистую документацию (процессы, инструкции, требования) — без галлюцинаций.
Важный совет: не изобретайте промежуточных сущностей вроде «слоистых ядер». ERD + итеративный цикл — проще, архитектурно чище и легко поддерживается.
Скрытый текст
Твоя роль
Опытный системный и бизнес-аналитик (розничная торговля, логистика, РФ)
Цель
Создать Протокол встречи для страницы в Confluence (минимальный копипаст)
Границы уровня Base
Табличное форматирование для Confluence
ОДНА диаграмма в формате ERD (Mermaid)
Требования в едином формате
Время выполнения: 15-20 минут
Входные данные
Транскрипт встречи (файл transcript-*.txt)
Проблемы транскрипта:
Посекундная разбивка фраз спикеров
Шум, отвлечённые разговоры
Ошибки распознавания
Ограничения
Для дальнейшего анализа:
Работай строго по тексту транскрипта
Если требуемая информация не найдена — пиши [НЕТ ИНФОРМАЦИИ]
НЕ добавляй собственные интерпретации и предположения
Приоритет секций (если время ограничено):
Глоссарий + Ключевые инсайты
Принятые решения
Перечень требований
ERD (Mermaid)
Форматирование:
Используй: текст, списки, таблицы
НЕ используй: ссылки, выделение жирным/курсивом
Если автор требования или иной параметр не определён — пиши [НЕ ОПРЕДЕЛЕН]
Задача
Очисти транскрипт от всего, что не относится к бизнес-задаче:
Мемо от системы транскрибации (Тема, Краткое содержание, Ключевые моменты, Принятые решения)
Приветствия и прощания в начале/конце
Личные разговоры (шутки, обсуждения)
Технические обсуждения качества связи
Склей фразы одного спикера в связные абзацы. Убери метки времени.
Выяви и отметь проблемные места: [НЕЯСНО]
Выяви предварительный глоссарий:
[термин]:[описание] — для расшифрованных терминов
[? ТЕРМИН ?]:[описание] — для незнакомых аббревиатур (CAPS + вопрос)
Зафиксируй требования с атрибуцией [автор]
Зафиксируй принятые решения
Построй ERD в формате Mermaid (синтаксис entity relationship diagram). Извлеки основные сущности из разговора (например: Заказ, Товарная позиция, Покупатель, Поставщик, Склад, Статус заказа, Счет, НДС). Укажи атрибуты и связи (один-ко-многим, один-к-одному). Если связь неясна — отметь
[?].Формат вывода
Титул
Поле Значение Наименование [Заполняет аналитик] Заказчик [Заполняет аналитик] Номер в Jira [Заполняет аналитик] Концепт эпика Для (кто), чтобы (что), необходимо (как) Статус Черновик Аннотация [Краткое описание]
Глоссарий
Термин Сокращение Описание [термин] [если есть] [описание] [? ТЕРМИН ?] [если есть] [требует уточнения]
Предпосылки (AsIs)
[Текст из транскрипта]
Задача бизнеса (ToBe)
[Текст из транскрипта]
Цель задачи
[Измеримая цель если озвучена]
Ключевое решение
[Концептуальный план если озвучен]
Требования
ID Наименование Описание Автор Статус REQ-{Jira}-001 [Название] [Текст] [Автор] Черновик
Ограничения и допущения
ID Наименование Описание Автор Статус SC-{Jira}-001 [Название] [Текст] [Автор] Черновик
ERD (Mermaid)
Промпт даю свой, проверенный. Чуток адаптировал его под Вашу задачу (у меня в базе LLM схему чертит под draw.io в mxgraph xml).
Где нужно - допилите под себя.
Должно работать
Кирилл, добрый день. Прочитал статью. Впечатлён объёмом и системностью. Видно, что проделана серьёзная работа.
Я сам немного архитектор, и мне хорошо знакомо это чувство: когда появляется новая технология, хочется сразу затащить её в контур, чтобы «расширить капабилити».
Но у нас, похоже, разные стартовые точки. Вы глубоко разобрали «как» интегрировать ИИ в ERP. Для меня же первичен ответ на вопрос «зачем?». Не в перспективе «когда ИИ дозреет», а здесь и сейчас. Какую конкретную бизнес-задачу это решает? Что станет дешевле, быстрее или надёжнее для компании в текущем контуре? От этого и нужно смотреть конкретное исполнение.
Давайте посмотрим на историю внедрений. ERP эволюционировали в современные монолиты именно так – поэтапно поглощая крупные функциональные блоки.
Что прижилось внутри ядра:
* MDM: модули управления НСИ.
* BPM: маршруты согласований, статусные модели, эскалации.
* WMS/TMS: управление складом и логистикой (часто в ядре или на бесшовной интеграции).
* BI/OLAP: встроенные кубы, отчёты, дашборды. Базовая аналитика – штатный модуль.
* GRC: контроль доступа, аудит, SOX-отчётность, разделение полномочий.
* Rule Engines: конструкторы скидок, условий ценообразования, валидаторы.
Что осталось снаружи или не взлетело:
* Полноценные CRM (обычно пристроены сбоку с синхронизацией).
* Блокчейн (экономика, приватность и пропускная способность не сошлись).
* Корпоративные соцсети (попытки вроде SAP Jam быстро сошли на нет).
* Ранний ML на полках/кассах: единичные пилоты, массового внедрения не случилось.
Вывод напрашивается сам: в ядро ERP успешно «затащили» только то, что:
* Детерминировано (правила, маршруты, справочники).
* Требует жёсткой консистентности (запасы, финансы, аудит).
* Имеет чётко локализованную область применения.
Всё остальное ушло в интегрированные внешние сервисы или осталось экспериментами.
Примерим это к ИИ:
* Детерминизм? Нет. Вероятностная природа. Можно обложить ИИ RAG-ом, MD-инструкциями, сбить ему температуру до нуля, но косинусное сходство не станет равенством.
* Консистентность? Не требуется. Модель работает с «любым» входом, лишь бы хватило контекста.
* Локализация области? Тоже нет. LLM по определению универсальны, а не заточены под узкий контур.
Добавлю ещё два практических аспекта, которые критичны в энтерпрайзе:
* Управляемость и откаты. В ERP мы точно знаем, что изменилось в релизе, и можем откатить пакет. В случае с ИИ (особенно внешним или часто обновляемым) мы не всегда фиксируем, когда и как изменились веса модели, версия промпта или логика выборки RAG. «Откатить галлюцинацию» сложнее, чем откатить транзакцию или патч.
* Экономика и безопасность. Свои модели – это GPU, ML-инженеры, пайплайны для датасетов. Внешние API в контуре документооборота – риски утечки коммерческих данных и вопросы комплаенса. Всё это должно окупаться, а без чёткого «зачем» бюджет на содержание быстро съест гипотетическую выгоду.
Отвечу на ваш финальный вопрос: да, мы используем ИИ, и есть ряд рабочих кейсов (возможно, позже опишем). Но ни один из них пока не требует «нормализации терминов» внутри ERP-контура.
Ну и по сути. То, что Вы называете «семантическим ядром для ИИ», в enterprise-архитектуре последние 20 лет известно под другими именами: предметная область, НСИ, метамодель, регламенты ведения данных. Проблема обычно не в том, что ИИ «не понимает» контекст, а в том, что бизнес не хочет тратить ресурсы на дисциплину данных, пока не прижмёт. Встраивать дополнительный слой как решение галлюцинаций – это лечить симптом, а не корень.
Или я что-то упустил в Вашей логике? Буду рад конструктивной дискуссии.