Повна версія

Головна arrow Техніка arrow МОДЕЛЮВАННЯ ПРОЦЕСІВ І СИСТЕМ

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

МЕТОДИ І ЗАСОБИ МОДЕЛЮВАННЯ БІЗНЕС-СИСТЕМ І ПРОЦЕСІВ

Методологія структурно-функціонального моделювання

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

IDEF0 реалізує методику функціонального моделювання складних систем. Вона заснована на відомій методології SADT (Structured Analysis and Design Technique), запропонованої в 1973 р Д. Россом і згодом стала основою стандарту IDEF0. Ця методика рекомендується для початкових стадій проектування складних систем управління, виробництва, бізнесу, що включають людей, обладнання, програмне забезпечення і т.д.

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

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

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

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

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

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

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

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

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

Найбільш популярний стандарт IDEF0 можна вважати наступним етапом розвитку добре відомого графічного мови структурного функціонального моделювання систем SADT. Історично IDEF0 як стандарт був розроблений в 1981 р в рамках великої програми автоматизації промислових підприємств США, яка носила позначення / САМ (Integrated Computer Aided Manufacturing). Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = ICAM • DEFinition). В процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому крім вдосконаленого набору функцій для опису бізнес-процесів одним з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках «аналітик - фахівець». Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.

В результаті пошуку відповідних рішень з'явився метод функціонального моделювання IDEF0. З 1981 р стандарт IDEF0 зазнав кілька незначних змін, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 р Національним інститутом по стандартам і технологіям США (NIST).

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

Першим з них є поняття функціонального блоку (.Activity Box), який являє собою конкретну функцію в рамках даної системи. Графічне зображення функціонального блоку має вигляд прямокутника (рис. 4.1) і має своїм унікальним ідентифікаційним номером. Відповідно до вимог стандарту назва кожного функціонального блоку має бути сформульовано, по можливості, в глагольном способі (наприклад, «виробляти продукцію», а не «виробництво продукції»).

функціональний блок

Мал. 4.1. функціональний блок

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

  • • верхня сторона має значення «Управління» ( Control ');
  • • ліва сторона - «Вхід» ( Input );
  • • права сторона - «Вихід» ( Output );
  • • нижня сторона - «Механізм» ( Mechanism ).

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

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

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

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

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

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

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

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

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

Вивчення функцій «Забезпечити захист інформації»

Рис . 4.2. Вивчення функцій «Забезпечити захист інформації»

Вивчення функцій технолога

Мал. 4.3. Вивчення функцій технолога

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

Третім основним поняттям стандарту IDEF0 є декомпозиція ( Decomposition).

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

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

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

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

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

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

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

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

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

Декомпозиція функціональних блоків

Мал. 4.4. Декомпозиція функціональних блоків

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

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

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

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

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

Е1апрімер, для вихідної інтерфейсної дуги «Результати аудиту» глосарій може містити перелік полів відповідного дузі документа, необхідний набір показників.

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

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

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

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

Як правило, процес розробки моделі є ітеративним і містить наступні етапи:

  • 1) створення чернетки моделі (Model Draft). На цьому етапі в створенні моделі бере участь група фахівців, які називаються авторами (Authors) і відносяться до різних сфер діяльності підприємства. Автори опитують компетентних осіб про структуру різних процесів, після чого на основі наявних положень, документів і результатів опитувань створюється чернетку моделі;
  • 2) поширення чернетки для розгляду, погоджень і Ко таріев. На цьому етапі відбувається обговорення чернетки моделі з широким спектром компетентних осіб ( читачів ) на підприємстві. У процесі реалізації цього етапу кожна з діаграм чорновий моделі письмово критикується і коментується, а потім передається автору. Автори, зі свого боку, також письмово погоджуються з критикою або відкидає її з викладом логіки прийняття рішення і знову повертає відкоригований чернетку для подальшого розгляду. Цей цикл триває до тих пір, поки автори і читачі не прийдуть до єдиної думки;
  • 3) офіційне затвердження моделі. Узгоджена модель затверджується керівником робочої групи за умови відсутності розбіжностей з приводу її адекватності у авторів моделі і читачів. Остаточна модель являє собою узгоджене уявлення про підприємство (системі) з заданої точки зору і для заданої мети.

Побудована модель системи може служити основою для її подальшого вдосконалення.

Моделювання з використанням методу IDEF0 включає:

  • 1) концептуальний етап (визначення об'єкта і мети моделювання, обґрунтування точки зору, підбір суб'єктів і встановлення термінів моделювання);
  • 2) етап розробки моделі (побудова IDEFO-діаграм, проведення циклів «автор - читач»);
  • 3) проведення експериментів з моделлю (вивчення моделі AS IS, отримання відповідей на питання типу «що буде, якщо ...»);
  • 4) інтерпретація результатів (побудова моделі ТО BE, документування результатів).
 
<<   ЗМІСТ   >>