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

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

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

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

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

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

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

[СВ]

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

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

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

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

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

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

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

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

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

[YorikER]

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

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

[Николай]

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

[YorikER]

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

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

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

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

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

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

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

[Дмитрий22]

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

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

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

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

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

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

[tramp_m]

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

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

[YorikER]

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

[Goran]

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

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

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

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

[tramp_m]

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

[YorikER]

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

[Goran]

Об этом я также выше писал: .... переносить задачи в электронный вид.

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

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

Только он имеет право на её сопровождение, изменение и больше ни кто.

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

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

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

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

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

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

[Goran]

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

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

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

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