The conventional seven-stage model of SSM is shown here. A major criticism of this model -- 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.
In the original SSM approach, the seven stages of the process shown represent sven stages of investigation. This is as good a way to learn SSM as any.
The investigator(s), referred to by Checkland and Scholes (1990) as "would-be improvers of the problem situation" try to understand, in as wide and holistic a sense as possible, the problem situation context and content. This can be done by the use of interviews, observations and workshops where organizational actors describe their work and the problems which they encounter. It is important to see this stage as a prelude to expressing the problem situation: a means of moving to a state of affairs where the situation is understood reasonably well and is capable of being expressed in words and diagrams, thus:
This stage involves the communication and validation of the investigator's ideas about the problem situation. A variety of tools can be used to achieve this; its purpose is to check that the investigator's ideas about the problem situation are shared by a wide range of organizational actors - some additional tools are described at the end of this paper. The main technique which described by Checkland is the drawing of "rich pictures" - unstructured pictures that communicate everything we can think of about the situation which we are analyzing: the main issues, relationships and problems of the organizational context. No drawing skill is required: they normally feature "stick-men" and "stick-women"!
In order to make explicit (visible and open to question) the decision on what to include or exclude, we need to include as much information as possible in order to obtain a "rich" (in the sense of full, complete, wide-ranging) picture of how, and in what environment, our system operates. An example for the traffic warden scheme is attached (figure 3, above) - note that, in order to include all aspects of a situation, you cannot represent everything in great detail, or all of the links between aspects of the situation. Just put in the main links and try to include as many points of view as you can. Then work to a set of slightly more structured diagrams, which you can use to make decisions about system boundaries and system interfaces.
Just drawing these rich pictures makes you (the analyst) think of factors which affect the situation - the more you draw, the more you are stimulated to new ideas by what you have drawn. If you are performing a SSM analysis with a client, ask them to draw pictures. Don't feel that you have to limit the number of pictures - draw as many as you want, to get a full picture of the situation. Peter Checkland suggests that you draw three different pictures, showing different aspects of the situation:
The intervention (analysis process) and your role in it: why are you performing the analysis? for whom? with whom? what does your client want to achieve from the analysis (this is very important: what are the goals of your system?) - this information informs your decisions about what to leave in and what to exclude from your system
The social context: who are the people involved in the situation being analyzed and how do they relate to each other?
The political context: who holds power? over whom? how is power exerted? how is it resisted? is the person "in charge" the person who makes things happen?
These three diagrams are useful if you are analyzing a structured organizational situation. However, don't draw them too early in the process; try to let your rich pictures be as unstructured as possible, to start with, so that you can examine what is not there at present, as well as what is there. Remember that SSM is a facilitative method: try to persuade organizational actors to draw pictures of their part of the organization (a good way to get them started is to draw part of a picture yourself, then ask them to fill in the gaps).
A Root Definition is a definition of the purpose of the system of human-activity. Any definition of purpose embodies some complex concepts, that are stimulated by use of the CATWOE framework described below.
Bear in mind that a system of human-activity never has a single purpose. It is tempting to think that it has, because this is what we attempt to define when we define computer-system requirements. If we are honest with ourselves, even a computer system has multiple purposes. One of the reasons that requirements analysis is so difficult is because we do not understand this and we do not separate out the different purposes, but get them confused in our heads.
This is why I would recommend SSM as a technique for computer system requirements analysis. It does not analyze in detail what the computer system should do, but you sure understand why it should do these things, once you are finished!
There are two steps involved in producing root definitions:
3(a) Clarify what the system is to achieve or change, using input-output transformation diagrams.
3(b) Use the CATWOE framework to produce a Root Definition for each transformation.
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 system (7), in figure 4. The Root Definition for this system is:
A system owned by Local Government Administration, where Local Government Officials make driving less attractive than public transport on behalf of Environmental Lobbyists among the public because the number of cars on the road is directly related to environmental degradation and public health problems, but limited by the need to find alternatives to financial incentives alone and the power of drivers' lobby groups.
The list of activities which I perceive as necessary [see Note 2] for this transformation are:
1. Determine what factors make driving more attractive than public transport
2. Assess what action can be taken to affect those factors by Local Government Officials
3. Take those actions
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.
Figure 4: A WEAK Conceptual Model for System of Input-Output Transformation (7)
Note that this conceptual model 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 it!
OK - so what to do? As a facilitator, I would interview the core stakeholders and understand what they would like to happen, to make public transport more attractive than driving. I would then derive a new conceptual model.
Let us imagine that I have done this and the core stakeholders suggested two main strategies for achieving transformation (7):
The list of activities which the stakeholders perceive as necessary are:
The new conceptual model is shown in Figure 5:
Figure 5: A Better Conceptual Map for System of Input-Output Diagram (7)
An important element of conceptual models are the feedback loops. There are normally two feedback loops in any conceptual model:
To permit the effective management of any system, you need to define a measure of success for a particular transformation. This is shown below the conceptual model in Figure 5.
Note 2: What I perceive as necessary may be totally different to what you perceive as necessary. The latter may be totally different to what a traffic warden perceives as necessary. At the end of the day, it should be up to the local stakeholders to determine what activities are required here - you are just the facilitator, transcribing their understanding of the problem situation into models. If the stakeholders cannot agree, it is not your job to sort this out. Present the conflicts to the managers who own the system and let them decide.
One of the best things about SSM is that you are never allowed to forget that your model does not represent the "real world". So what does your model represent?
Best case:
your model represents a more effective way of achieving the desired work goals, based on how the core stakeholders perceive that the system of human activity should take place.
Worst case:
your model automates what's there now - the manual system, or worse still, the current computer system (if the current computer system is so effective, why do you think they called you in to investigate how it could be replaced?).
Consider how far your model lies between either of these extremes (nobody's perfect). Validate your conceptual models by presenting them to stakeholders and asking for feedback. Once you are happy with them ...
... The purpose of all this activity is not to just draw pretty pictures, but to provide a solid set of prioritized recommendations for what changes need to be made to existing activity systems (which is a prerequisite for defining what information systems are needed to support those changed systems!). Therefore, for example, just taking system transformation (7), we can observe that:
1. Driving is less expensive that public transport. Action = determine the extent of cross-subsidy required and implement it.
2. There is no road rationing system in place. Action = implement a road rationing system.
3. We have no effective way of gathering statistics on road use vs. use of public transport. Action = put information gathering mechanisms in place.
You're probably thinking - OK, I got this far, but how does this relate to computer system requirements? These are just the initial actions for change. Once these mechanisms are in place, we can start to determine a set of detailed requirements for computer support. But unless we understand the details of all this stuff - the multiple purposes that the work-systems (the various human-activity systems represented by each conceptual model) exists to fulfill, the rationale behind these work-systems and the ways in which performance and success are measured, there is no way that we could define requirements for a computer system to support these work activities.
Now let us consider a more functional transformation - we will model transformation 2.
At the end of the day, you will (probably) not be the person implementing the changes that you suggest. Bear in mind that the people involved in the system have to live with these changes and make sure that they are happy with them and consider them appropriate.
There are three elements that need to be considered: Feasibility, Priorities and Risk
In the course of your analysis, you will have come to understand a great deal about how the various activities are performed. Make sure that you write down which changes are feasible and which are not (and why), so that this understanding is communicated to the people who inherit your analysis.
Consider:
Cultural feasibility: what is acceptable to the people working in this part of the organization (from their perspectives).
Technical feasibility: what it is appropriate to support with computer technology and what should be left as a manual process - as well as what it is possible to computerize.
Dependencies between work-systems and between technical systems. Sometimes it is necessary to complete one set of changes before another set can take place.
Win-win: does the change make life easier for people. If you are recommending that people perform six steps instead of three, to accomplish a task, perhaps you should reconsider? If people's lives are made more difficult, they will resist change and probably find ways to sabotage it. It makes sense to define changes that the people involved in the activity system will accept. Perhaps you need to find ways of compromising, so that everyone wins by the changes that you propose.
Prioritizing changes is one of the most important tasks in the whole analysis. One way of prioritizing change is to use a balanced scorecard approach, as demonstrated here:
Assign each system ALTERNATIVE a score out of 10, depending on extent to which it helps the system solution achieve a main goal or solve a main problem.
The changes with the highest scores should take the highest priority for implementation. However, you also need to consider feasibility and risk, when determining priorities. (You could make the table bigger, to assign each change a score for feasibility and a score for risk).
** Highest scores indicate risks/benefits that need managing carefully
* Starred activities require an evolutionary or experimental prototyping approach
At the end of the day, you will (probably) not be the person implementing the changes that you suggest. Bear in mind that the people involved in the system have to live with these changes and make sure that they are happy with them and consider them appropriate.
When implementing change, consider two cardinal rules of change management:
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 teaching 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 ... 
.
All contents of this site are copyright © Susan Gasson, 2005-2013
The contents of this website may not be sold, incorporated in other online materials, or used in any form without the express consent of the copyright holder.
Permission to use will normally be given to bona fide educational use - please contact Susan Gasson directly.
