Rapport BOUCHKARA Yassine VF [PDF]

Avant-propos Nom et prénom de l’élève stagiaire : Yassine BOUCHKARA Intitulé du travail : Intégration des domaines fonct

42 0 4MB

Report DMCA / Copyright

DOWNLOAD PDF FILE

Rapport BOUCHKARA Yassine VF [PDF]

  • 0 0 0
  • Gefällt Ihnen dieses papier und der download? Sie können Ihre eigene PDF-Datei in wenigen Minuten kostenlos online veröffentlichen! Anmelden
Datei wird geladen, bitte warten...
Zitiervorschau

Avant-propos Nom et prénom de l’élève stagiaire : Yassine BOUCHKARA Intitulé du travail : Intégration des domaines fonctionnels et applicatifs SAP ECC : MM, PM, FI & CO, dans le terminal méthanier de Dunkerque Etablissement d’accueil : IBM France Nom et prénom de l’encadrant du projet dans l’établissement d’accueil : M.Stephane ROGER, Chef de projet M.Gilles BACQUET, Consultant senior SCM SAP Nom et prénom du directeur du projet pédagogique : Mme. Nathalie SAUER, Encadrante pédagogique de l'UL M. Noureddine MOTAKI, Encadrant pédagogique de l'ENSAT Date de début et de fin du stage : Du 06 Février au 06 Août 2015 Cadre de coopération : Parcours de Co-diplomation dans le cadre du partenariat entre l'ENSAT et l'UL Soutien financier : Stage rémunéré

I

Dédicaces A mes parents, source de tendresse, Pour votre amour, votre soutien inconditionnel, vos sacrifices, votre patience et votre dévouement. Nul mot ne pourrait exprimer ma gratitude envers vous… Grâce à vous, je suis fier d’exceller et réaliser mon rêve. Je vous en suis reconnaissant à jamais. Que Dieu vous procure la santé et longue vie. A ma sœur Karima et mon frère Tarik, qui comptent beaucoup pour moi, C’est dans le même nid que nous avons grandi. L’enfance s’est bien vite enfuie et nous étions avides de connaître la vie, aussi nous avons suivi les chemins qui nous menaient vers nos destins, ils nous ont quelquefois éloignés pourtant je ne vous ai jamais oublié et de savoir que vous êtes quelque part même loin de mon regard me remplissent de bonheur. Je t’aime ma grande sœur, mon frère. A ma tante Latifa HDIDOU, ma cousine Aicha MACHOUAT et l’ensemble de ma famille Pour vos encouragements, vos prières si nombreuses et pour avoir pris soin de moi. A tous mes amis GIND Pour votre amitié et votre soutien. Que ces années à l’école ne soient qu’un avant-goût de tout ce qui est encore à venir. Je vous aime de tout mon cœur. A Mohamed Yamine ZETTI et Abdelkarim FASSINI, Vous trouvez ici l’expression de mon plus grand attachement, pour m’avoir encouragé et aidé durant les moments difficiles. A tous ceux que j’estime, amis de longue date ou connus à l’école, mais que je ne peux tous citer. Je vous dédie cet humble travail

II

Remerciements Je tiens à adresser mes vifs remerciements à toute personne contribuant de près ou de loin à l’élaboration de cet humble travail. Que ceux qui ne sont pas mentionnés ne m’en tiennent pas rigueur. Je remercie Madame Nathalie SAUER, responsable de la formation M2 SPIM GSI, d'avoir accepté de m'encadrer et de me guider tout au long de cette expérience. Je souhaite remercier mon encadrant Monsieur Noureddine MOTAKI, enseignant chercheur à l'ENSAT, d'avoir partagé avec moi sa passion contagieuse, ses connaissances, de m'avoir toujours soutenu et aidé. J'ai grandement apprécié son implication et son expérience tout au long de ces trois dernières années. Vous avez été un excellent encadrant, merci pour votre travail acharné à mes côtés cher maitre. Je tenais vivement à remercier Monsieur Stephane ROGER Chef de projet et Monsieur Gilles BACQUET consultant sénior SCM SAP, pour l'encadrement et tous les conseils dont j'ai bénéficié au cours des six mois que j'ai eu l'opportunité de passer à vos côtés. Comme je remercie l'ensemble de l'équipe projet Mr. Rene MONEKENE, Mr. Mohamed amine SALHI, Mme. Elodie MENDES, Mr. Hironui BOOSIE, Mr. Florencio GONZALEZ qui m'ont témoignés le professionnalisme, la disponibilité et toute l'attention et qui ont grandement contribué à la réussite de ce stage. J'adresse mes spéciales remerciements à ma grande famille GIND pour exprimer toute ma reconnaissance et vous dire à quel point je suis fière de vous avoir comme amis ,votre présence, soutien et écoute m'ont permis de remonter la pente. Merci pour les moments extraordinaires et atypiques que nous avons partagés durant les 3 dernières années. Je remercie aussi l'ensemble de mes amis et mes sincères gratitudes pour tout le cadre professoral de l’ENSAT, pour la formation qu’il m’a inculquée. Enfin, je tenais à dire à Monsieur Oualid KAMMACH un merci sincère pour votre soutien, votre enseignement et vos conseils tout au long de ces années qui viennent de s'écouler. Vous êtes le professeur qui a réussi à m'inspirer, à me donner la confiance en moi et en l'avenir, mais aussi qui a réussi à me donner l'envie d'apprendre.

III

Résumé Ce rapport synthétise le travail réalisé dans le cadre de mon projet de fin d’études qui a duré six mois au sein du service de conseil et d’intégration de l’entreprise IBM France, pour la mention Ingénieur d’état en Industriel et Logistique de l’Ecole Nationale des Sciences Appliquées de Tanger (ENSAT), ainsi que pour la mention Master en Génie des Systèmes Industriels de l’université de Lorraine. Ce rapport décrit de façon précise la période que j’ai passée chez IBM comme étant Consultant Fonctionnel SAP. Au cours de cette période, j’ai fait partie de l’équipe des consultants fonctionnels Supply Chain Management, responsable de l’intégration du nouveau système d’information, pour le compte de Dunkerque LNG dans le terminal méthanier basé à Dunkerque. Assurément, ce projet est le deuxième plus important chantier industriel en France, après le projet de la centrale nucléaire de Flamanville. En tant que consultant fonctionnel SAP, j’ai commencé par l’analyse des processus métiers du client. Par la suite, je suis intervenu dans le cadre des ateliers fonctionnels afin de recenser les besoins de notre client avant d’entamer la rédaction des dossiers de spécifications fonctionnelles et de conception. Après le paramétrage et la réalisation, j’ai été amené à réaliser les tests fonctionnels dans l’objectif de valider la solution SAP réalisée. Ensuite j’ai rédigé le livrable des tests unitaires du domaine de la maintenance, en plus du livrable qui contient les scénarios des tests d’intégration que nous avons présentés au client pour la validation de la solution SAP. Et enfin, j’ai préparé les programmes de chargement des données dans SAP via LSMW. L’implémentation de ce projet adopte une méthodologie de projet SAP développée par IBM. L’objectif étant d’assurer un déploiement rapide et réussi, l’implication du client et l’ensemble des collaborateurs est un acte décisif pour son succès, et sur lequel, évidemment, s’articule cette méthodologie, qui assure, en outre, un déroulement bien anticipé de toutes les phases du projet et par conséquent, bien maitrisé. Le cadre de mon intervention sur le projet s’est étalé sur une diversité de domaines allant de la maintenance (PM), la gestion des articles (MM), jusqu’à la comptabilité financière (FI) et le contrôle de gestion (CO).

IV

Abstract This report summarizes the work done as part of the final project assignment, which lasted six months within the consulting and integration department of IBM France for the chartered Engineer degree in Industrial and Logistics of the National School of Applied Sciences of Tangier (ENSAT) as well as the Master's degree in Industrial System Engineering of the University of Lorraine. The present report describes the work realized within this internship by the IBM team of consultants, myself included. In fact, I was part of the functional consultants Supply Chain Management’s that is responsible for the integration of the new ERP software or Dunkerque in the methane terminal in Dunkirk. Actually, this project is the second largest industrial site in France after the nuclear plant Flamanville project. On the one hand, I first began by analyzing the customer’s business processes before intervening via functional workshops to identify the customer’s needs, after which I took part of the drafting of the functional specification and design documents. On the other, I also took part in the functional testing that aims to validate the realized SAP solution. In addition, I wrote the deliverable regarding the unitarian maintenance tests and the deliverable containing the integration testing scenarios we presented to the client for validation of the SAP solution. Finally, I prepared the data loading programs via SAP LSMW.

The implementation of this project adopted an SAP project methodology developed by IBM. The main objective being to ensure a rapid and successful deployment of the solution customer involvement is a key ingredient to the success of the project. Therefore, the methodology is structured around client validation in addition to a precise and early planning of all project phases.

As a member of the working group, I had the opportunity to intervene in different modules: maintenance (PM), material management (MM) to financial accounting (FI) and Management Controlling (CO).

V

‫ملخص‬ ‫َّحي ِم‬ ‫بسم هللا الرَّحْ َم ِن الر ِ‬

‫التقدير الذي بين يديكم يلخص مجمل العمل الذي تم تنفيذه في إطار مشروعي للتخرج الذي دام ستة أشهر‪ ،‬والذي زاولت‬ ‫أثنائه مهمة مستشار وظيفي ‪ SAP‬داخل مؤسسة ‪ IBM‬بفرنسا‪ ،‬وذلك لحيازة دبلوم مهندس دولة بشعبة الهندسة الصناعية‬ ‫والخدمات اللوجيستيكية بالمدرسة الوطنية للعلوم التطبيقية بطنجة‪ ،‬وكذا شهادة الماجيستير في نظم الهندسة الصناعية بجامعة‬ ‫لورين بفرنسا‪ .‬يشمل هذا التقرير وصفا دقيقا لمختلف المراحل التي أمضيتها كمستشار وظيفي بـ ‪. IBM‬‬

‫أثناء هذه الفترة‪ ،‬كنت مسؤوال على إدماج النظام المعلوماتي لـ »‪ «Dunkerque LNG‬المتواجد بمحطة للغاز الطبيعي‬ ‫ب دونكيرك ‪ .‬وتجدر اإلشارة إلى أن هذا المشروع يعد ثاني أكبر مشروع صناعي بفرنسا‪ ،‬يتصدره مشروع المحطة‬ ‫النووية » ‪. « Flamanville‬‬ ‫بصفتي مستشارا وظيفيا ‪ ، SAP‬توجب علي القيام بمجموعة من المهام كان من أبرزها ‪:‬‬ ‫‪1‬ـ تحليل طريقة سير العمل و األنشطة المزاولة من قبل الزبون ‪،‬ومن ثم جرد احتياجاته جميعها عبر ورشات عمل وظيفية‪،‬‬ ‫الشيئان اللذان أعانني على تحرير دفتر التحمالت ‪.‬‬ ‫‪2‬ـ إضفاء تعديالت على النظام ليتوافق مع متطلبات الزبون‪ ،‬و إنجاز اختبارات للتأكد من نجاعة الحلول المقترحة‪.‬‬ ‫‪3‬ـ تدوين المراحل السابقة و االحتفاظ بها كمراجع بعد مصادقة الزبون على الحلول المقترحة‪.‬‬ ‫أخيرا‪ ،‬إعداد برامج لتحميل البيانات على ‪ SAP‬باالستعانة بالتطبيق ‪. LSMW‬‬

‫ولتخطي مختلف الرهانات التي واجهها المشروع‪ ،‬عمدت شركة ‪ IBM‬إلى تبني استراتيجية واضحة تضمن إدماج مختلف‬ ‫الموظفين المعنيين في اتخاد القرار وحثهم على احترام المواعيد والمدة الزمنية المخصَّصة لكل مرحلة من مراحل المشروع‬ ‫وحيثياتها‪ ،‬مما يضمن جودة العمل واإللتزام بموعد التسليم وبالتالي كسب ثقة الزبون‪.‬‬ ‫و أخيرا‪ ،‬فمن خالل مزاولتي لمختلف المهام األنف ذكرها‪ ،‬استطعت أن أوسع مجال معرفتي ليشمل الوحدات" ‪، " PM‬‬ ‫"‪."CO"، "FI"،"MM‬‬

‫‪VI‬‬

Table des matières Avant-propos ............................................................................................................................. I Dédicaces .................................................................................................................................. II Remerciements ....................................................................................................................... III Résumé .................................................................................................................................... IV Abstract .................................................................................................................................... V ‫ ملخص‬......................................................................................................................................... VI Liste des figures ....................................................................................................................... X Liste des tableaux ................................................................................................................... XI Liste des abréviations ............................................................................................................XII Glossaire ............................................................................................................................... XIII Introduction .............................................................................................................................. 1 Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet ..................... 1 1.

2.

3.

Organisme d’accueil : IBM ......................................................................................................... 1 1.1

IBM – Présentation .............................................................................................................. 1

1.2

IBM – Chiffres clés ............................................................................................................. 1

1.3

IBM – Service Line SAP ..................................................................................................... 1

Client : Groupe EDF.................................................................................................................... 4 2.1

EDF – Présentation .............................................................................................................. 4

2.2

EDF – Chiffres clés ............................................................................................................. 4

Cadrage du projet ........................................................................................................................ 5 3.1

Contexte du projet ............................................................................................................... 5

3.2

Cahier des charges ............................................................................................................... 6

3.3

Facteurs clés de succès ........................................................................................................ 8

Chapitre 2 : La solution pré-packagée IBM Express pour SAP ..................................................... 10 1.

Introduction ...................................................................................................................... 11

2. Présentation générale des ERP ....................................................................................... 11 2.1

Définition ............................................................................................................... 11

2.2

Les ERP : Pour qui ? Pourquoi ? ....................................................................................... 12

2.3

Architecture modulaire des ERP ........................................................................... 13

VII

3.

Les impératifs du projet et l’approche IBM .............................................................................. 15

3.1 Définition de la solution IBM Express ...................................................................................... 16 3.2 Les raisons du choix de la solution............................................................................................ 17 3.3 Les bénéfices de la solution IBM Express................................................................................. 18

Chapitre 3 : Démarche de mise en œuvre du projet ........................................................... 20 1.

2.

3.

4.

La méthodologie IBM Express adaptée aux solutions pré-packagées....................................... 21 1.1

Quick Scan ........................................................................................................................ 21

1.2

Validation .......................................................................................................................... 23

1.3

Activation .......................................................................................................................... 24

1.4

Simulation ......................................................................................................................... 27

1.5

Go Live & Support ............................................................................................................ 32

1.6

Maintenance ...................................................................................................................... 32

Gestion de projet ....................................................................................................................... 32 2.1

Procédure de gestion des risques et de la qualité............................................................... 33

2.2

Points-clés des revues de jalons ........................................................................................ 34

2.3

Organisation du projet ....................................................................................................... 35

2.4

Matrice des responsabilités – RACI .................................................................................. 38

Architecture technique............................................................................................................... 42 3.1

Définition de la plateforme technique ............................................................................... 42

3.2

Le paysage SAP................................................................................................................. 42

La gestion du transfert des connaissances ................................................................................. 43

Chapitre 4 : Focus sur la stratégie globale de reprise des données ................................... 46 1.

Introduction : Démarche de mise en œuvre ............................................................................... 47

2.

Description des besoins ............................................................................................................. 48

3.

Définition des données cibles dans SAP ................................................................................... 48 3.1

Données de base ................................................................................................................ 48

3.2

Données de paramétrage.................................................................................................... 49

3.3

Données transactionnelles ................................................................................................. 49

4.

Méthodologie de la reprise ........................................................................................................ 49

5.

Planning de la reprise ................................................................................................................ 54 5.1

Tests de reprise de données ............................................................................................... 54

VIII

5.1.1

Préparation des fichiers d’échantillons .......................................................................... 54

5.1.2

Contrôle et validation des fichiers chargés .................................................................... 55

5.1.3

Exécution des processus associés à ces chargements .................................................... 55

5.2

6.

Tir à blanc .......................................................................................................................... 55

5.2.1

Préparation des fichiers de reprise ................................................................................. 55

5.2.2

Contrôle et validation des fichiers chargés .................................................................... 55

5.2.3

Exécution des processus associés à ces chargements .................................................... 56

Phases de tests de reprise de données ........................................................................................ 56

Bilan et livrables par phase du projet .................................................................................. 58 Conclusion générale et perspectives ..................................................................................... 62 Bibliographie .......................................................................................................................... 63 Webographie ........................................................................................................................... 63 Annexes ................................................................................................................................... 64

IX

Liste des figures Figure 1 : Métiers d’IBM ........................................................................................................................ 1 Figure 2 : Force des prestataires de services SAP ................................................................................... 2 Figure 3 : Logo du Groupe EDF.............................................................................................................. 4 Figure 4 : Expression de besoin, le diagramme "Bête à cornes" ............................................................. 6 Figure 5 : Organigramme de l’équipe projet ........................................................................................... 7 Figure 6 : Diagramme de gant prévisionnel ............................................................................................ 8 Figure 7 : Eléments constitutifs de la solution IBM Express ................................................................ 16 Figure 8 : Solution pré-packagée IBM Express .................................................................................... 16 Figure 9 : Importance relative des différents chantiers selon la démarche adoptée .............................. 18 Figure 10 : Maison IBM Express .......................................................................................................... 19 Figure 11 : Etapes et démarches du projet............................................................................................. 21 Figure 12 : Déroulement des ateliers de présentation de Quick Scan ................................................... 22 Figure 13 : Déroulement des ateliers de convergence en phase de Validation ..................................... 24 Figure 14 : Démarche des rôles et autorisations .................................................................................... 27 Figure 15: Décomposition du paysage SAP .......................................................................................... 43 Figure 16 : Axes de transfert des connaissances ................................................................................... 44 Figure 17: Elaboration des jalons pour les sessions de formation ......................................................... 45 Figure 18 : Cheminement méthodologique de reprise de données ........................................................ 50 Figure 19: Log d’exécution du programme de chargement .................................................................. 52 Figure 20 : Protocole pour le détail des messages d’erreurs ................................................................. 53 Figure 21: Planning des tests de reprise de données ............................................................................. 54 Figure 22 : Cycles de chargement des données ..................................................................................... 57

X

Liste des tableaux Tableau 1: Chiffres clés d’IBM ............................................................................................................... 1 Tableau 2 : Service SAP d’IBM en France ............................................................................................. 3 Tableau 3 : Chiffres clés du Groupe EDF ............................................................................................... 4 Tableau 4 : Rôles et autorisations du domaine de la maintenance ........................................................ 26 Tableau 5 : Détection et prise en charge de l’anomalie ......................................................................... 30 Tableau 6 : Analyse d’impacts des anomalies ....................................................................................... 30 Tableau 7: Corrections et re-tests des anomalies................................................................................... 31 Tableau 8: Clôture des anomalies.......................................................................................................... 31 Tableau 9 : Procédure de gestion des risques et de la qualité................................................................ 34 Tableau 10 : Instances proposées pour le suivi du projet ...................................................................... 37 Tableau 11 : Matrice RACI ................................................................................................................... 41 Tableau 12 : Bilan et livrables du projet ............................................................................................... 61

XI

Liste des abréviations ABAP : Advanced Business Application Programming AMOA : Assistance Maitrise d’ouvrage CRM : Customer relationship management DEV : Développement EAI : Enterprise Application Integration ENSAT : École nationale des sciences appliquées de Tanger ERP : Entreprise Ressource Planning FRICE : Forms, Reports, Interfaces, Conversions and Enhancements IT : Information technology LSMW : Legacy System Migration Workbench MOA : Maîtrise d’ouvrage MOE : Maîtrise d’œuvre PAQ : Plan Assurance Qualité PME : Petite et Moyenne Entreprise PROD : Production QUAL : Qualité ou Qualification RACI : Responsible, Accountable, Consulted, Informed SAP : Systems, applications, and products for data processing SAP CO : SAP Controlling SAP ECC : SAP ERP Central Component SAP FI : SAP Finance SAP MM : SAP Material Management SAP PM : SAP Plant Maintenance SI : Système d’Information SOA : Services Oriented Architecture SRM : Supplier Relationship Management TMA : Tierce Maintenance Applicative UL : Université de Lorraine

XII

Glossaire Avis : C’est l’objet qui peut servir à introduire une demande d’intervention ou à mentionner un dysfonctionnement demandant une intervention de réparation. Bac à sable : un mandant de test, dans lequel les consultants testent leur travail. Blueprint : Conception d’une solution appropriée aux spécifications de l’entreprise. Log : Un fichier où on retrouve en particulier les messages d'erreurs générés par l'application. Go Live : La phase où le système est utilisé dans les processus quotidiens et réels de production. Mandant : Unité indépendante d’un point de vue commercial, organisationnel et technique dans un système SAP. Les mandants possèdent leurs propres fiches et ensembles de tables Sap.Com. Ordre de travail : C’est l’objet par lequel on gère la réalisation (exécution) de toute intervention, tant du point de vue de la préparation et planification avant l'intervention. Reporting : C’est l'opération consistant, pour une entreprise, à faire rapport de son activité. SAP Best Practices : un système préconfiguré spécifiquement conçu pour soutenir les processus métier de bout-en-bout pour les besoins de l'industrie et du marché génériques ou spécifiques. Ils sont basés sur une méthodologie de blocs de construction, fournissant une plus grande souplesse pour répondre aux besoins d'affaires uniques, tout en abordant simultanément les opérations commerciales clés.

XIII

Introduction Dans leur recherche d’évolution dans un environnement de plus en plus complexe et changeant, et afin de confronter les autres marchés et la compétitivité accrue, de s’aligner stratégiquement avec sa vocation, ainsi que d’assurer une communication en temps réel entre les différentes filiales, le terminal méthanier de Dunkerque tente d’intégrer un nouveau système d’information pour donner un nouveau souffle au département SI. Ce nouveau système propose l'intégration des principaux processus de l'entreprise et la mise en place d'un système d'information cohérent garantissant l'unicité de l'information et l'accès à celle-ci à partir de toutes les fonctions de l'entreprise. Dans cette optique, le client souhaite revoir ses processus métiers pour réaliser en permanence des améliorations et réduire les coûts. Une amélioration continue qui exige un niveau élevé de gestion et de contrôle des processus clés de sa chaîne logistique, de sa comptabilité financière et de son contrôle de gestion. L’objectif est de déployer des processus métiers souples et efficaces dans le but de simplifier la gestion des flux métiers, d’améliorer la traçabilité, d’assurer la cohérence entre les domaines fonctionnels et de réduire les coûts et les délais. Plusieurs possibilités permettent évidemment de réaliser cet objectif stratégique et de prendre en grande considération la complexité du périmètre concerné. SAP ERP reste toutefois la solution la plus adéquate pour parvenir à cette visée, notamment, par les bonnes pratiques métiers prédéfinies et recommandées par les experts SAP, et aussi, par la fiabilité et l’adaptabilité de la solution informatique proposée. A travers ce rapport, fruit de mon travail, je décris les différentes étapes parcourues afin de venir à bout de mon projet. Celui-ci s’articule autour de quatre parties : Le premier chapitre présente une description générale de l’organisme d’accueil et du client, ainsi que le cahier des charges du projet. Le deuxième chapitre présente l’approche adoptée et la solution de travail SAP choisie. Au troisième chapitre, je détaille le contexte spécifique du projet, et la démarche adoptée. Le quatrième chapitre traite la stratégie globale de reprise des données. Un bilan du travail réalisé et une conclusion clôturent ce rapport.

1

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet

Dans ce chapitre nous présentons l’organisme d’accueil ainsi que notre client. Puis nous définissons le cahier des charges de projet afin de développer la nature de l’activité en question et le contexte du projet réalisé.

1

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet

1. Organisme d’accueil : IBM 1.1 IBM – Présentation IBM (International Business Machines) est une société multinationale américaine qui a été fondée le 16 juin 1911. Elle est maintenant la plus grande entreprise de technologies de l'information, elle est présente dans 170 pays. IBM est une entreprise intégrée à l’échelle mondiale structurée autour de 4 métiers :

Figure 1 : Métiers d’IBM

1.2 IBM – Chiffres clés Siège social

Armonk, États-Unis

Effectif global

431 212

Dirigeant France

Alain Benichou

Spécialistes techniques

200 000

Centres de recherche

11

Chercheurs

3000

Chiffre d'affaires

99,7 milliards de dollars

Brevets en 2014

6 809

Prix Nobel

6

Tableau 1: Chiffres clés d’IBM

1.3 IBM – Service Line SAP Avec plus de 40 000 installations SAP et plus de 20 000 clients SAP, la Practice SAP d’IBM est à la disposition des entreprises pour les aider à déployer la suite de produits et de solutions industrielles. Cette volonté d'excellence de ses interventions a aidé à atteindre la position de

1

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet leader. IBM sert plus de 70% de la base installée de logiciels SAP dans les grandes entreprises comme dans les PME. Reconnu à de multiples reprises comme l’un des leaders des fournisseurs de services SAP ERP par Gartner, IBM dispose de plus de 32 500 professionnels spécialisés dans le monde pour apporter une connaissance exhaustive de l'industrie, des compétences étendues et des années d'expérience SAP sur tout le cycle applicatif, de la stratégie à l'exploitation en passant par l'hébergement. L’objectif d’IBM est de seconder ses clients pour qu'ils s'assurent un avantage concurrentiel, obtiennent des résultats commerciaux tangibles et réalisent un retour rapide sur leurs investissements. De plus IBM aide les entreprises à atteindre leurs objectifs avec la mise en œuvre des processus métiers et des technologies informatiques dans leurs organisations, par l’exploitation de sa puissante alliance et de ses initiatives de développement conjointement avec SAP.

Figure 2 : Force des prestataires de services SAP

- SAP est la 1ère ligne de services d’IBM Global Business Services avec : 

Environ 380 consultants en France couvrant toutes les offres et les modules de SAP,



Environ 500 consultants francophones,

2

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet 

Environ 6500 consultants en Global Delivery.

Tableau 2 : Service SAP d’IBM en France

-

Implantation des équipes SAP IBM en France

Des consultants rattachés à des bureaux régionaux :  Paris (Bois Colombes),  Lyon,  Nantes,  Bordeaux,  Toulouse. Des Centres de Services SAP IBM en France :  ISC Lille : Centre multi-technologies (Java, SAP, Oracle, Microsoft…),  Toulouse : SAP. Des Centres de Support et d’Expertise SAP IBM en France :  Montpellier,  La Gaude.

3

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet 2. Client : Groupe EDF 2.1 EDF – Présentation EDF (Électricité de France) est le premier producteur et fournisseur d’électricité en France et dans le monde. Elle a été fondée suite à la loi du 8 avril 1946 qui avait pour but de nationaliser les entreprises de production, transport et distribution d’électricité. Les principaux métiers de ce groupe sont les suivants :

-

La production nucléaire,

-

Le Transport,

-

La distribution,

-

La commercialisation.

Figure 3 : Logo du Groupe EDF

2.2 EDF – Chiffres clés Clients

39,3 millions dans le monde

Effectifs salariés en France

129492

La quantité d’énergie électrique produite en

642,6 TWh

2012 Chiffre d'affaires

72,9 milliards d'euros

Résultat net

3 milliards d'euros

Investissements net

12 milliards d'euros

Collaborateurs dans le monde

158 200

Production énergétique

623,5 TWH

Tableau 3 : Chiffres clés du Groupe EDF

4

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet 3. Cadrage du projet 3.1 Contexte du projet

Le 27 juin 2011, EDF, ses partenaires Fluxys (opérateur gazier du réseau de transport de gaz belge et du terminal méthanier de Zeebrugge) et TOTAL ont décidé la construction du terminal méthanier de Dunkerque. L’équipe commerciale du projet est « Dunkerque LNG », c’est une société de projet pour permettre le financement du projet par des partenaires actionnaires internationaux (65% EDF, 25% Fluxys et 10% TOTAL). De plus, l’exploitation du terminal méthanier a été confiée à «Gaz-Opale», c’est une société d’exploitation filiale de Dunkerque LNG. Le terminal méthanier de Dunkerque comporte ainsi une dimension stratégique qui lui donne une envergure nationale et européenne. Concrètement, le terminal de Dunkerque sera raccordé, cas unique, à 2 marchés : France et Belgique. Ainsi le terminal méthanier permettra une amélioration significative de la concurrence sur le marché de la fourniture de gaz, il contribuera fortement au renforcement de la sécurité d'approvisionnement de la France et de l'Europe, ainsi il renforcera la présence d’EDF et de ses partenaires européens sur les marchés du gaz. Le terminal méthanier de Dunkerque aura une capacité annuelle de regazéification de 13 milliards de m3 de gaz soit environ 20% de la consommation annuelle française et belge de gaz naturel, ce qui en fera le plus important terminal en Europe continentale.

Après plusieurs tentatives infructueuses de mise en œuvre de SAP, le client a décidé d'accélérer la maîtrise de ses systèmes d'information, pour qu'à la mise en service du terminal, les équipes d'exploitation soient en capacité de recevoir les méthaniers dès la mi-novembre 2015. En effet les équipes d'exploitation qui vont vivre avec SAP par la suite n'ont pas de système d'information intégré. Pour cela, afin de répondre à leurs besoins IBM France a proposé l'approche « solution pré configurée » qui leurs permet de se projeter immédiatement dans un système disponible dès le début du projet et qui est déjà enrichi de paramétrage et de données. La solution mise en place est une approche standard, basée sur les bonnes pratiques du progiciel SAP associées à la solution IBM Express, permettant une mise en œuvre en moins de 8 mois. Le projet lancé aujourd'hui avec IBM couvre les domaines fonctionnels et applicatifs suivants : MM (gestion des articles), PM (gestion de la maintenance), FI (comptabilité financière) et CO (contrôle de gestion). Ainsi le projet a débuté le 16/02/2015, pour un démarrage sur SAP prévu

5

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet le 15/11/2015 avec de l'assistance et des compléments de périmètre jusqu'en Février 2016. Les utilisateurs FI et CO sont situés à l’entité de Paris et les équipes PM et MM sont situées à Dunkerque.

3.2 Cahier des charges 3.2.1 Contexte pédagogique Ce projet est mené dans le cadre du projet de fin d’études qui s’est déroulé au deuxième semestre de la 3ème et dernière année industriel et logistique. La dernière année s'est déroulée en France, à Metz, dans le cadre d'un programme « Deux Diplômes » entre l'ENSAT et l'UL. Il s'est effectué dans la société IBM France sous la responsabilité de l'UL et sous l'encadrement d’IBM, l'ENSAT et de l'UL. L’objectif principal de ce travail est d’intégrer le monde professionnel par la réalisation d’un projet réel dans une société, afin de développer les atouts acquis lors de la formation pédagogique. 3.2.2 Expression et validation du besoin Le projet de déploiement permet la réponse au besoin exprimé par Dunkerque LNG, vis-à-vis de la solution SAP adoptée pour la gestion intégrée. En effet le client souhaite disposer d'un outil fiable, rapide, simple et abordable pour la gestion du terminal méthanier. Le diagramme suivant formalise explicitement le besoin :

A qui rend-t-il service ?

Sur quoi agit-il ?

Les processus métiers de Dunkerque LNG

Le terminal méthanier de Dunkerque LNG

Déploiement des modules : PM/ MM/ FI/ CO, du progiciel de gestion intégré SAP Dans quel but ? Gestion intégrée fiable, abordable, simple et homogène des processus métiers FI, CO, MM, PM Figure 4 : Expression de besoin, le diagramme "Bête à cornes"

6

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet Après avoir exprimé le besoin, nous l’avons validé en répondant à ces trois questions : 

Pourquoi le besoin existe-t-il ?

Parce que la gestion des processus métiers du terminal méthanier est très complexe, ainsi parce que l’entité de Paris doit superviser toutes les activités du terminal méthanier de Dunkerque en temps réel pour qu’il puisse faire la gestion de comptabilité et le contrôle de gestion du terminal méthanier. 

Pour quoi le besoin existe-t-il ?

Pour assurer une communication en temps réel entre les deux entités de Paris et de Dunkerque, ainsi que pour faciliter la gestion des processus métiers. 

Qu’est ce qui pourrait faire évoluer ou disparaître le besoin ?

Disparaître le besoin : une nouvelle génération de logiciels qui ne se basent pas sur des processus métiers, ou la non-utilisation des méthodologies métiers connues aujourd'hui chose qui ne peut pas se produire. Evoluer le besoin : un nouvel ERP qui peut s’adapter aux changements des processus métiers des entreprises et qui intègre d’autres systèmes de gestion CRM, SCM, etc. 3.2.3 Equipe du projet Stéphane ROGER Chef de projet Localisation : Site IBM, Bois-Colombes Site client, Dunkerque

Wilfrid REAL Architecte SAP Localisation : Site IBM, BoisColombes La Gaude (Nice)

Rene MONEKENE Consultant SAP MM Localisation : Site IBM, Bois-Colombes Site client, Dunkerque

Gilles BACQUET Consultant SAP PM Localisation : Site IBM, Bois-Colombes Site client, Dunkerque

Amine SALHI Consultant SAP FI CO Localisation : Site IBM, Bois-Colombes Site client, Paris

Fabien FRANCHITTO Architecte SAP Localisation : Site IBM, BoisColombes La Gaude (Nice)

Hironui BOOSIE Consultant SAP MM Localisation : Site IBM, Bois-Colombes Site client, Dunkerque

Yassine BOUCHKARA Consultant SAP PM Localisation : Site IBM, Bois-Colombes Site client, Dunkerque

Elodie MENDES Consultant SAP FI CO Localisation : Site IBM, Bois-Colombes Site client, Paris

Figure 5 : Organigramme de l’équipe projet

7

Claude DENIS Développeur SAP ABAP Localisation : Site IBM, Toulouse

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet 3.2.4 Gestion des délais La gestion des délais d’un projet consiste à planifier l’ensemble des activités du projet dans le temps et à les piloter de façon à respecter au mieux les engagements initiaux. Pour cela, il faut planifier les activités quotidiennes et décomposer les grands objectifs stratégiques en résultats tangibles et réalistes (livrables) de façon à organiser son temps et suivre ses priorités au jour le jour. Le diagramme de Gantt prévisionnel ci-dessous retrace le déroulement de mon stage et l’annexe 1

présente le diagramme de Gantt réel du projet réalisé.

Figure 6 : Diagramme de gant prévisionnel

3.3 Facteurs clés de succès La réussite du projet et plus spécialement l’intégration de l’ERP SAP dépendent de plusieurs facteurs clés : 1. L’adéquation de la solution aux besoins réels de Dunkerque LNG : Il s’agit de bien cerner les besoins essentiels et les enjeux liés. Par ailleurs, la valeur ajoutée doit être jaugée en permanence. L’objectif est de réaliser un apport aux opérateurs de Dunkerque LNG. 2. La méthodologie : IBM a développé sa propre méthodologie de gestion afin d’accompagner ses clients dans la réussite de leurs projets complexes ayant pour perspectives la création de

8

Chapitre 1 : Présentation de l’organisme d’accueil et du contexte de projet valeur et le respect des spécificités de l'entreprise. 3. Le savoir-faire de l’intégrateur : IBM a excellé dans de nombreux projets similaires à celui de Dunkerque LNG. Elle est déjà intervenue dans le domaine pétrolier pour Total. Ainsi par son expérience éprouvée dans la mise en œuvre du progiciel SAP, elle arrive à construire et intégrer les meilleures démarches. 4. Équipes projet : L’affectation des tâches entre les différents collaborateurs doit être de façon organisé. La disponibilité des équipes dédiée chez le client quand ils sont sollicités demeure un facteur clé de succès. 5. Une coordination forte des acteurs : Un nombre élevé de collaborateurs est impliqué dans le projet. La communication entre les différents intervenants est primordiale afin de venir à bout du projet.

9

Chapitre 2 : La solution pré-packagée IBM Express pour SAP

Chapitre 2 : La solution pré-packagée IBM Express pour SAP

Dans ce chapitre nous présentons le progiciel de gestion intégré SAP et nous décrivons son architecture modulaire. Puis nous traitons l’approche adoptée et la solution choisie dans ce projet.

10

Chapitre 2 : La solution pré-packagée IBM Express pour SAP

1. Introduction L'accès des entreprises aux nouvelles technologies, à internet en particulier, tend à modifier la communication entre les différents acteurs du monde des affaires. Notamment entre l'entreprise et ses clients (Business To Consumer, B2C), le fonctionnement interne de l'entreprise (Business To Employees, B2E) et la relation de l'entreprise avec ses différents partenaires et fournisseurs (Business To Business, B2B). On appelle aussi "e-Business" l'intégration au sein de l'entreprise d'outils basés sur les technologies de l'information et la communication, en l'occurrence les Progiciels de Gestion Intégré (PGI) ou Enterprise Ressource Planning (ERP). Cet outil permet une gestion homogène et cohérente du système d'information (SI) de l'entreprise, en particulier pour la gestion commerciale de la chaine de production à la vente d'un produit. Nous verrons tout d'abord une présentation générale des ERP ce qui nous conduira à la description de leur architecture modulaire.

2. Présentation générale des ERP 2.1 Définition L'acronyme ERP signifie "Enterprise Ressource Planning" traduit en français par Progiciel de Gestion Intégré ou PGI. ERP est le terme le plus couramment utilisé. Emanant d'un concepteur unique, un ERP est un progiciel qui permet de gérer l'ensemble des processus d'une entreprise intégrant l'ensemble de ses fonctions comme la gestion des ressources humaines, la gestion financière et comptable, l'aide à la décision, la vente, la distribution, l'approvisionnement, la production ou encore du e-commerce. Le principe fondateur d'un ERP est de construire des applications informatiques correspondant aux diverses fonctions citées précédemment de manière modulaire sachant que ces modules sont indépendants entre eux, tout en partageant une base de données unique et commune au sens logique. L'autre principe qui caractérise un ERP est l'usage de ce qu'on appelle un moteur de Workflow et qui permet, lorsqu’une donnée est enregistrée dans le SI, de la propager dans les modules qui en ont l'utilité, selon une programmation prédéfinie.

11

Chapitre 2 : La solution pré-packagée IBM Express pour SAP Ainsi, on peut parler d'ERP lorsqu'on est en présence d'un SI composé de plusieurs applications partageant une seule et même base de données, par le biais d'un système automatisé prédéfini et éventuellement paramétrable, un moteur de workflow.

2.2 Les ERP : Pour qui ? Pourquoi ? Pour qui ? Les ERP sont principalement destinés aux grandes entreprises ou multinationales du fait d'un coût important. Cependant, le marché des ERP tend à se démocratiser vers les PME/PMI. Certains éditeurs conçoivent un ERP uniquement pour ce type de structure. Enfin, il existe des ERP open source ce qui revient moins cher, puisqu'il n'y a pas de coût de licence (ils sont gratuits). En revanche, il faut inclure dans le calcul du coût d'acquisition total, les frais de maintenance et l'assistance technique. Pourquoi ? Concrètement, les avantages de la mise en place d'un ERP sont les suivants : 

L'intégrité et l'unicité du SI, c'est à dire qu'un ERP permet une logique et une ergonomie unique à travers sa base de données, elle aussi unique au sens "logique". Ceci se traduit par le fait qu'il peut exister plusieurs bases de données "physiques», mais celles-ci respectent la même structure. En bref, un ERP permet d'éviter la redondance d'information entre différents SI de l'entreprise.



L'utilisateur a la possibilité de récupérer des données de manière immédiate, ou encore de les enregistrer. Un avantage important, les mises à jour dans la base de données sont effectuées en temps réel et propagées aux modules concernés.



Un ERP est un outil multilingue et multidevise, il est donc adapté au marché mondial, en particulier aux multinationales.



Pas d'interface entre les modules, il y a synchronisation des traitements et optimisation des processus de gestion. De même, la maintenance corrective est simplifiée car celleci est assurée directement par l'éditeur et non plus par le service informatique de

12

Chapitre 2 : La solution pré-packagée IBM Express pour SAP l'entreprise. (Celui-ci garde néanmoins sous sa responsabilité la maintenance évolutive : amélioration des fonctionnalités, évolution des règles de gestion, etc.). 

Un ERP permet de maîtriser les stocks, élément important pour la plupart des entreprises car les stocks coûtent chers.

Par conséquent, les ERP gèrent et prennent en charge plusieurs périodes (pour les exercices comptables par exemple), plusieurs devises, plusieurs langues pour les utilisateurs et clients, plusieurs législations, plusieurs axes d'analyse en informatique décisionnelle. Mais l'implantation comporte plusieurs risques : des risques organisationnels (le progiciel et l'organisation de l'entreprise doivent cohabiter), de mise en œuvre (au niveau formation utilisateur), fonctionnels (fonctions offertes par le progiciel par rapport aux fonctions attendues),

techniques,

contractuels

entre

l'éditeur

et

l'entreprise

et

enfin

des

risques économiques du fait de l'investissement.

2.3 Architecture modulaire des ERP Voici le périmètre de gestion couvert par chacun de ces modules de SAP : -Le module MM (Material Management) : C’est le module logistique de SAP. Il gère les achats d’articles et les stocks d’articles (les mouvements de stocks : entrées et sorties, transferts de stocks). MM permet en particulier le calcul des besoins, la gestion des achats et des réapprovisionnements mais aussi des demandes d’achat et des contrats. MM gère aussi les emplacements magasin (WM Warehouse Management) et contrôle les factures d’achat. -Le module PP (Production Planning) : Le

module

PP

(Production

Planning)

concerne

la

gestion

de

la

Production.

Ce module permet de gérer des nomenclatures de produits et des gammes de produits d’un point de vue du suivi de la production. Il permet en effet de planifier la production, de calculer des besoins, de prévoir les ventes au niveau entreprise (PIC : Plan Industriel et Commercial), de prévoir la production (PDP : Plan Directeur de Production : prévision de la production au niveau usine), de calculer des besoins et des ressources (hommes et machines : MRP II), de

13

Chapitre 2 : La solution pré-packagée IBM Express pour SAP planifier des capacités, de contrôler la fabrication, de suivre la production, de calculer les coûts de revient. -Le module SD (Sales and Distribution): C’est le module d’administration des ventes. Ce module gère les appels d'offres, les offres, les contrats, les commandes clients, les expéditions et livraisons, les remises, la facturation et le système d'information commercial. Il s’adapte aux spécificités des produits vendus par les entreprises. Par exemple, dans le cas d’une entreprise industrielle qui vend des outils, il permet de gérer différents types de remises. Dans le cas d’une Maison d’Edition, on peut le paramétrer pour le calcul des droits d’auteur. -Le module QM (Quality Management) : C’est le module de gestion de la qualité de SAP. Il permet la planification des contrôles qualité et la documentation des démarches qualité. -Le module PM (Plant Maintenance) : Adapté aux entreprises industrielles, gère : 

La maintenance préventive et curative de l’usine,



La description du référentiel technique, des postes techniques et des équipements,



Le traitement des ordres de maintenance,



Les confirmations d'achèvements,



Les historiques.

-Le module FI (Financial) : Ce module comptable contient toutes les écritures comptables de ventes, d’achats et d’immobilisations, qui se centralisent dans la comptabilité générale. 

FI-AR (Accounts Receivable) : Comptabilité client,



FI-AP (Accounts Payable) : Comptabilité fournisseur,



FI-AM (Assets Management) : comptabilise les immobilisations,



FI-GL (General Ledger) : Comptabilité générale.

14

Chapitre 2 : La solution pré-packagée IBM Express pour SAP -Le module CO (Costing) : Traite la comptabilité analytique. C’est le module de contrôle de gestion de l’entreprise. Il permet l’analyse des coûts par centre de profits, par catégorie de produits/services/projets. Il calcule les coûts de production. Il permet l’édition du compte de résultat, d’états de reporting et d’analyses financières. -Le module PS (Project System) : Concerne la gestion des projets. Il permet de suivre les budgets prévisionnels et les coûts réels des projets. Il permet de gérer les plannings des projets. On peut y importer des fichiers venant de MS Project et d’excel. Il s’intègre avec les modules PM, PP et CO. -Le module HR (Human resource): Permet de gérer les recrutements, les paies des employés, les compétences des employés, de suivre les temps de travail et les évolutions de carrière, de gérer les demandes et les frais de déplacement.

3. Les impératifs du projet et l’approche IBM Pour constituer le système d’information de ces deux nouvelles entités (Dunkerque LNG et Gaz-Opale), Dunkerque LNG a décidé la mise en œuvre de la solution SAP avec les impératifs suivants : 

Un système d’information opérationnel mi-novembre 2015 (date du Go-Live),



Un historique applicatif et données limitées,



Des équipes Dunkerque LNG et Gaz-Opale très sollicitées et de tailles optimisées.

Au-delà des approches traditionnelles d’un projet SAP, ces facteurs imposent : 

Des accélérateurs méthodologiques éprouvés,



Un contenu fonctionnel pré-intégré dans la solution et certifié par l’éditeur SAP,



Une solution SAP accessible par Dunkerque LNG et disponible à T0.

15

Chapitre 2 : La solution pré-packagée IBM Express pour SAP

Figure 7 : Eléments constitutifs de la solution IBM Express

3.1 Définition de la solution IBM Express La solution SAP IBM Express a été construite à partir des bonnes pratiques SAP, de l’expertise fonctionnelle

et

sectorielle

IBM

ainsi

que

des

accélérateurs

méthodologiques

d’implémentation. Afin de mieux intégrer les spécificités liées à l’activité des clients, IBM a développé des solutions contextualisées par industrie (Chimie, Automobile, Pharmacie, Produits de grande consommation, etc.). En effet cette approche sectorielle permet d’enrichir la solution SAP prépackagée avec des processus métiers dédiés.

Figure 8 : Solution pré-packagée IBM Express

16

Chapitre 2 : La solution pré-packagée IBM Express pour SAP Dans le cadre de notre projet, la solution contextualisée pour l’industrie chimique nous a apparu celle étant la plus en adéquation avec les besoins du Dunkerque LNG. Ce choix de notre part a été motivé par nos hypothèses de base après lecture du Blueprint puis confirmé par nos différents échanges successifs notamment sur le domaine de la maintenance, pour la simple raison que : 

Les types de maintenance de Dunkerque LNG ne sont définis que dans les scénarios préconfigurés de l’industrie chimique,



Les contraintes et règlementations en terme de sécurité sont inclues dans cette solution verticale « Chimie »,

3.2 Les raisons du choix de la solution Notre conviction dans le projet de Dunkerque LNG c’est de mettre en œuvre une solution innovante reposant sur une méthodologie adaptée au contexte du terminal méthanier de Dunkerque, et qui va nous permettre d’atteindre les points suivants : 

L’acquisition progressive et durable des compétences par les équipes du client avec la présentation des processus dans SAP dès la phase de Quick Scan (propre à IBM),



Un effort de paramétrage réduit comparé à un projet d’implémentation classique avec la mise à disposition d’un environnement pré-paramétré et pré-chargé en données,



Une volonté d’utiliser au maximum le standard SAP en limitant les développements spécifiques.

17

Chapitre 2 : La solution pré-packagée IBM Express pour SAP Le schéma suivant représente l’importance relative des différents chantiers selon la démarche adoptée, traditionnelle ou Express :

Figure 9 : Importance relative des différents chantiers selon la démarche adoptée

3.3 Les bénéfices de la solution IBM Express L’avantage principal de la solution IBM Express c’est qu’elle apporte plusieurs bénéfices importants, qui sont de quatre ordres : 1- « Solution Out of the box solution » : par ce qu’il s’agit d’une solution utilisable dès le premier jour, avec une appropriation rapide par l’équipe projet client, ainsi cette solution embarque les Best Practices SAP et un périmètre parfaitement défini. 2- « Solution Delivery » : La solution à un temps d’implémentation maîtrisé, avec un risque réduit, ainsi des coûts parfaitement identifiés et maitrisés. 3- « Formation » : IBM Express offre une formation orientée solution et non focalisée uniquement sur les processus de gestion, de plus une meilleure appropriation par les utilisateurs.

18

Chapitre 2 : La solution pré-packagée IBM Express pour SAP 4- « Solution documentation » : La solution possède une documentation complète, surtout des supports de formation pour les utilisateurs finaux. Après avoir connu l’importance et les bénéfices de la solution, il reste à savoir les éléments constituants IBM Express solution SAP pré-packagée. Ces constituants sont présentés dans ce qu’on appelle la « Maison IBM Express » :

Figure 10 : Maison IBM Express

19

Chapitre 3 : Démarche de mise en œuvre du projet

Chapitre 3 : Démarche de mise en œuvre du projet

Dans ce chapitre nous présentons la démarche de mise en œuvre du projet en détaillant les différentes phases, la gestion de projet propre à la méthodologie adoptée et la plateforme de travail SAP afin de découvrir l’environnement technique et applicatif du projet.

20

Chapitre 3 : Démarche de mise en œuvre du projet 1. La méthodologie IBM Express adaptée aux solutions pré-packagées La méthode IBM Express pour solutions SAP pré-packagées s’appuie sur des phases séparées en activités et en tâches. Elle est adaptée à chaque projet selon le contexte client. Le schéma ci-dessous représente les différentes phases du projet :

Figure 11 : Etapes et démarches du projet

1.1 Quick Scan Cette phase a pour objectifs la définition du périmètre du projet, l’aligner avec la stratégie du métier, engager les acteurs du projet ainsi faire des recommandations techniques. Dans la phase de Quick Scan nous avons déroulé plusieurs ateliers avec le client pour bien tracer le périmètre du projet. Lors de ces ateliers nous avons fait des démonstrations des fonctionnalités standard de SAP sur l’environnement « bac à sable » pour la compréhension du métier et des macro-processus, à son rôle le client nous a présenté les différentes règles de gestion métier relatives à chaque domaine d’intervention (logistique, comptabilité financière et contrôle de gestion). L’objectif principal c’était de comprendre la stratégie du client, sa position sur le marché et ses opportunités opérationnelles, ainsi que de mesurer les bénéfices attendus du projet. Nous avons ensuite enchainé avec des ateliers pour l’analyse « Fit-Gap », qui est une analyse menée lors de la phase de Quick Scan du projet, elle permet de déterminer la manière dont le système standard SAP répond aux requis prédéfinis (Fit) c’est-à-dire qu’il n’ y a pas d’écart

21

Chapitre 3 : Démarche de mise en œuvre du projet fonctionnel entre le standard SAP et le métier ou, dans le cas contraire, s’y oppose (Gap), dans ce cas il faut définir le pourcentage de l’écart fonctionnel, ainsi le type de la solution proposée, soit une solution de contournement qui nécessite un paramétrage ou bien un développement spécifique qui fait appel à des développeurs ABAP (annexe 2). En effet pour toutes les solutions qui nécessitent des développements spécifiques, il faut définir ce qu’on appelle le « FRICE ». C’est un acronyme pour Formulaires, Rapports, Interfaces, Conversions et Extensions. Cette classification est utilisée dans les projets SAP pour catégoriser et inventorier les programmes et objets ABAP créés ou personnalisés afin de mettre en place une solution. Ces objets principalement utilisés lors de la phase d’implémentation peuvent être très importants lors de diverses opérations de support (maintenance, extensions, support de production…). Après la classification des différents développements, nous avons passé à l’identification de la complexité de chaque développement (très simple, simple, moyen, complexe), cela nous a permis de connaître la charge des développements à l’aide des abaques de chiffrage (annexe 3), ce qui nous permet par la suite d’évaluer les coûts des développements. En effet ces diverses sessions d’ateliers nous ont permis d’analyser et de comparer les processus du système standard SAP avec les processus métiers de Dunkerque LNG, dont l’objectif de parvenir à une solution finale, qui répond aux exigences du métier. Le déroulement des ateliers de présentation de Quick Scan est illustré dans le schéma suivant :

Figure 12 : Déroulement des ateliers de présentation de Quick Scan

22

Chapitre 3 : Démarche de mise en œuvre du projet

1.2 Validation Les objectifs de cette phase est de valider le périmètre des scénarios et processus métiers de la solution préconfigurée, ainsi d’identifier le hors-périmètre et les évolutions qui nécessitent des développements à prévoir avec trajectoire de mise en œuvre.

En effet dans ce projet la phase de validation nous a permis de confirmer le niveau global de convergence entre la solution SAP et les processus métiers de Dunkerque LNG, à travers des démonstrations des fonctionnalités SAP contextualisées. Lors de ces démonstrations, nous avons fait plusieurs ateliers avec le client sur l’environnement de développement « DEV » SAP. C’est un environnement qui contient des valeurs supplémentaires de paramétrage que nous avons identifiées lors des ateliers de Quick Scan, ainsi des données de base que nous avons chargées via des programmes de chargement des données « LSMW », dans le but de rendre les flux plus compréhensibles pour le client, ce qui facilite par la suite la validation de la solution SAP. Subséquemment nous avons défini un plan d’action pour adresser les besoins hors périmètre et pour confirmer les différents périmètres organisationnels et les impacts liés aux changements, semblablement nous avons identifié la totalité des développements qui nécessitent la conception des spécifications fonctionnelles (annexe 4). À la fin de cette phase, nous avons livré à Dunkerque LNG des Business Process pour chaque domaine d’intervention. Ce sont des documents qui englobent le besoin du client et qui résument les procédures et les manières spécifiées d'effectuer une activité ou un processus métier (annexe 5 et 6).

La clôture de cette phase nécessite une validation officielle des Business Process de tous les domaines, dans le cas échéant le client peut remonter des modifications. Le schéma suivant illustre le déroulement des ateliers de convergence en phase de validation :

23

Chapitre 3 : Démarche de mise en œuvre du projet

Figure 13 : Déroulement des ateliers de convergence en phase de Validation

1.3 Activation L’objectif principal de la phase d’activation est de finaliser le paramétrage et les développements, ainsi de mettre en œuvre les tests unitaires et d’intégration des processus métiers, de créer les rôles et profils pour les utilisateurs, la préparation de la migration de données et la mise à jour des Business Process.

1.3.1 Tests d’IBM 1.3.1.1

Tests unitaires

Le test unitaire est un processus dans lequel les parties testables plus petites d'une application, appelées unités, sont examinées individuellement et indépendamment pour un fonctionnement correct. Ce mode de test est une méthode pragmatique qui adopte une approche méticuleuse à la construction d'un produit au moyen d'essais et de révisions continuellement. Les tests unitaires sont les premiers tests réalisés après le paramétrage et le développement spécifique, ils impliquent que les caractéristiques qui sont essentielles à la performance de l'unité sous test. Une fois que toutes les unités dans SAP fonctionnent de la manière la plus

24

Chapitre 3 : Démarche de mise en œuvre du projet efficace et sans aucune anomalie constatée, les grands composants du programme peuvent être évalués au moyen de tests d'intégration. Les tests unitaires peuvent être longs et fastidieux. Ils exigent de la patience et de la rigueur de la part de l'équipe des consultants. Ainsi une documentation rigoureuse doit être maintenue. De plus les tests unitaires doivent être faits avec une prise de conscience qu'il ne sera pas possible de tester une unité pour chaque scénario d'entrée qui va se produire, lorsque le programme est exécuté dans un environnement du monde réel (production).

Dans cette phase du projet nous avons effectué tous les tests unitaires (plus de 150 tests unitaires, annexe 7) pour tous les domaines d’intervention (logistique, comptabilité financière et contrôle de gestion) de Dunkerque LNG et Gaz-Opale, après nous avons partagé avec le client les livrables des tests unitaires avec les résultats attendus de chaque test. Les programmes de chargement de données aussi ont été testés individuellement, mais pas avec la même méthode, les données d’entrée pour les programmes de chargement sont des fichiers Excel à charger dans SAP, après le client doit comparer les données chargées avec ce qui nous a été fourni dans le fichier Excel.

1.3.1.2

Tests d’intégration

Un test d'intégration est un processus de test utilisé pour tester les composants logiciels ou l’ensemble des unités de code pour vérifier l'interaction entre les différents composants logiciels et de détecter les défauts. Les composants sont testés en un seul groupe et organisés d'une manière itérative. Après la réalisation des tests d'intégration sur les composants, ils sont facilement disponibles pour les tests de système.

Dans notre projet et de la même manière nous avons listé tous les scénarios métiers possibles de Dunkerque LNG (annexe 8), après pour chaque scénario nous avons déroulé des flux intégrés avec la présence des référents métiers de chaque domaine. Ces tests ont été déroulés avec des données plus réalistes et entre les différents modules (PM / MM / FI / CO). Comme résultat, les tests ont montré que le processus relatif au client tel qu’il est conçu et configuré dans SAP fonctionne, en utilisant des échantillons de données représentatives de chaque domaine. C’était l’occasion aussi de montrer les nouvelles fonctionnalités ajoutées autrement dit, les développements, les interfaces et les paramétrages.

25

Chapitre 3 : Démarche de mise en œuvre du projet 1.3.2 Rôles et autorisations Le concept des autorisations de SAP permet d’affecter des autorisations différentes aux utilisateurs sur la base des rôles, chaque rôle est composé de plusieurs rôles composites. L’utilisation des rôles composites est très utile dans le cas où les utilisateurs ont besoin de l’autorisation de plusieurs rôles, dans ce cas-là il faut créer des rôles composites puis affecter les mêmes rôles composites pour des utilisateurs qui ont des rôles différents. Le tableau suivant montre un exemple de la matrice des rôles et des rôles composites que nous avons créés pour le domaine de la maintenance :

Rôle Composite / Rôle Responsable Consultation de la Maintenance X Opérationnelle Gestion des Données de Base Avis Gestion de la Maintenance Opérationnelle et Préventive Gestion des Données de Base Classe Enregistrement des x Durées Validation d'Avis x Définition de x l'Intervention Définition de l'Anomalie

Agent de la Conduite

X

Agent de Maintenance

Administrateur Données de Base

Gestion de Base Maintenance préventive

Intervenant

X

X

x

x

X X

x

X X

X

X

x

X

X

x

X

X

x

x

Consultation de l'Intervention Enregistrement d'une Défaillance Consultation de l'Ordre de Travail Impression du Permis de Travail Affichage de la Synthèse des Stocks Fiche du Personnel

x x

X

X

X

x

x

x

X

X

X

x

x

X

x

x x

Tableau 4 : Rôles et autorisations du domaine de la maintenance

Dans les ateliers d’intégration nous avons testé tous les rôles ainsi les autorisations, puisque nous avons déroulé les flux des tests d’intégration avec les rôles que nous avons définis avec le client.

26

Chapitre 3 : Démarche de mise en œuvre du projet Le schéma suivant illustre les démarches à suivre pour la création des rôles et autorisations :

Figure 14 : Démarche des rôles et autorisations

En fin la phase d’activation reste la plus chargé du projet, comme résultat de cette phase nous avons pu atteindre les objectifs fixés au départ et répondre aux besoins spécifiés par le client.

1.4 Simulation L’objectif de cette phase est d’exécuter la recette du système mis en œuvre avant passage en production, ainsi préparer la bascule par la rédaction des modes opératoires et la formation des utilisateurs. 1.4.1 Recette 1.4.1.1

Contexte et objectifs de la recette

La recette a pour objectif de mettre en œuvre les moyens nécessaires permettant à Dunkerque LNG de s’assurer de la bonne adéquation du produit livré par IBM aux besoins exprimés. Dans cette phase le client doit :

27

Chapitre 3 : Démarche de mise en œuvre du projet 

Vérifier le bon fonctionnement du progiciel, du paramétrage et des développements associés,



Contrôler la conformité des caractéristiques fonctionnelles avec les besoins.

Elle a lieu dans le contexte suivant : 

Le progiciel est installé dans l’environnement de pré-production dans une version supportant la mise en exploitation,



Le paramétrage et les développements sont terminés et testés unitairement (par exception, des anomalies résiduelles peuvent encore exister sur les formulaires et états à ce stade, sauf que leur correction n’a aucun impact sur les processus en termes de régression),



Un premier test complet des processus par les consultants IBM a été réalisé,



Le bilan des tests unitaires et d’intégration a été fourni à Dunkerque LNG, qui a donné son accord pour le démarrage de la recette (plus d’anomalies bloquantes et un taux acceptable d’anomalies graves).

1.4.1.2

Etapes de la recette

La phase de la recette est constituée de plusieurs étapes et qui sont : 

Etablissement de la stratégie de la recette : périmètre, planification, moyens à mettre en œuvre…,



Identification des domaines et lots fonctionnels,



Planification de la recette, en tenant compte des contraintes de disponibilité des utilisateurs de Dunkerque LNG,



Elaboration des cas de tests. Ces tests décrivent l’enchaînement des étapes, des transactions et des données utilisées,



Exécution des tests,



Accomplissement des fiches de tests avec les résultats observés,



Etablissement des fiches d’anomalies en incluant le type d’anomalie et les conditions d’exécution dans laquelle elle est apparue. Voir ci-dessous la procédure de gestion des anomalies.

28

Chapitre 3 : Démarche de mise en œuvre du projet La recette est une phase critique qui nécessite, en amont une grande préparation des différents scénarios métiers par l’AMOA. Elle fait aussi l’objet d’un suivi particulier des réalisations des cas de tests, des demandes de modification et des anomalies résiduelles.

1.4.2 Procédure de gestion des anomalies Lors de l’exécution des tests, les anomalies détectées sont découpées selon leur origine : Anomalie de développement de la solution : 

Bug SAP nécessitant l’application d’une note OSS pour corriger un dysfonctionnement applicatif ou le support de SAP,



Erreur de paramétrage,



Erreur de développement,



Erreur lors de la mise en œuvre des autorisations.

Anomalie dans l’environnement existant : 

Erreur de traitement dans une application existante provoquant une anomalie de l’interface,



Erreur de développement d’une interface côté application existante,



Erreur dans la qualité des données reprises.



Ecart entre le référentiel de conformité et une attente de l’utilisateur,



Anomalie dans les modes opératoires SAP qui ne correspondent pas au déroulement effectif des transactions,



Anomalies sans objet, liées à une mauvaise manipulation.

Ces anomalies sont également découpées en fonction de leur criticité : 

Bloquante,



Grave,



Mineure.

Dans le cas où plusieurs anomalies doivent être traitées sur un même processus par le même consultant, la priorité sera donnée à la correction des anomalies dans l’ordre de leur criticité. La procédure de traitement des anomalies comporte les étapes suivantes :

29

Chapitre 3 : Démarche de mise en œuvre du projet - Détection et prise en charge de l’anomalie Gestion de l’anomalie Libellé Dunkerque LNG Détection d’une anomalie dans le système

IBM

X

Documentation de l’anomalie avec renseignements suivants : 

Type et criticité de l’anomalie,



Domaine, flux et transactions impactés,



La date où l’anomalie est constatée,



La description détaillée, précise et explicite du problème constaté,



Identification de l’acteur et tout document nécessaire à la

X

compréhension du problème. Réception et enregistrement de l’anomalie dans l’outil ad-hoc

X

Tableau 5 : Détection et prise en charge de l’anomalie

- Analyse d’impacts Gestion de l’anomalie Libellé Dunkerque LNG Analyse des causes et identification des impacts techniques,

IBM X

fonctionnels et métiers : mise à jour éventuelle du type d’anomalie Proposition de la solution technique :

X paramétrage, développement, correction donnée de base, … Si aucune solution n’est détectée pour les anomalies bloquantes et graves après 3 jours ouvrés (depuis la date de signalisation de

X

l’anomalie), proposition d’une solution de contournement possible, dans un délai de 15 jours (depuis la date de signalisation de l’anomalie). Validation des mesures proposées (correction ou solution de contournement).

Tableau 6 : Analyse d’impacts des anomalies

30

X

Chapitre 3 : Démarche de mise en œuvre du projet - Corrections et retests Gestion de l’anomalie Libellé Dunkerque LNG

IBM

Anomalies de développement de la solution : analyse de non régression et correction pour retest ; dans le cas d’une anomalie

X

nécessitant l’application d’un correctif SAP, IBM gère la relation et le suivi de la mise à disposition du correctif. Anomalies de l’environnement Dunkerque LNG existant : correction

X

pour retest Ecart entre conception validée et attente de l’utilisateur sur la

X

solution : initier une demande de changement Erreur de mode opératoire SAP : correction du document

X

Anomalie sans objet : clôture de l’anomalie dans l’outil

X

En cas de correction : retest de la fiche de test concernée et vérification

X

de la conformité

Tableau 7: Corrections et retests des anomalies

- Clôture des anomalies Gestion de l’anomalie Libellé Dunkerque LNG Vérification que tous les points précédents ont été réalisés.

X

Clôture de l’anomalie dans l’outil

X

Tableau 8: Clôture des anomalies

31

IBM

Chapitre 3 : Démarche de mise en œuvre du projet 1.5 Go Live & Support L’objectif de cette phase est de supporter les utilisateurs lors de la mise en production, la résolution des anomalies remontées et le suivi de la performance et du monitoring à plus long terme. La phase de Go Live est constituée de plusieurs activités qui sont : 

Mettre en place la tierce maintenance applicative (TMA), de façon que les utilisateurs connaissent les procédures de support (qui contacter + comment tracer une erreur versus une évolution, etc.),



Exécuter le plan de bascule pour valider que le système sera prêt à être utilisé,



Former tous les futurs utilisateurs,



Tracer et qualifier tous les incidents et les problèmes rencontrés, ainsi la correction et la planification de leurs mises en production,



Analyser et mesurer les bénéfices réalisés,



Valider les premiers résultats des processus métiers en mode productif.

1.6 Maintenance Cette phase de maintenance n’est pas comprise dans l’offre IBM. L'objectif principal de cette phase est d'assurer le fonctionnement de la solution après le Go Live. Il s’agit : 

D’avoir la capacité de maintenir les systèmes en état de fonctionnement et d'exploitation,



De garantir la disponibilité des systèmes et les niveaux de performance requis pour soutenir l'exécution des opérations de l'entreprise.

2. Gestion de projet La gestion de projet est une démarche visant à organiser de bout en bout le bon déroulement d’un projet, elle est devenue à la mode depuis la fin des années 80, où on a commencé à vouer à cette forme de pilotage d’activités un intérêt médiatique, managérial et académique considérable. Pour la gestion de notre projet, nous avons proposé à Dunkerque LNG de profiter de l’expertise, des outils et accélérateurs d’IBM en la matière, autour des thèmes suivants :

32

Chapitre 3 : Démarche de mise en œuvre du projet 

Gestion des risques et de la qualité,



Gouvernance du projet, avec des revues de jalons dédiées,



Organisation du projet proposée,



Elaboration de matrices de RACI, par phase et thèmes transverses.

2.1 Procédure de gestion des risques et de la qualité Le cadre de gestion des risques et de la qualité de ce projet s’appuie sur les milliers de projets de mise en œuvre réalisés par IBM. Il permet de fournir un retour objectif à l’équipe de gestion de projet. En effet le processus de gestion consiste en une évaluation des risques et un plan d’action périodiquement revu avec la direction de projet. Ces revues sont menées comme des points de revue formels du projet par une équipe IBM composée d’experts SAP ayant une connaissance métier du secteur d’activité et non directement impliqués dans le projet. L’objectif recherché est de s’assurer que : 

Les facteurs de risque qui pourraient mettre le projet en péril en termes de délai, qualité, coût, acceptation et atteinte des objectifs « métiers » sont identifiés, quantifiés avec une probabilité d’occurrence (faible, moyenne, haute) et un niveau d’impact potentiel tant en terme de projet que de Business,



Des actions sont mises en place pour limiter les risques, identifier des solutions alternatives en cas d’occurrence et de s’assurer que leurs applications soient contrôlées.

La conviction d’IBM réside dans le fait que la maîtrise des risques est un élément clé de la réussite du projet, qu’elle doit être considérée comme une activité continue de la gestion de projet menée de façon proactive et préconisons donc qu’une revue soit réalisée périodiquement. Dans le cadre de ce projet, nous avons adopté un découpage en six thèmes classiques identifiés par IBM suite à son expérience acquise sur les projets ERP complexes : Type de risque

Risque technique

Actions à entreprendre

-Vérifier que l’architecture technique est adaptée et stable. -Vérifier l’intégrité des données dans le nouveau système. -Vérifier que le niveau de sécurité et de contrôle suffisants sont en place.

33

Chapitre 3 : Démarche de mise en œuvre du projet Risque organisationnel

-Vérifier la stratégie de communication en place pour répondre aux attentes et gagner l’adhésion. -Vérifier que la formation et le support nécessaires sont prévus pour les utilisateurs clés et finaux.

Risque projet

-Evaluer la planification du projet, ainsi la correcte définition et maîtrise du périmètre.

Risque management exécutif

-Vérifier que le management est impliqué pour la compréhension et le partage des objectifs du projet.

Risque fonctionnel

-S’assurer que les besoins utilisateurs sont bien définis et cohérents avec le processus métier. -Vérifier l’implication des utilisateurs pour gérer leurs attentes et leurs futures acceptations du système.

Risque ressources

-Evaluer

la

bonne

adéquation

des

ressources

(compétences et disponibilité) aux besoins du projet. -Vérifier que l’équipe projet a le niveau de responsabilité pertinent.

Tableau 9 : Procédure de gestion des risques et de la qualité

2.2 Points-clés des revues de jalons Un jalon, dans le cadre de la gestion de projet, est la fin d’une étape ou la fin d’un travail. La plupart du temps, le jalon est aussi un événement important, comme la signature d’un contrat, le lancement d’un produit…etc. Dans notre projet à chaque jalon, la synthèse de la phase précédente est réalisée selon les critères définis par la direction de projet et présentée en comité de pilotage. Étant donné que chaque jalon doit faire l’objet d’une décision formelle de clôture de phase et de passage à la phase suivante. Pour ce faire, les revues doivent couvrir tous les aspects du projet. D’ailleurs au démarrage du projet, la direction de projet doit définir et s’accorder sur les critères d’ouverture / clôture de phase, de la même manière le passage en production nécessite que le senior management de Dunkerque LNG valide la décision finale (décision de GO / NO GO) en fonction des critères définis, des risques encourus et actions de contournement identifiées si nécessaire.

34

Chapitre 3 : Démarche de mise en œuvre du projet En effet les supports de validation sont préparés par les chefs de projet et sont soumis aux comités de pilotage. Le principe fondamental à appliquer dans l’animation de ces revues est que l’absence de remarque sur un livrable vaut acceptation de celui-ci. Les critères et les règles de validation et d’acceptation sont définis de commun accord dans le plan assurance qualité (PAQ).

2.3 Organisation du projet 2.3.1 Plan Assurance Qualité (PAQ) La réussite d'un projet s'apprécie par les facteurs clés qui sont à minima : 

La conformité des résultats à ceux attendus,



Le respect des délais et du budget.

Elle passe par la définition et la mise en œuvre de dispositions de management du projet qui lui sont adaptées : 

Organisation et direction de projet,



Plan de développement et conduite de projet,



Gestion de projet,



Obtention de la qualité.

Le Plan Assurance Qualité est l’engagement d’IBM quant à la politique d’assurance qualité applicable aux prestations. Il s'applique depuis le démarrage du contrat jusqu’à sa clôture. En effet il a précisément pour vocation de recenser l'ensemble des dispositions que l'équipe projet IBM estime nécessaire de mettre en œuvre pour assurer la qualité requise par Dunkerque LNG et par là même la réussite du projet. Le PAQ est rédigé par IBM dans sa version initiale dès le début du projet, puis soumis à Dunkerque LNG pour validation, les éventuelles versions ultérieures sont examinées et approuvées conjointement par IBM et Dunkerque LNG au moins au début de chaque phase. Il peut faire l’objet d’adaptations en fonction des spécificités du projet. Le PAQ validé par Dunkerque LNG vaut document contractuel de référence, en particulier pour l'organisation et pour les phases de validation du projet.

35

Chapitre 3 : Démarche de mise en œuvre du projet 2.3.2 La démarche de validation des livrables Les livrables devant être validés sont de deux types : 

Documents : Présentation des processus métier (les Business Process), spécifications fonctionnelles, …,



Système : environnement de développement, développement spécifique, etc.

A ces deux types de livrables sont associés deux processus de validation : 

Documents processus de validation documentaire,



Système processus de validation de la solution.

A défaut de validation, ou d’un retour formel dans le délai défini dans le PAQ (ex. 5 jours), le document sera considéré comme validé. Une fois signé, les modifications apportées à un livrable doivent être exceptionnelles. En conséquence, chaque demande de modification d’un document validé déclenchera une étude d’impact (sur le livrable et le reste du projet) réalisée par le rédacteur du document.

2.3.3 Les instances proposées pour le suivi du Projet La communication est un élément essentiel de la gestion de projet, elle a un impact énorme et structurant sur la réussite du projet. En effet pour le suivi du projet plusieurs réunions hebdomadaires ont eu lieu avec les référents métiers de chaque domaine d’intervention (PM / MM / FI / CO) et l’équipe des consultants IBM, notamment pour discuter les réalisations, les acquis, les faits marquants, les prochaines étapes, les risques principaux ainsi que les décisions attendues (annexe 9). Dans le même cadre des réunions mensuelles ont eu lieu pour la validation des nouvelles fonctionnalités suite à un nouveau besoin, aussi pour discuter avec les prestataires de développement afin de s’assurer que nos demi-interfaces seront fonctionnellement adaptables en intégration. Le tableau ci-dessous synthétise les instances de pilotage du projet avec leurs différents niveaux de responsabilité et leur périodicité :

36

Chapitre 3 : Démarche de mise en œuvre du projet Principales activités Comité de

-

pilotage

-

Périodicité / Participants

Définir les orientations du projet : -

Réunions mensuelles,

vision, bénéfices attendus, priorités, périmètre…etc.,

Participants :

Garantir la résolution de problèmes

-Directeur de projet,

critiques et l’allocation de ressources, -

-Sponsor du projet,

-Chefs de projet.

Suivre la feuille de route du projet afin d’assurer la contribution du projet aux bénéfices métiers.

Comité projet

-

Assurer le suivi des activités de mise en -

Réunions

œuvre de la solution : expression des

hebdomadaires

besoins, conception, réalisation, recette et tests d’intégration, préparation au

Participants :

démarrage et support, -

Garantir

-Chefs d’équipes

l’intégration

technique

et

fonctionnelle, -

-Direction de projet,

fonctionnelles et techniques.

Assurer les activités de conduite du changement,

-

Suivi de l’objectif de délais et statut,

-

Alertes et risques associés au planning.

Tableau 10 : Instances proposées pour le suivi du projet

37

Chapitre 3 : Démarche de mise en œuvre du projet 2.4 Matrice des responsabilités – RACI La matrice RACI décrit la participation des acteurs d’un projet dans la complétude des activités et livrables d’un projet. Cela permet de clarifier les rôles et responsabilités notamment dans des processus transverses. L’acronyme RACI décrit les 4 responsabilités/actions les plus fréquemment utilisées pour la gestion d’un projet : Responsible, Accountable, Consulted et Informed. 

Responsible : Equipes/Membres qui réalisent le travail pour achever une tâche. Pour une tâche il peut y avoir plusieurs responsable par contre un seul. D’autres Equipes/Membres peuvent participer à l’accomplissement de la tâche,



Accountable : Equipes/Membres qui valideront la complétude de la tâche et qui les délèguent au Responsable. En d’autres termes les Equipes/Membres « Accountable » doivent valider le travail que réalise le Responsable. Il ne doit y avoir qu’un seul « Accountable » par tâche,



Consulted : Equipes/Membres qui participent à la réalisation de tâche,



Informed : Equipes/Membres qui seront informés régulièrement du progrès des tâches, et obligatoirement à la fin de la tâche elle-même.

Le résultat de ce travail est illustré dans le tableau ci-dessous : Légende : R

Responsible

A

Accountable

C

Consulted

I

Informed

N/A

Non applicable

38

Chapitre 3 : Démarche de mise en œuvre du projet IBM France Activité /tâche

Stephane ROGER

Fabien FRANCHITTO

Wilfrid REAL

Rene MONEKENE

EDF

Hironui BOOSIE

Gilles BACQUET

Yassine BOUCHKARA

Amine SALHI

Elodie MENDES

Claude Denis

Client

QUICK SCAN S’assurer de la présence des différents acteurs lors des ateliers d’expression du besoin

I

N/A

N/A

C

C

C

C

C

C

N/A

A, R

Exprimer les besoins métiers

I

N/A

N/A

C

C

C

C

C

C

N/A

A, R

Démontrer des fonctionnalités SAP et leurs impacts

A

N/A

N/A

R

R

R

R

R

R

N/A

I

Faire une revue de l’infrastructure technique et définir l’infrastructure cible

I

A, R

R

I

I

I

I

I

I

I

I

Evaluer la capacité de changement du client et de ses équipes

I

N/A

N/A

I

I

I

I

I

I

N/A

A, R

Confirmer les différents périmètres organisationnels

I

N/A

N/A

C

C

C

C

C

C

C

A, R

Fournir les fichiers cibles pour les chargements des données

I

N/A

N/A

R

R

R

A, R

R

R

N/A

C

Préparer des échantillons de données pour la phase de l’activation

I

N/A

N/A

C

C

C

C

C

C

C

A, R

39

Chapitre 3 : Démarche de mise en œuvre du projet Activité /tâche

IBM France Stephane ROGER

Fabien FRANCHITTO

Wilfrid REAL

Rene MONEKENE

EDF

Hironui BOOSIE

Gilles BACQUET

Yassine BOUCHKARA

Amine SALHI

Elodie MENDES

Claude Denis

Client

VALIDATION Rédaction des Business Process

A

N/A

N/A

R

R

R

R

R

R

N/A

C, I

Confirmer le niveau global de convergence solution / processus métier

I

N/A

N/A

R

R

R

R

R

R

N/A

A, R

Présenter des fonctionnalités SAP contextualisées (valeurs supplémentaires de paramétrage et de données)

A

N/A

N/A

R

R

R

R

R

R

N/A

C

Etablir un plan d’action pour adresser les besoins hors périmètre

A

N/A

N/A

R

R

R

R

R

R

N/A

C

Confirmer les différents périmètres organisationnels et impacts liés au changement

I

N/A

N/A

I

I

I

I

I

I

I

A, R

Convertir les données de base et transactionnelles

A

N/A

N/A

R

R

R

R

R

R

R

C

Rédiger la conception des spécifications fonctionnelles de développements opérationnelles

A

N/A

N/A

R

R

R

R

R

R

I

C

Basculer sur l’environnement DEV du projet

R

A, R

R

I

I

I

I

I

I

I

I

40

Chapitre 3 : Démarche de mise en œuvre du projet IBM France Stephane ROGER

Fabien FRANCHITTO

EDF Wilfrid REAL

Rene MONEKENE

Hironui BOOSIE

Gilles BACQUE T

Yassine BOUCHKARA

Amine SALHI

Elodie MENDES

Claude Denis

Client

ACTIVATION Finaliser les scénarios et processus métier contextualisés

I

N/A

N/A

R

R

R

R

R

R

N/A

A, C

Finaliser les règles de gestion complémentaires du métier

I

N/A

N/A

C

C

C

C

C

C

N/A

A, R

Valider les guides de configuration métier

I

N/A

N/A

C

C

C

C

C

C

I

A, R

Finaliser les développements spécifiques Valider les spécifications fonctionnelles

I

I

I

C

C

C

C

C

C

A, R

I

I

N/A

N/A

R

R

R

R

R

R

R

A, R

Rédiger les tests unitaires et d’intégration

A

N/A

N/A

R

R

R

R

R

R

R

I

Construire les structures d’injection des données dans SAP

I

N/A

N/A

R

R

R

A, R

R

R

C

I

Préparer l’environnement QUAL du projet

R

A, R

R

C

C

C

C

C

C

I

I

Tableau 11 : Matrice RACI

41

Chapitre 3 : Démarche de mise en œuvre du projet 3. Architecture technique 3.1 Définition de la plateforme technique Le cœur de la solution métier Dunkerque LNG s’appuie sur l’ERP de SAP. Ce composant est porté au travers de la brique technologique SAP Netweaver. Il s’agit d’une plateforme web d’intégration propriétaire des applications SAP dotée d’une architecture orientée service (notée SOA, Services Oriented Architecture). Cette plate-forme est une intégration d'applications d'entreprise (notée EAI, Enterprise Application Integration) répondant aux besoins d’inter-échange aux standards de l'industrie informatique. La plate-forme intègre l’ensemble des outils de développement pour les applications SAP.

La plateforme SAP Netweaver permet de : 

Soutenir diverses applications SAP telles que les ERP, SRM, CRM,…,



Supporter différents types d'utilisation pour l'analyse et l'intégration, tels que SAP Business Warehouse, Portail…,



Fonctionner indépendamment (exemple d’instances autonomes) à des fins diverses, telles que : -

Fourniture de services sur des piles logicielles ABAP,

-

Surveillance et exécution de services de base (par exemple e-mail, fax, etc.),

-

Délivrer une plate-forme pour Add-ons spécifiques de l’offre SAP et partenaires.

3.2 Le paysage SAP Les projets d’intégration nécessitent des environnements étanches afin d’isoler les parties projet, maintenance et production. Pour certaines briques SAP, chaque système pourra être constitué d’un ou plusieurs mandants (sous-ensemble de données). Les paramétrages et développements sont appliqués d’un environnement à l’autre par un mécanisme propre à SAP, appelé « transport ». L’environnement Quick Scan chargé avec les meilleures pratiques IBM-SAP a été mis à disposition de Dunkerque LNG dans le Business Solution IBM vers le centre du client selon le

42

Chapitre 3 : Démarche de mise en œuvre du projet planning qu’on a défini pour la création de l’environnement de DEV et de QUAL. Pour l’environnement de production (PROD) il est sous l’entière responsabilité de Dunkerque LNG. Les «Best Practices » SAP suivent, à savoir a minima le paysage système suivant :

Figure 15: Décomposition du paysage SAP

Nous préconisons une décomposition de l’ensemble du paysage SAP en 4 environnements : 

Bac à sable : Quick Scan,



Développement (DEV) : paramétrage, développements spécifiques, tests unitaires, développement des interfaces,



Intégration (QUAL) : tests d’intégration, tests fonctionnels, tests techniques, tests des reprises,



Production (PROD) : environnement productif.

4. La gestion du transfert des connaissances Il est primordial d’identifier les compétences nécessaires à la continuité du projet au regard des travaux à réaliser. Aussi, pour assurer la pérennité de la solution et un démarrage dans les meilleures conditions possibles de l’équipe projet, il sera capital, d’évaluer régulièrement le niveau de connaissance des acteurs du projet, et donc d’évaluer la qualité du transfert de connaissances réalisé par les consultants IBM. Ce transfert de connaissances s’articule autour de 4 axes principaux :

43

Chapitre 3 : Démarche de mise en œuvre du projet

Figure 16 : Axes de transfert des connaissances

Selon ces axes, le transfert de connaissances vers l’équipe projet doit s’effectuer au fil de l’eau et non par à coup. En effet nous avons mis en place une organisation en trinôme dès le début du programme avec : -

Les leaders métier qui apportent leurs connaissances de l’existant et leurs visions de la cible,

-

Les leaders IT qui apportent leurs maîtrises des SI existants et acquièrent des compétences sur la nouvelle solution,

-

Les consultants disposant de l’expertise requise sur les modules SAP concernés, qui apportent leurs maîtrises de l’outil et leurs expériences « métier » et « outil » acquises lors de projets antérieurs.

Cette approche se décline autour de deux axes principaux : -

Un transfert au cours des phases du projet : 

Acquérir de la connaissance concernant les capacités de l’outil à répondre aux besoins métier,



Comprendre les principes de construction d’une solution SAP,



Participer aux activités de paramétrage,



Se mettre en position de maintenir la solution,



acquérir l’autonomie au fil du projet pour adapter la solution et corriger les anomalies identifiées en production.

44

Chapitre 3 : Démarche de mise en œuvre du projet -

Des sessions de formation dédiées s’articulant autour de jalons de leurs élaborations comme illustré dans le schéma suivant :

Figure 17: Elaboration des jalons pour les sessions de formation

45

Chapitre 4 : Focus sur la stratégie globale de reprise des données

Chapitre 4 : Focus sur la stratégie globale de reprise des données

Dans ce chapitre nous présentons la méthodologie et l’outillage utilisés dans la stratégie de reprise de données du projet de mise en place de SAP.

46

Chapitre 4 : Focus sur la stratégie globale de reprise des données 1. Introduction : Démarche de mise en œuvre La migration représente le cœur de ce projet. Ainsi, nous allons dédier ce chapitre à la description de la méthodologie et l’outillage utilisés dans la stratégie de reprise de données du projet de mise en place de SAP pour Dunkerque LNG et Gaz-Opale. Nous commencerons par lister les besoins exprimés en termes de typologie et d’historique de données à reprendre dans SAP avant de passer à la mise au point de la stratégie de reprise de donnée. Les premiers ateliers de migration tenus avec le client étaient consacrés à la définition du périmètre des données à reprendre, au recensement des applications sources et à la définition d’une stratégie de reprise mettons en avance les dépendances entre les objets à migrer, les modes de reprise envisagés et la séquence des opérations de reprise. L’ensemble de ces éléments alimentera par la suite la stratégie de reprise des données. Lors des ateliers de migration, nous avons approfondi l’analyse de chaque objet à migrer, en précisant les règles de gestion qui permettent de le reprendre dans le nouveau système SAP. Ces règles nous permettront de constituer les spécifications fonctionnelles et techniques de reprise. La phase d’Activation était consacrée au développement des programmes d’extraction (côté Dunkerque LNG) et de chargement (côté IBM), aux travaux d’enrichissement et de nettoyage des données (côté Dunkerque LNG) à migrer et aux tests informatiques des programmes (IBM & Dunkerque LNG). Cette phase a inclus des tests unitaires afin de valider l’adéquation entre les règles identifiées et les outils développés. Pendant la phase de préparation au démarrage, nous avons défini des Runs à blanc de reprise qui seront effectués, « grandeur nature », en quantité de données cibles à reprendre. Cela consistera à réaliser une répétition des opérations de bascule incluant la reprise de données.

Dans notre démarche, nous considérons que l’implication des utilisateurs clés de Dunkerque LNG dans la migration des données est un facteur clé de succès. Nous avons identifié les actions dont ils seront responsables dans notre démarche : 

Définir et valider la portée de migration de données : quelles données doivent être extraites et chargées dans le système SAP,



Nettoyer et enrichir les données que ce soit dans les anciens systèmes ou dans une base de données intermédiaire avant chargement,

47

Chapitre 4 : Focus sur la stratégie globale de reprise des données 

Vérifier les données avant et après les imports dans le système cible,



Analyser les écarts, les éventuelles modifications et la validation des données converties et migrées,



Valider formellement les données basées sur des rapports et des tests,



Charger manuellement les données en Production, en compléments des alimentations automatiques.

En outre, l’équipe des consultants IBM sera responsable des actions suivante : 

L’équipe fonctionnelle IBM : définir le format des objets à reprendre dans SAP, avec l’aide des outils associés à la méthodologie IBM Express,



L’équipe technique IBM et IBM Express : adapter leurs outils de chargement dans SAP pour chacun des objets identifiés.

2. Description des besoins La solution SAP a été choisie comme système d’information pour permettre le pilotage des données de Dunkerque LNG et Gaz-Opale. Le démarrage productif sur SAP coïncidera avec le démarrage de l’exploitation du terminal. Avant le démarrage il sera nécessaire de reprendre sur SAP toutes les données nécessaires à l’exploitation. Ces données comprendront aussi bien les données liées à la comptabilité, aux achats qu’à la maintenance. 3. Définition des données cibles dans SAP Les données de SAP peuvent être catégorisées de la manière suivante : 3.1 Données de base Ce sont des données qui ne sont créées ou changées que ponctuellement. Elles sont utilisées communément par plusieurs entités organisationnelles et dans plusieurs processus métiers. Ces données peuvent être partagées par des populations d’utilisateurs différentes pour différents besoins. Elles sont définies comme des données traduisant des informations de base telles que les articles, les fournisseurs, les comptes, les équipements, les nomenclatures…etc. D’une manière générale les utilisateurs vont exploiter les données de base sans avoir à les créer ou les changer.

48

Chapitre 4 : Focus sur la stratégie globale de reprise des données Les données de base sont créées ou modifiées directement dans l’environnement de production par des utilisateurs possédants un profil en adéquation avec les données manipulées. 3.2 Données de paramétrage Durant la phase d’activation de SAP, des activités de configuration avaient lieu pour répondre aux besoins exprimés en phase de validation. La création de ces données de configuration qui sont à la main de l’intégrateur est effectuée par les consultants dans l’environnement de développement et devront être transportées jusqu’à l’environnement de production. Naturellement, des tests seront effectués sur différents environnements durant la phase de transport pour s’assurer de l’adéquation de ces données avec le besoin exprimé. D’une manière générale, les données de paramétrage sont des données structurantes pour la solution et ne sont amenées à changer que rarement. Les types d’articles, les types des avis et les catégories d’immobilisation sont des exemples de données de paramétrage. 3.3 Données transactionnelles Les données transactionnelles sont des documents qui sont créés durant les activités journalières des utilisateurs. Elles changent très régulièrement et utilisent les données de base ; c’est le cas des documents d’achats, des ordres de maintenances, des factures…etc. Les données transactionnelles sont à la main des utilisateurs et sont créées directement dans l’environnement de production. 4. Méthodologie de la reprise La migration des données est un processus complexe et itératif, d’où l’importance de suivre une méthodologie stricte ainsi que de s’appuyer sur un outillage adapté. En effet, les phases amont au chargement doivent permettre d’identifier, de qualifier et de préparer les données à migrer. La constitution de bases et de structures de travail est donc indispensable. Nous détaillerons dans cette partie la structure des données cibles dans SAP ainsi que l’agencement des activités des chargements. Le schéma suivant décrit le cheminement méthodologique de reprise des données que nous avons suivi dans le projet. Chaque étape est décrite par la suite.

49

Chapitre 4 : Focus sur la stratégie globale de reprise des données

Figure 18 : Cheminement méthodologique de reprise de données

1. Découvrir : La première étape consiste à recenser et analyser l’ensemble des structures de données sources susceptibles d’être – en partie ou en totalité – reprises pour la solution SAP. Ces données sources peuvent être sous format papier, Excel ou exister dans un système Legacy. L’objectif à ce niveau est d’opérer très en amont dans le processus de reprise de données une vérification du contenu des systèmes sources pour mettre en œuvre les mécanismes de correction qui éviteront de propager des anomalies dans la solution cible. Les objectifs de cette phase sont : 

Identifier les anomalies dans les données le plus tôt possible pour réduire de façon substantielle les efforts de test et de correction,



Permettre une estimation plus précise des travaux de préparation de données,



Fournir des éléments de modélisation des données sources pour quantifier les opérations de transformation.

2. Préparer : Cette étape consiste à préparer les données à migrer en effectuant les opérations suivantes : 

Supprimer les éventuels doublons,



Harmoniser les données dans le cas où elles proviennent de différentes sources,



Enrichir les données d’informations complémentaires.

50

Chapitre 4 : Focus sur la stratégie globale de reprise des données 3. Transformer : Cette étape consiste à préparer le chargement en transformant la représentation des données du format source vers le format cible SAP. Les règles de transformation entre les données sources et les données cibles sont de la responsabilité des utilisateurs Dunkerque LNG et Gaz-Opale. Les tableaux de structures de données sont composés de six colonnes (annexe 10) : -

ID : Représente l’identifiant du champ de la structure. Cet identifiant permet de faire le lien avec les fichiers Excel de chargement car il est repris dans l’en-tête du fichier,

-

Titre : Nom du champ,

-

Format : Ce champ reprend le format de la zone (numérique, Alphanumérique, case à cocher…etc.) ainsi que la longueur du champ,

-

O/F : Décrit le caractère facultatif (F) ou obligatoire (O) du champ,

-

LV (Liste de Valeurs) : Décrit si le champ prend une valeur dans une Liste de Valeurs prédéfinies qui doivent être existantes dans SAP (par exemple type de document doit être pris dans une liste de valeur) ou si le champ est en saisie libre. La valeur « Oui » dans le champ signifie que la valeur mise dans le fichier de chargement doit faire partie d’une liste de valeur,

-

Description : Description du champ.

4. Charger : Une fois les données mises au format attendu par SAP, l’étape suivante consiste à intégrer les données dans les environnements SAP qui composent la solution Dunkerque LNG. Pour les chargements automatiques, SAP offre un ensemble d’outils et de techniques pour assurer l’intégration des données dans ses environnements. Effectivement, nous avons eu recours à l’outil LSMW (Legacy System Migration Workbench) de SAP comme outil central de la migration des données (annexe 11). Cet outil permet de développer des programmes de chargement qui vont lire en entrée les données préparées par l’étape précédente avant de les transmettre aux traitements d’intégration mis à disposition par SAP (Batch input, BAPI, Direct input, etc.). 5. Réconcilier : Une fois chargées dans l’environnement SAP, les données migrées doivent être validées par les utilisateurs Métier.

51

Chapitre 4 : Focus sur la stratégie globale de reprise des données Les utilisateurs métier devront définir avec l’assistance de l’AMOA un ensemble d’outils et de procédures permettant de confirmer que toutes les données à reprendre ont été transformées et correctement chargées. En plus, cette étape définit les outils et procédures de retraitement des anomalies constatées lors du chargement. Certes l’organisation et les outils sont définis objet par objet dans SAP, mais cette étape s’appuie sur les principes de base décrits ci-après : -Dénombrer les données reprises : La première étape de réconciliation consiste en un contrôle quantitatif des données migrées, des nombres d’enregistrements en entrée, nombre d’objets manipulés, nombre d’objets créés/modifiés, nombre et nature des erreurs sont vérifiés qui sont des informations fournies par les traitements d’intégration. Un accès au log d’exécution des programmes de chargement permet d’avoir une vue d’ensemble et détaillé des résultats. Cidessous un exemple de Log d’exécution du programme de chargement :

Figure 19: Log d’exécution du programme de chargement

Dans cet exemple nous pouvons remarquer qu’il y avait 17 805 objets à créer dont 17 803 ont été créés et 2 sont tombés en erreurs et doivent faire l’objet de retraitement. L’accès au protocole donne le détail du message d’erreur (voir schéma ci-dessous) :

52

Chapitre 4 : Focus sur la stratégie globale de reprise des données

Figure 20 : Protocole pour le détail des messages d’erreurs

Nous fournissons après chaque chargement le résultat du chargement et la Log d’erreur le cas échéant, puisque l’analyse et les actions à entreprendre suite à ces erreurs sont de la responsabilité du métier (Dunkerque LNG). -Analyser les données reprises : La deuxième étape de vérification consiste en un contrôle qualitatif des données migrées. Une comparaison des valeurs intégrées aux valeurs attendues est effectuée par le client (l’analyse des niveaux de stock par exemple), qui permettent de dénombrer et d’analyser les valeurs ou montants repris. D’ailleurs, SAP fournit en standard un nombre important de requêtes permettant d’analyser en profondeur les données reprises et de valider les données intégrées. En effet, l’analyse pourra se faire directement dans SAP en utilisant les reportings ou en effectuant des extractions au format Excel avec une comparaison avec les données en entrée.

Les listes des reportings liées à chaque objet ont été fournies à Dunkerque LNG, ainsi que les noms de tables associées. Par ailleurs, des extractions ont été effectuées à la demande du métier, pour l’analyse des données extraites qui reste de la responsabilité du métier avec l’assistance de l’AMOA. A la suite de cette étape de réconciliation, des actions de corrections nécessaires devront être définies par le métier en concertation avec IBM. Ces actions correctrices pourront s’appuyer sur les outils standards SAP.

53

Chapitre 4 : Focus sur la stratégie globale de reprise des données 5. Planning de la reprise Avant la reprise des données en production, nous avons effectué des tests sur les environnements de DEV et de QAL en plus des tests qui seront effectués sur l’environnement de pré-production. Les tests se divisent en tests de reprise de données et en test de tir à blanc et se font suivant le planning suivant :

Figure 21: Planning des tests de reprise de données

Les tests de reprise de données se sont déroulés en parallèle avec les tests unitaires, d’intégration et recette métier. Le Tir à blanc quant à lui, fera partie des activités de préparation de mise en production. 5.1 Tests de reprise de données Ces tests ont pour but de contrôler : 

L’adéquation des structures de chargement avec les données à charger,



Le fonctionnement des programmes de reprise de données.

Ce travail de test se fait en trois étapes : 5.1.1 Préparation des fichiers d’échantillons Durant cette étape, des échantillons représentatifs de chaque objet ont été fournis par le métier pour pouvoir être chargés dans le système et tester ainsi la robustesse des programmes de chargement. Cependant, chaque échantillon fourni par le métier doit être dans la structure adéquate donnée par les consultants.

54

Chapitre 4 : Focus sur la stratégie globale de reprise des données 5.1.2 Contrôle et validation des fichiers chargés Pour chaque objet chargé dans SAP, nous contrôlons la bonne intégration des données. Ce contrôle a porté sur : 

Les nombres d’enregistrements en entrée, nombre d’objets manipulés, nombre d’objets créés/modifiés,



Comparaison des données enregistrées avec les données en entrées.

Les erreurs détectées ont été analysées par l’équipe des consultants IBM afin de remonter celles provenant des données en entrées au métier pour analyse et modification. 5.1.3 Exécution des processus associés à ces chargements Une fois les données de tests ont été migrées dans le système, les utilisateurs Dunkerque LNG ont déroulé les processus métier sur ces données en vérifiant par exemple le flux d’achat d’un article consommable sur un ordre de travail…etc. Cette étape a pour but de valider d’un point de vue fonctionnel les données migrées. Ces tests sont sous la responsabilité du métier. 5.2 Tir à blanc Ces tests ont pour but de : 

Répéter les gestes qui doivent être effectués aussi bien par le métier pour la préparation et le contrôle/validation des données que par l’équipe IBM pour le chargement des données dans SAP,



Contrôler et valider le chargement de données de manière exhaustive.

Le tir à blanc se fera en trois étapes : 5.2.1 Préparation des fichiers de reprise Les fichiers de reprises de données seront préparés et contrôlés par le métier. Ces fichiers doivent être conformes aux formats donnés. Ces fichiers doivent contenir l’exhaustivité des données à la date de chargement. 5.2.2 Contrôle et validation des fichiers chargés Les activités de chargement seront effectuées par l’équipe IBM en suivant le planning défini dans le document de Cut Over. Ces données seront ensuite analysées, corrigées, validées par le métier.

55

Chapitre 4 : Focus sur la stratégie globale de reprise des données 5.2.3 Exécution des processus associés à ces chargements Dans cette étape, une partie des scénarios de tests effectués devront être déroulés de nouveau. Les scénarios à dérouler devront être définis par les utilisateurs de Dunkerque LNG et devront couvrir à minima les processus métier les plus importants. 6. Phases de tests de reprise de données Comme la migration des données est un processus itératif, les phases de tests sont essentielles pour garantir que les données seront reprises correctement dans le système cible SAP. Notre approche est basée sur les cycles suivants : - Phase d’Activation : 

Tests unitaires : tous les objets, programmes, étapes de la reprise des données sont testés individuellement (réalisé à 100%).

- Phases d’intégration et de recette utilisateurs : 

Test utilisateurs : les processus de reprise des données sont testés de bout en bout. Cette phase est synchronisée avec la recette utilisateurs (UAT). Objectif : 50% des données correctement migrées (réalisé à 100%),



Bascule à blanc n°1 : les processus de reprise des données sont testés de bout en bout sur l’ensemble du périmètre à reprendre selon un planning proche du plan de bascule. Objectif : 90% des données correctement migrées (réalisé à 100%).

- Phase de préparation au démarrage : 

Bascule à blanc n°2 : identique à la bascule à blanc n°1, l’objectif est d’atteindre les 100% de données correctement migrées et validées. Les tests sont effectués dans l’environnement de « QUAL rafraîchi » (Pré-production).

56

Chapitre 4 : Focus sur la stratégie globale de reprise des données

Figure 22 : Cycles de chargement des données

57

Bilan et livrables par phase du projet Activités

Acteurs

Résultats

Livrables clés

Quick Scan Faire une revue des processus sélectionnés

Consultants fonctionnels IBM, Utilisateurs-clés métier

-Périmètre projet et réponse fonctionnelle du préconfiguré

-Liste des processus métier par scénario « version initiale »

-Évaluation macro des développements à réaliser (dont les reprises de données)

-Liste des besoins en développements spécifiques « version initiale »

Démonstration des fonctionnalités SAP et de leurs impacts

Consultants fonctionnels IBM

Compréhension du métier / macro-processus

-

Faire une revue de l’architecture applicative

Consultant technique IBM

Objectifs et concepts clés d’architecture applicative cible

-

Faire une revue de l’infrastructure technique et définir l’infrastructure cible

Equipe technique DKLNG

Objectifs et concepts clés d’architecture technique cible

Recommandations infrastructure technique.

Évaluer la capacité de changement du client et de ses équipes

Management DKLNG, Référents métier, AMOA

Rôles et responsabilités par processus cibles

Liste de rôles par processus Métier « version initiale »

Confirmer les différents périmètres organisationnels

Consultants fonctionnels IBM, Utilisateurs-clés métier

Première vision de la stratégie du plan formation

Recommandations du plan de formation

58

Comprendre la stratégie du client, sa position sur le marché et ses opportunités opérationnelles

Management DKLNG, Référents Métier, AMOA

Bénéfices attendus du projet

Business case du projet

Validation Revue des scénarios métier contextualisés

Consultants fonctionnels IBM, Utilisateurs-clés métier

Scénarios métier revus dans le prototype, avec échantillons données métier

Liste des scénarios métier de périmètre établie (supports en .ppt). « version intermédiaire »

Confirmer le niveau global de convergence solution / processus métier

Consultants fonctionnels IBM, Utilisateurs-clés métier

Mise à jour des fit/gap par processus Métier

Liste des procédures Métier (supports en .doc) « version intermédiaire »

Démonstration des fonctionnalités SAP contextualisées (valeurs supplémentaires de paramétrage et de données)

Consultants fonctionnels IBM, Utilisateurs-clés métier

Périmètre de paramétrage et de données prêt à être importé dans le DEV

Plan d’action pour adresser les besoins hors périmètre

Consultants fonctionnels IBM, Utilisateurs-clés métier

Trajectoire de mise en œuvre sur les processus hors périmètre V1

Recommandations sur les flux exclus du périmètre « version intermédiaire »

Confirmer les différents périmètres organisationnels et impacts liés au changement

Consultants fonctionnels IBM, Utilisateurs-clés métier

Compléments sur la stratégie du plan formation

Adaptations du plan de formation

Conversion des données de base et transactionnelles

Consultants fonctionnels IBM, Utilisateurs-clés métier

Planification des reprises des données

Stratégie de reprise des données

Conception des spécifications fonctionnelles de développements

Consultants fonctionnels IBM

Planification des tests unitaires à prévoir

Spécifications fonctionnelles pour les développements.

59

-

Environnement DEV du projet

Consultant technique IBM, Equipe technique DKLNG

Environnement de DEV installé

-

Activation Finalisation des scénarios et processus métier contextualisés

Consultants fonctionnels IBM

Les scénarios métier et les processus métier sont documentés

Finalisation des scénarios et processus métier.

Finalisation des règles de gestion complémentaires du métier

Consultants fonctionnels IBM

Livraison des paramétrages complémentaires

Guides de configuration par processus métier.

Validation des guides de configurations métier

Utilisateurs-clés métier, AMOA

Règles de gestion complétées et traduites en valeurs de paramétrage

Guides de configuration par processus métier validés.

Développements spécifiques

Consultants fonctionnels et techniques IBM

Livraison des développements spécifiques

Spécifications fonctionnelles et techniques. « version finale »

Validation des spécifications fonctionnelles

Utilisateurs-clés métier, AMOA

Spécifications fonctionnelles validées

Spécifications fonctionnelles validées par le métier.

Tests unitaires des développements spécifiques

Consultants fonctionnels et techniques IBM

Stratégie de construction des tests d’intégration et de recette

Plan de tests d’intégration.

60

Construction des structures d’injection des données dans SAP

Consultants fonctionnels et techniques IBM

Formats pivots de reprise des données

Livraison au métier des formats pivots de reprise des données

Enrichissement des structures des formats pivots

Utilisateurs-clés métier, AMOA

Tests unitaires de reprise des données

Fichiers de chargements des données « nettoyées » à injecter

Environnements QUAL et PROD du projet

Consultant technique IBM, Equipe technique DKLNG

Environnement de QUAL et de PROD installés

Tableau 12 : Bilan et livrables du projet

61

-

Conclusion générale et perspectives Le déploiement d’un système d’information pour la gestion des processus métiers améliore significativement les résultats financiers des entreprises qui cherchent à réduire leurs dépenses, en diminuant les coûts imputables à la main d'œuvre, aux consommables, aux erreurs et aux délais. Le terminal méthanier de Dunkerque qui a considéré le projet comme une priorité stratégique avance à pas sûr vers la recette fonctionnelle après avoir réalisé les tests d’intégration en prenant en charge les directives des consultants IBM France dont je faisais partie. Outre l’aspect purement technique, le stage m’a considérablement apporté de fortes améliorations à mes compétences fonctionnelles, notamment dans la modélisation des systèmes d’information d’entreprise. J’ai ainsi pu côtoyer de plus près le métier de consultant qui fait appel à la fois à des compétences techniques ainsi qu’à des qualités relationnelles vu la relation de confiance entretenue avec le client. De plus, J’ai pu témoigner de première main de la criticité du rôle de consultant vis-à-vis du choix d’une solution. Le défi ultime durant le projet était d’analyser les besoins de plusieurs entités parallèlement, en respectant les spécificités et exigences de chacune au niveau des processus métiers, ainsi que de trouver des solutions dans un délai bien défini pour ces besoins. Sur le plan humain, le projet m’a inculqué l’esprit de travail en équipe ; ce qui était extrêmement enrichissant grâce aux collaborations et aux partages de connaissances effectués. Suite à cela, j’ai pu développer mon sens de communication et mes compétences managériales. Subséquemment, cette mission représente un élan sûr pour me lancer dans le domaine de déploiement des SI, qui s’avère très prometteur, et bien évidemment, très passionnant.

La solution sur laquelle je suis intervenu sera exploitée en «Go Live» le 15 Novembre 2015, pour piloter et gérer les différentes activités citées précédemment. Elle devra répondre à toutes les fonctionnalités exprimées antérieurement par le client, dans la perspective d’assurer le succès du deuxième plus important chantier industriel en France.

62

Bibliographie Documents internes [1] Blueprint SAP pour Le Terminal Méthanier de Dunkerque. [2] Business Processes in Plant Maintenance (PLM300). [3] Maintenance and Service Processing: Preventive (PLM310). [4] Maintenance Processing: Controlling & Reporting (PLM316). [5] Maintenance Work Clearance Management (PLM320). [6] Plan assurance qualité (IBM – Dunkerque LNG). [7] SAP Best Practices, Business Process Documentation.

Ouvrages [1] Andrea CAVALLERI & Massimo MANARA, 100 things you should know about authorizations in SAP, édition 2012. [2] Jean Luis G.Muller, 100 questions pour comprendre et agir : Management de Projet, AFNOR, 2009.

Webographie [1] http://www.dunkerquelng.com/fichiers/fckeditor/Commun/dunkerque_lng/medias/2014/Point presse1eroctobre.pdf [2] http://www.ibm.com/ibm/fr/fr/?lnk=fap-pldi-frfr [3] http://www.learnsap.com [4] http://www.nttdata.com/jp/ja/news/release/2011/pdf/forrester_SAP_2011.pdf [5] http://help.sap.com [6] https://training.sap.com/shop/learninghub [7] http://fr.wikipedia.org

63

Annexes

64

Liste des annexes Annexe 1: Diagramme de Gantt réel ..................................................................................................... 66 Annexe 2 : Analyse Fit-Gap par processus métier (exemple création des gammes) ............................. 67 Annexe 3 : Extrait des abaques de chiffrage ......................................................................................... 68 Annexe 4 : Spécification fonctionnelle détaillée .................................................................................. 69 Annexe 5 : Business Process du flux de la maintenance préventive ..................................................... 80 Annexe 6 : Business Process du flux de la maintenance opérationnelle ............................................... 81 Annexe 7 : Exemple des tests unitaires des gammes............................................................................. 82 Annexe 8 : Exemple de 10 / 65 scénarios des tests d’intégration.......................................................... 86 Annexe 9 : Planche comité projet.......................................................................................................... 88 Annexe 10 : Exemple du tableau de structures de données ................................................................... 89 Annexe 11 : LSMW (Legacy System Migration Workbench) .............................................................. 90

65

Annexe 1: Diagramme de Gantt réel

66

Annexe 2 : Analyse Fit-Gap par processus métier (exemple création des gammes) Activité

-Saisie d'une gamme pour l'équipement (IA01) 1- Saisir les données dans l’écran « créer gamme équipement » 2- Saisir la liste des opérations (description première opération, travail, unité). Puis sélectionner la pièce de rechange.

Correspondance Métier

Définition sur SAP PM des gammes de maintenance pour les équipements avec une possibilité de mentionner les opérations, la durée de chaque opération et même le poste de travail qui va exécuter l’opération.

Écart fonctionnel

Solution contournement / Développement spécifique ?

Il n’y a pas d’écart fonctionnel avec les mêmes critères possible sur SAPPM.

--

Une gamme pour les activités de maintenance préventive est créée

67

Complexité du Développement -Très simple -Simple -Moyen -Complexe --

% Fit-Gap par rapport au standard

Acteurs

0%

Spécialiste maintenance

(à choisir dans la liste de rôles SAP associés au processus)

Annexe 3 : Extrait des abaques de chiffrage SAP Development Object Types

Editable Values for Object Counts

Edit only when you are sure about a different % distribution or definite Object Counts across different complexities

Phase 1 Reports V-High High Medium Low V-Low

ABAP ECC Interfaces V-High High Medium Low V-Low

PI Development V-High High Medium Low V-Low

Phase 2

0 5% 20% 55% 15% 5% Total

Objects 0 0 0 0 0 0

Hours 0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

Reports V-High High Medium Low V-Low

ABAP ECC Interfaces V-High High Medium Low V-Low

PI Development V-High High Medium Low V-Low

Phase 3

0 5% 20% 55% 15% 5% Total

Objects 0 0 0 0 0 0

Hours 0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

68

Reports V-High High Medium Low V-Low

ABAP ECC Interfaces V-High High Medium Low V-Low

PI Development V-High High Medium Low V-Low

0 5% 20% 55% 15% 5% Total

Objects 0 0 0 0 0 0

Hours 0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

0

Objects

Hours

5% 20% 55% 15% 5% Total

0 0 0 0 0 0

0 0 0 0 0 0

Annexe 4 : Spécification fonctionnelle détaillée

Spécification fonctionnelle détaillée Ajout zone transaction IW49

69

IBM

Projet Dunkerque LNG SPECIFICATION ¨PROJET

Spécification fonctionnelle détaillée

Document

:

DKLNG IBM - SFD - DEVXXXX - Ajout zone transaction IW49 v1.doc

Réf. Projet

:

DKLNG

Système (ECC, EP, BI)

:

ECC

ID Développement

:

Version

:

Phase

:

Prépare

Sujet

:

Modèle de document

Rédacteur

:

Relu par

:

Accessibilité

:

Documents Associés

:

Domaine / Module

:

PM

date de livraison

:

Yassine BOUCHKARA

date de rédaction

:

29/09/2015

Claude DENIS

date de relecture

:

29/09/2015

SFD TU

Statut (provisoire/validé)

:

I : Initialisé / Brouillon - draft L : Livré pour validation – submit for approval V : Validé - Validated 1

IBM

Projet Dunkerque LNG SPECIFICATION ¨PROJET

Approbation

Approuvé par

Nom

Rôle

Consultant

Yassine Bouchkara

Consultant SAP PM

Développeur

Claude Denis

Leader technique

Signature

Date

Historique du document

Version

Raison de changement

Date

1.0 1.1 1.2 1.3

2

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

Questions/Points de suspension

3

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

10 Pages Documents de référence SFD

Document SFD.doc

4

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

1

Description générale ............................................................................................................ 6 1.1 Définition du besoin .................................................................................................................... 6 1.2 Solution technique proposée ....................................................................................................... 7 1.3 Composants de la solution technique .......................................................................................... 7

2

Extensions ........................................................................................................................... 8 2.1 Append structure ......................................................................................................................... 8 2.2 Implémentation de l’extension .................................................................................................... 8 2.3 Logique de traitement ............................................................................................................... 10

5

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

Description générale Ajout dans le report de la transaction IW49 d’une colonne avec le nom de la ou des personne(s) en charge de l’opération.

Définition du besoin A partir de la transaction IW49 reporting des opérations d'un OT, ajouter le nom de la personne responsable de celle-ci. Dans la mesure où l’on affecte un poste de travail à une opération, seuls les employés du poste de travail peuvent être assignés à l’opération. Dans l’OT, au niveau de l’opération, une fois le poste de travail affecté, dans l’onglet « Interne », renseigner le champ « nombre » pour indique le nombre de personnes qui vont effectuer la tâche, ainsi que la durée du travail :

6

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

Solution technique proposée -

Ajout de la zone ZZENAME(Personne) dans la structure RIHAFVC (Structure d'affichage du reporting des opérations des OT)

-

Implémentation de la BADI BADI_EAM_SINGLELEVEL_LIST (point d’extension ES_EAM_LIST_ENHANCEMENTS) pour ajouter une zone au report (transaction IW49)

DEVELOPMENT TYPE

[ x ] Nouveau développement [ ] Modification de l’existant [ ] Modification d’objets SAP standard

DEVELOPMENT TOOLS

[ x ] Programmation ABAP [ ] Programmation tierce [ ] Développement LIS – Infos Structures client [ ] Workflow

Composants de la solution technique What are the technical objects involved in the design, and their relationships? OBJECT

DESCRIPTION

ELÉMENT DDIC FIELD-EXIT MODULE FONCTION STRUCTURE APPEND

ZRIAFVC1 (structure RIHAFVC)

REPORT SAPSCRIPT TABLE APPEND TRANSACTION USER-EXIT AUTRES

BADI: BADI_EAM_SINGLELEVEL_LIST 7

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

Extensions Append structure Ajout de la zone ZZENAME (Personne) dans la structure RIHAFVC. Pour cela créer un append structure ZRIAFVC1

Implémentation de l’extension Nom de l’extension

ES_EAM_LIST_ENHANCEMENTS

Nom de l’implémenation

ZES_EAM_LIST_ENHANCEMENTS2

de l’extension Nom définition de la BADI

BADI_EAM_SINGLELEVEL_LIST

Nom implémenation de la

ZPM_SINGLELEVEL

BADI Interface

IF_EX_BADI_EAM_SINGLELEVELLIST

Classe implémentante

ZPM_CLASS_SINGLELEVEL

Méthode

IF_EX_BADI_EAM_SINGLELEVELLIST~FILL_ADD_FIELDS

8

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

9

Projet Dunkerque LNG

IBM

SPECIFICATION ¨PROJET

Logique de traitement 

Récupérer l’ « ID de l'enregistrement du besoin en capacité » (zone ‘bedid’) et le « Compteur interne » (zone ‘bedzl’) de la table AFVC en efectuant une jointure avec la table AFKO (sur la zone ‘aufp’)



Avec les zones bedid et bedzl récupérer dans la table KBED la liste des personnes affectées à l’opération. Stocker le résultat dans une table interne ‘lt_kbed’.



Si lt_kbed n’est pas vide alors rechercher le nom des personnes dans la table PA001 à partir de la zone ‘pernr’. Concatener dans la zone ‘rihafvc-zzename’ les noms séparés par '/' avec une limite à 132 caractères. On affiche '/...' en fin de liste si elle est trop longue.



Si lt_kbed est vide alors rechercher le nom de la personne (dans la table PA001) à partir du matricule (zone ‘afvc-pernr’) et alimenter la zone ‘rihafvc-zzename’

10

Annexe 5 : Business Process du flux de la maintenance préventive

Nom et Prénom



Fonction

Rédaction

Yassine BOUCHKARA Consultant

Entité de rattachement IBM/GBS

Vérification

Gilles BACQUET

Consultant

IBM/GBS

Validation

Stephane ROGER

Chef de projet

IBM/GBS

Cartographie fonctionnelle des processus Maintenance préventive

Flux propre à MM Flux propre à PM Flux propre à FI/CO

80

Annexe 6 : Business Process du flux de la maintenance opérationnelle



Nom et Prénom

Fonction

Rédaction

Yassine BOUCHKARA

Consultant

Entité de rattachement IBM/GBS

Vérification

Gilles BACQUET

Consultant

IBM/GBS

Validation

Stephane ROGER

Chef de projet

IBM/GBS

Cartographie fonctionnelle des processus Maintenance opérationnelle

Flux propre à MM Flux propre à PM Flux propre à FI/CO

81

Annexe 7 : Exemple des tests unitaires des gammes

    

Nom des tests : Nom technique de l'application Domaine fonctionnel : Business Process : Application & Version :

Gammes Standard SAP PM Maintenance préventive SAP PM

Scenario Version 0.1

Vérificateur Dunkerque LNG DEV

Date

Objectif

Numéro Description de l'étape d'étape

Données de test

Créer une gamme pour poste technique

1.1

Auteur 21/06/2015 Yassine BOUCHKARA

Pour accéder à la transaction Gamme du poste Menu SAP : technique 00-TAI-11ALogistique/Maintenance/Mainte 104 sauvegardée nance planifiée/Planification du travail/Gammes opératoires/Pour poste technique/Créer Code de transaction : IA11

82

Résultat attendu

Résultat du test

Correct Date (Oui/Non)

L'écran Créer gamme poste technique : écran initial est affiché

Gamme du poste technique 00TAI-11A-104 sauvegardée

Oui

17/06/2015

1.2

Compléter la zone Poste technique (Exemple : DK/S93/ZND/B11A) puis sélectionner entrée

Gamme du poste technique 00-TAI-11A104 sauvegardée

1.3

Compléter les zones suivantes, puis sélectionner entrée : Capteur grpe gammes : compléter avec une description Statut de la gamme : sélectionner dans une liste déroulante. Exemple : 2 (OK pour ordre) (ajouter cette tâche si une autre gamme a déjà été créée pour ce poste technique : sélectionner le bouton Nouvelles entrées) Sélectionner le bouton Opération

Gamme du poste technique 00-TAI-11A104 sauvegardée

Compléter les colonnes suivantes pour chaque opération, puis sauvegarder Clé : sélectionner dans une liste déroulante. Exemple : PD01 Description opération Durée U. : sélectionner une unité dans une liste déroulante

1.4

1.5

L'écran Créer gamme poste technique : vue général en-tête est affiché (ou bien l'écran Créer gamme poste technique : liste des gammes est affiché si une autre gamme a déjà été créée pour ce poste technique) L'écran Créer gamme poste technique : vue général en-tête est affiché Les valeurs saisies sont affichées (ou bien l'écran Créer gamme poste technique : liste des gammes est affiché si une autre gamme a déjà été créée pour ce poste technique)

Gamme du poste technique 00TAI-11A-104 sauvegardée

Oui

18/06/2015

Gamme du poste technique 00TAI-11A-104 sauvegardée

Oui

19/06/2015

Gamme du poste technique 00-TAI-11A104 sauvegardée

L'écran Créer gamme poste technique : liste des opérations est affiché

Oui

20/06/2015

Gamme du poste technique 00-TAI-11A104 sauvegardée

L'écran Créer gamme poste technique : écran initial est affiché Le message suivant est affiché : Gamme du poste technique sauvegardée

Gamme du poste technique 00TAI-11A-104 sauvegardée Gamme du poste technique 00TAI-11A-104 sauvegardée

Oui

21/06/2015

83

Créer une gamme pour équipement affectée à une stratégie

2.1

2.2

2.3

2.4

Pour accéder à la transaction Menu SAP : Logistique/Maintenance/Mainte nance planifiée/Planification du travail/Gammes opératoires/Equipement/Créer Code de transaction : IA01 Compléter la zone Equipement (sélectionner un équipement affecté à un point de mesure en heure) puis sélectionner entrée

Gamme équipement 10000078 enregistrée

L'écran Créer gamme poste équipement : écran initial est affiché

Gamme équipement 10000078 enregistrée

Oui

22/06/2015

Gamme équipement 10000078 enregistrée

Gamme équipement 10000078 enregistrée

Oui

23/06/2015

Compléter les zones suivantes, puis sélectionner entrée : Capteur grpe gammes : compléter avec une description Statut de la gamme : sélectionner dans une liste déroulante. Exemple : 2 (OK pour ordre) (ajouter cette tâche si une autre gamme a déjà été créée pour ce poste technique : sélectionner le bouton Nouvelles entrées) Compléter la zone Stratégie d'entret. (Exemple : BOG-DK) puis sélectionner le bouton Opération

Gamme équipement 10000078 enregistrée

L'écran Créer gamme équipement : vue général en-tête est affiché (ou bien l'écran Créer gamme équipement : liste des gammes est affiché si une autre gamme a déjà été créée pour cet équipement) L'écran Créer gamme poste équipement : vue général en-tête est affiché Les valeurs saisies sont affichées (ou bien l'écran Créer gamme équipement : liste des gammes est affiché si une autre gamme a déjà été créée pour cet équipement)

Gamme équipement 10000078 enregistrée

Oui

24/06/2015

L'écran Créer gamme équipement : liste des opérations est affiché

Gamme équipement 10000078 enregistrée

Oui

25/06/2015

Gamme équipement 10000078 enregistrée

84

2.5

2.6

Compléter les colonnes suivantes pour chaque opération, puis sélectionner le bouton le bouton Md.Entr (Liste modules entretien) Clé : sélectionner dans une liste déroulante. Exemple : PM01 Description opération Durée U. : sélectionner une unité dans une liste déroulante Pour chaque opération sélectionner un module d'entretien en cochant la checkbox correspondante Puis sauvegarder

Gamme équipement 10000078 enregistrée

L'écran Modifier gamme de l'équipement : liste des modules d'entretien est affiché

Gamme équipement 10000078 enregistrée

Oui

26/06/2015

Gamme équipement 10000078 enregistrée

L'écran Créer gamme poste équipement : écran initial est affiché Le message suivant est affiché : Gamme équipement