Размышления о функциональности продуктов для строительной отрасли
Здравствуйте, нас зовут Павел и Артём, мы бизнес-аналитики компании 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. Как следствие из пунктов выше – мы добились увеличения лояльности клиентов к продукту и к изменениям, связанных с цифровизацией их деятельности.
Конечно, мы рассмотрели только малую часть айсберга проблем цифровизации строительства, но надеемся, что наши размышления были полезными. А на сегодня все, до новых встреч.
[1] НИУ ВШЭ https://issek.hse.ru/news/783750202.html
[4] Постановление Правительства Российской Федерации от 05.03.2021 № 331 «Об установлении случая, при котором застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию объекта капитального строительства, обеспечиваются формирование и ведение информационной модели объекта капитального строительства»
[5] Постановление Правительства РФ от 1 декабря 2021 г. № 2161 «Об утверждении общих требований к организации и осуществлению регионального государственного строительного надзора, внесении изменений в постановление Правительства Российской Федерации от 30 июня 2021 г.»
[6] Приказ Минстроя РФ от 2 декабря 2022 г. № 1026/пр «Об утверждении формы и порядка ведения общего журнала»