Business Process Modeling Across the Life Cycle Sponsored by: Howard Podeswa Principal Consultant, Process Impact www.nobleinc.ca
Sponsor: BonitaSoft Bonita Studio Drag-n-drop process application development BPMN 2.0 compliant Simulate process execution Connect with other outside databases and applications The leader in Open Source Business Process Management 1,600,000 DOWNLOADS 40,000 COMMUNITY MEMBERS 500+ CUSTOMERS 100 EMPLOYEES 90 TECH & SI PARTNERS 2
Featured Speaker Howard Podeswa CEO, Noble Inc. Since 1998, Noble Inc. has been providing Business Analysis training and consulting services to clients across the globe in a broad range of sectors including finance, government, insurance, new technology, resources, telecom, health and media with an illustrious client list that includes the International Standards Organization (ISO), the Mayo Clinic, Bell Nexia and Thomson Reuters. Phone #: E-mail: Blog: (416) 532-2205 info@nobleinc.ca www.nobleinc.ca 3
Business Process Modeling Across the Life Cycle All rights reserved. The material contained in this presentation is protected under the copyright laws of Canada and the United States. This material may not be reproduced in any form or by any means without the written permission of Noble Inc. Any infringement of these copyrights or trademarks will be prosecuted to the full extent of the law. 2012 by Noble Inc. All rights reserved. info@nobleinc.ca www.nobleinc.ca 4
Session Objectives Understand what Business Process Modeling (BPM) is and the rationale for doing it. Understand how BPM is applied across the project lifecycle. 5
Business Process Modeling Across the Life Cycle Part 1 The Business Case for BPM 6
Business Process Modeling What? The representation of current ("as is") and proposed ("to be") enterprise processes, so that they may be compared and contrasted. Used for: - Business process improvement - Business impact analysis in preparation for an IT project. Standards used in this context include: - BPMN - UML - Use Cases 7
1960 s Evolution of BPM Business process automation drove the need for understanding how a system would implement a business process Flowcharts 1970 s, 1980 s, 1990 s Increasing complexity of business process automation demanded new tools and techniques IDEF models, data flow diagrams, Statechart diagrams 8
Evolution 1989: OMG (Object Management Group) founded Owns the UML (Unified Modeling Language) standard for OO (Object Oriented) systems. 1990 s: OO Analysis and Design matures Unified Modeling Language standard gains wide acceptance. Includes activity diagrams and state-machine diagrams for modeling sequencing rules 2005 BPMI (Business Process Management Initiative) and OMG merge business process management activities. OMG becomes owner of BPMN (Business Process Modeling Notation), an alternative to UML activity diagram for modeling workflow 9
More than a Diagram Any business process model is usually expressed as: One or more diagrams Different processes, different perspectives, different levels of detail Supporting text Definitions Explanations Decisions, algorithms, detailed business rules 10
Business Process Workflow Model A business process workflow model depicts Activities and their sequence Transitions Decisions How it begins and ends Optionally: Who does what Business objects created, altered or required at each step 11
Business Process Modeling Why? By comparing and contrasting current and proposed enterprise processes, business analysts and managers can identify specific process transformations that can result in quantifiable improvements to their businesses. 12
So why bother with the picture? Better than text for depicting complex workflows. Well-suited for comparison of alternatives, scope definition and gap analysis. Enables BA to consolidate partial stakeholder views of a process into one end-to-end picture. Straw man to stimulate discussion. Aids identification of bottlenecks. Enables standardization of processes across the organization. Visual training aid for new process workers. End-to-end models used to design integration tests. May be used to run simulations and to generate code Modeling is simpler, faster and cheaper than building the real thing 13
Business Process Modeling Contexts for BPM Business merger or takeover Introduction of new products or services Other transformational change: Elimination of redundant processes Automation of services and processes (reduce manual elements) Centralization of common business processes Change to underlying software systems or how they are used; system migration Process improvement: Identify and remove bottlenecks Reduce double entry Role changes IT change: To ensure impact on end-to-end business process is taken into consideration Exit interviews Operations training 14
Business Process Modeling Relevance for IT projects Important step in ensuring IT development supports the business process. Provides clear path from business needs to IT requirements: Business process is decomposed using BPM. Process models are used to identify and define IT tasks (system use cases) required to support the business process 15
Overview of BPM Across the SDLC Initiation: To model As-Is and To-Be business processes. Discovery: To model user tasks and the corresponding interactions with the IT system. Construction: Developers use BA models as input to interface and software design. Final V & V: QA uses BA models as input to integration test design. 16
Business Process Modeling Case Studies 17
BPM to Centralize Processes Case Study: MyFile A state-level government client has decided to centralize the delivery of services. MyFile is to be a single point of entry for all services offered by the government: - Automobile licences, grants, fines, etc. Noble is currently working with this client on analyzing the As-Is and To-Be workflow for affected processes. 18
BPM to Reduce Inefficiencies Case Study: CRM Noble worked with one of the Big Four financial services companies on a project to change their Customer Relations Management (CRM) processes. As-Is: - Uses 2 systems one for prospects; another for wins. - Requires wasteful double entry To-Be: - One of the current systems to be expanded to handle full cycle. 19
BPM to Decrease Turnaround Case Study: Insurance International insurance company has launched a transformational change initiative. Has determined that most insurance applications could be fast-tracked. As-Is: - Applications filled out and adjudicated manually To-Be - Automated end-to-end processing for most insurance applications 20
Business Process Modeling Across the Life Cycle Part 2 Business Process Modeling Toolkit 21
BPMN Toolbox What? - Business Process Modeling Notation - Popular standard for Business Process Modeling (BPM) - Overseen by the Object Management Group (OMG) - URL: www.omg.org - External process view modeled as public process - Internal workflow modeled as private process Why? - Widely used and understood within BPM community - Well-supported by model-driven process modeling, simulation and automation tools - Nuanced symbols allow for accurate modeling of workflow subtleties 22
Public Business Process (BPMN) As-Is To-Be Public Process: Manage claim 23
Private Business Process (BPMN) As-Is To-Be Private Process: Manage claim 24
Activity Diagram Toolbox What? - UML alternative for depicting workflow Why? - UML-compliance - Much can be conveyed using a basic set of intuitive symbols - Easy to learn and interpret When? - Initiation: May be used to model business processes instead of BPMN for UML compliance - Discovery: Appendix to system use cases to model complex flows 25
Example of Business Process using an Activity Diagram with Swimlanes (UML) Plan Pursuit Toolbox Marketing Local Office Pursuit Team National Client Acceptance Identify Target Client Select Pursuit Team Enter Opportunities & Contacts Create Pursuit Plan Validate Pursuit Plan Record Pursuit Evaluation Launch Pursuit [Accepted] [Rejected] Abandon Pursuit 26
Functional Decomposition Diagram Toolbox What? - Indicates decomposition of business functions into processes, activities and low-level tasks - Does not indicate sequencing Why? - Useful first step in creating new functions and processes: - Focuses on what must be done without worrying about sequencing - Helps navigate through more detailed models: - Workflow models: FDD provides overview of decomposition of processes and activities appearing in the workflow models - Data Flow Diagrams: FDD summarizes decomposition of processes across DFD levels 27
Functional Decomposition Diagram Format Function Process 1 Process 2 Activity 1.1 Activity 1.2 Activity 2.1 Activity 2.2 28
Example of FDD to describe a business area Toolbox (Source, The Business Analyst s Handbook Chapter 4, Page 178) 29
Context Diagram Toolbox What? - High-level model describing how the entity under discussion (business area or IT system) interacts with its environment. - Defines the border between what is in the system and what is outside of it its scope. - Does not indicate sequencing Why? - Focuses on big picture: What business areas or IT systems are inside and outside of scope? What stakeholders and/or external systems are impacted by the initiative? What is the nature of the communication between the area under discussion and external players and systems 30
Context Diagram Looks at business/system in context of its environment 31
Data Flow Diagram Toolbox What is a DFD model? - Set of leveled diagrams that describe the way that data moves through a system. - Level 0 DFD is context diagram; Level 1 DFD depicts the main processes; Further levels provide successively increasing degrees of detail. - May be business or system; logical or physical Why? - Often used in legacy documentation. - Enables top-down analysis - Effective means for analyzing the informational needs of processes. - Effective in checking for completeness: Formal standard violations often point to missing requirements. 32
DFD Levels 33
State Diagram What? Toolbox Used to model the rules that govern how an object passes from state (status) to state over its lifecycle Included as part of the UML standard May be used to model lifecycles of wide array of business objects, such as: - Application (for Credit, Insurance, etc.) - Change Request - Incident Report - Insurance Claim 34
State Diagram Why? Provides an overview of the life cycle of business objects across business processes and user requirements Helps identify holes in business processes - Enables a visual check that the object transitions from status to status as required by the business Helps identify bottlenecks - E.g., metrics can be gathered for each state to determine where a business object is getting stuck. 35
The State-Machine Diagram: Lifecycle of a Purchase Initial Make purchase event state Created Apply royalties Paid guard [successful] [payment denied] choice Payment Pending Customer makes alternative payment Royalties applied transition Final 36
Business Use Case Toolbox What? An interaction with a business area that provides value to those outside the business area (a customer, a vendor, another sector, an external system ) Why? - Provides a basis for discussion about the scope of the business improvement project. - Identifies which stakeholders will be impacted by current and subsequent changes. 37
Business Use-Case Diagram Toolbox As-Is To-Be Customer Customer Service Rep Manage claim Policy Management Manager Customer Services Adjuster Finance 38
System Use Case What? Toolbox Definition: - Use Case: The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. (UML 2) - System Use Case: a use case for which the system is an IT system Describes all of the ways that the interaction could possibly play out. 39
System Use Case Why? Focuses on user s experience Separates true user needs from implementation considerations by excluding design issues Narrative style and short length makes it suitable for verification by business stakeholders Separation into flows eases identification of test cases Style well-suited for deriving test scripts Well-suited for planning what functionality increments to include in each iteration of an iterative/agile project 40
(System) Use Case Diagram Pay bills <<include>> <<include>> Verify funds Customer Transfer funds Add Payee Manager Customer 41
Business Process Modeling Across the Life Cycle Part 3 BPM Over the Course of a Project 42
Case Study The following case study pulls together some of the tools and guidelines used by the BA over the course of a project: An insurance company is proposing changes to the way Insurance Claims are managed. The BA has been brought in to facilitate the business process improvement initiative and see it through IT system requirements analysis. Here is how the tools and standards are used as the project progresses: 43
Initiation During Initiation: High Level Requirements Documentation is created. It provides the business context for the initiative and enough detail to estimate the size of the IT effort. 44
High Level Requirements Documentation Documentation contains the following elements: Business use-case diagram Public Business Process Models (Facades) Private Business Processes (Cross-functional workflow) System Use-Case Diagrams 45
Business use-case diagram As-Is To-Be Customer Customer Service Rep Manage claim Policy Management Manager Customer Services Adjuster Finance 46
Public Business Process (Business Use-Case Specification) As-Is To-Be Public Process: Manage claim 47
Business Use-Case Description (Specification) Business Use Case: Manage a Claim As-Is To-Be Description Process a claim against an insurance policy. Actors Business actors: Customer, Policy Management, Finance Metrics Claims per day % errors Repeatability Post-conditions Claim Resolution sent to Customer. Successful Claims result in Payment request sent to Finance. more 48
Business Use-Case Description (Specification) Business Use Case: Manage a Claim As-Is To-Be Basic Flow 1. Customer submits claim. 2. Claims receives the claim. 3. Claims verifies policy coverage. 1. Claims sends Check coverage message (request) to Policy Management and waits for a response. 4. Claims approves the claim. 1. Claims sends issue payment message to Finance. 2. Claims sends approved message (claim resolution) to Customer. The use case ends. Alternate Flows 4a) Claim denied:.1 Claims sends denied no coverage message (claim resolution) to Customer. The use case ends. Open issues: 1. What happens if claim is denied at later stage? 49
Private Business Process (Business Use-Case Realization) As-Is To-Be Private Process: Manage claim 50
From Business to IT System Requirements As-Is To-Be Circled activities represent IT tasks 51
System Use-Case Diagram As-Is To-Be 52
Detailed Requirements Specification System use cases are detailed according to the level of risk associated with each one: Low-risk use cases require a brief description only. Medium risk use case require a description of the Basic (Normal) Flow and a list of Alternate Flows (scenarios) and how they are to be dealt with. High-risk use cases require full documentation. 53
System Use-Case Description (Specification) System Use Case: Resolve a Claim As-Is To-Be Description Make final resolution on claim. Actors Manager Customer Services Customer Finance Metrics 50 claim resolutions per day 80% claims approved with no changes 10% claims approved with changes 10% claims denied Pre-conditions Adjuster s Report has been submitted. An authorized Manager Customer Services user has been identified. Post-conditions Claim Resolution sent to Customer. Successful Claims result in Payment request sent to Finance. more 54
System Use-Case Description (Specification) System Use Case: Resolve a Claim As-Is To-Be Basic Flow: Approve claim with no changes 1. System displays claims awaiting final approval. 2. User selects claim. 3. System displays adjuster s report. 4. User approves report with no changes. 5. System sends message to Finance to Issue payment. 6. System sends Claim Resolution (approved) to Customer. The use case ends. Alternate Flows 4a) Override selected:.1 User changes adjustment amount. Continue at step 5. 4b) Claim denied:.1 System sends Claim Resolution (denied) to Customer The use case ends. 55
System Use-Case Appendix: Activity Diagram As-Is To-Be 56
Business Process Modeling Across the Life Cycle Part 4 Guidelines for BPM 57 57
Guidelines and best practices Don t over-analyze Be only as formal as necessary Hand-drawn diagrams are sufficient for agile life cycles Perform BPM regardless of formality of the SDLC and documentation Diagrams for stakeholders use should be as simple as possible Stick to basic set of symbols Use notes instead of complex flows for hard-to-model sequencing rules 58
Guidelines and best practices Keep # activities on a diagram down by rolling up smaller activities into higher-level activities Don t expect to get it right the first time; develop models iteratively Begin with a best guess Refine through stakeholder feedback 59
Adapting BPM for agile life cycles Both stakeholders and developers are in the room as model is developed BA is facilitator of communication, not an intermediary between both sides BA role is not likely to be played by a dedicated individual Just-in-time analysis (vs. all upfront) More frequent feedback Less formal documentation Estimation performed at lowest level available at the time; refined as project proceeds 60
Top-Down Approach to Requirements Analysis As-Is To-Be Business Goals User Goals Receiver <<include>> Adjust inventory Receive product <<include>> Sales Sell product Basic Flow Detailed User Req s Detailed Specifications System use case: Withdraw Funds [ Basic Flow 1. The customer inserts a card. 2. The customer enters a PIN. 3. The system verifies the PIN. (A1) 4. The customer enters transactions details. 5. The system verifies the transaction. (A2) Alternate Flows A1 Invalid PIN: A1.1 The system gives the customer 3 chances to supply a correct PIN, after which the system destroys the card. A2 Insufficient funds in account: A2.1 The system displays the funds available for withdrawal. Continue at Step 4. Alternate 1. Customer Flow: A1 inserts card 2. Customer [ up to 4 attempts ] enters PIN 3. System verifies PIN [ invalid PIN ] [ 4th attempt ] [ else ] A1.1 System destroys card 4. Customer enters transactions details Alternate 5. System verifies Flow: A2 transaction [ insufficient funds in account ] A2.1 System displays funds available 6. System ejects ATM Card 7. System 8. System debits dispenses funds source account Alistair Cockburn, 2000 61
Adapting BPM for large scrum projects End-to-end business processes entered into the Product Backlog as epic user stories by Chief Product Owner (CPO)/ Portfolio Manager. BPM models created for high to medium priority/risk epic user stories modeled to derive small user stories (system use case scenarios) User stories entered into Product Backlog; divided amongst teams Lower-level models are created as development nears Integration/Gap Team focuses on interfaces between Teams Dedicated members or virtual team Looks for requirements that have fallen between teams Responsible for integration testing 62
Sponsor: BonitaSoft Free Download of Bonita Open Solution A Complete Open Source Business Process Management Suite: Bonita Studio for process modeling Bonita User Experience for user and stakeholder access Bonita Execution Engine runtime environment 63
Any questions? The Leader in Open Source Business Process Management Mac McConnell marketing@bonitasoft.com Bonitasoft.com https://twitter.com/bonitasoft https://www.facebook.com/bonitasoftbpm http://www.linkedin.com/company/bonitasoft Interest in Noble Courses? For more information, please contact Noble Inc. at: info@nobleinc.ca Or visit our Web-site at www.nobleinc.ca 64