In order to provide a definition of the core phrase used throughout this submission - concurrent engineering, this section sets out to give an overview to the term and what its context is for the purposes of this submission. This definition is approached from two points - academic and industrial, which when combined provide a concept base upon which many of this submission's cases are reviewed.
"Concurrent: Running in the same direction as parallel lines; (meeting at, or tending towards the same point); existing or acting together or at the same time; agreeing."
"Engineering: (n) the application of scientific knowledge to the design, building and use of machines, roads bridges and or electrical equipment."
"Concurrent Engineering is a systematic approach to the integrated...design of products and their related processes, including manufacturing and support."
[Gillen & Fitz 2]
"Concurrent Engineering is a cross-functional inter-disciplinary activity that begins at the pre-natal stages of design and continues through production and product end of life."
It can be seen from these various definitions, whilst noting their very different origins, that there are a number of commonalities which are present in them all. Perhaps the most obvious and most general is that concurrent engineering is not a 'product', that is, it cannot be bought off-the-shelf. Nor is it a strict process, no defined steps, no IF THEN, ELSE type statements. Perhaps concurrent engineering is best described as a management philosophy - a way of thinking, a way of approaching a situation. This is however a very broad definition; what is required is a more focused assessment of what kind of mind-set concurrent engineering represents. The academic definitions treat the two parts of the title separately, in cold isolation, whereas the industrial definitions take the two words together as an entity. This is both useful and divisive. To make further use of these definitions, we must meld the two, to get a better definition of what concurrent engineering means. A hybrid definition then, could read thus:
"Aspects of scientific knowledge running and working in parallel lines towards a given point or goal."
Common threads with these definitions then are that events and activities will occur at the same time, that the concept of time is dynamic in that it passes, and that a concurrent engineering activity requires a goal. Graphically, this may be shown as in Fig. 3.1.
The nature of these three factors gives rise to a fourth and possibly most important factor - how they relate to one another. The activities themselves could be of many different types; a component design, a monitoring process, indeed virtually any activity which occurs through time. Perhaps the driver behind much of this though is the goal itself. The goal may be flexible, depending on the project being considered, or it could be static - such as a specific launch date; it could be a dynamic, moving goal, such as in a research and development environment. Communications are usually the strands which hold the whole system together and often are the hardest part to quantify and achieve. The factor of time is of course constant, but it is vital for a number of reasons to remember the three general phases of past, present and future, what's done is done (the history), what is happening (the event as now), what is to happen (planning, schedule and forecast).
As has been said, the applications of concurrent engineering are broad, but for a single project, the ramifications of its use go further than just the team employing it. An industrial parallel would be just a single company in the middle of a supply chain implementing a Just-In-Time system when those around them are using other order and delivery scheduling systems - the overall benefits aren't anywhere near the real potential of JIT because it cannot be practised fully, also, it may well create friction and negative results in the chain, and in the implementor. In a similar way, concurrent engineering may well be implemented singly by a department, but to incorporate it to at least a degree in the bigger picture such as the organisation as a whole will help reach greater benefits, and an organisation working together towards a common goal may be no bad thing. Concurrent engineering can also employ other techniques [F2000 1] to aid this implementation, such as Quality Function Deployment [QFD], Taguchi methods and designing for manufacturing and assembly, though much of these concepts are beyond the scope of this report.
Identifying on how many levels concurrent engineering [CE] concepts work is difficult to quantify, as each activity has a goal and a single activity may have many resources to make it up, therefore each activity in itself is a kind of 'mini' CE project, with its own goal. As Goldratt speculates [Goldratt 1] one of the key reasons why some organisations fail to realise their potential can be attributed to their lack of overview - not seeing the organisation and its goals as a whole, rather as isolated, independent entities of function, thus they can often not account for important trade-off such as those covered in Fig. 3.2.
In the research of this submission, it has been evident that a number of people and authors treat simultaneous and concurrent engineering as the same concept. However, for the purposes of this report, the author concurs with those who draw a definite distinction between the two on the grounds of concurrent engineering's requisite of direction and goal, as discussed earlier in this section.
" Simultaneous (adj.) occurring or operating at the same time."
This then omits what we have already identified as one of the key ingredients to the concurrent engineering philosophy - that of direction and purpose. Here then, we have divorced the two concepts of simultaneous and concurrent engineering for the purpose of this submission, although that is not to say that simultaneous engineering concepts as we have now laid them out will not occur in this work as they do in later sections.