Размышления о функциональности продуктов для строительной отрасли

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

Мы хотели бы поделиться опытом решения некоторых проблем, с которыми мы столкнулись при разработке продукта, призванного помочь при проведении строительного контроля указанных объектов.

Рынок строительства

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

По статистике на данный момент индекс цифровизации составляет до 10 пунктов или 2 место с конца рейтинга отраслей экономики и социальной сферы [1], а востребованность в цифровизации крайне высокая: строительный контроль входит в ТОП-6 самых важных цифровых сервисов на российском рынке [2].

Размышления о функциональности продуктов для строительной отрасли

При этом количество продуктов в этой сфере крайне велико. Для примера достаточно вбить в поиск на сайте «Реестр российского программного обеспечения» [3] запрос «строительный контроль», и вы получите список из более чем пятидесяти наименований.

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

Проблемы

Давайте рассмотрим некоторые особенности российской отрасли строительства, которые помогут нам выявить проблему.

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

Во-вторых, в рамках решения об ускорении процессов перехода к цифровой стройке, Правительством принято ряд нормативных документов, направленных на регулирование строительной деятельности в цифре. Мы не будем перечислять их в статье, с некоторыми примерами вы можете ознакомиться в сносках [4][5][6]. Если кратко, суть всех документов в регулировании требований к различным формируемым в ходе строительства артефактам, например к электронным исполнительным актам, и к электронному взаимодействию с государственными органами.

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

1. разрабатывать ПО со «своей» методологией и пытаться тиражировать её на всех клиентов;

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

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

И вот здесь заключается, на наш взгляд вся соль и боль текущих ИТ-решений для строительства.

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

Наше решение

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

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

1. модель данных проекта – кастомизация объектов и их свойств;

2. процессы проекта – создание, настройка и редактирование бизнес-процессов в своем собственном «движке»;

Размышления о функциональности продуктов для строительной отрасли

3. отчеты проекта – настройка отчетов для пользователей в удобном изолированном инструменте, интегрированном в продукт.

Размышления о функциональности продуктов для строительной отрасли

Объектная модель

Размышления о функциональности продуктов для строительной отрасли

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

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

Процессный движок

Изначально перед нами был выбор между «придумать и разработать движок с нуля» и «взять известный процессный движок и интегрировать к нам в систему». В итоге был принят компромиссный вариант: мы взяли нотацию BPMN 2.0, которая наиболее понятна и однозначна и разработали свой собственный движок на её базе.

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

Отчеты

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

Заключение

Что мы имеем после реализации данных функциональных блоков?

1. Время на внедрение продукта после реализации описанных блоков функциональности сокращено на 60 %.

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

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

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

[4] Постановление Правительства Российской Федерации от 05.03.2021 № 331 «Об установлении случая, при котором застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию объекта капитального строительства, обеспечиваются формирование и ведение информационной модели объекта капитального строительства»

[5] Постановление Правительства РФ от 1 декабря 2021 г. № 2161 «Об утверждении общих требований к организации и осуществлению регионального государственного строительного надзора, внесении изменений в постановление Правительства Российской Федерации от 30 июня 2021 г.»

[6] Приказ Минстроя РФ от 2 декабря 2022 г. № 1026/пр «Об утверждении формы и порядка ведения общего журнала»

Начать дискуссию