За экспертным мнением мы обратились к кандидату технических наук, доценту кафедры строительства и городского хозяйства БГТУ им. В.Г. Шухова, генеральному директору ООО «ГК ЭПС» Павлу Сапожникову.

Павел Викторович, о цифровизации строительной отрасли заговорили не вчера и не сегодня. Что подразумевается под этим процессом? На что она нацелена?

Цель цифровизации — снижение себестоимости продукта как такового и сокращение сроков его производства с учётом всех основных и сопутствующих процедур.

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

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

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

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

Когда процессы будут отлажены, а недостатки выявлены, от части действий однозначно можно отказываться. Это приведёт к сокращению регламентных сроков. Более того, за их сокращение возможно бороться, измеряя величины в режиме реального времени. Такой подход нам позволит не просто соблюдать закон, но и, как в своё время сказал бывший премьер Виктор Черномырдин, «перевыполнять» его, ибо инструменты оптимизации у нас здесь же.

Наверняка потребуется целый банк информационных данных?

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

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

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

Здесь хочу вспомнить о BIM-моделях — объёмном моделировании зданий. То есть не проектировании как таковом, а моделировании, — создании полноценной объёмной модели со всеми функциями, какими она должна наделяться.

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

С чего же, на Ваш взгляд, начинать? Как это должно развиваться?

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

Второй блок — внедрение. Мы хоть и говорим, что у нас люди сегодня делают то же самое, что и вчера, только на компьютере, но они всё же должны обучиться. А любое обучение — это стресс. Причём в самом широком смысле слова. Потому очень часто на фазу внедрения приходится до 80% энергетических, финансовых и прочих затрат.

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

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

Это если говорить о цифровизации в целом.

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

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

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

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

В качестве более глубокой зарисовки. Инженер со специализированной программой в гаджете подходит, условно говоря, к узлу прохода коммуникаций через перекрытия. Его задача — зафиксировать, что работа принята и сделать фото, которое сразу же прикрепляется в базу данных. Если работа не принята, он ни в коем случае не должен ничего писать. У него открывается список замечаний, из которых необходимо выбрать те, что имеют отношение к данному узлу. Он не пишет замечания вручную и тем более не пишет: «Всё плохо, это переделать». После того, как замечания выбраны с помощью приложения, автоматически генерируется письмо подрядчику с указанием места узла и ссылками на норму, которая нарушена. Подобного рода подход и выбор замечаний «из-под флажка» убирает лишние «шумы», что положительно скажется на тех, кто выполняет свои функции качественно и хорошо, и идёт в минус для лодырей, так как любое промедление в работе сразу же фиксируется программой. Но из-за того, что мы все немножко лодыри и можем допустить слабину, такие системы вгоняют нас в стресс, что является барьером для их внедрения.

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

А как же свобода выбора и рыночные отношения, если всех и всё привязать к одной платформе?

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

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

В двух словах. Всё, что на сегодняшний день понимает заказчик, — это дизайн-проект. На уровне дизайн-проекта — какие окна, двери, стены, потолки, нравится - не нравится, — он хочет и готов принимать участие и решения. При этом, на данном этапе, как правило, дизайнеры и архитекторы тоже формируют первоначальную 3D-модель здания для демонстрации внешнего и внутреннего облика. Она — голая, и всего лишь содержит объёмные тела, у которых отсутствуют идентификационные признаки. А бизнес-проект, который мы реализуем, как раз нацелен на идентификацию этих отдельных тел, определение их по основным признакам — как элементов из существующих баз данных. Он ориентирован на объединение типовых серийных баз данных и применение необходимых инженерных решений, в том числе, влияющих на безопасность. То есть, сначала мы идентифицируем тела по их функционалу, после — по нагрузкам. Дальше — по прописанным алгоритмам, в зависимости от нагрузок и функционала, — подбираем традиционные серийные решения. После этого формируем корректную стоимость, затем — необходимые технологические процессы, связанные со строительством, параллельно набрасывая инженерные среды, которые там должны быть. Работу эту ведём совместно с БГТУ им. В. Г. Шухова, ибо написание корректных алгоритмов определения идентификационных признаков и перехода к инженерным решениям требуют элемента науки и живого студенческого потенциала.

Проект предполагает формирование исключительно интеграционной платформы с открытой архитектурой и ни в коем случае не замыкание на каких-то участках. Большинство элементов сегодня уже реализовано в рамках отдельных программ по закупкам, организации производства, по проектированию генпланов, по земляным массам, 1С, составлению смет и прочему. Остаётся интегрировать их на единую платформу.

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

Да, данная платформа по-прежнему не затрагивает области, регулируемые государством, хотя в процессе разработки всё может быть. Как я уже сказал, проект — с открытой архитектурой. Что-то новое добавляем и расширяем систему дальше, дальше и дальше.

То есть в идеале процесс цифровизации строительной отрасли Вам видится в создании такой полифункциональной адаптируемой под жизненные реалии платформы?

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

Источник информации: Бел.ру