Бізнес-вимоги є високоефективним інструментом, що здатний оптимізувати рутинні процеси, збільшити клієнтську конверсію, опрацьовувати масиви індивідуальної унікальної інформації і надати клієнту ресурсну перевагу (заощадити на кількості витрачених людино-годин на розробку і прототипізацію програмного продукту).
Детальніше про це можна прочитати у матеріалі блогу “Який ефективний спосіб виявити вимоги в ІТ проєктах”.
Як було зазначено, ефективність виявлення вимог залежить від комунікаціїї між усіма учасниками, тому важливим є вибір ефективної мови щодо цього. Останнім часом популярним варіантом для комунікування команд розробників та стейкхолдерів стає нотація BPMN, де найбільшою перевагою її використання є те, що нею легко ділитися, вона має певний граничний набір піктограм та більшість інструментів моделювання широко підтримують BPMN. Важливо додати, що використання BPMN також доповнює вимоги у вигляді UML діаграм (активності, варіантів використання або діаграм послідовності) та надає нових можливостей, наприклад створення загальних алгоритмів роботи у вигляді потоків.
Традиційне використання BPMN відомо завдяки підходу управління бізнес-процесами (BPM), але ії використання під час розробки програмного забезпечення залежить від того, наскільки добре продумані усі бізнес-процеси від початку до кінця, але у крупних проектах це врахувати практично неможливо. Тому у таких випадках традиційне управління (BPM) не допоможе та потрібен гнучкий підхід. Ми говоримо про те, що гнучкий BPM (agile) – це методологія бізнес-процесів, яка дозволяє бізнесу автоматизувати відомі етапи повсякденних операцій, залишаючи простір для вирішення так би мовити неформатних задач або врахування незапланованих чинників.
Керівникам проєктів потрібно аналізувати BPM з точки зору входів, процесів і виходів. Вхідні дані є змінними — вони можуть включати запити, яких ви не очікуєте, моделі даних, які змінюються, тощо. Гнучкий BPM дозволяє вводити нові позапланові вхідні дані, і надає структуру для їх обробки. Це знову ж таки і зручно, і ефективно: не потрібно вибудовувати окремий алгоритм, який би це враховував.
Така гнучкість надає замовникам швидко аналізувати, розуміти та вносити необхідні коригування у робочий процес. Задля цього платформи на основі BPMN пропонують ефективні рішення, які є розумною альтернативою і компромісом між готовим програмним кодом та високою вартістю розробки спеціальних програм з нуля. Окремо слід зазначити можливості швидкої розробці індивідуальних бізнес-застосунків і надання можливості тим, хто працює з ними, теж стати розробниками.
Як працює agile BPM?
Agile BPM працює як основа для ваших процесів. Він пропонує конкретні методи, які компанії можуть використовувати для управління своїми бізнес-процесами. Цей метод — це щось на зразок дошки або таблиці канбану (візуалізувати усі процеси), які можна використовувати для реалізації принципів agile BPM.
Щоб гнучкий BPM працював, члени команди повинні мати можливість працювати з неструктурованими або спеціальними робочими запитами, дотримуючись або сталого робочого процесу або змінюючи його на ходу.
Дві причинно-наслідкові моделі є основою того, чому потрібен agile BPM, і пояснюють, як він працює:
- Причинно-наслідкова модель експлуатації (IT operations)
Причина: стандартні (рутинні) процедури, як-от пакетні вивантаження даних або переконфігурування. Завдяки постійним змінам у системах, ці процедури насправді не є рутинними, оскільки для завершення процесу часто потрібно більше знань, ніж те, що зазначено в документації.
Ефект: Agile BPM дозволить адаптувати процес виконання процедур, щоб ви могли включити додаткові знання, необхідні задля успішного виконання.
- Причинно-наслідкова модель розвитку (application delivery management)
Причина: процес розробки програмного забезпечення вимагає набагато більшої співпраці, ніж зазначено процесами проєктного офісу. Можливо, доведеться розділити одне завдання на кілька етапів, щоб більше людей могли одночасно внести свій внесок у реалізацію проєкту.
Ефект: Agile BPM дозволить кільком командам одночасно працювати над проєктом, дозволяючи менеджерам проєкту розбивати одне завдання на менші частини, щоб вони могли виконати його швидше, ніж очікувалося.
Чи не було б простіше сісти й наполегливо працювати над складанням повного списку необхідних задач та їх залежностей, щоб не порушити традиційний процес? Це можна спробувати зробити, але, як показує досвід, здійснити це в реальності набагато складніше, ніж у теорії. Зрештою, можна витратити багато часу та зусиль на планування всіх непередбачених ситуацій, про які думали, і все одно щось упустити.
Якщо це відбувається у більшому масштабі, тут взагалі легко втратити контроль над усіма етапами проєкту. Уявіть, що виробник телеком-обладнання працював у бізнес-сфері надання послуг голосового зв’язку, але прийняв рішення розширити свою діяльність щодо надання послуг телебачення. Імовірність натрапити на неузгодженість процесів надання різнорідних послуг у розрізі окремих автономних процесів набагато вища, ніж коли розширюєш процес, який вже налагоджений та працює безперебійно. Зростання бізнесу часто є каталізатором для впровадження гнучкого BPM.
Як організація може застосувати agile BPM?
Якщо ви хочете запровадити гнучкий BPM у своїй організації, вам доведеться у процесі розробки враховувати наступні нюанси:
- Здатність членів команди змінювати речі на ходу. Ви повинні мати можливість змінювати невеликі частини процесу, як-от призначення нового члена команди або дробити завдання на менші частини.
- Менталітет спритності. Ваша команда має розуміти той факт, що процеси можуть змінюватися — і що вони мають право їх змінити.
- Точний процес оцінки. Якщо ваші процеси змінюються, ви повинні мати можливість оцінити, чи ця зміна мала якісний результат.
Як нотація BPMN та управління вимогами виглядає у робочій схемі?
Простими словами, процес управління вимогами із використанням BPMN виглядає так.
- Процес управління вимогами починається з виявлення та визначення проблеми чи можливості (актуалізація бачення клієнта), того, що саме має вирішити майбутнє програмне забезпечення.
- Потім – збір вимог від зацікавлених сторін (до яких належать користувачі, клієнти та інші учасники), на яких впливатиме система. Далі ці вимоги аналізуються, документуються та впорядковуються, а будь-які невідповідності чи двозначності усуваються. Зазвичай цей етап супроводжується артефактами Stakeholders Request (STRQ), які мають простежуватись у артефактах User story (US)
- Передостаннім кроком у процесі управління вимогами є дизайн, який містить BPMN візуалізацію впорядкованих вимог, щоб переконатися, що вони повні, послідовні та такі, які можливо реалізувати на практиці. Цей етап має супроводжуватися артефактами реалістична модель графічного інтерфейсу (mockup або GUI), яка має бути узгоджена із робочим потоком процесу (BPMN Workflow)
- Завершується процес верифікацією або створенням прототипу (PoC) із використанням low-code задля ефективного використання ресурсів розробників та перевірки життєздатності прототипу серед вузького кола доброзичливих користувачів (friendly users).
Щоб зрозуміти це більш детально, звернемо увагу на візуалізацію процесу управління вимогами із використанням BPMN від авторів дослідження «An Approach of Software Requirements Elicitation Based on the Model and Notation Business Process (BPMN)»:
1) Визначення проблеми: діяльність бізнес-аналітиків, спрямована на розуміння задачі на високому рівні (широкий контекст без деталей). Розмежування сфери застосування, спрямоване на узгодження із залученими опціями.
2) Макровизначення залученого: у цій діяльності бізнес-аналітикам важливо визначити, окрім основних зацікавлених сторін, і одного або декількох власників процесу. Ці особи несуть відповідальність за забезпечення узгодженості стратегій організації, а також мають надавати готові алгоритми як відповіді на можливі сумніви.
3) Моделювання BPMN: тут моделювання процесу є складним і вимагає зусиль та відданості тих фахівців, які беруть у участь в розробці, оскільки це графічна схема-представлення реальності. Це моделювання “зверху-вниз” починається з макропроцесів для визначення організаційних стратегій. Після уточнення бізнес-аналітиками ідентифікуються процедури корпоратизації, і лише після цього можна приступати до відображення дій, у якому призначаються ролі та визначається ступінь відповідальність за правильне виконання кожного виду діяльності (окремого робочого потоку BPMN Workflow).
3.1) Опис діяльності: полягає в створенні загального сценарію робочого потоку щодо кожної ручної або автоматизованої активності, яка має виконується в процесі, зокрема, включаючи такі компоненти як: причина або старт потоку, суб’єкти або активні елементи потоку (операції, дії, тощо), правила або умови керування напрямком потоку (перевірки, пречекі, варіативні відповіді, тощо), об’єкти або пасивні елементи потоку (дані, моделі, тощо), засоби вимірювання або обробка помилок, результати потоку (успішний та неуспішний) та розклад роботи потоку (сінхрон, асінхрон, на підставі подій, ручний, тощо).
3.2) Визначення залученого: полягає в ідентифікації всіх шагів, залучених у потік (отримання даних, створення запису база даних, api-виклик, обробка повідомлень, тощо). Ця ідентифікація має визначити всіх осіб, які так чи інакше впливають на розробку та архітектурні рішення потоку або залежать від результатів його роботи.
3.3) Ідентифікація міжпроцесної взаємодії: діяльність, спрямована на визначення існування інших систем або навіть інших процесів, які потребують або не потребують відображення. Ця ідентифікація має визначити всіх осіб, які так чи інакше впливають на інтеграційні рішення, а тих що впливають на потік (provider або південні інтерфейси) або залежать від нього (consumer або північні інтерфейси).
4) Опис функцій: полягає у визначенні алгоритмів, функціональних і нефункціональних вимог щодо кожного визначеного шагу потоку (вхідні та вихідні дані, алгоритми, тощо) для задоволення потреб розробників змодельованого потоку (Workflow BPMN).
Важливо зазначити, що запропонований підхід надає на виході готовий набір даних у вигляді файлу у стандарті BPMN 2.0, який можливо використати для написання програмного коду (наприклад автоматизації у платформі Camunda) або навіть автоматичного створення програмного забезпечення за рахунок використання low-code технологій, (наприклад створення високопродуктивних аплікації у платформі MEF.DEV).