What is “engineering systems thinking”?

The Authors

Moti Frank, Technion – Israel Institute of Technology, Haifa, Israel

Abstract

As technological systems grow larger, more complex, and interdisciplinary, electronics and hi-tech industries face a growing demand for engineers with a capacity for “engineering systems thinking”. This paper presents a multifunctional definition and 30 laws of “engineering systems thinking”. The definition and the laws are based on a study that its purpose was to identify the characteristics of engineers who are able to think in the manner called “engineering systems thinking”. A thorough understanding of “engineering systems thinking” on both the theoretical and operational levels will prove useful in the design of curricula to improve and develop thinking of this sort.

Article Type:

Conceptual Paper

Keyword(s):

Cybernetics; Systems design.

Journal:

Kybernetes

Volume:

Number:

9/10

Year:

2002

pp:

1350-1360

Copyright ©

MCB UP Ltd

ISSN:

0368-492X

Introduction

But, what is engineering systems thinking? Acknowledging the widespread use of the term “engineering systems thinking” in the engineering community, it was decided to examine the subject in the context of a study (Frank, 1999). Based on this study, a multifunctional definition (Frank and Waks, 2001) and 30 laws (Frank, 2000) of “engineering systems thinking” were extracted.

“Systems thinking”, according to Senge (1990), “is a discipline for seeing wholes”. It is a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static “snapshots”. Systems thinking offers us a flexible language that might expand, change, and shape our ordinary way of thinking in regard to complex issues.

The systems thinking literature deals mainly with living, economic, management and social systems, as well as with the analysis of complex organizations (Ackoff, 1981; Bertalanffy, 1968; Checkland, 1981, 1989; Chen and Stroup, 1993; Cleland and King, 1972; Hoefler and Mar, 1992; Graczyk, 1993; Katz and Kahn, 1978; Kim, 1995; Klir, 1985; O'Connor and McDermont, 1997; Richmond, 2000; Senge, 1990; Senge et al., 1994 and Waring, 1996). This paper, however, deals with something slightly different – “engineering systems thinking”. A thorough understanding of engineering systems thinking on both the theoretical and operational levels will prove useful in the design of curricula intended to improve and develop thinking of this sort.

The main purpose of the study (Frank, 1999) was to identify the characteristics of engineers with a capacity for engineering systems thinking. The research was carried out in three stages. The qualitative-naturalistic inquiry paradigm, in which data collection is principally based on interviews and observations, was found to be suitable for the first and second stages (Guba and Lincoln, 1985). The third stage of the research consisted of a survey based on a pilot questionnaire (N=31) and a final questionnaire (N=276).

The great amount of “raw data” collected in the study have been sorted to 83 categories: ten categories referred to the definition of engineering systems thinking; four categories dealt with various types of systems thinking; 15 categories related to the knowledge demanded of system engineers; 31 categories referred to the skills demanded of system engineers; 15 categories dealt with the behavioral competencies demanded of system engineers; eight categories referred to the processes by which systems thinking capability is acquired.

Based on the research findings and a literature review, a multifunctional definition (Frank and Waks, 2001) and 30 laws (Frank, 2000) of “engineering systems thinking” were proposed. First, I will present the definition of “engineering systems thinking” based on the first ten categories.

A multifunctional definition of engineering systems thinking

A multifunctional definition is a collection of facets combined through informal connectives. It is a framework that is constructed from detailed sub-definitions, each specifying uniquely the entity under consideration in a certain set of relevant aspects (Waks, 1995). Each aspect is represented by a facet, which in turn involves the labeling of conceptual categories that define the relevant universe of contents. Figure 1 shows the proposal for the multifunctional definition of engineering systems thinking (Frank and Waks, 2001). In this case we have seven facets A-G, each of which has its own labeling unique elements. Let me now discuss the main categories of the multifunctional definition (Figure 1):

Understanding the whole system

Most of the subjects defined engineering systems thinking as the ability to understand the whole system or the ability to perceive how the component or the card functions as part of a system.

According to Kim (1995), Senge (1994) and Waring (1996), a problem may not be solved by breaking it down into elements and finding a separate solution for each of those elements. One must be able to see the whole picture. Some problems stem from the structure of the system itself. All system components (persons, parts) share responsibility for system problems.

Thus, an engineer with a capacity for systems thinking understands how sub-systems integrate into a whole single system and understands the whole – the entire system and the whole picture beyond its single components.

Understanding the synergy of the system

Many subjects were of the opinion that the systems engineer required to understand the synergy of a given system. According to many authors (Graczyk, 1993; Kahn and Katz, 1966; Waring, 1996), a system is more than just a collection of parts. “The whole is more than the sum of its parts”. This synergistic effect is one of the central and most important attributes of a system, but it is, at times, hard to identify.

The general systems theory holds that all systems are similar in certain ways. According to this view, if the synergy attribute exists in all systems, then it certainly exists in man-made technological systems. The systems engineer must, therefore, be capable of deriving the synergy of a system from the very integration of the sub-systems under his responsibility.

Understanding the system from multiple perspectives

In the opinion of many interviewees, an engineer with engineering systems thinking capability must understand and be able to describe a system from all relevant perspectives beyond the level of engineering (i.e. technological, economical, managerial, social, electrical, mechanical, and operational perspectives).

A successful systems engineer would avoid adopting a one-dimensional view and would examine a specific subject or problem from different angles and points of view.

Understanding the implications of modification to the system

It turns out that modifications are central to the work of the systems engineer. The systems engineer must understand the system as a whole and be capable of anticipating and detailing all implications (including side effects) of changes in the system – engineering and non-engineering alike – both those initiated by the contractor and those required by the end user after freezing the design. In many cases, the systems engineer must be able to take care of every stage of the change starting from the conception of the idea and proceeding through the paper work (forms and approvals) and on to the execution and documentation of the introduced modification.

Understanding a new system immediately upon presentation

An engineer with a good grasp of the system understands and is able to describe the operation, purposes, applications, advantages, and limitations of an unknown system immediately after receiving an initial explanation.

System complexity level

According to O'Connor and McDermott (1997) and Senge (1990) systems showing complexity of detail may be treated by categorization, classification, ordering, and a systemic-algorithmic approach. A system has dynamic complexity, however, when its parts have multiple modes of operation and each part may be connected, according to need, to a different part. Dynamic complexity exists when a certain operation results in a certain series of consequences in one part of the system and a totally different series of consequences in other parts of the system. Dynamic complexity also exists when regular intervention produces results that are irregular. Regular methods of design and analysis are not structured to cope with dynamic complexity. In real life, most situations deal with dynamic complexity and not complexity of detail. Simulations with thousands of variables and complex alignments of components are likely to divert our attention from seeing the main patterns and interactions.

Thus, a system becomes more complex with the growing number of sub-systems within it, causing an increase in the number of interconnections between its components. A successful systems engineer will be better equipped to describe the functionality of complex systems.

Interconnections

The issue of interconnections between system parts is common to all definitions of the concept “system” (Cleland and King, 1972; Graczyk, 1993; O'Connor and McDermott, 1997; Whitner, 1985). In the opinion of many subjects, engineering systems thinking involves an understanding of the interconnections between system components. A successful systems engineer must understand and be able to describe the interconnections (even when some of them are hidden) and the mutual influences between sub-systems (and neighboring systems).

Remedies for failures and system problems

Systems engineers are sometimes required to remedy/solve/analyze system failures or system problems. Engineering systems thinking a priori could, perhaps, prevent the appearance of a system failure or a system problem. Therefore the treatment of system failures/problems is a significant component of engineering systems thinking.

Analysis and synthesis

System analysis is the disassembly of the system to its components with the purpose of analyzing its operation. Synthesis is the connection of components or sub-systems into a whole system.

An engineer with a capacity for engineering systems thinking must be able to move from the whole to its parts, and analyze the system by breaking it down to its components. He or she must be able to track signals from the input through every sub-system, and interface to the output. In addition to this, however, the systems engineer must be able to synthesize. He or she must be able to assemble or connect sub-systems into a complete system and provide end-to-end solutions.

Don't get stuck on details

There are engineers who have to thoroughly understand all the details involved in a given problem in order to be able to form a decision and come up with a solution. Engineers of this sort usually find it difficult to develop engineering systems thinking. A successful systems engineer must be able to see the whole picture and not get stuck on details. He or she should be able to act without understanding fully all of the system's details. Such engineers usually feel comfortable working in unclear conditions and in an uncertain environment.

Multidisciplinary and interdisciplinary knowledge

The single most prominent characteristic of an engineer with a capacity for engineering systems thinking is multidisciplinary knowledge, as well as interdisciplinary knowledge. Knowledge of this sort makes one comfortable with multi-tasking activities. By “multidisciplinary knowledge”, however, I do not mean that one knows “a little of everything”. The systems engineer must acquire specialization in at least one main area (an “anchor”); in addition, he or she must be knowledgeable in all other relevant areas.

The engineer's knowledge in those other areas need not be equal to that of a specialist. In the additional content areas, the systems engineer must possess general knowledge and understanding on the overall level. He or she must be familiar with the jargon of the other disciplines (relevant to his occupation and tasks), and be able to communicate with people from different areas. Wide knowledge is required for the systems engineer also in order to be able to understand and derive significance from the answers and reports of others, i.e. “specialists” from outside his own main area of expertise. Such wide knowledge may also enable the systems engineer to cope with new disciplines.

The 30 laws

Let me now present 30 engineering systems thinking laws (Frank, 2000), based on the research findings, a literature review and Senge's (1990) laws for systems thinking:

In all the project's phases/stages and along the system's life, the systems engineer has to take into account the customer organization vision, goals and tasks, the customer requirements and preferences, and the problems to be solved by the system and the customer needs.
The whole has to be seen as well as the interaction between the system's elements. For this purpose a circular thinking has to be developed, to replace the traditional linear thinking. A problem should not be solved by just dismantling it to parts but all its implications have to be taken into account. Each activity in a system's certain element affects the other elements and the whole.
Consider that every action could have implications also in another place or at another time.
One should always look for the synergy and the relative advantages stemming from the integration of sub-systems.
The solution is not always only engineering one. The systems engineer has also to take into account cost, re-use, organizational, managerial, and personal considerations.
The system's engineer should take as many different perspectives as possible, of every subject or problem, and other aspects have to be reviewed from all points of view.
Always take into account electrical considerations, mechanical considerations, environmental conditions constraints, quality assurance considerations, and benefit indices, such as reliability, availability, maintainability, testability and productibility.
In all development phases the future logistic requirements have to be taken into account (spare parts, maintenance infrastructures, support, service, maintenance levels, worksheets, technical documentation and various manuals).
When a need arises to carry out a modification in the system, take into account: the engineering and non-engineering implications in any place and at any time; the effects on the Form, Fit and Function; the delays and the time durations of the modification incorporation; the system's response time to the changes; the needs, difficulties and attitudes of those supposed live with the modification; that the change could bring short-term benefit but long-term damage.
Each problem may have more than one possible working solution. All possible alternatives should be examined and compared to each other by quantitative and qualitative measurements. The optimal alternative should be chosen.
Engineering design is not necessarily maximal. One should not always aspire to achieve maximum performances. At every stage engineering trade-offs and cost-effectiveness considerations should be considered. One could always improve more. One has to know when to “cut” and freeze a configuration for production. Excessive pressure in a certain point could cause a collapse at another point. Over stressing one part in the system could weaken another part and thus the entire system. Maximum performance design is expensive and not always results in maximizing entire system performance.
In case of system's malfunction, problem or failure, repeated structures and patterns should be looked for and analyzed, and lessons drawn accordingly (repeated failure is a failure that keeps returning, after the repairs, until the true malfunction is found and repaired. A repeated-non-verified failure is a failure that the user complained about, the technician inspected and could not verify and the failure reappeared again in the next operation).
Look always for the leverage point – changes that might introduce significant improvements by minimum effort.
Pay attention to and take into account slow or gradual processes.
Avoid adapting a known solution for the current problem – it might not be suitable.
Take into account development risks. In each project uncertainty prevails on the level of scheduling, cost, resources, scope, environmental conditions and technology. Therefore, the strategy of eliminating uncertainties has to be taken – e.g. experiments, tests, verifications, analyses, comparisons, simulations, awareness of possible risks, planning ways of retreat and risk deployment among the partners.
It is impossible to run a project without control, configuration management, milestones and management and scheduling methods. Possible bottlenecks and potential critical paths have to be examined constantly.
The operator/user person must be considered as major part of the system. Hence at each stage, the human element has to be considered. The engineering design should include MMI (Man-Machine-Interface) considerations.
The engineering design is a top-down design (excluding certain “open systems”, for which the bottom-up approach is preferable). The integration and tests are bottom-up.
At every stage, systemic design considerations should be used (such as decentralized or centralized design, minimum dependency between sub-systems, etc.). The systems engineer should be familiar with system malfunction analysis methods and tools.
Engineering systems thinking requires the use of simulations. The simulation limitations should be taken into account.
Engineering systems thinking requires the integration of expertise from different disciplines. As the systems become more complex and dynamic, one person, as competent as he may be, is inadequate to understand and see it all. Systems thinking, by its nature requires the examination of different perspectives, calling for teamwork to cover the various perspectives. When setting up the team proper representation has to be given to all the system's functions. Control and status discussions and meetings as well as “brain storming” may have to be more frequent.
Try to anticipate the future at every stage. Take into account anticipated technological developments, future market needs, difficulties, problems and expected changes in the project.
Selecting partners and sub-contractors could be critical. Before signing agreements refer to considerations such as the “engineering/economic history” of the potential partner, manpower (quality, stability, human capital) that he is capable of investing at the project's disposal, division of work and responsibility and proper arrangements for status meetings, integration tests and experiments of all kind.
When selecting the software language or software development tools and platforms, make sure that they are usable and supportable, or changeable, throughout the system's life.
When selecting components for production, take into account their shelf life. Select components whose supply is guaranteed throughout all the system's life. In case of likely obsolescence of component, make sure of having sufficient stock.
In order to win a tender, many companies reduce the development price in their offer, assuming that they will be compensated by the serial production and by the cost of modifications (if required). Therefore, in engineering systems thinking, it is recommended not to start development at all, if the serial production budgets are not guaranteed in advance.
Always examine the external threats against the system (for example, electro-magnetic-interference, environment conditions, etc.).
Engineering systems thinking resorts probability and statistical terms, both when defining the system specifications and when determining the project targets (costs, performance, time and scope).
In engineering systems thinking it is advisable to limit the responsibility assigned to an external factor (such as external counselor), since this increases the dependency on it.

Conclusion

In this paper, I presented a multifunctional definition and 30 laws of a concept I call “Engineering Systems Thinking”. The concept emerges from research that was carried out in the field. I claim that a successful systems engineer must possess a developed capacity for engineering systems thinking, a type of thinking that has many of the classic characteristics of systems thinking, but which also has unique characteristics that distinguish it from the term that is currently used in the field (systems thinking).

The proposed definition and laws are important on the theoretical and practical level alike. On the theoretical level they may contribute to the theoretical body of knowledge of the General Systems Theory. On the practical level the definition may constitute a basis for further research, to develop a curriculum for engineering systems thinking.

Figure 1A multifunctional d finition of engineering systems thinking (Frank and Waks, 2001)

References

Ackoff, R.L. (1981), Creating the Corporate Future, Wiley, New York, .