Harmon on BPM: A BPM Methodology—What Is It and Why It Is Important

As many readers know, I began working in the business process area many decades ago, when I worked for Geary Rummler, and I learned much of what I know about process change from Geary. Since then, I have been involved with many methodologies, including software development methodologies, AI and rule-based software methodologies, management methodologies, and, most recently, I have been collaborating with my business partner, Roger Burlton on the development of a comprehensive methodology for Business Process Management for our sister company, Business Process Associates. Along the way, I have studied most process related approaches and techniques, including Lean and Six Sigma.

In this Column, I want to provide my definition of a BPM Methodology, explore the various components of a good BPM Methodology and describe why I believe it is important for organizations to adopt a comprehensive BPM methodology.

Top-Down vs. Bottom-Up

If I step back from all of the various approaches I have explored, I think the first decision is whether one works top-down or bottom up. Put a different way, a top-down approach starts with a broad, architectural view of an organization; it defines organizational strategies and goals, and then defines the major value chains the organization employs. Other top-down approaches begin with stakeholders, define customer needs and work from those needs to define the goals of a process. Subsequently, one drills down into one of those value chains to major processes and then to subprocesses. In this way, one defines the goals and context for whatever specific process one ends up focusing on. In essence, one begins with the big picture and determines how the specific problem fits within the big picture.

The alternative is to begin with a specific broken process, or a process that a team is trying to improve. Using this bottom-up approach, one begins with the specific process, and later tries to figure out how that specific process relates to other processes, and ultimately, to the goals of the organization. Approaches like Lean and Six Sigma and most IT projects tend to be bottom-up approaches. There are advantages to a bottom-up approach, especially if one wants to train teams throughout the organization to continuously improve their processes, or if one is only concerned with automating a specific task. But, even when you are working bottom up, you need to assure that you area working with a consistent, scalable methodology to assure that everyone in your organization is speaking the same language and working with the same basic set of tools.

Ultimately, choosing between a top-down and a bottom-up approach depends on extent of the change required. If major changes are required, then a bottom-up approach can be very inefficient. You start your analysis, and quickly find that there are causes that lie outside the scope of your project. So, you expand the project and begin again. Or, you don't expand the project and must be content with being able to do no more than focus on some subset of the elements that are involved in fixing the prob;lem you are focused on.

I believe that a comprehensive BPM methodology must support both top-down and bottom-up approaches. Practitioners should be trained to begin with a top-down approach, so they understand all the possible causes of any process problem. At the same time the teams should be trained in continuous improvement techniques to assure ongoing process improvement for existing processes.

A Comprehensive Approach to Process Improvement

The term “process” can be used in many ways. Some use it very broadly to encompass almost everything that can influence the operations of an organization. Others use the term narrowly, and consider case management, or business rules, or change management to be outside the scope of a process improvement effort. I believe in a comprehensive approach – I believe that a well-trained process practitioner should have an extensive tool kit and be able to adjust his or her approach to fit the specific situation they face. The goal, ultimately, is not to diagram a specific sequence of activities, but to improve the overall performance of the organization.

When I think more about what “comprehensive” means, I come up with three different ways in which a methodology can be comprehensive. A methodology can (1) support a comprehensive view of what process work is all about, (2) support a comprehensive set of analysis and redesign techniques, or (3) support a comprehensive set of project management techniques. Let's consider each in turn.

1. A Comprehensive View of Process Work

Modern process improvement efforts started in the early years of the 20th Century in an effort to improve how employees performed specific tasks. It rapidly evolved to encompass entire production lines – a process that started with the beginning of a production run and ended when the product came out the other end of the line.

For some, including most of those in Six Sigma and IT, process work still focuses on improving specific sets of activities and tasks. A process notation like BPMN is, in essence, a way of graphically representing the flow of work between a specific set of activities and tasks.

In Figure 1 I have represented six different “process” concerns. The one in the center on the left that is bright yellow refers to the analysis of a set of activities and highlights what most of us would think of as a process improvement project.

Figure 1. Six areas involved in process improvement

Figure 1. Six areas involved in process improvement

The bold vertical line down the middle separates the three levels of concern in the Project Goals column on the left, from the three levels of concern in the Day-by-Day Operations column on the right.. Looking at level 2, on the left we have a project to improve a specific business process and on the right we have the same process, being executed each day by a team of employees. One can imagine a team of process professionals assigned to a project to improve a specific process, analyzing the process, redesigning the process and then handing it off to the team responsible for executing the process and performing the designated tasks on a day-by-day basis. If those supervisors and employee teams are properly trained, the desired behavior will be reinforced and the teams will identify and propose additional opportunities for incremental improvements on an ongoing basis. If they are not properly trained and the desired behaviors are not reinforced, it will be all but impossible for the teams to perform the process optimally.

A good process methodology ought to support the concerns of the redesign teams and the execution teams. It ought to provide support for a process redesign project, and, independently, it ought to support structures for continuous improvement. Such structures include tools and training for supervisors and employees to enable them to continuously improve the process as they execute the process each day. A methodology that only focuses on redesign or only focuses on execution doesn't provide a full tool box for process practitioners.

Now, consider Figure 1 again. The center row is focused on redesigning and then executing specific processes. How does an organization identify and prioritize specific processes? And, if it provides support for supervisors and employees who undertake continuous improvement efforts, how does it organize that support? The top row suggests two other major concerns: the development of an organization-wide business process architecture, and the ongoing management of that architecture. Every organization has a wide variety of processes and they all interact. Once an organization reaches a certain level of maturity, they need a comprehensive overview of all their process resources, including both their core processes and their various management and support processes. They need a systematic approach to measuring the performance of those processes and to managing those processes that is compatible with their other management concerns. On the project side, the organization needs to make a major effort to define their business process architecture and their measurement and management systems. On the operational side, the organization needs to create a BPM Center of Excellence to manage the ongoing coordination of their process change efforts.

Similarly, at the bottom of Figure 1, we picture the concerns of various support groups, like IT, HR and Facilities, that have an ongoing responsibility to support the business people responsible for the overall management of the core business processes. A process team may analyze a given business process and determine that a software application will be required to improve the process. Similarly, the process team may determine that employees will need to be trained in new behaviors, or that new offices will be required in new locations. All these changes should be driven by the process layer, but they will be executed by the support groups, using their own methodologies. Software developers, for example, will have their own approaches to generating and then maintaining new software applications. A comprehensive business process methodology needs to recognize these distinctions. In the case of IT, for example, a process level redesign team may decide that a software application is desirable, and may develop software requirements to hand off to IT developers. Similarly, new hires, new training requirements or altered job descriptions may need to be coordinated with HR.

Not to belabor this point, but most process methodologies focus narrowly on a single concern. A comprehensive process methodology needs to take a broad approach and be prepared to support any of the six major concerns we have identified in Figure 1. It isn't enough to redesign a process and toss it to operations and hope they can implement the new design. Or, hope they can improve it after they get the new redesign up and running. All these concerns need to be understood, planned for, and supported if performance improvement is to be reliably delivered.

2. A Comprehensive Set of Analysis and Redesign Techniques

At this point, we could consider the tools needed to deal with any of the six concerns we just enumerated, but we'll confine ourselves to one area: process redesign.

Over the years I have explored a wide variety of problems. When I first started doing process work in the late Sixties, there were few computers, and when people asked us to improve a process they meant that we should study what people did and advise on how to improve employee performance. In some cases, this meant training employees to do things in better ways. In other cases, it involved changing the ways managers interacted with employees in order to improve employee motivation.

Later, I worked on human performance problems that involved complex decision making and learned how to analyze the conceptual networks and business rules that employee's used when they make key decisions. And, still later, I learned how to develop software systems to automate tasks or support human decisions.

I've been around long enough to know that different organizations have different types of problems and require different types of techniques for analysis and for redesign. Thus, today, when I approach a serious business process problem – say a request to fix the sales system – or a request to see how a supply chain system can be made more efficient – I come prepared to use any of a variety of tools and techniques.

At a minimum, I think any good business process professional ought to know how to analyze process problems resulting from a variety of causes. For example, they ought to be able to:

  • define scope of business problem
  • define stakeholders and their concerns
  • define measures to let you know you've succeeded in improving situation
  • define customer needs and interactions with business
  • create flow diagram of business process
  • define flows that are very dynamic
  • define quality controls and determine consistency (Six Sigma)
  • define waste or inefficient flow patterns (Lean)
  • define decision management opportunities (business rules)
  • define a process using an industry framework like SCOR or APQC
  • define human performance problems
  • generate job descriptions and training requirements
  • define managerial performance problems
  • define problems with IT support
  • generate software requirements

In some cases we work with conventional modeling tools or existing ERP systems and in other cases we teach users when and where newer BPMS software tools can help in analysis or in supporting a process manager during the operational phase of a process redesign effort.

There are, of course, approaches that teach an individual how to do any of these tasks, but such instruction in isolation, isn't very effective. It creates a practitioner with a hammer who will look at everything as a nail. A comprehensive methodology ought to teach practitioners to look at problems as complex things that could involve any of a wide variety of problems and teach them when and how to do analysis for each. This doesn't require a methodology that reinvents everything. Many of the specific tools and techniques developed in the past are very useful. What is required today is a methodology that combines earlier techniques into an integrated approach that structures the way the practitioner looks at problems so that he considers all the options and knows which specific technique or combination of techniques are best to use in a given environment.

3. A Comprehensive Set of Project Management Techniques

In a similar way, a comprehensive process methodology will bring together a wide range of project management techniques to assure the success of the project. Basic project management techniques are well defined by organizations like the Project Management Institute (PMI). Their approach defines the general skills that project managers need – including things like budgeting, scheduling, team building, milestones and reviews. At the same time, PMI provides for domain specific extensions – and that is exactly what a good business process redesign methodology should provide. For example, change management models from groups like ProSci, and human performance change (culture change) from groups like ISPI should all find a place in a good process methodology. Similarly, approaches like balanced scorecard and process maturity can be integrated.

BPTrends Associates (BPTA) has spent the past decade working to develop a comprehensive, integrated, top-down BPM methodology and training curriculum for process change and improvement that embodies the concepts that I have described here. If others have developed a process methodology that approaches process management in a manner as comprehensive as the BPTA methodology, we aren't aware of them. BPTA has a worldwide network of certified partners delivering our methodology and our training Curricula in multiple languages making it available as widely as possible.

When BPTA teaches a team to set up a project, we not only teach what analysis techniques to use when, but we teach that a project needs to be structured into a series of phases, with structured meetings, interviews and milestones. Certain meetings and interviews are defined to assure that communication is established with relevant stakeholders and that individual's concerns are determined and addressed in the course of the project. Other interviews or meetings are held to assure that employees know what types of changes are being considered or to assure that managers in other areas will support the changes. We teach redesign teams to plan for resistance and we provide them with tools that they can design into the process manager's training to improve the acceptance of changes.

As with analytic techniques, there are methodologies specifically designed to teach process budgeting, change management, or overcoming resistance to change. These offerings, by themselves, teach useful skills, but a process methodology should integrate these management skills into a package that the process practitioner learns to use in an integrated manner.

Putting It All Together

There are lots of courses that contribute to an understanding of how to manage or implement process change. Indeed, most companies have been working at process redesign and improvement for many years and have tried various approaches. Many large companies have both Lean and Six Sigma groups active in process improvement. They support more than one methodology. This can be a strength, as long as someone is responsible for pulling it all and making sure that projects focus on solving overall performance problems and not just specific tactical problems..

Organizations are under a lot of pressure to move quickly and to get results. They don't benefit from turf fights between methodologies and practitioners who want to focus on one small piece of the whole picture. Today, a process methodology has to offer a top-down, comprehensive approach that integrates all of the best practices developed over the course of the last thirty years. Those leading the effort should be knowledgeable regarding how the various approaches can be blended to achieve results quickly and predictably. That's exactly what the BPTA Methodology is designed to do. We create case studies that force students to explore complex situations and mix a variety of techniques to solve a given problem. This isn't a simple, tactical approach. If you want a simple tactical approach, they are out there, but they won't create the kind of knowledgeable process practitioner organizations need today. Organizations need people who can look at the big picture, prioritize options and determine what will get the biggest bang for the time and money available. They must analyze a variety of possibilities, arrive at a comprehensive solution and implement that solution in an effective manner.

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

Speak Your Mind


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