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

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

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

Так, например, понятие "высота здания" в СП по общественным зданиям подразумевает высоту от отметки 0.000 до верха парапета, в 123-ФЗ (пожарном) это высота от уровня земли до нижа подоконника последнего этажа, а в 73-ФЗ (о культурном наследии) это высота от уровня земли до конька кровли, или до верха выступающего оборудования.

Я сейчас могу чуть ошибаться, т.к. не смотрел детально, но суть именно в том что есть такие определения, и их много.

После решения проблем «разных определений» для терминов и заведения всех определений в единый перечень можно будет перейти к задаче №4 - превращение нормативных документов в наборы условий, в основном вида "если... то..." (фактически они и сейчас ими являются, но написано всё так что не каждый человек поймёт, не то что машина).

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

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

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

Так например в Петербурге долгое время по ПЗЗ проектировщики детских садов были обязаны предусматривать на их территории не менее 50% парковочных мест для посетителей и персонала, при том что по СанПиН на территории ДОУ парковка в принципе запрещена (и на расстоянии 25м от него тоже). Как сейчас, уже не знаю, но уверен что таких мест ещё предостаточно, так как инструмент контроля их отсутствия ещё не изобрели).

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

Конечно, реализовывать эту задачу нужно по частям, как и есть слона: начать с одного документа, и с первых трёх пунктов – задач. Затем постепенно добавлять нормативы, и пробовать решать задачи 4 и 5 в тестовом режиме.

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

Это обязательный путь, который придётся пройти для введения автоматических проверок в экспертизах (и внутри организаций – проектировщиков, генподрядчиков и техзаказчиков).

Почему в РФ не нужно внедрять BIM на гос. уровне - с таким заголовком на прошлой неделе вышла статья Альберта Сумина.

https://zen.yandex.ru/media/id/5ac209cbad0f22cf63310792/pochemu-v-rossii-ne-nujno-vnedriat-bim-na-gosudarstvennom-urovne-5ddc3c15d7657134590e4078

Статья получилось эмоциональной и провокационной (один заголовок чего стоит?).

Альберт собирает комментарии и критику по интернету и отвечает на них, продолжением статьи. Задам и я пару вопросов:

1. С какого года в BIM стало возможно выполнить основные разделы проектирования (АР, КР, ОВ, ВК) и проверить их на коллизии? Какие есть примеры?

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

3. Имеются ли случаи в РФ, когда проектировщик компенсировал свои ошибки или его представители понесли наказание из-за аварии? Вообще, работает ли система ответственности в строительной сфере или это страшилки для совещаний?

Выскажу свое мнение по указанным выше вопросам:

1. В начале 2000х не было возможности выполнять BIM проекты т.к. инструменты были не готовы. Честно говоря и сейчас мало кто может выполнить проект в архикаде или аллплане. В 2008 в архикаде не было инструмента Морф (произвольная геометрия), которым сейчас в нем всё моделируется. Мебель выполнялась стенками и перекрытиями.

У них не было нормального экспорта в ifc. Сам IFC 2х3, который мы сейчас используем, только с 2008 начал появляться в этих ПО.

Не было инструментов для моделирования инженерных систем и конструктива. То, что некоторые называют тогдашним BIM'ом, не более чем 3D моделирование для визуализации. Использовали ArchCAD вместо 3ds Max и теперь примазываются мол в BIM'е давно.

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

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

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

Кароче, государству выгодно на своих объектах внедрять BIM. Для этого оно должно написать стандарты, которые сделать обязательными на своих стройках, а частный бизнес пусть либо применяет их у себя, либо пишет своё.

продолжение завтра...

Про увеличение ответственности проектировщика.

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

В РФ не принято решать вопросы в судах, не принято каждое изменение в ТЗ прикреплять допником. На стройках сейчас идет взаимодействие: "ты мне я тебе" - закрываются глаза на косяки в документации, взамен на внесение доп. изменений по инициативе заказчика. Главное - дружить и искать компромисы.

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

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

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

Виды отображения информации.

Отображение информации в BIM делится на 2 вида: мобильное отображение и рабочее. Рабочее отображение должно быть быстрым, должно отображать большое количество информации и позволять быстро с удобными интерфейсами управлять информацией.

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

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

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

Самое главное, что оба отображения должны смотреть в одни и те же данные, что приводит к необходимости единого сервера, как на стороне редактора информации (рабочая), так и просмотрщика (мобильная).

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

В марте 2018 я ушел из ПИК-Проекта. Мой уход оброс слухами со стороны недоброжелателей, в связи с чем я бы хотел их развеять и написать как все было на самом деле.

1. Алексей Сёмин, мой непосредственный руководитель, увольняется (причины того оставлю за скобками, да я и сам не знаю).

2. Я встречаюсь с Тихомировым Директором по ИТ ДИТ ГК ПИК и договариваюсь с ним о переходе к нему, чтобы внедрять BIM в ГК ПИК через его департамент.

Причины:

- Я шел в ПИК работать с Семиным, из тех, с кем мне еще было бы интересно поработать там, были Фуксман и Тихомиров.

- В ПИК-Проекте мы уже автоматизировали к тому моменту все (кроме КР), что было эффективно автоматизировать.

- Писать системы контроля людей и генерации красивых отчетов мне было не интересно.

- Я понял, что дальнейшее развитие BIM - на стройке.

3. На совещании с Алмазовым, Семиным и Меремкуловым я говорю им, что ухожу в ГК ПИК.

4. Алмазов идет к Прыгункову (заму Гордеева) и договораивается, чтобы меня не брали в ГК ПИК, т.к. он обиделся (из-за того, что я принял решение о переходе не обсудив заранее с ним).

5. Мне пишет Прыгунков в телеграм и предлагает извиниться перед Алмазовым и вернуться в ПИК-Проект, то же предложение от Меремкулова лично, когда я принес заявление.

7. Я увольняюсь в течении 3 часов в тот же день, что и Сёмин.

Как отличить рабочую визуализацию строительства от выдуманной?

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

Фасады будут появляться не поэтажно по всему зданию, а по сторонам.

Инженерные сети не будут появляться в один момент разом.

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

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

https://m.facebook.com/story.php?story_fbid=2135132426586276&id=773922306040635

Почему у консалтеров нет реальных кейсов визуализации и расчета стоимости?

Это происходит от того, что их продукты требуют замены удобных и привычных инструментов, в которых специалисты, кто должен использовать их инструменты работали прежде.

Так например программы календарного сетевого планирования предлагают отказаться от ms project'а.

И проблема в том, что пока BIM инструменты менее функциональны и удобны именно в планировании, чем ms project или primavera.

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

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

И тут главное: специалисту кто делает график не требуется наглядности, он итак это в голове у себя визуализирует - ему в программе это не особо требуется.

Отсюда, есть два пути решения задачи по внедрению в работу BIM инструментов для планирования.

Первый: в продукте надо реализовать функционал ms project. И сделать таким же удобным для задач планирования. А потом уже добавлять связку с моделью.

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

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

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

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

Аналогичная ситуация и с расчётом стоимости строительства. Сейчас он ведется в excel.

Но тут добавляется проблема гибкости excel'я. Пользователь добавляет и удаляет строки, объединяет ячейки, пишет значения не в том формате, который требуется.

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

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

Но реализовать связку с excel еще сложнее, чем с ms project. Т.ч. скорее всего тут второй вариант и не возможен.

Проблема ответственности в стройке.

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

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

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

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

Но потом он же не может это признать и ищутся крайние.

Проблема сроков и качества.

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

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

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

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

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

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

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

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

Uber в строительстве - что для него нужно?

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

Для ответа на вопрос, возможна ли Уберизация в строительстве, необходимо рассмотреть технологии, благодаря которым стал возможен убер в такси.

1. Появились смартфоны как у клиентов, так и исполнителей.

2. Везде в городе есть мобильный интернет.

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

4. Стал возможен безналичный расчет (технически и психологически).

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

Из всех этих технологий наиболее проблемной для стройки является последняя: адреса и карты дорог.

Адреса на стройке - это работы, а карты - это стройгенплан, планы этажей, развертки по стенам, узлы (если вы работаете в 2D), или Информационная модель (если в BIM). Проект меняется значительно чаще, чем карта дорог и вообще каждый раз проектируется заново.

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

Чем отличается строительный бизнес от такси?

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

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

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

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

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

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

Чтобы заказать такси, вам надо будет дождаться, чтобы ещё несколько человек неподалеку заказали такое же такси, и ваши пожелания к водителю и классу автомобиля сошлись.

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

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

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

К тому же водитель будет везти вас не весь путь, а в определенном месте пересадит в другое такси и так несколько раз.

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

И после всего этого, представьте, что вы едете без навигатора, по распечатанным “по ГОСТ” картам.

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

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

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

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

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

Почему в Москве активнее внедряются новые технологии?

В Москве выше зарплаты и как следствие фонд оплаты труда составляет существенную часть.

Программы и программисты для автоматизации на фоне огромных ФОТ'ов выглядят не существенно, а если они могут еще и сократить его, то совсем замечательно.

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

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

Кстати, если кто-то читает из региона - рекомендую переезжать в Москву, здесь есть спрос на BIM-специалистов с хорошими зп - проверьте на hh.ru. А стоимость жизни не на столько выше, как зп.

Многие спрашивают о пользе BIM, мол сколько времени он экономит? а если не экономит, то кому нужна такая автоматизация, которая не уменьшает количество людей?

Вот пара историй из моей практики, когда я работал без BIM.

Начало моей строительной карьеры было в далеком 2013, я участвовал в монтаже системы пожаротушения в ТРЦ "Весна" в г. Петрозаводск. Когда я открыл проект, то впервые увидел разводку инженерных систем в одном уровне и у всех было указание (проложить в 50мм от плиты перекрытия), при этом на паркинге были полуметровые балки, которые надо было либо сверлить, либо обходить. Ни то ни другое предусмотрено проектом не было. Проект разрабатывал лучший в то время Проектный институт Петрозаводска "Штрих".

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

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

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

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

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

Это как сравнивать изготовление велосипедов и автомобилей, скажите спасибо, что в те же сроки.

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

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

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

BIM позволяет в те же сроки (или чуть более) достичь такого качества документации, что CAD рисунки уже кажутся чем-то не серьезным и даже стыдным.