# Model-Driven Enterprise Resource Planning Specifications in SMEs

Clement Lacombe, Ramuntxo Pochelu, Said Tazi, Yves Ducq

► To cite this version:

Clement Lacombe, Ramuntxo Pochelu, Said Tazi, Yves Ducq. Model-Driven Enterprise Resource Planning Specifications in SMEs. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2014, Ajaccio, France. pp.538-545, 10.1007/978-3-662-44733-8_67 hal-01387318

HAL Id: hal-01387318

https://inria.hal.science/hal-01387318

Submitted on 25 Oct 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Model-Driven Enterprise Resource Planning
Specifications in SMEs

Clement Lacombe<fnref n="1" />, <fnref n="2" />, Ramuntxo Pochelu<fnref n="2" />, Said Tazi<fnref n="3" />, Yves Ducq<fnref n="1" />

¹ Univ. Bordeaux – IMS – UMR 5218 CNRS
351 cours de la Libération – 33405 Talence cedex, France
clement.lacombe@ims-bordeaux.fr, yves.ducq@ims-bordeaux.fr

²Sarl Atelier du Piment Elizaldeko Bidea, 64250 Espelette, France
si@atelierdupiment.com, ramuntxo@atelierdupiment.com

³UFR Anglet Université de Pau et des Pays de l'Adour
Allée du Parc Montaury 64600 Anglet, France
said.tazi@univ-pau.fr

**Abstract.** Small companies, like their larger counterparts, need information systems to drive and measure their performance. Until now, only large firms had access to ERP<fnref n="1" /> technology, but the market is increasingly tapping into to the needs of small businesses. For many SMEs<fnref n="2" />, however, the difficulty lies in navigating the choices available and defining their specifications for this type of information system, especially since few tools and methods exist to help them. This is why we have developed an enterprise modeling-driven method for needs specification: the information in a company's business model is used to prepare its ERP Functional Specification.

**Keywords:** Enterprise Resource Planning, specifications, Enterprise Modeling, SMEs.

# 1 Introduction

The research presented in this article was conducted in collaboration with the IMS Laboratory at University of Bordeaux 1, and with “Atelier du Piment” – a fast-growing company with a staff of ten, which grows, processes and markets the Espelette variety of chili pepper sold under the trade name “Piment d’Espelette AOP<fnref n="3" />”. The company wanted to improve its organizational structure, and undertaking a project to overhaul its information system with the integration of ERP software was

<footnote n="1">¹ Enterprise Resource Planning</footnote>

<footnote n="2">² Small and Medium Enterprises (SMEs)</footnote>

<footnote n="3">³ Protected Designations of Origin</footnote>
completely in line with this aim. The research presented herein was carried out simul-
taneously with the company's ERP project.

Regardless of its size, sector or line of business, a company has to implement various
functions in order to exist:

* Procuring materials or goods, collecting information

* Processing, however simple or complex

* Selling products or services

* Keeping records for tracking, measuring and monitoring purposes

* Setting up a dashboard to understand and analyze

These functions need to be implemented in a coordinated, well-thought-out and effi-
cient manner. Thus, a company can be seen as an organized system that is constantly
changing.

To represent the organization of the complex "company" system [Le Moigne, 1977]
breaks the company down into three sub-systems: a decision-making system, an in-
formation system, and an operating system.

The information system plays a central role in the company. Every company has an information system, which may be more or less formally structured, and which may be used by a single person or by a limited number of decision-makers, but the purpose of this system is the always the same: to enable understanding and analysis in order to improve performance. However, the larger the organization, the more complex the information system will be.

Information systems, especially ERP solutions, are key components of companies.
The difficulty of integrating ERP software will depend not just on the size of the
company, but above all on the scope of the project and the functional needs that the
ERP will have to cover. Not only is deploying these solutions challenging, but these
projects come with risks and the stakes are high. [Holland and Light, 1999] state that
information system projects are first and foremost company projects.

Considering the difficulties that can arise in these projects, specialists look for the key success factors. [Mamoghli, 2013] has created a classification of studies on the risk factors and success factors for ERP projects. Of all the factors listed, in this article we will focus on the ERP software selection phase. Choosing an ERP solution is a complex task, particularly for SMEs. At this stage in the project, the company needs to be able to define and formalize its needs in order to choose one of the ERP solutions on the market.

The challenge for SMEs is that few resources are available to help them define their
requirements. This is why we propose in this article a needs specification method
based on the use of enterprise modeling.

In the first part, above, we have seen that a company can be considered a complex
system, in which the information system plays a central role. We have also pointed
out the difficulties that SMEs face in specifying their needs for ERP projects. In the
second part, we will present a state of the art review of the main research on ERP software that has served as our reference base. We will then address the problem of the definition of needs in small companies, setting out our proposed method of using the company's enterprise modeling information for this purpose. Finally, we will illustrate the application of this method through a case study on "Atelier de Piment".

# 2 State of the art review

To establish the broader scientific context for our research, we will first examine the ERP life cycle. We will then discuss ERP alignment and enterprise modeling. Lastly, we will define the role and purposes of the Functional Specification in ERP projects.

## 2.1 ERP life cycle

There is a considerable body of research that has focused on ERP project phasing. [Mamoghli, 2013] presents a literature review. [Botta and al., 2001], [Deixonne, 2001], [Darras, 2004] proposes different ways of breaking down projects, which can be more or less detailed. There are five main phases: the pre-project phase, the pre-installation phase, the installation phase, the post-installation phase and finally the post-project phase. Our work focuses on the pre-installation phase. A poorly-realized definition of needs can negatively impact the ERP installation phase, since if the selected ERP software does not match the company's real needs, there is a greater risk of misalignment between the ERP and company processes.

## 2.2 ERP alignment

[Mamoghli, 2013] defines the Misalignment Risk as the probability of misalignment associated with the ensuing loss if the misalignment occurs. It is the probability that the processes placed under ERP control will not be aligned with the company's real needs and processes.

For [Botta and Millet, 2005], managing ERP alignment is a necessary key success factor for ERP projects. [Mamoghli, 2013] proposes a model-driven engineering method called "Model Driven - ERP Alignment" which reduces the effect of Misalignment Risk. This method involves a model-based alignment process enabling the following:

* precisely identifying situations of alignment and misalignment between the models of the processes the company wants (AS-WISHED) and the models of standard ERP processes (MIGHT-BE);

* constructing the model of the processes to be installed (TO-BE), step by step, in a guided manner, through the combined use of evaluation criteria and decision-making.

For this method to be applied, the AS-IS, AS-WISHED and MIGHT-BE models need to be based on the same formalisms. While creating AS-IS and MIGHT-BE models is
fairly straightforward, constructing the AS-WISHED model can be much more com-
plex, as in order to do so, the company must first have a precise vision of its needs.

We find that this method works well in the context of a company that is already well-
structured, and which has a fairly homogenous information system. However, we are
not convinced that this type of method is appropriate in the case of small companies,
which often rely on less sophisticated and somewhat informal information systems,
and where there is too wide a gap between the existing system (AS-IS) and the target
system (TO-BE).

In the following paragraph, we will lay out the modeling method and the interaction
model that we presented in a previous paper [Lacombe and al., 2013].

2.3 GIM<fnref n="4" /> and the interaction model

The GIM developed in the 1990s, based on the GRAI (Graph of Results and Intercon-
nected Activities) method, was designed to provide tools for analyzing and designing
complex production management-type systems in industrial engineering contexts
[Chen et al., 1997].

This method uses three graphic models to represent the three modeling views:

* The decision-making view: GRAI grid,

• The information view: UML class diagram,

* The physical view: IDEF0 diagram.

The interaction model that we have developed incorporates these three modeling
views. It does not model a specific system, but rather the interaction between these
three modeling views. The purpose of the interaction model is to provide a graphical
representation of a management step or process that can be defined as “special” –
meaning a “non-standard” ERP function or process, one not supported by off-the-
shelf ERP software.

We will now discuss how the information contained in the models produced is used to
formalize the company's requirements in a Functional Specification.

## 2.4 Functional Specification

A Specification serves to formally express a need and to explain it so that it can be
understood and validated by all stakeholders in a project. [Equey and Rey, 2004] ex-
plains that writing a high-quality Functional Specification helps limit cost overruns,
increase companies’ satisfaction and improve relations between the different stake-
holders in the project. Another advantage is that this helps the project team appropri-
ate the issues at stake in the project.

Writing the Specification is a key component of the ERP selection phase for compa-
nies of all sizes. However, the level of detail used to describe the needs is different for

<footnote n="4">⁴ GRAI Integrated Methodology</footnote>
different-sized companies. Specifications for large-scale enterprises will include a highly-detailed and in-depth study of the functional requirements, whereas SMEs will not go into as much detail in defining the needs in their specifications.

# 3 Model-driven needs specification

In this scientific context, and drawing on our previous work [Lacombe and al., 2013], we propose a method for formalizing needs in a Functional Specification using the information contained in the GIM models and our interaction model.

Before explaining the method, however, let us first identify and define the main components of an ERP Specification.

* Presentation of the company

The purpose of this part of the Specification is to describe the company in terms of its legal structure, environment, line of business, market and offer. Going beyond these simple descriptors, this part should also convey the company's values and business dynamics.

* Description of current systems

There are two parts to this description of the current systems. The first serves to describe the company's physical processes, e.g., manufacturing, acceptance or goods shipping processes. The second part describes the existing information system, specifying the hardware and software in place within the company. This component of the Specification needs to define the precise status of the existing resources within the company.

* Presentation of the project

The purpose of this part is to identify the context and objectives of the ERP project. This is also where the scope and functions to be covered by the ERP solution will be defined, along with any interfaces with third-party applications that need to be taken into account.

* Description of needs

Two types of needs need to be defined: functional needs and decision-making needs. The first type, functional needs, can include aspects that are considered standard ERP functions or more specific “special” functions. The needs are classified according to company functions and defined in the models. The second type, decision-making needs, refers to management-related or performance measurement aspects. This is where needs in terms of statistical reports and dashboard performance indicators will be defined.
<table><caption>**Table 1.** ERP software requirement specifications and models used</caption><thead><tr><th></th><th>GRAI<br>Grid</th><th>IDF0<br>Diagrams</th><th>Interaction<br>Model</th></tr></thead><tbody><tr><td colspan="4">Presentation of the company - 20%</td></tr><tr><td>Legal structure</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Environment</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Factors specific to line of business</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Customers</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Products and services</td><td>-</td><td>-</td><td>-</td></tr><tr><td colspan="4">Description of current systems - 10%</td></tr><tr><td>Physical processes</td><td>-</td><td>X</td><td>-</td></tr><tr><td>Information system</td><td>-</td><td>-</td><td>-</td></tr><tr><td colspan="4">Presentation of the project - 10%</td></tr><tr><td>Objectives</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Functional coverage</td><td>-</td><td>-</td><td>-</td></tr><tr><td colspan="4">Description of functional needs classified by functions - 50%</td></tr><tr><td>Standard needs</td><td>X</td><td>-</td><td>-</td></tr><tr><td>Special needs</td><td>-</td><td>-</td><td>X</td></tr><tr><td colspan="4">Description of decision-making needs / Subject of subsequent research - 10%</td></tr></tbody></table>

As shown in Table 1, the GRAI models and our interaction model will provide the information needed to complete certain parts of the Functional Specification.

First, we will be able to use the IDEF0 diagrams to describe the company's current systems and physical processes. This modeling language is used to represent the series of activities in a process, the incoming and outgoing flows, the resources used and the monitoring data for the various activities.

Second, using the information in the GRAI grid, we will be able to create a detailed list of the desired functions to be supported by the ERP software. For this to be effective, it is important to use a GRAI grid that provides fairly detailed descriptions.

Finally, the interaction model will allow us to provide more detailed specifications for certain steps or management processes that require more in-depth analysis.

In the following section, we will illustrate the use of these three models through a case study.
## 4 Case study: "Atelier du Piment"

<figure><img src="image_2.png" /><figcaption>Fig. 1. IDEF0 – Chili powder manufacturing process, to be included as-is in the Specification.</figcaption></figure>

<table><caption>Fig. 2. GRAI grid – Tasks classified by function and organized into decision-making centers.</caption><thead><tr><th>Manage procurement</th><th>Manage product processing</th><th>Manage shipments</th></tr></thead><tbody><tr><td>Scheduling deliveries<br>Receipt/acceptance of goods<br>Receipt of delivery slip<br>Printing shipment unit labels<br>(EAN128)</td><td>Preparing manufacturing orders<br>Ranking priorities</td><td>Scheduling shipments<br>Shipping cost simulation<br>Selecting carriers</td></tr><tr><td><strong>Recording inputs and outputs inventory</strong><br>Managing multiple warehouses<br>Reserving a quantity in stock</td><td>Launching manufacturing orders<br>Monitoring raw material traceability</td><td>Preparing shipment units / pallets<br>Preparing delivery slips<br>Shipping shipment units / pallets</td></tr></tbody></table>

<figure><img src="image_3.png" /><figcaption>Fig. 3. Interaction model – Record of incoming fresh Espelette peppers in stock.</figcaption></figure>

The specific aspects to be taken into account for this activity are: traceability data entry and the weighing equipment used. In this case, the function is included in the GRAI grid, but requires special attention.
# 5 Conclusion

In the first part of this article, we discussed how a company can be seen as a complex system, in which the information system plays a central role. We also pointed out the difficulties that SMEs face when it comes to specifying their needs for ERP projects.

In the second part, we examined the broader scientific context for our research, first discussing the ERP life cycle and the issue of ERP alignment, then presenting the GIM and the interaction model, and finally defining the role and purposes of Functional Specifications in ERP projects.

In the third part, we proposed a method for using modeling to write a Functional Specification. We first identified the main components of an ERP Specification, and then associated them with the most appropriate models, respectively.

In our ongoing work, we would like to develop a method to help SMEs specify their decision-making needs. While we have not yet addressed management aspects and the measurement of company performance through performance indicators and dashboards, these areas are of course highly relevant to our work on SME needs specification.

# 6 Bibliography

Botta-Genoulaz, V., Millet, P.-A., and Neubert, G., (2001) The role of enterprise modeling in ERP implementation. *Industrial Engineering and Production Management*, volume 1, pages 220-231.

Botta-Genoulaz, V., Millet, P.-A. (2005) A classification for better use of ERP systems. *Computers in Industry*, 56 (6):572-586.

Chen D., Vallespir B., Doumeingts G., (1997) GRAI integrated methodology and its mapping onto generic enterprise reference architecture and methodology, *Computers in Industry*, vol. 33, n° 2-3, p. 387-394.

Darras F., (2004) Proposition d'un cadre de référence pour la conception et l'exploitation d'un progiciel de gestion intégré. PhD, Institut National Polytechnique de Toulouse. Systèmes industriels. 230 pages.

Deixonne, J. L., (2006) Piloter un projet ERP: transformer et dynamiser l'entreprise par un système d'information intégré et orienté métier. Dunod. 2e édition. Paris.

Equey, C., and Rey, A., (2004) La mise en place d'une solution de gestion moderne (ERP/PGI), quels enjeux pour une PME/PMI ? 1ère partie : étude de cas détaillés, Working paper N°HES-SO/HEG-GE/C--06/1/4--CH

Holland, C.R., Light, B., (1999) A critical success factors model for ERP implementation. *Software,IEEE* 16, no. 3- pp.30-36.

Lacombe, C., Tazi, S., Ducq, Y., (2013) Méthode et modèle d'interaction pour la spécification des systèmes d'information dans les Très Petites Entreprises. Congrès International de Génie Industriel. La Rochelle.

Le Moigne, J.-L., (1977) La théorie du système général, Paris : presse universitaire de France. 258 pages.

Mamoghli, S., (2013), Alignement des Systèmes d'Information à base de progiciel, vers une ingénierie dirigée par les modèles centrée identification des risques. National Institute of Applied Sciences of Strasbourg. *Sciences et Technologies Industrielles*. 254 pages.