Как я Search внедрял или типичные проблемы внедрения PDM cистем на пост-советских производствах

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

Этапы внедрения системы

• Была сформирована рабочая группа, состоящая из конструктора, технолога, оператора архива ОТД и администратора системы;
  Был проведен анализ и оценка существующих бизнес-процессов и выделены основные типичные для предприятия бизнес-процессы по утверждению и сдаче документации;
  Проведен анализ рыночных предложений и выбор PDM-системы;
  Закупка малого количества лицензий, по количеству участников рабочей группы ( 6 лицензий Search, 3 лицензии AVS(система формирования спецификаций и вторичной документации), 1 лицензия Techcard (система работы с технологическими процессами)
  Был составлен план внедрения системы на реальном заказе «***», в качестве пилотного проекта;
  Произведена настройка бланков конструкторско-технологической документации;
  Создан и утвержден шаблон оформления документации в системе КОМПАС.
  Создана методика создания базы стандартных элементов;
  Создана методика ведения электронной картотеки документов ОТД;
  Создана методика ведения классификаторов ОТД;
  Создана и проверена эксплуатация создания спецификаций в PDM системе как с ручного ввода, так и в полуавтоматическом режиме, на основе имеющихся в базе документов и прочих изделий.

Проблемы

По результатам этапов были выявлены существующие проблемы на предприятии, связанные с ведением документации:

1. Документация имеет огромную преемственность ( 70% конструкторско-технологической документации по пилотному проекту – заимствованная из другого изделия).
2. Документы выполнены в разных версиях САПР системы Компас (система не поддерживает преемственность), с разными шаблонами оформления (Search параметрическая система и построена на принципах считывания атрибутов с листов САПР системы, атрибуты определяются в шаблонах), т.е. для загрузки документа в Search необходимо пересохранять каждый файл в текущую версию Компаса с применением новых стилей оформления. Т.к используются различные шаблоны, то часть важной информации теряется, необходимо перезаполнять соответствующие поля (Наименование, Обозначение, Разработал, Проверил, Н.контр, Первичная применяемость и т.д.)
3. Зачастую многолистовые чертежи сохранены в разные файлы, но имеют одинаковые атрибуты. Для загрузки в систему необходимо собрать проект в 1 файл, иначе возникают ошибки, т.к. к на разных документах один децимальный номер.
4. Не используется возможность «САПР Компас» «спецификация на листе», т.е., например, соединительные кабеля прописаны гладким текстом в таблице, созданной руками, соответственно интегратор Компас-Search не получает данных о изделии.
5. Вторичные документы (спецификации, ведомости спецификаций, ведомость материалов) выполняются не автоматически, средствами САПР, а в различных, не приспособленных к этому программах (word, excel,TDD и тд), в случае, когда спецификация выпускается в системе Компас, то по факту выполняются это таблице, созданная средствами компаса, и заполняется вручную и не имеет связей с чертежом. Разработчики печатных плат, в свою очередь, выпускают перечни элементов на компас-форме «ведомость спецификаций» в табличном режиме, внося данные вручную. Что приводит к логическим разрывам связей с первичной документацией.
6. Конструкторы и разработчики не вносят мелкие (зачастую оформительские, либо изменение номинала) изменения в проектируемые изделия, после выпуска извещений о корректировке, иными словами невозможно сказать насколько текущий электронный документ соответствует документу, находящемуся в ОТД.
7. Проблемы заполнения спецификаций и перечня элементов:
8. b) Библиотеки САПР P-CAD морально устарели и не соответствуют используемым на предприятии элементам, а так же они не содержат российских и советских элементов, принятых отраслевыми стандартами, в следствии чего разработчик вынужден создавать личные библиотеки элементов. Эти библиотеки между разработчиками никак не синхронизируются, что вызывает дублирование элементов, неверное истолкование элементов, а так же банальные ошибки, связанные с наименованием: допустим, «Конденсатор К-73-21б-500в 10А-0.1мкФ +- 10%» и Конденсатор К-73-21б-500в 10А-0.1мкФ +- 10%» при печати выглядят одинаково, но во втором случае в наименовании использованы английские символы. Т.е в базе создастся 2 элемента, и при автоматическом создании спецификаций и перечня покупных элементы не будут просуммированы.

c) Существующая в системе Search база стандартных изделий чрезмерно избыточна и не соответствует (используются полные Гостовские наименования и параметры, на предприятии приняты наименования из отраслевых ограничительных списков), а так же в ней не хватает некоторых отраслевых элементов из прочих изделия (розетки, разъемы, втулки), насчитывающие тысячи элементов.
d) Не используется библиотека «Материалы». Соответствующая графа заполняется вручную, а так же используются материалы, не существующие в текущих ГОСТах (нить суровая, вместо нить крученая капроновая 3К ОСТ-17-330-84)

8) Не существует единой системы разработки печатные платы и схем. Разработка выполняется в совершенно разных системах проектирования: cheemage, p-cad, orcad, visio, altium designer.
9) В проектах, созданных в системе P-cad не заполнены элементарные, но необходимые атрибуты оформления (разработал… наименование, обозначение), эти параметры нанесены на лист текстом, основная надпись выполнена рисунком. Дополнительно необходимо заполнять design attributes, в меню file.
10) Система Search является параметрической системой, поэтому необходимо соблюдать правила заполнения атрибутов элементов, внесения на схему или печатную плату. Т.е. необходимо заполнять главные атрибуты элементов, из которых формируется полная запись в перечне элементов и спецификации, т.е.: наименование, тип, номинал, допуск, позиционное обозначение. Либо создать отдельный атрибут, например ПЭ3, в котором должно быть прописано полное наименование элемента. Во всех файлах, участвовавших в пилотном проекте «****» существовали следующие ошибки:
a) Атрибуты элементов на схеме (файлы *.sch) и печатной плате(*.pcb) и не заполнены
b) Атрибуты заполнены не полностью, например, проставлено только наименование «конденсатор», без номинала и остальных параметров.
c) Атрибуты от элемента к элементу различаются по составу и наименованию, например: для конденсатора С1 атрибут «description» содержит наименование, а для конденсатора С65 этому атрибуту соответствует поле «name».
d) Проблемы с качественным наполнением этих атрибутов:
i) Номинал указывается не по ГОСТу
ii) Номинал одинаковых элементов с разными обозначениями (мк и мкФ)
iii) Обозначение заполняется не полностью.
11) В ходе подготовки документов к загрузке выяснилось, что перечень элементов создается в отдельной программе – TDD, в которой неполные наименования, полученные из атрибутов системы P-CAD дополняются вручную пользователем. На основе исправленного файла формируется перечень элементов, который сдается в архив конструкторской документации в печатном виде. Утилита TDD позволяет пересохранять перечень элементов обратно, в файл проекта p-cad, чем самым приводя его к идеологически правильной форме, но этого не делается. Этот файл сохраняется рядом с файлами проектов.
12) Из п.10 вытекает новая проблема: при корректировке сданного в ОТД комплекта документов не исправляется файл TDD, следовательно не вносятся корректировки, а перечень элементов правится вручную.
13) На схемах разъемы обозначены как контактная площадка, а не групповой элемент или элемент из библиотеки, что порождает за собой массу элементов типа Х1… Хn в автоматически сгенерированном перечне элементов.
14) Имена файлов и наименования имеют «код», Search построен таким образом, что транслирует код в исполнение.
15) Altium Designer не имеет интегратора к системе Search, т.к. не существует открытого API. В подразделении 2070 совместно с разработчиками НТЦ-4. Ведется разработка обработки, позволяющей перегрузить данные в PDM систему.
16) Не существует единой библиотеки элементов систем разработки печатных плат.
17) Сданные в архив документы, не имеют электронных версий, либо поиск электронных версий затруднителен. Рабочие копии документации хранятся не структурированно, собрать все файлы по минимальной ячейке изделия – блоку не представляется возможным.
Иными словами, на данном этапе система находится на первом, практически на переходном 2 этапе из 3 возможных этапов внедрения:
1. Интеграция на уровне файлов. Подразумевает простейшие операции с данными: сохранить файл в PDM, открыть файл из-под ПДМ. В классификации систем автоматизации это даже не интеграция, а базовый функционал. При таком подходе PDM система заполняет свойства файла некоторой информацией из своих атрибутов, например: наименование документа, обозначение, разработчик, масса. Либо во внешней программе в стандартном интерфейсе используется появится кнопка- «сохранить в PDM», по нажатию на которую, открывает интерфейс PDM системы и у пользователя появляется возможность, в соответствии с правами его доступа и ролью в делопроизводстве, заполнить атрибуты карточки и поместить файл в каталог, соответствующий каталогу, текущей разработке.
2. Интеграция на уровне атрибутов. Под такой интеграцией понимается подход, при котором PDM система считывает атрибуты, находящиеся в файлах документов САПР систем. Разработчик в САПР имеет возможность создавать и заполнять любые согласованные с PDM системой атрибуты в своей модели / чертеже. Эти атрибуты располагаются в системной (отрытой области) файла и PDM система может их прочитать, создать внутри себя объекты и автоматически заполнить свои атрибуты. В этих атрибутах может содержаться как информация, относящаяся к основному штампу так и информация о применяемости, технологических замечаниях, материале детали, весе, и именах внешних ссылок ассоциированных файлов.
Пример: при загрузке в PDM систему 3D модели детали (набора файлов), система:
— обновит обозначение объекта-документа,
— заполнит атрибуты -наименование, разработал и.т.п,
— создаст объект – материал(или укажет на соответствие материала в БД) и укажет его обозначение/наименование если он был назначен на модель,
— заполнит атрибут объекта «деталь» значением атрибута «масса»
— сохранит файл и заполнит атрибуты «дата последнего изменения» и т.п.

3) Чтение электронной структуры изделия (ЭСИ). Иными словами полная интеграция PDM системы в различные САПР. Под таким подходом понимают получение состава, при этом подходе избегается ручной ввод объектов и заполнения атрибутов. ЭСИ содержится в 3D моделях сборки и в документе «спецификация», которые в свою очередь собираются из БД PDM системы, а спецификация напрямую связана с файлами документов.
Т.е. при загрузке документации PDM система читает ЭСИ (системные области файлов, созданных в САПР, где находится ссылки на документы, участвующие в сборке) после чего:
— создается иерархическую структуру изделия с имеющимися количествами деталей, стандартных и покупных изделий.
— далее по хранимым внутри файла ссылкам рекурсивно, для каждого элемента сборки:
-определяется тип объекта (деталь, сборочная единица, библиотечный элемент -крепеж),
-создается обозначение;
-заполняются атрибуты объекта;
-создаются объекты – «документы — 3Д модель детали», задается обозначение
— заполняются атрибуты документа
— сохраняется файл
Если обозначение входящего в сборку объекта системе известно (примененный), то система автоматически создаст ссылку «применяемость» и дополнит существующее дерево состава отсутствующими элементами из БД.

За плохое форматирование — отдельно прошу прощения, в следующем посте исправлюсь.