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

Моделювання в управлінні бізнес-процесамиґрунтується на розумінні «бізнес-процесу» як логічного, послідовного, взаємозалежного набору заходів, який споживає ресурси, створює цінність і видає результат. У міжнародному стандарті ISO 9000:2000 прийнятий термін "процес", однак у цей час ці терміни можна вважати синонімами.

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

Моделювання бізнес-процесів проводиться з метою їх подальшого аналізу й реорганізації. У моделюванні бізнес-процесів склалися два підходи:

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

2) оскільки при формуванні бізнес-процесів прагнуть до створення більш ефективної організації діяльності, то існуючі процеси зазнають критичному аналізу, удосконалюються, у тому числі з використанням спеціального програмного забезпечення. Цьому відповідає принцип моделювання бізнес-процесів «як повинно бути» (англ. to be). У деяких випадках пропускають фазу «як є» і відразу пропонують моделі типу «як повинне бути».

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

Перетворення бізнес-процесів зводиться до двох основних етапів:

– формування оптимального (ідеального) виду бізнес-процесу (у першу чергу основного);

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

Розроблені різні системи відображення (нотації), застосовувані для моделювання бізнес-процесів, серед яких найбільше використовують наступні:

BPMN – функціональна послідовність робіт;

EPC – послідовність робіт за подіями;

IDEF0 – логічна послідовність робіт;

послідовність робіт, орієнтована на задачі.

Метою реорганізації може бути впровадження інформаційної системи, скорочення витрат, підвищення якості обслуговування клієнтів, створення посадових і робочих інструкцій і т.п., а детальний опис процесів сам по собі не представляє цінності. Реінжиніринг бізнес-процесів (англ. Business process reengineering) – це фундаментальне переосмислення й радикальне перепроектування бізнес-процесів для досягнення максимальної ефективності виробничо-господарської й фінансово-економічної діяльності, оформлене відповідними організаційно-розпорядчими й нормативними документами. Бізнес-інжиніринг складається з моделювання бізнес-процесів (розробка моделі " як є", її аналіз, розробка моделі " як треба") і розробки й реалізації плану перехід до стану "як треба".

Основу багатьох сучасних методологій моделювання бізнес-процесів склали методологія SADT (Structured Analysis and Design Technique – метод структурного аналізу й проектування), сімейство стандартів IDEF (Icam Definition, де Icam – це Integrated Computer-Aided Manufacturing) і алгоритмічні мови. Основні типи методологій моделювання й аналізу бізнес-процесів:

Моделювання бізнес-процесів (Business Process Modeling). Найбільше широко використовувана методологія опису бізнес-процесів – стандарт IDEF0. Моделі в нотації IDEF0 призначені для опису бізнесу компанії у функціональному аспекті.

Опис потоків робіт (Work Flow Modeling). Стандарт IDEF3 призначений для опису робочих процесів і близький до алгоритмічних методів побудови блок-схем.

Опис потоків даних (Data Flow Modeling). Нотація DFD (Data Flow Diagramming), дозволяє відбити послідовність робіт, виконуваних по ходу процесу, і потоки інформації, що циркулюють між цими роботами.

Інші методології.

Стосовно одержання доданої цінності продукту або послуги можна виділити наступні класи процесів:

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

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

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

Функціональний принцип полягає в тому, що для будь-якої функції достатнього обсягу може бути створений окремий підрозділ. Однак, на практиці, обсяги робіт по різних функціях діяльності різні. Дотримуючись цього принципу повсюдно, одержували б структурні підрозділи різних розмірів. Теоретично складне завдання побудови функціонально необхідної організаційної структури підприємства одержало практичне вирішення у формі методів структурного програмування SADT (Structured Analysis and Design Technique), ARIS, які дають можливості здійснення контролю над величезним числом функціональних зв'язків у діяльності підприємства і їх необхідного перетворення з урахуванням зміни взаємодії підприємства із середовищем.

Розроблена наприкінці 60-х років Дугласом Россом методологія SADT з середини 80-х років завдяки появі персональних комп'ютерів із графічними можливостями стала автоматизованою. Застосування методології SADT демонструє, що функціональну структуру будь-якого підприємства можна відобразити за допомогою особливих діаграм, що виражають усі необхідні функції і зв'язки у вигляді блоків і дуг, схематично відображених на рис. 4.4.

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

Рис. 4.4. Типовий функціональний блок і інтерфейсні дуги відображення
функціональної структури підприємства за технологією SADT

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

1) проводиться функціональний розподіл робіт з оцінкою їх трудомісткості;

2) на підставі функціонального розподілу робіт формується вихідна структура функціонально спеціалізованих підрозділів;

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

4) дрібні функціональні підрозділи поєднуються в багатофункціональні до мінімально припустимих розмірів;

5) встановлюється кількість ієрархічних рівнів на основі типової структури, а також з урахуванням забезпечення нормативного діапазону контролю для керівників підрозділів і департаментів;

6) визначається кількість підрозділів на кожному ієрархічному рівні з урахуванням принципу вертикального розподілу праці.

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

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

забезпечити розуміння поточних проблем організації й можливостей їх розв'язання;

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

створити базу для формування вимог до програмного забезпечення (вимоги до ПЗ формуються на основі бізнес-моделі).

Важливим елементом моделі бізнес-процесів є бізнес-правила або правила предметної області. Типовими бізнес-правилами є корпоративна політика й державні закони. Бізнес-правила звичайно формулюються в спеціальному документі й можуть відображатися в моделях.

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

Етапи опису бізнес-процесів:

Визначення цілей опису.

Опис оточення, визначення входів і виходів бізнес-процесу, побудова IDEF0-діаграм.

Опис функціональної структури (дії процесу), побудова IDEF3-діаграм.

Опис потоків (матеріальних, інформаційних, фінансових) процесу, побудова DFD-діаграм.

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

Представимо характеристику найбільш застосовних моделей.

IDEF0 (представлена вище на рис. 4.4).

Модель складається з діаграм, фрагментів текстів і глосарія, що мають посилання один на одного. Діаграми – головні компоненти моделі, усі функції й інтерфейси на них представлені як блоки й дуги. Місце з'єднання дуги із блоком визначає тип інтерфейсу:

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

вхідна інформація входить у блок ліворуч;

результати виходять із блоку праворуч;

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

Кожний компонент моделі може бути розшифрований більш докладно на окремій діаграмі. Рекомендується припиняти моделювання, коли рівень деталізації моделі задовольняє її цілі. Загальне число рівнів у моделі не повинне перевищувати 5-6.

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

На таких діаграмах не зазначені явно ні послідовність, ні час. Метод має рядом недоліків: складність сприйняття (велика кількість дуг на діаграмах і велика кількість рівнів декомпозиції), труднощі зв'язування декількох процесів.

IDEF3.

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

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

Типи зв'язків IDEF3:

1) випередження в часі (Temporal precedence) – відображається простою стрілкою. Вихідна дія повинна завершитися, перш ніж кінцева дія зможе початися;

2) об'єктний потік (Object flow) – стрілка з подвійним наконечником. Вихід вихідної дії є входом кінцевої дії. Вихідна дія повинна завершитися, перш ніж кінцева дія зможе початися. Найменування потокових зв'язків повинні чітко ідентифікувати об'єкт, який передається з їхньою допомогою;

3) нечітке відношення (Relationship) – пунктирна стрілка.

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

"І" – блок зі знаком &.

"АБО, що виключає одне з двох – блок зі знаком Х.

"АБО", блок зі знаком О.

Якщо дії "І", "АБО" повинні виконуватися синхронно, це позначається двома подвійними вертикальними лініями усередині блоку, асинхронно – однією.

Метод IDEF3 дозволяє декомпозувати дію кілька разів, що забезпечує документування альтернативних потоків процесу в одній моделі.

DFD.

Ціль такого представлення – продемонструвати, як кожний процес перетворює свої вхідні дані у вихідні. Може відображати не тільки інформаційні, але й матеріальні потоки.

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

Основними компонентами діаграм потоків даних є:

зовнішні сутності (матеріальний об'єкт або фізична особа, що є джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад);

системи й підсистеми (наприклад, підсистема по роботі з фізичними особами);

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

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

потоки даних (на діаграмі – стрілки).

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

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

Кожний процес на DFD може бути деталізований за допомогою DFD специфікації. Специфікації являють собою описи алгоритмів завдань, виконуваних процесами. Мова специфікацій може варіюватися від структурованої природньої мови або псевдокоду до візуальних мов моделювання.

При моделюванні бізнес-процесів діаграми потоків даних (DFD) використовуються для побудови моделей "AS-IS" і "AS-TO-BE", відображаючи, таким чином пропоновану структуру бізнес-процесів, що існують в організації.

ARIS. У цей час спостерігається тенденція інтеграції різноманітних методів моделювання, що проявляється у формі створення інтегрованих засобів моделювання. Одним з таких засобів є програмний продукт, що носить назву ARIS (Architecture of Integrated Information Systems), розроблений німецькою фірмою IDS Scheer.

ARIS підтримує чотири типи моделей (і безліч видів моделей у кожному типі) різні аспекти досліджуваної системи:

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

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

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

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

Для побудови перерахованих типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи й мови моделювання, зокрема, UML. Процес моделювання можна починати з кожного з типів моделей.

Основна бізнес-модель ARIS – eEPC (extended Event-driven Process Chain, розширена модель ланцюжка процесів, подіq). Нотація ARIS eEPC є розширенням нотації IDEF3. Бізнес-процес у нотації eEPC являє собою потік послідовно виконуваних робіт (процедур, функцій), розташованих у порядку їх виконання. Реальна тривалість виконання процедур в eEPC візуально не відображається. Для одержання інформації про реальну тривалість процесів необхідно використовувати інші інструменти опису, наприклад, MS Project.

Моделі в ARIS являють собою діаграми, елементами яких є різноманітні об'єкти – "функції", "події", "структурні підрозділи", "документи" і т.д. Між об'єктами певних видів можуть бути встановлені зв'язки певних видів ("виконує", "ухвалює рішення", " повинен бути проінформований про результати" та ін.). Кожному об'єкту відповідає певний набір атрибутів, які дозволяють увести додаткову інформацію про конкретний об'єкт.

Представимо основні об'єкти нотації eEPC.

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

Подія. Служить для опису реальних подій, що впливають на виконання функцій.

Організаційна одиниця. Наприклад, відділ.

Документ. Відображає реальні носії інформації, наприклад, паперові документи.

Кластер інформації. Характеризує набір сутностей і зв'язків між ними.

Зв'язок між об'єктами. Тип відносин між об'єктами, наприклад, активація виконання функції деякою подією.

Логічний оператор. Оператори "І", "АБО" що дозволяють описати розгалуження процесу.

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

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

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

При моделюванні бізнес-процесів конкретного підприємства можливо використовувати програмні продукти, створені для розв'язання типових завдань побудови бізнес-процесів або їх окремих блоків. Такі продукти формують основи єдиної системи управління бізнес-процесами BPMS (Business Process Management Systems).

Розв'язання в області Business Process Management (BPM) дозволяють підприємству зробити оптимізацію бізнес-процесів, використовуючи існуючі додатки. Як правило, рішення за допомогою BPM – це комплекс відкритих, заснованих на стандартах компонентів для моделювання, виконання, управління й оптимізації бізнес-процесів, а також інтеграції корпоративних додатків.

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

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

Системи управління бізнес-процесами забезпечують істотні переваги на двох рівнях. Перший рівень – стратегічний, він включає такі переваги, як зв'язок між повсякденною діяльністю компанії і її стратегічними установками. Другий рівень – кількісний: це ті переваги, які можна порахувати або виміряти, наприклад, економія коштів або скорочення строків, наприклад, укладання й узгодження договорів, з тривалості у декілька днів до декількох хвилин.

Ключові функції. Усі пропоновані на даний момент системи управління бізнес-процесами (BPMS), незалежно від платформи реалізації, надають наступні основні функції:

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

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

оперативний моніторинг (у режимі реального часу) основних показників процесів, висновок попереджень про помилки й падінні показників;

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

побудова жорстких регламентованих для всіх співробітників бізнес-процесів (рішення про перехід на наступну фазу ухвалює система, на підставі вже введених даних і логіки бізнес-процесу);

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

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

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

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

· Oracle SOA Suite/Oracle BPM Suite;

· IBM Websphere Process Server (Dynamic Process Edition);

· SAP Netweaver BPM;

· Microsoft Sharepoint і Biztalk Server.

Для залучення зовнішніх виконавців проводиться обстеження бізнес-процесів підприємства-замовника й надалі по можливості використовуються формалізовані засоби управління бізнес-процесами, опис яких виконується у форматі ARIS або Visio.

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

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

· розробка архітектури інтеграційного рішення;

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

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

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

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

· розробка експлуатаційної документації й проведення навчання користувачів системи;

· комплексне тестування інтеграційного розв'язання;

· забезпечення технічної підтримки й супроводу реалізованих розв'язань.

Питання й завдання для самоконтролю

1. Для чого застосовується опис бізнес-процесів?

2. Язик чого використовується як язик опису бізнес-процесів?

3. Які показники використовують для оцінки якості бізнес-процесів?

4. Що відображують вершини та дуги мережевого графу бізнес-процесу?

5. Надати приклади видів опису бізнес-процесів?

6. Що означає принцип «6W» при описі бізнес-процесу?

7. У чому полягає основна мета моделювання бізнес-процесів?

8. У чому полягає різниця в принципах опису бізнес-процесів «as is» і «to be»?

9. Чим розрізнюються методи опису бізнес-процесів BPMN (функціональна послідовність робіт) і EPC (послідовність робіт за подіями)?

10. Чим розрізнюються методи опису бізнес-процесів IDEF0 (логічна послідовність робіт) і послідовність робіт, зорієнтована за задачами?

11. Які характерні риси опису бізнес-процесів за методологією SADT?