5.4. The Performance Variables at the Process Level
Process Goals. 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 cross functional boundaries. 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 those 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 information. Process benchmarking—comparing 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 order-handling and distribution process to L. L. Bean's, its inventory management process to Wal-Mart's, its product development process to 3M's, and its customer service process to American Express's.
One of the Organization Goals of Computec, Inc., our software and systems engineering company (see Chapter Four), 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 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 seventy-two 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 organization requirements?
Process Design. 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 (see Chapter Four), 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 5.1 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, which reflects a disconnect-free order-filling process. That map appears in Figure 5.2.
As the figure shows, the major changes in the "Should" map are:
Direct order en try 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. (A more complete list of Process Improvement Project steps appears in Chapter Ten.) Process Mapping can also be used for purposes other than performance improvement. 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.
Figure 5.1. Computec Order Filling: An "Is" Process Map.
A successful Process Improvement Project results in an affirmative answer to the key Process Design question:
Process Management. Unfortunately, even the most logical, goal-directed processes don 't manage themselves. These are the four components of effective Process Management:
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 5.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 5.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 diskettes
Figure 5.2. Computec Order Filling: A "Should" Process Map.
One way to summarize this contribution is through a Role /Responsibility Matrix, an example of which is included in Chapter Twelve.
On the basis of these contributions, and on the basis of the process subgoals displayed in Figure 5.3, Computec should establish function al goals, such as those that appear in Table 5.2.
Performance Management. After Computec has established a workable order-filling process (Figure 5.2) and a set of goals and subgoals for its performance (Process Goals and Figure 5.3), its managers should establish system s 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 playa role, establishing mechanisms to solve process problems an d continuously improve process performance, and adjusting goals to meet new customer requirements. (In Chapter Twelve, we provide an example of a Performance Tracker that could be used to capture process performance information.)
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 thoroughness 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. (The criteria for selecting Process Owners and a description of their possible roles are included in Chapter Thirteen.)
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 such a pivotal theme within the Three Levels of Performance that we have devoted all of Chapter Thirteen to that subject.
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 function-oriented approach. Functional resource allocation usually results from a series of one-to-one meetings between a senior manager and his or her departmental or subdepartmental 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.
Figure 5.3. Selected Process Subgoals for Computec's Order-Filling Process.
Table 5.2. Selected Functional Goals Based on Computec Order-Filling Process Goals. FUNCTION Functional Goals Summary (Measures and Goals) Timelines Quality Budget Other Measures Goals Measures Goals Measures Goals Measures Goals TOTAL PROCESS Percent of orders received by customer within 72 hours of Computec receipt 95% Percent of accurate orders 100% Average handling cost per order $3.50 Percent of bad debt Inventory turns 1% 12 per year SALES Percent of orders entered within 10 hours of receipt 100% Percent of accurate orders 100% SALES ADMINISTRATION CREDIT AND INVOICING Percent of credit checks done within 24 hours of order receipt 100% Processing cost per order $.50 Percent of bad debt 1% PRODUCTION CONTROL Processing cost per order $.50 Inventory turns 12 per year COPYING Number of scheduling errors per quarter 2 ASSEMBLY AND SHIPPING Percent of orders shipped within 4 hours of receipt 100% Percent of accurate orders 100% Processing cost per order $2.50 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. Activity-based costing (ABC) (Sharman, 1990) is a tool that can help appropriately allocate budgets and costs across a process.
Interface Management: A Process Map (Figure 5.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. As we discussed in Chapter Two, these interfaces often represent the greatest opportunity for performance improvement. A process-oriented manager closely monitors interfaces and removes any barriers to effectiveness and efficiency.
As the Computec Process Map shows, the interfaces between sales and production control and between production control and assembly are particularly 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?