There is an interesting debate going on about the value of process architectures on the BP Trends discussion forum in LinkedIn. Paul Harmon initiated the discussion by saying while it is useful during a process improvement effort to map out the value chain in which the target process resides, it is a waste of time to diagram the whole architecture. The discussion got me thinking about my own experience with process architectures and how my opinion about the value of such an exercise has changed several times.
Perspective 1: Why Bother?
When I worked at the Rummler-Brache Group (RBG) in the 1990's, we did not advocate developing a process architecture for our clients. Our work most often centered on redesign of a major end-to-end process such as order fulfillment, manufacturing or new product development. During the project definition phase of a given project we did use a tool called a “process relationship map” (PRM), shown in Figure 1, which identified the target process (the one to be improved) and other processes connected to it. The purpose of the PRM was to scope the project properly by asking whether any of the processes related to the target process should be included in the improvement effort. But the intention was never to map out all of the organization's processes (unless the company was so small it only had one core process and a few supporting ones).
We saw little need for having a big picture view of all the processes, for the reasons Paul Harmon cites—too much work, too abstract, too little practical use, too difficult to maintain.
Perspective 2: Outcomes Instead of Outputs
By the mid-nineties, the scope of work at RBG had begun to change. No longer were we always redesigning single processes. Often we were dealing with all the processes related to some major issue or outcome, such as safety, mechanical integrity, risk management, profitability. Now we were dealing with multiple processes that often crossed multiple boundaries inside an organization. We needed some way to identify and depict the network of relevant processes. Fortunately, the PRM lent itself nicely to creating such pictures so we expanded its use to what we decided to call an “OSIP”—an Organizational System Improvement Project.
So gradually we were creating process architecture models—but with two limitations. The architectures we built were focused on a set of processes related to some major outcome but were not attempts to create a complete picture of all the processes in the organization, given it was a large one. And the architectures were created in service to an improvement effort, not built just for the sake of having a process architecture.
Perspective 3: Services Instead of Products
My view of process architecture evolved again when I left RBG in 1999 and struck out on my own for several years. I did some work for a bank that had purchased another bank that while smaller was more successful with customers, especially in its credit card operations. I was asked to map out the same processes of each bank and compare them to identify differences in practices. I simply interviewed employees in each bank, asked them to describe their work and then mapped out the processes one after another. Altogether I created maps of 57 processes. Along the way I had several realizations:
The RBG approach to process modeling was created while working in manufacturing companies, where there was one long sequential process (i.e., manufacturing) and everything else was subordinate to it. This was what we came to call the “core” process, and a map of it might be 50 or 100 steps long. In contrast, many service organizations consist of an “array” of little processes, not one big one. (In the credit card operations, there were a myriad of small processes for things like raising the credit limit on a card, ordering a second card, inquiring about a problem, changing an address, etc.). Such processes might only be three or four steps long.
A process architecture would have been awfully useful to have, instead of simply discovering all these processes through interviews as I had done. Some of you might be suspecting many of these 57 processes were not bonafide processes at all but sub-processes inside larger ones, and that is a fair point. An architecture view would have helped clarify such relationships.
The architecture also helped challenge the thinking of the managers who had to blend the two credit card operations. Not only did they have to identify the best practices of each organization but they also could see opportunities for simplification and clarification that they hadn't had earlier.
Perspective 4: It's a Hierarchy
In 2005 I joined Performance Design Lab, the company Geary Rummler founded after he sold off RBG. We compared notes about what we had each learned in the intervening six years and found out we had arrived at some of the same conclusions, namely that:
- The opportunity, and proper scope, of process work was no longer at the single process level but instead was at the very least multiple processes and even possibly an organization's entire process architecture;
- Modeling of an organization's process architecture was a valuable endeavor after all;
- Many more people were knowledgeable about processes but also very confused about them.
To assist with that last point, PDL had developed a hierarchy (Figure 2) that depicts an organization that can be modeled at multiple levels, starting with the entire enterprise at Level 1, the value chain for a given line of business at Level 2, the networks of related processes (called “processing sub-systems”) at Level 3, the single processes at Level 4, and the performer, sub-processes and enabling technologies at Level 5. This hierarchy gave us a language for helping clients figure out what they meant (that is, what level) when they talked about their processes, for identifying at what level improvements needed to be aimed, for figuring out how process management should overlay the processes—in short, it was the ideal tool for moving away from a single process perspective to an architecture perspective.
This hierarchical view also helped us understand that what we were doing at RBG with OSIP projects was addressing Level 3 (processing sub-systems), and projects at that level had much more impact than single-process improvement efforts.
We then decided to offer process architecture creation as one of our service offerings. And we got a lot of it. By the mid to late-2000's, many companies had gotten the message about process and believed having a view of their important processes was vital to becoming “process-centered” (or whatever they termed their objective regarding process).
Sad to say, though, the experience I gained in created a lot of process architectures gradually moved me to doubt the value of doing it. Much like Paul Harmon, I often saw wasted effort, arguments, stalled attempts, fingerpointing and other unfortunate behavior as well as issues with storage and upkeep even when the architecture creation work went okay. What often made things worse was the growing popularity of process reference frameworks (ITIL, e-TOM, and the like). These pre-packaged architectures were meant to make the identification of one's processes easier but all too often they triggered bickering over terminology and unrealistic expectations that the framework was a shortcut to understanding one's own processes.
So I became cynical about the value of process architectures even though when teaching classes I continued to promulgate the concept and its value. At least in theory it still made sense.
And then I had an experience that turned my opinion around once more. I did a project for a large company that in addition to its core product businesses had been selling its technical knowhow as a consulting service. For the course of several years the consulting services efforts were surprisingly successful, growing faster than anyone expected. For that reason, there was not much planning or central control, so each region of the world developed its own practices. But gradually large multinational customers demanded uniformity in the services it bought, and top management itself began preaching the value of a unified company instead of fiefdoms.
The project was to redesign the technical consulting business so that it would be practiced consistently worldwide. Early on, as I struggled to understand the scope of what would have to change to realize this goal, I decided (despite my private doubts) that a process architecture might be useful. Using a pile of existing process maps from the multiple organizations involved in the consulting work, I created a makeshift process architecture and used it in the kickoff meeting to orient the design team (consisting of people from all over the world) to the scale and scope of our endeavor. I encouraged the participants to review the architecture and mark it up to reflect their own views, and then I collected their work.
That little activity turned out to be the most valuable thing we did during the workshop. A sub-team was charged with completing the architecture and as they met over the course of months and refined the model little by little, the architecture became the basis for organizing how they went about redesigning that Frankenstein organization and even more for managing it once the changes were implemented. For the process practitioners, the architecture became their language for helping line employees to understand the transformation and to engage in it.
So I came away with a renewed respect for the usefulness of a process architecture and better understanding of how to apply it. But there are still some rules of thumb:
- Don't create a process architecture just because you think you're supposed to have one. Its usefulness is most evident when applied for making a change. The larger and more complex the change, the more insight an architecture might give you.
- Consider the model to be “throw-away” work once the project is done, unless you are really going to put effort and resources into maintaining it as part of a process library.
- Service organizations might benefit greatly from a process architecture perspective, in helping them to define and understand all of the work they do.
- The greatest opportunity for process improvement is not at the single process level but at the level of multiple processes, where interactions between processes and participating organizations tend to be poorly understood and managed.