ЭСИ

[белог 0]

И что же можно на сегодняшний момент предложить конструктору? :)

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

получается, cadzero прав?

Все это потому что все мы работаем по Райкину : К пуговицам претензии есть? - не чувствуем себя частью общего дела (процесса производства продукции).

В результате конструктор может заявить (в ответ на запрос что правильно модель или чертеж?) модель не правильная, чертеж не правильный, и это все заметьте из "архива".

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

Так что получается перед внедрением PDM - нужно повысить "культуру производства"????

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

[cadzero 0]

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

А по поводу конструктора... Разве не забота конструктора заполнять такие атрибуты, как входимость, применяемость. Если будет активно использоваться ЭСИ, то это "ляжет на плечи" информационной системы.

А структура конструкторской документации? При хорошей PDM-системе разработчик разрабатывает себе КД на свою составную часть изделия, а структура КД выстраивается автоматом.

Я думаю, что правильная PDM-система (а именно там строится ЭСИ) хороший помощник прежде всего конструктору.

Видите ли... :)

-1. Имея сборочную модель конструктор имеет и ЭСИ.

-2. Не дело конструктора заполнять атрибуты, особенно такие как входимость, применяемость - это ДОЛЖНА делать PDM.

У нас на предприятии один ретивый юный пионер толкает идею создания ERP на базе 1С, там, кроме прочего, конструктор должен бы РУКАМИ вводить: -а) комплектовочную ведомость, -б) закупочную ведомость и -в) создать в специальной программе эту самую ЭСИ. На предложения брать эту информацию хотя бы из таблиц CSV или EXEL и вносить программно фанатик категорически отказывается ссылаясь на то, что ему трудно.

Знаете, не могли бы Вы объяснить принципиальную разницу между Вами и этим ретивым?

[sceptic 0]

Не дело конструктора заполнять атрибуты, особенно такие как входимость, применяемость - это ДОЛЖНА делать PDM.

Ну, вы же ратуете, как я понял, за бесполезность PDM.

А кроме того, если вы не в курсе ОБОЗНАЧЕНИЕ ДОКУМЕНТА, В КОТОРОМ ВПЕРВЫЕ ЗАПИСАН ДАННЫЙ ДОКУМЕНТ (в просторечии ВХОДИМОСТЬ) записывается в графе 25 основной надписи, на любом конструкторском документе, ЭСИ и PDM здесь ни при чем. Но PDM действительно позволяет автоматизировать заполнение этого атрибута.

У нас на предприятии один ретивый юный пионер толкает идею создания ERP на базе 1С, там, кроме прочего, конструктор должен бы РУКАМИ вводить: -а) комплектовочную ведомость, -б) закупочную ведомость и -в) создать в специальной программе эту самую ЭСИ. На предложения брать эту информацию хотя бы из таблиц CSV или EXEL и вносить программно фанатик категорически отказывается ссылаясь на то, что ему трудно.

Знаете, не могли бы Вы объяснить принципиальную разницу между Вами и этим ретивым?

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

Какие PDM, ERP лучше использовать сейчас и надо ли вообще использовать, каждое предприятие и его персонал решают сами. Я вообще-то против фанатизма в любом его проявлении. И разницу между тем РЕТИВЫМ ПИОНЕРОМ и собой я Вам не собираюсь объяснять.

[cadzero 0]

Ну, вы же ратуете, как я понял, за бесполезность PDM.

Где???

А кроме того, если вы не в курсе ОБОЗНАЧЕНИЕ ДОКУМЕНТА, В КОТОРОМ ВПЕРВЫЕ ЗАПИСАН ДАННЫЙ ДОКУМЕНТ (в просторечии ВХОДИМОСТЬ) записывается в графе 25 основной надписи, на любом конструкторском документе, ЭСИ и PDM здесь ни при чем. Но PDM действительно позволяет автоматизировать заполнение этого атрибута.

Если есть PDM никто не будет рыться по чертежам в поисках атрибута "Входимость", ибо эта информация легко получается из отчета по базе. Да и само ОБОЗНАЧЕНИЕ документа теряет свой смысл.

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

Какие PDM, ERP лучше использовать сейчас и надо ли вообще использовать, каждое предприятие и его персонал решают сами. Я вообще-то против фанатизма в любом его проявлении. И разницу между тем РЕТИВЫМ ПИОНЕРОМ и собой я Вам не собираюсь объяснять.

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

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

[AnTe 1]

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

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

Хотелось бы видеть ещё плюсы ЭСИ, для конструкторов.

Так что получается перед внедрением PDM - нужно повысить "культуру производства"????

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

Есть такой способ - показать, что люди получат при этом. Вот только знать бы ещё это :)

[AnTe 1]

Если есть PDM никто не будет рыться по чертежам в поисках атрибута "Входимость", ибо эта информация легко получается из отчета по базе. Да и само ОБОЗНАЧЕНИЕ документа теряет свой смысл.

А ведь действительно..

Хочу ещё раз напомнить, что понимается под ЭСИ - формализованная структура данных, которая точно соответствует спецификациям, т.е. (теоретически) может их заменить. Нужна ли конструктору такая структура?

И вообще, какие реальные плюсы от её внедрения, в предположении, что в АСУП структуру изделия и так создают.

Изменено 2 ноября 2011 пользователем AnTe

[Елена 116]

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

[sceptic 0]

Где???

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

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

Я, кажется, пока ничего не предлагал.

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

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

Что же касается обсуждаемой темы, мое мнение такое:

1. Если вести дела по принципу "к пуговицам претензии есть?", то ЭСИ и соответственно PDM конструктору только мешают

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

3. К идеалу все-таки стремиться нужно. И если не удается найти удобные инструменты (например, PDM-систему), нужно создавать такие инструменты самим. (То, что уважаемый Cadzero не против PDM, он сам написал)

[cadzero 0]

А ведь действительно..

Хочу ещё раз напомнить, что понимается под ЭСИ - формализованная структура данных, которая точно соответствует спецификациям, т.е. (теоретически) может их заменить. Нужна ли конструктору такая структура?

И вообще, какие реальные плюсы от её внедрения, в предположении, что в АСУП структуру изделия и так создают.

Спецификация - форма представления структуры изделия. При наличии ЭСИ спецификация является отчетом по ЭСИ в текстовой форме. Соотв. должна составляться автоматически БЕЗ УЧАСТИЯ КОНСТРУКТОРА. Создав структуру он свое дело уже сделал. То же самое справедливо для всяческих ведомостей - закупочной, комплектовочной, допустимых замен и пр.

Сама же ЭСИ должна формироваться программно по сборочной модели изделия. Недопустимо вводить одну и ту же информацию по нескольку раз ВРУЧНУЮ да еще и в разные базы. Один раз введено в одной точке и стоп. Конструктор - не ксерокс, стОит дорого, устаёт быстро, ошибается часто.

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

Я, кажется, пока ничего не предлагал.

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

Что же касается обсуждаемой темы, мое мнение такое:

1. Если вести дела по принципу "к пуговицам претензии есть?", то ЭСИ и соответственно PDM конструктору только мешают

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

3. К идеалу все-таки стремиться нужно. И если не удается найти удобные инструменты (например, PDM-систему), нужно создавать такие инструменты самим. (То, что уважаемый Cadzero не против PDM, он сам написал)

Меня уже достали отечественные продавцы Больших Волшебных Кнопок, пытающиеся впарить, что увеличение ручного труда в 2..3 раза является автоматизацией.

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

Да не вопрос - СУБД + WEB-интерфейс. Пример - Windchill. Думаю, что это не единственный, но другого пока не щупал.

[DGroot 8]

Спецификация - форма представления структуры изделия. При наличии ЭСИ спецификация является отчетом по ЭСИ в текстовой форме. Соотв. должна составляться автоматически БЕЗ УЧАСТИЯ КОНСТРУКТОРА. Создав структуру он свое дело уже сделал. То же самое справедливо для всяческих ведомостей - закупочной, комплектовочной, допустимых замен и пр.

Во первых. Извините, однако пока ПО не достигло такого уровня когда что либо в части проектирования происходит без участия человека...

Во вторых перечень видов спецификаций не ограничивается "конструкторскими" спецификациями на изделия, основой которых служит Части ЭСИ, получаемые из электронных моделей сборочных единиц.

Существует масса разнообразных спецификаций комплектов за которыми никаких электронных моделей не стоит и близко.

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

Например СБ чертежи печатных плат проектируются в Autocad. (Я пока не слышал что из этого можно построить ЭСИ автоматически).

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

.................... Недопустимо вводить одну и ту же информацию по несколько раз ВРУЧНУЮ да еще и в разные базы. Один раз введено в одной точке и стоп.

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

[AnTe 1]

Спецификация - форма представления структуры изделия. При наличии ЭСИ спецификация является отчетом по ЭСИ в текстовой форме. Соотв. должна составляться автоматически БЕЗ УЧАСТИЯ КОНСТРУКТОРА. Создав структуру он свое дело уже сделал.

Вопрос - как он её создавал? Тем более, что:

Сама же ЭСИ должна формироваться программно по сборочной модели изделия.

Этого мало. Как я уже писал выше, и привёл конкретные примеры DGroot, в модели содержится далеко не вся информация, которую требует ЭСИ.

Ещё добавлю, по вышеперечисленному.

в сборочной модели Недопустимо вводить одну и ту же информацию по нескольку раз ВРУЧНУЮ да еще и в разные базы

А что, к примеру, прикажете делать с созданной и отлаженной базой отлаженной системы АСУП? :)

Елена написала о том, что для производства возможна перекачка структуры, и это абсолютно верно. Это ж с ума сойти сводить в одно, заменять, к примеру, в многолетработающей АСУП доступ к её БД на сущности системы документоборота. Сказать точнее - это сделать практически невозможно, без кардинальной переработки кода АСУП, а ради чего?

Но теперь, если оторваться от производства, в предположении, что те как работали, так и будут работать, разве что группа по вводу данных в базу из документов устранится, - нужна ли конструктору ЭСИ? Стоит ли овчинка выделки?

Изменено 3 ноября 2011 пользователем AnTe

[белог 0]

Вопрос - как он её создавал? Тем более, что:

Этого мало. Как я уже писал выше, и привёл конкретные примеры DGroot, в модели содержится далеко не вся информация, которую требует ЭСИ.

Ещё добавлю, по вышеперечисленному.

А что, к примеру, прикажете делать с созданной и отлаженной базой отлаженной системы АСУП? :)

Елена написала о том, что для производства возможна перекачка структуры, и это абсолютно верно. Это ж с ума сойти сводить в одно, заменять, к примеру, в многолетработающей АСУП доступ к её БД на сущности системы документоборота. Сказать точнее - это сделать практически невозможно, без кардинальной переработки кода АСУП, а ради чего?

Но теперь, если оторваться от производства, в предположении, что те как работали, так и будут работать, разве что группа по вводу данных в базу из документов устранится, - нужна ли конструктору ЭСИ? Стоит ли овчинка выделки?

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

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

Так вот для этой самой мобильности и вводится электронный документооборот, система PDM, и как основа всего этого проектирование от "модели".

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

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

Когда количество модификаций переваливает за 5 и объем поставки каждой из них тоже возрастает , а система отсутствует , на производстве творится полный ХАОС (думаю многим знакомый)

[cadzero 0]

Во первых. Извините, однако пока ПО не достигло такого уровня когда что либо в части проектирования происходит без участия человека...

Во вторых перечень видов спецификаций не ограничивается "конструкторскими" спецификациями на изделия, основой которых служит Части ЭСИ, получаемые из электронных моделей сборочных единиц.

Существует масса разнообразных спецификаций комплектов за которыми никаких электронных моделей не стоит и близко.

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

Например СБ чертежи печатных плат проектируются в Autocad. (Я пока не слышал что из этого можно построить ЭСИ автоматически).

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

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

-1. Составление спецификации проектированием не является. ДАВНО делается без участия человека во множестве разных систем.

-2. По одной и той же модели можно получить (получить, а не спроектировать!!) много РАЗНЫХ спецификаций.

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

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

Есть вещи, которые проще сделать руками, чем смоделировать. Есть ситуации, когда проще набить информацию вручную, чем создавать правильную модель. Однако это не отменяет основного правила: Дублирование ввода информации недопустимо. В противном случае информационная система достаточно быстро теряет достоверность и из полезного инструмента превращается в обузу.

P.S. Что вы имеете ввиду под "проектированием ЧЕРТЕЖА" ? 8-0

[cadzero 0]

А что, к примеру, прикажете делать с созданной и отлаженной базой отлаженной системы АСУП? :)

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

Елена написала о том, что для производства возможна перекачка структуры, и это абсолютно верно. Это ж с ума сойти сводить в одно, заменять, к примеру, в многолетработающей АСУП доступ к её БД на сущности системы документоборота. Сказать точнее - это сделать практически невозможно, без кардинальной переработки кода АСУП, а ради чего?

Ну, раз нельзя улучшить - значит пора менять.

Но теперь, если оторваться от производства, в предположении, что те как работали, так и будут работать, разве что группа по вводу данных в базу из документов устранится, - нужна ли конструктору ЭСИ? Стоит ли овчинка выделки?

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

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

[sceptic 0]

cadzero

Конструктору она (прим.-ЭСИ) нахрен не нужна - у него другие представления изделия есть.

Она нужна снабженцам, бухам, плановикам, etc..

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

Какой вы противоречивый, батенька

[cadzero 0]

Какой вы противоречивый, батенька

Напоминаю:

-1. Имея сборочную модель конструктор имеет и ЭСИ.

Поясняю (и повторяю):

-1. У конструктора и так ЕСТЬ целостная модель изделия. Дублирующая структура ему не нужна.

-2. Конструкторская модель может быть и неполным представлением изделия. Полное может быть полезно конструктору, но дублирующая структура ему всё-равно не нужна. :)

-3. Если в ЭСИ должно быть больше информации, чем в конструкторской модели, то ЭСИ должна строиться дополнением конструкторской модели силами заинтересованных подразделений БЕЗ УЧАСТИЯ КОНСТРУКТОРА.

Теперь понятно? :-)

[AnTe 1]

Тут не совсем понятно. "Целостная модель изделия" - это сборка в системе конструкторского моделирования?

Если это так - это в неё добавляются все сопутствующие не-геометрические данные? Их же помойка целая!

-3. Если в ЭСИ должно быть больше информации, чем в конструкторской модели, то ЭСИ должна строиться дополнением конструкторской модели силами заинтересованных подразделений БЕЗ УЧАСТИЯ КОНСТРУКТОРА.

А кто, в таком случае, отвечает за состав? Кто является автором и отвечает за документ "спецификация", который получится автоматическим образом?

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

Изменено 3 ноября 2011 пользователем AnTe

[AnTe 1]

Все это потому что все мы работаем по Райкину : К пуговицам претензии есть? - не чувствуем себя частью общего дела (процесса производства продукции).

...

Так что получается перед внедрением PDM - нужно повысить "культуру производства"????

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

Дело не только в этом.

Я довольно много встречал заявлений (чаще всего - рекламных), о необычайной пользе ведение ЭСИ, общей базы данных, под эгидой т.н. "единого информационного пространства" etc, сейчас много новых модных словечек.

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

На практике, как правило, везде всё одно - имеется куча различных систем (конструкторского проектирования, технологии, производства и т.п.), различные БД, между которыми налаживается автоматизированная связь.

Объяснять такую схему работы исключительно тем фактом, что конструкторы "не хотят за костюмчик отвечать" - не совсем корректно. Это ещё нужно доказать. Вот, скажем, ситуация у меня: предположим, все конструкторы начнут не спецификации выпускать, а заполнять ЭСИ (это если им ещё механизм соответствующий где-то найти и предоставить). Результат? На текущий момент он вырисовывается следующий: тысяча конструкторов облегчит работу аж десяти женщин, даже не являющихся специалистами, которые на сегодня ведут базу АСУП. Покамест, это единственный видимый результат столь кардинальных подвижек, т.к. информацию о входимости конструкторы запросто получают из базы АСУП, уже сегодня.

Итого: цена костюмчика значительно возрастает.

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

Изменено 6 ноября 2011 пользователем AnTe

[cadzero 0]

тысяча конструкторов облегчит работу аж десяти женщин, даже не являющихся специалистами

ППКС :)

[белог 0]

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

По- моему это все таки вопрос "что вперед курица или яйца".

При настройке системы должно существовать ТЗ и т.д. , где прописаны будут набившие оскомину "бизнес процессы" предприятия - вопрос один кто его пишет и что лично ему выгодно...( Простите за уныние , но таковы реалии). А выгоды наверно нужно показывать (на форуме советовали, и правильно) - но не втолковывать же каждому про себестоимость изделия в целом, про оперативность прохождения изменений...???? Кстати себестоимость в российских реалиях вещь очень эфимерная, порой главное Я ХОЧУ.