Our approach to analysis builds a working model of an existing process and then extends that model to consider innovations based on changes in coordinating activities. To understand how and why such changes may be innovative, it helps to build a clear understanding about how the process currently works.
The steps below suggest an approach to building a description of a process as you might encounter it within a business organization. These provide a foundation for further work in understanding process variation and the critical variables affecting process performance.
The potential advantages of this approach are:
Speed. Once you get used to it, you can develop an in-depth understanding of how the process actually plays out within the organization in a relatively short time. Using that understanding, you can build useful analytical models relatively quickly.
Size. This approach offers a way to represent realistically complex processes in a highly compact graphical form, choosing a level of detail that fits the goals of your analysis.
Meaning. Whether you use this approach from the top down or the bottom up (e.g., moving from general process descriptions to specific process examples, or vice versa), it will encourage you to think clearly about the meaning of each process step - e.g., what that task means to the organization strategically, tactically, and operationally. Asking about meaning provides a way of identifying goals that are explicit (and often only implicit) in a process as it is currently practiced, and surfaces assumptions that managers may not even realize they hold about the business.
| Phase | Activity | Output |
| Process Representation | Context description
Decomposition hierarchy |
Process representation consists of describing process context and developing a multi-level description, or decomposition, of process activities. The two steps affect one another and are often performed in a series of iterative loops. One of our objectives here is to give you sufficient experience with using the technique so that you only have to iterate through a process representation a minimum number of times - although it is likely that most of the time your last draft of the process representation may look quite different from the first. This is quite normal, and should not bother you - in fact, some people argue that one of the main values of this technique is what you learn along the way rather than the final process representation you produce. Please remember that the process map itself is not the final product we are seeking by using this technique - instead, the objective is a clear focus on what we can say about a (current) business and its (potential) improvements based on careful changes in how it is run.
Context setting results in a context description. This is basically a set of narrative field notes that describe the business you are studying, including the specific characteristics that lead you to think that you have defined an interesting and important management problem.
For example, a study of process design in healthcare might briefly describe how a hospital faced a combination of increasing local competition and more stringent government regulation, resulting in unprecedented pressure on its cost structure. Hospital management obviously did not want to sacrifice the quality of care that the institution provided just to lower its perceived costs, so managers asked whether there are better ways to run the institution so as to increase quality of care while decreasing costs. This discussion would provide a context for a comparison of the care process for an in-patient surgery procedure and an out-patient surgery procedure.
The context description would continue to describe the internal organizational factors from which current processes evolved. For example, in one hospital the nursing staff had spent several years applying total quality management techniques to in-patient procedures. After that experience that hospital was more prepared to analyze its own process and to learn from its own mistakes than many of its competitors.
Finally, the context description might consider the changing role of technology within the organization. References to technology change would probably remain brief at this stage, useful mostly for understanding how the organizational context might be shifting or as a foundation for understanding how new coordination techniques might be implemented, but since most organizations now operate using legacy systems of some kind (whether they are kanban cards or IBM mainframes), technology and its effects on organizational information are often worth considering explicitly.
For example, here is a brief description of how technology contributed to organizational context, taken from a healthcare process study.
In one hospital the information technology department began to assemble generalized case descriptions from the diagnoses and medical records of patients within its major practicies (e.g., cardiology, pulmonary disease, etc.). It began to circulate these general descriptions as "care plans" that described how patients were treated on day one, day two, etc. The IS department did this because then-current technology at the hospital meant that they were the only department in the organization that had ready access to the data. Unfortunately, they neglected to employ the assistance of the physician staff in articulating the care plans, leading to organizational conflict that threatened the level of trust existing between hospital administration and hospital medical staff. This led to the care plans triggering an organizational power struggle rather than improving care or cost.
How extensive should a context description be? At first, it can be quite sparse: a page or so of problem description, using an analytical framework such as that we introduced early in the term (see into2096.ppt). As your process description builds, however, the context information that you can provide will also expand, since any activities that you add to your process map will have their source in some example. That example provides the context that you can describe along with your activity summary, until you have the two end products of the process representation phase: a context description that is linked to a process decomposition hierarchy.
A process decomposition lists the subactivities that comprise each part of the process you are studying. It breaks a process down into its component parts. At high levels it describes the strategic intent of organized action (e.g., the goal of the process - for example, "Provide health care" or "Build cars"). At operational levels it describes tasks that get the work done - e.g., "Administer medication" or "Assemble engine". In between it describes important components of the process - "Prepare patient for operation" or "Run JIT assembly line".
Activity decompositions can be deceptively difficult to build because they demand analytical decisions about process goals, process steps, and process data. One way to organize these choices is through the use of activity lists.
Activity lists provide a shorthand way of describing the steps that an organization must accomplish in order to reach some goal. They can be as simple as a jumble of one-line activity descriptions in a word processor and as complex as a graphical tree of activities and subactivities. In order to keep track of activity characteristics that are important for coordination, one exhaustive way to describe activities is through the use of an activity table.
| Activity | Actor(s) | Goal | Resources/ Artifacts | Context |
| 1. | ... | ... | ... | ... |
| 2. | ... | ... | ... | ... |
| 3. | ... | ... | ... | ... |
This table would list, for each observed activity, the following characteristics:
It is easy to imagine that building a full-fledged activity table for a process of any realistic size is time-consuming. A completed activity table offers one end-point of process representation rather than a beginning - in effect, it describes a fairly extensive database of process attributes. In earlier stages of process representation you may find it easier to follow a three-step procedure for identifying activities and their subtasks.
This simplified approach suggests a relatively rapid (although more informal) way for describing and discussing processes. It takes three steps:
These three steps define activities in a way that completes a process decomposition hierarcy and begins to identify relevant process specializations. They can provide a helpful mental model for approaching the complexity of real-life processes.
As an example, consider the following table. It describes a company that builds long-haul trucks - and uses some of those trucks as the basis for a UPS-like shipping service. After growing rapidly for several years, the company is trying to rationalize its operations and better understand the core strengths of its businesses.
List. The first step is to list the activities that describe the work of the company. These are listed (in the order they were observed) in Panel A.
Drill down. The second step is to ask which activities represent the execution of some process. This step is shown in Panel B. This list outlines the process of building a truck and lists some processes are part of delivering the shipping service. The decisions that move the description from Panel A to Panel B consist mostly of asking which activities represent potential subactivities of others - in effect, asking what activities listed in A represent higher-level processes, and then "drilling down" within those processes to find what other activities in A represent the subparts of each.
The arrow in Panel A suggests the (fairly indiscriminate) listing of processes. The arrow in Panel B suggests the rearrangement of the activities identified in the listing stage into a preliminary activity decomposition hiearchy by drilling down within those activities in A that seem to represent higher-level process description than others (e.g., comparing Make trucks to Fabricate components, then realizing that Fabricate components is proably a subactivity of making trucks). Note that this exercise will probably force you to ask questions about the process that you have not yet asked - because you will be trying to understand what activities occur in each part of the process, and understand what each of those activities really means.
In the trucking example, the drill-down step produces a description of designing, producing, selling, and servicing trucks (e.g., a description of the company's internal value chain). It also suggests a description of the shipping service operation, including some definition of the manner in which the company designs new shipping services.
Generalize. The third step consists of consolidating what you have learned about the process by moving back up the ladder of abstraction. In effect, it asks that you review the process fragments you developed in the drill-down step and reassemble them into a coherent set of processes that begin to describe process variety in a consistent manner.
Panel C shows a segment of the trucking analysis, focusing on the Design process. It forces the realization that the company does more than design trucks - it also designs the services within which those trucks are used. This leads to a comparison of product and service design, reaching the potentially nonintuitive point that element of these two superficially very different businesses might be more similar than they seem on the surface. For example, let us presume that the company has extensive experience with high-quality manufacuturing, which includes the realization that design-for-manufacturing is an important part of the design process. The descriptions shown in Panel C, which essentially trigger a detailed comparison between designing products and designing services, might lead to greater use of "design-for service-delivery" in the shipping business. This could support tangible changes within the organization, such as giving closer attention to pilot projects during service design, or investing more in training and incenting the drivers and staff of the service operation to take a lead in new service ideas. In some companies even a simple analogy such as interpreting service training as a blueprint for guiding service delivery (in the sense of how Panel C suggests blueprints guide product manufacturing) might have a beneficial effect on service effectiveness.
The list/drill-down/generalize approach offers a way to sketch
process characteristics using very simple tools (e.g., the outlining
features now found in most word processors and spreadsheets).
It offers some structure for controlling the bewildering complexity
of process descriptions that attempt to describe organizational
work with reliable fidelity. It builds a compressed set of field
notes that offer a trace of evidence on which to support later
process interpretations. It also can trace changes that you make
as you move through successive versions of the process description
- and these changes often prove surprisingly useful for triggering
new approaches to the old business problems than the process analysis
is trying to address.
This section offers some hints for reducing the frustration of early-stage process description. These can be thought as ways to increase either your speed or your insights.
They refer back to the List/Drill-down/Generalize approach discussed above.
Use long activity descriptions at first. List activities means just that - develop as extensive a list as you can of the activities you think you see in one (representative) example of your process. At this point it can be helpful to use relatively long (e.g., one-line) description of each activity, since a description such as this one ~
(A) the junior loan analysts try to finish their worksheets in time for the Loan Review meeting
is generally more instructive at this stage than ~
(A) Analyze Credit .
When we discuss what Analyze Credit means as a description of business practice within the organization we are really using the second label to refer to the organizational inferences suggested by the first. By using a list of long activity descriptions you can capture many of your thoughts about such organizational inferences relatively efficiently.
By using relatively long activity names you are also doing in an informal way what the fields of the formal activity list table accomplish more rigorously -- e.g., imputing goals, actors, resources, and context to each activity. The loan analyst example above describes actors (loan analysts), resources (the software and hardware they need to complete their worksheets quickly), goals (to finish by the Loan Review meeting - but to provide effective credit analyses to their superiors), and artifacts (the worksheets themselves). It compresses all of these characteristics into a single line of text, but does so in a relatively natural way that captures some of the flavor of the process (it is not difficult to imagine the young analysts laboring away at their bullpen desks late into the night prior to the Loan Review).
In later phases of the process representation you can shorten the activity label - but this way you don't lose the information about the activity that you originally captured.
Many modeling approaches conceptualize processes as multi-level hierarchies of activities. Often, however, the notion of activity hierarchy has a top-down focus - it serves its major purpose as a mechanism for breaking generalized processes down into their component parts. Our approach to process modeling uses activity hierarchies that serve as both top-down and bottom-up tools. Using them in this fashion raises issues associated with the fit between top-down and bottom-views of processes. We refer to these issues as problems in mid-level representation.
In past projects it has proven relatively easy to articulate a process model based on interviews with high-level managers, strategic planners, or process designers. One might think of about this process design as an intended model, in the sense that it represents the process that was originally intended to implement a given strategy. Many projects have also successfully articulate process models that capture how work is actually accomplished at operating levels within the organization. One might think of these as emergent models that represent the ways in which work is actually done in the organization.
At this point in a process analysis, however, many analysts discover that the high-level process design bears little apparent correspondence to the workflows observed at operational levels. In other words, the intended and emergent models do not match at the middle levels of the activity hierarchy. This alignment problem triggers a focus on mid-level analysis.
In terms of representing activity hierarchies, mid-level analysis tends to increase the number of levels in the activity hierarchy while decreasing the number of branches from each node. This transformation is suggested in Figure 1.Figure 1: Mid-level transformations shift process map structures
To accomplish this transformation, analysts must group low-level processes into groups that make sense within organizational context. In essence, one must repeatedly articulate the meaning of process fragments. For example, suppose that the activities labeled 1.1 and 1.2 in section (B) of Figure 1 related to reviewing (1.1) and approving (1.2) customer credit. Section (C) of Figure 1 suggests that both activities are represented as parts of a mid-level activity (now labeled 1.1), perhaps called Assess Credit Risk.
This transformation, although superficially simple, forces us define what related activities mean for their organization. For some processes, this definition has important organizational implications. Consider, for example, what the aggregate of many Assess Credit Risk activities might mean for a large money-center bank - especially when the real work within those processes is performed largely by junior credit analysts who might not yet fully understand what Credit Risk really means.
By defining what high-level processes mean in terms of more detailed tasks, mid-level analysis contributes to a shared understanding of both strategies and workflows that many organizations lack. It is not uncommon for a corporate hierarchy to focus strategy development at high levels in the organization. In large organizations, it is not difficult for strategic intent to become so diffuse by the time plans reach levels of operational workflow that workers either have little understanding of the strategic implications of their actions (e.g., aggregate credit risk) or have different goals than top managers (e.g., to get finished by the Loan Review meeting). In many organizations, the sheer size and complexity of processes makes it difficult for top-level managers to think strategies through to operational detail, while employees are sometimes presented with tasks that appear to be inherently contradictory (e.g., give a careful credit assessment, but for 20 companies and by tomorrow at 9am).
Mid-level representation represents an opportunity for reconceptualizing the meaning of organizational processes that enable participants at multiple levels of the organization to develop a clearer picture of strategic intent and interpret that intent within the organizational context most familiar to them. To the degree that they force an organization to reconcile its intended processes with its actual processes, issues related to mid-level representation can play an important role in extracting value from the act of process modeling. They include transformations of activity hierarchies that are easy to execute, which simplify a process map, but which have the potential for greatly deepening its organizational meaning.
Process representations builds simple process models that capture potentially large amounts of information about process characteristics. They simplify process representations, without discarding information, in three ways:
We'll discuss the first of these below.
Here is an outline of a process developed from observations at a community hospital in Massachusetts. It describes procedures used to provide care for same-day surgery patients at the hospital's outpatient clinic. It derives from a process model constructed by two research teams in 1994 and 1995.
| Care for same-day surgery patient |
|
The outpatient care model shows six subprocesses that represent 20 subactivities. This representation aggregates into three levels a process map developed during the project that included seven levels of activities covering more than 175 activities. Generalizing from a lower level of detail to a higher level of aggregation does not lose knowledge about the process, since the we can always disaggregate process levels to surface lower-level detail. As Figure 2 suggests, activity decomposition makes the process representations in panels (1), (2), and (3) of the figure functionally equivalent.
Figure 2: Process aggregation does not lose activity information
Outliners (such as those found in word processors such as Microsoft Word) offer similar aggregation features. The important point to remember is that an activity hierarchy makes "compressed" process representations (such as in (3) above) functionally equivalent, for our purposes, to more detailed ones. To accelerate your analysis, realize that you can move back and forth between levels to control the depth of (potentially confusing) detail you need to consider.