Conference PaperPDF Available

Using the Process-Assets Framework for Creating a Holistic View over Process Documentation


Abstract and Figures

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.
Content may be subject to copyright.
Published and © copyright by Springer in “Enterprise, Business-Process and Information
Systems Modeling”, LNBIP, Vol. 214, 2015, pp 169-183
Using the Process-Assets Framework for Creating a
Holistic View over Process Documentation
Magnus Josefsson, Kim Widman and Ilia Bider
Department of Computer and Systems Sciences (DSV), Stockholm University, Sweden,,
Abstract. 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.
Keywords: BPM, business process, process documentation, process map
1 Introduction
This experience report is aimed at attracting attention to an insufficiently researched
practical problem that prevents reuse of existing process documentation. Besides
stating the problem, we also present a solution tested in the course of our project. We
do not insists that the solution (how) is optimal, but testing it in practice has helped us
to further investigate the problem (what), and requirements on a solution. The paper
presents the business case in which the problem has been encountered and the
solution tested, as well as lessons learned about the problem and solution that could
be of interest for both researchers and practitioners.
Ideally, all work revolving around business processes should be carried out in a
systematic and carefully managed way, and be aligned with overall business goals and
strategies [1]. However, as we discovered in the course of the project reported in this
paper, this policy is not followed in practice in all organizations. Some organizations
lack a structure to lead their work in Business Process Management (BPM). Still they
perform business process related projects. Such projects are performed sporadically,
i.e. on-demand. They can be completed locally by some department, or with a wider
scope, e.g. analysis of the processes that run through the whole organization, or even
several organizations. The on-demand BPM projects can be completed in connection
to reorganization, acquiring or developing new IT-support, etc. They produce process
maps and other types of process documents specifically aimed at the purpose of the
After the given BPM project ends, the documentation produced is filed in an
unsystematic way. Reuse of the documents is mainly based on the people engaged in
the project remembering its details. They can retrieve the documentation through
search based on the project name, date, participants, etc. Possibilities of reuse under
these circumstances are limited, especially considering that people may leave the
organization. Lack of systematization can result in loss, or underuse of valuable
knowledge contained in process maps and other process documents. It can also result
in the same process being investigated several times as people who decide on new
projects may not be aware of the previous projects.
The problem of unsystematic BPM encountered in the project reported in this
paper, is not unique for the organization we investigated. The same phenomenon has
also been encountered at least by some other researchers; see, for example, [2]
consultants whom we interviewed also pointed out that many of their clients
experienced the problems with unsystematically stored process documentation.
This paper reports on the project aimed at developing and testing a solution for
systematizing and organizing process documentation created in an ad hoc, on demand
fashion. The solution was worked out for a specific business case of an organization
that has produced around 100 process maps in an unsystematic way. As the problem
we dealt with was of general nature, we were looking not for a specific solution for
this organization, but for a generic solution that could be used in other organizations
independent of their business domain. The implementation of this solution in a
specific organization presented in this paper thus could be considered as proof of
concept of the suggested generic solution.
As a basis for systematizing process documentation, we used the process-assets
framework [3]. This framework has been developed for finding all processes within
an organization, starting from the main processes. As the framework was created with
another purpose in view, it, in its original form, did not directly fit our goal.
Therefore, we adjusted the framework for a new purpose while testing it on the
material from the organization we investigated. Consequently, the goal of the project
became twofold:
1. Solve a concrete problem in a specific organization while devising a generic
solution that could be used in other organizations. This goal included creating a
solution independent of business domain.
2. Test the usefulness of the assets-process framework from [3] for a new purpose,
namely, systematization of BPM documentation produced in ad hoc, on-demand
The rest of the paper is structured as follows. Section 2 presents the project context:
the case organization, problem, and project participants. Section 3 is devoted to
analyzing requirements on a solution. Section 4 gives an overview of our efforts to
find a standard solution, and a suitable basis for a new solution. Section 5 explains the
Actually, [2] is the only paper, we were able to find that reports on this problem.
This sub-goal is in-line with the special theme of BPMDS 2014 as it is directed for
increasing the value of the previous business process modeling projects.
process-assets framework chosen as a basis for our solution. Section 6 describes how
this framework has been transformed to fit the new purpose. Section 7 deals with
creating a solution for the case organization. Section 8 is devoted to evaluating the
solution for our business case. Section 9 discusses lessons learned and limitations of
the work completed so far.
2 The project settings
2.1 The investigated organization
The project took place in a Swedish organization operating in the area of betting, in the
text below referred to as the betting company. The betting company offers betting both
through physical shops and online. The main office currently has 250 employees,
whereof nearly half are employed by the IT department. The turnover of the company
is around thirteen billions Swedish Crowns (SEK) annually.
2.2 The practical goal of the project
Since year 2000 the IT department of the betting company has conducted 11 process
mapping projects that have rendered a large amount of process documentation. The
reasons for these projects have been of varying kind, to improve efficiency, to develop
computer systems, to oblige to new legislative demands, only to mention a few. There
is no formal repository in place, and the different projects have made their own
decisions about what modeling languages, methods, and tools to use. The
documentation has therefore not been uniformly designed and stored, and has over the
years become very difficult to retrieve and reuse. By the beginning of 2013 this
problem had reached such dimensions that there was uncertainty of the exact number
of existing process maps as well as where to find them. As a result, already gained
knowledge on business processes had sometimes been lost, and redundant work had
been done in investigating the same processes several times. A need to create a holistic
and comprehensible overview of the existing documentation had arisen, and a project
for this task was initiated.
2.3 The project participants
The project was carried out in 10 weeks by two business analysts (BAs) who were
entrusted the task of finding a solution for the problem identified, a scientific adviser,
and two employees of the betting company's IT-department. The roles of BAs were
held by the first two authors, while the third author served as a scientific adviser. As
far as participants from the betting company are concerned, one person held a position
of chief systems architect; the other one was responsible for all internal support
systems. The BAs were given full access to company's all known process
documentation, and unlimited access to the participating members of the IT
3 Establishing the requirements
It was a strong and explicit wish from the betting company that the holistic overview
of the process documents would be presented in a graphical form. The holistic
overview should also be easily understood by any person with knowledge of the
company's terminology, not only by IT managers and developers. Furthermore, the
holistic overview was not to change the existing BPM documents in order for them to
better fit the overview. The latter requirement concerned both content of the
documents, and the format in which they were stored.
Further requirements were elicited by studying the process documents. By
examining the documentation we found that a total of 137 processes had been
identified for the company's regular operations. 85 of these processes had been
thoroughly described with start, end and activity flow, i.e. documented in detailed
process maps. Some of the 85 process maps overlapped, since the processes had been
investigated within different projects with little or no cooperation between them. In
some maps inconsistencies were found, implicating that these documents were not
checked for logical or formal correctness. There were also maps that described only
parts of processes. A variety of mapping notations was found, as well as different
methods of document storage. The remaining 52 documents described processes in a
somewhat loosely manner as functional business areas with no clear starts, ends and
activity flows.
Based on the investigation completed, the following list of requirements was
compiled on holistic overview of process documentation, which we below refer to as
the holistic process model:
1. The holistic process model should be presented in a graphical form.
2. The holistic process model should be easily understood by any person with
knowledge of the organization's terminology.
3. The holistic process model must not in any way introduce changes into the
existing process documentation.
4. The holistic process model must not rely on that all process documents are
produced using the same notation or technique.
5. The holistic process model must not rely on that all process documents are stored
in a specific way.
6. The holistic process model must not rely on that all process documents are
produced having the same purpose in mind.
7. The holistic process model must not rely on that all process maps included in the
process documentation are correct.
8. The holistic process model must not rely on all processes within the organization
are mapped.
9. The holistic process model must not assume that a process document or map
depicts exactly one process. It can depict more than one process or “half” of a
10. The holistic process model must not assume that only one map exists for a
particular process.
4 In search for a solution
4.1 Searching for a standard solution
Before inventing a new solution, we checked whether there is a known solution for
the problem identified in the betting company. For this, we, first, investigated whether
this problem is unique for the betting company, or if it had been discovered in other
organizations. The investigation has been done in two directions: (a) interviewing
business management consultants with experience in BPM projects (b) literature
Two BPM consultants were contacted to check for real-life experience of the
problem and possible solutions. Consultant No 1 belonged to a consultancy that the
betting company had engaged for one of their projects. This consultant estimated that
around 70% of their clients had experienced problems with finding documents on a
given process. Among the other 30% of their clients, this was a lesser problem, due to
the fact that they had implemented a process management structure with committed
process owners and centralized standards for documentation.
Consultant No 2 was not bound to the betting company. He stated that most of their
clients had experienced problems with finding process documents, and also with
understanding their contents. Some clients had solved this problem by adopting formal
None of the BPM consultants interviewed knew a standard solution for the problem
or had encountered the problem as a subject at any conference or congress. The search
through the research literature has not resulted in a solution found for the problem of
creating a holistic overview of already existing process documentation. The search was
done on different variation of the phrase “organizing process documentation”. A
number of works has been found that proposed solutions for related problem, for
example, works on automatic process clustering [4], and business process models
repositories [5,6]. However, we found no works explicitly devoted to the problem at
hand. The only paper we found that refers to this problem explicitly was [2] that
investigated BPM experts’ points of view on the problems in BPM. This paper
includes extracts of the interviews of the following kind:
“When one looks at the way that an organization gets its work done, you see that
part of this is an important strategic level and part of this is an important
operational level”
“Often 4,5,6, different places in the organization run BPM projects and then you
have the problem how to bring these local projects together, in an overall process
architecture. I see a lot of bottom up projects but no way to tie that all into an
overall business strategy or process strategy of the organization.”
Though [2] confirms that the problem is spread, it does not suggest any solution for it.
4.2 Choosing a suitable framework
Though, to the best of our knowledge, there is no standard solution for the problem
discovered, there exist several ways of classifying business processes that could be
used for building a solution for the problem. To such classifications, for example,
1. The classification based on the Porter’s value chain [7] that differentiates primary
and supporting processes, and inside each of categories differentiate sub-
categories, like in-bound logistics (main process), or procurement (supporting
2. Process Classification Framework from the American Productivity & Quality
Center (APQC) [8] which classifies processes dependent on the industry.
Other classification schemes are in details analyzed in [6] devoted to developing
semantic annotation for business process models repositories. Besides classification
schemes, we also considered a fractal process-assets framework [3,9] that allows to
arrange all processes in an organization in a tree-like structure connecting them
through the assets used in each processes.
Neither existing classification schemes, nor the process-assets framework have
been tested for the practical task of organizing ad-hoc created process documentation,
at least, to the best our knowledge. All these frameworks concern business processes
not documents that can depict only part of the process or several processes at the same
time. In addition, some of the classifications use quite abstract taxonomies and it has
not been clear whether such taxonomy would be easily understood by practitioners.
As we did not have any special reasons to prefer one framework over all others, we
decided to start with the process-assets framework [3,9] because of having more
intrinsic knowledge of it and limitation on time for completing the project. As the
process-assets framework is not widely known, in Section 5, we give a short overview
of it, before describing how it was transformed to suit the task at hand.
5 The process-assets framework
The process-assets framework consists of the process-assets archetype (Fig. 1) and the
asset-processes archetype (Fig. 2), building on the idea that any business process in a
company rely on the company’s assets in order to be executed properly, and that the
assets themselves need supporting processes to keep them in shape.
The process-assets archetype shows a process and various assets that are needed for
this process to function friction free on a repetitive basis. The first process in the
framework is the main process of the organization. The assets are divided into six
different categories.
1. Paying stakeholders, e.g. customers of a company or paying members of a club.
2. Business Process Templates (BPT). For a manufacturing company this is both the
design of a product and a scheme of technological process of its production.
3. Workforce. People that are qualified to work in the main process.
4. Partners, e.g. suppliers for the manufacturing process of a company.
5. Technical and Informational Infrastructure. Equipment that is needed to run the
main process. For a manufacturing company this can be production lines,
computers, etc.
6. Organizational Infrastructure, e.g., departments, teams and management within
the organization.
Fig. 1. The process-assets archetype
Fig. 2. The asset-processes archetype
For the above mentioned assets to be able to support a process the assets themselves
need to be supported by a number of processes. This is where the asset-processes
archetype comes in. This archetype shows what processes are needed to acquire,
maintain, and retire an asset, see Fig. 2:
1. Acquire. Processes that are used to get hold of a certain asset, e.g. a recruiting
process to add new employees to the workforce.
2. Maintain. Processes for keeping assets. This can be customer-relationship
processes to keep customers, or training for employees.
3. Retire. Processes used to remove assets that are no longer needed. For the BPT
category this can be to phase out a product that is not in demand anymore.
Having the above archetypes can help to unveil the dynamic process structure of an
enterprise starting from the main process and going downwards via repeating the
pattern "a main process->its assets->processes for each asset->assets for each process-
> …". In this way it is possible to discover all processes within an organization. First
one defines the main processes and what assets are needed to run the processes. After
that focus goes to the assets and what processes are needed to acquire, maintain and
retire them. Then one starts to look at different assets that are needed to support the
acquiring, maintaining, and retiring processes. This procedure can be repeated until
all processes within the organization have been found and arranged in a kind of a tree
with a repeating pattern of nodes. Such kinds of structures are known in the scientific
literature under the name of fractal structures.
Note that in practice, the process structure will not form an indefinite tree as the
same process or assets can have multiple usages, i.e. serve different assets or
processes. This will, in the end stop the tree expansion. For details on the process-
assets framework we refer the reader to [3,9].
6 Transforming the process-assets model for our purpose
For the purpose of our task to get a holistic overview of all process documents that
exist within an organization, there is no need to go too deep into the fractal tree
described in the previous section. The full fractal view would make the holistic
process model too large and difficult to overview. Therefore, the unveiling of the
model stops after two iterations as it is represented in Fig. 3. In addition, the ovals that
represent the processes in the original model from [3] (see Fig 1, and 2) are
substituted by cylinders that are called “buckets” where the related process
documentation can be placed. Parallelograms are added to symbolize process
As a result, we get a relatively simple structure where all existing process
documentation can be mapped. The disadvantage of stopping at the second level of
iteration is that the documentation related to processes on the third or deeper levels will
be placed one or more levels up in the hierarchy. However, if the number of documents
in each bucket is small, it will not be difficult to look through all documents in it
manually to find out which process documents related to the given branch of the tree
exist. Extending the tree too deep can make it difficult for a non-technical person to
orient in the structure, thus there is a risk of breaking requirement #2 from Section 3
(understandability). Staying with two process levels and using the terminology
accepted in the organization makes it easier to navigate through the tree for the
members of the staff of the organization.
Naturally, the process documents themselves are not placed in the buckets. Instead,
the model works with references to the documents, e.g. their serial numbers. Therefore,
the holistic process model of Fig. 3 does not require making any changes to the
existing documentation. Working with references also supports the solution to the
problem of documents that describe more or less than one process, see requirement #9
in Section 3. If the document describes only part of a process, the reference to it is put
in the bucket where it belongs, as if it were a fully documented process. In a situation
where a process supports multiple assets, a reference to the process document will be
placed in all buckets connected to these assets (see process 17 in Fig. 3 that is placed in
three different buckets). In cases where multiple documents describe the same process,
the references to them are placed on the same reference holder.
Fig. 3. The holistic process model after referencing 17 process maps
Using references in the holistic process model automatically satisfies requirements
#3-7 from Section 3. For example, the documentation of the processes could be made
with any methods or techniques, and the holistic model of Fig. 3 does not require that
the existing documentation is correct. Neither does the model require that all
processes of the organization have been documented. If there are no process
documents related to a particular place in the tree, the bucket will be empty (see Fig.
3). This can be considered as an additional feature that shows areas in which there are
no documented processes within the organization.
7 Building the holistic process model for the betting company
Building a holistic model for the betting company based on the augmented process-
assets framework was done in three steps.
1. Make a graphical representation of the upper level of the model. Go through the
existing process documentation in order to find all assets mentioned in it. Put them
under appropriate categories of assets on the upper level. In the case of the betting
company, customers are to be placed under Paying stakeholders, employees under
Workforce stakeholders, shops under Partner stakeholders, and computer systems
under Tech and info infrastructure, see Fig. 3.
2. Extend the model by attaching buckets for acquire, maintain and retire processes
for all assets identified in Step 1.
3. Investigate each process document in order to determine which assets the process
described in it supports, and which of the asset process buckets acquire, maintain,
or retire it belongs to. Place a reference to the process documentation into all
buckets where it belongs.
To facilitate step three of the above, we compiled a document that contained metadata
for each process map at our disposal. This document helped in determining in which
bucket(s) to place references to any given map. The metadata represents a kind of
semantic annotation of the process at hand; it includes the name of the process map as
found in the documentation, and gives a short description of start and end conditions
for the process. The latter helped us to understand the business goal(s) of the process.
An example of process metadata is presented in Table1. This table refers to the
process related to applying for membership in Club XP. Club XP is a club that unties
players interested in a game called Game XP. As a Club XP member, a player gets
access to additional information about Game XP competitors on the weekly basis.
The resulting holistic process model after references to 17 process maps have been
placed in the buckets is presented in Fig. 3. As can be seen from Fig. 3, most of the
processes analyzed are related to the asset labeled Shop. A shop, e.g. a news agency,
is a partner who takes bets on behalf of the betting company, and pays prizes to the
winners. The processes in the acquire bucket deals with finding and setting formal
agreements with new partners. The bucket maintain contains processes related to
existing partners, the bucket retire contains processes related to canceling the
agreement with a partner.
Table 1. An example of process map metadata
Name of
Register new member in Club XP
A person/organization has applied for membership in Club XP
The applicant is registered as a member in the Club XP membership
database, or rejected. T
he applicant has been informed about the
outcome of the application.
Member of Club XP [acquire], Club XP [maintain], Club XP
membership database [Maintain]
Name of
Handling Club XP membership.doc
in storage
Directory //G:/Club XP/Process descriptions/
Serial #
Note that assets not explicitly named in the start and end conditions may also be
supported by the process, their presence being discovered in the detailed descriptions
of the process activities.
It can also be something of the form “
bookshelf in printer room 504” if the
document exists only in the printed form.
To give better understanding of the holistic process model built for the betting
company, below, we present some details on process documents 11 and 17 from Fig.
Document 11 in the acquire, maintain and retire buckets of asset Shop deals with
situations when a shop owner is retiring and sells his or her business to a new owner.
In essence, this process serves multiple purposes, i.e., retiring the current shop owner,
acquiring a new shop owner and keeping the shop open for betting services during the
change of ownership.
Document 17 in the maintain bucket of employees and maintain buckets of IT-
software systems describes the process for internal IT support. When an employee
reports a problem encountered with any of the company’s software, it can result in a
bug report filed in the company’s case handling system. The latter will lead to fixing
the software, which means maintenance of the software asset. But the problem report
can also come from an employee who misunderstands the functionality of the
software. In this case, the problem report does not lead to a bug report filed in the case
handling system, but to a training session that extends the employee’s knowledge of
the software, which is maintenance of employees.
8 Evaluating the results
The evaluation of the holistic process model built for the betting company was
completed in two phases. Phase one of the evaluation was conducted with the chief
systems architect of the betting company, hereafter called SA (Systems Architect).
The evaluation started with a description of the method and the model, to be
continued by a semi-structured interview where SA was given possibilities to
comment on fulfillment of requirements, applicability of the results, and their
suitability for the purpose.
SA did not convey any negative opinion that would indicate that the requirements
from Section 3 were not fulfilled. SA made positive comments regarding the
graphical model. To SA, it was refreshing to see the information about processes
presented in a new way, since it gave a new perspective, different from the one that is
given by process flow diagrams. SA found that the model was suitable to be presented
to the upper management since they are more used to look at organizational charts than
business process diagrams, and that the holistic process model was somewhat similar
to an organizational chart. The model also made it easier to find the places where there
was lack of process documentation. SA did however point out that it was not possible
to see how different processes from the same bucket are connected to each other, and
that this could be an issue for further investigation aimed at extending the model.
Phase two of the evaluation was designed as an test consisting of two steps. It was
carried out with a person responsible for all internal support systems at the betting
company, hereafter called IS (Internal Systems). IS was first given a short tutorial on
the structure of the model, and semantics of the graphical symbols in it. Thereafter, the
test began.
Step one of the test was aimed at examining whether IS could find the information
in a graphical model. IS was given a model that was pre-populated with assets and
references to process maps, and a table containing metadata of the referenced process
documents in the form as in Table 1. Thereafter, IS should complete assignments of
retrieving information from the model and the table. IS navigated easily through the
model and found all information that was asked for in the assignments, even in cases
where the name of a process did not clearly depict its contents.
Step two of the test examined whether IS could populate a half-filled model. IS was
given a model that was populated with some assets, but with their buckets empty. IS
was also provided with a set of cards that held metadata about various process maps (in
the form of Table 1). IS’s task was to place references to the process maps described
on the cards in the right buckets. In case an asset that was not already present in the
model appeared on one of the cards, IS had also to place this new asset under the right
asset category. This step of the test required more concentration from IS, and each
placement was preceded by a monologue in which IS considered the right place or
places for each process map. IS finally finished the task and had no problem with
either process maps that concerned more than one place in the model, or process maps
that dealt with new assets.
Interesting in step two of the test was that IS at one point decided not to place a
reference in one of the buckets that we considered appropriate. When asked about this
after all references had been placed, IS explained the reasons for the decision. We had
apparently misunderstood the meaning of some terms used in the process
documentation when building our holistic process model. This underlines the fact that
the model is easy to understand and operate only for those who have good knowledge
about the organization and terminology used in it. The incident did not reveal a fault
built in the modeling principles, it merely showed that IS knew the organization better
than we did.
In total, the model, and the method of building and using it showed to be operational
and useful for arranging and finding process documentation. There were no substantial
difficulties for IS to perform different tasks in the test, but without the introductory
tutorial before the test, IS would probably not have understood how to complete the
assignments. This is due to the processes and process documentation were visualized
in the model in an unusual manner.
9 Lessons learned and limitations
We summarize our experience from the project reported in the previous sections in
the form of a list of lessons learned and limitations of the work completed so far.
While discussing the lessons, we also point out areas where our work can produce
impact on research and practice.
1. Not all organizations work with BPM in a systematic way, but rather adopt an ad
hoc, on-demand approach to their BPM projects. This may lead to unintended and
undesirable consequences reported earlier in this paper. This problem is known to
BPM consultants, and but is not sufficiently covered by research literature.
2. To the best of our knowledge there is no solution for how to create a holistic view
of large amounts of process documentation created in an ad hoc manner. The
approach to a solution proposed and tested in this paper, even if not ideal, presents
a starting point for discussing and comparing new solutions to the problem.
3. During our work, we found that known ways of classifying processes are not
particularly suitable for the task of creating a holistic process view on the existing
documentation. Either they are domain dependent, or do not take into account the
diversity of process documents created in the ad hoc manner. The diversity
concerns multiple aspects, e.g. many-to-many relationships between the
documents and processes, diversity of notations and quality of the documents, etc.
4. The process-assets framework, originally developed for unveiling the dynamic
process structure of an enterprise, showed to be a suitable foundation for creation
of a holistic process model, but needed modification to fit this purpose.
5. The initial tests have shown that the model is understandable and have value for
people who belong to the business depicted in the model, but who have not been
directly engaged in its building. Though the results of these tests are promising,
more validation is required.
6. So far, our approach to building a holistic process model has been tested only in
one organization. Further validation of the approach requires its testing in other
organizations. We hope that publishing of this work and spreading it among BPM
researchers and consultants may help in promoting the adoption of our approach
by the BPM industry.
7. So far, the model was built using Power Point as a drawing tool. Its usage did not
create any major problems while the model was small (see Fig. 3). However,
using Power Point became cumbersome when the model grew to 85 documents,
see Fig. 4, and the tree structure became impossible to keep on one page. There is
a need to find a better tool, or create a new one specifically designed for building
the holistic process models. In the latter case, the tool can even be integrated with
the storage where all process documents are stored. In this case, clicking on the
document reference can result in opening it in some document viewer. In a
specialized tool, it would also be possible to expand or collapse parts of the tree
dynamically to concentrate on parts of interest to the viewer. It would also be
possible to trace maps that are referenced in more than one bucket, for example,
by clicking and highlighting.
Fig. 4. The holistic process model after referencing 85 process maps
8. Right now, the holistic process model represents only process-assets-processes
relationships. As was mentioned by the betting company's system architect, it
would be advantageous to complement the model with means to show how
processes are connected to each other in other ways, for example, how the output
from one process is being used as an input to another.
9. The process-assets model, though proved to be useful for our task, requires further
development. For example, it is not clear where to place and how to handle
economic assets. Other organizations may require adding additional type of assets
as well.
10. The biggest challenge in building the holistic process model for the betting
company was to understand the nature of the processes depicted in each
document. None of the notations used in these documents has been good at
explaining semantic content in a simple and understandable way. They all rely on
the reader's skill of how to interpret process maps. Variety of notations used in the
documents made our task even more difficult. Though we created a special form
for semantic annotation of the processes depicted in the documentation, see Table
1, we do not have a strict method for how to extract information from a document
to fill this form.
11. The holistic model seems to work well for a mid-range size of process
documentation (about 100 processes). It is not clear whether it will scale up to
thousands documents. Most probably, a sophisticated software tool will be
required to allow the scalability upwards.
1. J. Jeston, N. Nelis, “Business Process Management Practical Guidelines to successful
Implementations”, 2
edition, Oxford: Elsevier Ltd, 2008
2. W, Bandara, M, Indulska, S, Chong, S, Sadiq, “Major Issues in Business Process
Management: An Expert Perspective”, in Proceedings ECIS 2007 The 15th European
Conference on Information Systems, pp. 1240-1251, St Gallen, Switzerland, 2007
3. I. Bider, and E. Perjons and M. Elias, “Untangling the dynamic structure of an enterprise by
applying a fractal approach to business processes”, in Proceedings of PoEM 2012, LNBIP
Vol. 134, pp.61-76, Springer, 2012.
4. B. Srivastava , D. Mukherjee, “Organizing Documented Processes”, in Proceedings of the
2009 IEEE International Conference on Services Computing, September 21-25, p.25-32,
5. H. Reijers, M. La Rosa and R. Dijkman. Eds. “Managing Large Collections of Business
Process Models”, special issue of Computers in Industry, 63:2, p. 91-180, 2012
6. E. Mturi and P. Johannesson, A context-based process semantic annotation model for a
process model repository", BPMJ, V. 19 (3) pp. 404 430, 2013
7. M. Porter, On Competition, Updated and Expanded Edition, Harvard Business School Press,
8. APQC, Retail Process Classification Framework (PCF) [Electronic]
base/download/275010/K04040%20Retail%20PCF%20version%206.0.0.pdf> [Used: 2013-
9. M. Elias, I. Bider and P. Johannesson. Using Fractal Process-Asset Model to Design the
Process Architecture of an Enterprise: Experience Report. In Enterprise, Business-Process
and Information Systems Modeling, LNBIP, Vol. 175, pp. 287-301, Springer, 2014.
... Both tests gave positive results. More on this project, see in [16]. ...
Full-text available
This chapter discusses the authors’ experience of building tool support for a modeling technique called Fractal Enterprise Model (FEM) using the ADOxx metamodeling environment. FEM is introduced as a means for helping the management to comprehend how their organization operates, giving a picture understandable for the management team. It depicts interconnections between the business processes in an enterprise and connects them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (reputation, business process definitions, etc.). First, the chapter presents FEM informally—as a text with examples—and formally, as a metamodel. Then, the authors present the requirements on a tool support for FEM and discuss how these requirements were fulfilled in a tool called the FEM toolkit developed with the help of ADOxx.KeywordsEnterprise modelingFractal Enterprise ModelFEMADOxx
... One example of a specific application of FEM is using FEM for business model innovation, see, for instance, [32]. Another example is using FEM for arranging process documentation to make it possible to more easily find a model someone needs [38]. ...
Full-text available
The article is devoted to developing a methodological support for planning Design Science (DS) research projects. More exactly, it is aimed at developing a classification of a particular kind of cycles, inherent to DS research projects, and guidelines on how to choose the next cycle in a specific project. The classification and guidelines are based on results from an analysis of DS literature and a reflective analysis of our own research practice. As far as own research practice is concerned, two DS projects have been analyzed in detail. The analysis revealed that though both projects included cycles, the nature of these cycles was different. In the first project, cycles concerned finding a better problem to solve, while in the second project, cycles concerned finding a better solution for more or less the same problem. Both projects concern developing methodologies in the area of socio-technical systems, and the guidelines on how to choose the next cycle have special provisions related to such systems. In conclusion, the article presents examples of other projects that followed the suggested guidelines and discusses the difference of the suggested approach from other approaches to conduct DS research projects.
... 2. Find out new application areas for FEM, beyond those that were theoretically identified 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. ...
Full-text available
The paper presents an experience of evaluating the usefulness of a particular modeling technique called Fractal Enterprise Model (FEM). FEM connects enterprise processes with assets that are used in and are managed by 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 without 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.
... [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. ...
Full-text available
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.
... The task consisted of systematizing process documentation (e.g., process maps) obtained from multiple BPM projects in an ad hoc manner. A simplified FEM was built to arrange the documents related to the primary and supporting processes identified during the investigation [35]. ...
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.
... The two examples above are not artificial. The first happened at one of early issues of AdaptiveCM, the second happened last year with our experienced-based paper [11] submitted first to EDOC (Enterprise Computing Conference) [12], then to PoEM (working conference on the Practice of Enterprise Modelling) [13], and then to BPMDS (working conference on Business Process Modeling, Development, and Support) [14]. All three conferences had a category of experience-based papers. ...
Conference Paper
Full-text available
There are a number of methods for business process improvement that are used in practice and investigated in theory, such as Lean or Six Sigma. Most of these methods are activity based and they are aimed at optimizing the activities flow, and/or the usage of resources in the process. These methods suit well the workflow-based processes and thinking, but they are not easily adaptable to Case/Adaptive Case Management (CM/ACM) processes, the goal of improvement for which is improving the overall result from the knowledge workers cooperative work. Another distinctive feature of CM/ACM is that the process is guided not through which flow of activities to use in certain situations, but through a set of templates to use in these situations. This paper outlines a possible method of improving CM/ACM processes based on the Viable System Model (VSM). Though the usage of VSM for process improvement has been reported in the literature, it was not specifically applied to CM/ACM processes. The outline is based on the analysis of the process of organizing a series of scientific events, such as the AdaptiveCM workshop.
Conference Paper
Full-text available
In their previous work, the authors have developed a new kind of enterprise model, called fractal enterprise model, that connects enterprise processes via assets used for running these processes. One of the possible usages of this model is facilitating innovation, more exactly, changing or extending a business model used in the enterprise. This research-in-progress paper presents the idea of how such facilitation could be arranged, and lists the problems that need to be solved in order to convert the idea into a practical methodology. The discussion is based on a hypothetical example.
Full-text available
The Fractal Process-Asset (FPA) model has been proposed as an approach for identifying business processes and defining relationships between them in an enterprise. This paper reports on a project of applying the model in a Higher Education Institution enterprise. The goal of this project is twofold. One is to design a process architecture that provides a holistic view on the major business processes and their interconnections in the department to be used for business planning and development. Second is to test whether the FPA model is suitable for creating a holistic view on the major business processes and their interconnections in an enterprise. The FPA model has been applied and evaluated by business domain experts in a frame of a real organization—department of Computer and System Sciences, Stockholm University. The results show that the FPA model is understandable and suitable for creating a holistic view on the major business processes in an enterprise and their interconnections. The educational processes architecture produced is understandable and can be used for business planning and development. Though the study has been conducted only in one organization, there is a likelihood that the results achieved are of general nature.
Conference Paper
Full-text available
A promising approach for analyzing and designing an enterprise is to consider it as a complex adaptive system (CAS) able to self-adjust to the changes in the environment. An important part of designing a CAS model is to untangle the dynamic structure of an enterprise. This paper presents a procedure for identifying all processes that exist in an enterprise as well as their interconnections. The procedure makes use of a number of process-assets and asset-processes archetypes. The first ones help to find out what assets are needed for a particular process, the second ones help to find out supporting processes that are needed to have each type of assets ready available for deployment. The procedure is based on the ideas of fractal organization where the same pattern is repeated on different levels. The uncovered dynamic structure of an enterprise can support strategic planning, change management, as well as discovering and preventing misbalances between its business processes. The paper also presents an example of applying the procedure to research activities of a university.
Full-text available
Nowadays, business process management is an important approach for managing organizations from an operational perspective. As a consequence, it is common to see organizations develop collections of hundreds or even thousands of business process models. Such large collections of process models bring new challenges and provide new opportunities, as the knowledge that they encapsulate requires to be properly managed. Therefore, a variety of techniques for managing large collections of business process models is being developed. The goal of this paper is to provide an overview of the management techniques that currently exist, as well as the open research challenges that they pose.
Conference Paper
Full-text available
Process is perennial. Within any business activity or enterprise it is crucial that the variable of "operational efficiency" is maintained at sufficiently high levels, such that the return on investment is sustainable enough to justify its continued existence. Business Process Management (BPM) is the term used to encapsulate a process-driven approach to attaining enterprise operational efficiency. Despite BPM being ranked as top priority by organizations, current status of BPM research suggests a gap of addressing present industry demands. In this paper, we aim to identify the issues that organizations face in their efforts to manage business processes, as identified by BPM experts across the globe. The findings point to, among others, lack of top management support, lack of tool support for process visualization, and lack of connection between process design and process execution.
Full-text available
The results presented in this report form a part of a larger global study on the major issues in BPM. Only one part of the larger study is reported here, viz. interviews with BPM experts. Interviews of BPM tool vendors together with focus groups involving user organizations, are continuing in parallel and will set the groundwork for the identification of BPM issues on a global scale via a survey (including a Delphi study). Through this multi-method approach, we identify four distinct sets of outcomes. First, as is the focus of this report, we identify the BPM issues as perceived by BPM experts. Second, the research design allows us to gain insight into the opinions of organisations deploying BPM solutions. Third, an understanding of organizations’ misconceptions of BPM technologies, as confronted by BPM tool vendors is obtained. Last, we seek to gain an understanding of BPM issues on a global scale, together with knowledge of matters of concern. This final outcome is aimed to produce an industry driven research agenda which will inform practitioners and in particular, the research community world-wide on issues and challenges that are prevalent or emerging in BPM and related areas.
Purpose The purpose of this paper is to provide a model for semantically annotating business process models stored in a repository. The purpose of the model is to facilitate the searching of process models, to support navigating the process model repository and to enhance the understandability of process models. Design/methodology/approach The annotation model has been developed by following a design science research approach. By analysing existing works the authors have identified the requirements for such an annotation model. Following these requirements the authors have designed a context‐based process semantic annotation model. As a proof of concept, the annotation model has been implemented in a repository prototype and its applicability demonstrated. Finally, the annotation model has been evaluated in two controlled experimental studies. Findings The proposed annotation model can be used to positively affect searching, navigation and understandability of process models. Practical implications Application of the annotation model and clearly defined concepts in the process model repository is expected to improve the process of finding relevant process models in the repository for reuse. Originality/value The contribution of the paper is both theoretical and practical. It provides a clear‐cut context‐based process semantic annotation model that can be implemented easily in any process model repository.
Conference Paper
A frequent hurdle in applying Business Process Management(BPM) to large enterprises is that, since business processes are not only numerous but also documented in an engagement in multiple representations,it is difficult to work with the documented 'as-is' or 'to-be' state of the business, leave aside make accurate transformation decisions. In this paper, we consider the problem of how to reconcile and organize documented information about processes into groups that convey inter-process similarity. The discovered knowledge can be used for many applications like search, e.g., find all requirements across all available processes that are similar to those of the "Account Receivable" process. The method has been tested on a dataset consisting of hundreds of processes documented in Word and Visio, wherefrom it could find process clusters that significantly boosted search performance.
Managing Large Collections of Business Process Models. Special Issue of Computers in Industry
  • H Reijers
  • M La Rosa