Content uploaded by Ilia Bider
Author content
All content in this area was uploaded by Ilia Bider on Oct 03, 2015
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
http://link.springer.com/chapter/10.1007/978-3-319-19237-6_11
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
josefsson.magnus@gmail.com, kim.widman@gmail.com, ilia@dsv.su.se
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
project.
1
2
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]
1
. BPM
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
manner
2
.
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
1
Actually, [2] is the only paper, we were able to find that reports on this problem.
2
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.
2
3
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
department.
3
4
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
process.
10. The holistic process model must not assume that only one map exists for a
particular process.
4
5
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
search.
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
repositories.
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.
5
6
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,
belong:
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
process).
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.
6
7
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
7
8
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
documents.
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.
8
9
Fig. 3. The holistic process model after referencing 17 process maps
9
10
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.
10
11
Table 1. An example of process map metadata
Name of
process
Register new member in Club XP
Start
conditions
A person/organization has applied for membership in Club XP
End
conditions
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.
Assets
supported
Member of Club XP [acquire], Club XP [maintain], Club XP
membership database [Maintain]
1
Name of
document
Handling Club XP membership.doc
Placement
in storage
Directory //G:/Club XP/Process descriptions/
2
Serial #
36
1
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.
2
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.
3.
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.
11
12
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
12
13
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
13
14
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.
14
15
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.
References
1. J. Jeston, N. Nelis, “Business Process Management Practical Guidelines to successful
Implementations”, 2
nd
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,
2009
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,
2008.
8. APQC, Retail Process Classification Framework (PCF) [Electronic]
<http://www.apqc.org/knowledge-
base/download/275010/K04040%20Retail%20PCF%20version%206.0.0.pdf> [Used: 2013-
12-08]
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.
15
