Единичное производство и Pdm

[Ayrat A. Sibgatullin 0]

Здравствуйте.

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

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

[Krusty 194]

Для мелких компаний если память не изменяет есть SmarTeam Express (http://www.3ds.com/ru/products-solutions/plm-solutions/enovia-smarteam/overview/) и TeamCenter Express (http://www.ugs.com/products/velocity/teamcenterexpress/tcx.shtml) они я кобы ориентированы на мелкие фирмы, легки в развертывании и эксплуатации

[green_fx 0]

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

[Marian 0]

[q] по поводу внедрения PLM систем на единичном или мелкосерийном производстве.

[/q]

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

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

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

Так что все возможно

[Ayrat A. Sibgatullin 0]

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

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

При серийном производстве процент готовых механизмов гораздо выше, соответственно новых механизмов меньше - проблем меньше.

Поэтому с этой точки зрения использование PDM в единичном производстве не всегда оправдано.

[Max KZK 2]

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

[Paul_S 0]

В принципе можно проектировать и вне PDM, а потом туда ее выгружать...

только тогда вам нужно иметь две абсолютно одинаковые библиотеки - на диске и в PDM...

...и вносить изменения и туда и туда... стоит ли?

Считаю, что PDM нужна в любом случае...

...проблем с проработками нет...

...а если единичное изделие разрабатывает большой коллектив?

коллективная работа без PDM это геморой!

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

[Marian 0]

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

А вот это утверждение как раз и спорно. Если у вас нет ПДМ , то откуда такие выводы о удобстве/неудобстве, характере и наличии проблем?

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

2-я проблема - техническая. Необходимо минимизировать затраты времени на операции между САПР и ПДМ. Таким образом вопрос сводится к тому , что ПДМ необходима в любом случае, но какая именно?

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

Хотя если есть другие требования руководства, цели или ограничения - и эта рекомендация может измениться.

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

Изменено 6 июня 2007 пользователем Marian

[vladmi 0]

Задача PDM заключается в информационном обеспечении и координации всех участников проектирования и изготовления изделий. Необходимо, чтобы технолог уже на стадии конструкторского проектирования подключался к этому процессу. Для этого ему нужны 2-D, 3-D модели, КД, информация по конструкторскому составу. Эту информацию он получает из PDM. На Минском заводе колесных тягачей, где я работаю, применяется две базы данных: конструкторского и технологического состава. Наши технологи в своей БД меняют состав конструкторских сборок под технологический процесс изготовления деталь-сборочной единицы (ДСЕ). Процент изменения КС в БД ТС составляет 10-15%. Для планирования производства используются управляемые процедуры разузлования на основе кодов принадлежности (Кп) ДСЕ, определяющих условия разузлования и классификацию деталей (деталь, сборка, заготовка и т.п. по 20-ти значениям). В БД ТС технологи меняют конструкторские коды принадлежности на свои технологические. Технологическая база данных связана с маршрутами изготовления. У БД КС этого нет. Такова типичная схема для многих машиностроительных предприятий, использующих старые системы на FoxPro. Она нормально работает при серийном производстве. Но для мелкосерийного производства она не годиться, поскольку последнее связано с конструкторским составом. Особенностью мелкосерийного, единичного производства является то, что на ДСЕ не разрабатывается полного комплекта технологических документов и не используется специальная оснастка, инструмент. Часто технолог эксперим. цеха расписывает упрощенно техпроцесс прямо на КД. Для изготовления используется универсальное оборудование. Как правило в ТС занесены только ДСЕ основного производства, ДСЕ по ОКР из-за разности кодов принадлежности не заносятся. Существующая система ОИТ не приспособлена для этого. Ситуация усугубляется тем, что номенклатурный перечень каждого изделия по конструкторскому составу (КС) на нашем заводе составляет порядка 6-10 тыс. наименований и доля ОКР, единичного производства у нас составляет до 30%.

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

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

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

После тщательного выяснения причин было найдено решение, которое было реализовано в новой версии системы СпрутМ (см. статьи по CALS на www.belerp.com ). Оно свелось к созданию унифицированной базы данных конструкторского и технологического состава в одной таблице (порядка 80 полей). Благодаря индефикаторам принадлежности записи к тому или другому составу и ведению раздельных Кп удалось разделить базы данных. Это позволило развязать узел проблем.

Конструктора работают со своим составом, технологи со своим. Легче стало проводить изменения. А с этой таблицей реляционно связана таблица маршрутов (по цехам, участкам, рабочим местам, оборудованию). Имеются вариации маршрутов. В результате процент неучета уменьшился до 10% т.к. новое изделие, как правило, на 70% унифицировано с серийными. Этот процент в дальнейшем будет снижен до нуля при полном компьютеризации подразделений завода и назначении временных маршрутов по ДСЕ ОКР. Задание планирования на определенный период сводится к составлению специальной спецификации плана в эту же таблицу, где перечисляются изделия, их количества, сроки изготовления. Проводится разузлование по отдельным БД: для серийных машин по технологическому составу, ОКР, отдельным, разовым заказам по конструкторскому составу. Далее на основе этой информации производится расчет планирования, сводящейся к подсуммированию и заполнению специальных таблиц номенклатурного справочника ДСЕ, по моделям и их цеховым номерам, а также входимости и маршрутам. На основании их формируются перечни планов: общие, по подразделениям и т.п.. Предусмотрена возможность корректуры планов, их изменения, удаления. Благодаря этим изменениям в СпрутМ, мы все ближе подходим к CALS-системе:у нас есть возможность ведение электронного архива, осуществлять сквозное проектирование, подготовку производства, управление производством и за счет всего этого значительно сократить сроки внедрения изделий.

Изменено 20 июня 2007 пользователем vladmi

[linde 0]

Задача PDM заключается в информационном обеспечении и координации всех участников проектирования и изготовления изделий. Необходимо, чтобы технолог уже на стадии конструкторского проектирования подключался к этому процессу. Для этого ему нужны 2-D, 3-D модели, КД, информация по конструкторскому составу. Эту информацию он получает из PDM. На Минском заводе колесных тягачей, где я работаю, применяется две базы данных: конструкторского и технологического состава. Наши технологи в своей БД меняют состав конструкторских сборок под технологический процесс изготовления деталь-сборочной единицы (ДСЕ).

А какую PDM используют на Минском заводе колесных тягачей?

И в каком САПРе Вы работаете?

[vladmi 0]

А какую PDM используют на Минском заводе колесных тягачей?

И в каком САПРе Вы работаете?

УГК и УГТ используют в своей деятельности широкораспространенные 2-D, 3-D зарубежные пакеты и др. Основной объем конструкторской документации в УГК, как и на большинстве заводов, пока выполняется в в 2-D. Pro/E используется, в основном, для прочностных расчетов, выпуска каталогов, ремонтной документации и компоновок. Но есть тенденция к его большему использованию. Препятствием этому недостаточный его функционал для оформления КД. Нет фирм, которые могут написать хорошую надстройку на Java. В основном фирмы-продавцы готового.

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

Я работаю в УГК, занимаюсь больше конструкторским САПР. Используется PDM-ERP система СпрутМ собственной разработки на Borland C++ Builder под ORACLE. СпрутМ пока используется в основном в УГК. На заводе много старых компьютеров (50%), нет нормальной сети, ОИТ оказался неспособным вести разработки под Windows и прдолжить линию СпрутМ. Поэтому вынуждены делать работу за них. Разработка СпрутМ ведется с 1998 г. СпрутМ работает со всеми графическими и текстовыми пакетами (Pro/E, UG, SolidWorks/Edge, AutoCad, MS Office и др.). Мы изучали и тестировали много пакетов PDM, ERP и ничего устраивающего нас не нашли. Поэтому вынуждены были начать свою разработку. Первоначально СпрутМ задумывался как PDM с более расширенными функциями для констркуторских служб. Снйчас СпрутМ постепенно охватывает все больше функций ERP и постепенно превращается в полноценную CALS систему.

Изменено 20 июня 2007 пользователем vladmi

[SVS 1]

Ayrat A. Sibgatu...

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

Для Этого как раз можно использовать Windchill ProjectLink. В нем, допустим, ведется проект по созданию машины. И вот уже после завершения работы над машиной все это передается в Windchill PDMLink. Т.к. система одна - Windchill, то постоянно имеется доступ как к библиотекам, так и к другим изделиям, откуда можно заимствовать узлы, детали.

vladmi

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

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

Вот вам чертежи:

[Max KZK 2]

как и на большинстве заводов, пока выполняется в Автокаде

На КЗК пару лет назад, когда AutoDesk стал рассылать письма с угрозами, Генеральный директор приказал разобраться и доложить, кто использует Автокад. После долгих поисков нашли пару компутеров, кажется, в отделе Главного энергетика. Автокад, разумеется, снесли, и на этом его история на КЗК кончилась так толком и не начавшись. Так что, не надо, про большинство

[SVB 188]

Может я и ошибаюсь, но мне почему-то кажется, что vladmi и Михайлов В.Г., к.т.н. — одно и тоже лицо. Есть такая вероятность...

Понятное дело, что раскрывать ник никто не обязывает..., но у меня вопрос к vladmi:

Как Вы относитесь к статье Михайлова В.Г., размещенной на этом форуме здесь: <noindex>http://fsapr2000.ru/index.php?showtopic=17636</noindex>

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

Вот и SVS тоже подозревает "неладное"

[vladmi 0]

Для Этого как раз можно использовать Windchill ProjectLink. В нем, допустим, ведется проект по созданию машины. И вот уже после завершения работы над машиной все это передается в Windchill PDMLink. Т.к. система одна - Windchill, то постоянно имеется доступ как к библиотекам, так и к другим изделиям, откуда можно заимствовать узлы, детали.

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

Вот вам чертежи:

В начале темы было предложено высказатся по поводу внедрения PLM систем на единичном или мелкосерийном производстве. Почему-то узко понимают этот вопрос: только применительно к 3-D проектированию. Проблемой для конструкторов предприятий является выпуск КД в Pro/E или UG, а не занесение состава в Windchill PDMLink или планирование проектных работ. Без этого мы, производственники, можем обойтись, это не столь первоочередное. Информацию все равно необходимо конвертировать в ERP. При проведении измененийв КД, ТД возникает много с этим проблем. Получается лишнее звено. Предложенные одной коммерческой фирмой нам настройки имеют много ошибок, а сами они устранить их не могут. Могут только торговать. Если у Вас есть хорошая настройка для Pro/E по оформлению КД предложите на sapr7@mail.ru. Я передам предприятию. Более злободневной проблемой является невозможность учета ДСЕ опытно-конструкторских работ при планировании производства. Пока ни один PDM в связке с ERP не учитывает этого, как и не реализует ведение изделий по заказным спецификациям и планирование призводства по ним. Поэтому я и поделился своим опытом решения проблемы. Но проблема гораздо шире. Необходима единая информационная система всего предприятия, объединяющая PDM, ERP и другие системы. Windchill решает только узкий круг задач. У него слабая поисковая система. Из-за своей структуры (подходов) он, как и TeamCenter, плохо вписывается в CALS. Сейчас открыта тема Концепция создания корпоративной системы предприятия на основе CALS в рамках темы Все вопросы о PDM. Хотелось, чтобы высказались (или предложили) по существу.

[SVS 1]

Необходима единая информационная система всего предприятия, объединяющая PDM, ERP и другие системы. Windchill решает только узкий круг задач. У него слабая поисковая система. Из-за своей структуры (подходов) он, как и TeamCenter, плохо вписывается в CALS. Сейчас открыта тема Концепция создания корпоративной системы предприятия на основе CALS в рамках темы Все вопросы о PDM. Хотелось, чтобы высказались (или предложили) по существу.

Вы что хотите систему САПР+PDM+ERP от одного производителя. Я пока с такими продуктами не сталкивался. Пожалуйста PTC предлагает САПР(Pro/ENGINEER)+PDM/PLM(Windchill). ERP модуля у PTC нет, для этих целей есть специальные продукты (SAP, Oracle, ..."Свои собственные"). И нечего смешивать все в кучу. Задача Windchill Передать всю необходимую информацию в ERP. И это у Windchill как ни странно получается. Это что по вашему не единая информационная система всего предприятия.

Вот цитата из энциклопедии "Викепедия" (http://ru.wikipedia.org/wiki/PDM)

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

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

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

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

Вы хоть понимаете что пишете. Хотя бы посмотрели прежде чем такое заявлять. Windchill ишет не только по всем полям, но и по содержимому файлов. Объясните пожалуйста какой вам еще нужен поиск?

Если у Вас есть хорошая настройка для Pro/E по оформлению КД предложите на sapr7@mail.ru

Эти настройки есть у всех у кого есть ProE.

[SVB 188]

2 vladmi, Вам синих квадратиков, показанных на картинке — от одного поставщика мало?

Будем "тень на плетень наводить"?

[vladmi 0]

2 vladmi, Вам синих квадратиков, показанных на картинке — от одного поставщика мало?

Будем "тень на плетень наводить"?

У меня складывается впечатление, что большинство оппонентов является представителями фирм, торгующих ПО и их очень задевает критика продаваемых ими продуктов. В целом конструктоско-технологический блок PTC нас устраивает. Но камнем преткновения явлются недостатки Windchill и подобных ему PDM и их подходы, загоняющие в тупик последующее создание корпоративной информационной системы предприятия. В качестве контраргумента опоненты приводят возможность поиска информации (по атрибутам) в Windchill по файлам моделей. Такой поиск возможен по заголовочной текстовой части файла, но это же моразм. При большом объеме архива в Терабайтах он будет длится порядка несколько часов. В СпрутМ есть возможность сканирования этой информации атрибутов файла модели для занесения состава в БД. Но это совершенно другое. Критики слабо представляют потребности реального производства с полным циклом, зациклившись только на 3D пакетах и PDM и их отдельных функциях. Предприятию необходима единая информационная система, включающая и такие системы и охватывающая все, иначе мы утонем в колосальном объеме данных, конвертации из одной системы в другую. Мы делаем порядка 10-ти новых изделий в год. Каждое имеет состав порядка 10 тыс. У нас за месяц проходит от 500 до 2000 изменений в КД. На изделие до 10-ти отклонений. Каждое из этих изменений надо провести в конструкторском составе, технологическом или производственном и их базах данных. Изъять и заменить бумажную документацию. Механизм изменений настолько сложен, что многим пакетам не под силу, этим на заводе занято порядка 30-50 человек. И не один конвертор не позволяет все учесть. Мы захлебнеися в этом. Поэтому и нужна единая система с единой БД. Именно на это на это нацелен CALS. Многие хваленые западные продукты не отвечают его требованиям и потребностям производства. В них часто реализуются не столь важные для нас функции (второстепенные для нас). А первостепенные для нас функции часто вообще не реализованы или сложно их осуществить. Примером является ситуация с компьютерным ведением мелкосерийного производства. Те же BAAN, SAP больше нацелены на финансово-хозяйственную сферу дистрибьюторских и торговых компаний и верхний уровень управления. В первую очередь на автоматизацию бизнес-процессов в области бухгалтерского учета, учета затрат, управления логистикой и техническим обслуживанием и ремонтом оборудования. Они больше подходят для оценки капитализации предприятия. И гораздо слабее для управления производством. Один конвертор из Windchill в BAAN стоит 250 тыс.$. БелАЗу понадобилось 7 лет и 2 млн.$ выброшенных денег, чтобы убедится в неэффективности BAAN и Windchill. На очереди прозрения МАЗ. И такая ситуация с многими другими продуктами. Но потребность в единой системе есть и ее надо делать, а не кривить рожи. Изменено 21 июня 2007 пользователем vladmi

[mech 1]

vladmi,

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

[SVS 1]

В качестве контраргумента опоненты приводят возможность поиска информации (по атрибутам) в Windchill по файлам моделей. Такой поиск возможен по заголовочной части, но это же моразм.

А вы знаете как происходит поиск в Windchill?

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

При большом объеме архива в Терабайтах он будет длится порядка несколько часов.

А вы делали запрос в Windchill при террабайтном объеме архива?

В теме "Концепция Создания Кис На Основе Cals" вы утверждаете что в Windows Vista нет командной строки.

Ситуация с Vista сложная: она не представляет собой качественного шага вперед: ее функционал больше нацелен на то, чтобы заставить пользователей использовать лицензионное программное обеспечение. ... . Кроме того, в Vista исключено использование командной строки, что делает невозможным применение многих существующих программ в т. ч. на Java, MS-DOS, например Windchill, ORACLE.

И Vista не знаете, но уверенно пишете о ее недостатках, а люди потом читают и делают не правильные выводы.

В своей статье указывали на то, что Windchill работает только с ProE

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

Автоматизированный ввод информации из конструкторской документации (ее сканирование из файлов моделей, чертежей) возможен в Windchill только для файлов ProE

(А как же специально разработанные менеджеры для UG, Catia V5, SolidWorks, AutoCAD AUTODESK INVENTOR, I-DEAS.)

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

Хотите похвалить себя и СпрутМ, так хвалите, никто это не запрещает, но не возносите свою систему за счет обсира...я других систем.

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