Sinibaldi bpm
- 1. Business Process Management ( a cura di Alessandro Sinibaldi – CISSP, Assistente CC, MCSE: Security, CEH, OCP, CWSP, ... ) 24 febbraio 2009 Pag. 1
- 2. INDICE DELLA PRESENTAZIONE : 1. Cosa sono i processi e cosa è il BPM 2. Documentare i processi 3. Workflow 4. Modelli di processo 5. BPM e SOA 6. Livelli di Maturità 7. Ridisegnare i processi 8. Scegliere il BPMS 9. Consigli e raccomandazioni 10. Bibliografia 24 febbraio 2009 Pag. 2
- 3. Definizioni Business Process Un processo è un insieme di attività correlate che hanno complessivamente un obiettivo comune come, ad esempio, la produzione di un bene o di un servizio o, più in generale, la creazione di valore per il cliente Business Process Management Il Business Process Management è un approccio strutturato basato su metodi, policy, metriche, practice di management per gestire ed ottimizzare continuamente le attività ed I processi di un’organizzazione. Business Process Management System Il Business Process Management System (BPMS) è la suite che include i moduli funzionali, tecnologici e le infrastrutture a supporto, integrati in uno specifico ambiente, fornendo tutte le funzionalità della tecnologia BPM. 24 febbraio 2009 Pag. 3
- 4. Le fasi di processo L’obiettivo del BPM è gestire il ciclo di vita di un processo, a partire dalla modellazione fino all’ottimizzazione. Il ciclo di vita del processo richiede il coinvolgimento di ruoli aziendali con competenze differenti tra loro (es.business analyst, IT developer) Modeling Optimization • Documentazione e disegno del processo • Identificazione degli obiettivi di business e • Identificazione delle aree i KPI di miglioramento • Identificazione dei modelli • Quantificazione dei benefici ottenuti Simulation • Valutazione di qual è il miglior modello da implementare sulla base dei dati di monitoraggio di Monitoring precedenti esecuzioni di processo e dei KPI • Definizione delle grandezze relative al processo misurato (es. numerosità di reclami, durata del processo, numerosità dei difetti, etc.) Implementation • Valutazione di cosa funziona e cosa no Deployment/Execution • Traduzione di ogni step del • Misurazione dei KPI modello scelto in procedure • Esecuzione del processo nelle sue operative (es. chiamate a web fasi operative services, compilazione di form, etc.) 24 febbraio 2009 Pag. 4
- 5. Ciclo di vita di un processo...musicale Disegno del Implementazione Esecuzione Monitoraggio processo 24 febbraio 2009 Pag. 5
- 6. Le tre dimensioni del BPM Management Management Architecture È la dimensione del Coordinamento. Il suo scopo è abilitare, cioè rendere possibile l’esecuzione di un processo, mettendo a disposizione le risorse, gli skills e quant’altro sia necessario Un Processo è una catena del Valore che può attraversare differenti ambiti funzionali, differenti imprese e differenti Business business Valore Architecture È la dimensione del Business, cioè quella che dà gli obiettivi e gli scopi ai processi Trasformazione Process È la dimensione del Processo, cioè quell’insieme di attività coordinate, che trasforma input Architecture in output producendo Valore. I suoi obiettivi sono l’efficacia, cioè la capacità di eseguire un compito ottimizzando le risorse a disposizione, la trasparenza, cioè la capacità di avere chiaro l’intero flusso del processo, senza zone d’ombra, e infine l’agilità che dà la capacità di reagire velocemente al cambiamento 24 febbraio 2009 Pag. 6
- 7. Le tre dimensioni del BPM La business architecture è la rappresentazione di come un’organizzazione definisce se stessa in termini del suo ruolo e dei suoi scopi, e di come essa intende la creazione del Valore. Ogni organizzazione definisce i suoi obiettivi di business di alto livello e crea una struttura organizzativa come struttura base per raggiungere i suoi obiettivi. L’organizzazione definisce le relazioni interne di questa struttura e il modo in cui avviene l’interazione con i clienti, gli shareholders e gli stakeholders. La process architecture è la rappresentazione testuale o diagrammatica della catena del valore e dei processi di business che operano attraverso l’organizzazione. Essa include sia i processi operativi core che quelli a supporto del management. Una process architecture mostra chiaramente dove viene generato il Valore e come i processi operativi sono riferiti e allineati alle strategie e agli obiettivi dell’organzzazione La management architecture include il project management, il process management e il process improvement e definisce come il management impiega le risorse disponibili per raggiungere gli obiettivi di business. La technology architecture comprende l’insieme delle componenti tecnologiche che supportano gli obiettivi funzionali e le leve di business. Essa deve essere sufficientemente flessibile da permetetre una rapida riconfigurazione dell’IT a fronte delle mutate esigenze di business. SOA è un esempio di technology architecture che permette il riutilizzo dei componenti IT. 24 febbraio 2009 Pag. 7
- 8. BPM: le motivazioni 24 febbraio 2009 Pag. 8
- 9. BPM: i benefici 24 febbraio 2009 Pag. 9
- 10. BPM: classificazione Il focus è su attività automatizzate che tuttavia richiedono una forte interazione umana (es.call center Richiedono fortemente la operativi, customer services, presenza di persone che, People etc.)* interagendo con i sistemi tramite opportune interfacce intensive grafiche e collaborando tra Il focus è sui processi che loro, devono continuamente richiedono ai dipendenti decisioni prendere decisioni su quali critiche utilizzando informazioni e azioni adottare* regole di business; si tratta di Human Decision processi per cui i criteri di decisione e le regole di processo intensive intensive cambiano frequentemente. * Fanno un uso molto elevato di documenti cartacei, che devono essere inseriti nel sistema, BPM Document modificati o approvati, trasformati intensive in formati elettronici diversi o derivanti dal riempimento manuale di forms elettronici* Coinvolgono tipicamente un numero giornaliero Il focus è su processi di transazioni molto elevato System Integration automatizzati che integrano che abbracciano sistemi ed applicazioni, con una intensive intensive limitata interazione umana, un l’integrazione tra più sistemi, con un coinvolgimento basso numero di eccezioni ed un pressoché nullo da parte elevato numero di transazioni da delle persone* * Fonte: Forrester Wave™: Human-Centric BPM For Java Platforms, Q3 ’07 gestire.* 24 febbraio 2009 Pag. 10
- 11. Funzionalità dei BPMS I vari prodotti di mercato, in base al tipo di processo verso cui sono orientati, forniscono funzionalità differenti: Processo Caratteristiche tecniche BPM • Strumenti di integrazione • Gestione delle transazioni • Modellazione dei processi - Integration Intensive - • Monitoraggio e reportistica - • Ambiente di sviluppo per le applicazioni • Gestione del Ciclo di Vita • Orientato a SOA • Lista dei task assegnati • Portale a supporto del workflow di lavorazione People/Decision • Gestione dell’organigramma Intensive • Forms di inserimento/modifica • Integrazione con Applicazioni packaged (es.CRM, ERP, etc.) • Supporto nativo per la scansione, il riconoscimento (OCR) e la gestione dei documenti • Lista dei task Document Intensive • Portale a supporto del workflow • BPM venduto separatamente dalla piattaforma di Enterprise Content Management 24 febbraio 2009 Pag. 11
- 12. I livelli di maturità del BPM 24 febbraio 2009 Pag. 12
- 13. Un pò di storia: l’EAI 1/6 Un insieme di applicazioni monolitiche interagiscono attraverso vari tipi di interfacce. Ognuna è dotata del suo sistema di controllo degli accessi, la sua interfaccia utente, persistenza dei dati e logica di business. Problemi: •Elevata complessità e ridondanza •Difficoltà nella manutenzione di lungo periodo •Interfacce spesso proprietarie •Inconsistenza dei dati •Dipendenze fuori controllo •Complessità crescente esponenzialmente all’aumentare delle dimensioni del sistema Soluzione – primo step: Esternalizzare e mettere a fattor comune le aree condivise per •Lo scambio dati •Il controllo degli accessi (Single Sign On) •La persistenza dei dati 24 febbraio 2009 Pag. 13
- 14. Un pò di storia: l’EAI 2/6 L’adozione di un’area di scambio condivisa (middleware) con interfacce standard e di adattatori verso le applicazioni permette di •velocizzare le operazioni di scambio dati e trasformazione •Uniformità nello scambio dei messaggi •Trasparenza delle applicazioni relativamente ai vari formati utilizzati dalle applicazioni, alla loro collocazione fisica, alle tecnologie adoperate e al piano di indirizzamento di rete •Possibilità di instradare i messaggi sulla base di regole di business 24 febbraio 2009 Pag. 14
- 15. Un pò di storia: l’EAI 3/6 Portare l’interfaccia utente e il controllo degli accessi all’esterno permette di avere applicazioni: •Indipendenti dal tipo di interfaccia utente (web, palmare, sms ecc.) •Indipendenti dalla posizione dell’utente •Indipendenti dall’interfaccia •Consistenti nella presentazione dei dati all’utente (stesso look-and-feel, stessa logica di interfaccia ecc.) •Consistenti nell’applicazione e nella messa a punto delle policy di accesso •Single sign on 24 febbraio 2009 Pag. 15
- 16. Un pò di storia: l’EAI 4/6 La presenza di un’area di persistenza condivisa: •Facilita la sincronizzazione dei dati (dati in real- time) •Aumenta la consistenza e diminuisce la ridondanza (data warehouse) •Diminuisce gli sforzi di gestione •Facilita il recovery •Permette la virtualizzazione 24 febbraio 2009 Pag. 16
- 17. Un pò di storia: l’EAI 5/6 Il passo successivo è la messa a fattor comune della Business Logic. Business Process Management: flessibilità nella definizione e nella manutenzione dei processi Business Activity Monitoring: controllo in tempo reale dello stato del business Event processing: reagire in modo proattivo ad eventuali colli di bottiglia; correlare gli eventi rivelati per generare nuovi eventi 24 febbraio 2009 Pag. 17
- 18. Un pò di storia: l’EAI 6/6 Il passo successivo è la decentralizzazione della logica di Business, che viene portata al livello del cliente, il quale può così comporre servizi e processi provenienti da vari fornitori in modo personalizzato. 24 febbraio 2009 Pag. 18
- 19. Documentare i processi I processi si dividono in: •Processi strategici •Processi competitivi: processi con cui l’organizzazione compete sul mercato e con i quali mira a superare la concorrenza (es. fidelizzazione del cliente, elaborazione strategie, individuazione delle esigenze del cliente) •Processi di innovazione e trasformazione: processi che forniscono le capacità richieste per il futuro (es. innovazione prodotti/servizi, investimenti strategici) •Processi operativi: processi che realizzano i prodotti/servizi dell’organizzazione (es. gestione marketing e vendite, produzione/erogazione servizi, gestione della logistica) •Processi di supporto: processi che aggiungono efficienza ed efficacia ai processi operativi (es. gestione risorse umane, gestione finanza e amministrazione, gestione servizi IT) 24 febbraio 2009 Pag. 19
- 20. Documentare i processi Nell’analisi dei processi aziendali è importante raccogliere le seguenti informazioni: •definire lo scopo del processo; •definire il responsabile del processo; •stabilire inizio e fine del processo (delimitazione del processo); •identificare il cliente del processo; •specificare l’output del processo; •definire gli input del processo; •definire i fornitori degli input; •verificare i vincoli, le leggi e i regolamenti; •stabilire i controlli da effettuare; •identificare le infrastrutture necessarie per produrre l’output; •identificare le risorse umane necessarie e i livelli di competenza richiesti; •identificare i sottoprocessi; •evidenziare se l’output del processo costituisce l’input per un altro processo. 24 febbraio 2009 Pag. 20
- 21. Documentare i processi: Diagramma SIPOC Chi usufruirà Quali sono i Chi fornisce gli input Quali sono gli input Quali sono gli output degli output del al processo? del processo? del processo? requisiti del processo? processo? Suppliers Inputs Process Outputs Customers Requirements See Below Step 1: Step 2: Step 3: Step 4: Step 5: 24 febbraio 2009 Pag. 21
- 22. Documentare i processi: Matrice delle dipendenze l’elemento Pij della matrice rappresenta il fatto che l’ouput del processo Pj alla colonna j è utilizzato come input dal processo Pi alla riga i. Oltre a ciò, vengono anche aggiunte tante colonne quanti sono gli eventuali processi En, esterni al sistema, il cui output è utilizzato come input da almeno un processo del sistema. 24 febbraio 2009 Pag. 22
- 23. Documentare i processi: Diagramma DEMO Un processo di Business è rappresentato, nella sua forma fondamentale, dal fatto che “qualcuno chiede a qualcun altro di fare qualcosa in cambio di qualcos’altro”. Questa definizione di processo di business pone l’accento sull’aspetto sociale. In tal senso un’organizzazione può essere definita come un sistema sociale, composta da individui che interagiscono tra loro rivestendo dei ruoli e seguendo norme e valori. La metodologia Demo (Dynamic Essential Modeling of Organizations), inventata da Dietz (1992), analizza i processi di business di un’organizzazione in termine di interazioni tra i membri dell’organizzazione e tra questi e soggetti esterni. Il concetto chiave in Demo è quello di Transazione di Business, che è sostanzialmente l’interazione di base tra due soggetti, o Attori, un Iniziatore, o cliente, e un Esecutore, o fornitore, in cui il primo richiede qualcosa e il secondo la fa. La metodologia DEMO distingue l’essenza dei processi di Business (il Cosa? faccio) dalla loro realizzazione (il Come? e il Chi?). Così da una parte avremo il modello di Business, detto anche modello Essenziale, vero e proprio, dall’altra il modello Informativo/Documentale e il modello Organizzativo. Con questa suddivisione, i tre possono evolvere separatamente. 24 febbraio 2009 Pag. 23
- 24. Documentare i processi: Diagramma DEMO Una Transazione di Business è composta da tre fasi. La prima (O-phase o Order-phase) e la terza (R- request “puoi fare questo?” phase o Result-phase) sono fasi di Interazione O-phase perchè coinvolgono entrambi i soggetti che (interazione) promise interagiscono, appunto, tra loro. Nella O-phase “ok, lo faccio” l’Iniziatore chiede all’Esecutore di fare qualcosa I E (request) e l’Esecutore accetta (promise). Nella seconda fase (E-phase o Execution phase) l’Esecutore compie quanto richiestogli. Questa fase è, quindi, una fase di Azione e coinvolge E-phase execution Lo faccio solo l’Esecutore. (azione) Nella terza e ultima fase, la R-phase, Iniziatore e E Esecutore interagiscono nuovamente. L’Esecutore afferma di aver compiuto l’attività (state) e l’Iniziatore prende atto dell’avvenuta esecuzione (accept). Le sottofasi di interazione (request, promise, state “ok, l’ho fatto!” state e accept) sono chiamate anche azioni R-phase intersoggettive e rappresentate graficamente (interazione) “bene, vedo che lo hai fatto” accept come un cerchio, mentre le sottofasi di I E esecuzione (esecuzione) azioni oggettive e rappresentate graficamente come rombi. La transazione, che è composta sia di azioni che di interazioni, è rappresentata, a sua volta, come un rombo dentro un cerchio. 24 febbraio 2009 Pag. 24
- 25. Documentare i processi: Diagramma DEMO Transazione Iniziatore Esecutore Fasi Descrizione T1 Cliente Albergatore T1/O “Ci sono camere disponibili?” T1/E L’albergatore consulta il registro T1/R “si, ci sono” T2 Cliente Albergatore T2/O “posso prenotare una camera?” T2/E L’albergatore segna la prenotazione nel registro T2/R “la sua camera è prenotata” 24 febbraio 2009 Pag. 25
- 26. Documentare i processi: BPMN La Business Process Management Initiative (BPMI) ha sviluppato una Business Process Modeling Notation (BPMN) (http://www.bpmn.org/) . La versione 1.0 è stata rilasciata nel 2004. BPMN definisce un Business Process Diagram (BPD), che rappresenta un adattamento della tecnica dei diagrammi di flusso alla descrizione dei processi di business. Un Business Process Model è una rete di oggetti grafici che rappresentano le attività e i controlli di flusso rappresentano l’ordine di esecuzione. In un BPD ci sono 4 categorie di elementi possibili: •Flow Objects sono gli oggetti di base (eventi, attività ecc.) •Connecting Objects connettono i Flow Objects per rappresentare la struttura del processo •Swimlanes Sono come dei “raccoglitori” che permettono di raggruppare le attività in categorie visuali separate per mostrare diversi ambiti di responsabilità o ambiti funzionali •Artifacts Forniscono informazioni su come documenti, dati e altri oggetti sono usati e aggiornati in un Processo. 24 febbraio 2009 Pag. 26
- 27. Documentare i processi: BPMN Paziente Chiede Riceve appuntamento al Enuncia i sintomi Riceve la ricetta Va in farmacia l’appuntamento dottore Sopraggiunge la malattia 1) voglio vedere il dottore 5) va dal dottore 6) mi sento male Segretaria Riceve la Controlla la Riceve la Fissa un Conferma richiesta di disponibilità disponibilità appuntamento l’appuntamento appuntamento Ambulatorio 2) sei disponibile? 3) sono disponibile 4) faccio la prenotazione Dottore Riceve la Risponde alla Prende atto Prende atto dei richiesta di Prepara la ricetta richiesta dell’appuntamento sintomi disponibilità 24 febbraio 2009 Pag. 27
- 28. Documentare i processi: BPEL BPEL (Business Process Execution Language) è un linguaggio di markup, ideato per l’esecuzione dei processi, particolarmente orientato all’interazione coi web services e al calcolo distribuito, con supporto alle transazioni. Un'applicazione BPEL viene invocata come Web service ed interagisce con il mondo esterno esclusivamente invocando altri Web services. In questo senso, essa stessa rappresenta una forma di coordinazione di servizi Web, permettendo altresì di comporre questi ultimi in maniera ricorsiva. L'ambiente runtime all'interno del quale viene eseguito il generico processo è detto motore BPEL. Lo standard che definisce l'uso di BPEL nelle interazioni tra Web services è chiamato BPEL4WS o WS-BPEL. BPEL è in particolare adatto a modellare workflow completamente automatizzati. Non esiste una notazione grafica standard per BPEL. 24 febbraio 2009 Pag. 28
- 29. Documentare i processi: XPDL L'XPDL (XML Process Definition Language) è un linguaggio di markup, attualmente alla versione 2.1, ideato per la definizione e l’esecuzione dei processi e standardizzato dalla WFMC (WorkFlow Management Coalition). E’ nato con l’obiettivo di serializzare BPMN, che ne costituisce l’aspetto grafico. A differenza di BPEL, XPDL mantiene anche gli aspetti grafici come la posizione x,y o la dimensione di un nodo ad esempio e, per questo, è pensato come strumento per la condivisione di definizioni di processo tra vari applicativi. Inoltre, XPDL supporta i task umani, cosa che BPEL non fa. BPEL4PEOPLE, che è l’estensione di BPEL per questo scopo, non è ancora uno standard. 24 febbraio 2009 Pag. 29
- 30. Documentare i processi: XPDL 24 febbraio 2009 Pag. 30
- 31. Quando un processo è complesso? La complessità di un processo è definita come il grado in cui il processo è difficile da analizzare, capire o spiegare. Può essere caratterizzata dal numero e dalla complessità delle attività alle interfacce, delle transizioni, delle ramificazioni del flusso, dell’esistenza di loop, dei ruoli, dei tipi di strutture dati e di altre caratteristiche del processo. Non esiste una metrica univoca per misurare la complessità. Possiamo però considerare i seguenti: Complessità a livello di attività è legata al numero e alla complessità algoritmica delle attività che compongono un processo Complessità a livello di flusso dipende sostanzialmente da quante ramificazioni dovute all’esistenza di split e join ci sono nel grafo di flusso del processo Complessità a livello di dati dipende dal numero e dalla complessità delle strutture dati che vengono trasferite tra le attività e anche dal numero di parametri formali delle attività Complessità a livello di risorse ogni attività richiede l’uso di risorse. In questo caso il processo è tanto più complesso quanto più difficile è l’approvigionamento delle risorse necessarie 24 febbraio 2009 Pag. 31
- 32. Quando un processo è complesso? La Complessità Ciclotomatica o Numero di McCabe è un esempio di metrica relativa al diagramma di flusso di un processo ed è presa in prestito dall’Ingegneria del software. Essa misura il numero di cammini linearmente indipendenti e quindi, nel nostro caso, di possibili esecuzioni del processo start-to-finish. E’ chiaro che, in presenza di molte eccezioni rispetto al flusso di esecuzione principale, la complessità aumenta. Si misura come C = Narchi – Nattività + 1 24 febbraio 2009 Pag. 32
- 33. Workflow Management Il Workflow consiste nell’automazione di un processo di business, in tutto o in parte, durante il quale documenti, informazioni o attività vengono passati, seguendo un insieme di regole procedurali, da un partecipante all’altro per la loro elaborazione. I singoli componenti, o step, di un workflow possono essere caratterizzati da tre parametri: •un input •un algoritmo di processamento •un output Lo strumento grafico per descrivere i Workflow è quello delle Reti di Petri. Un sistema di Workflow Management è definito come un sistema che definisce, crea e gestisce l’esecuzione di workflows attraverso l’uso di software, che è eseguito all’interno di uno o più motori di workflow e che è capace di interpretare la definizione dei processi, interagire con i partecipanti al workflow e, qualora richiesto, di invocare l’uso di strumenti IT e applicazioni. Il sistema è formato da due componenti: •il workflow modeling component che permette ad amministratori e analisti di definire i processi e attività, analizzarli e simularli e assegnarli alle persone •il workflow execution component che è composto dal workflow engine, un ambiente di esecuzione che assiste nel compiere i processi e le procedure, e le interfacce di esecuzione verso l’utente finale. 24 febbraio 2009 Pag. 33
- 34. Workflow Management Processo di Business È definito in un È gestito da un Workflow Definizione di Management processo System sottoprocessi usato per creare composto di e gestire tramite Istanze di processo attività include una o Esegue una che possono più Durante essere l’esecuzione sono rappresentate da Istanze di manuali automatizzate attività che include ruolo Applicazioni Work items invocate ricopre un partecipante 24 febbraio 2009 Pag. 34
- 35. Workflow Management: Reti di Petri Le reti di Petri permettono di modellizzare sistemi concorrenti e sono state ideate da Carl Adam Petri nel 1962. In una rete di Petri gli elementi fondamentali sono due: le location o posti, che individuano lo stato del sistema, e le transizioni, che permettono di cambiare stato. I posti sono rappresentati graficamente con dei cerchi mentre le transizioni con dei rettangoli/quadrati. Un posto può rappresentare: •una posizione geografica •un buffer •uno stato o una condizione mentre una transizione: •un evento •la trasformazione di un oggetto •il movimento di un oggetto I posti e le transizioni sono collegate tra loro da linee direzionali, chiamate archi. La regola fondamentale è che un arco può collegare solo un posto a una transizione ma non posti fra loro o transizioni fra loro. arco Stato A Transizione Stato B da A a B 24 febbraio 2009 Pag. 35
- 36. Workflow Management: Reti di Petri Un altro elemento di una rete di Petri è quello che viene chiamato token, che può quasi essere pensato come il segnaposto di un giocatore in un gioco da tavola. In realtà, forse, un esempio migliore consiste nel pensare una transizione come una chiusa e un posto occupato da un token come un bacino pieno d’acqua. Quando la transizione avviene, l’acqua viene portata dai bacini di input ai bacini Stato A Transizione Stato B di output. da A a B Un token può rappresentare varie cose: •un oggetto fisico •una collezione di oggetti fisici •un dato con contenuto informativo •l’indicatore di uno stato •l’indicatore di una condizione Durante l’evoluzione, il sistema, il cui stato a un certo istante viene Stato A Transizione Stato B rappresentato con il token che si trova in un determinato posto o da A a B stato, evolve passando da un posto all’altro. Una transizione è detta abilitata se ciascuno dei suoi posti di input contiene almeno un token. In tal caso, la transizione può avvenire (firing) e un token verrà spostato (fired) da uno dei posti di input a uno dei posti in output. A un certo istante, più transizioni possono essere abilitate, cioè il sistema può fare la transizione verso più stati finali, ma solo una di esse si verificherà. Occorre fare attenzione che il numero di token non è necessariamente costante. Esso varierà, anzi, se ci sono transizioni in cui il numero di posti di input non è uguale al numero di posti di output. 24 febbraio 2009 Pag. 36
- 37. Workflow Management: Reti di Petri Un esempio relativo ad una rete di Petri più complessa è quello relativo ai 5 filosofi. Il filosofo Il filosofo smette Il filosofo Cinque filosofi sono seduti ad una tavola con un bastoncino in mezzo pensa di pensare e inizia a mangia a ogni coppia. Al centro della tavola c’è un gran piatto di spaghetti. mangiare Ogni filosofo passa il suo tempo a pensare (p1,p3,p5,p7,p9) o a mangiare (p10,p11,p12,p13,p14) . Quando vuole mangiare prende entrambi i bastoncini (p0,p2,p4,p6,p8) ai suoi lati e mangia. Alla fine li rimette a posto e riprende a pensare. Il filosofo smette di mangiare e riprende a pensare Il filosofo smette di pensare e inizia a mangiare Il filosofo Il filosofo pensa mangia Il filosofo smette di mangiare e riprende a pensare 24 febbraio 2009 Pag. 37
- 38. Workflow Management: Linguaggio Yawl Yawl (Yet Another Workflow Language) è un linguaggio per workflow management basato sui Workflow Patterns e sulle reti di Petri. È basato su un progetto open source. Yawl è distribuito con un editor grafico e un workflow engine, entrambi scritti in Java, al sito http://www.yawlfoundation.org. Al contrario di quanto accade con le reti di Petri, è possibile connettere direttamente transizioni tra loro. Una rete di workflow di Yawl è formata da: •una condizione di input •una condizione di output •un insieme di task, eventualmente associato a una molteplicità, qualora il task debba essere eseguito più volte •un insieme di cancellazione •uno split e un join scelto tra AND, OR e XOR • un insieme di condizioni •la relazione di flusso che, a partire dalla condizione di input fino alla condizione di output collega un elemento (task o condizione che non sia di output) a quello successivo (task o condizione che non sia di input), in modo tale che tutti gli elementi (task e condizioni) si trovino su un possibile cammino che, partendo dalla condizione di input, permette di raggiungere la condizione di output. Yawl nasce per risolvere i punti deboli delle reti di Petri e in particolare la presenza di sincronizzazione, cancellazione o istanze multiple di task nei patterns. 24 febbraio 2009 Pag. 38
- 39. Workflow Management: Linguaggio Yawl condizione Task atomico Condizione di Input Task composto flight pay Condizione di Ouput Più istanze di un task atomico hotel register Più istanze di un task composto car cancel AND-split task AND-join task Il task Pay viene eseguito se tutte e XOR-split task XOR-join task tre le prenotazioni hanno avuto successo. Se una di queste fallisce, allora tutte le altre OR-split task OR-join task prenotazioni vengono cancellate ..... Rimuovi tokens 24 febbraio 2009 Pag. 39
- 40. Modelli di processo e frameworks Lo scopo dei modelli è quello di supportare il lavoro collaborativo, sia fornendo una nomenclatura che un insieme di concetti comuni. Un trend recente nella letteratura riguardante i Business Process consiste nel tentativo di formalizzare la conoscenza di un determinato ambito/dominio di business in strutture, frameworks e pattern che possano essere riutilizzati per facilitare il redisegno dei processi e supportare lo sviluppo dei sistemi. Questo dovrebbe permettere di semplificare e accelerare l’innovazione di processo. L’insieme di queste strutture va a formare l’Architettura Enterprise. Un modello è, di fatto, una codifica delle best practice di settore. Utilizzarlo non vuole solo dire poter sfruttare tutta la consocenza condivisa acquisita fino a quel momento, ma anche essere in grado di confrontarsi con gli altri e capire meglio le ragioni del prorpio successo/insuccesso. 24 febbraio 2009 Pag. 40
- 41. Il Process Classification Framework di APQC APQC (American Productivity & Quality Center, www.apqc.org) ha realizzato nel 1992, e continuamente aggiornato da allora, con il coinvolgimento a livello mondiale di più di 80 organizzazioni, un Process Classification Framwework (PCF), consultabile all’indirizzo http://www.apqc.org/pcf, che descrive genericamente, e cioè ad alto livello ed in modo indipendente dalla industry, l’insieme dei processi di business, a partire dall’idea di business iniziale fino alla gestione del cliente. Essendo un framework, esso può poi essere declinato sui vari tipi di mercato. In particolare, APQC mette già a disposizione gratuitamente i modelli specifici per l’industria automobilistica, difesa e aerospaziale, farmaceutica, elettrica, petrolifera, telecomunicazioni, broadcasting, prodotti per consumatori. 24 febbraio 2009 Pag. 41
- 42. Il Process Classification Framework di APQC PCF organizza i processi operativi e di gestione in 12 categorie di livello enterprise, per un totale di più di 1000 processi e attività associate. A partire dalla versione 5 del framework, ogni elemento di processo è contraddistinto da due numeri. Il primo è nel formato 1.2.3.4 e rispecchia la struttura gerarchica in modo dipendente dal framework, mentre il secondo, indipendente dal framework, è un numero seriale univoco nel database OSBC e parte convenzionalmente da 10000. ogni elemento di processo è collocato in una gerarchia composta da (dal più grande al più piccolo): •Categoria è il livello più alto e contraddistinto dal primo numero (es. 1.0 e 8.0) •Gruppo di processi è il livello immediatamente successivo e contraddistinto da due numeri (es. 1.4 o 8.2) •Processo è il terzo livello della gerarchia e contraddistinto da tre numeri (es. 1.4.2 o 8.2.5) •Attività è il nodo foglia dell’albero e contraddistinto da 4 cifre (es. 1.3.4.2) In tal modo, l’attività 1.1.1.1 “Analizza e valuta la concorrenza” appartiene al processo 1.1.1 “Fai un assessment dell’ambiente esterno”, che a sua volta fa parte del gruppo di processi 1.1 relativi a “Definisci i concetti di business e la vision a lungo termine” della categoria 1.0 “Sviluppa una Vision e una Strategia”. 24 febbraio 2009 Pag. 42
- 43. eTOM eTOM (Enhanced Telecom Operations Map) è un framework per i processi di business che ha come scopo lo sviluppo e la gestione dei processi chiave di un telecommunications service provider. Come tale, è focalizzato sull’erogazione di servizi verso clienti esterni. Esso è descritto nel modo più possibile indipendente dall’organizzazione, dalla tecnologia e dal servizio. Il modello di business descritto in eTom, vede il service provider interfacciarsi con fornitori, clienti e altri service providers come partners. Il sito di riferimento è http://www.tmforum.org/browse.aspx?catID=1648. È stato inventato nel 1995 da Telemanagement Forum con il nome di TOM e successivamente rivisto fino a dare luogo alla versione Enhanced, comparsa nel 2001. L’attuale versione è la 7.0 ed è distribuito come modello da importare in Casewise Corporate Modeler o equivalente. È stato adottato come Standard Internazionale per il settore Telecom da ITU ed è il modello di riferimento di molte compagnie, tra cui Vodafone e Telecom Italia. 24 febbraio 2009 Pag. 43
- 44. eTOM Esso descrive tutti i processi enterprise richiesti da un service provider e li analizza ad un diverso livello di dettaglio, a seconda del loro significato e della loro priorità per il business. I processi sono inquadrati in una struttura gerarchica, in cui ciascun livello consiste in un dettaglio sempre maggiore. A livello concettuale, o livello 0, tutti i processi sono raccolti in tre aree: •Strategy, Infrastructure and Product che copre la pianificazione e la gestione del ciclo di vita •Operations che copre il core della gestione operativa •Enterprise Management che copre la gestione dei processi di supporto al business I processi di business sono poi ulteriormente raggruppati in modo diverso a seconda della prospettiva: •raggruppamento per processi verticale che rappresenta una vista end-to-end come ad esempio il flusso di billing verso gli utenti •raggruppamento per processi orizzontale che rappresenta una vista funzionale dei processi stessi, come ad esempio tutti i processi coinvolti nel Marketing e nella Decomposizione di livello 1 Gestione del Cliente 24 febbraio 2009 Pag. 44
- 45. eTOM Decomposizione di livello 2 di Operations 24 febbraio 2009 Pag. 45
- 46. SCOR SCOR (Supply-Chain Operations Reference) è un modello di riferimento per il processo di gestione della catena dei fornitori, sviluppato da Supply-Chain Council. Il sito di riferimento è http://www.supply-chain.org/cs/root/scor_tools_resources/scor_model/scor_model. SCOR copre tutte le fasi e, in particolare: •tutte le interazioni col cliente, dall’inserimento dell’ordine fino al pagamento della fattura •tutte le transazioni relative ai prodotti, a partire dal fornitore del fornitore fino al cliente del cliente •tutte le interazioni col mercato, a partire dalla richiesta aggregata di un certo prodotto o servizio, fino al soddisfacimento del singolo ordine. Il modello è basato su cinque processi di gestione: •Plan (Pianifica) gestisce l’equilibrio tra le risorse necessarie e i requisiti di produzione attraverso l’inventario, la misura delle performance della catena produttiva, le regole di business, la raccolta di dati, i requisiti normativi, il rischio e altro ancora. •Source (Approvvigiona) consiste nell’identificare e selezionare i fornitori di prodotti o servizi, programmare l’invio e la ricezione, lo stoccaggio e l’eventuale trasferimento dei materiali, pagare i fornitori, gestire l’inventario, effettuare misure di qualità sui fornitori ecc. •Make (Produci) è la parte vera e propria di produzione. Consiste nello schedulare le attività produttive, realizzare il prodotto, effettuare i test, impacchettare, inviare verso la consegna ecc. •Deliver (Consegna) gestisce tutti i passi dell’Ordine cliente, a partire dalla richiesta preventivo fino alla spedizione tramite i canali appropriati. Gestisce il magazzino, invia la fattura al cliente, stabilisce le modalità, i rischi e le normative per il trasporto del bene ecc. •Return (Restituisci) è la fase che sovrintende alla restituzione dei prodotti difettosi, delle forniture in eccesso, ai reclami, alla riparazione e alla manutenzione. Questi processi fanno parte del Supporto post- vendita al cliente 24 febbraio 2009 Pag. 46
- 47. SCOR Ad un livello successivo di dettaglio, ogni singolo processo mostrato in figura può essere ulteriormente scomposto. Ad esempio, S1 (Source Stocked Product, Approvvigiona il prodotto a catalogo) è composto dagli elementi di processo: S1.1 schedula la consegna del prodotto S1.2 ricevi il prodotto S1.3 verifica il prodotto S1.4 trasferisci il prodotto S1.5 autorizza il pagamento del fornitore 24 febbraio 2009 Pag. 47
- 48. Modelli in ambito bancario: ABILab ABI Lab (www.abilab.it) ha avviato nel 2001 un’attività di classificazione dei processi bancari: con il supporto di un gruppo di lavoro di banche è stata realizzata la prima versione della Tassonomia dei processi bancari. La mappa dei processi ABI Lab descrive il funzionamento di una banca attraverso 500 voci di processi e sottoprocessi strutturati su quattro livelli gerarchici. Insieme alla Tassonomia dell’Information Communication Technology (ICT), essa costituisce il cuore della metodologia di ricerca del Consorzio. La tassonomia è a disposizione delle banche consorziate e dei partner tecnologici su www.abilab.it. La tassonomia dei processi bancari di ABI Lab suddivide il mondo della banca in quattro macro ambiti (livello 1): processi direzionali o di governo sono i processi che sovraintendono al funzionamento della banca, tramite la formulazione della strategia e delle linee guida di indirizzo, la pianificazione aziendale, il controllo dell’efficace e regolare svolgimento dell’attività, la gestione del rischio nelle sue varie forme e la relazione con la proprietà, i dipendenti e le entità esterne processi di marketing, commerciali e customer service sono i processi che provvedono all'identificazione, generazione, conclusione, vendita e post-vendita di prodotti e servizi finanziari. processi di operations sono i processi legati alla gestione delle attività core della banca, dalle transazioni all'intermediazione finanziaria e creditizia. Comprendono i servizi bancari tipici, i servizi bancari accessori, gli incassi e i pagamenti, la finanza, il credito. processi di supporto è l’insieme di processi a supporto di tutte le attività operative dell'azienda. Comprendono l'organizzazione, i sistemi informativi e le telecomunicazioni, la sicurezza, le risorse umane, l'amministrazione, il supporto legale, tributario e logistico, gli acquisti, le partecipazioni e la gestione degli organi sociali, il contante e i valori. 24 febbraio 2009 Pag. 48
- 49. Modelli in ambito bancario: ABILab 24 febbraio 2009 Pag. 49
- 50. POSC per il mercato petroltecnico POSC (Petrotechnical Open Standards Consortium), oggi rinominato come Energistics, ha sviluppato un modello di riferimento, denominato E&P Business Process Reference Model o EPBPRM. Il sito da consultare è http://www.energistics.org/posc/Business_Process_Reference_Model.asp. Il modello viene rappresentato come una gerarchia in cui ogni processo occupa un nodo ed è una specializzazione del nodo padre. Esso è molto incentrato sugli Asset, sul loro ciclo di vita (box verdi in figura e numerati da 1 a 5) e sulla loro gestione (Asset Management) attraverso un insieme strutturato di Attività di supporto e di esecuzione (14 box di processo verde chiaro). I processi di gestione sono le tre box rosa. Il modello descrive l’interazione tra vari tipi di risorse: •Attori che possono essere interni, come dipendenti, manager, geologi ecc. o esterni, come partner, fornitori, clienti ecc. •Oggetti che possono essere di natura tangibile, come materiali, equipaggiamenti, ecc o di tipo intellettuale come documenti, database, misure sul campo, rapporti ecc. Il sito è anche fornito di un motore di Knowledge Management basato sul modello. 24 febbraio 2009 Pag. 50
- 51. POSC per il mercato petroltecnico 24 febbraio 2009 Pag. 51
- 52. POSC per il mercato petroltecnico 24 febbraio 2009 Pag. 52
- 53. Il progetto MIT process handbook Il sito di riferimento è http://ccs.mit.edu/ph. L’obiettivo del progetto è quello di sviluppare una libreria online per condividere e gestire la conoscenza sul business, in vari ambiti. Attualmente, sono contenuti nel repository più di 5000 processi di diverso tipo: 1. modelli generici di tipiche attività di business (es. Vendere, Comprare, Produrre) che vengono fatte in ambiti diversi 2. esempi specifici/case study di aziende 3. frameworks per classificare la conoscenza così acquisita Il Modello di Business su cui MIT handbook è basato è composto dai blocchi di base Buy, Make, Sell, Design e Manage. Ognuno di questi processi è a sua volta composto, ad un livello di dettaglio successivo, da sottoprocessi. 24 febbraio 2009 Pag. 53
- 54. Il progetto MIT process handbook Ogni entry (ad es. la parola Sell, Vendere, correlata al processo di Vendita) è corredata da un certo numero di informazioni aggiuntive, come ad esempio: descrizione ad es. una Vendita avviene quando un “Venditore” fornisce qualcosa che ha valore (come un prodotto o un servizio) a un “compratore” in cambio di soldi parti è la lista delle sottoattività di cui si compone il processo. Nel nostro caso, il processo di Vendita è formato dalle seguenti: a) identifica i clienti potenziali b) identifica le necessità dei clienti potenziali c) informa i clienti potenziali d) ottieni l’ordine e) consegna il prodotto o servizio f) ricevi il pagamento g) gestisci le relazioni con il cliente proprietà è una lista di attributi di processo, come ad es. la sua durata, il costo, il luogo dove si svolge ecc. processi correlati è una lista dei processi che sono in relazione con il processo in oggetto. Ci possono essere tre tipi di relazioni: a) altri modi in cui il processo può essere fatto (ad. es. nel caso della Vendita si può vendere tramite negozio, porta a porta o marketing, si può vendere un processo, un servizio o un prodotto ecc.) b) processi in cui il processo in oggetto viene utilizzato ( ad es. creare e vendere software per cellulari) c) processi simili al processo in oggetto (ad es. lo Scambio o la Donazione) specializzazioni sono i diversi modi in cui un processo può essere fatto. Nel caso della Vendita abbiamo la Vendita in negozio, che a sua volta può essere fisico o elettronico, la Vendita porta a porta, la Vendita per catalogo postale ecc. raggruppamenti (Bundles) sono gruppi di specializzazioni definiti rispondendo alle domande Come? Cosa? Chi? Dove? Quando? e Perchè? Nel caso del processo di Vendita avremo ad es. Vendere Come? Tramite un negozio, porta a porta o per catalogo postale; Vendere Cosa? Un processo, un prodotto o un servizio; Vendere a Chi? Aziende o Privati; ecc. usi è la lista dei processi che usano il processo in oggetto all’interno di un sottoprocesso generalizzazioni sono le generalizzazioni del processo in oggetto. Ad es. lo Scambio è una generalizzazione della Vendita, che a sua volta è un caso particolare dello Scambio in cui uno degli oggetti scambiati è denaro. matrici di compromesso (Trade-off Tables) rappresentano comparazioni tra le diverse specializzazioni contenute in un raggruppamento. Ad es. uno dei sottoprocessi della Vendita consiste nell’Informare i potenziali Clienti. Questa attività può essere fatta attraverso la Pubblicità, che può essere condotta in molti modi diversi, ad es. su giornali, in televisione, tramite internet ecc. Una matrice di compromesso mostrerà i pro e i contro di ogni modo di fare pubblicità mettendo in evidenza il diverso potere di penetrazione, il diverso costo, ecc. 24 febbraio 2009 Pag. 54
- 55. Il progetto MIT process handbook 24 febbraio 2009 Pag. 55
- 56. Il progetto MIT process handbook Il Process Handbook comprende anche sei Pattern, qui chiamati Archetipi, che consistono in sei modi di base con cui un’organizzazione può fare business: Creatore compra materiali o componenti dai fornitori e li trasforma o li assembla in prodotti finiti o servizi (fisici, informativi o finanziari) che vengono poi venduti. E’ un modello tipico negli ambiti manifatturiero e edile Distributore compra un prodotto e lo rivende a qualcun altro. Il Distributore può aggiungere valore addizionale con il trasporto o il packaging. E’ il caso tipico dei supermercati Intermediario mette in contatto venditori e compratori. Non assume mai la proprietà fisica del bene o del servizio. Spesso viene pagato sulla base di una percentuale del valore del bene scambiato dal venditore, dal compratore o da entrambi. E’ il caso tipico delle società di intermediazione immobiliari Affittuario vende il diritto di utilizzare, ma non di possedere, un bene. Questo può essere una proprietà immobiliare (un appartamento, una stanza d’albergo o un parco giochi), un evento (ad es. un concerto) o un oggetto (ad es. un’automobile o uno studio di registrazione). A seconda del caso si paga un affitto, un biglietto di entrata, un leasing o altro. Contractor vende un servizio fornito principalmente da persone. E’ il caso della consulenza, dell’insegnamento, della salute ecc. Spesso si paga il servizio in base alla quantità di tempo o al livello di specializzazione che il servizio richiede. Attrattore attrae l’attenzione delle persone vendendo cose come programmi televisivi o contenuti web e poi “rivende” l’attenzione ai pubblicitari. E’ il modello tipico su cui è basata la televisione o internet Modelli di business più complessi possono essere realizzati come combinazioni di questi modelli di base e, anzi, secondo il MIT, virtualmente qualsiasi modello di business esistente è ottenibile come composizione di questi. 24 febbraio 2009 Pag. 56
- 57. Pattern di processo Che cosa è un pattern? Un pattern è “una soluzione a un problema in un contesto”. Gli ingredienti, quindi, sono tre: •un contesto è un insieme di situazioni ricorrenti a cui il pattern si applica •un problema è l’insieme delle “forze” – obiettivi e vincoli – che si verificano in questo contesto. In letteratura, si trova esplicitamente nominato il concetto di forza, intesa nel senso di “spinta” (raggiungimento di un obiettivo) a fare qualcosa o di “rallentamento” e “impedimento” (vincoli). •una soluzione è un disegno generale che è possibile applicare per raggiungere l’obiettivo rispettando i vincoli Un pattern descrive i passi necessari da seguire per risolvere un problema. La chiave è la riusabilità. Un aspetto importante dei pattern è che essi non sono inventati ma scoperti. Il concetto di pattern è molto legato a quello di best practice, dal momento che, di fatto, rappresenta una soluzione a un problema ricorrente, esattamente come le best practices. Un pattern può essere semplice o composto, a seconda che sia di un tipo base o sia a sua volta composto da altri pattern. Una menzione va anche agli AntiPatterns che rappresentano esempi negativi, cioè di soluzioni da NON adottare. È importante studiarli perchè questo può darci la possibilità di prevenirli o, eventualmente, di correggerli. 24 febbraio 2009 Pag. 57
- 58. Le tre dimensioni di SOA SOA è un abilitatore tecnologico per BPM, ma è possibile implementare BPM anche senza SOA! 24 febbraio 2009 Pag. 58
- 59. Migrare a SOA Creare la lista delle funzionalità esposte da Creare la lista ciascuno dei dei servizi servizi elementari Implementare candidati i servizi elementari in rete DI SOA Aggregare i servizi elementari in servizi di business più Creare la complessi tassonomia dei servizi Identificare i Sottoprocessi comuni tra i vari Processi (ridondanze e Suddividere i patterns) Documentare processi in i processi sottoprocessi, di business consistenti di funzionalità correlate logicamente 24 febbraio 2009 Pag. 59
- 60. Tassonomia dei servizi Processi di Business Servizi di Business Servizi Elementari Tipologia di Servizi Descrizione Security Services Authorization, Authentication, Accounting, Criptazione, Firma Digitale, Marca Temporale Presentation Services Servizi che hanno come obiettivo la visualizzazione dei dati all’utente Communication Services Impacchettano l’accesso verso sottosistemi di Input / Output esterni (Es. Fax Server, E-Mail Server, SMS Gateway) Data Services Impacchettano l’accesso alle Basi Dati Peripheral Services Impacchettano l’utilizzo di periferiche esterne come Scanner, Stampanti, Imbustamento, Etc. Application Services Servizi Applicativi che racchiudono la logica di Business Servizi con cui l’azienda implementa i processi di Business ○ Core Services Servizi a supporto di quelli core che espongono funzionalità generiche (Es. ○ Support Services Conversione di formato, spedizione messaggi, etc.) 24 febbraio 2009 Pag. 60
- 61. Ripensare i processi La reingegnerizzazione dei processi ha come obiettivi uno o più dei seguenti: •automatizzazione di un’attività, che prima era svolta in modalità manuale •integrazione e interoperabilità tra sistemi più o meno eterogenei allo scopo di costruire processi complessi che sfruttino le funzionalità di tutti in modo trasparente ed efficiente •rimozione delle ridondanze e consolidamento spesso in un’organizzazione esistono sovrapposizioni funzionali, cioè processi o sistemi diversi che compiono parzialmente gli stessi compiti. Questo provoca duplicazione, maggiore complessità e problemi gestionali (chi deve trattare quei dati? Chi ne è responsabile?). •standardizzazione e uso delle best practices un’organizzazione potrebbe voler ricostruire un processo sfruttando i modelli esistenti sul mercato. La standardizzazione facilita il confronto tra aziende diverse, rende più semplice l’analisi delle performance e migliora l’interoperabilità e la sostituzione di parti del processo o dei sistemi coinvolti con altri. Per il ridisegno dei processi le metodologie che si possono utilizzare sono: •Six Sigma •Balanced Scorecard •Lean manufacturing •Value based management and Process Improvement •TQM 24 febbraio 2009 Pag. 61
- 62. Six Sigma Six Sigma è una metodologia di Gestione della Qualità basata su tecniche statistiche. La lettera sigma rappresenta la standard deviation della distribuzione di probabilità normale (curva a “campana” o di Gauss) che governa molti fenomeni fisici. Sei sigma rappresenta una variazione rispetto all’output medio di un processo pari a 3.4 difetti per milione e quindi è sinonimo della capacità di riduzione di anomalie fino a un livello considerato trascurabile. Nata in ambito manifatturiero, la metodologia ha l’obiettivo di generare prodotti tutti con le stesse caratteristiche a parte una percentuale irrisoria. La metodologia Six Sigma fornisce un approccio quantitativo al problema del miglioramento continuo e della diminuzione dei costi, riducendo la variazione dell’output di un processo al livello ritenuto più appropriato per una certa organizzazione. In questo modo, l’output di un processo verrà definito, almeno a livello di qualità tramite: •La forma della distribuzione dei valori •una media •una variazione standard •un LSL (Lower Specification Limit) o valore minimo dell’output ritenuto accettabile •un USL (Upper Specification Limit) o valore massimo dell’output ritenuto accettabile 24 febbraio 2009 Pag. 62
- 63. Six Sigma Six Sigma distingue tra: •External Critical to Quality rappresenta gli obiettivi di qualità come espressi dal cliente in linguaggio corrente. Un esempio è “Tutte le bottiglie devono avere la stessa quantità di bevanda”. Dal momento che un enunciato del genere non è misurabile, visto che ogni strumento di misura ha una precisione massima e non si può dire in assoluto se due bottiglie contengono la stessa quantità o no, ci viene in aiuto la definizione successiva. •Internal Critical to Quality descrive in termini misurabili gli obiettivi di qualità del cliente. Un esempio è “Tutte le bottiglie devono contenere tra 730 e 740 ml di bevanda”. Una volta compreso, dall’analisi dei processi, quali sono questi aspetti, il passo successivo è quello di capire da quali parametri essi dipendono maggiormente e studiare quale variazione si produce sulla qualità finale per ogni variazione di questi parametri. 24 febbraio 2009 Pag. 63
- 64. Six Sigma D: in questa fase si definiscono gli obiettivi del progetto. Un esempio potrebbe essere “Tutte le bottiglie devono contenere tra 730 e 740 ml di bevanda”. Questo enunciato è espresso in termini di Internal CTQ. C: l’obiettivo di questa fase è tenere sotto controllo la situazione per capire se le modifiche M: in questa fase si procede ad effettuate nella fase di Improve stanno dando i effettuare le misurazioni. Nel nostro risultati sperati e per stabilizzare la situazione. esempio, si tratta di prendere un Nel nostro caso, dovremmo monitorare la campione di bottiglie e misurare per temperatura dei macchinari e impedire, ad ognuno la quantità di bevanda che viene esempio, che nell’area di produzione vengano immessa. In seguito a ciò potremo aperte porte o finestre. ricavare, la distribuzione, la media e la variazione standard. I: una volta analizzate le cause, la fase successiva passa alla correzione, cioè alla messa a punto di contromisure e soluzioni per portare l’output del processo entro gli obiettivi di qualità previsti. Nel A: dopo essere entrati in possesso di nostro esempio, supposto di avere accertato che la dati misurabili, la fase successiva variazione di temperatura dei macchinari, dovuta prevede al loro analisi. Quale, tra i all’alternarsi delle stagioni, incide di più sulla parametri del processo, incide di più variazione della quantità di bevanda, dovremmo sull’output? Nel nostro caso ci dobbiamo passare ad installare un impianto di chiedere “quali tra gli aspetti che condizionamento delle aree di produzione per comportano una variazione della tenere costante la temperatura. quantità di bevanda incide di più?” 24 febbraio 2009 Pag. 64
- 65. Balanced Scorecard Balanced Scorecard è una metodologia pensata per aiutare a tradurre la strategia aziendale in obiettivi e individuare degli indicatori misurabili, in relazione causa-effetto tra loro, allo scopo di valutare l’efficienza con cui questi obiettivi soddisfano effettivamente la Strategia. La presenza di queste relazioni tra gli indicatori permette di individuare meglio le aree di investimento chiave allo scopo di ottenere la massimizzazione del Valore (redditività, soddisfazione di clienti, dipendenti e azionisti, ecc.). Al centro della metodologia stanno la Vision, intesa come “ciò che l’azienda vuole fare” e la Strategia, cioè “come l’azienda intende raggiungere i suoi obiettivi, delineati dalla Vision”. Dopodichè, deve essere espresso un insieme di indicatori misurabili che permetta di capire da cosa l’azienda parte, cioè la sua situazione attuale, e se sta effettivamente generando Valore, cioè se si trova nella situazione di poter raggiungere nei modi espressi dalla Strategia gli obiettivi delineati nella Vision. 24 febbraio 2009 Pag. 65
- 66. Balanced Scorecard Balanced Scorecard identifica quattro prospettive da cui vedere e valutare l’organizzazione, attraverso la raccolta di dati misurabili: la prospettiva di Apprendimento e Crescita (Learning and Growth) si focalizza sulla cultura aziendale, la formazione dei dipendenti, la Ricerca e lo Sviluppo e la gestione della conoscenza necessari per acquisire e mantenere un vantaggio competitivo. la prospettiva del processo di Business misura le performance dei processi. la prospettiva del Cliente misura la soddisfazione del cliente e i requisiti di performance, come ad esempio gli SLA (Service Level Agreement), relativamente alla produzione di beni o all’erogazione di un servizio la prospettiva Finanziaria traccia i requisiti finanziari e le relative performance. 24 febbraio 2009 Pag. 66
- 67. Balanced Scorecard 24 febbraio 2009 Pag. 67
- 68. Lean manufacturing Lean manufacturing (Produzione Snella) è un framework, composto da strumenti e tecniche, per l’ottimizzazione dei processi e, in particolare, per ottimizzare il tempo, le risorse umane, le attività e la produttività, e nello stesso tempo per migliorare il livello qualitativo dei prodotti e servizi al cliente. E’stato sviluppato da Taiichi Ohno and Shigeo Shingo come metodo per gestire la produzione alla Toyota (TPS, Toyota Production System). In particolare, l’obiettivo principale era quello di affrontare e risolvere il problema delle cosiddette 7 sorgenti di sprechi nei processi: •Eccessi od anticipi di produzione •Ritardi •Movimentazione e trasporto superfluo o fatto in modo manuale •Scarsa progettazione di processo •Scorte, che causano costi di immagazzinamento e deprezzamento dei materiali •Scarse performance di processo •Produzione di prodotti/servizi difettosi Categoria di sprechi descrizione antidoto Muda Attività improduttiva e Riduzione degli di nessun valore sprechi aggiunto Muri Attività irragionevole Standardizzazione del e assurda lavoro Mura Volubilità e Livellamento della fluttuazione produzione (Heijunka) 24 febbraio 2009 Pag. 68
- 69. Lean manufacturing A tale scopo, vengono utilizzati degli strumenti: •JIT: Just In Time •KANBAN/SISTEMA "PULL“ •POKA-YOKE •IL METODO "5S" •SMED: Single Minute Exchange of Die •TPM:Total Productive Maintenance •TAKT TIME •HEIJUNKA •CELLULAR MANUFACTURING •KAIZEN 24 febbraio 2009 Pag. 69
- 70. Just in Time Il JIT è una metodologia di gestione della produzione che consiste nel produrre esattamente solo i quantitativi richiesti nel breve periodo, idealmente un giorno, in modo da ridurre al massimo i costi relativi al magazzino. Per fare questo, si utilizza un sistema di segnali, o kanban, durante l’esecuzione del processo, che permettano di segnalare, appunto, al sistema di produzione quando iniziare la lavorazione del prossimo pezzo. Esempi di kanban possono essere la scomparsa di un prodotto dallo scaffale o la presenza a magazzino di soli 5 pezzi o l’arrivo dell’ordine di un cliente, come può essere il caso dell’industria automobilistica. Il concetto sostanzialmente è quello di produrre solo quando serve. Un limite della metodologia è che si basa sostanzialmente sull’esperienza e sui dati storici e non permette di far fronte in modo efficace all’aumento improvviso di richieste. Inoltre, il metodo risente molto di eventuali contrattempi, come può essere il ritardo nella consegna di un fornitore, uno sciopero, un guasto ecc. 24 febbraio 2009 Pag. 70
- 71. KANBAN/SISTEMA "PULL" Un sistema di produzione “pull” è contraddistinto dal fatto che la lavorazione inizia solo in seguito all’arrivo di un ordine, a differenza di un sistema “push” che invece, basandosi su un sistema di previsione delle vendite, entra in azione in anticipo rispetto al fabbisogno dei clienti. Una definizione più precisa è basata sui concetti di: •tempo totale di produzione P è il tempo di attraversamento cumulativo di un sistema produttivo, a partire dall’ordine iniziale delle materie prime fino al prodotto finito. Tutto il processo può essere scomposto in una serie di attività o sottoprocessi che ricevono un input dall’attività precedente, lo lavorano e passano l’output all’attività successiva, eventualmente attraverso uno stoccaggio intermedio •tempo di consegna (Delivery D) è l’intervallo di tempo che intercorre tra l’ordine del Cliente e la consegna del prodotto o l’erogazione del servizio In tal caso, un sistema Push è definito come avente P > D, mentre un sistema Pull come P <= D. Un sistema di tipo Pull per funzionare sfrutta un sistema di kanban che possono essere rispettivamente di due tipi: segnali o schede di movimentazione, che autorizzano il movimento di un pezzo da un centro di lavorazione al successivo, e schede di produzione che autorizzano la messa in produzione di un pezzo in un centro di lavorazione, nel momento in cui uno identico viene prelevato dal centro di stoccaggio in uscita. 24 febbraio 2009 Pag. 71
- 72. Poka-Yoke Poka-Yoke è un termine giapponese che significa sostanzialmente “a prova di errore” o “a prova di stupido” e indica una metodologia di messa a punto di un processo, con l’obiettivo di prevenire l’occorrenza di difetti impedendo sostanzialmente all’operatore di sbagliare. Esso si basa su meccanismi che o impediscano che un errore venga commesso o che ne segnalino visivamente in modo evidente ( “a colpo d’occhio” come si suol dire) l’occorrenza. Alcuni esempi possono essere quelli di impedire che un oggetto possa essere inserito in modo scorretto (a esempio la scheda in un bancomat), o il blocco di un’apparecchiatura se una barra non viene tenuta continuamente premuta (a prova di malore dell’operatore) o il foro di uno strumento che permette l’inserimento solo di un oggetto di forma appropriata (come il vecchio gettone nelle cabine telefoniche pubbliche). 24 febbraio 2009 Pag. 72
- 73. IL METODO "5S" Definisce una modalità per organizzare e gestire il proprio posto di lavoro. Il nome è basato sulle iniziali di 5 parole giapponesi: •Seiri: scegliere e separare sulla postazione di lavoro deve essere presente solo quanto necessario. Il resto deve essere rimosso •Seiton: sistemare e organizzare strumenti, attrezzature e materiali devono essere organizzati in modo efficiente e immediatamente disponibili •Seiso: controllare l’ordine e la pulizia la postazione di lavoro deve essere sempre pulita e ordinata. Anche eventuali problemi devono essere rimossi nel tempo minore possibile •Seiketsu: standardizzare e migliorare è “pulizia” mentale. Le attività devono essere chiaramente spiegate ed evidenziate, anche tramite cartelli e segnali, e standardizzate, in modo da ridurre al massimo deviazioni, eccezioni e imprevisti. •Shitsuke: sostenere la disciplina una volta eseguiti i passi precedenti, la situazione deve essere mantenuta al meglio, anche attraverso formazione continua, monitoraggio, audit e controlli periodici 24 febbraio 2009 Pag. 73
- 74. SMED: Single Minute Exchange of Die E’ anche chiamato Quick Changeover (QCO) e si riferisce alla riduzione massima dei tempi morti di attrezzaggio, setup e messa in moto delle macchine e passaggio da una lavorazione ad un’altra. Può anche essere riferito al tempo necessario per l’avvio di un software, come un sistema operativo ad esempio. Si distingue a questo proposito tra operazioni che possono essere fatte con la macchina in funzione (attrezzaggio esterno) o che ne richiedono l’arresto (attrezzaggio interno). Ovviamente l’obiettivo è quello di ridurre al massimo le operazioni del secondo tipo, convertendole in operazioni del primo tipo. Altre cose che possono facilitare sono la meccanizzazione di procedure, la parallelizzazione, ad esempio tramite il lavoro di gruppo o la semplificazione 24 febbraio 2009 Pag. 74
- 75. Takt Time Il Takt Time è praticamente sinonimo del Time to Market e rappresenta il tempo necessario per la produzione di un bene o l’erogazione di un servizio relativamente a una certa Domanda. Di fatto, esso coincide con l’obiettivo della produzione. Esso è definito come rapporto tra il tempo lavorativo netto disponibile giornaliero (ad es. 8 ore meno le pause caffè, meno la manutenzione ecc.) e il numero di prodotti richiesti dal cliente al giorno. Se, ad esempio, il tempo lavorativo netto fossero 7 ore, cioè 420 minuti e il numero di pezzi da produrre giornalmente fossero 420, allora la catena produttiva dovrebbe essere tarata per sfornare un pezzo al minuto. In tal caso il Takt Time è di un minuto (a pezzo). 24 febbraio 2009 Pag. 75
- 76. Heijunka Heijunka è una tecnica utilizzata allo scopo di rendere la produzione il più possibile esente da fluttuazioni nelle forniture e nella domanda finale. Qualora la domanda di un prodotto sul mercato fosse sempre costante, anche la produzione sarebbe costante e perfettamente predicibile. D’altronde, la presenza di fluttuazioni di mercato fà sì che anche la produzione ne risenta, con il rischio di superlavoro nei periodi di picco e di basso sfruttamento degli impianti e cassa integrazione nei periodi di magra. Il metodo consiglia di attestare la produzione su un valore medio e approfittare dei periodi di magra per farsi un magazzino di prodotti che verrano poi utilizzati nel periodo di picco. In questo modo l’entità del magazzino è mantenuta ad un livello ottimale e il rate di produzione è costante. 24 febbraio 2009 Pag. 76
- 77. L’innovazione nei processi: TRIZ Triz è un acronimo russo (Teoriya resheniya Izobreatatelskikh Zadatch), tradotto liberamente in italiano come “Teoria per la soluzione inventiva dei problemi”, ed è una metodologia e un insieme di strumenti sviluppati in Russia a partire dal 1946 da Gesnrich Altshuller, che hanno l’obiettivo di cercare di rendere sistematico il processo creativo, codificandolo e rendendolo così ripetibile e applicabile. Partendo dall’analisi di quasi 400.000 brevetti, Altshuller si accorse che problemi e soluzioni si ripetevano in ambiti diversi e con caratteristiche diverse, presentando però dei modelli di soluzioni comuni. trovare tutte le soluzioni dell’equazione di secondo x1=1 e x2=2/5 grado 5x2 – 7x + 2 = 0 trovare tutte le soluzioni dell’equazione di secondo grado ax2 + bx + c = 0 24 febbraio 2009 Pag. 77
- 78. Architettura funzionale L’architettura BPM completa che prevede • Design Tools: applicativo che consente il disegno dei flussi di processo l’utilizzo di otto componenti principali: in modo rapido e visuale; • API/Framework layer: interfaccia che consente di integrare in modo flessibile il sistema di BPM in ambienti eterogenei; • Process Automation: modulo che consente la gestione automatica dei processi, basato su condizioni predefinite, che limita l’intervento umano nella gestione dei processi; • Workflow: modulo che consente di disegnare i processi/flussi aziendali tra i vari sistemi coinvolti; • Rules: modulo che facilita l’interazione tra le risorse sia tra sistema che tra persone o una combinazione delle due cose; • Data Transformation: modulo che consente di convertire i dati da un formato sorgente a un formato di destinazione tra sistemi coinvolti nel prcesso di gestione. Opera anche come normalizzatore dei dati scambiati; • Connectivity Services: modulo alla base dell’intero framework BPM. Consente la gestione di eventi catturati da generatori di messaggi con il supporto dei meccanismi transazionali e di rollback; • BAM: modulo che consente di misurare l’efficienza del processo di business e fornisce analisi volte all’individuzione di rischi/opportunità; 24 febbraio 2009 Pag. 78
- 79. Differenze tra vendor Modellazione Modellazione Simulazione Simulazione Implementazione Implementazione Esecuzione Esecuzione Monitoraggio Monitoraggio Ottimizzazione Ottimizzazione Il formato grafico E’ possibile Il risultato della fase di Lo strumento : Lo strumento: Lo strumento: Il formato grafico E’ possibile Il risultato della fase di Lo strumento : Lo strumento: Lo strumento: dello strumento: simulare: modellazione: •interpreta a runtime • genera eventi di •È integrato con una dello strumento: simulare: modellazione: •interpreta a runtime • genera eventi di •È integrato con una •Usa BPMN • utilizzando dati l’XML generato nella monitoraggio, ad es. metodologia di •Usa BPMN • utilizzando dati l’XML generato nella monitoraggio, ad es. metodologia di •Usa un formato fittizi inseriti • è salvato in XPDL fase precedente al superamento di Enterprise •Usa un formato fittizi inseriti • è salvato in XPDL fase precedente al superamento di Enterprise proprietario manualmente • è salvato in BPEL • compila in classi una soglia Architecture e/o con proprietario manualmente • è salvato in BPEL • compila in classi una soglia Architecture e/o con •Usa un formato dall’analista Java e esegue su un • è in grado di una metodologia di •Usa un formato dall’analista • è salvato in un formato Java e esegue su un • è in grado di una metodologia di proprietario e BPMN •Utilizzando dati • è salvato in un formato Application Server ricevere e ottimizzazione proprietario e BPMN •Utilizzando dati interno proprietario Application Server ricevere e ottimizzazione con la possibilità di storici raccolti interno proprietario l’XML processare eventi di con la possibilità di storici raccolti l’XML processare eventi di passare dall’uno automaticamente •Esegue il formato monitoraggio passare dall’uno automaticamente •Esegue il formato monitoraggio all’altro senza dallo strumento nativo senza provenienti all’altro senza dallo strumento nativo senza provenienti perdita di sulle istanze di utilizzare un dall’esterno perdita di sulle istanze di utilizzare un dall’esterno informazione processo passate application server •È dotato di informazione processo passate application server •È dotato di strumenti grafici tipo strumenti grafici tipo Possibilmente lo Inoltre lo strumento Inoltre lo strumento è gadget windows Possibilmente lo Inoltre lo strumento Inoltre lo strumento è gadget windows strumento è dotato di identifica i colli di dotato di un motore vista, portlet ecc. strumento è dotato di identifica i colli di dotato di un motore vista, portlet ecc. un editor grafico di bottiglia e efficiente per la un editor grafico di bottiglia e efficiente per la regole* suggerisce valutazione delle regole* suggerisce valutazione delle soluzioni regole soluzioni regole * L’utilizzo di regole permette di semplificare il grafico di processo 24 febbraio 2009 Pag. 79
- 80. Differenze tra vendor TIBCO TIBCO Savvion TIBCO Savvion Interpretazione a A livello di vendor Savvion BEA BEA Global 360 runtime IBM BEA Salva in distinguiamo tra pure Global 360 XPDL player, cioè aziende che BPMN lavorano esclusivamente Global 360 BEA Compilazione in classi sul BPM (come Savvion, IBM Ultimus, Global 360 ecc.) e Ultimus IBM Global 360 Salva in non (come Oracle, IBM BPEL Interpretazione a Formato runtime ecc.) grafico IBM nativo Salva in formato Esegue proprietario direttamente Ultimus Ultimus MODELLAZIONE IMPLEMENTAZIONE ESECUZIONE 24 febbraio 2009 Pag. 80
- 81. Consigli e raccomandazioni Modellazione 1. Scegliete uno strumento che vi permetta di importare/esportare disegni di processo da altri applicativi, come Aris, Casewise o Visio. Meglio se supporta standard come BPMN e XPDL, qualora in futuro possiate avere l’esigenza di sfruttare solo certi moduli funzionali di un applicativo, e altri moduli con un altro. Ci sono aziende che vendono modelli di processi per industries specifiche. Avere uno strumento che permette di importarli, facilita enormemente il lavoro. 2. Scegliete uno strumento che possa essere facilmente utilizzato, in fase di Disegno, da un Business Analyst e, in fase di Implementazione, da uno Sviluppatore, tenendo il più possibile divise le due interfacce. 3. Nel caso di un BPMS people-oriented, accertatevi che le form generate aderiscano a standard che permettano di importarle, ad es. come portlet, in portali esistenti (una intranet o internet). Privilegiate prodotti che supportino la generazione di form per più devices (multicanalità) e per utenti diversamente abili (accessibilità). 4. Accertarsi, se si possiede un directory server aziendale, che lo strumento sia in grado di interfacciarsi con esso per recuperare ruoli e il valore di attiburi relativi agli utenti (es. un ramo di processo viene eseguito se l’utente è della sede di Napoli, un altro ramo, invece, se è della sede di Milano) 5. Gestisce il Change Management di processo, eventualmente integrandosi con prodotti di mercato? 6. Lo strumento è dotato di un motore evoluto di regole? Che tipo di interfaccia è fornita per l’editing delle regole (es. testuale, tabellare o grafica)? 24 febbraio 2009 Pag. 81
- 82. Consigli e raccomandazioni User Interaction 1. E’ possibile assegnare task a gruppi di utenti? In tal caso, è possibile considerare il task compiuto quando almeno uno degli utenti del gruppo lo ha eseguito? E’ possibile considerare il task compiuto quando tutti gli utenti del gruppo lo hanno eseguito? 2. E’ possibile assegnare un task ad un utente sulla base del suo carico di lavoro? E in base ai suoi skills? E in base al suo ruolo organizzativo o altri attributi letti da un Directory Server (anche in caso di schema personalizzati)? 3. Un utente può rifiutare un task che gli è stato assegnato? Può riassegnarlo ad altri? 4. L’applicativo consente al responsabile di un gruppo di lavoro di supervisionare le attivita' assegnate ai membri del gruppo, verificando ritardi ed eventualmente riallocando I task quando necessario? 5. L’utente può visualizzare un’interfaccia da cui controllare i task a lui assegnati? Tale interfaccia è integrabile in altri prodotti di portale (ad es. una Intranet)? 6. L’applicativo consente di inviare automaticamente notifiche ad un utente all'approssimarsi della scadenza di un task assegnato? Tali notifiche possono essere inserite dall'amministratore, dall'utente stesso o da un suo supervisore? 24 febbraio 2009 Pag. 82
- 83. Consigli e raccomandazioni Architettura e Integrazione 1. Avete già un’infrastruttura SOA di un determinato vendor? Accertatevi che il BPM che volete acquistare collabori completamente con essa. Ad es. il BPM in fase di implementazione è in grado di effettuare il browsing dei servizi sul Registry? 2. Come si integra con Microsoft Office? E’ possibile utilizzare forms internamente ad Outlook? Con Office 2007 esistono i cosiddetti ribbon: è possibile fare in modo che l’utente inizi il processo magari tramite un pulsante appositamente predisposto sulla toolbar di Office (es. pulsante di protocollazione in Microsoft Word)? 3. La struttura del prodotto è modulare? Quanto è possibile sostituire un modulo con uno funzionalmente identico fornito da un altro produttore? 4. Usa un application server? Se si, con quali prodotti è integrabile? 5. Supporta l’integrazione con applicativi esterni di mercato, come CRM, ERP, Document Management ecc. (es. SAP, Documentum, Peoplesoft ecc. )? Come? 6. Permette di esporre tutto il processo o parti di esso come web services? 7. Quali sono le modalità di licensing? 24 febbraio 2009 Pag. 83
- 84. Consigli e raccomandazioni Esecuzione 1. E’ possibile visualizzare lo stato delle singole istanze? E’ possibile forzarne lo stato, ad esempio eseguendo una procedura correttiva per un’istanza bloccata? 2. E’ possibile inviare alert, ad esempio se un determinato KPI va sotto un certo valore per un’istanza? E’ possibile, nello stesso scenario eseguire attività compensative in modo dinamico per la singola istanza di processo? 3. Permette di eseguire contemporaneamente versioni diverse dello stesso processo? Permette di schedulare il passaggio a una nuova versione? Come si comporta con le istanze attualmente running: si può decidere se farle passare alla nuova versione o se farle terminare sulla vecchia? 24 febbraio 2009 Pag. 84
- 85. Un esempio di processo...ben orchestrato ☺ http://www.youtube.com/watch?v=DjqQqS3xkXU 24 febbraio 2009 Pag. 85
- 86. Bibliografia e sitografia : 1. “Architetture Enterprise”, A. Sinibaldi, Infomedia, 2008 2. “La Gestione dei processi in azienda”, A. Sinibaldi, in lavorazione 3. “BPM basics for dummies”, K.K.Garimella, M.J.Lees, B.D.Williams, Wiley Publishing, free download da http://www.softwareag.com/Corporate/res/books/default.asp 4. http://soa-eda.blogspot.com/2007/08/what-is-eai.html 5. http://www.informatik.uni-hamburg.de/TGI/PetriNets 6. http://www.validar.com/PDF/WfMC/docs/98205871/Final_Specification_Draft.pdf 7. http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/ 8. http://is.tm.tue.nl/research/patterns/patterns.htm 9. http://www.bpelsource.com/ 10. http://www.bptrends.com 11. http://www.bpminstitute.org 24 febbraio 2009 Pag. 86
- 87. Bibliografia e sitografia : La Gestione dei Processi in azienda (work in progress) 24 febbraio 2009 Pag. 87
- 88. Grazie a tutti per la cortese attenzione! Domande? alessandro_sinibaldi@virgilio.it 24 febbraio 2009 Pag. 88