Вы получили BIM-модель от проектировщика, субподрядчика или своего же отдела и должны решить: подписывать акт приемки или нет. С момента подписания модель считается принятой вместе с ней вы принимаете и ее ошибки, даже те, что пока не обнаружены.
Вы получили BIM-модель — от проектировщика, субподрядчика или своего же отдела — и должны решить: подписывать акт приемки или нет. С момента подписания модель считается принятой — вместе с ней вы принимаете и ее ошибки, даже те, что пока не обнаружены. Единственный способ снизить этот риск — понять, что скрывается за аккуратным оформлением, до того как акт будет подписан.
Модель выглядит готовой: разделы заполнены, визуализация аккуратная, срок сдан вовремя. Но аккуратное оформление говорит только о том, что кто-то потратил время на подготовку модели, — оно ничего не говорит о том, прошла ли она инженерную проверку. Пересечение элементов разных разделов, незаполненный параметр, отклонение от согласованных требований — все это не видно на общем виде и не мешает модели выглядеть завершенной.
Если такая проблема останется незамеченной на этом этапе, она никуда не денется — она перейдет на стройплощадку, где ее обнаружат уже не в файле, а в конструкции, и исправление обойдется дороже, чем на этапе модели.
Сомнение, которое вы сейчас испытываете, — не недостаток квалификации, а недостаток информации: беглый просмотр модели не отвечает на вопрос, готова ли она на самом деле. Разница между тем, что модель выглядит готовой, и тем, что она прошла проверку, — определяет, чем вы рискуете, подписывая акт.
Первое, с чем аудит BIM-модели путают чаще всего, — с проверкой модели на коллизии. Это разные вещи: проверка коллизий отвечает на вопрос «где элементы пересекаются или расположены слишком близко»; аудит — на вопрос шире: «готова ли модель к следующему этапу». Спутать их — значит заказать одно, а получить другое: список пересечений там, где нужна была оценка готовности модели в целом. Пересечения — лишь один из параметров, которые для этого проверяются.
Аудит BIM-модели — это инженерная оценка самой модели и процессов работы с ней: от геометрии элементов и заполненности параметров до соответствия модели требованиям заказчика и ее готовности к дальнейшей работе. Программа поиска пересечений здесь — инструмент сбора данных, а не источник вывода: она покажет координаты пересечения, но не скажет, критично ли оно, — это остается задачей специалиста.
Экспертиза проектной документации (в том числе государственная) — тоже не то же самое, что аудит: она проверяет документацию на соответствие нормам и регламентам в рамках обязательной процедуры, а не по инициативе того, кто хочет оценить качество модели. Аудит может быть полезным шагом перед экспертизой, но не заменяет ее.
Аудит может стать основанием для решения о приемке модели — но это не одно и то же. Приемка завершается подписанием акта между заказчиком и тем, кто модель передал, и включает не только инженерную оценку, но и организационную сторону: кто и как подтверждает результат.
Разница между этими понятиями — не терминологическая придирка: от нее зависит, за что именно платит заказчик, — будь то проверка коллизий, экспертиза или приемка модели.
Термины, которые встретятся дальше Кредитный конвейер: как автоматизация полного цикла займа меняет экономику МФО Российские решения для ЖКХ и ИТС ИИ-агенты становятся слишком дорогими в эксплуатации
Есть соблазн думать: ошибку в модели допустил проектировщик, ему ее и исправлять — а моя роль на этом заканчивается, как только акт подписан. На практике не так: пока выясняется, кто виноват, стройка уже стоит — а график и бюджет, которые в этот момент останавливаются, принадлежат заказчику, а не тому, кто ошибся в модели.
Проектировщик может нести договорную ответственность за саму ошибку — и в итоге получить или не получить претензию. Но это отдельный и более медленный процесс, который не отменяет того, что происходит на площадке прямо сейчас: элемент демонтируют или переделывают, смежные работы стоят, а срок сдачи объекта сам по себе не сдвигается. Эти издержки заказчик несет в моменте — независимо от исхода будущего разбирательства.
Поэтому на вопрос «это моя проблема или проектировщика» есть прямой ответ: с момента приемки модели — ваша, и будущая ответственность проектировщика ее не отменяет и не откладывает.
Типичный отраслевой сценарий — не описание конкретного проекта, а обобщенная ситуация, которая закономерно повторяется там, где модель принимается без проверки коллизий между разделами: труба и воздуховод проложены в одном техническом коридоре без зазора, достаточного для монтажа теплоизоляции. Формально элементы не пересекаются — это именно то, что раздел 2 назвал мягкой коллизией, — и в модели, принятой «на глаз», такой недостаток зазора остается незамеченным, потому что модель в целом выглядит завершенной (раздел 1). Обнаруживается это не в файле, а на площадке — когда монтажник приходит на этот участок с изоляцией в руках и не может ее уложить.
Дальше события развиваются предсказуемо. Работы на этом участке останавливаются: нельзя примотать теплоизоляцию туда, где для нее физически нет места. Монтажника можно временно переключить на другой фронт, если он есть, но сам конфликт это не решает: нужно либо перетрассировать один из элементов, либо, если это невозможно, пересматривать способ прокладки на этом участке — а это отдельное решение и отдельное согласование, а не то, что можно исправить на месте вручную. Ни один из участников не ошибся в своем разделе по отдельности — конфликт создало отсутствие проверки на стыке между разделами, и обнаружился он в худшем возможном месте — на стройплощадке, а не в модели. Читайте также 
Новый дивный мир AI, что он обещает бизнесу и людям? Западные аналитики недавно обнародовали данные, которые заставляют по-новому взглянуть на влияние искусственного интеллекта на занятость. Оказалось, что компании, по-настоящему вложившиеся в ИИ, не только не сокращают персонал, а наоборот, активно нанимают людей.
Раз цена ошибки — это цена, которую заказчик платит сразу и в любом случае, следующий практический вопрос — не «нужен ли аудит», а когда именно его проводить, чтобы не расплачиваться по факту.
Вопрос «когда» оказывается не менее важным, чем «нужно ли». Аудит, проведенный слишком рано, ловит не реальные проблемы, а то, что и так предстоит доделать: часть разделов модели еще не проработана, и проверка возвращает список недоделок, а не инженерных ошибок. Аудит, проведенный слишком поздно, находит те же ошибки — но исправлять их приходится не в файле: модель к этому моменту уже передана на площадку или принята по акту, и цена исправления — та, о которой шла речь в предыдущем разделе.
Между этими крайностями есть рабочее окно, и оно не совпадает с календарными сроками вроде «к концу квартала». Оно совпадает с моментом, когда кто-то дальше принимает решение на основании модели — не открывая ее и не перепроверяя самостоятельно. Таких точек в жизни проекта несколько:
Общее у всех четырех точек — не стадия проекта сама по себе, а факт, что дальше кто-то будет действовать на основании модели, не перепроверяя ее заново. Поэтому практический вопрос для читателя — не «на какой я стадии», а «кто и на основании чего примет следующее решение, если модель останется непроверенной». Именно этот вопрос определяет момент аудита, а не строка в графике проекта.
То, что аудит привязан к моменту принятия решения, а не к календарю, пока не отвечает на другой вопрос: что именно проверяется в этот момент и складывается ли это в единый метод — или в каждой точке проверяется что-то свое, без общей логики.
Может показаться, что аудит — это «прогнать модель через программу и получить список проблем». Если бы это было так, результат зависел бы только от того, кто нажал кнопку, а не от того, кто провел проверку, — и заказывать аудит не было бы смысла: тот же список можно получить самостоятельно, запустив ту же программу проверки коллизий. Разница появляется там, где за проверкой стоит метод — последовательность вопросов, а не одна кнопка.
Метод строится на трех уровнях, и каждый отвечает на свой вопрос.
Первый уровень — сама модель: ее внутреннее качество и структура. Здесь программа действительно основной инструмент — она собирает данные: пересечения, незаполненные параметры, несоответствия координат. Но данные — это еще не вывод: критично ли найденное или это допустимое инженерное решение, программа не оценивает.
Второй уровень — процессы и роли команды, которая модель создает и ведет: соответствует ли работа с моделью тому, что описано в BEP, вносятся ли параметры так, как требует EIR заказчика, есть ли дисциплина в том, кто и как правит модель. Здесь программа уже не инструмент вовсе — проверка коллизий не показывает, кто и по какому регламенту вносил изменения в файл. Это устанавливается только изучением самого процесса.
Третий уровень — готовность модели к следующему шагу: экспертизе, строительству, эксплуатации. Модель может быть внутренне безупречной и все равно не готовой — например, если она не соответствует формату, ожидаемому следующим участником, или описывает не ту стадию проекта. Готовность — не свойство модели самой по себе, а ее соответствие тому, для чего она нужна дальше.
Три уровня идут в этом порядке не случайно: сначала — симптом (что не так в самой модели), затем — причина (какой процесс это произвел), и только потом — итоговый вывод (готова ли модель к тому, для чего ее создавали). Пропустить второй уровень и сразу перейти к выводу о готовности — значит гадать о причине проблемы, а не устанавливать ее.
От того, какой из этих уровней нужен заказчику в конкретной ситуации — а иногда не все три сразу, — зависит, какую именно проверку заказывать. Это не один и тот же вопрос для каждого случая.
Слово «аудит» звучит как одна услуга, но скрывает вопрос, который важно задать раньше, чем что-то заказывать: аудит чего именно? Если заказчик просит «сделать аудит модели» без уточнения, а на самом деле его волнует, пройдет ли модель по LOD стадии, а исполнитель в ответ проверяет коллизии, — оба по-своему правы: коллизии действительно проверены, только вопрос, который стоял перед заказчиком, так и остался без ответа. Разница между тем, что было заказано, и тем, что было нужно, обнаруживается обычно поздно — когда результат уже не помогает.
За словом «аудит» стоит несколько самостоятельных видов проверки, и каждый отвечает на свой инженерный вопрос:
Каждый вид проверяет свое и требует своего метода — смешивать их в одно понятие «аудит» неточно. Полный аудит — это когда нужны ответы сразу по нескольким пунктам; но если у заказчика есть один конкретный вопрос, запрашивать весь набор не обязательно — важно понимать, что именно проверяется, а не просто произнести слово «аудит». Читайте также 
Дмитрий Лебедев: Лестница безопасности. Как работает приказ ФСТЭК № 117 В марте 2026 г. вступил в силу приказ ФСТЭК России №117, который существенно обновил требования к защите информационных систем. Почему он так важен и как именно изменит ИТ-ландшафт российских компаний, рассказывает Дмитрий Лебедев, ведущий специалист отдела продвижения продуктов «Код Безопасности».
То, какой вид или сочетание видов нужно, обычно очевидно из ситуации, а не из желания «на всякий случай проверить все». Если аудит нужен перед подачей на экспертизу — на первый план выходят LOD/LOI и соответствие стандарту, а не коллизии. Если аудит нужен перед началом строительства — наоборот, важнее коллизии и координаты: экспертиза уже позади, а столкновение труб и балок на площадке — еще нет. Заказывать полный аудит там, где нужен один конкретный ответ, так же нерационально, как заказывать проверку коллизий там, где нужен ответ про LOD.
Из всех перечисленных видов аудит коллизий — самый предметный для разбора: он проявляется не абстрактно, а конкретно в каждом инженерном разделе — и именно с этого разбора начинается следующий раздел.
Отчет о коллизиях легко может содержать сотни строк, и если отнестись ко всем одинаково, результат один из двух: либо специалист потратит время на десятки конфликтов, которые ничего не значат (зазор чуть меньше нормы там, где монтажник обойдет трубу за десять минут), либо среди этих сотен строк потеряется одна, которая означает пересечение с несущей стеной и требует пересмотра конструктива еще до начала работ. Разница между «воздуховод пересекает балку» и «труба проходит сквозь несущую стену» — это не разница в тоне формулировки, а разница в том, что можно сделать дальше: первое почти всегда решается перетрассировкой, второе иногда нельзя решить без изменения конструкции вообще.
Именно здесь заканчивается работа программы и начинается работа инженера (см. раздел 5): проверка коллизий покажет оба пересечения одинаково — просто как факт конфликта. Какое из них устраняется перетрассировкой, а какое требует пересмотра проекта, решает инженер, знакомый с конкретным разделом, а не список пересечений сам по себе.
Такие конфликты закономерно повторяются на стыках между разделами. Ниже — типичные, обобщенные примеры (не привязанные к конкретному проекту и без реальных цифр) — они иллюстрируют закономерность, а не пересказывают конкретный случай из практики Tiver Group:
Все эти конфликты становятся видны только в сводной (консолидированной) модели — объединении моделей всех разделов в одной координационной среде. Модель каждого раздела в отдельности при этом может выглядеть полностью корректной: конфликт возникает не внутри раздела, а на стыке между ними, и увидеть его может только тот, кто смотрит на сводную модель целиком, а не на разделы по очереди.
Если конфликты настолько разные по природе, встает следующий закономерный вопрос: по каким конкретным признакам вообще определяется, что модель качественная, и можно ли проверить хотя бы часть этого самостоятельно, до заказа аудита.
«Качественная модель» — фраза, которую может произнести кто угодно: и подрядчик, сдающий модель, и аудитор, эту модель проверяющий. Проблема в том, что без конкретных критериев эта фраза непроверяема ни в одну, ни в другую сторону: заказчик не может ни подтвердить, что модель действительно хороша, ни оспорить вывод о том, что она плоха, — потому что не знает, что именно должно быть проверено. Пока «качество» остается оценочным суждением, любая сторона может сказать что угодно, и крыть будет нечем.
Раздел 6 показал, какие виды проверки существуют — коллизии, параметры, классификация и так далее. Здесь речь о другом: не о том, что заказывать, а о том, что конкретно внутри модели проверяется в рамках каждого вида, и что из этого читатель может увидеть сам, еще до заказа профессионального аудита.
Ниже — критерии, основанные на общеотраслевой практике контроля качества BIM-моделей, а не эксклюзивная методология Tiver Group: этого достаточно для первой самостоятельной проверки.
Все критерии выше относятся к первому из трех уровней оценки модели (раздел 5) — к самой модели. Процессы, которыми модель создавалась, и ее готовность к сдаче проверяются по-другому — не через самостоятельный осмотр в 3D-виде.
Часть этих критериев можно проверить по разделам проектирования без специализированного ПО — просто открыв модель:
Такая проверка ловит только формальные пробелы — отсутствие связи, пустой параметр, generic-заглушку вместо реального типа элемента. Оценить, критично ли конкретное отклонение, самостоятельная проверка не дает — это тот же вопрос, что уже поднимался в разделе 7 применительно к коллизиям, и здесь он верен для любого другого критерия так же.
Этот чек-лист не заменяет организационную процедуру приемки модели — что запросить у подрядчика, у кого уточнить требования, — с ней разберемся дальше в статье; здесь речь только про то, что видно внутри самой модели.
Критерии — это то, что проверяется. Но даже когда известно, что именно смотреть, остается вопрос, как устроен сам процесс проверки: кто и на каком этапе к этому подключается, и кто отвечает за результат. Это — следующий раздел. Читайте также 
Шпионы выходят в соцсети Британская MI6 завела Instagram*, открыла приемную в даркнете и объяснила на YouTube, как с ней связаться. У ЦРУ есть Telegram, у АНБ — собственный подкаст, а немецкая разведка размещает рекламу на улицах.
Нанять аудитора и получить список замечаний — это еще не аудит, если неясно, что происходит с этим списком дальше. Частая причина, почему проверка модели не дает результата: отчет есть, а кто должен вносить исправления, кто их проверяет и когда считается, что дело закрыто, — не определено. Список замечаний без ответственного за них — это просто список, а не завершенный процесс, и деньги за него заплачены впустую, если исправления так и не внесли.
Ниже — этапы и роли, которые в целом совпадают с логикой любого профессионального аудита BIM-модели, а не эксклюзивная внутренняя процедура именно Tiver Group.
В процессе участвуют, как правило, три стороны: заказчик (на практике эту роль часто исполняет его BIM-координатор), аудитор и автор модели — проектировщик, подрядчик или внутренняя BIM-команда, за согласованность исправлений по разделам в которой обычно отвечает ее BIM-менеджер.
Роли на этих этапах распределены не произвольно:
Это не то же самое, что критерии качества из раздела 8 (там — что именно проверяется) и не то же самое, что чек-лист приемки модели, который будет дальше в статье (там — что сделать перед подписанием акта в целом, а не как устроен сам процесс аудита).
Понимание процесса и ролей закрывает вопрос «что я получаю за свои деньги». Но даже правильно устроенный процесс полагается на инструмент, который совершает часть этой работы, — и здесь важно понимать, где заканчиваются его возможности.
Официальный рабочий процесс проверки коллизий в программах вроде Autodesk Navisworks Manage сам расставляет границу за вас. Цикл работы с инструментом Clash Detective — это «выбор/создание теста → настройка правил → выбор элементов и типа теста → просмотр результатов и назначение ответственных». Последний шаг — не вывод и не решение, а передача найденного человеку: даже вендор не описывает свою программу как то, что решает, что делать с находкой.
Это не случайность конкретного продукта, а общая граница: некоторые вещи программа находит надежно и воспроизводимо, а другие остаются за пределами того, что вообще можно закодировать в правило.
Ниже — граница между тем, что фиксируется автоматически, и тем, что остается вопросом инженерной оценки:
¹ IDS (Information Delivery Specification) — открытый формат, в котором требования к модели (обязательные классификаторы, параметры, правила именования) описываются так, что программа может проверить их автоматически.
Каждая строка левой колонки — это то, что можно закодировать в явное правило и проверить воспроизводимо, вне зависимости от того, кто запускает проверку. Каждая строка правой — то, что зависит от контекста конкретного проекта, узла, стадии, и не сводится к формальному совпадению или несовпадению с правилом.
Если сама программа со своей стороны прямым текстом передает результат человеку, а не завершает процесс, — встает следующий вопрос: какую роль тогда инструмент вообще играет в аудите, и почему разные инструменты в этой роли не взаимозаменяемы.
Лицензия на программу проверки коллизий создает иллюзию, что дальше все можно сделать самостоятельно. Расхождение между «прогнать проверку» и «провести аудит» проявляется не сразу — оно обнаруживается не до, а после того, как «чистый» отчет из программы не помешал реальной проблеме дойти до площадки.
Раздел 10 уже показал часть ответа: даже официальный процесс работы с инструментами проверки коллизий заканчивается передачей результата человеку, а не решением, что с ним делать. Но есть вторая часть, которая проявляется раньше, чем дело доходит до интерпретации результатов, — сама категория инструмента определяет, что вообще попадет в этот результат.
Инструменты для проверки BIM-моделей — не один универсальный тип программы, а несколько разных категорий, и каждая требует своего инженерного подхода: Читайте также 
Николай Распопин: «Человеку не нужно запоминать номера горячих линий разных ведомств» Когда цифровые сервисы становятся привычной частью работы региона, на первый план выходит другой вопрос: как связать их в единую управляемую систему? В Красноярском крае эта задача охватывает контакт-центр 122, платформу «Край», видеоаналитику, беспилотники, ИИ-проекты, работу с данными и поддержку технологических команд. Николай Распопин, министр цифрового развития Красноярского края, объясняет, как регион выбирает практические сценарии цифровизации, где оставляет человека в контуре решений и что нужно, чтобы пилоты превращались в работающие инструменты для жителей, ведомств и экономики.
¹ BCF (BIM Collaboration Format) — формат для передачи данных о найденных замечаниях (расположение, статус, комментарии) между разными программами, без повторного ввода вручную.
Разные категории инструментов не конкурируют друг с другом за звание «лучшего» — они решают разные задачи, и выбор зависит от того, что именно нужно на конкретном проекте. Если вы все же выбираете инструмент самостоятельно, есть несколько общих ориентиров:
Инструмент, отвечающий на все четыре пункта, все равно не проводит аудит сам — он дает данные и организационную структуру для работы с ними. Сам аудит виден не в возможностях программы, а в том, что происходит после: как выглядит результат проверки, доведенный до итогового отчета, и на реальном примере — дальше в статье.
Технический заказчик получает от подрядчика сводную модель перед началом строительных работ — точка из раздела 4, где цена необнаруженной ошибки выше всего. То, что происходит дальше, — типичная последовательность событий, собранная из общей практики BIM-аудита, а не описание одного конкретного проекта: имена, точные цифры и технические детали здесь не претендуют на реальность, важна сама логика шагов.
Постановка задачи. Заказчик формулирует не «проверить модель вообще», а конкретную комбинацию видов аудита (раздел 6): коллизии и координаты — потому что вопрос сейчас один: можно ли выдавать документацию в производство работ.
Сбор данных. Автоматическая проверка сводной модели возвращает список: часть находок — мягкие коллизии (недостаточные зазоры для обслуживания), часть — жесткие пересечения между разделами, часть — просто незаполненные параметры. Список есть, но сам по себе он не говорит, что из этого можно закрыть за час, а что остановит монтаж, — это та самая граница из раздела 10.
Инженерный анализ. При разборе обнаруживается то же разнообразие, что и в разделе 7: один из воздуховодов пересекает несущую балку — вырез в этом месте по расчету недопустим, значит нужна перетрассировка воздуховода, а не правка балки; в другом месте труба и кабельный лоток проложены слишком близко друг к другу — вопрос норматива, а не только геометрии. Отдельно — элементы с незаполненными параметрами: монтажу они не мешают, но не позволяют сформировать корректную спецификацию (раздел 8).
Формирование отчета. Находки сводятся в один документ с указанием критичности и привязкой к разделу — не просто список «что не так», а то, чем можно управлять. Что именно делает такой документ управляемым, а не формальным, — отдельный вопрос дальше в статье.
Устранение замечаний. Замечания возвращаются проектной команде: воздуховод перетрассирован, параметры заполнены, кабельный лоток перенесен. Не все закрывается одинаково быстро — перетрассировка воздуховода занимает больше времени, чем заполнение параметра, и это стоит учитывать при планировании сроков, а не только констатировать по факту.
Повторная проверка. Аудитор проверяет не всю модель заново, а именно исправленные позиции (раздел 9). Только после этого модель действительно готова к тому, для чего нужна дальше, — к производству работ, а не только к тому, чтобы выглядеть завершенной (раздел 1).
Такая последовательность — не разовый прогон программы, а управляемый процесс с понятным результатом на каждом шаге. То, что заказчик получает на руки в конце этого процесса, — тоже не просто список, а отдельный вопрос, к которому стоит присмотреться внимательнее.
Раздел 12 закончился вопросом: что именно оказывается в руках у заказчика после того, как аудит завершен? Ответ — не «список того, что не так», а структурированный документ, устроенный так же предсказуемо, как любой другой инженерный отчет: это общепринятая практика оформления результата аудита, а не проприетарный шаблон конкретного исполнителя.
Такой документ обычно состоит из нескольких частей, и каждая отвечает на свой вопрос:
Собрать эти четыре части — не то же самое, что экспортировать список коллизий из программы: экспорт дает данные, а структура документа — это решение о том, как эти данные превратить в то, чем можно управлять. Каким именно должно быть содержимое находок внутри этого документа, чтобы отчет работал, — вопрос следующего раздела.
Отчет может выглядеть внушительно — десятки страниц, сотни строк — и при этом быть бесполезным, если открыть любую отдельную строку и не понять, что именно нужно сделать. Формальный отчет и рабочий отчет часто содержат одни и те же находки; разница — в том, как оформлено каждое отдельное замечание внутри перечня, о котором шла речь в разделе 13. Читайте также 
ИИ в современном образовании. Что изменили высокие технологии в аудиториях Системный кризис ценности высшего образования, разрыв между академической программой и требованиями рынка, противоречие между разными функциями вуза, необходимость пересмотра традиционных моделей, эффективное сотрудничество с бизнесом – триггером всех этих проблем высшей школы стал ИИ.
Одно замечание в качественном отчете — это не строка «есть проблема», а как минимум пять элементов, без каждого из которых замечание превращается в вопрос, а не в задачу:
Формальный отчет обычно останавливается на первых трех пунктах — где, насколько критично, в каком разделе. Рабочий отчет добавляет к этому оставшиеся два: что конкретно делать и подтверждено ли, что это сделано. Без этих двух пунктов заказчик получает не инструмент управления, а зафиксированный на бумаге список сомнений.
Отчет, оформленный так, закрывает вопрос «что мне с этим делать» без дополнительных созвонов и уточнений. Но даже хороший отчет не убережет от ошибок, которые заказчик допускает не в модели и не в отчете, а в том, как сам организует приемку, — и это следующий вопрос.
Раздел 3 показал, что цена ошибки в модели — это цена заказчика. Но здесь есть менее очевидная часть: чаще всего дело не в том, что модель содержит ошибки, а в том, как сам заказчик организует момент приемки, — и именно это, а не качество модели, определяет, будет ли ошибка обнаружена до подписания акта или после.
Ниже — типичные, обобщенные паттерны такого поведения, а не описание конкретного случая или клиента:
Приемка по визуальному впечатлению. Модель выглядит завершенной — разделы заполнены, визуализация аккуратная — и этого оказывается достаточно, чтобы подписать акт. Раздел 1 уже показал, что внешний вид не говорит о том, прошла ли модель инженерную проверку; проблема в том, что на практике именно внешний вид чаще всего и становится единственным критерием, несмотря на то, что заказчик формально это понимает.
Отсутствие запроса исходных файлов. Приемка проходит по выгрузке, скриншотам или PDF вместо файла самой модели — а без файла ни собственная, ни сторонняя проверка (например, независимый аудит) невозможна или сильно ограничена: нельзя открыть модель и посмотреть, что происходит на стыке разделов, если ее просто не передали.
Отсутствие сверки с изначальными требованиями. Модель принимается «на глаз», без сопоставления с EIR/BEP, которые сам заказчик согласовывал на старте. Если требований изначально не было зафиксировано письменно, сверять нечего — но и в этом случае ответственность за отсутствие требований лежит на заказчике, а не на исполнителе.
Доверие отчету без понимания методологии. Заказчик получает документ с находками и считает вопрос закрытым, не уточняя, что именно проверялось. Если аудит охватывал только коллизии (раздел 6), а вопрос был в соответствии стандарту, — отчет формально есть, а нужный ответ в нем не появится.
Каждая из этих ошибок устраняется не отдельным решением для каждого случая, а одной и той же практикой — заранее понятной процедурой приемки, а не разовым доверием тому, что модель или отчет выглядят убедительно. Как эта процедура выглядит на практике — дальше в статье.
Подписание акта — точка, после которой ответственность переходит к вам (раздел 3), и исправить это можно только оговорками в самом акте, а не постфактум. Ниже — не критерии качества модели (раздел 8) и не список типичных ошибок, которые к плохой приемке приводят (раздел 15), а последовательность действий: что сделать и в каком порядке, прежде чем подписывать.
Такой порядок действий не избавляет от риска найти проблему в самой модели — он избавляет от другого риска: подписать акт, не зная, что вы подписываете.
До этого момента статья показывала, как отличить настоящий аудит от простого прогона программы — уже постфактум, по процессу и по отчету. Но эта же задача стоит и раньше, на этапе выбора исполнителя, когда ни процесса, ни отчета на руках пока нет, — и оценивать приходится не результат, а то, что обещают.
Ниже — критерии, применимые к любому исполнителю аудита BIM-моделей независимо от того, к кому вы обращаетесь, а не характеристика какого-то конкретного подрядчика:
Каждый из этих критериев можно проверить одним и тем же способом — задать прямой вопрос и посмотреть, есть ли на него конкретный ответ, а не общая формулировка. Исполнитель, который может ответить на все шесть вопросов конкретно, скорее всего умеет то же самое и в самой работе, а не только в разговоре о ней. Читайте также 
Фокус на совместимости. Как отечественные ПАК изменили подход к построению ИТ-инфраструктуры Отказ оборудования, срыв сроков проекта, многомиллионные простои — риски, которые несет точечная замена ИТ-решений. IT-World разбирается, как переход на программно-аппаратные комплексы меняет правила игры.
Ниже — короткие ответы на практические вопросы, которые не поместились в основной текст статьи, но обычно возникают до или во время работы с аудитом.
Сколько времени занимает аудит BIM-модели? Зависит от объема модели и от того, какие виды аудита заказаны (раздел 6): проверка одного вида (например, только коллизий) занимает меньше времени, чем несколько видов сразу. Точный срок можно оценить только после того, как известны объем модели и охват проверки, — это стоит уточнять у исполнителя заранее (раздел 17), а не ориентироваться на усредненные цифры.
В каком формате нужно передать модель? Предпочтительно — файл модели в родном формате той программы, где она создавалась, либо в открытом формате обмена (IFC), если инструмент проверки поддерживает импорт через него (раздел 10). PDF, скриншоты или облегченные выгрузки не годятся: без файла модели полноценная проверка невозможна — тот же принцип, что и при приемке модели от подрядчика (раздел 16), только в обратную сторону.
Что делать, если модель не в Revit? Аудит не привязан к одной программе моделирования. Большинство инструментов проверки поддерживают импорт через IFC (раздел 10), поэтому модель из другой платформы обычно можно передать через экспорт в этот формат. Экспорт не всегда сохраняет все исходные данные без потерь, поэтому об этом стоит спросить исполнителя заранее — тот же вопрос прозрачности методологии (раздел 17).
Это разовая услуга или ее можно заказывать регулярно? Возможно и то, и другое. Раздел 4 показал, что аудит привязан к точкам принятия решений, а не к календарю; если такие точки в проекте повторяются — например, при регулярном обновлении внутреннего BIM-стандарта — логично делать проверку периодической, а не разовой. Периодичность — вопрос договоренности с конкретным исполнителем, а не фиксированного формата услуги.
Чем аудит отличается от экспертизы? Это разные процедуры: экспертиза (в том числе государственная) — регуляторная проверка документации на соответствие нормам, а аудит — инженерная оценка самой модели и процессов работы с ней. Аудит может быть полезен перед экспертизой, но не заменяет ее. Подробный разбор — в разделе 2.
Сколько стоит аудит BIM-модели? Однозначно ответить невозможно без вводных: цена зависит от объема модели, охвата проверки и числа итераций (раздел 17). Прозрачный исполнитель объяснит, из чего складывается стоимость в конкретном случае, а не назовет цифру без пояснений.
Все, о чем шла речь в этой статье — методология, виды проверки, границы автоматики, критерии качества, устройство отчета, — сводится к одной мысли, с которой статья началась: модель, которая выглядит готовой, и модель, которой можно доверять, — не одно и то же, и разница между ними не видна на глаз (раздел 1). Сомнение, с которым читатель приходит к этому вопросу, обоснованно — и у него есть конкретный, инженерный ответ, а не только выбор «доверять или нет».
Этот ответ определяет и то, что делать дальше. Ценность любой проверки модели создает не сам факт ее проведения, а инженерная экспертиза за ней: понимание разделов проектирования, умение работать с разным программным обеспечением, способность объяснить, почему находка критична, а не просто ее перечислить. Именно эта экспертиза — а не готовая услуга «аудит» — стоит за смежными направлениями работы Tiver Group: BIM-моделированием, разработкой плагинов для BIM-инструментов и BIM-отделом на аутсорсе для тех, кому нужен постоянный контроль качества, а не разовая проверка.
Отвечает ли эта статья заказчику, проектной организации, генподрядчику или BIM-координатору — независимо от того, искали вы аудит как отдельную услугу или разбирались в вопросе для себя, ответ один: важно не то, у кого есть программа для проверки коллизий, а у кого есть инженерная экспертиза, чтобы использовать ее результат (раздел 17). Если вам нужна такая экспертиза — для моделирования, для разработки инструментов под вашу задачу или для постоянного контроля качества внутри команды — с этим можно обратиться уже сейчас.
Источник: www.it-world.ru