Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Наряду с выполнением собственно проектных процедур необходимо автоматизировать также управление проектированием, поскольку сам процесс проектирования становится все более сложным и зачастую приобретает распределенный характер. На крупных и средних предприятиях заметна тенденция к интеграции САПР с АСУП и системами документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное ПО — системная среда САПР или АС, называемая в настоящее время системой управления проектными данными или системой PDM (Product Data management). Системы более общего характера, связанные с управлением данными на всех этапах жизненного цикла изделий и интеграцией различных промышленных автоматизированных систем, получили название систем управления жизненным циклом изделий или систем информационной поддержки изделий PLM (Product Lifecycle Management).

История систем управления проектными данными непосредственно связана с развитием систем автоматизированного проектирования. Появление системных сред в САПР ознаменовало переход от использования отдельных не связанных друг с другом программ, решающих частные проектные задачи, к применению интегрированной совокупности таких программ.

Интегрирующим компонентом в 70-е г.г. стала единая БД САПР. Однако попытки использовать имевшиеся в то время СУБД не приводили к удовлетворительным результатам в силу разнообразия типов проектных данных, распределенного и параллельного характера процессов проектирования, с одной стороны, и недостаточной развитости баз данных, с другой стороны.

Специализированные СУБД, ориентированные на САПР, были созданы в 80-е годы. Однако они не учитывали или в недостаточной степени удовлетворяли требованиям обеспечения целостности данных, управления потоками проектных работ, многоаспектного доступа пользователей к данным.

И лишь на рубеже 80-90 г.г. появились системы управления проектными данными, названные в то время Framework или системными средами, сначала в САПР электронной промышленности, а позднее и в САПР машиностроения, где они и получили наименование PDM.

На протяжении 90-х годов роль системных сред неуклонно повышалась. Во-первых, из-за роста сложности проектируемых объектов и необходимости сокращать сроки проектирования. Во-вторых, из-за необходимости интеграции систем проектирования с системами управления предприятием и технологическими процессами. Благодаря развитию Internet, Web- и CALS-технологий такая интеграция стала возможной в глобальном масштабе.

Современные системы управления проектными данными называют PDM. Они предназначены для информационного обеспечения проектирования и выполняют следующие основные функции:

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

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

К важнейшим функциям PDM относятся управление проектами и управление конфигураций изделий.

Рассмотрим остальные функции PDM.

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

Например, в системе PDM STEP Suite элементы дерева, представляющего структуру изделия, могут соответствовать сборочным узлам, агрегатам, блокам, отдельным деталям. Навигация по дереву позволяет просматривать относящиеся к структурным единицам документы, геометрические модели, чертежи и другие атрибуты.

В системе PDM, разработанной в свое время фирмой Cadence для своей САПР, была предусмотрена иерархическая организация проектных данных, описывающих проектируемые СБИС (сверхбольшие интегральные схемы), с выделением уровней библиотек, категорий, ячеек, видов. Ячейка — базовый объект, который может иметь несколько различных представлений (видов). Ячейки объединяются в родственные группы — категории, а категории — в библиотеки. Разработчик с помощью системной среды имел доступ к проектным данным, мог создавать свои библиотеки, ячейки, виды.

Интерфейс с пользователем поддерживается визуализацией данных проекта одновременно в нескольких окнах. Для визуализации данных разных аспектов в PDM имеется ряд браузеров. Типичные изображения структуры изделия, создаваемые браузерами, представляются иерархическим списком или графически в виде дерева изделия или его фрагментов. В других окнах могут быть помещены различные виды, такие как 2D чертеж или 3D изображение; описания моделей; принципиальные схемы; атрибуты объекта (исполнитель, номер версии, дата утверждения и т.п.). Иногда для визуализации и редактирования данных в PDM конкретной фирмы привлекаются браузеры и редакторы других изготовителей.

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

Рис. 1. Фрагмент дерева изделия

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

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

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

Типичная схема разделения рабочего пространства между параллельно работающими пользователями показана на рис. 2.

Рис. 2. Информационные связи разработчиков с зонами базы данных

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

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

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

Следует отметить, что параллельное проектирование (совмещенное проектирование), интеграция автоматизированных систем проектирования и управления на современных предприятиях возможны только в распределенной среде. Распределенные хранение и обработка информации в большинстве случаев осуществляются на базе применения технологий SOAP, CORBA или DCOM, языков Java и XML. Данные проекта при этом находятся в хранилищах данных, т.е. в нескольких базах распределенного банка данных. Находят применение трехзвенные распределенные системы с уровнями сервер баз данных — сервер приложений — клиенты. Принимаются меры по защите информации, типичные для корпоративных информационных систем. Разработаны рекомендации по внедрению операций с электронными цифровыми подписями.

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

В CALS-технологиях взаимодействие систем основано на стандартах STEP, поэтому в ряде PDM имеются конверторы из предложенного в STEP языка Express.

Адаптация САПР к условиям конкретных предприятий может быть осуществлена с помощью языков расширения. Язык расширения — язык программирования, позволяющий адаптировать и настраивать системную среду на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования. Для большинства языков расширения базовыми являются Lisp или C.

Управление инженерными и проектными данными. PDM - системы.

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

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

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

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

В системах PDM разнообразие проектных данных поддерживается их классификацией и соответствующим выделением групп с характерным множеством атрибутов. Часто структура изделия представляется в виде дерева. Step suite - элементы дерева могут соответствовать отдельным сборочным узлам или изделия. В PDM системах существуют модули CDO - для подготовки, хранения и сопровождения необходимых документов в системах PDM как правило имеются специализированные системы управления документами и документооборотом. Причем некоторые системы делопроизводства либо интегрированы в САПР, либо имеют средства для управления проектной, в том числе чертежно-конструкторской документацией. Для создания систем управления документооборота - Lotus Notes, Lotus Domino.

Возможности управления чертежно-конструкторской документацией, которая подготовлена в системе AutoCAD, Microstation в Docs Open, CADlink (Documentum Search).

Наряду с информацией PDM системы управляют процессом изготовления изделия. Наряду с данными система PDM управляет и проектом, то есть процессом разработки изделия, при этом контролируя информацию об изделии-продукте, о состоянии объекта, о утверждении вносимых изменений, осуществляя авторизацию и другие операции, которые влияют на данные об изделии и режим доступа к ним конкретного пользователя. Управление процессом проектирования включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом, то есть необходимо управление потоком работ, которое выполняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE системах, workflow

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

• программы верхнего уровня - Artemis Project, Primavera Project Planner, Open Plan;
• программы среднего уровня - Time Line, Microsoft Project, Spider Project.
• Можно выделить несколько уровней интеграции PDM системы и других компьютерных приложений, используемых на предприятии:
• Наиболее продвинутым уровнем интеграции является использование на предприятии единой модели данных. Это означает, что все компьютерные системы работают с единой, совместно используемой базой данных.
• Следующий уровень интеграции - прямой доступ к БД, то есть все компьютерные системы имеют свои базы данных, но каждая из них имеет возможность читать и писать данные в базе данных другой системы. Этот способ интеграции встречается на практике - iMan обладает способностью читать и писать данные во внешние базы данных, а также синхронизировать свою БД с внешними в режиме реального времени - T-Flex Docs.
• Наиболее распространенным уровнем интеграции является использование для организации взаимодействия систем прикладных программных интерфейсов.
• Самый простой уровень интеграции - использование файлов для обмена данными между системами. При осуществлении передачи данных от одной системы к другой, первая система будет генерировать файл, содержащий передаваемые данные, а вторая система читать этот файл и получать эти данные. В рамках STEP (ISO-10303).

Существует множество ПП, реализующих функции PDM системы. Большинство из них выполнены по схожим принципам:

· В основе хранилища данных лежит какая-либо коммерческая СУБД;

· Поддержка основных стандартных форматов для обмена данными между системами (STEP \ IGES \ CDM \ DXF);

· Использование различных платформ;

· Поддержка графического интерфейса с пользователем;

· Предоставление доступа к PDM системе через интернет.

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

• 1 группа - фирмы, перешедшие из области САПР - PTC (Pro/Engineer \ Windhill), IBM (CATIA \ ENOVIA), Unigraphics (Unigraphics \ iMan), SDRC (I-DEAS \ Metaphase), Топ-системы (T-Flex CAD \ T-Flex Docs).
• 2 группа - независимые разработчики PDM систем, которые изначально начали свою работы над PDM (их преимущество в том, что системы этих фирм изначально ориентированы на интеграцию с широким спектром прикладных систем, в том числе и на основе международных стандартов) - CADIM \ EDM, Agile Software \ Agile, Лоцесофт \ PartY, НИЦ CALS логиcтика - STEP Suite,
• 3 группа - фирмы, пришедшие в PDM из других предметных областей - SAPE AG - SAPR R3, BAAN.

Большинство крупных организаций сталкивается с трудностями в выполнении массового обслуживания ПО. Эти трудности носят как объективный, так и субъективный характер. Объективной трудностью является неоднородность ИТ-инфраструктуры, полностью преодолеть которую невозможно. Однако руководители ИТ-отделов и системные администраторы не всегда уделяют должное внимание этой проблеме. Главной субъективной трудностью является отношение к обслуживанию корпоративного ПО как к обслуживанию коробочного и, как следствие, вера в существование «магической зелёной кнопки»: нажал - и всё установилось (обновилось). На практике такой сценарий, увы, нереализуем.

В чём же заключается разница?

Установка коробочного продукта обычно выполняется по довольно простому «итерационному» сценарию: попробовал установить → не получилось → устранил проблемы → попробовал снова. Для установки «из коробки» такая последовательность оправдана, потому что в случае возникновения блокирующих проблем они локализованы на конкретном компьютере. При этом пользователь вполне может потратить немного личного времени на установку недостающих компонентов, настройку ОС и т. д. В целом, можно сказать, что 20 минут настройки одного рабочего места - вполне средняя цифра.

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

Далее, в случае распределенных систем блокирующие проблемы могут иметь произвольную локализацию в пределах сети, и для их устранения может потребоваться привлечение специалистов из других подразделений, поскольку, как правило, на большинстве предприятий организационные единицы, ответственные за общесистемное и продуктовое администрирование, разделены. Это требует дополнительных временных затрат. В целом, по нашей статистике, обновление 30 рабочих мест за один рабочий день силами четырех человек - вот предел ручной производительности труда.

Эффективное управление таким процессом при сколько-нибудь значительном количестве рабочих мест без отработанной методики невозможно. Суть этой методики заключается в том, что проблемы необходимо выявлять предварительно, а устранять - централизованно, причём делать это до выполнения обслуживания ПО. Казалось бы, всё просто? Но даже, если такая методика имеется, для её реализации необходим инструмент, не сложнее решаемой задачи.

Для автоматизации управления ИТ-инфраструктурой создано множество инструментов и решений, от самых простых, нацеленных, как правило, на автоматизацию типичных повторяющихся действий на рабочем месте (назовём их решениями «лёгкого класса»), до весьма сложных и изощренных (по аналогии можно сказать о решениях «среднего и тяжёлого классов»), охватывающих все или почти все аспекты управления.

Решения «лёгкого класса» нас не интересуют: с их помощью можно в лучшем случае обеспечить установку на рабочем месте драйверов и комплекта часто используемых программ типа офиса, архиваторов и т. п. Как правило, в их основе лежит простой скриптовый язык, исполняющий механизм которого может эмулировать консольный ввод, управлять окнами, процессами и другими объектами. Ограниченность таких решений вызвана в первую очередь тем, что в процессе придания скрипту универсальности (необходимой ему в силу неоднородности инфраструктуры) его сложность значительно возрастает, требуя от разработчика не только хороших навыков программирования, но и достаточно глубокого понимания архитектуры ОС и прикладного ПО. В условиях хронического недостатка времени и ресурсов, срочного решения задач, которые надо было «сделать вчера», использование «лёгких» решений не приводит к удовлетворительному результату.

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

Структура Комплекса решений АСКОН на платформе ЛОЦМАН:PLM, с ним и работает ЦОК

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

«Центр обслуживания Комплекса». Основные отличительные моменты решения

Легковесность с учетом специфики. Продукт не перегружен лишним функционалом, сфокусирован на максимально простом решении основной задачи - массовом обслуживании (установке, обновлении) продуктов АСКОН, таких, как ЛОЦМАН:PLM, САПР ТП ВЕРТИКАЛЬ, справочник Материалы и Сортаменты, справочник Стандартные изделия, КОМПАС-3D и других, с учетом их специфики.

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

Централизованная диагностика. Очевидно, что для успешного обслуживания ПО необходима работоспособная инфраструктура. Проблема в том, что продуктовые администраторы часто не имеют прямого доступа к центральным, жизненно важным объектам ИТ-инфраструктуры (AD DS, DNS, DHCP, групповые политики и пр.). И даже имей они его - просто ли с ходу разобраться в многоуровневой архитектуре, которую, к тому же, ещё и не ты проектировал? Поэтому сбор, хранение и отображение диагностической информации об аппаратной и программной конфигурации рабочих мест и основных настройках ОС критически необходима для обслуживания ПО. Опять же, осуществляется он лишь в том объёме, что необходим для практической работы. Частично решается задача инвентаризации аппаратуры и ПО.

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

Интеграция в продуктовый портфель. Как правило, крупные производители корпоративного ПО стараются тем или иным способом решать задачи массового обслуживания своих продуктов. До сих пор таких инструментов у АСКОН не было. Теперь мы делаем шаг на встречу заказчику и закрываем ещё один сегмент автоматизации бизнес-процессов.

В целом мы надеемся, что данное решение будет востребовано в промышленности и, прежде всего, при обслуживании сложных PDM/PLM-систем. Хотя, как уже было сказано выше, номенклатура обслуживаемого ПО ограничена только используемым для развертывания механизмом (Windows Installer). Правда, справедливости ради надо отметить, что вряд ли кому-нибудь придет в голову использовать для корпоративной системы «легкий» инсталлятор типа NSIS.

Ну и в качестве заключения немного конкретных цифр. Испытания системы в «боевых условиях» показали, что с её помощью даже при минимальном уровне начальной подготовки продуктивной среды можно обновлять/устанавливать от 65 до 70 компьютеров в час! Это что-то около минуты на один компьютер при том, что все операции может выполнить один человек. Сравнение с цифрами, приведенными в начале статьи (30 рабочих мест за один рабочий день силами четырех человек), подтверждает прирост производительности труда как минимум на порядок.

Александр Юхименко, руководитель группы разработки Единого инсталлятора Комплекса.

Руководитель направления производственных решений, СофтБаланс

PLM (англ. Product lifecycle management) дословно - это управление жизненным циклом изделий. Иными словами, PLM - это подход [концепция], основанный на централизации всей информации об изделиях в едином информационном пространстве.

Этот подход получил свое уверенное развитие за последние 10-15 лет на Западе, а также в Японии и ряде других развитых стран. Начиная примерно с 2010 года PLM - концепция плавно приходит и в российские предприятия, однако знания и опыт зарубежных производителей применяется на отечественном рынке не так методично, как это могло быть. Что же такое PLM-концепция, для каких целей она внедряется и какова роль в ней PDM-системы? Все это мы попытаемся понять в данной статье.

Этапы жизненного цикла

Концепция PLM на любом зрелом производственном предприятии предусматривает управление процессами всего жизненного цикла продукта, включая следующие стадии:

• Маркетинговые исследования
• Проектирование продукта
• Планирование и разработка процесса
• Закупка
• Производство или обслуживание
• Проверка
• Упаковка и хранение
• Продажа и распределение
• Монтаж и наладка
• Техническая поддержка и обслуживание
• Эксплуатация по назначению
• Послепродажная деятельность
• Утилизация и(или) переработка

В зависимости от специфики предприятия и самого продукта, каждый этап жизненного цикла должен быть представлен в той или иной степени детализации. Если проанализировать функционал современных ERP-систем, внедряемых на отечественных предприятиях - мы видим, что большая часть этапов так или иначе охвачена в ERP-системе: Маркетинг, Планирование, Закупки, производство, Продажа, Монтаж и даже Техобслуживание - все это блоки современной учетной системы.

Из наиболее важных на данном этапе развития промышленности, в ERP-системах не хватает одного важного блока - это Проектирование продукта . Ниже пойдет речь именно о проектировании, что в свою очередь предполагает разговор о CAD- и PDM-системах (Computer-Aided Design - Система автоматизированного проектирования, САПР. Product Data Management - система управления данными об изделии).

Проблемы производственных предприятий: предпосылки перехода на концепцию PLM

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

• Низкая скорость выведения продукта на рынок;
• Постоянный срыв сроков разработки и производства [при позаказном производстве];
• Большие затраты на содержание конструкторских бюро
• Низкая скорость разработки изделий, а также внесения изменений в конструкторско-технологическую документацию (КТД);
• Проблемы кооперации конструкторских бюро (КБ) и производственных подразделений;
• Малая эффективность управления на проектах разработки новой продукции;
• Низкое качество разрабатываемой и производимой продукции;
• Несоблюдение требований маркетинга и производства при проектировании;
• Ориентированность сотрудников компании на показатели объема (система мотивации по типу "чем больше - тем лучше").

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

Что внедрять: PDM или PLM?

Для начала, нужно четко для себя понять: что же такое PLM и PDM и как они между собой соотносятся? PLM - это концепция, которую использует руководство предприятия для достижения каких-то целей.

С точки зрения глобальных бизнес-целей производственного предприятия (имеющего собственные конструкторские подразделения) можно выделить две основных цели менеджмента:

• Уменьшение себестоимости разрабатываемой продукции;
• Сокращение времени выхода на рынок новых изделий.

Важно то, какими методами достигаются эти цели. Основным инструментом достижения этих целей как раз-таки и является PDM-система. Рассмотрим ниже основные способы реализации PLM-концепции посредством внедрения тех или иных возможностей современной PDM-системы.

Снижение непроизводственных затрат конструкторов и технологов при подготовке КТД

Основные две сущности, которые появляются в PDM-системе [в отличие от «ручного» проектирования] - это Электронная структура изделия (ЭСИ) и Электронная технология изготовления (ЭТИ). Основная идея в том, чтобы конструкторы и технологи занимались разработкой именно ЭСИ и ЭТИ, а не, например, чертежей и маршрутных карт. В контексте PLM-концепции данные документы являются лишь конечной стадией проектирования (простой печатной формой, если хотите).

Для конструкторов будет важнее всего тратить минимум времени на работу с деревом спецификаций в самой PDM-системе и максимум - на разработку непосредственно изделия в своей САПР (3D-модель, электрическая схема и пр.). Кстати, страх того, что конструктору придется тратить много времени на работу с ЭСИ в PDM-системе - это основная причина внутреннего сопротивления персонала конструкторского бюро при внедрении, поэтому крайне важно обращать на это внимание с самого начала и убеждать персонал, что при должном обучении конструктор начинает очень уверенно ориентироваться в практически в любой современной PDM-системе уже через 2-3 недели после начала работы.

В отличие от конструкторов - для технологов [в современном видении PLM-концепции] PDM-система является не просто «дополнительной нагрузкой», а основным рабочим инструментом по разработке технологических карт и маршрутов (иначе говоря - по разработке ЭТИ). Соответственно, здесь мы видим очевидное преимущество автоматизации: вместо разработки технологической документации в MS Word или, того хуже, в твердой копии технологи теперь имеют возможность именно проектировать технологию в электронном виде. Ускорение процесса при этом - многократное (технологи тратят в 2-3, а то и больше раз времени на рутинную «механическую»).

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

Это еще один очевидный плюс автоматизации: использование ЭСИ и ЭТИ позволяет достаточно легко [технически] организовывать поиск деталей и сборочных единиц (ДСЕ), покупных изделий (ПКИ), средств технологического оснащения (СТО) и прочих элементов конструкторско-технологического проектирования по применяемости . Отсюда - возможность наследования узлов и деталей из более ранних разработок (причем - не конкретного специалиста, а всего предприятия). Теперь вместо банального копирования или, того хуже - «изобретения велосипеда», специалисты-разработчики могут наследовать часть узлов, схем, деталей и даже частей маршрута или технологии из предыдущих разработок. Для этого достаточно найти нужный узел по применяемости (в т.ч. - воспользовавшись параметрическим поиском) и включить его в свой текущий проект в состав электронной структуры изделия, либо в состав технологической карты/маршрута (в зависимости от вида проектирования).

Наведение порядка в архиве КТД

Другая важная часть работы конструкторских бюро и департаментов технической [технологической] документации - это организация архива . Современная PDM-система позволяет вести т.н. электронный архив, когда вся документация на изделие или на тех. процесс (например - те же спецификации или технологические карты) хранится в электронном виде, а твердые копии формируются только по мере необходимости (например - для передачи внешнему подрядчику или заказчику - предприятию Министерства обороны). Однако на практически любом Электронный и бумажный архив.

Ускорение процесса разработки изделий

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

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

Руководителям проектов и топ-менеджерам производственного предприятия PLM-концепция и как инструмент - внедренная PDM-система дает значительную «прибавку» в прозрачности процессов проектирования и разработки: теперь, за счет оперативности получения информации о нарастающей структуре изделия или комплекса в любой момент времени можно без формирования ручных отчетов сотрудников о проделанной работе оценить процент выполнения задач на проекте и принять соответствующие управленческие решения в рамках управления конструкторским бюро. Внедренная PDM-система дает представление о том, где в бизнес-процессе узкие места. Как правило - данный аспект внедрения PLM позволяет находить точки неоправданного простоя персонала КБ, что в свою очередь помогает повышать исполнительскую дисциплину.

Формализация процесса разработки КТД

Как известно, внедрение любой системы (в т.ч. - PDM) в рамках одного из этапов сопровождается разработкой регламентирующих документов - как регламентов работы всего предприятия, отдельных подразделений (причем - не только КБ и ОТД, но и отдела закупок, диспетчера на производстве и т.д.), так и пользовательских инструкций, регламентирующих работу специалиста на конкретном рабочем месте. Это позволяет не только поддерживать текущую работу в области проектирования, но и без особых усилий со стороны начальника КБ вводить в курс дела новых сотрудников. Это значительно снижает зависимость компании от "незаменимых" работников, имеющих «монопольные» знания на своем участке.

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

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

Представим себе команду конструкторов, каждый из которых работает у себя дома, или, например, совместную работу двух КБ одного предприятия, удаленных друг от друга территориально. При внедрении PDM-системы, как системы коллективной разработки, автоматически отпадает необходимость очного присутствия всех участников разработки в одном офисе. Действительно: каждый разработчик работает, в своей CAD-системе которая может быть установлена у него локально на рабочей станции, далее результат своей работы он выгружает в PDM-систему, как законченную электронную структуру изделия. Данные выгружаются по каналам связи (например - по RDP и/или по VPN), в том числе - вся документация на изделие формируется и хранится в PDM в электронном виде. Таким образом, нет никакой необходимости «быть на рабочем месте». Что же касается управления проектной командой - общение с конструкторами руководитель проекта выполняет посредством постановки задач в системе управления проектами, либо через одно из средств организации телеконференций.

PLM - это концепция управления, а PDM - это инструмент реализации большей части положений этой концепции, но далеко не всех (например - такие этапы ЖЦ изделия, как закупки, планирование продаж и пр.). Соответственно, для получения максимального эффекта от внедрения PLM-концепции, нужно рассматривать все аспекты данной концепции, т.е. внедрять на всех этапах жизненного цикла изделия. Все сотрудники компании должны перестать оперировать понятием «Документ» (спецификация, чертеж и пр.) и перейти к понятию «Изделие », как ключевой объект деятельности. Конструктор должен не «выпустить документацию», а разработать изделие - учитывая все особенности производственного и тех. процесса, принимая во внимание все аспекты эксплуатации и прочих этапов жизненного цикла.

Заключение

Рассматривая многочисленные программные продукты, предназначенные для автоматизации деятельности конструкторских подразделений, мы задаем себе вопрос: «Почему при такой технической проработке вопроса реально завершенных внедрений остается так мало?».

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

УПРАВЛЕНИЕ ДАННЫМИ

Алексей Жирков,

Александр Колчин,

Михаил Овсянников,

Сергей Сумароков

В настоящее время аббревиатура PDM (Product Data Management) становится все более популярной. Объяснить это можно двумя причинами: во-первых, общим развитием информационных технологий, а во-вторых, тем, что промышленные предприятия приходят к необходимости комплексного подхода при автоматизации своей деятельности (так называемые CALS-, или ИПИ-технологии, см. PC Week/ RE, № 18/2001, с. 34). Таким образом, настала пора более пристально взглянуть на PDM-системы и постараться понять, что же они собой представляют и что могут дать предприятию.

PDM-технология . Одной из ключевых CALS-технологий является PDM-технология управления данными об изделии, которая позволяет решить две проблемы, возникающие при разработке и поддержке жизненного цикла (ЖЦ) наукоемкой промышленной продукции: управление данными об изделии и управление информационными процессами ЖЦ изделия, создающими и использующими эти данные.

Данные об изделии представляют собой всю информацию, созданную в течение ЖЦ. Они включают в себя состав и структуру изделия, геометрические параметры, чертежи, планы проектирования и производства, спецификации, нормативные документы, программы для станков с ЧПУ, результаты анализа, эксплуатационные данные и многое другое. Поскольку при их создании все чаще используются компьютерные средства, то поиск ответа на вопросы: “Существуют ли необходимые данные?”, “Где они находятся?”, “Являются ли они актуальными?” - не всегда представляется тривиальным.

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

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

PDM-система . Для реализации PDM-технологии существуют специализированные программные средства, называемые PDM-системами, - системы управления данными об изделии и информационными процессами ЖЦ. PDM-система может выступать в двух основных ролях:

Как рабочая среда сотрудника предприятия;

Как средство интеграции данных на протяжении всего ЖЦ изделия.

Управление потоками работ в системе iMAN

Рабочая среда сотрудника. PDM-система должна стать рабочей средой для любого сотрудника предприятия, которому необходимы данные о выпускаемых изделиях. В эту категорию входят не только конструкторы, технологи и работники технического архива, но и работники из других областей - сбыта, маркетинга, снабжения, финансов, сервиса, эксплуатации и т. п. Таким образом, сотрудник предприятия в процессе своей работы должен постоянно находиться в PDM-системе, а система в свою очередь обеспечивать все его информационные потребности, начиная от просмотра спецификации узла и заканчивая изменением твердотельной модели детали или ее утверждением у начальника. При необходимости она обращается к помощи других систем обработки данных (например, САПР), самостоятельно определяя, какое именно внешнее приложение необходимо применить для обработки той или иной информации. Главной задачей PDM-системы как рабочей среды сотрудника является предоставление каждому пользователю нужной ему информации в нужное время и в удобной форме (в соответствии с правами доступа). Ниже приведен классический перечень функций PDM-системы:

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

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

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

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

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

Структура изделия в системе PDM STEP Suite

- вспомогательные функции обеспечивают взаимодействие PDM-системы с другими программными средствами, с пользователями, а также взаимодействие пользователей друг с другом. Наиболее мощные системы позволяют производить “цифровую сборку” сложных изделий из нескольких трехмерных моделей, созданных различными организациями в разных САПР.

Средство интеграции данных на протяжении ЖЦ . Важной задачей PDM-системы является также интеграция данных об изделии на протяжении всего ЖЦ. Фактически на предприятии существует два центра интеграции данных: АСУП и PDM-система. Но если АСУП интегрирует данные в основном о ресурсах предприятия, то PDM-система - о продукте. Кроме того, на предприятии существуют прикладные компьютерные системы, которые создают и обрабатывают данные об изделии. Таким образом, можно выделить два направления интеграции данных - вертикальное (PDM и прикладные системы) и горизонтальное (PDM-система и АСУП).

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

Сотрудник избавляется от непроизводительных затрат времени на поиск, копирование и архивирование данных, что при работе с бумажной документацией составляет 25-30% времени;

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

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

Увеличиваются доли заимствованных компонентов в изделии (до 80%) за счет упрощения процедуры поиска детали с необходимыми характеристиками.

При использовании систем автоматизированного проектирования и подготовки производства качество изделия зависит не столько от качества проектирования, сколько от состояния данных (т. е. их полноты, корректности, актуальности). PDM-система позволяет значительно улучшить это состояние и соответственно повысить качество самого изделия.

В настоящее время на российском рынке имеется ряд программных продуктов, реализующих PDM-технологию. Их производителей можно разделить на две группы: фирмы - разработчики САПР, которые предлагают еще и PDM-решения, и независимые поставщики. К первой можно отнести две “тяжелые” системы: iMAN (UGS, США) и Windchill (PTC, США), а также систему T-FLEX DOCs (“Топ Системы”, РФ). Ко второй группе относятся PartY PLUS (“Лоция Софт”, РФ), PDM STEP Suite (НИЦ CALS “Прикладная логистика”, РФ) и Search (“Интермех”, Белоруссия).

Центры интеграции на предприятии

У любой PDM-системы есть свои достоинства и недостатки, поэтому важно принять правильное решение по выбору продукта. Нужно также учитывать, что их внедрение представляет собой непростую задачу и требует адаптации к нуждам предприятия. Вопросы выбора и внедрения PDM-систем на отечественных промышленных предприятиях нуждаются в более детальном рассмотрении. 4