The Difficult Process of Identifying Processes

Why it Isn't as Easy as Everyone Makes it Sound

©  Fred Nickols 2012

This paper appears in John Wiley & Son's Knowledge and Process Management (Vol. 5, No. 1)

Why is it so difficult?

In conversation after conversation with people who are attempting to identify their company’s business processes, usually for the subsequent purpose of improving the performance of these processes, all agree that it is an extraordinarily difficult undertaking. What’s going on here? Why are efforts to identify and map an organization’s processes so fraught with difficulty and what can be done about it?

The quick answer is that definitions don’t define, names don’t identify, examples aren’t exemplary, and an organization’s processes are essentially unknowns (but, thank goodness, not unknowable).

This brief paper is an attempt to make clearer the meaning of process as it is used in terms such as "business process," "business process improvement," "continuous process improvement," "business process reengineering," and many more. The ultimate objective is to help make the task of identifying business processes simpler, easier, and more successful.

Definitions abound, words fail, and meaning eludes us

Definitions of "process" confront us almost everywhere we look.

Dictionaries list several definitions of process, both as noun and verb. As a noun, one of the dictionaries I own defines process as "a particular method of doing something, generally involving a number of steps or operations." [ From Webster’s New World Dictionary of the American Language , Second College Edition 1978.]

In the management literature the term "process" is frequently defined as a set of related activities. This basic definition often carries with it elaborating text referring to outputs, value, and customers.

Following are some definitions of process drawn from recent works by four of the experts regarding business processes.

• Thomas Davenport, in Process Innovation:

". . . a structured, measured set of activities designed to produce a specified output for a particular customer or market."

• Michael Hammer and James Champy, in Reengineering the Corporation:

". . . a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer."

• James Harrington, in Business Process Improvement:

"Any activity or group of activities that takes an input, adds value to it, and provides an output to an internal or external customer."

• Joseph M. Juran, in Juran on Planning for Quality:

". . . a systematic series of actions directed to the achievement of a goal."

The definitions of process just given could just as easily apply to activities wearing the labels function, task, step, or operation. Indeed, if you accept the notion that a process is a set of related activities, then any set of related activities, regardless of scope or scale, constitutes a process, and any label for activity is also a legitimate synonym for process. In the end, words fail us. As a result, the meaning of process eludes us. This lack of meaning creates much of the difficulty in defining an organization’s business processes.

The systems view

In the systems context, the concept of process is familiar to many as the center element in the input-process-output paradigm. In this context, process refers to the patterned, purposeful interactions between a system’s inputs and its processors. These interactions transform inputs into outputs; in the case of a manufacturer, raw materials become finished products.

The great shortcoming of the input-process-output paradigm is that it leads to a focus on the internal workings of a system so intense that the external world is sometimes ignored or overlooked. Yet, the external world is a vital factor in the performance of all systems. The relationship between an organization and its external world is characterized by transactions -- by the exchange of outputs for inputs (see Figure 1). The products and services a business produces go to customers in response to orders and in exchange for money. In turn, orders are placed with and payments made to suppliers for the inputs necessary to the organization’s continued functioning.

Results, as Peter Drucker points out, are always outside an organization. [ See Managing for Results (p. 5)] So are resources. A critical point to note in this context is that not only are results outside the organization, as Drucker observes, but they are measured on the input side of an organization not its output side. It is an order or a payment received from a customer that constitutes a business result, not an invoice mailed or a product shipped. Similarly, it is products and services received from suppliers, not payments to them, that constitute results. (For the supplier, however, payment received is very definitely a result.)

Figure 1 - Transformations & Transactions

An organization’s transformational processes (the conversion of inputs to outputs) and its transactional processes (the exchange of outputs for inputs) define the organization from the process perspective. The transformational-transactional view of organizations shown in Figure 1 suggests that all organizations have only a few basic processes. Some basic processes clearly implied by Figure 1 are listed below.

These basic processes are themselves parts of larger loops of activity, some of which are transformational and some of which are transactional in nature. An organization’s processes, that is, the flow of inputs and outputs through its transformational and transactional loops, are typically divided up into some commonly accepted business functions.

• Production (converting inputs into salable products and services)
• Distribution (getting products and services to the customer)
• Sales (getting customers to buy the products and services)
• Billing and Collections (getting customers to pay for what they’ve purchased)
• Accounts Receivable (keeping track of money coming in)
• Purchasing (obtaining the inputs necessary to support production and other processes)
• Accounts Payable (keeping track of money going out)
• Finance (managing the company’s money)

With additional thought, other functions can be added to those above:

• Marketing (identifying those with money to spend and their needs and requirements)
• Research (finding new sources of value)
• Product Development (creating new products and services)
• Legal (securing legal status and protecting against legal assaults)
• Personnel (finding, hiring, and compensating people)

The precise form these functions take, the labels they wear, and their distribution among a firm’s functional structures vary with the industry, the technology, and the history of the firm in question. That aside, the basic lesson is plain to see: There are only about a dozen or so basic business functions in any organization, and even fewer business processes.

Focusing on processes

Focusing on an organization’s key business processes is not as simple as it sounds.

Definitions are misleading. With but minor differences, Hammer, Harrington, Davenport, and Juran are agreed that a process is a set of related activities that produces a result of value to a customer. Answering a customer’s inquiry satisfies such a definition, but a process improvement effort taken down that path leads all too often to efforts aimed at making call handling more efficient instead of figuring out why such calls are occurring and how to eliminate them.

Similarly, all organizations are situated between suppliers and customers. Any student of business knows that supplier relationships are as essential as customer relationships to the survival and success of a business enterprise. To define key business processes only in terms of customers begs half the issue. To simply redefine everyone as customers muddies the conceptual waters beyond belief.

One generally accepted approach to mapping existing processes is to identify the outputs being delivered and then work backward from there to identify the processes or state-change activities that yield these outputs. (Payments to suppliers are outputs, which might explain why the functions of purchasing, accounts payable, and receiving are such frequent targets of reengineering efforts.)

At the risk of stating the obvious, the task of defining this or that process is influenced by the selection of outputs to trace and whether they are being traced to customers or to suppliers.

Business processes are unknown quantities

All of us tend to think in terms of what we know, and what we know best is the current scheme of things. For most of us, this is a functional view of our organization—sales, marketing, manufacturing, distribution, operations, systems, finance, legal, and so on. Within this functional framework, people generally have a good grasp of that portion of the business process to which their work contributes.

Business processes are streams of activity that flow across functional boundaries. For this reason, business processes are said to be fragmented, that is, scattered across so-called "functional silos." Few people in these silos ever have the occasion or the opportunity to study their work in the context of the larger business process their function supports. Thus, for most people, their company’s business processes are literally unknown quantities.

Beware names

Because an organization’s processes are unknowns, they do not have names and cannot be readily identified by their name. To start with names is, by definition, to start with the known. Using the names of known activities has the unfortunate effect of invoking the current view of things. To start with names, therefore, is to launch an exercise in futility. As you set about identifying your company’s key business processes, it might help to keep in mind that you can’t name them until you identify them; the names come last.

Beware examples, too

If words and names fail us, examples aren’t of much more help. Product development, or so we are told, is a process. So are purchasing, manufacturing, order fulfillment, and several other "sets of related activities." Yet, even when business processes are identified based on examples, disputes still arise. One person names a process. Another claims that the process just named is not a process at all but is instead merely a function. Terms and definitions are argued and bandied about. Examples are held up one after the other and, one after the other, are promptly shot down. Resolution of such disagreements, if resolution occurs, is usually the result of an act of authority, not a meeting of the minds.

Examples at ETS

Consider the case at my company, Educational Testing Service (ETS), home to a host of tests recognizable by their initials: for example, SAT, GRE, and GMAT. Ask almost anyone at ETS to generate a list of ETS’s key processes and, chances are, the list will include the following:

• test development
• test production
• test administration
• registration
• ticketing
• scoring
• reporting

Press for a longer list and you’ll probably see some of the following—plus others:

• inquiry
• equating
• item writing
• printing, mailing, and distribution
• systems development
• payroll
• purchasing

Pose any of the items above as examples of processes, however, and they will be immediately disputed. The primary reason for this contentiousness is that most analyses of processes are "floating," adrift in a sea of undefined terms, unclear boundaries, different perceptions and experiences, unstated assumptions and expectations, and an unwittingly imposed mindset.

Anchor the analysis

The solution to the problem of "floating analyses" is to anchor the analysis of a business process to something or someone, preferably to a tangible product or, better yet, to the customer. An example follows.

The tangible products with which ETS test takers come in contact include the following:

• test bulletins
• registration forms
• test center tickets
• test books
• answer sheets
• score reports

Moreover, the test takers typically come in contact with these products over time in the order listed. In some cases, test takers actually produce the finished product (e.g., filling out registration forms and filling in the bubbles on answer sheets). These products, then, offer evidence of some larger process and, at the same time, they mark off its subprocesses (see Figure 2).

Figure 2 - An "Anchored" View of the Testing Process

The end product, a reported score, has more than one use and more than one user. A college-bound high school senior might use it in selecting colleges to which he or she will apply. An admissions officer might use it as one of many factors used in determining whether or not to admit a particular applicant. A recruiter might use it to solicit applications.

Unknown, unnamed processes at ETS

Yet, we at ETS don’t have agreed upon names for or descriptions of each and every business process and subprocess depicted in Figure 2. Process B, for example, is marked at one boundary by the test taker being in possession of a bulletin and at its other boundary by a completed registration form. We don’t have a name for this process. Nor do we have a name for the process that is bounded on one side by the test taker completing a registration form and on the other by the test taker being in possession of a ticket of admission to a test center.

This lack of names raises a number of questions. Chief among them is this one: "What is the process marked at its beginning by the test taker’s awareness of some testing requirement and at its end by the score from an official score report entering into a decision (e.g., a decision to apply, admit, place, license, or certify)?"

Because they are unknowns, processes are generally not well understood

We not only don’t have names, we also lack exhaustive inventories of all the "related activities" making up the subprocesses shown in Figure 2. Process B, for instance, almost certainly involves test-taker behaviors such as reading, deciding, and filling out the registration form, yet these absolutely crucial activities do not show up in any analysis of ETS’s business processes.

Process boundaries must be set

A difficult lesson for all process analysts to learn is that processes are not really discrete sets of related activities. They are instead selected portions of larger streams of activity. Process boundaries must be set or established in this larger context, not simply identified. Only after these boundaries have been established can the process be treated as a set of related activities.

The importance of recognizing that processes are portions of streams of activity and not simply discrete sets of related activities is illustrated by the following analogy.

Picture yourself standing by the side of a shallow stream. In your hands are two stakes. You wade out into the stream and drive one stake into the bed of the stream. You say to yourself, "The process starts (or ends) here." Now, you wade downstream (or upstream) 50 feet or so, and drive the second stake into the bed of the stream, saying to yourself, "The process ends (or starts) here." You’re not fooled, are you? The process does not start nor end where you’ve driven the stakes into the stream bed. At best, you have marked a portion of the stream for study or manipulation or some other purpose. The same is true when you "drive stakes" into the stream bed of organizational activity as a way of defining business processes. What you have marked off and called a process is really a portion of some larger stream of activity.

That business processes are actually segments of a larger stream of activity is borne out by Figure 1. A quick look at Figure 1 reveals a "Figure 8" or "infinite loop" pattern. This loop operates as follows: Money coming in to a producer from its customers is used to purchase products and services from its suppliers. These products and services are used to produce products and services that can be sold to its customers in exchange for more money coming in. Thus it is that the cycle of events defining the organization as a system closes and reinitiates itself. This cycle of events can continue as long as the transactions with customers and suppliers can be carried out to mutual advantage (which is why some organizations outlive the people who establish them).

As a practical matter, establishing process boundaries is often facilitated by looking for places where state changes, hand-offs, and transfers of custody or ownership occur, but, in the last analysis, someone must bound the process, someone must say which of the many possible boundaries will be used, someone must drive the stakes into the bed of the organization’s stream of activity and, in so doing, define its processes.

Summary

1. Processes are selected portions of larger streams of activity.
2. Business processes are portions of streams of activity that contribute to business results.
3. Results are the effects of actions taken.
4. Business results are always external to the business, they are "out there."
5. Business results are measured on the input side of an organization, not its output side.
6. An order or a payment received is a business result; a product or service produced is not.
7. To define is to establish boundaries.
8. Boundaries must be set, not simply discovered or identified.
9. In a stream of activity, boundaries can be set anywhere one chooses.
10. The way to begin is to jump in; the place to begin is with results.
11. Many business processes take the form of loops, cycles of events that are initiated, carried out, and, upon closure, reinitiated.
12. Some business processes are transformational; others are transactional.
13. Transformational business processes are concerned with converting organizational inputs into organizational outputs.
14. Transactional business processes are concerned with exchanging outputs for new inputs to continue the cycle of events of which any given process is a part.

Conclusions

Word definitions of "process" are inadequate by themselves. They fail to clearly differentiate process from other related terms such as function, task, step, and operation. (For more on this score see my paper titled "Define Your Terms: Clearing up the Confusion among Function, Process, Procedure, Task, Step and Activity.") Perhaps the most important thing to know about all these terms is that they have meaning only in relation to one another.

Examples are often inadequate, too. Like verbal definitions, they all too often reflect the existing scheme of things. The process view is a different way of looking at things. Initially, at least, an organization’s processes are largely a mystery to its members. Organizational members fail to perceive and deal with the organization’s processes because the members’ view of the organization and its activities is colored by their functional view of things. People know the leg, the tail, the ear, the trunk, and the tusk, but not the elephant

Identification and analyses of business processes must be anchored to something concrete. These anchoring points can be customers or products or suppliers or orders or all these and more.

Exercise caution when using the input-process-output model as a framework for thinking about business processes. Unguarded, it leads to a focus on the transformational business processes to the exclusion of transactional processes. For the most part, customers don’t care about producers’ transformational processes. Most important, an organization’s business processes are really just portions of larger streams of activity, the main ones of which constitute an infinite loop involving suppliers and customers.

Finally, defining a business process is a taxing, vexing, and iterative process. Clarity regarding the business processes making up one’s company doesn’t leap forth full-blown; it is obtained instead only as the result of a lot of hard work.

References

1. Davenport, Thomas H., Process Innovation: Reengineering Work through Information Technology (1993). Harvard Business Press: Cambridge.
2. Drucker, Peter F., Managing for Results (1964). Harper & Row: New York.
3. Hammer, Michael and Champy, James, Reengineering the Corporation: A Manifesto for Business Revolution (1993). HarperCollins: New York.
4. Harrington, H. James, Business Process Improvement (1991). McGraw-Hill: New York.
5. Juran, Joseph M., Juran on Planning for Quality (1988). The Free Press: New York.