PDM для электронщиков

[Странник 6]

Согласен, но как быть с ГОСТ?

Делают они потихоньку и ГОСТ-овские настройки, особенно это касается CATIA.

Естественно своим постановщикам/программистам делов тоже хватит с избытком.

Я в курсе. Имел опыт внедрения и пару лет работал с Search, но тогда у них не было связи с ECAD (то, что нужно сейчас). Вот бы узнать, как оно там...

Пару лет проработали и отправили в топку или сами сменили место работы?

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

Все ECAD-овские файлы придётся привязывать к элементам структуры изделия от соответствующих MCAD компонентов (как правило плат), а что это за труд такой - получить ЭСИ в Search представляете стало быть и без дополнительных коментариев.

[VladS 0]

Однако интересно, откуда же это существо будет брать своё ТЗ, с бумажки или ему на пальцах покажут?

Ага, наступило всеобщее благолепие, везде внедрен электронный документооборот и подписанные ТЗ на бумаге больше не выпускают. Особенно при работе с изделиями ВП МО.

Настоятельно посоветовал бы именно кого ни будь из тяжеловесов (кроме NX)

[Удалено по просьбе Доброго модератора ART]

Teamcenter - одна из лучших систем на рынке, и если и уступает конкурентам в чем-то, то в чем-то и опережает их. И у Windchill, и у Enovia есть свои слабые и сильные стороны, которые по-разному проявляются в разных условиях. Утверждать обратное может только либо полностью некомпетентный, либо материально заинтересованный в продаже конкретной системы человек.

То же самое относится и к отечественным разработкам.

Сейчас практически все лидирующие системы примерно равны по функционалу. И выбор зависит иной раз больше от условий контракта и имеющейся команды внедренцев, чем от используемого ПО (и не только MCAD и ECAD) . В мире и в России есть множество примеров, когда Windchill успешно используется с Catia, Teamcenter - с Pro/E и т.п.

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

Для vian

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

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

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

Изменено 1 июня 2009 пользователем VladS

[Странник 6]

Ага, наступило всеобщее благолепие, везде внедрен электронный документооборот и подписанные ТЗ на бумаге больше не выпускают. Особенно при работе с изделиями ВП МО.

Вырезано

Придётся таки пояснить, ведь тут ходит полным полно новичков.

Итак, первичную компоновку изделия народ будет делать таки в MCAD, в том числе и определит объёмы под аппаратуру. И даже не важно на какой именно элементной базе эта аппаратура будет, а важны тип и положение разъёмов, посадочные места, направление действия и номинал доминантной силы, внешние тепловые поля, вибрации, источники электромагнитного излучения, номинал бортового питающего напряжения и т.п. Потроха самой АЭ тоже нужно разрабатывать в MCAD, собственно платы, радиаторы, скобы, втулки и т.д, особенно важно иметь библиотечные 3D модели самих радиоэлементов, дабы красивое на плоскости вдруг не оказалось безнадёжно торчащим за обводы.

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

Таким образом, каждый радиоэлементик должен занять своё место в виде точной модельки MCAD, а ECAD-овские вещи идут как дополнительное приложение.

Соответственно и в PDM, глупо строить особую систему под промежуточное ПО, тем более что оно само виснет на базовом.

Изменено 1 июня 2009 пользователем ART

[sceptic 0]

sceptic

Я вижу, Вы юзаете Allegro? Как у Вас связаны проекты печатных плат с PDM? Предлагаемая Вами TechnologiCS имеет с ней интеграцию?

PDM у нас как раз самопальная, как советует brigval, но я уже убедился, что эффективнее использовать готовую систему (конечно, процесс внедрения сильно зависит от степени ее тяжеловесности). Нам сильно мешает иллюзия того, что мы в состоянии учесть в системе нашу "уникальность". Мы ведь "не как все", ГОСТы нам по барабану и т.д. и т.п. Кстати, в отличие от большинства авторов в этом топике, я могу сказать, что у нас доминируют не конструктора и технологи, и не менагеры, а именно разработчики-электронщики и программисты. И это не есть гут

[sceptic 0]

sceptic

Я вижу, Вы юзаете Allegro? Как у Вас связаны проекты печатных плат с PDM? Предлагаемая Вами TechnologiCS имеет с ней интеграцию?

Да, извините, увлекся и не ответил

Насколько я знаю, TechnologiCS имеет интеграцию с ECAD-системами, с какими именно, ИМХО, не так важно, она активно развивается. Но мы эту систему, к сожалению, так и не приобрели. А внедрение готовой системы (даже такой, как 1С-PDM, есть в данном разделе ее обсуждение) очень дисциплинирует.

А в нашей системе файлы проектов плат просто помещаются в структуру документации соответствующего объекта-изделия.

[VladS 0]

Вырезано

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

Еще один момент по выбору PDM для разработки РЭА: очень желательно, чтобы она имела средства просмотра файлов ECAD (будет полезно, если задумаетесь об утверждении документов через workflow, да и просто удобно). Из отечественных систем такой модуль точно есть для Lotsia PDM (AutoVue), но и к другим системам что-либо подобное прикрутить можно.

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

Тут многое зависит от специфики предприятия. Если готовое изделие включает и электронику (электрику) и механику - это одно дело. И тут конструктора механики действительно могут быть ведущими. А если речь идет о разработке изделий микроэлектроники, то там ситуация может быть ровно обратная (мне приходилось участвовать в разработке изделия, когда на одного механика приходилось от 5 до 10 электронщиков; понятно, кто там доминировал). Изменено 1 июня 2009 пользователем ART

[brigval 690]

Насколько я знаю, TechnologiCS имеет интеграцию с ECAD-системами, с какими именно, ИМХО, не так важно, она активно развивается.

На данный момент, TechnologiCS не умеет автоматом брать данные из программ конструкторов, и тем более, из программ электронщиков.

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

На мое предложение рассмотреть возможность брать автоматом данные из системы БрагинДок (которая может предоставить все данные из спецификцуий в структурированном виде, все докуметнты, технологические файлы и файлы ПО) разработчик ответил непониманием проблемы. Автоматическое заполнение базы TechnologiCS для него пока не важно.

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

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

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

А "потрохи" надо документировать и процессом проектирования PDM надо, в общем-то, управлять, конечно.

Нам сильно мешает иллюзия того, что мы в состоянии учесть в системе нашу "уникальность"

Уважаемый, sceptic, согласитесь, что если мы не можем сформулировать исключения в своей системе бумажного оборота, что же тогда говорить о посторонних программистах. Они тоже не смогут их запрограммировать. У них, кстати, есть одна классическая отговорка "отсутствие исключений в ТЗ" :)

[VladS 0]

Для brigval

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

Согласен, но она-то как правило худо-бедно документирована. Да и система уже должна хотя бы у кого-то работать.

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

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

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

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

Ничего не хочу сказать плохого о T-FLEX, но если люди по доброй воле купили PSS, то они сами виноваты. Может быть, с Интермехом им повезет больше.

А "потрохи" надо документировать и процессом проектирования PDM надо, в общем-то, управлять, конечно.

Совершенно согласен с Вами, но кто ж это делает?

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

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

(OFF: альтернативная идея по поводу продвижения Вашей разработки. А Вы не думали о том, чтобы своими силами "поженить" ее с какой-либо из PDM систем, у которой есть открытое API? И тогда уже готовую интеграцию предложить на продажу. Может очень неплохо пойти, как мне кажется.)

Изменено 26 мая 2009 пользователем VladS

[Елена 116]

На данный момент, TechnologiCS не умеет автоматом брать данные из программ конструкторов, и тем более, из программ электронщиков.

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

Я не думаю, что Altum, DS или Simens будут информировать TechnologiCS. Это нужно иметь ввиду, считая на что вам хватит и чем можно пренебречь

[vian 2]

Господа! Не будем ссориться.

По-поводу Search: не вижу в системе никаких древних методов и убогих реализаций. В чем конкретно они проявляются? Вот правильную идеологию вижу.

По-поводу TechnologiCS: я так понял, система рассчитана на машиностроение и серийное производство. У нас же, в основном, опытно-конструкторские работы. Не подходит. Или я неправ?

Отдельно вижу у них есть TDMS, может, она лучше подойдет (пока подробно не смотрел)?

По-поводу Lotsia: модуль AutoVue доступен для нее? По сайту можно понять, что он только для Lotsia PLM, что больше и дороже...

Начинают складываться предпочтения.

Думаю, лучше всего подойдут Lotsia и Search. Если их сравинить? Что скажете?

[brigval 690]

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

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

Придется всю жизнь и догонять. А как иначе?

[sceptic 0]

Отдельно вижу у них есть TDMS, может, она лучше подойдет (пока подробно не смотрел)?

TDMS это голая система документооборота. Она входит составной частью в TechnologiCS.

Но это так, к слову. Я не уговариваю, решать вам.

to brigval

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

1-Является иллюзией то, что хорошие разработчики РЭА так же хорошо смогут разработать эффективную PDM-систему.

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

[brigval 690]

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

Речь об особеноостях каждого конкретного предприятия. Некоторые из них можно называть "бзиками".

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

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

И т.д. и т.п.

2-Любая "готовая" (т.е. релиз, протестированная, где-то обкатанная) PDM-система дает возможность работать более эффективно, чем без нее.

Согласен, при условии, что эта система успешно внедрена и решает основные задачи. А много таких систем? По отзывам все ОК. А начинаешь вникать и видишь, что до ОК еще ох как далеко.

[Елена 116]

Смотря какие данные брать. Состав как-правило в таблицах. Весь вопрос в цене и окупаемости. Обновляем CADы, к PDM,

а проданный товар должен все это как-минимум должен компенсировать.

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

[Странник 6]

По-поводу Search: не вижу в системе никаких древних методов и убогих реализаций. В чем конкретно они проявляются? Вот правильную идеологию вижу.

С 2004 или даже 2003 года Search практически не приблизился к уровню PDM системы для проектно-конструкторских работ, прежде всего это касаемо упоминавшихся выше версионности и методики погружения моделей в систему. По поводу же пользовательского интерфейса этой системы волками воют и сами айтишники. Особо стоит отметить также иерархическую структуру Imbase и общий уровень надёжности интермеховской продукции, в том числе при установке и обновлении версий системы.

Кстати, если люди из Минска скажут, что ни кто им про это не говорил, то не верьте - говорили и на экране пальцем показывали ещё лет 5 тому назад.

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

Add-Inn к ECAD в Seach-e конечно же нету, как и возможности хранения общей библиотеки проектирования SolidWorks.

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

Вырезано

Изменено 1 июня 2009 пользователем ART

[brigval 690]

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

Вообще-то я поспешил.

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

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

А может и нет

Но исключение из общего правила - налицо.

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

[VladS 0]

По-поводу Lotsia: модуль AutoVue доступен для нее? По сайту можно понять, что он только для Lotsia PLM, что больше и дороже...

Да, <noindex>доступен</noindex> (Lotsia PDM PLUS имеет то же самое ядро, что и Lotsia PLM, и AutoVue в нее встраивается).

Думаю, лучше всего подойдут Lotsia и Search. Если их сравинить? Что скажете?

Их довольно сложно сравнить. Это слишком разные по идеологии системы.

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

Lotsia PDM не имеет явной привязки к одной САПР, она изначально создавалась для интеграции с разными системами.

Lotsia очень гибкая в настройке, за счет чего успешно используется в разных отраслях (в частности, широко используется в приборостроении); есть бесплатные готовые шаблоны отраслевых решений. Она имеет мощные средства экспорта/импорта данных, аналитики, бизнес-логики и управления конфигурациями, очень мощный движок workflow (правда, если процессов запущено много, он жрет полно памяти, но это обещают исправить в ближайшее время).

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

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

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

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

Так что, ПМСМ, все же стоит определиться с требованиями, и уже с их учетом внимательно посмотреть на системы. На чужие мнения полностью полагаться опасно.

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

Вырезано

Изменено 1 июня 2009 пользователем ART

[vian 2]

Спасибо всем за советы.

Я в курсе, что Search потребует дополнительного программирования, особенно, в нашем случае.

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

С другой стороны несколько человек говорят, что ничего не изменилось, Search так и остался "машиностроительным".

Что ж, будем думать.

Так что, ПМСМ, все же стоит определиться с требованиями, и уже с их учетом внимательно посмотреть на системы. На чужие мнения полностью полагаться опасно.

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

[VladS 0]

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

Извините, но того, что Вы указали в первом посте, не совсем достаточно.

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

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

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

Что же касается Search, то у него много поклонников, так что, наверное, не все так плохо и для ряда организаций эта система вполне подходит.

И не только Search требует дополнительного программирования при тонкой настройке. Скорее, дело в объемах этого программирования.

Изменено 1 июня 2009 пользователем VladS

[vian 2]

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

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

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

Тем не менее, спасибо еще раз. Пока не закрываем тему.