Среда общих данных BIM-проектов: интересы девелоперов

На какие системы ориентироваться и что учитывать при их внедрении? В этой статье мы обобщим наш опыт по созданию среды общих данных (далее — СОД) у девелоперов жилой и коммерческой недвижимости с использованием программного обеспечения Pilot-BIM/Pilot-ICE (разработка АСКОН). Большинство проектов реализовано «с нуля», когда у заказчиков не было единой СОД для работы с BIM-моделями, технической и организационной документацией. В их числе внедрение системы управления проектной документацией в АО «ТПС Недвижимость» — проект победил в конкурсе GlobalCIO в номинации «Строительство/Недвижимость».

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

Например, АО «ТПС Недвижимость», как технический заказчик, хранит в Pilot-ICE Enterprise проектную и рабочую, иными словами, эксплуатационную документацию по торговым центрам, которые находятся у него в управлении. Поэтому к системе подключаются эксплуатирующие организации, обслуживающие эти объекты. У арендаторов торговых центров и технических служб тоже есть доступ к документации через web-интерфейс. К единой среде присоединяются те из них, кто занимают большие площади арендуемых помещений, делают внутреннюю планировку на этих площадях, разрабатывают документацию по ней и согласуют эту документацию в том числе с управляющей компанией.

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

В техническом плане для девелоперских компаний традиционно применяется следующая архитектура решения: сервер размещается у компании-владельца, а клиентское приложение Pilot-BIM/Pilot-ICE Enterprise/Pilot-ICE/Pilot-ECM устанавливается у всех участников проекта — как у застройщика или технического заказчика, так и у подрядной проектной или строительной организации.

В случае «ТПС Недвижимость» компании, которые присоединяются к системе на короткий период времени, например, арендаторы торговых площадей, взаимодействуют с системой через web-интерфейс. В свободном доступе есть web-клиент, которым можно воспользоваться для подключения к базе данных и загрузки информации. С точки зрения администрирования это гораздо легче, ведь в данном случае не требуется настройка десктопного приложения. Для такого подключения мы предоставляем минимальную инструкцию, и клиенты заходят в систему, где могут просматривать электронные документы и замечания к ним, скачивать и подписывать их, самостоятельно загружать исходные файлы в систему. Полнофункциональный же Web-клиент для решений Pilot мы выпустим в конце 2023 - начале 2024 года.

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

Обычно бизнес-процесс в девелоперских компаниях протекает по одной из двух схем:

• генподрядчик девелоперской компании подключён к СОД и размещает разработанную документацию в системе самостоятельно;
• генподрядчик девелоперской компании не подключён к СОД и тогда передаёт разработанную документацию представителю девелопера (технического заказчика), который размещает документацию в системе и запускает процессы проверки-согласования.

Во втором случае работа с документацией включает три этапа:

Этап 1. Входной контроль: подрядчик присылает проектную документацию, а технический заказчик проверяет её комплектность и качество.

Этап 2. Эксперты проверяют разделы проекта, оставляют замечания на документе.

Этап 3. Главный инженер принимает решение о том, какой статус присвоить документации. Если документ отклонён, его нужно переделывать полностью и вновь загружать на проверку в систему. А если согласован с некритичными замечаниями, например, к оформлению, проектировщик получает уведомление и приводит документ в порядок. В этом случае, так как стройка идёт параллельно, документ выдаётся на площадку со статусом «согласован с замечаниями». Если замечаний нет или они были устранены, документ согласуется окончательно.

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

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

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

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

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

Обычно девелоперы используют функциональность выдачи заданий, запуска процессов, проверки и согласования документов. Это базовый набор возможностей коробочного решения Pilot-BIM/Pilot-ICE Enterprise/Pilot-ICE/Pilot-ECM.

Для АО «ТПС Недвижимость» мы разработали дополнительные модули: модуль «Матрица согласований», автоматические штампы на документы и специальные отчёты. «Матрица согласований» была создана взамен огромного количества шаблонов процессов, которые нужно было администрировать. Штамп «В производство работ» подтверждает, что проектная документация проверена. А с помощью отчётов по замечаниям пользователь может построить отчёт, увидеть в нём все замечания и сохранить его как документ.

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

Также она содержит индивидуальные типы заданий:
—«входной контроль»;
—«проверка»;
—«контрольное задание».

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

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