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

[SVB 188]

2 vladmi

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

Я не являюсь представителем фирм, торгующих ПО, я — пользователь.

В целом конструктоско-технологический блок PTC нас устраивает.

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

Подробности смотрите в замечаниях от SVS и мои также в том числе и в ветке: <noindex>http://fsapr2000.ru/index.php?showtopic=17636</noindex>

Вы, господин кандидат технических наук, ведёте себя как М.С. Горбачев — вместо ответов на конкретные вопросы засыпаете пустопорожним многословием, вынутым из кармана. Думаете такая политика замаскирует Ваше незнание практических вопросов? Ошибаетесь! Такая Ваша тактика катит только на неподготовленной публике, а не на этом форуме. Многословие это ещё не признак ума!

К примеру одна Ваша фраза-предложение:

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

Говорит о том, что степень внедрения Pro/E на Вашем предприятии плачевное. Выводы напрашиваются простые. Как в старом анекдоте про бардель, который перестал приносить прибыль — про то, что нужно не мебель менять (плодить зоопарк PLM-продуктов), а девочек менять. Т.е. к подбору, обучению, стимулированию сотрудников подходить нужно основательно, а не искать "козлов отпущения" в заморских продуктах. Причем во всех продуктах... Создаётся впечатление, что на Вас как красная тряпка на быка действует только одно слово — зарубежные... Вникать в практику уже это как бы не обязывает?.. Ну прямо как красный комиссар! Политикой попахивает. Тенденция сверху?.. Белоруссия, однако.

Полагаете, что Вы получили карт-бланш на бесконечный консалтинг Вашей фирмы? Полагаете, что никто и никогда не найдет в чем упрекнуть СпрутМ и его разработчиков? Или может быть, извините за народный юмор — "Своё г... не пахнет?"

[vladmi 0]

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

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

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

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

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

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

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

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

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

То что я высказал, это один из возможных механизмов реализации поиска по атрибутам модели. Неужели Вы никогда не смотрели содержимое файла ProE модели текстовым редактором, например Far. Ведь в начале файла в заголовочной текстовой части модели содержиться информация по атрибутам и имена файлов, составляющих сборку. И с этой части считывается и заносится информация по составу сборки. С вашего заявления Гуру по Windchill выходит,что по содержимому атрибутов самой модели поиск не проводится. Вопросу атрибутов и шаблону модели, похоже, Вы не уделяете внимания. А ведь это важный аспект Pro/E и Windchill. И как тогда Вы работаете в ProE и ведете Windchill ?

В следующей ремарке уточняется (Вообще-то в Windchill индексируются все необходимые поля, а также при необходимости индексируется содержимое файла (TXT, , ...) и поиск осуществляется достаточно быстро.

Но полей на экране кот наплакал и поиск соответственно ограничен. Их правда можно добавлять, но они будут смещены за сетку таблицы и не видны. Что касается содержимого файла, речь, я понимаю идет о прикрепляемых файлах. То что поля БД могут быть проиндексированы и возможен линейный поиск понятно. Но то что индексируется содержимое файлов Word, PDF и др. и организован быстрый поиск по ним сомниваюсь. Нам диллеры ряда фирм этих уникал ьных возможностей Windchill никогда этого не демонстрировали и о них не говорили. Непонятно, кто прав?Внутренней структуры БД Windchill похоже никто не знает? Неужели так трудно в ORACLE или TOAD посмотреть ее.

То что можно прикрепить любой файл понятно. Но непонятно, как в Windchill можно сканировать состав сборок из файла сборочного 2D чертежа Автокада? Это можно сделать только вручную.

Чтобы развеять все сомнения и разное понимание вещей привели бы структуру основных таблиц Windchill и интерфейс обмена информации с ERP

[SVB 188]

2 vladmi

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

Не сомнИвайтесть — индексирует. Индексировала всегда на английском текст. Сейчас индексирует и на русском. Во всяком случае в Windchill V8 M040 — точно. Но индексирует в PDF-файлах только в тех, где текст распознан в векторном виде, а не в растровом. Т.е. если Вы из Worda конвертируете документ в PDF, то и в этом PDF будет всё индексировать. А если сосканировали текстовый документ без использования программ класса OCR (FineReader и т.д.), то не будет индексироваться.

А вообще— это уже лучше — можно хоть попенять на "дилеров ряда фирм", что недообразовали Вас. Маленький попутный вопросик — ну ежели если с такими вещами не разобрались, то как Вы берётесь такие "диагнозы" ставить Windchill'у?

"Трудно спорить о вкусе устриц, не испробовав их" — М.М. Жванецкий...

[SVS 1]

С вашего заявления Гуру по Windchill выходит,что по содержимому атрибутов самой модели поиск не проводится. Вопросу атрибутов и шаблону модели, похоже, Вы не уделяете внимания. А ведь это важный аспект Pro/E и Windchill. И как тогда Вы работаете в ProE и ведете Windchill ?

При сохранении модели в Windchill, из модели передаются все необходимые параметры и заносятся в соответствующие поля. А по содержимому модели поиск не проводиться. Поиск проводиться уже по содержимому полей.

Раз уж же сравнивали Windchill c др. системами, то должны были знать, а раз не знаете, не чего браться за такое ответственное дело.

То что можно прикрепить любой файл понятно. Но непонятно, как в Windchill можно сканировать состав сборок из файла сборочного 2D чертежа Автокада? Это можно сделать только вручную.

В Windchill передается не только состав сборки. Файлы Автокада, так же как и файлы ProE, UG, и т.д. имеют свои параметры, вот эти параметры и передаются в поля Windchill при сохранении в базу. Конечно из автокада мы не сможим передать состав, потому что его там нет, это и ежику понятно. Так же мы можем заводить свои параметры, для Word и так же, при сохранении, передовать их в Windchill.

Но полей на экране кот наплакал и поиск соответственно ограничен

Сколько вам надо полей - 100, 200,...,1000?

На картинке их больше 20. Но нам и этого хватает. Могу сделать хоть 1000, в чем проблема я что-то не пойму.

Как сказал SVB

"Трудно спорить о вкусе устриц, не испробовав их" — М.М. Жванецкий...

[evgeny_ch 0]

2 vladmi, вас опыт белаза чему-нибудь научил?

Заметно, что вы не поняли, почему там не получилась автоматизация.

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

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

Читал об опыте внедрения систем в Японии в 80 -90 годы. Там работникам после внедрения запретили держать на рабочем месте более 0,5 кв. м. бумаги. Подумайте, почему?

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

[Елена 116]

Можно вступиться за vladmi? По-видимому человек хочет посоветоваться, а на него накинулись. А свое, если при этом достигается цель всегда лучше. В конце-концов можно написать любой функционал под потребность предприятия (при наступлении новых возможностей - исправить не обращаясь к разработчику). Мы ведь не выбрасываем кучу денег на самое дорогое и красивое (для чего бы нам пришлось влезь в долги), а исходим из целесообразности. Для нас например целесообразнее оказалось на основе досовской БД (DBF) разрабатывать новые приложения под Windows (для новых таблиц использую СУБД по-современнее). И старые ПЭВМ задействованы под те задачи, с которыми справляются (состав изделия, материалы, трудоемкость и т.д) и новые возможности добавляются, и никого не напрягаем (систему не останавливаем). Будет возможность перевести состав изделия на другую БД - переведем без существенного изменения кода windows-приложений. В конце-концов (как здесь заметили) бизнес-процессы предприятия лучше всего видны на самом предприятии. А переучивать людей без конца (или одних выгонять, а других набирать) - эффекта не добиться. Это можно делать при подборе команды, при создании нового предприятия, а когда связи установились (зачастую многолетнии) - такой подход может только все разрушить, не создав ничего нового. Поэтому те, кто отвечает, прежде чем принимать решение должен все тщательно взвесить.

[SVS 1]

Возвращась к истории:

В первом своем ответе vladmi дает ссылку на статью

После тщательного выяснения причин было найдено решение, которое было реализовано в новой версии системы СпрутМ (см. статьи по CALS на www.belerp.com ).

где и находиться его статья

<noindex>http://www.belerp.com/modules.php?name=Ava...rint&pid=76</noindex>

В которой очень много написано хорошего про СпрутМ и очень много плохого про Windchill. Причем, почти что все неправда.

Например продолжая последние посты привожу цитату из статьи

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

...Windchill, похоже, исходит из того, что данная информация должна содержатся в файле самой модели в виде атрибутов. В его БД многие параметры отсутствуют.

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

...Слабым местом рассматриваемых PDM является недостаточный объем вносимой первичной информации и отсутствие ее кодирования из-за непредусмотрения соответствующих полей и непроработанности структуры БД...

Windchill решает только узкий круг задач. У него слабая поисковая система. Из-за своей структуры (подходов) он, как и TeamCenter, плохо вписывается в CALS

В отличие от Windchill к TCE можно подключить дополнительно приобретаемые модули: TeamCenter Manufacturing, TeamCenter Project и другие

см пост N17 <noindex>http://fsapr2000.ru/index.php?showtopic=1...st&p=160688</noindex> - Синие квадратики. Вам их мало?

И так можно продолжать и продолжать.

Этот форум читают многие люди, и наверное хотят почерпать отсюда верную информацию, а не чьи-то предположения, которые высказаны как 100% утверждение. Поэтому и приходиться отвлекаться от работы и указывать где правда, а где ложь. Замете, про СпрутМ пока ни кто ни чего плохого не сказал.

[vladmi 0]

При сохранении модели в Windchill, из модели передаются все необходимые параметры и заносятся в соответствующие поля. А по содержимому модели поиск не проводиться. Поиск проводиться уже по содержимому полей.

Раз уж же сравнивали Windchill c др. системами, то должны были знать, а раз не знаете, не чего браться за такое ответственное дело.

В Windchill передается не только состав сборки. Файлы Автокада, так же как и файлы ProE, UG, и т.д. имеют свои параметры, вот эти параметры и передаются в поля Windchill при сохранении в базу. Конечно из автокада мы не сможим передать состав, потому что его там нет, это и ежику понятно. Так же мы можем заводить свои параметры, для Word и так же, при сохранении, передовать их в Windchill.

Сколько вам надо полей - 100, 200,...,1000?

На картинке их больше 20. Но нам и этого хватает. Могу сделать хоть 1000, в чем проблема я что-то не пойму.

Как сказал SVB

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

Но в пылу полемики забыли о предмете, что тема единичное производство и PDM. Я предложил решение одной из проблем.

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

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

Чтобы осуществить планирование выпуска, необходимы маршруты изготовления ДСЕ. Ими часто пользуются и конструктора. У нас они привязаны к записям технологического состава и не учитывают ОКР.

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

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

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

[SVS 1]

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

Это и есть стандартный Windchill, в который всего лишь добавлены необходимые параметры. Универсальных параметров нет. На каждом предприятии они свои. И в стандартном Windchill нет ни одного параметра. Эти параметры (24 шт) были добавлены меньше чем за 1 час. Не думаю что то что мы обсуждаем является недостатком Windchill.

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

В картинке слева вы можете посмотреть информацию о:

- где используется

- Какие можно использовать заменяющие

- и т.д.

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

Эти БД как раз и являются универсальными для занесения любой информации.

Принятая система обозначений несет определенную информацию (классифицирует ДСЕ). Т.е. обозначение должно быть разнесенным в несколько полей

На одном из западных предприятий используется следующая схема:

Обозначение - какой то сгенерированный уникальный номер (например 020000000256). Т.е обозначение заносится в одно поле.

Далее имеется ряд параметров, которые характеризуют эту модель и позволяют таким образом классифицировать. Например:

Тип - Деталь типа тела вращения (010), или Плита (020) , и т.д.

Область использования - Нижний мост (110), Кабина (120), и т.д.

и т.д. (Это всего лишь пример)

Может я ошибаюсь, но объясните какая разница

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

или

2 - иметь обозначение, которое состоит из этих параметров отображаемых в числовом виде (010-120-...)

Чем первая схема хуже второй? По моему они одинаковы.

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

Так же могу сказать, что все стандартные и прочие изделия у нас вообще имели безликое обозначение (например 3135463), которое соответствовало коду BaaN. Было неудобно, в дереве ProE обозначения были безлики, но видимо в глобальном масштабе это было выгодно для предприятия.

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

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

[vladmi 0]

Это и есть стандартный Windchill, в который всего лишь добавлены необходимые параметры. Универсальных параметров нет. На каждом предприятии они свои. И в стандартном Windchill нет ни одного параметра. Эти параметры (24 шт) были добавлены меньше чем за 1 час. Не думаю что то что мы обсуждаем является недостатком Windchill.

В картинке слева вы можете посмотреть информацию о:

- где используется

- Какие можно использовать заменяющие

- и т.д.

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

Эти БД как раз и являются универсальными для занесения любой информации.

На одном из западных предприятий используется следующая схема:

Обозначение - какой то сгенерированный уникальный номер (например 020000000256). Т.е обозначение заносится в одно поле.

Далее имеется ряд параметров, которые характеризуют эту модель и позволяют таким образом классифицировать. Например:

Тип - Деталь типа тела вращения (010), или Плита (020) , и т.д.

Область использования - Нижний мост (110), Кабина (120), и т.д.

и т.д. (Это всего лишь пример)

Может я ошибаюсь, но объясните какая разница

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

или

2 - иметь обозначение, которое состоит из этих параметров отображаемых в числовом виде (010-120-...)

Чем первая схема хуже второй? По моему они одинаковы.

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

Так же могу сказать, что все стандартные и прочие изделия у нас вообще имели безликое обозначение (например 3135463), которое соответствовало коду BaaN. Было неудобно, в дереве ProE обозначения были безлики, но видимо в глобальном масштабе это было выгодно для предприятия.

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

Мне жаль, что Вы плохо представляете как в БД записывается любой состав. Упрощенно это запись обозначения Детали (или другой ДСЕ в т.ч. и сборки или установки) и запись сборки в которую эта ДСЕ входит и количество ДСЕ. Реальный запись состава может иметь большое количество полей (у меня их 80). Вопрос не в количестве. А в том как записывется обозначение ДСЕ: полностью или через ссылки. Записи относящиеся к сборке могут находится в любом месте строки таблицы. Когда они выбираются из таблицы, они сортируются по позиции и другим критериям.

Если обозначение разнесено по полям то можно проводить сортировку по ним. Если вместо записи обозначения есть ссылка на справочник ДСЕ, то сортировки по обозначению провести невозможно. Отсюда и возможности систем. Я согласен, что в принципе в Windchill можно вести разный состав. Но это будет не тот состав, который требуется ERP. Нам нужна простая схема: все составы всех изделий в одной таблице. Связи записей построены по принципу дерева. А дальше дело программы проводить выборку, разузлование, подсуммировку, сортировку. Судя по Вашим замечаниям Вы никогда не работали с АСУшными системами, где надо вводить записи вручную. За Вас это делает Windchill при визуальном прикреплении файлов ProE. Но в файлах часто содержится не вся информация. В спецификациях составов могут присутствовать материалы, изделия, инструменты и др. , используемые при производстве и сборке ДСЕ. Поэтому мы по разному это понимаем. Вы с позиций внешнего механизма работы Windchill, я с реальных позиций конструктора, технолога, производственника и АСУшника, знающего всю внутреннюю кухню информационных систем.

[SVS 1]

Я уже устал это обсуждать и у меня нет на это время.

Мне жаль, что Вы плохо представляете как в БД записывается любой состав.

Мне без разницы как оно там записывает. Мне не зачем знать устройство автомобиля, чтобы ездить на нем. Тем более, что чем новее автомобиль, тем вообще сложно в нем разобраться, а тем более лезть внутрь и что-то там делать. Это не Жигули 80х годов.

Если обозначение разнесено по полям то можно проводить сортировку по ним

У вас как я понимаю обозначение выглядит так:

Поле1=010

Поле2=125

Поле3=256

Это и есть обозначение, состоящее из 3х полей

У меня обозначение выглядит так:

Поле1=010

Поле2=125

Поле3=256

Обозначение=Поле1+Поле2+Поле3

Это и есть обозначение, состоящее из 3х полей + еще одно поле - обозначение, которое равно сумме 3х полей.

Как и у вас так и у меня можно сортировать и фильтровать по любому из этих полей.

Я согласен, что в принципе в Windchill можно вести разный состав. Но это будет не тот состав, который требуется ERP

Почему это будет не тот состав. Где докозательства.

За Вас это делает Windchill при визуальном прикреплении файлов ProE. Но в файлах часто содержится не вся информация. В спецификациях составов могут присутствовать материалы, изделия, инструменты и др. , используемые при производстве и сборке ДСЕ. Поэтому мы по разному это понимаем. Вы с позиций внешнего механизма работы Windchill, я с реальных позиций конструктора, технолога, производственника и АСУшника, знающего всю внутреннюю кухню информационных систем.

А вы что считаете,что в Windchill можно передать информацию только из ProE. Ну ттогда уж точно, сдесь разговор глухого с немым.

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

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

Изучайте Windchill, прежде чем делать поспешные неправильные выводы о системе.

[vladmi 0]

Я уже устал это обсуждать и у меня нет на это время.

Мне без разницы как оно там записывает. Мне не зачем знать устройство автомобиля, чтобы ездить на нем. Тем более, что чем новее автомобиль, тем вообще сложно в нем разобраться, а тем более лезть внутрь и что-то там делать. Это не Жигули 80х годов.

У вас как я понимаю обозначение выглядит так:

Поле1=010

Поле2=125

Поле3=256

Это и есть обозначение, состоящее из 3х полей

У меня обозначение выглядит так:

Поле1=010

Поле2=125

Поле3=256

Обозначение=Поле1+Поле2+Поле3

Это и есть обозначение, состоящее из 3х полей + еще одно поле - обозначение, которое равно сумме 3х полей.

Как и у вас так и у меня можно сортировать и фильтровать по любому из этих полей.

Почему это будет не тот состав. Где докозательства.

А вы что считаете,что в Windchill можно передать информацию только из ProE. Ну ттогда уж точно, сдесь разговор глухого с немым.

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

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

Изучайте Windchill, прежде чем делать поспешные неправильные выводы о системе.

Опять у нас разное понимание состава и способов реализации, использованных в Windchill, TeamCenter, Search . Отсюда вытекают абсурдные предложения, например, одной московской дилерской фирмы заводу Дегтярева с помощью Windchill управлять тем, для чего он первоначально не предназначался, например, ведением технологической документации. Эта фирма предлагает по типу обычной спецификации создать записи спецификаций по техпроцессам (записи операций техпроцессов) и привязать ее к ДСЕ, а к позициям спецификации прикрепить файлы иллюстраций. То есть смешать все в одну кучу и сборки составов и техпроцессы. А как потом различать спецификации в общем составе и вести разузлование с учетом их различий? Фактически предлагают предприятиям рыться в горах мусора. И такие же оторванные от жизни решения предлагаются другими диллерами по созданию каталогов запчастей. Похоже, Вы слабо представляете с чем сталкивается и в своей работе конструктор, технолог на предприятии. И какие нормативные документы он использует. Состав это перечень ДСЕ, входящих в сборку. И все составы сборок записываются в одну таблицу. Между ними выстраивается логическая связь по дереву изделия, зависимостям Деталь-сборка. Кроме этого есть сборки с переменной частью, предусмотренные ГОСТ. Большинство зарубежных систем не поддерживает этого. Необходимо различать и разделять составы: конструкторский, технологичский, призводственный. Содержание каждого состава может менятся. У зарубежных PDM применительно к ДСЕ это называется ревизией. Но к к перечисленным составам это не подходит. ДСЕ, Сборки имеют статус. Активно то, что действующее. Чтобы найти, что применялось раньше надо вручную рыться в составах, а это безнадежное дело. На всех PDM на каждое изменение/ревизию формируется свой состав. Это приводит к резкому увеличению объемов БД. Для одних СУБД это критично. Применяется ссылочный механизм записи состава. Это не самое удачное рещение, создающее массу проблем, в построении информационной системы предприятия. Лет 10 назад я придерживался такого же подхода. Пока не начал разработки всей системы на современных СУБД. И понял преимущества раздельного занесения обозначения, как в справочник ДСЕ, так и таблицу составов, то что на большинстве PDM не применяется. То что PTC, EDS и др. применяют занесение обозначение в одно поле и ссылочный механизм ведения состава связано с отсутствием стандартизации у них в этой области. У каждой фирмы своя система обозначений. Чтобы зарубежные PDM могли работать с таким разнообразием и применяется такой подход. У нас же подавляющее количество предприятий работает по отраслевой системе СССР 70-80 гг., немного переработанной в 2000 гг. Обозначение состоит из 3-х частей (8,7,7 символов). Первая часть на практике 3-8 символов. Переменный характер этого создает проблемы с сортировкой, если записывать обозначение в одно поле. Очень важно иметь возможность сортировки по частям обозначения в т.ч. и сборок. Есть еще ГОСТ-ая система обозначений по технологическому признаку, но применяется реже. На предприятиях при использованию комплектующих производится перекодировании обозначения на свою систему. И эта пратика подтверждена временем. Она идет от фордовской системы 20 гг. Ей пользуется немецкая автомобильная фирма MAN (специлизирующаяся на двигателях, грузовых автомобилях, автобусах). Кроме того многим службам необходимо иметь всю информацию об комплектующих, предприятиях-поставщиках. Необходима реляционная БД по ней связанная с ДСЕ. И все в рамках одной PDM. Я не видел ни одного PDM к которому можно было подключить дополнительную реляционную БД. При рассмотрении продукта оценивается все, а не только узкая его сфера. Пока из-за этих подходов я не вижу особого прока от подобных продуктов. Что-то не получается из-за подобных дилетанских взглядов на интеграцию (см. тему Интригация, Про интеграцию разных мегасистем). Можно решать это проще, постепенно и дешевле и в конце концов выстроить нормально всю последующую систему, если нацелится на CALS.

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

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

[SVS 1]

На всех PDM на каждое изменение/ревизию формируется свой состав. Это приводит к резкому увеличению объемов БД. Для одних СУБД это критично. Применяется ссылочный механизм записи состава. Это не самое удачное рещение, создающее массу проблем, в построении информационной системы предприятия.

Почему это приводит к резкому увеличению? Была сборка А, с ревизией (изменением) 1, (1 Mb), мы провели извещение и получилось сборка А, с ревизией 2. Итого объем увеличился на 1 Mb. Это резкое увеличение?

То что PTC, EDS и др. применяют занесение обозначение в одно поле и ссылочный механизм ведения состава связано с отсутствием стандартизации у них в этой области

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

Чем этот механизм хуже вашего?

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

[vladmi 0]

Почему это приводит к резкому увеличению? Была сборка А, с ревизией (изменением) 1, (1 Mb), мы провели извещение и получилось сборка А, с ревизией 2. Итого объем увеличился на 1 Mb. Это резкое увеличение?

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

Чем этот механизм хуже вашего?

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

Вопрос больше в том, как заносится обозначение в состав. А он в подавляющем большинстве PDM заносится в в виде ссылки на номер записи справочника ДСЕ. При таком подходе невозможны сортировки. Что касается обозначения ДСЕ, то оно формируется на основе требований ГОСТ, ОСТ, а не от балды, что хочу то и запишу. То что Вы можете добавить поля в справочник ДСЕ, это еще не означает возможности варриации в составе. Жаль, что Вы всего этого не знаете.

[SVS 1]

При таком подходе невозможны сортировки

Что касается обозначения ДСЕ, то оно формируется на основе требований ГОСТ, ОСТ, а не от балды, что хочу то и запишу

Если хотите то обозначения ДСЕ будет фотмироваться по какому угодно правилу (ГОСТ, ОСТ, ...)

То что Вы можете добавить поля в справочник ДСЕ, это еще не означает возможности варриации в составе

Вариация в составе - стандартная функциональность, если вы имеете ввиду конструкторский, производственный составы.

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

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

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

Но если бы У меня, как у рукововодителя предприятия, стоял выбор, то я наверное остановился бы на любой системе, которая как минимум имеет определенный бюджет, штат сотрудников, юридические реквизиты, документацию, тех. поддержку и опыт внедрения, хотя бы на нескольких предприятиях, web-адрес, где описана функциональность. При поиске информации о СпрутМ ни одно из этих требований не оказалось, слово "СпрутМ" встречалось в форуме SAPR2K и статьях BelERP.com.

[француз 0]

Вопрос больше в том, как заносится обозначение в состав. А он в подавляющем большинстве PDM заносится в в виде ссылки на номер записи справочника ДСЕ. При таком подходе невозможны сортировки.

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

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

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

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

[evgeny_ch 0]

Скоро прогрессивная общественность будет отмечать 10-летие разработки спрутм.

[Елена 116]

Француз писал:

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

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

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

[француз 0]

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

Учился вроде неплохо, красный диплом дали

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

В прошлом посте я попросил привести пример выборки или сортировки из таблицы состава, для которой НЕОБХОДИМЫ поля "обозначение". Кто нить может такое придумать?

[Елена 116]

Объединение таблиц одной БД - это одно, а когда используете например DBF, SQL и mdb - это другое. Я например не знаю как описать в одном запросе, может подскажете?