Девелопер отвечает за реализацию полного цикла работ по созданию объекта капитального строительства: от оценки необходимых инвестиций до сдачи в эксплуатацию. Проходя этот путь, девелоперская компания может самостоятельно выполнять функции проектировщика, застройщика и эксплуатанта или работать в связке со сторонними организациями. Чаще встречается второй вариант, поэтому в организации единого информационного пространства у девелоперов есть свои особенности. Использует ли компания информационную модель (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 года.
Администрированием после развёртывания занимается персонал владельца системы, а мы со своей стороны проводим обучение, консультируем и оказываем техническую поддержку.
В случае «ТПС Недвижимость» компании, которые присоединяются к системе на короткий период времени, например, арендаторы торговых площадей, взаимодействуют с системой через web-интерфейс. В свободном доступе есть web-клиент, которым можно воспользоваться для подключения к базе данных и загрузки информации. С точки зрения администрирования это гораздо легче, ведь в данном случае не требуется настройка десктопного приложения. Для такого подключения мы предоставляем минимальную инструкцию, и клиенты заходят в систему, где могут просматривать электронные документы и замечания к ним, скачивать и подписывать их, самостоятельно загружать исходные файлы в систему. Полнофункциональный же Web-клиент для решений Pilot мы выпустим в конце 2023 - начале 2024 года.
Администрированием после развёртывания занимается персонал владельца системы, а мы со своей стороны проводим обучение, консультируем и оказываем техническую поддержку.
Бизнес-процессы девелопера в СОД
Обычно бизнес-процесс в девелоперских компаниях протекает по одной из двух схем:
Во втором случае работа с документацией включает три этапа:
Этап 1. Входной контроль: подрядчик присылает проектную документацию, а технический заказчик проверяет её комплектность и качество.
Этап 2. Эксперты проверяют разделы проекта, оставляют замечания на документе.
Этап 3. Главный инженер принимает решение о том, какой статус присвоить документации. Если документ отклонён, его нужно переделывать полностью и вновь загружать на проверку в систему. А если согласован с некритичными замечаниями, например, к оформлению, проектировщик получает уведомление и приводит документ в порядок. В этом случае, так как стройка идёт параллельно, документ выдаётся на площадку со статусом «согласован с замечаниями». Если замечаний нет или они были устранены, документ согласуется окончательно.
- генподрядчик девелоперской компании подключён к СОД и размещает разработанную документацию в системе самостоятельно;
- генподрядчик девелоперской компании не подключён к СОД и тогда передаёт разработанную документацию представителю девелопера (технического заказчика), который размещает документацию в системе и запускает процессы проверки-согласования.
Во втором случае работа с документацией включает три этапа:
Этап 1. Входной контроль: подрядчик присылает проектную документацию, а технический заказчик проверяет её комплектность и качество.
Этап 2. Эксперты проверяют разделы проекта, оставляют замечания на документе.
Этап 3. Главный инженер принимает решение о том, какой статус присвоить документации. Если документ отклонён, его нужно переделывать полностью и вновь загружать на проверку в систему. А если согласован с некритичными замечаниями, например, к оформлению, проектировщик получает уведомление и приводит документ в порядок. В этом случае, так как стройка идёт параллельно, документ выдаётся на площадку со статусом «согласован с замечаниями». Если замечаний нет или они были устранены, документ согласуется окончательно.
Компании ведут не только рабочую, но и исполнительную документацию — её передают со стройки и тоже размещают в системе. Для проверенной и согласованной документации также важно структурированное хранение, которое поможет в её последующем поиске.
СОД девелопера отличается подходом к структуре хранения, так как в отличие от проектной организации девелоперы не заинтересованы в структурировании данных по проектам, им сразу нужен готовый удобный вариант, соответствующий специфике их деятельности. Им привычнее работать по этапам проектирования и строительства, а не по традиционным для проектных компаний зданиям или основным комплектам. На первом этапе это может быть, например, первичная концепция: тендерная документация, к которой они подключают потенциальных подрядчиков проектирования и получают от них предложения. Второй стадией является разработка проектной документации и т. д.
Проектная документация может храниться по объектам. Но даже в этом случае структура данных девелоперского проекта строится иначе, нежели в проектных организациях. Например, у одного из наших заказчиков в управлении находятся несколько региональных аэропортов с объектами, по которым ведутся работы. Если аэропорт небольшой, то он выступает как один объект со зданиями аэропорта, взлётно-посадочными полосами и площадкой аэродрома. В структуре проекта в Pilot-ICE заводятся два подобъекта — аэропорт и аэродром, каждый из которых имеет свой жизненный цикл, свои стадии тендерной и проектно-сметной документации.
Помимо проектной документации в системе также хранится дополнительная: запросы на изменение материалов, информационные письма и служебные записки, касающиеся рабочей и проектной документации.
Иногда для контроля достоверности данных используют специализированные модули. К примеру, модуль проверки документации по QR-коду помогает контролировать версии рабочей документации, ведь на стройплощадке необходима актуальная и согласованная. Специалист может отсканировать QR-код и увидеть на экране смартфона, какой статус имеет распечатанный лист: «согласован», «согласован с замечаниями» или «не согласован».
СОД девелопера отличается подходом к структуре хранения, так как в отличие от проектной организации девелоперы не заинтересованы в структурировании данных по проектам, им сразу нужен готовый удобный вариант, соответствующий специфике их деятельности. Им привычнее работать по этапам проектирования и строительства, а не по традиционным для проектных компаний зданиям или основным комплектам. На первом этапе это может быть, например, первичная концепция: тендерная документация, к которой они подключают потенциальных подрядчиков проектирования и получают от них предложения. Второй стадией является разработка проектной документации и т. д.
Проектная документация может храниться по объектам. Но даже в этом случае структура данных девелоперского проекта строится иначе, нежели в проектных организациях. Например, у одного из наших заказчиков в управлении находятся несколько региональных аэропортов с объектами, по которым ведутся работы. Если аэропорт небольшой, то он выступает как один объект со зданиями аэропорта, взлётно-посадочными полосами и площадкой аэродрома. В структуре проекта в Pilot-ICE заводятся два подобъекта — аэропорт и аэродром, каждый из которых имеет свой жизненный цикл, свои стадии тендерной и проектно-сметной документации.
Помимо проектной документации в системе также хранится дополнительная: запросы на изменение материалов, информационные письма и служебные записки, касающиеся рабочей и проектной документации.
Иногда для контроля достоверности данных используют специализированные модули. К примеру, модуль проверки документации по QR-коду помогает контролировать версии рабочей документации, ведь на стройплощадке необходима актуальная и согласованная. Специалист может отсканировать QR-код и увидеть на экране смартфона, какой статус имеет распечатанный лист: «согласован», «согласован с замечаниями» или «не согласован».
Конфигурация Pilot для девелоперов
Обычно девелоперы используют функциональность выдачи заданий, запуска процессов, проверки и согласования документов. Это базовый набор возможностей коробочного решения Pilot-BIM/Pilot-ICE Enterprise/Pilot-ICE/Pilot-ECM.
Для АО «ТПС Недвижимость» мы разработали дополнительные модули: модуль «Матрица согласований», автоматические штампы на документы и специальные отчёты. «Матрица согласований» была создана взамен огромного количества шаблонов процессов, которые нужно было администрировать. Штамп «В производство работ» подтверждает, что проектная документация проверена. А с помощью отчётов по замечаниям пользователь может построить отчёт, увидеть в нём все замечания и сохранить его как документ.
Для АО «ТПС Недвижимость» мы разработали дополнительные модули: модуль «Матрица согласований», автоматические штампы на документы и специальные отчёты. «Матрица согласований» была создана взамен огромного количества шаблонов процессов, которые нужно было администрировать. Штамп «В производство работ» подтверждает, что проектная документация проверена. А с помощью отчётов по замечаниям пользователь может построить отчёт, увидеть в нём все замечания и сохранить его как документ.
Из опыта реализованных проектов сформировалась специализированная конфигурация Pilot для девелоперов. Первая её особенность заключается в том, что структура проектов в ней адаптирована под строительство, а не проектирование, и документация хранится по этапам реализации проекта, учитывая таким образом специфику деятельности девелоперов.
Также она содержит индивидуальные типы заданий:
—«входной контроль»;
—«проверка»;
—«контрольное задание».
Каждый из этих типов настроен под определённый процесс работы с документацией.
В процессе внедрения мы дополняем конфигурацию, подстраиваем под конкретного заказчика и запускаем в применение. Таким образом, у нас есть готовое, проверенное практикой решение, которое мы предлагаем девелоперским организациям. Процесс старта с этой точки я вижу достаточно эффективным, ведь он экономит временные и интеллектуальные ресурсы компаний.
Также она содержит индивидуальные типы заданий:
—«входной контроль»;
—«проверка»;
—«контрольное задание».
Каждый из этих типов настроен под определённый процесс работы с документацией.
В процессе внедрения мы дополняем конфигурацию, подстраиваем под конкретного заказчика и запускаем в применение. Таким образом, у нас есть готовое, проверенное практикой решение, которое мы предлагаем девелоперским организациям. Процесс старта с этой точки я вижу достаточно эффективным, ведь он экономит временные и интеллектуальные ресурсы компаний.
Автор: Данил Пикалов, руководитель проектов АСКОН-Центральная Россия
