Functional Managers

Most companies are organized into functional units. Smaller companies tend to structure their organizations into departments. Larger organizations often divide their functional units into divisions and then divide the divisions into departments. The definition of a division varies from company to company. In some cases a division is focused on the production of one product line or service line. In that case the division manager can come very close to functioning as a process manager. In other cases divisions represent geographical units, like the European division, which may represent only a part of a process, or even parts of multiple processes that happen to fall in that geographical area. At the same time, there are usually some enterprise-wide departments like IT or finance. Thus in a large company it is not uncommon to have a mix of divisional and departmental units and managers playing multiple roles.

Figure 6.3 illustrates a typical organization chart for a midsize company. The managers reporting to the CEO include both divisional managers (senior vice president, or SVP, widget division) and departmental managers (CIO, CFO). Some of the departmental managers might be responsible for core processes, but it is more likely they are responsible for support processes.

An organization chart like the one illustrated in Figure 6.3 is designed to show which managers are responsible for what functions and to indicate reporting relationships. In Figure 6.3 it’s clear that the manager of production reports to the VP of widget manufacturing. This probably means that the VP of widget manufacturing sets the manager of production’s salary with some guidance from HR, evaluates the manager’s performance, approves his or her budget, and is the ultimate authority on policies or decisions related to widget production.

In many organizations mid-level functional managers wear two hats and serve as both a functional manager and a process manager. Consider the managers shown in Figure 6.4. In this simple example a value chain is made up of a sale, a manufacturing, and a delivery process. Each of these processes is managed by an individual who works within a functional unit and reports to the head of the functional unit. Thus the same manager—the sales supervisor, for example—is both the functional and the process manager of the widget sales process.

The situation shown in Figure 6.4 is very common. If problems arise they occur because functional units often defend their territory and resist cooperating with other functional units. What happens if the manufacturing process doesn’t get the sales information it needs to configure widgets for shipment? Does the manufacturing supervisor work with the sales supervisor as one process manager to another to resolve the problem, or does the manufacturing supervisor “kick the problem upstairs” and complain to his or her superior? It’s possible that the VPs of sales, manufacturing, and delivery all sit on a widget process committee and meet regularly to sort out problems. It’s more likely, unfortunately, that the VP of sales manages sales activities in multiple value chains and is more concerned with sales issues than he or she is with widget process issues. In the worst case we have a situation in which the issue between the two widget activities becomes a political one that is fought out at the VP level with little consideration for the practical problems faced by activity-level supervisors. This kind of silo thinking has led many organizations to question the overreliance on functional organization structures.

Before we consider shifting to an alternative approach, however, we need to be clear about the value of the functional approach. As a strong generalization, departmental managers are primarily concerned with the standards and best practices that apply to their particular department or function. In most cases a manager was hired to fulfill a junior position within a department—say, sales or accounting—and has spent the last 20 years specializing in that functional area. He or she is a member of professional sales or accounting organizations, reads books on sales or accounting, and attends conferences to discuss the latest practices in sales or accounting with peers from other companies. In other words, the individual has spent years mastering the details and best practices of sales or accounting by the time he or she is appointed a VP. Such an individual naturally feels that he or she should focus on what they know and not get involved in activities they have never focused on before. This type of specialization is a very valuable feature of the functional approach. Thus, for example, bookkeepers in an organization ought to follow accepted accounting practices. Moreover, they ought to follow the specific policies of the company with regard to credit, handling certain types of transactions, etc. The CFO is responsible to the CEO for ensuring that appropriate standards and practices are followed. In a similar way the head of sales follows standard practices in hiring and motivating the sales force. Moreover, the head of sales is well positioned to recognize that a widget sales supervisor is due a promotion and conclude that she is ready to become the new sales supervisor of the smidget sales process when the current guy retires. Functional management preserves valuable corporate knowledge and brings experience to the supervision of specialized tasks. Sometimes, however, it results in senior managers who are very territorial and prefer to focus on their special area of expertise while ignoring other areas.

Process Managers

Since we are primarily concerned with process management we will consider the role of a process manager in a little more detail. Figure 6.5 provides a very general overview of the role of a process manager. (Note that in Figure 6.4 we picture the process manager in a box outside the sales process. Earlier, in Figure 6.2 we pictured the process manager insider the process being managed. There is no correct way to do this and we do it differently, depending on what we are trying to emphasize.) This model could easily be generalized to serve as a high-level description of the job of any operational manager. This model could describe the job of the sales supervisor in Figure 5.4, for example. We’ll talk about it, however, to provide a description of the various managerial activities as they relate to a core process. The key point to consider is that an organization is made up of processes, and for each process there must be someone who is responsible for the day-to-day functioning of that process. At lower levels within an organization the individual who is responsible might very well be a functional manager who is also wearing a process manager’s hat. At higher levels in the organization, wearing two hats is harder because value chains and even large processes like new product development and supply chain often cut across functional boundaries.

Ignoring organizational issues for a moment, let’s just consider what sort of work any process manager needs to accomplish. The process manager is responsible for what happens as the process is executed. He or she is also responsible for working with suppliers, customers, and support processes to ensure that the process he or she manages has the resources and support it needs to produce the product or service the process’s customer wants. When one approaches process management in this way, it is often unclear whether one is talking about a role, a process, or an individual. When you undertake specific process redesign projects you will often find yourself analyzing whether or not a specific process manager is performing in a reasonable manner. Things the specific individual does or doesn’t do may result in process inefficiencies. When you focus on organization charts and managerial responsibilities you are usually focused on the role and seek to define who a specific manager would report to, without concerning yourself with the specific individual who might perform the role. Finally, when you focus on the competencies that a process manager should have to function effectively you are focusing on the managerial processes that successful individuals need to master if they are to perform the role effectively.

In Figure 6.6 we have expanded the process management box from Figure 6.5 and inserted some typical managerial processes. Different managerial theorists would divide or clump the activities that we have placed in the four managerial processes in different ways. Our particular approach is simply one alternative. We divide the process management process into four generic subprocesses: one that plans, schedules, and budgets the work of the process; one that organizes the workflow of the process, arranges for needed resources, and defines jobs and success criteria; one that communicates with employees and others about the process; and one that monitors the work and takes action to ensure that the work meets established quality criteria. We have added a few arrows to suggest some of the main relations between the four management processes just described and the elements of the process that is being managed.

Most process managers are assigned to manage an existing process that is already organized and functioning. Thus their assignment does not require them to organize the process from scratch, but if they are wise they will immediately check the process to ensure that it is well organized and functioning smoothly. Similarly, if they inherit the process they will probably also inherit the quality and output measures established by their predecessor. If the new manager is smart he or she will reexamine all the assumptions to ensure that the process is in fact well organized, functioning smoothly, and generating the expected outcomes. If there is room for improvement the new manager should make a plan to improve the process. Once satisfied with the process the manager has some managerial activities that need to be performed on a day-to-day basis and others that need to be performed on a weekly, monthly, or quarterly basis. And then, of course, there are all the specific tasks that occur when one has to deal with the problems involved in hiring a new employee, firing an incompetent employee, and so forth.

Without going into details here, each process manager sometimes functions as if he or she were a process analyst, considering redesigning the process. All of the tools described in this book can be useful to a business manager when he or she is functioning in this role. In essence, the manager must understand the process and know how to make changes that will make the process more efficient and effective.

We’ll consider the specific activities involved in process management in a later chapter when we consider how one approaches the analysis of process problems. At the enterprise level we will be more concerned with how companies establish process managers, how process managers relate to unit or functional managers, and how processes and process managers are evaluated.

Process managers, especially at the enterprise level, have a responsibility to see that all the processes in the organization work together to ensure that the value chain functions as efficiently as possible. While a functional manager would prefer to have all the processes within his or her department operate as efficiently as possible a process-focused manager is more concerned that all the processes in the value chain work well together and would in some cases allow the processes within one functional area to function in a suboptimal way to ensure that the value chain functions more efficiently. Thus, for example, there is a tradeoff between an efficient inventory system and a store that has in stock anything the customer might request. To keep inventory costs down the inventory manager wants to minimize inventory. If that’s done then it follows that customers will occasionally be disappointed when they ask for specific items and learn that they are not in stock. There is no technical way to resolve this conflict. It comes down to the strategy the company is pursuing. If the company is going to be the low-cost seller they have to keep their inventory costs down. If, on the other hand, the company wants to position itself as the place to come when you want it now they will have to charge a premium price and accept higher inventory costs. The process manager needs to understand the strategy the company is pursuing and then control the processes in the value chain to ensure the desired result. In most cases this will involve suboptimizing some departmental processes to make others perform as desired. This sets up a natural conflict between functional and process managers and can create problems when one manager tries to perform both roles.

If we had to choose the one thing that distinguishes a process manager from a functional manager it would be the process manager’s concern for the way his or her process fits with other processes and contributes to the overall efficiency of the value chain. This is especially marked by the process manager’s concern with the inputs to his or her process and with ensuring that the outputs of his or her process are what the downstream or “customer” process needs.

Functional or Process Management?

As we have already seen, at lower levels in the organization it’s quite common for a single manager to function as both a unit and a process manager. At higher levels, however, it becomes harder to combine the two roles. Thus, when an organization considers its overall management organizational structure, the organization often debates the relative advantages of an emphasis on functional or process management. Figure 6.7 illustrates a simple organization that has two value chains, one that produces and sells widgets and another that sells a totally different type of product, smidgets. This makes it easy to see how the concerns of functional managers differ from process managers. The head of the sales department is interested in maintaining a sales organization. He or she hires salespeople according to sales criteria, trains salespeople, and evaluates them. Broadly, from the perspective of the head of sales, selling widgets and selling smidgets is the same process, and he wants to be sure that the selling process is implemented as efficiently as possible. The VP for the widget process, on the other hand, is concerned with the entire widget value chain and is primarily concerned that the widget sales and service processes work together smoothly to provide value to widget customers. The widget process manager would be happy to change the way the sales process functions if it would, in conjunction with the other widget processes, combine to provide better service to widget customers.

Thus, although it’s possible for one individual to serve as both a unit and a process manager, it’s a strain. Without some outside support from someone who emphasizes process it’s almost impossible.

Setting Goals and Establishing Rewards for Managers

Managers, like everyone else, need to have goals to focus their efforts. Moreover, in business situations managers will predictably try to accomplish the goals they are rewarded for achieving. Rewards can take many forms: being told that you did a good job, getting a raise, knowing you are likely to get promoted, or receiving a significant bonus. The key point, however, is that a well-run organization sets clear goals for its managers and rewards effective performance. If the goals aren’t clear, or if a given manager is asked to simultaneously pursue multiple, conflicting goals, then suboptimal performance will invariably result. In examining defective processes it is common to find managers who are being rewarded for activities that are detrimental to the success of the process. This sounds absurd, but it is so common that experienced process analysts always check for it.

Does the organization really want more sales, and does it motivate the sales manager in every way it can? Or does it want sales reports turned in on time, and does it reward the sales manager who always gets his or her reports in on time while criticizing the sales manager who achieves more sales for failing to submit the reports? We remember working on a call center process where the management wanted the agents to try to cross-sell hotel stays to people who called to ask about airline flights. One group worried that, despite training and posters in the call center, few hotel stays were being sold. A closer examination showed that the call center supervisor was rewarded for keeping the number of operators at a minimum. That was achieved by keeping each phone call as short as possible. The time operators talked to customers was carefully recorded, and operators who handled more calls in any given period were rewarded and praised. Those who spent more time on their calls—trying to sell hotel stays, for example—were criticized. There were no compensating rewards for selling hotel stays, so predictably no hotel stays were being sold.

When we consider the analysis of specific processes we will see that it is important to carefully analyze each manager’s goals and motivation. If a process is to succeed, then we need to be sure the manager’s goals and rewards are in line with the goals of the process. Thus, just as it is important to have a management system that focuses on integrating and managing processes, it is important to see that there is a system for aligning the goals and rewards given to specific managers with the goals of the processes that they manage. We’ll consider performance measurement and then return to a discussion of how an organization can align measurement and manager evaluation.

PMI’s Project Management Maturity Model

PMI distinguishes between operations management (ongoing) and project management (done in a limited timeframe). They describe a body of knowledge about project management (PMBOK) and an Organizational Project Management Maturity Model (OPM3) that organizations can use to (1) evaluate their current sophistication in managing projects and then use as (2) a methodology for introducing more sophisticated project management skills. In their PMBOK and in the OPM3 they assume that there are five management processes that every project manager must learn. They include (1) initiating, (2) planning, (3) executing, (4) monitoring and controlling, and (5) closing. Figure 6.11 suggests how the skills involved in each of these processes map to our general overview of management.

Our general model of management (Figure 6.6) pictures an operational management role and describes the activities that a process manager must perform. Project management extends that by adding a process for defining the nature of the specific project to be managed (initiating) and another that critiques the project and pulls together things that were learned in the course of the project (closing).

SEI’s CMMI Model

The best known of all the process maturity models is the SEI’s CMMI, which we discussed in some detail in the Introduction. Although CMM was originally developed to evaluate IT departments, the extended version CMMI is designed to help companies evaluate and improve any type of business process. CMMI supports two ways of organizing your effort. You can either analyze the capabilities of a given department or group of practitioners or you can focus on the overall maturity of an organization. The first, which focuses on capability levels, looks to see what skills are present and then focuses on teaching managers or process practitioners the skills that are missing. The second, which focuses on maturity levels, assumes that organizations become more process savvy in a systematic, staged manner and focuses on identifying the state the organization is at now and then providing the skills the organization needs to move to the next higher stage. Obviously, if you focus on organizational maturity, then CMMI functions as an enterprise process improvement methodology that provides a prescription for a sequence of process-training courses designed to provide process managers with the skills they need to manage their process more effectively. If you focus on the individual work unit and emphasize capabilities, then CMMI provides a set of criteria to use to evaluate how sophisticated specific process managers are and to determine what management processes they need to master to more effectively manage the specific process you are trying to improve.

No matter which approach you use, once the basic evaluation is complete the focus is on either the management processes that need to be acquired by the organization’s managers or on the activities needed by individuals who are responsible for improving the organization’s existing processes.

Although CMMI doesn’t place as much emphasis on types of management as we might one way they organize their processes is based on the type of manager who will need to master the process. Thus they define some management processes for operations managers (which they term process management), a second set of processes for project managers, and a third set for engineering and support managers who manage enabling or support processes. Figure 6.12 shows how CMMI would define the various management processes and shows at what organizational maturity level company managers would normally require the ability to use those processes. It will help to understand the CMMI classification if you keep in mind that day-to-day operational managers need to manage routine improvements in processes, but that major changes are undertaken as projects and that a business process management group that maintained an architecture or provided process consultants (black belts) to a specific project effort would be a support group. Put a different way, CMMI’s focus is on improving processes, but their major assumption is that processes are improved as they are defined, executed consistently, measured, and as a result of measurement systematically improved. Ultimately, putting these elements in place and executing them on a day-to-day basis is the responsibility of the individual who is managing the process.

Here are the definitions that CMMI provides for its process management “process areas”:

• • OPD—Organizational process definitions process. Establish and maintain a usable set of organization process assets and work environment standards.
• • OPF—Organizational process focus process. Plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.
• • OT—Organizational training process. Provide employees with the skills and knowledge needed to perform their roles effectively and efficiently. It includes identifying the training needed by the organization, obtaining and providing training to address those needs, establishing and maintaining training capability, establishing and maintaining training records, and assessing training effectiveness.
• • OPP—Organizational process performance process. Establish and maintain quantitative understanding of the performance of the organization’s set of standard processes in support of quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.
• • OID—Organizational innovation and deployment process. Select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies.

If we were to map this particular subset of operational management processes to our general process management model (Figure 6.6) it would look something like what we picture in Figure 6.13. We placed numbers in front of the processes to suggest that at maturity Level 3 a manager would be expected to have the capabilities identified as (3). As the individual or organization matured and reached Level 4 you would assume the manager had mastered the (4) processes and at Level 5 he or she would have mastered the (5) processes.

SCC’s SCOR Framework

The SCC is primarily focused on defining the core processes that make up a supply chain system. At the same time, however, they have a generic process called plan. For each supply chain process, such as source, make, deliver, or return, they require the modeler to add a plan process. In fact, they require a hierarchy of plan processes, in effect creating a picture of the process management effort required for a supply chain process. Figure 6.14 shows how SCOR analysts would model a simple supply chain. To simplify things we only show plan processes for the top row of processes. Within Alpha there are two departments, which are separated by the dashed line. Within each department there are source, make, and deliver processes. There is one plan process for each. In addition, there is one plan process for all of the plan source, plan make, and plan deliver processes within a given department.

The SCC defines four subprocesses for their plan process, which vary slightly depending on the core process they are supporting. The plan make subprocesses include:

• • PM1 Identify, Prioritize, and Aggregate Production Requirements
• • PM2 Identify, Assess, and Assign Production Resources
• • PM3 Balance Product Resources and Requirements
• • PM4 Establish Production Plans

Although they don’t picture the processes on their thread diagrams the SCC’s SCOR framework also defines an enable process and then defines enable subprocesses. Here are the eight enable make subprocesses:

• • EM1 Manage Production Rules
• • EM2 Manage Production Performance
• • EM3 Manage Production Data
• • EM4 Manage In-Process Production Inventory
• • EM5 Manage Equipment and Facilities
• • EM6 Manage Make Transportation
• • EM7 Manage Production Network
• • EM8 Manage Production Regulatory Compliance

The subprocess list reflects the more specialized role of the supply chain manager. In addition, while a lower level make process manager might not be concerned with some of these subprocesses, higher level supply chain managers would and this reflects the fact that SCOR describes not only the work of the immediate managers of a process but also considers the work that the manager’s boss will need to do.

The SCC decided to focus on management processes that are more knowledge intensive and thus didn’t include things like assigning people to tasks, monitoring output, or providing employees with feedback. An overview of how the SCOR management processes map to our general process management model (Figure 6.6) is presented in Figure 6.15.

The ITGI’s COBIT Framework

ITGI developed their process framework to organize the management of IT processes. Their high-level IT management processes map easily to our general management model (see Figure 6.16).

ITGI has defined subprocesses for each of their processes and the subprocesses also reflect our general model. Thus, for example, the ITGI subprocesses for plan and organize (PO) include:

• • PO1 Define a Strategic IT Plan
• • PO2 Define an IT Architecture
• • PO3 Define Technical Direction
• • PO4 Define IT Processes, Organization, and Relationships
• • PO5 Manage IT Investment
• • PO6 Communicate Management Aims and Directions
• • PO7 Manage IT Human Resources
• • PO8 Manage Quality
• • PO9 Manage Projects

As we look at the subprocesses we realize that the COBIT management processes are more appropriate for a CIO or a senior IT manager and not for the manager of maintain ERP applications, let alone the manager of the process to maintain ERP for accounting.

On the other hand, a review of the COBIT documentation shows that COBIT not only defines high-level IT management processes, but also defines goals for the IT organization as a whole, and then shows how different IT management processes can be linked to IT goals and proceeds to define metrics for each management process.

We have not gone into any of the various process management frameworks in any detail. For our purposes it suffices that readers should know that lots of different groups are working to define the processes that managers use when they manage specific processes. Some groups have focused on the activities, skills, and processes that a manager would need to manage an ongoing process, and others have focused on the activities, skills, and processes a manager would need to manage a project. Some have focused on the activities of senior process managers, and others have focused on managers who are responsible for very specific core processes. As we suggested earlier, defining process management is hard. Different people have pursued alternative approaches. Some simply diagnose what specific managers are doing wrong as they look for ways to improve the performance of a defective process. Others focus on the actual processes and activities that effective managers need to master to plan, organize, communicate, and monitor and control the process they are responsible for managing. Organizations that focus on managerial processes usually tend to establish process management–training programs to help their managers acquire the skills they need to perform better.