Reference Models: The Long, Long Shortcut

Download PDF

BPTrends, March 2012

Authors: Alan Ramias, Cherie Wilkins

Business process reference models are one of the most popular tools in the arsenals of those doing process definition. Deriving from tools for defining and_ designing information systems, some 30 reference models for business processes now exist*, including such well-known ones as SCOR, V-COR, ITIL, TOGAF, and e-TOM. The notion of a reference model appears to make practical sense: Instead of starting from a blank sheet of paper, why not get a head start by borrowing from a generic model instead? It is a complicated task to identify, sort, categorize and organize a business process architecture, especially for people who have not done it before, and having a framework to assist with the task is most welcome.

There seem to be three types of reference models. One type describes “best practices” for a specific domain or area of expertise—ITIL is an example of this type. A second type describes the structure of a business process architecture—SCOR is an example of this. The third type aims at defining the design of a software system. The first two types are used for business processes; the third is not necessarily applied directly to business processes but sometimes is.

We have no objection to the concept of a reference model as long as it proves useful, and for many practitioners, reviewing a reference model while defining their processes is a helpful aid to their thinking. In fact, when we define a business process architecture for a client, we use our own framework, which could be viewed as a reference model of sorts. We always start by identifying and categorizing the core business processes as belonging in three buckets: processes that create and launch products or services; processes that market and sell products or services; and processes that deliver and support products or services. This simple structure applies at least roughly to most any organization, even those in non-profit and government arenas, and it does give us a head start in identifying, categorizing and naming the processes of an enterprise.

But as we have watched a good number of clients attempt to use reference models, we have noticed the same difficulties arising again and again—often enough to make us question whether this shortcut is always as helpful as it ought to be. So in this article we will share the problems we have seen in adopting and using reference models and offer some advice for avoiding these pitfalls. We will sort the problems into two types:

Some of the problems described below have to do with the design and content of various reference models that are most popular with process practitioners, enterprise architects and system developers. (We will not name names—this is not meant as an attack on any particular reference models or any sources that provide reference models. If you already use the ones we describe, you will likely recognize the ones we talk about; and if you encounter any of these models in the future, you will probably be able to recognize them from our descriptions.) Other problems stem from the practices of those who attempt to apply reference models and not necessarily with anything deficient in the models themselves.

The Functional Trap

A division of a large utility company had been working at some process improvements as a result of a major, multi-year transformation initiative. The process changes were still being implemented when it was recognized that process management would be needed to sustain the improvements. Several management teams were already doing some process architecture definition work as a way of clarifying roles and responsibilities after several reorganization efforts. To support and coordinate all these initiatives, a process center of excellence was established. The new manager of the center did not want more than one approach for process definition in the company, so she reached out to EA and other process groups in the company, and together they decided to adopt a utility industry architecture.

But once the manager got her hands on the actual utility reference model, she realized that the “processes” were actually all functionally bounded. None were cross-functional, which contradicted her experience that the important processes of an organization are cross-functional. She and her cohorts also realized that one of their main objectives in defining a process architecture for the company—to help managers manage processes across functional boundaries—would not be helped by an architecture designed like this one.

You might think that perhaps this is an isolated case, but examine for yourself some of the reference models commercially available and you will find this flaw in several of them.

The Irrelevance Trap

As another company embarked on a process management journey, EA identified several process models that were respected as “best practice” and—with the goal of engaging and pleasing several constituencies—they put together a composite reference model. The model was promoted within the company as the key tool for assigning process owners and initiating process improvement and management.

One of two business lines did make an effort to adopt and upgrade the model. The other business line had no interest. And at corporate level, the model was dismissed because it was viewed as unrepresentative of the entire organization. As a result, the model has never been institutionalized and is utilized only inside EA.

The Semantics Trap

Inside an IT shop, a major effort was started to adopt a “best practices” reference model that would help guide both IT and the client organizations it serviced. The effort was begun with great enthusiasm but began to stall when problems with terminology surfaced. Such innocuous terms as “services,” processes,” “outputs”, even “features” were sometimes used interchangeably and debated endlessly, causing widespread confusion and growing frustration. What became increasingly obscure was the actual purpose of the effort—was it to determine the “right” or “correct” way to define a service or to establish something useful to support real work?

Also arising during this effort was a conflict between IT and its business partners. Because the contents of this reference model were labeled as “best practices,” to some team members this meant the model had to be adopted wholesale, while others from the business side kept inquiring about how the model connected to customer needs. What the team was trying to do with the model became itself a cause for debilitating debate, until the effort fell apart.

 

The Absolutism Trap

A similar burnout happened in another organization where we were involved in defining a new line of business for a company. One of the steps was to create a business process architecture, so a decision was made to adopt an existing reference model from an industry similar to this new business line. All fine and good if the model had been employed for its intended purpose—as a reference tool—but instead, a number of the team members (not surprisingly, those who had suggested this particular reference model in the first place) insisted that it be adopted exactly as is—with no changes in structure or terminology. Why? We suspect they hoped that the reference model would be a shortcut. They did not have the stomach for debating and deciding exactly what to use from the model and what to discard or replace with better terms from the company’s own lingo. Easier to be fanatical about it. Of course this did not go well with the more practical members of the team and the effort collapsed as a result.

The Generic Trap

If a company adopts an industry-specific reference model, you would hope that the model is in fact specific to that industry. But don’t count on it. The utility industry model described earlier not only was functionally oriented, it was largely generic. Some 90 percent of the processes identified in the reference model could apply to virtually any industry. That would be okay if you knew you were buying a generic model but not if you paid for one that is tailored to an industry— or why bother? Yet a number of the so-called industry-specific reference models are anything but specific. Check some of them out for yourself.

A Few Principles to Consider

If these tales of woe have not utterly dissuaded you from reference models, there are a few notions for making them useful. We describe these principles below, followed by an example of a company where reference models were effectively used as a result of following these principles.

1. Uniqueness is more important than sameness

Reference models are based on the supposition that organizations share things in common. They all have some structural similarities, they all have some general categories of things (for example, you can find management processes, core value-creating processes, and supporting processes in any organization). Of course, this is true, which does make it possible to create generic models that can be of some use in any company, and industry-oriented models that can be generally accurate for any company in a given industry.

But that’s as far as it goes. What is more important about a given company is not what makes it like any other company but what makes it different. Competitive advantage lies in how a company might design and execute its marketing and sales processes, or how it manufactures its products more efficiently than anyone else, or how much better it is at pleasing and keeping key customers. So a major reason for creating a business process architecture is to identify an organization’s unique, value-adding, competitive differences and using process management to institutionalize those advantages.

What we have found is that the highest levels of a reference model are reasonably accurate for describing a given company’s business process architecture, but as you go down into the details of specific sub-systems and processes, things are quite different from one company to another. A generic reference model applied literally to a company could cause you to miss this insight.

2. Adaptation, not adoption, is the goal

Reference models are supposed to be useful tools—adjuncts to the task of defining an organization’s architecture—not the Holy of Holies. The structure and contents of a reference model should be borrowed, twisted, reshaped, replaced, rethought, not adopted as some talisman to discourage thinking. The creators of most reference models will all tell you as much. They don’t regard their own work as perfect, so why should their users?

3. Don’t forget your purpose

In the inevitable debate and confusion over terminology and whether some part of a reference model should be used, changed or discarded, what is most helpful in guiding the decisions is a point of reference that everyone can agree on. In our experience this has always been to consider the views of the customer. If the organization creating a process architecture is a staff group like EA, its customers are the business, and if the architecture is for the entire company, the external customers are the focus. Once we can agree that we are doing this ultimately to better serve customers, we can ask whenever disagreement arises what it would matter to the customer, what terminology would make sense to the customer, what level of detail would the customer want to see. And of course answering these questions happens most readily when you make your customers part of the team that is doing this definition work.

A Positive Example

This is a company that embarked on a series of process management efforts over some five years. Along the way they paid for development of several customer process architecture models and attempted to use proprietary industry models, but in every case there were fundamentals about the business that were missed. The most recent effort was an attempt by Corporate EA to create a high-level business process architecture in the form of “capability maps” but this too ignored much of the structure of the business. What then ensued was an agreement across several departments, including EA and a BPM groups inside R&D, to develop a multi-level custom business process architecture that would identify and be organized around well-established business milestones. Key to the effort was including two executives along with several BPM business SME”s and senior project managers. We began with the process best understood and already somewhat defined: the product development process. With that as a base, we had the team identify the milestone achieved at each stage gate, and then we identified and named upstream and downstream milestones Guiding the choice of what to include in the architecture was the significance of a process to the business strategy. Over two months, the team met regularly to hammer out a process architecture that when finished triggered the following reactions:

  • “You have captured the business on three sheets of paper.” (comment from the executives)
  • “This satisfies our modeling needs.” (Corporate EA)
  • “This is much better [than previous models] because it’s based on our business, not just our industry, and how our leaders think of it.” (R&D BPM)

So reference models can be useful, can be adapted to your organization, can provide content and structure for your business process architecture, and can be valuable to the many different departments that need an architecture to guide them—but don’t hold out hope for a shortcut. It takes hard work, participation from business leaders, a practical attitude, and a clear focus on purpose. Fanatics not welcome.

 

*Business Process Reference Models, Ekkart Kindler, Markus N¨uttgens (eds.), Proceedings of the Workshop  on Business Process Reference Models (BPRM 2005), Satellite workshop of the Third International Conference on  Business Process Management (BPM), Nancy, France, September 5, 2005