Нотація BPMN та управління вимогами тут є чи не єдиним якісним інструментом, який дозволяє координувати діяльність складних механізмів та технічних процесів (цифровий зв’язок, бездротові мережі, надання цифрового контенту, послуги SMS тощо). Ця модель управління, зазвичай, використовується для синхронізації дуже точних у часі і вельми складних у виконанні робочих процесів, зокрема і таких, які потребують одночасного і безперервного використання у кількох підрозділах.
Завдяки цій методиці можна полегшити побудову та постійне вдосконалення інформаційних систем на початковій стадії процесів розробки проєктів. Цей підхід покращує оперативний візуал, фіксує пробіли у знаннях залучених сфер, тим самим допомагає накопичувати і відстежувати фідбек, покращити якість послуг, що надаються, відтак, сприяє зменшенню ризиків, підвищивши задоволеність клієнтів. У випадку авіакомпаній, вокзалів, операторів зв’язку, інтернет-провайдерів etc. рівень задоволення клієнтів їхніми послугами безпосередньо впливає на прибутковість цих установ.
Крім того, шляхом документування як ручних, так і автоматизованих, процесів стає можливим визначити потенційні області для вдосконалення та оптимізувати всю систему в цілому та уникнути отримання негативного фідбеку в майбутньому.
На відміну від традиційних методів виявлення вимог та на думку авторів дослідження «An Approach of Software Requirements Elicitation Based on the Model and Notation Business Process (BPMN)», запропонований підхід з використанням BPMN є оптимальним для управління ними, завдяки наступному:
Як і будь-яка система, нотація BPMN, має свої переваги та недоліки. До вищезгаданих плюсів можна додати ще, що цей метод:
- дозволяє BA-фахівцю, разом з PM та бізнесом, цілісно розглядати стратегічні потреби, полегшуючи ідентифікацію вимог та їх пріоритетність.
- дозволяє зменшити робоче навантаження, пов’язане з обсягом, розумінням і нестабільністю вимог, що автоматизуються.
До основних недоліків можна віднести те, що використання BPMN нотації:
- вимагає значних зусиль для розуміння та розрізнення того, що таке бізнес-потік і що таке системний потік.
- цілі трасування можуть бути вразливими, що змушує створювати додатковий артефакт у документі вимог.
Однак, всі ці недоліки та їхні можливі наслідки легко попередити, якщо звернутися до досвідченого розробника або команди розробників. Тож, можна констатувати, що мінуси від використання BPMN є суто умовними.
Переваги
Основні переваги управління та аналізу вимог до програмного забезпечення за допомогою нотації BPMN включають: зниження ризику невдачі проєкту, поліпшення комунікації між сторонами-учасниками проєкту та розробниками зокрема, виявлення потенційних проблем на ранній стадії процесу розробки, а також створення чіткого та повного набору вимог, які можуть бути і будуть використані для управління розробкою програмного забезпечення.
Проблема гнучких методологій у великих підприємствах полягає в тому, що одна помилка інтеграції може легко призвести до багатьох інших. Спосіб, у який підприємства інтегрують методологію, може зійти з колії, і процес, який має створити перевагу для компаній, стає поміхою на шляху їх успіху.
Ретельний та ефективний аналіз вимог, в тому числі й з урахуванням гнучкого підходу, дозволяє команді покращити комунікацію та взаємодію між усіма членами, якомога точніше узгодити програмний продукт у відповідності до технічного завдання бізнесу, підвищити задоволеність користувачів та поліпшити якість готового програмного продукту.
Нотація BPMN пропонує системні рішення для осучаснення та якісної цифрової трансформація будь-якого бізнесу, надто, коли мова йде про одну з найдинамічніших галузей – сферу зв’язку та телекому, де вчасно застосований технологічний прогрес часто дорівнює конкурентній перевазі на ринку, як по часу, так і в ресурсах. В свою чергу, BPMN Low Code – це компактне і ефективне рішення для задач, які мають обмеження у плані дедлайну та релізу, або коли в одному проєкті на короткі строки об’єднуються різноманітні команди розробників і писати код з нуля не є можливим тощо.
На прикладі виконання проєктів у платформі MEF.DEV, під час створення застосунків із застосуванням BPMN Low Code, програмний цикл проєктів виглядає наступним чином:
Інакше кажучи, із застосуванням нотації BPMN під час управління та аналізу вимог до програмного забезпечення надає можливостей колоборації команд розробників Замовника та постачальника, а саме вони ведуть розробку разом – на рівні low-code Замовник створюєте керування і бізнес-логіку omnichannel, постачальник реалізує backend і супровід, забезпечуючи надійне виконання Ваших ІТ-операцій. Бізнес-аналітики, програмісти і архітектори працюють на результат завдяки бізнес-орієнтованому проектуванню. Автоматизація на на рівні BPMN Low Code забезпечує генерацію коду, та надає можливості тестування і DevOps – Замовник відстежує прогрес, вимірює вузькі місця і керує змінами. Плавне розгортання включає автоматичне документування, управління версіями, обліковими записами, і конфігурацією.
THE RACI MATRIX
Запропонована матриця ефективності проекту RACI (R – Responsible, A – Accountable, C – Consult, I – Inform):
| Діяльність | Команда Замовника | MEF.DEV команда |
| визначає цілі та обсяг змін | R | I |
| досліджує поточні бізнес-процеси, ІТ системи і оточення, щоб визначити потенційний план трансформації, який відповідає бізнес-цілям. | A | R |
| формує вимоги, задає функціональність і характеристики, | R | С |
| зіставляє їх з вимогами безпеки, правилами і технологіями у галузі розробки програмного забезпечення | A | R |
| складає графік проекту, відповідно до потрібних строків і наявного бюджету. | R | С |
| Здійснює частину розробки щодо бізнес-логіки та оркестрації omnichannel на рівні BPMN Low Code | R | С |
| Здійснює частину розробки щодо backend і супровіду, забезпечуючи надійне виконання Ваших ІТ-операцій | A | R |
| самостійно і незалежно від кого-небудь вносите зміни і розвиваєт проєкти | R | С |
| надає навчання та індивідуальну підтримку, щоб нові рішення працювали, мали розвиток і могли вирішувати наступні завдання. | A | R |