Несмотря на то, что основной набор параметрических 3D-CAD-программ (или САПР – систем автоматического проектирования) по-прежнему продается нам иностранными вендорами под брендом «BIM-технологии», можно, с определенным удовлетворением, констатировать, что в строительное сообщество пришло зрелое понимание того, что BIM-технологии – это не только и не столько 3D-графические редакторы, далекие от моделирования по-умолчанию. Более того, можно, с определенной оптимистической ноткой, констатировать, что даже 3D-вендоры стали правильно называть свои продукты (например, Dassault) именно как 3D-редакторы, а не BIM-технологии. Все стали достаточно осмысленно относится к тому, что BIM-технологии – это, прежде всего, единая среда данных и инструментарий, обеспечивающий использование этих данных для принятия решений на всех стадиях жизненного цикла объекта недвижимости. И сам по себе набор графической информации в формате 3D, безусловно, очень важный элемент информационной модели, но только с позиции визуального представления, а не принятия управленческих решений. Именно с точки зрения моделирования эффективного объекта недвижимости в будущем, более важными являются такие этапы развития информационной модели, как Инвестиционная модель и Модель Требований (см. рис. ниже).
Очевидно, что работа с требованиями – не просто далека от 3D-манипулирования, а в принципе представляет собой серьёзную математическую и аналитическую задачу, решаемую в рамках классических стандартов и правил системной инженерии. Безусловно, какие-то электронные эскизные 3D-макеты, или какие-то видео инструменты примитивной 3D-визуализации вполне применимы для работы с требованиями, но все они не являются реальными объектами для обсуждения проектных решений. Ибо проектные решения появляются только тогда, когда уже есть НАБОР ТРЕБОВАНИЙ. По сути, качество проектной документации в будущем на 90% зависит от того, как подготовили ТЗ, а значит – насколько системно поработали с требованиями до того, как окончательно увидеть проектируемый объем. Именно в таком разрезе, цифровая модель требований (совокупность электронной информации о требованиях и ограничениях, связанная в ИМ электронными инструментами контроля учета требований, их тестирования, верификации испытаний и оценки соответствия результата испытаний самому требованию – AR) становится краеугольным камнем эффективности BIM-технологий.
Для того чтобы точно описать цифровую модель требований как элемент информационной модели (BIM-модели) в целом, а соответственно, описать основные механизмы создания, учета, контроля и верификации требований в ИМ на всех этапах ЖЦ объекта девелопмента недвижимости, давайте определимся с исходными дефинициями инженерии требований. Для общего представления об инженерии требований лучше воспользоваться общим определением из стандарта IEEE-STD-1220-1998 (IEEE-1998): ТРЕБОВАНИЕ – это недвусмысленное, поддающееся измерению, проверке утверждение, определяющее целевой показатель, функциональную или расчетную характеристику, или ограничивающее условие признания пригодности продукции или процесса. Система соответствия требований может быть представлена в рамках классической системной инженерии (см. рис. ниже).
Не секрет, что Требования – это концептуальная основа любого проекта. Если инвестиционная модель, в определенном смысле – модель Желаний Заказчика, то есть модель его представлений о том, каким должен быть объект недвижимости в самом лучшем исполнении для него, то модель требований – это и антипод, и расширение инвестиционной модели. Требования определяют, что хотят получить от проектируемого объекта недвижимости все заинтересованные стороны (Stakeholder) – Потребители, пользователи, Инвесторы и Заказчики, Подрядчики и Проектировщики, государство и партнёрские коммерческие организации, и какими свойствами должен обладать будущий недвижимый актив для полного удовлетворения их запросов. Требования должны быть ясны любой заинтересованной стороне, поэтому их необходимо формулировать на едином понятном всем языке, то есть, так или иначе, потребуется единая система сигналов, их кодификации и декодирования. Общая методология ИНЖЕНЕРИИ ТРЕБОВАНИЙ – подраздела системного инжиниринга, предназначенного для выявления, разработки, отслеживания, анализа, проверки соответствия, установлением взаимозависимости требований и управления ими в целях повышения качества системного эффекта, предполагает, что источником требований всегда выступают именно Стейкхолдеры. Отсюда выстраивается вполне четкая логическая схема формирования Информационной модели: Определение заинтересованных сторон – формирование реестра требований – разработка проекта в соответствие с требованиями – проверка требований на соответствие – утверждение результата у стейкхолдера – привязывание проектного решения навсегда. Как видно, здесь термин СТЕЙКХОЛДЕР – физическое лицо или группа лиц, организация или иная социально-экономическая система, имеющие прямые или косвенные, опосредованные интересы (или порождаемые права), относительно создаваемого объекта недвижимости, становится одним из наиважнейших.
После создания объекта недвижимости, волей-неволей, необходимы будут специальные инструменты перманентного соответствия требованиям на всех этапах ЖЦ, поверки самих инструментов контроля требований и актуализацию требований по текущим изменениям на всех этапах ЖЦ. Как видно, после обсуждения, утверждения и принятия, требования становятся базовым ориентиром управления как любым инвестиционно-строительным проектом, так и объектом недвижимости в целом. Согласно международному стандарту IEEE-29148, любое требование стейкхолдера, требования к продуктам, системам или их компонентам должны обладать следующими характеристиками:
1. Необходимость. Требование должно определять существенную способность, свойство, характеристику, показатель или ограничение, игнорирование которых приведёт к качественным недостаткам, делающим невозможным использование целевой системы, продукции или процесса.
2. Независимость от реализации. Требование, определяющее необходимое и достаточное свойство системы, позволяет избежать ненужных ограничений на архитектурные, структурные и иные проектные решения. Иными словами, Требование должно содержать сведения о том, что требуется, а не о том, каким способом или методом это будет достигнуто, т.е. не привязываться к способу реализации.
3. Недвусмысленность. Требование должно быть сформулировано таким образом, чтобы оно не могло интерпретироваться различными заинтересованными сторонами по-разному, а только однозначно и одинаково всеми. Формулировка каждого требования должна быть простой для понимания и трансфера в проектные решения.
4. Непротиворечивость. Требование не должно противоречить прочим требованиям, как нижестоящим и вышестоящим элементам и составляющим продукта, так и вообще иным требованиям, даже если они напрямую никак не связаны.
5. Полнота. Требование должно быть описано таким образом, чтобы не нуждалось в дальнейшем ни в каких уточнениях, в разъяснениях, поскольку полное требование измеримо и в достаточной степени описывает возможности и характеристики, отвечающие потребностям Заказчика или пользователя.
6. Реализуемость. Требование должно быть технически реализуемым без необходимости использования принципиально новых технологических достижений, требование с приемлемым уровнем риска может быть реализовано в рамках прочих ограничений системы, накладываемых и иными требованиями.
7. Единственность. Требование должно быть связано только с одним уникальным параметром, свойством, характеристикой или ограничением стейкхолдера, которое ни с чем не увязывается и не составляет микросистем.
8. Прослеживаемость. Требование должно быть отслеживаемым от документа, утверждающего эту потребность стейкхолдера, до последнего документа, подтверждающего его исполнение. Прослеживание требование осуществляется как постоянным подтверждением соответствия требованию более высокого уровня или к другому проектному решению, результату или свойству. Требование должно прослеживаться сверху вниз к конкретным требованиям, описанных в общих документах создаваемого продукта.
9. Проверяемость. Требование должно позволять получить свидетельство того, что получившийся продукт или результат удовлетворяет этому требованию, особенно, если требование измеримо! Согласно тому же стандарту, есть целый набор характеристик, которыми должен обладать пакет или набор требований.
10. Согласованность. В составе набора требований должны отсутствовать индивидуальные требования, которые противоречат друг другу или дублируют друг друга.
11. Приемлемость. Решение, удовлетворяющее набору требований, должно быть доступно и достижимо в пределах ограничений (стоимость проекта, график работ, технические возможности, риски, правовые и нормативные ограничения), возникающих на протяжении всего ЖЦ объекта недвижимости.
Как видно из этого небольшого набора характеристик, требования играют важнейшую роль в вопросах эффективной реализации проектов, в том числе, инвестиционно-строительных. По большому счету, правильно сформулированный пакет требований – это гарантия эффективной реализации проектов. С точки зрения классификации самых стандартных требований можно говорить:
1. Требования по безопасности. Эти требования касаются не только безопасности эксплуатации, строительства, испытаний и тестирования, но и требований по безопасности труда, классические требования по противопожарной или по противотеррористической безопасности, экологической безопасности и, наконец, безопасности будущих поколений (устойчивого развития). Это же относится к вопросам обучения безопасным методам управления и эксплуатации, хотя, разумеется, этим не ограничивается.
2. Требования по качеству. Один из самых сложных аспектов требований, особенно в условиях постоянно меняющихся рынков. Не исключено, что требования по качеству являются переменными сами по себе, а значит должны учитываться в процессе реализации продукта. Качество – это соответствие цели или соответствие требованиям, в принципе, то есть предоставление таких потребительских свойств и характеристик, которые полностью удовлетворяют спрос Заказчиков и гарантируют учет нужд и потребностей всех заинтересованных сторон.
3. Требования географические. Сюда относятся как требования климатические, так и требования градостроительных правил и ограничений, требования к высотным отметкам, нагрузкам на грунты, гидрогеологической подоснове и обеспечению техническими условиями. Географические требования касаются и логистических маршрутов, и вопросов обслуживания и страхования, а также национальных, социальных, политических и иных особенностей конкретной территории, где создается объект недвижимости.
4. Требования жизненного цикла. Сегодня требования к эксплуатации, ремонтам, а также требования к проектным решениям в связи с возможными изменениями конструктива на протяжении всего жизненного цикла, становятся важными не только с точки зрения стоимости владения для собственника, но и стоимости эксплуатации инфраструктуры города для городских властей. По сути, инжиниринг требований должен не просто сказать, когда и какой ремонт, текущий или капитальный, надо делать, какие материалы покупать с точки зрения сроков эксплуатации и надежности, но и возможные варианты изменения целевого использования, расширения или реинжиниринге, редевелопмента и качественного изменения направления использования. Эти требования закладываются в начальное задание на проектирование и также должны быть подтверждены проектными решениями. Для сложных технических систем требования могут включать не только условиях и параметры эксплуатации, но и требования к инструментам проверки требований, требования к методикам и способом проведения проверки, поверки испытательных средств и приспособлений, обучению персонала и его сертификации, как например, это принято в Росатоме (см. рис. выше).
5. Требования к системе управления требованиями. Один из важнейших аспектов, особенно касающихся сложных технических систем, предприятий промышленности или крупных инфраструктурных проектов. Требования, которые могут появится в процессе реализации проекта требуют своей политики управления дополнительными ресурсами.
6. Требования к цифровой модели требований. Разумеется, когда мы говорим о создании электронной информационной модели требований, мы воспринимаем её как электронную неразрывную совокупность информации о требованиях и электронно связанной с ней информации, подтверждающей выполнение требований, их тестирование и поверку средств измерений.
Это небольшое введение в проблематику управления требованиями, инжиниринга требований, было необходимо для того, чтобы осознать, что деятельность в области инженерии требований – такая же системная сквозная задача управления информационной моделью на всех этапах жизненного цикла, как, например, управление стоимостью. Иными словами, эта задача НЕ РЕШАЕТСЯ наличием какого-то уникального IT-продукта и тем более, она не решается путем приобретения каких-то 3D-редакторов, пусть и расширенных, пусть модернизированных, но все равно графических редакторов. Отсюда важнейший вывод: Управление Требованиями и инжиниринг Требований – такая же ПЛАТФОРМЕННАЯ опция BIM-технологий, которая реализуется сквозь всю информационную модель, по аналогии с управлением стоимостью в BIM, управлением безопасностью BIM-safety или организацией сквозного управления сроками или контрактами.
Для того чтобы сконфигурировать примерную или визионерскую архитектуру подсистемы управления требованиями в структуре BIM-платформы давайте попробуем просто пробежаться по основным процедурам работы с требованиями. Эта прогулка, так или иначе, покажет, что надо сделать, чтобы управление требованиями в Информационной модели Объекта девелопмента Недвижимости стало цифровым и эффективным. Сразу надо оговориться, что ЦИФРОВАЯ МОДЕЛЬ ТРЕБОВАНИЙ – это электронная часть информационной модели, функционирующей в рамках BIM-платформы, предназначенная исключительно для электронного учета, отслеживания и актуализации работы с требованиями. Как это должно происходить?
1. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К ОБЪЕКТУ НЕДВИЖИМОСТИ В КЛАССИЧЕСКОЙ BIM-ПЛАТФОРМЕ.
И так, обсудив, пусть и не в полном объеме основные аспекты управления требованиями в рамках BIM-концепции строительной отрасли, можно попробовать «нарисовать» общий свод основных процессов реализации инвестиционно-строительных проектов в рамках опционального управления требованиями на всех этапах жизненного цикла ОДН. И так, по порядку:
· Допустим, Инвестор инициировал новый инвестиционно-строительный проект и в рамках утвержденной процедуры создания кабинета проекта и операционной деятельности какого-либо BIM-центра начал работу по созданию Информационной модели в полном объеме. Разумеется, в рамках классических документов проекта будет создан перечень основных стейкхолдеров проекта и, по возможности, составлена ведомость их ключевых требований.
· В рамках наличия разработанного Приложения к BIM-платформы, с условным наименованием «Управление требованиями», все стейкхолдеры заносятся в специальный электронный каталог (журнал), в котором предусматривается внутренняя коммуникация с документами по их требованиям и ссылки на конкретные разделы. На основании таких ссылок формируется Электронный реестр Требований, который становится основой для разработки ТЗ на проектирование в последствие. Разумно, если шаблон такого реестра является универсальной проформой ЕИП – Единого Информационного Пространства и подключен к базам данных ТИПОВЫХ ТРЕБОВАНИЙ, которую вполне мог бы вести, например, Росстандарт!
· Электронный реестр или журнал Требований к проекту становится типовым элементом интерфейса BIM-платформы, поскольку к нему придется обращаться достаточно часто, в том числе и по причине возникновения новых требований в процессе реализации BIM-проекта. Важнейшим элемент этого реестра – система взаимосвязи каждого требования с местом его исполнения в информационной модели. Если большая часть опий BIM-платформы можно считать условно интегральными, т.е. они собирают информацию из разных приложений-участников BIM-модели, то Приложение «Управление требованиями» - исключительно коммуникационное (workflow), с одной стороны, и контрольное – с другой.
· Все требования в реестре паспортизируются на момент принятия инвестиционного решения, а потом – на момент решения о старте строительства и эксплуатации. Этот утверждающий документ также является электронным и присваивается как атрибут реестру требований на соответствующей временной шкале (timeline). Все требования, соответственно, классифицируются по возможности их цифровизации, на требования параметрические и описательные. Параметрические требования представляют собой конкретные цифровые параметры и могут быть легко проверены в проектных решениях, в другом ПО или в отчетных документах, создаваемых собственно BIM-платформой. Описательные требования генерируют иной механизм выполнения и подтверждения – документационный.
· Параметрические требования – цифровые требования, формируют свой собственный электронный реестр, независимо от источника требования и должны подтверждаться конкретным параметром в проекте. Идеальным считается вариант, когда параметрическое требование из реестра напрямую связано с местом в проектной документации и выявляется на специальном слое или посредством специального фильтра «ФИЛЬТР – ТРЕБОВАНИЯ». В то же время, в самом реестре требований создается ведомость ссылок на точку в проекте, где и как это требование удовлетворено. Например, выполнено расстояние, размеры, параметры надежности, точности и т.п. Параметрические требования должны заканчиваться актом отсутствия коллизий требований, то есть должна быть проведена проверка на коллизии параметрических требований.
· Описательные требования – это требования, представленные конкретным описанием или неоцифрованным текстом. В случае описательного требования, система должна предусматривать и описательное же разъяснение, где и как это требование выполнено. И это разъяснение должно быть не просто спрятано глубоко в пояснительной записке к проекту или где-то в глубине приложений к проектной документации. Это разъяснение должно иметь четкий электронный вид, ссылку на него в нужном месте проекта (например, требование об экологической безопасности находится как глава пояснительной записки в ОВОС). Кроме того, в самом разъяснении должны быть представлены электронные ссылки (что важно) на источники информации, расчеты, исследования, экспертные мнения и иные документы, подтверждающие выполнение этого требования. Не должно быть ссылок просто на книгу, просто на статью, или просто на исследования некоторого ученого, без точного места или данных в этом источнике. В случае, если интернет-ссылка на источник может быть закрыта, данный источник полностью переносится в ИМ проекта и остается в базе данных проекта навсегда.
· В процессе проектирования и последующей реализации проекта создается целый блок информации – подтверждение требований. По сути, это сквозной срез информационной модели, который является своеобразным смысловым каркасом проекта, поэтому создать и отследить его в рамках какого-то выделенного 3D-графического редактора – практически невозможно и не имеет за собой никакого убедительного обоснования. В результате работы по созданию и управлению требованиями должен получится результирующий электронный документ – ОТЧЕТ ИСПОЛНЕНИЯ ТРЕБОВАНИЙ. Это документ, с которого должны начинать работу как техническое контролеры, так и экономические аудиторы, если проект имеет четкие экономические и социальные требования. По сути, вместо того, чтобы перебирать сотни папок бумажной документации, проверяющие органы могут спокойно исследовать отчет о выполнение требований, и, как по ветвям дерева, спустится не только по всем доказательным документам к самому требованию, но и к его источнику – стейкхолдеру.
· Безусловно, может сложиться ситуация, когда подтверждение выполнения требования, как параметрического, так и описательного, невозможно путем камеральных расчётов и исследований, а требуют дополнительных тестов, испытаний или даже исследований. Прежде всего, такая работа требует дополнительного финансирования и своего плана работ, встраиваемого в общий график реализации проекта. Подобная гармонизация задачи управления требованиями и фактической реализации проекта – то серьёзный профессиональный вызов для инициаторов и исполнителей проекта, поскольку без результатов проверки требования может быть невозможно продолжение проекта в целом. Даже простое требование, например, прокрутка турбины в рабочем режиме в течение 72-х часов, требует создание специальной тестовой системы. А соответственно, надо сделать проект этой системы, надо утвердить этот проект в надзорных органах, построить тестовую систему и проверить её, а потом начать опробование тестируемого оборудования. После завершения работ – тестовую систему надо демонтировать и утилизировать оставшиеся материалы. Результаты таких тестов сохраняются в информационной модели и через ссылки на видео или фото поток, на результаты лабораторных замеров, на экспертизу независимых специалистов и контролеров с электронной подписью. Как видно, для самой системы управления требованиями тоже потребуется создать высокопрофессиональное техническое задание и превратить его в стандартное приложение BIM-платформ. Безусловно, наличие такого Приложения может быть обязательным для исполнения Заказчиками, а может быть рекомендованным, но, если речь идет о безопасности строящихся объектов и работе по редевелопменту – дискуссии отпадают.
2. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К BIM-СЕТЯМ, BIM-ПЛАТФОРМАМ И BIM-БАЗАМ ДАННЫХ.
Как видно из предыдущего описания, подсистема управления требованиями становится наиважнейшим элементом BIM-платформы, но автоматически порождает целый набор вопросов, решение которых необходимо для универсализации, стандартизации и автоматизации управления требованиями. Создавать для каждого нового проекта свой уникальный пакет требований – может стать весьма длительной и затратной процедурой, особенно если речь идет о высокотехнологичных наукоемких промышленных проектах. Давайте рассмотрим основные проблемные зоны интеграции деятельности по управлению требованиями в рамках, например, какого-либо профессионального BIM-центра:
1. С точки зрения стандартизации требований, все требования можно разделить на требования институциональные, т.е. такие требования, возникновение которых вызвано источниками внешней среды: стандарты, регламенты, правила, законодательство, политики, убеждения и ценности, государственные традиции и географические условия. С другой стороны, речь идет о требованиях кастомизированных, то есть такие требования, которые уникальны именно для данного проекта и порождаются стейкхолдерами именно в отношении данного проекта или результата.
2. Очевидно, что институциональные требования повторяются для многих проектов, а потому сразу можно говорить о стандартизации требований и стандартизации процессов инжиниринга требований. Лучшим стандартом требований мог бы стать первый и самый важный BIM-стандарт «Состав информационной модели объекта недвижимости», который, в лучшем случае, мог бы дифференцироваться по типам зданий и сооружений. Разумеется, для объектов государственного заказа потребуется государственный BIM-стандарт, который не только описывает базовые требования к составу и наполнению ИМ, но оценку затрат на её создание и ведение. В любом случае, институциональные требования должны быть сразу сформированы в государственные информационные системы требований, например, ГИС ТС – государственной системы требований в строительстве. Такую базу данных, которая безусловно должна быть BIM-адаптированной, мог бы вести тот же Росстандарт или Минстрой.
3. Кастомизированные требования порождаются желаниями Заказчика и прочих стейкхолдеров, качественно отличающих строящийся объект недвижимости от типовых аналогов. Например, это могут быть требования к постархитектурным проектным решениям (имеется ввиду, архитектурные решения как производное типового конструктива), внутреннему наполнению, благоустройству и социальной «эргономичности» или удобстве внешней среды. Эти требования могут быть уникальны и потому они формируются в процессе работы над проектом. Но и в этом случае стандартизация баз данных может иметь место, но в другую сторону. Речь идет о стандартизации решений по удовлетворению требований, вплоть до создания базы данных типовых решений требований. Если у BIM-оператора существует специальная опция BIM-платформы, которая формирует прямые связи между требованиями и их решениями (особенно кастомизированными требованиями), то аналитическим инструментами можно создавать набор типовых решений по каждому похожему требованию. Например, по требованию оригинальности архитектурных решений или детских площадок, по требованиям обеспечения безопасности и т.п. требованиям.
4. Наиболее известным набором требований по реализации проектов с использованием BIM-технологий является BEP – BIM Executive Plan, то есть План Реализации проекта в BIM. Сегодня уже разработаны типовые проформы таких планов, но по сути, все они пока остаются кастомизируемыми под конкретный проект и Заказчика. Очевидно, что само по себе требование реализации проекта в BIM – прекрасный пример автотребования, то есть требования, являющегося основой цифрового управления требованиями. Базовый прототип BIM-проектной документации закладывается в цифровой набор документов BIM-платформы и заполняется автоматически по факту открытия кабинета нового проекта. Не стоит забывать, что реализация проектов с использованием BIM-технологий – это, само по себе, новая форма реализации проектов и, соответственно, новый набор требований к проектной документации.
5. Из последнего соображения вытекает, что требования к порядку реализации проекта в BIM порождают требования к корпоративным, межкорпоративным и отраслевым системам управления проектами, что также может быть прописано в реестре требований. И здесь вопрос состоит не столько в требованиях к интерфейсу или функционалу таких систем, сколько к удовлетворению требований стейкхолдеров о доступе к информации.
3. УПРАВЛЕНИЕ BIM-ТРЕБОВАНИЯМИ К МАТЕРИАЛАМ, КОНСТРУКЦИЯМ И ОБОРУДОВАНИЮ.
Безусловно, говорить о внедрении BIM-технологий, как одного из направлений цифровизации строительной отрасли, вообще, и об использовании цифровой модели требований в частности, без учета требований к промышленности строительных материалов и производителей оборудования – было бы заведомо неправильно. Как мы уже говорили, создание эффективного единого информационного пространства в строительстве возможно при одновременном наличии, во-первых, национальных BIM-платформ – специальных программных продуктов, позволяющих объединять различную информацию из различных источников и обеспечивать её коллаборационное создание, изменение и использование. Во-вторых, это создание сети универсальных BIM-центров (Банков, операторов, хабов), которые и будут основными пользователями BIM-платформ и станут центра концентрации и хранения Информационных моделей. И, наконец, в-третьих, это структурированная и стандартизированная экосистема поставщиков актуальной и целесообразной информации в BIM-Net, которые представляют собой или специализированные компании-поставщики Баз данных, библиотек, справочников, реестров и систем информационной навигации.
Вот именно этот третий элемент и является полем учета требований к продукции предприятий промышленности строительных материалов, производителей строительных конструкций и узлов, вплоть до технологического оборудования. В общем случае можно выделить три ключевых направления цифровой интеграции требований к строительным материалам и результатам проектирования и строительства:
· Создание BIM-адаптированных и перманентно актуализируемых справочников строительных материалов, максимально гармонизированных с международными классификаторами материалов и привязанных к конкретным производителям на основании приложения-навигатора. Проблема создания таких справочников заключается не в том, чтобы перечислить свойства, которыми они удовлетворяют те или иные требования Заказчиков, а в том, чтобы изменения свойств в них происходили моментально и стали известны всем участникам BIM-пространства в части соответствия требованиям. По сути надо создать идеальный информационный портал по материалам и оборудования. Если крупные производители оборудования уже создали свои корпоративные базы и библиотеки данных, включая 3D-модели, монтажные схемы и ППР для монтажа, то производителям строительных материалов не так просто объединиться. Это интеграция конкурентов. Но именно такого оператора производителям стройматериалов придется создавать, может быть и не одного – а по видам материалов. Такая BIM-база данных, которая будет подгружаться к BIM-платформам и индивидуальным BIM-решениям и создаст свою эко-среду поставщиков. Кроме того, она позволит моделировать логистические пулы и искать наиболее выгодные варианты комплексных поставок сразу с логистикой и оценкой стоимости.
· Создание электронных инженерных справочников физико-технических свойств и параметров строительных материалов, необходимых для нового проектирования или ремонта существующих зданий и сооружений в соответствие с требованиями стейкхолдеров. По сути, сегодня выбор тех или иных материалов происходит методом экспертного обсуждения бумажных и электронных каталогов фирм-производителей в проектных организациях или просто берется по соответствующему проекту-аналогу. Эта работа часто не приводит к выбору наилучшего материала или к моделированию оптимальной совокупности. А решается императивно ГИПом проекта с соответствующим убеждением Заказчика. BIM-технологии позволяют задавать технические параметры и требования к зданиям и сооружениям, например, по теплопроводности, шумозащите, энергосбережению, пожарной и иной безопасности, а программы должны сами выбирать из предлагаемого перечня материалов наиболее комфортные по списку требований. Такие приложения и продукты надо создавать совместно с инжиниринговыми и проектными организациями, но, в любом случае, это будет существенное подспорье в информационном моделировании новых объектов. Особенно если учесть, что такое моделирование должно учитывать важные аспекты инжиниринга жизненного цикла, то есть давать возможность моделирования поведения материалов в процессе длительной эксплуатации. Сюда же относятся и все аспекты использования BIM-синхронизированных электронных альбомов стандартных конструкций, изделий, узлов и иной производной продукции из первичных стройматериалов, имеющих свои индивидуально физико-технические характеристики и свойства (например, сборный железобетон из бетона и армокаркасов). Такие альбомы могут стать серьезным направлением развития BIM-адаптированных блок-чейн технологий в проектировании сложных строительных изделий и конструкций.
· Наконец, вытекающий из предыдущего пункта, вектор цифровой синхронизации требований строительной отрасли и требований к промышленности строительных материалов – это совместное проектирование и производство строительных материалов и изделий под задачи проекта, в том числе, под весьма уникальные свойства и задачи. Такая задача частично уже решается различными BIM-приложениями, на основе проектных расчетов которой можно планировать производство металлоконструкций или железобетонных конструкций на соответствующих предприятиях. А если они еще имеют и BIM-гармонизированные ERP, PDM или MES-системы, то и распределенная в облаке работа по формированию информационной модели приобретает вполне себе законченный и обоснованный вид. Это один момент, другой момент тоже важен. Если предприятие производит 100 видов фасадных покрытий, подвесных потолков, внутренней отделки или инженерных сетей, то приходится производить сразу все и много, без гарантии сбыта. Решением такой проблемы является т.н. удаленные BIM-кабинеты производителей, куда архитекторы и проектировщики могут заходить удаленно и на базе своего проекта делать варианты отделки и обеспечения на основании выставленных требований. На основе выбранных вариантов сразу формируются удаленные заказные спецификации для производства и идет автоматическая корректировка производственной программы производителя. По крайней мере, планирование производства становится более предсказуемым и планомерным. Желательно, чтобы производители однородных материалов (плитка, краска и т.п.) коллективно делали такие виртуальные BIM-кабинеты и давали доступ к ним архитекторам из любой точки мира в соответствие с реестрами требований к проекту.
Какой вывод можно сделать из этого короткого представления об управлении требованиями, об инжиниринге требований и их активного вовлечения в BIM-пространство? Очевидно экспертам и специалистам, что грамотное и эффективное управление требованиями, а теперь и постановка этого управления на высоком уровне автоматизации – существенно упрощает не только все процессы реализации инвестиционно-строительных проектов, но и автоматически гарантирует высокое качество проектирования, высокое качество соответствия пожеланиям заказчика и высокое качество исполнения работ. Это стоит того, чтобы поставить управление требованиями в BIM на профессиональную основу.
Статья 2018 года. Оригинал здесь.