Как проектная модель предприятия превращается в машиночитаемое эксплуатационное ядро и живёт после завершения проекта

Начало в статье 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 — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.

Локальная LLM — локальная большая языковая модель (Large Language Model) — естественно-языковой интерфейс к Enterprise-DR. Например, для этой роли может использоваться компактная Qwen2.5-0.5B-Instruct или аналогичная локальная модель. Это пример, а не реклама и не обязательный выбор. В эталонной поставке 2.5.1 для самопроверки используется контрольная модель gate_seq2seq_transformer.pt. Далее — «LLM».

Baseline — базовая версия — принятое состояние модели, относительно которого фиксируются последующие изменения. Далее используется короткая форма «baseline».

Project-DR — технология построения и структурной перестройки цифровой реплики предприятия. Enterprise-DR — эксплуатационный результат этой работы.

Заказчику передаётся Enterprise-DR конкретного предприятия. Project-DR остаётся внутренней производственной технологией.

Введение

Первая часть статьи «ERP внедрили. Что дальше?» была опубликована на Хабре. После публикации коллеги попросили отдельно и уже без литературной прозы показать инженерную конструкцию эксплуатационного ядра: где во время Project-DR накапливается проектное знание, как из принятого состояния получается Enterprise-DR, что физически передаётся заказчику и как эта модель эксплуатируется после запуска.

Эта третья часть посвящена именно этому. Ниже рассматривается маршрут от специализированных Project Core и Unified Project Store до клиентского Enterprise-DR Runtime, обычная работа через вопросы и сигналы, а также граница, после которой изменение профессиональной модели должно быть возвращено в Project-DR.

1. Какой инженерный вопрос остаётся после завершения ERP-проекта

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

Если на этом месте сохранить только Excel-файлы, человекочитаемые документы и архив проектных материалов, то будет зафиксирован результат проекта, но не эксплуатационная профессиональная память. Через некоторое время часть смысла снова окажется в переписке, часть — в настройках ERP, часть — в инструкциях, а часть — в памяти отдельных специалистов. Поэтому принятая модель Project-DR должна перейти в отдельную форму, рассчитанную уже не на построение модели, а на её длительную эксплуатацию.

В версии 2.5.1 этот переход оформлен как отдельный технологический маршрут: Project-DR производит принятую профессиональную модель, а Enterprise-DR получает её эксплуатационную проекцию.

Ключевая граница формулируется однозначно. Project-DR является производственной технологией реконструкции и построения профессиональной модели предприятия. Enterprise-DR является эксплуатационной цифровой репликой конкретного предприятия, полученной из принятого результата Project-DR. Поэтому Enterprise-DR нельзя рассматривать ни как копию всего Project-DR, ни как ещё один отчёт внутри проекта.

2. Почему Project-DR не передаётся заказчику

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

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

В технологической сборке v2.5.1 эта граница закреплена физически. Клиентский release проходит отдельную очистку поставки: в него не должны попадать универсальные донорские модели, фабричная и генеративная логика, полная технологическая сборка Project-DR ERP, внутренний управляющий контур Project-DR и универсальные реконструкционные шаблоны. Проверяется не только наличие запрещённых файлов, но и остаточные технологические ссылки внутри данных. Критическая утечка технологии должна быть равна нулю.

Итоговое правило для поставки простое: заказчику передаётся Enterprise-DR его предприятия; Project-DR как технология реконструкции остаётся внутренним технологическим ноу-хау исполнителя. При этом профессиональные данные заказчика, его процессы, операции, нормы, сценарии, решения и доказательства не теряются. Они переходят через контролируемую границу в эксплуатационную модель, а универсальные производственные механизмы — нет.

3. Где во время Project-DR накапливается информация конкретного проекта

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

Результаты обследования хранятся в QNR Project Core: там остаются принятые ответы, уточнения периметра, операционные факты, решения и изменения модели. Операционная модель хранится в OEM Project Core: там появляются проектные предметы, библиотека процессов, направления деятельности, цепочки, процедуры и операции. Учётный слой формируется в ACC Project Core, информационная архитектура — в NPA Project Core, сценарии и результаты проверок — в SCN Project Core, а история принятых изменений удерживается в соответствующих контурах происхождения и версионирования.

Это не временная разрозненность и не дефект архитектуры. Детальный проектный результат должен оставаться у того ресурса, который отвечает за его построение и проверку. В технологической сборке v2.5.1 этот принцип сохранён: специализированный Project Core остаётся владельцем подробного проектного содержания, а в единое хранилище передаётся его трассируемая принятая проекция.

Поэтому ответ на вопрос «куда записались результаты после работы конкретного ядра?» состоит из двух частей. Подробный результат остаётся в Project Core соответствующего ресурса. После принятия результат, необходимый для общей проектной и будущей эксплуатационной памяти, синхронизируется в единое проектное хранилище.

4. Зачем понадобилось единое проектное хранилище

Распределённая модель удобна во время проектирования, но неудобна для дальнейшей машинной эксплуатации. Если оставить только специализированные Project Core, то для любого сквозного вопроса придётся сначала определять владельца объекта, затем искать связанные сведения в других ядрах, отдельно поднимать решения, версии и доказательства. Такой способ приемлем для производственной технологии, но не для постоянной эксплуатационной памяти предприятия.

Поэтому между распределёнными Project Core и Enterprise-DR введён Unified Project Store — единое проектное хранилище Project-DR. Оно не заменяет специализированные ядра и не забирает у них ответственность за подробное содержание. Его функция состоит в том, чтобы собрать принятые проектные объекты в общей структуре и удерживать их единую идентичность, связи, версии, происхождение, решения, доказательства и базовые состояния.

Например, подробное описание операции продолжает принадлежать OEM Project Core. Но единое хранилище должно однозначно знать, что существует операция OP-117, к какой процедуре и процессу она относится, какой бизнес-предмет изменяет, какой ролью выполняется, каким объектом ERP реализована, каким сценарием проверяется и каким решением была изменена её текущая версия. Именно такую сквозную связанность создаёт Unified Project Store.

Единое проектное хранилище поэтому является не новой методологией и не ещё одним отчётом. Это машинная сборка принятых результатов Project-DR, необходимая для того, чтобы из распределённой производственной среды получить единое состояние конкретного предприятия.

5. Как Project-DR накапливает единое состояние предприятия

Unified Project Store не собирается вручную один раз в конце проекта. Состояние накапливается по мере того, как специализированные результаты проходят принятие. Пока предмет, процесс, операция или правило находятся в разработке, их подробное состояние остаётся в Project Core владельца. После принятия в единое проектное хранилище публикуется версионированная проекция этого объекта вместе с указанием источника, типа, естественного идентификатора, статуса, базовой версии и происхождения.

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

К завершению Project-DR единое проектное хранилище содержит уже не набор независимых записей, а связанное принятое состояние предприятия. При этом обратная трассировка сохраняется: любой объект можно связать с его Project Core, исходной записью, решением и доказательством. В версии 2.5.1 Project Core дополнительно ведёт состояния синхронизации, состояние Enterprise-DR, индекс выпущенных Enterprise-DR release и индекс собранных runtime-комплектов. Отдельный Project Enterprise-DR Core удерживает синхронизацию Project Store, выпуски release, runtime instances, change sets, структурные возвраты, доказательства, QA и runtime kits.

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

6. Что фиксируется перед выпуском Enterprise-DR

Project-DR содержит не только окончательные результаты. В процессе работы в нём присутствуют гипотезы, промежуточные варианты, ещё не принятые связи и рабочие версии. Enterprise-DR нельзя строить из всего этого массива. Эксплуатационная модель должна начинаться с однозначно определённого принятого состояния предприятия.

Поэтому перед компиляцией фиксируется принятая базовая версия Unified Project Store. Сначала синхронизируются принятые проекции специализированных Project Core, затем проверяются идентичность, связи и происхождение объектов, после чего проектное состояние фиксируется как исходная baseline для выпуска. Только после этого определяется клиентский периметр и разрешается компиляция Enterprise-DR.

Такой порядок обеспечивает три свойства. В эксплуатационную систему не попадают случайные рабочие версии. Каждое включённое утверждение имеет источник в Project-DR. Дальнейшие изменения сравниваются с конкретной базовой версией, а не с неопределённым «состоянием на момент запуска». Именно здесь проектная модель становится версионируемым профессиональным результатом, пригодным для выпуска в эксплуатацию.

7. Как Project-DR превращается в Enterprise-DR

После фиксации принятой baseline начинается не копирование файлов, а компиляция эксплуатационной модели. На вход компилятора поступает Unified Project Store. Затем применяется клиентская политика компиляции: выбираются только принятые объекты конкретного предприятия, их действующие версии, разрешённые связи, необходимые доказательства и решения. Результатом становится кандидат Enterprise-DR release.

Следующий шаг — delivery scrub, то есть контроль границы поставки. Он удаляет и блокирует всё, что относится к реконструкционной технологии Project-DR, но не требуется для эксплуатации предприятия. После успешной проверки формируется neutral Enterprise-DR release — машиночитаемый пакет модели конкретного предприятия, логически отделённый от физического сервера, на котором он будет работать.

Последовательность перехода выглядит так: специализированные Project Core → принятые проекции → Unified Project Store → принятая Project-DR baseline → customer compile policy → Enterprise-DR release candidate → delivery scrub → neutral Enterprise-DR release. Только после этого начинается отдельный маршрут клиентского runtime.

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

Project Core → Unified Project Store → принятая Project-DR baseline → compile → delivery scrub → Enterprise-DR release

8. Что находится внутри Enterprise-DR

После компиляции Enterprise-DR является самостоятельным эксплуатационным объектом. Его основной единицей становится не документ и не страница отчёта, а профессиональная сущность: бизнес-предмет, процесс, процедура, операция, роль, правило, сценарий, решение, доказательство или прикладная привязка. Эти сущности существуют не изолированно, а в системе явных отношений.

Операция может относиться к процедуре и процессу, изменять состояние предмета, выполняться определённой ролью, реализовываться объектом ERP и проверяться сценарием. Решение связано с изменёнными объектами и версией, которую оно породило. Доказательство связано с результатом, который подтверждает. Благодаря этому Enterprise-DR хранит не только сведения «что есть», но и причинную структуру «как связано» и «почему принято».

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

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

9. Почему эталонная реализация использует PostgreSQL

Excel удобен как рабочий носитель Project-DR, потому что позволяет быстро просматривать, проверять и перестраивать сложные проектные структуры. Для долговременной эксплуатации требуются другие свойства: многопользовательская работа, транзакции, устойчивые связи, контроль версий, API-доступ и возможность безопасно использовать данные без передачи всей модели каждому пользователю.

В технологической сборке v2.5.1 физически проверенной эталонной реализацией Enterprise-DR является PostgreSQL 18.1. Для семантического поиска предусмотрено расширение pgvector 0.8.5. Это не означает, что профессиональная модель принадлежит конкретной СУБД или должна всегда разворачиваться только на PostgreSQL. PostgreSQL является reference implementation, на которой проверен полный маршрут от клиентского release до работающего runtime.

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

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

10. Почему аналитик и языковая модель не работают с PostgreSQL напрямую

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

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

Операция resolve_context собирает действующую версию объекта, его непосредственные связи, происхождение и необходимые доказательства. Для пользователя или локальной модели результатом становится компактный пакет профессионального смысла, а не набор таблиц PostgreSQL. Благодаря этому физическая схема базы может развиваться независимо от интерфейса пользователя.

API одновременно является границей безопасности. Языковая модель не получает произвольного доступа к UPDATE или DELETE. Она может обращаться только к предусмотренным операциям. Поэтому большая профессиональная память предприятия не превращается в огромное контекстное окно: для конкретного вопроса API выбирает только тот участок модели, который действительно нужен для ответа.

11. Какую роль выполняет локальная модель

Локальная языковая модель не является собственником профессионального знания и не определяет, какая версия модели предприятия считается действующей. Знание находится в Enterprise-DR. Модель выполняет интерфейсную функцию: понимает запрос человека, вызывает разрешённую операцию API и преобразует полученный профессиональный контекст в понятный ответ.

Такое разделение существенно снижает зависимость от конкретной LLM. Если поиск объектов, связей, версий и доказательств выполняет Enterprise-DR, языковой модели не требуется каждый раз восстанавливать предприятие из большого набора документов. Ей передаётся уже собранный контекст. Поэтому локальная LLM может быть заменена без перестройки профессиональной памяти.

В стандартном Windows runtime-kit версии 2.5.1 физически включена локальная контрольная модель Gate-B gate_seq2seq_transformer.pt. Это замороженная нейромодель, использованная в исследовательском Gate-B и повторно проверенная при сборке версии 2.5.1. Она не позиционируется как универсальная промышленная LLM для реального предприятия. Её функция — обеспечить известный локальный интерфейс, самопроверку и доказать, что весь контур может работать без обязательного облачного вызова.

Для промышленной эксплуатации предприятие может использовать другую локальную LLM, соответствующий его языку, нагрузке, аппаратуре и требованиям информационной безопасности. В закрытом контуре база, API, локальная LLM и доказательства могут находиться внутри корпоративной сети; внешнее облако для штатной эксплуатации не требуется.

12. Обычная эксплуатация: профессиональный вопрос

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

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

Языковая модель не должна угадывать связи. Если вопрос относится к операции, контекст может включать процесс, роль, правило, прикладную привязку, решение и доказательство. Если подтверждённого основания нет, корректным результатом является указание на отсутствие такого основания, а не правдоподобное объяснение, сгенерированное моделью.

Reference customer release внутри технологической сборки v2.5.1 минимален и предназначен только для проверки маршрута запуска. Он не изображает модель реального предприятия. В рабочем проекте этот демонстрационный набор заменяется скомпилированным customer release, полученным из Unified Project Store конкретного заказчика.

вопрос → профессиональный адрес → resolve_context → действующий контекст → локальная модель → ответ

13. Эксплуатационный сигнал: когда вопрос становится событием

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

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

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

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

14. Что Enterprise-DR может изменять самостоятельно

Enterprise-DR должен уметь накапливать эксплуатационную историю без запуска нового Project-DR по каждому событию. Поэтому внутри runtime могут изменяться состояния исполнения, сигналы, наблюдения, доказательства, результаты проверок, статусы runtime-комплектов и другие данные, которые описывают жизнь уже принятой модели, но не меняют её профессиональную конструкцию.

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

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

15. Почему новое состояние нельзя переписывать поверх старого

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

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

Так формируется эксплуатационная цифровая нить: исходный сигнал → рассмотренный контекст → решение → затронутый объект → новая версия → доказательство проверки. Даже если итогом становится возврат в Project-DR, этот пакет уже содержит всю эксплуатационную историю, с которой проектный контур должен начать работу.

16. Кто обладает властью изменить профессиональную модель

Наличие локальной LLM не меняет распределение профессиональной власти. Языковая модель может разобрать сигнал, подобрать контекст, показать зависимости и подготовить проект изменения, но не имеет права самостоятельно объявить новую профессиональную модель предприятия действующей.

Если анализ показывает, что требуется изменение принятой модели, Enterprise-DR формирует структурированный пакет: сигнал, действующий контекст, затронутые объекты, предварительный анализ влияния, решение уполномоченного человека и имеющиеся доказательства. Этот пакет становится входом нового маршрута Project-DR.

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

17. Когда Enterprise-DR возвращает работу в Project-DR

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

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

Это правило можно сформулировать кратко: Enterprise-DR эксплуатирует принятую профессиональную модель; Project-DR строит и перестраивает саму конструкцию этой модели. Поэтому изменение модели является не свободным редактированием базы, а новым заказом на Project-DR соответствующего масштаба.

Enterprise-DR эксплуатирует принятую профессиональную модель. Project-DR строит и перестраивает саму конструкцию этой модели.

18. Как результат нового Project-DR возвращается в Enterprise-DR

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

Если появился новый предмет управления, выполняется его предметная проработка. Если перестраивается операционная модель, изменяется соответствующий участок OEM. Если затронуты учёт, данные, качество, интерфейс или сценарии, подключаются соответствующие Project Core. После принятия новые результаты снова синхронизируются в Unified Project Store.

Затем повторяется стандартный выпуск: фиксируется новая принятая Project-DR baseline, применяется customer compile policy, выполняется delivery scrub и формируется новая версия Enterprise-DR release. Эта версия загружается в runtime и после проверки становится новым эксплуатационным состоянием предприятия.

Получается замкнутый жизненный цикл: Enterprise-DR обнаруживает границу действующей модели → Project-DR перестраивает необходимую часть → новая принятая Project-DR baseline компилируется → Enterprise-DR получает новую версию и продолжает эксплуатацию.

Enterprise-DR → structural handoff → Project-DR → новая baseline → новый Enterprise-DR release → продолжение эксплуатации

19. Что физически получает заказчик

После отделения Enterprise-DR состав клиентской поставки становится однозначным. Заказчику не передаётся технологическая сборка Project-DR ERP с её 29 ресурсами. Ему передаётся эксплуатационный runtime конкретного предприятия, собранный из принятого клиентского release.

В версии 2.5.1 стандартный формат такой поставки задан как ENTERPRISE-DR_<CUSTOMER>_<VERSION>_WINDOWS_x64_RUNTIME_KIT.zip. В комплект входят клиентский Enterprise-DR release, схема и средства развёртывания базы, Enterprise-DR API, локальная LLM, конфигурация, скрипты запуска и самопроверки, manifest, контрольные суммы и доказательные материалы. В reference-поставке физически присутствует контрольная модель Gate-B.

Технология предусматривает два режима. Connected reference bootstrap может получить закреплённые внешние runtime-компоненты автоматически. Для полностью закрытого предприятия тот же runtime-kit должен быть заранее собран с заполненным vendor_cache, чтобы после передачи заказчику не требовался выход в Интернет. Подготовка автономного набора становится операцией исполнителя до приёмки поставки.

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

20. Как проверяется поставка и чем заканчивается проект

В версии 2.5.1 проектный маршрут заканчивается не формированием neutral release, а физической клиентской поставкой. В XCORE-EDR 1.1.0 введены операции EDR-015 «Сборка клиентского runtime-комплекта» и EDR-016 «Приёмка и передача runtime-комплекта». Их завершает блокирующий Gate EDR-G09 «Клиентская runtime-поставка».

Перед передачей проверяются клиентский release, база и механизм её инициализации, API, конфигурация, локальная контрольная модель, контрольные суммы, self-test и доказательства. Для закрытого профиля дополнительно проверяется полнота vendor_cache. Поэтому Enterprise-DR считается поставленным не в момент генерации JSON или SQL, а только после того, как эксплуатационный комплект физически собран и готов к запуску в согласованной среде.

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

В результате жизненный цикл ERP перестаёт завершаться архивированием проектных материалов. Project-DR используется для построения и структурного изменения профессиональной модели; Enterprise-DR — для её повседневной эксплуатации. Между ними существует контролируемый переход в обе стороны. Project-DR заказчику не передаётся как производственная технология. Заказчику передаётся Enterprise-DR — машиночитаемая, версионируемая и эксплуатируемая профессиональная модель его предприятия.

Краткий итог

Архитектура версии 2.5.1 отделяет производственную технологию от клиентского эксплуатационного результата. Специализированные Project Core накапливают подробное проектное содержание, Unified Project Store собирает принятые проекции в единую машиночитаемую память, а компилятор выпускает очищенный Enterprise-DR конкретного предприятия. После этого клиентский runtime разворачивает эту модель в базе данных, предоставляет к ней контролируемый API и, при необходимости, локальный языковой интерфейс.

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

ERP внедрили. Что дальше? Часть III. От Project-DR к Enterprise-DR