«Impact sur l organisation et les conditions de travail des nouveaux modes de gestion reposant sur les ERP/PGI»

Transcription

1 Maison des Sciences de l Homme (MSH) Université de Nantes (LAGON) Ecole des Mines de Nantes (EMN) «Impact sur l organisation et les conditions de travail des nouveaux modes de gestion reposant sur les ERP/PGI» Synthèse Auteurs de l étude : Bénédicte Geffroy-Maronnat Marc Bidan Redouane Elamrani Frantz Rowe Synthèse rédigée par Denis Bérard (Chargé de mission ANACT)- novembre 2005 Tous droits réservés

2 Sommaire A. ENJEUX, OBJECTIFS, HYPOTHÈSES...3 I. ENJEUX DE LA CONDUITE DU CHANGEMENT ORGANISATIONNEL FACE À L ÉVOLUTION DES SYSTÈMES D INFORMATION ET DE LA COMMUNICATION...3 I.1 Un nouveau jeu plus complexe d acteurs... 3 I.2 L enjeu revisité de l introduction des utilisateurs dans la conception... 3 II. MÉTHODOLOGIE GÉNÉRALE: CONTEXTE ET PROCESSUS...4 II.1 Un contexte multidimensionnel et multi-acteurs... 4 II.2 Les processus de changement... 4 III. OBJET DE L ÉTUDE...5 IV. PROBLÉMATIQUE ET HYPOTHÈSES...5 IV.1 L ERP est-il facteur de changements organisationnels et sociaux?... 5 IV.2 La conduite d un projet ERP... 9 IV.3 Les effets de la conduite du changement sur les usages, les performances et les conditions de travail IV.4 Les effets, la conduite du changement et la corrélation des deux phénomènes dépendent du contexte V. MÉTHODOLOGIE...15 V.I. Une méthodologie fondamentalement qualitative et croisant le regard des acteurs V.II. Le choix des techniques de recueil des données Traitement qualitatif des données et règles de décisions pour l hypothèse numéro B. TEST DES QUATRE HYPOTHÈSES DU MODÈLE DE RECHERCHE...17 HYPOTHÈSE 1 L ERP COMME TECHNOLOGIE DE RUPTURE...17 HYPOTHÈSE 2 LES FACTEURS DE LA CONDUITE DE PROJET SONT-ILS MOBILISÉS?...18 HYPOTHÈSE 3 LES EFFETS DE LA CONDUITE DU CHANGEMENT SUR LES USAGES ET LES PERFORMANCES...20 Caractéristiques des cas considérés comme «succès» Caractéristiques des cas considérés comme «semi-succès» Le rôle de la conduite de projet dans le succès constaté HYPOTHÈSE 4 LES EFFETS, LA CONDUITE DU CHANGEMENT ET LA CORRÉLATION DES DEUX PHÉNOMÈNES DÉPENDENT DU CONTEXTE...23 C. CONCLUSION GÉNÉRALE...24 E. RÉFÉRENCES DANS LE DOMAINE ET BIBLIOGRAPHIE...26 Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 2

3 A. Enjeux, Objectifs, Hypothèses I. Enjeux de la conduite du changement organisationnel face à l évolution des systèmes d information et de la communication L anticipation des effets sociaux et organisationnels des nouveaux outils «intégrés» de gestion constitue un nouvel enjeu majeur pour l entreprise et ses acteurs sociaux. En effet, historiquement, on a d abord automatisé et réduit les coûts, donc avec une certaine maîtrise et sans nécessité d innover dans la conduite du changement organisationnel. Tout au plus, fallait-il affronter les syndicats sur les postes perdus. L informatisation s est le plus souvent adaptée aux structures de l organisation existantes avant de les transformer peu à peu, ce qui s est 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 intermédiaires) et des qualifications demandées. I.1 Un nouveau jeu plus complexe d acteurs La taille des projets et le rythme de l informatisation poussent aujourd hui les entreprises à ne plus développer leurs logiciels elles-mêmes mais à les externaliser. Les Directions des Systèmes d Information (DSI) conservent une capacité de conseil, d intégration et d exploitation. Cependant elles perdent aussi beaucoup de pouvoir au profit des directions générales et de consultants extérieurs en stratégie, auxquels celles ci font appel. Ces cabinets venus plus récemment aux technologies de l information sont souvent peu sensibles aux aspects touchant le travail. Parallèlement, dans les grandes entreprises, les maîtrises d ouvrage se sont renforcées en compétences informatiques. Tout ceci affaiblit la capacité d action de la DSI en même temps que la complexification de la technologie lui laisse une part d expertise considérable sur ce plan. Dans ce contexte, nombre d acteurs peuvent prétendre accompagner le changement organisationnel. Ce peut être les éditeurs qui appliquent alors une méthode maison censée régler ce problème mais sur le papier seulement : car de l aveu de beaucoup d entre eux, c est au client de décider de dégager des ressources internes ou externes. Dans la pratique, on constate que ces ressources ne sont généralement dégagées qu à la suite de la constatation de problèmes que l on regroupe pudiquement sous le voile de la «résistance au changement». Des travaux précédents on montré que ces problèmes sont la résultante d un déficit d anticipation du jeu des acteurs et d une difficulté de l équipe de concepteurs à communiquer sur le projet avec les parties intéressées. Les technologies de l information ainsi que d autres outils d organisation (règles de gestion, plans, réunions, etc.) pourraient aussi être intégrés dans le processus de conception. Mais hélas, concrètement, les entreprises raisonnent plus souvent comme si la technique seule était la solution aux problèmes organisationnels. Autrement dit, il n y a pas véritablement de réflexion socio-technique au sens du Tavistock Institute : les projets d investissement du type ERP ne sont pas vus comme des projets organisationnels. I.2 L enjeu revisité de l introduction des utilisateurs dans la conception On le sait depuis longtemps déjà : la participation et l implication des acteurs sont au cœur du processus de changement organisationnel. D une part, les nouvelles technologies sont plus conviviales et accessibles aux utilisateurs et permettent de faire du prototypage rapide pour tester l expression des besoins. D autre part, le risque d une participation plus démocratique mais n adhérant pas au projet augmente avec l intégration des systèmes et l évolution vers une entreprise étendue comprenant des acteurs aux maturités stratégique et organisationnelle très différentes. On s aperçoit ainsi que les commerciaux ne sont généralement pas associés aux projets de commerce électronique des entreprises Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 3

4 justement parce qu ils perçoivent qu Internet pourrait bouleverser la relation au client et in fine leur métier. Nous rejoignons ici l hypothèse principale de cette étude : le facteur humain dans sa dynamique collective constitue le facteur clé de succès du processus d investissement. Cet enjeu capital n est pas seulement un problème d appropriation dans l utilisation, mais du fait du caractère de plus en plus stratégique des projets, c est bien un problème de conception. II. Méthodologie générale: contexte et processus Pour penser les effets des technologies de l information sur le travail et aboutir à des méthodes ou approches raisonnables de conduite du changement, nous pensons qu il faut quitter l approche uniquement centrée sur le poste de travail et les tâches de l utilisateur final pour s intéresser davantage au système d organisation qui conditionne la performance du système d information. Pour nous, le système d organisation est à la fois un contexte organisationnel comprenant le système d information et un processus de changement. II.1 Un contexte multidimensionnel et multi-acteurs L ambivalence des résultats des recherches sur le contenu des impacts organisationnels des systèmes d information s explique souvent par un contexte multi-dimensionnel et une perception différente selon les acteurs. Par exemple sur le plan des structures, le degré de centralisation paraît être une variable intéressante. Ainsi il a été montré que les réseaux ont eu des effets centralisateurs dans les banques décentralisées et inversement. C est pourquoi il est illusoire de produire des connaissances stables en la matière sans spécifier le contexte du changement. Les recherches focalisées sur le contenu ont souvent une valeur descriptive intéressante quant à l objet et à l intensité du changement organisationnel mais leur capacité explicative, voire prédictive est très faible. En revanche, la prise en compte du contexte historique, d un type de structure organisationnelle, de secteur économique, de pays, de valeurs culturelles, permet de comprendre des résultats empiriques souvent différents voire contradictoires. L appropriation et la conception des outils au sein d une population d entreprises ou dans une organisation sont liées à un contexte qu il faut examiner dans toutes ses dimensions (stratégie, structure, tâches, système d incitation, acteurs). La conduite des effets du changement organisationnel passe nécessairement par un diagnostic complet sur toutes les dimensions du contexte organisationnel dans le périmètre du projet. Ce contexte organisationnel fait système dans la mesure où les contraintes des différentes dimensions ne sont pas indépendantes entre elles de sorte que le véritable changement ne peut souvent s opérer que par une action conjointe sur plusieurs dimensions tenant compte des perceptions des parties intéressées. 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 l organisation et des effets bien distincts sur d autres. On retrouve ces distorsions dans les impacts des technologies au sein d une même organisation. Le système d organisation ne peut donc se réduire à la seule prise en compte du contexte. Il est aussi lié au processus et à la conduite du changement organisationnel. La littérature a toujours mis l accent sur le problème de l association et de l accompagnement des utilisateurs à la définition du nouveau système, mais également sur ceux de la structure projet, des méthodes d évaluation et des méthodes de développement elles-mêmes en insistant sur l intérêt des méthodes de prototypage. Avec le développement de projets de progiciels de gestion intégrés, l intérêt de recherches examinant plus finement les processus de changement s est fortement développé ces dernières années. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 4

5 III. Objet de l étude L objectif de l étude est de contribuer à faire avancer la connaissance et la pratique sur la conduite du changement des projets ERP/PGI par l examen de quatre hypothèses : «La mise en évidence des conséquences de l utilisation de l ERP sur le travail et l organisation» (cf. H1) «L analyse de la conduite de projet ERP et la conduite du changement associée» (cf. H2) «Etudier la corrélation entre la conduite de projet mise en œuvre pour implanter l ERP et les conséquences observées sur le travail et l organisation» (cf. H3) Et ce en fonction du type d entreprise et de son contexte (cf. H4) Le schéma suivant présente le modèle de la recherche et notamment les hypothèses et les dimensions qui sont analysées : Contexte organisationnel et technologique (H4) Conduite de projet (H2) Relation(s) (H3) Figure : modèle de recherche Effets et usages ex post (H1) IV. Problématique et hypothèses IV.1 L ERP est-il facteur de changements organisationnels et sociaux? L analyse du phénomène étudié est difficile car il ressort de plusieurs études que, d une part, l on ne peut pas ignorer le contexte dans lequel s inscrit le changement (pour une technologie donnée, les effets observés d un cas à un autre peuvent être différents) et d autre part, les effets organisationnels observés ne sont pas les mêmes selon la technologie considérée. L ERP soulève à cet égard un grand nombre d interrogations concernant son impact sur l organisation et les acteurs. En tant que nouvelle technologie de l information, nous pouvons supposer que l ERP a une influence sur le mode d organisation et de fonctionnement de l entreprise. Mais au-delà de cette influence, compte tenu des caractéristiques véhiculées par l ERP, nous pouvons l entrevoir comme une technologie de rupture avec les formes d organisation traditionnelles et les métiers existants. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 5

6 L hypothèse 1 est les questions dérivées : Rupture Y a-t-il des impacts à tous les niveaux organisationnels Oui? Y a-t-il un changement global Oui? Y a-t-il un changement fort du contenu du travail Oui? Y a-t-il un changement fort pour la hiérarchie intermédiaire Oui? Y a-t-il un changement dans la répartition des responsabilités Oui? Y a-t-il un changement dans les représentations des Oui? utilisateurs ERP et niveaux organisationnels Les entreprises s efforcent, depuis longtemps, d intégrer par les technologies de l information et de la communication les différentes fonctions. Avec l ERP, leur rêve d intégration informatique est enfin réalisé. Plus encore, il constitue pour les décideurs un vecteur potentiel de mise en cohérence globale du fonctionnement de l entreprise. Il leur offre la promesse d une meilleure coordination dans la mesure où elle aura été pensée, organisée et outillée. Les caractéristiques intrinsèques de l ERP laissent supposer que les différents niveaux organisationnels vont être impactés : Inter-organisationnel : la mise en place d un module de CRM va toucher la gestion et la nature des relations de l entreprise avec ses clients. Organisationnel : l ERP peut constituer une opportunité pour modifier la structure de l organisation - passer d un mode d organisation hiérarchico-fonctionnelle à un mode organisé en processus - réduire les niveaux hiérarchiques - ou encore centraliser/décentraliser les fonctions. Groupe : l ERP se structure sur la base de trois formes d interdépendance : séquentielle (l output de la fonction amont constitue l input de la fonction aval), de pool (les fonctions se partagent la base de données unique), réciproque ou en boucle (l action de A déclenche l action de B qui en retour ré enclenche l action de A). Ces formes d interdépendance viennent bouleverser le système de relation et de pouvoir entre les fonctions et les acteurs. De même, la nature et l intensité des échanges entre les entités couvertes par l ERP vont être modifiées. Individuel : l ERP touche différentes dimensions du travail : parcellisation, contenu des tâches, autonomie, responsabilité, contrôle A cet égard, l ampleur du changement associé à l ERP peut être appréhendée de deux façons : En analysant à un niveau donné, la profondeur du changement observé Ou/et en évaluant, le niveau le plus touché par l implantation d un ERP. Un ensemble de travaux a jusqu à présent davantage présenté de façon globale les effets des ERP considérant l organisation comme un ensemble homogène. A ce titre, il nous semble aujourd hui important d évaluer quel est le niveau organisationnel potentiellement le plus impacté par l ERP. [Hypothèse H.1.1 : Les niveaux organisationnels ne sont pas impactés par l ERP selon la même ampleur] Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 6

7 ERP et différenciation organisationnelle L ERP pose la problématique de l alignement de l organisation sur les processus de l ERP. Comme le souligne Bouillot (1999) «le succès réside dans la recherche d un juste équilibre entre une adaptation coûteuse du progiciel à l organisation existante et la reconfiguration brutale des processus» pour s aligner sur ceux de l ERP choisi. A contrario, un certain nombre d échecs s explique en partie par le «mésalignement» entre l organisation et l ERP. Par ailleurs, il n est pas pertinent de continuer à considérer l entreprise comme un tout homogène. Notamment, certaines fonctions se caractérisent par un degré de différenciation plus important au regard d autres fonctions dont leur contexte est gouverné par des standards et des réglementations sectorielles, nationales voire internationales. Nous pouvons ainsi supposer que l ampleur du changement sera plus faible dans les fonctions se caractérisant déjà par un faible degré de différenciation c est-à-dire les fonctions de back office (administration générale) régies par des processus de gestion standards telle comptabilité/finance, contrôle de gestion. En revanche, pour les fonctions se caractérisant par un fort degré de différenciation (front office et processus industriels), l entreprise sera amenée à modifier profondément ses façons de travailler afin que ses règles de gestion soient conformes à ceux de l ERP. L usage de l informatique dans certains fonctions et auprès de certaines catégories d acteurs est très répandu. De ce point de vue, la population des organisations n est pas homogène. Ainsi l implantation de l ERP va-t-elle affecter plus particulièrement les fonctions et les individus (magasiniers par exemple) qui sont les moins familiarisés avec l informatique de gestion. Les changements induits par l implantation de l ERP sont plus locaux que globaux et ils sont très inégaux suivant les services. Ce constat paraît relativement banal au début de la vague d implantation des ERP. Mais qu en est-il dans les entreprises qui les ont largement déployés? (effet du contexte H4). L ERP se caractérise par une forme d interdépendance séquentielle. Ainsi l output de la fonction amont devient l input de la fonction aval. Ce n est pas l ERP mais le fonctionnement de l entreprise qui prédéfinit ces relations d interdépendance entre les fonctions. L ERP ne fait qu introduire une structuration plus rigoureuse et rigide de ces relations. Mais ce faisant, ce système va déstabiliser et redistribuer le pouvoir des entités. Notamment, il va limiter les marges d action de certaines fonctions qui vont se retrouver en situation de stricte dépendance, à l inverse d autres fonctions vont voir leur poids renforcé. Là aussi, l intensité du changement ne sera pas ressentie de la même façon par les entités en fonction du degré d autonomie perdue. [Hypothèse H.1.2 : L ampleur du changement est différente selon les fonctions. Les changements induits par l ERP sont plus locaux que globaux.] ERP et Organisation du travail Conformément aux études portant sur les conditions de travail des salariés ayant recours à l informatique, la démarche consistera à analyser les dimensions du travail modifiées par l ERP 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 salariés utilisant un système informatique sont davantage soumis à des règles. L ERP sur cet aspect est très contraignant dans la mesure où son fonctionnement effectif dépend de la qualité des données codifiées et du respect des séquences d actions. En revanche, il offre un accès plus autonome et rapide à l information permettant une plus grande autonomie des utilisateurs dans l accès à l information. Est-ce pour autant que les utilisateurs gagnent en autonomie d action et de décision? Nous nous interrogerons ainsi sur les nouvelles formes d autonomie et de contrôle associées à la mise en place des ERP. L ERP modifie également les relations d interdépendance entre les acteurs. En effet, les contraintes d interdépendance véhiculées par l ERP vont introduire a priori une rationalisation et une rigidification des relations entre les entités. Nous chercherons ainsi à déterminer l impact de ces contraintes d interdépendance sur la charge, le rythme de travail et la vigilance des utilisateurs. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 7

8 Enfin, on tentera d identifier les marges de manœuvre dont disposent les utilisateurs en réponse à ces contraintes (règles, interdépendance). On cherchera à identifier, entre autres, le poids des procédures informelles et les «Feuilles Excel» ad hoc reconstituées par les utilisateurs. [Hypothèse H.1.3 : l adoption d un ERP entraîne une modification du contenu du travail] ERP et hiérarchie intermédiaire Dans cette partie de l étude, on tentera d analyser l impact de l ERP sur le rôle de la hiérarchie intermédiaire. Son rôle de superviseur est-il renforcé par la traçabilité et le contrôle qu il en découle? En ayant accès à des données en temps réel et fiables, son rôle de décideur (activité de pilotage) est-il renforcé? Sa liberté d action est-elle limitée du fait d une contrainte plus importante par les autres fonctions? Enfin, partant de l hypothèse que l évaluation sur des résultats chiffrés est facilitée avec l ERP, la hiérarchie intermédiaire est soumise à un renforcement du contrôle. [Hypothèse H.1.4 :Le rôle de supervision et de pilotage de la hiérarchie intermédiaire est renforcé.] ERP et structuration des responsabilités La mise en place d un ERP va supposer que soient clarifiées les relations entre les fonctions et les acteurs de l organisation c est-à-dire qui fait quoi en termes de répartition des tâches et de responsabilité. Cette structuration de l organisation portée par la normalisation des données constitue en soi un projet d ingénierie organisationnelle. Il s agit de structurer les droits d accès à la base de données en définissant pour chaque chaîne d activité la distribution des tâches et les niveaux d habilitation (consultation, validation, modification, impression). Une précédente étude du Lagon a souligné que pour différentes raisons (faible implication, problèmes de compétences informatiques, absence préalable de réflexion sur cette cartographie des droits d accès), cette cartographie constitue une phase du projet ERP dont les enjeux sont souvent sous-estimés. A l extrême, cette structuration organisationnelle implicite se traduit par une décentralisation des niveaux de responsabilité. En d autres termes, les niveaux d habilitation associés à l ERP ne correspondent plus avec ceux de l organigramme traditionnel de l entreprise d où des sources potentielles de conflits. [Hypothèse H.1.5 : En l absence de réflexion préalable, l ERP constitue un vecteur de déstabilisation de l organigramme de l entreprise.] ERP et représentation des utilisateurs En tant que système intégré, l ERP oblige théoriquement les utilisateurs à modifier leur représentation fonctionnelle de leur système de travail au profit d une approche plus transversale du fonctionnement de leur activité. La sensibilisation des utilisateurs à cette dimension est capitale. L ERP exige que les utilisateurs s insèrent dans une vision globale du fonctionnement de l entreprise c est-à-dire qu ils soient capables d appréhender l impact de leurs décisions et des saisies sur les autres fonctions. L appropriation de cette nouvelle représentation se manifeste entre autres par une vigilance accrue. Cependant, il n y a pas de déterminisme technologique dans cette relation. Le processus d introduction de l ERP notamment les modalités de la conduite du changement sont essentielles à l évolution de la représentation du système de travail des utilisateurs. [Hypothèse H.1.6 : l ERP modifie la représentation fonctionnelle du système de travail des utilisateurs.] Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 8

9 IV.2 La conduite d un projet ERP Le processus de mise en œuvre d un projet ERP Le modèle développé par Markus et Tanis (2000) concernant le processus d implémentation des systèmes d entreprises (Entreprise Systems), dont l ERP fait partie, nous semble adéquat pour comprendre et expliquer les différentes questions soulevées par le phénomène ERP. Ce modèle est conçu en 4 phases : Formulation du problème et choix de l ERP Ingénierie Déploiement Usages et effets Figure : le cycle de vie d un projet ERP Formulation du problème et choix de l ERP (Chartering ) : durant cette phase l opportunité d acquérir un ERP est examinée sous l angle des besoins de l entreprise et de l amélioration de sa performance. Les impacts de cette acquisition sur l organisation et la stratégie de l entreprise sont définis et estimés par la direction générale. Ingénierie ( Project) : cette phase comprend toutes les activités permettant de rendre l ERP opérationnel dans les différents services concernés. Les activités de paramétrage et de configuration de l ERP y sont particulièrement cruciales. C est aussi à ce stade que sont conduites les opérations de redéfinition des processus et réalisés les développements spécifiques. L implémentation d un progiciel ERP nécessite un travail de préparation en amont qui consiste à déterminer les données fixes, le nombre de sites et de points de vente par exemple, partagées par tout le monde et les données variables, spécifiques à des situations particulières susceptibles de varier et d évoluer. Déploiement (Shakedown) : dernière phase du projet, il concerne les activités d installation de l ERP, le basculement de l ancien SI, et la formation des utilisateurs. Le déploiement peut être fait plus ou moins progressivement (par module, puis par site par exemple) ou de manière plus rapide (big-bang: tous les modules et tous les sites en une seule fois ). Par ailleurs, une période d exploitation sous contrôle de l équipe projet permet de corriger les dysfonctionnements et d optimiser le système. C est au cours de cette phase que l adéquation des fonctionnalités de l ERP aux processus organisationnels de l entreprise se concrétise. Le déploiement s achève avec la clôture du projet ERP. Usages et effets (Onward and Upward) : le ERP entre maintenant en exploitation opérationnelle, et la recherche d une amélioration de son fonctionnement passe par des cycles de maintenance. L entreprise peut se lancer dans de nouveaux projets intégrant de nouvelles applications (CRM, SCM, e-business). Ces différentes phases correspondent au cycle de vie de l ERP et peuvent être vues comme un processus continu durant lequel plusieurs tâches, activités et décisions sont réalisées et prises. Ce modèle est conçu dans une approche longitudinale qui permet d étudier le processus d implémentation et d utilisation de l ERP dans une approche de cycle de vie qui comprend la décision initiale d adoption, Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 9

10 l implémentation, les premières phases d utilisation du système, l intégration de l outil au sein de l organisation et enfin les opérations de maintenance et les futures montées de versions. Diversité et variabilité des dimensions de la conduite du projet ERP Plusieurs études et recherches académiques ont mis en évidence plusieurs facteurs clés liés au cycle de vie de l ERP qui peuvent avoir un effet sur l organisation du travail de l entreprise. Nous supposons que les facteurs de la conduite d un changement diffèrent d un projet à un autre (H.2). Ainsi, nous allons nous intéresser aux facteurs suivants : 1- L implication et le soutien de la direction générale : 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 d argents investis, l implication de la direction générale ressort comme l élément stratégique. Nous supposons que l implication et le soutien de la direction générale sont mobilisés tout au long du projet (Hypothèse H.2.1). Au-delà de l allocation des ressources nécessaires, sa participation à l élaboration des processus décisionnels est forte (Hypothèse H2.2). 2- Les objectifs de la direction générale concernant la mise en place d un ERP qui se traduisent par la définition d une vision organisationnelle cible ; les études de cas déjà réalisées dans le cadre d études précédentes ont montré que ce facteur était rarement pris en compte par les dirigeants lors de la première phase consacrée à la formalisation du problème et au choix de l ERP. Il serait ainsi très utile de vérifier si les dirigeants des PME ont accordé plus d attention à ce facteur déterminant quant au succès du projet. De même, le niveau d implication réelle des utilisateurs dans la définition de l organisation cible supportant l outil est très faible (Hypothèse H2.3), même si les utilisateurs sont souvent appelés dans la phase de formulation du problème et du choix de l ERP à fournir de l information permettant de définir cette organisation cible (Hypothèse H2.4) et les fonctionnalités de l outil (Hypothèse H2.5). 3- La diversité dans la composition et les compétences de l équipe projet (et plus particulièrement celles du chef de projet, des utilisateurs clés, des informaticiens et des consultants externes) devrait être forte (Hypothèse H.2.6). La littérature portant sur les ERP a souvent classé ce facteur en deuxième rang tout de suite après l implication de la direction générale et le considère comme garant de la qualité des décisions et des actions qui seraient engagées ultérieurement. 4- La couverture fonctionnelle : ce facteur fait référence au périmètre organisationnel touché par l ERP et donne une idée sur l ampleur des changements à réaliser. 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 stratégique et implique des changements profonds. C est pourquoi il est important de tester si la couverture fonctionnelle est forte (Hypothèse H2.7). En revanche, lorsque l ERP est choisi pour couvrir quelques fonctions de support concernant des processus standards, les considérations stratégiques deviennent secondaires, et l ampleur des changements à venir est plus faible. 5- La réingénierie des processus : un projet ERP s accompagne souvent d une redéfinition des processus. Cette tâche complexe et délicate de la reconfiguration supposant de concilier la façon dont l entreprise souhaite travailler et celle dont le système lui permettra de le faire est déterminantes dans la réussite du projet (Hypothèse H.2.8). Ce processus de préparation de l organisation en amont par les acteurs du projet, internes et externes, qui consiste à décider de ce qui doit être global, commun et partagé par tout le monde et de ce qui doit être local, spécifique et susceptible de varier selon les évolutions de l environnement détermine la phase de paramétrage et le modèle organisationnel intégré dans l ERP. 6- Le processus de paramétrage et des développements spécifiques est une des caractéristiques techniques de l ERP s inscrivant dans une logique de différenciation et Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 10

11 d adaptation de l ERP aux besoins et réalités de l entreprise. Ce facteur dépend à la fois du travail effectué en amont sur les processus, les procédures et règles de gestion de l entreprise et des compétences techniques et organisationnelles (métier) des personnes chargées de cette tâche. La qualité du partenariat à ce niveau entre les consultants est les utilisateurs clés et/ou informaticiens est garante de la qualité et de la pertinence du paramétrage réalisé. Nous nous intéresserons également aux stratégies adoptées par l entreprise pour configurer leur ERP : s oriente-t-elle dans un paramétrage fin ou bien se contente-t-elle d un paramétrage standard? (cf IV.3) 7- La stratégie de déploiement adoptée (par étape ou en big-bang) : deux tactiques de déploiement peuvent être adoptées : Big-Bang ou progressif. Le déploiement progressif est réalisé par module et/ou par site. Dans le cadre de cette approche, l expression des capacités d intégration des PGI est souvent limitée. Le changement n est pas profond car les processus organisationnels impactés ne concernent qu une partie de l organisation. En revanche, avec le déploiement en big-bang, l entreprise fait le choix d une mise en œuvre en bloc de tous les modules du PGI sur tous les sites et les effets sur l organisation et le travail des utilisateurs sont très importants. C est pourquoi il est important de tester si les entreprises adoptent une stratégie d implantation en Big-Bang (Hypothèse H.2.9). 8- La politique d habilitation de l entreprise : l existence de ce facteur, durant la conduite du projet, peut nous renseigner sur les anticipations des concepteurs concernant la politique de centralisation et de décentralisation engagée par la direction générale et du degré de responsabilisation et d autonomie attribué aux utilisateurs à travers l accès ou non à des modules et des zones de travail différents (Hypothèse H.2.10). 9- L accompagnement du changement : la conduite du changement est fondamentale pour la réussite d un projet ERP (Hypothèse H.2.11). Elle est aussi importante que la mise en oeuvre du progiciel. Afin de comprendre et d analyser la politique d accompagnement du changement technique et organisationnel de l entreprise au cas ou elle existe, nous adopterons la démarche utilisée par De Dreuzy et Akoka, qui se décline en sept champs de questionnement : les dirigeants d une part et l équipe de projet d autre part ont-ils engagé une réflexion sur les processus à changer? Ont-ils analysé les impacts par population pour déterminer les besoins d accompagnement adéquats? ont-ils identifié les résistances au changement et programmé les journées de formation (technique et métier) nécessaires? (H ), ont-ils fournit la documentation adéquate? (H ) ont-ils instauré une politique d assistance des utilisateurs à travers la création par exemple d une entité de help desk (H ). une politique de communication a-t-elle été mise en œuvre? (H ), dés les premiers pas du projet jusqu à l intégration de l ERP dans les routines de l entreprise. quelle évaluation de l ergonomie des modules de l ERP installés (tests des maquettes par les utilisateurs et l addition de nouvelles fonctionnalités par exemple)? (H ), quel degré d adaptation à l organisation locale (suivi de l évolution des contextes locaux) et de la gestion sociale (la politique de recrutement, de reconversion et de reclassement des utilisateurs)? (H ). Une fois que l ERP est installé, les utilisateurs commencent à s en servir dans leur travail quotidien. A ce niveau, d autres variables viendront réguler le processus de changement et d adaptation de l organisation du travail à l outil. Dans ce cadre, nous allons voir dans quels cas les formations assurées au cours de l utilisation de l ERP et les éventuelles modifications et changements techniques et fonctionnels qui peuvent intervenir ont un effet sur l organisation du travail de l entreprise. Le processus d appropriation des connaissances lié directement à l exploitation de l ERP (différentes fonctionnalités de l ERP, la navigation et les interactions entre les modules, etc.) et à la nouvelle Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 11

12 organisation (règles de gestion, nouvelles procédures, les processus, etc.) peut avoir aussi un effet sur l organisation 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 (hypothèses H3), on cherchera essentiellement à voir si les facteurs mis en évidence par la partie précédente (hypothèses H2) ont un impact sur le succès de l outil. Pour cela, on suppose que le niveau d implication réelle des utilisateurs et le recours à eux comme source d information dans la définition de l organisation cible et les fonctionnalités de l outil favorise l usage, les conditions de travail, mais aussi sa performance (H3.3). Outre ces hypothèses (H3.1 à H3.11.6), nous supposons que la capacité de l entreprise à garder la maîtrise d ouvrage face aux partenaires est d autant plus faible que l entreprise est de taille réduite ou qu elle manque de compétences techniques (H3.12). A ce sujet, il sera intéressant d examiner le cas d une entreprise de petite taille mais avec de fortes compétences. Quant à l influence de l ordre des étapes dans l implantation du progiciel (ordre des modules, mais aussi préalable d un Business Process Reengineering) sur les usages et la performance (H3.13), nous supposons qu une phase antérieure de BPR ou tout au moins d analyse de l activité de travail est favorable dans la plupart des cas, mais qu au niveau de l utilisateur, et notamment en PME, la réussite du projet passe d abord par l usage du nouvel outil avant toute recherche d optimisation des performances par un changement de processus. Autrement dit que vouloir à la fois changer l applicatif et le processus est une erreur. Ce qui reste à tester. Par ailleurs, pour garder les caractéristiques particulières de l entreprise, les équipes de projet tentent d introduire des adaptations à l ERP sélectionné surtout lorsque leurs processus standards n arrivent pas à répondre aux problématiques de gestion spécifiques à chaque métier et situation de travail. Cette question des développements spécifiques est également un des facteurs clés de succès d un ERP (H3.14). Nous avons montré dans une étude précédente qu ils nuisaient à la flexibilité de l outil, mais aussi à la flexibilité opérationnelle et stratégique. Toutefois, sur ce point, les résultats que nous avons obtenus tant à travers les monographies que dans l étude qualitative sont difficiles à interpréter. Sur ce sujet en particulier seul une étude qualitative approfondie pourrait permettre d aller au-delà. Il s agira, dans la mesure du possible, d examiner les adaptations apportées tant au progiciel lui-même qu aux interfaces et de les resituer dans les stratégies d intégration du système d information de gestion qu aura finalement adoptée l entreprise volontairement ou non. Notre hypothèse est que tant que l on reste sur la même version du progiciel, que les modifications sont bien circonscrites et que l entreprise a une vision claire de sa stratégie d intégration, alors les développements spécifiques n ont pas d effets négatifs sur les usages notamment car ils permettent de maintenir des pratiques antérieures et sur la performance (H3.15.1). En revanche, ils freinent les changements (H3.15.2). Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 12

13 Comment adapter un «ERP» au contexte spécifique de l entreprise Configuration Bolt-ons Des écrans masques Reporting élargi Programmation de nouveaux flux de travail Users exits Programmer l ERP Développement des interfaces Modification du code source Processus selon lequel l entreprise fixe et détermine le paramétrage des processus et transactions qui correspondent à son modèle organisationnel. (définir les structures organisationnelles, créer les états de gestion standards, les procédures à exécuter, etc.) Implémentation d une autre application informatique conçue dans le même environnement de l ERP et qui permet de répondre à un besoin particulier. (Logiciels de trésorerie, logiciels de gestion des stocks selon les dimensions spécifiques des produits, etc.). Création d écrans masque pour la saisie et l édition des données. (Intégrer trois écrans en un seul). Programmation de nouvelles options de reporting et d édition des états. (Créer de nouveaux états spécifiques à un besoin précis : état des achats d une classe de produits). Créer 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 (développer une fonction statistique pour des calculs métriques). Création d une nouvelle application dans le même environnement technique de l ERP sans changer le code source. (Une application répondant à une niche de besoin impossible à inclure dans la version standard de l ERP). Programmation de nouvelles interfaces pour faire communiquer l ERP avec les applications maintenues par l entreprise ou avec d autres modules des autres ERP. (Interface entre SAP et le CRM d oracle). Changer les codes sources pour faire face à un problème stratégique très particulier (modification du processus de la planification de la production) Tableau : la typologie des choix d adaptation de l ERP Ces différents types correspondent aux choix que les entreprises ont faits lors de la mise en place de leur ERP. L impact sur l ERP augmente au fur et à mesure que la modification change le programme initial et introduit de nouvelles fonctionnalités différentes de celles livrées dans la version standard. Une entreprise peut modifier son ERP en utilisant plusieurs combinaisons à des degrés différents suivant le contexte et les besoins exprimés. Cependant, plus les modifications dans l ERP sont importantes, plus les efforts de maintenance sont considérables. Par exemple dans le cadre d une montée de version, les ERP ayant subi des modifications poseront des problèmes d adaptation car les efforts demandés s apparentent au démarrage d un nouveau projet d implémentation d autant plus qu il serait difficile de les faire communiquer avec les SI des autres partenaires. Il sera en effet important d examiner des manifestations de «résistance au changement», par exemple à travers le maintien de pratiques antérieures (utilisation ou création de feuilles de calcul tableurs-), mais aussi de les interpréter. Est ce pour se rassurer tant que l ERP n est pas encore rodé? Pour le compléter? ou véritablement par ce qu on n en veut pas que de telles pratiques sont mises en place ou tout simplement pérennisées? Sur ce point, nous nous contenterons de partir de ces déviances apparentes pour voir en quoi elles sont contre-productives ou au contraire essentielles au bon fonctionnement de l organisation. Enfin, il y a la résistance d une autre nature qui se manifeste par des conflits ouverts et que nous avons connu sur un certain nombre de cas d ERP. Ces types de conflits sont nombreux et résolus de façon diverses. Leur documentation reste toutefois délicate, mais notre hypothèse est que la communication de la Direction Générale joue un rôle capital dans cette affaire et qu elle n est pas à mettre sur le même plan que des actions plus classique d accompagnement du changement (formation, documentation, assistance). Parmi celles-ci, il nous semble que le projet se passe mal lorsque les ressources allouées à la formation sont insuffisantes (H3.16). Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 13

14 IV.4 Les effets, la conduite du changement et la corrélation des deux phénomènes dépendent du contexte «Tout projet ERP doit être contextualisé» (Besson). En effet, l organisation évolue, prend des décisions, bouge, hésite, décide, remet en cause une idée. et les situations changent incessamment. Ainsi pour étudier les effets de la mise en place d un progiciel ERP sur l organisation de l entreprise, il est très important de ne pas isoler le contexte global de l entreprise du processus d implémentation de l ERP et des usages qu en font les différents acteurs de l organisation. Au-delà de la décision de la direction générale d adopter un ERP, il serait intéressant de caractériser l environnement (hostile ou favorable) et d évaluer son impact sur le degré d implication des futurs utilisateurs durant les différentes périodes de cycle de vie de l ERP (Hypothèse H.4). Nous nous intéresserons à quatre types de contexte : environnemental, organisationnel, culturel et technologique. Le contexte environnemental se réfère à des facteurs tels que le secteur d activité, l intensité de la concurrence, l incertitude perçue de l environnement, etc. Ainsi la mise en place d un ERP peut différer d un secteur d activité à un autre, par exemple la mise en œuvre de l ERP ne se déroulera pas de la même manière dans un hôpital public que dans une entreprise industrielle privée. De plus, les premières générations d ERP étaient destinées aux grandes entreprises du secteur industriel. Il est donc intéressant de tenir compte du secteur d activité pour expliquer le choix de l ERP et des modules installés ainsi que leurs effets sur l organisation de travail (H.4.1). Le contexte organisationnel fait référence à la taille de l entreprise, au type de structure adoptée (centralisation/décentralisation, mono-site, multi-sites). Concernant l effet taille, nous supposons que la conduite du projet dans les PME obéit à une gestion globale sous la houlette de la direction générale et se démarque d une gestion par programme adoptée largement par les grandes entreprises (H.4.2). Nous supposons que pour les entreprises centralisées, l ERP contribue à un renforcement de la centralisation de l organisation (H.4.3). Pour les entreprises qui opèrent sur des sites géographiquement dispersés, nous chercherons à savoir si la conduite du projet a été centralisée et imposée ou décentralisée et si les unités locales ont disposé d une certaine autonomie locale de décision (H.4.4). Par ailleurs, de nombreux auteurs considèrent que les spécificités culturelles sont déterminantes pour l adoption et l utilisation d un ERP. Nous avons précédemment pu constater que la mise en place d un référentiel unique d un ERP peut se heurter aux cultures locales et notamment les logiques professionnelles. Nous chercherons dans le cadre de cette étude à vérifier leur existence, leur importance et leurs effets sur la conduite du projet et durant la phase d exploitation de l outil (H.4.5). Enfin, le contexte technologique dont nous cherchons à appréhender les effets sur la conduite du projet et les usages se caractérise par le degré de maturité du système d information en place, à savoir le mode et l intensité de diffusion des TI dans l entreprise, et les caractéristiques techniques du progiciel ERP (évolutivité, modularité, unicité de la base de données, paramétrage) (H.4.4). Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 14

15 V. Méthodologie V.I. Une méthodologie fondamentalement qualitative et croisant le regard des acteurs La démarche retenue dans le cadre de cette étude est fondamentalement qualitative. Nous adopterons une approche par étude de cas qui paraît plus adaptée pour accéder à la complexité de la configuration des organisations et offre également l occasion d étudier les relations et les événements tels qu ils se sont déroulés dans les situations vécues par les acteurs. Cette étude repose essentiellement sur 6 études de cas : une grande entreprise (à noter que dans ce cas, nous étudierons plus particulièrement les effets délimités à un service ou une fonction à périmètre restreint), des PMI dans des secteurs variés. Le fait de choisir des cas aussi variés permet d obtenir des résultats plus riches, de faire ressortir leurs similitudes et leurs différences et de les relier aux contextes dans lesquels elles évoluent. Conformément à ce choix méthodologique, il convient à présent de définir les techniques de recueil de données. V.II. Le choix des techniques de recueil des données Dans cette recherche, deux techniques de recueil des données ont été retenues: entretien semi-directif individuel pour collecter des données primaires et une analyse documentaire pour disposer de données secondaires complétant et renforçant les premières. Collecte des données primaires La méthode d investigation utilisée pour la réalisation des six monographies de cette recherche repose sur des entretiens semi-directifs réalisés face à face in situ. Les entretiens ont été menés à partir d une grille d entretien préalablement définie et structurée par l équipe de travail. Ils concernent deux types d acteurs de niveaux hiérarchiques et de fonctions différentes : les concepteurs et les utilisateurs. Les concepteurs du projet : - des membres de la Direction (Directeur Général ou représentant, Directeur Administratif et Financier, Directeur du Système d Information, 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 clés Les utilisateurs sont généralement les employés habilités à utiliser l ERP dans le cadre de leur travail. La confrontation des informations provenant de ces deux familles d acteurs est indispensable à la qualité, à l exhaustivité et à la cohérence des monographies. Dans le cas d une évolution sensible pendant la période de recherche des conditions d utilisation de l ERP, nous avons mené deux entretiens à des périodes différentes avec une même 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 inhérents aux projets ERP mais toujours sensibles et vecteurs potentiels de conflits (habilitations, pouvoir, rémunération, recrutement, formation, promotion, participation, etc.). Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 15

16 La confrontation des perceptions et des informations recueillies auprès des deux familles d acteurs est indispensable pour évaluer, d une part, l existence d effets et d autres part leurs degrés. De plus, l approche qualitative que nous nous proposons de suivre nous permettra de mettre en perspective l adéquation des objectifs des concepteurs avec les perceptions des utilisateurs et la compatibilité des anticipations des premiers et des informations communiquées aux seconds. Collecte des données secondaires L utilisation des données secondaires complète les données recueillies auprès des acteurs internes et externes de l organisation. Les différents supports et documents réalisés tout au long du processus de changement ont été analysés: les comptes rendus des comités de direction, de pilotage et opérationnel, journal interne, pages Intranet et Internet dédiés soit à l équipe de projet soit aux salariés de l entreprise et aux différents partenaires etc. L analyse de ces documents permet de reconstituer pour partie, les actions passées qui ont pu influencer les différentes étape du processus de déploiement ainsi que les niveaux d utilisation de l ERP au sein de l entreprise. C est en connaissant le passé de l entreprise qu on peut le mieux apprécier et comprendre le contexte actuel et les effets constatés. Traitement qualitatif des données et règles de décisions pour l hypothèse numéro 3 Conformément à la stratégie d étude de cas, l analyse de données pour cette recherche comprend une première phase consacrée à l analyse individuelle et descriptive de chaque entreprise, et une seconde phase consacrée à l analyse transversale et explicative de l ensemble des cas étudiés. Nous tentons de mettre en lumière les facteurs de «succès» ou «d insuccès» du projet, les changements et leurs degrés, les modifications du travail des utilisateurs ainsi que des concepteurs. Nous considérons comme «succès» le fait d utiliser le système (PGI) et de déclarer en être satisfait, d une part, et de constater que ces déclarations proviennent de l ensemble des utilisateurs et acteurs du système. En cas de non-unanimité dans les déclarations nous parlerons de «semi-succès», et en cas d insuffisances importantes de déclarations de satisfaction de la part des utilisateurs et acteurs, «d échec». Concernant explicitement la famille des hypothèses H3, l étude met en évidence le rôle des caractéristiques de conduite de projet et de leurs modalités (organisation, équipe, documentation, formation, délai, etc.) en confrontant et en analysant leurs contributions aux cas de succès, semi-succès et échec. Il nous faut alors mettre en perspective les modalités des facteurs de conduite de projet et leurs contributions relatives (lorsque les facteurs sont testés conjointement) et/ou absolues (lorsqu ils le sont individuellement) aux résultats déclarés. Nous appliquons la méthode suivante : si une modalité donnée d un facteur induit un résultat de type «succès» et que -dans le même temps- l ensemble des autres modalités de ce même facteur induit des résultats de type «semi-succès» et/ou «échec», nous considérons que cette modalité de ce facteur contribue à améliorer sensiblement l effet testé. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 16

17 B. Test des quatre hypothèses du modèle de recherche Le processus de validation d une hypothèse (ou sous hypothèse) repose sur trois validations (au moins) sur les six cas analysés. Hypothèse 1 L ERP comme technologie de rupture L hypothèse H1.1 est validée L hypothèse H1.2 est validée L hypothèse H1.3 n est pas validée L hypothèse H1.4 est validée L hypothèse H1.5 est validée L hypothèse H1.6 est validée «Les niveaux organisationnels ne sont pas impactés par l ERP avec la même ampleur». Les différents cas font apparaître que les niveaux organisationnels ne sont pas impactés avec la même ampleur. En général, l encadrement intermédiaire et les services fonctionnels sont les plus concernés par la mise en place de l ERP. «L ampleur du changement est différente selon les fonctions, et les changements constatés sont plus locaux que globaux» Cependant, si les fonctions commerciales et de gestion (y compris la logistique) sont les principales concernées, dans certains cas (entreprise industrielle multinationale) c est la fonction «production» qui a vécu le plus grand changement, l ERP ayant abouti à une remise en question des logiques métiers. «L adoption d un ERP n entraîne généralement pas de modifications du contenu du travail.» Mais cette conclusion doit être atténuée car souvent les métiers sont affectés, non pas au cœur de l activité, mais dans leurs frontières respectives : ainsi, selon les cas examinés, les assistantes commerciales peuvent voir augmenter leur niveau de responsabilité et leur autonomie, et le contenu des métiers des cadres et des «utilisateursclés» peuvent être amenés à évoluer,. «L adoption de l ERP modifie fortement l autonomie de la hiérarchie intermédiaire» Le rôle de supervision et de pilotage de la hiérarchie intermédiaire est bien renforcé par l arrivée de l ERP. Un accès plus facile à une information de pilotage actualisée en temps réel permet à l encadrement une meilleure réactivité dans le contrôle et la décision. «En l absence de réflexion préalable, l ERP constitue un vecteur de déstabilisation de l organigramme des entreprises.» Dans quatre cas sur six, on constate des «prises de pouvoir» de la part d individus ou de groupes, peuvent être des «utilisateurs-clés», des membres de l équipe projet, ou encore d une direction informatique «groupe» sur celles des sites décentralisés. Cette absence de réflexion sur les conséquences socioorganisationnelles de l arrivée de l ERP se manifeste le plus souvent pas une carence de la réflexion sur les droits d accès au système. «Sous certaines conditions, l ERP modifie la représentation fonctionnelle du système de travail des utilisateurs.». Bien sûr les premiers impactés par l ERP sont ceux qui travaillent à son déploiement : DSI et utilisateurs clés, dont la représentation du système de travail est modifiée par l ERP. Mais ce sont aussi des postes de travail d autres domaines fonctionnels, comme le commercial qui voient les représentations se modifier en fonction de l évolution (déjà constatée plus haut) du contenu du travail. Conclusion : Excepté pour la sous hypothèse H1.3 (modification du contenu du travail), l hypothèse H1 est validée et l ERP constitue effectivement une technologie de rupture. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 17

18 Hypothèse 2 Les facteurs de la conduite de projet sont-ils mobilisés? L hypothèse H2.1 est validée L hypothèse H2.2 est validée L hypothèse H2.3 est validée L hypothèse H2.4 n est pas validée L hypothèse H2.5 n est pas validée L hypothèse H2.6 est validée. L hypothèse H2.7 est validée. L hypothèse H2.8 n est pas validée. L hypothèse H2.9 n est pas validée «L implication et la soutien de la direction générale sont stratégiques et doivent avoir lieu tout au long du projet». Ce sont en effet les directions qui sont le plus souvent à l origine du projet (même si parfois l inititative vient de plus haut, lors d une absorption par exemple). Ensuite, les directions suivent activement et soutiennent le déroulement du projet. «La participation de la DG à l élaboration des processus décisionnels est importante.» Le plus souvent la DG définit des objectifs stratégiques, et les autres acteurs du projet (équipe projet, consultants, intégrateurs) jouissent de délégation de pouvoir, ce qui leur permet d imposer certains choix organisationnels. Les responsables de services peuvent aussi jouer de leur pouvoir pour peser sur ces choix. «Les dirigeants définissent une cible organisationnelle. Le niveau d implication des utilisateurs dans la définition de l organisation-cible est très faible». Cet état de choses peut s expliquer par le manque de compétences des utilisateurs, mais le plus souvent les utilisateurs sont écartés 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 problème et du choix de l ERP, les utilisateurs aident à définir l organisation-cible.» La non validation de cette hypothèse est la conséquence la validation de l hypothèse précédente. On l observe dans tous les cas analysés. «Dans la phase de formulation du problème et du choix de l ERP, les utilisateurs aident à définir les fonctionnalités de l outil». De même que pour l hypothèse H.2.4, on met en avant le manque de compétence présumé des utilisateurs pour reporter sur les consultants ou sur l équipe projet, le poids de ces choix essentiels pour le succès du projet. Dans 2 cas sur 6, certains utilisateurs-clés ont été plus ou moins impliqués dans la rédaction du cahier des charges. «La diversité des compétences de l équipe projet est mobilisée». L équipe projet peut être petite, il peut y avoir en plus des intervenants extérieurs, mais dans tous les cas c est en fonction des compétences de ses membres qu elle a été composée. Et ce sont ces compétences qui sont mises à contribution dans la conduite du projet. «L étendue de la couverture fonctionnelle est élevée». Les projets étudiés ont un large spectre de modules, ils intègrent presque toujours la production et la logistique (modules métiers), et le plus souvent la fonction commerciale. La paie et la gestion des immobilisations sont parfois exclus du périmètre. L entreprise procède à un business process re-engineering (BPR) pour la mise en place de l ERP. Le BPR n apparaît pas comme un point de passage obligé lors de la mise en place d un ERP. On peut réfléchir sur les processus, les réaménager selon telle ou telle théorie 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 d implantation de l ERP. «Les entreprises ont une stratégie de déploiement «Big Bang». Dans les faits, il s avère que les entreprises ont mode de déploiement adapté à chaque situation particulière. Lorsqu il y a «Big Bang», il ne concerne généralement pas l ensemble de l ERP, mais seulement une phase ou un groupe de modules. L hypothèse H2.10 est validée. «La politique d habilitation de l entreprise est bien conforme à une représentation du modèle organisationnel projeté par la direction générale». A travers les droits d accès au système on retrouve en effet la représentation de la plus ou moins grande importance des utilisateurs, selon leur place dans l organigramme. Il est beaucoup plus rare (mais cela existe néanmoins) que la réflexion sur les habilitations aboutisse à une nouvelle organisation. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 18

19 organisation. L hypothèse H2.11 n est pas validée L hypothèse H2.12 est partiellement validée L hypothèse H2.13 est partiellement validée L hypothèse H2.14 est partiellement validée L hypothèse H2.15 n est pas validée. L hypothèse H2.16 n est pas validée. «Les besoins de formation ont été définis à partir d une analyse des impacts par la population». L échantillon 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 considère que les nouvelles compétences s acquérront par l usage (doing by learning), ou encore on traite les besoins en formation au fur et à mesure des remontées, au cas par cas. «Une documentation adéquate a été fournie aux utilisateurs». Dans trois cas sur six, c est vrai, mais ce n est pas le cas pour les trois autres entreprises. La règle de validation des hypothèses retenue (au moins 3 cas) valide donc -au moins partiellement- cette hypothèse. «Un dispositif d assistance auprès des utilisateurs a été mis en place». Là encore l échantillon se divise en deux : trois entreprises ont mis en place (en interne ou via l éditeur ou l intégrateur) une assistance utilisateurs, et trois ne l ont pas fait. L hypothèse est donc validée. «La politique de communication a été intégrée à l ensemble du projet». Pour les trois cas qui valident cette hypothèse, la communication sur le projet s intègre dans un ensemble plus vaste (projet d entreprise étendue, ), mais elle est bien spécifique à l ERP. Dans les trois autres cas, la communication est soit réduite à sa plus simple expression, soit inexistante. Dans un cas elle est externalisée. «L ergonomie du système a été intégrée dans les préoccupations du projet». Dans aucun des cas étudié, l ergonomie du système a été un souci pour les responsables. Au mieux on se préoccupe d adapter quelques interfaces écran, mais c est à la fin de la conduite du projet, il n y a pas de prise en compte de l ergonomie dans la conception du système. «Une gestion sociale des salariés a été intégrée dans les préoccupations du projet». Au mieux, (un cas) les syndicats ont été associés car l ERP impliquait une saisie par les opérateurs, ou bien on intègre un membre du CE dans l équipe projet, mais le plus souvent le projet est simplement «évoqué» en CE. Au regard des multiples hypothèses H2.x non validées (ou seulement partiellement), l hypothèse H2 n est pas validée et on peut affirmer que les facteurs de conduite de projet ne sont pas dans leur globalité mobilisés. Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 19

20 Hypothèse 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 d une approche perceptuelle du «succès».on considère ainsi comme «succès» le fait d utiliser le PGI, de déclarer en être satisfait et de constater que ces déclarations sont partagées par l ensemble des utilisateurs et acteurs du système. En cas de non-unanimité, cette situation est caractérisée comme «semi-succès». Enfin, en cas d insuffisances et d insatisfactions majeures de la part des utilisateurs et des acteurs, la situation est qualifiée d échec. A partir de cette grille d analyse, sur les 6 cas observés, nous n avons pas relevé d échec. En revanche, sur les 6 cas étudiés, 3 cas peuvent être qualifiés de succès et les 3 autres de semisuccès. Caractéristiques des cas considérés comme «succès» Le démarrage des projets est parfois difficile : dans un cas, plan de déploiement des différents modules non maîtrisé en termes de délai, contrainte de devoir réaliser des spécifiques sur des fonctionnalités critiques pour l entreprise. Dans un autre cas, la date de déploiement a été avancée d un mois, ce qui n a pas laissé la possibilité de réaliser les formations initialement prévues. Les utilisateurs ont donc perdu beaucoup de temps à assimiler par eux-mêmes les fonctionnalités du système, ce qui peut être source de stress pour certains, et de tensions entre les services. Mais paradoxalement, ces difficultés peuvent être un vecteur d appropriation du projet par l entreprise. Car l appropriation du système et les transformations qu il induit reposent alors sur l implication forte de quelques personnes-clés dans la conception et l amélioration continue du système et dans la formation continue des utilisateurs (guide d utilisation réalisé par les responsables). Après quelques mois ou années- d utilisation, l évaluation qualitative des ERP est globalement positive : ils ont permis de préciser les tâches et les responsabilités de chacun, et contribuent à renforcer la traçabilité du process et des produits. En termes organisationnels, le progiciel est perçu comme une étape indispensable et préalable à l intégration logistique globale de l entreprise et de ses partenaires majeurs. Les utilisateurs (dont les directions générales) soulignent une coordination plus efficace, une rationalisation des modes de travail, une meilleure qualité de l information (les stocks sont justes à 97%) et enfin l amélioration du service offert aux clients. D une façon générale, la satisfaction des utilisateurs s appréhende au travers de l acceptation du système : l ERP est passé du stade de contrainte à celui d outil de travail, c est le système qui fait foi et non plus le papier, les utilisateurs ont acquis le «réflexe écran». Une fois le dispositif intégré dans le fonctionnement normal de l entreprise, il est finalement considéré comme «banal» alors qu il a été perçu au départ comme «révolutionnaire» dans sa forme et sa transversalité. Caractéristiques des cas considérés comme «semi-succès» Le plus souvent c est la difficulté d une reconfiguration des processus qui a généré une insatisfaction au près des utilisateurs. L harmonisation des pratiques métiers à travers l adoption d un référentiel unique, peut aussi être entravée par la volonté des entités de renforcer leurs territoires en accentuant leurs différences. Dans certains cas, c est l intervention 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 métier dans le sens d un rôle plus important dans le processus de production qui peut être un frein (responsabilité accrue). Synthèse rédigée par Denis Bérard (Chargé de mission ANACT) Tous droits réservés réseau Anact 20