Top-Down BPM and Architecture

There are different approaches to Business Process Management.  As a broad generalization, Six Sigma and IT process practitioners tend to take a bottom-up approach.  That is, they begin by focusing on a specific problem – usually a fairly limited problem, and proceed to redesign it.  If they are asked how the specific problem they are working on links to corporate strategy, they have to struggle to show the linkage.

To highlight this, I developed Figure 1 when I was working with a BPMS vendor.  The vendor showed me a BPMS application that they had developed for use in a class to teach people about the use of their software product, and asked how their training might compare with the BPM training that BPTrends Associates offered.

Figure 1. From a Value Chain to a Level 4-5 process model.

After struggling with this question for a few minutes, I created Figure 1 – and tried to work out the relationship between the specific process the BPMS vendors was working on – the large box at the bottom of Figure 1 — and a value chain that might contain that specific sub-process.  The value chain is pictured at the top of the stack, in an organization diagram — highlighted in yellow.  I estimated that the overall process was a level 4 process and that the specific activities that made up the process were level 5 processes.  (This approach uses the labeling approach we adopted from SCOR where a value chain is level 0, and the major processes that make up the value chain are termed Level 1 processes.)

I explained to the BPMS vendor that our process training taught students to define the organization and its goals, and then define the value chains contained within the organization, showing which goals each value chain sought to accomplish.  After than we defined the Level 1 processes included within whatever value chain we decided to focus on, and proceeded on down.  In most cases we focus on redesigning Level 1 or Level 2 processes, and rarely get down to Level 4 processes.  The key thing, however, is that we begin with a top-level overview, not a specific, low level process.  Starting at the bottom can work if you are trying to improve or automate a specific set of low level activities, but if you start there, its very hard to work upwards to tie the specific low-level process to the goals and KPIs  of the organization.

I was reminded of all this when I read the following comment posted to a discussion about business architectures:

“There is no overall model of business with which to frame and connect processes. As the CIO of Chevron once said, they had mapped all their processes but the result could be likened to a plate of spaghetti.”

The author of this comment seemed to suggest that this was a weakness of today’s business architecture efforts.

I can easily imagine, with a large corporation like Chevron, that a diagram that pictured level 3 or 4 processes would indeed look like a plate of spaghetti.  The question, of course, is why one would ever create such a diagram, let alone show it to the CIO, or any other senior executive.

BPTrends Associates has been doing quite a bit of work with organizations, helping them to develop business architectures, and I think it’s fair to say that we have had quite a bit of success.  We routinely develop organization diagrams that we show to CEOs and they find them useful, and indeed, they often join in our discussions to help us refine our models.  Figure 2, for example, pictures an organization diagram that we might show a CEO.

Figure 2.  Organization diagram showing two value chains.

At this level we are only concerned with identifying the value chains in the organization and the customers they target.   In effect we are describing the organization as a system that produces certain outcomes and tracing the major entities necessary to assure that the system works.   Once we sort out the value chains, we focus on a specific value chain and define stakeholders, as pictured in the Stakeholder Diagram in Figure 3.

Figure 3.  A Value Chain with Level 1 Processes linked to Key Stakeholders.

Notice that customers are one important stakeholder, but there are others that are also important.  For each major stakeholder-value chain relationship we define, we go on to define the process that supports that stakeholder.  We also define what the stakeholder expects from the value chain.  These expectations, in term, translate into measures that we will use to evaluate the value chain, and to later evaluate the effectiveness of any changes we make.  Management values ROI on capital.  Customers value quality of product and good service, while employees value career opportunities, and so forth.

I could continue to describe how BPTrends teaches business process architects to drill down into a value chain and to elaborate the processes that make up it up, but this is not the place for that.  Suffice to say that diagrams I have shown require discussion and decisions that senior managers can engage in and don’t lead to their thinking it’s all too confusing to understand.

A business process architecture, as I understand the term, and have used it for the past twenty years, provides management with a high level tool to help pinpoint problems when performance isn’t as it should be.  It helps everyone understand key relationships, and how activities within the organization tie to external stakeholders, be they stockholders, customers, regulators, or employees.  A well-done architecture is something that senior executives can use in developing and evolving strategy and should be intimately tied to defining and validating key performance measures.

These are not new ideas.  Much that I have described was initially defined by Geary Rummler in the Eighties, and it has been used by those working in that tradition ever since.

I’m sorry that the Chevron people didn’t provide their CIO with a better overview of the organization and a better architecture – if in fact they didn’t – but it wasn’t for lack of there being a well-defined approach that could have delivered these artifacts.