[elib.tsogu.ru]_kompjuternye-tekhnologii...83-a5 (2)

Во-первых, в основе хранилища данных каждой PDM-системы лежит какая-либо коммерческая СУБД (система управления базами данных). Основными производителями реляционных (или объектно-реляционных)

СУБД являются Oracle, IBM (продукт DB/2), Informix, Microsoft (продукт

SQL Server), Sybase. Однако многие производители PDM-систем уже начинают рассматривать в качестве возможной альтернативы использование чисто объектных СУБД: Objectivity, CA Jasmine и др. Так или иначе, благодаря использованию современных СУБД в PDM-системах практически полностью решается проблема управления хранением данных и обеспечения авторизованного доступа к ним, а также создания географически распределенных хранилищ данных, что особенно важно для организаций, партнеры которых находятся в разных точках планеты.

Вторым принципом, заложенным в большинство реализаций PDMсистем, является поддержка стандартных форматов для обмена данными между системами, в первую очередь ISO 10303 STEP, а также IGES, COM, DXF и т.п.

Третьим принципом в последнее время становится поддержка различных компьютерных платформ. Если первые PDM-системы функционировали в основном под управлением ОС UNIX и VAX, то сейчас производители стараются ориентироваться и на более распространенные платформы

Microsoft, в частности Windows NT/ 2000/XP/Server 2003, а также на платформу Macintosh. В немалой степени это связано с тем, что пользователями PDM-систем стали не только конструкторы, традиционно имеющие в своем распоряжении мощные вычислительные ресурсы, работающие под управлением ОС UNIX, но и сотрудники других отделов, рабочим местом которых обычно являются компьютеры типа PC или Macintosh. Другим фактором, повлиявшим на перевод PDM-систем на семейство ОС Windows, является растущая популярность этой ОС, постепенно вытесняющей UNIX даже с традиционных позиций.

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

се MS Windows.

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

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

121

1. Фирмы, пришедшие в PDM-бизнес из области САПР и других инженерных прикладных программ. Это наиболее опытные участники, которые первоначально стали производить PDM-системы в качестве дополнения к своим САПР для управления создаваемой в них технической документацией. Их продукты, как правило, тесно интегрированы с соответствующей САПР, хотя могут работать и с другими программами. Яркими примерами являются компании РТС с продуктами Pro/Engineer (САПР) и Windchill (PDM), IBM с продуктами CATIA (САПР) и ENOVIA (PDM), EDS с продук-

тами Unigraphics (САПР) и iMAN (PDM). Из российских производителей в эту группу входит фирма «Топ Системы» (TopSystems) с продуктом T-Flex Docs, интегрированным с САПР T-Flex CAD.

2. Независимые компании — разработчики PDM-систем, которые изначально работали над системами управления данными об изделии. В эту группу входят компании EignerHPartner AG (продукт CADIM/EDB), Agile Software (продукт Agile) и др. Среди российских фирм ведущие роли занимают компания «Лоция Софт» с продуктом PartY PLUS и НИЦ CALS «Прикладная Логистика» с продуктом PDM STEP Suite. Их системы изначально ориентированы на интеграцию с широким спектром прикладных систем, в том числе на основе международных стандартов.

3.Фирмы, пришедшие в PDM-бизнес из других предметных областей,

вчастности из области ERP-систем. Например, серьезные позиции на рынке PDM-систем занимает производитель известной ERP-системы R/3 компания SAP AG. Существуют разработки в области PDM и у другого крупного производителя ERP-систем — фирмы Ваап.

5.2. Управление процессами

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

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

Типовыми задачами Project Management являются:

122

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

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

•разработка графиков потребности проекта в ресурсах;

•отслеживание хода выполнения работ и сравнение текущего состояния

сисходным планом;

•формирование управленческих решений, связанных с воздействием на процесс или с корректировкой планов;

•формирование различных отчетных документов.

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

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

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

•управление работой (рассматривают, что происходит с данными, когда кто-либо над ними работает);

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

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

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

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

еечертеж, что требовало от конструктора значительных усилий. Сейчас

123

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

Помимо очевидных преимуществ такой подход вызывает и определенные трудности, связанные с тем, что теперь конструктор может легко создавать огромное количество слегка отличающихся друг от друга моделей. Зачастую конструктор хочет лишь просто исследовать определенный новый подход с тем, чтобы в дальнейшем в случае необходимости отказаться от него в пользу предыдущего варианта. В результате проектировщику грозит опасность потерять актуальную модель и историю ее появления. Чтобы этого не случилось, PDM-система должна тщательно отслеживать и брать под свой контроль все новые или измененные данные, как только они были созданы, для чего использовать концепцию блочно-модульного проектирования. Основным методом в этом случае является отслеживание версий всех данных и управление ими. Например, в системе Windchill новая версия объекта создается автоматически при каждом его изменении (при этом старая версия также остается в системе). В качестве обозначения версии используется ее порядковый номер (первая версия, созданная при появлении самого объекта, получает номер «1» и т.д.). При таком подходе можно не только найти последнюю версию объекта, но и проследить историю его появления и, если необходимо, даже вернуться на несколько этапов назад при обнаружении ошибки.

При совместной работе над проектом изделия возникает еще одна проблема — обеспечение одновременного доступа к проектируемому объекту сразу нескольких сотрудников предприятия.

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

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

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

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

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

124

При этом исходная версия данного объекта или документа остается доступной всем авторизованным сотрудникам для чтения. По окончании изменения (или в случае отказа от изменения) сотрудник «возвращает» объект или документ с редактирования и тем самым снимает блокировку объекта от изменения.

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

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

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

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

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

125

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

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

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

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

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

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

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

126

например «представлены на рассмотрение», «проверены», «утверждены», «выпущены» и т.п. Таким образом, такие документы не могут быть переданы от одного сотрудника или группы сотрудников без изменения их состояния.

Рис. 5.2. Схема модели потока работ на примере ОАО «Раменский приборостроительный завод»:

ТБ — технологическое бюро; БТК — бюро технического контроля; ХМО — химико-металлургический отдел; ОГТ — отдел главного технолога; ЕОТД — единый отдел технической документации;

ТБРР — технологическое бюро разрешений и расцеховок; БНМ — бюро нормирования материалов

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

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

127

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

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

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

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

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

Проектная документация характеризуется разноплановостью и большими объемами. В процессе проектирования используют чертежи, конструкторские

128

спецификации, пояснительные записки, ведомости применяемости изделий, различного рода отчеты и др. Кроме того, в интегрированных САПР и АСУП

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

Для подготовки, хранения и сопровождения необходимых документов,

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

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

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

В рамках концепции CALS/ИПИ вся деятельность по управлению проектом протекает в ИИС и сопровождается оформлением предписанных стандартами различного уровня документов и данных и электронным обменом этими документами и данными по определенным правилам.

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

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

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

Распределенный характер ИИС в отличие от традиционных БД требует создания специальной инфраструктуры, обеспечивающей накопление,

129

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

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

Анализ сегодняшнего состояния телекоммуникационных средств и систем позволяет высказать утверждение, что основой инфраструктуры виртуального предприятия, а также предприятия с географически распределенной структурой может служить глобальная сеть Интернет, в которой данные передаются с помощью протокола TCP/IP. Несмотря на внешнюю простоту и доступность сети Интернет, использование этой сети в качестве структурообразующего средства связано с рядом специфических проблем.

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

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

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

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

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

130