Business Process Transformation - Spring 1996 Business Process Transformation - Spring 1996
The Viable System Model is based on work of Stafford Beer, continuing from the 1950s until the present. The basic style of this work is "systems approach" and it grows out of Beer's operations research background. A systems approach assumes (or claims to show) that all systems (things) operate according to some common fundamental rules, that analysis is usually best done from the top down, that the most fundamental rules deal with the dynamic interaction of a system and its component parts and that systems should be viewed "recursively", that is, that each part of a system can itself be studied as a complete system (and vice versa). The operations research background leads Beer to claim that the model is "really" mathematical (but expressed in diagrams for simplicity) and that as such it is logically necessary (must always be true) and can be rigorously (objectively?) applied.
The following sections on VSM are based on Beer's Diagnosing the System and Espejo & Harnden's The Viable System Model.
A viable system is defined as a system which is able to survive in a particular sort of environment. Survival here means maintaining many of its important features over the short term and some fundamental (identifying) feature over the long term. "A particular sort of environment" implies that there are some limits outside which the system may not be expected to survive (eg alien invasion) but that the system is able to deal with environmental changes of particular kinds (eg economic fluctuations, changes in government). A different way of putting this is that the system is able to change more slowly (or more quickly if it wishes) than its environment.
The position of "goals" in a viable system is interesting. Short term goals are continually set and met, but these are seen as contributing to the "higher" goal of viability or survival. Since all systems (disregarding the problem of infinity, which VSM does) are subsidiary to other systems any system will "inherit" goals from the next higher level system, but from the point of view of the current system these goals are constraints. (eg the goal of UTS is to survive, not to balance the budget or avoid annoying the goverment too much - these are constraints on survival). So from within a particular level system, goals are things which are handed down to the next level, not received from above.
But what is surviving? A viable system needs some form of identity, partly to unite the parts and give a sense of direction, and partly, from the observers' point of view, so that we will know what we are studying, what it is that might be remaining viable. If, for instance, UTS stopped teaching and research, and became a multi-media publisher, would it have survived? We need to understand some core activities or characteristics which give the system identity. These are somewhat like "goals", but closer to Checkland's root definition.
"the viable system produces itself". What does this mean? From the second law of thermodynamics (and experience) we know that any system left to itself eventually runs down or wears out. Viable systems are different. They "last longer", they are self-repairing. While in one sense these differences are a matter of degree (does a bishop last longer than a cathedral?) there also seems to be an absolute difference in the way viable systems work. An elephant and a bulldozer may be similar in size, weight, strength, speed, fuel consumption, waste production and even life span, but we imagine that the elephant is actively (if not consciously) looking after itself, while the bulldozer is unable to function without someone to fill its tank and change its oil, let alone drive it. The bulldozer does not look after its own survival, it does not "produce itself". (Some parts of the bulldozer, such as the electrical charging system, may be seen as viable, but not the bulldozer itself.) The purpose of the bulldozer depends on who owns or drives it, the purpose of the elephant is to survive (and reproduce - but that doesn't seem to come into the VSM). (cf "It's a bypass, it has to be built" [Douglas Adams, Hitchhiler's Guide to the Galaxy ] - the word "purpose" is used very loosely in the previous sentence.)
Survival, self-production and identity all depend on "coherence". That is, the various parts of the system must at some level (the system level) be working together. Since the parts themselves are viable systems and primarily interested in their own survival, the system structure must provide mechanisms for coherence, ways of encouraging the parts to work together. These structures for coherence are a primary focus of the viable system model.
As mentioned at the beginning of this page, almost all systems approaches treat systems recursively, that is, all systems have other systems as parts and are part of other systems. The VSM approach emphasises the need to consider system components at the appropriate level of recursion (both where they actually are and where they should be). For example, when thinking about UTS as a whole we should not be worrying about the content of paticular subjects. VSM also insists that each super- or sub-sytem, as we move through levels of recursion, should itself be a viable system. This is not easy. In the UTS example it is not obvious what the next viable level up is/should be. Is the "Australian Tertiary Education System" viable? Should it be? And going down, division into viable sytems does not always match the organisation chart. Some "parts" may be viable, others not. This is particularly a problem with "service" sections of the organisation - can the finance division ever be a viable system? - if not, where does it fit in?
The recursive level which we are currently considering is called the system-in-focus. In the following sections it is important to keep in mind that we are speaking about one recursive level - what is considered "operational" at this level may be considered "management" at a lower level, and "management" at the current level may be considered "operational" at a higher level. Moreover, every system described in the following sections will (or should) occur at every level of recursion.
When considering the system-in-focus we use the following basic model.
The operational system interacts with the environment to do certain things. The maangement assures that the right things are done.
The work of the operational system is done by a network of subsystems (system 1). The operational system also includes some local coordinating mechanisms (system 2). Management allocates tasks to subsystems and monitors performance (system 3), deals with environmental trends (system 4) and sets policy (system 5). There must be a way of bypassing the "proper channels" to warn of an emergency (the algedonic system).
The operational part of the system-in-focus consists of a network of subsystems. Each of these subsystems has an operational part interacting with its environment (part of our environment) and a management part with which our management system interacts, but at the current level we should look at each subsystem as a single unit (a "black box").
Each subsystem should be itself a viable system. A great part of the skill in designing a system is in choosing an appropriate division into subsystems - it should be possible to state simply what each subsystem does and it should be obvious how this contributes to the viability of the system as a whole. As previously mentioned, this causes some difficulties with "service" type subsystems as it is not always clear how they could be viable in their own right. This problem may be partly due to perceptions or inexperience at setting appropriate subsystem boundaries. In the case of a university, for instance, there is usually little trouble imagining the library as a system in itself, but the "computer centre" often causes difficulties. Some organisations try to solve the problem of service functions by outsourcing but there should be other solutions.
Traditional management practice might suggest that subsystems at a given level should be about the same size, but this is usually not a valid criterion. (Why is it so popular?)
With the operational system divided into viable subsystems management sets goals for subsystems and monitors whether these goals are achieved. This aspect of mangement is known as "system 3". Beer points out that since we assume the subsystems are viable the only monitoring information necessary is in principle a simple "yes" or "no". Exactly what should be done if the answer is no is not clear. In any case the amount of information sought should be kept relatively small so that system 3 will be able to handle it.
Beer also calls this information relating management to operations the "resource bargain" - ie management says to operations "I will give you these resources and in return you will produce these things".
System 3 is concerned with managing the internal system in the present.
Because system 3 can only (regularly) monitor a small number of "performance indicators" it relies totally on these being reported "correctly" by the operational subsystems of system 1. For various reasons (to maintain their own viability) subsytems may be tempted to report incorrectly, especially if things are going badly. To check normal reporting system 3* from time to time (preferably at random) will do a detailed check on one of the subsystems to see that it is reporting correctly. This is the "audit" function. Beer stresses that system 3* should only be used for checking, not as an extra channel for delivering new policy instructions. If these can't be coped with by system 3 there is something wrong with the overall design of the organisation. (So why do governments in particular appear to use audit style enquiries to "discover" new policies?)
The division of system 1 into subsystems assumes that the subsystems are totally independent, but of course they are not. While a good system 1-system 3 design might ensure that subsystems have compatible goals and are not competing for resources there will still be interaction where the environments of different subsystems overlap and where decisions of one subsytem affect the operation of others. Even if all subsytems strive to co-operate, if feedback about interaction comes only through the environment or management there will be delays which can lead to undesirable and possibly uncontrollable oscillation in the system. If, for instance, the School of Economics and the School of Accounting discover that they are both teaching Marxism for Business to fairly small classes, they may both decide to drop the subject next year and let their students take it in the other school; and in the following year .....
Since system 3 can't possibly monitor all such cases there needs to be some local co-ordinating mechanism among the subsystems. This is system 2. It may take the form of timetables, standards, committees or informal interaction. Again this system is for a particular purpose, and should not be used as a secondary channel for management policy directions. Note that in the traditional (military) organisational model system 3 is similar to "line" management while system 2 (and to some extent systems 3* and 4) correspond to "staff" functions. But in VSM these systems occur at all levels of recursion.
System 3 does not deal directly with the environment. Day to day interactions with the environment are handled by the subsystems in system 1. (Think about what this means as we recurse downwards - then look at the section below on recursion.) System 4 deals with the future environment. Depending on the level of recursion this may mean anything from strategic planning to predicting the most popular line of ice cream for next month, or even how long it will take to drive to the airport this afternoon.
An interesting feature of system 4 is this. Since the system is not merely interested in the environmental future out of curiousity, but needs to predict how the future environment and (our) viable system will interact, system 4 needs to include a model of the viable system at the current level of recursion. Hence system 4 includes a model of itself and so is reflexive. Among other things, system 4 is the system's mechanism of self-awareness.
System 5 is the "boss" system, the policy making system. This is where the final responsibility lies, but in a well designed system few decisions are made here. The decisions which do need to be made here concern how the operational system (system 1) should change its behaviour to deal with the changing environment. This is based on intelligence information about the environment (filtered through system 4) and control information about the operational system (filtered through system 3). These two sources of information need to be in balance, so as well as dealing with the information, system 5 needs to ensure that the systems which provide it are properly designed. (see p98 of Espejo)
But the decisions which get as far as system 5 will be those that haven't been prespecified by policy guidelines or subsystem goals, decisions which can't be rationally decided. System 5 must make a decision, even if it's to just wait and see. So these decisions are made according to cultural precedent, the personality(ies) of system 5, the "mood of the time" or something similar. This is how the "ethos" or character of the organisation comes into play. Beer calls system 5 a "variety sponge". All the things which can't be decided otherwise are decided here. There had better not be too many of them.
Finally, an emergency system is needed to bypass the "proper channels" when an unexpected disaster occurs - perhaps the computer room floods, someone goes crazy and starts taking hostages, or Frontline discovers salmonella in the hamburgers in the cafeteria. Top management needs to be informed at once and we need a special emergency channel for doing this. This is the algedonic system, similar to the system that warns me when I step on a piece of glass at the beach. It's not related to what I was thinking about at the time, but it suddenly takes top priority.
A misreading of the above sections could lead us to conclude that all the company "ethos", thought and decision making occurs at the "top", and that most of the organisation's co-ordinating activity and interaction with the environment occurs at the very "bottom" - a very elitist and perhaps ignorant organisation. But remember that we have only been dealing with one level of recursion, the system-in-focus. Beer claims that exactly the same model must apply at all levels of recursion. So even (or especially) at the lowest levels all seven systems are in operation. In fact the very lowest level would probably be a person (or a machine?) and all these systems will be operating within the one person. The window cleaner may have a number of more or less independent tasks to do (system 1) with some co-ordination (eg using the same chemicals for several tasks - system 2). They may set themselves time and chemicals to do particular tasks and informally monitor their performance (system 3) decide not to clean the windows today because it will probably rain (system 4) and decide not to remove the poster for the Freedom from Hunger Appeal (system 5). (I'm having a bit of trouble with system 3* in this example, but I'm sure it's there.)
So all these activities or going on throughout the organisation. A viable system is a very complex thing indeed. This can be seen from the diagram on p23 of Espejo.
As with most structural approaches to organisations, the VSM is a role based model. That is the components of the system (including the lowest level components, which are usually people) are considered only for their theoretical or desired behaviour. They are like machines, they only react, they don't have emotions. This could be regarded as a major flaw in the model; the justification is that all parts of the system have a common interest in its survival, and that it is in no one's interest to behave "irrationally". It is not possible to discuss the merits of such a philosophy here.
The VSM is also a true "systems" model, in that it emphasises the relations among system parts, rather than the behaviour of individual parts. While VSM still claims that the behaviour of the whole system can be explained rationally, this explanation lies mainly in the arrangement of parts rather than their individual behaviour (hence concepts such as "leadership" are not very relevant.
Systems are also seen as dynamic. Relations among parts are not just passive links, correlations of states. The links carry information, become active only under certain conditions, have characteristic capacities and can contribute noise or error. The system moves!
VSM is a model for management. While efficiency and effectiveness are considered in abstract terms, there is little discussion of what the system actually does (because firstly it must survive?). The concern is that whatever it is doing is properly managed. This is apparent in Beer's work over the years, where he has used the same model to study a great variety of different systems.
VSM begins with the real system structure, not the "official" structure. While there is an underlying feeling that formal structures are most useful if they reflect reality, the analyst deduces structure from observing real behaviour and considering what connections are used and need to be used.
This diagram shows a basic regulatory system. Ashby uses this to derive the "Law of Requisite Variety". (I am using different letters from Ashby's original diagram.)
The system (S) tries to produce the desired output (O) despite variations in the environment (E). The job of the regulator (R), which is really part of the system, is to help S maintain a steady output. It does this by monitoring E and taking appropriate action within S. For example, if you were inside your house and wished to keep dry (O) you (R) might see a storm (E) coming and decide to close the window. You can only maintain the desired output if you have appropriate counter measures for each action of E. (You might not know what to do if you saw a missile coming.) This means that R can only stay in control if they have at least as many different actions as E has. If not, some of the "disturbance" from the environment gets through. That is, the variety (deviance) of the outcome O is at least the variety of E minus the variety of R. This is the law of requisite variety.
In reality of course, the variety of E is massive, and R cannot possibly match it. What can be done? In fact, the variety must be filtered in some way. The following diagram from Espejo appears to show variety being reduced between the environment and an operational system, then again between the operational system and management. How is this possible?
Beer says "Managerial, operational and environmental varieties, diffusing through an institutional system, tend to equate; they should be designed to do so with minimal damage to people and to cost." [Diagnosing the System, p35]
This means that whatever happens management (say) can only deal with a certain variety. The rest could just be ignored, but that may be dangerous. The alternative is to reduce the variety in a planned way. This is done through attenuators and amplifiers.
Amplifiers increase our (the system, the management, whatever's on our side) variety. This can be done by getting someone else to do it, by designing and building (or training, or buying) agents. If I wish to place 100,000 leaflets in letter boxes by next week, I may be better to get 50 assistants rather than doing it myself. Similarly if I wish to interview 100 applicants for a job. From these examples, think of some problems with amplification.
If we extend the concept of amplification down several levels we get a classical organisation hierarchy. From the point of view of variety, this is an hierarchy of regulators. Beer points out (perhaps naively) that looking at hierarchies this way alters questions of autonomy vs control, decentalisation vs centralisation. The question is how should the appropriate variety be distributed - what will be decided at each level. This is a sensible point. The Law of Requisite Variety shows that it is impossible to centralise completely, while questions of identity and coherence mean that total decentralisation is not viable. Beer's naivity is in ignoring who decides which decisions will be handled at which level.
Attenuators are the reverse of amplifiers, so we like to apply them to the "opposition" (eg the environment). We have to deal with massive variety. Amplification may help, but another tactic is to simplify the problem. Some environmental actions (eg comet strike) are outside the limits of our viability, so we have to just hope they won't happen. Other possible environmental actions may be grouped together and dealt with as one. For example, we may decide to answer all student questions the same way, we may filter our e-mail, we may ask subsystems to report only if performance deviates from target by more than 5%.
These techniques allow us to build hierarchies of regulators to handle variety far outside our normal capacity. But they are not foolproof. Amplifiers may distort, they may misunderstand or ignore our signals. Attenuators may misclassify or fail to report significant events. These problems can arise both in the design and operation of amplifiers and attenuators. (Remember that, despite the pseudo-technical terms, we are usually talking about people or organisations.)
As an exercise, think about "one if by land, two if by sea" in terms of requisite variety.
Beer's way of applying VSM diagnosis seems to be a sort of flow analysis. At an appropriate level of recursion the component systems (systems 1, 2, etc) are identified and analysed to see if they are handling the correct type of variety, and if so, whether they have sufficient (or excess) capacity. This is similar to process modelling in BPR, but Beer assumes an hierarchy and deals with exceptional cases, while BPR concentrates on normal cases but claims to cut across the hierarchy.
To successfully perform Beer's diagnosis it is helpful to first undertake
a number of preliminary steps. These should be done at each relevant
level of recursion (usually starting at the top, but not
always).
Then go ahead and analyse the variety flows among the various systems (at this level of recursion).
An approach which builds on the VSM (but not in detail) can be found in Senge's Fifth Discipline. Senge's book was recently very popular and covers some aspects of BPR also, but unlike any of BPR, SSM or VSM, Senge focuses on the people in the organisation. Senge discusses four "core disciplines": personal mastery, mental models, shared vision and team learning. We may consider some aspcts of these later, but what is relevant now is the "fifth discipline": systems thinking. Senge's discussion is best summarised in the following diagram.
This diagram indicates that all complex systems operate on a balance of two types of feedback loops, positive (growth) and negative (stability). The secret of managing complexity is to make sure that we are worrying about the right loop at the right time. These loops can be found in the VSM in coordination (system 2) and in all other places where messages are passed up and down hierarchies (systems 3, 3* and 5) or where systems interact with the environment (systems 1 and 4). So Senge's view can add an extra level of sophistication to the VSM.
Part of Lectures 4 and 5, 23/8/96 and 6/9/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 September 4th, 1996.
http://linus.socs.uts.edu.au/~jim/bpt/vsm.html
