BIM-менеджер: брать в штат или отдать на аутсорс
06.08.2026EIR и BEP: документы, без которых BIM-проект не примут
С 1 августа 2026 года часть объектов в Казахстане проектируется только через ТИМСО. Школы от 600 учащихся, аэропорты, тоннели и метро, мосты длиннее 100 метров, уникальные объекты — по ним требование уже действует, а не «планируется».
И вот тут у многих компаний обнаруживается неприятное. Модель есть. Revit освоен, коллизии ловятся, картинка красивая. А проект всё равно буксует — потому что кроме модели нужен пакет регламентных документов, и в обычном «бумажном» проектировании их аналогов просто не было.
Два главных — EIR и BEP. Разберём, что это, кто за что отвечает и где обычно всё разваливается.
Коротко: кто кому что пишет
Логика простая, если один раз её увидеть.
Заказчик объясняет, какая информация ему нужна и в каком виде. Это EIR — информационные требования заказчика.
Исполнитель отвечает, как он собирается эти требования закрыть. Это BEP — план выполнения проекта.
Всё остальное — производные. Сначала предварительный BEP (до подписания договора, как часть предложения), потом основной. Между ними — планы сроков, матрица ответственности, стандарт обмена данными.
По правде говоря, главная путаница на рынке даже не в содержании этих документов, а в том, кто их пишет. Регулярно встречается ситуация, когда заказчик выдаёт задание на проектирование, добавляет строчку «выполнить с применением ТИМСО» — и всё. Никаких информационных требований. Проектировщик остаётся угадывать, что от него хотят получить на выходе.
EIR: что заказчик обязан объяснить
Определение из СП РК 1.02-111-2017 (п. 3.16) звучит суховато: документ, в котором описан уровень поставляемой информации, необходимой для осуществления капитального строительства.
По-человечески: заказчик заранее говорит, что он будет делать с моделью после сдачи. От этого зависит вообще всё.
Если модель нужна только чтобы пройти экспертизу — это один уровень детализации. Если по ней потом будут считать объёмы и вести стройку — другой. Если планируется эксплуатация через модель, с паспортами оборудования и графиками обслуживания, — третий, и он заметно дороже.
Что внутри EIR по своду правил (п. 5.7): какие компоненты информационной модели создаются на каждом этапе проекта, включая уровень детализации поставляемой информации. Плюс на практике туда же уходят:
- цели и задачи проекта — зачем вообще модель;
- форматы передачи (обычно IFC 2×3 и выше, но исходники в родном формате заказчики просят почти всегда);
- требования к именованию файлов и элементов;
- структура разбивки модели по разделам;
- правила и нормы, которые исполнитель обязан применить;
- сроки и точки передачи информации.
Тонкий момент: EIR — не пожелание. По СН РК 1.02-03-2022 и РДС РК 1.02-04-2018 информационные требования заказчика вместе с заданием на проектирование входят в состав договора и обязательны для сторон с момента утверждения заказчиком. То есть это часть договорной базы, а не приложение «на всякий случай».
BEP: ответ проектировщика
BEP (BIM execution plan, план выполнения проекта) — документ, в котором исполнитель излагает свой подход к тому, как он закроет требования заказчика.
Свод правил разводит две версии. Предварительный (pre-BEP) формируется до договора и показывает подход, возможности и компетенцию подрядчика — по сути, это часть коммерческого предложения. Основной BEP появляется после того, как условия согласованы.
Что должно быть в основном BEP (п. 5.12):
- характеристики и структура разрабатываемой модели или моделей;
- состав участников проекта и условия их взаимодействия;
- регламенты контроля графического и информационного содержимого модели.
Последний пункт стоит прочитать дважды. Регламент контроля — это не «мы проверим модель перед сдачей», а конкретика: какие проверки, с какой частотой, кто ответственный, что считается ошибкой.
Свод правил выделяет три вида проверок: автоматизированная (коллизии, несоответствие свойств и параметров, аудит имён уровней, слоёв, материалов, семейств), визуальная (единицы измерения, базовая точка, точка съёмки, служебные виды) и экспертная — нормоконтроль на соответствие проектным решениям, нормативам и тем же EIR.
По итогам проверок формируются отчёты, журнал коллизий и журнал изменений. Это тоже документы проекта, а не внутренняя кухня отдела.
Между EIR и BEP есть ещё несколько бумаг
Их обычно упускают, а потом выясняется, что без них процесс не собирается.
MIDP — основной план реализации информационных задач. Появляется после заключения договора: сроки подготовки информации, ответственные лица, применяемые протоколы и процедуры. Собирается из серии TIDP — планов по каждому конкретному разделу проекта.
Матрица ответственности. Кто за какой этап и за какую задачу отвечает. Свод правил рекомендует зафиксировать её отдельно (п. 5.13), и это тот случай, когда рекомендация экономит месяцы споров.
Стандарт обмена информацией. Условия обмена данными между подрядчиком и субподрядчиками, правила интеграции с другими данными. И там же — правила работы участников в среде общих данных.
BIMP, информационный протокол проекта. Юридически значимое допсоглашение к договору с деталями по модели и стандартам управления информацией. Ведёт его заказчик.
Список выглядит пугающе, но на реальном проекте половина этих документов — три-пять страниц каждый, и половина переиспользуется от объекта к объекту, если в компании один раз собрали внутренний стандарт.
Где всё это обычно ломается
EIR пишет тот, кто не понимает, зачем. Самый частый сценарий: заказчик скачивает чужой шаблон и подставляет название объекта. В результате в требованиях стоит уровень детализации под эксплуатацию, а бюджет заложен под «пройти экспертизу». Проектировщик либо честно считает и пугает ценой, либо соглашается и потом не вытягивает.
BEP пишется задним числом. Проект уже идёт полгода, модель живёт своей жизнью, и тут кто-то вспоминает, что нужен план выполнения. Его собирают за неделю, описывая не то, как работают, а то, как хотелось бы. На проверке расхождение видно сразу.
Регламент проверок есть, проверок нет. В BEP написано «еженедельная координация моделей», по факту первая сводная сборка делается перед сдачей. Дальше — четыре тысячи коллизий за две недели до срока.
Никто не назначен. Матрицу ответственности не сделали, роли не распределили. За информационную модель отвечают все, то есть никто. Кстати, отдельная должность BIM-менеджера в СП РК не закреплена — важно, чтобы функции были закрыты и записаны, а кем именно, компания решает сама. Мы разбирали это подробно в статье про BIM-менеджера в штате и на аутсорсе.
Где эти документы должны жить
Отдельный вопрос, который почему-то всплывает последним: а физически где всё это лежит?
Ответ в самом своде правил, п. 5.14: стандарт обмена информацией закрепляет правила взаимодействия участников проекта в рамках среды общих данных — единого информационного поля проекта. И дальше, в требованиях к безопасности: проектная организация обязана обеспечить контролируемый доступ к данным путём назначения прав доступа к материалам среды общих данных.
То есть СОД (среда общих данных) — не опциональная надстройка «когда дорастём», а место, где по нормативу живут и модель, и регламенты, и история изменений. Папка на сетевом диске тут не подходит: нет ролей, нет версионности, нет прослеживаемости, кто и когда что заменил.
Что важно для EIR — заказчик может (и обычно должен) прямо указать в требованиях, в какой среде ведётся проект и кто администрирует доступы. Если этого нет, каждый участник тащит свой инструмент, и на этапе объединения моделей начинается археология.
Про разницу между обычным облаком и управляемой средой мы писали отдельно: чем СОД отличается от Google Диска. А если стоит задача выбрать конкретную платформу — есть разбор Autodesk Forma, SIGNAL и SODIS под казахстанские проекты.
С чего начать, если вы впервые
Порядок, который работает на практике:
- Понять, попадает ли объект под требование. Перечень утверждён приказом МПС РК № 114 от 19.03.2026, этапы — 1 августа 2026, 1 января 2028, 1 января 2030. Если объект в первой волне, времени на раскачку нет.
- Разобраться с ролями внутри. Кто отвечает за модель, кто за координацию, кто за проверки. Без этого любой BEP будет художественным произведением.
- Собрать внутренний стандарт. Именование, структура разбивки, шаблоны проверок. Один раз — и дальше переиспользуется.
- Развернуть среду общих данных. До того, как начнётся первый обязательный проект, а не во время.
- Написать pre-BEP под конкретный тендер. Он же станет заготовкой для основного.
Если на шаге 2 стало понятно, что ролей нет и процессов тоже, начинать имеет смысл не с документов, а с честной оценки — что уже есть, чего не хватает. Логику такой оценки мы разбирали в материале про аудит готовности к BIM.
Что дальше
EIR и BEP выглядят как бюрократия, пока не увидишь альтернативу. Альтернатива — проект, где никто не договорился, что считается результатом, и выясняется это на сдаче.
Если хотите быстро понять, насколько ваша компания готова к работе по ТИМСО, — скачайте чек-лист готовности к BIM/ТИМСО. Больше ста пунктов по процессам, ПО, команде и инфраструктуре, с пометками, что критично на старте, а что можно подтянуть по ходу.
Нужна помощь с конкретным проектом — оставьте заявку, разберём вашу ситуацию и подскажем, с какого документа начинать именно вам.
Частые вопросы
Кто пишет EIR, если заказчик — государственная структура без BIM-компетенций?
Формально — заказчик. На практике требования часто готовит привлечённый консультант или технический заказчик, а госструктура утверждает. Это нормальная схема, и она лучше, чем шаблон из интернета. Главное, чтобы утверждённый документ отражал реальные задачи, а не абстрактный максимум.
Можно ли обойтись без BEP, если проект небольшой?
Если объект попадает под обязательное применение ТИМСО — нет. План выполнения проекта нужен как ответ на информационные требования. Но объём документа масштабируется: для небольшого объекта это несколько страниц, а не том.
Чем EIR отличается от задания на проектирование?
Задание на проектирование говорит, что построить. EIR — какую информацию об этом объекте и в каком виде передать заказчику. Они дополняют друг друга и оба входят в договор.
В каком формате сдавать модель?
В том, который указан в EIR. Свод правил называет IFC версии 2×3 и выше как базовый вариант для обмена, и требует, чтобы используемое ПО поддерживало импорт-экспорт в этот формат. Исходники в родном формате (Revit, Civil 3D) заказчики запрашивают отдельно — свод правил это рекомендует.
Что будет, если сдать проект без этих документов?
Комплект исходных материалов, включая информационные требования заказчика, для проектов с применением ТИМСО обязателен к загрузке при подаче на экспертизу. Неполный пакет — это возврат на доработку и потерянные недели.
