Category: systemic thinking

Soft Systems Methodology (SSM) – A Summary

SSM As an Iterative Inquiring/Learning Cycle of Change

SSM is based upon a simple concept: that we separate and analyze systems of purposeful human activity (what people do), rather than data-processing or IT systems (how IT components should function to support what people do). SSM is helpful for analysis approaches that wish to understand the connections, conflicts, and discrepancies between elements of a situation rather than attempting to subsume all elements into a single perspective. It is systemic, rather than systems-focused, exploring relationships between participants and between perspectives (Checkland, 2000a).

Separating Out Purposeful System Perspectives

SSM relies on the explicit declaration of worldviews which make each purposeful system model meaningful to participants. In defining purposeful models, the Soft Systems Method (SSM) avoids what Russell Ackoff (1974) called “messes”: the typical situation where none of the requirements for change are understood or implemented fully, because the relationship between requirements is systemic (each requirement has “knock-on” implications for other requirements). Unraveling systemic messes needs a divide-and-conquer approach that separates out the requirements for each separate purpose that the system-of-work exists to achieve, as shown in Figure 4. We delay this stage until we have a reasonable understanding of the problem situation: what various actors do, why they do it, and how they interact to achieve their purposes.

SSM transformation process overview, showing key elements: input, transformation, output, worldview, and success criteria — Figure 4. SSM Transformation Process Overview

Generating one perspective on the work-system at a time allows us to analyze what work-activities need to be done to achieve a single purpose — and how actors’ work-outcomes are evaluated — in isolation from all the other purposes, before merging perspectives back into a (better understood) integrated system-of-human-activity so we may determine priorities for change. This divide-and-conquer strategy employs the CATWOE framework to define each perspective (or purposeful system):

Client	Who is the victim or beneficiary of these changes?
Actors	Who performs the work for this transformation?
Transformation	How is an entity, the input to the transforming process, changed into a different state or form to become the output of the process?
Weltanschauung	What is the perspective that makes the transformation significant to participants (the purpose)?
Owner	Who has the power to say whether the system will be implemented or not?
Environment	What needs to be known about the environmental conditions that the system operates under?

Table 1. The CATWOE Framework

Complex transformations should be separated into distinct purposes, with a single set of actors. It is usually an indication that you have conflated two purposes if you have two different sets of actors involved – you will tie yourself in knots attempting to model both points of view at the same time. You can happily repeat the exercise using another perspective, to see if you can balance the needs of two purposes with the same system, but conflating perspectives often leads to change requirements being overlooked. Sometimes it may not be possible to balance two perspectives – for example, how do you integrate the needs of drivers to park easily with the needs of pedestrians to be kept safe in congested areas? If you cannot integrate competing perspectives, you must take a decision about whose perspective will have priority – this is where your client’s objectives come into play. In every change, there are winners and losers; your job is to make it explicit who loses and who wins, rather than to make this decision for the client (!).

Defining and Prioritizing Requirements For Change

Once each transformation is defined, it can be explored in terms of the potential sequences of activity needed to achieve that purpose. Participants and other stakeholders are involved in developing conceptual models that reflect “ideal world” sub-systems of activity. Not all of these activities may be implemented – or they may not be implemented in the way originally envisaged. Subsequent changes to the real-world system of work are evaluated by managers and the client of the change initiative, to determine the order and priorities for change. But it is important to understand what work needs to be done, so you can consider constraints on achieving the desired outcomes should your client not choose to implement some process-changes. Actions to improve the problem-situation are based on finding accommodations that balance the interests of competing perspectives. This involves defining versions of the situation which stakeholders with competing interests can live with (Checkland, 2000b).

In much of his later work, Checkland addresses the difficulty of converting a model that represents a system of human activity into a set of requirements for an IT-based information system by distinguishing between the supporting system (IT) and the supported system (human activity). The supported system represents the problem domain, the amalgam of purposeful systems of human activity that underpins the problem situation. The supporting system represents the solution domain, that combination of people, processes, and technology that provides a solution to problems identified by participants in the problem situation.

Fig 4. The supporting system of IT vs. the supported system of human activity

Reconciliation between the two system views depends on the translation of requirements for change to the human-activity system to IT system requirements. If these changes are undertaken incrementally, with a focus on a single purposeful system perspective at a time, this is generally fairly simple to accomplish – it aligns well with the business-process (re)design approach used by most organizations in driving IT change.

The Contribution of SSM

Soft Systems Methodology (SSM) was devised by Peter Checkland and elaborated in collaboration with others at Lancaster University in the UK: (Winter, Brown, & Checkland, 1995; Checkland & Scholes, 1999; Checkland & Holwell, 2007; Checkland & Poulter, 2006). Its contribution is to separate the analysis of the “soft system” of human-activity from the “hard system” of IT and engineering logic that serves the needs of the human-activity system.

Checkland distinguishes between the hard, engineering school of thought and soft systems thinking. The development of systems concepts and system thinking methods to solve ill-structured, “soft” problems is Checkland’s (1979) contribution to the field of systems theory. Soft Systems Methodology (SSM) provides a method for participatory design centered on human-centered information systems. It also provides an excellent approach to surfacing multiple perspectives in decision-making, complex problem-analysis, and socially-situated research. The analysis tools suggested by the method — which is really a family of methods, rather than a single method in the sense of modeling techniques — permit change-analysts, consultants and researchers to exercise reflexivity and to explore alternatives. In his valedictory lecture at Lancaster University, Peter Checkland listed four “big thoughts” that underlie soft systems thinking (Checkland, 2000a):

1. Treat linked activities as a purposeful system.

2. Declare worldviews which make purposeful models meaningful (there will be many!).

3. Enact SSM as a learning system, finding accommodations enabling action to be taken.

4. Use models of activity systems as a base for work on information systems.

Systems thinking attempts to understand problems systemically. Problems are ultimately subjective: we select things to include and things to exclude from our problem analysis (the “system boundary”). But real-world problems are wicked problems, consisting of interrelated sub-problems that cannot be disentangled — and therefore cannot be defined objectively (Rittel, 1972; Rittel & Webber, 1973). The best we can do is to define problems that are related to the various purposes that participants pursue, in performing their work. By solving one problem, we often make another problem worse, or complicate matters in some way. Systemic thinking attempts to understand the interrelatedness of problems and goals by separating them out.

In understanding different sets of activities and the problems pertaining to those activities as conceptually-separated models, we understand also the complexity of the whole “system” of work and the interrelatedness of things – at least, to some extent. It is important to understand that, given the evolving nature of organizational work, a great deal of the value of this approach lies in the collective learning achieved by involving actors in the situation in analyzing changes, and that this approach in inquiry is, in principle, never ending. It is best conducted with and by problem-situation participants (Checkland, 2000b).

SSM is an approach to the investigation of organizational problems that may – or may not – require computer-based system support for their solution. In this sense, SSM could be described as an approach to generating early requirements for change analysis, rather than as a systems design approach. The original, seven-step method of SSM (Checkland, 1979) has been replaced by more nuanced approaches to soft systems analysis (note the loss of the word “method”). Checkland now considers the approach more of a mindset, or way of thinking than a strict set of steps that should be followed (Checkland & Holwell, 1997). However, without the roadmap provided by the seven stages of analysis, it can be difficult to understand where to start. For this reason, the discussion on this site employs the terminology and approach of the seven-stage method originally proposed, while attempting to iron out some of the complexities and confusions in the original (Checkland, 1979).

This website attempts to explain some of the elements of SSM for educational purposes. It is not intended as a comprehensive source of information about SSM, but as a reflection of my own tussles with the approach.
As a result, it may well subvert some of Checkland’s original intentions, in my attempt to make the subject accessible to students and other inquiring minds … .

Note [1]: Weltanschauung is a German word, used in philosophical works to represent a particular philosophy or view of life, especially when analyzing the worldview of an individual or group. Checkland (1979) adopted the term in its philosophical sense when he was making the argument that the purposes for which a system of human-activity (or work) exist are situated within a specific sociocultural framework of rules and expectations that govern who-does-what and how. The idea is similar to Anselm Strauss’ concept of social worlds, where participants draw on experience-based interpretations, culturally-situated, relational identities, and shared interpretations of organizational structures that allow them to respond automatically to new phenomena and events (Strauss, 1978). The term “worldview” may be substituted, with the understanding that this reflects the broader use of the term to indicate socioculturally-situated interpretations, not simply an individual’s point of view.

References

Ackoff, R. L. (1974). Redesigning The Future: Wiley.

Checkland, P. (1979) Systems Thinking, Systems Practice. John Wiley and Sons Ltd. Chichester UK. Latest edition includes a 30-year retrospective. ISBN: 0-471-98606-2.

Checkland P., Casar A. (1986) Vickers’ concept of an appreciative system: A systemic account. Journal of Applied Systems Analysis 13: 3-17

Checkland, P., Holwell, S.E. (1998) Information, Systems and Information Systems. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-95820-4.

Checkland, P. & Scholes, J. (1999) Soft Systems Methodology in Action. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98605-4.

Checkland, P. (2000a) New maps of knowledge. Some animadversions (friendly) on: science (reductionist), social science (hermeneutic), research (unmanageable) and universities (unmanaged). Systems Research and Behavioural Science, 17(S1), pages S59-S75. http://www3.interscience.wiley.com/journal/75502924/abstract

Checkland, P. (2000b). Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science, 17: S11-S58.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners, Teachers and Students. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-470-02554-9.

Churchman, C.W. (1971) The Design of Inquiring Systems, Basic Concepts of Systems and Organizations, Basic Books, New York.

Rittel, H. W. J. (1972). Second Generation Design Methods. Design Methods Group 5th Anniversary Report: 5-10. DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.: Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327.

Rittel, H. W. J. and M. M. Webber (1973). “Dilemmas in a General Theory of Planning.” Policy Sciences 4, pp. 155-169.

Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.

Winter, M., Brown, D. H., & Checkland, P. B. (1995). A role for soft systems methodology in information systems development. European Journal of Information Systems, 4(3), 130-142.

von Bertanlaffy, L. (1968) General System theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976.

December 27, 2014

Systems Thinking
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 misjudge 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.

In the pages that follow, I explore Soft Systems Methodology (SSM) – an approach that provides a philosophy and a set of techniques for investigating an unstructured problem situation without the constraints and blinkers that come with systems requirements techniques. SSM investigates an organization as a system of work-activities that may or may not require computer-based system support in solving problems with this system of work. 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 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.
December 7, 2014
Step 4: Conceptual Models

Step 4: Conceptual Models

Deriving a conceptual model is a method of analyzing the activities which need to take place in order to clearly define what the actors need to do in order to achieve the transformation. Do not include activities performed by anyone other than the actors whom you have named in the root definition (and if possible, limit the actors to one group of people – activity-monitoring becomes very complicated when more than one group are involved). Again, disciplined thinking is required – list the activities needed to achieve the objectives of the system. It is important also to include activities which monitor the system and feed-back results, so that system activities may be performed effectively. Ask: what defines success for this system? how can I measure that success? what do my actors need to do, to measure success?

I have chosen to provide a conceptual model for transformation (7), in the two examples below. The Root Definition for this system is:

A system owned by Local Government Administration, where a combination of parking restrictions, to alleviate congestion at bottlenecks, and public transport provision, to make driving less attractive for short journeys, reduces the number of cars on the road and so improves air quality and traffic flow on major routes.

The list of activities which I perceive as necessary for this transformation are:
1. Determine the extent of the problem (congestion & emissions), by major traffic route
2. Assess potential impact on these factors by managing parking, or implementing public transport
3. Take those actions that produce these impacts
4. Measure the number of people who transfer from cars to public transport
5. Measure the impact upon the environment of that transfer
6. Report to the public on the results.

In Figures 4-1 and 4-2, I contrast a weak attempt at a conceptual model with a strong(er) attempt, for Transformation 7: Traffic congestion causes high C02 & particulate emissions ⟶ Easy and convenient public transport replaces need for short car journeys on local routes.

Figure 4-1. A Weak Conceptual Model for Transformation 7.

The conceptual model shown in Figure 4-1 would be considered weak because each activity in the conceptual model is defined minimally. The activity defines what is to be done (the basic steps of the transformation), but not how to do it so that the purpose of the transformation (the combination of transformation, worldview/rationale, and evaluation of outcomes is achieved. Even the evaluation of the subsystem of activity is minimal, using only a single indicator to evaluate success.has fallen into the “consultancy mode” trap. What I have defined here is not what needs to be done, but how I, as a consultant, intend to find out what needs to be done and then take action. This happens whenever you do not have sufficient information from the stakeholders about what actually needs to be done – so you fudge the set of requisite activities! This is a core part of the “appreciating the situation” work of step 1.

As part of the step 1 analysis, you need to interview as many stakeholders as you can, to gather perspectives and to understand what they would like to happen – and why this system-purpose is important to them. This is often an iterative process: you define a transformation from one perspective, explore what needs to be done to achieve it , then realize that you need more information from stakeholders to understand the “hows” and “whys” of these activities. Having iterated a couple of time, you can then define a much more informed – and feasible conceptual model, as shown in Figure 4-2.

Let us imagine that I have done this – and the core stakeholders suggested two main strategies for achieving transformation (7):
– Increase fines for driving offenses and cross-subsidize public transport with the revenue raised.
– Make driving more difficult and time-consuming than public transport by rationing road use and policing parking at bottlenecks.

Figure 4-2. A Strong Conceptual Model for Transformation 7.

This conceptual model shown in Figure 4-2 is stronger, as it defines activities in terms of what needs to be done, and how, to achieve the desired purpose of the transformation. Each activity is defined from the worldview of why this transformation is important to the success of the system as a whole (of which it reflects one perspective). At each stage of the sequence of activity, evaluation criteria are considered – for example, when cost-benefit analyses are used to prioritize traffic routes for change implementation. This analysis of activities produces multiple indicators by which we can evaluate success, which allows us to tweak both activities and success criteria, on each cycle around the steps of this subsystem (which would be repeated multiple times, over the duration of the change project).

An important element of conceptual models are the feedback loops. There are normally two feedback loops in any conceptual model:
1. An internal feedback loop, that permits actors involved in the human-activity system perspective modeled to adjust how they perform their work (in this case, this loop is between the first and last “Measure traffic flows, congestion-points, CO2 and particulate emissions, in key places along each route” activities, enabling the state of the system at the start of the activity to be compared to the state of the system at the end of this round of activity). This feedback loop (the dotted line inside the model boundary) permits the people doing the work to evaluate their performance.
2. An external feedback loop, between the inputs and the outputs of the activity system model for this perspective. This feedback loop (the heavier dotted line outside of the model boundary) permits external managers to evaluate the performance of the system from this perspective. To permit the effective management of any system, you need to define measures of success for each transformation-purpose of the system. There is rarely a single measure that will indicate success – instead, use compound measures to evaluate complex outcomes – as shown to the right of the conceptual model in Figure 4-2.

December 6, 2014
Soft Systems Methodology (SSM)

Intro to Soft Systems Methodology

Soft Systems Methodology (SSM) provides a philosophy and a set of techniques – a method – for investigating a “real-world” problem situation. SSM provides an approach to participatory design that focuses on human-centered information systems by analyzing organizations as systems of human-activity. It also provides an excellent method for surfacing multiple perspectives in decision-making, complex problem-analysis, and socially-situated research. The analysis tools suggested by the method — which is really a family of methods, rather than a single method in the sense of modeling techniques — permit change-analysts, consultants and researchers to explore alternatives for change, while exercising reflexivity in considering the effect of their own prejudices and biases on the analysis.

SSM could be described as an approach to change requirements analysis, rather than a systems design or IT requirements approach. It questions what operations the system-of-work 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). The approach focuses on the investigation of situated problems that may or may not require computer-based system support as part of their solution. It investigates an unstructured problem situation that is viewed as a governed by business logic, rather than the engineering logic normally attached to IT system requirements. 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?”

The analysis is based upon a simple concept: that we model systems of purposeful human activity (what people do), separating these out into sub-systems that serve different purposes in order to understand the complexity involved. It models the sequence and interactions of human processes rather than data-management or IT components (the more usual focus of systems analysis). It is systemic, rather than systems-focused, calling upon the tradition of general systems theory (von Bertanlaffy, 1968) and inquiring systems (Churchman, 1971) in acknowledging the disparate elements of a situation. SSM is helpful for analysis approaches that wish to understand the connections, conflicts, and discrepancies between elements of a situation rather than attempting to subsume all elements into a single perspective.

The Origins of SSM

Soft Systems Analysis is based on Vickers’ concept of Appreciative Systems (Vickers, 1968; Checkland, 2000b). Geoffrey Vickers observed the diversity of norms, relationships, and experiential perspectives among those involved in, or affected by, a system of human-activity such as that found in business work-organizations. He argued that organizational change analysts needed methods for analysis that explored how to reconcile these perspectives, developing the concept of an “appreciative system,” the set of iterative interactions by which we explore, interpret, and mutually construct our shared organizational reality (Vickers, 1968), shown in Figure 1.

Figure 1. The Concept of an Appreciative System
(Source: Checkland and Casar (1986), via Checkland (2000b)

Vickers conceptualized organizational work as a stream, or flux, or events and ideas that were interpreted by participants in the organization by means of local “standards,” reflecting shared interpretation schema and sociocultural values (Checkland and Casar, 1986). Interpretations of new events and ideas are subject to the experiential learning that resulted from prior encounters with similar phenomena; these will vary across stakeholders, depending on how they interpret the purpose of the system of work-activity. To achieve substantive change, we need to understand and reconcile these multiple purposes, integrating requirements for change across the multiple system perspectives espoused by various stakeholders. These are separated out into distinct perspectives, which model subsets of activity that are related to a specific purpose or group of participants in the problem situation (Checkland, 1979, 2000b).

From Appreciative Systems To Soft Systems

Following from his studies of the appreciative systems approach to change and IT requirements analysis, Checkland (1979) focused on the analysis of SOFT SYSTEMS, purposeful systems of human activity that represent how various business processes, groups, or functions work, are organized,and interact. The idea is to apply systems theory to the modeling of organizational work, representing what people do (or need to do, to achieve their goals) rather than losing sight of stakeholder perspectives as we model information or technology architectures.

Soft Systems Methodology (SSM) provides a framework for the analysis of organizational change. It focuses on the human activities required to achieve participant-goals, using a divide-and-conquer approach to manage complexity. The method starts by exploring unstructured representations of the problem-situation in context, then models relevant “systems of human-activity” that achieve purposes valued by participants. Each human-activity system is compared to work activities in the real world, to identify areas where changes could improve outcomes, improve coordination, or otherwise improve organizational work as a whole. The set of changes is prioritized and implemented, then evaluated – after a suitable time-lag – to determine the effects of change and identify aspects of organizational work that might be explored in the next iteration. This process is shown in Figure 1.

Figure 2. The inquiring/learning cycle of SSM (Checkland, 2000b)

SSM provides a way of engaging in joint learning with stakeholders and participants about the problem-situation. It allows all parties involved to understand the implications of achieving various purposes and involves participants in defining relevant work-activities and exploring what needs to change. Initially, the process of inquiry focuses on the real-world problem-situation, exploring how this works using representations such as Rich Pictures, which impose as little structure on what exists as possible. In this way, we get to appreciate how this world “works” rather than viewing it through the filter of the models we construct. Whatever insights a model may give us, it does not represent the real world. Instead, it represents systems thinking about the real world. Checkland (1979) distinguishes between “above-the-line thinking” (about entities, relationships, and activities performed in the real-world situation) and “below-the-line thinking” (which models the potential/ideal-world sub-systems of human-activity required to achieve each separate purpose of the real-world system). Below-the-line thinking produces the “Relevant models of purposeful activity” shown in Figure 2, above. These are separated out, as shown in Figure 3, so we can model and analyze the activities required to achieve each purpose separately.

Figure 3. Contrast between real-world thinking and systemic thinking about perspectives in the real world

The SSM Analysis Process

The point of all this modeling is to provide ongoing cycles of organizational learning. Employing a systemic analysis means that we involve managers and participants in one functional area in modeling and analyzing the enterprise-wide business processes of which their work is a part. Each person gains a view of what others do in the organization, and an interior perspective of others’ problems and priorities. People start thinking in terms of organizational values and interests, rather than their own fiefdoms. The conventional seven-stage model of SSM is shown in Figure 2. A major criticism of this model — later made by Peter Checkland himself — is that it is too linear to represent the actual process of inquiry that SSM requires. Whilst most SSM analysts would accept that, this model provides a useful starting point for novice analysts.

Figure 2. Seven stages of the SSM formal process (Checkland, 1999)

The stages of SSM modeling are described in the following pages. The idea is to represent the problem-situation in ways that make sense to those involved in working there. The method allows us to separate real-world thinking – representing the various purposes that participants ascribe to their work, what they do to achieve these, and what problems they experience – from systems thinking about the real world – tracing how these purposeful systems of work interact, complementing or conflicting with each other, exploring how outcomes are evaluated and which outcomes are not evaluated, and investigating why/how problems occur in the wider scheme of roles, responsibilities, purposes, and coordination mechanisms.

In the pages that follow, I have included some examples of how to produce and use SSM models and processes, to explain the value of exploring problems systemically.

SSM is based upon the idea that we model systems of purposeful human activity (what people do), rather than data-management or IT components (the more usual focus of systems analysis). It is systemic, rather than systems-focused, calling upon the tradition of general systems theory (von Bertanlaffy, 1968) and inquiring systems (Churchman, 1971) in acknowledging the disparate elements of a situation. SSM is helpful for analysis approaches that wish to understand the connections, conflicts, and discrepancies between elements of a situation rather than attempting to subsume all elements into a single perspective.

Soft Systems Methodology (SSM) was devised by Peter Checkland and elaborated in collaboration with Sue Holwell and Jim Scholes (among others) at Lancaster University in the UK. SSM provides a philosophy and a set of techniques for investigating a “real-world” 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 early system requirements analysis, rather than a systems design approach. This website attempts to explain some of the elements of SSM for educational purposes. It is not intended as a comprehensive source of information about SSM and may well subvert some of Checkland’s original intentions, in an attempt to make the subject accessible to students and other lifelong learners … .

References

Checkland, P. (1999) Systems Thinking, Systems Practice: includes a 30-year retrospective. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98606-2.

Checkland, P. & Scholes, J. (1999) Soft Systems Methodology in Action. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98605-4.

Checkland, P., Holwell, S.E. (1997) Information, Systems and Information Systems. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-95820-4.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners,

Churchman, C.W. (1971) The Design of Inquiring Systems, Basic Concepts of Systems and Organizations, Basic Books, New York.

von Bertanlaffy, L. (1968) General System theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976.

December 6, 2014