Порівняльний аналіз нотацій, Комерція, Різне, статті

Зміст



  1. Введення. Типові завдання опису бізнес-процесів. Вимоги до опису бізнес-процесів підприємств.
  2. Опис нотації ARIS eEPC.
  3. Опис нотації IDEF0, IDEF3.
  4. Порівняльний аналіз нотацій ARIS і IDEF.
  5. Функціональні можливості продуктів ARIS і BPwin.
  6. Висновки. Рекомендації щодо застосування систем в залежності від типових завдань.

Введення. Типові завдання опису бізнес-процесів


Вимоги до опису бізнес-процесів підприємств


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



  1. яке програмне забезпечення використовувати в проекті («ARIS краще BPwin?», «ERwin краще ARIS?» і т.п.);
  2. як моделювати процеси з використанням продукту «Х»?;
  3. як проводити аналіз і виявляти проблеми за допомогою продукту «Х»?;
  4. яку методологію використовувати для опису процесів?

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



  1. цілей проекту;
  2. вимог до інформації, що характеризує бізнес-процеси і необхідної для аналізу і прийняття рішень в рамках конкретного проекту;
  3. можливостей CASE-систем по опису процесів з урахуванням вимог п.2.

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

Опис бізнес-процесів проводиться з метою їх подальшого аналізу і реорганізації. Метою реорганізації може бути впровадження інформаційної системи, скорочення витрат на випуск продукції, підвищення якості обслуговування клієнтів, створення посадових і робочих інструкцій при впровадженні стандартів ISO-9000 і т.д. Для кожної такої задачі існують певні параметри, що визначають набір критичних знань по бізнес-процесу. Від задачі до задачі вимоги до опису бізнес-процесів можуть змінюватися. У загальному випадку, модель бізнес-процесу повинна давати відповіді на наступні питання:



  1. які процедури (функції, роботи) необхідно виконати для отримання заданого кінцевого результату;
  2. в якій послідовності виконуються ці процедури;
  3. які механізми контролю та управління існують в рамках розглянутого бізнес-процесу;
  4. хто виконує процедури процесу;
  5. які входять документи / інформацію використовує кожна процедура процесу;
  6. які вихідні документи / інформацію генерує процедура процесу;
  7. які ресурси необхідні для виконання кожної процедури процесу;
  8. яка документація / умови регламентує виконання процедури;
  9. які параметри характеризують виконання процедур і процесу в цілому.

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


Опис нотації ARIS eEPC


Нотація ARIS eEPC розшифровується таким чином – Extended Event Driven Process Chain – розширена нотація опису ланцюжка процесу, керованого подіями. Нотація розроблена фахівцями компанії IDS Scheer AG (Німеччина), зокрема професором Шеєр. У наступній таблиці наводяться основні використовувані в рамках нотації об’єкти.




























































Найменування


Опис


Графічне представлення

1 Функція Об’єкт «Функція» служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства.  
2 Подія Об’єкт «Подія» служить для опису реальних станів системи, що впливають і управляють виконанням функцій  
3 Організаційна одиниця Об’єкт, що відображає різні організаційні ланки підприємства (наприклад, управління або відділ)  
4 Документ Об’єкт, що відображає реальні носії інформації, наприклад паперовий документ  
5 Прикладна система Об’єкт відображає реальну прикладну систему, використовувану в рамках технології виконання функції  
6 Кластер інформації Об’єкт характеризує дані, як набір сутностей і зв’язків між ними. Використовується для створення моделей даних  
7 Стрілка зв’язку між об’єктами Об’єкт описує тип відносин між іншими об’єктами, наприклад – активацію виконання функції деяким подією  
8 Логічне «І» Логічний оператор, що визначає зв’язок між подіями і функціями в рамках процесу. Дозволяє описати розгалуження процесу  
9 Логічне «АБО» Логічний оператор, що визначає зв’язок між подіями і функціями в рамках процесу. Дозволяє описати розгалуження процесу  
10 Логічне виключає «АБО» Логічний оператор, що визначає зв’язок між подіями і функціями в рамках процесу. Дозволяє описати розгалуження процесу  

Таблиця 1

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

Рисунок 1.

На малюнку 1 видно, що зв’язки між об’єктами мають певний сенс і відображають послідовність виконання функцій в рамках процесу. Стрілка, що з’єднує Подія 1 і Функцію 1 «активує» або ініціює виконання Функції 1. Функція 1 «створює» Подія 2, за яким слід символ логічного «І», «запускає» виконання Функцій 2 і 3. Нотація eEPC побудована на певних семантичних правилах опису:



  1. кожна функція повинна бути ініційована подією і повинна завершуватися подією;
  2. в кожну функцію не може входити більше однієї стрілки, «запускає» виконання функції, і виходити не більше однієї стрілки, яка описує завершення виконання функції.

Крім цих правил, існують і інші важливі правила формування моделей в ARIS. Ці правила можна вивчити за допомогою методичного матеріалу «Методи ARIS», який встановлюється на комп’ютер одночасно з демо-версією продукту.

На малюнку 2 показано застосування різних об’єктів ARIS при створенні моделі бізнес-процесу.

Рисунок 2.

Кожен об’єкт в системі ARIS Toolset, яка підтримує метод опису бізнес-процесів ARIS, має певний набір атрибутів. Користувачеві пропонується скористатися стандартними атрибутами для опису об’єктів або обмеженим кількість т.зв. користувальницьких атрибутів.

З малюнка 1 видно, що бізнес-процес в нотації eEPC являє собою послідовність процедур, розташованих у порядку їх виконання. Слід зазначити, що реальна тривалість виконання процедур в eEPC візуально відображена бути не може. Це призводить до того, що при створенні моделей можливі ситуації, коли на одного виконавця буде покладено виконання двох завдань одночасно. Використовувані при побудові моделі символи логіки дозволяють відобразити розгалуження і злиття бізнес-процесу. Для отримання інформації про реальну тривалості процесів необхідно використовувати інші інструменти опису, наприклад графіки Ганта в системі MS Project.

Таким чином, за допомогою нотації eEPC ARIS можна описувати бізнес-процес у вигляді потоку послідовно виконуваних робіт (процедур, функцій). Приклад моделей, сформованих з використанням ARIS eEPC, показані на малюнках 3-4.

Рисунок 3.



Рисунок 4.

Опис нотації IDEF0, IDEF3


Нотація IDEF0 була розроблена на основі методології структурного аналізу і проектування SADT, затверджено в якості стандарту США і успішно експлуатується в багатьох проектах, пов’язаних з описом діяльності підприємств. Нотація IDEF3 була розроблена з метою більш зручного опису робочих процесів (Work Flow), для яких важливо відобразити логічну послідовність виконання процедур. Нотації IDEF0 і IDEF3 використовують такі об’єкти.
































































Найменування


Опис


Графічне представлення

Нотація IDEF0
1 Модуль поведінки (UOB) Об’єкт служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства.  
2 Стрілка ліворуч Стрілка описує вхідні документи, інформацію, матеріальні ресурси, необхідні для виконання функції.  
3 Стрілка праворуч Стрілка описує вихідні документи, інформацію, матеріальні ресурси, які є результатом виконання функції.  
4 Стрілка зверху Стрілка описує управляє впливу, наприклад розпорядження, нормативний документ і т.д. В нотації IDEF0 кожна процедура повинна обов’язково мати не менше однієї стрілки зверху, що відбиває управляє вплив.  
5 Стрілка знизу Стрілка знизу описує т.зв. механізми, тобто ресурси, необхідні для виконання процедури, але не змінюють в процесі її виконання свій стан. Приклади: співробітник, верстат і т.д.  
Нотація IDEF3
1 Модель роботи (UOW) Об’єкт служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства.  
2 Нормативний об’єкт Об’єкт, який використовується для опису посилань на інші діаграми моделі, циклічні переходи в рамках однієї моделі, різні коментарі до функцій.  
3 Логічне «І» Логічний оператор, що визначає зв’язок між функціями в рамках процесу. Дозволяє описати розгалуження процесу.  
4 Логічне «АБО» Логічний оператор, що визначає зв’язок між функціями в рамках процесу. Дозволяє описати розгалуження процесу.  
5 Логічне виключає «АБО» Логічний оператор, що визначає зв’язку функціями в рамках процесу. Дозволяє описати розгалуження процесу.  
Таблиця 2

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





















Тип стрілки


Графічне представлення

1 Стрілка передування. Поєднує послідовно виконувані функції.  
2 Стрілка відносини. Використовується для прив’язки об’єктів-коментарів до функцій.  
3 Стрілка потоку об’єктів. Показує потік об’єктів від однієї функції до іншої.  
Таблиця 3


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

Бізнес-процес, сформований за допомогою нотації IDEF0, показаний на малюнку 5. (Цей процес представлений в нотації ARIS eEPC на малюнку 3).



Рисунок 5.

На малюнку 6 показано бізнес-процес, описаний за допомогою нотації IDEF3. (Цей процес представлений в нотації ARIS eEPC на малюнку 4.)




Малюнок 6.

В нотації IDEF3, так само як і в нотації ARIS eEPC, використовуються символи логіки, що відображають розгалуження процесу.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*