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

[VOleg 228]

Важно что бы у софта крыша не ехала при этом.

Софт - это "автомобиль", а ГОСТы - это "знаки дорожного движения". Автомобиль САМ по дороге не едет. Едет крыша.

[DGroot 8]

..............Ни дать, ни взять – стратегическая ловушка.

Вопрос: какой есть опыт борьбы с этим «весёлым» эффектом?

А Вы думаете при бумажном документообороте было как-то иначе???

Внедрение PDM должно лишь:

- уменьшить количество возможных ошибок (недоделок и.т.п) т.е. поднять качество разработки документации и изделия в целом.

- обеспечить ускорение процессов согласования (меньше бегать ногами по кабинетам).

и еще кое-что другое.

Изменено 29 марта 2008 пользователем DGroot

[Странник 6]

А Вы думаете при бумажном документообороте было как-то иначе???

Да не думаю, а прошёл всё это на личном опыте, при чём не единожды.

На теперешнем инженерном софте такие фокусы, в коих лично принимал не единожды участие, не пройдут.

[DGroot 8]

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

Другой разговор, проверяет ли нормоконтроль степень ответственности, автора извещения.

[Странник 6]

А визы разработчика следующего верхнего уровня вхождений ужели не достаточно?

[AnTe 1]

Пока бюро А готовит свои изменения (см. выше), в бюро Б возникла потребность проводить изменения в узле АБВ.3445.100.050. То, что описывалось ранее имеет место быть и здесь. Т.е. конструктор бюро Б меняет АБВ.3445.100.050, обновляет АБВ.3445.100.000... пока всё штатно, но только до тех пор пока эти изменения не встретятся в одном изделии АБВ.3445.000.000.

Так вот, если использовать одну единственную версию, то в случае возникновения коллизий в АБВ.3445.000.000 причин не найдешь! А если, несколько версий, то получается:

а) ГЛАВНАЯ версия изделия АБВ.3445.000.000

б) версия изделия АБВ.3445.000.000 с изменением от бюро А

в) версия изделия АБВ.3445.000.000 с изменением от бюро Б

и гл. конструктор может сделать для себя

г) версия изделия АБВ.3445.000.000 с обеими изменениями

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

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

ИТОГО: на стадии конструкторской разработки (конструкторской подготовки изменения) не обойтись без многоверсионности.

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

[VOleg 228]

Во-первых не рекомендую использовать такое обозначение:

АБВ.3445.000.000

без указания на стандарт, по которому оно сформировано.

Во-вторых, у АБВ.3445.000.000 есть автор и если этот автор я то никакое бюро А, Б, В, Г ..... изменения не внесут без моего "горячего" участия. Так что в электронной и бумажной технологиях я положу главному конструктору всего 1 вариант, который я подпишу и буду отвечать за него.

Ну а если автор кто-то другой, то это уже его проблемы.

[AnTe 1]

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

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

:wallbash:

[Странник 6]

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

А это потому, что КД утверждать не приходится, по видиму.

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

[AnTe 1]

А это потому, что КД утверждать не приходится, по видиму.

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

Когда бы раз 100000 пробежали бы по "заячьему кругу", да покланялись каждый раз каждой твари, то сразу бы поняли, что такое мягкая и жёсткая подпись,

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

а так же что значат понятия контрольной суммы и непринципиального изменения.

ну, с этим вроде понятнее..

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

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

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

С точки зрения WORKFLOW это будет не слабый «ротор» ибо количество таких процедур на каждом более высоком уровне сборочных единиц будет расти едва не в геометрической прогрессии. Ни дать, ни взять – стратегическая ловушка.

Если всё делать по правилам, то это и сейчас неслабый «ротор». Или электронный документооборот добавляет в этот ротор свои "вихри"? Изменено 11 мая 2008 пользователем AnTe

[Странник 6]

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

"Мягкая" это когда на непринципиальных изменениях подпись останется невредимой.

Например: по многочисленным просьбам завода некий радиус скругления в детали АБВГ.07.04.005 сменили с 0,3 на 0,5*. С точки зрения покрытия, термообработки, материала-заменителя, маркировок, прочности, даже массы в штампе чертежа изменение совершенно непринципиальное, но технологам оно надо, а конструктора не возражают. На бумаге по всем инстанциям пройдёт извещение с переправкой R0,3 на R0,5*, но даже "разраб.", "провер.", "т.контр.", "гл.мет.", "н.контр.", "утв." да и всякие на полях визирующие обновлять своих подписей не будут. Тем более на уровне сборок, особенно общих. Сделали указание о внедрении и задели и производство счастливо.

Теперь смотрим тож самое изменение при электронной технологии...

Модель параметризована полностью, радиус правим с 0,3 на 0,5 очень легко, чертёж обновляется тоже, но тут же появляется новая итерация этой детали и чертежа на неё, а вместе с ними сборок первого, второго и последующих уровней вхождения, вплоть до АБВГ.00.00.000, вместе с ними и чертежи, и всё это надо будет заново утверждать. Потом передавать в производство и заново же гнать ТД...

Вот это и называется "ротор".

[AnTe 1]

"Мягкая" это когда на непринципиальных изменениях подпись останется невредимой.

Например: по многочисленным просьбам завода некий радиус скругления в детали АБВГ.07.04.005 сменили с 0,3 на 0,5*. С точки зрения покрытия, термообработки, материала-заменителя, маркировок, прочности, даже массы в штампе чертежа изменение совершенно непринципиальное, но технологам оно надо, а конструктора не возражают. На бумаге по всем инстанциям пройдёт извещение с переправкой R0,3 на R0,5*, но даже "разраб.", "провер.", "т.контр.", "гл.мет.", "н.контр.", "утв." да и всякие на полях визирующие обновлять своих подписей не будут. Тем более на уровне сборок, особенно общих. Сделали указание о внедрении и задели и производство счастливо.

т.о. если при электронном документообороте ввести понятие вроде "изменение, не касающееся..", и отметить тех, кто "не возражает", (за подписями тех, кто за это изменение ответственен?), то проблема решится?

[VOleg 228]

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

[AnTe 1]

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

Так, правильно я сформулировал? Честно говоря, запарился я уже по выдуманным АБВГ.0000.... строить деревья, и разбираться, что же имелось в виду.

[AnTe 1]

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

т.е. эти "непринципиальные" изменения, на самом деле, подписываются и при бумажном документообороте? Хоть и подписи ставятся только на извещении?

[AnTe 1]

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

например, ТОЛЬКО разработчик ИИ?

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

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

Олег, поясните, пожалуйста, если не сложно, в двух словах, как в данном случае будет проходить процесс согласования изменения-выпуска_новой_версии?

ps не могу найти, как удалить предыдущих два своих сообщения. глупости какие-то понаписал:), а грохнуть их не могу:(

[Странник 6]

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

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

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

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

И куда же они денутся?

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

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

Нужны какие то специальные решения на уровне функционала PDM систем, ИМХО.

[VOleg 228]

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

Все свалили в кучу - уже здесь на форуме запутались.

Крохотная гайка влияет и серьезно. До замены была одна гайка, после замены другая. Меняются ведомости покупных, лимитные карты.... При этом старая гайка как была и так остается если были выпущены изделия с этой гайкой.

А теперь смотрим внимательно:

Разработчик детали выпустил ИИ, которое сам же и подписал. Всё.

Разработчик НОВОЙ гайки просто выпустил чертеж новой гайки и поставил ее на учет. Его работа закончена.

Далее разработчик "крохотной" сборки выпускает извещение "старую гайку удалить - новую гайку поставить" "внедрить с 26 комплекта" "версия 1.07 или "исполнение -05".

И вот тут 2 пути:

- первый - версия - все изменения организационные - поменяли версию и все - до ИИ были версии 1.06 после ИИ версии 1.07. (т.е. продолжаем выпускать тоже изделие, просто с другой версией). - все это отражается в извещении и, соответственно, в PDM.

- второй - исполнение - всё до самого верха должно получить исполнение - изделие имело 4 исполнения - после ИИ 5 исполнений - в извещении это все и прописываем и имеем еще одно изделие с еще одним набором сборок. (теперь можем выпускать и "старое" изделие и "новое")

Вроде все просто.

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

[Странник 6]

Кстати, придумайте хотя бы 3 причины по которой в ГСС уничтожают параметризацию моделей перед установкой их в ЭЦМ изделия, только поток изменений снизу и постоянные из-за этого перестройки общего не указывайте.

Хорошо они поступают или плохо - это обсудим позже.

[VOleg 228]

Кстати, придумайте хотя бы 3 причины по которой в ГСС уничтожают параметризацию моделей перед установкой их в ЭЦМ изделия

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