Systems Thinking

Typically, systems requirements analysis fails because of two reasons:

1. The analysis is not sufficiently systemic – it reduces a complex system down to a subset of activities and work-goals that can be understood.
2. The analysis is too focused on what can be computerized. It does not analyze what needs to change, but what the IT system should do to support an [implicit] set of changes.

Why are systems changes counter-intuitive?

The human mind is not adapted to understand the consequences of a complex mental model of how things work. There are internal contradictions between future structures and future consequences, that become difficult to balance when multiple mental models are involved. Most people are “point thinkers” who only see part of the big picture. It is easy to mis-judge the effects of change, when you only base your arguments on a subset of cause and effect. Systemic thinkers analyze interactions between various factors affecting a situation, to understand cycles of influence that affect our ability to intervene in changing the situation.
An example of counter-intuitive set of influences is shown in the “systemic” view of a limited social welfare system, given in Figure 1.

Figure 1. A Systemic View of A Limited Social Welfare System

We have two opposing “vicious cycles” of influence, in this model:

• The left-hand cycle reinforces the argument that raising welfare payments encourages “entitlement” and disincentivizes work.
• The right-hand cycle supports a counter argument, that raising welfare payments attracts job-seekers and increases employment, raising tax base revenue, to provide a net benefit (as well as humane assistance).

Unless a complete view of the whole system of interrelated processes is obtained, well-intentioned changes have unintended consequences. It is necessary to understand the system as a whole, rather than individual effects between factors, to understand these “vicious circles” of cause-and-effect. Tweaking one element will affect others, with knock-on effects as the two cycles interact. The only way to ensure a specific outcome is to intervene to break the cycle of influence (change the relationship between factors), or appreciate the interaction effects, so you can predict the outcome.

Soft Systems Methodology (SSM) provides a philosophy and a set of techniques for investigating an unstructured problem situation. SSM is an approach to the investigation of the problems that may or may not require computer-based system support as part of its solution. In this sense, SSM could be described as an approach to system requirements analysis, rather than a systems design approach.

Unlike most systems requirements analysis techniques (e.g. UML, entity-relationship modeling or data-flow diagrams), which focus on how the computer system should operate, SSM focuses on the system of work – the “human activity system” that requires computer system support. SSM asks the fundamental question that should (but usually does not) precede system requirements analysis:

“Why do we want a computer system and what role will it perform, in supporting people and organizational work?”

SSM questions what operations the system should perform and, more importantly, why. The approach provides a “soft” investigation (into what the system should do) which can be used to precede the “hard” investigation (into how the system should do it)., as shown in Figure 2.

Figure 2. Modeling “Soft Systems” To Explore The Real World

SSM does not produce either a set of information system requirements or an information system design. SSM produces a set of feasible and locally (culturally) acceptable actions which can be taken to improve the problem situation. These actions may be used to produce a set of information systems requirements, but it is more helpful to see them as a set of organizational process improvements, where a process is a set of organizational tasks performed purposefully by a human actor or actors.

Most methods for Information Systems requirements determination place the investigator (the systems analyst) in the role of “expert”. In other words, the analyst attempts to understand the organizational situation, determines what computer system functions are required by interviewing potential system users and/or managers, then draws on their expert knowledge of other computer systems to specify a hardware and software “system”, based upon their understanding of the organizational situation and tasks. If the analyst’s understanding is incorrect or incomplete, this is usually not detected until the system is tested by its organizational users, which may not happen until the system has been installed. This situation occurs because system users do not normally possess sufficient technical knowledge to understand and question the highly-technical system specification documents which the analyst produces, so any misunderstandings are not revealed until the system is built. One way of avoiding this problem is to produce a system prototype, where the system designer builds a trial version of the system for the users to try out. Comments and criticisms are fed back to the designer, who changes the system and produces another prototype; this process is repeated until both designer and users are happy with the system’s operation. However, prototyping is not appropriate for all development situations (such as very large, complex systems, where each user will only understand a very small part of the system’s operations) and also, a great deal of effort in producing and modifying inappropriate prototype systems can be avoided if a more effective investigation is performed into the system requirements in the first place.

The area where SSM is of most use is in information system requirements investigation, where the problem situation is seen as “fuzzy” or ill-defined. In other words, it is not immediately clear what type of system or systems will solve the problems of the organizational work-system.

The advantage of SSM in such cases is that it models explicitly the different value-systems (perspectives) of various people in the organization, representing different people’s differing beliefs about the effectiveness and purpose of the organization (or their part of the organization) and their perceptions of current information systems within it. When organizational problems are difficult to define, many problems can be due to work “systems” (for example a department) prioritizing one set of organizational objectives at the expense of another set of objectives. For example, a computer-based system for the authorization of traveling expenses, used by staff in the accounts department may have been designed to reject claims which do not conform to low-cost criteria. Use of this system will force (or “encourage”) staff to use the form of travel which has the lowest cost (e.g. train rather than car) even when the company may lose business by someone not being able to reach a business client before a competitor. The use of SSM for the analysis of requirements for a traveling expenses system would make this conflict explicit, leading to the specification of an alternative system which was able to flexibly approve the expense on the joint criteria of cost and urgency.