Much is made today of contemporary systems engineering, how it is a branch of engineering, and how it is supposed to 'operate.' It is highly educational to look back and see how things were done in the heyday of systems engineering in the UK, the 1960, 70s and 80s. Great emphasis was placed, for example, on exploration of the problem or situation, and on the environment in which the solution system would be required to operate. This exploratory phase included:
- problem scoping, particularly because experience showed that the customer frequently misunderstood the situation, and declared the wrong problem, or failed to get to the root of the problem
- conceiving potential solution options
- exploring the various Concepts of Operations (CONOPS) which each option might invoke, with associated threats and risks
- conceiving operational systems design, both functional and functional/physical, together with systems integration facilities
- designing the complete solution to the customer's (real) problem, including the operational solution, operator simulators and trainers, servicing and maintenance facilities, publications, etc., etc.
There was a quite different attitude to the customer, too. Perhaps because the systems engineering team really got to understand the problem, the situation and the risks involved, they tended to feel that they knew what the customer, and particularly the user, needed better than the customer and current operators did. (Contemporary operators were inhibited by knowing only their contemporary facilities and situations, and were often unable to imagine how they might use completely new facilities in operations.) And, while customers had to be served, it was the future users and operators who were the real customers… or, so we believed.
One last difference: this early phase, which might last two years or more for a complex problem, issue or situation was of uncertain duration and so was not conducted to a fixed price. Instead, it operated under "cost plus" contracting conditions, with the contractor encouraged to go into as much detail as necessary to ensure accurate specifications and robust implementation plans.
Managing Systems Creation is a prize winning paper from 1986 which shows the fundamentally different attitude to the undertaking of systems engineering activities that existed at the time — to such a degree that some readers might find it difficult to reconcile this former view of systems engineering with their own, contemporary views. How could they possibly be the same subject?
Systems Creativity is, as the title indicates as an essential element in design which can be taught and encouraged, however, and the paper presents creative design 'seeds' for decision-based systems, flow-line manufacture and maintenance processes and management information systems. Concept evolution techniques are presented as a structured decomposition methodology. The first example of creative design presented in the paper is of the design of a notional systems engineering company which is unusual to most readers in that it contains no manufacturing or production, and preconceived ideas of company organisation are likely, therefore, to be misleading. The application of state-variable analysis to the cash flow of a start-up defence company follows, and the application of systems dynamic to intercompany competition is presented. Creativity is not restricted to initial design; flow-line analysis using queuing theory for intensive flying of training aircraft is demonstrated as a means of resequencing activities to reduce mean throughput times. And finite state/transition analysis is used on the grand scale to examine the potential for European conflict. Finally, the author presents the principles of creativity and suggests that, far from being peculiar to engineering, one finds parallels in music, composition and the arts.