Лабораторна робота № 1

Тема: «Застосування нотації IDEF₀ для опису та моделювання бізнес-процесів»

Мета: вивчити можливості застосування моделі IDEF₀ для побудови візуальної моделі управління системою як сукупністю бізнес-процесів (на прикладі ситуативної задачі «ВИВЧИТИ КУРС УБП».

Задачі:

· Вивчити операційні можливості програмного продукту Processs Modeler r7, порядок роботи із ним у нотації IDEF₀ для опису та моделювання бізнес-процесів

· Розробити ТОР та сontext- модель процесу, назвати і описати зміст, вимоги до елементів бізнес-процесів (продукти, регламенти, ресурси), а також критерії, порядок відбору і форми документування даних про стан протікання під процесів та їх продуктів.

Теоретичні положення за темою лабораторної роботи

Моделювання бізнес-процесів – це відображення суб’єктивного бачення реально існуючих в організації процесів при допомозі графічних, табличних і текстових способів представлення.

Для рішення завдань моделювання складних систем існують перевірені методології і стандарти. До таких стандартів відносяться методології сімейства IDEF.

IDEF₀ - методологія функціонального моделювання. За допомогою наочної графічної мови IDEF₀, досліджувана система з'являється перед розроблювачами й аналітиками у вигляді набору взаємозалежних функцій (функціональних блоків - у термінах IDEF₀). Як правило, моделювання засобами IDEF₀ є першим етапом вивчення будь-якої системи.

Графічна мова IDEF₀ є проста і гармонійна. В основі методології лежать чотири основних поняття:

· функціональний блок (Activity Box)

· інтерфейсні дуги (Arrow)

· декомпозиція (Decomposition)

· глосарій (Glossary).

Функціональний блок графічно зображується у вигляді прямокутника (див. Рис.1.1.) і персоніфікує собою деяку конкретну функцію в рамках розглянутої системи. Згідно вимог стандарту назва кожного функціонального блоку повинна бути сформульована у формі дієслова.

Кожна із чотирьох сторін функціонального блоку (процесу) має своє певне значення (роль, елемент процесу), при цьому:

· верхня сторона має значення “Регламент” (Control);

· ліва сторона має значення “Вхід” (Input);

· права сторона має значення “Вихід” (Output);

· нижня сторона має значення “Ресурс (механізм” (Mechanism).

Кожен елемент процесу визначається у своєму змісті у визначеній послідовності (1-2-3-4-4), рис. 1.1..

Інтерфейсні дуги часто називають потоками або стрілками. Інтерфейсна дуга відображає елемент системи, що трансформується функціональним блоком або робить інший вплив на функцію, відображену даним функціональним блоком.

Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label), що сформульовано у формі іменника.

Рис. 1.1. Візуальна модель та порядок опису бізнес-процесу

За допомогою інтерфейсних дуг відображають різні об'єкти, у тій або іншій мірі визначальні процеси, що відбуваються в системі. Такими об'єктами можуть бути елементи реального світу (деталі, вагони, співробітники й т.д.) або потоки даних та інформації (документи, дані, інструкції і т.д.).

Залежно від того, до якої зі сторін підходить інтерфейсна дуга, вона зветься “входом”, “виходом” або “керуючим регламентом”. Крім того, “джерелом” (початком) і “приймачем” (кінцем) кожної функціональної дуги можуть бути тільки функціональні блоки, при цьому “джерелом” може бути тільки вихідна сторона блоку, а “приймачем” кожна із трьох, що залишилися.

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

При побудові IDEF₀-моделей важливо правильно відокремлювати вхідні інтерфейсні дуги від регламентних, що часто буває непросто.

Обов'язкова наявність регламентних інтерфейсних дуг є однією з головних відмінностей стандарту IDEF₀ від інших методологій класу DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

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

Принцип декомпозиції застосовується при розбивці складного процесу на складові його блоки. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

Модель IDEF₀ завжди починається з подання системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що простираються за межі розглянутої області. Така діаграма з одним функціональним блоком називається ТОР-діаграмою, і позначається ідентифікатором “А-0”.

У пояснювальному тексті до ТОР-діаграми повинна бути зазначена мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).

Визначення і формалізація мети розробки IDEF₀-моделі є вкрай важливим моментом. Фактично ціль визначає відповідні області в досліджуваній системі, на яких необхідно фокусуватися в першу чергу. Наприклад, якщо ми моделюємо діяльність підприємства з метою побудови надалі на базі цієї моделі інформаційної системи, те ця модель буде істотно відрізнятися від тієї, яку б ми розробляли для того ж самого підприємства, але вже з метою оптимізації логістичних ланцюжків.

Точка зору визначає основний напрямок розвитку моделі та рівень необхідної деталізації. Чітке фіксування точки зору дозволяє розвантажити модель, відмовившись від деталізації і дослідження окремих елементів, що не є необхідними, виходячи з обраної точки зору на систему. Наприклад, функціональні моделі того самого підприємства з точок зору головного технолога і фінансового директора будуть істотно розрізнятися за спрямованістю їхньої деталізації. Це пов'язане з тим, що в остаточному підсумку, фінансового директора не цікавлять аспекти обробки сировини на виробничих верстатах, а головному технологові ні до чого описані схеми фінансових потоків. Правильний вибір точки зору істотно скорочує тимчасові витрати на побудову кінцевої моделі.

У процесі декомпозиції, функціональний блок, що у ТОР-діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Діаграма другого рівня містить функціональні блоки, що відображають головні підфункції функціонального блоку ТОР-діаграми називається дочірньою (Child diagram) і кожний з функціональних блоків, що належать дочірній діаграмі відповідно називається дочірнім блоком (Child Box). У свою чергу, функціональний блок - предок називається батьківським блоком стосовно дочірньої діаграми (Parent Box), а діаграма, до якої він належить - батьківською діаграмою (Parent Diagram). Кожна із підфункцій дочірньої діаграми може бути далі деталізована шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному випадку декомпозиції функціонального блоку всі інтерфейсні дуги, що входять у даний блок, або вихідні з нього фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF₀-моделі. Наочно принцип декомпозиції представлений на рис.1.2. Варто звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм. Кожен блок має свій порядковий номер на моделі (цифра в правому нижньому куті прямокутника), а позначення під правим кутом указує на номер дочірньої для цього блоку моделі. Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.

Позначення “тунелю” (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги означає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася з “тунелю” (тільки на цій діаграмі). У свою чергу, таке ж позначення навколо кінця стрілки інтерфейсної дуги в безпосередньої близості від блоку-приймача означає, що в дочірній стосовно цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії. У такому випадку, вони спочатку “поринають у тунель”, а потім, при необхідності “повертаються з тунелю”.

Останнім з понять IDEF₀ є глосарій (Glossary). Для кожного з елементів IDEF₀: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення та підтримка набору відповідних визначень, ключових слів, оповідальних викладів і т.д., які характеризують об'єкт, відображений даним елементом. Цей набір називається глосарієм та є описом сутності даного елемента. Наприклад, для регламентної інтерфейсної дуги “розпорядження про оплату” глосарій може містити перелік полів відповідній дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочна графічна мова, розвиваючи діаграму необхідною додатковою інформацією.

Наочність графічної мови IDEF₀ робить модель цілком зрозумілою і для осіб, які не приймали участі в проекті її створення, а також ефективною для проведення показів і презентацій. Надалі, на базі побудованої моделі можуть бути організовані нові проекти, націлені на проведення змін на підприємстві (у системі).

При застосуванні процесного підходу, як методу забезпечення життєдіяльності системи управління, важливо передбачати:

а) розуміння і виконання вимог споживача;

b) необхідність розгляду процесів з точки зору додавання споживчої цінності;

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

d) постійне покращення процесів, що опирається на об’єктивність їх вимірювання;

Формуючи модель управління організацією за допомогою процесного підходу, ми робимо акцент не на ієрархічному підпорядкуванні у функціональних підрозділах, а на створенні проектних команд, де визначається власник процесу – відповідальний за хід та результат всього процесу в цілому, в тому числі відповідальний за роботу різних функціональних підрозділів. Роль власника процесу полягає не втім, щоб управляти повсякденною рутиною кожної із складових частин процесу, а в тому, щоб управляти створенням додаткової цінності для споживачів процесу.

Процеси системи менеджменту включають в себе не лише процеси створення продукції (безпосереднє виробництво продукції і надання послуг), але і процеси управління, моніторингу та вимірювання, процеси управління ресурсами, поінформування, внутрішнього аудиту, аналізу зі сторони керівництва та інші процеси, що забезпечують системність управлінського впливу на функціонування організації.

Принцип системного підходу до управління встановлює, що „ виявлення, розуміння та менеджмент взаємопов’язаних процесів як системи, сприяє результативності та ефективності організації у досягненні поставлених цілей ”.