What is a Process Model?

At one end of the spectrum, people associate a process model with a simple flow chart. At the other end of the spectrum, people associate it with complex variants such as use cases and discrete event models. BTM's concept of a process model falls somewhere between these two extremes. Process models are highly graphical in nature. They are usually expressed as a diagram in which shapes represent tasks and line connectors represent links or flows. So it is easy to understand why, on the surface, they might resemble common flow charts . In addition to this visual diagram, however, process models also contain a rich set of attributes and depict a complex series of relationships. Attribute information including metrics (average time to process a sales order, for example) can be useful inputs for other activities such as discrete event model simulation, while relationships help to capture process requirements and identify dependencies between people, processes, and technologies. The important distinction to make between a process model and its more simple and complex relatives is that it encapsulates the correct amount of detail for timely , real-world analysis and decision-making, without going to the extreme of empirical unreality.

In general, process models include four categories of items:

- Process Hierarchies provide a logical structure that groups processes into levels for easier viewing, understanding, and analysis.

- Process Definitions and Flows describe how a company performs operational tasks and indicate both the order in which the tasks are performed and the information that is passed back and forth during the execution of those tasks.

- Domains and Roles specify who is responsible in the organization for carrying out particular tasks along with the outright ownership or sharing of responsibility.

- Metrics and Rules describe how well a process should perform and indicate how specific conditions dictate the way or timing in which particular tasks are performed.

Process Hierarchies

The depth to which an organization chooses to decompose its processes depends on how work activity is divided among the various horizontal and vertical layers of the organization, and on the extent of the process analysis being conducted . At a minimum, a process hierarchy should include three levels ”processes, sub-processes, and activities. The purpose of the hierarchy is to provide a logical structure for drilling down from one process area to the next . This is especially helpful given the complex nature of enterprise processes. A beginning-to-end map of just a single enterprise process ”even without depicting any related processes ”could easily span the walls of an entire conference room. Organizing process elements into hierarchies makes it easy to group and traverse different levels. For example, the process Invoice and Service Customers could be broken down into the sub-processes Bill the Customer, Provide After-sales Service, and Respond to Customer Inquiries. The Bill the Customer sub-process could be further decomposed into the activities Develop, Deliver, and Maintain Customer Billing, Invoice the Customer, and Respond to Billing Inquiries (see Fig. 6.1).

Figure 6.1. An example process hierarchy for the Invoice and Service Customers process

Classifying processes into a hierarchy also facilitates the identification of appropriate anchor points for cross-links between the process model and business or technology models. This makes it easier to follow decisions from one model to the next to achieve alignment. In the above example, the process, Invoice and Service Customers, could be linked back to the business objective, Make it Easier For Our Customers to Carry Out Transactions With Us, to show how requirements from the business model are inherited into process optimization. Similarly, the activity, Invoice the Customer, could be linked forward to the application functionality, Electronic Bill Presentment, in the technology model to show where specific application and system decisions originate.

Process Definitions and Flows

The purpose of process definitions and flows is to provide a detailed understanding of how work is performed from a beginning to an end point. They describe operational tasks in both graphical (diagrammatic) and textual terms. Shapes and text identify what task is being performed and how it happens. While there is no categorically right or wrong way to describe tasks with shapes, there are commonly accepted representations. For instance, a rectangle is often used to represent a process, a diamond to represent a decision, an upside-down quadrilateral to represent a manual operation, a parallelogram to represent data, an ellipse to represent a termination point, and so on. Text that is associated with each shape ”expressed in clear business terminology instead of technical jargon ”provides additional information that explains the task to a broad audience (see Fig. 6.2).

Figure 6.2. An example process flow that depicts the billing process for a hypothetical automobile insurer

In general, there are two main types of flows: work flow and information flow. Work flow refers to the order in which tasks are performed, and indicates whether tasks are carried out sequentially or in parallel. Information flow shadows work flow and describes how information and decisions travel between tasks. Line connectors graphically tie the tasks together and illustrate the type of relationships (input or output) between them. The combination of process definitions and flows provides insight into the tasks that are manual, automated, out-sourced, or documented; the interdependencies that exist between tasks; and the informational or functional needs of each task.

Several notations are available that attempt to standardize how process definitions and flows are depicted, including Rummler-Brache, Integrated DEFinition (IDEF), Entry/Task/Validation/eXit (ETVX), Line of Visibility Engineering Methodology (LOVEM) , and Role Activity Diagrams (RADs) ^[1] . These vary according to their application and intended audience. Each has its strengths and weaknesses regarding its balance between uniform representation and the need for practical and flexible use. The decision to adhere or not to a particular notation should be made by each company independently based on the skills of its work force, the scope and objective of its process analysis, and the effort that will be required to enforce compliance.

Domains and Roles

Domains and roles identify the areas of the business and the individuals that are responsible for executing processes. Domains more or less correspond to the enterprise's organizational units. Examples of typical, generic domains include manufacturing, sales, marketing, customer support, finance, and human resource management. Examples of more industry-specific domains are claims processing, store operations, and plant management. Roles (sometimes referred to as actors) indicate who owns tasks at a more granular level ”departmental, group, individual, location site, internal, or external. Domains and roles are represented horizontally or vertically as swim lanes that are overlaid on process diagrams to demonstrate how tasks are segregated or shared. Figure 6.3 shows how swim lanes are applied to the previous example of the auto insurance billing process.

Figure 6.3. Swim lanes in our example billing process flow indicate who owns each task

The focus on domains and roles sometimes creates confusion between aspects of process optimization and those of organizational design. The primary intent of domains and roles is not to recreate or reengineer the organizational structure of a company. Instead, it is to group similar sets of processes, sub-processes, and activities together in a way that approximates how the business categorizes its operations and to highlight where responsibilities are transferred between organizational entities. This makes it easier to visualize how process changes might impact resource utilization, staffing, training, and cross-functional requirements.

Metrics and Rules

Companies generally apply a combination of performance metrics to their processes. Performance metrics specify how well a company needs to execute certain tasks. They tend to focus on target outputs that are more external in nature, such as meeting customer requirements. These metrics are expressed in terms of frequency, volume, effort level, error rates, cycle time, forecast accuracy, customer satisfaction, and such. For example, a company that wants to decrease return rates for its products might assign an accuracy performance metric to the order fulfillment process. Or, a company following the Six Sigma methodology might assign a numerical value to the invoice-processing activity to indicate what the statistically valid ideal should be per hour .

The process model also includes rules, designed to act as checks and balances on the execution of a particular process. The business owner of the process (domain, department, group, etc.) determines what rules need to be applied in order to ensure that certain process goals are met. Mostly, these rules are conditional ”if condition A is met then do B. Benefits enrollment terms, seasonal pricing schedules, credit checks, inventory replenishment alerts, and purchase-level amount authorizations are typical conditions that might require the application of rules to a process. It is important to note that these are not application logic rules or database triggers that actually automate the process; they do however, guide application and system developers in translating these business principles into programming code.

Metrics and rules are assigned in the process model as attributes. Figure 6.4a demonstrates how metrics are assigned to the sub-process Pick Orders. Figure 6.4b illustrates how rules are assigned to the activity Perform Physical Inventory Count of the Manage Inventory sub-process.

Figure 6.4a. The metric Perfect Order Fulfillment is assigned to the process Pick Orders

Figure 6.4b. A rule that indicates an alert should be sent to the materials manager if inventory falls below 66% is assigned to the process Perform Physical Inventory Count