Коли використовувати двигуни робочого процесу?

Я працював у минулому над деякими двигунами робочого процесу як програміст, але ніколи не мав ясності, чому ми в першу чергу обрали двигуни робочого потоку. І як програміст я знаю, що є щонайменше 100 способів зробити що-небудь, коли ви пишете код, але лише кілька способів є найкращими!

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

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

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

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

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

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

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

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

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

3. Збереження правил як даних дозволяє записати інструменти для візуалізації та зміни даних.

4. Збереження правил як даних дозволяє мета-програмування легше - ви можете написати код для аналізу даних і вставити більше деяким складним способом, що було б дуже складно для коду.

Усі ці речі можна зробити безпосередньо з кодом (наприклад - написати C #-аналізатор, щоб знайти всі правила певного типу та генерувати код для додаткових правил, динамічно вставити його у збірку таким чином, що дозволяє вивантажувати збірку, записувати інструменти для Користувачі зможуть це зробити і за допомогою свого візуалізатора та редактора), але це може бути набагато складніше в залежності від вашої мови (програмісти, які використовують Lisp, можуть посилатися на пункти 1-4 як "програмування").

ІМХО ТОЛЬКИ випадок, коли ви повинні використовувати подібні речі, це коли він може бути налаштований менш цінними користувачами. Якщо ви можете вирішити свою проблему, надавши їм інструмент, то поверніться до роботи над чимось більш важливим, тоді скористайтеся одним.

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

Це виглядає як давнє питання, але в дикій природі багато разів виникає. Я згоден з відповіддю Йона . Я виявив, що двигуни робочого процесу є високопродуктивними у наступних сценаріях:

1. Існує базовий бізнес-процес, який ви намагаєтеся представляти / впроваджувати за допомогою свого програмного забезпечення.
2. Існує єдиний (може бути складений) суб'єкт господарювання, над яким працюють всі або деякі етапи процесу. У прикладі, який Джон дав, ця сутність або елемент робочого процесу буде вмістом або статтею. Розгляньте відстеження помилок як інший приклад робочого процесу, переходу помилок між різними станами на основі дії, яку виконує користувач.
3. Використовуйте Workflows для моделювання своїх процесів, лише якщо ви очікуєте, що бізнес-процес зміниться, під зміною я маю на увазі послідовність або дії, виконані в результаті дії користувача або переходу.

Будьте дуже уважні та критичні, щоб побачити, чи є у вашої проблемної області / вимог бізнес-процес, не намагайтеся "вписати" її в робочий процес.

У мене є кілька рекомендацій, які я використовую для пропонування двигунів робочого потоку.

1) Коли бізнес-аналітики не мають кодування фону, але можуть малювати схеми.

Сучасні двигуни робочого потоку використовують позначення моделювання бізнес-процесів або менш спроможні версії, наявні в SharePoint та подібних системах. Вони дозволяють членам колективу технічно грамотним, але кодируючим завданням проектування та розробку багатьох робочих потоків.

2) Коли потрібно стежити за ходом роботи, виконайте ескалації, переверніть назад і вперед між процесами, керованими комп'ютером, і процесами, керованими людиною.

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

З точки зору HR-бізнесу, двигуни робочого потоку дуже важливі.

1. Вони забезпечують структурований процес, навіть якщо він щоразу однаковий.

2. Вони забезпечують прозорість

   • Хто запросив зміни,
   • Коли це просили,
   • Хто затвердив і т.д.

   Ця прозорість допомагає керувати процесом та сприяє власності.

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

Від імені HR: Живий робочий процес !!!