Як я Search впроваджував або типові проблеми впровадження PDM систем на пострадянських виробництвах

Не секрет, що для успішного впровадження будь-якої системи документообігу необхідно зробити кілька логічних кроків, в даному пості я опущу етапи дослідження, почну з пілотного проекту. І постараюся описати проблеми та способи вирішення цих, які з упевненістю у 90% існують на будь-якому пострадянському «кондовому» підприємстві.

Етапи впровадження системи

  1. Було сформовано робочу групу, що з конструктора, технолога, оператора архіву ОТД і адміністратора системи;
  2. Було проведено аналіз та оцінку існуючих бізнес-процесів та виділено основні типові для підприємства бізнес-процеси щодо затвердження та здачі документації;
  3. Проведено аналіз ринкових пропозицій та вибір PDM-системи;
  4. Закупівля малої кількості ліцензій, за кількістю учасників робочої групи (6 ліцензій Search, 3 ліцензії AVS (система формування специфікацій та вторинної документації), 1 ліцензія Techcard (система роботи з технологічними процесами)
  5. Було складено план впровадження системи на реальному замовленні «***», як пілотний проект;
  6. Здійснено налаштування бланків конструкторсько-технологічної документації;
  7. Створено та затверджено шаблон оформлення документації в системі КОМПАС.
  8. Створено методику створення бази стандартних елементів;
  9. Створено методику ведення електронної картотеки документів ОТД;
  10. Створено методику ведення класифікаторів ОТД;
  11. Створено та перевірено експлуатацію створення специфікацій у 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 в меню файлу. 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 моделі деталі (набору файлів), система: - оновить позначення об'єкта-документа, - заповнить атрибути - найменування, розробив і.т.п, - створить об'єкт - матеріал (або вкаже на відповідність матеріалу в БД) і вкаже його позначення / найменування якщо він був призначений на модель, - заповнить атрибут об'єкта "деталь" значенням атрибута "маса" - збереже файл і заповнить атрибути «дата останньої зміни» тощо.

За погане форматування — окремо перепрошую,наступному пості виправлюся.

Хардкорна конфа за С++. Ми запрошуємо лише профі.