ERP Projects in Organizations with Low Maturity in BPM:
A Collaborative Approach to Understanding Changes to Come
Danilo Lima Dutra
, Simone C. dos Santos
and Flávia M. Santoro
Centro de Informática, Universidade Federal de Pernambuco, Recife, Brazil
Instituto de Matemática e Estatística, Universidade do Estado do Rio de Janeiro, Rio de Janeiro, Brazil
Keywords: ERP Projects, BPM, As-Is modeling, Collaboration, Design Principles.
Abstract: ERP projects are constantly involved with profound changes in organizations that directly impact business
processes and their stakeholders. Therefore, process understanding is an essential step in such projects.
However, in companies with low maturity levels in BPM, the processes are informal and unstructured; there
are no previous models or outdated. Thus, the primary source of information about processes is the people
involved in their execution. But, how to engage ERP project stakeholders in the changes resulting from the
new system by understanding current processes and future changes? This study proposes a framework called
"Meet2Map" to answer this question. This approach promotes identifying, discovering, and modeling
processes involving participants based on collaborative interactions and human-centered design principles.
Through a case study, the results showed the adequacy of the Meet2Map framework in supporting the process
analyst in As-Is process modeling as an essential step in the implantation of ERP systems.
Organizations typically face challenges when trying
to implement initiatives to change their business
processes. A typical example of this scenario is
implementing business management systems, better
known as ERP (Enterprise Resource Planning). These
systems are responsible for any company's key
activities, usually implying changes in critical
processes in sectors such as production, services, HR,
finance, logistics, distribution, among others, and,
therefore, involving all employees who make the
company, from operational to a strategic level (Taube
and Gargeya, 2005), (Sedera, Gable and Chan, 2003).
Many ERP projects have been renewed recently,
mainly due to cloud computing and big data
technologies, aiming at service-based platforms to
reduce costs and increase business efficiency through
greater integration between the company and its value
chain (Schmitt, 2015; Seethamraju, 2014). Thus, ERP
solutions are constantly evolving, demanding the
implementation of new ERP projects (Lechesa,
Seymour, Schuler, 2012; Johansson and Ruivo,
2013). In this scenario, the sophistication of the new
ERP systems causes profound transformations in
organizations, directly impacting all employees'
activities, at all levels, conducted for years in the
same way and with the same people. These changes
often demand new skills, differentiated roles, much
less operational and more managerial functions,
involving a change in organizational culture and
personal mindset that organizations are not always
prepared to face.
It is not new that ERP projects have suffered
failures. According to Santos, Santana and Elihimas
(2018), one of the reasons is poor administration
regarding identifying and managing implementation
risks, in general, associated with critical factors of
project success. Among these factors, the human
factor is predominant such as the support of top
management, the presence of key users, the
competence of the project team (which includes
managers, users, and IT professionals), education &
training, communication, and the management of
expectations (Bhatti, 2005; Prata and Santos, 2019).
In this context, it is evident how essential the
involvement of the interested people is in
organizational changes and how these changes need
Dutra, D., Santos, S. and Santoro, F.
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come.
DOI: 10.5220/0010954800003179
In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 385-396
ISBN: 978-989-758-569-2; ISSN: 2184-4992
2022 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
to be understood effectively, not only with messages
and presentations, which are almost always
unidirectional. At this point, BPM can be used as a
strategy for engaging employees with future changes,
based on the exposure of their current processes and,
together with them, understanding the changes that
these processes will undergo with the implementation
of the new ERP.
The initial activities of an ERP project coincide
with the initial stages of the BPM life cycle, which
include the identification, discovery, and analysis of
business processes, according to Dumas (2013). In
general, process analysts carried out these steps to
identify business processes, detail their tasks, and
produce process models that clarify how to work
procedures are performed (As-Is models) and how
they can be improved (To-Be models). However,
many organizations, particularly those with low BPM
maturity, suffer from a lack of information from
outdated, inconsistent, or non-existent process
documentation (Jeston and Nelis, 2006). In these
organizations, the primary source of information
about processes is the people involved in their
execution through the domain experts (users, owners,
managers) representing the main stakeholders in the
ERP projects (Persson, 2001).
According to Luebbe and Weske (2012), raising
processes through interactions between process
analysts and domain experts is not easy.
Traditionally, process analysts interact with domain
experts, collect information, and translate it into
process models. However, domain experts (like users,
owners, managers) are generally unfamiliar with
process thinking and notations, failing to provide
meaningful feedback. Another common problem
during process modeling is that the process analysts
could misinterpret information because they are not
familiar with the process, generating an incomplete or
wrong model. Finally, failures during a process
modeling cause rework, costs and compromise
stakeholder confidence.
In this context, a central question motives this
study: How to engage ERP project stakeholders in
the changes resulting from the new system by an
understanding of current processes and their future
changes?”. To answer the central question, this study
describes a proposal to identify, discover and model
business processes from interactions of people
involved in those processes, called the “Meet-to-
Map” Framework (“Meet2Map”, in short). Based on
collaborative interactions and human-centered design
principles, this approach might foster new ways of
process modeling by engaging participants. For this,
the Meet2Map framework comprises an application
process, a design tool, and artifacts to guide the
process analyst in modeling the As-Is processes
together with domain experts. Although similar
proposals are found in the literature (Adamides and
Karacapilidis, 2006; Luebbe and Weske, 2010;
Cereja et al., 2017), there are no reference guides
focused on a collaborative process modeling able to
support the analyst in this task.
As main contributions, it is possible to highlight:
a detailed step-by-step procedure on how to perform
the As-Is modeling stage of the BPM life-cycle; and
a collaborative approach supported by a tool based on
design principles. Also, a case study is described,
showing the viability of this proposal.
This paper is organized into six sections. After
this introduction, Section 2 describes the primary
theoretical references and related works. After that,
Section 3 presents the research methodology. The
Meet2Map Framework and its components are
presented in Section 4, followed by a case study
discussed in Section 5. Finally, Section 6 presents the
conclusions and future perspectives of this research.
Two main fundamentals underlie the Meet2Map
framework: the characteristics of the discovery and
process modeling step of the BPM cycle, discussed in
Section 2.1; the principles of human-centered design,
discussed in Section 2.2. Section 2.3 also presents a
brief description of the works that inspired this study.
2.1 Business Process Discovering and
Several authors (Davenport et al., 1997; Jeston and
Nelis, 2006; Dumas et al., 2013) agree that the first
step in any BPM project is to understand the process
and identify its problems, and as so, to model the As-
Is process. It is necessary to understand the current
process to identify improvement points and avoid
repeating past mistakes (Sedera, Gable and
Rosemann, 2004). Another essential factor is the
acceptance of the model by its participants. The
imposition of a new process, not considering the
participants' experience, contributes considerably to
negative results. Baldan et al. (2007) emphasize the
relevance of the following steps on the identification
and modeling of the As-Is process: i) Project
planning, understanding of scope (which process will
be modeled, goals, metrics, strategic alignment,
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
deadlines, deliverables), team composition, schedule,
the infrastructure needed, access to documentation
related to the process (laws, regulations, references);
ii) Data collection with users (business experts and
facilitators), including interviews (open or
structured), the joint definition of activities,
information about the process, meeting records; iii)
Process documentation, building the process model,
according to the methodology adopted. Additionally,
some information could also be registered, such as
publications, references, scope, etc. In this phase, it is
expected the use software to support modeling; iv)
Process validation, evaluating the model in an
authentic process instance to check for coherence; v)
Model adjustment, in which any perceived distortions
during validation should be corrected.
These steps grounded the definition of the
Meet2Map framework. In addition, we considered
other critical factors extracted from the BPM CBOK
(2013), which could influence the planning and
execution of these steps. The first issue is the
communication problem. All the stakeholders must
fully understand the externalized knowledge. Thus, it
is necessary to establish a clear goal to support
defining priorities and needs. It is also required to
identify the process at a high level before describing
its activities. Going straight to the details can lead to
constructing a very large and challenging to
understand model. A sequential decomposition
approach of "understanding the whole -
understanding the parts - choosing one part" assists in
the conception and comprehension of the model.
It is also important to manage expectations
concerning modeling goals. Process modeling is not
an end but a means to achieve a goal. It is fundamental
to understand and make clear what is expected of the
modeling. It is important to emphasize that the model
must also be validated by those who will use it and
not only by those who have provided information
about it. Finally, it is important not to confuse
understanding and standardization. Process modeling
does not represent an institutionalization of the
process as a standard. These critical factors served as
a reference to define the method for the process
modeling phase proposed in this paper.
2.2 Design Principles to foster Business
Processes Discovering
Although the design thinking approach has been used
more frequently in the context of process innovation,
some studies suggest that alternatively, organizations
could use design principles (Brown, 2009) and
practices to address some issues faced by dealing with
BPM in a general way, considering these issues are
essentially human-centered (Van Looy and Poels,
In the context of “As-Is” process modeling, three
phases can be considered: identification, to achieve a
full understanding of the process, analyzing it both
from a rational and experienced perspective;
discovering, discussing processes, and proposing
potential solutions that represent them; as-is
modeling, in which a process is designed and
evaluated by people involved, in a real scenario,
getting feedback from them. As in the design of new
product or processes, some principles also need to be
adopted in the discovering and modelling of
processess, encouraging the participation and
engagement of domain analysts, users and other
stakeholders. In this context, Brown defines seven
design principles (DP) that can be related to
processes, as shown in Table 1.
Table 1: Design principles in process modeling.
ID Design Principle Process Modeling
DP1 Human-centered People who participate in
the modeling process are
the most important resource
and should be value
DP2 Collaboration Stakeholders should be able
to model process
collaboratively, making the
participants owner of the
DP3 Experimentation Look for different ways of
modeling processes and
breaking down barriers,
allowing domain experts to
model the process.
DP4 Reflective Observe the process from
different perspectives to
allow more discussion on
the process.
DP5 Multidisciplinary Involve people from
different areas and
functions related to the
DP6 Process thinking Ensure that process
stakeholders can analyze
their processes, think about
the problems faced, and
propose possible
DP7 New ways of
In this context, about the
These principles were used in the Meet2Map
conception to define its method and guidelines on
how to apply it as described in Sections 4 and 5.
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come
2.3 Related Work
According to Forster et al. (2012), since various
domain experts and engineers are involved in
collaboratively creating of process models, the
frontier between elicitation and representation is
blurred. The authors argue that the distinction
between those two phases disappears and is replaced
by an iterative process of performing them. So,
despite the most traditional method for process
discovery and modeling be the structured interview
(Davis et al., 2006; Dumas et al., 2013), some
research on collaborative process modeling has been
proposed. In this sense, Adamides and Karacapilidis
(2006) presented a framework for collaborative
business process modeling, in which during a
collaborative modeling session, a group participates
in four interrelated activities: construction,
presentation and understanding, critique, and
intervention on the model. Furthermore, Antunes et
al. (2013) developed a modeling approach and a
collaborative tool to support end-users in modeling
business process based on a composition of scenes
that form storyboards. None of these proposals
provide a structured method for the modeling phase
of business processes.
On the other hand, although some companies are
already starting to use design thinking in BPM (e.g.
SAP1), and this approach is mentioned in white
papers from consulting groups (e.g., Recker, 2012),
the academic literature has not explored this topic in
depth yet. Based on design science and action
research, Rittgen (2010) proposes a six-step method
to guide groups in workshops and a software to
support applying this method, also advocating the use
of collaborative methods for process modeling
(Rittgen, 2009). This work is focused on the
dynamics of the workshop itself. Cereja et al. (2017)
described the use of design within the BPM cycle. A
real case in a company has motivated that work when
a traditional method of requirements elicitation was
not successful in a specific project, and moreover, the
users did not perceive the process that the system
should support. So, a consulting company was hired
to apply design thinking. They did not focus on the
modeling phase and neither used a collaborative
application to support the approach, as the framework
presented here. Besides, Miron et al. (2019) described
the DIGITRANS Project, which is intended for an
automated transformation of haptic storyboards into
diagrammatic models. They are focused on the
development of an app that delivers a design-based
method and a set of tools to support the digital
transformation process of Small and Medium
Luebbe and Weske (2010) proposed a tool to
support business process modeling called TBPM
(Tangible Business Process Modeling). They aim to
model the process during the discovering phase, so
the domain specialist is no longer only interviewed,
but he/she models together with the analyst. This
proposal is based on design principles. The tool
comprises a set of acrylic artifacts based on BPMN
notation (task, event, gateway, and data object),
which can be handled by the team to create the model.
According to the authors, the semantics associated
with the artifacts impel participants to use the concept
of control flow, data flow, and resources. Thus,
participants can create, delete, organize and rearrange
objects. Luebbe and Weske (2010) pointed out the
benefits of the tool: people talk and think more about
their processes; people review their processes more
often and also apply more corrections during the
discovery session; more fun and new insights during
process modeling; active creation involves the
participants and increases the engagement to
complete the task. In view of these results, we
propose this work as the initial stage of our research
methodology, as described in the next section.
This study is characterized as qualitative research,
with an emphasis on Action-research. According to
Patton (2002), research is said qualitative when aims
to investigate what people do, know, think, and feel
through data collection techniques such as
observation, interviews, questionnaires, document
analysis, among others. According to Merriam &
Tisdell (2015), action research is intended to solve a
problem in practice, contributing to the research
process itself, addressing a specific problem in a real
environment such as an organization. This research
was conducted in three stages: 1) Research
delimitation; 2) Action-research cycles; and 3)
consolidation of results. Figure 1 shows an overview
of the research methodology.
In the first stage, a literature review was carried
out, which supported the construction of the
theoretical background on the themes related to BPM,
process modeling, and benefits of Design principles
(described in Section “Theoretical Background”).
Moreover, as an ICT manager of a company in the
electric sector, the first author of this study observed
many problems with business process management
concerns an ERP project in his organization,
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
particularly concerning adherence between processes
and systems. In the second stage, we specified the
problem, central question, research questions
(described in the section Case Study) and planned the
2 case studies. To guarantee the reliability of the
results, we defined a protocol for each one, which
described the procedures of data collection, selection
of the participants, analysis methods, and documents
Figure 1: Research methodology.
The first case study had an exploratory nature,
aiming to come up with the main challenges related
to process modeling with the usage of TBPM (Luebbe
and Weske, 2010). The results of this exploratory
study provided an additional basis for the design of
the Meet2Map Framework, which will be described
in the next section. The data collected allowed the
identification of the problems related to the process
elicitation and modeling phase as well as the use of
the collaborative tool. The problems were categorized
into 10 types of Failures: F1. Lack of experience of
the analyst in the application of the modeling tool; F2.
Lack of a clear introduction on business process
concepts and process model in BPMN; F3. Lack of an
interview script; F4. Lack of key participants in the
modeling team; F5. Lack of proper introduction on
tool use; F6. Homogeneity of participants; F7.
Inadequate or partial preparation of the modeling
tool; F8. Unclear or poorly defined activity proposal;
F9. Impulsive conclusion of the analyst; F10.
Excessive interference by the analyst for direct
modeling of the process. These failures were
associated with 9 different types of Consequences
arising from them: C1. Increasing the time of the
modeling task; C2. Lack of confidence in the use of
the tool; C3. Lost of focus in the modeling task; C4.
Process model not well-defined; C5. Unbalanced
participation; C6. Low performance of the team; C7.
Participant demotivation; C8. Resistance of the
participants; C9. Lapse of relevant information. The
categorization of failures and consequences allowed
the proposition of four critical success factors for
discovering and modeling activity, using the
collaborative modeling tool:
CSF1. Experienced and prepared analyst related
to failures (F1, F2, F5, and F9; C1 to C4);
CSF2. Detailed definition of the methodology
using the collaborative modeling tool (F2, F3,
F5, F7, and F10; C1 to C7);
CSF3. Choice of suitable participants for the
process (F4 and F6; C4 to C7);
CSF4. Clear and well-defined mission (F8; C3,
C4, C8, and C9).
The goal of the second case study was to evaluate
the application of the Framework. Section “Case
Study” describes that case study in detail, as its results
and discussions that are related to the third stage
(research finds).
This section presents the framework proposed to
support the analyst in conducting the discovery and
modeling phases collaboratively. The framework is
composed of a collaborative modeling method, a tool
for collaborative modeling processes, and group of
artifacts, as shown in Figure 2.
Figure 2: Components of Meet2Map Framework.
4.1 Modeling Tool
The goal of the Collaborative Modeling Tool is to
foster interaction among participants according to the
design principles. So, we took the TBPM tool as a
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come
starting point. However, despite the benefits
presented, the use of the tool in the exploratory case
(commented in section “Research Methodology”)
pointed out some problems related to its design:
building the acrylic pieces demands specific tools for
the appropriate cutting and craftsmanship for the
finishing of the pieces; and, applying the TBPM on a
horizontal surface, preferably of glass, is required to
allow the design of the swimlanes and flows. But
since modeling activities usually take place at the
customer's location, getting an environment with this
type of table is not so simple. Thus, the solution was
to replace the original material used in TBPM with
the paper since it is low cost and accessible to
everyone, as illustrated in Figure 3.
Figure 3: Collaborative Modeling Tool.
To ensure a tactile experience, some resistance to
handling and good appearance, various types of paper
were tested (Dutra, 2015). The BPMN elements are
start events, end events, tasks, gateways, and data
objects. Hence, the template cards could be printed
and easily cut for the preparation of the pieces.
Moreover, there is another benefit of this design: with
the application of a double-sided tape on the opposite
side of the printed face, the tool can be easily used in
whiteboards that are easy to acquire and commonly
used. To facilitate use during the modeling activity,
blank pieces were fixed on the board within reach of
the participant.
4.2 Collaborative Modeling Process
The main goal of the Method for Collaborative
Modeling Processes is to involve all participants in
the joint effort of modeling the process supported by
a collaborative tool. Thus, it is necessary that the
analyst to promote the participant's active
collaboration to extract as much as possible relevant
information and insights about the process. The result
expected is not the final version As-Is process model,
but the identification of details that allow adequate
final modeling. The method is composed of four
The first step is the Preparation for modeling. This
step is very important since the team needs an
appropriate environment. These are the instructions
for this step: Select the environment: it is important
to select a place free of distractions, favoring the
attention of all involved; Guarantee full availability
of participants: it is important to ensure that all key
stakeholders are fully engaged in the activity during
the proposed period, considering the human-centered,
collaborative and multi-disciplinary characteristics of
the design principles (DP1, DP2, and DP5 as shown
in Table 1); Prepare the modeling tool: it is important
to prepare the modeling tool so that it is ready for use
and available for participants during the modeling
activity encouraging experimentation (DP3).
The second step is the Introduction to essential
concepts. The process analyst starts the workshop by
introducing the team to the essential concepts to
perform the task as listed below, stimulating process
thinking (DP6): Understand the goals of the
organization with the accomplishment of the task;
Discuss the methodology that will be used for
modeling; Introduce the basics of BPM, process
modeling, and BPMN notation; Present the
collaborative process modeling tool.
The third step is Modeling the macro-process. The
main characteristics and macro tasks of the process
must be identified (identification phase). It is
recommended that the analyst conduct a semi-
structured interview, driven by questions that help to
understand the overall scope of the process. A
proposal of questions is presented in the section
After the questions for macro tasks identification
have been answered, providing new ways of thinking
about the process (DP7), the participant should
summarize the understanding of the macro process
and its main activities, taking the time to do it (DP4).
Finally, the last step is Modeling of the process
details. At this point, the macro tasks are already
identified and, it is time to learn the details, such as
responsibilities, interactions, transitions, rules, and
events. First, it is necessary to present the modeling
elements of the tool, recalling the basic concepts of
To demonstrate the use of the tool to the
participants, the analyst can represent the macro tasks
at the top of the whiteboard. That way, while he
demonstrates the use of the tool, he creates a
reference guide. Additionally, the analyst can also
draw the pool of the process with the swimlane of the
first participant-role identified, and then place the
start event. After this, participants should be
encouraged to detail each macro task, according to the
discovery phase.
The top-down design technique can aid in the
discovery of more details about the macro task, so
each task is examined until the desired level of detail
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
is reached. This human-centered activity (DP1)
promotes reflexive thinking, process thinking, and
new ways of thinking about the problem (DP4, DP6,
and DP7).
The process analyst can intervene by asking
questions about the process to guarantee the correct
use of the modeling concepts. But it is important that
he/she does not interfere by drawing conclusions
about activities, since this may decrease the
participation of business experts and make them mere
observers. Moreover, whenever necessary, the
analyst can also introduce a more specific BPMN
element to further enrich the process model. To do
this, he/she must adapt the base element (e.g.,
transforming a basic task into a user task or manual
task) by drawing the symbol corresponding to the
most specialized task. However, the concept must
always be presented to the participant, and his
understanding must be confirmed, so that knowledge
could be replicated in another situation by him.
Additionally, throughout this step, critical points of
the process and points of failure must be identified
and pointed out in the model; however, it is very
important that process improvements are not
addressed yet to prevent the participant from
contaminating the as-is process model with insights
of improvements that do not correspond to the actual
process performed.
Once the process has been detailed, the analyst
must validate it, corresponding to the as-is modeling
phase (sketch of the model). Therefore, the process
analyst should request participants to verbally
summarize the process model from the start to the end
to observe if any part of the process has not been
represented. It is also important to check if the
modeling goals were met.
4.3 Artifacts
To facilitate the application of Meet2Map, a script
was defined with reference to the experiment
designed by Luebbe & Weske (2012), in which the
following steps are defined: Step 1) Apply the
preliminary evaluation questionnaire; Step 2)
Conduct the interview to identify, discover and model
the processes; Step 3) Apply the step evaluation
About Step 1, the preliminary evaluation
questionnaire is composed of four questions:
1. Have you participated in a business process
mapping activity before?
2. Do you have any previous knowledge about
business process management, by articles,
books, or daily tasks?
3. Do you have knowledge of BPMN notation?
Have you used this notation?
4. Do you have experience with any process or
activity modeling language?
That questionnaire must be sent to the participant by
email and must be completed before the discovery
and modeling activity.
Considering Step 2, a roadmap is proposed,
according to the following activities:
Activity 1 Start the mapping session with a
presentation to introduce main concepts to the
team: Introducing the basic concepts of process
methodology; What is the business process
management and what is it for? What are
primary, managerial, and support processes?
What is an As-Is process? To present the basic
concepts of BPMN notation, the objectives of
the organization for mapping processes, the
methodology that will be used for the mapping
activity, and the mapping tool and collaborative
Activity 2 After preparing the team, begin the
interview for mapping the macro process as-is,
following a script with pre-defined questions:
What is the objective of the process? Why is the
process important to the organization? Who is
the client of the process? What is the customer's
expectation of the process? Who are the
suppliers of the process? How/when does the
process start? How/when does the process end?
What are the overall scope of the process and the
most important activities?
Activity 3 To demonstrate the modeling
technique and summarize the understanding of
the macro process and demonstrate the use of
the modeling tool, the process analyst should
model the macro process using the modeling
Activity 4 Start mapping to detail the process
using the collaborative modeling tool. Conduct
the participants in the as-is process model
construction and perform questions to identify
the parts of the process.
Activity 5 Once the process is modeled, ask
participants to flag existing problems in the
current process. Signalize problems directly in
the process using sticky notes that point to the
point of the problem that the process has.
Activity 6 Finally, the modeled process needs
to be validated by participants. For this, the
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come
process analyst must: Ask the participant to
verbally summarize the understanding of the
modeled as-is process; Review whether the
model made meets the reasons initially defined
for mapping the as-is process; Question if there
is any other information about the process that
the participant would like to share.
Regarding Step 3, questionnaires were defined
with the proposal to evaluate three main aspects: the
information provided; the modeling activity; and the
collaboration tool. These questions will be discussed
in the results section of the case study. It is important
to emphasize that the questionnaire was sent to the
participant by email, right after the modeling activity
was finished.
The case study was conducted within a company that
provides services to the electric sector. This company
had just acquired a new Enterprise Resource Planning
(ERP) system and needed to start modeling and
analyzing the current processes to align with the new
system. The scope of the project encompassed the
following areas of the company: Electrical
Management; Accounting (tax and patrimony);
Financial; Payroll and Point (Human Resources);
Purchasing and Inventory (Supplies); Logistics. In
total, 25 processes needed an analysis of conformance
to the new system. It was necessary to map in detail
how the processes were executed, observing activities
supported by the legacy software, manual activities,
rework due to the deficiency of the legacy software,
and business rules related to the processes. In this
context, the internal analyst (first author of this paper)
proposed to use the Meet2Map. It was selected four
processes to be modeled following the proposed
framework: Contract Billing (Electrical and Financial
Management); Employee recruitment (HR);
Maintenance of fleets (Logistics and Finance) and;
Purchasing (Supplies and Finance).
The selection of the participants was made in two
steps. The first selection was based on the
departments involved in the processes to seek the
support of the managers to identify all the key
participants in the processes. The second one
corresponded to the stage of identification of the
participants for the modeling activities (Preparation
for modeling). The identified participants were
involved in the modeling activities of the selected
processes, which were conducted by the researcher in
the role of the process analyst. The number of
participants for each process was: Kick-off Workshop
(6); Process 1 (3); Process 2 (2); Process 3 (2);
Process 4 (3). 80% of them had some coordination or
management function; which benefits the modeling
activity, considering their experience in the business.
Regarding the participants' experience time, 90% had
more than 2 years of experience in the area, with only
one participant with less than one year in the
company, who then participated in the modeling of
the Employee recruitment process as a listener. None
of the participants had performed process modeling
before, and only 40% of the participants had
participated as a collaborator in traditional modeling
activities based on interviews. It is worth noting that
a large part of the participants (80%) knew basic
concepts of business process management but had
never used these concepts in practice. This aspect
reinforces the importance of an introduction to the
theme for leveling the knowledge and the proposal.
Finally, 90% of the participants already knew some
language for control flow modeling and 40% of them
had already used this technique to model processes,
although none of the participants had previously used
The study was conducted as follows: 1) two
processes were modeled in a traditional way, without
the support of a collaborative modeling tool; 2) two
other processes were modeled using the tool.
5.1 Collaborative Modeling Process
The case study started with a kick-off meeting, for
which all the 6 leaders from the areas involved and
the project sponsor were invited. During this meeting,
the list of elected processes was presented together
with the organization's reasons for choosing them, the
methodology of work, and the structure of a form to
identify roles and participants. Finally, the deadlines
for returning the form and the agenda of the workshop
were defined. After the kick-off, an email was sent to
each leader, attaching the form, the presentation, and
the preliminary calendar of the mapping activities. As
far as the forms were being returned, the map of areas,
functions, and participants had been defined. The next
steps were the workshops for modeling each process.
To exemplify how they were conducted, we will
comment on two: first, using the traditional method
and; second, using the Meet2Map Framework.
The Contract Billing process was the first one to
be modeled in a traditional method. The goal of this
workshop was to identify the process, starting from
contract measurement, billing approval by the
contractor, registering in the Accounts Payable
system, receiving of payment, and conciliation. The
activity was performed as planned: all participants
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
have actively provided information about their
activities (2 leaders of the Electrical area, 1 supervisor
of the Accounts Payable and Receivable area, all of
them with 3-4 years of work in the company). The
workshop spent 2:34 hours. As main reports, the
participants declared that they were unaware of the
internal procedures of the other sector for the
implementation of the process and the participants
showed interest in knowing the work carried out by
the other area of the company. Clearly, some
weaknesses were evident in the first workshop: the
dependence on an interview script, which needs to be
detailed and precise to obtain quality answers; the low
motivation in answering questions that require more
dialogue; the difficulty in explaining processes from
memories and experiences; the lack of interactivity
between participants, which stimulates participation
and reasoning through information sharing. At the
end of each mapping workshop, a questionnaire was
sent out to evaluate the respective stage. These results
will be discussed in Section 5.3.
The second process mapped was the Purchasing
process (one of the most complex), following
Meet2Map Framework. The team identified all
phases of the process, from the demand to purchase,
quotation, approval, payment to delivery. The
workshop spent 3:41 hours. All participants (2 leaders
of the Supplies area, one supervisor of the Accounts
Payable and Receivable site, all of them with 2-4
years of work in the company) interacted actively
providing information about their activities, this time
generating an initial process design, as illustrated in
Figure 4. A clear picture of this process is available
in (Dutra, 2015).
Figure 4: Purchase process model.
All participants described the activities of their
department, as well as their activities. Despite the
longer duration, none of the participants felt
unmotivated or disinterested. Before each modeling
workshop, the researcher sent the team an email,
attaching the preliminary questionnaire link.
5.2 Collaborative Modeling Process
A questionnaire composed of open and closed
questions was used to collect data on the participants'
perceptions about the framework application,
organized into three groups: G1) information
provided, G2) modeling activity, and G3)
collaborative tool. Online questionnaires were
applied to all participants in anonymous mode and,
preserving the anonymity of the participants. It is
important to point out that the same questionnaire was
used for both situations, the processes modeled using
the collaborative modeling tool and the traditional
modeling through structured interviews.
The analysis approach was based on two ways of
organizing results: Unified evaluation, in which all
answers to the same question were grouped and
evaluated uniquely; Distinct evaluation, in which the
answers were separated into two groups, referring to
collaborative modeling and traditional modeling. The
goal was to assess if there is significant variation
between the techniques. Additionally, the data is
qualitative but uses a quantitative value scale to
analyze the data obtained from the closed questions
of the questionnaire. The closed questions verified the
degree of influence of the factors involved in the
modeling activity through the Likert scale. Thus,
quantitative responses replaced the qualitative scale:
I totally disagree (1), I partially disagree (2), Neither
agree nor disagree (3), I partially agree (4) and, I
totally agree (5). The Mean Ranking Index (MRI) was
used to analyze the items answered in each question.
MRI calculated the weighted average for each item,
based on the frequency of responses as presented in
the formula:
Mean Ranking Index (MRI) = WA / (NS), where WA
(Weighted Average) = Σ(fi.Vi); fi = Observed
frequency of each response for each item; Vi =
Value of each answer; NS = Number of subjects
5.3 Results and Discussion
The main goal of the Method for Collaborative
Modeling Processes is to involve all participants in
the joint effort of modeling the process supported by
a collaborative tool. Thus, it is necessary that the
We received the answers from 10 participants. Tables
2, 3, and 4 present the MRI for the questions of each
group. For the first group (G1), as shown in Table 2,
the results were considered positive, emphasizing the
need for efficient communication proposed by the
framework. The value of question Q1a (4.9) confirms
that the information presented by the analyst was
enough to guide the participants. That information
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come
consisted of the activity goals, introduction to BPM
and BPMN. This reinforces the importance of the
framework, which proposes the alignment of
knowledge and goals as a way to ensure the success
of the modeling. The values of questions Q1b (5.0)
and Q1c (4,8) emphasize the ability of the analyst to
inform the concepts.
Table 2: MRI for Group of Questions 1.
ID Question
Q1a The information was sufficient to carry
out the activit
Q1b The information was presented in a
clear way.
Q1c The information was presented
The results in Table 3 compare the responses
between the traditional (TM) and collaborative
modeling (CM) teams, separately.
Table 3: MRI for Group of Questions 2.
ID Question MRI
Q2a I felt motivated during the
5.0 4.0
Q2b I would participate in the
activity again for modeling
5.0 5.0
Q2c This activity helped me to
etter understand the
4.6 4.8
Q2d This activity can really help
me improve the current
4.8 4.8
Q2e The activit
was en
. 4.8 4.0
The second group of questions corresponds to the
perception of the participants about the modeling
activity. The results indirectly reflect the benefits of
the framework in providing a good roadmap
according to the following analysis. The values of
questions Q2a (5.0 / 4.0) and Q2e (4.8 / 4.0) reinforce
the benefits of the collaborative modeling tool since
there is a significant difference between the values for
the traditional and the collaborative modeling. This
result is in line with the proposal of the tool and
design principles. The values of questions Q2b (5.0 /
5.0), Q2c (4.6 / 4.8), and Q2d (4.8 / 4.8) support the
perception that the activity was performed properly,
showing that the participants in both cases were
motivated and willing to participate in more activities
of the type. The difference in the values of the Q2d
was not significant, and thus, it is not possible to
compare them.
The third group of questions (G3) corresponds to
the perception of the participants about usability and
utility aspects of the technique used for modeling, as
shown in Table 4.
Table 4: MRI for Group of Questions 3.
ID Question MRI
Q3a In my opinion, this technique is
fully adequate for process
5.0 4.4
Q3b I felt confident in using the
4.0 4.8
Q3c I agree that most people would
learn to use this technique
5.0 5.0
Q3d The notation adopted is
adequate for modeling
5.0 5.0
Q3e The notation used is very
licated to use.
1.2 1.2
Q3f I need the support of a
technician to be able to use the
2.6 2.6
Q3g The technique does not
encourage the contribution of
important observations.
1.0 1.2
Q3h I was enthusiastic about the
technique used for process
4.8 4.6
Q3i This technique aided to extract
my knowledge about the
5.0 4.8
The value of Q3a (5.0/4.4) presents the most
significant result for this group, since it indicates,
even with only a small difference, the participants'
perception that the modeling technique with the
collaborative modeling tool is better when compared
with the traditional one. Although the value of Q3c
(5.0/5.0) presents an equal result, it shows that all the
participants agreed that people would learn to use the
technique without problems. It was also a consensus
that the BPMN notation is suitable for process
modeling, this statement can be interpreted from the
values of questions Q3d (5,0/5,0) and Q3e (1,2/1,2).
The value of question Q3f (2.6/2.6) expresses those
participants agreed that the presence of an
experienced process analyst is required to perform the
mapping activity. The values of questions Q3g
(1,0/1,2), Q3h (4,8/4,6) and Q3i (5,0/4,8) underpin
the importance of the technique, and although they
present better values for the collaborative modeling
technique, the difference was very small, therefore.
This study confirmed the importance of preparing
the execution of the modeling task, allowing the
identification of critical success factors that the
process analyst must know. In addition, strategies to
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
promote the team's engagement during the activity
helped the improvement of the collaborative
modeling tool that transforms the domain analyst into
the agent responsible for modeling the process.
5.4 Research Threats and Limitations
This study has limitations and threats common to all
qualitative research: dependence on the application
context and lack of repeatability. In addition,
although action research has many advantages
because it is applied, empowering, collaborative and
democratic, it also has its flaws, especially in three
important aspects: the subjectivity of the researcher,
who may be over-involved or interpret results only
under his perception; the influence of power or lack
of it on the part of the researcher in the organizational
hierarchy, who in the role of subordinate or leader
may impact the results; and the time-consuming
process, considering an authentic ERP project and its
To mitigate these limitations and threats, this
study first sought to define the research in two cycles.
The first cycle sought to understand the problem
better and define the research objectives based on
actual experimentation with an existing proposal. In
the second experiment, the multidisciplinary nature of
the ERP project reduced the biases. As an IT
manager, the researcher has a position that facilitates
the articulation between other business area
managers, but without power influence. Still, the
survey involved several data collection tools, such as
questionnaires and interviews, preserving the original
data to avoid biased interpretations. To evaluate
results, the proposal to use a qualitative questionnaire
with the numerical value scale (Likert scale) sought
to attenuate the subjectivity of the analysis. In
addition, the collaborative process modeling included
review and corroboration steps for all involved,
avoiding misunderstandings and new biases. Finally,
this work has some limitations that prevent an in-
depth analysis of the framework's benefits.
Nevertheless, even with these limitations, Meet2Map
contributed to real-word ERP projects.
With the advancement of technologies in
organizations, the renewal of business management
systems, better known as ERPs, becomes frequent.
However, ERP projects are constantly challenged by
their characteristics and impacts on an organization's
business processes, transforming the activities and
tasks of its employees who are not always prepared
for the changes from the system. In this context, BPM
can be used to identify current processes and
understand future changes. However, in an
organization with low BPM maturity, where few or
no processes are documented and standardized,
process mapping becomes a significant challenge. As
a result, human capital becomes the primary source of
information about business processes and, therefore,
fundamental agents in ERP projects.
Thus, this paper proposes a framework that
presents clear recommendations on how to perform
the identification, discovery, and modeling phases of
the process life cycle, including support to the data
collection and detailing how to apply a collaborative
modeling tool to build the process model. In addition,
the definition of strategies to engage the team in ERP
projects showed up to be adequate for the case study
discussed: modeling the process with process analyst
together stakeholders allowed a detailed view of the
process, promoting the discussion and the emergence
of insights, which, traditionally, would be very
difficult to occur. The main contribution of this
research is a prescriptive solution for process
modeling in the context of ERP projects, which
includes: a process for discovery and modeling of As-
Is processes; an easy-to-use tool that carried out this
activity collaboratively, engaging its participants and;
that enables the management of this activity,
supporting its planning, execution, and follow-up.
From the scientific perspective, the research advances
in solutions for human-centered process modeling,
encouraging that the As-Is modeling activity could be
carried out with stakeholders involved in the process
(users, owners, and process managers), not only by
the analyst of the process. From the practical
perspective, we expect that the application of the
framework might improve the task of modeling
processes as a strategy to prepare the stakeholders for
future changes, achieving better inputs for the next
stage of the BPM life-cycle and ERP Project life-
As future work, we intend to conduct case studies
in different organizations and projects.
Adamides, E.D., Karacapilidis, N. (2006). A knowledge
centred framework for collaborative business process
modelling, Business Process Management Journal, Vol.
12 Issue: 5, pp.557-575.
Antunes, P., Simões, D., Carriço, L., Pino, J.A. (2013). An
end-user approach to business process modeling, In
ERP Projects in Organizations with Low Maturity in BPM: A Collaborative Approach to Understanding Changes to Come
Journal of Network and Computer Applications,
Volume 36, Issue 6, Pages 1466-1479.
Baldman R., Valle R., and Silva H. P. (2007).
Gerenciamento de Processos de Negócios: BPM
Business Process Management. 2a Edição. São Paulo.
Bhatti, T. R. Critical Success Factors for the
Implementation of Enterprise Resource Planning
(ERP): Empirical Validation. The second International
Conference on Innovation in Information Technology,
Dubai, 2005.
Bonini, L. A., & Sbragia, R. (2012). O Modelo de Design
Thinking como indutor da Inovação nas empresas: um
estudo empírico. Revista de Gestão e Projetos, 2.
Benedict T., Bilodeau N., and Vitkus P. (2013). BPM Cbok
Version 3.0: Guide to the Business Process
Management Common Body of Knowledge.
Createspace Independent Publishing Platform; 3rd Ed.
Brown, T. (2009). Change by design: how design thinking
transforms organizations and inspires innovation. New
York: Harper Business.
Dumas, M., Rosa, M. L., Mendling, J. and Reijers, H.
(2013). Fundamentals of Business Process
Management, Springer.
Dutra, D. L. 2015. Um Framework para Mapeamento de
Processos As-Is apoiado por Design Thinking (A
Framework for Mapping As-Is Processes supported by
Design Thinking). Master Dissertation, Centro de
Informática, UFPE, Brazil. 2015.
Davenport, SL Jarvenpaa, MC Beers. (1996). Improving
knowledge work processes. TH Sloan management
review 37 (4), 53.
Davis, A., Dieste O., Hickey A. and, Juristo N. (2006).
Effectiveness of requirements elicitation techniques:
Empirical results derived from a systematic review. In:
14th IEEE International Conference Requirements
Cereja J.R., Santoro F.M., Gorbacheva E., Matzner M.
(2017). Application of the Design Thinking Approach
to Process Redesign at an Insurance Company in Brazil.
In: vom Brocke J., Mendling J. (eds) BPM Cases.
Forster, S., Pinggera, J., Weber, B. (2012). Collaborative
Business Process Modeling. EMISA 2012: 81-94.
Jeston, J., Nelis, J. (2006). BPM Practical Guidelines to
Successful Implementations.
Van Looy, A., Poels, P. (2019). A practitioners’ point of
view on how digital innovation will shape the future of
business process management: towards a research
agenda. 52nd Hawaii Int. Conf. on System Sciences,
Maui, pp. 6448-6457.
Johansson, B., Ruivo, P. (2013). Exploring Factors for
Adopting ERP as SaaS. Procedia Technology 9 ( 2013)
94 – 99.
Lechesa, M., Seymour, L., and Schuler, J. (2012). ERP
Software as Service (SaaS): Factors Affecting
Adoption in South Africa. CONFENIS 2011, LNBIP
105, pp. 152–167.
Luebbe, A., Weske, A. (2012). The effect of tangible media
on individuals in business process modeling.
Technische Berichte Nr. 41. University of Postdam,
Merriam, Sharan B. and Tisdell, Elizabeth J. (2015)
"Qualitative Research: A Guide to Design and
Implementation". Jossey-Bass, Fourth Edition.
Miron, E.T., Muck,C., Karagiannis, D. (2019).
Transforming Haptic Storyboards into Diagrammatic
Models: The Scene2Model Tool. 52nd Hawaii Int.
Conf. on System Sciences, Maui, pp. 541-550.
Recker, J. (2012). From Product Innovation to
Organizational Innovation and what that has to do
with Business Process Management. BPTrends, Vol. 9,
No. 6, pp. 1-7.
Patton, M. Q. (2002). Qualitative Research & Evaluation
Methods. 3rd. ed. California: Sage Publications.
Persson, A. Enterprise modelling in practice: situational
factors and their influence on adopting a participative
approach. PhD thesis, Dept. of Computer and Systems
Sciences, Stockholm University, 2001.
Rittgen, P. (2009). Collaborative Modeling - A Design
Science Approach. In: Proceedings of the 42nd Hawaii
International Conference on Systems Sciences (HICSS-
42), Wailoloa Big Island, Hawaii, USA, January, 5-8.
Rittgen, P. (2010) Success factors of e-collaboration in
business process modeling. In Pernici, B., ed.:
Conference on Advanced Information Systems
Engineering (CAiSE), pp. 24-37.
Schmitt, E. ERP Software as a Service (SaaS). Government
CRM Software. Access: 08/30/2015.
Sedera, D.; Gable, G.; Chan, T. (2003). Knowledge
management for ERP success. Proceedings of Seventh
the Pacific Asia Conference on Information Systems,
Adelaide, p. 1405-1420, Julho.
Sedera, W., Gable, G., Rosemann, M., Smyth, R. (2004). A
success model for business process modeling: findings
from a multiple study. In: Proceedings of The 8th
Pacific-Asia Conference on Information Systems,
Shangai, China.
Seethamraju, R (2014). Adoption of Software as a Service
(SaaS) Enterprise Resource Planning (ERP) Systems in
Small and Medium Sized Enterprises (SMEs). Springer
Science. Business Media New York.
Santos, S. C., Santana C., Elihimas, J., 2018. "Critical
Success Factors for ERP Implementation in Sector
Public: An Analysis Based on Literature and a Real
Case", European Conference on Information Systems.
Prata, A. M., Santos S. C., 2019. "Towards Organizational
Transformations: A Manageable Model to
Communicate Changes", Americas Conference on
Information Systems (AMCIS 2019).
Taube, L. R.; Gargeya , V. B (2005). An Analysis of ERP
System Implementions: A Methodology. The Business
Review, Cambridge, v. 4, n. 1
ICEIS 2022 - 24th International Conference on Enterprise Information Systems