Статья "анализ И Сравнение Существующих Pdm"

[SVS 1]

Анализ и сравнение существующих PDM

Авторы: Михайлов В.Г., к.т.н, МЗКТ, САПР

Дата: 13/02/2007

Тема: Обзоры и аналитические материалы

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

Чтобы разобраться в этом вопросе рассмотрим ряд наиболее лучших зарубежных и отечественных систем: Windchill (PTC, США), Teamcenter (EDS, США), Search (Интермех, РБ) и сравним их с разработкой МЗКТ СпрутМ.

Функциональность

По своей функциональности рассматриваемые модули являются больше организационно-распорядительными системами электронного документооборота (СЭД), особенно Windchill. Хотя позиционируются как PDM, они имеют узкую нацеленность на технический документооборот, ведение электронного архива технической документации, перевод в электронную форму процесс взаимодействия участников создания и производства изделий. А СЭД выполняет всего лишь небольшую часть функций PDM. В СНГ данные модули используются в основном автономно вне связи с полным комплектом пакетов одной фирмы. Из-за этого возникает ряд проблем, связанных с их интеграцией в информационную систему предприятия, построенную из различных модулей разных производителей.

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

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

PDM Windchill (4 тыс. $/рабочее место) по своей функциональности в основном нацелен на организационную координацию деятельности различных служб, участвующих в разработке и производстве изделия: субподрядчиков по разработке, заказчиков, субподрядчиков по производству, поставщиков комплектующих, а также внутренних подразделений, таких как инженерная служба, маркетинг, продажи, обслуживание, производство, служба снабжения. Информационной поддержки проектирования, технологической подготовки производства у него нет. Заносимая информации с точки зрения конструкторов и последующей АСУ недостаточна: минимальная информация по ДСЕ (деталь-сборочная единица) и составу в приделах 2-х десятков полей. Во многом это типичная система электронного документооборота. Из-за этих недостатков он слабо подходит на роль первичного звена CALS. Стоимость модуля сопряжения Windchill с BAAN порядка 250 тыс. $.

БелАЗ промучавшись 7 лет с его внедрением, отказался от закупленных Windchill, BAAN, предпочтя ему Search и старую заводскую систему на Сlipper при их разрозненном использовании. Камнем преткновения явилась проблема синхронизации данных в разных системах построенных по разной бизнес-логике, слишком большой объем вносимой и меняемой информации из-за наличия разных систем, проблема с высококвалифицированными кадрами и разочарование в функционале Windchill и BAAN. Выбор Search был обусловлен, в первую очередь, более низкой ценой и потребностью технологов в модуле Техкард для формирования технологических карт и отсутствием на рынке полноценной PDM. Последний без Search работать не может.

Search является типичной системой электронного документооборота с большей ориентацией и поддержкой Автокада (в других модулях). В версии 9 добавлена поддержка UG, ProE, ведение заказных спецификаций и замен, значительно изменен его интерфейс. Предусмотрено варьирование составом, как на уровне головной сборки, так и внутреннем. Данный пакет лучше вышеперечисленных зарубежных настроен на отечественную систему бумажной конструкторско-технологической документации и документооборот. Обеспечивает формирования и распечатку бумажных документов спецификаций на основе информации баз данных, ведение электронного архива чертежей, согласование. Однако заносимая информация Search все же минимальна: только то, что содержится в штампе чертежа, спецификации и извещении и связанная с заменами и вариациями сборок. Организация электронного архива не в полной мере отвечает современным потребностям производства: файлы сбрасываются в папки, они не кодируются в БД, потом сложно с ними разбираться (различать). ERP функций у него практически нет. Например, отсутствует функция применяемости. И все это из-за ссылочного механизма ведения состава, не позволяющего вести сортировки. Построить полноценную систему CALS при использовании Search в качестве первичного звена сложно, возникает много проблем по интеграции. Сфера применения Search - проектные организации в основном конструкторско-технологического профиля, которым нет необходимости в CALS. Следует отметить, что Search от версии к версии заметно прогрессирует и по своим возможностям во многом уже превзошел TeamCenter. Подводит его наличие ошибок в программном обеспечении.

TeamCenter (TCE) позиционируется как PDM система, призванная обеспечить информацией последующие модули EDS, охватывающие подготовку производства и АСУ. Но в СНГ эти модули практически не используются и дать им оценку не представляется возможным. Его PDM также слабо годится на роль первичного звена.

Подходы и способы реализации

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

Преимущества и недостатки

Каждый пакет имеет свои преимущества и недостатки. Функциональность TeamCenter и Windchill в стандартном варианте явно недостаточна. Для применения под отечественную систему документации необходима доработка. Процесс настройки связей для описания объектов в TCE довольно сложен и по опыту ряда организаций (МАЗ, ОКБ Сухого) требуется порядка 3-5 лет. А на занесение полной информации на заводах может уйти до 8-10 лет. Необходимо написание своих программ на Java. Многие организации не в состоянии эти пакеты самостоятельно даже развернуть, не говоря об их модификации. TeamCenter (доработанный отечественными фирмами) несколько лучше чем Windchill адаптирован под производственную сферу в привычном АСУшном понимании. У Windchill уклон сделан на взаимодействие участников и согласование. Windchill слабее с точки зрения обеспечения привычной информацией конструкторов, технологов и АСУ. Работы по созданию надстройки к Windchill из-за слабого его применения в СНГ не ведутся и непонятны причины, по которому его собираются сделать основным в объединенной авиастроительной корпорации России. Единственным объяснением может быть необходимость в обмене данными при кооперации с западными разработчиками.

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

Механизм ведения заказных спецификаций реализован в TeamCenter за счет дополнительной программной настройки, сделанной в СНГ. В стандартном варианте его нет. У Windchill ведение заказных спецификаций, ERP функций не реализовано. Хотя в принципе возможна его некоторая доработка. Но она требует высококвалифицированных кадров по Java, больших затрат и экономически нецелесообразна из-за присущих ему недостатков.

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

В отличие от Windchill к TCE можно подключить дополнительно приобретаемые модули: TeamCenter Manufacturing, TeamCenter Project и другие, где заявлена возможность создания техпроцессов, привязки детали к указанному техпроцессу, возможность указания рабочих областей, реализации расцеховки, нормирования материалов, формирования графиков технологического оснащения (формирование, контроль графиков). Но опять, это ПО требует доработки под отечественную систему документации. Информационная поддержка процесса проектирования, особенно конструкторской части у него все же недостаточна. Что касается документов, то они формируются в формате XML. На экране смотрятся нормально, но малопригодны при распечатке. Получить технологические карты невозможно. Требуется модификация БД и разработка дополнительных программ на Java для вывода на печать. А это не каждой организации под силу. Прикрепляемые к карточке документа ДСЕ файлы, как у Windchill и Search неупорядочены, неотсортированы, плохо читаемые и воспринимаемые в дереве. При интеграции с другими системами АСУ у TeamCenter, как и у других пакетов, возникает много проблем. Если в организации не ведется электронный архив (а это наблюдается на многих предприятиях), то перечисленные пакеты вообще не нужны: это лишнее звено.

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

Проблемы с интеграцией во многом связаны со сложным механизмом проведения конструкторских и технологических изменений, усугубляемыми различными системами, применяемыми на одном предприятие и построенных по разной бизнес-логике. Необходимо учитывать, что каждая деталь может иметь до десятка изменений, а на одно изделие может приходиться в среднем до десяти отклонений и решений по КД. И все это должна учитывать система и обеспечивать их отслеживание. Но этого в рассматриваемых PDM не предусмотрено. А потом на предприятиях из-за неупорядоченности и отсутствия информации возникают проблемы, например с обеспечением запчастями ранее выпущенных изделий. В перечисленных PDM практически ничего не предусмотрено для формирования каталогов запчастей, обеспечения их перевода на иностранные языки. Предприятия захлебываются из-за большего объема информации и неразберихи с ней. Зачастую внедрения одного такого продукта требует создания дополнительного подразделения. И это несмотря на то, что одной декларируемой целью PDM и CALS является исключение дублирования данных. Во многом из-за этого у нас многие зарубежные системы так трудно внедряются и есть случаи отказа от них. Другой причиной яв-ляется то, что зарубежные системы не рассчитаны на наш документооборот и нормативные до-кументы. В их базах данных просто не предусмотрено полей для требующейся нам информации. Много декларируется, но в реальности этого нет или оказывается не то нужно. Отсюда и вытекает тот пестрый огород из различных систем, который мы вынуждены применять. Предприятия, не имея другой альтернативы, закрывают глаза на многие проблемы и вынуждены применять то, что есть на рынке. А потом трудно выбраться из болота такого выбора.

Заявления фирм-дилеров о возможности серьезной доработки пакетов под ваши задачи во многом пустые обещания. Это связано с самими пакетами (системами их защиты) и их возможностями. В лучшем случае вам сделают интерфейс стыковки, требующий после него ручного редактирования. Подтверждением этому является опыт МАЗа, где за 8 лет смогли добавить в TeamCenter всего лишь одно символьное поле для маршрутов, передаваемое из Omega Soft и реализовать несколько внешних функций по контролю передачи данных в другую систему. Или мучаться с конвертацией данных, прибегая к использованию 2-3х смен (Уралмаш, Search), требующих больших затрат времени при использовании примененного интерфейса.

Если бы удалось объединить положительные стороны этих пакетов, включая СпрутМ, получилась бы идеальная система. А пока с точки зрения конструкторско-технологических служб и АСУ в рассматриваемых первых трех пакетах много недостает, их структура должна быть иная и поддерживаться больше за счет реляционных баз. Нет цепочки ДСЕ – изменение – извещение – их содержание (графика). Согласно ЕСКД извещение может выпускаться только на конкретное изделие или на группу. На конкретную ДСЕ оно не выпускается. Фактически, не к чему в рассматриваемых PDM прикрепить файлы документов по изменениям и извещениям. В классическом варианте база данных ДСЕ должна быть реляционно связана с БД изменений, в которой должны быть указано извещение. А само извещение должно представлять группу таблиц, содержащих помимо текстовой информации ссылки на графику. Должно обеспечиваться формирование бумажных документов по извещению и предписанию. Все это отсутствует.

Сложность в том, что каждая задача требует наличия в БД определенной информации. Состав информации в зависимости от задач переменен. Поэтому простое некоторое увеличение полей, как предлагается в этих пакетах, здесь не годится. Необходима иная универсальная структура баз данных, в которую путем привязки дополнительных реляционных строк к основной записи и за счет кодирования, некоторой избыточности можно было бы занести любую информацию. Такой структурно-объектный подход реализован в PDM-ERP системе СпрутМ. Например, БД конструктивных параметров, характеристик может использоваться как для ведения прикрепляемых файлов так и для занесения другой информации, например по штампу чертежа по материалам. И также универсально используется базы данных параметрики, конструктивно-технологических признаков ДСЕ, согласования, архивных, ссылочных данных. В большинстве же пакетов заноситься строго лишь только тот минимум информации, который необходим для выполнения их основного предназначения. Поэтому нельзя говорить об их универсальности и соответствия CALS. Из-за узкой направленности рассматриваемых модулей и не полноты их функциональности имеются сомнения можно ли их вообще относить к PDM, CALS.

Каждый рассматриваемый пакет ориентирован на свои модули, за которые надо отдельно платить. Полноты охвата функционала нет ни у одного импортного пакета. У многих пакетов нет функций формирования требующихся нам документов из-за отсутствия информации. Как уже указывалось у Windchill и Search нет своего модуля ERP. Поэтому многие используют ERP, другого разработчика или собственные разработки. Но чтобы все это нормально работало, необходимо, чтобы последующие модули придерживалось той же бизнес-логики и имели аналогичную структуру данных. А этого нет.

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

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

Комплексная оценка пакетов,

С точки зрения пользователей САПР и АСУ существующие PDM мало что дают конструктору и технологу из-за некоторых присущих им конструктивным недостатков и недостаточности содержащейся в них информации. Определенную часть функций (организационно-распорядительных, ведения архива) они выполняют, но этого недостаточно. Конструктору приходится выполнять много несвойственных ему функций. Ему необходима мощная информационная поддержка по деятельности всего предприятия и удобный механизм ее реализации. А этого пока нет ни в одном пакете. Для указанных PDM характерно занесение информации по обозначению в одно поле и использование ссылочного механизма при ведении базы данных состава (запись номера ДСЕ вместо обозначения). Все это приводит к невозможности выполнения сортировок по частям обозначения как по ДСЕ так составу. Это принципиальные недостатки перечисленных систем, которые накладывают много ограничений на дальнейшее использование их информации в других систем. Ведь без сортировок нельзя обойтись, особенно когда номенклатура изделий предприятий составляет сотни тысяч. Теряется информативность, можно легко пропустить при просмотре требующуюся информацию. Все это вынуждает внедрять дополнительные системы, включая собственные. А это ведет к необходимости дублировать ввод информации, объемы которой сейчас резко возрастают. Необходимо подключение технологов на ранней стадии еще до утверждения КД и обеспечения их необходимой информацией. Фактически сейчас имеется большая потребность, чтобы PDM помимо своих стандартных функций выполнял часть функций ERP систем. Именно в этом направлении ведется совершенствование СпрутМ.

Могут возразить, а как за рубежом решают остальные задачи при использовании крупней-шими корпорациями PDM Windchill или TeamCenter. Очень просто - за счет собственных программных разработок, дублирования ввода информации и ее конвертации. Указанные PDM используются у них в качестве вспомогательных систем, а не основных. Крупные корпорации имеют свои собственные PLM системы и интерфейсы для общения с поставщиками. Поставщики, как правило, интегрированы в систему корпорации через свои продукты. А рассмотренные выше PDM используются для связей с другими организациями. И не все здесь идеально. При использовании конверторов всегда остаются проблемы синхронизации данных.

Использование PDM Windchill, TeamCenter некоторыми российскими азрокосмическими КБ обусловлено спецификой их деятельности. У них КБ отделены от производства и применяется Unix на 64-х битных рабочих станциях для возможности работы с очень большими сборками. Задача этих КБ выпустить документацию, включая электронную. Вопросы интеграции с другими производственными системами считались не их сферой. Мол это проблемы заводов, которые выпускают их изделие. А производство больше ориентировано на ERP, а не PDM. Хотя сейчас начинают понимать в потребности в PDM и на производстве, чтобы разобраться с комплектацией. Вторая причина, что других пакетов под ОС Unix нет и надо как-то автоматизировать и координировать 3-хмерное проектирование и вести электронный архив. И поэтому приходится мириться с недостатками этих PDM.

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

При выборе пакета необходимо в первую очередь обращать внимание на его функциональность и вписываемость в принятую на предприятии бизнес-логику, а также с какой целью приобретается PDM. Хотя в целом идея организации процесса, предложенного PTC неплохая. К сожалению, его функциональность и обеспеченность информацией имеет крен не в ту сторону. Какая польза от системы электронного согласований, визуализации, электронного архива без мощной поисковой системы, если информация и функциональность недостаточна и ее сложно использовать в других системах. Автоматизированный ввод информации из конструкторской документации (ее сканирование из файлов моделей, чертежей) возможен в Windchill только для файлов ProE, у TeamCenter для UG. Search позволяет выбирать ее из файлов AutoCad, ProE, UG. Все не свое для Windchill, TeamCenter приходится заносить вручную. На заводах лишь не более 3-5% проектирования ведется в 3-D, все остальное в 2-D в основном в Автокаде. Это создает трудности с ведением такого многообразного электронного архива.

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

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

Одновременно необходимо учитывать, что многие зарубежные пакеты также плохо подходят и по блоку экономических и финансовых задач из-за другого законодательства, форм документов. То же можно сказать о технологическом блоке в части форм документов. Поэтому имеются большие сомнения в эффективности использовании зарубежных пакетов АСУ. Потребуется много доработок и подключения своих систем. Исключение составляет моделирование техпроцессов, неплохо решенное в технологических модулях PTC и EDS. Но это автономные модули больше ориентированные на графические пакеты. Они могут работать и без PDM-ERP указанных фирм. Чтобы получить отдачу от CALS надо сочетать и импортные пакеты (их отдельные модули) и свои, например: импортные графические пакеты и развивать свои CALS-системы, перенимая положительные моменты. Гораздо хуже слепое преклонение перед оторванными от реального производства заморскими продуктами, проведение технической политики, заводящей в тупик собственные разработки и обрекающей нас на технический застой.

Важно понять, что если выбираем PDM Windchill, TeamCenter, SAP или им подобную то всю последующую ИИСП надо строить либо на основе их модулей или по их идеологии: применять обозначение в одно поле, использовать ссылочный механизм ведения состава, осуществлять изменение путем формирования новой спецификации и изменение статуса старой. А это повлечет за собой много указанных выше проблем и снизит функциональность и эффективность всей системы. Многих требующихся нам функций у них нет. Все дальнейшее построение интегрированной информационной системы предприятия при таком подходе пойдет не так, как хотелось. Из других систем нельзя будет изменять данные реализуемые PDM. Внедрение таких “PDM” потребует кардинальной перестройки всей системы предприятия, его ломку, создания конверторов, применения дополнительных пакетов, реализующих недостающие функции, полного переоснащения техникой. Это на длительный период вносит сумятицу в деятельность предприятия. Могут возразить - используйте весь комплекс пакетов одной фирмы, например EDS, SAP. Но это нашим предприятиям просто не по средствам. Кроме того, они требуют наличия на предприятиях высококвалифицированных кадров по Java, Web-технологиям, ORACLE. А из-за низкой оплаты специалисты не хотят работать на заводах. И пока еще никто не продемонстрировал эффективного использования этих систем. Имеется уже ряд примеров, когда на предприятиях (БМЗ), использующих в качестве АСУ SAP /R3, начинают параллельно внедрять отечественные разработки, например по персоналу и зарплате. Это оказалось дешевле и проще, чем адаптировать модули SAP. И также необходимо рационально поступать при выборе модуля PDM и создании ИИСП.

Приобретать такие PDM (СЭД) ради осуществления только красивого механизма электронного согласования и визуализации вряд ли целесообразно. С точки зрения наших предприятий это не является столь первоочередным и особо важным. Редко кто из предприятий, применяющих PDM, использует эту функцию, т.к. согласование это своеобразный торг конструктора и технолога и требует личного контакта. Визуализацию можно решать по-другому. Например, используя COM–Java технологии запускать из пакета сторонние 3-D редакторы и загружать файлы, как это сделано в СпрутМ. Или формировать в нем html страницы и запускать из него интернет-браузер для просмотра упрощенных 3D моделей. Единственное, что надо сделать: осуществить заранее вручную преобразование полной модели в упрощенную через 3-D редактор. У Windchill это делается динамически на сервере без участия человека, но требует мощных серверов. У СпрутМ применяется более простой механизм текстового электронного согласования и электронной подписи с идентификацией файлов, введен механизм замечаний с прикрепляемыми файлами графики, есть ведение заказных спецификаций и многих ERP задач.

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

Кроме того, западные продукты более ориентированы на верхний уровень управления, а не на средний и нижний, что сейчас больше необходимо нашим предприятиям. Стоимость одного рабочего места такого PDM не маленькая 4-6 тыс. $ /рабочее место (Windchill), 39 тыс.? для UG c TeamCenter, Search (3 тыс.$), а их требуется на предприятии несколько сотен, не учитывая других систем. Слишком дорогая цена за функцию согласование. Реально у большинства предприятий сейчас таких средств нет, тем более на кардинальное обновление всей системы предприятия. ИИСП - это комплексная система, где все должно работать во взаимодействии. И если какой-то модуль не вписывается в общее информационную среду, то лучше им пожертвовать.

Если использовать имеющиеся сейчас PDM скатимся на организационно-распорядительные функции и не построим интегрированную информационную систему предприятия - полноценную CALS/PLM систему. Вложим большие средства и не получим в итоге отдачи. И такие отрицательные результаты в РБ и СНГ уже есть, а главное потеряем веру в собственные возможности.

Но PDM в первоначальном их определении все же необходимы, ибо от них должна строиться вся информационная система предприятия. Они должны быть созданы с несколько иной функциональностью, чем существующие. Необходима единая информационная система, которая бы охватывала все: информационное обеспечение процесса проектирования и технологической подготовки, управление производством, взаимодействие со всеми участниками, поддержку жизненного цикла изделия, причем на новом качественном уровне с графикой. Требуется объединение усилий в этом вопросе.

Интересно Ваше мнение.

<noindex>http://docs.google.com/View?docid=dhnqt6f5_12g7mk8s</noindex>

[SVB 188]

Прочел с интересом. Трактат из серии сделано профессионалом (слова то все грамотные по отдельности...) для оправдания себя — продвижения своих продуктов.

Но шито такими белыми нитками, что просто жуть!

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

Если автор пишет:

Стоимость одного рабочего места такого PDM не маленькая 4-6 тыс. $ /рабочее место (Windchill),

Значит он ПРОСТО НИЧЕГО не понял. Значит он полагает ставить на каждое рабочее место сервер Windchill??? Дальше обсуждать уже нечего. Значит он не понял как работает PDM-Link. Значит операции Chek-in и Chek-out — это вне его компетенции... автор даже не в курсе для чего они и на каком рабочем месте они выполняются... Вот такой получился "Лысенко" от PLM —этот Михайлов В.Г.

[evgeny_ch 0]

"Мне, как разработчику PDM-ERP систем (СпрутМ), занимающемуся САПР, не известно ни одного случая успешного применения зарубежных PDM-ERP компонентов в СНГ на машиностроительных предприятиях. Да отдельные подсистемы, в основном ERP и где-то слабые PDM, изредка используются (как потемкинские деревни). Особого прока я, как производственник, от них не вижу т.к. это не CALS-системы. Хваленые зарубежные системы слишком дороги и не имеют необходимой полноты требуемых сейчас функций, поддержки графики. Эти системы ничего не дают конструкторам и технологам – первичному звену производства. Они несут шлейф старых подходов и проблем, которые надо менять. Но почему-то нам этот устаревший товар усиленно навязывается и находится много желающих погреть руки на этом. Поэтому нам необходима своя новая система, учитывающая все положительное имеющееся в зарубежных и отечественных разработках и адаптированная под наши условия. Только комплексные системы могут дать эффективную отдачу и навести порядок на производстве."

Авторы: Михайлов В.Г., к.т.н, МЗКТ, САПР

Наше лучше пахнет, не так ли?

А наше - это плохо захаченое забугорное.

А мы белые пушистые и бескорыстные.

[SAS_17 10]

Мне, как разработчику PDM-ERP систем (СпрутМ), занимающемуся САПР, не известно ни одного случая успешного применения зарубежных PDM-ERP компонентов в СНГ на машиностроительных предприятиях.

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

[SVS 1]

... рассмотрим ряд наиболее лучших зарубежных и отечественных систем: Windchill (PTC, США), Teamcenter (EDS, США), Search (Интермех, РБ) и сравним их с разработкой МЗКТ СпрутМ.

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

Я вообще когда читал, еле сдерживался от смеха.

А вот это "Без коментариев":

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

[SVS 1]

Почитайте вот эту тему

<noindex>http://fsapr2000.ru/index.php?showtopic=9...%E1%E5%EB%E0%E7</noindex>

Странно как то.

Altair_s, который задал вопрос (зарегестрирован 22.12.2005) и vladmi, который отвечал на вопросы (зарегестрирован 22.12.2005) очень уж похожи по формальным признакам и вопросу-ответу.

А vladmi очень уж похож на автора статьи.

[slaz 0]

Как говорится среди падонков "Аффтара в топку! Низачёт!".

Такой лабуды и в правду давно читать не приходилось.

Что статья заказная - тут без вариантов :), но вот КЕМ? - вот это вопрос!

Вообще у мня есть 2 версии появления этой чуши:

1. Это товарищи разработчики/продавцы того самого небесного "СпрутМ", но уж больно все несуразно написано. Слишком прямо указано кто герой, а кто дурак. Слишком много вызывает негатива. Они это должны были понимать, когда выпускали ее на свет божий.

Поэтому есть версия 2:

2. Статья заказна КЕМ-ТО, как раз против "СпрутМ", дабы вызвать гнев праведный. (Про "СпрутМ" рассуждать не буду, не видел его, и даже не знаю творение ли это "Спрут-Технологии" или же нет, поскольку на их сайте о таком продукте ни слова нет).

Вот...

[Странник 6]

Сфера применения Search - проектные организации в основном конструкторско-технологического профиля, которым нет необходимости в CALS. Следует отметить, что Search от версии к версии заметно прогрессирует и по своим возможностям во многом уже превзошел TeamCenter. Подводит его наличие ошибок в программном обеспечении.

Если кто скажет что в среде Searh можно ПРОЕКТИРОВАТЬ, то не верьте этому человеку.

Максимум, на что способен Intermeh это поддержка работы серийного завода, при условии уже готовой КД.

Чем он силён, так это Imbase, Tehcard (пожалуй для технолога трудно найти что лучше в СНГ) и, как то ни странно, Workflow (сравнивая с смартимовским, лоцмановским и SWR-Workflow, хотя и про другие слыхал много смешного, но сам руками их пока не щупал).

Главная беда Searh это ну очень очень большие трудности с построением ЭСИ, хотя и потребность в единой адресовке ОРП у каждого пользователя, а то и в едином логическом диске тоже ну очень смешна.

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

В общем же и целом ни одному конструктору не посоветую ставить такое ПО на рабочее место.

Как уже указывалось у Windchill и Search нет своего модуля ERP.

За Windchill не скажу, а с Search интегрировать можно... правда должно быть это достаточно муторным делом.

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

Вот в чём автор сего длинного трактата от правды не далёк, так это в мысли о отсутствии подходящего для российских предприятий ПО.

ТАКОГО СОФТА НЫНЕ ДЕЙСТВИТЕЛЬНО НЕТ!

[SVB 188]

Странник, когда научитесь пользоваться правильно форумом? Почему опять указываете на цитату, якобы моих слов, которые я не писал???