15.

Business Process Analysis [1]

Page 1 of 17

15. Business Process Analysis [1]

Bob Glushko (glushko@sims.berkeley.edu) Document Engineering (IS 243) - 14 March 2005

1. Plan for Today's Class

l

Two Process Modeling Challenges Introduction to Process Modeling The Abstraction Hierarchy in Process Models Meta-models for Business Process Modeling Assignment 5

2. Modeling Documents {and,vs,or} Modeling Processes

l

A document exchange consists of both the documents and the processes that produce and consume them By understanding the information in the documents, we learn what kinds of processes are possible By understanding the processes, we learn what kinds of information are needed

3. What Are You Doing Now?

l

If someone asks you "what are you doing now?" what might you say?

"I'm living in Berkeley and taking courses at the University" "I'm studying Document Engineering" "I'm listening to a lecture on business processes and was just asked what I was doing now"

You can answer the question at many different levels of abstraction What determines how you answer it?

4. Making a Pizza
1. Select recipe 2. Turn on as many lights as necessary to ensure adequate lighting in preparation and cooking area 3. Assemble required ingredients 4. Sift 1/2 kg of flour into a large mixing bowl (preferably plastic), and then add a pinch of salt and pepper (make sure your hands are dry first).

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

5. Follow the rest of the preparation instructions in the recipe to make the pizza. 6. Pre-heat the oven to 350 degrees Fahrenheit. 7. When the oven has reached 350 degrees, open the door, place the pizza in the oven, and close the door. 8. When the pizza is done remove it from the oven

Page 2 of 17

5. What's A Process? [1]

l

Process like model, pattern, component and other concepts we're dealing with is highly abstract and semantically overloaded, with a variety of formal and informal meanings A process is an goal-oriented activity that takes specified inputs and adds value to the inputs The goals, inputs, and added value can be just about anything

6. What's A Process? [2]

l

The output of one process can serve as the input to another process.

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 3 of 17

7. Business Process Analysis

l

We perform an "as-is" analysis of how the enterprise conducts its activities today We identify requirements that may result in new or revised activities / processes / transactions the "to-be" model We look for existing patterns or opportunities to use patterns in the models We may "re-engineer" the "as-is" model to optimize the processes; this is business process design

8. The Business Process Analyst (1)

l

Document engineering involves the analysis and modeling of both business processes and "documents," but it is useful to describe business process analysis as a separate specialty The primary roles of the business process analyst are those of any analyst (and those are?) Additional required skills

Ability to view and analyze a problem from the viewpoint of business goals, business requirements, and processes Familiarity with business reference models Less need for technology and implementation skills than the Document Analyst

9. The Business Process Analyst (2)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

l

Page 4 of 17

The business process analyst asks many of the same questions as the document analyst but the focus is on understanding the processes that produce and consume documents rather than on the documents themselves The business process analyst need to be comfortable talking with people at many organizational levels, from "factory floor" workers to executives

This is partly a question of vocabulary "value chain," "core competency," "ROI," "value proposition," "blah blah blah" But it is also a question of style the business analyst needs to think strategically, viewing technology as a means and not as an end in itself (as technologists often do)

10. Why We Analyze Business Processes [1]

l

To ensure that all participants, stakeholders, software providers, standards developers, etc. have a common understanding of the enterprise and business domain To understand the enterprise independent of its current or future technology To identify and understand gaps, inefficiencies, overlaps, and opportunities

Gaps things we should be doing but aren't Inefficiencies things we should be doing but are doing badly Overlaps things we should be doing but are doing redundantly Opportunities things we might want to do

11. Why We Analyze Business Processes [2]

l

Need for greater business speed and efficiency Need to evaluate potential new business partners; when two enterprises seek to "do business" with each other, they need to make their business processes compatible Need to prepare for new technology (like ERP) or business organization (M & A, restructuring) Need to capture "know how" for operations and training Need to manage human resources Need to comply with laws or regulations

12. What is a Business Process Model? (from Cousins & Stewart)

l

The set of processes and activities arranged in a hierarchy of detail Drawings that illustrate the relationships between activities Inputs and outputs for each activity, including the source or destination of each information flow and the characteristics of the data itself

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

l

Page 5 of 17

A text description of each process or activity that conforms to a template so that the information is presented consistently and completely Key performance indicators

13. Example: Buying a Used Car (D. Schlossberg, 2004)

14. Models {and,vs} Notation [1]

l

8 Explicit Collaborations with Information Exchanges (M. Tong, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 6 of 17

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 7 of 17

15. Models {and,vs} Notation [2]

l

2 Explicit Collaborations with Color Coding (L. de Larios-Heiman, 2004)

16. Models {and,vs} Notation [3]

l

7 Implicit (Color Coding) Collaborations with PIPs (D. Green, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 8 of 17

17. Models {and,vs} Notation [4]

l

7 Explicit Collaborations with PIPs (and Clip Art) (Color Scheme by Actors) (R. Huebsch, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 9 of 17

18. Models {and,vs} Notation [5]

l

No Collaborations with PIPs and Transaction Patterns (F. Gomes, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 10 of 17

19. Models {and,vs} Notation [6]

l

No Swimlanes (B. Maury, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 11 of 17

20. Models {and,vs} Notation [7]

l

"Copernican" Perspective with Seller in Center (A. Billings, 2004)

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 12 of 17

21. The Abstraction Hierarchy in Process Models

l

But there is one fundamental difference between document models and process models One of the hardest things about modeling business process is the range of abstractness / granularity with which you can describe them> We can model processes at an organizational level from the perspective of the nature and pattern of "value exchanges" between an enterprise and its suppliers, customers, and other entities in its "value chain" We can treat a group of interconnected or choreographed transactions that carry out "supply chain management" or "procurement" or "auction" as a construct in a process model; this is what we most often mean by "business process" We can model documents and processes at the same abstraction level when we focus on business transactions The contents or semantic components of documents can also vary on an abstraction hierarchy, but the document

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

container / message / assemblage for the components is a fixed and concrete thing

Page 13 of 17

22. The Abstraction Gap in Process Models

l

An abstract / coarse / strategic BDV of processes is the top-down perspective from senior management The granular BTV is bottom-up, less likely to be technology-independent, and naturally emerges from operational personnel as they describe the processes and documents they work with We need to close this gap to get a complete, balanced, and actionable view of the processes [one of the lessons from "staple yourself to an order']

23. The UMM Metamodels for Business Processes

l

UN/CEFACT has developed a "Unified Modeling Methodology" (UMM) that contains a metamodel that defines three levels or perspectives on business modeling, with the BRM at the top

Business Domain View (BDV) meta-model: organizational or big-picture perspective Business Requirements View (BRV) metamodel: process use cases Business Transaction View (BTV) metamodel: business transaction details down to the document requirements

24. The ebXML Process Metamodel

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

l

Page 14 of 17

Clark and Hayes present a conceptual model of a "business process" that captures the broad scope of the abstraction hierarchy

25. Modeling Worksheets

l

Brian Hayes led an effort to develop Worksheet Views that are compatible with the UMM's normative set of views but which capture the information in a less prescriptive and more user-friendly manner Philosophical approach:

Worksheets are just views into the underlying meta-model You can tailor the modeling approach by customizing worksheets to fit your or your client's methodology and language This is a less prescriptive approach that lets the analyst capture "fragments" of the metamodel whenever they arise or are discovered

26. BDV Worksheet for Event Calendar Network

Big picture view of business-to-business processes Establishes the business context of the modeled processes

27. BPA Worksheet for Maintain Events

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 15 of 17

Captures the process requirements in terms of:

Business objects used by process Information input and output requirements Pre- and post-conditions Starting and stopping critera Exception cases

28. Business Process Concept of "Transaction"

l

The most important concept in business process modeling and the most overloaded one is transaction Two or more business transactions can be sequenced to carry out a business collaboration The choreography describes the sequence and transition between business transactions that make up a business collaboration. Choreography is often depicted using UML Activity Diagrams and their associated concepts like start state, completion state, activities, synchronization, transitions, and guards

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

l

Page 16 of 17

From a "top-down" modeling perspective, the business transactions are re-usable (or "pluggable") components into collaborations you could have a collaboration that mixes RosettaNet business transactions with xCBL transactions A business transaction is NOT the same as a database transaction

29. BTV Worksheet for Submit Event

30. Sequence Diagram for Submit Event Transactions

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005

15. Business Process Analysis [1]

Page 17 of 17

31. Business Collaborations

l

A business collaboration is a series of activities carried out by two or more partners for the purpose of achieving a business goal; these activities are business transactions The set of transactions have meaningful and necessary semantic overlap with each other From a "top-down" modeling perspective, the business transactions are re-usable (or "pluggable") components into collaborations you could have a collaboration that mixes RosettaNet business transactions with xCBL transactions Collaborations should be expressed in implementation neutral terms

32. Assignment 5
l

Modeling the "register for classes" processes of the university You'll produce some worksheets and diagrams Due on Sunday 20 March (extended because of all the midterms many of you have)

33. For Wednesday 16 March

l

DE 10: Designing Business Processes with Patterns Automating Through RosettaNet

file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le... 3/13/2005