BIM и его семь смертных грехов

1. Введение

Так называемые “семь смертных грехов”, которым посвящена статья – это семь концептуальных проблем, которые возникают в практике внедрения инфомоделирования в проектной среде. Иными словами, статья посвящена разнице между идеализированным представлением о парадигме BIM и реальностью её практического применения. Главный вывод из статьи состоит в том, что препятствия внедрению BIM лежат в основном в, так сказать, “культурной” плоскости.

2. Семь смертных грехов BIM

2.1. Технопоклонничество.

Мы хорошо знаем описанный здесь грех; и уже не раз обсуждали, что термин BIM употребляется в самых разных смыслах, обозначая сущности от самой информационной модели. Чтобы обосновать точку зрения на BIM как на парадигму, а не просто технологическое изменение, Д.Х. в контексте “технопоклонничества” вспоминает таких авторов, как Рэнди Дойч (известный на Западе эксперт, много писавший о парадигменности BIM) и Ларри Даунс с его “законом потрясения”, приведенным ниже на картинке.

Я, в свою очередь, отмечу два довольно нехороших факта, связанных с этим “смертным грехом”.
Во-первых, с проблемой многозначности термина (да и вообще определения понятий в информационном AEC) совершенно ничего не делается – наоборот, со временем всё становится только хуже. Отдельные дисциплины, пытаясь повысить свою значимость и продаваемость, придумывают новые “измерения” BIM (временами доходящие до, кажется, седьмого и восьмого), публикующиеся BIM-эксперты при помощи несмешных шуток про котят бесплодно борются с тавтологией “модель BIM” – а терминология становится всё многозначнее и запутанней, приводя к словесным конфронтациям из-за того, что стороны по сути разговаривают на разных языках.
Во-вторых, несмотря на всеобщее среди экспертов понимание BIM как парадигмы (во всяком случае, это вроде бы уже наконец стало “смыслом по умлочанию”), обсуждение BIM в итоге обязательно скатывается в обсуждение конкретных реализаций и продуктов. Вопросы типа “может ли (и – главное! – должна ли) BIM уметь то-то и то-то?” подменяются смыслом в ответах типа “Если программный пакет X при определённых тепличных условиях может это сделать, то и BIM в целом может и должен.”

2.2. Неясность.

Серьёзным ингибитором внедрения BIM является, по общему мнению австралийского сообщества инженеров и архитекторов, отсутствие ясной информации о том диапазоне услуг, которые должна предоставлять BIM. По маркетологическим причинам к BIM причисляются многие аспекты цифрового проектирования, первоначально не имевшие к нему отношения. Процессы цифровой работы в архитектуре и инжиниринге, такие как исследование формальной топологии, анализ сложных систем, рационализация геометрии – все они рано или поздно оказываются причисленными к зонтичному термину “BIM”. С другой стороны, для описания разных сторон BIM придумываются легко продаваемые аббревиатуры вроде 5D, 6D и 7D – соответственно сметы, экологическое проектирование и эксплуатационная информация.

В результате у менее информированных пользователей создаётся впечатление, что к BIM относится вообще всё интересное и направленное на интеграцию в компьютерной архитектуре. Не помогает делу и то, что сам термин “информационное моделирование зданий” очень расплывчатый и его можно нацепить практически на всё, относящееся к трехмерному строительному дизайну.

Автор подчеркивает, что для использования перспективы BIM как связующего звена между ранее несвязными дисциплинами проектирования отрасли необходимо выработать номенклатуру спектра услуг, относящихся к BIM, чтобы заказчики получили представление о том, какой ценник соответствует каким конкретно услугам и выгодам от информатизации. С другой стороны, очень важно провести границу между блуждающим, эрративным, открытым исследовательским процессом, характерным для дизайна, и более формальным, целеустремлённым процессом создания трехмерных форм и их связывания с последующим созданием разнообразной документации. Для этого необходимо исследовать “цифровую экосистему” BIM-организации, представить её на бумаге и таким образом визуализировать связи между инструментами и конечный результат рабочего процесса.

На рисунке: пример “исследования цифровой экосистемы” в части архитектурного проектирования и визуализации. Показаны используемые инструменты и точки входа информации.

2.3. Элизия.

В целом, точка зрения автора на кривую Мак-Лими суммируется следующим: в целом она ради удобства изложения скрывает целые пласты BIM, его преимуществ и особенностей. Так, кривая не объясняет, какие игроки организационного и рабочего процесса платят за сдвиг в производительности и какие получают от него выгоду. Например, те усилия в координации и совместной работе, которые раньше считались обязанностью подрядчиков разных уровней, теперь фактически перекладываются на архитекторов и инженеров. Вообще говоря, действительная кривая усилий и эффективности – это, в отличие от кривой Мак-Лими, вещь комплексная, многомерная, и субъективная, то есть она нелинейно зависит от многих других переменных, от степени проработанности модели, от степени сотрудничества между участниками организационного процесса, и будет разной для разных действующих лиц проекта.

2.4. Фарисейство.

Дошло до той пародоксальной ситуации, когда слова “интегрированное проектирование” используются как простое извинение для объяснения недостатков BIM, либо просто как модное словечко, на которое претендуют все, кто использует со своей моделью ПО для совместной работы вроде Navisworks или Solibri. Разговор об IPD ведется в основном только регуляторами и вендорами, пытающимися продать идею, теоретически правильную, но на практике трудновыполнимую. Идеалистические попытки внедрить IPD страдают от отсутствия критической переоценки, соответствующей масштабу культурного значения этой системы работы. IPD требует абсолютного разрешения огромного количества вопросов для своего внедрения – культурных, политических, юридических и вопросов делового характера.

Теоретически, концепция интегрированного BIM правильна. BIM должен рассматривать всю цепочку снабжения объекта и весь его жизненный цикл. Причина, по которой сам по себе BIM имеет мало смысла – это столкновение между традиционной системой организации строительного производства и надзора и те конкретные договоренности о сотрудничестве, которые необходимы для каких-либо реальных выгод от BIM. Пользователи BIM остаются в плюсе только в случае, если информация, требуемая для выполнения проекта, становится доступной всем участникам процесса на как можно более ранней стадии. В то же время западная строительная индустрия работает в основном по схеме “проект-тендер-возведение” (Design-Bid-Build), с отношениями между участниками, скажем так, всегда имеющими судебный потенциал. Таким образом, для IPD (и, следовательно, для BIM тоже) необходимо в некотором смысле невозможное: смена ориентации с поиска выгоды для своей организации на стремление улучшить общее для всех участников процесса дело. Серьезное отношение к IPD требует с самого начала глубоко обсудить и закрепить вопросы интеллектуальной собственности, распределения рисков, аудита процессов, наступает на профессиональный снобизм некоторых участников и вынуждает заказчика объекта идти на серьезные риски на ранних стадиях внедрения IPD.

Обращаю внимание русскоязычного читателя на относительно новую для нас и, как мне кажется, исключительно интересную информацию о взаимоотношениях IPD и BIM: получается, что большинство преимуществ, обычно приписываемых BIM, могут быть реализованы только в рамках парадигмы IPD. Также очень неопределенным после осознания такого фарисейства становится положение BIM в собственной дисциплине – моделировании. Моделирование объектов не обязательно связано с новым строительством и даже возведением – большое количество работ проводится для существующих объектов. Что касается структуры строительной отрасли, мне кажется, что критичная граница непонимания у нас – в антагонизме проектировщика и подрядчика. С удовольствием добавлю комментарии более глубоко знающих строительную отрасль экспертов.

2.5. (Само)обман.

Обычно участники проекта договариваются о минимальном уровне детализации, требуемом на начальной стадии проекта. По мере продвижения проекта становится невозможным игнорировать необходимость полной координации в 3D, поскольку выпущенные наборы документации в BIM-процессе быстро устаревают. Требования к детализации от смежных дисциплин и внешних консультантов могут серьёзно затормозить выдачу документации, в то время как архитектор проекта должен доказать полную скоординированность используемых моделей разных участников. В итоге, качественное 2D-документирование так или иначе полностью зависит от координации в 3D. Всё это привело к появлению нового типа документа, своего рода дорожной карты проекта. “План выполнения проекта” (для тех, кто вплотную занимается строительством, это звучит так похоже на ПОС, ПОР и ППР, не так ли?) дополняет контрактные документы и указывает на обязательства и ответственность сторон по изготовлению содержимого информационной модели, расписанные по стадиям. В дополнение к своей роли процедурного руководства по обмену информацией о BIM между участниками, этот план также описывает обязанности BIM-менеджеров и координатора моделей. Такой документ позволяет участникам понимать, чего конкретно ожидать от BIM, на каких стадиях проекта, и какие компенсации это подразумевает для участников, предоставляющих своё наполнение модели.

Таким образом, мы видим зарождение новых координат отношений между участниками проекта, которые – в идеальном случае – должны обеспечить разрешение противоречий в принципиально новой плоскости – плоскости информационного наполнения проекта. Именно в этой части, по моему мнению, BIM ближе всего подходит в своей концептуализации к PLM, в чем-то сходной, а в чем-то очень отличающейся технологии из отрасли MCAD. Вероятно, это мнение могут разделить и эксперты по PLM?

2.6. Неверие.

В процессе перехода на BIM образуются целые классы услуг, которым раньше не было аналогов или которые были очень трудоёмки в исполнении: координация модели, определение коллизий, планирование возведения, (автоматизированное) управление эксплуатацией. Частично изменение процессов достигается путем более плотного и более раннего участия в работе над моделью инженеров-консультантов, подрядчиков и отвечающих за контроль качества. Руководители также должны вовлекаться в процесс работы над информационной моделью – это помогает распространить понимание того, что, например, изменения в проекте проходят более сложную и зависимую от многих факторов процедуру, чем в случае с двумерной подготовкой документации.

Комментарий. Как мы видим уже из нескольких пунктов “грехов” BIM, особенностью правильного внедрения BIM в его нынешней инкарнации является его бескомпромиссная тотальность и подрывной характер изменений. На будущем круглом столе “BIM: пределы роста” это станет одной из основных тем обсуждения: возможен ли частичный BIM? Как выжить и стать эффективными в условиях внедрения BIM дисциплинам, для которых эта парадигма ещё не разработана или откровенно неэффективна?

2.7. Высокомерие

Информационно изолированные, посвященные одной дисциплине структурные единицы (так называемые “силосы”, в современном управленческом сленге) считаются рассадником неэффективности. Сегодняшние программные инструменты для BIM, по мнению автора, плохо поддерживают совместную работу над проектом на ранних стадиях. Основные исследовательские усилия направлены на проблемы внутри конкретных дисциплин и на координацию объектной модели между дисциплинами на поздних стадиях. Только в последние годы наметился прогресс в инструментах концптуального проектирования, позволяющих соединять концептуальные модели с результатами узкоспециализированного, монодисциплинарного анализа. Приводится пример того, как осознание проблемы соединения концптуальных моделей со специализированными методами их исследования родило новую терминологию в стадиях проектирования: “критерийный” проект. Он соответствует более ранней терминологии “концептуальной” стадии и представляет собой пока ещё только видение того, как в будущем BIM-модели будут использоваться для своего рода “быстрого прототипирования” проекта – оценки сценариев и вариантов с довольно глубокой проработкой по специализированным расчётам. Пока считается, что творческие возможности архитекторов ограничены нежеланием консультантов (т.е. подрядчиков специализированных работ и экспертных оценок проекта) производить анализ и моделирование множества всего того, что архитекторы желают исследовать в качестве возможного варианта. Практически невозможно встретить ПО, хорошо подходящее для задачи “скоростного” междисциплинарного сотрудничества на концептуальной стадии, для получения быстрых ответов от специализированных дисциплин на вопросы об эффективности рассматриваемого варианта. Сейчас информационные модели слишком перегружены информацией, слишком тяжелы и требовательны к детализованности, чтобы использоваться в вышеупомянутом “критерийном” дизайне с его постоянными изменениями входных параметров.

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

Д.Х. предлагает также решение проблемы перехода между концептуальными и архитектурными моделями к инженерным, расчетным моделям (с обязательными возможностями визуализации на всех этапах, этого неотъемлемого компонента BIM). По его мнению, базирующиеся на облачных вычислениях программные системы (фреймворки) снимут существующую необходимость заново строить расчетные модели, а специализированные данные для них будут извлекаться из единой информационной модели через “умные фильтры”, программные компоненты для различных семантических (смысловых) представлений одних и тех же геометрических объектов.

Комментарий. Значение “дисциплинарного высокомерия” трудно переоценить для нашей дискуссии про BIM и его пределы применимости. Лично я считаю, что Д.Х. слишком оптимистичен в отношении облачных технологий – проблемы в связывании разных дисциплин в единую модель лежат совершенно не в вычислительной (решаемой и без облака) и организационно-технической плоскости (частично решаемой при помощи облака, поскольку в нем разрозненные, специализированные данные и компоненты модели можно хранить централизованно, легко и автоматически получать доступ к актуальным версиям таких данных и делать таким образом “иллюзию единой модели” – всё в рамках оговоренной, жестко ограниченной номенклатуры ПО). Мы, надеюсь, поговорим об этом подробно в следующей публикации на Writandraw.ru.

Выводы и комментарий.