BPM notations dominate the process modeling arena, however IDEF3 keeps some unique features.

1. IDEF3

2. COS’È IL MODELLO DI UN PROCESSO? La descrizione di un processo e dei suoi componenti, rappresentati in sequenza temporale. La rappresentazione della logica decisionale che può esistere tra gli elementi del processo. “Simply put, the Process Model is the way that work is divided in a value delivery system” James B. Swartz

3. CARATTERISTICHE DI IDEF3 Metodo per “catturare” la descrizione dei processi (Process Description Capture Method) Metodo per “catturare” la descrizione delle trasformazioni degli elementi di un processo (Object State Transition Description Method) Permette la descrizione dei processi a qualsiasi livello di dettaglio grazie ad una tecnica di “Scomposizione” Utilizza il concetto di “Scenario” per semplificare la descrizione di processi strutturalmente complessi Supporta la “cattura” di punti di vista diversi

4. IDEF3 Overview Sezione 1 Gli elementi di base dei Modelli Sezione 2 Descrizione delle UOB’s Sezione 3 Completamento della descrizione

5. GLI ELEMENTI DI BASE DEI DIAGRAMMI Unit of Behavior (UOB) Links Junctions

6. UNITS OF BEHAVIOR (UOB’S) Funzioni Azioni Attività Atti Operazioni Decisioni Procedure Rappresentati da Verb-based Label Node # IDEF Ref #

7. LINKS Scopo Descrivere le relazioni tra UOB’s di tipo temporale, logico, convenzionale, o naturale. Tipi di Links Precedenza Object Flow (*) Relazione (*) Vettore di Oggetti

8. Accendere il PC Login 1 2 PRECEDENCE LINK Esprime un semplice legame di precedenza tra “istanze” di diverse UOB’s. Ogni “istanza” della UOB a monte deve essere completata prima che la corrispondente “istanza” della UOB a valle possa iniziare. “Bisogna accendere il PC prima di fare login”

9. Verniciare una Parte Asciugare una Parte 1 2 OBJECT FLOW LINK Indica la “partecipazione” di un oggetto a due istanze del processo. Ha lo stesso significato temporale del precedence link. L’assenza di Object Flow link non significa che non ci sia un oggetto che “partecipa” alle due istanze del processo. C’è un oggetto (Parte) che è in comune con due UOB’s

10. Attività A Attività B 1 2 RELATIONAL LINK* Precede Immediatamente/Da inizio/Causa (Trigger)/Abilita/Si sovrappone/

11. JUNCTIONS Indicano la convergenza o divergenza di flussi del processo e la loro temporizzazione. 2 4 J1 J2 6 1 3 5 Fan-out junction Fan-in junction

13. Synchronous AndTutte le UOB a monte/valle devono iniziare/finiresimultaneamente

14. Asynchronous Or Una o più UOB a monte/valle deve iniziare/finire

15. Synchronous OrUna o più UOB a monte/valle deve iniziare/finiresimultaneamente.

17. NOTAZIONE SYSTEM ARCHITECT & Precedence Link Junction RelationalLink ObjectFlowLink Stakeholder (Funzione) Stato di un Oggetto Snodo Logico Legame di Precedenza Unit of Behavior (Elaboratore di Oggetti) Correlazione/ Trigger Vettore di Oggetti Controllo / Condizione

18. Descrizione delle UOB UOB’s Elaboration Referents

19. UOB Label Node # Elaboration Form UOB Label: UOB Reference Number: Objects: Facts: Constraints: Description: ELABORATION*

20. TIPI DI REFERENT UOB Punta direttamente ad altre attività del processo Go-to Usato invece di un link in modelli molto complessi Junction Specifica dei vincoli per le junctions OSTN Indica un legame con un diagramma OST Object Scenario Elaboration Note

21. Completamento della descrizione Scenario Decompositions Swim Lanes Diagrammi Object State Transition

22. SCENARIO Scenario è la struttura di riferimento di un modello IDEF3 e dei suoi elementi. Uno scenario rappresenta una situazione che succede abitualmente (as-is) o che dovrà verificarsi in futuro (to-be) Le diverse descrizioni dello stesso modello da parte di persone diverse possono appartenere a diversi scenari. Almeno uno scenario di base deve essere definito.

23. Elementi di uno Scenario Viewpoint Definisce cosa rappresenta il modello e da quale prospettiva viene descritto. Proposito Stabilisce cosa si intende realizzare mediante la descrizione del modello. Definisce perché il modello viene sviluppato, e come verrà utilizzato. Contesto Stabilisce il soggetto della descrizione. Definisce il soggetto come parte di un tutto. Crea i confini dell’ambito del modello.

24. DECOMPOSITION Caratteristiche Diminuisce la complessità di un diagramma. Consente la descrizione di un modello a vari livelli di astrazione. Fornisce uno strumento per descrivere lo stesso processo da diversi punti di vista. Sintatticamente, una “decomposition” non è che un altro diagramma IDEF3 PF.

25. TIPI DI DECOMPOSITION Objective view Diverse decompositions possono essere consolidate in una sola “objective view”, quella percepita da un osservatore neutrale. Pertanto, ci può essere una sola “objective view”. Role view La rappresentazione di un processo al punto di vista di un singolo individuo, di un tipo di ruolo, o di una funzione aziendale. Perciò, ci possono essere più di una “role view” dello stesso processo.

26. Il Cliente riceve il Materiale Fornitore x evade lo Ordine Trasporto del Materiale Il Cliente piazza un Ordine 4.1 2.1 3.1 1.1 ESEMPIO:“Ordine d’Acquisto” (1/2) Top-level Scenario: L’ombreggiatura indica che c’è scomposizione

27. Il Cliente riceve il Materiale Fornitore x evade lo Ordine Trasporto del Materiale Il Cliente piazza un Ordine 4.1 2.1 3.1 1.1 Il sistema genera la lista di riscontro Un addetto invia il file al centro stampa Il sistema verifica i dati della parte con l’ordine Un addetto digita la descrizione della parte 8.1 6.1 7.1 5.1 ESEMPIO:“Ordine d’Acquisto” (2/2) Scomposizione del Processo in “Tasks”

28. LE “SWIM LANES”:Esempio “Certificazione” Attività svolte dal team Qualità Attività svolte dall’Ente di Certificazione

29. ANALISI DEGLI OGGETTI Gli oggetti e i processi correlati possono essere analizzati utilizzando gli: Object State Transition Network (OSTN)

30. ELEMENTI DI UN OSTN Object State Label Object State Transition Arc Referents

31. Object State Entry Conditions State Description Exit Conditions OBJECT STATE ELABORATION

32. ESEMPIO di OSTN:Verniciatura L’oggetto in transizione è: “Vernice”

33. Diagramma OSTN Consente la costruzione di una vista centrata sull’oggetto. Sintetizza tutte le trasformazioni che l’oggetto subisce nel dominio descritto. Usato per documentare il ciclo di vita di un oggetto Taglia trasversalmente i diagrammi di flusso Caratterizza il comportamento dinamico (tempo) di un oggetto

34. ESEMPIO OSTN:Richiesta di Acquisto L’oggetto in transizione è: “RdA – Richiesta d’Acquisto”

35. Modelli IDEF3 Lettura Costruzione

36. Lettura dei Modelli IDEF3 Studiare lo Scenario (contesto, proposito, e viewpoint) per capire lo scopo del modello. Leggere i diagrammi di flusso da sinistra a destra. Leggere un diagramma in questo modo è chiamato in Inglese: “performing a walkthrough.” Esaminare attentamente la Description e la Elaboration di ciascun elemento del diagramma.

37. COSTRUZIONE DEI MODELLI IDEF3:Alcuni suggerimenti pratici Non far seguire a uno snodo XOR (fan-out junction) una giunzione AND (fan-in junction). Evitare di far confluire sulle UOB’s più di un link: la loro interpretazione diventa ambigua. Suddividere il flusso del processo prima della UOB in questione, usando uno snodo (fan-out junction). Per semplificare i diagrammi, evitare se possibile gli snodi nidificati. Uno snodo (fan-out junction) che segue immediatamente una giunzione (fan-in junction) può indicare che è stata dimenticata una UOB.

38. SYSTEM ARCHITECT Gestione degli "Eventi"

39. BUSINESS EVENTS Cos’è un “evento”? È un accadimento che causa l’inizio di un processo (trigger) Esempi di eventi del processo “Vendite”: vendita di un prodotto ricevere un ordine da un cliente ricevere un pagamento da un cliente rilasciare un prodotto a un cliente

40. NOTAZIONE SYSTEM ARCHITECT Evento “Trigger” Evento “Result”

41. FINE INIZIO A1 A4 Processo A A2 A3 Wait FINE INIZIO B1 B7 Processo B B6 B2 B4 B3 B5 SCHEMA GENERALEEventi/Triggers/Processi Evento Trigger

42. ESEMPIO 1:Eventi “Commerciale”

43. ESEMPIO 2:Eventi “Progettazione”

44. SIMULAZIONE

45. WHAT IS SIMULATION? Process models represent process-centered views of the modeled system and incorporate logical assumptions about how the system works. In simulation models, this process centered view becomes an object-centered view, allowing the modeler to numerically evaluate the performance of the model at discrete points of time.

46. CARATTERISTICHE DI IDEF3 (*) IDEF3 cattura gli aspetti “behavioral” di un processo esistente o da definire (temporizzazione), comprese le relazioni di causa ed effetto tra le attività (UOB) del processo. A differenza dei linguaggi di simulazione usati per costruire modelli matematici, IDEF3 fornisce una descrizione strutturata del processo che si desidera analizzare o del modello da realizzare Tale descrizione cattura le informazioni relative a cosa un processo fa o farà secondo il punto di vista di una o diverse persone.

47. CONCLUSION IDEF3 documents current processes for standardization and provides guidelines for new process members to reduce the learning curve. IDEF3 provides a mechanism to capture the temporal sequence of a process, the decision logic effecting the process, and the state transitions of objects within the process. IDEF3 serves as a tool to analyze existing processes and design and test new processes before embarking on expensive changes.

48. Eight Process Design Principles

49. PRINCIPLE 1 Process design is a design activity. Primarily creative in nature Find, copy, and adapt best practices Primarily iterative in execution Requires cost/performance/benefit/risk tradeoffs Simulation analysis ABC analysis No one single solution Not complete until specifications are produced

50. PRINCIPLE 2 Process design expertise is made up of a set of skills and the knowledge of how to apply those skills opportunistically. Constraint management / satisfaction Recognize difference between requirements and design goals Not a flow chart Progress not necessarily made in a linear fashion Should result in multiple alternatives that are subject to tradeoff analysis

51. PRINCIPLE 3 “Object design” plays a central role in the process design. Inputs and outputs Resources Intermediate objects Interface objects Object state transitions Object “quality” measures

52. PRINCIPLE 4 Processes must be specified to a level that can allow allocation to specific resources available in the execution environment. Decomposition into sub processes Termination condition of process design Processes will change as the skills and capabilities of the people and machines change

53. PRINCIPLE 5 Physical and logical input/output contiguity must be maintained (Conservation Law). Input/output of each process unit must be specified and matched with the input available and the output required at the position of the process unit in the process flow Drives decomposition Highly dependent on object design

54. PRINCIPLE 6 There will always be failures that must be addressed. Failure mode identification Failure mode analysis Failure detection sub process design Failure handling sub process design Robustness relative to failures

55. PRINCIPLE 7 Process design includes the design of process steps for by-product management. waste or scrap identify collect dispose

56. PRINCIPLE 8 Process design includes design of process steps and objects for execution coordination and management. Concurrent processes Resource allocation Work item prioritization Status, performance, traceability, data collection Interface management

57. Un Esempio

59. Il sistema di accettazione compila un ordine con i dati del cliente, la data le generalità delle cassette ordinate (codice, descrizione, quantità, prezzo) e l’importo totale. Fornisce poi il numero d’ordine alla contabilità che lo userà per recuperare gli ordini nuovi ed emettere fattura (codice, data, data scadenza, dati anagrafici cliente) al cliente.

60. La contabilità verificherà che la ricevuta di pagamento inviata dal cliente (tramite bollettino postale o pagamento tramite carta di credito) riporti correttamente importo e codice fattura di riferimento. Se il pagamento è corretto comunica il numero ordine al magazzino spedizioni che lo usa per recuperare l’ordine e spedire la/e cassetta/e al cliente. Se il pagamento è errato comunica il numero ordine all’ufficio solleciti.

62. Il sistema di accettazione compila un ordine con i dati del cliente, la data le generalità delle cassette ordinate (codice, descrizione, quantità, prezzo) e l’importo totale. Fornisce poi il numero d’ordine alla contabilità che lo userà per recuperare gli ordini nuovi ed emettere fattura (codice, data, data scadenza, dati anagrafici cliente) al cliente.

63. La contabilità verificherà che la ricevuta di pagamento inviata dal cliente (tramite bollettino postale o pagamento tramite carta di credito) riporti correttamente importo e codice fattura di riferimento. Se il pagamento è corretto comunica il numero ordine al magazzino spedizioni che lo usa per recuperare l’ordine e spedire la/e cassetta/e al cliente. Se il pagamento è errato comunica il numero ordine all’ufficio solleciti.

66. Il sistema di accettazione compila un ordine con i dati del cliente, la data le generalità delle cassette ordinate (codice, descrizione, quantità, prezzo) e l’importo totale. Fornisce poi il numero d’ordine alla contabilità che lo userà per recuperare gli ordini nuovi ed emettere fattura (codice, data, data scadenza, dati anagrafici cliente) al cliente.

67. La contabilità verificherà che la ricevuta di pagamento inviata dal cliente (tramite bollettino postale o pagamento tramite carta di credito) riporti correttamente importo e codice fattura di riferimento. Se il pagamento è corretto comunica il numero ordine al magazzino spedizioni che lo usa per recuperare l’ordine e spedire la/e cassetta/e al cliente. Se il pagamento è errato comunica il numero ordine all’ufficio solleciti.