Understanding Process Modeling
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 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