Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО «ЛС-Технологии»

ИНН 7807258360 ОГРН 1227800102375

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

7 - 2003

Внедрение PLM-системы на Минском автомобильном заводе

Константин Смирнов

Важнейшие проблемы предприятия

Что делать?

Как управлять комплектациями изделий

Два способа представления данных о структуре изделия; их плюсы и минусы

Что мешает применить опыт ведущих машиностроительных компаний для управления комплектациями изделий на МАЗе

Возможность компромисса

Этапы реализации

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

Важнейшие проблемы предприятия

Управление планированием и оперативный расчет цены выпускаемой автомобильной техники

Сразу же возникает вопрос: «Почему эти проблемы не беспокоили руководство МАЗа раньше?» Да просто они приобрели актуальность недавно — с приходом рынка. В былые времена завод выпускал весьма ограниченное количество комплектаций автомобилей, и заказчики довольствовались тем перечнем автомобильной техники, который им предлагали. Рыночные отношения вынудили завод, чтобы не потерять покупателя, перейти к гибкому варианту производства и комплектации автомобилей — в соответствии с требованиями потребителей. В результате число комплектаций стало стремительно расти — практически каждый второй автомобиль теперь уникален. Помимо конструктивных, получили широкое распространение особенности, обусловленные наличием нескольких поставщиков комплектующих, что также влияет на цену и на цеховые планы.

Прослеживаемость данных

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

Безопасность данных

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

В начало В начало

Что делать?

Определение пути документации от маркетинга до конвейера

Движение документации из отделов маркетинга и конструирования в производственный и в цех весьма извивистое, и рассматривать его в полном объеме нет необходимости — достаточно определить основное. Упростив цепочку (оставив только те ее элементы, которые непосредственно влияют на состав изделия), мы получаем схему, показанную на рис. 1:

Рассмотрим, какие документы циркулируют между службами и какую информацию они несут1 .

1. Маркетинг — Конструктор. Конструктор отправляет в отдел маркетинга ведомость комплектаций — это документ, в котором указывается номер комплектации (например, 437040-0000120) и основные характеристики (база = 3700, двигатель = евро1 и т.д.). Отдел маркетинга предлагает заказчикам различные комплектации автомобилей, исходя из технических требований, и, если необходимо, указывает особые условия комплектования (например, установить солнцезащитные козырьки и т.п.). Особые условия комплектования в отделе маркетинга обычно указываются со слов заказчика, поэтому необходимо согласовать эту комплектацию с конструктором. Если конструктор не возражает, то заказ на автомобиль уходит в плановое управление (маршрут 5). Для наглядности мы здесь и далее будем намеренно игнорировать административное согласование с различными должностными лицами.

2. Конструктор — Технолог. Конструктор выпускает документацию (спецификации, чертежи) на изделия и через извещение передает технологу. Далее идет процедура согласования.

3. Технолог — Планово-диспетчерское управление (ПДУ). После завершения подготовки производства технолог выпускает для ПДУ «Технологический маршрут», где указывает маршрут на каждую деталь или узел.

4. Технолог — Цеха. Технолог выдает для производства «Технологические процессы».

5. Маркетинг — ПДУ. Из отдела маркетинга поступает заказ на изготовление автомобилей, прицепов и т.п. определенных комплектаций.

6. ПДУ — Цеха. Отдел планового управления передает в цеха планы выпуска продукции в определенные сроки.

Выяснение требуемого качества информации

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

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

Плановое управление — получает номера комплектаций автомобилей с особыми условиями (если они есть) и их количество. Однако такая информация не устраивает отдел планового управления. Дело тут в особых условиях. Плановому управлению нужен конкретно определенный состав автомобиля с уникальным обозначением. Даже простейшая комплектация автомобиля — это более 6 тыс. различных деталей и узлов, и вручную произвести «разузлование» и «расцеховку» практически невозможно. Программное обеспечение, которым пользуются в ПДУ, требует обозначения комплектации, в котором описан однозначный состав изделия. (Выше мы упоминали, что прежде именно так и было.)

Технолог — получает от конструктора спецификации и чертежи. Как мы выяснили, в спецификациях отсутствует однозначный состав изделия, поэтому конструктор вынужден прибегать к формулировкам: «Устанавливать по требованию заказчика», «Допускается устанавливать в замен позиций № 1, № 4 совместно с позицией № 2» и т.п. Для технолога такая неоднозначность не только не усложняет процесс разработки технологической документации, но даже упрощает, поскольку это позволяет сократить количество комплектаций. В технологических документах технолог также использует формулировки: «По требованию …», «Допускается замена на…».

Конструктор — получает задание на разработку автотехники. Это может быть разработка новых изделий или применение других комплектующих. Рассмотрим в качестве примера задание на использование подшипников фирмы SKF в редукторе заднего моста. Конструктор может решить эту задачу следующими способами: либо вписать в спецификацию редуктора «Допускается взамен позиции» и указать позицию существующего подшипника, либо создать новое исполнение редуктора, в котором вместо существующего подшипника будет указан подшипник SKF. Во втором случае необходимо создать новую комплектацию редуктора и новую комплектацию моста (где применяется новый редуктор) и т.д. — до новой комплектации автомобиля. Естественно, для конструктора первый путь проще, а ПДУ нужно, чтобы документы были оформлены по второму варианту. В этом случае количество комплектаций автомобилей быстро превысит миллионный рубеж, что равносильно хаосу. А если идти по первому пути, то как определить на производстве, какой подшипник необходимо установить в редукторе заднего моста, тем более что покупатель может настаивать на использовании подшипников именно этой фирмы — SKF.

Маркетинг — получает от конструктора обозначения и описания комплектаций автомобилей. Большое количество обозначений комплектаций также усложняет работу отделу маркетинга. (Внимание: именно обозначений, а не самих комплектаций автомобиля.) Маркетологи работают с каталогом, в котором указаны обозначения комплектаций и их характеристики. Насколько усложнится выбор нужной комплектации, если количество этих обозначений превысит шесть разрядов?

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

В начало В начало

Как управлять комплектациями изделий

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

• под обозначением сборочных узлов описаны все возможные их комплектации (рис. 2);

• в спецификациях указываются (при необходимости) условия применения деталей и узлов;

• к спецификациям на изделия указываются характеристики, определяющие состав изделия.

Именно поэтому заказанные на германском предприятии MAN кабины и мосты различной комплектации имеют единое обозначение и в поставке указываются основные характеристики.

Приведем пример фрагмента спецификации на изделие 4370-2400012, как она могла бы выглядеть (см. рис. 2).

Такая форма представления состава узла не определяет его точный состав, но позволяет создавать различные комплектации без отдельных номеров, а для определения точного состава необходим еще один документ, содержащий требуемые характеристики узла. В данном случае точный состав можно указать таким образом: 4370-2400012, АБС = Wabco, Передаточное отношение (U0) = 3,45 или 4370-2400012, АБС = Экран, Передаточное отношение (U0) = 3,9.

Если данный узел может комплектоваться датчиками АБС — Wabco и Экран, устанавливать редукторы с передаточным отношением 3,45 и 3,9, то для создания всех возможных исполнений нам потребуются четыре различных обозначения; если добавить еще одного производителя АБС, то количество возрастет до восьми и т.д. Таким образом, количество обозначений будет увеличиваться в геометрической прогрессии. Для описания модели автомобиля 437040 потребовалось 36 опций (АБС, База и т.п.), каждая из которых имеет от 2 до 8 различных значений, поэтому если давать каждой комплектации свой уникальный номер, то потребуется присвоить более миллиона обозначений.

В начало В начало

Два способа представления данных о структуре изделия; их плюсы и минусы

Комплектации изделий можно представлять двумя способами: первый — по правилам ЕСКД как исполнения, с присвоением каждому уникального номера, и второй — тот, что мы рассмотрели выше. Назовем представление структуры изделия по второму способу «общей спецификацией». Рассмотрим плюсы и минусы каждого варианта.

Первый вариант. Плюсы: соответствует требованиям ЕСКД, уникальный номер исполнения определяет точный состав изделия (если, конечно, не допускать вариантности). Минус: требует задействования большого количества номеров исполнений. Пример: Создаем исполнение заднего моста с использованием подшипников SKF. Если мы имели 4 исполнения заднего моста, то количество исполнений увеличится вдвое, то есть до 8; если мы имели 20 исполнений автомобиля, где применяется этот задний мост, то теперь их число увеличится в 2 раза, то есть до 40. Если учесть, что автомобиль состоит из более чем 6 тыс. деталей, то объяснять, к чему это приведет, нет никакой необходимости.

Второй вариант. Плюсы: отсутствует недостаток первого варианта, то есть если мы применим новую деталь (например, тот же подшипник SKF), то это не потребует от нас создания нового исполнения — ни моста, ни автомобиля. Минусы: не соответствует правилам ЕСКД; для определения состава изделия требуются дополнительные сведения.

В начало В начало

Что мешает применить опыт ведущих машиностроительных компаний для управления комплектациями изделий на МАЗе

Первый вариант (по правилам ЕСКД) не позволяет решить основную задачу, поэтому самый простой способ ее решения — применение представления состава изделия по второму варианту, тем более что он уже «обкатан» ведущими производителями автомобильной техники (исключая страны, где используется ЕСКД). Но самый большой минус второго варианта для МАЗа как раз и заключается в несоответствии правилам ЕСКД. Проблема вовсе не в печатной форме спецификаций (ее-то как раз решить можно), а в производстве, которое десятилетиями работало по правилам, определенным в ЕСКД. И хотя все подразделения (см. рис. 1) выигрывают при применении общих спецификаций, перестроить весь документооборот невозможно (так, по крайней мере, заявляют руководители предприятия).

В начало В начало

Возможность компромисса

Противоречие заключается в необходимости строгого соблюдения требований ЕСКД и в невозможности решения поставленной задачи в рамках той же ЕСКД. Нет ничего проще — повторить все механизмы работы с документацией, заложенные в ЕСКД (ввести данные, создать исполнения с уникальным номером и получить бумажные формы документов). Но это не решит основную задачу, и применение такой мощной системы, как Teamcenter Engineering (IMAN), не будет оправданно, поскольку с этой задачей может справиться практически любая отечественная PDM-система (сильной стороной которой как раз и является соответствие требованиям ЕСКД и сравнительно небольшая стоимость). Так как решение основной задачи возможно только в случае применения второго варианта, то остается единственный выход — использовать по содержанию второй вариант, а по форме — первый. Что это значит? Конструктор в электроном виде должен создавать сборочные узлы по второму варианту (см. рис. 2), а выводить на печать и применять в производстве — спецификации по правилам ЕСКД. Для этого нужно посмотреть, как задается точная комплектация (исполнение) сборочного узла в первом и во втором случае и поставить между ними знак равенства. Пример: [4370-2400012, АБС = Экран, U0 = 3,45] = [4370-2400012-010]. Видно, что задний мост с такими характеристиками (левая часть равенства) соответствует исполнению с номером 4370-2400012-010. Представим это в виде таблицы.

Сочетание значений двух опций «АБС» и «Передаточное отношение» конструктор однозначно определил в исполнениях заднего моста, а значения для опции «Подшипники ступицы заднего моста» не определены, то есть в любом исполнении заднего моста можно использовать подшипники как ГПЗ, так и SKF (это головная боль ПДУ). В таблице представлены данные для конкретного сборочного узла с четырьмя исполнениями, который выпускается на производстве, поэтому у нас была возможность проследить его продвижение по схеме (см. рис. 1). ПДУ планирует любое исполнение заднего моста, включая в план и подшипники ГПЗ и SKF (мы упоминали о программном обеспечении в этом подразделении). В цехе сборки руководствуются правилом: смотри предписание от отдела маркетинга, какой подшипник ставить; если в предписании ничего нет, то следует устанавливать подшипники ГПЗ. Используя наш подход к решению проблемы, конструктор должен создать документ типа опросного списка (такого как вышерассмотренная таблица) для автомобиля и отправить его в отдел маркетинга. Тот, в свою очередь, предлагает заказчику выбрать нужные ему значения опций. Далее программа по выбранным значениям найдет в базе данных соответствующее исполнение автомобиля, а опции, которые не влияют на исполнение, внесет в предписание. Программное обеспечение ПДУ потребуется доработать. Для планирования необходимо указать не только номер исполнения, но и значение опций из предписания. Такой подход позволит решить следующие задачи:

• полностью повторить существующую документацию на производстве;

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

• получить точный состав автомобиля и правильно планировать производство, что необходимо для расчета реальных цен на продукцию.

В начало В начало

Этапы реализации

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

1. Создание электронных справочников (стандартные изделия, материалы и т.п.). Как правило, справочники уже существуют в разных подразделениях и для них используются различные базы данных (никто не ожидал стремительного появления Teamcenter). Поэтому задача заключалась в переносе данных в Teamcenter Engineering, а если необходимо, то и в создании ассоциативной связи с существующими базами данных.

2. Создание выходных печатных форм документов (спецификации, извещения и т.п.). Это было необходимо, так как внедрение PLM-системы происходит постепенно, от подразделения к подразделению, и на этот период необходима бумажная документация. Особо нужно отметить разработку процедуры соблюдения соответствия между бумажным и электронным документом. Пока создается база данных электронных конструкторских изделий, никто не останавливает процесс изменения изделий конструктором, поэтому для соответствия электронной и бумажной документации были приняты следующие правила:

• начальники подразделений при электронном утверждении документации обязаны проверить на соответствие электронную и бумажную документацию;

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

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

4. Обучение конструкторов и наполнение базы конструкторскими изделиями. К настоящему моменту в УГК Минского автомобильного завода введено 29 моделей автомобилей и прицепов с использованием Teamcenter Engineering. На каждую модель автомобиля приходится от 33 до 51 признака, на прицеп — до 10 признаков комплектаций.

5. Создание интерфейса для передачи данных (извещений, спецификаций, точного состава автомобиля и т.п.) в систему Omega Production. При внедрении PLM-системы необходимо задействовать множество служб и подразделений предприятия, поэтому неизбежны столкновения интересов. На МАЗе технологи сделали свой выбор в пользу системы Omega Production, конструкторы и маркетологи — в пользу Teamcenter Engineering.

6. Кроме того, существуют программные комплексы управления конвейером; есть и собственные разработки. Согласование данных между различными системами имеет ряд сложностей, и ему целесообразно посвятить отдельную статью.

Затронутые нами вопросы наверняка актуальны для многих предприятий стран СНГ, и найти верное решение важно для всех. Весьма немаловажным стало бы содействие служб Госстандарта в решении данных вопросов на качественно новом уровне.


1 Мы упростили схему, не отразив в ней параллельные и дополнительные извещения, множественные и параллельные маршруты и т.п. Это темы отдельных статей.


В начало В начало

«САПР и графика» 7'2003

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557