Content uploaded by Ilia Bider
Author content
All content in this area was uploaded by Ilia Bider on Jun 07, 2019
Content may be subject to copyright.
The final version of this paper has been published and is copyright by Springer in LNBIP, vol.
352, https://link.springer.com/chapter/10.1007/978-3-030-20618-5_24
Evaluating Usefulness of a Fractal Enterprise Model
Experience Report
Ilia Bider*, Arian Chalak**
*DSV - Stockholm University, Stockholm, Sweden
**Försäkringskassan, Sweden
ilia@dsv.su.se, arianchalak@gmail.com
Abstract. The paper presents an experience of evaluating the usefulness of a par-
ticular modeling technique called Fractal Enterprise Model (FEM). FEM con-
nects enterprise processes with assets that are used in and are managed b y these
processes. The evaluation has been conducted in a somewhat unusual manner. A
model that covers an essential part of an enterprise's activities has been built with-
out any practical goal in mind, e.g. finding a cause of a problem, designing or
completing a transformational change, etc. Then, it was presented to and dis-
cussed with the stakeholders that helped to build it. During the discussions, the
stakeholders were asked to elaborate on the potential usages of the model in the
practice of the enterprise. The result was a comprehensive list of possible usage
of the model.
Keywords: fractal enterprise model, business process, business process model-
ing, process architecture, experience report, evaluation, usefulness
1 Introduction
This paper reports on the experience of a project aimed at evaluating usefulness of
Fractal Enterprise Model (FEM) [1] for practical purposes. FEM presents an enter-
prise/organization as a network of interconnected processes and assets. From one point
of view, FEM can be considered as a model that expresses business process architecture
[2,3], as it shows interconnection between different business process that exist in an
organization/enterprise. From the other point of view, FEM can be considered as an
enterprise model (or an enterprise architecture [4]) in line with other enterprise models,
e.g. Viable System Model (VSM) [5], work systems framework [6], or Business Model
Canvas (BMC) [7], as it shows connection between the processes and enterprise's tan-
gible and intangible assets (resources in the terminology of other modeling techniques).
The objective of the project was threefold:
1. Introduce modeling technique into a company. This was to be done by creating a
model of the company business and then present it back to the company.
2. Find out new application areas for FEM, beyond those that were theoretically iden-
tified in [1], and partly investigated in other works, e.g. [8].
3. Test whether FEM can be built by a novice modeler in practical settings.
2
The objective has been achieved in a somewhat unusual manner. In normal practice, a
model is being built for some specific practical task, e.g. building an IT system to sup-
port a process, educating new members of staff, finding a cause of a problem or a solu-
tion when the cause has been identified. Having a practical task in mind is quite justi-
fiable, as building a model requires resources from the stakeholders when collecting
data on which to build a model. People need to be interviewed, documents related to
the object of modeling need to be provided, observation of activities need to be allowed,
etc. Providing these resources without having any practical task for which the model
should be built might be difficult to justify. However, in the case described in this paper,
we were lucky to obtain permission to use the resources for creating and discussing our
model without having a practical task to complete.
The strategy we used in this project was: (a) build a model based on information
obtained from different groups of stakeholders, and (b) present the model to each stake-
holders group separately and discuss for what purposes this model can be used in the
enterprise. The goal with building the model was to show to the stakeholders its capa-
bilities. As FEM is aimed at visualizing the interconnections between the enterprise
business processes and its assets, this general goal was translated into discovering rep-
resentative for the company business processes and assets and presenting as much in-
terconnection between them in the model as it was possible to discover. As the project
had limited resources, in terms of time and access to the information, there was no
attempt to build a full model of the whole enterprise.
An organization, for which a FEM has been built is a typical IT solution provider
that develops, supports, maintains and operates IT solutions for their customers. The
team who created a model consisted of an MS student – the second author who did all
fieldwork, and his thesis supervisor who guided the work via meetings held through a
video conferencing system. The first member of the team had minimal experience of
modeling in real practice in general and building FEM models in particular, though
FEM was included in one of the courses the second author took. He also did not possess
any domain knowledge, so the IT solution provider business was new to him. The sec-
ond member of the team, supervisor, has an intimate knowledge of FEM as being one
of the authors of the modeling technique, has long experience of building models of
various types in practical settings, as well as he has knowledge of the IT solutions pro-
viders business in general, being for a long time engaged in such business personally.
The composition of the team allowed us to include the third goal in the project's
objective, namely, "to test whether FEM can be built by a novice modeler in practical
settings".
The plan of first building, and then showing the model was successfully imple-
mented, though some stakeholders were a bit suspicious about the project as they did
not understand the goal with the project. The second part of the project showing to and
discussing the model with the stakeholders gave interesting results in both showing new
areas of application of FEM, and providing a more specific form for those areas that
were predicted in [1].
The rest of this paper is written according to the following plan. In Section 2, we
present a short overview of FEM to give the reader a possibility to read this paper with-
out studying the papers where FEM was originally introduced. Section 3 presents the
3
business case, i.e. necessary information on the IT-provider, and the ways of how the
FEM model has been built. Section 4 presents and explains the FEM model. Section 5
presents the stakeholders' views on how the model can be used in practice. Section 6
summarizes the findings.
2 Fractal Enterprise Model
As was mentioned in the introduction a Fractal Enterprise Model (FEM) belong to the
class of enterprise models and thus has some common features with other modeling
technique, and tools in this category. A full description of FEM, including its relation-
ships with other enterprise modeling techniques and tools is presented in journal paper
[1]. The latter has also explanation of why the model has been called fractal. The goal
of this chapter is only to give the basic notions so that the reader does not need to
become acquainted with [1] before reading this experience report.
FEM includes three types of elements: business processes, assets, and relationships
between them, see Fig. 1 in which a fragment of a model is presented. The fragment is
related to a business case considered in the next sections, and it will be explained in
more details in these sections. 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 relationship 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 processes and assets in a directed graph.
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 how the process affects (i.e. changes) the asset. In FEM, an asset
is considered as a pool of entities capable of playing given roles in 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.
4
Fig. 1. A fragment of a FEM representing a process from our case study
5
Labels inside ovals, which represent processes, and rectangles, which represent assets,
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 represent the
relationships between processes and assets, however, can be standardized. It 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 rectangles. Stand-
ardization improves the understandability of the models.
While there are many types of relationships that show how an asset is used in a
process (see example in Fig. 1), there are only three types of relationships that show
how an asset is managed by a process – Acquire, Maintain and Retire.
To make the work of building a fractal model more systematic, FEM uses archetypes
(or patterns) for fragments from which a particular model can be built. An archetype is
a template defined as a fragment of a model where labels inside ovals (processes) and
rectangles (assets) are omitted, but arrows are labelled. Instantiating an archetype
means putting the fragment inside the model and labelling ovals and rectangles; it is
also possible to add elements absent in the archetype, or omit some elements that are
present in the archetype.
FEM has two types of archetypes, process-assets archetypes, and an asset-processes
archetype. A process-assets archetype represents which types of assets that can be used
in a given category of processes. The asset-processes archetype shows which kinds of
processes are aimed at changing the given category of assets.
3 Project Overview
3.1 The Business Case
As was already mentioned in the introduction, this research has been completed at an
IT Solutions Provider, which we refer to as ITSP in the rest of the text. Organization-
ally, ITSP is a local office of a large national concern that has many offices around the
country. It works quite independently serving their customers but uses some services
provided by the central office. ITSP develops, supports, maintains and operates IT so-
lutions for their customers. The company has few significant customers for which it
develops and operates solutions. Thus, their sales process is more directed at getting
more orders from the existing customers than acquiring new customers.
3.2 The Project Strategy and Plan
As follows from the introduction, the project strategy was straightforward; the project
plan consisted only of three steps presented in Fig. 2. At the same time, this strategy
was a bit unusual. The project was not connected to any specific practical task, like a
problem to solve, challenge to meet or improvement to introduce. Still, it required re-
sources from the company for all three steps, like time for answering interview ques-
tions, time to participate in the presentations, and time for understanding the model and
6
providing feedback. All these resources were requested without promising anything
particular in return.
Fig. 2. Project plan
As was already mentioned in the introduction, all field work of building and presenting
FEM has been done by the second author. The information for building a model has
been gathered from different sources, such as interviewing people that play various
roles in the processes, reading the documentation, and making observations while par-
ticipating in the meetings of the software development team.
Navigation through the information sources was done according to the internal re-
cursive structure of FEM. When a process of interest had been identified, a process-
assets archetype, such as the one presented in Fig. 3, was used to produce a set of ques-
tions that needed answers, e.g. who participate in the process (workforce), what tools
(information & technical infrastructure) are used in it, what templates/guidelines/meth-
ods steer the process (EXTs -execution templates), etc. These questions were answered
by interviewing the participants, who in turn could also point to other people partici-
pating in the process to be interviewed. Thus, a snowball-like method guided by arche-
types was used for building the model.
Fig. 3. A generic process-assets archetype (adapted from [1]).
As the time frame for the project was limited, there was no possibility to build full FEM
of ITSP; thus only a limited, but an essential fragment of FEM has been built. It includes
one primary process – IT Solution delivery, and one supporting process that belongs to
a category of sales processes, called Offering Development. The first process delivers
value to the customers for which they are ready to pay; that is why it is called primary
in the FEM terminology of [1]. The second process aimed to get orders for the first
process from the existing customers; that is why it is called supporting in the terminol-
ogy of [1].
Building FEM Presenting FEM to
stakeholders
Recieving feedback
on the areas of use
for FEM
Generic process
Workforce Tech&Info
Infrastructure Organizational
Infrastructure
EXT Partner Stock
7
4 Fractal Enterprise Model of ITSP
4.1 FEM of a Primary Process
FEM for the primary process - IT Solution Delivery - is presented in Fig. 4. The process
includes both developing and delivering solutions. The model has been built using a
web tool called InsightMaker [9]. Though this tool is not designed for FEM diagram-
ming, its expressive graphical power is enough for many FEM diagrams.
The root of FEM in Fig. 4 is an oval representing the primary process; the assets
connected to it with the solid line arrows represent the assets that are used in this pro-
cess. There are many assets of the same type, i.e. assets that are connected to the process
with arrows that have the same labels. To make a diagram easier to grasp, assets are
grouped. Each group is represented by a visual element of InsightMaker called folder.
A folder is a group of visual elements that can be exploded or collapsed. As can be seen
in Fig. 5, an arrow can be drawn between a folder and a process. This arrow means that
each asset in the folder is connected with the corresponding process using the same type
of arrows like the one which goes from the folder.
Fig. 4 presents many assets that are used in the process of IT Solutions Delivery. It
took quite some time to identify and group these assets. The three groups of assets -
Software Environment, Basic Software Platform, and Advance Software Platform - rep-
resent environment/platform/tools used for solution development and employment.
They are connected to the process by arrows labeled as Tech. And Info. Infrastructure.
The fourth group connected by an arrow with the same label – Standardized Tools rep-
resents tools used to arrange the work of process instances of the primary process -
actual projects that produce and deliver solutions.
The group called Process Templates is connected to the primary process by an arrow
labeled EXT (EXecutable template). The group contains assets used for guiding differ-
ent phases of process instances; each asset includes descriptions of routines used in the
corresponding phase.
The group Software Development Team includes several assets that represent various
roles people play in solution development and delivery. The group is connected to the
primary process with an arrow labeled Workforce; each asset in this group represents a
particular category of participants of the development and delivery process. These par-
ticipants were the primary source of information for building the model. Representa-
tives of each group were interviewed as well as their meetings were observed. Note that
an arrow that leads from this group to the process has a diamond start. The diamond
start means that an asset or group represent a stakeholder of the process, which accord-
ing to [1] warrants a special kind of acquiring archetype to be used when expanding
this node.
The group, IT solutions Projects Orders, is connected to the primary process with
the arrow labeled Stock. The stock of orders is an essential asset that ensures that the
primary process can be run repeatedly. The stock always needs to be filled up, and this
is a responsibility of another process discussed in the next section. The orders group
consists of four different types of project orders, as shown in Fig. 4.
8
Fig.
4
.
FEM
of the main process
9
Customer is an asset that fulfills two functions. Firstly, the customer functions as a
beneficiary for the process. Having a beneficiary, somebody who gets value from the
process for which the company can get paid is mandatory for a primary process. Sec-
ondly, the customer actively participates in the process, thus fulfilling the role of Part-
ner. Both arrows start with the diamond pointing out that this asset is of stakeholder
type.
The last asset represented in Fig. 4 is Customer opinion on the quality of delivered
software. It is not an asset needed for running the primary process, but an asset that is
acquired and maintained by the process, which is represented by dashed arrows in Fig.
4. This asset is needed for another process, the one which is discussed in the next sec-
tion. This asset belongs to the particular type of intangible assets that represent the
opinion/reputation of some kind. Dashed borders highlight such assets.
For each asset represented in Fig. 4, there exist processes that manage it, e.g. hiring
and training people, creating and maintaining platforms, etc. These are not represented
in Fig. 4, except the ones that manage execution templates. The management processes
for the templates are presented explicitly to mark that these processes do not run by the
local company, but by the central office of the whole concern.
4.2 FEM of a Sales Process
The model for a sales process is presented in Fig. 1. The process belongs to supporting
processes, more precisely it is a process the goal of which is to get new orders from the
existing customers; this is why it is called Offering Development. This process serves
as an acquire process for a group of assets IT Solutions Orders, which is represented
by a dashed arrow from the process to the asset in Fig 1. All other assets connected to
the root process in Fig. 1, are assets that are used in the process.
As we see from Fig. 1, customer is an essential asset that functions as a partner in
developing new offers which it then accepts. Customer opinion is also a valuable asset
that makes the customer trust the companies even when all details of an offer are not
completely clear. Workforce is represented by a group of assets that includes several
roles. These are marked by a yellow background, which means that they also participate
in other processes presented in Fig. 1; the cases of repetition are denoted by a light-
yellow background. The offering process uses a number of Offering templates that are
being developed and maintained by the central office. Tech. & Info. Infrastructure is
represented by a group of assets that includes Project management tools and CRM of-
fering tool.
As can be seen from Fig. 1, an important asset for the offering development process
is a stock of suggestions. The stock is filled by two different processes Field based
discovery and Life cycle management. Both are connected to asset Suggestions via
dashed arrows labeled as Acquire. The Workforce for the first process is the Solution
development team, the same as identified in Fig. 4. The idea is that the team should
come with suggestions for new projects based on their knowledge of the existing sys-
tems and their communication with the customers. Though this source to generate sug-
gestions is very important, there are no standardized working procedures on how this
10
process should work. The latter is depicted in Fig. 1, by asset Templates under devel-
opment which is connected to the discovery process by an arrow labelled as EXT (Ex-
ecution template).
The second process that generates suggestions, Life cycle management, is based on
the idea of each product (solution) having a natural life cycle. The suggestions are made
to move the product to the next phase of the cycle, e.g. enhance the functionality, or
create a new version. One of the sources of enhancing and improving the products is
New trends and ideas coming from the ideation process. Life cycle management uses
Road map and Business plan templates for guiding the process of generating sugges-
tions. Three roles are included as Workforce for this process, these roles also participate
in the offering development process itself.
4.3 Connecting the Models
After both models for the solution delivery and offering development had been com-
pleted, they were integrated to give a holistic view of the company's activities. This
view is presented in Fig. 5, where the left-hand side represents the primary process, and
the right-hand side represents the sales process. The most important common assets are
represented once and connected to nodes on both sides. To these belong Customer,
Customer Opinion, IT solution project orders and Software development team. Other
assets that are included in both sides are represented by green background in the left-
hand side and light green background in the right-hand side. In addition the yellow
background is used in the right-hand side to show the assets that are used in several
processes on this side. Again, the light color is used to indicate the second (or third)
occurrence of the asset. Note also, that some groups of assets on the left-hand side are
collapsed and do not show all details that can be seen in Fig. 4.
5 Stakeholders Views
After the model had been built, it was separately shown to and discussed with different
stakeholders. Below, we summarize the feedback received from them. The summary is
structured according to the issues named by various stakeholders. The summary below
does not give all the details of the input, only the most important issues named by the
stakeholders.
5.1 Assets Management
The FEMs produced, especially the one on Fig. 4, turned out to be the first visual re-
pository of all assets used in the organization. This repository, which also shows the
interconnection between assets, can be used for different purposes listed below. The
purposes in the list were mentioned by different stakeholders, each giving a feedback
from the perspective of his/her roles.
11
Fig. 5. An integrated FEM
12
1. The assets map could be used for ensuring that each project, which is an instance of
the primary process, has all assets needed for its completion assigned to it. Fig. 4
lists all assets that potentially can be required for the completion of various projects.
Each project may use some of these assets, but not the others. It is important to iden-
tify the assets needed for a particular project from its beginning by picking them
from FEM. It came from the Project manager point of view. To make it work, a tool
is needed that could help "instantiation" of FEM for a particular project (process
instance).
2. The assets map can be used for risk management to ensure that each asset is respon-
sible for having it in order. It came from the Risk manager point of view. To make
the connection between the assets and responsible persons, the FEMs presented in
Fig. 1, 3 and 4, should be extended with assets management processes and their
workforce assets.
3. As FEM shows all usages of each asset, it can help in optimizing the asset usage on
the company level. For example, if the need for a specific human asset becomes
lesser, FEM can help to identify where else this asset can be used, instead of firing
people. This suggestion came from the Project manager.
4. An enhanced FEM is Fig. 4 can be used for ensuring that the sizes of assets that
represent various categories of specialists in IT solution team match the needs. This
will require adding numerical values showing the sizes of various assets and con-
necting HR processes, e.g. hiring and training, to the model that should take into
accounts these values. This suggestion came from the Software developers.
5.2 Holistic View on the Company's Activity
A FEM that includes a number of connected processes can be used as a visual repre-
sentation of how the company works. This can be used for a number of purposes, ex-
amples of which are presented below.
1. It shows to a member of staff his/her responsibilities and also responsibilities of
his/her colleagues. This can help in educating the employees and creating a common
view of the company and how it operates. This kind of usage was mentioned by
several roles, such as the Project manager and Software developers.
2. It shows all the places where a particular asset is engaged, which can help in planning
changes, especially changes that concern updates of software related assets, e.g. an
Oracle database. For this purpose, having separate maps of assets attached to various
projects would be helpful. It will allow finding all instances that use a specified asset
and calculate the impact of its change on each particular instance. This suggestion
came from the Solution architect.
5.3 Process Development and Improvement
As well as being a repository of assets, FEM can be considered as a repository of the
company's processes. This repository can be used for a number of purposes, examples
of which are presented below.
13
1. It is important to have EXTs for each process, as a process without EXTs will be run
in an ad-hoc manner, which may affect both efficiency and effectiveness of the com-
pany. Also, each process template needs to have its managing processes and respon-
sible persons for them. Missing this part in the organization may result in that the
templates are never updated, thus resulting in them being not used in practice. FEM
can both point to the processes without templates, and templates without proper man-
aging processes and responsible persons. This suggestion came from the Project
manager.
2. FEM shows the connections between various processes, which can help to avoid
each process being handled in isolation. The latter may result in improvement (e.g.
optimization) in one process decreasing the effectiveness of the company instead of
increasing it. This suggestion came from the Product solution manager.
5.4 Field Based Discovery
Many stakeholders provided feedback related to a particular area of the FEM on Fig.4,
namely around the process called Field based discovery, which is one of the sources
for generating suggestions for Offering development. The feedback related to this pro-
cess came from the Product solution manager (in fact, most of his feedback was asso-
ciated with this issue), Project manager and Software developers.
All stakeholder considered that FEM in Fig. 5 highlights the importance of Field
based discovery and the need to involve in it the software development team fully. FEM
in Fig. 5, shows that the IT solution development process requires orders from the cus-
tomers. Otherwise, the development team will have nothing to do. At the same time
creating these orders requires help from the developers, as they meet the customers and
can obtain information about their needs that might be missed by the sales executives
and managers. FEM also shows that the process does not have EXTs, which creates
confusion among the developers. They are asked to participate in the process, and they
are willing to do so, but there are no clear guidelines of how to do this.
In general terms, this particular usage falls in the categories already discussed in the
previous sections. However, we decided to address it separately, as it seems to be one
of the major issues in the company. Also, this issue is of importance not only for this
particular company but can be found in many consulting companies that have similar
problems with the engagement of consultants and developers in sales.
6 Lessons Learned
On the whole, the strategy accepted for this project proved to be successful. It was
possible to build a model without having a specific purpose and present it to stakehold-
ers for discussions and reflections. It showed that the stakeholders fully understood the
model and were able to reflect on it, which allows to conclude that the first goal of our
project, i.e. introduce FEM to the company has been successfully achieved. One of the
significant factors that contributed to the success was that the model presented to and
discussed with the stakeholders was not abstract, but showed their business activities,
14
and in a visual way. This prompted a chain of ideas related to the problems and chal-
lenges each stakeholder experienced in his/her work.
The discussions with the stakeholders and their reflections also revealed a number
of possible usages of the model in the organization, which was the second goal of our
project. The areas of usage suggested by stakeholders are listed in Section 5. They fall
into general categories discussed in [1]. However, in difference from [1], where the
categories were defined in broad terms, the suggestions from the stakeholders were
more specific. Some suggestions require a special kind of tools that were not thought
of before.
As far as using the FEM technique by a novice modeler, it was both challenging and
supporting. Challenging - because it was not clear in the beginning what questions to
ask, and to whom to talk. Supporting means that when some process had been identi-
fied, it was relatively easy to unwind the FEM structure by finding things connected to
the process according to the archetypes. Using FEM gives an alternative way to under-
stand the business activities of the company. Instead of starting with the official state-
ment of mission and vision, and then continuing to how they are implemented, FEM
can help to dive into how the company works as soon as some of its primary processes
have been identified. This may give a more reliable view of the company, as the official
goals (e.g. vision and mission) may not correspond to what the company does in reality.
Despite the challenges, it was possible to build a FEM for a novice modeler with a
limited assistance from an expert. This allows us to conclude that the question posed in
our third goal, whether it is possible to build a FEM by a novice modeler, can be an-
swered positively.
Note that the main goal of this project was investigating the usefulness of FEM, all
issues related to syntactical or semantical correctness were left outside the scope of the
investigation. In this respect, we follow the famous statement from [10]: “… essen-
tially, all models are wrong, but some are useful", which puts the usefulness issue be-
fore the correctness.
Note also, that the results of our project support the statement of Patrick Hoverstadt
for the need of an architectural model that shows the management of how the company
works presented in [11]. Namely, many managers found the strength of FEM in giving
them a holistic view of the company's business activities, and especially on the im-
portance of taking into consideration interconnectedness of processes and assets.
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.
Green, S., Ould, M.: A framework
for classifying and evaluating process architecture
methods. Software Process: Improvement and Practice 10(4), 415
-
425 (2005)
3.
Koliadis, G., Ghose, A., Padmanabhuni, S.: Towards an enterprise business process
architecture standard. In : Services
-
Part I,
2008. IEEE Congress on, pp.239
-
246 (2008)
15
4.
EARF: Enterprise Architecture Definition. In: Enterprise Architecture Research Forum.
(Accessed 2014) Available at:
http://samvak.tripod.com/earf.pdf
5.
Beer,
S.: The Heart of Enterprise. Wiley (1979)
6.
Alter, S.: The Work system method: Connecting people, processes, and IT for business
results. Work System Press (2006)
7.
Osterwalder, A., Pigneur, Y.: Business Model Generation: A Handbook for Visionaries,
G
ame Changers, and Challengers. Wiley, Hoboken, NJ,US (2014)
8.
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)
9.
Give Team: Insightmaker. (Accessed 2014) Available at:
http://insightmaker.com/
10.
Box, G., Draper, N.: Empirical Model Building and Re
sponse Surfaces. John Wiley & Sons,
New York, NY. (1987)
11.
Hoverstadt, P.: Why Business should take Enterprise Architecture seriously. In Gøtze, J.,
Jensen-
Waud, A., eds. : Beyond alignment, Systems Volume 3. College publishing (2013)
55
-
166