لطفا منتظر باشید ...
section 9.2, this book does not provide an explicit process description of reengineering. As a consequence the analysis involves additional steps at the outset to identify the activities and resources that comprise the reengineering design process.
9.3.1 Review of the Text
I begin by reviewing the text and flagging material that seems to indicate components of the process or otherwise seems especially important to my understanding of the process. Having extracted these relevant chunks of text from the book, the next step is to begin to make sense of this material as a process. What follows is an analysis very similar to that employed for Davenport (1993): I will identify the resource flows involved and then create a resource flow graph and a dependency map.
9.3.2 Resource Flow Graph
Having identified both the activities and the resources from a preliminary analysis of the text, the next step is to represent all these components on a single diagram (figure 9.8). We start by just listing the resources and activities so that later we can associate them with each other.
Figure 9.8: Identify activities and resources
In associating resources with particular activities, I found it useful to make certain changes in both the list of activities and the list of resources depicted in figure 9.8:
Combine SELECT PROCESSES and PRIORITIZE PROCESSES into a single compound step. Selection is a kind of prioritization, and given finite resources at hand, prioritization is a form of selection. At this level of analysis it is useful to consider the two activities as one.
Create a new activity IMPLEMENT REDESIGNED PROCESS.MAKE CASE FOR CHANGE would appear to be about generating support for the redesigned process and is thus a part of implementation, rather than the initial design process. The presence of MAKE CASE FOR CHANGE thus only makes sense if this implementation activity also appears in the process map.
Add activity UNDERSTAND REENGINEERING. This is done to clarify that the resource heuristics arises in part from ongoing efforts to understand reengineering, for example, as described in the Hammer and Champy text. Hammer and Champy seem to expect these generic reengineering heuristics arise from efforts such as theirs and to be primarily provided as external resources to a given reengineering effort. We include this activity in our flow graph, however, in order to tell a coherent story.
Replace the resource process name with the more generic resource identified processes. Naming a process can be thought of as one part of this identification activity. I have introduced some additional resources suggested by the function of activities (e.g., the output of SELECT PROCESSES is, naturally, selected processes).
Note that the resource context is implied by activities that employ the verbs IDENTIFY (context is the background from which the things to be identified are distinguished), UNDERSTAND (implies a rich set of inputs, i.e., context), and RETHINK (similar to UNDERSTAND ).
Figure 9.9 is the resource flow graph I developed based on the analysis above. Note that I did not bother neatening up the layout, since I will be refining this diagram further momentarily.
Figure 9.9: Preliminary resource flow graph
As with Davenport above, I now create an abstraction of this process based on the following observations:
Process map, which is not yet connected in figure 9.9, turns out (upon further review of the text) to be an output from IDENTIFY BUSINESS PROCESSES and an input to SELECT & PRIORITIZE. It seems reasonable to view process map as subsuming the identified processes resource, so I simply replace the latter with the former.
As in my Davenport analysis, for purposes of coordination analysis one can absorb external resources that have only one internal consumer into the description of that subactivity. Thus I can remove the explicit representation of technological capabilities and process inputs and outputs. Note the potential loss of information concerning possible additional activities that might use these resources. In the current analysis, however, the gain in simplicity seems to outweigh this loss. Similarly I can remove the two inputs to SELECT & PRIORITIZE.
I also propose to combine UNDERSTAND REENGINEERING with UNDERSTAND IT CAPABILITIES since both are about identifying relevant heuristics. Note that this diminishes the emphasis that Hammer and Champy place on IT and also the distinction between the heuristics that Hammer and Champy propose as a kind of universal set for reengineering and the IT heuristics that they expect a business to identify as part of its own analysis. This seems like a useful abstraction in that it emphasizes the core issue here that is obtaining a relevant set of heuristics to push the design process in the direction of radical and effective change. The abstraction also introduces the possibility of other approaches to obtaining these heuristics.
I was concerned at one point in this analysis that the relationship between UNDERSTAND EXISTING PROCESSES and SELECT & PRIORITIZE PROCESSES TO BE REENGINEERED seems to restrict the understanding effort to the processes that are selected, which makes the diagram more complex. However, one can view this as an issue of coordination for effciency, and apply resources to those processes that are most critical to the reengineering effort. This issue can be addressed in the dependency diagram, where it surfaces in the form of a fit dependency, thus allowing us to abstract the complexity away from the current diagram.
I have simplified the title SELECT & PRIORITIZE PROCESSES TO BE REENGINEERED to PRIORITIZE PROCESSES TO BE REENGINEERED. As I argued above, ''prioritize''can stand in here for ''select''as well.Figure 9.10 represents the implications of these changes for the resource flow graph, while figure 9.11 shows the abstracted resource flow graph that results. Note that when one abstracts away individual heuristics, what remains seems almost a generic example of heuristic design rather than something particular to reengineering. As I suggest below, this has important implications for understanding the place of reengineering in the history of organizational design.
Figure 9.10: Simplifying the resource flow graph
9.3.3 Dependency Diagram
In examining this resource flow graph, we can identify the following key dependencies (among others) and some of their implications for process design:
Shared context. Are all reengineering participants invoking the same context for their deliberations? How do they resolve differences in framework and perspective? Clearly, the reengineering team meetings serve as one key coordination mechanism for managing this dependency.
Process selection flow. Early decisions about the process map have a huge influence on the eventual focus of reengineering. This suggests the value of thinking ''out of the box''early in the reengineering effort. The process map enables but it also confines thinking. This flow dependency suggests we should look at the role that process maps might play in reengineering success and failure. It would be interesting to consider the extent to which additional reengineering opportunities can be enabled by more creative map making.
Fit between prioritized processes, insights, and heuristics. This dependency suggests that problems may result when too broad or too narrow a ''relevance filter''is placed on the heuristic and insight streams. It might be useful to consider the role that heuristics and insights might play in the selection of reengineering projects, as well as the role that they might play in process mapping.The full set of dependencies implied by figure 9.11 is shown in figure 9.12.
Figure 9.11: Simplification of reengineered business processes
Figure 9.12: First pass at a dependency diagram
Having thus arrived at a preliminary dependency diagram, there are several simplifications that we can make:
Aggregate the two processes IDENTIFY BUSINESS PROCESSES and PRIORITIZE PROCESSES TO BE REENGINEERED to form the process IDENTIFY PROCESSES TO BE REENGINEERED. This latter name implies both identification and prioritization of processes. Note that the flow dependency between the two original activities is also absorbed into the aggregation.
Restrict scope of the diagram to exclude the context sharing dependency. This restriction can be thought of as a narrowing of attention to a subset of the dependency issues (we could always consider including this context dependency in a separate analysis). Note that this restriction in scope works here because UNDERSTAND CONTEXT is on the periphery of the dependency diagram.
Absorb the activity MAKE CASE FOR CHANGE into IMPLEMENT REDESIGNED PROCESS. Justification: MAKE CASE FOR CHANGE, as described by Hammer and Champy, is not a part of the design process but rather the process by which such a design is to be implemented in the organization.These changes result in the simplified diagram of figure 9.13.[6]
Figure 9.13: Simplified dependency diagram
9.3.4 Discussion
While the primary purpose of these examples is to illustrate the modeling process, I will briefly explore some implications of this dependency diagram. Note that far more becomes possible when we consider a dependency diagram in the broader context of the design taxonomy, but some insight can also be gained by considering it on its own terms.The Power of Abstraction This dependency diagram, and the process that produced it, make a particularly nice illustration of the power of abstraction in this approach. In a sense the entire text has been reduced through a series of abstractions to two major dependencies. Note, however, that much of the value of this abstraction lies in its links back to the context established by the original text and the series of more complex maps developed during this analysis. In a sense the dependency diagram becomes not only a map of business process reengineering but a kind of index to the modeling process which produced this map.
How Are These Dependencies Coordinated? While the authors do address various aspects of the two dependencies we have identified, they are not a central concern of the text. It is, however, possible to construct an account of how the authors address (at least implicitly) these coordination issues.COORDINATING THE FIT DEPENDENCY By insisting that UNDERSTAND EXISTING DESIGN should produce insights rather than details, Hammer and Champy (1993, p. 129) have provided a mechanism for managing the fit between choice of process, choice of design heuristics, and understanding of existing design. This approach partially manages the fit dependency by producing a much more manageable and reusable set of outputs from UNDERSTAND EXISTING DESIGN. While this approach is arguably inadequate by itself, the authors effectively augment this mechanism by insisting that this be a centralized design effort. That is, the work is to be carried out by a reengineering team that, in the scenario provided in the book, sits down in a room together and works through all the issues. This kind of centralization provides a plausible strategy for managing the fit dependency at the center of figure 9.13, by assignment of all four activities[7] involved in that dependency to a single actor or team of actors. Given this approach, the reengineering meeting becomes the single crucial coordination mechanism for managing this fit dependency. This implies that effective coordination of this dependency comes to depend heavily on the quality of the team and the effectiveness of its meetings. This introduces a potential weak link in the reengineering process, and a source of variability in outcomes that may be hard to manage.
COORDINATING THE FLOW DEPENDENCY For a method whose authors themselves estimate a failure rate of 50 to 70 percent (Hammer and Champy, p. 200), one would expect the flow dependency between design and implementation to be a critical one. Coordination of this flow is further complicated by the large number of actors necessarily involved in the actual implementation of reengineering in a large organization. Interestingly the authors do not elaborate much on this issue. The aspect of this flow that is most directly addressed is the need to make the case for change. While this may be important, it does not seem to be suffcient for managing the design-implementation flow.In defense of the approach taken in the text, however, MAKING THE CASE FOR CHANGE does provide some support for coordinating this flow dependency. The more the entire organization shares the vision of the reengineering team, the more likely coordination of the design-implementation flow is going to work. The entire organization becomes in effect an extension of the team and is placed in a position to coordinate and effect the changes from within.This implicit coordination of the design-implementation flow would presumably be more likely to succeed where a new process is closely aligned with the existing process, in that intuitions about how the existing process is implemented are more likely to be relevant to the implementation of the new process. In the case of reengineering, however, we have radical changes which may be entirely confusing, mysterious, and at odds with how things are done now, and thus in the absence of an explicit coordination mechanism one would expect implementation failure to be far more likely.POSSIBLE COORDINATION MECHANISM: USE TOTAL QUALITY MANAGEMENT TO COORDINATE THE DESIGN-IMPLEMENTATION FLOW Hammer and Champy identified the complementarity between total quality management (TQM) and reengineering, where TQM refers to the technique for systematic process improvement pioneered by W. Edwards Deming and brought to fruition by Japanese manufacturers (Shiba et al. 1993). Where reengineering is about radical change, TQM is about incremental improvement. The complementarity that Hammer and Champy proposed is a kind of punctuated equilibrium model (Gersick 1991) in which reengineering is followed by an extended period of continuous improvement (Hammer and Champy 1993, p. 219). Can we imagine an approach in which TQM is used to manage the flow dependency between reengineering design and reengineering implementation? In this scenario TQM would become a way to iteratively correct any problems during the implementation phase. Presumably this might happen naturally in an organization in which TQM is in place for process implementation, provided that the obvious connection is made.[5]Unless otherwise noted, all references to ''Hammer and Champy''refer to (Hammer and Champy 1993).[6]Note that I also revise dependency descriptions to incorporate more information about the nature of the dependencies (something that would otherwise be lost when moving from the resource ?ow graph to the dependency diagram).[7]Identify processes to be reengineered, Identify design heuristics, Understand existing design, and Rethink fundamentally and redesign radically.
