Навчальний посібник: Покращуйте потоки бізнес-процесів за допомогою розгалуження

Потоки бізнес-процесів проведуть вас через різні етапи процесів продажу, маркетингу та обслуговування до самого кінця. У простих випадках лінійний потік бізнес-процесу є хорошим варіантом. Тим не менш, у складніших сценаріях за допомогою відгалуження можно поліпшити потік бізнес-процесу. Якщо у вас є дозволи на створення потоків бізнес-процесів, ви зможете створювати потік бізнес-процесу з декількома гілками за допомогою If-Else логіки. Умова розгалуження може бути сформована з безлічі логічних виразів, які використовують комбінацію операторів or AND OR . Вибір відгалуження відбуватиметься автоматично в режимі реального часу на основі правил, визначених під час процесу визначення. Наприклад, при продажу автомобілів можна налаштувати єдиний потік бізнес-процесу, який після загального кваліфікаційного етапу розбивається на дві окремі гілки на основі правила (Чи віддає перевагу клієнт новому автомобілю або автомобілю з пробігом, чи його бюджет вище або нижче $20,000 і так далі. ), одна гілка, для продажу нових автомобілів і інша філія, для продажу автомобілів з пробігом. Щоб дізнатися більше про потоки бізнес-процесів, перегляньте статтю Огляд потоків бізнес-процесів.

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

Що потрібно знати для розробки потоків бізнес-процесу з відгалуженнями

Зверніть увагу на наступну інформацію під час створення потоку бізнес-процесу з відгалуженнями:

• Процес може охоплювати не більше п’яти унікальних таблиць.

• Ви можете використовувати максимум 30 стадій на процес і максимум 30 кроків на стадію.

• Кожна гілка може бути глибиною не більше п’яти рівнів.

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

• Можна об’єднати кілька умов у правилі за допомогою оператора або оператора AND OR , але не обох операторів.

• Визначаючи потік процесу, можна за бажанням вибрати зв’язок між таблицями. Цей зв’язок має бути зв’язком 1:N (One-to-Many).

• Кілька активних процесів можуть виконуватися одночасно в одному рядку даних.

• Ви можете перевпорядкувати плитки (етапи, кроки, умови тощо) у процесі, використовуючи перетягування.

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

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

• Для форм у додатках на основі моделей взаємодія з майбутніми етапами запускає їхні умови та бізнес-правила. Однак, якщо активний етап залишиться незмінним, ці правила не будуть запущені знову під час перезавантаження форми. При завантаженні форми виконуються тільки правила в активній стадії.

Нотатка

• Таблицю, використану в процесі, можна переглядати кілька разів (кілька замкнутих циклів таблиці).

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

  В іншому прикладі, припустимо, що процес зараз знаходиться на стадії «Поточна пропозиція » у вашому потоці процесів: Кваліфікувати потенційного клієнта> Визначте потреби>Створіть пропозицію>Презентація>пропозиції закрийте. Якщо пропозиція, представлена клієнту, потребує додаткових досліджень для виявлення потреб клієнта, користувачі можуть просто вибрати етап «Визначити потреби » вашого процесу та вибрати «Встановити активну».

Приклад: Процес продажу автомобілів з двома гілками

Давайте переглянемо приклад потоку бізнес-процесу з двома відгалуженнями для продажу нових і потриманих автомобілів.

Спочатку ми створимо новий процес під назвою «Процес продажу автомобілів».

1. Відкрийте провідник рішень, а потім на лівій панелі навігації виберіть Процеси.

2. Виберіть Створити , щоб створити новий процес.

3. Вкажіть категорію як потік бізнес-процесу і для основної сутності виберіть Потенційний клієнт .

4. Додайте перший етап до процесу під назвою «Кваліфікація» та додайте кроки : «Часові рамки покупки» та «Уподобання автомобіля».

5. Після загального етапу кваліфікації ми розділили процес на дві окремі гілки за допомогою плитки «Умова ».

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

   2. Щоб додати перше відгалуження для стадії, додайте плитку "Стадія" на шляху "Так" у плиті умови

   3. Щоб додати другу гілку, яка виконується, коли умова не виконується, додайте ще одну плитку «Етап» на шляху «Ні» плитки умови

Порада

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

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

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

Запобігання витоку інформації

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

У цьому сценарії кредитному інспектору банку потрібен доступ до рядка «Запит», але він не повинен мати жодного уявлення про розслідування запиту. На перший погляд здається, що ми можемо легко це зробити, призначивши кредитному інспектору роль безпеки, який вказує на відсутність доступу до таблиці «Розслідування». Але давайте детальніше розглянемо приклад, щоб переконатися, чи справді це так.

Припустимо, що клієнт просить у банку кредит у розмірі понад 60 000 дол. США. Спершу запит переглядає експерт із кредитів. Якщо задовольняється правило відгалуження, яке перевіряє, чи розмір заборгованості в банку перевищує 50 000 дол. США, наступним етапом стане розслідування, чи не є запит шахрайським. Якщо буде встановлено, що це дійсно випадок шахрайства, процес переходить до судового позову проти запитувача. Кредитний інспектор не повинен мати уявлення про два етапи розслідування, оскільки він не має доступу до таблиці розслідувань.

Однак, якщо кредитний фахівець відкриє рядок «Запит», усі зможуть побачити весь наскрізний процес. Кредитний фахівець зможе не тільки побачити етап розслідування шахрайства, але й визначити результат розслідування, побачивши етап судового позову в процесі. Також офіцер зможе попередньо переглянути етапи розслідування, вибравши стадію. Хоча кредитний фахівець не зможе побачити дані або статус виконання кроку, він зможе визначити потенційні дії, які були вжиті проти заявника запиту на етапах розслідування та судових дій.

У цьому процесі експерт із кредитів буде мати можливість бачити розслідування шахрайства і стадії судового позову, що є неналежним розкриттям інформації. Ми рекомендуємо приділяти особливу увагу інформації, яка може бути розкрита з огляду на відгалуження. У нашому прикладі процес розподілено на два окремі процеси – один для обробки запитів і ще один для розслідування шахрайства. Це зроблено з метою запобігання розкриттю інформації. Процес для експерта з кредиту буде виглядати так:

Процес для розслідування буде закритим і передбачатиме такі етапи:

Вам потрібно буде надати робочий процес, щоб синхронізувати рішення «Схвалити/відхилити» з рядка «Розслідування» до рядка «Запит».

Наступні кроки

Створення потік бізнес-процесу
Створюйте кастомну бізнес-логіку за допомогою процесів