De la théorie à la pratique : Industriel et Logistique

understanding the business process of the client that’s related to the functional aspect of the job, to customizing standard or specific application which are one of the most important aspects of the profession. Agility, adaptation and involvement are the three major forces that have driven this work.

Amongst the different missions that I did, the one with a direct impact on the system followed the V Cycle methodology, which allows for a smooth division of the production steps, beginning with needs assessment, and its functional and technical translation via the drafting of the detailed functional specification, the realization of the solution which includes the development and configuration of the system, then the validation of the solution through unit and integrated tests.

ملخص يعرض هذا التقرير العمل الد ي أنجزته في إطار مشروع التخرج داخل شركة فيسيوفرنسا, خلال الفترة من 4 مارس 2019 إلى 4 سبتمبر من نفس العام للحصول على درجة الماجستير في هندسة النظم الصناعية من جامعة لورين و درجة مهندس دولة في شعبة الصناعة و لوجيستيك من المدرسة الواطنية للعلوم التطبيقية بطنجة خلال هذا التدريب ، انضممنا إلى فريق مشروع الأوبرا، ادي شرعته مجموعة أطلنتيك، التي تقع بفارنسا، والمختصة في صناعة منتاجات الراحة الحرارية عبر العالم، والدي من خلاله ساهمت في العديد من الماهم التي تهدف إلى تكويني كمستشار وظيفي في ساب. هده المهام كانت تكتسب تدريجيا نطاق وتعقيد بما يتناسب مع التدريبي المهني، بدءاً من فهم العمليات التجارية الشيء الدي يؤثرعلى الجانب التواصلي لمستشاروحتى تحديد معايير الحلول القياسية أو المحددة التي تشكل أحد أهم جوانب العمل الاستشاري الحيوية، التكيف والمشاركة هي القوى الثلاث الرئيسية التي دفعت بتنفيذ هذا العمل المهام التقنية ذات التأثير القوي على النظام إتبعت منهجية دائرة في، مما يسمح بتقطيع سلس لخطوات التنفيذ، بدءاً من تحديد الضرورة وترجمتها الوظيفية والتقنية من خلال صياغة المواصفات الوظيفية التفصيلية، وتطبيق الحل الذي يشتمل على تطوير ومعلمة النظام ، ثم التحقق من صحة الحل من خلال الاختبارات الوحدوية والمتكاملة

Actuellement la mondialisation a fait que les entreprises vivent et évoluent dans un monde de très haut concurrence toutes ces entreprises ils ont pour but d’améliore et de fluidifier leurs processus métier pour atteindre des nouveaux horizons et gagner plus de parts de marché.

Dans cette optique et pour face à cette concurrence ces organisations font appel à des outils technologiques pour gérer l’ensembles de leurs travail qu’il que soit leurs secteur d’activité et permettre ainsi aux dirigeants de prendre des décisions stratégique, SAP ERP est la solution technologique la plus adoptée en raison de son adéquation avec le besoin des clients et sa capabilité d’harmoniser les fonctions et donner en temps réel une vision globale des flux physiques, d’informations et financières d’entreprise.

De ce point de vue le GROUPE ATALNTIC leader dans le domaine de chauffage et de la climatisation et étant conscient de transformation qui va engendrer un tel système au niveau de l’accessibilité, la fiabilité et l’homogénéité des données relatives à ses processus métier sur son système d’information actuel, a décidé d’implémenter une solution SAP en interne dans le cadre de projet OPERA grand projet d’implémentation de la solution SAP S/4 HANA avec une scope de plus 6 modules fonctionnels, afin de mieux gérer son activité.

Pour répondre à cette demande Le GROUPE VISEO en tant qu’intégrateur a été mandaté pour accompagner son client dans l’implémentation de son ERP, et mener à bien ce projet de transformation du système d’information.

De mon côté, et pour me situer, j’ai intégré l’équipe des consultants de projet plus exactement l’équipe Achats, où je me suis monté en compétence en tant que consultant fonctionnel junior SAP logistique en participant à plusieurs missions et tâches parfois touchant autres domaines que les Achats.

Le présent rapport représente l’ensemble du travail réalisé durant la période de stage et sera scindé en 4 chapitres :

1. Le première chapitre je présente le cadre général du projet en premier lieu l’organisme d’accueil VISEO ensuite l’organisme client le groupe Atlantic et la management projet

2. Le deuxième chapitre je mets en lumière le projet OPERA et une présentation de SAP.

3. Le troisième et le dernier chapitre sera centré sur mes missions principales en tant que PMO (Project Management Office) notament la production des KPIs pour la bonne gestion de la conduite du projet et sur le fruit de mon travail, la conception d’une application SAP FIORI.

Nowadays globalization has made companies live and evolve in a world of high competition all these companies they aim to improve and streamline their business processes to reach new horizons and gain more share in the market. In this context, and in the face of this competition, these organizations are using technological tools to manage all their work, regardless of their sector of activity, thereby enabling managers to make strategic decisions.

SAP ERP is the most adopted technology solution because of its relevance to the needs of customers and its ability to harmonize functions and give a real-time global vision of physical, information and financial flows of a business.

From this point of view the ATALNTIC GROUP leader in the field of heating and air conditioning and being aware of the transformation that will generate such a system in terms of accessibility, reliability and homogeneity of data relating to its business processes on its former information system, decided to implement an SAP solution internally as part of project OPERA large project implementation of the SAP S / 4 HANA solution with a scope of over 6 functional modules, to better manage its activity.

To meet this demand The VISEO GROUP as an integrator has been mandated to support its client in the implementation of its ERP and carry out this project of the information system transformation. For my part, and to situate myself, I joined the team of project consultants more precisely the purchasing team, where I rose in competence as a junior SAP logistics functional consultant by taking part in several missions and tasks sometimes affecting other areas than the purchase.

This report represents all the work done during the internship period and will be divided into 4 chapters:

1. The first chapter I present the general framework of the project in the first place the host organization VISEO and the client organization GROUPE and the management of the project.

2. The second chapter I highlights the OPERA project and give a presentation of the SAP.

3. The third and last chapter will focus on my main missions as PMO (Project Management Office) especially the production of KPIs for the good management of the project and on the fruit of my work, the design of an SAP FIORI application.

 Présentation de l’organisme d’accueil et de client

Dans ce chapitre nous présentons en première partie l’organisme d’accueil VISEO Paris en citant ces principales particularités et ensuite on enchaînera avec son client le

GROUPE ATLANTIC

I. Organisme d’accueil.

VISEO 1. Historique Fondée en 1999, VISEO connait depuis, une croissance ininterrompue, en suivant une stratégie d’expansion consiste sur la création, développement et acquisition d’activités. Sa présence au niveau mondial et comptant plus de 2000 collaborateur dans son actif, VISEO a su se développer tout en gardant son indépendance, cette approche s’inscrit dans sa stratégie d’évolution et de croissance. VISEO a pour ambition d’accompagner les grands projets de transformation et veille à la réussite des projets mener par l’ensemble de leurs clients.

Le développement de VISEO s’est écrit sur une forte valeur méthodologique et technologique, mise au service de la maitrise des processus métier, de l’exploitation et la valorisation des données. Désormais, l’avenir du groupe il s’oriente ainsi sur le numérique.

La raison de cette approche stratégique est certainement est liée à l’ambition de VISEO de s’adapter à son marché et d’offrir à ses clients une réponse à tous leurs enjeux numériques. Figure 1 : l’évolution du groupe VISEO depuis 1999. 2. Chiffres clés pour VISEO Grace à sa présence dans cinq continents et son développement et sa croissance, le revenu du groupe à évoluer d’une manière considérable pour atteindre 218 millions en 2018.

D’autres part ce développement a aussi engendré une croissance au niveau de ses collaborateurs, en 2018 VISEO a atteint 2250 Collaborateurs. Figure 2 : L’évolution du chiffre d’affaire de VISEO. Figure 3 : L’évolution des effectifs de VISEO. 3. Centre de compétence de VISEO Etant une société de conseil et de service numérique, VISEO sa finalité se focalise sur l’accompagnement des entreprises dans leurs projet stratégique de transformation depuis la modélisation des processus métier et jusqu’à la conception d’expériences utilisateurs afin de rendre ces entreprises résiliente, agile et capable de conquérir la compétition numérique.

Pour assurer un meilleur accompagnement VISEO se base sur trois leviers Les clients connectés : VISEO ouvre la possibilité de réinventer l’expérience client surtout dans cette époque de client connecté. L’entreprise digitalisée : Assurer un meilleur accompagnement des entreprises dans leurs processus d’implémentions des logiciels numériques.

Les innovations de demain : Vu l’évolution rapide des nouvelles technologies VISEO veille que ces clients soit conscient des sauts technologiques et au même temps leurs doter des dernières technologies les plus prometteuses. 4. Partenaires & Clients Etant connu le leader en transformation digital et vu la complémentarité de ces centres de compétence, VISEO possède plusieurs partenaires mondiaux ainsi que des clients.

Partenaires : Pour permettre à ses clients de tirer profit de la meilleure capacité d’innovation VISEO a établie des partenariats stratégiques avec des éditeurs globaux cabale de répondre à les exigences des clients VISEO. Figure 5 : Les partenaires clés de VISEO Clients : VISEO aide 26 sociétés du CAC 40 et d’autres champions à asseoir leur leadership mondial et accompagne les acteurs les plus dynamiques à devenir les leaders de demain. Figure 6 : Clients VISEO 5. Organisme du groupe VISEO.

II. Organisme Client.

Groupe ATLANTIC 1. Historique Le groupe ATLANTIC il est fondé en France en 1968 par deux ingénieurs, Paul Radat et Pierre Lamoure, le Groupe s’appuie sur une forte culture d’industriels, mais aussi sur un état d’esprit qui place les hommes au cœur de son stratégie. Ayant une vision vers l’avenir, mais fort de son expérience, il a su évoluer et élargir constamment ces domaines de compétences.

Aujourd’hui l’entreprise compte plus de 15 marques stratégiques de solution de confort thermiques dans 4 domaines : Le chauffage, L’eau chaude sanitaire, La climatisation, La ventilation, 2. Pôles d’activité Le groupe Atlantic s’appuie sur une organisation en 6 Pôles d’activité complémentaires garantissent une expertise accrue dans chacun de ces domaines.

La collaboration transversale entre les 6 pôles permet d’assurer la cohérence des solutions préconisées pour répondre aux exigences des clients ainsi que l’utilisateurs. Figure 8 : Pôles d’activité de Groupe ATLANTIC. 3. Les marques du groupe Atlantic. C’est par la renommée des marques que possède le groupe Atlantic que les clients le connaissent, ces marques destinées au consommateur final ou aux industriels ont chacune un positionnement et une identité propre, mais elles ont toutes en commun l’esprit d’innovation, la qualité produit et le sens du service, ci-dessous les différentes marques du groupe : 4. Groupe ATLANTIC dans le monde.

Le groupe ATLANTIC est aujourd’hui présent sur 4 continents il dispose de 25 sites répartis au monde entier dont 11 est en France doté d’une ligne de production performante et en constante adaptation avec les enjeux économiques, il fabrique une large gamme de solution présent dans plusieurs marchés mondial à travers des bureaux commerciaux. Figure 10 : Présence dans le monde du groupe ATLANTIC.

III. Management de projet.

Nous avons établi les éléments indispensables, pour la bonne gestion de notre projet et pour une visibilité claire sur le déroulement du travail. Dans ce qui suit, nous allons présenter les acteurs, la méthodologie de projet cycle en V et risques projet.

1. Missions du stage : J’ai eu l’opportunité de travailler sur des missions variées qui touchent à plusieurs aspects du travail d’un consultant fonctionnel, au début en tant que PMO (Projet Management Office) où j’ai travaillé sur :

• La production des KPI pendant la phase de poste-démarrage de site de Fontaine pour les domaines métiers (Achats, Logistique, Production, Articles, Technique, etc…) En intervenant directement avec le chef de projet coté VISEO. La deuxième partie de mon stage a eu place au sein de l’équipe achats, constitue de mon encadrante et moi où j’ai commencé ma montée en compétence en tant que Consultant Fonctionnel Junior SAP – MM. Les missions que j’ai réalisées sont :

• Réalisation de chiffrage d’une application spécifique en collaboration avec l’équipe développement.

• Déroulement des scénarios de test unitaire dans le cadre des développements spécifiques

• Paramétrage de plusieurs solutions standards et spécifiques.

• Conception d’une solution SAP FIORI Risque Fournisseur.

2. Planning réel des tâches et missions réalisés : Au début du stage je n’avais pas une vision claire sur la nature ou le déroulement des différentes missions. J’évoluais au fur et à mesure des besoins relevés par les domaines du projet. Et ma transition du PMO vers le domaine Achats en faisait partie.

Pour cela, réaliser un planning prévisionnel des missions de stage s’est avéré impossible. Le planning réel cependant (ANNEXE 1 du rapport) reprend l’enchainement des missions que j’ai effectuées.

3. Analyse des risques : AMDEC Pour maitriser et identifier les risques de la manière la plus exhaustive possible, j’ai mis en place une démarche AMDEC projet qui a comme objectif l’étude de tous les risques potentiels que je peux rencontrer lors de la réalisation des différentes tâches et missions.

J’ai envisagé par la suite des actions correctives et préventives pour dépasser chaque problème qui peut menacer notre projet. Niveau G : Gravité O : Occurrence D : Détectabilité 1 Négligeable Improbable Fortement détectable 2 Mineure Peu probable Détectable 3 Majeure Probable Peu détectable 4 Catastrophique Fortement probable Non détectable Tableau 1 : Echelle de gravité La criticité : C = G*O*D Le tableau suivant synthétise l’analyse des différents risques relevés : Risque Cotation Actions proposées G O D C Non-respect des délais des tâches assignées 4 4 4 64.

Plusieurs actions ont été mises en place pour réduire ces risques :

• Suivi journalier de la réalisation des tâches affectés.

• Points quotidiens sur mon niveau d’apprentissage

• Des missions évolutives en termes de connaissances

• Participation à des activités de groupe Formation et compréhension des flux métier du client 4 4 4 64 Non maitrise des outils 3 4 4 48 Mauvaise compréhension des besoins client 4 4 4 64 Mauvaise compréhension des consignes 4 3 3 36 Mauvaise intégration à l’équipe projet 2 1 1 2 Accès aux outils, aux Sharepoints, problèmes techniques de connexion, etc. 2 2 1 4 Tableau 2 : Analyse AMDEC 4. Méthodologie du Cycle en V Pour le bon déroulement des missions techniques (Paramétrage, Spécification) j’ai suivi les étapes de la méthode « Cycle en V », elle s’appelle aussi la méthode de gestion de projet Waterfall, ou « en cascade ».

Elle provient du secteur de l’industrie et s’est répandue aux projets informatiques dans les années 80, consiste à passer par une liste d’étapes prédéfinies de façon séquentielle. L’analyse des besoins du client est naturellement toujours la première étape de la méthode de gestion Cycle en V. Viennent ensuite la phase de la conception, la rédaction des spécifications fonctionnelles et la planification des développements.

Le processus de développement peut alors débuter avec la création d’une première fonctionnalité, sa validation et/ou son éventuelle correction, puis sa maintenance. Cet enchaînement d’étapes recommence alors séquentiellement, jusqu’à ce que toutes les fonctionnalités demandées par le client aient été réalisées. Et si à l’issue de la dernière livraison, des mises à jour ou des modifications sont nécessaires, le même cycle sera répété. Figure 11 : Méthodologie du projet en Cycle V.

Définition du projet OPERA et présentation du progiciel SAP.

Dans ce chapitre nous allons présenter le projet OPERA le projet auquel j’étais affecté où j’ai participé à plusieurs tâches et missions. Un projet de refonte de système d’information au profit du groupe ATLANTIC en exposant ses enjeux, ses objectifs et sa structure, en suite on met la lumière sur SAP ERP la solution choisie par le groupe, on présentera sa définition ses phases d’implantions ainsi que ses composants fonctionnels notamment le module Achats : MM (Materials management) le domaine dans lequel j’ai réalisé mon stage. Cette présentation servira comme référentiel pour la suite de ce rapport.

I. Projet OPERA.

1. Enjeux et approche et objectifs du projet OPERA. Pour accompagner son développement international, renforcer son efficacité collective et l’harmonisation de ses processus, le groupe ATLANTIC a lancé le projet OPERA parmi les grands projet d’implémentions de la nouvelle technologie SAP S/4 HANA inclut aussi l’intégration de CRM (Customer Relationship Management) Salesforce pour la gestion de relation client. Ce projet doit permettre à l’ensemble de ses collaborateurs d’échanger et de partager des données harmonisées de qualité entre toutes les entités du groupe en toute confiance, cette visée est d’une grande importance pour la stratégie d’évolution et la croissance du groupe.

Le projet OPERA doit permettre de répondre à trois enjeux majeurs : Accompagner la croissance du Groupe : SAP dispose d’une couverture géographique mondiale est aujourd’hui l’ERP le plus diffusé, donc il permettre d’assure une ouverture maximale vers les clients, fournisseurs, autres partenaires et futures acquisitions du Groupe. Pérenniser l’excellence opérationnelle : Ayant un catalogue des bonne pratiques, SAP doit permettre de couvrir les exigences métier sans faire appel à des développements spécifiques.

La technologie SAP permet une exploitation des données en temps réel à l’échelle du Groupe et renforcera la capacité de pilotage. Développer l’innovation et la satisfaction client : Le choix de l’outil technologique et sa fiabilité avérée permet de donner des moyens d’enrichir la satisfaction client et d’accompagner la digitalisation des métiers du groupe.

Pour répondre à ces enjeux et dans l’optique d’accompagner le groupe dans ces ambitions le Groupe ATLANTIC a lancé le projet OPERA qui a pour objectif de mettre en place un nouveau système d’information qui comprendra 2 parties : ERP & CRM. • Côté ERP le Groupe a choisi la dernier version de SAP de la nouvelle technologie SAP S/4 HANA qui offre une ouverture sur le digital. le premier mondialement avec 23% de part du marché seulement à lui méme, et qui couvrira la partie «back office».

Pour faire le déploiment de cette solution le groupe a choisi VISEO comme etant integrateur. • Coté CRM le groupe a choisi Salesforce leader mondial dans la gestion de relation client une solution qui couvre la totalité de la relation client, pas seulement vente/commerce mais aussi la relation avant-vente, configuration et la relation après réclamations, mises en services et aussi SAV. Pour faire l’implémentation le groupe a choisi un autre intégrateur.

2. Le périmètre du projet OPERA. Ce projet d’envergure concerne l’intégralité du Groupe, touchant les 6 pôles d’activités ainsi que les fonctions supports. Un projet transversal affectant les sites industriels et commerciaux de 15 pays dont (France, Egypte, Italie…) Avec 10 domaines fonctionnels concernés à savoir Production, logistique et les Achats… Ce périmètre du projet accompagnera l’évolution et la croissance du Groupe. Figure 13 : Le périmètre actuel du projet OPERA.

3. L’organisation du projet OPERA. Un projet d’envergure comme le projet OPERA nécessite une organisation polyvalente compétente pour assurer le bon déroulement de ce projet, dans cette perspective OPERA a opté pour une structure trio « BPO/IPO et intégrateur » et a défini pour chaque partie des objectifs précis.

Le BPO est le propriétaire du processus métier et son garant dans le comité projet, ci-dessous ses rôles et responsabilités :

• Définit les processus de son domaine avec la communauté métier • Constitue et anime l’équipe projet Opéra pour son domaine

• Vérifie l’intégration transversale de son domaine

• S’assure du respect des règles et de la qualité des données

• Valide l’efficacité des processus (indicateurs)

• Suit l’évolution des pratiques métiers L’IPO est responsable du Système d’Information « Métier » au sein de la DSI, voici ses rôles et responsabilités :

• Garantit la capacité du système d’information à couvrir les exigences métier et contribue à l’optimisation des processus.

• Organise, coordonne, anime l’équipe projet informatique associée au projet pour leur métier et diffuse les informations projets au sein de la DSI (RIS compris).

• Évalue la cohérence des évolutions, intègre les processus dans les outils et vérifie la conformité de la solution L’Intégrateur c’est le garant du cadre des bonnes pratiques métier décrites dans SAP, et c’est le responsable de paramétrage réalisé dans le système.

4. Les phases du projet OPERA et le Core Model. Comme chaque projet de transformation de système d’information, le projet OPERA est structuré en 4 macro phases linéaires. i. Analyse métier : La phase 1 du projet OPERA se focalise sur les métiers du groupe consiste à standardiser et modéliser l’ensemble des processus métier du groupe en se basant sur une approche des best practices en vue de sélectionner la solution la plus adaptée au groupe. ii. Choix de solutions et intégrateurs : cette phase dans sa globalité a pour objectif de choisir la solution à déployer et avec quel intégrateur. Finalement le groupe a choisi la solution SAP S/4 HANA et VISEO comme Intégrateur. iii.

Construction du Core Model : Est une étape clé du projet OPERA. Le Core Model décrit l’organisation, les données et les processus communs qui seront appliquées durablement au sein du Groupe ATLANTIC en se basant sur les bonnes pratiques disponibles dans SAP. C’est un changement de pratiques du groupe, tous les métiers et les sites contribueront activement à la construction de ce Model y compris les Key Users projet, l’équipe projet et les équipes de la DSI Figure 15 : Les éléments de Core Model. Ce Core Model n’est jamais définitif, d’une part parce qu’au fur et à mesure des nouveaux déploiements, il s’enrichira de retours d’expériences, de nouvelles fonctionnalités nécessaires (localisation = adaptation aux exigences réglementaires et client locales) et aussi parce que l’ensemble de bonnes pratiques et de fonctions proposées par SAP ne cesse de s’enrichir avec les montées de version, alors la possibilité de compléter le Core-model, avec des fonctions dont le groupe aura besoins ultérieurement. iv.

La dernière phase est divisée entre deux sous phases la première consiste à déployer 4 sites pilotes et apporter plus de fonctions au Core Model. VISEO est en charge de cette étape en assurant à la fois la conception et le paramétrage de la solution et au même temps la formation des BPOs et IPOs pour piloter eux-mêmes les déploiements des autres sites qui suivent. Figure 16 : Les phases d’OPERA. Actuellement nous somme dans la phase de déploiement des 4 sites pilotes. 4 sites se sont déjà déployés et se sont fonctionnels sur le nouveau système d’information.

Par mesure de mettre en pratique les compétences acquises par les équipes interne du groupe un site intermédiaire a été ajouté plus spécifiquement le Site de FONTAINE donc on parle plus de quatre sites pilotes mais plutôt de cinq, j’ai intégré ce projet lors de déploiement de ce site, son Go live c’était le 1 juillet de cette année, et à l’heure où j’écris ces lignes on est dans les étapes premières de déploiement de MESIYEU le dernier site dans cette phase de projet.

Ci-dessous un tableau décrivant les 5 sites pilotes : Sites Descriptions GA SYNERGY C’est une société du support, les domaines majeurs impactés par sa transformation sont la fonction finance et gestion et fonction support. Atlantic International C’est une société commerciale qui achète des produits finis des autres sites du groupe et les reventes au client final, le périmètre fonctionnel concernés c’est la fonction achat, vente et service, finance et contrôle de gestion.

Site de SAINT-LOUIS C’est une société industrielle spécialisées dans la fabrication des radiateurs le projet de refonte de son système d’information comprendra 7 domaines fonctionnels : • Production • Logistique • Qualité • Achats • Finance et gestion • Services Site de FONTAINE C’est une société industrielle spécialisée dans la fabrication des chauffe-eau le projet touchera l’ensemble de sa chaine logistique de l’approvisionnement jusqu’à la vente MESIYEU C’est une société mixte incluant à la fois la fabrication et la vente au même site donc on parle d’une volumétrie des activités importante.

Le projet de transformation de système d’information au profit de ce site concerne l’intégralité de fonctions de l’entreprise. Tableau 3 : : Les sites pilotes de projet OPERA Figure 17 : : les sites pilotes de projet OPERA. Chaque site a été déployé indépendamment des autres en suivant une méthodologie d’implémentation SAP commençant par la préparation ensuite la réalisation en passant par les tests et finalement l’étape de Cut-over avant le go live. Toutes ces phases d’implémentation seront appréhendées dans la deuxième partie de ce rapport.

II. Présentation de l’ERP SAP et sa méthodologie d’implémentation.

1. Introduction à l’ERP SAP. L’ERP c’est un progiciel de gestion intégré, personnalisable, modulaire et qu’a pour objectif de mettre en place une seule base de données entre toutes les fonctions de l’entreprise (Logistique, Achats, comptabilité, contrôle de gestion, etc.) ceci donne une vision globale et transversale de l’entreprise contrairement à la structure traditionnelle en verticale où tous les domaines sont isolés, par conséquent les entreprises sont face à des contraintes majeures au niveau de déroulement de flux d’activités qu’a un caractère transversal.

De plus un tel système élimine la redondance des données, chaque mise à jour au sein d’une fonction est appliquée sur les données des autres fonctions cela permet aux utilisateurs d’avoir en temps réel des informations de qualité et assure une meilleure interaction entre les domaines par conséquent une amélioration de la productivité SAP est l’ERP le plus utilisé au monde à ce jour, avec 23% de part de marché.

Ce qu’il fait son succès c’est la couverture fonctionnelle qui offre à ses clients dans six secteurs d’activité différents (Énergie et ressources naturels, Banque et assurance, Secteur des biens de consommation, Industrie manufacturières, Secteur des tertiaires, Services publics) dans le monde entier, pour les grandes entreprises ainsi que pour les PME (Petites et Moyennes Entreprises). Figure 18 : Le pourcentage des parts de marché des ERP

2. L’évolution de SAP ERP. Etant le leader mondial dans son domaine. Le logiciel SAP a été conçu par 5 anciens ingénieurs d’IBM en 1972. Et dès lors a connu plusieurs modifications au long de son évolution, au niveau de ses version et ses plateformes technologiques ci-dessous une description globale de la série de l’évolutions de logiciel : • SAP R/1 : Lancé en 1972, c’est le premier produit de la société SAP qui gère seulement la fonction comptabilité financière. • SAP R/2 : en 1979 la société a lancé un nouveau produit plus performant et ça fait une révolution à l’époque vu ses capacités à gérer différentes langues et devise. • SAP R/3 : basé sur une architecture 3 tiers (client-serveur) jusqu’à aujourd’hui cette architecture c’est le standard pour les systèmes d’information. • SAP ECC (ERP Central Component) : couramment abrégé par SAP ERP il comprend des composants spécifiques pour un métier comme le SAP CRM (Customer Relationship management).

Parmi les ERP les plus utilisé jusqu’à maintenant surtout la version 6.0. • SAP S/4 HANA : la nouvelle solution technologique annoncée en 2015. C’est une plateforme utilisant la technologie In memory sur la base de données SAP HANA qui permet une meilleure accessibilité des données, ouvre la possibilité d’être déployer sur site, en cloud ou sur un modèle hybride, cette version a connu l’ajout d’un quatrième serveur, le serveur WEB afin de donner à l’utilisateur un accès au système à travers un navigateur. Le SAP S/4 HANA est la version choisie par le comité de pilotage de projet OPERA, plus spécifiquement la version (1610) la dernière au moment de lancement du projet. SAP S/4 HANA offre une meilleure expérience utilisateur UX par le biais de la solution SAP FIORI développée sur le Framework SAPUI5, c’est une interface utilisateur contenant une centaine d’applications, un tout nouveau concept remplaçant les transactions utilisées sur l’ancien système par des tuiles cela permet de donner à chaque utilisateur une vue plus personnalisables selon les rôles qu’il dispose, la chose qui permet de bénéficier des gains de productivité importantes.

On compte trois catégories des tuiles : SAP FIORI fonctionne sur n’importe quel machine (PC, tablette, smartphone) un outil ergonomique permettant d’affranchir plusieurs contraintes techniques. Avec la sortie de SAP FIORI, SAP a donné naissance à la notion de KPI et analyse en temps réel.

Cette solution permet aux utilisateurs de faire un suivi sur l’état sans sortir de leur interface métier, par exemple suivre le nombre des commandes en retard ou la valeur de stock par un simple coup d’œil. Pour un utilisateur, l’interface FIORI se décompose en un écran d’accueil contentent les tuiles nécessaires pour son travail et en deux autres tuiles optionnelles : Mes taches et Notifications et alertes. Figure 20 : Les écrans Fiori Aujourd’hui le Groupe fait la montée de version de son système d’information de (1610) vers (1809) la dernière version disponible sur le marché actuellement, une étape stratégique pour tirer bénéfices des nouvelle fonctionnalités proposées par SAP. 2. Les environnements du système SAP. Nous distinguos trois environnements de travail différents et chaque environnement contient plusieurs mandant. Un mandant représente un sous-système contenant ces données qui lui sont propre c‘est l’équipe des administrateurs qui se charge de créer et définir ces environnements ainsi que les utilisateurs qui peuvent y accéder.

Environnement de développement (DEV) : Au niveau de ce system l’équipe de développeurs ainsi que l’équipe des consultants font leur développement ainsi que le paramétrage nécessaire ensuite on transporte ces modifications dans l’environnement suivant à travers des OT (Ordre de transport). C’est à ce niveau qu’on fait la conception de zéro des applications SAP ou bien les adaptions du standard au besoin client. Environnement de qualité (QUAL) : Dans cet environnement le consultant exécute des cas de tests sur le travail réalisés afin de valider ou non en analysant les écarts entre le besoin de client et le développement fait, dans le cas contraire en remonte l’ordre de transport vers l’environnement DEV pour ajustement.

Environnement de production (PROD) : c’est l’environnement sur laquelle travail l’utilisateur final, aucune modification ni test ne doit être appliquée, on fait le chargement de ce système par les données réelles de métier de l’entreprise contrairement aux autres environnements qui contient des données créées par nos équipes pour faire des tests là-dessus. Figure 21 : La structure du système SAP. 3. Les phases du projet d’implémentation de SAP. Après la construction de Core Model et d’adopter les bonnes pratiques et des nouvelles règles de gestion il vient la phase de déploiement de la solution SAP dans les cinq sites pilotes.

Pour chaque projet de déploiement de SAP il y une méthodologie et une suite d’étapes standardisées à suivre pour l’implémenter, notamment dans le cadre du projet OPERA où on a suivi une suite d’étapes qui peuvent être décrits comme suit : Fits & Gaps : Dans cette première étape on fait l’analyse de l’existant on compare le trio (Core Model, Les processus métier dans le site, Standard SAP) pour avoir une idée sur la conception de la solution voulue et déterminer concrètement ce qui peut être couvrir par le standard ou son paramétrage et déceler des besoins client qui ne peuvent pas être assurer par le standard SAP et qui nécessitent un développement spécifique.

Réalisation : Apres avoir déterminer le model de la solution à concevoir qui est en parfaite cohérence avec le besoin client il vient l’étape de la réalisation qui consiste à faire les développements spécifiques nécessaires par les développeurs, c’est souvent lier à des modifications de code ABAP le langage de programmation de SAP, ou de faire le paramétrage par les consultants de standard sans faire appel aux développeurs. Dans cette étape on fait le test aussi au même temps pour vérifier le bon fonctionnement.

Tests : Cette étape est d’une très grande importance en termes de charges et de temps car il consiste à vérifier la solution mises en place et il est déroulée en deux sous-étapes :

• Tests d’intégration : consiste à tester la solution par les consultants en termes d’intégration avec d’autres applications dans d’autres domaines.

• Tests UAT (User Acceptance Test) : Durant les tests UAT on fait la formation des utilisateurs clés en collaboration avec le BPO/IPO et au final des ces séminaires les utilisateurs clés il prennent la main pour dérouler les tests et s’assurer que ça répond parfaitement à leur besoin métier et surtout qu’ils sont capables de travailler avec cette solution. Cut-Over : c’est la phase d’avant démarrage le terme désigne le fait de basculer de l’environnement tests et développement vers l’environnement de PROD, et ça consiste à préparer le système pour le lancement cela inclut le chargement des données de base métier (Clients, Fournisseurs, Articles, etc…) et c’est dans le cadre de RUN 3 le dernier chargement de données et s’assure que cela fonction correctement. Go Live: Go live ou démarrage.

Ce jour on fait la bascule de l’ancien système vers le nouveau système SAP tous l’équipe de projet est sur site pour accompagner les utilisateurs finals dans leurs travails et corriger au même temps s’il y a des points bloquants qui remonte dans le système, après cela un support sera assuré en dehors du site. 4. Conclusion. Dance cette chapitre j’ai représenté le reste de contexte du projet, j’ai présenté ainsi le projet OPERA ses phases ainsi que l’outil SAP choisi par le Groupe.

L’introduction sur l’outil SAP servira comme référentiel pour le chapitre suivant sur les missions que j’ai effectué durant mon stage.

Travail effectué en tant que PMO & la conception d’une application SAP FIORI.

J’ai réalisé mon stage de fin d’études au sein de l’équipe Achats chez VISEO, où J’ai intégré le projet OPERA à la fin de la phase des tests d’intégration pour le déploiement du 4éme site pilote du Groupe ATLANTIC, où j’ai participé à divers missions et tâches d’aspect techniques aussi bien que managériales, visant toutes ma montée en compétence en tant que consultant fonctionnel junior SAP logistique.

J’ai élaboré des cas de test en faveur des consultants pour le traitement des anomalies apparues lors des tests d’intégration. J’ai commencé à m’auto-former dans les sujets à présenter aux utilisateurs clés lors des séminaires des tests UAT au site de Fontaine afin d’accompagner les BPO/IPO durant cette phase, au terme de cette étape j’ai eu l’occasion de participer à la correction des anomalies UAT met en évidence par les utilisateurs clés.

Ensuite j’ai réalisé un chiffrage d’une application spécifique en collaboration avec l’équipe développement en se basant sur un descriptif métier. Par ailleurs j’ai participé à plusieurs paramétrages lier au domaine Achats que j’ai occupé, je cite ; le paramétrage de la stratégie de validation des commandes d’achats, le paramétrage du schéma de prix, paramétrage du formulaire évaluation fournisseur.

Par souci de concision je ne détaillerai dans la suite de ce rapport que les principales missions que j’ai réalisées. Le planning réel des différentes tâches réalisées pendant mon stage est dans l’annexe 1 de ce rapport. I. Mise en place de KPIs pour la conduite du projet dans le cadre de PMO 1. Introduction à la fonction PMO (Projet OPERA) Le PMO (Project Management Office) c’est une fonction au sein d’une organisation qu’a pour objectif de centraliser une partie de pilotage et du support en faveur des projets tels que le nôtre le projet de transformation de système d’information OPERA, son concept est de favoriser la réussite du projet par l’amélioration de pilotage, les méthodologies et les ressources et compétences utilisées donc il peut agir à la fois sur le projet aussi bien que sur l’entreprise dans sa globalité.

Durant mon stage chez VISEO, j’ai occupé la fonction PMO une mission qui m’a permise d’avoir une vision globale sur le déroulement du projet notamment dans la phase de poste-démarrage, en travaillant directement avec le chef de projet coté VISEO. Ma mission principale en tant que PMO a été de produire les KPIs (Key Performance Indicator) indicateur de performance en français lors de la phase poste-démarrage pour chaque domaine métier, (Achats, Logistique, production, Technique…) cette étape durant mon stage m’a permis de voir le projet avec une vision plus élargie.

Pendant mon stage j’ai été chargé de produire plusieurs KPIs quotidiennement. L’idée derrière c’est de permettre au comité de pilotage d’avoir un état d’avancement du démarrage et de mesurer la performance de nouveau système.

Le moment de création de ces KPIs a été crucial et doit se baser sur des processus d’extraction standard à exécuter étape par étape pour ne pas générer dans données fausses. Un KPI PMO produit doit être qualifier d’un KPI SMART c’est-à-dire qui remplit certaines conditions : Spécifique : Lier à un objectif spécifique à atteindre, facile est simple à comprendre pour permettre à ses utilisateurs de ne pas se perdre. Mesurable : Un KPI lier à un objectif cette objectif doit être quantifiable ou qualifiable pour savoir où ce qu’on est par rapport le seuil de l’objectif.

Atteignable : Cet indicateur de performance doit être logiquement atteignable aux yeux des utilisateurs. Réaliste : Le seuil d’objectif doit être réaliste ce qui permet aux participants de ne pas abandonner au fur et à mesure de l’avancement de l’objectif.

Limité dans le temps : Un objectif représenté par un KPI doit avoir une date de début et une date de fin c’est-à-dire délimiter dans le temps. Figure 23 : Les indicateurs SMART pour un KPI Pour la réalisation des de ces KPI il fallait en premier lieu les déterminer, donc j’ai fait une réunion avec le chef de projet en présence des chefs des domaines métier afin de se focaliser que sur les KPI les plus pertinents qui donneront un aperçu instantané sur la situation du projet pendant la phase de poste démarrage, j’ai fourni ces KPI quotidiennement à partir de système PROD et qui étaient présentés dans différentes réunions avec le client. J’ai fait le monitoring des KPI pendant un mois après le démarrage qu’il a eu lieu le 1er juillet.

2. Présentation des KPIs démarrage de site Fontaine. La liste des KPIs produits pour le démarrage du site de Fontaine par domaine et les KPI correspondants peuvent se résumer comme suit.

Domaine Technique : On a eu deux KPI pour monitorer ce domaine à savoir :

1. Le nombre de dumps par jour, c’est une erreur liée au disfonctionnement de système, il apparaitre quand l’utilisateur exécute des requêtes qui font arrêter le programme ABAP correspondant, ce KPI permet de voir le nombre des erreurs dans le système PROD.

2. Le nombre des Idocs en erreurs par jours.

Idoc veut dire un document intermédiaire ça rentre dans un protocole d’échange entre SAP et d’autres machines, cet indicateur nous donne une idée sur le niveau de performance de chargement entre systèmes. Ci-dessous un exemple de monitoring effectué au sein de ce domaine pour une journée donner : Domaine Article : Ce domaine a été jugé d’être décrit par un seul KPI ; le nombre d’articles crées par jour et par types d’articles, l’intérêt de cet indicateur est de savoir combien de produits rentrent à l’usine d’une manière journalière.

Domaine Production : Pour ce domaine on a suivi le nombre des demandes d’achats créer par le MRP un système qui se base sur les prévisions de vente et la nomenclature des produits pour générer des besoins planifiés sous forme des demandes d’achats. Domaine Achats.

C’est le domaine où je fais partie, pour notre domaine Achats on a trouvé pertinent de monitorer :

1. Le taux de transfert de demande d’achat en commande d’achats, ça permet aux acheteurs de revoir des contrats avec les fournisseurs pour que la conversion soit exécutée.

2. Le nombre des commandes d’achat d’indirectes créées par jour, les achats indirectes c’est les produits qu’on achète mais qui ne rentrent pas dans la nomenclature des produits fabriqués au sein de l’usine.

Le deuxième indicateur taux de conversion des demandes d’achats est décrit par le tableau suivant : Division Fontaine Organisation d’Achat B004 Total des demandes d’achats transférées en commandes Total des demandes d’achats créées Taux de transfert en commande/ jour. Total 4676 7264 Taux de transfert Global 64% Tableau 4 : Le taux de transfert des demandes d’achats en commande d’achats. Domaine Logistique : Pour ce domaine on s’est mis d’accord pour suivre la valorisation de stock en euros pour le site de Fontaine, cet indicateur permet de voir d’une manière journalière la valeur physique de stock dans les magasins, et de piloter le nombre des camions/produits préparés, chargés et expédiés par jour.

Les KPIs pour ce domaine sont représentés en annexe 2.

3. La procédure de génération des KPIs sur SAP. Pour produire ces KPIs, j’ai effectué un certain nombre de requêtes journalièrement (des transactions SAP) sur les données de la veille pour les présenter au jour suivant. Afin de gagner de la rapidité et de temps, il fallait trouver un moyen pour industrialiser le processus d’extraction des données de système et leurs traitements sur Excel. Je souligne que ce qui permet d‘exécuter ces requêtes c’est la notion de transaction qui dispose le système SAP.

Une transaction est un code qui permet de lancer une requête à savoir affichage, création ou modification, en générale il est composé de quatre caractère (Exemple ME23 pour afficher les commandes d’achats).

Par souci de concision, je vais présenter que la méthode suivie pour la génération de KPI dans le métier Achats le domaine où je me situe. Ci-dessous je détaillerai le 1er KPI qu’on a monitoré au sein de domaine Achats et les étapes que j’ai suivi pour extraire les données.

Pour avoir le nombre total des commandes créées j’ai suivi ces étapes :

1. Premièrement je me connecte au système avec mon login et mot de passe.

2. Pour avoir les documents d’achats crées par jour on lance la transaction ME2N après on obtient un écran de sélection avec des champs à remplir (Division, Organisation d’achat, Créé le) pour ne pas ressaisir chaque jour ces champs j’enregistre une variante qui enregistra l’écran avec les donnes remplies, je choisi la variante puis j’exécute.

Pour le champ Division on met 1006 c’est la codification système pour le site de Fontaine, ainsi pour n’avoir que les commandes d’achats d’indirectes je renseigne la valeur I001 pour l’Organisation d’achat qui désigne l’entité qui gère les produits d’indirects que l’usine achète et qui ne font pas partie de sa production. 3. J’obtiens ensuite toutes les commandes créées par jour, je fais l’export vers Excel en cliquant sur l’icône « calcule avec tableur », pour analyser ces donnes j’ai inséré un tableau croisés dynamiques avec un graphique, en sélectionnant les champs nécessaires. Chaque collage de données dans ce fichier Excel engendra une mise à jour de tableau croisée dynamique ainsi que le graphe dans les feuilles suivantes.

II. La conception d’une application spécifique SAP FIORI.

1. Je consacre cette dernière partie de mon rapport à la conception d’une application SAP FIORI, un besoin qu’a été formulé par l’équipe projet de domaine Achats pour mettre en place un process de calcul et de restitution du Risque Fournisseur dans SAP FIORI, une fonctionnalité déjà en place dans l’ancien système du groupe ATLANTIC et l’objectif et de mettre en place une solution identique dans SAP. Cette application nommée Risque fournisseur permet de calculer par fournisseur le ratio représenté par le domaine Achats chez ce fournisseur par rapport à la valorisation des expéditions d’une division du Groupe ATLANTIC.

Cette mission est considérée la plus importante que j’ai réalisé pendant mon stage vu le temps qu’on lui a consacré et la charge de travail exigée.

2. Description du besoin de la solution. Cette fonctionnalité permet à l’utilisateur final de calculer le risque fournisseur sous forme d’un ratio, sur la production et par conséquent sur l’expédition de l’usine, sorte du périmètre des fonctionnalités assurées par le standard SAP.

Dans cette optique, le groupe ATLANTIC souhaite réaliser un outil de reporting interactif, permettant d’évaluer le risque qui peut engendre un fournisseur sur sa production pour appliquer des mesures concrètes par rapport sa stratégie d’approvisionnement.

Le groupe ATLANTIC veut explorer les dernières solutions SAP pour pouvoir développer une solution, qui permettra un échange aisé entre l’utilisateur et l’application. J’ai résumé le besoin exprimé par le client à l’aide du digramme d’expression de besoin suivant.

3. Description des spécifications fonctionnelles de l’application. Dans cette partie nous décrivons la règle de gestion pour le calcul des ratios ainsi on déterminera les éléments de l’écran de l’application et finalement on représente les données de base qui sera utilisées par l’application. a. Méthode de calcul des Ratios L’application doit permettre d’afficher deux sortes de ratio le premier ratio met en exposition le chiffre d’affaire par rapport le fournisseur le deuxième met en exposition l’article par rapport le chiffre d’affaire.

Voici les règles de gestion suivies pour le calcul de ces deux ratios : Ratio « Exposition CA au fournisseur » : (Valorisation production annuelle des produits finis qui ont dans leur nomenclature des articles du fournisseur pour la division choisie).

Valorisation de la production annuelle de la (ou les) division choisie

• Ce ratio est effectué sur les fournisseurs actifs, concernant les produits finis et articles qui ont un statut actif dans le système.

• La valorisation est faite au prix standard annuel actuel.

• Si un article change de fournisseur dans l’année, on prend tout de même la production sur l’année car l’on veut évaluer le risque sur l’année.

• Si plusieurs fournisseurs actifs pour le même article, on ne prend pas en compte le pourcentage de répartition.

Chaque fournisseur est considéré comme approvisionnant 100 % des besoins. Ratio « Exposition CA à l’article » : (Valorisation production annuelle des PF qui ont dans leur nomenclature l’article choisi pour la (ou les) division choisie).

Valorisation de la production annuelle de la (ou les) division choisie

• Ce ratio est effectué pour les articles et composants de statut actif.

• La valorisation est faite au prix STANDARD. b. Les éléments de l’écran de l’application Risque Fournisseur. Comme l’application sera réalisé sur SAP FIORI qui offre des interfaces modernes et intuitifs vu son orientation vers l’expérience utilisateur, cet élément nous aidera dans la phase de validation de la solution par le client.

L’écran de l’application SAP FIORI doit inclure dans la mesure du possible les mêmes fonctionnalités existantes dans l’ancien solution. L’écran peut être divisé en différents blocs décrits ci-dessous.

BLOC A : informations générales contenant les champs

• Choix de la période sur 12 mois soit janvier à décembre soit juillet à juin et saisie du début de l’année correspondante. Dans l’exemple ci-dessus l’année de début est 2011, le choix de période fait que le calcul se fera de Janvier à Décembre 2011. Si le choix de période avait été Juillet à Juin le calcul se serait fait de Juillet 2011 à Juin 2012.

• Valorisation et ratios : remplacer les données affichées par le choix de la société puis de la division : Saisie de la société : proposer par défaut la société de connexion avec changement possible Division : par défaut la division de l’utilisateur avec accès à une liste des divisions de la société pour un choix multiple.

• Bouton « lancer le calcul » permet pour la période d’exécuter le calcul de la valorisation globale de la production en prix standard annuel pour la division ou la liste de divisions choisie. BLOC B : fournisseurs

• Saisie du code ou recherche possible du fournisseur que l’on veut consulter sur la période et la division ou liste de divisions.

• Affichage du nom du fournisseur avec son pourcentage et la valorisation en montant

• Affichage en consultation de tous les articles de ce fournisseur participant au calcul de base : Code article, nom de l’article, statut de l’article, pourcentage propre à l’article Coche permettant à l’utilisateur de désélectionner un article du calcul du fournisseur Bouton PF concernés permettant d’accéder à l’écran des PF concernés par l’article

• Bouton « Simuler » permet de lancer le calcul en prenant en compte uniquement les articles cochés pour le fournisseur : les valeurs calculées sont affichées dans Ratio Sim % et Valorisation Sim.

• Bouton « Enregistrer paramétrage article », permet de sauvegarder les articles cochés ou décochés

• Bouton « Enregistrer valorisation simulée », permet de sauvegarder la simulation dans les champs simulation prévus à cet effet de la table spécifique BLOC C : articles

• Saisie du code article ou recherche possible de l’article

• Bouton + permet d’ajouter autant d’article que souhaité

• Les articles saisis s’affichent en dessous en liste avec le code, le nom, le statut et la valorisation en montant

• Le Ratio et la valorisation de la liste des articles se calculent en dynamique à l’ajout de chaque article. BLOC D : extraction EXCEL

• Choix de l’extraction : Fournisseurs ou articles (toujours sur la période indiquée)

• Choix du répertoire de destination de l’extraction

• Bouton Excel, permet de lancer l’extraction et de l’afficher en dynamique à l’écran.

A l’issue de cette étape une maquette conçu sur l’outil SAP BUILD Open source de l’application a été proposée au client. c. Les données de base utilisées par l’application. La base de données dans SAP est structurée sous forme des tables de données. L’affichage de certaines données sur l’application Risque Fournisseur fait référence à ces tables. Ci-dessous un tableau récapitulatif des tables de données utilisées : Table Types de données LFA1 Cette table contient les donnes de base de fournisseur. MARC Table des données de base des articles au niveau de la division (Données poste). MBEW Cette table concerne la valorisation des produits fini par rapport la division. MAST Cette table fait la liaison entre un articles et sa nomenclature. Tableau 4 : Liste des tables de base des données utilisées. 4. Réalisation et conception de l’application. En vue de la réalisation de l’application, le Groupe ATLANTIC a opté pour la solution standard SAP ; Analysis Path Framework (APF) et en l’adaptant sur le besoin. Un Framework qui permettre de créer des applications interactives, orientées graphiques en effectuant des simples configurations.

Je présente brièvement l’outil dans sa globalité dans la suite de cette partie, ensuite je mets la lumière sur le travail réalisé par l’équipe des développeurs et je clôture cette partie par les tâches que j’ai effectué pour la réalisation de cette application. a. Analysis Path Framework (APF) L’APF ou (Analysis Path Framework) permet de créer des applications FIORI interactives où on peut effectuer une analyse déroulante pour faire une étude personnalisée sur un KPI et voir l’évolution de ceci via des représentations multidimensionnelles telles que des tables et des diagrammes, cet outil donne l’utilisateur le rôle de définir ses chemins d’analyses.

Un chemin d’analyse contient plusieurs étapes, chaque étape est déjà prédéfinie représente des données sur l’interface utilisateur, ce dernier a le choix de choisir ces étapes et enregistre son chemin d’analyse en activant des filtres.

L’image ci-dessous représente la mise en forme d’une application APF, suivie des explications, elle a la même interface que notre application Risque Fournisseur mais avec des données différentes. Voici l’image de la tuile APF pour concevoir et configurer des applications APF : b. Mon travail effectué pour la conception de l’application APF Risque Fournisseur. Comme chaque application logicielle, la partie développement a été pris en charge par l’équipe des développeurs coté VISEO, en se basant sur les spécifications fonctionnelles rédigées et validées par l’équipe projet de domaine Achats.

La partie fonctionnelle a été pris en charge par mon manager et moi. Après avoir effectué le développement de l’application et alimenter les tables avec les données de base nécessaires pour le bon fonctionnement de la part des développeurs dans l’environnement DEV, j’ai pris la main sur l’application pour faire le paramétrage nécessaire en créant des configurations qui font l’objet des chemins d’analyse.

Je détaille par la suite les étapes de paramétrage que j’ai effectué : Quand on clique sur la tuile présentée sur la Figure 57 on se dirige vers l’écran suivante qui constitue l’espace de travail ou j’ai paramétré les différentes interfaces graphiques de l’application :

1. Premièrement j’ai commencé par créer la configuration en renseignant le nom et son ID pour faire référence à sa base des données lors de l’exécution.

2. Ensuite on associe à la configuration une catégorie, je l’ai nommée Fournisseur.

3. Dans cette partie j’ai créé les étapes liées à la configuration en renseignant l’affectation à la catégorie ainsi que le service c’est la source des données pour cette étape, et les propriétés ou les indicateurs à suivre.

Pour chacun on a défini des représentions soit graphiques soit des tabulaires. La configuration des représentations est la dernière étape à faire ensuite on clique sauvegarder et exécuter pour tester l’application sur l’interface utilisateur et ça nous dirige vers l’écran suivante :

4. Pour tester le paramétrage qu’on vient de créer et de voir son adéquation avec le besoin de l’utilisateur, on ajouter des étapes d’analyses et après on les enregistre comme modèles pour l’utilisateur, donc on clique le Button + pour ajouter des étapes d’analyses, un pop-up s’affichera on choisit la catégorie Fournisseur, après l’étape Ratio par fournisseur et finalement on choisit la représentation.

On obtient finalement la représentation du risque pour chaque fournisseur avec en abscisse les valeurs du risque et en cordonné les fournisseurs correspondants.

C’est l’interface finale sur lequel l’utilisateur exécutera des filtres et personnalisera son analyse, il pourra ajouter d’autres représentation pour constituer un chemin d’analyse par exemple un tableau pour lier un fournisseur à ses composants. Une fois l’application est mise en place et paramétrée sur l’APF avec ses configurations que chacune fait l’objet d’un certain nombre d’étapes et chaque étape présente soit des tableaux soit des graphiques, c’est important de présenter cette application à l’utilisateur sous forme d’une tuile sur son page d’accueil principal.

Deuxième mission principale que j’ai réalisé pendant la conception de l’application Risque Fournisseur est de créer une tuile et de l’associer à l’application, Risque Fournisseur en effectuant toutes les configurations, nécessaires. A l’aide de l’outil standard FIORI SAP Smart Business Framework, un ensemble de tuiles, qui permettre à l’utilisateur de voir et d’analyser les données en temps réel, parmi ces tuiles on trouve la tuile Créer vignette que j’ai utilisé pour concevoir la tuile et construire un lien de celle-ci vers notre application.

En cliquant dessous on se dirige à l’écran suivante ou je peux créer des vignettes (tuiles) en cliquant sur Ajouter vignette : Une fois qu’on est sur l’écran suivante je peux choisir quel type de vignette je veux pour mon application pour notre cas j’ai choisi la vignette de comparaison car ça sera intéressant de comparer les risques par rapport les fournisseurs. Le paramétrage de la tuile contient deux parties, la première sur la Navigation j’ai renseigné les champs avec les bonnes informations comme c’est montré dans la figure ci-dessus et en mettant comme configuration celle que j’ai créé Risque Fournisseur.

La deuxième partie est sur la configuration de la tuile, j’ai nommé la tuile Risque Fournisseur et puis j’ai renseigné le catalogue sur lequel on mettra la tuile. Un catalogue c’est un ensemble des tuiles, on associe un catalogue à une rôle utilisateur pour que ce dernier peut accéder à des tuiles. Finalement on enregistre la tuile créée et pour la présenter sur l’interface principale de l’utilisateur on doit aller la chercher sur le catalogue renseigné ; X-SAP-UI2-CATALOGPAGE : ZCA_PUR_NEW_TILES en suivant une manipulation simple, et ensuite l’épingler sur l’écran utilisateur. Je présente ci-dessous la tuile finale que j’ai conçu sur l’interface utilisateur et ensuite les écrans de l’application derrière la tuile : L’application Risque Fournisseur est actuellement dans l’environnement QUAL en attente pour être tester par les BPO/IPO de domaine Achats, après la validation de leurs parts on la transporte éventuellement dans l’environnement PROD.

5. Conclusion Cette mission est la plus importante en termes de connaissances apprises que j’ai dû effectuée. Etant le garant de cette application chez le client, on a réalisé la validation des fonctionnalités auprès du client en effectuant plusieurs réunions présentielles ou via Skype, tout en essayant de répondre à leurs exigences dans des délai courts, et tout en gardant dans l’esprit que le client sera toujours le client malgré le contexte d’intimité dans lequel il se trouve, ça m’a permis de voir de près le métier d’un consultant fonctionnel, et ça m’a motivé en tant que débutant de donner davantage pour m’améliorer dans ce domaine.

Conclusion générale Dans le contexte d’amélioration de ses activités, ses processus métier, et dans l’optique d’adopter une nouvelle approche reposée sur un nouveau système d’information, le Groupe ATLANTIC a opté pour a la solution SAP S/4 HANA et comme intégrateur VISEO, le projet de déploiement de cette solution présente un défi majeur pour le Groupe aussi bien que l’intégrateur. Grace à ce nouveau système, le Groupe ATALANTIC aura une vision globale sur l’ensemble de ses activités et ses opérations, vu la visibilité qui lui offre ce système. Il sera cabale aussi de maitriser et optimiser ses dépenses dans ces divers métiers notamment le domaine Achats.

Ça va lui permettre aussi de mesurer sa performance à l’aide des indicateurs. Duran ce stage de fin d’études j’ai participé à plusieurs missions et tâches en tant que consultant fonctionnel junior SAP logistique j’ai rejoint le projet entre la phase des tests d’intégration et la phase des tests des UAT, en commençant par la présentation des formation aux utilisateur ainsi l’accompagnement des BPO/IPO dans ces formations, ensuite j’ai commencé à prendre la main sur le système SAP étant un système délicat au premier abord, les conseils de mon encadrant m’ont été très utile, au fur et à mesure de mon apprentissage j’ai participé à divers paramétrage et personnalisation des applications standards et spécifiques. Ma contribution au projet avait une conséquence sur l’évolution des mes compétence dans le monde des ERP notament SAP, les différentes tâches réalisées m’ont habituées au système et m’ont permis aussi de se mettre dans la peau d’un consultant fonctionnel SAP.

Mes interactions journalières avec les membres du projet qu’ils ont tous un caractère différent l’un de l’autre ont développé mes capacités d’intégrations et mon sens de relationnel. Bien évidement durant mon stage parfois, j’étais confronté à des difficultés et des obstacles mais j’ai trouvé toujours un soutien auprès des membres de l’équipe pour surmonter ces obstacles, pour cela je tiens à remercier encore une fois toutes les personnes de l’équipe pour cette belle expérience.

General conclusion In the context of improving its activities, its business processes, and in order to adopt a new approach based on a new information system, ATLANTIC Group chose the SAP S / 4 HANA solution and VISEO as an integrator. The project of deploying this solution represent a major challenge to the company as well as to the integrator.

Due to this brand-new system, ATALANTIC Group will have a global vision of all its activities and operations, given the visibility that offers this system. this will also allow the Group to master and optimize its spending in these various businesses, particularly the Purchasing sector. It will also allow him to measure his performance using indicators.

During this graduation internship I participated in several missions and tasks as a junior functional consultant SAP Logistics, I joined the project between the phase of integration tests and the testing phase of UAT, starting with the presentation of user training as well as BPO / IPO support in these training seminars, then I started to take control of the SAP system being a delicate system at first, the advice of my supervisor was very useful to me, during the process of my learning I participated in various settings and customizations of standard and specific applications.

My contribution to the project had a consequence on the evolution of my skills in the world of ERP specially SAP, the various tasks has made me fluent in using the system and allowed me to put myself in the shoes of an SAP functional consultant. My daily interactions with the members of the project every one of them has a different character from the other one has developed my integration abilities and my sense of relational.

Of course, during my internship sometimes, I was confronted with difficulties and obstacles, but I always found support from my team members to overcome these obstacles, for that I want to thank all the people of the team for this beautiful experience.