На головну

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

  1. Gt; завдання
  2. I. Бюрократичні структури управління
  3. II-2. 1. Постановка завдання прийняття рішень на дискретній керованому процесі

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-системою, управління системою безпеки, управління рідко мінливими даними (наприклад, структурою класифікаторів), налаштування системи, моніторингу її функціонування і т.п.



Стандарти єдиного інформаційного простору | Інтеграція структур даних і робота інтегрованої системи

Формування бази даних по виробу | Сценарії проектування виробничих систем | Визначення технологічної системи, структура, функції та постановка завдань проектування | Синтез технологічної системи | Вибір організаційно-технологічної форми технологічної системи | Вибір автоматизуються функцій | Моделювання технологічних систем | Використання елементів інтелектуального проектування при розробці автоматизованих виробничих систем | Завдання, які вирішуються інтегрованою системою управління інформаційним забезпеченням і підтримки життєвого циклу виробу | ИПИ-технології і концептуальна модель CALS |

© um.co.ua - учбові матеріали та реферати