• Aucun résultat trouvé

4.6 Organisation projet

4.6.3 La gestion des transports

Afin de garantir la stabilité du système, les transports des développements se doivent de suivre un processus strict incluant de la coordination pour l'exécution des tâches sur les différents systèmes impactés: SAP, applications tierces, intergiciels EAI et ETL.

Lors de chaque développement sur SAP, au moment de l'enregistrement du code le système réclame au développeur de fournir une clef appelée requête de transport. L'ensemble du nouveau code et des objets impactés se trouve ainsi automatiquement attaché à la requête qui constituera la référence unique du transport sur tout le paysage applicatif. Si plusieurs développeurs travaillent en sauvegardant leurs développements sur la même requête de transport, alors des tâches seront créées pour chacun d'eux sur cette dernière. Une fois que la requête est transférée vers un autre environnement, alors elle est automatiquement fermée et il faudra en ouvrir une nouvelle pour procéder à de nouveaux changements sur le même programme. L'illustration ci-dessous représente une requête de transport SAP assignée à un groupe nommé « MA4_73 ». Tous les développements de ce groupe seront transportés à la même date dans les environnements de simulation métier et production.

Robial Benoît - Mise en place d'interfaces dans le cadre d'un projet d'implémentation du PGI SAP ECC

Afin d'assigner chaque développement à une entrée Mercury de type erreur ou demande de changement, un outil de création de transport fut créé ainsi qu'une interface répliquant vers SAP les éléments de la liste des problèmes de l'outil de gestion de la qualité. Ainsi, il n'est plus possible de créer des requêtes de transport SAP sans les assigner à une erreur ou à une demande de changement suivie sur le projet. Grâce à ce lien, tous les transports sont gérés directement sur l'outil Mercury.

Les intergiciels WebMethods et DataStage ne disposent pas de mécanismes de clefs de transport similaire à ce qu'il existe sur SAP. Pour pallier ce problème important dans un contexte constitué de nombreux développements, un outil spécifique appelé TrackDev fut conçu afin de suivre les transports relatifs aux intergiciels. Tel que pour SAP, cet outil est lui aussi connecté via une interface à la liste des problèmes référencés sur Mercury. Les développements sur les applications tierces ne disposent quant à eux d'aucun service de suivi des transports. Réalisé manuellement, ce suivi requiert ainsi beaucoup de rigueur.

La gestion de l'ensemble des transports du projet est assurée par une équipe dédiée nommée « Outlook release managers ». Cette équipe définit un calendrier de transport ainsi que des numéros de version. Chaque transport se doit de suivre le calendrier, mis à part ceux dont la classification dans Mercury est spécifiée comme urgente. Pour éviter les abus, un processus de validation des transports urgents a été mis en place sur le projet. L'illustration ci-dessous représente un exemple du calendrier de transport Outlook incluant les versions allant de 4.6 à 4.73.

Robial Benoît - Mise en place d'interfaces dans le cadre d'un projet d'implémentation du PGI SAP ECC

5

Cas 1: Intégration des clients et de leur hiérarchie avec

l'application CDM

Pour tout progiciel de gestion intégré installé dans une entreprise œuvrant dans le domaine de l'industrie, les données sur les clients constituent des éléments essentiels à l'exécution de la majorité des processus métier. A travers le module Sales and Distribution (SD) SAP dispose d'outils complets pour gérer les informations sur les clients ainsi que la hiérarchie de ces derniers. Hiérarchiser les clients en fonction de leur structure en divisions et filiales permet de gérer des politiques de prix ou des paramètres de configuration fonctionnelle au niveau le plus fin ou le plus général selon les besoins du métier. L'illustration ci-après représente un exemple de hiérarchie pour le groupe français PSA.

Illustration 26: Exemple de hiérarchie de clients pour le groupe PSA.

Grâce à cette modélisation, il est possible pour une entreprise d'équipement dans le domaine de l'automobile de disposer de politiques de prix qui seront définies soit pour l'ensemble du groupe PSA, soit pour un sous groupe ou un client en particulier.

Lors des analyses fonctionnelles, il fut décidé d'adapter à SAP le processus utilisé avec BPCS, l'ancien PGI de Givaudan. Ainsi, les nouveaux clients doivent être créés directement dans le système SAP tandis que la hiérarchie de ces derniers est maintenue dans une application tierce appelée CDM, acronyme de « Customer Data Management ». Il est donc nécessaire de mettre en place deux interfaces. La première, de SAP vers CDM aura pour objectif d'envoyer à ce second tous les nouveaux clients ainsi que les mises à jour sur leurs données. La seconde, de CDM vers SAP chargera la hiérarchie des clients et la synchronisera à chaque changement.

Au cours des prochains paragraphes une étude de conception analysera en détail ces deux interfaces. La phase de migration des données ainsi que le fonctionnement du processus de gestion des clients en condition d'exploitation seront aussi abordés.

Robial Benoît - Mise en place d'interfaces dans le cadre d'un projet d'implémentation du PGI SAP ECC