Methods and Tolls for Business Process Modeling Operations Management Dr. Giuditta Pezzotta Università degli Studi di Bergamo 2011 Riproduzione riservata http://cels.unibg.it 1 Objectives of the lesson Understanding the meaning of a process modeling Making an analysis of the possible modeling tools Getting to know and use ARIS and IDEF0 Apply these tools to a case study Docente: Sergio Cavalieri 2 1
Process Model A model is a simplified and reduced representation of reality. Simplified because reality is too complex to copy exactly and much of the processes complexity is irrelevant to a specific problem. Process model helps to clarify the steps involved in a particular process. It is used for: understanding the current processes clarifying responsibilities identifying process inefficiencies designing new procedures considering the identified improvement (BPR) managing the company knowledge and training Docente: Sergio Cavalieri 3 What is a model? - a representation of the real thing. It is built to a certain scale and certain level of detail. It is built for a purpose and to show a view point. Why use a Business Modelling Method? - to have a consistent way of documenting and analysing a whole business. Why use a Business Modelling Tool? - it encourages standardization and use of process vocabulary, improves quality, allows multiple view points, provides analysis tools and represents the starting point for development of software systems. Docente: Sergio Cavalieri 4 2
Model - Benefits The benefits of modeling are: The cost of virtual experimentation is much lower than the cost of experimentation with a real system Models allow for the simulated compression of time. Manipulating the model is much easier than manipulating the real system. The cost of mistakes are much lower in virtual experimentation Modeling allows a manager to better deal with the uncertainty by introducing what-ifs and calculating the risks involved in specific actions Mathematical models allow the analysis and comparison of a very large number of possible alternative solutions Models enhance and reinforce learning and support training Docente: Sergio Cavalieri 5 How to produce a process map Consult with the experts. These are the people managing and working with the process. Identify the main objectives Identify the boundaries considering the objectives Identify the participants. Who in involved in the process and their responsibilities Identify the phase Identify the decision points. Identify the correct methods and tools to reach the objectives Draw an initial process flow using standard symbols selected. Check for completeness. Review with the experts to ensure completeness. Use the final model Docente: Sergio Cavalieri 6 3
Which tools There are many tools, but be careful: A tool is not only a software is more correct to define it as methodology Different methods highlight different features of the process The choice of methodology depends on the context and objectives and not vice versa Docente: Sergio Cavalieri 7 Methodologies STATIC TECHNIQUES OF BPM DYNAMIC TECHNIQUES OF BPM Functions Show processes as interrelated activities Show the flow of entities (control, information, materials, etc..) through activities Support analysis and experimentation with alternative process structures Support communication through animation and visualization Support user interaction with the process model Typical Methodologies Process Flowcharting Data Flow Diagramming IDEF0 (Function Modelling) IDEF1x (Data/Information Modelling) IDEF3 (Process Modelling) Basic Petri Nets RAD (Role Activity Diagramming) Discrete-event Business Process Simulation Systems Dynamics Timed Petri Nets Docente: Sergio Cavalieri 8 4
What is IDEF? Definition: IDEF is the common name referring to classes of enterprise modeling languages. Objective: IDEF is used for modeling activities necessary to support system analysis, design, improvement or integration. Originally, IDEF was developed to enhance communication among people trying to understand the system. Now, IDEF is being used for documentation, understanding, design, analysis, planning, and Integration. Docente: Sergio Cavalieri 9 IDEF History In the 1970 s, IDEF0 originated in the U.S. Air Force under the Integrated Computer Aided Manufacturing(ICAM) program from a wellestablished graphical language, the Structured Analysis and Design Technique (SADT). Docente: Sergio Cavalieri 10 5
IDEF Family IDEF Family of Methods: IDEF0: for Function Modeling (purpose:description) IDEF1: for Information Modeling. (purpose:description) IDEF1x: for Data Modeling. (purpose:design) IDEF3: for Process Modeling. (purpose:description) IDEF4: for Object-Oriented Design. (purpose:design) IDEF5: for Ontology Description Capture. (purpose:description) Docente: Sergio Cavalieri 11 IDEF0- Function Modeling Method Syntax: It is based on the box and arrow approach. Controls Inputs Function Name Outputs Mechanisms Docente: Sergio Cavalieri 12 6
Boxes Solid lines Verb or verb phrase Box number Assemble parts A3 Docente: Sergio Cavalieri 13 Arrows: ICOM Input: Describe resources or data that are needed to perform the function and are transformed by the function into outputs. Control: Describe the conditions, rules, procedures, or circumstances that govern the execution of the function. An arrow is a control unless it obviously serves only as input. Each function should have at least one control arrow. Most of controls are in the form of data. Output: The data or objects produced when the function is performed. Mechanism: Define the supporting mechanisms that carry out the function. A mechanism may be a person, an organizational unit, a physical device, or a computer program. Docente: Sergio Cavalieri 14 7
Box and Arrow Syntax Rules Boxes Boxes shall be sufficient in size to insert box name. Boxes shall be rectangular in shape, with square corners. Boxes shall be drawn with solid lines. Arrows Arrows that bend shall be curved using only 90 degree arcs. Arrows shall be drawn in solid line segments. Arrows shall be drawn vertically or horizontally, not diagonally. Arrow ends shall touch the outer perimeter of the function box and shall not cross into the box. Arrows shall attach at box sides, not at corners. Docente: Sergio Cavalieri 15 More Box and Arrow Syntax Rules 1. A box shall be named with an active verb or verb phrase. 2. Each side of a function box shall have a standard box/arrow relationship: a. Input arrows shall interface with the left side of a box. b. Control arrows shall interface with the top side of a box. c. Output arrows shall interface with the right side of the box. d. Mechanism arrows (except call arrows) shall point upward and shall connect to the bottom side of the box. 3. Arrow segments, except for call arrows, shall be labeled with a noun or noun phrase unless a single arrow label clearly applies to the arrow as a whole. 4. Arrow labels shall not consist solely of any of the following terms: function, input, control, output, mechanism Docente: Sergio Cavalieri 16 8
IDEF0- Context Diagram Syntax: Context Diagram: is a model of the function at the highest level of inputs, controls, outputs, and mechanisms.. Controls Inputs Function Name Outputs Mechanisms Docente: Sergio Cavalieri 17 IDEF0- Decomposition Diagram Decomposition Diagram: links together the context diagrams Docente: Sergio Cavalieri 18 9
IDEF0 Hierarchical Structure C1 I1 I2 O1 A-0 GENERAL I1 C1 1 I2 2 3 4 O1 Abstraction A0 The diagram A0 is the "parent" of the diagram A4. A4 1 2 3 Refinement 1 Università degli Studi di Bergamo 2011 A42 Riproduzione riservata 2 3 DETAILED Docente: Sergio Cavalieri 19 IDEF0- STRENGTHS The model has proven effective in detailing the system activities for function modeling. IDEF0 models provide an abstraction away from timing, sequencing and decision logic. However, it is easy to use IDEF0 for modeling activity sequences whenever needed. (Order the activities from left to right in the decomposition diagram). Provides a concise description of systems, by using the ICOMS. (Inputs, Controls, Output, Mechanism) The hierarchical nature of IDEF0 allows the system to be easily refined into greater detail until the model is as descriptive as necessary for the decision making task. Docente: Sergio Cavalieri 20 10
IDEF0- WEAKNESSES IDEF models might be so concise that only the domain experts can understand. IDEF models are sometimes misinterpreted as representing a sequence of activities. The abstraction away from timing, sequencing and decision logic leads to comprehension difficulties for the people outside the domain. Docente: Sergio Cavalieri 21 IDEF0 Example 11
Inter-Box Connections (arrows for child diagram) 23 Boundary Arrows: Arrows from parent box on parent diagram Coded by prefix and number 24 12
Introducing ARIS Arhitecture of Integrated Information Systems, prof. Scheer ARIS is not a tool, but a concept.it can model: - processes - data - organisations - information - product - knowledge - business objectives Docente: Sergio Cavalieri 25 ARIS ARIS includes: - an arhitecture for describing business processes - a set of modelling methods - the foundation of the ARIS Toolset software system - a concept for computer-aided business process management Docente: Sergio Cavalieri 26 13
The ARIS House Docente: Sergio Cavalieri 27 Event Process Chain (EPC) Materials mgmt Executive mgmt Sales Organizational view Disposition Inventory Offer Request Request received Sales processing Customer Request Request processing Request processed Offer processing Sales Request processing Check Credit worthiness Determine delivery date Offer processing Data view Control view Functional view Docente: Sergio Cavalieri 28 14
EPC (Example) Note the multiple start and end events Docente: Sergio Cavalieri 29 Basic elements of EPC Event Event: start points and end points of processes. They can represent midway positions in a process. Function Activity: they model the elaborative units of the process. They are activated by events. Organizational unit Organizational resourse: they model the human resources available for the process Logic connectors and links: they model the relation between events, activities and organizational resources Docente: Sergio Cavalieri 30 Docente: Sergio Cavalieri 30 15
Event Process Chain basic elements Organizational resource Start Start event Personnel executes contributes to F1 Intermediate event Activity E1 E2 Personnel F11 F12 Personnel Logic operator End Link End event Docente: Sergio Cavalieri 31 Evento Unità organizzativa Sistema applicativo Basic elements of EPC Attività Unità organizzativa Cluster Evento Unità organizzativa Document Sistema applicativo File And Posizione Attività Unità organizzativa Posizione Event Cluster Information Object Documento Xor Or Persona interna Persona esterna Tipo entity Tipo relazione Organisation Unit Tipo entity Telefono Persona interna Persona esterna Function Tipo relazione Fax Docente: Sergio Cavalieri 32 16
Basic elements of EPC Cluster Cluster: It models cluster of information and data (eg: a invoice, a order...), which is not specified the structure. System function System function: It represents activities automatically developed, without organizational resources. Application system Application system: It represents IT resources to support the process. Docente: Sergio Cavalieri 33 Representation of process flow Logic operators: They have two main functionality: Ramification of process. Junction of process flow AND OR XOR Docente: Sergio Cavalieri 34 17
Representation of a process flow. An example Docente: Sergio Cavalieri 35 Representation of a process flow. An example customer order modification claim Management orders portfolio Classification order Goods in stock Goods to be ordered Docente: Sergio Cavalieri 36 18
General rules to remember Each process begins and ends with one or more events. When the activity is identified, it is necessary to identify immediately the person who performs it. Any activity should be followed by an event. Avoid cycles. Beware of logical operators! Università degli Studi di Bergamo 2010 Riproduzione riservata Docente: Sergio Cavalieri 37 Forbidden links Event Events DON T have decisionmaking power Function Link XOR forbidden Function Link OR forbidden Event Function Function Università degli Studi di Bergamo 2010 Riproduzione riservata Docente: Sergio Cavalieri 38 19
Advance payment advance is transmitted/ paid is canceled Cancellation Planned trip must be canceled expenses reimbursement must be canceled costs cancelation statement is transmitted expenses reimbursement is rejected Payment amount transmitted to bank/ payee Unrequested trip has taken place Planned trip is rejected costs must be included in cost accounting Approved trip has taken place Need for trip has arisen Entry of a travel request is requested Approval of travel request Planned trip is approved Entry of trip facts facts and receipts have been released for checking Approval of trip facts facts are released for accounting Travel Expenses Payments must be released Need to correct planned trip is transmitted Approval of trip facts is transmitted Accounting date is reached Payment must be eff ected Amounts relevant to accounting transmitted to payroll accounting Amounts liable to employment tax transmitted to payroll costs statement is transmitted 10/12/2011 Subprocess Need for trip has arisen Entry of a travel request is requested subprocess Approval of travel request Planned trip is rejected Planned trip is approved Need to correct planned trip is transmitted Hierarchical view Start activity 2 Function Function Function Function Function The terminal events Drill-down must be sull attività the same of the higher level End Docente: Sergio Cavalieri 40 20
Strengths and weaknesses of the ARIS Set of models and methods to select considering the context under analysis Clear visual representation of processes The hierarchical approach allows to describe the process at different levels of detail Timelines are clearly identified BUT.. The model can result very complex. A good experience is needed to determine which models should be used in each case Docente: Sergio Cavalieri 41 21