Mémoire de fin d’étude

pour l’obtention du diplôme de Master :

Méthodes informatiques appliquées à la gestion des entreprises

Sous le thème :

La gestion des projets de mise en

place des progiciels de gestion
intégrés : étude de cas

Réalisé par : Sous l’encadrement de :

El arbi OUAHI Mohamed ZOUHRI

Membre de Jury :
Président : Mr. Mohamed ZOUHRI : Enseignant chercheur à la FSJES Meknès
Membre : Mr. Said AMALI : Enseignant chercheur à la FSJES Meknès
Membre : Mr. Rachid EL OUAHBI : Enseignant chercheur à la FSJES Meknès

FSJES-Meknès / 2018-2019
 Résumé
Le sujet de ce mémoire de fin d’étude porte sur la gestion des projets de mise en place des
systèmes ERP, et plus précisément la problématique de l’impact du bon choix de l’intégrateur
sur la réussite et la qualité du projet ERP. Les recherches en matière des projets ERP sont
vastes mais la problématique de l’intégrateur et son apport dans le succès des projets ERP est
peu nombreux.

Le choix d'étudier ce sujet a été fait dans le cadre des activités du stage de fin d’étude, j’ai
participé à la mise en place d’un système ERP. Cela a permis de prendre conscience des
besoins et des difficultés dans le domaine.

Les difficultés de ce genre des projets révèlent dans les ressources nécessaires à la mise en
place des ERP, ce sont des profils qualifiés, diversifiés et spécialisés dans ce domaine, ces
profils spécialisés dans l’implémentation existent rarement dans les entreprises commerciales
ils sont souvent employés chez les intégrateurs des solutions informatiques (les sociétés de
services en ingénierie informatique). L’intégrateur doit être donc forcément se présenté dans
ce genre des projets pour faire face aux besoins des entreprises en matière des ressources
humaines nécessaire pour la gestion du projet. A cet effet la réussite du projet ERP compte
beaucoup sur l’expérience de l’intégrateur, le choix d’un intégrateur ne se fait pas donc au
hasard mais en assurant qu’il s’agit du meilleur choix.

i
 SOMMAIRE
RESUME ............................................................................................................................................................ I

SOMMAIRE ...................................................................................................................................................... II
REMERCIEMENTS. ........................................................................................................................................... III

DEDICACE : ...................................................................................................................................................... IV
LISTE DES FIGURES ........................................................................................................................................... V

LISTE DES TABLEAUX ....................................................................................................................................... VI

LISTE DES ABREVIATIONS ............................................................................................................................... VII

INTRODUCTION GENERALE............................................................................................................................... 1
CHAPITRE 1 : LES PROGICIELS DE GESTION INTEGRES ................................................................................................... 3
Introduction ............................................................................................................................................. 3
Section 1 : le cadre conceptuel et théorique des PGI .................................................................................. 3
Section 2 : Histoire et évolution des PGI................................................................................................... 21
Conclusion : ............................................................................................................................................ 27
CHAPITRE 2 : LA MISE EN PLACE D’UN PGI : UN MEGA PROJET .................................................................................... 28
Introduction :.......................................................................................................................................... 28
Section 1 : Théories, tactiques et défis de la mise en place des PGI ........................................................... 28
Section 2: le bon choix de l’intégrateur : un maillon central pour le succès du projet ERP ......................... 46
Conclusion : ............................................................................................................................................ 50
CHAPITRE 3 : ETUDE DE CAS DE MISE EN PLACE D’UN ERP AU SEIN DE KARIZMA CONSEIL .............................................. 51
Introduction ........................................................................................................................................... 51
Section 1 : L’organisme d’accueil............................................................................................................. 51
Section 2 : Présentation du projet ........................................................................................................... 54
Conclusion .............................................................................................................................................. 72
CONCLUSION GENERALE ................................................................................................................................ 73
BIBLIOGRAPHIE .............................................................................................................................................. 75
WEBOGRAPHIE............................................................................................................................................... 77
TABLE DES MATIERES ..................................................................................................................................... 78

ii
 Remerciements.
Premièrement je remercie Dieu source de toute connaissance.

Je tiens à remercier toutes les personnes dont l’intervention au cours de ce

mémoire a favorisé son aboutissement.

Ainsi, je tiens à remercier toute l’équipe KARIZMA pour leur aide et leur
assistance tout au long de mon projet de fin d’étude. Votre gentillesse et bonne
humeur a fait de cette période la meilleure intégration au monde professionnel
possible.

Monsieur Saad THIFA FATHI précisément, chef de l’équipe KARIZMA

CONSEIL, pour son accueil, la confiance qu’il m’a accordée et pour la chance
qu’il m’a donnée afin d’intégrer son équipe, le soutien et l’esprit ouvert m’ont
permis d’améliorer mes compétences.

Mes remerciements les plus sincères vont à Mr. Mohammed ZOUHRI, mon
encadrant à LA FSJES Meknès, pour les conseils qu’il m’a prodigués et son
judicieux encadrement.

Je tiens à adresser mes plus sincères remerciements aux membres du jury qui
m’ont fait l’honneur d’accepter de juger mon travail. Je souhaite également
remercier l’ensemble du corps enseignant de la FSJES Meknès, pour avoir porté
un vif intérêt à ma formation, et pour avoir accordé le plus clair de leur temps,
leur attention et leur énergie et ce dans un cadre agréable de complicité et de
respect.

Enfin, je tiens aussi à remercier toute autre personne ayant contribué d’une
façon ou d’une autre, au bon déroulement de mon projet de stage.

iii
 Dédicace :

A mes très chers parents,

Aucune expression de gratitude ne pourra vous faire justice, merci
pour vos efforts, vos sacrifices et votre amour,
Que Dieu vous garde et vous procure la joie et la Santé.

A ma sœur, et mes frères

Dieu ne m’a pas donné des frères aînés, mais des amis et des confidents,
je vous aime et je vous souhaite une vie plein de bonheur et de Réussite.

A mes amis,
Merci d’avoir été la famille de mon cœur pendant ces 8 ans,
si je devais vous choisir encore une fois, je le ferais aveuglement.

Que Dieu vous garde et vous procure la joie et le vœu qu’on cherche tous
ensemble.

iv
 Liste des figures
Figure 1: les caractéristiques d’un ERP regroupé en 3 dimensions ....................................... 9
Figure 2: Le marché des PGI en 2016 ................................................................................. 18
Figure 3: Classement des ERP Opensource ....................................................................... 20
Figure 4: Figure: Évolution de l'informatisation vers les systèmes ER , source:Tomas,J.-L. ERP
et PGI : Sélection, déploiement et utilisation opérationnelle, DUNOD,P.20 .................................. 24
Figure 5: évolution de l'ERP ................................................................................................ 25
Figure 6: Logo de Karizma Conseil...................................................................................... 52
Figure 7: cartographie des processus de la société ............................................................. 55
Figure 8: La méthode SCRUM ............................................................................................ 58
Figure 9: planification et diagramme de GANTT du projet ................................................... 62
Figure 10: La solution Odoo entre autres............................................................................. 64

v
 Liste des tableaux
Tableau 1: Différentes perspectives de définition d'un ERP Source: BareIl, Bermer et
Rondeau (2000). ................................................................................................................... 7
Tableau 2: Récapitulation des principales caractéristiques attribuées à un ERP ................... 9
Tableau 3: Caractéristiques retenues pour la définition opérationnelle d'un ERP ................ 12
Tableau 4: Phases d'un projet ERP ..................................................................................... 38
Tableau 5: la hiérarchie de la société Karizma conseil ........................................................ 54

vi
 Liste des abréviations

TIC Technologie de l’information et de la

communication
ERP Enterprise resource planning
PGI Progiciel de gestion intégré
IDC International Data Corporation
SAP System, applications and products
PME Petite et moyenne entreprise
TI Technologie de l’information
SI Système d’information
SGI Système de gestion intégré
ES Enterprise system
MRP Manufacturing requirement planning
MRPII Manufacturing resource planning
EIT Enterprise information technology
EWS Enterprise wide systems
ERM Enterpise resource management
ICS Inventory control systems
XRP Extended resource planning
CRM Customer relationship management
SCM Supply chaine management

vii
 Introduction générale

La mondialisation des marchés est devenue une des principales préoccupations des
organisations aussi bien dans les secteurs marchands que non marchands, car elle tend à les
remettre en question tant au niveau stratégique qu'opérationnel.
Les TIC sont devenues des composantes majeures de la compétitivité des organisations. Ces
technologies présentent de nombreuses opportunités aux organisations pour l'amélioration de
leurs produits, services, de marché, processus et relations d'affaires. Aujourd'hui, les
organisations sont devenues de plus en plus dépendantes des TIC et par conséquent très
vulnérables aux échecs liés à ces technologies.
Pour faire face à leurs nouveaux défis, la plupart des organisations se sont engagées dans
d'importants programmes de changements organisationnels. Généralement, ces programmes
s'appuient sur les TIC.
La plupart des entreprises déploient des TIC intra et extra organisationnels (PGI, commerce
électronique, intranet/extranet et autres) à un rythme croissant pour assurer leur survie et
augmenter leur compétitivité.
Du fait de cette ferveur des organisations pour les TIC, la prépondérance de cette industrie
dans l'économie de la plupart des pays n'a cessé de croître. Selon International Data
Corporation (IDC) le premier groupe mondial de conseil et d'études sur les marchés des
technologies de l'information, les investissements dans les TIC continuent à enregistrer une
forte progression, qui devrait se maintenir à un rythme élevé voire s’accélérer au cours de
prochaines années ainsi les dépenses mondiales dans les TIC s'approche des 4 trillions
(milliers de milliards) de dollars en 2018 dans 50% proviennent des très grandes entreprises et
7% des PME.
C’était vers les années 1990 qu’un nouvel outil a été lancé sur le marché, les ERP, définis
selon le célèbre éditeur, SAP, comme « un outil de gestion des ressources de l’entreprise qui
permet d’assembler toutes les activités dans un modèle ou un processus qui automatise et
concorde toutes les transactions qui lui sont associées » (SAP, 1996).
L’objectif de la mise en place des progiciels de gestion intégrés est sensiblement relié à la
performance. En effet, la satisfaction des clients, des investisseurs et des autres parties
prenantes est désormais un axe de la stratégie pour toutes les entreprises. D’autant plus que la
mondialisation a augmenté considérablement l’intensité concurrentielle présentée sur les
marchés, jusque-là encore cloisonnés aux frontières des pays. Dans cette course contre la
1
performance, les petites entreprises doivent être réactives. Composée de 200 salariés
maximum avec un chiffre d’affaires annuel limité à 75 millions MAD, ou bien un bilan total
de 50 millions MAD, les PME représentent 95% des entreprises du Maroc. Elles doivent
donc, elles aussi, se mettre au niveau de grandes multinationales et proposer des services de
qualité à leurs clients, tout en ayant des processus moins complexes et des délais de prises de
décisions relativement courts.
La mise en place d’un ERP est avant tout un projet d’entreprise. C’est un investissement pour
le long terme que pour le court terme, un investissement qui peut apparaître coûteux surtout
pour les PME, et comme tout investissement les projets ERP sont risqués d’où la nécessité de
bien préparer ses ressources pour un tel projet. En répondant à cette problématique des
ressources d’un tel projet -surtout pour les PME qui ne dispose pas des ressources spécialisées
dans les systèmes d’information- que les intégrateurs ont vu le jour pour accompagner les
entreprises dans leurs projets. La problématique de ce mémoire s’inscrit dans ce contexte-là
:En quoi le bon choix de l’intégrateur constitue-t-il un maillon central pour une mise en
place réussie et qualifiée d’un PGI ? Pour répondre à cette problématique nous allons tout
d’abord situer le sujet dans son contexte général en abordant une approche théorique
typologique et historique des progiciels de gestion intégrés (chapitre 1), puis dans un
deuxième chapitre on présentera la mise en place des PGI en tant qu’un projet nécessitant
différents ressources, c’est dans ce chapitre qu’on va également répondre à la problématique
annoncée, et enfin le troisième chapitre est une étude de cas de mise en place d’un PGI au sein
de KARIZMA CONSEIL.

2
 Chapitre 1 : Les progiciels de gestion intégrés

Introduction
Au fur et à mesure que l'environnement socio-économique évolue, les organisations font face
à des exigences de plus en plus complexes, et pour y répondre, elles font appel à des outils
technologiques et de gestion qui ne cessent d'être développés et qui tentent d'intégrer cette
complexité croissante. Le développement des applications des systèmes d'information (SI) et
des technologies de l'information (TI) suit ce mouvement. Parmi les derniers développements
des SI/TI, les systèmes de gestion intégrés (SGI), dits encore progiciels de gestion intégrés
(PGI), mais plus connus sous le sigle d'ERP (enterprise resource planning), ont connu, depuis
leur apparition sur le marché dans les années 1990 (Miranda, 1999), une évolution fulgurante

Ce chapitre a pour but de clarifier le concept « ERP ». En relevant les différentes définitions
données à l'ERP dans la littérature tant académique que professionnelle, ses principaux traits
caractéristiques sont mis en évidence et discutés. Le but de cette discussion est de dégager les
caractéristiques clés de tout système ERP. Après avoir défini et spécifié les caractéristiques du
système ERP, celui-ci est placé dans le contexte général des SI et des TI. L'analyse tente de
répondre à la question de savoir si le concept d'ERP recouvre une réalité unique, une réalité
générique, ou si au contraire, il recouvre plusieurs réalités distinctes au point que l'on puisse
parler de typologies. Une typologie des SI nous sert à mieux situer les ERP par rapport aux SI
qui les ont précédés. Enfin, la présentation de l'évolution qu'a suivie le système ERP pour
aboutir à sa forme actuelle permet de comprendre les développements qu'il a connus, et de
s'interroger sur son avenir.

Section 1 : le cadre conceptuel et théorique des PGI

Définition théorique et caractéristiques d’un PGI
Le terme ERP (Enterprise Resource Planning) a été créé par le OartnerOroup au début des
années 90 (Keller, 1999 ; Klaus et al., 2000)1. En français, ces systèmes sont désignés par
l'acronyme PGI (progiciel de gestion intégré), ou par l'acronyme SGI (système de gestion

1
PLACIDE POBA-NZAOU, processus d’adoption des et réduction du risque d’implémentation des PGI
dans les PME, thèse présentée à l’université du QUÉBEC à TROIS-RIVIÈRES
3
intégré). D'après Tomas2, rien qu'en français, il existe plus de sept dénominations de ces
systèmes. Ces systèmes sont aussi désignés par Enterprise Systems ou Enterprise-Wide
Systems. Toutefois, en anglais, c'est le terme ERP qui demeure le plus utilisé dans la
recherche et la pratique alors qu'en français ce terme a été officiellement traduit par PGI.
Que désigne-t-on par ERP ? On peut d'emblée relever que cette terminologie anglaise, qui
semble finalement s'imposer, met l'accent sur l'ensemble de l'entreprise, par opposition à un
quelconque département ou à une fonction particulière. En effet, l'appellation « ERP» découle
en ligne droite de l'appellation «MRP II)) (manufacturing resources planning), et le mot
«enterprise» vient remplacer le mot «manufacturing» pour signifier l'étendue du système sur
l'organisation dans son ensemble. Dans la terminologie française, on parle de PGI (progiciel
de gestion intégré) ou de SGI (système de gestion intégré) et ici l'accent est mis sur le mot «
intégré» pour signifier le caractère inter fonctionnel (ou multifonctionnel) du système.
Comme le souligne, certains auteurs, jugeant la terminologie ERP trop restrictive par le fait
même qu'elle découle du MRP II ou par son allusion à la planification, ont proposé d'autres
appellations comme EWS (enterprise wide systems), ERM (enterprise resources management)
ou tout simplement ES (enterprise systems), ou encore EIT (enterprise information
technology) comme le proposent Sarkis et Sundarraj (2001), tout cela pour souligner
l'intégration de toutes les fonctions de l'entreprise. Les définitions de l'ERP insistent
cependant comme on va le voir, en plus de l'intégration du système, sur d'autres critères.
Brown (2001, p. 1) donne d'un ERP cette définition: «ERP offers a single system, which links
al! Corporate operations including planning, manufacturing, inventory control, purchasing,
sales, accounting, and human resources ». Deloitte Consulting (1999, p. 2) donne la definition
suivante: “An enterprise resource planning system (ERP) is a packaged business software
system that lets a company: -Automate and integrate the majority of Us business process,' -
Share common data and practice across the enterprise; -Produce and access information in
real-lime environment.”3
Pour Lequeux4: On définit par ERP, ou Progiciel de Gestion Intégré, un sous-ensemble du
système d'information qui intègre les caractéristiques globales suivantes: Gestion effective de
plusieurs domaines de l'entreprise par des modules intégrés ou des progiciels susceptibles

2
Tomas, J.-L. (2005). ERP et PGI : Sélection, déploiement et utilisation opérationnelle. (4 éd.). Paris:
Dunod.
3
Deloitte Consulting. (1999). ERP's second wave : Maximizing the value of ERP- enabled processes.
Atlanta: Deloitte Consulting, p.2
4
Lequeux, J. L. (2002). Manager avec les ERP. Progiciels de gestion intégrés et Internet. (2 éd.).
Paris: Éditions d'Organisation, p.33-34
4
d'assurer une collaboration des processus; -Existence d'un référentiel unique de données; -
Adaptations rapides aux règles de fonctionnement; -Unicité d'administration du sous-système
applicatif (les applications); Uniformisation des interfaces homme-machine; Existence d'outils
de développement ou de personnalisation de compléments applicatifs. Pour cette dernière
définition, Lequeux précise qu'une solution qui ne répond pas aux trois premiers critères ne
peut pas être considérée comme un système ERP. En analysant les définitions ci-dessus, on
peut identifier les caractéristiques communes à un système qualifié d'ERP. Toutes les
définitions mettent l'accent sur l'intégration de plusieurs fonctions de l'entreprise. La plupart
des définitions font implicitement ou explicitement référence à l'unicité du système « single
system », «common data and practice », «référentiel unique de données », «unicité
d'administration », « uniformisation des interfaces homme-machine») (Brown, 2001; Deloitte-
Consulting, 1999; Lequeux, 2002, p. 34). La définition de Deloirte Consulting (1999) met de
l'avant le caractère instantané des traitements (production et accès à l'information en temps
réel). L'accès en temps réel aux mêmes données présentant le même état de traitement, par
toutes les activités processuelles, est jugé comme une condition essentielle pour parler
d'intégration d'un ERP (Osterle, FleischetAIt, 2001, p. 26). La définition de l'erpfans.com
(2001) évoque une conception de l'organisation en termes de « processus» (pro cessview).
Ainsi donc, même si les composantes d'un ERP sont organisées en différents modules
fonctionnels, elles suivent toutes une vision processuelle (process-orientedview) de
l'entreprise (Klaus et al., 2000) : les processus d'affaires sont supportés à travers les fonctions
d'une manière telle que l'usager ne se rend pas compte de quel module fonctionnel il est en
train de se servir. On qualifie cette caractéristique de « transversalité» de l'ERP (Carbonel,
2001) : la configuration même des ERP conduit à visualiser la totalité de la chaîne de valeur à
la fois sous l'angle des fonctionnalités et de la temporalité. On peut également relever la mise
en évidence de l'adaptabilité (adaptation rapide aux règles de fonctionnement) du système. 5
Rowe6regroupe la plupart de ces caractéristiques dans le concept d'« intégration
informationnelle» qui, dans sa conception, se décompose selon les cinq aspects suivants: -
L'interconnexion fonctionnelle: l'ERP fait disparaître les interfaces bricolés, pour un accès
immédiat et une bonne distribution de l'information entre les différentes fonctions de
l'entreprise; -L'homogénéisation inter fonctionnelle : l'ERP assure une triple cohérence interne
à travers le référentiel unique du SI, l'uniformisation des interfaces hommes-machines et

Lequeux, op.cit, p. 33
5
6
Rowe, F. (1999). Cohérence, intégration informationnelle et changement: Esquisse d'un programme
de recherche à partir des progiciels intégrés de gestion. Systèmes d'Information et Management,3-20.
5
l'unicité d'administration du système applicatif; -La flexibilité organisationnelle: elle est
offerte par les fonctions de paramétrage rendant possible le changement des règles de gestion
et d'organisation;
-La fonctionnalité générique: cette caractéristique fait que les ERP peuvent être adaptés aux
entreprises de tous les secteurs, de toutes tailles; -L'ouverture évolutive: l'ouverture évolutive
trouve son origine dans la portabilité et la modularité qui permettent l'interopérabilité des ERP
avec toutes sortes de logiciels et de progiciels.
Tuteja7 (1998) avance de son côté qu'un système ERP ne saurait se limiter à l'intégration des
processus organisationnels, et identifie SIX principales caractéristiques qu'un système doit
avoir pour être qualifié de solution ERP :
La flexibilité : un système ERP doit être flexible pour répondre aux besoins changeants de
l'entreprise. La modularité et l’ouverture : un système ERP doit avoir une architecture
ouverte, c'est-à-dire que chacun des modules qui le composent peut-être interfacé ou détaché
chaque fois que de besoin sans affecter d'autres modules ; il doit pouvoir supporter des plates-
formes informatiques diverses, et des ajouts ultérieurs. La complétude (comprehensiveness):
un système ERP doit être capable de supporter une variété de fonctions organisationnelles et
compatible avec une variété d'organisations. Le caractère extra-organisationnel (beyond the
company) : un ERP ne doit pas se confiner à l'intérieur de l'organisation, mais doit permettre
une connectivité en ligne à d'autres entités extérieures à l'organisation. Les pratiques
exemplaires (best business practices) : un ERP doit véhiculer tout un ensemble de meilleures
pratiques d'affaires. La simulation de la réalité: il doit permettre la simulation de la réalité des
processus d'affaires sur ordinateur.
Les variantes observées dans les définitions d'un système ERP pourraient amener à penser que
leurs auteurs ne font pas nécessairement référence à la même réalité. On a cependant montré
que ces variantes découlent de la perspective privilégiée entre les perspectives technologique,
opératoire, informationnel et stratégique. Le tableau 1 présente les définitions d'un ERP selon
ces différentes perspectives.

7
Tuteja, A. (1998). Enterprise Ressource Planning: What'sthere in it?.
6
Perspective Définition

Technologique Approche moderne d'acquisition d'un logiciel paramétrable dans le

cadre d'un processus d'affaires donné.

Opératoire Système liant toutes les opérations d'une entreprise.

Informationnelle Ensemble de modules intégrés les uns aux autres par une base de
données commune et qui permettent de gérer les principaux processus
d'affaires de l'organisation.

Stratégique Intégrer et aligner l'organisation tout en standardisant les processus

(en comparaison à son industrie) dans le but d'améliorer la capacité et
s'assurer d'une croissance soutenable.

Tableau 1: Différentes perspectives de définition d'un ERP Source:BareIl, Bermer et Rondeau (2000).

Malgré l'utilisation de terminologies variantes par les divers auteurs, on peut tenter de
regrouper les différentes caractéristiques d'un système ERP (voir tableau 2).

Caractéristique Eléments explicatifs Auteurs

1) Intégration -Interconnexion Brown (2001); erpans.com

fonctionnelle et entre les (2001);
niveaux hiérarchiques Deloite Consulting
-Interaction entre les (1999);Lequeux (2002);
différents processus. Rowe (1999).

2) Complétude -Variété étendue de Brown (2001);erpans.com

(fonctionnalité générique) fonctions (2001); Deloitte Consulting
-Applicable à différentes extra-(1999); Lequeux
sortes d’entreprises organisationnel) (2002);
-Connectivité avec Rowe (1999); Tuteja (1998).

7
 l'extérieur

3) Homogénéisation -Référentiel unique de Consulting (1999);Lequeux

données (2002); Brown (2001);
-Uniformisation des Deloite
interfaces homme-machines
-Unicité de l'administration
du système

4) Instantanéité -Mise à jour et consultation Osterle et al. (200

en temps réel I);DeloiteConsulting (1999).

5) Adaptabilité (flexibilité) -Capacité à suivre les Lequeux (2002);Rowe

changements de règles et (1999);Tuteja(1998).
d'organisation; rendue
possible par les fonctions de
paramétrage

6) Ouverture évolutive -Modularité Lequeux (2002);

-Portabilité Rowe (1999);Tuteja (1998).

7) Transversalité (orientation -Conception du système Carbonel (2001);

processus) dans une optique des Erpfans.com (2001); Klaus
processus d'affaires pour et al. (2000).
atteindre les objectifs
organisationnels

8) Pratiques d'affaires -Le système est porteur de Smyth (2001 b);Tuteja

pratiques éprouvées dans le exemplaires (1998).
domaine

9) Simulation -La réalité des processus Rowe (1999);Tuteja

d'affaires peut être simulée
sur ordinateur (1998).

8
 Tableau 2: Récapitulation des principales caractéristiques attribuées à un ERP

Ces différentes caractéristiques peuvent être regroupées en fonction de trois principales

dimensions comme l'illustre la figure 1.

Figure 1: les caractéristiques d’un ERP regroupé en 3 dimensions

La dimension technique fait référence aux caractéristiques propres aux possibilités offertes
par le système en matière de développement des applications. Elle regroupe deux dimensions:
l'adaptabilité (flexibilité) et l'ouverture évolutive. La dimension organisationnelle regroupe les
caractéristiques ayant trait à l'envergure et au déploiement du système dans l'organisation:
l'intégration, la complétude (fonctionnalité générique), l'homogénéisation, la transversalité et
les pratiques exemplaires. La dimension informationnelle regroupe les caractéristiques
relatives à la qualité de l'information que permet de générer le système: l'instantanéité et la
simulation. On peut voir que les caractéristiques d'un système ERP sont beaucoup plus de
nature organisationnelle que technique, et ceci justifie l'assertion selon laquelle un PGI est

9
plus un système organisationnel que technique 8. Ainsi donc, même si l'on ne peut nier que
l'implantation d'un ERP constitue un pari technique de taille, sa réussite (ou son échec) tient
beaucoup plus des facteurs organisationnels et managériaux que des considérations d'ordre9.
Avoir toutes les caractéristiques énumérées pour un ERP, il semble paré de toutes les vertus !
Mais il s'agit là d'une définition théorique, et toutes les caractéristiques énumérées ne sont pas
nécessairement propres à tous les systèmes ERP. Certains auteurs, tout en énumérant la
plupart de ces caractéristiques, identifient les critères de base (caractéristiques minimales)
requis pour qualifier un système d'ERP. C'est le cas notamment de Lequeux10 qui retient trois
critères : l'intégration, le référentiel unique de données, et l'adaptabilité. Mais, d'un point de
vue opérationnel, le problème le plus important ne réside pas tant dans le nombre étendu de
caractéristiques que dans la qualification même de ces critères. Par exemple, quand on parle
d'intégration, quel degré doit-elle atteindre ? Un système qui intègre trois des cinq ou six
fonctions de l'entreprise est-il suffisamment intégré ? À quel niveau doit être poussée
l’homogénéisation ?
Certains auteurs ajoutent aussi le caractère “progiciel” comme l’une des principales
caractéristiques d’un PGI, Les SGI ERP sont généralement des progiciels commerciaux
réalisés par des éditeurs de système d'entreprise tels que SAP, Peoplesoft, Oracle, Baan's et
autres. De plus, lorsqu'une organisation acquiert un ERP, elle entreprend une relation à long
terme avec son fournisseur. La plupart du temps, les organisations n'ont pas les ressources
pour supporter, maintenir ou modifier leur progiciel. Conséquemment, ils dépendent de leur
fournisseur pour poursuivre l'amélioration de leur ERP (Markus et Tanis, 2000).

De la définition théorique à la définition opérationnelle

Pour une définition opérationnelle d'un ERP, nous allons non seulement nous limiter à
quelques critères, mais aussi nous essayerons de voir de quelle façon ces critères pourraient
être concrètement mesurés. Pour les critères à retenir, nous relevons à travers la littérature les
critères les plus significatifs et les plus communs aux ERP. L'emphase est ici mise sur les
critères les plus discriminants, en écartant tous ceux qui paraissent redondants. Le tableau 3
présente les caractéristiques retenues pour la définition opérationnelle d'un ERP, et les

8
Patrick Besson,Les ERP à l'épreuve des organisations,1999, p.22
9
Sedera, D., Rosemann, M. et Gable, G. (2001). Using performance measurement models for benefit
realization with Enterprise Systems - The Queensland govemment approach (Case Study). In Actes
du gh European Conference on Information Systems, Bled, Slovenia, June 27-29.837-847.
10
Jean-Louis LEQUEUX, manager avec les ERP, édition EYROLLES, 3ème édition, p.33
10
éléments qui justifient la prise en compte de telle caractéristique et le rejet de telle autre.
L'ordre de présentation suivi est celui de la figure 1.

Caractéristique Retenue : Oui (✔) Justification

Non (x)

Adaptabilité (flexibilité) ✔ Critère indispensable : avec tous les

organisationnelle, si un investissements qu'il requiert, et l'ampleur de la
ERP n'est pas adaptable, couverture organisationnelle, si un ERP n'est pas
il limiterait les adaptable, il limiterait les possibilités de
possibilités de développement de l'organisation dans un
développement de environnement très changeant.
l'organisation dans un
environnement très
changeant.

Ouverture évolutive X Critère pouvant être intégré dans celui

Critère pouvant être d'adaptabilité, dans la mesure où la modularité et
intégré dans celui la portabilité sont des facteurs de flexibilité
d'adaptabilité, dans la
mesure où la modularité
et la portabilité sont des
facteurs de flexibilité

Intégration ✔ Sans doute le critère le plus important. C'est

l'avantage majeur d'un ERP sur les systèmes
traditionnels cloisonnés dans les fonctions
respectives de l'entreprise ou à différents paliers
hiérarchiques, avec des possibilités de
communication nulles ou très limitées. g

Complétude X Poussé à l'extrême, ce critère est irréaliste: un

système (fonctionnalité générique pour toutes les

11
 fonctions et toutes les industries est générique)
difficile à concevoir. Et puis, le critère
d'intégration suffirait à rendre compte de la
considération de plusieurs fonctions, et des
entités externes.

Homogénéisation X C'est un critère qui est subordonné aux besoins

d'intégration: si celle-ci peut se faire sans
homogénéisation (par des logiciels d'interface
par exemple) le critère perd sa raison d'être.

Transversalité ✔ L'orientation processus est une caractéristique

essentielle des ERP qui leur permet d'éliminer
dans le processus des opérations qui n'apportent
aucune valeur ajoutée à l'output tant à l'interne
qu'à l'externe.

Pratiques X Critère qui ne peut être généralisé en raison de

l'existence exemplaires (Best d'entreprises qui
tirent un avantage compétitif des pratiques
Business Practices) particulières non modelées
aux pratiques normatives du secteur :
l'universalité des pratiques exemplaires est
sujette à caution. En plus, l'environnement étant
changeant, les pratiques considérées comme les
meilleures aujourd'hui ne le seront peut-être plus
demain.

Instantanéité X C'est une conséquence d'une intégration réussie.

Simulation X Conséquence de l'intégration de toutes les

fonctions de l'entreprise. C'est cette intégration
qui permet de simuler l'effet d'un input sur
l'ensemble des activités de l'organisation.

Tableau 3: Caractéristiques retenues pour la définition opérationnelle d'un ERP

12
Théories et modèles appliqués à l’adoption des ERP
Ce paragraphe présente quelques approches théoriques qui peuvent servir pour décrire et
comprendre le phénomène d'adoption des PGI. Nous avons choisi quatre théories applicables
à l'adoption des PGI et qui sont « universelles»: la théorie du changement organisationnel,
plus précisément, le cadre théorique de Boudreau et Robey(1999), la théorie de diffusion de
l'innovation, la théorie néo-institutionnelle et la théorie de la complexité. En suivant les
recommandations d'Holmstrom (2005), pour chaque théorie, nous présentons un bref
historique, les concepts clés, les limites ou critiques éventuelles et quelques recherches ayant
eu recours à cette théorie dans le domaine des PGI.

1. la théorie du changement organisationnel

Il y a presque unanimité dans les recherches pour reconnaître le caractère critique de la
conduite du changement organisationnel dans l'implantation d'un PGI (Aladwani, 2001;
Davenport, 1998;Esteves et Pastor, 2000; Parr, Shanks et Darke, 1999; Somers et Nelson,
2004).11
L'implantation d'un PGI affecte généralement la stratégie, la structure et la culture de
l'organisation12 ainsi que le modèle d'affaires de l'organisation13. Le changement induit par un
PGI peut donc être considéré comme un changement d'ordre stratégique (Hafsi et Fabi, 1997).
Enfin, d'après Robey et al. (2002), l'implantation d'un PGI s'accompagne généralement d'un
certain degré de changement organisationnel.

2. La théorie de la diffusion de l'innovation.

Rogers (2003) définit la diffusion d'une innovation comme un processus social ayant quatre
caractéristiques principales : « Diffusion is a process by which an innovation is communicated
through certain channels over time among the members of a social system» 14
Dans cette définition, « une innovation représente une idée, une pratique ou un objet qui est
perçu comme étant nouveau par l'entité qui l'adopte » Cette définition semble applicable aux

11
Placide poba-nizou, Processus d’adoption et réduction du risque d’implantation des PGI dans les
PME : études de cas multiples, thèse présentée à l’université du Québéque en 2008.
12
Yen, R. H. et Sheu, C. y. (2004). Aligning ERP implementation with competitive priorities of
manufaturingfirms : An exploratory study. International Journal of Production Economics, 92, 207-220.
13
Robey, D., Ross, 1. W. et Boudreau, M.-C. (2002). Learning to Implement Enterprise
Systems : An Exploratory Study of the Dialectics of Change. Journal of Management Information
Systems, 19(1),17-46.
14
Rogers, E. M. (2003). Diffusion of Innovations (5e éd.). New York: The Free Press,p.11
13
PGI qui sont à la fois des objets techniques, des idées et des pratiques, généralement perçus
comme nouvelles dans l'organisation adoptante. Selon cet auteur, les caractéristiques d'une
innovation, telles que perçues par les individus ou membres d'un système social, aident à
expliquer les différents taux d'adoption de cette innovation. Il distingue cinq attributs de
l'innovation qui influencent son adoption. La première caractéristique est l'avantage
concurrentiel, c'est-à-dire que l'innovation est perçue comme étant supérieure à ce qu'elle
remplace. Les quatre autres caractéristiques ont trait à la technologique proprement dite. Il
s'agit de la compatibilité de la technologie (avec le fonctionnement interne et les systèmes de
l'organisation), la complexité (l'intelligibilité et la convivialité), l'observabilité des résultats et
la capacité d'expérimentation.

3. La théorie néo-institutionnelle.
La théorie néo-institutionnelle soutient que les organisations peuvent adopter des pratiques ou
des procédures indépendamment des préoccupations de contrôle, de coordination et
d'efficacité immédiate de ces pratiques ou procédures (Meyer et Rowan, 1977). En d'autres
termes, dans un « contexte institutionnel » donné, ces pratiques ou procédures sont
imprégnées de propriétés fonctionnelles et symboliques reconnues qui influencent leur
adoption15.
Le fondement de la théorie néo-institutionnelle présenté ci-dessus qui stipule que les
organisations adoptent des pratiques, des procédures ou des innovations, en réponse aux
attentes externes semble applicable aux PGI. D'ailleurs, une assertion de Jim Convis,
président de User Solution inc est cohérente avec ce propos: « The nature of manufacturing
dictates that once you get to a certain size, you must implement an ERP system just to stay in
business »16.
En contraste avec la plupart des auteurs, par exemple Marbert et al. (2000), O'Leary (2000)
ainsi que Thévenon (2005) qui indiquent que les motivations pour l'adoption des PGI ont
essentiellement trait à la compétitivité par nature (Benders etal., 2006, Caldas et Wood (1999)
ont mis en évidence d'autres types de motivations. Cette étude a révélé que les organisations
ont adopté un PGI pour suivre la « tendance » (77 %) et du fait de l'influence des « gourous»
du management ou des consultants (23 %), c'est là une manifestation de l'isomorphisme
mimétique. La même étude a révélé que les organisations ont adopté un PGI en réponse à la

15
Meyer, 1. W. et Rowan, B. (1977). Institutional organizations: formaI structure as myth and
ceremony. American Journal ofSociology, 83, 340-63
16
Chalmers, R. E. (1999). Small manufacturers seek best ERP fit. Manufacturing
Engineering, p.44.
14
pression de la maison-mère (41 %) et en réponse aux pressions des clients ou des fournisseurs
(11 %), ce qui illustre l'isomorphisme coercitif.

4. La théorie de la complexité.
Durant les dernières décennies, l'intérêt des chercheurs pour la théorie de la complexité n'a
cessé de croître. Les travaux contemporains sur la complexité prennent leurs sources dans la
théorie générale des systèmes qui proposait dès 1928 d'appréhender les organismes vivants
comme des systèmes complexes. Viennent ensuite les travaux de McCulloch et Pitts (1943,
dans Thiétart, 2001) sur les réseaux neuronaux, en cybernétique et sur les automates
cellulaires. En somme, plusieurs disciplines ont participé à la construction de la théorie de la
complexité : l'étude de la dynamique des systèmes en sciences physiques, les mathématiques,
l'informatique, la cybernétique, la théorie générale des systèmes, la théorie de l'information,
les sciences naturelles et la biologie, l'économie et la linguistique.
La définition d'un phénomène ou d'un système complexe est assez difficile (Cilliers, 1998;
Morel et Ramanujam, 1999).Selon Jacucci, Hanseth et Lyytinen (2006), la définition de la
complexité et celle des systèmes complexes varient selon l'approche utilisée et le champ de
recherche.
Toutefois, Cellier (1998) repris par Jacucci17 et al. propose de définir lacomplexité de la
manière suivante: « Complexity generally refers to an emergentpro pert y of systems made of
large numbers of self-organizing agents that interact in adynamic and non-linear fashion and
share a path dependent history ».
Deuxièmement, les recherches ayant eu recours à la théorie de la complexité.
Plusieurs recherches ont eu recours à la théorie de la complexité pour étudier des phénomènes
sociaux. Cette théorie a notamment été utilisée dans les domaines de l'économie (Baumol et
Benhabib, 1989), de la gestion de la chaîne logistique (Wilding, 1998), des réseaux
d'entreprises (Choi, Dooley et Rungtusanathan, 2001) et du management stratégique (Levy,
1994). D'après McBride (2005), malgré un recours croissant à la théorie de la complexité dans
la recherche en management et en organisation, cette théorie constitue une source
d'inspiration encore négligée par les chercheurs en système d'information malgré son
potentiel. Dans l'éditorial d'un numéro spécial consacré à l'usage de la théorie de la

17
Jacucci, E., Hanseth, O. et Lyytinen, K. (2006). Introduction: Taking complexityseriously in IS
research. Information Technology& People, 19(1), 5-11, p.6
15
complexité dans la discipline des systèmes d'information, Jucucci, Hanseth et Lyytinen (2006)
lancent un appel pour l'utilisation de cette théorie dans cette discipline.
Quelques études18 (Dhillon et Ward, 2002; Kim et Kaplan, 2006; McBride, 2005;Mufatto et
Faldani, 2003; Van Aardt, 2004; Xia et Lee, 2004) ont eu recours à la théorie de la complexité
dans le domaine des systèmes d'information. Dhillon et Ward (2002) ainsi que McBride
(2005) font appel à la théorie du chaos alors que Kimet Kaplan (2006) et Van Aardt (2004)
ainsi que Mufatto et Faldani (2003) s'appuient sur la notion de système adaptatif complexe.
De leur côté, Xia et Lee (2005), repris par Benbya et McKelvey (2006), proposent un modèle
matriciel ayant quatre dimensions, pour mesurer la complexité des projets de développement
et d'implantation de TI/SI. Ces quatre dimensions sont: complexité organisationnelle versus
technologique et complexité structurelle versus dynamique.

La caractérisation du processus d'adoption d'un PGI comme un phénomène complexe. Le

processus d'implantation d'un système d'information met en action des interactions de facteurs
humains, organisationnels et technologiques qui sont difficilement séparables (Walsham et
Waema, 1988). Ces auteurs soulignent que le système d'information devrait être considéré
comme un système social dans lequel la technologie ne représente qu'une des dimensions. De
la même manière, le processus d'adoption d'un PGI est un processus social qui fait interagir
plusieurs acteurs. Or, les systèmes d'interactions sociales sont des exemples de systèmes
complexes (Cilliers,1998; Cole, 2002). D'après Cole (2002), les processus sociaux sont des
systèmes complexes dans lesquels les individus interagissent à travers le langage, les
symboles, les cultures, les médiums de communication, etc. Le processus d'adoption d'un PGI
peut donc être considéré comme un processus complexe dans lequel la technologie ne
représente qu'une dimension. Si l'on accepte que le processus d'adoption d'un PGI soit un
système complexe, plusieurs conséquences peuvent être tirées notamment, 1)le processus
d'adoption d'un PGI possède les caractéristiques d'un système complexe soit, l'émergence, la
non-linéarité, l' auto-organisation, loin de l' état d' équilibre et la dépendance au chemin, 2) en
nous basant sur Choi et al. (2001) nous déduisons que des régularités (patterns) devraient être
observées dans le comportement du processus d'adoption d'un PGI.

Typologie des PGI

18
Placide poba-nizou, op.cit p.128
16
Il existe sur le marché deux grands types d’ERP : ERP Propriétaire et ERP Open Source. Que
ce soit un ERP Propriétaire ou Open Source, il permet aux entreprises de partager toutes leurs
informations au sein d’une base de données unique et commune à tous les services : achat,
vente, comptabilité, finance, direction, marketing, logistique, production, maintenance… Il
facilite ainsi la prise de décisions de gestion et d’administration, de distribution, de production
et d’approvisionnement.

1. Les PGI propriétaires

Un ERP propriétaire est un progiciel conçu par un éditeur unique. Il comprend de nombreux
modules tels que la production, les achats, les ventes ou les stocks. Il existe deux grands types
d’ERP propriétaires : les généralistes qui proposent des fonctionnalités standards et les
verticaux offrant des fonctionnalités adaptées à des métiers, à des besoins bien spécifiques.
Au commencement était l’ERP généraliste. Logiciel standard, non modifiable, sans possibilité
de développement sur-mesure, il entendait répondre aux besoins des entreprises de la Terre
entière, quel que soit leur secteur d’activité.
« Tout le monde logé à la même enseigne »19, telle était la devise de l’ERP généraliste.
Mais certains clients demandaient des logiciels capables d’aller plus loin et de s’adapter, dans
une certaine mesure, à leur métier. Il n’en fallait pas plus aux éditeurs pour repenser leur socle
générique et en faire une solution verticalisable ! Des intégrateurs spécialisés ont alors
développé des briques supplémentaires, adaptées à une branche ou à un métier en particulier
et capables de se greffer sur le socle générique des éditeurs.

Le marché des ERP propriétaires : plus chers, mais performants

Le marché des ERP propriétaires est composé de PGI (Progiciels de gestion intégrée) sous
licence. Principalement destinés aux très grosses entreprises, les ERP propriétaires sont plus
chers, mais aussi plus performants et plus personnalisables.

La mise en place d'un ERP propriétaire inclut un accompagnement dans le projet ERP et un
service après-vente.
Parmi les progiciels ERP propriétaires, on trouve les suivants :

● SAP,
● Oracle,

19
https://www.silog.fr/erp-proprietaire-ou-open-source, consulté le 13/05/2019 12:00
17
 ● GEAC,
● SAGE,
● SSA Global, etc.

Le cabinet Panorama Consulting a publié une étude sur le marché de l’ERP, sobrement
intitulée « Clash of the Titans 2016 ». Deux principales tendances se dégagent : SAP domine
toujours le secteur de l’ERP, et les trois gros leaders ont été rejoints par l’outsider Infor.

L’étude de Panorama a été menée sur 519 entreprises ayant choisi ou déployé un ERP durant
la période entre juin 2014 et octobre 2015. En première place, pas de surprise : SAP est
toujours en tête, avec 23 % de représentation sur le marché. Son éternel rival, Oracle, a quant
à lui été choisi par 16 % des personnes sondées. Toutefois, Oracle arrive à égalité avec Infor
(16 % également de parts du marché) : classée parmi la masse des éditeurs Tier II lors du «
Clash of the Titans 2014 », la société a en quelques années pris du galon et déclassé
Microsoft, dont la gamme Dynamics n’a été sélectionnée que par 9 % des sondés.

Figure 2: Le marché des PGI en 2016

2. les PGI open source:

Les logiciels Open Source sont nées en 1998 d’une scission de la communauté de logiciels
libres. Un ERP Open Source est un logiciel au code source ouvert. Attention il ne faut pas

18
confondre ERP Open Source et logiciels libres. Un logiciel libre peut être utilisé modifié et
distribué librement.
La grande différence entre les deux solutions est qu’il vous est strictement interdit de revendre
un ERP Open Source.
L’ERP Open Source s’adresse, lui, plus particulièrement aux TPE et PME ne pouvant ou ne
souhaitant pas investir dans un logiciel propriétaire. Cet outil coûte en effet moins cher qu’un
ERP propriétaire et ne nécessite pas d’acquisition de licence.
Un ERP Open Source est susceptible d’offrir les mêmes fonctionnalités standards qu’un ERP
propriétaire. Par contre, côté logiciel et offres de services, les intégrateurs ne sont pas très
nombreux sur le marché. Vous n’aurez donc le choix qu’entre quelques solutions.
Dans le marché de l’open source : on peut citer 5 principaux éditeurs :

 Odoo : (anciennement OpenERP et TenyERP) grand gagnant du classement: Odoo est

un ERP rafraîchissant. Conçu autour d'Applications que vous assemblez à votre
convenance, Odoo est ergonomique, rapide et orienté vers les canaux de vente
modernes. Dans son dernier lot de nouveautés Odoo permet par exemple de créer un
site eCommerce et de gérer un point de vente. Il permet de piloter également les
actions de recrutement de talents. Odoo est un ERP pour les TPE et PME voulant
innover et se réinventer.

 Dolibarrc’est une légende des ERP et CRM Open Source. Il est par ailleurs le seul de
sa catégorie à être conçu pour les petites structures : indépendants, TPE, startups et
petites PME. Dolibarr est conçu sur des technologies éprouvées par une communauté
de développeurs très dynamique. Ses modules ne font pas d'impasses fonctionnelles. Il
prend la deuxième position de ce classement pour sa gratuité totale et ses
améliorations ergonomiques apportées dans sa dernière version.

 Axelor :c’est un ERP Open Source qui n'est pas seulement beau : il est ergonomique
et offre de nombreuses fonctionnalités collaboratives. Il fait oublier les ERP étouffants
en offrant des vues claires permettant de travailler aussi bien sur des tâches
opérationnelles que du décisionnel. Les technologies utilisées par Axelor sont à la
pointe du marché et sont particulièrement bien exploitées dans cet outil très interactif.

 Openbravo : un ERP libre qui dispose des moyens de ses ambitions grâce à des
levées de fond très conséquentes. Openbravo est un classique orienté "retail". Il

19
 convient particulièrement aux PME dans le secteur du commerce de bien grâce à sa
gestion fine de tous les canaux de vente, ainsi que des produits mis au catalogue. Le
nombre de contributeurs au projet Openbravo est tout simplement gigantesque et
garantit une longue vie à cet ERP Open Source.

 Compiere :un ERP robuste adapté aux niveaux d'exigences les plus élevées. Son ERP
et son CRM fonctionnent en duo parfaitement, et les sous-ensembles métiers sont
personnalisables à souhait. Compiere est réputé pour son modèle de données reposant
sur un Data Dictionary très efficace accessible par l'éditeur et les Web Services. Cet
ERP Open Source s'adresse aux grandes PME qui souhaitent réduire leurs frais de
fonctionnement.

Classement ERP Nombre d'utilisateurs

1 Odoo 2 000 000

2 Dolibarr 1 000 00020

3 Axelor Inconnu

4 Openbravo 31 00021

5 Compiere 9 000

Figure 3: Classement des ERP Opensource

source: https://www.appvizer.fr/magazine/operations/erp/top-5-erp-gratuit-open-source#erp-
open-source-definition-et-tendances-2018, consulté le 13/05/2019 13:30

3. Liste des ERP Open Source hors classement

Les ERP Open Source et gratuits ne sont pas nombreux. Ils méritent donc d'être tous cités
pour élargir votre champ de recherche si nécessaire. Les voici :

● ADempiere ERP (dérivé de Campiere)

● Apache OFBiz

20
estimation du site officiel de Dolibarrhttps://wiki.dolibarr.org/index.php/FAQ_Qui_utilise_Dolibarr
consulté le 13/05/2019
21
site officiel OpenBravohttp://www.openbravo.com/fr/about/news/openbravo-retail-subscriptions-
growth-soars-beyond-expectations-driven-by-openbravo-cloud-fr/ , consulté le 13/05/2019
20
 ● ERP5
● Negocia
● NOALYSS
● OBM
● Onix ERP / CRM
● OpenAguila
● OpenConcerto
● openinfo3w
● SpeeDealing,
● Tryton

Section 2 : Histoire et évolution des PGI

La technologie informatique a débuté à la fin de la seconde guerre mondiale 22. Elle est restée
très longtemps une affaire d’artisans de génie. Ce n’est que progressivement qu’elle s’est
industrialisée, commençant bien sûr par le matériel, dès les années soixante-dix. Les années
quatre-vingt ont vu la production industrielle de certains logiciels. Les éditeurs ont commencé
par les logiciels pour micro-ordinateur : systèmes d’exploitation, gestionnaires de réseaux
locaux. En général, ils ont pu éditer de façon industrielle toutes les applications très
horizontales où les pratiques professionnelles sont quasi invariantes d’une entreprise à une
autre à travers le monde Par exemple, les progiciels de bureautique, les applications de CAO.
Si les systèmes ERP sont apparus sur le marché au milieu des années 1990, l'idée d'intégration
de toutes les fonctions de l'entreprise en un seul système est loin d'être récente. Tout semble
indiquer que si l'intégration ne s'est pas réalisée plus tôt, c'est que les techniques de gestion, et
surtout les moyens technologiques dont on disposait, ne le permettaient pas encore. En effet,
selon Tuteja (1998)23, l'ERP est le résultat de 40 ans d'essais et erreurs, et il a évolué en tant
qu'outil stratégique grâce aux améliorations continues dans les techniques de gestion et grâce
à la croissance rapide des technologies de l'information. Forest24 affirme de son coté, que si

22
Jean-Louis LEQUEUX, op.cit, p.39
23
A.TUTEJA, enterprise resource planning : what’s there in it
http://www.angelfire.com/co/troyc/erp.html
Forest, Généalogie des ERP et gestion des flux physiques. Systèmes d'Information et
24

Management, 4(4), 71-89,1999, p. 78

21
l'appellation ERP est nouvelle, on retrouve dans la plupart de ces. Logiciels, les concepts
informatiques des années 1970 qui s'appuient tous ou presque sur la logique MRP (matérial
requirement planning). Forest note par ailleurs que le concept COPICS (communication
oriented production inventory control systems) d'IBM, datant de 1975, peut être considéré
comme un des premiers concepts de progiciel intégré. Mais avant de voir les étapes
d'évolution du système lui-même, commençons par voir l'évolution du contexte qui a eu une
incidence sur son développement.

 Le contexte d’émergence des PGI

Le système ERP s'est développé à la faveur d'une double évolution : métamorphose du monde
des affaires (nouvelles exigences) et des développements technologiques. La figure illustre
cette double poussée qui a conduit à l'émergence des ERP. Les effets combinés des exigences
de plus en plus pressantes du monde des affaires et des développements technologiques ont
conduit à une évolution croissante des rôles des SI/TI dans les entreprises. Comme le montre
O'Brien (2001, p. 30), les rôles remplis par les SI ont pris beaucoup d'expansion des années
1950 à nos jours. Si l'on parle d'expansion, c'est que l'apparition de nouveaux rôles ne fait pas
disparaître les anciens rôles : même de nos jours, en plus des rôles beaucoup plus complexes,
les SI continuent à remplir le rôle de traitement transactionnel qui constituait leur raison d'être
dans les années 1950-1960.

22
 Figure 2 : L'émergence des ERP sous l'effet d'une double évolution dans les technologies et dans les affaires

Ce qui nous intéresse particulièrement dans cette expansion des rôles des SI, c'est de voir
qu'elle aboutit, dans les années 1990-2000 à une plus grande intégration des SI, par le
réseautage intra-organisationnel et inter-organisationnel, l'intégration étant la principale
caractéristique des systèmes ERP. D'ailleurs, selon le modèle des étapes d'évolution des SI de
Nolan (1979) (initiation - expansion - formalisation -intégration - administration de données -
maturité), l'intégration représente une étape vers la maturité des SI. Il n'est d'ailleurs pas banal
de noter que dans le modèle de Nolan (1979) la phase même de maturité du SI est définie
entre autres par «l'intégration des applications ». Tout ceci montre que l'apparition des ERP
s'inscrivait dans la droite ligne de l'expansion des rôles des SI à travers le temps.
Dans cet ordre d'idée, Ross (2003) montre bien que l'adoption d'un système ERP s'inscrit bien
dans le processus de maturation de l'architecture TI. Elle identifie quatre phases d'évolution de
l'architecture TI: a) phase des applications en silo (application silo architecture stage), b)
phase de la standardisation de la technologie (standardized technology architecture stage), c)
phase de la rationalisation des données (rationalized data architecture stage), d) phase
modulaire (modular architecture stage). L'analyse de Ross (2003) montre que l'organisation
peut se servir d'un système ERP pour passer d'une phase à l'autre. Si actuellement les
systèmes ERP semblent constituer la norme vers laquelle les entreprises s'orientent dans leur
processus d'informatisation (Peslak, 2006), cette évolution est vécue différemment, en
fonction du degré d'informatisation de chaque organisation évalué sur les dimensions de la
couverture organisationnelle et du degré d'intégration. La figure en fait l'illustration.

23
 source:Tomas,J.-L. ERP et
Figure 4: Figure: Évolution de l'informatisation vers les systèmes ER ,
PGI : Sélection, déploiement et utilisation opérationnelle, DUNOD,P.20

L'on peut ainsi identifier trois catégories de situations concernant les entreprises désireuses
d'implanter un système ERP. La première situation concerne les entreprises qui empruntent le
chemin illustré à la figure par (l a) et (l b) : il s'agit ici de la situation la plus classique. Au
cours des dernières années, dans leurs efforts d'informatisation, les entreprises se sont dotées
des applications couvrant pratiquement l'ensemble de leurs activités, mais comme chaque
département/fonction ou unité de l'entreprise développait son système selon ses propres
besoins, on en est vite arrivé à une multitude de systèmes ne pouvant pas communiquer les
uns avec les autres. Pour passer de cette situation à un système ERP (l b), les entreprises se
trouvent confrontées à la difficulté d'harmoniser des pratiques ayant évolué séparément en
plus de celle liée à la question de savoir ce que l'on fait des anciens systèmes (legacysystems).
La deuxième situation est celle des entreprises qui suivent le chemin (2a) -(2b) : les
entreprises qui peuvent suivre ce cheminement sont celles qui, au moment où elles décident
d'implanter un système ERP, sont peu ou pas du tout informatisées. En partant, elles décident
d'intégrer les différentes fonctions, et procèdent de façon modulaire. La troisième situation
24
concerne les entreprises qui empruntent le chemin (3) : ICI encore, au moment de la décision
d'implantation d'un système ERP, les entreprises sont peu ou. pas informatisées, mais à la
différence de la situation précédente, elles décident de l'implanter d'un seul coup, c'est-à-dire
que l'ensemble des activités sont touchées en même temps. C'est l'implantation big-bang.

Évolution du PGI
Les auteurs s'accordent généralement pour situer les origines des systèmes ERP dans les
années 1970, avec l'émergence des MRP. La figure illustre les principales phases d'évolution
des ERP, avec les développements associés ou parallèles qui ont enrichi cette évolution.
Différentes étapes de l'évolution qui a conduit à l'émergence de l'ERP peuvent être identifiées

Figure 5: évolution de l'ERP

Source: Adapté avec SYLVIANE GLAUDE, L'ÉVOLUTION DES PROGICIELS DE GESTION

INTÉGRÉE:UNE APPROCHE PAR GESTION DE PORTEFEUILLE DE PROJET, p.4

Les années 1960-1970 ont vu se développer des ICS (inventory control systems) et la
technique MRP. Des ICS utilisés pour un suivi automatisé des stocks, on est vite passé au
MRP, une technique proactive de gestion des matières premières, les besoins en matières

25
premières étant calculés en fonction de la nomenclature des 79 produits finis, suivant le plan
directeur de production. La complexité des nomenclatures de produits rendait nécessaire
l'utilisation de l'informatique. Les succès atteints avec le MRP ont amené les entreprises à
vouloir appliquer le principe, non plus seulement en amont, mais en aval du processus de
production. Est ainsi apparu le DRP (distribution requirement planning), pour la
détermination des besoins en produits finis. Les années 1980 : le MRP a prouvé son efficacité
comme outil de gestion des stocks, mais il s'est vite avéré limité par le fait qu'il ne prend pas
en compte les autres ressources de l'organisation. Le MRP (material requirement planning)
fait place au MRP-II (manufacturing resources planning). Le MRP-II ajoute à la gestion des
stocks, la gestion de la capacité de production, le calcul du chemin critique, et le plan
directeur de production. Le MRP-II prend également en ligne de compte la gestion financière
des processus manufacturiers. L'intégration de toutes les activités manufacturières de
l'organisation, incluant la gestion des besoins en matières, les activités d'ordonnancement et
de pilotage des processus de production, et la gestion financière de toutes ces activités a
conduit à parler de CIM (computer integrated manufacturing). Avec les années 1990, c'est
l'avènement des ERP. Les entreprises se sont rendues compte que l'optimisation et la
satisfaction des clients ne se limitent pas aux seuls processus manufacturiers, qu'elles
s'appliquent plutôt à l'entreprise entière, incluant ainsi les fonctions plus administratives
(ventes et distribution, ressources humaines). L'intégration de plusieurs fonctions de
l'entreprise a ainsi conduit à l'appellation ERP (enterprise-wide) resources planning). Même si
les conceptions MRP, MRP-II et CIM avaient pris naissance dans le milieu manufacturier,
elles pouvaient être facilement généralisées au secteur tertiaire. Les années 2000 :
actuellement, les entreprises ne se limitent plus à la seule intégration de toutes leurs fonctions
dans un système ERP, elles veulent que ce dernier leur permette d'améliorer les relations avec
les partenaires. C'est ainsi que 80 l'on parle de XRP (extended ERP) (Ndede-Amadi,
2004;Rosemann et Wiese, 1999), pour signifier la connectivité que permet le système avec les
différents partenaires de la chaîne de valeur de l'entreprise, ou les partenaires d'un même
réseau horizontal. D'autres parlent d'ERP-II en référence à ce phénomène d'extension du
système (Harrington, 2001; M0ller, 2005; Ndede-Amadi, 2004; Weston Jr, 2003), ou encore
d'APS (advanced planning and scheduling systems) (Kraemmergaard et Rose, 2002). Les
concepts de CRM (customer relationship management) et de SCM (supply chain
management) sont le reflet de cette extension des systèmes ERP. C'est à ce titre que différents
auteurs (Chen, 2001; Esteves et Pastor, 2001; Esteves et Pastor, 1999) considèrent le SCM et

26
le CRM comme une phase d'évolution des systèmes ERP. Dans cette perspective, on pourrait
même relier l'évolution des ERP au commerce électronique (B2B, B2C). En effet, le
développement du commerce électronique incite les entreprises à se doter d'un système
intégré pour mieux répondre en temps réel aux demandes du marché (Ash et Bum,
2003;Jaiswal, 2002). Comme on peut le voir, l'évolution des systèmes ERP a consacré le
passage de l'informatique du back-office aufront-office : aux débuts, seules les opérations en
amont, à l'abri du destinataire des produits/services, étaient prises en charge par les systèmes
de gestion, et au fur et à mesure que ces systèmes se sont développés, ils ont intégré des
opérations en aval et en contact plus ou moins direct avec le client.

Conclusion :
Ce premier chapitre a permis de clarifier le concept de PGI. La définition théorique du
système et la détermination de ses caractéristiques essentielles nous permettra, le moment
venu, de juger si un système en opération dans une entreprise étudiée peut être qualifié de
système ERP, et rentre ainsi dans la catégorie des systèmes qui font l'objet de la présente
étude. Le deuxième chapitre sera quant à lui consacré pour La mise en place des PGI comme
des projets nécessitant l’intervention de différentes ressources et nécessitant de le découper en
plusieurs tâches.

27
 Chapitre 2 : La mise en place d’un PGI : un méga projet

Introduction :
Depuis l’arrivée des ERP, les entreprises commençaient à intégrer cette nouvelle démarche
d’organisation et de gestion, l’appel à une telle démarche ne cessent pas à augmenter puisque
les entreprises ont connu l’importance d’implémenter un système de gestion intégré couvrant
toutes les activités. L’appel à ce genre des systèmes a engendré de nouveaux métiers et un
nouveau type de projet et de son management spécifique au système d’information c’est la
mise en place des systèmes d’information en particulier les ERP. C’est l’objet du présent
chapitre, il s’agit d’analyser la mise en place en tant qu’un projet nécessitant différents
ressources à collaborer pour y réussir. C’est la raison pour laquelle les entreprises désirantes
s’orienter vers une vision ERP font appel aux intégrateurs qui maitrisent bien ce genre de
projet et qui possèdent toutes les ressources nécessaires pour réussir la mise en place d’un
ERP.

Section 1 : Théories, tactiques et défis de la mise en place des PGI

Dans cette première section on va déterminer tout d’abord qu’est-ce qu’un projet, en
particulier un projet ERP, présenter des théories appliquées sur la mise en place des ERP et
analyser les ressources nécessaires pour faire face à la complexité de ces projets.

 Définition d’un projet ERP

Avant de parler d’ERP revenons à la définition d’un projet. Un projet est un effort temporaire
exercé dans le but de créer un produit, un service ou un résultat unique. La nature temporaire
des projets implique que le projet a un commencement et une fin déterminée. Un projet est
une façon d'organiser les ressources. Un groupe d'individus est assemblé pour effectuer
différentes tâches afin de réaliser un ensemble d’objectifs communs dans une période de
temps définie.
Selon l'AFNOR25, un projet est un processus unique qui consiste en un ensemble d'activités
coordonnées et maitrisées, comportant des dates de début et de fin, entrepris dans le but
d'atteindre un objectif conforme à des exigences spécifiques, incluant des contraintes de
délais, de coûts et de ressources. Un projet ERP désigne l'ensemble des processus et des
phases nécessaires à la sélection, à la mise en œuvre de l'ERP et au suivi après la mise en

25
Association Français pour la Normalisation
28
production. Le projet ERP peut être considéré comme un programme (ensemble de projets)
car la sélection, les phases de mise en œuvre et l'amélioration continue sont des projets en soi.
Comme évoqué précédemment, un ERP est conçu en modules, doté d’une architecture de
système ouvert communicant avec les systèmes ERP/non ERP externes et possède un
référentiel unique de données alimenté entre autres par les transactions quotidiennes des
opérations de l’entreprise.
Le Management d'un projet ERP diffère de celui d’un projet de développement ou d’un projet
d’intégration de système car il peut comporter des proportions variables d’intégration, de
développement, d’interfaçage et de paramétrage.
Un projet d’ERP présente deux caractéristiques difficiles à faire cohabiter:
- Fait appel à des produits du marché qui, forcément, n’ont pas été réalisé sur mesure pour
l’entreprise. Les éditeurs proposent des progiciels plutôt génériques configurables et
paramétrables.
- Doit répondre à des besoins d’entreprise qui paraissent très spécifiques. Chaque entreprise
est unique et cherche à avoir un ERP qui couvre au maximum ses besoins.
Un projet de mise en œuvre d'ERP est un projet de développement de l'entreprise, qui vise à
améliorer la performance opérationnelle et optimiser les ressources. Une organisation qui
implémente un ERP doit avoir une vision claire sur la manière avec laquelle elle mène ses
activités et sur les objectifs qu'elle souhaite atteindre en utilisant le système.
Le concept d'implémentation est traditionnellement lié à l'installation du matériel et du
logiciel. Dans le cas des systèmes ERP, ’’implémentation’’ est utilisé comme un terme pour
décrire l'ensemble du projet allant de la planification préliminaire du projet, passant par la
configuration, le paramétrage du système, la formation des utilisateurs jusqu'à l'utilisation
réelle du système. Ceci est en réalité, le point de vue des éditeurs et des consultants sur
l'implémentation. Du point de vue de l'entreprise, l'implémentation est le cycle d'apprentissage
continu où les processus organisationnels soutenus par l'ERP sont progressivement alignés
avec les objectifs de l'entreprise.

Théories appliquées sur la mise en place des ERP

L’une des études majeures est l’article d'Arinze 26 et al. qui ont proposé une méthodologie
pour configurer rapidement les systèmes ERP dans le processus de mise en œuvre. Leur but

26
Arinze, B et al., (2003). "A Framework for Using OO to Rapidly Configure ERP systems."
Communication of the ACM, p. 46
29
était de faire un processus de mise en œuvre plus simple, plus facile, moins coûteux et moins
fastidieux. À cette fin, ils ont désigné le " Enterprise Object Model (EOM) "en tant que cadre
et méthode de mappage pour capturer les besoins des utilisateurs en termes généraux et les
transformer en configuration détaillée paramètres du logiciel ERP ". L’étude a révélé que 1)
l’approche de la EOM était applicable à différents packages ERP; le EOM a eu un impact
positif sur le développement du système ERP; et l’extension réussie du prototype de EOM a
eu un impact significatif et économiques de configuration et de maintenance.

Basu27 et al.ont fourni un modèle théorique d’agence qui souligne l’importance de la gestion
de la relation de l’intégrateur pour une réalisation réussie des projets ERP à court et à long
terme. Dans cette théorie, l'organisation qui demande le système ERP était « le principal » et
l’intégrateur était « l'agent ». Leur théorie était basée sur deux concepts: sélection adverse et
l’aléa moral. Ces deux concepts ont été définis comme le fait que l'agent ait dissimulé des
informations pertinentes ou présenté de manière erronée capacité; et le fait d’éviter les efforts
de l’agent, ce qui « inclut les actions ou les comportements incompatibles avec les objectifs
du principal »28. Ces deux concepts ont un impact négatif sur le succès du projet ERP. Cette
étude est importante puisque le fournisseur la gestion des relations est apparue comme l’un
des défis majeurs des systèmes ERP la mise en œuvre.

Bradford et al. (2003)29 ont utilisé la théorie de la diffusion de l'innovation et la théorie de la

réussite des systèmes d'information pour générer un modèle de réussite de la mise en œuvre
d'un ERP. Le modèle a identifié les trois catégories de caractéristiques suivantes : innovation,
organisationnel et environnemental. Les conclusions de l’étude indiquent que le soutien de la
direction et la formation ont eu un impact positif sur le projet ;perçu la complexité de l'ERP et
la pression concurrentielle étaient négativement liées ; et un consensus dans les objectifs
organisationnels et la pression concurrentielle ont eu un impact positif sur la perception la
performance organisationnelle.

Huin30 a présenté un modèle d’utilisation de multi-agents pour la mise en œuvre des

27
Basu et al.: An Agency Theory Model of ERP Implementation, ACM Press: New York.
2004, pp 8-13.
Basu et al. 2003Op. cit, p.46
28
29
Bradford M. et al., (2003). "Examining the role of innovation diffusion factors on the implementation
success of enterprise resource planning systems." InternationalJournal of Accounting Information
systems, 4, 205-225.
30
Huin, S. F., (2004). "Managing deployment of ERP systems in SMEs using multi-agents."
30
Systèmes ERP dans les petites et moyennes entreprises (PME). L'étude était basée sur une
enquête dans les PME en Asie du Sud-Est. Ce modèle (la principale conclusion de l'étude) qui
visait à coordonner la gestion des ressources de l'entreprise pour favoriser une meilleure
gestion de ses ressources et du projet ERP. L'architecture de ce modèle de gestion des
ressources étaient une hiérarchie à trois niveaux avec la coordination agent au sommet de la
hiérarchie. Les agents de planification au milieu interagissaient entre eux et avec l'agent de
coordination ci-dessus et les agents d'exécution en dessous d'eux. Les agents d'exécution
interagie avec l'agent de planification.

Luo et Strong31 ont proposé un cadre pour les choix de mise en œuvre de l'ERP. Ce cadre était
destiné aux décisions de gestion concernant "les choix de personnalisation et les capacités
requises pour les accomplir". Les résultats de cette étude étaient la personnalisation options
présentées dans un tableau indiquant les options de personnalisation technique associées aux
options de personnalisation de processus.

El Amrani et al.32 ont examiné les stratégies de mise en œuvre des progiciels de gestion
intégrés et leurs effets sur la fonctionnalité dans l'ensemble de l'organisation. Ces auteurs ont
soutenu que d'autres études ne traitent pas de la vue d'ensemble inter fonctionnelle des
problèmes des entreprises. Les stratégies proposées comprenaient la vision organisationnelle,
la réingénierie des processus, la portée de l’ERP et les contraintes du calendrier de mise en
œuvre. La principale découverte de cette étude était une théorie des effets de la stratégie
d’implémentation de l’ERP qui fournissait un modèle de recherche.

Ifinedo33 a proposé un modèle de mesure du succès des systèmes ERP basé sur uneenquête
menée en Finlande et en Estonie. C’était une extension du modèle de base proposé par Sedera
et Gable (2004), qui comprenaient les éléments suivants: qualité du système, qualité de
l'information, impact individuel et impact organisationnel. Le modèle d'Ifinedo ajoute les
éléments suivants: qualité du fournisseur / consultant, impact du groupe de travail. Même si le

International Journal of Project Management, 22, 511-517.

31
Luo, W., and Strong, D. M., (2004). "A framework for evaluating ERP implementation
choices." IEEE Transactions on Engineering Management, 51, 3, 322-333.
32
El-Amrani, R. et al., (2006). "The effects of enterprise resource planning implementation
strategy on cross-functionality." Info Systems Journal. 2006, 16, 79-104.
33
Ifinedo, P., (2006). "Enterprise Resource Planning Systems success measurement: An Extended
Model." International Conference on Enterprise Information Systems (ICEIS) 2006 - Databases and
Information Systems Integration.
31
focus et le but de leur étude étaient différents, ils ont souligné la qualité des vendeurs /
consultants en tant que domaine clé dans la mise en œuvre de l'ERP.

Vilpola (2008) a développé une méthode d'implémentation ERP centrée sur le client pour
l'analyse des exigences du système ERP sur la base des données de recherche empirique.
L'étude est basée sur une méthodologie de recherche-action plaçant l'utilisateur au centre des
exigences processus d'ingénierie. Cette méthode a adopté des principes de conception centrés
sur l'utilisateur promouvoir la participation des utilisateurs à tous les niveaux de l’institution,
et a nécessité une approche multidisciplinaire : équipe de conception, itération des résultats de
conception et affectation des utilisateurs. La méthode a également pris en compte principes de
conception contextuelle de compte analysant le contexte institutionnel du système.

Soffer 34 et al. (2005) ont proposé une méthodologie Object-Process pour les exigences de
l’ingénierie adaptée aux besoins de l’organisation destinataire. L’étude a tenté de résoudre le
problème d’identification et d’analyse des écarts entre un système ERP et les exigences d'une
institution. L’objectif ultime était d’aligner le système sur les besoins de l’institution. Les
auteurs ont affirmé que leur méthodologie fournissait un soutien systématique à ce processus
d'alignement et de réutilisation facilitée des bases des exigences de l'entreprise.

Lea et al. (2005) ont proposé une architecture similaire centrée sur l'utilisateur pour un
prototype multi agent ERP. Ce modèle a souligné l’interaction / communication entre les
ressources humaines, agents, logiciels intelligents et les différents composants / unités de
l'information infrastructure technologique. Il était destiné à faciliter l’intégration des systèmes
d’information existants et les systèmes ERP commerciaux de manière à éviter les problèmes
liés aux mises en place des systèmes ERP.

Morton et Hu (2008) ont utilisé la théorie de contingence structurelle pour analyser la mise en
œuvre et l’adoption de l'ERP. L’étude affirmait que le succès de la mise en œuvre dépendait
de l'adéquation entre les structures de l'organisation destinataire et les processus métier
standardisés intégrés dans les systèmes ERP. Cette étude a conclu que les "structures
organisationnelles" et Les "processus métier" sont des facteurs clés de réussite de la miseen
œuvre d'ERP.

34
Soffer, P. et al., (2005). "Aligning an ERP system with enterprise requirements: An object-process
based approach." Computers in Industry 56 (2005) 639-662.
32
Construction de l’équipe du projet
Ce paragraphe décrit les différents acteurs nécessaires ou facultatifs à la réalisation d’un
projet d’implémentation d’ERP. Afin de disposer d’une équipe compétente, leurs rôles
doivent être correctement décrits et leurs responsabilités clairement définies.

1. Les intervenants internes

Tous les employés internes à l’entreprise qui se consacrent à l’implémentation de l’ERP
impliqueront une baisse du temps de travail sur les activités principales de l’entreprise. Cela
signifie qu’il faudra redistribuer le temps de travail et les tâches à exécuter, éventuellement en
engageant des collaborateurs supplémentaires.
Pour les collaborateurs qui participent au projet, il est important de leur assurer un point de
chute dès la fin du projet, qui occasionnera une motivation supplémentaire.

a. Le chef de projet:

Au-delà de son expérience de l’entreprise, de son positionnement il devra bien sûr avoir les
qualités d’un patron de projet et la maitrise des savoirs faire relatif à:
 La gestion des objectifs, à leur contrôle;
 La négociation,
 L’anticipation des risques ;
 La capacité d’expression ;
 L’analyse des situations complexes relatives à des aspects relationnels et techniques.
Son comportement lui permettra de savoir poser les problèmes, écouter, travailler en
groupe, animer, s’imposer.
Ces qualités sont vraies pour toutes les natures de projet. Dans le cadre d’un projet ERP ce
patron de projet devra avant tout être en mesure de maîtriser l’organisation de son entreprise.
Pour cela il aura besoin d’avoir un positionnement adéquat et une capacité de communication
qui lui permettront d’assurer l’articulation entre le projet et l’entreprise. Sur bien d’autres
aspects il pourra se faire aider par un intervenant externe, mais la maîtrise de l’organisation de
l’entreprise ne peut être assurée que par lui-même.

b. Les membres du comité du pilotage:

33
L’animation et donc le fonctionnement de ce comité sont en grande partie du ressort du
directeur de projet.
Ce comité de pilotage est l’endroit où il rend compte à sa hiérarchie et ses pairs, de l’état du
projet. Les membres de ce comité de pilotage ont donc une responsabilité à exercer. À partir
des informations préparées par le directeur de projet les membres de ce comité sont
responsables des réorientations nécessaires. Ils doivent donc être choisis en fonction de leur
capacité à assurer ce rôle.
La préoccupation majeure des membres de ce comité est de s’assurer que la direction de
projet maîtrise et anticipe le déroulement du projet, pour cela ils seront attentifs, en fonction
de l’avancement du projet, à ce que les facteurs de risques suivants soient bien traités.

Le comité de pilotage dirige et pilote le projet et est de composition multidisciplinaire (il

comporte un membre de la direction générale, de la direction opérationnelle et de la direction
technique). Le leadership du comité doit être confié au représentant de la direction générale,
afin de montrer une image forte aussi bien à l’interne qu’à l’externe.
Ce comité doit être structuré et organisé de manière à prendre des décisions rapides et claires.
Le nombre de membres doit être restreint (au maximum 6), et ils doivent se réunir au moins
deux fois par mois, bien que cela dépende de la durée d’implémentation. Les objectifs du
comité de pilotage sont variables : fixer les priorités, acquérir les matériels et
logiciels, décider des dates de mise en production, etc.

c. La direction :

La direction est l’élément le plus élevé hiérarchiquement dans une entreprise. Elle décide des
choix stratégiques de l’entreprise et des ressources humaines, matérielles et financières mises
à disposition afin d’atteindre son objectif. Le souhait d’implémenter un ERP devrait émaner
de la direction, mais si ce n’est pas le cas, la direction doit absolument soutenir ce projet. Si
tel n’est pas le cas, le projet semble voué à l’échec.
La direction doit participer et s’impliquer dans le projet, et bien évidemment montrer un
engagement fort aussi bien à l’interne qu’à l’externe. Il faut qu’elle saisisse l’opportunité de
l’arrivée d’un ERP, qu’elle motive ce choix par les nombreux avantages qu’il occasionnera.
Des dissidents au sein de la direction auront un poids très important et ilfaudra donc essayer
de les convaincre avant le début du projet.

34
 d. Les utilisateurs

Les utilisateurs sont les employés de l’entreprise qui utiliseront l’ERP lors de la mise
enproduction. Leur motivation et leur implication doivent être préservées tout au long du
projet, qui ne doit en aucun cas être perçu comme un moyen pour réduire les effectifs.
Généralement il y a un « responsable utilisateur », personne qui va coordonner lesactions
réalisées par les utilisateurs. Il convient d’associer les utilisateurs aux procédures de tests et de
validation des livrables, afin d’augmenter leur implication dans le projet.

e. Le bureau exécutif :

Le bureau exécutif exécute les décisions prises par le comité de pilotage et représente à la fois
l’entreprise, l’éditeur et éventuellement l’intégrateur. Il constitue le lien de communication
entre l’éditeur et l’entreprise. Il est composé de deux membres : un de l’entreprise faisant
partie du comité de pilotage et un consultant de l’intégrateur.
La personne qui représente l’intégrateur doit avoir un rôle de chef de projet et pas seulement
commercial. Il doit fournir les informations dont le comité de pilotage a besoin (conseil,
expertise, documentation, démonstration). L’intégrateur doit rendre le monde de sa société
complètement transparent à l’entreprise, et vice versa. Pour réussir un projet il est nécessaire
de bien connaître à la fois l’entreprise et à la fois l’ERP.

f. Les équipes de mise en œuvre :

Les équipes de mise en œuvre (en principe une par module du progiciel) doivent gérer le
changement à travers l’ERP. Le responsable de l’équipe doit être un spécialiste du domaine
dans l’entreprise, son rôle est d’analyser les besoins de l’entreprise et d’effectuer le lien entre
ces besoins et les caractéristiques fonctionnelles de l’ERP. Ce rôle est très important pendant
les phases de reengineering des processus.

2. Les intervenants externes

a. Intégrateur

35
Sous ce nom on désigne le plus souvent une SSII ou de conseil qui va apporter à l’entreprise
cliente son savoir-faire et ses ressources vis-à-vis du pilotage, de la construction, et de la mise
en œuvre de projet ERP.
Les grands acteurs de ce secteur ont tous des capacités pour répondre à l’ensemble des
besoins des clients du conseil stratégique en système d’information a l’engineering de mise en
œuvre. Leur couverture géographique est mondiale et ils savent constituer rapidement des
équipes de projet transnationales. Ces dernières s’appuient sur une méthodologie commune et
des best pratices capitalisé par le réseau interne de centre des compétences. Ils ont le plus
souvent des compétences sur les ERP les plus connus et sont multi secteur du marché.
Ils recherchent donc à être le « partenaire » de référence d’une entreprise et souhaitent
participer activement au pilotage du projet avec en contrepartie, un engagement de réussite.
Leur offre leur permet également d'assister l'entreprise sur les volets relatifs à la gestion du
changement.
A côté de ces quelques ténors du marché il y a beaucoup sociétés de service de taille plus
réduite mais plus spécialisées. Cette spécialisation est relative soit à la compétence et à
l'expertise sur un ERP soit à la connaissance d'un secteur de marché donné.
Le recours à la fois aux leaders du marché et à des sociétés de taille plus réduite est parfois
souhaité pour faire face à la rareté des compétences. Bien sûr dans ce cas il faut décider si la
coordination des différents intervenants externes incombe à l’entreprise cliente ou à l’un
d’entre eux qui prend alors un rôle de chef de file. Ceci se traduit alors au plan contractuel par
des contrats de sous-traitance ou de cotraitance entre deux prestataires dont l’un assure la
relation avec le client.
Enfin, il existe des accords « de reconnaissance » entre éditeurs et intégrateurs. Les éditeurs
peuvent orienter leur futur client vers telle ou telle société qui est reconnue chez eux par un
contrat de partenariat.
La plupart des grands éditeurs assurent eux-mêmes une fonction d'intégrateur pour leur ERP
en s’appuyant notamment sur leur force de consultants internes.

b. Les consultants externes

L’entreprise peut faire appel à des consultants externes afin de combler les tâches que ne
peuvent effectuer les employés internes. Ces consultants doivent être choisis sur la base de
critères tels que méthodologie, écoute et communication. On distingue trois catégories de
consultants : Techniques, fonctionnels et méthodologiques.
36
 o Les consultants techniques travaillent avec les informaticiens et les intégrateurs
dans le cadre d’équipes d’infrastructures techniques. Leur rôle est d’aider ces
derniers à intégrer l’ERP.
o Les consultants fonctionnels, eux, ont de grandes connaissances d’une
fonctionnalité de l’ERP. Ils sont experts dans le processus précis et travaillent avec
les utilisateurs dans des équipes de mise en œuvre.
o Les consultants méthodologiques apportent à l’entreprise la méthodologie
nécessaire à l’implémentation d’un ERP. Ils connaissent l’ERP en détails et savent
l’organisation qui est nécessaire à mettre en place.

L’entreprise d’intégration peut proposer ses services en matière de consulting. Ainsi, de

l’analyse des besoins à la maintenance, en pas santpar le développement spécifique, le besoin
en consultant est adaptable à l’entreprise.
Ces consultants sont spécialisés dans l’ERP, ils connaissent le langage de programmation de
l’ERP, la méthodologie à mettre en place ou tout autre paramètre qui peut être nécessaire à
l’entreprise.
Il existe également des consultants juniors qui proposent leurs services à des prix inférieurs.
Cependant, il convient de comparer les compétences de ce consultant junior avec celles d’un
consultant senior.
Certaines entreprises proposent également des modules spéciaux pour le pays d’utilisation.
Par exemple, pour le Maroc, des plans comptables helvétiques ou des interactions avec les
banques. Ce sont des modules spécifiques à l’ERP qui ont été préalablement développés par
l’entreprise d’intégration/consulting et qui sont facilement implantables dans l’ERP. Cela
permetd’éviter des développements spécifiques plus coûteux, il est donc très important de
prendre en considération cette solution.
Enfin, il est parfois possible d’essayer d’implémenter soi-même son ERP et de faire appel en
cas de besoin à une société de consulting. C’est une solution avantageuse dans le cas où
l’entreprise compte un certain nombre d’employés (pas forcément informaticiens)
disponibles.
La direction du projet peut également être déléguée à une entreprise externe, maiscette
solution est fortement déconseillée.

Les phases du projet ERP

37
La mise en place d’un ERP en entreprise se distingue par quatre phases distinctes, du cadrage
à la maintenance. Dans chacune d’entre elles, nous identifierons les principaux risques, les
éléments à ne pas oublier, les pièges à éviter et les solutions à d’éventuels problèmes.

Risques Livrables

Cadrage Non implication de la Planification du projet

direction Choix de l’ERP
Mauvais Reengineering

Processus non identifié ERP paramétré et testé

Réalisation Mauvaise entente entre les
collaborateurs et les
consultants

Déploiement Utilisateurs mal formés ERP en production

Manque de fiabilité de
l’ERP

Maintenance Découverte de nouveaux Nouveaux modules

problèmes d’utilisation Nouvelles versions
Tableau 4: Phases d'un projet ERP

1. Cadrage
Cette phase commence par un état des lieux de l’entreprise 35, il faut analyser la situation
actuelle de l’entreprise et la mettre en parallèle avec le nouvel ERP. Cet état des lieux peut se
heurter à des difficultés de confidentialité, en effet, certains processus devront être connus par
d’éventuels intégrateurs. Il est important pour l’entreprise que la direction s’investisse un
maximum dans cette phase, en définissant la stratégie à adopter et en étant clair dans les
décisions.
Les employés, futurs utilisateurs, doivent être rapidement et correctement mis au courant de la
future implémentation d’un ERP, malheureusement, cela est rarement le cas en raison des
autres nombreuses préoccupations à ce moment du projet. Il faut également les informer que
les emplois seront préservés, afin d’éviter des rumeurs de 3 restructurations.
35
Selon l’ouvrage de Claude Quélennec. QUELENNEC, CLAUDE. ERP, levier de transformation de
l’entreprise. Paris : Hermès Science, 2007 p.288
38
 a. Objectifs &Reengineering

Il est important de fixer les objectifs de l’implémentation d’un ERP au début du projet.
Le but est de justifier l’investissement de l’entreprise. Les doubles saisis, la perte de données,
et la non intégrité des divers logiciels peuvent être mis en avant.
Il y a très régulièrement une étape de reengineering dès le début du projet, bien que certains
préconisent une phase de reengineering au début de la phase de réalisation. Le reengineering
consiste en une réévaluation complète des processus de l’entreprise et en une révision des
processus jugés obsolètes ou non informatisables, et sera abordé en détail.
Les processus à étudier sont nombreux, du processus d’achat à celui des ressources humaines
en passant par le processus de comptabilité, ils doivent tous être analysés afin d’être optimisés
et adéquats avec les objectifs de l’entreprise.
Ces processus souhaités seront comparés aux processus des différents ERP et peuvent être un
critère pour le choix final de l’ERP, à savoir quel ERP se rapproche le plus de nos processus,
et occasionnera le moins de frais de développements spécifiques.

b. Etude de marché et choix de l’ERP

Parallèlement, une analyse approfondie est effectuée dans le but de déterminer le choix de
l’entreprise en matière d’éditeur d’ERP. Il faut tenir compte des ressources et des besoins,
afin de se diriger vers une solution open source ou payante, et laquelle.
C’est une étape très importante dans l’implémentation d’un ERP, car l’éditeur de l’ERP, et
éventuellement l’intégrateur, doivent être choisis à ce moment-là.
La plupart du temps, le choix de l’ERP est décidé selon des critères étonnants tels que les
choix faits par la concurrence, la réputation ou l’origine du produit.

Une bonne solution est, selon Jean-Louis Tomas36 , de dresser une liste de critères et de leur
soumettre des coefficients de pondération. Ensuite, chaque ERP est évalué sur chaque critère,
qui sont répertoriés en six catégories :

36
TOMAS, Jean-Louis. ERP et progiciels de gestion intégrés : sélection, déploiement et
utilisation opérationnelle : les bases du SCM et du CRM . Paris : Dunod, 2003. 308 p.
39
-Critères stratégiques : Ce sont les critères les plus importants. Il s’agit de choisir l’éditeur
selon des facteurs relatifs à la position de l’entreprise sur son marché (partenariats, contrats
passés avec éditeurs, etc.).
-Critères fonctionnels : Il faut comparer quel ERP couvrira le mieux tel besoin fonctionnel ou
tel autre besoin spécifique. Il faut que l’ERP s’intègre aux fonctionnalités de l’entreprise.
-Critères technologiques : C’est aux informaticiens de juger de la souplesse et de la réactivité
de la technologie proposée par les éditeurs. Le but est de ne pas se retrouver avec des
technologies désuètes dans le futur.
-Critères techniques : Il faut définir la plateforme et l’environnement technique de l’ERP,
notamment, quel système d’exploitation utiliser.
-Critères commerciaux : L’ERP sera implémenté pour de nombreuses années, il convient donc
d’assurer une pérennité avec l’éditeur. Les contrats de mises à jour, hotline et support doivent
être clarifiés.
-Critères méthodologiques : Les ERP présentent différentes façons de faire, qui contribueront
à la réussite du projet. Il faut qu’elle soit adaptée au contexte de l’entreprise.
Enfin, le comité de pilotage se doit de ne pas sur estimer les besoins de l’entreprise, en
choisissant un ERP disposant d’un trop grand nombre de fonctionnalités qui induira une sous-
utilisation de l’ERP.

c. Choix des consultants et contrats

Dans la phase de cadrage, l’entreprise doit également choisir ses équipes (technique et mise
en œuvre) ainsi que ses éventuels consultants. L’ensemble de ses fonctions sont détaillées.
Les contrats signés avec l’éditeur et l’intégrateur doivent être très précis et spécifier certains
points comme les tâches à réaliser, les conditions de réalisation, les résultats attendus et les
clauses financières et juridiques.

d. Planification

En fin de phase, le plan du projet doit être établi. C’est d’ailleurs sur ce document que se
baseront les décideurs pour l’acceptation et le lancement du projet ou non.
L’organisation des tâches, le budget, la planification des tâches, la procédure de déploiement,
la gestion des risques, les ressources, les livrables et les objectifs du projet doivent être
mentionnés.
40
 2. Réalisation
Cette phase qui comporte principalement le paramétrage de l’ERP, débute par une préparation
de l’environnement informatique 37

Les principaux éléments de cette préparation sont : Déterminer l’architecture de base de

données ERP, évaluer les besoins en matériel, déterminer la configuration des postes et fixer
les procédures de maintenance.
Besoins en matériel :
Une fois l’ERP choisit et le budget établit, toutes les technologies ne sont pas utilisables.
Avant tout, il convient de choisir si l’on opte pour un client lourd ou un client léger et si notre
architecture sera client/serveur ou sur intranet, par exemple Il faut également vérifier que nos
stations de travail conviennent à l’utilisation de l’ERP ou si l’achat de nouvelles stations est
indispensable. Le choix d’acquérir des stations d’entrée de gamme ou des machines plus
puissantes doit être argumenté. L’équipe d’infrastructures techniques est à même de définir
les besoins de l’ERP.

a. Développement spécifique et paramétrage

L’objectif est de paramétrer l’ERP dans le but d’aligner le produit sur l’entreprise. Les
membres des équipes de mise en œuvre doivent donc comprendre les processus de l’entreprise
et connaître les fonctionnalités de l’ERP. Les consultants sont présents pour apporter leurs
connaissances du produit et les collaborateurs apportent, eux, leurs connaissances de
l’entreprise. Ensemble, ils peuvent configurer l’ERP afin qu’il corresponde le mieux à
l’entreprise.
C’est à ce moment-là que l’effet d’un bon reengineering est le plus visible. En effet, c’est
dans cette phase qu’il faut identifier les processus (ou certaines parties du processus) ne
pouvant pas être configurés sur l’ERP de manière satisfaisante, idéalement il ne devrait pas y
en avoir. Ces processus sont appelés « trous fonctionnels ».

OURNANT, Laurence. AZAN, Wilfried. Réussir votre projet ERP. Saint-Denis La Plaine :
37

AFNOR, 2003. 67 p.

41
Il est également important de documenter les processus afin d’avoir une pour poursuivre la
configuration, il faut établir des prototypes, afin de valider les fonctions, la navigation, etc.
L’acceptation de ces prototypes se fait par processus. S’il est aligné avec l’ERP, ou si il doit
être modifié.
Les risques durant la période de configuration sont nombreux, du processus non
préalablement identifié à la mauvaise compréhension de l’ERP, en passant par une
incompatibilité entre les équipes de maîtrise d’œuvre et les consultants externes, il est
important de bien les anticiper.

b. Simulations

Des simulations grandeur nature (tests réels afin d’étudier la capacité de l’ERP à supporter
des scénarios opérationnels) doivent être exécutés. Un environnement de ce type est
compliqué à mettre en place, car les composants informatiques (Réseau, SGBD, OS) doivent
être prêts à être utilisés. Il faut simuler tout ce qui est un risque pour l’entreprise au moment
de la mise en production. Il est également intéressant de voir le comportement de l’ERP en
utilisation réelle, c’est-à-dire avec des volumes importants, par exemple afin de mesurer le
temps de réponse. Les autres processus peuvent être testés par de simples prototypes.
Les trous fonctionnels identifiés précédemment doivent être catégorisés, afin de déterminer
s’ils empêchent le démarrage du projet ou si, en revanche, ils ne sont pas vitaux.
Le livrable de la phase de configuration et de simulation est l’ERP confirmé en accord avec
l’entreprise par le comité de pilotage.

c. Transfert des données

Le transfert des données vers le nouveau système peut être source de conflits.
Certaines données peuvent être converties automatiquement (par programmation de scripts),
d’autres manuellement (par la saisie dans les écrans de l’ERP). Les données qui doivent être
transférées sont en tous les cas celles qui concernent les clients, les commandes et les factures.
Dans les cas où l’historique doit être conservé, il faut définir la profondeur afin de
sauvegarder le minimum requis, suivant le type de données cela peut aller jusqu’aux
obligations légales. Mais ce transfert des historiques sa un coût. Un coût que certains
fournisseurs d’outils permettant l’aide à l’automatisation ont bien cerné. Selon certains, le
coût de la conversion de données peut représenter jusqu'à 40 % du coût total du déploiement.
42
De plus, la conversion automatique peut poser des problèmes tels que erreurs d’arrondis,
mauvais formats de dates etc.
Il est nécessaire de définir des règles de conversion et de nettoyer les données avant de les
charger dans la base de données de l’ERP.

d. Formation des utilisateurs

L’implication des utilisateurs est nécessaire à la réussite du projet, c’est pourquoi il faut leur
donner un avant-goût et leur donner l’envie d’apprendre et d’utiliser l’outil. Les utilisateurs
peuvent tester tout d’abord la documentation, puis les fonctionnalités de l’ERP. Ces
expériences marquent la fin de la phase de réalisation, et si elles sont concluantes, permettent
de passer à la phase de déploiement.
La documentation utilisateur (les différents modes d’emploi et manuels d’utilisation) doit être
effectuée. Elle comprend la documentation de base de l’ERP (par modules),et la
documentation spécifique à l’entreprise.
La formation à proprement dite est effectuée en deux phases. Tout d’abord les leaders des
équipes de mise en œuvre coacheront quelques utilisateurs, qui seront considérés comme «
formateurs ». Ensuite, ces formateurs formeront les autres utilisateurs. Bien évidemment, la
pédagogie est aussi importante que la connaissance de l’ERP.
La navigation dans l’ERP, les concepts généraux des nouveaux processus de l’entreprise et
l’utilisation de l’ERP par des exercices véritables sur des données doivent être au programme
de la formation.
Enfin, des entreprises organisent des sessions de cours pour utilisateurs, ce qui peut être une
alternative intéressante.

3. Déploiement
Le déploiement doit être planifié avant le commencement du projet et doit être précédé d’une
analyse de gestion des risques, car il y a plusieurs stratégies comportant des
risques différents. L’impact financier de cette phase est très important, et est inversement
proportionnel à la prise de risque.

43
Le déploiement d’un projet ERP peut être considéré comme un projet à part entière, et
plusieurs stratégies sont envisageables, en fonction de divers facteurs comme le nombre de
sites d’une entreprise ou la taille de cette dernière.

a. Le Big Bang

L’ERP est livré dans son intégralité à l’ensemble des utilisateurs sur tous les sites de
l’entreprise. C’est une stratégie risquée (risque technique et risque business), cependant, cette
stratégie est rapide et peu onéreuse, car il n’y a pas d’interfaces temporaires. Afin qu’elle
s’annonce gagnante, cette stratégie doit être menée par une équipe support composée
d’informaticiens compétent et de consultants prêts. Dans le cadre d’une PME, il s’agit de la
meilleure solution, d’une part financièrement et d’autre part organisationnelle. C’est la
stratégie la plus répandue aux Etats-Unis, mais elle convient d’être grandement sécurisée. La
formation et le support des utilisateurs sont les critères principaux car, d’un jour à l’autre ils
seront appelés à utiliser le nouveau ERP. Des cas de panique sont également à prévoir,
comme une mauvaise compréhension des droits d’accès ou des utilisateurs qui refuse de saisir
des informations. Il y a aussi un risque de fiabilité, en fonction de l’éditeur, de la
configuration et des développements spécifiques effectués, certains bugs peuvent apparaître.
Certaines mesures peuvent être prises, comme accroître l’effectif du support pendant la
période de démarrage, apporter son soutien et une formation aux utilisateurs, mais également:

• Prévoir un plan de retour en arrière en cas de catastrophe lors des premiers jours.
• Limiter les changements pendant la phase de démarrage tels que les déménagements de
bureaux ou les changements de fonctions.
• Définir certaines conditions particulières : Saisir un nombre limité de transactions ou ne pas
utiliser certaines fonctionnalités.

Il est également important de prévenir les clients et les fournisseurs entre un et deux mois à
l’avance38, car les formulaires et les procédures subissent un changement.

b. Le déploiement vertical

QUELENNEC, CLAUDE. ERP, levier de transformation de l’entreprise. Paris :

38

HermèsScience, 2007. 288 p.

44
Il consiste à implémenter toutes les fonctionnalités de l’ERP sur un seul site. Ensuite, après
stabilisation, toutes les fonctionnalités sont implémentées sur un autre site. Bien évidemment,
le prérequis est que l’entreprise soit multi sites. Cette stratégie donne une première
stabilisation sur le site pilote, mais il est important que ce site soit accessible, que les
collaborateurs présents sur ce site soient compétents et motivés et que les risques soient
minimes. Cela donne une rapidité pour démontrer une première réussite de l’ERP. Cette
stratégie est la stratégie la plus répandue en France.

c. Le déploiement horizontal

Il consiste en une implémentation d’une fonctionnalité de l’ERP sur tous les sites de
l’entreprise. Ensuite, après stabilisation, une autre fonctionnalité est implémentée sur tous les
sites. Cette stratégie minimise le plus possible les risques et est très intéressante dans le cas où
le Big Bang n’est pas acceptable et qu’il n’est pas possible de trouver un site pilote.
Néanmoins, les problèmes d’intégration des modules et le grand nombre d’interfaces
temporaires demandent un effort important.

d. Le déploiement mixte horizontal/vertical

Le déploiement mixte combine les deux stratégies précédentes. La réussite tient en une bonne
identification des étapes stables dans le déploiement horizontal, ce qui permet d’allonger le
test aux autres sites. Cette stratégie onéreuse et complexe est principalement dédiée aux
grandes entreprises.

e. Support et Maintenance

La mise en production achevée, le projet d’implémentation de l’ERP est terminé.

Cependant, il ne faut pas négliger la suite, à savoir les prochains défis, le retour sur
investissement, sans oublier les problèmes à solutionner.
Les bénéfices à espérer sont de deux types : tangibles et intangibles.
Les bénéfices tangibles :
• Réduction des coûts (informatique, RH, approvisionnement)
• Réduction d’inventaire
• Amélioration de la productivité

45
Les bénéfices intangibles :
• Visibilité améliorée de l‘information
• Nouveaux processus informatisés
• Processus améliorés
• Standardisation
Il faut surveiller attentivement les jours qui suivent le démarrage en organisant deux niveaux
de support (entreprise et éditeur).
Dès qu’une anomalie est détectée par l’utilisateur, il en informe le leader de l’équipe de mise
en œuvre correspondante ou l’équipe technique, ensemble, ils essayent de trouver une
solution. Si rien n’est trouvé, il faut faire appel au support chez l’éditeur.
Attention, ce ne sont jamais les utilisateurs qui sont en contact avec l’éditeur. En cas de non
résolution, le comité de pilotage va devoir décider des choses à faire, à savoir envisager une
modification de la procédure opérationnelle ou ne rien faire si cela n’est pas vital. En solution
de recours, l’entreprise peut demander une ressource technique à l’éditeur/intégrateur, cela
nécessite bien sûr un coût important.
Avec l’ajout et la mise à jour de nouvelles fonctionnalités, l’équipe d’infrastructures
techniques doit rester entière. Le support de l’ERP peut se faire de manière externe, mais le
coût et la compréhension des besoins de l’entreprise ne seront peut-être pas au rendez-vous.
En revanche, il n’y aura pas besoin de former ses informaticiens internes.

f. Mises à jour :

Il faut prêter attention aux nouvelles versions qui peuvent coûter beaucoup. Il faut compter un
changement de version tous les 2 ou 3 ans, et être sûr que cette nouvelle version apporte
quelque chose (interface Internet, nouvelle technologie, nouvelle fonction) afin de ne pas
l’installer inutilement.
Enfin, les nouveaux modules ne posent pas de problèmes. Toutefois, il ne faut pas céder à la
tentation s’ils ne s’avèrent pas utiles à l’entreprise. C’est au comité de pilotage que revient la
décision d’installer une fonction supplémentaire ou non

Section 2: le bon choix de l’intégrateur : un maillon central pour le succès

du projet ERP

46
La section précédente a montré la difficulté des projets ERP notamment en matière des
ressources humaines et aussi la difficulté de gérer ce genre des projets compliqués. Pour faire
face à cette difficulté l’appel à un intégrateur demeure nécessaire surtout pour les entreprises
qui ne disposent pas des ressources nécessaires par exemple l’absence d’un département
informatique ou de système d’information. La présente section analyse le rôle de l’intégrateur
comme un principal facteur clé de succès surtout pour les clients qui délèguent toutes les
activités de projet pour leurs clients et se limite à valider réalisation de son prestataire.

I. L’intégrateur : définition, rôle et équipe

L’intégrateur est l’entité de conseil et d’expertise chargée de l’intégration d’outils édités par
des tiers dans le système d’information d’une entreprise cliente. Il a un rôle de facilitateur
entre l’éditeur et le client, les utilisateurs.

L’intégration repose sur une relation de confiance entre l’intégrateur et l’entreprise qu’il
accompagne. L’accompagnement se fait tout au long du cycle de vie produit : de l’audit à la
mise en œuvre d’outils et de processus, jusqu’au paramétrage et à la maintenance applicative.

Un intégrateur ERPest souvent une Société de Service en Ingénierie Informatique, SSII,peut

être :
 Éditrice d’une solution logicielle ERP,
 Partenaire d’un éditeur de logiciels ERP,
 Et, ou spécialiste d’un ERP openSource

Pour le déploiement d’une solution, il faut faire appel à un intégrateur ERP qui, après analyse
de vos besoins et de vos processus, va vous accompagner :
 dans le choix de l’ERP et dans la présentation approfondie du progiciel retenu,
 dans l’installation et la personnalisation du logiciel,
 et pour son intégration avec les autres briques de votre système d’information.

C’est pourquoi il est nécessaire de le choisir avec soin. La bonne utilisation du logiciel
dépend des compétences de l’intégrateur, de ses consultants ERP et de sa capacité à
proposer des consultants aux autres compétences qui pourront vous conseiller dans votre
évolution numérique.

47
Vous devez vous renseigner au préalable sur sa réputation, les valeurs de son entreprise, le
niveau d’expertise de ses consultants et son champ d’action par rapport aux enjeux du
numérique.

Les consultants de l’intégrateur possèdent des compétences très importante pour répondre aux
attentes des clients.

Différents profils de consultants ERP peuvent intervenir sur un projet, souvent un même
consultant peut avoir plusieurs casquettes :

Les consultants ERP fonctionnels :

● Travaillent en appui de la MOA (maîtrise d'Ouvrage) sous forme d’assistance à la

maîtrise d’ouvrage, appelée AMOA,
● Élaborent et rédigent le cahier des charges fonctionnel ou dossier de conception
détaillée en collaboration avec la MOA (Maîtrise d’Ouvrage),
● Valident le cahier des charges technique, s’assurent qu’il répond bien au besoin
fonctionnel exprimé dans le cahier des charges fonctionnel,
● Préparent les plannings, les jeux de tests,
● Effectuent les tests et assurent leur suivi,
● Rédigent éventuellement des fiches d’incident à destination des consultants
techniques, s’ils ne corrigent pas eux-mêmes les paramétrages,
● Valident la recette quand toutes les corrections sont apportées aux paramétrages et les
nouveaux tests réussis,
● Rédigent les PV (procès-verbal) de recette qui attestent la validation de la recette
fonctionnelle,
● Assurent le suivi lors de la mise en production,
● Interviennent en support post-production pour aider son client à vivre sereinement
cette phase délicate.

Les consultants ERP techniques :

● Sont chargés des développements spécifiques et des paramétrages,

● Rédigent aussi les dossiers pour documenter leur travail.

48
 II. Le bon choix intégrateur un maillon central pour une mise en place réussie et
qualifiée d’un PGI
Souvent considéré comme moins important que le choix de l’ERP, le choix de l’intégrateur se
fait souvent par défaut. Il s’agit là d’une erreur puisque des compétences de votre intégrateur
dépendront la bonne utilisation de votre solution de gestion. Véritable partenaire, votre
intégrateur vous accompagnera tout au long de votre projet d’installation d’ERP.

Le choix d’un bon intégrateur ERP est donc aussi indispensable que le choix du logiciel lui-
même ! En effet, la méthodologie de déploiement sera essentielle pour la réussite du projet et
l’expérience de l’intégrateur sera déterminante. Voici donc les principales qualités àidentifier:

● Sa capacité d’analyse et de compréhension de vos besoins et de vos processus de

gestion au regard d’expériences similaires des consultants ERP,
● Son expertise technique et applicative attestant de sa maîtrise de l’ERP pour être
sûr que vous ayez les meilleurs conseils en termes de paramétrages,
● Sa méthodologie de déploiement basée sur des expériences concrètes réussies,

Mais surtout, c’est en adoptant une vision à long terme, que l’on comprend que le choix de
l’intégrateur est vital. Lorsqu’on s’équipe d’un ERP ou d’un PGI, on le garde pour 7, 8 ou 10
ans, voire même plus ! Avec la révolution digitale et les stratégies de croissance, la solution
retenue devra constamment évoluer au fil des ans, si le partenaire ERP choisi reste présent
dans le temps et peut faire bénéficier de ses conseils et de son expertise pour modifier les
paramétrages, c’est encore mieux…

Ce n’est pas tout de choisir la solution adaptée à vos besoins, encore faut-il s’assurer que son
déploiement se fera dans les meilleures conditions. C’est là que le partenaire intégrateur entre
en jeu. Bien choisir son partenaire intégrateur, c’est garantir un déploiement optimal.Afin
d’être sûr d’un accompagnement optimal, la priorité doit être donnée à la proximité
Géographique, “Culturelle” : l’intégrateur connaît-il votre métier ? Votre secteur ? Quel est
son savoir-faire ? Humaine : il est impératif que des relations de confiance soient très tôt
établies, Avec l’ERP qui va être déployé : quelle est l’expérience de l’intégrateur sur ce
progiciel en particulier ? Quel est son degré de compétence, quelles sont ses facultés de
paramétrages et de développements spécifiques ? De même, assurez-vous que l’architecture

49
technique proposée est adaptée, ce qui conditionnera directement les temps de réponse de
votre système.

Pour se rendre compte à la fois de la performance de l’outil et du professionnalisme de

l’intégrateur, qu’une visite sur le site de l’un de ses clients ayant opté pour l’ERP que vous
avez choisi. Ce sera l’occasion pour vous d’échanger avec les utilisateurs et la Direction, et
d’entrer dans le vif du sujet en voyant véritablement vivre le progiciel dans un environnement
équivalent au vôtre.
Réussir la mise en place repose donc surun intégrateur capable de fournir toutes les ressources
nécessaires avec une démarche bien structuré.

On peut faire appel au célèbre exemple du projet ERP de la société FoxMeyer qui l’a couté 60
million de dollards, FoxMeyer s’attendait à ce que le projet Delta économise 40 millions de
dollars par an. Andersen Consulting et SAP ont également été mobilisés pour poursuivre le
projet. Selon FoxMeyer, Andersen a utilisé des stagiaires (1998) et utilisé le projet Delta
comme un "terrain de formation" pour des "consultants très inexpérimentés" (Computergram
International, 1998). De même, FoxMeyer a affirmé que SAP le traitait comme "son propre
cobaye de recherche et de développement" (Financial Times 1998). De plus, les échecs du
projet semblaient temporaires. Par exemple, certaines données de mesure indiquaient que ces
systèmes pouvaient fonctionner au volume de transactions requis par FoxMeyer.

Conclusion :
En conclusion la mise en place d’un ERP est un projet qui nécessite la combinaison d’un
nombre de ressources diversifiés, l’organisation d’un tel projet est indispensable afin de faire
face à la complexité visée par ces genres des projets. Cependant faire appel à un intégrateur se
voit obligatoire, vu son expérimenté dans le domaine le degré du risque d’échec se diminue, la
réussite de projet dépond donc de l’intégrateur c’est pour cela que ce choix doit être fait
soigneusement, Le bon choix de l’intégrateur est un maillon central pour la réussite d’un
projet ERP. On s’interroge maintenant de la manière et la démarche selon laquelle ces projets
sont gérés, c’est l’objet du troisième chapitre qui va étudier un cas réel d’une mise en place
d’un ERP auquel j’ai participé personnellement durant ma durée de stage au sein d’un
intégrateur certifié ISO.

50
 Chapitre 3 : étude de cas de mise en place d’un ERP au
sein de KARIZMA CONSEIL

Introduction
Après avoir analysé le fonctionnement de la mise en place des ERP comme des projets
nécessitant de l’organisation et de la collaboration de différents profiles des ressources
humaines, le présent chapitre expose un cas concret d’un projet ERP auquel j’ai intervenu
durant ma période du stage au sein de l’intégrateur des solutions informatiques KARIZMA
CONSEIL, tout d’abord on va présenter dans une première section cet organisme, avant de
présenter dans une deuxième section l’étude de cas du projet en question.

Section 1 : L’organisme d’accueil

 Historique, activités et objectifs
Fondée en 2013, mais véritablement lancée en 2014, KARIZMA Conseil est un prestataire de
services spécialisé dans la mise en œuvre des solutions ERP, CRM, BI, e-commerce et
Messagerie. Plus de 7 ans d’expérience dans l’intégration de la solution Odoo (OpenERP), ses
consultants combinent expertise technologique, applicative et métier, afin d’apporter un
conseil éclairé tout au long d’un projet ERP.

KARIZMA Conseil occupe aujourd’hui la première place en matière d’intégration de solution

Odoo au Maroc et même dans toute l’Afrique ; partenaire GOLD et certifié de Odoo ; elle est
au centre du métier de consulting de d’intégration Odoo avec une filiale en France. Cela est
dû avant tout à son équipe de consultants dévoués et professionnels qui allient efficacité et
abnégation.

Ils interviennent sur plusieurs secteurs d’activité : distribution, vente, industrie, services,
transport, associations et gestion de la chaîne logistique (SCM) avec une forte expertise sur
les spécificités comptables pour le marché marocain et africain en général (Gestion de la paie,
édition des états fiscaux et télé déclarations, Gestion de le TVA, Gestion des appels d’offres
...)

51
KARIZMA Conseil offre une large palette de prestations et de services basés sur des
composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de
cette société est de livrer à ses clients des solutions simples, efficaces et performantes, qui leur
permettent d’atteindre leurs objectifs et d’obtenir un avantage compétitif. La gamme de
services de KARIZMA est articulée autour de huit axes majeurs qui permettent
d’accompagner les clients durant toutes les phases d’un projet afin d’en assurer sa réussite en:

● Formations techniques et fonctionnelles.

● Consultation et études techniques et fonctionnelles.
● Installation, Configuration, et migrations de données.
● Développement d’applications ou modules spécifiques.
● Synchronisation et interfaçage avec d’autres systèmes de gestion.
● Hébergement Saas ou dédié à haute disponibilité.
● Support technique et fonctionnel.
● Maintenance corrective et évolutive.
Bien que le secteur d’activité principal de KARIZMA Conseil soit Odoo, cela n’empêche pas
la société d’intervenir dans de nombreux autres domaines comme le développement
spécifique, organisation d’évènements, ou encore la maintenance informatique.

Figure 6: Logo de Karizma Conseil

Produits et clients
1. Les produits

KARIZMA Conseil offre une large panoplie de produits dans le service numérique, avec pour
produit phare, l’intégration de Odoo pour des entreprises de toutes taille. Parmi les autres
produits de KARIZMA Conseil, on peut citer

52
 o Todoo : solution SaaS idéale pour les PME/TPE du secteur des services,
Négoce, Restauration, Magasin, Bureaux d'études ......

o SpagoBI : qui est une solution de Business Intelligence entièrement open

source. Faisant partie de l'initiative libre/open source SpagoWorld1, fondée et
soutenue par Engineering Group2. SpagoBI est distribué sous licence Mozilla
Public License, qui est compatible avec les usages commerciaux.

o Jaspersoft est l'outil décisionnel le plus utilisé dans le cadre professionnel

grâce à son architecture flexible et sa gamme de fonctionnalités complètes de
reporting, tableaux de bord, requêtes et rapports ad-hoc, analyse OLAP ou
encore intégration de données

2. Les clients

Le dynamisme et le sérieux de la société lui ont fait valoir la place de numéro 1 en intégration
Odoo dans le maghreb et dans toute l’Afrique, cette place se traduit un nombre
impressionnant de clients :

Plus de 50 clients issus de 10 secteurs d’activités différents, dont on peut citer :

● Des écoles : HESTIM, EMSI

● Des professionnels du marbres : Bougstone, BUROPA

● Des cabinets : MEDEXEL, SAHAM

Organisation hiérarchique
KARIZMA Conseil est une jeune équipe composée des consultants technico-fonctionnels. Le
découpage hiérarchique est fait comme suit :

● Un directeur associé
● Deux chefs de projets et consultants associés,
● Un team leader et consultant sénior
● Des consultants technico-fonctionnels.
● Une assistante de direction et deux account manager

53
Le déroulement de notre projet c’est fait au sein de cette équipe polyvalente.

Directeur
Associé

Chef de Account Chef Assisante

projet manager marketing de direction

Consultants Consultants Consultants

sénior fonctionnel techniques
s

Tableau 5: la hiérarchie de la société Karizma conseil

Section 2 : Présentation du projet

Le présent projet est un projet en faveur de l’un des clients de Karizma conseil, donc cette
dernière est le maître d’œuvre tant que l’entreprise cliente est le maître d’ouvrage. L’objet de
cette section est de présenter le projet en passant par toutes ses étapes.

 La phase du cadrage
La société ABC est une société qui commercialise dans le domaine de l'électroménager, elle
dispose également d’une équipe helpdesk et SAV qui intervient sur le terrain pour
l’installation et le support sur site, ce genre d’activité présente plusieurs problèmes de gestion
surtout en ce qui concerne la gestion des employés sur le terrain, quel employé doit être se
déplacer au tel ou tel client? quels sont les exigences pour son intervention? sont-ils
disponibles ou non...?

Dans une démarche qualité la société décide de faire une consultation en vue d’acquérir un
système de gestion intégré.

le système doit être capable de couvrir toutes les fonctions de son domaine d’activité.

le système d’information intégré doit notamment:

54
 ➔ simplifier la circulation des flux d’information entre les différents utilisateurs du
système
➔ garantir la sécurité des données
➔ garantir l’unicité de l’information
➔ être adaptée également aux processus métier de la présente société

Figure 7: cartographie des processus de la société

Le périmètre du système

Le système d’information doit couvrir les domaines d’activités suivants:

➢ la gestion des ventes

➢ la gestion des achats
➢ la gestion du stock
➢ helpdesk
➢ la gestion des services sur sites (field services)
➢ la gestion des contrats

Description fonctionnelle des besoins

1. le module de vente
Le module vente doit permettre de
55
 ● créer des devis avec la possibilité de personnaliser ceux-ci
● transformer les devis en bons de commande au cas de validation
● gérer la facturation depuis le bon de commande
● Donner des remises sur n'importe quel élément d'un devis
● Obtenir un résumé complet de toutes les activités de vente
● Contrôler facilement un tableau de bord pour des informations importantes telles que
le montant total facturé, les ventes par région / vendeur …

2. le module achat
Le module achat doit permettre de

● Lancer des appels d'offres, intégrez les réponses des fournisseurs dans le processus et
comparez les propositions.
● Gagner du temps en établissant des règles automatisées visant à envoyer des demandes
de prix aux fournisseurs, en fonction du niveau de vos stocks.
● Définir les prix de vente, les codes-barres et les références, afin de distinguer
facilement les produits similaires les uns des autres.

3. le module de facturation
le module de facturation doit permettre de :

● générer automatiquement les factures des ventes

● créer des nouvelles factures client et fournisseur
● gérer les remboursements et les paiements
● suivre l’état des factures

4. le module inventaire
Le module inventaire doit permettre

● une gestion moderne de l'inventaire avec une double entrée de stock

● via un mobile de Scanner les produits dans l’entrepôt à l'aide du lecteur de barres-
codes, Contrôler vos tableaux de bord et suivre les commandes où que vous soyez.
● de faire un inventaire pour une zone, un produit spécifique, un lot ou une palette/boîte
● d’emballer les produits en un clic et d’attribuer des codes-barres aux packs pour un
suivi facile des commandes.
● Mettre certains produits au rebut en quelques clics
● de définir des règles de réapprovisionnement

5. Field services (la gestion des employés sur le terrain)

56
C’est le noyau du système puisque tous les autres modules s’entoure de celui-ci, le client a
montré l’intéressante de ce module pour son activité,

Les principaux composants d’un FSM comprennent:

Le module du field services doit permettre de

● Affectation des ressources , manuellement ou automatiquement (optimisation).

● Planification des ordres, livraisons et travaux de maintenance
● Planification et achat de pièces et d'équipements
● Activation des tiers entrepreneurs

● préparer les ordres d’intervention sur sites

● préparer les outils et les articles nécessaires pour l’intervention et vérifier leurs
disponibilités dans le stock
● gérer les employés sur le terrain en déterminant les localisations ciblées
● afficher l’état des différents ordres.
● Communication client
● Communication bidirectionnelle des ordres de travail et de livraison entre le
répartiteur et l’employé sur le terrain
● Mises à jour en temps réel via des appareils mobiles
● Analyse / Reporting et Opérations
● Pièces et équipements utilisés
● Gestion des opérations (maintenance des équipements, gestion de la flotte,

6. Assistance
Ce module doit permettre de :

 créer et suivre les tickets de support

 Créez des tickets de support par e-mail
● créer des ordres d’intervention sur le terrain à partir des tickets
● donner l’accès aux clients pour créer des tickets

57
Organisation et gestion du projet
Pour bien organiser un projet, le choix d’une méthode de gestion est primordial. Différents
outils permettant la gestion d’un tel projet, dans ce projet on va utiliser le planning de
GANTT avec la méthodologie agile SCRUM.

1. La méthode agile SCRUM pour la gestion des projets SI

Inspirée de la gestion des projets informatiques, la méthode SCRUM est devenue de nos jours
de plus en plus adoptée dans les équipes de développement. Cette méthode "agile" permet la
réalisation de projets complexes en favorisant l’interaction avec les membres de l’équipe et
les managers, la collaboration du client et la réactivité face aux changements.

Les projets qui suivent la méthode agile SCRUM sont divisés en plusieurs cycles de travail
relativement courts que l’on appelle « sprints ».

Ces derniers permettent aux membres de l’équipe de mieux planifier les prochaines étapes de
développement du projet mais aussi d’évaluer régulièrement les progrès liés au projet. Les
sprints peuvent durer d’une à quatre semaines. Ils permettent également de réajuster ou
réorienter la direction prise par le projet si besoin.

Figure 8: La méthode SCRUM

Il existe trois rôles principaux à « pourvoir » : le responsable produit, le SCRUM Master, et

les membres de l’équipe.

•Le responsable produit : Ce dernier définit les spécifications fonctionnelles et communique

la vision globale du produit à l’équipe. Il établit la priorité des fonctionnalités à développer ou
58
à corriger et valider les fonctionnalités développées. Il se doit de jouer le rôle client final, se
mettre à sa place et donc de prioriser ses besoins. Celui qui tient ce rôle est celui qui a le plus
de responsabilités et d’autorité. Le responsable (produit) est en effet celui qui est en première
ligne lorsque quelque chose se passe mal ; ce qui nécessite de trouver le juste équilibre entre
autorité – responsabilité et engagement.

•Le SCRUM Master : Ce dernier agit en tant que facilitateur entre le responsable produit et
l’équipe. Son rôle principal est d’éliminer tous les obstacles qui peuvent empêcher l’équipe
d’atteindre les objectifs fixés pour chaque sprint de travail. Il s’assure que les principes et les
valeurs Scrum sont respectés. Il facilite la communication au sein de l’équipe et cherche à
améliorer la productivité et le savoir-faire de son équipe. Le Scrum Master conseille aussi le
responsable produit sur la façon de maximiser le Return On Investment général de l’équipe.
•Les Membres de l’équipe : Dans la méthode SCRUM, l’équipe est responsable de la
réalisation opérationnelle des tâches. L’équipe est d’ailleurs généralement composée de 6 à 10
personnes mais pouvant aller jusqu'à 200 personnes. C’est toute l’équipe qui est responsable
du résultat final de chaque sprint. La manière dont sont exécutées les tâches est très libre mais
cette liberté doit être néanmoins cadrée par l’obligation de répondre aux objectifs du sprint
(2).

Pour le cas de ce projet :

o Le Product Owner comme défini ci-dessus (cf. Figure 4) est la MOA ou le

client,
o L’équipe de développement est composée d’un responsable fonctionnel
(Moi) qui assure que le produit réponde aux besoins exprimés par le client,
et un responsable technique charger de réaliser et développer les
spécifications.
o Le Scrum Master a pour rôle de suivre la procédure, assurer le suivi de la
méthode et la supervision globale du projet. Dans le cas de notre projet, ce
rôle est assuré par le chef de projet qui est l’encadrant interne au sein de
KARIZMA Conseil (M. Saad THAIFA FATHI).

2. Équipe du projet:
Avant de présenter la manière de gestion du projet, il faut d’abord s’intéresser à son
organisation. Pour ce, le tableau suivant présente les rôles des membres de l’équipe qui a
participé à la réalisation de ce projet :

59
 Nom Rôle

MOE Saad Thaifa Fathi Chef de projet MOE

OUAHI El arbi Consultant fonctionnel

OUZZAOUIYT Ilyas Consultant technique

MOA Chef de projet MOA

Membres de comité de pilotage

3. Planification du projet:
La planification a pour objectif d'organiser le déroulement des étapes du projet dans le temps.
Une tâche fondamentale pour la maîtrise des délais.

Généralement pour planifier un projet, la première phase consiste à le découper en plusieurs

étapes (identification de l'ensemble des tâches à réaliser), d'en estimer la durée, d'identifier
l'enchaînement des étapes, affecter des ressources, et enfin modéliser cette organisation sur un
document opérationnel partagé entre tous les acteurs concernés pour optimiser le déroulement
et le suivi de la réalisation.

60
61
 Figure 9: planification et diagramme de GANTT du projet

Étude de l’existant

Une réunion avec le client a démontré que la gestion de ses différentes activités se fait à l’aide
des différents systèmes non intégré et non performant de fait qu’ils ne permettent pas une
gestion complète de ses processus métiers.

Pour la facturation le client utilise une version très ancienne et illégal (cracké) de SAGE, ce
qui présente beaucoup des points négatifs :

La non intégration avec l’inventaire et les achats.

Enregistrement limité des donnés limitées

Pour le Helpdesk et la gestion des interventions sur le terrain le client utilise Excel pour
planifier ces dernières, ici il s’agit d’une planification incomplète ce qui engendre un grand
besoin en matière de planification des ordres d’intervention car ce genre de métier nécessite
une gestion exceptionnelle nécessitant un système performant capable de répondre à tous les
besoins des intervenants dans ce métier à savoir le planificateur qui planifie, affecte et assure
le bon déroulement les ordres d’interventions; les techniciens ou les ouvriers du terrain qui
sont chargés de l'exécution des ordres d’intervention sur le terrain. Ces derniers doivent avoir

62
l'accès à un système capable de les fournir à toutes les informations dont elles sont besoin
pour leur exécution, il s’agit notamment de savoir les différents emplacements concernés par
l’intervention, l’utilisation du maps et le remplissage des informations nécessaires...

Pour la gestion des contrats avec ses clients, le client utilise le word pour taper ses derniers ce
qui pose une réinsertion des données à tout moment, et les factures associées à un contrat sont
placés dans un même dossier, ici le client a exprimé un besoin vis à vis de cette situation,
puisque les interventions sont généralement associées à des contrats et même les ventes aussi,
d’où la nécessité d’intégrer un tel module des contrats aux ventes et au module de gestion des
services sur sites.

Le logiciel Excel apparaît aussi au niveau de la gestion d’inventaire ce qui pose une gestion
du stock manuel et non performant puisque l’agent chargé de le gérer peut oublier
d’enregistrer quelques opérations ce qui engendre un résultat loin de réalité. Le stock a besoin
d’être associé avec les ventes, les achats et toutes les autres activités de la société concernée.

Benchmark et choix de la solution Odoo

L’étude de besoin du client a montré une problématique nécessitant un ensemble
d’application, le besoin d’intégration est une exigence primordiale, les applications isolés non
intégrés sont donc à exclu. L’analyse benchmark est restreint donc en jetons l’œil sur les
progiciels de gestion intégré, dans une telle PME les coûts d’investissement élevés révèle
impossible de les réaliser, dans ce cas les géants des ERP à savoir SAP, ORACLE… sont
considéré comme des projets non faisable vu l’incapacité de financer un tel projet.

63
 Figure 10: La solution Odoo entre autres

Nos recherches nous ont permis de trouver une large gamme de solutions susceptibles de
répondre aux problématiques du client, mais nous avons opté pour la solution Odoo.
Plusieurs critères justifient le choix de cette solution :

o Les modules d’achats et de ventes de Odoo correspondent idéalement aux

besoins exprimés par le client, les autres modules nécessitent d’ajouter et de
développer certaines spécifications.

o Cout amoindri pour le client : Odoo est open source et ses licences ont des
couts réduits

o Une facilité de paramétrage : Odoo est un sous licence GPL qui permet d’en
éditer le code contrairement aux solutions payantes ou propriétaires

o Une expérience d’utilisation unique et son développement orienté business en

font l’un des leaders du monde des achats en matière d’ERP Open source

o Une large communauté de développeur qui facilite la maintenance et les mis à

jour de la solution.

Conception et modélisation des spécificités

64
Après avoir validé avec le client la partie préliminaire du projet et le cadrage du projet à
savoir le choix de la solution qui est adaptable aux besoins du client on a passé à l’étape de
conception : il s’agit notamment de modéliser les processus métiers de la société cliente sous
forme des BPMN, le diagramme de use case, et le diagramme des classes.

1. La modélisation des processus métier

Dans cette partie on va présenter la modélisation des processus pour la vente, le helpdesk et le
field service sous formes des BPMN

a. Le processus vente :

Figure : le processus de vente de la société

65
 b. Le processus d’achat :

Figure : le processus d’achat

c. Le processus du Field services

66
 2. Le diagramme de use case
Ce diagramme modélise les acteurs du système et leurs cas d’utilisation

67
 3. Diagramme des classes
Le diagramme des classes représente la manière selon laquelle les données du système
seront structurées : on présentera le diagramme de classe du module Field service

68
69
La phase de réalisation
Dans cette phase le système a été paramétré selon le besoin du client. Le paramétrage ne
suffisais pas des développements spécifiques ont été réalisé par le responsable technique cela
a concerné l’ajout des nouveaux champs et aussi l’intégration de certains champs avec
d’autre. Cette phase était marquée également par des différents tests fonctionnels pour
s’assurer du fonctionnement des spécifications ajoutés par l’équipe technique.

70
Objectif les modules affectés : Fonctionnalités demandées

intégrer les ventes aux  module ventes l'ajout d'une nouvel select

Contrats "Agreement" dans la création

des devis dont la fonctionnalité
est la sélection d'un contrat
auquel sera associé le devis.

 le module Agreement l'ajout d’une barre dans le

contrat permettant d’afficher les
ventes associées à ce contrat

se baser sur un modèle de le module Contrats ajouter une sélection des

contrat pour créer un modèles de contrats dans la

création des contrats lors du
nouveau contrat
choix d’un modèle de contrat
les autres champs seront
remplis automatiquement par
les données du modèle choisi.

problème technique lors de la le module Contrats illustration: lors de l’impression

création d’un contrat sur la d’un contrat généré à partir d’un
base d’un modèle modèle les clauses ne sont pas
affichées, alors qu’elles sont
dupliquées au niveau de
l’impression du modèle

Après la validation du résultat du projet le système a été installé sur le Cloud par option du
client des formations des utilisateurs ont été élaboré sur le site du client. L’accompagnement
de client est exigé pour gérer le changement organisationnel engendré par la mise en place
d’un tel système avec l’assurance de la maintenance du système sous les clauses du contrat
conclut entre les deux parties du projet.

71
 Figure 11: l'interface Odoo: le résultat du projet

Conclusion
Cette étude de cas a été le fruit de 5 mois du stage au sein de la société Karizma conseil, la
participation à un tel projet a été très bénéfique, une expérience riche en matière de la gestion
des projets SI, l’objectif était d’analyser le fonctionnement des projets ERP au sein d’un tel
intégrateur certifié ISO et partenaire Gold de l’éditeur Odoo leader des ERP OpenSource.
Le client a montré son avis à propos de sa relation avec Karizma conseil et le déroulement du
projet, « le succès de ce projet est dû de plusieurs facteurs d’abord le choix du la solution
Odoo était parfait vu sa simplicité d’utilisation, sa flexibilité, son coût réduit mais aussi le
choix d’un intégrateur spécialisé dans Odoo et certifié ISO était plus que parfait c’est la base
du succès du projet puisque l’intégrateur a assuré le bon déroulement du projet en respectant
ses différents engagements à savoir le respect des délais de livraison et en apportant une
démarche basée sur l’intégration du client dans toutes les étapes du projet, et par conséquent
le résultat correspond parfaitement aux attentes. » affirme-t-il le responsable SI du la société
bénéficiare du projet. Le choix donc de l’intégrateur par ce client n’était pas fait au hasard
mais en s’assurant des références et de l’expérience de l’intégrateur.

72
 Conclusion générale
Le présent mémoire a été l’occasion d'approfondir les connaissances sur les ERP, et sur le rôle
des intégrateurs dans leur mise en œuvre. Dans le premier chapitre, nous avons abordé les
ERP leur histoire et leur évolution avec quelques théories appliquées à ceux-ci. Ainsi
plusieurs théories et modèles ont focalisé sur ce genre des systèmes et cherchant à analyser le
fonctionnement de ceux-ci.

Le deuxième chapitre a pour but d’analyser le projet ERP, son management, ses prérequis et
des méthodes et bonnes pratiques pour le choix de l'éditeur et l'implémentation de la solution
dans le but de mettre en relief la taille et la complexité de ce type de projet. Des théories en
relation avec la mise en place de ces systèmes ont été abordé, certaine ont met l’accent sur
l’importance de la relation entre l’intégrateur est son client, d’autre ont met l’accent sur
l’importance de l’inginiering des processus de l’entreprise... Le projet de mise en place d'un
ERP est le projet le plus fréquent et le plus couteux. Malgré les risques encourus, les
entreprises se lancent dans ce projet dans le but de survivre, gagner en productivité, en délais
et prospérer dans un marché souvent dynamique et concurrentiel. Ces projets connaissent plus
d'échecs que de succès et c'est dans ce cadre que nous avions mené cette recherche pour
étudier l'impact du bon choix de l’intégrateur sur le succès des projets ERP.
Ce constat se vérifie. Le rôle de l’intégrateur ne se limite pas à accompagner les utilisateurs
dans le déploiement et la personnalisation. L’intégrateur est un partenaire incontournable dans
la mise en place de la solution, un interlocuteur clé avec qui les entreprises ont bien plus
qu’une relation professionnelle classique. C’est avec lui qu’elles collaborent dans le
déploiement de l’ERP afin de délivrer une prestation de qualité. Un travail d’équipe, une vraie
synergie indispensable pour avoir de bons résultats. Une complémentarité technique possible
avec des intervenants possédant des connaissances des technologies requises.

Finalement une étude de cas a montré le fonctionnement et la démarche de ce genre des

projets au sein des intégrateurs, spécifiquement chez Karizma conseil qui est un intégrateur
certifié ISO et partenaire Gold de l’éditeur Odoo. Cette étude de cas était selon le client
bénéficiaire un cas concret d’un projet PGI dont l’intégrateur est à la base de son succès. A
cet égard on peut présenter des recommandations pour les entreprises désirantes
d’implémenter un ERP : Premièrement le choix de l’intégrateur influence sans doute le
déroulement du projet, pour cela le choix de l’intégrateur doit être fait soigneusement. En

73
deuxième lieu pour bien choisir son intégrateur, il faut prendre en considération la taille de
l’équipe et l’organisation de l’intégrateur ERP à choisir doit, de préférence être en harmonie
avec la taille et la culture d’entreprise, il faut également s’assurer de l’expérience de
l’intégrateur ERP qui est un bon indicateur des compétences…

74
 Bibliographie
 A.TUTEJA, enterprise resource planning : what’s there in it
http://www.angelfire.com/co/troyc/erp.html
 Arinze, B et al., (2003). "A Framework for Using OO to Rapidly Configure ERP
systems." Communication of the ACM
 Basu et al., le modèle de la théorie d’agence pour l’implimentation des ERP,
ACM Press: New York.2004, pp 8-13.
 Bradford M. et al., (2003). " Examination du role des facteurs de de diffusion dans
l’implimentation réussite de l’ERP.’’
 DANIE JUTRAS, « Evaluation du potentiel d’adoption des systèmes de gestion
intégrés dans les PME manufacturière », thèse présentée à l’université de Québec par,
Novembre 2002.
 Deloitte Consulting. (1999). ERP's second wave: Maximizing the value of ERP-
enabled processes. Atlanta: Deloitte Consulting,
 “enterprise resource planning systems.” International Journal of Accounting
Information systems, 4, 205-225.
 Forest, Généalogie des ERP et gestion des flux physiques. Systèmes d'Information et
Management, 4(4), 71-89,1999.
 Huin, S. F., (2004). "Managing deployment of ERP systems in SMEs using multi-
agents." Version électroniquehttp://isiarticles.com/bundles/Article/pre/pdf/12329.pdf
 Ifinedo, P., (2006). "Enterprise Resource Planning Systems success measurement: An
Extended Model." International Conference on Enterprise Information Systems
(ICEIS) 2006 - Databases and Information Systems Integration.
 International Journal of Project Management, 22, 511-517.
 Kouassi Michel Nguessan « La gestion des projets de mise en œuvre des systèmes
ERP en milieu universitaire », Thèse présentée au Département d'informatiqueen vue
de I'obtention du grade de Philosophie doctor à l’université de Québec, Canada, mai
2012
 Lequeux, J. L. (2002). Manager avec les ERP. Progiciels de gestion intégrés et
Internet. (2 éd.). Paris: Éditions d'Organisation.
 Luo, W., and Strong, D. M., (2004). "A framework for evaluating ERP
implementation

75
 Mary Sumner, “Critical Success Factors in Enterprise Wide InformationManagement
Systems Projects”,Southern Illinois University EdwardsvilleCampus Box
1106Edwardsville, IL 62026 618-650-2093, pp 296-303
 OURNANT, Laurence. AZAN, Wilfried. Réussir votre projet ERP. Saint-Denis La
Plaine : AFNOR, 2003. 67 p.Basu et al. 2003.
 Panorama Consulting, “CLASH OF THE TITANS 2016An Independent Comparison
of SAP, Or ac le, Microsoft Dynamics and Infor”
 Patrick Besson,Les ERP à l'épreuve des organisations,1999.
 Placide poba-nizou, Processus d’adoption et réduction du risque d’implantation des
PGI dans les PME : une étude de cas multiples, thèse présenté à l’université du
Québéque en 2008.
 Sedera, D., Rosemann, M. et Gable, G. (2001). Using performance measurement
models for benefit realization with Enterprise Systems - The Queensland govemment
approach (Case Study). In Actes du gh European Conference on Information Systems,
Bled, Slovenia, June 27-29.837-847.
 QUELENNEC, CLAUDE. ERP, levier de transformation de l’entreprise. Paris :
Hermès Science, 2007. 288 p.
 Soffer, P. et al., (2005). "Aligning an ERP system with enterprise requirements: An
object-process based approach." Computers in Industry 56 (2005) 639-662.
 strategy on cross-functionality." Info Systems Journal. 2006, 16, 79-104.
 SYLVESTRE UWIZEYEMUNGU,juin 2008 « l'évaluation de la contribution des
progiciels de gestion intégrés à la performance organisationnelle: développement
d'une méthodologie processuelle »,thèse présentée à l'université du Québec à Trois-
rivières.
 Tomas, J.-L. (2005). ERP et PGI : Sélection, déploiement et utilisation opérationnelle.
(4 éd.). Paris: Dunod.
 utilisation opérationnelle : les bases du SCM et du CRM . Paris : Dunod, 2003. 308 p.
 Yen, R. H. et Sheu, C. y. (2004). Aligning ERP implementation with competitive
priorities of manufaturing firms: An exploratory study. International Journal of
Production Economics, 92, 207-220.

76
 Webographie
o https://www.akuiteo.com/blog/erp-generaliste-ou-erp-specialise-metier-lequel-choisir
o https://www.silog.fr/erp-proprietaire-ou-open-source/
o https://www.appvizer.fr/magazine/operations/erp/top-5-erp-gratuit-open-source#erp-
open-source-definition-et-tendances-2018
o http://www.openbravo.com/fr/about/news/openbravo-retail-subscriptions-growth-
soars-beyond-expectations-driven-by-openbravo-cloud-fr/
o https://www.panorama-consulting.com/wp-content/uploads/2016/07/Clash-of-the-
Titans-2016-2.pdf
o https://www.panorama-consulting.com/overview-of-the-top-10-erp-systems/
o https://www.panorama-consulting.com/overview-of-the-top-10-erp-systems/
o https://www.panorama-consulting.com/wp-content/uploads/2016/07/Clash-of-the-
Titans-2016-2.pdf
o https://archive.org/details/missioncriticalr00dave/page/84
o https://www.vdn.fr/actualites/conseils-informatique/qualite-integrateur-erp/

77
 Table des matières
RESUME ............................................................................................................................................................ I
SOMMAIRE ...................................................................................................................................................... II
REMERCIEMENTS. ........................................................................................................................................... III
DEDICACE : ...................................................................................................................................................... IV

LISTE DES FIGURES ........................................................................................................................................... V

LISTE DES TABLEAUX ....................................................................................................................................... VI
LISTE DES ABREVIATIONS ............................................................................................................................... VII
INTRODUCTION GENERALE............................................................................................................................... 1

CHAPITRE 1 : INTRODUCTION DANS LE MONDE DES PGI .............................................................................................. 3

Introduction :............................................................................................................................................ 3
Section 1 : le cadre conceptuel et théorique des PGI .................................................................................. 3
I. Définition théorique et caractéristiques d’un PGI ......................................................................................... 3
II. De la définition théorique à la définition opérationnelle : ........................................................................... 10
III. Théories et modèles appliqués à l’adoption des ERP ................................................................................... 13
1. la théorie du changement organisationnel ............................................................................................. 13
2. La théorie de la diffusion de l'innovation. .............................................................................................. 13
3. La théorie néo-institutionnelle. .............................................................................................................. 14
4. La théorie de la complexité. .................................................................................................................. 15
IV. Typologie des PGI ...................................................................................................................................... 16
1. Les PGIpropriétaires : De l’ERP généraliste à l’ERP généraliste verticaliste .............................................. 17
2. les PGI open source:.............................................................................................................................. 18
3. Liste des ERP Open Source hors classement ........................................................................................... 20
Section 2 : Histoire et évolution des PGI................................................................................................... 21
I. Le contexte d’émergence des PGI :............................................................................................................. 22
II. Évolution du PGI : ...................................................................................................................................... 25
Conclusion : ............................................................................................................................................ 27
CHAPITRE 2 : LA MISE EN PLACE D’UN PGI : UN MEGA PROJET .................................................................................... 28
Introduction :.......................................................................................................................................... 28
Section 1 : Théories, tactiques et défis de la mise en place des PGI ........................................................... 28
I. Définition d’un projet ERP.......................................................................................................................... 28
II. Théories appliquées sur la mise en place des ERP ....................................................................................... 29
III. Construction de l’équipe du projet ............................................................................................................. 33
1. Les intervenants internes ...................................................................................................................... 33
a. Le chef de projet: ............................................................................................................................. 33
b. Les membres du comité du pilotage:................................................................................................. 33
c. La direction : .................................................................................................................................... 34
d. Les utilisateurs ................................................................................................................................. 35
e. Le bureau exécutif : .......................................................................................................................... 35
f. Les équipes de mise en œuvre : ........................................................................................................ 35
2. Les intervenants externes ..................................................................................................................... 35
a. Intégrateur....................................................................................................................................... 35
b. Les consultants externes................................................................................................................... 36
IV. Les phases du projet ERP ........................................................................................................................... 37
1. Cadrage ................................................................................................................................................ 38
a. Objectifs &Reengineering ................................................................................................................. 39
b. Etude de marché et choix de l’ERP .................................................................................................... 39

78
 c. Choix des consultants et contrats...................................................................................................... 40
d. Planification ..................................................................................................................................... 40
2. Réalisation ............................................................................................................................................ 41
a. Développement spécifique et paramétrage....................................................................................... 41
b. Simulations ...................................................................................................................................... 42
c. Transfert des données ...................................................................................................................... 42
d. Formation des utilisateurs ................................................................................................................ 43
3. Déploiement ......................................................................................................................................... 43
a. Le Big Bang....................................................................................................................................... 44
b. Le déploiement vertical .................................................................................................................... 44
c. Le déploiement horizontal ................................................................................................................ 45
d. Le déploiement mixte horizontal/vertical .......................................................................................... 45
e. Support et Maintenance ................................................................................................................... 45
f. Mises à jour :.................................................................................................................................... 46
Section 2: le bon choix de l’intégrateur : un maillon central pour le succès du projet ERP ......................... 46
I. L’intégrateur : définition, rôle et équipe ..................................................................................................... 47
II. Le bon choix intégrateur un maillon central pour une mise en place réussie et qualifiée d’un PGI ................ 49
Conclusion : ............................................................................................................................................ 50
CHAPITRE 3 : ETUDE DE CAS DE MISE EN PLACE D’UN ERP AU SEIN DE KARIZMA CONSEIL .............................................. 51
Introduction :.......................................................................................................................................... 51
Section 1 : L’organisme d’accueil............................................................................................................. 51
I. Historique, activités et objectifs ................................................................................................................. 51
II. Produits et clients ...................................................................................................................................... 52
1. Les produits .......................................................................................................................................... 52
2. Les clients ............................................................................................................................................. 53
III. Organisation hiérarchique ......................................................................................................................... 53
Section 2 : Présentation du projet :.......................................................................................................... 54
I. La phase du cadrage .................................................................................................................................. 54
II. Description fonctionnelle des besoins ........................................................................................................ 55
1. le module de vente ............................................................................................................................... 55
2. le module achat .................................................................................................................................... 56
3. le module de facturation ....................................................................................................................... 56
4. le module inventaire ............................................................................................................................. 56
5. Field services (la gestion des employés sur le terrain) ............................................................................ 56
6. Assistance............................................................................................................................................. 57
III. Organisation et gestion du projet: .............................................................................................................. 58
1. La méthode agile SCRUM pour la gestion des projets SI ......................................................................... 58
2. Équipe du projet: .................................................................................................................................. 59
3. Planification du projet: .......................................................................................................................... 60
IV. Étude de l’existant ..................................................................................................................................... 62
V. Benchmark et choix de la solution Odoo .................................................................................................... 63
VI. Conception et modélisation des spécificités ............................................................................................... 64
1. La modélisation des processus métier ................................................................................................... 65
a. Le processus vente : ......................................................................................................................... 65
b. Le processus d’achat :....................................................................................................................... 66
c. Le processus du Field services ........................................................................................................... 66
2. Le diagramme de use case..................................................................................................................... 67
3. Diagramme des classes ......................................................................................................................... 68
VII. La phase de réalisation : ........................................................................................................................ 70
Conclusion : ............................................................................................................................................ 72
CONCLUSION GENERALE ................................................................................................................................ 73
BIBLIOGRAPHIE : ............................................................................................................................................ 75

79
WEBOGRAPHIE............................................................................................................................................... 77
TABLE DES MATIERES ..................................................................................................................................... 78

80