SSM – The Method

The conventional seven-stage model of SSM is shown here. A major criticism of this model — later made by Peter Checkland himself — is that it is too linear to represent the actual process of inquiry that SSM requires. Whilst most SSM analysts would accept that, this model provides a useful starting point for novice analysts.

Figure 1. The Seven-Stage, Soft Systems Methodology Approach

 

It is important to include activities which monitor the system and feed-back results, so that system activities may be performed effectively. There are normally two feedback loops in any conceptual model:

• An internal feedback loop, that permits actors involved in the human-activity system perspective modeled to adjust how they perform their work (in this case, this loop is between the “Assess” and “Determine” activities).
• An external feedback loop, between the inputs and the outputs of the activity system model. This permits managers to assess and manage the system of activity as a whole. (This loop is indicated by the dotted lines on the model).

To permit the effective management of any system, you need to define a measure of success for a particular transformation. This is shown below the conceptual model in Figure 7.

Stage 5: Comparing Conceptual Models With The Real World

One of the best things about SSM is that you are never allowed to forget that your model does not represent the “real world”.  So what does “system thinking about the real world” (your set of conceptual models) represent?

Best case: your models represent a more effective way of achieving the work goals, based on how the core stakeholders perceive that the system of human activity should take place.

Worst case:  your model automates what’s there now – the manual system, or worse still, the current computer system (if the current computer system is so effective, why do you think they called you in to investigate how it could be replaced?).

Consider how far your model lies between either of these extremes (nobody’s perfect).  The purpose of all this activity is not to just draw pretty pictures, but to provide a solid set of prioritized recommendations for what changes need to be made to existing activity systems (which is a prerequisite for defining what information systems are needed to support those changed systems!). Figure 6 represents the process of SSM analysis (from a “what is modeled” perspective, reflecting how the various purposes intersect, rather than the seven stage process model). Once you become practiced with the approach, you will notice how useful it is to include social and political aspects of the problem situation in your analytical models.

Figure 6.  What Aspects of the Situation Are Modeled Using An SSM Approach

Stage 6: Analyzing Feasible And Desirable Change

Now our task is compare system models of the real world with what happens in the real world. It is helpful to involve participants in this process. Validate conceptual models by presenting them to stakeholders and asking for feedback. To continue our example, taking system transformation (7), we can observe that:

1.  Driving is less expensive that public transport. Action = determine the extent of cross-subsidy required and implement it.

2.  There is no road rationing system in place. Action = implement a road rationing system.

3.  We have no effective way of gathering statistics on road use vs. use of public transport. Action =  put information gathering mechanisms in place.

At the end of the day, you will (probably) not be the person implementing the changes that you suggest. The system owners and actors – the people involved in the system – have to live with these changes and make sure that they are happy with them and consider them appropriate.

To analyze dependencies between the various actions for change — and to analyze missed synergies between the subsets of activity — we can assemble a “bricolage model” from various transformations. The actions for change, taken together, will need to work as a coherent system – one of the major issues with change management is that we often have conflicting aims, but don’t realize it (which is why the “divide and conquer” analysis of SSM is so useful). Figure 7 relates the seven purposeful systems of activity that we modeled in the input-output transformations and defined with the root definitions, above.

Figure 7.  Integrating The Separate “Purposeful System” Perspectives Analyzed in the Root Definitions

Note that this is the first time we have put a name to those systems (i.e. filled in the transformation bubble). This is deliberate. Until you have decomposed, explored, validated, and obtained consensus on all the activities required for each conceptual model — and perhaps split or redefined transformation perspectives along the way — you can’t really understand what the core purposes of the various system perspectives are. Figure 7 demonstrates a method by which to relate these perspectives, to explore what how they reinforce, support, or oppose each other – and what needs to change in the overall system of human-activity that you have modeled.

 

There are three elements that need to be considered: Feasibility, Priorities and Risk

Feasibility

In the course of your analysis, you will have come to understand a great deal about how the various activities are performed. Make sure that you write down which changes are feasible and which are not (and why), so that this understanding is communicated to the people who inherit your analysis.

Consider:

• Cultural feasibility: what is acceptable to the people working in this part of the organization (from their perspectives).
• Technical feasibility: what it is appropriate to support with computer technology and what should be left as a manual process – as well as what it is possible to computerize.
• Dependencies between work-systems and between technical systems. Sometimes it is necessary to complete one set of changes before another set can take place.
• Win-win: does the change make life easier for people. If you are recommending that people perform six steps instead of three, to accomplish a task, perhaps you should reconsider? If people’s lives are made more difficult, they will resist change and probably find ways to sabotage it. It makes sense to define changes that the people involved in the activity system will accept. Perhaps you need to find ways of compromising, so that everyone wins by the changes that you propose.

Priorities

Prioritizing changes is one of the most important tasks in the whole analysis. One way of prioritizing change is to use a balanced scorecard approach, as demonstrated here:

• Assign each system ALTERNATIVE a score out of 10, depending on extent to which it helps the system solution achieve a main goal or solve a main problem.
• Weight the scoring (e.g. score goal achievement out of 10 and problem solution out of 5, or vice versa, depending on whether you are there to make the organization more effective, or  to solve a set of pressing problems, OR BOTH!).

The changes with the highest scores should take the highest priority for implementation. However, you also need to consider feasibility and risk, when determining priorities. (You could make the table bigger, to assign each change a score for feasibility and a score for risk).

Risk Analysis

Risk or Benefit	Probability That This Will Happen	Importance To Goals of Change	Risk/Benefit Score **	Cause or Way In Which Risk/Benefit Could Happen	Risk/Benefit Management Strategy
Cut accidents by 20%	High, score (out of 10) = 9	10 (out of 10)	90	Policing parking should prevent dangerous parking and reduce accidents	Ensure policing is consistent, frequent, and well-publicized
Provide self-financing scheme	High, score = 10	10	100	Policing parking will raise revenue for scheme through fines	Ensure policing is consistent and frequent – and that all income is directed back into parking fund
Improve off-road parking*	High, score = 8	10	80	Policing parking will direct more cars to car parks, allowing us to raise more revenue for scheme and increasing business property values	Ensure that businesses are involved in planning car park locations – and that all income is directed back into parking fund
Improve public transport*	Medium, score = 6	8	48	Policing parking will improve traffic flow, allowing buses to move freely. Income from fines will allow us to run more buses and trains.	Plan incremental change, as income is allocated to transport funds
Improve disabled access	Mid/High, score = 7	9	63	Policing parking should improve sidewalk access + we can fund ramps from parking fine income and business property taxes.	Focus on one area of downtown each period; evaluate changes and publicize these.
Improve business access*	High, score = 8	10	80	Improving access will increase property tax base (as property becomes more valuable). This provides more income to fund the scheme.	Provide more car parks near to downtown businesses; Combine with more effective policing of illegal parking.
Increase local employment	High, score = 9	10	90	Implementing the scheme will employ local residents as parking wardens, which will ensure consistent and frequent policing.	Evaluate performance and implement bonuses based on fines raised

 

** Highest scores indicate risks/benefits that need managing carefully
* Starred outcomes require an evolutionary or experimental prototyping approach to achieve

Stage 7: Taking Action

At the end of the day, you will (probably) not be the person implementing the changes that you suggest. Bear in mind that the people involved in the system have to live with these changes and make sure that they are happy with them and consider them appropriate.

When implementing change, consider two cardinal rules of change management:

1. Do not try to change everything at once. Plan a set of incremental changes and reassess the need for change after each one has been implemented.
2. Involve the people actually working in the activity system. If you do not get their ownership and buy-in to the changes, it is likely that these will be a dramatic failure.

 

End Note: Defining IT Requirements Using SSM

You’re probably thinking – OK, I got this far, but how does this relate to computer system requirements? These are just the initial actions for change. Once these mechanisms are in place, we can start to determine a set of detailed requirements for computer support. But unless we understand the details of all this stuff – the multiple purposes that the work-systems (the various human-activity systems represented by each conceptual model) exists to fulfill, the rationale behind these work-systems and the ways in which performance and success are measured, there is no way that we could define requirements for a computer system to support these work activities.

These steps depend on iterations of determining what is not done (or not done well), what is not communicated in the way required (i.e. information-flow between activities is missing), or what is not monitored appropriately. The success measure defined for each transformation should be monitored, as shown in the conceptual model above. The blue activities in the conceptual model represent activities that are not currently done. This is where feasibility is considered: how and can these activities be performed effectively? What should be fixed first? The “take corrective action” activity is complex and may suggest a new transformation that needs to be modeled as a whole, or it may relate to another transformation that was already modeled. Each process in Figure 7 represents a single Transformation (purposeful system perspective), as modeled in step 2. When we assemble the system of systems, we have the requirements for an integrate IT system to manage the complex situation.  Each of the conceptual models can easily be modeled as a use-case, to define system requirements in detail. But until you understand how they affect each other, you can’t produce a feasible plan of action for change.

© Copyright Susan Gasson, 2014-17. Created 12 December 2014.