Когда #Autodesk возобновит деятельность в России?

Официальные лица Autodesk, их офис в Мск и партнеры (кто продают) публично не высказываются о ситуации с лицензиями. Кроме заявления 3 марта на офф сайте про приостановку деятельности в связи с событиями в Украине мы так ничего и не увидели.
https://adsknews.autodesk.com/views/crisis-in-ukraine
Но я не представитель ADSK и могу высказать свое мнение.

Напомню: В связи с событиями в Украине Autodesk приостановил продажи и продления своих продуктов на территории РФ. Т.е. сейчас не купить и не продлить лицензии AutoCAD, Revit, 3Ds Max, BIM360 и прочие.

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

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

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

В общем, если это санкции на весь рынок, то Autodesk вернется в Россию если:

1. Закончится война в Украине
2. Сменится режим Путина (или будут другие гарантии что это не повторится вновь)
3. Виновные понесут наказание и все компенсации за причененный ущерб будут выплачены.

если это что-то другое, пусть скажут. Отсутствие информации вынуждает додумывать.

Ниже репостну опрос по настрою пользователей Revit переходить на отечественный софт.

#Autodesk Интересную статистику получилось собрать, спасибо всем кто проголосовал.

https://t.iss.one/prostobim/699

С учетом исключения процентов «Посмотреть» проголосовала 1000 пользователей. Из них за то что остаются на Revit - 70%

Есть мнение, что это потому что опрос кинут в чат где в основном ревитчики. Ну во-первых целью опроса и есть узнать сколько из ревитчиков собираются переходить, а во-вторых если кто-то считает, что где-то в чате есть например уже перешедшие на ренгу ревитчики, то репостните туда опрос, пусть добавят объективности результату.

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

#Autodesk Второй опрос по Среде Общих Данных показал, что проголосовало более 500 человек (за вычетом голосов «Посмотреть»).

https://t.iss.one/prostobim/700

45% используют для СОД BIM360Docs / Autodesk Docs.

15% используют PilotICE / PilotBIM

24% выбрало выриант «Другое». В комментариях написали что в CadLib, BIM Tangle, BIMeister, Assistant Build, Неосинтез и прочее.

В следующем посте опишу почему я такие системы не считаю СОДом, а скорее системами по работе со сводными моделями по типу Navisworks. И по таким системам тоже запущу опрос.

Так же считаю что кто-то под Другим подразумевает файловый сервер, яндекс облако, ревит сервер, некст клауд и подобные, что я тоже считаю не полноценными СОДами. Тоже объясню подробнее в след. постах.

p.s. Пока понял что из СОД забыл Revizto. Предложите в комментарии еще чтото, что пропустил.

#Теория Функционал Среды Общих Данных (CDE)

Необходимый

1. Файлообменник с возможностью создания структур папок
2. Версионирование файлов
3. Атрибуты у файлов и поиск, сортировка по ним
4. Просмотр файлов типа Acrobat Reader’a. Для BIM систем как минимум просмотр формата IFC (в идеале NWD, RVT, DWG, DGN, PLN)
5. Выдача замечаний к файлам и внутри них, с единым реестром на проект
6. Согласование файлов с настройкой маршрутов, согласующих, выдачей замечаний, с изменением статусов файлов
7. Web, мобильная и десктопная версии системы
8. Дашборд с основными показателями по проекту
9. Администрирование. Гибко настраиваемый доступ по ролям, проектам, кому что видно, что может редактировать.

Желательный

10. Простановка ЭЦП И QR-кодов на PDF файлы
11. Сравнение содержимого файлов
12. API доступ для написания и подключения своих приложений к системе
13. Папки поиска. Создание дополнительных структур папок на основе атрибутов файлов
14. Возможность хранить файлы на своих серверах или выполнять их резервное копирование на них.

Дополнительный (выходящий за пределы СОДа. Расширенный)

15. Подсчет объемов по модели и пометкам, зонам, измерениям на 2D чертежах
16. Подгрузка и просмотр облаков точек, совмещенных с моделью по геодезическим координатам
17. Связь элементов модели с календарным сетевым графиком
18. Проверка на коллизии сводных моделей
19. Отображение фото360 с привязкой на планах и сравнением на разные даты, выдачей замечаний и простановкой пометок
20. Указание выполненных работ в привязке с элементами модели.

Предыдущие посты по этой теме
https://t.iss.one/prostobim/20
https://t.iss.one/prostobim/259
https://t.iss.one/prostobim/262
https://t.iss.one/prostobim/263
https://t.iss.one/prostobim/267
https://t.iss.one/prostobim/268

#СтроительныеРассказы Реновация

17 августа. Совет директоров крупной строительной фирмы.

ГД: «Мы не будем участвовать в этой программе, она нас обанкротит, невозможно построить за 28 тысяч рублей за квадратный метр какое либо жилье! Мы же не дебилы работать себе в убыток!»

18 августа. Новость на новостном портале:
«В офисе крупное строительной фирмы прошли обыски, наши источники сообщают, что это может быть связано с уходом от уплаты налогов…»

19 августа. Кабинет руководителя экономического отдела.

ГД: «Людочка, попробуй еще электрику на Китайскую поменять, может хотябы на 32 тысячи выйдем?»

—- Все события и персонажи вымышленные, любое совпадение с реальностью - случайно.

#Опрос Вадима Муратова @revitblog на тему влияния санкций и импортозамещения

Требуется всем инженерам, проектировщикам и BIM-координаторам пройти для передачи циферок на стол сами знаете кому
https://docs.google.com/forms/d/1hX_oAhtuYIQSqH7Emoq20XwC1DzNoBY0UBTRA5OoqNY/edit?usp=sharing

У меня заняло 1 минуту.

#СтроительныеРассказы Тендер

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

В 4 конверте оказалась заполненная заявка, но с пустым полем предложенной суммы.

Семён посметрел на суммы в трех других заявках: 3,4 млн. р, 3,99 млн.р и 3,2 млн. р.,.

Семён объявил: «Четвертая заявка компании… предложена сумма - 3 миллиона 100 тысяч рублей… Победителем конкурса на работы объявляю четвертого претендента, который дал самую низкую цену»

вписал в четвертую заявку 3,1 млн. р., свои ФИО и подписал.

—- Все события и персонажи вымышленные, любое совпадение с реальностью - случайно.

#Autodesk BIM 360 Docs на днях поймал баг. Судя по опросу пока еще многие в нем работают и дам рекомендацию по обходу этого бага.

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

Итак, решение:

Надо открыть забагованный файл, вручную пролистать листы и найти какое-нибудь замечание, установленное на листе (точку), запомнить лист (чтобы другим коллегам сказать, чтобы они его вручную не искали) и нажать на эту точку. Откроется Issue, нажимаете назад к списку замечаний и все работает как и прежде.

Да, данное действие с забагованным файлом надо проделать из под каждого юзера, кто этот файл в принципе смотрит, поэтому проще просто переслать коллегам эту инструкцию, чтобы понимали, что если реестр замечаний в документе не работает, то надо НАЙТИ ВРУЧНУЮ ТОЧКУ ЗАМЕЧАНИЯ В ЭТОМ ДОКУМЕНТЕ И ОТКРЫТЬ

#ГосТИМ Описание атрибутивного состава ЦИМ
https://minstroyrf.gov.ru/docs/183386/

Под таким заголовком опубликованы XSD-схемы будущей ТИМ-модели

Я глянул, атрибутивного состава не увидел. В основном добавлены таблицы атрибутов с возможными характеристиками самих будущих атрибутов (которыми эти таблицы надо будет наполнить). Среди этих характеристик у каждого атрибута добавлен "Код по КСИ", остальные стандартные IFC-шные.

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

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

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

А ну и ещё IfcBoreHole класс добавили - буровую скважину, видимо без него никуда (как еще уличные туалеты классифицировать?). Правда в новой версии IFC 4.3 (который сейчас в разработке у международного buildingsmart) IfcBorehole тоже добавили и у нас тут уже пошло разночтение в том большая или маленькая буква h. Как обычно, сделали единственную мелкую правку и не смогли не налажать.

#Классификатор Классификаторы и их маппинг. Часть 1.

По классификаторам базовые вещи описаны здесь:
https://t.iss.one/prostobim/571
https://t.iss.one/prostobim/572
https://t.iss.one/prostobim/573
https://t.iss.one/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й, а следующие уровни доуточняют уже другие специалисты.

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

продолжение следует...

#Классификатор Классификаторы и их маппинг. Часть 2.

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

Т.е. если для Стены и Пилона это будут одинаковые параметры, то не требуется их делить на 2 класса, но если Колонна - это элемент у которого геометрические характеристики задаются не параметрами Толщина и Длина, а параметрами Ширина и Высота (сечения), то это уже другой Класс.

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

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

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

продолжение следует...

#Классификатор Классификаторы и их маппинг. Часть 3.

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

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

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

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

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

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

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

продолжение следует...

#Классификатор Классификаторы и их маппинг. Часть 4.

В тоже время я не могу утверждать, что сервисы для настройки таблиц маппинга менее удобные, чем Google-таблицы. Наверное с развитием они будут лучше, удобнее, у них есть для этого все предпосылки. Они могут отображать данные не в двухмерном виде, а в многомерном, что позволит сократить количество таблиц (но усложнит их понимание). Правда приведет к проблеме зависимости от определенного сервиса (т.к. вне его не будет работать, а когда правила маппинга хранятся в Excel, то всегда можно это применить и в других системах).

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

Такой участник должен быть сообществом компаний, некоммерческой организацией, который обладает достаточными компетенциями для подобной разработки (не ФАУ ФЦС и его подрядчики, и не БИМ-ассоциация). Все классификаторы и таблицы проверок и маппингов должны выкладываться на открытые ресурсы, чтобы все желающие могли изучить, перепроверить и убедиться в корректности методологии расчета.

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

Таким образом девелоперам для реализации этой методологии (которая существенно автоматизирует его деятельность и упростит работу) будет достаточно прописать в требования к проектировщику задачу выполнить условия данной методологии, т.е. заполнить определенные коды классификатора и требуемые параметры. К тому же у проектировщика будет однозначное понимание, что он на 100% выполнил все требования (т.к. автоматизированно проверил модель) и что девелопер не прибежит в конце контракта с требованиями смоделировать ещё то-то и то-то и заполнить такие-то и такие-то атрибуты.

#ГосТИМ BIM не замесТИМ?

на прошлой неделе на ancb вышла статья по итогам конференции «ЦифраГрад-2022»
https://ancb.ru/publication/read/13122

Считаю нужным ответить Михаилу Викторову и Константину Михайлику на некоторые их политизированные бравурные заблуждения.

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

Комментарий: Как и остальные дела у нас в стране: "замах на рубль - удар на копейку", но зато научились оправдываться мол "просто надо аккуратно, без лишних жертв". Планировали внедрить BIM и разработать единую градостроительную систему - добавили русские атрибуты в IFC.

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

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

Михайлик: все, что они делали […] ограничивалось тем, что исторически был сделан упор на адаптацию зарубежных продуктов

Комментарий: потому что зарубежные работают, а отечественные пробуют работать, делаются либо десятком реальных программистов (Renga), либо на иностранных библиотеках ODA (NanoCAD) и SharePoint (VitroCAD)

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

Комментарий: это является вашей самой важной политической задачей поставленной вам сверху вашим руководством. Ни задачей разработчиков, ни их клиентов, а ВАШЕЙ. Поэтому не перекладывайте с больной головы на здоровую, можете например свою зарплату задонатить в ренгу или нанокад - больше пользы будет. Хотя можете и отжать у Аскона Ренгу, национализировать, стать ее директорами и ставить задачи программистам, а потом отжать ПИК и ставить задачи всем сотрудникам работать в ренге (сквозь боль и слезы).

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

Комментарий: То что вы сейчас называете «честной информацией» - это еще не она - честная потянет на 33 млрд рублей. Но честную вы и тогда и сейчас знаете, просто решили отмазаться, мол это там внизу нас обманывали, чтобы скинуть с себя ответственность, переложить на следующие уровни (им будет очень приятно дальше с вами работать и исполнять ваши указания).

Михайлик: Самое главное – выстроить диалог. Это очень тяжело. Очень тяжело поверить друг другу, начать инвестировать в это время, силы и средства.

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

И в конце два вопроса, которые следует задавать чиновникам после подобных выступлений: А на автомобиле какой марки Вы сюда приехали? и Какая модель вашего смартфона?

#послевас

#Подкасты Вышел подкаст с Александром Волковым у Игоря Рогачева. Дальше напишу пару своих комментариев на поднятые темы.
https://youtu.be/s2EKrt0q4EI

Александр Волоков: Уход западных разработчиков программного обеспечения создаст положительную динамику роста доходов Российских разработчиков. И рост доходов должен незамедлительно сказаться на качестве самих программных продуктов. Они должны начать гораздо быстрее эволюционировать.

Комментарий:
При уходе с рынка Autodesk будет происходить двунаправленное движение в покупке софта. С одной стороны кто-то перейдет на отечественное, с другой - кто-то перейдет на пиратское (бесплатное) и в принципе не будет рассматривать отечественное.

Тем компаниям, кто находится в технологиях 2010го года, достаточно удобно перейти на отечественное. Те же, кто находятся на технологическом развитии 2020го года, выберут пиратское, т.к. отечественное пока не может обеспечить работоспособность технологии на данном уровне.

В то же время, государство может начать массовую борьбу с пиратством (но ситуация в стране такова, что не до этого, т.к. борьба превратится в “кошмарить бизнес” и обнаружится, что даже отечественное работает на пиратских Windows).

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

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

#Подкасты Подкаст с Александром Волковым у Рогачева. Часть 2

Продолжу некоторые комментарии к подкасту Александра Волкова, много пищи дано для размышлений и обсуждений.

Про околополитические размышления в подкасте о выгодном сотрудничестве с Китаем. Я поработал с Китайцами на 3х крупных проектах, с разными их девелоперами. На всех трех они кинули. Работать с Китайцами невозможно, они выжимают всё из вас в свою пользу, без штанов оставляют.

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

Думаю с Китаем получится также как с Северным потоком 2, мы сейчас вложим последние деньги в расширения этих магистралей, жд путей, перерабатывающих заводов, а те потом: “а дайте нам скидку в два раза больше”, или и вовсе откажутся, т.к. присоединятся к санкциям, чтобы продолжать работать с миром (из-за каких-нибудь условий 8го или 9го пакета).

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

#Подкасты Подкаст с Александром Волковым у Рогачева. Часть 3

Александр Волоков: Если ввести правило, что например с 1 января вся стройка обменивается [электронными] формами КС-2 КС-3, ты с опозданием на сутки будешь видеть все цены и все товары в стране.

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

КС-2 КС-3 - это документы, которые являются основанием для оплаты, т.е. которые подтверждают, что работы по смете выполнены на определенный объем и стоимость. Эти документы имеют табличную форму, в которой набраны позиции из сметы, которая в наших реалиях составлена либо по гос. расценкам, либо по корпоративным.

В эти таблицы непосредственно с площадки попадают только объемы, т.е. количество сколько выполнено работ за указанный период. Расценки вносятся не реальные рыночные, за сколько куплены материалы или мол сколько уплачено непосредственно рабочему или субподрядчику, а взятые из сметы, которые один в один соответствуют позициям сметы (являющейся приложением к Договору), которые закрываются данной КСкой.

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

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

#ГосТИМ Моё отношение к гос. стандартизации в BIM/ТИМ. Часть 1.

Мне давно надоело читать и комментировать гос. стандарты, потому что все мои комментарии приводят к - “надо всё переделать”, и конечно никто их не слушает, т.к. работа нескольких месяцев, а то и года не может быть выкинута в урну, и признать, что писали стандарты некомпетентные люди - тоже нельзя, т.к. иначе надо уволиться.

Логичный на это ответ: “так возьмись сам и перепиши”. Я уже начал писать свою книгу, но не располагаю достаточным количеством времени, чтобы делать это быстро. Полагаю, что когда опишу все подробно, смогу развернуть и объяснить очень подробно, что имею в виду.

Почему у меня только негативные комментарии к гос. стандартам по BIM?

У меня есть своя BIM-методология (ну как своя, набранная отовсюду от экспертов с кем общаюсь), она комплексная, завершенная, позволяет решать различные задачи - такие как автоматическая проверка качества моделей, сбор объемов работ и связка их с бюджетом, сметой и календарным сетевым графиком. Мне она кажется правильной, я к ней шел больше 7 лет, отрабатывая и шлифуя, взращивая её на практике со всех ролей (проектировщика, застройщика, техзаказчика и генподрядчика), я видел лично работу этой методологии на более чем 30 проектах. Я допускаю что я могу ошибаться, что моя методология может быть неправильной, но, пока она работает и никто не показал что-то лучше, я её развиваю.

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

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

upd: Кому интересна подробнее моя методология https://youtu.be/kvV2XsxOZhI

продолжение следует...

#ГосТИМ Моё отношение к гос. стандартизации в 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 и двигаться дальше, не занимаясь ретро-технологиями из-за личных идеологических или политических проблем.