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. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Soft Systems Methodology map. Transformation process for producing Rich Picture. The routing of Systems Thinking. Shell's MF Rich Picture. Shell's MF world view of training. 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.

INPUT Unused land Need for tee times. New golf balls. Grass seed Uncooked food. Registered golfer. Golf lesson program.

OUTPUT Land occupied by golf course. Need for tee times is met. Used, scuffed up golf balls. Mature grass. Quality meals.

AS VIEWED FROM THE EYES OF: Architect. Club Management. Equipment industry. Greenskeepers Kitchen cook.

Golfer who completed round in X Pro shop staff. strokes. Enhanced lesson program. Club Professional.

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 Model

Exist?

How? Discussion and management action

Who?

Good/Bad Alternatives? Contractor

Accumulate Yes skill reservoir

MF management, Good Shell

Corporation's personnel Determine Yes nature of action needed Decide scope and depth of Not formally skill accumulation MF/Shell Co. MF and Shell Good in discussion Co. people general variously formal-informal No alternative Special exercise, task force, data base regularity updated

Bad

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