October 25, 2016
Hot Topics:

Understanding Process Modeling

  • March 16, 2001
  • By Developer.com Staff
  • Send Email »
  • More Articles »

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.

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel