Business Processes A business process describes a set of activities that are necessary to complete a response to a stimulus applied to an organization.

What is a business process? Supplier (order) Customer (request) Supplier (shipment) Inventory System (update inventory) Business Committee (response) Management (directive) News (Info. about competitor) Marketing (plan)

Examples of Business Processes Routine business processes: fulfill customer order receive shipment for inventory review loan applications create a two week payroll More complex business processes: Developing a new product Deciding on a location for new store Designing a new marketing campaign

Triggering Business Processes The stimulus for an organization to respond to could be external: customer request supplier shipment new knowledge about competitor or from an internal source: management wants new product developed organization opening a new branch office

Business Process - A Response The response is the action(s) that the organizations takes as a result of the stimulus. For example: ship product to customer update inventory based on shipment All of the activities required to recognize the stimulus and develop and implement the final response are the business process.

Business Process Modeling What is a process model? A formal way of representing how a business system operates. Illustrates the activities that are performed and how data moves through the process. A process model can be used to document current system or to illustrate new system Use Cases and Data Flow Diagrams (DFD) are among many techniques to support Business Process Modeling

Why Draw Process Models? Business Administration 362 2001-3 Session 3 Notes Why Draw Process Models? To clearly communicate the processes (flow of data) through a system. To help us structure our view of the business process. To articulate our understanding of how a system under study actually works To formalize the description of processes (documentation) Diagrams are sometimes easier to understand than text. Drew Parker September 2001

Why Draw Process Models? Business Administration 362 2001-3 Session 3 Notes Why Draw Process Models? Why use a diagram and not just text? “Since we previously had no way of showing a tangible model, we have had to build the next best thing, which is to use English narrative to describe the proposed system. Can you imagine spending five years’ salary on a custom built house on the basis of an exhaustive narrative description of how the house will be built? ... If you use English to describe a complex system... the result takes up so much space that it’s hard for the reader to grasp how the parts fit together” (Gane and Sarson, Structured System Analysis, 1974) Drew Parker September 2001

Business Administration 362 2001-3 Session 3 Notes Use Cases A Foray into the world of objects Look at business processes in an object oriented view more ‘natural’ in its makeup Not all that new Jacobson 1986 formally introduced them Late 1990’s they took hold as a ‘norm’ Part of UML Drew Parker September 2001

Use Cases This newer methodology allows analysts to consider what the user and the system need to do to interact and handle a business process They have recently moved from object-oriented analysis into more mainstream development Now, pretty much a standard

Use Case Modeling Process First, try to understand the general processes to be studied. Document Analysis Questionnaires about problems Observation Ask questions, test assumptions.

Use Case Modeling Process Try to understand the objectives of the new project Interviews JAD

Use Case Modeling Starts to document the process Triggers: Inputs to each use case with source What causes the system to ‘wake up’ and do something? Outputs with sync (destination) Major Steps with links to all inputs and outputs What do the users do? What does the system need to respond with?

Automation Use Cases are critical here The ‘2B’ system is, in fact, the ‘as is’ system More interested in physical processes than logical

Improvement Two objectives Need to understand ‘as is,’ since it will remain the core system Use Cases are the foundation for discussions about shortcomings of the current system More time is spent gaining an understanding of the logic of the current system

Reengineering The ‘as is’ system is studied in depth later in the project deemed ‘essential systems analysis’ start with the logic of the process design process, procedure, and physical system study current system develop a transition plan significant user involvement in systems specifications interviewing JAD

Use Cases A use case illustrates the activities that are performed by users of a system Use cases are logical models – they describe the activities of a system without specifying how the activities are implemented Triggers: Initiated by an external “actor” (which may be a person, a role, or even another system) Can be initiated by the passage of time, which is a specific type of trigger, a “temporal event”

Benefits of using use cases Business Administration 362 2001-3 Session 3 Notes Benefits of using use cases Facilitates user involvement. Understandable. A view of the desired system’s functionality from a business process viewpoint. An effective tool for validating requirements. An effective communication tool. In general: provide a representation of the behavior of a business organization for the purpose of understanding the business itself Drew Parker September 2001

Processes Processes are named with verb/noun combinations High level processes (also known as “events”) are logical units of action that must be completed as a whole They start with general verbs such as “process”, “respond to”, “generate” or “maintain” Lower level processes are discrete, detailed activities, with specific action verbs such as “calculate” or “validate”

What processes do Perform computations Make decisions Sort, filter, or otherwise summarize data Organize data into useful information (generate reports) Trigger other processes Use stored data (create, read, update, or delete a record)

Triggering a business process Stimulus for a process could be from outside the organization Customer makes a request Supplier sends a shipment Marketing department gets new info re competitors or from an internal source Manager wants to analyze sales force productivity Inventory for a specific item falls below its reorder point

Output from a business process The purpose of a business process is to generate a response to a trigger A product is shipped to a customer Inventory is updated to reflect new inventory All of the activities required to recognize the stimulus and develop and implement the final response are the business process

Use Cases One way to identify use cases is to start with actors - think about all the actions they take Another way is to look directly at outcomes – what are the different services we need to provide. For each use case, want to be clear on: the actor that initiates the event the event or business process (this will be the title) the first input or trigger all inputs, outputs and responses

Elements of a Use Case Note: like many of these tools and techniques, there are ‘norms’ rather than ‘standards’. Use Cases can be relatively simple and straightforward, or they might need to model a highly complex process, where they would be correspondingly detailed.

Elements of a Use Case Basic Information Name – as simple and descriptive as possible Number – just to keep track Priority – how essential is this to the overall system Actor – the key person, system, or device that interacts with the process Trigger – what starts the use case to happen? can be external (customer visits our web site) or temporal (its payday)

Elements of a Use Case Preconditions the state the system must be in before the use case can commence for example, a ‘sign in’ use case would require that a customer has an account. If not, it would direct them to a ‘create account’ use case

Elements of a Use Case Major steps performed ‘Normal Course’ probably the one you want no exceptions exist ‘Alternative Courses’ what happens if some alternative event takes place ‘sign up’ would be an alternative course in our eBy log in example

Elements of a Use Case Postconditions Exceptions an inventory of the results of progressing successfully through the use case Exceptions what errors could happen in the steps Summary Inputs and Outputs major elements and their source or destination

Steps for generating use cases Identify the use cases – think about the triggers coming in to initiate action, and the major inputs and outputs Identify the major steps for each Identify elements within each step – its triggers, inputs and outputs Confirm the use case with users

Some comments re Use Cases If you end up with a lot of use cases, think about combining some of them into higher level processes Write from the perspective of an independent observer The information flows should deal with “information” rather than physical objects There should be a match between the major inputs/outputs and the information flows

Not all elements of the use cases are always required. They should be as simple, or as complex, as you need them to be.