Business Process Transformation - Spring 1996 Business Process Transformation - Spring 1996
The soft systems methodology was developed in the 1960s by Peter Checkland at Lancaster University. This methodology arose out of attempts to apply systems engineering principles ("hard" systems theory) to business problems. Systems engineering emphasises measurable system objectives and the top down decomposition of systems into subsytems. Advanced views of systems engineering (such as VSM) show how systems exhibit emergent (unexpected, counterintuitive) behaviour because of complex feedback loops among system components.
When applying systems engineering to what he came to call "human activity systems" (people working together to achieve something) Checkland found a number of problems. Organisation goals (I use "goals" and "objectives" more or less interchangeably) were matters of controversy; in particular most investigators assumed that all members of the organisation accepted goals set by top management, but this is usually not the case. Formal methods usually begin with a problem statement; Checkland found that fixing the problem too early made investigators unlikely to see different, possibly more basic, problems. And the method itself restricted what could be found out; if we expect the organisation to be describable by the interaction among a number of clearly bounded subsystems then that will happen - we will see in the organisation a reflection of our methods.
To overcome these problems Checkland eventually proposed the following methodology. As with most methodologies, SSM was derived by summarising experiences from apparently successful projects done over a number of years. These projects usually involved external consultants advising on fairly high level problems (eg a publisher losing market share, a government agency wondering how it can benefit from new technology).
A key feature of SSM is the advice to keep the project vague and wide ranging for as long as possible - don't jump to conclusions, and don't ignore the current situation by concentrating on some utopian future. At times Checkland would probably say that the process is more important than the outcome - just going through SSM will change the organisation, and this will probably include a changed opinion about what problem we were really trying to solve. (SSM is not for high achievers, because a goal is never reached!)
It is important to realise that in principle an SSM project is done by the people in the organisation, with the consultant acting as a facilitator.
In Checkland's earlier work this was two phases, problem statement and analysis. The new name indicates that we don't know what problem we are interested in until the analysis is done. It is important in this phase to be as unsystematic as possible. There may be checklists of things to look for, and we will use many analogies from engineering, politics, biology and culture but it is important not to get stuck with one model. The usual creative techniques such as brainstorming will be used.
Part of the problem expression is working out who are the involved parties. Checkland uses mnemonic CATWOE to describe the human activity and its situation. A certain Transformation (process) is performed in a certain "atmosphere" (Weltanshauung - world view). It is performed for Clients (those who more or less directly benefit - customers - or suffer) by Actors. The activity is ultimately "controlled" or paid for by Owners, and occurs within an Environment. Notice that some of the people categories (actor, client, owner, environment) may overlap.
Checkland actually recommends CATWOE analysis as the first step in working out a root definition, but I think it is useful during problem expression. Still, you should avoid doing it too early in case you jump to conclusions about who is "important".
If, for example, we were examining a system which landed an aircraft, the transformation would involve getting the aircraft from (say) 100km and 10000m from the airport onto the runway in one piece. The actors would be the pilots (maybe both human and auto), the clients would be the passengers and crew, the owners the owners of the airline, and the environment air traffic controllers, air lanes, traffic conditions and geographic features. The weltanschauung would involve high concern for safety and (for a large aircraft) high technology operations.
Notice that the system here is the operational one. If we were inventing or designing a new system the clients may very well be airlines and/or government regulators.
Checkland tends to describe his systems with diagrams known as "rich pictures". Some students have commented that this can be any sort of picture, a diagram "without rules". This is exactly the point, though rich pictures do have some distinguishing features. They show the people involved, their stated purposes, and their desires and fears (usually in think bubbles). They show more environmental detail than most diagrams (human activities, like processes, cross organisational boundaries). And they show how interests agree or conflict. Rich pictures are cartoons - they can be funny, sad, political, preferably all at once. You can compare a rich picture from Wood-Harper with a political cartoon from Bruce Petty (an Australian systems cartoonist).
CATWOE analysis and rich pictures concentrate on the process view. Since SSM is quite concerned with existing systems, Checkland also recommends that we find out about the organisation structure and how this interacts with the process. Part of this interaction is the "climate" of the organisation (is it efficient, sloppy, democratic, sulky, joyous, ...?).
After the problem expression stage SSM participants will see the organisation in new ways. They will have a vast collection of "facts" at varying levels of detail, and many "problems", some major and some trivial . (But which are which?)
Now we have to bring it all together. Somehow or other the SSM team has to agree on what it is all about. What is the human activity on which we spend so much of our time together? This is the root defintion. It is like a very brief mission statement, though it applies to an activity and not necessarily an organisation or division of an organisation, and it is definitely for internal use rather than public consumption. In one sense it is the minimum we can agree on, but it must describe our real activity. And there will have already been much argument,because people will see what they are agreeing to and what has been left out.
Typical examples might be "we land the aircraft safely at any well-equipped, probably busy, airport", "we make gearboxes in the shadow of Mt Fuji", "we try to understand what is meant by BPR, and its advantages and disadvantages", "we are maintaining Australian capability in IC manufacture", "we provide full time employment for locals in this town" or "we inform students of their results, taking into account privacy considerations".
Notice that the root definition defines what is agreed and what is still up for discussion, and that many important (but not yet agreed) things might not be mentioned. We need to be sure that so far everyone is still with us. Achieving a truly agreed root definition (at least for the time being) is probably the most beneficial part of SSM.
Once the SSM team has agreed on a root definition (and the CATWOE participants) they temporarily forget about the existing system and model their "ideal" system to do the job. Here we can come up with lots of crazy ideas, though eventually we need to choose the "best". This means that we need choice criteria (though in the end the "best" model will be the agreed one, so the criteria can be implicit). Checkland suggests as criteria five Es: efficacy (will it work at all), efficiency (will it work with minimum resources), effectiveness (does it contribute to the enterprise), ethicality (is it moral) and elegance (is it beautiful).
The construction of the model was originally seen by Checkland as fairly formal, and he provided a definition of a "proper" logical model. Recently he has rejected the idea of a formal model. His current models are usually process models, with a small number of steps. Unlike BPR, however, SSM includes in its conceptual model management and support activities. The model must have enough detail (including resource use and performance measures) for it to be evaluated, but complete specification is not necessary since, as we shall see, the model is unlikely to ever be fully implemented.
In the aicraft landing example, the model may be: choose a runway, wait until runway available, lock onto approach path, fly to runway, lock onto final approach, touch down, stop; with supporting activities: ensure safe operation of aircraft, cooperate with airport operators and other aircraft, perform peer monitoring of crew performance. In this example these steps are probably fairly fixed in the short term, so the suggested ideal system would come in the detail of how these steps are implemented.
The conceptual model is used for comparison with the current system. Why aren't we doing it the "ideal" way? What is the reason for our current odd behaviour? How do we measure up to the ideal, semi-formally by the four criteria of efficiency, effectiveness, ethicality and elegance, and intuitively by group opinion? (We know the current system is efficacious - it does something - because it exists.) The conceptual model is meant to provide inspiration, not criticism.
Assuming our current system is not perfect (which is why we undertook the study in the first place) the enterprise needs to agree on desirable changes. Presumably these changes will move towards the ideal system. At this stage we go back and draw on the knowledge gained during the problem expression stage, particularly in understanding how proposed changes might affect and be affected by stakeholders. Changes which are not agreed on will not happen.
Finally, we need to implement the agreed changes. But even here the outcome is not predictable. Checkland sees implementation as a new human activity, so we can start the whole SSM process over again. It is unlikely that the final outcome will match the agreed change exactly. During implementation new compromises will need to be crafted.
You may wonder how an SSM project will ever finish. In one sense it is not meant to - SSM has a philosophy of continual improvement. But in another sense we hope for convergence. We hope that some of the issues agreed in the early stages will not resurface, that discussions arising during implementation will be more focussed as the participants' skills in SSM and understanding of the enterprise increase.
Soft systems methodology has many critics, both from the "right" and the "left".
Technically oriented critics complain that SSM doesn't actually tell you how to build a system, that there is no real method. A possible reply is that we have plenty of technology based methodlogies which don't work - what we need is a way of securing commitment and taking into account a variety of interests. Management oriented critics worry that the open ended nature of SSM makes it impossible to manage - Checkland himself has said that there is no way of telling whether an SSM project is a success or a failure. The same criticism applies to any prototyping or evolutionary approach - perhaps traditional ideas of project management just don't work for organisation change.
Radical (and traditional left) critics say that SSM assumes that all members of the enterprise have choice, in fact equal choice. The idea that managers and workers can openly discuss their probelms and needs is fanciful - SSM ignores issues of power. SSM supporters would reply that the very act of open discussion changes the organisational culture and empowers workers, though some would also argue for the rationalist "common good" view - "what's good for the company is good for the workers". Critics also argue that SSM involves manipulation by the consultants, that, like "human relations" management, can "trick" the participants into thinking they are happy with the consultant's hidden agenda. Further, critics claim, SSM imposes values of openness and "niceness" which are more suitable to middle class academics than to managers or workers. These criticisms do indicate that SSM has a fairly simple understanding of society.
Nevertheless, the use of "socially aware" methodlogies such as SSM has been growing gradually as people see that the outcome of "hard" systems approaches is seldom satisfactory to anyone.
Part of Lecture 4, 23/7/96.
Any questions or comments, just e-mail me.
This page is maintained by
Jim Underwood
who can be reached at
jim@socs.uts.edu.au.
This page was last updated on October 4th, 1996.
http://linus.socs.uts.edu.au/~jim/bpt/ssm.html
