EIR и BEP в BIM-проектировании: что это такое, чем отличаются и зачем нужны заказчику
Заказчик получил BIM-модель здания, но обнаружил, что использовать её для запланированной задачи нельзя. Геометрия инженерных систем есть, файл открывается, а получить согласованный реестр оборудования с нужными характеристиками не получается. Исполнитель считает работу выполненной: модель передана в указанном формате. Заказчик ожидал другого результата, но в исходном задании это ожидание не было подробно описано.
Такие расхождения возникают, когда стороны договариваются о наличии BIM-модели, но не фиксируют, какая именно информация нужна, зачем, к какому моменту и как будет проверяться её качество. Для управления этими вопросами в подходе ISO 19650 используются требования к обмену информацией — EIR, а команда исполнителя описывает способ их выполнения в BEP. Эти документы связаны, но не заменяют друг друга. Разберём их назначение, состав и практические критерии проверки с позиции технического заказчика и девелопера.
Такие расхождения возникают, когда стороны договариваются о наличии BIM-модели, но не фиксируют, какая именно информация нужна, зачем, к какому моменту и как будет проверяться её качество. Для управления этими вопросами в подходе ISO 19650 используются требования к обмену информацией — EIR, а команда исполнителя описывает способ их выполнения в BEP. Эти документы связаны, но не заменяют друг друга. Разберём их назначение, состав и практические критерии проверки с позиции технического заказчика и девелопера.
Что такое EIR в BIM и какую задачу он решает
EIR (Exchange Information Requirements) — требования к информации, которую одна сторона должна передать другой в определённые моменты обмена. По ISO 19650-2 их устанавливает назначающая сторона (appointing party) применительно к конкретному назначению исполнителя. В отношениях с генеральным проектировщиком этой стороной обычно выступает заказчик или его представитель; при привлечении субподрядчиков ведущий исполнитель может устанавливать собственные EIR для их информационных поставок. Требования включают в документы для выбора исполнителя и последующего оформления отношений.
В более ранней британской практике EIR расшифровывали как Employer’s Information Requirements — «информационные требования заказчика». В данном строительном контексте Employer означает заказчика, а не работодателя в трудовых отношениях. В терминологии ISO 19650 применяется Exchange Information Requirements — «требования к обмену информацией»: внимание сосредоточено на необходимой информационной поставке между участниками проекта, а не только на исходном заказчике.
Поэтому EIR — не просто перечень требований к 3D-модели и не техническое задание на выбор программы. Он должен отвечать на связанный набор вопросов: для какого действия нужны сведения → какие именно сведения → кто и когда их предоставляет → в каком виде → по каким правилам результат принимается.
От цели к проверяемому требованию
Допустим, заказчику нужно сопоставлять объёмы материалов по разделам. Требование «создать модель с высокой детализацией» почти ничего не говорит о результате. Нужно определить, какие элементы учитываются, в какой классификации, какие параметры необходимы, каким способом формируются ведомости, какие исключения допустимы и как проверяются расхождения. Если задача — анализ пересечений, набор сведений и критерии будут иными.
В подходе ISO 19650 детализация определяется через уровень информационной потребности (level of information need): сколько геометрических, буквенно-цифровых и документальных сведений достаточно для определённой цели. Это не сводится к одному числу LOD. Даже подробно смоделированное оборудование может оказаться бесполезным, если в нём отсутствуют необходимые свойства.
В более ранней британской практике EIR расшифровывали как Employer’s Information Requirements — «информационные требования заказчика». В данном строительном контексте Employer означает заказчика, а не работодателя в трудовых отношениях. В терминологии ISO 19650 применяется Exchange Information Requirements — «требования к обмену информацией»: внимание сосредоточено на необходимой информационной поставке между участниками проекта, а не только на исходном заказчике.
Поэтому EIR — не просто перечень требований к 3D-модели и не техническое задание на выбор программы. Он должен отвечать на связанный набор вопросов: для какого действия нужны сведения → какие именно сведения → кто и когда их предоставляет → в каком виде → по каким правилам результат принимается.
От цели к проверяемому требованию
Допустим, заказчику нужно сопоставлять объёмы материалов по разделам. Требование «создать модель с высокой детализацией» почти ничего не говорит о результате. Нужно определить, какие элементы учитываются, в какой классификации, какие параметры необходимы, каким способом формируются ведомости, какие исключения допустимы и как проверяются расхождения. Если задача — анализ пересечений, набор сведений и критерии будут иными.
В подходе ISO 19650 детализация определяется через уровень информационной потребности (level of information need): сколько геометрических, буквенно-цифровых и документальных сведений достаточно для определённой цели. Это не сводится к одному числу LOD. Даже подробно смоделированное оборудование может оказаться бесполезным, если в нём отсутствуют необходимые свойства.
Что такое BEP и почему его нельзя подменять требованиями заказчика
BEP (BIM Execution Plan) — план выполнения BIM-проекта в части управления информацией. Он описывает, как команда организует подготовку, совместную работу, проверку и передачу данных в ответ на установленные требования. В ISO 19650 это инструмент ведущего исполнителя и его команды, а не дополнительное название EIR.
Если EIR определяет ожидаемый информационный результат, то BEP показывает реалистичный способ его получения. В плане можно зафиксировать участников и их функции, структуру информационных моделей, правила координации разделов, использование среды общих данных (СОД/CDE), порядок обмена версиями, проверки и устранения замечаний. При этом не все связанные ресурсы обязаны находиться внутри одного файла BEP: отдельные матрицы ответственности и планы поставки информации могут оформляться приложениями или самостоятельными документами.
Предварительный и согласованный BEP
В процессе по ISO 19650-2 предусмотрены два этапа. До назначения исполнителя потенциальный ведущий исполнитель представляет предварительный BEP вместе с предложением: он демонстрирует подход команды к управлению информацией и её способность выполнить EIR. После выбора исполнителя, при оформлении договора команда уточняет и подтверждает BEP с учётом согласованного состава работ, ролей и способов взаимодействия. Утверждённую версию учитывают при оформлении договорных документов; далее план поддерживают в актуальном состоянии при согласованных изменениях.
Это принципиально при выборе исполнителя и согласовании условий сотрудничества. Формальный файл с общими словами о «координации в BIM» не доказывает, что исполнитель сможет передать конкретный набор атрибутов в нужный срок. Заказчику важно оценить соответствие предлагаемой схемы работ собственным требованиям, а не только наличие документа с названием BEP.
Если EIR определяет ожидаемый информационный результат, то BEP показывает реалистичный способ его получения. В плане можно зафиксировать участников и их функции, структуру информационных моделей, правила координации разделов, использование среды общих данных (СОД/CDE), порядок обмена версиями, проверки и устранения замечаний. При этом не все связанные ресурсы обязаны находиться внутри одного файла BEP: отдельные матрицы ответственности и планы поставки информации могут оформляться приложениями или самостоятельными документами.
Предварительный и согласованный BEP
В процессе по ISO 19650-2 предусмотрены два этапа. До назначения исполнителя потенциальный ведущий исполнитель представляет предварительный BEP вместе с предложением: он демонстрирует подход команды к управлению информацией и её способность выполнить EIR. После выбора исполнителя, при оформлении договора команда уточняет и подтверждает BEP с учётом согласованного состава работ, ролей и способов взаимодействия. Утверждённую версию учитывают при оформлении договорных документов; далее план поддерживают в актуальном состоянии при согласованных изменениях.
Это принципиально при выборе исполнителя и согласовании условий сотрудничества. Формальный файл с общими словами о «координации в BIM» не доказывает, что исполнитель сможет передать конкретный набор атрибутов в нужный срок. Заказчику важно оценить соответствие предлагаемой схемы работ собственным требованиям, а не только наличие документа с названием BEP.
EIR и BEP: основные отличия
Критерий | EIR — требования к информации | BEP — план её подготовки |
Главный вопрос | Что, для чего, когда и в каком виде передать? | Кто и какими процедурами обеспечит передачу? |
Инициатор | Назначающая сторона: заказчик либо ведущий исполнитель в отношении привлекаемых исполнителей | Потенциальный, затем назначенный ведущий исполнитель с командой |
Когда нужен | До обращения к потенциальному исполнителю и согласования условий назначения | В предложении потенциального исполнителя; уточняется и подтверждается при оформлении договора |
Основное содержание | Результаты, точки обмена, необходимая информация и критерии приёмки | Роли, взаимодействие, СОД, процессы подготовки и контроля |
Проверка качества | Соответствует ли полученная информация требованию? | Выполняется ли согласованный процесс и обеспечена ли выдача? |
Важно: таблица отражает логику ISO 19650. Точный набор документов, названия и договорные обязанности зависят от схемы проекта и применимых требований. В российской практике используются и иные обозначения, включая ПИМ.
Условная схема: требования к передаваемой информации (EIR) задают результат, план выполнения BIM-проекта (BEP) описывает организацию его подготовки, а модель служит одним из возможных результатов.
Что следует определить в EIR, чтобы модель можно было принять
Содержание EIR зависит от целей и состава работ. Универсальный шаблон допустимо использовать как основу, но каждый пункт должен быть связан с конкретным результатом. Для технического заказчика особенно важны следующие блоки.
1. Назначение данных. Для каких решений понадобятся модель, ведомости, отчёты или реестры: координация проектных разделов, оценка объёмов, анализ оборудования, передача сведений эксплуатирующей организации. Если назначение не определено, трудно обосновать требуемый состав атрибутов.
2. Состав выдачи и границы моделирования. Какие дисциплины и зоны объекта входят в работу; нужны ли отдельные модели разделов и сводная модель; какие документы и таблицы должны сопровождать передачу. Требование «все разделы в BIM» необходимо раскрывать в пределах реально заказанных работ.
3. Информационная потребность по элементам и этапам. Для каких категорий объектов обязательны геометрия, свойства, идентификаторы, классификация и сопутствующие документы. Уровень проработки должен меняться по мере решения проектных задач, а не автоматически быть максимальным для всех элементов.
4. Контрольные точки передачи. Когда заказчик получает данные, в том числе для промежуточной проверки, кто их рассматривает и сколько времени предусмотрено на замечания. Полезно отделять рабочие обмены между проектировщиками от формальной выдачи на приёмку.
5. Форматы и возможность использования. Какие нативные и открытые форматы необходимы, нужна ли конкретная версия или схема IFC, каким способом передаются связанные ведомости и документы. Само слово «IFC» не определяет полноту свойств и пригодность выгрузки для требуемой операции.
6. Правила качества и критерии приёмки. Как проверяется комплектность, корректность классификации, заполненность обязательных полей, пространственная согласованность, структура файлов и соответствие согласованным форматам. Для коллизий имеет смысл задать область и тип проверки, исключения, порядок регистрации и закрытия замечаний — а не требовать безусловного отсутствия любых пересечений.
7. Связь с информационными стандартами и правилами проекта. В EIR нужно указать, какие согласованные документы устанавливают правила доступа и защиты данных, работы в среде общих данных, управления версиями и изменениями. Эти процедуры могут находиться в отдельных информационных стандартах, регламентах и протоколах проекта; необязательно дублировать их текст в EIR. Важно согласовать ссылки, область действия документов и ответственных участников. В частности, пункт 8.1.8 СП 404.1325800.2018 предусматривает, что в требованиях заказчика отдельно оговаривают, кто организует СОД — заказчик или исполнитель.
Главная проверка для каждого пункта EIR проста: можно ли по его тексту однозначно определить состав результата и установить соответствие при передаче? Если ответ зависит от устной договорённости, требование ещё недостаточно определено.
1. Назначение данных. Для каких решений понадобятся модель, ведомости, отчёты или реестры: координация проектных разделов, оценка объёмов, анализ оборудования, передача сведений эксплуатирующей организации. Если назначение не определено, трудно обосновать требуемый состав атрибутов.
2. Состав выдачи и границы моделирования. Какие дисциплины и зоны объекта входят в работу; нужны ли отдельные модели разделов и сводная модель; какие документы и таблицы должны сопровождать передачу. Требование «все разделы в BIM» необходимо раскрывать в пределах реально заказанных работ.
3. Информационная потребность по элементам и этапам. Для каких категорий объектов обязательны геометрия, свойства, идентификаторы, классификация и сопутствующие документы. Уровень проработки должен меняться по мере решения проектных задач, а не автоматически быть максимальным для всех элементов.
4. Контрольные точки передачи. Когда заказчик получает данные, в том числе для промежуточной проверки, кто их рассматривает и сколько времени предусмотрено на замечания. Полезно отделять рабочие обмены между проектировщиками от формальной выдачи на приёмку.
5. Форматы и возможность использования. Какие нативные и открытые форматы необходимы, нужна ли конкретная версия или схема IFC, каким способом передаются связанные ведомости и документы. Само слово «IFC» не определяет полноту свойств и пригодность выгрузки для требуемой операции.
6. Правила качества и критерии приёмки. Как проверяется комплектность, корректность классификации, заполненность обязательных полей, пространственная согласованность, структура файлов и соответствие согласованным форматам. Для коллизий имеет смысл задать область и тип проверки, исключения, порядок регистрации и закрытия замечаний — а не требовать безусловного отсутствия любых пересечений.
7. Связь с информационными стандартами и правилами проекта. В EIR нужно указать, какие согласованные документы устанавливают правила доступа и защиты данных, работы в среде общих данных, управления версиями и изменениями. Эти процедуры могут находиться в отдельных информационных стандартах, регламентах и протоколах проекта; необязательно дублировать их текст в EIR. Важно согласовать ссылки, область действия документов и ответственных участников. В частности, пункт 8.1.8 СП 404.1325800.2018 предусматривает, что в требованиях заказчика отдельно оговаривают, кто организует СОД — заказчик или исполнитель.
Главная проверка для каждого пункта EIR проста: можно ли по его тексту однозначно определить состав результата и установить соответствие при передаче? Если ответ зависит от устной договорённости, требование ещё недостаточно определено.
Что заказчику нужно проверить в BEP
BEP должен объяснять, как именно исполнитель будет удовлетворять EIR. При согласовании особенно полезно искать не красивые схемы, а связи между требуемыми результатами, ресурсами команды и проверками.
Роли и границы ответственности. Кто координирует информационные модели, кто создаёт данные по АР, КР и инженерным разделам, кто объединяет выдачу, кто проводит внутренние проверки и кто направляет её заказчику. Наименование должности BIM-менеджера само по себе не заменяет распределение обязанностей.
Организация совместной работы. Как устроена СОД, какие состояния проходят файлы, кто публикует актуальные модели, как назначаются и закрываются замечания, как команда исключает работу по устаревшим версиям. Если правила существуют только внутри одной проектной организации, нужно проверить их совместимость с процессом заказчика.
Технологическая схема. В каком ПО создаются и координируются модели, какие версии и форматы используются, как проверяются экспорт и повторное открытие файлов. Заказчик не обязан предписывать один программный продукт во всех случаях; важно обеспечить совместимость с согласованным способом использования данных.
Контроль качества. Какие проверки выполняются до отправки: геометрия, координаты, структура, свойства элементов, классификация, полнота выдачи, коллизии и журнал исправлений. Должны быть понятны частота проверок, исполнитель, документирование результата и процедура повторной подачи.
Календарь поставок. Какая команда готовит каждую информационную поставку и в какой последовательности. В терминологии ISO 19650 для этого используются планы отдельных групп — TIDP — и сводный MIDP. Они связывают информационные поставки разных команд с контрольными точками EIR и сроками проверки заказчиком. При работе по ISO 19650-2 TIDP и MIDP входят в предусмотренный стандартом процесс; при этом форма их представления может быть удобной для команды и не обязана ограничиваться отдельными бумажными документами.
Если BEP обещает передать реестр оборудования, но не указывает, кто отвечает за его атрибуты и как их проверяют, между EIR и фактическим процессом остаётся разрыв.
Роли и границы ответственности. Кто координирует информационные модели, кто создаёт данные по АР, КР и инженерным разделам, кто объединяет выдачу, кто проводит внутренние проверки и кто направляет её заказчику. Наименование должности BIM-менеджера само по себе не заменяет распределение обязанностей.
Организация совместной работы. Как устроена СОД, какие состояния проходят файлы, кто публикует актуальные модели, как назначаются и закрываются замечания, как команда исключает работу по устаревшим версиям. Если правила существуют только внутри одной проектной организации, нужно проверить их совместимость с процессом заказчика.
Технологическая схема. В каком ПО создаются и координируются модели, какие версии и форматы используются, как проверяются экспорт и повторное открытие файлов. Заказчик не обязан предписывать один программный продукт во всех случаях; важно обеспечить совместимость с согласованным способом использования данных.
Контроль качества. Какие проверки выполняются до отправки: геометрия, координаты, структура, свойства элементов, классификация, полнота выдачи, коллизии и журнал исправлений. Должны быть понятны частота проверок, исполнитель, документирование результата и процедура повторной подачи.
Календарь поставок. Какая команда готовит каждую информационную поставку и в какой последовательности. В терминологии ISO 19650 для этого используются планы отдельных групп — TIDP — и сводный MIDP. Они связывают информационные поставки разных команд с контрольными точками EIR и сроками проверки заказчиком. При работе по ISO 19650-2 TIDP и MIDP входят в предусмотренный стандартом процесс; при этом форма их представления может быть удобной для команды и не обязана ограничиваться отдельными бумажными документами.
Если BEP обещает передать реестр оборудования, но не указывает, кто отвечает за его атрибуты и как их проверяют, между EIR и фактическим процессом остаётся разрыв.
Как EIR и BEP работают вместе: последовательность для проекта
Шаг 1. Определить цели использования информации. Заказчик формулирует конкретные решения, для которых потребуются данные: например, проверить взаимное расположение коммуникаций или сформировать перечень оборудования для передачи в эксплуатацию.
Шаг 2. Подготовить EIR и связанные правила. Для каждой значимой поставки определяются результаты, информационная потребность, сроки, форматы и условия приёмки. Требования увязываются с предметом закупки и проектными этапами.
Шаг 3. Получить предварительный BEP в составе предложения. Потенциальный исполнитель показывает, как удовлетворит EIR. Заказчик оценивает не названия программ и число страниц, а покрытие требований, достаточность ресурсов и организацию контроля.
Шаг 4. Согласовать рабочий набор документов. После выбора исполнителя, до завершения оформления договора, уточняют BEP, матрицу ответственности, графики поставки данных и договорные приложения. Если несколько контрактов и команд, отдельно согласуют границы обмена между ними.
Шаг 5. Организовать выпуск и обмен. Участники создают модели и другие материалы, проводят внутренние проверки, координируют смежные решения и публикуют согласованные версии через предусмотренный процесс.
Шаг 6. Проверить и принять информацию. Заказчик сопоставляет поставку с EIR и согласованными критериями, фиксирует замечания или решение о приёмке. Наличие открываемого файла само по себе не означает выполнения информационных требований.
Сквозной процесс — управление изменениями. Он действует на всех перечисленных этапах, а не только после приёмки. Если меняются цель использования данных, состав параметров, формат или контрольная точка выдачи, стороны фиксируют новую редакцию требования, оценивают влияние на объём работ и сроки, согласуют необходимые изменения BEP и связанных планов. Действующие версии документов должны оставаться согласованными.
Шаг 2. Подготовить EIR и связанные правила. Для каждой значимой поставки определяются результаты, информационная потребность, сроки, форматы и условия приёмки. Требования увязываются с предметом закупки и проектными этапами.
Шаг 3. Получить предварительный BEP в составе предложения. Потенциальный исполнитель показывает, как удовлетворит EIR. Заказчик оценивает не названия программ и число страниц, а покрытие требований, достаточность ресурсов и организацию контроля.
Шаг 4. Согласовать рабочий набор документов. После выбора исполнителя, до завершения оформления договора, уточняют BEP, матрицу ответственности, графики поставки данных и договорные приложения. Если несколько контрактов и команд, отдельно согласуют границы обмена между ними.
Шаг 5. Организовать выпуск и обмен. Участники создают модели и другие материалы, проводят внутренние проверки, координируют смежные решения и публикуют согласованные версии через предусмотренный процесс.
Шаг 6. Проверить и принять информацию. Заказчик сопоставляет поставку с EIR и согласованными критериями, фиксирует замечания или решение о приёмке. Наличие открываемого файла само по себе не означает выполнения информационных требований.
Сквозной процесс — управление изменениями. Он действует на всех перечисленных этапах, а не только после приёмки. Если меняются цель использования данных, состав параметров, формат или контрольная точка выдачи, стороны фиксируют новую редакцию требования, оценивают влияние на объём работ и сроки, согласуют необходимые изменения BEP и связанных планов. Действующие версии документов должны оставаться согласованными.
Кто за что отвечает: заказчик, ведущий исполнитель и проектные команды
При распределении функций важно различать ответственность за постановку задачи и за производство данных.
Заказчик или уполномоченный им представитель определяет назначение и приоритеты информации, утверждает требования, организует их включение в закупочную и договорную документацию и устанавливает процедуру рассмотрения результата. Для этой работы могут привлекаться BIM-консультанты; делегирование подготовки текста не отменяет необходимости согласовать свои потребности.
Ведущий исполнитель организует ответ команды на EIR, готовит и уточняет BEP, распределяет задачи между участниками, увязывает поставки и обеспечивает предусмотренный внутренний контроль.
Проектные и профильные команды формируют сведения по своим частям работ, соблюдают согласованные правила обмена, проводят предусмотренные проверки и устраняют замечания в пределах закреплённой ответственности.
BIM-руководитель/координатор может обеспечивать методическую и техническую координацию со стороны заказчика либо исполнителя, но конкретные полномочия определяются договором и организационной схемой. Нельзя автоматически считать одного специалиста ответственным за все ошибки в моделях разных разделов.
Заказчик или уполномоченный им представитель определяет назначение и приоритеты информации, утверждает требования, организует их включение в закупочную и договорную документацию и устанавливает процедуру рассмотрения результата. Для этой работы могут привлекаться BIM-консультанты; делегирование подготовки текста не отменяет необходимости согласовать свои потребности.
Ведущий исполнитель организует ответ команды на EIR, готовит и уточняет BEP, распределяет задачи между участниками, увязывает поставки и обеспечивает предусмотренный внутренний контроль.
Проектные и профильные команды формируют сведения по своим частям работ, соблюдают согласованные правила обмена, проводят предусмотренные проверки и устраняют замечания в пределах закреплённой ответственности.
BIM-руководитель/координатор может обеспечивать методическую и техническую координацию со стороны заказчика либо исполнителя, но конкретные полномочия определяются договором и организационной схемой. Нельзя автоматически считать одного специалиста ответственным за все ошибки в моделях разных разделов.
Условный пример: модель есть, а реестр оборудования получить нельзя
Представим условный проект многоквартирного жилого здания. Технический заказчик хочет по завершении проектирования получить реестр инженерного оборудования для передачи эксплуатирующей организации. В исходном задании указано лишь: «передать BIM-модель в формате IFC».
Проектировщик создаёт и передаёт модель с геометрией оборудования, но отдельные элементы не имеют единой классификации, часть параметров отсутствует, а обозначения повторяются. IFC-файл технически открывается, однако автоматически собрать реестр с необходимым составом полей нельзя. Это условный сценарий, а не описание реального объекта.
Чтобы устранить неопределённость, в EIR нужно заранее согласовать категории оборудования, перечень обязательных полей (например, идентификатор, тип, система, расположение, требуемые характеристики), правила заполнения, этап передачи и формат реестра. Для каждого поля важно указать, где оно должно находиться и что считать корректным значением. Сведения, которые на данной стадии ещё не определены, должны иметь согласованный статус, а не заполняться произвольно.
В BEP исполнитель описывает, какой раздел формирует атрибуты, как они объединяются, кто выполняет проверку заполненности и уникальности идентификаторов, как экспортируются данные и как устраняются замечания. Перед итоговой выдачей команда делает пробную выгрузку, а заказчик проверяет результат по заранее определённой выборке или согласованной процедуре проверки.
Сравнение ниже показывает, как расплывчатое пожелание превратить в проверяемое условие. Примеры формулировок условные: в реальном проекте состав параметров, сроки и допустимые отклонения согласуют отдельно.
Проектировщик создаёт и передаёт модель с геометрией оборудования, но отдельные элементы не имеют единой классификации, часть параметров отсутствует, а обозначения повторяются. IFC-файл технически открывается, однако автоматически собрать реестр с необходимым составом полей нельзя. Это условный сценарий, а не описание реального объекта.
Чтобы устранить неопределённость, в EIR нужно заранее согласовать категории оборудования, перечень обязательных полей (например, идентификатор, тип, система, расположение, требуемые характеристики), правила заполнения, этап передачи и формат реестра. Для каждого поля важно указать, где оно должно находиться и что считать корректным значением. Сведения, которые на данной стадии ещё не определены, должны иметь согласованный статус, а не заполняться произвольно.
В BEP исполнитель описывает, какой раздел формирует атрибуты, как они объединяются, кто выполняет проверку заполненности и уникальности идентификаторов, как экспортируются данные и как устраняются замечания. Перед итоговой выдачей команда делает пробную выгрузку, а заказчик проверяет результат по заранее определённой выборке или согласованной процедуре проверки.
Сравнение ниже показывает, как расплывчатое пожелание превратить в проверяемое условие. Примеры формулировок условные: в реальном проекте состав параметров, сроки и допустимые отклонения согласуют отдельно.
Неопределённое требование | Проверяемое требование (условный пример) |
Передать BIM-модель оборудования | Передать модель и отдельный реестр оборудования согласованных категорий и состава. |
Заполнить характеристики | Установить перечень обязательных полей, правила идентификации и допустимые пустые значения. |
Проверить качество модели | Определить виды проверок, порядок регистрации замечаний и условия повторной выдачи. |
Концептуальная визуализация проверки состава данных и координации инженерных систем. Значки и панели условные; изображение не является снимком реального программного продукта.
Пример показывает, почему нельзя заменить EIR словами «модель должна быть качественной», а BEP — фразой «исполнитель обеспечивает качество». Требование должно описывать измеримый результат, а план — ответственный процесс его получения.
Типичные ошибки EIR и BEP и их последствия
Ошибка 1. Требование «сделать BIM» без перечня результатов. Команды по-разному понимают состав модели и отчётов. Проверка: у каждой цели есть конкретная информационная поставка и стадия её подготовки.
Ошибка 2. Детализация задана одним уровнем для всего здания. Часть данных создаётся без необходимости, а нужных для конкретной задачи характеристик может не быть. Проверка: требования распределены по категориям элементов, этапам и назначению.
Ошибка 3. Указан формат, но не проверена пригодность выгрузки. Файл существует, однако теряет нужные свойства или структуру. Проверка: определены версия/схема формата при необходимости, состав полей и порядок тестовой передачи.
Ошибка 4. BEP является типовым шаблоном без ответа на EIR. В нём перечислены привычные процедуры подрядчика, но не раскрыты конкретные поставки. Проверка: для каждого значимого требования можно найти ответственного, процесс и срок выполнения.
Ошибка 5. Не определены правила СОД и контроль версий. Стороны используют разные файлы, неясно, какая модель представлена на согласование. Проверка: описаны доступ, статусы, публикация, журнал изменений и правила фиксации замечаний.
Ошибка 6. Нет критериев приёмки и процедуры исправлений. Споры возникают уже после передачи комплекта. Проверка: согласованы состав проверок, допустимые исключения, сроки рассмотрения и способ повторной подачи.
Ошибка 7. Требования изменились, а документы — нет. Увеличивается объём работ, появляются конфликтующие версии задания. Проверка: действует единый порядок согласования изменений с оценкой последствий для информации, сроков и договорных обязательств.
Важно разделять три причины: неполнота EIR, несоответствие BEP требованиям и нарушение уже согласованного процесса. Для каждой причины нужны разные действия: уточнение требования, пересмотр плана либо исправление результата.
Ошибка 2. Детализация задана одним уровнем для всего здания. Часть данных создаётся без необходимости, а нужных для конкретной задачи характеристик может не быть. Проверка: требования распределены по категориям элементов, этапам и назначению.
Ошибка 3. Указан формат, но не проверена пригодность выгрузки. Файл существует, однако теряет нужные свойства или структуру. Проверка: определены версия/схема формата при необходимости, состав полей и порядок тестовой передачи.
Ошибка 4. BEP является типовым шаблоном без ответа на EIR. В нём перечислены привычные процедуры подрядчика, но не раскрыты конкретные поставки. Проверка: для каждого значимого требования можно найти ответственного, процесс и срок выполнения.
Ошибка 5. Не определены правила СОД и контроль версий. Стороны используют разные файлы, неясно, какая модель представлена на согласование. Проверка: описаны доступ, статусы, публикация, журнал изменений и правила фиксации замечаний.
Ошибка 6. Нет критериев приёмки и процедуры исправлений. Споры возникают уже после передачи комплекта. Проверка: согласованы состав проверок, допустимые исключения, сроки рассмотрения и способ повторной подачи.
Ошибка 7. Требования изменились, а документы — нет. Увеличивается объём работ, появляются конфликтующие версии задания. Проверка: действует единый порядок согласования изменений с оценкой последствий для информации, сроков и договорных обязательств.
Важно разделять три причины: неполнота EIR, несоответствие BEP требованиям и нарушение уже согласованного процесса. Для каждой причины нужны разные действия: уточнение требования, пересмотр плана либо исправление результата.
EIR, BEP и российские документы: как соотнести терминологию
Для российских проектов полезна опора на СП 404.1325800.2018 «Информационное моделирование в строительстве. Правила разработки планов проектов, реализуемых с применением технологии информационного моделирования». В нём используются понятия «требования заказчика к информационным моделям» и «план реализации проекта с использованием информационного моделирования» (ПИМ). Свод правил описывает планирование, распределение ролей, совместную работу, состав моделей и контроль качества.
Логика близка к связке EIR/BEP: сначала определяют потребность заказчика в информации, затем организуют работу по её удовлетворению. Но называть российские требования и EIR, а также ПИМ и BEP полностью тождественными документами некорректно. Их конкретный состав, место в процессе назначения исполнителей и правовые последствия различаются. Кроме того, в англоязычном контексте сокращение PIM может обозначать Project Information Model, то есть вовсе не российский план ПИМ.
СП 333.1325800.2020 «Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла» действует, но имеет ограниченную область применения. Согласно разделу 1 он распространяется на информационные модели объектов капитального строительства, предназначенные для размещения в государственной информационной системе обеспечения градостроительной деятельности РФ и/или аналогичных системах субъектов РФ. На модели, не предназначенные для такого размещения, свод правил не распространяется. Для иных проектов использование отдельных положений возможно по согласованию сторон, но их нельзя автоматически объявлять обязательными. Редакцию 2017 года этот СП заменил.
Договорный статус EIR и BEP следует определить отдельно. Само название документа ещё не устанавливает все условия сдачи и приёмки. Проверку соответствия информационной поставки требованиям не следует автоматически отождествлять с договорной приёмкой проектных работ: их связь необходимо определить отдельно. В договоре и приложениях важно перечислить действующие редакции требований и плана, установить приоритет документов при противоречиях, порядок утверждения изменений, критерии соответствия информации, сроки рассмотрения и повторной выдачи. Если корректировка EIR меняет состав работ или сроки, последствия следует согласовывать в договорном порядке. Применимость стандартов, обязательность конкретных документов и правовые последствия определяются применимыми требованиями и условиями договора, а не одним лишь использованием терминов EIR и BEP.
Логика близка к связке EIR/BEP: сначала определяют потребность заказчика в информации, затем организуют работу по её удовлетворению. Но называть российские требования и EIR, а также ПИМ и BEP полностью тождественными документами некорректно. Их конкретный состав, место в процессе назначения исполнителей и правовые последствия различаются. Кроме того, в англоязычном контексте сокращение PIM может обозначать Project Information Model, то есть вовсе не российский план ПИМ.
СП 333.1325800.2020 «Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла» действует, но имеет ограниченную область применения. Согласно разделу 1 он распространяется на информационные модели объектов капитального строительства, предназначенные для размещения в государственной информационной системе обеспечения градостроительной деятельности РФ и/или аналогичных системах субъектов РФ. На модели, не предназначенные для такого размещения, свод правил не распространяется. Для иных проектов использование отдельных положений возможно по согласованию сторон, но их нельзя автоматически объявлять обязательными. Редакцию 2017 года этот СП заменил.
Договорный статус EIR и BEP следует определить отдельно. Само название документа ещё не устанавливает все условия сдачи и приёмки. Проверку соответствия информационной поставки требованиям не следует автоматически отождествлять с договорной приёмкой проектных работ: их связь необходимо определить отдельно. В договоре и приложениях важно перечислить действующие редакции требований и плана, установить приоритет документов при противоречиях, порядок утверждения изменений, критерии соответствия информации, сроки рассмотрения и повторной выдачи. Если корректировка EIR меняет состав работ или сроки, последствия следует согласовывать в договорном порядке. Применимость стандартов, обязательность конкретных документов и правовые последствия определяются применимыми требованиями и условиями договора, а не одним лишь использованием терминов EIR и BEP.
Чек-лист для заказчика перед согласованием документов
Проверить связь EIR и BEP можно по шести вопросам:
- Для каждого результата указано, какую задачу заказчика он обеспечивает?
- Понятно, что передавать: модели, наборы свойств, ведомости, отчёты и сопутствующие документы?
- Определены этап, формат, состав информации и критерии приёмки?
- Есть ли в BEP ответственные роли, правила взаимодействия и процедуры контроля, соответствующие этим требованиям?
- Связаны ли сроки обмена, график поставок и время проверки заказчиком?
- Описано ли, как фиксировать замечания, повторную выдачу и изменения требований?
Частые вопросы об EIR и BEP
Кто должен составлять EIR — заказчик или проектировщик?
EIR формирует назначающая сторона (appointing party). В отношениях с генеральным проектировщиком ею обычно выступает заказчик или уполномоченный представитель. Но когда ведущий исполнитель привлекает субподрядчиков, он также может устанавливать EIR для получаемой от них информации. BIM-консультант вправе помогать с подготовкой текста требований, при этом цели информационных поставок должны быть согласованы с соответствующей назначающей стороной.
Можно ли использовать один EIR для всех подрядчиков?
Единый набор базовых принципов удобен, но требования к поставкам должны учитывать предмет конкретного назначения. Архитектору, инженерам и строительному подрядчику могут понадобиться разные результаты и точки обмена. Поэтому общий набор требований обычно адаптируют к каждому объёму работ.
Может ли заказчик подготовить шаблон BEP?
Да, заказчик может задать структуру ответа или предложить шаблон. Однако будущий исполнитель должен наполнить его реальной схемой работы своей команды и показать соответствие EIR. Формальное заполнение без распределения ролей и процессов не решает задачу.
Достаточно ли указать LOD и формат IFC?
Нет. Обозначение уровня проработки и формат передачи не отвечают на вопросы о назначении данных, обязательных свойствах, составе выдачи и порядке приёмки. Их определяют отдельно и увязывают с информационной потребностью.
Нужно ли разрабатывать BEP только один раз?
Нет. В процессе по ISO 19650 потенциальный ведущий исполнитель сначала готовит предварительный BEP в ответ на запрос требований, затем документ уточняют и подтверждают при оформлении назначения и договора. При согласованных изменениях его следует поддерживать в актуальном состоянии.
Как соотносятся BEP и ПИМ по СП 404?
Оба связаны с планированием информационного моделирования, но сформированы в разных нормативных и методических системах. Для российского проекта нужно проверять содержательные требования применимых документов и условия договора, а не просто менять название «BEP» на «ПИМ».
EIR формирует назначающая сторона (appointing party). В отношениях с генеральным проектировщиком ею обычно выступает заказчик или уполномоченный представитель. Но когда ведущий исполнитель привлекает субподрядчиков, он также может устанавливать EIR для получаемой от них информации. BIM-консультант вправе помогать с подготовкой текста требований, при этом цели информационных поставок должны быть согласованы с соответствующей назначающей стороной.
Можно ли использовать один EIR для всех подрядчиков?
Единый набор базовых принципов удобен, но требования к поставкам должны учитывать предмет конкретного назначения. Архитектору, инженерам и строительному подрядчику могут понадобиться разные результаты и точки обмена. Поэтому общий набор требований обычно адаптируют к каждому объёму работ.
Может ли заказчик подготовить шаблон BEP?
Да, заказчик может задать структуру ответа или предложить шаблон. Однако будущий исполнитель должен наполнить его реальной схемой работы своей команды и показать соответствие EIR. Формальное заполнение без распределения ролей и процессов не решает задачу.
Достаточно ли указать LOD и формат IFC?
Нет. Обозначение уровня проработки и формат передачи не отвечают на вопросы о назначении данных, обязательных свойствах, составе выдачи и порядке приёмки. Их определяют отдельно и увязывают с информационной потребностью.
Нужно ли разрабатывать BEP только один раз?
Нет. В процессе по ISO 19650 потенциальный ведущий исполнитель сначала готовит предварительный BEP в ответ на запрос требований, затем документ уточняют и подтверждают при оформлении назначения и договора. При согласованных изменениях его следует поддерживать в актуальном состоянии.
Как соотносятся BEP и ПИМ по СП 404?
Оба связаны с планированием информационного моделирования, но сформированы в разных нормативных и методических системах. Для российского проекта нужно проверять содержательные требования применимых документов и условия договора, а не просто менять название «BEP» на «ПИМ».
Вывод: проверять нужно не два документа, а связь между ними
Полезный EIR начинается с задачи заказчика и заканчивается проверяемой информационной поставкой. Полезный BEP показывает, кто, каким способом и с каким контролем эту поставку подготовит. Если в требованиях отсутствуют нужные данные, их не создаст даже подробно составленный план; если в плане нет реалистичного процесса, требование останется формальностью.
При согласовании BIM-проекта важно видеть непрерывную цепочку: задача → требование к информации → ответственный процесс → передача → проверка по критериям. Она даёт сторонам общий предмет обсуждения и помогает принимать цифровой результат без подмены ожидаемых данных самим фактом наличия модели.
При согласовании BIM-проекта важно видеть непрерывную цепочку: задача → требование к информации → ответственный процесс → передача → проверка по критериям. Она даёт сторонам общий предмет обсуждения и помогает принимать цифровой результат без подмены ожидаемых данных самим фактом наличия модели.
Как согласовать требования к BIM-модели до начала проектирования
Перед заказом моделирования полезно определить, для каких решений будет использоваться модель, какие данные необходимо получить и как проверять их при передаче. TrueBIM в рамках консалтинга для застройщика помогает выстраивать BIM-процессы и правила работы с информационными моделями. Можно передать исходные задачи, проектную документацию и действующие требования, чтобы обсудить состав необходимых информационных поставок, организацию взаимодействия и критерии проверки результата.
Мы открыты к сотрудничеству
Оставьте заявку и получите детализацию стоимости проектирования в Revit