В стандарте ISO 19650 закреплён ключевой принцип управления информацией: "Appropriate Level of Information" (соответствующий уровень информации). Как указано в ISO 19650-1 (п. 3.3.10), отменённом ГОСТ Р 58439-1 (п.11.2), информация должна быть "достаточной, но не избыточной" для выполнения задач на каждом этапе проекта. Этот подход кратко формулируется как:
"Right information, at the right time, to the right people" ("Правильная информация, в нужное время, для нужных людей").
С другой стороны, в японской философии кайдзен и бережливого производства (Lean) есть термин "муда" (無駄), который обозначает любые действия, потребляющие ресурсы, но не создающие ценности. Классические примеры "муда" включают:
- Затраты времени на создание ненужных данных;
- Обработку избыточной информации;
- Хранение неиспользуемых моделей.
Создание и передача избыточной информации в Цифровых Информационных моделях (ЦИМ) - яркий пример "Муда":
- На создание избыточной информации тратятся человеческие и технические ресурсы;
- На их анализ и фильтрацию уходит дополнительное время;
- Это замедляет процесс принятия решений без улучшения результата.
Создание цифровых информационных моделей, не зависимо от программного обеспечения, в котором их создают, требует ресурсов — квалифицированных специалистов, вычислительных мощностей, времени.
Поэтому не зря ISO 19650-1 рекомендует:
- Определять минимально достаточную детализацию и уровень информации для каждого этапа жизненного цикла проекта;
- Избегать преждевременной детализации, увеличивающей нагрузку на:
- Совместную работу;
- Внесение изменений в модели,
- Просмотр, проверку и анализ результата.
Принцип конечного результата
Как описано в международной практике и Российских нормативных документах в области технологии информационного моделирования, эффективное управление информацией начинается с:
- Чёткого определения целей использования цифровых информационных моделей. Например:
- Получение чертежей и спецификаций;
- Выявление и устранение конфликтов и критических пересечений (коллизий);
- Просмотр и визуальный анализ проектных решений.
- Формирования требований к данным строго в соответствии с этими целями.
Принцип достаточности информации не нов. Вспоминаю наши проекты по разработке стандартов слоёв nanoCAD/ AutoCAD 15-20 летней давности. Какое количество слоёв самое оптимальное? Один и имя этому слою «0» =)).
Но как только возникает задача быстрого назначения нескольких свойств одной линии (толщина, тип линии и пр.), сразу к нулевому слою добавляется несколько слоёв, которые экономят время проектировщика. А потом коллеги из соседнего отдела начинают использовать твои чертежи как внешнюю ссылку (XRef), возникает следующий цикл увеличения структуры слоёв. Чтобы коллеги могли отключать и вносить изменения в свойства объектов «подложки», отключаемые или изменяемые объекты также выделяются в отдельные слои. Таким образом, шаг за шагом в зависимости от потребности увеличивался «уровень детализации» структуры чертежа.
Теперь перейдём из 2D|3D пространства nanoCAD|AutoCAD в пространство Цифровых информационных моделей.
Приведу 2 примера про детализацию (1) и информацию (2), так как в профессиональном сообществе закрепились 2 понятия LoD (Level of Details) и LOI (Level Of Information).
(1) Детализация.
У меня есть хороший товарищ, профессионал в части использования одного из зарубежных программных продуктов информационного моделирования, в первую очередь в области технологического раздела. При обучении пользователей использование данного программного продукта в первую очередь учит их «плохому».
А именно: он учит их рисовать простые кубики и вставлять в плане в виде сверху плоскую 2D подложку из nanoCAD|AutoCAD, которую представляют разработчики технологического оборудования. В результате получаются очень простые геометрические фигуры. Но в плане они ничем не отличаются от того, если бы это было сделано при плоском проектировании с высоким уровнем детализации отдельных деталей оборудования. Но при этом сил, нерв и средств тратится значительно меньше, если бы Вы попытались получить такой же вид как проекцию 3D элемента.
Это пример минимально необходимого уровня детализации, когда Вам необходимо разработать общие компоновочные решения, но чтобы на планировках это выглядело не как кубизм, а выглядело очень довольно себе прилично. Этот способ отлично «заходит» на ранних этапах проектирования, когда еще большой уровень неопределенности, но времени и ресурсов на формирование детальных элементов библиотеки нет.
В дальнейшем данные объемные фигуры начинают претерпевать изменения. Как говорил Микеланджело, «Я беру камень и отсекаю всё лишнее». С таким же подходом данные геометрические элементы постепенно с переходами из одной стадии в другую, по мере уточнения и согласования основных технических решений и используемой номенклатуры оборудования, начинают обретать свои очертания и формы. Но и в данном случае не стоит пытаться создавать идеально детализированные элементы библиотеки. Моделировать стоит только объекты, позволяющие сократить риски переделок и дополнительных затрат при монтаже и эксплуатации. Например, пространство открывания дверцы моделируем чтобы потом не срезать и переделывать трубопроводы, которые случайно смонтировали перед дверцами, монтажные опоры оборудования прорабатываем для того, чтобы не пришлось срезать анкерные болты и изобретать потом, как-же зафиксировать единицу оборудования. Такой простой подход применяем при принятии решения о проработке того или иного элемента. Каждый раз отвечаем на вопросы как это поможет на этапе монтажа или эксплуатации?
(2) Атрибуты (информация)
Аналогичный подход с атрибутами. ЦИМ, на мой взгляд, должна содержать минимально необходимое кол-во атрибутов, чтобы решать задачи выпуска графической части, спецификаций и рассмотрения этой модели заинтересованными сторонами или потребителями вашей информации. Представим, что сводную модель периодически рассматривает ГИП, он прогуливается по будущему объекту, как по уже построенному и пытается предугадать возможные риски или сложности, которые возникнут с нашим ОКС в процессе эксплуатации. В первую очередь информация в элементах должна ответить ему на вопрос «Что это?» и в каком томе или комплекте объект находится, чтобы получить больше информации из документации и поставить задачу на внесение изменений. Для этого достаточно информации в объекте, которая использовалась для выпуска спецификации и информации о шифре документа- основания. Если других задач проекта не применяется, не стоит загромождать требования к ЦИМ дополнительными атрибутами и сущностями.
Минимальные требования к ЦИМ — фокус на ценности, а не экономия на качестве . Как в любо процесс: двигайтесь от общего к частному, начинайте с простого, усложняйте — только когда это приносит пользу. Такой подход сокращает затраты и ускоряет процессы без ущерба для результата.
