ARIS Toolset / BPwin: вибір за аналітиком, Oracle, Бази даних, статті

Зміст


Введення. Типові завдання опису бізнес-процесівОпис нотацій AR   Нотація ARIS eEPC   Нотація ARIS Organizational Chart   Нотація ARIS Information FlowНотації, що підтримуються BPwin 4.0   Опис нотацій IDEF0 і IDEF3   Опис нотації DFD   Організаційні діаграми (Organizational Chart) в BPwin 4.0Порівняльний аналіз нотацій ARIS і IDEFФункціональні можливості продуктів ARIS і BPwinВисновки. Рекомендації щодо застосування систем в залежності від типових завданьЛітература


Аналіз діяльності підприємств та реорганізація бізнес-процесів – надзвичайно складне завдання, що вимагає методичної та інструментальної підтримки. Останнім часом серед бізнес-аналітиків все більшу популярності набувають CASE-засоби BPwin (Computer Associates) і ARIS Toolset (ARIS). У цій статті дається короткий порівняльний аналіз цих коштів і рекомендації щодо їх використання.


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


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



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

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



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

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


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



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

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


Опис нотацій ARIS


Нотація ARIS eEPC


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


Таблиця 1. Об’єкти нотації eEPC





























































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


Опис


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

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


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

Рис. 1. Приклад моделі в нотації eEPC


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



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

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


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

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


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


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


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

Рис. 3. Опис процесу обслуговування клієнта процесу

Рис. 4. Опис процесу аналізу та узгодження заявки клієнта


Нотація ARIS Organizational Chart


Нотація Organizational Chart є однією з основних нотацій ARIS і призначена для побудови схем організаційної структури підприємства. Як правило, ця модель будується на початку проекту з моделювання бізнес-процесів. У моделі відображаються існуючі підрозділи підприємства у вигляді ієрархічної структури, як показано на рис. 5.

Рис. 5. Модель організаційної структури підприємства


Модель будується з об’єктів «Organizational unit», «Position», «Internal person» та ін Закладені в нотацію види зв’язків дозволяють відобразити різні види відносин між об’єктами організаційної структури. У представленому на рис. 5 прикладі «Підприємство» управляється «Директором», при цьому використовується тип зв’язку «is Organization Manager for». Ієрархія підрозділів будується за допомогою зв’язків типу «is composed of ». Крім того, можуть бути зазначені посади – «Position» і прізвища реальних співробітників, їх займають: «Internal person», а також тип зв’язку «occupies».


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


Нотація ARIS Information Flow


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

Рис. 6. Фрагмент діаграми ARIS Information Flow


Простота нотації обмежує області її корисного застосування. Основними об’єктами нотації є «Function» (використовується також при побудові моделей бізнес-процесів) і «Information Flow» – інформаційний потік (рис. 7).

Рис. 7. Нотація ARIS Information Flow


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


Нотації, що підтримуються BPwin 4.0


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


Нотація IDEF0 була розроблена на основі методології структурного аналізу і проектування SADT, затверджено в якості стандарту США і успішно експлуатується в багатьох проектах, пов’язаних з описом діяльності підприємств. IDEF0 отримала надзвичайно широке поширення і є, зокрема, стандартом в таких міжнародних організаціях, як НАТО і МВФ. Нотація IDEF3 була розроблена з метою більш зручного описи робочих процесів (Workflow), для яких важливо відобразити логічну послідовність виконання процедур. Об’єкти нотацій IDEF0 і IDEF3 показані в табл. 2 і 3.


Таблиця 2. Об’єкти нотації eEPC











































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


Опис


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

Нотація IDEF0
1 Робота (Activity) Об’єкт служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства. Зображується прямокутником. Ім’я роботи має відображати процес, дія. Для того щоб робота могла бути змодельована, повинно пройти якийсь час від початку до закінчення роботи і повинні бути витрачені якісь ресурси
2 Стрілка входу Стрілка малюється входить в роботу зліва і описує вхідні документи, інформацію, матеріальні ресурси, необхідні для виконання функції і змінювані роботою
3 Стрілка виходу Стрілка малюється яка з роботи праворуч і описує результати виконання роботи – вихідні документи, інформацію, матеріальні ресурси. В нотації IDEF0 кожна процедура повинна обов’язково мати не менше однієї стрілки виходу
4 Стрілка управління Стрілка малюється входить в роботу зверху і описує керуючий вплив, наприклад розпорядження, нормативний документ і т.д. В нотації IDEF0 кожна процедура повинна обов’язково мати не менше однієї стрілки управління
5 Стрілка механізму Стрілка малюється входить в роботу знизу і описує так звані механізми, тобто ресурси, необхідні для виконання процедури, але не змінюють в процесі її виконання свій стан. Приклади: співробітник, верстат і т.д.
6 Стрілка виклику Стрілка малюється яка з роботи вниз і є посиланням на іншу модель роботи. У BPwin така стрілка використовується для злиття і розщеплення моделей


Таблиця 3. Об’єкти нотації IDEF3

































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


Опис


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

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


Семантика побудови моделей IDEF0 і IDEF3 передбачає дотримання чітких правил. Повний опис стандартів IDEF можна знайти на сайті www.idef.com/.


Приклад опису бізнес-процесу в нотації IDEF0 зображений на рис. 8 (відповідає процесу, показаному на рис. 3).

Рис. 8. Приклад опису бізнес-процесу в нотації IDEF0


Однією з особливостей опису процесів в нотації IDEF0 є чітке виявлення переваг та недоліків бізнес-процесів. Роботи на діаграмі IDEF0 розташовуються в порядку домінування – з лівого верхнього кута діаграми в правий нижній. У лівому верхньому кутку розміщується або найважливіша робота, або робота, виконувана першої. Стрілки пов’язують роботи, при цьому розрізняється п’ять типів зв’язків. Стрілка, спрямована з виходу вищестоящої роботи на вхід або управління нижчестоящої, є прямим зв’язком; стрілка, направлена ​​з виходу нижчестоящої роботи на вхід або управління вищестоящої, є зворотним зв’язком. Відсутність зворотних зв’язків, роботи без виходу або управління, дублюються роботи вказують на недосконалість бізнес-процесів.


На рис. 9 показаний приклад опису бізнес-процесу в нотації IDEF3 (відповідає процесу, показаному на рис. 4).

Рис. 9. Приклад опису бізнес-процесу в нотації IDEF3


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


Опис нотації DFD


Нотація DFD призначена для опису інформаційних потоків в обстежуваної організації. Об’єкти нотації DFD показані в табл. 4. Наявність об’єктів «сховище даних» та двонаправлених стрілок дозволяє найбільш ефективно описати документообіг та вимоги до інформаційної системи.


Таблиця 4. Об’єкти нотації DFD

































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


Опис


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

Нотація DFD
1 Робота (Activity) Об’єкт служить для опису функцій по обробці інформації, що виконуються підрозділами / співробітниками підприємства
2 Об’єкт посилання Об’єкт посилання моделює об’єкт, що впливає на систему ззовні
3 Сховище даних Сховище даних моделює місце зберігання інформації – архів, база даних, репозитарій і т.д.
4 Стрілка Стрілка показує потоки інформації, рух документів, що переміщаються разом як один пакет. Стрілка може бути двобічної, тобто показує потік інформації з даного маршруту в обидві сторони


На рис. 10 показаний приклад діаграми DFD.

Рис. 10. Приклад опису документообігу в нотації DFD


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


Організаційні діаграми (Organizational Chart) в BPwin 4.0


Організаційні діаграми BPwin (рис. 11) є аналогом організаційних діаграм ARIs і так само, як і в ARIS, призначені для опису ієрархії підпорядкування в організаціях.

Рис. 11. Приклад організаційної діаграми в BPwin



  1. Для створення організаційної діаграми в BPwin необхідно попередньо в словниках внести наступну інформацію.
  2. Зображення (bitmaps), якщо на організаційній діаграмі передбачається використовувати іконки.
    Групи ролей – можуть відповідати структурним підрозділом. У прикладі на рис. 10 показані групи ролей «Дирекція», «Бухгалтерія» та «Цех № 1».
  3. Ролі – можуть відповідати посаді. У прикладі на рис. 10 показані ролі «Ген. директор »,« Бухгалтер »,« Технолог »та ін
  4. Ресурси – можуть відповідати прізвищу конкретної персони.

Після створення словника BPwin дозволяє за допомогою діалогів-гідів створити ієрархію підпорядкування, що включає групи ролей, ролі та ресурси. У діаграмах IDEF0, IDEF3 і DFD кожній роботі може бути призначений виконавець-ресурс зі словника ресурсів. Ролі та ресурси можуть бути також використані при створенні діаграми Swim Lane – різновиду діаграми IDEF3, на якій у вигляді окремих смуг показуються зони відповідальності службовців підприємства при виконанні технологічних операцій.


Порівняльний аналіз нотацій ARIS і IDEF


Порівняльний аналіз нотацій ARIS і IDEF наводиться в табл. 5.


Таблиця 5. Об’єкти нотацій ARIS, IDEF0 і IDEF3




















































































Критерії порівняння


ARIS


IDEF0


IDEF3

1 Принцип побудови діаграми / логіка процесу Тимчасова послідовність виконання процедур Принцип домінування (див. стандарт IDEF0) Тимчасова послідовність виконання процедур
2 Опис процедури процесу Об’єкт на діаграмі Об’єкт на діаграмі Об’єкт на діаграмі
3 Вхідний документ Використовується окремий об’єкт для опису («документ») Стрілка входу, стрілка управління Використовується окремий об’єкт для опису (Об’єкт посилання типу Object або стрілка Object flow)
4 Вхідна інформація Використовується окремий об’єкт для опису («кластер», «технічний термін») Стрілка входу, стрілка управління Використовується окремий об’єкт для опису (Об’єкт посилання типу Object або стрілка Object flow)
5 Вихідний документ Використовується окремий об’єкт для опису («документ») Стрілка виходу Використовується окремий об’єкт для опису (Об’єкт посилання типу Object або стрілка Object flow)
6 Вихідна інформація Використовується окремий об’єкт для опису («кластер», «технічний термін») Стрілка виходу Використовується окремий об’єкт для опису (Об’єкт посилання типу Object або стрілка Object flow)
7 Виконавець процедури Використовується окремий об’єкт для опису («позиція», «організаційна одиниця») Стрілка механізму Ні (може бути відображений в моделі тільки прив’язкою об’єкта посилання)
8 Використовуване обладнання Використовується окремий об’єкт для опису Стрілка механізму Ні (може бути відображений в моделі тільки прив’язкою об’єкта посилання)
9 Управління процедурою Ні. Може бути відображено тільки символами логіки і подій (послідовність виконання процедур) та / або вказівкою вхідних документів Стрілка управління Тільки тимчасова послідовність виконання процедур і логіка процесу
10 Контроль виконання процедури Ні. Може бути відображений зазначенням вхідних документів Стрілка управління Ні (може бути відображений в моделі тільки прив’язкою об’єкта посилання).
11 Зворотній зв’язок з управління / контролю Ні. Може бути відображена тільки символами логіки (послідовність виконання процедур) Стрілка управління Немає
12 Зворотній зв’язок по входу Ні. Може бути відображена тільки символами логіки (послідовність виконання процедур) Стрілка входу Немає


Одним з найважливіших аспектів опису моделей бізнес-процесів є відображення на моделі управляючих впливів, зворотних зв’язків з контролю і керування процедурою. У нотації ARIS eEPC управління процедурою може бути відображено тільки за допомогою вказівки вхідних документів, які регламентують виконання процедури, і послідовності виконання процедур у часі (запускають події). На відміну від ARIS, в нотації IDEF0 кожна процедура повинна мати хоча б одне керуюче вплив (вхід управління – стрілка зверху). Якщо при створенні моделі в eEPC вказувати тільки послідовність виконання процедур, не піклуючись про відображення керуючих впливів (наприклад, документів та інформації), отримані моделі будуть мати низьку цінність з точки зору аналізу та подальшого використання. На жаль, саме ця помилка найбільш поширена на практиці. Створюється модель Workflow (потік роботи), що відображає просту послідовність виконання процедур і вхідних / вихідних документів, при цьому керуючі (Контрольні) впливу на функції в моделі не відображаються.


На рис. 12 функція 4 є контрольною і служить для перевірки результатів роботи, що виконується функціями 2 і 3. Але дана модель не відповідає на питання:



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

Рис. 12. Недоліки опису бізнес-процесу в ARIS eEPC


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


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


Функціональні можливості продуктів ARIS і BPwin


Функціональні можливості інструментальних засобів моделювання ARIS Toolset і BPwin можна коректно порівнювати тільки по відношенню до певного кола завдань. У даному дослідженні розглядається задача формування моделей (опису) бізнес-процесів підприємства. Кожна з розглянутих систем має свої переваги і недоліки. Залежно від розв’язуваних завдань ці переваги можуть як посилюватися, так і навпаки, слабшати. Те ж саме можна сказати і про недоліки: недолік системи в рамках одного проекту може не бути таким у рамках другого. Наприклад, відсутність чітких угод по моделюванню керуючих впливів у рамках eEPC ARIS може привести до створення моделей, що не відповідають на поставлені питання, у той час як нотація IDEF0 системи BPwin дозволяє вирішити це завдання. З іншого боку, процедура, яка виконується одним співробітником, може бути більш адекватно описана за допомогою eEPC ARIS, ніж за допомогою IDEF0 або IDEF3 BPwin. Порівняння функціональних можливостей систем наводиться в табл. 6.


Таблиця 6. Порівняння функціональних можливостей ARIS Toolset 5.0 і BPwin 4.0



























































































Можливості / Інструментальна середу


ARIS Toolset 5.0


BPwin 4.0

1 Підтримуваний стандарт (Частково – DFD, ERM, UML) IDEF0, IDEF3, DFD
2 Система зберігання даних моделі Об’єктна база даних Моделі зберігаються в файлах. Можливе створення репозитарія на основі реляційної СУБД з допомогою ModelMart
3 Обмеження на розмір бази даних Ні. Розмір бази даних обмежується обчислювальними ресурсами Ні. Розмір бази даних обмежується обчислювальними ресурсами
4 Можливість групової роботи Є. Використовується ARIS Server Є. Використовується ModelMart
5 Обмеження на кількість об’єктів на діаграмі Немає Для DFD і IDEF3 – ні. Для IDEF0 обмежено рекомендаціями нотації
6 Можливість декомпозиції Необмежена декомпозиція. Можлива декомпозиція на різні типи моделей Необмежена декомпозиція. Можливий перехід на іншу нотацію в процесі декомпозиції
7 Формат представлення моделей Не регламентується Стандартний бланк (каркас) IDEF з можливістю його відключення
8 Зручність роботи зі створення моделей Складна панель управління, є вирівнювання об’єктів, є undo Проста панель управління, немає вирівнювання об’єктів, немає undo
9 UDP – властивості об’єктів, що визначаються користувачем Велике, але обмежена кількість властивостей; кількість типів обмежено Кількість UDP не обмежена. Кількість типів обмежена (18)
10 Можливість аналізу вартості процесів Є. Можливість використовувати ARIS ABC Спрощений ABC – аналіз вартості за частотою використання в процесі. Можливість експорту в Easy ABC
11 Генерація звітів Створення звітів на основі стандартних і настроюваних користувачем макросів Visual Basic RPTwin, можливість візуального налаштування звітів, включаючи розрахунок за формулами з використанням UDP
12 Складність розробки нестандартних звітів Складно Просто
13 Експорт звітів Реалізовано експорт звітів в MS Office, текстовий файл, RTF, HTML Реалізовано експорт звітів в MS Office, текстовий файл, RTF, HTML
14 Зв’язок з моделлю даних Можливість побудови ERD-діаграм, для експорту необхідне додаткове програмне забезпечення Реалізована зв’язок з моделлю даних ERwin. Кожній стрілкою може бути поставлений у відповідність набір сутностей і атрибутів
15 Опис доступу до даних Немає Для кожної роботи можуть бути описані права на використання даних. Об’єкт моделі даних може бути створений безпосередньо в середовищі BPwin
16 Опис супутньої документації Є, підтримка OLE За допомогою UDP типу command з кожною стрілкою зв’язується будь-який документ, який може бути завантажений за допомогою Windows – додатки. Запуск програми проводиться безпосередньо з середовища BPwin


Порівнюючи дві системи, варто відразу зазначити, що для зберігання моделей в ARIS використовується об’єктна СУБД і під кожен проект створюється нова база даних. Для зручності користувача моделі (об’єкти моделей) можуть зберігатися в різних групах, організованих в залежності від специфіки проекту. Цілком природно, що в ARIS передбачені різні функції з адміністрування бази даних: управління доступом, консолідація і т.п. У BPwin дані моделі зберігаються у файлі, що істотно спрощує роботу по створенню моделі. Для групової роботи над великими проектами передбачено збереження моделей BPwin в репозитарії Model Mart (поставляється окремо). Model Mart є сховищем моделей для BPwin і ERwin і використовує реляційні СУБД Oracle, Informix, MS SQLServer, Sybase). В ньому передбачено адміністрування, у тому числі розмежування прав доступу до рівня об’єкта моделі, порівняння версій, злиття моделей і т.д.


Часто одним з недоліків BPwin прихильники ARIS називають обмеження за кількістю об’єктів на діаграмі. Проте досвід реальних проектів показує, що для проекту, результати якого можна реально використовувати (Критерій – видимість), кількість об’єктів у базі даних ARIS або моделі BPwin складає 150-300. Це означає, що при 8 об’єктах на одній діаграмі загальна кількість діаграм (листів) в моделі складе 20-40. Бази даних ARIS Toolset (як і BPwin), що містять більше 500 об’єктів, фактично неможливо використовувати. Слід підкреслити, що модель створюється для виділення і аналізу проблем, тобто потрібно детальний опис найбільш складних, проблемних областей діяльності, а не тотальне опис усіх процесів. Як не дивно, в середовищі директорів компаній поширене переконання в тому, що детальне опис процесів само по собі представляє цінність і може вирішити багато проблем. Але це далеко від істини. Саме розуміння того, що потрібно описувати і які аспекти функціонування реальної системи при цьому відбивати, визначає успіх проекту з моделювання бізнес-процесів.


ARIS надає значно більше можливостей по роботі з окремими об’єктами моделі, але саме внаслідок надмірної кількості налаштувань робота по створенню моделі повинна регламентуватися складною, багатоаспектною документацією – так званими угодами з моделювання. Розробка цих угод сама по собі є складною, дорогою і вимагає значного часу (1-3 місяці) і кваліфікованих фахівців завданням. Якщо проект з використанням ARIS починається без детального опрацювання таких угод, то вірогідність створення моделей бізнес-процесів, не відповідають на поставлені запитання, становить 80-90%. У свою чергу, BPwin відрізняється простотою у використанні і досить суворої регламентацією при створенні діаграм (стандарт IDEF і рекомендації щодо його застосування, бланк IDEF для створення діаграми, обмежена кількість обов’язково заповнюваних полів, обмеження кількості об’єктів на одній діаграмі і т.д.). ARIS, безумовно, є більш «важким» інструментом, в порівнянні з BPwin, але в підсумку це обертається значними труднощами і високими витратами на його експлуатацію.


Висновки. Рекомендації щодо застосування систем в залежності від типових завдань


Різні ситуації застосування інструментальних засобів моделювання бізнес-процесів та їх експертна оцінка за 5-бальною шкалою показані в табл. 7.


Таблиця 7. Оцінка застосовності ARIS Toolset 5.0 і BPwin 4.0 для задач моделювання бізнес-процесів





















Завдання / Інструментальна середу


ARIS Toolset 5.0


BPWin 4.0

Разовий проект з опису бізнес-процесів, наприклад:

  1. опис одного бізнес-процесу з точки зору контролю і управління;
  2. опис функціональних можливостей нової системи управління на верхньому рівні
3 5
Тривалий (безперервний) проект по опису діяльності компанії з різних точок зору (організаційна структура, структура документів, великий обсяг бази даних процесів і т.д.) 5 4
Розробка системи автоматизації:

  1. опис функціональних можливостей системи;
  2. створення логічної моделі даних;
  3. зв’язок моделі процесів і моделі даних;
  4. створення фізичної моделі даних;
  5. генерація коду програми.
3
3

5 BPwin + ERwin + Paradigm Plus


Позиціонування систем можна провести по відношенню до вирішення задачі моделювання бізнес-процесів (рис. 13).

Рис. 13. Оцінка ефективності ARIS Toolset і BPwin


Таким чином, для ведення невеликих за масштабами (малі та середні підприємства, 2-5 осіб у групі консультантів) і тривалості (2-3 місяці) проектів раціонально використовувати BPwin. Для великих і / або тривалих проектів (наприклад, таких як впровадження системи безперервного поліпшення бізнес-процесів, ISO, TQM) більше підходить ARIS. Слід зазначити, в що системі ARIS Toolset незручно створювати інформаційні моделі, а проектування та налаштування баз даних не передбачена. В цьому випадку підготовчі роботи зі створення регламентуючої документації можуть зайняти 1-3 місяці, але це є необхідним елементом подальшої успішної роботи.


Література



  1. Інтернет-сайт www.finexpert.ru
  2. Інтернет-сайт www.interface.ru
  3. Інтернет-сайт www.idef.com
  4. С.В.Маклаков. BPwin і ERwin. CASE-засоби розробки інформаційних систем. Москва: Діалог-МИФИ, 2000, 256с.
  5. Д.А. Марка, К. МакГоуен Методологія структурного аналізу і проектування. Москва, 1993.
  6. «Методи ARIS». Файл pdf, більше 1000 стор Поставляється разом з демо-версією системи ARIS Toolset.
  7. Август-Вільгельм Шеер. Бізнес-процеси: основні поняття, теорії, методи. Москва: Просвітитель, 1999.

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


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

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

Ваш отзыв

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

*

*