Quand utiliser les moteurs de flux de travail?

J'ai déjà travaillé sur certains moteurs de workflow en tant que programmeur, mais je n'ai jamais compris pourquoi nous avions choisi les moteurs de workflow en premier lieu. Et en tant que programmeur, je sais qu’il existe au moins 100 façons de faire quoi que ce soit lorsque vous écrivez du code, mais seules quelques-unes des méthodes sont les meilleures!

Je ne comprends toujours pas quels cas d'utilisation sont mieux résolus par les moteurs de flux de travail (ou plutôt par leur concept) que par la conception d'une bonne application activée par DI. Je recherche les caractéristiques générales des cas d'utilisation neutres, dans lesquels les moteurs de flux de travail sont l'une des meilleures options.

Ma question est donc la suivante: quelles sont les caractéristiques générales d’une exigence qui peut être considérée comme un signal permettant d’opter pour un bon moteur de workflow et d’en coder les effets?

Un moteur de flux de travail est utile lorsque vous devez aller d'un début à une autre, mais qu'il existe de nombreux chemins / logique / règles pour y parvenir.

Par exemple, disons que j'écris un programme qui publie du contenu. Donc, dans mon cas, la publication passe par un processus de révision, juridique, puis une approbation finale. J'écris le programme en mettant en œuvre ma logique de processus et mes étapes. Maintenant, ce travail est formidable pour moi et mon entreprise. Alors, je décide que les autres devraient utiliser mon programme.

Malheureusement, tout le monde n'édite pas le contenu en utilisant le même processus. Par conséquent, au lieu d'écrire des processus distincts pour chaque cas, nous implémentions un processus de flux de travail afin que le programme soit flexible pour accueillir tout le monde. Quel que soit le nombre d'étapes, de règles ou de logique entre ces deux points, le résultat est le même.

Par conséquent, si vous avez des processus qui sont variables du début à la fin, utilisez un flux de travail. Si le même processus peut être utilisé par tout le monde, vous n'avez pas besoin d'un flux de travail.

Je sais que vous avez demandé des cas d'utilisation, mais il est plus facile de lister les avantages que d'imaginer tous les cas d'utilisation possibles. Les avantages dépendent bien sûr du moteur et de la langue que vous comparez, mais en général:

1. Conserver les règles sous forme de données plutôt que de code signifie que vous ne devez pas recompiler. Vous pouvez donc tester rapidement les modifications, au moment de l'exécution, etc. Ce n'est pas un avantage si vous ne devez pas recompiler au départ.

2. Les utilisateurs peuvent plus raisonnablement s'attendre à modifier les règles. Ils peuvent potentiellement bricoler avec eux de manière interactive d'une manière qui n'est pas réalisable quand un programmeur écrit du code pour eux.

3. Conserver les règles sous forme de données permet d'écrire des outils pour visualiser et modifier les données.

4. Conserver les règles en tant que données facilite la méta-programmation - vous pouvez écrire du code pour analyser les données et en insérer davantage de manière complexe, ce qui serait très difficile pour le code.

Toutes ces choses sont possibles directement avec du code (par exemple, écrivez un analyseur C # pour trouver toutes les règles d’un certain type et générer du code pour plus de règles, insérez-le dynamiquement dans un assemblage de manière à permettre son déchargement, écrivez des outils pour les utilisateurs peuvent également le faire à l’aide de votre visualiseur et de votre éditeur), mais cela peut être beaucoup plus difficile en fonction de votre langue (les programmeurs utilisant un Lisp peuvent se référer aux éléments 1 à 4 comme "programmation").

IMHO le seul cas où vous devriez utiliser ce genre de chose est quand il peut être configuré par des utilisateurs moins précieux. Si vous pouvez résoudre votre problème en leur donnant un outil, utilisez-le à nouveau.

Si vous avez encore besoin de le configurer pour eux, alors j'imagine que vous pourriez penser à 10 façons différentes d'obtenir le même résultat avec un outil que vous connaissez bien et il sera beaucoup plus facile à prendre en charge et à personnaliser.

Cela ressemble à une vieille question, mais fait surface à de nombreuses reprises dans la nature. Je suis d'accord avec la réponse de Jon . J'ai constaté que les moteurs de flux de travail étaient très productifs dans les scénarios suivants:

1. Il existe un processus métier sous-jacent que vous essayez de représenter / mettre en œuvre via votre logiciel.
2. Il existe une seule entité commerciale (peut-être composite) sur laquelle sont travaillées toutes ou certaines des étapes du processus. Dans l'exemple donné par Jon, cette entité ou cet élément de flux de travail serait un contenu, ou un article. Considérez le suivi des bogues comme un autre exemple de flux de travail, un bogue faisant la transition entre différents états, en fonction d'une action entreprise par l'utilisateur.
3. Utilisez les flux de travail pour modéliser vos processus, uniquement si vous prévoyez que le processus technique change. Par modification, j'entends la séquence ou l'action effectuée à la suite d'une action ou d'une transition de l'utilisateur.

Soyez très prudent et critique pour voir si votre domaine / exigences pose un processus d’entreprise, n’essayez pas de le "faire correspondre" à un flux de travail.

J'ai quelques directives à suivre pour suggérer des moteurs de flux de travail.

1) Lorsque les analystes métier n’ont pas de formation en programmation mais peuvent dessiner des diagrammes.

Les moteurs de flux de travail modernes utilisent la notation de modélisation des processus métier, ou les versions moins performantes disponibles dans SharePoint et des systèmes similaires. Celles-ci permettent à l’équipe de concevoir et de développer de nombreux flux de travail avec l’aide de techniciens techniquement compétents et pourtant difficiles à coder.

2) Lorsque vous devez surveiller l'avancement des travaux, effectuez des escalades, basculez entre les processus contrôlés par ordinateur et les processus contrôlés par l'homme.

La surveillance et l'auto-référence sont les caractéristiques des moteurs de flux de travail modernes.

Du point de vue des ressources humaines, les moteurs de flux de travail sont très importants.

1. Ils fournissent un processus structuré, même s'il est identique à chaque fois.

2. Ils fournissent la transparence

   • Qui a demandé le changement,
   • Quand a-t-il été demandé,
   • Qui a approuvé etc.

   Cette transparence aide à orienter le processus et favorise la propriété.

En supposant que les formulaires soient intégrés et intelligents et prennent en charge la logique métier, cela a également un effet considérable sur la chronologie, l'efficacité du traitement et la qualité des données. La sécurité est également un élément à prendre en compte et contenir des informations sensibles dans un système sécurisé est de loin préférable à la présence de formulaires papier en attente de signature. C'est aussi beaucoup plus mobile. Après une récente mise en œuvre, un responsable m'a dit que cela lui évitait beaucoup de problèmes liés à la publication de messages, car il voyageait beaucoup.

Au nom des ressources humaines: Longue vie au workflow !!!