Engineering Documentation Control / Configuration Management Standards Manual ebook

Contents

Cover

Title page

Copyright page

Introduction

Questions and Answers

Part I Company EDC/CM Policy

Chapter 1 Policy Statement

EDC/CM Manager Job Description

Part II Basic Standards

Chapter 2 Writing CM Standards

Chapter 3 CM Requirements for Drafting Standards

Chapter 4 Technical Document Groups

Chapter 5 Teams for All CM Processes

Chapter 6 Cognizant Engineers

Chapter 7 Part Numbers

Chapter 8 Quantity and Units of Measure

Chapter 9 Bills of Material

Chapter 10 Approved Manufacturers List (AML)

Chapter 11 Deviations

Chapter 12 Spares List

Chapter 13 Prints/Point of Use/Paperless

Chapter 14 Signatures

Chapter 15 Class Coding/Naming Conventions/Group Technology

Chapter 16 Tabulated Documents

Chapter 17 Nameplate and Serial Number

Part III Product and Document Release Process

Chapter 18 Release Policy

Chapter 19 Team in Release

Chapter 20 Phase Release

Part IV Change Request Process

Chapter 21 Change Request Policy

Chapter 22 Team in Request

Chapter 23 Request Form

Part V Change Control Process

Chapter 24 Change Control Policy

Chapter 25 Team in Change

Chapter 26 Change Form

Chapter 27 Interchangeability

Chapter 28 Part Number & Revision Level Changes

Chapter 29 Change Classification

Chapter 30 Mark Up of Design Documents

Chapter 31 Effectivity

Chapter 32 Effectivity Management

Chapter 33 Disposition of Old Design Parts

Chapter 34 Impacted/Affected by a Change

Chapter 35 Product Improvements

Chapter 36 Change Design Complete

Chapter 37 Actual Effectivity Tracking

Chapter 38 Line-Down Change

Chapter 39 Closing a Change

Chapter 40 Tracing Changes

Part VI Changing Product shipped - Field Changes

Chapter 41 Change of Field Units

Chapter 42 Field Change Policy

Chapter 43 Field Change Order Form

Part VII Odds and Ends

Chapter 44 Costing Design Changes

Chapter 45 Data Dictionary

Chapter 46 System Measurements

Chapter 47 Users Guide/CM Plan

Chapter 48 Acronyms and Definitions

Author Biogaphy

End User License Agreement

Guide

Cover

Copyright

Contents

Begin Reading

Pages

ii

iii

iv

ix

x

xi

xii

xiii

xiv

xv

xvi

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

Scrivener Publishing100 Cummings Center, Suite 541JBeverly, MA 01915-6106

Publishers at ScrivenerMartin Scrivener ([email protected])Phillip Carmical ([email protected])

Engineering Documentation Control/Configuration Management Standards Manual

Policies, Procedures, Flow Diagrams, Forms and Form Instructions for Product Manufacturing Companies

This edition first published 2018 by John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA and Scrivener Publishing LLC, 100 Cummings Center, Suite 541J, Beverly, MA 01915, USA© 2018 Scrivener Publishing LLCFor more information about Scrivener publications please visit www.scrivenerpublishing.com.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.

Wiley Global Headquarters111 River Street, Hoboken, NJ 07030, USA

For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.

Limit of Liability/Disclaimer of WarrantyWhile the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials, or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read.

Library of Congress Cataloging-in-Publication DataISBN 978-1-119-47903-1

Introduction

Engineering Documentation Control — sometimes called Configuration Management or Product Lifecycle Management — is a key ingredient to world-class product manufacturing.

Most product manufacturing companies suffer from the “wall syndrome.” The “manufacturing side” bought ERP/Supply Chain tools; the “engineering side” 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 often do not communicate very well. The manufacturing folks say that engineering “throws it over the wall.” The development engineering folks say that you cannot find anyone who knows how the product will be processed. This situation often results in a huge “wall” or “gap” between engineering and operations. A significant part of bridging the gap is to develop “make sense” standards.

There is a very scary tendency in industry today; after the loose identification of a problem, the tendency is to seek a software application solution. App mania!

Software programs may help after you understand the job that needs to be done and what process flow is best for you. Something more substantial (than software) is needed between engineering and operations — Configuration Management. This author may use various terms but will most often use “CM,” as that is the term which is becoming most used in industry.

In order to achieve best-in-class CM it is necessary to document what you do, do what you document and, preferably, continuously improve what you do. Improve what you do by continuous improvement or by reengineering the processes. Of course, brand new startups can leap directly into best in class with these standards.

Yes, there is a gap between engineering and the rest of the company. With this manual you can bridge that gap. It also requires a dedicated and driven CM manager and/or engineering services director.

There are many commercial, military and agency standards — enough to boggle the mind. They will tell you what the expectations are for the “outcome” they desire — but give little help in the “how to.” This manual is directed at how to achieve best-in-class processes which are “make sense,” fast, accurate, efficient, effective, measured and well understood.

With this manual, you have the best of the best management practices for the configuration management processes. They also go a long way toward satisfying Total Quality Management, FDA, GMP, Lean CM and ISO/QS/AS 9XXX process documentation requirements. The one requirement common to all those standards is to document the processes and to do what you document.

This manual has been under development and improvement for many years. It was sold privately by the author for several years. Many copies have been used by engineering documentation control (EDC)/configuration management (CM) managers by editing to suit their particular product manufacturing environment.

This Standards Manual should be an invaluable guide in developing your standards. It will save you many man-hours of research, development, writing, form design and procedural flow design time.

Further understanding of these practices can be obtained by reading the Engineering Documentation Control Handbook and/or CM for Senior Managers.

These standards are designed to maximize the benefits of a fast, accurate and well-understood CM system which will:

Help get new products into the market faster. Reduce delivery time for customized product.

Make happier customers because they will see the new option, change or feature they requested much quicker.

Reduce significantly the manufacturing “bone piles” of rework and scrap material.

Improve Bill of Material accuracy and save the corresponding material and parts costs.

Eliminate multiple Bill of Material databases and save the costs of maintaining the databases and eliminating the risks associated with multiple databases.

Reduce field maintenance, retrofit and repair cost.

Reduce ERP/PLM run time. Avoid weekend computer runs that spill into Mondays.

Make you know exactly what is non-interchangeable in each product and in every product change as required.

Improve the understanding and communications between engineering and manufacturing and others.

Clarify responsibilities to eliminate finger pointing.

Save wear and tear on CM technicians, configuration managers, master schedulers, and engineers.

Help you sort out changes that are not needed or aren’t cost effective.

Cut distribution and save paper and printing costs.

Comply with commercial, government agency, and international standards.

Qualify as a best-in-class producer.

These standards are especially designed to allow fast processing of releases, requests, and changes. Why is process speed so very important? These processes are “just paper/online processing,” how can speed matter? Other than saying “time is money” what specifically do fast processes contribute to improved profits?

The best way to answer these questions is to ask more questions. It is a good idea to have 20-minute meetings with the people involved in the process and ask them to brainstorm why speed is important!

The questions to ask:

How fast/slow is the current process? Perhaps 20 or 40 days just in the CM portion of the change process? (Not an unusual condition.)

Is there more than a few hours of “hands on time” to process a change?

How fast might this portion of the process be? Perhaps 5 days?

What happens during the 15 to 35 unnecessary days?

What are suppliers doing? Building items that will have to be returned, reworked or scrapped?

What is the shop doing? Building items that will have to be reworked or scrapped?

What is assembly and test doing? Working on items that will have to be reworked or scrapped?

Is the line or part of the line “down”? Do we want to keep it that way for 15 to 35 extra days?

Will the change be retrofit? Will we ship 15 to 35 more days worth of product to be retrofit in the field or factory returned?

What if the change is a real cost reduction? Should we ship 15 to 35 days worth of product at the higher cost?

Did the customer request the fix or feature? Should we make the customer wait 15 to 35 unnecessary days to get it?

Is the customer site down? Would you like to be the field service person taking the heat during 15 to 35 extra days?

What is 15 to 35 days of customer good will worth?

Yes, fast accurate and well-understood processes are key to company profitability. In one company, a five day thru-put time was achieved while the engineering and operations process times were also reduced.

A dedicated, motivated CM manager is also key to profitability and to bridging the gap between Design Engineering and Operations. For that reason, the CM manager’s job description should be addressed early on in any process improvement/redesign/reengineer effort. A suggested job description is in Chapter I – Company EDC/CM Policy.

Questions and Answers

Why use the word Standards?

Because it is easier to say and because these writings include policy, procedure, forms, form instructions, flow diagrams and practices.

I’m in the process manufacturing business, not product manufacturing, will these standards help me?

Only partially and will require more editing.

How can they be “best practices” for all product manufacturers?

Each product manufacturing company will have different conditions regarding; current standards, practices, organization, attitude toward configuration management and their software applications. The standards will require editing in regards to those conditions. The standards, however, are based upon the authors work experience (5 companies), consulting experience (over 75 companies), seminar interaction (over 4,000 people from hundreds of companies), and three best-selling books in the field. That experience tells the author that the basics of CM do not change — unlike our product designs.

How can they satisfy the requirements of all commercial, military and international standards?

Allow this author to quote from one customer’s letter: “_______ would like to thank you for some of the best wisdom regarding configuration management. We were recently awarded several quality awards and received our IS9001 and AS9100 certification last month. A majority of our audit revolved a great deal around design and development control. We received 100% scores in these areas resulting from techniques we used in your book. We are an old but newly managed Aerospace company serving the world. Some customers are NASA, Lockheed, Airbus, Boeing, Raytheon, and Sikorsky. All of these companies have accepted our methods and most have commented that they wish their system was as simple. We feel confident that your ‘good logic’ will continue to grow our company for many years to come.”

Is there some redundancy in the standards?

Yes, to highlight important requirements when relative.

How are they best used?

Circumstances will vary with company size, age, extent of current documentation, company culture, management’s understanding of CM and goals. A new startup product manufacturing company, with some editing, can implement much of this “system” in total. Some will want to “pick and choose” among the many standards to enhance their system. If your company has a particularly troublesome process it might take priority, but the basics should always be put in place first.

In what order should I take on the editing/implementing of the standards for my company?

Start your standards by understanding the author’s “generic best of the best process” by reading Standard #47 – the Users Guide / CM Plan. You should eventually write such an “overview document / CM Plan” for your company/group. It can be given to anyone who asks; “How does the EDC/CM system work?”

If you do not have a satisfactory job description for your CM manager, edit the one found in the chapter on Company EDC / CM Policy and get management approval.

Then read and rewrite as necessary the standard on writing CM standards (#02) and then develop your acronyms standard and the definitions in Standard #48.

It is then wise to start from the “bottom up.” That is, begin with basics such as the policy statement, part numbering, interchangeability, etc. (Standards 01 thru 17). Rewrite them to suit your terminology, one at a time, and obtain approval. Get some successes under your belt and then move on to harder subjectsinter-changeability).

Obtain approvals from the highest possible management level you can interest in this project.

Next, ask yourself if you are going to document current practices or attempt to improve current practices in conjunction with writing the standards. It is often best to document the current process since very often the parties involved may not even agree on what the current process is.

Flow diagram the current process and draft an improved process work flow (Release, BOM, Request or Change). Use P3 — Principal of Planned Plagiarism — to develop your own version of that process. Write the supporting standards for that process.

How many processes are there in the “system”?

This author deems the Release, Change Request, Change as separable processes. The BOM-related standards could also be called a process but aren’t easily put into a flow diagram. The field change process is easily separated from the factory change as is done in these standards. So, the answer is: “Whatever you want them to be!” Divide and conquer when practical.

How can one show that implementation of the standards is effecting improvement?

Measure the processes as outlined in Standard ##46 and in the CM Metrics book.

What if, in some cases, I can’t “sell” the author’s approach?

Don’t belabor any given standard if you do not get management support. Move on to the next subject. Come back to that issue later.

There are many commercial, government and international standards that one must conform to, so what effect does that have on the standards?

The principles and practices found in these standards will almost always conform to those documents. All of those documents require written standards which must be followed in practice. Some terminology editing may be necessary. Take care to read those standards yourself rather than taking an auditors word for what they say.

The CM function is sometimes found in QA or Operations, how does that affect the standards?

In one case the author found the document control function answering to the founder/CEO. The only effect on the standards is organizational editing.

How can the other folks involved better understand the guiding principles behind the standards?

Study standard #1 Policy Statement. Read the Engineering Documentation Control Handbook. It is loaded with “Rules” and “Reasons.”

Why have a separate standard for requesting change than for making changes?

There are many reasons spelled out in the EDC Handbook — chief among them is that a different set of people should be involved in reviewing requests than in redesign, reviewing, approving and implementing.

What is the difference between “cost estimation” and “calculating”