Checkland and
Soft Systems
Copyright 2017 Graham Berrisford. One of
several hundred papers at http://avancier.website. Last updated 03/11/2018 18:02
What does “soft” mean? And is a soft system any different from a hard system?
Contents
The
triumvirate who created the soft systems methodology
Checkland’s
soft system methodology
Checkland’s
root definitions and CATWOE
Soft meaning
1: a system that is theoretical, a perspective of a concrete reality
Soft meaning
2: a system with questionable aims
Soft meaning
3: a human situation rather than a system
Soft meaning
4: a methodology rather than a system
Soft meaning
6: a socio-technical system
Bausch (2001) alludes to Churchman, Ackoff and Checkland as the triumvirate who created the “soft systems methodology” in the 1970s.
Churchman initially wrote for people in what was then called the operations research department.
Operational researchers studied regular business operations and proposed how to optimise systems they found therein.
|
Churchman’s view |
|
Business
systems <define
and optimise>
<abstracted from> Operations research
<observe and envisage> Business operations |
Ackoff said many things, not all of them made sense.
In “System of System Concepts” (1971), Ackoff’s first, his first four ideas about systems were these:
1. System: a set of interrelated elements
2. Abstract system: a system in which the elements are concepts.
3. Concrete system: a system that has two or more objects that act to realise an abstract system.
4. System state: the values of a system’s properties at a particular time.
|
Ackoff’s
v iew |
|
Abstract systems <create and
use> <idealise> Observers <observe & envisage> Concrete
systems |
The property values of a concrete system realise the property types or variables in an abstract system description.
The concrete entity we call IBM can and does realise many different abstract systems, and is therefore many concrete systems at once.
Can the IBM be a system before we describe that system? Yes and no.
It can be infinite systems before we describe any of them.
But it is meaningless to say IBM is a system without reference to which of those infinite system descriptions we have in mind.
Peter Checkland spoke of systems as input-to-output transformations.
He defined a system as a perspective of a reality, a world view or “Weltenshauung”.
|
Checkland’s
view |
|
Systems <define> <are views of> Stakeholders <observe and envisage> The world |
Ashby said infinite theoretical/abstract systems may be abstracted from any empirical/concrete entity.
Checkland brought this idea into his methodology.
Checkland defined a system as a perspective of a reality, a world view or “Weltenshauung”.
“Implicit
here is the notion that an observer engaged in systems research will give an
account of the world, or part of it, in systems terms;
·
his purpose in so doing;
·
his definition of his system or systems;
·
the principle which makes them coherent entities;
·
the means and mechanisms
by which they tend to maintain their
integrity;
·
their boundaries, inputs,
outputs, and components;
·
their structure.” Checkland (1981, p. 102.)
To paraphrase, Checkland’s system (aka transformation) might be defined thus.
·
A
structure of components
·
that
interact in mechanisms that
·
maintain
the integrity/coherence of the entity and
·
consume/deliver inputs/outputs
· from/to each other and external entities.
The table below shows Checklans system concept is much the same as in hard system thinking approaches.
|
Generic system description |
Ashby’s design for a brain |
Boulding’s social system |
Checkland’s
Soft System (Transformation) |
An object-oriented software system |
|
A collection of active structures that interact in regular behaviors that maintain system state and/or consume/deliver inputs/outputs from/to the wider environment. |
A collection of brain cells that interact in processes to maintain body state variables by receiving/sending information from/to bodily sensors/motors. |
A population of individuals that interact by processing information in the light of mental images they remember, and exchange messages to communicate meanings to others and related populations. |
A coherent entity, a
structure of components that interact in mechanisms
that maintain the integrity of
the entity and consume/deliver inputs/outputs from/to each other and external entities. |
A population of objects that interact by processing information in the light of state data they remember, and exchange messages to communicate with other objects and system users. |
All four specific
cases fit the generic system description reasonably well.
In every case, the
real world entity is regarded as a system only in so far as it realises a
system description.
Checkland proposed modelling the transformation (the system) in an abstract and informal “conceptual model” or “business activity diagram”.
This model shows transformation activities connected by dependency arrows.
Checkland proposed drawing up root definitions of a business entity – to uncover different viewpoints
E.g. Who is the customer of the system that distributes money from various European Union agricultural schemes to French farmers?
The farmers? The French government? The French taxpayer? The European agency whose existence depends on the scheme?
This source offers this example root definition.
“A company owned system to market the products and services of the company to existing and future clients by the most appropriate cost effective means.”
Then analyses that root definition using Checkland’s CATWOE acronym as below.
The “system” is primarily the Transformation, and the roles of Actors in that.
|
Root definition
analysis |
|||
|
C |
Customer |
Entities that receive outputs from the transformation |
“existing and future clients” |
|
A |
Actors |
Entities that do or could perform activities in the transformation |
“the company” |
|
T |
Transformation |
Activities that transform input to outputs |
“Market the products and services of the company” |
|
W |
World view |
The belief that makes sense of the root definition |
Providing appropriate marketing to a particular client will promote company products and services |
|
O |
Owner |
The decision maker concerned with system performance |
“the company” |
|
E |
Environment |
Constraints outside the system significant to the system |
“appropriate cost effective means” |
A truly general system theory (think, the solar system) does not feature Customers or Owners.
And for business systems, CATWOE may underplay the importance of Objectives, Outputs, Inputs and Suppliers.
Checkland Soft Systems Methodology (SSM) has seven main steps
This can be
presented as a variation of the approaches used in hard systems engineering.
The table below compares the seven steps of SSM with the steps in a typical system engineering methodology.
The difference are mostly cosmetic, a matter of emphasis or of particular technique.
|
A system
engineering methodology |
Checkland’s
Soft Systems Methodology |
|
Study the
context: goals, constraints, stakeholders, their concerns, problems and
requirements |
1. Enter the problem situation. |
|
Outline
optional solution visions, along with value propositions for stakeholders |
2. Express the problem situation (a rich picture) |
|
Analyse
trade offs between solution options with respect to the context |
3. Formulate root definitions of relevant systems
(validated using the CATWOE analysis below) |
|
Describe
a target system that compromises between conflicting goals and constraints |
4. Represent human activity systems as conceptual
models (business activity models) |
|
Plan the
work to move from the current to the target system |
5. Compare the models with the real world. |
|
Follow
the plan to build and test the target system |
6. Define changes that are desirable and feasible |
|
Roll out
the target system. |
7. Take action to improve the real world situation. |
This table shows both soft systems analysts and mechanical engineers are taught much the same process.
Even mechanical engineers have to trade off between different goals, some of which conflict.
The fact that stakeholders approve a target system description doesn’t mean they share the same perspective of, or purpose for, the system.
Each stakeholder may have their own perspective of and value proposition for a motor car.
Checkland proposed a generic design pattern for structuring a business.
First, regular operations management: a control system to set aims for, monitor and direct the transformation activities.
· Defining targets for operations
· Operations (the transformation or business system)
· Monitoring and Controlling Operations (the regulatory system).
Second, overarching executive/governance: a meta system to set aims for, monitor and control the regular operations management.
What does “soft” mean? And is a soft system any different from a hard system?
Peter Checkland (like Ashby) spoke of systems as input-to-output transformations.
He defined a soft system as a perspective of a reality, a world view or “Weltenshauung”.
The difficulty here is that “hard systems” thinkers make the same point.
W Ross Ashby wrote that infinite theoretical systems may be abstracted from a concrete entity or “real machine”.
If all systems are abstractions, how else to distinguish soft systems from hard systems?
“Churchman, Ackoff and Checkland consider hard systems methodology to be a special application of systems theory in situations where the objectives are not in question” Bausch (2001)
By implication, the distinguishing feature of a soft system is a debate about its aims.
However, the objectives of human beings, businesses, and even man-made things like motor cars, are questionable.
Which is why even mechanical engineers are taught to manage stakeholders and trade off between conflicting goals.
Checkland proposed his Soft Systems Methodology starts not with spotting a system to be reengineered but with spotting a confusing or complex situation.
OK, but these are not mutually exclusive starting points – and the end product is indeed a re-engineered human activity system.
His concern is to model regular business systems (he called transformations), and change them from a baseline (problematic) state to a target (improved) state.
After several decades, Checkland wrote "Soft Systems Methodology: A Thirty Year Retrospective" (2000)
In his review, he said the hard-soft distinction had proved slippery; people grasp it one week and lose it the next.
He said the term "soft" was intended to describe not systems, but an approach to solving problems in human activity systems.
OK, but defining a systems thinking approach as soft is very different from defining a system as soft.
Checkland said he designed the Soft Systems Methodology as a “learning system”.
OK, but all traditional system design methodologies include activities intended to help designers learn about the context.
And it is important not to confuse the meta system with the system.
Classical system theory can be applied to a human system (some call this “structuralism”).
Consider a tennis match as a system.
The human actors play defined roles, follow defined rules, and communicate using agreed terms (“fault”, “second serve”, etc).
If the players stop to debate and change the rules of the tennis match they are playing in, they are acting outside that system.
They are now playing roles in a meta system that observes and changes the system.
In practice, it may
be clearer to think of soft systems thinking as subtype of hard systems
thinking, which is specific to:
·
Open (rather than closed) systems, which have external customers and
suppliers.
·
Designed and purposive (rather than naturally evolved) systems,
which have owners and stakeholders.
·
Social and socio-technical (rather than purely technical) systems,
which employ human actors.
A socio-technical system is typically defined as “a group of people organised to use technologies to realise the functions of a system.”
But this is to flip between a discussing a concrete social group and an abstract system it realises.
· An abstract business system comprises logical functions that produce and consume data flows, and roles that people can play.
· A concrete business comprises real organisation units that realise the functions, and actors who realise the roles.
A business employee is only a member of the abstract system where/when they realise one or more roles in it.
And every person does many things outside of the abstract system.
There is rarely much that is sociological (political, cultural or personal) in models of a socio-technical system.
Except, perhaps, the risk that a data flow is inadequate or not understood, which might be addressed by adding a data flow to request clarification.
The biggest single issue in soft systems thinking is the confusion between:
· A social group or network in which people communicate
· A social system in which people realise role and rules.
It is social network (not the social system)
that has self-organizing dynamics.
It
is strongly recommend that you now read Social
networks versus social systems.
All free-to-read materials at http://avancier.website are paid for out of
income from Avancier’s training courses and methods licences.
If you find the web site helpful, please spread the word and
link to avancier.website in whichever social media you use..