Как справочники, процессы, роли, документы и показатели превращаются в общий язык управленческой памяти
Вопрос подписчика: Мы уже навели порядок в справочниках 1С:ERP: номенклатура, склады, подразделения, ресурсные спецификации, статьи затрат. Зачем после этого ещё какой-то глоссарий Nexus и семантическое ядро?
ERP-Мастер: Порядок в справочниках — это порядок в данных. Но предприятию нужен ещё порядок в смыслах.
Справочник помогает системе хранить данные: номенклатуру, склады, подразделения, рабочие центры, статьи затрат, договоры, контрагентов, группы финансового учёта, каналы продаж и другие элементы.
Но справочник сам по себе не всегда объясняет, что именно предприятие считает предметом управления, кто за него отвечает, каким процессом он проходит, каким документом подтверждается, какой статус у него может быть, какое событие меняет этот статус, какой показатель зависит от этого события и какое управленческое решение должно быть принято.
Например, в 1С:ERP может быть справочник номенклатуры. Но за ним стоят разные управленческие смыслы: материал, полуфабрикат, готовая продукция, средство технологического оснащения, упаковка, услуга, аналог, замена, группа учёта, объект себестоимости, объект интеграции с инженерной системой.
Если эти смыслы не разведены, справочник вроде бы заполнен, но управление всё равно остаётся мутным.
ERP-Мастер: справочники помогают 1С:ERP хранить данные. Глоссарий Nexus помогает предприятию одинаково понимать процессы, роли, документы, показатели и решения.
Почему обычный словарь не подходит предприятию
Вопрос подписчика: А почему нельзя сделать обычный словарь? Термин — определение. Термин — определение. Разве этого мало?
ERP-Мастер: Для чтения текста иногда достаточно. Для ERP-проекта, управленческого учёта, бизнес-процессов и ИИ-контура — нет.
Обычный словарь отвечает на вопрос: что значит слово.
Глоссарий Nexus отвечает на другой вопрос: какое место занимает термин в живом контуре предприятия.
Возьмём слово «статус». Если написать, что статус — это состояние объекта, вроде бы всё понятно. Но для ERP-проекта этого мало.
Нужно знать:
- какого объекта это статус;
- кто имеет право его изменить;
- какое событие переводит объект в новый статус;
- каким документом или системным действием подтверждается переход;
- какие действия после этого разрешены;
- какие действия запрещены;
- какой отчёт, показатель или риск зависит от этого статуса.
Если этого нет, статус превращается в ярлык. Один сотрудник пишет «готово», другой — «закрыто», третий — «проверено», четвёртый — «в работе». Потом руководитель пытается понять, что реально произошло, а система не может дать честный ответ.
ERP-Мастер: предприятие управляется не словами, а связями между словами, предметами, действиями, документами и ответственностью.
Что такое Глоссарий Nexus простыми словами
Вопрос подписчика: Тогда что такое Глоссарий Nexus?
ERP-Мастер: Глоссарий Nexus — это связанная карта терминов предприятия.
В обычном словаре важное слово получает объяснение. В Глоссарии Nexus важное слово получает место в архитектуре управления.
Для каждого значимого термина нужно понять:
- в каком слое предприятия он живёт;
- что это за тип сущности;
- какой у него ближайший род;
- чем он отличается от похожих терминов;
- с какими процессами, документами, ролями и показателями связан;
- какие у него допустимые состояния и события;
- какие права доступа или роли его обслуживают;
- с чем его нельзя смешивать;
- можно ли использовать этот термин в ИИ-контуре как утверждённый.
Глоссарий Nexus не нужен для красоты. Он нужен для того, чтобы предприятие, ERP-система, проектная команда, руководители, инструкции, роботы и ИИ-помощники не говорили разными языками.
ERP-Мастер: Глоссарий Nexus — это не алфавитный список слов. Это карта связанного языка предприятия.
Что такое семантическое ядро предприятия
Вопрос подписчика: А семантическое ядро — это то же самое, что глоссарий?
ERP-Мастер: Не совсем.
Глоссарий Nexus — один из главных рабочих инструментов семантического ядра. Но семантическое ядро шире.
Семантическое ядро предприятия — это слой общего языка, который связывает данные, процессы, роли, документы, показатели, учёт, бюджет, инструкции, роботов и ИИ-контур.
В него входят:
- справочники 1С:ERP;
- предметы управления;
- бизнес-процессы;
- процедуры;
- роли и ответственность;
- права доступа;
- документы и факты;
- статусы и события;
- показатели и финансовые последствия;
- бюджетные статьи;
- операционные инструкции;
- сценарии проверки;
- роботы;
- правила использования данных в ИИ-контуре.
Семантическое ядро не заменяет 1С:ERP. Оно не является новой программой вместо ERP. Оно объясняет, что означают данные, которые уже есть в ERP, в процессах, в учёте, в бюджетировании, в инструкциях, в проектных документах и в управленческих решениях.
ERP-Мастер: семантическое ядро — это не новая программа вместо 1С:ERP. Это слой смысла, который связывает данные, процессы и решения.
Пример: слово «роль» как источник проектных ошибок
Вопрос подписчика: Можете привести простой пример, где терминологическая путаница реально мешает проекту?
ERP-Мастер: Самый простой пример — слово «роль».
В проекте этим словом могут назвать всё что угодно:
- должность;
- пользователя;
- процессную роль;
- владельца процесса;
- исполнителя шага;
- профиль доступа;
- группу доступа;
- ограничение доступа по данным;
- участника согласования;
- робота как исполнителя действия.
Если это не развести, появляются очень практические ошибки.
Например, человеку дали профиль доступа в 1С:ERP, и команда решила, что теперь он отвечает за процесс. Но профиль доступа отвечает только на вопрос: что пользователь технически может сделать в системе.
А процессная роль отвечает на другой вопрос: за какое действие, решение, проверку или результат участник отвечает в процессе.
И наоборот: человека назначили владельцем процесса, но забыли проверить, есть ли у него права увидеть нужные документы, отчёты, статусы и аналитику. Формально ответственность назначена, а практически выполнить её невозможно.
ERP-Мастер: права доступа отвечают на вопрос «что можно сделать в системе». Процессная роль отвечает на вопрос «за что человек отвечает в процессе». Это разные вещи.
Пример: статус, событие, факт и комментарий
Вопрос подписчика: А кроме ролей есть такие же опасные слова?
ERP-Мастер: Да. Очень часто смешивают статус, событие, факт и комментарий.
Статус отвечает на вопрос: в каком состоянии находится объект.
Событие отвечает на вопрос: что произошло.
Факт отвечает на вопрос: что действительно подтверждено.
Комментарий — это пояснение человека. Он может быть полезен, но он не должен заменять статус, событие или подтверждённый факт.
Простой пример:
«Средства технологического оснащения недоступны» — это событие или причина.
«Партия заблокирована» — это статус.
«Операция выполнена и подтверждена» — это факт.
«Ждём мастера» — это комментарий.
Если всё это хранится в одном текстовом поле, предприятие теряет управляемость. Руководитель видит много записей, но не понимает, что реально произошло: объект изменил статус, событие требует реакции, факт подтверждён или это просто человеческая заметка.
ERP-Мастер: комментарий не должен заменять статус, событие или подтверждённый факт. Иначе предприятие управляется перепиской, а не системой.
Как термин превращается в управляемую сущность
Вопрос подписчика: Как понять, что термин уже достаточно хорошо описан?
ERP-Мастер: У термина должен быть адрес.
Если термин важен для управления, его нельзя оставлять на уровне «все примерно понимают». Нужно ответить на несколько вопросов.
Что это такое? К какому типу сущностей относится? Чем отличается от соседних понятий? В каком слое предприятия живёт? Какие у него атрибуты? Какие состояния и статусы возможны? Какие события его меняют? Какие роли и права доступа нужны? Какие документы, регистры, отчёты или артефакты его фиксируют? С какими процессами, показателями, бюджетом, учётом и роботами он связан?
Например, термин «партия» не должен означать просто «количество». В производственном предприятии партия может быть носителем движения, прослеживаемости, статуса, качества, маршрута, операции, складского положения, факта выполнения, себестоимости и ответственности.
Если это не зафиксировать, в одном месте партия будет количеством, в другом — серией, в третьем — заказом, в четвёртом — производственным этапом, а в пятом — просто строкой отчёта.
ERP-Мастер: если у термина есть только красивое объяснение, но нет связей и границ, это ещё не термин управляемого предприятия.
Почему термин нужно определять строго
Вопрос подписчика: Но разве не достаточно написать нормальное человеческое определение?
ERP-Мастер: Человеческое определение нужно, но его мало.
В Глоссарии Nexus термин определяется не как красивая фраза, а как управленческая операция.
Нужно указать ближайший род и видовое отличие.
Ближайший род отвечает на вопрос: что это такое в более широком смысле.
Видовое отличие отвечает на вопрос: чем этот термин отличается от соседних терминов того же рода.
Например, плохое определение: «KPI — это показатель эффективности».
На первый взгляд понятно. Но слишком широко. Показателем может быть число в отчёте, финансовый результат, план-факт отклонение, метрика качества, параметр процесса, бюджетный индикатор.
Более рабочая формула: KPI — это показатель поведения процесса, рассчитываемый по определённой формуле, на основании источника данных и используемый для контроля, сценарного моделирования или управленческой реакции.
Такое определение уже отделяет KPI от случайного числа, от параметра процесса, от финансового показателя и от бюджетной статьи.
ERP-Мастер: строгое определение нужно не для академичности. Оно нужно, чтобы предприятие не путало соседние понятия и не строило на этой путанице решения.
Почему это важно для ИИ
Вопрос подписчика: А при чём здесь ИИ? Разве ChatGPT, Qwen или другая модель сама не разберётся по контексту?
ERP-Мастер: Именно в этом и риск.
ИИ умеет очень красиво достраивать смысл. В обычном тексте это иногда полезно. Но в предприятии опасно, когда смысл достраивается «примерно».
Если термин не определён, ИИ может смешать роль и профиль доступа, процесс и процедуру, событие и факт, показатель и финансовый результат, документ и артефакт, справочник и предмет управления.
Ответ может получиться гладким, убедительным и неверным.
Здесь важно не сводить проблему к бытовой фразе: «модель не понимает русский язык». Часто дело не в русском языке как таковом. Дело в том, что в проект не поставили правильный семантический слой: не выбрали подходящую модель смыслового поиска, не описали термины, не связали документы с понятиями, не задали контекст и не проверили, что запрос действительно попадает в нужный слой знаний.
Хороший внешний пример — статья на Хабре «Идеальная база знаний, а RAG возвращает мусор — проблема не там, где кажется». Автор описывает локальную мультиагентную систему: база знаний была собрана аккуратно, документы были на русском с английскими техническими терминами, но поиск возвращал мусор. Причина оказалась не в том, что «ИИ глупый» или «русский язык плохой», а в том, что использовалась неподходящая embedding-модель. Она плохо сопоставляла русские документы и смешанные русско-английские запросы. После замены на мультиязычную модель поиск заработал.
Для Nexus этот пример важен как предупреждение. В корпоративном проекте недостаточно загрузить документы и сказать: «Теперь ИИ разберётся». Если семантический слой не настроен, ИИ может не найти нужный смысл даже в идеальной базе знаний. Он будет видеть текст, но не будет попадать в правильный контекст.
Глоссарий Nexus нужен, чтобы ИИ не угадывал, а проверял.
Он должен видеть:
- термин утверждён или только предлагается;
- есть ли конфликт употребления;
- какой слой используется;
- какие связи подтверждены;
- с чем термин нельзя смешивать;
- какой источник данных является опорным;
- какая модель поиска и какой контекст должны использоваться;
- где нужно остановиться и задать уточнение.
Nexus: я не должен уверенно отвечать там, где термин не определён, связь не подтверждена, слой не указан или семантический поиск не попал в нужный контекст.
Как справочная структура 1С:ERP переходит в глоссарий Nexus
Вопрос подписчика: Как это связано с предыдущей статьёй про справочную структуру 1С:ERP?
ERP-Мастер: Очень прямо.
Сначала предприятие выстраивает справочную структуру:
- номенклатура;
- склады;
- подразделения;
- рабочие центры;
- ресурсные спецификации;
- переналадки;
- средства технологического оснащения;
- статьи затрат;
- аналитики учёта;
- каналы продаж;
- упаковка готовой продукции;
- группы финансового и аналитического учёта номенклатуры.
Затем становится понятно, что за этими справочниками стоят термины и предметы управления.
Например, номенклатура — это не просто список позиций. Это предметная карта материалов, полуфабрикатов, готовой продукции, средств технологического оснащения, услуг, упаковок, групп учёта и аналитик себестоимости.
Склад — это не просто место хранения. Это часть потока: приёмка, размещение, ячейки, доступность, качество, выдача в производство, возврат, перемещение, инвентаризация, отгрузка.
Ресурсная спецификация — это не просто состав изделия. Это связь изделия, материалов, полуфабрикатов, операций, рабочих центров, видов работ, переналадок, средств технологического оснащения и себестоимости.
Глоссарий Nexus поднимает этот язык на следующий уровень: связывает справочники с процессами, ролями, документами, событиями, статусами, показателями, бюджетом и ИИ-контуром.
ERP-Мастер: справочная структура наводит порядок в данных. Глоссарий Nexus наводит порядок в смыслах, которые стоят за этими данными.
🔗 [Подробнее: как ERP-Мастер строит справочную структуру предприятия в 1С:ERP]
Зачем нужны внешние опоры
Вопрос подписчика: Это ваша авторская терминология или есть профессиональные опоры?
ERP-Мастер: Nexus не должен придумывать язык предприятия из головы.
Внутри предприятия, конечно, есть свой язык. Но если строить семантическое ядро только на привычных словах сотрудников, оно быстро станет набором местных выражений. Для серьёзной архитектуры нужны внешние опоры.
В работе используются профессиональные языки и подходы:
- Oracle AIM / Oracle Method — для языка внедрения, задач, результатов, агентов процесса и доступа;
- UML — для сущностей, объектов, атрибутов, состояний, событий и связей;
- TOGAF и ArchiMate — для корпоративной архитектуры, слоёв, возможностей, дорожных карт и изменений;
- Gherkin / Vanessa Automation — для проверяемых сценариев и автоматизированных инструкций;
- RPA-фабрика — для роботов, входов, выходов, логов и результата исполнения.
Эти опоры не заменяют язык конкретного предприятия. Они дисциплинируют его.
Например, если мы говорим «агент процесса», нам важно не смешать его с пользователем, должностью или профилем доступа. Агент процесса — это тот, кто отвечает за выполнение и завершение конкретного шага. Это может быть человек, подразделение, система или робот, если его ответственность и результат определены.
ERP-Мастер: хороший глоссарий не является набором авторских красивостей. Он должен проверяться профессиональными языками архитектуры, внедрения, моделирования, сценариев и автоматизации.
Глоссарий должен хранить не только определения, но и связи
Вопрос подписчика: Что кроме определений должно быть в таком глоссарии?
ERP-Мастер: Главное — связи.
Отдельный термин мало что даёт. Работать начинает сеть.
Примерная цепочка выглядит так:
термин → предмет → процесс → роль → документ → статус → событие → показатель → учёт → решение
Возьмём термин «партия». Он должен быть связан с номенклатурой, количеством, складом, операцией, статусом, качеством, прослеживаемостью, документом, себестоимостью и ответственными ролями.
Возьмём термин «KPI». Он должен быть связан с процессом, параметром, формулой, источником данных, финансовым следствием, сценарием, решением и, при необходимости, бюджетной статьёй.
Возьмём термин «профиль доступа». Он должен быть связан с пользователем, группой доступа, процессной ролью, действием, объектом 1С:ERP, ограничением по данным и ответственностью за результат.
Если таких связей нет, глоссарий остаётся словариком. Если связи есть, он становится семантическим ядром.
ERP-Мастер: отдельное определение объясняет слово. Связь показывает, как это слово работает в предприятии.
Почему нужен рабочий табличный слой, а не только красивый текст
Вопрос подписчика: А это всё можно описать в Word-статье или методичке?
ERP-Мастер: Объяснить — можно. Удержать всю сеть — нельзя.
Для серьёзного предприятия глоссарий не должен жить только в красивом тексте. Нужна рабочая таблица связей: термины, определения, слои, конфликты, роли, статусы, события, документы, показатели, внешние опоры, версии и изменения.
Текст объясняет правила. Табличное ядро хранит сеть терминов и связей.
Почему это важно?
Потому что один термин может быть связан с несколькими процессами, несколькими документами, несколькими ролями, несколькими показателями и несколькими внешними опорами.
Один термин может иметь конфликтные употребления. Один статус может быть связан с несколькими событиями. Одна роль может иметь несколько профилей доступа. Один процесс может иметь несколько показателей, бюджетных статей и сценариев автоматизации.
Это невозможно честно поддерживать только в линейном тексте.
ERP-Мастер: если терминологию нельзя отфильтровать, проверить, связать и версионировать, это ещё не семантическое ядро, а просто текст.
Что получает предприятие
Вопрос подписчика: Что предприятие получает на выходе от такой работы?
ERP-Мастер: Предприятие получает не просто словарь, а управляемый язык.
Самое главное — у предприятия появляется возможность обсуждать сложные вопросы без постоянного смещения смысла.
Когда финансовый директор говорит «себестоимость», производственник говорит «выпуск», кладовщик говорит «партия», руководитель проекта говорит «готовность», а ИТ-директор говорит «права доступа», Nexus должен видеть не разрозненные слова, а связанную карту управления.
ERP-Мастер: итог такой работы — не «словарик терминов», а управляемая языковая основа предприятия.
Как это выглядит как работа ERP-Мастер
Вопрос подписчика: А как это выглядит практически? Что вы делаете?
ERP-Мастер: Практически это может быть отдельный подпроект или часть большого ERP-проекта.
Мы берём:
- справочную структуру 1С:ERP;
- бизнес-процессы;
- документы;
- роли и права доступа;
- управленческий и бухгалтерский учёт;
- показатели;
- бюджетные статьи;
- инструкции;
- сценарии автоматизации;
- проблемные термины, по которым команда спорит.
Дальше строится рабочий глоссарий:
- список ключевых терминов;
- карточки терминов;
- конфликтные употребления;
- связи между терминами;
- связи с 1С:ERP;
- связи с процессами и ролями;
- связи с учётом, показателями и бюджетом;
- правила, как эти термины использовать в ИИ-контуре.
Например, если в проекте постоянно спорят, что считать «готовой продукцией», «партией», «заказом на производство», «фактом выпуска», «ответственным», «закрытием периода», «себестоимостью» или «готовностью к запуску», эти слова должны попасть в терминологическую работу.
Не для того, чтобы написать красивое определение. А для того, чтобы потом не ошибиться в справочниках, процессах, правах, инструкциях, отчётах, себестоимости и решениях.
ERP-Мастер: мы не пишем словарь ради словаря. Мы собираем язык, который помогает предприятию управлять собой и готовиться к работе с ИИ.
Как понять, что предприятию уже нужен такой слой
Вопрос подписчика: По каким признакам понять, что нам уже нужен глоссарий Nexus или семантическое ядро?
ERP-Мастер: Есть несколько простых признаков.
Первый признак — команда спорит об одних и тех же словах. Что такое заказ? Что такое партия? Что такое готовность? Что такое факт? Кто владелец процесса? Что означает статус «в работе»?
Второй признак — отчёты не совпадают не из-за математики, а из-за разных смыслов. Финансы считают одно, производство другое, склад третье, продажи четвёртое.
Третий признак — права доступа настроены, но ответственность всё равно не ясна. Люди могут нажимать кнопки, но непонятно, кто отвечает за результат.
Четвёртый признак — инструкции есть, но сотрудники всё равно трактуют процесс по-разному.
Пятый признак — в проект начали подключать ИИ, но никто не может сказать, какие термины, данные и связи ИИ имеет право использовать как утверждённые.
ERP-Мастер: если предприятие постоянно спорит не только о решениях, но и о смысле слов, значит, ему нужен не ещё один отчёт, а общий язык управления.
Глоссарий Nexus нужен сначала людям, а уже потом ИИ
Вопрос подписчика: Получается, это всё нужно в первую очередь для искусственного интеллекта?
ERP-Мастер: Нет. Это важный момент.
Семантическое ядро нужно сначала людям.
Руководителю нужно понимать, о каком процессе идёт речь. Финансовому директору — себестоимость чего считается и по каким аналитикам. Главному бухгалтеру — какой факт отражён в учёте. Производству — какая партия, какая операция, какая переналадка и какие средства технологического оснащения участвуют. ИТ-директору — какие права нужны и какие данные защищены. Руководителю проекта — какой артефакт готов, что принято, что требует доработки.
ИИ появляется позже как усилитель. Но если люди не договорились о языке, ИИ только усилит путаницу.
ERP-Мастер: ИИ усиливает не только порядок, но и хаос. Поэтому перед ИИ-контуром предприятию нужен общий язык процессов, данных и ответственности.
Как начать
Вопрос подписчика: С чего начать, если мы хотим понять, нужен ли нам такой глоссарий?
ERP-Мастер: Начать лучше не с большого глоссария, а с вопросов к предприятию.
Где у вас чаще всего возникают споры?
Что считать заказом? Что считать партией? Что считать готовой продукцией? Кто владелец процесса? Кто имеет право менять справочник? Что является фактом? Какой статус означает готовность? Как считать себестоимость? Какие показатели действительно управленческие? Какие данные можно давать ИИ? Где ИИ должен остановиться и спросить уточнение?
После обработки вопросника можно понять, нужен ли отдельный подпроект по глоссарию Nexus и семантическому ядру или достаточно включить терминологическую работу в проект по справочной структуре, бизнес-процессам, учёту или инструкциям.
🔗 [Перейти к входному вопроснику ERP-Мастер] - в разработке
Ответы и аудиозапись можно отправить на почту: vmeste@erp-master.ru.
Первый шаг: не начинайте с вопроса «какой глоссарий написать». Начните с вопроса: какие слова в вашем предприятии уже мешают управлять, считать, отвечать за результат и принимать решения.
Материалы по теме
- 🔗 [Бизнес-процессы и автоматизированные инструкции] - в разработке
Финальная мысль
Когда предприятие наводит порядок в справочниках, оно начинает лучше хранить данные.
Когда предприятие наводит порядок в терминах и связях, оно начинает лучше понимать само себя.
А когда этот язык становится связанным, проверяемым и пригодным для ИИ-контура, появляется основа для управленческой памяти предприятия.
ERP-Мастер: справочник отвечает на вопрос, как система хранит данные. Глоссарий Nexus отвечает на вопрос, как предприятие понимает само себя.