How to Make Viable System Model More Understandable

Abstract

Though Viable System Model (VSM) has been invented for several decennia ago, it is still not widely use in practice. One of the possible reasons for this is that the formal structure of an organization very rarely, or may be never corresponds to the VSM prescribed structure. This confuses novices and results in erroneous VSM models. To make VSM more understandable to a wider circle of enterprise modelers, we suggest using it in a combination with the Fractal Enterprise Model (FEM). FEM represents an organization as an interconnected set of processes and assets; relations between the two are of two types: assets are used in processes-workforce, infrastructure, etc., while processes manage assets-acquire, maintain and retire. The idea is that based on FEM, it is easier to understand which business activities belong to which VSM systems/units, as it can be done without considering the administrative structure of the company. Keywords: viable system model, VSM, fractal enterprise model 1 The Problem Viable System Model (VSM) proposed by Stafford Beer [1] suggests that for an order to be viable, an organizational (i.e. socio-technical) system needs to have a proper struc-ture/architecture. Viability here is considered as a property of a system to survive and prosper in the dynamic environment. VSM prescribed relatively decentralized architecture that consists of 5 so-called systems numbered from System 1 to System 5, and additional mechanisms, such as System 3* and algedonic signals to manage exceptions and unexpected perturbations in the system's internal and external environment, see Fig. 1. The VSM architecture is recursive, meaning that the operational units of the lower level, from System 1, on their own should be viable systems with the prescribed structure having all 5 systems inside them. Several decennia have passed from VSM first appearance. Though, there are a number of experts in the management world that successfully use VSM in practice, especially for systems diagnostics, the model has not got substantial spreading among the management practitioners. Even in the academia, VSM is not widely used in research and teaching, though there are a relatively large body of publications related to VSM. We believe that one of the reasons that hinders adoption of VSM in practice and academia is its seemingly strong focus on the structure of a socio-technical system, and

Full text

How to Make Viable System Model More
Understandable
Ilia Bider and Erik Perjons
DSV - Stockholm University, Stockholm, Sweden
{ilia|perjons}@dsv.su.se
Abstract. Though Viable System Model (VSM) has been invented for several
decennia ago, it is still not widely use in practice. One of the possible reasons for
this is that the formal structure of an organization very rarely, or may be never
corresponds to the VSM prescribed structure. This confuses novices and results
in erroneous VSM models. To make VSM more understandable to a wider circle
of enterprise modelers, we suggest using it in a combination with the Fractal En-
terprise Model (FEM). FEM represents an organization as an interconnected set
of processes and assets; relations between the two are of two types: assets are
used in processes - workforce, infrastructure, etc., while processes manage assets
- acquire, maintain and retire. The idea is that based on FEM, it is easier to un-
derstand which business activities belong to which VSM systems/units, as it can
be done without considering the administrative structure of the company.
Keywords: viable system model, VSM, fractal enterprise model
1 The Problem
Viable System Model (VSM) proposed by Stafford Beer [1] suggests that for an order
to be viable, an organizational (i.e. socio-technical) system needs to have a proper struc-
ture/architecture. Viability here is considered as a property of a system to survive and
prosper in the dynamic environment. VSM prescribed relatively decentralized architec-
ture that consists of 5 so-called systems numbered from System 1 to System 5, and
additional mechanisms, such as System 3* and algedonic signals to manage exceptions
and unexpected perturbations in the system’s internal and external environment, see
Fig. 1. The VSM architecture is recursive, meaning that the operational units of the
lower level, from System 1, on their own should be viable systems with the prescribed
structure having all 5 systems inside them.
Several decennia have passed from VSM first appearance. Though, there are a num-
ber of experts in the management world that successfully use VSM in practice, espe-
cially for systems diagnostics, the model has not got substantial spreading among the
management practitioners. Even in the academia, VSM is not widely used in research
and teaching, though there are a relatively large body of publications related to VSM.
We believe that one of the reasons that hinders adoption of VSM in practice and
academia is its seemingly strong focus on the structure of a socio-technical system, and

paying less attention to its other components, e.g. people, tasks, technology. This cre-
ates some confusion among inexperience people in their first encounter with VSM.
More specifically, they are trying to see the VSM systems and units in the official or-
ganizational structure of divisions, departments, labs, boards of directors, etc. While
this may help when designing a VSM model of a big international enterprise, it will not
work for a small company, e.g. a family business, which does not have any official
organizational structure. The confusion of the above sort was part of the authors’ own
experience of studying VSM; it was also observed in the MS students who studied VSM
under the guidance of the first author.
Fig. 1. VSM model, adapted from [2]
2 The Suggested Solution
As was highlighted in Section 1, the confusion when studying and using VSM arises
from the seemingly strong focus on the organizational structure. On a deeper level,
VSM is not tightly connected to the formal organizational structure, but to the nature
of actions completed inside each of its systems or units. Therefore, the focus when
studying and using VSM should be moved from the formal structure, to the activi-
ties/task completed inside each system or unit. This will move attention to another com-
ponent of a socio-technical system – tasks – in order to understand a real, sometimes
informal, structure of the organization. For example, the tasks/activities completed by
units of VSM System 1 are directed at delivering value to its customers (external envi-
ronment), while the tasks/activities of System 3 are directed at delivering resources, the
System 1 needs to complete their operations.
The difference between formal and informal structure when building a VSM is
known and its being highlighted by several authors, see, for example [2]. However, the

guidelines on how to differentiated tasks/activities that belong to different VSM sys-
tems still remain vague, at least for inexperience novice modeler. To facilitate the task
of detecting the VSM structure of a company independent of its size, we suggest using
another kind of enterprise modeling, the one which focuses on business processes that
run inside the organization. More specifically, we consider using our Fractal Enterprise
Model (FEM) [3] for this end.
FEM includes three types of elements: business processes (represented as ovals),
assets (represented as rectangles), and relationships between them (represented as ar-
rows), which is illustrated in Fig. 2. The relationships are of two types. One type rep-
resents a relationship of a process “using” an asset; in this case, the arrow points from
the asset to the process and has a solid line. The other type represents a relationship of
a process changing the asset; in this case, the arrow points from the process to the asset
and has a dashed line. A process that has an external beneficiary is called primary; a
process that is aimed at managing an asset is called supporting
Fig. 2. A fragment of FEM
The idea of using FEM for understanding what is included in each of the VSM systems
is as follows. A primary process belongs to System 1 and represents one of its units on
some level. A supporting process of type Acquire belongs to the management, i.e. can
be included in one of the upper systems from 3 to 5. For example, hiring new employees
in Fig. 2 belongs to System 3, while acquiring new product design belong to System 4
(development). In a full paper, we plan to give a more detailed view of which kind of
the processes belong to which VSM systems.

References
1.
Beer, S.: The Heart of Enterprise. Wiley (1979)
2.
Hoverstadt, P.: The Viable System Model. In : Systems Approaches to Managing Change: A
Practical Guide.
Springer, London (2010) 87
-
133
3.
Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development. SoSyM 16(3), 663
–
689 (2017)