В РФ был ГОСТ Р 58439, который давал определение BIM. Оно основано на определении из международного стандарта ISO 19650. Сейчас этот ГОСТ уже не актуален, взамен планировали подготовить новый документ. Однако за то время, что прошло с отмены 58439 и до текущего момента были приняты другие нормативные документы, в которых термину BIM практически не нашлось места.
Когда у нас идеи информационного моделирования только начинали развиваться, все профессиональное сообщество использовало термин BIM. Связано это было прежде всего с тем, что наша нормативная база в этом направлении была недостаточно развита. С течением развития BIM в России, это направление стало обрастать дополнительными аспектами, которые отражали специфику строительной отрасли России. Теперь мы можем говорить об использовании ТИМ, цифровизации, цифровой трансформации. Можно смотреть на ТИМ как на определение, воспринимая его буквально - оно дается в этой статье. Можно взглянуть шире - как на новую концепцию/методологию/философию строительного производства. Однако смысл слов подменять не стоит.
Если обобщать, в своей сути BIM и ТИМ в каких-то аспектах могут считаться синонимами, особенно если разговор идет про 3D-моделирование зданий и сооружений. Однако ТИМ это следующий этап развития идеи информационного моделирования, развитие которой мы в строительной отрасли России сейчас наблюдаем. На этом этапе к моделированию добавляются те нормативные требования, которые у нас уже есть, а также проявляется специфика процессов и процедур строительного производства в РФ.
В терминах главное, чтоб их все воспринимали одинаково. В моменты становления новых технологий правильно договориться о терминах и использовать их единообразно. Ну и общеприменимые термины, правильно использовать тоже важно. :)
Добрый день, спасибо за комментарий. Ответ на ваш вопрос и есть текст всей статьи. Поясню с другой стороны. Преамбула - я тоже занимался несколько лет проектированием на должности зам.ГИПа и ГИП. Первое, что стоит определить, то что BIM и СОД не одинаковые понятия. Скоро поделюсь статьей, где разбираю эти понятия. СОД это одна из частей технологии BIM или ТИМ. Если смотреть на среду общих данных глазами одного специалиста, то вроде бы СОД не приносит в вашу работу чего-либо существенного. Раньше вы в какую-то папку сгружали результат, а теперь будете в СОД сгружать. Раньше звонили смежнику, а теперь просто пометку на чертеже с вопросом оставите. Раньше на совещаниях все обсуждали, а сейчас в онлайн. И так далее. И вроде одному человеку - что так можно, что по другому можно. Но это только для 1 спеца. Если мы смотрим на проект целиком, то картина меняется сильно. Вы говорите о "культуре проектирования". А что под этим подразумеваете? Могу смело предположить - правильно названные файлы, качественную "чистую" документацию, не захламленную структуру проекта, соблюдение сроков и остальное, что так сильно раздражает, когда хочешь сделать свою часть, а тебе накидали непонятно что, да еще и изменения докинут, когда ты уже почти все сделал. Так я говорю? Ну так для этой культуры нужна некая система. Она пожет быть построена на чем угодно. Можно регламенты написать, сетевой диск поднять, ввести правила работы, общения и остального. Но гораздо проще, когда у проектировщиков есть среда общих данных, в которых это уже все настроено. Когда не нужно лезть и все искать самому. Это все может дать СОД и это только базовые вещи. И это только внутри одной проектной организации. Когда же мы с вами перейдем на рассмотрение процессов, которые происходят в проектах между компаниями, тут откроется совсем другая картина. Кто кому что послал, когда получил или не получил, кто согласовал, почему и на каком основании. Традиционно это выстраивается на основе обмена официальными письмами с подтверждением и т.д. Времени туда уходит очень много. А это все деньги, которые просто пропадают. Фактически внедрение СОД в проект можно сравнить с переходом от проводных телефонов, к беспроводным - мобильникам, с последующим их развитием в смартфоны. А ведь тоже и тот и тот телефон может совершать и принимать звонки, но пользовательские возможности сильно отличаются.
Все верно говорите. Про обучение разговор идет давно. Тут и там возникают курсы разные. Однако проблема сохраняется, т.к. системности в этом обучении нет. Каждый учит так, как ему кажется правильно. ВУЗы еще недостаточно освоили у себя эту тему. Выглядит так, что этот вопрос еще не один год будет длиться.
Отлично! Хорошо, что на этой площадке есть эксперты из предметной области. Будет интересно пообщаться. Можно еще про термин поговорить.
Взял с сайта института генплана Москвы:
Проект по строительству ОКС: Перечень мероприятий, осуществляемых застройщиком, техническим заказчиком, органами государственной власти, органами местного самоуправления и (или) иными организациями, в целях строительства, реконструкции ОКС, ввода такого объекта в эксплуатацию, а также государственной регистрации прав на него, реализация которых может состоять из следующих этапов:
а. приобретение прав на земельный участок, в том числе предоставляемый из земель, находящихся в государственной или муниципальной собственности;
b. утверждение или выдача необходимых для выполнения инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции ОКС сведений, документов, материалов;
c. выполнение инженерных изысканий и осуществление архитектурно-строительного проектирования;
d. строительство, реконструкция ОКС, ввод его в эксплуатацию;e. государственный кадастровый учет и (или) государственная регистрация прав на построенный, реконструированный ОКС.
Это я к чему? К тому, что "проект ОКС" - это все этапы жизненного цикла (как мне видится) до ввода в эксплуатацию. Потом проект ОКС становится просто ОКСом. Это про определения.
А вот теперь про интересное. Некоторое время тому назад, возьмем например года 4, когда только входило в обиход понятие СОД (среда общих данных), действительно было мнение, что это некая система для "всего жизненного цикла (ЖЦ)". Такое понимание нам пришло из международных стандартов по BIM. Практика применения СОД в реальной работе показывает, что да - СОД, как понятие, существует на каждом этапе ЖЦ ОКС, но СОД эта меняется. Как? Можно сказать так, что на этапе П и РД существует одна СОД, к стадии строительства она меняется и уж к стадии эксплуатации меняется еще более существенно. Почему так?
Прежде всего потому, что меняются задачи, которые решает эта система. Причем тут системой лучше называть не только ПО, но и людей, которые в ней работают, а также другие элементы. Т.е. мы же понимаем, что на стадии проектирования и на стадии строительства разные задачи, конечно да, а на стадии эксплуатации они еще сильней отличаются.
В итоге мы имеем, что разные в временном периоде этапы ЖЦ ОКС имеют разные задачи, разные люди вовлечены в работу и, главное, разные данные нужны! Все это неизбежно приведет к тому, что СОД будет организовываться разными системами, которые способны решать задачи того или иного этапа. Получается, что СОД для всего ЖЦ ОКС это некий набор СОДов для каждого этапа, которые интегрированы друг с другом.
В этом видении чуть легче становится и с задачами к ПО и с требованиями. Так общую задачу становится решить легче. Если вы работаете в компании, которая вовлечена в работу на каждом этапе ЖЦ ОКС, то такая задача перед вами стоит.
Так же признаю, что есть другое видение решения этой задачи - создать единую систему, которая способна решать задачи на всем ЖЦ. Есть и примеры вендоров, которые развивают свои решения таким образом.
Мое мнение - универсальный инструмент (а ПО это тоже инструмент) всегда хуже решает конкретную задачу, чем специализированный инструмент. В данном контексте некая система, которая способна решать задачи всего ЖЦ - это универсальный инструмент. Специализированный инструмент - это, например, СОД для этапа проектирования.
Какой именно путь (искать одну систему для всего или собирать пул решений) выбирает каждая компания для себя, исходя из своих возможностей и задач.
Спасибо за ваш комментарий, попробую "защититься". Проект ОКС - проект объекта капитального строительства - принятая в строительной сфере аббревиатура. Так он называется, хоть мне сочетание "проект объекта" тоже немного режет слух. Теперь про ИТ-службу - конечно, она должна принимать участие в выборе ПО. Но не всегда верно будет поручать ИТ-спецам принимать решение по выбору профильного программного обеспечения. Связано это с тем, что бизнес процессы какого-либо производства (а стройка это тоже -строительное производство) лучше знают те специалисты, которые этим занимаются. Поэтому мнение специалистов от бизнеса должно быть не только учтено, но и быть в приоритете. Про прописные истины - вот тут вас поддержу. Действительно написал вещи весьма тривиальные. Удивляет одно - а почему так не делают? Имею богатый опыт в данном направлении и говорю не потому, что так "кажется". Это первая статья. У нее есть продолжение, которое будет чуть "практичней" и будет касаться вывода задач для системы. У нее тоже проблема в том, что написать что-то применимое ко всем не просто. Но я старался :)
Спасибо, Алексей, за внимание к статье. Ваш комментарий первый на моих публикациях!
В РФ был ГОСТ Р 58439, который давал определение BIM. Оно основано на определении из международного стандарта ISO 19650. Сейчас этот ГОСТ уже не актуален, взамен планировали подготовить новый документ. Однако за то время, что прошло с отмены 58439 и до текущего момента были приняты другие нормативные документы, в которых термину BIM практически не нашлось места.
Когда у нас идеи информационного моделирования только начинали развиваться, все профессиональное сообщество использовало термин BIM. Связано это было прежде всего с тем, что наша нормативная база в этом направлении была недостаточно развита. С течением развития BIM в России, это направление стало обрастать дополнительными аспектами, которые отражали специфику строительной отрасли России. Теперь мы можем говорить об использовании ТИМ, цифровизации, цифровой трансформации. Можно смотреть на ТИМ как на определение, воспринимая его буквально - оно дается в этой статье. Можно взглянуть шире - как на новую концепцию/методологию/философию строительного производства. Однако смысл слов подменять не стоит.
Если обобщать, в своей сути BIM и ТИМ в каких-то аспектах могут считаться синонимами, особенно если разговор идет про 3D-моделирование зданий и сооружений. Однако ТИМ это следующий этап развития идеи информационного моделирования, развитие которой мы в строительной отрасли России сейчас наблюдаем. На этом этапе к моделированию добавляются те нормативные требования, которые у нас уже есть, а также проявляется специфика процессов и процедур строительного производства в РФ.
В терминах главное, чтоб их все воспринимали одинаково. В моменты становления новых технологий правильно договориться о терминах и использовать их единообразно. Ну и общеприменимые термины, правильно использовать тоже важно. :)
Добрый день, спасибо за комментарий. Ответ на ваш вопрос и есть текст всей статьи. Поясню с другой стороны. Преамбула - я тоже занимался несколько лет проектированием на должности зам.ГИПа и ГИП. Первое, что стоит определить, то что BIM и СОД не одинаковые понятия. Скоро поделюсь статьей, где разбираю эти понятия. СОД это одна из частей технологии BIM или ТИМ. Если смотреть на среду общих данных глазами одного специалиста, то вроде бы СОД не приносит в вашу работу чего-либо существенного. Раньше вы в какую-то папку сгружали результат, а теперь будете в СОД сгружать. Раньше звонили смежнику, а теперь просто пометку на чертеже с вопросом оставите. Раньше на совещаниях все обсуждали, а сейчас в онлайн. И так далее. И вроде одному человеку - что так можно, что по другому можно. Но это только для 1 спеца. Если мы смотрим на проект целиком, то картина меняется сильно. Вы говорите о "культуре проектирования". А что под этим подразумеваете? Могу смело предположить - правильно названные файлы, качественную "чистую" документацию, не захламленную структуру проекта, соблюдение сроков и остальное, что так сильно раздражает, когда хочешь сделать свою часть, а тебе накидали непонятно что, да еще и изменения докинут, когда ты уже почти все сделал. Так я говорю? Ну так для этой культуры нужна некая система. Она пожет быть построена на чем угодно. Можно регламенты написать, сетевой диск поднять, ввести правила работы, общения и остального. Но гораздо проще, когда у проектировщиков есть среда общих данных, в которых это уже все настроено. Когда не нужно лезть и все искать самому. Это все может дать СОД и это только базовые вещи. И это только внутри одной проектной организации. Когда же мы с вами перейдем на рассмотрение процессов, которые происходят в проектах между компаниями, тут откроется совсем другая картина. Кто кому что послал, когда получил или не получил, кто согласовал, почему и на каком основании. Традиционно это выстраивается на основе обмена официальными письмами с подтверждением и т.д. Времени туда уходит очень много. А это все деньги, которые просто пропадают. Фактически внедрение СОД в проект можно сравнить с переходом от проводных телефонов, к беспроводным - мобильникам, с последующим их развитием в смартфоны. А ведь тоже и тот и тот телефон может совершать и принимать звонки, но пользовательские возможности сильно отличаются.
Все верно говорите. Про обучение разговор идет давно. Тут и там возникают курсы разные. Однако проблема сохраняется, т.к. системности в этом обучении нет. Каждый учит так, как ему кажется правильно. ВУЗы еще недостаточно освоили у себя эту тему. Выглядит так, что этот вопрос еще не один год будет длиться.
Отлично! Хорошо, что на этой площадке есть эксперты из предметной области. Будет интересно пообщаться. Можно еще про термин поговорить.
Взял с сайта института генплана Москвы:
Проект по строительству ОКС:
Перечень мероприятий, осуществляемых застройщиком, техническим заказчиком, органами государственной власти, органами местного самоуправления и (или) иными организациями, в целях строительства, реконструкции ОКС, ввода такого объекта в эксплуатацию, а также государственной регистрации прав на него, реализация которых может состоять из следующих этапов:
а. приобретение прав на земельный участок, в том числе предоставляемый из земель, находящихся в государственной или муниципальной собственности;
b. утверждение или выдача необходимых для выполнения инженерных изысканий, архитектурно-строительного проектирования, строительства, реконструкции ОКС сведений, документов, материалов;
c. выполнение инженерных изысканий и осуществление архитектурно-строительного проектирования;
d. строительство, реконструкция ОКС, ввод его в эксплуатацию;e. государственный кадастровый учет и (или) государственная регистрация прав на построенный, реконструированный ОКС.
Это я к чему? К тому, что "проект ОКС" - это все этапы жизненного цикла (как мне видится) до ввода в эксплуатацию. Потом проект ОКС становится просто ОКСом. Это про определения.
А вот теперь про интересное. Некоторое время тому назад, возьмем например года 4, когда только входило в обиход понятие СОД (среда общих данных), действительно было мнение, что это некая система для "всего жизненного цикла (ЖЦ)". Такое понимание нам пришло из международных стандартов по BIM. Практика применения СОД в реальной работе показывает, что да - СОД, как понятие, существует на каждом этапе ЖЦ ОКС, но СОД эта меняется. Как? Можно сказать так, что на этапе П и РД существует одна СОД, к стадии строительства она меняется и уж к стадии эксплуатации меняется еще более существенно. Почему так?
Прежде всего потому, что меняются задачи, которые решает эта система. Причем тут системой лучше называть не только ПО, но и людей, которые в ней работают, а также другие элементы. Т.е. мы же понимаем, что на стадии проектирования и на стадии строительства разные задачи, конечно да, а на стадии эксплуатации они еще сильней отличаются.
В итоге мы имеем, что разные в временном периоде этапы ЖЦ ОКС имеют разные задачи, разные люди вовлечены в работу и, главное, разные данные нужны! Все это неизбежно приведет к тому, что СОД будет организовываться разными системами, которые способны решать задачи того или иного этапа. Получается, что СОД для всего ЖЦ ОКС это некий набор СОДов для каждого этапа, которые интегрированы друг с другом.
В этом видении чуть легче становится и с задачами к ПО и с требованиями. Так общую задачу становится решить легче. Если вы работаете в компании, которая вовлечена в работу на каждом этапе ЖЦ ОКС, то такая задача перед вами стоит.
Так же признаю, что есть другое видение решения этой задачи - создать единую систему, которая способна решать задачи на всем ЖЦ. Есть и примеры вендоров, которые развивают свои решения таким образом.
Мое мнение - универсальный инструмент (а ПО это тоже инструмент) всегда хуже решает конкретную задачу, чем специализированный инструмент. В данном контексте некая система, которая способна решать задачи всего ЖЦ - это универсальный инструмент. Специализированный инструмент - это, например, СОД для этапа проектирования.
Какой именно путь (искать одну систему для всего или собирать пул решений) выбирает каждая компания для себя, исходя из своих возможностей и задач.
Как новую статью опубликую - ссылку пришлю.
Спасибо за ваш комментарий, попробую "защититься". Проект ОКС - проект объекта капитального строительства - принятая в строительной сфере аббревиатура. Так он называется, хоть мне сочетание "проект объекта" тоже немного режет слух. Теперь про ИТ-службу - конечно, она должна принимать участие в выборе ПО. Но не всегда верно будет поручать ИТ-спецам принимать решение по выбору профильного программного обеспечения. Связано это с тем, что бизнес процессы какого-либо производства (а стройка это тоже -строительное производство) лучше знают те специалисты, которые этим занимаются. Поэтому мнение специалистов от бизнеса должно быть не только учтено, но и быть в приоритете. Про прописные истины - вот тут вас поддержу. Действительно написал вещи весьма тривиальные. Удивляет одно - а почему так не делают? Имею богатый опыт в данном направлении и говорю не потому, что так "кажется". Это первая статья. У нее есть продолжение, которое будет чуть "практичней" и будет касаться вывода задач для системы. У нее тоже проблема в том, что написать что-то применимое ко всем не просто. Но я старался :)
Спасибо, Алексей, за внимание к статье. Ваш комментарий первый на моих публикациях!
1