Business Process Modeling

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

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

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.

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.”

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 time-
slices. 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.

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.

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.

We shall return to indirect processes later in this document. For now, we concentrate on “direct value”
business processes.

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
Triggers a process thread or activity

Business Event
input or output driven.
An outcome of value produced

Result
by the process
Optional Leads to a process to indicate

Dependency its optionality
Mandatory
Dependency Leads to a mandatory process
Activity Generic Process
Exclusivety To indicate a condition
Concurrence P1 P2 To represent parallel processes
For each X
To indicate a repeating process
Iteration
or processes
Process A delay prior to another process

Break 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.

ENTERPRISE
BUSINESS BUSINESS BUSINESS

PROCESS PROCESS PROCESS
PROCESS PROCESS PROCESS PROCESS PROCESS

GROUP GROUP GROUP GROUP GROUP
EBP EBP EBP EBP
BUSINESS BUSINESS BUSINESS BUSINESS BUSINESS

STEP STEP STEP STEP 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


PROCESS THREAD
TRIGGERING EBP EBP EBP RESULT

EBP
EVENT

Figure 3: A Process Thread in Context

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
SERVICE
SELL VEHICLE SUPPLY PARTS
VEHICLE
PERFORM VALET RESTORE SERVICE AND ASSESS

BODY REPAIRS VEHICLE VINTAGE REPAIR VEHICLE 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

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 Book job for customer
job
Business
Temporal Time to establish parts for job Establish parts for job
Internal Parts controller submits parts request Request parts for job
Business
Temporal Time to schedule jobs for day Schedule jobs for day
Internal Lead mechanic completes job Complete job

Business
External Customer arrives to collect serviced car Close job with customer
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.

CUSTOMER
REQUESTS JOB
BOOK JOB FOR

CUSTOMER JOB BOOKED
WAITING FOR
PARTS
TIME TO ESTABLISH PARTS

ESTABLISH PARTS FOR JOB
PARTS ESTABLIS-
HED FOR JOB
REQUEST PARTS
FOR JOB
PARTS REQUESTED
AWAITING JOB
SCHEDULE
TIME TO SCHEDULE JOBS

SCHEDULE JOBS FOR DAY
PARTS ORDER
CREATED
COMPLETE JOB
JOB COMPLETED
CUSTOMER CLOSE JOB WITH

ARRIVES FOR CAR 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
SERVICE
VEHICLE
PERFORM VALET RESTORE SERVICE AND ASSESS

BODY REPAIRS VEHICLE VINTAGE REPAIR VEHICLE DAMAGES
BOOK JOB FOR ESTABLISH PARTS REQUEST PARTS SCHEDULE JOBS CLOSE JOB WITH
CUSTOMER COMPLETE JOB
FOR JOB FOR JOB FOR DAY CUSTOMER
*

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
SERVICE
VEHICLE
PERFORM VALET RESTORE SERVICEAND ASSESS

BODYREPAIRS VEHICLE VINTAGE REPAIRVEHICLE DAMAGES
BOOKJOBFOR ORGANIZE SCHEDULE ESTABLISHPARTS REQUEST PARTS SCHEDULEJOBS CLOSEJOB WITH

COMPLETEJOB
CUSTOMER PARTS JOBITEM FORJOB FORJOB FORDAY 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.

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.

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 ESTABLIS- SCHEDULE
HED FOR JOB ORGANIZE PARTS
JOB ITEM
REQUEST PARTS
FOR JOB PRIORITY JOB
SCHEDULED
PARTS REQUESTED
AWAITING JOB
SCHEDULE
TIME TO SCHEDULE JOBS

SCHEDULE JOBS FOR DAY
JOB SCHEDULED COMPLETE JOB
JOB COMPLETED
CLOSE JOB WITH

CUSTOMER CUSTOMER
ARRIVES FOR CAR
JOB CLOSED
Figure 9: Service and Repair Vehicle “To Be” Process Thread Diagram

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.

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).

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.

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

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 INTERNAL SYSTEM SERVICE

Requests to book job Customer
Request customer details C.S. Clerk
Establish customer and vehicle Supplies identification details Customer
details
For existing customer use fuzzy C.S. Clerk Match Customer
list to match customer and vehicle
For new customer add customer C.S. Clerk Add Customer
and vehicle details
If service required find available C.S. Clerk Find Services
service types
Agree service type with customer Ask for confirmation C.S. Clerk
Agree service requirement Customer
If repair required find estimates C.S. Clerk Find Repairs
Agree repair estimates Ask for confirmation C.S. Clerk
Agree repair requirement Customer
Find suitable bay slot for the job Find dates/times service bays C.S. Clerk Find Bay Slots
available
Agree date/time with customer for Customer
identified bay
Book the job Book job to include C.S. Clerk Book Job
services/repairs agreed at bay
Confirm job with customer C.S. Clerk
Figure 12: Book Standard Job for Customer Business Task Description

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
SYSTEM
3 U SE C A SE
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

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.

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).

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.

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


PROCESS THREAD
TRIGGERING EBP EBP EBP EBP RESULT

EVENT

Business Task
System Services
Use Case
Object 1 Object 2 Object ... Object n
Figure 16: BPM to Objects Roadmap.a

Business Process Modeling

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Business Process Modeling

Hochgeladen von

Copyright:

Verfügbare Formate

Business Process Modeling (BPM)

Disclaimer and Trademarks

© Select Business Solutions, Inc. 2003 Page: 1

© Select Business Solutions, Inc. 2003 Page: 2

© Select Business Solutions, Inc. 2003 Page: 3

© Select Business Solutions, Inc. 2003 Page: 4

© Select Business Solutions, Inc. 2003 Page: 5

In summary, we think of a business process as a family of activities that together collaborate in

© Select Business Solutions, Inc. 2003 Page: 6

Types of Business Process

Generic Customer Processes

Industry-specific customer processes

Generic administrative processes

Table 1: Examples of Types of Business Process

© Select Business Solutions, Inc. 2003 Page: 7

© Select Business Solutions, Inc. 2003 Page: 8

Business Process Modeling Notation

NAME SYMBOL DESCRIPTION

Triggers a process thread or activity

An outcome of value produced

Optional Leads to a process to indicate

Activity Generic Process

Exclusivety To indicate a condition

Concurrence P1 P2 To represent parallel processes

Process A delay prior to another process

Figure 1: Business Process Modeling Notation Set

© Select Business Solutions, Inc. 2003 Page: 9

BUSINESS BUSINESS BUSINESS

PROCESS PROCESS PROCESS PROCESS PROCESS

EBP EBP EBP EBP

BUSINESS BUSINESS BUSINESS BUSINESS BUSINESS

Figure 2: Process Hierarchy Concepts

BUSINESS BUSINESS BUSINESS

PROCESS PROCESS PROCESS PROCESS PROCESS

TRIGGERING EBP EBP EBP RESULT

BUSINESS BUSINESS BUSINESS BUSINESS BUSINESS

Figure 3: A Process Thread in Context

© Select Business Solutions, Inc. 2003 Page: 10

“As Is” Process Hierarchy Diagramming

PERFORM VALET RESTORE SERVICE AND ASSESS

Figure 4: Motor Dealership “As Is” Process Hierarchy Diagram

“As Is” Process Thread Diagramming

© Select Business Solutions, Inc. 2003 Page: 11

EVENT TYPE EVENT NAME ELEMENTARY BUSINESS PROCESS

Internal Lead mechanic completes job Complete job

Figure 5: Service and Repair Vehicle Events and EBPs

© Select Business Solutions, Inc. 2003 Page: 12

BOOK JOB FOR

TIME TO ESTABLISH PARTS

TIME TO SCHEDULE JOBS

CUSTOMER CLOSE JOB WITH

PERFORM VALET RESTORE SERVICE AND ASSESS

© Select Business Solutions, Inc. 2003 Page: 13

Figure 7: Motor Dealership Extended “As Is” Process Hierarchy Diagram

“To Be” Process Hierarchy Diagramming

PERFORM VALET RESTORE SERVICEAND ASSESS

BOOKJOBFOR ORGANIZE SCHEDULE ESTABLISHPARTS REQUEST PARTS SCHEDULEJOBS CLOSEJOB WITH

Figure 8: Motor Dealership “To Be” Process Hierarchy Diagram

“To Be” Process Thread Diagramming

© Select Business Solutions, Inc. 2003 Page: 14

© Select Business Solutions, Inc. 2003 Page: 15

BOOK JOB FOR

Organize Priority Job