Изменения в подсборках.

[Странник 6]

А что такое ГСС?

Гражданские Самолёты Сухого.

Предприятие как бы считается лидером по автоматизации в России.

Рисуют они в катьке, а PLM у них юниграфиковская.

[VOleg 228]

Понятно.

Это меня, конечно, волнует, но не тревожит.

[Странник 6]

Это меня, конечно, волнует, но не тревожит.

У нас без параметрического ЭЦМ изделия не обойтись, а цикл отработки предвидится лет на 5...7.

В общем проблема острейшая, просматривается.

[AnTe 1]

Да, забыл дописать: "извещения все - даже самые "незначительные" подписывает Гл.констр., Гл.технолог, Нач.ПДО, и кто еще Вам нужен" Это кроме автора и проверявшего.

то есть, это при бумажном документообороте?! т.о. при электронном кол-во подписей принципиально не изменяется?!

А в чём состоит проблема, означенная в первом посте треда, Странником?

[VOleg 228]

то есть, это при бумажном документообороте?! т.о. при электронном кол-во подписей принципиально не изменяется?!

Принципиально не меняется порядок подготовки производства и самого производства - так что все заинтересованные лица должны быть ознакомлены с изменениями - любым способом.

[Странник 6]

А в чём состоит проблема, означенная в первом посте треда, Странником?

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без PDM сие вообще невозможно.

С другой стороны элементы нижнего уровня по тем или иным причинам изменяются, в среднем где то один или два в год, а элементов этих тысячи. ЕМНИП, как то прикидывалось количество изменений в день и получалось, что "живой" (то есть полностью параметризованный и поддерживаемый в актуальном состоянии ЭЦМ изделия) будет получать в среднем порядка 4 или даже более обновлений в день. Ситуация достаточно критична сама по себе уже потому, что проектно-конструкторские организации обыкновенно работают в одну смену, но это пол беды. Страшнее то, что всем нужны не просто модели, но согласованная и утверждённая КД, а расставленные в результате работы Workflow галочки за "т.контр.", "гл.мет" и т.д. по определению теряют актуальность при появлении каждой новой итерации модели (следовательно и построеных с неё чертежей, ассоциативно).

Очевидно, что с внесением, хотя косметической правки, в какую ни будь деталь АБВГД.04.01.013 по законам CAD должны будут перестроиться и все сборки, в которые эта деталь входит, включая и АБВГД.00.00.000. Каждый из этих документов нужно будет снова сохранить в PDM, с изменение контрольной суммы и появлением новой итерации. То есть потребуется ещё раз пройти круг согласований, по каждому изменившемуся документу.

Смотрите, как пример, что тянет за собою изменение одного компонента самого ниженго уровня:

АБВГ.04.01.013 - АБВГ.04.01.020 - АБВГ.04.010.100 - АБВГ.04.01.000 - АБВГ.04.00.000 - АБВГ.00.00.000.

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

[AnTe 1]

Проектирование частного должно вестись как часть целого, то есть неизбежно появляется модель общего вида - ЭЦМ, полная модель, до шайбочки, до проводка. Без PDM сие вообще невозможно.

Почему же? А что такое КД, как не полная модель, пусть и "бумажная", до шайбочки, до проводка? Или в чём здесь принципиальная разница?

Страшнее то, что всем нужны не просто модели, но согласованная и утверждённая КД, а расставленные в результате работы Workflow галочки за "т.контр.", "гл.мет" и т.д. по определению теряют актуальность при появлении каждой новой итерации модели (следовательно и построеных с неё чертежей, ассоциативно).

А без внедрения PDM разве было по-другому?

Смотрите, как пример, что тянет за собою изменение одного компонента самого ниженго уровня:

АБВГ.04.01.013 - АБВГ.04.01.020 - АБВГ.04.010.100 - АБВГ.04.01.000 - АБВГ.04.00.000 - АБВГ.00.00.000.

Давайте немного упростим пример. Разработан и утверждён автомобиль. Понадобилось заменить гайку на колесе. Разработчик небольшой сборки "колесо" её меняет, в принципе, характеристики гайки те же, ну, пусть на ней эмблемка другая:) просто других не было!

Я понял, что при использовании PDM придётся заново утвердить все сборки, начиная от колеса, моста, и заканчивая нулевой сборкой. Так как изменится сигнатура каждой сборки.

А при бумажном документообороте? Разработчик колеса выпустил ИИ, которое затем подписывают те же участники, которые будут тыкать на кнопы в PDM системе?

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

Вот он и выигрыш - быть нажимателем кнопки проще, чем подписывателем листочка?

при чём без всякой возможности вникать в технику дела. При этом даже не важно влияет изменение той самой АБВГ.04.01.013 на функционирование хотя бы АБВГ.04.01.020, просто появилась новая итерация и вперёд по "заячьему кругу".

Может, можно сформулировать вопрос так: каким образом "вникают в технику дела" при бумажной документации? Какими правилами, ГОСТами это регулируется? Кто и как определяет, "влияет" ли замена гайки на сборку выше, нулевую сборку? И, в конце концов, почему это невозможно с PDM?

Изменено 23 мая 2008 пользователем AnTe

[Smike 0]

Возвращаясь к оригинальной теме: все описанные проблемы были объяснены и решены в Toyota, и это было описано в книге Toyota Way (принцип Toyota Lean Manufacturing). Я лично смог участвовать в подобной имплементации. Софт: SMARTEAM, CATIA. Порядка 600+ инжинеров. Делают самолеты.

1) Итак, они решили сделать в основе всего т.н. стандартные части (Standard Parts). Чем ниже по иерархии находится часть (и чем чаще она используется), тем меньше вероятность ее изменения. Т.е. те кто сверху по иерархии, должны брать то что дают.

2) Производственники (Manufacturing) участвуют в дизайне с самого начала, и они имеют возможность влиять на все до того, как был сделан Release. После того как был сделан Release, вероятность изменения крайне мала, я бы сказал, что такая ситуация (изменения after Release) негативно отразится на тех кто привел к подобной ситуации.

3) Во всем этом процессе очень большую роль играет разграничение полномочий. Люди, занимающиеся "старшими" асс, не имеют возмойность менять низлежащие, в особенности Standard Parts.

В общем, по результату имплементации, компания съекономила $250М за 2 года, а всего планируют сохранить 1 миллиард за 5-7 лет.

Счастье возможно!

[Странник 6]

А что такое КД, как не полная модель, пусть и "бумажная", до шайбочки, до проводка? Или в чём здесь принципиальная разница?

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

То есть ЭЦМ эта по сути таж самая конструкторская прорисовка, только на качественно более высоком уровне. Больше того, есть методики позволяющие буквально "лепить" изделие прямо в CAD, то есть формировать его облик, привязывать покупные и стандартные компоненты, оптимизировать, находить альтернативу, в общем делать всё то, что называется словом ПРОЕКТИРОВАНИЕ.

С этой же точнейшей прорисовки делаются и чертежи, и электронная стуктура изделия, и ещё много чего.

Это надеюсь понятно?

А при бумажном документообороте? Разработчик колеса выпустил ИИ, которое затем подписывают те же участники, которые будут тыкать на кнопы в PDM системе?

А вот тут медаль поворачивается другою стороною.

При бумажном обороте будет выпущено ИИ на сборку "колесо" и согласовано с первым уровнем вхождений, допустим "мост передний". То есть, ежели разработчик "колеса" докажет разработчику "моста", что его ИИ не выводит параметры "колеса" за границы ТЗ, то никакого ИИ на "мост", тем более "автомобиль" не потребуется вовсе. Производство и испытания проверят всех и каждого.

Вот он и выигрыш - быть нажимателем кнопки проще, чем подписывателем листочка?

Проще то проще, только не в сотни раз, а количество потребных согласований возрастёт в тысячи раз.

То есть не автоматизация в итоге получается, но диверсия.

И, в конце концов, почему это невозможно с PDM?

А кто сказал, что невозможно?

Только функционал софта необходимо повысить, что бы там не говорили и сколько бы на всяких янки с самураями не кивали.

1) Итак, они решили сделать в основе всего т.н. стандартные части (Standard Parts). Чем ниже по иерархии находится часть (и чем чаще она используется), тем меньше вероятность ее изменения. Т.е. те кто сверху по иерархии, должны брать то что дают.

А обводы самолёта тоже брать какие дают?

Создание нового всегда идёт по пути "от общего к частному", а если кто вздумает идти иным путём, то пусть это будет наш конкурент, ибо при прочих равных он очень скоро вылетит в трубу.

Всяких же болтов-гаечек и прочих компонентиков с литерой не ниже О1 и у нас хватает.

2) Производственники (Manufacturing) участвуют в дизайне с самого начала, и они имеют возможность влиять на все до того, как был сделан Release.

Опять же, Америку тут не открыли, называется это "т.контр.", только необходимости внесения изменений он не исключит хотя бы потому, что ТЗ на изделие выдаёт заказчик, а не подрядчик.

После того как был сделан Release, вероятность изменения крайне мала, я бы сказал, что такая ситуация (изменения after Release) негативно отразится на тех кто привел к подобной ситуации.

А приводит к такой ситуации банальна конкуренция: взяла фирма А и вывела на рынок новую модель, вот и приходится фирме Б модернизировать свою продукцию.

Кого и как будете наказывать?

А нижеследующее заявление уже вообще ни в какие ворота не лезет.

3) Во всем этом процессе очень большую роль играет разграничение полномочий. Люди, занимающиеся "старшими" асс, не имеют возмойность менять низлежащие, в особенности Standard Parts.

Неужели люди с высшим техническим образованием нуждаются в дополнительном курсе из серии "Найди 10 отличий между сложной технической системой и детским конструктором"? Или народ впрямь думает, что кругом одни тупицы и нагруженый золотом осёл возьмёт любой город?

В прочем, повторим ещё раз аксиомы:

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

2. Всякая новая техническая система появляется как следствие изменившихся внешних условий или прогноза их скорого изменения.

3. Между использующими разные физические принципы системами всегда возникают технические противоречия (например: одному нужно греться, а другому охлаждаться).

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

Таким образом, создание сложной технической системы всегда подразумевает как использование стандартизованных и покупных элементов (с литерой О1 то бишь), так и разработку оригинальных. Кроме того, внесение изменений в конструкцию дело совершенно неизбежное.

P.S. а вообще этот топик нужно читать только целиком.

[Smike 0]

Только функционал софта необходимо повысить, что бы там не говорили и сколько бы на всяких янки с самураями не кивали.

Ну, начинается беседа о патриотизме...

А обводы самолёта тоже брать какие дают?

Создание нового всегда идёт по пути "от общего к частному", а если кто вздумает идти иным путём, то пусть это будет наш конкурент, ибо при прочих равных он очень скоро вылетит в трубу.

Всяких же болтов-гаечек и прочих компонентиков с литерой не ниже О1 и у нас хватает.

Здесь вспоминается Пелевин: если у вас через 10000 жизней появится возмойность конкурировать с этой конретной фирмой, считайте что вам повезло. А если серьезно, то я попытаюсь уточнить: естественно, все новое начинается сверху. Однако, когда мы доходим до Release, то первыми Release получают самые нижние элементы, а те кто сверху должны подстраиваться, ибо сами виноваты, что раньше не заметили.

Опять же, Америку тут не открыли, называется это "т.контр.", только необходимости внесения изменений он не исключит хотя бы потому, что ТЗ на изделие выдаёт заказчик, а не подрядчик.

А приводит к такой ситуации банальна конкуренция: взяла фирма А и вывела на рынок новую модель, вот и приходится фирме Б модернизировать свою продукцию.

Кого и как будете наказывать?

Я здесь говорю о достаточно конкретном сегменте рынка, не смею судить о ваших конкретних проблемах. Однако, если речь идет о подрядчиках (suppliers), то они не могут просто так кого-либо заставить использовать новую модель, они обязаны поставлять старую сколько потребуются. Проблема еще и в том, что на каждое изменение post-Release понадобится сертификация FAA, а этого точно никто не хочет.

Неужели люди с высшим техническим образованием нуждаются в дополнительном курсе из серии "Найди 10 отличий между сложной технической системой и детским конструктором"? Или народ впрямь думает, что кругом одни тупицы и нагруженый золотом осёл возьмёт любой город?

Осел с золотом на самом деле - страшный противник. Я уже несколько лет наблюдаю как Американские и Европейские фирмы год за годом улучшают свою производительность: полностью 3D Design, никаких Drawings, workflow + ограничение на возможность изменений, автоматизированная сертификация. Потом приезжаю в Россию, и наблюдаю людей мечушихся по КБ/заводу с бумажками, потерянние изменения (или неизвестно кем внесенные) и т.д.

[Странник 6]

если у вас через 10000 жизней появится возмойность конкурировать с этой конретной фирмой, считайте что вам повезло.

Аккуратнее в выражениях, пока что наши конкуренты страдают сильною головною болью, да почёсывают свои ушибленные места.

естественно, все новое начинается сверху.

...первыми Release получают самые нижние элементы, а те кто сверху должны подстраиваться, ибо сами виноваты, что раньше не заметили.

Грязная игра однако, со стороны нижних. При правильной юридической организации дела это должно бы им дорого стоить. А по части проектирования для того и нужны CAD/CAE/PLM, что бы такового не случалось, бракоделов должно ловить за руку чем раньше, тем лучше и софт должен это позволять.

Однако, если речь идет о подрядчиках (suppliers), то они не могут просто так кого-либо заставить использовать новую модель, они обязаны поставлять старую сколько потребуются. Проблема еще и в том, что на каждое изменение post-Release понадобится сертификация FAA, а этого точно никто не хочет.

Здесь речь идёт о том, что музыку заказывает тот, кто платит деньги, а не тот кто за эти деньги подряжается выполнить работу. Смотрите сами:

Государство А запустило в серию новый тип бомбовоза, тем самым сделав ЗРК страны Р неэффективными. Посему некое КБ в стране Р в скором времени выпускает ИИ, что бы там директор завода УХ по этому поводу бы не думал. Вследствии прохождения названного ИИ некоего КБ новый бомбовоз страны А становится неэффективным и уже фирма YHOHO вынуждена выпускать ИИ, что бы по этому поводу не думал владелец соответствующего авиазавода JAMF. Таковая игра будет продолжаться до тех пор, пока одна из противостоящих систем не исчерпает инновационую способность. Инициаторами же всей этой чехарды являются соответственно главкомы ВВС страны А и ПВО страны Р, они и оплачивают все издержки.

Осел с золотом на самом деле - страшный противник.

Страшный, но вся его сила лишь в человеческом пороке.

Десятки поколений людей вполне успешно побеждали сию страшилку, и ещё будут побеждать.

Американские и Европейские фирмы год за годом улучшают свою производительность: полностью 3D Design, никаких Drawings, workflow + ограничение на возможность изменений, автоматизированная сертификация. Потом приезжаю в Россию, и наблюдаю людей мечушихся по КБ/заводу с бумажками, потерянние изменения (или неизвестно кем внесенные) и т.д.

Вот сказок про потерянные или неизвестно кем внесённые изменения не надо, как и про полностью 3D дизайн у янки и европейцев. Видали как их профессора "плывут" на первом же конкретном вопросе, да и образцы продукции при реальных "сравнительных испытаниях" оказываются друг друга вполне достойными.

Чай не лаптем щи хлебают ни те, ни другие.

[Smike 0]

Аккуратнее в выражениях, пока что наши конкуренты страдают сильною головною болью, да почёсывают свои ушибленные места.

Как говорят у нас на Западе, попытки оскорбить не было. Я не знаю чем занимается ваша фирма, но я вижу, что эти конкретние клиенты по всему миру имеют не слишком много конкурентов (при этом оккупируя большую часть своего сегмента) , а в России они конкурентов точно не имеют. Или опять осел с золотом виноват?

Грязная игра однако, со стороны нижних. При правильной юридической организации дела это должно бы им дорого стоить. А по части проектирования для того и нужны CAD/CAE/PLM, что бы такового не случалось, бракоделов должно ловить за руку чем раньше, тем лучше и софт должен это позволять.

Не думаю, что грязная игра, просто суровая реальность - если уж так получилось, то сначала отработать, а потом наказывать. Кроме того, не вижу противоречия: все изменения вносятся и вылавливаются в CAD/CAM/PDM до того как был произведен Release, а потом уже поздно.

Здесь речь идёт о том, что музыку заказывает тот, кто платит деньги, а не тот кто за эти деньги подряжается выполнить работу. Смотрите сами:

Государство А запустило в серию новый тип бомбовоза, тем самым сделав ЗРК страны Р неэффективными. Посему некое КБ в стране Р в скором времени выпускает ИИ, что бы там директор завода УХ по этому поводу бы не думал. Вследствии прохождения названного ИИ некоего КБ новый бомбовоз страны А становится неэффективным и уже фирма YHOHO вынуждена выпускать ИИ, что бы по этому поводу не думал владелец соответствующего авиазавода JAMF. Таковая игра будет продолжаться до тех пор, пока одна из противостоящих систем не исчерпает инновационую способность. Инициаторами же всей этой чехарды являются соответственно главкомы ВВС страны А и ПВО страны Р, они и оплачивают все издержки.

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

В качестве не-авиационного примера, у меня есть клиент, который делает некие электро-шкафы, стоящие потом на улице. Когда у их конкурента появляется новая модель, они вынуждены отвечать. Они меняют соответствующий модуль, следя при этом, чтоб минимизировать влияние на остальние блоки. Фактически, это продукт, где 90% деталей пришли из старого, используя PLM функцию Design Copy. И опасность "вихря в Workflow" снижается опять-таки, кардинально.

Вот сказок про потерянные или неизвестно кем внесённые изменения не надо, как и про полностью 3D дизайн у янки и европейцев. Видали как их профессора "плывут" на первом же конкретном вопросе, да и образцы продукции при реальных "сравнительных испытаниях" оказываются друг друга вполне достойными.

Чай не лаптем щи хлебают ни те, ни другие.

Опять-таки, я говорю о том что видел: американские, французские, шведские фирмы, полностью 3D Design, очень четкая система PLM. И то что видел в России - только в апреле имел честь.

Не уверен, что это имеет отношение к теме, по-поводу сравнения реальних образцов. У меня знакомые в свое время работали на американскую авиационную военку. Им каким-то образом достались советские двигатели и они их сравнивали со своими. Так вот, их поразило, что если по параметрам они были вполне сравнимы (что-то хуже, что-то лучше), но советские образцы отличались крайне низкой поддерживаемостью - их проще было выкинуть, чем чинить. Как они (американцы) мне объясняли, у них контракт заключается на 20-30 лет, заказчик пытается заставить фирму над поддерживаемостью, чтобы контролировать свои долговременные расходы. В этом смысле, философия PLM очень даже сюда вкладывается.

[Странник 6]

...я вижу, что эти конкретние клиенты по всему миру имеют не слишком много конкурентов (при этом оккупируя большую часть своего сегмента) , а в России они конкурентов точно не имеют.

Ошибаетесь, конкуренция по самым жёстким законам. В прочем, довольно лирики.

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

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

Кроме того, не вижу противоречия: все изменения вносятся и вылавливаются в CAD/CAM/PDM до того как был произведен Release, а потом уже поздно.

О нет, жизнь куда суровее, чем может показаться. Если какой агрегат нарушит ТЗ, то зачастую лучше сорвать сроки по вине субподрядчика, чем например получить трупы когда изделие начнёт работать уже с пассажирами. Только испытания окончательно расставят всё по своим местам, а они требуют уже реальной матчасти.

То есть если надо выпускать ИИ уже по построенному ЭЦМ, значит это ИИ будет выпущено и "ротор" закрутится.

Они меняют соответствующий модуль, следя при этом, чтоб минимизировать влияние на остальние блоки. Фактически, это продукт, где 90% деталей пришли из старого, используя PLM функцию Design Copy. И опасность "вихря в Workflow" снижается опять-таки, кардинально.

Великое дело модульная конструкция, но не спасёт и она от "ротора".

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

Софт должен позволять парировать все эти издержки по крайней мере не хуже, чем это позволяет делать бумага, а пока мы видим лишь суровую реальность современного ПО.

У меня знакомые в свое время работали на американскую авиационную военку. Им каким-то образом достались советские двигатели и они их сравнивали со своими. Так вот, их поразило, что если по параметрам они были вполне сравнимы (что-то хуже, что-то лучше), но советские образцы отличались крайне низкой поддерживаемостью - их проще было выкинуть, чем чинить. Как они (американцы) мне объясняли, у них контракт заключается на 20-30 лет, заказчик пытается заставить фирму над поддерживаемостью, чтобы контролировать свои долговременные расходы. В этом смысле, философия PLM очень даже сюда вкладывается.

А вот с этим спорить не буду.

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

Правда философию PLM в авторской редакции услышать так и не довелось, хотя противоречивых переложений достаточно... может озвучите?

[Smike 0]

Правда философию PLM в авторской редакции услышать так и не довелось, хотя противоречивых переложений достаточно... может озвучите?

Вынужден согласиться, что мы перешли в лирику. Сформулирую и напишу.

[AnTe 1]

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

...

Это надеюсь понятно?

Ну, с этим проблем и не возникало :)

Вот он, ключевой момент беседы, о котором я не знал (выделено мною):

А вот тут медаль поворачивается другою стороною.

При бумажном обороте будет выпущено ИИ на сборку "колесо" и согласовано с первым уровнем вхождений, допустим "мост передний". То есть, ежели разработчик "колеса" докажет разработчику "моста", что его ИИ не выводит параметры "колеса" за границы ТЗ, то никакого ИИ на "мост", тем более "автомобиль" не потребуется вовсе. Производство и испытания проверят всех и каждого.

Однако, он входит в противоречие с вышесказанным другими (выделено, опять же, мною):

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

В контексте нашего разговора, я понял эту выделенную фразу, примерно как "извещение подписывают все те, кто подписывает эл.модель"

А на деле получается, что далеко не "все"!

Каким-то образом, разработчик "колеса" может "доказать" разработчику всего лишь вышестоящей сборки, что Изменение никого не касается, т.е., как я говорил, "выпустил извещение, которое сам же и подписал".

Что при электронном документообороте невозможно.

Странник, а можно чуть поподробнее, как эта процедура "уговора" вышестоящего проходит в реальности, оформляется документально, при бумажном документообороте? Кто контролирует процесс?

[Странник 6]

Странник, а можно чуть поподробнее, как эта процедура "уговора" вышестоящего проходит в реальности, оформляется документально, при бумажном документообороте? Кто контролирует процесс?

Сядут за стол 3 разгильдяя:

"разраб." - разработчик "колеса",

"вед.констр" - разработчик "моста"

"гл.констр." - начальник отдела

и сообразят на троих, может быть поспорят, может почитают на пальцах или калькуляторе, а в лучшем случае посмотрят на тот же ЭЦМ с новым "колесом", в худьшем случае слегка подерутся, а потом выпьют мировую.

"Нач.предпр." подпишет не глядя, если какой сдвиг - то позвонит секретарше, а та приведёт соответствующего начальника отдела. Всё просто.

А что бы ВСЯ цепочка вхождений автографы ставила - это просто немыслимо, да и невозможно.

[AnTe 1]

Сядут за стол 3 разгильдяя:

"разраб." - разработчик "колеса",

"вед.констр" - разработчик "моста"

"гл.констр." - начальник отдела

и сообразят на троих, может быть поспорят, может почитают на пальцах или калькуляторе, а в лучшем случае посмотрят на тот же ЭЦМ с новым "колесом", в худьшем случае слегка подерутся, а потом выпьют мировую.

Ну, с этим понятно. Процесс разработки, так сказать ;)

"Нач.предпр." подпишет не глядя

Вот оно - ключевая фраза. "Нач.предпр. подпишет" т.о., если я правильно понимаю, утвердится нулевая сборка?. И именно это даёт разрешение нижестоящие сборки не переутверждать.

А PDM такого провернуть не даёт? Полагаю, тут два варианта: либо 1. подпись нулевой сборки "подписывает" все нижестоящие, подпись "нач.предпр." равносильна подписи авторов, либо 2. "нач.предпр" не ставит подписи на нулевой, но ставит какую-то галочку на колесе, после чего колесо перестаёт считаться изменённым для остальных сборок, что и фиксируется соответствующим документом.

Изменено 27 мая 2008 пользователем AnTe

[Странник 6]

"Нач.предпр. подпишет" т.о., если я правильно понимаю, утвердится нулевая сборка?.

Неа, "нач.предпр.", как правильно говорил VOleg, подписывает все извещения.

Здесь начинается область бизнесс-процессов, но мы в неё углубляться не будем.

И именно это даёт разрешение нижестоящие сборки не переутверждать.

Этот подписывает всегда позже всех, разве что в ВП МО может кто пойдёт после..

А PDM такого провернуть не даёт? Полагаю, тут два варианта: либо 1. подпись нулевой сборки "подписывает" все нижестоящие, подпись "нач.предпр." равносильна подписи авторов, либо 2. "нач.предпр" не ставит подписи на нулевой, но ставит какую-то галочку на колесе, после чего колесо перестаёт считаться изменённым для остальных сборок, что и фиксируется соответствующим документом.

"Нач.предпр." просто не в силах уследить за всем, ну представьте что у вас хотя бы 50 тем (новых изделий), в ЭЦМ каждой из которых будет порядка 10000 компонентов... или хотя бы 3...4 самолёта в разработке.

К тому же, зачастую таковые персоны вообще в технике не понимают, а умеют вычитать и делить.

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

[AnTe 1]

Спасибо! Кажется, начинает доходить... Надеюсь, не заманал ещё..

Надеюсь, что, быть может, попытка в очередной раз сформулировать проблему, поможет её решению?

Как я понимаю, проблема состоит в том, что нельзя провести изменение, не регистрируя его как изменение?

То есть, в случае с ИИ - дело понятное. ИИ на каком-то этапе перестают подписывать, и точка.

В случае, когда вместо изделие+ИИ есть новая версия изделия - это сделать не представляется возможным, т.к. в каждом случае изменения возникает НОВЫЙ документ...

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

да.... надо подумать....

правильно я сформулировал? :)

[Странник 6]

правильно я сформулировал? :)

В общем и целом правильно, вот только

ИИ на каком-то этапе перестают подписывать, и точка.

не подписывать перестают, но существует чёткий порог количества потребных виз и подписей.

В электронном же виде получается дополнительная "карусель", что собственно в топик и вынесена.