ЭСИ

[белог 0]

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

По- моему это все таки вопрос "что вперед курица или яйца".

При настройке системы должно существовать ТЗ и т.д. , где прописаны будут набившие оскомину "бизнес процессы" предприятия - вопрос один кто его пишет и что лично ему выгодно...( Простите за уныние , но таковы реалии). А выгоды наверно нужно показывать (на форуме советовали, и правильно) - но не втолковывать же каждому про себестоимость изделия в целом, про оперативность прохождения изменений...???? Кстати себестоимость в российских реалиях вещь очень эфимерная, порой главное Я ХОЧУ.

[cadzero 0]

Тут не совсем понятно. "Целостная модель изделия" - это сборка в системе конструкторского моделирования?

Если это так - это в неё добавляются все сопутствующие не-геометрические данные? Их же помойка целая!

А кто, в таком случае, отвечает за состав? Кто является автором и отвечает за документ "спецификация", который получится автоматическим образом?

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

-Сборка в CAD - целостная модель, хотя в ней могут быть не отражены некоторые элементы изделия.

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

-Группа авторов неспособна создать единый документ? :)

-Групповая работа над одним документом вопрос интересный, но уже неоднократно решенный разными способами.

[AnTe 1]

-Сборка в CAD - целостная модель, хотя в ней могут быть не отражены некоторые элементы изделия.

Ну, не то, чтобы просто "некоторые"... Всевозможные используемые ТУ, к примеру, будут смотреться в CAD-модели, мягко говоря, неуместно...

-Группа авторов неспособна создать единый документ? :)

-Групповая работа над одним документом вопрос интересный, но уже неоднократно решенный разными способами.

Наверное, имеются в виду системы контроля версий? Которые являются подмножеством PDM.

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

Изменено 8 ноября 2011 пользователем AnTe

[AnTe 1]

По- моему это все таки вопрос "что вперед курица или яйца".

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

Реалии ещё хуже: кто вообще его возьмётся писать. Есть такое выражение, с которым я согласен на 100% - "правильно сформулированная задача - это полдела". Кто возьмётся, за такую сложную и затратную работу, как написание качественного ТЗ, на все случаи жизни?

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

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

Да чего далеко с примерами ходить. Вот тут обсуждается небольшой раздельчик из ТЗ на ЭСИ, "что нужно в ЭСИ конструктору?" - кроме как "выяснить информацию о входимости" (что на данный момент обеспечивается другими средствами) - идей не прозвучало :( Если конструктору это не известно - то что говорить об айтишнике-программисте? вот и конец составлению ТЗ! :)

На самом деле такая ситуация для меня не впервой. Ещё на первых этапах, пытаясь составить ТЗ сталкивался с активными конструкторами, которые восторженно принимали мою идею о создании ЭСИ, доказывая, как она им нужна. Только вот стоило мне чуть-чуть конкретизировать их идеи, оказалось, что то, что нужно - просто красявости в представлении, а стоило мне чуть-чуть добавить мысль о том, что, возможно, данные придётся вносить самостоятельно - так и ЭСИ начала превращаться в не столь нужную вещь!

Данные конструктор и сейчас вводит, например, в MechaniCS, чтобы получить спецификацию. Ну очень хотелось им, чтобы данные в ЭСИ попадали самостоятельно :). На худой конец - прямиком из MechaniCS, чтобы данные попали в ЭСИ, и выстроились в дерево, и удивился, когда я рассказал о том, что это в принципе невозможно. Реальность показала, что в том виде, в котором вот вчера ЭСИ перед ним вырисовывалось и вызывало восторг, сегодня оказалось ненужной выдумкой.

А выгоды наверно нужно показывать (на форуме советовали, и правильно) - но не втолковывать же каждому про себестоимость изделия в целом, про оперативность прохождения изменений...???? Кстати себестоимость в российских реалиях вещь очень эфимерная, порой главное Я ХОЧУ.

Как и в моём случае. Конструктор изъявил желание, Я ХОЧУ - иметь ЭСИ. Когда узнал, что ему для этого придётся делать - оказалось, что уже не хочет. И так сплошь и рядом. Хочу - не хочу :)

Вот потому и возникла эта тема. А что реально нужно конструктору, от ЭСИ? Для чего вся эта затея? Есть ли смысл её воплощать, и что готов конструктор, ради этого "заплатить"?

Забегая вперёд, первый взнос оплаты уже определён: за ЭСИ в любом случае будет отвечать конструктор.

Изменено 8 ноября 2011 пользователем AnTe

[cadzero 0]

Всевозможные используемые ТУ, к примеру, будут смотреться в CAD-модели, мягко говоря, неуместно...

Зато вполне уместно будет смотреться ссылка на них.

Или сможете доказать, что ссылка на ТУ должна обязательно вбиваться руками с использованием специальной программы? :)

...Ну очень хотелось им, чтобы данные в ЭСИ попадали самостоятельно :). На худой конец - прямиком из MechaniCS, чтобы данные попали в ЭСИ, и выстроились в дерево, и удивился, когда я рассказал о том, что это в принципе невозможно...

Да ну? Реально в принципе невозможно синхронизировать две реляционные базы данных?

Нда... такого финта ушами в 21-м веке даже от индийских софтописцев ожидать не приходится.

До чего "этот фигляр" (с) Фурсенко довел отечественное образование... :)

Спасибо за полчаса гомерического хохота :)

[AnTe 1]

Зато вполне уместно будет смотреться ссылка на них.

Или сможете доказать, что ссылка на ТУ должна обязательно вбиваться руками с использованием специальной программы? :)

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

...Ну очень хотелось им, чтобы данные в ЭСИ попадали самостоятельно :). На худой конец - прямиком из MechaniCS, чтобы данные попали в ЭСИ, и выстроились в дерево, и удивился, когда я рассказал о том, что это в принципе невозможно...

Да ну? Реально в принципе невозможно синхронизировать две реляционные базы данных?

Нда... такого финта ушами в 21-м веке даже от индийских софтописцев ожидать не приходится.

До чего "этот фигляр" (с) Фурсенко довел отечественное образование... :)

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

Спасибо за полчаса гомерического хохота :)

да тут не смеяться, плакать надо. Фурсенков на рею пора, а народ всё гомерически хохочет над собой. :D

[белог 0]

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

И еще я пользователь и хотела разобраться так ли все красиво как описывают продажники различных ERP и т.д.

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

Наверно я зря здесь слушаю....

[AnTe 1]

И еще я пользователь и хотела разобраться так ли все красиво как описывают продажники различных ERP и т.д.

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

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

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

Когда системы разные - ещё хуже. Вот мой случай, ну написал я получение спецификации из геометрической модели системы Catia. Разумеется, она не полноценна, т.к. в модели дофига чего нет, но теперь и есть дофига чего! И что? Конструктор привычно ляпает сборочный чертёж в AutoCad, с использованием MechaniCS, и тот ему автоматически генерирует спецификацию, нумерует в ней позиции, затем нумерует позиции в чертеже, а в спецификацию закидывает зоны. Спецификация у него готова! Какого ляда теперь ему ЭСИ заполнять? Глянул я в нашу систему документооборота, мама родная! 95% чертежей, спецификаций идут в AutoCad, несмотря на то, что моделируют в других системах.

Создать ЭСИ, с использованием модели и ручным докидыванием необходимых данных - возможно, с этим проблем нет, но кому она будет нужна, эта ЭСИ?

[sceptic 0]

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

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

Конечно, лучше иметь государственную программу, нормальные стандарты, фирмы-разработчики информационных систем и прочее и прочее. Но где же их взять, если кругом Фурсенки, ЕГЭ, модернизация, фронты и борьба за власть. Похоже спасение утопающих..., ну дальше вы знаете.

Создать ЭСИ, с использованием модели и ручным докидыванием необходимых данных - возможно, с этим проблем нет, но кому она будет нужна, эта ЭСИ?

А пока что ДА, никому не нужна, убедил, AnTe.

[Елена 116]

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

Десятки тысяч имеется ввиду уникальных, не стандартизированных деталей.

[lexx174 373]

Создать ЭСИ, с использованием модели и ручным докидыванием необходимых данных - возможно, с этим проблем нет, но кому она будет нужна, эта ЭСИ?

как кому?например смежникам,особенно филиалам.Зачем по старинке кучи бумаг пересылать,когда можно отпраивть электронный состав,где в электронке отражено практически все(модели чертежи + необходимые атрибуты)

[AnTe 1]

как кому?например смежникам,особенно филиалам.Зачем по старинке кучи бумаг пересылать,когда можно отпраивть электронный состав,где в электронке отражено практически все(модели чертежи + необходимые атрибуты)

так свалку электронных документов и сейчас можно отправить, и даже бумажные отсканировать, и в ту же свалку добавить :)

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

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

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

Изменено 9 ноября 2011 пользователем AnTe

[lexx174 373]

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

вообще есть ГОСТ 2.052-2006 ЕСКД(сколько лет назад то уже выпущен?) где как бы узаканивается понятие ЭСИ,то биш передав куда-то электронный состав он будет иметь такой же вес как и бумага.

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

[белог 0]

разговор куда-то не туда пошел...

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

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

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

Для уменьшения времени от "идеи" "до реализации" связать нужно эти два процесса :разработку изделия и подготовку производства в единое целое.

Вот наверно и ответ зачем нужна ЭСИ - без нее никакой связи не будет, и она не может быть нужна отдельно конструктору или технологу или производству - она нужна ПРЕДПРИЯТИЮ в целом для удержания на плаву, для того чтобы расти вместе с потребностями рынка......... (извиняюсь если получилось высокопарно)

[AnTe 1]

вообще есть ГОСТ 2.052-2006 ЕСКД(сколько лет назад то уже выпущен?) где как бы узаканивается понятие ЭСИ

ЭСИ устаканивается в 2.053, а параллельно 2.052 обязательно идут спецификации, и без них никуда не деться. Модели смежники уже давно и успешно вытрясают, особенно зарубежные смежники :)

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

какие проблемы?знаю ряд предприятий которые работают с филиалами/смежниками в электронке.Модель и все остальное к ней есть - вполне устраивает

Я думаю, ключевое здесь "всё остальное к ней" :) тобишь, те же спецификации :)

Всё остальное как нельзя лучше описала белог.

Единственное, что для меня пока остаётся невыясненным:

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

Для уменьшения времени от "идеи" "до реализации" связать нужно эти два процесса

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

разработку изделия и подготовку производства в единое целое.

Вот наверно и ответ зачем нужна ЭСИ - без нее никакой связи не будет, и она не может быть нужна отдельно конструктору или технологу или производству - она нужна ПРЕДПРИЯТИЮ в целом для удержания на плаву, для того чтобы расти вместе с потребностями рынка......... (извиняюсь если получилось высокопарно)

На полном серьёзе, звучит - хорошо. Но ведь наличие ЭСИ, насколько понимаю, принципиально ничего не изменит?

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

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

Положим, ЭСИ создана, в самом лучшем виде. Что при этом принципиально изменится, помимо того, что освободятся, как я приводил пример выше, несколько низкоквалифицированных сотрудников? Или даже так, кому сильно полегчает, от того, что все работают в рамках т.н. "единого информационного пространства"?

Ответ на этот вопрос и будет самым началом создания упомянутого Вами же ранее ТЗ, на систему.

[Елена 116]

"Кто владеет информацией - тот владеет Миром!". Доступ к достоверной информации для принятия наиболее верного решения полезен всем участникам процесса.

[lexx174 373]

ЭСИ устаканивается в 2.053, а параллельно 2.052 обязательно идут спецификации, и без них никуда не деться. Модели смежники уже давно и успешно вытрясают, особенно зарубежные смежники :)

Я думаю, ключевое здесь "всё остальное к ней" :) тобишь, те же спецификации :)

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

[белог 0]

Как было в "бумажном" варианте:

Имея "бумагу" под названием "СПЕЦИФИКАЦИЯ" , так ненавистные конструкторам технологи составляли бумагу, которая в простонародье называлась "РАСЦЕХОВКА" - это и был состав изделия, которым пользовались плановики, экономисты, начальники цехов и т.д., составляя свои "бумаги"

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

Да, ЭСИ дублирует "спецификацию" и еще много "бумаг" но все это до того момента пока предприятие сертифицирует электронный документооборот.

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

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

А СПЕЦИФИКАЦИИ, РАСЦЕХОВКИ , ИНЫЕ ВЕДОМОСТИ -все это мы имеем до поры, до времени

Именно поэтому меня все таки волнует вопрос как связано проектирование в модели и ЭСИ (генерируется ли оно автоматически, и изменяется ли, при изменении модели?)

[AnTe 1]

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

То есть, смысл не в том, чтобы освободить от работы десяток девочек, вбивающих информацию со спецификаций, в АСУП, а в том, что девочки допускают ошибки?

Этот (к слову, незначительный) плюс, который принесёт ЭСИ, я исключил, т.к. допустив несколько ошибок, девочки ещё несколько иногда и находят. Тут "по нулям".

Да, ЭСИ дублирует "спецификацию" и еще много "бумаг" но все это до того момента пока предприятие сертифицирует электронный документооборот.

Что означает "сертифицирует"? Нет такого понятия. И электронный документооборот тут ни при чём: он может крутить электронные документы, являющиеся по сути, бумажными (те же спецификации, но в PDF, отсканированные документы и т.д.). Тут дело в форме документов. Кстати, замену спецификации в ГОСТах никто не указал. 2.053 не в счёт :)

Именно поэтому меня все таки волнует вопрос как связано проектирование в модели и ЭСИ (генерируется ли оно автоматически, и изменяется ли, при изменении модели?)

Для этого нужно сначала определиться, что такое ЭСИ, кому и для чего оно нужно.

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

"Кто владеет информацией - тот владеет Миром!". Доступ к достоверной информации для принятия наиболее верного решения полезен всем участникам процесса.

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

[lexx174 373]

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

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