Чего не хватает в Workflow

[Странник 6]

Так нам и нужны реальные процессы, разве нет? ;-) Штатными средствами как раз процесс и будет попадать к одному и томуже проверяющему. :-) Можно настроить чтоб к разным ходил без применения скриптов. Скрипты весчь нужная и полезная (и достаточно простая в реализации) если нужно сделать что-то уникальное под конкретные задачи или автоматизировать рутинные операции.

Нет, я могу это утверждать, ибо всё прошёл на собственном опыте.

Группа НОРМОКОНТРОЛЬ состоит пусть из 8 сотрудников и 2 начальников, нужно что бы документ на втором предъявлении попал к тому же контролёру, что проверял его и в первый раз. Как это сделать?

Вариант 1 - направить докУмент изначально к начальнику, что бы тот назначил ответственного (экранная форма + пользовательская переменная).

Вариант 2 - создавать роли (чего Search не умеет).

Вариант 3 - написать 1 строчку на скрипте.

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

Если мы всё замкнём на начальника, то это тоже не хорошо... во всяком случае с его точки зрения.

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

Если идет замена документа, то документ идет по тому же маршруту (в маршруте уже исполнители), если кто-то отсутствует, руководитель имеет право заменить исполнителя. Поэтому проблем попадания к тому же исполнителю нет. Это все, конечно, если маршрутизация организована правильно.

Вся штука в том, что документ может и не "запоминать" своего проверяющего, пришёл он на группу первый раз, точно так же приходит и второй, и третий разы. Ваше, Елена, заявление справедливо именно при ролевой организации, но Search совсем не таков. Вот если мы сразу строим процедуру с ОБЯЗАТЕЛЬНЫМ прохождением через начальника подразделения, то всё срабатывает, но самим то начальникам такое положение дел ну совсем не нравится.

Таким образом повторю своё ИМХО: потребность в написании скриптовых заплаток суть вернейший признак недостаточности инженерного софта.

[Странник 6]

Прошёл годик и возник ещё вопрос ко всем пользователям/продавцам/производителям систем электронного документооборота...

Имеется ли хоть в какой ни будь системе способ отправки на согласование не одного документа, но КОМПЛЕКТА документации?

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

P.S. это не фаллометрия.

[trion 0]

Прошёл годик и возник ещё вопрос ко всем пользователям/продавцам/производителям систем электронного документооборота...

Имеется ли хоть в какой ни будь системе способ отправки на согласование не одного документа, но КОМПЛЕКТА документации?

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

P.S. это не фаллометрия.

В Teamcenter есть пакет ассоциируемых документов, который формируется перед запуском определённого процесса Workflow.

Сами собой документы никого не тянут по разным бизнес процессам.

Изменено 23 июня 2010 пользователем trion

[Странник 6]

Сами собой документы никого не тянут по разным бизнес процессам.

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

[trion 0]

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

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

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

Все проблемы здесь - надуманные, их нет.

Изменено 24 июня 2010 пользователем trion

[Странник 6]

Все проблемы здесь - надуманные, их нет.

Однако...

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

[trion 0]

Однако...

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

Создаются стандарты предприятия, которые описывают как происходит утверждение документов.

Формируется группа утверждения для каждого бизнес процесса flow chata и т.д.

Это все рутина.

[Странник 6]

Создаются стандарты предприятия, которые описывают как происходит утверждение документов.

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

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

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

Вот поэтому то

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

Кстати...

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

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

[trion 0]

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

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

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

Вот поэтому то

Кстати...

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

Утверждается все в электронном виде, утверждающее лицо может посмотреть в режиме только для чтения любую информацию о проекте в системе PDM.

Утверждение в системе PDM немного смещает приоритеты по сравнению с ЕСКДэшной схемой.

Сначала происходит верификация данных - то есть модельный контроль и контроль правильности заполнения метадданых. Которая заканчивается заполнением Check list'ов.

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

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

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

Обычно сначала утверждается цифровой макет изделия без чертежей, а потом еще и чертежи. Здесь опять возможны варианты.

Изменено 26 июня 2010 пользователем trion

[Странник 6]

Обычно сначала утверждается цифровой макет изделия без чертежей, а потом еще и чертежи. Здесь опять возможны варианты.

Хе... вот тут то уж точно будет засада так засада, да ещё и не одна:

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

2. лицензии CAD-систем как правило недёшевы, а при озвученном подходе ставить их придётся всем... менегеры этого могут не понять

3. электронно-цифровой макет вообще штука дышащая ибо процесс проектирования всегда был, есть и будет версионно-итерационным.

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

[trion 0]

Хе... вот тут то уж точно будет засада так засада, да ещё и не одна:

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

Персонал надо учить - сейчас это планка такая. Иначе нет смысла внедрять PDM и инновации.

PMI наносить не обязательно - для первого утверждения достаточно просто утвердить сам макет или нанести минимум необходимой информации. Или наоборот полностью нанести всю информацию - как это делают в Боинге и других местах...

2. лицензии CAD-систем как правило недёшевы, а при озвученном подходе ставить их придётся всем... менегеры этого могут не понять

Teamcenter позволяет работать в режиме утверждения/согласования без лицензий на NX и имея только лицензию на тонкий клиент - это очень дешево.

3. электронно-цифровой макет вообще штука дышащая ибо процесс проектирования всегда был, есть и будет версионно-итерационным.

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

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

[Странник 6]

Персонал надо учить - сейчас это планка такая. Иначе нет смысла внедрять PDM и инновации.

Врядли кто будет спорить с простою мудростью

век живи - век учись

однако по поводу планочки утвержение слишком категорично, ИМХО. Даже у того самого NX ежегодно выходят новые версии и ничено лучшего чем чертеж формата pdf тут не придумано. К тому же мнение разработчиков CAD-системы вовсе не является законом для покупателей, скорее даже наоборот.

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

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

а я по модели не понял

если не технологи, то менегер.

[Sten 2]

однако по поводу планочки утвержение слишком категорично, ИМХО. Даже у того самого NX ежегодно выходят новые версии и ничено лучшего чем чертеж формата pdf тут не придумано. К тому же мнение разработчиков CAD-системы вовсе не является законом для покупателей, скорее даже наоборот.

Странно..КБ Сухому даже не понадобились новые версии, чтобы найти ЛУЧШЕ, чем чертеж в формате pdf,а именно 3D модель образмеренная PMI без чертежа. Новую птичку их видели? 75% конструкции выполнено без чертежей. Поспорьте с реальностью. Я ещё десяток предприятий знаю на территории СНГ, где чертеж уже не является первичным и где метал режут без чертежа.Да и ещё сходите в цеха и расскажите работягам, что им проще сборочные чертежи читать, чем смотреть как это должно быть в 3D макете, повеселите мужиков.

[trion 0]

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

если не технологи, то менегер.

Верификация - заканчивается одним проверяющим.

А валидацию по идеи должен делать или нач. отдела или ведущий конструктор по изделию.

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

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

Странно..КБ Сухому даже не понадобились новые версии, чтобы найти ЛУЧШЕ, чем чертеж в формате pdf,а именно 3D модель образмеренная PMI без чертежа. Новую птичку их видели? 75% конструкции выполнено без чертежей. Поспорьте с реальностью. Я ещё десяток предприятий знаю на территории СНГ, где чертеж уже не является первичным и где метал режут без чертежа.Да и ещё сходите в цеха и расскажите работягам, что им проще сборочные чертежи читать, чем смотреть как это должно быть в 3D макете, повеселите мужиков.

Вопрос применения PMI связан с оснащенностью производства современным производственным и контрольно-измерительным оборудованием.

Так как разрабатывать программы для ЧПУ станков - на основе модели с PMI производительней и это позволяет избежать ошибок. То же самое касается геометрического контроля - оборудование и софт для метрологического контроля геометрии работает с моделью и PMI информацией. Некоторые заграничные системы САПР ТП - тоже работают с моделью и PMI.

Изменено 27 июня 2010 пользователем trion

[Странник 6]

Странно..КБ Сухому даже не понадобились новые версии, чтобы найти ЛУЧШЕ, чем чертеж в формате pdf,а именно 3D модель образмеренная PMI без чертежа. Новую птичку их видели? 75% конструкции выполнено без чертежей. Поспорьте с реальностью.

Между прочим, разные птички/рыбки и строятся по-разному. У одних создаётся корпус как балочная конструкция и все "потроха" спокойно расставляются по своим местам уже после того. Другим иногда приходится прорезать автогеном до 7 УЖЕ СМОНТИРОВАННЫХ уровней и переделывать десятки помещений только потому, что некий задирищенский машиностроительный завод и/или РЖД несвоевременно подогнали к сборке крупногабаритный агрегат. А третьи вообще всё делают "от потрохов" и даже вне зависимости от того, как при этом надувает щёки аэродинамик. Больше того, у одних производство считай единичное да ещё и за каждым изделинм тянется ворох эксплуатационной документации, а другие изначально живут в мелкой серии с более или менее плавным переходом в массовое производство.

Я ещё десяток предприятий знаю на территории СНГ, где чертеж уже не является первичным и где метал режут без чертежа.Да и ещё сходите в цеха и расскажите работягам, что им проще сборочные чертежи читать, чем смотреть как это должно быть в 3D макете, повеселите мужиков.

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

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

Верификация - заканчивается одним проверяющим.

А валидацию по идеи должен делать или нач. отдела или ведущий конструктор по изделию.

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

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

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

[trion 0]

Цитата(trion @ Jun 27 2010, 8:10) *

Верификация - заканчивается одним проверяющим.

А валидацию по идеи должен делать или нач. отдела или ведущий конструктор по изделию.

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

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

-------------------------------------

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

Во всем мире нормативные требования - это всего лишь договоренность между продавцом и клиентом. Договорятся использовать DIN - будут работать по DIN, или договорятся работать по ASME...

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

[Sten 2]

Между прочим, разные птички/рыбки и строятся по-разному. У одних создаётся корпус как балочная конструкция и все "потроха" спокойно расставляются по своим местам уже после того. Другим иногда приходится прорезать автогеном до 7 УЖЕ СМОНТИРОВАННЫХ уровней и переделывать десятки помещений только потому, что некий задирищенский машиностроительный завод и/или РЖД несвоевременно подогнали к сборке крупногабаритный агрегат. А третьи вообще всё делают "от потрохов" и даже вне зависимости от того, как при этом надувает щёки аэродинамик. Больше того, у одних производство считай единичное да ещё и за каждым изделинм тянется ворох эксплуатационной документации, а другие изначально живут в мелкой серии с более или менее плавным переходом в массовое производство.

Это демагогия. Я вам говорю - конкретный пример, самолет, сложное изделие, летает, все новые ДСЕ спроектированы и сделаны без чертежей. Ещё есть ГСС, Миг, Миль,итд. где вполне успешно двигаются к этому. Эта реальность идет вразрез с вашими заявлениями, которые вы уже похоже отстаиваете только ради самого желания поспорить.

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

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

Эти "специалисты" цепляющиеся за свои привычки и нежелание объективно пересмотреть подходы будут скоро вымирать как динозавры.Ещё лет 5 назад можно было встретить одиозных личностей, которые с пеной у рта доказывали, что кульман ничего не заменит, и все эти CAD/PDM несерьёзные игрушки. И где они сейчас? Тот кто по-шустрей и по-мудрей всё-таки нашли в себе смелость признать очевидное,а те кто по-упрямей, те вместе с кульманами отправились на свалку истории:) Ваша позиция пример аналогичной одиозности, только другого уровня. На Сухом такие товарищи тоже имели место быть,однако ж самолет летает,а ретрограды нервно курят в сторонке:)

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

И как бы вам не хотелось отстаивать свои привычки, но реальность такова, что конструктор хочет он того или нет, сейчас должен работать с технологом на самой ранней стадии, и КД в виде модели должно выходить от конструктора уже с учетом мнения технолога. Просто потому, что весь этот PLM ориентирован на то, чтобы как можно раньше выпустить изделие согласно требованиям ТЗ, а не на то, чтобы как можно раньше конструктор выпустил чертеж.

[Странник 6]

Это демагогия.

Чтож откроем <noindex>словари</noindex>.

Демагогия (др.-греч. δημαγωγία «руководство народом; заискивание у народа») — набор ораторских и полемических приёмов и средств, позволяющих ввести аудиторию в заблуждение и склонить её на свою сторону. Чаще всего применяется для достижения политических целей, в рекламе и пропаганде.

По всей видимости в данной конкретной полемике сие определение употреблено явно не по адресу.

Я вам говорю - конкретный пример, самолет, сложное изделие, летает, все новые ДСЕ спроектированы и сделаны без чертежей. Ещё есть ГСС, Миг, Миль,итд. где вполне успешно двигаются к этому. Эта реальность идет вразрез с вашими заявлениями, которые вы уже похоже отстаиваете только ради самого желания поспорить.

Кивать на опытные образцы

Т-50

не следовало бы, хотя лично мне очень бы хотелось точно знать, что ВВС России смогут одновременно поднять в воздух тысячи и десятки и тысяч таких аэропланов.

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

name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="

type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350" align="center">

КНААПО

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

А вот изделие другого класса:

name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="

type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350" align="center">

FGM-148 Javelin

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

name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="

type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350" align="center">

brahmos

Это ещё скорости более 1000 м/с, сотни километров дальности и преодоление противодействия средств РЭБ.

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

P.S. А на личности переходить не стоит в принципе.

[Sten 2]

Это ещё скорости более 1000 м/с, сотни километров дальности и преодоление противодействия средств РЭБ.

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

P.S. А на личности переходить не стоит в принципе.

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

[trion 0]

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

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

А для серийного изделия - это критично. Так как величины издержек при появлении несоответствий слишком велики.

Посмотрите даже на процесс утверждения эл. документов - в безбумажном варианте вы утверждаете только 3D модели и структуру проекта.

А в бумажном варианте - в два раза больше объектов.

Изменено 27 июня 2010 пользователем trion