The Viable Systems Model is based on 5 systems which are seen as
fundamental to viability. If all 5 systems are working well within you organisation, then you can say that the basic functions needed for viability are present. If they are not, then your organisation is not viable in the terms defined in this pack, and you will need to change your organisation to ensure viability. The purpose of the Preliminary Diagnosis is to identify the 5 systems needed to ensure viability, and to draw them on a large VSM diagram which represents the parts of your organisation in its totality. If any are not present, they will need to be designed and added to your organisational structure. If any existing parts of your organisation do not fit into one of the 5 Systems, then they are not crucial for viability and may be unnecessary. |
He was telephoned one morning in connection with the proposed amalgamation of several businesses into an alliance designed to enable the member companies to combine their strengths, and thus compete more effectively in exporting their products. The group had done some preparatory work, but needed advice quickly. A meeting was scheduled for 2.00 pm that afternoon.
Usually, a consultant needs several days to assess the situation and
gather the background which is essential for sound advice.
This was clearly impossible.
So, GB arrived for the first meeting with a large piece of paper on which was drawn the outline of the VSM, that is the Operational units and Systems 2, 3, 4 and 5.
As the meeting proceeded, he began to ask questions about the proposed organisation and to fill in the boxes in his VSM diagram. Operational units: the member companies. And so on.
After the proposed organisation had been described, some of the boxes were empty and GB began to probe "How do you intend to ensure that the member companies work together in a more effective manner - won't you need someone to examine the various possibilities and to look for synergy?"
Basically, he was looking for something to write in the System 3 box.
This is the essence of the Preliminary Diagnosis. You define a function, look for the bits of your own enterprise which does it, and write it in on the relevant part of the diagram.
The VSM is so thorough in its model of how a business works, that GB's clients were overwhelmed with "his" insight and made aware there were several aspects of the organisation they had completely overlooked.
And all of this without any preparation.
In your case, assuming you are looking at an existing business, the insights are unlikely to be so staggering. Problems with viability will have arisen and been dealt with, and somewhere the functions needed for viability will have been implemented. The question is - are they adequate?
But whatever the context, you will be mapping your own organisation onto a VSM diagram, and this process is bound to affect the way you look at your enterprise.
PURPOSE: | To clarify the boundaries of the System-in-Focus. |
During the diagnosis which follows, there are times when it's easy to lose track of exactly what is being studied. So its essential to begin the Preliminary Diagnosis with a clear statement of the organisation (or the parts of the organisation) you are looking at. Throughout this guide, this will be referred to as the System-in-Focus. |
|
Before starting the Diagnosis and the identification of the systems needed for viability, you should list all the parts of the System-in-Focus as you see them.
The list should be exhaustive as it will be referred to throughout the Preliminary Diagnosis. It will contain the Operational parts, the accounting functions, the management functions and so on.
In compiling the list, keep one eye on your sketch of the various recursions and ensure that the items on the list refer only to the system-in-focus. It's likely that your first list will need revision and that one or two items will belong to another recursion. Check it carefully.
As the Preliminary Diagnosis proceeds, you will be able to take the items on your list and allocate them to one or other of the 5 systems within the Viable Systems Model. Thus, the list will gradually disappear.
If your organisation is perfectly Viable, the list will disappear completely and there will be 5 well defined systems giving the basis for viability.
If not, either
PURPOSE: | To depict the overview of your System-in-Focus in its totality. |
The diagnosis of your organisation will proceed by drawing a large diagram which will represent your System-in-Focus as a whole system. At this stage, the outlines of the three main parts of the VSM - Operation, Metasystem and Environment - will be sketched in. Between them they represent the overview of your System-in-Focus in its totality.
The diagram represents your system-in-focus interacting with its
environment. The Operation carries out the system's basic activities. It will consist of several Operational units. It is the muscles, the production units, the parts that generate wealth. The Metasystem is there to provide a service to the Operational units. It is there to hold the organisation together. It is the brain, the regulator, the management. The details of the what goes on within each of these three shapes will be filled in as the diagnosis proceeds. The job at this point is to draw the VSM in outline as an overview of your system-in-focus interacting with its environment.
|
|
Notes:
PURPOSE: | To specify those parts of the system-in-focus which undertake System One (primary) activities. |
The first system in the Viable Systems Model is the entire Operation which will be composed of several Operational units.
The Operational units undertake the System-in-Focus's basic activities.
They will all be (smaller) Viable Systems in themselves, and thus must be able to maintain a separate existence.
System One generates wealth and in a business, each element can be considered as a profit centre.
If you are a manufacturing business, System One is the production units, the teams of people and machines which actually do the manufacturing.
If you are a programming co-op, System One is the programmers or teams of programmers, perhaps divided into various specialist areas.
If you are looking at a more complex organisation, you may have a System One which includes manufacturing, distribution, and warehousing.
System One sounds straightforward, but is actually one of the most difficult areas to define clearly. For example, in the examples given above the computer department was a System One in the programming firm, but the computer department in the manufacturing company would have a support role and would therefore not be part of System One. Some people who are in basically service areas such as engineering maintenance may consider themselves important enough to be System One.
The question is: are they part of what the organisation is really about, or are they back-up, facilitators, or support? If the answer is the latter, then they do not qualify as System One.
You are now in a position to go back to the original list of jobs carried out by your System-in-Focus, and to list those which between them make up System One.
Note: Each Operational unit is a VSM at the next recursion down and thus will include both the physical aspects and the management of one aspect of the Operation. So, for example, the trucks and drivers and the management of the transport department are found within that Operational Unit.)
This diagram shows the VSM with three Operational units
high-lighted.
There is no reason why you should have three, although it is unlikely that you have more than eight. The diagram also shows the parts of the environment which are specific to the Operational units. |
|
SYSTEM IN FOCUS: Suma Natural Food Wholesalers
MISSION: Warehousing and Distributing Natural & Ecological products.
Note 1: | Whatever the nature of the Operational elements, each will have its specific bit of the external environment which it interacts with regularly. | |||||||
Note 2: | The details of the environments given above are by no means exhaustive. The more detail the better. | |||||||
Note 3: | At this stage, the diagnosis takes no account of the interactions between the Operational units and environments. This comes later. |
PURPOSE: | To identify those parts of the System-in-Focus which ensure that the Operational units interact in a stable manner. |
Anyone who's had the misfortune of trying to ride a bicycle with a buckled wheel down a steep hill will know how an unstable system can behave, and why the consideration of stability criteria is an essential part of any design.
Instabilities between people are just as universal. Look at young children in the playground, or marital break-down, or the way communes inevitably collapse.
Nation States exhibit extreme instabilities, the arms-race being the most concerning outcome.
But whatever the particular case, the need for some way of dealing with instabilities is essential, otherwise the organisation will shake itself to pieces.
The argument goes:
The motion of the pallet was exactly like a yo-yo, or in Beer's terms it was oscillating due to conflicting interests between Operational elements.
The resolution of this problem was to get the operators from each floor to meet, to discuss the problem and then to resolve it: "Look someone has to agree to take this pallet and its definitely nothing to do with me - I only do beans and grains." "Yes, but you're the only one with enough spare space ... my floor's too full already" Eventually agreement was reached, the pallet was found a home and the oscillation stopped.
A general strategy for System Two in this context would be a series of rules for allocating pallets. If it were thorough enough, oscillations would be rare.
Beer lists many examples of instabilities in industry which lead to oscillations. One of these came from his observation that the stocks of raw materials in a production shop vary dramatically. Sometimes they run so low that everyone is worried that they will run out, sometimes they are so high that the available space runs out and storage becomes a problem.
The stock levels oscillate between these extremes. Again a System Two needs to be designed to stabilise this situation, for example Just In Time ordering, which keep inter-process stocks to a minimum.
In some cases System Two may be a nuts-and-bolts system like a production schedule or a timetable which will ensure that conflicts do not arise as several parts of an organisation are all clamouring for the same resources.
In other cases, System Two may be more subtle. In Mondragon the predominant System Two was the methods they employed to share resources and support each other's businesses. My attempts to find out how they deal with conflicts between competing businesses were always answered with "but we share all profits anyway ... why should there be a problem?" In the case studies which you read you will notice that System Two in a co-operative is generally covered by the "co-operative ethos." It seems clear that in an organisation in which the common good is paramount, instabilities will be fairly easy to resolve.
If the company ethos is competitive, if your success is measured against the performance of others, then it's much more likely that your interests will be exactly the opposite of others. So the temptation will be to act in such a way that your successes will bring about others' failures. And of course everyone else is doing the same.
Obviously, a co-operative will not be completely free of this kind of thing: there is only so much money to spend and the various Operational elements will compete for it. Some people are naturally competitive. Cash flow will need to be controlled. The financial System Two will have to be designed.
However, in most of my applications, working within a co-operative ethos means that there is already a pervasive System Two, and this gives the System two designer a head start.
Every organisation must have a System Two:
The diagram to the right shows the VSM with System 2 added (in
green).
Note that System Two is part of the Metasystem (it sits in the diamond) and that it passes through every Operational unit. Thus, it looks at the entire collection of interacting System One units with a view to resolving conflicts, dealing with problems and creating stability. System Two has been drawn slightly larger than usual for emphasis. |
|
|
Examples of System Two are as follows:
The weekly Rota allocates members to various jobs according to departmental needs, and thus stabilises the problem of too many people in one area and not enough in another.
There must be good cash flow control, thus stabilising the tendency for huge surpluses and overdrafts.
The recent stock-control system stabilises stock holdings and avoids an oscillation between vast stocks and goods going out-of-stock.
It takes care of double-booking, and resolves the conflict of several teachers all wanting the same rooms, projectors etc., etc.
PURPOSE: | To identify those parts of the System-in-Focus which optimise the interaction of the Operational units, and to update the VSM diagram accordingly. |
Each person with a bucket is an Operational unit. Each will be absorbed with his own job.
The Metasystem - which may be one person sitting on the top of a ladder - will look at the whole system and may say "Keep to the left on the way down" (System 2 - stopping continuous collisions) or it may think about optimisation.
Eventually she may realise that if everyone forms a chain and moves the buckets from hand to hand, then you only have to move the water and buckets, and not your own body weight. The same job can be done, but only a fraction of the energy needs to be expended.
The extra efficiency which is generated as a consequence of acting as a whole system rather than an un-coordinated collection of parts is called synergy, and the generation of synergy is the essence of System Three.
The current task is to describe the ways that System Three functions within a viable system.
System Three is best thought of in the middle of a whole lot of
activity. All around it the Operational elements are concerned with
meeting the demands of their own environments (answering the phone,
getting the orders completed on time, scheduling the trucks ...) and
interacting with each other.
System Three sits right in the middle of all this activity, thinking about ways of optimising the whole thing.
|
Although this depicts nicely the relationship between Systems Three and One, it's a bit messy, and leave no room to illustrate the interactions between System Three and the rest of the Metasystem.
So it's usually drawn above a stack of Operation elements like this:
This diagram shows the VSM with System 2, reduced to fit into the
Metasystem's diamond and outlined, and a large System 3 added for
emphasis.
It's shown interacting with three Operational elements, although not as clearly as in the first diagram. This arrangement has much more in common with the human System Three - the base brain - which sits on top of the spinal column and optimises the working of the muscles and organs. |
We can now begin to describe the ways in which System Three over-sees the collection of Operational elements, looking for synergy.
This requires System Three to look at the whole of System One, and to allocate resources so as to optimise performance.
Thus System Three may say: "Your job is to get the goods to the customers in the most effective way, and we will give you £200,000 a month to do it. And as long as you do the job properly, you will continue to get the money."
Obviously this will require lots of negotiations between all the Operational units and System Three, and it leaves System Three with enormous amounts of flexibility to generate synergy "Hmmmm .... if I put a few more resources into production they say they can be 17% more efficient. But that will mean cutting back on procurement and cut our margins by 1.52%. On balance that looks fine ...a much better allocation of resources."
In a team, the resource bargain is more likely to involve allocation of people. "You do this and I'll do that, and things will work better ..." In a jazz band it could be allocation of time "The sax solo went on longer than expected, I'll cut down my break on keyboards."
But whatever the particular example, manipulation of the resource bargain provides a means of optimisation.
Thus the Operational elements must be accountable: they must be able to show that everything is proceeding as agreed with the Metasystem.
This is an essential aspect of the resource bargain; it's the way the Operational element demonstrates that it can justify the continuing allocation of resources from System Three.
The human Viable System has without doubt the most thorough network for demonstrating that all is going well. Every part of the body sends continuous messages to the base brain which knows just what's going on in real time. During periods of intense activity, this information is used by the base brain to modify the flow of adrenaline to the organs and muscles to optimise their operation.
Beer's design for an equivalent system in an enterprise is based upon near real-time monitoring of all System One activity and a set of statistical filters assessing the information. The System Three office would have a big green light or a continuous tone which would mean "everything is OK". As soon as any of the measurements moved outside acceptable limits, the light would go off, and other signals would identify the source of the problem.
But whatever the design, the Operational units must have a way of justifying their allocation of resources.
Clearly, there must be rules in place to deal with this. In certain situations System Three has to be given the mandate to intervene within an Operational element.
For example, if the information shows that productivity is down, wastage is up and morale has collapsed, then it's essential for System Three to intervene. Intervention means loss of autonomy and is only permitted when the cohesion of the whole system is at risk.
Intervention rules must be defined clearly, so that each Operational element knows it will be left alone unless it transgresses the agreed norms.
All of this needs careful design.
Beer has a simple recipe for deciding on the level of autonomy which can be allocated to an Operational element . He says autonomy should only be forfeit when system cohesion is at risk. So, if the actions of one Operational unit threaten to shake apart the whole system, its autonomy must be forfeit. In all other cases it should be left to function within the resource bargain - it is, after all, designed to be autonomous.
However, here we have a case in which the Operational Units, conceived as working with maximised autonomy, must obey a higher authority.
System Three will ensure they pay taxes and stick to legal guidelines on (for example) Heath and Safety and employment.
System Three will also ensure that the Operational elements stick to company Policy, regardless of the financial advantages. This may concern equal opportunities, or remuneration or a commitment to give money to charity.
Some years ago a Suma member suggested that we set up a separate department staffed mainly by part time labour from the job centre. Figures suggested we could make money this way (labour costs were significantly below usual levels) but the proposal was well outside our Policies on employment and pay. Corporate Suma said no.
It's job is to provide whatever information is needed to complete the model which is needed by System Three.
It's inevitable that System Three will encounter situations in which it just doesn't have enough information to know what's going on. Regardless of the kind of information it may need, this is the job of System 3*.
It may involve a study on buildings or machines or on the incidence of back injuries or on any aspect of the goings-on within the Operation.
System 3* is often referred to as looking for signs of stress. In the original physiological model System 3* was based upon a nerve called the vagus which reports back to the base brain on signs of stress in muscles and organs.
In the VSM this function has been extended to give System 3* the job of topping up the information needed by System Three.
System Three is concerned with improving the overall performance of System One, so its main job is optimisation. In simple terms, System 2 deals with problems between the Operational units (its function is stability) whereas System Three makes positive suggestions as to ways of improving overall performance.
In order to do this, System Three allocates resources of people and money. It may see that by cutting back in one area and by re-allocating those resources in another, the overall performance may improve.
System Three needs to know how each Operational unit is doing, so it can continuously re-think its own plans in the light of changing circumstances. It therefore needs the Operational units to be accountable. Ideally, System Three will have a complete and up to date model of everything it needs to know about System One.
From time to time System Three will need further information about the Operation and will ask to do audits and surveys.
And finally, System Three must have the ability to intervene within an Operational unit if it believes that unit is threatening the viability of the whole system.
This diagram shows the VSM with System 2, reduced to fit into the
Metasystem's diamond and outlined, and a large System 3 added for
emphasis.
Again note that System Three is part of the Metasystem, and that it has connections with every Operational unit. System Three surveys the entire collection of interacting Operational units, and looks for ways of generating synergy, of optimising their interactions. |
|
Note: Remember this is the Preliminary Diagnosis which is concerned only with the identification of the five Systems. So the job at this point is only to specify which parts of your enterprise do System Three stuff. The lines which you have drawn are to sketch in the connections between System Three and the Operational units. Later all of these interconnections will be dealt with in more detail, but it's far easier to build up a framework for the entire system-in-focus, before delving into the way the five systems interact.
The personnel budgets are decided in a similar way. Departments are asked how many people they can manage with, and this is optimised.
Accountability is very patchy. There is no standard departmental system to account for how the budgets are spent. Major mistakes are obvious anyway, but regular quantified reporting has yet to be established.
Audits are common and emerge from areas of interest. How much are we spending on back treatment? What skills do we have that are unused? Do we need to rotate jobs more regularly? Reports will be produced and the subject discussed.
Intervention rules have still to be defined. In theory a department could become inefficient (especially in slack times) and no-one would know. Thus an acceptable lower performance level and intervention rules are not possible.
There are many examples of how this is carried out.
PURPOSE: | To identify those parts of the System-in-Focus which are concerned with Future plans and strategies in the context of environmental information. |
An example: a company may have one year of its lease left. A number of possibilities are available: it could re-negotiate, the lease move to another rented site, buy an existing building or build a new one. Each of these options needs to be researched in some depth, and the most likely alternative selected. Throughout this process, System 4 must be referring constantly to System 3, to ensure that the Operational constraints are considered. How many square feet? How much head room? Access to motorways? How much office space? Any specialised manufacturing facilities?
Clearly, when System 4 has recommended a number of options, it will require site visits from System 3, and the interchange of ideas will continue.
(Remember, this is about the System-in-Focus, not about the embedded S1 Viable Systems ...
You may find that there is no focus for System 4 in your organisation. In the co-ops I've worked in, this kind of activity is usually undertaken as a last resort.
The Viable Systems Model asserts that for this function to work properly it must have a continuous focus: somewhere in the System-in-Focus someone must be looking at the environment and thinking about ways of dealing with a largely unknown future.
In the following section, you will find an exercise concerning System 4, and a worked example. When you have completed it, you should have a good idea about the System 4 activities which you organisation ought to be undertaking. When its finished, you should think about the question posed on this page: (What is System 4 in your structure?) and decide whether you think it can do the job of continuously adapting to the future.
The list refers to the System-in-Focus. Go thorough it and identify the items which refer to the embedded System One Operational elements. (Example: For Suma relocating refers to the System-in-Focus. Replacing a Fork Truck refers to the Warehouse which is System One) Cross out everything which belongs in System One. They will be dealt with at the next level.
The areas of overlap indicate how the various issues relate to each other, and the bit in the middle which has three areas overlapping (the move, new machinery, relationship with major customer) is the centre of real concern about the future.
Each shaded area indicates where collaboration may be needed.
You will probably need to re-draw this diagram several times.
If the diagram you drew has no areas of overlap, then something should be done. It means that the members of your organisation concerned with future planning are working in isolation, and this is obviously not a good idea.
However it is not uncommon for Research and Development to become obsessed with technological issues and to ignore Market Research. And for Corporate Planning to degenerate into purely economic terms which pay little heed to R & D and Market Research.
ACTIVITY | RESPONSIBILITY | TIME-SCALE | PRIORITY |
Move to Halifax | Me | C (current) | A |
Relations with Suma | All | C | A |
New Machines | Me | 1 year | C |
Selling Old Machines | Me | 6 months | D |
Looking for new Business | All | 1 year | D |
Packing for Co-op Federations | All | 3 years | E |
There were several more entries but they seemed to fall into four categories. After a few attempts the diagram looked like this.
The diagram shows the VSM with Systems 1, 2 and 3 in outline and a
large System 4 right in the middle of the Metasystem.
It also shows that part of the external environment which is the specific area of interest for System 4, some of which is unknown. System 4 also has to be in touch with the internal part of the VSM via System 3. |
|
Examples of System 4 are as follows:
Mondragon has built its own R & D facility.
It is in touch with those aspects of its external environment which may exhibit novelty (e.g. European Space Project).
It is currently looking seriously towards the unified European market in 1993 and planning accordingly.
PURPOSE: | To identify those parts of the System-in-Focus which are concerned with Policy. |
Policy concerns the ground rules which affect everyone in an organisation.
In the Viable System, policy is the domain of System 5. It may best be described as "Top Level Ethos", and its role is to become involved in the complex interactions between Systems 3 and 4.
System 5 has two main functions:
Firstly, to supply "logical closure": The loop between systems 3 and 4 is potentially unstable and must be overseen Metasystemically.
Secondly, to monitor the goings on in the whole organisation. These must be constrained by policy.
There is, of course, nothing to stop System 5 wielding its own authority (for example ... demanding that System 4 begins to study a particular issue and that System 3 responds to this ... and that the eventual outcome is passed to the Operational units to be elaborated into a production plan) but this is a rare occurrence.
System 5 provides the context, the ground rules, the ethos.
Who is System 5???
If your mind works like most of us the answer to this question will be something like Henry Ford or Walt Disney or some other hero who dominates the policy of the enterprise. (Any colour as long as it's black ...). Beer has written at length about the way that all elements of the Viable System are mutually dependant, and that giving one any more importance than another is clearly wrong. (How viable would Aristotle have been if any of his major organs had closed down??) The question of who System 5 actually is has to be answered very simply as everyone involved in the system. At the governmental level it should be described as "the Will of the People", within the co-op it's the same and systems must be designed to ensure that's how it works. (Again notice that Mondragon seem to have grasped the essence .. they describe their General Assembly as "The Will of the Members").
At Suma, the Hub/Sector system evolved to provide a means of ensuring that policy can involve all members on a continuous basis. To my knowledge this is the only System 5 which works in this way with large numbers: usually systems will involve a few meeting a year.
The diagram shows the VSM with Systems 1, 2, 3 and 4 in outline and
with System 5 shown as a large box right at the top of the picture.
System 5 is concerned with policy, with establishing the context within which the whole organisation can function.
|
|
Examples of System 5 are as follows:
System 5: Small Co-opWeekly meeting of all members
System 5: SumaWeekly meeting of delegates representing the views of all members.
System 5: MondragonYearly meetings of all members, or of representatives.
System 5: Traditional CompanyEither the owners or shareholders. No employee involvement. |
The picture to the right brings all the diagrammatic elements
together. It shows the five systems and the connections with the
external environment.
|
|
You have also put all of this together on a large VSM diagram, which will give a picture of your System-in-Focus in its totality.
Now cross out those parts of your organisation which appear on the VSM from your original list.
Remember to be clear about the System-in-Focus. Anything about the internal workings of the Operational elements should not appear on this diagram. (So .. in Suma's case .. the optimisation techniques used within each department don't appear. They are the concern of the next (smaller) level of organisation. The boxes 2, 3, 4 and 5 refer to the whole of Suma.)
If you can't put anything in some of the boxes, you are in the same position that I was. There was effectively no System 4, except when it was unavoidable, at Suma.
At this point you should take some time to consider the implications of the preliminary diagnosis.
Some of the five functions will be performed by people or departments which clearly don't have the resources to do the job adequately.
In some cases the entire Metasystem will be performed informally, and that may be fine (See Case Study on HWMC).
There will be some jobs which are left on your list after filling in the VSM. Are they necessary? Some will be support jobs, like machine maintenance. The computer department is a facilitator, which makes things happen more smoothly and quickly. Both these jobs are clearly useful.
But what about some of the committees? Are they really essential to viability?
At the end of this process you should have
This concludes the Preliminary Diagnosis.
HTML version constructed by John Waters at the Llanidloes Resource Centre. Last modified 30th October 2005.