Business Process Modeling
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Business Process Modeling as PDF for free.
More details
- Words: 6,746
- Pages: 27
Business Process Modeling (BPM) White Paper Version: 2.1
Business Process Modeling (BPM)
White Paper
Disclaimer and Trademarks © Select Business Solutions, Inc. 0000. All Rights Reserved. Information in this document is subject to change without notice and does not represent a commitment on the part of Select Business Solutions, Inc. to provide or continue providing said functionality. This document may not, in whole or part, be copied, photocopied, reproduced, translated or reduced to any electronic medium or machine-readable form without prior written consent of Select Business Solutions, Inc. Company names, data and other information appearing in examples are fictitious in nature unless otherwise designated. The software described in this document is furnished under license or non-disclosure agreement and may be used or copied only in accordance with the terms and conditions of that agreement. It is against the law to copy the software on any medium except as specifically allowed in the license or non-disclosure agreement. Select Enterprise is a Registered Trademark of Select Business Solutions, Inc., and Select Component Factory, Select Component Architect, Select Component Manager, Select Component Portal, Select JSync, Select CSync, Select C#Sync, Select ForteSync, Select VBSync, Select DBSync, Select XMLSync, Select ORSync, Select Document Generator, Select Object Animator, Reviewer for Select Component Architect, Reviewer for Select Enterprise, Reviewer for Rose, Select Process Director, Select Process Director Plus, Select UDDIServer, Select Application Composer, Select Scope Manager, Select Perspective, Select SE, Select SSADM, Select Yourdon are all Trademarks of Select Business Solutions, Inc. Because of the nature of the material, numerous hardware and software products are mentioned by their trade names in the publication. In most, if not all, cases these designations are claimed as trademarks by their respective companies. It is not the publisher's intent to use any of these names generically, and the reader is cautioned to investigate all claimed trademark rights before using any of these names other than to refer to the product described. For more information about Select Business Solutions Inc., or to download an electronic copy of this document please visit the Select Website: http://www.selectbs.com/
© Select Business Solutions, Inc. 2003
Page: 1
Business Process Modeling (BPM)
White Paper
Table of Contents Introduction .................................................................................................... 3 Focus of Interest ............................................................................................ 4 BPM Principles............................................................................................... 5 Types of Business Process............................................................................ 7 Business Process Modeling Notation............................................................. 9 BPM Techniques.......................................................................................... 11 “As Is” Process Hierarchy Diagramming ............................................................................ 11 “As Is” Process Thread Diagramming ................................................................................ 11 “To Be” Process Hierarchy Diagramming .......................................................................... 14 “To Be” Process Thread Diagramming............................................................................... 14
Process Thread Storyboarding .................................................................... 17 Identifying Business Tasks........................................................................... 19 Business Task Modeling .............................................................................. 20 Business Processes and Object-Orientation................................................ 22 Other Key BPM Activities ............................................................................. 25 Summary ..................................................................................................... 26
© Select Business Solutions, Inc. 2003
Page: 2
Business Process Modeling (BPM)
White Paper
Introduction Business process reengineering (BPR) and business process improvement (BPI) have become the “hot topics” of the 1990s as management faces up to the need to continually reinvent businesses in the context of a changing technological and sociological world. Such initiatives are customer and technology inspired, flatten organizational structures through the use of empowered teams, remove redundancy, and look for new ways to leverage business advantage.
However, our purpose in this document is not to discuss the merits of various approaches to BPR and BPI. Our focus is as follows:
• • •
To understand how BPR and BPI projects can provide the needed scope definition for software development projects. To describe a basic set of business process modeling (BPM) concepts and diagramming techniques that are usable in rapid analysis of software requirements with as little translation or rework as possible. To describe BPM techniques which give a basis for assembling, not coding, business solutions.
A variety of work flow and process diagrams have been used to model business processes and it is not our purpose here to over-elaborate on the notations used. We will use a subset of core BPM concepts, adapted from CSC’s Lynx methodology (Lynx 1995) which are briefly explained before considering how they fit into the Select Perspective. A full set of relevant definitions is included within the glossary. For reasons of scope we do not address some of the key issues of BPR and BPI such as organizational issues, location and physical distribution, as well as cultural and political impact. We restrict the focus to relevant modeling concepts.
© Select Business Solutions, Inc. 2003
Page: 3
Business Process Modeling (BPM)
White Paper
Focus of Interest The meaning of the term Business Process Reengineering (BPR) has become rather vague since it is used differently by different authors and commentators. We understand it to mean:
The radical reorganization of an enterprise along the flow of work that generates the value sought by the customer.
The emphasis in BPR is that change should be radical in order that the business makes efficiency gains of orders of magnitude. Under some circumstances the radical nature of the changes envisaged with a BPR exercise are unacceptable resulting in a drive for improvement of the current processes, however defined, rather than reengineering. We use the term Business Process Improvement (BPI) to indicate where improvements are sought within the current business constraints.
Both BPR and BPI encompass a whole range of techniques, which include both modeling techniques and techniques for organizational change. The former can involve workflow analysis, simulation, value chain analysis, critical path analysis and performance measurement. The latter are characterized by approaches to managing resistance to change, team building, performance measurement and incentive compensation.
We restrict the discussion in this document to process concepts and modeling techniques irrespective of whether a BPR or BPI approach is taken. We describe current “As Is” modeling and future “To Be” modeling techniques which will provide a basis for techniques such as workflow analysis, simulation, value chain analysis, critical path analysis and performance measurement.
We will employ business process models that will be readily usable in analyzing software requirements with as little translation or rework as possible. To speed development, close integration is critical between the BPM techniques of BPR/BPI and the modeling techniques used in the Select Perspective. In this document we will focus on showing how to “make the connection.”
© Select Business Solutions, Inc. 2003
Page: 4
Business Process Modeling (BPM)
White Paper
BPM Principles Hammer and Champy (Hammer and Champy, 1993) offer the following definition of a business process: “A collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.” A business process is crucially distinct from a function. Some processes might be contained within a departmental function; for example Computer Programming. Often however we find that a business process crosses the “white space” between boxes on an organizational hierarchy; for example Order Processing spans Sales, Credit Control, Inventory Management and Invoicing.
In the case of BPI, a huge amount of learning and process improvement can result simply from modeling how the components of business processes inter-connect. For example, we can seek to eliminate duplicate activities, introduce parallel activities and eliminate unnecessary movement of work. In the more extreme case of BPR this can result in a totally reorganized set of functions, based upon business processes; for example the four different elements of Order Processing (Sales, Credit Control, Inventory Management and Invoicing) are rationalized into a single process-based function Provide Customer Service.
A key point therefore about business processes is that they often cut across organizational boundaries in their mission to add value for the customer. They operate “horizontally” through a company in contrast to the vertical division of labor upon which traditional function decomposition approaches to business analysis are based. Each activity along the series should leave the system in a consistent state that adds value to the business process. We want to leverage this feature and guard against functional partitioning. We may well need to challenge and pinpoint unnecessary interfaces and time delays within the business process. We need to be able to apply creative thinking as to how best the organization interfaces with its customers.
A business process often involves multiple users and activities that take place over different timeslices. Not only do we need to examine the activities in which inputs are converted into outputs, we need to be able to identify the correct activities in the first place. A common approach is to attempt some form of function decomposition, unpeeling the layers of the process onion, until one reaches the magical notion of a component process. Unfortunately, there is an absence of criteria for establishing a bottom level process component. Too often we are exulted to “find a level you are comfortable with”. We feel this is unhelpful. Instead we recognize that the anatomy of a business process is essentially event-driven.
Very few BPM methodologies seem to recognize this fact. We need to work “outside-in” rather than “top-down.” One of the few that does is the Lynx methodology (Lynx 1995) from CSC. Many of the concepts that follow are therefore drawn and adapted from this methodology.
A business process consists of groups of activities performed in response to a set of related business events. Process threads are value chains of component business activities. They are used to model the flow of activities within a process group, initiated by a single business event, in terms of sequence dependency, iteration, concurrence and process breaks. A process thread normally produces some result that represents business value. A result from one process thread may be a business event relative to another process thread.
© Select Business Solutions, Inc. 2003
Page: 5
Business Process Modeling (BPM)
White Paper
A business event is a stimulus which triggers an elementary business process (EBP): a task performed, by one person in one place at one time, and which adds measurable business value and leaves the data in a consistent state; for example Approve Credit or Price Order. Business events may be input or output-driven. Input-driven business events are signaled by the arrival of an input information flow; they can be external or internal; for example Customer submits order (external) or Customer service clerk requests credit approval. Output-driven business events may be temporal or conditional. Temporal events are signaled by the arrival of a predefined point in time. Conditional events report the sensing of a particular circumstance that triggers an elementary process; for example Credit limit exceeded.
In summary, we think of a business process as a family of activities that together collaborate in different event driven groups to fulfill the business process. We “time-slice” the groups of activities by events that denote essential constraints imposed by the business, not by technology. This allows us to identify component business activities that can act on different process threads.
© Select Business Solutions, Inc. 2003
Page: 6
Business Process Modeling (BPM)
White Paper
Types of Business Process Some processes produce results that directly affect the external customer. Other processes although transparent to the customer are nevertheless necessary for effective management of the business. Some examples of the different types of process are shown in table 1. (Rummler & Brache 1990)
Generic Customer Processes • • • • • • •
Marketing and Sales Product/service development and introduction Manufacturing Distribution Billing Order processing Customer service
Industry-specific customer processes • • • • • • •
Loan processing (banking) Claim adjudication (insurance) Grant allocation (government) Merchandise return (retail) Food preparation (restaurants) Baggage handling (airline) Reservation handling (hotels/airlines)
Generic administrative processes • • • • • •
Formal strategic and tactical planning Budgeting Training Facilities management Purchasing Information Technology (IT) management
Table 1: Examples of Types of Business Process
BPM tends to work best with processes that are essentially “value chains” (Porter 1985) of interconnected activities. Often such processes are customer focused (for example “Claim Adjudication”), though this is not always the case (for example, “Purchasing”). It will be important not to forget other administrative processes that though they do not add measurable business value to the customer are nevertheless part of the lifeblood of the enterprise.
Such “indirect value” processes include key management information activities where a triggering event is not pre-definable; for example Analyze Pricing Trends. Often such management activities are concerned with overall business performance; for example Monitor Sales Activity. Also included here are infrastructure activities concerned with efficient service provision; for example, Maintain Stock.
© Select Business Solutions, Inc. 2003
Page: 7
Business Process Modeling (BPM)
White Paper
We shall return to indirect processes later in this document. For now, we concentrate on “direct value” business processes.
© Select Business Solutions, Inc. 2003
Page: 8
Business Process Modeling (BPM)
White Paper
Business Process Modeling Notation Notation Set: We will use a notation set for our business process models based upon [Lynx 1995], summarized below.
NAME
SYMBOL
DESCRIPTION
Business Event
Triggers a process thread or activity input or output driven.
Result
An outcome of value produced by the process
Optional Dependency
Leads to a process to indicate its optionality
Mandatory Dependency
Leads to a mandatory process
Activity
Generic Process
Exclusivety
To indicate a condition
Concurrence
P1
To represent parallel processes
P2
For each X
Iteration
To indicate a repeating process or processes
Process Break
A delay prior to another process starting (ends with an event)
Figure 1: Business Process Modeling Notation Set Business process modeling (BPM) creates two types of diagrams: process hierarchy diagrams and process thread diagrams. The diagrams are produced both for the current “As Is” and the proposed “To Be” models.
The Process Hierarchy Diagram is used to capture and graphically display the relationship between the levels of process granularity. At the very top sits the enterprise (or part of the enterprise) under study. This is divided into a number of key business processes consisting of process groups. Process groups may be nested as necessary, depending on size and complexity of the business under study. A process group consists of a number of EBPs and other process groups. EBPs can be re-used both within and across different process threads. An elementary process can optionally be broken down into business steps.
© Select Business Solutions, Inc. 2003
Page: 9
Business Process Modeling (BPM)
White Paper
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS STEP
BUSINESS PROCESS
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
EBP
EBP
BUSINESS STEP
BUSINESS STEP
PROCESS GROUP
EBP
EBP
BUSINESS STEP
BUSINESS STEP
Figure 2: Process Hierarchy Concepts Process Thread Diagrams are used to capture and graphically display dependencies among chains of EBPs driven by initiating business events and producing results of business value within process groups. A process thread can include both EBPs and other process groups. The process groups can be decomposed into other process groups and/or elementary business processes. A result produced by one process thread can be a triggering event relative to another process thread. An activity could be common to more than one process thread; it could also be used more than once in the same thread.
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
PROCESS THREAD
TRIGGERING EVENT
BUSINESS STEP
EBP
BUSINESS STEP
EBP
BUSINESS STEP
BUSINESS STEP
Figure 3: A Process Thread in Context
© Select Business Solutions, Inc. 2003
EBP
EBP
Page: 10
BUSINESS STEP
RESULT
Business Process Modeling (BPM)
White Paper
BPM Techniques “As Is” Process Hierarchy Diagramming A process hierarchy diagram is used to help determine the scope of the BPM effort by providing a visual focus for BPM with respect to current set of business processes. The goal here is to understand the business process, which will often be more difficult than originally perceived, as we start to challenge assumptions about what is actually going on! This will usually involve scouting ahead and doing some process thread diagramming (as described below) and then returning to revisit the process hierarchy diagram as our understanding sharpens.
The process hierarchy diagram in figure 4 illustrates business processes within a motor dealership enterprise. The process “Service Vehicle” fits Hammer’s definition; it is "a collection of activities that takes one or more kinds of input” (a customer car service request) “and creates an output that is of value to the customer” (a serviced car).
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODY REPAIRS
VALET VEHICLE
SUPPLY PARTS
RESTORE VINTAGE
SERVICE VEHICLE
SERVICE AND REPAIR VEHICLE
ASSESS DAMAGES
Figure 4: Motor Dealership “As Is” Process Hierarchy Diagram This business process splits into five process groups. The process group Service and Repair Vehicle will provide the context for our BPM.
“As Is” Process Thread Diagramming The selected current process group or process groups are now analyzed in more detail to the level of EBPs. Process thread diagrams are constructed for process groups. This involves identifying external business events and primary results. Each process group is analyzed as a chain of activity for each pair of triggering events and results.
We now consider the process thread for the process group Service and Repair Vehicle, within the context of the motor dealership company. The first step is to segment the process group into essential time-slices by considering typical pattern of events that will occur, thus exposing constituent EBPs. Each time slice should end in some value that is reflected in a stable system state. A good way to do this is to think of chains of events. This allows us to separate and identify dependencies between EBPs within the process group.
First we note that the process thread is initiated by the external business event (1) of a customer requesting a car service in dialogue with the customer service clerk. The customer service clerk uses a service from the system, in the shape of a bookings form, to sort out the customer’s requirement and
© Select Business Solutions, Inc. 2003
Page: 11
Business Process Modeling (BPM)
White Paper
work out required parts. The next event in the chain is temporal: parts requests are produced at regular times (2). If parts need to be ordered, the parts controller talks to a supplier, raising the necessary purchase order (3); an internal business event. At the start of day (4) a schedule of jobs is produced for the lead mechanic. On finishing the job the lead mechanic submits job completion details (5). The business process finishes on receipt of the business event (6) of the customer collecting the serviced vehicle.
EVENT TYPE
EVENT NAME
ELEMENTARY BUSINESS PROCESS
External
Customer asks customer service clerk to book a job
Book job for customer
Temporal
Time to establish parts for job
Establish parts for job
Internal
Parts controller submits parts request
Request parts for job
Temporal
Time to schedule jobs for day
Schedule jobs for day
Internal
Lead mechanic completes job
Complete job
Customer arrives to collect serviced car
Close job with customer
Business
Business
Business External Business
Figure 5: Service and Repair Vehicle Events and EBPs We now construct a process thread diagram as shown in figure 6. Note that internal business events Parts Controller Submits Parts Request and Lead Mechanic Completes Job are not shown on the diagram to limit complexity; though they could be shown if required.
The dependencies between EBPs represent postconditions of the previous EBP and preconditions of the subsequent EBP. Preconditions and postconditions must always evaluate to “true” or “false.” Thus the event Parts Controller Submits Parts Request will only trigger Request Parts for Job provided that the precondition Parts Established for Job is true. Preconditions and postconditions are important because they will help to govern the behavior of required services, when we model our system use cases.
© Select Business Solutions, Inc. 2003
Page: 12
Business Process Modeling (BPM)
White Paper
CUSTOMER REQUESTS JOB
BOOK JOB FOR CUSTOMER
JOB BOOKED
WAITING FOR PARTS
ESTABLISH PARTS FOR JOB
TIME TO ESTABLISH PARTS
PARTS ESTABLISHED FOR JOB
REQUEST PARTS FOR JOB PARTS REQUESTED
AWAITING JOB SCHEDULE
SCHEDULE JOBS FOR DAY
TIME TO SCHEDULE JOBS
PARTS ORDER CREATED
COMPLETE JOB JOB COMPLETED
CUSTOMER ARRIVES FOR CAR
CLOSE JOB WITH CUSTOMER
JOB CLOSED
Figure 6: Service and Repair Vehicle “As Is” Process Thread Diagram We can now elaborate the process hierarchy diagram as shown in figure 7. Notice that we have not done this by function decomposition. We have applied event analysis to expose the next level.
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODY REPAIRS
VALET VEHICLE
BOOK JOB FOR CUSTOMER
SUPPLY PARTS
SERVICE VEHICLE
RESTORE VINTAGE
SERVICE AND REPAIR VEHICLE
ESTABLISH PARTS FOR JOB
REQUEST PARTS FOR JOB
*
© Select Business Solutions, Inc. 2003
Page: 13
ASSESS DAMAGES
SCHEDULE JOBS FOR DAY
COMPLETE JOB
CLOSE JOB WITH CUSTOMER
Business Process Modeling (BPM)
White Paper
Figure 7: Motor Dealership Extended “As Is” Process Hierarchy Diagram “To Be” Process Hierarchy Diagramming Process hierarchy diagramming is again used this time to analyze the business process group(s) under study in order to identify a set of issues and associated impacts on the enterprise and to model proposed “To Be” solutions at a high level. Clearly much will depend on the scope of proposed changes; for example, whether our goal is to improve an existing process group, such as Service and Repair Vehicles or to reengineer across the board, which may involve considering process elements from various existing groups with a subsequent recommendation to reorganize. In our example our goal will be the former.
Whether improving or reengineering, we will need to consider the possible options that will move the organization towards achieving its goals. A process hierarchy diagram reflecting the required solution is produced for a selected option. The level of detail of this model will depend on the extent of the required change to the current business process. However, the model produced will at least be at an outline or concept level in terms of an enhanced process hierarchy diagram.
In the Service and Repair Vehicle process there is a major issue which emerges. We note that there is an increasing demand for a priority service for which customers are willing to pay premium rates. This involves same day service to alleviate pressing problems. The Services Manager would be able to commission parts for and schedule such jobs automatically, according to predefined algorithms. Certain complementary tasks, such as water and tire checks would be included and a chauffeur service would also be available as part of the deal.
Let us suppose that we decide to cater for priority jobs. This results in two further elementary processes: Organize Priority Job and Schedule Job Item as shown in the process hierarchy diagram in figure 8.
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODYREPAIRS
BOOKJOBFOR CUSTOMER
ORGANIZE PARTS
VALET VEHICLE
SCHEDULE JOBITEM
SUPPLY PARTS
SERVICE VEHICLE
RESTORE VINTAGE
SERVICEAND REPAIRVEHICLE
ESTABLISHPARTS FORJOB
REQUEST PARTS FORJOB
ASSESS DAMAGES
SCHEDULEJOBS FORDAY
COMPLETEJOB
CLOSEJOB WITH CUSTOMER
Figure 8: Motor Dealership “To Be” Process Hierarchy Diagram “To Be” Process Thread Diagramming Process thread diagramming is used iteratively with process hierarchy diagramming to assess issues and possible “To Be” solutions at a lower level.
© Select Business Solutions, Inc. 2003
Page: 14
Business Process Modeling (BPM)
White Paper
We restrict the discussion here to diagramming techniques. However it is important to realize that in most cases storyboarding (described below) and simulation of the process thread using relevant volumes will be useful in order to highlight bottlenecks, peaks and troughs and other problems. Process thread performance analysis may also be useful to measure characteristics such as processing time from event to outcome, processing and capital cost, and error rates. Such measures provide a baseline against which to assess proposed solutions.
Process thread diagramming helps us question the necessity of any events associated with internal actors. We ask “Is the event essential?”: for example, although the interfaces with the lead mechanic and customer services clerk are probably necessary, we might question the interfaces with the parts controller: for example, could the related work carried out by the parts controller be effectively automated?
We also recognize that the two EBPs Establish Parts for Job and Request Parts for Job could be combined and triggered automatically on booking a job. This would remove the time delay “Waiting for Parts” of anything up to half a day and also remove the need for manual intervention by the parts controller in requesting parts. However, after much deliberation, it is decided to leave things as they are. This is in order to take advantage of bulk discounts and delivery procedures, by keeping the temporally triggered Establish Parts for Job. Also complete automation of part ordering is not yet possible due to the level of human expertise needed in choosing the best suppliers for specific requirements and conditions.
We therefore limit the improvement to simply enhance the Process thread diagram, as shown in figure 9, to cater for priority jobs. Note that the EBPs Establish Parts for Job and Request Parts for Job are potentially re-usable by Organize Parts.
© Select Business Solutions, Inc. 2003
Page: 15
Business Process Modeling (BPM)
White Paper
CUSTOMER REQUESTS JOB
BOOK JOB FOR CUSTOMER
PRIORITY JOB IDENTIFIED
JOB BOOKED WAITING FOR PARTS
Organize Priority Job TIME TO ESTABLISH PARTS ESTABLISH PARTS FOR JOB
PARTS ESTABLISHED FOR JOB
REQUEST PARTS FOR JOB
ORGANIZE PARTS
SCHEDULE JOB ITEM
PRIORITY JOB SCHEDULED
PARTS REQUESTED AWAITING JOB SCHEDULE
TIME TO SCHEDULE JOBS
SCHEDULE JOBS FOR DAY
JOB SCHEDULED
COMPLETE JOB
JOB COMPLETED
CUSTOMER ARRIVES FOR CAR
CLOSE JOB WITH CUSTOMER
JOB CLOSED
Figure 9: Service and Repair Vehicle “To Be” Process Thread Diagram
© Select Business Solutions, Inc. 2003
Page: 16
Business Process Modeling (BPM)
White Paper
Process Thread Storyboarding Storyboarding provides an excellent mechanism for interactively developing the process threads and EBPs that are affected by the proposals for business improvement. As there are potentially thousands of scenarios within a business process it will be important to be selective and concentrate on key business cycles. Each business cycle is a set of elementary business processes that represent a general pattern of execution for a process thread. A process thread can execute in terms of several business cycles.
It is important to understand that what we are doing here is business process redesign: this is not the same as systems analysis. We need to consider all aspects of a business process including human interaction within the business context as well as automated activities. This is also a major difference to conventional business analysis which suspends judgment of how a process is to be supported by computer based activities until after a “pure” logical model has been built. Some “how” questions will have a significant impact on how the business actually works, and simply cannot be left until later.
The storyboard itself can take various forms, from simple whiteboard sketches too much more sophisticated simulation using different performance parameters. This approach ventilates discussion, and helps to challenge assumptions.
An informal picture of how we might model the business cycle for standard Service and Repairs is shown in figure 10. After discussion we confirm the elementary processes shown down the left-hand side of the diagram.
© Select Business Solutions, Inc. 2003
Page: 17
Business Process Modeling (BPM)
White Paper
Customer Customer Service Clerk
Book Job for Customer Bookings Form
Parts Controller
Establish Parts for Job Parts Request Report
Supplier Parts Order Form
Requset Parts for Job
Schedule Jobs for Day
Lead Mechanic
Job Schedule
Complete Job
Job Completion Form
Customer Service Clerk
Close Job
Job Closure Form
Customer
Figure 10: Service and Repair Vehicle Storyboard (Both customer and customer service clerk are actors denoted by stickmen; we have used a boxed stickman to denote actors which are internal to the business).
© Select Business Solutions, Inc. 2003
Page: 18
Business Process Modeling (BPM)
White Paper
Identifying Business Tasks We address details of how a particular EBP may be carried out in terms of external and internal actors in collaboration with services provided by a computer system. This results in a business task description and is performed in tandem with storyboarding.
A business task is a sequenced set of interactions, between external and internal actors and between those actors and the proposed system that represents a general pattern of execution for an elementary business process. In order to identify business tasks it is useful to break each elementary process into business steps, thinking of the system as a black box that consumes events and information and provides services. We need to keep the focus on the user’s task, concentrating on chunks of business activity and taking care not to become too preoccupied with the mechanics of the user interface that we envisage will become part of the solution. This avoids becoming embroiled in the design of the HCI before we have understood what the system is actually for in the first place. We keep the focus on business requirements and describe each step in a single statement.
Most of the elementary processes that we identified in the Service and Repair Vehicle process group can be easily described in one business task for each EBP. However, a complex EBP can execute in terms of several business tasks on different business cycles. For example, as we have two business cycles for the process thread Service and Repair vehicle, one for standard jobs and the other for priority jobs, we choose to model the EBP Book Job for Customer in terms of two corresponding business tasks, one for standard and one for priority bookings.
Our analysis results in the set of business tasks, within the Service and Repair Vehicle process group, shown in figure 11.
© Select Business Solutions, Inc. 2003
Page: 19
Business Process Modeling (BPM)
White Paper
Business Task Modeling Business tasks will focus attention on two key types of interaction: between actors (specifically between external and internal actors) and between the initiating an actor and services to be provided by the proposed computer system. This is shown in tabular form below for Book Standard Job for Customer in Figure 12. Shaded rows indicate interactions with system services.
System services are particularly significant, as they will ultimately be provided by objects from within the Perspective architecture. Preconditions and postconditions, from EBP interdependencies, will help to govern the behavior of the services.
Different business tasks might use many of the same services but in different combinations and contexts. For example in figure 11 it is clear that both Book Standard Job for Customer and Book Priority Job for Customer require the following services: Establish customer and vehicle details, Agree service type with customer and Agree repair estimates. By cataloging system services we can readily sew existing services into new system use cases which are grown to meet the needs of new business tasks.
BUSINESS TASK
BUSINESS STEP
Book job for customer
Establish customer and vehicle details
(Standard)
Agree service type with customer Agree repair estimates Find a suitable bay slot for the job Book the job
Book job for customer
Establish customer and vehicle details
(Priority)
Agree service type with customer Agree repair estimates Assess Feasibility of Priority Job Agree Pick Up Time Arrange Chauffeur Raise Priority Job
Establish parts for job
Identify which parts needed for job Create part requests for job Produce part requests report
Request parts for job
Reserve parts in stock for jobs Order outstanding parts for jobs
Schedule jobs for day
Produce jobs scheduled bill of materials Organize acquisition of parts for each job
© Select Business Solutions, Inc. 2003
Page: 20
Business Process Modeling (BPM)
White Paper
Complete job
Manage job to completion Record job labor Record service history Produce Highlight report
Close job with customer
Establish job Produce invoice Warn customer of highlights Receive payment for the job
Figure 11: Service and Repair Vehicle Business Tasks
BUSINESS STEP
BUSINESS STEP ELEMENT
EXTERNAL
Requests to book job
Customer
Request customer details Establish customer and vehicle details
Agree service type with customer
Supplies identification details
Customer Match Customer
For new customer add customer and vehicle details
C.S. Clerk
Add Customer
If service required find available service types
C.S. Clerk
Find Services
Ask for confirmation
C.S. Clerk Customer
If repair required find estimates
C.S. Clerk
Ask for confirmation
C.S. Clerk
Book job to include
C.S. Clerk
Find Bay Slots
C.S. Clerk
Book Job
Customer
services/repairs agreed at bay Confirm job with customer
C.S. Clerk
Figure 12: Book Standard Job for Customer Business Task Description
© Select Business Solutions, Inc. 2003
Page: 21
Find Repairs
Customer
Find dates/times service bays available Agree date/time with customer for identified bay
Book the job
C.S. Clerk
C.S. Clerk
Agree repair requirement Find suitable bay slot for the job
SYSTEM SERVICE
For existing customer use fuzzy list to match customer and vehicle
Agree service requirement
Agree repair estimates
INTERNAL
Business Process Modeling (BPM)
White Paper
Business Processes and Object-Orientation BPM usually arises from a compelling business need or opportunity. Often this will require software solutions to be rapidly developed. Information from BPM must therefore be usable in systems analysis and design, and software development, with as little translation or rework as possible.
Various attempts have been made (Jacobson 1994), to model business processes as objects in order to streamline the process and ensure solutions that are rooted in business needs. Although we accept the concept of a business process viewed in terms of an object, experience on real projects has taught us that the process view is more pragmatic. This is partly because senior executives and users are simply more comfortable with the notion of process. And partly it is because any development process is always faced with the problem of how to model the boundary between the business and the software. We have found that from a practical point of view it makes more sense to “make the break” at the most natural point (between processes and objects) rather than introduce the notion of a process object. Our approach views objects as service providers to business processes.
The analysis in terms of business tasks gives us a ready starting point for identifying system use cases. System use cases are essentially the ways in which actors are going to use the proposed system. They will therefore be a subset of the business tasks covering all actor-system service interaction and excluding any interaction between actors, as illustrated in figure 13.
B u sin ess S tep
1
2
SYSTEM U SE C A SE
3
4
5
Figure 13: System Use Case in Relation to Business Task The Select Perspective architecture consists of different layers of object models. This is essentially a model-based solution space for building software. The Select Perspective also views a business process in terms of layered activity which requires services provided from within the Select Perspective architecture as shown in figure 14. The external business layer consists of external actors that are “given” by definition of the business itself; examples include customers, suppliers, government
© Select Business Solutions, Inc. 2003
Page: 22
Business Process Modeling (BPM)
White Paper
departments and competitors. The internal business layer consists of internal actors that are part of the business and that perform roles within that business; examples include users, operators and managers.
External Actor Layer Internal Actor Layer
USER INTERFACE LOCAL
STORAGE
ENTERPRISE STORAGE
Figure 14: The Select Perspective Architecture in Business Context The Perspective architecture can thus be considered as a set of service layers relative to the business, supporting actors in their role of executing business processes. Business tasks encompass interactions between all three layers (external actors, internal actors and system services). System use cases sit at the boundary between the service layer and the actors which use those services. The service layer is modeled using collaborating objects to provide services to the actors. Each system use case is a typical example of how an actor will use the system given a certain sequence of events. System use cases are usefully pictured as providing a bridge between the object model and business processes as shown in figure 15.
© Select Business Solutions, Inc. 2003
Page: 23
Business Process Modeling (BPM)
White Paper
External Actor Layer
Internal Actor Layer
System Use Case Layer Object Layers
Figure 15: The Anatomy of a Business Process We have seen that analysis of business tasks should have already revealed the need for specific high level system services. We can now abstract out these actor-service interactions to form system use cases. Analysis of the system use cases will help to uncover the need for more detailed services. Notice that system use cases interact between actors and objects. They do not interact with one another. Rather, they communicate via the objects. Each system use case represents a self contained unit of interaction between actors and objects. We can also use our knowledge of required system services, together with requirements for indirect processes to identify classes. This provides a user-driven route into finding the objects responsible for providing such services.
By driving the development of objects in this way, we offer the analyst a mechanism to divide and conquer the complexity of the problem. Each use case offers a different view onto the various business objects which cooperate to support the business process.
We have already stressed the importance of indirect processes which though they do not add measurable business value to the customer are nevertheless part of the lifeblood of the enterprise.
The system use cases will be further distinguished according to whether they serve direct business processes, which add customer value (like selling a product) or indirect processes, which though they add no customer value are nevertheless vital to the business (like acquiring stock).
© Select Business Solutions, Inc. 2003
Page: 24
Business Process Modeling (BPM)
White Paper
Other Key BPM Activities Business Class Modeling: By analyzing business tasks in terms of required system services we have a ready route for identifying business classes in terms of responsibilities. This still leaves a whole category of requirements, including informational and management processes which we have not yet considered. Business class modeling involves the identification and structuring of high level business classes that reflect the semantics of the business domain. However, in real life we have often seen business class modeling usefully employed alongside BPM.
Infrastructure Re-Design. This involves mapping out the logical and technical infrastructure which will be used to support new IT systems. The Select Perspective architecture provides a framework for describing logical infrastructure, and establishes the strategy that an organization will adopt for application development. It provides a framework for effective application of modeling techniques.
Technical infrastructure re-design covers the work associated with building a suitable technical architecture: for example, technology principles, constraints, server distribution, and use of standards such as OLE, CORBA and DCE. This also covers the approach to dedicated persistent storage, legacy systems and support services.
Organization Re-Design. The purpose of this activity is to describe the roles and responsibilities of the people implementing the new processes. A model of the organization structure is built, showing how the roles in the process team fit together across functions or departments. However this is outside our scope.
© Select Business Solutions, Inc. 2003
Page: 25
Business Process Modeling (BPM)
White Paper
Summary The approach taken is to break business processes into their constituent business activities by using process thread and process hierarchy modeling. Analysis of threads of event driven activity is immensely useful in exposing EBPs: the lowest practically useful level of constituent business activities. Business cycles help us to understand the different ways in which EBPs are used; i.e. the business tasks.
We analyze business tasks in terms of interactions between actors and between actors and proposed system services. This gives us a ready basis on which to extract out the actor-system interactions as system use cases. System services will be provided by objects from within the Select Perspective architecture. Preconditions and postconditions, from inter EBP dependencies, will help to govern the behavior of required services, when we model our system use cases. System services are configured in different ways depending on the needs of different system use cases. By cataloging system services we can readily re-use existing services in new system use cases which are grown to meet new business needs. Object technology is ideally suited to this goal of looking to assemble, not code, business solutions. A roadmap summarizing the whole approach is shown in figure 16.
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
PROCESS THREAD TRIGGERING EVENT
EBP
BUSINESS STEP
BUSINESS STEP
EBP
BUSINESS STEP
BUSINESS STEP
EBP
EBP
RESULT
BUSINESS STEP
Business Task
System Services Use Case Object 1
Object 2
Object ...
Figure 16: BPM to Objects Roadmap.a
© Select Business Solutions, Inc. 2003
Page: 26
Object n
Business Process Modeling (BPM)
White Paper
Disclaimer and Trademarks © Select Business Solutions, Inc. 0000. All Rights Reserved. Information in this document is subject to change without notice and does not represent a commitment on the part of Select Business Solutions, Inc. to provide or continue providing said functionality. This document may not, in whole or part, be copied, photocopied, reproduced, translated or reduced to any electronic medium or machine-readable form without prior written consent of Select Business Solutions, Inc. Company names, data and other information appearing in examples are fictitious in nature unless otherwise designated. The software described in this document is furnished under license or non-disclosure agreement and may be used or copied only in accordance with the terms and conditions of that agreement. It is against the law to copy the software on any medium except as specifically allowed in the license or non-disclosure agreement. Select Enterprise is a Registered Trademark of Select Business Solutions, Inc., and Select Component Factory, Select Component Architect, Select Component Manager, Select Component Portal, Select JSync, Select CSync, Select C#Sync, Select ForteSync, Select VBSync, Select DBSync, Select XMLSync, Select ORSync, Select Document Generator, Select Object Animator, Reviewer for Select Component Architect, Reviewer for Select Enterprise, Reviewer for Rose, Select Process Director, Select Process Director Plus, Select UDDIServer, Select Application Composer, Select Scope Manager, Select Perspective, Select SE, Select SSADM, Select Yourdon are all Trademarks of Select Business Solutions, Inc. Because of the nature of the material, numerous hardware and software products are mentioned by their trade names in the publication. In most, if not all, cases these designations are claimed as trademarks by their respective companies. It is not the publisher's intent to use any of these names generically, and the reader is cautioned to investigate all claimed trademark rights before using any of these names other than to refer to the product described. For more information about Select Business Solutions Inc., or to download an electronic copy of this document please visit the Select Website: http://www.selectbs.com/
© Select Business Solutions, Inc. 2003
Page: 1
Business Process Modeling (BPM)
White Paper
Table of Contents Introduction .................................................................................................... 3 Focus of Interest ............................................................................................ 4 BPM Principles............................................................................................... 5 Types of Business Process............................................................................ 7 Business Process Modeling Notation............................................................. 9 BPM Techniques.......................................................................................... 11 “As Is” Process Hierarchy Diagramming ............................................................................ 11 “As Is” Process Thread Diagramming ................................................................................ 11 “To Be” Process Hierarchy Diagramming .......................................................................... 14 “To Be” Process Thread Diagramming............................................................................... 14
Process Thread Storyboarding .................................................................... 17 Identifying Business Tasks........................................................................... 19 Business Task Modeling .............................................................................. 20 Business Processes and Object-Orientation................................................ 22 Other Key BPM Activities ............................................................................. 25 Summary ..................................................................................................... 26
© Select Business Solutions, Inc. 2003
Page: 2
Business Process Modeling (BPM)
White Paper
Introduction Business process reengineering (BPR) and business process improvement (BPI) have become the “hot topics” of the 1990s as management faces up to the need to continually reinvent businesses in the context of a changing technological and sociological world. Such initiatives are customer and technology inspired, flatten organizational structures through the use of empowered teams, remove redundancy, and look for new ways to leverage business advantage.
However, our purpose in this document is not to discuss the merits of various approaches to BPR and BPI. Our focus is as follows:
• • •
To understand how BPR and BPI projects can provide the needed scope definition for software development projects. To describe a basic set of business process modeling (BPM) concepts and diagramming techniques that are usable in rapid analysis of software requirements with as little translation or rework as possible. To describe BPM techniques which give a basis for assembling, not coding, business solutions.
A variety of work flow and process diagrams have been used to model business processes and it is not our purpose here to over-elaborate on the notations used. We will use a subset of core BPM concepts, adapted from CSC’s Lynx methodology (Lynx 1995) which are briefly explained before considering how they fit into the Select Perspective. A full set of relevant definitions is included within the glossary. For reasons of scope we do not address some of the key issues of BPR and BPI such as organizational issues, location and physical distribution, as well as cultural and political impact. We restrict the focus to relevant modeling concepts.
© Select Business Solutions, Inc. 2003
Page: 3
Business Process Modeling (BPM)
White Paper
Focus of Interest The meaning of the term Business Process Reengineering (BPR) has become rather vague since it is used differently by different authors and commentators. We understand it to mean:
The radical reorganization of an enterprise along the flow of work that generates the value sought by the customer.
The emphasis in BPR is that change should be radical in order that the business makes efficiency gains of orders of magnitude. Under some circumstances the radical nature of the changes envisaged with a BPR exercise are unacceptable resulting in a drive for improvement of the current processes, however defined, rather than reengineering. We use the term Business Process Improvement (BPI) to indicate where improvements are sought within the current business constraints.
Both BPR and BPI encompass a whole range of techniques, which include both modeling techniques and techniques for organizational change. The former can involve workflow analysis, simulation, value chain analysis, critical path analysis and performance measurement. The latter are characterized by approaches to managing resistance to change, team building, performance measurement and incentive compensation.
We restrict the discussion in this document to process concepts and modeling techniques irrespective of whether a BPR or BPI approach is taken. We describe current “As Is” modeling and future “To Be” modeling techniques which will provide a basis for techniques such as workflow analysis, simulation, value chain analysis, critical path analysis and performance measurement.
We will employ business process models that will be readily usable in analyzing software requirements with as little translation or rework as possible. To speed development, close integration is critical between the BPM techniques of BPR/BPI and the modeling techniques used in the Select Perspective. In this document we will focus on showing how to “make the connection.”
© Select Business Solutions, Inc. 2003
Page: 4
Business Process Modeling (BPM)
White Paper
BPM Principles Hammer and Champy (Hammer and Champy, 1993) offer the following definition of a business process: “A collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.” A business process is crucially distinct from a function. Some processes might be contained within a departmental function; for example Computer Programming. Often however we find that a business process crosses the “white space” between boxes on an organizational hierarchy; for example Order Processing spans Sales, Credit Control, Inventory Management and Invoicing.
In the case of BPI, a huge amount of learning and process improvement can result simply from modeling how the components of business processes inter-connect. For example, we can seek to eliminate duplicate activities, introduce parallel activities and eliminate unnecessary movement of work. In the more extreme case of BPR this can result in a totally reorganized set of functions, based upon business processes; for example the four different elements of Order Processing (Sales, Credit Control, Inventory Management and Invoicing) are rationalized into a single process-based function Provide Customer Service.
A key point therefore about business processes is that they often cut across organizational boundaries in their mission to add value for the customer. They operate “horizontally” through a company in contrast to the vertical division of labor upon which traditional function decomposition approaches to business analysis are based. Each activity along the series should leave the system in a consistent state that adds value to the business process. We want to leverage this feature and guard against functional partitioning. We may well need to challenge and pinpoint unnecessary interfaces and time delays within the business process. We need to be able to apply creative thinking as to how best the organization interfaces with its customers.
A business process often involves multiple users and activities that take place over different timeslices. Not only do we need to examine the activities in which inputs are converted into outputs, we need to be able to identify the correct activities in the first place. A common approach is to attempt some form of function decomposition, unpeeling the layers of the process onion, until one reaches the magical notion of a component process. Unfortunately, there is an absence of criteria for establishing a bottom level process component. Too often we are exulted to “find a level you are comfortable with”. We feel this is unhelpful. Instead we recognize that the anatomy of a business process is essentially event-driven.
Very few BPM methodologies seem to recognize this fact. We need to work “outside-in” rather than “top-down.” One of the few that does is the Lynx methodology (Lynx 1995) from CSC. Many of the concepts that follow are therefore drawn and adapted from this methodology.
A business process consists of groups of activities performed in response to a set of related business events. Process threads are value chains of component business activities. They are used to model the flow of activities within a process group, initiated by a single business event, in terms of sequence dependency, iteration, concurrence and process breaks. A process thread normally produces some result that represents business value. A result from one process thread may be a business event relative to another process thread.
© Select Business Solutions, Inc. 2003
Page: 5
Business Process Modeling (BPM)
White Paper
A business event is a stimulus which triggers an elementary business process (EBP): a task performed, by one person in one place at one time, and which adds measurable business value and leaves the data in a consistent state; for example Approve Credit or Price Order. Business events may be input or output-driven. Input-driven business events are signaled by the arrival of an input information flow; they can be external or internal; for example Customer submits order (external) or Customer service clerk requests credit approval. Output-driven business events may be temporal or conditional. Temporal events are signaled by the arrival of a predefined point in time. Conditional events report the sensing of a particular circumstance that triggers an elementary process; for example Credit limit exceeded.
In summary, we think of a business process as a family of activities that together collaborate in different event driven groups to fulfill the business process. We “time-slice” the groups of activities by events that denote essential constraints imposed by the business, not by technology. This allows us to identify component business activities that can act on different process threads.
© Select Business Solutions, Inc. 2003
Page: 6
Business Process Modeling (BPM)
White Paper
Types of Business Process Some processes produce results that directly affect the external customer. Other processes although transparent to the customer are nevertheless necessary for effective management of the business. Some examples of the different types of process are shown in table 1. (Rummler & Brache 1990)
Generic Customer Processes • • • • • • •
Marketing and Sales Product/service development and introduction Manufacturing Distribution Billing Order processing Customer service
Industry-specific customer processes • • • • • • •
Loan processing (banking) Claim adjudication (insurance) Grant allocation (government) Merchandise return (retail) Food preparation (restaurants) Baggage handling (airline) Reservation handling (hotels/airlines)
Generic administrative processes • • • • • •
Formal strategic and tactical planning Budgeting Training Facilities management Purchasing Information Technology (IT) management
Table 1: Examples of Types of Business Process
BPM tends to work best with processes that are essentially “value chains” (Porter 1985) of interconnected activities. Often such processes are customer focused (for example “Claim Adjudication”), though this is not always the case (for example, “Purchasing”). It will be important not to forget other administrative processes that though they do not add measurable business value to the customer are nevertheless part of the lifeblood of the enterprise.
Such “indirect value” processes include key management information activities where a triggering event is not pre-definable; for example Analyze Pricing Trends. Often such management activities are concerned with overall business performance; for example Monitor Sales Activity. Also included here are infrastructure activities concerned with efficient service provision; for example, Maintain Stock.
© Select Business Solutions, Inc. 2003
Page: 7
Business Process Modeling (BPM)
White Paper
We shall return to indirect processes later in this document. For now, we concentrate on “direct value” business processes.
© Select Business Solutions, Inc. 2003
Page: 8
Business Process Modeling (BPM)
White Paper
Business Process Modeling Notation Notation Set: We will use a notation set for our business process models based upon [Lynx 1995], summarized below.
NAME
SYMBOL
DESCRIPTION
Business Event
Triggers a process thread or activity input or output driven.
Result
An outcome of value produced by the process
Optional Dependency
Leads to a process to indicate its optionality
Mandatory Dependency
Leads to a mandatory process
Activity
Generic Process
Exclusivety
To indicate a condition
Concurrence
P1
To represent parallel processes
P2
For each X
Iteration
To indicate a repeating process or processes
Process Break
A delay prior to another process starting (ends with an event)
Figure 1: Business Process Modeling Notation Set Business process modeling (BPM) creates two types of diagrams: process hierarchy diagrams and process thread diagrams. The diagrams are produced both for the current “As Is” and the proposed “To Be” models.
The Process Hierarchy Diagram is used to capture and graphically display the relationship between the levels of process granularity. At the very top sits the enterprise (or part of the enterprise) under study. This is divided into a number of key business processes consisting of process groups. Process groups may be nested as necessary, depending on size and complexity of the business under study. A process group consists of a number of EBPs and other process groups. EBPs can be re-used both within and across different process threads. An elementary process can optionally be broken down into business steps.
© Select Business Solutions, Inc. 2003
Page: 9
Business Process Modeling (BPM)
White Paper
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS STEP
BUSINESS PROCESS
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
EBP
EBP
BUSINESS STEP
BUSINESS STEP
PROCESS GROUP
EBP
EBP
BUSINESS STEP
BUSINESS STEP
Figure 2: Process Hierarchy Concepts Process Thread Diagrams are used to capture and graphically display dependencies among chains of EBPs driven by initiating business events and producing results of business value within process groups. A process thread can include both EBPs and other process groups. The process groups can be decomposed into other process groups and/or elementary business processes. A result produced by one process thread can be a triggering event relative to another process thread. An activity could be common to more than one process thread; it could also be used more than once in the same thread.
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
PROCESS THREAD
TRIGGERING EVENT
BUSINESS STEP
EBP
BUSINESS STEP
EBP
BUSINESS STEP
BUSINESS STEP
Figure 3: A Process Thread in Context
© Select Business Solutions, Inc. 2003
EBP
EBP
Page: 10
BUSINESS STEP
RESULT
Business Process Modeling (BPM)
White Paper
BPM Techniques “As Is” Process Hierarchy Diagramming A process hierarchy diagram is used to help determine the scope of the BPM effort by providing a visual focus for BPM with respect to current set of business processes. The goal here is to understand the business process, which will often be more difficult than originally perceived, as we start to challenge assumptions about what is actually going on! This will usually involve scouting ahead and doing some process thread diagramming (as described below) and then returning to revisit the process hierarchy diagram as our understanding sharpens.
The process hierarchy diagram in figure 4 illustrates business processes within a motor dealership enterprise. The process “Service Vehicle” fits Hammer’s definition; it is "a collection of activities that takes one or more kinds of input” (a customer car service request) “and creates an output that is of value to the customer” (a serviced car).
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODY REPAIRS
VALET VEHICLE
SUPPLY PARTS
RESTORE VINTAGE
SERVICE VEHICLE
SERVICE AND REPAIR VEHICLE
ASSESS DAMAGES
Figure 4: Motor Dealership “As Is” Process Hierarchy Diagram This business process splits into five process groups. The process group Service and Repair Vehicle will provide the context for our BPM.
“As Is” Process Thread Diagramming The selected current process group or process groups are now analyzed in more detail to the level of EBPs. Process thread diagrams are constructed for process groups. This involves identifying external business events and primary results. Each process group is analyzed as a chain of activity for each pair of triggering events and results.
We now consider the process thread for the process group Service and Repair Vehicle, within the context of the motor dealership company. The first step is to segment the process group into essential time-slices by considering typical pattern of events that will occur, thus exposing constituent EBPs. Each time slice should end in some value that is reflected in a stable system state. A good way to do this is to think of chains of events. This allows us to separate and identify dependencies between EBPs within the process group.
First we note that the process thread is initiated by the external business event (1) of a customer requesting a car service in dialogue with the customer service clerk. The customer service clerk uses a service from the system, in the shape of a bookings form, to sort out the customer’s requirement and
© Select Business Solutions, Inc. 2003
Page: 11
Business Process Modeling (BPM)
White Paper
work out required parts. The next event in the chain is temporal: parts requests are produced at regular times (2). If parts need to be ordered, the parts controller talks to a supplier, raising the necessary purchase order (3); an internal business event. At the start of day (4) a schedule of jobs is produced for the lead mechanic. On finishing the job the lead mechanic submits job completion details (5). The business process finishes on receipt of the business event (6) of the customer collecting the serviced vehicle.
EVENT TYPE
EVENT NAME
ELEMENTARY BUSINESS PROCESS
External
Customer asks customer service clerk to book a job
Book job for customer
Temporal
Time to establish parts for job
Establish parts for job
Internal
Parts controller submits parts request
Request parts for job
Temporal
Time to schedule jobs for day
Schedule jobs for day
Internal
Lead mechanic completes job
Complete job
Customer arrives to collect serviced car
Close job with customer
Business
Business
Business External Business
Figure 5: Service and Repair Vehicle Events and EBPs We now construct a process thread diagram as shown in figure 6. Note that internal business events Parts Controller Submits Parts Request and Lead Mechanic Completes Job are not shown on the diagram to limit complexity; though they could be shown if required.
The dependencies between EBPs represent postconditions of the previous EBP and preconditions of the subsequent EBP. Preconditions and postconditions must always evaluate to “true” or “false.” Thus the event Parts Controller Submits Parts Request will only trigger Request Parts for Job provided that the precondition Parts Established for Job is true. Preconditions and postconditions are important because they will help to govern the behavior of required services, when we model our system use cases.
© Select Business Solutions, Inc. 2003
Page: 12
Business Process Modeling (BPM)
White Paper
CUSTOMER REQUESTS JOB
BOOK JOB FOR CUSTOMER
JOB BOOKED
WAITING FOR PARTS
ESTABLISH PARTS FOR JOB
TIME TO ESTABLISH PARTS
PARTS ESTABLISHED FOR JOB
REQUEST PARTS FOR JOB PARTS REQUESTED
AWAITING JOB SCHEDULE
SCHEDULE JOBS FOR DAY
TIME TO SCHEDULE JOBS
PARTS ORDER CREATED
COMPLETE JOB JOB COMPLETED
CUSTOMER ARRIVES FOR CAR
CLOSE JOB WITH CUSTOMER
JOB CLOSED
Figure 6: Service and Repair Vehicle “As Is” Process Thread Diagram We can now elaborate the process hierarchy diagram as shown in figure 7. Notice that we have not done this by function decomposition. We have applied event analysis to expose the next level.
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODY REPAIRS
VALET VEHICLE
BOOK JOB FOR CUSTOMER
SUPPLY PARTS
SERVICE VEHICLE
RESTORE VINTAGE
SERVICE AND REPAIR VEHICLE
ESTABLISH PARTS FOR JOB
REQUEST PARTS FOR JOB
*
© Select Business Solutions, Inc. 2003
Page: 13
ASSESS DAMAGES
SCHEDULE JOBS FOR DAY
COMPLETE JOB
CLOSE JOB WITH CUSTOMER
Business Process Modeling (BPM)
White Paper
Figure 7: Motor Dealership Extended “As Is” Process Hierarchy Diagram “To Be” Process Hierarchy Diagramming Process hierarchy diagramming is again used this time to analyze the business process group(s) under study in order to identify a set of issues and associated impacts on the enterprise and to model proposed “To Be” solutions at a high level. Clearly much will depend on the scope of proposed changes; for example, whether our goal is to improve an existing process group, such as Service and Repair Vehicles or to reengineer across the board, which may involve considering process elements from various existing groups with a subsequent recommendation to reorganize. In our example our goal will be the former.
Whether improving or reengineering, we will need to consider the possible options that will move the organization towards achieving its goals. A process hierarchy diagram reflecting the required solution is produced for a selected option. The level of detail of this model will depend on the extent of the required change to the current business process. However, the model produced will at least be at an outline or concept level in terms of an enhanced process hierarchy diagram.
In the Service and Repair Vehicle process there is a major issue which emerges. We note that there is an increasing demand for a priority service for which customers are willing to pay premium rates. This involves same day service to alleviate pressing problems. The Services Manager would be able to commission parts for and schedule such jobs automatically, according to predefined algorithms. Certain complementary tasks, such as water and tire checks would be included and a chauffeur service would also be available as part of the deal.
Let us suppose that we decide to cater for priority jobs. This results in two further elementary processes: Organize Priority Job and Schedule Job Item as shown in the process hierarchy diagram in figure 8.
MOTOR DEALERSHIP
SELL VEHICLE
PERFORM BODYREPAIRS
BOOKJOBFOR CUSTOMER
ORGANIZE PARTS
VALET VEHICLE
SCHEDULE JOBITEM
SUPPLY PARTS
SERVICE VEHICLE
RESTORE VINTAGE
SERVICEAND REPAIRVEHICLE
ESTABLISHPARTS FORJOB
REQUEST PARTS FORJOB
ASSESS DAMAGES
SCHEDULEJOBS FORDAY
COMPLETEJOB
CLOSEJOB WITH CUSTOMER
Figure 8: Motor Dealership “To Be” Process Hierarchy Diagram “To Be” Process Thread Diagramming Process thread diagramming is used iteratively with process hierarchy diagramming to assess issues and possible “To Be” solutions at a lower level.
© Select Business Solutions, Inc. 2003
Page: 14
Business Process Modeling (BPM)
White Paper
We restrict the discussion here to diagramming techniques. However it is important to realize that in most cases storyboarding (described below) and simulation of the process thread using relevant volumes will be useful in order to highlight bottlenecks, peaks and troughs and other problems. Process thread performance analysis may also be useful to measure characteristics such as processing time from event to outcome, processing and capital cost, and error rates. Such measures provide a baseline against which to assess proposed solutions.
Process thread diagramming helps us question the necessity of any events associated with internal actors. We ask “Is the event essential?”: for example, although the interfaces with the lead mechanic and customer services clerk are probably necessary, we might question the interfaces with the parts controller: for example, could the related work carried out by the parts controller be effectively automated?
We also recognize that the two EBPs Establish Parts for Job and Request Parts for Job could be combined and triggered automatically on booking a job. This would remove the time delay “Waiting for Parts” of anything up to half a day and also remove the need for manual intervention by the parts controller in requesting parts. However, after much deliberation, it is decided to leave things as they are. This is in order to take advantage of bulk discounts and delivery procedures, by keeping the temporally triggered Establish Parts for Job. Also complete automation of part ordering is not yet possible due to the level of human expertise needed in choosing the best suppliers for specific requirements and conditions.
We therefore limit the improvement to simply enhance the Process thread diagram, as shown in figure 9, to cater for priority jobs. Note that the EBPs Establish Parts for Job and Request Parts for Job are potentially re-usable by Organize Parts.
© Select Business Solutions, Inc. 2003
Page: 15
Business Process Modeling (BPM)
White Paper
CUSTOMER REQUESTS JOB
BOOK JOB FOR CUSTOMER
PRIORITY JOB IDENTIFIED
JOB BOOKED WAITING FOR PARTS
Organize Priority Job TIME TO ESTABLISH PARTS ESTABLISH PARTS FOR JOB
PARTS ESTABLISHED FOR JOB
REQUEST PARTS FOR JOB
ORGANIZE PARTS
SCHEDULE JOB ITEM
PRIORITY JOB SCHEDULED
PARTS REQUESTED AWAITING JOB SCHEDULE
TIME TO SCHEDULE JOBS
SCHEDULE JOBS FOR DAY
JOB SCHEDULED
COMPLETE JOB
JOB COMPLETED
CUSTOMER ARRIVES FOR CAR
CLOSE JOB WITH CUSTOMER
JOB CLOSED
Figure 9: Service and Repair Vehicle “To Be” Process Thread Diagram
© Select Business Solutions, Inc. 2003
Page: 16
Business Process Modeling (BPM)
White Paper
Process Thread Storyboarding Storyboarding provides an excellent mechanism for interactively developing the process threads and EBPs that are affected by the proposals for business improvement. As there are potentially thousands of scenarios within a business process it will be important to be selective and concentrate on key business cycles. Each business cycle is a set of elementary business processes that represent a general pattern of execution for a process thread. A process thread can execute in terms of several business cycles.
It is important to understand that what we are doing here is business process redesign: this is not the same as systems analysis. We need to consider all aspects of a business process including human interaction within the business context as well as automated activities. This is also a major difference to conventional business analysis which suspends judgment of how a process is to be supported by computer based activities until after a “pure” logical model has been built. Some “how” questions will have a significant impact on how the business actually works, and simply cannot be left until later.
The storyboard itself can take various forms, from simple whiteboard sketches too much more sophisticated simulation using different performance parameters. This approach ventilates discussion, and helps to challenge assumptions.
An informal picture of how we might model the business cycle for standard Service and Repairs is shown in figure 10. After discussion we confirm the elementary processes shown down the left-hand side of the diagram.
© Select Business Solutions, Inc. 2003
Page: 17
Business Process Modeling (BPM)
White Paper
Customer Customer Service Clerk
Book Job for Customer Bookings Form
Parts Controller
Establish Parts for Job Parts Request Report
Supplier Parts Order Form
Requset Parts for Job
Schedule Jobs for Day
Lead Mechanic
Job Schedule
Complete Job
Job Completion Form
Customer Service Clerk
Close Job
Job Closure Form
Customer
Figure 10: Service and Repair Vehicle Storyboard (Both customer and customer service clerk are actors denoted by stickmen; we have used a boxed stickman to denote actors which are internal to the business).
© Select Business Solutions, Inc. 2003
Page: 18
Business Process Modeling (BPM)
White Paper
Identifying Business Tasks We address details of how a particular EBP may be carried out in terms of external and internal actors in collaboration with services provided by a computer system. This results in a business task description and is performed in tandem with storyboarding.
A business task is a sequenced set of interactions, between external and internal actors and between those actors and the proposed system that represents a general pattern of execution for an elementary business process. In order to identify business tasks it is useful to break each elementary process into business steps, thinking of the system as a black box that consumes events and information and provides services. We need to keep the focus on the user’s task, concentrating on chunks of business activity and taking care not to become too preoccupied with the mechanics of the user interface that we envisage will become part of the solution. This avoids becoming embroiled in the design of the HCI before we have understood what the system is actually for in the first place. We keep the focus on business requirements and describe each step in a single statement.
Most of the elementary processes that we identified in the Service and Repair Vehicle process group can be easily described in one business task for each EBP. However, a complex EBP can execute in terms of several business tasks on different business cycles. For example, as we have two business cycles for the process thread Service and Repair vehicle, one for standard jobs and the other for priority jobs, we choose to model the EBP Book Job for Customer in terms of two corresponding business tasks, one for standard and one for priority bookings.
Our analysis results in the set of business tasks, within the Service and Repair Vehicle process group, shown in figure 11.
© Select Business Solutions, Inc. 2003
Page: 19
Business Process Modeling (BPM)
White Paper
Business Task Modeling Business tasks will focus attention on two key types of interaction: between actors (specifically between external and internal actors) and between the initiating an actor and services to be provided by the proposed computer system. This is shown in tabular form below for Book Standard Job for Customer in Figure 12. Shaded rows indicate interactions with system services.
System services are particularly significant, as they will ultimately be provided by objects from within the Perspective architecture. Preconditions and postconditions, from EBP interdependencies, will help to govern the behavior of the services.
Different business tasks might use many of the same services but in different combinations and contexts. For example in figure 11 it is clear that both Book Standard Job for Customer and Book Priority Job for Customer require the following services: Establish customer and vehicle details, Agree service type with customer and Agree repair estimates. By cataloging system services we can readily sew existing services into new system use cases which are grown to meet the needs of new business tasks.
BUSINESS TASK
BUSINESS STEP
Book job for customer
Establish customer and vehicle details
(Standard)
Agree service type with customer Agree repair estimates Find a suitable bay slot for the job Book the job
Book job for customer
Establish customer and vehicle details
(Priority)
Agree service type with customer Agree repair estimates Assess Feasibility of Priority Job Agree Pick Up Time Arrange Chauffeur Raise Priority Job
Establish parts for job
Identify which parts needed for job Create part requests for job Produce part requests report
Request parts for job
Reserve parts in stock for jobs Order outstanding parts for jobs
Schedule jobs for day
Produce jobs scheduled bill of materials Organize acquisition of parts for each job
© Select Business Solutions, Inc. 2003
Page: 20
Business Process Modeling (BPM)
White Paper
Complete job
Manage job to completion Record job labor Record service history Produce Highlight report
Close job with customer
Establish job Produce invoice Warn customer of highlights Receive payment for the job
Figure 11: Service and Repair Vehicle Business Tasks
BUSINESS STEP
BUSINESS STEP ELEMENT
EXTERNAL
Requests to book job
Customer
Request customer details Establish customer and vehicle details
Agree service type with customer
Supplies identification details
Customer Match Customer
For new customer add customer and vehicle details
C.S. Clerk
Add Customer
If service required find available service types
C.S. Clerk
Find Services
Ask for confirmation
C.S. Clerk Customer
If repair required find estimates
C.S. Clerk
Ask for confirmation
C.S. Clerk
Book job to include
C.S. Clerk
Find Bay Slots
C.S. Clerk
Book Job
Customer
services/repairs agreed at bay Confirm job with customer
C.S. Clerk
Figure 12: Book Standard Job for Customer Business Task Description
© Select Business Solutions, Inc. 2003
Page: 21
Find Repairs
Customer
Find dates/times service bays available Agree date/time with customer for identified bay
Book the job
C.S. Clerk
C.S. Clerk
Agree repair requirement Find suitable bay slot for the job
SYSTEM SERVICE
For existing customer use fuzzy list to match customer and vehicle
Agree service requirement
Agree repair estimates
INTERNAL
Business Process Modeling (BPM)
White Paper
Business Processes and Object-Orientation BPM usually arises from a compelling business need or opportunity. Often this will require software solutions to be rapidly developed. Information from BPM must therefore be usable in systems analysis and design, and software development, with as little translation or rework as possible.
Various attempts have been made (Jacobson 1994), to model business processes as objects in order to streamline the process and ensure solutions that are rooted in business needs. Although we accept the concept of a business process viewed in terms of an object, experience on real projects has taught us that the process view is more pragmatic. This is partly because senior executives and users are simply more comfortable with the notion of process. And partly it is because any development process is always faced with the problem of how to model the boundary between the business and the software. We have found that from a practical point of view it makes more sense to “make the break” at the most natural point (between processes and objects) rather than introduce the notion of a process object. Our approach views objects as service providers to business processes.
The analysis in terms of business tasks gives us a ready starting point for identifying system use cases. System use cases are essentially the ways in which actors are going to use the proposed system. They will therefore be a subset of the business tasks covering all actor-system service interaction and excluding any interaction between actors, as illustrated in figure 13.
B u sin ess S tep
1
2
SYSTEM U SE C A SE
3
4
5
Figure 13: System Use Case in Relation to Business Task The Select Perspective architecture consists of different layers of object models. This is essentially a model-based solution space for building software. The Select Perspective also views a business process in terms of layered activity which requires services provided from within the Select Perspective architecture as shown in figure 14. The external business layer consists of external actors that are “given” by definition of the business itself; examples include customers, suppliers, government
© Select Business Solutions, Inc. 2003
Page: 22
Business Process Modeling (BPM)
White Paper
departments and competitors. The internal business layer consists of internal actors that are part of the business and that perform roles within that business; examples include users, operators and managers.
External Actor Layer Internal Actor Layer
USER INTERFACE LOCAL
STORAGE
ENTERPRISE STORAGE
Figure 14: The Select Perspective Architecture in Business Context The Perspective architecture can thus be considered as a set of service layers relative to the business, supporting actors in their role of executing business processes. Business tasks encompass interactions between all three layers (external actors, internal actors and system services). System use cases sit at the boundary between the service layer and the actors which use those services. The service layer is modeled using collaborating objects to provide services to the actors. Each system use case is a typical example of how an actor will use the system given a certain sequence of events. System use cases are usefully pictured as providing a bridge between the object model and business processes as shown in figure 15.
© Select Business Solutions, Inc. 2003
Page: 23
Business Process Modeling (BPM)
White Paper
External Actor Layer
Internal Actor Layer
System Use Case Layer Object Layers
Figure 15: The Anatomy of a Business Process We have seen that analysis of business tasks should have already revealed the need for specific high level system services. We can now abstract out these actor-service interactions to form system use cases. Analysis of the system use cases will help to uncover the need for more detailed services. Notice that system use cases interact between actors and objects. They do not interact with one another. Rather, they communicate via the objects. Each system use case represents a self contained unit of interaction between actors and objects. We can also use our knowledge of required system services, together with requirements for indirect processes to identify classes. This provides a user-driven route into finding the objects responsible for providing such services.
By driving the development of objects in this way, we offer the analyst a mechanism to divide and conquer the complexity of the problem. Each use case offers a different view onto the various business objects which cooperate to support the business process.
We have already stressed the importance of indirect processes which though they do not add measurable business value to the customer are nevertheless part of the lifeblood of the enterprise.
The system use cases will be further distinguished according to whether they serve direct business processes, which add customer value (like selling a product) or indirect processes, which though they add no customer value are nevertheless vital to the business (like acquiring stock).
© Select Business Solutions, Inc. 2003
Page: 24
Business Process Modeling (BPM)
White Paper
Other Key BPM Activities Business Class Modeling: By analyzing business tasks in terms of required system services we have a ready route for identifying business classes in terms of responsibilities. This still leaves a whole category of requirements, including informational and management processes which we have not yet considered. Business class modeling involves the identification and structuring of high level business classes that reflect the semantics of the business domain. However, in real life we have often seen business class modeling usefully employed alongside BPM.
Infrastructure Re-Design. This involves mapping out the logical and technical infrastructure which will be used to support new IT systems. The Select Perspective architecture provides a framework for describing logical infrastructure, and establishes the strategy that an organization will adopt for application development. It provides a framework for effective application of modeling techniques.
Technical infrastructure re-design covers the work associated with building a suitable technical architecture: for example, technology principles, constraints, server distribution, and use of standards such as OLE, CORBA and DCE. This also covers the approach to dedicated persistent storage, legacy systems and support services.
Organization Re-Design. The purpose of this activity is to describe the roles and responsibilities of the people implementing the new processes. A model of the organization structure is built, showing how the roles in the process team fit together across functions or departments. However this is outside our scope.
© Select Business Solutions, Inc. 2003
Page: 25
Business Process Modeling (BPM)
White Paper
Summary The approach taken is to break business processes into their constituent business activities by using process thread and process hierarchy modeling. Analysis of threads of event driven activity is immensely useful in exposing EBPs: the lowest practically useful level of constituent business activities. Business cycles help us to understand the different ways in which EBPs are used; i.e. the business tasks.
We analyze business tasks in terms of interactions between actors and between actors and proposed system services. This gives us a ready basis on which to extract out the actor-system interactions as system use cases. System services will be provided by objects from within the Select Perspective architecture. Preconditions and postconditions, from inter EBP dependencies, will help to govern the behavior of required services, when we model our system use cases. System services are configured in different ways depending on the needs of different system use cases. By cataloging system services we can readily re-use existing services in new system use cases which are grown to meet new business needs. Object technology is ideally suited to this goal of looking to assemble, not code, business solutions. A roadmap summarizing the whole approach is shown in figure 16.
ENTERPRISE
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
BUSINESS PROCESS
PROCESS GROUP
PROCESS GROUP
PROCESS THREAD TRIGGERING EVENT
EBP
BUSINESS STEP
BUSINESS STEP
EBP
BUSINESS STEP
BUSINESS STEP
EBP
EBP
RESULT
BUSINESS STEP
Business Task
System Services Use Case Object 1
Object 2
Object ...
Figure 16: BPM to Objects Roadmap.a
© Select Business Solutions, Inc. 2003
Page: 26
Object n
Related Documents
Business Process Modeling
October 2019 28
Pov Operational Excellence - Business Process Modeling
April 2020 11
Business Process Modeling Notation (bpmn) 1.2
July 2020 6
Chap 9 - Process Modeling
June 2020 11
Process Modeling Dfd 2
June 2020 8