О таксономии, онтологии и регламенте использования общего предметного языка в корпоративных ИИ-инструментах.

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

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

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

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

Что такое семантическое ядро предприятия

Семантическое ядро предприятия — это не глоссарий в конце регламента и не папка с методичками. Это машинно-читаемый пакет, в котором зафиксированы ключевые термины предприятия, бизнес-предметы, их классификация, связи, состояния, носители, источники, спорные места и правила использования этих смыслов человеком и LLM. В минимальном варианте это может быть набор Excel-файлов, JSON-файлов и текстовых инструкций. В более зрелом варианте это может быть база знаний, граф, внутренний портал или слой корпоративного ассистента. Но начинать можно очень просто: с управляемого Excel-core и набора регламентных промптов.

В этом ядре должны быть зафиксированы не только «слова и определения», а рабочие различения. Например, «заказ клиента», «заказ поставщику», «заказ на производство», «ремонтный заказ» и «внутренний заказ» не должны жить под одним общим словом «заказ». Это разные предметы предприятия. У них разные владельцы, основания возникновения, статусы, ERP-объекты, документы, последствия, риски и KPI. Точно так же «операция» может быть технологической операцией, хозяйственной операцией, платёжной операцией, складской операцией, операцией качества или операцией робота. Слово одно, предметы разные.

Семантическое ядро нужно для того, чтобы предприятие перестало каждый раз заново объяснять модели, что оно имеет в виду. Если ядра нет, каждый сотрудник пишет собственный контекст в промпте, а модель собирает собственную локальную картину. Если ядро есть, сотрудники работают в общем смысловом поле. Они могут использовать разные LLM-инструменты, но смысловой слой остаётся единым.

Таксономия, онтология и семантическое ядро

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

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

Семантическое ядро — это практический рабочий пакет, который соединяет таксономию, онтологические профили, ERP-связи, СМК-связи, учётные признаки, KPI, источники, регламенты и правила использования в LLM. Это не философская конструкция. Это то, что можно положить в корпоративную папку, зашить в Excel/JSON, приложить к промптам и использовать в ежедневной работе.

Почему это относится к 1С:ERP

1С:ERP уже содержит сильный предметный слой. В ней есть документы, справочники, регистры, статусы, реквизиты, движения и маршруты. На практике это часто единственный более-менее устойчивый слой предприятия, которому доверяют участники проекта. Заказ на производство можно открыть. Документ поступления можно проверить. Выпуск можно связать с движениями. Заявку на расходование денежных средств можно провести по маршруту. Это сильная сторона ERP.

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

Вот здесь и появляется семантическое ядро для 1С:ERP. Оно не заменяет ERP и не спорит с типовой конфигурацией. Оно объясняет, как предприятие понимает свои предметы и как эти предметы связаны с объектами ERP, СМК, управленческим учётом, KPI и документами. Для консультанта это снижает риск неправильной интерпретации требований. Для аналитика это даёт язык описания процессов. Для пользователя это даёт узнаваемые термины. Для LLM это даёт запрет на самостоятельное сочинение смысла.

Как это должно выглядеть в компании

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

Затем ядро оформляется в машинно-читаемом виде. На первом этапе это может быть Excel-core с листами: реестр терминов, реестр бизнес-предметов, таксономия предметов, карточки таксонов, связи с объектами 1С:ERP, связи с СМК-документами, связи с учётными объектами, связи с KPI, реестр конфликтов терминов, GAP-реестр и правила использования ИИ. Параллельно можно сделать JSON-выгрузку для тех, кто хочет подключать ядро к внутренним инструментам, корпоративным ассистентам или базам знаний.

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

Дальше сотрудникам выдаётся типовой промпт. Например:

«Ты работаешь с материалами нашего предприятия. Используй приложенное семантическое ядро как обязательный источник терминов, бизнес-предметов, состояний и связей. Не переопределяй термины самостоятельно. Если в запросе встречается слово, которое имеет несколько значений в ядре, сначала уточни контекст. Не смешивай бизнес-предмет, документ, статус, реквизит, KPI и носитель. Если нужного предмета нет в ядре, пометь его как кандидат и сформулируй вопрос для уточнения, а не придумывай определение».

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

Почему это резко повышает качество ответов

LLM хорошо работает с текстом, но плохо переносит локальный смысл предприятия без явной опоры. Если не дать ей ядро, она начинает восстанавливать смысл по вероятностной близости слов. Для обычного текста этого иногда достаточно. Для ERP, производства, СМК и управленческого учёта этого недостаточно. Там одно слово может иметь несколько допустимых смыслов, а разные слова могут указывать на один и тот же предмет.

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

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

Пример: «серия» на предприятии

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

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

В семантическом ядре это решается иначе. Сначала фиксируется конфликт употребления. Затем выделяются возможные предметы: «серия изделия», «серийный номер», «производственная партия», «партия контроля», «складская серия», «регистрационная серия». Потом каждый предмет проверяется по процессам, ERP-носителям, СМК-документам, учётным последствиям и человеческому употреблению. Часть кандидатов подтверждается, часть объединяется, часть отклоняется, часть уходит в GAP. После этого LLM получает не слово «серия», а карту допустимых смыслов и правило уточнения контекста.

Метод предметного захвата

Главная работа состоит не в том, чтобы красиво описать уже известные термины. Главная работа — захватить фрагмент реальности предприятия и переработать его в управляемые предметы. У предприятия нет готовой аккуратной онтологии. Есть процессы, документы, ERP-объекты, СМК-формы, Excel-таблицы, регламенты, жаргон, привычки, конфликты понимания и сильные сотрудники, которые «и так всё знают».

Метод предметного захвата должен брать этот фрагмент реальности и пропускать его через несколько проекций. Операционно-процессная проекция спрашивает, где предмет возникает, кто с ним работает, какой вход и выход у процесса, какие состояния и переходы есть. ERP-проекция спрашивает, какими объектами 1С это фиксируется. Учётная проекция спрашивает, является ли это фактом хозяйственной жизни, объектом учёта, статьёй, аналитикой или методологической единицей. СМК-проекция спрашивает, является ли это событием качества, записью качества, процедурой или доказательным носителем. Документарная проекция смотрит на договоры, приказы, регламенты, ТУ, РЭ и инструкции. KPI-проекция смотрит, какие параметры и управленческие последствия связаны с предметом. Человеческая проекция проверяет, как этот предмет реально понимают участники предприятия.

Только после такого прохода можно сказать: это бизнес-предмет; это не предмет, а статус; это не предмет, а документ-носитель; это не один предмет, а несколько разных предметов; это локальный синоним; это спорный термин; это кандидат в GAP.

Зачем нужен регламент

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

Регламент может звучать просто: если сотрудник использует LLM для подготовки материалов по ERP, СМК, управленческому учёту, производству, качеству, бюджетированию, закупкам, складу или сервису, он обязан прикладывать актуальную версию семантического ядра или использовать корпоративного ассистента, в котором это ядро уже подключено. Если модель встречает термин с несколькими значениями, она должна уточнять контекст. Если нужного предмета нет в ядре, она должна формировать карточку кандидата и вопрос на уточнение. Если термин противоречит утверждённому ядру, модель должна показать конфликт, а не молча переопределять смысл.

Это не бюрократия. Это техника безопасности. Предприятие уже не сможет запретить всем использовать ИИ. Но оно может дать общий смысловой слой и снизить хаос.

Что можно получить на выходе

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

В минимальном варианте пакет может включать Excel-core, JSON-выгрузку, краткую методику, регламент использования, типовые промпты, реестр спорных терминов и инструкцию для сотрудников. В более развитом варианте это превращается в доменную карту предприятия и граф знаний. Но для начала не нужно строить космический корабль. Достаточно перестать заставлять каждую LLM-модель заново угадывать, что предприятие имеет в виду под своими ключевыми словами.

Что не вошло в концепцию 1С:ERP 2026

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

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

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

Как создать семантическое ядро предприятия для Ии — Бизнес-литература автора Кирилл Ледовский | Читать онлайн на Литнет

Вместо вывода

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

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

Вопрос не в том, будут ли сотрудники использовать LLM. Будут. Вопрос в том, даст ли предприятие этим сотрудникам общий предметный язык. Если даст, ИИ начнёт усиливать управление. Если не даст, он начнёт усиливать терминологический хаос.

LLM уже работают в компаниях. Как организовать единое семантическое ядро предприятия?