Embed Size (px)
Citation preview
ESC 2 - Janvier 2015
Pour quelles raisons les grandes entreprises
« échouent » lors de la mise en place d’une
solution ERP ? Identification des facteurs
clés de succès.
Mémoire de recherche présenté et soutenu par :
Aurélie Jankowski et Jimmy Mendy
Directeur de recherche :
Mme Dominique Bouet
2
Résumé En 2013, le taux d’échec d’un projet ERP est de 10 % (Panorama Consulting
Solutions). Le but de cette étude est d’identifier les différents facteurs clés de succès à prendre
en considération lors de la mise en place d’une solution ERP. L’étude se focalise sur 6
facteurs clés majeurs : L’implication de la direction générale, la sélection de l’ERP, le choix
du groupe de projet, la redéfinition des processus métiers, la personnalisation de l’ERP, la
communication.
Une étude qualitative a été menée, basée sur des entretiens avec des chefs de projet
informatique et des utilisateurs finaux de 3 entreprises (une entreprise de gaz, une entreprise
d'électricité, une entreprise de géologie) qui avaient implémenté un ERP (SAP ou Oracle).
Les résultats montrent que la personnalisation et la redéfinition des processus métiers
étaient critiques et une source potentielle d’échec. D’autres constatations sont également
mises en avant et notamment une concernant les utilisateurs finaux.
Mots clés : Système d’information, ERP, Facteurs clés de succès, problèmes organisationnels,
chefs de projet, utilisateurs.
Abstract In 2013, the failure rate of ERP projects is 10 % (Panorama Consulting Solutions).
The purpose of this study is to identify the various key success factors to be considered during
the implementation of an ERP. The study focuses on 6 major KSF: Top management support,
the ERP selection, the choice of the group project, the business process reengineering, the
customization, effective communication.
A qualitative study was led, based on interviews towards both IT project managers and
final users from 3 companies a gas company, an electricity company, a geology company)
who had implemented an ERP (SAP or ORACLE).
Results show that customization and business process reengineering were critical and a
potential source of failure. Put other key findings briefly and also the one regarding final
users.
Keywords: Information system, ERP, Key success factors, organizational problem, IT project
managers, users.
3
Remerciements
Nous tenons à adresser nos remerciements aux personnes qui nous ont aidées dans la
réalisation de ce mémoire.
En premier lieu, nous exprimons toute notre reconnaissance à notre Directeur de mémoire
Madame Dominique Bouet, qui a bien voulu assurer la direction de ce travail. Nous la
remercions pour ses multiples conseils et pour tout le temps qu’elle y a consacré.
Nous remercions également les trois entreprises qui ont accepté de participer à l’étude
qualitative, et plus particulièrement les trois chefs de projet et les deux utilisateurs.
Pour finir, nous tenons à remercier l’entreprise Timspirit pour nous avoir mis en contact avec
deux des entreprises.
4
Table des matières
Résumé .................................................................................................................................................... 2
Abstract ................................................................................................................................................... 2
Remerciements ........................................................................................................................................ 3
Table des illustrations .............................................................................................................................. 6
I. Introduction ..................................................................................................................................... 7
II. Revue de la littérature ...................................................................................................................... 9
Facteurs clés de succès ....................................................................................................................... 9
Les phases d’un projet ERP .............................................................................................................. 10
Les différents types de FCS dans les projets ERP ............................................................................. 10
Synthèse des FCS recensés ................................................................................................................ 11
L’implication de la direction générale .............................................................................................. 14
La sélection de l’ERP ........................................................................................................................ 14
La composition du groupe de projet .................................................................................................. 15
Acteurs internes : le chef de projet et les équipes .......................................................................... 16
Acteurs externes : les consultants externes.................................................................................... 17
La redéfinition des processus métiers ............................................................................................... 17
La formation .................................................................................................................................. 19
Problème de pertinence des informations dans les ERP ................................................................ 20
Modèles de redéfinition des processus .......................................................................................... 20
La personnalisation de l’ERP ........................................................................................................... 21
La communication ............................................................................................................................. 22
III. La méthodologie de recherche ................................................................................................... 23
Justification du choix de la méthode qualitative ............................................................................... 23
La méthode qualitative : la population et les interviews ................................................................... 24
Le profil des entreprises .................................................................................................................... 26
Le profil des personnes interrogées .................................................................................................. 27
IV. Les résultats ............................................................................................................................... 29
Questions génériques - Les raisons de la mise en place d’une nouvelle solution ERP ..................... 29
Questions génériques – Périmètre d’implémentation, étapes de projet, réussite ou échec .............. 30
Les facteurs clés de succès ................................................................................................................ 33
L’implication de la direction générale .............................................................................................. 34
La sélection de l’ERP ........................................................................................................................ 35
La composition du groupe de projet .................................................................................................. 37
Acteurs internes : le chef de projet et les équipes .......................................................................... 37
5
Acteurs externes : les consultants externes.................................................................................... 38
La redéfinition des processus métiers ............................................................................................... 39
La formation .................................................................................................................................. 40
Problème de pertinence des informations ...................................................................................... 42
La personnalisation de l’ERP ........................................................................................................... 43
La communication ............................................................................................................................. 44
Les nouveaux FCS établis par les entreprises ................................................................................... 44
La conclusion de la mise en place ..................................................................................................... 45
V. Conclusion ..................................................................................................................................... 48
Bibliographie ......................................................................................................................................... 50
ANNEXE 1 - Guide d’entretien ............................................................................................................ 54
ANNEXE 2 – Tableau récapitulatif des entretiens (Chefs de projet) .................................................... 58
ANNEXE 3 – Tableau récapitulatif entretiens (Utilisateurs) ................................................................ 63
6
Table des illustrations
Figures
Figure 1 - Les quatre phases d’un projet ERP par Shanks, Parr, Hu, et al. (2000). .............................. 10
Figure 2 - FCS par rapport aux phases de projet des auteurs Shanks, Parr, Hu, et al. (2000) ............... 13
Tableaux
Tableau 1 - Tableau de synthèse des auteurs étudiés par FCS .............................................................. 12
Tableau 2 - Le profil des entreprises interrogées .................................................................................. 27
Tableau 3 - Le profil des personnes interrogées .................................................................................... 28
Tableau 4 - Les grandes dates des différents projets ............................................................................. 31
7
I. Introduction
Selon les statistiques de l’entreprise Panorama Consulting Solutions, un cabinet de
conseil spécialisé dans le choix et la mise en place d'ERP, le taux d’échec d’un projet ERP en
2013 est élevé : « 10 % des répondants parlent d’échec dans la mise en place de leur ERP ».
Ce constat pose question vu le nombre d’entreprises qui se lancent dans ce type de
projet informatique (81% des entreprises françaises sont dotées d’un ERP en 2011, d’après
l’étude Markess). Le marché des éditeurs de logiciel ERP est en croissance en 2013 malgré la
crise économique : « The worldwide Enterprise Software Market (ERP) market grew 3.8% in
2013” (Forbes, 2013). L’objectif des entreprises à se lancer dans la mise en œuvre d’une
solution ERP est d’adopter un système unique et cohérent afin de centraliser les informations
et de faciliter leur circulation. Le déploiement d’un système ERP est censé procurer à
l’entreprise une gestion plus souple, une amélioration de la productivité et ainsi obtenir un
avantage concurrentiel sur leur marché (Gilbert et Leclair, 2004).
Malgré un développement rapide de ces solutions, les bénéfices de performance
annoncés restent à relativiser : « 60% des répondants ont réalisé moins de la moitié des
bénéfices désirés » (Panorama, 2013). C’est ce constat contradictoire qui nous a amené à
réaliser ce mémoire au sujet des ERP. Ainsi tout au long de cette étude, nous nous efforcerons
de répondre à la problématique suivante :
Pour quelles raisons les grandes entreprises « échouent » lors de la mise en place
d’une solution ERP ?
L’ERP (« Entreprise Ressource Planning ») qui est source de productivité et de
performance pour les entreprises, devient un frein dans certaines d’entre elles. Les entreprises
n’ont pas réellement conscience des bouleversements organisationnels qui vont intervenir lors
de la mise en place de la solution. L’ERP va permettre de centraliser l’ensemble des
informations et va réorganiser les processus organisationnels de l’entreprise. Beaucoup
d’entreprises rencontrent des difficultés plus ou moins importantes. C’est ainsi que dans
certains cas, l’entreprise en vient même à ne plus utiliser le système d’information déployé
par la direction informatique car il n’y a eu aucun plan de formation ou de communication
comme par exemple les entreprises Dell et Boeing (Chaabouni, 2006).
8
L’échec des entreprises dans la mise en place de ces solutions ERP devient un
problème majeur qu’il est important de prendre en considération.
Si la question de l’échec des entreprises dans leur projet ERP est souvent mise en
avant dans la littérature, elle a rarement fait l’objet d’une étude globale. De plus, la plupart
des études scientifiques faites à ce sujet datent des années 2000, les entreprises étaient pour la
majorité dans la phase d’implémentation de leur solution et n’avaient pas forcément beaucoup
de recul. Aujourd’hui, les entreprises sont plus conscientes des difficultés qu’elles ont eues et
les problèmes organisationnels qu’elles auraient pu éviter.
Le but de notre mémoire est d’identifier les éléments à prendre en considération lors
de la mise en place d’une solution ERP afin de bâtir une liste de facteurs clés de succès (FCS).
Pour conduire ce mémoire, une revue de la littérature a été réalisée dans un premier
temps. Une vingtaine de revues scientifiques, mettant en avant les difficultés des entreprises à
implémenter leur solution ERP, ont été examinées. Ces sources extraites des bases de données
EBSCO, Emerald ont permis de mettre en avant les facteurs clés de succès nécessaires à une
implémentation réussie d’un projet ERP.
Dans un deuxième temps, nous avons conduit une étude qualitative avec plusieurs
entretiens dans le but de mettre en corrélation cette liste de facteurs clés de succès avec trois
grands projets ERP de trois grandes entreprises (une entreprise de fourniture de gaz, une
entreprise de fourniture d’électricité et une troisième entreprise de géologie). Les deux
premières ont fini le déploiement de leur solution depuis plus de cinq ans, la dernière a
abandonné la mise en place de sa première solution choisie. Cette étude empirique, nous a
amené à interroger trois chefs de projet de ces trois entreprises afin de discuter et de faire
valider la liste des facteurs clés de succès établie lors de la revue de la littérature. Nous avons
aussi effectué deux entretiens avec des utilisateurs du logiciel de l’entreprise de géologie pour
connaître leur ressentis sur leur implication dans le projet.
Ce mémoire va permettre d’aider les différentes entreprises et plus particulièrement la
direction informatique et de l’entreprise à mieux appréhender la mise en place de leur solution
ERP. Elles pourront vérifier si chaque facteur clés de succès a été vérifié et pris en
considération.
9
II. Revue de la littérature
La revue de la littérature va permettre d’identifier les facteurs clés de succès essentiels
lors de l’implémentation d’un logiciel ERP, décrits dans les textes scientifiques d’une
vingtaine d’auteurs. La mise en avant de ces facteurs clés de succès est essentielle à la
compréhension des échecs des entreprises dans le développement de leurs projets ERP. Il y a
d’importants risques de projets qui doivent être pris en compte et planifiés correctement
(Wong et Tein, 2007).
Facteurs clés de succès
La notion de facteur clé de succès a été proposée pour la première fois par Hofer et
Shendel (1978) : « Les facteurs clés de succès sont ces variables à partir desquelles le
management peut influencer de façon significative l’équilibre des positions concurrentielles
des firmes sur les industries ». Ils sont déterminants de la constitution d’un avantage
concurrentiel qui va permettre à l’entreprise de pouvoir surpasser ses concurrents par la
performance. Hazerbrouck (1992) parle de « maîtrise de la performance ».
Ces facteurs clés de succès vont être associés à des risques lors de la mise en place
d’un nouvel ERP dans une entreprise. Ces risques sont depuis longtemps détaillés dans la
littérature : le premier écrit, rédigé par Alter, remonte à 1979 où l’auteur expose des risques
informatiques en entreprise alors que l’informatique y est encore peu développée. L’ensemble
de ces facteurs clés de succès doivent être pris en compte et évalués si l’entreprise souhaite
minimiser les risques et si elle ne veut pas l’échec de son projet.
Pour beaucoup d’auteurs, il faut faire une différence entre un projet logiciel classique
et un projet logiciel ERP. Pour Bingi, Maneesh et al. (1999), le projet logiciel ERP comprend
l’implémentation d’un logiciel ainsi qu’une mise en place de processus organisationnels.
Quant à Figuières (2001), il explique que cette solution doit permettre la normalisation des
processus dans l’entreprise, ce qu’un simple logiciel ne fait pas nécessairement.
Le déploiement d’une solution ERP agit sur l’entreprise en termes de fonctionnement :
« L’organisation devient transversale, elle n’est plus découpée par de grandes fonctions mais
par des macroprocessus qui traversent les principales fonctions de l’entreprise. » (El Amrani,
2003).
10
En conséquence d’après la plupart des auteurs, l’ERP est beaucoup plus risqué, et le
projet a moins de chance d’aboutir (Sumner, 2000 ; Markus, Axline, et al., 2000).
Les phases d’un projet ERP
Selon Ross (1999), un projet ERP est découpé en cinq phases distinctes et chacune de
ces phases demande des compétences spécifiques : l’étude, l’implémentation, la stabilisation,
l’amélioration et la transformation. Quant à Hoffman (2007), il réduit le nombre de phases en
passant de cinq à trois. Ils regroupent les trois dernières phases ensemble pour n’en faire
qu’une plus globale. De plus, les auteurs utilisent des noms génériques comme : la pré-
implémentation, l’implémentation et l’après-implémentation. Shanks, Parr, Hu, et al. (2000)
ont décidé d’en définir quatre : L’étude de l’opportunité, l’implémentation, la conduite du
changement et l’amélioration. Ils font la distinction entre la conduite du changement,
l’accompagnement des individus dans les entreprises pendant et à l’issue de la mise en place
de l’ERP et l’amélioration du logiciel c’est-à-dire les changements de version ou bien l’ajout
de fonctionnalités dans l’ERP.
Dans la figure 1, nous avons choisi de représenter le processus de mise en place d’un
ERP par les quatre phases de Shanks, Parr, Hu, et al. (2000).
Lors de
Figure 1 - Les quatre phases d’un projet ERP par Shanks, Parr, Hu, et al. (2000).
Les différents types de FCS dans les projets ERP
Pour la majorité des auteurs deux catégories de facteurs clés de succès se dessinent :
les FCS techniques et les FCS organisationnels. Selon Sumner (2000), l’échec d’un projet
ERP est plutôt lié à un problème organisationnel qu’à un problème technique : « Poor
technical methods is only one of the causes and this cause is relatively minor in comparison to
larger issues such as failures in communications and ineffective leadership »
L’étude de
l’opportunité L’implémentation
La conduite du
changement Les améliorations
11
Il met en avant le problème technique comme plus mineur que l’ensemble des
problèmes organisationnels qui affectent les projets ERP (Sumner, 2000). Mais d’après
l’étude de Markus, Axline, et al. (2000), menée dans des entreprises, il peut y avoir un
problème d’intégration dans l’entreprise du logiciel à cause de matériels inappropriés
(Systèmes d'exploitation, système de télécommunication, logiciel de base de données), qui
peut être causé par une dispersion géographique de l’entreprise dans le monde ou par la taille
de l’entreprise.
Dans notre étude, nous nous intéresserons plus particulièrement aux FCS
organisationnels.
Synthèse des FCS recensés
Dans un premier temps, nous vous exposons le tableau des 6 facteurs clés de succès
avec la liste des auteurs que nous avons étudiés et confrontés entre eux :
FCS Auteurs
1 L’implication de la direction générale
Sumner (2000)
Rabaai (2008)
Wong et Tein (2007)
Nah et Lau (2000)
Wee (2000)
Ziemba et Oblak, (2008)
Saint-Leger et Beeler (2011)
Worou (2008)
2 La sélection de l’ERP Hawari et Heeks (2010)
Markus, Axline, et al. (2000)
Florescu et Dumitru (2007)
Wong et Tein (2007)
Mezghani et Maaloul (2003)
3 La composition du groupe de projet
Markus, Axline, et al. (2000)
Chang, Li et al. (2004)
12
Carmen et Vital (2010)
Verville et Halingten (2003)
Wong et Tein (2007)
Wilfrid et Tarek (2013)
Sumner (2000)
Lemaire (2002)
Lequeux (2011)
4 La redéfinition des processus métiers Chang, Li et al. (2004)
Sumner (2000)
Besson (1999)
Gomez, Frot et al. (2002)
Gunasekaran et Kobu (2002)
Peaucelle (1999)
El amrani, Rowe et al. (2003)
Ruzé (2003)
Florescu et Dumitru (2007)
Markus, Axline, et al. (2000)
4.1
/
4.2
/
4.3
- La formation
- Problème de pertinence des informations dans
les ERP
- Modèles de redéfinition des processus
Ruzé (2003)
Wong et Tein (2007)
Hawari et Heeks (2010)
Gomez, Frot et al. (2002)
Sumner (2010)
Ng, Ip et Lee (1999)
Markus, Axline, et al. (2000)
Gunasekaran et Kobu (2002)
5 La personnalisation de l’ERP
Markus, Axline, et al. (2000)
Hawari et Heeks (2010)
Wong et Tein (2007)
6 La communication
Sumner (2000)
Chaabouni, (2006)
Saint-Leger et Beeler (2011)
Strauss (1978)
Tableau 1- Tableau de synthèse des auteurs étudiés par FCS
13
Dans la figure 2, nous avons positionné les facteurs clés de succès par rapport aux
différentes phases de projet des auteurs Shanks, Parr, Hu, et al. (2000), ce qui permettra
d’identifier à quel moment du projet le facteur clé de succès doit être pris en compte :
Figure 2- FCS par rapport aux phases de projet des auteurs Shanks, Parr, Hu, et al. (2000)
Par la suite, nous confrontons les auteurs de la littérature par rapport à chaque facteur clés de
succès.
14
L’implication de la direction générale
L’implication et le soutien de la direction générale est le FCS principal, fondamental
pour la majorité des auteurs (Sumner, 2000 ; Rabaai 2008 ; Wong et Tein 2007).
Pour Wong et Tein (2007), la direction doit être présente car un projet ERP implique
des changements significatifs dans les processus métiers existants. L’appui de la direction
auprès des employés est la condition nécessaire pour que le salarié accepte le nouveau
système d’information (SI) mis en place. Si la direction est ferme vis-à-vis du projet, les
salariés le seront aussi. Au contraire si la direction n’est pas d’accord avec le nouveau
système, les salariés le seront encore moins. La direction n’a pas intérêt à montrer ces doutes
devant les salariés et doit être ferme quant à l’utilité du nouveau système. Elle doit créer un
environnement favorable à l’accueil d’un projet ERP, dans le cas contraire le projet pourrait
être rejeté par les utilisateurs (Saint-Leger et Beeler, 2011).
La direction général doit être d’accord dans la mise en place du projet et doit suivre la
totalité de l’avancement du projet (Nah et Lau, 2000), même dans les administrations
publiques (Ziemba et Oblak, 2008). Ces dernières ont effectué des recherches plus précises
sur les administrations publiques qui ont montré qu’il est aussi nécessaire d’avoir l’appui de la
direction générale. Le projet doit être une priorité pour la direction générale puisque
l’investissement est important. Elle doit soutenir les équipes pour atteindre les objectifs du
projet et aligner ces objectifs avec les objectifs stratégiques de l’entreprise (Sumner ,2000).
De plus, une excellente communication est demandée entre la direction et les chefs de
projet ainsi que les utilisateurs. L’ensemble des informations doit être remonté à la direction
de l’entreprise (Wee, 2000). Pour Worou (2008), la direction générale doit même être l’auteur
des actions de communication de formation et de gestion des compétences.
La sélection de l’ERP
Avant tout choix de solution et d’analyse d’étude, l’entreprise doit avoir un objectif
clair et définis (Wong et Tein, 2007). Le logiciel doit être choisi par l’entreprise suite à une
étude détaillée de l’environnement et des besoins de l’entreprise. Cette étude est souvent
effectuée par des consultants externes qui vont lui conseiller une solution adaptée à ses
besoins. Pour Florescu et Dumitru (2007), l’entreprise doit organiser des réunions avec les
15
différents acteurs afin de discuter et d’anticiper les risques qui peuvent intervenir au cours du
projet.
Souvent les entreprises sont amenées à choisir un logiciel en fonction du prix et non
par rapport aux besoins de l’entreprise : « The stated reason for the selection of Omega and
eMAG was cost » (Hawari et Heeks, 2010).
Les auteurs Markus, Axline, et al. (2000) ont défini une nouvelle phase au début du
cycle de déploiement d’un projet appelée « the chartering phase ». C’est la phase qui a besoin
de plus d’attention, où les décisions sont prises concernant les objectifs du projet, le budget
alloué et le choix du logiciel. Selon les auteurs, sans cette phase au préalable, un projet de
déploiement ERP est voué à l’échec.
Certaines entreprises rencontrent ensuite des problèmes si l’étude préalable n’a pas été
réalisée, car de ce fait la qualité du système peut être détériorée (Hawari et Heeks, 2010). Or
selon ces auteurs, la qualité du système est un déterminant essentiel au succès du projet. Le
logiciel sera plus ergonomique pour les utilisateurs (moins de bugs, facilité d’utilisation et
d’apprentissage). De plus, la résistance au changement sera moindre (Mezghani et Maaloul,
2003).
La composition du groupe de projet
Selon Markus, Axline, et al. (2000), la mise en place d’un groupe de travail
performant et uni est un FCS important : « Teamwork and composition in the ERP
implementer-vendor-consultant partnership is a key factor influencing ERP implementation
success ».
Beaucoup d’acteurs interviennent dans la mise en place d’un projet, deux grands types
d’acteurs sont ciblés : les acteurs internes et les acteurs externes. Lequeux (2011) préconise
une équipe hybride, composée des futurs utilisateurs du progiciel, des experts de la société
éditrice du progiciel. Les rôles doivent être définis et rédigés, dans le « Contrat Interne ».
16
Acteurs internes : le chef de projet et les équipes
Chang, Li et al. (2004) démontrent d’après leurs recherches basées sur la méthode
Delphi pour identifier les facteurs de risques, que le risque prioritaire dans un projet ERP est
celui du manque de compétence du chef de projet. Le manque de compétence et d’expérience
des personnes dans les équipes projet peuvent faire perdre du temps et beaucoup d’argent aux
entreprises car il y a un risque d’erreur beaucoup plus important pour l’ensemble du projet
(Wong et Tein, 2007). Carmen et Vital (2010) rejoignent l’analyse des auteurs précédents, sur
l’idée qu’un chef de projet est un acteur clé qui doit être compétent et expérimenté :
Le chef d’un projet de TI de grande taille et générateur de changements importants dans
l’organisation est l’acteur principal qui dirige le processus par lequel le projet est
amorcé, contrôlé et piloté dans le respect de l’échéancier, des ressources et du budget
établi (Carmen et Vital, 2010).
En effet, selon Carmen et Vital (2010), les chefs de projet doivent connaître la partie
technique du projet mais aussi la partie managériale, et le problème majeur c’est qu’ils sont
souvent très incompétents pour diriger leur équipe.
Pour Verville et Halingten (2003), c’est l’équipe de dirigeant qui va choisir lors du
comité de direction une personne qui sera en charge du projet. C’est cette personne (souvent
le directeur de la DSI) qui désignera un directeur/manager d’équipe pour coordonner l’équipe
projet. Le choix dépend du coût, de l’impact, mais aussi de la nature du projet. De plus, de la
phase d’étude à la phase d’amélioration, une durée importante va s’écouler, les équipes projet
peuvent évoluer, une personne peut être amenée à partir à la retraite ou bien tout simplement
changer de travail. Le roulement du personnel dans l’entreprise peut poser un problème, le
nouvel embauché sera beaucoup moins compétent au sujet du projet, il ne l’aura pas suivi
depuis le début (Markus, Axline, et al, 2000).
Pour Wilfrid et Tarek (2013), même à la suite du déploiement de la solution, le
responsable doit suivre les étapes d’amélioration et de conduite du changement.
Dans l’équipe de projet, il doit y avoir un leader qui coordonne le projet et motive ses
équipes. Mais le leader est souvent vu négativement au sein d’une organisation, ce qui peut
amener à des conflits entre lui et les équipes projet qui ne comprennent pas sa fonction au sein
du projet (Sumner, 2000).
17
Acteurs externes : les consultants externes
Les acteurs externes au projet doivent être totalement intégrés au projet et dans
l’entreprise, ce qui est plutôt difficile au vu du nombre d’acteurs externes impliqués dans un
projet (Markus, Axline, et al., 2000).
Les consultants externes doivent mettre en place des logiciels et s’adapter au type
d’organisation. A chaque entreprise les caractéristiques sont différentes comme par exemple
la taille, les acteurs touchés, l’environnement interne et les enjeux du projet (Wong et Tein,
2007).
Pour Sumner (2000), il est indispensable que les consultants qui viennent mettre en
place les solutions soient spécialistes de la solution. S’ils ne connaissent pas les différentes
fonctionnalités et les différentes procédures de mise en place, il sera alors difficile pour
l’entreprise de comprendre les consultants. Cette réflexion est aussi partagée par Wong et
Tein (2007) qui expliquent que ces consultants externes doivent avoir des connaissances et
des compétences poussées dans le logiciel en question. Dans l’étude de Markus, Axline, et al.
(2000), une entreprise exprime son incompréhension face aux différents consultants externes
qui n’avaient aucune connaissance sur le détail du produit qu’ils devaient implémenter.
Lemaire (2002) soulève aussi le problème de l’hyperspécialisation des consultants dans son
étude, elle indique qu’ils sont souvent experts dans un module de l’ERP et possèdent peu de
connaissances sur le métier de l’entreprise. Selon lui, du fait d’un marché grandissant, les
sociétés de consultants ne peuvent plus fournir un service personnalisé à chacun de leur client.
Il y a de nombreux conflits entre l’entreprise et les consultants externes, qui sont
souvent liés au coût du projet qui augmente ou à une mauvaise gestion des plannings
(Markus, Axline, et al. 2000).
La redéfinition des processus métiers
Au niveau de l’organisation, plusieurs auteurs ont perçu un problème majeur dans la
redéfinition des processus métiers (Chang, Li and al, 2004 ; Sumner, 2000). C’est la plus
importante des parties puisqu’elle regroupe plusieurs sous facteurs clés de succès :
La formation – la conduite du changement
18
La personnalisation de l’ERP
Le choix du processus
A la création des premiers ERP, les départements informatiques des entreprises pensaient
que l’implémentation d’un ERP était une façon intéressante de restructurer l’ensemble de
l’entreprise au niveau organisationnel (Besson, 1999). Pour Gomez, Frot et al. (2002), d’après
leur étude au sein d’un groupe industriel français, la mise en place d’un ERP engendre un
chamboulement au niveau organisationnel : l’entreprise va s’organiser autour d’une approche
par processus. Elle va devoir réorganiser ses métiers et ses centres de compétences. Quant à
Gunasekaran et Kobu (2002), la redéfinition des processus métiers est indispensable si
l’entreprise veut atteindre ses objectifs et si elle veut améliorer sa qualité, ses coûts, son
service, ses délais, sa flexibilité et son innovation : « A business process has to undergo
fundamental changes to improve pro-ductivity and quality ». Florescu et Dumitru (2007)
rejoignent aussi cette idée.
D’après l’étude de El amrani, Rowe et al (2003), le déploiement d’une solution en un
temps record améliore « la transversalité », c’est-à-dire avoir une ouverture sur les autres
départements (une approche par processus) avec une meilleure circulation des informations. A
l’inverse, selon Peaucelle (1999) la redéfinition des processus métiers n’est pas vraiment
stimulant pour l’organisation, les gains en productivité sont très faibles. Il s’est avéré que
l’approche par processus serait néfaste, voir même négative pour l’entreprise (Peaucelle,
1999). A l’inverse, Gomez, Frot et al. (2002) conclut que des études quantitatives ont été
établies pour montrer que la mise en place d’un ERP avec une nouvelle approche de
l’organisation par processus était un facteur de performance pour. Quelques auteurs
expliquent que afin d’implémenter le logiciel dans un délai court, certaines entreprises n’ont
pas fait la redéfinition des processus en espérant le faire après l’implémentation (Markus,
Axline, et al, 2000). Ces entreprises ont peut-être gagné du temps mais elles ont dû par la
suite recommencer l’intégralité de leur projet.
Selon Ruzé (2003), il y a deux problèmes qui se posent dans la redéfinition des processus
métiers, celui de l’apprentissage suite au déploiement de la solution et celui de la pertinence
des informations dans le nouvel outil.
19
La formation
Lors de la mise en place de l’ERP, les processus organisationnels métiers évoluent, les
informations sont normalisées, les tâches à effectuer par le salarié changent, ce qui devient
une source d’inquiétude pour le salarié. Ces problèmes peuvent être surmontés par
l'apprentissage des nouvelles tâches après l’implémentation du logiciel (Ruzé, 2003). L’ERP
qui est organisé autour de processus est plus touché par ce problème de formation que
d’autres types de solutions informatiques.
Les formations doivent être disponibles et elles sont très encouragées afin de réduire la
résistance au changement des utilisateurs dans les entreprises (Wong et Tein, 2007). Il peut y
avoir une mise en place d’un service téléphonique pour aider les utilisateurs qui auraient du
mal à utiliser le logiciel (Gomez, Frot et al., 2002). D’après l’étude d’Hawari et Heeks (2010)
menée dans une entreprise Jordanienne, l’apprentissage après l’implémentation est
indispensable. Il faut aussi penser à redéfinir chaque poste avec les nouvelles tâches associées.
Les entreprises sont amenées à créer de nouveaux postes dans les équipes et à décentraliser le
pouvoir au niveau opérationnel pour qu’ils accèdent à la totalité des informations nécessaires
dans la solution. Certaines entreprises font appel à des ressources externes pour s’occuper des
missions opérationnelles pendant un temps défini pour laisser les principaux utilisateurs de
l’entreprise se former correctement au logiciel (Gomez, Frot et al., 2002).
Ruzé (2003) montre que si l’inquiétude sur le changement est forte, les salariés auront du
mal à effectuer un travail productif, l’apprentissage des nouvelles tâches se fera plus
lentement par les salariés. L’organisation sera moins performante et nous verrons apparaître
une certaine résistance au changement des salariés. C’est pourquoi, une entreprise
culturellement unie qui partage les mêmes valeurs et qui n’a pas peur du changement aura
plus de chance de réussir son implémentation (Wong et Tein, 2007).
Summer (2000) décrit le retour d’expérience d’une entreprise militaire et explique
l’importance de former les utilisateurs pour qu’ils veuillent par la suite utiliser le système et
n’établissent pas une « résistance au changement » : « insuficient end-user training can
generate resistance to using the system ». L’entreprise étudiée par l’auteur Sumner (2000)
n’avait pas adopté cette démarche d’apprentissage lors de leur première implémentation ERP
et a échoué à impliquer les utilisateurs dans l’utilisation de l’ERP.
20
D’après l’étude des auteurs Markus, Axline, et al. (2000), les entreprises se rendent
compte parfois que les formations doivent être allongées par le manque de compétence des
utilisateurs sur ce type de logiciel et qu’elles doivent même parfois faire des formations
connexes (par exemple, une formation montrant l’impact de l’utilisation de l’ERP sur les
autres services de l’entreprise). Les opérationnels ne se rendent pas compte du
chamboulement fonctionnel suite à la mise en place d’un logiciel comme celui-ci.
Enfin, selon Markus, Axline, et al. (2000), le budget et le planning des formations sont
souvent demandés aux managers qui n’ont aucune ressource à accorder pour la formation à la
solution.
Problème de pertinence des informations dans les ERP
Un autre point est évoqué par les auteurs sur la pertinence des informations dans un ERP.
Lors de l’implémentation, le transfert des données doit être pertinent et précis. Les ERP sont
des systèmes globaux qui doivent s’adapter à l’environnement de chaque entreprise. Ils
doivent permettre à l’organisation d’avoir une visibilité plus importante sur les données qui
circulent sans les ressaisir plusieurs fois (Ruzé, 2003). Gomez, Frot et al., (2002) évoque le
même problème en expliquant que l’entreprise doit aligner un logiciel normalisé avec
l’organisation de son entreprise, et que la plupart du temps les données reprises sont très
faibles et peu pertinentes. Pour Wong et Tein (2007), il faut réussir à transférer l’ensemble des
données des anciens logiciels qui étaient auparavant séparées (logiciels de paye, comptabilité,
vente,...) dans la solution ERP qui devient le cœur du système organisationnel. La pauvreté
des données reprises entraîne parfois le maintien du contrôle manuel traditionnel et la création
de nouveaux postes pour gérer les troubles dans le logiciel (Gomez, Frot et al., 2002).
Modèles de redéfinition des processus
Afin d’éviter au maximum l’ensemble des problèmes vus précédemment, de nombreux
modèles ont été pensés par les auteurs pour la conception et la modélisation des processus de
l’organisation. Le but étant de chercher des solutions optimales pour améliorer la performance
globale du système. D’après Gunasekaran et Kobu (2002), il y a cinq types de modèles
fondamentaux : les modèles conceptuels, les modèles de simulation, les modèles orientés
21
objets, les langages de modélisation type IDEF (Integrated DEFinition), les modèles réseaux
et les modèles basés sur la connaissance.
Pour exemple, le modèle de Ng, Ip et Lee (1999), lu au cours de notre étude littéraire, est
appelé HDP (Hierarchic design Pyramid). Il fournit une culture de soutien en prenant en
compte la gestion de la qualité et la gestion du réseau de communication interne et externe qui
va permettre d’installer les bonnes pratiques et procédures de la gestion du changement dans
l’entreprise lors de la mise en place d’un ERP. Ce modèle renvoie à deux types de modèles
exprimés précédemment : le modèle IDEF et le modèle orienté objet.
La personnalisation de l’ERP
Tous les éditeurs de ce type de logiciel recommandent aux entreprises de ne pas
personnaliser leur ERP par des développements spécifiques. C’est un système global qui doit
s’adapter aux différents besoins et fonctionnalités de l’entreprise : « ERP packages are
selected on a centralized basis in order to fit the majority of corporate needs » (Markus,
Axline, et al., 2000).
Il est conseillé à l’entreprise de ne pas adapter le logiciel à leur fonctionnement mais
d’adapter leur fonctionnement au logiciel (Markus, Axline, et al., 2000). Mais ceci à des
limites, il y a aucun logiciel ERP qui puisse regrouper l’ensemble des fonctionnalités de
toutes les entreprises du monde. Chacune des entreprises possède des spécificités et ces
entreprises souhaitent les implémenter, ce qui engendre des dépenses importantes de
maintenance et cause une perte de temps dans les entreprises (Wong et Tein, 2007). Les
auteurs Markus, Axline, et al. (2000) soutiennent l’idée des auteurs précédents en parlant d’un
« challenge » pour l’entreprise de personnaliser la solution. D’après Hawari et Heeks (2010),
les modifications faites par ces entreprises devraient être évitées car elles entraînent des
erreurs dans le système. Il devient difficile de faire des mises à jour de versions plus récentes
si l’on doit continuellement vérifier si les modifications faites au départ n’engendrent pas des
problèmes dans les montées de version. De temps en temps, les entreprises ne personnalisent
pas leur ERP mais acquièrent des logiciels personnalisés qui vont être interfacés avec le cœur
du système. Ces autres logiciels peuvent aussi poser problèmes, il est difficile d’interfacer
plusieurs logiciels, il y a une perte de données et de temps impressionnants (Markus, Axline,
et al., 2000).
22
Parfois, la customisation est inévitable pour des questions de règles de travail définies
par le pays (Markus, Axline, et al., 2000).
La communication
Pour Sumner (2000), c’est le deuxième risque majeur après celui de l’implication de la
direction de l’entreprise. Lorsqu’une entreprise change son processus informatique, elle doit
le communiquer à ses salariés. L’auteur va même plus loin, lorsqu’il explique que lors de ses
recherches il a découvert que si les équipes ne sont pas bien informées sur les changements, il
y a un risque que certaines personnes préfèrent démissionner. Dans les entreprises le plus
souvent, les utilisateurs du logiciel et les techniciens en informatique ne se sont jamais parlé,
ils n’ont jamais eu besoin de travailler entre eux. De plus, ils évoluent dans des mondes
totalement différents et n’ont pas les mêmes objectifs et visions de l’organisation. Il est
difficile de faire interagir ces personnes. L’auteur dans son étude “Alpha” explique que la
communication a été difficile, chaque groupe voulant défendre son périmètre : « Chacun a
tendance à protéger son territoire et la communication est réduite au sein de ALFA »
(Chaabouni, 2006).
Pour contrer ce manque de communication Saint-Leger et Beeler (2011), ont utilisé et
adapté le concept de « Culture Négociée » du sociologue américain, Anselm Strauss au cas de
projet ERP: « Le concept de culture négociée décrit la capacité des individus à ajuster leur
comportement quand ils sont amenés à coopérer avec des personnes de cultures différentes sur
des objectifs communs » (Strauss, 1978).
23
III. La méthodologie de recherche
Justification du choix de la méthode qualitative
La méthodologie de recherche est basée sur une approche qualitative. Nous voulons
mieux comprendre les divers problèmes organisationnels rencontrés dans les entreprises par
les chefs de projet lors du déploiement d’une solution ERP. L’étude qualitative permet
d’observer et d’analyser les comportements des humains (Boodhoo et Purmessur, 2009). Elle
va permettre de dégager une observation approfondie de la mise en place d’un ERP. C’est
pourquoi ce type d’étude apparait comme la mieux adaptée pour répondre à notre
problématique.
Afin de mener notre recherche, la collecte de données est réalisée grâce à des
interviews dans différentes entreprises. L’interview est l’un des outils de l’étude qualitative
qui va permettre de discuter des expériences des individus sur la mise en place de l’ERP dans
l’entreprise. L’interview va permettre aussi de comprendre les raisons qui ont poussées des
individus à faire ces choix (Boodhoo et Purmessur, 2009). Nous allons pouvoir vérifier la liste de
FCS élaborée dans la littérature auprès d’acteurs dans les entreprises et identifier les problèmes
qu’ils ont rencontrés lors de la mise en place d’une nouvelle solution ERP. Cela nous permettra
selon les résultats obtenus lors de ces entretiens de confirmer ou infirmer les FCS identifiés..
Les interviews ont été conduits sur la base d’un guide d’entretien1. La recherche
qualitative permet de poser des questions ouvertes. Nous avons adapté le guide d’entretiens
selon la fonction de l’individu au sein du projet, ce qui nous permet d’avoir une collecte de
données plus spécifique selon chaque type de profil. Nous souhaitions diversifier les
fonctions des différents interviewés, afin d’avoir un point de vue nuancé, propre à chaque
type de profil, pour recueillir un plus grand nombre de points de vue objectifs sur le sujet.
Nous avons effectué la collecte de données à partir d’un échantillon de trois
entreprises. Les différentes entreprises ont ou sont en train d’installer toutes les trois une
solution ERP (SAP ou ORACLE). Nous avons choisi ces entreprises sur différents critères.
Nous voulions des entreprises diverses avec des projets ERP de différentes natures. Mais
aussi des entreprises qui souhaitaient comprendre la raison de leurs différents échecs. Nous
avons recruté deux des entreprises grâce à l’aide de Timspirit, une entreprise de conseil en SI
1 Annexes 1 - Guide d’entretien
24
qui intervient dans l’accompagnement des projets informatiques de grandes entreprises du
CAC 40. Pour la dernière, nous avons eu le contact à la suite d’un stage en entreprise. Nous
voulions interviewer une entreprise pour laquelle le projet n’était pas encore terminé car il est
plus facile de parler d’un moment présent que d’un moment passé et terminé. Quand le projet
est fini, les détails s’oublient et il est difficile de repenser à tout.
La méthode qualitative : la population et les interviews
Les interviews ont été menés par des responsables d’entité du côté fonctionnel
« métiers » pour les deux dernières entreprises et un responsable d’entité architecture plutôt
technique pour la première2. Ils avaient tous les trois en charge une importante partie du projet
de mise en place de la nouvelle solution au sein de leur entreprise.
Dans une des entreprises, nous avons aussi effectué deux interviews par téléphone des
utilisateurs du logiciel pour connaître leurs ressentis sur le déroulement du projet ainsi que sur
l’accompagnement au changement (la question des formations et de la résistance au
changement)3. Même si cette deuxième étude porte sur un échantillon restreint, elle permet de
nuancer certains résultats obtenus.
Pour structurer l’interview, un guide a été établi et suivi pour chaque entretien. Celui-
ci était basé sur les facteurs clés de succès décrits dans la revue de la littérature, afin de
discuter sur ces points principaux et de faire le parallèle entre ces FCS et le déroulement de
l’implémentation de leur solution dans l’entreprise. Le guide d’entretien était différent pour
un responsable d’entité et un utilisateur, les préoccupations finales relatives au projet pour ces
2 populations n’étant pas les mêmes.
La structure globale du guide d’entretien pour les chefs de projet était la suivante :
Profil des personnes interrogées (nom, métiers, parcours professionnel, temps
dans l’entreprise)
Profil des entreprises (le type d’entreprise, le CA, le nombre d’employés, le nom
de la solution)
2 Tableau 2 - Le profil des personnes interrogées.
3 Tableau 3 - Le profil des entreprises interrogées.
25
Questions génériques du projet (Les raisons de la mise en place d’une solution
ERP, le scope, la date de mise en place de la solution, le temps de déploiement, la
période, etc.)
Les 6 facteurs clés de succès vus dans la littérature :
o L’implication de la direction générale (les questions de la motivation,
l’effort de communication, le feedback des équipes opérationnelles sur le
projet)
o La composition du groupe de projet (L’organisation, les compétences des
chefs de projet, les consultants externes)
o La sélection de l’ERP (Les participants à la définition des besoins et aux
réunions, la procédure adoptée pour l’étude du besoin, la solution, la
comparaison avec les autres solutions sur le marché.)
o La redéfinition des processus métiers avec la formation et le transfert des
données (le problème de la gestion par processus métier, l’apprentissage
des utilisateurs, la résistance au changement, le nombre de formation, la
quantité de données transférée)
o La personnalisation de l’ERP ( « customisation » et mises à jour du
logiciel)
o La communication (La communication des informations entre les différents
services)
o Ainsi que tous les nouveaux FCS établis par les entreprises.
La conclusion de la mise en place (la satisfaction de l’entreprise et des
utilisateurs, les performances, les améliorations par rapport à l’ancienne solution,
les fonctionnalités répondent ou non aux besoins de l’entreprise).
26
Pour les utilisateurs, le guide d’entretien reprenait la première partie (Profil des
personnes interrogées) et les questions sur l’implication et la formation de l’utilisateur au sein
du projet.
La durée moyenne d’un entretien était d’une heure, et se déroulait dans le bureau de la
personne interviewée ou bien par téléphone si nous ne pouvions pas faire autrement (ville
éloignée de l’interview). Toutes les discussions ont été enregistrées avec l’accord de chacune
des personnes sur des bandes audio pour nous aider à retranscrire avec précision l’ensemble
du scripte de l’interview.
Dans un premier temps, nous avons retranscris l’ensemble des entretiens mot par mot
sur un fichier Word. Puis, dans un deuxième temps, nous avons analysé ces entretiens
qualitatifs en créant un fichier Excel (chefs de projet)4 et un autre (utilisateurs)
5. Ces deux
fichiers Excel ont pour but de résumer et confronter les différents entretiens entre eux pour
identifier les similitudes et les différences mais aussi d’évaluer l’importance des FCS (quelles
sont ceux qui sont le plus discutés et ceux qui n’ont pas vraiment eu d’impact lors de
l’entretien).
Le profil des entreprises
Les trois entreprises interrogées sont de grandes entreprises dont le chiffre d’affaires
oscille entre 1 et 15 milliards d’euro. Nous choisirons pour la suite de l’étude d’appeler les
entreprises d’une lettre respective A, B et C.
Nous détaillons l’ensemble des informations des entreprises (Lettre utilisée dans le
mémoire, type d’entreprise, CA, ainsi que le nombre d’employés dans l’entreprise), dans le
tableau 2 suivant :
4 Annexe 2 – Tableau récapitulatif entretiens (Chefs de projet)
5 Annexe 3 – Tableau récapitulatif entretiens (Utilisateurs)
27
Lettre Type d’entreprise CA de l’entreprise
en milliard d’€
(2013)
Le nombre
d’employés
A Entreprise de gaz,
technologies et services
pour l'industrie et la
santé
15,2 50000
B Entreprise de service
d’électricité
2,3 15800
C Entreprise de géologie 1,41 1100
Tableau 2 - Le profil des entreprises interrogées
Le profil des personnes interrogées
Le profil des personnes interrogées sont de trois sortes :
Les chefs de projet dit « métiers » : il est en charge des équipes projets qui analyse les
besoins des « métiers » (comptabilité, gestion, financier,…). Il est en lien direct avec les
opérationnels, les futurs utilisateurs de l’application. (Entreprise B et C). Pour l’entreprise
B, le chef de projet avait commencé comme opérationnel en tant que Responsable
d’affaire dans le BTP, puis secrétaire général afin de mettre en place toutes les
réorganisations, pour ensuite la direction a décidé de lui confier le projet de la refonte du
système d’information en 2004. Il s’occupait de l’ensemble des domaines alors que pour
l’entreprise C, l’interviewé était adjointe à la comptabilité générale de l’entreprise et elle
était chef de projet seulement pour le domaine comptabilité dont elle s’occupait.
Les chefs de projet dit « IT » : Il est en charge des équipes projets qui traduisent ces
besoins « métiers » dans l’application, il a un côté beaucoup plus technique que le chef de
projet dit « métiers ». Il n’est pas vraiment en contact avec les utilisateurs mais plutôt avec
les chefs de projet « métiers », il était plus difficile pour ce type de personne de nous
parler de la relation des utilisateurs avec l’application. Pour l’entreprise A, la personne
28
interrogée intervenait plutôt dans « la maintenance des applications, les projets, la vision
stratégique, en amont dans le choix des solutions » ; il avait travaillé pendant 10 ans dans
la DSI d’un grand industriel automobile et il était maintenant responsable de l’entité
architecture de l’entreprise A depuis sept ans.
Les utilisateurs de l’application : Ce sont les personnes qui utilisent au quotidien
l’application et doivent être normalement intégrées dans le projet afin de définir leurs
besoins. Nous avons réalisé deux interviews dans la dernière entreprise de deux
comptables pour connaître le ressenti et l’implication des utilisateurs au projet.
Tableau 3- Le profil des personnes interrogées
Type
Profil
Métiers
Temps
Entreprise
Chef projet
"IT" Responsable de l'entité
architecture au sein de la DSI
Europe
Intervention dans la
maintenance des
applications, les projets,
Choix de solutions les
projets,
la vision stratégique
7 ans
Chef projet
"métiers" Responsable "métiers" projet
SAP - Coordinateur du projet (Avant :
Responsable d'affaire dans le BTP;
Secrétaire général)
Cadrage
Mise en place du futur SI
14 ans
Chef projet
"métiers" Directeur adjoint de la division
comptable +
Chef de projet du domaine
comptabilité
Adjointe comptable
Mise en place du futur SI
3 ans
Utilisateurs de
la solution Comptable Opérationnel 1 ans
Utilisateurs de
la solution Comptable Opérationnel 2 ans
29
IV. Les résultats
Dans un premier temps, nous avons posés des questions génériques. Nous avons
essayé de comprendre l’utilité pour l’entreprise de mettre en place une solution comme l’ERP,
nous avons discutés des étapes de projet et le périmètre de l’implémentation de la solution.
Questions génériques - Les raisons de la mise en place d’une nouvelle solution ERP
Pour les trois entreprises le choix d’une solution ERP fut une question de performance,
d’économie d’échelle, et de modernité du système d’information qui devenait obsolète et sans
flexibilité.
Dans les années 90-2000, c’est la croissance du marché des solutions ERP avec deux
fournisseurs dominants SAP et ORACLE, comme l’explique l’entreprise A : « Les années 90-
2000, c’est l’Age d’or des ERP, aujourd’hui toutes les entreprises du CAC 40 et les PME ont
des ERP pour gérer de façon intégrée l’ensemble de leur processus avec des outils
informatiques qui leur donne de la flexibilité, de l’efficacité, du contrôle». Ce qui rejoint
l’idée de plusieurs auteurs de la littérature et notamment Gnasekaran et Kobu (2002) pour la
question de flexibilité. Les deux grandes entreprises A et B soutiennent l’idée qu’elles
devaient suivre la logique de toutes les entreprises du CAC 40 qui avaient déjà adoptées ce
type de logiciel et en particulier la solution SAP ou ORACLE qui étaient les solutions star
dans les années 90-2000. Les deux entreprises ne savaient pas dans quelle aventure elles se
lançaient mais elles devaient suivre la cadence pour ne pas perdre en performance et en
efficacité. Si elles n’avaient pas suivi le rythme, elles auraient sûrement perdu leur place de
leader dans leur domaine. Elles ont toutes les deux, choisi de mettre en place SAP sans
vraiment connaître le produit mais pour faire comme les concurrents. Et pour l’entreprise B,
elle devait suivre plus particulièrement les autres filiales du groupe qui avaient déjà adopté
SAP. Il y avait aussi un autre point c’est le chiffre d’affaires qui était grandissant et ceci
devait être géré efficacement pour ne pas perdre du terrain : « avant c’était que 1 milliard
maintenant on est passé à 2,4 milliards »
Deux entreprises sur trois parlaient d’économie et de diminution de perte de temps au
vue de la performance de l’ERP au niveau des processus organisationnels « pour éditer une
facture, il fallait faire 100 click, 50 dans les services amont et 50 dans notre service »
30
(Entreprise C), un manque de flexibilité de la solution qui fait perdre du temps et de l’argent.
D’après cette entreprise, il devrait y avoir moins de personnel dans les services administratifs
et plus dans les services de production pour augmenter la productivité de l’entreprise.
Les entreprises B et C ont parlé toutes les deux de « non satisfaction de l’ancienne
solution ». De plus, il n’y avait pas eu de mise à jour du logiciel depuis plusieurs années
pour les deux entreprises car la solution était trop vieille avec beaucoup de spécificités, la
maintenance de l’application n’était plus possible : « Entre 10 ans et maintenant on a monté
aucun patch. Et on est coincé parce qu’on rencontre des difficultés d’évolution et de
maintenance » (Entreprise C), « On a arrêté de l’évoluer donc on avait un problème de montée
de version » (Entreprise B)
Pour l’entreprise C, le projet a été commencé tard en 2011 alors que la solution n’avait
pas été mise à jour depuis plus de 10 ans, les utilisateurs n’utilisaient même plus la solution en
préférant stocker leurs données sur un fichier Excel. L’ancienne solution avait mal été
implémentée et elle ne répondait plus aux besoins de l’entreprise. C’est pourquoi il devenait
vital pour cette entreprise de mettre en place une nouvelle solution. « Aujourd’hui on est sur
un produit qu’on n’aime pas, et qu’on n’utilise pas et comme on a plein de spécificités qu’on
n’arrive pas à mettre à jour, on en revient à des personnes qui vont utiliser Excel à la place »,
ce qui amène à une grande perte de « productivité ». Les chefs de département étaient même
incapables de trouver des informations fiables et intéressantes dans le système : « Un soir, on
m’a demandé combien de clients j’avais et j’étais incapable de tirer le nombre de clients
qu’on avait dans la base, je n’ai pas pu répondre à la question, je suis chef comptable je n’ai
pas pu répondre à la question c’est quand même désolant. »
Questions génériques – Périmètre d’implémentation, étapes de projet, réussite ou
échec
La majorité des projets ERP dure très longtemps (de 2 à 5 ans) et ont souvent un
budget très conséquent puisque des acteurs externes comme les intégrateurs ou bien des
consultants externes viennent se greffer au processus projet. C’est pourquoi les auteurs
Markus, Axline and al. (2000) conseillent aux entreprises de bien préparer la phase d’avant-
projet (le budget, les objectifs, la composition du projet, etc.)
31
Dans le tableau suivant, un récapitulatif des étapes clés des différents projets pour les
trois entreprises interrogées, le périmètre d’implémentation de l’ERP ainsi que la réussite ou
non du projet :
Lettre Nom du
projet
Grande dates du projet Succès Périmètre
A OPERA
(SAP)
2000 : Démarrage – Etude de
cadrage
Janvier 2003 : déploiement de
l’application
OUI Utilisateurs : 10000
dans 12 pays,
Module : module
finance, controlling,
procurement, la
supply chain
B OMEGA
(SAP)
2004 : Démarrage - Etude de
cadrage
2006 - 2008 : Avant-projet.
2009 : Déploiement des premières
sociétés pilote.
2010 et 2011 : Déploiement général.
2012 : nouveau projet SAXO du
groupe cousin AXIMA rejoigne le
même SI.
OUI Utilisateurs : 7000
Module : la finance,
comptabilité,
Contrôle de gestion,
Achat logistique,
Vente, Gestion
d’affaire + autres
modules
C OPALE
(SAP
PUIS
ORACLE)
2010 : rédaction d'un cahier des
charges
2011 : début du projet - Appel
d'offre
2012 : Choix de l'intégrateur SAP
2012-2013 : ateliers avec
l’intégrateur - Fichier de
Paramétrage finit par BRGM
Décembre 2013: arrêt du contrat
avec SAP par la direction
2013 -2014 : Nouvel appel d'offre
mais sur un produit précis ORACLE
Mars 2015 : date éventuelle de
déploiement pour la partie
comptabilité
NON
(SAP)
Phase
de
déploie
ment
(ORAC
LE)
Utilisateurs : Moins
de 500
Module : Comptabilité, taxes,
module de projet
Tableau 4 - Les grandes dates des différents projets
Deux entreprises sur trois (entreprise A et B) ont fini le déploiement de leur solution
ERP depuis plusieurs années maintenant (2003 et 2012). Elles sont actuellement sur la phase
d’après-projet dite d’« amélioration » d’après les auteurs Shanks, Parr, Hu, and all (2000).
32
Elles ont débuté respectivement leur projet en 2000 et 2004, une dizaine d’années avant
l’entreprise C. Nous voyons que plus l’entreprise est importante (CA important, grand nombre
d’employés) plus le projet ERP a démarré tôt. Ceci peut être expliqué par le fait que toutes les
grandes entreprises ont vu des résultats de performance et d’efficacité se profiler au travers
des autres grandes entreprises. Ces entreprises ont tout de suite voulu mettre en place ce
changement qui pouvait paraître comme une petite « révolution » de la performance
organisationnelle. Elles n’avaient pas forcément de contrainte budgétaire, contrairement à
l’entreprise C, qui elle a un budget beaucoup plus serré.
Le budget est une donnée très importante dans un projet d’envergure comme celui-ci.
L’entreprise C mentionne cinq fois dans son interview le problème du « budget » qui a été
une des causes de l’échec de la mise en place de la première solution choisie : SAP. Ce
problème de budget est aussi évoqué par l’entreprise B : « on n’a pas respecté le planning et le
budget de base comme tout le monde ». Pour l’entreprise B, lors de la prise de décision du
budget, il a fallu le multiplier par le facteur « Pi » pour avoir le budget réel de sortie. Ce
problème de budget qui est d’ailleurs aussi indiqué par les différents auteurs de la revue de la
littérature (Markus, Axline and al, 2000).
L’entreprise C a démarré son projet en 2010, son ancienne solution Oracle avait été
fortement customisée et il était impossible de faire des mises à jour, comme nous l’avons
expliqué dans le paragraphe précédent (cf. Les raisons de la mise en place d’une nouvelle
solution ERP). C’est pourquoi l’entreprise a décidé de changer l’intégralité de son système
d’information à partir de 2010. Elle a commencé dans un premier temps par choisir SAP suite
à un appel d’offre. Après un an et demi d’ateliers avec des consultants externes d’une société
de conseil qui les aidait à dialoguer avec l’intégrateur, la direction a choisi en décembre
dernier d’arrêter le contrat avec SAP, principalement pour des raisons de coût. Ils avaient
pourtant fini l’ensemble des ateliers et le paramétrage fictif de la solution « Quand on a
rompu le contrat, on avait fini tout le paramétrage. ». Ce premier projet fut un échec pour
l’entreprise en question.
Les équipes projets et opérationnelles ont perdu un an et demi de travail et ceci a
provoqué un sentiment de « frustration » chez les salariés : «On a vécu un vrai échec pendant
un an et demi où l’on a travaillé pour rien ». Pour l’adjointe comptable, deux raisons
probables de la direction de l’entreprise : « On avait été trop confiant sur la capacité de
l’établissement à mener ce projet ou alors sur son niveau budgétaire »
33
La société a ensuite décidé de reprendre la solution Oracle qui était la solution déjà en
place. Le problème est que l’entreprise a maintenant perdu énormément d’argent et tout le
travail effectué auparavant est perdu : « Mais nous, utilisateurs, on avait fait tout un travail qui
a été perdu ». Le deuxième projet, va lui aussi souffrir du problème budgétaire et l’objectif de
l’entreprise de mettre à plat l’ensemble de ces processus est terminé. Aujourd’hui, l’entreprise
tente seulement de mettre à jour la version Oracle, elle passe de la version 11i à la version
r12. Dans un même temps, il faut réussir à remotiver les équipes pour redémarrer ce nouveau
projet.
Quant aux deux autres entreprises, elles parlent de « succès » pour leur projet, la mise
en place de leurs deux solutions a été semée d’embûches mais elles ont réussi à satisfaire leurs
utilisateurs et à déployer l’intégralité de la solution. « Cette opération est un succès chez B».
Elle est maintenant en place depuis 10 ans pour l’entreprise A et depuis 2 ans pour
l’entreprise B. L’entreprise B envisage même d’étendre le périmètre d’implémentation « On
envisage de donner SAP à des populations plus importantes comme les chefs de chantier qui
ne l’ont pas, à terme nous pourrions aller jusqu’à 12000 salariés ». Pour l’entreprise A,
maintenant une dizaine d’année que SAP est en place dans l’entreprise avec un périmètre
utilisateur important 10000 sur 12 pays. Mais ces deux entreprises tiennent à contraster ce
« succès », pour y parvenir elles ont fait face à un certain nombre de crises.
Les facteurs clés de succès
Les différents entretiens ont permis de discuter des différents FCS établis dans la revue
de la littérature (discutés dans l’ordre de la revue de la littérature). Et dans un deuxième
temps, ces entretiens ont permis de déterminer d’autres FCS qu’il est important de prendre en
considération.
Le premier résultat visible de l’enquête est que les trois entreprises sont d’accord sur le
fait que la mise en place d’un projet ERP est un énorme chamboulement dans l’organisation
de l’entreprise. Même sans aller dans le détail des questions, les interviewés cessent de parler
et énumèrent tous les types de problèmes rencontrés au cours de leur projet. Ces entreprises
sont similaires d’une entreprise à l’autre. Les problèmes organisationnels et techniques sont
pour les trois entreprises au cœur d’un projet ERP et elles souhaitent toutes débattre sur ce
type de sujet.
34
L’implication de la direction générale
Deux entreprises (A et C) sur trois parlent de « Sponsorship au niveau du
management ». La troisième mentionne ce FCS mais plus succinctement. Pour ces deux
entreprises, il doit y avoir un ou plusieurs individus du côté « business » avec de grandes
responsabilités qui doivent être à la tête du projet. Ceci corrobore les résultats de Wong et
Tein (2007). Pour l’entreprise A, le fait de désigner un « sponsor », qui soit à un niveau
hiérarchique élevé va permettre d'affronter les changements organisationnels (les
transformations sur le terrain) qui vont être causés par la mise en place de l’ERP :
« Des gens côté business qui adhèrent à l’approche qui sont prêts à appuyer les changements
métiers qui sont nécessaires dans les ERP, il faut être capable d’être suffisamment fort pour
imposer les transformations sur le terrain »
Cette personne doit avoir « un fort leadership, une certaine virilité, avec une capacité à
mettre le point sur la table » afin de prendre les bonnes décisions stratégiques, budgétaires,
financières au projet, pour permettre le succès du projet (Entreprise A). La direction doit
avoir défini préalablement une bonne stratégie et un périmètre précis afin de cadrer le projet.
Elle doit définir le « Target business process », c’est-à-dire les différents processus métiers
cibles qui décrivent comment l’entreprise doit s’organiser pour la finance, la comptabilité, les
ventes, etc. (Entreprise A). C’est le point de vue de Wong et Tein (2007), pour qui la direction
présente tout au long du processus doit cadrer le projet, définir une stratégie en phase avec ses
besoins, ses métiers et son budget.
Deux entreprises mettent en avant le problème de l’arbitrage des décisions qu’ils ont
eu à prendre lors de la mise en place du projet. Dans l’entreprise C, les groupes de projets
étaient très étendus car la stratégie de l’entreprise était d’impliquer un maximum de personnes
et d’opérationnels. Personne n’avait été mentionné pour arbitrer l’ensemble des décisions à
prendre. Or, dans un projet comme celui-ci, beaucoup de directives sont à prendre. Comme
personne n’avait été désigné, personne ne voulait prendre la responsabilité de décider à la
place de l’autre, de peur de se faire réprimander. Ce problème a causé une perte de temps
importante tout au long du projet. D’après les auteurs Nah et Lau (2000), il ne doit pas
seulement arbitrer, il doit faire acte de présence et effectuer un suivi rigoureux pendant toute
la durée du projet. Pour l’entreprise C, il aurait fallu impliquer un nombre moins important
d’acteurs afin d’arbitrer plus facilement. « Mais ça c’est dû à la multiplicité des acteurs car
quand il y en a moins c’est plus facile de se mettre d’accord. »
35
L’entreprise B quant à elle, met en avant un autre problème, celui de la direction qui a
voulu répondre aux différents besoins des métiers en acceptant l’ensemble des demandes des
opérationnelles même si celle-ci n’étaient pas importantes. « La direction pensait que si les
opérationnels faisaient la demande, c’est que c’était important, et donc ils en avaient besoin »,
le souci est que la plupart du temps les opérationnels demandaient des « choses farfelues »
comme un « logo sur une facture » et cet ajout prenait parfois pour cette entreprise plusieurs
semaines à mettre en place, synonyme de perte énorme de temps et d’argent. Comme il le dit,
à l’époque il n’avait pas eu le courage de dire « il le faut vraiment le logo ? »
La sélection de l’ERP
Une des entreprises a dû faire marche arrière concernant le choix de l’intégrateur.
Après un an et demi de réunions sur l’intégration des processus dans la solution, la direction a
choisi de rompre le contrat avec le nouvel intégrateur et reprendre le contrat avec l’ancien.
Comme le budget estimé, avait été dépassé, l’entreprise n’a pas voulu continuer. Pour les trois
entreprises, le budget est un facteur à prendre aussi en considération dans le choix de l’ERP.
Elles parlent toutes les trois de dépassement de budget. Le budget doit être estimé, clair et
précis dans l’étude préalable.
Pour une des entreprises (Entreprise B), la sélection de l’ERP n’a pas fait l’objet d’une
étude préalable suffisamment détaillée, ce qui peut être un risque d’après Lequeux (2011).
L’entreprise ne voulait pas perdre de temps et d’argent vu qu’elle connaissait déjà la solution
qu’elle souhaitait adopter. SAP était le leader sur le marché depuis des années et l’ensemble
des filiales avaient déjà adopté SAP comme logiciel de référence, elle n’avait pas vraiment le
choix. De plus, l’entreprise avait déjà contracté avec l’éditeur SAP : « Nous avions déjà
négocié un prix de licence contenue de la masse ». Ce qui a permis à l’entreprise
d’économiser sur la partie choix de l’intégrateur qui est souvent très longue et très cher car
elle fait intervenir un certain nombre de consultant externes : « Et cette démarche a durée au
moins 6 mois et un an avant un cahier des charges avaient été écrits » comme l’explique
l’entreprise C. Contrairement à l’entreprise B, l’entreprise C n’a pas voulu mettre en avant de
solution même si elle connaissait le leader sur le marché : « On veut garder les choses
ouvertes donc on va prendre un cabinet de consultant qui va nous aider à proposer une offre
très ouverte », mais cette procédure est très longue puisqu’elle a durée plus de 10 mois. A la
fin de cette période, les différents responsables ont lu l’intégralité des mémoires écrits par les
36
consultants dans le but de choisir une solution. Il y a eu plusieurs phases de décisions pour au
final retenir deux solutions SAP et ORACLE, les deux leaders sur le marché. L’entreprise
mentionne aussi le fait de ne pas prendre un petit intégrateur qui risquerait d’être mangé par
un des leaders, ce qui poserait un problème. (Entreprise C)
Pour l’entreprise B, les présentations par les intégrateurs sont parfois irréels, ils sont en
concurrence avec d’autres intégrateurs et souhaitent obtenir le contrat avec l’entreprise. C’est
pourquoi lors de la présentation de leur solution, ils jouent sur les fonctionnalités : « sur le
papier tous les ERP savent tout faire, après le diable est dans le détail ». Quand l’entreprise
commence à mettre en place le logiciel, elle se rend compte que ce n’est pas du tout comme
l’entreprise croyait. « Ce produit va vous apporter de la qualité et puis quand on arrive dans la
vraie vie on a du mal à faire en sorte que les explications et le paramétrage du produit cale
avec l’organisation »
Deux entreprises sur trois parlent de l’adoption d’une stratégie claire et qui doit rester
inchangée pendant la durée du projet comme les auteurs Wong et Tein (2007) l’expliquent
dans leur étude. « La stratégie de l’entreprise, elle est fixe » (Entreprise C)
Les trois entreprises mentionnent la partie périmètre (scope) à bien définir lors de la
sélection de l’ERP : « un périmètre doit être très clair et il faut s’y tenir » (Entreprise A). Les
processus organisationnels de l’entreprise doivent être définis correctement et doivent être mis
à plat pour permettre aux intégrateurs de bien comprendre les processus cibles des entreprises.
(Entreprise C et A).
Une des particularités de l’entreprise A, c’est sa superficie mondiale et le fait qu’elle
comporte des filiales. Pour chaque filiale qui a un besoin, il va d’abord être traduit en interne
et c’est l’équipe de coordination qui va prendre la décision de la solution à adopter. Une étude
va être faite en fonction de la taille, les moyens et les besoins de la filiale. L’entreprise va
regarder par rapport à ses standards en interne pour le choix du logiciel.
L’entreprise C a dû choisir la solution qui répondait à son architecture technique. L’un
des intégrateurs souhaitaient changer tous les ordinateurs de l’entreprise afin d’adapter le
produit à l’entreprise. Le choix de cette solution aurait coûté beaucoup d’argent.
L’architecture technique de l’entreprise peut être un facteur de choix de l’ERP.
37
La composition du groupe de projet
Acteurs internes : le chef de projet et les équipes
Pour trois entreprises, le groupe de projet ERP doit avoir des personnes compétentes
mais surtout des opérationnels, des gens du métier. Les entreprises expriment les mêmes
mots : « ce sont les métiers/opérationnels qui doivent porter le projet ». Un projet ERP est un
projet métier qui va chambouler les processus organisationnels métiers, ce sont les
opérationnels qui ont le plus de connaissance sur leur métier.
Les trois entreprises ont souligné aussi le fait que ces opérationnels doivent sortir de
leur métier en les remplaçant par des personnes externes afin que l’opérationnel travaille
uniquement sur le projet. Pour l’enterprise A, c’est essentiel pour que le projet ne pas perdre
l’adhésion des opérationnels au projet. Dans l’entreprise C, des comités utilisateurs sont
organisés pour demander les besoins spécifiques des utilisateurs et pour pouvoir
communiquer sur le projet.
Une des entreprises (entreprise C) n’a pas détaché ces opérationnels par manque de
budget. Le problème par la suite est que les opérationnelles n’avaient pas de disponibilités
pour s’occuper du projet, ils devaient faire ça en plus de leur quotidien. C’est un vrai
problème pour communiquer avec les intégrateurs qui ne vont pas avoir la réponse à leurs
questions : "Je voudrais avoir une réponse dans les deux jours parce que c’est contractuel
mais il ne l’aura pas dans les deux jours parce que vous avez d’autres choses à faire et que
vous ne pouvez pas forcément faire passer le projet en premier" (Entreprise C). L’entreprise
doit avoir des ressources spécifiques allouées au projet.
Les deux autres entreprises ont remplacé leurs opérationnels par des personnes en
intérim. L’entreprise B a développé un groupe de projet avec deux types d’acteurs appelés
« CPU : chef de projet utilisateurs » pour l’équipe métiers et « CPI : chef de projet
informatique » pour l’équipe informatique. La difficulté pour l’entreprise a été « de trouver
des personnes pour instruire, décrire et bien l’expliquer au CPI qui doit comprendre le
besoin ». Celui-ci devait vérifier ensuite que le besoin qu’il avait exprimé était bien intégré
dans la solution. (Entreprise B). Contrairement à cette entreprise, les responsables de domaine
de l’entreprise C n’avaient pas de ressources pour le projet et chacun des responsables
pouvaient choisir ou non l’implication de ses équipes au processus projet.
38
Les trois mentionnent aussi la nécessité d’avoir une équipe de projet compétente avec
une gouvernance de projet définie à l’avance : "il faut des gens qui aient une expérience réelle
des projets ERP car ceci ne s’improvise pas, que ce soit IT ou business, donc il faut avoir des
gens qui se sont déjà cassés les dents sinon on va droit dans le mur" (Entreprise A).
L’interviewé parle aussi de quelqu’un qui a « une très bonne compréhension des enjeux
business une capacité à coordonner, à fédérer, à contrôler, à communiquer », qui doit être
leader du projet (Sumner, 2000)
Acteurs externes : les consultants externes
Les trois entreprises sont d’accords sur le fait qu’il faut éviter au maximum de prendre
des consultants externes. Ceci est en contradiction avec Florescu et Dumitru (2007) pour qui
l’intégration des consultants externes constitue un facteur clé de succès.
Pour l’entreprise B, Il est préférable d’écarter les intégrateurs et de maitriser
l’intégration de l’outil pour les problèmes de montées de version ou les incidents techniques
(Entreprise B). L’entreprise ne voulait pas que les consultants aient la main sur la totalité du
projet, ils préféraient faire porter le projet aux opérationnels.
L’entreprisse A ne va pas forcément prendre beaucoup de consultants externes, quand
une de ces filiales aura un besoin particulier, elle va regarder si elle n’a pas déjà un standard
en interne capable de répondre au besoin, car elle a beaucoup de solutions déjà développées
au sein de son organisation : « parfois évidemment on fait appel à des externes pour des
spécificités d’expertises ou bien parce qu’on n’a pas le temps ». De plus, les consultants n’ont
pas à avoir de pouvoir de décision. Comme l’explique les auteurs Markus, Axline and al.
(2000), ce non-pouvoir des consultants externes va souvent amener à des conflits sévères
entre les consultants et la direction de l’entreprise.
Les consultants externes n’ont pas de connaissances sur l’organisation et sont souvent
spécialisés dans un seul domaine (Entreprise B), ce qui confirme l’idée des auteurs Markus,
Axline and al. (2000) sur le fait que les consultants externes doivent être intégrés à
l’entreprise pendant toute la durée du projet. Parfois les consultants externes jouent sur
l’incompétence des entreprises en matière d’informatique. Ils ne sont pas spécialisés dans tous
les domaines de la solution et ils vont avoir une « zone de confort ». C’est un problème pour
l’intégration de la solution d’après l’auteur Sumner (2000), le consultant doit être spécialiste
39
du logiciel et des modules en question. S’ils ne connaissent pas un point spécifique, ils vont
dire à l’entreprise que ce n’est pas possible (Entreprise B). Ceci rejoint l’idée de l’entreprise
C, les consultants doivent connaitre les métiers opérationnels des entreprises : « aller mettre
les mains dans le cambouis » pour comprendre les processus de l’entreprise. Ces points de
vue sont en phase avec l’étude de Lemaire (2002) qui indique que les consultants externes ne
connaissent pas le métier de l’entreprise.
Pour finir, il ne suffit pas d’avoir seulement de consultants externes compétents, il faut
aussi une bonne gouvernance projet avec l’organisation de points projets pendant toute la
durée du processus. L’entreprise A organisait des « Steering Commitee » qui se traduisent par
des comités de direction où des acteurs clés vont choisir une méthodologie de projet qui va
permettre l’avancement du projet. Un point non évoqué dans la littérature.
La redéfinition des processus métiers
Pour les trois entreprises la mise en place d’un ERP va chambouler entièrement les
processus métiers : « L’objectif d’un projet ERP c’est une transformation du processus métier
à des fins d’efficacité » (Entreprise A) comme le mentionne les auteurs (Gomez, Frot et al.,
2002).
Les entreprises A et C parlent de standardisation et d’homogénéisation des processus
métiers dans l’organisation pour intégrer les besoins de l’organisation au sein de la nouvelle
solution. Le problème pour l’une des entreprises (Entreprise C), c’est que ces processus
étaient extrêmement mal écrits et ils ont dû faire des centaines d’ateliers pour remettre à jour
leurs processus. Ce qui leur a coûté énormément d’argent car ils ont fait intervenir des
consultants externes qui n’arrivaient pas à comprendre leur processus « L’intégrateur qui était
face à nous avait du mal à comprendre processus mal définis au départ, difficulté de
l’intégrateur ». L’entreprise A, recommande d’utiliser des outils « BPM business project
manager » dans lesquels ils vont modéliser leurs processus métiers, faire le lien entre les
processus métiers et leur implémentation dans la solution. C’est pourquoi certains auteurs
comme Gunasekaran et Kobu (2012) et Ng, Ip et Lee (1999) ont réfléchi à la conception de
modèles pour la redéfinition de processus. Dans tous les cas, les trois entreprises insistent sur
le fait que les processus doivent être mises à jour avant l’intégration de la solution, ce qui
s’aligne avec l’idée des auteurs Markus, Axline, et al. (2000).
40
Pour la redéfinition des processus métiers, il faut avoir bien compris le travail des
opérationnels, il va falloir aller sur le terrain pour réfléchir à savoir comment réorganiser les
processus. (Entreprise B). Un autre résultat des trois auteurs est que cette redéfinition des
processus va engendrer une grande « résistante aux changements », l’entreprise A a voulu
aligner l’ensemble des principaux processus à l’ensemble de ses filiales dans le monde.
L’Allemagne a été totalement contre car elle avait mis en place un ensemble de processus
aligné avec leur métier :
« pour autant il y a eu des batailles, parce que chaque filiale avait son ERP notamment les
importantes filiales en Allemagne, qui avaient des solutions SAP avec des spécificités, et
quand on est arrivé avec notre « core » modèle qu’on a voulu déployer, il y a eu des
guerres terribles, entre la solution allemande qui était parfaite, automatisée pour les besoins
de l’Allemagne et le « core » process européen qui les énervait tant le business process que
la solution IT, il y a eu à la fois des rejets d’utilisation de la solution, des batailles entre
informaticiens, ça a été très difficile, des cas comme ça il y en a beaucoup. » (Entreprise A)
La formation
Deux entreprises sur trois (A et B) parlent de faire appel à des sociétés de conseil pour
la formation des équipes comme les auteurs Gomez, Frot et al. (2002) et Wong et Tein (2007).
Il est préférable que ce soit des acteurs externes qui prennent en charge une partie de la
réorganisation des processus métiers : « il y avait une réelle organisation de change
management avec des consultants spécialisés qui faisait la communication qui travaillaient sur
des livrables particuliers, se déplaçaient », ceci pour aider et suivre les opérationnels dans
toute la démarche de déploiement. De plus, les consultants externes sont des spécialistes de la
solution (deux le mentionnent). Les trois insistent sur le fait que des équipes de formateurs
doivent être présents sur le terrain pour leur expliquer les nouvelles démarches et éviter que
les opérationnels soient résistants envers le changement. « Il faut du présentiel, accompagner
physiquement ». L’entreprise B insiste sur le fait que les consultants doivent aller sur le
terrain, directement auprès des opérationnels quelques jours pour mieux comprendre leurs
métiers. Pour l’entreprise A, il y a différents types de changement. Le changement qui va
permettre d’améliorer le travail des opérationnels et là, c’est souvent simple pour eux
d’accepter. Mais souvent, par exemple lors de la standardisation de processus, le changement
41
ne va pas améliorer la qualité de travail de l’opérationnel et dans ces cas-là, il est plus difficile
de faire accepter le changement aux équipes.
L’entreprise A mentionne qu’un turnover très élevé comme dans une de ses filiales en
Angleterre peut amener les utilisateurs à ne plus être formés sur la solution et à faire de la
résistance au changement. Les auteurs Markus, Axline and al. (2000) ajoutent qu’ils auront
plus de difficulté à utiliser le logiciel et ils feront plus d’erreurs : « C’est parce que il y a une
perte d’efficacité de la solution qui est liée à un turnover dans la filiale et qui n’est pas
imputée au système en tant que telle mais à organisation de la filiale […] qui fait que
aujourd’hui ils ne maitrisent plus forcément l’usage de ça et derrière ça génère des risques tant
de fraudes que de perte de CA »
L’entreprise C quant à elle rejoint la conclusion des auteurs Markus, Axline, et al.
(2000) sur le fait qu’il est impossible pour les responsables de domaine de pouvoir s’occuper
du budget et planning des formations car la plupart du temps ils n’ont pas le budget nécessaire
pour les mettre en place. Il a été demandé au responsable de domaine de l’entreprise C
d’écrire les plans de formation, les documents mais eux même n’ont aucune connaissance sur
ce logiciel et n’ont pas le budget et les ressources supplémentaires pour l’effectuer. Les
utilisateurs vont devoir apprendre à utiliser le nouveau logiciel sans formation au préalable, ils
vont être amenés à mal l’utiliser, ce qui va être non productif pour l’entreprise. « Donc en
conséquence ça va être comme l’ancienne solution, les gens vont devoir apprendre sur le tas,
on ne va pas avoir de documentation et on va mal utiliser le produit et on en sera pas
performant et en plus il va y avoir de la résistance aux changement ». Or l’entreprise C n’avait
déjà pas effectué de formation sur son ancienne solution et certains des opérationnels ne
voulaient plus utiliser la solution et revenaient à utiliser les tableaux Excel. Ce résultat
corrode avec les résultats des auteurs Wong et Tein, (2007) sur le fait que les formations
doivent être disponibles et encouragées pour réduire la résistance au changement des
utilisateurs.
L’entreprise C parle aussi de « stress » des utilisateurs face au nouveau logiciel : « Les
gens vont être frustrés ça va déclencher un facteur de stress énorme. Donc à l’époque où on
parle beaucoup de risques psychosociaux, c’est un élément très stressant et très risqué sur le
personnel ». Ceci est aligné avec les conclusions de Ruzé (2003). C’est pourquoi la
responsable de domaine de l’entreprise C nous a indiqué qu’elle a impliqué l’ensemble de ses
collaborateurs depuis le début du projet pour qu’ils participent aux phases de test avec les
42
intégrateurs et à la définition des besoins. Ils ont pu de cette manière-là avoir un premier
aperçu de la solution et les principaux mécanismes : « Moi je sais que je ne vais pas avoir la
formation donc j’implique le plus de monde que je peux avant pour qu’il est contact avec le
produit avant que je l’ai ». Un autre problème évoqué par l’entreprise C qui n’a pas été vu
dans la revue de la littérature se pose, les utilisateurs non formés, demanderont aux
développeurs des corrections sur le logiciel pensant que la fonctionnalité n’est pas
implémentée, au final l’entreprise se rendra compte du contraire, qui se traduit par une perte
du temps, d’argent et d’efficacité de la solution. « On a demandé il y a dix ans des spécificités sur
des choses qui existaient déjà mais on ne nous l’avait pas dit ». Pour finir, l’entreprise évoque
l’importance de mettre en place des personnes de support interne dans la DSI pour la
maintenance applicative afin de résoudre le type de conflit précédemment décrit.
Problème de pertinence des informations
Pour les trois entreprises, ce sujet n’a pas vraiment fait beaucoup débat. Seule
l’entreprise C a évoqué le problème. Lors de son premier projet de mise en place de SAP, elle
avait voulu réorganiser ces données et nettoyer sa base de données pour récupérer seulement
les informations pertinentes, un des facteurs clés de succès de la mise en place d’un ERP
d’après l’auteur (Ruzé, 2003). Mais vu que la solution SAP n’a pas été adoptée et que
l’entreprise n’effectue à l’heure actuelle seulement qu’une montée de version de la solution
ORACLE, elle va récupérer l’ensemble des historiques de données qui sont stockées dans le
logiciel depuis plus de dix ans : « Vous avez des choses pas utiles dans votre machine vous
êtes obligé de les maintenir parce que vous avez un historique qui tourne dessus donc il y a un
moment c’est super embêtant de ne pas pouvoir dire on nettoie »
L’entreprise évoque aussi le problème des utilisateurs qui sont réticents à l’utilisation
du logiciel et qui réutilisent aujourd’hui les tableaux Excel, les informations peuvent se
retrouver en double ou bien ne pas être retranscrites dans la solution. Pourtant les
informations dans ce type de solution sont indispensables pour la prise de décision des
responsables de domaine comme l’explique les auteurs Markus, Axline, et al. (2000) dans leur
analyse.
43
La personnalisation de l’ERP
Premièrement, c’est l’un des points qui a été le plus discuté lors des trois entretiens.
Nous pouvons en déduire que c’est un problème majeur dans le processus de mise en place
d’un ERP.
Les trois entreprises A, B et C comme les auteurs Markus, Axline, et al. (2000)
recommandent aux autres entreprises de ne pas customiser leur ERP, c’est-à-dire ne pas faire
de spécificités. La customisation cause ensuite des problèmes de mise à jour à chaque
changement de version. Les trois entreprises ont été amenées à customiser leur ERP : « il ne
faut pas le customiser, et chez AL on a fait l’inverse, c’est-à-dire qu’on a hautement
customisé à un point » (Entreprise A). L’ancienne version de l’entreprise C n’avait pas été
mise à jour depuis plus de 10 ans à cause des nombreuses spécificités que l’entreprise avait
adoptées. A l’époque, le logiciel avait été spécifié par des développeurs au sein de
l’entreprise, si bien qu’il est aujourd’hui impossible de le mettre à jour.
Normalement d’après l’entreprise A, il faut prendre la solution standard donnée par
l’éditeur et il faut intégrer et implémenter ces processus à l’intérieur et non le contraire, ce qui
conduit au résultat des recherches des auteurs Markus, Axline, et al. (2000) : « Dans un ERP
vous avez une solution sur étagère, normalement la bonne pratique c’est que vous prenez ce
qui vous est fourni et vous vous débrouillez avec pour votre business » (Entreprise A). Le
problème dans la plupart des entreprises est que le standard ne leurs convient pas : « Chez A,
ce qui est fourni ne va pas et on le tripote dans tous les sens, on fait beaucoup de spécifiques
et comme vous dites quand on fait des montées de version c’est compliqué, et derrière quand
vous voulez les maintenir, c’est compliqué car vous oubliez que on a touché à quelque
chose. » Souvent l’entreprise fait intervenir les opérationnels et chaque opérationnel souhaite
avoir une customisation différente de la solution. Comme l’utilisateur doit être maître de
l’application, l’entreprise B a par exemple été obligée de customiser l’ensemble des demandes
des utilisateurs : « L’utilisateur dit : moi sur le reporting je veux que mon logo tienne sur ma
facture. C’est un casse-tête dans SAP pour mettre un truc comme ça. Il n’est pas facile de le
configurer sur les formulaires SAP »
Pour l’entreprise A, il faut quand même relativiser, la customisation est possible et
souvent nécessaire car toutes les entreprises ne peuvent pas avoir des processus standards. Il y
a deux types de customisation, une plus risquée que l’autre, la customisation que l’entreprise
déploie à l’ensemble des opérationnels « Standard versus spécifique » et celle où l’entreprise
44
souhaite faire un spécifique seulement pour quelques acteurs dans une filiale ou un
département « Convergence versus localisation ». La première est plus simple car tout le
monde va adopter cette spécificité et pour les montées de version il y aura le même problème
pour tout le monde alors que pour la deuxième il y aura des spécificités différentes pour
chaque type d’acteur.
Pour éviter ce problème, l’entreprise C a choisi d’intégrer différents logiciels à l’ERP
global afin d’être plus flexible. Mais d’après les conclusions des auteurs Markus, Axline, et
al. (2000) qui évoquent cette même solution, le problème est que cette interface entre
plusieurs logiciels va mener à des pertes de données et de temps.
La communication
Seulement deux entreprises sur trois mentionnent ce facteur clé de succès qui est
pourtant l’un des plus importants d’après l’auteur Sumner (2000).
La conclusion de l’entreprise A est qu’il faut communiquer l’ensemble du déroulement
du projet et de ne pas oublier l’ensemble des départements comme la comptabilité et la
finance (Entreprise C), si l’entreprise ne souhaite pas avoir une grande résistance au
changement. Il ne convient pas seulement de dessiner de nouveaux processus métiers, il faut
les communiquer et réussir à les vendre aux personnes qui travaillent depuis plusieurs années
sur une autre application. Il faut leur montrer que ça va apporter une valeur ajoutée à leur
travail et une meilleure productivité (Entreprise A). Ces conclusions rejoignent le point de
vue de Worou (2008), la communication et l’implication de la direction générale sont vecteur
d’adhésion au projet et limitent les résistances.
Les nouveaux FCS établis par les entreprises
Au cours de nos différents entretiens, nous avons découvert d’autres facteurs clés de
succès que nous souhaitions détailler car ces FCS paraissaient importants à prendre en
considération
Les trois entreprises (A, B, C) ont toutes les trois voulu discuter du déploiement de la
solution (Comment et quand déployer la solution etc.). Aucune ne fait le choix du « big
45
bang » : bascule de l’intégralité de l’entreprise à une date t. Dans les deux premières, elles
expriment l’importance de choisir des filiales pilotes et de déployer la solution dans un
premier temps en interne dans les filiales et dans un deuxième temps de l’étendre à l’ensemble
de l’entreprise. Il faut pouvoir effectuer les premiers tests et ne pas paralyser l’ensemble de
l’entreprise si la solution ne fonctionne pas.
Pour l’entreprise A, le choix de la filiale est crucial : « Il faut choisir quelque chose
d’assez représentatif mais pas trop grand pour ne pas que ça casse dès l’entrée ».
Pour l’entreprise B, la durée de vie du test de déploiement dans la filiale doit être
longue avant de donner une conclusion. C’est avec le temps que les premières modifications
sont à apporter et non pas dès le premier jour, il faut laisser le temps aux filiales pilotes
d’utiliser le logiciel. « Les filiales pilotes, il faut les laisser vivre et voir si ça fonctionne. Il
faut avoir la capacité à prendre du recul sur les filiales pilotes, pour avoir un retour. Il faut les
suivre et aller les voir régulièrement. C’est vrai que le pilote on ne l’a pas laissé vivre assez
longtemps »
L’entreprise C a mis en avant le fait qu’il faut bien choisir la date du déploiement de la
solution dans une filiale ou un département. Les intégrateurs souhaitaient déployer la solution
en janvier au moment de la clôture des comptes annuels. « Et nous on était farouchement
contre du fait du nombre de modules à changer et si on fait une bascule au 1er janvier on ne
pourra pas clôturer nos comptes au 31 janvier. Et si on a changé de version et que nos
programmes où on fait nos structures ne marchent pas bien on ne pourra pas clôturer nos
comptes. »
Dans un autre contexte, l’entreprise B a aussi parlé d’habilitation et de gestion des
droits qui pour le responsable n’ont pas été bien gérée lors de l’intégration de la solution. Pour
lui il aurait fallu avoir un chef de projet « IT » et un autre « métier » sur ce sujet : « Il aurait
presque été nécessaire d’avoir un CPU et un CPI (mais cela n’a pas été le cas), je pense que
c’est une erreur dans notre cas de figure. Après ça élève les coûts, il faut aussi comprendre »
La conclusion de la mise en place
Deux entreprises sur trois sont satisfaites de leur solution ERP :
46
L’entreprise A exprime: « le succès de l’entreprise a été de laisser l’initiative au terrain
pour gagner du business et construire des choses». L’entreprise souhaitait centraliser les
principaux processus informatiques et elle a réussi : « le projet OPERA qui a été structuré et
qui a été lancé il y a maintenant 14-15 ans, a révolutionné le paysage en tuant les DSI locales
et en réintégrant les IT. ».
La troisième après un premier échec de la solution SAP attend l’intégration de la
solution qui est prévue pour le domaine comptabilité et finances en mars prochain. De ce fait,
nous avons demandé à cette entreprise s’il était possible d’interroger deux futurs utilisateurs
de la solution dans le domaine de la comptabilité pour connaître leurs ressentis à propos de
l’échec du premier projet et leurs implications dans le nouveau projet.
Pour cette entreprise le nouveau projet, ne va pas forcément faire apparaître de grandes
améliorations. Les possibilités sont moindres par rapport au premier projet SAP : « Là où l’on
partait avec l’espoir d’améliorer nos processus fonctionnels et de faire d’importants
changements fonctionnels et bien là on est obligé de revoir nos espérances à la baisse. Et
l’utilisateur, quand il change de projet, il espère ne pas avoir de régressions fonctionnelles là
où ça marchait bien ».
Les deux utilisatrices que nous avons eues par téléphone nous ont fait comprendre que
pour elles, il ne s’agissait plus d’une « nouvelle solution » mais seulement d’une « montée de
version de l’ancienne solution Oracle » pour passer d’une version « Oracle 11i à Oracle r12 »
et qu’il n’y avait plus de grands changements fonctionnels : « SAP aurait été un grand
changement, on aurait pu créer la mobilisation dès le départ et non pas à la fin, ça aurait été
différent ». Le seul changement serait l’interface Web de l’application qui leur permettrait de
pouvoir utiliser une version du pack office plus récente celle de 2010.
Au niveau de l’implication, elles mentionnent toutes les deux qu’elles sont totalement
impliquées au sein du projet. Elles participent aux différentes phases de tests : « nous
participons aux différents tests avec les consultants ORACLE ». Elles doivent toutes les deux
remplir des fiches tests et peuvent exprimer les différentes évolutions qu’elles souhaitent
trouver dans la nouvelle application. Elles participent également à des comités appelés
« réunion de transfert de compétences » qui leur permettent d’avoir une vue sur la nouvelle
application.
Pour conclure notre étude exploratoire, nous voyons que ces six facteurs clés de succès
sont sources de grandes discussions dans les entreprises et doivent être évoqués avant le début
47
du projet. Quatre facteurs clés ressortent sur les six (L’implication de la direction générale, la
personnalisation de l’ERP, la redéfinition des processus métiers, le choix de l’ERP). Et les
questions de personnalisation de la solution et la redéfinition des processus métiers sont les
plus discutées.
48
V. Conclusion
L’échec des entreprises dans l’implémentation de leur ERP, est un sujet qui a été traité
dans de nombreux travaux académiques. Depuis les années 90, les entreprises mettent en
place rapidement des logiciels ERP afin de pouvoir être plus performantes et ne pas perdre
leur place sur le marché vis-à-vis de la concurrence. Les entreprises ne prêtent pas souvent
attention aux différents risques qui peuvent intervenir lors de la mise en place d’une solution.
Pourtant ces projets ont besoin d’être planifiés et évalués car ils peuvent affecter le
fonctionnement et la performance de l’organisation.
Notre but était de mieux comprendre les divers problèmes organisationnels et
techniques rencontrés dans une entreprise lors du déploiement d’une solution ERP. L’étude
ayant pour objectif final de retracer l’ensemble des facteurs clés de succès établis dans la
littérature par les auteurs, de les évaluer et de les faire valider par les acteurs de la DSI
interrogés lors d’une étude qualitative. Cette étude pourra servir à d’autres entreprises qui
souhaitent déployer une solution ERP afin de minimiser le risque d’échec de leur projet ERP.
Pour arriver à répondre à notre problématique, nous avons dans une première phase
étudié de nombreux articles concernant l’étude des ERP dans les entreprises. Nous nous
sommes rendus compte que les différents auteurs identifiaient les mêmes facteurs clés de
succès. C’est pourquoi, nous avons établi un tableau retraçant l’ensemble de ces FCS décrits
par les différents auteurs. Nous avons identifiés six FCS (L’implication de la direction
générale, la sélection de l’ERP, le choix du groupe de projet, la redéfinition des processus
métiers, la personnalisation de l’ERP, la communication) qui étaient les plus étudiés dans la
littérature. Nous avons aussi effectué le lien entre les FCS et les différentes phases d’un
projet ERP (l’étude de l’opportunité, l’implémentation, la conduite du changement, les
améliorations) ce qui nous a permis de mettre en avant à quelle étape du projet les FCS
doivent être pris en considération.
La seconde phase de l’étude consistait en une phase exploratoire, grâce aux facteurs
clés de succès identifiés dans la première partie, nous avons pu concevoir un guide
d’entretien. Nous avons conduit une étude qualitative basée sur ce guide d’entretien. Trois
entretiens ont été menés, auprès de trois personnes membres des équipes projets ayant
travaillées au déploiement d’un ERP au sein de trois entreprises différentes : une entreprise
dans le secteur de l’énergie, une autre dans le gaz et une dernière dans la géologie. Le but était
49
de comprendre leurs différents problèmes lors de l’intégration de leur solution SAP ou Oracle.
Nous avons eu la chance aussi d’interviewer deux utilisateurs de l’entreprise du secteur de la
géologie et connaître leur implication pendant le projet.
Les résultats de cette étude ont permis de confirmer l’importance de certains facteurs
clés dans le processus d’implantation d’un ERP. L’implication de la direction générale, le
choix du groupe de projet, la redéfinition des processus métiers, la personnalisation de l’ERP
sont les sujets les plus abordés. Les entreprises ont toutes les trois confirmé l’importance du
lancement d’un projet ERP et du changement organisationnel que celui-ci entraine. Deux
entreprises sur trois ont mis en avant les nouveaux besoins technologiques (de mobilité, de
personnalisation) et de la difficulté de l’ERP classique trop rigide et trop cher sur le marché :
« Aujourd’hui, l’ERP monolithique ne répond plus aux enjeux de transformation des métiers
nécessaires pour faire face aux révolutions digitales ». Les entreprises cherchent de nouvelles
solutions beaucoup moins contraignantes et coûteuses avec des solutions ERP en mode Saas
(Software as a service) qui intègre les 4 nouveaux piliers des entreprises digitales (Social
Media, Mobile, Analysis et Bigdata, cloud) qui va permettre à l’entreprise d’être moins rigide,
de pouvoir customiser plus facilement sa solution. L’ERP classique va tendre à disparaître
d’ici quelques années pour laisser place un ERP plus hybride répondant à ces nouveaux
besoins.
Notre étude comporte certaines limites dues au fait de ne pas avoir pu étendre
l’enquête sur un plus grand nombre de chefs de projet et d’utilisateurs d’une part, et
d’entreprises de secteurs d’activités diverses d’autre part. Notre recherche avait pour cible les
chefs de projet. De futures recherches pourraient être conduites en ciblant de nouveaux types
de population : les membres de la direction générale, les cabinets de conseil ou les éditeurs de
logiciel qui délivrent le projet et ceci afin d’avoir une vision de chacune des parties
prenantes.
50
Bibliographie
Alter, S. (1979). Implementation risk analysis. TIMS Studies in Management Sciences, 13(2),
103-19.
Besson, P. (1999). Les ERP à l’épreuve de l’organisation. Système d’Information et
Management. 4, 21-51.
Bingi, P.S., Maneesh K. et al. (1999). Critical issues affecting an ERP implementation.
Information Systems Management, 16(3), 7-14.
Boodhoo, R. et Purmessur, R. (2009). Justifications for Qualitative Research in Organisations:
A Step Forward. The Journal of Online Education (New York), Available at SSRN:
http://ssrn.com/abstract=1325607
Carmen B., Vital, R. (2010). Leadership, sourcing modes and IT project management.
Canadian Journal of Administrative Sciences (John Wiley et Sons, Inc.), 27(4), 348-362.
Chaabouni, A. (2006). Implantation d’un ERP (Enterprise Resource Planning) : antécédents
et conséquences. AIMS, XVème Conférence Internationale de Management Stratégique,
Annecy / Genève 13-16 Juin 2006.
El Amrani, R., Rowe F. et al. (2003). PGI et Flexibilités dans les moyennes et grandes
entreprises, Colloque DARES.
El Amrani, R. (2003). Vision organisationnelle cible comme facteur de réussite d'un projet
ERP: le cas SAP chez l'entreprise Consto. 8 ème colloque de l'AIM, Grenoble.
Esteves, J., Pastor, J., Casanovas, J. (2002). Measuring Sustained Management Support in
ERP Implementation Projects. Conference on Information Systems.
Figuières, C. (2001). Internet, un tremplin pour les ERP. Les Echos, l’Art du Management.
Florescu, V., Dumitru, V. (2007). L’implantation de l’erp : facteurs cles du succes et impacte
sur la performance. The Annals of the University of Oradea, Economic Sciences series - Tom
XIX, 4(1), 1353-1347
Forbes. (2013). Gartner's ERP Market Share Update Shows The Future Of Cloud ERP Is
Now. http://www.forbes.com/fdc/welcome_mjx.shtml
51
Gilbert P., Leclair P. (2004). « Les systèmes de gestion intégrés : une modernité en trompe-
l’œil ? ». Sciences de la Société, 61, 17-30
Gomez, M.L., Frot, B., et al. (2002). Quels effets organisationnels pour les erp ? Xi ième
conférence de l'aims, paris.
Gunasekaran, A., Kobu, B. (2002). Modelling and analysis of business process reengineering.
int. j. prod. res., 40(11), 2521-2546.
Hazebrouck, J.M. (1993). «Les facteurs clés de succès dans le management de projets». Revue
Internationale en gestion et management de projets, 27-40
Hawari, A., Heeks, R. (2010). Explaining ERP failure in a developing country: a Jordanian
case study. Journal of Enterprise Information Management, 23(2), 135-160
Herr, B. (03/04/2014). Rapport annuel 2013 du PCS : résultats contrastés. http://www.erp-
infos.com/info_article/m/1987/rapport-annuel-2013-du-pcs--resultats-contrastes.html
Hofer, C. W., Schendel, D. (1978). Strategy Formulation: Analytical Concepts. St. Paul, MN:
West Publishing Co.
Hoffman, T. (2007). Global ERP. Computerworld, 35-40.
Huang, S., Chang, I. et al. (2014). Assessing risk in ERP projects: identify and prioritize the
factors. Management and Data Systems, 104(8), 681-688.
Lemaire, L. (2002). “Systèmes ERP, emplois et transformations du travail”. Fondation
Travail – Université ASBL.
Lequeux, J.L. (2011). Manager avec les ERP : Architecture Orienté Services. Edition
Eyrolles.
Leroy, C. (27/10/2011). EDITO - L'avenir de l'ERP s'appelle le cloud.
http://www.cxp.fr/content/news/edito-lavenir-de-lerp-sappelle-le-cloud
Maaloul, I., Mezghani, L. (2003). L'implantation des ERP et ingénierie du changement : Les
déterminants de la satisfaction des utilisateurs d'un ERP dans les entreprises tunisiennes.
XIIème Conférence de l'Association Internationale de Management Stratégique.
Markus, M., Axline, S. et al. (2000). Learning from adopters’ experiences with ERP:
problems encountered and success achieved. Journal of Information Technology, 15, 245–
265.
52
Nah, F., Lau J. (2000). Critical factors for successful implementation of enterprise systems.
http://www.mcbup.com/research_registers,
Ng, J. K. C., Ip, W. H. et al. (1999). A paradigm for ERP and BPR integration. International
Journal of Production Research, 37(9), p2093-2108.
Panorama Consulting. (2013). 2013 ERP REPORT. http://panorama-
consulting.com/resource-center/2013-erp-report/
Peaucelle, J.L. (1999). Les conditions d’efficacité du BFR. IAE de Paris (Université Paris 1 •
Panthéon - Sorbonne), GREGOR.
Rabaai, A. (2009). Identifying Critical Success Factors of ERP Systems at the Higher
Education Sector. Queensland University of Technology (QUT).
Redouane, E., Frantz, R. et al. (2006). Effets de la stratégie de déploiement des PGI sur la
vision transversale de l’entreprise. Revue Française de Gestion, 168/169, 267-285.
Ruzé, E. (2003). Changement organisationnel et implementation des tic : pourquoi faire
attention aux dimensions économiques de la gestion du savoir dans le cas des erp ? VSE : la
revue de l'économie et de l'entreprise.
Ross, J.W. (1999). Surprising Facts About Implementing ERP. IEEE IT Pro, 65-68.
Saint-Leger G., Beeler, B. (2012). Emergence d’une culture négociée dans le cadre des projets
ERP. Revue Management et Avenir, 53.
Shanks, G., Parr, A., et al. (2000). Differences in critical success factors in ERP systems
implementation in Australia and China : A cultural analysis. In Proceedings of the 8th
European Conference on Information Sytems, 3-5, 537-544.
Strauss, Anselm L. (1978). Negotiations. Varieties, contexts, processes, and social order.
Sumner, M. (2000). Risk factors in enterprise-wide/ERP project. Journal of Information
Technology (Routledge, Ltd.), 15(4), 317-327.
Verville, J., Halingten, A. (2003). The effect of team composition and group role definition.
Team performance Management: an international Journal, 9(5/6), 115-130.
Wee, S. (2000).”Juggling toward ERP success: Keep key success factors high”. ERP News.
53
Wilfrid, A., Tarek, M. (2013). Évaluation des projets de système d’information : une approche
par les options réelles. Recherches en Sciences de gestion, 96, 69-89.
Wong, Dr., Tein, D. (2007). Critical Success Factors for ERP Projects.
Worou, R.D. (2008) Impact des pratiques de gestion des ressources humaines sur
l’acceptation de l’ERP dans les entreprises en Afrique : cas de deux entreprises en Afrique de
l’Ouest. Association francophone de Gestion des Ressources Humaines.
Ziemba, E., Obłąk, I. (2008). Critical Success Factors for ERP Systems Implementation in
Public Administration. Interdisciplinary Journal of Information, Knowledge, and
Management, (8), 2013.
