Реферат на тему:
Методи та інструменти моделювання управлінських процесів
Ефективність застосування моделей залежить переважно від правильного
використання відповідних методів та інструментів. Для вирішення складних
завдань управління в різних галузях діяльності людини накопичений
багатий досвід у цьому напрямі. Насамперед це стосується ділових
процесів, процесів керування виробництвом тощо.
Певну специфіку накладає на це необхідність автоматизації процесів
управління, головною специфікою яких є використання інтенсивних потоків
інформації. Для фахівця вільне орієнтування у “хащах” різноманітних
методів та інструментів рівнозначно володінню доброю мапою місцевості. А
для цього передусім необхідно ознайомитись з “основними позначками” на
такій мапі.
Останні дослідження і публікації. У публікаціях, що пов’язані з
проблематикою державного управління, усе частіше можна зустріти
безпосереднє використання підходів із застосуванням методу моделювання
або моделей, що побудовані в результаті такого застосування [1-6]). Це
системний підхід, підхід на засадах аналізу процесів та ін. Можна знайти
також матеріали, пов’язані з аналізом технологій, які ґрунтуються на
відповідних стандартах, що зазвичай використовують для
бізнес-інжинірингу або для розробки інформаційних систем [7-10].
Особливе значення набувають ті чи інші технології в умовах активізації
процесів інформатизації державних установ побудови в Україні системи
електронного врядування.
Однак серед невирішених частин проблеми залишається відсутність певного
“галузевого стандарту” як “де-факто”, так і “де-юре”, для методів та
інструментів моделювання. Більшість фахівців державного управління
обмежуються сьогодні використанням найпростіших із них, чим значною
мірою звужують можливості досягти вагоміших результатів.
Метою даної публікації є спроба порівняти особливості наявних методів і
інструментів моделювання та визначити способи їх використання для
побудови методологічної бази дослідження державно-управлінських
процесів.
Стандарти моделювання
Найбільш поширеними підходами дослідження управлінських процесів можна
вважати: системний, ситуаційний, процесний та об’єктно-орієнтований.
Перший з них ґрунтується на класичних уявленнях теорії систем,
кібернетики та інших споріднених дисциплін. Методи моделювання, що були
породжені цим підходом, стали класичними [1; 9].
Ситуаційне управління (або ситуаційне моделювання) розвивалося
паралельно з системологією як міждисциплінарний напрям аналізу
управлінських процесів. Ситуаційна модель прийняття рішень базується на
формуванні моделей проблемних ситуацій з використанням спеціалізованої
мови та отриманні рішення шляхом зіставлення їх з аналогічними моделями,
які відповідають правильному рішенню. Це супроводжується навчанням або з
допомогою експерта, або шляхом використання досвіду розв’язання задач,
який накопичує ситуаційна модель у процесі функціонування.
Стандартами системного та ситуаційного підходів можна вважати відповідні
мови моделювання (такі, наприклад, як Simula, Simscript, GPSS або мова
rx-кодів) або концептуальні технології (такі, як метод кусково-лінійних
агрегатів, теорія систем масового обслуговування і т. ін.), які
будуються на фундаментах відповідних математичних теорій.
Представлення діяльності організації окремими взаємоузгодженими
процесами та постійний контроль за ними і їх результатами є втіленням
процесного підходу в управлінні [3; 7]. У цьому напрямі розроблено
велику кількість стандартів та методологій, найбільш поширеними серед
яких треба вважати сукупність стандартів IDEF. Ця абревіатура походить
від ICAM Definition Method, де ICAM розшифровується як Integrated
Computer Aided Manufacturing, тобто “Інтегроване комп’ютер-орієнтоване
виробництво”. Кожний із стандартів IDEF визначає певну систему нотацій
(перш за все графічних) та конкретну методологію її використання.
Сьогодні до сукупності IDEF можна віднести такі стандарти:
· IDEF0 – методологія функціонального моделювання;
· IDEF1 – методологія моделювання інформаційних потоків усередині
системи, яка дозволяє відображати та аналізувати їх структуру і
взаємозв’язки;
· IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур
(баз даних), яка належить до типу методологій “Сутність-відношення” (ER
– Entity-Relationship) та, як правило, використовується для моделювання
реляційних баз даних;
· IDEF2 – методологія динамічного моделювання розвитку систем (у зв’язку
з серйозними складностями аналізу динамічних систем від цього стандарту
практично відмовились, і його розвиток зупинився на початковому етапі);
· IDEF3 – методологія документування технологічних процесів;
· IDEF4 – методологія побудови об’єктно-орієнтованих систем, яка
дозволяє відображати структуру об’єктів та принципи їх взаємодії,
дозволяючи тим самим аналізувати й оптимізувати складні
об’єктно-орієнтовані системи;
· IDEF5 – стандарт онтологічного дослідження складних систем (під
онтологією тут розуміють певну формалізовану інформаційну архітектуру
об’єкта).
Крім вищезгаданої сукупності до категорії поширених слід віднести
стандарти DFD (Data Flow Diagram – діаграми потоків даних) та WFD (Work
Flow Diagram – діаграми робочих потоків). Вони містять набори символів
або позначень, за допомогою яких може бути описаний бізнес-процес. Ці
позначення прийнято називати мовою або методологією опису процесів.
Незважаючи на різницю у назвах, ці методології є майже ідентичними за
філософією побудови моделей управлінських процесів.
Інструменти моделювання
Практично всі названі вище стандарти мають відповідну комп’ютерну
підтримку у вигляді програмних рішень. Більше того, практичні всі вони
використовуються для підтримки процесів побудови інформаційних систем,
для автоматизації окремих бізнес-процесів. З огляду на це програмні
засоби відносять до категорії CASE-засобів (Computer Aided
System/Software Engineering – комп’ютер-орієнтована системна/програмна
інженерія).
Методологія IDEF0 є основою для широко відомої програмної системи BPwin
(Business Process for Windows). Модель будується за допомогою
“функціональних блоків” та “інтерфейсних дуг”. Перші нагадують
кусково-лінійні агрегати [9], а за допомогою дуг, які пов’язують між
собою блоки, можна зобразити процес будь-якого рівня складності.
Для підтримки стандартів IDEF1/IDEF1X існує багато інструментальних
засобів, оскільки головною метою у цьому випадку виступають бази даних.
СУБД – системи управління базами даних, – які при цьому
використовуються, історично мають у своєму складі відповідні програмні
рішення. Ще до офіційної появи стандартів IDEF1 вже існували та
використовувалися методологія Oracle, методологія Power Builder та ін. З
появою стандартів цього класу до лідерів приєдналася програмна система
ERwin, а саму методологію стали називати ER-моделюванням.
Останнім часом обидві програмні системи BPwin та ERwin випускають у
складі інтегрованого CASE-засобу AllFusion Modeling Suite.
З причин, про які ми вже згадували вище, роботи над стандартом та
методологію IDEF2 були припинені, і тому ніяких поширених інструментів
їх підтримки не існує.
Методології IDEF3, IDEF4 та IDEF5 можна вважати більш “екзотичними”, ніж
попередні, тому важко назвати відомі приклади інструментальних засобів
їх підтримки. Але як елементи інтегрованих технологій вони можуть
використовуватись. Крім того, стандарт IDEF4 має конкурента в особі
стандарту MDA (Model Driven Architecture – архітектура, керована
моделлю), який на сьогодні вважається індустріальним ІТ-стандартом для
об’єктно-орієнтованих систем. Цей стандарт ґрунтується на використанні
мови UML (Unified Modeling Language – уніфікована мова моделювання)
[10].
Не можна не згадати про ARIS (від Architecture of Integrated Information
Systems), яка являє собою методологію та програмний продукт компанії IDS
Sheer, призначений для моделювання бізнес-процесів. Основною перевагою
ARIS можна вважати її високу інтегрованість. Фактично вона включає
підтримку більшості стандартів, які ми розглядали окремо. Зрозуміло, що
такий продукт призначений виключно для великих проектів. Остання
обставина робить її менш доступною для “ізольованого” використання, коли
задіяні тільки окремі функції з великого переліку.
Об’єктно-орієнтований підхід та мова SysML
Мова UML стала стандартом спілкування між учасниками великих проектів
розробки програмного забезпечення. Її багаті зображувальні засоби та
широкий спектр продуктів підтримки сприяли тому, що UML почав проникати
в інші галузі діяльності, пов’язані з моделюванням, наприклад у сферу
моделювання бізнес-процесів. Цілком природно, що це проявилось у появі
мови SysML (System Modeling Language) – клону (або, як ще кажуть,
“профілю”) UML [11].
До специфікації мови SysML були включені нові діаграми – вимог
(requirement), зовнішніх блоків (block definition), внутрішніх блоків
(internal block), часу (timing), параметрична (parametric). Такі
діаграми UML, як діаграми прецедентів, кінцевих автоматів (у попередніх
версіях UML вона називалась “діаграмою станів”), діяльності та
послідовності – використовуються у первісному вигляді.
Найбільш важливою новою діаграмою SysML виступає “діаграма вимог”. Її
призначення – визначення вимог (характеристик, обмежень), які мають
відношення до системи та її окремих компонент. Це, до речі, повністю
відповідає базовим принципам динаміки інформаційних артефактів (ІАр)
управління, що визначають “рівень вимог” як один із сталих станів ІАр
[12].
Основні концепції, покладені в основу семантики діаграми вимог, є
такими:
”
$
o
u
$
u
??}?Requirement. Вимога – можливість, яку повинна забезпечувати система,
або умова, яку вона повинна задовольняти.
· Rationale. Логічне обґрунтування рішень, які приймаються в процесі
моделювання.
· TestCase. Контрольний приклад – процес або діяльність, які
використовуються для визначення відповідності системи заданим вимогам.
· Derive. Залежність між двома вимогами, яка показує, що одна з них
випливає з іншої.
· Satisfy. Залежність між вимогою та елементом моделі, який її
забезпечує.
· Verify. Залежність між вимогою і контрольним прикладом, який перевіряє
виконання цієї вимоги.
· Decomposition. Зв’язок між складною вимогою та однією з її складових
(підвимог).
Усі ці концепції, згідно з правилами мови UML, використовуються на
діаграмі як “стереотипи”.
Для прикладу розглянемо діаграму вимог для відомої всім системи –
світлофора. Базова вимога (ID 1.0) поділена на дві підвимоги: “У
світлофора повинні бути три лампочки: червона, жовта і зелена” та
“Світлофор повинен бути керованим ззовні”. Вимога 1.2 обумовлює ще дві
вимоги: “Світлофор повинен бути здатним одержувати із зовнішнього
пристрою команди перемикання світлового сигналу” та “Світлофор повинен
сповіщати зовнішній пристрій про всі негаразди у своїй роботі”. Крім
того, вимога 1.1 перевіряється контрольним прикладом, який реалізовано
за допомогою функції work, що повертає логічне значення типу Boolean
(“так” або “ні”). А вимоги 1.2.1 і 1.2.2 забезпечуються за допомогою
двох спеціальних “інтерфейсів” (стереотипів класів) ITrafficLight та
ITrafficLightObserver відповідно.
Інтерфейси на діаграмі вимог не є “вимогами”, але вони семантично
пов’язані з відповідними вимогами і розміщені на діаграмі саме для того,
щоб показати спосіб їх забезпечення. З аналогічною метою на діаграмі
розміщені два прецеденти – “Керування світлом” та “Моніторинг світла” –
які також пов’язані з відповідними вимогами стереотипізованим
відношенням “trace” (трасування).
Інші елементи моделі так чи інакше пов’язані з вимогами. Їх конкретне
призначення можна зрозуміти, якщо ознайомитись із схемою класифікації
SysML-діаграм. Усі вони поділені на чотири групи: діаграми структури
(Structure Diagram), параметричні діаграми (Parametric Diagram),
діаграми вимог (Requirement Diagram) та діаграми поведінки (Behavior
Diagram).
До традиційних для UML діаграм класів (Class Diagram) у категорію
діаграм структури включені діаграми зв’язування (Assembly Diagram), які
є модифікацією діаграм складеної структури (Composite Structure Diagram)
UML2.
Діаграми діяльності (Activity Diagram) SysML використовують розширені
можливості керування діями порівняно з аналогічними діаграмами UML.
Інструментальна підтримка SysML сьогодні тільки починається. Практично
всі інструментальні засоби цього класу – комерційні. Найбільш доступним
варіантом для дослідників можна вважати безкоштовний шаблон до відомого
пакета ділової графіки MS Visio, який може бути знайдений у мережі
Інтернет і легко підключений до пакета. У складі шаблону можна знайти
елементи для побудови найбільш важливих елементів SysML: діаграм вимог,
діаграм блоків, параметричних діаграм та ін.
Методологія EUP
Ефективне використання мови SysML, яке передбачає не тільки дослідження
та аналіз складних управлінських процесів, а ще й втілення їх
результатів у реалізацію автоматизованої підтримки окремих процесів,
наприклад, у систему електронного врядування, спирається на накопичений
досвід у галузі ІТ-індустрії. Яскравим прикладом використання такого
досвіду є методологія розробки інформаційних систем (ІС) EUP (Enterprise
Unified Process) [13].
Методологія EUP є розширенням відомої методології RUP (Rational Unified
Process), яка призначена для підтримки софтверних проектів, що
використовують об’єктно-орієнтовану парадигму. Методологія передбачає
використання життєвого циклу.
Під поняттям “підприємство” (enterprise) треба розуміти складну
організаційну систему, процеси якої можуть бути автоматизовані. Це
приклад так званої “двовимірної моделі”. Один вимір – час. Він
визначається “фазами” діяльності: Inception (початкова фаза),
Elaboration (фаза уточнення), Construction (конструювання), Transition
(передача результатів, початок впровадження), Production (власне
виробництво, тиражування) та Retirement (завершення експлуатації
системи). Кожна окрема фаза може, у свою чергу, бути поділена на
“ітерації”, якщо виникає така потреба.
Другий вимір, умовно кажучи, “просторовий”. Він визначає розподіл
діяльностей серед учасників робіт за напрямами (Disciplines):
Development Disciplines (розробка, так званий “основний виробничий
процес” для реалізації ІС), Support Disciplines (процеси підтримки) та
Enterprise Disciplines (загальносистемні роботи).
Роботи в кожному напрямі певним чином розподіляються за фазами і можуть
бути детально регламентовані. У моделі присутня фаза, яку можна назвати
“нульовою фазою”. Вона передує традиційним потокам робіт, які характерні
для типових софтверних проектів. Зрозуміло, що головне завдання цієї
фази дуже важливе – зберегти цілісність системи після автоматизації її
основних процесів.
Головна перевага моделей, подібних до EUP або RUP, полягає в тому, що
вони породжують зрозумілі потоки ІАр, характеристики, поведінку та
взаємодію яких можна визначити дуже точно, використовуючи базові
принципи та закони динаміки інформаційних артефактів управління.
Висновки
Ділові процеси та процеси, що протікають у сфері державного управління,
мають дуже багато спільного. Це і наявність організаційних структур, і
необхідність урахування людського фактора. А найголовніше – це те, що
вони пов’язані з інтенсивними потоками інформації, без урахування яких
приймання управлінських рішень стає складною проблемою. Обійтись без
моделей у таких умовах практично неможливо. Досвід використання
стандартів моделювання ділових процесів багато в чому допомагає їх
використанню для вирішення державно-управлінських проблем.
Вибір тих чи інших методів у конкретних ситуаціях залежить не тільки від
особливостей самих проблем, а й від доступності інструментів підтримки
цих методів. Поява таких ефективних нових засобів моделювання, як мова
SysML та методологія EUP суттєво впливає на ефективність роботи
дослідників та практиків управління, допомагає їм знаходити нові, часто
несподівані результати на шляху інформатизації та комп’ютеризації
важливих процесів.
Подальші дослідження. Головним напрямом подальших досліджень є
визначення динамічних характеристик складних ІАр управління, наявність
яких є характерною рисою процесів державного управління.
Список використаних джерел
1. Нижник Н.Р., Машков О.А. Системний підхід в організації державного
управління: Навч. посіб. / За заг. ред. Н.Р.Нижник. – К.: Вид-во УАДУ,
1998. – 160 с.
2. Пілунський І.В. Моделювання територіальної соціально-економічної
еволюційної системи [Електронний ресурс] // Державне управління: теорія
та практика. – 2005. – № 2. – Режим доступу:
http://www.nbuv.gov.ua/e-journals/DUTP/2005-2/
3. Сухінін Д.В., Маматова Т.В. Процесний підхід до організації
діяльності з надання муніципальних послуг [Електронний ресурс] //
Державне управління: теорія та практика. – 2005. – № 2. – Режим доступу:
http://www.nbuv.gov.ua/e-journals/DUTP /2005-2/
4. Усенко О. Моделювання державного управління освітою в умовах сучасних
суспільно-політичних трансформацій // Проблеми трансформації системи
державного управління в умовах політичної реформи в Україні: Матеріали
наук.-практ. конф. за міжнар. участю, Київ, 31 трав. 2006 р.: У 2 т. /
За заг. ред. О.Ю.Оболенського, В.М.Князєва. – К.: Вид-во НАДУ, 2006. –
Т. 1. – С. 339-341.
5. Федорчак О.В. Проектний підхід як інноваційний механізм державного
управління [Електронний ресурс] // Державне управління: теорія та
практика. – 2006. – № 1. – Режим доступу: http://www.
nbuv.gov.ua/e-journals/DUTP/2006-1/
6. Иванов В., Коробова А. Модель создания и развития “электронного
правительства” // Открытые системы. – 2005. – № 4 //
http://www.osp.ru/os/2005/04/185527/
7. Ковалев С.М., Ковалев В.М. Современные методологии описания
бизнес-процессов IDEF0, DFD, IDEF3 // Справочник экономиста. – 2006. – №
12.
8. Применение бизнес-инжиниринга к задачам государственного управления
// http://www.iso-9001.ru/index.php3?mode=&id=306
9. Панчук А.М. Інформаційний аспект державного управління: особливості
моделювання [Електронний ресурс] // Державне управління: теорія та
практика. – 2006. – № 1. – Режим доступу: http://
www.nbuv.gov.ua/e-journals/DUTP/2006-1/
10. Панчук А.М. Концептуальні моделі у державному управлінні: методи та
засоби [Електронний ресурс] // Державне управління: теорія та практика.
– 2006. – № 2.
11. Николаев А., Зыль С. Визуальное проектирование на основе SysML //
Открытые системы. – 2006. – № 5 // http://www.osp.ru/os/2006/05/2449867/
12. Панчук А.М. Процеси еволюції інформаційних артефактів управління
[Електронний ресурс] // Державне управління: теорія та практика. – 2005.
– № 1. – Режим доступу: http://www.nbuv.gov.ua/e-journals/DUTP/2005-1/
13. Enterprise Unified Process (EUP) Home Page (домашня сторінка моделі
життєвого циклу розробки складних інформаційних систем Скотта У.Амбера)
// http://www.enterpriseunifiedprocess. com/
Нашли опечатку? Выделите и нажмите CTRL+Enter
