Структура управління

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

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

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

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

Організаційна структура

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

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

На концептуальному рівні для кожного підрозділу задається організаційно-штатна структура посад (ролей персоналу).

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

Технічна структура

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

На зовнішньому рівні моделі визначаються типи технічних засобів обробки даних і їх розміщення по структурним підрозділам.

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

На внутрішньому рівні будується модель «клієнт-серверної» архітектури обчислювальної мережі.

11. Синтетична методіка.Та її сутність.

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

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

При побудові адміністративних регламентів виділяються наступні стадії:

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

2. Виділення сценаріїв використання системи. На цій стадії за допомогою критерію корисності будують для кожної зовнішньої сутності набір сценаріїв використання системи.

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

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

5. Функціональна декомпозиція діаграм активностей як контекстних діаграм методики IDEF0.

6. Формальний опис окремих функціональних активностей у вигляді адміністративного регламенту (із застосуванням різнихнотацій).

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

При побудові адміністративних регламентів виділяються наступні стадії:

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

2. Виділення сценаріїв використання системи. На цій стадії за допомогою критерію корисності будують для кожної зовнішньої сутності набір сценаріїв використання системи.

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

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

5. Функціональна декомпозиція діаграм активностей як контекстних діаграм методики IDEF0.

6. Формальний опис окремих функціональних активностей у вигляді адміністративного регламенту (із застосуванням різнихнотацій).

12. Функціональний блок в методиці IDEF0.

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

Функціональний блок (Activity Box) являє собою деяку конкретну функцію в рамках розглянутої системи. За вимогами стандарту назву кожного функціонального блоку має бути сформульовано в дієслівному способі (наприклад, «виробляти послуги»). На діаграмі функціональний блок зображається прямокутником. Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

• верхня сторона має значення «Управління» (Control);

• ліва сторона має значення «Вхід» (Input);

• права сторона має значення «Вихід» (Output);

• нижня сторона має значення «Механізм» (Mechanism).

13. Декомпозіція в методиці IDEF0.

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

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

14. Етапи розробки моделі за стандартом IDEF0.

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

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

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

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

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

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

15. Сховище даних в методиці DFD.

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

16. Словники даних в методиці DFD.

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

17. Переваги та не доліки методики DFD.

До переваг методики DFD відносяться:

• можливість однозначно визначити зовнішні сутності, аналізуючи потоки інформації всередині і поза системою;

• можливість проектування зверху вниз, що полегшує побудову моделі «як має бути»;

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

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