Авторы: В.И. Пронин, Д.В. Медведев, А.А. Ислам, ООО «Ингипро»
Введение
Основной задачей цифровизации строительной отрасли и внедрения технологии информационного моделирования является сокращение сроков возведения объектов капитального строительства при сохранении и повышении качества работ.
Одним из инструментов, который позволяет работать со сроками проектирования, разработки и утверждения документации на всем жизненном цикле ОКС является организация единого информационного пространства - среды общих данных проекта.
В настоящей статье рассмотрим вопрос о том, как СОД позволяет повысить маржинальность проектной деятельности. Наибольшие затраты при проектировании идут на оплату труда специалистов. Себестоимость подготовки проектной документации зависит от времени, которое компания затратит на ее подготовку. Для повышения маржинальности следует рассмотреть возможности сокращения проектирования.
Перечень сокращений
- ОКС – объект капитального строительства
- СОД – среда общих данных
- ИС – информационная система
- ЦИМ - цифровая информационная модель
Определение понятий
Технологии информационного моделирования есть способ преобразования информации об объекте капитального строительства в информационную модель/модели ОКС, путем построения взаимосвязей внутри и между различными информационными частями посредством использования среды общих данных. [1]
Среда общих данных (СОД) — это единый программно-технический комплекс для совместной работы участников проекта с информационными моделями на всех стадиях жизненного цикла. [1]
Сроки проектирования
Этап проектирования по срокам сильно зависит от специфики проекта. Чем более уникален объект проектирования, тем большие сроки потребуются на подготовку документации.
Когда мы говорим про маржинальность проектирования, мы можем рассмотреть возможности сокращения сроков на подготовку документации. При этом важно понимать, что сокращение сроков данного этапа не должно производится в ущерб качеству проектной документации. В ином случае сокращение проектирования повлечет за собой увеличение длительности и стоимости следующих этапов проекта ОКС.
В проектной деятельности есть процессы, которые могут быть оптимизированы за счет внедрения соответствующих технологий.
Проектирование объекта капитального строительства - это коллективный труд многих специалистов. В этом процессе большую роль играет своевременный обмен информацией. Каждый участник процесса готовит свою часть проектной документации. Само по себе проектирование идет по принципу “от общего к частному”. Т.е. сначала принимаются общие проектные решения, на следующем шаге они уточняются и так далее, пока не будет достигнута нужная для проекта точность и детализация.
Если бы мы рассматривали проектирование без привязки к стоимости и времени, то следовало бы каждую итерацию проектирования проводить отдельно и в четкой последовательности друг за другом. В этом случае можно избежать большого количества ошибок и переделок. Каждое проектное решение идет после принятия и утверждения предыдущего.
В реальной жизни построение такого процесса проектирования невозможно в силу того, что оно бы занимало большое количество времени, а, следовательно, и стоимость его была бы высока. Т.к. проектные организации работают в конкурентной среде, то им приходится самостоятельно сжимать сроки и стоимость своих работ. Это возможно, когда разные специалисты работают одновременно. Т.е. даже те специалисты, результаты деятельности которых для одного являются результатом, а для другого входной информацией - работают одновременно. Инженер начинает разрабатывать свою часть проектной документации в условиях неполной входной информации. Такой режим работы сохранятся от начала работ по проектированию и до их завершения. Изменения в проектной документации проходят, как волны, затрагивая все ее разделы. Инициаторами таких изменений могут быть, как внутренние специалисты компании, так и внешние обстоятельства. Про это говорят: “проектирование идет по вновь открывшимся обстоятельствам”.
Итак, получается, что проектная команда, которая может состоять, как из сотрудников одной организации, так и разных организаций, что дополнительно осложняет общую координацию, работает совместно, одновременно и не имея полной и достоверной информации.
Внедрение инструментов, которые позволят повысить координацию работы проектных команд является возможностью для сокращения общего срока проектирования, а значит положительно отразится и на общих сроках проекта и маржинальности проектной работы. Таким инструментом является среда общих данных.
Работа по устаревшим данным
Как мы рассмотрели выше, работа проектной команды или отдельного специалиста сильно зависит от работы соседних команд. Для осуществления подобной синхронизации обычно вводят некий регламент работы. До недавнего времени прогрессивным считался подобный регламент: “по окончании рабочей недели выгрузить результаты работы на сервер”. Предполагалось, что синхронизация производится раз в неделю и это хороший результат.
Что означает подобная схема работы на практике? Возьмем в качестве примера 3 проектные команды. Результаты деятельности команды 1 являются входной информацией для работы команды 2. А результаты деятельности команды 2, аналогично, являются входной информацией для команды 3. Раз в неделю, как диктует регламент, команды выгружают свои результаты на общий сервер. Допустим, что первая команда внесла какие-то правки в свои проектные решения и выгрузила их в пятницу. В понедельник вторая команда увидела соответствующие изменения и внесла правки в свои решения, выгрузив их в пятницу второй недели. Третья команда, изучив результаты работы второй команды, приняла их в работу и выгрузила результат в пятницу третьей недели.
Рис 1. Пример совместной работы 3 проектных команд без СОД.
Итак, даже небольшие правки были внесены в проект спустя три недели от их первичного внесения. И это при том, что в рассматриваемом примере всего 3 уровня взаимной зависимости.
Регламент по обмену информацией “раз в неделю” приводит, в рассмотренном примере, к обновлению проекта за 3 недели. Если же уровней взаимных связей будет больше, то сроки будут еще выше.
Мы имеем проект, изменения в который внести очень долго, но это лишь часть проблемы. Другая ее часть заключается в том, что вторая команда целую неделю работала по устаревшим данным, а третья команда - две недели. Это называется “работа на корзину”. Смысл ее в том, что команды 2-го и 3-го уровня обусловленности разрабатывают свою часть документации по тем данным, которые уже неактуальны. При получении обновленной информации (как мы рассматривали - раз в неделю) им приходится переделывать то, что было сделано ранее.
Организация более быстрого/эффективного информационного обмена между проектными командами является потенциалом для сокращения сроков проектирования и повышения маржинальности деятельности.
Что в этом направлении позволяет организовать внедрение СОД?
Регламент информационного обмена может быть построен на принципе “поставка результатов по готовности”. Почему подобный регламент не внедряется при работе без специфического инструментария (на общем сервере)? В силу того, что специалисты вынуждены были бы тратить значительные усилия и время на поиск обновленной информации. Требовалось бы пройтись по всем частям проекта, которые потенциально могли бы обновиться.
Среда общих данных имеет функционал уведомлений об изменениях. Данный функционал призван привлечь внимание специалистов к тем изменениям, которые были внесены в проект. В простом понимании - система информирует пользователя о том, что была загружена новая версия какого-то документа или с этим документом были совершены какие-либо действия (например добавлен комментарий).
Казалось бы - проблема решена. Проектные команды загружают результаты своей деятельности в систему по готовности. Пользователи системы получают уведомления об изменениях. Работа на корзину сводится к минимуму.
Однако жизнь показывает, что этого недостаточно. В такой схеме возникает другая проблема - большое количество уведомлений. Дело в том, что проект ОКС содержит в себе слишком большое количество документов, по которым могут возникнут какие-то изменения. Это означает, что конкретного пользователя системы нельзя уведомлять обо всех изменениях проекта. В ином случае вся его работа будет заключаться в просмотре этих уведомлений.
Решение проблемы уведомлений не тривиально. Каждая система предлагает свои способы настройки уведомлений. Однако в конечном итоге, внедрение специализированной для проектной деятельности среды общих данных позволяет решить проблему работы по устаревшим данным.
Это первая часть, где могут быть существенным образом сокращены временные затраты на проектирование.
Поиск и идентификация информации
Совместная деятельность инженеров во многом связана с использованием исходной информации и проектных решений, которые были подготовлены другими инженерами, а также переиспользованием проектных решений, которые использовались в других проектах. Для этого инженеры используют различные варианты поиска требуемой им информации.
Если работа построена через общий сервер, то поиск информации производится на нем. Сложности могут возникнуть в силу того, что каждый специалист имеет свое представление о том, как стоит называть отдельные файлы. Для избежания подобных проблем в проект вводится правило именования файлов исходя из состава проекта. Насколько строго это правильно исполняется зависит от проектных команд. Практика показывает, что на 100% это правило не исполняется, а значит проблема поиска сохраняется.
Решить эту проблему помогает внедрение среды общих данных для проектных организаций. СОД может иметь функционал, который или запрещает загружать файлы с неправильным наименованием или явным образом подсвечивает ошибки в наименовании. Данная функция серьезным образом повышает исполнительскую дисциплину в проекте. При этом сокращается время, которое специалисты тратят на поиск нужной информации, а также последующая подготовка проекта для сдачи тоже упрощается.
Поиск нужной информации является важной, но не единственной проблемой, с которой сталкивается инженер при своей работе. После того, как он нашел нужную ему информацию, специалисту требуется определить статус этой информации. В какой степени готовности находится рассматриваемый документ, можно ли его использовать в своей работе, утвержден ли он? Самостоятельно ответить на эти вопросы специалист не может, поэтому ему нужно обратиться к автору документа с запросом информации. Это порождает множество мелких коммуникаций, которые происходят между инженерами, занимая время и отвлекая от работы.
Решить проблему идентификации позволяет СОД. В среде общих данных для проектных организаций существует функционал - статусы документов. Обычно эти статусы соответствуют методологии СОД - разделение на зоны готовности:
Таким образом, при использовании СОД, специалисты сокращают время на поиск нужной информации, а также на ее идентификацию.
Это вторая часть, где СОД позволяет сократить время на проектирование.
Согласование документации.
Коллективный труд проектных команд характеризуется большим количеством согласований. Проектной команде требуется не только передать результат свой работы другой команде, но и согласовать эти результаты. Сами согласования можно разделить на формальные и неформальные. Неформальные согласования (синхронизации работы) в труде проектировщиков происходят очень часто. Без использования специфических систем специалисты пользуются существующими инструментами такими, как электронная почта, телефон или очные встречи. На организацию неформальных согласований тратится большое количество времени. При этом это время не являются продуктивным, часто это ожидание.
Официальное согласование по своей функции похоже на подписание документов. Внутри одной организации такие согласования возможно ускорять “вручную”. Но в проектной деятельности требуется проводить согласование документации между организациями. Эта процедура может занимать значительное время, что негативно влияет на общий срок проекта. Бывают такие ситуации, когда к завершению согласования документация теряет свою актуальность и процедуру запускают заново.
При этом, используя “подручные инструменты”, невозможно выстроить эффективное параллельное согласование, а последовательное согласование занимает времени гораздо больше.
Если рассмотреть сам процесс согласования, то в нем можно выделить значительную часть времени, которое занимает общение между “автором документа” и “согласующим”. Это общение заключается в выяснениях нюансов предмета согласования, уточняющих вопросах, замечаниях и комментариях. Эта информация являются существенной при разработке проектных решениях, т.к. содержит в себе предпосылки принятия тех или иных проектных решений.
Использование среды общих данных позволяет выстроить процессы согласования и обсуждения проектных решений внутри системы. Это сильно экономит время инженеров, а также позволяет экономить “внимание специалиста”. Человеку не нужно думать про организацию согласования и обсуждения, держать в голове состояние процедур согласования и многое другое. При этом вся история развития проектных решений остается в системе и доступна в будущем, что в свою очередь, опять, экономит время на решение вопросов о том, почему было принято то или иное проектное решение. Сама процедура согласования может быть выстроена так, что несколько специалистов включены в согласование одновременно (параллельное согласование), что кратно сокращает время на всю процедуру.
Это третья часть, где СОД существенно сокращает время проектирования.
Стандартизация процессов проектирования
Первый этап оптимизации любой деятельности заключается в стандартизации процессов. Невозможно оптимизировать хаос. Существует мнение о том, что проектная деятельность - это творческий процесс и на него не применимы инструменты автоматизации. Это правда лишь отчасти. Выше мы рассмотрели, что в проектной деятельности, помимо творческой мыслительной составляющей наличествует большое количество вполне типичных рутинных процессов. Когда мы говорим об автоматизации проектной деятельности, то прежде всего имеем в виду автоматизацию рутинных процессов, сопутствующих этому виду деятельности.
Без использования каких-либо специфических инструментов проектные команды работают по индивидуальным принципам “так заведено”. Обычно принципы работы проектных команд соответствуют тому, как привыкли и как умеют работать ведущие специалисты этих команд. Такие специалисты являются “ядром” компании и являются одновременно сильной и слабой стороной проектной организации. Сила “ядра” заключается в его компетенции, умении выполнять сложные проекты, а слабость в высокой степени инерции. Старшее поколение специалистов обучает новых сотрудников, чем обеспечивается преемственность работы.
Раньше подобную ситуацию можно было считать большим плюсом для проектной организации и всемерно поощрять. Однако настоящее время диктует иные требования к организации труда. Проектная команда прекращает быть неким “замкнутым” коллективом. Труд удаленных специалистов становится нормой. И как бы мы не любили проведение очных совещаний с горячим обсуждением проектных решений, все это начинает уходить в прошлое. Это неизбежно, т.к. экономически более обоснованно. Содержание огромных проектных институтов - дорогостоящее предприятие. Новая форма - организация проектных команд под проект. Разные компании решают эту задачу по своему, обычно в компании существует некий свой штат сотрудников, а под проект привлекают дополнительных сотрудников или подрядчиков.
Именно в этот момент становится особо актуальным вопрос стандартизации процессов проектирования. Дело в том, что в индивидуальные, каждый раз разные процессы крайне сложно включать новых людей. Именно этим обусловлено большое время, которое обычно требуется новым проектировщикам для “вхождения в работу”. Специалисту требуется время для изучения специфики работы “ядра” компании.
Использование СОД для проектировщиков позволяет произвести стандартизацию процессов проектирования. Данный шаг позволяет достичь значительных эффектов в деятельности проектной организации:
- сокращаются временные издержки на проектирование;
- в компании появляется возможность составлять проектные команды под нужды проекта, привлекать дополнительный персонал или подрядчиков. При этом существенно сокращается время на включение в работу таких специалистов, а результаты их труда более качественны;
- в разработке новых проектов возможно в большей мере использовать те результаты труда, что были подготовлены в предыдущих проектах, что экономит время и повышает маржинальность деятельности компании;
- процессы планирования работ и их контроля строятся на объективных данных;
- компания получает возможность совершенствовать свою деятельность, т.к. стандартизированные процессы возможно улучшать в отличии от индивидуальных.
Стандартизация процессов является первым шагом на пути автоматизации проектирования. При этом важно понимать, что речь не идет об автоматическом проектировании. В обозримой перспективе машина не сможет заменить человека в творческой проектной деятельности. Однако стандартизация и последующая автоматизация существенно повлияет на финансовые показатели деятельности проектных компаний. Это значит, что конкурентную борьбу выдержат те компании, которые вовремя внедрят эти инструменты в свою работу.
Заключение
Технологии информационного моделирования это не столько про переход из 2D проектирования в 3D. Это смена парадигмы работы в целом. Для проектных компаний это означает переход из “закрытого” состояния, когда каждая компания живет в “своем мире”, в новое технологическое состояние, когда освоенные технологии и выстроенные бизнес процессы являются залогом победы в конкурентной борьбе.
Использование среды общих данных, как технологии работы, для проектной компании позволяет существенным образом сократить сроки проектирования, повысить маржинальность деятельности. Также СОД помогает компаниям повысить собственную конкурентоспособность, что является условием успешного развития компании в будущем.
Больше интересной информации в Telegram-канале «ИНГИПРО»
____________________________________________________
Список литературы
[1] Требования к средам общих данных. Д. В. Медведев, В. И. Пронин, А. А. Ислам // Человек. Общество. Инклюзия / Human. Society. Inclusion Том 14 (2023). № 4-2 / Volume 14 (2023). Issue 4-2
[2] Медведев, Д. В. Формирование экономических обоснованных требований к средам общих данных / Д. В. Медведев, В. И. Пронин, А. А. Ислам // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 4-2(59). – С. 161-170. – EDN INLKCQ.
[3] Ислам, А. А. Десктопное или веб-приложение для организации СОД ОКС / А. А. Ислам, В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-3(57). – С. 128-135. – EDN GHMTFS.
[4] Пронин, В. И. Экономические структуры имплементации коммерческих лицензий СОД строительных проектов / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия. – 2024. – Т. 14, № 4-3(60). – С. 166-176. – EDN AFWSVK.
[5] Медведев, Д. В. Уровни развития сред общих данных строительных проектов / Д. В. Медведев, В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 434-445. – DOI 10.34670/AR.2023.59.18.018. – EDN FVJNAG.
[6] Пронин, В. И. Организация процесса выбора среды общих данных для проектов объектов капитального строительства / В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 220-230. – DOI 10.34670/AR.2023.54.86.078. – EDN IMVWNL.
[7] Пронин, В. И. Трактовка понятий "технологии информационного моделирования" (ТИМ) и "среда общих данных" (СОД) / В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 2(54). – С. 140-146. – EDN YXDIPD.
[8] Пронин, В. И. Формирование задач для выбора информационной системы из стратегических целей проектной организации / В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-1(55). – С. 114-119. – EDN CNMXJI.
[9] Пронин, В. И. Коммерциализация технологий информационного моделирования на примере рынка СОД / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-1(55). – С. 141-149. – EDN CSQNSP.
[10] Особенности хранения проектной информации в среде общих данных строительного проекта / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия / Human. Society. Inclusion Том 15 (2024). № 1-2 / Volume 15 (2024). Issue 1-2
Комментарии (0)