Гужва В.М. Інформаційні системи і технології на підприємствах

Подождите немного. Документ загружается.

364

9.3.2.1 Repository

Repository — центральний компонент Miracle V. У ньому збе-

рігаються усі визначення, правила та описи (включаючи зв’язки

та відношення між ними самими). Repository являє собою різні

аспекти інформаційної системи (рис. 9.16), які контролюють і ви-

значають роботу виконавчої системи Miracle V. Інструменти

Miracle V використовують інформацію з Repository та зберігають

її у ньому. Його можна описати як «вихідний код» для всіх прик-

ладних програм.

Business Process

Modeler

OO Model Studio

Repository

Модель підприємства

Управління

Рис. 9.16. Різні аспекти інформаційної системи

Різноманітні аспекти підприємства (наприклад, процеси, орга-

нізація, структури даних тощо) описуються в єдиній, внутрішньо

узгодженій, придатній до практичного застосування моделі –

Repository. Головною перевагою даної архітектури є поєднання

цих аспектів, а не розподіл їх по різних моделях і за допомогою

різних інструментів. Вона гарантує цілісність та внутрішню узго-

дженість у системі усіх аспектів і кожного з них з іншими.

Як і в усіх компонентах Miracle V, включаючи й виконавчу

систему, в Repository суворо дотримані принципи об’єктно-орієн-

тованого програмування. В Repository визначаються базові класи.

Від них походять усі інші класи, наприклад, від класу «Основні

дані (Trunk data)» походить клас «Адреси». Таким чином, не тіль-

ки Miracle V, а й уся бізнес-модель є об’єктно-орієнтованою. На

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

си, документи, журнали, форми, вибірки, запити, дозволи на

365

доступ, організаційні структури (рис. 9.17). Усі окремі класи в

моделі можуть поєднуватися один з одним — вільно асоціювати-

ся або тісно пов’язуватися. Ці зв’язки полягають не просто в спе-

ціалізації та ієрархії наслідування (наприклад, нова адреса приє-

днується до форми адреси, яка, в свою чергу, приєднується до

запиту). Усі класи з їхніми відношеннями складають бізнес-

модель. Вона є робочою моделлю Miracle V.

Наводимо діаграму, яка описує конструкцію Repository.

Основні

дані

Процеси

Документи

Журнали

Черга

Вибірка

Маски

Дозволи

на доступ

Клас

(адреса)

Клас (…)

Клас

(адресна

маска)

Клас

(споживачі)

Атрибут

Метод

Зв’язок

Населений

пункт

…

Видалити

Створити

Змінити

Черга

Адресна

маска

Кнопки

Фіксація

Документи

. . .

Рис. 9.17. Схема Repository

366

Цей приклад роз’яснює викладені вище думки. Компанії

«Байк Інк» потрібно вводити адреси, де вказується більш ніж од-

на контактна особа. Існує клас «адреса», похідний від базового

класу «основні дані». Атрибути — це поля для необхідних даних

про адресата (назва компанії, прізвище, ім’я, відділ і т. ін.). Оби-

раються методи «створити», «змінити» та «вилучити».

За допомогою компоненти Miracle V Form Designer (дизайнер

форм) генерується форма для адреси. Дизайнер форм «знає» про

атрибути (поля) та методи (функції) з класу «Адреса». Форма

адреси є породженням форм базового класу. Клас «Адреса» по-

єднаний з відповідною формою, що дозволяє їй управляти адре-

сами. Окрім того, клас «Адреса» пов’язаний з класом «населений

пункт» (похідним від базового класу «Основні дані»), котрий мі-

стить усі населені пункти та відповідні індекси. Метод «внесення

населеного пункту», який дозволяє обирати індекс, також досту-

пний класу «адреса». Для вказання контактної особи створюється

клас «контактна особа», похідний від класу «адреса». Далі визна-

чається взаємозв’язок між двома класами, в даному випадку 1:n

(це означає, що одній адресі можуть відповідати одна або декіль-

ка контактних осіб). Контактна особа, проте, відповідає лише од-

ній адресі. «Байк Інк» не потрібно здійснювати операції з наведе-

ного прикладу, оскільки все це вже введене в довідковій моделі.

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

9.3.2.2. Інструментарій для побудови бізнес-процесів

Усі інструменти Miracle V, прямо пов’язані з процесами, на-

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

Business Process Modeler, Business Process Executer, Business

Process Analyzer та Business Process Simulator. Modeler визначає

процеси на різних рівнях абстракції. Під час моделювання проце-

си відкриваються та виконуються додатком Executer. Уся інфор-

мація, зібрана під час роботи, може бути вивчена за допомогою

компонента Analyzer. Simulator створює сценарії типу «що—

якщо для усіх процесів або їхніх частин.

Опис перелічених інструментів для побудови бізнес-процесів

наводиться нижче.



Business Process Modeler

У Business Process Modeler процеси визначаються графічно

на різних рівнях абстракції. Програмне середовище «дружнє»

367

щодо користувача і зрозуміле йому. Різні рівні дозволяють ко-

ристувачеві ніколи не випускати з уваги процеси в цілому, на-

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

турами.

Найвищим рівнем є групи процесів. Вони поділяються на

різноманітні категорії, які визначаються користувачем. Група

процесів може містити інші групи процесів або власні процеси

користувача. Процеси поділяються на один або більше частко-

вих процесів. На ще нижчому рівні часткові процеси розгляда-

ються як діяльність однієї або кількох осіб всередині процесу.

На останньому рівні кожен вид діяльності поділяється на дії —

кроки під час опрацювання інформації інформаційною систе-

мою (рис. 9.18).

Діяль-

ність

Частковий

процес

Процес

Групи

процесів

Частковий

процес

Частковий

процес

Частковий

процес

Діяль-

ність

Діяль-

ність

Діяль-

ність

Діяль-

ність

Рис. 9.18. Рівні абстракції у Process Modeler

У бібліотеці довідкової моделі містяться декілька різних про-

цесів однієї спрямованості. Це дозволяє підприємству обирати

процес(и), який(і) підходить(ять) найбільше. Це зменшує потребу

в модифікації процесів (рис. 9.19).

368

Груповий процес «Замовлення»

Замовлення споживача

Виробниче завдання

Замовлення

Процес «Замовлення споживача»

Виставлення

замовлення

Отримання

готових

продуктів

Відправка

Оплата

Рис. 9.19. Загальний вигляд процесу «Замовлення»

Вигляд компонента Process Modeler подібний до блок-схеми.

Найголовніша його відмітна риса — те, що процеси, визначені в

Modeler, можуть одразу вводитися в дію без необхідності вико-

нання будь-яких додаткових кроків. Цілісність інформаційної си-

стеми під час моделювання процесів гарантується, оскільки усі

зміни автоматично перевіряються на відповідність визначенням

та правилам, раніше описаним у Repository (рис. 9.20).

Процес «Замовлення споживача»

Виставлення

замовлення

Отримання

готових

товарів

Відправка

Оплата

Діяльність з отримання готових виробів

Підготувати

товари

Товари

хороші?

Оплата

замов-

лення

Друкування

супроводжуваль-

них документів

Так

Ні

Рис. 9.20. Етап роботи процесу

У Modeler визначається і організаційна структура підприємства.

Органіграма складається з функціональних робочих місць. Таким

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

конкретних найманих працівників. Коли останні змінюються, треба

лише змінити імена. Органіграма призначена не лише для цілей

369

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

інформаційною системою при розподілі завдань (рис. 9.21).

Діяльність з отримання готових виробів

Підготувати

товари

Товари

хороші?

Оплата

замов-

лення

Друкування

супроводжуваль-

них документів

Так

Ні

Друкування

накладних

на поставку

Для «роздрукування супроводжувальних документів»

Друкування

рахунка-

фактури

Передача даних через

системи EDI (електронний

обмін даними)

Рис. 9.21. Етап роботи — операційні кроки (дії)

Різні завдання прив’язуються до функціональних робочих

місць (рис. 9.22):

Рис. 9.22. Компонент Organigram Designer

370

Відповідальність за кожне завдання чітко визначається — на

рівні підприємства та на рівні інформаційної системи. Додаток

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

у будь-який момент та для будь-якого завдання визначити, хто

виконує його або хто відповідальний за нього (рис. 9.23).

Рис. 9.23. Business Process Modeler

Як показано вище, Process Modeler також виробляє повну до-

кументацію. За допомогою системи підтримки користувачі завж-

ди знають, де саме у процесі вони знаходяться. Допоміжна інфо-

рмація видається автоматично, залежно від того, з якого завдання

її викликали.



Business Process Executer

Додаток Business Process Executer виконує усі процеси та пра-

вила, визначені у Business Process Modeler. Він відповідає за всі

види завдань, їх цілісність, опрацювання у правильній послідов-

371

ності та нагляд за їх виконанням. Business Process Executer коор-

динує комплекс завдань системи та управління і розподіл окре-

мих завдань (рис. 9.24).

Repository

Виклик

процесу

Макро

Дані

підприємства

Завантаження/

збереження

Процесний об’єкт

Діяльність

Executer

Менеджер

завдання

Рис. 9.24. Система завдань

Далі описується робота Business Process Executer. Після його

активації з робочого місця (WorkPlace) Executer відшукує бажа-

ний процес і запускає перше його завдання. Системні дії вико-

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

у Modeler. Коли дія виконана, викликається наступна (відповід-

но до правил, визначених у Modeler). Ця процедура триває доти,

доки завдання не буде виконане повністю. Звичайно потім Exe-

cuter передає наступне завдання до Task Manager, який надсилає

відповідне повідомлення для наступного відповідального пра-

цівника (або групи). Передана задача належить групі доти, доки

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

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

можуть бути вільно визначені та автоматично передані відпові-

дно до органіграми.

Продовжимо розгляд прикладу — опрацювання вхідного ра-

хунка-фактури у компанії «Байк Інк». Усі вхідні рахунки-фак-

тури спочатку вводяться, потім передаються відповідній особі

для перевірки, підтвердження та сплати. За допомогою ярлика

на робочому місці (Miracle V WorkPlace) активується завдання

«введення рахунків-фактур». Перша дія завантажує форму для

введення рахунка-фактури та інші необхідні компоненти. На-

372

ступна дія, власне введення рахунка-фактури, являє собою вза-

ємодію з користувачем. Коли користувач закінчує дію (введення

рахунка-фактури), вона успішно завершується. Це є остання дія,

отже, завдання «введення рахунків-фактур» також успішно за-

вершується. Task manager потім генерує нове завдання для ро-

бочого місця відповідальної особи. З викликом цією особою

«підтвердження» виконуватимуться усі дії завдання «підтвер-

дження». Коли і воно завершиться, буде створене нове завдання

для відділу рахунків (на їхньому робочому місці). Якщо завдан-

ня відміняється, усі дії автоматично і коректно будуть повернуті

у вихідний стан системою.



Business Process Analyzer

Уся інформація, згенерована під час виконання завдань, запи-

сується компонентом Business Process Analyzer, наприклад, інфо-

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

було витрачено і яким шляхом пішов процес. Ці та інші дані

опрацьовуються додатком Analyzer, а результати надаються влас-

никові процесу та керівництву (в разі потреби).

Головною метою є не аналіз діяльності окремих працівників, а

надання інформації про якість усього процесу за певний промі-

жок часу. Цей інструмент разом з іншими даними процесів до-

зволяє власникам процесів концентруватися на своїй відповіда-

льній роботі та вдосконаленні цих процесів.

За допомогою Miracle V вперше стало можливим аналізу-

вати процеси на основі бази фактичних даних без необхідності

витрачати час та ресурси на збір цієї інформації. Ця нова ідея

безпосередньо впливає на управління якістю, оскільки для ко-

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

виконані і ким.



Business Process Simulator

Немає потреби наголошувати, що у комплексному продук-

ті, як-от Miracle V, обов’язковою є можливість здійснювати

симулювання. Business Process Simulator дозволяє моделюва-

ти та симулювати окремі процеси та їхні частини. Результу

ю-

чий стан середовища генерується на основі статистичних ме-

тодів.

Таким чином, існує можливість експериментувати з нетради-

ційними ідеями, перш ніж впроваджувати їх.

373

9.3.2.3 Робочі місця (WorkPlace)

Робоче місце Miracle V — це інтегроване робоче середовище

та головне вікно для прикладних програм Miracle V. Формат, по-

ведінка та інтуїтивність WorkPlace стандартні для ОС Windows 95

та NT. По суті WorkPlace — це інтерфейс між Miracle V та кін-

цевим користувачем. На робочому місці користувачі знаходять

усі об’єкти, необхідні для виконання своїх задач, — об’єкти біз-

нес-процесів, об’єкти запитів, а також окремі адреси та докумен-

ти (рис. 9.25).

Рис. 9.25. Робоче місце Miracle V

Користувач та ергономічність для користувача були в центрі

уваги під час розробки Miracle V. Це чітко видно по WorkPlace,

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

тувачем згідно з мірою його відповідальності та правами досту-

пу. WorkPlace поводить себе залежно від того, яке завдання ви-

конується. Наприклад, на документи про зарплату у WorkPlace

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

ристувачі, котрі не мають права на доступ до даних про зарплату,

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

завдання, що пов’язані із зарплатою.