SYSTEMS ENGINEERING

An emerging basis for unifying and relating the complexities of managerial problems is the system concept and its methodology. This concept has been applied more to the analysis of productive systems than to other fields, but it is clear that the value of the concept in management is pervasive.

The word "system" has become so commonplace in the general literature as well as in the field that one often wants to scream, for its common use almost depreciates its value. Yet the word itself is so descriptive of the general interacting nature of the myriad of elements that enter managerial problems that we can no longer talk of complex problems without using the term "systems." Indeed, we must learn to distinguish the general use of the term from its specific use as a mode of structuring and analyzing problems.

One of the great values of the system concept is that it helps us to take a very complex situation and lend order and structure to it by using statistics, probability, and mathematical modeling. A major contribution of the concept is the reduction of complexity in managerial problems to a block diagram showing the relationship and interacting effects of the various elements that affect the problem at hand. At its present state of development and application, the systems concept is most useful in helping us gain insight into problems. At a second and very powerful level of contribution, however, systems analysis is gaining prominence as a basis for generating solutions to problems and evaluating their effects, and for designing alternate systems.

"SYSTEMS" DEFINED

We have been using the term systems without defining it. Though nearly everyone may have a general understanding of the term, it may be useful to be more precise. Webster defines a system as a regularly interacting or interdependent group of items forming a unified whole. Thus a system may have many components and objects, but they are united in the pursuit of some common goal. They are in some sense unified, organized, or coordinated. The components of a system contribute to the production of a set of outputs from given inputs that may or may not be optimal or best with respect to some appropriate measure of effectiveness. Systems are often complex, although the definition does not specify that they need to be.

It is probably correct to say that some of the most interesting systems for study are complex and that a change in one variable within the system will affect many other variables of the system. Thus in productive systems, a change in production rate may affect inventories, hours worked per week, overtime hours, facility layout, and so on. Understanding and predicting these complex interactions among variables is one of our main objectives in this section.

One of the elusive aspects of the systems concept is in the definition of a specific system. The fact that we can define the system that we wish to consider and draw boundaries around it is important. We can then look inside the defined system to see what happens, but it is just as important to see how the system is affected by its environment.

Thus, invariably, every system can be thought of as a part of an even larger system. One of the dangers of defining systems that are too narrow in scope is that we may fail to see broader implications. On the other hand, a broad definition runs the risk of leaving out important details involved in the functioning of the system. Obviously, there is a large element of "art" in the application of systems concepts.

Systems can be open or closed. An open system is one characterized by outputs that respond to inputs but where the outputs are isolated from and have no influence on the inputs. An open system is not aware of its own performance. In an open system, past performance does not control future performance.

A closed system (sometimes called a feedback system), on the other hand, is influenced by its own behavior. A feedback system has a closed loop structure that brings results from past action of the system back to control future action. There are two types of feedback systems: the negative feedback, which seeks a goal and responds as a consequence of failure to achieve the goal, and the positive feedback, which generates growth processes wherein action builds a result that generates still greater action. Unfortunately most of the feedback systems in managerial problems are of the negative feedback type where the objective is to control a process.

IMPLICATIONS OF THE SYSTEMS CONCEPT FOR THE MANAGER

Managers who put the systems concept to work are rewarded initially by the development of a deeper understanding of the systems that they manage. By developing the structure of the interacting effects of system components and the various feedback control loops in the system, managers can see better which "handles" to twist in order to keep themselves in control. Indeed, with a knowledge of the system structure, a manager can see how it might be possible to restructure the system in order to create the most effective feedback control mechanisms.

With the availability of large-scale system models (simulation, statistical, reliability, and mathematical models) a manager is better able to assess the effects of changes in one division component on another and on the organization as a whole. Furthermore, the managers of any of the productive operations are better able to see how their units fit into the whole and to understand the kinds of trade-offs that are often made by higher level management and that sometimes seemingly affect one unit adversely.

Perhaps one of the most important contributions of systems thinking is in the concept of suboptimization. Suboptimization often occurs when one views a problem narrowly. For example, one can construct mathematical formulas to determine the minimum cost (optimum) quantity of products or parts to manufacture at one time, which results in a supposedly optimum inventory level. If one broadens the definition of the system under study, however, and includes not just the inventory and reorder subsystem but the production and warehousing subsystems as well, it may turn out that the inventory-connected costs are a measure of only part of the problem. If the product exhibits seasonal sales, the costs of changing production levels may be significant enough to warrant carrying extra inventories to smooth production and employment. In such a situation, the minimum cost inventory model would be a suboptimal policy.

Organizational suboptimization often occurs when the production and distribution functions of an enterprise are operated as essentially two different businesses. The factory manager will be faced with minimizing production cost while the sales/distribution manager will be faced mainly with an inventory management, shipping, and customer service problem. Each suborganization attempting to optimize separately will likely result in a combined cost somewhat larger than if the attempt were made to optimize the combined system. The reasons are fairly obvious, since in minimizing the costs of inventories, the sales function transmits directly to the factory most of the effects of sales fluctuations instead of absorbing these fluctuations through buffer inventories. Suboptimization is the result. By coordinating the efforts of the production and distribution managers, however, it may be possible to achieve some balance between inventory costs and the costs of production fluctuation.

Another way to view suboptimization is through the "hidden factory" ” the terminology of six sigma. If we take for example the issue of safety, let us examine what is really at stake. No one will deny that the bottom line of all safety programs is injury prevention, more often called "loss control." To appreciate the concept of "loss control," however, we must look at the direct and indirect costs (often called the hidden costs) associated with an on-the-job injury .

The direct costs are:

1. Medical

2. Compensation

The indirect costs are:

1. Time lost from work by injured

2. Loss in earning power

3. Economic loss to injured's family

4. Lost time by fellow workers

5. Loss of efficiency due to breakup of crew

6. Lost time by supervision

7. Cost of breaking in new worker

8. Damage to tools and equipment

9. Time damaged equipment is out of service

10. Spoiled work

11. Loss of production

12. Spoilage ” fire, water, chemical, explosives, and so on

13. Failure to fill orders

14. Overhead cost (while work was disrupted)

15. Miscellaneous (There are at least 100 other items of cost that appear one or more times with every incident in which a worker is injured.)

The point here is that with most injuries the focus becomes the direct cost, thereby dismissing the indirect costs. It has been estimated time and again that the cost relationship of direct to indirect cost is one to three, yet we continue to ignore the real problems of injury. An appropriate system design for injury prevention would minimize if not eliminate the hidden costs. Generally speaking, the system should include (a) engineering, (b) education, and (c) enforcement considerations. Some specific considerations should be:

1. Workers will not be injured or killed

2. Property and materials will not be destroyed

3. Production will flow more smoothly

4. You will have more time for the other management duties of your job

DEFINING SYSTEMS ENGINEERING

A simple definition of systems engineering is: A customer/requirements-driven engineering and management process which transforms the voice of the customer(s) into a feasible and verified product/process of appropriate configuration, capability, and cost/price. A system is always greater than the sum of its parts and is no better than the weakest link. The derivative of that, of course, is that optimizing a part does not optimize the whole. This was brought out by Mayne et al. (2001), when they reported that 37% of all the automotive warranty for model year 2000 was in interfacing of parts rather than individual components. The message of Mayne and coworkers and most of us in the quality field has been and continues to be: interactions determine the performance of the system. We cannot, no matter how hard we try, fully understand the whole by breaking down and analyzing parts ” yet design is historically done precisely that way.

Systems engineering builds on the fact that the whole is the most important entity and that integration to meet cost, schedule, and technical performance is dependent on both technical and management intervention. Ultimately, systems engineering is a team-based activity. This is very important because as we move into the future we see that:

1. Quality is becoming more customer dependent rather than definitional from the provider's point of view. In other words, we must specify what the product or service must do and how well it must do it, then verify the design to those requirements.

2. Products/services are becoming more sophisticated (complex).

3. Traditionally, product development has been very serial with designs thrown over the imaginary wall to manufacturing ” something that today is not working very well. This has resulted in late changes and ultimately higher costs. Systems engineering is based on the notion that design may be on a parallel development process and with a strong consideration for its total life cycle ” manufacture, delivery, maintenance, decommission, and recycling.

For systems engineering to be effective in any organization, that organization must be committed to integration of several items including timing of development and specific delivery(ies) at specific milestones. A generic approach to facilitate this is the following model, involving the steps of pre-feasibility analysis, requirement analysis, design synthesis, and verification.

PRE-FEASIBILITY ANALYSIS

Before the actual analysis takes place there is a preliminary trade-off analysis as to what the customer needs and wants and what the organization is willing to provide. This is done under the rubric of preliminary feasibility. When the feasibility is complete, then the actual requirement analysis takes place.

REQUIREMENT ANALYSIS

The requirement analysis involves the following steps:

1. Collect the requirements ” the customer's needs, wants, and expectations are collected at every level.

2. Organize requirements ” group the information in such a way that requirements are easy to address. Determine if the requirements are complete.

3. Translate into more precise terms ” cascade the definitions to precise terms, honing their definition to the best possible correlation of real world usage.

4. Develop verification requirements ” preliminary verification tests are discussed and proposed here to make sure that they are in fact doable.

At the end of the requirement analysis the results are moved to the second stage of the system engineering model, which is design synthesis. However, before the synthesis actually takes place, another feasibility analysis is completed to find out whether the organization is capable of designing the requirements of the customer. This feasibility analysis takes into consideration the organization's knowledge from previous or similar designs and incorporates it into the new. The idea of this feasibility analysis is to make sure the designers optimize reusability and carry over parts and/or complete designs.

DESIGN SYNTHESIS

Design synthesis involves the following steps:

1. Generate alternatives ” the more alternatives the better. The alternatives are generated with functionality in mind from the customer's perspective as reflected in the system specifications. Remember that the ultimate design is indeed a trade-off design.

2. Evaluate alternatives ” the generated alternatives are evaluated with appropriate benchmarking data and integrated into the design based on the customer's requirements.

3. Generate sub element requirements ” big chunks or sub elements are chosen and requirements cascaded to each sub element. As the cascading process continues, verification requirements are also developed to test the overall system integrity as more and more sub elements are integrated into the total system.

At the end of the design synthesis a very important analysis takes place. This analysis tests the integrity of the design against the customer's requirements. If it is found that the requirements are not addressed (design gap), a redesign or a review takes place and a fix is issued. If, on the other hand, everything is as planned, the process moves to the third link of the model ” verification.

VERIFICATION

The final stage is verification. It involves the following:

1. Verify that requirements are complete ” a review of all requirements from both design and the customer takes place with appropriate tests and correlated to real world usage.

2. Verify that design meets customer's requirements ” CAE tools, labs, rigs, simulations, and key life testing are some of the verification methodologies used at this stage. The intent here is to verify that the selected system and cascaded requirements will meet the customer's requirements and provide a balanced optimum design from the customer's perspective.

At the end of this stage, if problems are found they (the problems) revert back to the design; if there are no problems, the design goes to manufacturing, with a design ready to fulfill the customer's expectations. This final stage in essence tests the integrity of the design against the actual hardware. In other words, the questions often heard in verification are: Does the design work? Can you prove it?

The beauty of this model is that it is an iterative model, meaning that the process ” no matter where you are in the model ” iterates until a balanced optimum design is achieved. This is because the goal is to design a customer-friendly design with compatibility, carryover, reusability, and low complexity requirements compared to other, similar designs. Iterations happen because of human oversights, poorly defined requirements, or an increase in knowledge.

Another special characteristic of systems engineering is the notion of traceability. Traceability is reverse cascading and is used throughout the design process to make sure that the voices of the customer, regulator , and corporate or lower-level design are heard and accounted for in the overall design. With traceability, extra caution is given to the trade-off analysis. This is because by definition trade-off analysis accounts for designs with certain priority levels among the needs and wants of the customer. In a trade-off analysis, we choose among stated design alternatives.

However, a trade-off analysis is also an iterative process, and usually none of the alternatives is perfect [R(t) = 1 - F(t)]. This is important to remember because all trade-off analyses assess risk, both external and internal, of the given alternatives so as to make robust designs.

A final word about verification and systems engineering: As we already mentioned, the intent of verification is to make sure that the hardware meets the requirements of the design. The process for conducting this verification is done ” generally ” in five steps, which are:

1. Plan ” Review all requirements and make a preliminary assessment as to their impact. At the end of this evaluation, take ownership of important requirements and begin the assessment of specific tests and methods . It is not unusual at this stage to review the plan again and perhaps combine, consolidate, or even adjust the plan completely. In this stage we select attribute data, as well, monitor the " unselected " requirement, schedule preliminary tests, and approve the testing schedule. As you begin to zero in on specific targets, you may want to take into consideration features of the proposed design and benchmarking data so that your targets become of value to the customer. If this plan is rich in information, it is possible to begin predicting and formulating prototype(s).

2. Execute ” In this stage, the engineer in charge will determine which test(s) to run, when to run them, what the data should look like, and what to expect. Proper test execution is of importance here.

3. Analyze/ revise ” Analyze the test results, and see if the design has changed in any way. Determine whether to redo the test if the design changed during the test for any reason. At this stage you expect no design changes, only testing revisions and modifications.

4. Sign-off ” This is the most common ending for a verification process. In this stage final approvals are given, usually several months before production begins.

5. Archive ” This is a step that most engineers do not do, yet it is a very important step in the process. The idea of archiving or documenting is to make sure that key events are appropriately documented for future use. You may want to document unusual tests, time frames of specific tests, or any specific requirements that you had the intention of verifying but could not verify using the planned method. In essence, this phase of verification consists of lessons learned that need to be carried forward to the next design.

The focus of this process is to make sure that the requirements are driving the process and not the tests regardless of how sophisticated they are. To be sure, tests are an integral part of verification, but they are the means not the end. The intent of the tests is to verify each requirement, and there is no wrong way as long as the testing method is linked to real world usage. The reason for doing all this is to:

1. Reduce workload in design verification

2. Improve prototype and testing efficiency by avoiding duplication

3. Improve testing quality resulting in higher sign-off confidence

4. Improve communication and stronger relationships between customer and suppliers