Harmon on BPM: The Four Key Diagrams for Business Process Analysis Work

The analysis of a business process, whether because you intend to transform the organization and change the process utterly or whether you simply plan to improve the process in some limited way, requires that you think about how the process works. Diagrams are one of the best ways to organize your thinking about a business process. Over the years a wide variety of diagrams have been proposed – some narrowly focused on specific tasks and some more generic. In this Column I want to give you my opinion as to the four most useful diagrams for process analysis work. The four diagrams I will talk about are pictured in Figure 1 and include:

• the Scope Diagram, for an initial analysis of how the process interacts with its environment,
• the BPMN flow diagram with swimlanes and a customer pool, for the analysis of the activities and the flow within a process,
• the Decision Management Diagram for an overview of how business knowledge used for decisions is organized, and
• the Process Management Diagram for the analysis of how a process is governed.

In Figure 1, I picture all four diagrams and then suggest where the diagrams are most useful in a typical process redesign effort.

Figure 1. The Most Important Diagrams in a Process Redesign Effort

The Scope Diagram

One begins any process analysis effort by assuring that one understands exactly what management is trying to accomplish and the exact scope of the process one is trying to improve. There are several diagrams that can play a role in this task, but the most important is the scope diagram. One places the name of the process-in-scope in the center of the diagram and then proceeds to examine all of the interactions between the process-in-scope and its environment. One examines inputs, where they come from and how they impact the process-in-scope. One examines outputs, where they go, and how they impact those that receive the outputs. One also considers the rules and constraints on the process and the resources and support activities that support the process. One asks, in every case, if the inputs or outputs are currently acceptable, or if they could be improved. One ends with a clear idea of all of the ways the process interacts with stakeholders, other processes or systems, and which of those interactions could be improved.

Figure 2. A Scope Diagram

(Modified from BPTrends Associates class materials.)

This diagram lets you establish the nature of the problem and to gain some idea of the kind of effort that will be required to improve the process. This diagram had its origins in early IDEF0 diagrams, but owes its current form to Roger Burlton, who began to promote the use of this diagram some 20 years ago.

BPMN Flow Diagram

One creates a Scope Diagram without considering exactly how the process works. Instead, one simply focuses on the interactions between the process and its environment. Once one understands the scope of the process and the nature of the problems, one needs to drill into the process to define the causes. The best way to do this is with a Flow Diagram, and the most widely used flow diagram notation is the OMG's BPMN diagram. Some would argue for other flow notations – and eventually we will probably move to a modified flow diagram that accommodates some of the concerns of the Case Management people, but for most purposes, the best way to drill into the details of a process is to use a BPMN diagram to look at how the specific activities within the process work to produce the results that one is interested in. There are several BPMN flow diagrams one could use, but for most business situations, the best is a swimlane diagram with a customer pool about the process and various support process pools below it. This basic diagram was developed in the 1980s by Geary Rummler and popularized by Geary Rummler and Alan Brache. In essence, the diagram tracks interactions between customers or suppliers and follows as inputs are transformed, by means of a series of activities into outputs of value to customers.

Figure 3. A BPMN Flow Diagram.

BPMN Flow Diagrams can become quite complex, but by combining what one learned about problems, in the Scope Diagram, with a series of Flow Diagrams, one can limit the detail one needs to capture, drilling down only in areas where one knows one has a problem.

Decision Management Diagram

One of the things an analyst does, as he or she examines each activity within a process, is to determine the nature of the work being done by the activity. Some activities are manual activities done by employees, others are automated and done by computer systems. Many require a mix of human and machine work. Some involve decisions. When problems result from decisions that are incorrect or suboptimal, the decisions should be examined in detail. In most cases, defining the nature and correct approach to a decision involves defining the facts and the rules (knowledge) used in the decision process.

Figure 4. A Decision Management Diagram
(After an illustration in the OMG Decision Model and Notation (DMN) Specification, 2012.)

A Decision Management Diagram is actually a set of diagrams that define collections of facts and rules, sources of those facts and rules, specific rules or decision tables used in making decisions and ways to organize the rules for efficient problem solving. In effect, one creates a set of specific diagrams to document the knowledge to be used and how decisions will be defined and managed.

The Decision Management Diagram was initially developed by Barbara von Halle and Larry Goldberg in the early years of this century, and the form described above reflects the standard version of the diagram defined by the OMG's task force.

The Process Management Diagram

The other diagram that plays a key role in the analysis of business processes is the Process Management Diagram. This diagram defines the tasks that a manager of a process should undertake to assure that the process works smoothly. In this case, one usually thinks of the process as being done by employees and one defines how the employees interact with the process manager to assure the smooth functioning of the process. This diagram plays a key role in the initial analysis of process problems – which often result because employees are improperly trained, don't conceptualize their jobs correctly, or aren't given proper feedback and reinforcement for performing correctly. In a similar way, this diagram plays a key role when the team goes to plan the roll-out of the new process, or when one thinks of how the process manager will function once the new process is in place. Way too often, process redesign teams create a new process and roll it out only to find that employees reject it.

Figure 5. A Human Management Diagram.

(This version is modified to reflect its use in the BPTrends Associates classes.)

One often speaks of efforts to deal with rejection as Change Management or Culture Change. In fact, all that boils down to how the manager of a process deals with the employees who will be expected to implement the new process. Everything from communication and job descriptions to monitoring and reinforcement comes into play when one begins to think seriously about how to manage change effectively, and this diagram is the basis for analyzing the effects, and, when appropriate, designing a training program to modify behavior or encourage correct employee performance. (In some cases, of course, the place one begins is with the modification of the existing manager's performance.)

The Process Management Diagram was initially developed by Geary Rummler and Alan Brache in the Eighties and popularized in their 1990 book, Improving Performance.

Summary

There are, as I suggested earlier, many other diagrams one can use in analyzing or redesigning a business process. Different problems will call for different types of diagrams to model different types of problems. I have ignored, for example, diagrams that capture software requirements, or model systems of applications designed to support a given business process. At a high level, much of this information can be captured in a sufficiently detailed BPMN diagram, but there are many other diagrams, like dataflow diagrams, for example, that will be needed by software developers if not business analysts.

In the vast majority of cases, given the types of process redesign work that is being done in most organizations today, the four diagrams are the most important diagrams used by business people who seek to understand and redesign business processes. Knowledge of these diagrams and understanding of their use ought to be in every process analyst's toolkit.

• 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

Latest posts by Paul Harmon (see all)

• Harmon on BPM: A General Management Model - July 4, 2022
• Processes and Capabilities - July 4, 2022
• Harmon on BPM: The Scope of Management - June 6, 2022
• Should Every Manager Be a Process Manager? - June 6, 2022
• Harmon on BPM: Management Processes - May 2, 2022