Roles Evolve As Organizations Become More Mature

A few days ago I got into a discussion of the roles required by an organization doing process work, and I pointed out that, roles, like many other things, varied according to the overall process maturity of the organization [1]. Moreover, the focus of different people in the organization necessarily changes as an organization becomes more mature.

Figure 1 provides an overview of the basic CMM stair-step model with its 5 maturity levels. I have added some notes on some of the roles involved in the evolution of process maturity and suggested how they vary as an organization becomes more mature.

Roles-Evolve_fig1
Figure 1. How roles change as organizations increase their process maturity.

A level 1 organization has no well defined processes. Someone has to get process work started. The evolution might get kicked off by some outside agency – as for example a government regulation that requires reports about processes. Or it might be the case that a middle manager arrives from an organization that already focuses on processes and begins to push for a greater process focus at the new organization. The effort might be initiated by a senior executive or by a middle manager, or even by a technical employee. However it begins, there need to be a few people who begin to look for opportunities to use process concepts to make changes in the organization.

A level two organization usually begins by focusing on the documentation and then the redesign of major core business processes. This type of effort is usually undertaken by a team that is more or less independent of the people who perform the business process on a day-by-day basis, although some managers or employees may be recruited to serve on the redesign team. The BPM redesign project requires a manager who is well trained in process redesign and knows the tools and concepts required to undertake a major redesign effort. This person is usually assisted by consultants or internal black belts with specialized skills in process redesign, and by non-BPM people who are familiar with the process and participate in the process redesign effort. As a general rule, a level two process redesign project is sponsored by a senior executive (line of business manager) who is strongly associated with the process to be redesigned.

A level three organization moves beyond specific processes and seeks to create an enterprise-wide vision of how all the processes in the organization work to produce value for customers and other outcomes required by key stakeholders. This is the point at which the organization generates a business process architecture that provides everyone with a good overview of the major processes and relationships that define the organization. A business process architect is required. This person should be a business person and not an IT (Enterprise) architect, as the goal is a business description that business managers can identify with. An enterprise-wide business process architecture, if it's to be really useful, must necessarily involve the inputs of many senior managers and executives. The architecture is usually developed by a team, over the course of several months or years and with the participation of a wide cross-section of the organization's managers. It only occurs when there is serious and sustained support from senior executives.

At this stage, or by the next, most organizations establish a BPM Center of Excellence, and that requires a manager who becomes the lead process advocate in the organization. Again, this should be a business person with a serious commitment to developing the organization's process maturity. This person's technical role is often complemented by an senior executive who assumes overall responsibility for managing the organization's process efforts. In some cases this individual becomes the Chief Process Officer (CPO) of the organization. In some cases the role is assumed by the COO, or by the CIO, but it is often assumed by an executive assigned that one function.

As organizations move from level 3 to level 4, they extend the business process architecture with an enterprise-wide process measurement systems and, eventually, move to a process governance system that assigns managers responsibilities for each major process in the process architecture. This requires a major commitment on the part of senior executives to change both the way the organization evaluates day-to-day performance and the way it organizes managerial jobs, evaluations and bonuses. Many organizations that already have balanced scorecard systems and that use them for managerial performance evaluation extend these systems to support process manager evaluation efforts.

The transition to level 5 is, perhaps, even more difficult than the transition to level 4. In the transition to level 4, managers and executives have to give up their heavy reliance on traditional ideas about functional or departmental goals and managers and shift to a cross-functional, process perspective. In the transition to level 5, organizations have to change their ideas of management, again, and empower employees.

Most level 5 organizations are organized around employee teams who are responsible for the performance and the continuous improvement of specific processes. The process manager shifts from being responsible for the process to being a coach of a team that has taken responsibility for the process. At the same time the organization often switches employee compensation to assure that a significant amount of each employee's salary depends on the success of the process for which the team is responsible. Obviously employees can not assume these roles without training and a major commitment from the organization's management to make this approach work.

Most organizations that are committed to achieving process maturity begin to educate employees and transition to teams well before they reach Level 5, but it is at level five that employee teams become the organization's key role in achieving process excellence, and it is here that the Six Sigma ideal of continuous improvement if fully realized. It is, perhaps, Edward Deming's key insight, that if you want nearly perfect processes, you must move quality control from the “end of the line” to the process itself by assuring that every employee is focused on the effort, and that each employee must be responsible for stopping the line whenever he or she sees a defective product. As this approach is fully implemented, executives and managers shift toward being coaches rather than functioning as traditional managers have in the past. [2]

Most organization's, as we have frequently reported, are between levels 2 and 3. They have documented key, core processes and are seeking to extend their understanding of their processes. Thus, their main focus is in developing individuals with project management skills and skills in analyzing and designing processes. As they proceed, they need help in developing a business process architecture and, perhaps, in establishing a center of excellence. And, of course, they need executive support for these roles.

Note in passing that we have not talked about business analysis, process automation or IT roles at all in this discussion. IT usually operates more or less independently of the overall organization's process maturity. IT developers often use the term “process” to refer to whatever software system they are focused on, and it may or may not have much to do with business processes, as business managers understand them. Similarly, an organization might try to install EPR software with little reference to its current process maturity, and this often leads to serious problems, when there are significant mismatches between what the ERP software supports and the nature of the organization's actual business practices, as understood by employees and business managers.

Business analysts can play any of the process roles described in Figure 1, but in many organizations they avoid these roles and focus only on gathering software requirements for IT.

A BPMS developer can either be a business process role, or an IT role, depending on how the organization intends to use BPMS software. In some organizations, of course, IT people take the lead in helping the organization become more mature in its understanding of business processes, and in those cases some of the roles described in Figure 1 are performed by individuals located within the IT area.

Ultimately, the idea of an organization as a set of processes that work together to produce value for customers and other stakeholders is a perspective. Some individuals get it and others don't. Any organization that wants to embrace the process perspective needs to cultivate individuals, no matter what specific jobs they occupy, who embrace the process perspective and are able and willing to acquire the skills needed to help the organization evolve.

Notes:

[1] Organizations use a wide variety of job titles, so I have tried to focus on roles – which simply describe a task that needs to be performed, and are independent of any specific job title or description. One job can contain multiple roles. One role can be performed by any of several job holders.

[2] Read the Harvard Business Review interview of Toyota CEO, Katsuaki Watanabe, to understand how the CEO of a Level 5 company conceptualizes the role of senior executives in a CMM Level 5 process-centric organization. “Lessons from Toyota's Long Drive: An Interview with Katsuaki Watanabe” by Thomas A. Stewart and Anand P Raman. HBR, July-August 2007.

Read Jeffrey K. Liker and Michael Hoseus's book Toyota Culture: The Heart and Soul of the Toyota Way (McGraw Hill, New York, 2008) for a detailed description of how work groups are implemented in US Toyota plants.

PDF Version

Paul Harmon

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
Share

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share
Share