Форум пользователей ПО АСКОН

При бумажном документообороте времен кульмана процесс разработки строился следующим образом:
конструктор разрабатывает комплект КД (чертежи деталей, чертежи сборок, спецификации) на составные части изделий, согласовывает с заинтересованными лицами и отправляет архив. Процесс разработки полного комплекта КД на изделие может занимать несколько месяцев. По окончании разработки чертежей выпускаются ведомости, например: ведомость покупных, ведомость спецификаций, ведомость держателей подлинников и т.д. Обычно к выпуску данной документации привлекались студенты, которые лопатили документацию и по различным критериям заносили документацию в ведомости. Процедура разработки ведомостей занимала длительное время.
При электронном документообороте с разграничением прав доступа требуется пересмотреть процесс разработки. Казалось бы, при наличии структурированного электронного архива, выпуск ведомостей должен занимать считанные минуты, однако...
...для выпуска ведомостей необходимо снабдить документы и объекты базы данных необходимыми атрибутами, например, указать для заимствованных чертежей держателя подлинника, материал, количество листов, массу детали и пр. и пр.
Кто должен выполнять данную работу?
Если делать так, как было при бумажном документообороте, т.е. дать тому же студенту задачу проставить необходимые атрибуты для некоторых типов документов. Не получается, так как документация утверждена и прав доступа на изменение ни у кого нет.
Если обязать разработчика заполнять необходимые атрибуты, то при этом упадет производительность, так как творческий, требующий высокой квалификации, процесс разработки будет разбавлен рутинной работой указания атрибутов. Комплексное присвоение атрибутов тоже вряд ли поможет, т.к. в процесс разработки вовлечено несколько разработчиков, которые могут выпускать различные по сложности изделия.
"Что делать?" и "Кто виноват?"

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
При бумажном документообороте времен кульмана процесс разработки строился следующим образом:
конструктор разрабатывает комплект КД (чертежи деталей, чертежи сборок, спецификации) на составные части изделий, согласовывает с заинтересованными лицами и отправляет архив. .....

Как это?  :o
  Всю жизнь основным конструкторским документом полного комплекта была Спецификация комплекса, в которую входили всевозможные документы и ведомости, которую разрабатывало Бюро технической документации!!! И только после после ее согласования и утвержден сдавалось в архив.

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

Вы пытаетесь автоматизировать "дремучую" советскую систему документооборота, которая родилась в недрах советской оборонки. Одной из задач указанной системы являлась задача распределения и фиксации зон ответственности различных исполнителей на разных стадиях жизненного цикла изделия. В связи с этим технический документооборот оброс дополнительными атрибутами и документами, отражающих прежде всего систему поиска виноватого в случае чего-нибудь неприятного... Основными документами были и остаются прежде всего чертеж, спецификация, паспорт на изделие и руководство по эксплуатации. Это основные контрольные документы, на базе которых идентифицируется изготовленное изделие как у производителя, так и у потребителя. Все остальное - временные отчеты автоматизированной системы управления жизненным циклом изделия (PLM). Проанализируйте необходимость указанных Вами документов в жизненном цикле Вашего изделия. Так ли необходимо засорять ими архив бумажных документов? Как часто ими пользуются, да и пользуются вообще? Нельзя ли объединисть информацию в различных документах, объединив их в какой-нибудь единый отчет, полученный автоматизированным способом. Особенно умиляет такой документ, как ведомость покупных изделий. В сегодняшнем мире жестокой конкуренции когда возвращаешься к изготовлению изделия 5...10 летней давности сталкиваешься стем, что многих покупных просто нет на рынке (иногда и фирм изготовителей уже нет). Приходится снабжению срочно согласовывать замену. Мне довелось побывать на ряде зарубежных машиностроительных предприятий (в Германии, Италии, Чехии, Болгарии...). Везде я пытался детально изучить внутреннюю систему документооборота, начиная от КД, заканчивая производственной документацией отгрузки. Скажу честно: более замороченной системы, чем российская (советская) ЕСКД я не встречал. Целые подразделения российских предприятий заменяет небольшая группа менеджеров. Большая часть российских машиностроительных предприятий вплотную подошла к необходимости глубокого реинжиниринга, основная задача которого - это разумная рационализация технического документооборота, и соответственно высвобождение людских ресурсов, занимающихся сегодня неэффективной работой. Включите нестандартное мышление и посмотрите на свой документооборот со стороны...

Цитата: YorikER от 27.09.12, 21:29:19
..... Скажу честно: более замороченной системы, чем российская (советская) ЕСКД я не встречал......

Не отчаивайтесь! Еще все впереди, встретите! Это так называемая система межгосударственных стандартов...
Что мы имеем на сегодня/завтрашний день? Изм №8 ГОСТ 2.102  само по себе  :%: А если его рассматривать еще совместно с ГОСТами  2.051 .. 2.053   :cl:

Цитата: YorikER от 27.09.12, 21:29:19
.... Включите нестандартное мышление ....

Вот бы определиться..., и/или со смыслом  ГОСТов, и/или с местом где эта включалка

Поднятая тема напоминает действие ребенка,  который разломал сложную игрушку и теперь пытается её собрать, но ничего не получается и конечно слёзы..
Или « ...мы наш мы новый мир построим..»
Прежде что то ломать, а потом создавать нечто подобное попроще, надо бы сначала понять как это всё работало раньше (по старому).
Не поняв этого ни чего не получиться
И ни какие менеджеры хоть сотня не помогут, не получилось и не получиться, надо знать  (или хотеть) разобраться, что к чему и почему.
Это мы видим по сегодняшнему состоянию промышленности.
По количеству новых Российских изделий, проектов.
И ЕСКД тут не причем.
Как говориться , ...а вы друзья как не садитесь все в музыканты не годитесь...
Может быть я не прав, прошу прощения...

Цитироватьзаменяет небольшая группа менеджеров.

Эх дай бог толковых менеджеров, раньше у нас был отдел снабжения (причем говоря раньше я не имею в виду не 10-20 лет назад, а всего около 3-4 лет) сейчас нет отдела снабжения, за то появился "Департамент инжинеренговых услуг" в простонародье ДИО хотя за частую мы его так и называем "Департамент ИДИОТСКИХ услуг". Раньше не было вопросов сдали документацию и все! было даже такое что снабженцы звонили и говорили - Ребята а вот тут у вас количество на чертеже не совпало с СП либо а сюда эта задвижка не подойдет. Тем самым количество ошибок сводилось фактически к нулю. Сейчас департамент из 15 человек не может выполнить то что делали 5 снабженцев! Они не то что чертежи и СП читать не умеют, они просто приходят и говорят Посчитайте нам количество ЗАДВИЖЕК и распишите где какая. Аргументы типа Есть позиции и в СП все написано не действуют, ответ один мы ваши чертежи не понимаем вы нам напишите сколько чего!
PS: Извините за оф топ

Цитата: tramp_m от 27.09.12, 22:05:33
Поднятая тема ...

:fr:
YorikER! Вы можете предложить что то конкретное взамен ВПИ? И вообще взамен всего "дремучего"?
Стол конечно можно назвать тэйблом, но от этого продуктов на нём больше не станет!

Цитата: tramp_m от 27.09.12, 22:05:33

И ЕСКД тут не причем.

Ну, я бы не согласился с такойкатегоричностью.
Сейчас наряду с межгосударственными стандартами появились национальные, а они имеют приоритет над межгосударственными. Так вот в некоторых межгосударственных стандартах приводится ссылка на другой межгосударственный стандарт, приоритет над которым имеет национальный стандарт, а про национальный стандарт и упоминания нет. Так каким стандартом пользоваться? А ещё появились национальные стандарты, которые являются полным переводом стандартов МЭК, но с отечественной терминологией и самое интересное, что в тексте этого стандарты даются ссылки на действующие стандарты МЭК, но ещё не ставшие национальным стандартом. А вот это уже весело. У нас стандартов очень много, но хотелось бы чтобы их было меньше и в них было бы больше порядка.

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
Не получается, так как документация утверждена и прав доступа на изменение ни у кого нет.

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

Система стандартизации в прошлом строилась на основании и с учетом международных стандартов.
Это очень сложная система кодирования и поиска информации. :)
К сожалению имеет очень слабую компьютерную поддержку и на сегодняшний день подробный поиск по задаваемой теме не совсем поддерживает, да и не совсем открыта для рядового пользователя.
В общем, так же как и патентный поиск, довольно родственные темы. :shu:
Всё это наука, а наука, сами знаете на каком месте у нас ....  :)
А стандартов чем больше тем лучше, значит, больше формализованных (упрощенных) тем мы получили и будем получать. :o
Так же как с чертежами проекта. 8-)
В начале, получаем кучу деталей и лепим из неё сборку. :%:
Потом оказывается, что несколько деталей можно объединить в подузел, и ещё несколько взять Гостовские, другие позаимствовать из предыдущей сборки, а другие просто купить готовые....
Прошу прощения если, что не так... :shu:

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

Цитата: YorikER от 27.09.12, 21:29:19
Вы пытаетесь автоматизировать "дремучую" советскую систему документооборота, которая родилась в недрах советской оборонки.

Именно об этом и речь.

Цитата: YorikER от 27.09.12, 21:29:19
Проанализируйте необходимость указанных Вами документов в жизненном цикле Вашего изделия.

Да, действительно, нет такой необходимости, но ответ найдется в первой цитате: необходимость диктуется заказчиком, который далек от информатизации. Хотя работы по просвещению ведутся от участия заказчика в совещаниях по автоматизации до вопросов подключения заказчика к электронному архиву. Вопрос не лишен политических моментов )

Цитата: YorikER от 27.09.12, 21:29:19
Включите нестандартное мышление и посмотрите на свой документооборот со стороны...

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

Цитата: Николай от 28.09.12, 08:12:34
У нас тоже так. Но, если нужно посадить студента, копируем документацию из архива, делаем необходимую работу и снова сдаём в архив с соответствующим изменением с выпуском извещения об изменении.

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

Цитата: Resfeder от 27.09.12, 22:52:29
:fr:
YorikER! Вы можете предложить что то конкретное взамен ВПИ? И вообще взамен всего "дремучего"?
Стол конечно можно назвать тэйблом, но от этого продуктов на нём больше не станет!

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

Цитата: ben от 28.09.12, 09:00:12
А у нас вообще нет бумажного архива, все документация у кострукторов, а с лоцманом любой отчет на раз два. Плюс есть еще 1С с базой, вот там они сами нужные себе отчеты делают, не напрягая нам мозг.

Если все так хорошо, то как решается поставленная задача по выпуску ведомостей и кто такие "они"?

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
Если обязать разработчика заполнять необходимые атрибуты, то при этом упадет производительность, так как творческий, требующий высокой квалификации, процесс разработки будет разбавлен рутинной работой указания атрибутов.

Владимир Владимирович, современные системы  электронного документооборота (Лоцман, например) давно уже в состоянии автоматически извлекать нужные атрибуты из чертежей и спецификаций. НИЧЕГО РУКАМИ ВБИВАТЬ НЕ НУЖНО, при условии доплаты денег АСКОНУ для настройки программы. У нас все необходимые ведомости (ведомость покупных, материалов) строятся за считанные минуты. Если Вам так сильно нужна эта ведомость держателей подлинников, то ее формирование таже возможно, я уверен, автоматически, при соответствующей настройке программы.

Цитата: Resfeder от 27.09.12, 22:52:29
YorikER! Вы можете предложить что то конкретное взамен ВПИ? И вообще взамен всего "дремучего"?
Стол конечно можно назвать тэйблом, но от этого продуктов на нём больше не станет!

Во как я Вас раззадорил... Уважаемый Resfeder. Я давно уже ничего не предлагаю, а делаю то, что считаю нужным в рамках того бизнеса, в котором работаю. На сайте www.infnt.ru достаточно информации о реально внедренных разработках на действующем машиностроительном предприятии... Несмотря на то, что сейчас я работаю в другой области, по собственной инициативе я не бросаю свои начинания и продолжаю некоторые разработки... Учитывая задачи, которые передо мной стоят, все может пригодится... А что касается моего мнения про ЕСКД и сложившейся в России системе технической подготовки производства, объем информации, который мне пришлось перелопатить и проанализировать, позволяет мне с увереностью так говорить. Думаю, что мне стоит рассказать о посещении машиностроительного предприятия компании EMAG в городе Цербст (Германия) (кстати родина Екатерины II Великой). Я искренне благодарен руководству предприятия за то, что они уделили достаточное время для ответов на мои вопросы и за терпеливое отношение ко мне. А вопросов, поверьте, я задавал очень много. В одном сообщении все не расскажешь, поэтому монолог будет длинным... Да простит меня Администратор...

<irony>Уважаемый Дмитрий22, спасибо за участие в теме, но если Вы внимательно прочитаете сообщение, то вы найдете некий другой смысл, чем тот который Вам показался при первом прочтении.<irony>
Речь идет о том, что в "некоторой" ведомости должны содержаться объекты/документы, которые содержат некий параметр. Так вот этот параметр в самом чертеже не указывается.

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
...для выпуска ведомостей необходимо снабдить документы и объекты базы данных необходимыми атрибутами, например, указать для заимствованных чертежей держателя подлинника, материал, количество листов, массу детали и пр. и пр.

Ну вот не указывает конструктор чьего завода он использует чертеж или не будет он описывать вновь примененный электродвигатель, указывая поставщика, код продукции и пр. Да откройте, в конце концов, ведомости по ГОСТ 2.106 и попробуйте их сформировать, не нагружая конструктора-разработчика и не затягивая процесс разработки изделия.

Цитата: ben от 28.09.12, 09:00:12
А у нас вообще нет бумажного архива, все документация у кострукторов, а с лоцманом любой отчет на раз два. Плюс есть еще 1С с базой, вот там они сами нужные себе отчеты делают, не напрягая нам мозг.

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

Ок, я понял, моя вина, предоставил мало информации.
Лоцман успешно используется на предприятии, работают около 100 пользователей, почти вся КД идет через Лоцман. При этом возникла описанная выше задача, над которой ломали голову внутренние специалисты, также было обращение в Аскон, но пока нет однозначного решения, которое полностью нам подошло.

Цитата: Владимир Владимирович от 28.09.12, 16:16:37

Ну вот не указывает конструктор чьего завода он использует чертеж или не будет он описывать вновь примененный электродвигатель, указывая поставщика, код продукции и пр. Да откройте, в конце концов, ведомости по ГОСТ 2.106 и попробуйте их сформировать, не нагружая конструктора-разработчика и не затягивая процесс разработки изделия.

Судя по всему либо у Вас не настроен справочник покупных изделий на предприятии, либо просто нет понимания как построен электронный документооборот. ДА НЕ ДОЛЖЕН КОНСТРУКТОР ВНОВЬ ОПИСЫВАТЬ ПРИМЕНЕННЫЙ ЭЛЕКТРОДВИГАТЕЛЬ, ЕСЛИ ОНЕГО ОДИН РАЗ УЖЕ ЗАНОСИЛ ИЗ БАЗЫ ДАННЫХ.

Теперь по поводу ГОСТ 2.106 и др. Дело в том, что в Лоцман встроены некоторые отчеты по ГОСТам, но так получилось, что они нас не устраивают, в основном из-за слишком большого количества ненужных для нас граф, поэтому мы заказывали для себя упрощенные варианты отчетов.

Цитата: Владимир Владимирович от 28.09.12, 16:16:37

Уважаемый Дмитрий22, спасибо за участие в теме, но если Вы внимательно прочитаете сообщение, то вы найдете некий другой смысл, чем тот который Вам показался при первом прочтении.<irony>
Речь идет о том, что в "некоторой" ведомости должны содержаться объекты/документы, которые содержат некий параметр. Так вот этот параметр в самом чертеже не указывается.

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

Раз обещал, продолжу... Предприятие производит металлобрабатывающие станки с ЧПУ. Документация на предприятии в Цербсте не разрабатывается, она разрабатывается в головном офисе в другом городе и присылается на предприятие вместе с условиями контракта по электронной почте. Документация в UniGrafics, как 3D, так и чертежи. Спецификации как отдельного документа нет, есть файлы в Excel. А так спецификация на сборочных чертежах, сборочный чертеж - контрольный документ. Если внимательно их  изучить, вы увидите, что разделения на привычные нам разделы просто отсутствуют. Есть неформальная группировка на сборки, детали оригинального изготовления и покупные изделия. Эту документацию принимает к проработке в своем офисе "менеджер по закупкам" (так перевел переводчик). Это, прежде всего, высокооплачиваемый технический специалист высокого уровня, прекрасно знающий технологию машиностроительного производства, а также специалист по снабжению. По нашему снабженец-технолог-расцеховщик, имеющий огромный практический опыт. Указанный специалист вместе со своими двумя помощниками (электрооборудование и автоматика) импортируют полученную информацию в ERP систему (на предприятии используется SAP R3), при этом сразу же формируя в системе производственную спецификацию (по нашему по ЛОЦМАНу "рассыпанную" спецификацию) входящих изделий. При формировании спецификации, менеджер в полуавтоматическом режиме группирует составляющие на сборки, оригинальные детали (требующие изготовления на предприятии) и покупные изделия (стандартные, прочие, материалы).Зарегистрированные изделия в ERP проявляются автоматически, новые оригинальные прорабатываются менеджером. По покупным определяется изготовитель, сроки заказа и стоимость, готовятся контракты на субпоставку, для новых оригинальных определяется заготовка, поставщик, сроки и стоимость заготовки и, также готовятся контракты на субпоставку, сборки отправляются на сборочное производство, где собственно технология сборки определяется руководством сборочного производства (технологов сборщиков просто нет). Таким образом в системе ERP начинает формироваться график Ганта бизнес-процессов изготовления изделий. Фактически группа технологов-снабженцев заменяет целый отделы технической подготовки производства, снабжения и отчасти планово-экономического отделов российских предприятий. Причем на начальной стадии ТПП.

Цитата: Дмитрий22 от 28.09.12, 17:00:41
ДА НЕ ДОЛЖЕН КОНСТРУКТОР ВНОВЬ ОПИСЫВАТЬ ПРИМЕНЕННЫЙ ЭЛЕКТРОДВИГАТЕЛЬ, ЕСЛИ ОНЕГО ОДИН РАЗ УЖЕ ЗАНОСИЛ ИЗ БАЗЫ ДАННЫХ.

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

Цитата: Владимир Владимирович от 28.09.12, 18:26:16
Да с чего вы решили что он уже там есть?вот это как раз тот первый случай
Далее, и справочник есть, но проблема в том, что двигатель нужен прямо сейчас, я позвонил на фирму, узнал что за двигатель и применил у себя в конструкции, не хотелось бы ждать пока его внесут в справочник.

А вот это уже нарушение приказа по предприятию. Внесение объектов ТОЛЬКО через справочник. Не хотите ждать? Внесите сами. 

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

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

Цитата: Дмитрий22
Здесь Вы лукавите, Владимир Владимирович, в первом сообщении вы написали, что вам нужны "держателя подлинника, материал, количество листов, массу детали и пр. и пр." Большинство этих данных можно автоматически извлечь из чертежа. То чего нет, то уж, извольте, чего нет, того нет и может быть.

И опять же, нет чертежа, чужой он (другого предприятия), вот лежит перед конструктором на столе. Здесь общее решение такое:вся сторонняя документация должна первым делом заводится в архив, но имея дело с контрагентами бывает из-за срыва сроков документация поступает с задержкой, здесь мы не можем влиять на другую организацию.
Но а вообще немного съехали с темы. Речь идет о Лоцмане и разграничении сфер ответственности за вносимую информацию в разрезе ограничений,накладываемых PLM

Цитата: Дмитрий22 от 28.09.12, 18:35:16
А вот это уже нарушение приказа по предприятию. Внесение объектов ТОЛЬКО через справочник. Не хотите ждать? Внесите сами. 

А теперь читаем про рутину и творчество

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

Цитата: Владимир Владимирович от 28.09.12, 18:39:23
А теперь читаем про рутину и творчество

Кто кроме Вас лучше всего знает какой электродвигатель нужно занести, какой у него поставщик, какой код? Я не настаиваю, если предприятие имеет специальную девочку которая заносит в БД покупные изделия, то она может заносить. Если она не успевает, наберите 2-х, 3-х девочек, это уже проблемы предприятия. Но все покупные, как и материалы ДОЛЖНЫ ЗАНОСИТЬСЯ ЧЕРЕЗ СПРАОЧНИКИ. Это догма. Это необходимо, чтоб работал электронный документооборот!!!! Поймите. Тогда будет и учет и любые ведомости какие захотите, причем в автоматическом режиме. КСТАТИ, введя один раз в базу электродвигатель, потом Вы можете его использовать вторично, так что здесь справочник, наоборот, помогает в борьбе с рутиной! Думаю, я Вас убедил)))

Далее информация поступает руководителю производства, который организовывает планирование производства в онлайн режиме. Меня с ним познакомили и он по моей просьбе несколько часов водил меня по предприятию и рассказывал о производстве. Передо мной стоял молодой человек лет 30...34, в джинсах и легком свитере. Как мне сказали, он не имел высшего образования. По нашему у него было не оконченное высшее (в Европе двухстадийная система образования). Просто человек показал себя хорошим программистом технологом, аналитиком, был направлен на курсы SAP, блестяще их закончил, поработал производственным диспетчером и в конце концов так проявил себя, что был назначен производственным директором предприятия. На предприятии, ни один специалист никогда не получит руководящую должность, не окончив курсы ERP системы, и не освоив ее в совершенстве... Можно долго рассказывать об этом. Я не видел ни одной секретарши у руководящего состава, кроме помощницы генерального директора, с которым мы беседовали около двух часов. Причем эта помощница выполняла роль табельщицы (контроля за персоналом), вахтера (проверяла наши документы и пропускала нас на предприятие) и много других ролей (в том числе напоила нас кофем). Я не видел ни одного персонального водителя у руководящего состава, нас привез на предприятие коммерческий директор, он же отвез нас назад в Берлин. Я также не видел на предприятии ни одного охранника, но это уже не техническая тема. Результат: на предприятии работает в три раза меньше работников, чем на российском предприятии, на котором я работал, а оборот предприятия в евро был в четыре раза больше нашего предприятия. Сроки изготовления сложнейшего заказа исчислялись месяцами, у нас годами. О качестве мне лучше помолчать. Вывод: при анализе производственной цепочки машиностроительного предприятия сегодня необходимо масимально исключить "человеческий фактор" из технологии производства и рационализировать информационный поток. Так как здесь закопаны серьезные издержки ввиде зарплаты, налогов, брака и ликвидации последствий всего этого. Прежде чем что-то автоматизировать внимательно изучите предмет автоматизации. Если автоматизировать бардак, ничего не получится, кроме автоматизированного бардака... Поэтому прежде чем переходить на выпуск комплекта электронной КД, внимательно изучите необходимость всего комплекта бумажной КД. Так ли все это необходимо заносить в PDM?...

Да, в общем, понятна постановка вопроса о ЕСКД. :)
Всё гораздо проще. ;)
Согласно ЕСКД и чертежи (графическая информация) и спецификации-«ведомости» (текстовые документы) входят в единый состав комплекта проектной документации как единое неразделимое целое. :o
А предлагается всё это разрубить в клочья. 8-)
На примере одного зарубежного предприятия, его СТП- стандартов предприятия (и наверное не противоречащие стандартам приведенной страны), перестроить (переломать) всю систему ЕСКД и стандартизации в целом. :%:
прошу прощения если что не так.... :shu:

Наверно я плохо объяснил, если вы так все поняли. Никто не предлагает разрушить все разом. Для начала просто попробуйте определиться, так ли нужен Вам в реальном производстве весь комплект документации по ЕСКД. Кстати у АСКОНа появилась система управления проивзодством ГОЛЬФСТРИМ. Не задавался ли кто-нибудь из специалистов АСКОНа вопросом, а какие все-таки исходные данные в виде электронной КД необходимы для нормального функционирования системы? Весь комплект ЕСКД, или все-таки его можно существенно сократить... Ведь никто не призывает Вас при этом покинуть рамки ЕСКД, просто существенно их сократить.

Цитата: YorikER от 28.09.12, 18:45:22
..Никаких ведомостей покупных изделий, ведомостей спецификаций и другой мути по ЕСКД не выпускается и не хранится, не хранится, в этом просто нет необходимости. ....

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

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

Мы на пороге революционной ситуации "одни - не могут, другие - не хотят"  .....разобраться или понять ЕСКД  и систему стандартизации. :o
Поэтому начали с разрушения. :shu:
Как в одной знакомой сказке про лисаньку и зайку.... Пусти хоть хвостик в домик. :)
Прошу прощения если не прав.... :shu:

Цитата: YorikER от 28.09.12, 19:35:23
.... При приеме на работу объявляешь всем новые правила игры, кто не хочет просто не берется на борт...

А как быть с Аудитом по сертификации на ISO9000 в вопросах соответствия выполнения требований всевозможных стандартов ( И государственных, и межгосударственных, и международных, и доморощенных)??? 

Цитата: tramp_m от 28.09.12, 19:44:04
...
Поэтому начали с разрушения. :shu:......

В том то и дело, что Систему не разрушали, а свалиливсеводукучунедаваяразяснений

Вот интересно по чьей документации (Российской или Иностранной) проще и какому специалисту, создать новое предприятие. :shu:
В чем это состоят  новые правила игры и во что играем... :)

Первый раз не соглашусь

Цитата: YorikER от 28.09.12, 19:35:23
Сегодня иногда проще с нуля создать новое предприятие, чем перестраивать старое.

Через сколько лет "новое" предприятие станет "старым"?

Цитата: Goran от 28.09.12, 19:50:15
А как быть с Аудитом по сертификации на ISO9000 в вопросах соответствия выполнения требований всевозможных стандартов ( И государственных, и межгосударственных, и международных, и доморощенных)???  В том то и дело, что Систему не разрушали, а свалиливсеводукучунедаваяразяснений

ISO9000 не требует обеспечить соответствие ЕСКД. Стандарт ISO требует наличие дееспособной системы менеджмента качества, а по каким стандартам вы ее будете обеспечивать - ваши проблемы...

Цитата: Алхимик от 28.09.12, 19:52:02
Первый раз не соглашусьЧерез сколько лет "новое" предприятие станет "старым"?

И если оно станет не конкурентоспособным оно просто перестанет существовать... Таковы правила игры и к этому придётся привыкнуть...

Цитата: YorikER от 28.09.12, 20:13:40
ISO9000 не требует обеспечить соответствие ЕСКД.....

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

Изменений, а не соответствия ЕСКД. Не путайте горячее с кислым... Создайте свою корпоративную систему учёта изменений в КД, а самое главное адекватную систему реагирования производственного процесса на изменение и к Вам претензий у аудиторов не будет. Просто Вы опираетесь на ЕСКД и по нему к вам возникают вопросы

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

Чисто гипотетически - да. Не стоит при этом забывать, что Вы работаете не в безвоздушном пространстве. Существуют внешние требования и ограничения. Еще раз повторюсь, никто не призывает отказаться от ЕСКД, предлагается оcтавить в своем документообороте только то, что необходимо Вам для обеспечения Вашего производства, в том числе и обеспечения сертификации по ISO. И если Вы при этом разработаете какую-то свою систему менеджмента качества - флаг Вам в руки...

Вернусь к своему опыту. На предыдущем предприятии мы не сильно придерживались ЕСКД. Ведомостей покупных никто не создавал и не поддерживал, ведомостей спецификаций - тоже. Мало того - мы отказались от простой спецификации ЕСКД, у нас была расширенная - ЕСКД - это позволяет. Мы не придерживались системы литер - О, А, Б и т.д. У нас была одна И - индивидуальное производство. В производство шла так называемая "общая подетальная спецификация", аналогов которой в ЕСКД просто нет. Но на нее было настроено все производство. И никаких претензий у аудиторов института BSI никогда не было. Наоборот, когда мы им представили собственную разработку на ЛОЦМАНе, где был реализован весь этот неескдешный документооборот, но с системой поддержки состояний и изменений КД, нас поставили в пример. В отделе главного конструктора, которым я руководил 5 лет просто не было проблем с сертификацией по ISO 9000

Ну вот, что ж, поздравляю КОМПАС все усилия по переходу на Российские стандарты
были тщетны. :-\
Будем внедрять чужие стандарты. :o
Наплевать всё своё. :`(
Пока не перешли на чужие стандарты, будем работать, кто во что горазд. :)
Во благо менеджменту... :%:
ГОСТ 15.311-90 Система разработки и постановки продукции на производство. Постановка на производство продукции иностранных фирм
...При этом, если перевод на отечественные нормативы ухудшает технические требования, установленные в технической документации фирмы, то нормы и требования фирмы должны быть сохранены без изменений....
2.3.1. Если конструкторская, технологическая и программная документация фирмы оформлена по правилам, отличным от требований стандартов ЕСКД, ЕСТД и ЕСПД, то необходимость и объем ее переоформления в соответствии с требованиями этих стандартов определяет изготовитель с учетом перспективного дублирования производства продукции на других предприятиях, использования документации для дальнейшей собственной разработки продукции, а также с учетом подготовки кадров, степени первоначальной готовности предприятия к производству продукции, и т. п.
Прошу прощения .... :shu:

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

Спасибо за разъяснения. :) Возможно наши аудиторы консерваторы, потому как я уже предвижу аудиторские возражения....
ЕСКД - ЕДИНАЯ система конструкторской документации, и оставлять только то, что необходимо вам....?
Хотя возможно ...если представить "законченный цикл" документооборота всего предприятия, то что-то может и у нас получится.

Вот только интересно под кого будем работать, под одного или под всех сразу. :-)))

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

Цитата: Дмитрий22 от 28.09.12, 18:48:14
Думаю, я Вас убедил)))

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

Цитата: YorikER от 28.09.12, 21:01:02
Вернусь к своему опыту. На предыдущем предприятии мы не сильно придерживались ЕСКД. Ведомостей покупных никто не создавал и не поддерживал, ведомостей спецификаций - тоже. Мало того - мы отказались от простой спецификации ЕСКД, у нас была расширенная - ЕСКД - это позволяет. Мы не придерживались системы литер - О, А, Б и т.д. У нас была одна И - индивидуальное производство. В производство шла так называемая "общая подетальная спецификация", аналогов которой в ЕСКД просто нет.

А были ли при этом у вас заказы для МО РФ?

Если мы говорим о Лоцмане на нашем предприятии, то при подготовке производства мы отказались от ненужных ведомостей, для некоторых задач готовим свои отчеты, для других выбрасываем данные непосредственно из Лоцмана в 1С( но это пока незаконченный проект) Да, у нас конечно не SAP, но best practic стараемся использовать и меняем процессы подготовки.
А задача с ненужными ведомостями пока существует, да и будет существовать по некоторым долгосрочным проектам, так как перечень документации разрабатывается и согласовывается именно сейчас и их придется делать по этим проектам года через 2

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

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

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

Цитата: YorikER от 29.09.12, 14:45:22
Увеличение трудоемкости при автоматизации процесса - проблема постановки задачи с самого начала.

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

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

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

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

На моем предприятии нет Лоцмана и нет других продуктов АСКОН кроме Компаса. И чтобы не тратить лишние деньги конструктор бы в ручную рисовал СП.

Другое дело что при покупке Лоцмана и компаса СП, как бы автоматически перестраивалась.

Выше вы оговорили еще 2 фактора на которые электронная система не влияет:
- психологический;
- распределение ответственности.

К примеру на моем предприятии ничего не вынесишь, но про другое предприятие говорили один сотрудник за услугу выносил спирт через проходную другого завода. На вопрос почему охранники не останавливают ответила: "За спирт отвечаю Я, а не охранник".

"На "западе" все легко украсть, но только один раз" (препадователь ДонНТУ).
Похожая аналогия "Все грибы съедобны, но некоторые только один раз".

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

Цитата: YorikER от 30.09.12, 15:08:47
И в том и в другом случае можно поиметь проблемы с увеличением трудоемкости... Реинжиниринг необходимо делать не вследствие автоматизации, а рассматривать его как постоянный глобальный процесс рационализации информационных, производственных и финансовых потоков. Либо это должно быть вменено в обязанности линейного руководящего персонала, либо должна работать группа аналитиков с широкими полномочиями на постоянной основе. Цель постоянное снижение издержек. Таковы законы бизнеса.

Не могу не согласиться, все верно

Цитата: YorikER от 30.09.12, 15:54:01
Будучи начальником КБ, я внедрил базовый функционал ЛОЦМАНА, но далось мне это силовым методом. Через год отчаянной эксплуатации, мы решили переработать идеологию работы с PLM системой. В клиенте ЛОЦМАНа был разработан редактор спецификации по ЕСКД со всеми удобными "фишками" СУБД (автопоиск, автозаполнение, копировать, вставить и т.д.). Я перевел конструкторов на разработанный редактор и все вопросы к моему удивлению отпали. Конструктор, выполняя привычную ему процедуру составления спецификации работал НЕПОСРЕДСТВЕННО в PLM. При этом незаметно в полуавтоматическом режиме заполнял необходимые для дальнейшей переработки информации атрибуты объектов спецификации.

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

Цитата: YorikER от 30.09.12, 15:54:01
Конструктору было запрещено составлять спецификацию в КОМПАСе, объекты спецификации в КОМПАСе были отключены

Что в этом случае было предложену конструктору взамен для связи объектов сп с позициями на сборочном чертеже? Объекты сп были отключены средствами Компаса?

Цитата: YorikER от 30.09.12, 15:54:01
Надо отдать должное АСКОНу - они разработали хороший продукт КОМПАС с широкими возможностями, следуя текущим запросам рынка. Однако в стратегическом плане, на мой взгляд, допустили серьезную ошибку....
Через год отчаянной эксплуатации, мы решили переработать идеологию работы с PLM системой. В клиенте ЛОЦМАНа был разработан редактор спецификации по ЕСКД ... Я перевел конструкторов на разработанный редактор и все вопросы к моему удивлению отпали. Конструктор, выполняя привычную ему процедуру составления спецификации работал НЕПОСРЕДСТВЕННО в PLM. ...
Внедрение системы во всем отделе прошло довольно-таки легко...

Цитата: Владимир Владимирович от 30.09.12, 21:54:03
Первую итерацию внедрения запустили строя работу от Компаса, тем самым наладили конструкторов на восприятие недружелюбного интерфейса Лоцмана. Да были проблемы, вызванные скорее незнанием функционала компаса, но подружили конструкторов с Лоцманом (правда не до конца). Теперь постепенно переводим на работу от Лоцмана, постепенно отбрасывая ранее привычные приемы разработки КД в компасе.

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

Цитата: СВ от 30.09.12, 23:33:06

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

Внедрение Лоцмана вызовет изменение процессов проектирования, естественно будут противники, возможен саботаж и итальянская забастовка, да будут разногласия между подразделениями, так как будет пересмотр сфер ответственности. Но это естественный путь развития, если не начать сейчас, то либо вас закроют как не рентабельное предприятие, либо спустят внедрение системы сверху, могут в этом случае не прислушаться к мнению непосредственных участников процесса.
Низкая квалификация персонала-не помеха, вспомните как вы переходили от бумаги к CAD системе-тоже многие говорили о низкой квалификации, однако, те кто идет в ногу с прогрессом останутся на борту, остальные-прочь!
А для успешного внедрения необходимо обратиться к международному опыту и, так называемым, факторам успеха:
- участие руководства в проекте внедрения
- реализация плана внедрения, т.е. он должен быть и должен соблюдаться
- должны быть сформированы реальные цели: например, не "повышение производительности", а "сокращение издержек при проектировании новых изделий на X% за счет ..."
- качественно подобранная команда внедрения, состоящая из специалистов разных подразделений, также требуется привлечение специалистов со стороны вендора

Цитата: YorikER от 30.09.12, 15:54:01
Однако в стратегическом плане, на мой взгляд, допустили серьезную ошибку. СПЕЦИФИКАЦИЯ - является объектом системы PLM, но никак не CAD продукта. Каждый продукт должен заниматься свои делом.

Кроме того, насколько я понимаю, идет развитие Компаса в сторону PDM, появление в 13 Компасе функционала по отчетам, как бы намекает. Позиция Аскона в этом случае понятна и не осуждается. Хотя, логичным было бы развивать именно взаимодействие Лоцмана с CAD, а именно работа от Лоцмана.

Цитата: Владимир Владимирович от 30.09.12, 21:58:41
Что в этом случае было предложену конструктору взамен для связи объектов сп с позициями на сборочном чертеже? Объекты сп были отключены средствами Компаса?

Если я все правильно помню, мы отказались от объектов спецификации в чертежах и 3D моделях, для автоматического построения спецификации при подключении чертежей. Они просто мешались. Собственно сп состоит из объектов спецификации, которые вы можете вручную набрать и связать с позициями на чертеже. Зоны проставятся автоматически. Такую спецификацию создавал написанный нами клиент ЛОЦМАНа после набора ее конструктором непосредственно в СУБД и дальгейней интеграцией ее в КОМПАС как отчет. Далее конструктор привязывал позиции и все оформлялось как обычно. Чтобы долго не объяснять, загляните сюда: http://www.infnt.ru/CloudPDM/CloudPDM1.html на последней странице публикации выставлен дистрибутив облегченной версии альтернативного клиентского приложения для ЛОЦМАН:PLM (аналог того, о котором я рассказывал выше). Пример разработан специально для демонстрации работы с ЛОЦМАНом в "облаках" (или в удаленном доступе к серверу приложений в "облаках" через Интернет). Сервера приложений и баз данных находятся на виртуальном сервере одного из российских хостингов. Редактор спецификации непосредственно в ЛОЦМАНе представлен там достаточно подробно. Внимательно прочтите требования к настройкам сети. По умолчанию запуск клиента будет осуществляться от имени пользователя, для которого все доступно "только для чтения". Если будет желание попробовать поработать - пишите - организуем доступ...

Получается, спецификация, к которой все так привыкли, формируется по запросу из БД Лоцмана как один из видов отчётов?

Да, а формирование ее в клиентском приложении ЛОЦМАНа. При регистрации в Лоцмане нового документа типа Спецификация для объекта типа Сборочная единица создается файл спецификации КОМПАСа на базе зарегистрированного в ЛОЦМАНе шаблона, в который заносятся все данные из СУБД. Далее файл просто распечатывается на бумажный носитель...

Цитата: YorikER от 01.10.12, 15:48:29
Да, а формирование ее в клиентском приложении ЛОЦМАНа. При регистрации в Лоцмане нового документа типа Спецификация для объекта типа Сборочная единица создается файл спецификации КОМПАСа на базе зарегистрированного в ЛОЦМАНе шаблона, в который заносятся все данные из СУБД. Далее файл просто распечатывается на бумажный носитель...

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

Цитата: YorikER от 01.10.12, 14:18:51
Если будет желание попробовать поработать - пишите - организуем доступ...

Да, спасибо, надо обязательно посмотреть, чуть попозже...

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

1.   Хранить файл  спецификации вместе с файлом сборочного чертежа. Ибо надоели частые (из версии в версию) сообщения системы о рассогласовании см. скрин (особенно, когда открываешь чертежи, либо спецификации из Лоцмана).

2.   Объект спецификации в Лоцмане не удалять. В этом объекте хранить спецификацию, сформированную ПО СОСТАВУ ИЗДЕЛИЯ. Именно эта спецификация пойдет в печать и на утверждение гл.конструктору. Если изменится состав в спецификации сборочного чертежа, то конструктору придется перестроить состав в Лоцмане, иначе спецификация ПО СОСТАВУ не изменится!

3.   Развертывание комплекса сделать максимально простым. Чтобы справочники автоматически встраивались в комплекс, интегратор Лоцмана строил ВЕРНО состав по спецификации (включая БЧ детали) оформленной по ЕСКД, материалы отображались не в виде иероглифов, а на понятном языке СРАЗУ ПОСЛЕ РАЗВЕРТЫВАНИЯ КОМПЛЕКСА.

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

Хотелось чтобы меня услышали на самом верху, ибо изменения слишком серьезные. На форуме к Александру Владимировичу я подойти постеснялся :um:

Цитата: YorikER от 01.10.12, 15:48:29
Да, а формирование ее в клиентском приложении ЛОЦМАНа. При регистрации в Лоцмане нового документа типа Спецификация для объекта типа Сборочная единица создается файл спецификации КОМПАСа на базе зарегистрированного в ЛОЦМАНе шаблона, в который заносятся все данные из СУБД. Далее файл просто распечатывается на бумажный носитель...

Как то все громоздко.
Похоже на попытку дотянуться левой рукой до правого уха за головой.
Чем не устраивает Спецификация по форме ЕСКД, ведь это и есть ОТЧЕТ по составу Сборки, в Компасе такая есть.
Ведомости – ОТЧЕТЫ по материалам, комплектующим и т. д., так же.
Как то масло масляное «При регистрации в Лоцмане нового документа типа Спецификация для объекта типа Сборочная единица создается файл спецификации КОМПАСа на базе зарегистрированного в ЛОЦМАНе шаблона»
Чего огород городить?
Наверное, есть какая-то целесообразность в этом.
Прошу прощения если. что не так...

Я уже писал выше, что если рассматривать выпуск КД как конечный бизнес-процесс - то КОМПАС - просто пять баллов... Сформировали, распечатали, подписали и в путь... Если после разработки КД стоит еще и производственно-технологический бизнес-процесс, то дальнейшим процедурам нужна структурированная информация в СУБД (PLM, ERP и т.д.). Передача информации из КОМПАСа в СУБД - дополнительная процедура по сравнению с бумажным процессом, в котором может потеряться достоверность этой информации для производства (особенно при проведении изменений). Также часто размываются вопросы ответственности за актуальность данной информации на текущий момент. Грубо говоря, кто будет нести ответственность за ошибки, которые всплывут в производстве, если КД выпускает конструктор, а информацию в производственный блок системы вбивает нанятый студент. Студент ошибся в количестве узлов, поставил не 1, а 10. Издержки в производстве возросли в 10 раз. А на финише выясняется, что для данного заказа требуется всего один узел. Таких вопросов, мы поимели очень много на всех стадиях производственной цепочки. Поэтому в даном случае правильнее конструктору предоставить рабочее место в СУБД, и формировать спецификацию сразу же в системе, а не в КОМПАСе. А та "золотая" фраза, которая Вам не понравилась - это просто системное описание процедуры создания отчета-спецификации в специальном клиентском приложении для специалистов-аналитиков по ЛОЦМАНу. Звучит сложно, на деле нажатие одной кнопки (вернее выбор одного пункта меню)...

Цитата: YorikER от 04.10.12, 07:52:44
...Также часто размываются вопросы ответственности за актуальность данной информации на текущий момент....для специалистов-

Вот, мы плавно выходим на основную проблему ( необходимо законодательно определить приоритет электронной документации перед бумажной)

Цитата: Goran от 28.09.12, 19:30:33
... Таким образом ЭСИ должна считаться основным конструкторским документом -архивным экземпляром, а вот бумага в лучшем случае может соответствовать уровню -контрольного экземпляра. ...

решение которой, снимет ряд вопросов и упростит взаимопонимания проектировщиков и производственников

Полный комплект (корректно составленный) проектной документации и есть СУБДД для инженера проектировщика и не важно в бумажном или в электронном виде. :shu:
Только он имеет право на её сопровождение, изменение и больше ни кто. >:(
Если в комплект начинают вмешиваться сторонние силы, то от СУБДД не останется камня на камне. :%:
Вот тогда и начнется кто против кого. :x:
И вопрос электронная или бумажная потеряет актуальность воооще. :)
прошу прощения :shu:

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

Цитата: YorikER от 04.10.12, 09:26:01
Об этом я также выше писал: .... переносить задачи в электронный вид.

Я о другом....,  необходимо четко разделить приоритеты: что считать ОСНОВНЫМ конструкторским документом !!!
ГОСТы и прежде неоднозначно понимались, а вот изм№8 для ГОСТ 2.102 - ВАЩЕ! А еще вкупе с ГОСТами 2.501...2.503. - ПОЛНАЯ ...!
"Любое событие - это ж...а, полная ж...а - это комплеск мероприятий."

Цитата: tramp_m от 04.10.12, 09:00:21
Только он имеет право на её сопровождение, изменение и больше ни кто. >:(

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

Цитата: Goran от 04.10.12, 08:07:53
... Таким образом ЭСИ должна считаться основным конструкторским документом -архивным экземпляром, а вот бумага в лучшем случае может соответствовать уровню -контрольного экземпляра. ...

По поводу электронной структуры изделия (ЭСИ), этот документ является обязательным согласно ГОСТ 2.102 с изм. 2006 года, и именно он является отправной точкой для придания статуса электронным документам.

Цитата: Goran от 04.10.12, 09:44:05
Я о другом....,  необходимо четко разделить приоритеты: что считать ОСНОВНЫМ конструкторским документом !!!
ГОСТы и прежде неоднозначно понимались, а вот изм№8 для ГОСТ 2.102 - ВАЩЕ! А еще вкупе с ГОСТами 2.501...2.503. - ПОЛНАЯ ...!
"Любое событие - это ж...а, полная ж...а - это комплеск мероприятий."

Всю неоднозначность снимаем внутренним СТП

Цитата: Владимир Владимирович от 04.10.12, 10:21:00
...По поводу электронной структуры изделия (ЭСИ), этот документ является обязательным согласно ГОСТ 2.102 с изм. 2006 года, и именно он является отправной точкой для придания статуса электронным документам.

Не именно!
Читайте внимательно фраза "и/ или" Вам ни о чем не говорит? Проблема в том, что отправных точек для придания статуса две!!! Вот если бы было "или/или" стало бы проще. В идеале ЭСИ -должен быть основным документом вместо СП, и электроная модель детали вместо чертежа детали.

Цитата: Владимир Владимирович от 04.10.12, 10:22:13
Всю неоднозначность снимаем внутренним СТП

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

Цитата: Goran от 04.10.12, 10:38:28
Не именно!
Читайте внимательно фраза "и/ или" Вам ни о чем не говорит? Проблема в том, что отправных точек для придания статуса две!!! Вот если бы было "или/или" стало бы проще. В идеале ЭСИ -должен быть основным документом вместо СП, и электроная модель детали вместо чертежа детали.  Я и говорю, что созрела необходимость в установлении приоритета электронного документооборота (законодательно и однозначно), к которому должна быть привязана "бумажная" документация для "отсталых" организаций.
СТП - локальное решение, на мой взгяд обязательные правила должны быть общими для всех.

Про какое "и/или" вы говорите?

Цитата: Goran от 04.10.12, 10:38:28
Я и говорю, что созрела необходимость в установлении приоритета электронного документооборота (законодательно и однозначно), к которому должна быть привязана "бумажная" документация для "отсталых" организаций.
СТП - локальное решение, на мой взгяд обязательные правила должны быть общими для всех.

Обязательные правила вам уже предложило государство в виде изменений к ГОСТам 2006 года. Плохие они или хорошие, но они есть. Адаптируйте эти требования для себя. По ГОСТ 2.053 п.6.1 "Номенклатуру, техническое содержание и соответствующую ему модель данных ЭСИ, устанавливает разработчик..." Вот это и закрепляем СТП для внутренних нужд и, при необходимости, дополняем в ТЗ, если есть различные ЭСИ у контрагента/заказчика.
В чем неоднозначность?

Цитата: Владимир Владимирович от 04.10.12, 11:01:20
Про какое "и/или" вы говорите?
......
В чем неоднозначность?

Неоднозначность заключается в возможности существования одновременно двух основных документов.
И вот эту самую возможность и предоставили государства подписавшие этот документ.
И/ИЛИ (см. вложение)

И что вам мешает? Если есть и/или, значит трактуем в удобном для нас виде в СТП. Принимайте за основной документ тот, который вам необходим, основываясь на бизнес-требованиях. А если мы говорим про межведомственное взаимодействие, то нам в любом случае ЭСИ согласовывать с другим предприятием, будь тут "и" или "или". Не вижу здесь проблемы.

Да, посмотрите, что получается. :)
Проектная документация превращается не в документы, а в картинки 3D электронное их (изделий) отображение. :%:
Картинка 3D правилам черчения не подчиняется (ЕСКД не нужно) и становиться главным элементом проекта. :o
Проект получается – электронный альбом с картинками. :-)))
Это уже не проектный документ, а так рисунок на промакашке. :shu:
А, мы смеёмся над ЕГЭ Школьников. :)
Да мы уже давно там оказались. :shu:
Скоро кубики рисовать будем. 8-)
Прошу прощения... :shu:

Цитата: Владимир Владимирович от 04.10.12, 12:19:37
И что вам мешает?...

Лично мне ни что не мешает! Я уже высказывался на тему, что безболезненной автоматизации поддается однозначно понимаемый процесс.
Если конструктор при проектировании будет обязан выпускать и СОПРОВОЖДАТЬ только электронную документацию на основании которой можно дополнительно при необходимости выпустить "не основную" бумажную (которая будет актуальна на момент выпуска) - это одно, если конструктор может (ссылаясь на ГОСТ) выпустить только бумажную (а тем более смешанную) апеллируя к  преусловутому "и/или" будут возникать различные непонимания, трения и как следствие их разрешения принудительные меры воздействия.

Цитата: tramp_m от 04.10.12, 12:40:18
Да, посмотрите, что получается. :)
Проектная документация превращается не в документы, а в картинки 3D электронное их (изделий) отображение. :%:
Картинка 3D правилам черчения не подчиняется (ЕСКД не нужно) и становиться главным элементом проекта. :o
Проект получается – ...

Вы не до конца ознакомились с ГОСТами 2.051...2.053! Это как раз стандарты ЕСКД. В которых оговариваются требования предъявляемые к ЭСИ и ЭМД. Кстати пока в Компасе без бубна реализовать все эти требования весьма проблематично.

Приведу еще один пример из своей более чем 27 летней конструкторской практики... Заказчик совершил досадную ошибку в исходном техническом задании. Один параметр был неправильно описан. Конструкторы спроектировали, согласовали с Заказчиком документацию, предприятие изготовило, поставило и смонтировало оборудования (ориентировочная стоимость контракта 100 млн. рублей). При пусконаладке один из сдаточных параметров не достигается. Заказчик не разобравшись в чем дело оформляет официальную претензию на 10% от суммы контракта и подает в арбитражный суд. Арбитражный суд никакие ЭСИ и ЭМД просто не принимает к рассмотрению. Мы смогли отстоять свои интересы только благодаря тому, что в нашем делопроизводстве сохранились: бумажный экземпляр Приложения №1 к договору - Техническая часть договора с подписями обеих сторон на каждой странице (необходимая страница Заказчиком была подменена - но на ней не было подписи нашего представителя, суд не принял ее к рассмотрению), бумажный экземпляр КД, согласованный Заказчиком (подпись представителя Заказчика на каждом чертеже) и подписанные обеими сторонами акты приемки оборудования, монтажа и приемочных испытаний. После того, как я прошел всю эту процедуру (не дай бог кому это повторить), я забыл об ЭСИ и ЭМД, как о юридически значимых объектах. Юридическую силу в нашей стране имеет только информация на бумажном носителе с подписями и печатями. И долго еще так будет. ЭСИ и ЭМД могут иметь только справочный характер, и при этом одновременно нести основную информационную нагрузку при производстве изделия в замкнутом пространстве предприятия. Но когда на более высоком уровне начинаются разборки полетов связанные с издержками производства, поверьте личному опыту, подписанная и лежащая в архиве бумажка никода не помешает вашей "пылающей тыльной части".

Цитата: Goran от 04.10.12, 13:04:56
.Вы не до конца ознакомились с ГОСТами 2.051...2.053! Это как раз стандарты ЕСКД. В которых оговариваются требования предъявляемые к ЭСИ и ЭМД. Кстати пока в Компасе без бубна реализовать все эти требования весьма проблематично.

Да прошу прощения.
Конечно, я не против и 3D очень удобная для проверки задумок.
Просто попробовал немного пофантазировать и представить, что будет если...
Погорячился виноват....

Цитата: YorikER от 04.10.12, 13:44:22
.... Но когда на более высоком уровне начинаются разборки полетов связанные с издержками производства, поверьте личному опыту, подписанная и лежащая в архиве бумажка никода не помешает вашей "пылающей тыльной части".

Я, лично, сторонник бумаги!!! Но готов переменить свои взгляды на электронную при условии одназначности и определенности для всех в равной степени.
Просто в данной теме, мы постоянно шарахаемся от края к краю.
Моя мысль заключается в следующем - при узаканивании (на межгосударственном/государственном уровне) однозначного в понимании и применении электронного документооборота для всех субъектов деятельности (в том числе и правовой) вопросов автоматизации процесса будет гораздо меньше и внедряться будет без насилия.
Самый главный вопрос (ГОСТ 2.102) создавшегося положения - это вопросы непонимания возникающие при проверке нормоконтролем (без которого по ЕСКД, в архив документы не сдаются) что является основным документом при совместном производстве? Или кто в кого входит или содержит, структура вложенности? Ну и соответственно степень ответсвенности за актуальность.

Цитата: tramp_m от 04.10.12, 13:53:22
....Конечно, я не против и 3D очень удобная для проверки задумок.
...

Электронная модель детали - это не только 3D модель изделия, это еще указанные тех требования, допуски форм и расположений   и пр. и пр. Не поленитесь, полистайте новые стандарты.... Я лично в этой "каше" запутался окончательно.
Хотя осознаю, что "назрело время воткнуть пылающий факел знаний, в немытую тыльную часть невежества"     

Цитата: Goran от 04.10.12, 14:14:12
Самый главный вопрос (ГОСТ 2.102) создавшегося положения - это вопросы непонимания возникающие при проверке нормоконтролем (без которого по ЕСКД, в архив документы не сдаются) что является основным документом при совместном производстве? Или кто в кого входит или содержит, структура вложенности? Ну и соответственно степень ответственности за актуальность.

Ну так определите для начала, хотя бы для себя, что у вас является основным документом. Мы для себя определили, описали ЭСИ ну или вашими словами:

Цитироватькто в кого входит или содержит, структура вложенности

, закрепили ответственность. Следующий этап выводим на межведомственное взаимодействие (для своих заказчиков/контрагентов). Кстати СТП, ТЗ, договора, которые ссылаются к ЭСИ, ведем на бумаге с чернильными подписями и печатями. Тем самым оставаясь в юр. поле.
PS Я отдаю себе отчет в том, что не все так безоблачно, как написано.  :)

Цитата: Владимир Владимирович от 04.10.12, 14:42:57
Ну так определите для начала, хотя бы для себя, ...
... не все так безоблачно, как написано.  :)

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

Цитата: Goran от 04.10.12, 14:14:12

Цитата: Goran от 04.10.12, 14:14:12
 

Электронная модель детали - это не только 3D модель изделия, это еще указанные тех требования, допуски форм и расположений   и пр. и пр. Не поленитесь, полистайте новые стандарты.... Я лично в этой "каше" запутался окончательно.
Хотя осознаю, что "назрело время воткнуть пылающий факел знаний, в немытую тыльную часть невежества"    

Не буду лениться, присылайте список новых стандартов, попробую разобраться в этой «каше».
И что вы в ней ищете.

Новые стандарты во вложении.  Вот ссылка на ГОСТ 2.102 с изм 8 (http://xn--l1a)
Разъясните для начала как все должно выглядеть и как это сочетать с ГОСТами 2.501...2.503 оговаривающие  учет, хранение и правила внесения изменений? Потом (если с этими будет прослеживаться какая нибудь определенность) будем определяться с ГОСТами на эксплуатационную документацию.

PS:Лично я слабо представляю как вообще возможно автоматизировать то, окончательного понимания цельности/законченности которого еще не сложилось.

Создание новых форм документов с названием электронные только перегружает и без того достаточно большой состав проектных документов (речь не идет об упрощении документооборота, скорее всего наоборот), это бледная попытка дистанцироваться от стандартов СССР и в том числе от ЕСКД.
Скорее всего ход дипломатический времен переходного периода и создан в попыхах.
Без понимания основных задач и целей Стандартизации в промышленности ( как теперь говорят экономики) страны.
Это хорошо иллюстрирует ГОСТ 2.053-2006 по отношению к ГОСТ 2.101-68, .......ГОСТа 2. 503-90 и т.д.
И название международный стандарт звучит громко.
А если взглянуть количество и состав международности, то выясняется это страны бывшего СССР не более т.е. зоны действия ГОСТ  стандартов СССР.
И чего спрашивается...
Предлагаю вернуться к формам ЕСКД и в том числе ГОСТа 2. 503-90, что по крайней мере возможно продолжение в том же русле.
Ведь соблюдены же ГОСТы в КОМПАСе по оформлению (исполнению) чертежа, спецификации...
Хотя бы на этапе создания группы этих новых Стандартов дополнительных громоздких, запутанных так называемых электронных документов.
Как говориться улита едет.
Вот примерно так на первый взгляд.
А, как все должно выглядеть и как это сочетать с ГОСТами 2.501...2.503 оговаривающие  учет, хранение и правила внесения изменений в следующем послании.
Прошу прощения.
Может быть не прав...

Цитата: tramp_m от 04.10.12, 20:10:13
Создание новых форм документов с названием электронные .......

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

Да, но к ГОСТам 2.501...2.503 появились ГОСТы 2.511.2011 и 2.512.2011, а также 2.611.2011 и 2.612.2011. Кроме того есть электронная подписть на документацию по ГОСТ Р 34.11-94 Информационные технологии. Криптографическая защита информации. Функция хэширования.

Цитата: Goran от 04.10.12, 15:05:49
Для себя не проблема. Проблема в другом, мне необходимо объяснить для связки конструктор-нормоконтроль-архивариус как должен быть оформлен (выглядеть) документ предположим СП при одновременном наличии чертежа детали и ее электронной модели, их взаимную вложенность, систему внесения изменений и т.п.

Электронная модель, чертеж со всеми необходимыми атрибутами, связями, вложенностями, связями с извещениями и пр. являются объектами ЭСИ. А СП как содержала перечень документации, чертежей, ПКИ так и пусть их и содержит, и, кстати, получаться она должна из ЭСИ отчетом как и прочие ведомости.
Нормоконтроль должен проверят "правильность" построения ЭСИ, часть из фнукций нормоконтроля нужно автоматизировать.

Как все должно выглядеть и как это сочетать с ГОСТами 2.501...2.503 оговаривающие  учет, хранение и правила внесения изменений будет разъяснено в следующих ГОСТах группы электронные документы.
Целесообразность основана на переходе от понятия промышленность страны к понятию экономика страны...
Прошу прощения если что не так...

Цитата: Goran от 04.10.12, 20:23:28
...но в моем случае  востребована схоластика, а не демагогия.

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

Цитата: 2VMS от 04.10.12, 20:26:37
Да, но к ГОСТам .... появились ГОСТы ..., а также ГОСТ... Кроме того есть ...ГОСТ ...

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

Цитата: Владимир Владимирович от 04.10.12, 20:45:34
Электронная модель, .....
Нормоконтроль должен проверят "правильность" построения ЭСИ, часть из фнукций нормоконтроля нужно автоматизировать.

Владимир Владимирович, объясню еще проще - мое конструкторское понятие "правильности" необходимо урегулировать сначала с восприятием правильности нормоконтролера, а у нас разное понимание, у каждого третьего свое виденье правильности, чье понимание правильности будем автоматизировать?.
Пример. В настоящий момент (при одновременном наличии электронного и бумажного документа) СП должна содержать и чертеж детали (как основной конструкторский документ) и электронную модель детали (тоже как основной)  Атрибуты у чертежа и 3Д должны быть одинаковы, в противном случае это будут два самостоятельных РАЗНЫХ изделия, как получить "бумажную" копию идентичного документа с разными атрибутами?. А если они равноценного статуса по определению "своей основности", то в СП мы их будем указывать как удвоенное количество? Это все грубое приближение, но таких парадоксов достаточно...   

Цитата: tramp_m от 04.10.12, 21:06:32
......
Так что подождемсссс..., вот и вся схоластика....
....

Это не схоластика, это эскапизм

Цитата: Goran от 04.10.12, 21:14:03
Пример. В настоящий момент (при одновременном наличии электронного и бумажного документа) СП должна содержать и чертеж детали (как основной конструкторский документ) и электронную модель детали (тоже как основной)  Атрибуты у чертежа и 3Д должны быть одинаковы, в противном случае это будут два самостоятельных РАЗНЫХ изделия, как получить "бумажную" копию идентичного документа с разными атрибутами?. А если они равноценного статуса по определению "своей основности", то в СП мы их будем указывать как удвоенное количество? Это все грубое приближение, но таких парадоксов достаточно...   

Не должна СП содержать эти документы, нет такого требования, если вы его сами не выставляете. Далее, атрибуты не должны быть одинаковыми, так как это разные документы. Для примера хотя бы взять атрибут "дата разработки", 3d модель разрабатывается за некоторое время до чертежа. У чертежа есть формат документа, у модели нет и пр.
И еще раз повторюсь: ЭСИ - за основу, а СП-отчет

Кстати:

ЦитироватьИдентичный документ: документ, одинаковый с исходным по содержанию и формату и (или) кодам данных (ГОСТ 2.051-2006, п. 3.1.6).

Если автоматизировать построения ЭСИ по типу 3D модель в чертеж (пока чертеж всё -таки останется), в модель изделия?
Тогда и нормоконтроль не нужен, да собственно и технологический контроль, и ... выбросить.
Оставить только разработчика, что потопает то и полопает.
Уменьшатся этапы согласования....
Разрабатывай, ищи изготовителя и вперед...
По моему не так уж и плохо...
Может быть я ошибаюсь....

Цитата: tramp_m от 04.10.12, 21:54:23
Если автоматизировать построения ЭСИ по типу 3D модель в чертеж (пока чертеж всё -таки останется), в модель изделия?

Фраза не понятна, то ли не хватает запятых, то ли слов. :)

Цитата: tramp_m link=topic=23090.msg160929#msg160929 date= 1349373263
Тогда и нормоконтроль не нужен, да собственно и технологический контроль, и ... выбросить.

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

Цитата: Владимир Владимирович от 04.10.12, 21:44:35
Не должна СП содержать эти документы, нет такого требования, если вы его сами не выставляете. Далее, атрибуты не должны быть одинаковыми, так как это разные документы. Для примера хотя бы взять атрибут "дата разработки", 3d модель разрабатывается за некоторое время до чертежа. У чертежа есть формат документа, у модели нет и пр.
И еще раз повторюсь: ЭСИ - за основу, а СП-отчет

Кстати:

Мы с Вами друг друга не поймем. Дело в том, что Вы не конструктор. И  ваше

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
При бумажном документообороте времен кульмана процесс разработки строился следующим образом:
.....

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

Уважаемые, я прошу прощения, но спор на мой взгляд бесперспективен... В любом случае возможны варианты:
1. Главенство за ЭСИ;
2. Смешанная модель, и ЭСИ и бумажная копия имеют одинаковый статус и применяются в зависимости от необходимости на разных участках производства, при это возникает процедура поддержки и верификации актуальности информации в обеих системах;
3. Главенство за бумажным КД, ЭСИ - справочный характер для электронного документооборота, процедура поддержки и верификации атуальности информации также присутствует.
Выбор - за руководством предприятия в зависимости от готовности кадров и финансовой состоятельности. В любом случае рано или поздно возникнет вопрос эффективности вложений в автоматизацию. ИТ подразделение должно быть готово к ответу на этот вопрос. Если в связи с автоматизацией в технологическом процессе возникают дополнительные процедуры, требующие дополнительных затрат - это называется автоматизация ради автоматизации (кто-то получает удовольствие от процесса имения кого-то другого). Такая модель автоматизации быстро умрет. Допустимы два варианта.
1. Автоматизация должна сокращать процедуры и укорачивать информационные цепочки между реперными точками, в которых принимаются ключевые решения. Эффективность - за счет сокращения "человеческого фактора" (зарплата, налоги, ошибки, брак и т.д. и т.п.).
2. Количество процедур остается неизменным, комплексная автоматизация позволяет переработать больший объем информации для принятия более обоснованного решения в реперных точках. Эффективность за счет снижения издержек от ошибок и брака.
Ваш спор относится к рабочим моментам внедрения конкретной модели автоматизации, но он так и не отвечает на главный вопрос, а где собственно ЭФФЕКТ то? Ради чего акционеры предприятия должны вкладывать деньги?   

Цитата: Goran от 04.10.12, 22:47:57
Мы с Вами друг друга не поймем. Дело в том, что Вы не конструктор. И  ваше  не совсем понятно на чем основано.

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

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

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

ЦитироватьКак бы там не было это однозначно не не прописано.

ну так это же замечательно, как бы не было печально  :)
"Закон что дышло, где повернул, там и вышло"
Этот закон (в лице ГОСТа) есть и нам с ним жить.

Давайте так: чем вас не устраивают 2 варианта, предложенных YorikER, третий не рассматриваем в принципе

Цитировать1. Главенство за ЭСИ;
2. Смешанная модель, и ЭСИ и бумажная копия имеют одинаковый статус и применяются в зависимости от необходимости на разных участках производства, при это возникает процедура поддержки и верификации актуальности информации в обеих системах;

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

Цитироватьвопрос эффективности вложений в автоматизацию

Мы пошли следующим путем: утвердили ЭСИ, которая применяется для необходимых потребностей предприятия, при этом параллельно живет и СП и никому не мешает. Но значимость этого документа постепенно размывается. В перспективе -отказ от СП. Упомянутые "и/или" позволяют эволюционировать ИС безболезненно переходя от "и" к "или". Что вас смущает?

В любом случае для применения современных технологий придется менять устаревшие процессы. В ГОСТах 50-80 годов не может содержаться описания современных процессов.
Существует взаимосвязь между эффективностью, процессами и новыми технологиями. Исходя из этого внедрение новых технологий без изменения процессов может приводить и к снижению общей эффективности.
От ряда устаревших ГОСТ нужно отказываться, если мы хотим применять новые технологии.

Мне кажется, нет устаревших процессов, есть развитее продолжение процесса, переход на другой, более технически поддерживаемый уровень.
Концепция процесса остается той же.
При переходе на безбумажную электронную технологию очень важно не потерять наследие (те ценности, которые нам достаются по наследству, как дома в семье).
Иначе мы будем нищими...
А с «кашей» я разбирался,, когда волею судеб приходилось внедрять ГОСТы ЕСКД, ЕСТПП, ЕСТД..., вот так...
Составлял подобные таблицы и просто  их заполнял, и сразу... постепенно..., всё прояснялось.
Предлагаю составить вот подобную таблицу, возможно её развитие в зависимости от поставленной задачи...

Цитата: Владимир Владимирович от 05.10.12, 09:39:48
....И вообще: требую сатисфакции!....

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

Цитата: Владимир Владимирович от 05.10.12, 09:39:48
....
Давайте так: чем вас не устраивают 2 варианта.....

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

"ГОСТ 2.201-80 1.1. Каждому изделию в соответствии с ГОСТ 2.101-68  должно быть присвоено обозначение.
1.2. Обозначение изделия является одновременно обозначением его основного документа....Обозначение...документа не может быть использовано для...другого документа."
Ну не могу я понять каким образом может существовать ДВА основных конструкторских документа на изделие под разными номерами со всеми вытекающими последствия. В случае одинаковости номеров один из документов должен являться копией, дубликатом другого. В итоге получиться 

Цитата: YorikER от 05.10.12, 08:15:15
....возникают дополнительные процедуры, требующие дополнительных затрат - это называется автоматизация ради автоматизации (кто-то получает удовольствие от процесса имения кого-то другого). .....

К этому я и веду.

Цитата: tramp_m от 05.10.12, 18:09:55
......
Предлагаю составить вот подобную таблицу, возможно её развитие в зависимости от поставленной задачи...

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

А на уровне «нормоконтроль-конструктор», мне приходилось делать так... ,  открываем вместе Стандарт и читаем вместе, тут и выясняется, кто чего и как понимает.
Бывало и мне приходилось признавать свою ошибку безо всякого волюнтаризма ...

Да, а что бы помочь понять смысл надо бы как то поконкретнее.
«и/или» это не принципиально.
Для понимания смысла электронного документа, надо бы для себя понять назначение и функции его.
Наверное, так...
Если не ошибаюсь...

Вроде если внутри завода используются станки с ЧПУ, то модели достаточно. Но чтобы решить спорные вопросы нужна бумажка/чертеж всяким там электронным моделям не сильно верят)

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

Не знаю на чем закончился этот опыт...

Электронный документооборот внутри завода, называется проект изделия – Завод с электронным документооборотом. 8-)
Где электронные модели попадают сразу непосредственно в станок ЧПУ на исполнение, без посредников. :)
А в вашем случае какое-то половинчатое решение, поэтому и «много непоняток » :%:
Вроде так.
Источниками подтвердить не могу, где то в глубине архивов... :shu:
Хотите верьте, хотите нет. :o
Может быть не прав, прошу прощения... :shu:

ЦитироватьХотел сказать, что Ваш подход к данной ситуации обусловлен "интересом" автоматизации и только.

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

Цитировать"ГОСТ 2.201-80 1.1. Каждому изделию в соответствии с ГОСТ 2.101-68  должно быть присвоено обозначение.
1.2. Обозначение изделия является одновременно обозначением его основного документа....Обозначение...документа не может быть использовано для...другого документа."
Ну не могу я понять каким образом может существовать ДВА основных конструкторских документа на изделие под разными номерами со всеми вытекающими последствия. В случае одинаковости номеров один из документов должен являться копией, дубликатом другого.

Понятно что кривые ГОСТы, но все же:
ГОСТ 2.102

Цитировать2.8. Электронным документам присваивают дополнительные коды в соответствии с табл. 4, которые указывают в реквизитной части документа.

Таблица 4
Вид документа: Электронная структура изделия

Дополнительный код документа: ЭС
....
Примечание
.....
2. Если необходимо совместное использование электронной модели изделия (детали, сборочной единицы) и чертежа, то чертежу присваивают код документа согласно табл. 3, а электронной модели изделия (детали, сборочной единице) присваивается соответственно код «МД» или «МС».

Теперь 2 документа с разным обозначением. Такой вариант устроит?

Да, и как я говорил ранее: все эти примечания, недоговорки, "и/или", выявленнные в нормативных документах отшлифовываем СТП, ТЗ, договорами


PS Кстати:

ЦитироватьДубликаты

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

Копии

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

Электронные документы, выполненные способом, обеспечивающим идентичность их с подлинниками (дубликатами), подписанные установленными ЭЦП лиц, ответственных за их изготовление

Цитата: Алхимик от 05.10.12, 19:38:56
Вроде если внутри завода используются станки с ЧПУ, то модели достаточно.

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

В 14-той версии: размеры с отклонениями, базы, шероховатости и ТТ как в 2д чертеже.

В предложенных вами Goran к рассмотрению ГОСТах рассматривается разработка изделия от частного к общему.
вольный конспект к ГОСТ 2.051-2006
Электронный документ ЭД, создается на основе ранее выполненных форм (ЕСКД) в бумажной форме (или электронной по типу преобразования в Компас Фрагмента в Чертеж и далее создание трехмерной модели).
Естественно мы имеем два представления ЭД
1. Внешний вид - в доступной для визуального восприятия форме (стандартная форма чертежа, спецификации ЕСКД к примеру) для дисплея, печатающего устройства и т.д.
2. Внутренний вид – в виде записи информаци только для программно-технических средств. Внутреннее представление ЭД должно обеспечить преобразование внутреннего вида до внешний вида.
И далее
Внутренний вид ЭД состоит из 2х частей
1.   Содержательная. Состоит в свою очередь из нескольких информационных единиц ИЕ                                                                                                                                          - текстовой,                                                                                                                          – графической,                                                                                                                      -  визуальной (мультимедийной)
2.   Реквизитная.   По ГОСТ 2.104-..., и другие реквизиты, такие как подпись по ГОСТ 34.310 и т.п. для внешнего представления. Рекомендована форма внешнего вида реквизитной части ЭД – информационно удостоверяющий сопроводительный лист УЛ
Электронные документы ЭД подразделяют на:
- Простые  - содержательная часть с одной ИЕ
- Составные  - содержательная часть с несколькими ИЕ связанных друг с другом ссылками определенным применяемым форматом данных
- Агрегатированные  - содержательная часть с несколькими ИЕ информационно связанных друг с другом.
Ответственность за взаимное соответствие исходного ДЭ и его твердой копии в ходе жизненного цикла документов возлагается на разработчика.
Твердая копия должна содержать указание на исходный ДЭ....

Вот примерный не полный конспект ГОСТ 2.051-2006 :%:
В нем раскрывается термин - Электронный документ ЭД  его компоненты и составляющие дан внешний вид рекомендуемой формы реквизитной части ЭД.
Мне так показалось... :)
Может быть я ошибаюсь... :shu:

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

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

Цитата: Владимир Владимирович от 05.10.12, 21:49:27
...
Понятно что кривые ГОСТы, но все же:
ГОСТ 2.102Теперь 2 документа с разным обозначением. Такой вариант устроит?

Да, и как я говорил ранее: все эти примечания, недоговорки, "и/или", выявленнные в нормативных документах отшлифовываем СТП, ТЗ, договорами
...

Не устроит, поскольку это не решение противоречия.
Давайте остановимся на ГОСТ 2.102.
Пункт 2.2 оговаривает понятие основного конструкторского документа.
Пункт 2.3 оговаривает основной комплект конструкторских документов изделия!!!

Теперь рассмотрим ситуацию, существует бумажный чертеж и электронная модель детали
При условии наличия чертежа на деталь  с обозначением АБВ.ХХ.ХХ.101 равноправно (статус основного документа) существует  электронная модель с обозначением АБВ.ХХ.ХХ.101 (поскольку код для нее не оговорен - см табл.3 ГОСТ2.102). Парадокс - ,два основных документа под одним номером. Если я отсканирую бумажный чертеж, то буду иметь в наличии еще один основной документ под тем же номером (электронный чертеж детали)  у нас в наличии уже три основных равноправных документа.
Далее, деталь входит в основной документ изделия с обозначением АБВ.ХХ.ХХ.000 (что при бумажной форме соответствовало спецификации)  или в основной документ АБВ.ХХ.ХХ.000 (что соответствует ЭСИ) Каким образом будем различать эти два основных документа при ситуации совместного существования бумажной и электронной формы?
Далее тот же пункт говорит о возможности включения в один документ (СП или ЭСИ) документов различной формы,
  Таким образом, я могу в бумажной спецификации в разделе "документация" на основании табл.5 сделать запись  АБВ.ХХ.ХХ.101 (для чертежа бумажного) АБВ.ХХ.ХХ.101 3D (для электронной модели)  и  АБВ.ХХ.ХХ.101 2D (для сканированного чертежа), но в отличии от узлов для детали не может быть спецификации. Получается, что все три документа (равноправные) я должен указать в документе в состав которого они входят. 
Но в таком случае не понятно как на одно, и то же изделие (в данном случае деталь) может существовать три различных основных документа? Короче – "каша" , и вот вопрос что в этой каше автоматизируется?
Выпуская свое СТП, Вы/Мы просто закрываем глаза на проблемные места, которые все равно будут всплывать. И сегодняшняя автоматизация локального случая будет постоянно требовать устранения возникающих "несоответствий". А  пока автоматизируя процесс "невнятной схемы КД" напрягам психику конструктора (конечно не тупого исполнителя приказа), который не состоянии понять смысла требуемых от него действий, сам процесс - получает трудность внедрения.
Вот такая моя непонятливая ИМХА  :)

 Кстати, горячие финские парни, а почему это всё время электронные документы увязываются со станками ЧПУ?
А если нет ЧПУ -  электронные документы как бы и особо не нужны?
Или наоборот: есть  электронные документы - покупай станки с ЧПУ?

Цитата: СВ от 07.10.12, 14:37:08
Кстати, горячие финские парни, а почему это всё время электронные документы увязываются со станками ЧПУ?
А если нет ЧПУ -  электронные документы как бы и особо не нужны?
Или наоборот: есть  электронные документы - покупай станки с ЧПУ?

Речь пока идет не о нужности/ненужности тех или иных форм документов и их соответствия существующей технологии, а об отсутствии внятной системы совместного существования документов разных форм по принципу  и/или.
ГОСТ 2.102 приводит новую структурную схему комплектования документов для электронной формы в которой существует чертеж детали, а вот оставшаяся (существующая для бумажной формы) структурная схема комплектования не имеет связи с документами электронной формы. А ЕСКД это вроде как ЕДИНАЯ система.
В этом контексте и задается  вопрос; - автоматизируется единая система или две параллельных системы? Если две, то возникает вопрос об эффективности такой системы в целом и ее(их) автоматизации в частности и как следствие применение/использование в дальнейшем для всей конструкторской и технологической документации процесса создания изделия.

Если есть ЧПУшные станки, то как говорит Goran появляются как минимум два основных документа - 2Д и 3Д. Если у вас нет ЧПУшных станков то 3д, выступает дополнительным документом к 2д (хотя и 2д чертежи делаются по 3Д модели - прототипу). И о существовании 3д модели нет не кому дела кроме конструктора.

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

Цитата: СВ от 07.10.12, 17:14:34
Алексей Николаевич, да я вроде как в полушутку спросил.
Сути подобных разговоров в свои 51 я, естественно, понимаю. И потому призываю вас с Владимиром Владимировичем, как уважаемых всеми нами, к диалогу, а не к спору. Т.е. высказать свою аргументированную точку зрения, а не пытаться что-то доказать.
..... Взгляните на начало темы, Владимиру Владимировичу хотелось бы автоматизации простой работы...

А вот,я к большому сожалению сути "ВАЩЕ" не понимаю..., потому не спорю и не доказываю, а прошу обстоятельных разъяснений существующей ситуации.
Вчитайтесь внимательно еще раз в название темы!!! и соотнеся все это с ЕСКД растолкуйте мне, что (какой именно процесс) пытаемся автоматизировать? 

 Я увидел следующее

Цитата: Владимир Владимирович от 27.09.12, 17:40:33
...
При электронном документообороте с разграничением прав доступа требуется пересмотреть процесс разработки. Казалось бы, при наличии структурированного электронного архива, выпуск ведомостей должен занимать считанные минуты, однако...
...для выпуска ведомостей необходимо снабдить документы и объекты базы данных необходимыми атрибутами, например, указать для заимствованных чертежей держателя подлинника, материал, количество листов, массу детали и пр. и пр.
Кто должен выполнять данную работу?
...

Т.е. электронике данная работа вроде бы под силу. Надо только подработать её.

Но лучше всего, конечно, спросить Владимира Владимировича.

Цитата: СВ от 07.10.12, 17:39:55
Я увидел следующее...

Я тоже увидел

Цитата: Владимир Владимирович от 27.09.12, 17:40:33...., при наличии структурированного электронного архива....

Вот и мне хочется узнать по какому принципу структурировано

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

....

Цитата: tramp_m от 07.10.12, 20:29:03
...
Тема принципиальная .....
Если вы обратили внимание на раздел Библиография в представленных стандартах, то наверное заметили, что все Стандарты ИСО относятся по большей части к Информационная технология..., Техническая документация.   ...управление технической документации....  Системам автоматизации производства и их интеграция....
Только -Управление информации, хотелось бы подчеркнуть именно информации, но не её содержанием.
Это даже по названию не ЕСКД, не говоря о деталях...
В творческий процесс Конструктора-проектировщика по созданию технической документации (информации) не вмешивается. В представленном
ГОСТ 2.051-2006
В коротеньком конспекте его можно прочесть, что электронный документ ЭД состоит из ....
Это говорит о том, что те документы, которые вы определили как отдельные, таковыми не являются по ИСО. ..  Это один и тот же Агрегатированный ЭД.
....

Сергей Петрович, Вы сами поняли что написали? (Суть которую понял лично я из Вашего монолога -  выделил красным )
При чем тут ИСО? Вы сообщения читаете? Мы вроде пока определились в рассмотрении

Цитата: Владимир Владимирович от 05.10.12, 21:49:27
....
Понятно что кривые ГОСТы, но все же:
ГОСТ 2.102Теперь 2 документа с разным обозначением. Такой вариант устроит?....

Цитата: Goran от 07.10.12, 13:49:32
...
Давайте остановимся на ГОСТ 2.102.
Пункт 2.2 оговаривает понятие основного конструкторского документа.
Пункт 2.3 оговаривает основной комплект конструкторских документов изделия!!!
....

ГОСТ 2.051 относится к ЕСКД, как и ГОСТ 2.102, который предметно определяет (вернее который раньше определял) виды и комплектность ....
Документацию, которая подлежит учету, хранению, и  контролю на актуальность структурировали в электронный архив!!!!
Меня интересует принцип структурирования (каким образом  на основании чего).

И не стоит передергивать  :um:

Цитата: tramp_m от 07.10.12, 20:29:03
..... те документы, которые вы определили как отдельные, таковыми не являются по ИСО. .. ...

Я не определял, а представил два варианта  текущего состояния документов основываясь на определениях ГОСТа!

/quote]

Цитата: Goran от : Сегодня в 20:20:03
Меня интересует принцип структурирования (каким образом  на основании чего)
.

Это уже тянет на индивидуальную консультацию.
Давайте определяться....
Прошу прощения, если, что не так...

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

Цитата: ZorGR от 08.10.12, 08:45:37
....Т.о. структура изделия содержит наиболее полную информацию об изделии (по сравнению с любыми документами) и должна быть использована для получения любых необходимых документов.
ЭСИ в отличие от ГОСТированных документов гибкий инструмент и может быть приспособлена под предприятие.

Полностью согласен! Логика понятна и проблем с пониманием нет. Проблемность возникает при совместном использовании двух форм.
В примечании к приложению Б ГОСТ 2.102 пример комплект электронных документов сказано "Разбитые на графы текстовые документы (Спецификация, ВС, ВД, ВП, ВИ, ДП, ПТ, ЭП, ТП, ВЭД, ЗИ и др.), как правило, не ассоциируют с элементами структуры изделия, их следует получать в виде отчетов из электронной структуры изделия." А при бумажной форме СП является основным конструкторским документом.
В итоге, мы можем применять сществование документов только на принципе или/или.
1. Независимо существует параллельно две формы документов.
2. Существует приоритетно только электронная форма, а бумажнаа форма является только средством визуализации.
При такой, конкретизированной постановке комплектования появляется осмысленная логика для действий конструктора, нормоконтролера и архива (внесение изменений и актуализация)

Цитата: СВ от 07.10.12, 17:39:55
Я увидел следующееТ.е. электронике данная работа вроде бы под силу. Надо только подработать её.

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

По данному вопросу тема исчерпана, хотя если есть еще мысли можно продолжать,
а продолжение разговора про статус электронного документа предлагаю открыть в новой теме http://forum.ascon.ru/index.php/topic,23132.new.html#new (http://forum.ascon.ru/index.php/topic,23132.new.html#new), дабы не засорять тему посторонними вопросами.

Кстати, электронный документ нужен отнюдь не только для станков ЧПУ. И не обязательно что, если модель идет на станок, не нужен чертеж. Все должно идти от задачи.

Представил я себе такую  картину, так сказать пофантазировал! Одно предприятие решило перейти на электронный документооборот. Тем самым шагать в ногу со временем! Взяли "дремучий" проект из архива, разработанный еще при Иосифе Виссарионовиче, отсканировали его (перевели в электронный вид - pdf!). И послали его далее по всем соответствующим службам. Технолоджи-менеджер его мониторил не бумажно, а в Adobe Reader. Менеджеры по экономике и бухгалтерингу тоже не на абаке костяшками бряцали, а на уиндос-калькуляторе считали. Снабженингу также передали ведомости и нормы в электронном виде. Естественно, дабы исключить из производственного процесса бумагу как "класс", выдали всем цеховым менеджерам (по слесарингу, фрезерингу, токарингу или в зависимости от масштабов производства - наладкамейкерам) по планшету! И самое главное, обязательно, всех топовиков одеть в ливайсы! Именно в ливайсы (левисы), а не какие нибудь вранглеры или ещё того хуже в монтану! Вот тогда попрёт!  :j:
Да, это пародия. Именно, к большому моему сожалению, пародия.  :`(
Один гендир приказал спецификацию выпускать в другом формате. И он считает, что это правильно. Но хотелось бы узнать независимое (анонимное) мнение его подчинённых (конструкторов)! Потому как спецификация является прежде всего конструкторским документом. При проектировании, конструктор постоянно обращается к ней. Без проблем, при окончании проектирования спецификацию можно перевести в формат xls. Что касается "умеления" над ведомостью покупных изделий - этот документ необходим. Другое дело, что он должен формироваться автоматически, так же как и другие ведомости. Если конечно речь идёт об использовании САПР, а не описанном мною примере выше. Вполне возможно, что это реализовано в Лоцмане или в новом продукте Гольфстриме. Не знаю, с этими ПО я совершенно не знаком.
И ещё про "спецификацию на листе"! Этот вариант возможно гораздо эффективней, но как быть, если к примеру помимо сборочного чертежа ещё имеются монтажный, упаковочный, электромонтажный и пр. чертежи, различные схемы, ведомости и т.д.? На каком чертеже располагать спецификацию? А если спецификация состоит из 10 листов и более?
Я так скажу: "воду лить" это тоже нужно уметь! Для этого нужно иметь талант! Более того, качественный "водополив" весьма востребован!
Возможно я в чём то не прав, сорри.  :shu:

Цитата: Resfeder от 08.10.12, 23:44:45
Представил я себе такую  картину,... по планшету! И самое главное, обязательно, всех топовиков одеть в ливайсы!...! Вот тогда попрёт!  :j:
...

Не попрет, с вифи (Wi-Fi) по душам не поговоришь  :)

Цитата: Resfeder от 08.10.12, 23:44:45
Возможно я в чём то не прав, сорри.  :shu:

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

Ну почему же

Цитироватьогульное критиканство

Я обозначил именно то, с чем я не согласен. Согласен я с тем, что не надо выпускать ту документацию, которая не нужна на данном предприятии. Согласен, что многие ведомости должны формироваться автоматически, раз мы используем САПР и со многим другим.