779131-8.pdf
11.7 MB
Основные новеллы преддверии официального утверждения очередных правок в ГрК РФ
Основные изменения в ГрК РФ согласно принятому Госдумой РФ в третьем чтении законопроекту № 779131-8 «О внесении изменений в Градостроительный кодекс Российской Федерации»
(о совершенствовании саморегулирования в строительстве):
- отрицательное заключение и отказ в выдачи заключения - исключение для ГИП/ГАП из НРС;
- стандарты для СРО;
- выполнение РД только членами СРО;
- установлена ответственность ГИП и ГАП за качество ПД и РД;
- задание на выполнение изысканий более не разрабатывается исполнителем проектных работ;
- необходимость уведомления об увольнении ГИП и ГАП;
- выполнение работ ограничили предельным размером обязательств;
- уведомление СРО о заключенных договорах.
Кроме указанного, ИП или ЮЛ, не являющиеся членами строительных СРО, более не смогут выполнять работы по договорам строительного подряда, заключенным с региональным оператором, в случае, если размер обязательств по каждому из таких договоров не превышает 10 млн. рублей.
Основные изменения в ГрК РФ согласно принятому Госдумой РФ в третьем чтении законопроекту № 779131-8 «О внесении изменений в Градостроительный кодекс Российской Федерации»
(о совершенствовании саморегулирования в строительстве):
- отрицательное заключение и отказ в выдачи заключения - исключение для ГИП/ГАП из НРС;
- стандарты для СРО;
- выполнение РД только членами СРО;
- установлена ответственность ГИП и ГАП за качество ПД и РД;
- задание на выполнение изысканий более не разрабатывается исполнителем проектных работ;
- необходимость уведомления об увольнении ГИП и ГАП;
- выполнение работ ограничили предельным размером обязательств;
- уведомление СРО о заключенных договорах.
Кроме указанного, ИП или ЮЛ, не являющиеся членами строительных СРО, более не смогут выполнять работы по договорам строительного подряда, заключенным с региональным оператором, в случае, если размер обязательств по каждому из таких договоров не превышает 10 млн. рублей.
Рубрика «Вопрос/Ответ: входит ли ЦИМ и ИМ ОКС в Реестр документов, необходимых застройщику для строительства ОКС?
Вопрос:
В ходит ли ЦИМ и ИМ ОКС в состав Реестра документов, необходимых застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 статьи 5.2 ГрК РФ мероприятий при реализации проекта по строительству ОКС?
Ответ:
Согласно части 9 статьи 5.2 ГрК РФ, документы, сведения, материалы, согласования, предусмотренные нормативными правовыми актами Российской Федерации и необходимые застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 настоящей статьи мероприятий при реализации проекта по строительству ОКС, подлежат включению в Реестр таких документов, сведений, материалов, согласований, при этом, ЦИМ, ИМ ОКС с/без ЦИМ в составе текущей версии указанных документов, материалов и сведений в Реестре документов - не входит.
Сама проектная документация в текстовой и графической форме присутствует, а вот в форме ИМ ОКС и включаемых в нее сведений - нет.
Не смотря на то, что положениями части 5.3 статьи 49 ГрК РФ проектная документация и (или) результаты инженерных изысканий, а также иные документы, необходимые для проведения экспертизы проектной документации и (или) результатов инженерных изысканий, представляются в электронной форме, в том числе в форме информационной модели, наличие такой формы ПД как ИМ ОКС в Реестре документов, необходимых застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 статьи 5.2 ГрК РФ мероприятий при реализации проекта по строительству ОКС - не значится (отсутствует). То же характерно и для ПД, передаваемой в составе документов необходимых для получения РС и РВЭ.
Обращаем внимание, что согласно части 10 статьи 5.2 ГрК РФ, предъявление требований о получении в целях реализации проекта по строительству объекта капитального строительства документов, сведений, материалов, согласований, не включенных в Реестр документов, не допускается.
Вопрос:
В ходит ли ЦИМ и ИМ ОКС в состав Реестра документов, необходимых застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 статьи 5.2 ГрК РФ мероприятий при реализации проекта по строительству ОКС?
Ответ:
Согласно части 9 статьи 5.2 ГрК РФ, документы, сведения, материалы, согласования, предусмотренные нормативными правовыми актами Российской Федерации и необходимые застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 настоящей статьи мероприятий при реализации проекта по строительству ОКС, подлежат включению в Реестр таких документов, сведений, материалов, согласований, при этом, ЦИМ, ИМ ОКС с/без ЦИМ в составе текущей версии указанных документов, материалов и сведений в Реестре документов - не входит.
Сама проектная документация в текстовой и графической форме присутствует, а вот в форме ИМ ОКС и включаемых в нее сведений - нет.
Не смотря на то, что положениями части 5.3 статьи 49 ГрК РФ проектная документация и (или) результаты инженерных изысканий, а также иные документы, необходимые для проведения экспертизы проектной документации и (или) результатов инженерных изысканий, представляются в электронной форме, в том числе в форме информационной модели, наличие такой формы ПД как ИМ ОКС в Реестре документов, необходимых застройщику, техническому заказчику для выполнения предусмотренных частями 3-7 статьи 5.2 ГрК РФ мероприятий при реализации проекта по строительству ОКС - не значится (отсутствует). То же характерно и для ПД, передаваемой в составе документов необходимых для получения РС и РВЭ.
Обращаем внимание, что согласно части 10 статьи 5.2 ГрК РФ, предъявление требований о получении в целях реализации проекта по строительству объекта капитального строительства документов, сведений, материалов, согласований, не включенных в Реестр документов, не допускается.
Рубрика «Вопрос/Ответ»: Регламентирован ли срок включения сведений в ИМ ОКС в т.ч. виде ЦИМ и ИЦММ?
Вопрос:
Регламентирован ли срок включения сведений в ИМ ОКС в т.ч. данных, полученных в результате выполнения инженерных изысканий, представленных в цифровом объектно-пространственном виде (инженерных цифровых моделей местности), в форме электронных документов, представленных в цифровом объектно-пространственном виде (цифровых информационных моделей)?
Ответ:
В соответствии с пунктом 6 Правил ФиВ ИМ ОКС, утв. ПП РФ от 17.05.2024 г. N 614, сведения о фактическом выполнении работ в процессе осуществления инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции и эксплуатации ОКС включаются в ИМ ОКС после завершения выполнения таких работ и подписания соответствующих сведений, документов и материалов лицами, ответственными за их формирование, в том числе данных, полученных в результате выполнения инженерно-геодезических, инженерно-геологических, инженерно-гидрометеорологических, инженерно-экологических, инженерно-геотехнических изысканий, представленных в цифровом объектно-пространственном виде (инженерных цифровых моделей местности), в форме электронных документов, представленных в цифровом объектно-пространственном виде (цифровых информационных моделей).
Однако, срок включения вышеуказанных сведений в ИМ ОКС на текущий момент законодательно не регламентирован.
То же - см. Письмо Минстроя России от 07.08.2024 N 20838-ОГ/00.
Вопрос:
Регламентирован ли срок включения сведений в ИМ ОКС в т.ч. данных, полученных в результате выполнения инженерных изысканий, представленных в цифровом объектно-пространственном виде (инженерных цифровых моделей местности), в форме электронных документов, представленных в цифровом объектно-пространственном виде (цифровых информационных моделей)?
Ответ:
В соответствии с пунктом 6 Правил ФиВ ИМ ОКС, утв. ПП РФ от 17.05.2024 г. N 614, сведения о фактическом выполнении работ в процессе осуществления инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции и эксплуатации ОКС включаются в ИМ ОКС после завершения выполнения таких работ и подписания соответствующих сведений, документов и материалов лицами, ответственными за их формирование, в том числе данных, полученных в результате выполнения инженерно-геодезических, инженерно-геологических, инженерно-гидрометеорологических, инженерно-экологических, инженерно-геотехнических изысканий, представленных в цифровом объектно-пространственном виде (инженерных цифровых моделей местности), в форме электронных документов, представленных в цифровом объектно-пространственном виде (цифровых информационных моделей).
Однако, срок включения вышеуказанных сведений в ИМ ОКС на текущий момент законодательно не регламентирован.
То же - см. Письмо Минстроя России от 07.08.2024 N 20838-ОГ/00.
tk-servis.ru
Минстрой разъясняет: О формировании и ведении информационной модели объекта капитального строительства (ИМ ОКС)
подготовлен проект нового постановления взамен постановления N 1431
Рубрика «Вопрос/Ответ»: Допускается ли передача ИМ ОКС в ГИСОГД субъектов по частям?
Вопрос:
Допускается ли передача ИМ ОКС в уполномоченные на размещение в ГИСОГД органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления по частям, в том числе сформированных для отдельных стадий жизненного цикла ОКС?
Ответ:
ИМ ОКС направляется в ГИСОГД и подлежит дальнейшему хранению в ГИСОГД целиком. Направление частей ИМ ОКС, в том числе сформированных для отдельных стадий жизненного цикла ОКС, не предусмотрено.
То же - см. Письмо Минстроя России от 07.08.2024 N 20838-ОГ/00.э
Вопрос:
Допускается ли передача ИМ ОКС в уполномоченные на размещение в ГИСОГД органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления по частям, в том числе сформированных для отдельных стадий жизненного цикла ОКС?
Ответ:
ИМ ОКС направляется в ГИСОГД и подлежит дальнейшему хранению в ГИСОГД целиком. Направление частей ИМ ОКС, в том числе сформированных для отдельных стадий жизненного цикла ОКС, не предусмотрено.
То же - см. Письмо Минстроя России от 07.08.2024 N 20838-ОГ/00.э
tk-servis.ru
Минстрой разъясняет: О формировании и ведении информационной модели объекта капитального строительства (ИМ ОКС)
подготовлен проект нового постановления взамен постановления N 1431
Снимок экрана 2025—07—25 в 09.01.12.pdf
329.1 KB
Как описывать сведения сложного ОКС при формировании Задания на проектирование в формате xml?
Если вы формируете Задание на проектирование в форме электронного документа в формате xml (ЗнП.xml) в отношении т.н. сложного ОКС* с использованием личного кабинета на ЕЦПЭ ФАУ «ГГЭ» вероятнее всего вы столкнетесь неоднократно с сообщением «Проверка не пройдена».
При этом, в скаченном файле протокола с наименованием «Протоколе ошибок для ЗП N ГГГГ_ММ_ДД-ЗПХХХХХ» вы увидите следующее:
Раздел в котором обнаружена ошибка:
Местонахождение раздела:
Ошибка:
Восемь раз себя проверили, не понимаете в чем ошибка и что делать?
Сразу скажем - ошибка связана с издержками интерфейса, с его неинформативностью, а также в отсутствии ясности в части описания ошибки в протоколе.
В указанном случае, кроме проверки заполнения обязательных полей отмеченных красным символом «❄️ » проверьте правильность указания всех сведений в отношении сложного ОКС и входящих в него отдельных ОКС.
Пример порядка описания для сложного ОКС, который содержит в себе 2 и более ОКС:
- сначала заполняете раздел «Часть объекта - сложный объект (содержит в себе 2 и более объектов капитального строительства)»;
- затем заполняете «Часть объекта - объект капитального строительства» для каждого ОКС в составе сложно включая основной ОКС. При этом, в блоке «Часть объекта - сложный объект (содержит в себе 2 и более объектов капитального строительства)» после «Проектной мощности» заполняете «Составные части сложного объекта», далее еще отдельно по каждому заполняете «Часть объекта - объект капитального строительства».
Для наглядности - см. прилагаемые файлы скриншотов с учетом пройденной валидацией (в file.pdf проблемная область выделена цветными рамками).
___
* Сложный ОКС - объекты капитального строительства, предусмотренные проектной документацией, в том числе входящие в состав предприятия как имущественного комплекса, единого недвижимого комплекса или в состав сложного объекта (объекта, состоящего из нескольких объектов капитального строительства). Содержание понятия - см. Приказ Минстроя России от 03.06.2022 г. N 446/пр «Об утверждении формы разрешения на строительство и формы разрешения на ввод объекта в эксплуатацию».
#ЗнП, #XML, #Сложный_ОКС, #Часть_объекта, #Complex, #OKS
Если вы формируете Задание на проектирование в форме электронного документа в формате xml (ЗнП.xml) в отношении т.н. сложного ОКС* с использованием личного кабинета на ЕЦПЭ ФАУ «ГГЭ» вероятнее всего вы столкнетесь неоднократно с сообщением «Проверка не пройдена».
При этом, в скаченном файле протокола с наименованием «Протоколе ошибок для ЗП N ГГГГ_ММ_ДД-ЗПХХХХХ» вы увидите следующее:
Раздел в котором обнаружена ошибка:
"Составные части сложного объекта"
Местонахождение раздела:
"Документ: задание на проектирование/
[1]Содержимое документа/
[1]Требования к объекту капитального строительства/
[1]Объекты капитального строительства, входящие в состав объекта капитального строительства/
[1]Составные части сложного объекта"
Ошибка:
"Содержимое раздела 'Составные части сложного объекта' является неполным. Список ожидаемых элементов: '{Complex, OKS}'"
Восемь раз себя проверили, не понимаете в чем ошибка и что делать?
Сразу скажем - ошибка связана с издержками интерфейса, с его неинформативностью, а также в отсутствии ясности в части описания ошибки в протоколе.
В указанном случае, кроме проверки заполнения обязательных полей отмеченных красным символом «
Пример порядка описания для сложного ОКС, который содержит в себе 2 и более ОКС:
- сначала заполняете раздел «Часть объекта - сложный объект (содержит в себе 2 и более объектов капитального строительства)»;
- затем заполняете «Часть объекта - объект капитального строительства» для каждого ОКС в составе сложно включая основной ОКС. При этом, в блоке «Часть объекта - сложный объект (содержит в себе 2 и более объектов капитального строительства)» после «Проектной мощности» заполняете «Составные части сложного объекта», далее еще отдельно по каждому заполняете «Часть объекта - объект капитального строительства».
Для наглядности - см. прилагаемые файлы скриншотов с учетом пройденной валидацией (в file.pdf проблемная область выделена цветными рамками).
___
* Сложный ОКС - объекты капитального строительства, предусмотренные проектной документацией, в том числе входящие в состав предприятия как имущественного комплекса, единого недвижимого комплекса или в состав сложного объекта (объекта, состоящего из нескольких объектов капитального строительства). Содержание понятия - см. Приказ Минстроя России от 03.06.2022 г. N 446/пр «Об утверждении формы разрешения на строительство и формы разрешения на ввод объекта в эксплуатацию».
#ЗнП, #XML, #Сложный_ОКС, #Часть_объекта, #Complex, #OKS
Please open Telegram to view this post
VIEW IN TELEGRAM
Показатели по глобальному объёму инвестиционно-строительных проектов с BIM+IFC в мире и РФ
Показатели по глобальному объём инвестиционно-строительных проектов, реализуемых с BIM + IFC, в мире и на российском строительном рынке (01.01.2022 –25.07.2025):
Показатели по глобальному объём инвестиционно-строительных проектов, реализуемых с BIM + IFC, в мире и на российском строительном рынке (01.01.2022 –25.07.2025):
За 3.5-летний период (с 01 января 2022 г. по 25 июля 2025 г.) в странах-участниках buildingSMART реализовано проектов с технологиями BIM и открытым форматом IFC на сумму около 20 366 000 млн $. Совокупный объём всех инвестиционно-строительных проектов в России за тот же период составил 656 750 млн $. Сравнение: мировой BIM-портфель buildingSMART в 31-раз превышает российский рынок общего строительства.
🔥3
Forwarded from Всё про IFC
Разбираем техническое задание на ЦИМ. Выпуск 1
Приходится часто сталкиваться с такого рода заполнением классификационных требований (см. скрин).
Для различного рода элементов класс IFC не разбит на подтипы. А введение дополнительной классификации (например, КСИ), также на дает больше ясности.
🔍 Способы решения описаны тут. Из них можно порекомендовать эти:
1. Использование альтернативной классификации.
Если в вашем распоряжении есть классификатор, который наиболее подходит для ваших нужд, используйте его. В данном примере же использование КСИ только добавляет лишней работы и не дает результата.
2. Использование PredefinedType + ObjectType.
Мы наблюдаем, что сегодня мало действительно проработанных и структурированных классификаторов. Поэтому способ PredefinedType + ObjectType в текущих реалиях является наиболее безболезненным и универсальным решением.
С другой стороны, если Вы только в начале пути и вам достаточно базовой классификации, то и расписывать в задании подробную разбивку нет надобности.
👥 @IFC_ru
👥 @IFC_club
Приходится часто сталкиваться с такого рода заполнением классификационных требований (см. скрин).
Для различного рода элементов класс IFC не разбит на подтипы. А введение дополнительной классификации (например, КСИ), также на дает больше ясности.
1. Использование альтернативной классификации.
Если в вашем распоряжении есть классификатор, который наиболее подходит для ваших нужд, используйте его. В данном примере же использование КСИ только добавляет лишней работы и не дает результата.
2. Использование PredefinedType + ObjectType.
Мы наблюдаем, что сегодня мало действительно проработанных и структурированных классификаторов. Поэтому способ PredefinedType + ObjectType в текущих реалиях является наиболее безболезненным и универсальным решением.
С другой стороны, если Вы только в начале пути и вам достаточно базовой классификации, то и расписывать в задании подробную разбивку нет надобности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Об изменении Положений об охранных зонах объектов электроэнергетики, магистральных и технологических сетей, газораспределительных сетей
На публичное обсуждение размещены проекты постановлений Правительства РФ:
- об утверждении Положения об охранной зоне объектов электроэнергетики (объектов электросетевого хозяйства и объектов по производству электрической энергии) и о внесении изменений в некоторые акты Правительства РФ
(размещено 24.07.2025)
- об утверждении Положения о зонах минимальных расстояний до магистральных и технологических трубопроводов <газопроводов, нефтепроводов и нефтепродуктопроводов, трубопроводов для продуктов переработки нефти и газа>
(размещено 25.07.2025)
- об утверждении Положения об охранных зонах газопроводов газораспределительных сетей и о признании утратившим силу постановления Правительства Российской Федерации от 20 ноября 2000 г. № 878 «Об утверждении Правил охраны газораспределительных сетей» и отдельных положений некоторых актов Правительства РФ
(размещено - 25.07.2025).
На публичное обсуждение размещены проекты постановлений Правительства РФ:
- об утверждении Положения об охранной зоне объектов электроэнергетики (объектов электросетевого хозяйства и объектов по производству электрической энергии) и о внесении изменений в некоторые акты Правительства РФ
(размещено 24.07.2025)
- об утверждении Положения о зонах минимальных расстояний до магистральных и технологических трубопроводов <газопроводов, нефтепроводов и нефтепродуктопроводов, трубопроводов для продуктов переработки нефти и газа>
(размещено 25.07.2025)
- об утверждении Положения об охранных зонах газопроводов газораспределительных сетей и о признании утратившим силу постановления Правительства Российской Федерации от 20 ноября 2000 г. № 878 «Об утверждении Правил охраны газораспределительных сетей» и отдельных положений некоторых актов Правительства РФ
(размещено - 25.07.2025).
Forwarded from Лизунова | юрист в строительстве
Дополнительные работы в проектировании
По дополнительным работам в строительстве все более или менее понятно, много раз мы эту тему разбирали, смотрели судебные дела, обсуждали порядок взаимодействия сторон, в том числе с учетом особенностей контрактной системы.
❓ Существует ли такая проблема в проектировании? Ну конечно же существует. И часто подрядчики, выполняющие ПИР, испытывают некоторые трудности в квалификации ситуации, связанной с необходимостью выполнения дополнительных работ. И еще больше с тем, как получить за них оплату.
Гражданский кодекс дает определение дополнительным работам в статье 743 ГК «Техническая документация и смета» - это работы, не учтенные в технической документации. Это определение дополнительных работ имеет отношение непосредственно к строительным работам. В составе норм, регулирующих подрядные отношения по выполнению ПИР, прямого определения дополнительным работам нет. Техническая документация представляет собой результат проектирования, а мы рассматриваем ситуации, которые возникают до возникновения этого результата.
Конечно, в процессе правоприменения мы пользуемся всеми нормами 37 главы ГК о подряде, в том числе о допработах. Возьмите любой спор, когда-либо рассмотренный судами по дополнительным работам в проектировании, в каждом из них суды будут ссылаться на ст. 743 ГК. Потому что больше не на что. И правилами этой статьи проектировщикам действительно можно и нужно пользоваться.
Но вот как определить, является ли работа дополнительной, если мы говорим о ПИРах, с чем соотносить то, что вы считаете дополнительным?
Прежде всего с заданием на проектирование, со сметой, с показателями самого объекта. Хоть это и не техдокументация. Из всей массы споров по допработам в проектировании, которые я видела, могу выделить следующие причины появления дополнительных работ в ПИР:
1️⃣ Потребность в разработке дополнительных проектных решений, а иногда даже целых разделов, ранее не указанных в задании на проектирование.
2️⃣ Изменение натуральных показателей проектируемого объекта. Такое особенно часто наблюдаем в проектировании реконструкции и капремонтов, когда параметры проектируемого объекта уточняются на ходу. Ну или когда изначально вы взялись за проектирование 2-х этажного здания, а потом заказчик попросил третий или кровлю захотел эксплуатируемую.
3️⃣ Уточнение исходных данных в ходе проектирования. Например, нужно провести дополнительные мероприятия по изысканиям, или предусмотреть противоаварийные мероприятия, или изменить какие-либо показатели. Вот такое, пожалуй, чаще всего происходит.
Но не все ваши доделки и переделки можно признать допработами. Для того, чтобы понять, допработы это или нет, нужно правильно ответить всего на три вопроса:
🔵 являются ли причиной ваших дополнительных движений новые вводные от заказчика или иные объективные обстоятельства, а не ваши собственные ошибки?
🔵 достаточно ли четко мы можем отделить эти дополнительные работы от того, что написано в задании на проектирование и смете?
🔵 является ли невозможным достижение результата без выполнения этих дополнительных работ?
Если на все три вопроса ответ ДА, то вы имеете дело именно с дополнительными работами. Что с этим делать и как получить за них оплату от заказчика, обязательно расскажу. Буду признательна, если поделитесь своими примерами в комментариях, провожу небольшое исследование на эту тему.
➡️ Записаться на консультацию
По дополнительным работам в строительстве все более или менее понятно, много раз мы эту тему разбирали, смотрели судебные дела, обсуждали порядок взаимодействия сторон, в том числе с учетом особенностей контрактной системы.
Гражданский кодекс дает определение дополнительным работам в статье 743 ГК «Техническая документация и смета» - это работы, не учтенные в технической документации. Это определение дополнительных работ имеет отношение непосредственно к строительным работам. В составе норм, регулирующих подрядные отношения по выполнению ПИР, прямого определения дополнительным работам нет. Техническая документация представляет собой результат проектирования, а мы рассматриваем ситуации, которые возникают до возникновения этого результата.
Конечно, в процессе правоприменения мы пользуемся всеми нормами 37 главы ГК о подряде, в том числе о допработах. Возьмите любой спор, когда-либо рассмотренный судами по дополнительным работам в проектировании, в каждом из них суды будут ссылаться на ст. 743 ГК. Потому что больше не на что. И правилами этой статьи проектировщикам действительно можно и нужно пользоваться.
Но вот как определить, является ли работа дополнительной, если мы говорим о ПИРах, с чем соотносить то, что вы считаете дополнительным?
Прежде всего с заданием на проектирование, со сметой, с показателями самого объекта. Хоть это и не техдокументация. Из всей массы споров по допработам в проектировании, которые я видела, могу выделить следующие причины появления дополнительных работ в ПИР:
Но не все ваши доделки и переделки можно признать допработами. Для того, чтобы понять, допработы это или нет, нужно правильно ответить всего на три вопроса:
Если на все три вопроса ответ ДА, то вы имеете дело именно с дополнительными работами. Что с этим делать и как получить за них оплату от заказчика, обязательно расскажу. Буду признательна, если поделитесь своими примерами в комментариях, провожу небольшое исследование на эту тему.
Please open Telegram to view this post
VIEW IN TELEGRAM
Разработаны методические рекомендации по цифровой трансформации государственных корпораций и компаний с государственным участием
Протоколом президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 04.07.2025 N 29пр одобрены "Методические рекомендации по цифровой трансформации государственных корпораций и компаний с государственным участием".
Настоящие методические рекомендации определяют структуру и содержание стратегии цифровой трансформации, порядок мониторинга ее реализации, а также формы отчетности государственных компаний для представления в Минцифры России.
Рекомендации могут применяться любой организацией. Положения, содержащиеся в документе, носят рекомендательный характер, если иное не указано в законодательстве РФ, поручениях (указаниях) Президента РФ, поручениях и директивах Правительства РФ.
Стоит отметить, что рекомендации получились довольно проработанными.
Протоколом президиума Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 04.07.2025 N 29пр одобрены "Методические рекомендации по цифровой трансформации государственных корпораций и компаний с государственным участием".
Настоящие методические рекомендации определяют структуру и содержание стратегии цифровой трансформации, порядок мониторинга ее реализации, а также формы отчетности государственных компаний для представления в Минцифры России.
Рекомендации могут применяться любой организацией. Положения, содержащиеся в документе, носят рекомендательный характер, если иное не указано в законодательстве РФ, поручениях (указаниях) Президента РФ, поручениях и директивах Правительства РФ.
Стоит отметить, что рекомендации получились довольно проработанными.
Утвержден новый национальный стандарт по организационно-распорядительной документации
⚡️ ГОСТ Р 7.0.97-2025 Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов.
Настоящий стандарт распространяется на организационно-распорядительные документы: уставы, положения, правила, инструкции, регламенты, постановления, распоряжения, приказы, решения, протоколы, договоры, акты, письма, справки и др.
Определены состав реквизитов документов, правила их оформления, в том числе с применением информационных технологий; виды бланков, состав реквизитов бланков, схемы расположения реквизитов на документе; образцы бланков; правила создания документов.
Положения стандарта распространяются на документы на бумажном и электронном носителях.
Стандарт утвержден взамен ГОСТ Р 7.0.97-2016.
Вступает в действие - с 18.08.2025 г.
Настоящий стандарт распространяется на организационно-распорядительные документы: уставы, положения, правила, инструкции, регламенты, постановления, распоряжения, приказы, решения, протоколы, договоры, акты, письма, справки и др.
Определены состав реквизитов документов, правила их оформления, в том числе с применением информационных технологий; виды бланков, состав реквизитов бланков, схемы расположения реквизитов на документе; образцы бланков; правила создания документов.
Положения стандарта распространяются на документы на бумажном и электронном носителях.
Стандарт утвержден взамен ГОСТ Р 7.0.97-2016.
Вступает в действие - с 18.08.2025 г.
Please open Telegram to view this post
VIEW IN TELEGRAM
Рубрика «Обзор законопроектов»
Проект Федерального закона N 960721-8 "О внесении изменений в Федеральный закон "Об информации, информационных технологиях и о защите информации" (ред., принятая ГД ФС РФ в I чтении 17.07.2025).
В целях ликвидации правовых пробелов в области регулирования ИТ-инфраструктуры госорганов путем структурирования государственных информационных систем (далее - ГИС) и конкретизации их критериев законопроектом предлагается:
- ввести понятия "государственная информационная система", "государственная цифровая платформа", "государственный информационный ресурс", "ведомственный сервис";
- закрепить исчерпывающий перечень актов, являющихся основанием для создания государственных, муниципальных и ведомственных информационных систем (далее - ИС);
- определить виды государственных информационных систем (федеральные и региональные);
- создать правовые условия для привлечения органами госвласти к мероприятиям по созданию и развитию ГИС подведомственных им государственных бюджетных или автономных учреждений;
- установить, что исключительно на территории России должны будут размещаться технические средства, обеспечивающие функционирование ИС, используемых госорганами, органами местного самоуправления, органами управления государственными внебюджетными фондами, унитарными предприятиями и учреждениями, ППК, госкомпаниями и госкорпорациями, а также технические средства для функционирования государственных и муниципальных ИС;
- наделить Правительство РФ полномочиями по установлению требований к ГИС, общих требований к содержанию актов о создании, развитии (модернизации) и эксплуатации ГИС, а также дополнительных требований к ведомственным сервисам и входящим в состав государственных цифровых платформ ГИС;
- обязать операторов ИС, в которых обрабатывается информация государственных, муниципальных и ведомственных ИС, обеспечивать непрерывное взаимодействие с госсистемой обнаружения, предупреждения и ликвидации последствий компьютерных атак;
- установить тождественность дефиниций "модернизация" и "развитие" информационных систем;
- разрешить использовать ведомственные и иные ИС госучреждений, государственных внебюджетных фондов, госкомпаний и госкорпораций для обеспечения функционирования ГИС.
Проект Федерального закона N 960721-8 "О внесении изменений в Федеральный закон "Об информации, информационных технологиях и о защите информации" (ред., принятая ГД ФС РФ в I чтении 17.07.2025).
В целях ликвидации правовых пробелов в области регулирования ИТ-инфраструктуры госорганов путем структурирования государственных информационных систем (далее - ГИС) и конкретизации их критериев законопроектом предлагается:
- ввести понятия "государственная информационная система", "государственная цифровая платформа", "государственный информационный ресурс", "ведомственный сервис";
- закрепить исчерпывающий перечень актов, являющихся основанием для создания государственных, муниципальных и ведомственных информационных систем (далее - ИС);
- определить виды государственных информационных систем (федеральные и региональные);
- создать правовые условия для привлечения органами госвласти к мероприятиям по созданию и развитию ГИС подведомственных им государственных бюджетных или автономных учреждений;
- установить, что исключительно на территории России должны будут размещаться технические средства, обеспечивающие функционирование ИС, используемых госорганами, органами местного самоуправления, органами управления государственными внебюджетными фондами, унитарными предприятиями и учреждениями, ППК, госкомпаниями и госкорпорациями, а также технические средства для функционирования государственных и муниципальных ИС;
- наделить Правительство РФ полномочиями по установлению требований к ГИС, общих требований к содержанию актов о создании, развитии (модернизации) и эксплуатации ГИС, а также дополнительных требований к ведомственным сервисам и входящим в состав государственных цифровых платформ ГИС;
- обязать операторов ИС, в которых обрабатывается информация государственных, муниципальных и ведомственных ИС, обеспечивать непрерывное взаимодействие с госсистемой обнаружения, предупреждения и ликвидации последствий компьютерных атак;
- установить тождественность дефиниций "модернизация" и "развитие" информационных систем;
- разрешить использовать ведомственные и иные ИС госучреждений, государственных внебюджетных фондов, госкомпаний и госкорпораций для обеспечения функционирования ГИС.
Результаты анализа общих именований в пространстве имен XML-схем ПЗ, ЗнП, Заключения (данные ИИ)
Объекты анализа:
XML-схемы:
- explanatorynote-01-05.xsd (Пояснительная записка);
- DesignAssignment-01-00.xsd (Задание на проектирование);
- conclusion-01-03.xsd (Заключение).
В анализ включены все типы данных из указанных схем:
- ComplexType (сложные типы);
- SimpleType (простые типы);
- Attribute (атрибуты);
- Element (элементы);
- AttributeGroup (группы атрибутов);
- Group (группы элементов).
Результаты сравнения общих имен из принятого пространства имен по всем указанным xml-схемам:
Общие для всех указанных схем: 18 имен (9 ComplexType: tAddress, tDocument, tOrganization, tPerson, tPostAddress, tSignFile, tTEI, tTechnicalCustomer, tfile;
9 SimpleType: tCadastralNumber, tClimateDistrict, tEmail, tFunctionsClass, tGeologicalConditions, tSNILS, tSchemaVersion, tSeismicActivity, tWindDistrict)
Доля в каждой схеме:
- explanatorynote: 13.33% (18 из 135);
- DesignAssignment: 12.95% (18 из 139);
- conclusion: 18.75% (18 из 96).
Парные совпадения:
- для explanatorynote + DesignAssignment: 33 имен, из них 20 имен ComplexType (tAuthor, tCell, tClimateConditions, tEngineeringSurveyDocument, tImage, tIndustrialObject, tLandInfo, tLinearObject, tModel, tNonIndustrialObject, tOKS, tObjectParts, tProjectDocument, tProjectDocumentSection, tProjectDocumentSubSection, tResources, tRow, tSRO, tTable, tTextBlock) и 13 SimpleType (tAlignTypes, tBudgetLevel, tConstructionType, tDangerIndustrialClass, tDangerousAndComplex, tDocumentType, tFileChecksum, tFileFormat, tFileName, tFireDangerCategory, tPlacement, tPositiveDecimal, tUnique).
Доля:
- explanatorynote: 24.44% (33 из 135);
- DesignAssignment: 23.74% (33 из 139).
- для explanatorynote + conclusion: 18 имен, из них 4 ComplexType (tDocuments, tEngineeringSurveyDocuments, tfinanceSources, tWorkPerson;
14 SimpleType: non-empty-string, string100, string1000, string200, string50, string500, tDocumentType, tEngineeringSurveyType, tOGRNIP, tRegionsRF, tResponsibilityLevel, tShowDistrict, tYesNo, tYear).
Доля:
- explanatorynote: 13.33% (18 из 135)
- conclusion: 18.75% (18 из 96).
- для DesignAssignment + conclusion: 3 имени, из них 2 ComplexType (tStage, tClimateConditions) и 1 SimpleType (tObjectType).
Доля:
- DesignAssignment: 2.16% (3 из 139);
- conclusion: 3.12% (3 из 96).
Уникальные типы:
- explanatorynote: 66 имен (48.89%)
(44 ComplexType, 15 SimpleType, 6 Attribute, 1 Element);
- DesignAssignment: 85 имен (61.15%)
(28 ComplexType, 50 SimpleType, 2 AttributeGroup, 4 Group, 1 Element);
- conclusion: 57 имен (59.38%)
(28 ComplexType, 26 SimpleType, 2 Group, 1 Element).
Общие имена (хотя бы с одной схемой):
- explanatorynote: 69 имен (51.11%)
- DesignAssignment: 54 имени (38.85%)
- conclusion: 39 имен (40.62%)
Анализ по типам элементов:
ComplexType (сложные типы):
• общие для всех: 9 (11.69% от explanatorynote, 15.25% от DesignAssignment, 20.93% от conclusion);
• парные:
- explanatorynote + DesignAssignment: 20;
- explanatorynote + conclusion: 4;
- DesignAssignment + conclusion: 2.
SimpleType (простые типы):
• общие для всех: 9 (17.65% от explanatorynote, 12.33% от DesignAssignment, 18.00% от conclusion);
• парные:
- explanatorynote + DesignAssignment: 13;
- explanatorynote + conclusion: 14;
- DesignAssignment + conclusion: 1.
Другие типы (Attribute, Element, Group):
- нет пересечений между схемами из-за наличия уникальных:
• атрибутов - в explanatorynote - 6;
• групп - в DesignAssignment - 4 и в conclusion - 2;
• элементов: ExplanatoryNote - в explanatorynote; Document в DesignAssignment; Conclusion в conclusion.
Результаты сравнения - см. рис. (диаграммы Венна).
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
Объекты анализа:
XML-схемы:
- explanatorynote-01-05.xsd (Пояснительная записка);
- DesignAssignment-01-00.xsd (Задание на проектирование);
- conclusion-01-03.xsd (Заключение).
В анализ включены все типы данных из указанных схем:
- ComplexType (сложные типы);
- SimpleType (простые типы);
- Attribute (атрибуты);
- Element (элементы);
- AttributeGroup (группы атрибутов);
- Group (группы элементов).
Результаты сравнения общих имен из принятого пространства имен по всем указанным xml-схемам:
Общие для всех указанных схем: 18 имен (9 ComplexType: tAddress, tDocument, tOrganization, tPerson, tPostAddress, tSignFile, tTEI, tTechnicalCustomer, tfile;
9 SimpleType: tCadastralNumber, tClimateDistrict, tEmail, tFunctionsClass, tGeologicalConditions, tSNILS, tSchemaVersion, tSeismicActivity, tWindDistrict)
Доля в каждой схеме:
- explanatorynote: 13.33% (18 из 135);
- DesignAssignment: 12.95% (18 из 139);
- conclusion: 18.75% (18 из 96).
Парные совпадения:
- для explanatorynote + DesignAssignment: 33 имен, из них 20 имен ComplexType (tAuthor, tCell, tClimateConditions, tEngineeringSurveyDocument, tImage, tIndustrialObject, tLandInfo, tLinearObject, tModel, tNonIndustrialObject, tOKS, tObjectParts, tProjectDocument, tProjectDocumentSection, tProjectDocumentSubSection, tResources, tRow, tSRO, tTable, tTextBlock) и 13 SimpleType (tAlignTypes, tBudgetLevel, tConstructionType, tDangerIndustrialClass, tDangerousAndComplex, tDocumentType, tFileChecksum, tFileFormat, tFileName, tFireDangerCategory, tPlacement, tPositiveDecimal, tUnique).
Доля:
- explanatorynote: 24.44% (33 из 135);
- DesignAssignment: 23.74% (33 из 139).
- для explanatorynote + conclusion: 18 имен, из них 4 ComplexType (tDocuments, tEngineeringSurveyDocuments, tfinanceSources, tWorkPerson;
14 SimpleType: non-empty-string, string100, string1000, string200, string50, string500, tDocumentType, tEngineeringSurveyType, tOGRNIP, tRegionsRF, tResponsibilityLevel, tShowDistrict, tYesNo, tYear).
Доля:
- explanatorynote: 13.33% (18 из 135)
- conclusion: 18.75% (18 из 96).
- для DesignAssignment + conclusion: 3 имени, из них 2 ComplexType (tStage, tClimateConditions) и 1 SimpleType (tObjectType).
Доля:
- DesignAssignment: 2.16% (3 из 139);
- conclusion: 3.12% (3 из 96).
Уникальные типы:
- explanatorynote: 66 имен (48.89%)
(44 ComplexType, 15 SimpleType, 6 Attribute, 1 Element);
- DesignAssignment: 85 имен (61.15%)
(28 ComplexType, 50 SimpleType, 2 AttributeGroup, 4 Group, 1 Element);
- conclusion: 57 имен (59.38%)
(28 ComplexType, 26 SimpleType, 2 Group, 1 Element).
Общие имена (хотя бы с одной схемой):
- explanatorynote: 69 имен (51.11%)
- DesignAssignment: 54 имени (38.85%)
- conclusion: 39 имен (40.62%)
Анализ по типам элементов:
ComplexType (сложные типы):
• общие для всех: 9 (11.69% от explanatorynote, 15.25% от DesignAssignment, 20.93% от conclusion);
• парные:
- explanatorynote + DesignAssignment: 20;
- explanatorynote + conclusion: 4;
- DesignAssignment + conclusion: 2.
SimpleType (простые типы):
• общие для всех: 9 (17.65% от explanatorynote, 12.33% от DesignAssignment, 18.00% от conclusion);
• парные:
- explanatorynote + DesignAssignment: 13;
- explanatorynote + conclusion: 14;
- DesignAssignment + conclusion: 1.
Другие типы (Attribute, Element, Group):
- нет пересечений между схемами из-за наличия уникальных:
• атрибутов - в explanatorynote - 6;
• групп - в DesignAssignment - 4 и в conclusion - 2;
• элементов: ExplanatoryNote - в explanatorynote; Document в DesignAssignment; Conclusion в conclusion.
Результаты сравнения - см. рис. (диаграммы Венна).
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
👍2🔥1
Выводы и рекомендации по результатам анализа общих именований в пространстве имен XML-схем ПЗ, ЗнП, Заключения
Выводы:
1. Процент общих элементов для каждой схемы:
explanatorynote (Пояснительная записка):
- общие элементы со всеми схемами: 13.33% (18 из 135);
- элементы, общие хотя бы с одной схемой: 51.11% (69 из 135);
- уникальные элементы: 48.89% (66 из 135).
DesignAssignment (Задание на проектирование):
- общие элементы со всеми схемами: 12.95% (18 из 139);
- элементы, общие хотя бы с одной схемой: 38.85% (54 из 139);
- уникальные элементы: 61.15% (85 из 139).
conclusion (Заключение):
- общие элементы со всеми схемами: 18.75% (18 из 96);
- элементы, общие хотя бы с одной схемой: 40.62% (39 из 96);
- уникальные элементы: 59.38% (57 из 96).
2. Уровень совместимости между схемами:
- высокая совместимость (30-40% общих элементов):
explanatorynote ↔ DesignAssignment:
• 37.78% элементов explanatorynote встречаются в DesignAssignment;
• 36.69% элементов DesignAssignment встречаются в explanatorynote.
- средняя совместимость (20-30% общих элементов):
explanatorynote ↔ conclusion:
• 26.67% элементов explanatorynote встречаются в conclusion;
• 37.50% элементов conclusion встречаются в explanatorynote.
- низкая совместимость (<20% общих элементов):
DesignAssignment ↔ conclusion:
• 15.11% элементов DesignAssignment встречаются в conclusion;
• 21.88% элементов conclusion встречаются в DesignAssignment.
Единственный значимый общий тип: tObjectType.
3. Уровень уникальности пространства имен в xml-схемах:
- наибольшая уникальность имен элементов (>60%) в DesignAssignment - 61.15%;
- средняя уникальность имен элементов (50-60%) в conclusion - 59.38%;
- наименьшая уникальность имен элементов (<50%) в explanatorynote - 48.89%.
4. Предрасположенность к интеграции:
- все схемы имеют «ядро» из 18 базовых типов (13-19% от их состава);
- explanatorynote наиболее открыта для интеграции (51% элементов общие);
- DesignAssignment наиболее специализирована (61% уникальных элементов).
Рекомендации разработчикам сервисов по формированию электронных документов в формате xml на основе указанных xml-схем:
1. Для схем explanatorynote ↔ DesignAssignment - создать общий подмодуль с 33 совместно используемыми типами.
2. Для схем explanatorynote ↔ conclusion - разработать адаптер-модуль для 18 общих типов.
3. Для схем DesignAssignment ↔ conclusion - использовать минимальную интеграцию через базовые типы.
4. Оптимизация уникальных компонентов:
- сохранить уникальные типы DesignAssignment в специализированном пространстве имен;
- вынести общие типы conclusion в отдельный модуль для повторного использования;
- для explanatorynote разработать транслятор в форматы других схем.
Заключение:
Каждая схема сохраняет специализацию (48-61% уникальных элементов), но обеспечивает интеграцию через общее «ядро» (13-19% полностью общих типов). Наибольший потенциал для унификации наблюдается между explanatorynote и DesignAssignment.
Из отрицательного - в некоторых схемах по-прежнему присутствуют двойственные наименования в составе простых типов (см. пример для простого типа tAddress на рис.).
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
Выводы:
1. Процент общих элементов для каждой схемы:
explanatorynote (Пояснительная записка):
- общие элементы со всеми схемами: 13.33% (18 из 135);
- элементы, общие хотя бы с одной схемой: 51.11% (69 из 135);
- уникальные элементы: 48.89% (66 из 135).
DesignAssignment (Задание на проектирование):
- общие элементы со всеми схемами: 12.95% (18 из 139);
- элементы, общие хотя бы с одной схемой: 38.85% (54 из 139);
- уникальные элементы: 61.15% (85 из 139).
conclusion (Заключение):
- общие элементы со всеми схемами: 18.75% (18 из 96);
- элементы, общие хотя бы с одной схемой: 40.62% (39 из 96);
- уникальные элементы: 59.38% (57 из 96).
2. Уровень совместимости между схемами:
- высокая совместимость (30-40% общих элементов):
explanatorynote ↔ DesignAssignment:
• 37.78% элементов explanatorynote встречаются в DesignAssignment;
• 36.69% элементов DesignAssignment встречаются в explanatorynote.
- средняя совместимость (20-30% общих элементов):
explanatorynote ↔ conclusion:
• 26.67% элементов explanatorynote встречаются в conclusion;
• 37.50% элементов conclusion встречаются в explanatorynote.
- низкая совместимость (<20% общих элементов):
DesignAssignment ↔ conclusion:
• 15.11% элементов DesignAssignment встречаются в conclusion;
• 21.88% элементов conclusion встречаются в DesignAssignment.
Единственный значимый общий тип: tObjectType.
3. Уровень уникальности пространства имен в xml-схемах:
- наибольшая уникальность имен элементов (>60%) в DesignAssignment - 61.15%;
- средняя уникальность имен элементов (50-60%) в conclusion - 59.38%;
- наименьшая уникальность имен элементов (<50%) в explanatorynote - 48.89%.
4. Предрасположенность к интеграции:
- все схемы имеют «ядро» из 18 базовых типов (13-19% от их состава);
- explanatorynote наиболее открыта для интеграции (51% элементов общие);
- DesignAssignment наиболее специализирована (61% уникальных элементов).
Рекомендации разработчикам сервисов по формированию электронных документов в формате xml на основе указанных xml-схем:
1. Для схем explanatorynote ↔ DesignAssignment - создать общий подмодуль с 33 совместно используемыми типами.
2. Для схем explanatorynote ↔ conclusion - разработать адаптер-модуль для 18 общих типов.
3. Для схем DesignAssignment ↔ conclusion - использовать минимальную интеграцию через базовые типы.
4. Оптимизация уникальных компонентов:
- сохранить уникальные типы DesignAssignment в специализированном пространстве имен;
- вынести общие типы conclusion в отдельный модуль для повторного использования;
- для explanatorynote разработать транслятор в форматы других схем.
Заключение:
Каждая схема сохраняет специализацию (48-61% уникальных элементов), но обеспечивает интеграцию через общее «ядро» (13-19% полностью общих типов). Наибольший потенциал для унификации наблюдается между explanatorynote и DesignAssignment.
Из отрицательного - в некоторых схемах по-прежнему присутствуют двойственные наименования в составе простых типов (см. пример для простого типа tAddress на рис.).
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
👍2🔥1
Сравнение_XML_схем_Минстроя_России_на_предмет_наименований_идентичных.pdf
4.9 MB
Проблематика создания XML-схем Минстроя России
Мы часто слышим о качестве данных от официальных лиц Минстроя России. Одно дело нагнать данные через разработанные XML-схемы, а другое дело, если данные одинаковые, то почему они в разных XML-схемах звучат по разному (ЗнП.xsd, ПЗ.xsd, Заключение.xsd)…Понятно, что у каждой схемы свое назначение, и может быть свой подрядчик-разработчик. Но понятно и другое, что нужен единый подход к формированию пространства имен в каждой из XML-схем, если речь идет о одинаковых наборах данных.
Про учет правил по созданию XML-схем не говорим, подразумевая, что их нужно придерживаться, чтобы исключать штрафные круги при разработке сервисов по формированию электронных документов на основе XML-схем.
Пример сравнения пространства имен все типов из трех XML-схем от наших подписчиков (спасибо коллеге из Перми) к вопросу указанного отрицательного явления (см. файл).
Кого там пнуть надо в Департаменте цифрового развития Минстроя России? Трое без волос очевидно не вывозят тему.
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
Мы часто слышим о качестве данных от официальных лиц Минстроя России. Одно дело нагнать данные через разработанные XML-схемы, а другое дело, если данные одинаковые, то почему они в разных XML-схемах звучат по разному (ЗнП.xsd, ПЗ.xsd, Заключение.xsd)…Понятно, что у каждой схемы свое назначение, и может быть свой подрядчик-разработчик. Но понятно и другое, что нужен единый подход к формированию пространства имен в каждой из XML-схем, если речь идет о одинаковых наборах данных.
Про учет правил по созданию XML-схем не говорим, подразумевая, что их нужно придерживаться, чтобы исключать штрафные круги при разработке сервисов по формированию электронных документов на основе XML-схем.
Пример сравнения пространства имен все типов из трех XML-схем от наших подписчиков (спасибо коллеге из Перми) к вопросу указанного отрицательного явления (см. файл).
Кого там пнуть надо в Департаменте цифрового развития Минстроя России? Трое без волос очевидно не вывозят тему.
#XML, #ЗнП, #ПЗ, #Заключение, #explanatorynote_01_05,
#DesignAssignment_01_00,
#conclusion_01_03
😁7🔥4👀4💯3✍2🤯1
Forwarded from Artem Boiko
Бесплатное n8n приложение: Менеджмент проекта: универсальная система управления задачами и отчётами через телеграмм и таблицу
Универсальный автоматизированный бесплатный workflow на базе n8n, предназначенный для управления задачами и отчётами в любых отношениях "менеджер-исполнитель". Система использует Telegram-бота как удобный интерфейс для взаимодействия, Google Sheets (или можно подключить к любым другим таблицам) для хранения данных и автоматических напоминаний о задачах и отчётах.
🤖 Демо-бот менеджмента задач: https://t.me/ProjectDiaryBot
▪️ Таблица с задачами и отчётами: https://docs.google.com/spreadsheets/d/14V795nago6Qt7PpECflnuFSTdTvwo-fWEG_n83wgKug
▪️ Видео демонстрации работы: https://t.me/n8n_pipelines/1660
Система подходит для любых отношений "менеджер-исполнитель", где нужно ставить задачи, отслеживать выполнение и собирать отчёты. Система позволяет начать с минимального описания задачи (ID, название, исполнитель, время) и дополнять её реальными данными исполнителя (статус, фото, комментарии, GPS), что делает её универсальной для любых сценариев:
♻️ Строительство. Менеджер проекта и прорабы-подрядчики:
-> Менеджер: Назначает задачи (например, "Уложить плитку 10 м²") и запрашивает фотоотчёты (журнал работ, сварка).
<- Исполнитель: Отправляет статус ("выполнено"), фото и GPS стройплощадки.
Дополнения: Погода, комментарии о проблемах (например, "нет материалов").
♻️ Офис. Менеджер проекта и сотрудники-исполнители:
-> Менеджер: Назначает задачи ("Подготовить презентацию к 15:00") с приоритетами.
<- Исполнитель: Отвечает статусом ("готово") и прикрепляет файл/скриншот.
Дополнения: Комментарии о прогрессе или проблемах.
Начало обсуждения технического задания workflow менеджера задач n8n в группе "n8n Development": https://t.me/n8n_pipelines/831
Скачать полный n8n workflow и инструкции по установки бесплатного приложения:
📥 GitHub: https://github.com/boikoartem/Project-management-with-task-management-and-photo-reports
Англоязычная версия приложения:
📥 GitHub: Project Management: Universal Task and Report Management System
https://github.com/datadrivenconstruction/Project-management-n8n-with-task-management-and-photo-reports
Универсальный автоматизированный бесплатный workflow на базе n8n, предназначенный для управления задачами и отчётами в любых отношениях "менеджер-исполнитель". Система использует Telegram-бота как удобный интерфейс для взаимодействия, Google Sheets (или можно подключить к любым другим таблицам) для хранения данных и автоматических напоминаний о задачах и отчётах.
🤖 Демо-бот менеджмента задач: https://t.me/ProjectDiaryBot
▪️ Таблица с задачами и отчётами: https://docs.google.com/spreadsheets/d/14V795nago6Qt7PpECflnuFSTdTvwo-fWEG_n83wgKug
▪️ Видео демонстрации работы: https://t.me/n8n_pipelines/1660
Система подходит для любых отношений "менеджер-исполнитель", где нужно ставить задачи, отслеживать выполнение и собирать отчёты. Система позволяет начать с минимального описания задачи (ID, название, исполнитель, время) и дополнять её реальными данными исполнителя (статус, фото, комментарии, GPS), что делает её универсальной для любых сценариев:
♻️ Строительство. Менеджер проекта и прорабы-подрядчики:
-> Менеджер: Назначает задачи (например, "Уложить плитку 10 м²") и запрашивает фотоотчёты (журнал работ, сварка).
<- Исполнитель: Отправляет статус ("выполнено"), фото и GPS стройплощадки.
Дополнения: Погода, комментарии о проблемах (например, "нет материалов").
♻️ Офис. Менеджер проекта и сотрудники-исполнители:
-> Менеджер: Назначает задачи ("Подготовить презентацию к 15:00") с приоритетами.
<- Исполнитель: Отвечает статусом ("готово") и прикрепляет файл/скриншот.
Дополнения: Комментарии о прогрессе или проблемах.
Начало обсуждения технического задания workflow менеджера задач n8n в группе "n8n Development": https://t.me/n8n_pipelines/831
Скачать полный n8n workflow и инструкции по установки бесплатного приложения:
📥 GitHub: https://github.com/boikoartem/Project-management-with-task-management-and-photo-reports
Англоязычная версия приложения:
📥 GitHub: Project Management: Universal Task and Report Management System
https://github.com/datadrivenconstruction/Project-management-n8n-with-task-management-and-photo-reports
🔥3
vii-2025-06-105_web.pdf
927.1 KB
Механизм разработки РПСО и СТО должен быть усовершенствован
Статья из «Вестника инженерных изысканий», Июнь 2025 № 6 (105) стр. 16-23.
Прошло уже полтора год с момента принятия Федерального закона от 25 декабря 2023 г. № 653-ФЗ «О внесении изменений в Федеральный закон «Технический регламент о безопасности зданий и сооружений», а профессиональное сообщество строительной отрасли по-прежнему находится в процессе критического осмысления его основных положений.
Статья из «Вестника инженерных изысканий», Июнь 2025 № 6 (105) стр. 16-23.
Прошло уже полтора год с момента принятия Федерального закона от 25 декабря 2023 г. № 653-ФЗ «О внесении изменений в Федеральный закон «Технический регламент о безопасности зданий и сооружений», а профессиональное сообщество строительной отрасли по-прежнему находится в процессе критического осмысления его основных положений.
Больше всего опасений у инженерного, научного и экспертного сообщества вызывают именно РПСО. Поскольку законодательством предусмотрено привлечение к разработке таких документов научных организаций, ведущие центры оказались практически завалены предложениями. Причем связаны они не с инновациями, а с необходимостью обоснования спорных проектных решений, которые в обычном порядке не проходят экспертизу. Во многих случаях инициатива разработки исходит со стороны заказчика. При этом далеко не все ГИПы готовы ставить свою подпись под документом сомнительного содержания и требуют его оформления в виде СТО.
Специалисты экспертизы тоже не спешат брать на себя ответственность за те РПСО, которые к ним поступают. Поэтому стараются готовить как можно больше замечаний и требований дополнительного обоснования тех или иных решений, всячески затягивая процедуру утверждения.
Встречаются случаи, когда эксперты, наоборот, выступают инициаторами подготовки научных обоснований, когда видят, что в обычном порядке документация не имеет перспективы быть утвержденной в положенный срок.
Ученым ответственность за сомнительные с точки зрения требований безопасности решения тоже не нужна. Поэтому со стороны крупных научных центров начинают звучать предложения ввести практику утверждения РПСО в отраслевом техническом комитете.
По СТО ситуация не намного лучше. Ответственный секретарь ТК 465 «Строительство» Сергей Хвоинский отмечает, что из 15 СТО, поступивших на рассмотрение с момента вступления в силу новых норм законодательства, ни один не был подготовлен в соответствии с требованиями ГОСТ Р 1.4-2004. Наметилась тенденция, что документы идут с отклонениями от тех норм, которые прописаны в основополагающих стандартах в сводах правил. Поэтому технический комитет, собственно, и вынужден был разработать вышеупомянутые порядки в дополнение к требованиям приказа Минпромторга. В результате на сегодняшний день от разработчиков требуется, в частности, представление сопоставительного анализа требований, заложенных в СТО, с действующей нормативно-технической базой.
Очевидно, что если существующие фильтры в лице научных организаций, экспертизы и ГИПов не сработают, в отрасли начнется хаос. По выражению модератора конференции Азария Лапидуса, в отрасли складывается революционная ситуация наоборот - у нас верхи не хотят применять новые нормы закона, потому что не понимают как это делать, а низы не могут, потому что тоже не понимают, что с ними делать. Потому что многие известные в отрасли специалисты выступают против использования новых видов документов в качестве доказательной базы Технического регламента.
Могут ли физических лиц из НРС в области инженерных изысканий и архитектурно-строительного проектирования исключить из ошибок в ИМ ОКС с/без ЦИМ?
В феврале 2025 года на просторах интернета «ушел в плаванье» Аналитический отчет за 2024 год по практике исключения сведений о физических лицах из Национального реестра специалистов в области инженерных изысканий и архитектурно-строительного проектирования (Москва, 2025 г.).
Ну казалось бы, как в той песне: «По реке плывет кирпич, деревянный как стекло, ну и пусть себе плывет, нам не нужен пенопласт».
И если обратить внимание на причины, по которым на физических лиц из НРС в области инженерных изысканий и архитектурно-строительного проектирования подавались жалобы в НОПРИЗ, то среди таковых причин, связанных с ошибками допущенными в такой форме ПД как ИМ ОКС (с/без ЦИМ) вы не найдете.
Однако, анализируя знания, навыки и умения, изложенные в проф стандарте «Специалист по организации архитектурно-строительного проектирования», формально ошибки при формировании ПД в форме ИМ ОКС, в ряде случаев могут стать основанием для исключения ГИП/ГАП из НРС.
Приятного в этом мало.
Но потенциальная «собака» зарыта глубже.
Не смотря на то, что во всех случаях причины и решения были связаны с «привычной» текстовой и графической часть ПД, указанная тенденция имеет все шансы затронуть работу соответсвующих специалистов и с ПД в форме ИМ ОКС (с/без ЦИМ).
Поживем - увидим. А пока учимся на ошибках других.
Однако, если анализировать, те случаи которые описаны в Аналитическом отчете, и которые были связаны с «привычной» формой ПД и РИИ, то стоит обратить внимание, на ряд суждений, которые легли в основу обоснования принятого решения по исключению специалиста из НРС.
Т.е. в ряде случаев решение об исключении, на наш взгляд, основано на некорректно установленной причинно-следственной связи наступления тех или иных событий, положенных в обоснование причин исключения.
Так, к примеру, приведем цитату по содержанию указанного документа, вызывающую сомнения в корректности выстраивании причинно-следственной связи детерминированного вида (если изменить причину, то это обязательно приведёт к перемене следствия).
Т.е. проверяющих не смутила, действовавшая в период заключения договора на экспертизу (договор на ПИР от 03.08.2020, а договор на экспертизу очевидно значительно позднее заключен) редакция п.24 Положения, утв. ПП РФ от 05.03.2007 N 145 (в ред. ПП РФ от 31.12.2019 N 1948 - дейст. с 17.01.2020) которая устанавливала, что основаниями для отказа в принятии ПД и (или) РИИ, представленных на экспертизу, являются отсутствие в ПД разделов, которые подлежат включению в состав такой документации в соответствии с требованиями, установленными Положением, утв. ПП РФ от 16.02.2008 г. N 87?
А если заменить указанную причину на отсутствие отказа в приемке некомплектной документации…и попробовать выяснить, почему не был выдан отказ в рассмотрении представленной документации по существу…
И вот вся эта не очень убедительная история, пока в ряде случае, развивается в отношении привычной текстовой и графической частей ПД.
А если заглянуть чуть дальше…
И как только еще не догадались жалобы за наличие несоответствий в СДМ, включаемых в ИМ ОКС, в т.ч. и ЦИМ в ее составе на ГИПов, ГАПов подавать…
В общем в теории - исключение возможно, на практике скорее только в купе с более существенными причинами не связанными с формой документации.
Напомним, что согласно Приказа Минтруда России от 21.04.2022 N 228н, данные специалисты теперь должны обладать знаниями и уметь использовать ТИМ.
В феврале 2025 года на просторах интернета «ушел в плаванье» Аналитический отчет за 2024 год по практике исключения сведений о физических лицах из Национального реестра специалистов в области инженерных изысканий и архитектурно-строительного проектирования (Москва, 2025 г.).
Ну казалось бы, как в той песне: «По реке плывет кирпич, деревянный как стекло, ну и пусть себе плывет, нам не нужен пенопласт».
И если обратить внимание на причины, по которым на физических лиц из НРС в области инженерных изысканий и архитектурно-строительного проектирования подавались жалобы в НОПРИЗ, то среди таковых причин, связанных с ошибками допущенными в такой форме ПД как ИМ ОКС (с/без ЦИМ) вы не найдете.
Однако, анализируя знания, навыки и умения, изложенные в проф стандарте «Специалист по организации архитектурно-строительного проектирования», формально ошибки при формировании ПД в форме ИМ ОКС, в ряде случаев могут стать основанием для исключения ГИП/ГАП из НРС.
Приятного в этом мало.
Но потенциальная «собака» зарыта глубже.
Не смотря на то, что во всех случаях причины и решения были связаны с «привычной» текстовой и графической часть ПД, указанная тенденция имеет все шансы затронуть работу соответсвующих специалистов и с ПД в форме ИМ ОКС (с/без ЦИМ).
Поживем - увидим. А пока учимся на ошибках других.
Однако, если анализировать, те случаи которые описаны в Аналитическом отчете, и которые были связаны с «привычной» формой ПД и РИИ, то стоит обратить внимание, на ряд суждений, которые легли в основу обоснования принятого решения по исключению специалиста из НРС.
Т.е. в ряде случаев решение об исключении, на наш взгляд, основано на некорректно установленной причинно-следственной связи наступления тех или иных событий, положенных в обоснование причин исключения.
Так, к примеру, приведем цитату по содержанию указанного документа, вызывающую сомнения в корректности выстраивании причинно-следственной связи детерминированного вида (если изменить причину, то это обязательно приведёт к перемене следствия).
Подготовка специалистом ПД без необходимых исходных данных, направление на госэкспертизу результатов несостоявшегося проекта, подготовка документации с нарушениями требований технических регламентов явилось основанием для исключения сведений о таком специалисте из НРС.
…
Проект сдавался без некоторых разделов в документации, которые разрабатывались и сдавались уже после начала экспертизы.
Т.е. проверяющих не смутила, действовавшая в период заключения договора на экспертизу (договор на ПИР от 03.08.2020, а договор на экспертизу очевидно значительно позднее заключен) редакция п.24 Положения, утв. ПП РФ от 05.03.2007 N 145 (в ред. ПП РФ от 31.12.2019 N 1948 - дейст. с 17.01.2020) которая устанавливала, что основаниями для отказа в принятии ПД и (или) РИИ, представленных на экспертизу, являются отсутствие в ПД разделов, которые подлежат включению в состав такой документации в соответствии с требованиями, установленными Положением, утв. ПП РФ от 16.02.2008 г. N 87?
А если заменить указанную причину на отсутствие отказа в приемке некомплектной документации…и попробовать выяснить, почему не был выдан отказ в рассмотрении представленной документации по существу…
И вот вся эта не очень убедительная история, пока в ряде случае, развивается в отношении привычной текстовой и графической частей ПД.
А если заглянуть чуть дальше…
И как только еще не догадались жалобы за наличие несоответствий в СДМ, включаемых в ИМ ОКС, в т.ч. и ЦИМ в ее составе на ГИПов, ГАПов подавать…
В общем в теории - исключение возможно, на практике скорее только в купе с более существенными причинами не связанными с формой документации.
Напомним, что согласно Приказа Минтруда России от 21.04.2022 N 228н, данные специалисты теперь должны обладать знаниями и уметь использовать ТИМ.
Forwarded from Канал BIM INSPECTOR
Не пропустите наш вебинар «BIM Inspector: Настройка BIM стандартов, масок и правил проверки»
31 июля 2025 г.
13:00 (МСК)
Трансляция в Telegram-канале BIM Inspector
Максим Курбатов, руководитель продукта
*Ссылка на трансляцию будет отправлена на почту после регистрации
#BIM #вебинар #BIM_Inspector #Настройка_BIM_стандартов
Please open Telegram to view this post
VIEW IN TELEGRAM