Quando utilizzare i motori del flusso di lavoro?

Un motore di workflow è utile quando devi andare dall'inizio alla fine, ma ci sono molti percorsi / regole / regole per arrivarci.

Ad esempio, diciamo che scrivo un programma che pubblica contenuti. Quindi, nel mio caso, la pubblicazione passa attraverso un processo di revisione, legale e quindi l'approvazione finale. Scrivo il programma implementando la mia logica di processo e i passaggi. Ora questo funziona benissimo per me e la mia compagnia. Quindi, decido che gli altri dovrebbero usare il mio programma.

Purtroppo, non tutti pubblicano contenuti utilizzando lo stesso processo, quindi anziché scrivere processi separati per ogni caso diverso, implementeremo un processo di flusso di lavoro in modo che il programma sia flessibile per soddisfare tutti. Indipendentemente dal numero di passaggi o regole o logica tra questi due punti, il risultato è lo stesso.

Quindi, se i processi sono variabili dall'inizio alla fine, utilizzare un flusso di lavoro. Se lo stesso processo può essere utilizzato da tutti, non è necessario un flusso di lavoro.

So che hai chiesto casi d'uso, ma è più facile elencare i vantaggi che immaginare tutti i possibili casi d'uso. Naturalmente i vantaggi dipendono dal motore e dalla lingua che si sta confrontando, ma in generale:

1. Mantenere le regole come dati anziché codice significa che non è necessario ricompilare, in modo da poter testare le modifiche rapidamente, cambiare in fase di esecuzione, ecc. Non è un vantaggio se non si deve ricompilare il primo posto, però.

2. Gli utenti possono ragionevolmente aspettarsi di modificare le regole. Possono potenzialmente armeggiare con loro in modo interattivo in modi che non sono fattibili avendo un codice di scrittura del programmatore per loro.

3. Mantenere le regole come dati consente di scrivere strumenti per visualizzare e modificare i dati.

4. Mantenere le regole in quanto i dati consentono più facilmente la meta-programmazione: puoi scrivere codice per analizzare i dati e inserirne altri in un modo complesso, il che sarebbe molto difficile per il codice.

Tutto ciò che è possibile fare direttamente con il codice (ad es. scrivere un parser C # per trovare tutte le regole di un certo tipo e generare codice per più regole, inserendolo dinamicamente in un assembly in un modo che consenta lo scaricamento degli assiemi, scrivere strumenti per gli utenti per poterlo fare anche usando il visualizzatore e l'editor) ma potrebbe essere molto più difficile a seconda della lingua (i programmatori che usano un Lisp potrebbero riferirsi agli articoli 1-4 come "programmazione" ).

IMHO, l'UNICO caso in cui dovresti usare questo genere di cose è quando può essere configurato da utenti meno preziosi. Se riesci a risolvere il tuo problema dando loro uno strumento, torna a lavorare su qualcos'altro di più importante, quindi usane uno.

Se devi ancora configurarlo per loro, immagino che potresti pensare a 10 modi diversi di ottenere lo stesso risultato con uno strumento che conosci e sarà molto più facile da supportare e personalizzare.

Sembra una vecchia domanda, ma emerge numerose volte in natura. Sono d'accordo con la risposta di Jon . Ho trovato che i motori del flusso di lavoro sono altamente produttivi nei seguenti scenari:

1. Esiste un processo aziendale sottostante che stai tentando di rappresentare / implementare tramite il tuo software.
2. Esiste un'unica entità aziendale (forse composita) su cui sono state elaborate tutte o alcune fasi del processo. Nell'esempio che Jon ha dato, questa entità o elemento del flusso di lavoro sarebbe contenuto o un articolo. Prendi in considerazione il bug tracking come un altro esempio di un flusso di lavoro, una transizione Bug tra vari stati, basata su un'azione che un utente prende.
3. Utilizza i flussi di lavoro per modellare i tuoi processi, solo se prevedi che il processo aziendale cambi, per modifica intendo la sequenza o l'azione eseguita come risultato di un'azione o transizione dell'utente.

Sii molto attento e fondamentale per vedere se il tuo dominio / i requisiti del problema hanno un processo aziendale, non provare a "adattarlo" a un flusso di lavoro.

Ho un paio di linee guida che uso per suggerire i motori del flusso di lavoro.

1) Quando gli analisti di business non hanno background di codifica, ma possono disegnare diagrammi.

I moderni motori di flusso di lavoro utilizzano la notazione per la modellazione dei processi di business o le versioni meno efficienti disponibili in SharePoint e sistemi simili. Ciò consente ai membri del team tecnicamente competenti e con problemi di codifica di progettare e sviluppare molti flussi di lavoro.

2) Quando è necessario monitorare lo stato di avanzamento del lavoro, eseguire escalation, spostarsi avanti e indietro tra processi controllati dal computer e processi controllati dall'uomo.

Il monitoraggio e l'auto-riferimento sono le caratteristiche dei moderni motori di flusso di lavoro.

Dal punto di vista delle risorse umane, i motori di flusso di lavoro sono molto importanti.

1. Forniscono un processo strutturato, anche se è sempre lo stesso.

2. Forniscono trasparenza

   • Chi ha richiesto la modifica,
   • Quando è stato richiesto,
   • Chi ha approvato ecc.

   Questa trasparenza aiuta a guidare il processo e promuove la proprietà.

Supponendo che i moduli siano integrati e intelligenti, supportando la logica di business, hanno anche un effetto drammatico sulla timeline, l'efficienza di elaborazione e la qualità dei dati. La sicurezza è anche una considerazione e contenere informazioni sensibili in un sistema sicuro è preferibile avere moduli cartacei in attesa di essere firmati. È anche molto più mobile. Dopo una recente implementazione, un manager mi ha detto che gli ha risparmiato un sacco di fastidi facendogli scrivere cose per la firma mentre viaggiava molto.

A nome delle risorse umane: lunga vita al flusso di lavoro !!!