Harmon on BPM: KPIs and Stakeholders

If there is a missing piece in most process redesign projects, it's a clear and comprehensive set of performance measures. In many cases the redesign team focuses on analysis and seems to ignore the definition of good measures. In other cases the team comes up with a mixed bag of measures, some derived from organizational strategic concerns, some from current organizational initiatives, some from an analysis of customer concerns and some from the internal workings of the process itself. Popular books on performance measures aren't always helpful, since they often reflect the same confusion or they focus only on one subset of measures. One book, for example will describe how to derive and align performance measures with organizational strategic concerns. Another book will describe the vital role of analyzing customer needs when defining performance measures. I have known a number of process teams that focused on customer objectives only to find that management was much more interest in the ROI of the new process.

In this Column I'd like to briefly describe the approach to performance measures that is used in the BPTrends Process Redesign Methodology. The approach represents a comprehensive approach designed to derive a balanced set of measures.

The first step, as you might imagine, given that it's a process-oriented approach, is to define the business process you are concerned with. Graphically, we present the resulting definition by drawing a process box and labeling it. We also show the input that initiates the process and the output that concludes it. Thus, for example, we might be concerned with a photocopying business, and specifically with a business process that makes copies for customers. The process begins when a customer requests copies and presents a manuscript to be copied. It ends when the customer has paid and original manuscript and the finished copies are presented to the customer. We always name processes with a combination of a verb and a noun, and emphasize the outcome, thus, we term this process “Make Copies.” (See Figure 1)

Figure 1.  Make Copies process.

Figure 1. Make Copies process.

Once we have defined the process we are going to focus on, we next ask about the stakeholders of the process. In this case, a stakeholder is anyone who cares whether the process succeeds or fails. One obvious stakeholder is the customer, who depends on the process to achieve some goal. In the case of the Make Copies process, the customer needs copies and depends on the process to prepare those copies. Another key stakeholder is the management of the copy store. They depend on the process to generate the income that the store was established to generate. To keep track of the stakeholders of a given process we often create a diagram that pictures the process and shows stakeholders and what they derive from the given process. Figure 2 pictures the Make Copies process with two stakeholders.

Figure 2.  Make Copies Stakeholder diagram

Figure 2. Make Copies Stakeholder diagram

It's in the nature of process work that processes can be very large and comprehensive sets of activities – as, for example, a value chain that flows across multiple departments and produces a major line of products or services – or something rather small and mundane – as a process that resided many levels down in an auto production process would be. Stakeholders concerns vary, depending on the nature and location of a given process. Thus, if the Make Copies process was a value chain that produced the main product of a photocopying store, management would be very concerned with the ROI (Return on Investment) of the process. If, on the other hand, there was a copying process located several layers down within a value chain designed to produce and sell life insurance policies, management might not care much about the process, simply regarding it as a utility. Similarly, the customer for the photocopy store's Make Copies value chain would be the primary customers of the organization, while the customer for the copying process buried within a life insurance sales process might simply be another rather modest process. None of this changes how one develops performance measures for processes, but it reminds us that the interface concerns for “Management” and “Customer” can vary quite a bit, depending on the process we are describing.

Let's return to our copies example, and to management's concerns. In the case we are looking at, the process is a value chain for a small copyshop. Thus, the management of the organization might well have a strategy, and the management team might well adopt a set of initiatives, depending on their goals and the nature of the market. Thus, for example, the management team might have an initiative to reduce costs by 10%. Similarly, they might have an initiative to comply with some new tax regulation that required a new type of report on employee earnings each quarter. In effect, both of these concerns would be incorporated into our diagram as things management was concerned with.

Figure 3.  Stakeholder diagram incorporating management initiatives and goals.

Figure 3. Stakeholder diagram incorporating management initiatives and goals.

Let's consider some other possible stakeholders. Common stakeholders include business partners who supply or receive outputs from the process, government agencies that receive reports on income from the process (sometimes stated as independent stakeholders if the process generates the payment, but otherwise added as a management concern), and employees. The copy shop, for example, may use an outside company to clean its premises at night, it may lease equipment from a copy machine manufacturer and expect that manufacturer to provide services and so forth. The copy shop may think its employees are easy to replace and may not place a high premium on retaining them. Although, in fact, if they are concerned with reducing costs, then retaining employees rather than going to the expense of hiring and training new employees is probably important to the copy store. A software game company that competes for key employees, however, might think about the matter very differently, and be very concerned with the happiness of its game designers.

Figure 4.  Make Copies with More Stakeholders Shown

Figure 4. Make Copies with More Stakeholders Shown

With a little work, a business team can usually define a process and then generate a good list of important interactions. Once one has done this, defining Key Performance Indicators (KPIs) follows naturally. One knows a process is successful if it satisfies it stakeholders. The list of things that are required to satisfy stakeholders can easily be converted into a set of measures that one can use to evaluate the success of a process.

There is also some confusion about how one uses terms. Most process people use the term “key performance indicator” to indicate a rather vague goal. In that case they usually associate KPI's with specific “objectives” which they quantify, specifying the item to be measured, the appropriate target, and a time criterion. Thus, one of the customers KPIs might be “copies delivered when promised.” We could then translate this into the objective “95% of orders ready at the time promised.” Similarly, a management KPI might be to “Meet cost reduction goals,” while the objective might be “Reduce costs by 10% by the end of the 1st quarter.”

Figure 5. Portion of a Process Performance Measures Worksheet

Figure 5. Portion of a Process Performance Measures Worksheet

When BPTrends trains new process teams, we teach the teams to define the process they are going to focus on, and then to create a Stakeholder Diagram for the process. Once the diagram is complete, we go on to develop a worksheet. In essence, the team lists each stakeholder, the key concerns of each stakeholder, and then creates formal KPIs and Objectives for each stakeholder concern.

One might object at this point that we have only considered “external” measures, and not considered “internal” measures – as for example how many hours employees worked, or the waste generated by specific subprocesses. If one was really focused on reducing costs, for example, one would probably want to measure several “internal” measures. Our response is that, at this point, we are only focused on external measures. External measures tell you what the process is accomplishing. They are the only sound basis for KPIs. At the same time, however, if you want to improve a process, or even manage it effectively, you will probably need a number of internal measures that correlate with the external measures or at least give you a good idea of the likelihood of achieving the external measures. Deriving internal measures from external measures is a separate process that depends on an analysis of the internal structure of the process, and which won't be discussed here for lack of time and space. Our goal here has been to assure that we have a complete set of external measures to use in monitoring the performance of a given process.

The development of the Stakeholder Diagram assures that the process team has a clear set of goals for the process redesign effort. Moreover, done as we have suggested, with an equal emphasis on Customers, Management and other key stakeholders, it generates a complete list of measures for a process. It also provides the foundation for the derivation of more precise internal measures that are used when one tries to improve a process.

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.