Техническое задание на BIM-моделирование: что обязательно указать заказчику?
Если в ТЗ указано только «создать BIM-модель в Revit», на приёмке может выясниться, что нужную ведомость оборудования сформировать нельзя: у части элементов отсутствуют марки, обозначения систем или параметры отбора. Подрядчик при этом может считать работу выполненной — необходимость передавать эти сведения не была зафиксирована в задании.
Разногласия возникают, когда стороны согласовали инструмент моделирования, но по-разному поняли назначение результата. Техническое задание на BIM-модель фиксирует требования к информационной модели: какие задачи она решает, какие объекты и сведения включает, в каких файлах передаётся и по каким признакам принимается. Иначе даже визуально качественная модель может оказаться непригодной для конкретной работы заказчика.
Требования можно оформить отдельным документом или разделом задания на проектирование. При составлении ТЗ полезно сразу отделить договорные условия от требований законодательства: их применимость зависит от конкретного проекта.
Разногласия возникают, когда стороны согласовали инструмент моделирования, но по-разному поняли назначение результата. Техническое задание на BIM-модель фиксирует требования к информационной модели: какие задачи она решает, какие объекты и сведения включает, в каких файлах передаётся и по каким признакам принимается. Иначе даже визуально качественная модель может оказаться непригодной для конкретной работы заказчика.
Требования можно оформить отдельным документом или разделом задания на проектирование. При составлении ТЗ полезно сразу отделить договорные условия от требований законодательства: их применимость зависит от конкретного проекта.
Сначала определите, зачем нужна модель
Фраза «нужна BIM-модель здания» не раскрывает объём работ. Для проверки коллизий нужны согласованные границы моделирования, корректное пространственное положение элементов и правила анализа пересечений. Для подсчёта объёмов дополнительно требуется определить, какие элементы учитываются, какие свойства используются и как формируются ведомости. Для эксплуатации потребуются сведения об оборудовании, идентификация и связи с эксплуатационной документацией — в объёме, установленном заказчиком.
Поэтому цели лучше записывать через задачу, необходимые данные и ожидаемый результат. Например:
В одном проекте может быть несколько задач, но для каждой потребуется собственный набор требований. Если заказчику нужен только анализ пространственных конфликтов, запрашивать подробные паспортные характеристики каждого элемента необязательно. Если по модели будут формировать закупочную ведомость, перечень атрибутов уже нельзя оставлять на усмотрение исполнителя.
Поэтому цели лучше записывать через задачу, необходимые данные и ожидаемый результат. Например:
Задача заказчика | Что предусмотреть в модели | Как подтвердить результат |
Координация АР, КР и инженерных систем | Согласованные разделы, геометрия основных элементов, единые координаты | Проверка объединённой модели по утверждённой матрице коллизий |
Получение объёмов | Перечень учитываемых элементов, правила измерения, параметры для группировки | Контрольная ведомость и сверка выбранных позиций с моделью |
Передача данных на эксплуатацию | Согласованный перечень обслуживаемого оборудования и обязательных атрибутов | Выборочная проверка карточек оборудования и экспортируемых свойств |
В одном проекте может быть несколько задач, но для каждой потребуется собственный набор требований. Если заказчику нужен только анализ пространственных конфликтов, запрашивать подробные паспортные характеристики каждого элемента необязательно. Если по модели будут формировать закупочную ведомость, перечень атрибутов уже нельзя оставлять на усмотрение исполнителя.
Зафиксируйте объект, этап и границы работ
В начале ТЗ указывают объект и его части: корпус, секцию, подземную часть, наружные сети или участок территории, если они входят в задание. Далее — этап жизненного цикла, стадия проектирования или состояние исходной документации, для которого создаётся модель.
Отдельно определяют характер услуги. Моделирование по готовым DWG/PDF означает воспроизведение согласованных решений в информационной модели в установленном составе. Если в чертежах есть противоречия, подрядчику нужен порядок запроса разъяснений; разработка недостающих решений не должна автоматически считаться частью такого моделирования. При BIM-проектировании исполнитель может разрабатывать и согласовывать проектные решения, если это предусмотрено договором и составом работ. Разница влияет на ответственность, сроки и стоимость, поэтому её стоит прямо записать в ТЗ.
Полезно определить, какие версии документов являются исходными и что происходит при их обновлении. Например: «Модель создаётся по перечню исходных файлов в приложении № 1. После передачи новой редакции чертежей изменение модели выполняется в порядке, установленном договором». Это пример договорной формулировки, а не цитата из нормативного документа. Подробности подготовки исходных DWG и PDF описаны в материале «BIM-модель по чертежам DWG, PDF и РД».
Отдельно определяют характер услуги. Моделирование по готовым DWG/PDF означает воспроизведение согласованных решений в информационной модели в установленном составе. Если в чертежах есть противоречия, подрядчику нужен порядок запроса разъяснений; разработка недостающих решений не должна автоматически считаться частью такого моделирования. При BIM-проектировании исполнитель может разрабатывать и согласовывать проектные решения, если это предусмотрено договором и составом работ. Разница влияет на ответственность, сроки и стоимость, поэтому её стоит прямо записать в ТЗ.
Полезно определить, какие версии документов являются исходными и что происходит при их обновлении. Например: «Модель создаётся по перечню исходных файлов в приложении № 1. После передачи новой редакции чертежей изменение модели выполняется в порядке, установленном договором». Это пример договорной формулировки, а не цитата из нормативного документа. Подробности подготовки исходных DWG и PDF описаны в материале «BIM-модель по чертежам DWG, PDF и РД».
EIR и BEP: основные отличия
Подготовьте реестр с названием, форматом, датой или ревизией и статусом каждого файла. В зависимости от задачи он может включать архитектурные и конструктивные чертежи, схемы инженерных систем, спецификации, результаты изысканий, имеющиеся модели смежников и требования к координатам.
Для объединения моделей отдельно согласуют базовую точку, ориентацию осей, отметку нуля, систему координат и единицы измерения. Нельзя предполагать, что одинаковые названия уровней означают совпадающее пространственное положение. Укажите ответственного за подтверждение общих координат и порядок действий, если данные разных разделов противоречат друг другу.
Если часть исходных сведений отсутствует, лучше занести её в перечень открытых вопросов до заключения договора. Там же можно обозначить, какие допущения допускаются, кто их согласует и как они будут отражены при передаче модели.
Для объединения моделей отдельно согласуют базовую точку, ориентацию осей, отметку нуля, систему координат и единицы измерения. Нельзя предполагать, что одинаковые названия уровней означают совпадающее пространственное положение. Укажите ответственного за подтверждение общих координат и порядок действий, если данные разных разделов противоречат друг другу.
Если часть исходных сведений отсутствует, лучше занести её в перечень открытых вопросов до заключения договора. Там же можно обозначить, какие допущения допускаются, кто их согласует и как они будут отражены при передаче модели.
Опишите состав разделов и элементов, включая исключения
Перечень дисциплин — отправная точка, но сам по себе он не определяет полноту модели. Запись «АР, КР, ОВ, ВК, ЭОМ» оставляет открытым вопрос о конкретных системах и элементах. Например, в разделе ОВ можно моделировать только магистральные воздуховоды и оборудование, а можно включить ответвления, арматуру, теплоизоляцию и зоны обслуживания. Для разных задач нужен разный состав.
Удобнее использовать матрицу по разделам и группам элементов: что моделируется, в каких границах, с какой геометрией и какими свойствами. Для инженерной модели дополнительно фиксируют, какие системы входят в работу, где они начинаются и заканчиваются, моделируются ли существующие сети, крепления, отверстия, закладные детали и технологические зазоры.
Удобнее использовать матрицу по разделам и группам элементов: что моделируется, в каких границах, с какой геометрией и какими свойствами. Для инженерной модели дополнительно фиксируют, какие системы входят в работу, где они начинаются и заканчиваются, моделируются ли существующие сети, крепления, отверстия, закладные детали и технологические зазоры.
Условная BIM-модель здания: архитектурные элементы, конструкции, инженерные системы и связанные данные
Не менее полезен список исключений. Если для поставленных задач не требуются отдельные соединительные элементы, отделочные слои, внутреннее наполнение изделий или временные строительные элементы, это нужно зафиксировать. При этом нельзя исключать элементы, отсутствие которых помешает согласованным проверкам или расчётам. Иначе заказчик может ожидать более подробную модель, чем предусмотрел исполнитель.
Пример для условного объекта: в модель ОВ включают установки, воздуховоды, фасонные части, основные клапаны и решётки. Крепёжные изделия не моделируют. Зоны доступа к обслуживаемому оборудованию передают согласованным способом для координации. Этот состав подходит только как образец записи: для реального проекта его нужно уточнить по назначению модели.
Пример для условного объекта: в модель ОВ включают установки, воздуховоды, фасонные части, основные клапаны и решётки. Крепёжные изделия не моделируют. Зоны доступа к обслуживаемому оборудованию передают согласованным способом для координации. Этот состав подходит только как образец записи: для реального проекта его нужно уточнить по назначению модели.
Уровень проработки: не ограничивайтесь записью «LOD 300»
Запись «LOD 300» сама по себе не раскрывает, какие сведения должны быть доступны на конкретном этапе. Термин LOD используется в разных методиках, и одно обозначение нельзя считать универсальным перечнем требований для всех элементов. В ТЗ нужно указать принятую систему уровней проработки и конкретизировать геометрию, атрибуты и документы по категориям элементов и этапам выдачи.
В ISO 7817-1:2024 применяется подход уровня потребности в информации: требования определяются назначением выдачи и могут охватывать геометрию, буквенно-цифровые сведения и документацию. Для практического ТЗ это означает, что нужно отдельно описывать:
геометрию: форму, положение, габариты и те детали, которые необходимы для поставленной задачи;
атрибуты: названия параметров, значения или правила их заполнения, типы данных и единицы измерения;
связанные документы: паспорта, спецификации или иные материалы, если они действительно нужны при передаче.
Например, для проверки пересечения воздуховода с балкой необходимы корректные габариты и положение элементов. Для отбора воздуховодов по системе дополнительно требуется признак принадлежности к системе. При подготовке сведений для эксплуатации потребность в информации может быть шире, но она определяется конкретным процессом эксплуатации, а не универсальным списком на все объекты.
В ISO 7817-1:2024 применяется подход уровня потребности в информации: требования определяются назначением выдачи и могут охватывать геометрию, буквенно-цифровые сведения и документацию. Для практического ТЗ это означает, что нужно отдельно описывать:
геометрию: форму, положение, габариты и те детали, которые необходимы для поставленной задачи;
атрибуты: названия параметров, значения или правила их заполнения, типы данных и единицы измерения;
связанные документы: паспорта, спецификации или иные материалы, если они действительно нужны при передаче.
Например, для проверки пересечения воздуховода с балкой необходимы корректные габариты и положение элементов. Для отбора воздуховодов по системе дополнительно требуется признак принадлежности к системе. При подготовке сведений для эксплуатации потребность в информации может быть шире, но она определяется конкретным процессом эксплуатации, а не универсальным списком на все объекты.
Как задавать обязательные параметры
Лучше оформить спецификацию атрибутов отдельным приложением. Для каждой группы элементов укажите название параметра, его назначение, тип значения, единицу измерения, обязательность, источник и правила проверки. При обмене между программами понадобятся согласованные имена и соответствие полей в целевом формате.
Названия полей в таблице иллюстративны. Для проекта необходимо установить точные имена параметров, словари значений и правила их передачи. Особое внимание уделяют признакам, по которым заказчик будет фильтровать элементы, связывать их с документацией или строить отчёты.
Группа элементов | Параметр — условный пример | Правило заполнения и проверки |
Воздуховоды ОВ | Код системы | Значение выбирается из утверждённого справочника; обязательность и охват проверки определяются матрицей атрибутов |
Оборудование ОВ | Марка или позиционное обозначение | Соответствует согласованной спецификации соответствующей редакции |
Трубопроводы ВК | Условное обозначение системы | Используется единый справочник обозначений; проверяется на выборке |
Обслуживаемое оборудование | Идентификатор элемента | Идентификатор уникален в согласованной области модели; проверяются дубли и незаполненные значения |
Названия полей в таблице иллюстративны. Для проекта необходимо установить точные имена параметров, словари значений и правила их передачи. Особое внимание уделяют признакам, по которым заказчик будет фильтровать элементы, связывать их с документацией или строить отчёты.
Форматы файлов: запишите, что и в каком виде передаётся
Требование «передать IFC» недостаточно: необходимо понимать, какое программное обеспечение будет читать данные, какая версия схемы используется и какие свойства должны сохраняться при экспорте. buildingSMART описывает IFC как открытый стандарт обмена данными, содержащий структуру объектов, свойств и связей. При этом фактическая поддержка версий и наборов данных зависит от программ и настроек обмена.
Если заказчик планирует редактировать модель, в ТЗ отдельно предусматривают исходный рабочий формат и согласованную версию ПО. Если модель передают для независимой проверки или включения в сводную модель, могут потребоваться IFC-файлы. В проектах с несколькими дисциплинами полезно указать состав отдельных файлов по разделам, правила сборки общей модели и перечень сопроводительных материалов.
В приложении к ТЗ удобно закрепить правила именования, структуру каталогов, идентификатор редакции, дату передачи, статус файла, систему координат и единицы. Для IFC важно согласовать не только версию, но и правила экспорта, а затем проверить тестовый набор элементов в целевой программе. Наличие файла .ifc само по себе не доказывает, что все необходимые заказчику атрибуты переданы без потерь.
Отдельно следует проверить, обязательно ли формировать и вести информационную модель ОКС по условиям конкретного проекта. Постановление Правительства РФ № 614 от 17.05.2024 устанавливает правила формирования и ведения информационной модели, состав включаемых сведений, документов и материалов, а также требования к форматам электронных документов. Применимость этих положений необходимо оценивать отдельно; они не превращают каждый коммерческий заказ BIM-моделирования в процедуру передачи модели в государственную информационную систему.
Если заказчик планирует редактировать модель, в ТЗ отдельно предусматривают исходный рабочий формат и согласованную версию ПО. Если модель передают для независимой проверки или включения в сводную модель, могут потребоваться IFC-файлы. В проектах с несколькими дисциплинами полезно указать состав отдельных файлов по разделам, правила сборки общей модели и перечень сопроводительных материалов.
В приложении к ТЗ удобно закрепить правила именования, структуру каталогов, идентификатор редакции, дату передачи, статус файла, систему координат и единицы. Для IFC важно согласовать не только версию, но и правила экспорта, а затем проверить тестовый набор элементов в целевой программе. Наличие файла .ifc само по себе не доказывает, что все необходимые заказчику атрибуты переданы без потерь.
Отдельно следует проверить, обязательно ли формировать и вести информационную модель ОКС по условиям конкретного проекта. Постановление Правительства РФ № 614 от 17.05.2024 устанавливает правила формирования и ведения информационной модели, состав включаемых сведений, документов и материалов, а также требования к форматам электронных документов. Применимость этих положений необходимо оценивать отдельно; они не превращают каждый коммерческий заказ BIM-моделирования в процедуру передачи модели в государственную информационную систему.
Какие проверки модели нужно предусмотреть
Фраза «модель должна быть качественной» не задаёт способ контроля. По каждому виду проверки важно договориться о составе объектов, методе, допустимых исключениях и результате в виде отчёта или протокола.
Комплектность. Проверяют наличие согласованных разделов, систем и групп элементов, а также соответствие границам моделирования. При необходимости используют сопоставление с реестром исходных чертежей или перечнем помещений и оборудования.
Геометрия и координаты. Контролируют положение модели, отметки, габариты и соответствие документам, по которым выполнялось моделирование. Для проверки на основе выборки заранее устанавливают её состав: какие этажи, участки и категории элементов проверяются.
Комплектность. Проверяют наличие согласованных разделов, систем и групп элементов, а также соответствие границам моделирования. При необходимости используют сопоставление с реестром исходных чертежей или перечнем помещений и оборудования.
Геометрия и координаты. Контролируют положение модели, отметки, габариты и соответствие документам, по которым выполнялось моделирование. Для проверки на основе выборки заранее устанавливают её состав: какие этажи, участки и категории элементов проверяются.
Условные примеры: как связать задачи заказчика с данными модели, правилами проверки и результатом приёмки
Информационное наполнение. Проверяют обязательные атрибуты, допустимые значения, классификацию, идентификаторы и наличие необходимых связей. Если проверка автоматизируется, список полей и правил должен быть доступен в формализованном виде. Например, стандарт buildingSMART IDS позволяет машиночитаемо описывать требования к типам объектов, классификации, свойствам и значениям в IFC-модели. IDS не заменяет проверку геометрии, коллизий и инженерных решений: для них нужны другие методы контроля.
Коллизии. Зафиксируйте пары разделов для проверки, категории объектов, допустимые пересечения, зоны обслуживания, способ формирования замечаний и критерии их закрытия. Проверка всех элементов со всеми элементами создаёт много нерелевантных сообщений. Требование «ноль коллизий» без согласованных исключений и метода оценки обычно приводит к спору о том, какие пересечения считать ошибками.
Важно разделять технические проверки модели и инженерную оценку проектных решений. Отсутствие геометрического пересечения воздуховода с балкой ещё не подтверждает соответствие системы всем требованиям проектирования. Расчёты, подбор оборудования и проверка технических решений входят в объём работ тогда, когда это предусмотрено заданием на проектирование и договором.
Коллизии. Зафиксируйте пары разделов для проверки, категории объектов, допустимые пересечения, зоны обслуживания, способ формирования замечаний и критерии их закрытия. Проверка всех элементов со всеми элементами создаёт много нерелевантных сообщений. Требование «ноль коллизий» без согласованных исключений и метода оценки обычно приводит к спору о том, какие пересечения считать ошибками.
Важно разделять технические проверки модели и инженерную оценку проектных решений. Отсутствие геометрического пересечения воздуховода с балкой ещё не подтверждает соответствие системы всем требованиям проектирования. Расчёты, подбор оборудования и проверка технических решений входят в объём работ тогда, когда это предусмотрено заданием на проектирование и договором.
Как организовать обмен, замечания и приёмку
Даже подробное ТЗ не заменяет порядок взаимодействия. Следует согласовать, кто передаёт исходные данные, кто утверждает требования, где хранятся актуальные файлы, в какие контрольные точки проводится выдача и как фиксируются изменения. Это может быть общая среда данных или иной согласованный канал с ведением версий.
Промежуточная выдача полезна для ранней проверки координат, структуры файлов и заполнения нескольких типовых элементов. Если выявить несовместимый экспорт только при итоговой сдаче, исправления могут затронуть уже готовые модели всех разделов.
В процедуре приёмки стоит определить комплект поставки: модели по разделам, при необходимости сводную модель, реестр файлов, отчёты о проверках, список известных ограничений и замечаний. Для замечаний нужны идентификатор, описание, привязка к элементу или месту, ответственный, статус и подтверждение устранения. Порядок классификации замечаний и перечень препятствующих приёмке дефектов согласуют до начала работ. О действиях после возврата модели с замечаниями — в статье «Заказчик не принимает BIM-модель: что делать».
Промежуточная выдача полезна для ранней проверки координат, структуры файлов и заполнения нескольких типовых элементов. Если выявить несовместимый экспорт только при итоговой сдаче, исправления могут затронуть уже готовые модели всех разделов.
В процедуре приёмки стоит определить комплект поставки: модели по разделам, при необходимости сводную модель, реестр файлов, отчёты о проверках, список известных ограничений и замечаний. Для замечаний нужны идентификатор, описание, привязка к элементу или месту, ответственный, статус и подтверждение устранения. Порядок классификации замечаний и перечень препятствующих приёмке дефектов согласуют до начала работ. О действиях после возврата модели с замечаниями — в статье «Заказчик не принимает BIM-модель: что делать».
Примеры проверяемых критериев приёмки
В приложении к ТЗ критерий лучше записывать вместе с областью и способом проверки. Ниже приведены условные примеры формулировок — они не являются универсальными нормативными допусками:
Комплектность: в итоговом комплекте присутствуют все файлы и разделы из утверждённого реестра выдачи; отсутствие файла фиксируется как несоответствие.
Атрибуты: у элементов категорий, перечисленных в матрице обязательных параметров, соответствующие поля заполнены допустимыми значениями; исключения задокументированы и согласованы.
Координация: по согласованной матрице проверок не осталось открытых критических коллизий; признанные допустимыми пересечения имеют утверждённый статус и пояснение.
Обмен данными: переданный IFC открывается в указанной в ТЗ программе-получателе; выборочная проверка подтверждает наличие оговорённых объектов и полей после экспорта.
В реальном задании к таким критериям добавляют согласованную процедуру проверки, состав выборки и ответственных за подтверждение результатов. Тогда стороны могут одинаково оценить выполнение каждого пункта.
Пример договорной формулировки: «Итоговая модель передаётся в форматах, перечисленных в приложении № 3, с реестром версий и отчётом о проверках. Приёмка проводится по требованиям приложений № 2 и № 4. Замечания фиксируются в согласованном журнале; повторная выдача содержит перечень исправлений и нерешённых вопросов». Номера приложений здесь условные — они показывают принцип связывания ТЗ, спецификации данных и критериев приёмки.
Комплектность: в итоговом комплекте присутствуют все файлы и разделы из утверждённого реестра выдачи; отсутствие файла фиксируется как несоответствие.
Атрибуты: у элементов категорий, перечисленных в матрице обязательных параметров, соответствующие поля заполнены допустимыми значениями; исключения задокументированы и согласованы.
Координация: по согласованной матрице проверок не осталось открытых критических коллизий; признанные допустимыми пересечения имеют утверждённый статус и пояснение.
Обмен данными: переданный IFC открывается в указанной в ТЗ программе-получателе; выборочная проверка подтверждает наличие оговорённых объектов и полей после экспорта.
В реальном задании к таким критериям добавляют согласованную процедуру проверки, состав выборки и ответственных за подтверждение результатов. Тогда стороны могут одинаково оценить выполнение каждого пункта.
Пример договорной формулировки: «Итоговая модель передаётся в форматах, перечисленных в приложении № 3, с реестром версий и отчётом о проверках. Приёмка проводится по требованиям приложений № 2 и № 4. Замечания фиксируются в согласованном журнале; повторная выдача содержит перечень исправлений и нерешённых вопросов». Номера приложений здесь условные — они показывают принцип связывания ТЗ, спецификации данных и критериев приёмки.
Чем ТЗ заказчика отличается от ПИМ/BEP
В ТЗ заказчик определяет, какие сведения и результаты ему нужны. План реализации проекта с использованием информационного моделирования (ПИМ, в международной практике близок по функции к BEP) описывает, как участники организуют работу для выполнения этих требований: роли, процессы, программную среду, координацию, контроль качества и выдачи.
Такое разграничение отражено в приложении Ж к СП 333.1325800.2020: там приведён пример требований заказчика и предусмотрена разработка ПИМ исполнителем на основе ТЗ. Структуру ПИМ раскрывает СП 404.1325800.2018. При этом СП 333 имеет специальную область применения, поэтому его приложение следует использовать как структурный пример, а не как универсальное обязательное требование для любого заказа.
Подрядчик может предложить способ реализации требований и уточнить технологические детали, но существенные изменения состава результата, форматов или критериев приёмки должны быть согласованы сторонами. Иначе исполнительская методика начинает незаметно подменять первоначальные потребности заказчика.
Такое разграничение отражено в приложении Ж к СП 333.1325800.2020: там приведён пример требований заказчика и предусмотрена разработка ПИМ исполнителем на основе ТЗ. Структуру ПИМ раскрывает СП 404.1325800.2018. При этом СП 333 имеет специальную область применения, поэтому его приложение следует использовать как структурный пример, а не как универсальное обязательное требование для любого заказа.
Подрядчик может предложить способ реализации требований и уточнить технологические детали, но существенные изменения состава результата, форматов или критериев приёмки должны быть согласованы сторонами. Иначе исполнительская методика начинает незаметно подменять первоначальные потребности заказчика.
Ошибки в ТЗ, из-за которых возникают разногласия
Самые рискованные формулировки выглядят привычно и коротко. Проблема в том, что проверить их исполнение невозможно без дополнительных договорённостей.
Хороший способ проверить полноту формулировки — представить, как независимый специалист будет принимать результат. Если для ответа «соответствует / не соответствует» ему потребуется каждый раз звонить исполнителю и уточнять ожидания, требование ещё не готово.
Неопределённая формулировка | Как уточнить требование |
«Разработать BIM-модель в Revit» | Указать назначение модели, перечень разделов, элементы, параметры, рабочий формат и версию ПО, если редактируемый файл обязателен |
«Сделать LOD 300» | Приложить матрицу элементов с необходимой геометрией, атрибутами и документацией для конкретной выдачи |
«Передать IFC» | Уточнить версию схемы, разделение файлов, координаты, правила экспорта и проверяемые свойства |
«Проверить все коллизии» | Утвердить матрицу пар разделов, исключения, критерии значимости и форму отчёта |
«Подготовить модель для расчёта объёмов» | Перечислить категории элементов, правила количественного учёта и контрольную ведомость |
«Исправить все замечания заказчика» | Определить критерии соответствия ТЗ, порядок регистрации замечаний, согласования изменений и повторной выдачи |
Хороший способ проверить полноту формулировки — представить, как независимый специалист будет принимать результат. Если для ответа «соответствует / не соответствует» ему потребуется каждый раз звонить исполнителю и уточнять ожидания, требование ещё не готово.
Что из требований обязательно по закону, а что определяется договором
Нужно различать требования законодательства и условия договора. В первом случае речь идёт о формировании и ведении информационной модели ОКС в предусмотренных законом случаях, установленных, в частности, постановлением Правительства РФ № 331 от 05.03.2021; правила формирования и ведения модели, состав включаемых сведений и требования к форматам электронных документов определяет постановление № 614. При этом информационная модель в смысле этих актов включает взаимосвязанные сведения, документы и материалы об объекте — её нельзя сводить к одной трёхмерной цифровой модели. Применимость определяется условиями конкретного проекта.
Второй уровень — дополнительные договорные требования заказчика: расширенный набор атрибутов, собственные классификаторы, конкретные версии рабочих файлов, правила координации, состав отчётов и процедуры приёмки. Их можно закрепить в ТЗ, если они нужны для задачи и согласованы сторонами. Нельзя утверждать, что каждый частный заказ обязан содержать одинаковый перечень параметров или один фиксированный уровень проработки.
СП 333.1325800.2020 действует, однако его заявленная область применения связана с информационными моделями, предназначенными для размещения в государственных информационных системах обеспечения градостроительной деятельности. Приложение Ж полезно как пример структуры требований заказчика, но из него нельзя выводить обязательность одинакового ТЗ для всех коммерческих объектов.
Второй уровень — дополнительные договорные требования заказчика: расширенный набор атрибутов, собственные классификаторы, конкретные версии рабочих файлов, правила координации, состав отчётов и процедуры приёмки. Их можно закрепить в ТЗ, если они нужны для задачи и согласованы сторонами. Нельзя утверждать, что каждый частный заказ обязан содержать одинаковый перечень параметров или один фиксированный уровень проработки.
СП 333.1325800.2020 действует, однако его заявленная область применения связана с информационными моделями, предназначенными для размещения в государственных информационных системах обеспечения градостроительной деятельности. Приложение Ж полезно как пример структуры требований заказчика, но из него нельзя выводить обязательность одинакового ТЗ для всех коммерческих объектов.
Чек-лист: готово ли ТЗ к отправке подрядчику
Перед запросом коммерческого предложения проверьте 15 пунктов. Если по какому-то пункту решения пока нет, лучше обозначить вопрос как открытый, а не оставлять исполнителю неявное предположение.
☐ 1. Сформулированы задачи модели и ожидаемые результаты её использования.
☐ 2. Определены объект, корпуса, секции, этап и границы моделирования.
☐ 3. Разделены создание модели по готовой документации и разработка проектных решений.
☐ 4. Подготовлен реестр исходных данных с версиями и статусами файлов.
☐ 5. Установлены координаты, оси, отметки и единицы измерения.
☐ 6. Согласованы разделы, системы и категории моделируемых элементов.
☐ 7. Перечислены исключения и элементы, которые моделировать не требуется.
☐ 8. Описана геометрия, необходимая для каждой задачи и этапа выдачи.
☐ 9. Приложена спецификация обязательных атрибутов и правил их заполнения.
☐ 10. Согласованы классификация, идентификаторы и справочники значений.
☐ 11. Установлены форматы, версии файлов, правила экспорта и именования.
☐ 12. Определены контрольные точки и способ обмена актуальными моделями.
☐ 13. Описаны проверки геометрии, данных и коллизий, включая исключения.
☐ 14. Назначены ответственные за согласование изменений и устранение замечаний.
☐ 15. Определены комплект итоговой выдачи и проверяемые критерии приёмки.
Такой список помогает подготовить сопоставимые исходные требования для нескольких подрядчиков. Итоговую стоимость и сроки следует сравнивать только после уточнения одинакового объёма работ: одна и та же фраза «создание BIM-модели» может скрывать существенно разный состав задач.
☐ 1. Сформулированы задачи модели и ожидаемые результаты её использования.
☐ 2. Определены объект, корпуса, секции, этап и границы моделирования.
☐ 3. Разделены создание модели по готовой документации и разработка проектных решений.
☐ 4. Подготовлен реестр исходных данных с версиями и статусами файлов.
☐ 5. Установлены координаты, оси, отметки и единицы измерения.
☐ 6. Согласованы разделы, системы и категории моделируемых элементов.
☐ 7. Перечислены исключения и элементы, которые моделировать не требуется.
☐ 8. Описана геометрия, необходимая для каждой задачи и этапа выдачи.
☐ 9. Приложена спецификация обязательных атрибутов и правил их заполнения.
☐ 10. Согласованы классификация, идентификаторы и справочники значений.
☐ 11. Установлены форматы, версии файлов, правила экспорта и именования.
☐ 12. Определены контрольные точки и способ обмена актуальными моделями.
☐ 13. Описаны проверки геометрии, данных и коллизий, включая исключения.
☐ 14. Назначены ответственные за согласование изменений и устранение замечаний.
☐ 15. Определены комплект итоговой выдачи и проверяемые критерии приёмки.
Такой список помогает подготовить сопоставимые исходные требования для нескольких подрядчиков. Итоговую стоимость и сроки следует сравнивать только после уточнения одинакового объёма работ: одна и та же фраза «создание BIM-модели» может скрывать существенно разный состав задач.
Частые вопросы заказчиков
Можно ли заказать BIM-модель, если есть только DWG и PDF?
Да, если исходные чертежи позволяют восстановить нужные элементы и сведения. В ТЗ важно определить актуальный комплект документов, пределы моделирования, перечень недостающих данных и порядок согласования противоречий. Создание модели по чертежам не означает автоматическую проверку и разработку проектных решений.
Обязательно ли передавать исходный файл Revit?
Не для каждого заказа. Если нужно дальнейшее редактирование в определённом ПО, рабочий формат и версия программы закрепляются в ТЗ и договоре. Если задача ограничена проверками или обменом данными, состав передачи может быть иным; его определяют требования получателя.
Достаточно ли одного LOD для всего здания?
Обычно такая запись слишком общая. У разных элементов могут отличаться требования к геометрии и данным, а на разных этапах — назначение выдачи. Практичнее задать матрицу по категориям элементов и конкретным целям.
Кто определяет требования к параметрам модели?
Потребность в данных задаёт заказчик или уполномоченный им специалист. Исполнитель может помочь уточнить реализуемость требований, имена параметров и способ обмена. Итоговая спецификация должна быть согласована до разработки или до соответствующей контрольной точки.
Нужно ли требовать модель без единой коллизии?
Лучше установить правила проверки, категории значимых конфликтов и допустимые исключения. Часть обнаруженных пересечений может быть предусмотрена проектным решением или связана со способом моделирования. Поэтому принимать модель по одному абсолютному числу без контекста некорректно.
Можно ли проверить атрибуты автоматически?
Многие проверки наличия и допустимости свойств автоматизируются, если требования формализованы. Для IFC-моделей может применяться IDS. Геометрические проверки и оценка корректности инженерных решений выполняются другими средствами и процедурами.
Да, если исходные чертежи позволяют восстановить нужные элементы и сведения. В ТЗ важно определить актуальный комплект документов, пределы моделирования, перечень недостающих данных и порядок согласования противоречий. Создание модели по чертежам не означает автоматическую проверку и разработку проектных решений.
Обязательно ли передавать исходный файл Revit?
Не для каждого заказа. Если нужно дальнейшее редактирование в определённом ПО, рабочий формат и версия программы закрепляются в ТЗ и договоре. Если задача ограничена проверками или обменом данными, состав передачи может быть иным; его определяют требования получателя.
Достаточно ли одного LOD для всего здания?
Обычно такая запись слишком общая. У разных элементов могут отличаться требования к геометрии и данным, а на разных этапах — назначение выдачи. Практичнее задать матрицу по категориям элементов и конкретным целям.
Кто определяет требования к параметрам модели?
Потребность в данных задаёт заказчик или уполномоченный им специалист. Исполнитель может помочь уточнить реализуемость требований, имена параметров и способ обмена. Итоговая спецификация должна быть согласована до разработки или до соответствующей контрольной точки.
Нужно ли требовать модель без единой коллизии?
Лучше установить правила проверки, категории значимых конфликтов и допустимые исключения. Часть обнаруженных пересечений может быть предусмотрена проектным решением или связана со способом моделирования. Поэтому принимать модель по одному абсолютному числу без контекста некорректно.
Можно ли проверить атрибуты автоматически?
Многие проверки наличия и допустимости свойств автоматизируются, если требования формализованы. Для IFC-моделей может применяться IDS. Геометрические проверки и оценка корректности инженерных решений выполняются другими средствами и процедурами.
Как получить модель, пригодную для ваших задач
При подготовке ТЗ полезно пройти одну цепочку: задача заказчика → элементы и сведения → формат передачи → метод проверки → критерий приёмки. Если какое-то звено отсутствует, результат остаётся открытым для толкования. Особое внимание стоит уделить границам моделирования, составу атрибутов и документам, по которым подрядчик будет подтверждать соответствие.
TrueBIM выполняет комплексное BIM-проектирование и работает с информационными моделями зданий и инженерных систем. Если вы планируете заказать BIM-модель, можно направить исходную документацию и описание задач: обсудим состав работ, необходимые данные, форматы передачи и порядок проверки результата.
TrueBIM выполняет комплексное BIM-проектирование и работает с информационными моделями зданий и инженерных систем. Если вы планируете заказать BIM-модель, можно направить исходную документацию и описание задач: обсудим состав работ, необходимые данные, форматы передачи и порядок проверки результата.
Мы открыты к сотрудничеству
Оставьте заявку и получите детализацию стоимости проектирования в Revit