G-TECH SUITE – первое российское платформенное облачное решение для строительных проектов

Не так давно на рынке появился продукт G‑Tech SUITE — первое российское платформенное облачное решение для строительных проектов, разработанное компанией «Джемини». Иван Гордиенко, руководитель проектов «Облачные решения для строительства» (CSD), поговорил с директором по продукту компании «Джемини» Ильей Кноповым, чтобы узнать о преимуществах предлагаемого решения, на кого оно ориентировано и какие задачи клиентов может решить.

Какие предпосылки появления продукта G‑Tech?

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

Отсутствие целостности системы и контроля на всех этапах проектирования и реализации объекта привело к созданию такой информационной концепции строительства, где можно будет легко вносить изменения и обновления, а также быстро извлекать требуемую информацию об объекте строительства или производства.

За основу такой «информационной модели» строительства можно взять различные принципы. Мы пошли по концепции BIM‑модели: она позволяет существенно упростить и внести прозрачность на всем жизненном пути стройки, так как «провязывает» все этапы между собой. Каждый элемент модели обогащается информацией на протяжении всего жизненного пути. Появляется прозрачность при прохождении любого элемента стройки (окна, двери, стены, трубы отопления, радиатора или насоса) по всем этапам — от начала проектирования до финальной сдачи и дальнейшей эксплуатации.

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

Такая цифровая информационная модель может использоваться для управления на протяжении всего жизненного цикла здания, как при передаче объекта, так и на стадии его эксплуатации. G‑Station — продукт компании «Джемини» — является альтернативой BIM‑360 в части хранения данных и workflow.

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

Наш продукт G‑Tech Suite — это облачная платформа для организации строительных проектов и работы с BIM‑моделью. На каждом этапе жизненного цикла проекта есть свои возможности и особенности.

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

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

Далее следует этап проверки проектных решений, на котором модель проверяется на соответствие требованиям заказчика. Для этого есть онлайн модуль «Проверки» доступный в той же среде. Также есть отдельный плагин для проектировщиков для проверки моделей не выходя из программы проектирования. С ним работа проектировщика объективно ускоряется на порядок.

Поговорим про следующий этап жизненного цикла — проверку спецификации, — на котором мы рассчитываем количество материалов для закупок, планирования работ и т.д. До сих пор нередко считается нормальным пользоваться для этого бумажной или квазибумажной (бумага в электронном виде — PDF и прочее) документацией. В случае небольших проектов время, затраченное специалистами на расчеты и проверку спецификации, наверное, можно как-то оправдать. Но как только сложность и объем проекта превышают определенный порог, расчеты с использованием обычной документации становятся слишком трудоемкими не только для регулярных оперативных подсчетов, но и для подготовки ВОР или проверки спецификации. Думаю, никому не хочется тратить 2-3-4 недели для получения оперативных цифр. Для этого часто используются различные инструменты для расчетов по данным в BIM‑моделях, что порой требует высокой квалификации специалистов.

Многие до сих пор использовали для подобных расчетов Navisworks — софт от западной компании, которая ушла с рынка РФ. У нашего модуля G‑Tech «Объемы» есть главное преимущество перед существующими инструментами: универсальность, удобство и простота работы. Мы его называем «Excel для строительства». Не требуется ставить специальный софт на компьютер — всё доступно через браузер, даже с планшета. Не требуется высокой квалификации. Первый расчет можно получить буквально за десять минут. С помощью модуля «Объемы» можно подготавливать объемы для осмечивания, ВОР, решать оперативные вопросы, например, службы ПТО. Модуль также позволяет при расчетах применять различные формулы и коэффициенты, что существенно расширяет область использования инструментария.

Также мы внедряем практику подготовки спецификации проектировщиком через модуль «Объемы». Если проектировщик готовит спецификацию в модуле, т.е. сразу в среде общих данных, то дальше ее не нужно перепроверять, воссоздавая в отдельном инструменте. Один раз собранные и проверенные данные переходят от этапа к этапу без дополнительных проверок внутри единой среды, что существенно экономит время и повышает прозрачность процесса. Нет лишних этапов экспорта и импорта данных в XLS/XML, что обычно приводит к потере прозрачности и целостности в данных.

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

Про функционал Вы рассказали очень подробно. А для кого непосредственно создавался G‑Tech? Мы знаем про СОД (G‑Station — прим.), который был разработан ранее. Он позволил отойти от использования Autodesk BIM 360, недоступного сейчас на российском рынке, и перевести все данные на свою платформу.

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

Раньше все работали в Excel, данные приходилось по сто раз перепроверять. То есть пользователь вносит вручную или выгрузкой в табличку какие-то цифры, а как проверить, откуда он их взял и правильно ли он их внес? Всё замыкается на человеке. Невозможно полностью доверять этим данным в силу «разорванности» в процессе их передачи. Поэтому появилась идея: все данные с каждого этапа жизненного цикла хранить в привязке к конкретным элементам информационной модели. Тем более что BIM‑модель в большинстве случаев готовит проектировщик на стадии проектирования.

Уход с нашего рынка Autodesk BIM 360, с одной стороны, освободил нишу СОД, где в большинстве своем царил BIM360. С другой стороны, мы можем за счет разработки собственной СОД сделать гораздо более удобный продукт для пользователей и покупателей с учетом специфики наших заказчиков и российского рынка. И, кроме того, будет дополнительный эффект от синергии собственной СОД и всеми остальными модулями, что позволит сделать СОД гораздо более универсальным и удобным инструментом для наших заказчиков, который закрывает вообще весь жизненный цикл проекта — от проектирования до сдачи объекта и эксплуатации.

В целом мы ориентируемся на застройщиков, инженеров, руководителей строительных компаний, инженеров ПТО, специалистов технического и строительного контроля, сметчиков и т.д.

То есть все модули, которые есть в платформе, будут всегда ссылаться на папки-хранилища? Один раз модель или документ положили в определенную папку, и другие модули могут к ней подключаться?

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

Расскажите, пожалуйста, про ядро платформы. Что лежит в ее основе?

Могу сказать, что это полностью собственная разработка компании «Джемини», но не будем здесь уходить в технические подробности.

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

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

Допустим, я подрядчик-строитель (внешняя компания или собственное подразделение), и я готов сдать какие-либо конструкции или объемы работ заказчику, то через модуль «Стройконтроль» я отмечаю эти конструкции прямо на 2D-чертеже или в 3D-модели либо из списка как готовые к приемке. При этом у меня отсутствует возможность предъявить одни и те же объемы или конструкции несколько раз. Теперь вся система и все модули понимают, что эти элементы предъявлены к выполнению и готовы к приемке.

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

Если, допустим, настроена интеграция через API к 1С, то документы могут быть сформированы автоматически, и проверять и подтверждать объемы не нужно. Как я уже сказал, дважды предъявить к выполнению одни и те же объемы нельзя.

Я правильно понимаю, что API открытый и, соответственно, можно строить интеграции с какими-то решениями, у которых тоже открытый API?

API у нас есть, и им можно сейчас пользоваться на любом этапе, так как с точки зрения архитектуры любой наш модуль имеет API для взаимодействия. Например, можно сделать интеграцию на этапе тендеров: в учетную систему заказчика передавать информацию по составу соглашения (работы/объемы) с конкретным подрядчиком, после того как прошла тендерная процедура, выбран конкретный подрядчик и необходимо заключить договор.

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

А где находятся сервера, где храните информацию? Есть варианты хранения данных на серверах заказчика?

Мы предлагаем два варианта поставки нашей платформы: это облачные решения, которые развернуты на серверах Яндекса, и здесь нет ограничений по масштабу. Второй вариант — развертывание платформы в закрытом контуре заказчика (при работе с теми, у кого есть определенные требования к информационной безопасности).

Мы знаем, что уже много клиентов использует G‑Station в работе. Какие самые запоминающиеся кейсы есть в вашем портфолио?

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

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

Не только на текущих — мы смотрим довольно широко. Сам по себе BIM находится на стадии формирования, поэтому мы смотрим в будущее и снимаем как с текущих, так и с потенциальных клиентов боли и проблемы на всех стадиях проекта.

А каких ценностей Вы придерживаетесь при разработке своего софта?

С точки зрения ценности компании мы стараемся придерживаться продуктового подхода, который исходит из болей клиента. Есть подход Data Driven, который мы активно стараемся развивать. То есть мы ориентируемся не только на боли клиента, но и на то, как мы решаем задачи и решаем ли мы их в действительности. Мы стараемся измерять тот результат, который доносим до клиента, и не делать фичу ради фичи, ведь это бессмысленная история.

Илья, спасибо Вам за уделенное время и за развернутые ответы. Подведем итоги: Вы взяли самое лучшее из BIM 360 Docs — СОД, добавили интуитивно понятный, привычный многим интерфейс и возможность проверять и снимать объемы с BIM‑модели в веб-браузере, приправили функционалом для стройконтроля и завернули в упаковку под названием G‑Tech Suite.

Желаем Вам удачи в дальнейшем развитии ваших продуктов!