Сообщений в теме: 7

[Mikhaylov_YV]

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

Простыми словами PLM/PDM технологий заключается в том, что все данные о изделии находятся в одном месте(сетевом хранилище) и каждый, кому дан доступ, может смотреть и редактировать чертежи и другие данные(тонкости настройки прав доступа одна из ключевых задач в развитии PLM) Ведь буквально 15 лет назад, пересылка документа по электронной почте была в новинку, а сегодня конструктора из десятков КБ по всему миру могут работать над одним большим проектом одновременно(судно, автомобиль, самолет). И у этой области еще огромный потенциал и в ближайшие годы нас ждет еще много нового.
А о имеющихся сегодня достижениях PLM можно почитать и посмотреть видио 
Teamcenter: «Гражданские самолеты Сухого», НПО Сатурн, ОАО «КАМАЗ», ОКБ «Аэрокосмические системы» и даже LEGO[/size]
Smarteam: ОАО «Павловский автобусный завод»
Лоцман: ОАО «Интелтех»
 
Истории везде красивые и складные да я и сам оценил высокую эффективность PLM, но хотел обсудить подводные камни в начале работы с этими системами.

[vss]

Я не конструктор и никогда не работал непосредственно в системах PDM/PLM. Поэтому, о "подводных камнях" работы с этими системами я могу говорить только как потребитель информации из этих систем. Не хочу бросать тень на какую-либо систему, потому что проблемы конструкторско-технологической документации иногда не зависят от самой системы. Во всех автоматизированных системах присутствует человек. Поэтому всё это аппаратно-программно-организационные системы. Если организационная часть ущербна (системы кодирования данных, нормоконтроль, документооборот, регламент и т.п.), то нужно быть готовым к проблемам.

Если предприятие использует системы PDM/PLM, то наверняка есть и какая-нибудь ERP, APS, MES и т.п. система, которая является потребителем конструкторско-технологической информации.

Алгоритмы работы ERP, APS, MES предполагают использовать качественную и полную информацию. Только на основании такой информации эти системы способны обеспечить эффективную работу плановиков, снабженцев, сбытовиков, диспетчеров, кладовщиков, контролеров и т.д.

Поэтому от системы PDM/PLM ждут качественной и полной информации. А вот с этим как раз и возникают проблемы.

Из личной практики могу выделить:

1. Общесистемные проблемы:

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

- кодирование рабочих мест, подразделений, оборудования

- необходимость наличия в АСУ информации, которая вне АСУ есть и используется, но некоторыми системами не предусмотрена (например: определение вида заготовки (отливка, поковка или штамповка) на стадии конструкторской подготовки), признак того, что запчасть может не только закупаться, но изготавливаться самостоятельно, и др.)

2. Качество документации. Пример: руководство предприятия считая, что системы PDM/PLM обеспечивают выдачу документации в соответствии с ЕСКД, ЕСТД сократили нормоконтролеров (оптимизация численности). В результате: встречаются сборочные единицы без состава или с составом, но входимость "0", вместо обозначения чертежа наименование детали, и т.д.

3. Оперативность внесения изменений в документацию. Ошибки в регламенте тормозят производство.

4. и масса других проблем.

Пока всё, по этому вопросу.

[ingenerkons]

С данными системами не встречался но работал с 1С УПП, так вот там была проблема, которая также возможна и в данных системах, Есть например куча записей похожего вида (например Болт М12 ГОСТ, БОЛТ М12 ГОСТ, БолтМ12 ГОСТ). То есть грубо говоря есть куча похожих надписей из которых необходимо выбрать)) Эти все надписи появлялись из-за недостатка опыта у пользователей, а инструкции как таковой и не было, при чем не всякий  из этих "болтов" брать можно было, там тоже были нюансы, периодически да осуществлялась чистка базы, но это не очень помогало. Все таки сначала должен быть четко выверенный алгоритм работы и взаимодействия между отделами, а уже потом внедрение автоматизации.

[Mikhaylov_YV]

Я не конструктор и никогда не работал непосредственно в системах PDM/PLM. Поэтому, о "подводных камнях" работы с этими системами я могу говорить только как потребитель информации из этих систем. Не хочу бросать тень на какую-либо систему, потому что проблемы конструкторско-технологической документации иногда не зависят от самой системы. Во всех автоматизированных системах присутствует человек. Поэтому всё это аппаратно-программно-организационные системы. Если организационная часть ущербна (системы кодирования данных, нормоконтроль, документооборот, регламент и т.п.), то нужно быть готовым к проблемам.

Если предприятие использует системы PDM/PLM, то наверняка есть и какая-нибудь ERP, APS, MES и т.п. система, которая является потребителем конструкторско-технологической информации.

Алгоритмы работы ERP, APS, MES предполагают использовать качественную и полную информацию. Только на основании такой информации эти системы способны обеспечить эффективную работу плановиков, снабженцев, сбытовиков, диспетчеров, кладовщиков, контролеров и т.д.

Поэтому от системы PDM/PLM ждут качественной и полной информации. А вот с этим как раз и возникают проблемы.

Из личной практики могу выделить:

1. Общесистемные проблемы:

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

- кодирование рабочих мест, подразделений, оборудования

- необходимость наличия в АСУ информации, которая вне АСУ есть и используется, но некоторыми системами не предусмотрена (например: определение вида заготовки (отливка, поковка или штамповка) на стадии конструкторской подготовки), признак того, что запчасть может не только закупаться, но изготавливаться самостоятельно, и др.)

2. Качество документации. Пример: руководство предприятия считая, что системы PDM/PLM обеспечивают выдачу документации в соответствии с ЕСКД, ЕСТД сократили нормоконтролеров (оптимизация численности). В результате: встречаются сборочные единицы без состава или с составом, но входимость "0", вместо обозначения чертежа наименование детали, и т.д.

3. Оперативность внесения изменений в документацию. Ошибки в регламенте тормозят производство.

4. и масса других проблем.

Пока всё, по этому вопросу.

 Да, я не думаю, что это какая-то тень. Хотел бы отметить, что PLM софт не является готовым решением, как SolidWorks или Компас, где после простейшей установки любой может сразу начать выпускать чертежи. PLM(как в прочем и 1С) это среда, где предприятие само должно выстроить свои закономерности и порядки. Так как на каждом заводе существует свой работающий документооборот. И успешность внедрения, зависит на прямую от полноты и качества настройки системы. А в ее настройке нужно принимать участие всем пользователям и выставлять свои требования к настройке. И так день за днем после совещаний и споров появится система, в которой станет интересно и удобно трудится.

А быстро и сразу, только сами знаете, что делается. 

 

Я уже слышал много примеров, где внедрение PLM решений, когда первый год по мимо заполнения бумажной документации принуждают заполнять и электронную. 

[Alexander B.]

Мне знакома российская разработка - PDM Step Suite.

У кого-нибудь установлена? 

Может кто-нибудь сказать отличия от западных комплексных систем?

[Dimon012]

С данными системами не встречался но работал с 1С УПП, так вот там была проблема, которая также возможна и в данных системах, Есть например куча записей похожего вида (например Болт М12 ГОСТ, БОЛТ М12 ГОСТ, БолтМ12 ГОСТ). То есть грубо говоря есть куча похожих надписей из которых необходимо выбрать)) Эти все надписи появлялись из-за недостатка опыта у пользователей, а инструкции как таковой и не было, при чем не всякий  из этих "болтов" брать можно было, там тоже были нюансы, периодически да осуществлялась чистка базы, но это не очень помогало. Все таки сначала должен быть четко выверенный алгоритм работы и взаимодействия между отделами, а уже потом внедрение автоматизации.

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

[DubovDV]

С данными системами не встречался но работал с 1С УПП, так вот там была проблема, которая также возможна и в данных системах, Есть например куча записей похожего вида (например Болт М12 ГОСТ, БОЛТ М12 ГОСТ, БолтМ12 ГОСТ). То есть грубо говоря есть куча похожих надписей из которых необходимо выбрать)) Эти все надписи появлялись из-за недостатка опыта у пользователей, а инструкции как таковой и не было, при чем не всякий  из этих "болтов" брать можно было, там тоже были нюансы, периодически да осуществлялась чистка базы, но это не очень помогало. Все таки сначала должен быть четко выверенный алгоритм работы и взаимодействия между отделами, а уже потом внедрение автоматизации.

Чтобы не получалось дублей наименований изделий, оснастки и т.д. принято использовать единую базу НСИ, международной терминологии - MDM. На рынке САПР сейчас их не так много, но есть отечественная система которую используют на таких крупных предприятиях как "Вертолеты России" - Semantic MDM. Mas­ter Data Man­age­ment — это системный подход к построению единого информационного пространства предприятия на уровне справочных данных, позволяющий реализовать единый корпоративный язык общения автоматизированных систем.

[Dimon012]

... Есть например куча записей похожего вида (например Болт М12 ГОСТ, БОЛТ М12 ГОСТ, БолтМ12 ГОСТ). То есть грубо говоря есть куча похожих надписей из которых необходимо выбрать)) Эти все надписи появлялись из-за недостатка опыта у пользователей, а инструкции как таковой и не было, при чем не всякий  из этих "болтов" брать можно было, там тоже были нюансы, периодически да осуществлялась чистка базы, но это не очень помогало. Все таки сначала должен быть четко выверенный алгоритм работы и взаимодействия между отделами, а уже потом внедрение автоматизации.

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

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

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