Управление конфигурацией : задачи, стандарты и реализация

[EYKD 0]

планируемый к установке в изделие компонент может не подходить по габаритам/массе/токопотреблению/тепловыделению/вибрационной стойкости/надёжности/цене/срокам изготовления и ещё многим другим параметрам. Именно по этой простой причине последнее слово в технической дискуссии всегда остаётся за конструктором.

Мы немного уходим от темы PDM и управления конфигурацией, а больше говорим о процессе реализации проектов, но тем не менее. Ключевое слово в вашем утверждении "технической". Но конструктор не может и не должен отвечать за "подходимость" планируемого компонента по абсолютно всем параметрам. Например, за цену и сроки поставки отвечают снабженцы (procurement). Поэтому-то сейчас так важна роль интеграторов-управленцев, задача которых найти оптимальное решение, оперируя разными параметрами.

принять решение о конфигурации изделия может менеджер по управлению конфигурацией. <...> Название не принципиально, важно, что в организации есть такая функция.

Только функция сия в чистом виде конструкторская, а чтобы этим мог заниматься и менеджер как раз и нужны упоминавшиеся выше база знаний предприятия и логические правила. То бишь чтобы сама система организовывала "защиту от дурака" желающего повесить на источник энергии мощностью 1кВт потребителя на 5кВт.

И всё-таки это не так. Не чисто конструкторская это функция. Объясню. По вашим представлениям, конструктор - это царь и бог, а все остальные - это мелкие вредители, которые только и мечтают о том, чтобы применить на изделии какой-нибудь неподходящий компонент. Но поймите, никто не отнимает у конструктора его прав и обязанностей выдать грамотное техническое решение.

А вот менеджер по конфигурации отвечает за то, чтобы из готовых грамотных технических решений, или опций, как из кубиков, собрать необходимое заказчику изделие. Разумеется, что опции-кубики могут собираться только по определёным логическим правилам, о которых писал выше по ветке ExtraRight (несовместимость, односторонняя или двусторонняя необходимость и т. п.) Разумеется, что в разработке этих логических правил и базы знаний конструктор принимает участие.

Управление конфигурацией - это всё-таки административно-инженерная дисциплина, а не чисто инженерная. Предлагаю прочитать <noindex>статью</noindex> "Методы и технологии управления конфигурацией сложных изделий".

Давайте посмотрим на тему ветки, "Управление конфигурацией : задачи, стандарты и реализация". Мне кажется, что мы уже довольно много обсуждаем задачи и стандарты, может быть всё-таки есть желание поговорить о реализации управления конфигурацией на разных предприятиях и в разных PDM-системах? В соседнем разделе есть небольшая тема <noindex>Конфигурируемый продукт в Windchill</noindex>, но она уже полтора года не обновлялась.

Изменено 4 ноября 2010 пользователем EYKD

[Странник 6]

Ключевое слово в вашем утверждении "технической". Но конструктор не может и не должен отвечать за "подходимость" планируемого компонента по абсолютно всем параметрам.

...

По вашим представлениям, конструктор - это царь и бог, а все остальные - это мелкие вредители, которые только и мечтают о том, чтобы применить на изделии какой-нибудь неподходящий компонент. Но поймите, никто не отнимает у конструктора его

прав и обязанностей выдать грамотное техническое решение.

...

А вот менеджер по конфигурации отвечает за то, чтобы из готовых грамотных технических решений, или опций, как из кубиков, собрать необходимое заказчику изделие. Разумеется, что опции-кубики могут собираться только по определёным логическим правилам, ... в разработке этих логических правил и базы знаний конструктор принимает участие.

...

Управление конфигурацией - это всё-таки административно-инженерная дисциплина, а не чисто инженерная.

Ключевым действительно является слово "технический", тут всё ровно как в сказке про большой камень из-за которого и не проехать, и не пройти. Есть способ этот камень с дороги убрать - можно говорить о сроках/цене, а на нет и суда нет.

Главная заморочка здесь состоит в том, что вместо расчётной синергии специалистов в разных областях науки и техники ныне имеет место противостояние all vs all, а источником сей смуты является именно "чистый управленец" (торговец).

Разделяй и властвуй.

Иначе менеджер просто не усидит, ибо по определению не зная доминантного на предприятии/территории ремесла он неизбежно:

-поведёт неверную кадровую политику;

-не разглядит технического подлога как внешнего, так и внутреннего;

-наберёт кредитов под несостоятельное изделие либо завышенный прогноз прибыли;

-не сумеет правильно определить цели и оптимально поставить задачи;

-создаст непрестанное "броуновское движение" даже среди самых высококлассных специалистов;

-развалит дело и смоется прихватив с собою всё что сможет унести.

Это уже не ИМХО, но

плавали, знаем.

Декомпозировать и формализовать систему действующих сил настолько чтобы можно было произвольным образом состыковать любые элементы из заданного набора и получить в итоге именно то, что хотелось невозможно даже на детсадовском уровне. А в реальной жизни процесс создания новой техники всегда был, есть и будет итерационным. И никакая встроенная компьютерная система с кучей датчиков и приводов тут не поможет.

Посему менеджер по конфигурации может варьировать только заданными на этапе общего проектирования параметрами и только в строго определённых пределах. А чтобы выдавать ТЗ на разработку новой базовой модели нужно быть экспертом в ремесле использующем разрабатываемые системы как инструмент, да и сами изделия знать хорошо (учить матчасть).

Таким образом идеальным управленцем в машиностроении является опытный конструктор, прошедший несколько курсов дополнительного обучения, в том числе и основам управления предприятием. Стало быть и PLM-система должна позволять работать на уровне конструктора, а не менеджера торгового зала. Отсюда собственно и требования к софту и НД.

Я бы это отнес к проблеме классификаторов (библиотек изделий). Это где-то пересекается, но не полностью...

ИМХО, это фундамент на котором строится любой конфигуратор. А трудность в динамичности рынка базовых элементов. Можно найти на предприятии экспертов в конструировании, технологии, схемотехнике... и создать ограничительные перечни, но для заполнения и актуализации базы знаний предприятия этого явно недостаточно.

[EYKD 0]

Хочу сделать подарок участникам форума, которые хотят понять и разобраться в том, что такое Configuration Management.

То ли по недосмотру, то ли по доброте душевной, немецкая тренинговая компания IndusrtieHansa оставила в открытом доступе на своём интернет-сайте <noindex>тренинг</noindex> по управлению конфигурацией компании Airbus. У вас есть возможность узнать, как управляет конфигурацией сложных технических объектов один из лидеров мирового машиностроения.

Тренинг состоит из 10 небольших (по 3-4 минуты) флэш-презентаций на английском языке с субтитрами. Материал излагается в максимально доступной форме, но всё-таки иногда может быть сложен для восприятия неподготовленным человеком. Отчасти из-за того, что тренинг создан для компании Airbus и в нём используются некоторые специфичные термины.

Я настоятельно рекомендую ознакомиться с этим тренингом всем, кто хочет постичь для себя эту науку - Configuration Management. Если что-то останется непонятным и спорным, давайте будем здесь это обсуждать и вместе разбираться.

[SVB 188]

Хочу сделать подарок участникам форума, которые хотят понять и разобраться в том, что такое Configuration Management.

...по управлению конфигурацией компании Airbus. У вас есть возможность узнать, как управляет конфигурацией сложных технических объектов один из лидеров мирового машиностроения.

Я настоятельно рекомендую ознакомиться с этим тренингом всем, кто хочет постичь для себя эту науку - Configuration Management. Если что-то останется непонятным и спорным, давайте будем здесь это обсуждать и вместе разбираться.

Смотрел, я смотрел эти руководства...., но так и не нашел, как сделать вариант конфигурации аэробуса A380 с отваливающимся в полёте двигателем...

[EYKD 0]

Нашёл ещё одну крохотную тему на этом форуме, посвящёную управлению конфигурацией. Дам здесь на неё <noindex>ссылку</noindex> просто для того, чтобы собрать в этой теме всё, что посвящено Configuration Management. Если кто-то видел здесь другие ветки на эту тему, дайте, пожалуйста, ссылки. Спасибо!

[ExtraRight 1]

Хочу сделать подарок участникам форума, которые хотят понять и разобраться в том, что такое Configuration Management.

То ли по недосмотру, то ли по доброте душевной, немецкая тренинговая компания IndusrtieHansa оставила в открытом доступе на своём интернет-сайте <noindex>тренинг</noindex> по управлению конфигурацией компании Airbus. У вас есть возможность узнать, как управляет конфигурацией сложных технических объектов один из лидеров мирового машиностроения.

Большое спасибо за ссылку - действительно любопытно. Жаль, что дальнейшие курсы (особенно по VPM) недоступны.

Любопытно, что очень похожий 3-х уровневый метод дерева применяется и в автомобилестроении - видимо для широковариантных продуктов другого пути уменьшить количество оперируемых уникальных объектов нет.

3-х уровневый метод:

- пространственно-функциональные модули - причём всё по тому же принципу 3F,

- configurated items как "placeholders" и их варианты (DS'ы в аирбасовской терминологии) со связанными правилами применения,

- p/n parts - точно-составные узлы и детали

Ну а над всем этим хранилище (назовём это так), привязанное к BOM'у вариантного продукта, где описаны применяемые опции, правила совместимости и необходимости (добавления) опций.

Отличия между авто и авиа наверное заключены в правилах конфигурирования - в автомобилестроении массовое производство по типу ATO - все опции и правила разрабатываются при разработке продукта и затем передаются в производство как законченная система без вмешательства конструкторов при обработке заказов от потребителя (я конечно тут утрирую). А вот как выглядят правила конфигурирования (применения, совместимости, необходимости-добавления) у авиаторов?

[EYKD 0]

Любопытно, что очень похожий 3-х уровневый метод дерева применяется и в автомобилестроении - видимо для широковариантных продуктов другого пути уменьшить количество оперируемых уникальных объектов нет.

3-х уровневый метод:

- пространственно-функциональные модули,

- configurated items как "placeholders"и их варианты (DS'ы в аирбасовской терминологии),

- p/n parts - точно-составные узлы и детали

Не знаю, знакомы ли вы с терминологией Airbus или термин "placeholder" используется в автомобилестроении, но в немецкой части Airbus используют термин "platzhalter", то есть как раз "placeholder" в дословном переводе. А DS'ы я бы назвал не просто вариантами Configuration Item, а вариантами реализации CI, потому что сами CI являются виртуальными компонентами структуры изделия.

Кстати, для управления оборудованием Airbus использует схожий подход. В стуктуре изделия назначаются узлы, которые называются FIN (Functional Item Number). Эти элементы выполняют роль placeholder'ов для оборудования и им назначаются определённые характеристики. Например, насос имеет такую-то производительность и такие-то интерфейсы. А вот конкретный артикул оборудования является своего рода DS и может отличаться от экземпляра к экземпляру. Очень удобно управлять с помощью FIN опциональным оборудованием заказчика (например, пассажирскими креслами).

Отличия между авто и авиа наверное заключены в правилах конфигурирования - в автомобилестроении массовое производство по типу ATO - все опции и правила разрабатываются при разработке продукта и затем передаются в производство как законченная система без вмешательства конструкторов при обработке заказов от потребителя (я конечно тут утрирую). А вот как выглядят правила конфигурирования у авиаторов? Что-то типа CTO?

Да, в авиации используется CTO. Цикл изготовления конкретного экземпляра самолёта всегда начинается с определения и фиксирования в контракте конфигурации и заканчивается верификацией реализации законтрактованной конфигурации.

Между этими двумя точками идёт техническая проработка конфигурации, проверка совместимости опций, проектирование недостающих опций и уникальных запросов заказчика.

Конечно, ATO в определённом смысле лучше, чем CTO. Потому что ATO быстрее и надёжнее в плане конечного результата. Поэтому производители авиационной техники стремятся сохранить подход CTO, но добавить в него как можно больше элементов ATO: разработать предварительно как можно больше опций, выпускать ограничительные списки применяемого оборудования, привлекать предварительно выбранных поставщиков к проектированию на как можно более ранних этапах, чтобы минимизировать риски, вызванные несовместимостью опций и оборудования.

Это становится особенно актуально в настоящее время, когда по требованиям рынка время от заказа до получения самолёта сокращается. Но в целом подход CTO в авиации сохранится ещё надолго, может быть даже навсегда.

[ExtraRight 1]

Не знаю, знакомы ли вы с терминологией Airbus или термин "placeholder" используется в автомобилестроении, но в немецкой части Airbus используют термин "platzhalter", то есть как раз "placeholder" в дословном переводе. А DS'ы я бы назвал не просто вариантами Configuration Item, а вариантами реализации CI, потому что сами CI являются виртуальными компонентами структуры изделия.

Термин placeholder заимствован у одной крупной немецкой автоконюшни - видимо, методологию конфигурирования для немецких авто и авиастроителей разрабатывали немецкие учёные одной школы

Кстати, CI в терминологии немецкой автоконюшни звучит проще - просто Positions, над ними 3-х уровневое модульное дерево (пространственно-функциональное разбиение по принципу Form, Fit, Function), под ними варианты - Position Variants, к которым привязаны правила применения - логические выражения, оперирующие кодами опций. Вариантный (конфигурируемый) BOM в связке с т.н. Описанием продукта (где прописаны применимые для данного вариантного продукта опции, правила совместимости их, правила необходимости (добавления)) - вся эта система порождает достаточно нетривиальные задачи контроля конфликтов, особенно при внесении изменений. Конфликты типа "Вариант позиции (DS) физически ни в одной из возможных конфигураций не осуществим", "Есть применимые для продукта опции, которые не осуществимы ни в одной из возможных конфигураций" и т.п. Есть публичные материалы немецких учёных как они разрабатывали логику первой версии такой системы контроля для той самой крупной немецкой автоконюшни - если интересно, могу дать ссылку

Да, в авиации используется CTO. Цикл изготовления конкретного экземпляра самолёта всегда начинается с определения и фиксирования в контракте конфигурации и заканчивается верификацией реализации законтрактованной конфигурации.

....

Это становится особенно актуально в настоящее время, когда по требованиям рынка время от заказа до получения самолёта сокращается. Но в целом подход CTO в авиации сохранится ещё надолго, может быть даже навсегда.

Очень познавательная информация. Спасибо. Насчёт CTO - для крупного авиастроения это будет оптимумом наверное навсегда, так как серийность на порядок меньше, чем у авто, а цикл производства на порядок больше (если я ошибся в своих оценках, сильно не ругайте и поправьте).

[EYKD 0]

Есть публичные материалы немецких учёных как они разрабатывали логику первой версии такой системы контроля для той самой крупной немецкой автоконюшни - если интересно, могу дать ссылку

О чём речь?! Конечно, интересно! Я думаю, что нам есть много чему поучиться у немецких автопроизводителей, с их серийностью и количеством опций.

[ExtraRight 1]

О чём речь?! Конечно, интересно! Я думаю, что нам есть много чему поучиться у немецких автопроизводителей, с их серийностью и количеством опций.

Вот на этой странице <noindex>http://www-sr.informatik.uni-tuebingen.de/index.php?id=54</noindex> перечислены их публикации. И хотя на самой странице ссылки на материалы уже не рабочие, все материалы легко находятся в интернете в pdf формате по приведённым на странице названиям

[Mr Eugene 0]

эх... тема так плавненько и незаметно утекла от Управления Конфигурациями в сторону Конфигурируемого Продукта.

Когда американское МО вводило понятие "Configuration Management" и соответсвующий процесс, оно преследовало цель получать от поставщика техники идентичные эклемпляры продукта "АБВ-012-03" сегодня, завтра и после завтра. При этом у продукта "АБВ-012-03" нет ни каких опций/вариантов. Если нужен продукт с другими свойствами, то с точки зрения МО есть продукт "АБВ-012-04" и оба продукта живут своей практически независимой жизнью по процессам CM. Т.е. задача CM - управление описанием продукта, реализующуюся посредством версионности через управление изменениями. Ни о каких опциях и вариантах при этом речь не шла.

Но жизнь потребовала многообразия вариантов продукта, появилось потребность описывать продукт не в виде точного состава, а в виде "общего состава" (GBOM, Generic BOM), из которого посредством инструмента "Конфигуратор" (бумажного или электронного) можно получить "точный состав" (PBOM, Precise BOM) необходимого экземпляра продукта. При этом процесс Configuration Management никто не отменил, только описание продукта и управление изменениями в нем стало сложнее.

Поэтому для конструктивной беседы в этой теме надо определиться, что обсуждаем:

- процессы Управления Конфигурацией

или

- методы описания Конфигурируемого Продукта

зы: часть материалов по проблеме описания конфигурируемого продукта у выше упомянутого немецкого автопроизводителя можно взять на страничке одного из авторов этих публикаций <noindex>http://www.carstensinz.de/publications.html</noindex> , основной упор в них сделан на математическую проблему, но в них можно найти и описание подхода к описанию продукта и обработке заказа продукта.

ззы: по теме "Configuration Management" познавательно хотя бы полистать MILitary-HanDBooK-61

Изменено 10 ноября 2010 пользователем Mr Eugene

[EYKD 0]

Mr Eugene, большое спасибо за участие в теме и за ценные объяснения!

Действительно, похоже, что тема развивается вслед за развитием Configuration Management. Кстати, насколько я знаю, когда американское МО вводило понятие "Configuration Management" и соответсвующий процесс, оно преследовало цель получать от поставщика техники идентичные эклемпляры продукта "АБВ-012-03" сегодня, завтра и после завтра а также получать идентичные экземпляры одного и того же продукта от разных поставщиков.

Но, как вы абсолютно правильно заметили жизнь потребовала многообразия вариантов продукта и поэтому методы и задачи управления конфигурациями значительно продвинулись и усложнились. Но, как опять-таки вы совершенно верно заметили, при этом процесс Configuration Management никто не отменил.

Поэтому для конструктивной беседы в этой теме надо определиться, что обсуждаем:

- процессы Управления Конфигурацией; или

- методы описания Конфигурируемого Продукта

Для меня Configuration Management - это всё-таки работа с конфигурируемым продуктом. Во-первых, потому что таково веление времени и требования авиационной отрасли, в которой я работаю.

Во-вторых, конфигурация продукта может изменяться не только по требованию заказчика. Это могут быть и улучшения конструкции и изменения поставщиков и ещё что-нибудь. И всем этим надо управлять в рамках одного и того же продукта "АБВ-012-03" с заданными характеристиками.

А в-третьих, потому что получение стабильного продукта "АБВ-012-03" - это частный случай работы с вариантами продукта. Ведь для достижения и того и другого необходимо успешно решить все задачи УК (планирование, идентификация, контроль, учёт и аудит).

Ну и на сладкое: материалы ещё одного тренинга. Называется он Training for Small and Medium Enterprises on CONFIGURATION MANAGEMENT и подготовлен Европейским Космическим Агентством (esa). Он состоит из 13 разделов (с 0 по 12) и трёх приложений (с 1 по 3).

<noindex>Раздел 0</noindex> - это детальное оглавление тренинга. Чтобы скачать остальные разделы, нужно в адресе поменять ноль на номер раздела. Для приложений используйте Appendix-*-CM, вместо звёздочки подставляйте номер приложения.

Изменено 10 ноября 2010 пользователем EYKD