Process Improvement: Are Process Architectures Useful?

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.

Final Perspective

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.
Alan Ramias

Alan Ramias

Alan Ramias is a Partner of the Performance Design Lab (PDL). He has had twenty-five years of experience in performance improvement and organization effectiveness. Alan was employed by Motorola for ten years as an internal consultant on organizational performance. As a member of the team that founded Motorola University, he was the first person to introduce Geary Rummler's pioneering concepts in process improvement and management to business units within Motorola. Alan advocated and led several of the first groundbreaking projects in process improvement that evolved to the invention of six sigma and Motorola's winning of the first Malcolm Baldrige Award in 1988. Alan was also involved in major restructuring projects at Motorola, and in job design work, compensation planning, workplace literacy, and educational program development. After joining The Rummler-Brache Group in 1991, Alan led major successful performance improvement engagements within Fortune 500 companies. His experience spanned several industries and the full spectrum of corporate functions and processes, such as strategic planning, manufacturing, product development, financial management, and supply chain. Major clients included Shell, Hewlett-Packard, 3M, Citibank, Motorola, Steelcase, Citgo, Hermann Miller, Louisiana-Pacific, and Bank One. After leading many high-profile projects, he became a partner and Managing Director of Consulting Services at RBG. He led development of much of RBG's products and services, and was responsible for selecting, training and mentoring RBG's consultant teams. Upon leaving RBG, Alan founded his own consulting company, where he continued to practice in the field of performance consulting. He was also involved in several organizational restructuring initiatives in the U.S. and in Asia. Alan can be reached at


  1. @Alan,

    We all agree that projects are unique so why would we expect the best way to manage them to not also be unique? I have been a long time advocate that the best approach will be a model that is driven by the characteristics of the project, the organizational environment within which it will be executed and the external market situation. What is needed is a vetted portfolio of tools, templates and processes from which those models can be designed. Finally, the team (including client representation) is empowered to make those decisions.


  2. Hello, Happy New Year.
    9% of firms and work sites, have one Entreprise Process…
    New ISO 9001 and 9101 don’t request Process Map…
    100% of companies become prospects…

  3. Alan, I really enjoyed your review of your own development and I think we have reached very similar conclusions. As you suggest,there are certainly times when a process archiecture is very useful, It’s often useful to develop one in the context of a specific project. What I find worrying is the tendency to set up groups that seek to create and maintain a process architecture, as if if were an end in itself. Paul

  4. Kai Laamanen says:

    Thank you Alan for your review on your personal trip on process architecture. My reflection on this is, that for me the process architecture may involve some other aspects than mapping the processes. We may need to consider, how do we map the processes (I know roughly 20 different ways to model processes), do we only make graphical presentations or should we also describe customer needs or other stakeholder needs, or how about performance metrics such as leading vs. lagging, or how do we deal with the issue of process ownership. We might also have in our mind network of processes (only one level) or hierarchical set up of sub processes (several levels). We may talk about business processes, service processes or work flow (processes)… are we talking about same thing or different one?… Br Kai

    • Alan Ramias says:

      I agree with you that developing and using a process architecture can and probably should involve more than just mapping the processes. In that company I described at the end of my article, they did delve into things like process ownership, process performance measurement, process hierarchies and job/role overlays. The reason they got so much value out of having the architecture was because they used it as a focal point for the many things they had to address during their organization redesign.

Speak Your Mind