Об авторе: Наталья Резина, директор портфеля проектов ООО «МетаПрайм».
«Вот есть же пример – сначала делают, смотрят, как это работает, а потом передают в ISO. У нас, к сожалению, сначала думают, а потом делают».
Участник чата
Весь прошлый год мы активно обсуждали нормативные документы, определяющие порядок ведения государственной информационной системы обеспечения градостроительной деятельности субъектов РФ (далее ГИСОГД региона), создание которых предписано ст.56 и 57 Градостроительного кодекса РФ с 2019 года.
2019 год был сумбурным, поскольку начало действовать требование по созданию ГИСОГД региона, но каких-либо требований к порядку ведения этих систем или функционалу не было, дело ограничивалось необходимостью построения ГИСОГД регионов на базе типовых решений из национального фонда алгоритмов и программ. Порядок ведения ГИСОГД региона появился с принятием постановления правительства РФ № 273 от 13.03.2020 и далее требования к составу данных (реестрам ГИСОГД) были сформулированы в приказе Минстроя России № 433/пр от 06.08.2020.
Несмотря на принятые нормативные документы, определяющие порядок ведения ГИСОГД, вопросов у регионов много, свидетельство этому – групповой чат в Telegram по этой теме, в котором участвуют представители регионов, Минстроя России и разработчиков систем. Как правило, вопросы связаны с созданием/ведением «цифрового контента» (данных системы) с использованием ГИСОГД, а также с оказанием государственных/муниципальных услуг с использованием этого самого контента.
Больным для регионов вопросом является наполнение систем данными, особенно с учётом того, что градостроительные документы, подлежащие внесению в ГИСОГД региона, и понятие «цифровой контент», на использование которого и нацелены эти системы, пока весьма далеки друг от друга – большой объём данных не имеет машиночитаемой формы, утверждённые карты представлены в большинстве случаев растровыми изображениями, а не векторными слоями; имеющиеся векторные данные не унифицированы (сформированы по разным правилам и имеют разную семантическую наполненность).
Наличие вопросов – свидетельство того, что и методологическое, и методическое обеспечение нуждается в дополнительной проработке. Это нормальный рабочий процесс, главное, чтобы он был синхронизирован с внедрением/эксплуатацией/развитием информационных систем. Тот же вопрос преобразования контента в цифровую форму требует, с одной стороны, методологической проработки – для чего и в каких случаях планируется использовать данные, с другой – необходимость разработки методик (стандартов) создания/ведения данных. Сейчас отсутствуют требования к машиночитаемым формам бо́льшей части документов, взять, к примеру, нормативы градостроительного проектирования, идущие в текстовой форме. При наличии машиночитаемых форм эти данные могли бы использоваться для предоставления справочно-информационных сервисов определения уровня обеспеченности и доступности объектов того или иного вида (например, достаточно ли в школах мест для детей из близлежащих домов; сколько требуется парковочных мест для запланированных к постройке многоэтажек). Исходя из того, какие задачи мы планируем решать с использованием тех или иных данных, можно определить структуру данных, в которую требуется разложить привычный текстовый документ.
Другой вопрос, который задают представители регионов – что же именно и в какой форме следует вести в разделе ГИСОГД «план наземных и подземных коммуникаций». С одной стороны, в приказе Минстроя России № 430 от 6.08.2020 определена структура сведений, по крайней мере, от неё можно отталкиваться, с другой – неясно, что собой представляет этот документ, как должна выполнятся его актуализация, да и является ли этот набор данных как таковой документом. Полагаю, для того, чтобы ответить на эти вопросы, надо понимать, как именно планируется использовать эти данные. Тогда станет ясно, является ли достаточным описание структуры реестров для ведения данных в этом разделе, приведённое сейчас в приказе Минстроя России № 433/пр.
Очевидно, что такая методологическая и методическая проработка не должна быть разовой акцией, поскольку фронт задач – не уменьшается, а значит и методическое обеспечение будет нуждаться в постоянной корректировке. Например, наверняка должны появиться рекомендации или указания по объёму сведений, подлежащих направлению и регистрации в ГИСОГД региона, которые исходно размещены в федеральной государственной информационной системе «Единый государственный реестр заключений» (ФГИС ЕГРЗ), должны ли при таком размещении в ГИСОГД региона дублироваться сами файлы проектной документации, на которые выдавалось заключение, или достаточно выписки (атрибутивные данные).
В апреле в Перми «Ростех» и правительство Пермского края провели стратегическую сессию по формированию идей для цифровой трансформации отраслей региона, в число которых была включена и строительная отрасль. По итогам сессии сформирован пул предложений (проектов). В число приоритетных проектов по направлению «строительство», которое мне довелось модерировать, по инициативе региона сформулирован проект «цифровая среда взаимодействия участников строительства», в котором одна из подсистем должна обеспечить дублирование файлов проектной документации ФГИС ЕГРЗ.
Дублирование не рационально? Да, не рационально, но на другой чаше весов – частые запросы из подразделений органов власти на получение проектной документации и технические проблемы с получением файлов проектных документов посредством СМЭВ из ФГИС ЕГРЗ, из-за чего сотрудники Госэкспертизы существенное время тратят на отработку таких запросов в ручном режиме и потому ратуют за создание регионального хранилища файлов проектной документации, возможно, в той же ГИСОГД региона.
Идти по пути дублированного хранения или же выбрать другой вариант – каждому региону придётся решать самостоятельно, если не будет сформулирован общий подход со стороны Минстроя России.
Уверена, что в ближайшее время станет востребованным также порядок размещения и последующего использования/предоставления данных из раздела ГИСОГД «Информационные модели объектов капитального строительства».
Есть ли понятные «айтишные» задачи, которые могут быть решены за счёт разработки/внедрения новых модулей или подсистем, без необходимости методологической проработки либо такая проработка уже проведена (бери и реализуй)?
Казалось бы, к таким задачам могут быть отнесены задачи оказания государственных/муниципальных услуг, в том числе с использованием данных ГИСОГД региона, или порталы ГИСОГД, размещение которых в Интернете для граждан и бизнеса определено в постановлении правительства РФ №279 от 13.03.2020. Однако, та же задача применения данных ГИСОГД при оказании услуг тоже может потребовать методологической проработки, по крайней мере в части «экспертной подсистемы», которая сейчас предусмотрена в описании целевых состояний государственных услуг (pdf). В указанных описаниях такой функционал назван «автоматизированными процедурами принятия решений о предоставлении услуг».
При решении подобных задач можно было бы воспользоваться методами, которые уже активно применяются, например, при принятии решений по услугам в сфере социальной защиты населения в системах «Электронный социальный реестр населения» (ЭСРН), внедрённых в более чем 20 регионах (в их число входит Санкт-Петербург, Московская, Омская, Саратовская, Кировская области). В ЭСРН реализована настраиваемая подсистема поддержки принятия решений, выполняющая автоматическую проверку с использованием настраиваемых правил состава и данных в документах, представленных заявителями, в том числе данных об иных социальных услугах, предоставляемых заявителю и зафиксированных в ЭСРН. Далее на основании представленных данных выполняется автоматическое принятие решений о предоставлении запрошенной услуги и размере начислений (выплат).
Такая подсистема поддержки принятия решений в ЭСРН применяется уже более 20 лет, тогда как в платформе государственных сервисов (ПГС), которая сейчас активно продвигается в регионы, заложена только автоматизированная проверка комплектности документов. Возможно, связано такое функциональное ограничение с отсутствием данных в машиночитаемой форме, которые стоило бы использовать при таких проверках. Напрашивается вывод, что проработку состава данных в машиночитаемой форме надо выполнять, держа в голове задачу автоматизации услуг и проверок, которые при оказании этих услуг нужны. И, конечно же, возникает вопрос – как ПГС будет взаимодействовать с региональными ведомственными системами (той же ГИСОГД региона), в которой будет размещена существенная часть данных для этих проверок? Иными словами, куда и как мы идём, и что делаем с создаваемыми системами.
Создание порталов ГИСОГД косвенно тоже связано с оказанием государственных и муниципальных услуг, поскольку представление сведений и данных о документах в региональной ГИСОГД позволяет заинтересованным лицам ознакомиться с градостроительными документами региона. Хотя при этом никто не отменил требование по размещению ряда утвержденных документов территориального планирования в федеральной государственной информационной системе территориального планирования (необходимость обеспечения такого доступа прописана в Градостроительном кодексе, например, в ст. 9 ч.9, ст.29.4 ч.7).
В постановлении правительства РФ № 279 от 13.03.2020 приведён перечень сведений, документов и материалов, содержащихся в ГИСОГД региона (читай: должны содержаться в ГИСОГД региона), доступ к которым осуществляется онлайн. Организация доступа, конечно, может быть реализована по-разному. Чаще возникает трактовка «создание сайта ГИСОГД региона». В целом логично, поскольку можно реализовать «одно окно» к градостроительным документам региона, тогда как сейчас органы местного самоуправления публиковать вынуждены такие документы на своем сайте в специальном разделе.
Опять же в постановлении правительства № 279 указана необходимость предоставления доступа к векторным моделям (картам), что влечёт необходимость создания на сайте геоинформационного компонента. Далеко не каждый орган местного самоуправления может такое «потянуть» финансово, целесообразнее сделать региональный сайт. Сейчас в регионах такие порталы начинают создаваться, в чём-то они похожи, в чём-то разнятся – пока идеи по реализации скорее относятся к творчеству разработчиков систем, бо́льшая часть порталов находится в стадии тестирования.
Портал ГИСОГД Ленинградской области
Портал ГИСОГД Самарской области
Портал ГИСОГД Приморского края
Портал ГИСОГД Республики Башкортостан
Портал РГИС территориального планирования Республики Саха (Якутия)
Тут тоже возникают вопросы, которые каждый регион трактует по-своему из-за отсутствия методических рекомендаций. Например, сведения о выданных разрешениях на строительство должны быть представлены в форме «векторных моделей (карты) с возможностью просмотра характеристик объектов, в том числе информации, содержащейся в разрешении на строительство». Видимо, это стоит трактовать как отображение на карте данных разрешения на строительство, которое в ГИСОГД региона лежит в машиночитаемой форме. Однако пока описание состава сведений для класса «Объект капитального строительства», приведённое в приказе Минстроя России № 433 от 06.08.2020, не отвечает описанию сведений в разрешении на строительство, которые определены приказом Минстроя России от 20.03.2018 № 153/пр «Об установлении требований к форматам предоставления сведений, содержащихся в разрешении на строительство и разрешении на ввод в эксплуатацию объекта капитального строительства». Например, не понятно, как должны быть представлены сведения об этажности объекта, если разрешение на строительство может быть выдано на несколько объектов, а этажность или площади описываются не числовыми атрибутами, а текстом.
Всё больше и чаще при обсуждении/создании автоматизированных информационных систем в государственных органах наблюдается тренд на централизацию – создание типового облачного решения на федеральном уровне, которое предлагается регионам для использования. Вопрос такого перехода на федеральные решения неоднозначный, наверное, стоит его обсуждать с участием пользователей других подобных систем, наприер, «Типовое облачное решение контрольно-надзорной деятельности» (ТОР КНД).
Независимо от того, в облаке ли находится система, надо понимать, в каком направлении развивается она и связанные с ней; какими сервисами эта система должна обрасти по дороге. Надо прорабатывать концептуально-архитектурные вопросы, и, конечно же, обеспечить для такой системы методическое сопровождение всех участников – операторов, пользователей, разработчиков. Пусть я буду ретроградом, однако принцип «вначале думаем, а потом делаем» считаю обязательным к соблюдению.
