Procédure d’escalade et de résolution des conflits

La méthodologie du projet réside en itérations pendant lesquelles des phases d’analyse, d’escalade et de résolution sont prévues. Ces analyses portent sur les conflits recensés dans les cycles précédents ou issus des anomalies détectées lors des tests du cycle en cours. Le projet s’est donc organisé en utilisant trois répertoires communs, sur l’espace SharePoint, pour y rédiger la documentation et tracer les décisions prises et les modifications techniques apportées :

- Répertoire FIS-BPO : Documentation entre le consultant fonctionnel projet – référent métier :  contenant les fichiers WORD d'échange avec le métier ;

 concerne les décisions à prendre ou prise par les BPO.

- Répertoire FIS-ABAP-TEST : Documentation entre le consultant fonctionnel projet – développeur :  contenant les point de paramétrage : avant / après ;

 _{contenant les flux à tester (référence fichier Excel TEST).}

- Répertoire FIS-FIS : Documentation entre les consultants fonctionnels du projet :  contenant les conflits techniques ou fonctionnels à partager entre module ;  une fois pris en compte pour tous les FIS :

o si le conflit reste, déplacer le fichier vers FIS-BPO pour décision ; o si le conflit est résolu, déplacer le fichier vers FIS-ABAP-TEST.

7.6.1 Conflits sur les données organisationnelles

La première problématique sur lequel il a fallu statuer était la codification des données organisationnelles. Au sein du SAP du Groupe l’ensemble des entités avaient déjà été codifiées. Pour les entités non encore sur SAP, leur paramétrage organisationnel était une coquille vide ; ces codes servent avant tout pour le reporting dans la BI15_{. A l’intérieur du SAP du Groupe, les codifications des sociétés, des divisions, des domaines} commerciaux et des entités de consolidation étaient donc déjà normées.

Au sein du SAP local de Lyon, le code société a été attribué bien avant la codification définie dans le SAP du groupe et ne correspondait donc pas à la convention en vigueur. En d’autres termes, à la fusion technique, il y avait deux sociétés BOBST Lyon dans le SAP du Groupe.

Figure 37. Sociétés dans le système source.

Figure 38. Sociétés dans le système cible.

La société 1060, n’était pas utilisée dans le SAP du Groupe ; aucune écriture, ni aucun flux n’y était enregistré. Le renommage de la société 0200 – Bobst Lyon dans la société 1060 – SAM Bobst Lyon S.A.S n’était pas couvert par le contrat SLO dans le cadre du projet ; il en était de même pour les divisions et les domaines commerciaux. Il fallait donc composer avec cet état de fait. La décision prise était de garder la société 0200 et la renommer comme l’était la 1060 car la description courte de la société est une donnée exploitée dans la BI. Après le démarrage en production, la suppression de la société 1060 devait être faite.

Enfin, les entités de consolidation ont été prises en compte dans le renommage, bien que cela ne soit pas initialement prévu, car il a été possible de les fusionner à 1:1 dans les entités déjà existantes du système cible.

7.6.2 Conflits sur la base article

Dans les deux bases SAP, des articles provenant de BOBST Lyon et de BOBST Lausanne sont régulièrement créés et disposent des mêmes codes. Au cours du projet, un total de 200.000 articles avec la même codification dans les deux bases a été identifié.

De façon régulière, un fichier plat est intégré dans le SAP du Groupe, contenant les nouveaux articles provenant de BOBST Lyon. Ces nouveaux articles sont créés dans la base cible avec des règles de conversion, ce qui explique que même si les articles sont les mêmes avec les mêmes noms, les données de base divergent. Par la suite, ces articles de BOBST Lyon sont inclus dans des processus de vente client ou des processus « Business to Business ». Ces articles sont créés dans les différentes divisions des différentes entités commerciales déjà présentes dans le SAP de Lausanne.

Comme aucune homogénéisation de la base article n’a été réalisée en amont du projet et que ces articles devaient être fusionnés, ce point saillant a été remonté au différents responsables métiers ainsi qu’au comité de pilotage. La recommandation de l’équipe projet était que la base article de BOBST Lyon reste prédominante. De nombreux flux, ainsi que de nombreux développements spécifiques utilisent les données de base des articles dans le SAP de BOBST Lyon. Afin d’éviter le conflit sur un même article, il a été décidé de renommer les articles de BOBST Lyon dans la base de BOBST Lausanne avant la fusion. Ainsi tous les articles de Lyon qui étaient déjà créés dans le système cible étaient renommés par une opération appelée « Rename in Target ».

Tableau VII. Renumérotation des articles.

Système Codification article avant la fusion Division

Codification article après la fusion

Système

source PL1 SAM0389P06319 BOBST Lyon

Système cible P10 SAM0389P06319 BOBST Lausanne SAX0389P06319 BOBST Belgique BOBST Pays-Bas BOBST Espagne BOBST Allemagne

BOBST Lyon SAM0389P06319

7.6.3 Autres conflits

Bien d’autres conflits existaient entre le système SAP de Lyon et du Groupe : les équipements, les types de documents financiers, la séquence d’accès de détermination de la TVA sur les documents de ventes, etc. Au total, cent vingt-sept conflits ont été résolus par un renommage dans la base source16 _{avant une intégration} dans la base cible, et deux conflits ont été résolus par un renommage dans la base cible afin de permettre une intégration sans modification des données provenant de la base cible (les articles et les équipements).