Бізнес-аналітики в ІТ діляться на дві групи:
- ті, хто знає моделювання, і в їхній реальності жоден документ не пишеться без діаграми
- ті, хто розібрався, наприклад, із BPMN (Business Process Model and Notation — мова моделювання бізнес-процесів) тільки для того, щоб додати цей інструмент у резюме і ніколи більше про нього не згадувати
Проте щойно ви почнете малювати, одразу побачите, наскільки це легший спосіб описувати процеси.
«Найбільша проблема тут — подолати вхід у нотації, — впевнена Ірина Крючкова, яка моделює та автоматизує бізнес-процеси понад 16 років. — Є страх зробити щось неправильно або просто не хочеться вивчати 500 сторінок стандарту BPMN, що написаний сухою мовою».
У колонці для Laba експертка спрощує життя початківцям та розповідає про поширені помилки у використанні BPMN. Текст буде корисним для бізнес-аналітиків в ІТ, процесних аналітиків, операційних менеджерів та власників бізнесів, які хочуть проаналізувати або оптимізувати процеси, не ставши при цьому на типові граблі.
#1. Пропустити підготовчий етап
Щоб зрозуміти, як має бути, ми маємо спершу розібратися, що саме зараз не так. І аналіз того, як є (as is), і моделювання того, як має бути (to be), — складають дві окремі, хоч і пов’язані, структурні частини.
Якщо замовник не знайомий з особливостями процесу, він може легко спокуситися на те, щоби пропустити першу фазу аналізу. Мовляв, ми ж і так знаємо, як є зараз і що зараз — недобре; давайте одразу перейдемо туди, де покращення.
Йдучи на цей компроміс, ви, звісно, зможете змоделювати процеси. Але ризикуєте тим, що ваші діаграми не збігатимуться з реальністю і не працюватимуть. У такому сценарії у вас будуть прописані всі відповідальності, очікування та етапи. Але на практиці виявиться, що люди не мають ресурсів, достатньої інформації для виконання своїх кроків або ще не зроблені певні проміжні чи суміжні кроки.
Процеси не мають бути ідеальними, але мають бути робочими. Саме для того, щоб знайти найреалістичнішу модель, ми й проводимо попереднє дослідження: аналізуємо, як є зараз, шукаємо вузькі місця, а потім вирішуємо, як покроково їх виправляти.
Ще одна небезпека, яку спричиняє пропуск підготовчого етапу, — це сповільнення двох наступних. Структурно процес моделювання процесів можна умовно поділити на три частини. Уявімо, що вони рівні: 33,33 % часу ми присвячуємо аналізу as is, 33,33 % — моделюванню to be, і ще 33,33 % — імплементації.
Просте викидання етапу аналізу as is не зробить весь проєкт на 33,33% коротшим. Скоріше за все, в результаті ваш етап to be розтягнеться, адже не знаючи, як є зараз, неможливо зрозуміти, як має бути. Своєю чергою, імплементація стане довшою. Бо не поговоривши з зацікавленими особами процес, не почувши їхні проблеми на старті, ми зустрінемо нерозуміння і спротив на етапі впровадження нових способів роботи.
Пояснювати, чому все має працювати по-новому, а не так, як усі звикли, і переконувати, що новий формат кращий за попередній, — це час та зусилля, яких можна буде не докладати, якщо якісно провести підготовчу роботу.
#2. Недостатньо комунікувати зі стейкхолдерами на всіх етапах
Мій теперішній досвід роботи пов’язаний з ІТ-компаніями, в яких процеси зазвичай покращують не лише для того, щоб бізнес працював ефективніше, а й для того, щоби працівникам було комфортно. Але раніше, коли я працювала з державними інституціями або заводами-виробниками, до цих питань ставилися більш директивно. Там керівник вирішує, як виглядатиме процес, виконавців ставлять перед фактом — і всі працюють.
Можливо, в таких організаціях це й не вважатимуть проблемою, оскільки не надто дбають про працівників, але за директивного підходу про мотивацію впроваджувати зміни не буде й мови. Люди виконуватимуть нові процеси, але, стикнувшись із помилкою або невизначеністю, не намагатимуться розв’язати їх самостійно. Натомість буде настрій: «Ці ваші процеси — дурні, нічого не працює, нічого не буду робити». На поверхні буде все запроваджено і нібито працюватиме, але на практиці ви зіткнетеся з саботажем і незадоволеністю.
Щоб цього уникнути, не варто делегувати моделювання виключно на бізнес-аналітика. Залучайте всі зацікавлені сторони й на всіх етапах. В ідеальному сценарії ми маємо співпрацювати з наступними ролями:
- Власник процесу — топменеджер, який має запит щодо оптимізації або автоматизації. Максимально залучений на початку — під час формулювання задачі, і в кінці — на етапі затвердження нового підходу.
- Менеджер процесу — керівник підрозділу або відділу. Людина, яка знає, як відбувається процес, і відповідає за його виконання щоденно.
- Учасники процесу — ті, хто його виконує. З ними комунікуємо найбільше на всіх етапах.
- Бізнес-аналітик — який збирає та структурує інформацію від інших учасників.
Коли ми змінюємо внутрішні процеси у гнучкій, сучасній та демократичній корпоративній культурі, найкраще буде сформулювати запит до виконавців у такий спосіб: «Від керівництва є побажання зробити процес простішим/дешевшим/швидшим. Давайте подумаємо, як це можна зробити, і разом із цим розв’яжемо й ваші виклики чи проблеми». Так усі учасники розумітимуть, навіщо впроваджуються зміни, і будуть мотивовані як пропонувати свої варіанти покращень, так і виконувати їх.
Окремо варто проговорити ситуацію зі зміною процесів у командах ІТ-розробки. Часто аналітики в ІТ залучені також до зміни процесів колаборації між технічною командою та бізнесом (клієнтом). Для таких ситуацій актуальні ті самі правила — залучати зацікавлені сторони на всіх етапах.
Припустімо, ми залучили всіх потрібних людей команди, сформулювали чудовий процес, узгодили його всередині та готові впроваджувати. Але якщо ми не врахуємо тут точку зору клієнта, процес, яким би ідеальним він не був, помре — і доволі швидко.
Якщо клієнт не розуміє, навіщо йому приходити на регулярні зустрічі або описувати вимоги, він цього не робитиме. І для ваших внутрішніх процесів це стане суттєвою перепоною. Але можна прийти до клієнта і сказати йому: «Ось у цих точках наша робота зупиняється, бо ми не отримуємо від вас вчасного фідбека або вимог. І це призводить до таких і таких наслідків. Давайте подумаємо, як це можна розв’язати». І тоді клієнт, можливо, сам запропонує приходити на ваші зустрічі регулярно.
Не слід приносити залученим людям процеси «на блюдечку», навіть якщо ви знаєте, як краще. Дайте їм можливість бути авторами змін.
#3. Неправильна деталізація для неправильних людей
У моделюванні є стратегічний та операційний рівні. Бізнес-аналітику слід розуміти, з яким рівнем деталізації він має справу в кожній конкретній ситуації.
Припустімо, у нас є замовник — CHRO (Chief Human Resources Officer). Якщо ми почнемо в деталях говорити з ним про те, як відбувається рекрутинг, описувати всі 25 дрібних кроків, це його заплутає, ускладнить вам зустріч і не дасть досягти згоди. З замовником такого рівня у більшості випадків слід говорити на стратегічному рівні: «Ось три основних етапи: шукаємо кандидатів, проводимо інтерв’ю, готуємо офер. Давайте визначимо, що саме в них ми хочемо покращити».
І навпаки: якщо ми прийдемо до виконавця процесу — рекрутера — і опишемо його роботу в трьох основних блоках, то зустрінемо спротив. Він одразу почне перераховувати свої болі, блокери, вузькі місця. І це справедливо: з його точки зору рекрутинг містить не три кроки, а набагато більше.
Оскільки наша операційна пам’ять здатна утримувати до 10 об’єктів у полі зору, я не рекомендую одразу вести людей у діаграму з 50 елементів, яку б роль вони не обіймали. Ви будете дуже довго обговорювати модель — і взагалі не факт, що всі все зрозуміють однаково.
Починайте зі стратегічного рівня — розкрийте три основних блоки. А потім, покроково і поступово, заглиблюйтеся в деталі за кожним із них. Це дасть змогу і ретельно опрацювати діаграму, і бути з усіма на одній сторінці.
#4. Довільна візуалізація
Одна помилка — не робити візуалізацій взагалі, бо ви не знаєте нотації та боїтеся зробити помилку. Тут є лише один вихід: пробувати. Робіть це так, як вмієте. Навіть не знаючи жодної нотації, ви можете моделювати прості блок-схеми, і це вже буде краще, ніж текст. Просто тому, що послідовні та паралельні зв’язки сприймаються легше, коли вони візуалізовані.
Друга помилка — робити візуалізації у довільному форматі, «щоб нам було зрозуміло». Нотації — це не вигадана мова, якою ми з друзями спілкуємося в дитинстві. Її створили саме для того, щоб її могли розуміти й в Україні, і в США, і зараз, і за 5 років.
Звісно, ви можете придумувати свої правила та використовувати елементи як заманеться. Але тоді все буде зрозуміло, лише допоки ви будете поруч із діаграмою. Коли ви підете з компанії, а ваші моделі залишаться, їх ніхто не зможе прочитати.
Тобто будь-яка діаграма — краща за ніяку, але правильна і загальнозрозуміла — точно краще, ніж створена за довільними правилами. Починайте моделювати, хай і з неправильних, але не зупиняйтеся на цьому, вдосконалюйтеся та рухайтеся в бік правильного використання нотацій.
#5. Презентація результатів без обговорення
Припустімо, ви досконало знаєте нотацію, правильно моделюєте процеси та залучаєте всі зацікавлені сторони. Але якщо ви просто відправляєте свої діаграми стейкхолдерам імейлом, очікуючи, що ваш документ вивчать і дадуть фідбек, — готуйтеся до поразки. Цього не станеться.
Є просте правило, якого мене навчив досвід: якщо ви не ініціюєте обговорення — не отримаєте фідбек. По-перше, тому, що стейкхолдери можуть не знати нотації, якою ви моделюєте. А по-друге, тому, що вони мають багато іншої пріоритетної роботи й не будуть витрачати час на вивчення діаграм.
Тому я раджу бізнес-аналітикам приходити до стейкхолдерів разом із діаграмою. Презентації, обговорення та узгодження важливі як на етапах аналізу (as is), так і на етапах структурування (to be) та зміни процесів. Лише описавши та проговоривши кожен крок, ви будете певні, що всі все зрозуміли однаково. Знову ж таки: це додаткова робота для вас зараз, але вона дозволяє уникнути різночитань та конфліктів у майбутньому.
#6. Некоректне використання елементів BPMN
Ну і помилки безпосередньо в нотації BPMN, які можна зустріти в діаграмах. Наведу кілька, які мені довелося бачити найчастіше.
- Часто новачки не розуміють, що таке подія, навіщо вона в діаграмі, а також плутають подію та активність (або крок). Основна різниця між цими елементами — в тому, що подія стається одномоментно (надійшов лист, завершилося оформлення документа), тоді як активність (крок) позначає дію, що триває певний час (лист пишеться, документи оформлюються). Подія не є активністю, але може тригерити наступні активності або просто відзначати початок або завершення якоїсь фази. Саме так і слід її використовувати — як позначення майлстоуна, віхи чи стадії.
- Крім того, новачки часто некоректно використовують гейтвеї. В них також часто закладають ідею кроку, маючи на увазі, що в гейтвеї щось відбудеться (порахується чи перевіриться). Насправді гейтвей означає буквально те, що ми чуємо, — це ворота, перед якими всі події та рішення вже зроблені. Гейтвей покликаний лише перенаправляти потік тією чи іншою гілкою, базуючись на тих даних, що він отримує на вхід.
- Третя найпоширеніша помилка — неправильне використання потоків контролю та повідомлень. В BPMN потік контролю (суцільна стрілка) рухає один процес від його початку до завершення. Якщо з якогось кроку потік контролю не вийшов, знайте, що тут ваш процес і зупинився.
Потік контролю має бути безперервним від стартової події до завершальної. При цьому в BPMN є ще й потік повідомлень (пунктирна стрілка), який натомість ніяк не рухає процес, а лише відправляє повідомлення від одного процесу до іншого.
Коли ви моделюєте процеси лише для людей, некоректне використання події, гейтвею чи потоків не принесе суттєвих проблем. Якщо ви дослухалися до попередніх рекомендацій, то будете поруч і зможете пояснити, що мали на увазі. Але якщо ви плануєте на основі ваших діаграм автоматизувати роботу в системі BPM (Business Process Management), ваші діаграми працюватимуть неправильно або взагалі не працюватимуть. В неправильних подіях, гейтвеях та з неправильними потоками система застрягатиме — і ваш процес просто не рухатиметься далі.
Бажаєте отримувати дайджест статей?
