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

[француз 0]

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

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

2. таблица состава и таблица ДСЕ находятся внутри ОДНОЙ базы, поэтому ваш вопрос к теме не относится

3. здесь обсуждают ГОТОВЫЕ системы PDM, а не учатся их создавать.

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

[SVB 188]

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

Коллеги, Вы разве не поняли, что для vladmi найти что-то "неправильное" в зарубежных системах — вопрос жизни и смерти. Он будет придумывать "грабли" до бесконечности. Мне он напоминает В. Турту — спеца по CAM- системе всех времен и народов, до которой никто кроме него в мире ещё не додумался. Думаю старожилы помнят его. Его одно время забанили на этом форуме, но он прессингует своей волшебной CAM-системой на форуме www.cad.ru

Схожесть просто потрясающая. Может они какие сводные или двоюрно-троюрные братья?

Ну вот:

Я вовсе не хочу утверждать, что существующие PDM не работают. Они работают, но применительно к своей среде и своему узкому кругу задач.

Мировая CALS индустрия изнывает без СпрутМ. Где-то я уже это слышал — Узок круг их задач, страшно далеки они от народа... Грядет революция!

Можно конечно изощрятся в их применении, но в конечном итоге получится не то, что требуется сейчас.

Ну кто ещё знает, что нужно сейчас!?

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

Свежих — ещё не значит нужных для производства — для МИНИМИЗАЦИИ затрат производителя.

Вот здесь их подходы и неизбежно порождаемые ими проблемы и создают проблемы в построении корпоративных систем.

Вначале автор демонстрирует своё незнание элементарных вещей зарубежных PLM-систем, затем он строит правильные и красиво выстроенные предложения, где утверждает, что разобрался в ПОДХОДАХ этих систем.

То что PTC, EDS и др. применяют занесение...

Автором почему-то вспоминается фирма EDS, которая уже давно рассталась с продуктами от UGS. Да и вообще она была временным владельцем UGS.

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

Во-первых, уже хорошо, что не принуждает приобретать СпрутМ. Во-вторых, какой объём данных у автора остаётся за кадром. Неужели 100 Гигабайт? Тогда — да, 286-е машины захлебнутся... да и где ж такие носители — HDD-взять?

[evgeny_ch 0]

Хорошо засекречен спрутм, перерыл инет - няма.....

Извиняйте, есть его реклама от автора.

Это чтоб шипиен не открутил контрагайку от секретного тягача.

[Елена 116]

<Коллеги, Вы разве не поняли, что для vladmi найти что-то "неправильное" в зарубежных системах — вопрос жизни и смерти. Он будет прибумывать "грабли" до бесконечности.>

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

[SVS 1]

Коллеги, Вы разве не поняли, что для vladmi найти что-то "неправильное" в зарубежных системах — вопрос жизни и смерти. Он будет прибумывать "грабли" до бесконечности.

и в споре узнавать истинные возможности системы

Поэтому если кто-то возьмется подключить в online к приобретенной системе имеющуюся на предприятии и работающию систему, то скорее всего это будут отечественные разработчики

Во первых почему считают что к Windchill нельзя подключить внешнюю базу?

Во вторых не известно где в итоге будет больше проблем.

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

PTC как только зарождалось изначально был упор на создание 3D модели и работы с ней, а потом уже чертеж и т.д. Сам помню, как в конце 90х на моем заводе считалось, что САПР - это чертеж, и на заводе все смотрели на ProE, как на мультики и не воспринимали всерьез. Теперь, вроде как-то предприятия начали к этому привыкать и уже даже ГОСТы есть по 3D объектам (файлам). А некоторые уже представляют или имеют у себя сквозной цикл от детали до ЧПУ.

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

[vladmi 0]

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

И что можно обсуждать с такими специалистами (типа Француза) поколения Pepsi, если они ничего не понимают в этом вопросе и их уровень понимания БД - Аccess и БД с одной (двумя) таблицами. Они могут только кликать и перетаскивать мышкой и применять чужие продукты. Как ребята не садитесь - в программисты не годитесь, если не понимаете элементарных вещей и что Вам преподавали в институте. Для Вас, продающих чужой продукт PDM- он черный ящик и Вы не можете (не пытаетесь) даже понять его логику, структуру БД. И своего опыта разработки подобных систем у Вас, чувствуется нет. Любой специалист по базам данным (FoxPro, SQL) знает гораздо больше и это чувствуется по Елене, которая работает(ла) с разными БД и понимает суть этого. И как раз на заводе лучше видны все проблемы и пути решения. И именно с заводской практики рождались нормальные решения и становились стандартами. Изменено 25 июня 2007 пользователем vladmi

[француз 0]

И что можно обсуждать с такими специалистами (типа Француза) поколения Pepsi, если они ничего не понимают в этом вопросе и их уровень понимания БД - Аccess и БД с одной (двумя) таблицами. Они могут только кликать и перетаскивать мышкой и применять чужие продукты.

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

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

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

А вот разгильдяйство и некомпетентность всяких спецов по внедрению не раз приводила к тому, что всё КБ не один день занималось полной ерундой типа ручного перелопачивания данных. И этой "творческой" работой я сыт по горло.

Поэтому у меня мало уважения к спецам типа вас. Вы пример выборки привели? Я уже в ТРЕТИЙ раз прошу вас это сделать, А вы тут воду переливаете на пару с Еленой, Тоже крупным спецом в программировании, но не умеющим даже цитаты в сообщения вставлять

[Елена 116]

, но не умеющим даже цитаты в сообщения вставлять

Да, с цитатой в быстом ответе что-то не получается. Надо вопрос администраторам задать. Я по-моему Вас не оскорбляла, хотя по-видимому в 2 раза старше.

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

[evgeny_ch 0]

Мы круче яиц, систему разрабатываем. Девять лет пока.

Найдется ли на МЗКТ 1,5-2 программиста (неостепененных)?

Если и были то ушли, не может завод платить около 2 килобаксов в месяц.

Оставшиеся напрягают моск и с умным видом занимаются кипучей деятельностью с КПД=0.

Параллакс однако....

[Елена 116]

Мы круче яиц, систему разрабатываем. Девять лет пока.

Найдется ли на МЗКТ 1,5-2 программиста (неостепененных)?

Если и были то ушли, не может завод платить около 2 килобаксов в месяц.

Оставшиеся напрягают моск и с умным видом занимаются кипучей деятельностью с КПД=0.

Параллакс однако....

У всех свои реалии, может и в Москве можно нанять внедрение PDM-системы, то у нас в провинции нам для того, чтобы дождаться спеца по техподдержке даже инженерных центров (KIP) - ждать приходилось иногда недели (хорошо, что центра два)- когда что-то с механикой случалось, если еще бы и по работе сетей-ПО ждали, да каждый раз командировочные оплачивали. Наши пользователи ждать пока крутые ребята из Москвы приедут разобраться не привыкли. Может и доживем до тех времен. Кто-то из минчан рассказывал, как в Париже в теченее 4-х лет PDM внедряли под ключ. У кого из участников форума что-то похожее сделано? Все будем ждать пока до нас очередь дойдет? А так ради бога,пусть руководство платит, только под ключ, чтобы в чужих кодах не ковыряться.

[evgeny_ch 0]

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

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

У него по слухам райское наслаждение, и никаких налогов.

[Елена 116]

А почему в Минске? Мне до Москвы ближе. А наше руководство о моих проблемах знает. В общем каждый кулик свое болото хвалит.

[evgeny_ch 0]

Тогда это к vladmi.

[vladmi 0]

Тогда это к vladmi.

Мы ушли от темы "Единичное производство и PDM", увлеклись играми в КВН. Надо рассматривать проблемы и решения по теме. Если SVS и evgeny_ch, такие юольшие специалисты, то пусть они предложат как можно занести инфо по составу изделий с единичным производством в Windchill (у которого как и у всех БД используется одна таблица для состава), и дальше как реализовать учет и планирование единичного производства и передаче информации из него в ERP, рассчитанную на серийное производство, к которым относится BAAN, SAP, Omega Production и др. Вариант ревизий прошу не предлагать - это из другой оперы, вариации одного состава. Здесь речь идет о разных по содержанию и назначению составов: конструкторском, технологическом. Фактически предлагаю Вам продемонстрировать возможность изменения структуры этой таблицы средствами Windchill под эту задачу? Изменено 26 июня 2007 пользователем vladmi

[SVS 1]

Если SVS и evgeny_ch, такие юольшие специалисты, то пусть они предложат как можно занести инфо по составу изделий с единичным производством в Windchill (у которого как и у всех БД используется одна таблица для сгостава), и дальше как реализовать учет и планирование единичного производства и передаче информации из него в ERP

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

И можете ли Вы изменить структуру это таблицы?

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

[evgeny_ch 0]

vladmi, придется грубить, а жаль.

Если SVS и evgeny_ch, такие юольшие специалисты

Авторитет специалиста не определяется его степенью и геометрическими размерами, так уж повелось.

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

Если хотите развести свой завод на "научно -исследовательский проект" не охаивайте тупо продукт, сделанный специалистами достаточно известными и успешно действующими на рынке.

Если чего-то не знаете, вежливо спросите, вам вежливо ответят, не нужно этих местечковых понтов.

Ежели вы большой ученый, должны иметь представление об этике.

[nester 0]

Внимательно прочел данные рассуждения

Что значит динамическое подключение других баз данных к системе? (отображение на одной карточке полей из физически разных баз данных, предположим технологическая на ms sql, а конструкторская на oracle) данные поступают из различных систем, предположим T-Flex и SmarTeam соответственно, а потом есть третья система которая для чего-то эти данные объединяет в одно. Или это какой то другой зверь, тогда ЗАЧЕМ это необходимо? Получать различные отчеты и выборки? Зачем если это можно делать с помощью внешних генераторов отчетов или другими способами и методами?

Идея хранить данные в одной системе она замечательна, но НИ ОДИН разработчик не может похвастаться полностью законченным решением, которое охватывает весь жизненный цикл изделия (CALS как Вы его называете) и никогда не будет общей базы данных для всех этих систем (ИМХО), передача необходимых данных - да, но она прекрасно реализуется, и для этого не надо обладать "мегапрограмистами", интеграция между Смартим с 1С:Предприятие была написана 1 человеком в течении 2 месяцев. Системы должны быть узкопрофильными и решать конкретные задачи, попытки написать ВСЕОБЩЕЕ решение еще ни к чему хорошему не приводило.

[Странник 6]

Системы должны быть узкопрофильными и решать конкретные задачи, попытки написать ВСЕОБЩЕЕ решение еще ни к чему хорошему не приводило.

А 4 PDM на предприятии это типа нормально?

Типа один мерку снимает, другой мост ставит, а за дикцию ни кто не отвечает???

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

Сегодня вроде друзья, а завтра кость не поделили и коды поправили каждый в свою сторону.

Пользователю то что делать когда у него всё работать перестанет?

[Елена 116]

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

[Странник 6]

Решение может быть любым при сохранении обязательного условия (выработанного еще много лет назад). Данные вводятся один раз, а использоваться могут разными системами.

Однако системы то развиваются, при чём зачастую вовсе не в ту сторону что нужно.

Как сказал однажды один из власть имущих на поле CAD в России:

мы не обязаны повторять свои старые ошибки

.

Вот и получается, банальная ситуация с погоней малой группы программистов предприятия за 3..4 бОльшими группами программистов из фирм.

1. PDM на CAD.

2. PDM на технологическую часть.

3. PDM на управление производством.

4. PDM на финансы.

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