ChapterPDF Available

Testing the Fractal Enterprise Model in Practice: Experience Report


Abstract and Figures

The paper is devoted to testing in practice a new kind of enterprise model, called the Fractal Enterprise Model (FEM), that connects enterprise processes via assets used for running these processes. Case study was implemented for a larger man-ufacturing company that has a large repository of process models. FEM was gen-erated from existing repository data, elaborated and used for analysis. The paper presents lessons learned from the case study and could be useful for a novice FEM modeler.
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,,
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
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
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
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
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-
Ordering Production
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-
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
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
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-
Fig. 3. FEM diagram (As-Is) for the industry case.
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.
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.
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)
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)
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-
Dumas, M., La Rosa, M., Mendling, J., Reijers, H. A.: Fundamentals of business process
management. Springer (2013)
Elias, M., Johannesson, P.: A survey of process model reuse re-positories. In : Internati
Conference on Information Systems, Technology and Management, Springer, pp.64-
Chinosi, M., Trombetta: BPMN: An introduction to the standard. Computer Standards &
Interfaces 34(1), 124
134 (2012)
Lindland, O. I., Sindre, G., Solvberg,
A.: Understanding quality in conceptual modeling.
IEEE software, 11(2), pp. 11(2), 42
49 (1994)
2Consiliate Business Solutions: 2c8 Modeling Tool. Available at:
... This work is the first in a series where we offer a relatively formal comparison of the FEM technique with other techniques that (a) can be used for representing an organization as an interconnected set of processes, or (b) the models built with these techniques could be used as a source of information for building a FEM for a particular business case, as in [5]. More specifically, this work is devoted to comparing FEM with IDEF0 [2], which on a high level can be used for representing interconnections between various business processes in an organization. ...
Full-text available
The paper presents a comparison of two modelling techniques that can be used to describe an organization as an interconnected set of business processes. The first technique is called Fractal Enterprise Model, which is an invention of the authors of this paper. The second technique is a well-established technique, IDEF0, normally used to present a functional decomposition of an enterprise. The comparison is done based on building a simplified ontology for each technique using UML class diagrams, after which a mapping is established between the concepts of the two ontologies. The discussion that follows analyzes how much of a model designed using one technique can be represented using the other, which is illustrated by an example.
Full-text available
The pace of changes in the business environment in which a modern enterprise operates requires the enterprise to constantly review its business models in order to survive and prosper in the dynamic world. This exploratory study investigates how to help the enterprise to innovate their business models based on the concepts of fractal enterprise model and transformational patterns. The paper suggests an approach to Business Model Innovation (BMI) where the focus is on transformational patterns. It discusses the structure of such patterns, and based on examples, it presents an approach on how such patterns can be derived from cases of completed business transformations.
Full-text available
Paper is in open access: This paper suggests a new type of enterprise models called fractal enterprise models (FEM), with accompanying methodological support for their design. FEM shows interconnections between the business processes in an enterprise by connecting them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (employees, business process definitions, etc.). A FEM model is built by using two types of patterns called archetypes: a process-assets archetype that connects a process with assets used in it, and an asset-processes archetype that connects an asset with processes aimed to manage this asset (e.g., hiring people, or servicing machinery). Alternating these patterns creates a fractal structure that makes relationships between various parts of the enterprise explicit. FEM can be used for different purposes, including finding a majority of the processes in an enterprise and planning business change or radical transformation. Besides discussing FEM and areas of its usage, the paper presents results from a completed project in order to test the practical usefulness of FEM and its related methodological support.
Conference Paper
Full-text available
When an organization has not adopted a uniform and standardized way of producing and storing process documentation, keeping track of and maintaining process documents can be a real challenge. In this paper we suggest a framework for organizing process documentation which is created in different notations, for different purposes, and stored in different formats. We show how this framework has been applied in a real case in an organization where such problems are present. We discuss advantages and disadvantages of the framework and suggest further development and testing of the framework to improve its usability.
Full-text available
With the increasing focus on early development as a major factor in determining overall quality, many researchers are trying to define what makes a good conceptual model. However, existing frameworks often do little more than list desirable properties. The authors examine attempts to define quality as it relates to conceptual models and propose their own framework, which includes a systematic approach to identifying quality-improvement goals and the means to achieve them. The framework has two unique features: it distinguishes between goals and means by separating what you are trying to achieve in conceptual modeling from how to achieve it (it has been made so that the goals are more realistic by introducing the notion of feasibility); and it is closely linked to linguistic concepts because modeling is essentially making statements in some language
Business Process Management (BPM) is the art and science of how work should be performed in an organization in order to ensure consistent outputs and to take advantage of improvement opportunities, e.g. reducing costs, execution times or error rates. Importantly, BPM is not about improving the way individual activities are performed, but rather about managing entire chains of events, activities and decisions that ultimately produce added value for an organization and its customers. This textbook encompasses the entire BPM lifecycle, from process identification to process monitoring, covering along the way process modelling, analysis, redesign and automation. Concepts, methods and tools from business management, computer science and industrial engineering are blended into one comprehensive and inter-disciplinary approach. The presentation is illustrated using the BPMN industry standard defined by the Object Management Group and widely endorsed by practitioners and vendors worldwide. In addition to explaining the relevant conceptual background, the book provides dozens of examples, more than 100 hands-on exercises – many with solutions – as well as numerous suggestions for further reading. The textbook is the result of many years of combined teaching experience of the authors, both at the undergraduate and graduate levels as well as in the context of professional training. Students and professionals from both business management and computer science will benefit from the step-by-step style of the textbook and its focus on fundamental concepts and proven methods. Lecturers will appreciate the class-tested format and the additional teaching material available on the accompanying website
Conference Paper
Business process modeling is a complex, time consuming and error prone task. However the efforts made to model business processes are seldom reused beyond their original purpose. Rather than modeling of business processes from scratch, analysts can drive process models, by redesigning the existing ones. A repository is, therefore, necessary to store and manage process models for future reuse. In this paper we, discuss requirements for a process model repository that would support reuse of process models, review existing process model repositories based on the requirement. Finally we analyse and point out major challenges of existing repositories that affect reuse. This survey will be a base to develop the future efficient searchable, user-friendly, useful and well-organized process model repositories.
The Business Process Model and Notation (BPMN) is the de-facto standard for representing in a very expressive graphical way the processes occurring in virtually every kind of organization one can think of, from cuisine recipes to the Nobel Prize assignment process, incident management, e-mail voting systems, travel booking procedures, to name a few. In this work, we give an overview of BPMN and we present what are the links with other well-known machineries such as BPEL and XPDL. We give an assessment of how the OMG's BPMN standard is perceived and used by practitioners in everyday business process modeling chores.