Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

11.3 A Coordination Theory Approach to Processes Description

In this section we describe our process-description technique in six stages. Our overall approach draws on Checkland's (1989) Soft Systems Methodology. For data collection, we draw on four field-based research traditions: grounded theory (Glaser 1967), ethnographic research (Spradley 1979), case study research (Yin 1984), and the clinical perspective in fieldwork (Schein 1987). We have found these perspectives useful because they focus on the categories and terms that process participants themselves use to describe the process while imposing a minimum level of external preconceptions on process representation.

The technique starts by setting the boundaries of the process to analyze. Second, sources of data on the process are identified and data collected. The heart of the analysis is the identification of activities, actors, and resources and dependencies between them (steps 3, 4, and 5). Finally the process model must be verified. Although we present the steps in this order, in practice, analysis and data collection are likely to be interleaved, as analysis reveals gaps in understanding, which motivate further data collection. For example, some data are necessary to set the process boundaries, while the process boundaries are necessary to bound the data collection. Similarly the steps in an analysis will be performed iteratively, as a greater understanding of one aspect of the process will suggest additional alternatives to consider in the others.

11.3.1 Source of Examples

We will illustrate our technique using examples drawn from a case study of a small marketing services company. We offer this case as a demonstration that our method has helped at least one organization. We chose this company because its core processes are simple enough to present in a chapter, yet suffciently complex to permit a discussion of generative process design. To motivate our discussion, we will first briefly describe the company, which we will refer to by the pseudonym ''MAG Services''or simply ''MAG.''

MAG Services is a wholly owned subsidiary of a direct mail company that provides mailing and inquiry fulfillment services for corporate marketing departments of Fortune 500 corporations. MAG receives requests for information about a client's product(s) from individuals and fulfills the requests by mailing out appropriate marketing materials. MAG provides two kinds of service: custom and noncustom. Figure 11.1 shows the basic workflow through MAG's facility for both kinds of job.

Figure 11.1: Basic work flow at MAG Services

In the noncustom business, fulfillment is similar for all clients. A typical job would work as follows. A company runs an ad in Business Week. The ad includes a tear-off postcard bound into it saying, ''Send me more information about . . .''and offering choices of products (e.g., ''I want to know about blue widgets, or large widgets, or oil-resistant widgets''). On the front of the card is MAG's mailing address. A filledout card with a return address, demographic information, and product interest arrives by mail at MAG's data-entry room. MAG mails back product brochures according to the selections made by the person who sent in the card, and collects the data from the cards to feed back to MAG's client as marketing leads. In noncustom work, jobs typically run for an extended period (usually longer than a year), mailing materials are relatively standard and supplied in bulk by the client, mailing and production tasks do not vary significantly over time, and MAG performance reporting is largely limited to tracking the number of qualified sales leads.

Custom business is performed for clients on a one-time basis. An example of this nontraditional work might be a contract in which MAG provides inquiry fulfillment services following a trade show. At the show anyone passing by the booth can tear off a postcard with ''Send me more information . . .''on the back of it. Fulfillment of these requests is similar to the noncustom case. Based on these inquiries and other data, MAG creates a database of leads, including the addresses of people who have inquired, the inquirers'demographics, lists of prequalified leads, structured customer feedback, and the like. In contrast to noncustom jobs, these jobs run for only a limited time with a concentrated volume of work, materials may be specific to the particular job and include materials customized to the requester, and performance reporting includes both volume of contacts and measures of the quality of leads generated.

During a ten-year period in which MAG became a leader in the traditional mailing services business, the company developed a sophisticated database system that produced most of the mailings required by high-volume, standardized inquiry fulfillment and the reports required by long-time clients. By 1994 the company was actively engaged in applying the same database to customized services. By that year customized services accounted for more than 40 percent of revenue. However, at the same time MAG's management recognized severe operational and profitability problems with the custom business. These issues captured management's attention because custom contracts were straining the capacity of the organization and customers dissatisfied with MAG's performance on custom work were beginning to direct follow-on business to competitors. MAG managers gave high priority to custom work because they believed that it represented the area into which the company would have to grow in order to maintain its market share within the mailing services industry.

In the remainder of this section we will describe how we analyze the work done in MAG to suggest alternative processes that might be more effcient or effective, working through our technique step by step.

Step 1: Setting Process Boundaries The first step in our analysis is setting the process boundaries. Boundary-setting involves decisions about which actors, resources, and activities are central to the analysis and which are included only as tangential links to other processes or not at all. We focus our analyses around the stated goal of the process. Activities, actors, and resources that contribute to this goal are included in the analysis; activities that are peripheral are included only abstractly or not at all. In many cases there may be multiple possibilities for the overall goal of the process. In these cases the process boundaries are particularly important because they define the ''problem''and thus the scope of the solutions considered (Smith 1988).

IDENTIFYING GOALS An obvious way to identify goals is to ask process actors why they perform process activities. However, Spradley (1979) is quite emphatic about not asking people ''why''questions. He points out that intentions and motivations are subject to a great deal of rationalization as well as interviewer ''demand characteristics,''so much so that their reported intentions must often be handled with suspicion. Instead of asking ''why,''Spradley suggests asking, ''Under what circumstances would you do X ?''or ''Describe a situation where X would be appropriate.''For the top-level goals, we ask more general questions about the business purpose and overall objectives (e.g., How does this process fit into the business?). For the lower-level activities/goals, we suggest more specific questions:

What purpose does this activity serve? If you stopped doing it, what would happen?

How is (or how could) performance of this activity measured? What counts as a ''good''or ''bad''performance?

Who uses the results of this activity? What kinds of results to they find most important or helpful?

For MAG Service's custom business, these questions produced the following answers:

At the highest level of abstraction, MAG Services and its customers had divergent purposes in entering into custom business arrangements. MAG's customers wanted to find new customers through trade shows and targeted mailings, rather than waiting for customers to come to them as before. MAG wanted sales and profits to grow by generating new jobs that deliver such contacts with the promise of follow-on business. Custom-designed mailing programs were intended to satisfy both of these goals.

Performance measurements reflected the potential divergence of these goals. MAG's customers were interested in new sales based on leads generated by customized mailing services. MAG was interested in the profits from custom work and follow-on business.

The definition of helpful results differed in the same manner. Customers wanted to learn more about their markets, so as to build sales. MAG wanted to learn more about what services customers needed, but in a way that enabled the company to deliver those services at reasonable cost.

In other words, our initial study of the process suggests that at a general level this process has two divergent goals, first concerning customers'needs for specific attention to generate an explicit sets of sales leads and second concerning MAG's objectives of assembling and delivering mailings as effciently and profitably as possible. Each of these views—customer and company—may be appropriate depending on the purpose of the analysis. The point is not whether there is a single, universal process perspective that fits all conditions, which seems unlikely; instead, the more appropriate question to ask is whether the boundary of the process chosen is appropriate for the problem the analysis is intended to address.

Furthermore, as an analysis proceeds, it may be useful to change the definition of the process boundaries under consideration. It is not a question of the definition being right or wrong as much as useful or not useful. As Checkland (1981) puts it, ''the systems thinker must be able cheerfully to abandon his earlier choice of relevant systems and start again''(p. 223), perhaps shifting focus from a stated primary task to some latent issue that must continually be addressed (p. 222) or moving higher in a process decomposition hierarchy. For example, analysts considering supply chains might start with a process representation that describes one participant in the chain but might expand the analysis to include multiple flows coordinated by multiple corporate actors. For example, MAG might develop different strategic goals if it saw itself as an integral part of its customer's marketing processes rather than as a provider of standardized marketing services.

In our example, the focus of the analysis will be on the company that provides mailing services because the management problem under consideration is how to position the company for profitable growth. Other questions might lead to different boundaries (i.e., the definition of the system under study depends on the purpose of the study rather than being an inherent property of the system). For example, a study of companies that used account executives as sales coordinators might contrast MAG with several of its competitors using higher-level process maps.

Step 2: Collecting Data Building a process representation requires collecting considerable detail about many activities, goals, actors, and available resources, as described in the following sections. In this section, we describe our approach to data collection. Many data collection techniques have been proposed, which make different trade-offs among rigor, speed, cost, and accuracy. Many of the techniques focus on the question of reliability, in the sense that a second observer using these techniques should come to the same exact conclusions about the organization. Such rigor is clearly necessary for doing scientific studies where the goal is to make some generalizable assertion about how some phenomenon works in multiple settings. However, our goal here is different, as we simply want to say something about a particular site that others will find interesting or useful.

The methods we use include three central components:

Semistructured interviews based on understanding process decompositions, specializations, and dependencies.

Observation and participant observation where such approaches appear appropriate (this may include a range of participation from ''stapling oneself to an order''to sitting in on meetings).

Iteration that encourages revisiting collected data repeatedly as process understanding grows during subsequent phases of analysis.

Likewise we examine existing data about the process, such as flowcharts of processes and process fragments, examples of documents created in the process, training manual, and even interviews with managers or narratives collected from line workers. Even if this evidence was originally collected for purposes other than process analysis, it can be used to increase understanding.

At MAG Services, we used a combination of these steps. One of the authors interviewed more than 15 members of an organization of 70 people, including all of the company's account managers, the managers comprising the top three levels of the company, and selected part-time employees (e.g., in data entry and operations). Participant observation accumulated during approximately 20 weeks over eighteen months, and was largely accomplished by a MAG Services manager whom we trained in process analysis techniques.

Step 3: Identifying Actors and Resources As data are collected, we begin to create and fill the various categories of our description. Although we have presented this as a distinct step, in practice, data collection and analysis are likely to be interleaved (i.e., steps 2-5overlap). In step 3, we identify the actors who execute the process and the resources used and created in the process. This step is also useful in refining the process boundaries because only activities performed by the selected actors around the selected resources will be included.

Identifying process actors who are direct human participants is relatively straightforward. Nonhuman actors are more diffcult to identify. In some cases machines might be viewed as actors (e.g., ''the database sorted the leads by zip code''); in others larger aggregations, such as departments, might be considered (''Sales qualified the customer''). Again, our general rule of thumb is to add detail only where necessary for the purposes of the study. For activities on or near the boundaries of the process description, aggregations may be appropriate for defining actors (''Federal Express takes the package from the loading dock . . .''), while for activities central to the process description, human and system-related actors may need to be described more specifically (''Martha reads the output from the quality testing equipment on the assembly line. She's the only one of us who knows how to interpret it, and she's almost always right''). Similarly we would tend to treat a computer system as an actor unless there was some reason to concern ourselves with the source of data or the programs embedded in the system.

To check that the set of actors is complete, we follow the work flow up and downstream, using questions like, ''After you get done, to whom does this paperwork go?''or ''From whom do you get your work?''The tracing can diminish (and the actors become increasingly aggregate) at the edges of a selected process boundary.

Once the set of actors is identified, we group them into classes of actors who perform similar activities in a similar fashion (i.e., who fill similar roles in the process). For example, we might chose to treat all accounting clerks or FedEx drivers as examples of a class and document how these actors work in general as opposed to in particular. A possible rule of thumb for this grouping is that any member of the group could perform a given task. At MAG Services we developed the list of actors shown in table 11.1.

As the actors are being identified, we also begin to list the resources that are created by or pass between activities. Some of these may be physical objects, which are relatively easy to identify. Often, however, the key resource is information. To identify information resources, we ask what messages the actors send one another. For example, at MAG the account executives (AEs) write instructions for all the different production participants, such as data entry instructions, technical work orders (for programmers and Technical Services workers), and mailing services work orders (e.g., operations/production people in the warehouse). Resources identified in the case are shown in table 11.2.

Step 4: Identifying Activities The next stage in our analysis is to identify the activities that compose the process (i.e., what gets done in the process). Several problems must be addressed in this analysis. First, the same activities may be labeled and interpreted differently by different actors, and vice versa. Second, activities can be described at varying levels of detail. Third, the actual activities observed may vary between performances of the process, making identification of ''the''process problematic. The solutions chosen for these problems have implications for understanding activities themselves and for identifying the resources that activities use.

HOW TO IDENTIFY ACTIVITIES Spradley describes an interviewing technique used by cognitive anthropologists in collecting complex information from informants (1979, esp. chs. 4-6). The basic technique comes in three parts.

One could ask ''grand tour''or ''mini-tour''questions. These are general, open-ended questions like, ''Tell me about a typical day. What do you do?''A grand tour potentially covers all of the different work activities that go on in a particular task unit.

One could focus on more specific topics, like a particular part of the job or a particular process: ''Tell me what happens when a customer comes in,''and so on. One could follow up, probe, ask for elaboration, clarifications, and so on, but the basic idea is to elicit a general description of the work in the respondent's own words.

Having obtained a basic outline for groups of activities, it is possible to focus the contents of various ''semantic domains''(Spradley 1979, p. 107). A semantic domain is like a category, which can be very high level or very low level. In understanding process decomposition, ''activities''that can be decomposed into ''steps in''or ''parts of''the activity are important. To get at this information, one could ask a structural question: ''What are all the steps in this process?''This would be followed up with various probes to check for completeness: ''So far, you've mentioned the following steps: a, b, c, d, e, ..., Are there others?''At the most detailed level, all activities should be ''direct,''meaning something an actor can actually do (e.g., collect information or make plans), as opposed to the hoped-for outcomes of an action (e.g., lower costs) (Checkland 1981, p. 235).

The result of these investigations is a preliminary list of activities. This list will likely omit some of what the actors do. For example, two people may start each interaction by spending a few minutes discussing a previous night's game, yet not include that activity when describing the process. In general, we would follow the informants'lead in choosing whether to include such activities in the process description. It may be that these interactions are viewed by some of the individuals as necessary to the smooth running of the process, in which case they need to be included, or it may be that they are considered as secondary, in which case we would probably also leave them out.

DECOMPOSITION OF A PROCESS INTO ACTIVITIES Given a description of an activity, a second problem is to choose the appropriate level of decomposition at which to represent it. For example, a flowchart might include one box for a particular actor's task or hundreds of boxes for the fine details of that task. Each level of detail might be appropriate for different purposes. We avoid this problem by developing process decomposition trees that show how a high-level task is decomposed into lower-level tasks, thus simultaneously representing varying levels of detail. Following our general rule of thumb, we keep decompositions at the most general possible level unless the problem to be analyzed provides a reason to decompose a process in more detail. For MAG Services, we represent 'Send mailing'as an atomic activity, but 'Run job'is broken down into at least four subactivities, including preparing quotes, setting up jobs, producing jobs, and providing status reports.

VARIATIONS ON A PROCESS A third problem is representing variations on the process. In many processes the exact activities observed in a single instance of a process may never be repeated in all particulars. Even so, most organizational participants have little diffculty in recognizing the process as an abstract description that represents multiple instances of specific steps, both those that have happened and those that might happen in the future. This feature of organizational life can be described as inducing a generalized process from a relatively small set of observed activities by fitting observed actions into mental templates that define more abstract process steps. This translation usually forms an important part of ''learning the ropes,''the acculturation that orients newcomers to existing organizational characteristics and habits.

Our approach to this issue is to build a prototype sequence and then asking for variations. For example, ask the informant to describe a typical sequence of steps. Then ask: ''Can you think of an example where the steps were done in a different order?''or ''Under what circumstances would you do things differently?''These alternative ways of accomplishing the same activity may be ''alternative specializations.''A general activity (e.g., order entry) may be accomplished in several different ways, each of which is specialized for a particular purpose. One can elicit alternative specializations during an interview by asking: ''Are there different ways that you accomplish this activity?''Alternatives might also be generated by identifying in the Process Handbook (Malone 1999) a more generic activity of which an identified activity is a specialization.

EXAMPLE A decomposition of the activities in the MAG Services example is shown in figure 11.2. This figure shows a hierarchical decomposition of the process of providing MAG services, shown at the top of the page, into activities and subactivities, drawn down the page. This description shows that MAG engages in three phases of activity when handling a typical job. These phases include qualifying prospective customers, providing custom and noncustom mailing services, and billing clients.

The activity of providing mailing services is itself further decomposed in figure 11.2. The operational details of providing mailing services are normally handled by MAG account executives (AEs). The AE writes and distributes several sets of instructions inside the company so that the mailing that is produced ultimately matches the client's specifications (as approved in the quote). The AE also stays in touch with the client to ensure that MAG's services continue to be satisfactory as the job progresses. Most of the examples discussed below concern coordination managed by AEs in initiating new work on behalf of the company.

Figure 11.2 shows that MAG undertakes mailing contracts by qualifying prospective customers, providing services, and billing clients. Once prospects are qualified, the company sells its services. The sales activity ends when an AE takes an order for a job expressed within the company as a job quotation. Once the quote is approved, the AE prepares and distributes instructions that describe the job to operational departments within the company, and shows a copy of sample output from the job to the client. Finally, the operational departments execute the instructions and complete the job, which results in the collection of market information and a completed mailing. Sales and billing functions are performed in part by MAG's parent company.

Figure 11.2: High-level process decomposition view

Earlier we discussed an important variation in the processes that MAG Services used to deliver mailings: the difference between custom and noncustom work. Figure 11.3 suggests how this variation can be interpreted as representing variations in the Provide Services process. Figure 11.3 shows that the generic process of providing mailing services can be provided in to different ways, indicated by the two different specialized forms of the process—providing custom services and providing traditional services—drawn below on the page. Note that the specialized versions of the process have specialized versions of the subactivities as well. This comparison enables us to focus in useful ways upon the differences in producing mailings for custom and noncustom work. Table 11.3 summarizes some of these dimensions from the point of view of MAG's management.

Figure 11.3: Specializations illustrate process variety

This comparison surfaces some of the coordination challenges raised by custom jobs that a focus on production effciency alone would not recognize. Noncustom work is long term, standardized, brings guaranteed mailing volumes, and operates against a schedule largely set by MAG. Custom work is short term, nonstandard (even with respect to the order in which specific production tasks are done), operates against tight deadlines, and requires daily contact with the customer. Custom work differs fundamentally from traditional jobs in process and coordination.

Step 5: Identifying Dependencies So far our technique resembles most other process mapping techniques, identifying activities, actors, and the flow of resources.

These results for our example are summarized in table 11.4. The novel aspect of our approach is the identification of dependencies between the activities and resources and the application of coordination theory, which we discuss in this section.

Given a process description that includes goals, activities, actors, and resources, we propose two general heuristics for identifying dependencies.

Dependency-focused analysis. Identify dependencies, and then search for coordination mechanisms. In other words, look for dependencies, and then ask which activities manage those dependencies. Failure to find such activities might suggest potentially problematic unmanaged dependencies.

Activity-focused analysis. Identify coordination mechanisms, and then search for dependencies. In other words, identify activities in the process that appear to be coordination activities, and then ask what dependencies those activities manage. This approach asks directly whether all observed coordination activities are necessary.

These approaches are described and illustrated in the remainder of this section.

DEPENDENCY-FOCUSED ANALYSIS In dependency-focused analysis we examine the activities and the resources they use, determine possible dependencies by considering which resources are used by more than one activity, and then look for other activities within the process that manage these dependencies. More specifically, to identify dependencies and mechanisms, we ask questions such as the following about each activity in turn:

What are the inputs to this activity (physical, informational and other necessary preconditions, such as permissions)? Are there flow dependencies with the activities that create these resources? Are these resources used by other activities, creating shared resource dependencies?

What are the outputs? Is there a flow dependency with the activities that use these resources? Do multiple activities create these resources, creating common output dependencies?

What other resources are used, such as actors, equipment, overhead, time, and other items of importance in the process? Are there shared resource dependencies with these resources? How are these resources assigned to this activity?

What performance problems have been reported for this process (e.g., observed divergence from stated goals)? Do these problems reflect unmanaged dependencies?

For each potential dependency identified this way, we then search for activities that manage it. The typology in Crowston (chapter 3 in this volume) is helpful, as it suggests a range of possible coordination mechanisms for each type of dependency. For example, if an activity needs a resource, then from the typology we note that the resource may be permanently assigned, taken first come–first served from a pool of resources, assigned by a manager, and so forth. A flow dependency might be managed by a single activity or the coordination mechanism might be decomposed into separate activities for managing the transfer, usability, and inventory dependencies.

To summarize, in dependency-focused analysis, we examine the use of resources in order to identify potential dependencies, and then look for activities that manage those dependencies.

Example of Dependency-Focused Analysis The analysis discussed above can be done at every level of decomposition. We will illustrate by first considering dependencies in the MAG case at a very abstract level, considering the company as a link in a value chain, as shown in figure 11.4. At this level there are several resources, such as mailings and market information, that are used by multiple activities, thus creating dependencies. The dependencies between the activities are indicated using curved lines to show the flow of resources from one activity to the next. More specifically, examining inputs and outputs suggests that MAG produces resources for the 'Using market data'activity (i.e., it provides inputs to this activity), including sales leads generated by MAG mailings and market information collected from sales inquiry forms (demographics, channel sensitivity, etc.). The 'Using market data'activity is part of some larger process, indicated schematically by the vertical lines that connect this activity to other, unshown, activities.

Figure 11.4: MAG Services as a step in a value chain

Taken together, these resource uses suggest two kinds of dependencies: first, a task-resource dependency between MAG's customers and MAG, shown by the fact that MAG performs certain activities on behalf of their customers, and second, a flow dependency between the activities of MAG and its customer, shown by the flow of sales that leads from MAG to the customer. We next attempt to identify the activities that manage these potential dependencies.

MAG's business starts when a customer decides to hire them to provide mailing services that leads to useful demographic data or qualified sales leads. We note that numerous activities, such as mailing marketing information, are performed by MAG on behalf of a client. Such an assignment of tasks suggests a possible task-actor dependency (a special case of a task-resource dependency). In other words, a customer needs these services but does not or cannot perform them and therefore decides to hire MAG to perform them.

The various activities needed to manage a task-actor dependency are shown in Crowston (2002). These include determining needs, identifying possible actors, collecting information, picking the best, and then assigning the task. Interestingly in this case we see the assignment from the perspective of the assigned company, as it responds to requests for information ('Sell to customer'and 'Prepare quote'), is assigned the job, and finally performs it. Likewise several other activities, such as ''Qualify prospects''and ''Bill client''are likely involved in managing this dependency, although, in this case, these activities were performed by MAG's parent organization. The business completes a service cycle once customers receive data in a manner that disposes them to seek more work from MAG (e.g., the 'Use market data and sales leads'process in figure 11.4). The service cycle is a process that manages a flow dependency existing between MAG's activities and those of their customers.

Coordination theory suggests that a flow dependency includes usability, prerequisite, and transfer constraints that influence process performance. Following this distinction, we can identify activities or groups of activities within the 'Provide MAG Service'process that manage such constraints (see figure 11.4). Figure 11.5 provides a full overview of the process representation created so far in our analysis. It includes a hierarchical process decomposition, as in figure 11.2, overlain with dependencies and coordinating activities, as in figure 11.4. In figure 11.5 we look within the 'Provide MAG Services'process to understand how subactivities manage the dependencies that act as constraints on the flow of jobs. From the customer's point of view, key variables associated with process performance appear to lie within the 'Run job'process. For example, the time dimension of MAG's performance appears to be constrained by the speed with which MAG can set up jobs and produce mailings. This implies that 'Set up job'is managing prerequisite constraints associated with the higher-level flow of jobs. The geographic nature of its work (e.g., disseminating mailings to inquirers and market data to clients) emerges clearly from the 'Produce mailing service'process. This implies that 'Produce mailing service'is managing transfer constraints associated with the flow of jobs. Preparing a quote is a critical step in ensuring that the job defined to the company is a job that will be satisfactory to the customer, which implies that 'Prepare quote'is managing usability constraints.

Figure 11.5: Coordinating subdependencies within the 'Run job' process

Figure 11.5 summarizes this analysis using a graphical notation that shows subactivities and subdependencies. The upper levels of the process representation describe MAG Services as managing a flow of resources between two of its client's processes, as discussed above. The darker arrows in the figure suggest how dependency-focused analysis moves downward within the activity hierarchy to identify coordination processes that manage subdependencies. In this case specific coordination activities manage resources associated with a subdependency that constrains the flow of jobs. 'Prepare quote'manages the usability of a job to a customer and to MAG. 'Set up job'ensures that the company completes the right tasks in the right sequence, thereby managing prerequisite constraints that affect the flow of jobs. 'Produce mailing services'generates the physical mailings that fulfill inquiries and transfer information back to the client. These coordination activities are summarized below in table 11.5.

Using figure 11.5 and table 11.5, we can ask how effective the chosen coordination strategies have been in practice. Table 11.6 shows the results of a coordination analysis that explicitly considers coordination strategies. It compares the effectiveness of the coordination strategies that MAG developed for noncustom business with performance observed for custom jobs. Recall that the company's existing coordination processes were designed for long-cycle, high-volume, low-variation jobs. Using our approach, it becomes possible to identify specific ways in which MAG's services are breaking down under the differing requirements of custom work. Specifically, custom business varies across dimensions such as deadlines, job complexity, and accuracy requirements in ways that MAG's existing coordination techniques are not particularly well prepared to handle. To illustrate, we will discuss three examples from table 11.6 in more detail. The analysis enables us to apply the notions of usability, prerequisites, and transfers to specific operations-level activities within the company. These activities represent the coordinating mechanisms that the company uses, implicitly or explicitly, to implement its services. By this means we were able to pinpoint with some accuracy how coordination breaks down within the daily work practices of the company.

QUOTES: COORDINATING USABILITY MAG's traditional work was suffciently standardized that AEs could successfully negotiate quotes over the telephone, taking handwritten notes that were later revised into a quotation letter signed by the customer. This approach worked well for relatively simple standard work. Custom work, however, often varies in the types of services that the customers requested, and always requires much tighter deadlines. Under such circumstances AEs did not always know how to quote jobs immediately, customers often didn't realize the cost implications of what they were asking for, and quotation letters became both delayed and increasingly controversial. In this sense, a quotation process developed for standard work proved unsuitable for coordinating quotes for custom jobs.

JOB SET UP: COORDINATING PREREQUISITES Once a quote was complete, AEs prepared and circulated instructions for entering data and producing a job. These instructions delivered on internal forms that MAG designed for traditional work, and became increasingly dysfunctional for custom jobs. The forms were long and complex; as the custom business evolved, their options became irrelevant to the instructions that AEs needed to provide. MAG's organizational systems, in effect, were asking for the wrong data. Some AEs reacted to this problem by taking more time to type their own versions of instructions; others hand wrote long additions to standard company forms. Others insisted on following up all written instructions with verbal instructions. The net effect of these reactions was to slow the pace of custom work at the very time that custom jobs were requiring faster turnaround times.

MAILING SERVICES: COORDINATING TRANSFERS MAG's internal operations were highly developed for producing standardized bulk mailings. Problems developed, however, when custom jobs required below-average batch sizes and MAG was unable to adjust. This problem surfaced when customers required AEs to report back to them on misdeliveries immediately rather than monthly or quarterly. Because MAG's reporting systems, developed for standard jobs, only traced activity by batch number, AEs had to spend hours researching potential mistakes. The net effect, again, was to slow down custom work and make MAG appear inflexible.

To summarize, in dependency-focused analysis we first identify dependencies by considering resources used or created by multiple activities. We then search for coordination mechanisms that manage those dependencies, searching through successively more detailed layers of the process until insights are gained about how process goals are implemented in practice. In a full analysis this dependency focus leads to a detailed understanding of activities that coordinate key resources associated with dependency constraints.

Activity-Focused Analysis Our second approach to finding dependencies and related coordination mechanisms starts from the activities. Activity-focused analysis surfaces candidate coordination activities, and then looks for the dependencies that they manage. In this sense it operates inductively rather than deductively, aggregating dependencies upward through the process hierarchy to build an analysis that complements dependency-focused approaches.

In activity-focused analysis we suggest three complementary heuristics to triangu-late on potentially important dependencies. These include identifying critical process tasks, identifying coordination activities, and identifying coordinators.

Search for process-critical activities. Activity-focused analysis asks which activities play a necessary role in the completion of a process; the remaining activities are likely to be coordinating these. At MAG Services, producing a mailing is a process-critical activity because it directly leads to the output desired by the customer.

Search directly for coordination activities. Activity-focused analysis examines tasks identified within a decomposition hierarchy and asks whether these activities represent coordination, namely whether they match one of the activities in table 11.1 or otherwise manage an important dependency within the process. For example, examining budget preparation cycles can identify resource allocation mechanisms; tracking the flow of chapter or other physical resources within an organization can often identify activities that manage flow dependencies.

Search for actors or resources that coordinate. Activity-focused analysis looks for actors whose work frequently suggests coordination tasks. At MAG, account executives negotiate a contract and write the instructions that define customized mailing services.

To summarize, in the activity-focused analysis, we look for activities that may implement coordination mechanisms. Candidate activities are those that are non-production, resemble coordination mechanisms, or are performed by coordinators.

Example Figure 11.6 summarizes a search for coordinating activities at MAG Services. The illustration represents the results of the steps described above.

Figure 11.6: Chapter flow and resources at MAG Services

SEARCH FOR CRITICAL ACTIVITIES This step asks the same question of each activity: Could the end product of the process exist without it? Of all the activities shown in figure 11.6, the only one that appears irreplaceable is 'Produce materials'. The company might use different sales processes, it can change its quoting process, it can even ''send''mailings via the Internet, but jobs cannot be delivered without some production of personalized materials, be they physical, chapter, or electronic.

This focus is helpful because it offers a core from which to aggregate dependencies. If 'Produce materials'represents a key production activity in this process, the analysis can step outward from that foundation to ask what coordination other observed activities provide. From this perspective the activities related to converting client interest into instructions for producing materials (9 of the 18 activities in figure 11.6) appear to be attempts to coordinate production of mailings according to criteria that meet the performance expectations of both MAG and its customers (e.g., maximum profit with minimum time, errors, and cost).

SEARCH FOR COORDINATION Within the 'Run job'process, the only obvious production step is 'Produce mailing service'; that is, only this step produces an output that is given to the customer. 'Prepare quote'and 'Set up job'appear to be processes that largely prepare information to ensure either that jobs meet performance criteria (e.g., 'Prepare quote') or that work will proceed error-free ('Set up job'). In other words, they appear to manage the usability of the production work found in the 'Produce mailing service'step.

Where records represent information that crosses process boundaries (i.e., they are an output that is used as input by another process), they identify potentially important flows. Thus records can form a resource within flow dependencies. By this means information-intensive activities (i.e., those that handle information used extensively by other activities) can often be understood as coordination mechanisms. Figure 11.6 shows records that cross the branches of the process tree developed for the mailing company. It describes six steps in executing a job: prospective customers produce an inquiry about mailing services, sales processes pass prospects and job proposals to MAG account executives, AEs prepare quotes in response to those proposals, quotes are converted into instructions, and instructions precede the mailings and leads generated by a job. Each of these elements represents a resource that flows across process boundaries within MAG's operations. In figure 11.6 the 'Run job'process is shown at a lower level of decomposition because it represents internal activities over which MAG managers have greatest control (as noted above, sales and billing are performed by MAG's parent organization).

SEARCH FOR COORDINATORS Actors perform activities that use resources. To the degree that the same actors perform multiple coordinating activities or produce resources employed by coordinating activities, they can be identified as important coordinators within a process. MAG account executives produce both quotes and instructions (resources) while performing five of the nine coordinating activities identified in the prior step. From this perspective they appear to play an important organizational role in supporting coordination.

DEPENDENCY AGGREGATION The three steps of activity-focused analysis have so far suggested that (1) preparing quotes and instructions are at least coordination-intensive activities, (2) producing personalized mailing materials is probably a critical process step around which coordination activities cluster, and (3) AEs perform much of the coordination required to define and complete profitable jobs. These suggestions focus attention on the potential coordination provided by processes related to preparing quotes and setting up jobs.

If these coordination activities manage dependencies, it is reasonable to move one level higher in the process hierarchy and ask what coordination they perform. Doing so considers the relationship between the company and its customers as the company runs a mailing job (e.g., 'Run job'). From this perspective it appears that 'Prepare quote'manages the usability of a job to the customer and the profitability of the job to MAG; in other words, it manages usability constraints. 'Set up job'appears to manage the sequencing of activities within MAG operations (recall that three sets of instructions are prepared and distributed, one to each functional area, that direct how the functional areas are to interact during the job). In this sense 'Set up job'is managing prerequisites.

To summarize, in activity-focused analysis, we first search for activities that appear to be examples of coordination mechanisms, and then check for dependencies that are managed by these activities. This bottom-up approach offers an alternative view of the process that is complementary to the results produced by a top-down, dependency-focused perspective. Where the results overlap the two analyses offer the means for producing confirmatory evidence of coordination choices made by the organization. Either approach can confirm or disconfirm process characteristics suggested by the other. Dependency-focused analysis proceeds from the perspective of high-level goal structure, while activity-focused analysis begins with chapter flows and process artifacts that exist deep within the organization.

Step 6: Verifying a Model Process models may be as valuable for the insights that are developed in the process of building them as for the final process diagram. To this end verification plays a particularly important role in the techniques suggested here. We suggest two verification techniques in particular as complementary mechanisms for improving process representation and analytical accuracy.

The first of these is the negative case method (Kidder 1981). Candidate process representations are developed and discussed to discover what is missing in the representation of the process. Gaps and ambiguities identified guide further data collection. These omissions can be identified by discussing the process model as it evolves with the actors who are involved in the process—discussions that often trigger the need to go back and revisit various process representation decisions made earlier.

Triangulation provides a second opportunity to verify the faithfulness of process representations. We use the term to refer to the ways in which process models are discussed with process actors. The emphasis here complements the negative case method by assessing what process elements appear to generate broad representational agreement from groups of process participants. Representational accuracy, in this sense, can be corroborated by broad agreement among process participants.

Negative case analysis and triangulation are included here to highlight the importance of internally consistent verification of process models, context descriptions, and analyses by the individuals who participate in the process themselves. Since any organizational process is open to differing interpretations by each of its participants (Hackman 1969), and since even the problems that processes are designed to ''solve''are open to definition-by-interpretation (Weick 1969), subjective verification may be the best consistency-control available to field teams.

From a research design point of view, the dangers of subjective verification, even by multiple respondents, are well known (Yin 1984). It is important to recognize, however, that managers and other professionals working within organizations face the same limitations in understanding observed behavior: for them, low-level subjective consensus represents one key mechanism whereby groups jointly interpret events. Iterative, multiple-source verification (e.g., of process descriptions) in this view represents the same level of reliability that process designers themselves must handle in actual practice. To the degree that an expanding understanding of process characteristics can add structure and consistency to process representations, the reliability of process descriptions can be improved. Absent this, however, the use of iterative, multiple-source verification seems not only an achievable means for checking descriptive fidelity but also one that very appropriately reflects real-world conditions.

11.3.2 Summary

The result of the six-step process outlined above is documentation of a process that includes activities, actors, resources, and dependencies among them, as well as identification of how the dependencies are currently managed. This process documentation can then be tested to ensure that it is reasonable, that it makes sense to people or that it can be used to communicate the process. In the next section we will see how such documentation might be useful as a basis for process improvement.

11.3.3 Using Dependency Analyses as a Basis for Process Improvement

Our main purpose in creating process representations is to support process improvements. Documenting the dependencies and coordination mechanisms of a process provides an approach to developing new processes. New activities can be proposed to manage poorly managed dependencies or alternative coordination mechanism can be considered to manage each dependency. Note that mechanisms are themselves activities, with their own set of dependencies. Replacing one mechanism may therefore eliminate some problems while creating an entirely new set to be managed.

When the custom mailing process began to break down, MAG managers responded in ways suggested by their experience with traditional, high-volume, standardized mailings. They initially fixed their attention on lowering costs by trying to make custom jobs run as smoothly as the standardized noncustom work. They focused on rearranging the company's internal production processes (e.g., the steps by which MAG sorted data and prepared mailings). Unfortunately, this perspective meant that the cures initially suggested for the custom business proved worse than the disease, as it missed the need for flexibility demanded by customized contracts.

Our analysis suggests ways in which to modify coordination strategies and the tools used to implement those strategies. For example, dependency-oriented analysis might to suggest ways in which AEs can redesign the quoting process to reduce project lead-times. Activity-based analysis, however, can contribute useful detail describing how to redesign a quotation form to be used in describing the cost of services to clients over the telephone. Taken together, the two approaches can contribute guidance to information systems development designed to resolve the timing and flexibility problems identified as threats to the custom business. Dependency-focused analysis can contribute to clarity of process purpose, while activity-focused analysis can contribute insight about implementation detail.

The process analysis performed for MAG services as part of this project led to prototypes of process improvements. After completing the analyses described above, the organization developed software based on a commercially available groupware package to experiment with making three changes in the Run Job process.

First, the software provided AEs with cost estimates for any combination of mailing tasks, using an interface that enabled them to build accurately costed job quotations during a telephone conversation. The same software generated quotation letters semi-automatically. Second, the system fed data electronically to instruction forms. These forms were extremely simple in design, and accumulated operational detail only for the tasks specifically required in any one project. Last, the system provided a series of checkpoints so that AEs could electronically monitor job progress, enabling them to report back to customers on a daily basis if necessary. All three of these innovations provided a better way to ensure that the work done is what the customer requested and is correct, that is, to manage the usability portion of the high-level flow dependency discussed above. AEs reported that these design changes had the potential for increasing their capacity for custom work. At the end of our study the company was considering whether to develop a commercial version of the system.

A coordination perspective also provides some insight for goal resolution. To the degree that usability constraints threaten to be incompatible, the process coordinating them may include explicit activities devoted to resolving potential conflicts. In many organizations, for example, order-taking begins to resemble sales negotiation as activities are added to ensure that the order will be usable for both producer and consumer. In engineering-intensive businesses, the RFP (request for proposal) process can be understood in this fashion. In simpler businesses, as well, an important coordination opportunity often arises as new business enters the work flow. At MAG Services, for example, a quoting process controls how orders for customized services are placed.

More specifically, the perspective provides a mechanism for summarizing potentially divergent goals surfaced by MAG's business relationships. For example, it suggests how a customer's purpose might interact with the organization's internal goals. A customer is likely to seek to generate the maximum number of useful sales leads in the shortest available time. MAG has a need for profitable growth. In coordination terms, these goals represent usability constraints affecting the flow that MAG coordinates. Each mailing service, this representation implies, must remain usable to both the customer and to the supplier—that is, it must provide sales leads that satisfy some range of customer criteria yet remain profitable to MAG.

11.3.4 Trade-off Matrices

Likewise the models can serve as a basis for articulating the trade-offs available between different versions of a given process. Trade-off matrices contrast process characteristics across different versions of a process. Consider the variations of the 'Run job'activity. One version of the process refers to selling traditional business; the second refers to selling custom jobs. The dependencies underlying the coordination analyses above apply to both but the strategies employed for coordinating these dependencies differ. The trade-off matrix in table 11.4 suggests some of the ways in which the two types of business compare. The comparison suggests ways in which process performance can be improved by redesigning the ways in which process dependencies are coordinated.

For example, the trade-off matrix suggests that coordinating custom projects is more time-sensitive than initiating noncustom work. This comparison implies that if the company could facilitate AEs'and clients'understanding of the cost implications of custom services, the logistics and productivity of MAG's custom services might be enhanced. Analyzing usability, transfer, and prerequisite dependencies suggests a range of alternatives for improving communication among AEs, customers, and operations staff in all stages of job definition and execution, extending from technology-intensive solutions such as an on-line job definition system that allows new customers to design their own customized service to relationship-intensive solutions such as pairing operating staff with AEs in custom-project teams.