Процесс выпуска комплекта электронной КД против комплекта бумажной КД

Автор Владимир Владимирович, 27.09.12, 16:40:33

« предыдущая - следующая »

0 Пользователей и 1 гость просматривают эту тему.

Goran

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

YorikER

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

YorikER

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

tramp_m

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

С уважением tramp_m

YorikER

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

Goran

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

tramp_m

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

С уважением tramp_m

YorikER

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

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

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

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

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

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

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

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

YorikER

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

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

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

YorikER

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

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

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

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

YorikER

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

YorikER

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

YorikER

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

Алхимик

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

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

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

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

"На "западе" все легко украсть, но только один раз" (препадователь ДонНТУ).
Похожая аналогия "Все грибы съедобны, но некоторые только один раз".
Да, день бывает труден, // И хуже, как не скуден, // Сынок, бывает все, все превозмочь сумей!
Вот, видишь, висит бубен, // Старинный мощный бубен, // Берешь вот этот бубен, //
И бей в него, и бей! Бей в бубен!   :-))) :-))) :-))) :-)))

YorikER

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

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

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

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