Systems Design

views updated Jun 11 2018

Systems Design

A system can be defined in several ways, including: (1) a set of interrelated parts that function as a whole to achieve a common purpose; (2) a piece of software that operates to manage a related collection of tasks; or (3) a design for an organization that perceives sets of processes as a related collection of tasks.

Systems can be open or closed. An open system is one that interacts with the external environment; a closed system has no external interactions. A system is normally thought to have inputs, outputs, and a transformation process by which the inputs are transformed to the desired outputs. The majority of systems are open, requiring interaction with the environment for the source of inputs and the destination for outputs.

Almost any collection of related items or tasks that take inputs and produce outputs can be characterized as a system. This also allows for subsystems that are contained by the suprasystem. For example, an airplane can be conceived of as a system. The airplane takes fuel, oxygen, and passengers at one point and transforms the fuel and oxygen to a motive force, thus transforming the passengers from people who wanted to travel to people who have arrived. However, an airplane is made up of many subsystems, such as the engine that takes the fuel inputs and the cargo area that accepts passengers. Individually, either of these two subsystems can function, but together they produce an output that is greater than the sum of the outputs from the two subsystems. In many cases, as in the one described here, systems and subsystems are mutually dependent for their survival, or their utility.

Subsystems need to communicate in order for the suprasystem to function effectively. The subsystems therefore require common language(s) for system integration. Language is of the utmost importance in system integration. This connects systems theory and information theory.

Normally, systems are shown as having a feedback loop. An adaptation from engineering control systems,

this requires systems that are automatically controlled to have a feedback loop in order to direct the correction of inputs to result in the correct outputs. In organizational development theory, this feedback loop can be conceived of as business results, consumer comments, or market information.

For example, a thermostat is a simple system. The thermostat takes the temperature of the room as an input. If the temperature is below the set point, the furnace comes on to heat the room. As the room heats, the temperature that is read into the thermostat is compared against the set point. Once the room temperature reaches the set point, the furnace turns off. The input for this system is the room temperature. The transformation process is the heating of the room. The output is the warmed room. The feedback loop is the constant temperature measurement comparison to the set point.

HISTORY

In the late 1940s Norbert Wiener's Cybernetics set the stage for later development of the ideas of systems theory. In 1955, using ideas that were developed from the biological sciences, Bertanlanffy, Hempel, Bass, and Jonas wrote a seminal work on systems theory that presented the activities that occur within a corporation as being similar to a biological system. This was a dramatic shift from the mechanistic way of conceptualizing organizational activities that was popular during the first half of the twentieth century. In 1956 Kenneth E. Boulding presented an addition to systems theory that classified systems into hierarchies. He called this the hierarchy of levels. The hierarchy of levels indicated that systems are composed of a collection of systems that operate in a hierarchical manner.

More recently, Wendell L. French and Cecil H. Bell offered a list of systems into which the typical organization can be separated. The concept of a system was used by Michael Hammer and James Champy to develop their idea of business process reengineering. Systems design continues to be a growing and developing field in the twenty-first century. Such updated works as Valacich, George, and Hoffer's Essentials of Systems Analysis and Design (fourth edition published in 2009, first edition published in 2000), indicate the continuing power and importance of the systems approach for organizing and running present-day businesses.

SYSTEMS DESIGN AND DEVELOPMENT

Systems theory can be helpful in analyzing business processes and finding inefficiencies. Business processes can include a set of elements such as a purchasing agent, a supplier, the customer orders that request a part, and the final product that uses the part. Analyzing how well this system functions across functional lines can help reduce non-value-added activities such as cyclical flows of paperwork and unnecessary cross-checking for accuracy. Many systems such as the one described develop over time without a great deal of effort to design or develop systems with efficiency. They become cumbersome due to stopgap solutions that increase the number of steps, circular flows, and a variety of other non-value-added activities that are usually implemented to minimize errors or solve a problem in service. As a company grows, these stop-gap fixes can cause bottlenecks and delays in the process. At times, the original purpose of the measure is forgotten or even becomes obsolete, but the process is performed this way by employees who do not understand the system and its goals.

Systems within companies are often not readily apparent because they cross functional borders, geographical borders, and hierarchical borders. Employees within the system can therefore be blind to the impact of their activities on the end result of the system. At times, they may not even be aware of the result itself, but simply their piece of the activity. In systems design, therefore, it is often necessary to look across these borders to identify the key activities of the system and eliminate paperwork or other activities that only serve to reduce overall productivity.

Business Process Reengineering. Business process reengineering (BPR) was begun to help companies overcome these artificial barriers and see the whole system as a process that produces an end product, such as a bill, a satisfied customer, or a well-designed product. The popularity of BPR has waned somewhat because of the high number of failures to produce the promised results. In 1999 Hammer and Champy admitted that about 70 percent of the BPR efforts undertaken do not result in success.

BPR is the identification, analysis, and redesign of systems within a corporation in order to improve the efficiency of the operations. Much of the focus of BPR has been on the elimination of labor and employees, often at a fast pace. This has resulted in the phenomenon of downsizing. Downsizing is meant to eliminate all non-value-added activities as well as all nonessential employees of the system under evaluation. This concept attracted enthusiastic adherence in the early 1990s, and it has continued as a common business practice well into the 2000s, with major corporations often eliminating tens of thousands of jobs at a time. For example, in 2008, Ford Motor Company downsized both its manufacturing and white-collar jobs after a previous downsizing in manufacturing during 2006.

Downsizing has left some internal corporate systems changed with the expectation of improved efficiency, but the result was less than favorable. The interaction of other systems had been neglected in the analysis, as was sufficient time to retrain employees to adapt to the new system. The phenomenon of rehiring fired employees as consultants to keep the business running effectively was a direct result of over-enthusiastic downsizing. This, of course, reduced the expected savings and efficiencies, thus reducing the effectiveness of business process reengineering overall.

Examining a System. Systems design requires that all elements of the system be identified: inputs, outputs, feedback, and transformation. In addition, it is important to recognize that an organization consists of many different systems, all of which interact, and that the transitions between systems can be particularly difficult to manage. The use of systems design allows for the compartmentalization of processes into understandable and measurable systems that can then be diagnosed, redesigned, and implemented. This is of great value to complex organizations that are seeking greater efficiency and profitability.

For example, the system of product delivery—including order receipt, production, materials acquisition, packaging, quality control, and delivery—can be seen as a separate system from the human resources system (which consists of the interviewing, hiring, training, development, and release of employees), although the two systems certainly interact. However, analysis of the efficiencies of the human resources system can be conducted separately from analysis of the efficiencies of the product delivery system. Separating the system into its component parts can assist in the diagnosis of problems in a system. For example, hiring employees is an input to the human resources system, the training and development is the transformation, and the release of employees through retirement, layoffs, or firing is an output, as is the delivery of trained and qualified workers.

It is one thing to conceive of an organization as the total system containing various subsystems in the abstract; in practice, however, identifying the suprasystem and the subsystems has no convention and depends entirely upon the arbitrary perspective of the observer. French and Bell identify five subsystems of a corporation that may be considered generic and applicable to most business entities. These five subsystems are technological, task, structural, human-social, and the external interface subsystems. Other observers might identify more subsystems in a completely different manner.

Simply stated, the diagram of a system can be separated into subsystems by tracing a line around the boundaries of related activities that have a common goal. The items that cross the boundary are then considered inputs or outputs.

Value-Added and Non-Value-Added Activities. Systems design requires that one consider the value-added activities and minimize the non-value-added activities. Value-added activities are those that directly affect the product or service, such as assembly or delivery of a package. Non-value-added activities include such things as quality testing and writing a receipt. Normally this requires a cross-functional team that can examine the interfaces over which the system extends and ensure that these “hand-offs” occur efficiently. Various tools are used to develop a system, and several varieties of flow charts and diagrams can be used to develop a visual representation of the system. Team members may then analyze and discuss the activities represented on the flow chart and evaluate whether they are essential or can be minimized or eliminated.

Oftentimes, this is not immediately evident. For example, perhaps accounting policy once required that the account manager be called every time an order came in from a particular company with a spotty payment history. Over time, the computer systems were upgraded to check customer credit and whether a customer was current on its bills. At this point, the call to the account manager could have been eliminated. However, the customer service agent trained to call the account manager does not realize that these checks are occurring. The account manager receiving the calls may consider them important or trivial, but does not realize that at one time the calls were made to prevent over-selling to unreliable customers. During a discussion and analysis of this system, these two functional representatives should find that this activity is non-value-adding and, because of the improvements to the computer system, the calls are now completely unnecessary—a fact that may not have been uncovered otherwise.

In systems design, any activity that does not directly add to the value of the product is eliminated while value-added activities are made efficient. The related activities that must be done, as well as the activities that aid in the accounting, documentation, or delivery of the product, are examined together.

System Development. System development can be the development of a new system or improvement of an existing system. This can be approached much the same as system design and with much the same tools. However, current employees must be included in the development process and retrained to understand and help with the implementation. In addition, the goals or set points and the feedback loops are developed at this point in order to guide the system toward proper performance.

SYSTEM IMPLEMENTATION

Implementation of a new system design must include training employees to understand the new system and their role in achieving the goals the company has for it. Implementation times can vary depending upon the complexity of the system being implemented.

Computer systems have been developed to help organizations conduct, control, and document related tasks more efficiently. In this case, the design and development requires a study of the system to be modeled or controlled by the computer. Software and hardware are then acquired or developed to effectively handle the tasks. Implementation requires a verification stage that tests the computer system prior to actual use to verify that the system operates as envisioned. Modifications to fit the needs of the corporation are usually made over time as problems are identified with use. These systems tend to be expensive and development often requires significant effort to correctly handle the complexities of each individual company. Some computer systems that can be purchased off the shelf can handle such typical tasks as accounting, inventory control, or transportation. Some of these are even developed for a particular industry. However, most off-the-shelf products still require technical modification to fit the needs of the individual company.

It should be apparent that computer systems closely parallel the organizational systems previously discussed. In this sense the two definitions are related but not the same.

SEE ALSO Business Process Reengineering; Open and Closed Systems; Systems Analysis

BIBLIOGRAPHY

Bertanlanffy, Ludwig von. General Systems Theory: Foundations, Development, Applications. rev. ed. New York: George Brazillers, 1976.

Boulding, Kenneth E. “General Systems Theory—The Skeleton of Science.” Management Science 2 April 1956): 197—208.

Dennis, Alan, Barbara Wixom, Robey Roth. Systems Analysis and Design: An Applied Approach. 4th ed. Hoboken, NJ: Wiley, 2008.

French, Wendell L., and Cecil H. Bell, Jr. Organizational Development: Behavioral Science Interventions for Organizational Improvement. 6th ed. Englewood Cliffs, NJ: Prentice Hall, 1999.

Hammer, Michael, and James Champy. Reengineering the Corporation. New York: Harper Business, 2003.

Kast, Fremont E., and James E. Rosenzweig. “General Systems Theory: Applications for Organization and Management.” Academy of Management Journal, December 1972, 447–465.

Kendall, Kenneth, and Julia Kendall. Systems Analysis and Design. 7th ed. Englewood Cliffs, NJ: Prentice-Hall, 2007.

Mingers, John, and Leslie P. Willcocks, eds. Social Theory and Philosophy for Information Systems. New York: John Wiley & Sons, 2004.

Wiener, Norbert. Cybernetics. New York: Wiley, 1948.

Encyclopedia of Management

Systems Design

views updated Jun 08 2018

Systems Design

Systems design is a component of the systems engineering process. Typically, it follows systems analysis, precedes implementation, and is driven by the requirements generated during the earlier phases of the project. Within the context of computer sciences, systems design includes the specification of hardware and software architecture granulated to the necessary components, modules, and interfaces.

The systems design process may include such subcategories as network design, software design, and data design. The scope of the project is a primary determinant of the degree to which any of these and potentially other sub-processes factor into the overall system design effort. Organizational standards and budgetary constraints may also limit design activity.

The sequence of design events relative to other processes in a system's life cycle is largely determined by the systems methodology chosen for the project. This is often based upon the nature of the system being considered. The traditional systems engineering methodology, often referred to as the waterfall paradigm , assumes that all planning, business analysis, risk assessment, and requirements definition occur before any of the design activity begins. All systems design activity must then be completed and verified against requirements before any implementation can begin. Implementation may include constructing a network, developing software, or a combination of such activities, depending on the scope of the system. When implementation is complete, the system is evaluated and ultimately introduced to the operational environment.

Often, such a strict serial methodology is impractical. Increasingly, and especially for the development of software, an iterative approach is chosen. The most evolutionary of the iterative models, often preferred for object-oriented software construction, is the spiral methodology. Under this paradigm, a prototype is rapidly constructed through much shorter phases of analysis, design, development, and testing. The cycle is then repeated many times until the original prototype is adequately refined and ready for operation.

While the waterfall paradigm is structurally confining, the spiral approach has the potential for lack of structure and initial planning. For this reason, a compromise is often chosen between the two models. For instance, project managers may choose an approach that is predominately sequential, but with review and refinement iterations planned between each phase. Or they may choose an incremental model, which is closer to the spiral methodology but defines a limited number of structured iterations.

Regardless of the scope or chosen methodology, systems engineering activities occur in the same functional sequence: Analysis is followed by design, which is followed by implementation. The scope of design activities changes on a per-project basis, but effective design practices apply to all engineering projects regardless of scope or chosen methodology.

The design phase deals with decisions regarding the specific architecture of the system so that it meets all of the stated requirements when constructed. During the first round of an iterative project, requirements may be few and vague. A large-scale waterfall-based project, by contrast, may present many specific requirements. Regardless of scope or methodology, stated requirements must be addressed and verified before the design can be considered complete.

A well-designed system will operate efficiently, providing maximum value given its use of resources. Surplus resources sometimes permit the designer to incorporate features or performance in excess of basic requirements. Such decisions must be carefully evaluated because improving one aspect generally diminishes another. Most systems design decisions involve some degree of compromise, so effective evaluation methods are an important part of the design process.

Decision models, often constructed as tables or trees, may be incorporated to assist designers in quantifying alternatives. Decision tables assist in translating actions and conditions into a tabular format, while tree models generally break a high-level decision into alternatives, each of which is further aggregated into individual consequences and further alternatives. Decision models may extend into several layers of conditions and actions. If systems and their associated decisions are complex enough to justify it, decision support systems may be implemented to assist the decision process. Decision support systems are often computer-based and built specifically to help evaluate both objective and subjective considerations of much larger independent systems. Decision models may be used to help the designer evaluate high-level decisions about the system's construct as well as to demonstrate the internal decision processes that occur within a system.

Other models that assist designers in visualizing system processes include flowcharts and data flow diagrams (DFDs). Both models graphically depict process flows through a system using shapes to represent processes or entities. The shapes are connected by arrows that direct flow.

Flowcharts primarily depict the sequence of decisions internal to a system, based on logical conditions. By convention, boxes indicate processing steps and diamonds depict conditions. This simple set of constructs was originally proposed in the late 1960s and is most effective for designing procedural programs. Object-oriented software development projects may benefit from a program design language such as the Unified Modeling Language (UML), which defines a robust set of notational conventions.

Data flow diagrams provide a means to depict the movement of data through a system or organization. They were introduced in 1979 in the book Structured Analysis and System Specification by Tom DeMarco. The DFD depicts data flow between processes, external agents, and data stores. DFD convention defines an oval to be a process, a rectangle to be an external agent, and two horizontal lines to represent a data store. Other tools for modeling data include entity-relationship diagrams and state-transition diagrams.

Systems design that is complete, based upon solid decisions, and well-documented produces a valuable blueprint for the remaining phases of the engineering project. This is especially important under the waterfall approach, since all subsequent activity is reliant on the product of the design effort, and previous project phases are not easily revisited. An effective design product provides measurable deliverables and verifies that, in concept, the finished system will satisfy all requirements.

see also Design Tools; Office Automation Systems; System Analysis.

Jeffrey C. Wingard