Авторы: Владимир Нешкес, Екатерина Пужанова, Наталья Мещерекова

---

Введение: проблематика

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

• сроки ввода объектов сжимаются;
• растёт давление владельцев проекта, чтобы снизить CAPEX и оптимизировать OPEX;
• внешняя среда (рынки и конкуренция, технологии и инновации, регуляторика и ограничения) меняется быстрее, чем длится жизненный цикл проекта.

Это приводит к широкому распространению подходов параллельного проектирования и строительства (concurrent engineering, fast‑track), когда:

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

В таких условиях управляемость проекта в значительной степени зависит от того, насколько:

1. структурирован весь объём инженерной и проектной (в широком смысле этого термина) документации;
2. прозрачно и предсказуемо организован поток документов между участниками;
3. синхронизированы календарные планы выпуска документации, закупок и строительства.

В такой ситуации наиболее уязвимыми точками оказываются:

• несвоевременное предоставление рабочей документации на площадку;
• ошибки и коллизии в рабочей документации;
• задержки в предоставлении документации от поставщиков (vendor data);
• коллизии между проектными решениями и фактическими характеристиками поставляемого оборудования;
• разночтения между версиями инженерной документации и снижение доверия к «актуальной» ее версии.

В ответ на эту проблематику в мировой EPC‑практике оформились два ключевых инструмента:

• MDR (Master Document Register или, как его еще называют, Master Deliverables Register) — основной реестр проектной, инженерной и смежной документации проекта;
• VDR (Vendor Document Requirements, или как его еще называют, Vendor Data Requirements / Vendor Document Register) — требования к документации (или данным) от поставщиков и структурированный реестр этой документации или данных.

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

Что происходит без MDR и VDR (антикейсы)

Рассмотрим некоторые антикейсы (негативные сценарии), достаточно часто встречающиеся в промышленных проектах.

Антикейс 1. Разрозненные списки документов и «слепые зоны» по готовности

Ситуация: EPC‑подрядчик ведут учёт своих документов в отдельных Excel‑таблицах по каждому из инженерных направлений: АР, КЖ, КМ, ТХ, ЭОМ и т.д. Так исторически сложилось, когда у каждого профильного инженера - своя Excel‑таблица, а единого интегрирующего реестра (как MDR) нет.

Последствия такого подхода:

• Менеджер по закупкам не видит, какие документы уже готовы и согласованы для запуска тендеров, он работает «по заявкам»;
• Менеджер по строительству не понимает, какие комплекты рабочей документации в какой момент появятся на площадке (график выпуска РД не помогает, так как постоянно меняется);
• Заказчик получает отчёты в виде разрозненных перечней и не может оценить общую готовность инженерной документации по объекту.

В результате параллельное проектирования и строительства в параллели превращается в цепочку «сюрпризов», вместо плановой работы.

Антикейс 2. Неконтролируемый поток вендорской документации

Ситуация: в договорах с поставщиками не формализованы состав и сроки предоставления документации. Нет единого VDR.

Последствия таковы:

• разные поставщики присылают документацию в разных форматах, причем с различной глубиной проработки;
• часть критичных документов (чертежи фундаментов, габаритные и присоединительные размеры, требования к инженерным системам) поступает с опозданием;
• проектировщики и строители вынуждены работать по предварительным данным или по согласованным предположениям (согласование при этом – результат множества непростых совместных совещаний).

Ведение строительства в параллель с поставками в таких условиях ведёт к переделкам, дополнительным работам, затратам и конфликтам по ответственности.

Антикейс 3. Формальный MDR без связи с графиком и ответственностью

Типичная ситуация, когда MDR формируется, но остаётся «мертвым»:

• в нём нет чётко назначенных ответственных за каждый документ;
• отсутствуют статусы по документации, например, «выпущен для рассмотрения», «на согласовании», «утверждён», выдан для производства работ» и др.;
• не указаны целевые даты выпуска
• не увязано с календарным графиком проекта (MDR ведётся отдельно от системы планирования и контроля работ проекта).

В результате MDR превращается в справочник, а не в инструмент управления. Параллельное проектирование и строительство всё равно ведутся вслепую, потому что нет оперативной, статусной картины по документации.

История и эволюция MDR и VDR в практике реализации проектов

Исторически прообразы MDR и VDR возникли как:

• перечни проектной документации (в частности, чертежей) по различным инженерным разделам;
• приложения к контрактам на проектирование и поставку оборудования;
• элементы систем качества по ISO 9001, в частности (как пример) «строительные журналы» на площадке и др.

В ходе подготовки и реализации крупных EPC/EPCM‑проектов получила развитие стандартизация системы проектной деятельности, в частности, через поэтапные релизы PMBOK, семейств стандартов для управления проектами (ISO 21502) и активами (ISO 55000), а также развитием ИТ‑средств электронного документооборота (EDMS) и контроля инженерной документации (EDC). С учетом этого:

• Перечни инженерной документации начали оформляться в виде вполне структурированных реестров, интегрированных с календарными планами проектов, WBS/OBS (структурами), контрактами на поставки и субподряды, системами 3D-проектирования и BIM‑моделями.
• Параллельно усложнялись и требования к вендорской документации. Так, если раньше стороны часто ограничивались в переписке базовыми паспортами и инструкциями, то теперь заказчики стали запрашивать у поставщиков 3D‑модели оборудования, планы ТОиР и требования к эксплуатационному персоналу, данные для интеграции в цифровые двойники и системы управления активами (EAM/CMMS), комплекты для HAZOP/HAZID и других мероприятий по анализу безопасности и др.

В свою очередь это потребовало заняться формализацией инструментария VDR и внедрением процессов управления вендорской документацией в рамках отдельного направления.

Что такое MDR и VDR и из чего они состоят

MDR (Master Document Register)

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

Ключевые характеристики «зрелого» MDR:

1. Полнота. Критерий: в реестр включены все документы, критичные для проектирования, закупок, строительства, пуско‑наладки и ввода в эксплуатацию.
2. Ролевое наполнение. Критерий: для каждого документа определены организация/подрядчик‑разработчик, ответственное подразделение внутри этой организации, конкретное ответственное лицо.
3. Интеграция с графиком. Критерии: MDR связан с календарным графиком проекта (вехами проекта). Даты выпуска документов не произвольны, а выведены из логики: когда необходимо запустить закупку, когда начинается тот или иной вид СМР, какие документы являются предшественниками для других.
4. Статусность и трассируемость. Критерии: каждый документ в MDR имеет текущий статус, историю изменений. привязку к версиям и ревизиям, ссылки на файлы в системе электронного документооборота / электронного архива.
5. Разделение видов документации. Критерии: В MDR отражаются как проектная и рабочая документация, так и эксплуатационная, пусконаладочная, документация по охране труда, промышленной безопасности и др.

Пример типов документации (не ограничиваясь), управление которой «может взять на себя» MDR: комплекты рабочей документации, комплекты рабочих чертежей, планы, деталировочные чертежи, монтажные чертежи, альбомы цветовых и интерьерных решений, различные схемы, условные обозначения, изображения, созданные при помощи графических средств, задание на проектирование, опросные листы, технические требования, титульные списки, ведомости (BoM, BoE, BoQ), таблицы, матрицы каталоги, прочностные, архитектурные, системные и пр. расчеты, спецификации, технические требования, функциональные требования, проектные требования, процедуры, концепции и описание основных принципов, каталоги монтажных работ, блок-схемы, технологические схемы, P&ID-схемы и аналогичные по сути, эксплуатационно-техническая документация, инструкции и описание процесса, процедуры и руководства, требования к пусконаладке, программы обучения, руководства, графики и расписания и многое другое

В зависимости от особенностей объекта проектирования/строительства и иных факторов количество и содержание полей MDR может быть различным. Так, на практике MDR может содержать 50+ аналитических полей. В Таблице 1, в качестве иллюстрации, представлена упрощенная модель MDR.

Таблица 1. Пример упрощенной модели MDR

VDR (Vendor Document Requirements / Vendor Document Register)

VDR — это инструмент, фокус которого — поставщики оборудования и материалов. Он включает:

1. Требования к составу и содержанию документации. Для каждого типа поставки определяются: перечень обязательных документов, форматы и стандарты (например, совместимость с CAD/BIM‑системами заказчика), требования к языкам, единицам измерения, структуре данных, пр.
2. Требования к срокам предоставления документации. Определяется, на каком этапе жизненного цикла закупки и/или строительства должны быть предоставлены: предварительные данные (например, для определения компоновки, определения габаритов и типа фундаментов, кабельных трасс), окончательные чертежи, эксплуатационная документация, инструкции, перечни ЗИП и т.д.

VDR является достаточно близким аналогом MDR, но с фокусом на документацию, исходящую от поставщиков. Пример структурированной части VDR представлен в Таблице 2.

Таблица 1. Пример упрощенной модели VDR

Критические требования к VDR:

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

MDR и VDR как инструменты параллельного проектирования и строительства

Параллельное ведение проектирования и строительства допустимо только тогда, когда:

1. заранее понятно, какие документы необходимы, чтобы начать тот или иной вид работ на конкретном объекте;
2. известно, когда и кем эти документы будут выданы;
3. имеется действующий инструмент мониторинга статуса готовности документации относительно графика работ.

В этом смысле MDR и VDR выступают «скелетом» информационной модели проекта, интерфейсом между инженерными подразделениями, закупщиками и строителями, средством превратить параллельность в управляемую стратегию, а не в стихийный процесс.

Иллюстрация положительного влияния MDR и VDR на возможность параллельного выполнения работ в проекте:

Пример 1. Для начала бетонирования фундаментов под основное технологическое оборудование необходимы:

• рабочая документация по фундаментам (разделы КЖ/КМ);
• габаритные и присоединительные размеры (рабочие чертежи) оборудования от поставщика;
• данные по нагрузкам и динамике от технологов.

Для решения этих задач:

• MDR определяет, какие проектные документы должны быть готовы к дате X
• VDR задаёт, какие данные должны быть получены от поставщика к дате Y (причем Y < X на время, необходимо для проектирования и согласования).

Пример 2. Для прокладки кабельных трасс и коммуникаций в условиях ограниченного пространства необходимо иметь:

• 3D‑модель технологического оборудования (от поставщиков);
• 3D‑модель здания/сооружения и несущих конструкций (от проектировщика);
• координационные чертежи^[1] по дисциплинам.

Для решения этих задач:

• MDR фиксирует план выпуска координационных чертежей и моделей.
• VDR обеспечивает своевременное получение корректных 3D‑моделей и спецификаций от поставщиков.

Таким образом, MDR и VDR создают общую «временную» и «содержательную» сетку для всех участников, на которую «накладываются» параллельно выполняемые виды работ.

Современные практики применения MDR и VDR

1. Единая среда общих данных (CDE^[2]), в которой MDR и VDR функционируют, не как отдельные Excel‑таблицы, а как неотъемлемая часть цифровой среды, где:

• статусы документов обновляются автоматически по факту загрузки и согласования;
• сохраняется история ревизий и комментариев;
• доступ к документам разграничивается по ролям.

2. Интеграция с 3D/BIM‑моделями, когда документы и данные из MDR/VDR привязываются к конкретным объектам модели (оборудованию, конструкциям, системам). Это позволяет:

• визуализировать готовность документации по объектам;
• «пространственно» планировать и контролировать параллельность выполнения работ, например посредством инструментария 4D‑моделирования.

3. Связь с контрактами и SLA по документации, когда в договорах на проектирование и поставку:

• Требования к ведению MDR и VDR, соответствующие шаблоны и др. включаются в качестве неотъемлемых приложений;
• фиксируются KPI участников проекта исходя из своевременности (по актуальному графику) и качества предоставляемых документов;
• фиксируются штрафы и бонусы, связанные не только с поставкой оборудования поставщиками, но и с документацией, которую они должны предоставить.

4. Использование MDR/VDR для анализа рисков и «узких мест», когда на основе MDR/VDR выявляются:

• критические для графика проекта документы и данные от поставщиков;
• наиболее рискованные контрагенты (по срыву сроков и низкому качеству)
• наиболее критичные инженерные дисциплины или позиции поставок (по влиянию на график проекта);
• зоны, в которых из-за отсутствия необходимых данных, возможны задержки и коллизии при параллельном ведении работ.

^[1] Координационные чертежи - специальные чертежи (обычно в 2D или 3D), на которых совместно показываются решения разных инженерных разделов, чтобы проверить их согласованность между собой, например проверить согласованность архитектурных решений с конструкциями
^[2] CDE— Common Data Environment

Интегрированные инструменты применения MDR и VDR

Платформа PM.integrator позволяет перевести MDR и VDR из разрозненных реестров в интегрированный цифровой контур управления, обеспечивая их прямую интеграцию не только с графиками, но смежными дисциплинами и видами работ, создавая единое пространство координации и контроля для всех участников проекта. 

В этой среде прогресс проектирования оценивается автоматически на основе данных, определенных в MDR, что позволяет в реальном времени сопоставлять выдачу документации с плановыми вехами и оперативно перераспределять ресурсы.

Благодаря умной структуре и аналитике в привязке к технологии выполнения работ (прохождение «шагов» по MDR, VDR) платформа выявляет «узкие места» — критические задержки выполнения и/или согласования, риски несоответствия документации поставщиков (VDR), оголяя потенциальные конфликты в «прогнозе» на стыках ПИР – МТО – СМР, способные заблокировать или сорвать фронты работ на площадке. 

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

Заключение

MDR и VDR — это не просто таблицы со ссылками и характеристиками документов. В условиях параллельного проектирования и строительства они становятся:

• ключевыми инструментами координации между инженерными решениями, закупками и строительством;
• основой для управляемого параллельного выполнения работ, позволяющей начинать работы заранее, но с контролируемыми рисками;
• элементом цифрового контура проекта, необходимым для перехода к моделям «сквозного» управления жизненным циклом объектов.

Антикейсы показывают, что отсутствие или формальный подход к применению MDR и VDR ведут к хаотичному документообороту, провалам по срокам и качеству, росту конфликтов между участниками и потерь на переделки.

Современные практики демонстрируют, что при правильном методологическом и ИТ‑обеспечении MDR и VDR становятся:

• стандартной составляющей контрактов EPC/EPCM;
• основой для бенчмаркинга и повышения зрелости управления проектами;
• важным фактором успешного внедрения цифровых технологий, таких, например, как BIM, 4D ‑планирование и управление, цифровые двойники.

Дальнейшее развитие инструментов MDR и VDR связывается с более глубокой их интеграцией с информационными системами управления инженерными данными (EDMS) и системами управления производственными активами, а также с автоматизацией контроля полноты и качества выпускаемой документации на основе аналитики и, в перспективе, и методов искусственного интеллекта.

Платформа PM.integrator обеспечивает возможность интеграции MDR / VDR в единый цифровой контур управления, обеспечивая их прямую взаимосвязь не только с графиками проекта, но и смежными дисциплинами и видами работ, создавая единое пространство координации и контроля для всех участников проекта.