Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management

Table of Contents

Cover image

Front Matter

Copyright

Preface

Chapter 1. Introduction

Chapter 2. Product Documentation

Chapter 3. Identification Numbers

Chapter 4. Interchangeability and Service Parts

Chapter 5. Bill of Material

Chapter 6. Teams and Other Foundation Blocks

Chapter 7. Document Release and Product Lifecycle

Chapter 8. Change Requests

Chapter 9. Change Lifecycle Cost

Chapter 10. Change Management

Chapter 11. Fast Change

Chapter 12. Process Improvement/Work Flow Diagrams

Chapter 13. Process Standards and Audits

Chapter 14. EDC and the Supply Chain

Chapter 15. Benchmarking

Chapter 16. Product Manufacturing Software

Reference and Reading List

Index

Front Matter

Engineering Documentation Control Handbook

CONFIGURATION MANAGEMENT AND PRODUCT LIFECYCLE MANAGEMENT

FOURTH EDITION

FRANK B. WATTS

Amsterdam • Boston • Heidelberg • London New York • Oxford • Paris • San Diego San Francisco • Singapore • Sydney • Tokyo

William Andrew is an imprint of Elsevier

Copyright

William Andrew is an imprint of Elsevier

The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB, UK

225 Wyman Street, Waltham, MA 02451, USA

First edition 1993

Second edition 2000

Third edition 2008

Fourth edition 2012

Copyright © 2012 Elsevier Inc. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the Publisher. Details on how to seek permission, further information about the Publisher's permissions policies and our arrangement with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions.

This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein).

Notices

Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary.

Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.

To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Control Number: 2011936727

ISBN: 978-1-4557-7860-7

For information on all William Andrew publications visit our website at www.elsevierdirect.com

Printed and bound in the United States

12 13 14 15 10 9 8 7 6 5 4 3 2 1

Preface

The wide acceptance of this book has been very gratifying. This work seems to have taken on a life of its own. The third edition publisher wrote: Your book over the last year has resulted in the most ‘Buy This Book’ links of our entire catalog … It is very well received by the Googleites. Sales have exceeded 11,000 at the time of writing of this fourth edition. Why? While management fads come and go, buzzword programs abound, software acronyms and software applications ebb and flow, the critical importance and the basics of engineering documentation control remain the same. The author thinks of himself as the Vince Lombardi of document control. Basic blocking and tackling! In that sense, the fourth edition has not changed the principles but has been significantly rewritten and edited. A new chapter on product manufacturing systems has been added. All with the intent of improved explanations, emphasizing product lifecycle management, and Configuration Management (CM) as engineering's quality control function.

Whether you think of this subject as Engineering Documentation Control (EDC) or CM, or Product Lifecycle Management (PLM) it needs to be recognized as a key business strategy. The wall or gap between engineering and the rest of the world has existed too long in many companies. The throw it over the wall syndrome can be overcome. It is prevalent in new product releases, bills of material, change requests, and change processes as well as in related software packages. Simple, make-sense, fast, accurate, efficient, measured, and well-understood Engineering Documentation Control/Configuration and Product Lifecycle Management can tear down that wall – bridge that gap.

The title of this book indicates that Engineering Documentation Control – Configuration Management and Product Lifecycle Management are equivalent terms. But are they really? Many people feel that EDC is a subset of CM. Some think of EDC as what they are currently doing and CM as what they ought to be doing. PLM is a term used primarily by software applications for engineering – but it certainly implies a cycle that transcends engineering into manufacturing and to the customer. Much of the truth in this discussion is in the eyes of the beholder.

Historically, the CM term was largely invented by the Defense Industry and the Department of Defense (DOD). The term had been used and abused so extensively by our product manufacturing world that it had taken on a parochial and a very complex meaning. Commercial businesses began taking back the CM term in a simplified form. Many defense product manufacturers are moving toward commercial practices – simplified Configuration Management – a healthy trend.

In the meantime, the software configuration management folks have largely usurped the CM term for application to the development and production of software tools. If you Google the CM term, you will largely find software tools for controlling software tools.

The author is thus all the more pleased to have consistently used the Engineering Documentation Control term. This work will use all of these terms selectively.

Can CM in a Defense Industry context be made simple? A study published in National Defense magazine, September 1992, by George Krikorian, PE, summarizes the conditions at that time. The results revealed that the cost of a product when selling to DOD increases from five percent to one hundred percent as compared to the same or similar product cost to a commercial (non-DOD) enterprise. One of the significant reasons given was MIL-SPECS and Standards. Configuration Management standards make up a significant portion of the total DOD Specs and Standards. There has been some significant reform in the DOD, however, so the hope for military contractors and taxpayers is improving.

Meanwhile, some in the commercial segment are erroneously moving toward more complex CM. The Automotive and Aeronautical segments have written their own versions of ISO standards adding a layer of bureaucracy that is making our autos and air transport expensive, adding little value or safety to the products. The FDA continues to make their requirements excessive by controlling products in the same manner they control drugs. The ISO standards have evolved but not necessarily for the better. While claiming to be more general and less specific, the page count has, nevertheless, increased significantly.

The primary goal of this book is to keep CM simple. The basics of best-in-class Configuration Management will be presented from the ground up, for application in either a commercial or military kind of business.

The typical CM approach is to acquire and read all the applicable commercial and Military Specs, Standards, and Directives, and then design the system around them. Rather, every product manufacturing business should develop a simple, make-sense, fast, accurate, efficient, measured, and well-understood process approach to Engineering Documentation Control/Configuration Management/Product Lifecycle Management and then examine the DOD, MIL, DOE, FDA, ISO/QS/AS, and all other applicable agency standards. After careful examination of those standards, add to or modify that approach to satisfy the customer/agency specifications, as and if necessary.

Since the first edition of this book, many companies have become ISO/AS/QS-certified. Write down what you do and do what you have written, it is said. Companies have also come to realize that certification only gets their CM practices minimally documented and followed. A significant majority of ISO requirements and problems involve the CM discipline, but there is no built-in assurance in the ISO certification that the processes are efficient, measured, productive, or that they outperform the competition. Thus, writing down what you do and doing what is written may be a form of insanity – which is defined as doing the same thing over and over again, and expecting different results. Subsequent revisions of ISO requirements have emphasized process improvement. The emphasis of this book is not on ISO requirements. The emphasis is on helping people help their companies toward exceptional CM practices and processes.

The quick release of new product documentation, minimal structuring of a single bill of material database, the ability to request changes, and to change the documentation and product quickly, accurately, and at least cost are critical to a company's profitability. Thus, the development and implementation of a simple, make-sense, fast, accurate, efficient, measured, and well-understood CM system is an important business strategy. Simply put, it sets the stage for innovation in engineering and operations.

The basic principles of world-class EDC/CM are applicable, regardless of the kind of manufacturing or the kind of customer. Toward achieving this make-sense approach, the following will be the guiding principles of this book:

• Develop a generic approach that is good for commercial or agency-regulated companies. Many of the existing texts on this subject address DOD Specifications and Standards. This work takes a generic approach.

• Take the acronyms out wherever possible! The goal here will be to only use those acronyms which are universal in the manufacturing business and to explain each where it is first used.

• Use the English language, defining terms as we go, as opposed to using, for example, over 20 pages of glossary found in one text.

• Take the jargon, mystique, double-talk, fads, and unnecessary complexity out of Configuration Management.

• Systematically approach the discipline by using an example product – an electronic ignition, application software programmed, front-end loader with a variety of features and options. Develop the design documentation for this product, structure the bills of material with operations people, release it from engineering to manufacturing, request changes, change it, and close the loop by knowing when each change was made and what is in each product as needed.

• Develop principles that are sound for any size company, while recognizing the nuances that may be present in small, large, multinational, make-to-print, make-to-stock, make-to-order, or design-to-order for discrete product manufacturing.

• Develop principles which are sound for any type of product, while recognizing differences in products that vary from needles to nuclear ships, and production rates that vary from quantities per second to years per quantity one.

• Emphasize early costing of the product and changes, a generally ignored aspect of CM practice.

• Show how redundant bills of material can be eliminated, how to simplify the bill of material structuring, and how to evolve bills in lead time to produce the product.

• Develop generic CM processes in the form of flow diagrams and standards to use as a guide in the development of your own processes. Assure that the horse (documentation) comes before the cart (the product).

• Establish methods for achieving fast processing of releases, requests, and changes. The emphasis will be on speed – a long-overlooked criterion and very costly oversight.

• Outline methods for analyzing an existing system and implementing a new system. Outline methods that can be used, whether reinventing the system and/or using continuous improvement techniques.

• Explore methods for standardizing the processes and auditing them.

• Outline the importance of EDC/CM in the supply chain, note how the chain can be broken and address the issues facing the Original Equipment Manufacturer (OEM) and the supplier.

• Share benchmarking surveys and analysis with the readers.

• Identify the most serious, most often made, mistakes in the discipline.

• Distinguish between Engineering Documentation Control, Configuration Management, and Product Lifecycle Management.

• Develop a few key metrics for all the processes – speed, quality, and volume. Many more measures of merit are in the author's CM Metrics book.

• Develop EDC/CM/PLM rules and give reasons for the rules. Realize that almost all rules have exceptions. Realize that all the rules need not be followed in your company, but violation of very many will lead to chaos.

• Demonstrate why the CM function is essentially the quality control function for engineering.

Such goals can be accomplished without sacrificing product quality. In fact, the quality of documentation releases and changes as well as the quality of the product must increase as new or improved Engineering Documentation Control is implemented.

Good CM alone will not achieve best-in-class Total Quality Manufacturing (TQM); however, best-in-class TQM cannot be achieved without best-in-class Configuration Management. This will be accomplished while improving quality, not hurrying up to do it wrong!

Engineering Documentation Control is a significant business strategy and an absolute foundation block for: TQM, JIT (Just In Time), cross-functional teams (concurrent engineering), engineering/manufacturing/supply chain software systems, lean manufacturing, meeting domestic or international standards, and efficient manufacturing. In fact, it must be a significant company strategy if best-in-class or world-class manufacturing is to be achieved.

One reviewer of this book titled his review, Setting the Stage for Innovation. Time for innovation in design and manufacturing can be realized, with the current work force, by first making the EDC/CM processes simple, make-sense, fast, accurate, efficient, measured, and well understood.

My thanks to the universities who have sponsored my seminar. Also to the over 3500 folks who have attended – I learn something in each seminar. My many customers also deserve hearty thanks since I learn something from each of them. Last, but not least, thanks to the third edition reviewers, their compliments and ideas for improvement.

Frank B. Watts, BSME, CCDM (email: ec3corp@rkymtnhi.com)

www.ecm5tools.com, Winter Park, Colorado

Chapter 1. Introduction

Contents

What is Configuration Management4

Between Engineering and Manufacturing5

Configuration Management Ladder7

Configuration Management Discipline8

Configuration Management System8

History of Configuration Management9

Organization of Configuration Management10

Document Control Function Responsibilities12

Configuration Management Function Responsibilities12

Distributed Configuration Management14

Manager's Job14

Manager of Configuration Management14

Organization Within Configuration Management16

Configuration Management—What is It?16

Summary19

This chapters introduces the reader to the book and the concept and history of configuration management. Sections in this chapter cover aspects including why engineering documentation is needed and who should control it as well as the responsibilities of the various departments/managers.

Why do we need engineering documentation at all? Why control that documentation? The mere use of the word control puts most engineers into a very defensive mode. Are we trying to stifle the engineer's creativity? What is there to manage about the configuration of a product?

Let us first identify the basic raw materials of product manufacturing – the very essence of product manufacturing. There are four primary elements:

• Money – for the start-up/profits.

• Tools (machine, mold, software, etc.).

• People (and the processes and measurements they choose).

• A product embodied in design drawings and specs.

So why is it a surprise for some to hear that the management of those design documents is a critical discipline? Think about it. Without design documents, you do not have a producible product. Without control of design documents with make-sense processes and measurements, you have chaos.

Why do architects make drawings and specifications for a home or plant? Do they do this for their own pleasure or for a trade magazine or show? Isn't the documentation done so the customers get what they want? Aren't the documents for the builder who has to build the house and for the eventual owner who will have to maintain it? Try building or maintaining a product without adequate drawings and specs, it becomes especially difficult and error-prone when changes are being made. Try controlling the cost without controlling the changes. Still, most businesses operate to some extent without proper, timely, or adequate control of their documentation. The symptoms are usually everywhere. Let us take a look at the symptoms.

Manufacturing says:

• I don't understand what I'm supposed to build.

• What criteria do we test to?

• Where is the change I need to:

Reduce costs

Avoid making scrap

Avoid making parts that will have to be reworked?

• Will this change increase the bone pile of down-level material?

• Why do I have these bad parts on the dock?

Sales says:

• You mean the product isn't ready for the market window.

• Where is that promised new feature?

• Why didn't we deliver a product with the options the customer asked for?

Customer says:

• I didn't get what I ordered.

• Where is the fix you promised me?

• Where is that new feature or option?

Dealer/Field Service says:

• Shouldn't my publications match my product?

• Where is the fix for this nagging product, firmware, or software problem?

• Our customer is angry – can't we move faster?

Repair says:

• I could fix it easier if I knew what is in this product.

• What changes should be and shouldn't be incorporated upon repair?

Quality says:

• Is this cost included in our Cost of Quality?

• Should we treat ourselves, our suppliers, or our customers this way?

• How can we meet our customer's standards?

• We can't meet international and US standards.

Employee says:

• I asked them to do something about this a long time ago.

Do any of these symptoms sound familiar? The cure is: simple, make-sense, fast, accurate, measured, efficient and well-understood Engineering Documentation Control/Configuration Management (EDC/CM) standards and processes. Good design documentation and its control is the solution for the root cause of these symptoms. Thus, Configuration Management is the medicine that cures the root causes.

CM, kept simple, results in many benefits to the company. What are the benefits of a fast, accurate, and well-understood CM system? Let us take a look at the potential benefits of a carefully planned CM strategy.

Benefits:

• Helps to get new products to the market faster and reduce delivery time for a customized product.

• Happier customers because they see the new option, change, or feature they had requested, much quicker.

• The customers get what they ordered with fewer missed delivery commitments.

• Reduces the bone piles of down-level material.

• Gets real cost reductions implemented quicker.

• Reduces the manufacturing rework and scrap costs significantly.

• Improves bill of material (BOM) accuracy and saves the corresponding material waste and correction time, resulting in corresponding improvement in product quality and inventory accuracy.

• Eliminates multiple BOMs and saves the costs of maintaining the bills, not to mention eliminating the risks associated with multiple bills.

• Evolution of the BOM in lead time to produce the product quicker.

• Reduces field maintenance, retrofit, and repair cost.

• Know exactly what items are non-interchangeable in each product.

• Improves the understanding and communication between design engineering and the rest of the world.

• Clarifies the responsibilities and thus eliminates finger pointing.

• Saves wear and tear on CM managers, master schedulers, and all types of engineers.

• Complies with applicable customer or agency standards.

• Sorts out changes that are not needed or aren't cost-effective.

• Saves many dollars a year in paper and copying costs alone.

• Significant reduction in the cost of quality.

• Allows the company to qualify as a best-in-class producer.

• Sets the stage for innovation in engineering and manufacturing.

The ways and means of achieving these benefits are not secret, high-tech, or cost-prohibitive. These benefits are attainable. This book will outline the who, what, how, why, when, where, and how much in order to achieve an exceptional EDC system. The author has never seen a world-class CM system; he has, however, brought the best of the best to this book. Who knows, maybe the best of the best constitutes a world-class system!

What is Configuration Management

Configuration Management is the communications bridge between design engineering and the rest of the world (see Fig. 1.1). This is the single most important function performed by the CM organization.

The critical nature of the CM discipline cannot be overemphasized. American manufacturing has developed a near tradition of allowing design engineering and the rest of the company to be in an adversarial relationship. It results substantially from the throw it over the wall syndrome – the new design release or engineering change that is done without consultation with the key people at the right time.

Many manufacturing and engineering systems are often unwittingly designed to foster that traditional kind of thinking. The enlightened CM manager can tear down the wall, or at least build a bridge over it.

Let us face it, generally, the designers are thinkers and creators, while the operations people are movers and doers. They will naturally have difficulty communicating. The CM group can enhance communications and ensure that these folks cross the bridge at the right time for necessary communications and with the necessary documents.

The CM function must ensure that what crosses the bridge is properly documented, minimally controlled, available as and when needed, and that feedback is obtained as to when changes occur in production or service. All this must be done at a minimum cost, while appearing transparent to the creative design people and the rest of the world.

While not getting in the way of the design engineer or software engineer, it must be kept in mind that the engineer's product is not just a working evaluation or prototype unit, but that it is accurate specification and drawings for all the parts in that product ready for production. The engineering/CM product is thus quality design documentation.

The primary customer for this documentation is not design engineering, but is manufacturing, suppliers, field service, and the company's customer. The company's customer must be paramount among these users (a term that is much less acceptable to this writer than customer). The vast majority of the design documents are prepared for manufacturing/operations, suppliers and service use. In this sense manufacturing, suppliers and field service people are the most important customers.

There are some symptoms crying for improved CM in every company. The benefits of having a best-in-class CM organization and system explain why it is a significant business strategy.

Between Engineering and Manufacturing is an article the author wrote for Mid-Range Enterprise Resource Planning (edited), which may shed further light on the need for improving this discipline. This article follows.

Between Engineering and Manufacturing

Most product manufacturing companies suffer from the wall syndrome. The manufacturing side bought MRP/ERP; the engineering side went out and bought CAD/PDM/PLM. Those software systems do not generally talk to each other. The engineering folks are, by and large, analytical and cautious (Ready . . . Aim . . . . Fire); the manufacturing folks are, by and large, shakers, movers, and doers (Fire-Aim, Fire-Aim, Fire-Aim). The people do not communicate very well. The manufacturing folks say that engineering throws it over the wall. The engineering folks say that you cannot find anyone when you need them who knows how the product will be processed. Many of the modern MRP/ERP/SCM and CAD/PDM/PLM systems also do not aid the communications very well. This situation often results in a huge gap between engineering and manufacturing.

There is a discipline which can, if properly done, bridge this gap. It is EDC/CM. However, EDC/CM is often very poorly understood and often clouded with claims from the software application folks on both sides. Those who came from a military/DOD-regulated world have applied configuration management requirements that are too complicated, and usually resulted in too much control. Most often, the document control function is manned by one or a few low-paid people who are ill-trained, buried in the organization structure, frustrated, and ready to change jobs. A configuration management function that is properly managed, organized, trained, and manned can tear down the wall and bridge the gap between engineering and manufacturing. Properly manned, however, does not always mean hiring new people. Often the people are there, but they are just scattered in many parts of the organization.

The software applications people all seem to have a claim for doing configuration management. Some do address some parts of the processes involved, but few are comprehensive. Most companies end up with a CAD, a manufacturing system, an engineering system and other systems, but still lack a comprehensive CM. These software systems (a term used frequently in this text to refer to the variety of three-letter software applications) that allow workflow diagrams to be developed to control the processes come closest but are also often found wanting.

The military definition of the discipline is based on the terms: identification, control, status accounting, and planning; some real put-you-to-sleep terms. A much better way to define the discipline is by the processes that it encompasses – the new item release, BOM, requesting changes, and making changes. Thus, we are talking about processes that most readers can relate to. Are there any software application systems out there that will address all our needs for these processes? Maybe, if one pays enough, if one buys enough consulting time to accompany the software, if one knows what one needs, and if the consultants understand the discipline – that is a lot of ifs!

There is a very scary tendency in industry today. After the identification of a problem(s), the tendency is to seek a software application solution. Software programs may help after you understand the job that needs to be done and what process flow is best for you. The processes, however, must be simple; they must make sense, be fast, accurate, and efficient, measured and well understood. Get educated first, design your processes with legacy software, and then finally buy more software if needed.

Something more substantial than software is needed between engineering and the rest of the organization, and it is called CM.

Configuration Management Ladder

Many people believe that when they have been ISO (International Standards Organization) certified, they have adequately covered the documentation control and configuration management requirements. This is true as far as ISO is concerned, but ISO does not care how fast or efficient, or effective or simple the processes are. As is often said: ISO merely wants you to document what you do and do what you document. This is a good step out of chaos, but is a long way from being the best in class or world-class. Examine the CM ladder in Fig. 1.2.

Configuration Management Discipline

Let's start with a definition of Configuration Management:

Definition: CM; A simple, make-sense, fast, accurate, efficient, measured, and well-understood process approach to planning, identifying, controlling, and tracking a product's configuration from its inception throughout its life with minimum cost.

We engineers hate the word control. Too much control detracts from speed. Speed is an element missing in most systems. Also note the time frame – birth to death of the product. Notice that the term tracking is used instead of the classical DOD term status accounting. The challenge for the CM manager is to mix just the right amount of each of these elements into the CM processes – product and document release, BOM, request and change.

Also notice the emphasis on training – a well-understood system. To be systematic and well-understood, the processes must be documented. The discipline must be depicted in a set of standards, and the involved people trained in those standards.

Definition: Configuration; The technical description and arrangement or combination of parts and materials which are capable of fulfilling the requirements defined by the product specification, other specifications, and drawings.

The discipline can be applied to companies that produce a product which is either parts or process driven – discrete product manufacturing or process manufacturing. The product can be a component or an atomic power plant. The principles apply, with some care, to any product. This book will, however, concentrate on discrete product manufacturing. At the other end of the spectrum, where does the product program code (product applications software) fit into this definition? It is also included in the sense that the code is assembled onto a disc or chip that then becomes one of the components.

Notice the emphasis on the product specification. It is surprising how many companies try to get along without a controlled product specification, or they have one but do not release it, or they produce or release it much later than is desirable. This issue will be discussed in detail later.

Configuration Management System

The total CM system is made up of four major processes. These are generally collectively referred to as product release and change control or lifecycle management. More specifically, the processes are:

• Document release process.

• BOM process.

• Change request process.

• Design change process.

Thus, one CM System = four major processes.

The change request process and the design change process are often combined under one term, change management. This will not be done in this book for reasons that will be apparent later. The product or part or document obsolescence process is combined with the design change process and treated as a special kind of design change. These four processes must cover any product from inception to obsolescence – from birth to death.

There is a temptation to claim that these processes occur in series. For example, first, we document the product and release the documentation, then create a BOM, and so on. Although some companies try to do business in series, it is not desirable. The processes overlap almost totally. For example, the product specification should be created and released very early in the product lifecycle. The product specification should be put under a simplistic form of change control, then, long-lead parts should be released in lead time. This may well be done long before a BOM is structured.

Some documents may be obsolete before they are released, thus the processes should not be considered serial, but very parallel. In fact, trying to do these processes in series creates a problem. If, for example, we try to create and release all the documentation for a product before proceeding, then the need to release long-lead items (in lead time to make/buy) creates a quandary. Shall we hold up the project until all the items are documented before releasing the long-lead items? Shall we wait for their assemblies to be released? Grouping any of the documents for release creates an artificial batching of the work. It is much better to design the processes to encourage an item-by-item release in lead time to produce, since that is the way they are needed and used.

History of Configuration Management

The real beginning of CM occurred when Eli Whitney designed and built his cotton gin with interchangeable parts. That concept of interchangeability has come to be expected in all product manufacturing. Items that are replaceable (service items and the end product) are expected to interchange, or reasonable notice be given.

Many companies use CM standards and practices that date back to the early years of their conception. Industry standardization of certain CM practices began with the government during the space program in the late 1950s. This was a necessary and natural occurrence, since the assurance of interchangeability between the many contributors in a space program was very important. In the late 1960s, the Department of Defense (DOD) recognized that each agency and branch was developing its own set of standards. They brought all the CM standards under the purview of the DOD. By the 1990s, they had begun to adopt some industry/commercial practices.

In the 1990s and in the twenty-first century, software solutions have been sought to solve every problem. In the first edition of this book, almost all the existing standards and books in the field had been military/DOD-driven. Since then, the Institute of Electrical and Electronic Engineers (IEEE), Society of Automotive Engineers (SAE), Electronics Industry Association (EIA), American Production & Inventory Control Society (APICS), American National Standards Institute (ANSI), and International Standards Organization (ISO), have all made some contribution in the field.

The following quote from the first edition of this book is no longer true: Industry by and large, however, has been satisfied to let the DOD take the initiative. The result is an IRS like, bureaucratic maze of forms and regulations. It is time for the commercial CM world to stand up and be counted.

Several organizations have helped the discipline. The Association for Configuration and Data Management (ACDM) has blossomed into a wondrous resource. However, a lack of understanding of the basics still exists. This book will answer the challenge and keep it simple – that is the goal!

Organization of Configuration Management

Let us examine the CM organization starting with the names it is called – the organizational names that is. The terminology varies depending upon the company. Some common names are:

• Engineering Documentation Control.

• Revision Drafting.

• Documentation Control.

• Engineering Services.

• Design Drafting.

• Configuration Management.

Documentation Control may be a proper term, if that is all the function does. There may be several documentation control functions in the company or division – engineering, manufacturing, service, etc. One of these functions (normally engineering) should be designated as the CM function – it will control the total processes by which all do business as well as other functions.

The CM title is preferred when the responsibilities are generally as outlined in this book. When the responsibilities are broader (include functions such as publications, reproduction, data backup, software system input/control, etc.), then the generally preferred name is Engineering Services. Presuming that your company or division organization is slim (few total levels of management), the CM function should answer to the VP of engineering. In larger organizations there may be an engineering services function between CM and the VP of engineering. If the function reports to any lower in the organization, it will not have the necessary clout; communication of needs will suffer, and the result will be more of the symptoms described earlier.

Some companies have the CM function answer to quality assurance (QA), manufacturing, operations, or even (rarely) to the president. If the results are very good, do not change the reporting relationship. It can and does work well or poorly in any organization. Most companies have the function answer to engineering. The question is often asked, Isn't that like having the fox watch the chicken coop? The answer is, Of course, but they're engineering's chickens! We are talking primarily about design documentation!

If engineering has the function and the described symptoms exist, reorganization may or may not solve the problems. The design engineering management, however, runs the risk of losing the function if they eat too many chickens. Location of the function in QA tends to produce rigid over control. No matter which organization has CM, there is always a risk that they will grind their own axe.

Large multi-plant companies should have a CM organization in each business unit or division. They should also have a slim corporate function to ensure that minimum standards are met. This minimum level of standardization should be based upon three criteria:

1. Moving a product from one business unit to another.

2. Customers contact/contract with more than one division or business unit.

3. Field service by a single person for products made in more than one division.

The greatest difficulties arise when engineering is in one location and manufacturing is in another or several different locations. A different building, across town, across the country, across an ocean … the bridge gets longer.

When one of the manufacturing locations is offshore, this adds another level of complication. The ideal results are more likely obtained when the engineering (or at least the continuing or sustaining engineering function), CM, and the manufacturing functions are in the same location (small business unit). This is desirable, regardless of the company size.

Within a business unit, placing CM responsibilities within multiple project offices is inviting chaos.