ТИМ | BIM | Литература | НПА | НТД

Кейс: как ПИК перевел исполнительную документацию с корпоративной системы на «Билдокс» Лилия Карасева и Ольга Абражевич из команды автоматизации девелопмента в ПИК рассказали на Хабре о том, почему технически правильное решение не гарантирует принятия пользователями. Исполнительная документация (500+ объектов, 250 тыс. документов в год) велась в корпоративной системе Тесса. Для пользователей это был привычный инструмент. Но отрасль переходила на XML, и поддержка процессов внутри универсальной системы становилась всё дороже. Поэтому начали переход на профильное решение и выбрали «Билдокс». Это усложнило работу пользователей: вместо одного файла — привязка документа к объекту, работам, материалам. Действий стало больше, привычный сценарий сломался. Началось: «верните как было». С чем столкнулись Пилот на трёх объектах прошёл успешно, но при масштабировании выяснилось: то, что работает на малой выборке, не гарантирует принятия тысячами пользователей. Люди проходили обучение, знали процессы, но не могли работать — не были настроены доступы, роли, не созданы объекты. А пока старая система оставалась доступной, большинство откладывало переход. Что помогло Запустили War Room — отдельный канал связи с ежедневным мониторингом проблем в первые две недели после отключения старой системы. Вместо формальных спонсоров-руководителей нашли амбассадоров — опытных сотрудников, к которым коллеги привыкли обращаться за советом. Обучение перестроили с разделов системы на сценарии. Результаты 800+ объектов переведены, SLA достиг 99%, затраты на техподдержку снизились на 70%. Весь цикл занял 10 месяцев. Главный вывод: сопротивление неизбежно, но если новый инструмент решает задачи, а старого больше нет, пользователи адаптируются. «Альянс Цифровых Лидеров в стройке» в MAX

Интервью уважаемого начальника Главгосэкспертизы Игоря Евгеньевича Манылова, конечно, больше рекламное, в части допуслуг и сервисов ГГЭ. С другой стороны — почему нет, могут себе позволить, да и необходимость назрела: особенно на фоне свежей проверки Счётной палаты, которая нашла на счетах учреждения около 11,9 млрд рублей свободных остатков (доходы выросли с 6,6 млрд в 2020-м до 12,1 млрд в 2025-м) и предложила перечислить в бюджет половину. На таком фоне подробный рассказ о новых сервисах — вполне объяснимое желание показать, зачем нужны деньги. Центр инженерии данных: XSD как запоздалое признание

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

Вот это мы любим: сначала наплодили кучу XML-схем, теперь спохватились про правила их создания. Хорошо, что вообще спохватились. Но раз стандартов для приведения схем в порядок до сих пор не было — это заодно и трудозатраты, и доработка ПО у всех, кто с этими схемами работает. Отдельный нюанс: не все XML-схемы в принципе разрабатывает Главгосэкспертиза — так что методология для чужих схем это либо межведомственная координация, либо заход на чужую поляну и расширение полномочий. 🙂 И главное: внедрение ИИ — это не только про XSD и машиночитаемый формат, хотя кормить его действительно нужно упорядоченными данными, а не мусором. Но мало «упорядочить» — данные ещё нужно анализировать содержательно. А вот с этим у нас по-прежнему большие пробелы: собирать научились, извлекать смысл — пока нет. «Работаем на себя» — но, кажется, уже с оговоркой Задачи ЦДИ в интервью в первую очередь про саму ГГЭ: административные процессы, управление стоимостью, геоданные. Но дальше — судя по всему, после неоднократных напоминаний министра — появляется формулировка: доступ к разрабатываемым решениям нужно обеспечить всем участникам отрасли, для чего потребуются отдельные платформенные решения. Хорошо, что появилась. Вопрос — окажется ли это доступом к самим данным (база КАЦ, XML-сметы прошедших экспертизу объектов, XML-ВОР), или только к готовым сервисам поверх них, которые ГГЭ сама решит, что показывать. Экономия и повторные экспертизы — тот самый неудобный вопрос

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

Только вот Счётная палата регулярно говорит ровно об обратном — о постоянных повторных экспертизах и перепроектировании. Например, июльский отчёт по трём арбитражным судам (Волгоград, Иркутск, Удмуртия). Если экспертиза действительно снижает риски перепроектирования на ранних стадиях — почему СП из отчёта в отчёт находит ровно этот сценарий? И ещё момент: проверка достоверности сметной стоимости — это сверка с действующей сметно-нормативной базой, а не независимая проверка конъюнктурного анализа цен и не ответственность за итоговую стоимость, которая вышла из экспертизы. Примеров хватало, когда после положительного заключения претензии по итогу предъявляют почему-то не Главгосэкспертизе, а заказчику.

Только в первом полугодии 2026 года мы сэкономили общему бюджету стройки более 144 млрд рублей, из них свыше 94 млрд — средства государственных бюджетов всех уровней

Отлично. А на сколько по факту подорожало? Есть такая статистика? В пресс-релизах и интервью — нет, только цифры в одну сторону. Ценообразование: справедливая цена — для кого?

За каждой методикой стоят вопросы точной и справедливой цены строительства. По плану на 2026 год уже разработаны 9 из 12 методик

Точная и справедливая — запишем. Справедливая для кого: бюджета, подрядчика, заказчика, который эту смету потом будет пересчитывать? И насколько точная, если по нашим расчётам по 86 регионам среднее наполнение КСР текущими ценами — 2,11%, ценообразующих ресурсов — 5,83%, при официальных ~41% по другому знаменателю. Про ресурсный метод и наполняемость ФГИС ЦС — в интервью снова ни слова. Биржи и ЭТП: зарегистрировались — не значит передают Регистрация организатора торгов — административный факт, а не поток цен. Интереснее была бы не констатация подключения, а цепочка: сколько ценовых предложений реально получено, сколько признано пригодными для расчёта, по скольким позициям КСР изменились текущие цены. Пока — только «зарегистрировались», а «в дальнейшем» без сроков. Ну да осталось немного: ждем невероятного прорыва по итогам публикации данных в ФГИС ЦС за III квартал. Иначе зачем все это было, правда? Что в сухом остатке Направление в целом верное — ЦДИ создан не для галочки, ИИ действительно внедряется, а оговорка про доступ для всей отрасли — правильный сдвиг, который стоит поддержать. Но пока каждый содержательный тезис интервью упирается ровно в то, что уже не раз подсвечивала Счётная палата: экономия без обратной статистики, доступ к сервисам без доступа к данным, наполнение ФГИС ЦС без конкретных цифр. Разница только в формулировке — там это «риск» и «нарушение», здесь — «эффективное использование» и «интеллектуальные инструменты».

Отдельная государственная экспертиза информационной модели законодательством не предусмотрена Тринадцатый арбитражный апелляционный суд рассмотрел дело № А42-11389/2025, в котором заказчик отказался принимать и оплачивать выполненные проектные работы, ссылаясь, в частности, на отсутствие отдельного положительного заключения государственной экспертизы на информационную модель в формате IFC. Проектная документация при этом была представлена на государственную экспертизу, по результатам которой было выдано положительное заключение. Суд установил, что документация была разработана в бумажном и цифровом виде и в полном составе передана на экспертизу. Информационная модель в формате IFC также была передана заказчику. Поэтому предметом спора стала не передача информационной модели как таковой, а требование о наличии отдельного заключения государственной экспертизы именно на эту модель. Суд первой инстанции указал, что отдельного прохождения государственной экспертизы только информационной модели в рамках разработанной и получившей положительное заключение ПД и РИИ законодательством не предусмотрено. Апелляционный суд этот вывод подтвердил. Вывод судов основан на разграничении предмета государственной экспертизы и формы представления проектной документации. В соответствии со статьей 49 ГрК РФ государственной экспертизе подлежат ПД и РИИ. Результатом экспертизы ПД является заключение о ее соответствии установленным требованиям, результатам инженерных изысканий и заданию на проектирование. Отдельная государственная экспертиза информационной модели как самостоятельного объекта этой нормой не предусмотрена. При этом информационная модель может являться формой представления ПД. Ее наличие в составе проектного комплекта не превращает ее автоматически в дополнительный объект экспертизы. Это важно и с точки зрения договора. В рассматриваемом деле контракт предусматривал разработку и передачу информационной модели в формате IFC. Такая обязанность подрядчика могла подлежать исполнению и проверке заказчиком в рамках договорных отношений. Однако само договорное требование о передаче IFC не создает предусмотренной законом процедуры государственной экспертизы информационной модели. Иными словами, наличие обязанности разработать информационную модель и наличие обязанности получить положительное заключение государственной экспертизы на эту модель – не одно и то же. Отдельно следует обратить внимание на письмо Минстроя России от 27.11.2025 № 73021-КМ/14. Оно уже не относится непосредственно к обстоятельствам рассматриваемого спора, но представляет интерес для понимания действующего подхода к фиксации ПД в форме ИМ ОКС. В письме Минстрой рекомендовал считать проектную документацию подготовленной в форме информационной модели при наличии в составе комплекта документов файлов в формате XML и (или) IFC и указывать это обстоятельство в заключении государственной экспертизы. Рекомендация была связана прежде всего с унификацией учета таких заключений при расчете показателя цифровой зрелости строительной отрасли. Таким образом, наличие IFC может быть достаточным основанием для соответствующей отметки в заключении государственной экспертизы по предложенному Минстроем подходу и в целях учета документации при расчете соответствующего показателя. Но это не означает появления отдельной экспертизы информационной модели и не требует выдачи самостоятельного положительного заключения непосредственно на IFC. В результате дело № А42-11389/2025 показывает достаточно четкую границу: ПД может быть представлена на государственную экспертизу в форме информационной модели, а факт ее подготовки в такой форме может фиксироваться в заключении. Однако отдельная государственная экспертиза информационной модели после проведения экспертизы ПД законодательством не предусмотрена. Именно отсутствие такой самостоятельной процедуры не позволило заказчику обосновать отказ от приемки и оплаты работ ссылкой на отсутствие отдельного заключения на информационную модель. С заказчика было взыскано 5 840 400 рублей. Дело ушло в кассацию. 📸 bimsert

Как обещала, вот все типы проверок. Напоминаю, всё это прямо внутри Civil 3D. По этому функционалу есть, кстати, подробная видео-справка на Rutube. Если хотите в текстовом виде, напишите в комментах, я отправлю PDF. Общие - наложение CAD-блоков - наложение мультивыносок - наложение контуров семейств - наложение штриховок - пересечение санитарно-защитных зон - пересечение границ проектирования - проверка производителя материалов - самопересечения полилиний и штриховок - проверка соответствия слоя CAD-стандарту Бордюры - корректность прилегания покрытий к бордюрам (например, асфальт не доведён до бордюра или наоборот заходит за него) Озеленение - соответствие количества деревьев и кустарников в модели количеству, указанному в выносках МАФ - соответствие высоты падения толщине резинового покрытия - пересечения зон безопасности разных МАФ - соответствие зоны безопасности резиновому покрытию Освещение - проверка расстояния между деревьями и опорами освещения (по умолчанию используется радиус 4 м) Покрытия - наличие конструкций дорожной одежды (КДО) у покрытий Наружные сети - проверка нормативных расстояний и пересечений между элементами благоустройства и подземными коммуникациями 🤩Бесплатная пробная версия PikTools Генплан на 30 дней — по ссылке 🤩

XML для исполнительной документации: а где обещанный эффект? Недавно на Хабре вышла показательная статья о переходе к цифровой работе с исполнительной документацией. Ее ценность в том, что авторы показывают не просто замену бумажных документов электронными файлами, а изменение самого подхода: от «документа как файла» к структурированным данным, связанным с объектами, работами, материалами и другими документами. И здесь возникает вопрос, с которого, на наш взгляд, и стоило бы начинать разговор об XML. Не «нужна ли цифровизация исполнительной документации?». Безусловно, нужна. Вопрос другой: а обязательно ли для этого переводить исполнительную документацию именно в XML? Потому что основные преимущества, описанные в статье, связаны прежде всего со структурированием данных и установлением связей между ними. Это позволяет искать и анализировать информацию, контролировать комплектность, автоматизировать процессы, интегрировать данные с другими системами. Но это преимущества цифровой системы и структурированных данных, а не XML как такового. Структурированные данные и XML – не одно и то же. Можно построить цифровую систему, в которой PDF остается визуальным представлением документа, а необходимые сведения о нем хранятся в структурированном виде и используются для автоматической обработки. И наоборот, можно получить XML-файл, который формально соответствует XSD-схеме, но по существу остается электронной формой привычного документа. XML действительно удобен для формализации структуры, машинной обработки, валидации и межсистемного обмена. Но тогда возникает главный вопрос – какую дополнительную ценность дает именно XML? Причем этот вопрос особенно интересен, если посмотреть не на отдельную информационную систему, а на регулирование исполнительной документации в целом. В действующем перечне XML-схем Минстроя действительно есть схемы отдельных документов исполнительной документации – общего и специальных журналов, актов освидетельствования, актов испытаний и других документов. Но значительная часть перечня вообще относится не к исполнительной документации, а к документам государственного строительного надзора и административным процедурам. Да и сами XML-схемы появляются хаотично, а их содержание строиться на исключенных из сводов правил формах. И главное – состав исполнительной документации существенно шире набора документов, для которых сегодня разработаны XML-схемы. То есть мы имеем не перевод всей исполнительной документации в единый структурированный формат, а формирование XML-схем для определенной ее части. И здесь возникает самый интересный вопрос – где именно находится системный эффект от XML, если в XML переводится только часть массива исполнительной документации, а остальная документация продолжает существовать в иных форматах? Если преимущество XML заключается в структурированных данных – почему структурируется только часть данных? Если преимущество в межсистемном обмене – какой объем исполнительной документации реально участвует в таком обмене? Если преимущество в автоматизации контроля – какие конкретно процессы становятся эффективнее именно благодаря XML? Это не аргумент против цифровизации. Напротив, статья на Хабре достаточно убедительно показывает, зачем строительной отрасли нужны связанные и структурированные данные. Но она одновременно позволяет отделить ценность цифровизации от ценности конкретного формата. Полученный авторами эффект нельзя автоматически приписать XML, поскольку одновременно изменились процессы, архитектура данных и сама организация работы с исполнительной документацией. Есть и обратная сторона. Переход к структурированным данным увеличивает количество операций для пользователя – нужно заполнять дополнительные сведения, устанавливать связи между документами и поддерживать их структуру. Авторы проекта прямо описывают это как одну из проблем перехода. Поэтому возникает вполне рациональный вопрос: какой измеримый эффект компенсирует эту дополнительную нагрузку? Сколько времени экономится при поиске документов? Насколько сокращается количество ошибок? Как ускоряется проверка комплектности? Что получает заказчик, эксплуатация и государственные информационные системы? И вот здесь мы подходим к главному. Часто необходимость XML объясняется очень просто: «так требует законодательство». Но это не отвечает на вопрос, насколько обоснованно само законодательное требование. Если государству нужны структурированные и машиночитаемые данные – с этим трудно спорить. Если нужен межсистемный обмен – тоже. Но из необходимости получить структурированные данные еще не следует необходимость сделать обязательным именно XML. Это разные утверждения «нам нужны структурированные данные» и «значит, эти данные должны представляться именно в XML». Между ними должно находиться обоснование: почему именно XML, какую проблему он решает лучше альтернативных технических решений, какой измеримый эффект дает и соразмерен ли этот эффект затратам участников строительства. Особенно если нормативное регулирование в итоге приводит не к единой структурированной исполнительной документации, а к появлению XML только для отдельных ее видов. И тогда возникает уже не технический, а регуляторный вопрос – доказана ли необходимость делать именно этот технический способ обязательным? Возможно, правильнее было бы сначала определить конечный результат – какие данные должны быть структурированы, какие связи между ними должны сохраняться, какие автоматизированные операции должны обеспечиваться и какие системы должны уметь их использовать. А уже затем выбирать технический формат. Потому что цифровизация исполнительной документации нужна не ради XML. Она нужна ради данных и возможностей, которые эти данные дают. А XML – всего лишь один из инструментов. И прежде чем превращать этот инструмент в обязательное нормативное требование, хотелось бы увидеть главное – где именно доказан эффект от его применения и почему этот эффект нельзя получить более рациональным способом? 📸 bimsert

Опубликован ПНСТ 1080-2026 по ЦИМ поликлиник ПНСТ 1080-2026 Цифровые информационные модели объектов непроизводственного назначения. Поликлиники. Общие требования Стандарт разработан с целью внедрения ТИМ, используемых при разработке ЦИМ поликлиники в составе информационной модели поликлиники. Стандарт распространяется на ЦИМ ОКС непроизводственного назначения с функциональным назначением поликлиники (код 03.01.004.002). Настоящий стандарт устанавливает требования к формированию ЦИМ поликлиники для достижения целей базовых процессов ведения ЦИМ объекта капитального строительства, указанных в настоящем стандарте, на этапах осуществления предпроектной подготовки, архитектурно-строительного проектирования, строительства, реконструкции, капитального ремонта, эксплуатации и сноса. Стандарт определяет набор базовых процессов ведения ЦИМ объекта капитального строительства и наборы атрибутивных данных элементов ЦИМ поликлиники. Стандарт содержит описание наборов атрибутивных данных элементов ЦИМ поликлиники, объем которых зависит от базовых процессов ведения ЦИМ поликлиники, установленных застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию ОКС в договоре, задании на проектирование, техническом задании на ЦИМ ОКС. Настоящий стандарт устанавливает требования к наборам атрибутивных данных элементов ЦИМ поликлиники для реализации набора базовых процессов, при этом наборы атрибутивных данных элементов ЦИМ поликлиники включаются в ЦИМ, если это установлено законодательством Российской Федерации, а также если требование об их включении содержится в стандарте организации, договоре, задании на проектирование, техническом задании на ЦИМ объекта капитального строительства и (или) в плане реализации проекта с использованием информационного моделирования. Вступает в действие с 01.01.2027 г. 📸 bimsert

Вопрос/Ответ: о регистре хэш-сумм файлов при формировании Пояснительной записки (Раздел ПД №1) Вопрос: При подаче пояснительной записки в ФАУ «Главгосэкспертиза России» нам выставлено замечание, что контрольные суммы CRC-32 должны быть записаны в верхнем регистре. Однако XML-схема explanatorynote-01-07.xsd допускает любой регистр. Правомерно ли данное замечание? Ответ: Нет, замечание о необходимости верхнего регистра является требованием конкретной информационной системы (ЕЦПЭ), а не требованием XML-схемы explanatorynote-01-07.xsd. В схеме explanatorynote-01-07.xsd тип tFileChecksum определен следующим образом:

<xs:simpleType name="tFileChecksum">
    <xs:annotation>
        <xs:documentation xml:lang="ru">Текстовая строка длиной 8 символов</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
        <xs:pattern value="[0-9a-fA-F]{8}"/>
    </xs:restriction>
</xs:simpleType>

Регулярное выражение [0-9a-fA-F]{8} явно допускает: • 0-9 - цифры; • a-f - строчные буквы; • A-F - прописные буквы. Таким образом, с точки зрения XML-схемы файл с хэш-суммами в любом регистре является валидным. Если файл успешно прошел проверку по XML-схеме, а система требует верхний регистр - это ограничение программного обеспечения (ЕЦПЭ), которое должно быть устранено на стороне системы, так как оно противоречит принятой логике в данной версии XML-схемы. Примеры валидных значений по XML-схеме ПЗ версии 01.07: • 3c57452f - строчные: валидно; • 3C57452F - прописные: валидно; • 3c57452F - смешанный: валидно. С точки зрения XML-схемы - регистр не имеет значения, все варианты допустимы. Замечание ФАУ «Главгосэкспертиза России» о необходимости верхнего регистра не закреплено в схеме и по сути противоречит ей. Обращаем внимание, что для всех типов файлов, упоминаемых в XML-файле пояснительной записки, используется один и тот же тип tFileChecksum: • файлы проектной документации; • файлы отчетов по инженерным изысканиям; • файлы подписей; • файлы 3D-моделей; • любые другие файлы. Таким образом, правило одинаково для всех файлов, и указанное противоречие носит системный характер. Рекомендуется обратиться в Техподдержку ФАУ «Главгосэкспертиза России» для разъяснения данного требования и его приведения в соответствие с XML-схемой. 📸 bimsert

Вчера провели первую встречу с экспертным сообществом по обсуждению проектов параметрических сводов правил. Почему это важно? Сейчас в системе технического регулирования одновременно идут два ключевых процесса. Первый — переход к параметрическому нормированию: в соответствии с СП 555 нормативная база выстраивается по трем уровням — СП «Основные положения», СП «Правила проектирования» и методические документы. Второй — изменение подхода к экспертизе. С 1 марта 2027 года экспертиза будет проверять проектные решения на соответствие требованиям, включенным в Реестр требований на портале Стройкомплекс.РФ. Обращаю внимание, что в Реестр войдут требования из сводов правли уровня «Основные положения». А требования СП «Правила проектирования» сами по себе обязательным предметом проверки экспертизы не будут, но могут применяться проектировщиком для обоснования своих решений. Поэтому сейчас две задачи: максимально качественно сформировать СП «Основные положения» — именно заложенные в них требования станут основой для проверки экспертизой — и обеспечить поэтапный перевод этих требований в машиночитаемый (машинопонимаемый) формат. Ниже презентации по теме.

Новое учебное пособие «Нанософт»: «Проектирование и расчет систем электроснабжения 0,4 кВ предприятий транспорта в nanoCAD BIM Электро» Компания «Нанософт» (член НОТИМ) представляет первое пособие в новой серии Академической библиотеки. Издание объединяет теорию, практику и цифровые инструменты для создания информационных моделей систем электроснабжения 0,4 кВ в nanoCAD BIM Электро. Разработка уже получила рекомендацию Приволжского государственного университета путей сообщения. Ключевые возможности пособия: ✅Готовый алгоритм работ — от старта проекта до комплекта чертежей по ГОСТ; ✅Работа с архитектурной подосновой и интеллектуальный выбор оборудования; ✅Прокладка кабельных трасс с новыми функциями: наклонные участки под любым углом и точная работа с высотами в 3D; ✅Автоматизированные проверочные расчеты и выпуск документации. Подробнее #новости_членов_НОТИМ 🥲 НОТИМ в MAX

Правительство утвердило новые требования к информационным системам госорганов не относящихся к ГИС Постановлением Правительства РФ от 13.08.2026 № 1007 утверждены требования к порядку создания и эксплуатации государственными органами информационных систем, не являющихся государственными информационными системами. Утверждённые требования устанавливают единые правила для систем, которые используются в работе ведомств для организационного, документационного, финансового и технического обеспечения их деятельности, но не предназначены для реализации государственных функций или предоставления услуг в электронном виде. Документ вводит понятие «фасет информационной системы» – группы систем со сходными характеристиками и параметрами. Для каждого такого фасета разрабатываются и утверждаются стандарты, устанавливающие минимальные требования к функциям, процессам и иным характеристикам. Разработку стандартов ведёт Минцифры России, а утверждает – президиум Правительственной комиссии по цифровому развитию. Государственные органы вправе направлять предложения о разработке новых стандартов, а Минцифры либо принимает решение о разработке, либо даёт мотивированный отказ, в том числе если уже есть действующий стандарт для данного фасета. Все создаваемые системы подлежат обязательному учёту в федеральной государственной информационной системе координации информатизации в соответствии с правилами учёта ИТ-активов. Создание системы оформляется правовым актом государственного органа. При этом реализация мероприятий по созданию должна вестись с использованием программ для ЭВМ и баз данных (программно-аппаратных комплексов), включённых в национальный фонд алгоритмов и программ или в реестры российского ПО и ПО из стран ЕАЭС, причём для таких компонентов в реестрах предусматривается специальный признак «соответствует стандартам». Если необходимого ПО с таким признаком нет или стандарт для данного фасета не утверждён, допускается разрабатывать собственное ПО на базе имеющегося из реестров, но при этом требуется подготовить технико-экономическое обоснование и согласовать его с Минцифры (срок согласования – 20 рабочих дней). Положительное заключение уполномоченного органа является обязательным условием для начала создания. Техническое задание на создание системы разрабатывается с учётом модели угроз безопасности информации и уровней защищённости персональных данных. На всех этапах должны соблюдаться требования о защите информации, установленные в соответствии с законодательством. Вводится обязательная оценка вводимых в эксплуатацию и уже эксплуатируемых систем на соответствие стандартам. Такая оценка проводится автоматически через систему координации на основе сведений, размещённых государственным органом при учёте системы. По результатам системе присваивается статус «соответствует стандартам» или «не соответствует стандартам». В случае соответствия в реестры ПО автоматически включается специальный признак для используемых компонентов, а информация о системе публикуется на портале системы координации. Минцифры осуществляет мониторинг соответствия систем стандартам и при необходимости актуализирует присвоенный статус. Системы, признанные несоответствующими, подлежат приведению в соответствие. Эксплуатация системы начинается на основании правового акта о вводе в эксплуатацию, в котором назначаются ответственное должностное лицо и структурное подразделение, определяется порядок эксплуатации. Эксплуатация ведётся в соответствии с разработанной эксплуатационной документацией. Запрещается эксплуатация без надлежащего оформления прав на объекты интеллектуальной собственности и без учёта системы в системе координации. Любые изменения функций уже введённой в эксплуатацию системы должны осуществляться в соответствии с теми же правилами, что и создание. Для государственных органов города Москвы установлено исключение – для них обязательными являются только пункты о правовом акте создания, техническом задании с учётом защиты информации, вводе в эксплуатацию, эксплуатационной документации и порядке изменений, остальные требования не обязательны. Кроме того, постановление вносит изменения в Правила ведения реестров российского ПО и ПО из ЕАЭС – в них добавляется новый специальный признак «соответствует стандартам», который включается автоматически по результатам оценки информационной системы. Документ вступает в силу 1 сентября 2026 года и распространяется на все ведомственные информационные системы, создаваемые для внутреннего обеспечения деятельности государственных органов. P.S. ИСУПовцам на заметку. 📸 bimsert

Рубрика «Вопрос/Ответ»: о форме журнала ухода за бетоном Вопрос: Минстрой России 19.11.2025 разместил XML-схему «Журнал ухода за бетоном» в разделе «Действующие XML-схемы». В описании схемы в качестве нормативного основания указана форма, предусмотренная СП 70.13330.2012. При этом приказом Минстроя России от 03.06.2026 № 353/пр утверждено Изменение № 8 к СП 70.13330.2012, которым приложение с формой журнала исключается из свода правил с 01.03.2027. В СП 543.1325800.2024 отдельная форма такого журнала не установлена. Какую форму применять после 01.03.2027? Ответ: С 01.03.2027 приложение к СП 70.13330.2012, устанавливающее форму журнала, утрачивает действие. Это прямо следует из пункта 2 приказа Минстроя России от 03.06.2026 № 353/пр, которым приложения А, Б, В, Г, Д, Е, И, Ф Изменения № 8 вводятся в действие с 1 марта 2027 года. При этом в СП 543.1325800.2024 форма журнала ухода за бетоном пока не установлена. Однако соответствующие изменения готовятся. Таким образом, если до 01.03.2027 новая нормативная форма журнала не будет установлена, с этой даты возникает ситуация, при которой обязательный документ должен вестись, но его типовая форма нормативно не определена. В таком случае форма журнала может быть определена для конкретного объекта в технической документации и договоре строительного подряда. Согласно части 2 статьи 743 ГК РФ договором строительного подряда определяются состав и содержание технической документации. Определенная таким образом форма может быть закреплена в утвержденном перечне исполнительной документации объекта в соответствии с приказом Минстроя России от 16.05.2023 № 344/пр. При этом XML-схема Минстроя не является самостоятельным нормативным основанием для установления формы документа. Она предназначена для формирования исполнительной документации в электронном виде и должна соответствовать форме и содержанию документа, установленным нормативными и техническими документами. Поэтому после 01.03.2027 использование опубликованной XML-схемы, построенной на форме исключенного приложения СП 70.13330.2012, само по себе не может определять форму журнала. Если новая нормативная форма к этому моменту не будет установлена, ее следует определить для конкретного объекта и закрепить в договорной и технической документации. При этом наличие XML-схемы на сайте Минстроя не означает, что она продолжает применяться независимо от нормативного основания формы, для которой она разработана. Если с 01.03.2027 соответствующая форма исключена из документов по стандартизации и новая форма не установлена, нормативная форма документа, на основе которой разработана XML-схема, отсутствует. В этом случае для формирования электронной исполнительной документации применяется один из альтернативных форматов, предусмотренных пунктом 5 Порядка, утвержденного приказом Минстроя России от 16.05.2023 № 344/пр. Аналогичный вопрос возникает и в отношении других XML-схем, размещенных Минстроем России в разделе «Действующие XML-схемы» и основанных на формах приложений к СП 70.13330.2012, которые Изменением № 8 исключаются с 01.03.2027. В частности, речь идет о «Журнале бетонных работ», «Журнале замоноличивания монтажных стыков и узлов», «Журнале выполнения монтажных соединений на болтах с контролируемым натяжением», а также о формах, связанных со сварочными и антикоррозионными работами. По каждой из таких схем необходимо отдельно оценивать наличие новой нормативной формы после 01.03.2027. Иными словами, при отсутствии нормативно установленной формы участники строительства вправе определить форму журнала самостоятельно – с учетом требований к содержанию документа и особенностей конкретного объекта. Указанный вывод об альтернативных форматах относится к случаям ведения исполнительной документации в электронной форме. Пункт 1 Порядка, утвержденного приказом Минстроя России от 16.05.2023 № 344/пр, предусматривает также ведение исполнительной документации на бумажном носителе. В этом случае вопрос применения XML-схемы непосредственно не возникает. Ранее, мы писали о подобной проблеме с формами специальных журналов работ. 📸 bimsert

💻Как цифровизация этапа эксплуатации повышает удовлетворённость жителей и сокращает издержки? Уровень цифровизации процессов на этапе эксплуатации – 46% по данным исследования ЭКСПЕРТ.ДОМ.РФ. Эффективными цифровыми решениями на этапе эксплуатации девелоперы признают: 🏠 Управленческие инструменты для УК и девелопера. 📱 Потребительские сервисы, которые реализуются за счет мобильных приложений.

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

Пилотируемые цифровые решения: 🤖 Роботизация. Некоторые девелоперы запускают пилоты проектов, где используются роботы, которые выполняют функцию клининга в МОП и консьержа. 📶 Системы для прогнозирования трафика и оптимальной «рассадки» коммерческих площадей в ЖК. Цифровизация на этапе эксплуатации позволяет получать как качественные, так и прямые финансовые эффекты: ➡️Цифровые решения повышают скорость обработки обращений жителей и качество предоставляемых услуг, что повышает удовлетворенность клиентов. ➡️Потребительские сервисы позволяют снижать операционные расходы УК за счет автоматизации работ и создавать дополнительные каналы монетизации сервисов. ➡️Безопасность: устройства помогают контролировать состояние инженерных систем и доступ на придомовую территорию. ИТ-ландшафт умной эксплуатации формируется исходя из выбранных сценариев автоматизации ЖК/здания/квартиры. Структуру решений и их функциональные возможности можно изучить в маркетплейсе ЭКСПЕРТ.ДОМ.РФ. Подробнее о цифровизации этапа эксплуатации в нашем экспертно-аналитическом докладе. Узнайте подробнее о внедрении цифровых сервисов на этапе эксплуатации: expert@domrf.ru

#Вопросы #Впомощьпроектировщику ❓ Будет ли в новой версии XML-схемы задания на выполнение инженерных изысканий возможность указывать сразу несколько видов инженерных изысканий? ✅ Да, такая возможность предусмотрена. XML-схема задания на выполнение инженерных изысканий версии 01.00, вступающая в силу с 3 октября 2026 года, позволяет включать в один XML-документ сразу несколько видов инженерных изысканий. Структура схемы предусматривает три независимые категории: — основные виды инженерных изысканий — до 5 видов; — специальные виды инженерных изысканий — до 6 видов; — иные необходимые исследования — до 6 видов. Эти категории могут использоваться как по отдельности, так и одновременно в любых сочетаниях. Например, в одном XML-задании можно указать инженерно-геодезические и инженерно-геологические изыскания, дополнить их геотехническими исследованиями, а также включить иные исследования с текстовым описанием. При этом для каждого указанного вида изысканий XML-схема предусматривает обязательное заполнение целей и задач.