#Опрос Вадима Муратова @revitblog на тему влияния санкций и импортозамещения
Требуется всем инженерам, проектировщикам и BIM-координаторам пройти для передачи циферок на стол сами знаете кому
https://docs.google.com/forms/d/1hX_oAhtuYIQSqH7Emoq20XwC1DzNoBY0UBTRA5OoqNY/edit?usp=sharing
У меня заняло 1 минуту.
Требуется всем инженерам, проектировщикам и BIM-координаторам пройти для передачи циферок на стол сами знаете кому
https://docs.google.com/forms/d/1hX_oAhtuYIQSqH7Emoq20XwC1DzNoBY0UBTRA5OoqNY/edit?usp=sharing
У меня заняло 1 минуту.
Google Docs
BIM и импортозамещение в РФ и РБ
23 мая выступаю на конференции «BIM&BЕM 2022. ИМПОРТОЗАМЕЩЕНИЕ» журнала С.О.К: https://www.c-o-k.ru/seminars/bimbem-2022-importozameschenie
Для подготовки по теме импортозамещения в сфере BIM мне бы хотелось опираться не только на свои размышления, но и…
Для подготовки по теме импортозамещения в сфере BIM мне бы хотелось опираться не только на свои размышления, но и…
#СтроительныеРассказы Тендер
Семён, специалист по тендерным процедурам, открыл четвертый конверт с заявкой, перед ним на тумбе лежали уже 3 открытых с указанными тендерными предложениями. В помещении с ним находились представители участвующих компаний, они внимательно следили за тем, чтобы конкурс на выбор подрядчика проходил честно.
В 4 конверте оказалась заполненная заявка, но с пустым полем предложенной суммы.
Семён посметрел на суммы в трех других заявках: 3,4 млн. р, 3,99 млн.р и 3,2 млн. р.,.
Семён объявил: «Четвертая заявка компании… предложена сумма - 3 миллиона 100 тысяч рублей… Победителем конкурса на работы объявляю четвертого претендента, который дал самую низкую цену»
вписал в четвертую заявку 3,1 млн. р., свои ФИО и подписал.
—- Все события и персонажи вымышленные, любое совпадение с реальностью - случайно.
Семён, специалист по тендерным процедурам, открыл четвертый конверт с заявкой, перед ним на тумбе лежали уже 3 открытых с указанными тендерными предложениями. В помещении с ним находились представители участвующих компаний, они внимательно следили за тем, чтобы конкурс на выбор подрядчика проходил честно.
В 4 конверте оказалась заполненная заявка, но с пустым полем предложенной суммы.
Семён посметрел на суммы в трех других заявках: 3,4 млн. р, 3,99 млн.р и 3,2 млн. р.,.
Семён объявил: «Четвертая заявка компании… предложена сумма - 3 миллиона 100 тысяч рублей… Победителем конкурса на работы объявляю четвертого претендента, который дал самую низкую цену»
вписал в четвертую заявку 3,1 млн. р., свои ФИО и подписал.
—- Все события и персонажи вымышленные, любое совпадение с реальностью - случайно.
#Autodesk BIM 360 Docs на днях поймал баг. Судя по опросу пока еще многие в нем работают и дам рекомендацию по обходу этого бага.
Баг заключается в том, что в многостраничном PDF-документе перестали открываться Issues из реестра или и вовсе из него пропали. При этом из общего реестра Issues они открываются (но так неудобно, хочется все внутри одного файла видеть и по ним проходить).
Итак, решение:
Надо открыть забагованный файл, вручную пролистать листы и найти какое-нибудь замечание, установленное на листе (точку), запомнить лист (чтобы другим коллегам сказать, чтобы они его вручную не искали) и нажать на эту точку. Откроется Issue, нажимаете назад к списку замечаний и все работает как и прежде.
Да, данное действие с забагованным файлом надо проделать из под каждого юзера, кто этот файл в принципе смотрит, поэтому проще просто переслать коллегам эту инструкцию, чтобы понимали, что если реестр замечаний в документе не работает, то надо НАЙТИ ВРУЧНУЮ ТОЧКУ ЗАМЕЧАНИЯ В ЭТОМ ДОКУМЕНТЕ И ОТКРЫТЬ
Баг заключается в том, что в многостраничном PDF-документе перестали открываться Issues из реестра или и вовсе из него пропали. При этом из общего реестра Issues они открываются (но так неудобно, хочется все внутри одного файла видеть и по ним проходить).
Итак, решение:
Надо открыть забагованный файл, вручную пролистать листы и найти какое-нибудь замечание, установленное на листе (точку), запомнить лист (чтобы другим коллегам сказать, чтобы они его вручную не искали) и нажать на эту точку. Откроется Issue, нажимаете назад к списку замечаний и все работает как и прежде.
Да, данное действие с забагованным файлом надо проделать из под каждого юзера, кто этот файл в принципе смотрит, поэтому проще просто переслать коллегам эту инструкцию, чтобы понимали, что если реестр замечаний в документе не работает, то надо НАЙТИ ВРУЧНУЮ ТОЧКУ ЗАМЕЧАНИЯ В ЭТОМ ДОКУМЕНТЕ И ОТКРЫТЬ
#ГосТИМ Описание атрибутивного состава ЦИМ
https://minstroyrf.gov.ru/docs/183386/
Под таким заголовком опубликованы XSD-схемы будущей ТИМ-модели
Я глянул, атрибутивного состава не увидел. В основном добавлены таблицы атрибутов с возможными характеристиками самих будущих атрибутов (которыми эти таблицы надо будет наполнить). Среди этих характеристик у каждого атрибута добавлен "Код по КСИ", остальные стандартные IFC-шные.
Таблицы атрибутов это типа группы свойств, например: Общие параметры, Параметры армирования, Общие параметры стен, Общие параметры перекрытий и т.п. каждой группе еще указано в какие ifc-классы они должны добавляться по данной схеме.
Сам документ по сути пока никому не нужен, так для галочки сделан, кому-то отчитаться перед ничего не смыслящим руководством, но он позволяет нам понять общий вектор направления мысли тех кто этим там занимается.
Т.е. если мы группы свойств распределяем между классами IFC, значит мы за основу берем классы IFC, т.е. используем это как фундамент, т.е. за основу взят стандартный IFC4 и пишутся на него небольшие региональные расширения в виде отдельных атрибутов (пока таблиц под них).
А ну и ещё IfcBoreHole класс добавили - буровую скважину, видимо без него никуда (как еще уличные туалеты классифицировать?). Правда в новой версии IFC 4.3 (который сейчас в разработке у международного buildingsmart) IfcBorehole тоже добавили и у нас тут уже пошло разночтение в том большая или маленькая буква h. Как обычно, сделали единственную мелкую правку и не смогли не налажать.
https://minstroyrf.gov.ru/docs/183386/
Под таким заголовком опубликованы XSD-схемы будущей ТИМ-модели
Я глянул, атрибутивного состава не увидел. В основном добавлены таблицы атрибутов с возможными характеристиками самих будущих атрибутов (которыми эти таблицы надо будет наполнить). Среди этих характеристик у каждого атрибута добавлен "Код по КСИ", остальные стандартные IFC-шные.
Таблицы атрибутов это типа группы свойств, например: Общие параметры, Параметры армирования, Общие параметры стен, Общие параметры перекрытий и т.п. каждой группе еще указано в какие ifc-классы они должны добавляться по данной схеме.
Сам документ по сути пока никому не нужен, так для галочки сделан, кому-то отчитаться перед ничего не смыслящим руководством, но он позволяет нам понять общий вектор направления мысли тех кто этим там занимается.
Т.е. если мы группы свойств распределяем между классами IFC, значит мы за основу берем классы IFC, т.е. используем это как фундамент, т.е. за основу взят стандартный IFC4 и пишутся на него небольшие региональные расширения в виде отдельных атрибутов (пока таблиц под них).
А ну и ещё IfcBoreHole класс добавили - буровую скважину, видимо без него никуда (как еще уличные туалеты классифицировать?). Правда в новой версии IFC 4.3 (который сейчас в разработке у международного buildingsmart) IfcBorehole тоже добавили и у нас тут уже пошло разночтение в том большая или маленькая буква h. Как обычно, сделали единственную мелкую правку и не смогли не налажать.
#Классификатор Классификаторы и их маппинг. Часть 1.
По классификаторам базовые вещи описаны здесь:
https://t.me/prostobim/571
https://t.me/prostobim/572
https://t.me/prostobim/573
https://t.me/prostobim/575
Далее будет 4 части, для комплексного обсуждения предлагаю дождаться 4й.
При разработке методологии работы с проектными моделями для получения объемов можно опираться на классификаторы и таблицы маппинга.
Работа с моделями через классификаторы - это методология, которая основывается на том, что проектировщик при разработке модели заполняет в определенные параметры коды, которые однозначно определяют элемент. Далее подход может разделиться на 2 варианта:
Вариант 1, когда в код классификатора зашивается составляющая вида работ или даже ресурса.
Т.е. до 3 уровня, к примеру, классификатор делится по системам и конструктивной функции B20 - “Несущие конструкции”, B20.10 - “Вертикальные конструкции”, B20.10.10 - “Стена”, а дальше делятся по виду работ B20.10.10.001 - ”Устройство монолитной железобетонной стены класса бетона B25 с коэф. армирования 130 кг/м3”, на следующем уровне уже делится на ресурсы B20.10.10.001.001 - “Монолитный бетон В25 W6 F100” и т.д.
В такой ситуации проектировщик вынужден прописать в элемент те данные, которые не находятся в его компетенции, за которые он не отвечает, а выбор конкретной позиции из классификатора может даже означать и конкретного производителя и поставщика (например по оборудованию или например дверям, окнам).
Есть еще подход, что проектировщик указывает только определенный уровень классификатора, например 3й, а следующие уровни доуточняют уже другие специалисты.
Но в целом такой вариант подробно описывать не будем, т.к. он тупиковый и приводит к тому что в коды по классификатору потребуется вынести все параметры, которые влияют на расценки, поставщиков, технологичность и трудоемкость монтажа и прочее, что приведет к дублированию большого количества позиций в справочниках и в целом выглядит нерабочим.
продолжение следует...
По классификаторам базовые вещи описаны здесь:
https://t.me/prostobim/571
https://t.me/prostobim/572
https://t.me/prostobim/573
https://t.me/prostobim/575
Далее будет 4 части, для комплексного обсуждения предлагаю дождаться 4й.
При разработке методологии работы с проектными моделями для получения объемов можно опираться на классификаторы и таблицы маппинга.
Работа с моделями через классификаторы - это методология, которая основывается на том, что проектировщик при разработке модели заполняет в определенные параметры коды, которые однозначно определяют элемент. Далее подход может разделиться на 2 варианта:
Вариант 1, когда в код классификатора зашивается составляющая вида работ или даже ресурса.
Т.е. до 3 уровня, к примеру, классификатор делится по системам и конструктивной функции B20 - “Несущие конструкции”, B20.10 - “Вертикальные конструкции”, B20.10.10 - “Стена”, а дальше делятся по виду работ B20.10.10.001 - ”Устройство монолитной железобетонной стены класса бетона B25 с коэф. армирования 130 кг/м3”, на следующем уровне уже делится на ресурсы B20.10.10.001.001 - “Монолитный бетон В25 W6 F100” и т.д.
В такой ситуации проектировщик вынужден прописать в элемент те данные, которые не находятся в его компетенции, за которые он не отвечает, а выбор конкретной позиции из классификатора может даже означать и конкретного производителя и поставщика (например по оборудованию или например дверям, окнам).
Есть еще подход, что проектировщик указывает только определенный уровень классификатора, например 3й, а следующие уровни доуточняют уже другие специалисты.
Но в целом такой вариант подробно описывать не будем, т.к. он тупиковый и приводит к тому что в коды по классификатору потребуется вынести все параметры, которые влияют на расценки, поставщиков, технологичность и трудоемкость монтажа и прочее, что приведет к дублированию большого количества позиций в справочниках и в целом выглядит нерабочим.
продолжение следует...
Telegram
Просто о BIM
#Классификатор Основы. Часть 1.
Обычно, в широком смысле под классификаторами подразумевают справочники позиций, сгруппированные в иерархические структуры.
Примеры тому КСР у нас и Uniformat, Uniclass, Omniclass - в мире.
Но можно относиться к классам…
Обычно, в широком смысле под классификаторами подразумевают справочники позиций, сгруппированные в иерархические структуры.
Примеры тому КСР у нас и Uniformat, Uniclass, Omniclass - в мире.
Но можно относиться к классам…
#Классификатор Классификаторы и их маппинг. Часть 2.
Перейдем к варианту 2 - код по классификатору - это указание конструктивной составляющей элемента. При таком подходе в элемент вписывается его Класс, т.е. определяется его сущность до того уровня, на котором можно однозначно определить необходимый перечень параметров, которые должны быть обязательно в нем заполнены на каждом этапе проработки проекта и нужные для каждого участника взаимодействия.
Т.е. если для Стены и Пилона это будут одинаковые параметры, то не требуется их делить на 2 класса, но если Колонна - это элемент у которого геометрические характеристики задаются не параметрами Толщина и Длина, а параметрами Ширина и Высота (сечения), то это уже другой Класс.
При таком подходе можно заранее описать правила проверки элементов на содержание нужных для данного этапа и требуемых задач параметров, программно проверить модели на наличие требуемых элементов и содержание ими нужных параметров и использовать уже таблицы маппинга, опирающиеся на Классы и значения параметров. Таким образом таблицы маппинга, привязки работ к элементам будут опираться на классы и заполненные в них атрибуты.
Таблицы маппинга выглядят в виде обычных Excel или Google-таблиц, в которых в одном столбце прописывается код работы, в другом указатель из каких параметров брать ключевой объем и в каких единицах, а в следующих столбцах правила отбора нужных элементов для калькуляции по коду класса и значениям атрибутов.
Затем уже к работам отдельными таблицами могут прикрепляться сметные расценки или ресурсы, но это отдельная история, которая аналогична работе и без BIM.
продолжение следует...
Перейдем к варианту 2 - код по классификатору - это указание конструктивной составляющей элемента. При таком подходе в элемент вписывается его Класс, т.е. определяется его сущность до того уровня, на котором можно однозначно определить необходимый перечень параметров, которые должны быть обязательно в нем заполнены на каждом этапе проработки проекта и нужные для каждого участника взаимодействия.
Т.е. если для Стены и Пилона это будут одинаковые параметры, то не требуется их делить на 2 класса, но если Колонна - это элемент у которого геометрические характеристики задаются не параметрами Толщина и Длина, а параметрами Ширина и Высота (сечения), то это уже другой Класс.
При таком подходе можно заранее описать правила проверки элементов на содержание нужных для данного этапа и требуемых задач параметров, программно проверить модели на наличие требуемых элементов и содержание ими нужных параметров и использовать уже таблицы маппинга, опирающиеся на Классы и значения параметров. Таким образом таблицы маппинга, привязки работ к элементам будут опираться на классы и заполненные в них атрибуты.
Таблицы маппинга выглядят в виде обычных Excel или Google-таблиц, в которых в одном столбце прописывается код работы, в другом указатель из каких параметров брать ключевой объем и в каких единицах, а в следующих столбцах правила отбора нужных элементов для калькуляции по коду класса и значениям атрибутов.
Затем уже к работам отдельными таблицами могут прикрепляться сметные расценки или ресурсы, но это отдельная история, которая аналогична работе и без BIM.
продолжение следует...
#Классификатор Классификаторы и их маппинг. Часть 3.
В случаях, когда мы не используем классификаторы или к нам часто приходят разные модели с разным составом и структурой данных, полезно применять сервисы для настройки таблиц маппинга.
Сервис для настройки таблиц маппинга - это интерфейс через который пользователь может указать какие элементы с какими параметрами в какие работы должны попадать и из каких параметров надо брать объемные показатели для какой работы. Далее в данной системе происходит маппинг работ с ресурсами или сметными позициями, при котором указываются дополнительные формулы пересчета, коэффициенты или расходы.
Также в этой системе могут мапиться структуры работ для календарного графика, с указанием их последовательности и трудоемкости или просто импортированные даты начала и конца каждой работы, вычисленные в голове планировщика (в идеале использовать единые структуры видов работ и бюджетов/смет, но это сложно - кто-то должен будет мучиться, или все будут немного мучиться).
Сервисы для настройки таблиц маппинга лучше подходят в тех случаях, когда базовые данные нестабильны, т.е. например имена элементов и атрибуты на основе которых необходимо осуществлять группировку по видам работ и собирать объемы часто меняются. На следующих этапах работы с данными это имеет смысл в ситуациях, когда справочники работ и их связка с ресурсами и сметными расценками также нестабильны.
Минус подобных сервисов в том, что они строятся на тезисе, что невозможно всем проектировщикам задать единые стандарты моделирования и наборы параметров, мол у них у каждого будут свои написанные скрипты, плагины, шаблоны и файлы общих параметров, а также свои классификаторы видов работ, структуры бюджетов и справочники ресурсов. Но в такой ситуации каждая компания будет вынуждена сама настраивать эти таблицы маппинга и их сопровождать, редактировать в случае появления каких-то изменений, новых материалов, элементов и пр.
Т.е. основной риск в том, что сложность ручного сопоставления, маппинга сущностей может быть намного выше, чем указание правильных классов и заполнения нужных параметров. А также сложность отслеживания изменений и контроля что все сопоставления актуальны - иначе говоря, что стабильность системы является допустимой, результатам работы которой мы можем доверять и можем их верифицировать.
Такие системы позволяют нормализовать, структурировать неструктурированные данные в виде информационных моделей, которые сегодня попадают к девелоперу (или на строительную площадку), но они не мотивируют проектировщика улучшать качество своих моделей, изначально делать правильно и удобно. В таких условиях проектировщик будто может делать “как хочет”, а там мол разберутся, т.е. откладывать процесс нормализации данных на последующие этапы не задумываясь (Понятно что для каждой уникальной ситуации единожды, понятно что в целом порядок полностью не отменяется, но подход мол “потом там разберутся” не мотивирует стараться сразу).
продолжение следует...
В случаях, когда мы не используем классификаторы или к нам часто приходят разные модели с разным составом и структурой данных, полезно применять сервисы для настройки таблиц маппинга.
Сервис для настройки таблиц маппинга - это интерфейс через который пользователь может указать какие элементы с какими параметрами в какие работы должны попадать и из каких параметров надо брать объемные показатели для какой работы. Далее в данной системе происходит маппинг работ с ресурсами или сметными позициями, при котором указываются дополнительные формулы пересчета, коэффициенты или расходы.
Также в этой системе могут мапиться структуры работ для календарного графика, с указанием их последовательности и трудоемкости или просто импортированные даты начала и конца каждой работы, вычисленные в голове планировщика (в идеале использовать единые структуры видов работ и бюджетов/смет, но это сложно - кто-то должен будет мучиться, или все будут немного мучиться).
Сервисы для настройки таблиц маппинга лучше подходят в тех случаях, когда базовые данные нестабильны, т.е. например имена элементов и атрибуты на основе которых необходимо осуществлять группировку по видам работ и собирать объемы часто меняются. На следующих этапах работы с данными это имеет смысл в ситуациях, когда справочники работ и их связка с ресурсами и сметными расценками также нестабильны.
Минус подобных сервисов в том, что они строятся на тезисе, что невозможно всем проектировщикам задать единые стандарты моделирования и наборы параметров, мол у них у каждого будут свои написанные скрипты, плагины, шаблоны и файлы общих параметров, а также свои классификаторы видов работ, структуры бюджетов и справочники ресурсов. Но в такой ситуации каждая компания будет вынуждена сама настраивать эти таблицы маппинга и их сопровождать, редактировать в случае появления каких-то изменений, новых материалов, элементов и пр.
Т.е. основной риск в том, что сложность ручного сопоставления, маппинга сущностей может быть намного выше, чем указание правильных классов и заполнения нужных параметров. А также сложность отслеживания изменений и контроля что все сопоставления актуальны - иначе говоря, что стабильность системы является допустимой, результатам работы которой мы можем доверять и можем их верифицировать.
Такие системы позволяют нормализовать, структурировать неструктурированные данные в виде информационных моделей, которые сегодня попадают к девелоперу (или на строительную площадку), но они не мотивируют проектировщика улучшать качество своих моделей, изначально делать правильно и удобно. В таких условиях проектировщик будто может делать “как хочет”, а там мол разберутся, т.е. откладывать процесс нормализации данных на последующие этапы не задумываясь (Понятно что для каждой уникальной ситуации единожды, понятно что в целом порядок полностью не отменяется, но подход мол “потом там разберутся” не мотивирует стараться сразу).
продолжение следует...
#Классификатор Классификаторы и их маппинг. Часть 4.
В тоже время я не могу утверждать, что сервисы для настройки таблиц маппинга менее удобные, чем Google-таблицы. Наверное с развитием они будут лучше, удобнее, у них есть для этого все предпосылки. Они могут отображать данные не в двухмерном виде, а в многомерном, что позволит сократить количество таблиц (но усложнит их понимание). Правда приведет к проблеме зависимости от определенного сервиса (т.к. вне его не будет работать, а когда правила маппинга хранятся в Excel, то всегда можно это применить и в других системах).
Из всего выше озвученного мне видится более рабочим подход, когда один участник отрасли разрабатывает и поддерживает свой классификатор строительных элементов, таблицы атрибутов каждого класса, таблицы проверки этих атрибутов. Связывает свой классификатор с другими классификаторами видов работ, ресурсами, расценками через таблицы маппинга.
Такой участник должен быть сообществом компаний, некоммерческой организацией, который обладает достаточными компетенциями для подобной разработки (не ФАУ ФЦС и его подрядчики, и не БИМ-ассоциация). Все классификаторы и таблицы проверок и маппингов должны выкладываться на открытые ресурсы, чтобы все желающие могли изучить, перепроверить и убедиться в корректности методологии расчета.
Назовем совокупность классификаторов и таблиц маппинга их между собой - методологией. Таким образом один участник будет заниматься развитием этой методологии, собирать обратную связь, связывать свой классификатор с государственными расценками и заниматься разработкой программных продуктов (плагинов) для реализации методологии в различных проприетарных программных продуктах и возможно писать свой собственный платный или опенсорсный продукт.
Таким образом девелоперам для реализации этой методологии (которая существенно автоматизирует его деятельность и упростит работу) будет достаточно прописать в требования к проектировщику задачу выполнить условия данной методологии, т.е. заполнить определенные коды классификатора и требуемые параметры. К тому же у проектировщика будет однозначное понимание, что он на 100% выполнил все требования (т.к. автоматизированно проверил модель) и что девелопер не прибежит в конце контракта с требованиями смоделировать ещё то-то и то-то и заполнить такие-то и такие-то атрибуты.
В тоже время я не могу утверждать, что сервисы для настройки таблиц маппинга менее удобные, чем Google-таблицы. Наверное с развитием они будут лучше, удобнее, у них есть для этого все предпосылки. Они могут отображать данные не в двухмерном виде, а в многомерном, что позволит сократить количество таблиц (но усложнит их понимание). Правда приведет к проблеме зависимости от определенного сервиса (т.к. вне его не будет работать, а когда правила маппинга хранятся в Excel, то всегда можно это применить и в других системах).
Из всего выше озвученного мне видится более рабочим подход, когда один участник отрасли разрабатывает и поддерживает свой классификатор строительных элементов, таблицы атрибутов каждого класса, таблицы проверки этих атрибутов. Связывает свой классификатор с другими классификаторами видов работ, ресурсами, расценками через таблицы маппинга.
Такой участник должен быть сообществом компаний, некоммерческой организацией, который обладает достаточными компетенциями для подобной разработки (не ФАУ ФЦС и его подрядчики, и не БИМ-ассоциация). Все классификаторы и таблицы проверок и маппингов должны выкладываться на открытые ресурсы, чтобы все желающие могли изучить, перепроверить и убедиться в корректности методологии расчета.
Назовем совокупность классификаторов и таблиц маппинга их между собой - методологией. Таким образом один участник будет заниматься развитием этой методологии, собирать обратную связь, связывать свой классификатор с государственными расценками и заниматься разработкой программных продуктов (плагинов) для реализации методологии в различных проприетарных программных продуктах и возможно писать свой собственный платный или опенсорсный продукт.
Таким образом девелоперам для реализации этой методологии (которая существенно автоматизирует его деятельность и упростит работу) будет достаточно прописать в требования к проектировщику задачу выполнить условия данной методологии, т.е. заполнить определенные коды классификатора и требуемые параметры. К тому же у проектировщика будет однозначное понимание, что он на 100% выполнил все требования (т.к. автоматизированно проверил модель) и что девелопер не прибежит в конце контракта с требованиями смоделировать ещё то-то и то-то и заполнить такие-то и такие-то атрибуты.
#ГосТИМ BIM не замесТИМ?
на прошлой неделе на ancb вышла статья по итогам конференции «ЦифраГрад-2022»
http://ancb.ru/publication/read/13122
Считаю нужным ответить Михаилу Викторову и Константину Михайлику на некоторые их политизированные бравурные заблуждения.
Викторов: Работу Минстроя можно сравнить с работой хирурга – именно он может так проложить курс, чтобы не навредить здоровью всех участников процесса.
Комментарий: Как и остальные дела у нас в стране: "замах на рубль - удар на копейку", но зато научились оправдываться мол "просто надо аккуратно, без лишних жертв". Планировали внедрить BIM и разработать единую градостроительную систему - добавили русские атрибуты в IFC.
Михайлик: у отечественных компаний потенциал намного больше, чем у коллег с Запада, а возможные решения уже ничуть не хуже.
Комментарий: хуже, и потенциал и функционал, денег меньше, хорошие программисты уезжают, рынок меньше, клиентов меньше, ваших грандов хватает на месяц оплаты офиса.
Михайлик: все, что они делали […] ограничивалось тем, что исторически был сделан упор на адаптацию зарубежных продуктов
Комментарий: потому что зарубежные работают, а отечественные пробуют работать, делаются либо десятком реальных программистов (Renga), либо на иностранных библиотеках ODA (NanoCAD) и SharePoint (VitroCAD)
Михайлик: ...немного они отстают по функциональности, интерфейсу и удобству по сравнению с Автодеском. Но это значит, что нужно улучшить все эти параметры и довести продукт до мирового уровня. Это и является самой важной оперативной задачей.
Комментарий: это является вашей самой важной политической задачей поставленной вам сверху вашим руководством. Ни задачей разработчиков, ни их клиентов, а ВАШЕЙ. Поэтому не перекладывайте с больной головы на здоровую, можете например свою зарплату задонатить в ренгу или нанокад - больше пользы будет. Хотя можете и отжать у Аскона Ренгу, национализировать, стать ее директорами и ставить задачи программистам, а потом отжать ПИК и ставить задачи всем сотрудникам работать в ренге (сквозь боль и слезы).
Михайлик: до тех пор, пока мы не получали честной информации, мы строили свои прогнозы и свои выкладки на том, что у нас все здорово. Когда мы получили честную информацию, мы поняли, что сегодня требуется 3 млрд рублей федеральных средств для того, чтобы реализовать задачи, о которых мы уже отрапортовали как о реализованных в регионах.
Комментарий: То что вы сейчас называете «честной информацией» - это еще не она - честная потянет на 33 млрд рублей. Но честную вы и тогда и сейчас знаете, просто решили отмазаться, мол это там внизу нас обманывали, чтобы скинуть с себя ответственность, переложить на следующие уровни (им будет очень приятно дальше с вами работать и исполнять ваши указания).
Михайлик: Самое главное – выстроить диалог. Это очень тяжело. Очень тяжело поверить друг другу, начать инвестировать в это время, силы и средства.
Комментарий: Очень тяжело поверить тем, кто всех обманул и подставил, поставил геополитические амбиции царька выше интересов своей страны и отрасли. И очень тяжело инвестировать свои силы и средства в экономику, которую банкротит политическое руководство. Поэтому наверное мы подождем и со следующими, кто будет уже после вас поработаем.
И в конце два вопроса, которые следует задавать чиновникам после подобных выступлений: А на автомобиле какой марки Вы сюда приехали? и Какая модель вашего смартфона?
#послевас
на прошлой неделе на ancb вышла статья по итогам конференции «ЦифраГрад-2022»
http://ancb.ru/publication/read/13122
Считаю нужным ответить Михаилу Викторову и Константину Михайлику на некоторые их политизированные бравурные заблуждения.
Викторов: Работу Минстроя можно сравнить с работой хирурга – именно он может так проложить курс, чтобы не навредить здоровью всех участников процесса.
Комментарий: Как и остальные дела у нас в стране: "замах на рубль - удар на копейку", но зато научились оправдываться мол "просто надо аккуратно, без лишних жертв". Планировали внедрить BIM и разработать единую градостроительную систему - добавили русские атрибуты в IFC.
Михайлик: у отечественных компаний потенциал намного больше, чем у коллег с Запада, а возможные решения уже ничуть не хуже.
Комментарий: хуже, и потенциал и функционал, денег меньше, хорошие программисты уезжают, рынок меньше, клиентов меньше, ваших грандов хватает на месяц оплаты офиса.
Михайлик: все, что они делали […] ограничивалось тем, что исторически был сделан упор на адаптацию зарубежных продуктов
Комментарий: потому что зарубежные работают, а отечественные пробуют работать, делаются либо десятком реальных программистов (Renga), либо на иностранных библиотеках ODA (NanoCAD) и SharePoint (VitroCAD)
Михайлик: ...немного они отстают по функциональности, интерфейсу и удобству по сравнению с Автодеском. Но это значит, что нужно улучшить все эти параметры и довести продукт до мирового уровня. Это и является самой важной оперативной задачей.
Комментарий: это является вашей самой важной политической задачей поставленной вам сверху вашим руководством. Ни задачей разработчиков, ни их клиентов, а ВАШЕЙ. Поэтому не перекладывайте с больной головы на здоровую, можете например свою зарплату задонатить в ренгу или нанокад - больше пользы будет. Хотя можете и отжать у Аскона Ренгу, национализировать, стать ее директорами и ставить задачи программистам, а потом отжать ПИК и ставить задачи всем сотрудникам работать в ренге (сквозь боль и слезы).
Михайлик: до тех пор, пока мы не получали честной информации, мы строили свои прогнозы и свои выкладки на том, что у нас все здорово. Когда мы получили честную информацию, мы поняли, что сегодня требуется 3 млрд рублей федеральных средств для того, чтобы реализовать задачи, о которых мы уже отрапортовали как о реализованных в регионах.
Комментарий: То что вы сейчас называете «честной информацией» - это еще не она - честная потянет на 33 млрд рублей. Но честную вы и тогда и сейчас знаете, просто решили отмазаться, мол это там внизу нас обманывали, чтобы скинуть с себя ответственность, переложить на следующие уровни (им будет очень приятно дальше с вами работать и исполнять ваши указания).
Михайлик: Самое главное – выстроить диалог. Это очень тяжело. Очень тяжело поверить друг другу, начать инвестировать в это время, силы и средства.
Комментарий: Очень тяжело поверить тем, кто всех обманул и подставил, поставил геополитические амбиции царька выше интересов своей страны и отрасли. И очень тяжело инвестировать свои силы и средства в экономику, которую банкротит политическое руководство. Поэтому наверное мы подождем и со следующими, кто будет уже после вас поработаем.
И в конце два вопроса, которые следует задавать чиновникам после подобных выступлений: А на автомобиле какой марки Вы сюда приехали? и Какая модель вашего смартфона?
#послевас
ancb.ru
Цифровизация стройки – это навсегда, и отсидеться в стороне не получится
#Подкасты Вышел подкаст с Александром Волковым у Игоря Рогачева. Дальше напишу пару своих комментариев на поднятые темы.
https://youtu.be/s2EKrt0q4EI
Александр Волоков: Уход западных разработчиков программного обеспечения создаст положительную динамику роста доходов Российских разработчиков. И рост доходов должен незамедлительно сказаться на качестве самих программных продуктов. Они должны начать гораздо быстрее эволюционировать.
Комментарий:
При уходе с рынка Autodesk будет происходить двунаправленное движение в покупке софта. С одной стороны кто-то перейдет на отечественное, с другой - кто-то перейдет на пиратское (бесплатное) и в принципе не будет рассматривать отечественное.
Тем компаниям, кто находится в технологиях 2010го года, достаточно удобно перейти на отечественное. Те же, кто находятся на технологическом развитии 2020го года, выберут пиратское, т.к. отечественное пока не может обеспечить работоспособность технологии на данном уровне.
В то же время, государство может начать массовую борьбу с пиратством (но ситуация в стране такова, что не до этого, т.к. борьба превратится в “кошмарить бизнес” и обнаружится, что даже отечественное работает на пиратских Windows).
Но, стоит отметить, что доходы отечественных разработчиков все же растут (т.к. передовых компаний не много, а тех кто в 2010м году - масса). Но этот рост не может прямо конвертироваться в качество и рост функционала программных продуктов, т.к. программисты мирового уровня уехали и работают на иностранные компании. Отечественные разработчики еле еле успевают заменять увольняющихся, повышая всем зарплаты (благо появилось из чего).
Ни о каком росте команд речи не идет, подбор персонала сталкивается с ситуацией, когда просто нет программистов требуемого уровня - конверсия от собеседований стремится к нулю, массово снижается уровень команды, т.к. самые лучшие уходят, а набираются только начинающие, вчерашние студенты (вспомните еще как у нас учат в универах).
https://youtu.be/s2EKrt0q4EI
Александр Волоков: Уход западных разработчиков программного обеспечения создаст положительную динамику роста доходов Российских разработчиков. И рост доходов должен незамедлительно сказаться на качестве самих программных продуктов. Они должны начать гораздо быстрее эволюционировать.
Комментарий:
При уходе с рынка Autodesk будет происходить двунаправленное движение в покупке софта. С одной стороны кто-то перейдет на отечественное, с другой - кто-то перейдет на пиратское (бесплатное) и в принципе не будет рассматривать отечественное.
Тем компаниям, кто находится в технологиях 2010го года, достаточно удобно перейти на отечественное. Те же, кто находятся на технологическом развитии 2020го года, выберут пиратское, т.к. отечественное пока не может обеспечить работоспособность технологии на данном уровне.
В то же время, государство может начать массовую борьбу с пиратством (но ситуация в стране такова, что не до этого, т.к. борьба превратится в “кошмарить бизнес” и обнаружится, что даже отечественное работает на пиратских Windows).
Но, стоит отметить, что доходы отечественных разработчиков все же растут (т.к. передовых компаний не много, а тех кто в 2010м году - масса). Но этот рост не может прямо конвертироваться в качество и рост функционала программных продуктов, т.к. программисты мирового уровня уехали и работают на иностранные компании. Отечественные разработчики еле еле успевают заменять увольняющихся, повышая всем зарплаты (благо появилось из чего).
Ни о каком росте команд речи не идет, подбор персонала сталкивается с ситуацией, когда просто нет программистов требуемого уровня - конверсия от собеседований стремится к нулю, массово снижается уровень команды, т.к. самые лучшие уходят, а набираются только начинающие, вчерашние студенты (вспомните еще как у нас учат в универах).
YouTube
Александр Волков. Часть 2. Стратегический BIM | Первый BIM форум на ДВ | Цифровизация строительства
Онлайн курсы Civil 3D, Infraworks, Revit ИССО и Autodesk Subassembly Composer https://infrabim.pro/online-course
Тайминг для ленивых
00:00 Начало
01:23 Дальневосточный BIM форум
11:23 Центры компетенций BIM на Дальнем Востоке
07:59 Школа заказчика
10:56 Стройка…
Тайминг для ленивых
00:00 Начало
01:23 Дальневосточный BIM форум
11:23 Центры компетенций BIM на Дальнем Востоке
07:59 Школа заказчика
10:56 Стройка…
#Подкасты Подкаст с Александром Волковым у Рогачева. Часть 2
Продолжу некоторые комментарии к подкасту Александра Волкова, много пищи дано для размышлений и обсуждений.
Про околополитические размышления в подкасте о выгодном сотрудничестве с Китаем. Я поработал с Китайцами на 3х крупных проектах, с разными их девелоперами. На всех трех они кинули. Работать с Китайцами невозможно, они выжимают всё из вас в свою пользу, без штанов оставляют.
Когда они участвуют в проекте, они нанимают своих подрядчиков, привозят своих сотрудников, закупают свой софт, работают в своих системах. От России им нужны разве что дешевые ресурсы, если Россия начнет выпендриваться и поднимать на эти ресурсы цены, то они придут и заберут их бесплатно.
Думаю с Китаем получится также как с Северным потоком 2, мы сейчас вложим последние деньги в расширения этих магистралей, жд путей, перерабатывающих заводов, а те потом: “а дайте нам скидку в два раза больше”, или и вовсе откажутся, т.к. присоединятся к санкциям, чтобы продолжать работать с миром (из-за каких-нибудь условий 8го или 9го пакета).
Т.ч. если будет строиться вся эта инфраструктура за наш счет, то это рискованные инвестиции, которые могут прекратиться в любой момент, и повышают зависимость от Китая. Если за счет Китая, то там будут работать не наши сотрудники и не на нашем ПО, т.е. не наша экономика будет зарабатывать.
Продолжу некоторые комментарии к подкасту Александра Волкова, много пищи дано для размышлений и обсуждений.
Про околополитические размышления в подкасте о выгодном сотрудничестве с Китаем. Я поработал с Китайцами на 3х крупных проектах, с разными их девелоперами. На всех трех они кинули. Работать с Китайцами невозможно, они выжимают всё из вас в свою пользу, без штанов оставляют.
Когда они участвуют в проекте, они нанимают своих подрядчиков, привозят своих сотрудников, закупают свой софт, работают в своих системах. От России им нужны разве что дешевые ресурсы, если Россия начнет выпендриваться и поднимать на эти ресурсы цены, то они придут и заберут их бесплатно.
Думаю с Китаем получится также как с Северным потоком 2, мы сейчас вложим последние деньги в расширения этих магистралей, жд путей, перерабатывающих заводов, а те потом: “а дайте нам скидку в два раза больше”, или и вовсе откажутся, т.к. присоединятся к санкциям, чтобы продолжать работать с миром (из-за каких-нибудь условий 8го или 9го пакета).
Т.ч. если будет строиться вся эта инфраструктура за наш счет, то это рискованные инвестиции, которые могут прекратиться в любой момент, и повышают зависимость от Китая. Если за счет Китая, то там будут работать не наши сотрудники и не на нашем ПО, т.е. не наша экономика будет зарабатывать.
#Подкасты Подкаст с Александром Волковым у Рогачева. Часть 3
Александр Волоков: Если ввести правило, что например с 1 января вся стройка обменивается [электронными] формами КС-2 КС-3, ты с опозданием на сутки будешь видеть все цены и все товары в стране.
Комментарий:
Писал после прошлого подкаста в чем данная идея не правильная, но видимо коллеги не поняли мою мысль или не услышали. Напишу еще раз.
КС-2 КС-3 - это документы, которые являются основанием для оплаты, т.е. которые подтверждают, что работы по смете выполнены на определенный объем и стоимость. Эти документы имеют табличную форму, в которой набраны позиции из сметы, которая в наших реалиях составлена либо по гос. расценкам, либо по корпоративным.
В эти таблицы непосредственно с площадки попадают только объемы, т.е. количество сколько выполнено работ за указанный период. Расценки вносятся не реальные рыночные, за сколько куплены материалы или мол сколько уплачено непосредственно рабочему или субподрядчику, а взятые из сметы, которые один в один соответствуют позициям сметы (являющейся приложением к Договору), которые закрываются данной КСкой.
Т.е. еще раз: в КСках не рыночные, реальные цены, а сметные, которые заложил сметчик перед началом стройки и которые прикреплены к договору. Получив анализ этих цен никакой реальной картины со стройки, или мол “за сколько покупаются материалы” не получить, можно только подумать: “о как мы точно посчитали расценки, т.к. копейка в копейку все по ним закрываются”. Но они это делают, потому что по правилам так - есть смета, приложением к договору, закрываешь объемы по ней, процентуешь, вычерпываешь из общей суммы договора. К реальным стоимостям работ и материалов это не имеет никакого отношения, они совершенно другие.
К тому же, основная прибыль генподрядчика, которому например государство поручило выполнение работ - это разница между расценками, по которым он закрывает работы у заказчика и расценками, по которым он закрывает работы субподрядчику или выплачивает непосредственно работнику. Т.е. для генподрядчика выгодно скрывать стоимости, по которым он расплачивается с субчиками, чтобы заказчик не потребовал у него снижение цены по этим работам, т.к. мол изначально планировалось что генподрядчик работает мол под меньший процент и не экономит на качестве и стоимости материалов.
Александр Волоков: Если ввести правило, что например с 1 января вся стройка обменивается [электронными] формами КС-2 КС-3, ты с опозданием на сутки будешь видеть все цены и все товары в стране.
Комментарий:
Писал после прошлого подкаста в чем данная идея не правильная, но видимо коллеги не поняли мою мысль или не услышали. Напишу еще раз.
КС-2 КС-3 - это документы, которые являются основанием для оплаты, т.е. которые подтверждают, что работы по смете выполнены на определенный объем и стоимость. Эти документы имеют табличную форму, в которой набраны позиции из сметы, которая в наших реалиях составлена либо по гос. расценкам, либо по корпоративным.
В эти таблицы непосредственно с площадки попадают только объемы, т.е. количество сколько выполнено работ за указанный период. Расценки вносятся не реальные рыночные, за сколько куплены материалы или мол сколько уплачено непосредственно рабочему или субподрядчику, а взятые из сметы, которые один в один соответствуют позициям сметы (являющейся приложением к Договору), которые закрываются данной КСкой.
Т.е. еще раз: в КСках не рыночные, реальные цены, а сметные, которые заложил сметчик перед началом стройки и которые прикреплены к договору. Получив анализ этих цен никакой реальной картины со стройки, или мол “за сколько покупаются материалы” не получить, можно только подумать: “о как мы точно посчитали расценки, т.к. копейка в копейку все по ним закрываются”. Но они это делают, потому что по правилам так - есть смета, приложением к договору, закрываешь объемы по ней, процентуешь, вычерпываешь из общей суммы договора. К реальным стоимостям работ и материалов это не имеет никакого отношения, они совершенно другие.
К тому же, основная прибыль генподрядчика, которому например государство поручило выполнение работ - это разница между расценками, по которым он закрывает работы у заказчика и расценками, по которым он закрывает работы субподрядчику или выплачивает непосредственно работнику. Т.е. для генподрядчика выгодно скрывать стоимости, по которым он расплачивается с субчиками, чтобы заказчик не потребовал у него снижение цены по этим работам, т.к. мол изначально планировалось что генподрядчик работает мол под меньший процент и не экономит на качестве и стоимости материалов.
#ГосТИМ Моё отношение к гос. стандартизации в BIM/ТИМ. Часть 1.
Мне давно надоело читать и комментировать гос. стандарты, потому что все мои комментарии приводят к - “надо всё переделать”, и конечно никто их не слушает, т.к. работа нескольких месяцев, а то и года не может быть выкинута в урну, и признать, что писали стандарты некомпетентные люди - тоже нельзя, т.к. иначе надо уволиться.
Логичный на это ответ: “так возьмись сам и перепиши”. Я уже начал писать свою книгу, но не располагаю достаточным количеством времени, чтобы делать это быстро. Полагаю, что когда опишу все подробно, смогу развернуть и объяснить очень подробно, что имею в виду.
Почему у меня только негативные комментарии к гос. стандартам по BIM?
У меня есть своя BIM-методология (ну как своя, набранная отовсюду от экспертов с кем общаюсь), она комплексная, завершенная, позволяет решать различные задачи - такие как автоматическая проверка качества моделей, сбор объемов работ и связка их с бюджетом, сметой и календарным сетевым графиком. Мне она кажется правильной, я к ней шел больше 7 лет, отрабатывая и шлифуя, взращивая её на практике со всех ролей (проектировщика, застройщика, техзаказчика и генподрядчика), я видел лично работу этой методологии на более чем 30 проектах. Я допускаю что я могу ошибаться, что моя методология может быть неправильной, но, пока она работает и никто не показал что-то лучше, я её развиваю.
Когда я смотрю на отечественные стандарты в области BIM, то я не понимаю их методологию (возможно это проблемы моей компетенции), у меня складывается ощущение, что они не понимают что делают, будто они надергали со всех сторон где что увидели - кривые переводы иностранных стандартов, размышления теоретиков бизнес-методологов, которые не знают возможностей инструментов и не представляют как их гипотезы могут работать на практике, размышления профессиональных айтишников, которые не понимают проблематики САПР и размышляют базами данных, шинами и xml-схемами. Затем они накрывают это всё криво разработанным КСИ - и вуаля, ТИМ-винегрет готов.
У меня создается ощущение, что данные стандарты не несут в себе методологию, что их разработчики не видят картину целостно, не понимают как это будет работать на практике. Поставьте лайк, если у вас такое же ощущение и дизлайк, если вы понимаете, как это должно работать.
upd: Кому интересна подробнее моя методология https://youtu.be/kvV2XsxOZhI
продолжение следует...
Мне давно надоело читать и комментировать гос. стандарты, потому что все мои комментарии приводят к - “надо всё переделать”, и конечно никто их не слушает, т.к. работа нескольких месяцев, а то и года не может быть выкинута в урну, и признать, что писали стандарты некомпетентные люди - тоже нельзя, т.к. иначе надо уволиться.
Логичный на это ответ: “так возьмись сам и перепиши”. Я уже начал писать свою книгу, но не располагаю достаточным количеством времени, чтобы делать это быстро. Полагаю, что когда опишу все подробно, смогу развернуть и объяснить очень подробно, что имею в виду.
Почему у меня только негативные комментарии к гос. стандартам по BIM?
У меня есть своя BIM-методология (ну как своя, набранная отовсюду от экспертов с кем общаюсь), она комплексная, завершенная, позволяет решать различные задачи - такие как автоматическая проверка качества моделей, сбор объемов работ и связка их с бюджетом, сметой и календарным сетевым графиком. Мне она кажется правильной, я к ней шел больше 7 лет, отрабатывая и шлифуя, взращивая её на практике со всех ролей (проектировщика, застройщика, техзаказчика и генподрядчика), я видел лично работу этой методологии на более чем 30 проектах. Я допускаю что я могу ошибаться, что моя методология может быть неправильной, но, пока она работает и никто не показал что-то лучше, я её развиваю.
Когда я смотрю на отечественные стандарты в области BIM, то я не понимаю их методологию (возможно это проблемы моей компетенции), у меня складывается ощущение, что они не понимают что делают, будто они надергали со всех сторон где что увидели - кривые переводы иностранных стандартов, размышления теоретиков бизнес-методологов, которые не знают возможностей инструментов и не представляют как их гипотезы могут работать на практике, размышления профессиональных айтишников, которые не понимают проблематики САПР и размышляют базами данных, шинами и xml-схемами. Затем они накрывают это всё криво разработанным КСИ - и вуаля, ТИМ-винегрет готов.
У меня создается ощущение, что данные стандарты не несут в себе методологию, что их разработчики не видят картину целостно, не понимают как это будет работать на практике. Поставьте лайк, если у вас такое же ощущение и дизлайк, если вы понимаете, как это должно работать.
upd: Кому интересна подробнее моя методология https://youtu.be/kvV2XsxOZhI
продолжение следует...
YouTube
Максимум цифрового строительства 2022 с новым SIGNAL
Современные крупные компании уже используют продукты SIGNAL для цифровизации строительства. Благодаря чему, успешно оптимизируют свои процессы на строительной площадке, используя BIM-модели и цифровые данные. Мы собрали лучшие кейсы из разных проектов и покажем…
#ГосТИМ Моё отношение к гос. стандартизации в BIM/ТИМ. Часть 2.
В то же время с той стороны я слышу критику, мол моя методология работает только на продуктах Autodesk, а Минстрой не может допустить зависимость от одного вендора (особенно который приостановил свою деятельность в настоящее время в РФ).
То, что методология работает только на ADSK - это не так, я разрабатываю методологию под любые системы, просто в настоящее время реальный BIM вокруг меня есть только на продуктах Autodesk, я получаю крайне мало реальных рабочих моделей из ArchiCAD, Allplan, AECOSIM, Tekla, Aveva, Renga и т.д.
Т.е. моделей, которые соответствуют выданной документации, по которым мы можем собрать объемы и тендерить подрядчиков, моделей, которые мы можем использовать для закрытия выполнения. Т.е. я могу показывать свою методологию развернуто в экосистеме Autodesk, к тому же я считаю, что это до недавнего времени было более экономически эффективным и позволяло с меньшими проблемами работать.
Подход через IFC я считаю также рабочим и если бы я был гос. чиновником, и ставил перед собой ограничения, мол нельзя завязываться на одном вендоре, то я бы реализовывал методологию именно на базе него.
Но это приводит к огромному количеству трудностей, реализовать BIM на IFC - это на порядок сложнее чем в методологии ADSK. Т.е. с IFC приходится бороться с такими "детскими" проблемами, которых не возникает с ADSK методологией.
Н-р нестабильная конвертация элементов, когда некоторые просто пропадают, нехватка IFC-классов для описания элементов, отсутствие общих координат, когда можно скоординировать модели начатые в разных системах координат (мол приходится все модели переносить в локальные системы координат - часто с потерей элементов, привязок и оформления) и оформлять на виды в том же положении локального размещения (в повернутом виде, не ортогонально краям листа).
В работе с IFC столько подводных камней и столько ещё дорабатывать, что я бы взял от 3 до 5 лет для доработки инструментов и самого формата IFC, прежде чем показывать те же результаты, что сейчас показываю на проприетарных технологиях RVT+NWD.
Именно поэтому я не топлю за подход с IFC, потому что он будет связывать развитие моей методологии по рукам и ногам, т.е. будет заставлять меня думать не о связке информации между системами, а о том каким инструментом лучше смоделировать элемент, чтобы он правильно передался в IFC, и о том могу ли я использовать функционал Revit для подрезки элементов или задания уклонов (т.к. IFC их не увидит). Или например в ArchiCAD'е как бы часть элементов выгрузить в BREP-геометрии, а другую в Solid (т.к. в одном варианте одни элементы не передадутся в IFC, а в другом другие).
Т.е. использование методологии на продуктах ADSK позволяет мне заниматься меньше техническими вопросами и больше методологическими, т.е. более высокоуровневыми. IFC же меня погружает в технические вопросы и это сдерживает развитие и будто откидывает меня на 10 лет назад. Т.е. то, что ADSK проходил в 10х годах, еще предстоит в подходе с IFC. А мне это не интересно, т.к. я могу использовать продукты Autodesk и двигаться дальше, не занимаясь ретро-технологиями из-за личных идеологических или политических проблем.
В то же время с той стороны я слышу критику, мол моя методология работает только на продуктах Autodesk, а Минстрой не может допустить зависимость от одного вендора (особенно который приостановил свою деятельность в настоящее время в РФ).
То, что методология работает только на ADSK - это не так, я разрабатываю методологию под любые системы, просто в настоящее время реальный BIM вокруг меня есть только на продуктах Autodesk, я получаю крайне мало реальных рабочих моделей из ArchiCAD, Allplan, AECOSIM, Tekla, Aveva, Renga и т.д.
Т.е. моделей, которые соответствуют выданной документации, по которым мы можем собрать объемы и тендерить подрядчиков, моделей, которые мы можем использовать для закрытия выполнения. Т.е. я могу показывать свою методологию развернуто в экосистеме Autodesk, к тому же я считаю, что это до недавнего времени было более экономически эффективным и позволяло с меньшими проблемами работать.
Подход через IFC я считаю также рабочим и если бы я был гос. чиновником, и ставил перед собой ограничения, мол нельзя завязываться на одном вендоре, то я бы реализовывал методологию именно на базе него.
Но это приводит к огромному количеству трудностей, реализовать BIM на IFC - это на порядок сложнее чем в методологии ADSK. Т.е. с IFC приходится бороться с такими "детскими" проблемами, которых не возникает с ADSK методологией.
Н-р нестабильная конвертация элементов, когда некоторые просто пропадают, нехватка IFC-классов для описания элементов, отсутствие общих координат, когда можно скоординировать модели начатые в разных системах координат (мол приходится все модели переносить в локальные системы координат - часто с потерей элементов, привязок и оформления) и оформлять на виды в том же положении локального размещения (в повернутом виде, не ортогонально краям листа).
В работе с IFC столько подводных камней и столько ещё дорабатывать, что я бы взял от 3 до 5 лет для доработки инструментов и самого формата IFC, прежде чем показывать те же результаты, что сейчас показываю на проприетарных технологиях RVT+NWD.
Именно поэтому я не топлю за подход с IFC, потому что он будет связывать развитие моей методологии по рукам и ногам, т.е. будет заставлять меня думать не о связке информации между системами, а о том каким инструментом лучше смоделировать элемент, чтобы он правильно передался в IFC, и о том могу ли я использовать функционал Revit для подрезки элементов или задания уклонов (т.к. IFC их не увидит). Или например в ArchiCAD'е как бы часть элементов выгрузить в BREP-геометрии, а другую в Solid (т.к. в одном варианте одни элементы не передадутся в IFC, а в другом другие).
Т.е. использование методологии на продуктах ADSK позволяет мне заниматься меньше техническими вопросами и больше методологическими, т.е. более высокоуровневыми. IFC же меня погружает в технические вопросы и это сдерживает развитие и будто откидывает меня на 10 лет назад. Т.е. то, что ADSK проходил в 10х годах, еще предстоит в подходе с IFC. А мне это не интересно, т.к. я могу использовать продукты Autodesk и двигаться дальше, не занимаясь ретро-технологиями из-за личных идеологических или политических проблем.
#ГосТИМ Новые требования к ЦИМ от СпбЦГЭ.
(Сам документ см. выше).
При прочтении этого стандарта возникли двоякие впечатления. С одной стороны - это лучшее, что я видел (от Гос.) после требований Московской гос. экспертизы (трехлетней давности). Но с другой, опять отсутствует методология - и есть крупные методологические ошибки.
Т.е. выглядит как существенный рывок после двухлетнего “бла бла” на технических комитетах при Минстрое, но чуть чуть не докрутили. Т.е. моё мнение по данному стандарту, что можно переписать не всё, а только половину. Поэтому разделю своё мнение на 2 части - что понравилось в этих требованиях и что не понравилось.
Часть 1. Что понравилось?
1. Заданы правила наименования файлов, этажей и имена помещений, зон.
Файлы:
0001-20_К1_С0_БМ_П.ifc - Сводная модель
0001-20_К2_С2_ИОС-ОВ_П.ifc - Модель ОВ
Этажи:
Ф1_-10,500 - Фундамент
ПЭ2_-6,000 - Подземный -2 этаж
Э1_+0,000 - 1 этаж
И даже предусмотрены некоторые частные случаи, которые прежде вводили в ступор (н-р междуэтажное пространство - МП4/5_+12.300)
2. По этажам даже дана схема какие как определять (прежде её не видел).
3. Настроена связка требуемых классов с IFC-классами.
Стена - IfcWall
Несущая стена - IfcWall.SOLIDWALL
Перегородка - IfcWall.PARTITIONING
Подпорная стенка - IfcWall.SHEAR
Плиты перекрытий - IfcSlab
Междуэтажное перекрытие - IfcSlab.FLOOR
4. Определены параметры и форматы значений, которые требуется заполнять в какие классы.
Что особенно примечательно, что для некоторых параметров даже задана стандартизация значений, что может позволить в будущем их использовать для автоматического дополнительного уточнения подклассов. Например: IfcWall с параметром Материал = "ЖБ" и Несущий элемент = "1" - это Несущая железобетонная стена.
5. Есть таблицы какие классы должны содержать какие параметры.
Т.е. например элемент Стена (IfcWall) должен содержать следующие параметры:
Номер корпуса, Номер секции, Этаж, Позиция, Обозначение, Наименование, Толщина, Длина, Высота, Объем, Предел огнестойкости, Тип противопожарной преграды, Класс пожарной опасности, Тип огнезащиты, Материал, Несущий элемент, Наружная, Защитный слой рабочей арматуры, Защитный слой хомутов, Диаметр арматуры, Класс арматуры, Расход арматуры.
6. Приведена матрица коллизий и определена приоритетность коллизий, которая позволит устранять их поэтапно от более важных к менее. На практике это очень полезный подход, т.к. в жизни идеальных моделей без коллизий не бывает, т.к. каждая правка в модели приводит к новым коллизиям (а правки постоянны и их много) и устранять их надо по мере важности. Т.к. если устранять просто по порядку, то обойдя например везде гибкой трубой лоток СС, вам все равно придется все это двигать при изменении положения воздуховода, который пересекал трубу канализации, которые дороже, а иногда и невозможно гнуть.
7. Для элементов ИОС указано какие элементы в каких системах надо моделировать, причем в формате 5 вариантов: Обязательные к моделированию, Если хотите, При наличии в системе, При возможности ПО, Не моделируется. Т.е. дана некоторая гибкость, которая для начала отработки подходов очень кстати.
8. В некоторых местах предложен подход к упрощению моделирования, например Водомерный узел мол чтобы не из всех деталей мог состоять: фитингов, задвижек и приборов, а как Габаритный элемент, форма в общих габаритах (условно параллелепипед) названная как Водомерный узел и содержащая необходимые данные.
9. Порадовало что не ссылаются на мертворожденный нерабочий КСИ.
В общем описанный подход - выглядит рабоче и есть полезные моменты, которые отображают практику. Подход через связку с классами IFC тоже радует и особенно с определением необходимых параметров.
Могу рекомендовать как документ, которым можно заменить бездарную новую версию СП333 и теоретический трактат о жизни на земле - ЕСИМ. А разработчиков этих требований привлек бы для корректировки текущих определений в области ТИМ и переработке КСИ, т.к. видно что они понимают о чем пишут (и видимо прислушиваются к мнению экспертов).
(Сам документ см. выше).
При прочтении этого стандарта возникли двоякие впечатления. С одной стороны - это лучшее, что я видел (от Гос.) после требований Московской гос. экспертизы (трехлетней давности). Но с другой, опять отсутствует методология - и есть крупные методологические ошибки.
Т.е. выглядит как существенный рывок после двухлетнего “бла бла” на технических комитетах при Минстрое, но чуть чуть не докрутили. Т.е. моё мнение по данному стандарту, что можно переписать не всё, а только половину. Поэтому разделю своё мнение на 2 части - что понравилось в этих требованиях и что не понравилось.
Часть 1. Что понравилось?
1. Заданы правила наименования файлов, этажей и имена помещений, зон.
Файлы:
0001-20_К1_С0_БМ_П.ifc - Сводная модель
0001-20_К2_С2_ИОС-ОВ_П.ifc - Модель ОВ
Этажи:
Ф1_-10,500 - Фундамент
ПЭ2_-6,000 - Подземный -2 этаж
Э1_+0,000 - 1 этаж
И даже предусмотрены некоторые частные случаи, которые прежде вводили в ступор (н-р междуэтажное пространство - МП4/5_+12.300)
2. По этажам даже дана схема какие как определять (прежде её не видел).
3. Настроена связка требуемых классов с IFC-классами.
Стена - IfcWall
Несущая стена - IfcWall.SOLIDWALL
Перегородка - IfcWall.PARTITIONING
Подпорная стенка - IfcWall.SHEAR
Плиты перекрытий - IfcSlab
Междуэтажное перекрытие - IfcSlab.FLOOR
4. Определены параметры и форматы значений, которые требуется заполнять в какие классы.
Что особенно примечательно, что для некоторых параметров даже задана стандартизация значений, что может позволить в будущем их использовать для автоматического дополнительного уточнения подклассов. Например: IfcWall с параметром Материал = "ЖБ" и Несущий элемент = "1" - это Несущая железобетонная стена.
5. Есть таблицы какие классы должны содержать какие параметры.
Т.е. например элемент Стена (IfcWall) должен содержать следующие параметры:
Номер корпуса, Номер секции, Этаж, Позиция, Обозначение, Наименование, Толщина, Длина, Высота, Объем, Предел огнестойкости, Тип противопожарной преграды, Класс пожарной опасности, Тип огнезащиты, Материал, Несущий элемент, Наружная, Защитный слой рабочей арматуры, Защитный слой хомутов, Диаметр арматуры, Класс арматуры, Расход арматуры.
6. Приведена матрица коллизий и определена приоритетность коллизий, которая позволит устранять их поэтапно от более важных к менее. На практике это очень полезный подход, т.к. в жизни идеальных моделей без коллизий не бывает, т.к. каждая правка в модели приводит к новым коллизиям (а правки постоянны и их много) и устранять их надо по мере важности. Т.к. если устранять просто по порядку, то обойдя например везде гибкой трубой лоток СС, вам все равно придется все это двигать при изменении положения воздуховода, который пересекал трубу канализации, которые дороже, а иногда и невозможно гнуть.
7. Для элементов ИОС указано какие элементы в каких системах надо моделировать, причем в формате 5 вариантов: Обязательные к моделированию, Если хотите, При наличии в системе, При возможности ПО, Не моделируется. Т.е. дана некоторая гибкость, которая для начала отработки подходов очень кстати.
8. В некоторых местах предложен подход к упрощению моделирования, например Водомерный узел мол чтобы не из всех деталей мог состоять: фитингов, задвижек и приборов, а как Габаритный элемент, форма в общих габаритах (условно параллелепипед) названная как Водомерный узел и содержащая необходимые данные.
9. Порадовало что не ссылаются на мертворожденный нерабочий КСИ.
В общем описанный подход - выглядит рабоче и есть полезные моменты, которые отображают практику. Подход через связку с классами IFC тоже радует и особенно с определением необходимых параметров.
Могу рекомендовать как документ, которым можно заменить бездарную новую версию СП333 и теоретический трактат о жизни на земле - ЕСИМ. А разработчиков этих требований привлек бы для корректировки текущих определений в области ТИМ и переработке КСИ, т.к. видно что они понимают о чем пишут (и видимо прислушиваются к мнению экспертов).
#ГосТИМ Новые требования к ЦИМ от СпбЦГЭ.
Часть 2. Что не понравилось?
1. Есть некоторая методологическая проблема в таблицах “Основные элементы ЦИМ. Соответствие элементов классам IFC”
В этих таблицах есть столбцы “Элемент ЦИМ” и “Класс IFC. Подтип IFC”. Например они содержат “Подпорная стенка” и “IfcWall.SHEAR” соответственно. Далее описано что куда попадает и в какой таблице смотреть требуемые атрибуты. Причем атрибуты указаны только для верхнеуровневого Элемента ЦИМ (далее ЭЦИМ) - “Стены” т.е. Класса “IfcWall”.
На первый взгляд может показаться, что ЭЦИМ - это переводы Классов IFC, а Подтипы ЭЦИМ - это Подтипы Классов IFC. Но затем мы сталкиваемся с тем, что абсолютно разные ЭЦИМ закидываются в один Класс - как например “Малые архитектурные формы”, “Бортовой камень”, “Путь прохода” и “Вентблок” - в IfcBuildingElementProxy, “Помещения” и “Пространство шахты” - это IfcSpace, Импост Витража с кучей других элементов - в IfcMember и т.д. Т.е. ЭЦИМ соответствуют Классам IFC ни как один к одному, а как многие к одному. Также иногда ЭЦИМ могут содержать внутри себя кучу других классов (как например Витраж может содержать в себе IfcMember, IfcPlate, IfcWindow и IfcDoor - предъявляются ли тогда требования к этим классам в случаях, когда они являются вложенными элементами?).
Это все приводит к тому, что мы не можем использовать классы IFC ни для проверки наличия параметров или пересечений, ни для сбора объемов или генерации смет, ни для маппинга с календарным графиком. Значит нам надо опираться только на ЭЦИМ - но в таком случае нам надо иметь определитель в модели какой IfcBuildingElementProxy обозначает в модели Бортовой камень, а какой Вентблок, т.е. дополнительный признак по которому отделять одно от другого. В то же время использовать текущие имена ЭЦИМ, как значения в параметрах элементов мы тоже не можем, т.к. они названы скорее как описание, но ни как код (н-р: “Круговой пролет пандуса / рампы”), иногда даже применяется перенос на следующую строку.
В такой ситуации можно кодировать все ЭЦИМ и потребовать у проектировщика указывать значение например для Revit в “Код по классификатору”. Порядковую нумерацию внутри таблиц мы тоже использовать не можем, т.к. она повторяется в каждой из них. Т.е. такое себе решение.
продолжение следует...
Часть 2. Что не понравилось?
1. Есть некоторая методологическая проблема в таблицах “Основные элементы ЦИМ. Соответствие элементов классам IFC”
В этих таблицах есть столбцы “Элемент ЦИМ” и “Класс IFC. Подтип IFC”. Например они содержат “Подпорная стенка” и “IfcWall.SHEAR” соответственно. Далее описано что куда попадает и в какой таблице смотреть требуемые атрибуты. Причем атрибуты указаны только для верхнеуровневого Элемента ЦИМ (далее ЭЦИМ) - “Стены” т.е. Класса “IfcWall”.
На первый взгляд может показаться, что ЭЦИМ - это переводы Классов IFC, а Подтипы ЭЦИМ - это Подтипы Классов IFC. Но затем мы сталкиваемся с тем, что абсолютно разные ЭЦИМ закидываются в один Класс - как например “Малые архитектурные формы”, “Бортовой камень”, “Путь прохода” и “Вентблок” - в IfcBuildingElementProxy, “Помещения” и “Пространство шахты” - это IfcSpace, Импост Витража с кучей других элементов - в IfcMember и т.д. Т.е. ЭЦИМ соответствуют Классам IFC ни как один к одному, а как многие к одному. Также иногда ЭЦИМ могут содержать внутри себя кучу других классов (как например Витраж может содержать в себе IfcMember, IfcPlate, IfcWindow и IfcDoor - предъявляются ли тогда требования к этим классам в случаях, когда они являются вложенными элементами?).
Это все приводит к тому, что мы не можем использовать классы IFC ни для проверки наличия параметров или пересечений, ни для сбора объемов или генерации смет, ни для маппинга с календарным графиком. Значит нам надо опираться только на ЭЦИМ - но в таком случае нам надо иметь определитель в модели какой IfcBuildingElementProxy обозначает в модели Бортовой камень, а какой Вентблок, т.е. дополнительный признак по которому отделять одно от другого. В то же время использовать текущие имена ЭЦИМ, как значения в параметрах элементов мы тоже не можем, т.к. они названы скорее как описание, но ни как код (н-р: “Круговой пролет пандуса / рампы”), иногда даже применяется перенос на следующую строку.
В такой ситуации можно кодировать все ЭЦИМ и потребовать у проектировщика указывать значение например для Revit в “Код по классификатору”. Порядковую нумерацию внутри таблиц мы тоже использовать не можем, т.к. она повторяется в каждой из них. Т.е. такое себе решение.
продолжение следует...
#ГосТИМ Новые требования к ЦИМ от СпбЦГЭ.
Часть 3. Что не понравилось?
2. У инженерных сетей требования к параметрам предъявлены не по элементам мол к Трубам, Фитингам, Оборудованию, Оконечным приборам, Проводам, а разом на всю систему. Из-за этого мы например не можем указать требуемые Геометрические характеристики трубам или как называть Высоту и Ширину сечения Воздуховода и толщину его стенки и изоляции, а также радиус Отвода или Коэффициент потерь на Тройнике. Т.е. по инженерным сетям явно разработчики схалявили (не так подробно разложили как по АР и КР).
3. Матрица коллизий никак не связана с ЭЦИМ (или IFC Классами) из таблиц соответствия и требуемых параметров. Не хватает единой системы классификации сущностей - за её основу можно взять либо IFC-классы, либо ЭЦИМ.
4. В матрице коллизий не используется деление труб и воздуховодов по размеру на магистральные и разводку, что важно для определения критичности коллизий. Т.к. в первую очередь надо проверять например трубы диаметром свыше 50, а затем уже трубы разводки, если потребуется.
5. У коллизий не заданы допуски на сколько миллиметров один элемент может входить в другой. Все таки модели не идеальны и дверь всегда на пару миллиметров входит внутрь стены и сами стены в местах стыков создают зачастую коллизии (особенно при выгрузке в IFC).
Еще из пожеланий - было бы очень здорово получать таблицы соответствия и требуемых параметров в формате XLSX, чтобы не растаскивать по ячейкам после копирования из PDF. Все таки мы хотим заниматься автоматизацией и использовать структурированные данные.
Моё предложение по доработке: Взять за основу IFC классы, дорасшить их самостоятельно до ЭЦИМ, перепроверив нет ли в стандартном IFC того что требуется. Вложенные элементы называть как Подтипы основного в который вложены (пусть и немного дублируя сущности). В матрице коллизий создать сущности типа Трубы>50 и получать их в системах проверки через ключ Class+Parameter (т.е. IfcClass = IfcPipeSegment И Размер > 50), предварительно автоматически проверив заполненность классов и параметров, требуемых для них.
Готов организовать подкаст и обсудить с разработчиками и участниками канала, кто что думает по этому документу и моим комментариям.
Часть 3. Что не понравилось?
2. У инженерных сетей требования к параметрам предъявлены не по элементам мол к Трубам, Фитингам, Оборудованию, Оконечным приборам, Проводам, а разом на всю систему. Из-за этого мы например не можем указать требуемые Геометрические характеристики трубам или как называть Высоту и Ширину сечения Воздуховода и толщину его стенки и изоляции, а также радиус Отвода или Коэффициент потерь на Тройнике. Т.е. по инженерным сетям явно разработчики схалявили (не так подробно разложили как по АР и КР).
3. Матрица коллизий никак не связана с ЭЦИМ (или IFC Классами) из таблиц соответствия и требуемых параметров. Не хватает единой системы классификации сущностей - за её основу можно взять либо IFC-классы, либо ЭЦИМ.
4. В матрице коллизий не используется деление труб и воздуховодов по размеру на магистральные и разводку, что важно для определения критичности коллизий. Т.к. в первую очередь надо проверять например трубы диаметром свыше 50, а затем уже трубы разводки, если потребуется.
5. У коллизий не заданы допуски на сколько миллиметров один элемент может входить в другой. Все таки модели не идеальны и дверь всегда на пару миллиметров входит внутрь стены и сами стены в местах стыков создают зачастую коллизии (особенно при выгрузке в IFC).
Еще из пожеланий - было бы очень здорово получать таблицы соответствия и требуемых параметров в формате XLSX, чтобы не растаскивать по ячейкам после копирования из PDF. Все таки мы хотим заниматься автоматизацией и использовать структурированные данные.
Моё предложение по доработке: Взять за основу IFC классы, дорасшить их самостоятельно до ЭЦИМ, перепроверив нет ли в стандартном IFC того что требуется. Вложенные элементы называть как Подтипы основного в который вложены (пусть и немного дублируя сущности). В матрице коллизий создать сущности типа Трубы>50 и получать их в системах проверки через ключ Class+Parameter (т.е. IfcClass = IfcPipeSegment И Размер > 50), предварительно автоматически проверив заполненность классов и параметров, требуемых для них.
Готов организовать подкаст и обсудить с разработчиками и участниками канала, кто что думает по этому документу и моим комментариям.
Большое зарплатное исследование продолжается
Данных пока мало, но мы готовы поделиться промежуточными результатами:
https://docs.google.com/spreadsheets/d/1piplme7DSftw-KTJ_mRHs84odBKSM5kWKH1bmjYlffo/edit#gid=1093665353
Скоро добавим:
- матрицу компетенций (какая должность какие задачи подразумевает)
- какая при этом зп
- уровень зп в зависимости от размеров компании
- уровень зп в зависимости от опыта
- влияние количества подчинённых на уровень зп
- самые крутые плюшки от компании
- что влияет на лояльность сотрудников
- влияние уровня ЗП на отношение сотрудника к компании
Предложить свою метрику или указать на ошибки вы можете комментарием в документе
Чтобы данные были объективными, нам нужно Больше ваших ответов, так что продолжайте делится анкетой для заполнения:
https://forms.gle/DvPsvXnSTYQvmXHEA
Данных пока мало, но мы готовы поделиться промежуточными результатами:
https://docs.google.com/spreadsheets/d/1piplme7DSftw-KTJ_mRHs84odBKSM5kWKH1bmjYlffo/edit#gid=1093665353
Скоро добавим:
- матрицу компетенций (какая должность какие задачи подразумевает)
- какая при этом зп
- уровень зп в зависимости от размеров компании
- уровень зп в зависимости от опыта
- влияние количества подчинённых на уровень зп
- самые крутые плюшки от компании
- что влияет на лояльность сотрудников
- влияние уровня ЗП на отношение сотрудника к компании
Предложить свою метрику или указать на ошибки вы можете комментарием в документе
Чтобы данные были объективными, нам нужно Больше ваших ответов, так что продолжайте делится анкетой для заполнения:
https://forms.gle/DvPsvXnSTYQvmXHEA
#Теория Как и зачем переходить на BIM?
Ещё один пост о том как можно перевести на BIM-технологии строительную отрасль (в рамках всей страны, или одной компании - неважно). Или не на BIM, а просто улучшить то, что в ней происходит.
Если кратко:
- собрать перечень проблем в отрасли от максимального количества причастных (опрос из открытых вопросов, затем обработка ответов с объединением одинаковых)
- методом голосования построить проблемы в списке от самой важной к неважным
- с каждой проблемой сопоставить какой-либо BIM-use, если таковой для этой проблемы найдётся
- выбрать пилотные проблемы, выбрать пилотные проекты, где будут пробовать их решать, в команду пилотных проектов включить сотрудников кто будет в курсе происходящего и по итогам создаст внятные отчёты, а возможно и проекты стандартов по решению конкретных проблем
- далее, по итогам пилотов, писать стандарты и рекомендовать их применение: Минстрою – в госзаказе, частным компаниям – у себя внутри, если дело происходит на уровне компании, параллельно делая новые пилоты для решения новых задач из списка. Не везде решением проблемы будет BIM, но какая разница какую технологию будут использовать на пилоте, лишь бы она приносила результат.
Будучи единожды запущенным, этот процесс должен привести к постоянному улучшению качества работы в конкретной компании, или во всей отрасли в части госзаказа, если речь про Минстрой. Опросы, например, можно сделать ежегодными, и по их результатам оценивать проникновение новых технологий, пропадают ли «самые важные» проблемы с верхних позиций по по популярности, соответственно если не пропадают – реагировать, узнавать почему не пропадают, а если пропадают – переходить к решению следующих по важности, тех которые в этом году окажутся в верхней части списка.
Более подробно этот подход, как и почему он должен работать, описан в статье (7 минут на прочтение):
https://roseco.net/about/articles/kak-i-zachem-nam-perexodit-na-bim
Ещё один пост о том как можно перевести на BIM-технологии строительную отрасль (в рамках всей страны, или одной компании - неважно). Или не на BIM, а просто улучшить то, что в ней происходит.
Если кратко:
- собрать перечень проблем в отрасли от максимального количества причастных (опрос из открытых вопросов, затем обработка ответов с объединением одинаковых)
- методом голосования построить проблемы в списке от самой важной к неважным
- с каждой проблемой сопоставить какой-либо BIM-use, если таковой для этой проблемы найдётся
- выбрать пилотные проблемы, выбрать пилотные проекты, где будут пробовать их решать, в команду пилотных проектов включить сотрудников кто будет в курсе происходящего и по итогам создаст внятные отчёты, а возможно и проекты стандартов по решению конкретных проблем
- далее, по итогам пилотов, писать стандарты и рекомендовать их применение: Минстрою – в госзаказе, частным компаниям – у себя внутри, если дело происходит на уровне компании, параллельно делая новые пилоты для решения новых задач из списка. Не везде решением проблемы будет BIM, но какая разница какую технологию будут использовать на пилоте, лишь бы она приносила результат.
Будучи единожды запущенным, этот процесс должен привести к постоянному улучшению качества работы в конкретной компании, или во всей отрасли в части госзаказа, если речь про Минстрой. Опросы, например, можно сделать ежегодными, и по их результатам оценивать проникновение новых технологий, пропадают ли «самые важные» проблемы с верхних позиций по по популярности, соответственно если не пропадают – реагировать, узнавать почему не пропадают, а если пропадают – переходить к решению следующих по важности, тех которые в этом году окажутся в верхней части списка.
Более подробно этот подход, как и почему он должен работать, описан в статье (7 минут на прочтение):
https://roseco.net/about/articles/kak-i-zachem-nam-perexodit-na-bim