Програмні роботи в керованих бізнес-процесах

Robotic Process Automation / BPM / Системна інтеграція

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

Протягом останніх років корпоративна автоматизація розвивалася переважно через впровадження ERP, CRM, систем електронного документообігу та інтеграційних платформ. Основним завданням було забезпечити контрольоване виконання господарських операцій і скоротити кількість ручної роботи.

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

Інший працівник переносить клієнтські дані з CRM до партнерського порталу. Третій щоденно формує звіт в одній системі та завантажує результат до іншої.

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

Одним із підходів до вирішення проблеми є Robotic Process Automation (RPA). Програмні роботи можуть виконувати визначені дії в користувацьких інтерфейсах, обробляти файли та взаємодіяти з програмами за встановленими правилами.

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

Саме ці завдання належать до сфери Business Process Management — BPM.

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

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

Чим RPA відрізняється від BPM

Попри спільне призначення — автоматизацію корпоративної діяльності — RPA та BPM мають різні функції.

Robotic Process Automation

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

У багатьох випадках він використовує вже наявний графічний інтерфейс.

Це особливо корисно для старих корпоративних застосунків, які не мають сучасних програмних API.

Business Process Management

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

Частина завдань виконується автоматично. Інші потребують участі відповідальних співробітників.

BPM визначає послідовність, умови переходів, строки та правила ескалації.

Головна відмінність

RPA відповідає переважно на запитання: як виконати визначену операцію в конкретному застосунку?

BPM відповідає на запитання: коли, за яких умов, ким і в межах якого бізнес-процесу ця операція повинна виконуватися?

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

Чому робот не повинен самостійно керувати всім процесом

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

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

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

По-перше, процес може тривати декілька днів. Увесь цей час необхідно зберігати його стан.

По-друге, погоджувач може бути відсутнім. По-третє, документ може потребувати додаткової перевірки або повторного погодження.

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

Тому доцільніше використовувати BPM для керування загальною послідовністю. Робот отримує лише конкретне завдання, виконує його та повертає результат.

Наприклад, BPM передає роботу з реєстрації рахунка до RPA. Після завершення робот повідомляє номер створеного документа.

BPM переводить процес до відповідного етапу погодження. Якщо робот повертає помилку, процес переходить до обробки винятку.

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

BPMN 2.0 як мова опису процесів

Для моделювання корпоративних бізнес-процесів використовується BPMN — Business Process Model and Notation. BPMN 2.0 дозволяє описувати події, завдання, шлюзи, послідовності та взаємодію учасників.

Наприклад, у процесі обробки рахунка можна визначити:

• отримання документа;
• автоматичну перевірку реквізитів;
• реєстрацію через RPA;
• погодження відповідальним співробітником;
• перевірку фінансових умов;
• завершення або відхилення процесу.

При цьому роботизована операція може бути представлена як Service Task. Однак BPMN сам по собі не визначає, як саме виконуватиметься інтеграція з RPA.

Це залежить від процесної платформи й архітектури відповідного сервісу.

Приклад логічної моделі

• Отримання рахунка
• Початок процесу
• Data Quality / MDM
• Автоматична перевірка
• RPA: реєстрація в ERP
• Service Task
• Погодження документа
• User Task
• Фінансовий контроль
• Бізнес-правила
• Завершення або виняток
• Результат процесу

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

Якщо підприємство згодом замінить RPA на підтримуваний API, загальна процесна модель може залишитися незмінною.

Camunda BPM 7.8: процесний рушій для інтеграції з роботами

Одним із доступних інструментів BPM є Camunda BPM.

30 листопада 2017 року компанія оголосила про вихід Camunda BPM 7.8.

Отже, у лютому 2018 року підприємства вже можуть використовувати цю версію.

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

External Tasks

Camunda підтримує модель External Task. Процесний рушій створює завдання визначеного типу.

Зовнішній worker отримує його, виконує необхідні дії та повідомляє результат. Це може бути адаптер, який взаємодіє з RPA-платформою.

Наприклад, BPM створює завдання register_invoice. Інтеграційний worker отримує ідентифікатор документа й запускає відповідного робота.

Після завершення робот повертає результат через адаптер.

Обробка помилок

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

Наприклад, відсутність контрагента в ERP не завжди є технічною помилкою. Вона може означати необхідність створити завдання Data Steward.

Контроль стану

BPM дозволяє відстежувати, на якому етапі перебуває документ. Це особливо важливо для довготривалих процесів.

Проте Camunda не забезпечує автоматично всю необхідну логіку інтеграції з UiPath або Blue Prism. Для цього потрібний відповідний адаптер чи інший підтримуваний механізм.

UiPath 2018 Firefly: новий реліз для корпоративної автоматизації

8 лютого 2018 року UiPath оголосила про загальну доступність платформи UiPath 2018, що отримала кодову назву Firefly.

Реліз орієнтований на масштабування корпоративної роботизації та розвиток інструментів управління й експлуатації роботів.

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

UiPath Studio

Середовище дозволяє створювати роботизовані сценарії.

Наприклад, розробник описує послідовність операцій із ERP, файлами чи вебзастосунками.

UiPath Robot

Компонент виконує відповідний процес.

Залежно від сценарію робот може працювати за участю користувача або в автоматизованому режимі.

UiPath Orchestrator

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

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

Зв’язок із BPM

UiPath може виконувати технічні операції, тоді як BPM керує загальним маршрутом. Наприклад, Camunda передає завдання через інтеграційний сервіс до відповідного робота.

Результат повертається процесному рушію.

При цьому необхідно враховувати реальні можливості API та інтеграційних компонентів конкретної версії UiPath 2018.

Не слід припускати, що всі механізми готових BPM-конекторів, які можуть з’явитися пізніше, уже доступні в лютневому релізі.

Blue Prism 6 та керована роботизація

Ще одним важливим постачальником є Blue Prism. Версія 6 була випущена у 2017 році та вже доступна на початку 2018 року.

Blue Prism орієнтується на централізовану й керовану корпоративну автоматизацію.

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

Process Studio

Використовується для побудови логіки роботизованого процесу.

Object Studio

Дозволяє описувати взаємодію із застосунками.

Control Room

Забезпечує контроль запусків та управління відповідними роботами. Однак у складній корпоративній архітектурі не слід дублювати всі BPM-правила всередині RPA-платформи.

Наприклад, погодження фінансового документа може залишатися в BPM, а Blue Prism виконуватиме лише роботу з відповідним інтерфейсом ERP.

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

Взаємодія BPM та RPA через інтеграційний сервіс

Одним із практичних архітектурних рішень є окремий інтеграційний адаптер. Він знаходиться між BPM-рушієм та RPA-платформою.

Наприклад, Camunda створює External Task. Адаптер отримує завдання, перевіряє необхідні параметри й ініціює робота.

Після завершення адаптер повідомляє BPM результат.

Чому потрібен адаптер

По-перше, процесний рушій не повинен знати всі особливості конкретної RPA-платформи. По-друге, необхідно контролювати обробку помилок.

По-третє, важливо забезпечити ідемпотентність.

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

Контракт виконання

Для завдання доцільно визначати стабільні параметри.

Наприклад:

{
  "taskId": "BPM-20180213-1024",
  "processType": "InvoiceRegistration",
  "documentId": "DOC-5824",
  "sourceSystem": "EDM",
  "targetSystem": "ERP"
}

Це умовний інформаційний контракт. Він не є готовим API конкретної RPA-платформи.

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

Якщо можливо, робот може отримувати їх через захищене сховище за визначеним ідентифікатором.

Data Quality та MDM перед виконанням роботизованих операцій

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

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

Тому перед виконанням критичних операцій необхідно використовувати MDM.

Перевірка контрагентів

Робот або інтеграційний сервіс звертається до корпоративного реєстру. Якщо знайдено один підтверджений запис, використовується відповідний ідентифікатор.

Якщо знайдено декілька потенційних збігів, процес передає випадок Data Steward.

Контроль реквізитів

Для рахунків перевіряються валюта, сума, номер документа та інші необхідні поля.

Обробка винятків

Якщо реквізити не відповідають правилам, робот не повинен автоматично заповнювати їх довільними значеннями.

Контроль результату

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

Сам факт натискання кнопки «Зберегти» не є достатньою гарантією.

Ідемпотентність і повторне виконання

Для RPA особливо важливо враховувати ситуації часткових відмов. Наприклад, робот створив рахунок у ERP, але втратив мережеве з’єднання до підтвердження результату.

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

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

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

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

Коли RPA економічно виправдана

Не кожна ручна операція потребує робота.

Перш ніж починати впровадження, необхідно оцінити альтернативи.

Наприклад, якщо ERP має підтримуваний API для створення замовлень, його використання може бути стабільнішим за UI-автоматизацію.

Якщо завдання полягає в масовому завантаженні таблиць до DWH, доцільніше використовувати ETL або ELT.

RPA найбільш корисна тоді, коли застосунок не має придатного програмного інтерфейсу, а повторювана робота достатньо стабільна.

Критерії вибору

Для підприємства важливо оцінювати не лише час ручної операції.

До розрахунку потрібно включати ліцензії, інфраструктуру, розроблення, тестування та супровід роботизованих сценаріїв.

Практичний сценарій: автоматизація фінансових документів

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

Документи надходять до СЕД та повинні реєструватися в ERP.

Компанія вже має BPM для погодження, але значна частина введення реквізитів залишається ручною.

Етап 1. Процесна модель

Команда визначає послідовність обробки рахунка через BPMN.

Етап 2. Data Quality

Виконується перевірка обов’язкових реквізитів.

Етап 3. MDM

Контролюється відповідність постачальника затвердженому корпоративному довіднику.

Етап 4. RPA

Робот відкриває ERP та виконує реєстрацію документа.

Етап 5. Підтвердження

Система перевіряє номер створеного запису й фіксує результат.

Етап 6. BPM

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

Етап 7. Винятки

Якщо постачальника немає або реквізити суперечливі, створюється завдання Data Steward чи фінансовому спеціалісту.

Етап 8. Аудит

Зберігаються ідентифікатор процесу, результат робота та відповідні рішення.

Етап 9. Оцінка

Підприємство вимірює середній час обробки, кількість помилок і частку ручних втручань.

У результаті роботизація стає частиною керованого процесу, а не ізольованим сценарієм натискання кнопок.

Інформаційна безпека RPA

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

Тому необхідно правильно організувати їхні повноваження.

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

Окремі облікові записи

За можливості потрібно використовувати визначені технічні облікові записи.

Мінімальні права

Доступ надається лише до необхідних функцій.

Захист секретів

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

Журналювання

Необхідно фіксувати критичні операції.

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

Підготовка до GDPR

Для процесів, на які поширюватиметься GDPR з 25 травня 2018 року, необхідно оцінювати цілі й правові підстави обробки персональних даних роботами.

Роботизація не створює автоматичного права копіювати інформацію між системами.

Організаційна модель RPA та BPM

Для масштабного використання підприємству потрібен розподіл відповідальності.

• Process Owner визначає бізнесовий результат і правила процесу.
• BPM Analyst формує процесну модель та описує маршрути погодження.
• RPA Developer створює й підтримує роботизовані сценарії.
• Integration Architect визначає взаємодію між BPM, RPA та корпоративними системами.
• Data Steward забезпечує перевірку проблемних даних.
• ІТ-служба відповідає за експлуатацію, моніторинг і технічний захист.

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

Наприклад, оновлення інтерфейсу ERP може порушити роботу RPA.

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

Це завдання пов’язане з корпоративним Change Management.

Технічні вимоги до поєднання BPM і RPA

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

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

Моделювання процесів і системна інтеграція допомагають включити автоматизовані операції в наскрізні процеси.

Роботам потрібні надійні обчислювальні ресурси, мережевий доступ і сховища.

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

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

Практичні орієнтири для впровадження

Поєднання RPA та BPM створює нові можливості для автоматизації корпоративних інформаційних процесів.

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

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

Camunda BPM 7.8, UiPath 2018 і Blue Prism 6 пропонують відповідні технологічні складові для побудови такої архітектури.

Проте роботизація не повинна замінювати підтримувані API без достатніх причин.

Для фінансових і господарських операцій особливо важливі ідемпотентність, Data Quality, MDM та аудит результатів.

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

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