Таксоно-онтологическая методология многопредметного инженерного исследования с управляемым межпредметным переносом

Как собирать исследовательскую оптику, переносить конструкции между предметными областями и проверять новое с помощью ИИ

Аннотация

Публикую Часть I книги "Глаз стрекозы" о том, как собирать исследовательскую оптику, переносить конструкции между предметными областями и проверять новое с помощью ИИ.

Полный текст книги состоит из пяти частей, 15 глав, 29 иллюстраций.

Полный текст книги бесплатно прочитать и скачать на Литнет.

«Глаз стрекозы» — практическая книга о многопредметном инженерном исследовании в эпоху ИИ. Она показывает, как одиночный исследователь может собирать несколько предметных миров, различать таксоны, находить переносимые механизмы, защищаться от ложной аналогии, связывать утверждения с доказательствами и вовремя останавливать поиск. Сквозной кейс Universal DR демонстрирует, как продуктовая постановка меняет сам Рабочий Глаз исследования. Книга предназначена для ИТ-архитекторов, аналитиков, инженеров и руководителей, которым нужен не ещё один набор промптов, а воспроизводимая дисциплина работы с неизвестным.

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

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

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

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

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

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

Сначала нужно понять, какими предметными мирами смотреть на задачу. Только потом — какой метод применять.

1. Одиночный исследователь — не маленький НИИ

У одиночного исследователя нет десятков лабораторий, отделов и специалистов. Но его маршрут дешевле перестраивается: можно быстро зайти в соседнюю дисциплину, проверить странную связь, закрыть тупиковую ветвь и вернуться обратно. Большое исследование по более чем 65 миллионам статей, патентов и программных продуктов показало, что малые и большие команды действительно чаще занимают разные ниши: небольшие коллективы чаще связаны с работами, открывающими новые направления, крупные — с развитием существующих линий [1]. Это не означает превосходства одиночки. Это означает другой режим поиска.

Не история всех изобретений человечества, а одна условная траектория: как западная научно-техническая система раз за разом расширяла пространство следующих возможных решений.

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

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

Такое ограничение — не утверждение о превосходстве этой траектории и не попытка объявить её единственно жизнеспособной. Это исследовательская оптика. В книге «Мозг фирмы: 2026» жизнеспособность рассматривается не как один заранее назначенный маршрут, а как поле продолжений: важно не только то, какой вариант существует сейчас, но и какие возможности он оставляет после себя, насколько они независимы и сколько стоит удерживать их открытыми. Я переношу эту мысль на историю только как способ постановки вопроса: какие институты, технологии и способы организации знания не просто давали непосредственный результат, а расширяли поле последующих результатов?

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

Ту статью можно прочитать здесь: «Что такое время в нашей профессии?» на Хабре

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

Хорошо. Время ещё есть. А что именно я хочу на нём построить?

И вот здесь разговор неожиданно вышел далеко за пределы профессии.

Я отец. У меня жена, дети. Дети растут стремительно. Ещё недавно большая часть отношений с ними строилась почти автоматически: ребёнку нужен взрослый, который кормит, защищает, учит, задаёт границы, помогает выбрать школу, объясняет мир. Но эта конструкция временная. Ребёнку становится шестнадцать, восемнадцать, двадцать пять, тридцать пять. У него появляется собственная профессия, супруг или супруга, дети, свой дом, свой бюджет, свой взгляд на жизнь. И тогда уже недостаточно просто любить его и надеяться, что отношения как-нибудь сложатся.

Что приходится собирать генеральному директору

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

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

Задача «Мозга фирмы: 2026» — показать этот многомерный спектр в явном виде. Что именно сегодня приходится удерживать в голове генеральному директору: что сохранить, какие продолжения ещё существуют, какие угрозы они переживают, на каких общих зависимостях держатся, насколько готовы, сколько времени остаётся до закрытия выбора и чем сегодняшнее спасение будет оплачено завтра.

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

Начало в статье ERP внедрили. Что дальше?

Термины, используемые в статье

Project-DR ERP Technology Distribution — полное название технологической сборки. В дальнейшем — «технологическая сборка Project-DR ERP», версия.

Project-DR — Project Digital Replica, проектная цифровая реплика — внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Заказчику Project-DR как технологическая среда не передаётся.

Project Core — проектное ядро — проектный носитель специализированного ресурса, в котором хранится подробный результат его работы по конкретному проекту.

Unified Project Store — единое проектное хранилище — машиночитаемый слой Project-DR, в котором собираются принятые проекции результатов специализированных Project Core.

Enterprise-DR — Enterprise Digital Replica, цифровая реплика предприятия — эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Именно Enterprise-DR передаётся заказчику.

Enterprise-DR Runtime — эксплуатационная среда Enterprise-DR — физически работающая система, в которой клиентская модель загружена в базу данных и доступна через Enterprise-DR API.

Enterprise-DR Runtime Kit — комплект, передаваемый заказчику для развёртывания и эксплуатации Enterprise-DR.

PostgreSQL — система управления базами данных, используемая в версии 2.5.1 как эталонная реализация базы Enterprise-DR. Далее — «база Enterprise-DR».

Enterprise-DR API — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.

От работающей ERP к цифровой реплике и вычислимой модели предприятия

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

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

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

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

У Алексея Толстого в «Золотом ключике, или Приключениях Буратино» есть сцена, которая неожиданно хорошо описывает значительную часть того, что сегодня происходит вокруг больших языковых моделей.

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

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

Мне кажется, мы сейчас примерно в такой точке отношений с LLM.

Большая языковая модель за несколько минут способна сделать то, на что раньше уходили дни работы аналитиков, архитекторов и дизайнеров. Она нарисует архитектуру предприятия, бизнес-процесс, карту функций, модель управления, структуру исследования, концепцию продукта, требования к ERP, презентацию руководству. Всё получится аккуратно, современно и настолько убедительно, что заказчик совершенно естественно может посмотреть на результат и сказать: «Вот оно. Наконец-то всё стало понятно».

Но в серьёзной аналитике после первого впечатления должен прозвучать другой вопрос: что находится за этим холстом?

В ИТ-проектах я всё чаще вижу новую норму: когда руководитель проекта, заказчик или HR рассматривает специалиста в команду, он уже не ограничивается присланным резюме. Гораздо проще открыть ChatGPT, Gemini, DeepSeek или другую привычную модель и спросить: «Что известно об этом человеке как о профессионале?» И вот здесь начинается самое интересное: машина собирает ответ не из того, что человек хотел о себе рассказать, а из того, что о нём действительно осталось в цифровой среде.

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

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

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

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

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

В 2016 году это ещё могло звучать как шаг в будущее. В 2026 году, после скачка ИИ и больших языковых моделей, такая постановка вопроса выглядит уже недостаточной. Поэтому хочется спокойно, без персональных атак, но достаточно прямо спросить: если вы называете свою работу цифровой трансформацией, где ваша методология?

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

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

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

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

Но у СМК есть гораздо более серьёзный потенциал. Она может быть не документальной надстройкой над предприятием, а живой инженерной моделью качества. Такой моделью, которая показывает, какие предметы качества регулируются, какие требования к ним предъявлены, какие процедуры должны быть выполнены, где в бизнес-процессах возникают события качества и какие доказательные записи подтверждают результат.

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

Именно здесь начинается предметно-ориентированный инженерный подход к СМК. Его суть в том, что система качества должна строиться не от папки документов, а от предметов качества, требований, единичных документированных процедур, событий качества, доказательных записей, реквизитов, статусов, маршрутов, приёмки и архива. То есть СМК должна отвечать не только на вопрос «какие документы у нас есть?», а на более строгий вопрос: какие предметы качества мы обязаны доказательно удерживать, какими событиями качества они подтверждаются и какие записи можно предъявить как доказательство?

Сейчас 2026 год.

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

И вот в какой-то момент я поймал себя на простой, но неприятной мысли.

Я оборачиваюсь назад на эти 30 лет и спрашиваю себя: что это было?

Внешне всё понятно.
Годы прошли.
Проекты сделаны.
Этапы закрыты.
Системы внедрены.
Что-то получилось.
Что-то не получилось.

Но внутренне ответ оказывается далеко не таким простым.

Потому что если убрать всю официальную хронологию — даты, проекты, договоры, внедрения, переходы, должности, результаты, — остаётся другой вопрос: а как я вообще прожил это время?

Не по календарю.
Не по проектному плану.
Не по диаграмме Ганта.
А по факту собственной жизни.

И тут возникает второй ход, ещё более жёсткий.

Я мысленно прибавляю к сегодняшнему моменту ещё 30 лет вперёд.

И мне это уже не нравится.

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

Я смотрю вперёд и понимаю: если следующие 30 лет будут устроены так же, как были устроены предыдущие, то вопрос становится слишком жёстким.

Что стоит за вопросом «это писал человек или нейросеть» — и почему разговор об авторстве уже упирается в SIP, DR и MAP.

Я руковожу компанией, которая с 2012 года занимается описанием бизнес-процессов и внедрением систем класса ERP. За это время мы не раз сталкивались с одной и той же проблемой: бизнес-процесс вроде бы можно описать словами, можно нарисовать схему, можно составить таблицу операций, но в момент проверки выясняется, что документ не держит реальное исполнение. В нём не хватает предметов, состояний, источников, ролей, переходов, прикладных носителей, исключений и проверок. Такой документ выглядит убедительно, но не позволяет понять, как именно процесс должен работать в системе и как его проверить.

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

Так возникла ЕСППД-ИИ — Единая система процессно-предметной документации для искусственного интеллекта. Это наш внутренний стандарт работы с документацией, а не государственный ГОСТ, не рекламный продукт и не название компании. В этой методичке я объясняю не все технические детали стандарта, а человеческий маршрут: как начать описывать бизнес-процессы так, чтобы с ними мог работать искусственный интеллект и чтобы результат не превращался в имитацию.

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

SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou всё активнее строят вокруг корпоративного ИИ семантические слои: knowledge graph, ontology, process intelligence, business data cloud, agent memory и агентные платформы.

Зачем им это, если языковая модель уже умеет читать документы, таблицы и API?

Потому что корпоративному ИИ нужен не только доступ к данным. Ему нужен смысловой слой предприятия: термины, объекты, экземпляры, статусы, источники, связи и правила качества.

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