La dynamique de la mise en cohérence .1 Des besoins non satisfaits

En effet, les corrections d’une information mobilisent souvent de nombreux utilisateurs. Il est donc essentiel de bien prévoir à l’avance les procédures de correction. Par exemple, changer une imputation analytique doit être fait par un utilisateur qui possède une vision centrale du processus. De même, le PGI amplifie les liens de dépendance entre les différents services : dans l'entreprise A le service Maintenance alimente le système qui est exploité par la comptabilité, laquelle, en retour, produit des analyses qui doivent permettre au service Maintenance de tirer des enseignements de sa propre activité.

Les liens entre les différents domaines gérés sont parfois difficiles à démêler : les procédures internes de calcul propres à SAP sont compliquées et parfois opaques. Ceci empêche par exemple, comme signalé dans l'entreprise A, d'anticiper l’impact des actions de maintenance sur la valorisation des ordres de fabrication. Ce manque de transparence, peut-être dû à un manque de connaissance approfondi du produit, se retrouve notamment dans la genèse des coûts de revient industriels. Il est donc bien important de déterminer ceux-ci rigoureusement et de bien surveiller les résultats des calculs de SAP, afin de se familiariser avec les résultats obtenus et les méthodes de calcul.

Le PGI est également perçu comme un outil d’intégration très puissant des applications informatiques. Ce point positif pour ce qui concerne les économies d'échelles et de maintenance a son revers, qui est une moindre capacité à évoluer.

Plus SAP comporte de modules, moins le système supporte des modifications, des changements dans l’organisation (comme des redécoupages dans les unités ou des changements dans la hiérarchie). C'est pourquoi subsistent, à côté du PGI, des programmes interfacés. Ainsi, dans l'entreprise B, le domaine des Achats se livrait à des ressaisies pour la comptabilité. SAP a permis de supprimer certaines redondances inutiles, mais il subsiste cependant un système de gestion des informations et des tarifs des fournisseurs localisé sur Excel et connecté avec SAP R/3.

2.2 La dynamique de la mise en cohérence

l'origine d'attentes importantes, qui se heurtent à la difficulté, classique, d'adapter un produit informatique à une utilisation particulière et à une organisation spécifique.

Quel que soit l'interlocuteur, sa fonction, son niveau opérationnel ou fonctionnel, un certain nombre de lacunes sont relevées, mais souvent d'importance secondaire. Par exemple est évoquée la mauvaise gestion de la notion d’établissement, au sein d’une société. Ce niveau d’analyse manque pour retranscrire l’activité du centre de profit administré. Cette faiblesse oblige à effectuer des retraitements pour présenter les comptes. Ou encore la notion de gisement, dans la gestion du stock, qui fait défaut.

Le stock physique n’est pas décrit finement, ce qui peut ralentir la localisation des pièces. La gestion des profils, commandant les accès différenciés aux fonctions de R/3, est également souvent décriée et son implémentation donne lieu à des débats quant à la philosophie à lui donner : soit une position restrictive, qui accorde par défaut peu d'autorisations, soit une position ouverte, qui autorise un large accès aux fonctions du PGI. La première option limite les risques de maladresse d'utilisateurs peu concernés, mais fait courir un risque de blocage, alors que la seconde option assure une meilleure flexibilité au détriment de la sûreté des saisies.

Pour beaucoup d'acteurs, tous les besoins n’ont pas trouvé de réponse satisfaisante dans SAP lors de la phase d’analyse et il a souvent été décidé de conserver une partie des anciennes applications. De toute manière, il est souvent souligné que, contrairement au mythe du PGI omnipotent, SAP ne fait que restituer l'information que l'on a bien voulu saisir. Le progiciel est basé sur une image analytique de l’entreprise : structure de coût, lignes de produits, centres de dépenses. Il n’est donc pas possible d’extraire de SAP des informations non préalablement définies.

Pour limiter ces effets réducteurs, qui s'opposent à une bonne prise en compte des besoins des utilisateurs, plusieurs éléments de réponses sont apportés de la part des participants. Certains demandent et obtiennent des dérogations dans le traitement standard du processus qui pose problème, d'autres font acte de pragmatisme et se rapprochent le plus possible des fonctions proposées par SAP, quitte à procéder à des aménagements dans les procédures de fonctionnement.

Ceci illustre bien l'importance de l'adaptation, c'est-à-dire de la cohérence entre les pratiques, routines de l'organisation et le logiciel support. Une

tentative de réponse est la réduction de la distance entre ces deux univers.

Cette démarche de convergence peut revêtir deux aspects : soit l'adaptation du PGI aux pratiques, routines, soit l'adaptation des routines au PGI. Les témoignages des participants au sujet de ces deux aspects font l'objet du développement suivant.

2.2.2 Les tentatives d'adaptation a) Construire une solution spécifique

Pour certains, la cause principale du développement de programmes spécifiques s'apparente à un manque de fermeté pour contraindre les besoins des utilisateurs au plus près du standard ou à l'absence d’une approche globale des besoins. Pour d'autres, c'est face à des problèmes de manque d’adhésion des utilisateurs, que le développement de spécifiques s’est généralisé. Une vision fonctionnaliste de ce recours existe aussi chez ceux qui y voient par exemple la faiblesse des restitutions de données standard de SAP qui ne sont pas performantes, surtout en comparaison avec d'autres systèmes pré-existant et fabriqués sur-mesure.

La méthode employée dans la phase de conception favorise ou non le recours aux développements spécifiques. Dans le cas de l'entreprise B, cette phase a impliqué beaucoup de personnes et seul le fonctionnement existant, peu ou prou, a été exprimé. Les processus n’ont donc pas été remis à plat et ont donc perduré avec leurs spécificités. Les techniciens, les gestionnaires, les acheteurs et les comptables ont reconduit leur manière de travailler. Les positions de chacun étant maintenues, seul le recours aux programmes spécifiques a permis de reconduire l'existant dans un nouveau système construit sur SAP. Au contraire, dans l'entreprise A, la décision préalable de rester très proche du standard a influencé la phase de conception dans le sens de l'adaptation des besoins à l'offre du PGI.

Enfin, certains notent la difficulté générale à exprimer des besoins ou encore l'action de groupes de pressions aux intérêts divergents, pour expliquer le recours aux développements spécifiques. Car ceux-ci constituent une sorte d'argument de négociation qui peut servir à réhabiliter des visions distinctes et incompatibles au sein d’un même outil.

b) Adapter les routines au PGI

Les projets SAP peuvent fournir l'occasion de revoir les processus de l'entreprise et procéder à leur optimisation. Une approche classique consiste à travailler d'abord sur les types de données avant de s'intéresser aux processus de gestion. Ainsi, dans la société B, les types de commande ont été revus, cette rationalisation ayant entraîné un gain de temps dans leur gestion.

Pour la société A, un principe général retenu, vu comme une condition d'un fonctionnement optimal de SAP, a plutôt été l’adaptation au produit. Il est rappelé la prééminence de SAP et privilégié une approche pragmatique : même si certaines règles paraissent difficiles à utiliser ou à maîtriser, il faut tirer parti du nouveau système et l’utiliser au mieux, quitte à trouver de nouvelles solutions d’organisation ou de nouvelles procédures.

D'autres regrettent que le projet n'ait pas donné lieu à une refonte des processus.

Pour eux, il aurait fallu profiter du projet pour imposer des nouvelles règles de gestion, par exemple le niveau de détail d'une demande de travail (doit-on faire une telle demande pour commander une souris d’ordinateur ou globaliser dans un ensemble moins détaillé ?).

Dans certains cas, l'adaptation a été forcée car le PGI ne proposait pas de véritables alternatives, seulement des processus relativement structurants pour l’organisation du service. Par exemple, l'entreprise B a du réaliser l'éclatement forcé de l’arrivage distribution en plusieurs pôles distincts car SAP prévoit une organisation bien particulière, avec des procédures déterminées.

Beaucoup de commentaires sont exprimés sur la notion de standardisation impliquée par SAP. Il s'agit ici surtout d'une mesure de l'écart entre ce que propose SAP dans une version basique et simple (le standard) et SAP agrémenté d'ajouts fonctionnels dédiés au traitement de certaines fonctions bien spécifiques.

Pour l'entreprise B, la standardisation a essentiellement concerné le module de gestion des Immobilisations, par décision du siège et malgré les demandes du site. La volonté de préserver pour le futur des possibilités de consolidation est ici mise en avant. Cependant, chaque unité ou service tenant à faire prendre en compte ses

propres besoins, il y a eu des débats sur les outils existants et les liaisons avec SAP.

Dans ce cas précis, les demandes ont été écoutées, avec la réalisation de programmes spécifiques.

Comme SAP est un produit universel, il existe un intérêt naturel à "rentrer dans le moule" et à utiliser toutes les fonctions proposées. Le problème est de rester dans le standard de SAP. Comme le PGI est complexe, il paraît plus efficace de s’adapter à l’outil, qui propose souvent une modélisation des processus séduisante. Cependant, une mise en œuvre proche du standard se heurte parfois à un manque d’éducation du management, trop rigide sur la forme, ou à une formation insuffisante des utilisateurs.

L'intérêt principal de suivre la norme de base de SAP est de pouvoir faire évoluer le PGI à moindre frais et, éventuellement, profiter des évolutions fonctionnelles proposées par la consolidation des besoins des clients de l'éditeur.

En outre, les changements de version ne sont satisfaisants que si l'on est proche du standard. En effet, un inconvénient souvent signalé est la course aux changements de version, avec parfois l’impression de rétrograder. Ceux-ci sont issus de la stratégie commerciale de l'éditeur et sont difficiles à refuser ou différer, car manquer un changement de version peut porter préjudice aux évolutions futures du produit. A contrario, modifier une version alors que son utilisation est stabilisée peut provoquer des désordres non souhaités.

D'une manière générale, si l'on suit la dynamique de l'éditeur, il n’y a pas beaucoup de périodes de stabilisation car les versions successives font évoluer en permanence les périmètres fonctionnels des modules. Selon les acteurs interrogés, trop de versions différentes sont commercialisées, à un rythme trop élevé. De plus, la progression doit être cumulative. Comme chaque modification peut avoir des impacts sur de nombreux modules, il faut à chaque fois tenir compte de ce qui est déjà installé, ce qui représente en soit un travail, peu productif.

Enfin, les acteurs s'accordent pour admettre qu'il apparaît difficile d'échapper à la standardisation. Pour rendre celle-ci plus acceptable, SAP propose des zones

réservées aux utilisateurs, permettant d’introduire une petite dose de créativité et préservées lors des changements de version.