Understanding Process Modeling

by Developer.com Staff

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 model.
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 process.

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 Send Payment.

Figure 2: Process decomposition of Send Payment.

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 expanded

Figure 10.3: Function hierarchy diagram.

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 one another.

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 the right.







Human resources 


Research and development 


To 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 level-1 DFD.



Accounts payable 


Accounts receivable 




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



Receive invoice 


Verify receipt of product 


Send payment 


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

Print check

Prepare envelope

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 level.
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 (data).

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

This article was originally published on Friday Mar 16th 2001
Mobile Site | Full Site