Una metodologia di analisi e confronto per strumenti BPM

More documents

Recommendations

Info

28 Capitolo 2. Stato dell’Arte 3. l’esecutore del task: l’agente che sta eseguendo un task. Grazie al modello organizzativo appena descritto, un WfMS èingrado di assegnare task ai vari partecipanti del workflow in fase di esecuzione. Questo assegnamento può essere effettuato sia mediante uno scheduler, dove l’engine dello scheduler assegna il task al miglior partecipante disponibile del ruolo associato al task secondo la policy di assegnamento, oppure viene fatto direttamente da un utente. Nel primo caso si parla di assegnamento automatico dei task; nel secondo caso si parla assegnamento manuale che potrebbe essere assistito dal calcolatore nell’identificazione delle priorità e dei casi critici). La necessità dientrambelemodalità di assegnamento dei task emerge in tutte quelle situazioni in cui il task viene assegnato ad un gruppo di partecipanti e, allo stesso tempo, non vi è il bisogno di schedulare in anticipo chi deve eseguire quel determinato task. Sistemi di gestione di workflow (WfMS) In questo paragrafo descriveremo la struttura di un sistema di gestione di workflow. Una generica architettura di sistema di gestione dei workflow permette di gestire i vari sottosistemi necessari per la progettazione e l’attuazione dei workflow sia di sistema che quelli ad interazione umana (fig. 2.14). L’architettura contiene i seguenti sottosistemi e ruoli: Figura 2.14: Schema base di un workflow management system
2.2. Business Process Management 29 • Workflow Modelling che fornisce i mezzi per poter modellare i processi di business. • Workflow Model Repository che si occupa di immagazzinare i modelli di workflow che sono stati creati. • Workflow Engine è responsabile del’attuazione dei processi di workflow. Esso in particolare permette la creazione e l’attuazione di un’istanza di workflow quando questa viene richiesta. Il workflow engine si comporta diversamente in base alla tipologia di workflow che deve istanziare. Nel caso di workflow di sistema esso manda avanti il flusso di workflow secondo quanto è stato definito nel modello di workflow, occupandosi direttamente del trasferimento di dati tra le applicazioni coinvolte nel processo. Nel caso invece di workflow ad interazione umana, l’istanza di workflow contiene sia applicazioni invocate automaticamente sia interazioni umane. Queste interazioni umane vengono eseguite utilizzando una Graphical User Interface. Inoltre la conoscenza delle abilità e delle competenze dei partecipanti al processo permette al workflow engine di assegnare correttamente i task a chi ha le competenze per portarlo a termine. L’architettura sopra descritta è un modello generico di architettura dei wfms. Una descrizione più completaè stata fornita dalla Workflow Management Coalition, la quale descrizione è diventata un punto di riferimento nella progettazione di questo tipo di architetture. La figura 2.15 illustra i vari componenti di questa architettura di riferimento. Il componente centrale di questa architettura è il Workflow Enactment Service che nella terminologia del WfMC rappresenta il Workflow Engine prima descritto. Quest’ultimo comunica con gli altri sottosistemi per mezzo di interfacce. Il sottosistema Process Definition Tools rappresenta gli strumenti per mezzo i quali è possibile modellare i processi. Esso è connesso al Workflow Enactment Service per mezzo dell’Interfaccia 1. L’obiettivo di tale interfaccia è di permettere agli strumenti di modellazione prodotti dai vari vendors di rappresentare i processi di business in una forma standard. In particolare l’interfaccia suggerisce l’utilizzo di un linguaggio basato su XML chiamato XPDL, XML Process Definition Language. Definiremo più avanti questo tipo di linguaggio. Il sottosistema Workflow Client Applications permette l’interazione con i partecipanti umani del processo quando viene attivato un workflow ad interazione umana. L’obiettivo dell’interfaccia 2 è quello di permettere la comunicazione delle applicazioni client di vendors differenti con il Workflow Enactment Service. Il sottosistema Invoked Applications rappresenta l’insieme di applicazioni che permettono di svolgere specifici task
Page 1: POLITECNICO DI MILANO Facoltà di I
Page 5: A Martina
Page 9: Sommario Il Business Process Manage
Page 13 and 14: Indice Abstract I Sommario III Ring
Page 15: 6.2.4 Conformità agli standard BPM
Page 18 and 19: 2 Capitolo 1. Introduzione Fattori
Page 20 and 21: 4 Capitolo 1. Introduzione opiù wo
Page 22 and 23: 6 Capitolo 1. Introduzione
Page 24 and 25: 8 Capitolo 2. Stato dell’Arte 2.1
Page 26 and 27: 10 Capitolo 2. Stato dell’Arte Fi
Page 28 and 29: 12 Capitolo 2. Stato dell’Arte ni
Page 30 and 31: 14 Capitolo 2. Stato dell’Arte Ne
Page 32 and 33: 16 Capitolo 2. Stato dell’Arte
Page 34 and 35: 18 Capitolo 2. Stato dell’Arte mo
Page 36 and 37: 20 Capitolo 2. Stato dell’Arte 1.
Page 48 and 49: 32 Capitolo 2. Stato dell’Arte so
Page 50 and 51: 34 Capitolo 2. Stato dell’Arte Se
Page 54 and 55: 38 Capitolo 2. Stato dell’Arte e
Page 56 and 57: 40 Capitolo 2. Stato dell’Arte if
Page 58 and 59: 42 Capitolo 3. Standard degli Strum
Page 94 and 95:
78 Capitolo 3. Standard degli Strum
Page 96 and 97:
80 Capitolo 4. Analisi degli Strume
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
100 Capitolo 4. Analisi degli Strum
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
130 Capitolo 5. Valutazione dei Sin
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
show all

Una metodologia di analisi e confronto per strumenti BPM

Create successful ePaper yourself

Delete template?

Save as template?