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 air-plane 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.
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, and the concept of systems was used for the development of business process reengineering activities, as described by Michael Hammer and James Champy.
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 stop-gap 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 (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. However, it 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.
Systems design requires that all elements of the system be identified: inputs, out-puts, 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 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 either inputs or outputs.
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 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.
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 can be purchased off the shelf that 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.
Terri Friel
Revised by Badie N. Farah
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.
Flood, R.L., and E.R. Carson. Dealing With Complexity: An Introduction to the Theory and Application of Systems Science. 2nd ed. New York: Plenum, 1993.
Flood, R.L., and M.C. Jackson. Creative Problem Solving: Total Systems Intervention. Chichester, UK: Wiley, 1991.
——. Critical Systems Thinking: Directed Readings. Chichester, UK: Wiley, 1991.
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 Jamens E. Rosenzweig. "General Systems Theory: Applications for Organization and Management." Academy of Management Journal, December 1972, 447–465.
Laszlo, Ervin. Introduction to Systems Philosophy. New York: Gordon and Breach, Science Publishers, 1972.
Machol, R.E., ed. Systems Engineering Handbook. New York: McGraw-Hill, 1965.
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.
Comment about this article, ask questions, or add new information about this topic: