Средний

8 мин

5

Привет! Меня зовут Дарья Царёва, BIM-менеджер Sminex, и я веду в компании управление архитектурными данными из BIM-моделей и их автоматизацию. В этой статье я расскажу вам о нашем опыте работы с такими данными, как технико-экономические показатели проекта.

ЧТО ДЛЯ НАС ТЭП

В девелоперском проекте технико-экономические показатели — это не просто таблица с площадями. Это данные, на которые завязано множество подразделений и управленческих решений внутри компании.

Но в реальности ТЭП часто живут не как данные, а как набор файлов: Excel, PDF, письма, выгрузки из Revit, ручные таблицы с названиями вроде «финал_2_точнофинал_260101».

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

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

С КАКОЙ ПРОБЛЕМОЙ МЫ СТОЛКНУЛИСЬ

В Sminex технико-экономическими показателями занимается отдельное подразделение. Коллеги пришли к нам с проблемой: на корректировки уходит уйма времени. На стадии П каждого проекта эксперты тратили в среднем около 350 часов на проверку ТЭП.

Несмотря на большое количество итераций проверки (в среднем 13 за стадию П), ведомости от проектировщиков приходили с ошибками и разрозненно.

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

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

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

Excel удобен. И честно, он никуда полностью не исчезнет. Вопрос не в том, чтобы запретить Excel, а в том, чтобы перестать считать его источником правды там, где данные должны быть проверяемыми и версионными.

И мы поняли, что BIM-модель — это то, что нам поможет сделать этот процесс проще и прозрачнее.

КАК ЭТО МОЖНО РЕШИТЬ

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

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

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

А В ЧЁМ ИДЕЯ

Идея инструмента «ТЭП Контроль» появилась не как желание «сделать ещё одну базу данных».

Задача была другая — разработать управляемый контур, где ТЭП можно не просто посчитать, а проверить, подтвердить, сравнить, передать дальше и всегда понимать, почему они изменились.

Если коротко, «ТЭП Контроль» — это связка веб-интерфейса и плагина Revit, которая позволяет создавать цифровые ведомости и расчёты на стороне заказчика, получая от проектировщика только правильно указанные параметры по EIR (требования заказчика к BIM-модели).

Внутри инструмента есть следующие функциональные блоки

Главный принцип — модель остаётся источником геометрии, а «ТЭП Контроль» становится контуром доверия к данным.

Разработка: подводные камни и ключевые решения

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

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

Наверное, самым сложным было настроить взаимодействие между «ТЭП Контроль» и Revit так, чтобы расчёты и проверки, описанные в сервисе, корректно интерпретировались внутри модели. Для этого потребовались часы анализа тест-кейсов и последующего тестирования связки: каждый проект по-своему уникален, но логика проверки при этом должна оставаться предсказуемой и устойчивой.

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

Для работы с формулами мы использовали NCalc на бэкенде и Ace на фронтенде. Это позволило обращаться к атрибутам элементов и выполнять стандартные арифметические операции. Помимо формульных расчётов, мы предусмотрели подсчёт уникальных значений и суммирование показателей.

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

Переход проходил уже в период пользовательской эксплуатации, поэтому мы внимательно синхронизировали релизы с проверками ТЭП и отдельно контролировали сохранность данных.

Пилотный проект: как мы проверяли инструмент на боевом проекте

Пилотный проект мы начинали с простого вопроса:

Можем ли мы взять BIM-модель, загрузить данные в систему и дальше контролировать изменения не вручную, а через инструмент? И смогут ли эксперты эффективно проверять ТЭП в нём? Не нарушив SLA :)

Что мы проверяли на пилоте:

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

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

По итогам пилота подтвердилась наша гипотеза: инструмент помогает ускорить проверку ТЭП примерно на 20%. Кроме того, за счёт более прозрачного обмена замечаниями и проверок на соответствие стандартам проектировщик быстрее устранял недочёты. В результате на дистанции от старта ОПР и фасадов до захода в экспертизу нам потребовалось всего пять проверок.

Конечно, ТЭП — не единственный фактор, влияющий на график проектирования. Но на этом проекте мы смогли подготовить материалы раньше планового срока: раньше выпустить АГР и ПСО и, как следствие, раньше перейти к получению РНС.

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

Что дальше

В итоге, представив бизнесу наше решение и результаты пилотного проекта, мы согласовали масштабирование инструмента. И в этот момент стало понятно: сервис сбора и проверки данных только верхний уровень задачи.

Следующий важный этап — настроить передачу данных во все смежные системы через новый каталог показателей ТЭП.

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

Для сотрудников это тоже важное изменение: вместо разрозненных источников и ручных проверок появляется понятная структура, где данные можно быстрее найти, проверить и использовать в своей работе.

При этом мы понимаем, что показатель — это не просто число, а объект с набором атрибутов. Мы выделили три измерения для описания: показатель, контекст и время.

Показатель — название, метод расчёта и статус подтверждения.

Контекст — проект, этап строительства, строение, секция, этаж, лот.

Время — стадия проекта, дата подтверждения и версия.

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

Что изменилось для команды

Какие выводы мы сделали

1. ТЭП — это не просто таблица, а управляемый процесс
   В Excel удобно работать, но сложно поддерживать качество данных — отслеживать актуальную версию, статус проверки и ответственность за изменения. Поэтому для надёжных ТЭП нужны единый источник, версия, статус, ответственный и понятные правила проверки.

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

   BIM — это хорошая база. Но доверие появляется только через проверку модели экспертами.

3. Самое сложное — не разработка, а внедрение правил
   Интерфейс разработать легко. Гораздо сложнее сделать так, чтобы им начали пользоваться правильно.

   Особенно когда меняется привычный процесс: раньше можно было «дослать Excel», а теперь нужно передать данные в структуре, пройти проверку и получить статус. И здесь начинается влияние на стандарты и требования.

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

   Хороший инструмент должен объяснять: что не так, где проблема, кто её исправляет, что изменилось, можно ли подтверждать данные и какие показатели уйдут дальше.

Вместо финала

Когда мы начинали делать «ТЭП Контроль», казалось, что задача в основном техническая: забрать данные из модели, положить в базу, показать в интерфейсе.

Но чем дальше мы шли, тем яснее становилось: настоящая задача — не в расчёте площадей.

Настоящая задача — в доверии к проектным данным. Чтобы в любой момент можно было открыть показатель и понять:

• откуда он взялся;

• по какой логике рассчитан;

• к какой версии проекта относится;

• кто его проверил;

• можно ли его использовать дальше.