STD (State Transition Diagrams) — діаграми переходів станів.

Усі вони містять графічні й текстові засоби моделювання: перші — для зручності відображення основних компонентів моделі, другі — для забезпечення точного визначення її компонентів та зв’язків.

Класична DFDпоказує зовнішні щодо системи джерела і стоки (адресати) даних, ідентифікує логічні функції (процеси) і групи елементів даних, що зв’язують одну функцію з іншою (потоки), а також ідентифікує сховища (накопичувачі) даних, до яких здійснюється доступ. Структури потоків даних і визначення компонентів їх зберігаються й аналізуються у словнику даних. Кожна логічна функція (процес) може бути деталізована за допомогою DFDнижнього рівня; коли подальша деталізація перестає бути корисною, переходять до вираження логіки функції за допомогою специфікації процесу (міні-специфікації). Вміст кожного сховища також зберігається у словнику даних, модель даних сховища розкривається за допомогою ERD. За наявності реального часу DFDдоповнюється засобами опису поведінки системи, залежної від часу, що розкриваються за допомогою STD. Ці взаємозв’язки показані на рис. 2.6.

 

Рис. 2.6. Взаємозв’язок графічних нотацій за структурного аналізу

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

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

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

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

Порівняльний аналіз цих двох методологій можна здійснити за такими параметрами:

а) адекватність засобів проблемі, що розглядається;

б) узгодженість з іншими засобами структурного аналізу;

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

Рис. 2.7. Приклад DFD-діаграми

1) Адекватність. Вибір тієї або іншої структурної методології безпосередньо залежить від предметної області, для якої створюється модель. У нашому випадку методології застосовуються до автоматизованих систем управління підприємством, а не до систем взагалі, як це передбачається в SADT. Для задач, що розглядаються, DFD — поза конкуренцією. На рис. 2.7 та 2.8 наведено моделі вимог до системи автоматизації управління підприємством, що займається розподілом товарів за замовленнями.

По-перше, SADT-діаграми значно менш чіткі й зручні для моделювання АІСУП (порівняйте рис. 2.7 і рис. 2.8). Так, дуги в SADT жорстко типізовані (вхід, вихід, управління, механізм). Водночас стосовно АІСУП стирається смислова відмінність між входами і виходами, з одного боку, і управліннями й механізмами — з іншого: входи, виходи, механізми і управління є потоками даних і/або управління і правилами їх трансформації. Аналіз системи за допомогою потоків даних і процесів, що їх перетворюють, є більш прозорим і недвозначним.

 

Рис. 2.8. Приклад SADT-діаграми

По-друге, в SADT взагалі відсутні чіткі засоби для моделювання особливостей АІСУП. DFD з самого початку створювалися як засіб проектування інформаційних систем, що є ядром АІСУП, і мають більш багатий набір елементів, які адекватно відображають специфіку таких систем (наприклад, сховища даних є прообразами файлів або баз даних, зовнішні сутності відображають взаємодію системи, що моделюється, із зовнішнім світом).

2) Узгодженість. Головним достоїнством будь-яких моделей є можливість інтеграції їх з моделями інших типів. У цьому випадку йдеться про узгодженість функціональних моделей із засобами інформаційного і подійного (часового) моделювання. Узгодження SАDТ-моделі з ЕRD і/або SТD практично неможливе або має тривіальний характер. У свою чергу DFD, ЕRD і SТD взаємно доповнюють одна одну і є по суті узгодженими поданнями різних аспектів однієї і тієї самої моделі. У табл. 2.1 відображена можливість такої інтеграції для DFD і SADT-моделей.

 

Таблиця 2.1

Назва	ЕRD	STD	Структурні карти
DFD	+	+	+
SADT	+	–	–

 

3) Інтеграція з подальшими етапами. Важлива характеристика методології — її сумісність з подальшими етапами застосування результатів аналізу (і передусім з етапом проектування, що йде безпосередньо за аналізом і спирається на його результати). DFD можуть бути легко перетворені в моделі проектування (структурні карти) — це близькі моделі. Більш того, відомий ряд алгоритмів автоматичного перетворення ієрархії DFD в струк­турні карти різних видів, що забезпечує логічний і безболісний перехід від етапу аналізу вимог до проектування системи. З іншого боку, невідомі формальні методи перетворення SADT-діаграм у проектні рішення АІСУП.

2.3.1.2. Структурне проектування

Базовими будівельними блоками АІСУП при використанні структурного підходу є модулі. Всі види модулів у будь-якій мові програмування мають ряд загальних властивостей, з яких істот­ні при структурному проектуванні перелічені нижче:

1) Модуль складається з безлічі операторів мови програмування, записаних послідовно.

2) Модуль має ім’я, на яке до нього можна посилатися як до єдиного фрагмента.

3) Модуль може приймати і/або передавати дані як параметри в послідовності виклику або зв’язувати дані через фіксовані осередки або загальні області.

Під час структурного проектування виконуються два види робіт:

1) проектування архітектури АІСУП, що включає розробку структури та інтерфейсів її компонент (автоматизованих робочих місць), узгодження функцій і технічних вимог до компонентів, визначення інформаційних потоків між основними компонентами, зв’язків між ними і зовнішніми об’єктами;

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

При цьому відбувається розширення моделі вимог:

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

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

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

У структурному підході для цілей проектування модулів використовується техніка структурних карт (схем), що демонструє, яким чином системні вимоги відбиватимуться комбінацією програмних структур. При цьому найчастіше застосовують дві техніки: структурні карти Константайна (Соnstantine), призначені для опису відношень між модулями, і структурні карти Джексона (Jackson) — для опису внутрішньої структури модулів.

Структурні карти Константайна є моделлю відношень ієрархії між програмними модулями. Вузли структурних карт відповідають модулям і областям даних, потоки відображають міжмодульні виклики (в тому числі циклічні, умовні й паралельні). Міжмодульні зв’язки по даних і управлінню також моделюються спеціальними вузлами, прив’язаними до потоків, стрілками вказуються напрями потоків і зв’язків. Фундаментальні елементи структурних карт Константайна стандартизовані ІВМ, ISO і АNSI.

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

2.3.2. Об’єктно-орієнтований підхід

2.3.2.1. Об’єктно-орієнтовані методи аналізу

Важливе місце в розробках АІСУП займають об’єктно-орієн­товані методології, засновані на об’єктній декомпозиції предметної області, що подається у вигляді сукупності об’єктів, які взаємодіють між собою за допомогою передачі повідомлень. Даний підхід не є протиставленням структурному підходу, більш того, фрагменти методологій структурного аналізу (а саме його базові моделі: DFD, ЕRD і SТD) використовуються при об’єктно-орієн­тованому аналізі для моделювання структури і поведінки самих об’єктів.

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

Об’єкти і класи організуються з дотриманням таких принципів:

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

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

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

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

Відомі об’єктно-орієнтовані методології базуються на інтегрованих моделях трьох типів:

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

· динамічній моделі, що відображає часові аспекти й послідовність операцій (при цьому досить часто використовують SТD);

· функціональній моделі, що описує потоки даних (з використанням DFD).

Головними недоліками об’єктно-орієнтованих методологій є такі:

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

· відсутність методу, що однаково добре реалізує етапи ана-
лізу вимог і проектування (більшість методів призначена для об’єктно-орієнтованого аналізу, деякі передбачають слабко розвинуті засоби проектування).

2.3.2.2. Об’єктно-орієнтоване проектування

Якщо методи структурного проектування мали на меті спрощення системної розробки на основі алгоритмічного підходу, то об’єктно-орієнтовані методи вирішують аналогічне завдання, використовуючи описи класів і об’єктів, тобто чіткі засоби об’єкт­но-орієнтованого програмування. Г. Буч визначив об’єктно-орі­єнтоване проектування як «методологію проектування, що поєднує в собі процес об’єктної декомпозиції і прийоми уявлення як логічної та фізичної, так і статичної та динамічної моделей системи, що проектується».

Основою для об’єктно-орієнтованого проектування цілком обґрунтовано служать результати об’єктно-орієнтованого аналізу. Проте результат будь-якого з методів структурного аналізу також може бути використаний як вхідні дані для об’єктно-орієнтовано­го проектування: в цьому разі проводиться інтеграція діаграм потоків даних з класами та об’єктами.

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

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

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

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

2.3.3. Процесно-орієнтований підхід

2.3.3.1. Реінжиніринг бізнесу як основа
процесно-орієнтованого підходу
до створення інформаційних систем

Сучасний підхід до управління підприємством ґрунтується на конвергенції управлінських і інформаційних технологій. Класики теорії сучасного менеджменту — Хаммер, Чампі, Давенпорт, Джонсон, Морріс, Брандон та інші — сходяться на думці, що автоматизоване управління будується на інших принципах, ніж керування підприємствами в передкомп’ютерну епоху, і вимагає докорінної перебудови всієї системи управління. Процес впровадження інформаційної системи в організації тісно пов’язаний із перебудовою самої системи управління — оптимізацією організаційної структури, процесів і функцій, що описують взаємодію ланок цієї структури, а також із зміною мотивації персоналу.

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

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

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

Бізнес-процеси — це ділові, адміністративні, технологічні процедури функціонування підприємства, до яких належать: документообіг, управління фінансовими, матеріальними потоками, персоналом, організаційно-господарськими і технологічними про­цесами, процесами проектування виробів і т.ін. Аналіз і оптимізація бізнес-процесів заради досягнення компанією стратегічних цілей і є реінжиніринг, що виконується за допомогою аналізу внутрішнього середовища підприємства. Його методологічною осно­вою є системний і структурний аналіз, теорія управління великими системами, а також методи керування якістю, промислова інженерія тощо. Відповідна розробка методології дозволила перетворити реінжиніринг в інженерний процес (підкреслюється визначенням!), підтримуваний інструментами і технологіями проектування ділових процесів. Спочатку розглядається існуюча система управління підприємством: виявляються витратні центри, формуються моделі: структурні, функціональні (процесні), моделі даних, а також комплексні — «як є» і «як повинно бути». Потім складається план заходів щодо переходу зі стану «як є» у стан «як повинно бути» і за необхідності проектується інформаційна система, що підвищує ефективність функціонування підприємства.

2.3.3.2. Методика інтегрованого
процесно-орієнтованого проектування
інформаційних систем (ARIS)

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

 

Рис. 2.9. Склад інструментального середовища ARIS

забезпечували генерацію повноцінних програмних модулів, що цілком відповідають установленим вимогам. Для створення автоматизованих систем високого класу, здатних справді підвищити ефективність, необхідні «ручне» програмування або адаптація вже готової системи управління підприємством до умов конкретного об’єкта автоматизації. У зв’язку з цим засоби, що дозволяють проаналізувати всі аспекти діяльності підприємства (а не тільки принципи опрацювання інформації) і спроектувати відповідну автоматизовану систему, можуть не мати засобів генерації робочої програми (приклад — програмний пакет ARIS Toolset компанії IDS Prof. Scheer Gmbh).

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

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

Рис. 2.10. Методологічний «дім» ARIS. Взаємозв’язки моделей

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

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

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

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

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

Результатом проектування за допомогою ARIS Toolset є регуляризація управління. З одного боку, виключаються будь-якого роду надмірність: дублюючі один одного процеси, а також непотрібні з погляду цілей компанії функції і процеси, підрозділи, посади і виконавці. З іншого — жодна з функцій, жодний із процесів не перебуває в «підвішеному» стані, без закріпленої відпові­дальності за виконання.

Після того, як закінчено певний варіант моделювання, можна візуалізувати діяльність і управління на підприємстві, тобто «програти» деякі альтернативні варіанти перетворень, імітуючи виконання процесів у часі. У ARIS Toolset для цих цілей використовується модуль імітаційного моделювання ARIS Simulation, що здійснює імітаційне моделювання на основі графічного уявлення послідовності процесів, керованих подіями (EPC — Event-driven Process Changing).

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

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

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

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

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

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

Моделі, створені за допомогою ARIS Toolset, є основою для реалізації ділових процедур у системах класу workflow (автоматизації ділових процесів) і процесів за допомогою стандартного програмного забезпечення. Ці моделі слугують як вхідна інформація для CASE-систем, що використовуються для розробки нестандартного програмного забезпечення.

2.3.3.3. Процесно-орієнтоване (динамічне)
моделювання підприємства на основі мереж Петрі

В основі будь-якого моделювання лежить теорія, яка стверджує: абсолютна подібність може мати місце лише за умови заміни одного об’єкта таким самим іншим. А це означає, що при моделюванні подібність не має місця — основна мета моделювання полягає в тому, щоб модель досить добре відображала досліджуваний аспект функціонування. Класифікація методів моделювання детально розглянута в [12]. З наведеного там переліку нас найбільше цікавитимуть ті методи, які є найприйнятнішими для моделювання бізнесу (наприклад, діяльності підприємства), тобто для побудови бізнес-моделей, що описують функціонування підприємства. До числа таких методів слід віднести: а) систем­но-структурне моделювання; б) ситуаційне моделювання; в) імітаційне моделювання. У подальшому основна увага зосереджуватиметься на останньому.

2.3.3.3.1. Методика та елементи імітаційного
процесно-орієнтованого (динамічного)
моделювання підприємства

Загалом процес динамічного моделювання підприємства (Dynamic Enterprise Model) можна виразити таким чином: підприємство зводиться до ієрархічної моделі, яка формується з еле­ментарних функціональних модулів (бізнес-функцій), що поєднуються в інформаційні потоки (бізнес-процеси), та організаційної структури підприємства (бізнес-організації). Сукупність моделей бізнес-функцій, моделей бізнес-процесів і моделі бізнес-організації являє собою імітаційну бізнес-модель підприємства (рис. 2.11).

Бізнес-моделі складаються з таких компонентів:

· Модель бізнес-функцій — до її складу входять:

¾ дерево бізнес-функцій;

¾ відношення оптимізації;

¾ «ноу-хау» в галузі удосконалення бізнесу;

¾ ключові показники діяльності.

· Модель бізнес-процесів складається з:

¾ основних бізнес-процесів;

¾ детальних бізнес-процесів.

· Модель бізнес-організації.

· База даних по певній галузі промисловості.

Рис. 2.11. Рівні динамічного моделювання підприємства

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

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

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

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

¾ після виконання діяльності і за її результатами знак копіюється в один (чи декілька) відповідних каналів для передачі факту здійснення діяльності;

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

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

L Модель бізнес-процесів

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

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

· дати наочне уявлення того, яким чином корпоративна система працює з бізнес-процесами найвищого рівня, особливо для певного напряму або виду діяльності (основні процедури), наприклад: «Потік замовлень основної процедури в моделі комерційної діяльності»;

· дати наочне уявлення і задокументувати загальні бізнес-про­цеси (детальні процедури), що підтримуються системою (наприклад: «Надходження від продажу»);

· дати наочне уявлення і задокументувати періодичні детальні бізнес-процеси (наприклад: «Рознесення фінансових операцій» і «Підрахунок циклів»);

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

· зафіксувати розробку процесу (особливо для детальних бізнес-процесів) для надання руху операційному робочому процесові;

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

· розробити й задокументувати перетворення корпоративною системою бізнес-процесів, пов’язаних з конкретним проектом.

· Бізнес-процеси мають такі характеристики:

· бізнес-процеси складаються з ряду компонентів, як-от станів, видів діяльності і контролю. Робота є основною частиною біз­нес-процесів. Стан передує кожному виду діяльності і визначається ним. Діяльність може являти собою сеанс роботи з корпоративною системою, бути прикладним програмним забезпеченням, що не належить до неї, та неавтоматизовану діяльність або вмонтований бізнес-процес;

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

· посадові інструкції, документи аналогового виводу і коди утиліт (сервісних програм) можуть бути співвіднесені з видами діяльності. Посадові інструкції можуть містити особливу допоміжну інформацію для сеансу в межах конкретного бізнес-про­цесу. У рамках певного виду діяльності можливе співвіднесення з документом аналогового виводу, створеним у межах даного виду діяльності. Коди утиліт — це блоки сеансів, що можуть бути використані як допоміжні сеанси (сеанс виводу на екран, роздруківки) під час здійснення певного виду діяльності;

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

· працівники і виконувані ними функції можуть бути співвіднесені з видами діяльності бізнес-процесу;

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

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

l Роботи

Роботи є основною частиною бізнес-процесів. Виділяють такі типи робіт:

¾ ручна робота — робота, не пов’язана з прикладною програмою;

¾ бізнес-процес — робота як процес, що є складовою поточного процесу;

¾ сеанс;

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

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

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