Когда использовать рабочие процессы?

В прошлом я работал программистом над некоторыми механизмами рабочих процессов, но никогда не понимал, почему мы выбрали двигатели рабочих процессов в первую очередь. И как программист, я знаю, что есть по крайней мере 100 способов сделать что-нибудь, когда вы пишете код, но только немногие из них являются лучшими!

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

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

Механизм рабочего процесса полезен, когда вам нужно пройти от начала до конца, но есть много разных путей / логики / правил, чтобы добраться туда.

Например, скажем, я пишу программу, которая публикует контент. Так что, в моем случае, публикация проходит процесс рецензирования, юридического, а затем окончательного утверждения. Я пишу программу, реализующую мою логику процесса и шаги. Теперь эта работа отлично подходит для меня и моей компании. Итак, я решил, что другие должны использовать мою программу.

К сожалению, не все публикуют контент, используя один и тот же процесс, поэтому вместо того, чтобы писать отдельные процессы для каждого отдельного случая, мы реализовали бы процесс рабочего процесса, чтобы программа могла приспосабливаться к каждому. Независимо от того, сколько шагов, правил или логики находятся между этими двумя точками, результат один и тот же.

Итак, если у вас есть процессы, которые являются переменными от начала до конца, используйте рабочий процесс. Если один и тот же процесс может использоваться всеми, то вам не нужен рабочий процесс.

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

1. Хранение правил в виде данных вместо кода означает, что вам не нужно перекомпилировать, поэтому вы можете быстро тестировать изменения, вносить изменения во время выполнения и т. Д. Тем не менее, нет особого преимущества, если вам не нужно перекомпилировать в первую очередь.

2. Пользователи могут более разумно ожидать, чтобы редактировать правила. Они могут взаимодействовать с ними в интерактивном режиме таким образом, что это невозможно, когда программист пишет для них код.

3. Сохранение правил в качестве данных позволяет создавать инструменты для визуализации и изменения данных.

4. Хранение правил в качестве данных позволяет более легко метапрограммировать - вы можете написать код для анализа данных и вставить более сложный способ, что будет очень сложно для кода.

Все эти вещи можно делать напрямую с кодом (например, написать синтаксический анализатор C #, чтобы найти все правила определенного типа и сгенерировать код для большего количества правил, динамически вставить его в сборку способом, позволяющим выгрузку сборки, написать инструменты для пользователи могут сделать это также с помощью визуализатора и редактора), но это может быть намного сложнее в зависимости от вашего языка (программисты, использующие Lisp, могут ссылаться на пункты 1-4 как «программирование»).

ИМХО, ЕДИНСТВЕННЫЙ случай, когда вы должны использовать такие вещи, это когда их могут настроить менее ценные пользователи. Если вы можете решить свою проблему, предоставив им инструмент, а затем вернуться к работе над чем-то более важным, используйте его.

Если вам все еще нужно настроить его для них, я думаю, вы могли бы подумать о 10 различных способах получить тот же результат с помощью инструмента, с которым вы знакомы, и его будет намного проще поддерживать и настраивать.

Это похоже на старый вопрос, но всплывает множество раз в дикой природе. Я согласен с ответом Джона . Я обнаружил, что механизмы рабочих процессов являются высокопроизводительными в следующих сценариях:

1. Существует базовый бизнес-процесс, который вы пытаетесь представить / реализовать с помощью своего программного обеспечения.
2. Существует одна (возможно, составная) бизнес-единица, над которой работают на всех или на некоторых этапах процесса. В примере, приведенном Джоном, этот объект или элемент рабочего процесса будет содержимым или статьей. Рассматривайте отслеживание ошибок как еще один пример рабочего процесса - ошибка переходит между различными состояниями на основе действий, предпринимаемых пользователем.
3. Используйте Workflows для моделирования ваших процессов, только если вы ожидаете, что бизнес-процесс изменится. Под изменением я подразумеваю последовательность или действие, выполненное в результате действия или перехода пользователя.

Будьте очень внимательны и критичны, чтобы увидеть, есть ли в вашей проблемной области / требованиях бизнес-процесс, не пытайтесь «вписать» его в рабочий процесс.

У меня есть пара рекомендаций, которые я использую для предложения рабочих процессов.

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

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

2) Когда вам нужно следить за ходом работы, выполнять эскалации, переключаться между компьютеризированными процессами и процессами, контролируемыми человеком.

Мониторинг и самостоятельная привязка являются отличительными чертами современных двигателей рабочих процессов.

С точки зрения HR-бизнеса двигатели рабочего процесса очень важны.

1. Они обеспечивают структурированный процесс, даже если он всегда одинаков.

2. Они обеспечивают прозрачность

   • Кто запросил изменение,
   • Когда это было запрошено,
   • Кто одобрил и т. Д.

   Эта прозрачность помогает вести процесс и способствует собственности.

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

От имени HR: Да здравствует рабочий процесс !!!