ERP Et RH

Maison des Sciences de lHomme (MSH)
Universit de Nantes (LAGON)

Ecole des Mines de Nantes (EMN)
Impact sur lorganisation et les

conditions de travail des nouveaux modes
de gestion reposant sur les ERP/PGI
Synthse
Auteurs de ltude :
Bndicte Geffroy-Maronnat
Marc Bidan
Redouane Elamrani
Frantz Rowe
Synthse rdige par Denis Brard (Charg de mission ANACT)- novembre 2005 Tous droits rservs www.anact.fr
Sommaire
A. ENJEUX, OBJECTIFS, HYPOTHSES ........................................................................................................................................... 3

I. ENJEUX DE LA CONDUITE DU CHANGEMENT ORGANISATIONNEL FACE LVOLUTION DES SYSTMES DINFORMATION ET
DE LA COMMUNICATION ........................................................................................................................................................................... 3
I.1 Un nouveau jeu plus complexe dacteurs ................................................................................................................................ 3
I.2 Lenjeu revisit de lintroduction des utilisateurs dans la conception................................................................................... 3
II. MTHODOLOGIE GNRALE: CONTEXTE ET PROCESSUS .................................................................................................................... 4
II.1 Un contexte multidimensionnel et multi-acteurs .................................................................................................................... 4
II.2 Les processus de changement ................................................................................................................................................. 4
III. OBJET DE LTUDE ............................................................................................................................................................................. 5
IV. PROBLMATIQUE ET HYPOTHSES ..................................................................................................................................................... 5
IV.1 LERP est-il facteur de changements organisationnels et sociaux ? ................................................................................... 5
IV.2 La conduite dun projet ERP ................................................................................................................................................. 9
IV.3 Les effets de la conduite du changement sur les usages, les performances et les conditions de travail .......................... 12
IV.4 Les effets, la conduite du changement et la corrlation des deux phnomnes dpendent du contexte ........................... 14
V. MTHODOLOGIE ................................................................................................................................................................................ 15
V.I. Une mthodologie fondamentalement qualitative et croisant le regard des acteurs ........................................................ 15
V.II. Le choix des techniques de recueil des donnes ................................................................................................................. 15
Traitement qualitatif des donnes et rgles de dcisions pour lhypothse numro 3 .............................................................. 16
B. TEST DES QUATRE HYPOTHSES DU MODLE DE RECHERCHE ................................................................................. 17
HYPOTHSE 1 LERP COMME TECHNOLOGIE DE RUPTURE ............................................................................................................... 17
HYPOTHSE 2 LES FACTEURS DE LA CONDUITE DE PROJET SONT-ILS MOBILISS ?........................................................................... 18
HYPOTHSE 3 LES EFFETS DE LA CONDUITE DU CHANGEMENT SUR LES USAGES ET LES PERFORMANCES ....................................... 20
Caractristiques des cas considrs comme succs ............................................................................................................. 20
Caractristiques des cas considrs comme semi-succs .................................................................................................... 20
Le rle de la conduite de projet dans le succs constat............................................................................................................ 21
HYPOTHSE 4 LES EFFETS, LA CONDUITE DU CHANGEMENT ET LA CORRLATION DES DEUX PHNOMNES DPENDENT DU
CONTEXTE. .............................................................................................................................................................................................. 23
C. CONCLUSION GNRALE............................................................................................................................................................. 24
E. RFRENCES DANS LE DOMAINE ET BIBLIOGRAPHIE.................................................................................................... 26
Synthse rdige par Denis Brard (Charg de mission ANACT)- 2005 Tous droits rservs rseau Anact
A. Enjeux, Objectifs, Hypothses

I. Enjeux de la conduite du changement organisationnel face lvolution des systmes
dinformation et de la communication
Lanticipation des effets sociaux et organisationnels des nouveaux outils intgrs de gestion
constitue un nouvel enjeu majeur pour lentreprise et ses acteurs sociaux.
En effet, historiquement, on a dabord automatis et rduit les cots, donc avec une certaine matrise et
sans ncessit dinnover dans la conduite du changement organisationnel. Tout au plus, fallait-il
affronter les syndicats sur les postes perdus. Linformatisation sest le plus souvent adapte aux
structures de lorganisation existantes avant de les transformer peu peu, ce qui sest traduit pour les
utilisateurs finaux par une volution forte des postes de travail et une transformation de la structure des
emplois (diminution du back-office, des fonctions intermdiaires) et des qualifications demandes.
I.1 Un nouveau jeu plus complexe dacteurs
La taille des projets et le rythme de linformatisation poussent aujourdhui les entreprises ne plus
dvelopper leurs logiciels elles-mmes mais les externaliser. Les Directions des Systmes
dInformation (DSI) conservent une capacit de conseil, dintgration et dexploitation. Cependant elles
perdent aussi beaucoup de pouvoir au profit des directions gnrales et de consultants extrieurs en
stratgie, auxquels celles ci font appel. Ces cabinets venus plus rcemment aux technologies de
linformation sont souvent peu sensibles aux aspects touchant le travail. Paralllement, dans les grandes
entreprises, les matrises douvrage se sont renforces en comptences informatiques. Tout ceci affaiblit
la capacit daction de la DSI en mme temps que la complexification de la technologie lui laisse une
part dexpertise considrable sur ce plan. Dans ce contexte, nombre dacteurs peuvent prtendre
accompagner le changement organisationnel. Ce peut tre les diteurs qui appliquent alors une mthode
maison cense rgler ce problme mais sur le papier seulement : car de laveu de beaucoup dentre
eux, cest au client de dcider de dgager des ressources internes ou externes. Dans la pratique, on
constate que ces ressources ne sont gnralement dgages qu la suite de la constatation de problmes
que lon regroupe pudiquement sous le voile de la rsistance au changement .
Des travaux prcdents on montr que ces problmes sont la rsultante dun dficit danticipation du jeu
des acteurs et dune difficult de lquipe de concepteurs communiquer sur le projet avec les parties
intresses. Les technologies de linformation ainsi que dautres outils dorganisation (rgles de gestion,
plans, runions, etc.) pourraient aussi tre intgrs dans le processus de conception. Mais hlas,
concrtement, les entreprises raisonnent plus souvent comme si la technique seule tait la solution aux
problmes organisationnels. Autrement dit, il ny a pas vritablement de rflexion socio-technique au
sens du Tavistock Institute : les projets dinvestissement du type ERP ne sont pas vus comme des
projets organisationnels.
I.2 Lenjeu revisit de lintroduction des utilisateurs dans la conception
On le sait depuis longtemps dj : la participation et limplication des acteurs sont au cur du processus
de changement organisationnel. Dune part, les nouvelles technologies sont plus conviviales et
accessibles aux utilisateurs et permettent de faire du prototypage rapide pour tester lexpression des
besoins. Dautre part, le risque dune participation plus dmocratique mais nadhrant pas au projet
augmente avec lintgration des systmes et lvolution vers une entreprise tendue comprenant des
acteurs aux maturits stratgique et organisationnelle trs diffrentes. On saperoit ainsi que les
commerciaux ne sont gnralement pas associs aux projets de commerce lectronique des entreprises
justement parce quils peroivent quInternet pourrait bouleverser la relation au client et in fine leur
mtier. Nous rejoignons ici lhypothse principale de cette tude : le facteur humain dans sa dynamique
collective constitue le facteur cl de succs du processus dinvestissement. Cet enjeu capital nest pas
seulement un problme dappropriation dans lutilisation, mais du fait du caractre de plus en plus
stratgique des projets, cest bien un problme de conception.
II. Mthodologie gnrale: contexte et processus

Pour penser les effets des technologies de linformation sur le travail et aboutir des mthodes ou
approches raisonnables de conduite du changement, nous pensons quil faut quitter lapproche
uniquement centre sur le poste de travail et les tches de lutilisateur final pour sintresser davantage
au systme dorganisation qui conditionne la performance du systme dinformation. Pour nous, le
systme dorganisation est la fois un contexte organisationnel comprenant le systme dinformation et
un processus de changement.
II.1 Un contexte multidimensionnel et multi-acteurs
Lambivalence des rsultats des recherches sur le contenu des impacts organisationnels des systmes
dinformation sexplique souvent par un contexte multi-dimensionnel et une perception diffrente selon
les acteurs. Par exemple sur le plan des structures, le degr de centralisation parat tre une variable
intressante. Ainsi il a t montr que les rseaux ont eu des effets centralisateurs dans les banques
dcentralises et inversement. Cest pourquoi il est illusoire de produire des connaissances stables en la
matire sans spcifier le contexte du changement. Les recherches focalises sur le contenu ont souvent
une valeur descriptive intressante quant lobjet et lintensit du changement organisationnel mais
leur capacit explicative, voire prdictive est trs faible. En revanche, la prise en compte du contexte
historique, dun type de structure organisationnelle, de secteur conomique, de pays, de valeurs
culturelles, permet de comprendre des rsultats empiriques souvent diffrents voire contradictoires.
Lappropriation et la conception des outils au sein dune population dentreprises ou dans une
organisation sont lies un contexte quil faut examiner dans toutes ses dimensions (stratgie, structure,
tches, systme dincitation, acteurs). La conduite des effets du changement organisationnel passe
ncessairement par un diagnostic complet sur toutes les dimensions du contexte organisationnel dans le
primtre du projet. Ce contexte organisationnel fait systme dans la mesure o les contraintes des
diffrentes dimensions ne sont pas indpendantes entre elles de sorte que le vritable changement ne
peut souvent soprer que par une action conjointe sur plusieurs dimensions tenant compte des
perceptions des parties intresses.
II.2 Les processus de changement
Il reste frappant de constater que dans des contextes apparemment semblables des technologies
identiques produisent la fois des effets identiques sur certains aspects du travail et de lorganisation et
des effets bien distincts sur dautres. On retrouve ces distorsions dans les impacts des technologies au
sein dune mme organisation. Le systme dorganisation ne peut donc se rduire la seule prise en
compte du contexte. Il est aussi li au processus et la conduite du changement organisationnel.
La littrature a toujours mis laccent sur le problme de lassociation et de laccompagnement des
utilisateurs la dfinition du nouveau systme, mais galement sur ceux de la structure projet, des
mthodes dvaluation et des mthodes de dveloppement elles-mmes en insistant sur lintrt des
mthodes de prototypage. Avec le dveloppement de projets de progiciels de gestion intgrs, lintrt
de recherches examinant plus finement les processus de changement sest fortement dvelopp ces
dernires annes.
III. Objet de ltude

Lobjectif de ltude est de contribuer faire avancer la connaissance et la pratique sur la conduite du
changement des projets ERP/PGI par lexamen de quatre hypothses :
La mise en vidence des consquences de lutilisation de lERP sur le travail et
lorganisation (cf. H1)
Lanalyse de la conduite de projet ERP et la conduite du changement associe (cf.
H2)
Etudier la corrlation entre la conduite de projet mise en uvre pour implanter lERP et
les consquences observes sur le travail et lorganisation (cf. H3)
Et ce en fonction du type dentreprise et de son contexte (cf. H4)
Le schma suivant prsente le modle de la recherche et notamment les hypothses et les dimensions
qui sont analyses :
Contexte organisationnel et technologique
(H4)
Conduite de projet
(H2)
Effets et usages ex
post (H1)
Relation(s) (H3)
Figure : modle de recherche
IV. Problmatique et hypothses

IV.1 LERP est-il facteur de changements organisationnels et sociaux ?
Lanalyse du phnomne tudi est difficile car il ressort de plusieurs tudes que, dune part, lon ne
peut pas ignorer le contexte dans lequel sinscrit le changement (pour une technologie donne, les effets
observs dun cas un autre peuvent tre diffrents) et dautre part, les effets organisationnels observs
ne sont pas les mmes selon la technologie considre.
LERP soulve cet gard un grand nombre dinterrogations concernant son impact sur lorganisation et
les acteurs. En tant que nouvelle technologie de linformation, nous pouvons supposer que lERP a une
influence sur le mode dorganisation et de fonctionnement de lentreprise. Mais au-del de cette
influence, compte tenu des caractristiques vhicules par lERP, nous pouvons lentrevoir comme une
technologie de rupture avec les formes dorganisation traditionnelles et les mtiers existants.
Lhypothse 1 est les questions drives :

Y a-t-il des impacts tous les niveaux organisationnels
Y a-t-il un changement global
Y a-t-il un changement fort du contenu du travail
Y a-t-il un changement fort pour la hirarchie intermdiaire
Y a-t-il un changement dans la rpartition des responsabilits
Y a-t-il un changement dans les reprsentations des
utilisateurs
Rupture
Oui ?
Oui ?
Oui ?
Oui ?
Oui ?
Oui ?
ERP et niveaux organisationnels

Les entreprises sefforcent, depuis longtemps, dintgrer par les technologies de linformation et de la
communication les diffrentes fonctions. Avec lERP, leur rve dintgration informatique est enfin
ralis. Plus encore, il constitue pour les dcideurs un vecteur potentiel de mise en cohrence globale du
fonctionnement de lentreprise. Il leur offre la promesse dune meilleure coordination dans la mesure o
elle aura t pense, organise et outille. Les caractristiques intrinsques de lERP laissent supposer
que les diffrents niveaux organisationnels vont tre impacts :
Inter-organisationnel : la mise en place dun module de CRM va toucher la gestion et la

nature des relations de lentreprise avec ses clients.
Organisationnel : lERP peut constituer une opportunit pour modifier la structure de
lorganisation - passer dun mode dorganisation hirarchico-fonctionnelle un mode
organis en processus - rduire les niveaux hirarchiques - ou encore centraliser/dcentraliser
les fonctions.
Groupe : lERP se structure sur la base de trois formes dinterdpendance : squentielle
(loutput de la fonction amont constitue linput de la fonction aval), de pool (les fonctions se
partagent la base de donnes unique), rciproque ou en boucle (laction de A dclenche
laction de B qui en retour r enclenche laction de A). Ces formes dinterdpendance
viennent bouleverser le systme de relation et de pouvoir entre les fonctions et les acteurs. De
mme, la nature et lintensit des changes entre les entits couvertes par lERP vont tre
modifies.
Individuel : lERP touche diffrentes dimensions du travail : parcellisation, contenu des
tches, autonomie, responsabilit, contrle
A cet gard, lampleur du changement associ lERP peut tre apprhende de deux faons : En
analysant un niveau donn, la profondeur du changement observ Ou/et en valuant, le niveau le plus
touch par limplantation dun ERP.
Un ensemble de travaux a jusqu prsent davantage prsent de faon globale les effets des ERP
considrant lorganisation comme un ensemble homogne. A ce titre, il nous semble aujourdhui
important dvaluer quel est le niveau organisationnel potentiellement le plus impact par lERP.
[Hypothse H.1.1 : Les niveaux organisationnels ne sont pas impacts par lERP selon la mme
ampleur]
ERP et diffrenciation organisationnelle

LERP pose la problmatique de lalignement de lorganisation sur les processus de lERP. Comme le
souligne Bouillot (1999) le succs rside dans la recherche dun juste quilibre entre une adaptation
coteuse du progiciel lorganisation existante et la reconfiguration brutale des processus pour
saligner sur ceux de lERP choisi. A contrario, un certain nombre dchecs sexplique en partie par le
msalignement entre lorganisation et lERP. Par ailleurs, il nest pas pertinent de continuer
considrer lentreprise comme un tout homogne. Notamment, certaines fonctions se caractrisent par
un degr de diffrenciation plus important au regard dautres fonctions dont leur contexte est gouvern
par des standards et des rglementations sectorielles, nationales voire internationales. Nous pouvons
ainsi supposer que lampleur du changement sera plus faible dans les fonctions se caractrisant dj par
un faible degr de diffrenciation cest--dire les fonctions de back office (administration gnrale)
rgies par des processus de gestion standards telle comptabilit/finance, contrle de gestion. En
revanche, pour les fonctions se caractrisant par un fort degr de diffrenciation (front office et
processus industriels), lentreprise sera amene modifier profondment ses faons de travailler afin
que ses rgles de gestion soient conformes ceux de lERP.
Lusage de linformatique dans certains fonctions et auprs de certaines catgories dacteurs est trs
rpandu. De ce point de vue, la population des organisations nest pas homogne. Ainsi limplantation
de lERP va-t-elle affecter plus particulirement les fonctions et les individus (magasiniers par exemple)
qui sont les moins familiariss avec linformatique de gestion. Les changements induits par
limplantation de lERP sont plus locaux que globaux et ils sont trs ingaux suivant les services. Ce
constat parat relativement banal au dbut de la vague dimplantation des ERP. Mais quen est-il dans
les entreprises qui les ont largement dploys ? (effet du contexte H4).
LERP se caractrise par une forme dinterdpendance squentielle. Ainsi loutput de la fonction amont
devient linput de la fonction aval. Ce nest pas lERP mais le fonctionnement de lentreprise qui
prdfinit ces relations dinterdpendance entre les fonctions. LERP ne fait quintroduire une
structuration plus rigoureuse et rigide de ces relations. Mais ce faisant, ce systme va dstabiliser et
redistribuer le pouvoir des entits. Notamment, il va limiter les marges daction de certaines fonctions
qui vont se retrouver en situation de stricte dpendance, linverse dautres fonctions vont voir leur
poids renforc. L aussi, lintensit du changement ne sera pas ressentie de la mme faon par les entits
en fonction du degr dautonomie perdue.
[Hypothse H.1.2 : Lampleur du changement est diffrente selon les fonctions. Les changements
induits par lERP sont plus locaux que globaux.]
ERP et Organisation du travail
Conformment aux tudes portant sur les conditions de travail des salaris ayant recours
linformatique, la dmarche consistera analyser les dimensions du travail modifies par lERP et se
demander si ces volutions sont en rupture avec la division taylorienne du travail ou si elles prolongent
les principes du taylorisme. En effet, des tudes ont montr que les salaris utilisant un systme
informatique sont davantage soumis des rgles. LERP sur cet aspect est trs contraignant dans la
mesure o son fonctionnement effectif dpend de la qualit des donnes codifies et du respect des
squences dactions. En revanche, il offre un accs plus autonome et rapide linformation permettant
une plus grande autonomie des utilisateurs dans laccs linformation. Est-ce pour autant que les
utilisateurs gagnent en autonomie daction et de dcision ? Nous nous interrogerons ainsi sur les
nouvelles formes dautonomie et de contrle associes la mise en place des ERP.
LERP modifie galement les relations dinterdpendance entre les acteurs. En effet, les contraintes
dinterdpendance vhicules par lERP vont introduire a priori une rationalisation et une rigidification
des relations entre les entits. Nous chercherons ainsi dterminer limpact de ces contraintes
dinterdpendance sur la charge, le rythme de travail et la vigilance des utilisateurs.
Enfin, on tentera didentifier les marges de manuvre dont disposent les utilisateurs en rponse ces
contraintes (rgles, interdpendance). On cherchera identifier, entre autres, le poids des procdures
informelles et les Feuilles Excel ad hoc reconstitues par les utilisateurs.
[Hypothse H.1.3 : ladoption dun ERP entrane une modification du contenu du travail]
ERP et hirarchie intermdiaire
Dans cette partie de ltude, on tentera danalyser limpact de lERP sur le rle de la hirarchie
intermdiaire. Son rle de superviseur est-il renforc par la traabilit et le contrle quil en dcoule ?
En ayant accs des donnes en temps rel et fiables, son rle de dcideur (activit de pilotage) est-il
renforc ? Sa libert daction est-elle limite du fait dune contrainte plus importante par les autres
fonctions ?
Enfin, partant de lhypothse que lvaluation sur des rsultats chiffrs est facilite avec lERP, la
hirarchie intermdiaire est soumise un renforcement du contrle.
[Hypothse H.1.4 :Le rle de supervision et de pilotage de la hirarchie intermdiaire est renforc.]
ERP et structuration des responsabilits
La mise en place dun ERP va supposer que soient clarifies les relations entre les fonctions et les
acteurs de lorganisation cest--dire qui fait quoi en termes de rpartition des tches et de
responsabilit. Cette structuration de lorganisation porte par la normalisation des donnes constitue en
soi un projet dingnierie organisationnelle. Il sagit de structurer les droits daccs la base de donnes
en dfinissant pour chaque chane dactivit la distribution des tches et les niveaux dhabilitation
(consultation, validation, modification, impression). Une prcdente tude du Lagon a soulign que pour
diffrentes raisons (faible implication, problmes de comptences informatiques, absence pralable de
rflexion sur cette cartographie des droits daccs), cette cartographie constitue une phase du projet ERP
dont les enjeux sont souvent sous-estims. A lextrme, cette structuration organisationnelle implicite se
traduit par une dcentralisation des niveaux de responsabilit. En dautres termes, les niveaux
dhabilitation associs lERP ne correspondent plus avec ceux de lorganigramme traditionnel de
lentreprise do des sources potentielles de conflits.
[Hypothse H.1.5 : En labsence de rflexion pralable, lERP constitue un vecteur de dstabilisation
de lorganigramme de lentreprise.]
ERP et reprsentation des utilisateurs

En tant que systme intgr, lERP oblige thoriquement les utilisateurs modifier leur reprsentation
fonctionnelle de leur systme de travail au profit dune approche plus transversale du fonctionnement de
leur activit. La sensibilisation des utilisateurs cette dimension est capitale. LERP exige que les
utilisateurs sinsrent dans une vision globale du fonctionnement de lentreprise cest--dire quils
soient capables dapprhender limpact de leurs dcisions et des saisies sur les autres fonctions.
Lappropriation de cette nouvelle reprsentation se manifeste entre autres par une vigilance accrue.
Cependant, il ny a pas de dterminisme technologique dans cette relation. Le processus dintroduction
de lERP notamment les modalits de la conduite du changement sont essentielles lvolution de la
reprsentation du systme de travail des utilisateurs.
[Hypothse H.1.6 : lERP modifie la reprsentation fonctionnelle du systme de travail des utilisateurs.]
IV.2 La conduite dun projet ERP

Le processus de mise en uvre dun projet ERP
Le modle dvelopp par Markus et Tanis (2000) concernant le processus dimplmentation des
systmes dentreprises (Entreprise Systems), dont lERP fait partie, nous semble adquat pour
comprendre et expliquer les diffrentes questions souleves par le phnomne ERP.
Ce modle est conu en 4 phases :
Formulation du
problme
et choix de lERP
Ingnierie
Dploiement
Usages et
effets
Figure : le cycle de vie dun projet ERP
Formulation du problme et choix de lERP (Chartering ) : durant cette phase

lopportunit dacqurir un ERP est examine sous langle des besoins de lentreprise et de
lamlioration de sa performance. Les impacts de cette acquisition sur lorganisation et la
stratgie de lentreprise sont dfinis et estims par la direction gnrale.
Ingnierie ( Project) : cette phase comprend toutes les activits permettant de rendre
lERP oprationnel dans les diffrents services concerns. Les activits de paramtrage et de
configuration de lERP y sont particulirement cruciales. Cest aussi ce stade que sont
conduites les oprations de redfinition des processus et raliss les dveloppements spcifiques.
Limplmentation dun progiciel ERP ncessite un travail de prparation en amont qui consiste
dterminer les donnes fixes, le nombre de sites et de points de vente par exemple, partages par
tout le monde et les donnes variables, spcifiques des situations particulires susceptibles de
varier et dvoluer.
Dploiement (Shakedown) : dernire phase du projet, il concerne les activits

dinstallation de lERP, le basculement de lancien SI, et la formation des utilisateurs. Le
dploiement peut tre fait plus ou moins progressivement (par module, puis par site par
exemple) ou de manire plus rapide (big-bang: tous les modules et tous les sites en une seule
fois ). Par ailleurs, une priode dexploitation sous contrle de lquipe projet permet de corriger
les dysfonctionnements et doptimiser le systme. Cest au cours de cette phase que ladquation
des fonctionnalits de lERP aux processus organisationnels de lentreprise se concrtise. Le
dploiement sachve avec la clture du projet ERP.
Usages et effets (Onward and Upward) : le ERP entre maintenant en exploitation

oprationnelle, et la recherche dune amlioration de son fonctionnement passe par des cycles de
maintenance. Lentreprise peut se lancer dans de nouveaux projets intgrant de nouvelles
applications (CRM, SCM, e-business).
Ces diffrentes phases correspondent au cycle de vie de lERP et peuvent tre vues comme un processus
continu durant lequel plusieurs tches, activits et dcisions sont ralises et prises. Ce modle est
conu dans une approche longitudinale qui permet dtudier le processus dimplmentation et
dutilisation de lERP dans une approche de cycle de vie qui comprend la dcision initiale dadoption,
limplmentation, les premires phases dutilisation du systme, lintgration de loutil au sein de

lorganisation et enfin les oprations de maintenance et les futures montes de versions.
Diversit et variabilit des dimensions de la conduite du projet ERP

Plusieurs tudes et recherches acadmiques ont mis en vidence plusieurs facteurs cls lis au cycle de
vie de lERP qui peuvent avoir un effet sur lorganisation du travail de lentreprise. Nous supposons que
les facteurs de la conduite dun changement diffrent dun projet un autre (H.2). Ainsi, nous allons
nous intresser aux facteurs suivants :
1- Limplication et le soutien de la direction gnrale : en principe ils doivent avoir lieu
tout au long du projet ; mais est-ce bien le cas ? Vu la nature transversale de ce type de projet
et les sommes dargents investis, limplication de la direction gnrale ressort comme
llment stratgique. Nous supposons que limplication et le soutien de la direction gnrale
sont mobiliss tout au long du projet (Hypothse H.2.1). Au-del de lallocation des
ressources ncessaires, sa participation llaboration des processus dcisionnels est forte
(Hypothse H2.2).
2- Les objectifs de la direction gnrale concernant la mise en place dun ERP qui se
traduisent par la dfinition dune vision organisationnelle cible ; les tudes de cas dj
ralises dans le cadre dtudes prcdentes ont montr que ce facteur tait rarement pris en
compte par les dirigeants lors de la premire phase consacre la formalisation du problme
et au choix de lERP. Il serait ainsi trs utile de vrifier si les dirigeants des PME ont accord
plus dattention ce facteur dterminant quant au succs du projet. De mme, le niveau
dimplication relle des utilisateurs dans la dfinition de lorganisation cible supportant
loutil est trs faible (Hypothse H2.3), mme si les utilisateurs sont souvent appels dans la
phase de formulation du problme et du choix de lERP fournir de linformation permettant
de dfinir cette organisation cible (Hypothse H2.4) et les fonctionnalits de loutil
(Hypothse H2.5).
3- La diversit dans la composition et les comptences de lquipe projet (et plus
particulirement celles du chef de projet, des utilisateurs cls, des informaticiens et des
consultants externes) devrait tre forte (Hypothse H.2.6). La littrature portant sur les ERP a
souvent class ce facteur en deuxime rang tout de suite aprs limplication de la direction
gnrale et le considre comme garant de la qualit des dcisions et des actions qui seraient
engages ultrieurement.
4- La couverture fonctionnelle : ce facteur fait rfrence au primtre organisationnel
touch par lERP et donne une ide sur lampleur des changements raliser. Lorsque la
couverture fonctionnelle est large et touche la presque totalit des fonctions et services de la
compagnie, le projet ERP est hiss un niveau stratgique et implique des changements
profonds. Cest pourquoi il est important de tester si la couverture fonctionnelle est forte
(Hypothse H2.7). En revanche, lorsque lERP est choisi pour couvrir quelques fonctions de
support concernant des processus standards, les considrations stratgiques deviennent
secondaires, et lampleur des changements venir est plus faible.
5- La ringnierie des processus : un projet ERP saccompagne souvent dune redfinition
des processus. Cette tche complexe et dlicate de la reconfiguration supposant de concilier
la faon dont lentreprise souhaite travailler et celle dont le systme lui permettra de le faire
est dterminantes dans la russite du projet (Hypothse H.2.8). Ce processus de prparation
de lorganisation en amont par les acteurs du projet, internes et externes, qui consiste
dcider de ce qui doit tre global, commun et partag par tout le monde et de ce qui doit tre
local, spcifique et susceptible de varier selon les volutions de lenvironnement dtermine la
phase de paramtrage et le modle organisationnel intgr dans lERP.
6- Le processus de paramtrage et des dveloppements spcifiques est une des
caractristiques techniques de lERP sinscrivant dans une logique de diffrenciation et
dadaptation de lERP aux besoins et ralits de lentreprise. Ce facteur dpend la fois du

travail effectu en amont sur les processus, les procdures et rgles de gestion de lentreprise
et des comptences techniques et organisationnelles (mtier) des personnes charges de cette
tche. La qualit du partenariat ce niveau entre les consultants est les utilisateurs cls et/ou
informaticiens est garante de la qualit et de la pertinence du paramtrage ralis. Nous nous
intresserons galement aux stratgies adoptes par lentreprise pour configurer leur ERP :
soriente-t-elle dans un paramtrage fin ou bien se contente-t-elle dun paramtrage
standard ? (cf IV.3)
7- La stratgie de dploiement adopte (par tape ou en big-bang) : deux tactiques de
dploiement peuvent tre adoptes : Big-Bang ou progressif. Le dploiement progressif est
ralis par module et/ou par site. Dans le cadre de cette approche, lexpression des capacits
dintgration des PGI est souvent limite. Le changement nest pas profond car les processus
organisationnels impacts ne concernent quune partie de lorganisation. En revanche, avec
le dploiement en big-bang, lentreprise fait le choix dune mise en uvre en bloc de tous les
modules du PGI sur tous les sites et les effets sur lorganisation et le travail des utilisateurs
sont trs importants. Cest pourquoi il est important de tester si les entreprises adoptent une
stratgie dimplantation en Big-Bang (Hypothse H.2.9).
8- La politique dhabilitation de lentreprise : lexistence de ce facteur, durant la conduite
du projet, peut nous renseigner sur les anticipations des concepteurs concernant la politique
de centralisation et de dcentralisation engage par la direction gnrale et du degr de
responsabilisation et dautonomie attribu aux utilisateurs travers laccs ou non des
modules et des zones de travail diffrents (Hypothse H.2.10).
9- Laccompagnement du changement : la conduite du changement est fondamentale pour
la russite dun projet ERP (Hypothse H.2.11). Elle est aussi importante que la mise en
oeuvre du progiciel. Afin de comprendre et danalyser la politique daccompagnement du
changement technique et organisationnel de lentreprise au cas ou elle existe, nous
adopterons la dmarche utilise par De Dreuzy et Akoka, qui se dcline en sept champs de
questionnement :
les dirigeants dune part et lquipe de projet dautre part ont-ils engag une rflexion
sur les processus changer ? Ont-ils analys les impacts par population pour
dterminer les besoins daccompagnement adquats ?
ont-ils identifi les rsistances au changement et programm les journes de formation
(technique et mtier) ncessaires ? (H.2.11.1),
ont-ils fournit la documentation adquate ? (H.2.11.2)
ont-ils instaur une politique dassistance des utilisateurs travers la cration par
exemple dune entit de help desk (H.2.11.3).
une politique de communication a-t-elle t mise en uvre ? (H.2.11.4), ds les
premiers pas du projet jusqu lintgration de lERP dans les routines de lentreprise.
quelle valuation de lergonomie des modules de lERP installs (tests des maquettes
par les utilisateurs et laddition de nouvelles fonctionnalits par exemple) ? (H.2.11.5),
quel degr dadaptation lorganisation locale (suivi de lvolution des contextes

locaux) et de la gestion sociale (la politique de recrutement, de reconversion et de
reclassement des utilisateurs) ? (H.2.11.6).
Une fois que lERP est install, les utilisateurs commencent sen servir dans leur travail quotidien. A
ce niveau, dautres variables viendront rguler le processus de changement et dadaptation de
lorganisation du travail loutil. Dans ce cadre, nous allons voir dans quels cas les formations assures
au cours de lutilisation de lERP et les ventuelles modifications et changements techniques et
fonctionnels qui peuvent intervenir ont un effet sur lorganisation du travail de lentreprise. Le
processus dappropriation des connaissances li directement lexploitation de lERP (diffrentes
fonctionnalits de lERP, la navigation et les interactions entre les modules, etc.) et la nouvelle
organisation (rgles de gestion, nouvelles procdures, les processus, etc.) peut avoir aussi un effet sur
lorganisation du travail des utilisateurs.
IV.3 Les effets de la conduite du changement sur les usages, les performances et les
conditions de travail
Dans cette partie (hypothses H3), on cherchera essentiellement voir si les facteurs mis en vidence
par la partie prcdente (hypothses H2) ont un impact sur le succs de loutil. Pour cela, on suppose
que le niveau dimplication relle des utilisateurs et le recours eux comme source dinformation dans
la dfinition de lorganisation cible et les fonctionnalits de loutil favorise lusage, les conditions de
travail, mais aussi sa performance (H3.3) . Outre ces hypothses (H3.1 H3.11.6), nous supposons que
la capacit de lentreprise garder la matrise douvrage face aux partenaires est dautant plus faible que
lentreprise est de taille rduite ou quelle manque de comptences techniques (H3.12). A ce sujet, il
sera intressant dexaminer le cas dune entreprise de petite taille mais avec de fortes comptences.
Quant linfluence de lordre des tapes dans limplantation du progiciel (ordre des modules, mais aussi
pralable dun Business Process Reengineering) sur les usages et la performance (H3.13), nous
supposons quune phase antrieure de BPR ou tout au moins danalyse de lactivit de travail est
favorable dans la plupart des cas, mais quau niveau de lutilisateur, et notamment en PME, la russite
du projet passe dabord par lusage du nouvel outil avant toute recherche doptimisation des
performances par un changement de processus. Autrement dit que vouloir la fois changer lapplicatif
et le processus est une erreur. Ce qui reste tester.
Par ailleurs, pour garder les caractristiques particulires de lentreprise, les quipes de projet tentent
dintroduire des adaptations lERP slectionn surtout lorsque leurs processus standards narrivent pas
rpondre aux problmatiques de gestion spcifiques chaque mtier et situation de travail. Cette
question des dveloppements spcifiques est galement un des facteurs cls de succs dun ERP
(H3.14). Nous avons montr dans une tude prcdente quils nuisaient la flexibilit de loutil, mais
aussi la flexibilit oprationnelle et stratgique. Toutefois, sur ce point, les rsultats que nous avons
obtenus tant travers les monographies que dans ltude qualitative sont difficiles interprter. Sur ce
sujet en particulier seul une tude qualitative approfondie pourrait permettre daller au-del. Il sagira,
dans la mesure du possible, dexaminer les adaptations apportes tant au progiciel lui-mme quaux
interfaces et de les resituer dans les stratgies dintgration du systme dinformation de gestion quaura
finalement adopte lentreprise volontairement ou non. Notre hypothse est que tant que lon reste sur
la mme version du progiciel, que les modifications sont bien circonscrites et que lentreprise a une
vision claire de sa stratgie dintgration, alors les dveloppements spcifiques nont pas deffets
ngatifs sur les usages notamment car ils permettent de maintenir des pratiques antrieures et sur la
performance (H3.15.1). En revanche, ils freinent les changements (H3.15.2).
Comment adapter un ERP au contexte spcifique de lentreprise

Configuration
Bolt-ons
Des crans masques

Reporting largi
Programmation de nouveaux
flux de travail
Users exits
Programmer lERP
Dveloppement des
interfaces
Modification du code source
Processus selon lequel lentreprise fixe et dtermine le paramtrage des processus et

transactions qui correspondent son modle organisationnel. (dfinir les structures
organisationnelles, crer les tats de gestion standards, les procdures excuter,
etc.)
Implmentation dune autre application informatique conue dans le mme
environnement de lERP et qui permet de rpondre un besoin particulier. (Logiciels
de trsorerie, logiciels de gestion des stocks selon les dimensions spcifiques des
produits, etc.).
Cration dcrans masque pour la saisie et ldition des donnes. (Intgrer trois
crans en un seul).
Programmation de nouvelles options de reporting et ddition des tats. (Crer de
nouveaux tats spcifiques un besoin prcis : tat des achats dune classe de
produits).
Crer des flux de travail non-standards. (Mettre en place un processus automatis de
validation des ordres de changement techniques).
Programmer une nouvelle fonctionnalit dans une interface ouverte (dvelopper une
fonction statistique pour des calculs mtriques).
Cration dune nouvelle application dans le mme environnement technique de
lERP sans changer le code source. (Une application rpondant une niche de besoin
impossible inclure dans la version standard de lERP).
Programmation de nouvelles interfaces pour faire communiquer lERP avec les
applications maintenues par lentreprise ou avec dautres modules des autres ERP.
(Interface entre SAP et le CRM doracle).
Changer les codes sources pour faire face un problme stratgique trs particulier
(modification du processus de la planification de la production)
Tableau : la typologie des choix dadaptation de lERP
Ces diffrents types correspondent aux choix que les entreprises ont faits lors de la mise en place de leur
ERP. Limpact sur lERP augmente au fur et mesure que la modification change le programme initial
et introduit de nouvelles fonctionnalits diffrentes de celles livres dans la version standard. Une
entreprise peut modifier son ERP en utilisant plusieurs combinaisons des degrs diffrents suivant le
contexte et les besoins exprims. Cependant, plus les modifications dans lERP sont importantes, plus
les efforts de maintenance sont considrables. Par exemple dans le cadre dune monte de version, les
ERP ayant subi des modifications poseront des problmes dadaptation car les efforts demands
sapparentent au dmarrage dun nouveau projet dimplmentation dautant plus quil serait difficile de
les faire communiquer avec les SI des autres partenaires.
Il sera en effet important dexaminer des manifestations de rsistance au changement , par exemple
travers le maintien de pratiques antrieures (utilisation ou cration de feuilles de calcul tableurs-), mais
aussi de les interprter. Est ce pour se rassurer tant que lERP nest pas encore rod ? Pour le
complter ? ou vritablement par ce quon nen veut pas que de telles pratiques sont mises en place ou
tout simplement prennises ? Sur ce point, nous nous contenterons de partir de ces dviances
apparentes pour voir en quoi elles sont contre-productives ou au contraire essentielles au bon
fonctionnement de lorganisation. Enfin, il y a la rsistance dune autre nature qui se manifeste par des
conflits ouverts et que nous avons connu sur un certain nombre de cas dERP. Ces types de conflits sont
nombreux et rsolus de faon diverses. Leur documentation reste toutefois dlicate, mais notre
hypothse est que la communication de la Direction Gnrale joue un rle capital dans cette affaire et
quelle nest pas mettre sur le mme plan que des actions plus classique daccompagnement du
changement (formation, documentation, assistance). Parmi celles-ci, il nous semble que le projet se
passe mal lorsque les ressources alloues la formation sont insuffisantes (H3.16).
IV.4 Les effets, la conduite du changement et la corrlation des deux phnomnes

dpendent du contexte
Tout projet ERP doit tre contextualis (Besson). En effet, lorganisation volue, prend des
dcisions, bouge, hsite, dcide, remet en cause une ide. et les situations changent incessamment.
Ainsi pour tudier les effets de la mise en place dun progiciel ERP sur lorganisation de lentreprise, il
est trs important de ne pas isoler le contexte global de lentreprise du processus dimplmentation de
lERP et des usages quen font les diffrents acteurs de lorganisation. Au-del de la dcision de la
direction gnrale dadopter un ERP, il serait intressant de caractriser lenvironnement (hostile ou
favorable) et dvaluer son impact sur le degr dimplication des futurs utilisateurs durant les diffrentes
priodes de cycle de vie de lERP (Hypothse H.4). Nous nous intresserons quatre types de contexte :
environnemental, organisationnel, culturel et technologique.
Le contexte environnemental se rfre des facteurs tels que le secteur dactivit, lintensit de la
concurrence, lincertitude perue de lenvironnement, etc. Ainsi la mise en place dun ERP peut diffrer
dun secteur dactivit un autre, par exemple la mise en uvre de lERP ne se droulera pas de la
mme manire dans un hpital public que dans une entreprise industrielle prive. De plus, les premires
gnrations dERP taient destines aux grandes entreprises du secteur industriel. Il est donc intressant
de tenir compte du secteur dactivit pour expliquer le choix de lERP et des modules installs ainsi que
leurs effets sur lorganisation de travail (H.4.1).
Le contexte organisationnel fait rfrence la taille de lentreprise, au type de structure adopte
(centralisation/dcentralisation, mono-site, multi-sites). Concernant leffet taille, nous supposons que la
conduite du projet dans les PME obit une gestion globale sous la houlette de la direction gnrale et
se dmarque dune gestion par programme adopte largement par les grandes entreprises (H.4.2). Nous
supposons que pour les entreprises centralises, lERP contribue un renforcement de la centralisation
de lorganisation (H.4.3). Pour les entreprises qui oprent sur des sites gographiquement disperss,
nous chercherons savoir si la conduite du projet a t centralise et impose ou dcentralise et si les
units locales ont dispos dune certaine autonomie locale de dcision (H.4.4).
Par ailleurs, de nombreux auteurs considrent que les spcificits culturelles sont dterminantes pour
ladoption et lutilisation dun ERP. Nous avons prcdemment pu constater que la mise en place dun
rfrentiel unique dun ERP peut se heurter aux cultures locales et notamment les logiques
professionnelles. Nous chercherons dans le cadre de cette tude vrifier leur existence, leur importance
et leurs effets sur la conduite du projet et durant la phase dexploitation de loutil (H.4.5).
Enfin, le contexte technologique dont nous cherchons apprhender les effets sur la conduite du projet
et les usages se caractrise par le degr de maturit du systme dinformation en place, savoir le mode
et lintensit de diffusion des TI dans lentreprise, et les caractristiques techniques du progiciel ERP
(volutivit, modularit, unicit de la base de donnes, paramtrage) (H.4.4).
V. Mthodologie
V.I. Une mthodologie fondamentalement qualitative et croisant le regard des acteurs
La dmarche retenue dans le cadre de cette tude est fondamentalement qualitative. Nous adopterons
une approche par tude de cas qui parat plus adapte pour accder la complexit de la configuration
des organisations et offre galement loccasion dtudier les relations et les vnements tels quils se
sont drouls dans les situations vcues par les acteurs.
Cette tude repose essentiellement sur 6 tudes de cas :
une grande entreprise ( noter que dans ce cas, nous tudierons plus particulirement les effets dlimits
un service ou une fonction primtre restreint),
des PMI dans des secteurs varis.
Le fait de choisir des cas aussi varis permet dobtenir des rsultats plus riches, de faire ressortir leurs
similitudes et leurs diffrences et de les relier aux contextes dans lesquels elles voluent.
Conformment ce choix mthodologique, il convient prsent de dfinir les techniques de recueil de
donnes.
V.II. Le choix des techniques de recueil des donnes

Dans cette recherche, deux techniques de recueil des donnes ont t retenues: entretien semi-directif
individuel pour collecter des donnes primaires et une analyse documentaire pour disposer de donnes
secondaires compltant et renforant les premires.
Collecte des donnes primaires
La mthode dinvestigation utilise pour la ralisation des six monographies de cette recherche repose
sur des entretiens semi-directifs raliss face face in situ. Les entretiens ont t mens partir dune
grille dentretien pralablement dfinie et structure par lquipe de travail. Ils concernent deux types
dacteurs de niveaux hirarchiques et de fonctions diffrentes : les concepteurs et les utilisateurs.
Les concepteurs du projet :
- des membres de la Direction (Directeur Gnral ou reprsentant, Directeur
Administratif et Financier, Directeur du Systme dInformation, Directeur des
Achats, Directeur de la Production, Directeur des Ressources Humaines),
- le chef de projet,
- les consultants des diteurs et des cabinets de conseil intervenant sur le projet,
- les utilisateurs cls
Les utilisateurs sont gnralement les employs habilits utiliser lERP dans le cadre de leur travail.
La confrontation des informations provenant de ces deux familles dacteurs est indispensable la
qualit, lexhaustivit et la cohrence des monographies.
Dans le cas dune volution sensible pendant la priode de recherche des conditions dutilisation de
lERP, nous avons men deux entretiens des priodes diffrentes avec une mme personne. Ces
entretiens semi-directifs ont dur entre une heure et deux heures. Nous ne les avons pas tous enregistr
in extenso pour avoir aborder certains sujets inhrents aux projets ERP mais toujours sensibles et
vecteurs potentiels de conflits (habilitations, pouvoir, rmunration, recrutement, formation, promotion,
participation, etc.).
La confrontation des perceptions et des informations recueillies auprs des deux familles dacteurs est
indispensable pour valuer, dune part, lexistence deffets et dautres part leurs degrs. De plus,
lapproche qualitative que nous nous proposons de suivre nous permettra de mettre en perspective
ladquation des objectifs des concepteurs avec les perceptions des utilisateurs et la compatibilit des
anticipations des premiers et des informations communiques aux seconds.
Collecte des donnes secondaires
Lutilisation des donnes secondaires complte les donnes recueillies auprs des acteurs internes et
externes de lorganisation. Les diffrents supports et documents raliss tout au long du processus de
changement ont t analyss: les comptes rendus des comits de direction, de pilotage et oprationnel,
journal interne, pages Intranet et Internet ddis soit lquipe de projet soit aux salaris de lentreprise
et aux diffrents partenaires etc.
Lanalyse de ces documents permet de reconstituer pour partie, les actions passes qui ont pu influencer
les diffrentes tape du processus de dploiement ainsi que les niveaux dutilisation de lERP au sein de
lentreprise. Cest en connaissant le pass de lentreprise quon peut le mieux apprcier et comprendre
le contexte actuel et les effets constats.
Traitement qualitatif des donnes et rgles de dcisions pour lhypothse numro 3
Conformment la stratgie dtude de cas, lanalyse de donnes pour cette recherche comprend une
premire phase consacre lanalyse individuelle et descriptive de chaque entreprise, et une seconde
phase consacre lanalyse transversale et explicative de lensemble des cas tudis.
Nous tentons de mettre en lumire les facteurs de succs ou dinsuccs du projet, les
changements et leurs degrs, les modifications du travail des utilisateurs ainsi que des concepteurs.
Nous considrons comme succs le fait dutiliser le systme (PGI) et de dclarer en tre satisfait,
dune part, et de constater que ces dclarations proviennent de lensemble des utilisateurs et acteurs du
systme. En cas de non-unanimit dans les dclarations nous parlerons de semi-succs , et en cas
dinsuffisances importantes de dclarations de satisfaction de la part des utilisateurs et acteurs,
dchec .
Concernant explicitement la famille des hypothses H3, ltude met en vidence le rle des
caractristiques de conduite de projet et de leurs modalits (organisation, quipe, documentation,
formation, dlai, etc.) en confrontant et en analysant leurs contributions aux cas de succs, semi-succs
et chec. Il nous faut alors mettre en perspective les modalits des facteurs de conduite de projet et leurs
contributions relatives (lorsque les facteurs sont tests conjointement) et/ou absolues (lorsquils le sont
individuellement) aux rsultats dclars. Nous appliquons la mthode suivante : si une modalit donne
dun facteur induit un rsultat de type succs et que -dans le mme temps- lensemble des autres
modalits de ce mme facteur induit des rsultats de type semi-succs et/ou chec , nous
considrons que cette modalit de ce facteur contribue amliorer sensiblement leffet test.
B. Test des quatre hypothses du modle de recherche

Le processus de validation dune hypothse (ou soushypothse) repose sur trois validations (au moins)
sur les six cas analyss.
Hypothse 1 LERP comme technologie de rupture
est valide
Les niveaux organisationnels ne sont pas impacts par lERP avec la mme
ampleur . Les diffrents cas font apparatre que les niveaux organisationnels ne sont pas
impacts avec la mme ampleur. En gnral, lencadrement intermdiaire et les services
fonctionnels sont les plus concerns par la mise en place de lERP.
Lhypothse H1.2
Lampleur du changement est diffrente selon les fonctions, et les changements

constats sont plus locaux que globaux Cependant, si les fonctions commerciales et de
gestion (y compris la logistique) sont les principales concernes, dans certains cas
(entreprise industrielle multinationale) cest la fonction production qui a vcu le plus
grand changement, lERP ayant abouti une remise en question des logiques mtiers.
Lhypothse H1.1
est valide
Lhypothse H1.3
nest pas valide
Lhypothse H1.4
est valide
Lhypothse H1.5
est valide
Lhypothse H1.6
est valide
Ladoption dun ERP nentrane gnralement pas de modifications du contenu du

travail. Mais cette conclusion doit tre attnue car souvent les mtiers sont affects, non
pas au cur de lactivit, mais dans leurs frontires respectives : ainsi, selon les cas
examins, les assistantes commerciales peuvent voir augmenter leur niveau de
responsabilit et leur autonomie, et le contenu des mtiers des cadres et des utilisateurscls peuvent tre amens voluer,.
Ladoption de lERP modifie fortement lautonomie de la hirarchie intermdiaire
Le rle de supervision et de pilotage de la hirarchie intermdiaire est bien renforc par
larrive de lERP. Un accs plus facile une information de pilotage actualise en temps
rel permet lencadrement une meilleure ractivit dans le contrle et la dcision.
En labsence de rflexion pralable, lERP constitue un vecteur de dstabilisation de
lorganigramme des entreprises. Dans quatre cas sur six, on constate des prises de
pouvoir de la part dindividus ou de groupes , peuvent tre des utilisateurs-cls , des
membres de lquipe projet, ou encore dune direction informatique groupe sur celles
des sites dcentraliss. Cette absence de rflexion sur les consquences socioorganisationnelles de larrive de lERP se manifeste le plus souvent pas une carence de la
rflexion sur les droits daccs au systme.
Sous certaines conditions, lERP modifie la reprsentation fonctionnelle du systme de
travail des utilisateurs. . Bien sr les premiers impacts par lERP sont ceux qui travaillent
son dploiement : DSI et utilisateurs cls, dont la reprsentation du systme de travail est
modifie par lERP. Mais ce sont aussi des postes de travail dautres domaines fonctionnels,
comme le commercial qui voient les reprsentations se modifier en fonction de lvolution
(dj constate plus haut) du contenu du travail.
Conclusion : Except pour la sous hypothse H1.3 (modification du contenu du travail), lhypothse H1
est valide et lERP constitue effectivement une technologie de rupture.
Hypothse 2 Les facteurs de la conduite de projet sont-ils mobiliss ?

Lhypothse H2.1
est valide
Lhypothse H2.2
est valide
Lhypothse H2.3
est valide
Lhypothse H2.4
nest pas valide
Lhypothse H2.5
nest pas valide
Lhypothse H2.6
est valide.
Lhypothse H2.7
est valide.
Lhypothse H2.8
nest pas valide.
Limplication et la soutien de la direction gnrale sont stratgiques et doivent avoir

lieu tout au long du projet . Ce sont en effet les directions qui sont le plus souvent
lorigine du projet (mme si parfois linititative vient de plus haut, lors dune absorption
par exemple). Ensuite, les directions suivent activement et soutiennent le droulement du
projet.
La participation de la DG llaboration des processus dcisionnels est importante.
Le plus souvent la DG dfinit des objectifs stratgiques, et les autres acteurs du projet
(quipe projet, consultants, intgrateurs) jouissent de dlgation de pouvoir, ce qui leur
permet dimposer certains choix organisationnels. Les responsables de services peuvent
aussi jouer de leur pouvoir pour peser sur ces choix.
Les dirigeants dfinissent une cible organisationnelle. Le niveau dimplication des
utilisateurs dans la dfinition de lorganisation-cible est trs faible . Cet tat de choses
peut sexpliquer par le manque de comptences des utilisateurs, mais le plus souvent les
utilisateurs sont carts du processus de conduite du projet et des choix organisationnels,
au profit du groupe projet et de la direction.
Dans la phase de formulation du problme et du choix de lERP, les utilisateurs aident
dfinir lorganisation-cible. La non validation de cette hypothse est la consquence la
validation de lhypothse prcdente. On lobserve dans tous les cas analyss.
Dans la phase de formulation du problme et du choix de lERP, les utilisateurs aident
dfinir les fonctionnalits de loutil . De mme que pour lhypothse H.2.4, on met en
avant le manque de comptence prsum des utilisateurs pour reporter sur les consultants
ou sur lquipe projet, le poids de ces choix essentiels pour le succs du projet. Dans 2 cas
sur 6, certains utilisateurs-cls ont t plus ou moins impliqus dans la rdaction du cahier
des charges.
La diversit des comptences de lquipe projet est mobilise . Lquipe projet peut
tre petite, il peut y avoir en plus des intervenants extrieurs, mais dans tous les cas cest
en fonction des comptences de ses membres quelle a t compose. Et ce sont ces
comptences qui sont mises contribution dans la conduite du projet.
Ltendue de la couverture fonctionnelle est leve . Les projets tudis ont un large
spectre de modules, ils intgrent presque toujours la production et la logistique (modules
mtiers), et le plus souvent la fonction commerciale. La paie et la gestion des
immobilisations sont parfois exclus du primtre.
Lentreprise procde un business process re-engineering (BPR) pour la mise en place
de lERP. Le BPR napparat pas comme un point de passage oblig lors de la mise en
place dun ERP. On peut rflchir sur les processus, les ramnager selon telle ou telle
thorie en vogue, mais ces volutions se font la marge. Sauf dans un cas ou un travail de
fond a t fait (flux tendus), mais avant le projet dimplantation de lERP.
Lhypothse H2.9
nest pas valide
Les entreprises ont une stratgie de dploiement Big Bang . Dans les faits, il savre
que les entreprises ont mode de dploiement adapt chaque situation particulire.
Lorsquil y a Big Bang , il ne concerne gnralement pas lensemble de lERP, mais
seulement une phase ou un groupe de modules.
Lhypothse H2.10
est valide.
La politique dhabilitation de lentreprise est bien conforme une reprsentation du

modle organisationnel projet par la direction gnrale . A travers les droits daccs au
systme on retrouve en effet la reprsentation de la plus ou moins grande importance des
utilisateurs, selon leur place dans lorganigramme. Il est beaucoup plus rare (mais cela existe
nanmoins) que la rflexion sur les habilitations aboutisse une nouvelle
Synthse rdige par Denis Brard (Charg de mission ANACT)-
2005 Tous droits rservs rseau Anact
18
organisation.
Lhypothse H2.11
nest pas valide
Les besoins de formation ont t dfinis partir dune analyse des impacts par la
population . Lchantillon se divise grosso modo en deux parts, selon que les entreprises
accordent ou pas une place importante la formation, mais rarement au point de prendre
celle-ci en compte en amont (analyse des impacts). Pour celles qui ne mettent pas la
formation comme composante du projet, on considre que les nouvelles comptences
sacqurront par lusage (doing by learning), ou encore on traite les besoins en formation
au fur et mesure des remontes, au cas par cas.
Lhypothse H2.12
est partiellement
valide
Une documentation adquate a t fournie aux utilisateurs . Dans trois cas sur six,
cest vrai, mais ce nest pas le cas pour les trois autres entreprises. La rgle de validation
des hypothses retenue (au moins 3 cas) valide donc -au moins partiellement- cette
hypothse.
Lhypothse H2.13
est partiellement
valide
Un dispositif dassistance auprs des utilisateurs a t mis en place . L encore

lchantillon se divise en deux : trois entreprises ont mis en place (en interne ou via
lditeur ou lintgrateur) une assistance utilisateurs, et trois ne lont pas fait. Lhypothse
est donc valide.
Lhypothse H2.14
est partiellement
valide
La politique de communication a t intgre lensemble du projet . Pour les trois

cas qui valident cette hypothse, la communication sur le projet sintgre dans un
ensemble plus vaste (projet dentreprise tendue, ), mais elle est bien spcifique
lERP. Dans les trois autres cas, la communication est soit rduite sa plus simple
expression, soit inexistante. Dans un cas elle est externalise.
Lhypothse H2.15
nest pas valide.
Lergonomie du systme a t intgre dans les proccupations du projet . Dans

aucun des cas tudi, lergonomie du systme a t un souci pour les responsables. Au
mieux on se proccupe dadapter quelques interfaces cran, mais cest la fin de la
conduite du projet, il ny a pas de prise en compte de lergonomie dans la conception du
systme.
Lhypothse H2.16
nest pas valide.
Une gestion sociale des salaris a t intgre dans les proccupations du projet . Au
mieux, (un cas) les syndicats ont t associs car lERP impliquait une saisie par les
oprateurs, ou bien on intgre un membre du CE dans lquipe projet, mais le plus souvent
le projet est simplement voqu en CE.
Au regard des multiples hypothses H2.x non valides (ou seulement partiellement), lhypothse
H2 nest pas valide et on peut affirmer que les facteurs de conduite de projet ne sont pas dans
leur globalit mobiliss.
19
Hypothse 3 Les effets de la conduite du changement sur les usages et les performances
Comme il a t soulign en introduction, le choix a t fait dune approche perceptuelle du
succs .On considre ainsi comme succs le fait dutiliser le PGI, de dclarer en tre satisfait et
de constater que ces dclarations sont partages par lensemble des utilisateurs et acteurs du systme. En
cas de non-unanimit, cette situation est caractrise comme semi-succs . Enfin, en cas
dinsuffisances et dinsatisfactions majeures de la part des utilisateurs et des acteurs, la situation est
qualifie dchec. A partir de cette grille danalyse, sur les 6 cas observs, nous navons pas relev
dchec. En revanche, sur les 6 cas tudis, 3 cas peuvent tre qualifis de succs et les 3 autres de semisuccs.
Caractristiques des cas considrs comme succs
Le dmarrage des projets est parfois difficile : dans un cas, plan de dploiement des diffrents modules
non matris en termes de dlai, contrainte de devoir raliser des spcifiques sur des fonctionnalits
critiques pour lentreprise. Dans un autre cas, la date de dploiement a t avance dun mois, ce qui na
pas laiss la possibilit de raliser les formations initialement prvues. Les utilisateurs ont donc perdu
beaucoup de temps assimiler par eux-mmes les fonctionnalits du systme, ce qui peut tre source de
stress pour certains, et de tensions entre les services.
Mais paradoxalement, ces difficults peuvent tre un vecteur dappropriation du projet par lentreprise.
Car lappropriation du systme et les transformations quil induit reposent alors sur limplication forte
de quelques personnes-cls dans la conception et lamlioration continue du systme et dans la
formation continue des utilisateurs (guide dutilisation ralis par les responsables).
Aprs quelques mois ou annes- dutilisation, lvaluation qualitative des ERP est globalement
positive : ils ont permis de prciser les tches et les responsabilits de chacun, et contribuent renforcer
la traabilit du process et des produits. En termes organisationnels, le progiciel est peru comme une
tape indispensable et pralable lintgration logistique globale de lentreprise et de ses partenaires
majeurs. Les utilisateurs (dont les directions gnrales) soulignent une coordination plus efficace, une
rationalisation des modes de travail, une meilleure qualit de linformation (les stocks sont justes 97%)
et enfin lamlioration du service offert aux clients. Dune faon gnrale, la satisfaction des utilisateurs
sapprhende au travers de lacceptation du systme : lERP est pass du stade de contrainte celui
doutil de travail, cest le systme qui fait foi et non plus le papier, les utilisateurs ont acquis le rflexe
cran .
Une fois le dispositif intgr dans le fonctionnement normal de lentreprise, il est finalement considr
comme banal alors quil a t peru au dpart comme rvolutionnaire dans sa forme et sa
transversalit.
Caractristiques des cas considrs comme semi-succs
Le plus souvent cest la difficult dune reconfiguration des processus qui a gnr une insatisfaction au
prs des utilisateurs. Lharmonisation des pratiques mtiers travers ladoption dun rfrentiel unique,
peut aussi tre entrave par la volont des entits de renforcer leurs territoires en accentuant leurs
diffrences.
Dans certains cas, cest lintervention de plusieurs utilisateurs dans un des processus (par ex. le
traitement de commande) qui provoque des dysfonctionnements. Ce peut tre aussi la difficult de
certains voir voluer leur mtier dans le sens dun rle plus important dans le processus de production
qui peut tre un frein (responsabilit accrue).
20
Il peut aussi arriver que la perception locale de lapport oprationnel du progiciel par les utilisateurs
apparaisse relativement faible compar au systme prcdent, conu sur-mesure et donnant entire
satisfaction depuis des annes.
La perception dun projet et dun dploiement, pilot la hussarde par des consultants externes et
sans BPR pralable peut dgrader encore limage de lERP et expliquer galement cette qualification de
succs partiel .
Mais, globalement, dans les cas de semi-succs , le systme intgr est finalement peru comme
satisfaisant. Surtout lorsque lentreprise fait partie dun groupe europen : on met alors en avant
lhomognisation des processus au sein des filiales et des facilits de pilotage quil permet au travers
de la standardisation des donnes collectes auprs des sites et filiales.
Le rle de la conduite de projet dans le succs constat
Sur la base dune analyse transversale, on observe que, sur les 17 facteurs de conduite de projets tudis,
cinq facteurs sont prsents systmatiquement dans les quatre cas de succs:
-
une large couverture fonctionnelle,

limplication de la DG,
la dfinition dune vision organisationnelle,
lordonnancement du dploiement,
la diversit de lquipe projet
On peut en dduire que ces facteurs contribuent positivement la satisfaction du systme par les
utilisateurs. Ils sont dailleurs dj identifis dans la littrature comme des facteurs cls de succs, ils
ressortent comme les plus discriminants et paraissent jouer, ce titre, un rle critique dans le succs.
Ces quatre facteurs (deux de nature oprationnelle : couverture fonctionnelle et ordonnancement du
dploiement ; deux de nature organisationnelle : implication de la DG et vision organisationnelle cible)
traduisent en fait la matrise effective du projet par lentreprise au sens particulier de la capacit de
lentreprise sapproprier le projet.
Concernant les aspects ngatifs de ces cas de succs, il est intressant de remarquer une absence de BPR
et une ergonomie du systme juge globalement insuffisante dans les quatre cas. On peut faire
lhypothse que labsence de BPR vite de dstabiliser les repres des utilisateurs et limite les
changements de forte ampleur. Et lergonomie nest pas perue par les utilisateurs comme tant un
facteur critique dans lappropriation du systme. Ils notent cet gard surtout une absence
doptimisation du systme.
Lexistence de dveloppements spcifiques et de ressources formations juges suffisantes, sont observs
dans trois cas sur quatre.
Les facteurs qui sont peu ou pas prsents dans les cas de succs sont : lassistance utilisateur, le mode de
dploiement en big bang, lexistence dune documentation, la communication, limplication des
utilisateurs, la politique dhabilitation, la formation juge insatisfaisante, et labsence de gestion sociale.
Cela ne signifie pas que ces derniers facteurs ne sont pas importants. La mthodologie retenue ne
permet pas, en effet, de conclure quils ne contribuent pas au succs , ni de hirarchiser les facteurs et
dmettre in fine un jugement sur la pertinence de ces facteurs dans la contribution au succs. En
revanche, on observe quils ne constituent pas un dnominateur commun associ au succs.
Par exemple, concernant la communication, nous nous sommes intresss lexistence dun plan de
communication formel et structur. Mais labsence de plan de communication ne signifie pas pour
autant labsence de communication autour du projet. Ainsi, dans certaines entreprises, si la
21
communication na pas lobjet fait de plan de communication structur et planifi, en revanche, elle
sest droule au fil du projet essentiellement par ajustement mutuel .
De mme, concernant la formation, le problme se pose tout dabord en termes de processus de
formation et de modalits choisies, ce qui revient poser la question du comment . Lexprience aura
montr que certains dispositifs de formation comme le processus de dmultiplication de la formation
nont pas t jugs satisfaisants ou encore la formation aura t juge soit trop brve ou encore
trop technique . Cette perception globalement ngative de la formation na pas empch dans la
pratique que la formation se ralise en parti sur le tas par auto-formation. Ainsi prsent, ce nest pas
tant la formation en soi qui constitue un facteur important mais plutt les dispositifs de formation.
Si on se fonde sur les rsultats de cette analyse transversale, ce qui semble dterminant dans la russite
dun tel projet, cest, dune part, lexistence de contours organisationnels bien dfinis par la direction
gnrale et dautre part, labsence dune gestion simultane dun projet de rorganisation et
dintroduction dune nouvelle technologie de linformation. Labsence de BPR limite lampleur des
changements perus par les utilisateurs. Plus prcisment, dans les cas de succs, les utilisateurs ne
peroivent pas lERP comme une technologie de rupture. Mais, ce qui ne signifie pas quil ny a pas de
changement organisationnel li limplantation de lERP. Les tudes de cas montrent que les diffrents
niveaux organisationnels sont effectivement impacts, et que ces changements ne gnrent pas de rejet
de la part des utilisateurs. En revanche, dans certains cas, les utilisateurs se disent globalement satisfaits
du systme mais insatisfaits des modalits de conduite du projet.
Comme il a t soulign en introduction, il nous semble intressant et important de contextualiser les
projets dimplantation dERP afin didentifier des variables contextuelles favorables la russite de tels
projets.
22
Hypothse 4 Les effets, la conduite du changement et la corrlation des deux phnomnes

dpendent du contexte.
Cas tudi
RBL
DSL
Pers.
DD
Cycle Eur.
API
Succs
Oui
Oui
Oui
Oui
Semi
Semi
Taille
120
211
420
490
3000 (450)
4000
Organisation
Organisation
Centralise
Centralise
Centralise
Centralise
Centralise
Centralise
2 sites
Mono site
3 sites
Mono site
Multi sites
Multi sites
Technicit du projet/
Maturit du SI
Forte
Moyenne
Forte
Forte
Faible
Moyenne
A partir du tableau, nous pouvons observer que la taille (la taille et lorganisation mono sites ou des
sites gographiquement proches) constitue une variable discriminante. Les PME semblent bnficier
dun contexte organisationnel plus favorable ce genre de projet. On peut faire lhypothse que les
PME se caractrisent par un degr de complexit organisationnel moindre et que le processus
dimplmentation est plus aisment matrisable.
Ces entreprises se caractrisent en effet par une relle matrise de leur projet qui se manifeste par une
large couverture fonctionnelle, limplication de la DG, une dfinition dune vision organisationnelle
cible et un ordonnancement du dploiement. En revanche, nous avons pu observer que dans certains cas,
les utilisateurs et les acteurs dclaraient tre insatisfaits des modalits de la conduite du projet
notamment concernant le processus de formation ou encore labsence dimplication des utilisateurs dans
lquipe de projet. Lappropriation du systme sest fait sur le tas et par auto-formation sur le temps
et par ajustement mutuel. En loccurrence, les problmes dadquation et les demandes dvolution ont
t rsolus par des relations de proximit entre lquipe de projet et les utilisateurs. Si les utilisateurs ont
t relativement absents du processus amont, ils lont t davantage en phase ex-post.
Dans les entreprises de taille modeste, lexpertise des responsables modules a permis de suppler
efficacement la faible implication des utilisateurs. Nous soulignons nouveau limportance de lquipe
projet en termes de diversit des comptences et/ou dexpertise mtier.
Enfin, la taille de lquipe projet restreinte sur les 4 cas (infrieure 10 personnes) semble galement
jouer positivement en facilitant les aspects de coordination relatifs de tel projet.
Plus globalement, cest bien la relative petite taille de ces entreprises qui facilite les processus de
coordination indispensable de tels projets notamment la coordination par ajustement mutuel par
opposition une coordination par supervision, par qualification et/ou par rsultat.
Dune manire gnrale, nous avons pu galement observer que lERP renforce la centralisation des
entreprises. Par exemple, une entreprise a remplac ses trois SI par un seul et cela a eu pour
consquence de placer les acteurs de la fonction commerciale (assistantes commerciales et
commerciaux) au centre du processus : ils se situent en amont du processus en entrant les donnes et en
aval les validant. Auparavant, le processus tait plus dcentralis notamment au niveau des usines ;
limplmentation de lERP a renforc la centralisation du pouvoir de dcision. On observe cette mme
tendance la centralisation en faveur dune ou deux fonctions critiques de lentreprise dans les autres
cas.
23
C. Conclusion Gnrale
La leon premire que lon peut tirer des projets suivis, est que le dploiement du systme technique lui
mme, prend du temps et quon ne peut donc esprer avoir des rsultats aussi rapidement quon
limagine. Une installation en 6 mois et des effets immdiats relvent de circonstances exceptionnelles.
Ensuite, les effets dpendent de lambition du projet cest--dire de la dfinition dune vision
organisationnelle cible quil doit permettre datteindre et de la faon dont le changement est
accompagn. Sans cette vision la mise en place dun ERP ne signifie pas automatiquement changement
profond dorganisation Ainsi lun des projets suivis a finalement largement reproduit les spcificits de
lorganisation antrieure et constitue ainsi un chec partiel. A partir de l on peut se demander ce que les
actions daccompagnement peuvent apporter pour aider changer puisquon se contente, mme si en soi
cest dj difficile, de changer doutil de travail. Quapporte alors loutil ? tait-ce utile ?
Une anne au moins aprs le dploiement quasi complet de plusieurs modules dans les entreprises
tudies, on peut constater certains effets:
un changement important du travail, voire du mtier de certaines fonctions (ex : dans une
des entreprises les assistantes commerciales souvent recrutes sur un profil de communication, passent
maintenant environ 5 heures par jour au lieu dune sur le progiciel et voient donc leur mtier fortement
voluer),
la structuration de certaines fonctions comme les achats qui nexistaient pas en tant que service
auparavant,
la perception beaucoup plus nette des incidences des consquences dune saisie dans les autres
fonctions de lentreprise ; toutefois cette perception ne touche encore pour la plupart des projets
tudis que les utilisateurs cls, cest--dire ceux qui ont t incorpors dans lquipe projet.
Ce dernier effet montre que la dynamique du projet a un impact important sur la perception des effets.
Au risque dtre caricatural, les autres effets de la mise en place des ERP tudis sont les suivants :
des changements plus locaux que globaux, dont lutilit est encore limite mais qui peuvent
samplifier ultrieurement
le rle du contrle a tendance a tre renforc dans la mesure o les erreurs sont beaucoup plus
coteuses puisque la saisie unique et en temps rel a des rpercussions immdiates dans toutes
les fonctions o un module de lERP est implant,
la reprsentation du systme de travail des utilisateurs-cls volue et leur donne enfin une
vision de ce que font les autres dans lentreprise.
Finalement, lERP est il peru comme une technologie de rupture ? Oui et non. Si lon fait la somme
des changements dans lorganisation, ceux-ci sont importants et on est alors tent de rpondre par
laffirmative (cf. hypothse 1). Mais cest alors le point de vue des chercheurs qui sexprime. Si lon se
place du point de vue des acteurs, la rponse est plus simple. Pour les dirigeants et pour lencadrement,
cest bien une technologie de rupture. Leur implication dans le projet, comme leur rapport au
fonctionnement du systme dinformation de gestion sont dune autre nature avec lERP. Leur accs
linformation est beaucoup plus large, la perception des problmes plus prcise et plus exacte ; ils
passent dun pilotage fonctionnel ou multi-fonctionnel une vision transversale des problmes. En
24
revanche, pour la plupart des utilisateurs, lERP nest pas une rvolution. Ceci est dautant plus vrai que
dans de nombreux cas de PME on na pas cherch redfinir les processus (cf. hypothse 3). Mme
avec un ERP dploy dans lensemble de lorganisation, les utilisateurs restent centrs sur leur poste de
travail dont les fonctions nont t largies que marginalement.
Cependant, les rsultats de ltude confirment que ces effets diffrent selon la conduite de projet et le
contexte de lentreprise (hypothses 2,3 et 4).
Le soutien de la DG apparat systmatique et la participation de celle-ci la dfinition des processus
importante, sans quoi le projet naboutirait pas. Les dirigeants sont au minimum appels dfinir une
vision organisationnelle cible, mais le nombre dutilisateurs impliqus dans ce choix est trs faible. Par
ailleurs ils aident rarement dfinir les fonctionnalits de loutil, do des difficults dappropriation.
La composition de lquipe-projet et les comptences des membres (informaticiens, utilisateurs, chef de
projet, consultants externe) constituent un facteur cl de succs.
La formation est juge trop souvent insuffisante et non adapte aux impacts du projet sur lorganisation
. Elle est insuffisante en temps et trop centre sur loutil et pas assez sur le mtier et lorganisation bien
que souvent servie en partie par des hommes des mtiers concerns. Des dficits importants de
documentation et dassistance ont galement t constats. Un effort sur lensemble de ces moyens
daccompagnement du changement aurait permis sinon daller plus vite du moins de mieux matriser ce
qui sest fait.
Les dveloppements spcifiques permettent de relier le nouveau systme intgr dautres applications
et de rpondre des besoins particuliers que le systme prcdent satisfaisait, et dont on ne peut se
passer. Du point de vue des utilisateurs ils sont apprcis et facilitent le changement. En revanche, ils
entranent des difficults de maintenance et des cots supplmentaires.
Sur le plan du contexte, la leon de notre recherche est quil semble bien que ce soit plus facile de
russir un projet ERP en PME quen grande entreprise. Cela peut paratre paradoxal si lon raisonne en
termes de ressources, mais cela sexplique par le caractre moins complexe mais plus complet du projet
en PME. La particularit des PME est aussi sans doute de ne pas chercher mener de Business Process
Reengineering (cest--dire de redfinition de la squence doprations qui supportent une
activit) avant la mise en place de lERP. Comment lexpliquer ? soit la complexit des PME est faible
et la gnricit des ERP souvent taills pour la grande entreprise est telle que la PME peut facilement
sadapter a lERP, soit la PME ne le fait pas par manque de temps.
Enfin, mme si lampleur de ces projets exige une nergie considrable et en dpit de ressources
souvent insuffisantes en nature ou en quantit pour accompagner le changement, y compris dans les
grandes entreprises, les acteurs simpliquent fortement, et notamment les utilisateurs en aval du projet.
Ceci semble pour partie lie lenvironnement qui pousse lentreprise rechercher la rigueur
quapporte lERP, mme si cest au prix de gros efforts . Cette forme dimplication est positive, mme si
dans le respect de la culture de lentreprise on pourrait esprer un moindre effort en faisant intervenir les
utilisateurs plus en amont. Les stratgies de croissance, la traabilit, le calcul prcis des stocks, la
relation avec les clients sont ainsi favorises. Cette performance accrue dans le cas des entreprises
rencontres montre que lon a progress sur ce sujet par rapport aux projet ERP des grandes entreprises
dans les annes 1990.
25
D. Rfrences dans le domaine et bibliographie

Barki H., Hartwick, J., (1994), User participation, Conflict and conflict resolution : the mediating roles of
influence, Information Systems Research, vol 5 n4, p.422-38.
Besson P. (1999), Les ERP lpreuve de lorganisation, Systmes dInformation et Management, vol 4
n4, p. 21-52.
Besson P., Rowe F., (2001) ERP project dynamics and enacted dialogue: perceived understanding,
perceived leeway and the nature of task-related conflicts, Database advances in Information Systems.
Bidan M., El Amrani R., Geffroy-Maronnat B., Marciniak R., Rowe F. (2002), PGI, flexibilits,
organisation du travail et reprsentations dans les moyennes et grandes entreprises , rapport DARESMinistre du Travail.
Bidan M., 2004, Intgration du systme dInformation de Gestion, www.e-theque.com ( paratre)

Bouillot C.(1999), Mise en place de Progiciels de Gestion Intgre loccasion de fusions et cessions
dentreprises dans un contexte international , Systmes dInformation et Management, vol.4, n4, p 91-106.
Czard M., Dussert F., Gollac M., (1992), Taylor va au march. Organisation du travail et
informatique , Travail et Emploi, n54.
Coat F. et Favier M., (1999), Passage lERP et refonte du systme dinformation : le cas des ASF ,
Systme dInformation et Management, n4, p.107-128.
Davenport T.H. (1998) Putting the Entreprise in the Entreprise system , Harvard Business Review. JulAug.
De Dreuzy E., Akoka J. (1996), Accompagner le changement chez lutilisateur : le cas de Air Inter,
Systmes dInformation et Management, vol.1, n2, p.61-78.
Desq S. (2001) Linformatique de lutilisateur : un concept victime de son succs ? S ystme s
dInformation et Management, vol.1, n2, p.65-80.
Grover V., Fiedler, K., Teng J., (1994), Exploring the success of Information Technology enabled
business process reengineering, IEEE Transactions on Engineering Management, vol.41, n3, p.1-8.
Marciniak R., Rowe F., (1997) Systmes dinformation, dynamique et organisation, Economica : Paris.
Monod E., (1998) Transformation dentreprise et dveloppement des systmes dinformation : le cas IBM,
Systmes dInformation et Management, n4, vol.3, p.17-48.
Numro thmatique Risques et progiciels de gestion intgrs 2004 Systmes dInformation et

Management (www.revuesim.free.fr et Editeur ESKA Paris).
Pettigrew A., (1987), Context and action in the transformation of the firm, Journal of Management
Studies, vol 24 n6.
Pinsonneault A., Kraemer K. (1993), the impacts of information technology on middle managers, MIS
Quarterly, vol. 17 n3, p.271-92.
Robey D., Boudreau M-C, (2000) Organizational consequences of information technology: dealing with
diversity in empirical research in Framing the domains of IT Management, R. Zmud (ed.), Pinnaflex:
Cincinnati.
26
Rowe (2003), Changement et systmes dinformation, in Allouche J. (ed.) Encyclopdie de Gestion des
Ressources Humaines, Paris, Vuibert, 2003.
Rowe F., (1994) Des banques et des rseaux : productivit et avantages concurrentiels, Economica :
Paris.
Rowe F., Struck D., (1995), Linteraction tlcommunications-structure des organisations : perspectives,
thories, mthodes, Sciences de Gestion- Cahiers de lISMEA, n21.
Rowe, F. (1999) ; Cohrence, intgration informationnelle et changement : esquisse dun programme de
recherche partir des Progiciels Intgrs de Gestion, Systmes d'Information et Management, vol.4, n4,
p.3-20.
Vaast E., Benghozi P.J. (2000), Intranets et entreprises technologie, apprentissages et organisation de la
cohrence, Colloque AIM, Montpellier, France.
Yin.R, (1984), Case study research, Sage.
Zack, M., & Mac Kenney, J. (1995).Social Context and Interaction in Ongoing Computer-supported
Management Groups. Organization Science, 6(4), 394-422.
27

ERP Et RH

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ERP Et RH

Diunggah oleh

Hak Cipta:

Format Tersedia

Maison des Sciences de lHomme (MSH)

Universit de Nantes (LAGON)

Impact sur lorganisation et les

A. ENJEUX, OBJECTIFS, HYPOTHSES ........................................................................................................................................... 3

A. Enjeux, Objectifs, Hypothses

II. Mthodologie gnrale: contexte et processus

III. Objet de ltude

IV. Problmatique et hypothses

Lhypothse 1 est les questions drives :

ERP et niveaux organisationnels

Inter-organisationnel : la mise en place dun module de CRM va toucher la gestion et la

ERP et diffrenciation organisationnelle

ERP et reprsentation des utilisateurs

IV.2 La conduite dun projet ERP

Figure : le cycle de vie dun projet ERP

Formulation du problme et choix de lERP (Chartering ) : durant cette phase

Dploiement (Shakedown) : dernire phase du projet, il concerne les activits

Usages et effets (Onward and Upward) : le ERP entre maintenant en exploitation

limplmentation, les premires phases dutilisation du systme, lintgration de loutil au sein de

Diversit et variabilit des dimensions de la conduite du projet ERP

dadaptation de lERP aux besoins et ralits de lentreprise. Ce facteur dpend la fois du

quel degr dadaptation lorganisation locale (suivi de lvolution des contextes

Comment adapter un ERP au contexte spcifique de lentreprise

Des crans masques

Processus selon lequel lentreprise fixe et dtermine le paramtrage des processus et

Tableau : la typologie des choix dadaptation de lERP

IV.4 Les effets, la conduite du changement et la corrlation des deux phnomnes

V.II. Le choix des techniques de recueil des donnes

B. Test des quatre hypothses du modle de recherche

Hypothse 1 LERP comme technologie de rupture

Lampleur du changement est diffrente selon les fonctions, et les changements

Ladoption dun ERP nentrane gnralement pas de modifications du contenu du

Hypothse 2 Les facteurs de la conduite de projet sont-ils mobiliss ?

Limplication et la soutien de la direction gnrale sont stratgiques et doivent avoir

La politique dhabilitation de lentreprise est bien conforme une reprsentation du

Synthse rdige par Denis Brard (Charg de mission ANACT)-

2005 Tous droits rservs rseau Anact

Un dispositif dassistance auprs des utilisateurs a t mis en place . L encore

La politique de communication a t intgre lensemble du projet . Pour les trois

Lergonomie du systme a t intgre dans les proccupations du projet . Dans

une large couverture fonctionnelle,

Hypothse 4 Les effets, la conduite du changement et la corrlation des deux phnomnes

D. Rfrences dans le domaine et bibliographie

Bidan M., 2004, Intgration du systme dInformation de Gestion, www.e-theque.com ( paratre)

Numro thmatique Risques et progiciels de gestion intgrs 2004 Systmes dInformation et

Anda mungkin juga menyukai