3.2. Il flusso di lavoro

Il flusso di lavoro è una catena di azioni o di eventi di cui si ha bisogno per raggiungere un obbiettivo. Il flusso di lavoro spesso esprime il processo attraverso il quale si concretizza la realizzazione di un determinato business.

Ogni business ha le sue regole e un esempio di queste potrebbe includere:

• Prima che un documento di un dipendente sia diffuso esso deve essere visto ed approvato da un revisore.

• In una fabbrica di macchine utensili, per ogni macchina da assemblare l’ordine deve essere notificato e ogni cambiamento nello stato dell’assemblamento deve passare dalle strutture della fabbrica.

• Prima che una pagina Web sia pubblicata essa deve essere approvata dagli uomini del marketing, approvata dal web master ed eventualmente tradotta da un traduttore.

Il flusso di lavora organizza logicamente la catena di produzione e definisce il modello da seguire per la realizzazione di un prodotto o la fornitura di un servizio. Dal momento che esiste un’organizzazione logica dei compiti e dei passi necessari è più facile programmare dei cambiamenti o creare nuove strutture concettuali per rafforzare l’ efficacia del processo stesso.

Per cominciare introdurremo due termini: stato e transizione.

Uno stato è un’ informazione su una unità di contenuto in un dato momento. Esempi di stato sono: bozza, da visionare, non visibile e pubblicato. Ogni flusso di lavoro ha almeno uno stato iniziale dal quale tutti i contenuti partono, essi passeranno poi attraverso un certo numero di stati differenti nei quali saranno modificati fino allo stato finale. Nel caso dei CMS gli stati che possono essere considerati finali sono più d’uno a secondo della natura e della finalità dei documenti.

Per ogni unità di informazione che passa da uno stato ad un altro c’è bisogno di una transizione. Una transizione collega uno stato di partenza con uno di arrivo. Ogni transizione può comportare un gran numero di cambiamenti ma comunque essa muove un documento da uno stato ad un altro. Di solito una transizione avviene in seguito a una azione dall’esterno, ad esempio un click di un utente autorizzato.

Per visualizzare meglio il concetto riproporremo qui di seguito l’ esempio che Andy McKay usa nella sua “The definitive guide to Plone”¹ come introduzione all’argomento: il bollettino di pagamento delle carte di credito. (Andy McKay, The definitive Guide Plone, Berkeley, Apresse, 2004, cap. VIII, pp. 2-4.)

1. La banca prepara il bollettino e lo invia al mio domicilio.

2. Ritiro il bollettino e lo pongo sulla mia scrivania. Può succedere abbia dei dubbi su alcune delle voci di spesa e così faccio delle richieste di chiarimento alla banca.

3. Presento alla banca i miei dubbi che a volte possono rendere necessario l’invio di un nuovo bollettino o che vengono risolti in altra maniera.

4. Alla fine del mese saldo il debito da me contratto in precedenza.

Gli stati di questa situazione sono così riassumibili:

• Bozza: il bollettino è stato preparato e mi è stato inviato.

• Revisione: ho ricevuto il bollettino e lo sto esaminando.

• Pagato: il bollettino è stato saldato ed archiviato.

Individuati gli stati occupiamoci ora delle transizioni del caso:

• Spedizione: la banca mi invia il bollettino.

• Pagamento: il bollettino viene pagato.

• Chiarimento: nel bollettino c’è qualcosa di poco chiaro e per questo viene rinviato alla banca per chiarimenti

Il flusso di lavoro di questo processo è quindi visualizzabile attraverso il seguente diagramma:

Una volta esplicitato il processo per il pagamento dei bollettini in un flusso di lavoro, il passo successivo è l’ organizzazione dei ruoli per la sicurezza dei pagamenti. Per adesso questo flusso di lavoro contiene la struttura logica per una applicazione che si occupa del pagamento dei bollettini.
In qualsiasi sistema complesso ci sono utenti, ruoli e gruppi. Questo metodo organizzativo consente ai CMS di gestire in maniera flessibile la sicurezza anche in presenza di comunità di utenti molto numerose e diversificate al loro interno.
Quando un contenuto viene trasformato dal flusso di lavoro da uno stato a quello successivo possono variare anche le impostazioni della sicurezza e le regole di accesso.


Tornando all’ esempio dei bollettini bancari vediamo di ricavarne le possibili regole riguardo alla sicurezza del processo:

Figura 3.2. Le transizioni e le entità che possono attivarle

Da questa prospettiva sono chiare le transizioni e chi può renderle effettive. Non è però chiaro che tipo di accesso ognuna di queste entità effettuerà per compiere le azioni necessarie ad ogni transizione. Per esempio quand’ è che la banca emette il bollettino e quando può essere visionato?
Se solo io ho la possibilità di fare addebiti con la mia carta di credito, la banca senz’ altro può in ogni momento controllarne l’entità e eventualmente fornirmi chiarimenti a riguardo.
Vediamo quindi la tabella in figura 3.3 aggiornata sul tipo di accesso che le entità in questione hanno sul mio bollettino:

Stato	Debitore	Proprietario
Bozza		Spedire, vedere, emettere
Revisione	Pagare, chiedere pagamenti, vedere	vedere
Pagato	vedere	vedere

Figura 3.3. Entità e possibilità di accesso.

Com’ è evidente io non posso emettere il bollettino, solo la banca può. In questa situazione è la banca che è la proprietaria del bollettino. Questa è la dimostrazione pratica del concetto di proprietà digitale di un contenuto: sono il proprietario di una informazione quando le impostazioni della sicurezza mi danno la possibilità di crearla.

Se combiniamo transizioni e azioni con le entità e i ruoli la tabella avrà l’ aspetto seguente:

schema4

Anche se questo esempio è piuttosto forzato illustra un’ applicazione di base del flusso di lavoro.

Tornando ai CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

i CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

• Utente anonimo. Non viene assegnato dall’ amministratore, è chiunque navighi nel sito e può soltanto vedere i contenuti espressamente pubblicati e visibili.

• Utente autenticato. Viene riconosciuto dal sistema attraverso un nome utente e una password.

• Editor. È un utente autenticato che ha la possibilità di creare contenuti o contribuire alla elaborazione di quelli esistenti in specifiche aree del sito alle quali ha accesso, ma non ha la possibilità di pubblicare direttamente i documenti editati che deve invece sottoporre al revisore.

• Revisore. È un utente a cui i contenuti vanno inviati affinché vengano rivisti ed approvati per la pubblicazione oppure rimandati al mittente per eventuali modifiche. Tipicamente questo gruppo di utenti comprende i responsabili dei vari dipartimenti.

• Pubblisher. Chi è responsabile della pubblicazione definiva e che rende attivo questo stato.

• Amministratore. Questo utente è responsabile del sistema. È l’ amministratore che assegna ruoli e permessi ed ha accesso a qualsiasi documento. Possono esserci diversi livelli anche per gli amministratori che possono avere delle restrizioni a seconda delle sezioni del sito.

Introduciamo quindi dopo le entità attive all’ interno di un CMS un modello di macchina a stati che si occupa della gestione dei contenuti e che prende in esame flusso di lavoro potenziale tra l’ editor di un documento, il revisore e gli stati di visibile, privato, da rivedere e pubblico.

La figura 3.5 mostra i principali stati e le principali transizioni necessarie per la gestione delle informazioni attraverso un CMS. La linea punteggiata rappresenta una sorta di divisione che sono le impostazioni della sicurezza, alla destra della linea il revisore interagisce con i contenuti. Ogni contenuto può e deve avere soltanto un proprietario ovvero l’ utente che ne è l’autore.

Ora possiamo, proprio come per i bollettini bancari, associare le entità con le azioni e con i permessi in modo da esplicitare i ruoli all’interno del flusso di lavoro.

schema6

Quando un contenuto è stato pubblicato solo il Pubblisher ha la possibilità di ritirarlo e di modificarne il contenuto, il revisore si occupa invece di visionare le bozze che i proprietari propongono per la pubblicazione che se approvate vengono a loro volta passate al Pubblisher che ne rende operativa la pubblicazione.

Come abbiamo visto un flusso di lavoro di un CMS si occupa quindi di gestire in maniera standardizzata ed automatica i contenuti che una organizzazione produce al suo interno come quelli che possono giungerle dall’ esterno, la condizione sufficiente e necessaria è che l’ amministratore assegni ai vari utenti un ruolo nel sistema.

Una entità che non è stata presa per ora in esame è quella di membro di un gruppo. Per il lavoro collaborativo è necessario che i membri di un dipartimento possano intervenire su documenti che pur non essendo strettamente di contenuti digitali sono evidenti e sono stati trattati in precedenza. privati, ovvero accessibili al solo proprietario, non possono nemmeno essere visibili a tutti, la risposta che i CMS danno a questa necessità è la creazione dei gruppi. L’ amministratore può dare la possibilità di creare documenti in uno stato intermedio tra visibile e privato e cioè visibile soltanto ai membri di uno stesso gruppo.

Successivo: Amministrazione e sicurezza Precedente: Funzionamento del CMS