Data ultimo aggiornamento: 03/01/2022

Modelli Workflow

Moduli richiesti: Gestione Work Flow
Opzioni programma: vai alle opzioni
Report programma: vai ai report

La schermata home permette di visualizzare la lista dei modelli di processo con le loro informazioni base tra cui lo stato.

Un modello di processo può avere 4 stati:

1. INCOMPLETO: quando siamo ancora in fase di creazione del modello e non sono state inserite ancora tutte le informazioni necessarie al suo utilizzo. Questo stato permette all'utente di creare un modello con calma. Se un modello è in questo stato non può essere utilizzato.
2. COMPLETO/PRONTO: in questo stato il modello di processo è pronto per essere utilizzato, quindi tutte le informazioni necessarie al suo utilizzo sono state inserite correttamente.
3. IN USO: il modello di processo è in uso, in termini tecnici possiamo dire che è stata generata un'istanza del modello.
4. DISMESSO: questo stato è utile quando un modello di processo non è più utilizzato oppure quando si vuole generare una nuova versione. Ricordiamo che se un modello di processo è IN USO la sua struttura non può essere più modificata, quindi per attuare modifiche è necessario crearne uno nuovo duplicandone la struttura e impostando il vecchio modello in uno stato DISMESSO.

Nella schermata Home è possibile effettuare le seguenti operazioni:

• Nuovo (F2): crea un nuovo modello di processo
• Apri (F3): apre il modello di processo selezionato
• Duplica (CTRL+F2): duplica interamente il modello di processo selezionato
• Dopo Salva -> Rimani: flag per determinare se dopo il salvataggio di un modello si ritorna alla schermata home oppure si rimane
• Regole di attivazione: apre la schermata per la gestione delle regole di attivazione
• Export/Import modello: consente l'import/export di un modello da un file XML precedentemente esportato

Processo

Un modello di processo è composto da una testata e un corpo. Il programma è strutturato in due TAB, il primo (PROCESSO) dove sono contenute le informazioni di testata del modello e il secondo (TASK) dove è possibile definire il corpo del modello, ovvero la struttura del flusso di lavoro composto dalle varie attività e dalle connessioni che intercorrono tra essi.

Un modello di processo è composto da una serie di informazioni quali il nome, la descrizione, un flag per indicare se si accettano o meno i task custom (che verranno spiegati nei capitoli successivi), lo stato e le note. Le regole di attivazione del modello vengono gestite da programma a parte descritto nei capitoli seguenti.

Lo stato di un processo può essere settato manualmente con una serie di vincoli riportati di seguito:

• Da INCOMPLETO a COMPLETO: lo stato del modello può essere settato da INCOMPLETO a COMPLETO solo se tutte le informazioni necessarie al suo utilizzo sono state inserite correttamente. I controlli vengono effettuati in fase di salvataggio.
• Da COMPLETO a INCOMPLETO: se il modello è in uno stato COMPLETO può essere settato in uno stato INCOMPLETO nel caso in cui ci si accorga di qualche mancanza.
• Da COMPLETO a IN USO: il modello viene settato da uno stato COMPLETO a uno stato IN USO in automatico dal programma dal momento in cui viene utilizzato. Non è possibile settarlo manualmente.
• Da IN USO a COMPLETO: in termini tecnici se un modello è IN USO vuol dire che è stata generata una sua istanza, ma se vengono eliminate tutte le istanze del modello il suo stato viene settato in automatico dal programma da IN USO a COMPLETO.
• Da IN USO a DISMESSO: se il modello è IN USO, può essere settato in uno stato DISMESSO se non lo si intende più utilizzare o se è stato superato da una nuova versione.
• Da DISMESSO a IN USO: se un modello è stato DISMESSO può essere riattivato settandolo nello stato IN USO.

Task

Ogni modello di processo è composto da una serie di modelli di task, ovvero le attività del flusso di lavoro (workflow). Ogni modello di task appartiene ad un solo modello di processo e non è possibile riutilizzare lo stesso modello di task su modelli di processi diversi. Le informazioni che caratterizzano un modello di task sono state raggruppate in cinque TAB:

• Struttura: dove sono contenuti i dati principali e i dettagli delle connessioni con gli altri task.
• Opzioni: dove sono contenute le opzioni del Task.
• Notifica: dove si definiscono tutti i dettagli relativi alle notifiche in apertura o chiusura del task.
• Gestione: dove si definiscono le procedure di controllo e di update in apertura o in chiusura del task.
• Note: un campo dove poter annotare dettagli estesi sul Task.

Alla destra del TAB è posizionato l'editor grafico per visualizzare la struttura del modello di processo ed interagire graficamente per la creazione di nuovi task e per la gestione delle connessioni.

Struttura

All'interno del modello un TASK è identificato da un ID e caratterizzato principalmente da un numero, un nome, una descrizione e una tipologia.

Ogni modello deve avere un flusso che parte da un TASK di apertura e si conclude in un task di chiusura. Questo viene verificato ogni volta prima del salvataggio e si controlla che ogni possibile flusso di lavoro porti ad un TASK di chiusura.

Le tipologie di TASK vengono identificate nell'editor grafico grazie l'utilizzo di colori distinti. Le tipologie disponibili sono le seguenti:

• Apertura (Verde): è il primo TASK del processo ad essere creato (non ha un padre). Un modello può avere un solo task di apertura.
• Apertura/Decisionale (Verde/Giallo): definisce un TASK che oltre ad essere di apertura è anche decisionale.
• Decisionale (Giallo): è un TASK che pone una domanda ed implica una sola scelta tra le possibili risposte.
• Standard (Azzurro): definisce un TASK standard.
• Chiusura (Rosso): definisce un TASK di chiusura (non può avere figli).
• Attesa (Arancione): definisce un TASK di attesa.
• Custom (Grigio): è un TASK extra modello che può essere assegnato al flusso di lavoro.
• Chiusura/Custom (Grigio/Rosso): è un TASK extra modello che rappresenta una chiusura straordinaria del flusso di lavoro.

All'interno dei dati principali della struttura di un TASK troviamo inoltre i campi seguenti:

• Gruppo Utenti: il modulo workflow è dotato di una gestione a parte dei gruppi utente gestibili tramite l'apposito programma BNWFGSGR. Un TASK deve obbligatoriamente avere assegnato un gruppo utenti oppure un singolo utente. Questo serve per definire chi sarà abilitato a prendere in carico il TASK creato.
• Utente: da utilizzare nel caso in cui non è necessario assegnare un gruppo di utenti ma solo un singolo utente. Questo evita di generare gruppi di utente con all'interno un singolo utente.
• Durata: la durata può essere espressa in giorni o ore. Se un TASK rimane aperto per una durata maggiore di quella indicata, viene classificato come scaduto.
• Coordinate: determina la posizione del TASK all'interno del diagramma (editor grafico).

All'interno del TAB Struttura è presente anche la griglia dove sono contenute le connessioni con gli altri Task figli. Se il Task in questione è di tipo Decisionale, è possibile inserire la risposta definendo quella di Default, se è di qualsiasi altro tipo è comunque possibile inserire un dettaglio. La risposta o il dettaglio verranno riportati sulla freccia che collega i due Task all'interno dell'editor.

Opzioni

Per un TASK è possibile impostare le seguenti opzioni:

• Può essere respinto: determina se il TASK può essere respinto.
• Obbliga note in chiusura: obbliga all'utente che sta chiudendo il task ad inserire delle note in chiusura.
• Obbliga inserimento password: obbliga all'utente che sta chiudendo il task ad inserire la propria password.
• Obbliga inserimento Durata in Apertura: obbliga l'utente che sta chiudendo il task ad inserire la durata prevista del task successivo, in giorni, ore, oppure inserendo una data.
• Auto-Assegnazione Utente dal Task Padre: con questa opzione è possibile determinare che quando un nuovo task viene generato, viene subito assegnato all'utente assegnato al task padre. Questo è molto utile quando si vuole far svolgere un ramo del flusso di lavoro all'utente che lo ha inizializzato.
• Auto-Assegnaz. all'utente responsabile del padre: con questa opzione è possibile determinare che quando un nuovo task viene generato, viene subito assegnato all'utente indicato come Utente Bus resp. nell'organizzazione della ditta sull'utente assegnato al task padre.
  
  
• Obbliga Assegnazione Utente in Apertura: Quando si completa un Task, escluso quello di chiusura, si vanno a generare i Task figli. Con questa opzione attiva si obbliga all'utente che sta chiudendo il Task di assegnare i nuovi Task figli ad un utente appartenente al gruppo di lavoro assegnato al Task.
• Auto-Completa alla Scadenza: Ad ogni modello di Task è possibile settare una durata, al momento della creazione del Task viene calcolata la data di scadenza a seconda della durata impostata. Con questa opzione attiva se il Task scade senza essere completato, viene completato in automatico da un programma BATCH. È possibile impostare questa opzione anche su un Task di tipo Decisionale andando però ad impostare qual è la risposta di default.

Notifica

Il modulo Workflow è dotato di un servizio di notifiche per ogni Task sia in fase di apertura che in fase di chiusura (completamento). Per impostare:

• Tipologia: le notifiche in apertura o chiusura di un Task possono essere fatte tramite Mail, pop-up o con post di Business 4 People. Per impostare le notifica via Pop-up ricordarsi di: a) lanciare il Busserv.exe sul server e sul client destinatario; b) configurare un modello Mail nel task che prevede la notifica via pop-up; c) impostare in Gestione Operatori, il campo "PC Abituale" nell'operatore destinatario del pop-up
• Destinatari: in avvio del task possiamo effettuare notifiche al gruppo utenti assegnato al modello di Task, oppure ad un operatore specifico. In chiusura oltre al gruppo utenti e ad un operatore specifico, è possibile inviare notifiche al cliente/fornitore o agli agenti legati all'oggetto gestione assegnato al Processo.
• Modello MAIL: per facilitare il riuso di mail preimpostate, il modulo workflow è dotato di un suo strumento per la creazione di modelli di mail caratterizzati da un codice e un oggetto. In questo modo è possibile utilizzare lo stesso modello di Mail per la notifica in avvio o chiusura di Task diversi. Il programma per la gestione dei modelli MAIL si chiama BNWFGSTM.

Gestione

Quando un Task viene aperto (generato) si effettuano le seguenti operazioni:

1. Si esegue, se assegnata, la procedura di controllo in ingresso.
2. Se la procedura di controllo da esito positivo si procede con la creazione del record sul DB.
3. Una volta generato il Task si esegue, se assegnata, la procedura di update.
4. Infine si eseguono le notifiche assegnate (Mail, popup, post).

Esistono dei casi particolari dove questa sequenza di eventi non si verifica come riportato sopra:

• Se il Task è di tipo APERTURA, non viene eseguita la procedura di controllo perché verranno già eseguite le procedure di controllo associate alla regola di attivazione del processo.
• Se si tratta di un Task rigenerato, perché il figlio è stato respinto, non vengono eseguite le procedure di controllo e di update in ingresso, ma vengono eseguite solo le notifiche.

Quando un Task viene chiuso (completato) si effettuano le seguenti operazioni:

1. Si esegue, se assegnata, la procedura di controllo in uscita.
2. Se la procedura di controllo da esito positivo si procede con la chiusura del Task.
3. Una volta chiuso si esegue, se assegnata, la procedura di update.
4. Infine si eseguono le notifiche assegnate al task (Mail, popup, post).

Procedura Di Controllo: La procedura di controllo può essere eseguita prima della creazione di un nuovo task o prima della chiusura di un task.

• In APERTURA serve per verificare se il nuovo task può essere generato oppure no. Quando viene lanciata questa procedura il task non esiste ancora. ATTENZIONE: Se il task è di tipo Apertura, quindi il primo task ad essere istanziato quando viene creato il processo, non deve essere eseguita alcuna procedura di controllo.
• In RIAPERTURA. Quando si respinge un task viene invalidato lui e rigenerato il suo padre. Quando il task padre viene riaperto non deve essere eseguita la procedura di controllo
• In CHIUSURA serve per verificare se l'istanza di task può essere chiusa oppure no. Quando viene lanciata questa procedura, l'istanza di task esiste sul Database ma ancora non è stata chiusa.

Procedura Di Update: La procedura di update può essere eseguita dopo la creazione di un nuovo task o dopo la chiusura di un task.

• In APERTURA quando viene eseguita la procedura di update, il task è già generato (inserito) all'interno del Database. Questo vuol dire che la procedura di update non viene eseguita all'interno della stessa transazione che genera il task. Se la procedura per qualche motivo non viene eseguita correttamente, si perdono solo le sue modifiche, mentre il task generato rimane invariato.
• In CHIUSURA quando viene eseguita la procedura di update, il task è già stato chiuso (completato). Questo vuol dire che la procedura di update non viene eseguita all'interno della stessa transazione che chiude il task. Se la procedura per qualche motivo non viene eseguita correttamente, si perdono solo le sue modifiche, mentre il task rimane invariato.

Editor Grafico

L'editor grafico permette di interagire in modo visuale al flusso, strutturando i vari task per rendere il tutto più comprensibile e portabile. Grazie all'utilizzo del mouse è possibile spostare i task, effettuare le connessioni in modo rapido ed allinearli sfruttando l'ancoraggio assistito.

L'editor è inoltre dotato di una state bar in basso dove a sinistra vengono riportate informazioni sul numero di nodi inseriti suddivisi per tipologia, mentre a destra vengono riportate le seguenti informazioni:

• Posizione del nodo selezionato (X, Y)
• Dimensione del nodo selezionato (Larghezza x Altezza)
• La percentuale di zoom del diagramma
• La dimensione del diagramma espressa in pixel

La rappresentazione grafica di un task, riporta le principali informazioni:

• In alto a sinistra troviamo il numero del TASK.
• Nel primo campo in alto è riportato il gruppo di utenti assegnato preceduto dal prefisso (G) e l'utente assegnato preceduto dal prefisso (U).
• Nel riquadro centrale c'è il nome del TASK.
• In basso a sinistra è presente un'icona, che in modalità editing del modello può essere utilizzata per effettuare le connessioni con gli altri TASK con l'utilizzo del Mouse, mentre nel diagramma di flusso verrà riportata un'icona diversa a seconda dello stato del TASK (aperto, completato, rifiutato).
• Il colore del TASK è utile per determinare la tipologia.

Task previsionali

I task previsionali vengono generati automaticamente alla creazione del processo e modificati durante le operazioni di avanzamento/respingimento dei task.

La creazione iniziale dell'albero previsionale viene fatta in base al flusso presente sul modello del processo; è quindi necessario fornire tutte le risposte di default ai task decisionali, altrimenti non sarà possibile la creazione di tale struttura.

La gestione dei modelli workflow avvisa l'utente in caso di mancanza dei default.

In caso di assegnazione di un default che causa un loop infinito (come dall'esempio successivo), il modello viene salvato in stato incompleto.

Alla creazione del processo vengono creati i task previsionali.

Se si apre un task previsionale, tutte le operazioni possibili sono state disabilitate, tranne 'Strumenti/Assegna Utente', in modo da poterlo assegnare al probabile esecutore finale per programmare il lavoro futuro dell'operatore.

Chiudendo un task aperto, il successivo task previsionale viene cancellato ed al suo posto viene creato il task in stato 'Aperto'; se il task previsionale era assegnato ad un utente, anche il task in fase di creazione viene assegnato allo stesso utente.

Questa regola ha una deroga, se il task in fase di creazione ha la spunta su 'Auto-Assegnazione utente da Task Padre', allora viene utilizzato l'operatore del task padre.

Nel caso in cui l'operatore deve essere inserito obbligatoriamente in apertura, sulla maschera di scelta viene riportata l'informazione dell'utente a cui è assegnato il task previsionale; a questo punto sarà a carico dell'operatore confermare o meno tale scelta.

Chiudendo un task decisionale con una scelta diversa dal default (ad es: NO), viene cancellato l'albero previsionale del 'NO' e creato quello della risposta effettiva 'SI'.

Se il task viene respinto, viene ricreato l'albero previsionale della risposta di default 'NO'.

Aprendo un qualsiasi task, nel tab 'Flusso' è visibile la 'storia' del task ed i futuri task previsionali.

Nel tab 'Diagramma di flusso' NON sono riportati i task previsionali.