Do you know the methods for presenting business models? Learn about the three standard representations and some of the capability and syntax for each.
Overview of Process Modeling
A process model is an effort to capture real-world processes, ranging from
the overwhelmingly general to the painfully specific, into a logical
representation that can then be studied and manipulated to support different and
better ways to accomplish these tasks. Not all processes have or need
information system support. Automated or not, they should be included in the
Business processes are modeled for the following reasons:
- Understanding business processes
- Reengineering/improving business processes
- Graphically representing interaction between
organizations within the company
- Illustrating the duration of a process cycle
- Developing a business process flowchart
- Crosschecking with entities to ensure completion
Most business processes these days, however, are automated. Applying
information system support to business processes in new ways has been the source
of many of the productivity gains that have led to the ongoing success story for
American business. Applying massive and immediate business process changes using
information systems is the basis for business process reengineering (BPR).
There are three commonly used methods for presentation of business models.
All three represent the same processes. Largely, they are different ways of
looking at the same thing, with some additions in capability and syntax for
each. These three models are discussed in the following subsections:
- The process model
- The function hierarchy
- The dataflow diagram
The Process Model
The first method for modeling business processes is the process model. The
process model allows you to assign processes to particular business units
(organizational units) and show flows of data between those processes and
therefore within and between the organizational units. In Oracle's Designer
product, the process modeler also allows you to allot resources to a
|The process model allows you to assign processes
to organizational units within your enterprise.|
Figure 1 shows a simple process model that includes processes performed by
two different organizational units: ACCOUNTING and OPERATIONS. When a vendor
sends an invoice, this process is triggered. First, an invoice is received along
with the product. The product and quantity on the invoice is checked against the
actual products received. Upon verification, payment is sent to the vendor for
the product, while OPERATIONS updates the inventory of the product in the
database. The large arrow pointing to the Receive Invoice process represents a
triggering event. A box is used to designate each process, whereas the arrow
lines represent flows between processes. Notice that a rounded box encloses
INVENTORY. A rounded box designates a data store or an entity.
Figure 1: Process model depicting
organizational units and processes.
Figure 2 shows a breakdown of the Send Payment process step from the
previous figure. Send Payment has substeps and has been decomposed as shown in
the figure. The processes shown here are child processes of the root process
Figure 2: Process decomposition of
The Function Hierarchy
The second method for presenting process models is the function hierarchy
diagram (FHD). The FHD is best for displaying the process hierarchy. An FHD can
show processes in various levels of decomposition, depending on the point of
interest at the time.
|The functional hierarchy diagram allows you to look at your process model as a hierarchy of tasks.|
A functional hierarchy diagram is shown in Figure 3. The root process, or
function, is Accounting. Accounting has one child function, which in turn has
three child functions of its own. Notice the plus (+) and minus (-) signs next
to some of the functions. The plus sign allows a function to be expanded (show
child functions), and the minus allows a function to be collapsed (hide child
functions). Figure 4 shows how the Manage Accounts Payable function has been
Figure 10.3: Function hierarchy
Figure 10.4: Expansion of a child function.
|In the function hierarchy diagram, notice that process flows are not shown. The
concern in the FHD is on function relationships, not necessarily the flow. An
FHD is an excellent tool to use to show how functions (processes) are related to
The Data Flow Diagram
The third method
for presenting process models is the traditional data flow diagram (DFD). The
DFD shows processes and data flows like the process modeler, but it also assigns
a numeric ID number to each process. Using the generic process model example
discussed earlier, the high-level processes would be DFD level 0, each with its
own unique identifying number to the left of the decimal place with a zero to
|Research and development
further decompose accounting, you would use the accounting processes "1" on the
left and a unique number as the first digit on the right. This would be a
These processes can then be further decomposed. To further decompose accounts
payable, you would use the accounting process's "1" to the left of the decimal
place and the accounts payable process's "1" as the first digit on the right.
You would then add another decimal point and a unique number for each process
beneath accounts payable as the second digit on the right of the decimal place.
This would be a level-2 DFD with two numerals to the right of the first decimal
|Verify receipt of product
These processes can yet again be decomposed. You could
decompose send payment 1.1.3 by adding a decimal place and unique number for
each process beneath send payment. This would be a level-3 DFD, and its
decomposition is shown in the following example.
|Receive disbursal approval
DFD is the oldest method for processing modeling.
Extensive rules are defined for the creation of DFDs that are derived from years
of experience using them. The logical organization brought with the numbering
system also can be valuable.
The DFD is the traditional method for process
modeling, and it assigns a numeric ID to each process based on its parent
process and its sequence as related to other processes on the same
Figure 5 illustrates a data flow diagram based on
the process that has been discussed so far this chapter. The main process shown
in this DFD is "manage accounts payable" (1.1.1). Notice that the step number is
annotated in the upper-left corner of each function. Functions are represented
by rounded boxes. Data stores (entities) are represented by open-ended rounded
boxes. Process and data flows are represented by arrows. This diagram contains
much of the same information found in the process model. The focus here is to
define data access (data usage) by associating functions and entities.
Figure 5: Data flow diagram.
A data flow diagram can be created to illustrate the functions, flows of
data, and data stores associated with a database system being designed. A data
flow diagram is used to show how information moves through an organization.
What Does One Gain from the Process Model?
The business process model is an invaluable tool in communicating process
requirements between developers and users and in capturing them once
communicated. Users, the people who truly understand the current processes, can
look at the description of processes from the model to see if you, as a
developer, really have captured the processes the new system needs to
accomplish. As with the ERD, a picture is worth a thousand words. User feedback
sessions utilizing the process model as the starting point for discussions are
invaluable as you develop the model. Once you've completed the model, it will
hold the process requirements agreed to by developers and users as analysis
turns to design and then to implementation.
|A good developer/consultant will get to know the nature of the business and really
understand the business itself before beginning to use the process model or
asking questions of the user.|
The process of creating the model will help the design team develop a better
understanding of the business. The great depth of detail that must be captured
as you decompose each process will show the designer exactly how the processes
are working and, on occasion, how they're not. It will also often show
opportunities for getting rid of duplicated efforts and gaining economies of
scale by combining duplicate processes on an enterprise level or establishing
new processes that combine several of the old processes more efficiently and
effectively. The process model graphically illustrates the flow of data within
the system. Often, this will be helpful in identifying ways to make those flows
more effective. Unused weekly reports may disappear. Entire applications may be
found that are making no real contributions.
You might be able to design a database without producing process models, but
you can't design a database without considering the business processes that take
place. A database exists for the end user. The end user has a job to perform
that, with or without the use of an automated database system, always requires
at least one process. The database must be designed to fit the mold of the
requirements implied by these processes. Therefore, business processes drive the
need for a database.
In this article, you learned about the three basic models used to visually
represent business processes. These are the process model, the function
hierarchy diagram, and the data flow diagram. The process model shows processes
(starting with a root process), organizational units that perform processes,
flows between processes, and data stores. Data stores refer to entities that
have been defined. The functional hierarchy diagram shows all processes, also
called functions, that have been defined in a hierarchical format so that it is
easy to determine the relationship between processes. The data flow diagram also
shows processes, their flows, and their associated data stores. The DFD is used
primarily to show how data flows within an organization. Data usages can be
defined that determine how processes may access entities and attributes
This article is derived from the book Database Design (ISBN: 0-672-31758-3), which is available
by clicking on the title.
About the Authors
Ryan K. Stephens and Ronald R. Plew are the authors of Database Design (ISBN: 0-672-31758-3), a book by Sams Publishing. Ryan is president and CEO of Perpetual
Technologies, Inc. a database company specializing in Oracle consulting and
training. Ron is vice president and CIO of Perpetual Technologies, Inc. Both
have numerous years of experience training and consulting at the DBA level.
© Copyright Sams Publishing, All Rights Reserved