Steps Toward a Discipline for Process Managers

There is a lot of confusion in the market about what a “process manager” is or is not. Let's begin with a fundamental distinction: There are two types of process managers…

Those who function as Project managers who manage process redesign projects.
Those who function as Operational managers who manage the day-by-day execution and performance of a business process.

Both are, in a sense, “process managers.” One is a manager for a process redesign project, and the other is an operational manager who is in charge of the on-going execution of the process. In this Advisor we are going to ignore project redesign managers and focus only on operational managers who have responsibilities for managing the overall performance of one or more business processes.

At a high level, an operational process manager might be responsible for a value chain. A bit further down, a process manager might be responsible for a process that includes activities that occur within several departmental silos. At a still more fine grained level, a manager might wear two hats and be responsible for an overall process as well as an activity that occurs within the process within a departmental silo. Thus, for example, a manager might be a sales manager responsible for the Sell Widgets process while simultaneously reporting to the head of the sales department.

At Toyota, there are supervisors who are responsible for teams that work on the auto assembly production line. Each of these supervisors is a process manager in the sense that their team is responsible for a specific activity, and they are responsible for managing that specific activity.

In most companies there is little agreement regarding what operational managers need to know or do to support a process-centric organization. Everyone seems to agree that major business processes need to be managed, but how it's to be done is usually left rather vague.

Consider some of the initiatives that have been tried.

When Six Sigma was first developed at Motorola, there was a major emphasis on quality and consistency and on empowering groups of employees to improve the processes they were working on. When Six Sigma became established at GE, Jack Welch mandated that each senior executive's bonus would depend, in part, on achieving Six Sigma goals for his or her division. In other words, operational managers were responsible, in Welch's eyes at least, for improving the business processes they managed. At the same time, GE trained lower level managers in Six Sigma techniques, and those managers were supposed to be responsible for encouraging the employees they managed to work to continuously improve their business processes. Thus, at GE, Six Sigma assumed that senior managers were responsible for improving operational results, and that subordinate managers were responsible for improving day-to-day activities.

Michael Hammer made organizing for process management a key goal of a reengineering project, and often began projects by meeting with executive teams to define an organization's value chains, and then asking that a senior manager be appointed to manage each of the value chains. Following Hammer's approach, organizations either had a matrix structure with some value chain managers and some departmental managers, or one had to convert the entire organization to a process based structure.

In the early 90's the SEI group at Carnegie Mellon, working with Watts Humphrey, developed the Capability Maturity Model (CMM). In essence, CMM assumes that organizations are more mature if they have well defined processes and if they measure and manage to assure that their processes are consistently implemented. More to the point, CMM assumes that it's the managers in an organization that define processes, define measures and then use the measures to be systematic about their management practices. In other words, for CMM, process maturity is a direct consequence of the process knowledge and the process management skills possessed by an organization's managers. To underline this, when SEI does an evaluation of an organization, to determine its maturity, they look to see what the organization's managers know and do. CMM defines a number of process-focused skill-knowledge capabilities that managers need to acquire to assure that the organization becomes more mature.

This management-focused approach puts the CMM approach at a right-angle to most of the process improvement programs that Hammer, Davenport and Rummler were launching in the early Nineties. Hammer, Davenport and Rummler tended to use specialized teams, identify broken processes, inconsistent output, or unnecessary activities, and then seek to change how specific processes are implemented by the employees who perform the work. In many cases they assumed that automation could improve the performance of the day-to-day activities in question.

Toyota has always been the poster child for CMM and practically defines a CMM Level 5 organization. At Toyota, employees are organized into teams and each team is responsible for the efficiency and effectiveness of the specific set of activities the team works on. At the same time, the process manager is expected to coach the team and work with them to improve their activities. Managers at Toyota use reports called A3 reports (refers to a paper size) that summarize how a process is performing. Senior managers review the A3 reports of junior managers and mentor them on how to work with their employee teams. This is often regarded as Level 5 because it has gone beyond Level 4—where operational managers manage processes—and reached Level 5—where every employee is aware of the importance of processes, and the managers serve as consultants rather than the initiators of change. This approach obviously has its limits, especially where major new technology is to be introduced, but it certainly plays an important role in popular conceptions of process management.

Geary Rummler always assumed that every process had a management activity. Thus, if we have a process called Prospect for Sales, someone has to be responsible for managing the Prospect for Sales process. When Rummler examined the Prospect for Sales process he would also examine the management activities to see if the manager was making appropriate planning, hiring, monitoring and feedback decisions. Rummler assumed that is was just as likely that employees were performing ineffectively because of management decisions as it was that they were performing ineffectively as a result of personal failures. In essence, Rummler thought of a process that looked something like the one shown in Figure 1.

Figure 1. A process with its process management activities emphasized.

Unfortunately, too much process redesign is done by individuals who ignore the management activities and only focus on the core activities [1]. Moreover, today it is popular to talk about management processes, referring to processes like Corporate Planning or Finance, and to lose track of the immediate, operational activities of the managers actually responsible for executing specific processes.

And then there are BPMS applications. As initially conceived, BPMS software was going to support process managers as they executed processes. In effect, the BPMS application stood between the core and the management process, monitored, and in some cases directly controlled the core activities, and reported the status of the core process to the process manager. In reality, many, if not most, of the BPMS applications built to date are just updated workflow or EAI applications and only provide minimal support for process management control. One reason for this is that BPMS vendors are building applications for organizations that have no real concept of process management. It's hard to have a new BPMS application provide support for a process manager who doesn't exist. Still, it is the ideal, and as time passes, we hope that better BPMS applications will be developed for more mature organizations and that they will, in fact, empower operational managers to organize and control their processes.

What can most of us do? It's very hard to make a CMM Level 2 organization into a Level 4 organization in a short time. In my experience, convincing organizations to assign process managers for value chains, let alone begin to think of all operational managers as having process management responsibilities, is very hard. It usually doesn't depend on the process practitioner but on a senior executive who either is or is not willing to reconsider how the organization understands the management process. In other words, it depends on a top-down commitment rather than a bottom-up effort. Still, each process practitioner should always keep process management in mind and talk about it whenever he or she can, to lay the groundwork for a top-down initiative.

Every process redesign project should consider what role the local manager plays in establishing goals, training employees, measuring process results, providing feedback and encouragement, and otherwise assuring that the employees working on the process do what the process design calls for them to do. This statement assumes that the local manager in question understands how his or her work involves a process and tracks some measures of what the process generates and how it performs.

The logic is straight forward: Processes—not departments—describe how an organization creates value. You only get what you measure. If you don't measure value chains and their subsidiary processes, you don't achieve consistent results. And, finally, someone has to responsible for achieving results if you are to get them. Jack Welch had it right: If you want an organization to be focused on achieving efficient and effective process results, somebody's bonus needs to depend on it.

Notes

[1] Some process theorists are nervous about management activities that don't have a clear start and end. In essence, most management activities cycle: They check to see if something is correct or within bounds, and, if it is, wait for awhile and check again. If something is out of bounds, then the management activity generates action. These kinds of activities are common enough in process control systems and do not represent a theoretical problem, especially when one considers how important it is to define and manage these activities if one is to assure that a specific process is performing as well as it should. The alternative is to ignore some of the most important levers one can use to improve business processes.

PDF Version

Bio
Latest Posts

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at pharmon@bptrends.com