У професійному середовищі я дедалі частіше з певним сумом стикаюся з одним напрочуд живучим і доволі шкідливим уявленням:
BPMN 2.0 — універсальна мова опису бізнес-процесів компанії.
Іноді амбіції йдуть ще далі: на BPMN намагаються будувати архітектуру процесів підприємства, описувати холдинги, інформаційні та матеріальні потоки — загалом, описувати практично все, до чого дотягнуться руки. Далі за класикою:
Якщо єдиний твій інструмент — молоток, то всі проблеми у тебе будуть цвяхами.
І проблема тут не в BPMN. Проблема починається тоді, коли спеціалізований інструмент оголошують універсальним, а відсутню в ньому семантику починають добудовувати власною уявою та фантазіями. Перевіримо можливості BPMN не за переказами, навчальними презентаціями та розповідями адептів, а на підставі самого стандарту.
1. Амбітна місія BPMN
У розділі 1.1 OMG формулює основну мету BPMN:
надати нотацію, зрозумілу широкому колу користувачів — від бізнес-аналітиків, які створюють початкові моделі процесів, до технічних фахівців, які реалізують технології їх виконання, і людей, які управлятимуть цими процесами та контролюватимуть їх.
Тут народжується одна з центральних ідей BPMN:
створити стандартизований міст між проектуванням бізнес-процесу та його реалізацією.
Крім того, стандарт має уніфікувати процесну модель і нотацію за умов існування множини підходів і точок зору та в такий спосіб полегшити обмін інформацією про процеси між бізнесом і технічними фахівцями. Конструкція виглядає вельми привабливо: зрозумілість для бізнесу + єдина нотація + формальна семантика + зв’язок із виконанням.
Важливо одразу зафіксувати: сам OMG не називає BPMN універсальною мовою опису бізнесу. Це вже наступний шар міфології. Для початку перевіримо місію BPMN на несуперечливість, виходячи зі змісту самого стандарту.
2. Перший удар по універсальності
Розділ область застосування BPMN варто читати раніше за підручники з BPMN. З’ясовується, що територія мови обмежена доволі жорстко. Стандарт прямо каже, що BPMN підтримує лише ті концепції моделювання, які застосовні до Business Processes. При цьому за межами стандарту прямо залишені:
- організаційні моделі та визначення ресурсів
- функціональна декомпозиція
- моделі даних та інформації
- стратегія
- моделі бізнес-правил.
А далі йде особливо корисна фраза:
BPMN is not a data flow language.
Тобто BPMN може показувати повідомлення та зв’язок даних із роботами процесу, але сам стандарт окремо попереджає: це не мова моделювання потоків даних. На цьому тезу:
«BPMN — універсальна мова опису бізнесу»
можна вважати закритою. Неуніверсальність BPMN — не претензія до стандарту. Це свідомо встановлена самим стандартом межа.
Більше того, OMG прямо передбачає співіснування BPMN з іншими видами бізнес-моделювання та можливість формально визначати відносини між ними. Тобто логіка самого стандарту приблизно така:
BPMN моделює свою область. Інші аспекти бізнесу можуть моделюватися іншими засобами.
Дещо відрізняється від «опишемо всю компанію в BPMN».
Технічна вставка
В офіційній BPMN 2.0.1 цей розділ має номер 7.2 BPMN Scope.
3. Що ж моделює BPMN?
Відповідь добре видно в базовій семантиці мови. Sequence Flow використовується для того, щоб показати порядок елементів процесу. Для пояснення поведінки BPMN використовує концепцію токена, який проходить через роботи, події, шлюзи та Sequence Flow.
Навіть невиконувана BPMN-модель залишається передусім описом поведінки процесу. BPMN відповідає на запитання:
Що відбувається?
Що відбувається далі?
За яких умов?
Як розгалужується та синхронізується виконання?
Які події впливають на перебіг процесу?
Як самостійні учасники взаємодіють один з одним?
Це передусім поведінкова семантика. І саме тут проходить фундаментальна межа.
4. Чому BPMN не є мовою архітектури процесів
Архітектурна модель відповідає на інше запитання:
Що існує і як наявні сутності пов’язані між собою?
Наприклад, на діаграмі процесів ми можемо відобразити: Закупівлі → Виробництво → Продажі і мати на увазі:
Це три процеси компанії, між якими існують певні залежності та передаються результати.
Вони можуть виконуватися в різних сценаріях і комбінаціях.
Але Sequence Flow означає не абстрактне «пов’язаний». Його нормативна семантика — однозначний порядок виконання елементів процесу.
Тому якщо стрілка сьогодні означає:
виконується після
завтра:
отримує результат
післязавтра:
залежить від
а ще через тиждень просто:
пов’язаний із
то перед нами вже не різні способи використання BPMN. Це власна нотація автора, намальована символами BPMN.
І тут обмеження подвійне. Scope виводить за межі BPMN значну частину необхідних архітектурних сутностей. А ключові відносини самого BPMN мають передусім поведінкову та комунікаційну, а не універсальну архітектурну семантику.
Тому:
BPMN може описувати поведінку процесів усередині процесної архітектури. Але це не робить його повноцінною мовою моделювання самої процесної архітектури.
Показово, що автори Real-Life BPMN (Jakob Freund, Bernd Rücker, Real-Life BPMN, 3rd edition, 2016) проводять цю межу цілком недвозначно:
Одного BPMN у більшості проектів недостатньо для моделювання реальної діяльності бізнесу.
5. Перевірка «універсальності» у фізичному світі
Тепер візьмемо вже не заяву, документ чи замовлення. Візьмемо автомобіль. Нам потрібно описати його підготовку та передачу замовнику.
Тут прихильник універсальності BPMN цілком справедливо може сказати:
Але BPMN дозволяє вказати, що представлений об’єкт має фізичну природу.
Так. Стандарт справді дозволяє відрізнити інформаційну природу представленого елемента від фізичної. Тому твердження:
«BPMN взагалі нічого не знає про фізичні об’єкти»
було б неправильним.
Значно цікавіше інше запитання:
Що саме дає нам ця фізичність?
Технічна вставка
На рівні метамоделі фізична природа задається через
ItemDefinition: його атрибутitemKindможе набувати значеньInformationабоPhysical; за замовчуванням використовуєтьсяInformation.Для розуміння подальших міркувань знати будову
ItemDefinitionне потрібно. Достатньо самого факту: BPMN дозволяє позначити представлену сутність як фізичну.
6. Але автомобіль потрапляє до розділу Data Modeling
Ось тут починається найцікавіше. Фізичний об’єкт з’являється в моделі процесу через механізм Data Object. І розташований цей механізм у розділі стандарту Items and Data → Data Modeling.
Data Object зберігає інформацію про дані процесу, бере участь у входах і виходах робіт, а під час виконання BPMN оперує значеннями цих даних.
Тому якщо на схемі написано: Автомобіль виникає запитання:
Що саме перебуває всередині BPMN-моделі — півторатонний фізичний автомобіль чи його представлення в інформаційному контексті процесу?
Найбільш несуперечливим є друге прочитання:
Data Object представляє інформацію про конкретний автомобіль — його ідентифікацію, властивості та стан, суттєві для цього процесу.
Це особливо добре видно з життєвого циклу Data Object. Він пов’язаний із життєвим циклом батьківського Process або Sub-Process. Коли створюється екземпляр процесу, створюються відповідні екземпляри Data Objects. Коли екземпляр Process/Sub-Process припиняє існування, його Data Objects також припиняють існування, а дані, що містилися в них, стають недоступними.
Для: Сума замовлення усе цілком природно.
Тепер візьмемо: Автомобіль.
Екземпляр процесу завершився. Автомобіль у фізичному світі, на щастя, нікуди не зник. Зникло його представлення в контексті цього екземпляра процесу.
Це принципова відмінність.
Технічна вставка
У метамоделі Data Object належить до елементів, здатних зберігати або передавати вміст, пов’язаний із певним типом. У виконуваній семантиці його значення беруть участь в операціях над даними. Стандарт окремо розрізняє Data Object і Data Store: останній якраз призначений для інформації, що зберігається за межами конкретного процесу.
Іншими словами,
Physicalповідомляє нам не те, що BPMN отримав повноцінну модель матеріального світу, а те, що представлена процесом сутність має фізичну природу.
7. Людина бачить стан автомобіля. BPMN знає значно менше
Ми можемо показати: Автомобіль [до відвантаження] а пізніше: Автомобіль [відвантажено].
Для людини природне прочитання:
один фізичний автомобіль змінив свій стан.
BPMN справді дозволяє позначати стан Data Object. Але стандарт прямо попереджає: можливі стани та їхня специфічна семантика ним не визначаються.
Тобто BPMN дозволяє написати: [відвантажено] але сама мова не встановлює, чи означає це:
автомобіль залишив склад
переданий перевізнику
отриманий замовником
чи лише:
в інформаційній системі встановлено статус «відвантажено».
Людина добудовує бізнес-сенс. Стандарт цього сенсу не визначає.
Технічна вставка
У стандарті ця конструкція називається
DataState. Вона фактично дозволяє задати назву стану даних, але модель допустимих станів і переходів між ними BPMN не задає.
8. Виконання просто знімає ілюзію
Можна було б сказати:
на аналітичній схемі у нас є фізичний автомобіль, а під час виконання він перетворюється на дані.
Але це, схоже, надто сміливе трактування. Інформаційне представлення фізичного світу було закладене в конструкцію від початку.
Виконавча семантика лише робить це особливо помітним. Коли BPMN виконує зв’язок Data Object із роботою, він оперує значеннями: отримує значення джерела, за потреби перетворює його та копіює до цільового елемента.
Жодної операції:
«перемістити фізичний об’єкт»
тут немає.
Система виконання процесів працює з інформацією та управляє виконанням робіт, які мають відбуватися у зовнішньому світі.
І тут виявляється ще одна напрочуд показова деталь. Деякі конструкції BPMN стандарт дозволяє моделювати, але не визначає для них достатньої семантики, щоб система виконання процесів була зобов’язана розуміти й виконувати їх зміст.
Сам стандарт називає такі конструкції non-operational.
І серед них одночасно перебувають:
- Manual Task
- стан Data Object
- ознака фізичної природи об’єкта.
Виходить досить цікава картина. BPMN може показати фізичну природу речі. Може зафіксувати її стан. Може показати ручну роботу людини з цією річчю. Але стандартна виконавча семантика не зобов’язана розуміти фізичність речі, смисл її стану і тим більше виконувати саму фізичну роботу.
Технічна вставка
У §13.1 серед
non-operational elementsпрямо переліченіManual Task,Abstract Task,DataStateтаItemDefinitions with an itemKind of Physical. Стандарт пояснює, що для таких елементів надана концептуальна модель, але недостатньо деталей для виконання системою виконання процесів; сумісна реалізація може їх ігнорувати або додати власну семантику шляхом розширення.При цьому Manual Task цілком може перебувати в моделі виконуваного процесу. Просто сама ручна робота «ніколи фактично не виконується ІТ-системою» — це прямо зафіксовано в execution semantics.
9. Влаштуємо невеликий краш-тест BPMN
Тепер уявімо досить просту аналітичну схему.
У процесі продавця є Activity: Відвантажити товар
З нею пов’язаний Data Object: Автомобіль
А з Activity іде Message Flow до Pool: Замовник.
Що побачить майже будь-яка людина?
Автомобіль передали замовнику.
Схема виглядає настільки природно, що величезна кількість BPMN-моделерів узагалі не побачить тут предмета для обговорення.
І справді: сам по собі зв’язок Data Object з Activity допустимий. Activity також може бути джерелом Message Flow.
Але поставимо одне не дуже приємне запитання:
Де в стандарті сказано, що саме автомобіль перетнув межу Pool?
10. Транзитивність, якої не існує
Тут виникає дуже характерний ефект. Data Object пов’язаний з Activity. Activity має Message Flow до замовника.
Мозок автоматично добудовує третій зв’язок:
отже автомобіль передається замовнику.
Виходить уявна транзитивність: Автомобіль → Відвантажити товар і Відвантажити товар → Замовник подумки перетворюються на: Автомобіль → Замовник.
Але BPMN такого правила не містить.
Із двох допустимих відносин не виникає третя семантика:
якщо Data Object є результатом Activity, а Activity є джерелом Message Flow, то цей Data Object автоматично передається іншому учаснику цим Message Flow.
Такого правила немає.
Можна розташувати біля Activity одночасно: Автомобіль, накладну, ключі та гарантійний талон і провести один Message Flow до замовника.
Що саме з цього «пішло» до замовника? Візуальна близькість відповіді не дає.
11. Що саме йде до замовника?
Ось тут стандарт відповідає цілком однозначно. По Message Flow іде Message.
Не автомобіль, який опинився поруч на схемі. Не будь-який Data Object, пов’язаний з Activity. А повідомлення.
Сам стандарт визначає Message як зміст комунікації між двома учасниками; окремо в метамоделі задається і його вміст.
Тобто між самостійними учасниками BPMN моделює передусім комунікацію.
Замовнику можна повідомити номер автомобіля. Можна надіслати накладну. Можна передати підтвердження відвантаження. Можна повідомити, що автомобіль готовий до видачі.
Але повідомлення про автомобіль — не автомобіль. Інформація про контейнер — не контейнер.
І Message Flow не стає матеріальним потоком лише тому, що біля Activity-відправника намальований Data Object.
Технічна вставка
Data Object узагалі відсутній серед елементів, які можуть бути джерелом або ціллю Message Flow. Такими елементами можуть бути Pool/Participant, Activity та деякі Events. Якщо конкретне Message визначене, Message Flow може посилатися на нього через
messageRef.
messageRefнеобов’язковий. Тому якщо конкретне Message не вказане, модель повідомляє ще менше — вона фіксує комунікацію, але тим більше не перетворює сусідній Data Object на передавану річ.
12. Семантична катастрофа на межі Pool
Тепер спробуймо все-таки проявити настирливість:
Data Object — це буквально сам фізичний автомобіль.
Тоді виникає вельми цікава конструкція. У процесі продавця існує фізичний Data Object - автомобіль. Сам Data Object пройти через Message Flow не може. Між учасниками проходить Message — зміст комунікації. У процесі отримувача може з’явитися вже своє представлення автомобіля.
І якщо сприймати Data Object буквально як саму фізичну річ, виходить майже метафізичний процес:
автомобіль помирає як Data Object одного процесу, перетворюється на зміст комунікації та воскресає як Data Object іншого процесу.
Це і є семантична катастрофа фізичного об’єкта на межі Pool.
Звісно, сам стандарт не вимагає проводити обряд перетворення автомобіля на повідомлення. Навпаки.
Абсурд виникає саме тому, що ми намагаємося надати Data Object і Message Flow семантику матеріального потоку, якої в них немає.
Якщо ж розуміти Data Object як інформаційне представлення автомобіля, усе раптом стає логічним. В одному процесі існують дані про автомобіль. Між учасниками передається інформація. В іншому процесі з’являються дані про той самий автомобіль.
Чудова інформаційна модель взаємодії.
Але де тут саме фізичне переміщення автомобіля? Його в семантиці цих відносин, як і раніше, немає.
13. Три сосни матеріального потоку
Після цього експеримент можна згорнути до дуже простої моделі.
Sequence Flow говорить, що відбувається далі. Зв’язок даних з Activity — Data Association — показує використання або отримання даних роботою і під час виконання оперує їх значеннями. Message Flow показує комунікацію між самостійними учасниками.
Жодне з цих відносин не означає:
той самий фізичний предмет перемістився від A до B, зберігши свою фізичну ідентичність.
Окремого відношення на кшталт Material Flow BPMN не має.
Тому власної нормативної семантики фізичного місцезнаходження, матеріального балансу, передачі володіння або зберігання, фізичного поділу партії та часткового постачання як руху певної кількості матеріальних об’єктів мова не надає.
Усе це можна представити через інформацію про фізичний світ. Наприклад, зберегти кількість, масу, місцезнаходження або статус у даних процесу.
Але запис:
залишок = 350 кг
не перетворює BPMN на мову матеріального балансу.
Так само як запис:
автомобіль передано замовнику = true
не означає, що BPMN змоделював фізичну передачу автомобіля.
14. І це повністю узгоджується зі Scope
Тепер повернімося до початку. Стандарт сам попереджає:
BPMN показує Messages і зв’язок даних з Activities, але не є мовою потоків даних.
Тут проявляється вельми характерна особливість BPMN.
Він може використовувати ресурс. Може працювати з інформацією. Може позначити фізичну природу представленого об’єкта. Може викликати бізнес-правило. Може показати організаційного учасника.
Але від цього він не стає мовою ресурсного моделювання, інформаційної архітектури, матеріальних потоків, бізнес-правил або організаційної архітектури.
Звідси можна вивести загальний принцип:
BPMN може використовувати об’єкт певної предметної області тією мірою, якою він необхідний для опису поведінки процесу, не стаючи мовою моделювання самої цієї предметної області.
І зовсім коротко:
BPMN моделює не бізнес навколо процесу, а процес усередині бізнесу.
15. Що тоді залишилося від «мосту між бізнесом та ІТ»?
Міст залишився. Але виявився істотно вужчим, ніж популярна інтерпретація цієї формули.
Бізнес дивиться на модель: Автомобіль [до відвантаження] → Відвантажити товар → Автомобіль [відвантажено] і чудово розуміє її зміст.
Але коли ми запитуємо:
що саме з цього розуміє і виконує система виконання процесів?
картина стає іншою.
Фізична природа автомобіля не має обов’язкової виконавчої семантики. Його підписаний стан — теж. Manual Task може позначати реальну ручну роботу, але ІТ-система саму цю роботу не виконує. Зв’язки даних працюють зі значеннями. Message Flow працює з повідомленнями.
Тобто виконання не перетворює автомобіль на дані.
Дані про нього тільки й були всередині виконуваної моделі.
Система виконання процесів здатна призначити людині роботу, дочекатися підтвердження, змінити значення статусу, зберегти VIN, надіслати повідомлення замовнику та продовжити процес.
Але те, що півтори тонни металу справді залишили склад і опинилися у клієнта, відбувається у зовнішньому фізичному світі. Система може лише отримати інформацію про те, що це сталося.
І ось тут формулу «стандартизований міст між проектуванням і реалізацією» доводиться розуміти обережніше.
Точніше визначення виглядає так:
BPMN здатний зберегти спільний формальний шар поведінки процесу між бізнес-моделлю та технічною реалізацією.
Це дуже серйозна цінність. Але це не означає:
уся бізнес-семантика аналітичної моделі безшовно стає семантикою виконання.
Технічна вставка
Сам стандарт окремо розрізняє відповідність вимогам моделювання процесу та відповідність вимогам виконання процесу. Реалізація, що відповідає одному типу, не зобов’язана відповідати іншому.
У BPMN існують і додаткові підкласи відповідності моделей, але для нашого аргументу вони не потрібні. Суттєвий сам факт: моделювання та виконання нормативно розділені вже на рівні Conformance.
16. «Єдина мова» — теж не зовсім єдина
Залишається ще одна популярна теза:
BPMN створює єдину мову бізнесу.
У певному сенсі — так. Він стандартизує графічні елементи та їх базову семантику.
Але стандартизація мови не означає стандартизацію моделювання.
BPMN не дає єдиної відповіді, де провести межу процесу, яку обрати деталізацію, де використовувати Task, а де Sub-Process, які винятки показати і як декомпозувати одну й ту саму діяльність.
Тому два кваліфіковані аналітики можуть побудувати суттєво різні BPMN-моделі одного процесу — і обидві будуть коректними.
Freund і Rücker прямо вказують, що одна й та сама ситуація може моделюватися в BPMN різними способами і що це ускладнює стандартизацію моделей та взаєморозуміння. Саме тому вони рекомендують організаціям встановлювати власні угоди про моделювання.
І це не суто теоретична рекомендація. В описаному ними корпоративному впровадженні BPMN компанія окремо визначала власні modelling conventions і відповідну підмножину BPMN, а моделі потім перевірялися на дотримання цих правил.
Звідси:
BPMN стандартизує мову, але не забезпечує одноманітності мовлення цією мовою.
Без угод про моделювання досить швидко з’являються діалекти.
17. А потім з’являються шамани, месії, конкістадори ...
Сам по собі діалект ще не проблема. Можна використовувати обмежений набір BPMN, встановити корпоративні правила застосування елементів і дотримуватися єдиного стилю.
Проблема починається тоді, коли змінюється значення самих елементів стандарту.
Sequence Flow стає «будь-яким зв’язком».
Pool — напрямком бізнесу.
Task — функцією підприємства.
Message Flow — передачею документів, сировини, автомобілів і взагалі всього, що автору необхідно в цей момент передати.
Data Object — універсальним об’єктом предметної області.
А потім автор цієї конструкції урочисто повідомляє:
«Ось бачите: BPMN — універсальна мова опису бізнес-процесів компанії».
Звичайно. Якщо дозволити кожному символу означати все що завгодно, універсальною мовою можна зробити навіть набір дорожніх знаків.
Тільки ціна такої універсальності доволі висока:
знищення власної семантики BPMN.
Це вже не альтернативний стиль. Не діалект. І не «розширене використання BPMN».
Це авторська нотація, зовні схожа на BPMN.
Замість висновку
У BPMN є реальна й велика цінність. Він добре моделює поведінку процесу: порядок виконання, події, умови, розгалуження, синхронізацію та інформаційну взаємодію.
Він справді створює спільний шар між бізнес-аналізом і технічною реалізацією.
Але звідси зовсім не випливає, що BPMN є універсальною мовою бізнесу, повноцінною мовою архітектури процесів компанії, мовою інформаційної архітектури або мовою матеріальних потоків.
І вже тим більше не випливає, що будь-яку зрозумілу бізнесу BPMN-модель можна без зміни семантики перетворити на виконувану.
Тому твердження:
«BPMN 2.0 — універсальна мова опису бізнес-процесів компанії»
краще сприймати не як характеристику BPMN, а як діагностичну ознаку глибини розуміння стандарту її автором.
Робоче визначення виглядає значно скромніше — і саме тому точніше:
BPMN — спеціалізована мова моделювання поведінки бізнес-процесів та суттєвої для цієї поведінки інформаційної взаємодії.
Інші об’єкти бізнесу можуть бути присутні в моделі тією мірою, якою вони необхідні для опису поведінки процесу, але BPMN не призначений для моделювання їхньої власної структури та відносин.
І зовсім коротко:
BPMN моделює не бізнес навколо процесу, а процес усередині бізнесу.
Стосовно фізичного світу висновок ще цікавіший:
Під час виконання фізичний об’єкт не перетворюється на дані. Дані про нього тільки й були всередині моделі.
А головний підсумок нашої історії:
BPMN хороший саме тому, що спеціалізований.
Універсальним він стає лише після знищення власної семантики.