109,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Wiley Series in Systems Engineering and Management
- Sprache: Englisch
Presents the foundational systemic thinking needed to conceive systems that address complex socio-technical problems
This book emphasizes the underlying systems analysis components and associated thought processes. The authors describe an approach that is appropriate for complex systems in diverse disciplines complemented by a case-based pedagogy for teaching systems analysis that includes numerous cases that can be used to teach both the art and methods of systems analysis.
- Covers the six major phases of systems analysis, as well as goal development, the index of performance, evaluating candidate solutions, managing systems teams, project management, and more
- Presents the core concepts of a general systems analysis methodology
- Introduces, motivates, and illustrates the case pedagogy as a means of teaching and practicing systems analysis concepts
- Provides numerous cases that challenge readers to practice systems thinking and the systems methodology
How to Do Systems Analysis: Primer and Casebook is a reference for professionals in all fields that need systems analysis, such as telecommunications, transportation, business consulting, financial services, and healthcare. This book also serves as a textbook for undergraduate and graduate students in systems analysis courses in business schools, engineering schools, policy programs, and any course that promotes systems thinking.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 581
Veröffentlichungsjahr: 2016
Ähnliche
Contents
Cover
Wiley Series in Systems Engineering and Management
Title Page
Copyright
Original Preface from Jack Gibson
Preface
Acknowledgments
About the Companion Website
Part I: Primer
Chapter 1: Introduction
1.1 What is a System?
1.2 Terminology Confusion
1.3 Systems Analysis Equals Operations Research Plus Policy Analysis
1.4 Attributes of Large-Scale Systems
1.5 Transportation Systems: An Example of a Large-Scale System
1.6 Systems Integration
1.7 What Makes a “Systems Analysis” Different?
1.8 Distant Roots of Systems Analysis
1.9 Immediate Precursors to Systems Analysis
1.10 Development of Systems Analysis as a Distinct Discipline: The Influence of Rand
References
Chapter 2: Six Major Phases of Systems Analysis
2.1 The Systems Analysis Method: Six Major Phases
2.2 The Goal-Centered or Top-Down Approach
2.3 The Index of Performance Concept
2.4 Developing Alternative Scenarios
2.5 Ranking Alternatives
2.6 Iteration and the “Error-Embracing” Approach
2.7 The Action Phase: the Life Cycle of a System
References
Chapter 3: Goal Development
3.1 Seven Steps in Goal Development
3.2 On Generalizing the Question
3.3 The Descriptive Scenario
3.4 The Normative Scenario
3.5 The Axiological Component
3.6 Developing an Objectives Tree
3.7 Validate
3.8 Iterate
References
Chapter 4: The Index of Performance
4.1 Introduction
4.2 Desirable Characteristics for an Index of Performance
4.3 Economic Criteria
4.4 Four Common Criteria of Economic Efficiency
4.5 Is There a Problem with Multiple Criteria?
4.6 What is Wrong with the B–C Ratio?
4.7 Can Irr Be Fixed?
4.8 Expected Monetary Value
4.9 Nonmonetary Performance Indices
References
Chapter 5: Develop and Evaluate Alternative Candidate Solutions
5.1 Introduction
5.2 The Classical Approach to Creativity
5.3 Concepts in Creativity
5.4 Brainstorming
5.5 Brainwriting
5.6 Dynamic Confrontation
5.7 Zwicky's Morphological Box
5.8 The Options Field/Options Profile Approach
5.9 Computer Creativity
5.10 Trade Study Methods
5.11 Trade Study Example
References
Chapter 6: The 10 Golden Rules of Systems Analysis*
6.1 Introduction
6.2 Rule 1: There Always is a Client
6.3 Rule 2: Your Client does not Understand his Own Problem
6.4 Rule 3: The Original Problem Statement is too Specific: You must Generalize the Problem to Give it Contextual Integrity
6.5 Rule 4: The Client does not Understand the Concept of the Index of Performance
6.6 Rule 5: You are the Analyst, not the Decision Maker
6.7 Rule 6: Meet the Time Deadline and the Cost Budget
6.8 Rule 7: Take a Goal-Centered Approach to the Problem, not a Technology-Centered or Chronological Approach
6.9 Rule 8: Non-Users must be Considered in the Analysis and in the Final Recommendations
6.10 Rule 9: The Universal Computer Model is a Fantasy
6.11 Rule 10: The Role of Decision Maker in Public Systems is Often a Confused One
References
Part Two: Casebook
Cases in Systems Engineering
Introduction
The Case Study Method
What is a “Case”?
Implementing the Case Study Method
The Case Studies
Using Case Studies to Build Teamwork and Communications Skills
Aligning Case Studies with the Ten Golden Rules of Systems Analysis
To Winnebago or to not Winnebago?
How can this Case be used to Teach and Reinforce Systems Analysis?
A Word About the Cases
Validation of Learning: Evidence-Based Learning
Sample Evaluation Instrument: Exam with Solutions
Sample Evaluation Instrument: Exam Without Solutions
Case 1: Great Buys
Attachment A
Case 2: Surf's Up?
Case 3: Extended Engineering Education
Case Study Background
Your Assignment
What to Turn in
Case 4: Systems Engineering Majors Proliferating
What to Turn in
Case 5: Motor Carrier Safety and Compliance
What to Turn In
Appendix
Case 6: Is Getting There Half the Fun?
Case Study Background
Lockn' Revisited
Your Group's Assignment
What to Turn In
Case 7: Is Getting There Half the Fun? (Revisited)
Case Study Background
Your Group's Assignment
What to Turn In
Case 8: Which Camper Should We Choose?
Case Study Background
Your Individual Assignment
What to Turn in for the Individual Assignment
Your Group's Assignment
What to Turn in for the Group Assignment
Case 9: Seat Belt Issue
Case 10: Baseball Free Agent Draft—20xx
Part A: Ranking Free Agents
Part B: Draft Day
Case 11: For the Birds?
Case 12: Wal-Mart Crisis
Memorandum
Case 13: Ocean Cleanup
Case 14: BRAC
Memorandum
Case 15: Opportunity?
Memorandum
Case A:
Case B:
Case 16: Risky Business
Memorandum
Case 17: Corporate Headquarters
Case 18: The Ad Forecaster
Case 19: For the Birds (Revisited)
Case 20: Best MBA?
Case 21: Health Insurance? What Health Insurance?
Case 22: Social Media in Emergency Management
Project Background and Context
Project Objective
Case 23: Which Bridges to Repair?
Case Study Background
Your Team Assignment
Your Individual Assignment
What to Submit
Case 24: Going-to-the-Sun Road Rehabilitation Project
Case Study Background
Purpose and Need for Road Rehabilitation
Alternatives Considered
Data for Use in Multiattribute Decision Modelanalysis
Your Assignment
Case 25: HEV versus HOV?
Should Hybrid Vehicles be Allowed in the HOV Lanes?
Case 26: “Show Me the Money!”
“Show Me the Money”
So What's the Problem?
Case 27: The Collections Subsidiary1
Company Background
Case 28: MNB One Credit Card Portfolio1
MNB One's Card Customer Partitioning
The Portfolios
Valuation of a Customer Account
Other Risk Management Options
Appendix
MNB One Credit Card Portfolio
Case 29: Select Collections1
Company Background
Case 30: To Distance or Not to Distance? Is That the Question?
Index
End User License Agreement
List of Tables
Table 1.1
Table 2.1
Table 2.2
Table 2.3
Table 3.1
Table 4.1
Table 4.2
Table 4.3
Table 4.4
Table 4.5
Table 4.6
Table 4.7
Table 5.1
Table 5.2
Table 5.3
Table 5.4
Table 5.5
Table 5.6
Table 5.7
Table 5.8
Table 5.9
Table 5.10
Table 5.11
Table 5.12
Table 5.13
Table 5.14
Table 24.1
Table 24.2
Table 24.3
Table 24.4
Table 27.1
List of Illustrations
Figure 1.1
Figure 1.2
Figure 2.1
Figure 2.2
Figure 2.3
Figure 3.1
Figure 3.2
Figure 4.1
Figure 4.2
Figure 4.3
Figure 4.4
Figure 5.1
Figure 5.2
Figure 6.1
Figure 1
Figure 2
Figure 3
Figure 24.1
Exhibit 28.1
Exhibit 28.2
Exhibit 28.3
Exhibit 29.1
Exhibit 29.2
Guide
Cover
Table of Contents
Begin Reading
Part 1
Chapter 1
Pages
i
ii
iii
iv
ix
x
xi
xii
xiii
xiii
xiv
xv
xvi
xvii
xviii
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
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
228
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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
Wiley Series in Systems Engineering and Management
Andrew P. Sage, Founding Editor
A complete list of the titles in this series appears at the end of this volume.
How to Do Systems Analysis Primer and Casebook
John E. Gibson
William T. Scherer
William F. Gibson
Michael C. Smith
Copyright © 2017 by John Wiley & Sons, Inc. All rights reserved
Published by John Wiley & Sons, Inc., Hoboken, New JerseyPublished simultaneously in Canada
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, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data
Names: Gibson, John E., author.
Title: How to do systems analysis : primer and casebook / John E. Gibson, William T. Scherer, William F. Gibson, Michael C. Smith.
Other titles: How to do systems analysis (2017)
Description: Hoboken, New Jersey : John Wiley & Sons, Inc., [2017] | Includes index.
Identifiers: LCCN 2016019023 | ISBN 9781119179573 (cloth) | ISBN 9781119179597 (epub)
Subjects: LCSH: System analysis. | System analysis–Case studies.
Classification: LCC T57.6 .G5434 2017 | DDC 658.4/032–dc23 LC record available at https://lccn.loc.gov/2016019023
Original Preface from Jack Gibson
There appear to be three generic points of view one may take in writing a textbook. These are…the problem-centered viewpoint, the technique-centered viewpoint, and the reader-centered viewpoint. Of course, it is also possible to write a book with no consistent point of view at all, one probably need not add. The problem-centered view is not common in general texts but is an acceptable approach for advanced texts on focused, narrow topics. My text, Designing the New City, Wiley, 1977, was written from this perspective. However, if the author has an introductory, general purpose in mind, this approach leads to difficulties. In such a situation, problem-centering usually leads to a book of recipes. That is, the author is led to saying for a series of instances, “given this problem, here is how to handle it.” One becomes bogged down in specifics, and it is difficult to achieve a general perspective of the topic. This is a severe limitation in itself, and, furthermore, it is unappealing to the academic mind. The technique-centered approach is more common in basic introductory texts.
Generally speaking, technique-centered texts typically provide a chapter or two of introduction and then launch into a survey of the main topics and techniques in the field. It is assumed that the reader will be able to select the appropriate tools to solve his or her specific problem. If one is faced with a problem similar to the type of problems used to illustrate the technique under discussion in the text, this is a good approach. But what it gains in general perspective and an overall viewpoint, it may lose in usefulness in applicability. The technique-centered approach seems to be popular with academics, since we generally have a mind bent that seeks general understanding and we are less interested in problem-solving and specifics. I have written several texts with this perspective, among them being Introduction to Engineering Design, Holt, Rinehart & Winston, 1968, and Nonlinear Automatic Control, McGraw-Hill, 1963.
The reader-centered point of view has initial appeal as a guide to the perplexed, but in practice it sometimes descends to pontification and anecdotal generalities—that is, retelling of old and possibly irrelevant personal “war stories.” This approach assumes a common starting point for its readers, and, as in the present text, this starting point is usually an assumption of a reader's unfamiliarity with the topic. Scientific American magazine practices this approach in a masterly way. The first paragraph or two of each of its articles is couched at a simple, obvious level and then acceleration is smooth and gradual.
For better or worse, the reader-centered approach is the one taken in this text. I will assume you are a systems analyst faced with a problem situation. We will go through a step-by-step approach to the application of the systems approach to the situation, using techniques as the need arises. We will not focus on the details of the analytic techniques to be used; it is assumed that you will learn the details of these (mostly mathematical) techniques elsewhere. From the present text, I hope you will learn just what “systems analysis” (SA) is and what the “systems approach” means. You will see from examining the cases, which are based on actual practice, how the need for mathematical techniques develops, and how to apply them. Moreover, I hope that you will develop a sense of the pitfalls and difficulties in practicing SA. This is a tall order, especially for readers without professional work experience.
Unless you are able to provide a “reality check” from your own work experience, you may be tempted to accept the suggestions herein for analyzing problems as simple and obvious. In reality they are neither, but unlike advanced mathematics, which is obviously difficult going in, SA appears almost trivial on first observation. We will discuss this trap as we go on.
JACK GIBSONIvy, VirginiaJanuary 1991
Preface
The systems approach, systems analysis, systems engineering, or systems thinking, whatever one calls the concept, is more likely to be caught than taught. Asking the right questions is often more important than knowing the right answers. The collective experience of the authors in teaching and practicing systems engineering in academia and in the public and private sectors exceeds a combined 100 years. This experience leads us to conclude that the best way for students and practitioners to master the systems concepts is to face realistic, often unstructured, and typically ambiguous problems that require much more than reciting answers or applying methods from the text. Moreover, we have observed that students discover that what they learn from the material presented in Part One of this text becomes integrated into the way they think, as they gain more experience applying the principles and methods through cases such as those provided in Part Two. These cases, developed by instructors based on their professional experience, are situations that students and practitioners face in their own lives, from finding places to live while in school, evaluating employment opportunities, reading about current events and issues, or making other major life decisions.
The unique approach in this book is to motivate systems thinking, or as we like to say: “See the world with new eyes—that of a systems thinker.” Throughout the book are examples from the past and from today's pressing issues, which illustrate these concepts, along with case studies in Part Two to give the reader exposure to the practice of systems analysis and systems engineering. The resulting book is appropriate for numerous fields and professionals that need the perspective and tools of systems analysis, including anyone working in the analysis of complex systems, such as in business consulting, financial services, healthcare, telecommunications, and so on.
The goal of the book is to assist in creating the active learning experience such that both students and practitioners internalize systems thinking and the systems approach as they become more effective systems engineering practitioners, including greater proficiency in both technical and professional competencies. We measure the success of this approach by observing the extent to which students demonstrate good systems thinking in the way they approach cases, conduct analysis, communicate findings and recommendations to clients and other stakeholders, and demonstrate professionalism in their ability to both collaborate with others and conduct themselves within ethical standards of practice.
We believe that present books in the area of systems analysis and engineering are excellent; however, many fail to emphasize the art of systems problem-solving (systems analysis) by focusing instead on operations research methods (mathematical models, such as linear programming) or on the formal systems engineering processes (as stressed by INCOSE: The International Council on Systems Engineering). This book focuses on systems analysis, broadly defined also to include problem formulation and interpretation of proposed alternatives in terms of the value systems of stakeholders. Therefore, this book is a complement, not a substitute, to the other “traditional” books when teaching systems engineering and systems analysis. However, the nature of problem-solving discussed in this book is appropriate to a wide range of systems analyses—thus, it can be used as a stand-alone book for teaching the analysis of systems.
Numerous other books describe the processes of systems engineering, including systems engineering handbooks developed by NASA, DOD, Boeing, and so on.
Currently, there is also considerable discussion on the concept of system-of-systems—that is, systems that are of significant complexity and order that they require methodologies beyond the classic systems methodologies that are all basically derivatives of MIL-499B, a classic systems engineering military standard. The emphasis of this book, however, is not on the formal process of systems engineering eloquently described in the referenced books, but on the systems analysis component and the associated thought processes.
The design of this book is such that it can be used at different educational levels. Undergraduates, for example, focus on the basic problem-solving ideas, and the expected depth in their analyses and cases would be significantly less than expected from graduate students. How the book is used, that is, as a primary text or supplemental/complementary text, also depends on the student level. Experience at both levels has shown that experienced students (such as our Accelerated Master's Degrees students—working professionals in an executive degree format program) clearly understand (from their experiences) the issues addressed in the book and can relate the material directly to their work experiences, especially from what we call the systemic perspective; thus, for them the book is a required and a primary source. Undergraduates, typically without the benefit of significant work experience, see the value in a general problem-solving method that applies to many situations, with more focus on the systematic aspects of the material. For them, we use the book as supplemental.
Fundamentally, we see two worlds typical in systems engineering (both are necessary!):
By systemic, we mean affecting the entire system or holistic.1 By systematic, we mean a formal step-by-step process (in the most direct form, computer code is an example). This book makes a unique contribution by addressing the right-hand side, the systemic side. An analogy could be made to the left-brain (logical; often engineers) and right-brain (artistic) thinkers. The book focuses on problem definition, which is in our opinion a very difficult part of the systems process and an often neglected (or failed) part in practice (and books).
So, we have How to Do Systems Analysis: Primer and Casebook. This book is not intended to be an instructional guide to systems engineering (such as practiced in industry or government), but a book that engages one in beginning or enhancing their journey toward becoming a systems thinker—a requisite skill for systems engineers and all problem solvers. Trends come and go, but quality Systems Analysis thinking abides. Throughout the book are pointers and references to excellent books and articles that provide detailed techniques, research, and think pieces on the disparate aspects of systems analysis. We have deliberately left much of Jack Gibson's original material alone. We feel strongly that there is considerable wisdom in these words and that this wisdom is timeless. Unfortunately, systems thinking and good systems engineering remain elusive, as evidenced by the fairly recent (Summer 2006) experiences with the Big Dig in Boston and the current U.S. healthcare system debates. Many of Jack's examples and experiences, some dating back to the 1950s, add considerable insight to the realm of systems thinking. We have used draft parts of this book in graduate and undergraduate courses that introduced systems engineering concepts since the early 1990s; then the first book of this nature was based largely on Jack Gibson's contribution, How to Do Systems Analysis, published in 2007. The material uniformly received excellent reviews from students for its unique perspective on problem-solving in all types of domains. It is particularly relevant for students with some professional experience who appreciate its practical and accessible concepts.
How would we read this book? Top-down of course. One might start with reading in Part One, beginning by reading Chapter 6 completely, followed by Chapter 1, then reading the first several pages of Chapters 2–5, using the cases in Part Two to reinforce and practice the concepts presented in Part One. For undergraduate students, Chapters 2–4 form the core concepts of a general systems analysis methodology. Chapter 6 is, in effect, an executive summary of systems analysis and can basically stand on its own.
We encourage you to engage in and enjoy the material.
WILLIAM T. SCHERERWILLIAM F. GIBSONMICHAEL C. SMITHCharlottesville, VirginiaJanuary 2016
Note
1.
A wide-reaching term designating views in which the individual elements of a system are determined by their relations to all other elements of that system. Being highly relational, holistic theories do not see the sum of the parts as adding up to the whole. In addition to the individual parts of a system, there are “emergent,” or “arising,” properties that add to or transform the individual parts. As such, holistic theories claim that no element of a system can exist apart from the system in which it is a part. Holistic theories can be found in philosophical, religious, social, or scientific doctrines. (
Source
: Public Broadcasting Systems.)
Acknowledgments
Many people have contributed to this book, but first and foremost is John “Jack” Egan Gibson, one of the most intelligent and insightful people I have met and a true systems thinker and cofounder of the modern systems approach. I've had the pleasure of working for 30 years in the premier systems engineering department in the world, a department cofounded by Jack and Andrew P. Sage. During those years, I've had the pleasure of working with giants in the field, including Gibson, Sage, Aleco Christakis, John Warfield, and Wil Thissen. I'd especially like to acknowledge my two mentors, Chip White and Doug White, for their wisdom and friendship.
I'd like to thank my coauthors, Will Gibson and Mike Smith, two outstanding colleagues and true disciples of the systems approach. Finally and most importantly, I'd like to acknowledge the considerable support and love from my wife, Amy, and my trio of daughters, Kendall, Merritt, and Linden, the lights of my life.
W.T.S.
This book is the culmination of the work of many individuals. The primary is John Egan Gibson. Over the years, I pleasantly continue to be surprised by the comments I receive from his students, colleagues, clients, and friends. His seminal ideas and insights continue to provide the framework by which individuals and groups analyze problems. And, I continually see the practical application of these ideas in the nonacademic environment. Many of Jack's former graduate students and faculty members provided valuable comments and perspectives on this work.
Additionally, over many years working on the predecessor text and this one, I have enjoyed collaborating with Bill Scherer; we continually chide each other about how Jack's systems approach continues to prevail. And, an additional evangelist of this discipline is Mike Smith, from whom I continue to learn. Over the many years, I could not have completed this work without the help of two very important people. This book would not have been in your hands without the love, tolerance, and support of my wife, Hilary, and our son, Ted.
W.F.G.
“Systems thinking” is something that is observed, learned, and earned over the course of many years, through academic preparation, professional practice, and life experiences. As I look back over the past 30+ years of learning and practice, I see the thumbprints of many individuals – colleagues, clients, students, friends, and family – whose influence and encouragement gave me insights into “How to do systems analysis.” I am grateful to my coauthors, Bill Scherer and Will Gibson, who invited me to participate and have embraced my contributions as helpful in advancing systems thinking among young minds and older practitioners. I am also grateful for the experiences afforded to me throughout my professional career by clients who trusted my colleagues and me to provide thoughtful analysis based largely on the principles presented in this book. And, of course, my greatest appreciation goes to my family, especially my wife, Amanda, whose steadfast love and support exceeds what I deserve or ever expected; and our four children, Martha, Laura, David, and Elizabeth, whose ideas and perspectives always challenge me to think more systemically and recognize the importance of approaching problems with humility and grace.
M.C.S.
About the Companion Website
This book is accompanied by a companion website:
www.wiley.com/go/Gibson/HowtoDoSystemsAnalysis
The Student's website includes:
Excel data sets associated with specific cases
Other materials may be added to this website that complement the materials in the textbook and enhance the learning experience.
Part IPrimer
Chapter 1Introduction
sys·tem (sĭs′ təm) n.
A group of interacting, interrelated, or interdependent elements forming a complex whole.
A functionally related group of elements, especially:
The human body regarded as a functional physiological unit.
An organism as a whole, especially with regard to its vital processes or functions.
A group of physiologically or anatomically complementary organs or parts:
the nervous system; the skeletal system
.
A group of interacting mechanical or electrical components.
A network of structures and channels, as for communication, travel, or distribution.
A network of related computer software, hardware, and data transmission devices.
An organized set of interrelated ideas or principles.
A social, economic, or political organizational form.
A naturally occurring group of objects or phenomena: the solar system.
A set of objects or phenomena grouped together for classification or analysis.
A condition of harmonious, orderly interaction.
An organized and coordinated method; a procedure.
The prevailing social order; the establishment. Used with:
You can't beat the system
.
[Late Latin systēma, systēmat-, from Greek sustēma, from sunistanai, to combine: sun-, syn- + histanai, set up, establish.]
Source: Answers.com: American Heritage
In the systems approach, concentration is on the analysis and design of the whole, as distinct from…the components or parts…The systems approach relates the technology to the need, the social to the technological aspects; it starts by insisting on a clear understanding of exactly what the problem is and the goal that should dominate the solution and lead to the criteria for evaluating alternative avenues…The systems approach is the application of logic and common sense on a sophisticated technological basis…It provides for simulation and modeling so as to make possible predicting the performance before the entire system is brought into being. And it makes feasible the selection of the best approach from the many alternatives.
(Ramo, 1969, pp. 11–12)
1.1 What is a System?
A system is a set of elements so interconnected as to aid in driving toward a defined goal. There are three operative parts to this short definition. First is the existence of a set of elements—that is, a group of objects with some characteristics in common. All the passengers who have flown in a Boeing 787 or all the books written on systems engineering form a set, but mere membership in a definable set is not sufficient to form a system according to our definition. Second, the objects must be interconnected or influence one another. The members of a football team then would qualify as a system because each individual's performance influences the other members. See Ackoff (1971) for an interesting taxonomy of systems concepts (also see Whitehead et al., 2014).
Finally, the interconnected elements must have been formed to achieve some defined goal or objective. A random collection of people or things, even if they are in close proximity and thus influence each other in some sense, would not for this reason form a meaningful system. A football team meets this third condition of purposefulness, because it seeks a common goal. While these three components of our working definition fit within American Heritage's definitions, we should note that we are restricting our attention to “goal-directed” or purposeful systems, and thus our use of the term is narrower than a layman's intuition might indicate.1
It must be possible to estimate how well a system is doing in its drive toward the goal, or how closely one design option or another approaches the ideal—that is, more or less closely achieves the goal. We call this measure of progress or achievement the Index of Performance(IP) (alternatively, Measures of Effectiveness[MOE], Performance Measures[PM], etc.). Proper choice of an Index of Performance is crucial in successful system design. A measurable and meaningful measure of performance is simple enough in concept, although one sometimes has difficulty in conveying its importance to a client. It is typically complex and challenging in practice, however, to establish an index that is both measurable and meaningful. The temptation is to count what can be counted if what really matters seems indefinable. Much justifiable criticism has been directed at system analysts in this regard (Hoos, 1972; Syme et al., 2011). The Index of Performance concept is discussed in detail in Section 2.3.
Our definition of a system permits components, or the entire system in fact, to be of living form. The complexity of biological systems and social systems is such that complete mathematical descriptions are difficult, or impossible, with our present state of knowledge. We must content ourselves in such a situation with statistical or qualitative descriptions of the influence of elements one on another, rather than complete analytic and explicit functional relationships. This presents obvious objective obstacles, as well as more subtle subjective difficulties. It requires maturity by the system team members to work across disciplinary boundaries toward a common goal when their disciplinary methodologies are different not only in detail but in kind.
From these efforts at definition, we are forced to conclude that the words “system,” “subsystem,” and “parameter” do not have an objective meaning, independent of context. The electric utility of a region, for example, could be a system, or a subsystem, or could establish the value of a parameter depending on the observer's point of view of the situation. An engineer for the Detroit Edison Company (DTE Energy) could think of his electric utility as a system. Yet, he would readily admit that it is a subsystem in the Michigan Electric Coordinated System (MECS), which in turn is connected to the power pool covering the northeastern portion of the United States and eastern Canada. On the other hand, the city planner can ignore the system aspect of Detroit Edison and think of it merely supplying energy at a certain dollar cost. This is so if it is reasonable for him to assume that electricity can be provided in any reasonable amount to any point within the region. In this sense, the cost of electricity is a regional parameter. The massive Northeast U.S. power failure in 2003, along with the resulting repercussions directly affecting over 50 million people, clearly illustrates the regional nature of these systems.
That the function of an object and its relationship to neighboring objects depends on the observer's viewpoint must not be considered unusual. Koestler, for example, argues persuasively that this is true for all organisms as well as social organizations. For these units, which we have called “systems,” he coins the term “holon.”
But “wholes” and “parts” in this absolute sense just do not exist anywhere, either in the domain of living organisms or of social organizations. What we find are intermediate structures or a series of levels in an ascending order of complexity: sub-wholes which display, according to the way you look at them, some of the characteristics commonly attributed to wholes and some of the characteristics commonly attributed to parts.…The members of a hierarchy, like the Roman god Janus, all have two faces looking in opposite directions: the face turned toward the subordinate levels is that of a self-contained whole; the face turned upward toward the apex, that of a dependent part. One is the face of the master, the other the face of the servant. This “Janus effect” is a fundamental characteristic of sub-wholes in all types of hierarchies.
(Koestler, 1971)
This issue is further confused by the recent extensive use of the term “system-of-systems” or SoS, which refers to systems whose level of complexity creates emergent behavior and where the level of decision making and stakeholder values becomes difficult to determine.
Some uses of the term SoS apply to extremely complicated systems with many independently functioning but highly integrated subsystems such as might be found in a modern commercial or military aircraft or in an advanced manufacturing system with all of its associated logistics. While the system is, indeed, complicated and much care must be taken to understand, model, design, optimize, and test all of the many interfaces and scenarios under which the system must perform, the system is still very much the product of careful design around well thought-out functional requirements and operational objectives.
Other uses of the term SoS apply to systems that exhibit great complexity in which the emergent interactions and outcomes are difficult to model or anticipate and may not reflect any particular design intent, for better or worse. In this case, use of the word “system” may be applied without ever acknowledging or agreeing on the major objectives of the “system”—as in health care system, education system, economic system, and environmental system—and the best we can do is attempt to describe and understand the emergent behavior, regardless of whether or not we can influence or control the outcome.
The more formal use of SoS has been led by the U.S. Department of Defense and associated organizations (see Nielsen (2015), for an overview of SoS). Whether such SoS requires different methodologies is up for debate; however, the discussion has been evolving for over 60 years, with efforts in the 1980s and earlier on “meta-systems” methodology and S2 (e.g., Sage (1981), Eisner et al. (1991), Jackson and Keys (1984)).
1.2 Terminology Confusion
Because one is often introduced to system analysis in a specific context, it may be confusing subsequently to find the method used in an entirely different context. Engineering students, for example, may follow a “systems” curriculum that specializes in automatic control, communications theory, computer science, information retrieval, and so on, and which entirely excludes general system planning and policy-oriented questions (Brown and Scherer, 2000; Pyster et al., 2012). Students of management may think of fiscal control or ERP (Enterprise Resource Planning) “systems” when they use the phrase “system analysis.” We have sewage systems, social systems, and fantasy football team selection systems. Perhaps Koestler was wise to avoid the word “system” entirely, but then again, he only renamed the problem. Here is an example of a dual use of the word “system” that resulted in initial confusion by members of a government advisory panel.
A panel of engineers was requested by the federal government to establish the future research and development needs in the field of high-speed ground transportation (HSGT) (U.S. Department of Commerce, 1967; Herbert, 1968). The panel originally conceived the study in the categories shown in Figure 1.1. It soon became apparent, however, to the “system” subpanel that a number of the tasks, which they had been asked to consider, fell into the category we will call “general system planning.” Such items as subsystem interaction, reliability, and system management are included in this category. Yet what about communications and control, the question of a single, overall centralized control computer system versus many individual machines, or the reporting of the position and velocity of individual vehicles? Just as surely, these are more specific “systems.” Thus, the final report of the HSGT panel was organized as shown in Figure 1.2. This is a more functional arrangement, and it helped the panel to produce a less confusing and thus more useful report.
Figure 1.1 The original HSGT study concept. The Department of Commerce wished to assemble a study team to establish the concept of high-speed ground transportation (HSGT) on a conceptually correct basis. Originally, it felt that the study should have the five units shown above. However, when the team of experts assembled, they discovered that there existed considerable confusion as to the meaning of the “systems and communications” unit.
Figure 1.2 The final HSGT report formulation. Here we see the general systems aspect of the problem broken out and placed in the overall coordinating position. Now the term “communication and control system” is less ambiguous.
Thus far we have discussed the difference between the general or “comprehensive” system viewpoint we take in this text, i.e., the specific problem at issue, plus all of the interactions and impacts of the specific issue with its setting, including policy issues and a more localized, exclusively technological “control system” point of view. There are at least three additional semantic difficulties to be discussed.
In the early twenty-first century, as the U.S. populace was tiring of the prolonged war in Iraq and Afghanistan, the military sought an option that would allow it to capitalize on its technological superiority and reduce its reliance on soldiers in harm's way (and concomitant casualty rates). There was an insatiable demand to meet insurgencies in locales such as Syria, Libya, and Somalia, in addition to Iraq, Afghanistan, and Yemen. To meet this demand, unmanned drones seemed to be a cost-effective option.
So, for more than 10 years, to varying levels of success, pilots flew their television monitors, rather than strapping into their F-16s; Maverick and Ice Man were still graduating from Top Gun in Miramar only to sit at a Game Boy™ machine and shoot images on a screen.
However, as always, the Law of Unintended Consequences reared its ugly head—in 2015, as demand increased for drone operations in Yemen and Syria, the daily mission rates dropped from 65 to 60, as an increasing number of the 1,200 fighter pilots in the Air Force were completing their tours of duty and opting not to re-enlist.
The reason for this dilemma faced by the military was that pilots were facing new types of stresses—rather than flying from aircraft carriers in the Gulf Sea or from airbases in Bahrain, they were flying Reaper and Predator drones via satellite links in the United States. The perceived benefit was that the pilots were living safely, away from SAMs (surface to air missiles). However, while they were with their families, the constant shift back and forth between war and family activities created, in effect, a feeling of perpetual deployment.
Col. James Cluff, the commander of the Air Force's 432nd Wing, stated, “Having our folks make that mental shift every day, driving into the gate and thinking, ‘All right, I've got my war face on, and I'm going to the fight,’ and then driving out of the gate and stopping at Walmart [sic] to pick up a carton of milk or going to the soccer game on the way home—and the fact that you can't talk about most of what you do at home—all those stressors together are what is putting pressure on the family, putting pressure on the airman.”2
The Government Accountability Office (GAO) conducted a study and released its findings in April 2014.3 It found that while high-performing organizations, such as the Air Force, manage human capital to identify and target the optimum number of individuals to fill its drone group personnel needs, it fails to account for all tasks these units complete. Air Force officials stated that, as a result, the crew ratio for drone efforts was too low, but the Air Force did not update it. It recognized that low crew ratios diminished combat capability and cause flight safety to suffer, that high work demands on drone pilots limited the time they have available for training and development, and it negatively affected their work–life balance, but the Air Force failed to utilize direct feedback from drone pilots to develop its approach to managing challenges related to recruiting, retention, training, and development of drone pilots.
The failure of the Air Force to examine and implement this issue from a holistic systems approach meant that, while it might have some short-term successes, it would ultimately have a failed initiative on its hands because it failed to analyze the challenge faced by pilots to balance their war-fighting roles with their personal lives. It needed to change its methods and metrics rapidly, applying an approach like the one we describe in this text.
Later in the chapter, we indicate that operations research (OR) may be considered an immediate precursor of systems analysis (SA). Thus, one may fairly inquire as to exactly the difference between the two. In Section 1.10, we will see that B. L. R. Smith (RAND, 1966) argues that when RAND added an explicit policy component to OR studies, a new synthesis was achieved. Thus for us, system analysis equals an analytic OR study, plus a policy analysis.
Symbolically, then, Smith might say
In other words, in modern usage, SA is a more general design philosophy than is OR, and it exhibits marks that are readily observable to an outside inquirer. See Section 1.3 for further discussion on this matter.
Finally, one may ask if SA differs from “system design” and/or “systems engineering.” In a precise technical sense, “analysis” is defined as taking apart into constituent elements, while “design” generally means “synthesis” or combining elements into a functional new whole. Unfortunately for all of us interested in precise terminology, the common use of “system analysis” in the literature almost always includes not merely an “analytic” phase, but also the development or recommendations for the solution or amelioration of the problem at hand—that is, “design” or synthesis. Following this usage, we include in the term “SA” that wider sense of synthesis.
What of the term “systems engineering?” In the older and narrower usage, “engineering” includes analysis and synthesis, but it is restricted to the design and operation of physical devices, that is, hardware design. However, in the broader and more modern sense, systems engineering (SE) includes all of the matters we include within the term systems analysis. Systems engineering, in fact, has its roots in classical control theory where the “system” was described in terms of an initial system state, controls (e.g., designed to achieve the “desired” state of the system), transfer functions (that modeled the conversion from the initial state into the desired state), exogenous factors (that influenced the transfer function's performance), a new system state, and feedback to the control function. All of this is characterized by latency, accuracy, response, and other measures of system performance. This approach to analyzing physical systems has expanded to large dynamic systems where the “stocks and flows” (see Senge (2006) or Meadows and Wright (2008)) include social systems, environmental systems, economic systems, and other large-scale complex systems involving technology, policy, legal and regulatory issues, and social and cultural considerations. This concept of systems engineering is broader than a view based primarily on the life cycle of physical systems and focuses extensively on the analysis that leads to effective design of systems. Thus for us in this text:
Numerous books describe the process of systems engineering,4 including systems engineering handbooks developed by NASA, DOD, Boeing, and so on. Currently, there is also considerable discussion on the concept of SoS—that is, systems that are of significant complexity and order that they require methodologies beyond the classic systems methodologies that are all basically derivatives of MIL-499B.5 The emphasis of this book, however, is not on the formal process of systems engineering eloquently described in the footnoted books (and the synonym of the word system: “Method”), but on the systems analysis component as described above and the associated thought processes.
1.3 Systems Analysis Equals Operations Research Plus Policy Analysis
We will see in a later section of this chapter (see Section 1.10) that the RAND approach to systems analysis began with operations research and added a policy analysis component. We subscribe to that approach in this text. Of course, defining a term using two other ill-defined terms doesn't help very much. So we should feel obliged to define OR and PA. Fortunately a number of students of the field have defined OR and Table 1.1 gives a collection of these definitions.
Table 1.1 Some typical definitions of operations research
“OR is simply the application of scientific method (
i.e.
, quantitative, analytic thinking with empiric checking) to the problems of an executive authority.”—Waddington 1973
“OR is the application of scientific ideas and methods to improve the efficiency of an industrial process, an organization or, in the most general of senses, the working of any part of society.”—Friend
et al
., 1988
“Operations Research (O.R.), or operational research in the U.K, is a discipline that deals with the application of advanced analytical methods to help make better decisions.”— INFORMS, 2015
“Though there is no ‘official definition’ of Operational Research (‘Operations Research’ in the US), it can be described as a scientific approach to the solution of problems in the management of complex systems.”— EURO: The Association of European Operational Research Societies 2015
“Operations Research is the quantitative study of the operations of a complex organisation and the prediction of the effects of changes in conditions for the guidance of executives in obtaining the maximum effectiveness from available resources.”—Brown and Easterfield 1951
“Operations research (operational research in Britain) as understood today is essentially identical to systems analysis.”— Principia Cybernetica Web 2015
“Operations research is a vast branch of mathematics which encompasses many diverse areas of minimization and optimization.”—
Wolfram MathWorld
, 2015
“OR, let us say, is the securing of improvement in social systems by means of scientific method.”—Churchman, 1970
“Operations research analysts use advanced mathematical and analytical methods to help organizations investigate complex issues, identify and solve problems, and make better decisions.”—U.S. Bureau of Labor Statistics, 2015
We notice the frequent occurrence of terms such as “scientific” and “mathematical” in these definitions; also there is the use of “optimization” and the emphasis on the concept of a “client.” The term “client” itself does not appear, but synonyms such as “executive authority,” “organization,” “society,” and so on, do. Thus, while the details differ among these definitions, a common basis emerges. We could go on with this definitional exercise to discover the typical analytic techniques of OR, such as linear programming, queuing theory, optimization techniques, simulation methods, and so on.
“Policy analysis” is a little more difficult to limit. But, if we note how RAND came to include the policy analysis aspect, matters become clearer. RAND knew from working with the military mind that it is hierarchal, a primary attribute of a Tayloristic value set. Taylorism, as we shall see, includes a rigid separation of “thinking” by managers from “doing” by workers. Thus, the U.S. Air Force, RAND's original sole sponsor, tended to come to it with orders to do a certain analysis. When RAND analysts asked “why,” they were rebuffed. But as we will see, the Tayloristic mind-set is not suitable for creative analysis of new issues. The system analyst must know the goals of the issue and the underlying values from which the goals are formed to conduct an analysis properly. In the Air Force's view, this took RAND out of the realm of OR into management's territory, Policy Analysis. So RAND simply included policy analysis in its definition of what it did and that helped matters somewhat.
1.4 Attributes of Large-Scale Systems
In this text we will concentrate on a particular aspect of the field called large-scale systems. How does a large-scale system differ from a non-large-scale system? Almost certainly there is a policy component to the issue under consideration. Generally, a large-scale problem is not merely one containing many components, although that can occur. The usage has become common to differentiate between (a) the low-order, well-defined physical system to which almost all of the mathematical theory of operations research is directed and (b) larger, more complex issues with a policy component. By “policy component,” we generally mean that the goals of the system and the index of performance are subject to the personal standards and judgment of the client. The typical large-scale system will have many of the following attributes:
Policy Component.
In addition to the physical infrastructure, or the so-called engineering component, a large-scale system often contains a social or “policy” component whose effectiveness must be evaluated by its accord with general social, governmental, or other high-order judgments, rather than by simple economic efficiency.
High Order.
A large-scale system (LSS), or “General System,” will usually have a large number of discernible subsystems or parts. These parts can be quite different from one another and may be interconnected in complex ways. Some of the elements of the large-scale system may include living elements as linkages. In addition, social, economic, political, environmental, and technological considerations will often be involved.
Complex to Describe.
Because of the large number and variety of its elements, the LSS is often difficult to describe analytically or to model precisely via dynamic computer simulation.
Lengthy Installation.
Because of the cost and effort needed for its installation, the LSS may take a number of years to construct and install. Thus special care is needed with respect to graceful phasing-in of the new system and phasing-out of the old system that it replaces.
Unique.
Often the LSS will be unique in its overall concept. Thus special care must be given to careful preliminary design and complete analysis. The designer will not be able to correct design errors in early models later in the production run, if only one is to be built.
Prior Complete Testing Impractical.
Because of the size and cost of the LSS, it may be impractical to construct a test prototype prior to installation of the operating system, or even to assemble the complete system off-site for preliminary testing. We are thinking here of complete subway systems, and so on.
One could cite an almost endless list of LSS, of which the following are a few examples:
The “Big Dig” transportation project in Boston (1982–2002)
The information technology infrastructure for the Department of Homeland Security
President Reagan's “Star Wars” initiative in the 1980s
A Manned Mars Mission (considered in
Chapter 2
)
The complete water supply for a large system (or any infrastructure component)—think of Flint, Michigan, in 2015–2016 (and beyond)
The integrated Highway/Rail/Air/River transportation system for a developing nation such as Colombia, funded by the World Bank in the 1960s
The long-range business plan for a complex international corporation such as Royal Dutch Shell in the months before the 1970s OPEC oil crisis
The New Orleans flood containment system (levees, pumps, drainage, staff, policies, and so on, or the flood evacuation process)
The U.S. Social Security System
The World Wide Web (The Web)
The Mexico–United States border
The Health Insurance component of the Affordable Care Act
1.5 Transportation Systems: An Example of a Large-Scale System
Intelligent transportation systems (ITS) involve the use of disparate technologies to improve, typically without capacity increases, the performance of a transportation system. The preliminary analysis, design, and installation of an ITS is complex and lengthy. The system is of high order. It may involve numerous subsystems, from transit rail to freeways to arterial signal systems. Some of the elements may be analyzed in exact details—for example, individual intersection signals and the associated control computers. Other elements may submit to statistical analysis; passenger origin/demand studies are an example. Design data are typically necessary from disparate sources, such as the U.S. Census origin/destination data and local traffic management centers. Financial estimates of system operation will be less precise, but still well within the bounds of approximate analysis. Connected vehicles and high-speed automated platoons of vehicles will introduce new dimensions of risks and radically change our vision of the interstate highway system, and such systems are being tested throughout the world. But other elements upon which the success of the system rests seem to be beyond analytic description.
For example, the demographics of the urban region may change dramatically in 30 years. A 2011 study shows that, within a period of 5 years, one-half of the families in a typical American community have changed their place of residence (He and Schachter, 2003; for details see Molloy et al. (2011)). Housing prices, which dramatically affect traffic congestion and have major ITS implications, soared in the 2000s and also doubling in a 5-year time frame; however, the bubble burst in 2008–2009 as a result of the financial and economic downturn (Anonymous, 2005a). Thus, if the return on investment of several ITS technologies is calculated on the basis of a 30-year operating life, one must extrapolate over six half-lives of the demographic base that the system is designed to serve—a rather risky process. Another example involves the driving habits of new generations, such as the “millennials,” who are exhibiting different driving behaviors (fewer getting driver licenses, more Über, etc.) (Dutzik et al., 2014).
Political questions are even more difficult with which to grapple than are demographic ones. For example, the so-called “U.S. Highway Trust Fund” is a special-purpose federal gasoline tax with a limited set of permissible uses that Congress reauthorizes every 5 years. In general, funds are returned to the states to reimburse approved state highway construction and reconstruction and other transportation infrastructure investments based on a complicated allocation formula. The highway trust fund eligibility criteria have been expanded to include investments in ITS as well as transit, bicycle, and pedestrian improvements. The larger issue is that, as we drive fewer miles in more efficient (or electric) vehicles, the gasoline tax has become a less reliable source of funding for highways and other transportation investments. At present, we anticipate the highway trust fund becoming exhausted because we refuse to raise the federal gas tax (last raised in 1992), which is linked to “gallons” rather than “vehicle miles driven” or the wholesale price of gasoline.6 This is a political question that will have a greater impact on the benefit–cost studies for deploying ITS than almost any technological factor.
Another example is photo-red systems, where camera systems can be installed to detect and issue tickets to vehicles that run red lights (Anonymous, 2005b). Systems can be operated by local or state governments, or they can be operated by for-profit companies via a profit-sharing formula with localities. Evaluation of such systems has proved their capability in terms of technology, accident reductions, and economic viability; however, considerable political opposition has limited their deployment in the United States, where the opposition is based on claims of invasion of privacy or claims of increasing accident rates. Some regions have turned off effective and proven photo-red cameras, against the wishes of police agencies, for political reasons (Stockwell, 2005). As a result, since their initial deployment in the United States in the late 1960s, red-light cameras remain an enigma due to conflicting goals and values, misinformation, and plain politics. However, in other parts of the world, such as The Netherlands, such technologies are widely used and accepted, not only for red lights, but also for excessive speed.
Sociological factors are most difficult of all to predict. What will be an acceptable level of urban pollution produced by a transportation system? What is an acceptable level of delay on the highways? What will be the performance requirements placed by federal diktat on the next generation of individual vehicles and transit vehicles? What safety needs, real and perceived, must be met by ITS technology in the future? What will be the timing and level of acceptance of “driverless vehicles?” What about questions of “ambience” and “user-friendliness?”
