DIPARTIMENTO DI FILOLOGIA, LETTERATURA E LINGUISTICA Corso di Laurea Magistrale in Informatica Umanistica
La gestione di un lavoro collaborativo
mediante una piattaforma software
Candidato
Mafalda Papini
Relatore
Vincenzo Ambriola
Ringraziamenti
Desidero ringraziare tutti coloro che direttamente e indirettamente mi hanno aiutata nella stesura di questa tesi. Ringrazio anzitutto il professor Vincenzo Ambriola, mio relatore, per avermi guidata in questo percorso. Senza i suoi commenti e le sfide continue alle quali mi ha sottoposta questo lavoro non sarebbe stato possibile. Inoltre la mia gratitudine va al dottor Ludwig Bargagli, il cui aiuto è stato fondamentale per comprendere alcune delle tecnologie utilizzate in questo progetto. Infine vorrei ringraziare la mia famiglia e i miei amici, che mi hanno supportata (e sopportata) in questi mesi di lavoro. Sono stati il mio punto di equilibrio e la mia forza, a loro dedico questa tesi.
Indice
Elenco delle figure iv
Elenco delle tabelle vi
1 Introduzione 1
2 Il lavoro collaborativo 3
2.1 La disciplina . . . 3
2.2 L’approccio di analisi . . . 5
2.3 Il supporto al lavoro collaborativo . . . 7
3 BPMN 2.0 9 3.1 La storia . . . 9 3.2 La notazione . . . 10 3.2.1 Eventi . . . 10 3.2.2 Attività . . . 11 3.2.3 Porte . . . 12 3.2.4 Flussi . . . 12 3.2.5 Swimlane . . . 13 3.3 Esempio . . . 13 3.4 Scenario . . . 15 3.5 Il meta-modello . . . 17 4 Il caso di studio 19 4.1 Descrizione . . . 19 4.2 I ruoli . . . 20 4.3 I documenti . . . 20 4.3.1 Certificato di servizio . . . 20
4.3.2 Autocertificazione dei servizi . . . 21
4.3.3 Domanda di ricostruzione di carriera . . . 21
4.4 I flussi di lavoro . . . 21
4.4.1 La richiesta di certificato di servizio . . . 22
4.4.2 La presentazione della domanda di ricostruzione di carriera . . . 23
5 Activiti e Alfresco 25 5.1 Lo stato dell’arte . . . 25
5.2 Confronto . . . 27
5.3 Activiti . . . 29
5.4 Alfresco Community Edition . . . 31
5.4.1 L’interfaccia . . . 33
5.4.2 Programmare per Alfresco . . . 40 iii
iv INDICE
6 La piattaforma software 43
6.1 La rappresentazione dei ruoli . . . 43
6.2 La rappresentazione degli spazi di lavoro . . . 44
6.3 Implementazione dei contenuti . . . 45
6.4 Implementazione dei flussi di lavoro . . . 50
7 Il supporto tecnologico 61 7.1 Installazione dei software necessari . . . 61
7.2 Dettagli relativi al caso di studio . . . 63
7.2.1 Moduli AMP di “Portale Scuola” . . . 64
7.2.2 Configurazione dell’interfaccia . . . 66
7.3 Prove d’uso . . . 70
7.3.1 Test: la richiesta di certificato di servizio . . . 70
7.3.2 Test: la presentazione della domanda di ricostruzione di carriera . . 74
7.3.3 Test: la ricerca di un file . . . 79
8 Conclusioni 83 A L’enunciato del problema 85 A.1 Ricostruzione di carriera di docenti e personale ATA . . . 85
A.2 Glossario . . . 86
A.3 Ruoli e Documenti . . . 88
A.3.1 Ruoli . . . 88
A.3.2 Documenti . . . 89
A.4 Flussi e Attività . . . 92
A.4.1 Flussi . . . 92
A.4.2 Attività . . . 93
Elenco delle figure
3.1 Tipologie di eventi . . . 11
3.2 Tipologie di attività . . . 12
3.3 Tipologie di porte . . . 12
3.4 Tipologie di flussi . . . 13
3.5 Rappresentazione delle swimlane . . . 13
3.6 Diagramma BPMN 2.0 che rappresenta l’ordine di una pizza . . . 15
4.1 Diagramma BPMN per la richiesta di certificato di servizio . . . 23
4.2 Diagramma BPMN per la presentazione di una domanda di ricostruzione di carriera . . . 24
5.1 Activiti Designer, creazione di un nuovo progetto . . . 30
5.2 Activiti Designer, schermata iniziale di un diagramma . . . 30
5.3 Activiti Designer, esempio di flusso di lavoro . . . 31
5.4 Activiti Designer, modello aperto con un editor XML . . . 32
5.5 Gartner Magic Quadrant for ECM, ottobre 2015 . . . 32
5.6 Pagina iniziale di Alfresco per l’amministratore . . . 34
5.7 Pagina di gestione del pannello di controllo . . . 35
5.8 Modulo iniziale per “Esamina e approva (esame di gruppo)” . . . 36
5.9 Pagina relativa all’archivio . . . 36
5.10 Creazione di un nuovo utente . . . 37
5.11 Creazione di un nuovo gruppo . . . 38
5.12 Creazione di un nuovo sito . . . 39
7.1 Strumenti di amministrazione, creazione dei gruppi relativi ai ruoli . . . 66
7.2 Creazione delle cartelle condivise . . . 67
7.3 Gestione dei permessi di accesso alle cartelle . . . 68
7.4 Creazione della regola “Protocollabile” . . . 68
7.5 Personalizzazione delle pagine del sito PortaleScuola . . . 69
7.6 Aggiunta dei membri al sito PortaleScuola . . . 70
7.7 Pannello di Controllo di Mafalda Papini . . . 71
7.8 Form iniziale della richiesta di certificato di servizio . . . 71
7.9 Assegnamento all’istituto . . . 71
7.10 Notifica di un nuovo compito in attesa . . . 72
7.11 Nuovo documento di testo normale . . . 72
7.12 Cambiare il tipo di un documento . . . 73
7.13 Compilazione del form dei metadati di un documento . . . 73
7.14 Il certificato di servizio viene associato al compito . . . 73
7.15 Modulo per la valutazione del certificato di servizio . . . 74
7.16 Il certificato di servizio viene spostato fra i documenti personali del richiedente 74 7.17 I documenti sono caricati sulla piattaforma . . . 75 7.18 Modulo iniziale per la presentazione della domanda di ricostruzione di carriera 75
vi ELENCO DELLE FIGURE
7.19 La documentazione passa nello spazio di lavoro della segreteria . . . 76
7.20 Modulo per protocollare i documenti . . . 76
7.21 Il numero di protocollo viene memorizzato come proprietà del documento . 77 7.22 Modulo per la verifica dell’autocertificazione dei servizi . . . 77
7.23 Modulo per la verifica della documentazione della domanda di ricostruzione di carriera . . . 78
7.24 Notifica di approvazione e notifica di una nuova domanda di ricostruzione di carriera . . . 78
7.25 La documentazione passa nello spazio di lavoro delle Ragionerie dello Stato 78 7.26 Selezione del tipo di contenuto da ricercare . . . 79
7.27 Compilazione del modulo di ricerca specializzato . . . 79
7.28 Risultati della ricerca che soddisfano i parametri . . . 80
7.29 Ricerca dell’autocertificazione dei servizi di Mario Rossi . . . 80
Elenco delle tabelle
5.1 Motori BPMN . . . 27
6.1 Schema dei tipi di contenuto personalizzati . . . 47
6.2 Schema della richiesta di certificato di servizio . . . 50
6.3 Schema della presentazione di domanda di ricostruzione di carriera . . . 51
6.4 Assegnamenti della richiesta di certificato di servizio . . . 55
6.5 Assegnamenti della presentazione di domanda di ricostruzione di carriera . . 57
7.1 Path per “workflow-portalescuola-repo” . . . 64
Capitolo 1
Introduzione
«Il lavoro collaborativo è un’attività che prevede la partecipazione di più persone, rivolta alla produzione di un bene o all’erogazione di un servizio.»
La natura collaborativa caratterizza da sempre moltissime attività umane, ma è con l’avvento della tecnologia informatica e di Internet in particolare che questa spinta alla col-laborazione ha raggiunto i suoi massimi livelli. Aziende e organizzazioni di ogni dimensione e tipo fondano sempre più la loro fortuna su complessi processi di collaborazione, interni ed esterni, che devono essere gestiti in maniera appropriata. Assistiamo a una progressiva digitalizzazione di tali processi, con tutte le sfide che questa evoluzione comporta.
Questa tesi nasce dall’intenzione di approfondire le tematiche affrontate nel corso di “Piattaforme per il lavoro collaborativo”. L’insegnamento mira a definire il lavoro collabo-rativo e a identificare un insieme di metodi per la sua analisi e la progettazione dei requisiti di una piattaforma di supporto.
A partire dalle riflessioni del corso, la tesi affronta il problema di capire quali strumenti tecnologici siano idonei per realizzare una piattaforma software di supporto. Per validare la soluzione individuata, la piattaforma è utilizzata per uno specifico lavoro collaborativo. Il caso di studio è svolto seguendo le fasi di analisi, di implementazione e di verifica.
La tesi è organizzata in due parti: la prima (capitoli 2-4) è dedicata agli strumenti concettuali, la seconda parte (capitoli 5-7) affronta i temi relativi agli strumenti tecnologici. Il capitolo 2 presenta il concetto di lavoro collaborativo secondo la letteratura. L’in-quadramento disciplinare dell’argomento come oggetto del Business Process Management permette di delineare una strategia di analisi e di identificare le tipologie di strumenti software più idonei al suo supporto.
Il capitolo seguente presenta lo standard riconosciuto per la rappresentazione di pro-cessi aziendali, ossia la notazione BPMN (Business Process Model and Notation). Dopo averlo inquadrato nel suo sviluppo storico, viene descritto nei suoi elementi principali e successivamente utilizzato in un caso di prova.
A chiudere l’inquadramento concettuale della tesi è la presentazione del caso di studio: un lavoro collaborativo relativo alla ricostruzione di carriera di docenti e personale ATA.
La sezione sugli strumenti tecnologici presenta una panoramica sullo stato dell’arte e una selezione degli strumenti software più idonei per la realizzazione del progetto, attra-verso un processo di esclusione progressiva. Dei sistemi selezionati (Activiti e Alfresco
2 CAPITOLO 1. INTRODUZIONE Community Edition) presentiamo le caratteristiche fondamentali e le modalità generali di utilizzo.
Il capitolo 6 descrive l’implementazione del caso di studio sulla piattaforma Alfresco. In particolare, presenta le modalità scelte per rappresentare i ruoli e i loro spazi di lavoro e, contemporaneamente, l’implementazione dei modelli dei contenuti e dei flussi di lavoro. L’ultimo capitolo riporta i dettagli più prettamente tecnologici relativi all’installazione dei sistemi software utilizzati e alla corretta configurazione della piattaforma di supporto. Il capitolo si chiude con la presentazione dei risultati di alcuni test di utilizzo della piattaforma software.
Capitolo 2
Il lavoro collaborativo
La prima sezione è dedicata alla definizione dei concetti fondamentali del lavoro collabora-tivo e alle discipline che si occupano del suo studio. Abbiamo quindi descritto un approccio di analisi che nasce dalla convergenza delle tecniche del Business Process Modeling e del-l’analisi dei requisiti nell’ingegneria del software. L’ultima sezione descrive le categorie di strumenti software che possono essere usate per la realizzazione di un sistema di supporto del lavoro collaborativo.
2.1
La disciplina
Un lavoro collaborativo è un insieme di attività svolte da più persone per il raggiungimento di un obiettivo comune [29]. Questa definizione è applicabile a un ampio spettro di attività umane, appartenenti ai contesti più disparati. Se, per esempio, consideriamo un qualsiasi gioco a squadre, vedremo che anche questo coinvolge più partecipanti per raggiungere l’obiettivo comune, cioè la vittoria.
Una definizione più precisa di lavoro collaborativo in ambito produttivo è stata data da Ko [34]: un processo aziendale (Business Process, BP) è un insieme di attività messe in atto dai suoi ruoli coinvolti per raggiungere volontariamente un obiettivo di business comune. Questa definizione evidenzia gli elementi principali che caratterizzano un lavoro collaborativo, a cominciare dal fatto che l’obiettivo comune è un obiettivo di business, ossia un risultato dotato di valore. Una prima distinzione rispetto alla prima definizione di lavoro collaborativo è data dall’effetto del suo completamento, ossia la produzione di beni, siano essi beni materiali o servizi erogati.
Un singolo processo aziendale comprende più attività (o compiti) elementari che devono essere completate per portare a termine il lavoro nel suo insieme. Queste attività non sono svolte da persone, ma da ruoli. Questo termine evidenzia una netta separazione fra il lavoro e l’individuo effettivo che lo svolge. Un ruolo, infatti, è un’entità dotata di competenze e conoscenze, a cui è assegnato un insieme di compiti che deve eseguire all’interno di un’azienda. Un ruolo, pertanto, si distingue da una persona reale in quanto può essere ricoperto da più persone1.
1In questo caso si parla di un ruolo collettivo.
4 CAPITOLO 2. IL LAVORO COLLABORATIVO L’importanza dei processi all’interno di un’organizzazione ha fatto emergere e conso-lidare la disciplina della gestione dei processi aziendali (Business Process Management, BPM). Secondo la definizione di van der Aalst [51], BPM supporta i processi aziendali usando metodi, tecnologie e software per progettare, mettere in atto, controllare e ana-lizzare processi operativi che coinvolgono persone, organizzazioni, applicazioni, documenti e altre fonti di informazione. Si tratta di un approccio che ha l’obiettivo di migliorare i processi di lavoro di un’organizzazione, focalizzandosi sulla ri-progettazione dei flussi per ottimizzare le procedure, aumentare l’efficienza e l’efficacia attraverso un miglioramento continuo dei processi stessi [33].
Il BPM è una disciplina teorico-pratica che coinvolge settori molto diversi (teoria del management, matematica, informatica, semiotica, ecc.) e permette uno studio approfon-dito delle procedure di un’organizzazione. La consapevolezza di come queste si strutturino può aumentare la visibilità e la conoscenza delle attività di un’azienda, facilitare il processo di identificazione di eventuali problemi e punti di possibile miglioramento e migliorare la definizione dei compiti e dei ruoli all’interno di un’azienda [34].
La letteratura [25, 33, 34] è concorde nell’individuare fra i principali obiettivi del BPM l’ottimizzazione dei processi di lavoro. Questo costituisce un fattore di grande interesse per le aziende, in quanto l’aumento di efficacia ed efficienza delle loro procedure si può tradurre in una diminuzione dei costi (pensiamo solamente ai costi per la risoluzione di problemi altrimenti non identificati).
Sul piano tecnologico, la ri-progettazione dei processi si traduce nella progressiva di-gitalizzazione del lavoro. Attualmente l’uso di strumenti informatici per la gestione del lavoro è una realtà sempre più affermata, caratterizzata da un costante processo di evolu-zione parallelo a quello che coinvolge l’industria informatica in generale. Il diffondersi di piattaforme software di supporto ha reso il BPM fondamentale, in quanto solo una piena conoscenza delle procedure può guidare la realizzazione di piattaforme idonee a gestirle. In quest’ottica possiamo identificare un sottoinsieme della disciplina che si occupa in maniera puntuale dell’aspetto tecnologico, ossia il Workflow Management (gestione dei flussi di la-voro). Si tratta dell’automatizzazione di un processo aziendale, parziale o totale, durante il quale informazioni, documenti o compiti sono trasmessi da un partecipante all’altro per lo svolgimento di azioni, secondo un insieme di regole procedurali [34].
La modellazione dei processi aziendali diviene quindi una disciplina rilevante sia in ambito business che nella ricerca sui sistemi informativi, che permette di affrontare la dimensione organizzativa in termini di attori, attività e flussi di lavoro. I modelli prodotti sono una base utile per il trasferimento della conoscenza, per la comunicazione fra i diversi partner interni ed esterni a un’organizzazione e per la documentazione delle procedure [36]. Sul piano tecnologico, le analisi effettuate nel corso della modellazione hanno un ruolo importante nello sviluppo di piattaforme software, in quanto permettono di identificare i requisiti e le parti del lavoro che necessitano di un supporto digitale.
2.2. L’APPROCCIO DI ANALISI 5
2.2
L’approccio di analisi
Data l’importanza del Business Process Modeling, è opportuno definire un metodo di analisi dei lavori collaborativi che sia il più possibile sistematico e formale, dando al contempo una panoramica completa sulle procedure descritte.
Ko [34] fornisce una descrizione sintetica di quella che, nel 2009, era la prassi nell’in-dustria. Si tratta di un processo in sei fasi:
1. identificazione della necessità di modellare un processo aziendale
2. definizione degli obiettivi aziendali; si tratta solitamente di una fase di lavoro in cui l’analista si consulta con il committente per comprenderne le necessità
3. diagrammi dettagliati del flusso di lavoro mediante uno standard grafico facilmente interpretabile
4. traduzione dei diagrammi in codice eseguibile
5. esecuzione del codice mediante la realizzazione di un prototipo da mostrare al com-mittente
6. attuazione del processo aziendale eseguibile, ossia trasferimento del business process su una piattaforma software in grado di gestire il flusso di lavoro
Questo approccio è focalizzato sulla realizzazione di una piattaforma di supporto, lascian-do all’analisi del lavoro collaborativo uno spazio limitato. Poiché la modellazione di un processo aziendale può essere utilizzata anche per produrre una documentazione senza l’implementazione di una piattaforma software di supporto, è necessario che ogni aspetto delle procedure sia analizzato e descritto in maniera appropriata.
Una disciplina che presenta tecniche di analisi strutturate e affermate è l’ingegneria del software. In particolare il settore dell’analisi dei requisiti propone un metodo di lavoro che comprende la descrizione del lavoro non soltanto nell’ottica del sistema che deve essere realizzato, ma in primo luogo analizza i processi per come sono svolti in assenza dello strumento informatico [39].
Abbiamo quindi adattato alcune tecniche classiche dell’ingegneria del software al settore del Business Process Modeling, pianificando un’analisi suddivisa in due momenti. La prima fase è costituita dall’analisi preliminare del lavoro collaborativo, dove questo viene descritto al suo stato attuale in tutte le sue componenti. Segue una fase di rielaborazione delle informazioni raccolte alla luce del sistema di supporto che si intende realizzare.
L’analisi preliminare prevede una fase iniziale di formazione dell’analista che deve ac-quisire un bagaglio di conoscenze sul dominio tale da poter interagire senza difficoltà con il committente e da capire pienamente i processi che dovrà analizzare. L’analista svolge una serie di passi, ciascuno dei quali porta alla produzione di un documento:
1. effettua ad una serie di interviste al committente nel corso delle quali ottiene una de-scrizione dettagliata del processo aziendale; la dede-scrizione viene poi rielaborata nella forma di enunciato del problema, ossia una descrizione puntuale delle procedure in
6 CAPITOLO 2. IL LAVORO COLLABORATIVO esame, che dovrà essere approvata dal committente; in caso di mancata approva-zione si procede a una nuova serie di interviste per redigere una nuova versione del documento
2. definisce un glossario del dominio, che rende conto del significato di tutti quei termini, utilizzati nell’enunciato del problema
3. identifica ed elenca i ruoli e i documenti coinvolti, indicando per ogni documento i dati in esso contenuti
4. identifica i flussi di informazioni, indicando per ciascuno il documento scambiato, il ruolo mittente e il ruolo destinatario
5. produce uno schema sintetico delle attività (in forma di elenco) che distingue i diversi compiti base2
I documenti prodotti al termine dell’analisi preliminare descrivono il lavoro collaborativo in tutte le sue componenti e forniscono una base strutturata per la creazione di una do-cumentazione. La descrizione dei passi rende esplicita la scelta di utilizzare il linguaggio naturale per la realizzazione dei documenti. Questa scelta risponde all’esigenza di rendere l’analisi fruibile sia per tecnici (che sono facilitati nel lavoro di formalizzazione), sia per i referenti aziendali che hanno richiesto l’analisi dei processi.
La seconda fase di analisi prevede la rielaborazione dei documenti nell’ottica dell’imple-mentazione di una piattaforma di supporto. La scelta degli strumenti informatici con cui realizzare la piattaforma costituisce un presupposto per rielaborare le informazioni raccolte nell’analisi preliminare. Il processo di rielaborazione prevede i seguenti passi:
1. analisi dei ruoli coinvolti e scelta di come rappresentarli nel sistema informatico 2. analisi dei documenti utilizzati, eliminazione di eventuali documenti superflui e
iden-tificazione delle caratteristiche rilevanti a fini implementativi (per esempio, i metadati caratteristici di una tipologia di documento)
3. rielaborazione delle attività sulla base della piattaforma di supporto; si eliminano tut-te le attività sostituitut-te dalla piattaforma software (per esempio, l’invio e la ricezione di posta) e si inseriscono nuove attività di controllo
4. descrizione formale dei processi aziendali come flussi di lavoro, mediante uno standard grafico
Al termine di questa seconda fase di analisi, si può tornare al punto 4 del processo di modellazione descritto da Ko [34], ossia alle fasi di implementazione vera e propria della piattaforma software.
2.3. IL SUPPORTO AL LAVORO COLLABORATIVO 7
2.3
Il supporto al lavoro collaborativo
La modellazione dei processi aziendali, come già accennato, può avere come scopo la realiz-zazione di una piattaforma software di supporto per il lavoro collaborativo. Se consideria-mo le definizioni di BPM e di Workflow Management, notiaconsideria-mo che i loro ambiti di studio comprendono da una parte i flussi di lavoro (intesi come insieme di compiti da portare a termine) e dall’altra i flussi di informazioni che spesso costituiscono tali flussi di lavoro. Una piattaforma di supporto ai processi aziendali, quindi, deve gestire contemporanea-mente due diversi aspetti: da una parte la messa in opera dei diversi compiti, dall’altra la gestione dell’informazione.
Per quanto riguarda i flussi di lavoro, sono disponibili sul mercato degli strumenti spe-cifici per la loro descrizione ed esecuzione, ossia i motori BPM (BPM engine). Si tratta essenzialmente di software che, data una descrizione formale di un flusso di lavoro in una notazione specifica, riescono a gestire il flusso delle attività fra i diversi ruoli coinvolti in un lavoro collaborativo, con meccanismi di notifica e inserimento di informazioni. Tali stru-menti sono solitamente dotati anche di apposite interfacce di modellazione, che permettono di realizzare una descrizione grafica dei flussi di lavoro.
La semplice possibilità di eseguire un processo aziendale, tuttavia, non è sufficiente per parlare di un completo supporto del lavoro, in quanto manca la componente di gestione dell’informazione. Se consideriamo la forma più classica che l’informazione assume, ossia quella documentale, gli strumenti che paiono più adatti per la sua gestione in ambito business risultano essere i sistemi ECM (Enterprise Content Management Systems).
I sistemi ECM sono sistemi software utilizzati per la creazione, la modifica e la gestione di materiale documentale non strutturato [26]. Si tratta non di semplici archivi, né di file system3, bensì di strumenti che mettono a disposizione un sistema di memorizzazione delle informazioni documentali con funzionalità avanzate di ricerca, diversi livelli di accesso al materiale, memorizzazione delle diverse versioni di uno stesso contenuto.
I sistemi ECM non devono essere confusi con i Content Management Systems (CMS). Per quanto i due termini siano spesso utilizzati in modo interscambiabile, gli ECMS in-tegrano al loro interno una serie di strategie aziendali che invece mancano ai CMS4. Non a caso, il mercato attuale mette a disposizione delle aziende un’ampia gamma di software ECM forniti di motori per i flussi di lavoro. I prodotti appartenenti a questa tipologia possono essere considerati delle vere e proprie piattaforme per il lavoro collaborativo.
3I file system presentano numerosi fattori di rischio tra cui lo scarso controllo dell’accesso ai documenti
e la possibilità di perdita di materiale (per guasti, negligenza).
Capitolo 3
BPMN 2.0
Il capitolo affronta il problema della descrizione formale del lavoro collaborativo. La pri-ma sezione è dedicata al percorso evolutivo che ha portato all’emergere di una notazione standard per i flussi di lavoro: BPMN 2.0. La seconda sezione entra nel merito delle ca-ratteristiche della notazione in termini di obiettivi, elementi costitutivi e problematiche di implementazione. Il capitolo si conclude con un esempio di utilizzazione di BPMN 2.0 per la descrizione di un semplice flusso di lavoro.
3.1
La storia
Il Business Process Modeling “permette di catturare l’aspetto organizzativo di un’azienda in termini di attori, attività e flussi di lavoro”1 [36]. Tale livello di analisi descrittiva ha un duplice utilizzo a livello organizzativo: da una parte permette di documentare il lavoro che si svolge e di individuare gli elementi critici che ne inficino l’efficienza, dall’altra offre gli strumenti per ideare un’appropriata piattaforma di supporto.
Affinché questi obiettivi possano essere raggiunti anche in realtà articolate e complesse, le descrizioni prodotte con le tecniche del BPM devono essere complete e in linguaggio formale (per non incorrere in problemi di interpretazione). Queste necessità hanno portato, nel corso del tempo, allo sviluppo di linguaggi e notazioni per il BPM. In molti casi, però, si tratta di notazioni legate a specifici strumenti di modellazione o di gestione dei flussi di lavoro [16], notazioni proprietarie e incompatibili tra loro.
I primi standard nel settore nascono dall’esigenza di descrivere processi aziendali esegui-bili e sono mirati all’integrazione con i sistemi di gestione dei processi di lavoro (Business Process Management Systems, BPMS). A questo gruppo appartengono linguaggi come XPDL (XML Process Definition Language) e, in particolare, BPEL (Business Process Executable Language). Si tratta di due linguaggi di markup basati su XML che tuttavia mancano di una rappresentazione visiva di tipo grafico che li renda fruibili a tutti i livelli di un’azienda.
Un primo tentativo di dare una rappresentazione standardizzata dei processi in forma di diagramma si è basato su UML (Unified Modeling Language), un linguaggio di modellazione e specifica che utilizza diagrammi correlati, composti da elementi grafici, elementi testuali
1La traduzione è nostra.
10 CAPITOLO 3. BPMN 2.0 formali e testo libero. Il suo utilizzo per la modellazione dei processi di lavoro, tuttavia, non ha avuto la diffusione sperata, anche se questo rimane tutt’ora il linguaggio leader nel settore dello sviluppo software.
Dall’obiettivo di fornire un terreno condiviso per la rappresentazione dei processi di la-voro, nasce Business Process Model and Notation (BPMN), una notazione standard basata sui flussi di lavoro. BPMN raccoglie il meglio delle esperienze precedenti ed è costituito da una rappresentazione grafica in forma di diagrammi e da una semantica operazionale formalizzata [41], divenendo così utilizzabile a diversi livelli da parte di tutte le figure di un’azienda. La varietà degli elementi disponibili per la costruzione di un modello rispecchia il carattere generale della notazione, che vuole essere applicabile a ogni contesto.
Lo sviluppo di BPMN è stato avviato dalla Business Process Management Initiative (BPMI) allo scopo di fornire una notazione grafica al linguaggio per la descrizione di flussi di lavoro eseguibili BPML (Business Process Modeling Language). La prima specifica è stata sviluppata nel 2004 da un gruppo guidato da Stephen A. White (IBM) [16]. Con-temporaneamente il progetto è passato sotto il controllo dell’Object Management Group (OMG)2, che l’ha accettato come proprio standard nel 2006.
L’uscita della versione BPMN 2.0 nel 2011 segna il successo di questa notazione, nonché un punto importante di svolta. Le versioni 1.x erano dotate unicamente di descrizioni verbali degli elementi grafici utilizzati. La nuova specifica contiene invece, per la prima volta, una descrizione formale dei suoi elementi mediante un meta-modello.
La conferma definitiva di questa notazione arriva nel 2013, con l’uscita della revisione 2.0.2, riconosciuta come standard dall’ISO [27] (International Organization for Standardi-zation)3.
3.2
La notazione
BPMN 2.0 offre un ampio insieme di elementi grafici che possono essere composti per descrivere un lavoro collaborativo nella forma di diagramma di flusso. Questi possono essere raggruppati in cinque famiglie principali4:
• eventi • attività • porte • flussi • swimlane 3.2.1 Eventi
Un evento (event ) rappresenta qualcosa che accade durante un processo, che influisce sul flusso di lavoro e che ha solitamente una causa o un impatto.
2Un consorzio internazionale per gli standard tecnologici. Per approfondimenti [40]. 3
ISO/IEC 19510:2013 per maggiori informazioni si veda [30].
3.2. LA NOTAZIONE 11 Gli eventi sono rappresentati graficamente come cerchi, i disegni contenuti al loro inter-no sointer-no utilizzati per distinguerne le diverse tipologie (Figura 3.1). Possiamo individuare tre sotto-gruppi di eventi in base al momento in cui intervengono sul sistema:
iniziali: indicano l’inizio di un particolare processo
intermedi: sono collocati fra un evento iniziale e uno finale; questi eventi influenzano il processo, ma non lo avviano (almeno non direttamente) né lo terminano
finali: indicano la fine di un processo
Figura 3.1: Tipologie di eventi
3.2.2 Attività
Un’attività (activity) è un compito che viene portato a termine da un’azienda (o da un suo sottoinsieme) all’interno di un processo. Può essere semplice o composta (ossia a sua volta ulteriormente suddivisibile in più attività semplici).
Le attività semplici sono rappresentate graficamente con riquadri rettangolari che ne contengono il nome e un’icona che ne indica il tipo (Figura 3.2). Possiamo distinguere: compito manuale: (manual task ) indica un’attività umana svolta senza l’utilizzo di uno
strumento informatico
compito umano: (human task ) indica un’attività umana svolta con l’utilizzo di uno strumento informatico
compito messaggio: (message task ) indica un’attività di invio o ricezione di un messag-gio
compito servizio: (service task ) indica un’attività svolta da un servizio automatizzato compito script: (script task ) indica un tipo di service task che corrisponde a codice
12 CAPITOLO 3. BPMN 2.0 compito regola: (rule task ) indica un tipo di service task che valuta una regola e precede
una porta
Figura 3.2: Tipologie di attività
3.2.3 Porte
Una porta (gateway ) è utilizzata per controllare la divergenza o la convergenza di flussi di lavoro in base a specifiche regole. I diversi tipi di porta si distinguono per il tipo di comportamento gestito (per esempio, le porte esclusive permettono di scegliere un solo flusso fra quelli possibili) e/o per il tipo di elemento su cui si basa la scelta (per esempio, le porte basate su eventi scelgono il flusso da seguire in base a quale evento si verifica).
Graficamente le porte sono indicate da rombi, il cui disegno interno permette di indi-carne il tipo (Figura 3.3).
Figura 3.3: Tipologie di porte
3.2.4 Flussi
Un flusso (flow ) viene utilizzato per indicare uno “spostamento” (Figura 3.4). In particolare distinguiamo:
flussi di sequenza: (sequence flow ) collegano attività ed eventi secondo il loro ordine di esecuzione, indicando lo spostamento dell’esecuzione
3.3. ESEMPIO 13 flussi di messaggi: (message flow ) indicano uno scambio di informazione fra due
parte-cipanti a un diagramma di collaborazione
Figura 3.4: Tipologie di flussi
3.2.5 Swimlane
Una swimlane (letteralmente “corsia di nuoto”) rappresenta un partecipante a una col-laborazione. Questa è costituita da un gruppo (pool ) che rappresenta il partecipante (per esempio, se un lavoro coinvolge più aziende, ciascuna azienda è un partecipante) ed eventualmente da due o più corsie (lane) che rappresentano i ruoli coinvolti nel processo (Figura 3.5).
Figura 3.5: Rappresentazione delle swimlane
3.3
Esempio
La notazione BPMN 2.0 permette la descrizione di un qualsiasi processo di lavoro, indi-pendentemente dal contesto. A conferma di questo presentiamo un semplice esempio5 di utilizzo della notazione.
Consideriamo l’attività di ordinare una pizza: un cliente seleziona una pizza e la ordina presso una pizzeria. Se la pizza selezionata è disponibile, viene preparata e consegnata a domicilio, dove il cliente la paga. Se invece la pizza non è disponibile, la pizzeria contatta il cliente che può selezionarne una diversa.
5
Abbiamo utilizzato come base l’esempio proposto da Camunda alla pagina https://camunda.org/ bpmn/tutorial/.
14 CAPITOLO 3. BPMN 2.0 In questo processo abbiamo due partecipanti: il cliente e la pizzeria. Nella notazione i partecipanti sono indicati utilizzando dei “gruppi” (pool ). Abbiamo quindi suddiviso le attività fra i partecipanti, suddividendo le azioni svolte in compiti semplici e unitari:
• Il cliente
1. Seleziona una pizza 2. Ordina la pizza
3. Se riceve la conferma dell’ordine (a) Riceve la pizza
(b) Paga la pizza (c) Mangia la pizza
4. Se riceve l’avviso che la pizza non è disponibile (a) Torna al punto 1
• La pizzeria
1. Riceve un ordine
2. Verifica che la pizza sia disponibile 3. Se la pizza è disponibile
(a) Cucina la pizza (b) Consegna la pizza
(c) Riceve il pagamento 4. Se la pizza non è disponibile
(a) Comunica al cliente che la pizza non è disponibile
Le attività della pizzeria sono svolte da persone con diversi compiti, ossia da diversi ruoli. I diversi ruoli all’interno di un gruppo sono indicati con delle corsie all’interno del gruppo stesso. Nell’esempio individuiamo i seguenti ruoli coinvolti nell’ordinazione:
• Cassiere
1. Riceve l’ordine
2. Verifica la disponibilità
3. Contatta il cliente se la pizza non è disponibile • Pizzaiolo
1. Cucina la pizza • Ragazzo delle consegne
1. Consegna la pizza 2. Riceve il pagamento
3.4. SCENARIO 15 Il processo prevede due biforcazioni. La prima riguarda il cliente, le cui azioni variano a seconda che riceva un avviso di mancata disponibilità o che invece riceva la pizza. Per rappresentare la biforcazione utilizziamo una porta, in particolare una porta basata su eventi, in quanto la ricezione del messaggio o della pizza possono essere interpretate come eventi intermedi di ricezione di un messaggio.
Nelle attività della pizzeria, invece, incontriamo una biforcazione in relazione alla verifi-ca della disponibilità della pizza. Anche in questo verifi-caso utilizziamo una porta, in particolare però si tratta di una porta esclusiva, in quanto le attività successive dipendono dal risultato dell’attività di verifica attribuito al cassiere.
Gli scambi di messaggi e oggetti fra i due gruppi devono essere resi come flussi di messaggi. La notifica BPMN infatti richiede che fra due gruppi distinti ci siano solo flussi di messaggi.
La Figura 3.6 mostra il diagramma completo che rappresenta l’attività appena descritta.
Figura 3.6: Diagramma BPMN 2.0 che rappresenta l’ordine di una pizza
3.4
Scenario
La notazione BPMN 2.0 fa corrispondere al modello grafico del diagramma un modello basato su XML. L’esempio precedente (ordinare una pizza) può essere visualizzato anche nella sua forma XML (di cui proponiamo unicamente un estratto):
16 CAPITOLO 3. BPMN 2.0
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g =" UTF -8"? >
< d e f i n i t i o n s x m l n s =" h t t p :// www . omg . org / s p e c / B P M N / 2 0 1 0 0 5 2 4 / M O D E L " x m l n s : xsi =" h t t p :// www . w3 . org / 2 0 0 1 / X M L S c h e m a - i n s t a n c e " x m l n s : xsd =" h t t p :// www . w3 . org / 2 0 0 1 / X M L S c h e m a " x m l n s : a c t i v i t i =" ht t p :// a c t i v i t i . org / b p m n " x m l n s : b p m n d i =" h t t p :// www . omg . org / s p e c / B P M N / 2 0 1 0 0 5 2 4 / DI " x m l n s : o m g d c =" h t t p :// www . omg . org / s p e c / DD / 2 0 1 0 0 5 2 4 / DC " x m l n s : o m g d i =" h t t p :// www . omg . org / s p e c / DD / 2 0 1 0 0 5 2 4 / DI " t y p e L a n g u a g e =" h t t p :// www . w3 . org / 2 0 0 1 / X M L S c h e m a " e x p r e s s i o n L a n g u a g e =" h t t p :// www . w3 . org / 1 9 9 9 / X P a t h " t a r g e t N a m e s p a c e =" h t t p :// www . a c t i v i t i . org / t e s t " > < c o l l a b o r a t i o n id =" C o l l a b o r a t i o n " > < p a r t i c i p a n t id =" p o o l 2 " n a m e =" C l i e n t e " p r o c e s s R e f =" p r o c e s s _ p o o l 2 " > </ p a r t i c i p a n t > < p a r t i c i p a n t id =" p o o l 3 " n a m e =" P i z z e r i a " p r o c e s s R e f =" p r o c e s s _ p o o l 3 " > </ p a r t i c i p a n t > < m e s s a g e F l o w id =" m e s s a g e f l o w 1 " s o u r c e R e f =" u s e r t a s k 2 " t a r g e t R e f =" m e s s a g e s t a r t e v e n t 1 " > </ m e s s a g e F l o w > [ . . . ] </ c o l l a b o r a t i o n > < p r o c e s s id =" p r o c e s s _ p o o l 1 " n a m e =" p r o c e s s _ p o o l 1 " i s E x e c u t a b l e =" t r u e " > < l a n e S e t id =" l a n e S e t _ p r o c e s s _ p o o l 1 " > < l a n e id =" l a n e 1 " > </ lane > < l a n e id =" l a n e 2 " n a m e =" New l a n e " > </ lane > </ laneSet > </ process > < p r o c e s s id =" p r o c e s s _ p o o l 2 " n a m e =" p r o c e s s _ p o o l 2 " i s E x e c u t a b l e =" t r u e " > < l a n e S e t id =" l a n e S e t _ p r o c e s s _ p o o l 2 " > [ . . . ] </ laneSet > < s t a r t E v e n t id =" s t a r t e v e n t 1 " n a m e =" S t a r t " > </ s t a r t E v e n t > < u s e r T a s k id =" u s e r t a s k 1 " n a me =" S e l e z i o n a una p i z z a " > </ u s e r T a s k > < u s e r T a s k id =" u s e r t a s k 2 " n a me =" O r d i n a la p i z z a " > </ u s e r T a s k > < s e q u e n c e F l o w id =" f l o w 1 " s o u r c e R e f =" s t a r t e v e n t 1 " t a r g e t R e f =" u s e r t a s k 1 " > </ s e q u e n c e F l o w > [ . . . ]
Il modello XML viene utilizzato dai cosiddetti motori BPMN (BPMN engine) per eseguire un’animazione del lavoro collaborativo. L’esecuzione avviene secondo la semantica definita formalmente dal meta-modello di BPMN.
Nell’esempio dell’ordinazione in pizzeria, uno dei possibili scenari di esecuzione corri-spondenti6 è:
• il cliente ha fame (evento iniziale per il partecipante cliente) • il cliente seleziona una pizza
3.5. IL META-MODELLO 17 • il cliente ordina la pizza – un messaggio passa dal cliente alla pizzeria
• il cassiere riceve un ordine (evento iniziale per il partecipante pizzeria) • il cassiere verifica la disponibilità della pizza
• la pizza è disponibile • il pizzaiolo cucina la pizza
• il ragazzo delle consegne recapita la pizza – un messaggio (pizza) passa dalla pizzeria al cliente
• il cliente riceve la pizza (evento intermedio per il partecipante cliente) • il cliente paga la pizza – un messaggio passa dal cliente alla pizzeria
• il ragazzo delle consegne riceve il pagamento – termina il processo per il partecipante pizzeria
• il cliente mangia la pizza – termina il processo per il partecipante cliente
3.5
Il meta-modello
La notazione BPMN 2.0, come già accennato, è descritta formalmente da un meta-modello che definisce le caratteristiche, le relazioni e la semantica operazionale dei suoi elementi.
Il meta-modello, pur dando una descrizione formale di ogni elemento di BPMN, non è completo nella parte relativa alla semantica. La documentazione [41] fa riferimento a una categoria di elementi definiti “non operativi” (non-operational ), per i quali non è possibile definire i dettagli necessari per la loro esecuzione. In questa categoria ricadono, per esempio, i “Manual Task” e gli “Abstract Task”7.
La definizione formale della semantica operazionale di BPMN ne permette l’esecuzione [27] mediante un motore BPMN, che interpreta il modello e “mette in moto” i flussi di lavoro in esso descritti.
La presenza di elementi non operativi fa sì che la realizzazione di un motore BPMN introduca un notevole margine di libertà. Gli elementi non operativi possono essere ignorati o eseguiti in maniera arbitraria. In entrambi i casi l’implementazione di BPMN è parziale e dà luogo a un suo dialetto.
L’Object Management Group ha definito criteri molto rigidi in materia di conformità allo standard BPMN [41]. Per essere conforme a questo standard una sua implementazione deve [28]:
• supportare tutti gli elementi definiti nello standard
• implementare la semantica di tutti gli elementi secondo quanto definito dallo standard
7
Possiamo notare che entrambi i compiti vengono svolti (per loro natura) al di fuori del sistema informatico per il quale sono definite le semantiche di esecuzione.
18 CAPITOLO 3. BPMN 2.0 • eseguire il flusso di lavoro definito secondo lo standard
Nonostante l’impegno dell’OMG per controllare la conformità delle singole implementazioni rispetto alla notazione, rimane ancora molto lavoro da fare per arrivare a una completa e corretta utilizzazione dello standard.
Capitolo 4
Il caso di studio
Il capitolo presenta l’analisi di un caso di studio, per descriverlo ed eseguirlo utilizzando la notazione BPMN 2.0. Il lavoro collaborativo scelto è la presentazione di una domanda di ricostruzione di carriera, un’attività d’ufficio svolta all’interno della Pubblica Istruzione.
Lo scopo dell’analisi è l’individuazione dei concetti e degli elementi che caratterizzano il caso di studio: i ruoli coinvolti, i documenti scambiati e i flussi di lavoro.
4.1
Descrizione
«La ricostruzione di carriera serve a riconoscere i servizi e i benefici al fine di un inqua-dramento giuridico-economico di docenti e personale Amministrativo Tecnico e Ausiliario (ATA).»
L’analisi preliminare, disponibile nell’appendice A, ha individuato gli elementi (ruoli, documenti, flussi, ecc.) del processo originario. Questi hanno fornito la base per un processo di semplificazione e formalizzazione secondo le specifiche di BPMN 2.0.
La domanda di ricostruzione di carriera viene presentata da docenti e ATA dopo l’en-trata di ruolo e il superamento dell’anno di prova e deve essere indirizzata al Dirigente Scolastico (DS) dell’istituto cui ci si rivolge. Il documento ha come allegato obbligatorio l’autocertificazione dei servizi, dove sono elencati i servizi pre-ruolo di durata superiore ai 180 giorni svolti dal richiedente. La domanda viene protocollata dal responsabile del pro-tocollo, per poi essere inviata al Direttore dei Servizi Generali e Amministrativi (DSGA). Questi si occupa di valutare la correttezza del documento prima di inviarlo al DS per la conferma e la firma. Se la domanda di ricostruzione di carriera non presenta errori, viene quindi inviata agli uffici delle Ragionerie dello Stato.
Nel caso in cui un docente o ATA non ricordi i dati esatti di uno dei servizi svolti, può richiedere un certificato di servizio al DSGA dell’istituto interessato, che produrrà prima una nota e poi creerà un certificato di servizio. Questo deve essere approvato e controfirmato dal DS, prima di essere eventualmente inviato al richiedente.
La rielaborazione dell’analisi preliminare ha portato in primis all’eliminazione della nota dalla lista dei documenti. Questa, infatti, nasceva per dare un supporto documentale alla telefonata del docente/ATA alla segreteria della scuola per richiedere un certificato di servizio, quindi per passare da una comunicazione verbale sincrona a una comunicazione
20 CAPITOLO 4. IL CASO DI STUDIO asincrona. Descrivendo il processo di lavoro in BPMN con l’obiettivo di utilizzare una piattaforma software, la nota esaurisce la sua funzione, sostituita dalla comunicazione asincrona propria della piattaforma.
Per quanto riguarda i flussi di lavoro, abbiamo eliminato i passaggi in cui i documenti non venivano modificati o valutati, ma semplicemente “rimbalzavano” da un ruolo all’altro. In questa categoria rientra, per esempio, l’invio iniziale della domanda di ricostruzione di carriera al DS. Oltre ad aver semplificato i flussi, abbiamo aggiunto delle attività per gestire eventuali errori. Se si considera il caso in cui un certificato di servizio non sia approvato dal DS, l’inserimento di un’attività di verifica da parte del DSGA permette di intercettare e correggere errori della segreteria.
4.2
I ruoli
Identifichiamo sei ruoli coinvolti nel lavoro collaborativo: • personale ATA
• docente
• Dirigente Scolastico (DS)
• Direttore dei Servizi Generali e Amministrativi (DSGA) • Ragionerie dello Stato
• responsabile del protocollo
4.3
I documenti
La rielaborazione dell’analisi preliminare mostra che il caso di studio coinvolge tre tipologie di documenti:
• Certificato di servizio
• Autocertificazione dei servizi
• Domanda di ricostruzione di carriera (DRC)
Per tutti i documenti abbiamo individuato un insieme di metadati, ossia di informazioni che permettono di descrivere l’insieme di dati in essi contenuti rendendo possibili funzioni quali la ricerca dei documenti stessi.
4.3.1 Certificato di servizio
Un certificato di servizio è un «documento rilasciato dalla segreteria amministrativa in cui si attesta il servizio svolto all’interno della relativa scuola dal docente o dall’ATA»
Analizzando i dati in esso contenuti abbiamo selezionato le voci che paiono più appli-cabili per una ricerca:
4.4. I FLUSSI DI LAVORO 21 • nome e cognome del docente o dell’ATA
• anno scolastico • sede di servizio • profilo
4.3.2 Autocertificazione dei servizi
L’autocertificazione dei servizi è un «documento in cui il docente o l’ATA riporta i servizi svolti assumendo la responsabilità legale di tale attestazione». Tale documento deve essere necessariamente allegato alla domanda di ricostruzione di carriera.
Trattandosi di un documento unico per ogni dipendente, eventuali ricerche saranno in questo caso svolte dalle segreterie amministrative che hanno in carico la presentazione delle domande di ricostruzione di carriera e dalla Ragioneria di Stato che elabora tali domande. I metadati rilevanti in questo caso sono:
• nome e cognome del docente o dell’ATA
• domanda di ricostruzione di carriera di cui costituisce un allegato
4.3.3 Domanda di ricostruzione di carriera
La domanda di ricostruzione di carriera (DRC) è un «documento con cui il docente o l’ATA richiede l’avvio di una procedura di ricostruzione di carriera» necessaria per «riconoscere i servizi e i benefici al fine di un inquadramento giuridico economico di docenti e personale ATA».
In questo caso valgono essenzialmente le considerazioni fatte per l’autocertificazione dei servizi, quindi identifichiamo come metadati pertinenti:
• nome e cognome del docente o dell’ATA • autocertificazione dei servizi allegata • documentazione allegata
4.4
I flussi di lavoro
Un processo aziendale è costituito da un insieme di attività che possono essere descritte da uno o più flussi di lavoro. Analizzando tali attività, abbiamo deciso di distinguere due diversi flussi di lavoro:
• la richiesta di certificato di servizio
22 CAPITOLO 4. IL CASO DI STUDIO Questa distinzione è data dal fatto che la richiesta di certificato di servizio, pur essen-do una possibile componente necessaria alla presentazione della essen-domanda di ricostruzio-ne di carriera, costituisce un procedimento a parte che deve poter essere messo in atto indipendentemente1.
Per ciascun flusso di lavoro abbiamo descritto il flusso delle attività corrispondenti e lo abbiamo tradotto in un diagramma BPMN 2.0. In questa fase abbiamo deciso di non utilizzare il meccanismo delle swimlane, considerando tutti i ruoli come dipendenti di un’unica azienda Scuola.
4.4.1 La richiesta di certificato di servizio
La richiesta di certificato di servizio viene inviata da un docente/ATA alla segreteria (DSGA) della scuola presso cui ha prestato servizio. Il DSGA crea un certificato di ser-vizio che invia al dirigente scolastico per la valutazione. Se il certificato è corretto, il DS lo approva e il documento è inviato al richiedente. Se invece il certificato di servizio non è approvato dal DS, il documento viene inviato al DSGA che può decidere se modificarlo (correggendo eventuali errori) prima sottoporlo a una nuova valutazione, o se annullare la procedura e inviare un avviso di rifiuto al richiedente.
1. Il richiedente avvia una richiesta di certificato di servizio indirizzata al DSGA 2. Il DSGA riceve una notifica di richiesta di certificato di servizio
3. Il DSGA crea un certificato di servizio 4. Il DSGA invia il certificato di servizio al DS
5. Il DS riceve una notifica di un nuovo certificato di servizio 6. Il DS valuta il certificato di servizio
(a) Se il certificato di servizio è corretto:
• Il DS invia il certificato di servizio al richiedente
• Il richiedente riceve una notifica con il nuovo certificato di servizio (b) Se il certificato di servizio non è corretto:
• Il DS respinge il certificato di servizio
• Il DSGA riceve una richiesta di revisione del certificato di servizio – Se il DSGA decide di revisionare il certificato di servizio
i. Il DSGA modifica il certificato di servizio ii. Il DSGA re-invia il certificato di servizio iii. Si torna al punto 6
– Se il DSGA sceglie di abbandonare il certificato di servizio
i. Il richiedente riceve una notifica di rifiuto del certificato di servizio
1
Un docente o un ATA può non aver bisogno di certificati di servizio per presentare la propria DRC, ma può anche doverne richiedere molteplici in contemporanea.
4.4. I FLUSSI DI LAVORO 23 Il diagramma BPMN corrispondente (Figura 4.1) utilizza due eventi (uno iniziale corrispon-dente al punto 1 e uno finale) e cinque attività svolte da utenti. I due punti di biforcazione (al punto 6 e quello contenuto nel punto 6.b) sono rappresentati da porte esclusive, in quanto entrambe le valutazioni consentono di seguire uno solo dei flussi in base al loro esito.
Figura 4.1: Diagramma BPMN per la richiesta di certificato di servizio
4.4.2 La presentazione della domanda di ricostruzione di carriera
La presentazione della domanda di ricostruzione di carriera è un’attività complessa, che prevede l’invio da parte del docente/ATA dei documenti (domanda di ricostruzione di servizio, autocertificazione dei servizi ed eventuali allegati) alla segreteria dell’istituto. Qui il responsabile del protocollo prende carico della procedura e protocolla i documenti prima di inviarli al DSGA per l’approvazione ed eventuali modifiche. Se il DSGA respinge la documentazione, il richiedente riceve un avviso di rifiuto, altrimenti i documenti sono inviati al DS per la valutazione. Se il dirigente scolastico approva i documenti, questi sono inviati alle Ragionerie dello Stato e il richiedente riceve un avviso di presentazione della domanda. In caso contrario il docente/ATA riceve un avviso di respingimento.
1. Il docente/ATA (richiedente) crea una domanda di ricostruzione di carriera e un’au-tocertificazione dei servizi
2. Il richiedente avvia una presentazione di domanda di ricostruzione di carriera indi-rizzata al DSGA e invia i documenti alla segreteria
3. La segreteria riceve la notifica di una domanda di ricostruzione di carriera da proto-collare
4. Il responsabile del protocollo modifica (protocolla) la domanda di ricostruzione di carriera e l’autocertificazione dei servizi
24 CAPITOLO 4. IL CASO DI STUDIO 6. Il DSGA valuta ed eventualmente modifica l’autocertificazione dei servizi
7. Se l’autocertificazione dei servizi è approvata:
(a) Il DS riceve una notifica di domanda di ricostruzione di carriera da valutare (b) Se la domanda di ricostruzione di carriera è approvata:
• I documenti sono inviati alle Ragionerie dello Stato
• Le Ragionerie dello Stato ricevono una notifica della nuova domanda di ricostruzione di carriera
• Il richiedente riceve una notifica di domanda di ricostruzione di carriera presentata
(c) Se la domanda di ricostruzione di carriera è respinta
• Il richiedente riceve una notifica di domanda di ricostruzione di carriera respinta
8. Se l’autocertificazione dei servizi è respinta:
(a) Il richiedente riceve una notifica di domanda di ricostruzione di carriera respinta Il diagramma per la presentazione di domanda di ricostruzione di carriera (Figura 4.2) utilizza due eventi (uno iniziale corrispondente al punto 2 e uno finale) e sei attività svolte da utenti. Le biforcazioni sono gestite utilizzando due porte esclusive e due porte paral-lele. Le porte esclusive sono utilizzate per i punti 7-8 e 7.b-7.c, mentre quelle parallele rappresentano la contemporaneità dei punti contenuti nel punto 7.b.
Figura 4.2: Diagramma BPMN per la presentazione di una domanda di ricostruzione di carriera
Capitolo 5
Activiti e Alfresco
Il capitolo affronta il panorama tecnologico disponibile per supportare un lavoro collabo-rativo e le scelte compiute in questa tesi.
La prima sezione riporta il processo di identificazione delle tecnologie necessarie. All’in-terno di tali tecnologie si sono compiute scelte ben precise al fine di identificare un insieme di sistemi candidati alla realizzazione di una piattaforma, qui brevemente descritti.
La sezione successiva analizza i diversi sistemi individuati per la realizzazione di una piattaforma software di supporto per il lavoro collaborativo. Il processo di selezione pro-gressiva ha portato a individuare le tecnologie più idonee al raggiungimento di questo fine. Le ultime due sezioni descrivono i due sistemi tecnologici scelti, la loro storia e le caratteri-stiche specifiche. Descriviamo inoltre le modalità generali di utilizzo dei sistemi informatici scelti.
5.1
Lo stato dell’arte
Una piattaforma di supporto per il lavoro collaborativo deve integrare una componente di descrizione e attivazione dei processi come flussi di lavoro e un’altra di memorizzazio-ne e gestiomemorizzazio-ne delle informazioni. Con questa premessa abbiamo individuato memorizzazio-nei motori BPMN 2.0 e nei sistemi ECM le tecnologie più appropriate per la realizzazione di un simile strumento di supporto.
Il mercato attuale offre molte soluzioni per entrambe le tecnologie, rendendo l’indivi-duazione di software candidati quanto mai complessa. Un filtro importante che abbiamo adottato per la ricerca è stato la scelta di utilizzare software open source (OSS). Conside-rato che uno dei fini di questa tesi è la sperimentazione di un sistema di supporto, abbiamo bisogno di strumenti dotati di una licenza gratuita e che consentano l’accesso al codice sorgente e una sua eventuale modifica.
Gli argomenti a favore dell’utilizzo di un OSS non mancano:
• si tratta di strumenti «technologically neutral» [49], che non incontrano problemi di compatibilità con sistemi operativi e altri software in uso
• il mercato degli OSS sta conoscendo negli ultimi anni una forte espansione, con una distribuzione capillare dei suoi prodotti
26 CAPITOLO 5. ACTIVITI E ALFRESCO • l’utilizzo di sistemi open source è diffuso sia in ambito aziendale che governativo in quanto permette una riduzione dei costi e la liberazione dai vincoli dei sistemi proprietari, fornendo nel contempo una spinta all’innovazione [47]
• la Commissione Europea ha stilato una direttiva per promuovere i programmi alter-nativi ai sistemi proprietari1 [47]
La ricerca ha quindi riguardato in prima istanza i motori BPMN 2.0 OS. Anche in questo caso le soluzioni disponibili sono numerose, tali che un’analisi accurata di tutte le possibilità avrebbe richiesto un carico di lavoro eccessivo per gli scopi di questa tesi. Attraverso la consultazione della letteratura [18, 27, 28] e la consulenza di alcuni addetti ai lavori, abbiamo individuato quattro sistemi:
Activiti: supporta tutti gli aspetti del Business Process Management, sia quelli non tecnici (analizzare, modellare e ottimizzare i processi aziendali) che quelli tecnici (creazione di un supporto software). Questo strumento ha come obiettivo un utilizzo quoti-diano dei processi aziendali eseguibili, facilitando i rapporti fra referenti aziendali e sviluppatori, ma anche il suo inserimento in azienda. Activiti non sostituisce tutti gli strumenti esistenti, ma tratta con questa diversità [5]. Questo è possibile perché è costituito da un motore eseguibile in un qualsiasi ambiente Java (e quindi facile da utilizzare per gli sviluppatori Java), che supporta nativamente lo standard BPMN 2.0 [3].
Bonita: è una piattaforma software basata sui processi che permette agli sviluppatori di costruire applicazioni aziendali che possono essere adattate in tempo reale. Bonita permette di disegnare graficamente processi aziendali utilizzando BPMN 2.0. Questi possono essere connessi a sistemi esterni, aggiungendo dati aziendali e disegnando un’interfaccia utente, così che Bonita BPM generi un’applicazione. La piattaforma utilizza un motore leggero e programmato in Java ed è possibile sfruttare la serie completa di API Java e REST per semplificare l’integrazione. Il portale web permette di eseguire i compiti quotidiani e gestire le applicazioni, ma è anche possibile creare un’applicazione completamente personalizzata per gli utenti finali [21] .
camunda BPM: è una piattaforma software per la gestione di flussi di lavoro e processi di business, nata nel 2012 da una biforcazione di Activiti [19, 27]. Consente di modellare ed eseguire BPMN 2.0 per l’automazione dei processi, CMMN 1.1 per la gestione dei casi e DMN 1.1 per la gestione delle decisioni [22]. Il fulcro è un motore per l’esecuzione dei modelli che supporta gli standard OMG. Camunda BPM viene fornito con un insieme di applicazioni che aiutano l’utente a modellare, eseguire e amministrare i processi. Queste applicazioni interagiscono con la REST API pubblica del motore centrale. Si possono creare applicazioni personalizzate che possono a loro volta usare la Java API pubblica del motore centrale [24].
jBPM: è una suite BPM flessibile con caratteristiche di gestione dei processi usabili sia dagli utenti commerciali che dagli sviluppatori. La base di jBPM è un motore di flussi
5.2. CONFRONTO 27
Licenza Definizioni di processi dispiegabili
Framework
Activiti Apache License 2.0 / LGPL 2.1
BPMN 2.0 Java
Bonita LGPL BPMN 2.0 Java
camunda BPM Apache License 2.0 BPMN 2.0, DMN 1.1, CMMN 1.1 Java jBPM Apache License 2.0 BPMN 2.0 Java EE Tabella 5.1: Motori BPMN
di lavoro estendibile, completamente programmato in Java, che permette di eseguire flussi di lavoro descritti nella versione più recente di BPMN. Può essere eseguito in qualsiasi ambiente Java, integrato in una propria applicazione o come servizio [31].
5.2
Confronto
Activiti, Bonita, camunda BPM e jBPM hanno caratteristiche2piuttosto omogenee (Tabel-la 5.1): distribuiti con licenze libere (Apache License 2.0 o LGPL), implementano BPMN 2.0 e sono sviluppati in un framework Java.
Per quanto riguarda l’implementazione di BPMN 2.0, questi sistemi affermano di essere conformi alla notazione. Questa affermazione, però, risulta non essere del tutto corretta. In uno studio del 2015 [27], i risultati di un confronto sulla conformità alla notazione di Activiti, camunda BPM e jBPM ponevano jBPM in coda alla classifica. Il software risultava implementare un numero maggiore di elementi BPMN 2.0, ma in maniera gene-ralmente più parziale rispetto agli altri concorrenti. Al contempo camunda BPM risultava più conforme alla notazione, implementando tutte le funzionalità messe a disposizione da Activiti, insieme ad altre. Attualmente le differenze fra questi ultimi due sono aumentate, con l’individuazione da parte di Activiti di due errori sfuggiti a camunda BPM [28].
L’adesione agli standard è un fattore primario per la realizzazione di una piattaforma, in quanto aumenta il livello di interoperabilità del sistema e facilita la collaborazione del-l’azienda/organizzazione che lo utilizza con eventuali enti esterni. Abbiamo quindi deciso di abbandonare l’opzione jBPM e di concentrarci su Activiti, Bonita e camunda BPM.
Un altro aspetto da tenere in considerazione è la possibilità offerta agli utenti di creare e utilizzare i propri flussi di lavoro attraverso interfacce. Activiti è dotato di un’applicazione web che comprende queste funzionalità, seppure mettendo a disposizione un modellatore BPMN molto essenziale3. Il software fornisce un plugin per l’ambiente di sviluppo (IDE) Eclipse, dando una maggiore libertà di azione ai programmatori. Bonita BPM ha inserito lo strumento di modellazione all’interno della sua applicazione desktop Bonita Studio. I flussi di lavoro sono eseguiti dal motore all’interno dell’applicazione web, che è la stessa che
2I dati sono stati raccolti attraverso la documentazione messa a disposizione dalle aziende stesse [4, 20,
23, 32].
28 CAPITOLO 5. ACTIVITI E ALFRESCO permette la creazione di tipi di dati e form associati alle singole attività. Camunda, invece, ha abbandonato Eclipse per non essere legata a continui aggiornamenti. In cambio offre quattro diverse interfacce utente (modellazione, elenco delle attività, amministrazione dei processi e monitoraggio) sotto forma di applicazione desktop [19].
Activiti, Bonita BPM e camunda BPM sono strumenti validi per il supporto di un lavoro collaborativo. Analizziamo quindi come questi motori per i flussi di lavoro si integrino all’interno di soluzioni per la gestione dell’informazione aziendale (ossia gli ECM).
Activiti è un progetto supportato dalla Alfresco Software, che ne distribuisce la versione enterprise [19] ed è l’azienda di provenienza di metà del team di organizzazione4. Alfresco ha fra i suoi prodotti principali un sistema ECM che integra al suo interno il motore BPMN Activiti. Il sistema è distribuito in due versioni:
Alfresco One è la distribuzione enterprise, a pagamento. Si tratta di un sistema ibrido (sfrutta anche la tecnologia cloud ) per la gestione di informazione non strutturata e di processi di lavoro (potenzialità estese con l’integrazione di Alfresco Activiti BPM), integrabile con alcuni degli strumenti più diffusi e utilizzati (Microsoft Office, Google Docs, Microsoft Outlook per citarne alcuni). Alfresco One supporta i principali standard aperti e mantiene l’accessibilità del codice, permettendo un’ampia gamma di personalizzazioni sulla base delle necessità dell’azienda [9]. Fra i servizi offerti è centrale quello di supporto, particolarmente potente in Europa grazie alla ricca rete di collaboratori [35].
Alfresco Community Edition è la distribuzione open source del sistema, mantenuto da un’ampia comunità di volontari con interventi contenuti da parte dell’azienda. Le funzionalità fondamentali di gestione delle informazioni e dei processi di lavoro si mantengono, anche se richiedono maggiori competenze informatiche. L’integrazione con strumenti quali Microsoft Office e Google Docs è preservata, inoltre si ha la possibilità di estendere la piattaforma con moduli prodotti dalla comunità stessa [7]. Nel caso di camunda BPM l’integrazione con un sistema ECM è possibile ma appare meno immediata. Consultando le discussioni sull’argomento sia nei blog ufficiali [37, 38], sia nei forum [1, 2], è risultato che le possibili integrazioni sono sempre di competenza di chi vuole utilizzare questi software, creando gli opportuni collegamenti da codice. Se da una parte questa soluzione garantisce un’estrema libertà per aziende e sviluppatori, dall’altra rende il compito di creare una piattaforma per il supporto del lavoro collaborativo ancor più gravoso.
Anche Bonita BPM permette l’integrazione con un sistema ECM attraverso specifici connettori. La lista di sistemi integrabili con i connettori riportata nella documentazione comprende strumenti di varia natura, compresi database e social media (Twitter). Risulta interessante la presenza di una connessione con Alfresco, tuttavia la connessione è riferita a vecchie versioni dello strumento (Alfresco 3.4 e Alfresco 4.2) e presenta una serie di limita-zioni (per esempio, per cancellare una cartella su Alfresco utilizzando Bonita è necessario che la cartella sia vuota) e conflitti fra le diverse librerie.
5.3. ACTIVITI 29 Le presenti considerazioni sul rapporto con i sistemi di gestione dei contenuti aziendali ci hanno portati a prediligere l’utilizzo combinato di Alfresco Community Edition e di Activiti, in quanto il motore BPMN scelto è integrato nativamente nel sistema ECM. Utilizzeremo in particolare il plugin di Activiti per Eclipse, dato che la versione open source di Alfresco manca di uno strumento di modellazione integrato.
5.3
Activiti
Nel maggio 2010 la Alfresco Software annuncia ufficialmente [8] un nuovo progetto nel set-tore del BPM: Activiti. Le prime notizie su questo software risalgono a pochi mesi prima, quando Tom Baeyens e Joram Barrez5 annunciano di aver abbandonato il progetto JBoss jBPM per creare una nuova piattaforma distribuita con licenza Apache che implementi na-tivamente BPMN 2.0 [17]. Un progetto ambizioso che può contare sull’esperienza acquisita nello sviluppo di jBPM, come infatti evidenziato dalla scelta di numerare con 5 la prima versione di Activiti, a ribadire l’eredità delle versioni da 1 a 4 di jBPM.
Activiti ha come obiettivo esplicito la realizzazione di una piattaforma BPM che imple-menti BPMN 2.0 e che fornisca un terreno condiviso a tutti gli attori di un’azienda, siano essi tecnici o meno. Consapevoli della necessità e delle potenzialità date dall’integrare un simile motore BPM nei software utilizzati in un’azienda, gli sviluppatori si sono impegnati affinché la piattaforma fosse in grado di lavorare in “qualsiasi” ambiente Java [5].
La piattaforma si compone di tre parti [3]:
Activiti Engine è un motore di processo Java che esegue nativamente processi descritti come flussi di lavoro BPMN 2.0.
Activiti Explorer è un’applicazione web che permette di utilizzare il motore Activiti, ossia permette di disegnare un flusso di lavoro, dispiegarlo, metterlo alla prova con degli utenti diversi e tener memoria dei resoconti di queste elaborazioni
Activiti Designer è un plugin di Eclipse che permette di disegnare e programmare un flusso di lavoro all’interno del proprio ambiente IDE
Uno degli obiettivi di questa tesi è quello di utilizzare Activiti in combinazione con Alfre-sco Community Edition. Poiché il motore per i flussi di lavoro è integrato nella piattafor-ma ECM dell’intera distribuzione software di Activiti, utilizzeremo unicamente l’Activiti Designer6.
Lo strumento permette di creare un nuovo diagramma (Figura 5.2) utilizzando gli ele-menti BPMN raccolti nella “Palette” situata sulla destra: è sufficiente trascinarli nell’area di lavoro secondo le necessità. In basso si trova la finestra delle “Properties”, da cui è possibile personalizzare le proprietà del processo e dei suoi singoli elementi.
Consideriamo un flusso di lavoro basilare costituito da un evento iniziale “StartEvent”, un evento finale “EndEvent” e un’attività/compito dell’utente “UserTask”, uniti da due
5
Baeyens era fondatore e architetto del progetto JBoss jBPM, mentre Barrez era un suo collaboratore [8].
6
Alfresco nella sua versione open source non fornisce uno strumento di modellazione interno alla piattaforma.
30 CAPITOLO 5. ACTIVITI E ALFRESCO
Figura 5.1: Activiti Designer, creazione di un nuovo progetto
5.4. ALFRESCO COMMUNITY EDITION 31 “SequenceFlow”. Selezionando l’attività, la scheda delle proprietà “Main config” contiene
Figura 5.3: Activiti Designer, esempio di flusso di lavoro
molte caratteristiche fondamentali per il corretto funzionamento del flusso. In particolare notiamo (Figura 5.3):
Assignee, Candidate users, Candidate groups permettono di definire chi deve svol-gere quel compito, in particolare se si tratta di una singola persona (laddove persona indica un utente), di una fra più persone o di uno fra più gruppi.
Form key per collegare un’attività a un modulo da presentare nell’interfaccia attraverso l’identificativo associato al modulo stesso.
Questa interfaccia grafica di Eclipse può essere utilizzata anche da parte di chi non è uno sviluppatore per realizzare dei modelli di flusso di lavoro, in particolare se volti a descrivere i processi per una documentazione. Ulteriori schede delle proprietà permettono anche ai programmatori di intervenire inserendo degli script. Tuttavia, per estensioni ulteriori può essere preferibile lavorare direttamente a livello di codice.
Con Eclipse è possibile aprire ed elaborare un file BPMN utilizzando un editor XML. Lo stesso flusso di lavoro utilizzato precedentemente come esempio, corrisponde al file di codice presentato nella Figura 5.4.
5.4
Alfresco Community Edition
L’idea di Alfresco Community Edition nasce nel 2004 da John Newton e John Powell7, i quali erano rimasti colpiti dal fatto che le aziende software in maggiore crescita apparte-nessero al panorama open source [48]. Insieme delineano il progetto di un sistema ECM open source basato sugli open standard, che abbia le caratteristiche di una piattaforma di livello enterprise.
7
Si tratta dei co-fondatori di Alfresco, in particolare Newton è il CTO di Alfresco, mentre Powell è stato CEO e continua a far parte del Consiglio di Amministrazione dell’azienda.
32 CAPITOLO 5. ACTIVITI E ALFRESCO
Figura 5.4: Activiti Designer, modello aperto con un editor XML
La scommessa di Newton e Powell porta allo sviluppo di un nuovo tipo di sistema ECM che fa la sua comparsa sul mercato nel 20068, con risultati nettamente superiori
alle aspettative. Ad oggi Alfresco rimane uno dei sistemi di alto livello nel settore, tanto da rientrare nelle analisi di Gartner [35] in qualità di precursore (si veda la Figura 5.5). La forza riconosciuta a questo ECMS è quella di aver mantenuto una forte sensibilità alle necessità del mercato, aggiungendo di volta in volta le caratteristiche più idonee a supportare il lavoro dei suoi utenti.
Figura 5.5: Gartner Magic Quadrant for ECM, ottobre 2015
