Towards an Easy Transition for Legacy Systems Evolution with the
Extension for BPTrends Methodology
Gabriel Bolson Dalla Favera
1
, Vinicius Maran
1
, Jonas Bulegon Gassen
1,2
,
Tamires Marques Sum Giffoni
3
and Alencar Machado
1
1
Universidade Federal de Santa Maria, Santa Maria, Brazil
2
Antonio Meneghetti Faculdade, Restinga S
ˆ
eca, Brazil
3
Sicredi Regi
˜
ao Centro RS/MG, Santa Maria, Brazil
Keywords:
BPM, Software Automatization, Methodology, Legacy Systems.
Abstract:
With the growing demand for producs and services, organizations are considering ways to better manage their
processes. Being the business process management (BPM) the most widely used approach in this context.
However, traditional methodologies of BPM do not encopass all different needs yet. Some stages of the BPM
lifecycle do not present the information needed to meet the requirements of some organizations. Some of those
still use legacy systems that not directly support business process management systems (BPMS). Therefore,
for instance, it is dificult to mesure performance or to update processes. In this paper we present an extension
based on the BPTrends methodology. It intends to approach problems such as the aforementioned ones, which
are not preditected by traditional methodologies. To evaluate the extension, tests were carried out in a real
scenario. Furthermore, it was possible to observe, e.g., that the extension allowed BPM to be adopted with
ease compared with traditional metodologies, that do not have the possibility to model a legacy system and
need to wait organizations to invest on systems compatible with a BPMS.
1 INTRODUCTION
With the growing demand of products and services in
organizations, business process management (BPM)
teams have emerged (Leopold et al., 2014). BPM al-
lows organizations to present multiple and different
viewpoints of its processes, aside of managing activ-
ities, events and decisions (Weske, 2012). As well
as adding value to organizations and their customers.
However, current methodologies do not support some
aspects of real world scenarios, such as process re-
design in the context of organizations that had a rapid
growth and still use legacy systems.
For instance, in various cases, it is difficult to de-
fine the risks associated with processes due the di-
versity of collaborators participating in its execution.
Also, computer systems, essential for the function-
ing of the organization, have become outdated (Nasci-
mento et al., 2009). These legacy systems present
problems that generate a huge demand of effort for the
collaborators, besides causing difficulties to newcom-
ers to understand its operation. Additionally, some
organizations do not make use of business process
management systems (BPMS). Since the acquisition
of a BPMS can be an arduous process, involving
the acquisition, adaptation and implantation. Thus,
there has been a need to provide consistent infor-
mation about running processes (monitoring stage),
taking into account the lack of a BPMS (Mejri and
Ghanouchi, 2015). In a BPMS, such information
should be easily acquired.
Taking into account the presented paradigms, the
objective of this paper is to extend the BPTrends
methodology. This extension can be applied in differ-
ent business environments that present a rapid growth
and did not consider BPM beforehand. For the con-
struction of the methodology extension, tests were
carried out in a real scenario. In which there was
a high growth in the demand of work related to the
BPM lifecycle. Meaning that many processes were
identified and continued the cycle. Besides, the ex-
ecution of those processes requires many efforts as
they run in different systems, including legacy sys-
tems.
This paper is organized as follows. Section 2
presents the background, which involves BPM and its
technologies. In Section 3 the related work is pre-
sented, followed by Section 4 which presents the ex-
666
Favera, G., Maran, V., Gassen, J., Giffoni, T. and Machado, A.
Towards an Easy Transition for Legacy Systems Evolution with the Extension for BPTrends Methodology.
DOI: 10.5220/0007758906660673
In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 666-673
ISBN: 978-989-758-372-8
Copyright
c
 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

tension of the methodology. Section 5 presents the
evaluations and discussions. Finally, conclusions and
future work are presented.
2 BACKGROUND
The present section was divided in two. Firstly, is ex-
plained about the BPM and its lifecycle. In sequence,
is presented about BPMS and legacy systems.
2.1 BPM
BPM is an approach that shows how work is per-
formed in an organization, allowing to ensure consis-
tent outcomes and to take advantages that improve the
organization (Dumas et al., 2018). BPM intends to
bring out important informations about the executed
processes , improving decision making (vom Brocke
and Rosemann, 2015).
The BPM lifecycle helps to understand all the
technologies involved, their processes, and steps in
order to be adopted in any business environment
(Weske, 2012). It is defined in six steps, shown in
Figure 1 (Dumas et al., 2018). Since BPM concerns
process improvement, it is possible to define each of
its stages, approaching from the process identification
to the implementation and monitoring stages. There-
fore, the BPM lifecycle values continuous process im-
provement, aiming at some goal such as to reduce
costs and improve performance (Panagacos, 2012).
Figure 1: BPM Lifecycle.
Modeling is important during various stages of the
BPM lifecycle. Therefore, the BPM has a notation
for business process modeling (BPMN) that contains
a series of standard icons for drawing (Dumas et al.,
2018). Enabling a better understanding of the busi-
ness. However, before starts modeling a process it is
important understand what is your motivation.
The models produced may be different depend-
ing on the reason for which they are constructed.
BPMN’s main objectives are to understand the pro-
cess itself and share its understanding with the people
involved (vom Brocke and Rosemann, 2015). Fre-
quently, process participants perform very specific
tasks and are rarely confronted with the process as
a whole (vom Brocke and Rosemann, 2015). There-
fore, modeling as well as providing a better under-
standing of the process also helps to identify and pre-
vent possible problems.
Actualy the BPMN notation has more than a hun-
dred symbols (Dumas et al., 2018). However, only a
few of them are actually used, less common symbols
can be aggregated according to the company’s need in
more complex projects. In BPMN modeling there are
four groups of elements, being them, Flow Objects,
Connecting Objects, Swimlanes e Artifacts.
2.2 BPMS and Legacy Systems
BPM provides a set of systems for the automation
of the business process management (Dumas et al.,
2018). These BPMS include the ability to perform
point-to-point business process mapping, as well as
enable electronic forms, workflow definition, real-
time monitoring of activities and alerts (Aguirre-
Mayorga et al., 2012). They are facilitators of the
knowledge management related to the processes, be-
ing used to obtain, distribute and analyze data.
Also, some organizations have a computer sys-
tem that, although old, still essential for its opera-
tion (F
¨
urnweger et al., 2016). This legacy systems
are usually difficult to maintain due to their degree
of complexity and costs for modernization. Whereas,
lack of documentation and the departure of technical
staff involved in the development, legacy systems can
present some problems such as code structuring er-
rors, outdated or obsolete programming styles and ob-
solete development tools (Seacord et al., 2003).
In the following section the related works are pre-
sented. The weaknesses of literary methodologies are
also shown.
3 RELATED WORK
Harmon (2014) presents a methodology for process
redesign. It is incorporated, including, in the process
the stages of implamentation and process transition.
Towards an Easy Transition for Legacy Systems Evolution with the Extension for BPTrends Methodology
667

The methodology is defined in five stages, being: un-
derstand project, analyze business process, redesign
business process, implement redesigned business pro-
cess and roll out redesigned business process (Fig-
ure 2). Different from the methodology presented by
Rosemann, which shows a focus on processes model-
ing, a greater focus is given in evaluations involving
process redesign. And also is adopted an environment
for performing the process redesign.
Figure 2: BPTrends Methodology.
During the application of the BPTrends method-
ology (Section 4), some steps could not be faithfully
applied. Thus, it was necessary to apply changes to
achieve the expected results for the organization. At
the identification stage, risk identification was not ap-
plied due to lack of knowledge of the process as a
whole by those involved. In addition, the processes to
be mapped were already defined by the organization.
In the process analysis stage, there was a need
to model the execution flow of legacy systems. The
modeling should allow a better understanding of the
flow executed in the systems, besides providing infor-
mation for the redesign and for the involved collab-
orators. There was a need to define the risks of each
process modeled in the current environment and in the
improvement. Finally, due to the lack of a system for
the management of the business process and the time
needed to acquire. Functionalities have been devel-
oped to monitor the processes during the monitoring
stage.
Rosemann (2017) present a methodology for the
rapid process redesing. It was defined by the author
that the process redesign would be divided into four
stages. (i) navigate, (ii) expand, (iii) strengthen and
(iv) tune/takeoff). It is defined by the author, includ-
ing, the ideal environment to realize the processes
mapping. It is used a room where it is possible to
place the models AS-IS and TO-BE arranged on op-
posing walls (Figure 3). Also are used two opposite
walls to show the process resources and the policies
and procedures.
The NESTT methodology has its main feature
focused on the best use of a dedicated space for
modeling process (Rosemann, 2017). However, this
Figure 3: NESTT Environment.
methodology is focused only on the modeling and re-
design of the processes, in order to prepare for to take-
off. The stages of identification, implementation and
monitoring are not addressed, and it is the criterion of
each company to carry out. In the methodology pre-
sented by (Harmon, 2014) are included all the stages
of the BPM lifecycle. Focusing on continuous pro-
cess improvement. However, the steps do not provide
specific instructions for the tasks preparation.
Due to the difficulty of applying a literary method-
ology in a business environment, emerged the need
to construct a extention methodology based on BP-
Trends. The papers presented in this section and the
applications made in a real scenario (Section 5) were
essential in order to achieve positive results for the
company. The following is the methodology applied
in the company.
4 EXTENDING THE
METHODOLOGIES
As presented in Section 3, the current methodologies
of BPM do not cover all kind of requirements that the
organizations need. Therefore, in this work we dis-
cuss a extension methodology based on the BPTrends
methodology.
The main problems found for organizations tran-
sitioning from non BPM to a BPM approach, hav-
ing legacy systems, concerns the stages identification,
analysis, redesign and monitoring (Table 1). To eval-
uate the proposed extension, tests were carried out in
a credit cooperative, based on the BPTrends method-
ology.
Based on practice, aspects in different phases were
missing. The following sections describe the phases
poiting out the missing parts.
4.1 Identification
In the identification phase, the criteria for selecting
processes was defined. In order for the processes to
be chosen, it is important to hold meetings with the
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
668

Table 1: Comparative applying the extension.
Stages BPTrends Methodology The NESTT Extension
Identification
- Show documentation
- Mesure costs
- Mesure risks
- Show documentation
- Mesure costs
- Consider risks
Analysis
- Model AS-IS process
- Colect data for simulations
- Construct documentation
- Prepare the environment
for NESTT
- Colect all documents
- Model AS-IS process
- Model AS-IS process
- Colect data for simulations
- Construct documentation
- Model execution of legacy systems
- Mesure risks
Redesign
- Model TO-BE process
- Colect data for simulations
- Construct documentation
- Colect sugestions for
the TO-BE process
- Model TO-BE process
- Model TO-BE process
- Colect data for simulations
- Construct documentation
- Model legacy systems
- Mesure risks
- Formulate precautions
Implementation
- Create a team for the
implementation
- Train employees
- Create a team for the
implementation
- Train employees
- Pilot the implementation
Monitoring - Mesure with BPMS
- Create a mesure using the
documentations and
evaluations
team involved to point out the main focus of BPM be-
ing applied for the given organization. Should be pre-
sented the process with the description and the degree
of complexity and importance (Harmon, 2014).
In BPTrends it is necessary to measure the risks
presented in each process. These risks provide data
that help in making the decision about which pro-
cesses to apply BPM for. However, identifying those
risks was difficult due the diversity of people involved
in some processes. Additionaly, the risk should be
considered differently from aspects such as costs. The
risk might change in the TO-BE model, increasing or
decreasing. However it depends on the company ap-
petite for risks. Thus, the risk should be considered,
but carefully in the identification phase.
The risks could be measured after mapping the
processes that are executed in the current environment
(AS-IS) and in the improvements (TO-BE). This in-
formation is used to leverage metrics for monitoring.
Additionally, some processes can be defined from the
top, as organization priorities.
4.2 Analysis
After defining the main processes, meetings were held
in order to build their models. It is necessary that all
the activities described during the meetings match the
processes modeled, thus accurately representing how
processes occur in the current environment. In some
cases, depending on the complexity of each process,
follow-up meetings should be held where the collab-
orator performs the process in practice, and is accom-
panied by the modeling team. Once the process is
modeled, a document containing the description of
the processes must be created and the company must
be handed over to the understanding of the modeling
process. Must be collected also run-time data in order
to perform simulations.
When the process is documented, the risk of the
AS-IS process must be evaluated. This risks should
be predicted for each modeled process. The company
should predict the risks and the main impacts that are
presented for itself and its clients. It also can be used
to create improvements in the TO-BE process.
It was also identified, the need to perform the
modeling of the execution of the legacy systems. This
modeling provides more information for the redesign
process and for the implementation processes as well.
For the modeling of the legacy systems can be
made using the BPMN notation. As in business pro-
cess modeling, it should contain start and end event.
And the tasks are simple and can be represented by
the same verb-object structure. If there is a need, in-
termediate events and gateways can be used. Interme-
diate events can represent, for example, the need for a
system to wait for some message, signal or some time,
since the gateways represent the deviations of the ex-
ecution flow. In addition, the use of sub-processes can
be made to improve the visualization of processes.
The swimlanes are also used in modeling the pro-
cesses of legacy systems. Pools continue to represent
the company to which the software belongs and the
Lanes will represent the persons or roles that perform
these systems.
The modeling of these systems provides subsidies
for building an upgraded system, as well as containing
documentation for possible future improvement. In
the next stage process improvement will begin, and
all documents built will be essential.
Towards an Easy Transition for Legacy Systems Evolution with the Extension for BPTrends Methodology
669

4.3 Redesign
During the improvement stage, meetings or work-
shops are held with the purpose of analyzing the AS-
IS model and presenting solutions for process im-
provement. This step involves not only the follow-
up of the collaborator but also that of his superiors,
being responsible for providing suggestions within
the availability of company. Also, the documentation
must be created, so that the company can evaluate.
It is also required collect stipulated run-time data for
the purpose of being simulated and measured before
its implementation.
As an adiction for the BPTrends methodology,
when constructing the TO-BE process the AS-IS pro-
cess should be used as a comparison. The two models
must be visible, arranged side by side, as a basis for
their construction. Also the modeled process of the
execution of the legacy system can be used as a basis
to create an automation or a new system. However,
this should be described in the TO-BE process.
As in the previous step, the risks that the re-
designed process presents should be described, to-
gether with the precautions. In this way, it will be
possible to generate precautions when some risk oc-
curs.
4.4 Implementation
The implementation stage can be applied in different
ways. In some cases, the modeling team may be in
charge of refining TO-BE processes. In other situ-
ations the development team should provide support
for the implementation of the changes that occurred
in the process. Software implementation can also be
done, as well as training for users.
In this step, the legacy system flow previously
modeled in the analysis phase can be used. It pro-
vides information to implement new systems and to
modify the task flow of the current systems.
4.5 Monitoring
In the BPTrends methodology, during the monitoring
stage, BPMS are used. These systems can provide
detailed information of average time in the process
execution flow, in addition to distributing and defining
tasks. However, acquiring a BPMS can be a complex
task and requires a greater time demand.
In order for the processes to be measured, com-
parisons were made between the simulations of the
processes. The data for which the processes were
simulated were collected in the analysis and redesign
stages. Thus, the average execution time can be com-
pared taking into account the types of tasks, for ex-
ample, the significant decrease of the time due to an
automation.
The risks presented by both AS-IS and TO-BE
processes were compared. The amount of risk that
each process presented or comes to present is indica-
tive of the performance in the process flow. Preven-
tions, in addition to reducing costs for the organiza-
tion are also indicative of improvements in the pro-
cess.
Besides the analysis of the simulations and risks,
forms were filled out by those involved in their re-
spective processes. The form seeks to measure the
level of satisfaction of each collaborator and client,
regarding the level of stress for their tasks, average
time of execution, customer waiting time informed
by the collaborator and difficulties of adaptation with
changes in the process. Other metrics can be defined
according to the needs of each organization, usually
applied when presenting specific tasks.
Both documents can be used to monitor and mea-
sure the level of collaborator and customer satisfac-
tion. The results in these analyzes may serve as a fu-
ture improvement in the process or even until a BPMS
system be properly implemented, thus obtaining more
precise documentation.
In the following section the related works are pre-
sented. The weaknesses of literary methodologies are
also presented.
5 EVALUATION AND
DISCUSSION
In order to elaborate an extension methodology based
on BPTrends, applications were made in a credit
cooperative, which did not have defined processes.
Thus, the techniques of traditional methodologies
were applied, allowing us to identify the main limi-
tations concerning the scenario.
During the first stage, a difficulty was identified
in measuring the risks associated with AS-IS pro-
cesses. The fact behind this was that no collabora-
tor was aware of the process as a whole. Once the
AS-IS processes were already modeled, the risk eval-
uation became easier. The identification stage started
with demands from the organization, which had al-
ready selected processes by their own means. These
processes were defined by the superiors and accord-
ing with their needs.
Although some processes were already deter-
mined, it was verified the need to measure the costs
involved. Those costs were used to continue identi-
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
670

Table 2: Example result table.
Process
Cost by
minute
Cost by
instance
Total annual
Consortium - vehicle
acquisition
$0.30 $18.00 $900.00
fying process candidates, as well as to measure im-
provements during the monitoring phase. A table was
built based on the method of analysis and problem
solving (MASP) in order to calculate the costs in-
volved. The total cost per minute (cm), was calcu-
lated using the monthly salary (ms), days worked in
the month (dwm) and hours worked in the day (hwd)
based on a collaborator (Equation 1).
cm =
ms
dwm × hwd × 60
(1)
The cost per instance (ci) defines the amount spent
for each execution of the process. Total cost per
minute was used (cm) plus running minutes spent
(rms) (Equation 2).
ci = cm × rms (2)
Impact (i) was used to calculate the total annual
cost (ta). It was calculated based on process execution
frequency per year (fey) plus the number of clients
and adjacent affected (caa) 3.
i = f ey × caa (3)
Finally, the annual total (ta) was calculated with a
sum of the cost per instance (ci) and the impact (i).
ta = ci × i (4)
Based on the results generated from the equations,
it was possible to calculate the cost involved in each
process (Table 2). External costs were not evaluated,
such as the maintenance of computers, due to the ir-
relevance presented to the processes. Also, it was pos-
sible to define with more severity the priority of the
processes.
Once the processes were defined, the AS-IS pro-
cess modeling was started. During the modeling, sev-
eral suggestions for improvement were made, making
it difficult to model the current process. However, it
was possible to perceive a better understanding of the
operation of the process by those involved. With the
processes modeled, mapping documents were gener-
ated using a Bizagi tool. These documents could be
analyzed by the directors and stakeholders.
Also, data were collected from the execution of
the processes. These data were collected for the
purpose of simulations when TO-BE processes were
modeled. There was also a need to model the exe-
cution flow of the legacy system to be handled in the
Table 3: Preventions table.
Process Risk Prevention
Consortium - vehicle
acquisition
Lack of adaptation
in the use of the system
- Provide courses of use
- Build documentation
for use of the software
Error in
automated system
- Construction of a contingency
for the carrying out the tasks
- Testing in a safe environment
next steps. The modeling of the system has even al-
lowed a better understanding for its employees and
modeling team, which can be based on documenta-
tion for the execution of their activities. For the flow
modeling of the systems, basic BPMN elements were
used (Figure 4), making the process understandable
to the involved.
At this point, it became possible to measure the
risks of each process, thus setting a standard. This
information was essential for the monitoring step as
well as to compare with the TO-BE process.
For the construction of the TO-BE model, meet-
ings were held with the team involved, together with
process managers. Suggestions were provided by the
process team. However, because the team had spe-
cific knowledge of some stages of the process, the
managers were able to provide an overview, thus con-
tributing to the improvement as a whole.
Once the TO-BE process was modeled, it became
possible to measure the risks based on the model-
ing process. Precautions have also been provided for
some situations that may occur with the process (Ta-
ble 3). Again, data were collected for the purpose of
simulations, identifying the improvements achieved.
Finally, the TO-BE process documentation was gen-
erated. This documentation was passed on to those
involved to collect suggestions for improvement.
During the implementation phase, teams were cre-
ated to carry out the construction of software or au-
tomation, implement and provide process training.
Based on the modeling processes of the legacy sys-
tems, information was obtained that facilitated the au-
tomation and construction of the software. Functional
and non-functional requirements of the systems were
defined, as well as diagrams using the unified model-
ing language. The documents generated were deliv-
ered to the organization in order to update when nec-
essary. Trainings also provided for the use of software
and to adapt to the new modeled processes.
Finally, during the monitoring phase, it was ver-
ified the absence of a system for managing business
processes (BPMS). However, acquiring a system that
meets the needs of the company can be a lengthy pro-
cess. In this way, it were developed ways of measur-
ing the performance of processes without the use of
software.
Initially, the simulations were used, seeking to
identify the execution time. Some issues are taken
Towards an Easy Transition for Legacy Systems Evolution with the Extension for BPTrends Methodology
671

Figure 4: Part of the process of launching into the system the release of personal credit.
into account, such as the automated tasks and the re-
duction of employees’ tasks. Comparisons of the AS-
IS and TO-BE processes. The risks were compared
with the AS-IS and TO-BE processes. Thus, it is up
to each organization to define the risk it wishes to as-
sume.
During the application of the methodology exten-
sion it was possible to perceive an easy adaptation
from the company side. Concerning the modeling
phase and processes involving the legacy systems,
more time was required than in the application of the
traditional methodologies. However, during the im-
plementation phase, which involved the development
of an application, a significant decrease in time was
observed.
It was also observed that the lack of a BPMS did
not prevented the evaluation of the process perfor-
mance. The evaluations provided satisfactory infor-
mation to the organization. However, a greater time
demand was required for the data collection in order
to perform the monitoring phase.
In the next section, conclusions and future work
are presented.
6 CONCLUSIONS
This paper presented an extension based on the BP-
Trends methodology. Which was tested in a real
world scenario, concerning a organization which had
high growth in work demand. The organization made
use of legacy systems, which required a greater time
for the execution of tasks. It was also identified the
lack of a BPMS in the organization, thus it was diffi-
cult to measure processes performance.
Based on the presented results, it is possible to af-
firm that the use of the methodology extension can
provide essential information regarding process mod-
els documentation for comprehension and implemen-
tation. Facilitating the adoption of BPM on the orga-
nization.
The modeling of tasks execution in legacy systems
provide essential information to build new software.
In addition to provide information of its operation to
other employees. In this way, it was also possible to
avoid that knowledge for the execution of the system
remained with only one collaborator.
Regarding the BPMS, the extension provides tech-
niques to gather process performance metrics. This
can avoid downtime since acquiring a BPMS can in-
volve a lot of time, and the organization can not stop
in the meantime. In addition, the definition of risks
and preventions in the analysis and redesign stages
provides information, allowing a comparative analy-
sis in the monitoring stage.
For future work, we envision the development of
a tool that allows the modeling of legacy systems
tasks. The tool can provide more information about
the legacy systems for modelers and organizations
that wish to use it.
REFERENCES
Aguirre-Mayorga, H. S., Carre
˜
no-Vargas, J. E., Vega-Mej
´
ıa,
C. A., Vega-Mej
´
ıa, J. S., and Hern
´
andez-Mart
´
ınez,
Y. P. (2012). Evaluation of int
´
egration approaches be-
tween erp and bpm systems. 16.
Dumas, M., La Rosa, M., Mendling, J., and Reijers, H.
(2018). Fundamentals of business process manage-
ment. Springer, 2 edition.
F
¨
urnweger, A., Auer, M., and Biff, S. (2016). Software
ICEIS 2019 - 21st International Conference on Enterprise Information Systems
672

evolution of legacy systems: a case study of soft-
migration. 1:413–424.
Harmon, P. (2014). The BPTrends Process Redesign
Methodology, pages 353–383. Morgan Kaufmann, 3
edition.
Leopold, H., Mendling, J., Reijers, H. A., and La Rosa, M.
(2014). Simplifying process model abstraction: tech-
niques for generating model names. 39:134–151.
Mejri, A. and Ghanouchi, S. A. (2015). Evaluation of
paradigms enabling flexibility: Bpmss comparative
study.
Nascimento, G. S., Iochpe, C., Thom, L. H., and Reichert,
M. (2009). A method for rewriting legacy systems
using business process management technology.
Panagacos, T. (2012). The ultimate guide to business pro-
cess management, pages 8–24. 1 edition.
Rosemann, M. (2017). The nestt - rapid process redesign.
pages 1–20.
Seacord, R. C., Plakosh, D., and Lewis, G. A. (2003). Mod-
ernizing Legacy Systems, chapter 1.1 and 3. Addison-
Wesley Professional, 1 edition.
vom Brocke, J. and Rosemann, M. (2015). Handbook
on business process management 1, pages 209–250.
Springer, 2 edition.
Weske, M. (2012). Business process management: con-
cepts, languages, architectures, pages 3–23. Springer,
2 edition.
Towards an Easy Transition for Legacy Systems Evolution with the Extension for BPTrends Methodology
673