Tools for analyzing and constructing agility, R Dove

Tags: Agility Forum, enterprise, Paradigm Shift International, scope, requirements, attributes, Plug Compatibility, Domains, agile enterprise, competitiveness issues, Agile Production Focus Group, accounting system, system integration, system integrators, fundamental characteristics, software technology, client-server architecture, production control system, Client-Server, software change, systems architecture, Agile Operations Focus Group, Daniel Jones, xxxxxxxxxxxxxxxx, xxxxxxxxxxxxxxxxxxxx, architecture, systems concepts, agile production, Strategic Analysis Working Group, xxxxxxxxxxxxxxxxx, Self Organization, fundamental attributes, Lehigh University, understanding, production line, qualitative analysis, Craft production, Martin Marietta, mass-production, Martin Marietta Energy Systems, incremental development, lean production, unanticipated change, principal dimensions, information automation systems, Watervliet Arsenal, software systems, interacting systems, integrated software system, Information Automation, Change Relationships, change causes, integrated software systems
Content: Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Tools for Analyzing and Constructing Agility
Abstract: This paper discusses an analytical and structural picture of agile enterprise, with a focus on the production area. analytical tools will be described that are useful in formulating, prioritizing, and evaluating agile strategies.
Rick Dove Agility Forum 200 W. Packer Avenue Bethlehem, PA 18015 [email protected], www,
Rick Dove is Director of Strategic Analysis for the Agility Forum and Chairman and CEO of Paradigm Shift International, a company specializing in competitiveness research and analysis. He co-chaired the 21st Century Manufacturing Enterprise Strategy project that identified Agility as a key competitive requirement. He has organized and chaired various consortia, commercial and DoD initiatives and workshops in agile production research, development, and technology transfer. He chairs the Strategic Analysis Working Group and the Agile Operations Focus Group at the Agility Forum. He has had senior executive and founding positions at companies in the computer, office products, systems integration, software, and food processing industries. Since 1985 he has focused on competitiveness issues.
Agile Attributes
xx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx
xxxxxxxxRxxexsxxpxoxxnxsxxex Ability Profile xx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCxhange Domains
xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx----------------------------
xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxx
xx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxx
xx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx
xx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx
Structural Alternatives
o oo o o oooo oo -o--o--o--o-
Features xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
Advantages xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxEx nterxxpxrxxisxxexxxRxxexxsxpxxoxxnxxsxxexxAxxxbxixlxixtxyxxTMxxxxProfile
xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
Creation xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxCxaxpxaxcxityxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxCxxapxaxbxixlitxyxxxxxxxxxxxxxxx
Org Structure Human Res Op Procedures Info Automation Cont Automation Facility
Distribution supply chain Changeover/Setup Production Equip production process Material Move/Mgmnt
Org Structure Human Res Op Procedures Info Automation Cont Automation Facility
Distribution Supply Chain Changeover/Setup Production Equip Production Process Material Move/Mgmnt
© 1994 Rick Dove
Figure 1 Republished by Agility Forum, PA96-01, Jan 1996
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Tools for Analyzing and Constructing Agility
Rick Dove [email protected]
What precisely is agility? How do we measure it? How do we know when we have it? Is there a simple metric or index? How can we develop both analytical and intuitive understandings of agileness in our operating environments? The investigation of these questions continues in various forums, with some answers and tools beginning to take useful shape.
Early discussions about agility have exhibited a great deal of confusion, along with a constant difficulty in separating agile from fast and agile from flexible. Many companies are preoccupied and committed with lean and TQM programs that seem in competition with yet another perspective. Adding to the confusion are proponents from both the agile and the lean camps that would collect all the best practices under their favorite banner; willing us to believe that each is a comprehensive answer to all the competitiveness issues.
Amidst all this promise and all this confusion lie some real pearls.
Communicating basic concepts is the first order of business. To this end we can adopt a working definition of agility as: the ability to thrive in an environment of continuous and unpredictable change. The focal point here is "change" - the ability to initiate it, and the ability to respond to it. "Thrive" is a key word because it implies both long term success, as opposed to a lucky response, and because it implies wielding agility both as an offensive as well as a defensive capability. "Continuous and unpredictable" underscores the new long-term picture but, most importantly, distinguishes agility from mere flexibility, enabling successful change even when there is little advance notice and no prior expectation.
The Domains of Change
The agile paradigm is concerned principally with unpredictable change; but that is a large and overly general subject area. If we are to analyze the kinds of change impacting an enterprise, and analyze that enterprise's ability to respond, then we need to decompose change into its various and interesting domains. To this end the nature of change was investigated by the Agile Production Focus Group, and over the course of a twelve month trial-and-error modeling process eight interesting domains emerged.
This decomposition into the domains of change was undertaken with an eye to the operational aspects of the production environment. Our interest of course is "unpredictable" change; and consequently does not address routine change, such as the changing of a production shift day-in and day-out, or the normal functioning of an automatic tool changer in an FMS.
Table 1: Eight Agile Change Domains
Creation Capacity Capability Reconfiguration Migration
Build something new. Increase/decrease existing resource mix. Add/delete resource types. Change relationships among modules. Event-based change of fundamental concepts.
Agile adds new domains above to traditional lean domains below
Performance Improvement Recovery
Real-time operating surprise. Continuous, incremental upgrade. Reincorporate corrected failures or alternatives.
Building a model of "change domains" gives us a tool for analyzing potential agile characteristics. Table 2 shows the eight change domains and simple examples of how they might manifest themselves in four different areas. Under actual analytical conditions there is rarely a single statement made under each domain. These change domains illuminate a key part of the answer to the question: What does the agile concept bring that's new? Lean deals very directly with issues related to the final three change domains: Performance, Improvement, and Recovery. Agile includes these lean areas as well as five new change domains: Creation, Capacity, Capability, Reconfiguration, and Migration.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 1
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Table 2: The Eight Change Domains with Four Simple Examples
Domain Creation Capacity Capability Reconfiguration Migration Performance Improvement Recovery
Production Build new production plant. Add similar production equipment. Add different production equipment. Convert line to different purpose. Convert to bid-based cellular scheduling. Setup/changeover for unscheduled part. Daily control system upgrades. Return broken station to service.
Organizational Structure Build new team with new people. Add more people with similar skills to team. Add more people with different skills to team. Abolish old teams and reform new teams. Institute self-direction in work teams. Function when team members absent. Continuous learning of teamwork skills. Fix dysfunction in team structure.
Information Automation Build information access & email infrastructure. Add acquired company to network. Add access to new database. Change network structure. Full access to outside databases & email. Video traffic swamps network. Personal agents get smarter. Route around bad network node.
human resources Hire all new people for new facility. Increase/decrease employee head count. Add people with new and different skills. Adjust dental vs medical benefit mix. Institute on-the-job continuous learning. Deal with a union wildcat work-shutdown. Start monthly company communication sessions. Return to EEOC compliance.
The change domains have been tested in a variety of real applications. Table 3 shows one of the many profiles developed by
Paradigm Shift International in a strategic analysis
of the semiconductor wafer fabrication industry. A
portion of the study examined the perceptions of manufacturing execution software (MES) vendors
Table 3: Change Domain Modes - Semiconductor wafer processing
relative to industry dynamics, went on to develop profiles of specific shop-floor control systems, and eventually explored the dynamics affecting process
Creation (Build New Capability)
Building a new wafer fabrication facility. Developing equipment characterization models. Developing integrated process models.
equipment changes. Table 3 is a truncated version of an actual profile that was developed - which attempted to show the dynamics that shop-floor control systems should facilitate as a matter of
Capacity (+/- Same Capability)
More equipment for high market demand and/or added product variations. Add/extend shifts to meet surge and increased demand.
course. The Four Dimensions of Agility
Capability (+/- Different Capability)
Product, e.g., DRAM to CPU to ASIC. Chemistry, e.g., NMOS to CMOS to BiCMOS to SOI. Process re-characterization for new products.
Though we are still in an early stage of understanding, one thing has become clear already: an agile enterprise must have broad change capability that is in balance across multiple dimensions. We come to understand how important the "balance" part is when we test candidate examples against extreme conditions. Would you call it agile if a short-notice change was completed in the time required but at a cost that eventually bankrupted the company? Or if the changed environment thereafter required the special wizardry and constant attention of a specific employee to keep it operational? Is it agile if the change is virtually free and painless but out-ofsynch with market opportunity timing? Is it agile if
Reconfiguration (Change Relationships)
Selective equipment upgrade. Mix change causes plant re-layout. .
Migration (Fundamental, Event-Based)
To "brilliant" machines. Geometry, e.g., .8µ to .5µ to .35µ to ..... Wafer size, e.g., 8" to 12" to .....
Performance (Operating Surprise)
Hot-lot expediting; test lots. Improperly processed batch. Equipment failure.
Improvement (Incremental, Continuous)
Yield. Cycle time. Equipment utilization.
Recovery (Return to Service)
Utilizing partially inoperable equipment. Expediting a failed-batch replacement.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 2
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
it can readily accommodate a broad category of change that is no longer needed, or too narrow for the latest requirements?
These questions help us tease apart this thing called agility into four principal dimensions: cost, time, quality, and scope. To be agile, there is a requirement to "score" well in all four dimensions. Scoring is not an area we are yet able to address against a universal yardstick. Instead, you will find here a subjective approach to quantitative scoring that is used to focus a qualitative analysis.
An operation may successfully accommodate many changes without all dimensions being above the agile threshold. These kinds of changes don't represent the full range required for thriving on the unpredictable, and can provide a very false sense of security. A few successes at narrow-band change can lull an operation into thinking it is agile even when all dimensions have not been stressed.
You can change virtually anything if cost is no object. However, if your response to change costs too much relative to your competitor's costs, there will be a steady erosion of working capital, or at least a higher tax on shareholder profits. Change at any cost is not viable, else we need not restructure anything - we can simply throw out the old and buy a new capability; assuming, of course, that we can bring something new to the operational level quick enough.
But the cost of change alone does not provide a metric for agility. Completing a change in a timely manner is the only effective way to respond at all. Thus, time of change becomes an equally important factor, especially in an environment characterized by continuous and unanticipated change.
Quick, economical change, however, is still not a sufficient profile for agility. If after change the result is balanced on the head of a pin and requires 24-hour-a-day baby-sitting to remain functional the change accommodation was insufficiently robust. If we cut corners in the process of changing in order to do it quickly and economically, we end up with a fragile, spit-and-bailing-wire result.
Finally, something is considered to be agile precisely because it is prepared to thrive on change. But how much change? The dimension of scope addresses this question. Scope is the principal difference between flexibility and agility. Flexibility is that characteristic you fix at specification time. It is the planned response to anticipated contingencies. Agility, on the other hand, repostures the fundamental approach in order to minimize the inhibitions to change in any direction. Being agile is to recognize that the frequency of required change has accelerated to the point where contingency lists are outdated as soon as the ink dries. At the heart of scope is the architectural issue: rather than build something that anticipates a defined range of requirements, or ten or twelve contingencies, build it so it can be deconstructed and reconstructed as needed.
Thus, for some element of an enterprise to be agile it must have a balanced response-to-change capability across the four dimensions of cost, time, robustness, and scope.
The four agility dimensions of cost, time, robustness, and scope form the basis for a powerful profiling tool. We could usefully explore the use of this tool applied to examples in three enterprise areas: people, product, and process. This is not an attempt to be comprehensive - for we might also inquire into the agility of an enterprise strategy, or the agility of enterprise business relationships, just to name two other categories. It is worth noting that evaluating a product's agility is an exercise that can be applied to a piece of production equipment as well. After all, a piece of production equipment is just a product bought for, and employed in, the manufacturing process.
People Product Process
Table 4: Four Balanced Dimensions - Three Arbitrary Categories
Cost (Evaluation) (Evaluation) (Evaluation)
Time (Evaluation) (Evaluation) (Evaluation)
Robustness (Evaluation) (Evaluation) (Evaluation)
Scope (Evaluation) (Evaluation) (Evaluation)
The entries in this matrix can be both quantitative and qualitative. The purpose of the matrix is to structure an analytical discussion that focuses on the dynamics of change for a specific area under scrutiny. Before seeing this tool applied to an example, however, a final note on balance is in order.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 3
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
When is an enterprise sufficiently agile to be called an agile enterprise? Perhaps when adequate agility exists in each and every one of the necessary enterprise system structures. Note that we are suggesting that "all" necessary structures must be agile in order for the enterprise to be agile. Again, we see the concept of balanced capability associated with agileness. We can have agile departments without having an agile company. In fact, we will undoubtedly begin the journey to agile on a department-by-department basis. In many cases, an agile department responding to a threat focused in that area will successfully defend the company, giving the illusion that the enterprise is agile. OK - as long as we don't take solace in the illusion and think the task is done. Combining Change Domains and Agile Dimensions Combining the agile change domains with the four dimensions of agility provides an analytical tool for prioritizing problems and opportunities. At Paradigm Shift International we call this the Response AbilityTM Profile. This combination was recently used to identify key points and metrics of the Business Case for switching to modular fixturing in a rapid-response machined metal environment at Watervliet Arsenal. The subsequent analysis (see Table 5) came out so overwhelmingly in favor of modular fixturing that the assessment team spent more time trying to disprove the analysis then they did in constructing it. The context of the analysis is important. In this case the machining facility was oriented for rapid-response horizontal and vertical machining, generally in low or unit quantities, where time is the critical factor assuming cost and quality are reasonable. The only real alternative to measure against is hard fixturing, which clearly takes longer on the initial part. It turns out that it also takes longer to return a hard fixture to service after storage then it does to rebuild a modular fixture once its initial design has been completed and electronically archived for subsequent use. Modular fixturing also wins hands down on all cost measurements, is virtually as robust as a hard tool, offers no problems in high precision machining according to experienced users (though problems may be masked by the fact that they are also doing in-process gauging to know the exact part position). Though one might imagine specialized integral machine fixturing that could be faster and less expensive, it is difficult to believe that it would satisfy the broad scope requirements on potential work shapes. Keep in mind that scoring for agility is relative to alternatives and requirements. In time a real alternative will arrive, and/or the business environment will require even more responsiveness - when these events occur, modular fixturing may look less agile. It is interesting to note that the technologists building the FCIM facility at the Watervliet arsenal, which was the subject of this analysis, had an intuitive understanding of the values of modular fixturing, but had not yet spent any time relating that to subsequent manufacturing costs. Though obvious now in hindsight, the analysis pointed out very clearly that a change should occur in the cost accounting and order estimation procedures - which currently charge all fixturing expense to an initial order. From the analysis, it also appears that modular fixturing can reflect a real cost reduction into final order pricing; and it is interesting to note that these savings in "operating" costs did not require an up-front investment any larger then the inagile alternative of hard fixturing. Here is an example indicating that agility is not necessarily something that must cost more. The analysis shown in Table 5 is qualitative; but it very clearly shows the shape of the business case, and importantly, indentifies specific supporting metrics. Key Enterprise Elements So now that we have a model for subjectively measuring agility across a variety of change domains the question of where to apply it in the enterprise arises. Specifically, how can we decompose the enterprise into its sub-modules for focused
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 4
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Table 5: Agile Response Ability Profile of Modular Fixturing in Rapid-Response Metal Machining Legend: C = Cost, T = Time, R = Robustness, S = Scope
Creation (Build New Capability)
C - 0.8 T - 1.0 R - 0.9 S - 0.9
Cost Benchmark: Hard and modular both = $26k original cost but modular is reusable. Time Benchmark: lead time for hard = 3 mos, modular = 8 hrs. Modular has no storage expense and hard must often be matched to a specific machine. Robust: No real precision problems, but more error potential at slight time inconvenience. Scope: Especially tall parts may present some rigidity problems.
Capacity (+/- Same Capability)
C - 1.0 T - 1.0 R - 1.0 S - 0.9
Changing the number of parts accommodated by a modular fixture is fast, inexpensive, robust and fairly broad in scope. Increasing or decreasing the number of fixtures needed for a part production run is fast, inexpensive, robust, and unlimited in scope; especially useful is the opportunity to easily obtain fixtures for different machines.
Capability (+/- Different Capability)
C - 1.0 T - 1.0 R - 0.9 S - 0.9
Modular fixturing is readily available in different families for different types of parts. Easy to accommodate wider range of materials for making the same part. Fixtures can be easily modified for machines other than those they were initially built for.
Reconfiguration (Change Relationships)
C - 1.0 T - 1.0 R - 0.9 S - 0.9
The very essence of modular fixturing is reconfigurability at low cost and high speed. Scope and robustness are the same as outlined under the creation domain.
Migration (Fundamental, Event-Based)
C - 1.0 T - 1.0 R - 0.9 S - 0.9
Here we conjecture how well modular fixturing might cope with potential changes as itemized: To solid modeling and automated fixture building. To high frequency build-up and tear-down. To 24-hour order-to-shipment response requirement.
Performance (Operating Surprise)
C - 1.0 T - 1.0 R - 1.0 S - 1.0
Part design changes can be accommodated by reconfiguring the fixture. Unexpected expedited orders for old parts can be accommodated quicker and cheaper with a modular fixture build-up then with retrieving an old hard fixture from storage.
Improvement (Incremental, Continuous)
C - 1.0 T - 1.0 R - 1.0 S - 1.0
Improvement in fixture design for lowering part machining cost, improving part quality, or increasing part throughput can be easily accommodated. Importantly, these advantages are often foregone with hard fixturing because of the great expense and time involved in a new fixture.
Repair (Return to Service)
C -1.0 T - 1.0 R - 1.0 S - 1.0
Damaged fixtures are quickly and inexpensively returned to service, and do not noticeably interrupt a production compared to damaged hard fixturing.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 5
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
measurement and analysis. The Agile Production Focus Group took up this question within the confines of the enterprise's production area...initially.
The task at hand was to identify a manageable number of categories within production that, when taken as a whole, encompassed all of production, but when taken individually could productively channel an analytical exercise. At this point a twelve-category taxonomy is being used. It has been shaped by eight months of trial-and-critique workshops as well as some preliminary testing against industrial analytical exercises. Consider for a moment a conceptual entity representing all that the production environment is; and visualize it as a complex integrated system in the shape of a solid sphere. We want to slice that sphere in half and see what categories are exposed across the entire surface. Many different surfaces could be exposed depending upon our absolute angle of attack. Which exact surface is exposed is not important at this point, only that the surface is comprehensive and the categories are functionally meaningful. This discussion recognizes that different people might slice the sphere at different angles; exposing a different set of names for the categories. But since the sphere is sliced precisely in half, all slices will be comprehensive no matter the names used for categorizing the elements.
Thus, if the category names we have chosen to work with do not reflect the reader's personal decomposition model, or appear at first reading to be missing an important category, the reaction is not unique. Through much trial we have learned that no model will immediately satisfy everyone, but most who work with this model find it useful and comprehensive. All of that aside, the model is preliminary at this point and currently being vetted in a series of applications which may well cause the addition or modification of a few categories. There will be a strong resistance, however, to grow the number of categories as twelve already taxes our abilities to produce succinct, comprehensible profiles that can serve as a first-order organizational snapshot - which is the intended use of this model. As industry-wide understandings mature and some degree of agileliteracy within industry develops, more complex and detailed models will be appropriate.
What to call these categories? We have called them structures in the past because we wish to examine their architectural makeup. We have called them systems also, because we recognize them as integrated functional entities composed of subunits. Unfortunately we have seen the powerful capabilities of these words to stand in the way of the concept they are trying to represent. Consequently, we have chosen to call them "elements".
In developing and studying these categorizations it was natural to ask how they might scale to the enterprise level, or apply to other functional areas besides production. These questions are in part responsible for the shape of the current model and the element names. Every functional units within an enterprise, no matter what it does, from the secretarial pool to the Board of Directors, has a production process and production equipment, has an analog to the changeover/setup activity as one job is finished and another started, receives input from a supply chain and transfers output through a distribution system, and so on. This model very much views the enterprise and each of its sub-modules as functional units that are expected to produce something. Thus, the jargon of production is useful.
Organizational Structure Human Resources Operating Procedures Information Automation Control Automation Facility
Material Movement/Management Production Process Production Equipment Changeover/Setup System Supply Chain Distribution System
Figure 2
If it is the production environment that we wish to analyze according to these twelve elements, how do we deal with the product issues? A common question. The context within which these elements are applied must always be well understood. In the case of production, we will use these elements to localize our analysis of response abilities in the face of unpredictable change within the production environment. Thus, the issues associated with "agile product design", a very interesting and related subject in its own right, are not represented within our enterprise element categories, nor should they be. On the other hand, issues associated with the interface and interactions between production and engineering may have analytical inclusion in production's Supply Chain element, in engineering's Distribution System element, and in the greater
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 6
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
enterprise's Organizational Structure, Production Process, Changeover/Setup System and other elements.
What about business strategy, or accounting, or contracts? Those words seem important but are not evident in the enterprise element list. As enterprise functional units any of these areas can be analyzed with the enterprise element decomposition model. As work products of functional units they can be analyzed in their own right outside of the enterprise decomposition model, just as a product design, the work product of the engineering department, can be analyzed for agile concepts. Otherwise they are included in the Operating Procedure analysis of various enterprise functional units. This discussion was meant to be indicative rather then exhaustive - other seemingly anomalous categories may come to mind and can be dispatched similarly.
Combining the eight agile change domains, the four agile dimensions, and the twelve enterprise elements provides a preliminary but comprehensive tool for analyzing (or designing) enterprise agility. Using the eight change domains and the twelve enterprise elements we can build an 8 x 12 matrix of 96 cells and use it as an enterprise profile framework. Within each cell we can focus on the four change dimensions of cost, time, robustness, and scope to profile the response ability for a particular change domain in a particular enterprise element.
This profile framework is useful for structuring discussion and debate about the agility of an enterprise and its functional units. It can also be used to identify areas for development or re-engineering, and help prioritize a migration strategy.
Useful and meaningful profiles of existing enterprises and functional units emerge without populating all 96 cells. When the model is used to communicate the flavor of the organization or indicate general trends, too much information can in fact be counterproductive. On the other hand, when detail planning is required or when concentration is directed to just one or a few of the twelve enterprise elements, all eight change domains should be reviewed.
An enterprise and its functional units are extremely rich and complex entities. Even if we narrow our interest to agileness, slicing into twelve generalized areas for scrutiny can still produce an overwhelming amount of information. Adopting a specific context for analysis or planning activity will make the effort manageable and more importantly, answer useful questions. For example, an agile response ability profile exercise was recently conducted at the Watervliet Arsenal. Analyzing all aspects of the organization within each of the 96 cells would have been a formidable task, and well beyond the three days allotted for information gathering. Instead, a specific context was adopted for the analysis that focused on surge capability in cannon manufacturing as well as a new interest at the arsenal: rapid response, small-lot, machined-metal parts under a program referred to as FCIM.
At this writing the analysis detail of the Watervliet Arsenal profile is not yet complete; but an enlightening and surprising (to
the author) picture emerged rather quickly. The Arsenal arranged for a constant sequential stream of 30-minute presentations
over the three days that spanned all twelve enterprise elements. This barrage of information was filtered in real-time by the
analysis team (principally the author) for applicability to the surge and FCIM focus of the profiling exercise. At the same
time, information was gathered about the
environmental dynamics within which the Arsenal
Etc... Demand Process Fickelness Rigidity Surprise Innovation Creation Capacity
functions as an enterprise. In principle, these environment dynamics are overlaid upon the response ability of the enterprise on a cell-by-cell basis to produce the overall agile response ability profile. The preliminary profile that has emerged paints the
Projecting Environmental Dynamics Against Enterprise Response Ability
Capability Reconfiguration Migration Performance Improvement Recovery
Scope Robustness Time Cost
Arsenal as much more agile, in the focus area, then the author had expected from a government run organization. Even more interesting is the emergence of a picture that suggests the Arsenal has (or is developing) core competencies in surge and rapid-
Org. Structure Human Resources Operating Procedures Information Automation Control Automation Facility
Distribution Supply Chain Changeover/Setup Production Equipment Production Process Material Movement/Mgmnt
response manufacturing that may be useful to the rest of the defense establishment. Importantly, the profiling exercise also suggested some areas that need
closer scrutiny and attention if full potential for agile
Figure 3
rapid-response is to be realized.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 7
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Agile Attributes The Agile Response Ability Profile provides a useful tool for contrasting environmental dynamics with an enterprise's ability to keep pace; and can pinpoint areas that need attention. In essence, it can show us what's agile and what's not. What we do about it is another question entirely. This led us on a search for agile attributes: important enabling characteristics of enterprise elements that allow them to be agile. We started our search in the information automation and control automation enterprise elements.
Few would disagree that information automation systems are critical enablers for modern production; but what will an agile information automation system look like? More importantly, are there fundamental attributes that provide agileness that we can look for in selecting information automation systems.
The progress of software technology and deployment of large integrated Software Systems has provided an interesting laboratory for the study of complex interacting systems in all parts of enterprise. The integrated software system, whether it's in the accounting area, provides management decisions support, or spread over countless factory computers and programmable logic controllers, is understood to be the creation of a team of programmers and system integrators. We recognize that these people have the responsibility for ongoing maintenance and eventual replacement. In short, the integrated software system is the product of intentional design and constant maintenance.
As engineering efforts, the design and implementation of these integrated software systems proceeds according to an
"architecture", whether planned or defacto. Over the years the size and complexity of these systems has grown to a point
where traditional techniques are recognized as
inappropriate. This awareness has come from
experience: from waiting in line for years to get
necessary changes to the corporate accounting
system; from living with the bugs in the production control system rather than risk the uncertainty of a software change; and from watching budgets, schedules, and design specifications have little or no impact on the System integration effort. The problem stems from dynamics. Traditional techniques approach software design and
10 Structural Attributes: Encapsulated Modules Plug Compatibility Peer/Peer Interfacing Loose Coupling Distributed Cont/Info Self Organization Scalability Redundancy Reusability Promiscuity
12 Priority Agile Structures: Organizational Structure Human Resources Operating Procedures Information Automation Control Automation Facility Material Movement/Management Production Process Production Equipment Changeover/Setup System Supply Chain Distribution System
8 Agile Change Domains: Creation Capacity Capability Reconfiguration Migration Performance Improvement Repair
implementation as if a system will remain static and
have a long and stable life. New techniques, based on
"object oriented" architectures, recognize that
systems must constantly change, that improvements
and repairs must be made without risk, that portions of the system must take advantage of new sub-
Figure 4
systems when their advantages become compelling,
and that interactions among subsystems must be partitioned to eliminate side-effects.
These new approaches have been matured over a decade now and are emerging most visibly into everyday employment under the name client-server architecture. Though there are significant differences between systems concepts called clientserver and those called object-oriented, encapsulated modularity and independent functionality are the important and shared key concepts. More to the point, information automation practitioners are now focusing a good deal of thought on the architectures of systems that accommodate change; providing a laboratory and experience base from which fundamental characteristics are beginning to emerge.
The Agile Production Focus Group opened a project early in 1993 to catalog a preliminary list of attributes that an agile information automation system would possess. This was done with an eye to generalizing these attributes across all twelve
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 8
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
"enterprise elements" in the production environment. The hope was to find a way to structurally analyze many different types of systems for agile characteristics. At this writing a preliminary model has evolved and been employed usefully in group discussions and limited analytical exercises. Initial results indicate that an analysis of software systems and potential investments in them will greatly benefit from a structured examination for agile attributes. We go a step further, and propose that value also exists in examining the other non-software key enterprise elements for these same characteristics.
Attribute Encapsulation / Modularity
Manifestations Client-Server, object-oriented, autonomous modules.....
Describe attribute manifestation and depth/breadth of employment. Client-Server systems architecture. SmallTalk O-O Client and server applications architecture. Clients = operators and station controllers. Servers = applications.
Plug Compatibility Peer-Peer Interfacing Loose Coupling
Open systems, APIs, heterogeneous networking, interoperability, standards..... Message-based interactions, nonhierarchical structure, clientserver..... Intermodule messaging; real-time, late-binding dynamic confederations.....
Semastech DFS framework compatible. Corba and isis Bus Compatible. All ParcPlace SmallTalk Platforms OK. Published message format. Client-Server. Published proprietary messages. Non-hierarchical, flat structure. Not: Server maintains client data locally => unbreakable relationship. Repaired equipment automatically absorbed as system resource.
Distributed Control & Information Self Organization Scalability Redundancy
Distributed scheduling, planning, & systems; make decisions at knowledge point..... Bidding, dynamic scheduling, capability declarations, dynamic alliances, adaptive..... Identical concepts at all levels of granularity, unrestricted module population..... Fault tolerant, live backup, multiple instances.....
Central scheduling and planning Real-time resource disposition. Automatic creation of new Server if one crashes. Automatic hot-backup cutover. Automatic real-time resource disposition. Automatic repaired-resource absorption. Not - Different architectures at two levels: Client-Server at system level Object-oriented at application level. Multiple servers of same type ok. Hot backup.
Facilitated Reusability
Module templates, module libraries, module editing tools.....
System-wide app servers insure app consistency, eg, one SPC approach. Configurable applications. Applications maintained as object-oriented class hierarchies.
Interoperable, opensystems, heterogeneous coexistence, legacy interfaces.
Sematech DFS standard framework. Published proprietary message formats. General purpose object/message adaptor gateway. All changes published to message bus.
S__e_m_i_c_o_n_d_u_c_t_o_r_W__a_fe_r_-_F_a_b_a_n_d__C_o_m__p_u_t_e_r_iz_e_d__M_E_S_____________________ Structure Identification © 1993 RK Dove/Paradigm Shift, 510-652-7528
_________r_k_d_/_a_m_________ Reviewer(s)
__7_/_2_9_/9_3____ Date
Permission granted for attributed copies.
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 9
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Currently these attributes are expressed in the jargon of the computer world, and betray their origins. Readers far removed from current computer technology may find the application of these terms to other enterprise elements difficult to work with. Though a human resources director might feel more comfortable with "empowered work team" then with "encapsulated modules", the two are similar architectural concepts. It is necessary to find more generic expressions for these attribute concepts to make their use broadly accessible. However, though that task is not yet accomplished, we will not let it stop us from completing the tool framework discussion we have begun here. The agile attributes identified here are presented as an integrated minimal set that have survived unsophisticated attempts to remove any one of them. Recent work has expanded preliminary attempts [4, 6] to show how each of these attributes is manifested in each of the twelve key enterprise elements. The details of that work is beyond this discussion and will not be dealt with here.
Though no detail on the agile attributes will be covered here, they are presented in order to show our complete structural model of agility. These attributes were recently used to profile manufacturing execution systems (MES) software from the five (only) vendors serving the semiconductor wafer fabrication market. The products offered by each of these vendors have very different profiles when analyzed for agile attribute manifestation. An attribute profile does not provide a value judgment directly. Instead, it identifies issues and differences that might, for instance, be compared with a specific set of usage requirements before making an investment decision or freezing a set of development specifications.
Lean and Agile in Perspective
A year before the 21st Century Manufacturing Enterprise Strategy [1] was published, a book called The Machine That Changed The World [2] became available. Written by James Womack, Daniel Jones, and Daniel Roos, and based on a five year MIT study on the future of the automobile, this book is the definitive work on lean manufacturing.
As the authors explain it, lean is a term applied to a collection of practices that began in Japan at Toyota in the 50s and deserve full credit for Japan's ascendancy in the automotive world. The lean movement in the USA is an attempt to understand what some Japanese already know, and The Machine That Changed The World packages these understandings quite readably for consumption in the USA as well as elsewhere. On the one hand it is an excellent history book, and on the other it is a call to action.
The lessons of lean are extremely important for our understanding of agile. Many USA companies today are in the midst of major programs to emulate the Japanese methods and want to understand how agile relates. Others, listening to the rhetoric from both views hear much in common and want to know what are the distinctions. That lean and agile are both competing for mind share at the same time is just one more sign of how fast things are moving. No sooner do we understand what the Japanese have been building for the last 40 years than we have a new view that claims equal importance and urgency. We will attempt to put these two into a working perspective.
Lean is a set of practices intended to remove all waste from the system. It is predicated on maximal usage of resources. It gave birth to, and encompasses, JIT, Kaizen, Kanban, empowered teams, quality circles, cycle-timereduction, market pull, small-lot manufacturing, flexibility - practically all of the current wave of change methodologies. And virtually the same things that agile needs in its domain.
The lean paradigm has been incrementally developed by Toyota since the '50s as a sequence of profound objectives and tactics, the completion of one guiding the way to the next. Forced to design a flexible stamping
Figure 5
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 10
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
press because their volume couldn't afford a large number of single-part dedicated presses, Toyota discovered that small-lots in fact cost less then mass-production runs: inventory carrying costs and defective parts were both greatly reduced. This showed the way to JIT concepts, which led the way to the Kanban system. To utilize flexible stamping presses effectively, highly skilled teams were necessary. Serendipity played a hand when a major strike was resolved with employees gaining empowerment through decision responsibility. And this led the way to quality circles and Kaizen incremental improvement concepts, and eventually to "empowering" the distribution channel and the customer by involving them in the business decision making processes. All the while, a core of genius broadened these basic understandings across a larger and larger portion of the enterprise activity.
No grand vision drove this development. This was a continuing sequence of innovative steps taken by very perceptive people. Lean is a response to competitive pressures with limited resources, agile is a response to complexity brought about by constant change. Lean is bottom-up driven, incrementally transforming the mass-production model. Agile is top-down driven responding to large forces.
Lean is a collection of operational techniques focused on productive use of resources, agile is an overall strategy focused on thriving in an unpredictable environment. As such, lean, with its bottom-up, incremental development, and 40 years of development, has a demonstrable number of proven methodologies. Agile, with its top-down vision, has identified a compelling objective and is now beginning the search for enabling methodologies. This and previous statements are oversimplifications. Nevertheless, they offer comparative perspectives as we all attempt to corral the lean beast the Japanese gave birth to in the '50s, and the agile beast the Americans are starting to create in the '90s.
A very discernible difference surfaces when we look at architectural roots of manufacturing paradigms. Craft production is based upon the comprehensive single unit: one man builds an entire rifle, one team builds an entire car. Mass production introduced specialized work modules and sequential work flow past these modules. Lean brought us flexibility with its alternate paths and multiuse work modules. And now agile brings us reconfigurable work modules and work environments.
Another important and valuable working perspective: lean is interested in those things we can control, agile is interested in those things we can't.
What appears to be true is that all new paradigms retain a large dose of their predecessors. Though we focus on the differences in order to advance to the next stage, a closer look reveals a much larger common core. Those companies currently making the transition from mass production to lean production are not likely to find any conflict or wasted effort in a subsequent transition to agile: most of the requirements for lean are also requirements for agile; and leanness to the point of fragility is unlikely to be attained in these early stages. Knowing that the ultimate goal is agile, however, should help set priorities and transition sequences.
Craft Reconfigurable Flexible Fixed Comprehensive
oooo oo -o--o--o--o-
Agile o o oo o
Figure 6
Never before have we seen two major paradigms come so close together. Before we have a chance to internalize our understandings of lean through operational experience, here comes agile. But then again, the USA is starting on lean forty years late. Perhaps the lessons of lean can be learned in night school at the same time the potential of agile is developed and exploited. In Conclusion Agile will not solve all the problems of competitive enterprise. Nor is agile the correct approach for all things at all times. Agile is a new option that needs to be understood and applied when the benefits are important. An interesting exercise to conduct when building awareness and
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 11
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
understanding for agile concepts identifies reconfigurable, flexible, fixed, and comprehensive approaches for the same item.
Table 6 shows how this might be applied to Manufacturing Execution Systems software. The exercise helps sharpen an understanding of the principal features that categorize the architecture and, importantly, identify the advantages that each approach brings. The agile reconfigurable approach is the right choice some times, but not always.
The tools described here are
Table 6: Agile Is A New Option
part of a larger set [3] undergoing application
Sometimes It Is The Best Option - Sometimes Not.
testing and extension in
Shop Floor Control Systems
Principal Features
Message-based object oriented network with reusable and extensible class structures.
Advantages Minimizes software maintenance and development costs and times in a dynamic environment after initial set of control and information classes are developed. Promotes safe continuous
various industrial settings. The " Structure of Enterprise Agility" figure relates agile attributes and key enterprise elements to the agile change domains
and agile dimensions.
4GL configurable application templates.
Common applications look and feel across all production lines; easy user customization for each line's individual differentiation.
Refinement of these structural relationships and analytical tools owes much to the members of the Agile
Production Focus Group of
Custom built software for each production line.
Optimal performance of each individual production line if nothing changes.
the Agility Forum as well as the many companies that
are participating in early
One universal fixed
assessment exercises.
control and information approach that applies to all production lines.
Minimizes software development, risk, and maintenance expense by disallowing change.
The history book on Lean has already been written.
The history book on agile
can't be written until there
is some history. Waiting until others discover and test new methods worked when things changed slowly. It doesn't
anymore. Those who don't help write the agile book are not likely to be around to read it.
[1] An Industry-Led View, 21st Century Manufacturing Enterprise Strategy, 2 Volumes, , November 1991, Agile Manufacturing Enterprise Forum, Lehigh University, Bethlehem, Pennsylvania, 215-758-5510. [2] James P. Womack, Daniel T. Jones & Daniel Roos, The Machine That Changed The World, 1990, Rawson Associates, New York. [3] RK Dove, Lean and Agile: Synergy, Contrast, and Emerging Structure, Proceedings Defense Manufacturing Conference `93, December 1993. [4] RK Dove, Editor, Agile Production Focus Group 1992/93/94 Journal of Progress, Chapters 1-16+, available from Agile Manufacturing Enterprise Forum, Lehigh University, Bethlehem, Pennsylvania, 215-758-5510. [5] Testing Agile Response Ability Profile Tools at Watervliet Arsenal, November 1993, Paradigm Shift International performed the work as a subcontractor to management systems Applications under FCIM Support Contract N00612-93D-7310. Contact: R. Patterson, Joint Center Flexible Computer Integrated Manufacturing, 803-760-4344. [6] An Agile Systems Framework: A Foundation Tool, S. Benson, RK Dove, J.Kann, Proceedings - AMEF Second Annual Conference, 12/93, Lehigh University, Bethlehem, PA 610-758-5510
© 1994 Rick Dove
Republished by Agility Forum, PA96-01, Jan 1996
Page 12
Tools for Analyzing and Constructing Agility
Attributed copies permitted.
Watervliet Arsenal modular fixturing analysis: A. Baridino, Sandia; L. Burnet, Lawrence Associates; R. Dove, Paradigm Shift International; J. Oleson, Dow Corning; R. Patterson, Department of Defense, JCFCIM and Watervliet Arsenal; M. Surzyn, Watervliet Arsenal; M.Scherdlup, Rockwell, Collins. Agile Production Focus Group participants: Chair: R. Dove, Paradigm Shift International; C. Ackerman, Digital Equipment Corp; L. Allgaier, General Motors; A. Beradino, Sandia ; S. Benson, Thesis; K. Burr, Electronic Data Systems; M. D'Orlando, UTC - Norden Systems; W. Drake, Martin Marietta Energy Systems: P. Eicker, Sandia; M. Griesmeyer, Sandia; A. Gunneson, Gunneson Group: R. Hale, Rockwell; C. Holmes, Martin Marietta Energy Systems; A. Hrncir, Texas Instruments; K. Jessen, Rockwell; J. Jackman, Iowa State; B. Kaminski, Softech; J. Kann, Allen-Bradley; J. Kohls, Institute of Adv Mfg Sciences; P. Leinbach, Aeroquip Corporation; V. Lott, Texas Instruments; R. Neal, Martin Marietta Energy Systems; G. McBryde, Acme Electric; J. Oleson, Dow Corning; J. O'Neil, Kingsbury Corp; R. Patterson, Department of Defense, JCFCIM and Army; F. Plonka, Chrysler; D. Reich, Department of Labor; F. Reynolds, Eastman Kodak; D. Rife, Westinghouse; S. Scaringella, UTC - Norden Systems; M.J. Scheldrup, Rockwell, Collins; R. Seshadri, Honeywell; G. Staffend, Allied Signal Automotive; D. Standen, Chrysler; S. Swirsky, Department of Labor; R. Textor, Martin Marietta Energy Systems; O. Thien-Ngern, Iacocca Institute; Trabin, Jack, Ford Motor Company; J. Tuschner, Martin Marietta; G. Vasilash, Gardner Publications; W. Wadsworth, Retired - Scott Paper; M. Wald, Alcatel Network Systems; C. Ward, Agile Business ReEngineering; R. Woelfling, Hershey Chocolate USA. Response Ability is a trademark of Paradigm Shift International.
Promiscuity Reusability Redundancy Scalability Self Organizing Distributed C&I Loose Coupling Peer-Peer Plug Compatibility Encapsulation Creation Capacity Capability Reconfiguration Migration Performance Improvement Recovery
Org. Structure Human Resources Operating Procedures Information Automation Control Automation Facility
Distribution Supply Chain Changeover/Setup Production Equipment Production Process Material Movement/Mgmnt
STRUCTURE OF ENTERPRISE AGILITY _________ 10 Agile Attributes + 8 Change Domains + 12 Enterprise Elements + 4 Agile Dimensions
© 1994 Rick Dove
Figure 7 Republished by Agility Forum, PA96-01, Jan 1996
Page 13

R Dove

File: tools-for-analyzing-and-constructing-agility.pdf
Title: Microsoft Word - Rkd4Art4.DOC
Author: R Dove
Author: Rick
Published: Fri Oct 29 10:09:11 2004
Pages: 14
File size: 0.26 Mb

Automated Coin Grader, 4 pages, 0.02 Mb

WRITER'S STYLE GUIDE, 24 pages, 0.56 Mb

, pages, 0 Mb
Copyright © 2018