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

Bhagat Nainani

Вступ

Бізнес-процеси - Це основа будь-якої успішної компанії. Ці процеси поєднують системи, партнерів і співробітників для досягнення ключових стратегічних і тактичних цілей. Зростаюча кількість компаній придивляються до Web-сервісів і сервіс-орієнтованої архітектури (Service Oriented Architecture, SOA) для вирішення проблем інтеграції, що виникають при з'єднанні додатків. BPEL і інші стандарти в області Web-сервісів пропонують відкритий, переносимо і стандартизований спосіб вирішення типових проблем розвитку додатків. Вони дозволяють створювати рішення на базі SOA, які забезпечують гнучкість бізнесу при максимальному використанні вже задіяних ресурсів та мінімізації вартості розгортання нових додатків.

Бажання розташовувати адаптивними бізнес-процесами, які можуть бути тонко налаштовані й оптимізовані, щоб відповідати, що змінюються, бізнесу, нормативним вимогам законодавства і тиску конкуренції, призвело до систем управління бізнес-процесами повного циклу (closed loop Business Process Management (BPM) systems). Oracle BPEL Process Manager + інструменти моделювання інших виробників - це повна і легка в застосуванні платформа для проектування і розгортання BPM-рішень повного циклу.

Рис. 1. BPM-рішення повного циклу

Життєвий цикл процесу складається з наступних кроків або завдань:

Моделювання процесу (Model the process) - під час цього кроку власники бізнес-процесів створюють високорівневу модель, що складається із завдань, які повинні виконуватися, і потрібних для цього ресурсів. Крім того, робляться деякі припущення про виконавчі і вартості кожного завдання.

Імітація й аналіз (Simulate and Analyze) - отримана Високорівнева модель використовується для "прогону" деяких гіпотетичних сценаріїв з метою виявлення критичних ділянок (paths) і "вузьких шийок" (bottlenecks). Отримана інформація застосовується для тонкої настройки процесу перед його розгортанням.

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

Розгортання і виконання (Deploy and Execute) - цей крок включає розгортання процесу для BPM-"движка" (BPM-engine) і його виконання для реалізації наскрізних (end to end) потоків [управління та даних] між системами і людьми.

Моніторинг (Monitor) - під час цього кроку відбувається моніторинг бізнес-процесів з метою отримання ключових індикаторів ефективності та інших метрик. Це крок виконується, як правило, із застосуванням засоби моніторингу бізнес-активності (Business Activity monitoring tool) спільно з BPM-"движком".

Оптимізація і перепроектування (Optimize and Redesign) - після того, як над системою в протягом деякого часу проведено моніторинг, отримані за цей час метрики (historical metrics) можуть бути використані для подальшої оптимізації процесу. Реальна пропускна здатність процесу і метрики використання можуть бути введені в інструмент імітації, щоб отримати оптимальну ісполненітельную модель.

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

II. Моделювання процесів із застосуванням BPMN

В як стандарт для моделювання бізнес-процесів отримує визнання BPMN (Business Process Modeling Notation - нотація моделювання бізнес-процесів), розроблена організацією Business Process Modeling Initiative (BPME.org).

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

BPMN прямо відображається на мову виконання бізнес-процесів, такі як BPEL і BPML. BPMN надає нотацію для моделювання, а BPEL є мовою опису виконання процесів.

До ключових особливостей BPMN відносяться:

Пули і Лейн (Pools and lanes - басейни і доріжки) - ці суті використовуються для демаркації процесів і систем. Пул використовується, щоб розділити різні бізнес-суті або учасників. Дії (activities) всередині пулів - це модульні (self-contained) процеси. Лейн (Lanes) використовуються для опису і поділу дій в пулах (як би водні доріжки в басейні - прим.ред). Вони, як правило, використовуються для групування дій по функціях або ролям.

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

Сполучені об'єкти (Connect objects) - різні сутності BPMN можуть бути з'єднані через послідовність операцій, потік операцій (sequence flow), щоб відзначити порядок, в якому дії виконуються, потік повідомлень, щоб відзначити сполучення між сутностями, або асоціацію, що використовується для асоціювання тексту та інших артіфактов з об'єктами потоку (flow objects).

Проектування складного процесу (Complex process design) - BPMN може використовуватися, як для високорівневого опису процесів, так і для опису складних процесів з багатьма рівнями деталізації. Процеси можуть включати деталізують подання (drill down views) для опису деталей більш низького рівня (lower levels of detail) всередині окремих діаграм.

Моделювання і контроль повідомлень (Model message and control) - на додаток до специфікації порядку операцій в потоці BPMN забезпечує подання про об'єкти даних для моделювання того, як документи, дані та інші об'єкти використовуються і змінюються під час процесного потоку.

BPMN надає нотацію моделювання, яка забезпечує перехід від бізнес-визначень до карти виконання процесу (process execution map). Об'єкти BPMN володіють багатим набором атрибутів, які дозволяють легко відображати ці об'єкти в опису BPEL, стандарт defacto для виконання процесів.

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

Розглянемо приклад процесу LoanFlow (), який використовується типовим брокером позик (loan broker). Цей брокер позик приймає запит від клієнта, виконує кредитна перевірку (credit check) зі зверненням до зовнішньої службі і потім направляє це прохання до двох різних агентствам з надання позик (loan agencies). Після отримання пропозицій від них краще буде відібрано і клієнт буде повідомлений про це.

На етапі моделювання звичайно специфікує учасники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService і клієнт). Процес LoanFlow оркестрірует взаємодії між цими сервісами. Для цього необхідно специфікувати послідовність подій і потік повідомлень між цими сутностями, використовуючи BPMN. Рис. 2 ілюструє високорівневу модель процесу в BPMN і деталізацію для підмножини цього процесу, коли відповідний менеджер (loan offer) звертається до двох різних агентствам з надання позик.

III. Імітація та аналіз

Для виконання імітації під час цього етапу життєвого циклу процесу повинні бути зроблені наступні оцінки:

Час (період часу), необхідне для виконання, і ціна кожної дії

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

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

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

Обчислити середнє (average elapsed) час транзакції, повну, від початку до кінця (end-to-end) пропускну здатність і стандартні відхилення (deviation) для визначення того, наскільки ці відхилення відповідають допустимим по угодами про рівень обслуговування SLA (Service Level Agreements);

Ідентифікувати "Вузькі місця" при використанні процесу та ресурсів;

Визначити кількісно людські та інші ресурси, необхідні для завершення завдань, щоб відповідати заданим SLA;

Обчислити очікувані оцінки помилок і рейтинги рівнів обслуговування за 6 сигма (six sigma);

Визначення оптимізації, необхідної для переходу процесу на рівень "як має бути";

Продовжуючи приклад LoanFlow з Секції II, можна змоделювати режим заповнення та час обробки прохань про позику для кожного агентства, про надання позик, а потім "прогнати" імітацію, щоб оцінити пропускну здатність або час відповіді для наскрізного потоку. Також, якщо ми припустимо, що є якийсь, достатня для виконання цього завдання, кількість агентів по позиках у StarLoan і UnitedLoan, і ми задамо якийсь середній час для обробки прохання про позику, то імітація допоможе визначити використання ресурсів і число потрібних ресурсів на основі очікуваних запитів на позики.

IV. Документування та впровадження

Під час цього етапу Високорівнева модель процесу перетворюється в модель виконуваного процесу. До автоматизації процесу він, як правило, документується у формі, яка може бути використана персоналом і партнерами. Цей документ містить інформацію, яка визначає потік бізнес-процесу (business process flow), ролі залучених сутностей, виняткові ситуації, очікування і вимоги до ресурсів. Все це потрібно для майбутньої підтримки і поліпшення процесу. І це також може допомогти в досягненні відповідності деяким вимогам регулюючих органів.

Наступний після документування крок - це впровадження бізнес-процесів. Мова BPEL (Business Process Execution Language) стає очевидним стандартом впровадження для об'єднання безлічі синхронних і асинхронних сервісів в колективні (collaborative) потоки і транзакції. При розробці BPEL скористалися результатами більш ніж десяти досліджень його попередників - мов XLANG і WSFL. Він включає наступні концепції:

Web Services/WSDL - як компонентна модель

XML - Як модель даних

Шаблони синхронного та асинхронного обміну повідомленнями

детермінована і недетермінірованная координація потоку

Ієрархічне керування винятковими ситуаціями

довгоживучих одиниця роботи/компенсації (Long-running unit of work/compensation)

Oracle BPEL Designer надає графічний і дружній інтерфейс для побудови BPEL-процесів. Що виділяє Oracle BPEL Designer - так те, що BPEL - Це його "рідний" формат. Це означає, що процеси, побудовані з застосуванням цього інструменту, 100% переносимість, і, крім того, він дозволяє розробникам переглядати і модифікувати вихідний код на BPEL, не знижуючи корисності цього інструменту.

Якщо високорівнева процес змодельований на BPMN, він перш за все експортується до скелетному (skeletal) BPEL-процесу, який як правило, складається з областей дії процесу (process scopes), дій за викликом/отриманню (invoke/receive activities) і партнерських зв'язків до відповідних сервісів (partner links to the appropriate services).

Наступні кроки мають бути виконані в Oracle BPEL Designer, перш ніж даний процес може бути розгорнутий:

ідентифіковані операцій web-сервісів, які викликаються різними сервісами;

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

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

специфікування положення кінцевих точок (endpoint) і параметрів з'єднання для залучених сервісів.

Якщо ми розглянемо приклад LoanFlow, описаний раніше, то для коду на BPEL, згенерованого із засобу моделювання BPMN, буде потрібно включення URL для цих сервісів, XSD для прохання про позику та пропозиції позики, а також визначення трансформацій даних між документами, які передаються між сервісами. Рис. 3 показує процес LoanFlow, змодельований в Oracle BPEL Designer.

V. Розгортання та виконання

Найбільш критичним етапом у життєвому циклі процесу є його розгортання на платформі, яка може оркестріровать потік і виконувати різні завдання цього процесу. Оркестрування набору сервісів в наскрізний потік процесу вимагає виконання безлічі технічних вимог, включаючи з'єднання (binding) з різнорідними системами, шаблони для синхронного та асинхронного обміну повідомленнями, маніпулювання даними, координація в потоці, управління надзвичайними ситуаціями, недетермінірованние події, що компенсують транзакції (compensating transactions), управління версіями, і т.д. Призначення стандарту BPEL - забезпечення більш багатого, але в той же час більш простого рівня абстракції/стандарту для задоволення цих вимог. Продукт Oracle BPEL Process Manager забезпечує найбільш зрілу, масштабовану і повну реалізацію механізму виконання BPEL, доступну сьогодні. Деякі з ключових функцій цього сервера:

Підтримка стандартів - механізм включає безпосередню підтримку стандартів BPEL і web-сервісів;

Продуктивність і масштабованість - високопродуктивний BPEL-механізм виконує одночасно безліч BPEL-процесів і забезпечує можливість "віджимання" ( "dehydration"), так що стан довгоживучих потоків автоматично підтримується в базі даних. Можливе застосування кластерів для забезпечення масштабованості і відмовостійкості;

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

Безліч платформ розгортання - BPEL Server використовує OC4J як базовий J2EE-сервер додатків з підтримкою більшості основних комерційних серверів додатків;

Вбудовані сервіси інтеграції - вони дозволяють використовувати просунуті можливості з'єднань і трансформацій зі стандартного BPEL-процесу. Ці можливості включають підтримку для трансформацій і з'єднань з використанням механізму XSLT/Xquery, а також безлічі тиражованих додатків і успадкованих систем . Розширювана схема з'єднання WSDL забезпечує з'єднання за протоколами і форматів повідомлень, іншим ніж SOAP. З'єднання доступні для JMS, електронної пошти, JCA, HTTP і багатьох інших протоколів для зв'язку з сотнями внутрішніх (back-end) систем.

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

BPEL Console надає web-інтерфейс для управління, адміністрування та налагодження процесів, розгорнутих на BPEL-сервер. Автоматично підтримуються дані аудиту та інформація історії процесу і звітів, і все це доступне через BPEL Console і Java API.

На рисунку 4 показана архітектура BPEL Process Manager і супутніх компонентів.

VI. Моніторинг

Вимірювання ключових метрик процесів і "видимість" (visibility) в реальному часі виконання процесів критичні для оцінки продуктивності розгорнутих бізнес-процесів. Oracle Business Activity Monitoring (BAM) - це критичний компонент нашого повного BPM-рішення.

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

Ключові концепції Oracle BAM такі:

Бізнес-події (Business Events) - перехоплення таких цікавих подій як зміна інформації про клієнтів, зміни в описі товарів, замовлення на покупку з широкого ряду інформаційних систем підприємства (EIS).

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

Метрики та ключові індикатори еффектівности (КПЕ або KPI) - виконання складної обробки складових подій для генерації метрик і Кае.

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

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

Продовжимо наш приклад з LoanFlow з Секції II. Після того, як процес розгорнуто, BAM-панель може бути використана, щоб відповісти на критичні бізнес-питання:

(a) Запити на позики, надані сьогодні, на цьому тижні, в цьому місяці.

(b) Пропозиції позик в агентства

(c) Середній час обробки однієї позики

(d) середня кредитна оцінка (скоринг) осіб, які бажають отримати позику.

Також BAM-панель може відобразити сигнали:

(a) були надані позики багатьом особам з низькою скорингової оцінкою

(b) відсоток відхилених прохань про позики більше 10%.

Останній факт можна використовувати для переоцінки критеріїв відбору або для того, щоб вжити деякі запобіжні дії. Малюнок 6 показує BAM-панель з деякими ключовими метриками для процесу LoanFlow.

VII. Оптимізація і перепроектування

BAM закриває відсутнє ланка між виконанням процесу і перепроектування. Традиційно імітація процесів заснована на припущеннях і здогадах. Проблема такого підходу в тому, що надійні тільки результати, а припущення робилися на етапі моделювання. При застосуванні BAM, як дані реального часу, так і історичні дані, накопичені за період часу, можуть бути використані, щоб промоделювати процес "як є" ( "as-is") і створити оптимальний процес "як має бути" ( "to-be"). Завдяки таким успішним ітерація процес може бути тонко настроєний, що призведе до значної економії ресурсів та засобів.

Події в BAM також можуть бути використані для оптимізації розгорнутих процесі в реальному часі, завдяки змінам потоку бізнес-процесу. Сигнали (alerts) BAM також можуть почати нові бізнес-процеси для обробки виняткових ситуацій або бути використані для переривань процесів.

Ще раз розглянемо приклад LoanFlow. На етапі оптимізації повинні використовуватися дані реальної обробки на основі щоденних/щомісячних звітів і потім прогони інструменту імітації для виявлення можливих вузьких місць і рівнів обслуговування (predict SLA). Це може призвести до перепроектування процесу. Наприклад, до додавання нових сервісів при оформленні позики, що відповідати вимогам за часом відповідь. Деякі з цих метрик також можуть використовуватися в реальному масштабі часу. Наприклад, якщо якесь з агентств надто довго не відповідає, процес може продовжувати роботу тільки з одним пропозицією позики (стосовно до одного агентству), щоб задовольнити SLA-вимогам обслуговування.

VIII. Партнери

Корпорація Oracle встановила партнерські відносини з рядом постачальників, щоб надати засоби моделювання і імітації разом з Oracle BPEL Process Manager і інструментом Oracle Business Activity Monitoring. У число цих постачальників входять Popkin Systems and Software Ltd (www.popkin.com) - продукти Popkin System Architect і Popkin Simulator II можуть бути використані для моделювання та аналізу процесів. При цьому застосовується BPMN та експорт в форматі BPEL для розгортання на платформі Oracle.

За більш докладною інформацією про моделювання процесів з використанням цих коштів, їх впровадженні та розгортанні з Oracle BPEL Process Manager, звертайтеся за адресою http://www.oracle.com/technology/products/integration/index.html

IX. Висновок

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://citcity.ru/