Harmon on BPM: Defining Problems for Critical Processes

In my December Column, I suggested that there were two key tools that agile process developers needed to know. One is the Stakeholder Diagram – which allows a redesign team to quickly identify the key inputs and outputs that are important to a process and KPIs and Objectives necessary to guide and evaluate a redesign effort. The second tool is the Scope Diagram – a tool that refines our understanding of a process and identifies problems that we might want to alter or improve.

Before considering the use of the Scope Diagram we must determine if (1) we are trying to create a new process, or (2) we are trying to improve an existing process. In the first instance, we can’t use a Scope Diagram, because we don’t have a process to analyze. Instead, we need to pull together a team to conceptualize how we might go about performing a new process. In most cases, however, we have an existing process and simply want to improve it. Agile improvement projects will greatly benefit from using the Scope Diagram.

The Scope Diagram

One begins an agile process analysis effort by assembling a team of people who work on the current process – people who understand the process. The analysis can be done different ways, but I usually do it on a whiteboard so everyone can see what is being done and can easily contribute. One begins by explaining that a process has inputs and outputs. Then one expands on this idea by explaining that processes also use some resources over and over again (eg. Machinery, employees) and are guided or constrained by established procedures, manuals and rules.

We put the name of the process we want to analyze in a box. If it’s a very complex process and there are doubts about what activities might be included or excluded in the process, we write the names of key activities that will be included in the process in the box, under the process name. Otherwise, we ignore what happens within the process, and focus on how the process interacts with its outside environment.

We ask about inputs, outputs, controls or constraints, and about resources that are reused. In each case, we begin by naming the inputs. Then we identify the source of the input. Later, we continue to refine our analysis, we ask if the current input is acceptable. If getting the input, or the nature of the input is somehow a problem, we note that. (In my case I use a convention of red, yellow and green dots to highlight serious problems (red lights), inputs or outputs that might be a problem, and those that clearly are alright (green lights). (See Figure 1)

Figure 1. A Scope Diagram

Figure 1. A Scope Diagram

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 (guides) and one also examines the resources and support activities that enable 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.

A team can spend half a day working on a Scope Diagram. At the end of that time, however, one usually has a good overview of the problems associated with a given process. The problems may involve defective or inadequate inputs or outputs, or they may involve inadequate resources (enablers) or poorly conceived procedures or decision rules (guides). Sometimes they cluster around specific activities, but at other times they are diverse and seemingly random.

Once a team is satisfied that they have identified all of the ways a given process interacts with its environment, and have identified where the problems lie, it’s time to develop some metrics and a plan for improvement.

One looks at each problem one has identified and asks how one would know the problem was solved. Perhaps it’s a matter of being able to say that adequate supplies are arriving on time. Perhaps a solution involves better trained employees, or no rejects of given outputs. One considers each problem and develops a metric, and then one begins to consider the nature of the problem and how one might eliminate it.

In some cases, to better understand the nature of a specific problem, one must develop flow diagrams to determine how activities within the process function. The key thing, however, is that one does not begin with an extensive flow diagramming effort, and, even when one identifies a problem, one confines ones flow analysis to just those activities that explain the specific problem one is focused on. As with all agile efforts, one seeks to stay focused on results and avoid work that slows down the momentum of the process improvement effort.

By using an initial Stakeholder Diagram to quickly define the organization’s objectives and goals for the process, and then using a Scope Diagram to quickly define the problems affecting the process in scope, and the metrics one can use to evaluate one’s effort to improve the process. Equally important, using these two diagrams, one can move through an initial process analysis effort in a matter of days and end with a well-defined list off all the problems. As necessary, your team can rank the problems and set priorities to guide the actual improvement design effort.

Agile isn’t so much a specific activity as it is an attitude. Too many projects get bogged down with large teams and extensive analysis work. We want to move more quickly and rely on a smaller, more compact team. The tools discussed here can make that possible.

Note. To learn a lot more about the development and use of the Scope Diagram, see Harmon’s Business Process Change. The Scope Diagram in its present form was initially created by Roger Burlton, who called it an IGOE diagram and is extensively used by BPTrends Associates in their training classes.

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.info

Speak Your Mind