The Process Level of Performance
We have found the Process Level to be the least understood and least managed level of performance. Processes are rolling along (or, frequently, stumbling along) in organizations, whether we attend to them or not. We have two choices—we can ignore processes and hope that they do what we wish, or we can understand and manage them. We have proposed that the only way to truly understand the way work gets done is to view an organization horizontally (as a system) rather than vertically (as a hierarchy of functions). When you view an organization horizontally, you see business processes.
In previous articles, we discussed the systems view at the Organization Level. We introduced the Relationship Map as a tool for viewing an organization as a system. We showed how a tremendous amount of learning and eventual improvement can result from the documentation and examination of the input-output (customer-supplier) linkages depicted in a Relationship Map.
However, between every input and every output is a process. Our understanding and improvement are incomplete if we don’t peel the onion and examine the processes through which inputs are converted to outputs. While the Organization Level provides a perspective, sets a direction, and points to areas of threat and opportunity, our experience strongly suggests that the Process Level is where the most substantive change usually needs to take place. A clear strategy and logical reporting relationships (Organization Level) and skilled, reinforced people (Job/Performer Level) cannot compensate for flawed business and management processes.
What Is a Process?
A business process is a series of steps designed to produce a product or service. Some processes (such as programming) may be contained wholly within a function. However, most processes (such as order fulfillment) are crossfunctional, spanning the “white space” between the boxes on the organization chart.
Some processes result in a product or service that is received by an organization’s external customer. We call these primary processes. Other processes produce products that are invisible to the external customer but essential to the effective management of the business. We call these support processes. The third category of processes—management processes—includes actions managers should take to support the business processes. Examples of these types of business processes appear in Table 5.1.
Understanding and Managing the Organization Level
A process can be seen as a “value chain.” By its contribution to the creation or delivery of a product or service, each step in a process should add value to the preceding steps. For example, one step in the product development process may be “prototype market-tested.” This step adds value by ensuring that the product is appealing to the market before the design is finalized.
Processes are also consumers of resources. They need to be assessed not only in terms of the value they add, but also in terms of the amount of capital, people, time, equipment, and material they require to produce that value.
At the Organization Level, we “peel the onion” to increase our understanding of the customersup-plier relationships among functions. At the Process Level, we peel the onion by breaking processes into subprocesses. The manufacturing process, for example, may comprise these sub-processes: scheduling, tooling, fabrication, as-sembly, and testing.
Why Look at Processes?
An organization is only as effective as its processes. Organization Goal can be achieved only through logical business processes, such as those listed in Table 5.1 . For example, one of an automobile manufacturer's Organization Goals may be to reduce the time it takes to deliver a car with the options requested by a customer. The company cannot hope to meet this goal if it has an inefficient ordering process or a convoluted distribution process.
When we view the situation from the top down, we see that process effectiveness is a major variable in the achievement of Organization Goals. We can also look at the value of processes from the bottom up. At the Job/Performer Level, we can take a variety of steps to improve performance. For example, we can improve our recruiting and promotion practices. We can provide more specific, up-to-date job descriptions, more effective tools, and more attractive incentives. We can drive decision making down in the organization. We can empower teams to solve problems in their work units. However, even talented and motivated people can only improve organization performance as much as the business process allow.
To continue our automobile distribution example, salespeople may be thoroughly completing order forms, data-entry clerks may be accurately coding information, and dock crews may be efficiently loading cars onto trucks. However, the effectiveness of any improvement in their performance could be limited by the logic (or illogic) of the total distribution process made up of the order entry, production scheduling, and transportation subprocesses.
People in jobs such as these can certainly influence the effectiveness and efficiency of the processes to which they contribute. However, we have found that individual and team problem solving rarely focuses on process improvement. Furthermore, actions taken in a single organizational unit often lead to the reinforcement of the functional silos and the system suboptimization. The net message is that, over the long haul, strong people cannot compensate for a weak process. All too often, management relies on individual or team heroics to overcome fundamentally flawed processes. Why not fix the processes and enlist our heroes in the battle against the competition?
Finally, the Process Level is important because process effectiveness and efficiency should drive a multitude of business decisions. For example, a reorganization serves no purpose if it doesn’t improve process performance. Jobs should be designed so that people can best contribute to process outputs. Automation is a waste of money if it calcifies an illogical process. The pivotal link between organization performance and individual performance can be established only through the three variables at the Process Level.
THE PERFORMANCE VARIABLES AT THE PROCESS LEVEL
Each primary process and each support process exists to make a contribution to one or more Organization Goals. Therefore, each process should be measured against Process Goals that reflect the contribution that the process is expected to make to one or more Organization Goals. In our experience, most processes do not have goals. While functions (departments) usually have goals, most key processes do not. If we are working in an organization in which billing is a key process, and if we ask for the goals of the billing process, the response usually is “Oh, you mean the goals of the billing department.” When we reply that we really do mean the billing process—including steps accomplished outside the billing department—we frequently get blank stares.
We believe that measurement is most effective if it is done in relation to targets, or goals. Process Goals are derived from three sources: Organization Goals, customers’ requirements, and benchmarking a process to the same process in an exemplary organization—is particularly useful. Often the organization that is best in its class for a given process is not a competitor and is therefore easy to study. An organization can learn a lot by benchmarking its inventory management process to WalMart’s and its product development process to 3M’s. One of the Organization Goals for Computec, (our software and systems engineering company example), is to introduce three new software products and two new system integration services within two years. As a result, Computec’s product development and product introduction process is critical to its strategic success. The goals it might establish for this process include:
- We will introduce our first new software product within nine months, our second within eighteen months, and our third within twenty-four months.
- We will introduce two new system integration services within twelve months.
- Our five new products and services will generate a total of $4.4 million in revenues and $660,000 in profits during the first full year after their introduction.
- The aerospace industry’s need for each new product or service will be supported by current market research.
- Each new product and service will have applications outside as well as within the aerospace industry.
- New products and services will be unique or will be superior (in the eyes of the customer) to competitors’ offerings.
- New products and services will use our existing sales and delivery systems.
These Process Goals are linked both to Organization Goals and to customers’ requirements. Note that they are not merely goals for the product development department. These Process Goals also reflect the performance expected of product development’s partners in the process of product development and introduction—marketing, sales, manufacturing, and field operations. By meeting these goals, this process will make a significant contribution to the realization of the company’s strategic vision.
A second Computec Organization Goal is to reduce the software package’s order cycle to an average of seventytwo hours by the end of next year. For this goal, Computec’s order-filling process becomes strategically critical. The goals for this process might include:
- No products will be shipped to incorrect addresses because of Computec’s errors.
- We will meet our seventy-two-hour goal without increasing the cost of order filling.
- We will provide our customers with a single point of contact for order questions and feedback.
Given Computec’s Organization Goals, its managers should also establish Process Goals for the customer support process. (The impact of Process Goals on functions will be discussed in the section on Process Management.) In all cases, the key question for Process Goals is:
Are goals for key processes linked to customer and organizational requirements?
Once Computec has established goals for its critical processes, its managers need to ensure that the processes are designed to achieve those goals efficiently. To determine whether each process and subprocess is appropriately structured, we recommend that a cross-functional team build a Process Map, which displays the way work currently gets done. While the Relationship Map, which is built at the Organization Level, shows input-output relationships among departments, a Process Map documents, in sequence, the steps that the departments go through to convert inputs to outputs for a specific process. All too often, a team finds that there isn’t an established process; the work just somehow gets done.
Figure 1 on page 6 contains an “IS” (current state) Process Map of Computec’s order-filling process, as developed by a team representing all functions that contribute to the process. The mapping process starts by identifying the entities involved with the process, listing them on the left-hand axis, and drawing a horizontal band for each. Once this is done, the team (made up of representatives from all the functions listed—possibly including the customer) traces the process of converting the input (orders) through all the intervening steps until the final required output (payment) is produced. The map shows how all functions are involved as the order is processed. This mapping format allows the team to see all the critical interfaces, overlay the time to complete various subprocesses on the map, and identify “disconnects” (illogical, missing, or extraneous steps) in the process.
As the Computec team documented and analyzed the current process for filling an order, it identified a number of disconnects:
- Sales reps take too long to enter orders.
- There are too many entry and logging steps.
- Sales administration slows down the process by batch-processing orders.
- Credit checking is done for both old and new customers.
- Credit checking holds up the process because it is done before (rather than concurrently with) order picking.
The team then created a “SHOULD” Process Map, (see Figure 2 on the following page), which reflects a disconnect-free order-filling process. As the figure shows, the major changes in the “SHOULD” map are:
- Direct order entry by sales, eliminating sales administration
- Parallel order processing and credit checking
- Elimination of multiple order-entry and order-logging steps
Another possible “SHOULD” process would include a Just-In-Time production system, in which packages are assembled to order and not inventoried.
“IS” and “SHOULD” Process Mapping is a central step in Process Improvement Projects. For example, organizations are finding Process Maps to be more useful than procedures manuals as a format for meeting the documentation requirements set forth in the ISO 9000 standards.
A successful Process Improvement Project results in an affirmative answer to the key Process Design question:
Is this the most efficient and effective process for accomplishing the Process Goals?
Unfortunately, even the most logical, goal-directed processes don’t manage themselves. These are the four components of effective Process Management:
1. Goal Management: The overall Process Goals should serve as the basis for the establishment of subgoals throughout the process. If we managed a natural-gas pipeline, we would want to measure pressure and purity, not only at the end but also at various critical junctures along the line. Similarly, we need to establish process subgoals after each step that has an especially critical impact on the ultimate customer-driven Process Goals. Figure 3 shows some examples of process subgoals for Computec’s order-filling process.
Many organizations, particularly in manufacturing industries, use Statistical Process Control (SPC) tools. We fully support the use of these tools, such as control charts, to track process performance, reveal problems, and maintain process stability. We have found that the goal-setting approach depicted in Figure 3 helps identify where SPC tools should be used.
Once process subgoals have been established, functional goals can be developed. Any functional goals established at the Organization Level should be modified, if necessary, to reflect maximum functional contributions to the Process Goals and subgoals. Since the purpose of a function is to support processes, it should be measured on the degree to which it serves those processes. When we establish functional goals that bolster processes, we ensure that each department meets the needs of its internal and external customers.
Computec’s first step should be to identify each function’s contribution to the process. For example, order entry is the first segment (subprocess) of the order-filling process. Three functions contribute to this segment:
- Sales, which enters the order via telephone
- Finance, which determines the customer’s credit status
- Production control, which determines the inventory status and, if necessary, triggers copying to produce additional files
One way to summarize this contribution is through a Role/Responsibility Matrix. On the basis of these contributions, and on the basis of the process subgoals displayed in Figure 3 on the following page, Computec should establish functional goals.
2. Performance Management: After Computec has established a workable order-filling process (Figure 2) and a set of goals and subgoals for its performance (Figure 3), its managers should establish systems for obtaining internal and external customer feedback on the process outputs, tracking process performance against the goals and subgoals, feeding back process performance information to the functions that play a role, establishing mechanisms to solve process problems and continuously improve process performance, and adjusting goals to meet new customer requirements.
During the last few years, we have learned a lot about managing process performance (which is, in effect, managing the horizontal organization). We have learned that if processes are to be managed on an ongoing basis (and not just fixed when they break), then managers must establish an infrastructure, which many organizations are beginning to call Process Management. Computec senior managers could take several Process Management actions to ensure that the order-filling process is continuously managed:
- Rate the performance of the process, giving it a grade in such areas as customer satisfaction, cost, clarity and thoughtfulness of documentation, and quality and quantity of measures. Each function’s contribution to the process could also be rated.
- Designate a Process Owner to oversee the entire process.
- Identify a permanent Process Team, which would meet monthly to review and improve process performance.
- Hold monthly operations reviews, in which process performance would be reviewed first and function performance would be reviewed second.
- Reward people within a function only if Process Goals were met and if the function’s contribution goals were met.
Process Management is a pivotal theme within the Three Levels of Performance.
3. Resource Management: Managers have always understood that resource allocation is a major part of their responsibility. However, process-focused resource allocation tends to be different from the usual functionoriented approach. Functional resource allocation usually results from a series of one-to-one meetings between a senior manager and his or her departmental managers. In these meetings, each manager makes a case for a bigger slice of the pie, and the most persuasive presentations are rewarded with the largest budgets and headcount allocations.
Process-driven resource allocation is the result of a determination of the dollars and people required for the process to achieve its goals. After that is done, each function is allocated its share of the resources, according to its contribution to the process. If Process Management is institutionalized throughout an organization, each function’s budget is the sum total of its portion of each process budget.
In Computec, for example, resources should be allocated to each step in the order-filling process, according to the quality, timeliness, and cost goals established for that process. Then the various functions should receive the resources they require to make their contributions to that process. For example, the process budget may be divided into order entry, credit checking, scheduling, picking, and shipping. Each of these process segments should receive an appropriate chunk of the process budget. The functions responsible for these process segments should therefore receive budgets that will enable them to make their process contributions. Activitybased costing is a tool that can help appropriately allocate budgets and costs across a process.
4. Interface Management: A Process Map (Figure 2) clearly displays the points at which one function (horizontal band on the map) provides a product or service to another function. At each of these points, there is a customer-supplier interface. These interfaces often represent the greatest opportunities for major performance improvement. A process-oriented manager closely monitors interfaces and removes any barriers to effectiveness.
As the Computec Process Map shows, the interfaces between sales and production control and between production control and assembly are critical to the success of the order-filling process. Senior management and the Process Owner should pay particular attention to this “white space.” To ensure proper attention, they should establish and monitor measures that indicate the quality and efficiency of these interfaces.
The Process Management questions are:
- Have appropriate process subgoals been set?
- Is process performance managed?
- Are sufficient resources allocated to each process?
- Are the interfaces between process steps being managed?
Work gets done in an organization through its primary, support, and management processes. If you want to understand the way work gets done, to improve the way work gets done, and to manage the way work gets done, processes should be the focus of your attention and actions. Viewing business issues from a process perspective often reveals a need to make radical changes in goals, in the design of business systems, and in management practices. The Process Level of Performance has significant implications for:
- Executives, who can use the process perspective and tools to link Organization Goals to individual performance, measure what’s really going on in the business, benchmark performance against other companies, establish competitive advantages, assess the impact of mergers and acquisitions, and evaluate alternative organization structures
- Managers, who can use the process perspective and tools to identify and close quality, cost, and cycle time gaps; manage the interfaces with other departments and the interfaces within their own departments; implement change, and effectively allocate resources
- Analysts, who can use the process perspective and tools to diagnose business needs and recommend improvements that will have a significant impact on organization performance, to evaluate actions they are asked to take, and to facilitate improvement teams
If we had to pick one of the Three Levels as the area of greatest opportunity for most organizations, it would be the Process Level. Perhaps that is because it tends to be the least understood and therefore the least managed level of performance. Perhaps it is because work gets done through processes. Perhaps it is because it is the middle level and, as such, serves as the linking pin between the goals, the design, and the management at the Organization Level and at the Job/ Performer Level. Or perhaps it is because application of the process tools can address some of the most fundamental needs facing organizations—building a customer-focused organization, quickly and intelligently adapting to new situations, implementing change, and breaking down barriers between departments.
Regardless of the reasons, the Process Level represents a wealth of largely untapped potential. We are learning that it is not enough to manage results. The way in which those results are achieved (the process) is also important. If we are achieving the results, we need to know why. If we are not achieving the results, we need to know why. In both cases, to a great degree, the answer lies in the process. Once we have processes that are designed and managed to meet Organization Goals efficiently, we can address the needs of the Job/Performer Level.