Опубликован международный стандарт LOIN - требований потребности в информации: ISO 7817-1:2024

https://www.iso.org/standard/82914.html

Это произошло ещё в июне, но по каким-то причинам в заголовках новостных лент и телеграм каналов не пестрило. Возможно зря!

Стандарт написан в развитие британского BS EN 17412-1:2020 и призван обеспечить единое понимание всеми заинтересованными сторонами потребностей в информации на различных этапах проекта, тем самым улучшая коммуникацию, эффективность и результаты проекта. Определяя четкие требования к уровню информации, стандарт призван уменьшить двусмысленность и способствовать более точному и эффективному сотрудничеству в строительной отрасли, указано в описании на сайте стандарта.

Интересно теперь ознакомиться с текстом стандарта.
Как это повлияет на стандарт IDS, устанавливающий правила описания машиночитаемых требований к той самой информации?)

Будем посмотреть!

⚠"Песец подкрался незаметно": СП333.1325800.2020 включен в "Реестр требований" и стал "обязателен" к использованию при формировании и ведении ИМ ОКС.

Сегодня коллеги из канала @bimsert напомнили о том, чтобы не торопиться использовать "Проекты" документов минстроя о требованиях к ЦИМ в соответствии с ПП№614 от 17.05.2024, о котором я тоже напоминал еще 1 сентября. Всё дело в том, что в соответствии с новой редакцией ФЗ-384 (техрегламент о безопасности зданий и сооружений), а это наверное второй документ всех строителей после ГрК РФ (ну и с ним же ФЗ-123 о пожарной безопасности), обосновывать соответствие требованиям безопасности можно через нацдокументы в реестре требований, международный стандарты и СТО в специальном федеральном фонде (который еще согласовать надо), или же используя результаты применения способов обоснования (РПСО), что по сути замена СТУ, только без необходимости муторных согласований с полным возложением ответственности на ГИПа...
В общем, почитайте ФЗ-384, он вступил в силу.

Так вот СП333.1325800.2020, который изначально не отличался работоспособностью и использовался мало кем... включен в тот самый реестр требований и подлежит проверке экспертизой, особенно в случае обязательности применения ТИМ...

Напомню, СП333* определяет "Правила формирования информационной модели объектов на различных стадиях жизненного цикла", отличается тяжеловесностью и противоречивостью, результаты его апробации показали его несостоятельность, перегруженность и нецелесообразность, в связи с чем, вероятно, никем в отрасли всерьез он не воспринимался. Теперь, судя по всему, ситуация изменится.

Пообсуждали, тут 3 варианта:
- Едим кактус и пытаемся следовать СП333...
- Разрабатываем СТО и с потугами его согласоываем (это не быстро) и используем многократно
- для каждого проекта готовим раздел РПСО, в соотетствии с ПП708 от 30.05.2024, где обосновываем соответствие ФЗ-384...

Выбор очевиден, конечно) Но толку тогда от государственных требований к ЦИМ нет, ведь их невозможно будет одинаково интерпретировать в информсистемах, возможно даже в ГИСОГД...

Конвейер IFC: собери свой обработчик IFC без умения программировать!

Изучил тут новый интересный опенсорсный проект на базе библиотеки ifcopenshell и системы автоматизации сервисов n8n - ifcpipeline (конвейер IFC).

Эта штука позволяет посредством использования методов Fast-API, подключенных из ifcopenshell собирать различные процедуры обработки полученных файлов информационных моделей в формате IFC при помощи функций, заложенных в библиотеку ifcopenshell: анализ, парсинг, конвертация, и даже проверка по ids (подробнее тут )

Соль в том, что мне даже python знать не надо, достаточно выбрать нужную функцию из методов Fast-API и поместить её как обрбатывающий узел в n8n (подробнее о n8n тут)

Таким образом можно выстроить простую цепочку функций, которые будут например брать модель IFC, затем её проверять, формировать отчет и конвертировать нужным образом
А если этого не хватит, при помощи n8n можно добавить передачу данных в самые удобные для вас сервисы - их там прям очень много!

И главное штука эта может быть развернута локально. Для нас и многих крупных компаний это особенно важно.

Пока проект в стадии альфы, но сама по себе идея прекрасна. Положил в закладки, чую, что возьмем на вооружение. Берите и вы.

Нейросетевой помощник для проектировщика - https://howie.systems/

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

Нейросети все больше и больше входят в повседневную жизнь и это отнюдь не последний пример, я думаю.

Бизнес-идея! Сделайте, пожалуйста, кто нибудь цифровой разработчик параметрических семейств по фотографии, будет пользоваться спросом 😁

❇ Интерактивная матрица коллизий

Относительно недавно в Solibri добавили новую проверку - матрицу коллизий. Сама проверка коллизий была и раньше и реализована там довольно мощно. Однако чем цепляет новый инструмент:

✅ Автоматическая матрица. Матрица создается автоматически по любым информационным наборам с многоуровневой вложенностью. Это колоссально сокращает трудозатраты, когда надо проверить много, здесь и сейчас. Любые модели с любым наполнением.
✅ Интерактивность настройки. Каждая ячейка матрицы может настраиваться индивидуально, с настройками допусков, критичности и игнорирования. Можно даже одновременно для целой группы ячеек установить нужную настройку одним кликом.
✅ Интерактивность результатов. После проверки в отдельном окне на каждом пересечении отражается количество выявленных коллизий и одним кликом по ячейке можно отфильтровать все элементы с найденными коллизиями. Все ячейки раскрашиваются цветом критичности, что бросается в глаза. Сразу видишь проблемные зоны, что очень и очень удобно.
✅ Многоуровневая структура. Элементы матрицы – как в столбцах, так и в строках – группируются по любым атрибутивным признакам и могут иметь вложенное представление. Например, по умолчанию, 1 уровень - разделы проекта (дисциплины), а в них входят IFC классы. Ну а в нашем случае можно, например, группировать по КСИ: 1 уровень таблица 4-ФнС, 2 уровень таблица 5-ТхС, 3 уровень – 6-Ком. И будет без разницы сколько файлов модели находится в сводной. Это прекрасная возможность проверять модель, невзирая на технические нюансы разделенных файлов. Модель рассматривается целиком.
✅ Импорт настроек и экспорт результатов в эксель. Если у вас есть заготовка матрицы в электронной таблице (например, вы согласовали ее с заказчиком в EIR/BEP), одной кнопкой можно загнать её в настройки и запустить проверку. А результаты экспортировать обратно в эксель и передать заказчику в формате матрицы, а не длинных нудных отчетов о коллизиях. Это повышает читаемость отчетов и позволяет документировать договоренности, не тратя много времени на ручной перенос настроек.

📸 Скриншоты ниже (не влезли, описание длинное).
Вот здесь можно почитать, а здесь - посмотреть подробнее.

Ввиду недоступности Solibri на нашем рынке, я не удивлен, что новость об этой функции в сетях особо не обсуждалась. Но было бы здорово, если бы в отечественных продуктах получилось реализовать подобный функционал.

BIM's Point

EIR – требования к обмену информацией!

Уже который раз в различных образовательных материалах в том числе пабликах соцсетей и телеграм-каналах наблюдаю одну и ту же картину, когда EIR расшифровывают как Employer’s Information Requirments или в переводе Информационные требования заказчика. И когда то это действительно соответствовало международной практике и унаследовано из британских стандартов серии PAS 1192.

Здесь напрашивается старый мем «Остановитесь» с Януковичем.

❌ Друзья, этот термин не актуален с момента выхода ISO 19650 - главенствующей серии международных стандартов про BIM.

✅ EIR это Exchange Information Requirments - Требования к обмену информацией.

❓ Почему так? Потому что основа BIM – это процессы. Процессы обмена информацией. И обмен информацией – ключевая мысль стандарта ISO 19650. Суть документа не изменилась – описать требования к передаваемой информации. Но информационный обмен — это многосторонний процесс, где информация поставляется не только заказчику. К тому же в нужное время и в нужном месте.

Такой же перевод термина был и у отмененного ГОСТ 58439.1-2019, который был локализацией ISO 19650-1:2018. Документ не претендует на всеобъемлющую правду, но хотя бы EIR расшифровывает правильно.

Но почему то везде упорно продолжают расшифровывать "E" как "Employer’s"... Предлагаю сразу импортозамещенный вариант - "ТЗ на ТИМ"!

Краткий обзор к обновлению профстандарта «Специалист в сфере информационного моделирования в строительстве»

Пробежался по верхам, решил поделиться, что заметил.

🔹В группы занятий добавили (по ОКЗ)
- 2161 Архитекторы зданий и сооружений
- 1323 Руководители подразделений (управляющие) в строительстве

🔹Отнесли к новым видам деятельности (по ОКВЭД)
- 71.11Деятельность в области архитектуры
- 41.10 Разработка строительных проектов
- 62.02 Деятельность консультативная и работы в области компьютерных технологий

🔹Среднее профессиональное образование в обобщённой трудовой функции (ОТФ) по коду В "Разработка и использование структурных элементов информационной модели ОКС на этапе его жизненного цикла" исключили, теперь только высшее (в АТФ по коду А осталось)

🔹Удалили трудовую функцию C/05.6 "Консультирование разработчиков и пользователей информационной модели ОКС по технологиям информационного моделирования".
Не царское это дело – консультации оказывать!

🔹Повсеместно в характеристиках трудовых функций сократили технологии информационного моделирования до ТИМ;
Но в возможных наименованиях профессий наоборот все что было сокращено до ТИМ раскрыли до "технологий информационного моделирования" – видимо, чтоб эйчары не сходили с ума от неведомых аббревиатур должностей!)

🔹Много разных корректировок по характеристикам трудовых функций. Не вижу смысла делать сопоставительные таблицы, просто приведу некоторые отличия.

🔸В необходимые знания очень многих трудовых функций добавили такие как:
- «Функциональные возможности программного обеспечения для информационного моделирования, просмотра данных моделей ОКС»
- «Функциональные возможности программного обеспечения для организации коллективной работы с информационными моделями ОКС»
- «Современные методы коммуникации, в том числе средства дистанционной коммуникации»

🔸В отдельных также встречались такие необходимые знания, как
- «Стандарты и своды правил разработки информационных моделей ОКС»
- «Требования законодательства Российской Федерации и иных нормативных правовых актов, нормативных технических и нормативных методических документов по архитектурно-строительному проектированию, включая технические регламенты, национальные стандарты и своды правил, санитарные нормы и правила»
- «Методы коллективной работы над единой информационной моделью ОКС»

🔸В некоторых трудовых функциях раньше было указано: «Предоставление шаблонов программного обеспечения», а теперь «Предоставление шаблонов рабочего пространства для различного программного обеспечения».
Что за рабочее пространство имели ввиду авторы, кто-нибудь знает?

🔸Ну и удалили некоторые характеристики. Например требуемые знания «Назначение и функции системы управления инженерными данными»

В целом, сильно ничего не поменялось. Но тайна с «рабочими пространствами» вызывает любопытство.

Редактор IDS от разработчиков Solibri

Солибристы тут анонсировали онлайн конструктор для разработки IDS на английском языке.
Доступен бесплатно, но с VPN и авторизацией.

Интерфейс - ничего. Подключен к справочникам bSDD, выпадающие меню по условию, как и должно быть. Например типы классов ограничиваются выбранным классом. Как и должно быть.
Из минусов - куда-то потеряли прокрутку (опуститься к элементам ниже невозможно), а еще - отсутствует как класс - фасет partOf, что даже больше расстроило. Проверять атрибутивный состав уже и без IDS многие научились, а вот фишку солибри с глубокими проверками по связям в IDS не унаследовали. Печально.

На мой взгляд в этом направлении солибристы сильно отстают, несмотря на то, что само направление очень молодое. Радует, что наши коллеги из ИСП РАН продолжают развивать абсолютно бесплатный инструмент, работающий без ВПН и регистрации. Проверяльщик бы еще автономный сделали - цены бы не было.

Ответ на пост: Эпоха перемен: IFC уходит в прошлое или почему Autodesk готов отказаться от IFC ради USD

Очередное грандиозное рукописное творение господина @ArtemBoiko вышло на хабре. 20 минут на чтение это по современным меркам уже лонгрид. Спасибо большое Артёму за такой подробный разбор очередной новой неизведанной для большинства из простых смертных инженеров темы, связанной с форматами данных для стройки. Но, выскажу-таки своё мнение.

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

Но. IFC это прежде всего стандарт описания модели данных для строительства. Для меня моделью является такое описание объекта, которое воспроизводит не только визуальный образ, но и его поведение, реакцию. В модели здания или сооружения элементы модели влияют друг на друга. То есть не просто перечислены перечнем, а имеют взаимосвязи, структуру. Я не работал с USD, но мне пока не понятно как через плоский формат можно описать структуру, подобную стандарту IFC.

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

В каком виде это будет - JSON, USD, XML или иное - не знаю, пусть вендоры решат. Мне как инженеру, описывающему объект, важно описать его таким, какой он есть в реальной жизни.

Мёртвая геометрия уже превратила концепцию BIM в глазах многих обывателей в "3D модель", где основная польза от модели - весёлые картинки на презентациях.
Поэтому очень надеюсь на здравомыслие BIM-рептилоидов разработчиков, влияющих на развитие открытых BIM-форматов, и модель останется моделью не только с позиции геометрии.

P.S. у меня одного аббревиатура USD по-прежнему ассоциируется с US Dollar?

ЦИМ и внешняя БД как способ связи между стадиями ЖЦ.

Как я и говорил, частых сообщений не будет. Поэтому тут долго было тишина. Но тут мне интересная новость попалась.

У Алексея Бабинова, руководителя департамента информационного моделирования и автоматизации компании WE-ON, вышел ролик с не для всех очевидным названием "WEB & BIM & sqlite & параметры ЦИМ ОКС" но крайне любопытным содержанием.


На YouTube (нужен vpn)
Или на rutube

Подход предполагает расширять возможности использования IFC моделей с применением внешней БД, чтобы можно было дополнять параметры элементов моделей без использования САПР. Это крайне полезно, например, для строителей. Открыл браузер, нашёл элементы (или группу) и присвоил им новые значения для своих нужд. Потом ещё и в новую версию модели можно выгрузить.

Что от себя хотелось бы отметить?

1. В предложенном подходе для связи БД и элементов используется GUID. Это чревато проблемами, т.к. очень часто при корректировке моделей в нативном САПР этот уникальный идентификатор элементов в модели данных может быть изменён, что влияет на стабильность связи. Нужен твёрдый идентификатор, который не будет изменяться, даже если поменяется модель или вообще используемая САПР.

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

3. После проектирования элементы модели должны менять не только свои атрибутивные свойства, но и пространственные. Иначе говоря, фактическое положение элементов после их строительства должно быть зафиксировано в этой модели в пространственном выражении, а не только в атрибутивном. Как на схеме в исполнительной документации. Пока такое доступно только с применением САПР, желательно и исходной модели нативного формата. Использование открытых стандартов для этих задач при предложенном подходе - серьёзный вызов, но его все равно придётся решать, потому что это возможно самое важное, что нужно на стадии строительства и эксплуатации - реальное расположение элементов в пространстве.

Алексею большое спасибо за мысли и идеи, это явно двигает отрасль вперёд и помогает специалистам взглянуть на BIM с другого ракурса.

Мой унылый канал внезапно залетел в список отраслевых подборок, и я не могу не ответить взаимностью.

Я такой список не составлял, но подписаться на канал Анастасии Кирюшиной однозначно рекомендую.
За относительно короткое время Настя стала настоящей душой BIM-сообщества, внесла непосильный вклад в организации тематических отраслевых мероприятий и продолжает нести доброе и светлое информационное моделирование в массы. Если ещё не подписаны, рекомендую.

🎓Обучение ТИМ: тому ли учим?

Недавно вышла новость о том, что Минстрой РФ утвердил типовую доппрограмму повышения квалификации по ТИМ.

Пересказывать нудно и не интересно, тем более что уважаемые люди уже публиковали свои комментарии (например, здесь и здесь) по поводу этого.

Плюс у этого, конечно, есть. Появляется хоть какой-то единый шаблон, на основании которого можно все учебные заведения страны привести к общему ТИМ-знаменателю. Это значит, что дальше можно будет оценивать качество обучения по единым критериям, что позволит, например, рейтинговать учебные заведения, тогда и выбор может быть более объективным. Кроме того, учебным заведениям теперь есть чем прикрыться. Вот же, есть типовая программа, не мы придумали, все согласовано.

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

У меня после ознакомления сложилось ощущение, что программу «склепали» из разных наборов положений в куче действующих ТИМ-стандартов (типа СП333, СП404 и т.п.), не связанных между собой, к тому же применение которых давно оспаривается в профсообществе. Еще про многострадальный ЕСИМ забыли и ИМ ОКС по ГрК (да-да, та самая, где будет куча XML).

⚠️К чему это приведет? На мой взгляд, объективно хорошее дело «выравнивания» содержания обучения без налаживания языка со стандартами и людьми, которые будут «потребителями» услуг обучившихся специалистов, приведет к отсутствию взаимопонимания. Рынок хочет одно, специалист говорит «нас учили по-другому», и вообще у нас не BIM, а ТИМ.

❓Что делать? Привести все стандарты к единому знаменателю. Просто хотя бы научиться на одном языке говорить. И определиться «че конкретно надо» от специалистов в области ТИМ.

#информационнаясреда

❓Что есть BIM?

Недавний пост у коллеги про образование BIM в очередной раз вогнал меня в депрессию констатировал факт: в России по-прежнему BIM = Revit.
Когда многие из нас (я в частности) начинали изучать BIM-технологии 10 лет назад, наибольший вклад в продвижение внесла, конечно, компания Autodesk. Естественно и я, будучи простым конструктором, пришел в BIM именно через Revit. Однако, готовив магистерский диссер на тему BIM-технологий, я очень много изучал саму методологию, которая Revit-ом, естественно, не ограничивается.

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

Основываясь на международных стандартах серии ISO 19650, информационная модель включает в себя как структурированные (трехмерные модели, базы данных, электронные таблицы) так и неструктурированные (облака точек, текстовые документы, аудио, фото, видео) данные. А среда общих данных это не просто зоны с известными статусами, а пространство, где информация распространяется в рамках управляемого процесса.

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

⚠️Дорогие бимщики! BIM это не только "Revit" и "Dynamo". Пожалуйста, учитесь не только САПР и программированию.

❇️ Учитесь бизнес-анализу, учитесь описывать процессы и оптимизировать их. Стандартизированные процессы обмена информацией позволят вовлечь в информационное моделирование больше людей, повысят достоверность и качество управляемых данных, распределит нагрузку и сделает технологию гораздо эффективнее. А применение инструментов автоматизации процессов управления информацией (СОД в том числе) позволит сократить время протекания процесса и упростить взаимодействие участников проекта.
❇️ Учитесь управлять проектами. Сроки, риски, ресурсы и т.п. Например, календарно-сетевые графики это не только "обои" на стене бытовки у прораба. Это полноценная структурированная часть информационной модели, где ее элементом является работа. Работы связаны между собой. Изменение одной работы влечет изменение в других, за счет связей. Кто вносит информацию о ресурсах? Кто вносит факт и кто его подтверждает? Какие инструменты для этого используются? Это все описывается процессами и реализуется конкретными цифровыми инструментами.
❇️ Учитесь оперировать данными. Управлять, извлекать, анализировать. Моделеориентированный подход предполагает извлечение выгод из использования(!) модели, не только для формирования чертежей и проверки на коллизии. Систематизация управления данными тоже является предметом описания процессов. Потому что как вы сформируете требования к модели в своем EIR, если не будете знать ДЛЯ ЧЕГО вы ее собрались использовать и КАК эта информация будет использована.

Где-то в глубине души у меня еще тлеет надежда, что BIM в России станет еще сильнее и не будет в головах большинства ограничиваться только САПР и 3D. Но пока что есть - то есть.

#информационнаясреда

🔍Зачем определять свойства в ЦИМ?

У проекта bimcorner вышла довольно очевидная, но всё же интересная статья о стандартизации требований к свойствам в ЦИМ.
Всё по делу, и таблички, и типы данных, и привязки к этапам и т.д. Думал, прокомментировать, что мол, уже IDS есть, в очередной раз вспомнив мой вебинарчик про IDS (за что в очередной раз спасибо за приглашение автора @bimsert), если еще не знаете что это такое, рекомендую посмотреть. Ну или ждите следующую статью от bimcorner.

🤨Меня другое зацепило. А именно абзац, где рассказывается о последовательности шагов. И конечно, первое это что? Define Your Data Scope. Все верно, определи область применения. И общими словами указано мол определите на каких этапах (с несколькими пунктами расшифровки) вы будете использовать вашу модель. А дальше сразу "Build Your Property List", ну то есть собери требуемый набор свойств. А че так можно было?
(Дальше в статье расписывается способ систематизации свойств, но я об этом не хочу говорить, можете почитать сами или у моих коллег, которые об этом частенько пишут.)

Самым распространенным способом ограничить набор требований к элементам ЦИМ является так называемая концепция LOD (Level of Development), или уровней проработки, где определенный набор уровней ограничивает определенный набор информационной насыщенности. Она и по сей день живет в различных нормативных документах многих стран.

❗️Как показала практика, LODы часто не отвечают на один простой вопрос: зачем?

В различных EIRах встречались как абстрактные LODы (сделайте-ка мне модель LOD100500, чтобы круче всех было!), так и мелкодисперстные детализированные LODы, с которыми уже хоть как-то, но можно было работать. Тем не менее, главной проблемой было отсутствие связи вписанных в LOD требований к модели к целям их использования. Проектировщик сделает вам любую детализацию, если вам нужна именно модель.
Большинство заказчиков, увы, закладывая LOD в свои ТЗ на модель, как правило вообще не знает что с этим будет делать.

❓И что тогда делать?

✅Сценарии прорабатывать. BIM-сценарии, конечно же. Сценарий это не просто описанная в двух словах цель. Это полноценный процесс, с указанием целей, входов, выходов, участников и их действиях. С указанием что, когда, кто и кому передает информацию таким образом, чтобы BIM приводил к требуемому эффекту. С описанием минимально необходимой для реализации информации. У buildingSMART аж целый проект для этого создавался.

📝Я для формализации сценария использую внутренний документ компании, который называется паспортом. А структуру данных для него заимствую из международного стандарта IDM (который, кстати, утвержден в России в качестве ГОСТ 10.0.03-2019).

⚠️Заполнение даже одного значения атрибута - это трудозатраты. Все трудозатраты должны быть обоснованы целями, для которых создается продукт (а модель - это продукт, а не только инструмент выпекания чертежей). Понимая ДЛЯ ЧЕГО вносится та или иная информация, стандартизируя процесс ее получения и передачи, мы осознаем ценность вложенного труда. А значит можем точнее измерить его стоимость. Тогда и заказчик понимает ЗА ЧТО он платит, а исполнитель понимает границы его работы.

Так давайте же подходить к определению требований осознанно. Чтобы это не выглядело - "Сделай чтоб было".

P.S. А к этой табличке атрибутов из статьи можно приделать графу с набором сценариев и отмечать какой атрибут в каком сценарии задействован. Тогда я смогу отслеживать точно какой набор информации мне потребуется для решения конкретных выбранных задач.

#информационнаясреда

➡️ Информационная модель ... процесса?

В предыдущем посте с рассказывал про проработку BIM-сценариев и говорил о том, что они включают в себя стандартизированный бизнес-процесс.

📝 Я для описания бизнес-процессов использую нотацию (т.е. язык описания) BPMN 2.0 - Business Process Model Notation.
Обратите внимание, что в расшифровке аббревиатуры присутствует слово Model - модель.

❗️Это означает, что это не просто блок схема. Это полноценная информационная модель бизнес-процесса. Моделью ее делает структурная взаимосвязь всех элементов, включая действия, события, шлюзы выбора, изменение одного из которых приводит к изменению всей модели процесса.
Такие модели, как правило, описываются в XML и могут быть интегрированы в системы автоматизации (BPMS). А современные средства описания позволяют проводить и симуляцию процесса (как на видео), а некоторые и автоматически проверять исполнимость процесса.

А вот как заставить всех работать по процессу - совсем другая история...)

#информационнаясреда #ликбез

🤔 Чего хочет заказчик?

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

Я работал консультантом от заказчика на одном крупном промышленном проекте. Надо сразу сказать, что совокупная цифровая зрелось заказчика была довольно низкой. Но аппетиты его росли вместе с ростом зрелости, которую он обретал, вовлекаясь в цифровые процессы и работу с BIM-моделями. За время работы с заказчиком я в очередной раз убедился в главной его цели - построить объект качественно, не вылезая за бюджеты и в установленные сроки. А это ключевые элементы чего? Правильно, проектного управления. А что это значит в свою очередь? Что при отсутствии корректно выстроенного проектного менеджмента на проекте никакие BIM-технологии не помогут. Вернее как, они в лучшем случае останутся в уровне проектировщика. Но со стороны заказчика модель останется "игрушкой", которой в случае чего можно похвастаться перед руководством.
Сроки при этом все равно будут "ехать вправо", а затраты все равно расти. В результате имеем отношение заказчика, у которого всё горит "и тут еще эти ваши бимы никому не нужные".

❓А когда нужные?

📈Когда заказчик начинает грамотно управлять проектом. Даже в цифровом плане не очень зрелые заказчики, но с правильно выстроенным проектным менеджментом, опираются на множество инструментов. В традиционном понимании инструменты чаще всего это люди, вернее профессионалы - лояльные, ответственные, на которых можно положиться и которым можно доверять. Каждый занимает свою роль, и проектный менеджер, как интегратор, получает всю информацию от команды проекта. Проблема в том, что людям свойственно ошибаться. Сквозные цифровые процессы обмена информацией эту проблему частично решают, сокращая количество возможных ошибок. Элементарное наличие среды общих данных, даже без BIM-моделей, резко повышает качество управления проектом, потому что появляется один источник согласованной информации (Single Source of Truth). Связанная цепочка документов с кучей метаданных и удобным поиском, автоматические статусы согласований, интерактивные отчеты и дашборды текущей ситуации по проекту и т.п. - только некоторые кейсы, позволяющие заказчику своевременно принимать управленческие решения. Однако документоориентированный подход, доминирующий в проектной практике накладывает свои ограничения - проектную документацию по прежнему разрабатывают и проверяют люди. Как следствие - ошибки и проблемы на стройплощадке.

❇️Использование BIM-моделей даже "на минималках" предоставляет заказчику возможность лучше и точнее проверить качество проектной и рабочей документации, выдаваемой в производство работ. А с ростом аппетитов он и сметы захочет, и интерактивные графики СМР, закупки и стройконтроль и т.д... Проходили.
BIM (как технология) с развитием зрелости заказчика предоставляет для него крайне удобный источник информации для управления проектом.
И именно от зрелости заказчика, прежде всего в области проектного управления, зависит глубина проработки информационных требований. Потому что зрелый в этом плане заказчик ищет надежные инструменты. И поэтому уж точно знает, чего хочет.

#информационнаясреда

⏺️Почему госзаказчик требует IFC? (Рубрика очевидное-невероятное)

Недавно в одном из чатов была дискуссия о том, почему в информационных требованиях заказчика, в основном - госзаказчика, идёт запрос на предоставление моделей в формате IFC. У специалистов, работающих в частном бизнесе, и сталкивающихся с такими требованиями, возникает закономерный вопрос: для чего? Ведь формирование моделей в формате IFC имеет свою специфику и приводит к дополнительным трудозатратам. В особенности, если до этого компания работала только в моновендорной среде.

На самом деле всё довольно просто. Все госзаказчики так или иначе связаны с ФЗ-44, проще говоря с правилами госзакупок. Согласно этому ФЗ, а именно положениям статьи 33 "Правила описания объекта закупки", заказчик не может указывать в требованиях такую характеристику, которая влечет за собой ограничение количества участников закупки. Иначе говоря, ограничивает конкуренцию. А еще есть сам ФЗ-135 "О защите конкуренции", где в нескольких статьях (11, 14, 17...) косвенно по тексту запрещено лоббирование производителей.
Если еще проще, то указание требований к предоставлению результата в формате, например, *.rvt, который можно сформировать только с применением одного конкретного программного продукта, является фактом ограничения конкуренции, а при определенных условиях и лоббирования конкретного производителя.

❓Тогда почему IFC? Так исторически сложилось.
Да потому что это самый распространенный формат для работы с ЦИМ с открытой спецификацией и не от конкретного производителя софта.
Несмотря на то, что корнями разработки являются все те же производители ПО, он не лоббирует конкретного производителя и не ограничивает конкуренцию. Выпускается-то он из большинства современных BIM-платформ.
И это несмотря на то, что он является зарубежным.
И это несмотря на то, что российские вендоры предлагали отечественные альтернативные форматы (пример 1, пример 2).
IFC доступен для чтения большинством программ для работы с моделями, существуют бесплатные и свободно распространяемые (open source) программные решения для работы с ними.
Но самое важное, что IFC не просто формат. Это стандарт, описывающий модель данных в строительстве. То есть где все элементы модели имеют принадлежность к классу и место в сложной системе взаимосвязей.

❗️Возникает еще один другой вопрос - почему тогда мы частенько встречаем в требованиях предоставление чертежей DWG и PDF? Ведь они проприетарные? Да, но они не ограничивают конкуренцию. DWG выпускается из множества CAD-программ, а PDF читается большинством бесплатных просмотрщиков. Парадоксально, но факт (хотя, может я ошибаюсь и это нарушение и на него закрывают глаза)

📔В ПП-614 от 17.05.2024, определяющим состав ИМ ОКС, основным форматом обмена является открытый формат XML по схемам, утвержденным Минстроем. Тем не менее, для отдельных видов документов, в частности трехмерных цифровых информационных моделей по-прежнему требуется IFC.

⚠️Я вижу проблему как раз в другом - отсутствие понимания заказчиком как использовать эти модели. То есть разработчики "плюхаются" делать модели по требованиям, но в результате отточенные модели кладутся на полку и не используются ни при строительстве, ни при эксплуатации.

💬Тема абсолютно дискуссионная. Если у вас есть интересные кейсы по этому вопросу, поделитесь в комментариях, было бы интересно.

P.S. Solibri, как один из лучших представителей ПО для анализа ЦИМ работает только с IFC. А государственные органы европейских стран делали ставку на IFC еще в начале прошлого десятилетия (Норвегия, в частности, имплементировала машиночитаемые требования к IFC-моделям в 2013 году и они до сих пор доступны в Solibri как внешний патч для контроля соответствия информационным требованиям).

#информационнаясреда