118,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Wiley Series in Systems Engineering and Management
- Sprache: Englisch
A systems-level approach to reducing liability through process improvement
Forensic Systems Analysis: Evaluating Operations by Discovery presents a systematic framework for uncovering and resolving problematic process failures. Carefully building the causal relationship from process to product, the discussion lays out in significant detail the appropriate and tactical approaches necessary to the pursuit of litigation with respect to corporate operations.
Systemic process failures are addressed by flipping process improvement models to study both improvement and failure, resulting in arguments and methodologies relevant to any product or service industry. Guidance on risk analysis of operations combines evaluation of process control, stability, capability, verification, validation, specification, product reliability, serial dependence, and more, providing a robust framework with which to target large-scale nonconforming products and services.
Relevant to anyone involved in business, manufacturing, service, and control, this book:
- Covers process liability and operations management from both engineering and legal perspectives
- Offers analyses that present novel uses of traditional engineering methods concerning risk and product quality and reliability
- Takes a rigorous approach to system tactics and constraints related to product and service operations and identifies dysfunctional processes
- Offers both prescriptive and descriptive solutions to both the plaintiff and the defendant
The global economy has created an environment in which huge production volume, complex data bases, and multiple dispersed suppliers greatly challenge industrial operations. This informative guide provides a practical blueprint for uncovering problematic process failures.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 674
Veröffentlichungsjahr: 2017
Ähnliche
Table of Contents
Cover
Title Page
Preface
References
1 What Is Forensic Systems Engineering?
1.1 Systems and Systems Engineering
1.2 Forensic Systems Engineering
References
2 Contracts, Specifications, and Standards
2.1 General
2.2 The Contract
2.3 Specifications
2.4 Standards
Credits
References
3 Management Systems
3.1 Management Standards
3.2 Effective Management Systems
3.3 Performance and
Performance
3.4 Addendum
Credits
References
4 Performance Management
4.1 Background of ISO 9000
4.2 Form and Substance
Credits
References
5 The Materiality of Operations
5.1 Rationale for Financial Metrics
5.2 Mapping Operations to Finance
Credits
References
6 Process Liability
6.1 Theory of Process Liability
6.2 Process Liability and the Law
Credits
References
7 Forensic Analysis of Process Liability
7.1 Improper Manufacturing Operations
7.2 Management Responsibility
References
8 Legal Trends to Process Liability
8.1 An Idea Whose Time Has Come
8.2 Some Court Actions Thus Far
References
9 Process Stability and Capability
9.1 Process Stability
9.2 Process Capability
9.3 The Rare Event
9.4 Attribute Testing
References
10 Forensic Issues in Product Reliability
10.1 Background in Product Reliability
10.2 Legal Issues in the Design of Reliability
10.3 Legal Issues in Measuring Reliability
10.4 Legal Issues in Testing for Reliability
10.5 When Product Reliability Is not in the Contract
10.6 Warranty and Reliability
References
11 Forensic View of Internal Control
11.1 Internal Controls
11.2 Control Stability
11.3 Implementing Controls
11.4 Control of Operations
References
12 Case Study
12.1 Background of the Case
12.2 Problem Description
12.3 Examining the Evidence
12.4 Depositions
12.5 Problem Analysis
12.6 Arriving at the Truth
12.7 Damages
References
13 Examining Serially Dependent Processes
13.1 Serial Dependence: Causal Correlation
13.2 Properties of Serial Dependence
13.3 Serial Dependence: Noncausal Correlation
13.4 Forensic Systems Analysis
Credits
References
14 Measuring Operations
14.1 ISO 9000 as Internal Controls
14.2 QMS Characteristics
14.3 The QMS Forensic Model
14.4 The Forensic Lab and Operations
14.5 Conclusions
Credits
References
15 Stability Analysis of Dysfunctional Processes
15.1 Special Terms
15.2 Literature Review
15.3 Question Before the Law
15.4 Process Stability
15.5 Conclusions
Credits
References
16 Verification and Validation
16.1 Cause and Effect
16.2 What Is in a Name?
16.3 The Forensic View of Measurement
References
17 Forensic Sampling of Internal Controls
17.1 Populations
17.2 Sampling Plan
17.3 Attribute Sampling
17.4 Forensic System Caveats
References
18 Forensic Analysis of Supplier Control
18.1 Outsourcing
18.2 Supply Chain Management
18.3 Forensic Analysis of Supply Systems
18.4 Supplier Verification: A Case Study
18.5 Malfeasant Supply Systems
References
19 Discovering System Nonconformity
19.1 Identifying Nonconformities
19.2 The Elements of Assessment
19.3 Forming Decisions
19.4 Describing Nonconformities
19.5 A Forensic View of Documented Information
Acknowledgment
References
Appendix A: The Engineering Design Process
A.1 Design and Development
A.2 Forensic Analysis of the Design Process
References
Appendix B: Introduction to Product Reliability
B.1 Reliability Characteristics
B.2 Weibull Analysis
B.3 Design for Reliability
B.4 Measuring Reliability
B.5 Testing for Reliability
References
Appendix C: Brief Review of Probability and Statistics
C.1 Measures of Location
C.2 Measures of Dispersion
C.3 Distributions
C.4 Tests of Hypotheses
C.5 Ordered Statistics
References
Appendix D: Sampling of Internal Control Systems
D.1 Populations
D.2 Attribute Sampling
D.3 Sampling Risks
D.4 Sampling Analysis
References
Appendix E: Statistical Sampling Plans
E.1 Fixed‐Size Attribute Sampling Plan
E.2 Stop‐or‐Go Sampling
E.3 One Hundred Percent Inspection
E.4 Application: An Attribute Sampling Plan
References
Appendix F: Nonstatistical Sampling Plans
F.1 Sampling Format
F.2 Nonstatistical Estimations
References
Index
End User License Agreement
List of Tables
Chapter 02
Table 2.1 A partial list of performance standards and their sponsors.
Chapter 04
Table 4.1 Quality management system requirements of ISO 9001.
Table 4.2 Partial list of documents in conduct of operations.
Table 4.3 IT monitoring factors mapped to ISO 9001.
Chapter 05
Table 5.1 Comparison of some controls for CobIT and for ISO 9001.
Table 5.2 The costs of quality.
Chapter 07
Table 7.1 Some operations that may indicate malfeasance.
Chapter 10
Table 10.1 Good design practices from ISO 9001.
Chapter 11
Table 11.1 Some events that may require integral or rate control.
Chapter 19
Table 19.1 Analyzing observations to form decisions.
Table 19.2 The nature of a finding.
Table 19.3 The elements of nonconformity description.
Appendix C
Table C.1 Errors in a test of hypothesis.
Appendix D
Table D.1 Alpha and beta errors related to decision analysis.
Table D.2 Correspondence of standard deviations to confidence level.
Appendix E
Table E.1 Sample sizes for tests of controls.
Table E.2 The relationship of beta error and deviation rates.
Table E.3 Sample sizes for stop‐or‐go sampling (zero expected deviation rate).
Table E.4 Sampling strategy of the
Wild Rover
forensic team.
Appendix F
Table F.1 Selecting audit confidence level as a function of the ADR.
List of Illustrations
Chapter 02
Figure 2.1 An effective contracting process.
Chapter 04
Figure 4.1 A model of a management system for operations.
Figure 4.2 A paper trail of manufacturing.
Chapter 05
Figure 5.1 The IT Governance Institute model of performance.
Chapter 07
Figure 7.1 A classic closed‐loop system.
Chapter 09
Figure 9.1 Phase plane geometry of dynamic system stability. (a) A bounded trajectory in state space near a stable equilibrium point,
X
e
and (b) Covariance diminishing with increasing
k
, of a distribution in equilibrium with weak stationarity.
Figure 9.2 Normal distribution of a random variable.
Figure 9.3 A control chart of a characteristic (key) value.
Figure 9.4 Process variation superimposed on specification limits.
Chapter 11
Figure 11.1 “Turtle diagram” of a generalized process.
Figure 11.2 A closed‐loop control system with corrective path.
Figure 11.3 A PID feedback control structure.
Figure 11.4 Lead and lag responses to a step input.
Chapter 13
Figure 13.1 A generalized work station scenario.
Figure 13.2 Increasing probability of nonconformity in serially dependent work stations.
Figure 13.3 Exponential increase in negative float from serially dependent events.
Chapter 15
Figure 15.1 A causal diagram of process and product.
Figure 15.2 Response curve of a nonstationary AR(1) time series,
ϕ
= 2.
Figure 15.3 Process response to a step disturbance,
ϕ
= 0.1 (weak correlation).
Figure 15.4 Process response to a step disturbance,
ϕ
= 0.6 (moderate correlation).
Figure 15.5 Process response to a step disturbance,
ϕ
= 1.0 (full correlation).
Chapter 16
Figure 16.1 US labor sector productivity, 1950–2016.
Figure 16.2 The costs of conformance.
Chapter 18
Figure 18.1 A general purchasing system with supplier control.
Figure 18.2 The V50 test result of an acceptable design of body armor.
Chapter 19
Figure 19.1 Quality documentation arrayed in tiers.
Appendix A
Figure A.1 The design and development process.
Appendix B
Figure B.1 Product life cycle phases (bathtub model).
Figure B.2 Examples of Weibull distributions.
Figure B.3 A Weibull probability plot.
Figure B.4 Examples of the B‐percentile of product life.
Figure B.5 A cause‐and‐effect diagram.
Figure B.6 A Weibull graph of time to failure.
Figure B.7 An example of accelerated life testing.
Appendix C
Figure C.1 The normal distribution.
Figure C.2 (a) Continuous and (b) discrete distributions skewed right.
Figure C.3 A hypothesis of process nonconformity.
Appendix D
Figure D.1 The interaction of alpha and beta errors.
Figure D.2 An estimated deviation rate with confidence intervals.
Appendix E
Figure E.1 Population size versus the required sample size.
Figure E.2 Distributions of expected and shifted SDRs.
Guide
Cover
Table of Contents
Begin Reading
Pages
ii
iii
iv
v
vi
vii
xix
xx
xxi
xxii
xxiii
xxiv
xxv
xxvi
xxvii
1
2
3
4
5
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
47
48
49
50
51
52
53
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
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
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
273
274
275
276
277
278
279
280
281
282
283
284
285
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
Wiley Series in Systems Engineering and Management
William Rouse, Editor
Andrew P. Sage, Founding Editor
ANDREW P. SAGE and JAMES D. PALMERSoftware Systems Engineering
WILLIAM B. ROUSEDesign for Success: A Human‐Centered Approach to Designing Successful Products and Systems
LEONARD ADELMANEvaluating Decision Support and Expert System Technology
ANDREW P. SAGEDecision Support Systems Engineering
YEFIM FASSER and DONALD BRETINERProcess Improvement in the Electronics Industry, Second Edition
WILLIAM B. ROUSEStrategies for Innovation
ANDREW P. SAGESystems Engineering
HORST TEMPELMEIER and HEINRICH KUHNFlexible Manufacturing Systems: Decision Support for Design and Operation
WILLIAM B. ROUSECatalysts for Change: Concepts and Principles for Enabling Innovation
UPING FANG, KEITH W. HIPEL, and D. MARC KILGOURInteractive Decision Making: The Graph Model for Conflict Resolution
DAVID A. SCHUMEvidential Foundations of Probabilistic Reasoning
JENS RASMUSSEN, ANNELISE MARK PEJTERSEN, and LEONARD P. GOODSTEINCognitive Systems Engineering
ANDREW P. SAGESystems Management for Information Technology and Software Engineering
ALPHONSE CHAPANISHuman Factors in Systems Engineering
YACOV Y. HAIMESRisk Modeling, Assessment, and Management, Third Edition
DENNIS M. SUEDEThe Engineering Design of Systems: Models and Methods, Second Edition
ANDREW P. SAGE and JAMES E. ARMSTRONG, Jr.Introduction to Systems Engineering
WILLIAM B. ROUSEEssential Challenges of Strategic Management
YEFIM FASSER and DONALD BRETTNERManagement for Quality in High‐Technology Enterprises
THOMAS B. SHERIDANHumans and Automation: System Design and Research Issues
ALEXANDER KOSSIAKOFF and WILLIAM N. SWEETSystems Engineering Principles and Practice
HAROLD R. BOOHERHandbook of Human Systems Integration
JEFFREY T. POLLOCK and RALPH HODGSONAdaptive Information: Improving Business Through Semantic Interoperability, Grid Computing, and Enterprise Integration
ALAN L. PORTER and SCOTT W. CUNNINGHAMTech Mining: Exploiting New Technologies for Competitive Advantage
REX BROWNRational Choice and Judgment: Decision Analysis for the Decider
WILLIAM B. ROUSE and KENNETH R. BOFF (Editors)Organizational Simulation
HOWARD EISNERManaging Complex Systems: Thinking Outside the Box
STEVE BELLLean Enterprise Systems: Using IT for Continuous Improvement
J. JERRY KAUFMAN and ROY WOODHEADStimulating Innovation in Products and Services: With Function Analysis and Mapping
WILLIAM B. ROUSEEnterprise Transformation: Understanding and Enabling Fundamental Change
JOHN E. GIBSON, WILLIAM T. SCHERER, and WILLAM F. GIBSONHow to Do Systems Analysis
WILLIAM F. CHRISTOPHERHolistic Management: Managing What Matters for Company Success
WILLIAM B. ROUSEPeople and Organizations: Explorations of Human‐Centered Design
MOJAMSHIDISystem of Systems Engineering: Innovations for the Twenty‐First Century
ANDREW P. SAGE and WILLIAM B. ROUSEHandbook of Systems Engineering and Management, Second Edition
JOHN R. CLYMERSimulation‐Based Engineering of Complex Systems, Second Edition
KRAG BROTBYInformation Security Governance: A Practical Development and Implementation Approach
JULIAN TALBOT and MILES JAKEMANSecurity Risk Management Body of Knowledge
SCOTT JACKSONArchitecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions
JAMES A. GEORGE and JAMES A. RODGERSmart Data: Enterprise Performance Optimization Strategy
YORAM KORENThe Global Manufacturing Revolution: Product‐Process‐Business Integration and Reconfigurable Systems
AVNER ENGELVerification, Validation, and Testing of Engineered Systems
WILLIAM B. ROUSE (Editor)The Economics of Human Systems Integration: Valuation of Investments in People’s Training and Education, Safety and Health, and Work Productivity
ALEXANDER KOSSIAKOFF, WILLIAM N. SWEET, SAM SEYMOUR, and STEVEN M. BIEMERSystems Engineering Principles and Practice, Second Edition
GREGORY S. PARNELL, PATRICK J. DRISCOLL, and DALE L. HENDERSON (Editors)Decision Making in Systems Engineering and Management, Second Edition
ANDREW P. SAGE and WILLIAM B. ROUSEEconomic Systems Analysis and Assessment: Intensive Systems, Organizations, and Enterprises
BOHDAN W. OPPENHEIMLean for Systems Engineering with Lean Enablers for Systems Engineering
LEV M. KLYATISAccelerated Reliability and Durability Testing Technology
BJOERN BARTELS, ULRICH ERMEL, MICHAEL PECHT, and PETER SANDBORNStrategies to the Prediction, Mitigation, and Management of Product Obsolescence
LEVANT YILMAS and TUNCER ORENAgent‐Directed Simulation and Systems Engineering
ELSAYED A. ELSAYEDReliability Engineering, Second Edition
BEHNAM MALAKOOTIOperations and Production Systems with Multipme Objectives
MENG‐LI SHIU, JUI‐CHIN JIANG, and MAO‐HSIUNG TUQuality Strategy for Systems Engineering and Management
ANDREAS OPELT, BORIS GLOGER, WOLFGANG PFARL, and RALF MITTERMAYRAgile Contracts: Creating and Managing Successful Projects with Scrum
KINJI MORIConcept‐Oriented Research and Development in Information Technology
KAILASH C. KAPUR and MICHAEL PECHTReliability Engineering
MICHAEL TORTORELLAReliability, Maintainability, and Supportability: Best Practices for Systems Engineers
DENNIS M. BUEDE and WILLIAM D. MILLERThe Engineering Design of Systems: Models and Methods, Third Edition
JOHN E. GIBSON, WILLIAM T. SCHERER, WILLIAM F. GIBSON, and MICHAEL C. SMITHHow to Do Systems Analysis: Primer and Casebook
GREGORY S. PARNELLTrade‐off Analytics: Creating and Exploring the System Tradespace
CHARLES S. WASSONSystems Engineering Analysis, Design and Development
Forensic Systems Engineering
Evaluating Operations by Discovery
William A. Stimson
This edition first published 2018© 2018 John Wiley & Sons, Inc.
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.
The right of William A Stimson to be identified as the author of this work has been asserted in accordance with law.
Registered OfficesJohn Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
Editorial Office111 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.
Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of WarrantyThe publisher and the authors 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 fitness for a particular purpose. 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 every situation. In view of on‐going research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. The fact that an organization or website is referred to in this work as a citation and/or potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this works was written and when it is read. No warranty may be created or extended by any promotional statements for this work. Neither the publisher nor the author shall be liable for any damages arising here from.
Library of Congress Cataloging‐in‐Publication Data
Names: Stimson, William A., author.Title: Forensic systems engineering : evaluating operations by discovery / William A. Stimson.Description: Hoboken, NJ : Wiley, 2018. | Series: Wiley series in systems engineering and management | Includes bibliographical references and index. |Identifiers: LCCN 2017039503 (print) | LCCN 2017042410 (ebook) | ISBN 9781119422761 (pdf) | ISBN 9781119422785 (epub) | ISBN 9781119422754 (hardback)Subjects: LCSH: Failure analysis (Engineering) | System failures (Engineering) | Forensic sciences. | Evidence, Expert. | BISAC: TECHNOLOGY & ENGINEERING / Electronics / General.Classification: LCC TA169.5 (ebook) | LCC TA169.5 .S755 2018 (print) | DDC 620/.00452–dc23LC record available at https://lccn.loc.gov/2017039503
Cover Design: WileyCover Image: © Digital Vision./Gettyimages
To Josette,
my love,
my wife,
my friend,
my life.
Preface
Scientific theories deal with concepts, never with reality. All theoretical results are derived from certain axioms by deductive logic. The theories are so formulated as to correspond in some useful sense to the real world whatever that may mean. However, this correspondence is approximate, and the physical justification of all theoretical conclusions is based on some form of inductive reasoning
(Papoulis, 1965).
The profession of law is several thousand years old, at least. Given this history, it is quite natural that tradition would have an important role. This is especially true in English Common Law, in which precedence has a major influence on judicial decisions. During the past 100 years or so, product liability has developed as the basis of tort law when there is a question of harm caused by a product or service, and thus enjoys the influence of tradition. During much of this time, production volume was relatively low, claims were low in proportion, and over the years, litigation involving product liability became relatively straightforward.
Today, production volume can be massive—hundreds of thousands of units produced and sold annually, with claims increasing in proportion. The result has been class action suits and large volume manufacturing suits, all continuing to be prosecuted by product liability, one claim per unit. From an engineering point of view, this process is inefficient and even ineffective. As seen by engineers, a far more effective mechanism for litigation would be process liability.
The concept of process liability was first defined by attorney Leonard Miller (5 New Eng. L. Rev. 163, 1970) in his article, “Air pollution control: An introduction to process liability and other private actions.” Being unschooled in law, I do not know the present status of this idea in legal circles, but it is certainly helpful in forensic analysis and in systems engineering. In this book, process liability is shown to be a direct result of systems engineering procedures and methodologies applied to business operations.
Engineers have long recognized the strong correlation of process to product and many mathematical models are commonly used that can validate this cause and effect relationship. Process liability provides a needed legal basis in forensic application. Forensic Systems Engineering offers a complete approach to the investigation of large volume operations by uniting the concept of process liability to systems engineering.
Organization of the Book
The purpose of forensic systems engineering is to identify dysfunctional processes and to determine root causes of process failure, and further, to assist the court in determining whether harm or a breach of contract has occurred. Chapters 1 through 6 describe the role of management in operations. Chapters 7 through 11 unite liability to the essential characteristics of processes used in these operations. Chapter 12 is a fictional case study of a manufacturer, albeit based on actual events. The narration of the study is similar to the narrative technique used in many graduate schools of business.
Chapters 13 through 15 offer formal mathematical models, widely accepted in systems engineering, to demonstrate the correlation of process to product in terms of the risk of liability. Chapter 16 delves into the most troubling area found in my years as a consultant and expert witness in the litigation of business operations—the verification and validation of processes. Chapter 17 discusses the difficulty of supplier control in the age of offshore outsourcing and supply chain management. Chapter 18 addresses an unavoidable aspect of process evaluation via discovery, the effect of sampling. Finally, Chapter 19 discusses the process of identifying nonconformities in discovery and how to assess them.
Appendices A through F provide certain basic information to the reader in those subjects that are essential to forensic systems engineering and analysis. Appendices A and B are detailed accounts of engineering issues that occur more frequently in contract litigation than others. Appendix A concerns design and development; Appendix B concerns product reliability and should be considered by the reader as a prerequisite for Chapter 10.
Appendices C through F address the statistical nature of production and service processes and the fact that a forensic audit of discovery is effectively a sampling process. Therefore, the procedures of sampling and of statistics apply. These appendices, too, should be perused before Chapter 18, and they would be helpful in understanding Chapters 13 through 16. These latter chapters introduce the subject of risk, which is a probability, and employ various mathematical models of random variables.
Definitions and Terms of Art
One of the things that I admire about the profession of law is that when a specific idea requires a unique definition, it is expressed in Latin. Examples abound: nolo contendere, habeas corpus, qui tam, and so on. The terminology is effective because it is constant over time and does not compete with the common language. Unfortunately, engineering lacks this insight. When engineers want to express a specific idea, they borrow terms from the common language even though the engineering definition may have little to do with common understanding. One example will suffice. A system is called controllable if it can be taken from an initial state to any other state in finite time. I have witnessed a meeting at NASA aborted because someone used the word “controllable” in its general meaning, thereby confusing the conversation.
In addition, even terms within engineering context vary in their meaning, depending upon the audience. The meaning of terms such as production, operations, process, and system may differ from one group to another in the business and technical community. Therefore, to prevent confusion I have provided the definition of certain technical terms as they are intended in this book.
Discovery
Discovery is a pretrial procedure in a lawsuit in which each party in litigation, by court order, may obtain evidence from the other party by means of discovery devices such as documents, interrogatories, admissions, and depositions. The term “discovery” hence refers to the body of evidence available to each party in their pursuit of justice.
Production, Service, and Operations
For brevity, in this book the phrase “production or service” is called “operations.” On occasion, I may use “production” in lieu of “operations,” but only if the context is manufacturing. Or I may use the term “product” when speaking of operations in accordance with common usage. For example, I may speak of product quality or product reliability even though I implicitly include service, and ask the reader to bear in mind that service also has the traits of quality and reliability that apply to production. From a systems viewpoint, there is little or no difference between production and service. For this reason, for additional brevity I may use the term “unit” in place of the phrase “product or service.” For example, I might say 10 units proved to be nonconforming to requirements. These units could be 10 jet engine fan blades or they could be 10 billing accounts, depending on the context of the discussion.
Management System
The classical role of management is described in five functions: plans, organization, coordination, decision, and control (Laudon & Laudon, 1991). It is reasonable to assume that a systematic approach to these activities will optimize the effectiveness and efficiency of their results. Such an approach is called a management system. The overall system includes structures for self‐correction and for improving performance. The functions become subsystems of the management system, whose role is to achieve a synergistic direction to corporate goals.
With a system of management, operations can be conducted in an orderly fashion such that responsibility, authority, and accountability may be assigned with documented procedures and traceable results. The documentation and traceability do more than provide a basis from which risk assessment and methods of improvement can be made. They also provide forensic evidence if litigation arises. The evidence may support the defense or the plaintiff, depending on its nature.
The effectiveness of management will be a result of this system. Critics claim that too strict an adherence to formal procedures will stifle innovation. On the other hand, no system at all invites fire drill modes and chaos. Forensic systems engineering will measure the effectiveness of a management system in litigation by its conformity to contract requirements. The justification for this strategy is developed throughout this book.
Performance Standard
A management system has both form and substance. The form might derive from a standard of management. In this book, frequent reference is made to standards of management whose objective is the effective performance of operations in assuring the quality of the product or service rendered. Systematic operation is essential to effectiveness and can be enhanced by management standards. Such a standard is often called a quality management system (QMS) because its purpose is to improve the quality of whatever is being produced or served. For example, ISO 9001 is such a standard.
It is not unusual that in describing a document, the words management, performance, standard, and quality all occur in the same paragraph. To minimize this repetition, I may refer to such a document according to the characteristic being discussed and call it a standard of quality management, a standard of performance, or a standard of operations. In all cases, I am talking about the same thing—the effective management of business operations.
In short, I equate a standard of performance to a standard of quality management. This convention may be controversial because “quality” has, in industry, a nebulous definition. Many a company sharply distinguishes between its operations function and its quality function. Yet, assuming that a process is causal, then quality either refers to the goodness of operations or it has little meaning. (Some might argue whether a process is causal, but engineers do not and this book goes to great lengths to demonstrate the causal relation between process and product.) I regard ISO 9001 has a parsimonious set of good business practices and therefore an excellent performance standard, recognizable as such in a court of law.
A system and a standard for that system have a straightforward relationship—that of form and substance. We might say that form is a model of something; substance is the reality of it. Philosophically, the entity may or may not have physical substance. A violin can be substantive, but the music played on it may also be substantive. Relative to standard and system, the former provides the form and the system provides the substance. Both are deemed necessary to effective performance and the forensic evidence of nonconformity in either can lead to product or process liability.
A forensic investigation is akin to an audit in that it compares the descriptive system to the normative—what it is to what it should be. An effective examination of evidence will reveal what the system is doing; what it should be doing requires a relevant standard. In forensic analysis of operational systems, any recognized performance management standard can serve this role. By “recognized,” I mean a standard that is recognized within the appropriate industry and by the law. Chapter 2 provides a list of several well‐recognized performance standards that would carry weight in a court of law. All of them are very good in enhancing the effectiveness of operations, but not all of them are general enough to cover both strategic and tactical activities. A standard is needed for the purpose of explaining forensic systems engineering and ISO 9001 (2015) is selected as the model standard of this book because of its international authority.
I must admit that the selection of ISO 9001 as the standard of performance for this book is taken with some unease. This standard is rewritten every few years, not in its fundamentals but in its format. A good practice in, say, Clause 3 of one year may appear in Clause 5 in another year and perhaps even under another name or with a slightly different description. I beg the reader to understand that in this book, a reference to an ISO 9001 control or to its information refers to an accepted universal principle or action and not to a particular clause, paragraph, or annual version. For forensic purposes, any reference to ISO 9001 can be defended in court, although tracking down the itemized source may take some ingenuity.
Process Liability
The notion of process liability as it applies to operations is discussed in considerable detail in Chapter 6, but the subject is crucial to forensic systems engineering and appears often in various chapters of this book as it is applied to different situations. At this point, I shall not present the argument for process liability but simply introduce its genesis.
In his paper cited earlier, attorney Leonard A. Miller introduced the concept of process liability and traced legal precedents that justified its use. With permission of Mr. Miller and of the New England Law Review, several paragraphs are extracted from his paper and inserted in this book because of their pertinence to forensic investigation. Although referring to pollution control, his arguments for process liability are logically and clearly applicable to nonconforming or dysfunctional processes, as explained in Chapter 6.
Controllability, Reachability, and Observability
Formally, a system is controllable if it can be taken from any initial state in its state space to its zero state in finite time. A system is reachable if it can be taken from the zero state to any other state in finite time (Siljak, 1969). Over the years, the need to distinguish between system controllability and reachability has lessened and the latter has largely disappeared, simply by making a minor change in the definition of controllability to include the property of reachability. This explains the earlier definition I used in talking about the engineering use of common words: Engineers today say that a system is controllable if it can be taken from any initial state to any other state in finite time.
A system is completely observable if all its dynamic modes of motion can be ascertained from measurements of the available outputs (Siljak). Observability is no small issue in forensics because of its relation to verification and validation, which obviously require the property of observability. From an engineering point of view, inadequate processes of verification and validation render a system unobservable and are major nonconformities in management.
Process and System
The terms system and its kin, process, have no standard meaning in business and industry. Historically, they have carried different connotations and still do. For example, the international management standard, ISO 9000 (2005), distinguishes between them, defining a process as a set of interrelated or interacting activities which transforms inputs into outputs, and defining a system somewhat differently, omitting the dynamic sense assigned to a process.
In systems theory, they are regarded as the same thing. R.E. Kalman et al. (1969) defined a system as a mathematical abstraction—a dynamical process consisting of a set of admissible inputs, a set of single‐valued outputs, all possible states, and a state transition function. Since a system is a dynamical process in systems theory and a process is dynamical by definition of ISO 9000, the terms are considered equivalent in this book. I may use “process” and “system” where they are traditionally used, but I ask the reader to bear in mind that they behave the same way. The elements that compose a process or system may be called a subprocess or subsystem.
Product and Process Quality
Over the years there have been many definitions of “quality” when referring to a product, but the international definition used in this book is provided by ISO 9000 (2005): quality is the degree to which a set of inherent characteristics of a product or service fulfils requirements. Conformity is the fulfillment of a requirement; nonconformity is the nonfulfillment of a requirement. The requirements may denote those of a unit, customer, or the QMS. These definitions are also used in this book because they are good ones, implying how one might measure quality.
However, from a systems view, the definition of quality is necessary but not sufficient, as it infers nothing about the system that provides the product or service. One of the major objectives of this book is to demonstrate a causal relation between the conformance of a process and the conformance of its output. Any definition of quality should accommodate this relationship. Therefore, in Chapter 5, I offer an additional measure of “quality”: it refers to the effectiveness of productive and service processes in assuring that products and services meet customer requirements.
Acceptable Quality and Acceptable Performance
In the context of product and process, manufacturing uses two similar terms. Recognizing that no process is perfect, industry employs the metric, acceptable performance level (APL), defined as the lowest acceptable performance level of a function being audited (Mills, 1989). However, the term is not used in reference to a performance objective, but it is used simply to determine a sample size.
Similarly, recognizing that no sampling plan is perfect, industry employs the metric, acceptable quality level (AQL), defined as the largest percent defective acceptable in a given lot (Grant & Leavenworth, 1988). From the standpoint of auditing controls, the two criteria are essentially identical. Therefore, in this book the term, acceptable performance level, is preferred when referring to either concept because it has a greater sense of systems activity, suggesting both a dynamism and a broad perspective, in keeping with systems thinking.
Effectiveness and Efficiency
In litigation, it is critical that the meaning of a term be clear and unambiguous. I generally follow the definitions of ISO 9000 (2005). Effectiveness is the extent to which planned activities are realized and planned results are achieved. Efficiency is the relationship between the results achieved and the resources used. Briefly, then, effectiveness is a measure of how good the process is; efficiency is a measure of the cost to obtain that goodness.
Compliance and Conformance
Because financial auditing is subject to legal review, its procedures are well developed and formal. They are acknowledged and respected in courts of law. Forensic systems engineering is fundamentally an audit of evidence in discovery and as such the analysis should be conducted in a manner acceptable in court. Therefore, I often refer to the techniques of financial auditing in this book and use some of its terms, although they may differ somewhat from their meaning in business operations. Compliance is one such term.
A financial auditor audits financial reports for compliance to legal requirements. This corresponds closely with the definition of compliance used in manufacturing or service operations: Compliance is the affirmative indication or judgment that the performer of a product or service has met the requirements of the relevant contract, specifications, or regulation (Russell, 1997). In contrast, the same source defines conformance as the affirmative indication or judgment that a product or service has met the requirements of the relevant contract, specifications, or regulation.
Because of the kinship of process and product in liability, I continue with this kinship in performance and usually speak of the conformance of a control rather than of its compliance. This assignment can get complicated if the control is nonconforming because of misfeasance, which suggests that the control is noncompliant also. At the end of the day, the wording to be used in litigation will be determined by attorneys and not by forensic analysts or engineers.
Framework and Model
The word framework has several meanings but the one used quite often in business is that of a basic structure underlying a system, concept, or text. You see the word several times in Table 2.1, used in the titles of recognized performance standards. Engineers, however, tend to use the word model possibly because any concept is modeled mathematically before it is physically constructed. Although the two words come from different spheres, they meet in this book and are used interchangeably. Both refer to an organization or structure of elements assembled to affect a purpose. In short, they depict systems.
Sidestepped Definitions
There are several subjects of common occurrence in most civil litigation whose use cannot be avoided, but whose definitions I choose to leave unsaid. Strict liability and due diligence are used in this book in the sense that I understand them. However, I am unschooled in law and prefer that readers look up the meaning of the terms on their own.
Another such term is standard of care. This issue is critical to any critique of management performance and I use it often. Standard of care refers to the watchfulness, attention, caution, and prudence that a reasonable person in the circumstances would exercise. Failure to meet the standard is negligence, and any damages resulting there from may be claimed in a lawsuit by the injured party. The problem is that the “standard” is often a subjective issue upon which reasonable people can differ. I believe that in any specific litigation, standard of care will be decided by the court, so the very general description just given will do for this book.
Redundancy
The reader will find a certain amount of repetition of information in this book, and deliberately so. First, I believe that redundancy is a good teaching tool. Secondly, some important properties, understood in one context, may also be applicable in other contexts. For example, ISO 9001 is regarded internationally as a set of good business practices and this role is important from a number of points of view, each view expressed in a different chapter: Chapter 4, Chapter 5, and Chapter 8. Also, internal controls are defined redundantly: Chapter 5, Chapter 11, Chapter 14, and Chapter 15. As an additional example, a comparison of the terms durability and reliability is made both in Chapter 2 and in Appendix B because the difference is very important and not all readers will read the appendix.
References
ANSI/ISO/ASQ (2005).
ANSI/ISO/ASQ Q9000‐2005: Quality Management Systems—Fundamentals and Vocabulary
. Milwaukee, WI: American National Standards Institute and the American Society for Quality.
ANSI/ISO/ASQ (2015).
ANSI/ISO/ASQ Q9001‐2015: American National Standard: Quality Management System Requirements
. Milwaukee, WI: American National Standards Institute and the American Society for Quality.
Grant, E. L. and Leavenworth, R. S. (1988).
Statistical Quality Control
. New York: McGraw‐Hill, p. 452.
Kalman, R. E., Falb, P. L., and Arbib, M. A. (1969).
Topics in Mathematical System Theory
. New York: McGraw‐Hill, p.74.
Laudon, K. C. and Laudon, J. P. (1991).
Management Information Systems: A Contemporary Perspective
. New York: Macmillan, p. 145
Miller, L. A. (1970). “Air Pollution Control: An Introduction to Process Liability and other Private Actions.”
New England Law Review
, vol. 5, pp. 163–172.
Mills, C. A. (1989).
The Quality Audit
. New York: McGraw‐Hill, p. 172.
Papoulis, A., (1965).
Probability, Random Variables and Stochastic Properties
. New York: McGraw‐Hill.
Russell, J. P., ed. (1997).
The Quality Audit Handbook
. Milwaukee, WI: ASQ Quality Press, p. 12.
Siljak, D. D. (1969).
Nonlinear Systems: Parameter Analysis and Design
. New York: John Wiley & Sons, Inc., pp. 445–446.
1What Is Forensic Systems Engineering?
CHAPTER MENU
1.1 Systems and Systems Engineering
1.2 Forensic Systems Engineering
References
Forensic systems engineering can be defined as the preparation of systems engineering data for trial. This snapshot raises more questions than it answers because neither “systems” nor “systems engineering” enjoy general agreement on what they mean. Forensics is well defined and refers to the application of scientific knowledge to legal problems. Conversely, systems engineering has no generally accepted definition and each discipline holds its own parochial notion of it. When I entered the systems engineering program at the University of Virginia, only one other university in the United States offered a degree in the field.
In the computer world the term refers to the design and implementation of hardware and software assemblies. In the Department of Defense, it refers to large human machine structures. Systems theory itself is substance neutral and can be applied with equal vigor to computers, machines of war, video assemblies, banks, institutions, dams, churches, governments, ports, and logistics—any dynamic activity with a determined goal. So let us begin with the meaning of a system.
1.1 Systems and Systems Engineering
The Kalman et al. (1969) definition of a system, shown in the Preface, is repeated here for facility: a dynamical process consisting of a set of admissible inputs, a set of single‐valued outputs, all possible states, and a state transition function. Two of these criteria are particularly significant in forensics. Admissible inputs are essential to the proper operation of a system and will be important characteristics in forensic investigation. An admissible input is one for which the system was designed. The output of a system subject to inadmissible inputs is not predictable and may be nonconforming to requirements.
In practical operation, the second Kalman criterion of a state transition function refers to that mechanism by which the system changes its state. This mechanism must be controllable and observable. An implementation or change to a system that frustrates these qualifications implies a nonconforming system. In this book, then, I define a “system” as a dynamical process consisting of a set of integrated elements, admissible inputs, and controllable states that act in synergy to achieve the system purpose and goal.
At the University of Virginia’s School of Engineering and Applied Science, Professor John E. Gibson (2007) defined systems engineering as “operations research plus a policy component,” the latter adding the question of “why?” to the engineering “how?” Operations research (OR) concerns the conduct and coordination of operations or activities within an organization (Hillier & Lieberman, 1990). The type or nature of the organization is immaterial and operations research can also be applied to business, industry, the military, civil government, hospitals, and so on. As a forensic examination will compare what is to what should be, then contracts too, may be of concern.
In this book, then, we define systems engineering as the creative application of mathematics and science in the design, development, and analysis of processes, operations, and policies to achieve system objectives.
1.2 Forensic Systems Engineering
Forensic analysis is the application of scientific principles to the investigation of materials, products, structures, or components that fail or do not function as intended. Situations are investigated after the fact to establish what occurred based on collected evidence. Forensic analysis also involves testimony concerning these investigations before a court of law or other judicial forum (Webster, 2008).
If a failing material, product, structure, or component is a subset of a system, then the cause of failure may be the system itself, and if so, failure may be systemic. Therefore, the system itself is properly within the purview of forensic investigation. This idea is particularly important when the failed unit is mass produced and sold widely. An investigation of a failure in Baltimore will say nothing about a similar failure in Miami or elsewhere; there may be systemic failure and only a system level investigation will reveal it. If so, then the productive system, too, requires forensic investigation because only a system‐level approach can determine the root cause.
Therefore, I define forensic systems engineering as the investigation of systems or processes that have failed to achieve their intended purpose, thereby causing personal injury, damage to property, or failure to achieve contracted requirements. The basis of the investigation will be the fit of the system in litigation to contract requirements according to systems engineering criteria. Established systems theory and system analytical tools are used extensively in the investigation. Such tools include probability models, linear and nonlinear programming, queuing theory, Monte Carlo simulation, decision theory, mathematical systems theory, and statistical methods. The purpose of forensic systems analysis is to identify dysfunctional processes, to determine root causes of process failure, and to assist the court in determining whether harm or a breach of contract has occurred.
Forensic systems engineering includes all of the components of engineering: design, development, operations and analysis, and synthesis. Forensic systems analysts will aid counsel in designing and developing case strategy, based on preliminary overview of findings. In this pursuit, they will use formal scientific methods in analysis of evidence.
All products are manufactured and all services organized through business processes that are integrated so as to contribute to a symbiotic or synergistic goal. In this way the processes compose an operational system and systems theory applies. The consequences of system failure can be dealt with by a new legal concept called process liability.
For ease of reference, I repeat from the Preface that in this book the term operations refers to both production and service. Operations can be managed in an orderly fashion with a systematic approach using well‐recognized good business practices, which we shall call a management system. A company with a formal management system has the best opportunity to consistently meet or exceed customer expectations in the goodness of its products and services.
A management system should be synergistic—the parts work together effectively to achieve the system goal. All the productive and supportive activities in the company are integrated and coordinated to achieve corporate goals. All productive processes should be organized in the natural flow of things and supported with necessary resources. This type of structure is called the process approach and is suitable to the newer standards of performance. Also, the performance of the management system is continually measured for effectiveness and efficiency, with structures for improving performance.
The forensic systems analyst should understand the relationship between system and standard. Simply put, a standard is a model—pure form. It does nothing, but it enables things to be done well. Performance standards offer consistency, efficiency, and adequacy. The system is the implementation of the standard and provides the substance. Properly implemented, the system will work well and get things done to the satisfaction of the customer, performer, and shareholder.
An investigation is akin to an audit in that it compares the descriptive system to the normative—what it is to what it should be. As discussed in the Preface, the ISO 9000 (ANSI/ISO/ASQ, 2005) Quality Management System is chosen as the standard model of this book to be used in such comparisons. However, in the absence of a contract requirement for a specific standard, any equally capable standard may do, even a locally developed one. The issue in litigation is whether the performer is prudent in standards of care and due diligence.
In 1970, attorney Leonard A. Miller presented a paper in the New England Law Review that introduced the concept of process liability and traced legal precedents that justified its use. With permission of Mr. Miller, several paragraphs are extracted from his paper and inserted into Chapter 6 because of their pertinence to forensic investigation. Although referring to pollution control, his arguments for process liability clearly apply as a consequence of nonconforming or dysfunctional processes.
Businesses differ in how they refer to their core entities: systems, processes, cost centers, activities, and business units, to name a few. In this book, these terms may be used interchangeably to accommodate the various backgrounds of readers. But whichever terms are used, their dynamic property does not change. Whatever it is called, a system is designed to use states and feedback loops to change admissible inputs into specified outputs. It consists of the resources, inputs, outputs, and feedback mechanisms necessary to make the process work correctly and consistently. The conditions required by every system are (i) the input must be admissible—appropriate to the system design; (ii) the states of the system are established by proper set up; (iii) the feedback loop provides the capability to compare what is to what should be; (iv) and the outputs are in agreement with system objectives. In litigation, each of these conditions can be challenged and may be the focus of forensic investigation.
In sum, a performer offers to provide a product or service to a customer. A contract is drawn up listing customer requirements and the intended use of the product or service. There may also be specifications on the performance itself, such as constraints of cost and time, or the requirement to perform in a certain way, say in accordance with given industrial or international standards. In the event of customer disappointment, a forensic investigation may be called for in which it becomes apparent that a process or operation may be a contributing factor in an adverse outcome. Both plaintiff and defense attorneys may well consider forensic system engineering in their strategies.
References
ANSI/ISO/ASQ (2005).
ANSI/ISO/ASQ Q9000‐2005: Quality Management Systems—Fundamentals and Vocabulary
. Milwaukee, WI: American National Standards Institute and the American Society for Quality.
Gibson, J. E., Scherer, W. T., and Gibson, W. F. (2007).
How To Do Systems Analysis
. Hoboken, NJ: John Wiley & Sons, Inc.
Hillier, F. S. and Lieberman, G. J. (1990).
Introduction to Operations Research
. New York: McGraw‐Hill, p. 5.
Kalman, R. E., Falb, P. L., and Arbib, M. A. (1969).
Topics in Mathematical System Theory
. New York: McGraw‐Hill, p. 74.
Miller, L. A. (1970). “Air Pollution Control: An Introduction to Process Liability and Other Private Actions.”
New England Law Review
, vol. 5, pp. 163–172.
Webster, J. G., contributor (2008). “Expert Witness and Litigation Consulting.”
Career Development in Bioengineering and Biotechnology
, edited by Madhavan, G., Oakley, B., and Kun, L. New York: Springer, p. 258.
2Contracts, Specifications, and Standards
CHAPTER MENU
2.1 General
2.2 The Contract
2.2.1 Considerations
2.2.2 Contract Review
2.3 Specifications
2.4 Standards
Credits
References
I repeat an earlier statement that every investigation is essentially an audit—a comparison of what is to what should be. A forensic investigator will examine the evidence with that perspective in mind. From this viewpoint, any harm, injury, or breach resulting from a failed unit or from a contracted performance is an effect. The root cause will be determined by investigating the performance according to accepted industrial practice. For example, a metallurgist may examine a failed jet vane for metal fatigue. A systems analyst may examine the nonconformance of a process. In every case the forensic systems analyst must have an understanding of the applicable references: contracts, specifications, and standards.
2.1 General
In law, a contract is a formal agreement between parties to enter into reciprocal obligations. It is not necessary that a contract be in writing; verbal contracts are equally enforceable in law. However, in this book we are concerned with written contracts, and in particular, with contracts of performance. One party agrees to pay another party to do something, usually in a certain way and within a specified time. The first party may be called the customer; the second the performer, provider, or in this book, the company.
Necessarily then, conditions are imposed upon the performance. These conditions are called specifications because they specify what must be done. Specifications are not always expressed in numbers, but very often it is practical to do so. Numbers help to demonstrate to the performer exactly what must be done and to the customer that the thing done is exactly what was wanted. Numbers also help to achieve repeatability.
As an example, a family might hire a tutor to educate their children. A curriculum is agreed upon, with a schedule and the education begins. This type of contract can be executed with no numbers assigned at all. However, if numerical grades are assigned to the test scores, then the family receives a measure of the effectiveness of the education. Similarly, a customer might want a blue dress. No number is involved. But a specific blue can be identified with a number, perhaps a wavelength, which then enables the customer and performer to agree on expectations and also enables reproduction of the dress.
Sometimes a number must be specified. Suppose that a customer wants a fast car. A fast car cannot be built. The performer must have an idea of what the customer means by “fast,” and that requirement is best identified with a number. This example demonstrates a condition that occurs more often than not. A customer wants something and quite often expresses this desire qualitatively. For example, the customer may want fresh vegetables, a durable sofa, an efficient washing machine, or an impressive business suit. The performer can provide or manufacture all of these things and to many customers. Inevitably though, for optimum customer satisfaction and for repeatability, all these things must somehow be expressed quantitatively. Freshness of vegetables is often measured in days from picking; durability of a product is often measured in mean time to failure. Efficiency of an operation can be measured in cost per use. A metric for impressiveness presents a challenge, but the cost of the item as indicated by the brand name has been shown to be effective.
In negotiating the contract, the customer is concerned with how well the job will be done. It is cause for concern if the performer has never done this job before. Usually, the customer will want a performer of some experience. This means that the performer has done the job repeatedly and has developed a set of procedures to ensure the quality and cost of the task. Repetition implies that a standard way of doing business has been developed. The standard may be in‐house, that is, unique to that performer, or it may be a set of general good business practices used by many performers engaged in similar activities.
Good business practices have been codified into standard procedures by a large number of industries and institutions in order to improve the capability and professionalism of the industry and to better achieve the expectations of customers. Simply put, it is good business to use good business practices. These practices apply to how things are made and how they are performed. Standards of how things are made are called product standards. There may be legal requirements imposed upon product standards, especially if the product is a drug or medicine. Standards of how things are done are called performance standards. This book is primarily concerned with a certain kind of performance—management standards.
Some standards are simply common sense, although they may vary from country to country. For example, in the United States, the contacts on electrical appliances have two flat pins, usually polarized. In Europe the contacts are round. Some societies adopt standards that meet the requirements of their customers but may not meet others. In recent years, the trend is to international standards. For example, desktop computers are often produced that can perform anywhere that meets their power input requirements. Telephone systems, too, are designed according to internationally agreed standards to enable worldwide conversation. Thus, contracts, specifications, and standards are inseparably entwined. Sometimes both customers and performers make the mistake of treating these issues as separate entities. This mistake is grave and can lead to customer disappointment. The contract must record exactly what the customer wants and what the performer can deliver and must ensure an agreement between them. The specifications must be correct translations of the customer’s requirements, which are not easy to do because quite often the customer requirements are qualitative and the specifications quantitative. The numbers may mean little to the customer, which complicates customer review and approval. Therefore, performance must be done in an acceptable way, in accordance with customer requirements, industry standards, and government regulations.
