The Soft Systems Method (SSM) is based on Systems Theory, whose fundamental concepts have been introduced in Chapter 3. In his book Systems Thinking, Systems Practice (1981), Peter Checkland introduced the distinction between soft and hard systems. As a production engineer, Checkland had been involved in a number of projects to introduce new technology in the manufacturing sector. Even though much care was given to design robust and efficient technology, problems would often occur on introduction, which led to breakdown of the system and halt of production. Checkland observed that this was often due to problems which the operators had with the technology. The design of the system assumed operators functioned like hardware components. Checkland proposed that work organisation should be seen as consisting of a technology system (hard) and a Human Activity (soft) system. The methods used for engineering the technology should not be applied to the human side of the system. In order to analyse and describe the relevant aspects of the Human Activity System, and how it interacts with the technology system, a different approach was needed. Chekland developed the Soft Systems Method (SSM) to deal with this task.
When applying SSM, we look at organisations as a system in which people perform actions. These actions need to be interpreted (understood) by the analyst before designing technology which effectively supports the overall system. SSM provides the analyst with a framework for collecting and interpreting information about the overall system, and the issues and constraints of the Human Activity System. Once we have completed this process, we can define the overall system, its boundaries, the tasks performed by technology and by people, and how they interact. We can then proceed to apply more structured, formal techniques to design the technical part of the information system.
Figure 4.1: The 7 Stages of SSM
Figure 4.1 shows the 7 stages of the SSM, which are not strictly sequential - it is often necessary to correct or add to the output of previous stages. The first important thing to notice is the division between real-world and systems word stages. This reflects a conscious division between stages in which analysts firmly focuses on the existing system of the client organisation, and stages in which they develop an idealised model of how the system should be. During the first two stages, analysts collect information required to identify and model relevant systems in the client organisation, and current problems. Managers and employees of the organisation are involved in those stages and share responsibility for the completeness and accuracy of the description drawn up by the analyst. Managers and employees sometimes hold different views about purpose, goals or effectiveness of certain tasks or subsystems. These different views can be represented in SSM, and often hold the key to existing problems in an organisation. SSM does not necessarily result in fundamental changes of working practices or implementation of a major information system - the action to be taken depends on what is deemed desirable and feasible within the organisation. SSM provides a model of the organisation, its tasks and how it performs them, which the analyst can use as a framework for the specification of an information system. Other tools will have to be used to specify individual parts of the system.
Figure 4.2: How SSM works
The initial stage consists simply of managers and/or employees deciding that a review or change of tasks and the way they are performed is required, and calling in an analyst.
Stage 1 is basically that one member of the organisation thinks 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 the problem situation. So what sort of information are we looking for, and how do we go about collecting it?
We are trying to identify:
 | the structure of the organisation: 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 organisational members (complaints, criticisms, suggestions, endorsements). |
There is a wide range of strategies analysts can employ when collecting facts, ranging from very informal, unstructured approaches (just watching people performing their work, chatting to them about what they do) to very formal, structured tools employed in traditional systems analysis (time and measurement studies). Since factfinding in SSM is all about collecting facts which will form the basis of our definition of "what the problem is", it is very important not to narrow our scope of investigation down too early. If we select a very structured approach (say, 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 (to elicit detailed information or check assumptions). Specific techniques should always be selected to fit in with work of the organisation, and everyone who is providing information should be informed about what the purpose of the analysis is.
Some 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 |
Figure 4.3: Place the various factfinding techniques along the continuum
When an analyst elicits information from the members of an organisation, she or he communicates with them using natural language (English). This poses a number of problems and potential pitfalls, which are discussed in detail in Chapter 5. The analyst should be prepared to accept that at this stage, the information elicited will be incomplete, and contain contradictions and ambiguitities. 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.
Producing "Rich Pictures"
The purpose of a Rich Picture is to help the analyst to gain an appreciation of the problem situation. They are artistic and individualistic expressions, and therefore not "right" or "wrong". (They can, of course, contain inaccurate or misleading representations, and communicate the problem situation clearly or not very clearly.) Rich Pictures should represent structure, processes and issues of the organisation which could be relevant to the problem definition, and try to give an impression of the organisational 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 organisations 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.
Once we have collected a set of information to work with, we move from the Real World into the Systems World. We start by naming the systems which we have identified, then write Root Definitions for each of those systems, and then develop a Conceptual Model of the overall system. The modelling states are the most difficult stages of SSM. It is always necessary to go through the loop of root definitions and modelling several times - you never, ever, get a conceptual model right first time you try to draw it.. These are also the most important stages: stand back from the situation and individual facts, and try to see what is behind all those facts observed - what makes the organisation tick, or what stops it from ticking properly? This part of the analysis is best performed by a team of analysts - it helps to identify missing information, additional questions which need to be asked, hidden assumptions made by one analyst, etc. If different analysts performed factfinding in different parts of the organisation, they can play the role of actors which they interviewed to convey the viewpoint of that part of the organisation to the other analysts.
Root Definitions
A Root definition is the first stage of formalising ideas about a Human Activity System. There are four different systems which can be described by a root definition: primary and issue-based systems, and service and non-service systems.
Primary task: Neutral account of what is necessary for the organisation to fulfill its primary role
Many organisations are set up explicitly to carry out a stated task (getting a certain product out of the door, providing a certain type of service).. A primary-task approach is concerned with trying to create systems relevant to exploring this aspect of the situation. It might be possible to create a primary-task systems definition from a mission statement, charter or official description of the organisation's activity. Another approach is to seek agreement amongst the problem owners as to what the primary-task root definition is.
Issue-based: Reflecting particular points of view - what is the role of the organisation, and its processes?
This means that several Root Definitions will be written, and acknowledges that there are conflicts and problems between (for instance) actors, owners and clients of a system. Issue based Root definitions are likely to focus on particular parts or aspects of the system rather than being comprehensive.
Service vs. non-service systems: This acknowledges that a system which serves another system cannot be defined and modelled until a definition and model of the system served are available.
Figure 4.4 Four types of Root definitions
The CATWOE components are: Clients, Actors, Transformations, Worldview, Owner, Environment. CATWOE is a good acronym, but if sorted in order of importance, TWECOA might be more appropriate. Describing transformation and worldview are the crucial steps, since the form the basis for the conceptual model.
Transformations: The changes that take place within or because of the system; input/output conversion. This is the fundamental element of a system. Early clarification of the transformation is one of the clues to successful completion of the systems thinking stages, being the basis of the activities represented in the subsequent conceptual model. This is similar to input-transformation-output descriptions we know from computer systems, but more complex and less tangible.
Figure 4.5: Transformations
Worldview: How the system is perceived from a particular viewpoint;assumptions made about the system. Worldview (translated from the German word Weltanschauung) - ``world according to (members of/owners/clients of) the organisation''. What role does the organisation perform in its particular environment? How does its performance rate compared to other organisations? How do clients/competitors perceive the organisation? Different people will answer those questions in a different manner, depending on their role, background, and experience. To select relevant viewpoints, make a list of those persons or groups that have an interest in the situation (e.g. from rich picture) and define the worldviews as expressed during factfinding. Identify overlaps and disagreements.
Environment: The world that surrounds and influences the system, but has no control over it. Identify external forces which might influence the way in which the organisation operates, and the changes that the organisation is prepared to accept. The distinction of what influences but does not control is sometimes very difficult to make.
Clients: Those who benefit from or are affected by the outputs from the system. Clients might receive products or services, or be affected by the system in some way. Sub-systems might have their own clients.
Owners: To whom the system is answerable and/or who could cause it to cease to exist. Different sub-systems might have different owners.
Actors: Who carry out the activities within the system. Role of clients, owners and actors are sometimes mixed: e.g. employees who own shares, tax payers who receive services.
Having defined the roots of the model, the next stage is to illustrate it in a manner that shows the relationship between activities required of the system: via the Conceptual Model. The model will be in form of a drawing or diagram. The conceptual model shows those components (sub-systems or activities) which are logically necessary to achieve the transformation described in the root definition.
A Conceptual Model should:
| represent exactly the number of activities (tranformations) required to achieve the goals of the organisation; |
| meet the criteria for being a system (compare with formal systems model - see Section 3); |
| decompose activities in a hierarchical (what-how)manner; |
| use verbs to identify sub-systems or activities |
| contain 5-7 activities at first-resolution level; |
| have all components connected (except for monitoring & contol units) |
Constructing a model will always means going through several drafts, and several levels of resolution. Participation from "experts" from the organisation is important to check the basic model and fill in specific details (this is where discussion comes in). Once a first-resolution version model has been drawn, the process of decomposing begins: the system is divided into sub-systems, and root definitions and conceptual models are developed for each of them. In the process of hierarchical decomposition, it is important that lower-level systems describe how the activity described at the higher level is achieved.
Figure 4.6: Hierachical decomposition
The What/How Distincton: System components are often described as activities. It is important to distinguish between what is being achieved by the system or sub-system, and how it can be achieved. The latter can be described through a set of activities that can be employed. Each of those activities is another sub-system or component.
Once the conceptual model has been drafted by the analyst, it should be checked for completeness in terms of being a complete system model. This is done by comparison with the Formal Systems Model (see Section 3.3.1).
The analyst has to check whether the system has:
| an ongoing purpose, i.e. achieves some transformation |
| measure(s) of performance |
| a decision-making or control process |
| components (which are themselves systems) and interact |
| existence as part of wider system, or environment with with which it interacts |
| a boundary which encloses the area over which decision-making process |
| has resources for its own use |
| an expectation of continuity |
Once the analysts are happy with the conceptual model, it is time to move from the Systems World to the Real World again: explore what is happening in practice, making use of the models for comparison. The purpose of the model is to uncover potential problem areas for discussion with the client organisation. (Remember this is still about problem identification and definition. Remember also that the models are theoretical constructs rather than icons or architect's models: conceptual models do not represent the existing or potential structure of the organisation.)
Making the Comparison:
The comparison is carried out by taking the models across the Systems World/Real World line in the SSM stages diagram, and using them to compare what is desirable from a systems point of view with what is happening in practice. Mismatches between the systems model and the real world might indicate problems and/or where improvements could be made. The output from this stage is a list of system activities, the corresponding activities in the real world, and the differences.
You can summarise the differences in a table like this:
Subsystem Current system Conceptual Model Change required 3.1 5 processes 2 processes merge functions 3.2 separate system no system remove function 3.3 4 processes 4 processes no change 3.4 output to 3.2 output to 3.3 output to 3.3
Table 4.1: List of comparisons
Methods for comparison:
General discussion/observation: Mismatches between the conceptual model and what is going on in the organisation can initiate focussed discussion between analysts and actors/owners. Issues illustrated in the rich pictures might be indicators of fundamental problems, and subsequent comparisons of the conceptual model with the existing activities could reveal the reasons why issues arise. In a large organisation, a series of discussions with small groups of people (grouped by skills, roles, or work groups) would be advisable.
Question generation: Models can be used as a source for a series of focussed questions (might be used to generate a questionnaire which can then be given to members of the organisation). Matrix can be drawn up to check on each part of the model in turn: Does the activity exist? How can its performance be measured? Effectiveness? Efficiency?
Historical reconstruction: Comparing what happened in a particular situation with model (here typical tasks, critical incidents collected help). This also helps examine whether rationale for current organisational structure is still valid.
Model overlay: Comparing the conceptual model to the model implied by the organisation. Mismatches revealed form the basis of discussion. It can turn out, for instance, that one core activity is spread across several departments.
Figure 4.7 Model overlay
Extended Analysis: Detailed top-down examination of organisation (its activities, resources, information and communication links). Should only be undertaken if the client organisation understands that this might be very ``painful'', since all implicit assumptions will be made explicit, and their validity will be checked. Detailed investigation needs to be structured properly, and all findings have to be documented. An audit trail should be established to avoid loosing track.
This is the stage where the client organisation has to decide whether it accepts the problem definition produced by the analysts, and which changes it deems to be feasible and desirable. The task of the analysts is to clearly describe the problems as revealed by the SSM, and present suggestions for change that make sense from a systems point-of-view.
Analysts should never promise that following their suggestions will turn a problem situation into a problem-free one (i.e. never ever say that computerising an operation will get rid of all your problems - you should know better by now!). What you can promise is an improvement on specific issue, providing you have applied SSM competently and conscientiouly.
First step is to decide what issues should be addressed at this stage. The second step is defining the action which should be taken to bring an improvement.
Formally, there are 3 types of changes possible: Changes to structure, procedures and attitudes.
Structure: those factors that do not changes on a short-term basis, (organisational structure, location etc.)
Procedures: processes involved in reporting and informing, activities of producing, and those related to achieving the aims of the organisation
Attitudes: changes of influence and the expectations of individuals
The decisions about which changes to make are done after discussion with the client organisation. The analyst(s) should make it clear what type of change is required where/from who, and how/which structures, procedures or attitudes might be affected. Changes must be described in systems terms or logical terms (you could use systems diagrams), and culturally feasible - Semiotic Analysis (see Section 2) could help to work out cultural restrictions. Economic and technical feasibility also needs to be checked.
After discussion/negotiation with client has been completed, a proposal is drawn up stating what should be done and how it should be done.
| Decide what needs to be done, stating clearly the aim or objective. |
| Determine alternative ways of achieving the objective. |
| Appraise the costs of each alternative. |
| Build a model (if required) of the different alternatives, and test each model under different conditions. |
| Decide, on the basis of pre-defined criteria, the preferred or optimal alternative. |
stage output 1 Problem situation unstructured 2 Problem situation expressed Rich picture 3 Root definition CATWOE root definitions 4 Conceptual modeling Conceptual systems model 5 Comparsion system/real world List of discrepancies 6 Feasible/desirable changes List of changes 7 Action to improve Table 4.2: Summary of SSM stages and output
SSM is a complementary, not a competing approach to Traditional Systems Analysis. Traditional methods such as dataflow modelling and entity-relationship modelling provide methods and techniques for modelling internal parts of the design solution. SSM provides us with a technique for identifying and defining a problem an the existing system, and describing the requirements for a new one .
SSM as a framework for design
" ....we must develop and adopt systems analysis and design methods that consider such new developments as socio-technical systems and suitably integrate them with traditional development methods." (Gutierrez & Greenberg, 1993)
" The first [rule] is that they [the developers] must embody a level of flexibility which is commensurate with the variety of ways in which organisations undertake the work associated with their goals. If design teams make assumptions about the viability of a single way of undertaking complex processes in which the staff of the user organisations are experts, the products will almost certainly be deemed unacceptable." (Eason & Harker, 1988)
Now that the study has been completed and a thorough model of the organisation has been generated, it is necessary to think ahead to the system being developed. How is that system going to be built? One of the main themes that have been discussed within this book is the need to be flexible in developing a response. As the introduction and the case study material in Chapter 2 illlustrates, there is no procedure, either explicitly embodied within a methodology or implicitly embodied within the training of system developers, that can guarantee the success of a systems development. A structured methodology may assist with the management of a development, but modern systems analysis and design is much more than following a prespcriptive procedure. The strengths of structured approaches in providing stable, consistent and technically competent views of the system are compromised by their lack of flexibility and their limitations in exploring issues of organisational complexity. Just as the systems we create affect the environments in to which they are introduced, so the environment will ultimately affect the composition or make-up of the system. Organisational environments are increasingly less static as business pressure promotes change. We have to accept that, to varying degrees, our requirements, and hence our design and deliverables, are likely to change.
Even the coarse requirements developed at the end of the SSM study are likely to change. It is important, however, to remember that change is not a symptom of poor analysis, but an unavoidable reality. Over the weeks, months or years of a system's development, social, economical and political turbulence will affect the system being developed. A number of other factors may change the requirements for a system. Land (1987) has identified the following:
| changes in available technology |
| changes in legal requirements |
| changes in economic and environmental factors |
| changes in attitudes, expectations, tastes, or in climates of opinion |
| changes within the organisation |
It is difficult, perhaps impossible, to 'guess' what might change over the life time of a system development, so a 'futures analysis' is only of limited use. Likewise, it is impossible to make our designs so flexible that any change can be immediately incorporated. At some point, we must commit ourselves to a particular design (Fitzgerald,1988). Because of this constraint, we must understand the nature of the organisation, and of the problem being invesitaged. We cannot predict individual changes to requirements, but we can choose the approach best suited to handling particular types of problems.
The strengths of the SSM study are connected with the level of understanding of the organisational reality within which any future system development will have to be incorporated. Information systems have to be as flexible as the social systems they are used within and can no longer be "conceived as autonomous artifacts "(Gutierrez & Greenberg, 1993) - developed in isolation. Understanding the characteristics of the organisation and of the problem to be solved can be beneficial in defining the best approach for developing a particular system.
The basis of the toolbox approach is that the analyst - rather than following one prescriptive methodology - chooses the tools and techniques depending on the problem situation. The process we use to support the toolbox approach has its roots within the SSM technique. By identifying characteristics of the organisation and the problem type, it should be possible to tailor the system development approach in order to generate a 'best' fit for the system to be developed. Much of this work has been based on earlier models, ( Gutierrez & Greenberg, 1993; Gowler & Legge, 1978) which look at how the characteristics of project management and user participation, respectively, are dependent on the nature of the organisation. Land(1989) has presented what he sees as four different classes of information system development, dependent on the characteristics of the problem. The remaining part of this section merges the two different fields of research, in order to build a simple framework for the toolbox approach.
In Chapter 3, we outlined the areas of systems and organisational theory. The first task in defining the development approach to be used is to understand some of the characteristics of the organisation, and also of the environment within which it is based.
The characteristics of the organisation can have an important impact on the approach taken to develop a system development. Each of the four main organisational types (Hornby & Clegg, 1992; Gowler & Legge, 1978) are outlined below:
| Mechanistic - Stable | Organisation is characterised by having 'vertical' communications (top-down
decision making), set heirarchies, demarcation of responsiblities and skills and set routines and procedures. When conditions are stable ie, a change within one activity creates little or no change in other activities, then group participation (within a project) will tend to be highly regulated, in terms of exercised authority, control of resources, task specialism, etc. |
| Mechanistic - Unstable | As above, but when conditions are unstable, ie a change within one activity creates
unplanned changes in other activities, then group participation (within a project) will tend to be sporadic, with temporary task groups, etc. |
| Organic - Stable | Organisation is characterised by having lateral/consultative communications,
flexible work roles, flexible work structures. When conditions are stable, then group participation (within a project) will tend to be open, with regular consultation between groups. |
| Organic - Unstable | As above, but when conditions are unstable, then group participation (within a
project) will tend to be ongoing. |
Table 4.3: Types of organisation
Looking back to the results of the SSM study, was the organisation an example of a Mechanistic or Organic organisation? (For a definition of systems, and systems structures refer back to Chapter 3). From the data you have collected, you should be in a position to characterise the organisation you have analysed as having certain characteristics that identify them as mechanistic-stable, organic-unstable etc.
Figure 4.8: Types of system development in organisational context (based on Gowler & Legge, 1978)
The idea that we are promoting is that the types of system development approaches are dependent variables. So, the acceptablity of prototyping approaches, and of novel forms of development strategies, like user participation in design, depend to an extent on the characteristics of the organisation. Hornby and Clegg (1992) give a good example of how such constraints may show themselves:
" This perspective leads to the prediction that mechanistic organization structures find it difficult to accommodate 'open' participation [of users]. In such organizations the responsibility for decision making lies, traditionally, with management and not with staff. Conflict rather than co-operation may be the accepted means of resolving differences."
Figure 4.8 illustrates how the organisational context influences both the nature of the problem, and the system development strategy. Each of the labels (marked A or B) indicate the problem type (Gutierrez & Greenberg, 1993) and the development strategy needed to cope with those problems. The process works by identifying the organisational type. Once the organisational type has been decided, the nature of the problem can be considered. For example:
You have recently completed an SSM study of an organisation dealing with the design and manufacture of engine fittings. The management of XYZ automotive originally asked you to carry out the study, as they are interested in speeding up the design and development process, and reduce the turn-around in developing parts to less than three weeks. The organisation has a highly layered structure of management, and different parts of the product have to be developed by different divisions. Recent safety legislation has had major impacts on the development process, as have the introduction of a CAD/CAM system to replace the old drawing room staff. Given the highly structured nature of the organisation, and the instability in work operations and the environment, you have decided that this organisation shows signs of being mechanistic-unstable.
If we look at Figure 4.8, the consequences of having a mechanistic organisational structure and an unstable organisational process is that two problem types are possible - Practice or Evolution (Table 4.4 describes the characteristics of each problem type). Later, when we consider what system we are going to develop, the choice between the problem types (either A or B) will inform the development approach we finally take.
A choice of which problem type will need to be The toolbox approach takes into account a number of project-specific characteristics. The framework is based on earlier work by Guterriez and Greenberg (1993) and Land (1989), who define four classes of information systems, depending on characteristics of the real-world and the demands that these place on the development process. The four types of system are described below:
| Problem Type | |
| Specification | Real World is understood and stable Functional specification is a good
representation of that world. Emphasis is on error-free code and accurate transformation of specification. |
| Practice | Real World is dynamic Information system itself changes. Specification valid for a limited period. Emphasis is on flexibility and ability to respond to change. |
| Evolution | Designers unsure of real-world requirements or user responses. Highly turbulent environments make confident specification difficult to produce. Emphasis is on experimental methods including prototyping. |
| Uncertainty | Intense interaction between system and environment. Process of systems
operation itself changes the environment. Emphasis is on constantly changing specification and adaptive code. |
Table 4.4: The four types of information system
Refer back to Figure 4.8. The individual problem types are labelled A or B. These represent the types of problem that are likely to be faced, and the characteristics of that problem type (illustrated in Table 4.4). We have to identify whether the project we are to undetake is going to be either technically or socially complex. The recommended choice of A or B depends on the broad characteristics of the problem domain. A framework for making such a choice is outlined below:
Figure 4.9: Defining the problem to be analysed
Even though the organisational context may constrain the range of approaches that can be used to develop a system, the characteristics of the problem will also affect the choice of suitable techniques and tools. If the social impact of the system being produced is extensive, causing very visible changes in the way that work is carried out within an organisation, then a more considered, evolutive approach may be needed to develop the system. An example of this type of application is an office-based system, which many different types of users will use, or be affected by, as part of their working lives. On the other hand, if the system is highly complex, is affected by legislative requirements or when there are intense internal pressures to complete the project, there is a real need for verifiable design materials and accurate tracking of changes to the system. An example of this type of development would be systems where security or safety issues are important, and affect the technical complexity of the system.
In figure 4.9, 'A' characterises an approach where the problem type requires close and efficient management. 'B' characterises an approach were the identification of important social issues are critical to the success of the application. Again, with reference to the SSM study that you have carried out, identify individual characteristics of the problem. On the bi-polar scale, identify how relevent each of the problem characteristics, as indicated, are to the system you have identified. For example, you have completed a study of an Underground station electronic gate system. You feel that while the use and social acceptability of individual gates will need to be assessed via prototyping, the overall social impact of such a system is fairly limited. In the course of your analysis, however, you discover that the technical complexity of such a system is fairly high and reliability issues are important, not only for the management and staff using the system, but also for the users, who get angry when the system breaks down. Therefore a technically robust system is necessary. You may indicate these characteristics in the following way:
Figure 4.10: Problem identification
Each of the seven possible choices along the bi-polar scale indicate the degree to which you feel that the characteristic is important. In Figure 4.10, the analyst has indicated that, while there is some social impact, the introduction of automatic gates will not cause dramatic social changes in the environment. The analyst has indicated that they feel the system to be developed is more technically complex than straight-forward. Each of the points on the scale has a value associated with it. When you have identified the importance of each of the problems, add up the total. If your final total is a negative one, then it is quite likely that a more controlled and cautious approach will be needed to solve that problem, and solution strategy A is more acceptalbe. If the final total is a positive number, or zero, it is likely that the technical and legal considerations will be outweighed by the social impact that the system will have in its environment, and solution strategy B is a better fit for the problem. The complexity of the social system may affect the number of requirements changes, so a more evolutive and exploratory approach will be needed to develop the system.
In summary, the application of a system development approach needs to be based on the characteristics of the organisation, and the characteristics of the problem type. Now that these characteristics have been identified, it is important to develop a framework suitable for handling these approaches. Chapter 11 covers the remaining analysis, design and implementation strategy that you will need to put in place.
D. Patching (1990): Practical Soft Systems Analysis. London: Pitman.
A very readable introduction to SSM, and, true to the promise of the title, aimed at those who want to apply SSM. Written with information system design in mind, it gives practical examples at the various stages and introduces some related SADMs such as MultiView.
P. Checkland (1981): Systems thinking, system practice. London: Wiley.
The original book on Soft Systems Thinking, explaining the the history and motivation for SSM. Still essential background reading for those who are designing technology in organisations today and want to develop a considered perspective of what this entails.
D. K. Hitchins (1992): Putting systems to work. Chichester: Wiley.
The author aims to bridge the gap between soft and hard systems thinking through by introducing his own concept, the Unified System Hypothesis. Most valuable is the non-theoretical part of the book which is firmly aimed at application of systems thinking to technology design and manufacturing, and contains a fair amount of case study material.
P. Checkland & Scholes (1990): Soft Systems Methodology in Action. Chichester:Wiley.
A collection of case studies performed in the public sector and industry. Most are focussed on identifying organisational issues and stakeholders.
K. Eason and S.D.Harker (1988): The Suppliers Role in the Design of Products for Organisations, The Computer Journal, Vol 31, No 5.
G. Fitzgerald (1988): Information Systems Development for Changing Environments: Flexibility Analysis, in Information Technology for Organisational Systems, H.J. Bullinger et al (Eds.), Esevier Science Publishers, North-Holland.
D. Gowler. & K. Legge. (1978): Participation in context: towards a synthesis of the theory and practice of organisational change. Part I, Journal of Management Studies 15, (pp150-175).
Gutierrez and Greenberg(1993) - 'Creative problem solving', Journal of Systems Practice.
P. Hornby & C. Clegg. (1992) 'User Participation in context: a case study in a UK bank' in Behaviour & Information Technology, Vol 11. No. 5, (pp. 293-307).
F. Land (1989): From Software Engineering to Information Systems Engineering. In Knight, K. [Ed.]:Participation in Systems Development , (pp.9-33), UNICOM Seminars.
F. Land (1987): Adapting to Changing User Requirements. In R.D.G. Galliers (Ed.) Information Analysis: Selected Readings. Sydney: Addison-Wesley,.
Even though there is a quite a bit of reading available on SSM and its applications, including case studies, the only way for an analyst to develop an appreciation for its potential and problems is to apply it. Unless one is working alongside an experienced analyst, it is not advisable to do one's SSM virgin run on the analysis and design of a real information system.
A good way to gain hands-on experience and practise is analysing an existing system mainly by observation, analysis of written documents and a limited number of interviews. We all participate in a number of systems as customers and employees. Performing an SSM on one of those systems is usually an eye-opener both in terms of how SSM can help to identify the problem and design the solution, and how much scope for improvement there is in most administrative and commercial organisation. Students are often sceptical at the beginning of the exercise. They usually voice their scepticism by saying:
Surely XXX (Name of Organisation) know what they are doing? If they do it this way, it must be the best way of doing it. How could we possibly find ways of improving it?
We have to come across an SSM exercise that found a system which could not be improved. Once persuaded to start the factfinding, they tend to uncover a issues and problems, and become intrigued. The output of the 7 SSM stages should be compiled into a report. This is best performed as a group exercise, ie.e working as a team of analysts preparing the report as basis for a bid to build a new information system. This reduces the amount of time and effort which has to be spent on factfinding, and gives helps to get over the blank page problem when writing root definitions and building conceptual models. Presentation to and feedback from peers or instructors on the output of the various stages can replace feedback from customers.
It is best to chose relatively small systems for this. If at all possible, the opportunity to perform some interviews with employees, owners and customers of the system should be given. Access is often easiest to gain to systems within the education establishment, such as the library, registry, refectory, accommodation office etc. Another way of gaining access to public or commercial organisation is to use the fact that many students today work or have worked, or to gain access through friends or relatives. Examples for such systems are: small retail units (E.G. video rental shops, bookshops, clothes shops), subsystems of large retail units (e.g. checkout systems in supermarkets) ticket sales or information systems in public transport, etc.