The Web-site of design Company Chelyabenergoproekt in English   English
Проектные работы в проектной организации Челябэнергопроект Заказать проектные работы в письме к проектной организации Челябэнергопроект Карта сайта
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




Création de site web société française Chelyabenergoproekt   Française

   Облако тегов на сайте проектной организации Челябэнергопроект
Проекты интеллектуального мастерства!
новости компании
30.12.2015 С Новым годом!
Администрация ...
21.12.2015 С Днём Энергетика!
Уважаемые друзья и коллеги! Поздравляю вас с нашим большим праздником – Днем Энергетика! ...



новости отрасли
объекты Ростехнадзора
  Облако тегов
проектирование монтаж ключ котел кран сертификат ГОСТ ремонт заказЧелябинск

От набора программных продуктов к отраслевым PLM-решениям
За последние несколько лет термин PLM (Product Lifecycle Management – управление данными о продукте на протяжении его жизненного цикла) прочно занял свое место в области компьютеризации промышленного производства. Сегодня PLM переживает бум популярности, как в свое время ГПС и CALS.            

С одной стороны, многие специалисты хотели бы иметь четкое представление о том, что стоит за понятием PLM. С другой стороны, мода на термин PLM нередко приводит к случаям его неадекватного использования. Цель данной статьи – внести ясность в данный вопрос.

Первой концепцию и методы PLM взяла на вооружение компания IBM/Dassault Systemes – сегодняшний лидер в области разработки PLM-решений. Определение термина PLM можно найти в публикациях и рекламно-информационных материалах этой компании. Однако, в целях большей объективности, воспользуемся определением компании CIMdata, известного в мире независимого эксперта по проблемам CAD/CAM/CAE, PDM и PLM. Это определение, в частности, можно прочитать на сайте www.cimdata.com в разделе «What is PLM?».

Итак, определение CIMdata: «PLM – это стратегический подход к ведению бизнеса, который использует набор совместимых решений для поддержки общего (Collaborative) представления информации о продукте в процессе его создания, реализации и эксплуатации, в среде расширенного (Extended) предприятия – начиная от концепции создания продукта и заканчивая его утилизацией – при интеграции людских ресурсов, процессов и информации». За приведенной формулировкой идут еще два предложения, содержащие ряд дополнений и уточнений по поводу того, что именно следует относить к решениям класса PLM.

Следовательно PLM – это не система и не класс систем, как, например, CAD/CAM, CAE или PDM, а стратегия производства промышленных изделий с применением комплексной компьютеризации, которая базируется на едином представлении информации об изделии (продукте) на всех стадиях его жизненного цикла. Эта информация может (и не просто может, но должна) совместно использоваться всеми участниками расширенного предприятия, к которым относятся основной производитель продукта, поставщики, субподрядчики, заказчики и потребители.

Нельзя понять PLM в отрыве от основных тенденций развития современного производства. В публикациях часто говорится о росте конкуренции среди производителей, о меняющихся предпочтениях заказчиков, о борьбе за сокращение сроков, о снижении цены и улучшении качества продукции как о причинах, требующих использования PLM-решений. Более глубокий анализ тенденций содержится в материалах компании IBM, которые были любезно предоставлены нам московским представительством этой компании (пользуясь случаем, выражаем благодарность). В указанных материалах отмечается, что новые информационные технологии, с одной стороны, следуют за развитием процесса глобализации экономики, а с другой – сами выступают источниками новых идей. Среди тенденций развития производства названы следующие:
- облик изделия во все меньшей степени определяется его разработчиком как авторская инициатива, и во все большей степени зависит от требований его будущего потребителя. Это касается не только комплектации, но и качественных характеристик изделия;
- головные предприятия – инициаторы промышленного бизнеса – все больше сосредоточиваются на окончательной сборке изделия, а все большая доля производства приходится на долю компаний-поставщиков;
- специализация поставщиков от традиционных принципов – производственно-технологического, конструктивного, сырьевого или территориального – меняется в сторону специализации системного типа. При этом поставщик стремится продавать определенную систему целиком, независимо от того, как она распределена на конечном изделии (например, систему кондиционирования пассажирского салона, гидравлическую систему или пилотажно-навигационный комплекс). Предлагаются также услуги специалистов, которые устанавливают, регулируют и проверяют систему на головном предприятии;
- компании предпочитают нанимать специалистов на срок реализации текущей производственной темы и освобождать их после завершения цикла разработки. Доля постоянного штата сотрудников компании-производителя изделия постепенно уменьшается, а доля контрактников, нанятых конкретно под данный проект, – увеличивается;
- при выполнении работ поставщики получают возможность использовать вычислительные мощности (сервер) хозяина проекта, работая в режиме удаленных терминалов. Это снижает затраты и риск инвестиций в программы и аппаратную часть для небольших фирм;
- предприятие – потребитель продукции все чаще становится прямым инвестором в его разработку. Вместо того чтобы сначала копить деньги, а потом разом покупать то, что предлагается на рынке, заказчик сам авансирует свое будущее приобретение. При этом заказчик забирает у предприятия-изготовителя изделия часть технического и финансового риска. Такое растянутое во времени расходование капиталов и более равномерное распределение рисков благоприятно сказывается на общих финансовых показателях как производителя, так и потребителя;
- развитие производственной кооперации привело к появлению виртуальных предприятий. Такое предприятие является временным и создается на время производства конкретного продукта. При этом все компании, являющиеся участниками виртуального предприятия, работают фактически как департаменты одной фирмы, с одной инфраструктурой и по единым корпоративным правилам. Границы, языки, локальная специфика и расстояния становятся незаметными для деятельности каждого из них. Предприятия-поставщики, как правило, стоят в очереди к обладателю промышленной инициативы на конкурентной основе;
- для владельцев бизнес-инициативы, то есть обладателей интеллектуальной собственности на производство с применением данной торговой марки, продаваемым товаром стала не только сама продукция, но и право на ее производство (как правило, ограниченное сроками или объемом выпуска). Это право подразумевает возможность перевода лицензионного производства на удаленные территории, где имеются для этого благоприятные экономические условия.
Приведенные тенденции обусловливают такие требования к используемым информационным технологиям, как обеспечение комплексности и высокого уровня автоматизации, поддержка всех этапов жизненного цикла изделия, организация совместного (коллаборативного) использования информации о продукте большим числом географически удаленных друг от друга участников бизнес-процесса.

В области компьютеризации промышленного производства используется большое число систем различных классов. PDM-системы обеспечивают создание и поддержку единого информационного пространства на всех этапах жизненного цикла изделия (ЖЦИ). CAD/CAM/CAE-системы автоматизируют процессы проектирования и подготовки производства. MRP-системы решают задачи планирования ресурсов и управления производством, а ERP-системы – задачи управления деятельностью предприятия. CRM-системы управляют взаимоотношениями с заказчиками. SCM- и CPC-системы обеспечивают управление цепочками поставок и ведение совместного бизнеса всеми участниками расширенного предприятия. И это далеко не весь перечень элементов в используемой сегодня классификации.

Не все из перечисленных видов систем относятся к средствам поддержки PLM-решений. Так, согласно CIMdata, поддержка PLM-решений выполняется системами автоматизации процессов проектирования (CAD/CAM/CAE и др.) и PDM-системами (точнее, коллаборативными PDM, обозначаемыми как cPDm – collaborative Product Definition Management). IBM/Dassault Systemes также отмечает, что системы классов ERP, SCM и CRM не относятся к средствам поддержки PLM-решений, а обеспечивают, совместно с PLM, эффективное функционирование расширенного предприятия (рисунок 1).

Связь PLM-решений с другими задачами Что касается систем класса MRP, то, несмотря на их отсутствие в классификации CIMdata, представляется, что их следует отнести к средствам поддержки PLM-решений. Это не противоречит определению PLM, так как процесс производства является одним из этапов ЖЦИ. Подтверждением может служить также включение компанией IBM/Dassault Systemes в состав предлагаемых PLM-решений системы DELMIA, к функциям которой относятся решение задач планирования, разработки, контроля и управления процессами производства.

PLM-решения обеспечивают высокий уровень автоматизации процессов проектирования не только за счет большого числа инженерных приложений. Современный уровень предполагает наличие возможности параллельного проектирования, накопление и использование корпоративных знаний, автоматизацию проведения изменений по всем этапам процесса проектирования, различные режимы визуализации проекта и др. Такой уровень проектирования получил название методологии RGD (Relational Generative Design). Примером реализации методологии RGD может служить система CATIA V5.

Помимо решения типовых для CAD/CAM/САЕ-систем задач, CATIA V5 обладает эксклюзивным набором инженерных приложений, часть из которых (например, проектирование кузова автомобиля) присоединена к типовым задачам, а другая часть образует два специальных класса: «системный синтез промышленных изделий» и «проектирование инженерных систем и коммуникаций» (рис. 2). Первый класс позволяет решать такие задачи, как хранение и использование корпоративных знаний, оптимизация альтернативных вариантов проекта, проведение общей экспертизы модели изделия, анализ взаимодействия «человек – изделие». Приложения второго класса решают задачи схемного и пространственного проектирования инженерных систем (трубопроводов, вентиляции, кондиционирования), функционального проектирования электрических систем, проектирования и размещения в изделии систем электрожгутов, создания проектов размещения производственного оборудования c учетом виртуальной модели цеха или предприятия.

Классы задач, решаемых CATIA V5


Еще совсем недавно трехмерная визуализация изделия была прерогативой только участников процессов проектирования. Сегодня PLM-решения дают возможность просмотра и оценки 3D-модели (используется также термин DMU (Digital Mock-Up) – цифровой макет изделия) и на других этапах ЖЦИ. Для практики важно, что такой просмотр и оценка не требуют от пользователя умения работать в CAD-системе. По результатам оценки может быть принято решение, которое учитывается при проектировании. В качестве примера таких PLM-решений можно привести систему ENOVIA, которая создает 3D-пространство сотрудничества для всех участников расширенного предприятия. ENOVIA обеспечивает построение единой модели, которая конфигурирует и интегрирует продукт с процессами и ресурсами, необходимыми для его создания и обслуживания на протяжении всего жизненного цикла.

Создание единого информационного пространства (ЕИП) для поддержки информации на всех этапах ЖЦИ является сложным процессом, носящим итерационный характер. Это делает предпочтительным использование объектно-ориентированного подхода при построении ЕИП и выдвигает соответствующие требования к используемой PDM-системе. Примером PDM, реализующей объектно-ориентированный подход, является система SmarTeam, которая допускает плавное, итерационное развитие структуры ЕИП и наращивание функциональности системы за счет создаваемых приложений.

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

Базовая конфигурация SmarTeam содержит набор средств для совместной работы при создании, редактировании, поиске и хранении любых типов данных и документов, обеспечивая управление проектами, ведение версий, экспорт и импорт информации, включает средства для редактирования структур баз данных и настройки системы. Другие конфигурации SmarTeam обеспечивают интеграцию с CAD, работу удаленных пользователей (с доступом к общей базе данных через Интернет), поддержку ЕИП по всей цепочке поставок, маршрутизацию документов и заданий (Workflow), интеграцию с MRP/ERP и др.

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

Следует различать модель бизнес-процессов, существующих на предприятии в данный момент, и модель новых бизнес-процессов, которые будут протекать после внедрения PLM-решений. Понятно, что в рамках ЕИП должна быть реализована вторая модель, однако формализация существующих бизнес-процессов также необходима, поскольку позволяет понять их недостатки и выработать критерии новых бизнес-процессов. Для описания существующих и новых бизнес-процессов рекомендуется использовать единую методологию, реализующую объектно-ориентированный подход. Наиболее известной из таких методологий является методология UML (Unified Modeling Language), позволяющая строить модель предметной области с помощью набора специальных диаграмм. Инструментальным средством разработки диаграмм UML служит система Rational Rose. Построенные диаграммы позволят органично перейти к построению объектно-ориентированной модели ЕИП в среде PDM-системы.

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

Рассмотрим пример PLM-решения – ЛОЦМАН:PLM.

ЛОЦМАН:PLM – система управления инженерными данными и жизненным циклом изделия, «центральная нервная система» комплексного решения АСКОН. ЛОЦМАН:PLM содержит всю информацию, необходимую для проектирования, изготовления и эксплуатации продукции машиностроительного предприятия. Система решает задачи:
- хранения и управления технической документацией на изделие;
- управления информацией о структуре, вариантах конфигурации изделий и входимости компонентов в различные изделия;
- управления процессом разработки изделия.

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

В процессе эксплуатации PLM-решений заказчик часто сталкивается с проблемой недостаточно эффективного использования приобретенного программного продукта. Рассмотрим одну из причин ее возникновения и возможные пути преодоления.

Опыт применения систем САПР в 90-х годах показал, что с внедрением новых информационных технологий на предприятиях возникали проблемы. Приобретение программного продукта не являлось 100-процентной гарантией успеха, по крайней мере в долгосрочной перспективе. Попытки прямого переложения традиционных (бумажных) методик проектирования и производства на новый инструментарий превращали мощные пакеты 3D-моделирования и производства в аналоги пространственных кульманов. В лучшем случае выигрыш получался только за счет более точной геометрической привязки и компоновки изделия, а также за счет сокращения используемой в проектировании бумаги в обмен на неконтролируемо большое количество файлов. Увы, никто особенно не заботился о сохранении знаний, опыта предприятия и его повторного использования, никто не инвестировал свое время в разработку шаблонов процессов проектирования и производства. Работа шла по такому принципу: быстро и точно воспроизвести объект, потом еще раз воспроизвести, потом еще раз и еще: Типично «бумажный» подход.

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

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

Рассмотрим возникающие противоречия.

Никто, кроме самого заказчика, разумеется, если у него достаточно продолжительный опыт работы с продуктом, не знает, как лучше проектировать и изготавливать продукт, но с использованием старой методологии и инструментария! Значительная часть знаний об изделии – это драгоценный опыт предприятия и сотрудников. Как должен выглядеть продукт, работать, изготавливаться – эти знания универсальны, они не зависят от инструмента, который их описывает.

Однако другая часть знаний зависит от применяемого инструментария: как лучше построить, отобразить, заложить возможность быстрой модификации и редактирования. Именно в этом пункте и заключается одно из главнейших противоречий, тормозящих успешное внедрение систем PLM на предприятиях. Ситуация выглядит так. Заказчик заявляет: «Я знаю, как сделать продукт». С одной стороны, он прав, если говорит об опыте, с другой – нет, если говорит об инструменте. Обычно заказчик формулирует свои требования так: «Дайте мне программный продукт как инструмент, а уж как проектировать с его помощью, я сам разберусь». Это одно из стандартных заблуждений, так как базовые курсы дают знания о работе с универсальными функциями. Однако для эффективной работы этого недостаточно. Специалисты САПР знают, что одну и ту же 3D-модель можно построить приблизительно n! (n-факториал) способами, где n – число геометрических операций (фичерсов). В связи с этим для одного предприятия оптимальным может быть один сценарий, а для другого – совсем другой. Вот почему так важна работа по адаптации программного продукта. Кто должен ее выполнить? Заказчик? Но он не обладает всеми знаниями о программных продуктах, методиках работы с ними, особенностях применения той или иной функции. Производитель ПО? Однако он, как правило, недостаточно знает о специфике изделия, о методах его проектирования и производства.

Вариантов выхода три:
- создание группы компетенции на предприятии;
- привлечение сторонних компаний-консультантов (по сути – внешний центр компетенции);
- направление, в котором уже давно и плодотворно работает компания Dassault Systemes.

В последнем случае речь идет о центрах отраслевых решений (заметьте – не продуктов, а решений) внутри самой компании Dassault Systemes. Создание таких центров имеет достаточно долгую историю. Дело в том, что изначально компания Dassault Systemes работала с очень большими компаниями-заказчиками. Одним из требований корпоративных заказчиков было прямое участие в процессе внедрения и адаптации программных продуктов под требования заказчика, а также разработка специальных методологий по использованию ПО для решения конкретных задач компаний. Корпоративный заказчик напрямую выдвигал требования по адаптации к производителю ПО, запросы направлялись сразу в подразделения R&D (подразделение разработки ПО), где проходила их обработка. Со своей стороны Dassault Systemes получала прямой доступ к корпоративным бизнес-процессам, методологиям и правилам, все больше погружаясь в специфику той или иной отрасли и особенности создания конкретного изделия.

В итоге в выигрыше оказывались все стороны. Заказчик формулировал технические требования к продуктам напрямую и для реализации их работал с R&D. В свою очередь, специалисты Dassault Systemes набирались бесценного опыта непосредственно на предприятии-заказчике в той или иной индустрии и лучше понимали, как и для каких целей используются эти продукты. Так, многие продукты Dassault Systemes рождались под влиянием прямого запроса корпоративных заказчиков, как, например, это произошло с продуктом Aerospace Sheetmetal Design (ASL) для проектирования штампованных деталей из листа для авиационной и космической промышленности. Ценность таких продуктов заключается в том, что в них уже заложены определенные методики проектирования и производства изделий, типичных для различных отраслей промышленности.

Безусловно, имеются и сложности. Перед тем как выдать задание на разработку нового продукта, адаптацию существующего или даже на разработку методики работы с тем или иным стандартным продуктом, Dassault Systemes и заказчик проводят серию стандартных и хорошо отлаженных процедур по выработке технических требований к разработке. Подробно рассматриваются бизнес-процессы. Решается вопрос о копировании существующего бизнес-процесса и воспроизведении его с применением нового инструмента или о создании совершенно новых бизнес-процессов, использующих новый функционал, предоставляемый ПО. Лишь после этого начинается проработка решения.

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

Укрупненно схему работы Dassault Systemes по поддержке решений для заказчиков можно представить в виде диаграммы (рисунок 3).

Схема организации поддержки отраслевых решений


Задачей центра является разработка решений для оптимизации работы с продуктами Dassault Systemes в отдельных отраслях промышленности. Разработка методологий ведется совместными рабочими группами специалистов, привлеченных и со стороны заказчика, и со стороны Dassault Systemes. В работе группы принимают участие ведущие специалисты компании-заказчика, в том числе разработчики корпоративных методологий. От Dassault Systemes в нее входят эксперты ПО, архитекторы PLM-решений и программисты R&D.

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

PLM Program Center – Центр программ. Задачей этой группы является планирование и организация работ по разработке решений для той или иной отрасли промышленности.

Решаемые задачи:
- общее управление проектом;
- управление PLM-программами разработки решений;
- проведение аудита процессов заказчика;
- формирование стратегии разработки PLM-решений отрасли.

Industry Solution Center – Центр решений. Их в настоящее время существует несколько – для каждого крупного сегмента промышленности: авиация и космос, автомобилестроение, судостроение, нефтегазовая и нефтеперерабатывающая промышленность, электрика и электроника, общее машиностроение (Fabrication & Assembly), товары народного потребления и упаковка.

Решаемые задачи:
- управление процессом формирования требований к решению и взаимоотношений с заказчиком;
- адаптация существующих обобщенных приемов работы и продуктов под специфику заказчика и разработка специальной методологии работы с комплексными PLM-решениями.

Deployment Center – Центр детальной проработки решения и индустриализации.

Решаемые задачи:
- разработка специализированных решений в зависимости от групп используемых продуктов (CATIA, DELMIA, ENOVIA, SIMULIA, 3D VIA);
- обеспечение качества разработанного продукта;
- обеспечение всех необходимых интеграций, отработка процессов миграций версий, индустриализация кода.

Knowledge Center – Центр разработки (компетенции).

Решаемые задачи:
- внедрение решения на площадке заказчика;
- обучение персонала заказчика;
- техническая поддержка;
- оказание сервисных услуг, связанных с решением.

Упрощенная схема разработки решения показана на рисунке 4.

Схема разработки решения в подразделениях отраслевых решений


Процесс разработки и внедрения решения ведется объединенной группой представителей заказчика и Dassault Systemes. Каждую неделю проводятся совещания, где рассматривается статус запланированных работ, разрешаются конфликты и вырабатываются тактические планы, что контролируется руководством предприятия и компании Dassault Systemes.

Рассмотрим, что в итоге получают стороны.

Заказчик – методологию работы на новом инструменте, оптимизированную, с одной стороны, под бизнес-процессы заказчика, а с другой – под рациональное использование инструмента. Иногда модификацию текущих бизнес-процессов, иногда новые бизнес-процессы, ориентированные на новые инструменты, о которых заказчик даже не имел четкого представления. В результате выполнения специальных тестовых сценариев (так называемых use-case) на примере собственных изделий и документов заказчик получает документальное подтверждение, что тот или иной процесс выполним. Причем заказчику предоставляется целый набор метрик, отображающих полноту реализации тех или иных процессов, и план разработки функциональности, если он на тот момент реализован не до конца. Более того, заказчику предоставляются четко и подробно описанные методики пользования продуктами при выполнении тех или иных процессов, а также рекомендации по настройке и модификации типовых процессов, если требуется модификация описанного сценария. Эти методики схожи с РДК (руководством для конструктора), но с акцентом на правильное использование ПО.

Компания – поставщик решений получает неоценимый опыт работы в реальном окружении, опыт «боевой» эксплуатации ПО, четко расписанные методологии основных бизнес-процессов для той или иной отрасли промышленности, отладку универсальных программных средств по итогам эксплуатации, разработку новых, ориентированных на отдельные отрасли программных продуктов и модулей.

Однако есть еще один, пожалуй, самый важный аспект, которому компания Dassault Systemes уделяет особое внимание в процессе разработки решений для конкретных заказчиков. В продолжение своей политики, направленной на развитие функционала программных продуктов по капитализации знаний предприятия (шаблоны деталей, сборок и процессов), Dassault Systemes также капитализирует знания, полученные при прямой работе с заказчиками, превращая свой опыт в универсальные методологии. Безусловно, разработка универсальных методологий ведется с соблюдением правил конфиденциальности и сохранением прав на интеллектуальную собственность всех заинтересованных сторон. В методиках отсутствует информация, которая могла бы нанести ущерб предприятиям, в сотрудничестве с которыми Dassault Systemes разрабатывает свои решения. На основе анализа процессов нескольких предприятий берутся только базовые принципы, характерные для данной отрасли промышленности. Разрабатываются и документируются подходы к настройкам универсальных методик под возможную специфику заказчика. В итоге получается новый продукт, который может быть предложен другим заказчикам из данной отрасли промышленности, нуждающихся в подобных методологиях.

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

Если говорить об авиационной промышленности, то спектр предлагаемых методик весьма широк. Например, это рекомендации по формированию структуры продукта в системе PDM и структуры проектных подразделений, по управлению конфигурациями и изменениями, по созданию и управлению мастер-геометрией, проектированию деталей из композиционных материалов и многое другое.

Пример оформления методики проектирования


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

Для того чтобы оценить полноту реализации основных бизнес-процессов определенной отрасли, взгляните на набор решений компании Dassault Systemes для авиационной промышленности, представленный на рис. 6.



По вертикали размещены основные этапы жизненного цикла самолета – от концептуального дизайна до эксплуатации на авиалиниях. Горизонтальные ряды – группы бизнес-процессов, начиная от процессов в отделах продаж и маркетинга и заканчивая производством самолета. Из схемы видно, что практически все процессы создания, производства и эксплуатации самолета могут быть реализованы на базе PLM-решений компании Dassault Systemes.

Таким образом, в настоящее время компании-разработчики ПО создали превосходные инструменты по сохранению опыта предприятий при проектировании и производстве изделий, что способствует капитализации знаний предприятия. В связи с этим необходимы специалисты, которые могли бы разрабатывать и поддерживать базу знаний предприятия. Причем основа такой базы может быть построена разными способами: с использованием собственных разработок центров компетенции предприятия, при помощи компании-партнера или консультанта или посредством специальных отраслевых решений компаний- разработчиков ПО, о которых было подробно рассказано в этой статье на примере Центра отраслевых решений Dassault Systemes.


Источники:
1. Кошелев, В., Молочник, В. Что такое PLM?// САПР и графика, №10, 2003 [http://www.sapr.ru/article.aspx?id=8052&iid=325]
2. Оснач, Д., Нырков, Н. ЛОЦМАН:PLM – «центральная нервная система» комплекса АСКОН// САПР и графика, №6, 2003 [http://www.sapr.ru/article.aspx?id=7460&iid=304]
3. Лягушкин А. От программных продуктов – к отраслевым решениям// САПР и графика, №4, 2008. – С.54-58 [http://www.sapr.ru/article.aspx?id=18954&iid=880]
Дата: 22.07.2009

Комментарии специалистов Челябэнергопроект:
Нет
Статьи

смета проектных работ
©Челябэнергопроект – проектные работыinfo@chepr.ru, 2007-2013
DRA.RU - проектирование сайта под ключ; системный администратор ООО «Челябэнергопроект»
Главная|О компании|Стратегия|
Компетенция / услуги|Контакты
Сертификат качества