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