Business Process Modelling - 12.2/2013 - Marcello La Rosa Queensland University of Technology Brisbane, 17 October 2013.

Slides:



Advertisements
Similar presentations
Writing Good Use Cases - Instructor Notes
Advertisements

Chapter 6 Flowcharting.
Software Process Modeling with UML and SPEM
Module N° 7 – Introduction to SMS
A Vehicle to Promote Student Learning
Week 2 The Object-Oriented Approach to Requirements
Business Process Modelling -8.2/2013 -
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Chapter 1 Business Driven Technology
Systems Investigation and Analysis
Systems Development Environment
Process-oriented System Analysis Process Discovery.
The “Lifecycle” of Software. Chapter 5. Alternatives to the Waterfall Model The “Waterfall” model can mislead: boundaries between phases are not always.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
Systems Analysis and Design 9th Edition
Use-case Modeling.
Effective systems development requires a team effort from stakeholders, users, managers, systems development specialists, and various support personnel,
231 Business Modeling - Domain Analysis Most materials taken from the RUP textbook Chapter 8 and OOSE, pp
Fundamentals of Information Systems, Second Edition
Systems Analysis and Design in a Changing World, Fourth Edition
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Chapter 4: Beginning the Analysis: Investigating System Requirements
© INB/INN /2012 – 25 July 2013 Your Unit Coordinator A/Professor Marcello La Rosa Academic Director (corporate programs and partnerships) for IS.
IS&T Project Management: Project Management 101 June, 2006.
Internal Auditing and Outsourcing
Chapter 4: Beginning the Analysis: Investigating System Requirements
What is Business Analysis Planning & Monitoring?
S/W Project Management
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Requirements Elicitation Process Lecture-8.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
1 4 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 4 Beginning the Analysis: Investigating System Requirements.
Copyright 2002 Prentice-Hall, Inc. 1.1 Modern Systems Analysis and Design Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 The Systems Development.
Lecture 7: Requirements Engineering
Systems Analysis and Design 8 th Edition Chapter 2 Analyzing the Business Case.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Systems Analysis and Design in a Changing World, Thursday, Feb 1.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Process Modeling
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
1 Class exercise II: Use Case Implementation Deborah McGuinness and Peter Fox CSCI Week 8, October 20, 2008.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Requirements Workshop Techniques for E-Business Projects
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Prof. Marcello La Rosa BPM Discipline Queensland University of Technology.
Prof. Marcello La Rosa BPM Discipline Queensland University of Technology.
HCIS 410 Read, Lead, Succeed/Uophelpdotcom For more course tutorials visit
Business Process Modelling
Prof. Marcello La Rosa BPM Discipline Queensland University of Technology.
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
Chapter 33 Introduction to the Nursing Process
CHAPTER OVERVIEW The Case Study Ethnographic Research
Chapter 4: Business Process and Functional Modeling, continued
Lecture Software Process Definition and Management Chapter 3: Descriptive Process Models Dr. Jürgen Münch Fall
Business Modeling - Domain Analysis
CHAPTER OVERVIEW The Case Study Ethnographic Research
Presentation transcript:

Business Process Modelling / Marcello La Rosa Queensland University of Technology Brisbane, 17 October 2013

© INB/INN /2013 – 17 October 2013 Quick Repeat from Week 11 What is process identification? Why is it important to conduct process identification properly? What is a process architecture? What are the typical artifacts of a process hierarchy?

© INB/INN /2013 – 17 October 2013 BPM Lifecycle

© INB/INN /2013 – 17 October 2013 Process Discovery 1.Defining the setting: assemble a team in a company that will be responsible for working on the process. 2.Gathering information: build an understanding of the process. Different discovery methods can be used to acquire information on a process. 3.Conducting the modeling task: organize the creation of the process model. The modeling methodology gives guidance for mapping out the process in a systematic way. 4.Assuring process model quality: guarantee that the resulting process model meets different quality criteria. This phase is important for establishing trust in the process model.

© INB/INN /2013 – 17 October 2013 Who is involved? Domain ExpertProcess Analyst

© INB/INN /2013 – 17 October 2013 Challenge 1: Fragmented Process Knowledge Why can‘t I directly provide cash after approval? We bundle refinancing to get better interest rates. I make a photocopy before handing over the application Iterative validation process

© INB/INN /2013 – 17 October 2013 Challenge 2: Domain Experts think on Instance Level “Every trip is different” “You cannot really compare. Our customers go to different places in different seasons using different modes of transportation” “We can never do anything exactly in the same way. There are so many special conditions” Abstraction from instance level to process level

© INB/INN /2013 – 17 October 2013 Challenge 3: Knowledge of Process Modelling is uncommon “Could you please tell me, whether this diagram correctly shows your process?” Translation to natural-language

© INB/INN /2013 – 17 October 2013 What Makes a Good Process Analyst Getting the right people on board Formulate and test hypotheses Identify patterns Pay attention to model aesthetics

© INB/INN /2013 – 17 October 2013 Process Discovery Methods Evidence-based –Document analysis –Observation –Automatic process discovery Interview-based Workshop-based 10

© INB/INN /2013 – 17 October 2013 Document Analysis Documents point to existing roles, activities and business objects: –Process descriptions (ideal scenario) –Internal policies –Organization charts –Employment plans –Quality certificate reports –Glossaries and handbooks –Forms –Work instructions May not be process-oriented and trustworthy. Could be used to gather information before approaching domain experts. 11

© INB/INN /2013 – 17 October 2013 Observation Follow directly the processing of individual cases: –Active role: play a specific role, e.g. customer –Passive role: observe participants and their environment Trace business objects in the course of their lifecycle Active role: no big picture Passive role: participants’ bias 12

© INB/INN /2013 – 17 October 2013 Automated discovery via Process Mining 13 model /  event log event stream DB extract model Discovery Conformance

© INB/INN /2013 – 17 October 2013 Interviews Interview ModellingValidation Verification 14 Forward vs. backward Structured vs. unstructured Assumption: analyst and stakeholder share terminology Pitfall: exceptional behavior neglected > use questions that aim to identify such behavior

© INB/INN /2013 – 17 October 2013 Workshops Gather all key stakeholders together Participants interact to create shared understanding Typically one process analyst (facilitator), multiple domain experts, process owner may also attend May be software-supported, a model is directly created during the workshop (typically a separate role – tool operator) Model is used as reference point for discussions Alternative: brown-paper workshops Usually 3 to 5 half-day sessions

© INB/INN /2013 – 17 October 2013 Any Difference in Discovery? Consider the following two companies: Company A is young, founded three years ago, and has grown rapidly to a current toll of one hundred employees. Company B is owned by the state and operates in a domain with extensive health and security regulations. How might these different characteristics influence a workshop-based discovery approach?

© INB/INN /2013 – 17 October 2013 Discovery and Culture Before starting with process discovery, it is important to understand the culture and the sentiment of an organization. There are companies that preach and practice an open culture in which all employees are encouraged to utter their ideas and their criticism. Such organizations can benefit a lot from workshops as participants are likely to present their ideas freely. In strictly hierarchical organizations, it is necessary to take special care that every participant gets an equal share of parole in a workshop and that ideas and critique are not held back. It might be the case that the young dynamic company has a more open culture than the company with extensive health and security regulations. This has to be taken into account when organizing a workshop.

© INB/INN /2013 – 17 October 2013 Strengths and Weaknesses TechniqueStrengthWeakness Document AnalysisStructured information Independent from availability of stakeholders Outdated material Wrong level of abstraction ObservationContext-rich insight into process Potentially intrusive Stakeholders likely to behave differently Only few cases Automatic DiscoveryExtensive set of cases Objective data Potential issue with data quality InterviewDetailed inquiry into process Requires sparse time of process stakeholders Several iterations required before sign-off WorkshopDirect resolution of conflicting views Requires availability of several stakeholders at the same time

© INB/INN /2013 – 17 October 2013 Effort of Process Discovery Consider the order-to-cash process of your favorite online book retailer has ten major activities that are conducted by different persons. How much time do you approximately need for creating a process model that is validated and approved by the process owner? Make appropriate assumptions.

© INB/INN /2013 – 17 October 2013 Process Discovery Effort This process contains ten major activities that are executed by different persons. We can assume that there will be a kickoff meeting with the process owner and some important domain experts on day one. 1 day might be required to study the available documentation. An interview with one domain expert can take 2-3 hours, so we would be able to meet two persons per day, and document the interview results at nighttime (yes, at nighttime). Let us assume that we meet some persons only once while we seek feedback from important domain experts in 2 additional interviews. Then, there would be a final approval from the process owner. This adds up to 1 day for the kickoff, 1 for studying the documentation, 5 days for the first iteration interviews, and further 5 days if we assume that we meet 5 experts 3 times. Then, we need 1 day for preparing the meeting for final approval with the process owner, which would be on the following day. If there are no delays and scheduling problems, this yields = 14 days of work as a minimum.

© INB/INN /2013 – 17 October 2013 Organizing the Gathered Material 1.Identify the process boundaries 2.Identify activities and events 3.Identify resources and their handovers 4.Identify the control flow 5.Identify additional elements

© INB/INN /2013 – 17 October 2013 Process Boundaries Under which condition does the process start? With which result does it end? Which perspective do we assume? What data are required as input and output to the process?

© INB/INN /2013 – 17 October 2013 Identify Activities and Events

© INB/INN /2013 – 17 October 2013 Identify Resources and Handovers

© INB/INN /2013 – 17 October 2013 Identify Control Flow

© INB/INN /2013 – 17 October 2013 Process Modelling Quality Assurance Validity Completeness Structural correctness Behavioral correctness Understandibility Mantainability

© INB/INN /2013 – 17 October 2013 Is this process model of good quality? Deadlock

© INB/INN /2013 – 17 October 2013 Syntactic Quality: Verification

© INB/INN /2013 – 17 October 2013 Is this process model of good quality? Deadlock Labeling

© INB/INN /2013 – 17 October 2013 Formulate Labels Adequately Activities as Verb-Object Events as Object-Past-Participle Verb Conditions with reference to Object

© INB/INN /2013 – 17 October 2013 Semantic Quality: Validation Validity Completeness Domain ExpertProcess Analyst

© INB/INN /2013 – 17 October 2013 Pragmatic Quality – Example: Layout Better layout helps understanding

© INB/INN /2013 – 17 October 2013 Seven Process Modeling Guidelines (7PMG) G1 Use as few elements in the model as possible G2 Minimize the routing paths per element G3 Use one start and one end event G4 Model as structured as possible G5 Avoid, where possible, OR routing elements G6 Use verb-object activity labels G7 Decompose a model with more than 30 elements

© INB/INN /2013 – 17 October 2013 Example: explain which 7PMG guidelines point to potential for improvement. Remodel the process based on your observations.

© INB/INN /2013 – 17 October 2013 Solution

© INB/INN /2013 – 17 October 2013 Process Discovery - Summary Domain expert and process analyst have different strengths and limitations in process discovery There are various discovery methods Quality Assurance is important

© INB/INN /2013 – 17 October 2013 References Required Chapter 5 of textbook “Fundamentals of BPM” Recommended M. Rosemann, “Potential pitfalls of process modeling: Part A”. Bus. Process. Manag. J. 12(2), 249–254 (2006) M. Rosemann, “Potential pitfalls of process modeling: Part B”. Bus. Process. Manag. J. 12(3), 377–384 (2006) J. Mendling, H.A. Reijers, W.M.P. van der Aalst, “Seven process modeling guidelines (7PMG)”. Inf. Softw. Technol. 52(2), 127–136 (2010) J. Mendling, L. Sánchez-González, F. García, M. La Rosa, “Thresholds for error probability measures of business process models”. J. Syst. Softw. 85(5), 1188– 1197 (2012) J. Mendling, H.A. Reijers, J. Recker, “Activity labeling in process modeling: empirical in- sights and recommendations.” Inf. Syst. 35(4), 467–482 (2010) Books A. Sharp, P. McDermott, “Workflow Modeling: Tools for Process Improvement and Application Development”, 2 nd edn., Artech House (2008)

© INB/INN /2013 – 26 September 2013 A/Prof. Marcello La Rosa IS School Academic Director (Corporate Programs and Partnerships) BPM Discipline, IS School Science & Engineering Faculty Queensland University of Technology 126 Margaret Street Brisbane QLD 4000 Australia p +61 (0) e w