If you read some of the Columns and Articles on BPTrends, or on any of the other popular “BPM websites or blogs” you get the impression that process architecture is the hot thing at the moment. In fact, in some surveys, process practitioners say that they are very interested in the topic. This past month, however, we have asked BPTrends readers to tell us what percent of their processes were well documented, modeled and routinely measured – what we take to be the outcome of a good process architecture effort. The leading response was 10%, closely followed by 25%.
Companies have been talking about actively talking about business processes since Michael Hammer and James Champy published Reengineering the Corporation in 1993. After 25 years, you might have expected that a lot more companies would have defined their business processes! The fact that they haven't suggests one of two things. Either (1) they don't really care much about processes, or (2) they are too focused on a few processes and don't have the time or interest in moving beyond the few they are focused on. Polls throughout the Zeros routinely suggested that the number one concern of large numbers of CEOs and CIOs were business processes. To us, that suggests that companies are interested in processes, but have actually only focused on a few processes.
This makes good sense to us. Large companies have anywhere from one to ten value chains, and dozens of major processes. Analyzing all of them would be a major effort. At any given time, however, a large organization is focused on a few key issues — responding to a major government or industry initiative, responding to a major shift in technology, or to a seminal shift in customer concerns, or dealing with a recession that is causing chaos in their industry or in a major market. It would be nice to be able to say that concerns like these have been rare, but in fact that have come with relentless certainty during the past decades as we've endured globalization, outsourcing, the euro, the Internet and the web, smartphones, on-line sales and purchases, the rise of China and various economic crises and political upsets. The number of Fortune 500 companies that have failed or been acquired in the past three decades is staggering and underlines the toll these relentless changes have taken.
Given the pace of change, it's hard to imagine any organization having the time and leisure to calmly think about all its business processes and to deploy teams to systematically review and catalog their various processes and activities. Most companies, have, instead, remained focused on their key processes – redefining them to deal with major changes – changing them to accommodate new technologies or new markets – and then redefining them again to deal with still other major changes.
Most organizations don't need methodologies to help them define all their processes – they need a methodology to help them redesign key business processes – quickly and efficiently. Moreover, given the focus on making changes quickly, I tend to term a redesign approach that helps a business define and make changes quickly, an agile process redesign methodology.
Two Key Tools
Over the past decade, two tools have impressed me as particularly appropriate for this effort. One is a simple diagram that helps identify stakeholders and their needs. The second is a diagram to identify the overall scope of the change required and to pinpoint the major opportunities available to improve processes. In my opinion, architecture diagrams of various kinds, and even flow diagrams pale by comparison.
In this Column I'll focus on diagrams to identify stakeholders and their needs. In the next Column, I'll consider the type of scope diagrams that extend the scope diagram and helps with the identification of problems.
Stakeholder Diagrams
Most process redesign methodologies spend too much time talking about architecture, corporate goals, strategies, and initiatives. These are all important issues, but if they are treated as separate concerns, they tend to cause more confusion than provide focus. What's needed is a simple diagram that allows us to pull together all the information we need in a manner that is clearly focused on the process that we need to redesign.
The place to begin is with a process to be improved – probably a large-scale process that needs to be changed because of a shift in technology, customer interests or a government initiative. We'll keep our example simple, however, and consider a copy center. Their major business process is termed Make Copies and it includes everything involved from when the customer requests copies to when the copies are delivered to the customer. An overview of this major process is provided in Figure 1.
Figure 1. Make Copies process
Now we'll modify the basic Make Copies process diagram to generate a Stakeholder Diagram by replacing the input and output arrows with the names of various Stakeholders and arrows to show what flows occur between the process and the stakeholders. As we are using the term, a stakeholder is anyone outside the process who has an interest in the success or failure of the Make Copies process.
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
The relationship between the customer and the Make Copies is easily understood. The customer generates an order, provides money and specifications, receives the copies, and, hopefully, is happy with the result.
The relationship between the customer and management is a bit more complicated. Here's where strategy, goals and initiatives come into play. Management sets goals for the process, they provide policies and financial resources that constrain the activities of those engaged in the Make Copies process. They may mandate changes in the technologies being employed. In a nutshell, all the information that more complex process methodologies might seek by other means can be quickly captured on a simple diagram like the one in Figure 2 by simply noting how management constrains and what management expects from the process. Management is a stakeholder with expectations and this diagram should allow the organization to make that information explicit.
If the Make Copies process was a value chain process 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 copy shop. 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 with which management was concerned.
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
With a little work, a business team can usually define a process and then generate a complete 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 its 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
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, 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.
As we indicated earlier, many methodologies use a variety of diagrams and worksheets to define an organization's goals and initiates. Others get lost in discussions of process outcomes for customers and how they square with management concerns for things like ROI or staying within budget. The Stakeholder Diagram captures all this in a single diagram and an accompanying worksheet.
If you are trying to do an agile process redesign, you need a tool like this – something simple that captures a lot of information in one place and highlights potential buyoffs. The Stakeholder Diagram is the place to begin your Agile Process Redesign effort.
Paul Harmon
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
Speak Your Mind