Impact sur l'organisation et les conditions de travail des nouveaux modes de gestion reposant sur les ERP/PGI (synthse)

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 SynthseAuteurs de ltude : Bndicte Geffroy-Maronnat Marc BidanRedouane ElamraniFrantz RoweSommaireA. ENJEUX, OBJECTIFS, HYPOTHSES ........................................................................................................................................... 3I. ENJEUX DE LA CONDUITE DU CHANGEMENT ORGANISATIONNEL FACE LVOLUTION DES SYSTMES DINFORMATION ET

DE LA COMMUNICATION ........................................................................................................................................................................... 3I.1 Un nouveau jeu plus complexe dacteurs ................................................................................................................................ 3I.2 Lenjeu revisit de lintroduction des utilisateurs dans la conception................................................................................... 3II. MTHODOLOGIE GNRALE: CONTEXTE ET PROCESSUS .................................................................................................................... 4II.1 Un contexte multidimensionnel et multi-acteurs .................................................................................................................... 4II.2 Les processus de changement ................................................................................................................................................. 4III. OBJET DE LTUDE ............................................................................................................................................................................. 5IV. PROBLMATIQUE ET HYPOTHSES ..................................................................................................................................................... 5IV.1 LERP est-il facteur de changements organisationnels et sociaux ? ................................................................................... 5IV.2 La conduite dun projet ERP ................................................................................................................................................. 9IV.3 Les effets de la conduite du changement sur les usages, les performances et les conditions de travail .......................... 12IV.4 Les effets, la conduite du changement et la corrlation des deux phnomnes dpendent du contexte ........................... 14V. MTHODOLOGIE ................................................................................................................................................................................ 15V.I. Une mthodologie fondamentalement qualitative et croisant le regard des acteurs ........................................................ 15V.II. Le choix des techniques de recueil des donnes ................................................................................................................. 15Traitement qualitatif des donnes et rgles de dcisions pour lhypothse numro 3 .............................................................. 16B. TEST DES QUATRE HYPOTHSES DU MODLE DE RECHERCHE ................................................................................. 17HYPOTHSE 1 LERP COMME TECHNOLOGIE DE RUPTURE ............................................................................................................... 17HYPOTHSE 2 LES FACTEURS DE LA CONDUITE DE PROJET SONT-ILS MOBILISS ?........................................................................... 18HYPOTHSE 3 LES EFFETS DE LA CONDUITE DU CHANGEMENT SUR LES USAGES ET LES PERFORMANCES ....................................... 20Caractristiques des cas considrs comme succs ............................................................................................................. 20Caractristiques des cas considrs comme semi-succs .................................................................................................... 20Le rle de la conduite de projet dans le succs constat............................................................................................................ 21HYPOTHSE 4 LES EFFETS, LA CONDUITE DU CHANGEMENT ET LA CORRLATION DES DEUX PHNOMNES DPENDENT DU CONTEXTE. .............................................................................................................................................................................................. 23C. CONCLUSION GNRALE............................................................................................................................................................. 24E. RFRENCES DANS LE DOMAINE ET BIBLIOGRAPHIE.................................................................................................... 26A. Enjeux, Objectifs, HypothsesI. Enjeux de la conduite du changement organisationnel face lvolution des systmes dinformation et de la communicationLanticipation 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 dacteursLa 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 conceptionOn 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 entreprisesjustement 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 processusPour 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-acteursLambivalence 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 changementIl 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 ltudeLobjectif 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)

Relation(s) (H3)

Effets et usages ex post (H1)Figure : modle de rechercheIV. Problmatique et hypothsesIV.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 :Rupture

Y a-t-il des impacts tous les niveaux organisationnelsOui ?

Y a-t-il un changement globalOui ?

Y a-t-il un changement fort du contenu du travailOui ?

Y a-t-il un changement fort pour la hirarchie intermdiaireOui ?

Y a-t-il un changement dans la rpartition des responsabilitsOui ?

Y a-t-il un changement dans les reprsentations des

utilisateursOui ?

ERP et niveaux organisationnelsLes 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 organisationnelleLERP 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 travailConformment 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 intermdiaireDans 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 responsabilitsLa 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 utilisateursEn 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 ERPLe processus de mise en uvre dun projet ERPLe 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 problmeet choix de lERP

Ingnierie Dploiement Usages et effetsFigure : 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 ERPPlusieurs 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 etdadaptation 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 nouvelleorganisation (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 travailDans 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 lentrepriseConfigurationProcessus selon lequel lentreprise fixe et dtermine le paramtrage des processus ettransactions qui correspondent son modle organisationnel. (dfinir les structures organisationnelles, crer les tats de gestion standards, les procdures excuter, etc.)

Bolt-onsImplmentation dune autre application informatique conue dans le mmeenvironnement 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.).

Des crans masquesCration dcrans masque pour la saisie et ldition des donnes. (Intgrer troiscrans en un seul).

Reporting largiProgrammation de nouvelles options de reporting et ddition des tats. (Crer denouveaux tats spcifiques un besoin prcis : tat des achats dune classe de produits).

Programmation de nouveauxflux de travailCrer des flux de travail non-standards. (Mettre en place un processus automatis devalidation des ordres de changement techniques).

Users exitsProgrammer une nouvelle fonctionnalit dans une interface ouverte (dvelopper unefonction statistique pour des calculs mtriques).

Programmer lERPCration dune nouvelle application dans le mme environnement technique delERP sans changer le code source. (Une application rpondant une niche de besoin impossible inclure dans la version standard de lERP).

Dveloppement desinterfacesProgrammation de nouvelles interfaces pour faire communiquer lERP avec lesapplications maintenues par lentreprise ou avec dautres modules des autres ERP. (Interface entre SAP et le CRM doracle).

Modification du code sourceChanger 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 lERPCes 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. MthodologieV.I. Une mthodologie fondamentalement qualitative et croisant le regard des acteursLa 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 donnesDans 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 primairesLa 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 laqualit, 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 secondairesLutilisation 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 rechercheLe processus de validation dune hypothse (ou soushypothse) repose sur trois validations (au moins)

sur les six cas analyss.

Hypothse 1 LERP comme technologie de ruptureLhypothse H1.1est valide Les niveaux organisationnels ne sont pas impacts par lERP avec la mmeampleur . 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.2est valide Lampleur du changement est diffrente selon les fonctions, et les changementsconstats 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.3nest pas valide Ladoption dun ERP nentrane gnralement pas de modifications du contenu dutravail. 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 utilisateurs- cls peuvent tre amens voluer,.

Lhypothse H1.4est valide 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.

Lhypothse H1.5est valide En labsence de rflexion pralable, lERP constitue un vecteur de dstabilisation delorganigramme 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 socio- organisationnelles de larrive de lERP se manifeste le plus souvent pas une carence de la rflexion sur les droits daccs au systme.

Lhypothse H1.6est valide Sous certaines conditions, lERP modifie la reprsentation fonctionnelle du systme detravail 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.1est valide Limplication et la soutien de la direction gnrale sont stratgiques et doivent avoirlieu 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.

Lhypothse H2.2est valide 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.

Lhypothse H2.3est valide Les dirigeants dfinissent une cible organisationnelle. Le niveau dimplication desutilisateurs 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.

Lhypothse H2.4nest pas valide 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.

Lhypothse H2.5nest pas valide 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.

Lhypothse H2.6est valide. La diversit des comptences de lquipe projet est mobilise . Lquipe projet peuttre 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.

Lhypothse H2.7est valide. Ltendue de la couverture fonctionnelle est leve . Les projets tudis ont un largespectre 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.

Lhypothse H2.8nest pas valide.Lentreprise procde un business process re-engineering (BPR) pour la mise en placede 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.9nest pas valide Les entreprises ont une stratgie de dploiement Big Bang . Dans les faits, il savreque 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.10est valide. La politique dhabilitation de lentreprise est bien conforme une reprsentation dumodle 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 18organisation.Lhypothse H2.11nest pas valide Les besoins de formation ont t dfinis partir dune analyse des impacts par lapopulation . 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.12est 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.13est partiellement valide Un dispositif dassistance auprs des utilisateurs a t mis en place . L encorelchantillon 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.14est partiellement valide La politique de communication a t intgre lensemble du projet . Pour les troiscas 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.15nest pas valide. Lergonomie du systme a t intgre dans les proccupations du projet . Dansaucun 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.16nest pas valide. Une gestion sociale des salaris a t intgre dans les proccupations du projet . Aumieux, (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.Hypothse 3 Les effets de la conduite du changement sur les usages et les performancesComme 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 etde 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 semi- succs.

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 fortede quelques personnes-cls dans la conception et lamlioration continue du systme et dans laformation 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).

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 constatSur 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 lacommunication 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.

Hypothse 4 Les effets, la conduite du changement et la corrlation des deux phnomnes dpendent du contexte.Cas tudiSuccsTailleOrganisationOrganisationTechnicit du projet/Maturit du SI

RBLOui120Centralise2 sitesForte

DSLOui211CentraliseMono siteMoyenne

Pers.Oui420Centralise3 sitesForte

D DOui490CentraliseMono siteForte

Cycle Eur.Semi3000 (450)CentraliseMulti sitesFaible

APISemi4000CentraliseMulti sitesMoyenne

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.

C. Conclusion GnraleLa 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. Enrevanche, 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 dedocumentation 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.

D. Rfrences dans le domaine et bibliographieBarki 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 4n4, 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 DARES- Ministre 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. Jul- Aug.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 ? Systmes 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 etManagement (www.revuesim.free.fr et Editeur ESKA Paris).

Pettigrew A., (1987), Context and action in the transformation of the firm, Journal of ManagementStudies, 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.Rowe (2003), Changement et systmes dinformation, in Allouche J. (ed.) Encyclopdie de Gestion desRessources 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-supportedManagement Groups. Organization Science, 6(4), 394-422.