Стандарти та методології моделювання бізнес-процесів. Управління основної діяльності ріелторської фірми.

Виконав: студент групи 03-431 Степанов М.Д.

Московський авіаційний інститут (Державний технічний університет)

Москва, 2009.

Вступ

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

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

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

Основу багатьох сучасних методологій моделювання бізнес-процеси склали методологія SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування), сімейство стандартів IDEF (Icam DEFinition, де Icam - Це Integrated Computer-Aided Manufacturing) і алгоритмічні мови. Основні типи методологій моделювання та аналізу бізнес-процесів:

Моделювання бізнес-процесів (Business Process Modeling). Найбільш широко використовувана методологія опису бізнес-процесів - стандарт IDEF0. Моделі у нотації IDEF0 призначені для високорівневого опису бізнесу компанії у функціональному аспекті.

Опис потоків робіт (Work Flow Modeling). Стандарт IDEF3 призначений для опису робочих процесів і близький до алгоритмічним методам побудови блок-схем.

Опис потоків даних (Data Flow Modeling). Нотація DFD (Data Flow Diagramming), дозволяє відобразити послідовність робіт, що виконуються по ходу процесу, і потоки інформації, що циркулюють між цими роботами.

Інші методології.

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

Сутність і значення моделювання бізнес-процесів

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

Існує кілька підходів до визначення поняття «моделювання бізнес-процесів»:

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

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

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

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

моделювання бізнес-процесів - це метод, що дозволяє дати вартісну оцінку кожному процесу, взятому окремо, і усіх бізнес-процесів на підприємстві, взятим в сукупності;

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

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

Бізнес-процес - Це логічний, послідовний, взаємопов'язаний набір заходів, який споживає ресурси, створює цінність і видає результат. У міжнародному стандарті ISO 9000:2000 прийнятий термін "процес", однак на сьогодні час ці терміни можна вважати синонімами. Серед основних причин, що спонукають організацію оптимізувати бізнес-процеси, можна виділити необхідність зниження витрат або тривалості виробничого циклу, вимоги, пропоновані споживачами і державою, впровадження програм управління якістю, злиття компаній, внутрішньоорганізаційні протиріччя та ін.

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

Рішення з моделювання бізнес-процесів звичайно приймається з причин, представленим на малюнку 1.

Малюнок 1 - Причини, з яких приймається рішення з моделювання бізнес-процесів

Моделювання бізнес-процесів зачіпає багато аспектів діяльності компанії:

зміна організаційної структури;

оптимізацію функцій підрозділів і співробітників;

перерозподіл прав і обов'язків керівників;

зміна внутрішніх нормативних документів та технології проведення операцій;

нові вимоги до автоматизації виконуваних процесів і т. д.

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

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

Структурний моделювання бізнес-процесів організації може виконуватися в нотації IDEF0 з використанням інструментарію BPwin або мовою UML з використанням інструментарію Rational Rose. Детальне моделювання виконується на мовою UML.

На етапі структурного моделювання в моделі мають бути відображені:

існуюча організаційна структура;

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

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

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

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

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

Детальна модель бізнес-процесу має включати:

набір прецедентів відображають можливі варіанти виконання бізнес-процесів «як є »;

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

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

Моделі повинні бути узгоджені з провідними фахівцями організації, що володіють необхідними знаннями.

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

1.2 Історія розвитку методологій моделювання бізнес-процесів

Основу багатьох сучасних методологій моделювання бізнес-процеси склали методологія SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування) і алгоритмічні мови, які застосовуються для розробки програмного забезпечення.

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

Малюнок 2 - Історія розвитку методологій моделювання бізнес-процесів

1.3 Сучасні методології опису бізнес-процесів

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

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

На Насправді, не дивлячись на свою протилежність, в основному пов'язане з назвою діаграм і видів використовуваних об'єктів сучасні методології опису бізнес-процесів практично ідентичні і являють собою незначні видозміни двох класичних схем - DFD і WFD - Work Flow Diagram, які були розглянуті.

Давайте розглянемо інші сучасні мови опису бізнес-процесів:

IDEF0;

DFD у нотації Гейне-Сарсона і Йордана-Де Марко;

IDEF3;

Oracle;

BAAN;

ARIS.

Swimmer lanes;

1.4 Методологія IDEF0

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

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

В стандарті IDEF0 c допомогою входу показують об'єкти - інформаційні та матеріальні потоки, які перетворюються в бізнес-процесі. За допомогою управління показують об'єкти - матеріальні та інформаційні потоки, які не перетворюються в процесі, але потрібні для його виконання. За допомогою механізмів стали показувати механізми, за допомогою яких бізнес-процес реалізується: технічні засоби, люди, інформаційні системи і т.д. Вихід бізнес-процесу, описаного в стандарті IDEF0 повністю відповідає за змістом виходу процесу, описаного за допомогою DFD-схеми.

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

Таблиця 1. Назва та розміщення входів і виходів у стандарті IDEF0 щодо функціонального блоку.

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

Рис.3. Стандарт опису бізнес-процесу IDEF0.

Стандарт IDEF0 отримав велике поширення в США і активно використовується в Росії. З огляду на те, що в стандарті IDEF0 з'явилася додаткова аналітика з порівняно з класичним стандартом DFD, схеми бізнес-процесів одержувані при описі в стандарті IDEF0 виглядають більш складними з точки зору менеджерів компанії, з причини обмеженого наявності у них вільного часу. Дана складність часто призводить до того, що менеджери, особливо вищого рівня, які повинні брати активну участь у проекті з опису та оптимізації діяльності компанії, "відмовляються" від роботи з IDEF0. У даному випадку IDEF0 - є занадто інформаційно насиченим і складним стандартом.

Другий недолік стандарту IDEF0 пов'язаний з тим, що він дає більше приводів і можливостей прихильникам опорів змін пригальмувати проект з опису та оптимізації бізнес-процесів і дискредитувати його ідею. Це також пов'язане з ускладненою аналітикою стандарту IDEF0, яка часто дає привід задуматися і задавати такі питання: "А чи правильно, що цей об'єкт віднесений до входу? Може його віднести до управління? "

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

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

Рис. 4. Діаграма IDEF0 верхнього рівня бізнес-процесу "Звільнення співробітника".

1.5 Методологія DFD у нотації Гейне-Сарсона і Йордана-Де Марко

Наступний стандарт опису бізнес-процесів, який набув поширення, був розроблений на основі розвитку класичної методології DFD. Даний стандарт представлений двома трохи розрізняються варіантами, які називають нотаціями. Перша з них називається нотацією Гейне Сарсона, другий нотацією Йордона-Де Марко.

Гейн Сарсон, запропонував класичну DFD-схему трохи ускладнити. Він запропонував ввести додатковий об'єкт, за допомогою якого показуються місця бізнес-процесу, в яких зберігається інформація, або матеріальні ресурси. Прикладами таких місць є архів, в якому зберігаються документи, база даних, у якій зберігається інформація, або склад, на якому зберігаються матеріальні ресурси. Даний об'єкт отримав назву - сховище даних. На DFD-схемах у нотації Гейне-Сарсона і Йордона-Де Марко також використовуються об'єкти, за допомогою яких показують зовнішніх суб'єктів, з якими бізнес-процес взаємодіє. Дані об'єкти називають зовнішніми сутностями. На рис. 5 наведено приклад DFD-схеми бізнес-процесу "Оформлення та видача трудової книжки працівникові при звільненні", розробленої в нотації Гейне-Сарсона.

Рис. 5. DFD-схема бізнес-процесу "Оформлення та видача трудової книжки працівникові при звільненні "у нотації Гейне-Сарсона.

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

Друга нотація Йордона-Де Марко методології DFD була названа на честь розробив її фахівця Йордона-Де Марко. У першому наближенні ця нотація аналогічна нотації Гейне Саросна, за виключення форм об'єктів: для описів операцій бізнес-процесу замість закруглених прямокутників стали використовуватися кола, трохи видозмінилися і інші об'єкти - сховище даних і зовнішні сутності (рис. 6).

Рис. 6. DFD-схема бізнес-процесу "Оформлення та видача трудової книжки працівникові при звільненні "у нотації Йордона-Де Марко.

В таблиці 2 наведено назви, позначення і змив елементів, які використовуються при побудові DFD-схеми бізнес-процесу у нотації Гейне-Сарсано і Йордона-Де Марко.

Таблиця 2. Елементи методології DFD в нотаціяхГейна-Сарсано і Йордона-Де Марко.

1.6 Методологія IDEF3

Стандарт IDEF0, яке було розглянуто раніше є розвитком класичного DFD -- підходу і призначений для опису бізнес-процесів верхнього рівня. Для опису тимчасової послідовності і алгоритмів виконання робіт стандарт IDEF0 не підходить. Для вирішення цього завдання стандарт IDEF0 отримала подальший розвиток в результаті чого був розроблений стандарт IDEF3, який входить до сімейство стандартів IDEF.

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

Рис. 7. Схема бізнес-процесу в стандарті IDEF3.

В відміну від класичної методології WFD в стандарті IDEF3 зв'язку між роботами діляться на три типи, позначення, назви та змив яких, наведені в таблиці 3.

Таблиця 3. Типи зв'язків між роботами в стандарті IDEF3.

Крім наявності декількох типів зв'язків між роботами в стандарті IDEF3 логічні оператори, які в даному випадку називаються перехрестями також діляться на кілька типів: "Що виключає АБО", "І" і "ИЛИ".

Перехрестя "Що виключає АБО" означає, що після завершення роботи "A" (рис. 8), починає виконуватися тільки один з трьох розташованих паралельно робіт B, С або D в залежності від умов 1, 2 і 3. Перехрестя "І" означає, що після завершення роботи "A", починають виконуватися одночасно три паралельно розташовані роботи B, С і D. Перехрестя "АБО" означає, що після завершення роботи "A", може запуститися будь-яка комбінація трьох паралельно розташованих робіт B, С і D. Наприклад може запуститися тільки один з них, можуть запуститися три роботи, а також можуть запуститися подвійні комбінації В і З, або C і D, або B і D. Перехрестя "Що виключає АБО" є невизначеним, тому що передбачає кілька можливих сценаріїв реалізації бізнес-процесу і застосовується для опису слабко формалізованих ситуацій.

Рис. 8. Застосування перехресть "Що виключає АБО", "І" і "ЧИ" - схеми розбіжності.

Перехрестя "І" і "АБО" підрозділяються ще на два підтипи - синхронні і асинхронні. Перехрестя синхронного типу позначають, що роботи В, С і D запускаються одночасно після завершення роботи A. Перехрестя асинхронного типу вимог до одночасності не пред'являють.

Наведені на рис. 5 схеми взаємозв'язку робіт і перехресть називаються схемами розбіжності, тому що від перехресть розходяться кілька робіт. Існує і інші схеми взаємозв'язку перехресть і робіт - це так звані схеми сходження, коли до перехрестя підходить декілька робіт (рис. 9).

Рис. 9. Застосування перехресть "Що виключає АБО", "І" і "ЧИ" - схеми сходження.

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

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

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

1.7 Методологія ORACLE

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

Три найбільш великих розробника інформаційних систем: SAP/R3, BAAN і ORACLE для підвищення ефективності впровадження своїх інформаційних систем розробили свої стандарти і програмні продукти, за допомогою яких описується бізнес-діяльність компанії. Кожен з цих стандартів містить кілька бізнес-моделей, за допомогою яких описуються бізнес-процеси, організаційна структура, а також будуються інші бізнес-моделі.

Давайте розглянемо стандарт, який використовує компанія ORACLE. Методологія ORACLE містить 5 бізнес-моделей, назва, опис і призначення яких наведено в таблиці 5.

Таблиця 5. Моделі методології ORACLE.

При описі бізнес-процесів з використанням методології ORACLE найбільш часто застосовується другим згідно з переліком таблиці 5 модель бізнес-процесів. Побудова цієї моделі базується на підході "Swimmer lanes", який повинен містити суміш класичних DFD і WFD стандартів і має одну відмінну рису. Діаграма, на якому малюється схема бізнес-процесу розділена по горизонталі на доріжки. Кожна доріжка належить певному структурному підрозділу або посади, що бере участь у бізнес-процесі. Ті операції бізнес-процесу, які виконуються цим структурним підрозділом, розміщуються в зоні відповідної доріжки. Такий підхід дозволяє наочно показати розподіл відповідальності у бізнес-процесі і продемонструвати ступінь його організаційної фрагментарності (рис. 10).

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

Одним з недоліків формату "Swimmer lanes" є те, що в даному випадку більш важко відстежити тимчасову послідовність робіт, а так само критичний шлях бізнес-процесу, що актуально при проведенні тимчасової оптимізації.

1.8 IDEF1X

IDEF1X - Методологія опису даних. Застосовується для побудови баз даних.

IDEF1X є методом для розробки реляційних баз даних і використовує умовний синтаксис, спеціально розроблений для зручного побудови концептуальної схеми. Концептуальною схемою ми називаємо універсальне уявлення структури даних у рамках комерційного підприємства, незалежне від кінцевої реалізації бази даних та апаратної платформи. Будучи статичним методом розробки, IDEF1X спочатку не призначений для динамічного аналізу за принципом "AS IS", тим не менш, він іноді застосовується в цій якості, як альтернатива методу IDEF1. Використання методу IDEF1X найбільш доцільно для побудови логічної структури бази даних після того, як усі інформаційні ресурси досліджені (скажімо, з допомогою методу IDEF1) і рішення про впровадженні реляційної бази даних, як частини корпоративної інформаційної системи, було прийнято. Однак не варто забувати, що засоби моделювання IDEF1X спеціально розроблені для побудови реляційних інформаційних систем, і якщо існує необхідність проектування іншої системи, скажімо об'єктно-орієнтованої, то краще обрати інші методи моделювання.

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

1.7.1 Зв'язок між сутностями

Зв'язки в IDEF1X представляють собою посилання, з'єднання і асоціації між сутностями. Нижче, на малюнку, наведено ряд прикладів зв'язку між сутностями:

Сутність описується в діаграмі IDEF1X графічним об'єктом у вигляді прямокутника. На малюнку 2 наведений приклад IDEF1X діаграми.

1.7.2 Переваги IDEF1X

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

1.9 IDEF4

IDEF4 - Об'єктно-орієнтована методологія. Чи відбиває взаємодія об'єктів. Зручна для створення програмних продуктів на об'єктно-орієнтованих мовах (наприклад С + +). Поки що, на мій погляд, широкого поширення не знайшла. Більше широко зараз використовується UML.

1.10 SADT

SADT - Методологія структурного аналізу і проектування (Structured Analysis and Design Technique). Заснована на поняттях функціонального моделювання. Є методологією, що відображає такі системні характеристики, як управління, зворотній зв'язок і виконавці. Виникла наприкінці 60-х років.

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

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

1.11 ARIS

Методологія ARIS

Однією з сучасних методологій бізнес-моделювання, що отримала широке поширення в Росії є методологія ARIS, яка розшифровується як Architecture of Integrated Information Systems - проектування інтегрованих інформаційних систем. Її використовує програмний засіб ARIS Toolset

Методологія ARIS на даний момент часу є найбільш об'ємною і містить близько 100 різних бізнес-моделей, які використовуються для опису, аналізу та оптимізації різних аспектів діяльності організації. Частина моделей методології ARIS використовуються в настроювальної модулі інтегрованої інформаційної системи SAP/R3, який застосовується при впровадженні системи та її налаштуванні на діяльності компанії. З причини великої кількості бізнес-моделей методологія ARIS ділить їх на чотири групи (рис. 11):

Група "Оргструктура".

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

Група "Функції".

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

Група. "Інформація".

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

Група "Процеси".

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

Рис. 11. Групи моделей методології ARIS.

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

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

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

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

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

Таблиця 6. Найбільш часто використовуються на практиці моделі методології ARIS.

Модель "Діаграма цілей" - OD застосовується для опису стратегічних цілей компанії, їх ієрархічної впорядкованості, а також зв'язків цілей з продуктами і послугами, що виробляються компанією і бізнес-процесами, що підтримують їх виробництво (рис. 12)

Рис. 12. Модель "Діаграма цілей" - OD/ARIS.

Модель "Дерево продуктів і послуг" - PST застосовується для опису продуктів і послуг, вироблених в компанії, а також і зв'язку зі стратегічними цілями компанії, бізнес-процесами, що підтримують їх виробництво (рис. 13).

Рис. 13. Модель "Дерево продуктів і послуг - PST/ARIS".

Модель "Дерево функцій" - FT описує функції, які виконуються в компанії та їх ієрархію. Дана модель часто застосовується для для побудови дерева бізнес-процесів компанії (мал. 14).

Рис. 14. Модель "Дерево функцій" - PST/ARIS.

Модель "Діаграма оточення процесу" - FAT дозволяє описати оточення або кордону бізнес-процесу, показуючи його входи, виходи, постачальників і клієнтів (рис. 15).

Рис. 15. Модель "Діаграма оточення процесу" - PST/ARIS.

Модель "Діаграма ланцюжка доданої вартості" - VACD є прототипом класичного DFD-стандарту і використовується для опису бізнес-процесів верхнього рівня. Додатковим відмінністю даної та інших процесних моделей є те, що інформаційні та матеріальні потоки на схемі VACD змальовується не стрілками, а об'єктами. При цьому для кожного типу потоку використовується свій об'єкт. На моделі VACD методології ARIS на відміну від класичного підходу також використовується логічні зв'язки між роботами, які дозволяють відобразити логічну наст?? послідовно виконання робіт. У Як один з варіантів логічній послідовності може виступати тимчасова послідовність виконання робіт, що характерно для класичного підходу WFD. (рис. 16).

Рис. 16. Модель "Розширена ланцюжок процесів, керована подіями" -- eEPC/ARIS.

Модель "Матриця вибору процесу" - PSM є прототипом класичного DFD-стандарту і використовується як альтернатива для моделі VACD. Матриця вибору процесів по відношенню до діаграми ланцюжка доданої вартості є з одного боку більш спрощеним варіантом опису процесу, з іншого боку дана модель містить додаткові об'єкти, що дозволяють показати інші аспекти бізнес-процесу. Простота матриці вибору бізнес-процесів пов'язана з тим, що на даній моделі не показуються інформаційні та матеріальні потоки. Що стосується інших аспектів, то дана модель дозволяє на одній схемі компактно і наочно показати різні варіанти виконання бізнес-процесу, який описується. Відповідно матрицю вибору процесів доцільно застосовувати замість діаграми ланцюжка доданої вартості у випадках, коли описуваний бізнес-процес має декілька варіантів виконання, кожен з яких лягає базову схему. Приклад застосування матриці вибору процесів для опису діяльності компанії "Еврика", що має функціональну організаційну структуру показано на рис. 17.

Рис. 17. Модель "Матриця вибору процесів" - PSM/ARIS.

Модель "Extended event driven Process Chain" - eEPC є прототипом класичного WFD-стандарту і використовується для опису бізнес-процесів нижнього рівня. Додатковим відзнакою eEPC-моделі від класичної WFD-схеми є наявність на моделі об'єкта, який називається подією. За допомогою подій зображується факт, час або подія ініціюють початок виконання робіт процесу, а також факт або час їх завершення (рис. 18).

Рис. 18. Модель "Розширена ланцюжок процесів, керована подіями" -- VACD/ARIS.

Модель "Організаційна структура" - ORG використовується для опису організаційної структури компанії. На даній моделі зображуються структурні підрозділу, групи, посади, ролі та інші елементи організаційної структури і зв'язки між ними (рис. 19).

Рис. 19. Модель "Організаційна структура" - ORG/ARIS.

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

Рис. 20. Модель "Діаграма типів інформаційних систем" - VACD/ASTD.

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

Робота по створенню моделі повинна регламе