Студопедия — Така схема може бути складена шляхом використання різних графічних елементів для різних операцій, як описано в роботі [13 ].
Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Така схема може бути складена шляхом використання різних графічних елементів для різних операцій, як описано в роботі [13 ].






Можуть використовуватись різні схеми, які мають два виміри: процес - функція, процес - час і т.п.. Приклад такої схеми показаний на рис. 10.

Для вирішення завдань моделювання складних систем існують добре апробовані методології та стандарти. До таких стандартів належать методології IDEF [14-16]. З їхньою допомогою можна ефективно відображати й аналізувати моделі діяльності широкого спектра складних систем у різних розрізах. При цьому широта й глибина обстеження процесів у системі визначається самим розроблювачем, що дозволяє не перевантажувати створювану модель зайвими даними. У даний момент до сімейства IDEF можна віднести наступні стандарти [15]:

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

· IDEF1 – методологія моделювання інформаційних потоків всередині системи, що дозволяє відображати та аналізувати їх структуру й взаємозв’язки;

 

 

Рис. 9. Спрощена блок-схема процесів обслуговування на СТО.

 

Рис. 10. Схема процес - функція.

· IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій “Сутність - взаємозв’язок” (ER – Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до системи, яка розглядається;

· IDEF2 - методологія динамічного моделювання розвитку систем. У зв'язку з досить серйозними складностями аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. Однак у цей час існують алгоритми і їхні комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі “кольорових мереж Петрі” (CPN - Color Petri Nets);

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

· IDEF4 - методологія побудови об’єктно - орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів і закладені принципи їхньої взаємодії, тим самим дозволяючи аналізувати й оптимізувати складні об’єктно - орієнтовані системи;

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

 

У наш час найбільш часто використовується методологія функціонального моделювання IDEF0 і методологія документування процесів IDEF3.

Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках програми автоматизації промислових підприємств, що носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). У процесі практичної реалізації, учасники програми ICAM зіштовхнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. З 1981 року стандарт IDEF0 дещо змінився. Остання його редакція була випущена в грудні 1993 року Національним Інститутом з стандартів і технологій США (NIST, http://www.nist.gov) і прийнята як федеральний стандарт США (http://www.idef.com/IDEF0.html), а в 2000 році - як керівний документ зі стандартизації в Російській Федерації [16].

Національним технічним комітетом зі стандартизації «Управління якістю» Республіки Бєларусь в 2001 році розроблений проект нормативного документу ТК РБ 4.2-Р-05-2001 «Методика й порядок робіт з визначення, класифікації й ідентифікації процесів і побудови карт процесів», що базується на російському стандарті [16].

 

Докладніше про методологію функціонального моделювання.

В основі методології IDEF0 лежать чотири основних поняття:

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

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

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

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

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

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

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

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

 

Рис. 11. Функціональний блок [15].

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

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

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

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

При побудові IDEF0 - діаграм важливо правильно відокремлювати вхідні інтерфейсні дуги від управляючих. Наприклад, на рис. 12 [15] зображений функціональний блок “Обробити заготівку”.

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

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

Рис. 12. Функціональний блок «Обробити заготовку» [15].


Рис. 13. Функціональний блок «Коректувати технологічні вказівки» [15].

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

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

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

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

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

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

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

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

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

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

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

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


Рис. 14. Декомпозиція функціональних блоків [15].

Звичайно IDEF0-моделі несуть у собі складну й концентровану інформацію, і для того, щоб обмежити їхню перевантаженість і зробити зручними для читання, у відповідному стандарті прийняті відповідні обмеження складності:

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

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

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

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

  • Створення моделі групою фахівців з різних сфер діяльності підприємства. Ця група в термінах IDEF0 називається авторами (Authors). Побудова первісної моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів і результатів опитувань створюється чернетка (Model Draft) моделі.
  • Поширення чернетки для розгляду, погоджень і коментарів. На цій стадії відбувається обговорення чернетки моделі з широким спектром компетентних осіб (у термінах IDEF0- читачів) на підприємстві. При цьому кожна з діаграм чорнової моделі письмово критикується й коментується, а потім передається авторові. Автор, у свою чергу, також письмово погоджується із критикою або відкидає її з викладом логіки рішення й знову повертає відкоректовану чернетку для подальшого розгляду. Цей цикл триває доти, поки автори й читачі не прийдуть до єдиної думки.
  • Офіційне затвердження моделі. Затвердження погодженої моделі відбувається керівником робочої групи в тому випадку, якщо в авторів моделі й опонентів відсутні розбіжності з приводу її адекватності. Остаточна модель являє собою узгоджене подання про підприємство (систему) із заданої точки зору й для заданої мети.

При побудові IDEF-діаграми необхідно відповісти на наступні питання:

  • Що надходить у підрозділ “на вході”?
  • Які функції, і в якій послідовності виконуються в рамках підрозділу?
  • Хто є відповідальним за виконання кожної з функцій?
  • Чим керується виконавець при виконанні кожної з функцій?
  • Що є результатом роботи підрозділу (на виході)?

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

4.5. Методологія моделювання бізнес-процесів на підприємстві

4.5.1. Загальні підходи до опису бізнес-процесів

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

(http://www.tengrygroup.com/consulting).

Для управління бізнес-процесом повинні бути розроблені документи, що представлені на рис. 15.

Рис. 15. Документи для управління бізнес-процесом.

 

Згідно з таким стандартом на підприємстві необхідно зробити описи всіх бізнес-процесів.

Опис бізнес-процесу має включати такі елементи [7]:

1. Текстовий опис моделі регламентованого бізнес-процесу;

2. Матрицю відповідальності за виконання операцій, що входять до складу бізнес-процесу.

3. Графічні моделі регламентованого бізнес-процесу (графічні схеми);

4. Перелік цільових показників бізнес-процесу;

5. Регламенти, що визначають періодичність і порядок аналізу результатів діяльності бізнес-процесу для:

а) оцінки відповідності бізнес-процесу поставленим цілям;

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

в) прийняття попереджуючих дій за відхиленнями, що передбачаються;

г) встановлення цільових показників бізнес-процесу на наступний період.

6. Регламент аналізу з боку власника бізнес-процесу;

7. Регламент аналізу з боку керівника.

 

У додатку до опису приводяться такі документи (див. Додаток):

 

1. Положення, посадові й робочі інструкції.

2. Специфікація операцій бізнес-процесу (БП-Ф01).

3. Специфікації входів/виходів (БП-Ф02).

4. Специфікації на ресурси (БП-Ф03).

5. Графічні схеми бізнес-процесу і їхній текстовий опис (БП-Ф04).

6. Показники бізнес-процесу (БП-Ф05).

7. Глосарій (БП-Ф06).

8. Перелік документів бізнес-процесу (БП-Ф07).

 

При описі бізнес-процесу повинна бути зібрана інформація, представлена нижче в таблиці.

 

Характеристи-ки бізнес-процесу Інформація з бізнес-процесу, що підлягає збору Документ, у який включається зібрана інформація (посилання на форму документа)
  Назва й призначення бізнес-процесу Назва бізнес-процесу. Призначення бізнес-процесу. Замовник робіт з опису бізнес-процесу. Робочі документи (проект регламенту виконання бізнес-процесу)
  Інформація про підрозділ або підрозділи 1. Повна й скорочена назва підрозділу (або підрозділів), що виконує бізнес-процес або бере участь у виконанні процесу. 2. Додаток. Схема організаційної структури підрозділу. Посилання на документи (Положення про підрозділи) у формі БП-Ф07
  Власник бізнес-процесу Посада. Посилання на посадову інструкцію власника бізнес-процесу або Положення про підрозділ, або на розпорядницький документ, що визначає сферу відповідальності власника бізнес-процесу. Посилання на документи (Посадова інструкція) у формі БП-Ф07
4. Основні операції Надається перелік основних операцій, що виконуються при проведенні бізнес-процесу, і відповідальні за їхнє виконання в підрозділі. Форма БП-Ф01
5. Клієнти й виходи бізнес-процесу Перелік клієнтів бізнес-процесу із вказівкою одержуваних ними виходів Форма БП-Ф02
5.1 Вихід 1 бізнес-процесу Виходи бізнес-процесу: продукт, послуга, документ, інформація. Коротка специфікація виходу або посилання на неї. Споживач: (указується, хто є споживачем даного виходу бізнес-процесу). Форма БП-Ф02
5.2 Вихід 2 бізнес-процесу (див. пп. 5.1) Форма БП-Ф02
6. Входи бізнес-процесу і перелік постачальників Перелік входів бізнес-процесу й постачальників цих входів. (БП-Ф02). Форма БП-Ф02
6.1 Вхід 1 бізнес-процесу Входи бізнес-процесу: продукт, послуга, документ, інформація. Коротка специфікація входу або посилання на неї. Постачальник:... (указується, хто є постачальником даного входу або зовнішнім ініціатором дій у даному підрозділі). Форма БП-Ф02
6.2 Вхід 2 бізнес-процесу (див. пп. 6.1) Форма БП-Ф02
7. Ресурси 1. Перераховуються ресурси, які використовуються при проведенні бізнес-процесу. Коротка специфікація на кожен ресурс або посилання на документ. 2. Постачальник даного ресурсу. Форма БП-ФОЗ
8. Графічні схеми бізнес-процесу і їх текстовий опис Графічні схеми й текстовий опис бізнес-процесу. Форма БП-Ф04
9. Показники бізнес-процесу Інформація заноситься у форму БП-Ф05. Форма БП-Ф05
9.1 Показники бізнес-процесу 1. Заповнюються назви кількісних показників, що характеризують хід бізнес-процесу, абсолютні й/або відносні витрати на його проведення. 2. Посилання на документ, де зафіксовані даний показник і методика його розрахунку (або опис цієї методики). 3. Використання показника для: а) прийняття управлінських рішень; б) звіту перед вищестоящим керівником. Форма БП-Ф05
9.2 Показники продукту бізнес-процесу Заповнюються назви кількісних показників, що характеризують продукт (вихід) бізнес-процесу. Форма БП-Ф05
9.3 Показники задоволеності споживача бізнес-процесу Заповнюються назви кількісних показників, за якими можна оцінити ступінь задоволеності споживача (замовника) результатами бізнес-процесу. Форма БП-Ф05
  Глосарій термінів Терміни, які використані при виконанні бізнес-процесу. Форма БП-Ф06
  Перелік документів бізнес-процесу Перелік і короткий опис документів, які використані при виконанні, описі й регламентації бізнес-процесу. Форма БП-Ф07

 

 

4.5.2. Текстовий опис моделі бізнес-процесу

 

При описі бізнес-процесу на верхньому рівні в обов'язковому порядку повинні бути вказані:

· назва бізнес-процесу;

· входи бізнес-процесу;

· виходи бізнес-процесу;

· виконавець – структурні підрозділи організації, окремі працівники зовнішні (стосовно організації) виконавці;

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

· перелік операцій бізнес-процесу.

 

При формуванні мережі бізнес-процесів описуються:

1) значимість і трудомісткість операцій, що виконуються в бізнес-процесі;

2) їхнє відношення до основної діяльності даного підрозділу (бізнес-процесу);

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

 

Коротко характеризуються показники бізнес-процесу й способи їх досягнення.

 

4.5. 3. Матриця відповідальностей за виконання операцій бізнес-процесу

 

Форма матриці відповідальностей по бізнес-процесу має вигляд:

 

Найменування операції бізнес-процесу      
    Вик Вл У
    Вл У Вик
    Ін

 

Вл – власник процесу - відповідальний за проведення й кінцевий результат роботи;

У – бере участь у проведенні роботи;

Ін – одержує інформацію про проведення бізнес-процесу (роботи) і результати.

Вик 1, Вик 2 …- виконавці роботи

Список посадових осіб за штатним розкладом:

1- посада 1;

2 - посада 2;

3 - посада 3.

Матрицю відповідальностей за конкретний бізнес-процес можна скласти за результатами заповнення форми БП-Ф01.

 

4.5. 4. Графічні моделі бізнес-процесу (графічні схеми)

 

Правила формування графічних схем бізнес-процесів за методологією IDEF докладно описані в [14, 15, 16].

 

А) Обов'язкові й рекомендовані формати графічних схем бізнес-процесів.

Вибір формату для опису бізнес-процесу визначається масштабом і ступенем деталізації розглянутого бізнес-процесу.

Виділяється кілька рівнів деталізації бізнес-процесу:

1) 1-й умовний рівень - бізнес-процес організації в цілому. Рекомендована глибина деталізації - 2-3 рівня;

2) 2-й умовний рівень - бізнес-процес підрозділу організації Можлива глибина деталізації операцій бізнес-процесу 2 – 3 рівня;

3) 3-й умовний рівень - бізнес-процес робочого місця підрозділу. Можлива глибина опису - 1-2 рівня.

 

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

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

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

 

Завдання опису бізнес-процесу Тип моделі Формат для використання
  Опис бізнес-процесу рівня організації 1. Функціональна модель бізнес-процесу (рекомендована)   IDEF0
  Регламентація бізнес-процесу рівня організації 1. Функціональна модель бізнес-процесу {рекомендована). 2. Модель потоку робіт {обов'язкова)   IDEF0 IDEF3
  Опис бізнес-процесу рівня структурного підрозділу 1. Функціональна модель бізнес-процесу {рекомендована) 2. Модель потоку робіт {обов'язкова) IDEF0 IDEF3
  Розробка регламенту виконання бізнес-процесу структурного підрозділу 1. Модель потоку робіт (обов'язкова) IDEF3
  Опис бізнес-процесу для робочого місця виконавця 1 Модель потоку робіт (обов'язкова) IDEF3
  Розробка регламенту виконання бізнес-процесу для робочого місця виконавця 1 Модель потоку робіт (обов'язкова) IDEF3

 

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

Б) Правила формування моделей бізнес-процесів в IDEFO.

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

Модель IDEFO рекомендована до застосування в організації при описі бізнес-процесів на верхньому рівні.

При складанні функціональної моделі бізнес-процесу (IDEFO) описуються функції, що виконуються, вхідні, вихідні потоки матеріальних, фінансових ресурсів й інформації (документів, файлів).

При описі бізнес-процесу одночасно можуть застосовуватися комбінації різних моделей - IDEFO, IDEF3 й інших. Модель в IDEFO можна декомпозувати на моделі IDEF3.

Умовні позначки формату IDEFO представлені в таблиці.

 

Найменування Опис Графічне подання
  Модуль поведінки (функція або операція) Об'єкт служить для опису функцій (операцій, робіт), що виконуються підрозділами/ співробітниками підприємства  
  Стрілка зліва Стрілка описує входи функції (операції)  
  Стрілка праворуч Стрілка описує виходи функції (операції)  
  Стрілка зверху Стрілка описує управляючу дію, наприклад розпорядження, нормативний документ і т.д.  
  Стрілка знизу Стрілка знизу описує механізми або ресурси, що не витрачаються, наприклад, персонал, які використовуються для виконання процесу

 

На діаграмі IDEFO стрілки зв'язують функції які виконуються.

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

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

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

Правила складання моделей IDEF0 наступні.

У складі комплекту діаграм повинна бути присутня контекстна діаграма.

Блоки на діаграмі повинні розташовуватися діагонально - від лівого верхнього кута діаграми до правого нижнього в порядку наданих номерів.

Діаграми (крім контекстної) повинні містити не менш трьох і не більше восьми блоків.

Кожен блок діаграми одержує номер, що розміщується в правому нижньому куті. Порядок нумерації - від верхнього лівого до нижнього правого блоку (наприклад, номера від 1 до 8).

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

Імена блоків (функцій, що виконуються) повинні бути унікальними.

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

Блоки завжди повинні мати хоча б одну управляючу й одну вихідну стрілку, але можуть не мати вхідних стрілок.

Якщо ті самі дані служать і для управління, і для входу, показується тільки стрілка управління.

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

Зворотні зв'язки щодо управлінню показують «петлею зверху» (нагору й над). Зворотні зв'язки щодо входу зображуються «нижньою петлею» (униз і під).

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

При з'єднанні великої кількості блоків необхідно уникати необов'язкових перетинань стрілок. Варто мінімізувати число петель і поворотів кожної стрілки.

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

Побудова стрілок-виходів підпорядковується тим же правилам, що й стрілок-входів.

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

Стрілки управління на діаграмах нижнього рівня повинні бути деталізовані до назви документа, що регламентує дану дію.

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

В) Правила формування моделей бізнес-процесів в IDEF3.

Формат IDEF3 застосовується для опису бізнес-процесів у вигляді потоків операцій (робіт).

Умовні позначки формату IDEF3 представлені в наступних таблицях.

 

Найменування Опис Графічне представлення
  Модель операції (роботи) Об'єкт служить для опису операцій (робіт), що виконуються підрозділами/співробітниками підприємства.
  Об'єкт посилання Об'єкт, використовуваний для опису посилань на інші діаграми моделі, циклічні переходи в рамках однієї моделі, різні коментарі до операцій  
  Логічне «І» Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу   &  
  Логічне «АБО» Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу   O  
  Логічне «АБО» що виключає Логічний оператор, що визначає зв'язки між операціями в рамках процесу. Дозволяє описати розгалуження процесу   X  

 

Тип стрілки Графічне подання
  Стрілка передування. З'єднує операції що виконуються послідовно.  
  Стрілка відносини. Використовується для прив'язки об'єктів-коментарів д





Дата добавления: 2015-09-19; просмотров: 3670. Нарушение авторских прав; Мы поможем в написании вашей работы!



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

ТЕОРЕТИЧЕСКАЯ МЕХАНИКА Статика является частью теоретической механики, изучающей условия, при ко­торых тело находится под действием заданной системы сил...

Теория усилителей. Схема Основная масса современных аналоговых и аналого-цифровых электронных устройств выполняется на специализированных микросхемах...

Логические цифровые микросхемы Более сложные элементы цифровой схемотехники (триггеры, мультиплексоры, декодеры и т.д.) не имеют...

Классификация ИС по признаку структурированности задач Так как основное назначение ИС – автоматизировать информационные процессы для решения определенных задач, то одна из основных классификаций – это классификация ИС по степени структурированности задач...

Внешняя политика России 1894- 1917 гг. Внешнюю политику Николая II и первый период его царствования определяли, по меньшей мере три важных фактора...

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

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

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

Образование соседних чисел Фрагмент: Программная задача: показать образование числа 4 и числа 3 друг из друга...

Studopedia.info - Студопедия - 2014-2024 год . (0.012 сек.) русская версия | украинская версия