Reverse Engineering of Enterprise Business Processes - Enterprise Information Systems Design, Implementation and Management: Organizational Applications - page 109

In the Figure 7, actions are combined with
activities. Some rules can be found like “some
tasks could not be repeated more than 36 times”.
Then it is essential to restructure scenarios which
will be done in the next phase presented below.

identified and modeled until reaching the higher
level of abstraction where the detailed processes
composing the global process are modeled.
In the first occurrence of this step the modeler
should identify the set of activities. An activity
is a set of actions performed by a single role. As
seen above, the granularity of activities depends
on the motivation of the reverse-engineering. For
example, an enterprise that models its process to
collaborate with external partners does not need
to consider the details of operations carried out by
the process. It is sufficient to consider the major
features that interact with external actors. However
to automate a production line, we must model the
details considering the activities of finer granular-
ity. In the first occurrence of this step, the modeler
must give a clear definition of an activity. This
definition may differ from the definition used in the
organization and obtained in the collecting phase.
Then, all activities must be identified with a name,
a number and some characteristic elements like
the role, time constraints, preconditions, etc. All
these activities with their characteristic elements
must be grouped in a table. Table 1 summarizes
the activities of the candidature process realized
entirely by the applicant. The table contains the
elements characterizing these activities.

restructuring and Modeling

This phase constitutes the originality of our
reverse-engineering process. The purpose of this
phase is to study the global processes one by one
in order to restructure the collected information
and build process models with business process
modeling languages. In our case we will use BPMN
but it is possible to use any other language as the
metamodel is generic. The process models will
be documented with other models to illustrate
concepts that are not considered by BPMN. This
phase consists of 4 steps detailed below.

Identifying Roles (Organizational View)

The different actors involved in a process were
identified in the previous phase. In this step the
modeler should assign role names to these actors
while distinguishing between processor roles and
performer roles. The delegation links between
processor roles and performer roles must be high-
lighted. It is possible to express organizational
view with graphical business process modeling
languages. For example, with BPMN, processor
roles are represented by pools and performer roles
delegated by the processor roles are represented
by lanes within these pools. For the actor “stu-
dent” executing the process “candidature in the
application” we assigned the role applicant which
is more general and can group also non-student
persons applying for university education.

Modeling with a Bp Language
(Behavioral and Interactional Views)

Scenarios obtained in the collecting phase are
obtained from the available documents or after
interviews with the actors and may be improper
or incorrect. Therefore, the user must restructure
these scenarios and define a scenario for each
activity. A scenario must be written to reorganize
the scheduling information collected previously in
ordered sentences. The used scenario model is that
of use cases defined by Cockburn (1998). A sce-
nario must contain all behavioral and interactional
elements of the functional component identified
in the previous step. In the first occurrence of
the previous step activities was identified. In this

Identifying Composition
Level (Functional View)

This step and the next one should be repeated sev-
eral times: each time a composition level should be