Soft Systems Methodology

A report by
Dale Couprie
Alan Goodbrand
Bin Li
David Zhu
Department of Computer Science
University of Calgary
Table of Contents.
Abstract.
Introduction
Map
Stage 1. Problem situation unstructured.
Stage 2. Problem Situation expressed.
Rich Pictures
Illustration of Stage 1 and Stage 2 as a whole in SSM
Pitfalls that must be avoided.
Stage 3: Naming of Relevant Systems
Root Definitions
CATWOE
Stage 4: Conceptual Models
Systems Thinking
Formal Systems Model
Monitoring a System
Stage 5: Comparing Conceptual Models with Reality
Using Conceptual Models as a Base for Ordered Questioning
Comparing History with Model Prediction
General Overall Comparison
Model Overlay
Stages 6 and 7. Implementing Feasible and Desirable Changes
Case Study - Rethinking a Service Function in the Shell Group
Stages 1 and 2
Stage 3: Naming of Relevant Systems
Stage 4: Conceptual Models
Stage 5: Comparing Conceptual Models with Reality
Stages 6 and 7. Implementing Feasible and Desirable Changes
Observations and Conclusions
Exercise
References

Figures.
Figure 1. Soft Systems Methodology map.
Figure 2. Transformation process for producing Rich Picture.
Figure 3. The routing of Systems Thinking.
Figure 4. Shell's MF Rich Picture.
Figure 5. Shell's MF world view of training.
Figure 6. Shell's MF training conceptual model.

Tables.
Table 1. One to one transformations involving different world views.
Table 2. Shell's Comparison with reality.

Abstract
This document deals with Soft Systems Methodology as developed by Professor Peter Checkland. This
methodology is a way of dealing with problem situations in which there is a high social, political and human
activity component. This distinguishes SSM from other methodologies which deal with HARD problems
which are more technologically oriented.

Introduction
Hard problems are problems characterized by the fact that they can be well defined. You assume that there is
a definite solution and you can define a number of specific goals that must be accomplished. In essence, with
a hard problem you can define what success will look like prior to embarking on implementing the solution.
The "WHAT" and the "HOW" of a hard problem can be determined early on in the methodology.

Soft problems, on the other hand, are difficult to define. They will have a large social and political
component. When we think of soft problems, we don't think of problems but of problem situations. We
know that things are not working the way we want them to and we want to find out why and see if there is
anything we can do about it. It is the classic situation of it not being a "problem" but an "opportunity".

Soft Systems methodology was developed by Peter Checkland for the express purpose of dealing with
problems of this type. He had been in industry for a number of years and had been working with a number of
hard system methodologies. He saw how these were inadequate for the purpose of dealing with extremely
complex problems which had a large social component so in the 1960’s he turned to the University of
Lancaster, in the UK, in an attempt to research this area and deal with these SOFT problems. His "Soft
Systems Methodology" was created through a number of research projects in industry and its application and
refinement over a number of years. The methodology, which is pretty much how we know it today, was
published in 1981 and by that time he was firmly entrenched in University life and had left industry to pursue
a career as a professor and researcher in Software Engineering.

SSM is divided into seven distinct stages. These are;

1. Finding out about the problem situation. This is basic research into the problem area. Who are the key
players? How does the process work now? etc.
2. Expressing the problem situation through Rich Pictures. As with any type of diagram, more
knowledge can be communicated visually. A picture is worth a 1000 words.
3. Selecting how to view the situation and producing root definitions. From what different perspectives
can we look at this problem situation.
4. Building conceptual models of what the system must do for each root definitions. You have basic
"Whats" from the root definitions. Now begin to define "Hows".
5. Comparison of the conceptual models with the real world. Compare the results from steps 4 and 2 and
see where they differ and are similar.
6. Identify feasible and desirable changes. Are there ways of improving the situation.
7. Recommendations for taking action to improve the problem situation. How would you implement the
changes from step 6.

Figure 1. Soft Systems Methodology map.

This is an iterative approach. Sometimes several iterations of these seven steps are required to produce good
results.
The remainder of this document will present the details of each of the seven stages. Following this will be
the details of a specific case study which Checkland took part in with the Shell Group in the UK. This case
study involves a major rethinking of one of Shell's Manufacturing Functions and took place in the late
1980’s. Checkland, himself, refers to this project as a mature use of Soft Systems Methodology.

Back to Top.

Stage 1: Problem situation unstructured

The initial stage consists simply of managers and/or employees (problem owner) deciding that a review or
change of tasks and the way they are performed is required, and an analyst (problem solver) was called in.
People of the organization think there might be a problem or room for improvement, and initiates the analysis
or review. Soft system methodology thinks the term 'the problem' as inappropriate because it might narrow
the view of the situation. Soft system believes that 'the problem situation' is more appropriate since there
might be many problems which are perceived need to be solved.

Stage 2: Problem situation expressed

Stage 1 is basically that people of the organization think there might be a problem or room for improvement,
and initiates the analysis or review. In stage 2, the analyst collects and sorts information and provides some
description of the problem situation. Following are the information we are looking for [2] :

the structure of the organization: those factors that do not change easily (e.g. buildings, locations,
environment);
processes or transformations which are carried out within the system: many of these are changing
constantly;
issues that are expressed or felt by organizational members (complaints, criticisms, suggestions,
endorsements).

There are many strategies analysts can employ when collecting facts, ranging from very informal,
unstructured approaches to very formal, structured tools employed in traditional systems analysis. Some of
the techniques are:

Work observation:
identify tasks performed
identify tools employed
establish interactions between people/systems
produce logs
"day-in-the-life-of" descriptions
make drawings of structures/layouts
video recordings
collect samples of tools used to handle information
perform participant observation

Interviews:
unstructured, informal ("tell me what you do")
semi-structured (questionnaire with open-ended answers)
highly structured (questionnaire with boxes to tick)
critical incidents
audio recording

Workshops and discussion:

future workshops
review workshops
conflict resolutions workshops
mock-ups, simulations, mind-games

The stage 1 and stage 2 are an 'expression' phase during which an attempt is made to built the richest possible
picture, not of 'the problem' but of the situation in which there is perceived to be a problem [1]. It is very
important not to narrow our scope of investigation down too early. If we select a very structured approach
such as a multiple-choice questionnaire at the beginning of our study, and build a model on the basis of those
results only, we probably exclude a lot of information which could be relevant. As a general strategy,
therefore, it is better to employ a selection of not too structured techniques at the beginning, and employ more
structured techniques after a first impression of the problem has been defined for the purpose of eliciting
detailed information or checking assumptions. Specific techniques should always be selected to fit in with
work of the organization, and everyone who is providing information should be informed about what the
purpose of the analysis is.

When an analyst elicits information from the members of an organization, she or he communicates with them
using natural language (English). This poses a number of problems and potential pitfalls. The analyst should
be prepared to accept that at this stage, the information elicited will be incomplete, and contain contradictions
and ambiguities. The system which we are looking at is a soft system, and therefore the information about the
system is likely to be qualitative rather than quantitative.

Back to Top. Back to Map.

Rich Pictures

Rich pictures are used to provide a model for thinking about the system and to help the analyst to gain an
appreciation of the problem situation. It is important to note the difference between rich picture and formal
models. The rich picture does not attempt to model the system in any precise way. It provides a
representation of how we can look at and think about the system . It can be refined as our understanding of
the system becomes clearer, and what we want becomes clearer. The rich picture shown in Figure 4 is based
on the case studies on Shell's "Rethinking a service function in the Shell group". The circle represents the
boundary of the system, with those small circles which are components of the system, while those outside are
the external entities with which the system interacts. The thought bubbles represent the current thinking of
the people in that service group. They want to know good is their organization and how to evaluate their
current performance because they want make it better.

Rich pictures are artistic and individualistic expressions, and therefore not "right" or "wrong". However,
Rich Pictures should represent structure, processes and issues of the organization which could be relevant to
the problem definition, and try to give an impression of the organizational climate. Each analyst or team will
develop their own style of Rich Picture. You can start with people or locations. You can put objects, items or
issues or bits of paper and try to group them, or fit them in the structure. A Rich Picture is not a system model
or system map (which is generated at later stages), nor should be an organigram (the sort of management
hierarchy maps which organizations often use to describe themselves).

Issues elicited can be indexed or grouped according to a themes or causes. With large-scale studies,
computer-based tools such as a database or hypertext system can be used to store and manage the information
elicited.

The following analysis need to be performed on a rich picture for problem situation expressed:

Roles of intervention analysis, is an analysis which deliberately identifies the issues that people
involved in the situation think are problematical.
Social analysis, identifies the roles people fill in the organization, the norms of behavior those people
display and the values by which their behavior is judged.
Power analysis, is concerned with such issues as 'What are the commodities of power in this situation',
'How is the commodity obtained', and 'How is the commodity passed on'

Back to Top. Back to Map.

Illustration of Stage 1 and Stage 2 as a whole in SSM

A transformation diagram was produced to illustrate the first stage 1 and stage 2 in SSM as shown in Figure
2:
 Figure 2: Transformation process for producing Rich Picture.

The problem owner's help is the input of the process. The problem solver will perform analysis on the soft
system and end up with a rich picture as output of this transformation process. The analyst will use the rich
picture to aid their communication with the problem owner. In addition, he or she will notify the conflict he
observer on personnel or function. The rich picture is used to identify problems and inform the problem
owner of the situation rather than provide possible solution.

Back to Top. Back to Map.

Pitfalls that need to be avoided

The following pitfalls need to be avoid during the initial stage of SSM:

Do not narrow the scope of investigation down to early.

Assembling richest picture without imposing a particular structure and solution on problem situation.
People have difficult to interpret the world in the loose way, and often show an over-urgent desire for
action.
Not to press the analysis in systems terms at all.
Should realize that there will be many possible versions of the system.
Back to Top. Back to Map.

Stage 3: Naming Of Relevant Systems.

Root definitions.

It is necessary to pay close attention to the formulation of names of relevant systems, and to write them in
way such that a model could be built based on these names. These names are known as Root Definitions.
The purpose of the root definition is to express the core purpose of some purposeful activity system [3]. It is
important that attention is paid into the development of root definitions. Properly written root definitions
provide a much simpler insight into building system models.

A root definition is expressed as a transformation process that takes some entity as input, changes or
transforms that entity, and produces a new form of the entity as output. A prescription for developing
transformation processes is shown in the following table, which shows examples of transformations which
are typical of a golf course operation. As you may notice, these transformations will vary greatly, depending
on the world view that is applied.
 AS VIEWED FROM THE
INPUT OUTPUT
EYES OF:
Unused land Land occupied by golf course. Architect.
Need for tee
Need for tee times is met. Club Management.
times.
New golf balls. Used, scuffed up golf balls. Equipment industry.
Grass seed Mature grass. Greenskeepers
Uncooked food. Quality meals. Kitchen cook.
Golfer who completed round in X
Registered golfer. Pro shop staff.
strokes.
Golf lesson
Enhanced lesson program. Club Professional.
program.
Table 1. One to one transformations involving different world views.

Producing a root definition is a two step process.

1. An issue or task is chosen from a rich picture
2. A system is defined to carry out the task or address the issue.
Each root definition involves two important things. The first is that we must involve a certain view of the
world. Definition of the world view is not always trivial. Also, not all world views may be desirable to the
definer. Remember that each rich picture will involve a variety of world views. The eyes may come from
sources such as government officials, company executive, project managers, employees, customers,
competitors, and news media. Each of these world views will be linked to one or more distinct root
definitions.

It is important to pay attention to the cardinality of the transformation process. Each root definition involves
a transformation of one input to one output [3]. Suppose we define a transformation as "golf equipment" plus
"golf course" plus "manpower" (three inputs) yields "golf needs met" plus "golf market served" (two
outputs). This "three to two" transformation is ambiguous, but can be resolved into many one to one
transformations that look much clearer (golf equipment is transformed into used golf equipment).

Back to Top. Back to Map.

CATWOE

Root definitions are written as sentences that elaborate a transformation. There are six elements that make up
a well formulated root definition, which are summed up in the mnemonic CATWOE.

Customer: everyone who stands to gain benefits from a system is considered as a customer of the
system. If the system involves sacrifices such as lay offs, then those victims must also be counted as
customers.
Actor: The actors perform the activities defined in the system.
Transformation process: This is shown as the conversion of input to output.
Weltanschauung: The German expression for world view. This world view makes the transformation
process meaningful in context.
Owner: Every system has some proprietor, who has the power to start up and shut down the system.
Environmental constraints: External elements exist outside the system which it takes as given. These
constraints include organizational policies as well as legal and ethical matters.
CATWOE is mainly used for the purpose of analysing the analysis of root definition sentences, but may be
used as a building block for to derive the root definition sentence if we know the CATWOE elements.

We use CATWOE as the backbone for developing root definitions because the use of the transformation
itself as a root definition makes it difficult to model. The transformation and world view make the core of
CATWOE. The two meld together. Every activity can be expressed in many ways, using different world
views. It is a good idea that different world views are used to develop different root definitions. CATWOE
also recognizes the need to account for ownership, performance, beneficiaries, victims and external
constraints, which are important things to account for in documenting the system.

Back to Top. Back to Map.

Stage 4: Conceptual Models.
Given a root definition of a system, a conceptual model can be drawn. A conceptual model is a human
activity model that strictly conforms to the root definition using the minimum set of activities. Systems
thinking is applied in this development.

Systems Thinking

Figure 3. The routing of Systems Thinking.

Figure 3 shows that systems thinking is an iterative process that combines three concepts. [3]

The Perceived world: Each one of us has our own views of the world.
Ideas: We perceive the world through the framework of ideas that are internal to us.
Methodology: There are many of these for thinking about the world, of which SSM is one..

Formal Systems Model

Formal Systems Thinking is applied to the development of the conceptual model. The Formal System Model
serves as a guideline for checking the conceptual model we draw. Let S represent a human activity system.
Under the Formal System model [4], S is a formal system if and only if it meets the following criteria:

S must have some mission.

S must have a measure of performance.
S must have a decision making process
S must have components which interact with each other such that the effects and actions are
transmitted through the system.
S must be part of a wider system with which it interacts.
S must be bounded from the wider system, based on the area where its decision making process has
power to enforce an action.
S must have resources at the disposal of its decision making process.
S must either have long term stability, or the ability to recover in event of a disturbance.
Components of S must be systems having all the properties of S (subsystems).

The conceptual model can be written as a directed graph, similar to a PERT chart. Nodes in the graph are
activities to be done. These activities are based on the verbs in the root definition. Structuring of the system
is based on the logical dependency. The logical dependencies are shown as arcs in the graph. An arc in the
graph means that the source activity is a prerequisite for the destination activity.

The conceptual model for a system consists of an operational system which is covered by - but bounded from
- a monitoring process. This operational system consists of a core activity and whatever pre-requisite
activities are required such that the core activity can be done. Cognitive psychology suggests the human
brain can cope with 7 +/- 2 concepts at the same time. Therefore, we should aim to have 7 +/- 2 activities
within each operational system. If this guideline leads to activities that are too high a level, those activities
can be expanded to another level. Simply put, each general activity becomes a source for a root definition to
be expanded at the next level.

Back to Top. Back to Map.

Monitoring a System.
Monitoring the operational system consists of three activities [3]:

Define a measure of performance: We can use any or all of the three E's for measurement of the
operational system
Efficacy - does it work
Efficiency - How much of work completed given consumed resources
Effectiveness - Are goals being met.
Monitor the activities in the operational system, in accordance with the metrics defined in step 1.
Take control action: Use the outcomes of these metrics to determine and execute action to control the
operational system.

However the three E's shown above are not the only metrics that can be used. Many firms will use metrics
including economical, ethical, elegant, and other metrics which may be dependent on the context of the work
being done.

Back to Top. Back to Map.

Stage 5: Comparing Conceptual Models with Reality

This is the stage back to the real world, thinking above the dotted line. At this stage, conceptual models built
at stage 4 will be compared with real world expression at stage 2. The work at this stage may lead to the
reiteration of stage 3 and stage 4. Previous experience of using SSM indicated that the comparison at this
stage is not in fact a proper comparison of like with like. This will be discussed more later. Based on the
rationale of this methodology, there are four ways of doing comparison from number of experiences.

Before comparison is carried out, several other aspects need to be mentioned. The first question is what is the
end of stage 4. When should be the time to stop building conceptual model and move on the real world
comparison. The temptation is always to indulge in prolonged and elaborate model building. It is fun to work
on the modelling and it is not comfortable to bring the model to the reality and engage with the difficulties of
the problem situations. In fact, from Checkland’s experience, it is better to move quickly to the comparison
stage. It is allowed to refine the model subsequently when it has to go back to the conceptualization stage
again.

Before we summarize stage 5 of SSM, we need to understand definition of Comparison. Generally,

comparison is an important part of rational, serious thinking which contains perceiving, predicting and
comparing. In SSM, Check land defines comparison as the point that intuitive perceptions of the problem are
brought together with the systems constructs which the systems thinker asserts provide epistemologically
deeper and more general account of the reality beneath surface appearances; it is the comparison stage which
embodies the basic systems hypothesis that systems concepts provide a means of testing out the complexity
of 'reality'.

Four ways of doing comparison can be summarized as follows:

1. Using Conceptual Models as a Base for Ordered Questioning

This is a type of comparison which can be done when the real world situation is very different from
conceptual model. The system models are used to open up debate about change. The model is used as a
source of questions to ask of the existing situation. The questions are written down and answered
systematically. The answers to the questions can provide illumination of the perceived problem.

2. Comparing History with Model Prediction

Another method of comparison is done by reconstructing a sequence of events in the past and comparing
what had happened in producing it with what would have happened if he relevant conceptual model has
actually been implemented. In this way, the meaning of the models can be exhibited and satisfactory of
comparison can be reached. Based in Checkland’s experience, this is a method used successfully for a
consultant who wanted to know why one of his studies for a client had been a spectacular failure. In that case,
the whole content of the study was history, and the analysis compared the story as remembered and recorded
at the time by participants, with a system model of consultant/client interaction. Checkland also warned that
this method of comparison should be used carefully so that it may reveal the inadequacies of the actual
procedure and it can be interpreted as offensive recrimination concerning their past performance.

3. General Overall Comparison

Checkland suggested that in the illustration of the methodology as a whole, it is usually appropriate to
comparison of stage 5 a general one, asking what features of the conceptual models are especially different
from present reality and why. This comparison is also generally discussed with "Whats" and "Hows" by
Checkland. It is the distinction between 'whats' and 'hows' which makes the word 'comparison' a somewhat
crude description of what is happening in stage 5. Checkland points out that at stage 5, we have available
systems models which themselves derive from the careful naming, in root definitions, of human activity
systems which we hope are relevant to the problem situation and to its improvement. In stage 5, we examine
the models alongside the expression of the problem situation assembled in stage 2. The comparison between
the two is the formal structure of a discussion about possible changes, a discussion held with concerned
people in the problem situation. In order that the discussion shall be rich and wide-ranging, we wish to
question whether various activities in the models discernible in the real world, as well as - if they are present
- how well they are being done. We also wish to discuss possible alternatives to the real world activities. We
will see how this comparison will be carried out in a case study illustrated later. Here wide-ranging
comparison other than like with like is emphasized and now we can see why stage 5 is not a straightforward
comparison.

4. Model Overlay

The fourth method of doing stage 5 is referred as "model overlay" by Checkland. For the comparison, after
completing conceptualization based on the chosen root definition, we made a second model from what exists.
The second model has as near as possible the same form as the conceptual model, the aim being to re-draw
that model, changing it only where the reality differed from the conceptual model. With this method, direct
overlay of one model on the other then revealed the mismatch which is the source of discussion of change.
With this method, such questions as what root definition is implied by this system? How does it compare
with the one which was the basis of conceptualization in stage 4?

All four methods can help ensure the comparison in stage 5 is conscious, coherent and defensible. Depending
on the perceived problems, particular method can be used to do the comparison, or all kinds of comparison
can be carried out with all these four methods. For the existing system, the comparison can be done with what
exists, but for a new system, the comparison cannot be with what exists, only with some redefined
expectation. In this case, the previous experience implied that incrementalism and trial and error are the best
approach.

Back to Top. Back to Map.

Stages 6 and 7: Implementing 'Feasible and Desirable' Changes

In stage 6, feasible and desirable changes are identified and discussed, and they will be put in action in stage
7. The purpose of the comparison stage is to generate debate about possible changes which might be made
within the perceived problem situation. This can be seen clearly with the second method of doing comparison
as discussed above.

The outcome of stage 6 and 7 for both hard and soft system is the creation and implementation of a system.
Generally, in these more nebulous problem situations, the eventual action is likely to be less than the
implementation of a system, it is more likely to to be the introduction of a more modest change.

Normally, there are three kinds of changes:

changes in structure, which is changes made to those parts of reality which in the short term, in the
on-going run of things, do not change.
changes in procedure, which is the changes to the dynamic elements
changes in attitude, which is behaviour appropriate to various roles, as well as changes in the readiness
to rate certain kinds of behaviour 'good' or 'bad' relative to others.
Changes in structure and procedure are easy to specify and relatively easy to implement. At least, these can
be done by the people who have authority or influence. It is relatively difficult to change attitude. It is
possible in principle to try to bring about changes of this kind. Whether or not this is attempted, the main
essential is continuously to monitor attitude if changes are to be made in situations perceived as problems so
that concerned people in the situation agree that improvement has been achieved. One of the important
features in SSM is it emphasis on change.

Another important feature of SSM is that it is goal-driven, it focuses on a desirable system and how to reach
it. Checkland indicated that the changes must be systemically desirable as result of the insight gained from
selection of root definitions and conceptual model building, and they must also be culturally feasible given
the characteristics of the situation, the people in it, their shared experiences and their prejudices. It is hard to
find any changes which do not meet both criteria. Checkland found out from one of his case studies that it is
important to move quickly and lightly through all the methodological stages, several times if necessary, in
order to engineer a bridgeable gap between 'what is' and 'what might be'. He also suggested that we may have
to incorporate 'root constrains' in order to compromise a situation which proposed changes have to be
changed due to the power influence.

The job at stage 7 is to implement changes and put them into action. When action is taken, it might be a
straightforward one. However, other situations may be encountered. The introduction of the action may
change the situation so that although the originally perceived problem has been eliminated, new problem
emerge. Often it is recommended that a temporary system be used to carry out the task under the supervision
of the analyst, followed by a transition to the operation of the new system. Checkland pointed out that this
methodology has in fact not emerged as a once-and-for-all approach to something sharply defined as a
problem, but perceived as a problem.

Back to Top. Back to Map.

Case Study - Rethinking a Service Function in the Shell Group

This case study was conducted by Checkland and was organized together with Shell management. This is
also the case study our group used to illustrate examples of using SSM at each individual stage. [3]

Stages 1 and 2.

A service group in Shell, manufacturing function (MF), it provides a lot of service for the other group in
Shell to help them to make decision for the future development. The MF has been running for a long time,
and the people think it is about the time for them to rethink their role in Shell and how to make their
performance better. Thus, the problem situation for them will be how good is our current system be
organized and how to evaluate our system performance? Can we do better? A rich picture was produced for
this problem situation in Figure 4.

Figure 4. Shell's MF Rich Picture.

Back to Top. Back to Map.

STAGE 3: Naming Of Relevant Systems.

Shell is a changing company and this change requires constant training of employees. The models discussed
in the discussion of Stages 3 and 4 were prepared for General Workshop II and are based on the following
training concept.

Figure 5. Shell's MF world view of training.

From the eyes of the company executive, two needs are seen: a need for trained personnel with
manufacturing expertise as well as having this expertise in other functions. The best way to meet the need
was to inject trainees into the normal workflow, training them through real life situations. They come out
well trained and can be hired in other functions.

A root definition for a system for training in accordance with this concept is as follows:

An MF owned and staffed system which, in response to a continuous need for higher quality personnel
for servicing and managing the manufacturing operations of the Shell Group, and a need for
manufacturing expertise in other functions, develops and trains people and provides experience in a
cost effective manner, within constraints imposed by MF’s carrying out its core tasks as service
provider and technology.

The CATWOE analysis for this root definition is as follows:

C: Those trained; through them, the Company
A: MF Personnel
T: The need for trained experienced people is tranformed to a fulfilled need.
W: Training can emerge from careful planning of MF work with a view to providing suitable
experience.
O: MF
E: MF core tasks
Note how the world view of this transformation enforces training through hands on experience.

Back to Top. Back to Map.

Stage 4: Conceptual Models.

From the root definition comes this conceptual model.

 Figure 6. Shell's MF training conceptual model.

This model consists of an operational model which is monitored at two different levels. The core activity of
this operational system is task 6 (Assign MF personnel to tasks). However to be able to do this task
effectively requires a lot of understanding, which is covered in tasks 1 to 5. We need to know about Shell's
changing environment and MF's ongoing task requirements. These requirements fill a need for expertise in
MF and other functions. We also need to know the experience of existing and new MF personnel. Once
those requirements are filled, task assignment is completed. The task assignment also has an output, which is
a list of skills and experience received by MF personnel as a result of doing assigned tasks. These must be
logged and appreciated in future task assignments.

Two levels of monitoring are taken in this model, but note how this process follows the guidelines of
"metrics, monitoring, and control action". The operational system is monitored by the MF group, and they
are using efficacy and efficiency as their measures of performance. The second level of monitoring is done at
a managment level, whose performance measurement is cost effectiveness.

Back to Top. Back to Map.

Stage 5: Comparing Conceptual Models with Reality

For a investigation of how stage 5 was used, we go to general workshop I. This workshop was to discuss
technology development in Manufacturing Function (MF) of Shell Group. The root definition is stated as "A
MF owned staffed system which manages fluid relationships between those involved in MF tasks in order to
achieve a flexible non-fragmented organization which makes an impact on Shell business". CATWOE was
used to draw this root definition and a conceptual model was built for this issue based root definition. After
the conceptual model was built, a special format was used to carry out comparison. This format is shown
below. By comparing the activities in the model and the existing activities, the model was evaluated and
alternatives were suggested.

Activity in
Exist? How? Who? Good/Bad Alternatives?
Model
Discussion and MF
Accumulate
Yes management management, Good Contractor
skill reservoir
action Shell
 Corporation's
personnel
MF/Shell Co.
Determine
discussion MF and Shell Good in
nature of Yes No alternative
variously Co. people general
action needed
formal-informal
Special
Decide scope exercise, task
and depth of Not force, data
Bad
skill formally base
accumulation regularity
updated
Table 2. Shell's Comparison with reality.

Stage 6 and 7: Implementing 'Feasible and Desirable' Changes

In this case study, after comparing models, desirable and feasible changes had been identified. They are:
1. Maintaining and updating a reservoir of 'know-how'
2. Developing relevant R&D objectives and programs
3. Creating business options on the basis of new or improved technology
Back to Top. Back to Map.

Observations and Conclusions

Peter Checkland states in his book "Systems Thinking, Systems Practice", "The complexity of the universe is
beyond expression in any possible notation". [5] Soft systems Methodology is an attempt to apply science to
human activity systems. By the very nature of these systems, Checkland admits that any methodology will
be inadequate, but that doesn't mean that it's useless. By examining the Human Activity systems in this
manner, we can draw some vital knowledge about interaction and perception. This knowledge will help us in
understanding and improving these systems.

It was stated in the beginning that SSM was an iterative approach. Checkland states that the current
methodology has evolved after about 50 uses [5] so obviously not only is the use of the methodology iterative
but also is it's growth. This is due to the nature of the types of problem situations it is meant to deal with; ill
structured and poorly defined problems with a large social component. The main advantage of the
methodology is that it gives structure to these types or problem situation which can allow them to be dealt
with in an organized manner. It forces the developer to look for a solution that is more than technical.

Several people are currently conducting research into ways of overcoming the problems inherent with SSM.
There is research ongoing at the University of Ulster dealing with the enhancement of SSM through Formal
Methods and Risk Analysis techniques. A more practical approach is to use SSM to generate HARD
questions which can then be dealt with by the, more traditional, HARD methodologies.

Back to Top. Back to Map.

Exercise for SSM

Objective: This exercise is designed to help you to have a good understanding of what is SSM and how to
use it in practice.

Remember: There is no 'right' or 'wrong' answer for this exercise, what you need to present is your thinking
about the problem situation and a relevant system model for your thinking. There are five requirements for
this exercise, do as much as you can within 20 minutes. If you need hints for these questions, please refer the
appendix.

Problem situation:

A local Calgary choral society always has the difficulty in obtaining nominations for its officers and
committee and attracting people to participation in choral related works. As it is a performing society a
number of non-choral tasks must be managed. How could this difficulty be addressed and examined?
Requirement 1: Use a rich picture to address the "Problem Situation Expressed" stage in SSM for this
problem situation.
Requirement 2: Define a "Root Definition" for this problem situation.
Requirement 3: Do a CATWOE analysis on your Root Definition.
Requirement 4: Produce a "Conceptual Model" based on your Root Definition. (activities such as identify
needs of local community, attract membership, general funds, attract audiences could be used for this
problem situation)
Requirement 5: Use the "Tabular Display" comparison method to perform the comparison between the
real world and intellectual world.

Results for Adi Damian, Danfeng Hong, Quan Li and Dong Pan.
Results for Qian Wang, Kim Johnson, Jasper Fai, and Sheng Ouyang
Results for Daniela Herlea, Stephen Lam, and Micheal Wu

Back to Top. Back to Map.

References:
[1].Wilson, Brian (1990), System: Concept, methodologies and applications. John Wiley, New York

[2]. http://www.is.curtin.edu.au/venable/isdl/prototype/chp4-.htm

[3] Checkland, Peter and Jim Scholes (1990). Soft Systems Methodology in Action. Toronto, John Wiley
and Sons.

[4] Macaulay, Linda A (1996). Requirements Engineering. London. Springer.

[5] Checkland, Peter (1981). Systems Thinking, Systems Practice. London, John Wiley & Sons.

Dale Couprie - Alan Goodbrand - Bin Li - David Zhu