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.

1 INTRODUCTION

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

https://orcid.org/0000-0002-7903-9981

https://orcid.org/0000-0003-3421-1984

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

385

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.

2 THEORETICAL

BACKGROUND

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

Modeling

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

386

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,

2019).

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

rocess.

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

rocess.

DP6 Process thinking Ensure that process

stakeholders can analyze

their processes, think about

the problems faced, and

propose possible

rovement.

DP7 New ways of

thinking

In this context, about the

rocesses.

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

387

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

Enterprises.

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.

3 RESEARCH METHODOLOGY

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

388

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

used.

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).

4 Meet2Map FRAMEWORK

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

389

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

steps.

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

“Artifacts”.

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

BPMN.

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

390

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

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

questionnaire.

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

modeling.

 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

tool.

 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

391

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.

5 CASE STUDY

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

BPMN.

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

392

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

393

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

4.9

Q1b The information was presented in a

clear way.

5.0

Q1c The information was presented

objectively.

4.8

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

MRI

Q2a I felt motivated during the

activit

5.0 4.0

Q2b I would participate in the

activity again for modeling

another

rocess.

5.0 5.0

Q2c This activity helped me to

etter understand the

rocess.

4.6 4.8

Q2d This activity can really help

me improve the current

rocess.

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

MRI

Q3a In my opinion, this technique is

fully adequate for process

modelin

5.0 4.4

Q3b I felt confident in using the

techni

ue.

4.0 4.8

Q3c I agree that most people would

learn to use this technique

without

roblems.

5.0 5.0

Q3d The notation adopted is

adequate for modeling

rocesses.

5.0 5.0

Q3e The notation used is very

com

licated to use.

1.2 1.2

Q3f I need the support of a

technician to be able to use the

techni

ue.

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

modeling.

4.8 4.6

Q3i This technique aided to extract

my knowledge about the

rocess.

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

394

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

complexity.

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.

6 CONCLUSIONS

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-

cycle.

As future work, we intend to conduct case studies

in different organizations and projects.

REFERENCES

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

395

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

Engineering.

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,

Germany.

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

396