Для крупного девелопера создали систему планирования и контроля строительных работ на объекте

Для крупного девелопера создали систему планирования и контроля строительных работ на объекте
5 минут

Есть запрос на внедрение?

Напиши нашим консультантам и назначьте встречу

Клиент

Девелоперская и PropTech-корпорация, входящая в российский топ-5 по объёмам строительства. Включена в список системообразующих предприятий. По состоянию на апрель 2023 года ведёт работу более чем над 50 масштабными проектами.

Проблема: клиент узнаёт о проблемах в строительстве с опозданием и теряет деньги

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

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

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

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

Как клиент управляет строительством и сроками

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

  • даты начала и окончания каждого этапа строительства (например, 15 мая строители завершают подготовку котлована, 1 июля заливают фундамент, а к 20 сентября должны возвести стены первых трёх этажей);
  • сроки и объём поставок строительных материалов на объект;
  • количество бригад строителей на разных этапах строительства;
  • перечень требуемой техники.

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

Составление плана-графика и прогноза сопровождалось следующими проблемами:

  • по сложившейся практике сотрудники ведут график работ в трёх разных программах одновременно — Microsoft Project и внутренних IT-сервисах девелопера;
  • данные о реальном положении дел на стройке обновляются вручную раз в несколько недель — и только после личного общения с подрядчиком, возводящим здание;
  • сроки проведения одного и того же этапа на объекте, вычисляемые используемыми системами, не совпадают, т. к. каждая из трёх систем обладает собственной вычислительной логикой.

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

Одновременно существовало четыре таймлайна строительства: первоначальный план, графики в Microsoft Project и внутреннем IT-сервисе, а также реальное положение дел на стройке. Клиент узнавал об изменении сроков лишь после того, как информация о возникших проблемах вносилась в Microsoft Project

Задача: создать автоматизированную систему планирования и контроля строительных работ на объекте

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

  • получение данных о ходе строительства и иных параметрах напрямую со стройки или из других IT-систем клиента;
  • прогнозирование сроков завершения строительства и каждого этапа в отдельности на основании сведений, полученных непосредственно со стройки;
  • своевременное извещение о возникающих проблемах и изменении сроков строительства.

Результат 1: клиент узнаёт о возникающих проблемах и изменении сроков строительства в режиме реального времени

Как было

Раз в неделю подрядчик должен был отчитываться о ходе строительства. Эти данные вручную заносились в Microsoft Project, и на их основе составлялся прогноз.

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

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

Проблемы зачастую выявлялись несвоевременно, из-за чего сроки строительства сдвигались на несколько месяцев.

Как стало

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

Вся информация автоматически попадает в разработанную KT.Team систему,п осле чего происходит корректировка прогноза. Команда проекта видит изменение сроков, что позволяет решить проблему на самом раннем этапе.

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

 

Результат второй: бизнес-логика прогнозирования строительства стала базовой для всех IT-систем клиента

Как было

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

Вычислительная логика задействованных сервисов не совпадала: обрабатывая одни и те же данные, они выдавали три противоречащих друг другу прогноза. Правила в Microsoft Project отличались от установленных в остальных системах, а правила во внутренних сервисах девелопера и вовсе составлялись разными командами IT-специалистов — разработчики зашили их напрямую в код, не снабдив компанию какой-либо программной документацией.

Как стало

KT.Team изучила сотни сценариев использования на примере реальных объектов и совместно с клиентом доработала формулы, приведя их в соответствие методологии девелопера. Став базовыми, эти формулы начали применяться во всех системах клиента, что позволило отказаться от эксплуатации Microsoft Project. Полученные данные о сроках, прогнозируемых системой, стали надёжным источником информации для принятия решений о поставке материалов, найме подрядчиков, выдаче рабочей документации и многом другом.

Все правила сведены в единую таблицу и доработаны в соответствии с требованиями бизнеса клиента
Оглавление
Другие кейсы

Смотреть все

Для сети Fix Price разработали портал поставщика и автоматизировали работу с данными о товарах

Подробнее

Для крупного девелопера создали систему планирования и контроля строительных работ на объекте

Подробнее

Разработка международной платформы для хакатона на Python

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок