Skip navigation
RU_Hero.jpg

Совместная работа в BIM-процессах

Четко сформулированные рабочие процессы и коммуникативные структуры являются решающими 
для успеха или неудачи.

Благодаря прогрессирующей дигитализации в строительной отрасли возникают новые виды и средства коммуникации для всех участников проектирования. Обмен моделями зданий и связанными с ними документами, а также добавление информации в них может происходить практически в режиме реального времени, что обеспечивает гораздо более гибкую форму выполнения проекта и не только позволяет, но даже требует координации промежуточных статусов проектирования. Иногда, однако, слишком высокая степень сотрудничества может быть контрпродуктивной, потому что вовлеченные проектировщики должны обрабатывать большое количество информации за очень короткое время. Особенно это касается ситуаций, когда работа осуществляется параллельно над различными дисциплинами, поскольку существует дополнительная опасность того, что нужно приспосабливаться к постоянно меняющимся граничным условиям, теряясь в постоянном редактировании своей части модели, вместо того, чтобы концентрироваться на собственной проектировочной работе. Одним из способов разрешения данной сложности является создание упорядоченных структур процессов с определенными моментами передачи данных и этапами координации для отдельных частей модели, а также для всего проекта. Что касается разделения модели на части, то было выявлено, что архитектурные модели следует отделять от моделей с инженерными системами, а также что референцированная архитектура и проектирование несущих конструкций должно синхронизироваться между командами с промежутком в несколько дней, а не часов или даже минут.

Как показано на рис. 1, несколько проектировщиков разных дисциплин работают асинхронно друг с другом. Кроме того, они работают с различными настройками фильтров видов в двумерной проекции трехмерного здания. При этом маловероятно, что не будут возникать ошибки. Такое междисциплинарное проектирование в настоящее время создает дополнительную проблему, так как помимо большого количества команд и отдельных участников, существуют отдельные области ответственности и компетенции. Один человек, как правило, не может в одиночку решить проблемы, возникающие в процессе моделирования. Для достижения идеального результата в конечном итоге необходима коммуникация.


КЛАССИЧЕСКИЕ ТАБЛИЦЫ НЕ ЯВЛЯЮТСЯ РЕШЕНИЕМ
Управление и устранение многих ошибок моделирования зачастую становится сложным и трудоемким процессом. На сегодняшний день для решения этой задачи выбираются такие программы, как Microsoft Excel, так как большинство участников обычно либо уже имеют базовые знания, либо могут легко их приобрести, и это программное обеспечение часто уже установлено на их компьютерах, поэтому нет необходимости вводить новый инструмент. Если у вас есть молоток, все внезапно выглядит как гвоздь. Но эффективен ли этот путь в долгосрочной перспективе?

По мере того как с возрастающим числом участников управление усложняется экспоненциально, электронные таблицы также становятся все более подробными и обширными. Такой рабочий процесс может работать в слаженной команде только до определенной степени.  Однако реализация требует большой дисциплины и четко определенных правил игры. Так как комментарии в таблице неудобны, то для полноценной коммуникации в большинстве случаев требуются внешние каналы, такие как электронная почта, телефон или разноцветные записки, приклеиваемые к монитору. К этому моменту существуют десятки потенциальных мест, через которые может происходить коммуникация, и если она является аналоговой, то ее сложно документировать и сравнивать.  Следует опасаться того, что человеческие ошибки при этом станут повесткой дня, а не исключением. В результате электронная таблица не намного лучше рукописного списка. Ее проще пересылать или просматривать, но она не решает ключевых проблем сбора, интерпретации и согласования информации. Помимо всех процессуальных недостатков, существуют еще несколько решающих моментов: электронная таблица не имеет программного интерфейса к BIM-платформе. Таким образом, локализация отчетов по отдельным элементам модели может быть достигнута только трудоемким путем, даже проверка достоверности может быть осуществлена только ручными средствами.

Для того чтобы оцифровать процессы, абсолютно необходимо хранить данные в цифровом виде. Но собранные в цифровом виде данные не особо полезны, если их нельзя интерпретировать и искать в компьютере. В особенности можно заметить, что несмотря на, или даже из-за наличия более доступной и передаваемой информации, у всех участников проекта не возникает автоматически чувство компетенции. Причиной этого может являться недостаточная точность информации с точки зрения получателя. Что мы имеем в виду?


ПРОДУКТИВНАЯ И ЭФФЕКТИВНАЯ КОММУНИКАЦИЯ
Для того чтобы информация воспринималась и обрабатывалась как эффективно, так и продуктивно, должно быть удовлетворено как можно больше из следующих критериев:

  • Должна соблюдаться определенная степень точности, поэтому мы ожидаем минимального требования к четкости и прослеживаемости информации.
    Утверждение вроде «На первом этаже существует проблема с радиаторами» не является точной информацией, которую легко проверить на верность.
  • Информация должна быть достоверной, то есть объективно верной и правдивой на момент обработки.
    Не стоит проверять давно решенные ситуации пересечений между элементами.
  • Должна существовать некоторая актуальность для получателя, т. е. целесообразность для его сферы деятельности.
    К примеру, архитектору не важна информация об открытых концах в вентиляционной сети.
  • Сообщение не должно превышать определенную степень очевидности.
    Если инженер находится в процессе проектирования сложной водопроводной системы, то информация о пересечениях с другими дисциплинами ему не поможет, он может знать о них и даже намеренно игнорировать их на данный момент.

Теперь сравнительно легко удовлетворить требования к точности информации с помощью коммерчески доступных решений, поскольку с помощью нескольких щелчков мыши можно снабдить документацию о проблеме такой машинно обрабатываемой информацией, 
 
как настройки камеры, ссылки на затронутые элементы и различные аннотации. Остальные пункты, однако, требуют внедрения структур процессов со стороны координаторов проекта и их соблюдения участниками проекта. Прежде чем мы начнем говорить о собственно процессах, давайте рассмотрим первый пункт, потому что, к счастью, существуют признанные и поддерживаемые на разных платформах стандарты именно для этого случая.


ЦИФРОВЫЕ ЗАМЕТКИ
Полезные дополнения, такие как BIM Collaboration Format (BCF), разработанный buildSMART, позволяют сообщать о проблемах и структурировать их в асинхронном процессе проектирования, пока они выявляются, обрабатываются и решаются. Это осуществляется легковесно, без необходимости переносить полноценные (части) модели. Отчеты (англ. Issues) в BCF-файле могут использоваться в качестве цифровых заметок в простейшем смысле этого слова и предлагают дополнительную возможность хранения специализированных метаданных для комплексных процессов BIM.

Для обработки отчетов зачастую недостаточно простого описания проблемы. Она должна быть дополнительно локализована и визуально показана, что уменьшает возможности для интерпретации и ускоряет редактирование. Не спешите при создании отчетов. Назначайте исполнителей, используйте различные виды, скриншоты, аннотации, сроки, подписи, мильные камни, а также значимые типы, статус и приоритеты для предоставления предельно точной информации для Вашей команды. Продолжайте выстраивание процессов, чтобы максимизировать эффективность и результативность работы. Если Вы больше не желаете погрязть в лавине электронных писем, чатов и записок, то теперь у Вас есть возможность избежать их. Инвестированное время с лихвой вернется несколько раз, так как Ваши коллеги по команде точно знают, что Вы желаете им сообщить.

ИНТЕГРИРОВАННЫЕ ОТЧЕТЫ И ЗАДАЧИ
Хорошо зарекомендовавший себя концепт liNear Desktop для Revit был адаптирован для совместной работы.  Благодаря проверенному интерфейсу у Вас вскоре появится возможность управлять несколькими темами с отчетами и при этом взаимодействовать с моделью. В особенности структурированное управление по выбранным дисциплинам помогает Вам в любой момент отображать только те операции, которые имеют отношение к Вашим текущим задачам.

В дополнение к возможности связывать внешние источники BCF с проектом, отчеты большинства модулей liNear уже переносятся в соответствующие темы. Это особенно полезно для систематической обработки ошибок моделирования, которые были обнаружены во время анализа (например, открытые концы трубопроводов или отсутствующие значения мощности при расчете сетей), а также для детализации и передачи междисциплинарных тем (например, пересечения перекрывающих друг друга элементов в архитектурной модели). На примере другого часто встречающегося варианта использования BIM, проектирования штроб и проемов, мы рассмотрим, как эффективные структуры коммуникации на основе BCF могут быть утверждены в проектировочной практике.

ПРОЕКТИРОВАНИЕ ШТРОБ И ПРОЕМОВ ЧЕРЕЗ BCF
Проектирование штроб и проемов является излюбленным примером для комплексного BIM-процесса, так как оно по своей природе является совместным благодаря задействованным участникам и ролям. Во многих случаях процесс координации на более высоком уровне предусматривает, что ответственные за инженерные системы лица вносят содержательные предложения о строительных мерах для устранения уже известных на данный момент пересечений со строительными дисциплинами. Таким образом, входные данные процесса представляют собой список отчетов о пересечениях, а выходные данные - скоординированную модель со штробами и проемами. При этом проектировщику инженерных систем, как правило, не разрешается размещать временные проемы непосредственно на архитектурной модели. Для решения этой правовой проблемы было установлено, что сначала следует вносить предложения в форме временных заполнителей (provision for void, далее сокращенно PfV)  и направлять их координаторам строительного объекта для дальнейшей классификации. В лучшем случае эти предложения и желаемые изменения принимаются, однако, как правило, требуется несколько поправок, пока оптимальный скоординированный результат не будет достигнут.

OPEN ИЛИ CLOSED BIM?
Проектировочное решение от liNear дает Вам свободу выбора средств, с помощью которых можно реализовать процесс координации для проекта. Если Вы желаете работать исключительно в Revit, то Вашим партнерам по проекту будет полезно установить нашу бесплатную надстройку liNear Void Manager, которая позволяет использовать формат BCF для классификации PfVs на модели строительного объекта и вместе с тем проектирует принятые временные проемы (voids).

Если Вы, напротив, предпочитаете другой или даже открытый рабочий процесс, то Вы, в дополнение к архиву BCF, также можете экспортировать документ IFC с графическим представлением Ваших PfVs1. Он может быть наложен на координируемую модель в любой платформе по Вашему выбору. Отдельные PfVs могут быть дополнены информацией через файл BCF, а также легко открыты и классифицированы на целевой платформе. Для оптимального рабочего процесса Ваше программное обеспечение для разработки архитектуры должно поддерживать прямое преобразование PfVs из IFC во временные проемы.

Какой бы путь Вы ни выбрали, наше решение последовательно использовать BCF в качестве канала связи для проектирования штроб и проемов позволяет Вам передавать ценную информацию помимо собственно классификации.  То есть, к примеру, каждому PfV может быть добавлено неограниченное количество скриншотов и комментариев. Благодаря решению liNear Вы также можете сделать этот подпроцесс в значительной степени бесплатным. Давайте внимательнее рассмотрим этот момент.

ИЛЛЮСТРАЦИЯ МИКРОПРОЦЕССОВ
В то время как подзадачи размещения PfV проектировщиками инженерных систем и классификация или преобразование субподрядом сводятся к одной и той же деятельности, общая организация проекта различается в зависимости от конкретного состава проектировочной команды или сложности строительного проекта. Инструменты, сопровождающие проектировочный процесс, теперь должны оптимально адаптироваться к этим структурам, а не наоборот.

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

Стандарт BCF позволяет присваивать произвольный статус. Поэтому возможно легко представить показанные структуры в форме микропроцессов.  Однако конкретная реализация в коммерчески доступных решениях требует от пользователей соблюдения определенной дисциплины.  Решение от liNear предлагает соответствующее представление этапов процесса. Оно реализуется путем присвоения отдельных статусов с четко определенным значением. Кроме того, Вы можете назначать обозначения для переходов между двумя статусами, чтобы лучше структурировать пользовательские рабочие процессы, в конечном итоге уменьшая количество ошибок по невнимательности при их выполнении. Такой переход создает интерфейс с рядом рабочих шагов на вкладке «Отчеты и задачи», которые всегда адаптируются в соответствии с текущим статусом отчета.

Закрытые отчеты могут дополнительно содержать информацию о решении проблемы. К примеру, можно задать однозначные наименования различным этапам многоступенчатого микропроцесса, чтобы в последствии использовать информацию о статусе для координации при проектировании штроб и проемов.

PFV-МОДЕЛЬ В КАЧЕСТВЕ НОСИТЕЛЯ ИНФОРМАЦИИ
Поскольку новая дисциплина Проектирование штроб и проемов интегрирована в нашу проверенную модель управления видами, то мы можем целенаправленно включать и отключать отображение скоординированных предложений пустот на основании их статуса классификации. Это также позволяет нам продолжать пользоваться имеющейся информацией после успешной координации с моделью здания. К примеру, информация об отклоненных предложениях пустот может понадобиться, если потребуется внести изменения в системы. В местах, где проемы были отклонены, маловероятно утверждение конструктивного вмешательства в ходе реализации проекта. Поэтому иногда можно сэкономить драгоценное время, если сразу же начать искать альтернативную прокладку трубопровода. Кроме того, включение принятых предложений пустот позволяет осуществлять последующую проверку частей модели и выявление потенциально избыточных проемов.

УСТОЙЧИВЫЙ УСПЕХ БЛАГОДАРЯ ПРОЗРАЧНЫМ ПРАВИЛАМ
Некоторые разработчики, специализирующиеся на сотрудничающих платформах, рекламируют возможность в любое время и в любом месте синхронизировать части модели с облаком в режиме live. Это быстро создает впечатление, что современная работа в облаке спланирована таким образом, что каждый участник может и должен быть постоянно информирован обо всех касающихся его процессах. Но как бы заманчиво это ни звучало: слишком частое согласование может ввести сотрудников в заблуждение, поскольку они могут воспринимать новые отчеты с чрезмерной важностью и срочностью, если они приходят по отдельности, а не в совокупности. Кроме того, в случае неясности в отношении обязанностей всегда существует опасность того, что два пользователя одновременно будут работать над одной и той же проблемой, что делает объединение общих данных излишне сложным. Поэтому передача отчетов должна происходить по достижении определенных этапов и передаваемые на каждом этапе BCF-данные должны быть версионированы и архивированы для документирования процесса. В связи с этим можно и полезно использовать специализированные (облачные) решения или традиционные системы контроля версий. Это хранилище является центральным надежным источником данных в Вашем многоуровневом процессе.

Мы заканчиваем эту статью призывом к созданию упорядоченных и заранее утвержденных структур процессов.


Christian Waluga

1 Как IfcBuildingElementProxy с заданным типом PROVISIONFORVOID

 

Header: CoreDESIGN/Shutterstock