Реализация задачи интеграции PDM-системы и системы управления проектами

4.3.1. Электронные модели изделий, процессов и ресурсов

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

Рис. 4.6. Информационные модели изделия, процессов и ресурсов

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

Классификация информационных моделей и их связь со стадиями ЖЦ приведены в таблице 4.1.

Таблица 4.1

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

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

Рис. 4.7. Схема построения интегрированной модели изделия

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

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

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

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

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

Рис. 4.8. Классификационные характеристики ресурсов

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

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

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

ЭМИ обладает следующими особенностями:

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

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

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

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

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

Многообразие предметных областей, охватываемых ЭМИ, требует наличия данных, описывающих эти предметные области. Такие данные по отношению к данным об изделии являются словарными метаданными.

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

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

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

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

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

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

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

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

1. Функциональные стандарты. Задают организационную процедуру взаимодействия компьютерных систем; пример: IDEF0;

2. Стандарты на программную архитектуру. Задают архитектуру программных систем, необходимую для организации их взаимодействия без участия человека; пример: CORBA;

3. Информационные стандарты. Задают модель данных об изделии, используемую всеми участниками ЖЦ;

4. Коммуникационные стандарты. Задают способ физической передачи данных по локальным и глобальным сетям; пример: Internet-стандарты.

Рассмотрим требования к ЭМИ подробнее.

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

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

Средства поддержки ЭМИ должны обеспечивать возможность соблюдения регламентов и процедур процесса проектирования. То есть, документооборот КТД должен быть построен на основе общепринятых ГОСТов, устоявшихся международных стандартов (вроде IGES, Gerber, и т.п.). Это необходимо для обеспечения целостности и корректности ЭМИ: изменения моделей должны происходить в управляемых условиях, в соответствии с принятыми регламентами, например, процессом изменения по извещениям на изменение.

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

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

Стандарт ISO 10303 STEP и его подраздел AP203 определяет представление конструкторских данных об изделии согласно концепции управляемой конфигурации. Термин «управляемая конфигурация» означает возможность определения комплектации изделия в зависимости от условий проектирования, производства или заказа. Современный рынок все больше поворачивается лицом к потребителю, сам продукт становится всё более конфигурируемым и настраиваемым, вплоть до позаказной конфигурации под каждый заказ отдельно. Более того, согласно стандартам обеспечения качества ISO серии 9000, поставщик обязан предоставить потребителю возможность выбора комплектации изделия. При этом не любая возможная комбинация опций допустима: например, при сборке компьютера из комплектующих слишком большой вентилятор может не помещаться с этой моделью памяти, или видеокарта может не помещаться в этот корпус. Поэтому при управлении конфигураций требуется отслеживать конфигурации, не приводящие к конфликтам, к проблемам в сборке в целом. В PDM-системе Search управляемая конфигурация называется комплектом. Конфигуратор комплектов позволяет собрать конфигурацию и проверить её на конфликты, затем сохранить как единое целое, типовой комплект/конфигурацию.

Средства поддержки ЭМИ должны обеспечивать преобразование информации, получаемой из различных источников в стандартный электронный вид. В процессе проектирования ЭМИ наполняется данными, при этом не все данные могут быть получены сразу в желаемом виде. Средства поддержки должны обеспечивать преобразование информации, получаемой из различных источников, в стандартизованную форму. Это означает унификацию используемых форматов (например, .doc, .docx для файлов Word, стандартные форматы для картинок).

В общем случае информация об изделии может быть получена из следующих источников:

- непосредственно в формате STEP из систем CAD/CAM;

– преобразованием форматов электронных данных, полученных в различных автоматизированных системах;

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

Такие документы, как правило, хранятся в форматах PDF. В дальнейшем могут быть распознаны и преобразованы в формат какой-то CAD системы.

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

Учитывая это, а также то, что потребителю необходимы только эксплуатационные данные об изделии, в качестве средства доступа к ЕИП он будет использовать не PDM-систему, а ИЭТР. ИЭТР разрабатывается поставщиком, обеспечивает доступ потребителя к эксплуатационной информации об изделии в ЕИП и имеет стандартный интерфейс пользователя (например, согласно MIL-M-87268), что позволяет сотрудникам эксплуатирующей организации одновременно обслуживать изделия от разных поставщиков.

4.3.2. Интеграция PDM и PPE

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

Для решения проблемы интеграции PDM-системы и системы управления проектами (PPE) необходимо:

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

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

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

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

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

Для реализации интеграционного решения необходимо выделить атрибуты работы из календарно-сетевого графика, которые будут наследоваться в WF:

§ Срок старта работы.

§ Величина отклонения от планового срока старта (в числе дней со знаком + или -).

§ Длительность работы (необходима для оценки длительности задач процесса).

§ Информация об элементах работы.

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

§ Ресурсы, выделенные для выполнения работы.

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

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

Рис.4.9. Концептуальная схема совместной работы PPE и модуля управления WF в PDM-системе

При планировании и реализации конкретного проекта информация посредством интеграционного модуля, передается между PPE и PDM-системой. Рассмотрим этот процесс подробнее:

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

2. Выполняется, в соответствии с календарно-сетевым графиком, детализация работ по проекту отдельными WF в PDM-системе (указываются необходимые шаблоны).

3. Производится выбор необходимых шаблонов из базы шаблонов, построенных на основании выполненных или виртуальных бизнес-процессов предприятия.

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

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

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

4.3.3. Управление хранением данных и документов

В PDM-системе применяются два основных способа хранения данных:

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

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

В то же время, документ сам является объектом в системе, имеющим определенные свойства.

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

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

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

Данные и документы хранятся в специальной системе “хранилище данных”, которая обеспечивает:

· целостность данных;

· контроль доступа;

· поиск;

· архивирование.

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

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

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

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

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

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

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

Функции управления процессами в PDM-системе предназначены для контроля способов создания и изменения данных. Может показаться, что «управление процессами» является лишь новым названием для уже известного «календарного планирования», однако это не так. Календарное планирование занимается лишь распределением задач по ресурсам (или наоборот), а управление процессами касается поддержки процедур жизненного цикла и их влияния на данныеоб изделии.

Среди функций управления процессами можно выделить три основные группы:

· Управление работой. Эти функции касаются того, что происходит с данными, когда кто-либо над ними работает;

· Управление потоком работ. Эти функции управляют передачей данных между людьми;

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

Управление работой (рис. 4.10).

PDM-система выступает в качестве рабочей среды пользователя:

· управляет версиями данных и документов;

· управляет папками с данными и документами.

Рис. 4.10. Управление работой

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

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

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

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

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

4.3.5. Управление потоком работ

Управление потоком работ – управление передачей данных, документов и задач между участниками проекта, заключается в следующем:

· моделирование потока работ при помощи маршрутного листа папки;

· отслеживание руководством хода проекта;

· контроль взаимозависимости работ проекта.

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

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

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

Возвращаясь к состояниям папки, следует заметить, что от того, как реализован способ задания состояний папки (задачи) в PDM-системе, зависит гибкость, предоставляемая PDM-системой участникам проекта.

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

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

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

4.3.6. Протоколирование работы

Протоколирование работы – отслеживание и фиксация истории развития проекта. Протоколирование работы необходимо:

· для сертификации на соответствие ISO 9000;

· для отката к определенной точке в истории проекта.

PDM-системы по-разному протоколируют работу.

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

Календарное планирование.

Календарное планирование заключается в следующем:

· разбиение проекта на отдельные задачи;

· задание взаимосвязей между задачами;

· распределение ресурсов между задачами;

· отслеживание хода проекта.

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

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

Вспомогательные функции.

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

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

· Функции транспортировки данных. Эти функции предназначены для перемещения данных (документов) из хранилища в прикладную систему (например, САПР) и обратно.

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

· Функции обработки изображений. Эти функции предназначены для управления изображениями, хранимыми в PDM-системе, доступу к ним и их просмотру. Отдельную нишу занимают функции визуализации трехмерных моделей изделия, созданных в какой-либо САПР.

· Функции администрирования. Эти функции предназначены для управления самой PDM-системой, управления системой безопасности, управления редко меняющимися данными (например, структурой классификаторов), настройки системы, мониторинга ее функционирования и т.п.