Статус электронного документа

[Владимир Владимирович]

Теперь о 3D модели. Это тоже документ для Изделия но не основной, он должен фиксироваться только в ЭСИ, либо в какой-нибудь ведомости документов. Основным документом для Детали является чертеж. Поэтому в спецификации Сборочной единицы в разделе Детали должна быть строчка с описанием чертежа, а не 3D-модели. У сборочной единицы может быть тоже 3D-модель. И вы можете ее указать в разделе Документация в спецификации данной Сборки с расширением 3D (например ААА.БББ.ВВВ 3D, при этом ААА.БББ.ВВВ - обозначение спецификации данной сборки, а ААА.БББ.ВВВ СБ - обозначение сборочного чертежа данной сборки). Строчка с 3D обозначением в разделе Документация будет просто означать, что у данной сборки есть 3D модель в ЭСИ. Для Детали я честно говоря так и не нашел, где в КД надо фиксировать наличие 3D модели, в спецификации сборки фиксация 3D модели рядом с чертежом - не логично, двойственность в определении составного объекта. Может только в колонке Примечание?.

Поздно пришел, все уже более-менее разрулилось. Тем лучше.
Абсолютно точное описание.

По поводу деталей поступаем в соответствии с п.3.4 ГОСТ 2.106, т.е.

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

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

Да, и еще, электронные документы можно отобразить в ведомости электронных документов ГОСТ 2.102

[Владимир Владимирович]

При визуализации ЭСИ (выводе на бумагу) получаем основной документ СП

ЭСИ и СП - это не один документ. ЭСИ может существовать только в электронном виде. ЭСИ можно визуализировать, но при этом мы получим другой документ/отчет.

Далее по поводу электронного документа и полученного с него бумажного чертежа-здесь как раз все наоборот-это аутентичные документы, имеющие ссылки друг на друга. На бумаге это графа, например с именем файла, либо guid из ЭСИ. В электронном виде-это ревизит.

[Goran]

Алексей Нколаевич, не вы ли присылали мне пару лет назад форму "Электронной подписи", которая действовала на тот момент у вас на предприятии? Прижилось это дело?

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

[Владимир Владимирович]

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

Вот так же поступили и с ГОСТами
если бы не было так печально

[Goran]

....Далее по поводу электронного документа и полученного с него бумажного чертежа-здесь как раз все наоборот-это аутентичные документы, имеющие ссылки друг на друга. На бумаге это графа, например с именем файла, либо guid из ЭСИ. В электронном виде-это ревизит.

Если често, то я уже заблудился в словесах (определениях) тем более если принять во внимание (дополнительно рассматривать) еще и другие ГОСТы, понятия атрибутов и реквизитов на мой взгляд становятся притиворечивыми.
Вы (или кто-то вообще) можете показать визуально (накидать от руки) как будет выглядеть бумажная документация (заполнение граф и т.п.) на примере.
Имеем
деталь -ХХ.101 гайка 1шт.
деталь -ХХ.102 болт - 1шт.
сборка (гайка накручена на болт) ХХ.000 -1шт.
Предположим что создано 3D и 2D(получено из 3D) на каждую из деталей и на сборку, и выпущены бумажные чертежи на каждую из деталей, а также СБ и СП на сборку. 

[ZorGR]

Бумажная документация будет выглядеть так, как того требуют ГОСТы прошлого века. Т.е. бумажные документы ссылаются только на бумажные документы. Для того чтобы упорядочить электронные документы существуют PDM и PLM системы.

[Goran]

Бумажная документация будет выглядеть так, как того требуют ГОСТы прошлого века. Т.е. бумажные документы ссылаются только на бумажные документы. ...

Ой ли?
ГОСТ 2.102 вводит дополнительные обозначения кодов для документов. Где их необходимо указывать при совместном использовании двух форм обеспечивая ссылки друг на друга?
(я понимаю значения терминов "допускается" и "устанавливается разработчиком", но все-таки...)

[Владимир Владимирович]

Если често, то я уже заблудился в словесах (определениях) тем более если принять во внимание (дополнительно рассматривать) еще и другие ГОСТы, понятия атрибутов и реквизитов на мой взгляд становятся притиворечивыми.
Вы (или кто-то вообще) можете показать визуально (накидать от руки) как будет выглядеть бумажная документация (заполнение граф и т.п.) на примере.
Имеем
деталь -ХХ.101 гайка 1шт.
деталь -ХХ.102 болт - 1шт.
сборка (гайка накручена на болт) ХХ.000 -1шт.
Предположим что создано 3D и 2D(получено из 3D) на каждую из деталей и на сборку, и выпущены бумажные чертежи на каждую из деталей, а также СБ и СП на сборку. 

Если на словах, то так:
СП
Документация
ХХ.000СБ Сборочный чертеж
ХХ.000ЭСБ Электронная модель сборки
Детали
ХХ.101Гайка
ХХ.102 Болт

В бумажных чертежах вводим доп. графу 39 ГОСТ 2.104, в которых пишем признак аутентичного документа в соответствии с п.4.10 ГОСТ 2.051. В электронных документах вводим доп. атрибут.

При необходимости включаем в ВДЭ все электронные чертежи и модели. Это наш путь, он не противоречит ГОСТу, не нагружает конструктора.

[Владимир Владимирович]

Ой ли?
ГОСТ 2.102 вводит дополнительные обозначения кодов для документов. Где их необходимо указывать при совместном использовании двух форм обеспечивая ссылки друг на друга?
(я понимаю значения терминов "допускается" и "устанавливается разработчиком", но все-таки...)

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

[Goran]

Если на словах, то так:
...

Значит все-таки это самый вероятный принцип

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

Мда.....сложно доказать это кому-нибудь, при существующем написании ГОСТа (уже раз на 300 перечитал). Скорее всего этот принцип (прочтение/понимание) и стоит узаканивать в СТП другого выхода не вижу.

[ZorGR]

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

[ZorGR]

Например, всеми ссылками между всеми документами может управляет PDM система, а при получении бумажной КД (из ЭСИ) будут оставаться только ссылки между бумажными документами (т.е. бумажная КД не ссылается ни на ЭСИ, ни на 3D).

[Владимир Владимирович]

Может лучше начать изучать функционал PDM, PLM систем? Там эти задачи точно решаются.

Может лучше изучить автоматизируемую задачу и требования к этой задаче? PDM, PLM системы решают формализованные задачи. Где-то упоминалось про автоматизацию бардака.

Например, всеми ссылками между всеми документами может управляет PDM система, а при получении бумажной КД (из ЭСИ) будут оставаться только ссылки между бумажными документами (т.е. бумажная КД не ссылается ни на ЭСИ, ни на 3D).

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

[Goran]

.....Может лучше начать изучать функционал PDM, PLM систем? ....

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

[YorikER]

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

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

[YorikER]

Тема действительно очень обширная, но все-таки вкратце я попробую ее осветить. Имел когда-то опыт общения с аудитом... Возьмем за аналог структуру функционирования государства: есть Конституция (основные правила, права, обязанности, структура органов госуправления, кто чем занимается, кто что контролирует и т.д.), затем идут Федеральные законы по различным темам, после чего уже прописываются подзаконные акты, конкретно описывающие правила действия в конкретных условиях... Аналогичный свод законов предприятие должно прописать и для себя. Если оно хочет получить сертификат соответствия по ISO9000 и выйти на определенные рынки, куда без данной бумажки Вас даже не пустят. Цель аудита, проверить соответствие системы функционирования Вашего предприятия стандарту ISO9000 с точки зрения обеспечения качества выпускаемой продукции. На предприятии должно быть разработано "Руководство по качеству" (РК - аналог Конституции), в котором прописаны все основные правила, права и обязанности, также структура органов управления и, самое главное, должна функционально описана структура цикла жизнедеятельности изделия на предприятии. В указанном документе должен быть определен перечень функциональных блоков укрупненных бизнес-процессов на предприятии, должны быть определены лидеры бизнес-процессов и перечень стандартов, описывающих функционирование каждого бизнес-процесса. В свою очередь лидеры бизнес-процессов (руководители подразделений) обязаны разработать стандарты предприятия с описанием систем функционирования своих процессов (аналог - Федеральный Закон). Как правило процессы разбиваются на подпроцессы и т.д. Кажды подпроцесс, завершается выпуском какой-то конкретной документации (в Вашем случае КД), подтверждающей завершение процесса. В качестве источников информации для начала процесса предполагается наличие документов предыдущего (или параллельного) процесса. На каждый документ, в составе СТП необходимо разработать инструкцию по формированию документа или функционированию подпроцесса (разрабатывают соответствующие лидеры подпроцессов - аналог - подзаконные акты). Можно много об этом рассказывать, но это огромная аналитическая работа, которую лидеры предприятия обязаны провести, для того чтобы доказать внешнему сообществу, что у Вас на предприятии для поддержки высокого качества продукции и ее конкурентоспособности работает СИСТЕМА, а не "человеческий фактор" в виде горла и авторитета. И автоматизация процессов должна прежде всего опираться на систему менеджмента качества, как функциональный скелет. Поэтому я постоянно и пытаюсь сказать, прежде чем что-то автоматизировать, необходимо функционально описать предмет автоматизации. Может найдете много лишнего в своем процессе.
Рекомендую поизучать стандарт IDEF0 (http://ru.wikipedia.org/wiki/IDEF), для облегчения функционального описания системы. В интернете достаточно информации об этом стандарте. Не могу сказать, что это верх совершенства, но как первый шаг для аналитической работы вполне подойдет. Кстати аудиторам очень нравится, когда им показывают такие блок-схемы. Я будучи Главным конструктором ради интереса отредактировал СТП "СМК - Проектирование изделий" с применением блок-схем по IDEF0. Аудитор сразу же нашел в одной схеме ошибку и поставил нашему подразделению отличную оценку (поставил нас в пример). Два года потом ко мне никто не приставал...

[tramp_m]

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

[СВ]

 Любезные други, а не будет ли наиболее удобным рассуждать-разговаритвать по теме, выложив для наглядности полный набор документов какого-либо условного изделия (сбока, подсборка, пара деталей, пара стандартных, пара материалов, прочих), документация на которое выполнена и в эл-й, и в бумажной форме. Плюс пояснения (лучше прямо на документах "красным карандашом"), что на что ссылается, что где обозначает, в общем - что к чему. Тогда, мне кажется, будет реальный ПРЕДМЕТНЫЙ разговор. А главное - подсказка, ОЧЕНЬ НУЖНАЯ подсказка. Сами знаете - лучше один раз увидеть...

[ZorGR]

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

Ну так то я уже тоже заикался про процессы. Что они первичны. YorikER все очень грамотно и обстоятельно пишет. + Много

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

Это мы еще не задели сквозных процессов и нисходящего проектирования 

[ZorGR]

Рекомендую поизучать стандарт IDEF0 (http://ru.wikipedia.org/wiki/IDEF), для облегчения функционального описания системы. В интернете достаточно информации об этом стандарте. Не могу сказать, что это верх совершенства, но как первый шаг для аналитической работы вполне подойдет. Кстати аудиторам очень нравится, когда им показывают такие блок-схемы. Я будучи Главным конструктором ради интереса отредактировал СТП "СМК - Проектирование изделий" с применением блок-схем по IDEF0. Аудитор сразу же нашел в одной схеме ошибку и поставил нашему подразделению отличную оценку (поставил нас в пример). Два года потом ко мне никто не приставал...

Лучше конечно использовать тот стандарт описания процессов, который хорошо понимает ваш аудитор.
Мне больше нравятся UML или BPMN.