- •2.1. Типова структура та склад інформаційних систем
- •2.1.1. Компоненти системи опрацювання даних
- •2.1.2. Організаційні компоненти інформаційної системи
- •2.2. Моделі життєвого циклу інформаційних систем підприємств та його основні етапи
- •1) Аналіз вимог.
- •2) Розробка технічного завдання.
- •3) Проектування.
- •4) Реалізація (програмування / адаптація).
- •5) Тестування і налагодження.
- •6) Експлуатація і супроводження.
- •2.3. Сучасні підходи до створення інформаційних систем на підприємствах
- •2.3.1. Структурно-орієнтований підхід
- •1) Dfd (Data Flow Diagrams) — діаграми потоків даних разом зі словниками даних і специфікаціями процесів (міні-специфікаціями);
- •2) Erd (Entity—Relationship Diagrams) — діаграми «суть—зв’язок»;
- •3) Std (State Transition Diagrams) — діаграми переходів станів.
- •2.3.2. Об’єктно-орієнтований підхід
- •2.3.3. Процесно-орієнтований підхід
- •2.3.3.3.1. Методика та елементи імітаційного процесно-орієнтованого (динамічного) моделювання підприємства
- • Модель бізнес-процесів
- • Роботи
- • Модель бізнес-функцій
- •Стандартна класифікація бізнес-функцій
- •1. Правила цілісності
- •2. Правила перетворення
- •3. Правила конфігурації
- •4. Правила статичного режиму
- • Модель бізнес-організації
- •Мережі Петрі як засіб побудови динамічних моделей підприємства
- •2.4. Саsе-технології — інструментарій підтримки життєвого циклу інформаційних систем
3. Правила конфігурації
Правила конфігурації використовуються для присвоєння значення параметра залежно від його наявності в бізнес-функціях, бізнес-процесах або комбінацій останніх у бізнес-моделі.
(Приклад правила конфігурації:
Якщо був визначений варіант бізнес-функції «Опрацювання замовлення на покупку в ЕОД (Електронний обмін даними)», то значення параметра «Електронний обмін даними» налагоджується на «так».)
4. Правила статичного режиму
Контроль є одним із компонентів бізнес-процесу і використовується для моделювання варіантів. Під терміном «варіант» слід розуміти умову. В результаті умови з’єднуються з вхідними стрілками на діаграмах мереж Петрі. На додаток до тексту в діаграмі умова може також містити значення, яке встановлюється шляхом використання правил. Якщо значення логічної умови «Хибно», то в результаті така неактивна гілка «дерева» мережі Петрі подається в затемненому вигляді.
Оскільки ці правила можуть бути визначені всередині моделі бізнес-функції, то можливим стає динамічне конфігурування бізнес-процесу.
Ролі та обов’язки
Роль є функцією, що може бути реалізована тільки тими працівниками, за якими ця функція закріплена. Ролі і, якщо необхідно, обов’язки можуть бути пов’язані з роботами, бізнес-процесами, організаційними компонентами і бізнес-функціями. За допомогою ролей визначається, які працівники (групи працівників) уповноважені на виконання певної роботи (або мають відповідні обов’язки).
Розрізняють два типи ролей:
«Ролі за організаційними одиницями» є функціями працівників, що пов’язані з організаційними одиницями у специфічній для замовника організаційній діаграмі (проектній моделі), наприклад:
— фахівець із закупівель;
— фахівець із продажу;
— менеджер;
— планувальник;
— комірник.
«Ролі за бізнес-функціями» є такими функціями працівників, які виконуються у межах визначених бізнес-функцій, наприклад:
а) бізнес-функція: продаж
ролі: фахівець із продажу;
секретар;
б) бізнес-функція: робота із забезпечення матеріалами
ролі: менеджер;
комірник.
Обов’язок являє собою деяку задачу, за допомогою якої специфікується роль (тобто функція, виконувана групою працівників), наприклад:
— «Доступність для рекомендації»;
— «Необхідність у консультації»;
— «Необхідність в інформуванні»;
— «Прийняття остаточного рішення»;
— «Виконання»;
— «Контроль виконання».
З роботою можуть бути пов’язані не більше шести ролей. Для кожної ролі можна задати не більше шести обов’язків.
Ролі й обов’язки наслідуються на нижніх рівнях бізнес-процесів. Якщо для деякого бізнес-процесу одна роль використовується для всіх обов’язків у всіх роботах, то достатньо пов’язати цю роль і відповідні обов’язки з даним процесом. Спадкування ролей і обов’язків не застосовується до організаційних компонентів і бізнес-функцій.
Модель бізнес-організації
Модель бізнес-організації — це опис організаційної структури та структури персоналу організації. Структура персоналу може бути описана на абстрактному рівні за допомогою опису ролей або на конкретному рівні — зіставленням працівників і організаційних одиниць.
Модель бізнес-організації має такі цілі:
одержати уявлення про поточну і, по можливості, майбутню (цільову) організаційні структури і задокументувати їх;
одержати уявлення про зміни в структурах підрозділів компанії залежно від розташування їх у загальній системі й задокументувати їх;
зробити можливим створення інтерфейсу користувача корпоративної системи в розрізі працівників або виконуваних функцій, що полегшується накладанням організаційної моделі на модель бізнес-процесу.
Модель бізнес-організації має такі характеристики:
організаційна модель складається з низки організаційних компонентів. З цими організаційними компонентами можна співвіднести ім’я, тип і текст;
між організаційними компонентами можуть бути встановлені функціональні відношення. З такими функціональними відношеннями можна співвіднести текст;
організаційна модель може складатися з однієї або біль- ше організаційних схем. Дані схеми можуть співвідноситися одна з одною за допомогою визначення компонентів суб- діаграм;
користувачі й функції, які ними виконуються, можуть співвідноситися з організаційними компонентами;
організаційні моделі можуть визначатися за фазами оптимізації так, щоб створити наочне уявлення про ефект проекту накладання бізнес-процесів на організацію.
У загальному випадку модель підприємства включає такі об’єкти:
а) основні дані;
б) референтні моделі;
в) проектні моделі.
Перш ніж скористатися деякою референтною моделлю та побудувати на її основі для конкретного підприємства проектну модель, треба спочатку ввести деякі основні дані (рис. 2.13). По-перше, повинна бути визначена версія, на основі якої створюватиметься модель. По-друге, компоненти, що використовуються в моделях, мають бути визначені як основні дані. Останні включають такі складові, як бізнес-функції, бізнес-процеси та правила. Ці основні дані розміщуються в так званому архіві, що містить конструктивні блоки для моделей, які створюватимуться.
Рис. 2.13. Зв’язок
між об’єктами моделювання
Підсумовуючи, можна зробити такі висновки:
1) референтні моделі складаються з ряду компонентів, доступних в архіві (як визначено в бізнес-об’єкті Основні дані);
2) проектні моделі часто засновані на референтних моделях;
3) проектні моделі складаються з ряду компонентів, доступних в архіві (або нещодавно включених, або отриманих за допомогою референтних моделей);
4) референтні моделі можуть бути засновані на проектних моделях.