HryuckinnenОтвечаю на исходный вопрос:
автор
Не расскажите, какие нынче PDM системы в моде, какова их специфика, функциональность и возможности к интеграции с другими системами?

1. В моде та, за которую откат дают больше. На самом деле рынок PDM не так раскручен, как рынок бухгалтерских или учетных систем, видимо, из-за сложности предмета (булгахтерию автоматизировать проще). Игроков здесь раза в три побольше, и бардака больше во столько же раз. Явных лидеров типа 1С нету.

2. Основная специфика PDM-системы заключается в том, что вы должны очень четко представлять себе, какие именно информационные процессы вы хотите с её помощью автоматизировать. Если, например, с бухгалтерией и складом всё более или менее ясно, то процессы конструкторского проектирования и жизненные циклы технической документации (информации об изделиях) плохо представляют себе даже сами конструкторы. Еще имеет смысл предпринять все усилия, чтобы на предприятии не осталось кульманов (во всяком случае, у конструкторов, разрабатывающих документацию, которая идет в производство), и чтобы все конструкторы работали в одном и том же САПРе. Иначе средства, потраченные на приобретение PDM-системы и гонорары внедренцам, будут, мягко говоря, выкинуты псу под хвост.

3. Функциональность большинства PDM-систем - это
а) обеспечение совместной работы нескольких конструкторов над одним и тем же проектом (данные из САПРа не лежат в виде файликов на сетевых дисках, а укладываются в базу данных; теоретически, при этом должно быть меньше бардака);
б) хранение деревьев состава изделий, обычно с поддержкой "конфигураций" или "исполнений" (это когда две однотипных машины могут иметь разный состав) и с возможностью присоединения к различным узлам дерева произвольной информации (хотя и то, и другое может отсутствовать);
в) генерация различных отчетов (хотя бывает, что в системе изначально нет ни отчетов, ни конструктора отчетов, а надо садиться и кодить);
г) как правило, модуль workflow/docflow (опять же не обязательно).

4. Возможность интеграции с другими системами - обычно есть интеграция с системами того же производителя, и очень хорошая. Со всеми остальными - придется дорабатывать напильником. Структуры данных различных PDM-систем не обязательно документированы, программный интерфейс не обязательно присутствует. Но наличие девайса "напильник" и драйверов "руки.sys" и "мозги.drv" позволяет интегрировать PDM-систему с чем угодно.

Наличие встроенной платформы для разработки (типа как у 1С или Акцапты) - большая редкость (если вообще есть). Максимум, что видел - это набор библиотек на Жабе и плагин для Rational Rose.

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

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

Про процессы: в целом, ситуация не безнадежная. Даже если конструктора не представляют, то совместно с аналитиками что-то все равно придумывается. Корень этой проблемы в том, что в бывшем союзе выпало целое поколение автоматизации и, зачастую, ты приезжаешь внедрять PDM там, где месяц назат твои же коллеги закончили обучать автокаду. Переход с бумажных технологий происходит рывком через несколько ступенек - это рождает много проблем и хаотичность процессов - не самое страшное. Еще есть проблема "зоопарка", когда пиратский софт стоит по 100 рублей за диск - это приводит к тому, что в опрганизации есть 5 кадовских платформ, накоплены массивы электронных документов. Но ни полностью купить какую-то одну из тех платформ, к которым они привыкли (дорого) ни перевести все документы в один выбранный формат (без потерь) уже невозможно. Обычно на это накладывается проблема отсутствия единых информационных шаблонов. После нескольких лет работы в режиме такой стихино-пратской автоматизации организация получает полученную прибыль и нулевой архив документации, из которого можно было бы заимствовать решения, удешевляя разработку. Вот тогда они и приходят с вопросом о PDM.

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

Про встроенные платформы разработки и допил.
Teamcenter позволяет втыкаться на яве с любыми наворотами - только очень уж это геморройно, дизайнер типов документов, связей, карточек, атрибутов, выборок и т.д..
Search имеет открытый COM API
T-Flex - API + внутренние макросы
TDMS настраивается с участием программирования на VBS, подключением dll и писанием ActiveX, дизайнер типов объектов, атрибутов, форм, выборок и т.д.

Это то, что я трогал руками.

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

GaryaВсё остальное оставлю без комментариев... Отвечу только вот на это:
BoatmanУ меня нет собственного производства. Но если бы было, то пистон получили бы те, кто заказал оборудование без защиты от дурака и те, кто обучал и допускал рабочего к работе, если он зашел на чужое рабочее место, то те, кто отвечает за разграничение доступа. И так далее в том же духе для того, чтобы смотреть в корень проблемы не обязательно приводиьть по дватцать аббревиатур на трир предложения. А вообще сказал бы спасибо, что никому не оторвало руку или голову...RCA изначально исходит из того, что пистон не должен получать НИКТО . По утверждению Деминга 98% проблем возникают по вине системы , а не сотрудников. RCA находит коренные причины в самой системе, а не занимается поиском "стрелочников".

Ну всё, пойду покурю... В смысле, поучусь курить (потому как некурящий)... :)
Этот вопрос предлагаю обсудить в другой теме

Создал тему