Content uploaded by Ilia Bider
Author content
All content in this area was uploaded by Ilia Bider on Aug 21, 2019
Content may be subject to copyright.
The final version of this paper has been published and copyright by Springer in LNBIP series
v. 352 pp.103-111, DOI: 10.1007/978-3-030-20618-5_7
Testing the Fractal Enterprise Model in Practice
Experience Report
Toomas Saaren*, Ilia Bider** and Erik Perjons**
*University of Tartu, Tartu, Estonia
**DSV - Stockholm University, Stockholm, Sweden
toomas.saarsen@ut.ee, ilia@dsv.su.se, perjons@dsv.su.se
Abstract. The paper is devoted to testing in practice a new kind of enterprise
model, called the Fractal Enterprise Model (FEM), that connects enterprise pro-
cesses via assets used for running these processes. Case study was implemented
for a larger manufacturing company that has a large repository of process models.
FEM was generated from existing repository data, elaborated and used for anal-
ysis. The paper presents lessons learned from the case study and could be useful
for a novice FEM modeler.
Keywords: fractal enterprise model, business process, business process model-
ing, process architecture
1 Introduction
The Fractal Enterprise Model (FEM) [1] presents an enterprise/organization as a net-
work of interconnected processes and assets. [1] suggests several areas where FEM can
be used in practice, most of them being related to organizational change, including a
radical one, such as business model transformation. Some examples of using FEM for
different purposes are presented in the literature [2,3]. However, these examples are
limited, and all of them were completed by the group that has developed the FEM
modeling technique. There is a need to gather more experience of using FEM for prac-
tical tasks, including its usage by experts outside the original FEM developers. Such
experience can help both disseminate and farther develop FEM technique.
In our case study FEM model was built for a larger company that has a large repos-
itory that includes over one hundred of models of their process. In this case, an idea of
deriving a FEM based on such a repository has been tested. A group of interconnect
processes has been chosen and a procedure of building a FEM from models of these
processes has been designed. A FEM was created based on the procedure that visually
revealed interconnection between the process in the group that was implicitly present,
but not revealed for the company's staff. The employees of the company found this
visualization quite useful as it gave a more holistic picture of this particular part of their
business.
The rest of this paper is written according to the following plan. In Section 2, we
give a short overview of FEM to give the reader a possibly to read this paper without
2
studying the papers where FEM was originally introduced. Section 3 and 4 present two
cases of building FEM. Each section present details of a business case, how the model
has been built, and for which purpose and it what way it has been used. Section 5 in-
cludes lesson learned including reflections on the challenges of using FEM technique
in practice.
2 Background – Fractal Enterprise Model
Fractal Enterprise Model (FEM) [1] includes three types of elements: business pro-
cesses (more exactly, business process types), assets, and relationships between them,
see Fig. 1, in which a fragment of a model for a management consulting company is
presented. Graphically, a process is represented by an oval; an asset is represented by a
rectangle (box), while a relationship between a process and an asset is represented by
an arrow. We differentiate two types of relationships in the fractal model. One type
represents 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 relation-
ship of a process changing the asset; in this case, the arrow points from the process to
the asset and has a dashed line. These two types of relationships allow tying up pro-
cesses and assets in a directed graph.
Fig. 1. A fragment of a FEM representing a management consulting company
In FEM, a label inside an oval names the given process, and a label inside a rectangle
names the given asset. Arrows are also labeled to show the type of relationships be-
tween the processes and assets. A label on an arrow pointing from an asset to a process
identifies the role the given asset plays in the process, for example, workforce, infra-
structure, EXecution Template (EXT), etc. A label on an arrow pointing from a process
to an asset identifies the way in which the process affects (i.e. changes) the asset. In
FEM, an asset is considered as a pool of entities capable of playing a given roles in a
given processes. Labels leading into assets from supporting processes reflect the way
the pool is affected, for example, a label acquire identifies that the process can/should
increase the pool size.
Note that the same asset can be used in two different processes playing the same or
different roles in them, which is reflected by labels on the corresponding arrows. It is
3
also possible that the same asset can be used for more than one role in the same process;
in this case, there can be more than one arrow between the asset and the process, but
with different labels. Similarly, the same process could affect different assets, each in
the same or in different ways, which is represented by the corresponding labels on the
arrows. Moreover, it is possible that the same process affects the same asset in different
ways, which is represented by having two or more arrows from the process to the asset,
each with its own label.
Labels inside ovals, which represent processes, and rectangles, which represent as-
sets, are not standardized. They can be set according to the terminology accepted in the
given domain, or be specific for a given organization. Labels on arrows, which repre-
sent the relationships between processes and assets, however, can be standardized. This
is done by using a relatively abstract set of relationships, like, workforce, acquire, etc.,
which are clarified by the domain- and context-specific labels inside ovals and rectan-
gles. Standardization improves the understandability of the models.
3 Case study – a large manufacturing company
3.1 Company and problem description
Harju Elekter has been manufacturing electrical equipment since 1968. Harju Elekter
Group has seven subsidiaries (fully owned); our case study was conducted at Harju
Elekter Elektrotehnika that produces equipment for power distribution networks, and
industrial control and automation systems for the energy and industrial sectors as well
as for public utilities.
Quality management of the company is based on process model built a number years
ago. Process model is decomposed into the six levels [4]; altogether, there are 260 pro-
cess models containing 1400 tasks in the repository [5]. Process diagrams follow
BPMN [6] format. Quality of the syntax and completeness [7] of the diagrams are rel-
atively good; validity (i.e. relation to the current state of the business) could be better,
which would require live update of the diagrams.
The area chosen for this case study was preparation for manufacturing a batch of
products. Every batch is unique and it is treated as a project that starts with client or-
dering a product (white shape “Ordering” in Fig.2), which in turn triggers the whole
process of batch manufacturing (final step is “Production”, highlighted with the white
shape in the right-upper corner in Fig.2). For production to go smart-free there is a need
to ensure that all resources needed, e.g. material or equipment, are available at the batch
start. There are two project phases to ensure resources availability: pre-planning, which
happens a couple of weeks before production, and operative planning to double check
availability of materials and resources before production, which happens a couple of
days before production.
From the process view accepted in the company, pre-planning and operative plan-
ning phases are not depicted as sub-process, but are spread between several processes,
as represented in Fig. 2. In the diagram in Fig. 2, there are 5 (sub-)processes (green
shapes) that include activities related to pre-planning and operative planning phases (at
4
the top of the diagram) and three other processes that indirectly participate in prepara-
tion of the batch: Purchase, Logistic and Stock Management, as shown at the bottom of
the diagram.
Fig. 2. Process diagrams and focus of the FEM
To represent the activities that are in focus of current study, but are spread between
the processes identified in the company process documentation, a different process
view is needed. For this purpose, we identify two sub-processes not presented as green
shapes in the diagram of Fig. 2. We introduced them in the diagram as oval magenta
shapes called Material Assessment 1, and Material Assessment 2. Dashed arrows from
the green shapes show which of these three original processes contribute to the newly
identified sub-processes.
Both planning phases are quite similar, but differ on the type of stock material as-
sessment is done and roles involved in them: Pre-planning is completed on the “vir-
tual” stock by Production Planner and Buyer (a role responsible for making purchases);
Operative planning is completed on the real stock by Production Supervisor (although
Production Planner and Buyer could be involved).
The focus of the pre-planning is on the forecast. The Production Planner has to match
material requirements from the product to be produced in the batch and the two weeks
forecast of the stock position; the Buyer has to match stock position and material pur-
chase and shipment. Moreover, the Production Planner cannot handle all details (mainly
risks) concerning purchase and delivery; the Buyer does not know all details about the
production and client behind the batch product.
There is no forecast during operative planning phase. The Production Supervisor
completes a similar process to pre-planning on the real stock. Any problem discovered
by Production Supervisor triggers tasks similar to the pre-planning process, the main
difference is that instead couple of weeks (as it was during pre-planning phase) there is
just a few days (sometimes hours) for resolving material delivery problems.
The first objective of the case study was to improve data context for material assess-
ment in pre-planning process in order to provide better information to Production Plan-
Pre
planning
Operative
planning
Stock
management
Purchase
Logistics
Ordering Production
Material
Assessment
1
Material
Assessment
2
5
ner and Buyer when they work on the forecast. In this objective, the focus of the mod-
eling was on analyzing and improving the quality of data and data exchange (Material
Assessment 1 in Fig.2.). The second objective of the case study was related to the ma-
terial assessment in operative-planning – how to produce an adequate, i.e. prompt, re-
sponse to the problems discovered by Production Supervisor under Material Assess-
ment 2 (see Fig. 2).
3.2 Building and using FEM
When applying FEM concepts and graphical presentation in this case, the focus of what
is the object (or subject) of modeling has been changed in comparison to the original
idea behind FEM [1]. Originally, FEM presents relationships between the process types
(ovals), and "global", i.e. organization-wide, assets that are needed for uninterrupted
starting and finishing process instances. In the current case, FEM was built to highlight
the relationship between the sub-processes related to one production batch and thus can
be considered as part of the whole manufacturing process. The instances of these sub-
processes produce and use assets that we can call "local", i.e. assets related to a partic-
ular instance of one (sub-)process or connected instances of different (sub-)processes.
The model as-is for this case is presented in Fig. 3. It was built mainly based on the
information from the process model repository of the company which has been created
and is maintained using a software tool called Conciliate 2c8 [8]. The process diagrams
in the repository contain various context elements (called assets in FEM) related to the
tasks of processes [5], in particular: related actors (represented by swim-lines in pro-
cess diagrams); related data elements (represented as Documents and Information Sys-
tems in process diagram); related materials (represented as Materials in a process dia-
gram).
Data was exported from five process models/diagrams (highlighted with green arrow
shapes in the previous figure, Fig 3). Based on the exported data, two contexts related
to two material assessments from Fig. 2 were modeled and analyzed in Fig.3.
Green rectangles in Fig. 3 identify roles that participate in a process; they have ap-
proximately the same meaning as a workforce in the original FEM.
Blue rectangles in Fig. 3 identify local assets of the type data; they do not have direct
analogous in the original FEM.
Yellow rectangles in Fig. 3 identify communication assets produced in one sub-pro-
cess and consumed/used in another sub-process.
A dashed arrow directed to a local asset in Fig. 3 shows the sub-process that gener-
ates this asset. A solid arrow from an asset points to a sub-process that uses this asset.
Thus the arrows have the same meaning as in original FEM.
Red arrows in Fig. 3 identify that local assets connected by them are produced and
consumed to handle exceptions/deviations that occur during the preparation of a
batch.
The first draft of FEM that we got with the formal procedure described above contained
several redundancies and some incorrectness: several tasks not relevant for our con-
sideration were automatically included in the model; some context elements were
6
missing (as they were not included in the process diagrams); some errors in the pro-
cess diagrams were imported to our FEM (these errors, mainly, concerned relations
between Tasks and Documents; in addition, a couple of semantic errors).
The improvement of the first FEM draft was completed in the following fashion.
Firstly, we merged/grouped some tasks to diminish the number of oval nodes in FEM.
In the terms of process architecture [4], we moved up about one level, i.e. from level 6
to level 5. In addition, we eliminated tasks not directly related to our consideration (e.g.
Stock management and Book-keeping).
Secondly, we improved the context representation related to the sub-processes.
Namely, missing context elements were added, and few errors that had been discovered
were eliminated.
Also, the layout of FEM has been changed so that the horizontal dimension started to
highlight time-axes and vertical dimension represent parallel sub-processes. As we can
see in Fig. 3, a general strategy of a layout is similar to a typical process diagram.
However, arrows have different meaning: instead of a showing the sequence of execu-
tion, they connect sub-processes to the related context elements (local assets).
After introducing the improvements, we had a separate discussion with employees
participating in business activities. The primary goal was to improve communication
between parallel sub-processes. We analyzed what information (local assets) is pro-
vided to actors and whether this information is sufficient for completing activities. The
analysis showed that the informational assets provided to the parallel sub-processes
where not equal. For example, while the Production planner participating in Material
Assessment had knowledge on the product related to the batch under preparation, while
the Buyer participating in Delivery Confirmation did not have this information. The
difference resulted in misunderstandings that were solved in erratic email communica-
tion.
Fig. 3. FEM diagram (As-Is) for the industry case.
7
Based on the analysis, an attempt has been made to redesign the local assets for the sub-
processes to make it more unified so that parallel sub-processes would have the same
informational assets in their disposition. The redesign resulted in a to-be FEM presented
in Fig. 4. The new aggregated local informational assets are encapsulated in red squares
in Fig. 4. These were design according to the following principles:
Order of Materials and Table of Assessed Orders were transferred from the as-is
model in Fig. 3.
Essential data concerning purchase and logistics, Stock View, were provided for Pro-
duction Planner completing Material Assessment.
Data concerning the product and project (batch), Project View, were provided for
Buyer completing Delivery confirmation.
Missing material e-mails were substituted by common view called Adjustments to
be made in the project plan.
Providing a richer set of informational assets simplifies communication and makes sub-
processes implemented in parallel to run smoother.
Similar changes were proposed for the operative-planning phase (completing a few
weeks later) where Material Assessment will be implemented by Production Supervi-
sor. If problems appear (Material Problem - some materials are not delivered in the
stock and production cannot start), then Product Planner and Buyer will be involved to
solve the delivery problem, using the same data context they are familiar with (used
already during the pre-planning phase). These changes are expected to produce more
effect on the overall effectiveness, as there is much less time to solve the material prob-
lems before the batch starts in comparison to pre-planning.
Fig. 4. FEM diagram (To-Be) for the industry case.
8
4 Lessons learned
A FEM model does not need to deal only with global assets as it was discussed in [1].
A FEM can be created to show relationship between the sub-processes and local assets.
This can be especially useful when analyzing interdependent sub-processes completed
in parallel. FEM provides a holistic view on the interconnections and gives a possibility
to analyze dependencies and communication between different sub-processes. The re-
sulting diagram helps to elaborate on informational assets used by different actors
working in parallel.
A FEM concerning local assets can be created from an existing business process
model repository; a modeler gets a basic set of elements and relations related to the
topic of interest of process analysis. Additional elaboration is needed to finish the mod-
eling task, but a significant amount of information for building the model can be ob-
tained without additional investigation.
The primary challenge for the modeler having an experience of process modeling
(using BPMN) is the similarity of two different types of diagram. The difference lies in
the meaning assigned to arrows. Arrows bring out a timeline in workflow-orient process
model; while in FEM arrows shows interconnections between processes and assets. It
takes some time to get used with two diagrams where nodes are similar, but arrows
emphasize different aspects.
References
1.
Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development.
Software & Systems Modeling 16(3), 663
–
689 (2017)
2.
Bider, I., Perjons, E.: Defining Transformational Patterns for Business Model Innovation. In
: Perspectives in Business Informatics Research: 17th International Conference, BIR 2018,
Stockholm, Sweden,
LNBIP, vol. 330, pp.81
-
95 (2018)
3.
Josefsson, M., Widman, K., Bider, I.: Using the Process-
Assets Framework for Creating a
Holistic View over Process Documentation. In : Enterprise, Business-
Process and
Information Systems Modeling, Stockholm, Sweden, Springer, LNBIP, vol. 214, pp.169-
183
(2015)
4.
Dumas, M., La Rosa, M., Mendling, J., Reijers, H. A.: Fundamentals of business process
management. Springer (2013)
5.
Elias, M., Johannesson, P.: A survey of process model reuse re-positories. In : Internati
onal
Conference on Information Systems, Technology and Management, Springer, pp.64-
76
(2012)
6.
Chinosi, M., Trombetta: BPMN: An introduction to the standard. Computer Standards &
Interfaces 34(1), 124
-
134 (2012)
7.
Lindland, O. I., Sindre, G., Solvberg,
A.: Understanding quality in conceptual modeling.
IEEE software, 11(2), pp. 11(2), 42
-
49 (1994)
8.
2Consiliate Business Solutions: 2c8 Modeling Tool. Available at:
https://www.2c8.com/en/
products/2c8
-
modeling
-
tool/