Int. J. Business Information Systems, Vol. 8, No.

1, 2011 23

A decision algorithm for ERP systems alignment

Sarra Mamoghli* and Virginie Goepp

INSA de Strasbourg – LGeCo Equipe Licia,
24, Boulevard de la Victoire 67084 – Strasbourg Cedex, France
E-mail: sarra.mamoghli@insa-strasbourg.fr
E-mail: virginie.goepp@insa-strasbourg.fr
*Corresponding author

Valérie Botta-Genoulaz
Université de Lyon,
INSA de Lyon – Liesp,
F- 69621 – Villeurbanne Cedex, France
E-mail: valerie.botta@insa-lyon.fr

Abstract: Information systems (IS) are now more and more based on
‘off-the-shelf products’ such as enterprise resource planning (ERP) systems.
These offer a generic solution apart from the company in which they will be set
up. Thus, an essential success factor of this set up is a consistent alignment with
the company. The methods suggested to support this alignment, which are
described and analysed in this paper, especially insist on the modelling
techniques to use without sticking to the characterisation of the various
alignment and misalignment situations. Therefore, an algorithm to identify
them is proposed. It formalised those situations and associate decisions to be
taken in order to mitigate the misalignment risks.

Keywords: ERP project; business process reengineering; alignment; enterprise

modelling; business information systems; decision algorithm.

Reference to this paper should be made as follows: Mamoghli, S., Goepp, V.

and Botta-Genoulaz, V. (2011) ‘A decision algorithm for ERP systems
alignment’, Int. J. Business Information Systems, Vol. 8, No. 1, pp.23–45.

Biographical notes: Sarra Mamoghli is a PhD student in the National Institute

of Applied Sciences of Strasbourg in France (INSA-Strasbourg) and in the
National Institute of Applied Sciences of Lyon in France (INSA-Lyon). She
holds a Master’s degree in Computer Sciences from INSA de Lyon in 2009.
Her researches concern the ERP systems and their alignment with the strategy
of the company.

Virginie Goepp is an Associate Professor in the National Institute of Applied

Sciences of Strasbourg in France (INSA-Strasbourg). She defended her PhD
thesis on ‘Contingency and modularity in production information system
projects’ in 2003 at the University of Nancy (France). Her current research
interests include the design and management of technical information systems.
Particularly she is interested into the alignment between these systems and the
enterprise. These results are applied, among others, on the information systems
based on ‘off the shelf’ products like ERP systems.

Copyright © 2011 Inderscience Enterprises Ltd.

24 S. Mamoghli et al.

Valérie Botta-Genoulaz is a Professor in the Industrial Engineering Department

of the National Institute of Applied Sciences of Lyon (INSA-Lyon), France,
and do research in Laboratory of Information Science for Enterprise and
Production Systems (LIESP). With five years experience in the industry, and a
Certified Application Consultant in Production Planning for SAP R/3, her
research interests deal with operation planning, supply chain management,
information sharing, ERP systems, collaborative practices, and their impacts on
enterprise performance.

1 Introduction

Information systems (IS) play a central role in manufacturing companies and are
increasingly based on ‘off-the-shelf’ products. In this paper we focus on enterprise
resource planning (ERP) systems, whose implementation is not always a success. Many
studies, such as ‘the CHAOS report’ (http://www.standishgroup.com/chaos) in 1995 by
the Standish Group, or the ‘LLC’ (http://www.robbinsgioia.com/new_events/
012802_erp.aspx) report by Robbins-Gioia in 2002, analyse the failure rates of
such implementation in terms of over-spending, deadlines, and unsatisfied requirements.
Darras (2004) shows that the failure rate reported in these studies ranges from
51% to 69%. A number of authors (e.g., Ramayah et al., 2007; Kamhawi and
Gunasekaran, 2009) have studied the critical success factors of ERP systems
implementation. Among them, there are two major kinds of factors: those linked
to the stakeholders and those linked to the project. For the stakeholders, there are the
difficulties linked to the culture of change, for example a poor understanding of the
ERP system functioning that leads to its rejection by the end-users. Secondly, there
are the difficulties that stem from poor project management such as the decisions
linked to the functional perimeter and the composition and involvement of the
project team. In this paper we focus on the functional perimeter and particularly on
the fit between the ERP system and the company. As the implementation of the ERP
systems implies their alignment with the enterprise’s needs, a consistent alignment
constitutes one of the keys of successful implementation (Millet and Botta-Genoulaz,
2008).
The second section presents the ERP systems/enterprise alignment problem. It details
the different choices that have to be made during the ERP project, especially during the
selection and deployment phases. The third section reviews the methods suggested in the
literature to support those choices for both phases of presents the ERP systems/enterprise
alignment problem. It details the different choices that have to be made during the ERP
project. Some methods are based on the use of questionnaires and others on the use of
models. Those that are based on the match between the standard solution models and the
enterprise needs models are analysed in the fourth section. This analysis emphasises their
characteristics with regard to formalisms used in the models, and to the alignment
approach. We will see that the studied methods do not insist sufficiently on the various
alignment and misalignment situations between the processes to be put under control and
those proposed by the ERP system. Therefore, in the fifth section we propose a decision
algorithm that formalises all situations of alignment and misalignment between the ERP
system and the company’s processes. Situations of alignment and misalignment can thus
 A decision algorithm for ERP systems alignment 25

be identified and associated with an adequate decision. In the sixth section we illustrate
the proposed algorithm in the case of an SME in the region of Strasbourg (France)
running an ERP project. Finally, in the seventh section we conclude and give some
research perspectives.

2 The ERP system alignment problem

One of the main features of ERP systems is that they offer a generic solution which has to
be customised by a specific company depending on its own requirements. This means
that during the implementation project, also called the ERP project, the ‘alignment
between the ERP system and the enterprise’ has to be worked out.
We have first studied the different life cycles of ERP projects proposed in the
literature (Esteves, 1999; Darras, 2004; Quellenec, 2007; Klee, 2005; Giachetti and
Truex, 2009). The aim was twofold: to propose our own view of this life cycle, and to
identify the stages during which alignment occurs. Our view is that the ERP project life
cycle is composed of the selection and deployment phases. The first phase consists of the
following stages: opportunity and feasibility study, needs specification, analysis of call
for tenders, and editor’s choice. The second phase is composed of: launching, adequacy,
configuration, and integration and releasing.
Several critical issues influence the success of an ERP project, including the users’
training, the ease of use of the ERP system, the composition of the teamwork, the
top-management involvement, etc. (Botta-Genoulaz and Millet, 2005; Motwani et al.,
2008; Ramayah et al., 2007; Singla and Goyal, 2007; Kamhawi and Gunasekaran, 2009;
Prakash and Rolland, 2001; Madapusi and D’Souza, 2004). We focus primarily on one of
them: the alignment between the deployed ERP system and the enterprise. This
problematic is underlined by Prakash and Rolland (2001) and Madapusi and D’Souza
(2004) and requires a choice to be made during:

• Selection, especially during the analysis of call offer stage. This stage makes it
possible to choose the ERP system best suited to the needs of the company.

• Deployment and, more precisely, during the adequacy stage. Since the ERP system
offers a generic solution, this stage enables to choose the company’s processes that
have to be put under control and the way to put them under control with the ERP
system.
Many authors show that the decisions that have to be made towards these choices are
tricky (Soh et al., 2000; Davenport, 1998; Light, 2005; Daneva and Wieringa, 2006). For
example, when the corporate culture is completely different to that offered by the ERP
system, adopting the logic of the ERP system can entail a risk. Moreover, companies
have to be careful about not losing their competitive advantage by abandoning some of
their carrier strategies for more standard strategies imposed by the ERP system. It has
been shown (Etien and Rolland, 2005; Botta-Genoulaz, 2007; Millet and Botta-Genoulaz,
2008) that some problems can stem from a company’s lack of adaptation to its ERP
system. Methods to support these choices are thus essential. In the following section we
review these methods.
26 S. Mamoghli et al.

3 Literature review

In this section we present the methods that deal with the ERP system/enterprise
alignment problem during the selection and deployment phases. The methods proposed
for the selection phase are based on the use of either questionnaires or models. Those for
the deployment are all model-based.
The methods based on the use of questionnaires (Wei and Wang, 2002; Tournant and
Azan, 2003; Yazgan et al., 2009) consist in providing a questionnaire to each competing
editor. The questions to be answered are related to software evaluation criteria such as the
editor’s reputation, the costs suggested by the editor for the ERP system’s proposed set
up, etc. The editor’s choice is then based on the one that responds best to different
criteria.
The model-based methods, which are completely different from those recommending
the use of questionnaires, are detailed in the following sub-section. Each author studied
proposes a set of models, a related formalism, and an alignment approach using the
models. Their methods are described in the following sub-section according to those
three points.

3.1 Description of alignment methods

3.1.1 Proposition of Wu et al.
For the selection phase, Wu et al. (2007) propose a process for matching what the
company wants – i.e., its wishes – with the possibilities offered by the ERP system. This
matching process takes place on three levels: intentional for the processes’ goals,
functional for the sequence of the processes’ activities, and informational for the data
produced or used by them.
Wu et al. use the adequate unified modelling language (UML) diagram for each of
those levels. To the intentional level corresponds the goal-oriented use case; to the
functional level the activity diagram; and to the informational level the drawing and the
data glossary.
To achieve the alignment, Wu et al. propose to locate the misfits between each ERP
system under study and the company. The chosen ERP system is the one that presents the
minimum of misfits and the maximum of solutions for those misfits. Thus, for the
intentional level, the matching process is done visually. Then, for the functional and
informational levels, algorithms are proposed to match activity diagrams, data glossaries
or drawings. Finally, a list of misfits is drawn up for each competing ERP system.

3.1.2 Proposition of Prakash and Rolland

For the deployment phase, Prakash and Rolland (2001) propose the comparison of three
models. These are the ‘to-be MAP’ for the enterprise’s wishes, the ‘as-is MAP’
representing the existing situation of the enterprise, and the ‘ERP MAP’ for what the
ERP system proposes. The result of the matching process is the ‘matched MAP’ which
corresponds to what will be implemented in the ERP system.
Prakash and Rolland (2001) use the MAP formalism, which is also used in Salinesi
and Rolland (2003). Each model is represented by a graph in which the functionalities
(wished, proposed by the ERP system, etc.) are associated with intentions (represented by
 A decision algorithm for ERP systems alignment 27

nodes) and strategies (represented by edges) to achieve them. A section is the association
of two intentions and a strategy to link one of these two intentions to the other. Start and
Stop intentions are used respectively for the beginning and the end of the MAP.
These authors propose first to build the ‘to-be MAP’, ‘as-is MAP’, and ‘ERP MAP’.
The construction of the ‘matched MAP’ can be driven by one of them. In fact, the authors
suggest considering one of the first three models constructed, and comparing it with the
other two. For each section of the driven model, we consider the intention and strategy of
the corresponding MAP from start to stop. This is done in order to decide whether they
a match the requirements exactly and so must be included in the ‘matched MAP’
b need adaptation before their inclusion in the ‘matched MAP’
c are irrelevant.

3.1.3 Proposition of Soffer et al.

For the deployment phase, Soffer et al. (2003, 2005) propose a matching process in order
to match the model of what the ERP system offers with the model of the company’s
wishes. The latter model is then progressively transformed in order to obtain the model of
what should be implemented.
Soffer et al. (2003, 2005) use the object-process methodology (OPM) language and,
in particular, the object-process diagram (OPD) diagram. This diagram serves to
represent the processes, their objects (affected or used) and the options related to both of
them.
The authors propose two iterative alignment processes: the single requirement
matching (SRM) and the bottom-up aggregation (BUA). The former serves to measure
the similarity score between the OPD diagrams of the company’s wishes and those of the
ERP system. The latter analyses the scores obtained previously, and check the coherence
of the OPD diagram of the company’s wishes. As these wishes were formulated by
different members of the company, they may be incompatible. After the score analysis
and the check, some reformulations are carried out on this model. The SRM and BUA
processes are then repeated, until the experts are satisfied. The modifications made to the
model of the company’s wishes are either ‘splitting’, ‘abandoning’ or ‘mapping’
operations. The first one consists in the company adopting new processes, the second in
giving up processes, and the third in adjusting the functioning of some company
processes so that they fit the ERP system. In the latter case, the new and the former
processes have the same objectives but function differently. However, the authors do not
link these operations to specific model configuration situations.

3.1.4 Proposition of Darras

Darras (2004) proposes a complete approach dealing with both the selection and the
deployment phases. It is based on process models.
For the selection phase, he proposes a comparison of the macroscopic model of what
the ERP system offers, with a model of the enterprise’s wishes, for each ERP system. For
the deployment phase, the comparison deals with models that are more detailed.
Darras (2004) proposes that the particular model of the company (company’s wishes) be
matched with the reference model (what the ERP system proposes) in order to finally
obtain the IS enterprise model (what will be implemented). He uses the GRAI
grid-oriented use case of the UML to represent the functional perimeter. Every decision
28 S. Mamoghli et al.

centre of the GRAI grid corresponds to a use case that allows one to highlight the main
functionalities wished by the enterprise or proposed by the ERP system. Each use case
constitutes an input for a process, represented in the form of an UML activity diagram.
For the selection phase, the macroscopic comparison proposed by Darras (2004)
allows us to analyse the functional cover rate of each competing ERP system and their
possibilities of extension towards the company’s uncovered needs. The ERP system that
covers the maximum number of functionalities and extension possibilities is therefore
chosen. However, it is not specified how the models can be compared. Furthermore, for
the deployment phase, Darras (2004) proposes a mapping mechanism that is based on the
matching process of similar elements between activity diagrams of the particular model
of the company, on the one hand, and the reference model, on the other hand. Similar
elements are put into the IS enterprise model that is built gradually during the process of
visually matching the activities of each model one-by-one.

3.1.5 Proposition of Millet

Millet (2008) proposes an alignment process consisting in the formalisation of the
processes corresponding to the company’s objectives, and of the different solutions
proposed in the ERP system. The connection between these two models leads to the
construction of what will be implemented.
Millet uses a ‘meta model of integration’ inspired by the Meta model 19440 which he
extends with the SCOR reference model and his own Meta model of the ERP system. It
provides constructs that can be instantiated in objects. These objects, like processes or
data, form the integration graph and are interconnected by relations of dependence. For
example, a process and a data are connected if the process uses the data.
To build the model of what will be implemented in the ERP system, Millet (2008)
proposes a comparison between the model representing the solutions suggested by the
ERP system, and the one representing the company's objectives. According to Millet, this
comparison is the base of alignment. It corresponds to a study of the possibility to
implement the company’s needs through the ERP system. The aim is to check the
coherence of these needs with the constraints of the ERP system.
3.1.6 Proposition of Scheer et al.
Architecture of integrated information systems (ARIS) (Scheer et al., 2002; Scheer and
Nuttgens, 2000) is a framework that provides tools allowing studying the alignment of
the processes of the ERP system with those of the company. This framework is used
during the development of ERP systems.
First, a part of the framework called the ‘ARIS House of Business Engineering’
(HOBE) provides tools for choosing the processes to implement in the ERP system.
Those tools enable the analysis of the company’s existing processes, their improvement,
and their simulation to check their performance.
Kirchmer et al. (2002) propose a framework called the ‘HOUSE’ that guides process
representation according to five views. ARIS does not require a particular language to
describe those views. According to Bézivin et al. (1999), the ‘event driven process chain’
(EPC) language is adequate to represent them. EPC enables one to represent the sequence
of process activities in the form of a diagram (function view), and to model information
concerning the organisational units in charge of the processing of the activities
(organisational view). The data that are handled (data view) or produced (output view) by
 A decision algorithm for ERP systems alignment 29

the processes can also be represented. The interaction between those four views
constitutes the fifth one. EPC is able to represent this interaction and not only each view
separately.
Finally, as noted above, ARIS does not provide an approach supporting the alignment
process but only tools that can help and accompany it. ‘ARIS simulation’
(ARIS platform, http://www.ids-scheer.fr/fr/index_fr.html), for example, is a tool that
allows one to simulate, analyse and customise the existing processes of the company. It is
thus possible, thanks to ARIS tools, to establish a model of the enterprise’s wishes.

3.1.7 Proposition of Etien

Etien (2007) suggests the ACEM method to correct the alignment between the ERP
system and the enterprise. This method supposes that the ERP system is already set up in
the company. We present this method because we assume that it is easily applicable to
the deployment phase. The only difference lies in the fact that the correction of the
alignment is more important during this phase.
The author proposes six models:
1 the existing situations of the company with the ‘as-is BM’
2 the ERP system functionalities with the ‘as-is SFM’
3 the combination of these two models which produces the ‘pivot’ model; the
adjustment of the pivot model during the alignment process which leads to a new
model
4 the ‘modified pivot’ model; and, finally, the two components of the latter which
leads two new models
5 the ‘to-be BM’
6 the ‘to-be SFM.
The latter two models represent the situations of, respectively, the company and the ERP
system after the transformation of the ‘pivot model’ into the ‘modified pivot’ model.
Etien (2007) uses an extended version of the MAP formalism and the UML language.
Each of the six models is formalised in a MAP. For each MAP section of these models,
the following elements are detailed: the pre-condition, the post-condition, the affected
resources, the ‘trigger’ actor, and the corresponding management rules. A class diagram
of the involved objects in the model is associated with each MAP model.
The ACEM method consists first in building the three ‘as-is’ models. The ‘modified
pivot’ model is then built progressively through transformation of the ‘pivot’ model. This
transformation is based on actions stemming from so-called ‘evolution requirements’.
These will have been identified previously, for example, through analysis of the ‘pivot’
model. The ‘evolution requirements’ can therefore represent dysfunctions, misalignments
between the ERP system and the company, or improvement needs linked, for example, to
contextual strengths. Finally, to support the model transformation, each action is linked to
a set of pre-defined operations on the ‘pivot’ model.

3.1.8 Synthesis
Table 1 sums up the contribution of each author. It shows, for each proposition, the
phase(s) of the ERP project life cycle (selection and deployment) concerned, and the type
30 S. Mamoghli et al.

of method proposed (questionnaire or model-based). As the majority of the methods are

model-based, we analyse them in more detail in the following sub-section.
Table 1 placement of the authors according to the phase of the ERP project in which they
intervene and the type of approach proposed

ERP project phase Type of approach

Reference
Selection Deployment Questionnaire Model
Wei and Wang (2002) × ×
Tournant and Azan (2003) × ×
Yazgan et al. (2009) × ×
Wu et al. (2007) × ×
Darras (2004) × × ×
Prakrash and Rolland (2001) × ×
Etien (2007) × ×
Soffer et al. (2003, 2005) × ×
Millet (2008) × ×
Scheer et al. (2002) and
× ×
Scheer and Nuttgens (2000)

3.2 Method comparative analysis

Each method proposes the use of modelling formalisms. To analyse them we use the
approach developed by Izza (2007) who, within the Easy-DIM1 project, reviews the
enterprise models and their classification criteria. Among the proposed criteria, we
consider the treated views and the nature of use.
Each studied method proposes a process to tackle the alignment. This process is
analysed according to three key points. The first one is the models chosen in each method
to implement this alignment process. The second one is the measurement techniques used
to establish a connection between the models of what the ERP system proposes and the
company’s wishes. Finally, the last one is the proposed alignment process.
This analysis allows us to highlight the strengths and weaknesses of the studied
methods. It thus enables us to identify possible obstacles in the progress of the alignment
process and thus in the decision-making towards the choices which appear during this
process. The comparison between each method according to those different points is
shown in Table 2.

3.2.1 Analysis of the modelling formalism

Concerning the modelling views, only MAP associated with UML, as Etien (2007) uses
it, allows for all the views to be represented (intentional, functional, resource-related,
organisational and informational). The integration diagram and the OPC language allow
for all of them, except for the intentional view, to be represented. OPM and UML, as they
are used in the studied methods, allow for the informational and functional views to be
represented. MAP as it is used by Prakash and Rolland (2001) allows for the intentional
and functional views to be represented on a macroscopic level.
 Table 2

Formalism (language and diagram used) Alignment process

Author
Diagram or langage View(s) Nature of use Models Approach
Prakash and MAP Intentional and Communicate, analyse, 1 Model of the existing of the company Alignment process: matching process of the three first models
Rolland functional reason, pilot the 2 Model of the needs of the company while generating the fourth one
functioning 3 Model of what proposes the ERP Measurement technique: visual
system
4 Model of what will be implemented
Soffer et al. OPD diagram of OPM Informational and Communicate, analyse, 1 Model of the needs of the company Alignment process: matching process of the two first models
functional reason, pilot the 2 Model of what proposes the ERP and progressive modification of the first one to obtain the
functioning system third one
3 Model of what will be implemented Measurement technique: similarity measurement of the
entities and the links between entities
Darras GRAI grid oriented use Functional but not Communicate, analyse 1 Model of the needs of the company Alignment process: matching process of the two first models
(adequacy) case detailed 2 Model of what proposes the ERP while generating the third one
system Measurement technique: match of similar elements
3 Model of what will be implemented
Activity diagram of Functional detailed Communicate, analyse,
Comparison of the methods of the authors studied
A decision algorithm for ERP systems alignment

UML for each use case reason, pilot the

of the GRAI grid functioning
Class diagram of UML Informational Concept
Millet Integration graph Informational, Communicate, analyse, 1 Model of the needs of the company Alignment process: matching process of the two first models
organisational, reason, pilot the 2 Model of what proposes the ERP while generating the third one
functional, of functioning system Measurement technique: comparision
resources 3 Model of what will be implemented
31
 32

Table 2

Formalism (language and diagram used) Alignment process

Author
Diagram or langage View(s) Nature of use Models Approach
Scheer et al. OPC Informational, Communicate, analyse, 1 Model of the existing of the company There is not an alignment process but a proposition of tools
functional, reason, pilot the 2 Model of the needs of the company allowing the alignment of the processes
organisational, of functioning 3 Models of what proposes the ERP
resources
S. Mamoghli et al.

system
4 Model of what will be implemented
Darras GRAI grid Functional detailed Communicate, analyse, 1 Model of the needs of the company Alignment process: matching process of the two models to
(selection) reason, pilot the 2 Models of what proposes the ERP obtain the cover rate and extension possibilities of the second
functioning system one toward the first one
Measurement technique: not specified
Wu et al. Use Case diagram of Intentional Communicate, analyse, 1 Model of the needs of the company Alignment process: matching process of two models to obtain
UML oriented goals reason 2 Models of what proposes the ERP a list of misftis
system Measurement technique: comparison algorithm of the activity
diagrams, the drawings and the data glossaries
Activity diagram of Functional and Communicate, analyse,
UML with drawings informational reason
and data glossaries for
each activity
Etien MAP Intentional, Analyse, reason, pilot 1 Model of the existing of the company Alignment process: union of the first two models to obtain
functional, the functioning 2 Model of what proposes the ERP the third one, progressive modification of the latter to obtain
organisational, of system the fourth model which is separated into the fifth and sixth
resources 3 Model of what will be implemented ones
4 Model of the company with the Measurement technique: observation of the third model and
Comparison of the methods of the authors studied (continued)

implementation of the needs use of metrics

5 Model of the union of 1 and 2
6 Model of the union of 3 and 4
Class diagram of UML Informationnel Concept
 A decision algorithm for ERP systems alignment 33

Each author has his or her own idea of the elements to be compared between
the proposals of the ERP system and the wishes of the company. We think that
the alignment between the desired processes and those proposed by the ERP system
should not be limited to the functional view, but should also include other views. This
alignment concerns, first, the goals of the processes and their activity sequence. It
however also implies a choice of the format and type of the used or produced data and
documents, as well as the organisational units and the material resources in charge of
these activities.
Furthermore, we see that the use of modelling and of these formalisms are primarily
intended to facilitate communication between the members of the company and the
experts, and serve to find a common language. The mechanisms used to build them must
therefore be simple, but that is not always the case. For example, the analysis tools used
in the integration graph require long calculations whose complexity increases when they
have to be applied to real companies.

3.2.2 Analysis of the alignment process

Each proposed alignment process requires some models to be worked out. All the authors
propose to build the models representing the company’s wishes, what the ERP system
proposes, and what will be implemented in the ERP system. Only some methods, like
those of Prakash and Rolland (2001), or Etien’s, propose the construction of the company
as-is model. Building this model is nevertheless necessary to ensure that the difference
between the company’s present and what will be implemented in the future is not too
large. Once the software package is deployed, a too wide variation can lead to failures
(Avila et al., 2009). Etien’s idea is therefore to represent both the ERP system and the
company in the pivot model, with the aim of not deviating from one of them during the
alignment process.
The methods furthermore recommend matching the model representing what the ERP
system proposes with the model of the company’s wishes, in order to obtain the model of
what will be implemented. However, the measuring techniques opted for are not always
well formalised. In the proposition of Darras (2004), for example, we only know that the
activities of the two models are put in one-to-one correspondence and this for each
activity. There are no tools guiding the order in which to study the activities and the
comparison between them. Only Soffer et al. (2003, 2005); Etien (2007); and Wu et al.
(2007), propose techniques to calculate the distance between models. The potential
situations of alignment and misalignment between the ERP system and the company can
be deduced from this distance.
All the authors present the alignment process in a fair amount of detail. The order of
use of the models, the role of each model in the alignment process and the steps in the
process are always well explained, except for Prakash and Rolland (2001). These authors
do not propose a set of pre-defined steps for their model-driven alignment process. For
example, the process can be driven by one of the three models built at the outset
(‘to-be MAP’, ‘as-is MAP’, and ‘ERP MAP’). However, once one of the models is
chosen, there is no guide on how to continue the matching process with the other
remaining models. Finally, the methods do not adequately formalise the various
alignment and misalignment situations between the models of what the ERP system
proposes and what the company wishes, or the required decisions. Those decisions are
34 S. Mamoghli et al.

however important because they bring to the construction of the model corresponding to
what will be implemented. Only Soffer et al. (2003, 2005) have begun to work on this
point.

3.2.3 Synthesis
We conclude from this section that the authors insist mainly on the formalisms that they
use, and on the matching techniques, which are well developed. However, the methods
do not enable us to emphasise enough the situations of misalignment between the
company's needs and those supported by the ERP system. They do not drive the
decision-making towards these situations. Hence, our proposition is an algorithm to
identify the alignment and misalignment situations as well as the related decisions. It
constitutes the continuation of the work of Soffer et al. (2003, 2005).

4 Proposition for a decision algorithm

The purpose of this section is to present our decision algorithm. It formalises both
the various situations of alignment and misalignment between the ERP system and
the company and the kind of adequate decisions to be made in order to tackle
these situations. We develop, firstly, the situations that represent a typology of aligned
and misaligned situations, and then present our algorithm linking situations and
decisions.

4.2 A typology of alignment and misalignment situations

This section details the different alignment and misalignment situations. These are
defined in terms of involved models and a configuration of matched modelling views of
these models.

4.1.1 The involved models

To detail the situations, we first present the models used to study them. The analysis of
the potential alignment and misalignment implies four models:

• The ‘as-wished’ model, representing the company’s wishes.

• The ‘as-is’ model, representing the existing organisation. This model enables us to
deduce a part of the ‘as-wished’ model.

• The ‘might-be’ model, representing the needs supported by the ERP system.

• The ‘to-be’ model, representing what will be implemented. This model should
result from the decisions made to tackle the various alignment and misalignment
situations. In our approach, the ‘as-wished’ and ‘might-be’ models are matched to
obtain the ‘to-be’ model as shown in Figure 1. It is during this matching process that
the different situations depending on different modelling views happen. The
following sub-section details the link between modelling views and alignment
situations.
 A decision algorithm for ERP systems alignment 35

Figure 1 Models involved in the study of alignment and misalignment situations

4.1.2 Alignment situations and modelling views

The different alignment and misalignment situations concern three modelling views. The
first view, that is, the intentional one, represents the process goals and allows for the
verification of the coherence between the purposes of the processes desired by the
company and those proposed by the ERP system. The functional view, that is, the second
one, serves to check the consistency on the level of the process activity sequence, that is,
the functioning of the processes. It corresponds to the ways in which a given goal can be
reached. We call it the strategies of a company’s processes. On this level, are also
compared the data used or impacted in terms of their existence. Finally, the informational
view allows for the matching of the data format used or impacted by the processes. These
data can take the shape of documents such as dashboards or graphs. They may also
corporate data such as suppliers or customers.
We propose eight situations: five concerning both the intentional and functional
views, and three concerning the informational view.
The five situations concerning the functional and intentional views are broken down
into two kinds of situation:
1 related to each process wished for by the company and present in the ‘as-wished’
model
2 related to each process discovered by the company in the ERP system and present in
the ‘might-be’ model but not in the ‘as-wished’ model.
For the first category, considering a particular process of the ‘as-wished’ model, the four
situations are:
• S1: the goal and strategy of a given ‘as-wished’ process are identical to those of a
‘might-be’ process: the company finds a perfect equivalence, in the ERP system, for
the studied wished process
• S2: the goal of a given ‘as-wished’ process is identical to a ‘might-be’ process goal
but the strategies of the two processes are different, and the company’s one is
particular and cannot be modified
• S3: the same situation as the former but the company’s process strategy is basic and
can be modified
• S4: the goal of a given ‘as-wished’ process has no equivalent in a given ‘might-be’
process: the enterprise does not find equivalence in the ERP system for the wished
process.
36 S. Mamoghli et al.

For the second category, considering a process present in the ‘might-be’ model but not in
the ‘as-wished’ model, the situation is:
• S5: the ‘might-be’ process goal and strategy are interesting for the company.
The three situations concerning the informational view deal with each process already
chosen by the company. Considering data used or impacted by a selected process, those
situations are:
• S6: the ‘as-wished’ data format is identical to that proposed in the ‘might-be’ model
• S7: the ‘as-wished’ data format is not identical to that proposed in the ‘might-be’
model but the format wished for by the company is important
• S8: the same precedent situation as the preceding one but the format proposed by the
ERP system is interesting for the company.
The algorithm that we propose associates one or several actions for each of those
situations. These situations happen during the alignment process consisting essentially in
matching the ‘as-wished’ model with the ‘might-be’ model at the different modelling
view levels.

4.2 A decision algorithm for the alignment

This sub-section presents our decision algorithm. The strength of this algorithm is that it
makes the connection between the situations resulting from the match of the ‘as-wished’
model with the ‘might-be’ model and the related decisions. We first explain the different
decisions that can be made and then present the algorithm.

4.2.1 The alignment decisions

Four types of decision that we find partially in the work of Soffer et al. (2003, 2005) and
that we have decided to consider in more depth are associated with the situations
described above. These decisions represent a graduation from the highest to the lowest fit
between the ERP system and the company. They can be described as follows:
• D1: the ERP system configuration: it corresponds to the case when the ERP system
simply has to be parameterised. This is possible when there is a perfect equivalence
between the ERP system and the company.
• D2: the ERP system adaptation: with this decision, the ERP system is adapted to the
company’s wishes. This is possible when there is a partial equivalence between the
system and the company, so that the ERP system responds to a part of the company’s
wishes.
• D3: the addition of an applicative component: this decision occurs when the ERP
system does not meet the enterprise’s specific needs, which are met through another
application.
• D4: the manual supported process: this is an alternative to the D3 decision. In this
case, no additional application is chosen and the ‘uncovered’ process is done
manually.
 A decision algorithm for ERP systems alignment 37

Figure 2 The intentional and functional flowchart for Situations S1, S2, S3 and S4

4.2.2 The decision algorithm

The proposed algorithm is given in Figures 2, 3 and 4. It enables us to work out the to-be
model through a step-by-step matching process between the as-wished and might-be
models, at different modelling view levels. The strength of this algorithm is that it
associates one of the four decisions (D1 to D4) with the eight situations (S1 to S8) quoted
in sub-section 4.1.2. This is proposed in none of the previous methods reviewed and it
affords the possibility to guide the expert’s decisions.
38 S. Mamoghli et al.

Figure 3 The intentional and functional flowchart for Situation S5

Figure 4 The informational flowchart for Situations S6, S7 and S8

 A decision algorithm for ERP systems alignment 39

The proposed algorithm enables us to check, in a given order, the various situations of
alignment and misalignment between a company’s needs, based on its wishes, and
those supported by the ERP system. This is done by matching the ‘as-wished’ model
with the ‘might-be’ model at different modelling view levels. The idea is to begin
with the intentional view, then with the functional view, and lastly with the
informational view. The algorithm takes into account the enrichment of the ‘to-be’
model with elements discovered gradually, during the model matching process, on
the ‘might-be’ model. When the different situations are characterised, the algorithm
also enables us to associate them with the consistent decisions to tackle these
situations. This matching process is carried out goal-by-goal and activity-by-activity.
For the moment, it is not automated. We have decided to use the UML activity
diagram to represent the algorithm. Thus, we propose three diagrams. The first
corresponds to the intentional and functional view matching the processes defined in the
as-wished model. The second corresponds to the discovering of new processes in
the might-be model. This situation is generally not tackled in the literature studied
above. However, it is crucial because the ERP systems often offer new functionalities
that the companies never even envisage. These have to be analysed carefully. The third
activity diagram details the matching at the informational view level, for the chosen
processes. These three diagrams have to be executed sequentially. The algorithm
therefore begins with the intentional and functional flowchart, for each process of the as-
wished model (cf. Figure 2). This flowchart leads to situations S1 to S4 and their
corresponding decisions. The algorithm then goes further, with the discovered processes
in the might-be model (cf. Figure 3). This flowchart corresponds to the fifth situation
(S5). Finally, the algorithm ends with the ‘informational matching’ of the chosen
processes in the to-be model (cf. Figure 4). This flowchart is associated with situations S6
to S8.
In the next section we illustrate the algorithm in the case of an SME leading an ERP
project.

5 Illustration

We have studied the case of an SME in the region of Strasbourg (France), which decided
in 2008 to change its ERP system. As this system had reached ‘the end of life’, its
maintenance was no longer insured. At the end of 2008, the company selected a new ERP
system for which the deployment phase began in January 2009. In June 2009 the
company validated the adequacy stage of the deployment phase. This real case of an ERP
project serves to validate and illustrate the decision algorithm proposed in the previous
section.

5.1 Application context

The company is an SME of 120 persons, established in 1952. It is specialised in the
manufacturing and marketing of height access and personal safety equipment for the
building and manufacturing industries, such as scales and scaffolds.
To validate the various situations presented in our algorithm, we based our work on
the specifications containing the list of the processes that the company wanted. We also
40 S. Mamoghli et al.

drew on the minutes of the adequacy meetings that we attended. During these meetings,
the processes to be effectively implemented were discussed between the editor and the
stakeholders.

5.2 Results of decision algorithm application

We used the UML formalism to represent the models and especially the activity diagram.
This enabled us to represent the functional view. Since (by definition) this diagram does
not allow us to represent the intentional and informational views required to illustrate the
situations of our decision algorithm, we adapted it. We added the possibility of
visualising the data used and impacted by the various activities. We also added a note on
every diagram, indicating the purpose of the represented process. Moreover, the
differences between the ‘as-wished’ and the ‘might-be’ models are represented in bold
type.
Two situations are presented here. The first one deals with ‘employee pay
management’, and the second one with ‘expedition management’.
The first studied process does not exist in the ERP system (S4 situation of the
algorithm) and the company decided to support it with an additional applicative brick
(D4 decision of the algorithm). This process exists in the ‘as-wished’ model (Figure 5)
but not in the ‘might-be’ model. The company needs to collect the punches of the
employees’ working hours in order to be able to pay them according to the number of
hours they worked. However, the ERP system selected by the company does not propose
a module that supports this process; that is, that links pay calculations and employee
punches. An external applicative component, interfaced with the ERP system, therefore
has to be added. This software allows one to revert to the punches supplied by the ERP
system and to deduce the corresponding pay.

Figure 5 ‘As-wished’ model of the process ‘employee pay management’

 A decision algorithm for ERP systems alignment 41

Figure 6 (a) ‘Might-be’ and (b) ‘as-wished’ models of the process ‘expedition management’

The second studied process is proposed by the ERP system and desired by the company.
There is however a partial equivalence because the strategy proposed by the ERP system
is not the same as the one wished for by the company (S2 situation of the algorithm). The
company decided to keep the company’s process strategy (D2 decision of the algorithm).
In fact, it is not possible for the company to abandon it for a standard one due to the
42 S. Mamoghli et al.

specificity of its product. The ‘expedition management’ process is present in both the
‘as-wished’ and ‘might-be’ models (Figure 6). By visually matching these two models
representing two versions of the process, we notice that
1 the purpose of the two versions is identical
2 the strategies are different
3 the ‘volume’ attribute of the data ‘article’ is not present in the ‘might-be’ model.
The goal of this process is to prepare and deliver the merchandise to the customer. In fact,
the strategy proposed by the ERP system in the ‘might-be’ model is not convenient for
the company. Firstly, calculating the number of trucks required for a company’s delivery
cannot be based on the weight of the products to be transported. Products such as scales
or access platforms are huge. Therefore, the volume of the products to be transported is
more meaningful than their weight, for calculating the number of trucks. The ‘volume’
attribute of the data ‘article’ does not exist in the ERP system, which has to be adapted.
Secondly, in the ‘as-whished’ model of the expedition process, the company insists on
printing packing slips only when the transporter arrives and not when the order is
prepared, as suggested in the ‘might be’ model of the same process. Printing the packing
slip is associated in the ERP system with the status ‘delivered merchandise’. In the
company’s experience, it happens quite often that the transporter forgets to retrieve the
merchandise on the loading dock, so that it cannot be considered as delivered. The
company therefore decided, based on its experience and the specificity of its products, to
keep its own process strategy and not to adopt the standard one of the ERP system. The
ERP system therefore had to be adapted. The interface for computing the number of
trucks now contains the possibility of analysing the merchandise to be transported,
according to its volume. A punch also had to be made by the transporter to allow the
system to print packing slips.
In the course of the adequacy stage, we identified some of the situations of the
decision algorithm so that they could be validated: in particular, S1, S2, S4 and S5 of our
situation typology. For S4, we identified its association with the D2 and D3 decisions.

6 Conclusions – perspectives

During the implementation of software packages based on ‘off-the-shelf’ products, one of

the main problems is the choice of the processes to be implemented, allowing for an
alignment between the information system to be developed and the company.
An analysis of several alignment methods in the literature shows that none of the
authors proposes a guide to understand what kinds of alignment or misalignment situation
are possible, and which solutions can be envisaged. They insist more on the models to be
built or on the alignment measurement techniques to determine, for example, the distance
between the wishes of the company and the standard solutions proposed by the ERP
system.
We therefore propose a decision algorithm that enables companies to make their
choice concerning the processes to bring under the control of the ERP system that they
selected. It describes the different situations of alignment and misalignment between the
processes desired by the company and those proposed by the ERP system. Based on this
description, the decisions that the company can envisage for each situation are detailed.
 A decision algorithm for ERP systems alignment 43

The proposed algorithm allows one to recapitulate all the situations that a company has to
face during alignment, especially misalignment.
However, the reviewed methods require all the processes desired by the company and
those proposed by the ERP system to be modelled, in order to locate the potential
misalignments. We therefore suggest, in a future study, to identify misalignment risks at a
very early stage, like Ho. et al. (2009) who propose to identify all the risks of an ERP
project from the outset. The aim is to focus only on the modelling of the processes
representing a major misalignment risk, and thus to save a considerable amount of time
during the deployment phase. One of the envisaged ways could be to implement the
principles stemming from the dialectic, by modelling a given risk situation in the form of
a contradiction (Goepp and Kiefer, 2006).

Acknowledgements

The authors would like to thank the reviewers. Their remarks enable the authors to
improve their work.

References
Avila, O., Goepp, V. and Kiefer, F. (2009) ‘Understanding and classifying information systems
alignment approaches’, Journal of Computer Information Systems (JCIS), Vol. 50, No. 1,
pp.2–14.
Bézivin, J., Bouchet, J-P. and Breton, E. (1999) ‘Revisiting the P&P pattern with explicit
meta-models’, paper presented at the LA Chapter Spring Conference, Los Angeles, California,
USA.
Botta-Genoulaz, V. (2007) ‘Les ERP: un atout pour la cohérence, un risque pour la flexibilité’,
in G. de Terssac, I. Bazet and L. Rapp (Eds.): La Rationalisation Des Entreprises Par Les
Technologies Cooperatives, Octares ed., pp.37–53.
Botta-Genoulaz, V. and Millet, P-A. (2005) ‘A classification for better use of ERP systems’,
Computers in Industry, Vol. 56, No. 6, pp.572–586.
Daneva, M. and Wieringa, R. (2006) ‘A requirements engineering framework for
cross-organizational ERP systems’, Requirement Engineering Journal, Vol. 11, No. 3,
pp.194–204.
Darras, F. (2004) ‘Proposition d’un cadre de reference pour la conception et l’exploitation d’un
progiciel de gestion integre’, PhD thesis, INP Toulouse, Speciality Industrial Systems, France.
Davenport, T.H. (1998) ‘Putting the enterprise into the enterprise system’, Harvard, Business Rev,
Vol. 76, pp.121–131.
Esteves, P. (1999) ‘An ERP life-cycle-based research agenda’, paper presented at The First
International Workshop in Enterprise Management and Resource Planning: Methods, Tools
and Architectures, Italy.
Etien, A. (2007) ‘La methode ACEM pour l’alignement d’un systeme d’information aux processus
de l’entreprise’, PhD thesis, Speciality Computer Science, Paris 1-Panthéon-Sorbonne, France.
Etien, A. and Rolland, C. (2005) ‘Measuring the fitness relationship’, Requirements Engineering
Journal, Vol. 10, No. 5, pp.184–197.
Giachetti, R.E. and Truex, D.P. (2009) ‘The ERP life cycle, course’, Computer Information
Systems (CIS) Department, Georgia State University, USA, available at
http://www.cis.gsu.edu/~dtruex/courses/CIS8090/pdf/ERPLifeCycle.pdf.
44 S. Mamoghli et al.

Goepp, V. and Kiefer, F. (2006) ‘Design of information system architectures using a key problem
framework’, Computers in Industry, Vol. 57, No. 2, pp.189–200.
Ho, L.T., Lin, G. and Nagalingam, S. (2009) ‘A risk mitigation framework for integrated-enterprise
systems implementation for the manufacturing environment’, International Journal of
Business Information Systems, Vol. 4, No. 3, pp.290–310.
Izza, S. (2007) ‘Etat de l'art sur les modeles d’entreprise’, Easy-DIM, available at
http://www.easy-dim.org/.
Kamhawi, E.M. and Gunasekaran, A. (2009) ‘ERP systems implementation success factors: IS and
non-IS managers’, International Journal of Business Information Systems, Vol. 4, No. 6,
pp.688–704.
Kirchmer, M., Brown, G. and Heinzel, H. (2002) ‘Using SCOR and other reference models for
e-business process networks’, in A.W. Scheer, F. Abolhassan and W. (Eds.): Business Process
Excellence, ARIS in Practice, pp.52–74, Springer, Berlin.
Klee, A. (2005) ‘The ERP life cycle: from birth to death and birth again’, JDEtips Journal,
available at http://erptips.com/site_searchRESULTS.asp?search=erp+life+cycles.
Light, B. (2005) ‘Going beyond ‘misfit’ as a reason for ERP package customisation’, Computers in
Industry, Vol. 56, No. 4, pp.606–619.
Madapusi, A. and D’Souza, D. (2004) ‘Aligning ERP systems with international strategies’,
Information Systems Management, Vol. 22, No. 1, pp.7–17.
Millet, P-A. (2008) ‘Une étude de l’intégration organisationnelle et informationnelle, application
aux systèmes d’informations de type ERP’, PhD thesis, INSA Lyon, Speciality Computer
Science, France.
Millet, P-A. and Botta-Genoulaz, V. (2008) ‘Process alignment maturity in changing
organisations’, in Grabot, B., Mayère, A. and Bazet, I. (Eds.): ERP Systems and
Organisational Change – A Socio-technical Insight, pp.157–180, Springer ed., London.
Motwani, J., Akbulut, A.Y., Mohamed, Z.M. and Greene, C.L. (2008) ‘Organizational factors for
successful implementation of ERP systems’, International Journal of Business Information
Systems, Vol. 3, No. 2, pp.158–182.
Prakash, N. and Rolland, C. (2001) ‘Matching ERP system functionality to customer requirements’,
paper presented at The 5th IEEE International Symposium on Requirements Engineering,
Toronto, Canada, pp.27–31.
Quellenec, C. (2007) ERP Levier de Transformation de l’Entreprise, Hermès, Paris.
Ramayah, T., Roy, M.H., Arokiasamy, S., Zbib, I. and Ahmed, Z.U. (2007) ‘Critical success
factors for successful implementation of enterprise resource planning systems in
manufacturing organization’, International Journal of Business Information Systems, Vol. 2,
No. 3, pp.276–297.
Salinesi, C. and Rolland, C. (2003) ‘Fitting business models to system functionality exploring the
fitness relationship’, paper presented at The 15th International Conference on Advanced
Information Systems Engineering, pp.647–664.
Scheer, A-W., Abolhassan, F., Jost, W. and Kirchmer, M. (2002) ‘ARIS: from the vision to
practical process control’, in Scheer, A.W., Abolhassan, F. and Jost, W. (Eds.): Business
Process Excellence, ARIS in Practice, pp.1–13, Springer, Berlin.
Scheer, A-W. and Nuttgens, M. (2000) ‘ARIS architecture and reference models for business
process management’, in Van Der Aalst, W., ter Hofstede, A. and Weske, M. (Eds.): Business
Process Management – Models, Techniques, and Empirical Studies, pp.366–379.
Singla, A.R. and Goyal, D.P. (2007) ‘Success factors in ERP systems design implementation:
an empirical investigation of the Indian industry’, International Journal of Business
Information Systems, Vol. 2, No. 4, pp.444–464.
Soffer, P., Golany, B. and Dori, D. (2003) ‘ERP modeling: a comprehensive approach’,
Information Systems, Vol. 28, No. 6, pp.673–690.
Soffer, P., Golany, B. and Dori, D. (2005) ‘Aligning an ERP system with enterprise requirements:
an object-process based approach’, Information & Management, Vol. 44, No. 8, pp.666–680.
 A decision algorithm for ERP systems alignment 45

Soh, C., Kien, S.S. and Tay-Yap, J. (2000) ‘Culture fits and misfits: is ERP a universal solution’,
Communications of the ACM, Vol. 43, No. 4, pp.47–51.
Tournant, L. and Azan, W. (2003) Reussir Votre Projet ERP, Afnor, Paris.
Wei, C-C. and Wang, M-J.J. (2002) ‘A comprehensive framework for selecting an ERP system’,
International Journal of Project Management, Vol. 22, No. 2, pp.161–169.
Wu, J-H., Shin, S-S. and Heng, M.S.H. (2007) ‘A methodology for ERP misfit analysis’,
Information & Management, Vol. 44, No. 8, pp.666–680.
Yazgan, H.R., Boran, S. and Goztepe, K. (2009) ‘An ERP software selection process with using
artificial neural network based on analytic network process approach’, Expert Systems with
Applications: An International Journal, Vol. 36, No. 5, pp.8713–9606.

Notes
1 Model-Driven Enterprise and Information System Engineering project supported by the GDR
MACS, CNRS, France.