Спецификации

[suslad 1]

Задача программиста, автоматизирующего работу конструктора, - сократить срок выдачи КД конструктором с одновременным уменьшением количества ошибок

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

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

Одна из целей внедрения PLM-систем -- это так называемая "база знаний", которая накапливается как раз таки при внесении изменений в существующее КД. Именно этими знаниями так дорожат буржуйские производители. А мы -- хех, не по ГОСТу, и все тут!!! Зачем нам какая-то история изменений! Мы, главное, должны бумажку в архив сдать, желательно побольше бумажек в эквиваленте А4, чтоб видна была работа!

[Route 2]

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

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

Задача конструктора - в поставленные сроки выдать комплект КД в том виде, в котором от него требуют.

Задача программиста, автоматизирующего работу конструктора, - сократить срок выдачи КД конструктором с одновременным уменьшением количества ошибок. В том числе и при выпуске спецификаций.

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

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

За последние 10-15 лет относительно спокойной жизни предприятий (финансовой), произошло такое ускорение выдачи КД конструктором с "одновременным уменьшением количества ошибок", что количество ИИ проводимых на предприятиях использующих системы "автоматизирующие работу конструктора" возросло в десятки а иногда и в сотни раз. Вопрос, почему так?

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

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

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

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

[brigval 690]

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

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

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

Зачем нам какая-то история изменений!

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

Именно этими знаниями так дорожат буржуйские производители

Откуда такая информация? Не из рекламы часом?

Мы, главное, должны бумажку в архив сдать, желательно побольше бумажек в эквиваленте А4, чтоб видна была работа!

Если Вы это серъезно, то какая задача у программистов, автоматизирующих рутинную работу конструкторов? Настрочить тучу кода со всеми историями изменений, получить гонорар и тут же забыть про свои программы. А внедрять кто будет? Дядя? :)

[Route 2]

Спецификация - основной конструкторский документ, при бумажном документообороте.

А что с ней случается, при переходе на электронный?

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

В голову приходит лишь одно решение: обозвать Электронным-Документом-Спецификация какой-нибудь тип файла, например, в PDF, или, лучше, свой формат, и прикреплять его к наращиваемой базе ЭСИ...

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

А то у нас в этом вопросе сплошной :wallbash:

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

Если захотите прикрепить спецификацию как файл к структуре изделия, то тогда при ИИ нужно будет изменять и прикрепленную спецификацию. Но я лично считаю что пока у Вас все по ГОСТ, бумажной спецификации распечатанной со структуры изделия, подписанной и хранящейся в архиве будет хавать всем кому она понадобится.

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

[Странник 6]

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

В самом деле их будет не менее 2:

-конструкторская;

-технологическая.

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

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

Правда база знаний это таки нечто иное:

-стандартизованный и покупной хлам;

-конструкционные материалы;

-UDF;

-библиотечные детали;

-библиотечные сборки;

-автокомпоненты;

-"глупые" и "вумные" шаблоны;

-типовые техпроцессы;

-...

В общем всё то, что так или иначе формально описывается на этом предприятии средствами MCAD, ECAD, Microsoft Office и т.д.

[Route 2]

В самом деле их будет не менее 2:

-конструкторская;

-технологическая.

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

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

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

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

Естественно, зачем технологу конструкторские изменения? Пусть так и штампует технологию такой какая она есть. А потом всеми любимый "разбор полетов" .

Потом спрашивают друг у друга: Как это у нас получается? Моделька-3D - красота, а на выходе из цеха - жалкая пародия .

Правда база знаний это таки нечто иное:

-стандартизованный и покупной хлам;

-конструкционные материалы;

-UDF;

-библиотечные детали;

-библиотечные сборки;

-автокомпоненты;

-"глупые" и "вумные" шаблоны;

-типовые техпроцессы;

-...

В общем всё то, что так или иначе формально описывается на этом предприятии средствами MCAD, ECAD, Microsoft Office и т.д.

База знаний это по Вашему справочники?

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

[Странник 6]

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

Способ классический: договор (приказ по предприятию) - извещения (ИИ) - предварительные извещения (ПИ) - карточки отступлений (КО) - "разбор полётов".

Например.

Приказ №102

Четвёртому производству изготовить 10000 изделий АБВГ.000 Косилка

Срок 15.05.2010

расчётный счёт 233-322-233-322

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

Вы всёже отделяйте мух от котлет, ибо есть ОГТ и есть цеховые техбюро.

ОГТ-шники (и даже экономисты ) очень даже запросто могут входить в состав конструкторских комплексных бригад разработки и поддержки хотя бы того же изделия АБВГ.000.

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

Цеховые же технологи уже окончательно разложат всё по полочкам конкретных цехов... ну и с ОГТ-шниками перегрызутся тоже.

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

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

С 3 раз угадаете как их зовут?

Естественно, зачем технологу конструкторские изменения? Пусть так и штампует технологию такой какая она есть. А потом всеми любимый "разбор полетов" .

Потом спрашивают друг у друга: Как это у нас получается? Моделька-3D - красота, а на выходе из цеха - жалкая пародия .

Ещё раз.

Существуют понятия ИИ, ПИ, КО, а так же журнал отработки. Так же существуют конструкторский чертёж, ТУ (всё в электронном виде) и ОТК. Внёс изменения - утверди их по соответствующей процедуре Workflow, в итоге все заинтересованные лица автоматически получат нужную им информацию. Какие тут технические проблемы то, кроме слабой адаптации CAD под ЕСКД и отсутствия в PDM встроенных трансляторов?

Вот административных проблем - море.

База знаний это по Вашему справочники?

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

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

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

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

[Route 2]

Способ классический: договор (приказ по предприятию) - извещения (ИИ) - предварительные извещения (ПИ) - карточки отступлений (КО) - "разбор полётов".

Например.

Сколько сдесь этапов соглдасования?

Вы всёже отделяйте мух от котлет, ибо есть ОГТ и есть цеховые техбюро.

ОГТ-шники (и даже экономисты ) очень даже запросто могут входить в состав конструкторских комплексных бригад разработки и поддержки хотя бы того же изделия АБВГ.000.

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

Цеховые же технологи уже окончательно разложат всё по полочкам конкретных цехов... ну и с ОГТ-шниками перегрызутся тоже.

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

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

С 3 раз угадаете как их зовут?

А здесь сколько этапов согласования?

Ещё раз.

Существуют понятия ИИ, ПИ, КО, а так же журнал отработки. Так же существуют конструкторский чертёж, ТУ (всё в электронном виде) и ОТК. Внёс изменения - утверди их по соответствующей процедуре Workflow, в итоге все заинтересованные лица автоматически получат нужную им информацию. Какие тут технические проблемы то, кроме слабой адаптации CAD под ЕСКД и отсутствия в PDM встроенных трансляторов?

Вот административных проблем - море.

Да, у Вас цепочка согласований не слабая, а сколько итераций? Workflow не помагает? В понедельник начинаете согласовывать в пятницу начинаете новую итерацию? Тяжко?

А все по тому что внедряя PDM, Вы исключили саму возможность снизить количество итераций согласования занявшись лоскутной автоматизацией. У вас исключено само понятие "ИЗДЕЛИЕ" у вас есть только понятие "документы" (электронные, бумажные, тут уже не важно). Соответственно, ни кто в Вашей конторе не может увидить совокупную информацию по изделию. Т.е. спецификаций то у вас две, а замкнуть вы их на "изделии" не можете, актуальность то то по одной спецификации то по другой теряется.

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

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

Ну уж извините, конечно и справочники - 10 % от базы знаний.

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

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

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

Вот только не надо обижать. Я в Ваших спорах с манагерами не учавствую. При чем тут фискальный чек?

По поводу базы знаний сейчас объсню доступно:

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

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

Изменено 28 марта 2009 пользователем Route

[Странник 6]

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

Итак, этап согласования это:

-подпись либо виза одного лица;

-согласование с одной инстанцией (ОГТ, ВПЗ);

-прохождение эпата ЖЦИ (например НИР-а);

-нечто иное?

По поводу базы знаний сейчас объсню доступно:

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

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

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

[Route 2]

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

Объясните свое высказывание: "Вы думаете лишь о жалком, хотя и необходимом, фискальном чеке, но с ним одним далёко не уедешь"

Это то на мои слова: "Думаю что база знаний это история развития любого изделия. А также возможность просмотра истории издедлия в разрезе любого из параметров PDM-системы (изменений, качество комплектующих, история изменения технологии в привязке к составу изделия, изменения качества изделия в разрезе еще каких либо параметров и т.п.). Вот тогда эта база знаний и пригодится новому поколению, а не справочники с кучкой устаревших элементов."

Итак, этап согласования это:

-подпись либо виза одного лица;

-согласование с одной инстанцией (ОГТ, ВПЗ);

-прохождение эпата ЖЦИ (например НИР-а);

-нечто иное?

В том числе и это. Ну не выдержки же из стандартов сюда копировать, ГОСТы я читать умею.

Для меня важнее уменьшить на этапе проектиролвание количество итераций на всех этапах согласования, иначе Workflow не поможет.

СОГЛАСОВАНИЕ — достижение предварительной договоренности, общего согласия между группой заинтересованных и ответственных лиц по поводу выпуска документа определенного содержания, протокола, договора, принятия общего решения, осуществления общей сделки, проведения совместных действий.

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

Странный вопрос, поподробней можно объснить?

По поводу базы знаний, к примеру:

Конструктор разработал модель изделия. Технолог - технологию. Все данные во время ЖЦ изделия (не только конструкторско-технологические) завязываются на составе изделия. В любой момент я могу получить информацию как по конструкции изделия, так и по технологии его изготовления. А при создании ревизии на изделие (Revision - модификация любых данных об изделии) можно учесть и рекламации по изделию, которые в свою очередь тоже можно получить по составу в практически в режиме online.

[Странник 6]

Объясните свое высказывание: "Вы думаете лишь о жалком, хотя и необходимом, фискальном чеке, но с ним одним далёко не уедешь"

Это то на мои слова: "Думаю что база знаний это история развития любого изделия. А также возможность просмотра истории издедлия в разрезе любого из параметров PDM-системы (изменений, качество комплектующих, история изменения технологии в привязке к составу изделия, изменения качества изделия в разрезе еще каких либо параметров и т.п.). Вот тогда эта база знаний и пригодится новому поколению, а не справочники с кучкой устаревших элементов."

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

Почему именно такие приоритеты?

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

В том числе и это. Ну не выдержки же из стандартов сюда копировать, ГОСТы я читать умею.

Для меня важнее уменьшить на этапе проектиролвание количество итераций на всех этапах согласования, иначе Workflow не поможет.

СОГЛАСОВАНИЕ — достижение предварительной договоренности, общего согласия между группой заинтересованных и ответственных лиц по поводу выпуска документа определенного содержания, протокола, договора, принятия общего решения, осуществления общей сделки, проведения совместных действий.

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

Ну а без этого все известные мне Workflow просто трещат по швам, вне зависимости от наличия или отсутствия в них ролевого функционала.

Странный вопрос, поподробней можно объснить?

Если у нас на изделии КЕНГ.000 появилась какая ни будь непонятная вибрация, а CAE-шники только руками разводят, то право же полезно было бы посмотреть статистику прочих изделий и найти в них все идентичные моменты, как то:

-фамилии разработчиков;

-номера патентов;

-смежные организации;

-номера цехов;

-карточки отступлений

-....

Собственно это и есть та самая фискальная функция, только работать эффективно она начнёт лет через 10 или даже более.

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

1. на такую конструктивную схему имеется 2 докторских, 5 кандидатских, 36 заявок и 271 рацпредложение, со включением высших менегеров в соавторы;

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

Сможете тут что ни будь противопоставить "вектору инерции мышления" не обладая бОльшею властью?

По поводу базы знаний, к примеру:

Конструктор разработал модель изделия. Технолог - технологию. Все данные во время ЖЦ изделия (не только конструкторско-технологические) завязываются на составе изделия. В любой момент я могу получить информацию как по конструкции изделия, так и по технологии его изготовления. А при создании ревизии на изделие (Revision - модификация любых данных об изделии) можно учесть и рекламации по изделию, которые в свою очередь тоже можно получить по составу в практически в режиме online.

Вашими бы устами, да мёд пить.

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