Process Types

One of the major events in the evolution of modern process thinking was the 1985 publication of Michael Porter’s book, Competitive Advantage, which introduced the idea of the Value Chain.
A Value Chain describes all of the activities that an organization undertakes to satisfy a customer value proposition.

One key idea to come out of the Value Chain model, is the difference between core processes, and support processes. (here).
Today, it is popular to divide support processes between processes that directly support the core processes and more generic management processes that plan, organize, communicate, monitor and control the activities of the organization. Support processes are sometimes called enabling processes (here).

To model or not to model?
The question that confronts every team that tries to model a process is how much to model. In particular, should you model management and support processes? We  suggest that, in general, you should not. It’s acceptable to include some support  processes in a high level diagram just to suggest important things that must happen  to assure the core process succeeds.


The key to an enterprise-wide business process architecture is a good description of all of the core processes the organization supports. They may all lie within a single Value Chain, or in more than one, but the core processes in each Value Chain are linked from certain initial events to the delivery of products and services to the ultimate external customer.
Different methodologists take different approaches to dealing with support processes in diagrams. BPTrends Associates uses an approach very similar to the approach developed and used in the Supply Chain Council’s SCOR and the Value-Chain Group’s Value Reference Model. We model the core processes, and then, when we are ready to focus on support processes, we model them only as they touch any one of the specific core processes.

Support processes are just as important to the success of the organization as core processes. The inability to hire key employees or the failure to properly account to government agencies can result in bankruptcy just as not satisfying customer needs can lead to failure. Often, however, there is no flow among the support processes that approximates the logical flow we observe in the core processes.


We model the core processes, and then, when we are ready to focus on support processes, we model them only as they touch any one of the specific core processes.

If one takes this approach, one can begin with a core process diagram which shows the relationships between each core process and then move on to a number of more specific diagrams that show the relationships that exist between each core process and all of the management and support processes, of a similar granularity.


Much of the confusion about process modeling and process architectures would be eliminated if everyone kept the distinction between core and support processes clearly in mind and avoided the temptation to try to capture too much in a single diagram.(again)


Geary Rummler has always maintained that you need to model the management of processes at the same time that you manage the execution of the process. (See Geary Rummler and Alan Brache, Improving Performance, Jossey-Bass, 1990, or Geary Rummler, Serious Performance Consulting, ISPI Press, 2004.)

Thus, looking at a  specific activity, like Route Shipments, Dr. Rummler would propose that we think of a  manager and managerial processes that control the Route Shipments process (here)