| author(s): | Ashok Dandekar, Dewayne E. Perry, Lawrence G. Votta |
| title: | A Study in Process Simplification |
| organisation(s): | Bell Laboratories, Fujitsu Network Transmission System |
The customer documentation process subsystem represents a substantial subset of the entire process system. From this subset we chose a smaller subset of the core processes to look at more closely (because they represented the production of 90% of the document artifacts) and from that set finally selected the particular process for this study. The simplification team consisted of process executors (the people writing the documentation), members of the quality team, and members of research.
2. Understanding the Processes
Watts Humphrey distinguished between processes as described, processes as executed, and processes as they ought to be. To determine the last of these, we need to understand the first two.
The entire set of processes governing the production of this product from first customer contact to customer support are defined in electronic form and available as an on-line methodology. We augmented it with what we came to call ``the big picture'' of the documentation subsystem to visualize its interconnections with the rest of the entire process system and its intraconnections among the various processes that make up this subsystem.
To understand the process as executed we investigated the organizational context with its geographical and management considerations, the means of inter-location interactions, and the computing equipment and environments. The discussion about cost factors included issues of personnel and resource costs, costs of the context (computing and communications), process intervals, and process and artifact costs. The process modeling discussions covered issues about roles, process and artifact structure, and process interfaces.
In Figure 1 we have the initial process flowchart. In comparing this flowchart with that in Figure 2 , you will notice that there are more iterations and a more complex control flow in the initial process.
3. Analyses of the Trial Process
For our simplifications and improvements, we used primarily three different kinds of analyses: value added analysis, time usage analysis, and analysis of alternatives.
3.1 Value Added Analysis
One of the first problems faced in trying to simplify a process is that of what to use as criteria for choosing what to keep and what to cut. Harrington's advice seemed to be a good place to start: first identify each activity as having either customer value, business value or no value. Then maximize customer added value, minimize business added value, and eliminate those activities which add no value. Activities that are required to maintain the product are considered to be of business value.
Using this approach we classified 20% of the activities as adding customer value, 30% of the activities as adding business value, and the remaining 50% as adding no value.
Once the notion of customer added value was proposed as the most important aspect in the design of the processes, the thinking of the simplification team changed about the value of the business-oriented decisions that had been made. Early configuration control did not add anything to the value of the documents for the customer and, apparently, only caused a large amount of extra work.
3.2 Time Usage Analysis
One of the primary problems in large-scale software development is the time spent waiting for resources, responses, meetings, etc. To this end, we included two things in the data we needed to analyze the process: estimated race (the race time is the time that would be spent if there were no delays of any kind -- that is, it is the actual time spent) and elapse times, and estimated percentages of time spent in various paths in the process (that is the percentage of time taking one path over another out of the decision points).
Using the insights from the value added analysis exercise, we decided to look at the part of the process where there was the most rework: the private, manual and production builds We did a study to grade how successful these three build processes were. Once they succeed, they are then passed on to production. Unfortunately, production builds have the same failure and success rates (one-third each). The reason for this is that the manual builds (as well as the private builds) are done in a non-production context -- the manual builds succeeded but in the wrong contexts.
So nothing but extra work was actually gained from the manual builds. 3.3 Alternatives Analysis
Alternative solutions need to be analyzed to make sure that they will be better than the steps they replace. Given that we eliminate the manual builds, we have two choices as to where to put the artifacts under configuration control: before the private builds or before the production builds. The trial showed that chapter optimization was very expensive under configuration control -- a factor of two more expensive.
4. Results
On the basis of our various analyses, the simplification team thoroughly scrutinized the current process as it is executed and proposed a list of improvements. The accumulated effect of these simplifications and improvements amount to a significant savings in terms of cost (20%) and both race (20%) and elapsed (40%) intervals. Moreover, the number of activities was reduced by 30.
The improvements may be characterized as follows:
The resulting process flowchart illustrates the effect of the simplification effort (see figure 2 ). Note how much simpler the control flow is and that there are fewer iterations.
5. Some of the Lessons Learned
Effective process simplification requires a deep understanding of the processes and their relevant domains. We chose those executing the processes as the suppliers of this knowledge rather than those responsible for the process descriptions. This strategy worked effectively.
Iterations in processes that span multiple locations can be very expensive in both actual time and elapse time costs. There are time lags, even when electronic means are used (especially when the multiple locations span different time zones or continents). Moreover, inter-location communication is still relatively primitive when high-bandwidth interactions are needed.
Harrington's advice of emphasizing customer added value, minimizing business added value and removing no added value was instrumental in generating several key insights into the fundamental nature of the process and why so much rework was being done.
Estimates and measurements of resource usage, and time and effort cost studies are necessary preconditions to any simplification or improvement effort.
No single simplification produced a major result, rather the accumulation of modest simplifications in the right places resulted in a significant reduction in time and cost. These modest improvements resulted in removing some of the accidental debris and enabled the process executors to focus on the essential problems of artifact production.
To gain the maximum benefits from simplification and improvement efforts, the focus should be at the process system level where global improvements will have a more far reaching effect than they do at the individual process level where improvements have only local effects.
| ISPA Homepage - This information last updated October 1997 |
| Copyright © 1996-7. All rights reserved. |