#Классификатор #Интриги
Спасибо специалистам за подробный анализ классификаторов, достаточно конкретный и по делу, без лишней воды. Но считаю вывод к которому пришли специалисты не верным, что они считают Шведский классификатор и Датский более прогрессивными. Сам подход к классам верный, но к отображению его считаю не верным.
Считаю необходимым проверить на практике: в каких фирмах работают на его основе, с приведением скриншотов из моделей (Navisworks, Synchro), т.е. если начинать свой классификатор разрабатывать на основе их, т.е. если прям принимать ответственное решение и выделять на это средства, то необходимо убедиться в том, что это не только теория, но и рабочий механизм.
Моё мнение что классификаторы "3 поколения" не работают из-за того, что структура изрядно запутанная, и даже, если один код расшифровать для пользователя, или объяснить, как элемент зашифровывается, то соседний элемент пользователь уже не сможет зашифровать, т.е. по уровню сложности может и 3го поколения классификаторы, но по применимости явно тупиковое направление из-за чрезмерной сложности.
Многие, конечно, не говорят об этом, т.к. мол считается что признать, что для них сложно - это мол не солидно, но когда это вынесется на практику, то все просто забьют на это и будут саботировать применение.
Примерно как получилось с ценами на ресурсные расценки ФЦС (т.е. опыт у нас уже есть - как все кричали: "как прикажем, как закон сделаем, так и будет!" - а по факту, когда не рабочая, невыполнимая схема, то никакой закон не заставит работать, хоть там расстрелом ответственность прописать).
Спасибо специалистам за подробный анализ классификаторов, достаточно конкретный и по делу, без лишней воды. Но считаю вывод к которому пришли специалисты не верным, что они считают Шведский классификатор и Датский более прогрессивными. Сам подход к классам верный, но к отображению его считаю не верным.
Считаю необходимым проверить на практике: в каких фирмах работают на его основе, с приведением скриншотов из моделей (Navisworks, Synchro), т.е. если начинать свой классификатор разрабатывать на основе их, т.е. если прям принимать ответственное решение и выделять на это средства, то необходимо убедиться в том, что это не только теория, но и рабочий механизм.
Моё мнение что классификаторы "3 поколения" не работают из-за того, что структура изрядно запутанная, и даже, если один код расшифровать для пользователя, или объяснить, как элемент зашифровывается, то соседний элемент пользователь уже не сможет зашифровать, т.е. по уровню сложности может и 3го поколения классификаторы, но по применимости явно тупиковое направление из-за чрезмерной сложности.
Многие, конечно, не говорят об этом, т.к. мол считается что признать, что для них сложно - это мол не солидно, но когда это вынесется на практику, то все просто забьют на это и будут саботировать применение.
Примерно как получилось с ценами на ресурсные расценки ФЦС (т.е. опыт у нас уже есть - как все кричали: "как прикажем, как закон сделаем, так и будет!" - а по факту, когда не рабочая, невыполнимая схема, то никакой закон не заставит работать, хоть там расстрелом ответственность прописать).
👍1
#Классификатор #Интриги
В дополнение к предыдущему письму хочу также отметить, что по всей видимости руководителям, кто планирует принять в разработку текущий проект классификатора понравилась подача от Владимира Волкодава, что мол есть классификаторы 2 поколения и 3го - эта классификация выдумана им и прошу не относиться к этому как к факту. Есть иерархический подход к классификации, есть фасетный. За определениями идите в википедию. Эти принципы не отображают прогрессивности подхода или качество, это просто разные подходы. В данном контексте Владимир использовал свою введенную группировку классификаторов в корыстных целях - для введения в заблуждение лиц принимающих решение по выделению средств на проект, чтобы таким образом обосновать предлагаемый подход.
Также, было заметно, что коллег, руководителей, принимающих решение по проекту, подкупил тот аргумент, что мол для применения фасетного (Датского) классификатора нужно разработать меньше классов, мол всего 750, а в Omniclass ооо сколько позиций. Т.е. это желание халявы, мол разработать меньше, дешевле, мол быстрее, а результата мол больше. Так вот, во-первых, чудес не бывает, уважаемые коллеги, и, от типа классификации, количество сущностей в строительном процессе не изменится. Оценить стоимость и привязать сроки вам по-прежнему придется для всех элементов. Во-вторых, фасетный принцип классификации касается лишь описания строительных элементов. Реализацию по такому принципу классификации видов работ, материалов я даже не могу себе представить. Представляю удивление минстроя, когда через 2 года на вопрос мол "ну вот модель классифицирована, а как посчитать деньги?" - Владимир ответит: "Нужно разработать классификатор видов работ - еще 2 года".
Фасетный принцип классификации создает большое количество несуществующих позиций, т.е. когда мы по двум аспектам составим например по 10 классов в каждом, то количество их сопоставлений будет 10х10. И так при добавлении каждого аспекта. Т.е. 20 классов порождают нам 100 сущностей, из которых вполне вероятно 50 не будет и существовать, но пользователь при выборе будет иметь возможность указать их комбинацию, т.е. условно говоря в классификаторе имеется огромное количество пустых областей (это если бы вы искали файлы и проходя по папкам они оказывались пустыми).
Самый лучший вариант проверить удобство классификатора - это попросить нескольких людей, с помощью какого-нибудь небольшого примера классификатора, одновременно, без коммуникации классифицировать одну и ту же модель, а затем сравнить насколько они классифицировали элементы одинаково. Это будет показывать, насколько структура классификатора позволит одному (пользователю) найти нужные объекты в структуре другого (разработчика).
В дополнение к предыдущему письму хочу также отметить, что по всей видимости руководителям, кто планирует принять в разработку текущий проект классификатора понравилась подача от Владимира Волкодава, что мол есть классификаторы 2 поколения и 3го - эта классификация выдумана им и прошу не относиться к этому как к факту. Есть иерархический подход к классификации, есть фасетный. За определениями идите в википедию. Эти принципы не отображают прогрессивности подхода или качество, это просто разные подходы. В данном контексте Владимир использовал свою введенную группировку классификаторов в корыстных целях - для введения в заблуждение лиц принимающих решение по выделению средств на проект, чтобы таким образом обосновать предлагаемый подход.
Также, было заметно, что коллег, руководителей, принимающих решение по проекту, подкупил тот аргумент, что мол для применения фасетного (Датского) классификатора нужно разработать меньше классов, мол всего 750, а в Omniclass ооо сколько позиций. Т.е. это желание халявы, мол разработать меньше, дешевле, мол быстрее, а результата мол больше. Так вот, во-первых, чудес не бывает, уважаемые коллеги, и, от типа классификации, количество сущностей в строительном процессе не изменится. Оценить стоимость и привязать сроки вам по-прежнему придется для всех элементов. Во-вторых, фасетный принцип классификации касается лишь описания строительных элементов. Реализацию по такому принципу классификации видов работ, материалов я даже не могу себе представить. Представляю удивление минстроя, когда через 2 года на вопрос мол "ну вот модель классифицирована, а как посчитать деньги?" - Владимир ответит: "Нужно разработать классификатор видов работ - еще 2 года".
Фасетный принцип классификации создает большое количество несуществующих позиций, т.е. когда мы по двум аспектам составим например по 10 классов в каждом, то количество их сопоставлений будет 10х10. И так при добавлении каждого аспекта. Т.е. 20 классов порождают нам 100 сущностей, из которых вполне вероятно 50 не будет и существовать, но пользователь при выборе будет иметь возможность указать их комбинацию, т.е. условно говоря в классификаторе имеется огромное количество пустых областей (это если бы вы искали файлы и проходя по папкам они оказывались пустыми).
Самый лучший вариант проверить удобство классификатора - это попросить нескольких людей, с помощью какого-нибудь небольшого примера классификатора, одновременно, без коммуникации классифицировать одну и ту же модель, а затем сравнить насколько они классифицировали элементы одинаково. Это будет показывать, насколько структура классификатора позволит одному (пользователю) найти нужные объекты в структуре другого (разработчика).
👍2
#Классификатор #Интриги Предложения по прошедшему заседанию:
1. Требуется провести общую презентацию для рабочей группы по тому, что уже было сделано по BIM в России, какие ведомства, ТК и ПТК что сейчас по этой сфере разрабатывают. Считаю, что хорошо может рассказать Марина Георгиевна Король. Со своей стороны могу рассказать про опыт работы клуба BIM-лидеров на площадке Autodesk. Может у BIM-ассоциации будет что рассказать.
2. Прежде чем утверждать проект по классификаторам на 2 года и садиться ждать, предлагаю заказать тому же Владимиру Волкодаву разработать Техническое задание на разработку классификатора, в рамках которого он подготовит разъяснительные материалы в виде статей и видео, о том, как будет работать данный классификатор. Данную работу необходимо сделать на реальном небольшом объекте, возможно коттедже или поликлинике. Я бы оценил работу в 300-500 тыс. руб. и 3 месяца срок. Также в ТЗ должен быть разработан график с вехами и датами отчетности и формат этих отчетов. Если рабочую группу привлекают к этому процессу, то вполне могли бы иметь место презентации на рабочей группе.
3. Требуется перевод и адаптация классификаторов Uniclass и Omniclass.
4. Требуется исследование Датского опыта, найти компанию, кто у них работает в BIM и использует CCS. Попросить их провести вебинар (на англ.) и показать как работает их система на практике.
5. Требуется организовать чат в Телеграм или WhatsApp или группу в fb.com, где рабочая группа может обсуждать внутри себя вопросы, возможно публично, чтобы все могли подключаться. Пока практика показывает, что эл. письма позволяют все предложения и замечания игнорировать, почта со всеми в копии - не вариант, т.к. вынуждает постоянно просматривать вдруг важное письмо, а чат фоном может висеть и периодически его проматывать когда удобно.
6. Разослать всем участникам на ознакомление ГОСТ 12006-2 https://files.stroyinf.ru/Data/647/64715.pdf, отчет по сравнению классификаторов от НИЦ ЦПС.
7. Адаптировать документ ІЕС 81346-1(2009), чтобы можно было на него ссылаться. Владимир мне прислал пример Казахских коллег. https://drive.google.com/open?id=1Qo5XXQASK-MWGyvZ8o3jBGrhNHbSkDJy
8. Хотел бы отметить, что принятие проекта внедрения BIM, если рабочая группа действительно участвует в нём (в принятии), не должно быть формальным, мол выслушали, не сказали сразу замечания (иногда ведь надо обдумать, подготовиться) - значит приняли. Т.е. надо организовать платформу, на которой можно было собрать единый реестр замечаний, я бы предложил Google Таблицы, на которые давать доступ по учетной записи google - по запросу. Т.е. в один столбец замечание - в другой - ответ, и комментариями обсуждения - мини-чаты.
1. Требуется провести общую презентацию для рабочей группы по тому, что уже было сделано по BIM в России, какие ведомства, ТК и ПТК что сейчас по этой сфере разрабатывают. Считаю, что хорошо может рассказать Марина Георгиевна Король. Со своей стороны могу рассказать про опыт работы клуба BIM-лидеров на площадке Autodesk. Может у BIM-ассоциации будет что рассказать.
2. Прежде чем утверждать проект по классификаторам на 2 года и садиться ждать, предлагаю заказать тому же Владимиру Волкодаву разработать Техническое задание на разработку классификатора, в рамках которого он подготовит разъяснительные материалы в виде статей и видео, о том, как будет работать данный классификатор. Данную работу необходимо сделать на реальном небольшом объекте, возможно коттедже или поликлинике. Я бы оценил работу в 300-500 тыс. руб. и 3 месяца срок. Также в ТЗ должен быть разработан график с вехами и датами отчетности и формат этих отчетов. Если рабочую группу привлекают к этому процессу, то вполне могли бы иметь место презентации на рабочей группе.
3. Требуется перевод и адаптация классификаторов Uniclass и Omniclass.
4. Требуется исследование Датского опыта, найти компанию, кто у них работает в BIM и использует CCS. Попросить их провести вебинар (на англ.) и показать как работает их система на практике.
5. Требуется организовать чат в Телеграм или WhatsApp или группу в fb.com, где рабочая группа может обсуждать внутри себя вопросы, возможно публично, чтобы все могли подключаться. Пока практика показывает, что эл. письма позволяют все предложения и замечания игнорировать, почта со всеми в копии - не вариант, т.к. вынуждает постоянно просматривать вдруг важное письмо, а чат фоном может висеть и периодически его проматывать когда удобно.
6. Разослать всем участникам на ознакомление ГОСТ 12006-2 https://files.stroyinf.ru/Data/647/64715.pdf, отчет по сравнению классификаторов от НИЦ ЦПС.
7. Адаптировать документ ІЕС 81346-1(2009), чтобы можно было на него ссылаться. Владимир мне прислал пример Казахских коллег. https://drive.google.com/open?id=1Qo5XXQASK-MWGyvZ8o3jBGrhNHbSkDJy
8. Хотел бы отметить, что принятие проекта внедрения BIM, если рабочая группа действительно участвует в нём (в принятии), не должно быть формальным, мол выслушали, не сказали сразу замечания (иногда ведь надо обдумать, подготовиться) - значит приняли. Т.е. надо организовать платформу, на которой можно было собрать единый реестр замечаний, я бы предложил Google Таблицы, на которые давать доступ по учетной записи google - по запросу. Т.е. в один столбец замечание - в другой - ответ, и комментариями обсуждения - мини-чаты.
👍1
#Подкасты 25.05 прошёл открытый клуб BIM-лидеров Autodesk.
Запись можно посмотреть по ссылке: https://cutt.ly/2nt6iNn
1 час - доклады участников клуба
2 и 3 часы - круглый стол по классификатору КСИ
Свои тезисы из экспресс-анализа КСИ напишу в следующих постах.
Запись можно посмотреть по ссылке: https://cutt.ly/2nt6iNn
1 час - доклады участников клуба
2 и 3 часы - круглый стол по классификатору КСИ
Свои тезисы из экспресс-анализа КСИ напишу в следующих постах.
#Классификатор строительной информации КСИ. Часть 1.
ksi.faufcc.ru
Состоит из 21 таблицы. Таблицы сгруппированы по группам.
Результат (1-6 таблицы)
Процесс (7-15)
Ресурс (16-20)
Характеристика (21 таблица)
Большинство таблиц не касается информационных моделей в узком смысле (где элементы моделируются в Revit, ArchiCAD, Allplan, Tekla, Renga).
Касаются BIM только:
1 RZo - зона; помещение
4 FnS - функциональная система
5 TeS - техническая система
6 Com - компонент
21 Prp - характеристика
Остальные таблицы это перегруппированные пункты из международных ИСО по менеджменту строительных процессов, ГЭСНов, КСРа, приказов и уже использующихся классфикаторов в РФ.
1 таблица про помещения и зоны - полезная, но незаполненная. Многих помещений нет. Требуется наполнение и переделать группировку помещений по более однозначным признакам, т.к. н-р под "помещение для пребывания людей" подпадают все помещения.
21 таблица про характеристики могла бы быть просто атрибутами у классов, ни к чему их выделять в отдельную таблицу группировать и присваивать коды.
4,5 и 6 таблицы - это суть методики классификации предложенной Владимиром Волкодавом, которую стоит обсуждать в разрезе информационного моделирования. Потому что эти коды могут попросить (обязать) заполнять в элементы информационной модели.
Когда Владимир говорит про фасетную классификацию или мол особый "прогрессивный" подход - это касается именно этих трёх таблиц. Остальные таблицы вполне себе стандартные иерархические как ГЭСН и КСР.
ksi.faufcc.ru
Состоит из 21 таблицы. Таблицы сгруппированы по группам.
Результат (1-6 таблицы)
Процесс (7-15)
Ресурс (16-20)
Характеристика (21 таблица)
Большинство таблиц не касается информационных моделей в узком смысле (где элементы моделируются в Revit, ArchiCAD, Allplan, Tekla, Renga).
Касаются BIM только:
1 RZo - зона; помещение
4 FnS - функциональная система
5 TeS - техническая система
6 Com - компонент
21 Prp - характеристика
Остальные таблицы это перегруппированные пункты из международных ИСО по менеджменту строительных процессов, ГЭСНов, КСРа, приказов и уже использующихся классфикаторов в РФ.
1 таблица про помещения и зоны - полезная, но незаполненная. Многих помещений нет. Требуется наполнение и переделать группировку помещений по более однозначным признакам, т.к. н-р под "помещение для пребывания людей" подпадают все помещения.
21 таблица про характеристики могла бы быть просто атрибутами у классов, ни к чему их выделять в отдельную таблицу группировать и присваивать коды.
4,5 и 6 таблицы - это суть методики классификации предложенной Владимиром Волкодавом, которую стоит обсуждать в разрезе информационного моделирования. Потому что эти коды могут попросить (обязать) заполнять в элементы информационной модели.
Когда Владимир говорит про фасетную классификацию или мол особый "прогрессивный" подход - это касается именно этих трёх таблиц. Остальные таблицы вполне себе стандартные иерархические как ГЭСН и КСР.
#Классификатор строительной информации КСИ. Часть 2.
Прежде чем перейдем к сути таблиц 4-6, пару слов по форме.
Коды классификатора выглядят в непривычном для российского специалиста виде. Нам это преподносят как нечто прогрессивное и мол так должно быть по ISO и без этого никак.
Н-р код помещения:
RZo>AAA010 - Гостиная
RZo - ключ,указывающий на определенную таблицу, по которой надо смотреть следующие значения.
> - знак разделителя кода указателя от кода классификатора
AAA010 - код по таблице “зона; помещение".
На самом деле в кодах можно применять и кириллические символы и цифры, т.е. например отобразить код так
КСИ 01.10.10.110 - Гостиная
либо КСИ ПЗ 10 10 110
Как десятки уже используемых в РФ классификаторов типа ОКПД2, ОКУД, ОКВЭД2 или ФЕРы, ГЭСНы. (Мне с точками больше нравится).
Прежде чем перейдем к сути таблиц 4-6, пару слов по форме.
Коды классификатора выглядят в непривычном для российского специалиста виде. Нам это преподносят как нечто прогрессивное и мол так должно быть по ISO и без этого никак.
Н-р код помещения:
RZo>AAA010 - Гостиная
RZo - ключ,указывающий на определенную таблицу, по которой надо смотреть следующие значения.
> - знак разделителя кода указателя от кода классификатора
AAA010 - код по таблице “зона; помещение".
На самом деле в кодах можно применять и кириллические символы и цифры, т.е. например отобразить код так
КСИ 01.10.10.110 - Гостиная
либо КСИ ПЗ 10 10 110
Как десятки уже используемых в РФ классификаторов типа ОКПД2, ОКУД, ОКВЭД2 или ФЕРы, ГЭСНы. (Мне с точками больше нравится).
#Классификатор строительной информации КСИ. Часть 3.
Идея 3 таблиц (Функциональные системы, Технические и Компоненты) возникла из соображений создать 3 кода на каждый аспект, описывающий элемент с определенной стороны. И в купе все три кода дают нам однозначное понимание что перед нами за элемент.
Такой подход эффективен для разделения одинаковых элементов, но применяемых для разных систем (например одинаковые трубы для ОВ и ВК) или стены ниже 0 и выше. Потому что, если включить разбивку по отметке 0 в структуру иерархического классификатора, то это приведет к дублированию позиций в обеих ветках.
В то же время, такой подход не эффективен для случаев, когда один элемент встречается только в одной системе и не применяется в других. Это приведет к дублированию функции в дереве выбора компонентов (в текущей версии это называют другими словами).
В нашей сфере (судя по уже имеющимся классификаторам) 90% элементов являются специализированными для своих систем, т.е. выделение системы как отдельный аспект происходит из-за 10% элементов и вынуждает придумывать формальные признаки группировок для классификатора компонентов.
Также в нашей сфере техническая и функциональная системы очень похожи для 80% элементов, что приводит к дублированию их разбивки (и только наименование одного и того же разными словами лишь как-то это прикрывает в текущем КСИ).
Я считаю, что функциональная система может быть одним из уровней деления классификатора, допустив 10% дублирующихся элементов (и можно применить параллельную классификацию). Технические системы добавить к функциональным в той части, где не дублируются.
Принцип отдельного классификатора надо применить к местоположению. Но мы заранее не знаем разбивку объекта, потому для неё нужно задать логику, правила наименования и примеры.
Идея 3 таблиц (Функциональные системы, Технические и Компоненты) возникла из соображений создать 3 кода на каждый аспект, описывающий элемент с определенной стороны. И в купе все три кода дают нам однозначное понимание что перед нами за элемент.
Такой подход эффективен для разделения одинаковых элементов, но применяемых для разных систем (например одинаковые трубы для ОВ и ВК) или стены ниже 0 и выше. Потому что, если включить разбивку по отметке 0 в структуру иерархического классификатора, то это приведет к дублированию позиций в обеих ветках.
В то же время, такой подход не эффективен для случаев, когда один элемент встречается только в одной системе и не применяется в других. Это приведет к дублированию функции в дереве выбора компонентов (в текущей версии это называют другими словами).
В нашей сфере (судя по уже имеющимся классификаторам) 90% элементов являются специализированными для своих систем, т.е. выделение системы как отдельный аспект происходит из-за 10% элементов и вынуждает придумывать формальные признаки группировок для классификатора компонентов.
Также в нашей сфере техническая и функциональная системы очень похожи для 80% элементов, что приводит к дублированию их разбивки (и только наименование одного и того же разными словами лишь как-то это прикрывает в текущем КСИ).
Я считаю, что функциональная система может быть одним из уровней деления классификатора, допустив 10% дублирующихся элементов (и можно применить параллельную классификацию). Технические системы добавить к функциональным в той части, где не дублируются.
Принцип отдельного классификатора надо применить к местоположению. Но мы заранее не знаем разбивку объекта, потому для неё нужно задать логику, правила наименования и примеры.
#Подкасты В среду 02.06 в 19:00 мск планируем подкаст в @bimclub
на тему: Классификатор строительной информации (КСИ) - что не так?
Решили, что осталось еще что обсудить после клуба BIM-лидеров.
https://youtu.be/t3yAtQuk_KM?t=3572
Кто хочет высказаться - пишите в ЛС @popov_bim - добавлю
Спикеры:
Александр Попов, Илья Беленький, Алексей Лобанов, Алексей Крылов (будут добавляться).
Может разработчик Владимир Волкодав все-таки выйдет на диалог?)
на тему: Классификатор строительной информации (КСИ) - что не так?
Решили, что осталось еще что обсудить после клуба BIM-лидеров.
https://youtu.be/t3yAtQuk_KM?t=3572
Кто хочет высказаться - пишите в ЛС @popov_bim - добавлю
Спикеры:
Александр Попов, Илья Беленький, Алексей Лобанов, Алексей Крылов (будут добавляться).
Может разработчик Владимир Волкодав все-таки выйдет на диалог?)
YouTube
Открытая встреча Клуба BIM-лидеров, 25 мая 2021
Запись первой открытой встречи Клуба BIM-лидеров Autodesk.
Действующие члены Клуба представляют доклады, отобранные на отчетном заседании по итогам 2020 года и обсуждают за круглым столом тему: "Практика использования классификатора строительной информации".…
Действующие члены Клуба представляют доклады, отобранные на отчетном заседании по итогам 2020 года и обсуждают за круглым столом тему: "Практика использования классификатора строительной информации".…
014_bimclub_Что не так с КСИ
<unknown>
#Подкасты Вчера провели подкаст в @bimclub на тему:
Классификатор строительной информации КСИ - что не так?
Выступили Артем Рыжков и Илья Беленький с предложением не делать Франкенштейна и убрать таблицы по ISO 81346, сделав все таблицы по ISO 12006.
Алексей Лобанов обозначил, что в первую очередь надо обозначить цели применения классификатора и согласился, что должна быть возможность использовать каждую таблицу классификатора по отдельности.
Алексей Крылов попробовал объяснить логику разработчиков классификатора (как сам понял), выступил с поддержкой классификатора КСИ и сказал что они у себя в YIT на его основе сделали свой (думаю этот пример надо поизучать подробнее).
Илья Усов предложил написать конкретные предложения в Минстрой и ФАУ ФЦС и заняться обсуждением онтологии (что имел в виду - с этим надо будет поразбираться отдельно - пока выглядит как очередной никому непонятный термин на котором можно порубить бабла, когда со сметами из ИИ уже не канает)
Классификатор строительной информации КСИ - что не так?
Выступили Артем Рыжков и Илья Беленький с предложением не делать Франкенштейна и убрать таблицы по ISO 81346, сделав все таблицы по ISO 12006.
Алексей Лобанов обозначил, что в первую очередь надо обозначить цели применения классификатора и согласился, что должна быть возможность использовать каждую таблицу классификатора по отдельности.
Алексей Крылов попробовал объяснить логику разработчиков классификатора (как сам понял), выступил с поддержкой классификатора КСИ и сказал что они у себя в YIT на его основе сделали свой (думаю этот пример надо поизучать подробнее).
Илья Усов предложил написать конкретные предложения в Минстрой и ФАУ ФЦС и заняться обсуждением онтологии (что имел в виду - с этим надо будет поразбираться отдельно - пока выглядит как очередной никому непонятный термин на котором можно порубить бабла, когда со сметами из ИИ уже не канает)
#Теория "BIM - это не 3D!"
Часто можно услышать, что BIM - это не 3D, что инструменты не главное, мол важнее методология и процессы, чем знание инструмента.
Обычно это говорят те, кто не владеет инструментом для информационного моделирования и пытаются сделать вид что это норм и так и должно быть. Будто им для генерации своих теорий не нужны прикладные знания и мол BIM можно и на бумаге внедрить. (Есть еще те, кто считает календарный график или смету сутью BIM, но об этом отдельно).
На самом деле, знание инструмента для внедрения BIM, для генерации стандартов и организации процесса - очень важно, т.к. инструмент очень ограничивает, не зная этих ограничений можно придумать нерабочий процесс или написать крайне трудоемкое требование, за которое никто не готов будет платить.
Такие люди лучше знают Word и Excel и от того предлагают с их помощью писать ТЗ на новые программы, разрабатывать стандарты и классификаторы. Т.е. они придумывают, как инструментарием, которым они владеют - решить задачи новой технологии.
На процессы можно влиять организационно (приказами и стандартами, наказывая людей), а можно программно - не давая возможности на уровне инструмента сделать не правильно. Программная стандартизация замещает организационную и инструменты все большее имеют значение.
Часто можно услышать, что BIM - это не 3D, что инструменты не главное, мол важнее методология и процессы, чем знание инструмента.
Обычно это говорят те, кто не владеет инструментом для информационного моделирования и пытаются сделать вид что это норм и так и должно быть. Будто им для генерации своих теорий не нужны прикладные знания и мол BIM можно и на бумаге внедрить. (Есть еще те, кто считает календарный график или смету сутью BIM, но об этом отдельно).
На самом деле, знание инструмента для внедрения BIM, для генерации стандартов и организации процесса - очень важно, т.к. инструмент очень ограничивает, не зная этих ограничений можно придумать нерабочий процесс или написать крайне трудоемкое требование, за которое никто не готов будет платить.
Такие люди лучше знают Word и Excel и от того предлагают с их помощью писать ТЗ на новые программы, разрабатывать стандарты и классификаторы. Т.е. они придумывают, как инструментарием, которым они владеют - решить задачи новой технологии.
На процессы можно влиять организационно (приказами и стандартами, наказывая людей), а можно программно - не давая возможности на уровне инструмента сделать не правильно. Программная стандартизация замещает организационную и инструменты все большее имеют значение.
👍1
#Новости Вот уже 2 года после каждого обновления BIM360 я в первую очередь захожу в Issues BIM360 и проверяю не добавлена ли функция редактирования Linked document (т.к. product manager Autodesk на конфколе по предложениям мне говорил что мол скоро будет).
Я даже 1,5 года как уже сделал сервис для быстрого создания Issues по шаблонам, который ждал эту функцию (и на каждом вебинаре, когда рассказывал про неё, говорил: "вот Autodesk когда доработает, тогда это будет юзабельно, пока лежит созревает на полочке".
И вот сегодня, проверяя эту функцию уже в 8 наверно раз, я её обнаружил. И это круто! теперь наши спецы могут ставить замечание со смартфона на площадке (еще и максимально автоматизированно), а точку замечания устанавливать приходя в бытовку с ноутбука - как показывает практика, это намного удобнее.
Я даже 1,5 года как уже сделал сервис для быстрого создания Issues по шаблонам, который ждал эту функцию (и на каждом вебинаре, когда рассказывал про неё, говорил: "вот Autodesk когда доработает, тогда это будет юзабельно, пока лежит созревает на полочке".
И вот сегодня, проверяя эту функцию уже в 8 наверно раз, я её обнаружил. И это круто! теперь наши спецы могут ставить замечание со смартфона на площадке (еще и максимально автоматизированно), а точку замечания устанавливать приходя в бытовку с ноутбука - как показывает практика, это намного удобнее.
#СуперСистемы Строительные супер-системы. Часть 1.
Многие строительные компании сегодня пробуют разработать (или перебирают имеющиеся) ССС (строительные супер-системы), которая должна объединить в одном месте данные из разрозненных систем и связать все потоки информации в компании в одном месте.
Обязательно с загрузкой на входе смет из excel, календарного графика из ms project, оплат из 1С, и выгрузкой кс-2 кс-3 и автоматической генерацией исполнительной документации <- Так почти всегда ставится задача.
Эти потуги длятся уже больше 5 лет, а в некоторых компаниях (судя по интерфейсам) и все 10. Так почему же до сих пор нет на рынке продукта более менее рабочего? Почему все компании попрежнему работают в Word и Excel, а в системах для руководства лишь дублируют информацию задним числом?
Конечно продажники софта заявляют мол вот в Газпроме всë работает на том, в Росатоме на том, в Сибуре на третьем, пользуясь закрытостью их контуров и что мол опровергнуть будет сложно. Но время все расставляет по местам и там знакомые появляются и на собеседования оттуда приходят, т.ч. эти фейки вскрываются.
Многие строительные компании сегодня пробуют разработать (или перебирают имеющиеся) ССС (строительные супер-системы), которая должна объединить в одном месте данные из разрозненных систем и связать все потоки информации в компании в одном месте.
Обязательно с загрузкой на входе смет из excel, календарного графика из ms project, оплат из 1С, и выгрузкой кс-2 кс-3 и автоматической генерацией исполнительной документации <- Так почти всегда ставится задача.
Эти потуги длятся уже больше 5 лет, а в некоторых компаниях (судя по интерфейсам) и все 10. Так почему же до сих пор нет на рынке продукта более менее рабочего? Почему все компании попрежнему работают в Word и Excel, а в системах для руководства лишь дублируют информацию задним числом?
Конечно продажники софта заявляют мол вот в Газпроме всë работает на том, в Росатоме на том, в Сибуре на третьем, пользуясь закрытостью их контуров и что мол опровергнуть будет сложно. Но время все расставляет по местам и там знакомые появляются и на собеседования оттуда приходят, т.ч. эти фейки вскрываются.
#СуперСистемы Строительные супер-системы. Часть 2.
Давайте разбираться!
Для начала поймем "почему то что есть не подходит?"
Чем не подходит Excel? - он нестабилен из-за того что пользователь может добавлять столбцы и использовать разные типы сущностей в строках. Он двумерный. В нём столбцы используются и как атрибуты и как даты/месяца, в нём нельзя "растягивать полосочки" и устанавливать между ними зависимости чтобы они смешались при смещении предыдущей.
Чем не подходит MS Project? - в нём нельзя (крайне трудоемко, не как с ексель) добавлять столбцы и выполнять дополнительные, оперативные вычисления и адаптировать под свои задачи. При большом количестве строк и зависимостей постоянно чтото съезжает и куча времени тратится на поиск что и из-за чего.
Чем не подходит 1С? - он менее удобен чем Excel и MS Project и менее гибкий.
Кстати в этом же и не подходят любые написанные ССС - в них не получается перетянуть пользователей, т.к. они оказываются для него неудобными (причем не из-за привычки, а именно по функционалу, интерфейсу, объективно) и менее гибкими.
Это приводит к тому, что задача превращается в "давайте напишем свой ексель, но вот тут с возможностью блокировки на редактирование, тут с запретом добавлять другие типы сущностей, тут со смещением и перераспределением значений внутри ячеек при изменении вот того значения, а тут с заполнением данных из смартфона и только после согласования руководителем".
Давайте разбираться!
Для начала поймем "почему то что есть не подходит?"
Чем не подходит Excel? - он нестабилен из-за того что пользователь может добавлять столбцы и использовать разные типы сущностей в строках. Он двумерный. В нём столбцы используются и как атрибуты и как даты/месяца, в нём нельзя "растягивать полосочки" и устанавливать между ними зависимости чтобы они смешались при смещении предыдущей.
Чем не подходит MS Project? - в нём нельзя (крайне трудоемко, не как с ексель) добавлять столбцы и выполнять дополнительные, оперативные вычисления и адаптировать под свои задачи. При большом количестве строк и зависимостей постоянно чтото съезжает и куча времени тратится на поиск что и из-за чего.
Чем не подходит 1С? - он менее удобен чем Excel и MS Project и менее гибкий.
Кстати в этом же и не подходят любые написанные ССС - в них не получается перетянуть пользователей, т.к. они оказываются для него неудобными (причем не из-за привычки, а именно по функционалу, интерфейсу, объективно) и менее гибкими.
Это приводит к тому, что задача превращается в "давайте напишем свой ексель, но вот тут с возможностью блокировки на редактирование, тут с запретом добавлять другие типы сущностей, тут со смещением и перераспределением значений внутри ячеек при изменении вот того значения, а тут с заполнением данных из смартфона и только после согласования руководителем".
#СуперСистемы Строительные супер-системы. Часть 3.
Допустим мы разработали такую систему. И даже сделали еë удобной. Реализовали загрузку excel и ms project на входе, стандартизировали коды бюджета в компании, подготовили аналитику. Но почему не работает?
Разработчики и внедренцы говорят что кто-то не хочет прозрачности, саботирует процесс, не хочет учиться. Но, видя адекватность в глазах этих горе-пользователей, в это с трудом верится. И хочется копнуть глубже.
Основная проблема на этом этапе заключается с том, что после загрузки данных в программу необходимо все дальнейшие операции вести именно в ней, что намного более трудоемко, чем в екселе (иногда конечно это связано с ужасным интерфейсом как у 1С, SAP, Sharepoint, но сейчас давайте о тех, что с нормальным интерфейсом).
Проблема в том, что раньше, при изменении позиций, расшивке структуры, добавлении забытых позиций можно было это все накидать, перемешать в екселе (при сохранении общей суммы по договору) и утвердить как новый план жизни и жить по нему (типа на совещании всем объяснив что куда перешло и где увеличилось). В ССС же так нельзя - все изменения надо проводить отдельным процессом (желательно с согласованием).
Т.е. проблема не в инструментах, а методологическая. Если вы хотите жить в порядке то надо не мусорить, если для вас жить в порядке - трудоемко, и проще - намусорить, сжечь хату и переехать в новую, то вам никакие системы по соблюдению порядка не помогут.
Есть ещë у кого-то мечта, что их специалисты будут продолжать работать в excel и msp, а в систему эти данные будут подгружаться и магическим образом распознаваться - что откуда и куда, мол для этого всего-лишь пользователю надо работать "правильно" в своём excel. Но это приводит лишь к тому, что пользователь всегда виноват и работает "не правильно".
Допустим мы разработали такую систему. И даже сделали еë удобной. Реализовали загрузку excel и ms project на входе, стандартизировали коды бюджета в компании, подготовили аналитику. Но почему не работает?
Разработчики и внедренцы говорят что кто-то не хочет прозрачности, саботирует процесс, не хочет учиться. Но, видя адекватность в глазах этих горе-пользователей, в это с трудом верится. И хочется копнуть глубже.
Основная проблема на этом этапе заключается с том, что после загрузки данных в программу необходимо все дальнейшие операции вести именно в ней, что намного более трудоемко, чем в екселе (иногда конечно это связано с ужасным интерфейсом как у 1С, SAP, Sharepoint, но сейчас давайте о тех, что с нормальным интерфейсом).
Проблема в том, что раньше, при изменении позиций, расшивке структуры, добавлении забытых позиций можно было это все накидать, перемешать в екселе (при сохранении общей суммы по договору) и утвердить как новый план жизни и жить по нему (типа на совещании всем объяснив что куда перешло и где увеличилось). В ССС же так нельзя - все изменения надо проводить отдельным процессом (желательно с согласованием).
Т.е. проблема не в инструментах, а методологическая. Если вы хотите жить в порядке то надо не мусорить, если для вас жить в порядке - трудоемко, и проще - намусорить, сжечь хату и переехать в новую, то вам никакие системы по соблюдению порядка не помогут.
Есть ещë у кого-то мечта, что их специалисты будут продолжать работать в excel и msp, а в систему эти данные будут подгружаться и магическим образом распознаваться - что откуда и куда, мол для этого всего-лишь пользователю надо работать "правильно" в своём excel. Но это приводит лишь к тому, что пользователь всегда виноват и работает "не правильно".
#Практика #Стандарты Я часто пишу про техническую стандартизацию и Autodesk (прям в руку) реализовал хороший пример таковой.
В BIM360Docs и Docs появилась новая функция - стандартизация наименования загружаемых файлов.
На папку (и автоматом все подпапки) можно навесить правило нэйминга, на которое будут проверяться загружаемые файлы (это делается в Project admin - Services - Document management).
В случае, если имя файла не соответствует нужному, то он будет выведен в новое окно для ренейминга.
Правило наименования можно гибко настраивать (по умолчанию по ISO 19650).
Данный функционал доступен только в новых проектах, которые созданы после какой-то даты типа 24 марта 2021г.
В BIM360Docs и Docs появилась новая функция - стандартизация наименования загружаемых файлов.
На папку (и автоматом все подпапки) можно навесить правило нэйминга, на которое будут проверяться загружаемые файлы (это делается в Project admin - Services - Document management).
В случае, если имя файла не соответствует нужному, то он будет выведен в новое окно для ренейминга.
Правило наименования можно гибко настраивать (по умолчанию по ISO 19650).
Данный функционал доступен только в новых проектах, которые созданы после какой-то даты типа 24 марта 2021г.
#ACC Autodesk Construction Cloud. Часть 1.
Для начала расскажу о линейке продуктов BIM 360, которым приходит на смену новая сборка сервисов.
BIM 360 Docs - облачная CDE от Autodesk.
BIM 360 Design - облачный Revit server с правами доступа, процессами взаимодействия команд и функционалом Docs.
BIM 360 Model Coordination - бывший Glue - облачный Navisworks для проверки моделей на коллизии (который не работает из-за того что проверяет всë со всем, а не по настроенным поисковым наборам).
BIM 360 Field Management - первоначально Build и Field - модуль с чеклистами и ежедневными отчетами, который оказался очень слабым по функционалу (несоразмерно своей стоимости).
BIM 360 Project Management - модуль для согласования пакетов документации в zip архивах (который перестал быть актуальным после появления Reviews), meetings - бестолковая функция, позволяющая создать совещание в бим360 и привязать к нему ссылку на zoom. Не работает из-за того, что требует от всех участников процесса находиться в системе, а это дорого и у многих внешних участников нет аутодеск учетки.
BIM 360 Cost Management - потенциально крутая система для ведения бюджета, но с несколькими проблемами: сильно завязана на коды по классификатору - т.е. прям создание новых позиций ведётся поиском по коду, а не по описанию. Вторая, что требует заведения всех участников строительства и компаний в эту систему, что выглядит очень сложным.
BIM 360 Assets - возможность создавать справочник оборудования по Excel и привязывать к позициям из него замечания и документы. Пока без привязки к элементам моделей выглядит нерабочим.
Для начала расскажу о линейке продуктов BIM 360, которым приходит на смену новая сборка сервисов.
BIM 360 Docs - облачная CDE от Autodesk.
BIM 360 Design - облачный Revit server с правами доступа, процессами взаимодействия команд и функционалом Docs.
BIM 360 Model Coordination - бывший Glue - облачный Navisworks для проверки моделей на коллизии (который не работает из-за того что проверяет всë со всем, а не по настроенным поисковым наборам).
BIM 360 Field Management - первоначально Build и Field - модуль с чеклистами и ежедневными отчетами, который оказался очень слабым по функционалу (несоразмерно своей стоимости).
BIM 360 Project Management - модуль для согласования пакетов документации в zip архивах (который перестал быть актуальным после появления Reviews), meetings - бестолковая функция, позволяющая создать совещание в бим360 и привязать к нему ссылку на zoom. Не работает из-за того, что требует от всех участников процесса находиться в системе, а это дорого и у многих внешних участников нет аутодеск учетки.
BIM 360 Cost Management - потенциально крутая система для ведения бюджета, но с несколькими проблемами: сильно завязана на коды по классификатору - т.е. прям создание новых позиций ведётся поиском по коду, а не по описанию. Вторая, что требует заведения всех участников строительства и компаний в эту систему, что выглядит очень сложным.
BIM 360 Assets - возможность создавать справочник оборудования по Excel и привязывать к позициям из него замечания и документы. Пока без привязки к элементам моделей выглядит нерабочим.
#ACC Autodesk Construction Cloud. Часть 2.
Далее о предпосылках изменений.
Таким образом, мы видим что из перечисленных выше модулей - реально рабочие Docs и Design.
При этом, взяв во внимание тот факт, что половина функционала Docs также мимо (Plans, Sets, Transmittals), можно понять недовольство со стороны руководства.
(Справедливости ради добавлю что в Docs есть функции ради которых его стоит брать и из-за которых я считаю его лучшей CDE на сегодня - Project Files, Permissions, Compare, Issues, Reviews, API, ADC)
В разработке самих модулей тоже все не так гладко, они основаны на платформе Forge и каждая хотелка по функционалу упирается в доработку платформы. Таким образом все разработчики модулей как-бы садились в очередь со своими запросами на доработку платформы к центральной команде.
Внесение каждой новой функции требовало отображение еë и в мобильных версиях для Android и iOS - хотя на это похоже все забили сразу же. И вот несмотря на то, что во всех брошюрах Autodesk позиционирует как мобильное решение, оно по факту было только для модуля Docs и то не для всего функционала.
Недавно Autodesk купил PlanGrid и Assemble Systems, программистов, продакт менеджеров и дизайнеров которых можно подключить к разработке модулей Build и Takeoff.
Далее о предпосылках изменений.
Таким образом, мы видим что из перечисленных выше модулей - реально рабочие Docs и Design.
При этом, взяв во внимание тот факт, что половина функционала Docs также мимо (Plans, Sets, Transmittals), можно понять недовольство со стороны руководства.
(Справедливости ради добавлю что в Docs есть функции ради которых его стоит брать и из-за которых я считаю его лучшей CDE на сегодня - Project Files, Permissions, Compare, Issues, Reviews, API, ADC)
В разработке самих модулей тоже все не так гладко, они основаны на платформе Forge и каждая хотелка по функционалу упирается в доработку платформы. Таким образом все разработчики модулей как-бы садились в очередь со своими запросами на доработку платформы к центральной команде.
Внесение каждой новой функции требовало отображение еë и в мобильных версиях для Android и iOS - хотя на это похоже все забили сразу же. И вот несмотря на то, что во всех брошюрах Autodesk позиционирует как мобильное решение, оно по факту было только для модуля Docs и то не для всего функционала.
Недавно Autodesk купил PlanGrid и Assemble Systems, программистов, продакт менеджеров и дизайнеров которых можно подключить к разработке модулей Build и Takeoff.