Достоинства и недостатки PDM

[inord 0]

Господа, да что ж вы все TeamCenter пинаете, можно подумать вам о нем все известно

[Lazy_PDMer 0]

To monster_lord

Приятно вести спокойный разговор.

насколько я знаю, в настоящее время Team Center - пока лишь декларация возможностей.. хотя может быть это уже и не так...)))

На самом деле, не совсем так. Все-таки наработки, сделанные в Метафейс были очень серьезными.

Главное - команда предприятия, которая будет заниматься внедрением.. и поддержка на самом высоком уровне.. (уровень хозяина)..

Золотые слова! Но в этом и лежит основная проблема при внедрении (в недостаточной поддержке хозяином, -- считается, что систему купили, чего же вам еще? Работайте!). А продавцы довольно часто опускают этот момент когда нахваливают свои системы.

Увы.. в настоящее время.. мало кто хочет прозрачности... информации..

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

По поводу внедрения.. Извините, но в настоящее время я не видел ни одного полномасштабного внедрения серьезной PLM ни на одном предприятии..

Я тоже.

Причем, причины, на мой взгляд, банальные:

1. Цена решения для предприятия хотя бы на 100 рабочих мест очень высока (сеть + компьютеры + ПО + обучение + внедрение + сопровождение). Ну не готово большинство предприятий заплатить сразу 300-600 тысяч у.е., когда результат далеко не очевиден (наше -- точно не готово ).

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

3. Каждая служба тянет одеяло на себя. В результате вместо внедрения системой занимаются "политИком".

4. Существует два страшных мифа: а) "деньги заплатили, оно теперь заработает само", б) "у нас есть свои программисты, они за ту же зарплату в свободное от основной работы время внедрят любую систему (или разработают свою)".

5. Ну и опять, нет заинтересованности руководства --> хороним систему.

хотя описать ТП можно и средствами PDM (в Windchill я это делал).

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

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

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

А с ERP класса SAP R/3, BAAN, Oracle Manufacturing существуют стандартные (форменные) решения.. Хотя как они работают увы.. я не знаю..

Могу сказать только за пару систем, с которыми приходилось сталкиваться: R/3 и BAAN -- очень много зависит от конкретной настройки, которая была сделана при внедерении этих систем на предприятии. Счастья там нет...

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

Тогда получается, что нужна. Поскольку и аналитика нужна всегда, и интерфейсы тоже нужны.

Да даже тривиальный случай: практически всем нужна спецификация. А если уперлась "пятая приемка", то заставляют делать по ЕСКД. А собрать спецификацию с точным соблюдением требований ЕСКД, например, для изделий приборостроения -- то еще развлечение.

To inord

Если Ваше обращение относится и ко мне, то смею уверить, что продукцию EDS PLM Solutions я очень даже уважаю. И рассматриваю Team Center именно как одного из лидеров рынка. Моя ирония относилась к выводу об оптимальности Windchill. На самом деле, не все здесь однозначно, и явных лидеров нет. Каждая система имеет преимущества и слабые места.

[Гость monster_lord]

Lazy_PDMer

хм.. А действительно приятно спокойно пообщаться.

Да, я полностью согласен с Вами по многим Вашим замечениями.

По идее, синтегрировать "доморощенные системы с PDM" можно и не так уж и сложно. Однако, по своему опыту могу сказать, что не видел еще ни на одном предприятии АСУ, которая писалась бы на основе нормального полноценного системного проекта. Может где и есть такое, но я пока не встречал.

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

По поводу SAP и BAAN, то тоже полность согласен. Более того, при интеграции PDM с ERP естественно придется принимать во внимание сделанные в них настройки.

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

Более того, я бы точно не рекомендовал покупать сразу 100 мест. Поскольку перед внедрением системы на уровень 100 мест, необходимо провести достаточно много как организационных, так и технических мероприятий по подготовке внедрения (настройка структуры представлений данных по центрам ответственности, настройка workflow, жизненных циклов, разработка регламенов выполнения работ в соответствии с перепроектированными под внедрение PDM бизнес процессами жизненного цикла и т.д. и т.п.) Поэтому, я считаю оптимальным на первом этапе 5-10 мест. Зачем платить за неиспользованные возможности?

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

С пп. 2-5 согласен. Зачастую так оно и есть, причем чаще всего, главный враг - АСУП, который видит во внедрении PDM ущемление своих интересов. А так на самом деле и есть.. Кроме этого, часто противниками выступают также руководители (причем на уровне главных специалистов и начальнико отделов), которые за непрозрачностью скрывают свои "пенки" или просто "ловят рыбку в мутной воде".

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

[inord 0]

Lazy_PDMer

Ну если с уважением,

monster_lord

остались ли сомнения в возможностях TeamCenter после замечания Lazy_PDMer'a ? Остались - развеем

[Гость monster_lord]

inord

Ну что я могу сказать??? Увы, я не имел возможности поработать (практически и плотно) с TeamCenter.. Поэтому ничего плохого про данную систему сказать не могу.. Каждый из нас, насколько я понимаю, рассказывает о той системе, которую знает.. Я знаю Windchill..))) Если вы имеете реальный практический опыт (любой.. удачный или неудачный) внедрения TeamCenter, буду рад услышать о ее преимуществах.. ну и недостатках.. поскольку, насколько я понимаю, пока в мире нет реальной PDM системы без недостатков.. особенно такого уровня..))))

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

Я рассматриваю PLM/PDM систему, главным как источник аналитической информации для принятия решений высшим руководством..

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

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

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

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

Еще мне Windchill нравится своей гибкостью... Хотя у нее естественно есть и обратная сторона.. Можно построить как идеальный порядок, так и абсолютный хаос...)))))

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

А по поводу TeamCenter. Если честно, то очень бы хотел познакомиться с этой системой поближе.. в более так сказать интимной обстановке..))))

[inord 0]

Отвечаем ....

monster_lord

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

По поводу интимной обстановки ??!!

Ну в общем если без интима - то можно

[Гость monster_lord]

inord

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

А для того, чтобы показать преимущаства внедрения PDM-системы на первом этапе как раз и выполняется описание и "легкое" перепроектирование всей цепочки бизнес-процессов жизненного цикла. И вот тут-то и выявляются "чисто теоретические" преимущаства от внедрения... В основном это преимущества от электронной формы документа, когда процессы можно достаточно эффективно распараллелить... И при этом, даже теоретически получается сокращение времени на достаточно ощутимую величину.. > 30%.. А это уже достаточно существенный козырь...

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

Руководство "высшее" ну очень желает управлять себестоимостью (читай рентабельностью).. Вот только не знает как..))))

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

По поводу "интимности"... ну это значит забраться этой системе под "шкурку")))))

Если поделитесь своим опытом по TeamCenter, буду крайне признателен...

[Гость Гость_Oleg]

Насчёт отсутствия графического редактора workflow в Search. Он появился начиная с версии 7.0 (в этой версии модуль документооборота был полностью переписан). О возможностях можете узнать например здесь <noindex>http://intermech.ru/search.htm</noindex>

[Che 0]

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

[vladmi 0]

На сайте www.belerp.com, ww.vespol-soft.com имеется ряд аналитических статей, посвященных

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

[vladmi 0]

Что касается недостатков PDM, я не понимаю их зациклинность на "маршрутизацию" под которым понимается электронное согласование документации. С точки зрения заводского практика я не вижу особого в этом особого прока. Последне можно решать через обычную электронную почту, мы, на МЗКТ, отказались от Outlook, перешли внутри на Email через фильтры. Это касается как TeamCenter, Windchill, Search. Для заводов гораздо важнее иметь конструкторскийи технологический состав с переменными частями, включая заказные спецификации, маршруты изготовления деталей (расцеховку), матеральные нормативы, параметрику и иметь всю информацию об изделии, чего нет в данных системах. Все это должно относится к PDM и связано с ERP. Тогда можно говорить о CALS. Т.е. должна быть мощная поисковая система с электронным архивом, включая изменения, извещения, предписанния, собираемость, информацию о поставщиках. Необходима единая система, охватывающая функции как PDM так и ERP. Тогда устраняется проблема синхронизации данных т.к. используется единая БД. Что касается "маршрутизации" то вопрос можно решать и по другому, вести БД согласований, идентификаций файлов по контрольному числу, электронных подписей по имени пользователя.

[monster_lord 0]

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

<{POST_SNAPBACK}>

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

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

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

А по поводу соглсования через е-mail - могу сказать, попробуйте параллельно пустить один документ на согласование например 5-6 участникам, а потом попробуйте провести интеграцию всех замечаний в документ и посмотрите, сколько у вас это времени займет и сколько денег вы потратите на таблетки от головной боли.

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

Ничего личного. С надеждой на понимание и уважением.

[dynas 0]

Господа, да что ж вы все TeamCenter пинаете, можно подумать вам о нем все известно

В нашей "конторе" у нас это основная БД , которая отлаженно работает c UG ...

А вот с Catia " особой дружбы" не видно. Потеря связи между Тс Eng и Сatia становится уже системой.

[dynas 0]

Цитата : По поводу внедрения.. Извините, но в настоящее время я не видел ни одного полномасштабного внедрения серьезной PLM ни на одном предприятии..

Не стоит извиняться за то , что вы не видели и не надо говорить о том , что вы не знаете.

[Termik 0]

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

В плане внедрения (настройки) ENOVIA весьма сложна...

[nibulla 0]

Обсуждение этой темы я бы начал с доступной аппаратной базы. В силу присущей человеческой природе "обезьяньего" эффекта внедрение систем часто строится по принципу - вот у них это, значит и мы это возьмем. Особенно приуспевают в этом продавцы различных систем "впаривая" их заказчикам. Например, то что у GM UG это совсем не значит, что свя наша автопромышленность должна на него сесть. Почему - да потому что UG на Work Station (HP, SGI, SUN) это совсем другое, чем на PC (хотя бы из за разрядности процессора). К другим производителям это тоже относится. Так что если мы хотим перенять западный опыт надо присматриваться не к отраслям промышленности, а к фирмам использующим эквивалентное оборудование. И если мы используем платформу WinTel в 99% случаев, то и надо исходить из этого печального факта и не удивляться, что кокой - то PDM у Вас еле щевелится.

[PDM-золотарь 0]

Настало время помыть кости производителям PDM (но только грамотно и корректно, произвола не допустим). Предлагаю обсудить здесь те функциональные возможности которых нехватает современным PDM/PLM системам.

С PDM столкнулся впервые.

Вот предлагают купить PDM (Intermech).

Поставили триальную версию.

Что я вижу на сервере MSSQL?

select count(*) as table_count 

from information_schema.tables t 

where t.table_type = 'BASE TABLE'



table_count 

----------- 

	   4266

select count(*) as fk_count 

from information_schema.table_constraints tc 

where tc.constraint_type = 'FOREIGN KEY'



fk_count	

----------- 

		  0

Для тех, кто не работает с SQL: в базе 4266 таблиц и 0 связей между таблицами. Детский сад. Тут не кости надо промывать, а попку подтирать.

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

Разработчики бодро заявляют про масштабируемость, что, мол, их система с SQL-Server или Oracle "тянет" 250 (!) клиентов. Не знаю, на какой помойке они такой Oracle нашли, не самый свежий Oracle 9i, что стоит на моем стареньком нотебуке (!) тянет 10000 подключений и не вякает.

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

[Che 0]

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

Посмотрите внимательно как там делается разузлование. Думаю долго будете удивляться

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

[slaz 0]

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

Извеняюсь - не разобрался как делать цитирование.

Довольно классическая ситуация, когда первичную оценку "качества" предлагаемой системы на предприятии проводят непосредственно спецы: системщики, конструктора, технологи...

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

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

Вот только когда заглядываешь в базу данных АСУП любого предприятия постсоветского пространства, которая развивалась еще с 60-ых и начинала работать на ЕСках - волосы шевелятся ни чуть не меньше, а делали ее такие же заводские системщики

Конструктор смотрит насколько быстро и удобно эта системка поможет ему оформить чертежик по требованиям ЕСКД - он это делает каждый день, для него это важно!

Технологи мечтают о ворде или екселе для техпроцессов - их можно понять! писать руками такие объемы далеко не сладко!

Вот отсюда и появляются подобные посты...

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

Интересами отдельных специалистов, увы, лучше пожертвовать ради общего блага

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

Если копнуть старые "бивневые" системы, типа TCE и т.п. так в них вообще зарыты функции, написанные еще в далеких 70-ых годах, и ничего, работает же!

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

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

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

Изменено 9 марта 2007 пользователем slaz

[suslad 1]

Довольно классическая ситуация, когда первичную оценку "качества" предлагаемой системы на предприятии проводят непосредственно спецы: системщики, конструктора, технологи...

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

<{POST_SNAPBACK}>

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

Или Вы намекаете что у ИНТЕРМЕХа иной принцип проникновения на предприятия -- через руководящие поста?

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

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

<{POST_SNAPBACK}>

То есть предлагается купить "как есть" с "большой надеждой на будущее"?