لطفا منتظر باشید ...
9.2 Example — Process Innovation (Davenport 1993)
The following analysis is based on the account of process innovation given in Davenport's Process Innovation: Reengineering Work through Information Technology (1993).[1] Early in his book, Davenport proposes an innovation process consisting of the steps diagrammed in figure 9.1. Most of Davenport's book can be understood as a working through of the details involved in each of these substeps.[2]
Figure 9.1: Steps in process innovation as described in Davenport (1993)
9.2.1 Subactivities
Here then are the subactivities that have been identified:Identify processes for innovation. It can be argued that this is outside the scope of a design taxonomy, in that process design takes as a starting point a given process to be designed. However, it can also be argued that choosing a design problem can be a key element of design. I adopt the latter approach. (Source: Davenport, p. 27)Identify change levers. Davenport considers three potential sources for process innovation: new information technologies, better use of information as process resource, and innovations in organizational structure. (Source: Davenport, p. 48)Develop process visions. The process vision is the link between potential process innovation and the broader sense of business vision and strategy. (Source: Daven-port, p. 121, figure 6.1)Understand existing processes. This refers to describing and analyzing the process as it exists. (Source: Davenport, p. 139, fig. 7.1). This step does not appear to be a focus for Davenport. He seems to mostly ''outsource''this step by appealing to existing methods. ''We look to [traditional process-oriented approaches] for tools and techniques . . . They are most appropriately used to complement the components of the innovation approach described in this book''(Davenport 1993, pp. 150-51).Design and prototype new process. ''Ironically, there is less to say about the design phase of process innovation than about the activities that lead up to it. The design activity is largely a matter of having a group of intelligent, creative people review the information collected in earlier phases of the initiative and synthesize it into a new process. There are techniques for facilitating the review process, but the success or failure of the effort will turn on the particular people who are gathered together''(Davenport, p. 153). Note that this approach implicitly assumes a relatively centralized process, where the key is to ''gather together''the right group of people.
Improve process. Process improvement does not play a central role in Davenport's account of process innovation. In reviewing my original analysis of this text, I can see that I have given process improvement a different role than that intended by Davenport. Where Davenport views process improvement as a short-term complement to process innovation, I have conceived of it in the maps which follow as a potential follow on to process innovation. That is, while it is the design team that is charged with achieving dramatic breakthroughs in the process, such innovation can be viewed as setting the stage for ongoing process improvement. In retrospect, it would have been more in keeping with my intent to capture Davenport's view of things to drop my interpretation in favor of the one he so clearly sets forth (e.g., on pp. 140-41). However, I will allow my (questionable) view of process improvement to stand as a record of my original reading of the text. As it turns out, this does not prove a critical pitfall for my analysis in the end, because I ultimately restrict the scope of my map of process innovation such that the process improvement activity is eliminated from this analysis.
9.2.2 Resource Flow Graph
Our goal at this point is to move from the simple activity decomposition in figure 9.1 to an enumeration of the key dependencies in PROCESS INNOVATION. Given our stance that dependencies can be viewed as resource-based, a first step in this direction is to construct a resource flow graph that captures the flow of resources among the activities, as described in section 9.1.2.2, and thereby facilitates identifying dependencies among those activities. The approach I take here is to identify inputs and outputs associated with each activity in figure 9.1. This done, I am able to construct the resource flow graph shown in figure 9.2, including both activities (indicated by rectangles in figure 9.2) and resources[3] (indicated by circles). This is done by adding flows from an activity to all resources that are outputs of that activity, and a flow from each resource to the activities where it is an input.
Figure 9.2: Resource flow diagram for process innovation
A first step toward a dependency diagram is to simplify the resource flow graph by generalizing and aggregating its components, as shown in figure 9.3:One test for a good aggregation is that one can imagine alternative decompositions for the aggregate activity or resource:
The current decomposition of DEFINE PROBLEM is an example of identifying a problem by reviewing a preexisting list of potential problems (in this case in the form of list of existing processes). This is just one particular example of the more general notion of DEFINE PROBLEM. Indeed, this is one possible specialization of DEFINE PROBLEM.
Similarly the current decomposition of ESTABLISH REQUIREMENTS is but one possible implementation of this process (i.e., develop requirements from analysis of strategic doctrine).One technique for identifying potential resource aggregations is to look at resources that can be viewed as parts or kinds of a more general resource. Thus in figure 9.3 we have identified the list of impact categories and the list of generic applications as two strategies available in the design process and have aggregated them accordingly into existing strategies.
Figure 9.3: Simplification of process innovation
Figure 9.4 results from abstracting away the decomposition of the aggregates we introduced in figure 9.3. While this diagram highlights important features of Davenport's approach to process innovation and does so in a somewhat more general (and hence reusable) form, the diagram is still so complex that some of the key features and trade-offs of this approach are not easily seen.
Figure 9.4: Design using solution strategies
9.2.3 Dependency Diagram
To address this issue, we move from a resource flow graph to a dependency diagram in which the focus shifts to just those flows that seem to be the critical dependencies. As mentioned earlier, we categorize dependencies into three types: flow, sharing, and fit. Notice that there is an isomorphism between a resource flow and a flow dependency. This suggests that one could produce a dependency diagram simply by replacing each resource flow with a flow dependency. There are, however, a few issues to deal with here:
Flows into a common resource may indicate a fit dependency.
Flows out of a common resource may indicate a sharing dependency.
It is not obvious what to do with flows into or out of an external resource. One might replace such a flow with a dependency involving an ''external''or ''boundary''activity. I would argue that one could also suppress external resources in certain cases as discussed below.
Unlike a resource flow graph that typically represents all the flows involving resources important to the activities shown, the dependency diagram represents only those dependencies that are important to the process; these critical dependencies correspond to a subset of the flows in the corresponding resource flow graph.Note that in this sense a dependency diagram represents a further abstraction and hence simplification of a resource flow graph, one must bear in mind that the ''importance''of a dependency is relative to the point of view and judgment of the process observer. One might imagine starting with all the flow, sharing, and fit dependencies which are implicit in the resource flow graph (see items one and two above), and then removing those dependencies that are unimportant to the observer. A dependency might be unimportant for several reasons:
Its effect on the process outcomes of interest is insignificant.
It has a significant effect but is easily managed.
It has a significant effect and raises nontrivial issues, but the problem has been solved (at least to the satisfaction of the process observer) and has been excluded from analysis.
As suggested in item 3 above, a special case of suppressing dependencies exists when there are external resource flows. It is easy to see that when an external resource flows to just a single activity in the process, it may be due to a local coordination issue that can be considered nonproblematic at the level of the process as a whole.Figure 9.5 is an annotated version of figure 9.4, which shows how these issues are dealt with in the current analysis to produce the dependency diagram shown in figure 9.6.
Figure 9.5: Transforming a resource flow graph into a dependency diagram
The numbered annotations in figure 9.5 identify elements of the resource flow diagram that are to be suppressed in the dependency diagram. The remaining resource flows are converted to flow dependencies, resulting in figure 9.6. Here is a brief discussion of the reasoning behind each annotation in figure 9.5:
Figure 9.6: First attempt at a dependency diagram
Two flows in this diagram can be viewed as part of the coordination mechanisms used to manage the dependencies associated with other flows in the diagram: (a) the flow of problem definition to UNDERSTAND PROBLEM CONTEXT is employed to manage the usability (in this case, primarily relevance) of the flow of design context from UNDERSTAND PROBLEM CONTEXT to DESIGN. (b) the flow of design requirements to IDENTIFY SOLUTION STRATEGIES is similarly used to manage the usability (relevance) of the flow of selected strategies to DESIGN. Thus, when we move to a dependency diagram, these two flows are encompassed by the dependencies of which they are a part.
The two inputs to IDENTIFY SOLUTION STRATEGIES are tagged as local resources because they are used only by that activity in this process and the coordination of these flows is not the focus of our analysis, which centers on the design step. Thus we do not include dependencies for these resources in the dependency diagram, and they are therefore omitted in figure 9.6.
Note that while Davenport acknowledges the importance of process improvement, this is more or less outside the scope of his analysis. This is clear for several reasons:
He does not include a process improvement step in his representation of process innovation. (Davenport, p. 25, fig. I.2)
He identifies process improvement as an essential adjunct to process innovation (the focus of his book) and as clearly distinct from it. (Davenport, pp. 140-41)
His discussion of process improvement mainly directs the reader to existing methods rather than presenting novel techniques in the book. (Davenport, p. 139) In contrast, Davenport's discussion of process innovation is clearly an original contribution rather than a recapitulation of existing work.
Once the elements noted above are suppressed and the remaining flows mapped as dependencies, one obtains the diagram in figure 9.6.
In reviewing figure 9.6, I make the following observations:
The three intersecting flow dependencies could be represented as a single fit dependency. Not only is this a simpler representation, but it is consistent with the two flows we abstracted away in figure 9.5. In retrospect, these flows can be understood as coordinating the interaction among the flow dependencies in figure 9.6, as they flow between DEFINE PROBLEM and ESTABLISH REQUIREMENTS and the other two flows. Indeed, one implication of the fit dependency is that more such coordination may exist (although I did not surface such flows in the preliminary analysis above). Stating this as a modeling heuristic, we might say that if one has a number of flow dependencies involving the same consumer and with lots of cross-connections of a secondary nature (especially coordination flows), there is a strong implication that it will be useful to model this as a fit dependency.
If, for the moment, we assume that it is useful to explore the possibility of symmetry as a modeling heuristic, we can identify at least four ways to make the diagram symmetric:
Declare DEFINE PROBLEM to be outside the scope of our analysis.
Aggregate Define problem and Establish requirements.
Make the case that DEFINE PROBLEM is a fourth parallel flow in the fit dependency.
Add two additional flows: from Define problem to both Understand problem context and Identify solution strategies.
I adopt the second of these strategies, and argue that ESTABLISH REQUIREMENTS can be thought of as a part of a larger notion of problem definition. That is, requirements can be thought of as an extension of a problem definition and hence part of that definition. Thus we can aggregate DEFINE PROBLEM (in the narrower sense in which we have used it here) with ESTABLISH REQUIREMENTS. The resulting aggregation can be thought of as DEFINE PROBLEM USING REQUIREMENTS, which can be further generalized to DEFINE PROBLEM (in a larger sense of that term).This aggregation illustrates an issue that frequently arises in this kind of process modeling: the same term (here ''Define problem'') takes on multiple meanings during our analysis. I argue that this ''overloading''of terminology is inevitable and points to the confusion that can occur when a process is described using ordinary language. By keeping track of both the evolution of the process model and the context the model provides for each term, we can untangle the multiple meanings and keep them straight. Thus this model as it appears in figure 9.7 links back to the context that distinguishes this larger sense of DEFINE PROBLEM from the narrower sense employed in earlier diagrams.
Note that we could as easily have explored the other options for introducing symmetry. The issue here is not which option is correct but which options are plausible, and of these, which are most useful. Having chosen an approach, the resulting simplified dependency diagram can be seen in figure 9.7.
Figure 9.7: Symmetric dependency diagram
This diagram seems to argue for the virtues of the symmetry heuristic.[4] One could argue that given two diagrams that take the same point of view and express the same process, the one that is simpler (in this case more symmetric) is often likely to be the more useful diagram because it is easier to understand and easier to analyze.
9.2.4 Analysis
This dependency diagram emphasizes the inputs to the design process and the fit among them. This seems to be a key insight at the core of Davenport's account of process innovation: To manage and cultivate the innovation process, attend to the critical inputs to the design activity. As Davenport says in his opening paragraph in the design chapter: ''Ironically, there is less to say about the design phase of process innovation than about the activities that lead up to it''(Davenport 1993, p. 153). Thus the focus here is on identifying the critical inputs to the design step and figuring out how to manage their usability and fit.
One implication of the presence of this fit dependency in the innovation process is the potential importance of managing the interconnections among the inputs. For example, consider the activity UNDERSTAND PROBLEM CONTEXT. This is the activity that represents mapping the current state of the organization, including the existing process. In practice, this activity can very easily get disconnected from the design process it is embedded in and become an independent exercise that generates so much data as to become practically useless as a resource to support design. The value of context is in danger of being outweighed by the burden of sorting through the massively complex process maps.In coordination terms, the issue here is the usability of the flow of context information. One approach that is often used to manage this kind of flow is for the receiver to filter out what is not useful. Note that this approach is doubly expensive, as we have the cost of compiling the information and then the cost of throwing extraneous or low-value information away. One solution proposed to this costly information flow is to avoid mapping the as-is process. However, as Davenport points out, this has the disadvantage of losing lots of important context.[1]The process names are mostly directly quoted from Davenport. I have in some places modified the names to conform with the Process Handbook's verb-noun format. Where I depart from Davenport's terminology I will note this explicitly. Unless otherwise indicated, all references to ''Davenport''refer to (Davenport 1993).[2]Davenport mentions IMPROVE PROCESS in the context of his discussion of understanding existing processes, but he does not include it in his original diagram. I include it at the outset as a potential additional activity, but as it turns out I ultimately consider it to be outside the scope of this analysis.[3]Resources are not an explicit component of Davenport's process diagrams and are thus the result of my own analysis.[4]My thanks to Tom Malone for pointing out to me the usefulness of symmetry in this context.
