Лекція 4. Моделювання бізнесу та case-технології
Для моделювання бізнес-процесів часто використовується структурний аналіз. Структурний аналіз є методологічним різновидом системного аналізу. Він був розроблений в 60-70-х роках XX століття Дугласом Т. Россом у вигляді методології SADT (Structured Analysis and Design Technique) – технологія структурного аналізу та проектування. В основі структурного аналізу лежить виявлення структури як відносно стійкої сукупності відношень.
Основним поняттям структурного аналізу служить «структурний елемент (об’єкт)» – елемент, що виконує одну з елементарних функцій, пов’язаний з предметом, процесом чи явищем, що моделюються.
Структурний аналіз передбачає дослідження системи за допомогою її графічного модельного представлення, яке починається із загального огляду і потім деталізується, набуваючи ієрархічної структури із все більшою кількістю рівнів. Для такого підходу характерні:
розбиття на рівні абстракції з обмеженням числа елементів на кожному з рівнів (зазвичай від 3 до 9);
обмежений контекст, який включає тільки суттєві на кожному рівні деталі;
використання строгих формальних правил запису;
послідовне наближення до кінцевого результату.
Мета структурного аналізу полягає у перетворенні загальних знань про вихідну предметну область у точні моделі, які описують різні підсистеми організації, що моделюється.
Декомпозиція є основним прийомом, що дозволяє представити систему у зручному для сприйняття виді та оцінити її складність. В результаті декомпозиції підсистеми за певними ознаками виділяються окремі структурні елементи та зв’язки між ними.
Декомпозиція служить засобом, який дозволяє уникнути забруднень у розумінні системи. Глибина декомпозиції визначається складністю та розмірністю системи, а також цілями моделювання.
Будь-яка організація, як правило, має велику кількість підсистем, у зв’язку з чим кількість структурних елементів та зв’язків між ними є досить великою. Кожний структурний елемент (чи об’єкт) та зв’язок володіють певними властивостями, які повинні бути описані. Одним із різновидів властивостей є атрибути.
Атрибут – необхідна, суттєва, невід’ємна властивість об’єкта.
Природно, що різні структурні елементи мають різні атрибути. Кожний об’єкт чи зв’язок має також набір характеристик, за допомогою яких можна задати кількісні та якісні характеристики елементів, що моделюються. Зокрема, для кожної функції можна задати її ім’я, унікальний код в проекті, автора, час та дату створення, детальне описання, приклад реалізації, часові та вартісні затрати на виконання даної функції тощо. Усі вказані характеристики об’єктів формалізовані і використовуються при проведенні аналізу чи складанні звіту.
Структурний аналіз як сукупність методів моделювання складних систем внаслідок великої розмірності розв’язуваних задач повинен опиратися на потужні засоби комп’ютерної підтримки, що забезпечують автоматизацію праці системних аналітиків. Такими засобами є CASE-системи (Computer Aided Software Engineering). Архітектура більшості CASE-систем базується на парадигмі «методологія – модель – нотація – засоби», рис. 4.1.
Рис. 4.1. Архітектура CASE-систем
Методологія структурного аналізу представляє методи та засоби для дослідження структури і діяльності організації. Вона визначає основні принципи та прийоми використання моделей.
Модель – це сукупність символів (математичних, графічних тощо), яка адекватно описує деякі властивості об’єкта, що моделюється та відношення між ними.
Нотації – система умовних позначень, прийнята в конкретній моделі.
Засоби – апаратне та програмне забезпечення, за допомогою якого реалізується вибрана методологія, зокрема побудова відповідних моделей з прийнятою для них нотацією.
При моделюванні систем, і, зокрема для цілей структурного аналізу, використовуються різні моделі, що відображають:
функції, які повинна виконувати система;
процеси, що забезпечують виконання вказаних функцій;
дані, необхідні для виконання функцій, та відношення між цими даними;
організаційні структури, що забезпечують виконання функцій;
матеріальні та інформаційні потоки, що виникають в ході виконання функцій.
Серед великої кількості засобів, передбачених для проведення структурного аналізу, найчастіше і найефективніше застосовуються:
DFD (Data Flow Diagrams) – діаграми потоків даних в нотаціях Гейна-Сарсона, Йордона Де Марко та інших, що забезпечують вимоги аналізу та функціонального проектування інформаційних систем (приклад зображено на рис. 4.2.);
Рис. 4.2. Приклад діаграм потоків даних
STD (State Transition Diagrams) – діаграми переходу станів, що базуються на розширеннях Хартлі та Уорда-Меллора для проектування систем реального часу (приклади зображено на рис. 4.3, 4.4.);
Рис. 4.3. Діаграма роботи секундоміра
Рис. 4.4. Модель роботи ресторану
ERD (Entity-Ralationship Diagram) – діаграма «сутність-зв’язок» в нотаціях Чена та Баркера (приклад зображено на рис. 4.5);
Рис. 4.5. Приклад ER-діаграми
структурні карти Джексона та Констайна для проектування між модульних взаємодій та внутрішньої структури об’єктів (рис. 4.6);
Рис. 4.6. Приклад структурної карти Джексона
FDD (Functional Decomposition Diagrams) – діаграми функціональної декомпозиції (рис. 4.7);
Рис. 4.7. Приклад декомпозиції структури
SADT (Structured Analysis and Design Technique) – технологія структурного аналізу та проектування (рис. 4.8);
Рис. 4.8. Діаграма SADT
сімейство IDEF (Integration Definition for Function Modeling):
IDEF0 – методологія функціонального моделювання, яка представляє собою структурну частину SADT та дозволяє описати бізнес-процес у вигляді ієрархічної системи взаємозв’язаних функцій (рис. 4.9);
Рис. 4.9. Зразок діаграми IDEF0
IDEF1 – методологія аналізу та вивчення взаємозв’язків між інформаційними потоками у рамках комерційної діяльності підприємства;
IDEF1X – методологія інформаційного моделювання, що базується на концепції «сутність-зв’язок», запропонованій Ченом. Застосовується для розробки реляційних баз даних та використовує умовний синтаксис, спеціально розроблений для зручної побудови концептуальної схеми, який забезпечує універсальне представлення структури даних в рамках підприємства, незалежне від кінцевої реалізації бази даних та апаратної платформи (рис. 4.10);
Рис. 4.10. Діаграма IDEF1X
IDEF3 – методологія документування технологічних процесів підприємства, яка дозволяє моделювати їх сценарії шляхом описання послідовності змін властивостей об’єктів у рамках розглядуваного процесу (рис. 4.11);
Рис. 4.11. Діаграма IDEF3
IDEF4 – методологія об’єктно-орієнтованого проектування для підтримки проектів, пов’язаних з об’єктно-орієнтованими реалізаціями (рис. 4.12);
Рис. 4.12. Діаграма IDEF4
IDEF5 – методологія, що забезпечує наглядне представлення даних, отриманих в результаті обробки онтологічних запитів, у простій графічній формі (рис. 4.13).
Рис. 4.13. Діаграма IDEF5
За допомогою розглянутих методів можуть бути побудовані логічні моделі вихідної та реорганізованої систем управління організацією.
Моделювання бізнесу. На початку 1980-х років, у період бурхливого розвитку теорії управління і становлення термінології в цій області, американським кібернетиком Стенфордом Біром було запропоновано визначення моделі в широкому розумінні цього слова. «дехто вважає, що модель – це математичне рівняння, – пише Бір, – інші вважають її теорією, треті – гіпотезою, але є і такі, хто сприймає її як фізичний предмет. Незважаючи на безхитрісність останніх, вони розуміють проблему найкраще. Ми говоримо пр. модель корабля чи залізної дороги, але ми спеціально говоримо про працюючу модель». Для моделі, пояснює вчений, в загальному випадку характерні чотири властивості:
зменшений масштаб (розмір моделі, точніше її складність завжди менша, ніж у оригіналу, завдяки введеним свідомо спрощенням);
дотримання ключових співвідношень між ключовими частинами (так, у випадку фізичної моделі реально існуючі в оригіналі частини розташовуються у правильному положенні одні відносно одної);
працездатність – можливість в принципі працювати як оригінал (по крайній мірі, подібним чином);
відповідність дійсним властивостям оригіналу (міра достовірності).
Отже, модель потрібна для того, щоб довідатися щось про річ, яка моделюється. Найбільш лаконічне визначення звучить так: А є моделлю В, якщо А дозволяє відповідати на питання, пов’язані з В.
При відсутності не тільки стандартів, а й загальноприйнятих (по крайній мірі в нашій країні) критеріїв в області моделювання бізнесу необхідно знайти по можливості переконливі доводи на користь застосування моделей систем управління фірмою. Моделювання сьогодні – не засіб аналізу бізнесу, а засіб його здійснення. Тому для побудови сучасного технологічного бізнесу необхідно створювати та використовувати моделі. Модель тим більше необхідна, чим менш інтуїтивною і зрозумілою є поведінка об’єкта управління, коли, наприклад, ми очікуємо від нього однієї реакції на управлінський вплив, а отримуємо щось зовсім протилежне. При цьому модель не обов’язково повинна бути рівнянням (чи системою рівнянь). Нею може бути й найпростіший предмет. Головне, щоб модель правильно відповідала якщо не на всі, то хоча б на головні питання про реальний об’єкт.
У бізнесі, як і в усьому світі, в переважній більшості використовуються типові моделі, а ось унікальність (часто дуже перебільшена) є «приправою» до цієї основної частини. Або вимушеною мірою (як, наприклад, при пошиві костюму на нестандартну фігуру).
Моделі, що використовуються для управління бізнесом, можна розділити на кілька груп. В цьому випадку на найвищому рівні розміщуються стратегічні, фундаментальні моделі, що описують глобальні правила та залежності поведінки об’єкта управління. Вони оперують незначною кількістю високо агрегованих показників (у розрахунку на тривалу перспективу) і складають основу стратегічного управління. У свою чергу, залежно від питань, на які повинні відповідати стратегічні моделі, вони можуть поділятися на категорії:
модель фінансового управління (погляд на бізнес з точки зору ружу фінансових засобів);
маркетингова модель (оцінка впливу зовнішнього середовища – ринку – на розглядуваний бізнес);
модель управління виробництвом;
модель управління логістикою (постачанням та збутом).
До цих категорій можна віднести і ряд інших моделей. Для їх побудови використовуються популярні на Заході концепції управління – MRP (Manufacturing Resource Planning), DRP (Distribution Resource Planning), ERP (Enterprise Resource Planning), CSRP (Customer Synchronized Resource Planning).
На другому рівні – транс акційному – розміщується модель, що відповідає за операційну реалізацію глобальних принципів (у вигляді послідовності кроків). Тут ми маємо справу з процесами, сутностями та зв’язками, потоками даних тощо. Важливо відмітити, що будь-яка модель відображає точку зору тієї чи іншої групи проектувальників. Кожній моделі притаманні свої цілі та задачі. У зв’язку з цим об’єкт бізнесу, який представляє собою складний комплексний організм, як правило, описується деяким набором об’єктів, які в сукупності утворюють загальну модель даної бізнес-системи.
Використання багатьох моделей приводить до необхідності їх класифікувати. Обґрунтована класифікація моделей представляє собою їх умовне групування за заданими ознаками відповідно до визначеної цілі. При різних цілях одні й ті ж об’єкти можуть класифікуватися по різному. Класифікація не є самоціллю, вона диктується потребами теорії та практики. Доцільна класифікація моделей забезпечує зручність при виборі методів моделювання та отримання бажаних результатів. До найважливіших ознак, за якими проводиться класифікація моделей, відносяться:
закон функціонування та характерні особливості вираження властивостей та відношень оригіналу;
підстава для перетворення властивостей та відношень моделі у властивості та відношення оригіналу.
Відповідно до першої ознаки моделі діляться на логічні, матеріальні і семантичні (вербальні). Логічні моделі функціонують за законами логіки у свідомості людини чи в комп’ютері, що працює під управлінням написаної людиною програми. Матеріальні моделі функціонують відповідно до об’єктивних законів природи. Семантичні (вербальні) моделі є словесним описанням об’єктів моделювання. Вони застосовуються в ряді випадків, зокрема на початкових етапах моделювання діяльності організації, при опитуванні експертами персоналу з метою отримання необхідної інформації. Основна проблема, що виникає при побудові вербальних моделей бізнес-процесів організації, полягає в тому, щоб встановити ефективну взаємодію між експертами предметної області (співробітниками організації) та фахівцями в області моделювання.
Образні (іконічні) моделі виражають властивості оригіналу за допомогою наглядних образів, що мають прообрази серед об’єктів матеріального світу. Знакові (символічні) моделі виражають властивості системи, що моделюється, за допомогою умовних знаків чи символів. Образно-знакові моделі поєднують у собі ознаки образних та знакових моделей. Функціональні, геометричні та функціонально-геометричні моделі відображають відповідно тільки функціональні, тільки просторові та одночасно функціональні і просторові властивості оригіналу.
За другою ознакою моделі діляться на умовні, аналогічні та математичні, рис. 4.14. Умовні моделі виражають властивості та відношення оригіналу на основі прийнятої умови чи угоди. У таких моделей подібність до оригіналу може взагалі бути відсутнім. Слід відмітити, що образні та образно-знакові моделі також відносяться до умовних. Аналогічні моделі володіють подібністю до оригіналу, достатньою для переходу до оригіналу на основі мислення (висновків умозаключений) по аналогії. Математичні моделі забезпечують перехід до оригіналу, фіксацію та дослідження його властивостей і відношень за допомогою математичних методів. Математичні методи володіють важливими перевагами – чіткістю, можливістю строгої дедукції, здатністю до перевірки. Однак в цілому ряді випадків при побудові математичних моделей можуть виникати проблеми, які складно, а іноді й неможливо вирішити.
Рис. 4.14. Класифікація моделей
Можна провести класифікацію моделей залежно від їх призначення. З точки зору врахування часового фактору виділяють статичні, імітаційні та динамічні моделі. Статичні моделі описують змістовну сторону системи, що не змінюється в часі. Вони можуть бути функціонально-інформаціними (описувати структуру інформації, на основі якої функціонує система), та структурними (описувати структуру системи). Імітаційні моделі дозволяють моделювати поведінку системи залежно від вводимої вихідної інформації. Динамічні моделі дозволяють моделювати поведінку системи в часі, враховуючи фактор її розвитку. З їх допомогою моделюють потік подій.
CASE-системи. На українському ринку представлена досить велика кількість CASE-систем, багато з яких дозволяють створювати описання (моделі) бізнес-процесів. Очевидно, що вибір системи у значній мірі визначає весь подальший хід проекту. Раціональний вибір системи можливий при розумінні керівництвом компанії та її спеціалістами кількох аспектів:
цілей проекту;
вимог до інформації, що характеризує бізнес-процеси та необхідної для аналізу і прийняття рішень в рамках конкретного проекту;
можливості CASE-систем з описання процесів.
Говорити про переваги тієї чи іншої системи/нотації не має змісту доти, поки не визначено тип та рамки проекту, основні задачі, які даний проект повинен вирішувати.
Описання бізнес-процесів проводиться з метою їх подальшого аналізу та реорганізації. Метою реорганізації може бути впровадження інформаційної системи, скорочення затрат на випуск продукції, підвищення якості обслуговування клієнтів, створення посадових та робочих інструкцій при впровадженні стандартів ISO-9000 та ін.. Для кожної такої задачі існують певні параметри, що визначають набір критичних знань по бізнес-процесу. від задачі до задачі вимоги до описання бізнес-процесів можуть змінюватися. В загальному випадку модель бізнес-процесу повинна давати відповіді на наступні питання:
які процедури (функції, роботи) потрібно виконати для отримання заданого кінцевого результату;
в якій послідовності виконуються ці процедури;
які механізми контролю та управління існують в рамках розглядуваного бізнес-процесу;
хто виконує процедури процесу;
які вхідні документи/інформацію використовує кожна процедура процесу;
які вихідні документи/інформацію генерує процедура процесу;
які ресурси необхідні для виконання кожної процедури процесу;
яка документація/умови регламентує виконання процедури;
які параметри характеризують виконання процедур та процесу в цілому.
Описання бізнес-процесу формується за допомогою нотації та інструментального середовища, які дозволяють відобразити узі зазначені аспекти. Тільки в цьому випадку модель бізнес-процесу виявиться корисною для підприємства, адже її можна буде піддати аналізу та реорганізації.
На сьогодні найрозповсюдженішими в Україні CASE-інструментами для моделювання бізнесу є ARIS Collaborative Suite компанії IDS Scheer AG та AllFusion Modelling Suite, зокрема AllFusion Process Modeler (раніше називався BPwin) компанії Computer Associates. Методологія ARIS, що базується на розробленій професором А.В. Шеєром теорії «Архітектура інтегрованих інформаційних систем» (ARchitecture of Integrated Information System – ARIS). Вона визначає принципи моделювання практично усіх аспектів діяльності організацій, що є її корінною відміною від інших методологій. Відповідно до термінології, прийнятої в області структурного аналізу, термін «архітектура» описує типи використовуваних методів, їх функціональні властивості та взаємовідносини між складовими частинами системи, що моделюється.
Методологія ARIS базується на концепції інтеграції, що передбачає цілісний погляд на бізнес-процеси, і представляє собою множину різних методологій, інтегрованих в рамках єдиного системного підходу. Це дозволяє говорити про загальну структуру ARIS. До найважливіших компонентів її архітектури відносяться типи представлення та рівні описання об’єкта, що моделюється. В загальному випадку архітектура ARIS виділяє в організації такі підсистеми, як:
організаційна. Визначає структуру організації – ієрархію підрозділів, посад та конкретних осіб, різноманітність зв’язків між ними, а також територіальну прив’язку структурних підрозділів;
функціональна. Визначає функції, що виконуються в організації;
підсистеми входів/виходів. Визначають потоки використовуваних і створюваних продуктів та послуг;
інформаційна (підсистема даних). Описує отримання, розповсюдження та доступ до інформації (даних);
підсистема процесів управління. Визначає логічну послідовність виконання функцій шляхом подій та повідомлень. Можна сказати, що підсистема управління – це сукупність рознесених в часі повідомлень різного роду;
підсистема цілей організації. Описує ієрархію цілей, що досягаються в ході виконання того чи іншого процесу;
підсистема засобів виробництва. Описує життєвий цикл основних та допоміжних засобів виробництва;
підсистема людських ресурсів. Описує прийом на роботу, навчання та просування по службі персоналу організації;
підсистема розташування організаційних структур. Описує територіальне розташування організаційних одиниць.
Усі ці підсистеми організації в реальності та в моделях повинні бути зв’язані між собою. Методологія ARIS надає можливість описувати досить різнорідні підсистеми у вигляді взаємозв’язаної та взаємоузгодженої сукупності різних моделей, які зберігаються в одному репозиторії. Саме взаємозв’язаність та взаємоузгодженість моделей є відмінною рисою та особливістю методології ARIS.
Відповідно до правил структурного аналізу, кожна з цих підсистем розбивається на окремі блоки (модулі), сукупність яких і складає нотацію структурної моделі тієї чи іншої підсистеми організації.
Природно, що ці підсистеми взаємно проникають одна в одну, і тому одні й ті ж елементарні модулі можуть використовуватися для описання різних структурних моделей. Для усунення надлишковості методологія ARIS обмежує кількість моделей п’ятьма типами представлень:
організаційні моделі, що описують ієрархічну структуру системи, – ієрархію організаційних підрозділів, посад, повноваження конкретних осіб, різноманітність зв’язків між ними, а також територіальну прив’язку структурних підрозділів;
функціональні моделі, які описують функції (процеси, операції), що виконуються в організації;
інформаційні моделі (моделі даних), які відображають структуру інформації, необхідної для реалізації усієї сукупності функцій системи;
моделі процесів/управління, які представляють комплексний погляд на реалізацію ділових процесів в рамках всієї системи та об’єднують інші моделі;
моделі входів/виходів, які описують потоки матеріальних та нематеріальних входів і виходів, включаючи і потоки грошових коштів.
Графічно такий підхід зображено на рис. 4.15.
Рис. 4.15. Взаємозв’язок видів моделей ARIS
У рамках кожного типу представлення створюються моделі, що відображають ту чи іншу сторону досліджуваної системи. Методологія ARIS включає велику кількість методів моделювання, відомих як діаграми Чена ERM, мова UML (Unified Modeling Language), методики OMT (Object Modeling Technique), BSC (Balanced Scorecard) і т.п. Перевага такого підходу полягає в тому, що при аналізі діяльності організації кожному аспекту можна приділяти достатню увагу, не відволікаючись на його зв’язок з іншими аспектами. І тільки після детального вивчення усіх аспектів можна перейти до побудови інтегрованої моделі, яка відображає усі існуючі зв’язки між підсистемами організації.
Організаційні та функціональні моделі, а також моделі даних, входів/виходів та процесів/управління розглядаються як поля у спеціальній базі даних, що називається репозиторієм. Репозиторій є ядром інформаційної системи, що реалізує методологію ARIS. Він має вирішальний вплив на ефективність застосування моделей. Інтеграція різних видів моделей стає можливою завдяки зберіганню їх в єдиному репозиторії. Методологія ARIS не накладає обмежень на послідовність підготовки п’яти типів представлення. Процес аналізу та проектування можна розпочинати з будь-якого з них, залежно від конкретних умов та цілей, які стоять перед виконавцем.
У теорії систем можна провести розмежування між структурою системи та її поведінкою. Структура характеризує статичне представлення системи, а поведінка описує динаміку. У моделях бізнес-процесів динаміка виражається управлінням подіями та потоками повідомлень. Моделі функцій, організаційної структури, даних та виходів описують структуру системи. Моделі управління показують усі структурні зв’язки та описують динамічну поведінку потоку, що відображає бізнес-процес.
Розглянемо нотацію ARIS eEPC (extended Event Driven Process Chain) – розширена нотація описання ланцюжка процесу, що управляється подіями. У табл. 4.1 наведено основні об’єкти, що використовуються в рамках нотації.
Таблиця 4.1